企業システムの意思決定の多くは、いつ決めるかを自分たちで選べます。ところが基幹システムのサポート終了だけは違います。製品ベンダーが保守の終了時期を公表した時点で、判断の期限は外から与えられます。SAPは主力の業務スイート（SAP Business Suite 7 / SAP ERP 6.0）の標準保守を2027年末まで、有償の延長保守を2030年末までとし、後継のSAP S/4HANAについては2040年までの保守提供を表明しています。いわゆる「2027年問題」と呼ばれるものです。

期限が明示されているのですから、本来は最も計画しやすい投資のはずです。しかし実際には、多くの企業が数年にわたって結論を出せずにいます。そして期限が近づくほど、要員も支援パートナーも確保しにくくなり、判断の自由度は下がっていきます。

この記事では、特定製品の移行手順ではなく、基幹システムのサポート終了という局面を、経営の投資判断とプロジェクト推進の問題としてどう扱うか を整理します。SAPを例に挙げますが、考え方は他のERPパッケージやミドルウェア、業務パッケージの世代交代でも同じように使えます。

課題 ― 期限は決まっているのに、判断が進まない

サポート終了への対応が止まる企業には、共通した3つの詰まり方があります。

1つ目は、選択肢が2択に縮んでいることです。 議論の場に上がるのが「後継製品へ移行するか、しないか」の二択だけになっているケースは非常に多く見られます。実際には延命も、別の製品への乗り換えも、機能ごとに切り出す形も選択肢です。2択で議論している限り、答えは「金額が大きすぎるので、もう少し様子を見る」に落ち着きがちです。

2つ目は、現行システムの実態を誰も説明できないことです。 どれだけのアドオン（追加開発した独自機能）があり、そのうちいくつが今も使われているのか。外部システムとの連携がどれだけあり、どのデータが本当に必要なのか。この棚卸しがないまま見積もりを取ると、ベンダーは安全側に振った金額を出さざるを得ません。高い見積もりが出る、経営が驚く、判断が止まる、という循環に入ります。

3つ目は、意思決定者が定まっていないことです。 IT部門が起案するものの、業務プロセスを変える判断は業務部門にしかできず、投資規模から見れば経営の決裁が要ります。誰が何を決めるかが曖昧なまま検討だけが進み、結論が出ないまま時間が過ぎていきます。

この3つは独立した問題ではありません。実態が見えないから選択肢を並べられず、選択肢が並ばないから経営が判断できない、という一本の線でつながっています。

なぜ今、あらためて問われるのか

サポート終了そのものは以前から分かっていた話です。それでも今、議論が再燃しているのには理由があります。

期限までの残り時間が、プロジェクト期間より短くなり始めています。 基幹システムの刷新は、現行調査から本稼働まで数年を要するのが通例です。標準保守の終了時期を前提に逆算すると、すでに「今から検討を始めても間に合うか」を確認しなければならない段階に入っている企業が出てきています。

支援側の供給が逼迫します。 同じ期限に向けて需要が集中するため、経験のある要員やパートナーは早い者勝ちになります。後になるほど選べる相手が減り、単価も上がります。つまり 「いつ決めるか」自体が、条件を左右する判断 になっています。

先行事例の失敗が可視化されてきました。 大規模な基幹システム刷新で損失を計上した事例や、稼働直後に内部統制上の不備が表面化した事例が報じられています。期限に追われて品質やスコープの管理を犠牲にすると、サポート切れよりも大きな損害を招きかねないことが、実例として知られるようになりました。

「2025年の崖」以降の文脈も残っています。 経済産業省のDXレポートが指摘したとおり、老朽化・複雑化した基幹システムは、それ自体がリスクであると同時に、新しい取り組みの足かせになります。サポート終了は、その積み残しを扱わざるを得ないタイミングを外から与えているとも言えます。

まず選択肢を4つに開く

判断を前に進める最初の一手は、選択肢を正しく並べ直すことです。二択ではなく、少なくとも次の4つを机の上に載せます。

選択肢 内容 得られるもの 先送りするもの 向くケース
移行 同じベンダーの後継製品へ乗り換える 業務の連続性、ベンダー支援の得やすさ 業務標準化の議論（方式次第で温存される） 現行製品への依存度が高く、業務要件も大きく変えない
延命 延長保守や第三者保守で稼働を続ける 判断の時間、目先の投資回避 老朽化そのもの。期限も再び来る 事業構造の変更（統合・分社等）が控え、今は決められない
再構築 別のERPやSaaS、内製を含めて選び直す 前提の見直し、コスト構造の変更 移行負荷は最大。習熟もやり直し 現行が業務実態と合っておらず、標準に寄せる意思がある
分割 コア機能は残し、周辺業務を個別サービスへ切り出す 段階的な移行、リスク分散 全体アーキテクチャの複雑化 一括での刷新が体力的に難しく、優先順位が明確

