予算は付いた。ツールも導入した。体制図も引いた。それなのにプロジェクトが前に進まない——AI・DX案件でこの相談が目立って増えています。会議は毎週開かれ、資料も積み上がっているのに、肝心のことが決まらない。

原因をPMの力量や現場の抵抗に求めると、次の案件でも同じことが起きます。止まる組織には共通した構造があるからです。本記事では、その構造を「意思決定の設計不全」として分解し、着手前に決めておくべきことと、決定を回し続けるための運営を、発注者側の推進責任という立場で整理します。

課題 ― 「止まっている」ことが誰にも見えない

遅延は通常、進捗報告で顕在化します。実務で厄介なのは、タスクは動いているのに前進していない状態です。検討は続き、比較表は精緻になり、会議体も定刻に回っている。しかし決めるべきことが決まっていないため、後工程が着手できません。

この状態は進捗率にほとんど現れません。「検討中」は遅れとして計上されないからです。期限が迫って表面化したときには先送りされた決定が積み上がっており、取り戻す手段はスコープ削減か納期延伸しか残っていません。多くのプロジェクトは作業が遅いから失敗するのではなく、決めない時間が積算されて失敗します。

なぜ意思決定が止まるのか ― 三つの構造

第一に、目的と成功条件が言語化されていない。 「業務効率化」「DX推進」という水準で止まっていると、選択肢を比較する物差しがありません。物差しがなければ、どの案も明確には否定できず、結果としてどの案も選べません。議論が一周して振り出しに戻る会議は、たいていここに原因があります。

第二に、決める人が特定されていない。 プロジェクト責任者は任命されていても、「予算の増額は誰が決めるのか」「部門をまたぐ業務ルールの変更は誰が承認するのか」が事前に決まっていない組織は珍しくありません。論点が出るたびに決裁者を探すところから始まるため、一件ごとに待ち時間が発生します。

第三に、課題・リスク・変更・決定が別々に管理されている。 課題管理表とリスク一覧と変更管理票が別々のファイルにあり、いま何が誰の判断待ちなのかを一覧できません。待ち行列そのものが見えないため、遅れの原因を特定できません。

いずれもPM個人の努力不足ではなく、プロジェクトの入り口で設計されなかったことの帰結です。

着手前に決めておく五点セット

プロジェクト憲章やキックオフ資料に、次の五点を書き下します。どれも「あるはず」で済まされがちですが、一枚の文書に収まっていない限り共有されているとは言えません。

決めること 書き下すべき内容
目的 何のためにやるのかを、事業側の言葉で一文にする
成功条件 何が達成されたら完了と見なすか。判定できる形にする
責任者（オーナー） 成果に責任を持つ人。原則として事業側に置く
意思決定者 論点の種類ごとの決裁者と、決裁できる範囲
対象範囲 やること／やらないこと。特に「やらない」を明示する

なかでも効果が大きいのが、意思決定者を論点の種類ごとに分けておくことです。予算、スコープ、業務ルール、要員、リリース可否——これらは決裁者も判断の重さも異なります。一律に「ステアリングコミッティで決める」としてしまうと、本来は現場で即決できる論点まで月次の会議を待つことになります。逆に、重い判断を実務者が一人で抱え込む事故も防げます。誰がどのレイヤーで何を決めるかという設計は、PMOの型とレイヤーの設計と地続きの問題です。

決定を「運営」に組み込む

五点セットを決めても、運営に乗らなければ元に戻ります。次の三つを定例の仕組みに組み込みます。

決定を記録する。 いつ、誰が、何を、どの選択肢の中から、なぜ選んだかを一箇所に残します。「そんな話は聞いていない」による手戻りが減るうえ、万一トラブルに至った場合でも、責任の所在は主張の強さではなく通常運営の記録で判断されるため、平時の記録がそのまま守りにもなります。

判断待ちを待ち行列として見せる。 課題・リスク・変更を一つの管理体系にまとめ、各項目に「誰の判断待ちか」「いつまでに決めるか」を付けます。進捗報告に判断待ちの件数と最長滞留日数を並べるだけで、止まっている場所が可視化されます。

定例を報告の場から判断の場に変える。 議題を「報告」と「判断を求める事項」に分け、後者には論点・選択肢・推奨案・決めない場合の影響をあらかじめ添えます。準備のない議題を持ち込ませないルールが、会議の回数より効きます。

AIで速くなる領域と、詰まったままの領域

進捗の集計、議事録の作成、課題の抽出、リスク兆候の検知——このあたりはAIの導入で確実に速くなります。一方で、目的の合意、部門間の利害調整、責任を伴う決裁は速くなりません。

つまり、管理業務が速くなるほど、判断待ちがボトルネックとして目立つことになります。「報告資料の作成は楽になったが、完了時期は早まらない」という結果になる組織は、詰まっている場所が最初から意思決定側にあったということです。PMO業務のどこをAIに任せられるかを検討する際も、削減できるのは作業時間であって判断時間ではない、という前提を置く必要があります。

よくある失敗と回避策

失敗パターン 回避策
目的が「DX推進」のまま着手し、比較の物差しがない 成功条件を判定可能な表現にし、キックオフ前にオーナーと合意する
オーナーがIT部門に置かれ、業務側が当事者にならない 成果責任は事業側に置き、IT部門は推進と技術判断を担う分担にする
論点が出るたびに決裁者を探し、都度時間が溶ける 論点の種類ごとに決裁者と決裁範囲を事前に割り当てる
判断待ちが管理表に埋もれ、遅れの原因が特定できない 判断待ち件数と滞留日数を進捗報告の定型項目にする
決定の経緯が残らず、同じ議論が何度も蒸し返される 決定記録を一箇所に集約し、変更時は前の決定を参照して差分で残す

まとめ

プロジェクトの完遂力は、担当者の粘り強さではなく組織の設計から生まれます。目的と成功条件を言語化し、論点の種類ごとに決裁者を決め、判断待ちを見える化し、決定を記録する。特別な手法ではなく、着手前と定例運営という二つの場面で意識的に設計するかどうかの差です。

AIによって管理業務が軽くなるこれからは、この差がそのまま成否として現れます。次の案件のキックオフで、五点セットが一枚の文書になっているかをまず確認してみてください。

FAQ

Q. 五点セットを決めようとしても、経営から明確な答えが返ってきません。 A. 答えを待つのではなく、こちらから案を出して否定してもらう進め方が有効です。「成功条件はこう置きます。異論がなければこれで進めます」という形で仮置きし、期限を切って合意を取ります。空欄のまま止めるより、仮の物差しがある方が議論は前に進みます。

Q. 決裁者を細かく分けると、かえって統制が効かなくなりませんか。 A. 分けるのは決裁者と範囲であって、報告先ではありません。現場で決めた事項も、決定記録を通じてステアリングコミッティに可視化される状態を保てば、統制は弱まりません。むしろ「重い判断だけが上位に上がる」ため、経営の審議の質は上がります。

Q. 既に走っていて止まっているプロジェクトには、どこから手を付けるべきですか。 A. 判断待ちの棚卸しからです。いま決まっていない事項をすべて洗い出し、それぞれに決裁者と期限を割り当てるだけで、動く案件は少なくありません。目的の再定義はその後で構いません。

Q. 外部のPMOに支援を依頼する場合、何を期待すべきですか。 A. 資料作成の代行ではなく、判断待ちを可視化し、決めるべき論点を選択肢の形に整えて意思決定者の前に持っていく役割です。会議体の設計と論点整理を任せられるかどうかが、支援先を選ぶ際の見極めどころになります。

参考資料