自分の環境では問題なく動いていたのに、本番に上げた途端に様子が変わる。Docker案件でまず向き合うのは、その落差を埋める作業です。コンテナという道具を入れれば同じものが動くと考えられがちですが、実際に問われるのは環境・設定・データ・確認という4つの観点をどう揃えるかという設計の力です。この記事では、その差がどこで生まれ、案件の中でどこまでの範囲を任されていくのかを整理します。

1. 埋めるのは「同じものが動く」までの差

環境・設定・データ・確認という4つの観点

Docker案件で最初に確認されるのは、開発と本番で何が違うかという洗い出しです。同じイメージを使っていても、動かす環境のOSやミドルウェアのバージョンが揃っていなければ、挙動はそのままでは一致しません。まず見るのは環境そのものの差で、次に設定ファイルや環境変数の差、扱うデータの差、そして確認の仕方の差という順番で整理されていきます。

この4つの観点は、どれか1つだけを整えても効果が限られます。環境を合わせるだけよりも、4つの観点を同時に見渡すほうが、差を埋める近道になります。設定を揃えてもデータの中身が異なれば、確認の結果は変わってしまいます。

デジタル庁の方針では、提供されているクラウドサービスをそのまま使っても、新しい構成になるとは限らないと示されています¹。Dockerを入れることも同じで、道具を導入した時点でゴールに着くわけではなく、そこから何を揃えるかという作業が始まります。

この作業には、一つだけの正解があるわけではありません。案件によって重視される観点は異なり、データの整合性を優先する現場もあれば、確認の自動化を優先する現場もあります。どこに重心を置くかを見極めることも、任される仕事の一部です。

道具を入れることと、前提を揃えることは別の作業

クラウドが提供するサービスも、すべてが新しいものとは限らないと方針は示しています²。長く使われてきた機能ほど、そのまま残っている場合があり、選び方ひとつで構成の古さが持ち込まれます。

道具を入れることと、前提を揃えることは別の作業だと分けて考える必要があります。前者は環境を用意する作業で、後者はその環境の中で何を守り、何を更新していくかを決める作業です。案件で任されるのは、後者の部分であることがほとんどです。

この視点を持たずに案件へ入ると、道具の使い方を覚えることそのものが目的になりがちです。しかし実際に評価されるのは、環境・設定・データ・確認という4つの観点をどう揃えるかを、自分の言葉で説明できるかどうかです。操作の速さよりも、差をどう捉えているかという理解のほうが、任される範囲を決める材料になります。

図の作成：Remogu編集部。開発と本番の差が生まれる観点を整理したもので、統計データではありません

2. 道具を入れれば消えるわけではない

そのまま使うことと、中身を選び直すことの違い

そのまま使えば整うと考えられがちですが、方針が示しているのは逆の内容です。クラウドが提供するサービスも、すべてが新しいものとは限りません²。長く動いてきた機能ほど、更新されないまま提供され続けることがあります。

Dockerの案件でも同じことが起こります。動いているイメージをそのまま本番に持ち込んでも、ベースイメージの選び方や依存関係の固定の仕方によって、古い構成がそのまま引き継がれてしまいます。道具を入れることよりも、中身を選び直すことのほうが、任される範囲を広げる作業です。

どこまでを引き継いでよいかを判断するには、今動いている構成を理解する時間が必要です。急いで置き換えるのではなく、まず現状を言葉にしてから手を付けるほうが、結果として手戻りが少なくなります。

使用を避けたいサービスがあることも、方針の中で名指しされています³。サーバーの構築を前提とするものなど、性質上その後の運用が重くなりやすい選択肢です。案件で任されるのは、こうした選び方の妥当性を見極める役割でもあります。

図の作成：Remogu編集部。判断をいつ・誰が行うかという設計の差を整理したもので、統計データではありません

前提を決めた場合と並べると違いが見えます

そのまま使う場合と、前提を先に決めて使う場合とでは、後から必要になる作業の量が変わります。構成の選び方をその都度その場で決めていくやり方は、最初は速く進みますが、更新のたびに個別の判断が必要になります。反対に、使ってよい範囲や更新の頻度をあらかじめ決めておくやり方は、判断の負担を仕組みの中に移していく考え方です。次の表は、この2つの状態を並べたものです。

観点	そのまま使う場合	前提を決めて使う場合
構成の選び方	その都度その場で決める	使ってよい範囲を先に決めておく
更新への対応	発生してから個別に判断する	頻度を決めて仕組みに組み込む
古い構成の扱い	気づかないまま残りやすい	見直す機会を設けておく

並べて分かるのは、道具そのものの機能差ではなく、判断をいつ・誰が行うかという設計の差です。案件で評価されやすいのは、後者の考え方を提案できるかどうかです。

