部屋をプロンプトできない：AI が代替しない最後のスキル

AI が代替しない最後のスキル：コードを書く力ではなく「部屋を読む」力

ソフトウェア開発において、AI によるコード生成が一般化し、実装のスピードが劇的に向上した現在。しかし、開発者の役割は単なる「実装者」から、「何を作るべきか」を決定する「価値設計者」へと本質的に転換しています。

今やボトルネックになっているのは技術的なスキルではなく、顧客やステークホルダーとの対話を通じて真の課題を見極める能力です。AI は既存の平均的な回答を返すことは得意ですが、人間同士の複雑なやり取りや「場の空気」を読み取ることはできません。つまり、部屋全体をプロンプトすることはできないのです。

コード作成は AI に任せて、ボトルネックは「対話」にある

過去 13 年間、私はソフトウェア業界でビジネスと IT、そして開発者の間を橋渡しする役割を務めてきました。かつてはテストや仕様書の作成、さらには実装まで手がけていましたが、今では AI が構築するための良質な仕様に情報を変換する訓練に注力しています。

しかし、顧客との関わり方やシステムへのアプローチという本質的な部分は、AI の登場によって大きく変わることはありませんでした。変わるのは「AI との関わり方」です。

今年初め、社内ハッカソンで約 21 の AI エージェントアイデアが提案されました。そのうち 17 は、データアクセスの問題やビジネス価値の欠如により中止になりました。この結果は痛烈な教訓を与えてくれました。

コードや仕様全体をプロンプトで指示することはできますが、部屋（ステークホルダーとの対話環境）そのものをプロンプトすることはできません。

AI は定義上、「最も一般的な回答」を与えるようにプログラムされています。もし AI に「馬を速くしてほしい」と頼めば、それは既存の馬を改良する方向にしか働きません。しかし、真のイノベーションは、ユーザーが求めている「より多くの馬」ではなく、彼らが気づいていない「車」を提供することにあります。

コード作成が安価で高速になった今、開発者の最大の価値は「AI が平均的なものから離れ、私たちにとってより良い方向へ進むよう保証する」ことにあります。そのために必要なのは、顧客や意思決定者を部屋に招き、時間を共有して真の要件を引き出す人間力です。

復活する分析ツール：ストーリーマップとビジネスモデルキャンバス

「何を作るか」を決めるための最も有効な手段は、一見古くさいと感じるかもしれませんが、ストーリーマップやビジネスモデルキャンバスといった従来の分析ツールの再評価です。

これらは単なる製品管理の手法ではなく、AI に正確な指示を出すための重要なツールとして復活しています。特にストーリーマップは、顧客がプロセスをどのように進めるかを理解する上で不可欠です。

例えば、サポートシステムのケース処理を例にとると、以下のようになります。

1. バックボーン（全体像）: 連絡 → トリアージ → 解決 → クローズという顧客の行動ステップを定義します。
2. ユーザーストーリーの配置: ステップごとに「誰が」「何を」行うのかを記述し、優先度や緊急性を分類します。
3. 詳細化: 最初のセット（MVP）と、その後の機能拡張（感情の読み取り、チームへの書き込みなど）を階層化します。

AI はパターン認識に優れており、このように構造化されたユーザーストーリー（ペルソナ・行動・ニーズ・理由）の形式に非常に慣れています。これらの要素をパッケージ化して AI に渡すことで、明確な受け入れ基準に基づいたテストケースや仕様書、そして最終的なコードを生成させることが可能になります。

古くからのスキルですが、これこそが今や「適切な要件を引き出す方法」であり、「より良いソフトウェアを構築する」ための新しい経済性です。

VAD プロセス：価値・アーキテクチャ・デザインの思考法

顧客の真の課題解決を目指すためには、VAD（Value, Architecture, Design）という思考プロセスが有効です。これは単なる上流工程の手法ではなく、AI を活用する現代において必須のステップです。

1. 価値（Value）: 誰の問題か？成功とはどのような姿か？利用を拒む要因はないか？
2. アーキテクチャ（Architecture）: その価値を生み出すためのプロセスと基盤となるシステムはどうあるべきか？
3. デザイン（Design）: 上記の価値とプロセスを最適に支える具体的な設計は何か？

この順序で考えることで、AI に「エージェントを構築して」といった曖昧な指示を出すのではなく、「顧客が A という課題を抱え、B というプロセスで解決したいという文脈がある。そのためのシステムを設計せよ」という文脈豊かな指示を与えることができます。

具体的な問いかけとして、以下の 4 つの質問を常に意識します。

• これは誰の問題でしょうか？（ペルソナの特定）
• 成功とはどのような姿でしょうか？（成果の定義）
• 彼らが使用を拒む要因は何でしょうか？（セキュリティや使いやすさの確認）
• このシステムは決定を変えるのでしょうか？（意思決定への影響）

これらの答えを Markdown ファイルなどに記録し、AI がアクセスできる状態にしておくことが、高品質な成果物への近道です。

KPI の転換：リリース数から「利用頻度」へ

AI によってコード作成が容易になった結果、企業は「間違ったものを作る速度」を上げてしまうリスクがあります。新機能を異常なほど速くリリースしても、実際に使われていなければ意味がありません。

従来の指標である「リリースされた機能の数」や「デモの完成度」は、もはや良い KPI ではありません。デモは美しく見えても本番環境では誰も使わないケースが多く、PRD に実際のユーザーテストが含まれていないと、開発が止まってしまうからです。

今求められている指標は以下の通りです。

• 実際に利用されている機能の数: 2 回以上使用された機能に注目する。
• 特定の活動の頻度: サイト滞在時間ではなく、コアとなるアクションの回数を見る。
• 廃止すべき指標: 先四半期に出荷された機能の総数は削除し、代わりに「利用頻度」を重視する。

優秀な人材は、コードを書くことよりも「何を構築するかを決定する」ことに費やすべきです。コストのかかる部分を減らすためには、開発者や実務の専門家を意思決定のプロセスに巻き込み、彼らの経験知を活かす必要があります。

結論：上流工程へシフトし、正しいものを作る

AI エージェントやコード生成ツールの普及は、開発者の役割を「実装」から「要件定義・価値設計」へと完全に転換させました。技術的なスキルよりも、ビジネス理解力と対話能力を持つ人材の重要性が急増しています。

今すぐできることは、全員をプロダクトマネージャーにする必要はありません。重要なのは、構築前に必ずストーリーマップやビジネスモデルキャンバスを用いて価値創造のプロセスを明確にすることです。

AI に頼りすぎず、人間同士の対話から真の価値を見出すことで、私たちは単なる「次のもの」ではなく、「正しいもの」を構築できるようになります。これが、AI 時代において人間が最後に守るべきスキルなのです。