プロジェクトガバナンスの本質：なぜCXOはITプロジェクトに関与しないのか
itpjstudy
大規模ITプロジェクトでは「CXOの巻き込みが重要」と言われますが、実態としてはCIOレベルで意思決定が止まり、経営層は限定的にしか関与しないケースが多く見られます。
その結果、プロジェクトはIT部門最適で進み、経営インパクトと接続しないまま完了してしまうことが少なくありません。 本質的な問題はCXOの関心ではなく、CXOが関与できるように設計されたガバナンス構造が存在しないことにあります。
CXOが関与しない構造と、IT主導に陥る理由
ITプロジェクトがIT主導になるのは偶然ではなく、組織設計と意思決定構造に起因する必然的な結果です。
CIO中心の意思決定構造が固定化される背景
多くの企業では、IT投資はCIO組織が起案し、そのままIT部門内で要件定義からベンダー選定までが進みます。この構造では、課題定義そのものがIT部門の視点で行われるため、プロジェクトの前提条件がすでにIT最適化されています。
結果として、以下のような状態が自然に発生します。
- IT部門が課題の定義者になる
- ベンダー選定の軸もIT部門が決める
- 経営層は最終承認のみ関与する
この構造では、プロジェクトがスタートした時点ですでに「経営課題」ではなく「IT課題」として固定されてしまいます。
RFPと評価基準がIT最適に閉じる問題
RFPの設計は、プロジェクトの性質を決定づける非常に重要な要素です。しかし実務では、技術要件やコスト条件が中心となり、経営的な観点が十分に織り込まれないケースが多く見られます。
典型的な評価構造は以下です。
| 評価項目 | 実務での比重 |
| 技術要件適合性 | 高 |
| コスト | 高 |
| 実績 | 中 |
| 経営インパクト | 低 or 未定義 |
この時点で、プロジェクトは「最も優れたIT構成」を選ぶ場になっており、「最も経営効果が高い選択肢」を選ぶ場ではなくなっています。
「ITはIT部門に任せる」という暗黙の前提
多くの組織には明文化されていない前提として「ITはIT部門の領域である」という認識があります。この前提は非常に強力で、経営層が関与する余地を構造的に狭めます。
この結果、CXOは意思決定者ではなく「最終承認者」として扱われ、議論の主体から外れていきます。これは意図的な排除ではなく、役割設計の問題です。
CXO不在が“正常状態”として定着する構造
最も問題なのは、CXOが関与しない状態が例外ではなく「標準プロセス」として定着していることです。
この状態が続くと次のような現象が起きます。
- CXO巻き込みが“追加作業”として扱われる
- ステアリングが形式的な報告会になる
- 意思決定がCIOレイヤーで完結する
結果として、CXO不在は問題として認識されなくなり、むしろ「効率的な進め方」として正当化されてしまいます。
CXOを動かせない理由と、巻き込み失敗の構造
CXOが関与しない理由は「関心がないから」ではなく、「関与できる設計になっていないから」です。
CXOはITではなく経営インパクトで判断する
CXOの意思決定軸は常に経営インパクトです。ITそのものの優劣ではなく、以下の観点で判断されます。
- 売上への影響
- コスト構造の変化
- リスク低減効果
- 競争優位性への寄与
そのため、ITテーマのまま提示されると判断材料が不足し、「CIOに任せる」という結論に戻ってしまいます。
ステアリングコミッティが報告会になる理由
多くのステアリングコミッティは、本来の意思決定機能を持っていません。議題は進捗報告が中心となり、意思決定事項が明確に定義されていないためです。 この状態ではCXOは意思決定者ではなく、状況を「聞く人」になります。結果としてガバナンスは形骸化し、プロジェクトの推進力も弱まります。
IT論点のままCXOに投げてしまう問題
CXOに提示される論点がITのままである場合、そもそも判断が成立しません。
例えば以下のような論点です。
- アーキテクチャ選定
- ベンダー比較
- 技術方式の違い
これらは専門領域の意思決定であり、経営判断ではありません。そのためCXOは意思決定から距離を置くことになります。
巻き込みは努力ではなく設計である
CXO巻き込みは「説明を丁寧にすること」では実現しません。本質は構造設計です。
重要なのは以下です。
- 何を決める場なのかを明確にする
- どの選択肢が提示されているかを設計する
- CXOが意思決定せざるを得ない状態を作る
巻き込みとは関係構築ではなく、意思決定設計です。
CXOを動かすガバナンス設計とKPI接続の本質
IT課題を経営課題に再定義する
ITプロジェクトを成功させるためには、課題そのものを経営言語に翻訳する必要があります。
例えば：
- システム刷新 → キャッシュ効率改善
- データ統合 → 意思決定スピード向上
このように再定義することで、CXOの関心領域と接続されます。
CXOごとに異なる意思決定軸を設計する
CXOはそれぞれ異なる視点で意思決定を行います。
- CFO：投資対効果・財務インパクト
- COO：業務効率・オペレーション改善
- CEO：成長戦略・競争優位性
この違いを無視すると、どのCXOも「自分ごと」として認識しません。
ステアリングを意思決定の場に変える
ガバナンスの本質は会議体設計にあります。
- NG：進捗報告の場
- OK：意思決定の場
この違いにより、CXOの関与レベルは大きく変わります。
プロジェクト目標と経営KPIの接続
プロジェクト目標は単体では意味を持ちません。必ず経営KPIと接続される必要があります。
錦の御旗としてのプロジェクト目標
構想フェーズで設定されるプロジェクト目標は「錦の御旗」です。この目標が明確であれば、組織全体の意思決定が揃いやすくなります。 関連して以下の記事でも詳しく解説しています。
錦の御旗が明確なプロジェクトでは、IT導入ではなく組織変革としてプロジェクトが進行します。
CXO巻き込みはスキルであり、外部依存領域である
CXO巻き込みは「やる気」や「根回し」で実現できるものではありません。実務的には、かなり高度なスキルセットが必要であり、属人的な能力に依存する領域です。そのため、組織内に自然に存在することを前提にするのは現実的ではありません。
CXOを動かすには高度なスキルが必要
CXOは日々、経営判断・投資判断・組織マネジメントなど、極めて抽象度の高い意思決定を行っています。そのため、通常のIT説明や業務説明では意思決定が発生しません。
CXOを動かすためには、少なくとも以下のスキルが必要になります。
- 経営課題への翻訳力（ITを経営言語に変換する力）
- 意思決定構造の設計力（何を決める場なのかを定義する力）
- ステークホルダー間の力学理解（組織政治を含む調整力）
- トレードオフ提示力（選択肢とリスクを明確にする力）
重要なのは「説明が上手いこと」ではなく、「意思決定が発生する構造を作れること」です。
内部にそのスキルがない場合に起きる問題
このスキルが組織内に十分存在しない場合、プロジェクトは次のような状態に陥ります。
- ステアリングコミッティが報告会化する
- CXOが“聞くだけの存在”になる
- 意思決定がCIOレイヤーに戻る
- プロジェクトがIT部門内最適で進む
結果として、「CXO巻き込みをしているつもり」であっても、実態は関与していない状態が継続します。
外部人材は“意思決定設計者”として必要になる
このギャップを埋める手段として、外部ITパートナの活用は非常に有効です。ただし、その役割は単なる実装支援ではありません。
外部に求められるのは以下のような役割です。
- CXO向けの論点設計
- 経営アジェンダへの再定義
- 意思決定プロセスの設計
- ステアリングのファシリテーション
つまり外部人材は「作る人」ではなく、「決めさせる構造を設計する人」です。
CXOのスイッチを入れられるITパートナとは何か
CXOを動かすためには、単に優秀なSIerやコンサルを選べばよいわけではありません。重要なのは「CXOの関心スイッチを入れられるかどうか」です。 これは個人スキルに依存する部分が大きく、会社のブランドや規模とは必ずしも一致しません。
CXOの関心をITから経営課題へ変換できる力
優れたITパートナは、ITテーマをそのまま説明しません。必ず経営課題に翻訳します。
例えば：
- 「システム刷新」ではなく「キャッシュフロー改善」
- 「データ統合」ではなく「意思決定スピード向上」
- 「業務標準化」ではなく「人件費構造の最適化」
この“翻訳力”がない限り、CXOは自分ごととして認識しません。
CXOごとに異なるストーリー設計能力
CXOは同じ内容でも、見る観点が異なります。
- CFO：投資対効果・回収期間・キャッシュインパクト
- COO：業務効率・現場負荷・オペレーション安定性
- CEO：競争戦略・市場ポジション・成長性
そのため優れたパートナは、同じプロジェクトでもCXO別に異なるストーリーを設計します。
「一つの説明で全員を納得させる」は失敗パターンです。
意思決定を起こす能力（最も重要な能力）
CXO巻き込みで最も重要なのは、「理解させること」ではなく「決めさせること」です。
そのためには以下が必要です。
- 選択肢を必ず複数提示する
- それぞれのトレードオフを明確にする
- 意思決定しない場合のリスクを提示する
CXOが「判断せざるを得ない状態」を設計できるかどうかが本質です。
ステアリングを意思決定の場に変える力
多くのステアリングは報告会ですが、優れたパートナはこれを意思決定会議に変えます。
具体的には以下の違いがあります。
| 項目 | 失敗する会議 | 成功する会議 |
| 目的 | 進捗共有 | 意思決定 |
| 議題 | 状況報告 | 選択肢比較 |
| CXOの役割 | 聞き手 | 意思決定者 |
この変換ができるかどうかで、CXOの関与レベルは大きく変わります。
CXO駆動力でパートナを選ぶべき理由
今後のITパートナ選定では、従来の基準は不十分になります。
従来：
- 技術力
- コスト
- 実績
これから：
- CXOを動かせるか
- 経営アジェンダに変換できるか
- 意思決定構造を設計できるか
「システム実装力」ではなく「CXO駆動力」が評価軸になります。
プロジェクト成功はガバナンスとCXO設計力で決まる
ITプロジェクトの成功は、技術力そのものではなく「意思決定構造の設計力」に依存します。
CXO巻き込みは設計でありスキルである
CXO巻き込みは自然発生するものではなく、明確に設計された構造の中でのみ機能します。
- 誰がCXOと話すのか
- 何を決めるのか
- どのタイミングで意思決定するのか
これらが設計されて初めてCXOは動きます。
外部と内部の役割分担が成功条件になる
成功するプロジェクトでは役割が明確に分かれています。
- 内部：関係性・最終意思決定の責任
- 外部：論点設計・構造設計・意思決定支援
どちらか一方では成立しません。
成功するプロジェクトの条件
最終的に成功するプロジェクトには共通点があります。
- CXOが最初から意思決定者として設計されている
- KPIが経営と直接接続されている
- ステアリングが意思決定の場として機能している
- ITパートナがCXO駆動力を持っている
プロジェクト成功は「実行力」ではなく「ガバナンス設計力」で決まります。
世の中の多くのプロジェクトが、IT主導だと思います。しかし、IT主導では、経営に大きなインパクトを与えるようなプロジェクトはできません。CXOの巻き込みは、本来的にはユーザ企業側が自ら行わなくてはなりませんが、なかなか出来ていない企業が多いように見受けます。CXO巻き込みも、ひとつのスキルだと考えて、外部調達するなどして、強化することが欠かせません。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
