LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

クラウド移行を業務委託エンジニアに手伝ってもらうことになったが、移行計画に何を書けばよいのか社内で答えられない。委託先から移行計画書を受け取ったものの、どこを確かめればよいのか分からない——。自社でサーバーを持って動かしてきたシステムをクラウドへ移す案件では、こうした戸惑いが起こりがちです。クラウド移行の移行計画とは、新しい環境で業務を始めるまでに要る切替えの作業を、対象、方法、体制、日程まで書き出した計画のことです。

デジタル庁の標準ガイドラインは、政府の情報システムについて、移行計画書の案を開発の請負先に作らせ、発注する側が確かめる手順を定めています。民間の案件でも、委託先に何を書いてもらい、社内で何を決めるかを分ける手がかりになります。ただし万能ではなく、手順をそのまま当てはめると文書が増えすぎることもあります。本記事では、開発の現場を回すマネージャーに向けて、移行計画の前に決める移行方式、移行計画に書く6つの項目、業務委託エンジニアに任せる作業と社内に残す判断、そして移行判定と切り戻しの決め方を整理します。

クラウド移行の移行計画とは

デジタル庁の標準ガイドラインには、手順を詳しく説明した解説書があり、移行を「業務移行」「システム移行」「データ移行」の3つに大別しています。業務移行は、いまの業務から新しい業務のやり方に切り替える作業で、切替えの時期や期間、拠点、方法を決めて計画します。システム移行は、本番環境を整えて利用者が使える状態にする作業で、古いシステムの停止や、連携先のシステムの接続先を新しいシステムに切り替える作業も含みます。データ移行は、いまのシステムが持つデータを変換して新しいシステムに入れる一連の作業です。

解説書は、移行ではデータ移行が注視されがちだが、業務とシステムの移行も欠かせないと書いています。連携先のシステムや、新しい画面で仕事をする担当者まで含めて計画しておかないと、データは移ったのに業務を始められません。

移行計画書は、一度で完成させる文書ではありません。解説書は、移行の対象や方法、体制と役割、必要な環境とツール、準備作業と実際の移行作業の内容と日程を書いたものを「移行計画書の案」と呼んでいます。開発やテストで変更が入ることを前提に、設計の段階では案を作り、遅くともデータ移行、環境整備、本番移行の各段階を始める前に、発注する側が確定させるとしています。^*2

なぜ移行方式を先に決めるのか

移行計画の中身は、クラウドへの移り方で大きく変わります。デジタル庁の「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」は、クラウドへの移り方として、システムを作り直して全面的にモダン化（新しい技術や考え方を取り入れて作り替えること）する「全面的な刷新」と、一部をマネージドサービス（クラウド事業者が運用まで担うサービス）に置き換える「基盤の変更」を挙げています。

同じ方針は、移行を2回に分ける「二段階移行」を、移行作業が2回になって総費用が増えるおそれがあるとして、できる限り避けるよう求めています。それでもアプリケーションの改修を最小限にしてインフラだけをクラウドに移すしかない場合は、それを第一段階とし、アプリケーションも含めた第二段階の刷新を最初から計画しておくとしています。先に挙げた「基盤の変更」は、この第一段階に当たります。大規模で難しいシステムについては、サブシステムなどの単位に分け、優先度を決めて順に刷新するよう求めています。^*3

この方式は、移行計画を立てる前に社内で決めておきます。一度で移すのか、二段階で移すのか、サブシステムごとに順に移すのかが決まっていなければ、移行計画書に書く対象も日程も決められません。基本方針は、刷新ではいまのシステムの機能や作りをそのまま引き継ぐことを前提にせず、「データ移行のある新規システム」として考えるよう求めています。^*3 いまの仕様は参考にとどめて新しい仕様で作り、そこへ必要なデータだけを移すという考え方です。

移行計画に書く6つの項目

移行計画書を確かめる観点として、解説書は表7-5「移行計画書の確認観点の例」で、移行データ調査、移行データ整備、本番環境構築、移行リハーサル、移行判定、本番切替えの6つの確認項目を挙げています。^*2 解説書が確かめるとしている点を、移行計画に書いておく内容として並べると、次のようになります。

