大きな移行の案件に加わる話が来ると、まず気になるのは技術の新しさより、自分が担当する範囲がどこまでかということです。範囲が曖昧なまま作業を始めると、後になって「そこは想定していなかった」という差し戻しが起き、疲れの大半はそこから生まれます。行政のクラウド活用の方針は、刷新の項目を細かく分けて示しており、その分け方は基幹システムの移行案件全般にも当てはまります。この記事では、その分け方をたどりながら、自分が確かめておきたい担当範囲の見つけ方を整理します。読み終える頃には、次に確認したい一歩まで具体的に見えてきます。

1. 「移行」の中身は一様ではない

見積りの段階で切り分けられている実務

大きな移行の話は、ひとつの塊として語られることが多いものです。実際に現場に入ると、見積りの段階だけでも確かめる点がいくつも並んでいて、範囲の広さに戸惑う場面が出てきます。

行政のクラウド活用の方針では、見積りを取る段階の留意点が、ひとつの項目として個別に置かれています¹。刷新全体の話とひとまとめにせず、見積りという入口だけを取り出して確かめる姿勢が前提になっています。

この分け方は、担当範囲を確かめる側にとって助けになります。見積りの妥当性を見る役割と、刷新全体の設計を見る役割は、同じ人が担うとは限りません。参画前にどちらの役割かを言葉にしておくと、後の食い違いが減ります。

小規模なシステムの刷新も別枠として扱われている

大きな基幹システムの陰に隠れがちですが、小規模なシステムの刷新も、方針の中で独立した項目として扱われています²。規模が小さいからといって、大きな刷新のついでに片づけられる話ではありません。

規模の大小よりも、対象がどれだけ他のシステムと結びついているかのほうが、作業の重さを左右します。小さなシステムでも、周辺との連携が複雑であれば、確かめる項目は基幹システムと変わりません。

担当範囲を確かめるときは、見積りの留意点と小規模なシステムの刷新、どちらに近い依頼なのかを見極めることから始めたいところです。次の章では、複数の組織にまたがる刷新を一つにする場面を見ていきます。

図の作成：Remogu編集部。基幹システムの移行で分かれる範囲を整理したもので、統計データではありません

参画前に確認しておきたいのは、依頼の文書に「そのまま運ぶ」「ほどいて移す」「業務まで見直す」のどれに当たる作業が並んでいるかということです。呼び方がそろっていない案件もあるため、担当する工程を自分の言葉で言い換えてから、依頼した側とすり合わせておくと、後になって認識のずれに気づくという事態を防げます。

2. 組織ごとに分かれていたものを一つにするとき

独立して動いていたシステムが一つの管理下に入る

部署や拠点ごとに別々に運用されてきたシステムを一つにまとめる場面は、大きな移行案件の中でもとりわけ手間がかかる工程です。行政のクラウド活用の方針でも、組織ごとに独立していたシステムの刷新は、単独の項目として扱われています³。

別々に育ってきたシステムには、それぞれの部署の判断や運用の癖が染み込んでいます。一つにまとめるということは、その癖のどれを残し、どれを手放すかを決める作業でもあります。

この工程を任される場合、確かめたいのは統合の技術手順だけではありません。どの部署の判断を優先するかという業務側の合意形成が、どこまで済んでいるかも作業の見通しを左右します。

統合の前後で確かめる観点が入れ替わる

統合前は部署ごとのシステムが個別に動いているため、障害の影響範囲も部署内にとどまりやすい状態です。統合後は一つのシステムに複数の部署が乗ることになり、確かめる観点そのものが変わります。

個別最適で運用してきた期間よりも、統合後にどの部署の要望を優先するかを決める期間のほうが、関係者の調整に時間がかかります。ここを甘く見て日程を組むと、合意形成が追いつかない事態が起こります。

統合前は部署ごとに確認が完結しますが、統合後は優先順位の調整や影響範囲の把握など、確かめる観点そのものが広がります。下の表は、統合の前後で観点がどう変わるかを整理したものです。

