案件の説明に「クラウドへの移行」と書かれていても、実際に手を動かす範囲はそこで終わりません。方針の改定では画面や帳票の見直しについても追記され¹、長く手を入れてきた現行システムが複雑になっている前提も明記されました²。土台を動かすだけの仕事だと思って参画すると、後半になって別の宿題が並びます。まず、担当する範囲がどこまで広がるのかを先に押さえておきます。

1. 移行の主題は途中で移る

「土台を動かす」だけでは区切りがつかない

業務システムの移行案件に参画すると、最初に渡される資料には「クラウドへ移す」という言葉が並びます。土台さえ動けば区切りがつくように見え、動かす対象を絞って考えたくなります。ところが実際に手を動かす範囲は、そこで終わらないことがほとんどです。説明の言葉と、担当する作業の広さが一致しない場面が、参画してから出てきます。

政府のクラウド利用に関する方針は2026年の改定で、画面や帳票の見直しについても追記しました¹。土台の移設だけを見ていたところに、利用者が直接触れる部分の話が後から加わる形です。範囲は最初の説明よりも広く見ておいたほうが、途中で戸惑わずに進められます。担当する作業の輪郭を、早い段階で自分なりに引き直しておく価値があります。

「土台を動かす仕事」より「業務の見え方まで直す仕事」のほうが、後半で慌てずに済みます。参画の早い段階で、どちらを頼まれているのかを事業者側に確かめておくと、終盤の手戻りを減らせます。範囲の確認は、遠慮する場面ではなく、最初にすませておきたい作業のひとつです。

複雑になった現行システムという前提も並んで置かれている

同じ改定では、長期間の改修を重ねて複雑になった現行システムへの対策も追記されました²。土台の移設と、複雑化した現行システムの扱いが、同じ方針の中で並んで語られている形です。片方だけを見て進めると、もう片方が終盤にまとまって出てくることになります。

「複雑になっている」という前提がすでに文書に書かれているということは、参画する側が現行システムの見通しの悪さを個人の力量不足のように感じる必要はないということでもあります。前提として織り込まれている課題だと捉えたほうが、落ち着いて向き合えます。分からない部分を早めに言葉にして共有する姿勢のほうが評価されやすい場面です。

移行の主題は、土台・処理・画面と帳票という順に、参画期間の中で少しずつ移っていきます。次の章では、なぜ画面や帳票の話が終盤にまとまって出てくるのか、その理由を具体的に見ていきます。

図の作成：Remogu編集部。方針の追記内容をもとに、直す範囲の広がりを整理したもので、統計データではありません

2. 画面と帳票が後から出てくる理由

なぜ終盤にまとめて出てくるのか

画面や帳票の話が終盤にまとまって出てくるのは、偶然ではありません。方針の中で、土台の話とは別枠として画面や帳票の見直しが追記されているためです¹。土台の作業を優先して進めると、画面や帳票の確認は自然と後回しになり、気づいたときには残された時間が少なくなっています。

後から出てくる理由が分かっていれば、参画の早い段階で「画面や帳票も見直しの対象になっているか」を確認しておく余地が生まれます。何も聞かずに進めるより、最初に一言確かめておくほうが、終盤の負担を減らせます。確認する側から動くことで、範囲の説明を待つだけの立場から抜け出せます。

土台の移設が早く終わるプロジェクトほど、画面・帳票の検討に充てられる時間が短くなりがちです。「早く終わらせること」より「後半に何が残るかを早めに知ること」のほうが、担当する範囲を安定させます。進み方の速さよりも、見通しの正確さを優先したい場面です。

移すだけの場合と、業務まで直す場合を分ける観点

移すだけの場合と、業務まで直す場合とでは、対象になる部分も、話が出てくるタイミングも変わります。次の表は、その分かれ目を観点ごとに整理したものです。事業者側からどちらの依頼を受けているのかを、参画の初期に確認しておく材料として使えます。表を見た上で、自分が担当する範囲がどちらに近いかを当てはめてみます。

