Oracle移行の案件を打診されると、まず目が向くのは移行先の技術構成です。ですが、デジタル庁が示す方針を読むと、判断の材料はもっと手前にあることが分かります。クラウドへ移すことと、システムを刷新することは同じ作業ではありません。この記事では、その違いを判断の材料に変える順番を整理します。

1. 移せば新しくなるわけではない

クラウドが提供するサービスにも古いものが残っている

Oracle移行の打診を受けたとき、案件情報にはクラウド化という言葉だけが並んでいることがあります。ですが方針は、市場シェアの大きいクラウドであっても古い機能が残ったまま提供されている場合があり、提供されるサービスのすべてがモダンなものとは限らないと述べています⁶。

つまり、移行先を決めただけでは、システムの中身が新しくなったとは言えません。ここを最初に共有できるかどうかで、参画したあとの認識のずれの大きさが変わってきます。

この一文を軽く読み流すと、移行の見積りだけを固めて、構成の見直しを後回しにする進め方になりがちです。方針が項目として置いているのは、この見落としを防ぐためだと考えられます。

案件情報の中に「刷新」という言葉が出てこない場合でも、複雑さへの対策が求められている可能性はあります。言葉の有無だけで判断せず、方針が挙げている論点に当てはまるかどうかを見る視点が役に立ちます。

そのまま使うことと構成を見直すことの違い

方針はもう一段踏み込んで、提供されたサービスをそのまま使ったとしても、モダンなアーキテクチャになるとは限らないとも述べています⁷。移すことと、構成を見直すことは、別の作業として扱われているのです。

移行案件を受ける立場からすると、この違いは提案の組み立て方に直結します。移行だけを請け負う案件なのか、構成の見直しまで含む案件なのかで、必要な経験も、確認したい論点の数も変わってきます。

案件情報を読む段階で、この2つのどちらを指しているのかを確かめておくと、参画後に想定外の作業範囲が出てくる場面を減らせます。

構成の見直しまで含む案件では、移行を担当する人と、その先の構成を検討する人が別々に動いていることもあります。誰がどこまでの判断を担っているのかを早めに把握しておくと、確認する相手に迷わずに済みます。次の章では、方針が判断の材料として置いている項目を具体的に見ていきます。

出典：デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（2026年）をもとに作成

2. 判断の材料として置かれている項目

複雑になった現行システムへの対策

方針には、長期間の改修で複雑になった現行システムへの対策が、判断の材料として追記されています¹。これはOracleに限らず、稼働年数の長いシステムに共通する論点です。

複雑さの中身は案件ごとに異なります。テーブルの数が多いのか、バッチ処理が絡み合っているのか、外部システムとの接続点が多いのか。この整理を先に済ませておくと、見積りの精度も上がります。

技術力の高さよりも、複雑さを言語化して伝えられるかどうかのほうが、この段階では重宝されます。整理して共有する力が問われる場面だからです。

複雑さを整理する作業は、参画してからでは遅れて始まることもあります。打ち合わせの早い段階で、現行システムのどこが複雑になっているかを一緒に確かめる時間を持てるかどうかも、案件を見るときの材料になります。

見積りを取る段階での留意点

見積りを取得する際に留意したい点も、判断の材料の一つとして方針に置かれています²。見積りそのものより、その前提が問われているという整理です。

見積りは、金額の大小だけで判断されるものではありません。何を確認したうえでその金額になっているのか、根拠の説明が伴っているかどうかが、方針が示す留意点に近い視点です。

受ける側として、見積りの前提条件を確認する習慣を持っておくと、提案の内容が方針に沿っているかどうかを見る、後の章の観点ともつながります。

見積りの数字だけを追うより、前提となる作業範囲がどこまで含まれているかを読み解くほうが、後工程での認識のずれを防ぎやすくなります。金額の比較よりも、範囲の比較を先にする進め方です。

項目	何を確認する項目か
複雑化した現行システムへの対策1	稼働年数の長いシステムの複雑さにどう向き合うか
見積りの取得時の留意点2	見積りの前提や根拠をどう確認するか
小規模なシステムにおける刷新3	規模が小さいシステムの刷新をいつ検討するか
組織ごとに独立していたシステムの刷新4	組織ごとに分かれた構成をどう扱うか
クラウド移行後のシステム刷新タイミング5	移行のあとに刷新の時期をどう置くか

出典：デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（2026年）をもとに作成

3. 刷新のタイミングをいつに置くか

小規模なシステムは刷新を先に検討する

方針は、小規模なシステムについて、刷新そのものを検討する項目を置いています³。規模が小さいほど、移行と同時に刷新まで進めやすいという整理です。

小規模なシステムを受ける案件では、移行の提案の中に刷新の視点が含まれているかどうかを、早い段階で確認しておくと、後工程での手戻りを避けやすくなります。

規模が小さいという条件は、複雑さが少ないことと同じ意味ではありません。小規模でも、外部接続や独自の処理が多ければ、確認する項目は増えます。

