Terraformの案件を受けるとき、多くの開発者がまず気にするのは書く量です。しかし発注元が実際に確かめたいのは、書き終えたあとにどんな既定が残るかという点です。政府情報システムの方針でも、IaCによるインフラ作業の効率化が掲げられています¹。運用作業の自動化を徹底することもあわせて挙げられており²、コードそのものより運用の姿を決めることに重心が置かれています。

1. 書くことより既定を決めること

TerraformなどのIaCを扱う案件で最初に渡されるのは、既存のインフラ構成を読み解く作業です。ここで求められるのは正確に書き写す力ではなく、なぜその構成になっているかを言葉にできる力です。政府情報システムの方針でも、IaCによるインフラ作業の効率化が掲げられており¹、効率化の中心はコードの量ではなく作業そのものの型を変えることに置かれています。

書く速さより、後から誰が触っても崩れない既定を残せるかどうかのほうが、参画先での評価につながります。運用作業の自動化を徹底することも同じ方針の中で挙げられており²、手作業に戻さない仕組みを残すことが役割の中心になります。

既定とは、次に触る人への申し送りです

既定というと堅い言葉に聞こえますが、中身は次にこの構成を触る人への申し送りです。どこまでを自動化してあるか、何を確認すれば安全に変更できるかを、コードと運用の型の両方に残しておくことを指します。

参画してすぐの開発者に期待されるのは、この申し送りを整えることです。書いたコードの量よりも、後任が迷わず判断できるかどうかが、案件の評価を分けます。

この申し送りが無いまま案件が進むと、後から入った開発者が同じ確認を何度も繰り返すことになります。既定を書き残す作業は地味に見えますが、次に触れる人の時間を守る仕事でもあります。参画したばかりの段階でこの視点を持てるかどうかが、案件の中での動き方に差を生みます。

既定がどこにあるか分からないときは、いきなり構成を書き換えるのではなく、クライアントと協議しながら、何が既に決まっていて何が決まっていないかを一緒に洗い出すところから始められます。この順番を踏むと、後になって前提が食い違う事態を避けられます。

この申し送りは、使う量・見る・やめるという3つの既定に分けて考えると整理しやすくなります。次の章から、それぞれの中身を見ていきます。

図の作成：Remogu編集部。方針が示す既定の区分を整理したもので、統計データではありません

2. 使う量の既定を最初に決める

使う量の既定は、案件の中でいちばん手を付けやすい既定です。ピーク時を想定した大きなリソースを通常時に使用しないことが方針の中で挙げられており⁴、常に最大構成のままにしておく発想からの転換が求められています。書くことに慣れた開発者ほど、まずこの既定から着手すると成果が見えやすくなります。

常時最大構成を維持するより、稼働の波に合わせて絞り込むほうが、コストと運用の両方に効きます。稼働していないリソースへの課金を抑制することも同じ並びで挙げられており⁵、使っていない時間の扱いが既定の対象になっています。

波のある稼働にどう既定を当てるか

案件によって稼働の波は違います。日中に集中するものもあれば、月末や特定の処理だけ重くなるものもあります。既定として決めるのは、この波のどの部分を常に確保しておく量とし、どこからを絞り込む対象にするかという線引きです。

線引きが曖昧なまま構成を組むと、後から見直すたびに議論が振り出しに戻ります。参画した早い段階でこの線を言語化しておくことが、次の見る既定・やめる既定にもつながります。

使う量の既定を決める作業は、既存の構成を眺めるところから始まります。どのリソースが常に稼働していて、どのリソースが波に応じて増減しているかを分けて見ることが、最初の一歩になります。

この線引きは一度決めれば終わりではありません。案件が進むにつれて処理の重さも変わるため、見直す機会をあらかじめ決めておくことも、使う量の既定に含めておきたい点です。

ピーク時想定と、使う量の既定でどこが変わるか

