Azureの案件情報を開くと、構成図の隅に別の名前のサービスが並んでいることがあります。Azureひとつで完結すると思って参画すると、初日から前提が崩れます。そこにあるのは複数のクラウドを併存させる考え方で、乗っている場所よりも扱う層のほうが作法を決めています。入る前に何を確かめればよいかを、公開されている方針¹から整理します。

1. 乗っていること自体は目的ではない

古い機能が残っていることは欠陥ではない

市場シェアの大きいクラウドを開くと、公開された時期の異なる機能が同じ画面に並んでいます。新しい仕組みだけが揃っているわけではなく、クラウドが提供するサービスの全てが新しいものとは限りません²。この事実は、参画先の構成を最初に見たときの受け止め方に関わります。

古い機能が残っているのは放置ではなく、互換性を保つための設計です。ここを取り違えると、既存の構成をすべて疑ってかかるところから作業を始めてしまい、確かめる範囲が要らないほど広がります。まず見るのは、その機能がいつ選ばれたかという時期です。

構成の古さよりも、選ばれた理由のほうが判断の起点になります。導入時点で理にかなっていた選択が、いま見ると古く映ることは珍しくありません。理由を先に確かめれば、置き換えの是非を後から冷静に検討できます。

参画前の面談では、古い機能を残している理由を尋ねられる場面があります。答え方に迷ったときは、否定から入らず、まず互換性を保つ目的で残されている可能性を挙げてみます。ここで慌てて刷新の提案を並べるより、現状を正しく読み取ろうとする姿勢のほうが伝わります。

そのまま使っても新しい構成になるとは限らない

クラウドに乗せ替えれば構成が新しくなる、という期待もよく聞きますが、そのまま使ったとしても新しい構成になるとは限りません³。仮想サーバーの上に既存の仕組みをそのまま移しただけでは、動く場所が変わっただけで中身は変わっていません。

移した直後の構成よりも、運用しながら整えていく過程のほうが評価の対象になります。参画してすぐに理想形を求められることは少なく、まずは動いている状態を保ちながら少しずつ手を入れていく進め方が現実的です。

これまで単独のクラウドで運用の経験を積んできた場合、その経験は置き場所が変わっても活きます。動かし続けながら手を入れる感覚は、対象がAzureに変わっても、複数のクラウドが並ぶ構成になっても同じように使えます。

置き場所を先に変えるやり方よりも、中身を少しずつ整えながら必要なところだけ置き場所を見直すやり方のほうが、参画してからの負担は軽く済みます。全部を一度に見直そうとすると、確かめる範囲が広がりすぎて優先順位がつけにくくなります。

図の作成：Remogu編集部。公開されている方針の考え方を整理したもので、統計データではありません

置き場所を変えることと、中身を新しくすることは別の作業です。この線引きを最初に持っておくと、参画先で求められているのがどちらの作業なのかを取り違えずに済みます。次に見るのは、その線引きが層によってどう変わるかという点です。

2. 扱う層で作法が変わる

IaaSとPaaSは中心に書かれ、SaaSは名指しされる

公開されている方針は、原則としてIaaSとPaaSを中心に記述し、SaaSについてはSaaSと明示して記述しています¹。この書き方の違いは、資料を読むときの手がかりになります。名指しされていない層は、IaaSかPaaSを前提に書かれていると読めます。

層をまたいで同じ言葉が使われていても、指している対象は層ごとに違います。設定を触れる範囲、責任を持つ範囲、更新の頻度は、IaaS・PaaS・SaaSでそれぞれ異なります。案件情報を読むときは、まずどの層の話をしているのかを切り分けます。

外部のサービスを組み合わせる前提は珍しくない

外部のサービスや製品は、一部での利用を含めて6割強の企業が活用しています¹⁰。この数字が示すのは、単独のクラウドで完結させる進め方よりも、複数のサービスを組み合わせる進め方のほうが実際には広がっているという傾向です。

組み合わせる前提で構成を読むと、見え方が変わります。Azureの案件情報に別のサービス名が並んでいても、それは構成の乱れではなく、層ごとに適した道具を選んだ結果であることが多いといえます。まず疑うより先に、なぜその組み合わせなのかを確かめます。

図の作成：Remogu編集部。公開されている方針の書かれ方を整理したもので、統計データではありません

層	資料での書かれ方	受ける側が見る勘所
IaaS	方針の中心として記述される	構成を組む自由度が広い分、運用の設計を自分で持つ場面が多い
PaaS	IaaSと並んで方針の中心に置かれる	用意された仕組みに沿う進め方になり、更新の頻度が高い
SaaS	SaaSと名指しして記述される	設定や連携が中心になり、内部の構成には踏み込まない

層による作法の違いを知っておくと、複数のクラウドが混在する構成を見ても慌てずに読み進められます。案件を進めやすい土台をどこで整えるかという話に、次は移ります。

