VMwareなど仮想化基盤の移行案件を打診されると、まず気になるのは「いつまでに、何をどう移すか」という工程表です。ただ、切り替えの前に確かめておきたい範囲は、工程表だけでは見えてきません。地方公共団体の標準準拠システムを対象にした移行手順書には、切り替える前に何を可視化しておくかという整理の型が示されています。この記事では、その型を手掛かりに、参画前に確認しておきたい観点と、経験を言葉にする材料を整理します。

1. 移行は「移す作業」の前に、3つのフェーズで組まれている

現行システム確認が、独立した最初の段階に置かれている理由

移行の打診は多くの場合「◯月までに切り替えてほしい」という期限から始まります。工程表に先に目が行くのは自然な流れで、担当できる範囲を早く見積もりたい気持ちの表れでもあります。

地方公共団体の標準準拠システムを対象にした移行手順書は、移行計画の策定を「現行システム確認」「システム移行計画」「RFI結果分析及び移行計画の評価と詳細化」という3つのフェーズで組んでいます¹。移す前に調べる段階が、計画を立てる段階よりも先に、独立した工程として置かれている点が要になります。

工程表を先に埋めるよりも、まず何を確認できているかを言葉にするほうが、案件の中身を自分の判断で語れる立場に近づきます。次の段階からは、その「確認できていること」を具体的な4つの対象に分けて見ていきます。

打診を受けた時点で、どの段階を任されるのかを確かめる

打診の連絡では「移行を手伝ってほしい」という言い方だけで、どの段階の作業かがはっきりしないまま話が進むことも珍しくありません。

現行システム確認・システム移行計画・評価という3段階のどこを担うかで、必要になる確認の深さは変わります¹。調べる段階から関わるのか、すでに調べ終えたものを引き継いで計画に入るのかを最初に確かめておくと、後から話が食い違う場面を減らせます。

次章では、この「現行システム確認」の中身、つまり何が可視化されている必要があるのかを、構造とつながりという切り口から具体的に見ていきます。

図の作成：Remogu編集部。移行手順書が示す確認対象を整理したもので、統計データではありません

2. 構造とつながりが見えているか

アーキテクチャという、全体の構造を描けているか

現場に残っている資料が古いと、システム全体の構成を一枚の図で説明できる人がすでにいない、という状況は珍しくありません。

移行手順書は、現行システム確認の段階で、システムを構成する要素とその関係を表現したシステム全体の構造であるアーキテクチャが可視化されているかを確認する、と示しています²。持っている情報が「動いている」ことの確認にとどまり、「どうつながっているか」まで説明できているかは、別の話になります。

図がない場合は、まず監視画面や設定ファイルから、動いている要素を一つずつ書き出すところから始めると、後で説明を求められた場面でも言葉に詰まりにくくなります。

外部システムとの境目は、文字コード変換まで見る

「外部連携はある」という認識までは共有されていても、具体的に何をやり取りしているかまで整理されている現場は限られます。

移行手順書は、外部システムとの関連性を可視化する対象の中に、文字コード変換等も含めています³。単に「連携している」で止めず、変換のルールまで踏み込んで確認する対象になっている点が実務的です。

構造とつながりが言葉にできると、次に問われるのは「動いていることと、約束されていることは同じか」という運用の水準です。次章ではその境目を見ていきます。

見えていない箇所の見つけ方

資料が古い、あるいは作った人がすでにいない現場では、構造とつながりを一から洗い出す必要があります。闇雲に探すのではなく、確認する対象ごとに見る場所と、資料が無いときの代わりの探し方を分けておくと、抜け漏れを防ぎやすくなります。

下の表は、アーキテクチャと外部システムとの関連について、実務でよく使う確認の切り口を整理したものです。案件によって残っている資料の量は異なるため、自分が担当する範囲に当てはめて使う想定です。

確認したい対象	資料があるときの見る場所	資料が無い・古いときの代わりの探し方
全体の構成（アーキテクチャ）	構成図・環境一覧	監視画面や接続の設定ファイルから逆に洗い出す
外部システムとの関連	インターフェース仕様書	ログや連携用の設定から、どこと何をやり取りしているか辿る
文字コードなど変換の有無	連携仕様書の変換ルール	実際のデータを1件取り出し、変換前後を突き合わせる
権限や認証の連携	認証基盤の設定	ログインの経路を実際にたどってみる

3. 運用と約束の水準が見えているか

「動いている」ことは、運用の実態を指す

システムが日々動き続けていると、それだけで「特に問題は無い」と受け止めてしまいがちです。

移行手順書は、現行システム確認の段階で、現行運用方法が可視化されているかを確認するとしています。運用体制や障害発生時の対応、パッチリリース等の保守対応が、その具体的な中身として挙げられています⁴。