ここまでの内容を表に整理します。ピーク時を想定した構成のままにしておく場合と、使う量の既定を置いた場合とでは、リソースの大きさと稼働していない時間の課金の扱いが変わります。判断の主体も、その場ごとの判断から、あらかじめ決めた既定に沿った判断へと移ります。案件を受ける側としては、この2つの状態のどちらに現場が近いかを、参画前後で確かめておくと動きやすくなります。

表の右側にあたる状態を目指す場合でも、一度にすべてを変える必要はありません。まずリソースの大きさだけを見直し、課金の扱いと判断の主体は次の段階に回すというように、区切って進めることもできます。

観点	ピーク時想定のまま	使う量の既定を置いた状態
リソースの大きさ	常に最大構成を確保する	ピーク時想定の大きなリソースを通常時に使用しない4
稼働していない時間の課金	稼働の有無を問わず発生する	稼働していないリソースへの課金を抑制する5
判断の主体	その都度その場で判断する	あらかじめ既定として決めておく

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

3. 見る既定を、使う量の次に置く

使う量を絞り込んだだけでは、既定は長く保たれません。定量的な計測とダッシュボードによる状況の可視化が方針の中で挙げられており⁷、絞り込んだ状態を見え続ける仕組みにすることが次の既定になります。

クラウド利用料を定期的に確認することも同じ並びで挙げられています⁶。見る既定が無いと、使う量の既定は決めた瞬間から古くなっていきます。決めた直後は正しく見えていた線引きも、確認する仕組みが無ければ誰も気づかないまま崩れていきます。

見る仕組みは誰のためにあるか

見る既定は、担当者一人の記憶に頼らないための仕組みです。ダッシュボードに数値が並んでいれば、参画したばかりの開発者でも今の状態を追いかけられます。

担当者の勘に頼るより、誰が見ても同じ判断にたどり着ける状態のほうが、既定として長く残ります。見る既定を先に整えておくことが、後任への引き継ぎを軽くします。

見る仕組みを新しく作る場合、最初から複雑なダッシュボードを目指す必要はありません。まずは追いかけたい数値をひとつ決めて、それを定期的に確認する型を作ることから始められます。

見る仕組みが整うと、使う量の既定が実際に効いているかどうかも数値で確かめられるようになります。感覚ではなく数値で語れることは、クライアントとの協議でも材料になります。

見る仕組みがある場合とない場合で何が変わるか

見る仕組みの有無は、利用料の把握のしかたと状況の可視化の水準に直結します。仕組みが無ければ都度調べたり担当者の記憶に頼ったりする形になり、仕組みがあれば定期的な確認と可視化によって状況が数値として残ります。引き継ぎの負担にも差が出るため、参画時に見る仕組みの有無を確かめておく価値があります。

見る仕組みが無い現場に参画した場合は、いきなり大がかりな可視化を提案するより、まず自分の作業範囲だけで小さく確認の型を作り、そこから広げていくほうが受け入れられやすくなります。

観点	見る仕組みが無い状態	見る仕組みを既定にした状態
利用料の把握	必要になるたびに調べる	クラウド利用料を定期的に確認する6
状況の可視化	担当者の記憶に依存する	定量的な計測とダッシュボードで可視化する7
引き継ぎ	そのつど説明が必要になる	数値を見れば状況が伝わる

4. やめる既定を後回しにしない

使う量を絞り込み、見る仕組みを整えたら、次に残るのは動かし続けているものを止める判断です。夜間バッチの必要性を見直すことが方針の中で挙げられており⁸、動いている理由を定期的に問い直す既定が求められています。

夜間に処理を回す理由は、その処理が始まった当時の事情によることがあります。事情が変わったあとも、仕組みだけがそのまま残っていることは珍しくありません。理由を確かめる相手は、構成を組んだ本人とは限らず、資料が残っていない場合もあります。

止める判断は、誰が持つか

やめる既定を決めておかないと、動いているものを止める提案は、そのたびに一から議論になります。見る仕組みで使われていない時間が分かっていれば、やめる判断はその数値をもとに進められます。