観点	移すだけの場合	業務まで直す場合
対象になる部分	土台（インフラ）が中心	土台に加えて画面・帳票も対象
出てくるタイミング	早い段階で見えている	終盤にまとまって見えてくることがある
手を動かす担当への影響	インフラの作業が中心になる	画面や帳票の仕様確認まで担当が広がる

表を見比べると、「土台の移設で完了とする」進め方と、「画面・帳票まで含めて直す」進め方とでは、途中で確認しておきたいことが違うと分かります。担当する範囲がどちらになりそうか、参画の早い段階で言語化しておくと、終盤の認識のずれを防げます。

図の作成：Remogu編集部。方針の追記内容をもとに、範囲の想定を比較したもので、統計データではありません

画面・帳票まで範囲に入る案件かどうかは、契約前の会話で決まっていることがほとんどです。参画してから慌てないために、最初の会話で確かめておきたい観点として、次の章以降でも具体的に触れていきます。

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

複雑さは個人の問題ではなく、前提として書かれている

長年手を入れてきた現行システムが複雑になっているという前提は、方針の中にすでに書き込まれています²。参画してから「思っていたより込み入っている」と感じても、それは前提どおりの状態だと捉えられます。見通しの悪さを、自分の理解不足のせいだと抱え込む必要はありません。

複雑さが前提になっているということは、参画してすぐに全体の見通しを立てられることを期待されているわけではないということでもあります。分からない部分を早めに言葉にして共有するほうが、抱え込んで進めるより結果的に早く進みます。疑問を持ち越さない姿勢のほうが、現行システムの複雑さとは相性が良いといえます。

「一人で全体を把握してから動く」より「分かった範囲から確認しながら動く」ほうが、複雑になった現行システムとは相性が良い進め方です。分かっている範囲を先に固め、分からない範囲を早めに切り分けていく進め方に切り替えます。

更新への対応は「一度きりの作業」ではない

加えて、サービスの更新への対応は特別なイベントではなく、通常のアップデートとして日常的に対応していく必要があるとも書かれています¹⁰。移行の作業が一区切りついた後も、更新への対応は続く前提として置かれています。

「移行が終われば手が離れる」という見え方をしていると、日常的な更新対応が始まったときに想定外に感じられます。参画の時点で、稼働開始後にも対応が続く可能性を織り込んでおくと、後から慌てずに済みます。契約の話し合いでも、この前提を共有しておく価値があります。

複雑になった現行システムという前提と、更新への日常的な対応という前提は、どちらも「移行して終わり」ではないことを示しています。次の章では、クラウドが提供するものをそのまま使った場合に何が起きるのかを見ていきます。

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

提供される機能がすべて新しいとは限らない

市場シェアの大きいクラウドでは、古い機能も継続して提供されており、提供されるサービスのすべてが新しいものとは限らないと方針に書かれています³。クラウドに移せば新しい環境に切り替わるという見え方は、そのままでは成り立ちません。

さらに、提供されるサービスをそのまま使ったとしても、必ずしも新しい構成になるわけではないとも示されています⁴。土台を移す作業と、構成を新しくする作業は、別の作業として扱ったほうが実態に近い見方です。ひとつの作業で両方が済むとは考えないほうが安全です。

「移せば新しくなる」より「何を新しくするかを選んで初めて新しくなる」という見方のほうが、担当する作業の中身と一致します。選ぶ手前の段階で立ち止まる必要があるという前提を、最初に共有しておきたいところです。

そのまま使う場合と、見直す前提で使う場合を分ける観点

そのまま使う場合と、見直す前提で使う場合とでは、残る古さの扱い方が変わります。次の表は、サービスの新しさ・構成の前提・避ける対象の扱いという3つの観点から、その違いを整理したものです。表の右側の列にある動きは、いずれも手を止めて確認する工程を含んでいます。

