基幹システム/ERP更改の開発期間・スケジュール・納期について

基幹システム/ERP更改とは、会計・人事給与・生産管理・販売管理・在庫管理といった企業の背骨となる全社基盤システムについて、保守サポート契約の満了やハードウェア（オンプレミスサーバー）のリース満了、ERPパッケージのバージョンアップサイクルの節目という「契約・ライフサイクル起点の期限」をきっかけに、そのまま延長するか作り替えるかを判断し実行する取り組みを指します。同じ基幹システム/ERPというテーマを扱いながらも、記事「基幹システム/ERPのモダナイゼーション」が扱うのはグリーンフィールド・ブラウンフィールド・ブルーフィールドという移行アプローチの選び方に代表される「どう技術的に刷新するか（HOW）」という論点であり、記事「基幹システム/ERP刷新」が扱うのは経営層がなぜ・いつ刷新に投資すべきかという「経営判断（WHY/WHEN）」という論点です。これに対し本記事群が扱う基幹システム/ERP更改は、保守契約の更新通知やハードウェアリースの満了通知が届くという、企業の意思とは無関係に外部から強制的にやってくる期限にどう向き合うかという「契約起点のWHEN」に焦点を当てます。ゼロから基幹システムを構築する「基幹システム開発」「ERP導入」とも異なり、既に稼働している老朽化した基幹システムを前提とする点はモダナイゼーション・刷新と共通ですが、更改は良くも悪くも「待ったなし」で判断を迫られる契約実務である点が最大の特徴です。

本記事では、基幹システム/ERP更改における開発期間・スケジュール・納期について、保守契約の更新通知が届くタイミングから逆算した意思決定リードタイム、ハードウェアリース満了・ERPバージョンアップサイクルが生むスケジュール制約、「そのまま延長保守を契約するか、この機会に更改に踏み切るか」を判断する意思決定プロセスと必要な検討期間、そして契約期限からの逆算に伴う更改特有の納期遅延要因と対策までを体系的に解説します。移行アプローチ別の技術的な期間の違いは基幹システム/ERPのモダナイゼーションの記事に、経営層への説明や全社合意形成に要する期間の詳細は基幹システム/ERP刷新の記事にそれぞれ譲り、本記事では「契約更新までに残された時間の中で、どうスケジュールを組み立てるか」という実務に焦点を当てます。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・基幹システム/ERP更改の完全ガイド

基幹システム/ERP更改とは何か（契約・ライフサイクル起点というトリガー）

基幹システム/ERP更改の開発期間を検討する前に、本記事が扱う論点の位置づけと、更改を引き起こす3つの外圧トリガーを整理しておく必要があります。

「基幹システム/ERPのモダナイゼーション」は移行アプローチという技術手法の選定を、「基幹システム/ERP刷新」は稟議・全社合意形成という経営判断のプロセスを、それぞれ主軸に据えています。これに対し本記事が扱う基幹システム/ERP更改は、保守サポート契約の満了、ハードウェアのリース満了、ERPパッケージのバージョンアップという、企業側の経営判断とは独立して外部から到来する期限を出発点とします。更改は「守りのIT投資」として、現状の業務プロセスを変えずに新しいインフラへ載せ替えるだけで完結するケースも少なくありませんが、この契約更新のタイミングこそが、技術手法（モダナイゼーション）や経営判断（刷新）に踏み込む絶好の機会でもあります。開発期間・スケジュールを検討する際は、まずこの「外圧型トリガーに対応するための期間」という性質を正しく認識することが出発点になります。

基幹システム/ERP更改を引き起こす期限は、大きく3種類に分類できます。1つ目は保守サポート契約の満了で、多くの場合1年単位の自動更新となっており、契約満了の3〜6ヶ月前にベンダーから次年度の見積書とともに更新通知が届くのが実務上の通例です。2つ目はオンプレミスサーバーなどハードウェアのリース満了で、税法上の法定耐用年数に合わせて4年または5年のリース契約が組まれるのが一般的です。3つ目はERPパッケージのバージョンアップサイクルで、軽微なマイナーバージョンアップは年1〜数回、アーキテクチャの変更を伴うメジャーバージョンアップは数年サイクルで発生します。SAP ECC6.0の2027年問題（EHP5以下は2025年12月末で標準保守終了済み、EHP6以上は2027年末に標準保守終了予定）は、この3つのトリガーが同時期に重なる象徴的な事例であり、開発期間の見積もりはこれら複数の期限を一枚のカレンダーに落とし込むところから始まります。

保守契約更新通知から逆算する意思決定リードタイム

保守契約の更新通知が届いてから検討を始めたのでは、開発期間を十分に確保できません。契約更新のタイミングから逆算したリードタイムの設計が、更改プロジェクト最大の勘所です。

