LASSIC Media らしくメディア
システムリプレイスのスケジュール｜保守期限から逆算する工程表
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- システムリプレイスのスケジュールは、サポート終了や保守契約の満了を右端に置き、さかのぼって着手日を決める工程表です。
- IPAの集計では再開発の開発5工程のうち製作の月数の比率が中央値26.2％と最も高く、全体の工期の中央値は10.1か月です。
- 延びやすいのは現行調査の不足とデータの準備なので、調査の期間と並行稼働の期間を先に工程表へ書き込みます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
「サポート終了まであと1年。今から始めて間に合うのか」「保守契約の更新を断られたが、どこから手を付ければよいのか」——。期限が先に決まっているリプレイスの現場では、こうした迷いが起こりがちです。システムリプレイスのスケジュールは、OSやミドルウェアのサポート終了、保守契約の満了といった期限を右端に置き、そこから工程をさかのぼって並べて、いつ何を始めるかを決める工程表です。
逆に組んだ工程表があれば、着手の遅れに早く気づけます。ただし万能ではなく、新規の導入と同じ並べ方では、リプレイスに特有の現行調査や並行稼働の期間が抜け落ちます。本記事では、リプレイスを初めて任された情報システムの担当者に向けて、工程ごとのやることと期間の目安、期限からの逆算の手順、延びやすい理由と手当て、そして外部に頼むときに確認したい点を整理します。
目次
システムリプレイスのスケジュールとは
IPA（情報処理推進機構）の「ソフトウェア開発分析データ集2022」は、開発の種別のうち「再開発」を、既存システムがあり、機能仕様をほとんど変えずに作り直す場合と定め、いわゆるリプレースやモダナイゼーションを含むとしています。*2 システムリプレイスでは期限が外から決まりやすく、IPAの「システム再構築を成功に導くユーザガイド 第2版」も、再構築のテーマの1つ目に、ハードウェアやソフトウェアの販売終了・サポート終了などへの対応を挙げています。*3
- OS・ミドルウェアのサポート終了：製品ごとに公表される日付です。Microsoftの固定ライフサイクルポリシーでは、最低5年間のメインストリームサポートがあり、一部の製品には延長サポートの期間が続きます*5
- ハードウェアの保守切れ：機器の保守の提供が終わる時期です。製造元の案内で確かめます
- 保守契約の満了：自社と保守会社のあいだの契約の期間です。更新できるかどうかも含めて、契約書と相手先に確かめます
例えばWindows Server 2016は、延長サポートの終了日が2027年1月と公表されています。*6 この日付を工程表の右端に置き、左へさかのぼって工程を並べると、左端に来た日付が「遅くともこの日までに始める日」になります。
工程ごとのやることと期間の目安
工程ごとの期間の数値は、IPAのデータ集にあります。2022年9月の公開で、企業から集めた5,546件のプロジェクトの実績をもとにしています。*1 再開発については、基本設計から総合テストまでの「開発5工程」がそろった40件で、工程ごとの月数が5工程の合計に占める比率が示されています。*2
| 工程 | やること | 期間の目安 | 延びやすい理由 |
|---|---|---|---|
| 現行調査 | 現行の機能・データ・運用・保守の状況を調べ、新しいシステムへ引き継ぐ範囲を決める | 決め手：設計書の残り具合と、現行を知る担当者がいるか | 普段は見えない部分まで調べ切れず、後の工程で手戻りが出る |
| 企画・要件定義 | 作り直す手法を選び、新しいシステムの要件を決める | 決め手：変えたい業務の範囲と、業務部門が参加できる頻度 | 要件を「今と同じ」で済ませ、後から食い違いが出る |
| 設計 | 基本設計と詳細設計を行う | 開発5工程の月数のうち、基本設計18.6％、詳細設計17.4％（中央値） | 作業の途中で現行システムの仕様が変わり、取り込み直す |
| 製作 | 設計に沿ってプログラムを作り直す | 同じく26.2％（中央値） | 移す資産の版がそろっておらず、どれを元にするかで迷う |
| テスト | 結合テストと総合テストで、現行と新しいシステムの結果を比べる | 結合テスト17.6％、総合テスト14.3％（中央値） | 完了の基準が決まっておらず、比べる作業が終わらない |
| データ移行 | データを整えて新しいシステムへ移し、リハーサルを行う | 決め手：データの量と、整える手間 | 不整合なデータの修正と、リハーサルのやり直し |
| 並行稼働・切替 | 一定期間、現行と新しいシステムの両方で同じ操作をして確かめ、切り替える | 決め手：利用部門が負担を受け止められる期間 | 期限までに並行稼働の期間を取れない |
再開発では製作の比率が26.2％と最も高く、データ集も、製作工程の比率が新規開発や改良開発に比べて高いと述べています。*2 比率は工程ごとに別々に求めた中央値なので、足しても100％にはなりません。現行調査、データ移行、並行稼働・切替は、何で期間が決まるかを書いています。自社の条件で見積もる部分です。
期限からどう逆算するのか
全体の期間の幅は、同じデータ集のプロジェクト全体の月数が手がかりになります。開発の種別を分けない1,396件で、中央値は10.1か月、短いほうから4分の1の位置は6.0か月、4分の3の位置は15.0か月でした。*2 期限まで1年を切ってから動き出すと、中央値の期間でも余裕がほとんど残りません。着手の日は次の4つのステップで決めます。
- ステップ1：期限の日付を確かめる。製品のサポート終了日、機器の保守切れ、保守契約の満了日のうち、いちばん早いものを右端に置く
- ステップ2：期限から並行稼働・切替とデータ移行の期間を引き、新しいシステムを仕上げておく日を決める
- ステップ3：そこから開発5工程の期間を引き、要件定義を終える日を決める
- ステップ4：さらに企画と現行調査の期間を引き、着手の日を決める
着手の日が今日より前になったら、期限のある部分だけを先に移すように範囲を分けるか、期限そのものを延ばせるかを確かめます。Microsoftの固定ライフサイクルポリシーでは、サポート終了の後のセキュリティ更新は、拡張セキュリティ更新プログラムを通じて受けられる扱いが示されています。*5 使えるかどうかは製品ごとに確かめます。
延びやすい理由と手当て
システムリプレイスの工程表が延びる理由には、新規の開発にはない型があります。IPAの2つの資料が取り上げている点を並べます。*3*4
| 理由 | 起きやすい工程 | 手当て |
|---|---|---|
| 現行調査が表面的 | 現行調査 | 普段目にしない部分も含めて調べる範囲を決め、調査に十分な時間を割り当てる |
| 要件が「今と同じ」 | 要件定義 | 現行の何を、どのような状態にしたいのかを要件定義の成果物にする |
| 現行システムの変更が続く | 設計〜テスト | 現行の仕様を確定させる時期を決め、それ以降の変更は追いつきの開発として扱う |
| テストの完了基準があいまい | テスト | 業務を続けられる条件を数値の基準にして、テストの前に合意する |
| 比べるデータの準備が遅れる | テスト・データ移行 | テストに使うデータを早めに用意し、移行のリハーサルを工程表に入れる |
見落とされやすいのはデータの準備です。ユーザガイドは、1年間のデータを日ごとに流して新旧の結果を確かめる場合、その分のデータを1年前から用意しておかなくてはならないとして、早めの検討を求めています。*3 並行稼働についても、利用部門がどれほど許容できるかと、現行システムのサポート終了の期限内で実施できるかを確かめるよう注意を促しています。*3
IPAの「デジタル変革に向けたITモダナイゼーション企画のポイント集」は、現行調査の結果が、適切なスケジュールとコストを確定させる要素になるとしています。*4 期限が迫っても、調査の期間は削らずに確保します。
外部に頼むときに確認しておきたい点
外部の事業者から工程表を受け取ったら、日数そのものより、期限と前提の置き方を確かめます。見積もりを比べるときも、次の項目で並べます。
- 範囲：現行調査、データ移行、並行稼働・切替まで工程表に入っているか
- 期限：サポート終了日や保守契約の満了日を右端に置き、そこからさかのぼって組んでいるか
- 体制：現行を知る社内の担当者と業務部門が、どの工程で確認に加わるか
- 費用の決まり方：調査の結果で範囲が変わったとき、費用と期間をどう決め直すか
- 引き継ぎ：切替の後の保守を誰が受け持ち、次の期限をどう管理するか
費用の内訳と見積もりの比べ方はシステムリプレイスの費用の内訳で、サーバーの入れ替えを外部に頼むときの進め方はサーバーリプレイスの外注で扱っています。
まとめ：システムリプレイスのスケジュールで確かめておきたい3つの点
システムリプレイスのスケジュールを組むうえで、確かめておきたい点は3つに整理できます。第一に、サポート終了日や保守契約の満了日のうち最も早いものを右端に置き、さかのぼって着手の日を決めること。第二に、現行調査・データ移行・並行稼働の期間を自社の条件で見積もって別の行に入れること。第三に、現行の仕様を確定させる時期と、テストの完了の基準を早めに決めておくことです。この3点を踏まえておけば、「切替の準備が終わらないまま、サポート終了の日を迎えた」という事態を避けやすくなります。期限に間に合うかの見立てに迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
OSのサポート終了と保守契約の満了がずれている場合、どちらを基準にしますか
早いほうを工程表の右端に置きます。早い期限を過ぎた部分から、更新や修正を受けられなくなるためです。期限ごとに対象の機器やソフトウェアを書き出しておくと、どこから移すかの順番も決めやすくなります。
並行稼働はどのくらいの期間を取ればよいですか
並行稼働の標準の期間は公表されていません。利用部門が二重の操作をどれだけ受け止められるかと、期限までに残る日数で決めます。月末や年度末の締めを並行稼働の中で確かめるかどうかも決め手です。
現行システムの設計書が残っていない場合、スケジュールはどう考えますか
現行調査の期間を長めに取ります。IPAのユーザガイドは、ソースコードや稼働ログの分析、現行と新しいシステムの処理結果の比較、ソースコードからの設計書の再生といった手段を挙げています。*3 どの手段を使うかを先に決めると、調査の期間を見積もりやすくなります。
システムリプレイスの計画づくりのご相談
現行調査から移行の計画、切替後の運用・保守まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。出典：公開日（2022年9月26日）と、5,546プロジェクトの定量データをもとにした分析であることの記述を参照（2026年10月確認）
- *2 参考：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集2022」本編（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：開発プロジェクトの種別の定義（c：再開発）、表1-3-3（プロジェクト全体の月数）、A3.3.5の注記（比率の合計は1にならない）、表A3-3-7（工程別の実績月数の比率（再開発）・N=40の中央値）を参照（2026年10月確認）
- *3 参考：独立行政法人情報処理推進機構（IPA）「システム再構築を成功に導くユーザガイド 第2版」（https://www.ipa.go.jp/archive/publish/secbooks20180223.html）。出典：2018年2月23日発行。表2.1 再構築のテーマ一覧、現行仕様の凍結タイミングと追いつき開発、テストの完了基準、データ移行とサイクルテストのデータ準備、表3.9 リスク対策の例（並行稼働）、現行システムの情報を補う手段の記述を参照（2026年10月確認）
- *4 参考：独立行政法人情報処理推進機構（IPA）「デジタル変革に向けたITモダナイゼーション企画のポイント集」（https://www.ipa.go.jp/archive/publish/qv6pgp000000117x-att/000063997.pdf）。出典：落とし穴2（「今と同じ」という要件定義）、落とし穴3（表面的な現行調査）のポイントとワンポイントアドバイスを参照（2026年10月確認）
- *5 参考：Microsoft「固定ライフサイクル ポリシー」（https://learn.microsoft.com/ja-jp/lifecycle/policies/fixed）。出典：最低5年間のメインストリームサポートと一部製品の延長サポート、サポート終了を超えたセキュリティ更新プログラム（拡張セキュリティ更新プログラム）の扱いの表を参照（2026年10月確認）
- *6 参考：Microsoft「Windows Server 2016 – Microsoft Lifecycle」（https://learn.microsoft.com/ja-jp/lifecycle/products/windows-server-2016）。出典：固定ライフサイクルポリシーに従うことと、延長サポートの終了日を参照（2026年10月確認）