止める判断を提案するときは、いきなり停止するのではなく、まず影響の範囲を確かめることが順序になります。その処理の結果を誰が使っているかを洗い出すところから始めます。

夜間バッチに限らず、常時動き続けている仕組み全般に同じ問いが当てはまります。動いている理由を定期的に問い直す習慣が、やめる既定を機能させる土台になります。

使う量・見る・やめるの3つの既定は、この順番でつながっています。ただし、これら3つを決めても、コスト削減効果は十分に発現しない場合があります⁹。効果が出ない理由については、次の章で見ていきます。

やめる既定を決めた直後は、関係者から慎重な声が上がることもあります。見る仕組みで示した数値を根拠に、影響が小さい範囲から順に止めていく進め方であれば、協議も落ち着いて進めやすくなります。

5. 既定が無い現場に入るという前提を持つ

ここまでの3つの既定は、案件によっては最初から存在しません。構成管理のツールを導入している企業は、利用する側で約3割、作る側で約4割にとどまっています¹⁰。参画先の多くが、まだこの段階にあるという前提を持っておくことが必要です。

既定が整っている現場を期待するより、既定が無い状態から始まるという前提のほうが、実際の案件には近いです。IaCによるインフラ作業の効率化という方針の方向性¹は掲げられていても、現場ごとの導入状況にはばらつきがあります。

既定が無いことは、参画する側の役割を広げる

既定が整っていない現場では、コードを書く前に、何を既定として残すかを最初に言語化する役割が生まれます。これは負担ではなく、参画する開発者の裁量が広がる場面でもあります。決める内容の多くはクライアントとの協議を経て確定していくため、提案する力もあわせて求められます。

既定を決める役割は、決めた後の運用にも関わります。使う量・見る・やめるのどれから手を付けるかを自分で組み立てられることは、参画先での動き方の幅にもつながります。

既定が無い現場では、最初の数週間で構成全体を把握する作業に時間がかかることもあります。焦って一気に既定を作ろうとせず、使う量から順に手を付けるほうが進めやすくなります。

この段階では、クライアントとどこまでを既定として決めるかを協議しながら進めることになります。決める範囲を最初に合意しておくと、後からの手戻りが減ります。

既定がある現場とまだ無い現場で何を確かめるか

参画前に確かめておきたいのは、構成管理ツールの導入状況と、最初に任される役割です。既定が整っている現場では既存の型に沿って作業しますが、まだ無い現場では既定そのものを言語化する役割から始まります。方針の方向性と現場の実態には距離があることも多く、その距離を前提に動くと戸惑いが少なくなります。

面談の段階でこの距離をある程度つかんでおけば、参画開始後に何から手を付けるかの見通しが立てやすくなります。既定が無い前提で臨むほうが、実際に無かったときの戸惑いが小さくて済みます。

観点	既定が整っている現場	既定がまだ無い現場
構成管理ツールの導入	既に運用に組み込まれている	導入企業は利用する側で約3割・作る側で約4割にとどまる10
最初に任される役割	既存の既定に沿って作業する	既定そのものを言語化する役割が生まれる
方針との距離	IaCの効率化1が実践に近い	方針の方向性と現場の実態に距離がある

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」（2025年4月）をもとに作成

6. 効果が出ない理由は運用にある

既定を3つとも決め、構成を組み替えても、効果が出ない案件があります。システム運用が従前のままでは、コスト削減効果は十分に発現しません⁹。構成だけを変えて、運用の型を変えていない場合にこれが起こります。

方針では、オートスケールによって綿密な当初見積りが不要な無駄のない構成へ向かうことも挙げられています³。ただしこれは構成の話であり、運用する人の動き方まで自動的に変わるわけではありません。構成が自動で調整されるようになっても、その結果を確認し判断する役割は人に残ります。

構成の変化と運用の変化は別物です

構成を組み替えた直後は、数値が改善して見えることがあります。しかし運用の担当者が以前と同じ手順で確認や変更を続けていれば、その改善は長続きしません。