「規模が小さい」という言葉が案件情報に出てきたときは、対象のシステムがいくつあるのか、他のシステムとどこまでつながっているのかを、打ち合わせの中で具体的に確認しておくと、後の見立てが立てやすくなります。

クラウド移行後に刷新のタイミングを置く考え方

一方で方針は、クラウドへ移行したあとのシステム刷新のタイミングについても、別の項目として置いています⁵。移行と刷新を同時に決め切らない進め方も、選択肢として扱われているということです。

この考え方に沿う案件では、移行の直後ではなく、運用が安定したあとに刷新を検討する計画になっている場合があります。稼働してすぐの提案より、運用実績を踏まえた提案のほうが、精度は高くなりやすいという整理です。

受ける側としては、案件がどちらの考え方に立っているかを確認しておくと、参画中に求められる作業の見通しが立てやすくなります。次の章では、組織ごとに分かれたシステムという論点を見ていきます。

案件情報だけでは、どちらの考え方に立っているか分からないこともあります。参画前の打ち合わせで、刷新の検討時期について尋ねておくと、認識のずれを防ぎやすくなります。

システムの規模・考え方	刷新をいつ検討するか
小規模なシステム3	移行と合わせて刷新まで検討する
移行後に刷新を置く考え方5	運用が安定したあとに刷新のタイミングを置く

出典：デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（2026年）をもとに作成

Remoguで扱う案件は、90%以上がフルリモート可能です。移行案件で培った整理の視点は、次に関わる案件でもそのまま活かせます。

4. 組織ごとに分かれたシステムという論点

組織ごとに独立していたシステムの刷新

方針には、組織ごとに独立していたシステムの刷新も、判断の材料として置かれています⁴。部署や拠点ごとに別々に運用されてきたシステムを、どう扱うかという論点です。

組織ごとに分かれたシステムは、それぞれの部署の業務に合わせて手が加えられてきた経緯があります。統合するのか、個別に刷新するのかで、必要な調整の量は大きく変わります。

受ける側としては、この論点が案件情報に含まれているかどうかで、作業範囲の広がり方が変わってきます。1つのシステムの話なのか、複数の組織にまたがる話なのかを、早めに確かめておきたい点です。

複雑さと組織構造が重なる場面

組織ごとに分かれたシステムは、長期間の改修で複雑になった現行システムへの対策¹とも重なりやすい論点です。分かれて運用されてきた期間が長いほど、個々のシステムの複雑さも積み重なっています。

複雑さの整理を、組織の数だけ別々に行うのか、共通する部分をまとめてから行うのかでも、進め方は変わります。まとめてから整理するほうが、重複した確認作業は減らしやすくなります。

組織ごとに分かれたシステムを受ける案件では、担当する範囲が一部の組織に限られているのか、複数の組織にまたがるのかによって、必要なやり取りの量も変わってきます。

組織構造に関わる論点は、技術的な判断だけでは決まりません。次の章では、事業者からの提案が方針に沿っているかどうかを見る視点に移ります。

5. 提案が方針に沿っているかを見る

提案が方針に沿っているかという観点

方針は、事業者からの提案が方針に沿ったものであるかどうかに留意する必要があるとしています⁸。提案の内容を、方針が示す項目と照らし合わせて見るという視点です。

提案書には移行の手順や体制が並びますが、それぞれの項目が方針の考え方に沿っているかどうかまで書かれているとは限りません。受ける側からもこの観点を意識しておくと、提案の抜けに気づきやすくなります。

提案の中身を細かく検証する立場になくても、方針が挙げている項目を知っておくだけで、打ち合わせの場で確認したい質問が具体的になります。抽象的な不安より、確かめる項目のほうが、話を前に進めやすくなります。

方針に沿っているかどうかは、1つの項目だけでは判断できません。前の章で見てきた複雑さへの対策や組織ごとの論点も含めて、全体として整合しているかを見る必要があります。

見積りの根拠と方針への適合を合わせて見る

見積りの取得時の留意点²も、この観点と結びついています。見積りの根拠が、方針が示す項目のどこに対応しているかを確認できると、提案全体の整合性を見やすくなります。

根拠が示されていない見積りより、項目ごとに対応関係が示されている見積りのほうが、後工程での認識のずれは起きにくくなります。

提案の各項目を、方針が挙げている項目と1つずつ突き合わせる作業は手間がかかりますが、抜けている論点に気づく機会にもなります。

受ける側として提案の整合性を確認する視点を持っておくと、参画後に方針転換が起きた場合にも、どこに立ち返って確認すればよいかが分かりやすくなります。次の章では、運用まで含めた効果の話に移ります。

確認する観点	見る内容
方針への適合8	提案の各項目が方針の考え方に沿っているか
見積りの根拠2	見積りの前提が方針の項目に対応しているか

6. 運用を変えないと効果が出ない

運用が従前のままでは効果が出ない

