移行計画書の書き方 記載項目と移行方式の選び方・リハーサルまでの進め方を解説

システムの入れ替えで最も緊張するのが、本番移行の当日です。想定より時間がかかる、データが一部取り込めない、切り替え後に外部連携が動かない。こうした事態は、計画の作り込み不足がそのまま現れた結果であることがほとんどです。

移行計画書は、誰が、いつ、どの方法で移行を行い、リハーサルや切り戻しをどう扱うのかまでを事前に定めた文書です。作業の直前に慌てて作るものではなく、関係者の認識を揃え、当日の判断基準として使うためのものです。

本記事では、移行計画書の役割と手順書との違いから、記載すべき項目、移行方式の選び方、データ移行の計画、リハーサルと当日の運営、そして見落とされやすい項目までを順番に整理します。

確認したいポイント	結論	詳細
移行計画書とは何ですか？	移行の全体像を合意する文書	誰がいつどの方法で移行し、リハーサルや切り戻しをどう扱うかまでを事前に定めます。
移行手順書との違いは？	計画書は方針、手順書は作業	当日の具体的な操作は手順書に書き、計画書には体制、タイムテーブル、判定基準を載せます。
移行方式はどう選ぶ？	業務を止められる時間で決まる	一括・段階・並行稼働の3方式があり、停止許容時間とデータ量、失敗時の影響で判断します。
特に抜けやすい項目は？	切り戻しと外部連携の連絡	中止の判断基準と復旧手順、連携先への事前連絡は計画の段階で決めておく必要があります。

この記事でわかること

• 移行計画書の役割と、移行手順書との書き分け
• 計画書に載せるべき項目と、それぞれに書く内容の粒度
• 一括・段階・並行稼働という3つの移行方式の違いと選び方
• データ移行で決めておくべき変換ルールと検証の方法
• リハーサルの進め方、移行の判定基準、切り戻しの考え方

▼ システム導入や刷新の進め方を整理したい方へ 業務の棚卸しからシステム化・AI活用までの進め方、支援内容、導入までの流れをまとめた資料をご用意しています。検討の初期段階でも構いませんので、まずは全体像の把握にご活用ください。 ＞ 資料請求はこちら

移行計画書とは何を定義する文書か

書き始める前に、役割を整理します。似た名前の文書が複数あるため、どこに何を書くのかを決めておかないと、内容が重複したり抜けたりします。

移行計画書の役割

移行計画書の役割は、移行の全体像について関係者の合意を取り、当日の判断基準として使えるようにすることです。移行要件や方針にもとづいて、誰がいつどの方法で実施するのかを記述します。

もう1つの役割が、リスクへの備えを事前に決めておくことです。想定どおりに進まなかったとき、どこで中止を判断し、どう元に戻すのか。当日になってから議論していては間に合いません。

関係者が多いほど、この文書の価値は上がります。開発側、業務部門、情報システム部門、外部の連携先が同じ内容を見て動ける状態をつくるのが目的です。

移行手順書との違い

混同されやすいのが手順書です。移行計画書には方針、体制、スケジュール、判定基準を書き、具体的な操作手順は移行手順書に分けて書くというのが一般的な分担になります。

計画書に当日のコマンド一つひとつまで書き込むと、分量が膨れ上がって読まれなくなります。逆に手順書には、体制図や中止の判断基準は不要です。読み手と使う場面が違うためです。

計画書は事前の合意形成のため、手順書は当日の実作業のため。この使い分けを最初に決めておいてください。

規模が小さい案件では、計画書と手順書を1冊にまとめることもあります。その場合でも、方針を書く章と作業を書く章は分けておくと、読み手が迷いません。

いつ作るのか

作成のタイミングは、設計がある程度固まり、移行の対象と方式が見通せた段階です。要件定義の直後では前提が定まらず、テスト工程に入ってからでは調整が間に合いません。

特に業務停止を伴う移行では、関係部署との日程調整に時間がかかります。移行の候補日を早めに押さえるためにも、計画の骨子は前倒しで作っておくのが実務的です。