重要なのは、延命を「何もしないこと」と同一視しない ことです。延長保守や第三者保守は、事業再編を控えているなど正当な理由があれば合理的な選択です。ただし条件が2つあります。ひとつは、延命している期間に何を進めるか（現行調査、アドオン削減、データ整備）を決めておくこと。もうひとつは、延命にも期限があり、その先で同じ判断が再び必要になると認識しておくことです。この2つがないまま延命を選ぶと、判断を先送りしただけで、次に来るときには残り時間だけが減っています。

判断の軸 ― 経営に問うべき5つの問い

選択肢を並べたら、次は比較の軸です。金額と期間だけで比べると、必ず「一番安い案」に流れます。実務では次の5つを、経営を含めた場で言語化することをお勧めします。

1. 業務を標準に寄せる意思が、経営にあるか。 これが最も効きます。「現行の業務は一切変えない」という前提を置いた瞬間、選べる方式もコストも決まってしまいます。逆に、標準に寄せると決めたなら、その痛みを引き受ける覚悟を経営が示す必要があります。IT部門が現場を説得して回る構図にすると、まず通りません。

2. アドオンは今も価値を生んでいるか。 独自開発した機能の多くは、追加した当時の事情に基づいています。制度が変わり、担当者が代わり、使われなくなっているものは珍しくありません。「使っているか」ではなく「なくなると何が困るか」を業務側に問い直すと、実際に残すべきものは想定よりかなり絞られることがよくあります。

3. データは移行に耐えるか。 マスタの重複、コード体系の不整合、履歴データの品質。これらは移行方式の選択を左右し、方式が決まった後で発覚すると計画が崩れます。どこまでの履歴を移すのかは業務・監査要件の問題であり、技術的な都合で決めるべきではありません。

4. 期限までに使える体力があるか。 社内の要員、パートナーの確保、並行して走っている他の投資案件。基幹システムの刷新は、IT部門だけでなく業務部門の主要メンバーを長期間拘束します。同じ人が別の重要案件も抱えているなら、それは計画上の制約として先に扱う必要があります。

5. この投資で、サポート維持以外に何を得るのか。 「サポートが切れるから」だけを理由にした稟議は、通ったとしても弱いままです。途中で予算が絞られたとき、優先度を守る根拠がありません。決算の早期化、業務の標準化によるM&A対応力、データの一元化といった便益を、少なくとも定性的に合意しておきます。

移行方式をどう選ぶか

後継製品への移行を選んだ場合、方式の議論が始まります。代表的な3つの考え方を整理します。

方式 考え方 得意なこと 主なリスク 向くケース
新規構築型（Greenfield） 新しい環境を一から構築し、業務を標準に寄せる 業務プロセスの刷新、アドオンの整理 業務部門の負荷が最大。合意形成に時間がかかる 業務を変える意思があり、期間の余裕がある
移行型（Brownfield） 現行環境を後継製品へ変換し、資産を引き継ぐ 期間短縮、業務の連続性 現行の複雑さをそのまま持ち込む 期限が迫っており、まずは基盤だけ更新したい
選択移行型（Selective Data Transition） 必要な設定・データだけを選んで新環境へ移す 上の2つの中間。段階的な整理が可能 設計と検証の難度が高い。実績のある支援が要る 残すべき資産と捨てる資産が切り分けられる

方式選びで最も多い誤りは、方式を出発点にしてしまうこと です。「短期間で終わるらしいから移行型で」と決めた後に、業務部門から「この機会にプロセスを見直したい」という要望が出て、スコープが膨らむ——これは典型的な崩れ方です。

順序は逆です。業務をどこまで変えるのか、アドオンをどこまで減らすのか、データをどこまで持っていくのか。これらを先に決めれば、方式はその帰結としてほぼ自動的に決まります。方式は目的ではなく、決めたことを実現する手段です。

なお、移行型を選んだ場合でも「後から段階的に整理する」ことは可能です。ただしそれは、整理する計画と体制を稼働後に確保できる場合に限ります。「いったん移行して、落ち着いたら見直す」という言い方で先送りされた課題が、実際に見直された例は多くありません。稼働後に何をいつ整理するのかを、移行の意思決定と同時に決めておくべきです。

アドオンの扱いは、技術ではなく統制の問題

近年のERP移行では「クリーンコア」という言葉がよく使われます。標準機能からの逸脱を最小限にとどめ、必要な拡張は基幹の中に埋め込まず、公開されたインターフェースを介して外側のプラットフォーム上に置く、という考え方です。SAPであれば、拡張をSAP BTP側に分離する構成がこれにあたります。

