PostgreSQLの案件を受けるとき、多くの技術者はまず移行作業の範囲でスコープを組み立てます。しかし実際の依頼では、移行が終わった後の運用設計まで含めて相談されることが増えています。移行だけを引き受ける前提で見積もると、後から運用面の追加相談が重なり、当初の作業量と実際の稼働がずれていきます。この記事では、政府情報システムにおけるクラウド利用の方針が挙げる観点を手がかりに、PostgreSQLの案件で運用まで含めて受ける範囲をどう見積もるかを整理します。

1. 移してそれで終わりにならない理由

運用が変わらなければ効果が出ない理由

PostgreSQLの移行案件を受けると、環境を切り替えた時点で作業の区切りがついたように感じられます。依頼した側も、まずは動くようになったことに安心します。

ただし、システムを刷新しても、運用の仕方が従前のままでは、コスト削減の効果は十分に発現しません⁹。移行は入り口であって、運用を作り替える工程のほうが本体だという捉え方になります。

動かすことよりも、動かし続ける工夫のほうが評価につながる場面が増えています。運用側の設計をどこまで引き受けるかが、案件の価値を左右します。

見積もりの起点を移行だけに置かない考え方

見積書を作る段階では、移行作業の工数だけを積み上げたくなります。区切りが明確で、依頼側にも説明しやすいためです。

一方で方針では、当初からピーク時を想定して構成を組む考え方から、オートスケールによって綿密な当初の見積りが要らない、無駄のない構成へ変わることが挙げられています¹。構成そのものが見積もりの前提を変えます。

移行の範囲と、その先の運用の作り替えを分けて示すと、受ける範囲の違いが見えやすくなります。次の章では、使う量の考え方がどう変わるのかを具体的に見ていきます。

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

2. 使う量の考え方が変わる

ピーク前提から必要な分だけへ

リソースの規模を決めるとき、最も混み合う時間帯に耐えられる大きさを最初に確保しておく進め方は、これまで自然な選択でした。

方針では、ピーク時を想定した大きなリソースを、通常時には使用しないという考え方が挙げられています²。常時大きく構えるのではなく、必要な分だけを使う発想への転換です。

稼働していないリソースへの課金を抑えることも、同じ文脈で挙げられています³。大きさを先に決めるよりも、使った分に応じて調整する設計のほうが、運用のコストに直結します。

使う量に応じた構成が意味すること

この違いを整理すると、リソースの規模や課金の考え方が、従来の前提と使う量に応じた考え方とでどう変わるのかが見えてきます。PostgreSQLの案件では、構成を決める段階でこの違いを踏まえておくと、後から運用側の相談を受けたときにも判断がぶれにくくなります。次の表に観点ごとの違いを整理します。

観点	従来の考え方	使う量に応じた考え方
リソースの規模	ピーク時を想定して大きく構える	必要な分に応じて調整する2
課金の考え方	稼働の有無にかかわらず一定で発生	稼働していない分への課金を抑える3

表からも分かるとおり、変わるのは規模の決め方だけではなく、課金や監視といった運用の各局面です。使う量に応じた考え方は、次章で扱う監視や計測の作り替えにもつながります。

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

3. 監視と計測を作り替える

監視の対象を見直す

移行が終わった直後は、これまでと同じ監視項目をそのまま引き継ぎたくなります。慣れた指標のほうが、変化に気づきやすいためです。

方針では、監視の対象を見直すことも、挙げられている観点の一つです⁴。使う量の考え方が変わった以上、見るべき指標も同じままではいられません。

定量的な計測とダッシュボードによる可視化

監視の対象を見直した先には、状況をどう把握するかという論点が続きます。従来は稼働の有無を中心に確認する場面が中心でしたが、使う量に応じた構成では、数値として状況をつかむ場面が増えます。観点ごとの違いを次の表に整理します。

観点	これまで中心だったこと	作り替えの方向
監視の対象	稼働しているかどうかの確認	監視対象そのものを見直す4
状況の把握	定性的な報告が中心	定量的な計測とダッシュボードによる可視化5

定量的な計測と、ダッシュボードによる状況の可視化も挙げられています⁵。感覚で捉えていた稼働状況を、数値として残せる形に作り替える工程です。

監視と計測の作り替えは、移行の作業には含まれにくい工程です。受ける範囲を決める段階で、この工程をどちらが担うのかを確認しておくと、後の認識のずれを防ぎやすくなります。

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

継続的なアップデートへの対応

サービスの更新は、これまで年に数回のイベントのように扱われがちでした。予定を組んで、まとめて対応する進め方です。

方針では、継続的なアップデートへの対応も、挙げられている項目の一つです⁷。まとめて構えるのではなく、続けて向き合う対象として位置づけられています。

