基幹システム刷新のPMO設計｜業務改善・AI活用を同時に進めて炎上させない実践論

1. なぜ基幹システム刷新は炎上するのか

基幹システム刷新が炎上する原因の一つは、プロジェクトの構造にあります。現場の頑張り不足だけが理由ではありません。構造を先に理解しておくと、PMOで何を設計すべきかが見えてきます。「うちのプロジェクトは大丈夫だろうか」。計画段階でそう感じる責任者は少なくありません。DXプロジェクト全般の落とし穴はDXプロジェクト管理で失敗しない進め方でも整理しています。

1-1. 基幹システム刷新は「複合プロジェクト」である

基幹システム刷新とは、中核業務を支える仕組みごと入れ替える取り組みです。本記事では、ERP（Enterprise Resource Planning＝統合基幹業務パッケージ）の導入を伴う基幹刷新を扱います。ERPは会計・販売・購買・在庫・人事といった中核業務を統合管理します。そこへ旧システムからのデータ移行、業務プロセスの改善、生成AIの活用検討が同じ時間軸で並走します。

たとえるなら、走っている電車の車両を入れ替えながら、線路も引き直す作業です。運行ダイヤの見直しも同時に進みます。どれか一つでも段取りを外すと、全体が止まります。

ERP刷新とレガシーマイグレーションは、力点の異なる取り組みです。ERP刷新はパッケージ導入が中心で、標準機能に業務を合わせるフィット・ギャップ分析が欠かせません。老朽化した独自システムを作り替えるレガシーマイグレーションは、アーキテクチャの再構築を含みます。旧システムからERPへ移る案件のように、両者が重なる場合もあります。自社の刷新がどちらの性格を強く持つかは、計画段階で言語化しておきます。

レガシーシステムとは、技術的負債が積み上がって改修・連携・拡張が困難になったシステムです。単に古いシステムという意味ではありません。経済産業省「DXレポート」（2018年9月・経済産業省）は、レガシーの温存が経営リスクになると問題提起しました。ただし2018年時点の問題提起です。刷新の完了はDXの完成ではなく、DX推進の前提条件の一つという位置づけです。

1-2. 炎上の所在はどこにあるのか

炎上の火種は一か所ではありません。本記事では、実務で現れやすい断層を次の四つに整理します。

• スコープが管理されないまま膨らむ
• 部門をまたぐステークホルダーの整合が取れない
• ベンダーとの役割境界が曖昧になる
• 業務改善とシステム設計が別々に進んで分断する

四つは独立した問題に見えて、互いを呼び込む連鎖構造になっています。次の図で、連鎖の流れを示します。

具体的な場面を思い浮かべてみましょう。要件定義の途中で、営業部門が「この画面もほしい」と追加を要望します。情報システム部門はベンダーへ口頭で伝え、ベンダーは言われたとおりに作ります。誰も全体のスケジュールとコストへの影響を確認していません。これがスコープクリープ（変更管理を経ずにスコープが無統制に拡大すること）です。正式な変更管理を通した仕様変更とは区別します。

IPA「システム再構築を成功に導くユーザガイド 第2版」（2018年・情報処理推進機構）も、既存システムの仕様が不明確なまま進むことが失敗の温床になると指摘しています。

部門間の整合不足は、マスタ項目の定義のずれとして表れます。会計部門と販売部門が同じ項目を別の定義で使い、要件会議で初めて食い違いが露呈します。

ベンダーとの役割境界の曖昧さは、責任の押し付け合いとして表れます。ユーザー側の要件確定漏れか、ベンダー側の設計ミスかで揉め、対応が止まります。

業務とシステムの分断は、翻訳役の不在として表れます。To-Beフローをシステム要件へ翻訳する担当が決まらず、ベンダーが旧業務のままシステム化してしまいます。

厄介なのは、四つが連鎖することです。整合不足が要件の追加を呼び、追加がスコープを膨らませます。膨張はテストとデータ移行を圧迫し、稼働を遅らせます。