この考え方の狙いは、バージョンアップのたびに独自開発部分の改修に追われる状態から抜け出し、更新を継続的に受け入れられるようにすることです。技術的な話に聞こえますが、マネジメントにとっての意味は別のところにあります。

クリーンコアの本質は、「誰がアドオンの追加を承認するか」という統制の設計です。

どれだけ丁寧に整理して移行しても、稼働後に個別要望を受け入れる仕組みが以前のままなら、独自機能は同じ速度で再び増えていきます。多くの企業が「10年前に刷新したはずなのに、また同じ状態になっている」という経験をしているのは、移行の技術的な巧拙ではなく、この統制が設計されていなかったためです。

刷新プロジェクトの中で、次の3点を決めておくことをお勧めします。

  • 申請と審査の経路：追加開発の要望を誰が受け、誰が可否を判断するか。判断者は業務部門・IT部門のどちらか一方ではなく、両者が入る場であることが望ましい
  • 判断の基準：標準機能で代替できないか、外側の拡張として実現できないか、そもそも業務側を変えられないかを、この順で問う
  • 定期的な棚卸し：追加した機能を一定周期で見直し、使われていないものを止める。作るときの手続きだけ整えて、やめる手続きがない組織は非常に多くあります

こうした統制は、現行資産の全体像が見えていて初めて機能します。どのシステムがどの業務を支え、どのデータがどこで生まれてどこへ流れているのか——この見取り図を持つ取り組みが、エンタープライズアーキテクチャ（EA）です。基幹システムの刷新は、EA的な可視化に着手する現実的なきっかけにもなります。詳しくはエンタープライズアーキテクチャ（EA）の始め方で整理しています。

進め方 ― 期限から逆算する4ステップ

ステップ1：現行資産を棚卸しする

アドオン、外部連携インターフェース、帳票、マスタ、そして「実際に使われているか」の利用実態。ここを飛ばして見積もりを取ると、金額は必ず安全側に膨らみます。この工程は移行の準備ではなく、判断の材料づくり です。移行すると決める前に着手して構いません。延命を選ぶ場合でも、この棚卸しは無駄になりません。

ステップ2：選択肢を評価し、投資として合意する

4つの選択肢について、費用・期間・リスク・得られる便益を並べたシナリオを作り、経営の場に出します。ここで大切なのは、IT部門が推奨案を1つだけ持っていくのではなく、比較できる形で出す ことです。選択肢を見せずに1案だけ持ち込むと、経営は判断ではなく承認しかできず、後で「他の道はなかったのか」という話に戻ります。

ステップ3：スコープと方式を確定し、体制を組む

業務をどこまで変えるかの合意を先に取り、その帰結として方式を決めます。同時に、業務部門から意思決定できる人を出してもらいます。「調整担当」ではなく「決められる人」です。ここが確保できないプロジェクトは、後工程ですべての判断が止まります。

ステップ4：実行し、稼働後の統制まで設計する

移行そのものに加えて、稼働後のアドオン統制、運用体制、更新の受け入れ方を設計します。プロジェクトのゴールを「本稼働」に置くと、この部分が誰の担当でもないまま解散します。ゴールは「新しい基盤を、継続的に更新し続けられる状態」に置くべきです。

推進体制 ― 誰が何を決めるか

基幹システムの刷新が難しいのは、技術的な難度よりも、判断の主体が組織をまたいで分散している ためです。役割を先に固定しておきます。

役割 主な責務 よくある機能不全
経営・投資委員会 投資の可否、業務を標準に寄せる方針の明示、スコープ変更の裁定 起案を承認するだけで、業務変更の後ろ盾にならない
業務オーナー（部門長級） 業務要件の決定、アドオン要否の判断、移行後の受け入れ 決定権のない担当者が窓口になり、判断が持ち帰りになる
PMO 全体計画、進捗・課題・リスクの統制、意思決定の場の運営、ベンダー横断の調整 進捗の集計係になり、判断を上げる機能を果たさない
IT部門・アーキテクト 現行資産の把握、方式・アーキテクチャの評価、統制ルールの設計 実装の議論に埋没し、全体設計が誰の担当でもなくなる
ベンダー 製品知見の提供、構築・移行の実行 要件定義ごと委ねられ、発注者が判断できなくなる

この体制で最も重要なのは、PMOが「業務オーナーに決めさせる」機能を持つこと です。基幹システムの刷新では、業務側が判断を保留し続けることでスケジュールが崩れるケースが多く見られます。いつまでに何を決める必要があり、決まらない場合に何が起きるのかを可視化して意思決定の場に上げるのは、PMOの役割です。

もうひとつは、ベンダーへの委ね方です。製品知見はベンダー側にありますが、業務要件とアドオンの要否は発注者にしか決められません。ここを一体で任せると、後から「言われたとおりに作った」という結果だけが残ります。複数ベンダーが関わる場合の統制の考え方はマルチベンダー時代のベンダーマネジメントで扱っています。