選び直す作業は、動いているものを壊す作業ではありません。今の構成のどこが古く、どこを残してよいかを見分ける作業であり、経験を積むほど判断が速くなっていく領域です。案件の中でこの判断を任されるようになると、道具を操作するだけの立場から一歩進んだ関わり方になります。

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

IaaSとPaaSを中心に置く理由

方針は原則としてIaaSとPaaSを中心に記述し、SaaSについてはSaaSと明示して記述するとしています⁴。同じクラウドサービスでも、扱う層によって前提の置き方が変わるという考え方です。

IaaSやPaaSは、動かす基盤に近い部分を自分たちで組み立てる領域です。Dockerを使う案件はこの層に関わることが中心で、環境の再現性や更新の手順を自分たちで設計する場面につながります。SaaSは、提供される機能をそのまま使う前提が強く、扱い方の重心が異なります。

この層の違いを意識せずに案件へ入ると、任されている範囲を見誤ることがあります。基盤の設計を求められているのか、機能を使う前提で確認だけを求められているのかは、最初に確かめておきたい点です。

層ごとの向き合い方を並べると違いが見えます

IaaSやPaaSと、SaaSとでは、方針の中での書かれ方も、実務での向き合い方も異なります。前者は基盤の設計や更新の手順まで踏み込んで記述され、後者は利用する機能として明示して扱われます。次の表は、この2つを並べたものです。

対象	記述のされ方	実務での意味
IaaS・PaaS	基盤の設計や更新の手順まで踏み込んで記述される	環境の再現性や更新の手順を自分たちで設計する
SaaS	利用する機能として明示して記述される	提供される機能をそのまま使う前提が強い

この分かれ方を踏まえると、IaCによってインフラ作業を効率化するという方針の考え方⁵は、主にIaaSやPaaSの層で生きてきます。案件でこの層を任されるときほど、構成をコードとして残す姿勢が求められます。

扱う層を早い段階で確認しておくと、案件に入ってからの手戻りも減ります。基盤の設計を任されると思っていたら実際は機能の確認だけだった、という食い違いを防ぐ材料になります。層の違いを整理して伝えられることは、参画の初期に信頼を得るための小さな、しかし確かな一歩です。

4. 確かめる作業をどこまで持つか

確認テストの最適化という考え方

方針が挙げているのは、マネージドサービスの更新時などにおける確認テストの最適化です⁶。更新のたびにすべてを人の手で確かめるのではなく、確かめる範囲と方法をあらかじめ整えておくという考え方です。

Docker案件でも、確認の持ち方は任される範囲を左右します。イメージを更新するたびに動作確認を一つずつ手作業で行うのか、自動で回る仕組みの中に組み込むのかで、任される作業の重さは変わります。

更新は特別な出来事ではなく、日常の一部にする

サービスの更新への対応は、通常のアップデートと捉えて日常的に対応していく必要があると方針は示しています⁸。特別な対応として身構えるのではなく、日々の作業の中に組み込む発想です。

この発想に立つと、確認テストの持ち方も変わります。更新が来るたびに一から確認手順を考えるよりも、あらかじめ整えた確認の型に当てはめていくほうが、任される範囲を安定させます。案件で信頼を得やすいのは、この型を提案できる立場です。

確認の型を持ち込めるかどうかは、経験の長さだけでは測れません。今の現場のやり方を観察し、どこに仕組みを足せるかを見つける姿勢のほうが、型を機能させる力になります。小さな範囲から自動化を提案し、結果を見せていくことが、任される範囲を広げる近道になります。

図の作成：Remogu編集部。確認テストを仕組み化する考え方を整理したもので、統計データではありません

確認の型は、一度作って終わりではありません。対象が増えるたびに見直しが必要になり、その見直しをどの頻度で行うかも、任される範囲を決める要素になります。

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

終了の通知は前触れなく来るわけではない

使っているサービスが終了する場合は、終了の時期と代替の機能が事前に通知されると方針は示しています⁷。前触れなく突然止まるという性質のものではありません。

この前提に立つと、Docker案件で任される役割も見えてきます。通知が来てから慌てて対応を考えるよりも、通知を受け取った時点で何を確認し、どう切り替えるかという手順をあらかじめ用意しておくほうが、任される範囲を広げます。

Dockerで動かす対象がクラウドの機能に依存している場合ほど、この考え方は効いてきます。依存先の終了通知は、作業計画そのものに影響する情報であり、受け取った後の動き方を事前に決めておく価値があります。

終了の場面と、日常の更新の場面を並べて見ます

サービスが終了する場面と、通常の更新が来る場面とでは、示される内容も、求められる対応も異なります。終了の場面では時期と代替が示され、切り替えの計画を立てる対応が求められます。更新の場面では、日常的に対応していく姿勢そのものが求められます⁸。次の表は、この2つの場面を並べたものです。

