基幹システム・ERP導入にPMOは必要か？失敗しやすい理由と外部活用のポイント

基幹システムの刷新を任された情シスや経営企画の方なら、一度は「PMOって本当に必要なのか」と考えたことがあるはずだ。ベンダーにはPMがいるし、社内にも推進担当を置く。そのうえでさらに管理役を増やすのか、と。結論から言えば、複数部門にまたがる基幹システム・ERP導入では、PMOは「あった方がいい」ものではなく「ないと計画を立て切れない」機能だと僕は考えています。この記事では、なぜ基幹システム導入が失敗しやすいのかを構造から解きほぐし、PMOの役割と体制の組み方、外部PMO支援を使うときの見極め方まで、年間3桁億円規模のアカウントを統括してきたベテランPMとの対談で得た教訓を交えて整理する。

システム開発の成功率は3割と言われる。その中でも基幹システム・ERP導入は、特に条件の悪い部類に入る。会計・販売・購買・人事と複数部門の業務を同時に変え、締切の決まったデータ移行を抱え、パッケージベンダー・SIer・社内の業務部門という思惑の違うプレイヤーを最後まで調整し続ける。どこか一つの管理が漏れるだけで、遅延と予算超過に直結する構造です。

僕の持論に「3億円以下のプロジェクトは、計画を立て切れば大コケしない」というものがある。裏を返せば、基幹システム刷新の多くはこの規模を超えてくる。やること・やらないことを全部洗い出して計画に落とし切る作業そのものが、一人のPMの手には負えなくなる。ここが、PMOという専任機能を体制に組み込むべき分岐点だと思っている。

必要かどうか迷ったら、次のチェックリストで判断してほしい。3つ以上当てはまるなら、専任のPMOを体制図に入れることを勧める。

• 関係部門が3つ以上あり、業務要件の決定権が分散している
• 導入するパッケージ（ERP）の経験者が社内にいない
• データ移行の対象システムが複数あり、データの持ち主が部門ごとに違う
• プロジェクト期間が1年を超える見込み
• 社内の推進担当が現業との兼務で、専任者がいない

なお、SAP S/4HANAへの移行や2027年問題といったSAP固有の論点は事情が大きく異なるため、この記事では踏み込まない。レガシーシステム刷新の進め方全般も別のテーマに譲り、ここでは「体制」に絞って話を進める。

先日、YouTubeチャンネルの対談で、システムズデザイン株式会社 取締役の岡田さんにお話を伺った。大手SIerの金融部門で幹部を務め、年間3桁億円規模のお客様予算を預かる組織を率いてきた方だ。その岡田さんが「プロマネに対する考え方が大きく変わった転機」として挙げたのが、某金融企業向けの統合コールセンター構築プロジェクトだった。予算規模は約10億円、2,000席。グローバルスタンダードなパッケージ製品の導入案件だ。ERPそのものではないが、「海外製パッケージを、業務のこだわりが強い日本企業に入れる」という構造は基幹システム導入と同じで、失敗のメカニズムもそのまま重なる。対談の全体を動画で詳しく知りたい方は、以下もあわせてご覧ください。

「3桁億PMが語る大規模プロジェクトマネジメントの失敗と教訓【プロジェクトマネジメントの教室】」

この事例を下敷きに、失敗しやすい理由を4つに整理する。

理由1：パッケージの思想と、業務のこだわりが「真逆」だから

format_quote

日本のお客様って業務に対するこだわりが非常に強いので、自分たちがやりたいこの業務を実現するためにパッケージをカスタマイズしてほしい、という願いが非常に強いんですよね。パッケージメーカーの方々は、パッケージに合わせて業務を変えてくださいという考え方。つまり、もう真逆なんですね。ということは、当然コンフリクトが発生します。そのコンフリクトを調整することこそが、SIerのプロマネの役目のはずなんです。

ERP導入で言われる「Fit to Standard（業務をパッケージに合わせる）」と、現場の「今の業務を変えたくない」は、放っておけば必ず衝突する。問題は、衝突が起きること自体ではない。衝突を裁く機能を体制に用意していないことだ。カスタマイズ要求を一つずつ「業務を変える／作り込む／諦める」に仕分ける判断は、ベンダー任せにも現場任せにもできない。

開発プロジェクトの7割は上流工程で決まると僕は考えている。自社のAI上流工程支援プロダクトに「Headwater（川の源流＝ヘッドウォーター）」と名付けたのも、源流を押さえるのが一番大事だという意味を込めてのことだ。基幹システム導入では、この仕分けこそがまさにその最上流にあたる。

理由2：中身を誰も把握しないまま、「丸投げの多段構造」ができるから

岡田さんのプロジェクトは、どこを統合しどこを統合しないかをコンセプチュアルに提案したことが評価され、受注にこぎつけた。良かったのはそこまでで——と、ご本人は続ける。

format_quote