1-3. PMOとは何か、PMとどう違うのか

PM（プロジェクトマネージャー）は、個々のプロジェクトの目標達成に責任を負う「人」です。対してPMO（Project Management Office）は「組織機能」を指します。標準・方法論・ツール・情報を組織横断で整え、複数のプロジェクトを支援・統制する仕組みです。PMが単一プロジェクトの舵取り役で、PMOはその舵取りを支える仕組みと道具立ての提供者です。上下関係とは限りません。

PMOには、関与の強さで三つの型があります。相談役に徹する支援型（Supportive）、標準への準拠を求める管理型（Controlling）、プロジェクトを直接指揮する指揮型（Directive）です。この分類はPMBOK Guide 第6版（第5版から記載）のもので、原則ベースに移行した第7版の分類ではない点に注意してください。

型の名前より、基幹刷新でどれを選ぶかの理由のほうが実務では効きます。

基幹刷新は複数ベンダー・複数ストリーム・複雑な意思決定構造を同時に抱えます。全社横断の統制を効かせないと足並みが崩れます。一方で、各ストリームの専門判断まで一つのPMOが握れば、現場は止まります。

本記事では、統制の芯として管理型を据え、各ストリームには支援型として伴走する組み合わせを推奨します。

2. 基幹刷新でPMOは何をするのか

基幹刷新でPMOが担うのは、管理支援と推進支援の二つの機能です。役割を二つに分けて定義すると、境界がはっきりします。曖昧なまま体制を組むと、PMOは便利屋になるか、何でも決める過剰な存在になりがちです。皆さまの現場では、PMOの担当範囲がどこまで書かれているでしょうか。

2-1. 管理支援：状況を「比較可能な形」に整える

管理支援とは、進捗・課題・リスクを関係者が同じ定義で読める形に整える機能です。土台になるのが用語の区別です。リスクとは、目標への影響がまだ発生していない不確実性です。リスク登録簿で管理します。課題（issue）はすでに発生した問題で、課題ログで追います。二つを混ぜると、対応の優先度が狂います。発生した問題は課題ログに起票し、元のリスク記録と関連付けます。この運用の型をPMOが用意します。

進捗の可視化も、道具を正しく組み合わせて初めて機能します。WBS（Work Breakdown Structure）は成果物を指向した作業の階層分解で、時間軸を持ちません。時間軸で管理するガントチャート、未発生の不確実性を追うリスク登録簿、変更を統制する変更管理と組み合わせます。そこではじめて全体像が見えます。WBSの体系はPMIの「Practice Standard for Work Breakdown Structures」に整理されています。WBSを作れば管理が完成するわけではありません。

2-2. 推進支援：合意形成と意思決定を「補佐」する

推進支援とは、部門をまたぐ論点を整理し、合意形成を後押しする機能です。意思決定に必要な材料をそろえる役目も含みます。誤解されやすい点を明言します。改善テーマの優先順位や投資判断を下すのは、業務オーナーと経営スポンサーです。PMOではありません。PMOが担うのは、判断の土台となる論点・KPI・進行管理の枠組みの提供です。

たとえば、複数部門から改善要望が上がったとします。PMOは要望を横断して並べます。それぞれの効果とコスト、他ストリームへの影響を比較できる一覧に整えます。そのうえで「この観点で優先順位を議論しましょう」と土俵を用意します。優先順位そのものを決めるのは、あくまで業務オーナーと経営スポンサーです。決める人と支える人を区別することを、本記事ではPMO設計の軸に置きます。

2-3. PMOが担わない領域を先に決める

PMOが担わない領域を、本記事では三つに整理します。価格交渉や契約締結といった調達、技術設計の判断、そして投資の可否判断です。これらはそれぞれ、調達部門、発注者側の技術責任者とSIベンダーの技術者、業務オーナーと経営スポンサーの領分です。担う範囲と担わない範囲を先に決めておくと、責任の押し付け合いが起きにくくなります。

