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

システム更改とは、稼働中のシステムを新しい環境へ作り替えるという結果だけを見れば「システム刷新」や「システムのモダナイゼーション」と同じに見えますが、開発期間・スケジュール・納期を検討するうえで決定的に異なるのが、着手のきっかけです。システム刷新が経営層の内発的な意思決定で始まるのに対し、システム更改は保守サポート契約の満了時期、ハードウェアのリース期限、ベンダーが定めるEnd of Support・End of Life（EOS/EOL）という、自社の都合とは無関係に到来する「外部から強制される期限」がトリガーになります。この期限は先延ばしができないため、開発期間の検討は「理想のスケジュールをどう組むか」ではなく「決められた期限から逆算して、いつまでに何を終えなければならないか」という発想に立つ必要があります。

本記事では、システム更改の開発期間・スケジュール・納期に焦点を当て、契約満了・リース満了・EOS/EOLという期限がなぜ発生し、いつまでに更新か更改かの方針を決めるべきかという判断のリミット、期限から逆算した工程別の期間配分、残存期間が短い場合の短納期での進め方、そして期限に間に合わなかった場合のリスクと対策までを、具体的な数値とともに体系的に解説します。保守契約の更新通知やベンダーからのEOS/EOL通知をすでに受け取っている方はもちろん、自社システムがいつ期限を迎えるのか把握しきれていない方にとっても、期限管理の視点からスケジュールを描くための判断軸が身に付く内容です。

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

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

システム更改の開発期間を左右する前提（契約・ライフサイクル起点という位置づけ）

システム更改の開発期間を正しく見積もるための出発点は、着手のきっかけが「経営としてどう変えたいか」ではなく「契約・ライフサイクル上、いつまでに対応しなければならないか」という外部要因にある点を理解することです。保守サポート契約には満了日が定められており、サーバーなどのハードウェアにはリース期間の終了時期があり、OSやミドルウェア、パッケージ製品にはベンダーが公表するEOS/EOLの日付があります。これらはいずれも自社の意思で延期できるものではなく、期限が到来した瞬間にサポートが受けられなくなる、あるいは機器の使用そのものが継続できなくなるという性質を持ちます。開発期間の計画は、この動かせない期限から逆算するところから始まります。

システム更改を引き起こす期限は大きく3種類に整理できます。1つ目は保守サポート契約の満了で、ベンダーとの間で締結している保守契約には必ず契約期間が定められており、更新するか終了するかを契約満了前に決めておく必要があります。2つ目はハードウェアのリース満了で、サーバーやネットワーク機器の多くはリース契約で導入されており、リース期間が終わるタイミングで継続・買い取り・入れ替えのいずれかを選ばなければなりません。3つ目はベンダーが公表するEOS/EOLで、OS・ミドルウェア・パッケージ製品の提供元がサポート終了日を一方的に告知するもので、この日を過ぎるとセキュリティパッチの提供が止まり、障害時のサポートも受けられなくなります。この3つの期限のうち最も早く到来するものが、実質的な更改プロジェクトのデッドラインになります。

姉妹記事「システム刷新」は、なぜ・いつ刷新に踏み切るかという経営判断とプロジェクト推進のプロセスに、「システムのモダナイゼーション」はリホスト・リプラットフォーム・リファクタリング・リビルド・リプレースという5つの技術的アプローチの使い分けに、それぞれ重心を置いています。本記事が扱うシステム更改は、この2つのどちらとも異なり、契約満了・リース満了・EOS/EOLという「外部から強制される期限をどう管理し、その期限内に開発・移行を終えるか」という期限管理の視点に焦点を絞ります。技術手法の詳細や経営判断のプロセスそのものを詳しく知りたい方は、両姉妹記事の完全ガイドをあわせてご参照ください。本記事では、期限が確定している前提での現実的なスケジュールの組み方に絞って解説を進めます。

契約満了までの判断リミットと逆算スケジュール

期限が確定している以上、システム更改のスケジュールは「いつから始めるか」ではなく「いつまでに方針を決め、いつまでに終えるか」という逆算思考で組み立てる必要があります。ここでは、方針決定のリミットと、確定したスケジュールを工程別に分解した際の期間配分を見ていきます。