誰が、どのタイミングで、何に対応しているかを言葉にできて初めて、運用の実態を引き継げる形になります。

「約束されている」ことは、水準として定義されたものを指す

動いている実態とは別に、契約や取り決めの中で「このくらいの水準を保つ」という約束が結ばれている場合があります。

移行手順書は、現行SLAが可視化されているかも確認の対象に含めています。稼働率目標や耐障害性設計、バックアップ取得頻度やインシデント管理方法等が、その項目として挙げられています⁵。具体的な数値は案件ごとに異なるため、ここでは何を約束の項目として持っているかを押さえておくことが要点になります。

動いていることと、約束されていることは別の情報です。この二つを分けて言葉にできると、次に検討する並行稼働の判断材料にもつながります。

図の作成：Remogu編集部。移行手順書が挙げる確認項目を整理したもので、数値は記載していません

4. 並行稼働は選択肢であって、既定路線ではない

作業ボリュームは、観点を洗い出してから見積もる

移行の見積もりというと、まず作業日数や人数から考えたくなります。

移行手順書は、システム移行計画の段階で、移行作業における技術的な観点を洗い出し、移行作業ボリュームを検討するという順番を示しています⁶。観点を先に洗い出さないまま日数だけを決めてしまうと、後から想定外の作業が見つかったときの説明が難しくなります。

技術的な観点を先に言葉にできる立場は、単なる作業の担い手よりも一歩踏み込んだ関わり方になります。

並行稼働は、データ同期の難しさとセットで考える

「念のため並行稼働にしておきましょう」という判断は、安全に見えて選ばれやすいものです。

移行手順書は、影響箇所を特定したうえで、新旧並行稼働の可否と、並行稼働をする場合の新旧切り替えタイミングを策定するという流れを示しています。あわせて、並行稼働ではデータの同期が必要となり、難易度が高くなることを考慮する点も挙げています⁷。

安全策を先に選ぶよりも、同期の負担に見合うかどうかを材料にして選ぶほうが、判断として筋が通ります。次の表では、その判断材料を具体的に整理します。

並行稼働の可否を判断する材料

並行稼働にするかどうかは、一つの基準だけで決まるものではありません。データの同期方法、切り替えられる時間帯、影響が及ぶ範囲、並行期間中の運用体制など、複数の材料を並べたうえで難易度を見積もる必要があります。

下の表は、判断材料と確認すること、難易度に影響する理由を整理したものです。案件ごとに重みは変わるため、自分が関わる案件に当てはめて材料を並べ直す使い方を想定しています。

判断材料	確認すること	難易度に効く理由
データの同期方法	新旧どちらを正として扱う時間帯を作れるか	同期の仕組みが複雑になるほど難易度が上がる
切り替えタイミング	業務を止められる時間帯があるか	時間帯が短いほど並行稼働の負担が増える
影響箇所の範囲	どこまでを新旧両方で動かす必要があるか	範囲が広いほど確認の手間が増える
運用体制	並行期間中に双方を見られる体制があるか	体制が薄いと並行稼働の選択肢が狭まる

図の作成：Remogu編集部。移行手順書が示す考慮点を整理したもので、統計データではありません

5. 移した後の日々の作業まで見る

切り替え日は終わりではなく、運用フローの起点

移行の話では「切り替え日」がゴールのように語られることがよくあります。

移行手順書は、移行後のソース管理、リリース自動化（CI/CD）等、運用フローへの影響箇所を特定するという工程まで含めています⁸。切り替えた瞬間ではなく、その後の日々の作業に何が変わるかまでが確認の対象になっています。

切り替え後にどう運用が回るかまで見通せている人は、作業の担い手ではなく、運用を設計できる立場として見られやすくなります。

移行の経験を、担当した層で言葉にする

「移行を担当しました」だけでは、どこまで関わったのかが伝わりにくいことがあります。

現行システム確認、移行計画、切り替え作業、そして移行後の運用フローという層に分けて振り返ると、自分が実際に踏み込んだ範囲が具体的な言葉になります。同じ移行案件でも、調べる層から関わったのか、切り替え作業だけを担ったのかで、次に打診される案件の幅は変わってきます。

下の表は、その振り返りを4つの層に分けて整理したものです。自分の経験をどの層まで言葉にできるか、当てはめて確認してみましょう。

移行の経験を4つの層で書き出す

移行の経験は、担当した層によって言葉にできる内容が変わります。調べた層、計画した層、実行した層、運用に接続した層と分けると、自分がどこまで踏み込んだ経験を持っているかが整理しやすくなります。