方針は、システムの運用が従前のままでは、コスト削減の効果は十分に出ないと述べています⁹。移行や刷新そのものよりも、そのあとの運用の変え方に効果の大きさが左右されるという整理です。

運用を変えるというのは、担当者を入れ替えることではなく、確認の頻度や、改善を反映する手順を見直すことを指しています。仕組みを変えずに看板だけ変えても、効果は積み上がりません。

移行の作業だけを終えて離れる進め方より、運用が回り始めたあとの様子まで見届ける進め方のほうが、方針が求めている効果には近づきやすくなります。関わる期間の長さが、そのまま評価につながる場面です。

受ける側の視点では、運用フェーズに関わる案件かどうかで、求められる動き方が変わります。移行だけで完結する案件より、運用の見直しまで含む案件のほうが、継続的に関われる可能性が高くなります。

受ける案件が運用フェーズに関わるものであれば、改善提案を継続的に行う役割を担う場合もあります。移行時点だけの関わりとは、求められる視点の幅が変わってきます。

改善を続ける前提で計画する

方針はさらに、運用フェーズも含めて日々改善していくことを前提に、予算や体制、日程を計画する必要があるとしています¹⁰。移行後の改善を、後から追加する作業ではなく、最初から計画に組み込む考え方です。

この前提に立つと、参画のタイミングも変わってきます。移行が終わったあとの運用改善の段階から声がかかる案件も、方針に沿った進め方をしている案件だと見ることができます。

この考え方を踏まえると、見積りの前に確認しておきたい順番も見えてきます。次の章で整理します。

7. 見積りの前に決める順番

見積りの前に確認しておきたい順番

ここまで見てきた項目を、見積りを受け取る前の順番として並べ直すと、まず現行システムの複雑さを整理し、次に見積りの取得時の留意点²を確認し、そのうえで運用フェーズの計画¹⁰まで含めて見る、という流れになります。

順番を先に決めておくと、見積りが出てきた段階で、何が含まれていて何が含まれていないのかを判断しやすくなります。金額だけを見て判断すると、運用フェーズの計画が抜けたまま話が進むことがあります。

受ける側としても、この順番を共有できると、参画前の打ち合わせで確認したい論点が明確になります。方針が示す項目を、そのまま確認の材料として使う進め方です。

順番通りに確認できる案件ばかりとは限りません。すでに見積りが出ている段階で声がかかることもあります。その場合でも、抜けている項目だけを後から確かめるという使い方ができます。

この順番は、方針の項目をそのまま並べ替えただけのものです。特別な手法ではなく、方針に書かれている論点を、確認する場面ごとに並べ直したものだと考えると扱いやすくなります。

まず、今声がかかっている案件が、この順番のどこまでを含んでいるかを確かめるところから始めてみましょう。含まれていない部分があれば、それを補う形で参画後の関わり方を決めていけます。

出典：デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（2026年）をもとに作成

小規模なシステムと大規模なシステムでは進め方が変わりますか

方針では、小規模なシステムについては刷新そのものを検討する項目が置かれ³、クラウド移行後に刷新のタイミングを置く考え方も別に示されています⁵。規模によって、刷新を同時に進めるか、後に置くかの整理が変わります。

案件情報に規模の記載がない場合は、参画前の打ち合わせで、対象システムの構成やシステムの数を尋ねておくと、どちらの考え方に近いかが見えてきます。

見積りを受け取ったあとに確認しておきたいことはありますか

見積りの取得時の留意点²に加えて、提案が方針に沿ったものであるかどうかも確認したい点です⁸。金額の根拠と方針への適合を合わせて見ておくと、参画後の認識のずれを防ぎやすくなります。

見積りに前提条件が書かれていない場合は、その場で確認しておくと、後から作業範囲について認識がずれる場面を減らせます。

運用フェーズまで含めて確認する必要はありますか

方針は、運用が従前のままでは効果が十分に出ないとし⁹、運用フェーズも含めて計画する必要があるとしています¹⁰。移行や刷新の提案の中に、運用フェーズの計画が含まれているかどうかも確認しておきたい点です。

運用フェーズの計画が案件情報に書かれていない場合でも、打ち合わせの中で運用の見直しをどう位置づけているかを尋ねてみると、案件の性質が分かりやすくなります。

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

出典・参考情報

＊1 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」複雑さへの対策（2026年・2026年8月確認）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」見積りの作法（2026年・2026年8月確認）
＊3 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」規模で変わる（2026年・2026年8月確認）
＊4 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」分かれている前提（2026年・2026年8月確認）
＊5 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」移した後の話（2026年・2026年8月確認）
＊6 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」古い機能も残る（2026年・2026年8月確認）
＊7 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」使えば新しくはならない（2026年・2026年8月確認）
＊8 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」提案を読む（2026年・2026年8月確認）
＊9 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」刷新の限界（2026年・2026年8月確認）
＊10 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」計画の作り方（2026年・2026年8月確認）