保守契約やリース契約の更新通知は、一般的に契約満了の3〜6ヶ月前に届きます。しかしこの通知を受け取ってから「そのまま更新するか、更改に踏み切るか」を検討し始めたのでは、実装フェーズだけで数ヶ月から1年以上を要する更改プロジェクトには到底間に合いません。実務上は、契約満了の1年〜1年半前、対象が大規模な基幹システムであれば2年前の時点で、更新するか更改するかの方針決定そのものを完了させておくことがリミットになります。ベンダーが公表するEOS/EOLについても、通知はサポート終了の1〜3年前になされるのが一般的で、通知を受け取った時点で直ちに業務影響度とセキュリティリスクを評価し、更改プロジェクトを立ち上げるか第三者保守で延命するかを判断する必要があります。この判断リミットを見誤ることが、更改プロジェクトが後手に回る最大の原因です。

方針が決まった後の標準的な更改プロジェクトは、大きく4つの工程に分解できます。現状分析・企画・ベンダー選定に約2〜3ヶ月、業務フローの整理や機能・非機能要件を固める要件定義に約3〜4ヶ月、基本設計・詳細設計・プログラミングを行う設計・開発に約4〜6ヶ月、単体・結合・総合テストからユーザー受け入れテスト（UAT）、データ移行リハーサル、本番稼働までのテスト・データ移行・UATに約3〜5ヶ月が目安で、合計すると大規模な基幹系システムでは12〜18ヶ月程度を要します。期限が明確な更改では、この最終工程であるテスト・移行フェーズの完了日を確定の期限日に固定し、そこから要件定義・設計開発の各工程の締切を逆算して割り振る「タイムボックス型」のスケジュール管理が欠かせません。

残存期間が短い場合の短納期進行術

判断リミットを過ぎてしまった、あるいは方針決定に想定以上の時間がかかってしまい、標準的な工程別期間では契約満了に間に合わない場合も実務では珍しくありません。ここでは、残存期間が短い状況で納期を守るための具体的な短縮策を解説します。

短納期での更改を実現する最も有効な手段は、SaaSやパッケージ製品を導入する際、自社の業務にあわせてシステムをカスタマイズするのではなく、業務プロセスの方をシステムの標準機能に合わせる「Fit to Standard」を徹底することです。追加開発を最小限に抑えることで、最も時間のかかる設計・開発とテストの期間を大幅に短縮できます。あわせて、データ移行の粒度を見直すことも有効な短縮策です。過去の全データを新システムへ移行しようとすると工数と難易度が跳ね上がるため、更新頻度の低い過去データはPDF等でそのまま参照可能な形式にとどめる「簡易移行」としたり、新システムには移行せず既存のファイルサーバーで継続管理する「移行対象外」として割り切ったりすることで、移行にかかる時間を圧縮できます。

残存期間が短い場合、人的リソースの投入量を増やして期間を圧縮するという選択肢も検討に値します。要件定義などの上流工程や大規模な設計部分は実績のあるSIerに任せつつ、アプリケーション開発やテストといった下流工程の小規模な部分には、柔軟に契約できるフリーランスエンジニアやSES（システムエンジニアリングサービス）を組み合わせて増員するハイブリッドな体制を組むことで、リソース不足を解消しスケジュールを加速させることができます。ただし増員による並行作業はコミュニケーションコストの増加や品質のばらつきを招くリスクもあるため、増員する範囲を影響の小さい周辺機能に限定し、コア業務のロジックは経験豊富な少数精鋭のチームに集中させるという役割分担が、短納期下での品質確保の鍵になります。

期限に間に合わなかった場合のリスクと対策

短縮策を尽くしてもなお契約満了やEOS/EOLの期限に間に合わない可能性がある場合、あらかじめリスクと対策を把握しておくことが、最悪の事態を回避するために欠かせません。

