〜「正解」がコモディティ化する時代に、リーダーが引き受けるべき固有の役割〜
1. はじめに：「正解」が溢れる時代に、人間に残る「責任の境界線」を考える
2026年現在、エンジニアリングマネージャー（EM）を取り巻く環境は一変しました。かつて、リーダーの価値は「誰よりも正解を知っていること」や「迅速に決断を下すこと」にありました。しかし今、論理的な最適解やリスクの洗い出し、さらにはプロジェクトの実行プランに至るまで、生成AIに問えばわずか数秒で「それらしい回答」が手に入ります。
回答が容易に、そして安価に手に入るようになった時、私たちマネージャーの価値はどこへ向かうのでしょうか。もし、AIが出した答えを確認し、判を押すだけの存在になっているとしたら、それは「マネジメント」ではなく単なる「処理」です。
本稿では、AI時代のEMが真に担うべき役割は答えを出すことではなく、組織が解くべき「問い」の質を設計し、その結果に対する責任をデザインすることにある、という視座を提示します。
2. 意思決定の自動化と、人間に残る「境界線」
AIが得意とするのは、過去のデータ、膨大なベストプラクティス、実理的な整合性に基づいた「予測」と「最適化」です。しかし、どれほど技術が進歩しても、AIには決してできないことが二つあります。それは、「不確実な未来に対する『賭け』」と、「その決断がもたらす感情的な文脈への責任」です。
AIは「A案の方が成功確率が15%高い」と提示することはできますが、その15%の不確実性が顕在化した時、組織の動揺を鎮め、メンバーの目を見て「この判断は私が下した。次へ進もう」と告げることはできません。多種多様なプラットフォームとサーバーサイド基盤が複雑に絡み合う開発現場において、AIは「予測」はしてくれますが、「覚悟」はしてくれません。
3. 問いの設計責任を構成する3つの要素（前提・リスク・納得感）
リーダーシップを「問いの設計」として捉え直した時、EMが注力すべきは以下の3点に集約されます。
① 前提条件の定義（Context Design）
AIに問う前に「何を解決すべきか」の制約条件をどう置くか。
典型的な失敗： 「問いが広すぎる」ケースです。 状況設定（コンテキスト）を曖昧にしたままAIに問うと、教科書通りの「もっともらしいが現場では使えない答え」しか返ってきません。これはEMが現場の解像度を直視することを放棄した時に起こる失敗です。
実践のポイント： 「技術負債を返却すべきか」ではなく、「チームの習熟度と来期の目標を天秤にかけ、どのモジュールから着手するのが組織の持続性を最大化するか」という問いを立てること。
② 失敗の許容範囲の設計（Risk Boundary）
判断が外れた際、どこまでなら組織は耐えられるかという「防波堤」をあらかじめ設計すること。
典型的な失敗： 「リスクの丸投げ」です。 AIの出した最適解をそのまま採用し、失敗した際に「AIがそう言ったから」という空気が流れてしまう。これは、EMが「失敗した時の責任の取り方」を設計できていない典型的なパターンです。
実践のポイント： 決断そのものよりも、失敗した際の「後始末」の道筋を立てておくことこそが、現場が安心してアクセルを踏めるためのインフラとなります。
③ 納得感の醸成（Narrative Building）
AIの答えを、メンバーが「自分たちの意思」として受け取れるストーリーへ昇華させること。
典型的な失敗： 「論理の押し付け」です。 AIが導き出した「正解」は、時に冷徹で感情を無視します。現場の感情的な揺らぎを無視して「これが論理的に正しいから」と押し通すと、組織のエンゲージメントは急速に冷え込み、実行力が失われます。
実践のポイント： なぜ今、この道が最良なのか。この文脈の構築こそ、AIには代替不可能な人間らしいリーダーシップの核心です。
実務における判断の切り分け：AIに委ねる部分と、人間が引き受ける部分
ここで、現場の判断基準を整理してみましょう。
- AIに任せていい（決めなくていい）こと: 過去の類似案件に基づく工数見積もり、標準的なエラーハンドリングの方針、静的解析に基づくコード品質の判定。
- EMが引き受ける（決めるべき）こと: 「今は速度を優先し、技術負債をあえて許容する」という経営的判断、チーム間のコンフリクトを解消するためのリソース配分、そして失敗時の全責任の所在。
思考停止の回避：AIを「丸投げ」にせず、意志のある意思決定を行うために
AI時代のマネジメントにおいて、最も避けるべきは「AIを免罪符にする」ことです。例えば、複数のプラットフォームにまたがる複雑な改修の優先順位を、AIにそのまま決めてもらう。一見効率的に見えますが、そこには「なぜその順位なのか」というEM自身の意志が欠落しています。
問いを誤ったEMは、AIが出したアウトプットの「整合性」だけをチェックし、その裏側にある「メンバーへの負荷」や「将来的な技術の柔軟性」という、数値化しにくい変数を無視しがちです。結果として、組織は論理的には正しいが、誰も情熱を持てない「死んだプロジェクト」を抱えることになります。
4. 実践：AIを「最良の批判者」に変え、思考の死角を補完する具体プロンプト
「問いの設計」を磨くために、私はAIを「答えをくれるツール」ではなく「自分の思考を叩き壊すための批判者」として活用しています。前回の記事（子記事No.6：WBSを手放す勇気）で触れた「60%の仮説」を、私はそのままAIにぶつけます。
プロンプト例：
- 「この戦略案において、複数のプラットフォーム間の整合性を損なうような『隠れた依存関係のリスク』を3つ挙げよ」
- 「私が提示したこの工数削減案に対して、現場のリードエンジニアが抱くであろう『感情的な懸念』とその対策をシミュレーションしてほしい」
- 「来期の予算配分案に対し、あえて『反対派の役員』の立場で論理的な欠陥を指摘せよ」
答えを求めるのではなく、自らの問いの「死角」をAIに補完させる。このプロセスを経て磨き上げられた戦略は、上層部への説明責任（Accountability）を果たすための強固な盾となり、同時に、現場に対する誠実な「覚悟」へと昇華されます。
実務への適用：問いを構造に変える
この「問いの設計」という思想を、日々のマネジメント実務に落とし込んだ各論は以下の通りです。
- 管理を手放す: 30/60/100%の解像度管理
- 論理の盾を作る: 説明責任（Accountability）の果たし方
よくある質問（FAQ）
- Q. AIに意思決定を任せる際、EMが最も注意すべき点は？
- A：結論として、AIの回答を鵜呑みにせず、その回答を採用した際のリスクを「設計」し、責任を引き受ける覚悟を持つことです。
- AIは論理的な最適解を提示しますが、最終的な意思決定に伴う「責任」を取ることはできません。
- Q2. 「問いの設計」をチームに浸透させるには？
- A：結論として、1on1や振り返り会において、「答え」そのものではなく「なぜその問いを立てたのか」という思考の前提条件を言語化し、チームと共有することです。
あわせて読みたい（関連記事）
本ブログの全体像や、複数の開発ラインを管轄する組織においてシニアEMが守るべきAI活用のロードマップについては、こちらの旗艦記事を参照してください。
AIによって確保した「思考の余白」を、どのように戦略的な解像度向上へ投資すべきか。その具体的なステップについてはこちらの記事で解説しています。
5. むすび：答えを出す人から、問いを育てる人へ
かつて、優秀なマネージャーとは「迷える現場に正解を指し示す人」でした。しかしこれからの時代、その役割は「メンバーがより良い問いを立てられるように環境を整え、最後に出た結果に対して『私が責任を持つ』と静かに告げる人」へと変わっていくでしょう。
管理や決断という重圧をAIと分かち合い、空いた手でメンバー一人ひとりの声に耳を傾け、組織の「問い」を育てる。この「問いの設計責任」という聖域に立ち返ることで、エンジニアリングマネジメントをより創造的で、より人間らしい喜びを伴う仕事へと再定義する責任が、今まさに私たちにあります。
