顧客満足 2 — 溝を越える：内部顧客関係の実践

ケース3：錦上添花と本質的な要求 — 力を正しい場所に使っていますか 掘り下げた議論の中で、ある参加者が、どの開発チームも一度は考えるべき問いを投げかけました。下流に技術案を届けるとき、私たちはアーキテクチャの先進性、コードの美しさ、ドキュメントの完備——いわば「錦上添花」——に関心を向け、顧客の最も本質的な要求をちょうど見落としがちです。本質的な要求とは、下流チームがあなたという上流に依存する根本理由のことです。インターフェースが安定しているか、ミドルウェアが信頼できるか、コンポーネントが既存の技術スタックに摩擦なく組み込めるか。 現実的な開発現場で考えます。基盤チームが業務開発チーム向けに新しいマイクロサービス基盤を投入しました。画面は美しく、監視ダッシュボードは充実し、ログトレースも完備——技術的には非の打ちどころがありません。ところが業務チームが実際に接続すると、カナリアリリースの方式が既存の CI/CD パイプラインと互換でなく、リリースのたびに手作業でトラフィックを切り替える必要がある。エラーコード体系は既存のアラートルールとまったく合わず、アラートは洪水になるか取りこぼすかのどちらかです。これが解決しないうちは、どれほど美しい基盤も業務チームには負担です——「虎に翼」ではなく「保守すべきシステムが一つ増えた」だけです。 ここで要求の階層が効いてきます。基本要求——インターフェースの安定、性能の信頼性、既存スタックとの互換性——は、下流があなたに依存する根本理由です。期待要求——明確なドキュメント、迅速な対応、低い接続コスト——は満足度を直接上下させます。興奮要求——先進的な設計、美しいコード、想定を超える性能——は驚きを生みますが、基本要求が満たされてはじめて意味を持ちます。開発チームで最も多い誤りは、互換性と安定性が十分に検証されないまま、期待要求や興奮要求に過剰投資すること——アーキテクチャの先進性で業務の可用性を置き換えてしまうことです。 ある参加者はこう言い切りました。「硬貨の両面を見る必要がある」。同じ硬貨の片面は上流が見る「何を届けたか」、もう片面は下流が感じる「何が使えるか」。図柄はまったく違うのに、上流はしばしば同じ面だと思い込みます。 「私はこう思う」から「あなたが確認する」へ — 視点校正の論理 参加者が役割を入れ替える前後で認識を比べたとき、鋭い洞察が現れました。開発者なら誰でも「供給者」と「顧客」を同時に生きています。午前に自分が SDK を届け、午後に誰かがコンポーネントを届けてくれる。受け取る側の瞬間、自分が何を気にするかは手に取るように分かります。そのまま組み込めるか、既存機能を壊していないか、ドキュメントは本当に動くのか。ところが届ける側になった瞬間、その感覚は消え、自分の成果物への自然な肯定に置き換わります——「コードは問題ない、ドキュメントもある、そのまま使ってくれ」。 この「役割忘却」は、内部顧客関係で最も見えにくい認知の仕組みです。意図的なダブルスタンダードではなく、役割が切り替わるときに脳が別の参照系を起動するのです。供給者のとき、脳は自分の開発過程の記憶——夜遅くの不具合修正、繰り返した負荷試験、丁寧に書いたドキュメント——を呼び出し、「もう十分やった」という証拠の連鎖を作ります。顧客のとき、脳は自分の利用体験——接続の失敗、版が合わないドキュメント、実際の場面に合わない性能——を呼び出し、「あなたは私の必要を理解していない」という証拠の連鎖を作ります。二つの連鎖は交わらないまま、同じ一人の中に同居します。 したがって視点校正の核心は「相手の立場で考えよう」という漠然とした標語ではありません。実は誰もが、受け取る側になれば相手がどう振る舞うべきかを本能的に知っています。本当の校正は役割が切り替わるその瞬間に起こります。「届ける」を押す前に、強制的に受け取り手の身分へ移り、問うのです——もし今これを受け取ったら、最初の反応は何だろうか。この小さな思考操作が、受け取る側で蓄積した実感を、届ける側の行動へ直接写像します。 溝を越える — 4ステップの実践フレーム ステップ1：理解を「結論」から「仮説」に下げる。 「下流はこのインターフェースを必要としている」と思ったら、心の中で印を付けます——「下流が必要と仮定しているが、まだ検証していない」。この操作だけで納品行動が根本的に変わります。完成した API を投げて反応を待つのではなく、草案を持って短くすり合わせる。三十分ではなく三秒ではなく、三十分の確認が三日の手戻りを省きます。 ステップ2：要所で先に合わせる。 満足度の検証を最終納品に圧縮しないこと。要求理解の段階で「私の理解では A・B・C が必要、合っていますか」。設計段階で「議論の方向に沿うと、こう設計する予定です。抜けはありますか」。段階納品で「これが現行版です。期待との差はどこですか」。確認のたびに溝は狭まります。最後にだけ検証しても、調整の余地は残っていません。 ステップ3：要求の階層を分け、基本を固めてから卓越を狙う。 納品リストを二列に分けます——「必ず満たす」と「さらに良くする」。「必ず満たす」は、既存プロトコルとの互換、統合場面での性能達成、ドキュメントのサンプルコードが実際に動くこと。「さらに良くする」は、洗練された設計パターン、充実した監視、想定超えの負荷試験値。前者が下流に検証されるまで、後者に余力を割かないこと。卓越が不要なのではなく、基礎が固まる前の内装は双方の信頼を浪費するからです。 ステップ4：「確証」ではなく「反証」を探す。 脳は自分の既有信念を支える証拠を集めたがります。これを確証バイアスと呼びます。機能やミドルウェアやコンポーネントを届けたあと、私たちは無意識に「下流が褒めた一言」に注目し、「下流が眉をひそめた一瞬」を見落とします。対抗策は意識的な反例探しです。下流にこう問います——「今回の納品で、いちばん不満な点はどこですか」。この問いは居心地の良い場所から引きずり出し、聞きたくない答えに耳を向けさせます。そこが溝を狭める出発点です。 結び：謙虚さが最良の認知ツール 内部顧客関係の認知の溝は、技術力や経験が伸びても自然には消えません。むしろ逆です。経験を積んだ開発者ほど「下流が何を必要としているか分かっている」という固定観念を作りやすく、自分の技術判断を相手の業務要求と同一視しやすくなります。ワークショップで起きた場面——供給者が顧客の目の前に座りながら、顧客の本当の必要を完全に見誤る——は、偶発的な失敗ではなく、体系的な認知の困難を示しています。 最も確信している瞬間に、認知のレーダーは切れています。新しい情報を受け取らず、仮説を検証せず、自分の結論と食い違う声に耳を貸さない。この溝を越える唯一の道は、自分の認知に対する謙虚さです。謙虚さは自信の欠如ではなく、自分の認知の限界をはっきり自覚すること。それがあれば、納品のたびに少し立ち止まり、身分を切り替え、最も簡単で最も忘れられやすい問いを発せます——もしこの納品物を受け取ったら、私の第一反応は何だろうか。 ある参加者がワークショップの最後に語ったとおりです——「硬貨の両面を見る」。開発組織の内部サプライチェーンで、誰もが一日中その両面を行き来しています。切り替えのたびに校正の機会があります。溝は決して埋まりきりませんが、誠実な校正のたびに少しずつ狭くなります。そしてそれは、おそらくどの開発者も一生かけて鍛える基礎力なのです。