基幹システム/ERP更改の開発期間は、保守契約・ハードウェアリース・ERPの更新時期という期限から逆算して決めます。
期限は会社の都合では動かせないため、延長保守か更改かの判断、契約期限までの開発と移行、納期遅れへの備えを、早い段階から見積もる必要があります。
このテーマの全体像は、以下の記事で扱っています。
▼全体ガイドの記事
・基幹システム/ERP更改の完全ガイド
契約更新通知の時期、ハードウェアリースの満了、ERPのバージョンアップ周期を起点にすれば、残された時間からスケジュールを逆算できます。その際は、技術的な移行手法や経営層の合意形成とは分けて考えます。
基幹システム/ERP更改とは、会計、人事給与、生産管理、販売管理、在庫管理といった全社基盤システムを対象にする取り組みです。きっかけは、保守サポート契約の満了、ハードウェア（オンプレミスサーバー）のリース満了、ERPパッケージのバージョンアップの節目といった「契約・ライフサイクル起点の期限」です。そのうえで、そのまま延長するか作り替えるかを判断し、実行します。
同じ基幹システム/ERPの話題でも、役割は分かれています。「基幹システム/ERPのモダナイゼーション」は、グリーンフィールド、ブラウンフィールド、ブルーフィールドといった移行アプローチの選び方に代表される、どう技術的に刷新するかというHOWを扱います。一方で「基幹システム/ERP刷新」は、経営層がなぜ、いつ刷新に投資すべきかという経営判断（WHY/WHEN）を扱います。
これに対して本記事が扱う更改は、保守契約の更新通知やハードウェアリースの満了通知が届き、企業の意思とは関係なく外部から期限がやってくることに、どう向き合うかが中心です。その点を、「契約起点のWHEN」として扱います。
ゼロから基幹システムを構築する「基幹システム開発」や「ERP導入」とは異なります。一方で、既に稼働している老朽化した基幹システムを前提とする点は、モダナイゼーションや刷新と共通しています。更改の最大の特徴は、良くも悪くも「待ったなし」で判断を迫られる契約実務である点です。
- 更改の期限と判断条件
- 必要な工程と検証範囲
- 依頼先と実行体制
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
基幹システム/ERP更改の定義（契約・ライフサイクル起点というトリガー）
開発期間を検討する前に、本記事が扱う論点の位置づけと、更改を引き起こす3つの外圧トリガーを押さえておく必要があります。
モダナイゼーション・刷新との違い（契約起点という第三の観点）
「基幹システム/ERPのモダナイゼーション」は移行アプローチという技術手法の選定を、「基幹システム/ERP刷新」は稟議や全社合意形成という経営判断のプロセスを、それぞれ主軸に据えています。
本記事が扱う更改は、保守サポート契約の満了、ハードウェアのリース満了、ERPパッケージのバージョンアップといった、企業の判断とは関係なく外部から到来する期限を出発点にします。更改は「守りのIT投資」として、現状の業務プロセスを変えずに新しいインフラへ載せ替えるだけで完結するケースも少なくありません。
一方で、この契約更新のタイミングは、技術手法（モダナイゼーション）や経営判断（刷新）に踏み込む絶好の機会でもあります。そのため、開発期間やスケジュールの検討は、まず「外圧型トリガーに対応するための期間」という性質を正しく認識することから始まります。
保守契約更新・ハードウェアリース満了・バージョンアップサイクルという3つの外圧トリガー
基幹システム/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の2027年問題を起点にしたスケジュール設計
SAP ECC6.0を利用している企業にとって、2027年問題は開発期間の設計で最も具体的な期限です。EHP5以下のバージョンは2025年12月末で標準保守がすでに終了しており、EHP6以上のバージョンも2027年末に標準保守が終了する予定です。
一定の条件（拡張保守費用の追加支払いなど）を満たせば、2030年末まで延長保守を受けることも可能です。ただし、これはあくまで一時的な延命措置であり、いずれ更改は避けられません。標準保守終了の期限から逆算すると、S/4HANAへの移行や他社ERPへの更改を完了させたい場合は、期間の目安を押さえておく必要があります。
上流工程（現状アセスメント〜方針決定）だけで4〜7ヶ月、段階的な実装に6〜18ヶ月を要するのが一般的な期間感です（基幹システム/ERPのモダナイゼーションの記事参照）。そのため、標準保守終了の1年〜数年前には検討に着手しておき、延長保守の期間は「更改の準備期間を確保するためのバッファ」として活用するのが現実的なスケジュール設計になります。
ハードウェアリース満了・バージョンアップサイクルが生むスケジュール制約
契約更新は、保守サポートだけでなく、ハードウェアのリースやERPパッケージ自体のバージョンアップサイクルとも密接に関わり、それぞれ異なるスケジュール上の制約を生みます。
サーバーリース4〜5年サイクルと選択肢別に異なる準備期間
オンプレミスサーバーなどIT機器のリース契約は、税法上の法定耐用年数に合わせて4年または5年で組まれるのが一般的です。コスト比較の観点でも、5年間のTCO（総所有コスト）で比べるのが、ライフサイクルの一つの目安とされています。リース満了時の選択肢は大きく3つあり、準備期間もそれぞれ異なります。
1つ目の再リースは同じ機器を継続して使う方法で、準備期間は短くて済みます。リース料は当初の1/10程度と格安ですが、メーカーの保守期限が切れると故障時に修理対応ができなくなるリスクを抱え、延命措置に過ぎません。2つ目の買取は、残存価値で機器を買い取り自社資産化する方法で、契約形態によっては選べない場合もあります。
3つ目の更改（リプレース）は、旧機器を返却し新機器で新規リース契約を結んでシステムを移行する方法です。新環境の選定・調達・移行にまとまった期間を要するため、リース満了の1年以上前から検討を開始しておく必要があります。
ERPパッケージのバージョンアップサイクルと保守契約更新タイミングのズレ管理
ERPパッケージのバージョンアップサイクルは、保守契約の更新サイクルやハードウェアのリースサイクルと必ずしも一致しません。厄介なのは、保守契約の更新時期、ハードウェアリースの満了時期、ERPのメジャーバージョンアップ時期という3つのサイクルが、企業ごとにバラバラのタイミングで到来する点です。
マイナーバージョンアップは年1〜数回のペースで提供される一方、アーキテクチャの変更を伴うメジャーバージョンアップは数年サイクルで発生します。そのため、保守契約を1年ごとに更新していても、大規模な更改判断を迫られるのはメジャーバージョンアップの時期に限られる企業も少なくありません。
このズレを放置すると、ハードウェアだけ更新してソフトウェアは旧バージョンのまま、といった中途半端な更改を繰り返すことになりかねません。そこで、開発期間・スケジュールを検討する段階で、これら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更改の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。