「予定通りリリースしました」── その後、何が起きたか
プロジェクト完了の報告書には、こう書かれていた。「計画通りのスケジュールでGo Liveを達成」「予算は当初計画の102%で着地」「要件定義書に記載された機能はすべて実装済み」。PMOは安堵し、経営層は報告を受理し、プロジェクトチームは解散した。
3か月後。現場からこんな声が聞こえてくる。「新しいシステム、使いにくいんだけど」「結局Excelに戻してる」「前のやり方の方が早い」。導入前より業務効率が落ちている部署がある。データの二重入力が発生している。カスタマーサポートの応答時間が伸びている。
しかし、プロジェクトの報告書上は「成功」だ。QCD（品質・コスト・納期）の3指標はすべて達成している。プロジェクトチームはすでに解散しており、この「3か月後の現実」を拾い上げる仕組みは、どこにもない。
Standish GroupのCHAOS Reportは、ITプロジェクトの成功率を約29%と報告している (Standish Group, 2015)。この数字でさえ、「QCDを達成したか」という狭い定義での成功率だ。「導入したシステムが、組織に価値をもたらしているか」まで含めて評価すれば、成功率はさらに下がるだろう。
なぜGo Liveがゴールになるのか
プロジェクトの「終わり」が構造的に決まっている
プロジェクトとは、定義上「有期性」を持つ活動だ。始まりがあり、終わりがある。PMBOKに基づくプロジェクトマネジメントは、この有期の活動を計画通りに遂行するための知識体系として極めて優れている。しかしその構造ゆえに、「プロジェクトの終わり」と「成果の実現」が同義であるかのように扱われる傾向がある。
Go Live日は、プロジェクトの「終わり」を象徴する日だ。ベンダー契約はGo Liveを基準にマイルストーンが設計される。予算はGo Liveまでの期間で承認される。プロジェクトチームのアサインもGo Liveまでだ。あらゆるリソースと関心が、Go Liveに向かって収束する構造になっている。
そしてGo Liveの翌日から、プロジェクトは「運用」に移管される。しかし、運用チームに引き渡されるのはシステムの操作手順であり、「組織がこの変化をどう受け入れ、定着させるか」の設計ではない。
「成功の定義」が狭すぎる
従来のプロジェクト成功の定義は、QCD ── 品質・コスト・納期 ── の3指標だった。この3つを達成すれば「成功」。しかし、QCDはあくまでプロジェクトの実行品質を測る指標であり、成果の実現を測る指標ではない。
興味深いのは、PMI（プロジェクトマネジメント協会）自身がこの定義の限界を認識し始めていることだ。PMIは2024年に、プロジェクト成功の新たな定義として「労力と費用に見合う価値をもたらしたかどうか」を提唱した (PMI, 2024)。2025年に刊行されたPMBOK第8版でも、バリュードリブン（価値主導）のマインドセットが3つの柱の一つとして強調されている。プロジェクトマネジメントの世界標準自身が、「QCD達成＝成功」ではないと言い始めているのだ。
Go Liveは「完了」であって「成功」ではない。成功とは、導入した変化が組織に価値をもたらし、定着している状態を指す。
Go Liveの先にある「Jカーブの谷」
プロジェクトマネジメントの視界は、Go Liveで終わる。しかし、組織の変革はGo Liveから始まる。
新しいシステムが稼働した瞬間、現場には混乱が生じる。慣れ親しんだやり方が使えなくなり、新しいインターフェースに戸惑い、以前は5分で終わっていた作業に20分かかる。業務のパフォーマンスは一時的に下がる。これが変革のJカーブの「谷」だ。
この谷の存在は、チェンジマネジメントの世界では常識だ。しかし、プロジェクト計画にこの谷が織り込まれていることは、ほとんどない。Go Liveまでの計画は精緻に設計されているのに、Go Live後に現場が経験する混乱と、そこからの回復プロセスは、計画の外側に置かれている。
Prosci の調査は、効果的なチェンジマネジメントを行ったプロジェクトは目標達成率が7倍高いことを示している (Prosci, 2023)。この「目標達成」には、Go Live後の定着まで含まれている。つまり、Go Live後の定着を計画に含めないプロジェクトは、成功の確率を構造的に7分の1に下げているということだ。
問題は、谷の存在そのものではない。変革には谷がつきものだ。問題は、谷を越えるための支援が、プロジェクトの計画にもリソースにも含まれていないことだ。プロジェクトチームは解散し、ベンダーは撤退し、現場は谷の中で孤立する。
緑の曲線は、Go Live後もチェンジマネジメントの支援が継続し、谷を越えて定着・成長に至るプロジェクト。赤の破線は、Go Liveでチームが解散し、谷に取り残されたまま回復しないプロジェクト。多くの組織が経験しているのは、後者だ。
「定着フェーズ」をプロジェクトに組み込む
では、どうすればいいのか。答えは概念的にはシンプルだ。Go Liveを「プロジェクトの中間地点」として再定義し、その先の定着フェーズをプロジェクトの正式なスコープに含める。
計画段階で「成功の定義」を書き換える
プロジェクトの企画段階で、成功の定義をQCDだけでなく「組織への価値の実現」まで拡張する。具体的には、以下の問いに答える形で成功基準を設計する。
「このプロジェクトが成功したとき、Go Liveの6か月後に現場はどうなっているか」。システムの利用率は何%か。業務効率はどう変化しているか。ユーザーの満足度はどの水準か。これらの遅行指標を定義し、プロジェクトの成功基準に含める。
QCDは引き続き管理する。ただし、それは「成功の必要条件」であって「十分条件」ではないという位置づけに格下げする。
リソースをGo Liveの先まで確保する
定着フェーズに必要なリソースを、プロジェクトの予算と体制に最初から組み込む。Go Liveまでの予算の100%がプロジェクト全体の予算ではない。Go Liveからの3〜6か月間 ── 現場が谷を越えるまでの期間 ── に必要な支援体制、トレーニング、フィードバック収集、改善対応のリソースを、計画段階で確保する。
「Go Live後のことは運用予算で」という考え方が一般的だが、これは変革の最も危険な時期を、最も手薄な体制で乗り切れと言っているに等しい。谷の中にいる現場を支えるのは、プロジェクトの責任だ。
Quick Winを「谷の中の道標」にする
Go Live後、すべてが一度に完璧に動く必要はない。むしろ、最初に効果が実感できる小さな成功（Quick Win）を意図的に設計することが重要だ。
たとえば、全社展開の前に一部門で先行導入し、「確かに楽になった」という実感を作る。その成功事例を社内で共有し、次の部門の展開への推進力にする。Kotterが変革の成功要因として短期的な成果の創出を重視したのも (Kotter, 1996)、谷の中にいる組織に「このまま進めば光が見える」という道標を示すためだ。
Quick Winは偶然には生まれない。プロジェクト計画の段階で、「Go Live後の最初の1か月で、どの業務でどんな成果を見せるか」を設計しておく必要がある。
PMが果たすべき役割、CMが補完すべき役割
ここで重要なのは、従来のプロジェクトマネジメント（PM）が不要だと言っているのではないということだ。QCDを管理し、Go Liveまでを計画通りに遂行するPMの力は、引き続き不可欠だ。
問題は、PMだけでは足りないということだ。既に投稿済みのInsight「PMBOKだけでは届かない理由」でも論じた通り、PMは「計画を遂行する力」であり、CMは「人を動かす力」だ。Go Liveまではプロジェクトの計画力が主役だが、Go Liveの後は人の行動変容が主題になる。
定着フェーズで必要なのは、コミュニケーション計画の実行（なぜこの変化が必要なのかを繰り返し伝える）、チェンジエージェントの配置（現場に寄り添い、困りごとを拾い上げる推進者）、フィードバックループの構築（現場の声を集め、素早く改善に反映する仕組み）だ。これらはPMのスコープには通常含まれないが、変革の成否を決定的に左右する活動だ。
PMとCMを統合的に設計し、Go Liveの前も後もシームレスに管理する。プロジェクトの「完了」を報告するのではなく、変革の「定着」を報告する。 この発想の転換が、「成功率29%」の構造を変える第一歩になる。
明日から始められること
大規模なプロジェクト設計の見直しは一朝一夕にはできない。しかし、次のプロジェクトから取り入れられることはある。
第一に、プロジェクト憲章に「Go Live後6か月の成功基準」を一行加える。 QCDの達成基準に加えて、「Go Live後6か月時点でシステム利用率80%以上」のような遅行指標を一つだけ定義する。この一行があるだけで、プロジェクトの関心がGo Liveの先まで伸びる。
第二に、Go Live後3か月のサポート体制を予算に含める。 プロジェクト予算の10〜15%を定着フェーズに確保する。これは追加コストではなく、「使われないシステムを作るリスク」を低減するための投資だ。
第三に、プロジェクト完了報告を「Go Live報告」と「定着報告」の2段階にする。 Go Live時に中間報告、6か月後に最終報告。この仕組みがあるだけで、プロジェクトチームの関心と責任がGo Liveの先まで持続する。
まとめ ── 成功の定義を書き換える
「プロジェクト完了＝成功」は、幻想だ。Go Liveは旅の途中であり、目的地ではない。
PMBOKの世界標準自身が、成功の定義を「QCDの達成」から「価値の実現」へと拡張し始めている。この流れは、現場の実感と一致している。予定通りにリリースしたが使われない。予算内に収まったが価値を生んでいない。これらは「成功した失敗」であり、最も質の悪い失敗だ。なぜなら、報告書上は成功なので、誰も問題を認識しないまま同じことが繰り返される。
テクノロジーだけでは、組織は変わらない。Go Liveは技術の完了であって、変革の完了ではない。成功とは、変化が組織に根づき、人の行動が変わり、価値が持続的に生まれている状態を指す。この定義を、プロジェクトの起点に置くこと。それが、変革のJカーブの谷を越えるための、最も確実な設計になる。