メーカーの保守期限が切れた状態でシステムを使い続けると、万が一障害が発生してもベンダーからのサポートを受けられず、業務が長期間停止するという深刻な事態に陥りかねません。加えて、EOS/EOLを超過したOSやミドルウェアには最新のセキュリティパッチが提供されなくなるため、マルウェア感染や不正アクセスといったサイバーリスクが年々高まっていきます。リース契約についても同様で、満了後にそのまま機器を使い続けると、故障時の修理費が全額自己負担になったり、交換部品が入手できず修理そのものが不可能になったりするリスクを抱えることになります。これらのリスクは更改の完了が遅れれば遅れるほど積み上がっていくため、期限超過は「単なるスケジュール遅延」では済まされません。

更改の完了が期限に間に合わないことが確定した場合の有効な対策の1つが、メーカーの保守期限が切れた機器であってもサポートを提供してくれる「第三者保守サービス」の活用です。第三者保守を利用することで、新システムが稼働するまでの猶予期間を安全に確保し、リスクを抑えながら延命できます。あわせて、システム全体を一斉に切り替える一括移行（ビッグバン方式）が困難な場合は、特定の部門や機能のみを先行して新システムへ移行する「パイロット移行」や、機能ごとに順次切り替える「段階移行」へと計画を切り替えることも有効です。さらに、本番移行が予定通りに終わらない、あるいは致命的なデータ不整合が発覚した場合に備えて、即座に旧環境へ切り戻す「ロールバック計画（コンティンジェンシープラン）」を事前に策定し、移行リハーサルの中で実効性を確認しておくことが、最悪の事態を防ぐ最後の保険になります。

依頼先選定・契約形態が納期順守に与える影響

期限が動かせない更改プロジェクトでは、どのパートナー企業にどのような契約形態で依頼するかが、納期順守の成否を大きく左右します。発注前に確認しておくべきポイントを整理します。

依頼先を選定する際にまず確認すべきは、期限管理を伴う更改プロジェクトそのものの実績です。EOS/EOL対応や保守契約満了に伴う移行案件をどれだけ手掛けてきたか、類似規模・類似業種での更改を期限内に完了させた実績があるかを具体的な数値とともに確認することが重要です。第三者保守サービスの活用実績や、Fit to Standardによる短納期導入の実績を持つパートナーであれば、残存期間が限られた状況でも現実的な選択肢を提示してもらいやすくなります。契約前の提案段階で、想定される工程別スケジュールと、遅延が発生した場合の代替案（段階移行への切り替えや第三者保守の手配など）をどこまで具体的に描けているかを確認することが、期限内に完了できるパートナーかどうかを見極める実務上の目安になります。

契約形態についても、期限を前提とした更改案件ならではの取り決めが必要です。要件が明確に固まっている移行であれば成果物の完成責任を伴う請負契約が適していますが、期限までの時間が限られ探索的に進めざるを得ない部分がある場合は準委任契約を組み合わせるハイブリッドな契約形態も検討に値します。契約書には、納品物の定義や検収条件に加えて、万が一期限内に完了しなかった場合の対応（段階移行への切り替えや第三者保守の手配責任の所在）、ロールバック計画の策定と実施をどちらの責任で行うかまでを明記しておくことが、期限直前でのトラブルを防ぐ実務上のポイントです。発注者側が用意すべき協力工数（現行システムの資料提供、移行リハーサルへの参加）も契約前にすり合わせておくことで、後半になってからのリソース不足による遅延を防げます。

まとめ

本記事では、システム更改の開発期間・スケジュール・納期について、契約・ライフサイクル起点という位置づけ、契約満了までの判断リミットと逆算スケジュール、残存期間が短い場合の短納期進行術、期限に間に合わなかった場合のリスクと対策、依頼先選定・契約形態が納期順守に与える影響を体系的に解説しました。システム更改の開発期間を見誤らない鍵は、これを保守契約満了・リース満了・EOS/EOLという動かせない期限から逆算するプロジェクトだと理解することにあります。方針決定は契約満了の1年〜1年半前、大規模なら2年前がリミットで、標準的な工程は合計12〜18ヶ月程度、残存期間が短い場合はFit to Standardとハイブリッド体制で圧縮し、それでも間に合わない場合は第三者保守による延命とロールバック計画で最悪の事態を回避することが実務の要になります。経営判断のプロセスや技術手法の詳細については、姉妹記事「システム刷新」「システムのモダナイゼーション」もあわせてご参照ください。

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

株式会社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を創業。