層ごとの作法を押さえておくと、案件情報を読む速さも変わります。構成図を見た瞬間に「ここはPaaSだから更新の頻度が高い」と見当をつけられれば、参画前の面談で確かめる質問も的を絞れます。

3. 使わない判断もある

選ばないことも設計の一部になる

クラウドには多数のサービスが並んでいますが、その全部を候補として扱うわけではありません。方針では、使用を避けたいサービスもあると示されています⁴。使えるかどうかより、使わない理由を持っているかどうかが問われる場面があります。

使わない理由の多くは、サーバーを直接構築する前提の仕組みに関わります。運用の手間や責任の範囲が広がりやすいためです。新しい機能よりも、運用を任せられる範囲が広い機能のほうが、参画先で選ばれやすい傾向があります。

終了に備える判断も含まれる

使うかどうかの判断には、その先に終了する可能性が含まれているかどうかも関わります。長く使い続けられる前提のサービスと、いずれ整理される前提のサービスとでは、構成に組み込むときの重みが違います。この見分けは経験がまだ少ない段階では難しく感じられますが、資料を読み込む練習で少しずつ身についていきます。

使う判断と使わない判断は、どちらも同じ資料の延長線上にあります。参画先の担当者に「なぜこの構成なのか」を尋ねたとき、その答えが方針に沿っているかどうかを確かめる材料にもなります。

これまで運用の途中でサービスを見直した経験があれば、それはそのまま活きる経験です。使わない判断をした理由を言語化できる人は、初めて触れる構成でも同じ考え方を当てはめられます。

使わない判断は、機能を否定することではありません。むしろ、運用を任せられる範囲が広い機能を選び直すという前向きな判断です。この言い方に置き換えられると、面談での説明もしやすくなります。

判断	見る観点	受ける側の対応
使う	運用を任せられる範囲が広いか	構成に組み込み、更新の頻度を確認する
避ける	サーバーの構築を前提としていないか	代わりの層で同じ役割を果たせないかを検討する
終了に備える	長く使われる前提の機能かどうか	代替の候補を頭の片隅に置いておく

図の作成：Remogu編集部。公開されている方針の考え方を整理したもので、統計データではありません

使う・避ける・終了に備えるの3つを持っておくと、案件情報にある構成図を見たときの読み方が定まります。終了そのものがどう扱われているかを、次の章で見ていきます。

4. 終了と代替は事前に知らされる

突然の停止ではなく、通知を前提にした仕組み

使っているサービスが終了する場合は、終了の時期と代替の機能が事前に通知されます⁵。予告なく止まる仕組みではなく、猶予を持って知らされる仕組みだという理解が土台になります。慌てて構成を作り替える必要がある場面は限られます。

通知が来てから動くよりも、通知が来る前提で構成の依存関係を把握しておくほうが、実際の切り替え作業は軽くなります。どの機能に依存しているかを一覧にしておくだけでも、通知が来たときの動きは変わります。

依存関係の一覧は、参画した初日から少しずつ作っていくものです。最初から完璧な一覧を求められることは少なく、触れた範囲から書き足していく進め方で十分に間に合います。

代替の機能があることと、切り替えが軽いことは別

代替の機能が示されるということは、乗り換え先が用意されているということです。ただし、代替が示されていることと、切り替え作業そのものが軽く済むこととは別の話です。構成によっては設定の見直しに時間がかかる場合があります。

この違いを参画前に把握しておくと、終了の通知を受けたときに落ち着いて対応できます。通知の有無ではなく、通知を受けたあとの対応にどれだけ時間を割けるかが、参画先で評価される部分になります。

面談の場では、過去に終了通知を受けて切り替えを進めた経験を尋ねられることもあります。経験がまだ少ない場合でも、通知を受けてから何を最初に確認するかという手順を答えられれば、考え方が伝わります。

終了と代替が事前に扱われていることを知っておくと、日々の更新にも同じ姿勢で向き合えます。更新がどのように日常へ組み込まれているかを、次に見ていきます。

5. 更新は日常の作業になる

特別な対応ではなく、通常のアップデートとして扱う

更新は特別な対応ではなく、通常のアップデートと捉えて日常的に対応していく必要があります⁸。継続的な更新への対応が、この方針でも挙げられています⁹。年に数回のイベントとしてまとめて構えるやり方とは、前提が違います。

イベントとして構える更新よりも、日常のリズムに組み込んだ更新のほうが、1回あたりの負担は軽くなります。まとめて対応しようとすると変更の範囲が広がり、確認する項目も増えてしまいます。

日常のリズムに慣れるまでには一定の期間がかかります。最初のうちは更新の連絡を見落としがちでも、確認する場所と頻度を決めてしまえば、そのあとは大きな手間なく続けられるようになります。

日常に組み込む姿勢は参画先でも共有される

この姿勢は参画するエンジニア個人だけの心がけではなく、参画先のチーム全体で共有される前提でもあります。案件情報の中に更新の頻度についての記載があれば、それはチームがどの速さで動いているかを示す手がかりになります。

