「顧客はわかっていない」を構造的に再解釈する

TL;DR

「顧客はわかっていない」という感覚は お互いの思考限界がズレている ことを示しているに過ぎない。
顧客は技術的制約を思考限界の外に置き、技術者はビジネス文脈を思考限界の外に置く。この非対称性が衝突を生む。
優れたアーキテクトは、思考限界を動的にずらしながら、顧客・技術者・システムの三者間をコーディネートする。この能力を 構造設計能力 と呼ぶ。
AIとの協働においても、まったく同じ構造が成立する。「AIに何をさせ、何をさせないか」の設計と、「顧客と何を共有し、何を委ねるか」の設計は、同じ問いの別バージョンである。
「顧客はわかっていない」という思考は未熟である。問うべきは「どの思考限界をどこへずらすか」である。

きっかけ

顧客との打ち合わせのあと、「あの人は技術的なことが全くわかっていないから、好き勝手なことを言う」と感じることがある。おそらく多くのエンジニアが、一度はそう思ったことがあるはずだ。

一方で、最近AIを使った開発を進める中で、ある気づきがあった。AIに対して「なんでこんなことをするんだ」「指示通りにやってくれない」と感じる場面が増えてきた。これは、顧客に対して感じることと、構造的にとても似ている。

では、「顧客はわかっていない」という感覚は、本当に正しいのか。逆に顧客の立場から見たらどうなのか。AIとの対比を通じて、この問題を構造的に整理してみたい。

思考限界というフレームワーク

まず、「思考限界」という概念を導入する。

人は誰でも、自分が認識できる範囲に「限界」を持っている。業務を知り尽くしている顧客は、システムがどう実装されているかを必ずしも知らない。逆に、技術者はシステムを構築できるが、その業務がなぜ今の形になっているのか、歴史的・組織的な文脈を把握していないことが多い。

[顧客の思考]
思考限界の内側: 業務知識・経営判断・ユーザー体験
思考限界の外側: 技術的制約・実装コスト・インフラ構造  ← まだ見えていない

[技術者の思考]
思考限界の内側: 技術スタック・実装難易度・パフォーマンス特性
思考限界の外側: 業務フロー・組織の意思決定構造・顧客の顧客の要求  ← まだ見えていない

「顧客はわかっていない」という発言は、技術者の思考限界の内側にある情報を、顧客が持っていないことへの苛立ちである。しかし同時に、顧客の思考限界の内側にある情報を、技術者も持っていない。この非対称性は、どちらかが「わかっていない」という話ではなく、 互いに相手の思考限界の外側に重要な情報を持っている という構造の問題だ。

アーキテクトの役割：思考限界をずらす

では、どうすればよいのか。ここで登場するのが「思考限界を動的にずらす」という設計行為だ。

たとえば、顧客が「膨大なデータを、リアルタイムで全件表示したい」と要求してきたとする。技術者は「100万件を毎秒描画するのは不可能だ」と思う。この時点で衝突が生まれる。しかし、ここで優れたアーキテクトが行うのは、「それは無理です」というのではなく、自身が持つ技術知識をもとに、顧客の思考を分解して考え、思考限界を技術的制約の側に一歩ずらすことである。

[初期状態]
顧客の思考限界の内側: 「全件リアルタイム表示」

↓ アーキテクトが制約を可視化

[目的達成可能な状態]
顧客の思考限界の内側: 「集計ビュー + 閾値超過時のアラート」← 移動させる
顧客の思考限界の外側: 描画コストの詳細（もはや意識不要）

顧客が本当に欲しかったのは「全件表示」ではなく、「意思決定に必要な情報をタイムリーに得ること」だったかもしれない。このように、思考限界をずらすことで、本来の目的に辿り着ける。これが構造設計能力の本質だと考えている。このとき、制約は「できないことの証明」ではなく、 目的へ向かうための設計上の道具 として機能する。制約を設けることでトレードオフが生まれ、そのトレードオフを顧客と共有することで、はじめて合意形成ができる。