そのグローバルスタンダードなパッケージの、実は中身がよくわかってなかった。なので、そのパッケージを使ったことのあるパートナー様に丸投げする形に、結果としてなってしまったんですよ。

パッケージの中身がわからないから、顧客とパッケージメーカーの間で右往左往するしかなくなり、調整に時間を食い、最終的に納期を遅延させてしまった——対談ではそう率直に語られていた。岡田さんの結論は明快で、経験のないパッケージを入れるなら、開始前に1〜2週間を潰してでもプロマネ自身が中身を腹落ちできるまで学んでから入るべきだった、急がば回れだ、というものだ。

これは受注側だけの教訓ではない。プロジェクトの失敗原因は発注側にも受注側にもある。発注側→SIer→パートナー→パッケージメーカーと委託が多段になるほど、「何ができて何ができないか」の線引きを誰も持たないまま要件だけが積み上がる。発注側にこの構造を監視する機能——つまりPMO——がなければ、丸投げの連鎖は誰にも止められない。

理由3：多部門の利害調整が、決める場の設計なしに始まるから

経理は月次決算を止めたくない。営業は現場の入力負荷を増やしたくない。情シスは保守性を守りたい。基幹システムの要件は部門間トレードオフの塊で、「誰が・どこで・いつまでに決めるか」を設計せずに走り出すと、要件は声の大きさで決まっていく。決まらない論点は先送りされ、設計工程で再燃し、テスト工程で噴き出す。表面化するのはスケジュール遅延ですが、遅延は症状にすぎない。真因は、部門間の合意形成という上流の仕事を、誰の責任範囲にも置いていなかったことにある。

理由4：データ移行と本番相当の検証が、終盤まで後回しになるから

対談で最も背筋が冷えたのは、サービスイン後の話だった。海外製DBMS製品のバグを引き、ある条件で数百万件のフルスキャンが走ってメモリが枯渇し、サーバーダウン。2,000席のうち600席まで拡大していたコールセンターを、いったんサービス中止まで戻した。パッチを当てて再リリースするにも、本当に問題がないかを何度も検証する必要があり、リベンジまで半年近くかかったという。

format_quote

実際の本番データと同じ量で、同じトランザクションを再現させておくということって、意外と難しかったりもするので、そういった時に運用テストの重要性っていうのは非常に痛感いたしました。

前始末は後始末の3〜5倍安い、というのが僕の信念だが、基幹システムの本番障害はその比ではない。業務停止、データ補正、顧客への説明、再発防止策の検証。事後のコストは何重にも膨らむ。データ移行と負荷検証は「最後にやる作業」ではなく、計画段階から管理すべきリスクの筆頭なのだ。

PMOが担うべき5つの役割

失敗の構造を裏返すと、基幹システム導入でPMOが担うべき役割が見えてくる。

PMOを「報告の中継役」で終わらせない

役割を並べたうえで、一番強調したいのはここだ。対談で岡田さんが語った次の言葉は、PMだけでなくPMOにもそのまま当てはまる。

format_quote

数字しか抑えてないと、品質のデータだとか進捗の状態ですとか、「何日遅れてます、原因が何で、リカバリーに何日かかります」という報告を聞いて、ただそれを喋るだけというのがプロマネになってしまいますので。やっぱり中身をしっかり把握するということがプロマネにとって極めて重要で、大規模になればなるほど私は大事だと思いますね。

大規模になるほど管理業務が膨らむのだから、管理者は純粋な管理に専念し、中身は各リーダーに任せる分業になる——僕も対談前はそうイメージしていた。実際は逆で、大規模だからこそ中身を押さえないと、関係者との会話すら成立しなくなる。進捗率をExcelに転記して読み上げるだけのPMOなら、置かない方がましです。遅延の数字の裏にある要件のズレを特定し、経営が判断できる形に選択肢を並べる。そこまでやって初めて、体制図にPMOを置く意味がある。

体制は3パターン。ただし「発注側に軸足を置く1枚」を必ず入れる

どのパターンを選ぶにせよ、原則は一つ。発注側の利害に軸足を置いて中身に踏み込むPMOを、最低1枚は入れることだ。ベンダー側PMOが悪いという話ではなく、ベンダー自身の見積りの甘さや品質問題を、ベンダーの中の人が発注側の経営に率直に報告するのは構造的に難しい、というだけの話である。

体制を組んだうえで、基幹システム導入で特に転びやすい3つの領域の勘所を押さえておきたい。

多部門調整：「誰が・どこで・いつまでに決めるか」を先に文書化する

要件定義が始まる前に、論点の決定ルールを文書で決めておく。担当者間で決めてよい論点、部門長間で決める論点、ステアリングコミッティに上げる論点の3階層に分け、それぞれに期限を切る。もう一つ重要なのが、業務部門のキーパーソンの稼働確保を経営に約束させることだ。「現場が忙しくて要件レビューに出られない」を放置した瞬間、パッケージと業務の仕分けは止まる。

