システム更改の開発期間・スケジュール・納期は、保守契約やリースの満了、EOS/EOLといった外部の期限から逆算して決めます。標準的な工程を合計すると、大規模な基幹系システムでは12〜18ヶ月程度が目安になります。期限は先延ばしできないため、いつまでに何を終えるかを先に押さえます。
▼全体ガイドの記事
・システム更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
システム更改の開発期間を左右する前提（契約・ライフサイクル起点という位置づけ）
システム更改の開発期間を正しく見積もるには、着手のきっかけを確かめることが出発点になります。きっかけは「経営としてどう変えたいか」ではなく、「契約やライフサイクル上、いつまでに対応しなければならないか」という外部要因です。
保守サポート契約には満了日があり、サーバーなどのハードウェアにはリース期間の終了時期があります。さらに、OSやミドルウェア、パッケージ製品には、ベンダーが公表するEOS/EOLの日付があります。
これらの期限は、どれも自社の判断で延ばせません。期限を過ぎた時点で、サポートを受けられなくなるか、機器を使い続けられなくなります。
そのため、開発期間の計画は、この動かせない期限から逆算するところから始まります。
保守契約満了・リース満了・EOS/EOLという「外部から強制される期限」
システム更改を引き起こす期限は、大きく3種類に整理できます。1つ目は、ベンダーとの保守契約の満了です。保守契約には必ず契約期間があり、満了の前に、更新するか終了するかを決めておく必要があります。
2つ目は、ハードウェアのリース満了です。サーバーやネットワーク機器の多くはリース契約で導入されており、期間が終わるタイミングで、継続・買い取り・入れ替えのいずれかを選ばなければなりません。
3つ目は、ベンダーが公表するEOS/EOLです。OS・ミドルウェア・パッケージ製品の提供元が一方的に告知するサポート終了日で、この日を過ぎるとセキュリティパッチが止まり、障害時のサポートも受けられなくなります。3つの期限のうち最も早く到来するものが、実質的な更改プロジェクトのデッドラインになります。
「システム刷新」「システムのモダナイゼーション」との違いと本記事の焦点
姉妹記事の「システム刷新」は、なぜ・いつ刷新に踏み切るかという経営判断とプロジェクト推進のプロセスに重心を置いています。「システムのモダナイゼーション」は、リホストからリプレースまでの5つの技術的アプローチをどう使い分けるかが主題です。
一方で、本記事が扱うシステム更改はこの2つとは異なります。契約満了・リース満了・EOS/EOLという「外部から強制される期限」をどう管理し、その期限内に開発・移行を終えるかという、期限管理の視点から捉えます。
技術手法の詳細や経営判断のプロセスそのものを知りたい方は、両姉妹記事の完全ガイドもあわせてご覧ください。ここでは、期限が確定している前提で、現実的なスケジュールの組み方に絞って解説します。
契約満了までの判断リミットと逆算スケジュール
期限が確定している以上、システム更改のスケジュールは「いつから始めるか」ではなく、「いつまでに方針を決め、いつまでに終えるか」という逆算で組み立てる必要があります。まず方針決定のリミットを、次に工程ごとの期間配分を見ていきます。
更新通知のタイミングと方針決定のリミット（満了1年〜1年半前、大規模なら2年前）
保守契約やリース契約の更新通知は、一般的に契約満了の3〜6ヶ月前に届きます。しかし、この通知を受け取ってから「そのまま更新するか、更改に踏み切るか」を検討し始めたのでは、実装フェーズだけで数ヶ月から1年以上を要する更改プロジェクトには到底間に合いません。
実務上は、契約満了の1年〜1年半前、対象が大規模な基幹システムであれば2年前の時点で、更新するか更改するかの方針決定を終えておくことがリミットになります。また、ベンダーが公表するEOS/EOLについても、通知はサポート終了の1〜3年前になされるのが一般的です。
通知を受け取った時点で直ちに業務影響度とセキュリティリスクを評価し、更改プロジェクトを立ち上げるか、第三者保守で延命するかを判断する必要があります。特に、この判断リミットを見誤ることが、更改プロジェクトが後手に回る最大の原因です。
工程別の期間配分（現状分析〜テスト・移行・UATまで）
方針が決まったあとの標準的な更改プロジェクトは、大きく4つの工程に分けられます。現状分析・企画・ベンダー選定には約2〜3ヶ月、業務フローの整理や機能・非機能要件を固める要件定義には約3〜4ヶ月を見込みます。
設計・開発（基本設計、詳細設計、プログラミング）には約4〜6ヶ月かかります。テスト・移行（単体・結合・総合テストから、ユーザー受け入れテスト（UAT）、データ移行リハーサル、本番稼働まで）には約3〜5ヶ月が目安です。合計すると、大規模な基幹系システムでは12〜18ヶ月程度を要します。
期限が明確な更改では、最終工程であるテスト・移行フェーズの完了日を、確定の期限日に固定します。そのうえで、要件定義や設計・開発の締切を逆算して割り振る「タイムボックス型」のスケジュール管理が欠かせません。
残存期間が短い場合の短納期進行術
判断リミットを過ぎてしまった場合や、方針決定に想定以上の時間がかかった場合、標準的な工程別の期間では契約満了に間に合わないことも、実務では珍しくありません。ここでは、残存期間が短い状況で納期を守るための具体的な短縮策を解説します。
Fit to Standardによる追加開発抑制とデータ移行の簡易化
短納期の更改を実現するうえで最も有効なのは、SaaSやパッケージ製品の導入時に「Fit to Standard」を徹底することです。自社の業務に合わせてシステムをカスタマイズするのではなく、業務プロセスのほうをシステムの標準機能に合わせる考え方です。
追加開発を最小限に抑えれば、最も時間のかかる設計・開発とテストの期間を大幅に短縮できます。あわせて、データ移行の粒度を見直すことも有効な短縮策です。
過去の全データを新システムへ移そうとすると、工数と難易度が跳ね上がります。そこで、更新頻度の低い過去データは、PDFなどでそのまま参照できる形にとどめる「簡易移行」にするか、既存のファイルサーバーで継続管理する「移行対象外」にします。これにより、移行にかかる時間を圧縮できます。
SIer＋フリーランス・SESのハイブリッド活用によるリソース確保
残存期間が短い場合は、人的リソースの投入量を増やして期間を縮めるという選択肢も検討に値します。
要件定義などの上流工程や大規模な設計は、実績のあるSIerに任せます。そのうえで、アプリケーション開発やテストといった下流工程の小規模な部分には、柔軟に契約できるフリーランスエンジニアやSES（システムエンジニアリングサービス）を組み合わせます。こうした体制を組めば、リソース不足を解消し、スケジュールを加速させられます。
ただし、増員による並行作業は、コミュニケーションコストの増加や品質のばらつきを招くリスクがあります。そこで、増員は影響の小さい周辺機能に限り、コア業務のロジックは経験豊富な少数精鋭のチームに集中させる役割分担が、短納期での品質確保の鍵になります。
期限に間に合わなかった場合のリスクと対策
短縮策を尽くしても契約満了やEOS/EOLの期限に間に合わない可能性がある場合、あらかじめリスクと対策を把握しておくことが、最悪の事態を避けるために欠かせません。
EOS/EOL超過が招くサポート断絶・セキュリティリスク
メーカーの保守期限が切れたシステムを使い続けると、障害が起きてもベンダーのサポートを受けられず、業務が長期間止まる深刻な事態に陥りかねません。加えて、EOS/EOLを超えたOSやミドルウェアには最新のセキュリティパッチが提供されなくなり、マルウェア感染や不正アクセスといったサイバーリスクが年々高まります。
リース契約でも、満了後にそのまま機器を使い続けると、故障時の修理費が全額自己負担になったり、交換部品が入手できず修理そのものができなくなったりするリスクを抱えることになります。これらのリスクは、更改の完了が遅れるほど積み上がるため、期限超過は「単なるスケジュール遅延」では済まされません。
第三者保守による延命、段階移行・パイロット移行への切り替え
更改の完了が期限に間に合わないことが確定した場合、有効な対策の1つが「第三者保守サービス」の活用です。メーカーの保守期限が切れた機器でもサポートを提供してもらえるため、新システムが稼働するまでの猶予期間を安全に確保し、リスクを抑えながら延命できます。
あわせて、一括移行（ビッグバン方式）が困難なら、特定の部門や機能だけを先行させる「パイロット移行」や、機能ごとに順次移す「段階移行」へ計画を変えることも有効です。
さらに、本番移行が予定どおり終わらない場合や、致命的なデータ不整合が発覚した場合に備えて、即座に旧環境へ切り戻す「ロールバック計画（コンティンジェンシープラン）」を事前に策定します。移行リハーサルでその実効性を確認しておくことが、最悪の事態を防ぐための最後の備えになります。
依頼先選定・契約形態が納期順守に与える影響
期限が動かせない更改では、どの企業にどんな契約形態で依頼するかが、納期を守れるかどうかを大きく左右します。発注前に確認したいポイントを、順に見ていきます。
EOS/EOL対応・レガシー移行の実績を確認するポイント
依頼先を選ぶ際にまず確認すべきは、期限管理を伴う更改の実績です。EOS/EOL対応や保守契約満了に伴う移行案件をどれだけ手がけてきたか、類似規模・類似業種の更改を期限内に終えた実績があるかを、具体的な数値とともに確かめることが欠かせません。
加えて、第三者保守サービスの活用実績や、Fit to Standardによる短納期導入の実績があるパートナーなら、残存期間が限られていても現実的な選択肢を提示してもらいやすくなります。契約前の提案段階で、想定される工程別スケジュールと、遅延時の代替案（段階移行への切り替えや第三者保守の手配など）をどこまで具体的に描けているかを見ます。
これが、期限内に完了できる相手かを見極める実務上の目安になります。
ロールバック計画を含む契約前の確認事項
契約形態も、期限を前提とした更改案件ならではの取り決めが必要です。要件が明確に固まった移行であれば、完成まで責任を負う請負契約が適していますが、期限までの時間が限られ、探索的に進めざるを得ない部分があるなら、準委任契約を組み合わせる形も検討に値します。
契約書には、納品物の定義や検収条件に加えて、期限内に完了しなかった場合の対応を明記しておくことが、期限直前のトラブルを防ぐうえで欠かせません。具体的には、段階移行への切り替えや第三者保守の手配の責任の所在、ロールバック計画の策定と実施をどちらが担うかです。
発注者側が用意すべき協力工数（現行システムの資料提供や移行リハーサルへの参加）も、契約前にすり合わせておきます。そうすれば、後半になってからのリソース不足による遅延を防げます。
まとめ
本記事では、システム更改の開発期間・スケジュール・納期を、契約・ライフサイクル起点という位置づけから依頼先選定・契約形態まで順に解説しました。システム更改の開発期間を見誤らないためには、保守契約満了・リース満了・EOS/EOLという動かせない期限から逆算して組み立てるプロジェクトだと捉えておく必要があります。
方針決定のリミットは、契約満了の1年〜1年半前、大規模なら2年前です。標準的な工程は合計12〜18ヶ月程度を要します。残存期間が短い場合は、Fit to Standardとハイブリッド体制で圧縮し、それでも間に合わなければ、第三者保守による延命とロールバック計画で最悪の事態を避けることが実務の要になります。
経営判断のプロセスや技術手法の詳細については、姉妹記事「システム刷新」「システムのモダナイゼーション」もあわせてご参照ください。
▼全体ガイドの記事
・システム更改の完全ガイド
▼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を創業。
システム更改は、動かせない期限の日付を最初に確かめることから始まります。検討では、まず判断対象を外部期限、工程、リスクの3点に分けて確認します。
- 外部期限と判断リミットの把握
- 残存期間からの工程の逆算
- 契約・移行・延命に伴うリスクの管理