観点	そのまま使う場合	見直す前提で使う場合
サービスの新しさ	古い機能がそのまま残ることがある	何が新しく何が残るかを都度確かめる
構成の前提	必ずしもモダンな構成にはならない	構成を見直す前提で選び直す
避ける対象の扱い	気づかずに使ってしまうことがある	事前に対象から外しておく

そのまま使う進め方には無い工程が、見直す前提の進め方には組み込まれています。「都度確かめる」「選び直す」「事前に外す」という動きを、誰がどの段階で担当するのかを、参画の初期に確認しておきます。

図の作成：Remogu編集部。方針が示す内容をもとに、想定と実際の違いを整理したもので、統計データではありません

案件の90%以上がフルリモート可能です。Remoguでは、こうした見直しの工程を含む業務システムの移行案件も扱っています。何を新しくするかを自分で確かめながら進められる案件かどうか、まず登録して条件を確かめてみましょう。

5. 選ばない判断も要る

使わない対象になっているサービスがある

提供されるサービスの中には、サーバーの構築を前提とするものなど、使用を使用を避けたいサービスもあると方針に書かれています⁵。選べる範囲が広いことは良いことですが、選ばない判断も同じくらい必要だという前提です。選択肢の多さを、そのまま良さだと受け取らないほうが安全です。

「使えるかどうか」だけで選ぶと、後になって避けたほうがよかったサービスに気づく場面が出てきます。選定の初期段階で、対象から外すサービスを先に確認しておくほうが、手戻りを防げます。使える範囲を広げる前に、使わない範囲を決めておく順番です。

「使えるものを増やす」より「使わないものを先に決める」ほうが、複雑になった現行システムを移す作業では効きます。選択肢を絞ってから比較したほうが、検討にかかる時間も安定します。

選ばない判断を、誰がいつ確認するか

使わない対象になっているサービスの確認は、参画してすぐの段階で担当することが多い作業です。事業者側がすでに方針を持っている場合もあれば、確認自体をこれから進める場合もあります。どちらの状況にあるのかを、最初の打ち合わせで見極めておきます。

避ける対象として名前が挙がっているサービスを、事前に一覧として持っておくと、提案や見積りを読むときの判断が早くなります。一覧を自分で作るだけでも、参画先との会話がかみ合いやすくなります。次の章で扱う「提案を読む」場面にもつながる準備です。

選ばない判断は、消極的な作業に見えて、実は範囲を安定させる作業でもあります。避ける対象を先に決めておくことが、後半の手戻りを減らす一番の近道になります。

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

提案が方針に沿っているかを確かめる

事業者からの提案が方針に沿ったものかどうかについて、留意する必要があると書かれています⁶。提案書に書かれている内容をそのまま受け取るのではなく、方針と照らし合わせて読む姿勢が前提になっています。読み方そのものが確認したい対象だと考えます。

提案を読む担当は、必ずしも意思決定をする立場とは限りません。それでも、方針に沿っているかどうかを確認できる材料を持っておくと、クライアントとの協議の場で意見を出しやすくなります。材料を持たずに読むより、確認する視点を持って読むほうが、提案の見え方が変わります。

「提案書の完成度」より「方針との整合性」を先に見るほうが、後から手戻りの少ない判断につながります。見た目が整った提案ほど、方針との照らし合わせを省略したくなるので、あえて先に確認しておきたい観点です。

提案書を読むときに確かめる観点

提案を読むときに確かめておきたい観点は、方針との整合だけではありません。見積りを取得する段階の留意点も、項目として置かれています⁷。次の表は、確かめること・根拠をあわせて整理したものです。

観点	確認すること	根拠
方針との整合	提案が方針に沿っているか	提案が方針に沿ったものであるか否かについて留意する必要があります6
見積りの前提	見積りの前提条件が明確か	見積りの取得時の留意点として置かれています7
対象範囲の明確さ	画面・帳票まで対象に入っているか	前の章までに整理した範囲の確認をもとにします