移行日の候補は、業務部門と情報システム部門の双方に確認したうえで複数挙げておいてください。1日しか候補がない状態は、延期が許されない状況をつくります。

移行対象はデータだけではない

移行と聞くとデータ移行を思い浮かべがちですが、対象はそれだけではありません。環境の移行、アプリケーションの移行、そして業務そのものの移行も含まれます。

公的機関が公開している目次案でも、環境設定の移行とデータの移行を分けて記載する構成が示されています。データについても、マスタ系のデータ、業務ファイル、書類データといった単位で範囲を明確にすることが求められています（出典：特許庁「移行計画書」目次案）。

業務の移行、つまり利用者が新しい手順に切り替わることも、計画に含めておく必要があります。システムが動いても現場が使えなければ、移行は完了していません。

移行計画書に記載する項目

ここからは具体的な構成です。規模を問わず必要になるのは5つの領域で、まずはこの骨格を押さえます。

目的と前提条件

冒頭に、なぜ移行を行うのか、完了時点で何が達成されているのかを書きます。あわせて、計画が成り立つための前提条件も明記しておきます。

「旧システムは移行日まで稼働している」「対象データは事前に凍結される」「連携先は指定日にテストに応じる」といった前提です。ここに書いておけば、前提が崩れたときに計画を見直す根拠になります。

移行対象の範囲

何を移行し、何を移行しないのかを明確に分けて書きます。システムとインフラの範囲、データの範囲、それぞれについて対象と対象外を列挙します。

対象外の明記は特に重要です。「過去5年分のみ移行し、それ以前は旧システムで参照する」といった線引きを書いておかないと、稼働後に「昔のデータが見られない」という指摘を受けます。

移行しないと決めたデータをどう扱うかも、あわせて決めておいてください。旧システムを参照用に残すのか、別の形式で保管するのか。法定保存期間がある書類は特に注意が必要です。

範囲の記述は、後から読む人が判断できる粒度で書きます。「一部のマスタ」ではなく、対象のマスタ名を列挙するところまで具体化してください。

移行方式と選定した理由

どの方式で移行するのかと、なぜその方式を選んだのかを書きます。理由を残しておくと、後から条件が変わったときに再検討の判断がしやすくなります。

方式ごとの違いは次の章で扱いますが、いずれを選ぶにせよ、業務停止の有無と時間、利用者への影響を明示しておく必要があります。

スケジュールとマイルストーン

移行に向けた準備から当日、そして移行後の安定稼働までを時系列で示します。リハーサルの実施日、移行判定を行う日、本番移行日、初期対応期間の終了日が主なマイルストーンになります。

当日については、日単位ではなく時間単位のタイムテーブルを用意します。何時に何を開始し、何時までに終わっていなければならないのか。この時刻が、中止判断の基準にもなります。

準備期間には、関係部署との調整やデータのクレンジングといった、目に見えにくい作業も含まれます。これらもスケジュールに載せておかないと、直前になって時間が足りなくなります。

体制と役割分担

誰がどの作業を担い、誰が判断を下すのかを体制図と一覧で示します。開発側と利用者側の双方について整理してください。

移行当日は休日や夜間に行うことが多く、関係者が分散します。連絡体制と緊急時の連絡先を計画書に含めておくと、いざというときに探し回らずに済みます。

判断を下す責任者は必ず1人に決めておきます。中止するかどうかの判断を合議で行おうとすると、時間だけが過ぎていきます。

▼ プロジェクトの進め方からご相談いただけます 移行の方式選定、体制づくり、リスクの洗い出しまで含めて、実務目線でご一緒に整理します。検討の初期段階でも構いません。 ＞ 相談予約はこちら

移行方式の選び方

計画の骨格を決めるのが方式の選定です。主な選択肢は3つあり、それぞれリスクの形が違います。

一括移行

決められた日時にすべてを切り替える方式です。旧システムを停止し、データを移し、新システムで稼働を開始します。期間が短く、並行運用の負担がない点が利点です。