観点	統合前(部署ごと)	統合後(一つのシステム)
障害の影響範囲	部署内にとどまりやすい	複数の部署に及ぶ
優先順位の決め方	部署ごとの判断で完結	部署間の合意形成が要る
データの持ち方	部署ごとに個別管理	共通の基準に合わせる
連絡する相手	該当部署の担当者のみ	関係する部署全体

図の作成：Remogu編集部。組織ごとのシステムが一つにまとまる関係を整理したもので、統計データではありません

統合の作業に途中から加わる場合は、すでに固まっている前提と、まだ決まっていない論点を最初に切り分けておくことが助けになります。前提を疑わずに作業を進めると、後から合意形成のやり直しに巻き込まれることがあります。

3. 複雑になった現行システムという前提

長く使われてきたシステムほど確かめる項目が増える

長期間にわたって手を加え続けてきたシステムは、当初の設計から離れた作りになっていることが珍しくありません。行政のクラウド活用の方針にも、長期間の改修で複雑になった現行システムへの対策が、後から追記されています⁵。

追記されたということは、当初の想定だけでは対応しきれない現場が実際にあったということです。複雑さは、システムの見た目の古さではなく、改修の積み重ねの厚みに表れます。

担当範囲を確かめるときは、対象のシステムがどれだけの期間、どれだけの改修を経てきたかを、早い段階で確認しておきたいところです。履歴が見えないまま作業を始めると、想定外の依存関係に後から気づくことになります。

レガシーシステムを抱える企業は今も一定数ある

利用する側の企業の半数程度が、今もレガシーシステムを抱えています¹⁰。移行の案件が途切れずにあるのは、この状態が特別なものではなく、広く見られる状況だからです。

半数程度という数字は、裏を返せば残りの半数がすでに刷新を終えているということでもあります。刷新を終えた側の事例よりも、今も抱えている側の事情のほうが、担当する案件では出会う機会が多くなります。

複雑さの度合いを数値だけで測ろうとすると、実態を見誤ります。担当する範囲を決める前に、関係者への聞き取りや過去の改修の記録など、複数の手がかりを組み合わせて確かめる姿勢が助けになります。

複雑になった現行システムという前提に立つと、任される範囲は「刷新する」だけでなく「複雑さを解きほぐす」作業を含むことが見えてきます。次の章では、そのまま使っても新しくはならない、という点を見ていきます。

改修の履歴を確認する手段が社内に整っていない場合は、現状の挙動から逆に読み解く作業も担当範囲に含まれることがあります。どこまで遡って調べるかを、依頼した側と先に決めておくと、作業の終わりが見えやすくなります。

4. そのまま使っても新しくはならない

置き換えても中身が自動的に新しくなるわけではない

クラウドに移すこと自体を目的にすると、見落としやすい点があります。クラウドが提供するサービスのすべてが新しいわけではありません⁶。市場でよく使われているクラウドほど、古くからの機能を残したまま提供を続けている場合があります。

置き場所を変えるだけで、中身の設計が古いままということは十分に起こります。任される範囲が「移す」だけなのか、「中身の設計まで見直す」ところまで含むのかは、依頼の段階で確かめておきたい違いです。

見た目の新しさよりも、実際に使われている機能や構成が更新されているかどうかのほうが、刷新の実態を映します。稼働実績だけを見て「新しくなった」と判断するのは早計です。

そのまま使える範囲と見直しが必要な範囲を切り分ける

現行のまま動かせる部分と、見直しが必要な部分を切り分けることが、担当範囲を言葉にする最初の一歩になります。切り分けの基準は、機能が古いかどうかよりも、業務の変化に合わせて調整され続けているかどうかに置きたいところです。下の表は、そのまま使える範囲と見直しが必要になりやすい範囲を整理したものです。