保守サポート契約は1年単位の自動更新であることが大半で、契約を終了・見直す場合は満了の3ヶ月前（契約によっては1ヶ月前）までに申し出るという解約通知期限が設けられているケースが一般的です。このため、ベンダーからの契約更新通知（次年度の見積書提示など）は契約満了の3〜6ヶ月前に届くのが実務上の通例ですが、この通知が届いてから更改の検討を始めては、開発期間を十分に確保できません。システム更改は、小規模なシステムでも数ヶ月、大規模で複雑な基幹システムであれば1年以上を要することも珍しくないため、契約満了（リース切れ・保守切れ）の1〜2年前からITロードマップを描き、検討を始めておくのが実務上の理想とされています。通知が届く3〜6ヶ月前というタイミングは、あくまで「意思決定を確定させ、発注に踏み切るための最終リミット」として位置づけ、実質的な検討はその1年以上前から並行して進めておく必要があります。

SAP ECC6.0を利用している企業にとって、2027年問題は開発期間の設計における最も具体的な締め切りです。EHP5以下のバージョンは2025年12月末で標準保守がすでに終了しており、EHP6以上のバージョンも2027年末に標準保守が終了する予定です。一定の条件（拡張保守費用の追加支払いなど）を満たせば2030年末まで延長保守を受けることも可能ですが、これはあくまで一時的な延命措置であり、いずれ更改は避けられません。この期限から逆算すると、S/4HANAへの移行や他社ERPへの更改を完了させたい場合、上流工程（現状アセスメント〜方針決定）だけで4〜7ヶ月、段階的実装に6〜18ヶ月を要する一般的な期間感（基幹システム/ERPのモダナイゼーションの記事参照）を踏まえれば、標準保守終了の1年〜数年前には検討に着手しておく必要があり、延長保守の期間はあくまで「更改の準備期間を確保するためのバッファ」として活用するのが現実的なスケジュール設計になります。

ハードウェアリース満了・バージョンアップサイクルが生むスケジュール制約

契約更新は保守サポートだけでなく、ハードウェアのリースやERPパッケージ自体のバージョンアップサイクルとも密接に絡み合い、それぞれ異なるスケジュール制約を生みます。

オンプレミスサーバーなどIT機器のリース契約は、税法上の法定耐用年数に合わせて4年または5年で組まれるのが一般的で、コスト比較の観点でも5年間のTCO（総所有コスト）で比較するのが一つのライフサイクルの目安とされています。リース満了時の選択肢は大きく3つに分かれ、それぞれ準備期間が異なります。1つ目の再リースは同じ機器を継続使用する方法で、リース料は当初の1/10程度と格安になる一方、メーカーの保守期限が切れると故障時に修理対応ができなくなるリスクを抱えるため、準備期間は短くて済む代わりに延命措置に過ぎません。2つ目の買取は残存価値で機器を買い取り自社資産化する方法で、契約形態によっては選択できない場合もあります。3つ目の更改（リプレース）は旧機器を返却し新機器で新規リース契約を結んでシステムを移行する方法で、新環境の選定・調達・移行にまとまった期間を要するため、リース満了の1年以上前から検討を開始しておく必要があります。

ERPパッケージのバージョンアップサイクルは、保守契約の更新サイクルやハードウェアのリースサイクルと必ずしも一致しません。マイナーバージョンアップは年1〜数回のペースで提供される一方、アーキテクチャの変更を伴うメジャーバージョンアップは数年サイクルで発生するため、保守契約は1年ごとに更新していても、実際に大規模な更改判断を迫られるのはメジャーバージョンアップのタイミングに限られるという企業も少なくありません。厄介なのは、保守契約の更新時期・ハードウェアリースの満了時期・ERPのメジャーバージョンアップ時期という3つのサイクルが、企業ごとにバラバラのタイミングで到来する点です。このズレを放置すると、ハードウェアだけ更新してソフトウェアは旧バージョンのまま、といった中途半端な更改を繰り返すことになりかねません。開発期間・スケジュールを検討する段階で、これら3つのカレンダーを一元管理し、次に更改の好機が訪れるタイミングを可視化しておくことが、長期的な更改計画の精度を左右します。

「そのまま延長するか、更改に踏み切るか」の意思決定プロセスと期間

契約更新通知を受けて、企業がまず下すべき最初の意思決定は「延長保守を選ぶか、更改に踏み切るか」です。この判断にかかる期間そのものが、開発期間全体のスケジュールを左右します。