一方で、問題が起きたときの影響が全体に及びます。想定外の事態に備える時間的な余裕も限られるため、切り戻しの手順を確実に準備しておくことが前提になります。

業務を一定時間止められること、移行するデータ量が時間内に処理できることが条件です。夜間や連休を使って実施するケースが多くなります。

段階移行

拠点ごと、業務ごと、機能ごとに分けて順次切り替える方式です。1回あたりの影響範囲が小さく、初回で見つかった課題を次回に反映できます。

欠点は、移行期間中に新旧のシステムが混在することです。データの整合をどう保つか、両方を使う利用者の負担をどうするかを別途設計する必要があります。

拠点数が多い、業務が明確に分かれている、一度に止められないといった条件では有力な選択肢になります。

並行稼働

一定期間、新旧の両方を動かして結果を突き合わせる方式です。新システムの正しさを実データで検証できるため、確実性は最も高くなります。

ただし、その期間は両方に入力する必要があり、現場の負担が大きくなります。期間が長引くほど負担が積み上がるため、いつ終わらせるかの基準を先に決めておくことが不可欠です。

金額の計算や帳票の出力など、誤りが許されない業務で採用されることが多い方式です。

並行稼働では、差異が出たときにどちらを正とするかも決めておく必要があります。突き合わせの結果をどう記録し、誰が判断するのかまで設計しておいてください。

判断の基準

選択の軸は3つです。1つ目は業務をどれだけ止められるか。数時間しか止められないなら一括、まったく止められないなら段階か並行を検討します。

2つ目は移行するデータの量と処理時間です。実データに近い規模でテストして、所要時間を把握してから判断してください。3つ目は失敗したときの影響の大きさ。影響が大きいほど、確実性の高い方式を選ぶ価値があります。

複数の方式を組み合わせることもできます。基幹データは一括、周辺システムは段階、というように分けて設計する構成も実務では使われます。

▼ 「この方式で安全に移行できるか」から相談できます 業務停止の調整、データ量の見積もり、切り戻しの設計まで、第三者視点での確認も含めてご相談いただけます。 ＞ 相談予約はこちら

データ移行の計画

移行作業の中心になるのがデータです。ここでの準備不足が、当日のトラブルに直結します。決めておくべき4点を整理します。

対象データを棚卸しする

まず、どのテーブルのどの項目を、どれだけの件数移すのかを一覧にします。マスタ、トランザクション、添付ファイル、それぞれについて整理してください。

この段階で、実際には使われていないデータが見つかることがあります。移行対象から外せるものは外すほうが、作業時間もリスクも減らせます。

件数は概算ではなく実測してください。移行処理の所要時間を見積もる基礎になります。

添付ファイルや帳票のイメージデータは、件数の割に容量が大きくなりがちです。処理時間と保存領域の両面で、早い段階に見積もっておいてください。

変換ルールを定義する

旧と新でデータの持ち方が違う場合、項目の対応関係と変換のルールを定義する必要があります。いわゆるマッピングの作業です。

よく問題になるのが、コード体系の変更、桁数の違い、必須項目の追加です。旧システムでは空欄が許されていた項目が新システムでは必須になっている場合、その値をどう埋めるかを決めなければなりません。

「業務上どう扱うべきか」の判断が必要な部分なので、業務部門を巻き込んで決めてください。開発側だけで決めると、後から実態と合わないことが判明します。

移行できないデータの扱いを決める

変換できない、あるいは新システムの制約に合わないデータは必ず出てきます。エラーとして弾くのか、既定値を入れるのか、手作業で修正するのかを事前に決めておきます。

件数がわずかなら手作業でも対応できますが、数が多いと当日の作業が破綻します。リハーサルで件数を把握し、多い場合は変換ルール側を見直してください。

データそのものの品質を整える作業も、移行前に必要になることがあります。重複、表記の揺れ、使われていないコード。これらを移行後に直すのは、移行前に直すより手間がかかります。

検証の方法を決めておく