クラウドでは機器の搬入はありませんが、ネットワークやサーバーの設定、疎通テスト（システム同士がつながるかの確認）の作業に過不足がないかは同じように確かめます。表7-5では、どの項目にも「リスクが網羅的に挙げられ、対応策等が整理されているか」という確認の観点が並んでいるので、項目ごとに起こりうる問題と対応策を書き添えておきます。

解説書は移行リスクの例として、移行作業中に利用者へのサービスが止まる期間が出ること、システム方式の変更で連携先のシステムからアクセスできなくなること、データ移行で一部のデータが失われることを挙げています。^*2 クラウド移行ではシステムの置き場所が変わるので、連携先のシステムの接続設定をいつ、誰が変えるかも移行計画に書いておきます。

業務委託エンジニアに任せる作業

標準ガイドラインの手順では、移行計画書の案を作るのは設計・開発の請負先です。発注する側は、その案が要件定義（システムに求めることを決めた文書）と合っているかを確かめ、移行リスクを下げるために、連携先のシステムの担当など関係する機関や事業者と調整します。移行に要るデータ変換やツールの設計、移行手順書の作成も請負先に求める作業です。^*1 業務委託エンジニアに頼む場合も、この分け方がそのまま使えます。

一方で、社内に残す判断があります。一つは関係者との調整で、解説書は、移行計画書を作るにあたり、いまの委託先やシステムの利用者と調整し、現在の業務とシステムの状況を十分に把握するよう求めています。もう一つは稼働判定、つまり新しいシステムに切り替えても業務に支障が出ないかの判断です。解説書は、業務移行は請負先では最終的な確認ができないため、職員による稼働判定が欠かせないとしています。^*2 民間の会社なら、業務を担う部門の社員がこの判断に加わります。

データ変換にも社内の手が要ります。解説書によれば、データ変換にはコード値（区分を表す番号）の付与や重複データの統合・除去などさまざまな作業があり、機械的な変換だけでなく、発注側の職員が確認や修正をする場合もあります。どのデータを移し、どの古いデータを移さないかは、業務を知る社内の担当者が決めます。

移行手順書の書き方も、委託先に伝えておきたい点です。解説書は、移行手順書を、作業の経験や担当者のスキルに左右されず、誰がやっても間違えずに作業と確認ができる書き方にするよう求めています。手順書は、業務委託エンジニアの契約が終わったあとも社員が読んで作業できる形で受け取ります。

誰に頼むかにも注意が要ります。基本方針は、刷新の費用の見積りは、マネージドサービスを使った構成などのモダン技術に詳しい事業者に頼むことが欠かせないとし、そうでない事業者の見積りは従来の方式を守るためのものが多く、正しい意思決定を妨げるとしています。^*3 業務委託エンジニアを選ぶときは、マネージドサービスを使った移行の経験を確かめておきます。

移行判定と切り戻しの決め方

本番の移行を始めてよいかを決めるのが移行判定です。標準ガイドラインは、次の3つの条件をすべて満たす場合に限り、本番移行を始めるとしています。^*1

• 受入テスト（発注側が行う最後の確認のテスト）で、要件定義に沿った内容で、設定した品質基準をすべて満たしたと認められる
• 指定されたプロジェクトでは、第三次工程レビュー（政府の管理組織が移行の前に行う審査）で問題なく妥当と判断される
• 移行計画書の内容とリハーサルの結果が適正と判断される

2つ目の審査は政府の仕組みなので、民間の案件なら、社内のシステム部門の責任者による確認の場に置き換えます。リハーサルは、できる限り本番と同じ環境とデータを使い、本番と同じ手順と日程で行う予行演習です。解説書は、リハーサルを複数回計画して実行し、結果を見て手順やツールを直したうえで、もう一度リハーサルで確かめるよう求めています。^*2