PMO自体をこれから立ち上げる場合は、権限と担う範囲の設計が先です。PMOの立ち上げ方と組織設計を参考にしてください。

よくある失敗と回避策

失敗パターン 何が起きるか 回避策
「サポートが切れるから」だけで稟議を出す 便益が語られないため、途中で予算・優先度が下がる サポート維持以外に何を得るのかを、定性的でよいので合意しておく
現行調査を省いて方式を決める 後から想定外のアドオン・連携が出て、計画が破綻する 判断の前に棚卸しを実施する。延命を選んでも無駄にならない
業務部門が「今のまま」を要求する 独自機能が再生産され、次の世代交代でも同じ問題が起きる 標準に寄せる方針を経営が明示し、例外の判断基準を決める
要件定義ごとベンダーに委ねる 発注者が判断できず、稼働後の運用も他人任せになる 業務要件とアドオン要否は発注者が決める前提で体制を組む
期限直前に一括で切り替える 検証期間が確保できず、稼働後に業務・決算・統制へ影響が出る 逆算した計画に検証と並行稼働の期間を明示的に確保する
本稼働をゴールにする 統制と運用が置き去りになり、数年で元の状態に戻る アドオン統制と運用体制の設計をプロジェクトのスコープに含める

FAQ

Q. 延長保守や第三者保守で待つのは、単なる先送りですか。

必ずしもそうではありません。事業構造の変更が控えている、他の大型投資と重なっているなど、今は決められない正当な理由があるなら合理的な選択です。ただし、延命している期間に現行調査やアドオン削減を進めること、そして延命にも期限があり同じ判断が再び来ることを、あらかじめ確認しておく必要があります。何も進めずに時間だけ使うと、次の局面では選択肢がさらに狭まります。

Q. どこから手を付ければよいですか。

現行資産の棚卸しです。アドオン、外部連携、帳票、マスタ、そして利用実態。これは移行を決める前でも着手できますし、どの選択肢を選んでも使えます。判断が止まっている企業の多くは、この材料がないことが原因です。

Q. 業務を標準に寄せる新規構築型のほうが良い、と言われますが本当ですか。

一般論としては、独自機能を整理できるという利点があります。ただし業務部門の負荷が最も大きく、合意形成に時間がかかります。期限までの残り時間、業務部門から出せる人員、経営が業務変更を後押しできるかによって、適切な方式は変わります。「良い方式」ではなく「自社が完遂できる方式」を選ぶべきです。

Q. アドオンはゼロにすべきですか。

ゼロを目標にする必要はありません。競争力に直結する業務については、独自の作り込みが妥当な場合もあります。判断すべきなのは数ではなく、そのアドオンが標準の更新を妨げる場所に置かれていないか です。基幹の中に埋め込む代わりに、外側の拡張として分離できないかを検討します。

Q. 生成AIを使えば移行は楽になりますか。

現行資産の解析やドキュメント整備など、調査・整理の工程では作業量を減らせる可能性があります。一方で、この記事で扱ってきた「業務を標準に寄せるか」「どのアドオンを残すか」「誰が決めるか」は、いずれも組織の合意の問題であり、AIが代わりに決められるものではありません。AI活用の位置づけについては生成AI時代のレガシーモダナイゼーションで詳しく扱っています。

Q. 社内に大規模刷新の経験者がいません。

外部の支援を使うこと自体は現実的な判断です。ただし、意思決定そのものを外に出さないことが条件になります。支援を受ける場合でも、判断の材料を理解し、選択の理由を自社の言葉で説明できる状態を保ってください。この線引きの考え方はシステム内製化の進め方とも共通します。

まとめ

基幹システムのサポート終了は、外から期限を与えられる数少ない意思決定です。裏返せば、計画的に扱える数少ない機会でもあります。

判断を前に進めるための要点は、次の4つに整理できます。

  • 選択肢を4つに開く。移行・延命・再構築・分割を並べ、二択の議論から抜け出す
  • 判断の材料を先に作る。現行資産の棚卸しは、どの選択肢を選んでも無駄になりません
  • 方式は帰結として決める。業務をどこまで変えるかを先に合意すれば、方式はほぼ決まります
  • 稼働後の統制まで設計する。アドオンの承認経路と棚卸しの仕組みがなければ、同じ問題が次の世代交代でも繰り返されます

そして最も重要なのは、この判断をIT部門だけの課題にしないこと です。業務を標準に寄せるかどうかは経営の方針であり、アドオンの要否は業務部門の判断です。その合意を取り付け、決めるべき論点を決めるべき人へ運ぶ役割は、PMOが担うべき仕事です。

参考資料

関連記事