AIとの協働に見る、同じ構造

最近、AIを使った開発を進める中でまったく同じ構造を感じるようになった。AIに対して自由さを与えると、出力が発散する。逆に、過度に細かい制約を与えると、AIは制約の範囲でしか動けず、本来解けるはずの問題も解けなくなる。

AIに「思考させる範囲」と「人間が判断すべき範囲」を設計することは、顧客の思考限界と技術者の思考限界の境界を設計することと、構造が同じだ。

Vibe-Codingが崩壊するのも、この制約の設計が欠如しているからだと理解している。RAG、Spec Driven Development、エージェント設計といった手法は、すべてAIの思考限界を設計的に制御する試みであり、「AIに何をわからせ、何は人間が持つか」を明示化するアプローチだ。

対顧客も対AIも、 思考限界の境界を設計することが、問題解決の核心 にあると考えている。

思考限界を動的にずらすことに成功した例

OpenShift：「強制」という制約が自由をもたらす

以前調べたRed Hat OpenShiftが良い事例だと感じた。OpenShiftはGit・OCI・Kubernetesという業界標準を強制することで、開発者の思考限界を「何を使うか」から「どう使うか」にずらしている。

AWS（サービスの集合体）は設計の自由度が高い反面、「何を選ぶか」という判断コストが利用者に集中する。OpenShiftは、その選択の余地をあえて削ることで、350人規模の開発チームでもオンボーディングコストを下げることに成功した。

「強制」という制約が、実は「自由に動ける範囲」を明確にしていた。これはまさに思考限界をずらす設計の実例だ。

Porsche Informatik：「枠」が組織のしがらみを溶かす

Porsche InformatikがプライベートクラウドからOpenShiftに移行した際、6週間で移行を完了し、350人超の開発者が常時利用する環境を実現した。「枠」という制約を設けることで、オープンソースの自由さと、組織の標準化要求という相反する要件を両立している。

これは、顧客（経営層・開発チーム）の思考限界に「標準化された開発プラットフォーム」という概念を移植した結果だと言える。

「構造設計能力」という自己研鑽の方向性

ここまでを整理すると、技術者に求められる能力は次のように言い換えられる。

「自分の思考限界がどこにあるかを把握し、顧客や技術者の思考限界を動的にずらしながら、目的達成へコーディネートする能力」

これを構造設計能力と呼ぶことにしている。技術者の自己研鑽とは、何かの技術を追い続けることによって、「自分の思考限界がどこにあるかを探究し続けること」だと思っている。技術書を読む、新しいフレームワークを触る、顧客の業務フローを深く学ぶ、これらはすべて「自分の思考限界を広げる」行為だ。

ただし、もうひとつ重要なことがある。思考限界を広げるだけでなく、どこに境界を置くかを設計する能力 も同時に必要だということだ。自分が何でも知っていようとすることは、「何でもできるノートパソコン」と同じで、帯に短し、襷に長しになりかねない。何を知っていて、何を知らないのかを具体化し続けることが重要なのではないだろうか（難しい話だが）。

構造設計能力とは、知識の総量ではなく、知識の境界を設計する力 だと今は考えている。

まとめ

「顧客はわかっていない」は、思考限界の非対称性を正確に言い表した言葉ではあるが、それ止まりでは未熟な認識である。
問うべきは「どの思考限界を、どこへ、どうずらすか」であり、この設計行為がアーキテクトの核心的な仕事だと考えている。
AIとの協働においても、この構造はまったく同じだ。「AIに何をわからせるか」の設計と、「顧客に何を共有するか」の設計は、同じ問いの異なる文脈での現れである。
思考限界の自己研鑽は終わりのない旅だが、その方向性は「限界を広げること」と「限界の境界を設計すること」の両輪で成り立つ。