通常のアップデートとして日常的に対応する

サービスの更新への対応は、特別な出来事としてではなく、通常のアップデートと捉えて日常的に対応していく必要があります⁸。イベントから日常の作業へと、扱い方そのものが変わります。

まとめて構えるよりも、少しずつ続けて対応するほうが、1回あたりの負荷は小さくなります。受ける側にとっては、日常の作業として組み込めるかどうかが分かれ目になります。

更新への向き合い方が変わると、確認の仕方も見直す必要が出てきます。次の章では、確認テストの最適化という論点を取り上げます。

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

5. 確認テストの最適化という論点

マネージドサービスの更新時に何を確認するか

更新が日常の作業になると、そのたびに何をどこまで確認するかが論点になります。1回ごとに個別の手順で確認していては、日常の作業として続けることが難しくなります。方針が挙げる観点を、確認テストの位置づけとして次の表に整理します。

論点	これまでの位置づけ	方針が挙げる位置づけ
確認テスト	更新のたびに個別の手順で対応	マネージドサービスの更新時などにおける確認テストの最適化6
アップデートへの対応	特別な出来事として扱う	通常のアップデートと捉えて日常的に対応8

マネージドサービスの更新時などにおける確認テストの最適化も、挙げられている観点です⁶。毎回の確認を作り込むのではなく、繰り返せる形に整える方向です。

アップデートへの対応を確認テストにどうつなげるか

通常のアップデートと捉えて日常的に対応していく考え方⁸は、確認テストの位置づけにもそのまま重なります。特別な検証ではなく、繰り返し使える確認の仕組みとして設計する発想です。

確認テストの最適化は、更新の頻度が上がるほど効いてきます。受ける範囲にこの工程を含めるかどうかは、案件ごとに事前にすり合わせておきたい点です。

6. 自動化はどこまで含むか

運用作業の自動化を徹底する範囲

運用の作業が増えるほど、手を動かす時間も比例して増えていきます。日常の対応が積み重なると、一つひとつは小さくても全体の負荷は大きくなります。

方針では、運用作業の自動化を徹底することも、挙げられている観点です¹⁰。繰り返す作業を人の手から離すことが、日常化した運用を支える前提になっています。

自動化と効果の関係を見積もりにどう反映するか

システムを刷新しても、運用の仕方が従前のままでは、コスト削減の効果は十分に発現しません⁹。自動化まで含めて運用を作り替えることが、その効果を出す条件の一つになります。

自動化の範囲を後から広げるよりも、見積もりの段階でどこまで含むかを決めておくほうが、作業の抜け漏れは少なくなります。受ける範囲を数える基準として、次の章で順番を整理します。

7. 受ける範囲を見積もる順番

見積もりの起点をどこに置くか

見積もりを作る段階では、まず移行の工数から積み上げたくなります。区切りがはっきりしていて、依頼側にも説明しやすいためです。

ただし方針では、オートスケールによって、綿密な当初の見積りが要らない、無駄のない構成へ変わることが挙げられています¹。構成の前提が変わる以上、見積もりの起点も移行の工数だけでは収まりません。

受ける範囲を、移行の作業だけでなく運用の作り替えまで含めて考える順番を、次の図に整理します。

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

運用まで含めて合意しておくこと

システムを刷新しても、運用の仕方が従前のままでは、コスト削減の効果は十分に発現しません⁹。この前提を共有できているかどうかで、受ける範囲についての認識は大きく変わります。

Remoguは、案件の90%以上がフルリモート可能な、リモートワーク案件に特化したエンジニアマッチングです。運用まで含めた見積もりの感覚は、実際の案件情報を見比べながらのほうが磨かれていきます。まず登録して、自分の経験に近い条件の案件を確かめてみるのも一つの道です。

PostgreSQLの案件を受けるとき、運用まで含めて見積もる範囲はどう判断しますか

まず移行の範囲を確認したうえで、使う量の考え方や監視、更新への対応、自動化までを含めるかどうかを、依頼側とすり合わせておくと判断しやすくなります。含める工程が増えるほど、見積もりの幅も変わります。

移行の作業だけを引き受けて、運用は含めない進め方はできますか

引き受け方として不可能ではありませんが、運用の仕方が従前のままではコスト削減の効果は十分に発現しないという前提⁹を踏まえると、後から運用側の相談が重なりやすくなります。範囲を絞るなら、その前提を依頼側と共有しておくと認識のずれを防げます。

確認テストの最適化とは、具体的に何を指しますか

マネージドサービスの更新時などにおける確認テストの最適化⁶として挙げられている観点です。更新のたびに手順を作り直すのではなく、繰り返し使える確認の形に整えることを指します。

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

出典・参考情報

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