次の表は、基幹刷新でありがちな状況に対し、PMOが担う範囲と担わない範囲を整理したものです。線引きの原則は、PMOが可視化と枠組みの提供に徹し、決定は権限を持つ人へ返すことです。PMOが動くべきか、決裁者に上げるべきかを判断する目安として使えます。

3. 刷新・業務改善・AI活用を一つのPMOで回す

刷新・業務改善・AI活用は、三本のストリームに分けたうえで、統制の枠組みだけを一つのPMOへ集約します。三つを混ぜて一本の作業列にしないことが鍵です。本章では、その設計の中身を順に見ていきます。

3-1. ストリーム分割 × 単一PMOガバナンス

三者を破綻なく回す設計の基本は、二段構えです。作業の流れを「刷新ストリーム」「業務改善ストリーム」「AI活用ストリーム」の三本に分け、統制の枠組みだけは単一のPMOに集約します。各ストリームは目的も専門性も違うため、無理に一つのチームで抱えると内部で優先順位争いが起きます。分けて走らせ、統制の芯だけをPMOがそろえます。これで自走とガバナンスを両立させます。

統合PMOが3つのストリームを束ねる構造を示します。PMOは進捗報告フォーマット・課題エスカレーション経路・変更管理ルールを共通の物差しとして揃え、各ストリームが自律的に動ける環境を整えます。

共通の物差しの中身は、定例会議の設計に落とすと具体的になります。たとえば週次の統合PMO定例に各ストリームのリーダーが集まり、同一フォーマットで次の三点を共有します。

• ストリーム別の進捗ステータス（赤・黄・緑の三段階）
• 他ストリームへ影響が出ている課題
• 翌週に決裁が必要な論点

PMOはこの場で依存関係を突き合わせ、影響が出ているストリーム間の調整を設計します。決めるのは各ストリームのオーナーで、PMOは論点と選択肢を並べる役に徹します。

分けたものを束ねる理由は、三本のストリームが依存し合うからです。依存が崩れる場面を具体で挙げます。業務改善で新しい業務プロセスが確定する前に刷新側の要件を凍結すると、後からの変更で改修費が膨らみます。データ移行が遅れると、移行後のデータを前提にしたAI活用のPoC（概念実証＝小さく試して効果を見る検証）が始められません。AI活用で扱うデータの品質は、移行時のクレンジングの精度に左右されます。どれも、片方の遅れがもう片方を巻き込む構図です。

単一PMOは、この依存関係を可視化する「管制塔」の役目を果たします。早期検知の具体は、定例の進捗ステータスと依存関係マップを毎週重ねて見ることです。あるストリームが黄から赤に変わったら、依存する下流の作業を依存マップからたどります。そのうえで、影響が及ぶ範囲を先に洗い出します。要件凍結の期限をずらすか、下流の着手を待たせるかといった選択肢を、決裁者へ差し出します。検知して終わりにせず、打ち手の候補まで用意して意思決定へつなぎます。

3-2. 業務棚卸し → 可視化 → 改善、そしてFit to Standard

業務改善は、棚卸し→可視化→改善の順で進めることを本記事では推奨します。まず現状業務を洗い出し、次にそれを見える形にし、そのうえで改善へ進みます。この順を飛ばして「改善案」から入ると、実態と乖離した机上の理想論になりやすくなります。現状業務をAs-Is（現状のプロセス）、目標業務をTo-Be（あるべきプロセス）と呼び、両者の差を埋める道筋を描きます。

ERPの標準機能に業務を合わせるのか、業務に合わせてカスタマイズするのか。この判断がフィット・ギャップ分析です。Fit to Standard（標準機能に業務を寄せる方針）を貫けるかが、追加開発の肥大化を左右します。Gap（差異）が多く見込まれる場合は、カスタマイズを増やす前に議論します。その業務ルール自体を標準に合わせられないかを、業務部門と話し合います。この審査プロセスをPMOが運営します。要件の膨張を止める具体策はスコープクリープ防止の7原則で詳しく扱っています。

