基幹システムの刷新プロジェクトが、ベンダー任せのまま炎上していく——多くの現場で繰り返されるパターンです。要件定義の段階では順調に見えても、テストフェーズで「これは業務と合わない」という指摘が噴出し、追加見積もりとスケジュール延長が連鎖していきます。最終的には、当初予算の 1.5〜2 倍に膨らんだ状態で稼働日を迎えるケースが珍しくありません。
一方で、社内 PMO が主導権を握り、外注は実装パートナーとして使い分けながら、予算とスケジュール内で完遂する組織もあります。両者の差は技術力ではなく、プロジェクト開始前に何を決めていたかにあると整理できそうです。本記事では、社内主導で大規模基幹刷新を完遂するために必要な 5 つの前提条件を、現場で見てきた具体例とともに解説します。
本記事の結論：成否は社内体制の設計で 8 割決まる
社内主導で基幹刷新を完遂する組織には、共通する 5 つの前提条件があります。(1) 経営層が「やり切る」と決めている、(2) 業務を語れる社内 PMO が常駐している、(3) 外注先を機能単位で分割して発注している、(4) 意思決定のリズムが週次で固定されている、(5) スコープを動かす権限が PMO に集約されている——この 5 点です。
逆に言えば、これらが揃わない状態でベンダーに丸投げすると、要件定義の解釈ズレが累積して必ず炎上します。技術選定やパッケージ選びは後段の論点であり、まず組織側の体制を固めるところから始めるべきだと考えています。基幹刷新は組織能力のテストでもあり、外注先の能力テストではありません。
基幹刷新の成否は、ベンダー選定ではなく社内体制の設計で 8 割が決まる。
前提条件 1：経営層が「やり切る」と意思決定している
基幹刷新は 2〜3 年に及ぶ長期プロジェクトです。途中で経営層の関心が薄れると、現場は驚くほど早く漂流を始めます。キックオフ時点で「やり切る」「途中で止めない」「予算超過しても完遂させる」という意思を経営層が明示しているかが、最初の分岐点になります。
過去に見た失敗事例の中で印象的だったのは、刷新開始 1 年後にトップが交代した某流通業のケースでした。新トップが「投資対効果が見えない」として一旦凍結を指示した結果、ベンダー側のキーメンバーが離散し、半年後に再開した時には要件定義のコンテキストが失われていた。結局、追加コストを払って要件定義からやり直すことになりました。
ここでの教訓は単純で、中途半端な状態での撤退は、続行よりも高くつくということです。基幹刷新は止まっている間も保守コストとレガシー負債が積み上がっていきます。経営層が示すべきは、技術判断ではなく「完遂する意思」そのものです。
実務的には、キックオフ時に経営会議で以下の 3 点を文書化することをおすすめしています。
- 完遂期限と、その期限が動かない理由
- 予算超過時の追加投資上限（10〜20% を目安に明文化）
- プロジェクト責任者の人事固定（最低 2 年間異動させない）
この 3 点を経営層が握っていないプロジェクトは、現場がどれだけ優秀でも構造的に漂流します。
前提条件 2：業務を語れる社内 PMO が常駐している
外部のコンサルタントや PM を雇っても、業務の機微までは把握できません。受発注の例外処理、月次締めの裏ワザ、現場で口伝されているルールの数々——これらは社内で長く業務に関わってきた人間でなければ語れない領域です。
社内で 10 年以上業務に関わってきた中堅人材を PMO 専任にアサインし、要件定義から運用開始まで一貫して伴走させる体制が必要になります。ここで頻発する失敗が、兼務 PMO による形骸化です。「本業の傍らで PMO もやってもらう」という発令の仕方をすると、本業の繁忙期と要件定義の山場が重なった瞬間に PMO 機能が停止します。
専任化にはコストがかかります。中堅課長クラスを 2〜3 年抜くわけですから、人件費換算で 1 名あたり年間 1,500 万〜2,000 万円相当の機会費用が発生する計算です。ただし、このコストを惜しんで兼務にした結果、要件定義の解釈ズレで 1〜2 億円の追加開発が発生するケースを考えれば、専任化は明らかに合理的な投資です。
体制 | 業務理解 | 意思決定速度 | 結果として発生する追加コスト |
|---|---|---|---|
ベンダー丸投げ | 浅い | 遅い | 当初予算の 50〜100% |
外部コンサル主導 | 中程度 | 中程度 | 当初予算の 20〜40% |
社内専任 PMO 主導 | 深い | 速い | 当初予算の 5〜15% |
PMO に求められるのは、業務を語れることに加えて、ベンダーの見積もりを技術観点で検証できる素養です。情報システム部の管理職と、業務部門の中堅課長を 1〜2 名ずつ組み合わせるのが現実解だと整理しています。
前提条件 3：外注先を機能単位で分割発注する
一社のベンダーに全てを任せると、見積もりがブラックボックス化し、追加開発時の交渉力を失います。「この機能の追加には 3 ヶ月かかります」と言われた時、それが妥当な工数かを検証する手立てが社内に残らないのです。
対策はシンプルで、基盤・業務ロジック・フロント・データ移行など、機能単位で発注先を分割することです。社内 PMO が統合責任を持つ構造にすることで、各ベンダーの見積もりに相場感が働き、追加交渉時にも比較材料が揃います。
もちろん、マルチベンダー管理には負荷が伴います。インターフェース仕様の調整、責任分界点の定義、障害時の切り分け——これらは全て社内 PMO の仕事になります。ただし、この負荷を引き受けることで得られる統制メリットは負荷を上回ります。
具体的には、以下の 3 軸で分割するのが扱いやすいと感じています。
- 基盤・インフラ層（クラウド構築、ネットワーク、セキュリティ）
- 業務ロジック・アプリケーション層（パッケージカスタマイズ or スクラッチ）
- データ移行・周辺連携（既存システムからの移行、外部システム連携）
3 領域に分けると、それぞれの専門性を持つベンダーを選定でき、見積もりの妥当性も領域横断で検証しやすくなります。なお、PMO に発注管理の経験が薄い場合は、調達フェーズだけ外部の支援を入れる選択も現実的です。
前提条件 4：意思決定のリズムを週次で固定する
基幹刷新では、日々数十件の意思決定が発生します。「この項目はマスタに含めるか」「この画面遷移はどうするか」「移行データの欠損をどう扱うか」——これらを 月次会議で捌くと遅すぎ、随時判断にすると現場が止まります。
実務的に機能するのは、週次の定例で論点を捌くリズムです。曜日と時間を固定し、PMO・業務部門代表・主要ベンダーが集まる場を 2 時間確保する。論点は前日までに事前共有し、定例の場では決裁のみ行う運用にすると、1 回あたり 15〜30 件の意思決定が処理できます。
ここで重要なのが、決裁ルートの単純化です。週次定例で決めきれる範囲を最大化するため、PMO に大幅な権限委譲を行う必要があります。経営会議に上げる事項を「金額 X 円以上の追加投資」「全社業務プロセスの変更を伴う事項」など、明確な閾値で限定するのが定石です。
決裁ルートが複雑なまま走り出すと、週次定例が「持ち帰り検討」の山になり、現場が判断待ちで止まります。スピードの源泉は人数ではなく、権限の委譲幅にあります。
前提条件 5：スコープ変更権限を PMO に集約する
プロジェクト中盤になると、必ず「これも入れたい」「あれも変えたい」という追加要望が噴出します。要件定義時には見えなかった業務上の論点が、画面プロトタイプを見て初めて顕在化するためです。
この要望を捌く権限を PMO に集約することが、スコープ膨張を防ぐ最後の砦になります。経営層に上げると判断が遅れ、現場部門に任せるとスコープが青天井で膨張する。間に立つ PMO が一次判断を行い、影響度に応じてエスカレーションする構造が安定します。
実装の型として参考になるのは、以下のような 3 段階のスコープ変更フローです。
- 軽微な変更（追加工数 5 人日以内）：PMO 判断で即時承認
- 中規模変更（追加工数 5〜30 人日）：PMO 主催の臨時審査会で承認
- 大規模変更（追加工数 30 人日超 or 月額影響 100 万円超）：経営会議に上申
このルールを キックオフ時点で全関係者に周知し、文書化しておくことが肝心です。プロジェクト中盤で運用ルールを後付けすると、必ず例外申請が殺到して機能不全に陥ります。
スコープ凍結のタイミングも事前合意が必要です。設計完了時点で機能スコープを凍結し、それ以降の追加は次期フェーズに送る——というルールを最初に握っておけば、現場の要望を理性的に整理できます。
製造業 B 社、4.2 億円規模の刷新を 10% 以内の超過で完遂した実例
ある中堅製造業 B 社（従業員 800 名規模）では、20 年稼働した基幹システムの刷新に踏み切りました。当初はベンダー一社への一括発注を検討していましたが、過去に同規模の刷新で 1.8 倍の予算超過を経験していたため、方針を切り替えています。
具体的には、業務部門から中堅課長クラス 3 名を PMO 専任にアサインし、情報システム部の部長を含めた 4 名体制で常駐させました。外注は基盤構築・業務ロジック実装・データ移行の 3 領域に分割し、それぞれ別のベンダーに発注。統合責任は社内 PMO が持つ構造にしています。
意思決定は毎週水曜の 2 時間定例で全論点を捌き、スコープ変更は PMO が一次判断、月 100 万円超の影響が出る変更のみ経営会議に上げるルールとしました。結果、当初予算 4.2 億円・期間 24 ヶ月の計画に対して、予算 4.4 億円・期間 26 ヶ月で稼働を迎えています。10% 以内の超過は、この規模のプロジェクトでは成功と評価できる水準です。
稼働後の評価で印象的だったのは、業務部門からの不満が極めて少なかった点です。要件定義の段階で社内 PMO が業務側と握っていたため、「思っていたものと違う」というギャップがほぼ発生しませんでした。ベンダーの優秀さではなく、社内 PMO が業務翻訳の役割を果たし続けたことが、この結果の本質だったと整理しています。
基幹刷新の体制設計から伴走するご相談
社内主導で基幹刷新を進めたい組織に対して、私たちは PMO 体制設計、外注先の分割発注、意思決定リズムの構築まで一貫して伴走しています。コンサルとしての戦略立案だけで終わらず、設計や実装にも降りていけることが、私たちが選ばれている理由のひとつだと感じています。
「ベンダー選定の前段で何を決めるべきか」「PMO に誰を据えるべきか」「分割発注の境界線をどう引くか」——こうした具体的な体制設計の論点があれば、議論から始められればと考えています。
関連記事：