移行した結果が正しいかを、どう確認するのかを計画に書いておきます。件数の突合、金額の合計値の一致、サンプル抽出による目視確認が基本の組み合わせです。

検証にかかる時間も、当日のタイムテーブルに含めてください。移行処理だけを見積もって、確認の時間を取っていない計画は珍しくありません。

誰が検証し、誰が結果を承認するのかも決めておきます。データの正しさを判断できるのは、多くの場合は業務部門です。

リハーサルと当日の運営

計画の実効性を確かめる場がリハーサルです。本番と同じ手順を通しで試すことで、計画の不備が見つかります。

リハーサルの目的と回数

リハーサルの目的は、手順が正しいかの確認と、所要時間の実測です。見積もりと実際の時間がずれていれば、タイムテーブルを組み直す必要があります。

公的機関の目次案でも、リハーサルの実施有無、実施する場合は何回行うか、1回目では何を移行するか、見つかった課題をどう取り込むかを計画に書くことが示されています。

最低でも2回は行いたいところです。1回目で課題を洗い出し、対策を反映したうえで2回目を実施して、計画どおりに完了することを確認します。リハーサルは、できるだけ本番に近い環境と実データに近いもので行ってください。件数の少ないテストデータでは、所要時間の実測になりません。

当日のタイムテーブル

当日については、開始時刻、各作業の所要時間、担当者、完了の判断基準を時間単位で並べます。作業の具体的な操作は手順書に譲り、計画書には流れと責任者を書きます。

重要なのが、各工程に「この時刻を過ぎたら判断する」という基準を設けておくことです。遅れが出たときに、続行するか中止するかを感覚で決めることになるのを防げます。

想定外の待ち時間も見込んでおいてください。実測値ぴったりの計画は、少しの遅れで破綻します。

移行の判定基準を決める

本番移行に進んでよいかを判断する場を、事前に設けておきます。リハーサルが完了していること、未解決の重大な課題がないこと、切り戻しの準備が整っていることといった条件を、判定の基準として明文化します。

判定の時期は、移行日の数日前が一般的です。この場で中止を判断した場合の代替日も、あらかじめ押さえておくと調整が楽になります。

切り戻しの条件と手順

最も抜けやすく、最も重要なのがこれです。どういう状態になったら中止するのか、中止した場合に何をすれば元に戻るのかを計画に明記します。

切り戻しにも時間がかかります。「何時までに切り戻しを開始しなければ、翌朝の業務に間に合わない」という時刻を逆算し、それを中止判断の期限としてタイムテーブルに書き込んでください。

切り戻しの手順自体も、リハーサルで一度試しておくことをおすすめします。使わないことを願う手順ですが、使うときは余裕のない状況です。

▼ 移行の計画とリスク対策を第三者視点で確認します 「この体制と時間で回るのか」「切り戻しの想定に漏れはないか」といった確認も含めて、ご相談いただけます。 ＞ 相談予約はこちら

見落とされやすい項目

システム面の準備が整っていても、業務や社外との調整が抜けていると当日に問題が起きます。特に見落とされやすい4点を挙げます。

業務停止の調整と利用者への周知

移行のために業務を止めるなら、いつからいつまで使えないのかを、利用部門へ事前に周知する必要があります。周知の時期と方法も計画に書いておいてください。

月末や締め日を避ける、繁忙期を外すといった調整も必要です。システム側の都合だけで日程を決めると、業務部門の合意が得られません。

停止期間中に発生した業務をどう記録し、稼働後にどう反映するかも決めておきます。紙で受け付けて後から入力する、といった運用の設計が要ります。

問い合わせ窓口の体制も、この期間だけは厚くしておく必要があります。通常の人員では捌けないことが多いためです。

外部連携先への連絡

他社のシステムと連携している場合、相手側にも影響が及びます。データの形式が変わる、連携の時刻が変わる、一時的に停止するといった内容を、事前に伝えておく必要があります。

相手側での確認や設定変更が必要な場合、その作業にも日程調整が要ります。自社の都合だけでスケジュールを組まないよう、早い段階で連絡してください。