場面	示されること	求められる対応
サービスが終了する場面	終了の時期と代替の機能	切り替えの計画を立てる
日常のアップデートの場面	通常の更新としての位置づけ	日常的に対応していく姿勢

並べて見えるのは、どちらの場面も「驚かないための情報」が先に示されているという共通点です。任される範囲は、その情報をどう受け止め、どう手順に落とし込むかという部分にあります。

通知を受け取ってから動くのではなく、通知が来る前提で切り替えの手順を用意しておくことが、任される範囲を広げる材料になります。案件に入る段階でこの視点を示せると、運用を任せられる相手として見てもらいやすくなります。

6. 自動で確認が回っていない現場

導入している企業とそうでない企業の差

DevOpsやモデルベース開発は、開発を手掛ける企業を除くと導入している企業が少ないとIPAの調査は示しています¹⁰。仕組み化する側と、仕組みを受け取る側とで、導入の進み方に差があるという結果です。

この差は、Docker案件に入ったときの現場の状態にそのまま表れます。イメージの更新や確認が自動で回っている現場もあれば、まだ人の手で一つずつ進めている現場もあります。どちらに入るかによって、最初に任される作業は変わります。

どちらの現場であっても、今の状態を否定から入る必要はありません。今あるやり方を理解したうえで、変えられる部分を提案していく姿勢のほうが、現場との関係を築きやすくなります。

自動で回る仕組みが無い現場に入ったとき、いきなり大きな仕組みを持ち込もうとすると、周囲との調整が追いつかなくなります。まずは今ある手順のどこを仕組みに置き換えられるかを見つける作業から始めることになります。

運用を変えなければ効果は出にくい

システムの運用が従前のままでは、コスト削減の効果は十分に発現しないと方針は示しています⁹。構成を新しくしても、動かし方が変わらなければ結果は変わりにくいという指摘です。

Docker案件でも同じ構図が起こります。コンテナに載せ替えることよりも、載せ替えた後の運用を設計することのほうが、差を生む部分になります。任される範囲がここまで広がると、操作そのものより、運用をどう変えるかという提案の質が問われてきます。

自分の経験の中で、運用を変えた場面があるなら、それは案件を選ぶときに示せる材料になります。操作の経験だけでなく、その後の運用まで見据えて動いた経験を言葉にしておくと、任される範囲の話し合いがしやすくなります。

7. 任される範囲を決める順番

今の状態を確認してから、対象範囲を切り分ける

IaCによってインフラ作業を効率化するという考え方⁵は、何もない状態から一気に実現するものではありません。まず今の状態を確認し、どこから手を付けられるかを切り分ける作業が最初に来ます。

次に来るのが、確認テストの範囲を決める作業です。マネージドサービスの更新時に何をどこまで確かめるかという最適化の考え方⁶は、任される範囲そのものの輪郭を決める材料になります。

この2つを合わせると、任される範囲を決める順番が見えてきます。今の状態を確認する、対象範囲を切り分ける、承認の要否を決める、進め方をすり合わせる、という4つの段階です。

図の作成：Remogu編集部。任される範囲を決める段階を整理したもので、統計データではありません

順番を自分から示せると、任される範囲が明確になります

この順番を自分から示せると、案件に入った直後から任される範囲がはっきりします。何をどこまで自分の判断で進めてよいのかが早い段階で見え、後になって認識のずれが出にくくなります。

場所に縛られず、裁量を持って設計に関わりたいと考えている場合、この順番を示せる力は案件選びそのものに関わってきます。案件の90%以上がフルリモート可能です。今の経験と、任せてもらえる範囲がどこまで重なるかは、実際の案件を見てみないと分かりません。

任される範囲は、案件によって幅があります。だからこそ、自分の経験がどこで生きるのかを早い段階で言葉にしておくことが、次の一歩につながります。今の状態を確認し、範囲を切り分けて示す力は、参画したその日から発揮できるものです。

Docker案件は、操作の経験だけでは任されませんか

操作の経験だけで任されないわけではありませんが、任される範囲は前提を揃える力によって変わります。今の状態を確認し、対象範囲を切り分けるところまで自分で示せると、任される範囲は自然に広がっていきます。

クラウドの細かな仕様をすべて覚えておく必要がありますか

すべてを覚えておく必要はありません。方針が示すように、原則としてIaaSとPaaSを中心に前提が書かれ、SaaSは明示して扱われます⁴。まずはどの層を任されているのかを確認する視点のほうが役に立ちます。

運用の仕組みが整っていない現場に入る場合、何から始めればよいですか

DevOpsやモデルベース開発は、開発を手掛ける企業を除くと導入している企業が少ないとIPAの調査は示しています¹⁰。まずは今ある確認の手順のどこを仕組みに置き換えられるかを見つけることから始めます。運用を変えなければ、コスト削減の効果も十分に発現しません⁹。

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

出典・参考情報

＊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月確認）