LASSIC Media らしくメディア
システム移行計画書に書く8つの項目｜体制から切り戻しまでのひな形
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- システム移行計画書は、移行の対象・方式・体制・日程・判定基準を関係者でそろえるための文書です。
- 8つの項目のうち、体制・日程・判定基準・切り戻しの4つはあいまいなまま残りやすい点です。
- 委託先が案を書く場合も、発注する側が中身を確かめ、移行の前に確定させます。
※ 本記事は2026年11月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
移行の日程は決めたのに、当日に誰が判断するのかが決まっていない。旧システムに戻すかどうかの線引きも、担当者の頭の中にしかない——。システムの入れ替えを控えた会社では、こうした詰め残しが起こりがちです。システム移行計画書は、移す対象・方式・体制・日程・判定の基準をまとめ、関係者が同じ前提で動けるようにするための文書です。
委託先に作ってもらう場合でも、発注する側が中身を読んで確定させる必要があります。ただし細かく書くほどよいわけではなく、作業の一つ一つは別の手順書に分けたほうが読みやすくなります。本記事では、システム移行を控えた情報システムの担当者に向けて、計画書に書く8つの項目、手順書やカットオーバー計画との違い、作る流れ、そして外部に頼むときに確認したい点を整理します。
目次
システム移行計画書とは
デジタル庁の標準ガイドライン解説書（DS-110）は、移行計画書の案を「移行の対象や方法、体制と役割、移行に必要となる環境、ツールとその概要、移行に関する準備作業及び実際の移行作業の内容とスケジュール等を計画書として記載したもの」と説明しています。*1 政府のシステム向けの文書ですが、民間のシステムの入れ替えでもそのまま目次の骨組みに使える内容です。
- 移す対象は、業務・システム・データの3つです（業務移行・システム移行・データ移行）*1
- 設計の段階で「案」を作り、開発やテストで変わった点を反映して、移行を始める前に確定させます
- 確定は遅くとも、データ移行・環境整備・本番移行の各段階が始まる前に、その段階の部分を済ませます
- 作業の一つ一つの手順は、計画書をもとに別の「移行手順書」に書きます
計画書が要るのは、移行そのものが業務に影響するからです。同じ解説書は移行のリスクの例として、作業中にサービスが止まる期間が出ること、連携先のシステムからつながらなくなること、データの一部が失われることを挙げています。*1 影響を受ける相手を先に洗い出し、手当てを計画に書いておくことが、計画書の役割です。
移行計画書に書く8つの項目
計画書の項目は、解説書の定義と、IPA（情報処理推進機構）の非機能要求グレードにある「移行性」の項目を合わせると、次の8つに整理できます。*2 ひな形として、この順に見出しを立てて埋めていくと抜けが出にくくなります。
| 項目 | 書く内容 | 決めておかないと起きやすいこと |
|---|---|---|
| 1. 目的と対象 | なぜ移すか。業務・システム・データのどれを、どこまで移すか | 移す物の漏れ、連携先の切り替え忘れ |
| 2. 移行方式と環境 | 一度に切り替えるか、段階的に移すか、新旧を並べて動かすか。使う環境とツール | 途中で方式が変わり、日程が組み直しになる |
| 3. 体制と役割分担 | 自社・委託先・現行システムの保守会社が受け持つ作業と、連絡の窓口 | 作業の押し付け合い、当日の判断の遅れ |
| 4. 日程と停止できる時間 | 準備から本番稼働までの日程、システムを止められる日時、戻すための時間 | 作業が時間内に終わらず、業務の開始に間に合わない |
| 5. データ移行と検証 | データの変換の決まり、不備データの直し方、件数と合計値の照合 | 移したデータの欠けや食い違いに気づかない |
| 6. リハーサル | 試す範囲、回数、使うデータと環境 | 本番で初めて手順の誤りが見つかる |
| 7. 移行判定の基準 | 本番移行に進むかを決める条件と、判断する人 | 「たぶん大丈夫」で進めてしまう |
| 8. 切り戻しの条件と手順 | どの状態になったら旧システムに戻すか、その手順と所要時間 | 戻すかどうかで迷い、止まる時間が長引く |
8つのうち、あいまいなまま残りやすいのは体制・日程・判定基準・切り戻しの4つです。非機能要求グレードは移行の日程について、切り戻しの時間や事前のバックアップの時間も含めて考えるよう求めています。*2 作業そのものの時間だけで日程を組むと、戻す時間が足りなくなるからです。
移行手順書やカットオーバー計画との違い
移行に関わる文書は、名前が似ていて役割の違いが分かりにくいものです。計画書は「何を・誰が・いつまでに・どの基準で」を決める文書で、作業の細かい手順は手順書に分けます。解説書でも、移行手順書は開発・テストの工程で作る文書として、計画書とは別に扱われています。*1
| 文書 | 書くこと | 作る時期 |
|---|---|---|
| 移行計画書 | 移行全体の対象・方式・体制・日程・判定基準・切り戻し | 設計の段階で案を作り、移行の前に確定 |
| 移行手順書 | 作業ごとの手順、使うツール、確かめ方 | 開発・テストの段階で、計画書をもとに作る |
| カットオーバー計画 | 本番を切り替える当日の段取り、判定の時刻、連絡の流れ | 本番移行の前に、計画書の切り替えの部分を細かくする |
計画書は移行全体の地図にあたり、切り替え当日の時間割はその一部です。当日の段取りの詰め方はシステム移行のカットオーバー計画で、データの移し方はシステム移行・データ移行を外注する進め方で扱っています。
移行計画書を作る流れ
計画書は、一度書いて終わりではなく、調べて・書いて・試して・直す順に育てていく文書です。IPAのシステム再構築のガイドも、移行する資産の棚卸しと移行性の分析を先に行い、その結果にもとづいて移行の方針を決め、移行計画を作る流れを示しています。*3 次の4つのステップで進めると、書き直しが少なくて済みます。
- ステップ1：現状を調べる（データの形、使っているコード、不備のあるデータ、連携先）
- ステップ2：8つの項目を埋めて計画書の案を作る
- ステップ3：リハーサルで手順と日程を試し、案を直す
- ステップ4：移行の前に計画書を確定させ、移行判定に使う
時間を取っておきたいのはステップ3です。解説書はリハーサルについて、できる限り本番と同じ環境・データ・手順・スケジュールで行い、複数回計画して結果を手順に反映するよう求めています。*1 本番移行に進むかの判定でも、移行計画書の内容とリハーサルの結果が適正であることが条件の一つに挙げられています。
外部に頼むときに確認しておきたい点
移行計画書の案は、開発を受けた委託先が書くことが多い文書です。それでも、非機能要求グレードは、最終的な移行結果の確認は作業分担にかかわらず発注する側（ユーザ）が行うとしています。*2 案を受け取ったら、次の点が書かれているかを確かめます。
- 作業分担：旧システムのデータの調査、抽出と変換、本番への投入と確認を、どちらが受け持つか*2
- 判定基準：「問題がないこと」で終わらず、件数の一致など誰が見ても同じ答えになる条件で書かれているか
- 切り戻し：戻す条件と方法が明確か。リハーサルで戻す手順まで試すか*1
- データの扱い：本番のデータをリハーサルに使ってよいか、使うならどう守るか
- 確定の手順：案を誰が直し、誰が承認して確定とするか
解説書は、移行判定の基準について、客観性があり、あいまいさを除いたものになっているかを確かめるよう示しています。*1 判定基準が言葉だけで書かれていたら、数で言い換えられないかを委託先と話し合っておくと、当日の判断で迷わずに済みます。
まとめ：移行計画書で確かめておきたい3つの点
システム移行計画書を作るうえで、確かめておきたい点は3つに整理できます。第一に、目的と対象から切り戻しまでの8つの項目を、見出しとしてそろえること。第二に、日程には作業の時間だけでなく、戻すための時間とバックアップの時間を入れること。第三に、移行判定の基準を誰が見ても同じ答えになる条件で書き、リハーサルの結果で直してから確定させることです。この3点を踏まえておけば、「当日になって、戻すかどうかを誰も決められなかった」という事態を避けやすくなります。計画書の作り方や中身の確かめ方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
移行計画書のテンプレートはありますか
決まった書式はありませんが、骨組みに使える公的な資料はあります。デジタル庁の解説書には、移行計画書を確かめるときの観点の例が、データの調査からリハーサル、移行判定、本番の切り替えまで表で載っています。*1 この表と本記事の8つの項目を見出しにして、自社の規模に合わせて書く量を調整すると作りやすくなります。
小さなシステムでも移行計画書は必要ですか
規模が小さくても、短い計画書を作っておくことをおすすめします。項目ごとに数行で足りますが、移行判定の基準と切り戻しの条件だけは省かないようにします。この2つが決まっていないと、問題が起きたときに止める・戻すの判断が遅れるからです。
移行計画書は誰が書くものですか
開発を受けた委託先が案を書き、発注する側が確認して確定させる形が一般的です。デジタル庁の解説書でも、発注側のプロジェクト管理の担当が委託先に案の作成を求め、内容を確かめて関係者と調整したうえで確定させる流れになっています。*1
システム移行計画書づくりのご相談
現行システムの調査から移行計画書の作成、リハーサルと移行判定の進め方まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：デジタル庁「DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf）。出典：第7章「4. 設計の実施・管理」の移行計画書の案の説明と移行リスクの例、「8. 移行の実施・管理」の移行計画書の確定・リハーサル・移行判定の記述、表7-5「移行計画書の確認観点の例」を参照（2026年11月確認）
- *2 参考：独立行政法人情報処理推進機構（IPA）「非機能要求グレード2018 改訂情報 ～初版との差異～」（付録 非機能要求グレード2018 活用シート）（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ps6vr700000077he-att/000066170.pdf）。出典：大項目「移行性」の移行時期・移行方式・移行対象・移行計画（移行作業分担、リハーサル、トラブル対処）の記述を参照（2026年11月確認）
- *3 参考：独立行政法人情報処理推進機構（IPA）「システム再構築を成功に導くユーザガイド 第2版」（PDF）（https://www.ipa.go.jp/archive/publish/qv6pgp000000117x-att/000057294.pdf）。出典：再構築作業の流れ（資産棚卸・移行性分析、移行方針の決定と移行計画の策定）の記述を参照（2026年11月確認）