延長保守を契約するか更改に踏み切るかの判断は、主に3つの基準で行われます。1つ目は老朽化リスクで、メーカーの保守期限切れによりシステム障害が発生した際に業務へ及ぼす影響をどこまで許容できるかという観点です。2つ目はコストの妥当性で、延長保守にかかる追加費用と、新システムを導入した場合の5年間TCOを比較して判断します。3つ目はビジネス要件で、レガシー化した現行システムが現在のDX推進のボトルネックになっていないかという観点です。これら3つの基準を整理し経営層の判断を仰ぐプロセスには、小規模なシステムでも数ヶ月、大規模で複雑な基幹システムであれば1年以上を要することも珍しくなく、この判断そのものの期間を開発期間の見積もりに織り込んでおかなければ、契約更新通知が届いてから慌てて延長保守を選ばざるを得なくなるという事態を招きます。

更改に踏み切るという判断が固まった後は、要件整理、ベンダー・新システムの選定、移行、並行稼働という標準的な流れでプロジェクトを進めます。上流工程（現状アセスメント・目標設定・方針決定とベンダー選定）だけで合計4〜7ヶ月程度、段階的な実装フェーズは移行アプローチによって6〜18ヶ月程度、稼働後の定着化フェーズにも6〜12ヶ月程度を要するのが一般的な目安です（技術的な工程配分の詳細は基幹システム/ERPのモダナイゼーションの記事を参照してください）。更改の場合、この標準スケジュールに加えて、旧ハードウェアの返却・撤去、旧保守契約の解約手続きといった契約実務上のタスクも並行して管理する必要があり、これらの契約手続きにかかる期間を見落とすと、システムの移行自体は完了していても契約上の整理が追いつかず、二重に費用が発生する期間が生じるといった実務的なトラブルにつながります。

更改特有の納期遅延要因と対策

更改プロジェクトには、モダナイゼーションや刷新とは異なる、契約期限に起因する特有の遅延要因が存在します。

更改プロジェクトの最大の遅延要因は、契約満了日という動かせない期限から逆算してスケジュールを引いた結果、想定外の事態に対応するためのバッファが十分に確保できないことです。基幹システムはデータ移行の検証だけでも数ヶ月を要することがあり、従業員200名規模の商社で20年分の顧客データが複数システムに分散していたため事前のデータ統合作業だけで4ヶ月を要した事例もあります。契約満了日を起点に必要な工程を積み上げていくと、テストや並行稼働の期間が真っ先に削られがちですが、基幹システムは会計・税務処理の中核を担うため、検証を安易に省略すると本番稼働後に決算処理そのものに支障が出るリスクがあります。契約更新の1〜2年前から検討を始めておくべきなのは、まさにこの逆算スケジュールにバッファを確保するためです。

更改プロジェクトの納期を守るための実務としては、まず契約更新通知を待たずに、契約満了の1〜2年前から検討に着手することが最も効果的な対策です。それでも準備期間が不足する場合は、延長保守（再リースを含む）を「更改の準備期間を確保するための一時的なブリッジ」として明確に位置づけたうえで契約し、その延長期間中に着実に更改プロジェクトを進めるという段取りも現実的な選択肢です。また、全モジュールを一度に切り替える「ビッグバン方式」は障害発生時のリスクが大きいため、業務影響の小さい周辺モジュールや拠点から段階的に移行するトランシェ方式・インクリメンタル方式を採用し、全体工程には10〜20%程度のリスクバッファを組み込んでおくことも、契約期限という動かせない制約の中で納期を守るための実務上の要諦です。

まとめ

本記事では、基幹システム/ERP更改における開発期間・スケジュール・納期について、契約・ライフサイクル起点という位置づけ、保守契約更新通知から逆算する意思決定リードタイム、ハードウェアリース満了・バージョンアップサイクルが生むスケジュール制約、「延長か更改か」の意思決定プロセスと期間、そして更改特有の納期遅延要因と対策までを体系的に解説しました。保守サポート契約は満了の3〜6ヶ月前に更新通知が届くのが通例ですが、大規模な基幹システムの更改には1年以上を要することも珍しくないため、契約満了の1〜2年前からITロードマップを描き検討を始めておくことが欠かせません。移行アプローチ別の技術的な期間の違いは基幹システム/ERPのモダナイゼーションの記事に、経営層への説明や全社合意形成の詳細は基幹システム/ERP刷新の記事にそれぞれ譲るとして、本記事で強調したいのは、更改という契約更新のタイミングこそが、守りのIT投資で終わらせるか、攻めのモダナイゼーション・刷新に転じるかを見極める貴重な分岐点であるという点です。次の契約更新まで手をこまねくのではなく、早めに専門家に相談し、余裕を持ったスケジュールで判断することをお勧めします。

▼全体ガイドの記事
・基幹システム/ERP更改の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。