ERPは入れるだけでは業務を変えません。標準機能に業務を寄せ、プロセスそのものを見直す体制が伴って、はじめて改善が進みます。IPA「ユーザのための要件定義ガイド 第2版」（2019年・情報処理推進機構）が上流工程を重視するのも、この地点でのボタンの掛け違いが後工程へ波及するからです。移行や業務切り替えの運用設計はPMO流チェンジマネジメント実践法もご参照ください。

3-3. AIが効く工程・人が判断する工程を切り分ける

AI活用ストリームで最初に手を付けるのは、期待値の調整です。本記事では、生成AIの用途を下案づくりに絞って整理します。処理の中身で道具を書き分けると、期待値がそろいます。

表記ゆれや欠損値の抽出は、集計ツールやスクリプトの処理で行えます。生成AIが担いやすいのは、抽出結果の要約や分類の下書き、要件の初期整理です。AI利用環境が整っていれば、こうした工程で短時間に叩き台を得られます。ただし速くなるのは、AIが初稿を担える工程に限られます。業務要件の合意やフィット・ギャップの最終判断は人が担います。

協働の流れを一つ描いてみましょう。移行データの品質チェックでは、まずツールで表記ゆれと欠損の一覧を作ります。生成AIはその一覧の要約と論点候補の下書きを出します。それをPMが業務オーナーと精査し、どれを補正し、どれを移行対象から外すかを確定します。

道具が下案を作り、人が業務上の意味づけと最終判断を担います。この分担が協働の基本形です。

業務データをAIに入力する際の線引きも、先に決めておきます。何をAIに入れてよいかを決めずに使うと、情報漏えいのリスクが立ち上がります。次の表は、当社が考える初期運用の一例として、情報の種類ごとの入力可否の考え方を整理したものです。判断に迷う情報は「入れない」を初期値にすると、安全側に倒せます。

※上表は当社が考える初期運用の一例です。実際の取扱いは、自社の情報セキュリティ方針と社内規程、顧客との契約、AIサービスの利用規約とデータ取扱条件、法令に従ってください。

4. ベンダーマネジメントと炎上予防の設計

基幹刷新では、ERPベンダー、SIer、既存システムの保守ベンダーなど、複数のベンダーが同時に関わります。ここの統制が緩むと、責任の空白地帯が生まれます。PMOはベンダーを「管理・指示」する存在ではなく、共有と統制の仕組みを設計・運営する存在だ、という前提から入ります。

4-1. ユーザーサイドPMOとベンダーサイドPMOの役割分担

マルチベンダーの現場では、発注者側に立つユーザーサイドPMOと、ベンダー内部に置かれるベンダーサイドPMOが並存します。両者の役割を混同すると、進捗報告が二重になったり、逆に抜け落ちたりします。ユーザーサイドPMOは全ストリームを横断して進捗・課題・リスクを束ね、経営への報告と意思決定の補佐を担います。ベンダーサイドPMOは自社の開発進捗と品質を管理し、ユーザーサイドへ定型フォーマットで報告します。

設計すべきは、報告フォーマット・エスカレーションルート・権限委譲の境界線です。

二層構造の典型例を挙げます。ベンダーサイドPMOが週次で課題ログと進捗サマリーをユーザーサイドPMOへ提出します。ユーザーサイドPMOはそれを月次でステアリングコミッティ（経営スポンサーを含む意思決定の場）へ集約して報告します。

エスカレーションの基準も先に文書化します。本記事での一例を挙げます。納期影響などが委譲範囲内なら、現場とユーザーサイドPMOで対応します。範囲外の事象は、ステアリングコミッティへ即時上申します。契約上の期限に関わる遅延、重大障害、情報流出も即時上申の対象です。日数だけで委譲の線を引かず、重大性も併せて判断します。