データ移行：独立したサブプロジェクトに格上げする

データ移行を開発の付帯作業として扱うと、ほぼ確実に終盤で泣く。移行対象データの棚卸しとクレンジングは要件定義と並走で始め、移行リハーサルの回数を最初から計画に織り込む。そして岡田さんの教訓のとおり、本番と同じ量・同じトランザクションでの運用テストを省略しない。ここはコストを惜しむ場所ではなく、かけた分だけ品質が返ってくる場所なんです。

ベンダー管理：「何ができて何ができないか」の線引きを自社側に持つ

パッケージ導入のベンダー管理で最初にやるべきは、進捗の督促ではなく、標準機能でできること・できないことの線引き表を自社側に持つことだ。線引きがベンダーの頭の中にしかない状態では、カスタマイズ要求の妥当性を判断できず、見積りの言い値を飲むしかなくなる。マニュアルを読むだけでなく、プロトタイプを触って確かめる。岡田さんも、合宿をしてでも開始前に把握しておくべきだったと振り返っていた。ベンダーコントロールの具体的な実践手法はそれだけで一本の記事になる分量なので、ここでは深入りせず、丸投げを防ぐベンダーコントロールの実践は別記事に譲る。

社内に経験者がいない場合、外部PMO支援は現実的な選択肢になる。ただし、入れ方を間違えると「高い議事録係」を雇うだけに終わる。外部PMO支援に任せられる業務範囲や委託の進め方の全体像は別記事に譲るとして、基幹システム導入に絞った見極めのポイントは4つ。

1. 計画段階から入れる。 ベンダー選定や要件定義が走り出してからでは、上流の仕分けに関与できない。構想段階で入れるのが最も費用対効果が高い。火消しでの途中参画にも価値はあるが、前始末の方が遥かに安くつく。
2. パッケージ・基幹システム導入の経験を確認する。 進捗管理の一般論ではなく、業務とパッケージの仕分けやデータ移行計画のレビューといった中身に踏み込めるか。複数部門・パッケージ導入・データ移行ありという近い構成の支援経験を、具体的に聞いてみるといい。
3. 発注側の立場で動けるかを確認する。 導入ベンダーと資本関係・商流関係がないか。ベンダーの品質問題を経営に率直に報告できる立ち位置かどうかは、契約前に確かめておくべき点だ。
4. 成果の定義を最初に求める。 「何をもってPMOが機能しているとみなすか」を自分から提案できない支援会社は、議事録係になる可能性が高い。期待する成果物と、判断を求める場面のリストを、着任時に文書ですり合わせる。

支援会社ごとの得意領域は、公開されている事例を「導入前の課題→支援内容→成果」のセットで読み比べると見えてくる。クリエイティブテックスタジオの支援事例も事例紹介で公開しているので、判断材料の一つにしてほしい。

• 部門をまたぐ基幹システム・ERP導入は、計画を立て切る作業が一人のPMの手に負えない規模になる。だからPMOはほぼ必須
• 失敗の構造は4つ。パッケージ思想と業務のコンフリクト、丸投げの多段構造、合意形成の設計不足、データ移行・検証の後回し
• PMOは報告の中継役ではなく、中身を把握して判断材料を作る機能として設計する
• 体制は内製・ベンダー側・外部の3パターン。どれを選んでも、発注側に軸足を置く1枚を必ず入れる
• 外部PMOは計画段階から。導入経験・立ち位置・成果の定義の3点で見極める

基幹システムの刷新は、多くの担当者にとって職業人生で一度か二度しか巡ってこない仕事だ。社内に経験者がいないのは当たり前で、恥じることでは全くない。ただ、経験がないままプロジェクトの源流を流れに任せれば、その代償はサービスインの後に、何倍にもなって返ってくる。経験は外から借りられる。借りるべきは作業の人手ではなく、計画を立て切るための知見です。投資先を間違えないための支援会社の見極め方は、別記事で詳しく整理している。

---

基幹システム・ERP導入のPMO体制づくりに悩んだら

「ERP導入が決まったが、社内に大規模プロジェクトの経験者がいない」「ベンダーの『順調です』を検証する手段がなく、報告を信じるしかない」「データ移行が漠然と不安だが、何から手を付ければいいかわからない」——基幹システム刷新の悩みは、突き詰めるとだいたいこの3つのどれかに行き着きます。

クリエイティブテックスタジオは、発注側に軸足を置いたPMO支援を提供しています。進捗表の管理だけでなく、パッケージと業務の仕分け、データ移行計画のレビュー、ベンダーとの調整といった中身に踏み込むのが僕たちのやり方です。サービスの詳細はPMO支援サービスをご覧ください。

体制をどう組むべきか、そもそも外部PMOが必要かどうかの整理だけでも構いません。お話を伺ったうえで、社内で組める体制があればその組み方を、他社のサービスが適していればその旨も正直にお伝えします。まずは無料相談からお気軽にどうぞ。