表に挙げた観点は、いずれも提案を受け取った直後に確認できる項目です。方針に沿っているかどうか、見積りの前提が明確かどうかを、最初の読み合わせで一度確認しておくと、後工程での確認が減ります。

図の作成：Remogu編集部。方針が示す確認事項をもとに整理したもので、統計データではありません

こうした観点を自分の言葉で持っておくと、参画後の打ち合わせでも発言しやすくなります。Remoguでは、こうした確認を重ねながら進める業務システムの案件も扱っています。条件を知ることから始めてみるのも一つの道です。

7. 層で書き分けられている前提と、続ける計画

SaaSは明示され、IaaS・PaaSが原則として書かれている

この方針は原則としてIaaSとPaaSを中心に記述し、SaaSについてはSaaSと明示して記述すると書かれています⁸。読んでいる項目が、土台に近い層の話なのか、業務側に近い層の話なのかを、まず見分ける手がかりになります。

層によって書き分けられているということは、資料を読むときに「これはどの層の話か」を都度確認する必要があるということでもあります。層を意識せずに読むと、土台の話と業務側の話を混同したまま進めてしまいます。読み違えたまま作業に移ると、後で整理し直す手間が生まれます。

「全体をまとめて理解する」より「層ごとに分けて理解する」ほうが、この方針とは相性が良い読み方です。層を分けて整理しておくと、担当する範囲を説明するときにも言葉にしやすくなります。

稼働後も改善を続ける前提で計画する

稼働後も含めて、日々改善していくことを前提に予算・体制・スケジュールなどを計画する必要があるとも書かれています⁹。移行の作業が終わった時点を最終ゴールとして計画すると、この前提とはずれてしまいます。

稼働開始後の改善が前提に含まれているということは、参画の期間が移行作業だけで区切られるとは限らないということでもあります。稼働開始後の対応まで視野に入れて、参画の条件を確認しておくと安心です。区切りの位置を、資料と実際の作業の両方で確かめておきます。

移行の主題が途中で移ること、複雑になった現行システムが前提であること、そのまま使っても新しくはならないこと、選ばない判断が要ること、提案を方針と照らして読むこと、層を分けて理解し稼働後も計画を続けること。ここまでの観点を一通り押さえておけば、担当する範囲の広さに驚かずに済みます。

業務システムの移行案件は、インフラの技術だけで対応できますか

土台の移設だけで完結する案件もありますが、画面や帳票の見直しが方針に追記されている以上¹、業務側の確認まで担当する場面は増えています。インフラの技術に加えて、業務側の仕様を読み解く姿勢を持っておくと、任せてもらえる範囲が広がります。

現行システムの複雑さは、参画してからでないと分かりませんか

複雑になっているという前提はすでに方針に書かれているため²、参画前の面談の段階で、複雑さの度合いや対策の状況について確認しておくことができます。何も聞かずに参画するより、事前に一言確認しておくほうが、参画後の見通しが立てやすくなります。

こうした案件の経験は、次の案件を探すときにどう活きますか

方針に沿っているかを確認する視点や、避ける対象を見極める視点は、業務システムを扱う別の案件でも共通して使える経験になります。積み上げてきた経験を、次の案件を選ぶときの材料として言語化しておくと、参画先との協議もスムーズになります。まず登録して、自分の経験に近い案件があるかを確かめてみませんか。

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

出典・参考情報

＊1 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」業務側の見直し（2026年）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」複雑さへの対策（2026年）
＊3 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」古い機能も残る（2026年）
＊4 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」使えば新しくはならない（2026年）
＊5 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」選ばない判断（2026年）
＊6 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」提案を読む（2026年）
＊7 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見積りの作法（2026年）
＊8 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」層で書き分ける（2026年）
＊9 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」計画の作り方（2026年）
＊10 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」更新の捉え方（2026年）