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

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

「うちのプロジェクトは大丈夫だろうか」。基幹刷新の計画段階で、この不安を感じない責任者はいません。まず押さえたいのは、炎上が現場の頑張り不足ではなく、プロジェクトの構造から生まれるという事実です。構造を先に理解しておくと、PMOで何を設計すべきかが見えてきます。DXプロジェクト全般の落とし穴はDXプロジェクト管理で失敗しない進め方でも整理していますので、あわせてご覧ください。

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

基幹システム刷新は、単なるシステムの入れ替えではありません。会計・販売・購買・在庫・人事といった中核業務を統合管理するERP（Enterprise Resource Planning＝統合基幹業務パッケージ。自社開発の基幹システムとは別物です）の導入が軸になります。そこへ旧システムからのデータ移行、業務プロセスそのものの改善、生成AIの活用検討が、同じ時間軸で並走します。たとえるなら、走っている電車の車両を入れ替えながら、同時に線路も引き直し、運行ダイヤも見直すようなものです。どれか一つでも段取りを外すと、全体が止まります。

ここで注意したいのが用語の混同です。ERP刷新はパッケージ導入が中心で、標準機能に業務を合わせるフィット・ギャップ分析が欠かせません。一方、老朽化した独自システムを作り替えるレガシーマイグレーションは、アーキテクチャの再構築を含む別概念です。両者を「刷新」の一語でまとめると必要な作業も体制も見誤るため、自社の刷新がどちらの性格を強く持つかは計画段階で言語化しておきます。

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

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

複合プロジェクトである以上、炎上の火種も一か所ではありません。実務で繰り返し現れるのは四つの断層です。第一に、スコープが管理されないまま膨らむこと。第二に、部門をまたぐステークホルダーの整合が取れないこと。第三に、ベンダーとの役割境界が曖昧なこと。第四に、業務改善とシステム設計が別々に進んで分断すること。

炎上の火種となる4つの断層が連鎖する構造を図示します。それぞれが独立した問題に見えて、実は互いを呼び込む連鎖構造になっています。

具体的な場面を思い浮かべてみましょう。要件定義の途中で営業部門が「この画面もほしい」と追加を要望し、情報システム部門はベンダーに口頭で伝え、ベンダーは「言われたので作る」と受ける。誰も全体のスケジュールとコストへの影響を確認していません。これがスコープクリープ（変更管理を経ずにスコープが無統制に拡大すること）です。正式な変更管理を通した仕様変更とは区別すべきものです。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が便利屋になるか、逆に何でも決める過剰な存在になるか、どちらかに振れます。役割を二つの機能に分けて定義すると、境界がはっきりします。

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（差異）が全機能の3割を超えるような状況では、カスタマイズを増やす前に「その業務ルール自体を標準に合わせられないか」を業務部門と議論する。この審査プロセスを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はそれを月次でステアリングコミッティ（経営スポンサーを含む意思決定の場）へ集約して報告する。

エスカレーションの基準も先に文書化します。たとえば「納期への影響が1週間以内なら現場とユーザーサイドPMOで対応、1週間を超えるならステアリングコミッティへ即時上申」と、課題の規模で報告先を分けておく。

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

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

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

炎上要因を列挙するだけの記事は多いのですが、実務で効くのは「その要因に対しPMOが何を設計するか」への接続です。次の表は、代表的な炎上パターンと、それに対してPMOが用意する機能を対応させたものです。自社の計画がどのパターンに近いかを当てはめ、対応する機能が体制に組み込まれているかを点検する使い方をおすすめします。表を眺めるだけでなく、各行の右側が自社に「ある/ない」を確認するのが要点です。

この対応関係を計画段階で埋めておくと、炎上を「起きにくい構造」へ近づけられます。確実に防げると断言はできませんが、兆候の早期検知はしやすくなります。近年の政策動向もこの方向を後押ししています。経済産業省「レガシーシステムモダン化委員会 総括レポート」（2025年5月・経済産業省）は、レガシー脱却に向けた論点を挙げています。経営意識の転換、ITガバナンスの強化、IT部門の自律性強化、そしてベンダーとの連携です。統制の枠組みと役割分担を先に設計するという本記事の主張は、この最新の政策的な整理とも重なります。

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

ここまでの議論を、計画策定フェーズの行動に落とし込みます。競合記事の多くはプロジェクト開始後を想定していますが、実は勝負は計画段階にあります。後から変えると炎上する項目を、先に固めておくのです。決めておくべきは五つ。スコープ、体制、KPI、ベンダー方針、意思決定ルールです。

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

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

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

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