観点	そのまま使える範囲	見直しが必要になりやすい範囲
基本的な操作画面	継続して使える場合がある	業務の流れが変わると調整が要る
連携するデータの形式	既存の形式のまま動く	新しい連携先に合わせ直す
権限やアクセスの管理	既存の設定を引き継げる	組織変更に応じて見直す
古くからの個別機能	提供が続く場合がある	使われ方に合わせて整理する

見直しが必要な範囲に近い依頼ほど、業務側との調整に時間がかかります。切り分けの結果を早めに共有しておくことが、後の手戻りを防ぐ最初の一歩になります。

切り分けの結果を業務側に共有するときは、機能名を並べるよりも、日々の作業がどう変わるかで説明したほうが理解を得やすくなります。見直しが必要な範囲ほど、合意を取るのに時間がかかる点も踏まえておきたいところです。次の章では、使っているサービスが終わるときの知らせ方を見ていきます。

5. 終わりの知らせは事前に来る

サービス終了は通知とセットになっている

クラウド上のサービスにも、提供が終わる時期があります。使っているサービスが終わる場合、終了の時期と代わりの機能が事前に知らされます⁷。ある日突然、使えなくなるという話ではありません。

事前に知らされるということは、対応する側にも準備の時間があるということです。とはいえ、通知が来てから動き出す場合と、通知が来る前提で日程に余白を持たせておく場合とでは、任される範囲の重さが変わります。

担当する範囲を確かめるときは、通知を受け取った後の対応窓口になるのか、日頃から終了予定の情報を追って備える役割なのかを、依頼の段階で区別しておきたいところです。

通知の届く先が担当者個人ではなく、代表窓口になっている案件もあります。自分にきちんと情報が届く経路になっているかを、参画の早い段階で確かめておくと、対応の遅れを防げます。

通知を待つ側と備える側の違い

通知を待つだけの姿勢よりも、代わりの機能が示された時点で早めに検証を始める姿勢のほうが、切り替えにかかる期間を短くできます。事前に知らされる仕組みは、備える側に時間を渡すための仕組みでもあります。

この違いを意識しておくと、依頼された範囲が「知らせを受けて動く」役割なのか、「知らせが来る前から動く」役割なのかを、参画前に確かめやすくなります。

備える側の役割を担う場合は、終了の知らせを受け取る前から、代わりの機能の情報を自分から追いかける動き方が求められます。待つ姿勢のままでは、切り替えの検討に着手する時期が遅れてしまいます。

通知の内容を確認するだけで終わらせず、代わりの機能が今の業務にどう影響するかまで確かめる。そこまでを担当範囲に含めるかは、依頼した側と早めにすり合わせておきたい点です。次の章では、事業者からの提案を読むときに確かめたい観点を見ていきます。

6. 提案が方針に沿っているかを読む

沿っているかどうかを留意して読む

事業者から出てくる提案は、専門的な言葉で書かれている場面があり、内容の是非を判断しにくいことがあります。行政のクラウド活用の方針では、提案がこの方針に沿っているかどうかを確かめる必要があります⁸と明記されています。

方針に沿っているかどうかを確かめるというのは、提案の書きぶりをそのまま受け取らないということでもあります。専門用語が並んでいても、実際に指針の要求を満たしているかは別に確認する必要があります。

沿っている記述とずれている記述を見分ける

沿っている提案は、対象範囲や体制、日程といった要素が、方針の項目と対応づけて書かれています。ずれている提案は、要素は並んでいても、どの項目に対応するのかが曖昧なまま進みます。

曖昧な提案よりも、対応関係が明記された提案のほうが、後になって「聞いていた話と違う」という食い違いを防ぎやすくなります。担当範囲を確かめる側にとっても、対応関係の有無は読み解く手がかりになります。

下の比較表は、沿っている記述とずれている記述の違いを整理したものです。提案書を読むときの確認材料として使ってください。

確認する項目	沿っている記述	ずれている可能性がある記述
対象範囲	担当箇所が具体的に書かれている	範囲の説明が曖昧なまま進む
体制	役割ごとの担当が示されている	誰が何を担うか触れられていない
日程	方針の項目に沿った区切りがある	全体を一括りにした日程だけ

