#25：正しい体制は、必要条件に過ぎない
─ 体制論の総括と、その先にある「意思決定」の問題
お世話になっております。YMGアドバイザリーの山口です。
今回は、少し立ち止待って話をしたいと思います。
Vol.19から6号にわたって論じてきた「体制論」を一度整理し、その先にある「意思決定」の問題へ進みます。
過去6号の議論は、一つの構造を指していた
Vol.19では、「管理」と「監理」の違いを取り上げました。
進捗、予算、課題、スケジュールを追いかける管理だけでは、プロジェクトが本当に正しい方向へ進んでいるかは判断できない。
プロジェクトの外側から構造を見て、必要なら立ち止まらせる「監理」の視点が必要だと論じました。
Vol.20では、その監理者をどこに配置するべきかを考えました。
ベンダーの下に置けば、契約や納期の制約を受ける。現場部門の中に置けば、局所的な事情に引っ張られる。
監理者が機能するには、進捗管理のラインから一定の独立性を持ち、経営層へ直接、構造上の問題を報告できる位置づけが必要です。
Vol.21では、監理者が何を見るのかを具体化しました。
Closed-loopが途中で断絶していないか。
AM-BOMと現場運用が整合しているか。
Bolted-onによる将来負債が積み上がっていないか。
個別機能の完成度ではなく、業務、データ、システムが一つの構造として持続可能かを見る「構造監査」の視点です。
Vol.22では、監理者を置いても、その指摘が機能しない組織の力学を取り上げました。
一度承認された計画書が、「更新されるべき仮説」ではなく「守るべき既成事実」へ変わる。
問題を指摘すれば、計画を乱す人と見られる。
黙って予定通り進めれば、少なくともその場では責任を問われない。
悪意のない人々が、それぞれの立場で合理的に行動した結果、組織全体として失敗を選んでしまう構造です。
Vol.23では、そのような組織の中で、DX推進責任者や現場側の変革リーダーが、どうすれば経営判断を引き出せるのかを考えました。
正論で相手を追い込むのではなく、今と将来の修正コストの違いを示す。
問題が顕在化する場面を具体化する。
そして、判断しない場合に何を引き受けることになるのかを共有する。
「あなたが間違っている」ではなく、「私たちは同じ現実に直面している」と伝えるための言語設計です。
Vol.24では、なぜ監理機能が最初から体制に組み込まれないのかを掘り下げました。
PMには、進捗、課題、スコープ、納期を管理し、プロジェクトを前へ進める役割があります。
しかし、経営層やプロジェクトメンバーは、PMに対して、業務、データ、システム、現場運用を横断し、構造上の問題まで引き取って判断してくれることを暗黙に期待している場合があります。
PMが「総責任者」と呼ばれることで、実際には存在しない監理機能まで、体制の中に備わっているような錯覚が生まれるのです。
誰も手を抜いていないのに、失敗を選んでしまう
この6号で指していたのは、実は全て同じ構造です。
日本企業のDXプロジェクトは、誰も手を抜いていないのに、合理的な判断の積み重ねによって、失敗を選びやすい構造を抱えています。
PMが無能だからではありません。 DX推進責任者の勇気が足りないからでもありません。 ベンダーが不誠実だからでもありません。
PMは、納期とスコープを守ろうとする。 ベンダーは、契約上の責任を果たそうとする。 現場は、日々の業務を止めないようにする。 推進責任者は、社内の合意を壊さないようにする。 経営層は、承認した計画を予定通り完遂しようとする。
それぞれの行動には、それぞれの合理性があります。
しかし、その合理性の間に落ちた構造的な課題を、誰も引き取らない。
それが、DXプロジェクトで繰り返されている問題の正体です。
誰も手を抜いていないのに、失敗を選んでしまう
この6号で指していたのは、実は全て同じ構造です。
日本企業のDXプロジェクトは、
誰も手を抜いていないのに、
合理的な判断の積み重ねによって、
失敗を選びやすい構造を抱えています。
PMが無能だからではありません。
DX推進責任者の勇気が足りないからでもありません。
ベンダーが不誠実だからでもありません。
PMは、納期とスコープを守ろうとする。
ベンダーは、契約上の責任を果たそうとする。
現場は、日々の業務を止めないようにする。
推進責任者は、社内の合意を壊さないようにする。
経営層は、承認した計画を予定通り完遂しようとする。
それぞれの行動には、それぞれの合理性があります。
しかし、その合理性の間に落ちた構造的な課題を、誰も引き取らない。
それが、DXプロジェクトで繰り返されている問題の正体です。
正しい体制は、必要条件に過ぎない
では、監理者を置けば、プロジェクトは救われるのでしょうか。
PMの役割と責任範囲を明確にする。監理者の席を体制図に設ける。
構造上の問題を経営層へ直接報告できる経路を作る。
計画書を、必要に応じて更新される仮説として扱う。
これらは、すべて必要です。
しかし、必要条件であって、十分条件ではありません。
私がこれまで見てきた中には、体制図や役割分担が一見整っていても、プロジェクトが迷走するケースがありました。
そこでは、「誰が何を見るか」は定義されていました。
しかし、
「何が見えたときに、どう判断するのか」
が決まっていませんでした。
構造上の歪みが発見されても、それを許容して進むのか。
一度止めて修正するのか。
当初計画とは異なる方向へ切り替えるのか。
見る人がいても、判断基準と判断権限がなければ、問題は可視化されるだけです。
会議で共有される。
課題管理表に登録される。
誰かが「重要」と発言する。
しかし、次の一手は決まらない。
体制は、「誰が何を見るか」を決めます。
しかし、何が見えたときに、進むのか、止まるのか、方向を変えるのかまでは決めてくれません。
判断のコストを、誰が負うのか
日本の組織で意思決定が先送りされる背景には、しばしば共通した構造があります。
判断によって生じるコストを、誰か一人が負わなければならない。
プロジェクトを止めれば、納期が遅れる。
追加費用が発生する。
社内説明が必要になる。
取締役会や経営会議で、当初計画との違いを説明しなければならない。
そして、「止める」と言った人が、その責任を負うことになります。
方向転換を提案すれば、
「当初計画を壊した人」
「話を複雑にした人」
「追加コストを発生させた人」
として記憶されるかもしれません。
その一方で、「予定通り進める」という判断は、既存の計画に従っただけなので、少なくともその時点では個人の責任になりにくい。
だから、問題が見えていても、
「もう少し様子を見よう」
「次のフェーズで確認しよう」
「運用でカバーできるか検討しよう」
という言葉が繰り返されます。
Vol.22で述べた「合理的に失敗を選ぶ構造」は、体制を変えただけでは消えません。
判断のコストを個人に背負わせる構造が残っている限り、監理者が問題を発見しても、組織は動かないからです。
必要なのは、勇敢な一人を探すことではありません。
誰が、何を基準に判断し、その判断によって生じる結果を組織としてどう引き受けるのかを、あらかじめ決めておくことです。
次に問われる、三つの意思決定
体制論が問うてきたのは、
「誰が、何を見るのか」
でした。
次に問わなければならないのは、
「何が見えたときに、どう判断するのか」
です。
今後のシリーズPart4では、DXプロジェクトの成否を分ける意思決定を、三つの視点から考えていきます。
一つ目：進めるか、止めるか、方向を変えるか
プロジェクトの選択肢は、GoとStopだけではありません。
現状の計画で続ける。一度止めて修正する。スコープや方式を変えて、別の方向へ進む。
つまり、Go・Stop・Redirect
の三つです。
誰がこの判断を下せるのか。
どのような条件がそろったときに、判断を行うのか。
そして、止めることや方向を変えることを、失敗ではなく適切な経営判断として扱えるか。
これが一つ目の論点です。
二つ目：何を守り、何を変えるか
プロジェクトでは、すべてを守ることはできません。
スコープ。
納期。
予算。
品質。
標準化。
現場固有の例外。
将来の拡張性。
どれかを優先すれば、別の何かを手放さなければならない場面があります。
問題は、何を優先するかが決まっていないまま、すべてを守ろうとすることです。
その結果、表面上は納期も予算も守られながら、現場運用や将来の持続可能性が犠牲になることがあります。
何を絶対条件として守るのか。
何は変更可能なのか。
何を諦める覚悟を持つのか。
これが二つ目の意思決定です。
三つ目：何を満たせばGo-Liveできるのか
多くのプロジェクトでは、作業が終わったことが、稼働開始の理由になります。
要件定義が終わった。
開発が終わった。
テストが終わった。
予定日が来た。
しかし、「工程が終わったこと」と「稼働できる状態になったこと」は同じではありません。
現場が運用できるか。
重要なデータが正しく循環するか。
重大な例外処理に対応できるか。
導入後のサポート体制が整っているか。
どの条件を満たさなければ、Go-Liveを認めないのか。
その基準がプロジェクト開始時に決まっていなければ、リリース直前になってから、納期を守るために条件が緩められていきます。
Go-Liveは、スケジュール上のイベントではありません。
経営による意思決定です。
体制の次は、判断である
Vol.19からVol.24まで、私たちは体制を見てきました。
管理と監理を分ける。
監理者を適切な位置に置く。
構造品質を見る。
正しい指摘が届く環境を作る。
経営判断を引き出す言葉を設計する。
PMへの過剰な期待で、監理機能の空白を隠さない。
これらは、DXプロジェクトを健全に進めるための土台です。
しかし、土台があるだけでは、プロジェクトは正しい方向へ進みません。
その上で、
進むのか。
止まるのか。
方向を変えるのか。
何を守り、何を変えるのか。
何を満たせば、稼働を認めるのか。
を決めなければなりません。
正しい体制は、必要条件に過ぎない。体制の次に問われるのは、判断です。
次号からは、DXプロジェクトの成否を分ける意思決定を、一つずつ解剖していきます。
YMG Advisoryでは、プロジェクトの体制や進捗を確認するだけでなく、重要な意思決定に必要な論点が整理されているかを、第三者の視点から診断しています。
「問題は見えているが、誰も判断できない」
「会議では共有されるが、次の一手が決まらない」
「このまま進めてよいのか、止めるべきなのか判断できない」
そのような状況にある方は、ymg-info@ymg-advisory.comまでご連絡ください。
次回Vol.26では、
「進める・止める・方向を変える」
という三つの選択肢を、誰が、何を基準に判断するのかを考えます。