役員会で「AIで基幹刷新を進める」という方針が決まった。翌週、IT課長のデスクに刷新プロジェクトの企画書が降ってきた。予算も期限も、判断材料も断る権限も渡されないまま、着手だけが決まっている。
flowchart TD
A[役員号令] --> B[期待値未定義]
B --> C[現場丸投げ]
B --> D[問いで壊す]
D --> E[条件付き受託]
役員の号令と現場の実態がズレたまま走り出す#
外から観察してきた限り、この手の刷新案件は企画書が課長に届く時点で、成功の定義がまだ役員の頭の中にしかない。「AIで効率化」「刷新で競争力を」という言葉だけが先に降りてくる。
私が話を聞いてきた課長たちは口を揃えて言う。「予算も期限も承認済みなのに、何をもって成功とするかだけが決まっていない」と。
この段階で課長にできるのは、渡された前提をそのまま受け取り、資料に落とし込むことだけだ。判断材料も断る権限も渡されていないから、疑問を挟む余地がない。
この構造は珍しくない。上位の意思決定と現場の実行の間に、情報の非対称がそのまま残っているからだ。大型のIT刷新プロジェクトほど、生成AIへの期待の設定が実態と乖離したまま着手され、成果を出せずに終わりやすい。
期待値の設計者と実行者が分離している#
役員は「AIで刷新」という号令の結果責任を負う。一方で、現場が何を実行可能かという情報は持っていない。
逆に課長は実行可能性を知っていても、期待値を設定する権限を持たされていない。号令と実行の間に、判断の主体が二つに割れている。
この分離が、号令の時点で期待値と実態を乖離させる。乖離したまま着手すれば、失敗の芽は発足前にすでに埋め込まれている。
私から見ると、この号令自体が悪いのではない。悪いのは、期待値を誰も所有していない状態のまま着手させることだ。課長が資料を磨いても、進捗を細かく報告しても、乖離そのものは埋まらない。磨くべきは資料ではなく、役員が握っている期待値そのものだ（役員説明の問いの設計にも同じ構造がある）。
発足前に期待値を壊して、条件付きで組み直す#
期待値を壊せるタイミングは、着手前しかない。着手してしまえば、失敗の責任は現場に付け替えられる。
- 成功の定義を役員の言葉で書かせる 「何をもって成功とするか」を文書化させる。書けない号令は、実行段階に進めない。
- 判断材料の提出を着手条件にする 必要なデータ・予算・期限を、先に役員側から提示させる。
- 受託は条件付きで返す 「この3条件が満たされれば引き受ける」という形で、期待値のボールを役員に返す。
これは反対ではない。号令そのものは否定せず、実行可能な形に組み直す作業だ（30秒で論点を握り返す手順は役員説明の手戻りを止める方法に書いた）。断る権利を使わなくても、期待値コントロールだけで乖離の大半は削れる。
失敗確定後は先に降りる#
条件付きで受託しても、途中で乖離が埋まらないと分かる瞬間が来る。そこから先は挽回ではなく、撤退のタイミングを見極める番だ。
進捗報告に「当初の前提条件が崩れている」と一行残す。役員の合意のもとで撤退した記録は、あなた個人の失点にならない。
それでも撤退が認められないなら、異動願いを出すか、主担当を外れる交渉に切り替える。退路は最初から用意しておく（断る権利の作法も同じ発想で書いた）。
期待値は号令ではなく問いで受け取る#
「AIで刷新」という号令は、そのまま資料化する対象ではない。課長の仕事は、発足前に期待値を壊し、条件で組み直して役員に返すことだ。
本記事は AI が下書きし、管理人が監修しています。