この経路を敷かないまま走ると、問題が現場に滞留して発覚が遅れます。ステークホルダーの巻き込み方はステークホルダマネジメントの実践法で掘り下げています。

PMOが設計・運営するのは、あくまで共有と統制の仕組みです。技術判断や価格交渉そのものは、各担当部門が担います。

4-2. 炎上パターンとPMO機能の対応マッピング

炎上パターンごとに、PMOが設計する機能を対応させておきます。要因の列挙だけでは、体制の設計につながりません。次の表は、代表的な炎上パターンと、それに対してPMOが用意する機能を対応させたものです。自社の計画がどのパターンに近いかを当てはめ、対応する機能が体制に「ある／ない」を点検してみてください。

炎上パターンと機能の対応を計画段階で埋めておくと、炎上が起きにくい構造へ近づけやすくなります。確実に防げると断言はできませんが、兆候の早期検知はしやすくなります。近年の政策動向も同じ方向を向いています。

経済産業省「レガシーシステムモダン化委員会 総括レポート」（2025年5月・経済産業省）は、レガシー脱却に向けた論点を挙げています。経営意識の転換、ITガバナンスの強化、IT部門の自律性強化、そしてベンダーとの連携です。統制の枠組みと役割分担を先に設計するという本記事の主張は、この政策的な整理と重なる部分があります。

4-3. 計画段階で先に決めておく5点

計画段階で先に決めるのは、スコープ・体制・KPI・ベンダー方針・意思決定ルールの五つです。本記事では、後から変えると影響が大きい項目をこの五つに整理します。プロジェクトが動き出す前に固めておく点が要点です。

とりわけ意思決定ルールは軽視されがちです。誰が、何を、いつまでに、どの会議で決めるのか。決裁の設計が曖昧なまま走ると、判断待ちで各ストリームが停滞します。逆にここを固めておけば、想定外の論点が出ても「これはこの会議で決める」と交通整理ができます。次のチェックリストで、計画段階の詰めを点検してみてください。

• 1

  スコープ
  各ストリームの「やること／やらないこと」を決めます。計画キックオフ前に3ストリームのリーダー・業務オーナー・IT統括が揃う場を設け、対象業務・システム範囲・期間をスコープ定義書に落とします。

• 2

  体制
  ユーザーサイドPMOとベンダーサイドPMO、各ストリームの決裁者を体制図に落とします。誰が最終の説明責任を負うかを一意に決めておきます。

• 3

  KPI
  刷新の目的を測る指標を、業務オーナー・経営スポンサーと合意します。目的とKPIをプロジェクト憲章に明記します。

• 4

  ベンダー方針
  報告フォーマットとエスカレーションルートを定義します。マルチベンダーなら、ベンダー横断で使う報告様式を先にそろえます。

• 5

  意思決定ルール
  変更の規模（工数・コスト・日程への影響）に応じたエスカレーション先を決裁マトリクスとして一枚に整理し、プロジェクト憲章に添付します。

5. 結論：計画策定フェーズこそPMO設計の勝負どころ

決めるのは業務オーナーと経営スポンサーで、支えるのがPMOです。この一点が、本記事で繰り返した原則です。PMOは論点・KPI・進行管理の枠組みを提供し、意思決定を後押しします。優先順位も投資も、PMOが単独で決めるものではありません。この線引きを崩さないことが、刷新・業務改善・AI活用という三つのストリームを一つの統制で回す前提です。炎上を必ず防げる保証ではありません。リスクを構造的に低減し、兆候を早期に検知しやすくする枠組みの話です。

この設計は、次年度のIT投資計画を練る「今」から始められます。プロジェクトが動き出す前に、スコープ・体制・KPI・ベンダー方針・意思決定ルールを固めます。この一手が、半年後・一年後の混乱の起きやすさを左右します。大きく構える必要はありません。まずは今週中に、業務オーナーと刷新のKPIを一本だけ合意する場を設けてみてください。その小さな一歩が、統合PMO設計の起点になります。