参画したエンジニアが構成を組み替える立場であっても、運用の手順まで踏み込んで確かめられるかどうかで、案件の成果の見え方は変わります。構成の担当と運用の担当が分かれている案件では、この橋渡しを誰が担うかを早めに確かめておくと動きやすくなります。

構成だけを直すより、構成と運用の両方を同時に見直すほうが、効果が長く残ります。見る既定を先に整えておくと、構成と運用のどちらに手を付ける必要があるかの違いに早い段階で気づけます。

効果が続かない案件では、構成の見直しだけを繰り返して、運用の手順には手を付けないまま時間が過ぎることがあります。運用の手順まで踏み込んで確かめる姿勢が、既定を機能させる鍵になります。

運用の型を変える提案は、構成を変える提案より抵抗を受けやすい場面もあります。見る既定で示した数値を根拠にしながらクライアントと協議を進めると、話が前に進みやすくなります。

効果が続かない案件に参画したときは、構成の見直しと運用の見直しを分けて考えることが手がかりになります。どちらか一方だけを直しても、既定は長くは保たれません。

7. 既定を決める順番

ここまで見てきた既定には、決める順番があります。オートスケールで綿密な当初見積りが不要な無駄のない構成へ向かうという方向性³を先に押さえておくと、細かな既定を決める土台ができます。

次に必要なのが、定量的な計測とダッシュボードによる状況の可視化です⁷。見る仕組みを先に作っておかなければ、使う量の既定もやめる既定も、根拠のない話し合いになってしまいます。

全体の方向、見る仕組み、個別の既定という順番

最初に全体の方向性を確かめ、次に見る仕組みを整え、そのうえで使う量・やめるという個別の既定を詰めていきます。この順番を保つと、後から既定を見直すときも迷いにくくなります。順番を飛ばして個別の既定から手を付けると、あとで全体の方向と合わずに組み直す羽目になります。

参画したばかりの開発者がまず取り組めるのは、この順番のうちどこが抜けているかを確かめることです。全体の方向はあるのに見る仕組みが無い案件も、見る仕組みはあるのに個別の既定が無い案件も、どちらもよくあります。

この順番は、案件の規模が大きくなるほど効いてきます。決める既定の範囲が広がるときほど、全体の方向を先に共有しておかないと、個別の既定同士が食い違う原因になります。

参画してすぐの開発者でも、この3段階のうちどこが埋まっていないかを確かめる問いを持っておけば、最初の面談やクライアントとの協議で状況をつかみやすくなります。

図の作成：Remogu編集部。既定を決める順番を整理したもので、統計データではありません

Terraformの案件では、最初から既定を決める役割を任されますか

参画したばかりの段階では、既存の既定を理解する役割から始まることが一般的です。既定が整っていない現場に入った場合は、早い段階で言語化を求められることがあります。

既定を決める経験がまだ少ない場合でも案件を受けられますか

使う量・見る・やめるという3つの区分を押さえておけば、経験がまだ少ない場合でも、どこから確かめればよいかの見当がつきます。まずは見る仕組みが既にあるかどうかを確かめることから始められます。区分ごとに小さく確かめていけば、経験は参画しながら積み上げられます。

フルリモートで参画できる案件はありますか

Remoguが扱う案件は90%以上がフルリモート可能です。既定を作る役割は現場への常駐を前提としないため、リモートでも参画しやすい領域です。

既定が無い現場かどうかは、参画前にどう確かめますか

構成管理ツールの導入状況や、見る仕組みの有無を面談で尋ねることが手がかりになります。導入企業は利用する側で約3割、作る側で約4割にとどまっているため¹⁰、無い前提で確かめておくと落ち着いて臨めます。既定が整っている案件でも、その既定がどの範囲まで及んでいるかを確かめておくと、参画後の見え方が変わります。

既定は、コードを書き終えたあとに忘れられがちですが、次にこの案件に関わる誰かへの申し送りそのものです。参画したら最初の週に、使う量・見る・やめるの3つがどこまで決まっているかを一度確かめてみましょう。

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

出典・参考情報

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