比較表の観点を手元に置いておくと、提案を受け取った段階で疑問点を挙げやすくなります。疑問をそのままにせず、対応関係を確認してから作業を始めることが、担当範囲を守る一番の近道です。

提案の中に、方針のどの項目にも対応しない記述が混ざっている場合もあります。そうした記述を見つけたら、無視するのではなく確認したい論点として扱い、依頼した側に問い合わせる材料にしてください。

図の作成：Remogu編集部。提案書を確認するときの観点を整理したもので、統計データではありません

7. 移した後にも刷新の時期がある

移行はゴールではなく次の刷新までの通過点

移行が終わった時点で、案件が完結すると考えるのは早いかもしれません。クラウドへ移した後の刷新の時期についても、方針の中に項目が置かれています⁴。移行は終着点ではなく、次の刷新までの通過点だということです。

移行直後は落ち着いて見えても、しばらく経てば次の見直しの話が出てきます。担当範囲を確かめるときは、今回の案件が「移行だけ」なのか「その先の刷新まで」を含むのかを、早い段階で言葉にしておきたいところです。

移行の完了だけを区切りにするよりも、次の刷新の時期まで視野に入れて計画するほうが、後から呼び戻される回数を減らせます。担当範囲の終わりは自分で決めるのではなく、方針が示す区切りに沿って確かめる姿勢が要ります。

図の作成：Remogu編集部。移行後の時間の流れを整理したもので、統計データではありません

運用フェーズも計画に含める

運用が始まった後も改善を続ける前提で、予算や体制、日程を計画します⁹。稼働した時点で計画が終わるのではなく、運用の期間そのものが計画の対象に含まれているということです。

この前提に立つと、担当範囲には「動かす」ところまでではなく、「動かし続けながら整える」ところまでが含まれることがあります。参画する段階で、運用フェーズにどこまで関わるのかを確かめておくと、後になって役割が広がりすぎることを防げます。

大きな移行の案件で消耗するのは、技術そのものより範囲が決まっていないことです。見積りの留意点から運用フェーズの計画まで、方針が示す区切りに沿って自分の担当を言葉にしていく。それが、移行案件に参画する最初の一歩になります。

担当する範囲を自分の言葉で説明できるようになると、参画先を選ぶときの基準も明確になります。Remoguが扱う案件でも、案件の90%以上がフルリモート可能です。場所にとらわれず、積み上げてきた経験を活かせる範囲かどうかを、条件と合わせて確かめてみましょう。

見積りの段階でどこまで確認しておけば安心ですか

見積りの留意点は方針の中でも独立した項目として扱われています¹。担当する範囲が見積りの確認までなのか、その先の刷新設計まで含むのかを、参画前に言葉にしておくと、後の役割のずれを防ぎやすくなります。

組織ごとに分かれたシステムを一つにする案件では何を優先して確認すればよいですか

統合前後で確かめる観点が変わる点を押さえておくことです。障害の影響範囲や優先順位の決め方は、統合後には部署間の合意形成が必要になります³。担当する範囲がどちらの段階に近いかを、早めに確認しておきたいところです。

移行が終わった後も関わりは続きますか

方針には移行後の刷新の時期についての項目があります⁴。運用が始まった後も改善を続ける前提で計画することも示されています⁹。関わりが移行の完了だけで終わるとは限らないと考え、自分がどこまでの範囲を任されているのかを、参画前に一度言葉にしておくと安心です。

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

出典・参考情報

＊1 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見積りの作法（2026年）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」規模で変わる（2026年）
＊3 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」分かれている前提（2026年）
＊4 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」移した後の話（2026年）
＊5 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」複雑さへの対策（2026年）
＊6 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」古い機能も残る（2026年）
＊7 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」終わりの知らせ（2026年）
＊8 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」提案を読む（2026年）
＊9 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」計画の作り方（2026年）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」レガシーの残存（2025年4月）