下の表は、各層で何をしたかと、それを実績としてどう言葉にするかの例を並べたものです。全ての層を経験している必要はなく、実際に担った層だけを言葉にすれば十分です。

層	何をしたか	実績として言葉にする例
調べた層	現行の構成やつながりを洗い出した	可視化されていなかった外部連携を整理した
計画した層	並行稼働の可否や切り替えタイミングを検討した	判断材料を整理し、切り替え方針の検討に加わった
実行した層	実際の切り替え作業を担った	切り替え作業を実施した
運用に接続した層	移行後のソース管理やCI/CDへの影響を確認した	移行後の運用フローの調整に関わった

図の作成：Remogu編集部。移行手順書が示す確認範囲を整理したもので、統計データではありません

6. まとめ

移行の案件は「移す速さ」で評価されると考えがちですが、地方公共団体の標準準拠システムを対象にした手順書が示す型に沿って読み直すと、評価の軸は「移す前に何を確認できていたか」に近いことが分かります。構造とつながり、運用と約束、並行稼働の可否、そして移した後の運用フローまで、確認する対象を先に言葉にできる人は、単なる作業の担い手にとどまりません。

この整理は地方公共団体のシステムを対象にしたものですが、切り替える前に何を確認するかという組み立て方そのものは、案件の種類を問わず参考にできる型です。自分が関わってきた移行の経験をこの型に沿って振り返ると、これまで「移しました」としか言えなかった実績が、どの層に踏み込んだ経験かという言葉に変わります。

Remoguは、リモートワーク案件に特化したエンジニアマッチングで、掲載されている案件の90%以上がフルリモート可能です⁹。仮想化基盤の移行に関わってきた経験を言葉にできたら、まずは自分の経験に近い案件がどんな条件で並んでいるかを確かめてみることから始めてみましょう。

7. よくある質問

現行の資料が古い案件では、どこから始めるとよいか

現行システム確認の段階からやり直す意識を持つと、抜け漏れが少なくなります。監視画面や設定ファイル、実際に流れているデータから、構造とつながりを一つずつ書き出していくと、資料が無くても現行の姿に近づけます²。焦って計画に進むよりも、確認できた範囲を先に言葉にしておくほうが、後の工程で説明に困る場面を減らせます。

並行稼働はやったほうがよいのか

並行稼働は安全策に見えますが、データの同期が必要になり、難易度が高くなる点も考慮の対象です⁷。「やる・やらない」を先に決めるのではなく、同期の方法や切り替えタイミング、影響箇所の範囲といった材料を並べたうえで、案件ごとに向き不向きを判断する進め方が現実的です。

期日が先に決まっている案件では、どう進めるか

期日が固定されている場合でも、確認する順番を省略しないことが要点になります。移行手順書も、技術的な観点を洗い出したうえで作業ボリュームを検討する順番を示しており⁶、期日から逆算しつつ、何を確認できているかを先に整理しておくと、期日直前での想定外を減らせます。

政府向けの手順書は、民間の案件でも参考になるのか

この手順書が対象にしているのは、地方公共団体の標準準拠システムのガバメントクラウド移行です¹。民間の案件に同じ手続きが義務づけられているわけではありませんが、「切り替える前に何を可視化しておくか」という決めごとの組み立て方そのものは、対象を問わず参照できる整理として読めます。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「地方公共団体標準準拠システムのガバメントクラウド移行に係る手順書」4. ガバメントクラウド移行計画（2025年3月）
＊2 デジタル庁「地方公共団体標準準拠システムのガバメントクラウド移行に係る手順書」4.1 現行システム確認（アーキテクチャ）（2025年3月）
＊3 デジタル庁「地方公共団体標準準拠システムのガバメントクラウド移行に係る手順書」4.1 現行システム確認（外部システム間の関連性）（2025年3月）
＊4 デジタル庁「地方公共団体標準準拠システムのガバメントクラウド移行に係る手順書」4.1 現行システム確認（現行運用方法）（2025年3月）
＊5 デジタル庁「地方公共団体標準準拠システムのガバメントクラウド移行に係る手順書」4.1 現行システム確認（現行ＳＬＡ）（2025年3月）
＊6 デジタル庁「地方公共団体標準準拠システムのガバメントクラウド移行に係る手順書」4.2 システム移行計画（移行作業ボリューム）（2025年3月）
＊7 デジタル庁「地方公共団体標準準拠システムのガバメントクラウド移行に係る手順書」4.2 システム移行計画（移行における影響箇所の特定）（2025年3月）
＊8 デジタル庁「地方公共団体標準準拠システムのガバメントクラウド移行に係る手順書」4.2 システム移行計画（移行における運用変更点）（2025年3月）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）