切り戻し（新しいシステムへの切替えをやめて元のシステムに戻すこと）の条件と方法も、移行計画の段階で決めておきます。表7-5も、切戻しの条件と方法が明確か、移行判定の基準に曖昧さがないかを確認の観点に挙げています。たとえば「決めた時刻までに主要なデータの照合が終わらなければ元のシステムに戻す」のように、誰が見ても同じ判断になる書き方にしておきます。

移行方式の選び方は「クラウド移行戦略と移行方式の選び方」で、本番切替えの当日の段取りは「システム移行のカットオーバー計画」で扱っています。

つまずきやすい点

一つ目は、いまのシステムの規模をそのまま前提に計画を立ててしまうことです。基本方針は、多数の画面や帳票、大量のバッチ処理（まとめて自動で行う処理）で大きくなったシステムの規模を前提に見積りを取ると、非常に高額になり刷新の計画自体が頓挫してしまうとしています。^*3 画面や帳票、バッチ処理を減らせないかを先に検討してから、移行計画を書きます。

二つ目は、移したデータの確認を移行ツールの結果だけで済ませることです。標準ガイドラインは、データを変換・移行したあとは、移行後のデータだけでなく例外データなども確認するよう求めています。^*1 解説書は、手作業で入れたり直したりしたデータも確認の対象とし、複数の関係者で作業を分けるときは確認に漏れが出ないよう配慮するとしています。業務委託エンジニアと社員で作業を分けるなら、どのデータを誰が確かめるかを表にしておきます。

三つ目は、文書を作ること自体が目的になってしまうことです。基本方針は、使われない大量の文書に工数と期間を割くのではなく、クラウドではまず実機の環境で作ってみて、試行錯誤と評価のあとに確定した内容だけを必要な文書として納品物にすることが重要だとしています。^*3 移行計画書も、自社の案件で要る項目から書き始め、リハーサルの結果を見て書き直していくとよいでしょう。

まとめ：移行計画で確かめておきたい3つの点

業務委託エンジニアとクラウド移行の移行計画を立てるうえで、確かめておきたい点は3つに整理できます。第一に、一度で移すのか、二段階で移すのか、サブシステムごとに移すのかという移行方式を、移行計画書を頼む前に社内で決めること。第二に、移行データ調査から本番切替えまでの6つの項目を移行計画に書き、移行計画書の案やデータ変換の設計は委託先に任せつつ、関係者との調整と業務の稼働判定は社内に残すこと。第三に、移行判定の基準と切り戻しの条件を、誰が見ても同じ判断になる書き方で決め、リハーサルを繰り返して確かめることです。この3点を踏まえておけば、「データはクラウドに移ったのに、連携先のシステムがつながらず業務を始められない」という事態を避けやすくなります。移行計画の立て方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：デジタル庁「DS-100 デジタル・ガバメント推進標準ガイドライン」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715_resources_standard_guidelines_guideline_01.pdf）。出典：2026年6月12日 デジタル社会推進会議幹事会決定。ドキュメントの位置付け、第3編第7章4.4)「移行の計画・設計」、5.3)「移行ツールの実装及び移行データ・移行手順書等の作成」、8.「移行の実施・管理」、9.「引継ぎ」を参照（2026年9月確認）
2. *2　参考：デジタル庁「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）。出典：2026年6月12日版。第7章4.の解説(10)〜(13)（移行の定義、移行計画書の案、移行リスク、データ変換）、5.の解説(3)（移行要領・移行手順書）、8.の趣旨と解説(1)〜(3)、表7-5「移行計画書の確認観点の例」を参照（2026年9月確認）
3. *3　参考：デジタル庁「DS-310 政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/a612d406/20250619_resources_standard_guidelines_guideline_08.pdf）。出典：2025年5月27日 デジタル社会推進会議幹事会決定。1.4 表1-1（モダン化、マネージドサービス、Rebuild、Replatform）、3.4 マルチクラウド等について、3.5 1)〜2)、3.9 1)（二段階移行、一括刷新、データ移行のある新規システム）、3.9の図3-3の説明を参照（2026年9月確認）

Tweet