更新を日常の作業として扱えるかどうかは、案件を選ぶときの見極めどころのひとつです。負担の大きさよりも、負担をどう分散させているかを見ると、その現場の進め方がつかめます。こうした進め方は、常駐を前提にしなくても十分に共有できます。Remoguの案件は、90%以上がフルリモート可能です。

更新の構え方	頻度	1回あたりの負担
イベントとして構える	まとめて低頻度	変更の範囲が広がりやすい
日常のリズムに組み込む	小さく高頻度	1回あたりの確認項目は絞られる

更新の構え方が定まると、次に見えてくるのは事業者からの提案そのものをどう受け止めるかという点です。

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

提案の中身よりも、沿っているかどうかを見る

提案が方針に沿ったものであるかどうかには、留意する必要があります⁶。新しい技術が並んでいるかどうかよりも、その提案が全体の方針からどれだけ外れていないかのほうが、確かめたい軸になります。

方針から外れた提案がすべて悪いわけではありません。むしろ、外れる理由がきちんと説明されているかどうかが分かれ目になります。理由の説明がない提案は、あとから見直しが必要になる場面が増えます。

この見方は、参画する側にも同じように当てはまります。自分が構成に手を入れるときも、方針から外れる理由を一言添えられれば、あとから聞かれたときに慌てずに答えられます。

運用の段階まで含めて計画されているか

運用の段階も含めて日々改善していくことを前提に、予算や体制、日程を計画します⁷。導入までの計画だけで終わっている提案は、運用が始まってから体制が追いつかなくなることがあります。

導入時点の完成度よりも、運用の段階まで見通した計画のほうが、参画してからの働きやすさに直結します。案件情報や打ち合わせの場で、運用の体制について触れられているかどうかを確かめておくと、参画後の見通しが立てやすくなります。

運用の計画まで尋ねる姿勢は、経験の長さに関係なく示せます。「導入後の体制はどう考えていますか」という一言を面談で添えられれば、その場で構成の全体像を聞き出す糸口になります。

提案が方針に沿っているかを見る視点を持てると、参画先の構成に対する信頼の置き方が変わります。最後に、これまでの観点を入る前の順番として整理します。

7. 入る前に確かめる順番

層を確かめてから、判断の理由を確かめる

ここまでの観点を、入る前に確かめる順番としてまとめます。最初に見るのは、対象がIaaS・PaaS・SaaSのどの層かという点です¹。層が分かれば、記述のされ方も、更新の頻度も、想定される作業の範囲もおおむね決まります。

層を確かめたあとは、その構成の中で何を使い、何を避けているかの理由を確かめます⁷。理由が説明できる構成は、運用の段階まで見通されている可能性が高く、参画後に振り回されにくい現場だと判断できます。

図の作成：Remogu編集部。公開されている方針の考え方を整理したもので、統計データではありません

層を見て、理由を見て、終了の扱いを見て、運用の計画を見る。この4つを順番に確かめれば、案件情報だけでは分かりにくい前提の多くが見えてきます。あとは、実際によく挙がる疑問を確認しておきます。

4つの順番は、一度で完璧に確かめきる必要はありません。最初の面談で層と理由だけ確かめ、参画してから終了の扱いと運用の計画を実際の構成で確かめ直す、という進め方でも十分に機能します。

複数クラウドの経験がなくても参画できますか

単独のクラウドで組んだ経験しかない場合でも、層ごとの読み方さえ押さえていれば、参画そのものが難しくなるわけではありません。むしろ、なぜその組み合わせが選ばれているのかを尋ねる姿勢のほうが重視されます。分からない構成を分からないまま進めないことが大切です。

案件情報だけで方針への沿い方まで分かりますか

案件情報に書かれているのは構成の概要が中心で、方針にどこまで沿っているかまでは読み取れないことが多いといえます。面談や参画後のやり取りで、運用の段階までの計画について尋ねると、実際の姿が見えてきます。

単独のクラウドで積んだ経験は、どの場面で効きますか

単独のクラウドで運用を続けてきた経験は、更新を日常のリズムに組み込む感覚や、終了通知を受けたあとに何を確かめるかという手順の部分でそのまま活きます。層が増えても、確かめる順番の考え方までは変わりません。

経験がまだ少ない層があっても、他の層で身につけた確かめ方をそのまま持ち込めば、構成全体を読む力はすでに備わっています。差があるのは経験の量ではなく、確かめる順番を言葉にする練習の有無だけという場合もあります。

こうした確認は、どこで実践できますか

層を見て理由を尋ねる進め方は、案件を実際に選ぶ段階で試すのが近道です。まずは自分の経験に近いAzure関連の案件情報を見て、構成の書かれ方から練習してみると、確かめる順番が体に馴染んでいきます。

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

出典・参考情報

＊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 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」利用の広さ（2025年4月・2026年8月確認）