旧システムの停止と保管

移行が完了した後、旧システムをいつ停止し、データをどう保管するのかも計画に含めます。すぐに止めるのか、参照用にしばらく残すのか。

法定の保存期間がある帳票やデータは、確実に参照できる形で残す必要があります。ライセンスの契約期間や、機器の保守期限とも関係するため、早めに確認してください。

移行後の初期対応体制

稼働直後は問い合わせが集中します。誰が受け付け、誰が対応するのか、いつまでその体制を維持するのかを決めておいてください。

この期間を計画に含めていないと、開発側は移行完了とともに解散し、現場だけが混乱に取り残されます。1週間から1か月程度を目安に、対応体制を確保しておきます。

計画を機能させるための運用

計画書は作って終わりではありません。関係者が実際に読み、使う状態にして初めて価値が出ます。

手順書へつなげる

計画書に書いた各作業が、どの手順書のどこに対応するのかを明示しておきます。当日、計画書を見ながら手順書をたどれる状態が理想です。

手順書は作業者が実際に読みながら操作するものなので、画面名やコマンドまで具体的に書きます。計画書とは粒度が違う点を意識して書き分けてください。

変更履歴を残す

計画は必ず変わります。版数、日付、変更内容、変更理由、承認者を履歴として残し、関係者に最新版が届く仕組みを作っておいてください。

古い版を見ながら作業されると、当日に混乱します。共有場所を1か所に決め、そこを正本とする運用にしておくことが確実です。

当日は計画書を印刷して手元に置く運用も有効です。移行中にネットワークやシステムが使えない時間帯があると、画面上の資料を参照できなくなります。

終わったら振り返る

移行が完了したら、計画と実績のずれを記録しておきます。どの作業が想定より時間がかかったか、何が抜けていたか。次の移行で必ず役立ちます。

振り返りの結果は、自社の移行計画書のひな形に反映してください。個人の経験で終わらせず、組織の資産として残すことが投資の回収につながります。業務全体の整理の仕方は業務効率化アイデア55選の記事でもまとめています。

書ける人を1人に限定しない

移行計画を書けるのが特定の1人だけという状態は、組織として脆弱です。レビューに複数人を巻き込み、次の案件では別の人が書く運用にしておくと、経験が分散していきます。

なお、要件定義から移行までの工程全体を共通の用語で整理したい場合は、IPAの共通フレームが参考になります。企画から開発、運用までの作業項目と役割が体系的にまとめられており、発注側と受注側で認識を揃える土台として使えます（出典：IPA「共通フレーム2013」）。人材面の育て方はAI研修の目的と選び方をまとめた記事も参考になります。

まとめ

移行計画書は、誰がいつどの方法で移行し、リハーサルや切り戻しをどう扱うのかを事前に定め、当日の判断基準として使う文書です。具体的な操作手順は手順書に分け、計画書には方針、体制、スケジュール、判定基準を書きます。

記載する骨格は、目的と前提条件、移行対象の範囲、移行方式と選定理由、スケジュールとマイルストーン、体制と役割分担の5領域です。移行の対象はデータだけでなく、環境、アプリケーション、そして業務そのものも含まれます。

方式は一括、段階、並行稼働の3つ。業務をどれだけ止められるか、データ量と処理時間、失敗したときの影響の大きさで選び分けます。データ移行では、対象の棚卸し、変換ルール、移行できないデータの扱い、検証方法を必ず決めておいてください。

そして最も重要なのが、リハーサルで所要時間を実測すること、中止の判断基準と期限を時刻で決めておくこと、切り戻しの手順を用意しておくこと。この3点が揃っていれば、想定外が起きても落ち着いて対応できます。

▼ システムの刷新と移行を、安全に進めませんか 株式会社ネクストスケールでは、業務の棚卸しから要件の整理、移行の計画づくり、社内への定着支援までを一貫してご支援しています。何から手をつけるべきか整理したい段階でも構いません。まずはお気軽にご相談ください。 ＞ 相談予約はこちら