案件が完成した後、思ったより稼働が減らないと感じる場面があります。契約書に書かれている明示事項を確認しても、稼働の上限という項目はどこにも見当たりません。稼働が膨らむ理由は、実際には「作った後に続く仕事」が見積りの外に置かれていることにあります。この記事では、稼働が膨らむ仕組みと、契約の入り口で稼働を条件として置く順番を整理します。

1. 明示される項目に含まれない稼働の上限

公正取引委員会が案内するパンフレットには、業務委託の際に明示しておく事項が並んでいます。検査を完了する期日と、報酬の額、そして支払期日がそこに含まれています¹。契約の入り口を整えるほど、後の稼働は落ち着くはずだと考えたくなります。ところが、その一覧のどこを見ても「稼働の上限」という項目そのものは出てきません。

支払いに関わる期日の具体的な基準

検査を完了する期日は、納品された成果物の内容を確認し終えるタイミングを指します。あわせて報酬の額と支払期日も明示する事項に挙げられていて¹、いつ、いくら支払われるかという骨格ははっきりしています。

支払期日にはさらに具体的な基準があります。支払期日は、給付を受領した日から60日以内のできる限り短い期間内で定めます¹。報酬を受け取るまでの見通しは、この基準で立てられます。

項目	内容
検査を完了する期日	納品された給付の内容を確認し終える期日1
報酬の額	支払う報酬の金額1
支払期日	給付を受領した日から60日以内のできる限り短い期間内1

明示の対象にならない稼働の上限

契約の入り口で明示される事項は、支払いに関わる期日と金額が中心です。稼働時間の上限や、想定を超えた作業が発生したときの扱いは、その一覧には含まれていません。

稼働が膨らむかどうかは、契約書の明示事項だけでは決まりません。何が「作業の完了」に含まれるかという線引きのほうが、稼働の量を左右します。

支払期日を確認することよりも、作業の範囲がどこで区切られているかを確認することのほうが、稼働の見通しを左右します。

図の作成：Remogu編集部。パンフレットに挙げられている明示事項をもとに整理したもので、統計データではありません

その線引きが曖昧になりやすいのが、成果物を納品した後に続く仕事です。次の章から、その中身を見ていきます。

2. 運用が従前のままでは出ない刷新の効果

契約の入り口が整っていても、稼働の見通しが崩れる場面があります。システムを刷新した後の運用が、刷新前と同じやり方のまま続いているときです。運用が従前のままではコスト削減の効果が十分に出ません²。刷新そのものより、その後の運用の変え方に、稼働の量が左右されます。

刷新の後に残る「運用を変える仕事」

刷新のプロジェクトは、本番稼働の開始をもって完了したように見えます。ところが、運用のやり方を変えないまま同じ体制・同じ手順を続けると、刷新にかけた費用や工数に見合う効果は現れません²。「作る仕事」が終わっても、「運用を変える仕事」がまだ残っている状態です。

この「運用を変える仕事」は、契約の明示事項¹のような形では表に出てきません。検査を完了する期日や支払期日は明示されても、運用の変え方そのものは、日々の稼働の中で少しずつ積み上がっていきます。

「作る量」に偏った見積り

案件の見積りは、成果物を作り切るまでの工数を積み上げる形で組まれることが多くあります。作った後にどれだけ運用を変える仕事が続くかは、見積りに含まれていないことのある部分です。

見積りに運用を変える仕事が入っていないと、契約を結んだ後に稼働の交渉をやり直す場面が生じます。運用フェーズの項目を契約の入り口で確認しておけば、後からの調整は小さくなります。

作る量を見積もることよりも、作った後に続く運用の量を見積もることのほうが、稼働の見通しを左右します。デジタル庁の資料には、運用フェーズで見直しの対象に挙げられている項目がいくつか並んでいます²。この続きは、次の章から順番に見ていきます。

3. 挙げられている運用作業の自動化

運用フェーズに残る仕事の一つが、運用作業そのものの自動化です。デジタル庁の方針では、運用作業の自動化を徹底することが挙げられています²。手作業で続けている確認や実行の手順が残っているほど、その分の稼働が積み上がります。

刷新のプロジェクトが終わった後に初めて、自動化に着手する進め方があります。作っている間は「動かすこと」を優先すると、繰り返し発生する作業をどう減らすかは後に回ります。

自動化できる作業の洗い出し

運用作業の自動化を徹底するには、まずどの作業を自動化できるかを洗い出す仕事が必要です²。この洗い出し自体が、成果物を作り終えた後に発生する仕事のひとつです。

洗い出しの後には、自動化の仕組みを組み込み、動作を確認する仕事が続きます。作る仕事が終わった時点では、この一連の作業量はまだ稼働の見積りに入っていない場合があります。

稼働の見積りに含める自動化の仕事

自動化の仕事を稼働の見積りに含めるには、運用作業の自動化を徹底する対象と範囲を、契約の早い段階ですり合わせます²。

範囲をすり合わせずに稼働を始めると、どこまでが「作る仕事」でどこからが「運用を変える仕事」か、後になって切り分けにくくなります。

自動化の仕事量が見えてくると、次に確認したいのは、日々の運用の中で見直しの対象に挙がっている個別の項目です。

図の作成：Remogu編集部。方針に挙げられている運用フェーズの項目を整理したもので、統計データではありません

4. 見直しの項目に挙がる夜間バッチの必要性

運用の中には、当初の設計のまま続いている処理が残っていることがあります。デジタル庁の方針は、夜間バッチの必要性を見直すことを挙げています²。夜間に動かしている処理が、今も同じ理由で必要かどうかを確かめる仕事です。

「動いているから残す」処理が積み上げる稼働

夜間バッチは、一度組み込むとそのまま動き続ける処理です。動いていること自体は問題にならないため、必要性を見直す機会は自然には訪れません。

夜間バッチの必要性を見直すことは、運用フェーズの項目として挙げられています²。見直しの仕事は、意識して稼働に組み込んでおく項目です。

見直しにかかる確認と調整の稼働

夜間バッチの必要性を見直すには、処理が何のために動いているかを確認し、不要であれば止める調整をする仕事が発生します。処理の数が多いほど、この確認と調整にかかる稼働も増えます。

この見直しの仕事も、成果物を作り終えた後に続く仕事の一つです。作る量だけで見積もった稼働には、この確認と調整の時間が含まれていないことがあります。

夜間バッチの必要性を見直す仕事も、契約の入り口で運用フェーズの項目として確認しておけば、後になって想定外の稼働として重なる場面を減らせます。

自動化と夜間バッチの見直しは、どちらも運用フェーズの個別の項目です。運用全体をどんな前提で計画するか、続く章で確かめます。

5. 本番稼働の後も改善を続ける前提の計画

自動化や夜間バッチの見直しのような個別の項目は、単発の作業ではなく、運用フェーズを通じて続く前提で計画されています。運用フェーズも含めて日々改善を続けていくことを前提に、予算、体制、日程を計画する必要があります²。

「作って終わり」ではなく「改善を続ける」前提

計画の前提が「改善を続けること」に置かれているため、本番稼働を始めた後の期間も、稼働がゼロになる区切りにはなりません。予算・体制・日程のいずれも、稼働が続くことを前提に組まれます²。

稼働を見積もる区切りを「本番稼働の開始」に置いてしまうと、その後に続く改善の稼働が抜け落ちます。区切りは、もう少し先に置く必要があります。

改善が続く前提での体制と日程の確認

予算や体制、日程を確認するときは、改善を続ける前提が反映されているかどうかを見ます²。本番稼働の開始だけを区切りにした日程になっていないかを確かめる進め方が現実的です。

体制についても同じ視点で見ます。刷新の期間だけに合わせて組まれた体制のままだと、運用フェーズも含めて日々改善を続ける前提²に沿った稼働を確保しにくくなります。

この前提を確認しておくと、本番稼働の後に稼働が急に減る、あるいは想定より増えるという振れ幅を、事前にならせます。改善を続ける前提は、稼働の量だけでなく、稼働がいつまで続くかという見通しにも関わります。日々の対応として何が続くのかは、この先で具体的に見ていきます。

6. 日常的な仕事としての更新への対応

運用フェーズに続く仕事には、更新への対応も含まれます。デジタル庁の方針は、サービスの更新への対応を、通常のアップデートと捉えて日常的に対応していく必要があるとしています²。

更新対応は「イベント」ではなく「日常」

更新への対応を大きなイベントとして扱うと、その回のためだけに稼働を確保すればよいように見えます。ところが方針が示すのは、通常のアップデートと捉えて日常的に対応する考え方です²。

日常的な対応として組み込むということは、更新のたびに稼働が発生するのではなく、日々の稼働の中に更新対応の時間があらかじめ含まれている状態を指します。

同じ枠に入る継続的なアップデートへの対応

継続的なアップデートへの対応も、運用フェーズの項目として挙げられています²。

更新への対応と継続的なアップデートへの対応は、どちらも一度きりの作業ではありません。稼働の見積りに、繰り返し発生する前提で組み込んでおく項目です。

改善を続ける前提の計画、日常的な更新対応、継続的なアップデートへの対応の3つは、どれも運用フェーズが続く限り繰り返されます。

項目	内容
改善前提の計画	運用フェーズも含めて日々改善を続ける前提で、予算・体制・日程を計画します2
更新への対応	通常のアップデートと捉えて、日常的に対応します2
継続的なアップデート	継続的なアップデートへの対応が挙げられています2

図の作成：Remogu編集部。方針に挙げられている運用フェーズの項目を整理したもので、統計データではありません

作った後に続く仕事を並べてみると、自動化、夜間バッチの見直し、改善を続ける前提の計画、更新への日常的な対応と、いくつもの項目が運用フェーズに残っていることが分かります。これらの項目を契約の入り口でどんな順番に置くかは、最後の章で整理します。

7. 稼働を条件として先に置く順番

運用フェーズの項目は、どれも契約の入り口で確認しておけます。稼働を条件として先に置く順番を整理します。

手がかりになるのは、システム開発の契約の実態です。取引ごとに手間や工数がかかる点を課題として挙げる企業が多いという結果が出ています³。この手間や工数の中に、運用フェーズの見直し項目が入っているかどうかが、稼働の量を左右します。

順番を決めておく理由は、後から確認すると調整の余地が狭くなるからです。稼働が始まってから運用フェーズの項目を持ち出すよりも、契約の入り口でまとめて確認しておくほうが、調整の余地は広く残ります。

先に固定する支払いに関わる条件

最初に確認するのは、検査を完了する期日と支払期日です¹。支払期日は、給付を受領した日から60日以内のできる限り短い期間内で定められます¹。ここが固まっていないと、稼働をどこまで続けるかという話し合い自体が始めにくくなります。

支払いに関わる条件を先に固定したうえで、運用フェーズの見直し項目——自動化、夜間バッチの見直し、改善を続ける前提の計画、更新への日常的な対応——が、稼働の条件に含まれているかを確かめます。

手順	確認する内容
手順1	取引ごとに手間や工数がかかる点を、課題として押さえておきます3
手順2	検査を完了する期日1と、支払期日1を確認します
手順3	運用フェーズの見直し項目が、稼働の条件に含まれているかを確かめます
手順4	期日における報酬の支払義務違反が最も多い実態を踏まえ、支払いに関わる条件を先に確認します4

図の作成：Remogu編集部。資料に挙げられている項目を、確認する順番として整理したもので、統計データではありません

令和7年度の運用状況では、期日における報酬の支払義務違反が最も多く1,135件（41.6％）です⁴。支払いに関わる条件は、運用フェーズの項目以上に、先に確認しておく重みが増します。

場所に縛られず、積み上げてきたスキルを活かせる稼働のしかたを探している場合、Remoguでは案件の90%以上がフルリモート可能です。まず登録して、自分の経験に合う条件を確かめてみる進め方もあります。

8. よくある質問

要件が途中で増えた場合、稼働の条件はどう見直せばいいですか

検査を完了する期日や支払期日は、明示する事項に挙げられています¹。稼働の上限は明示事項に含まれないため、増えた要件を運用フェーズの項目に含めるかどうかは、クライアントと協議して条件として置きます。

報酬の支払いに関する違反で、最も多いものは何ですか

令和7年度の運用状況では、期日における報酬の支払義務違反が最も多く、1,135件（41.6％）です⁴。

システムを刷新した後も、運用を従前のまま続けるとどうなりますか

システム運用が従前のままでは、コスト削減の効果は十分に出ません²。

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

出典・参考情報

＊1 公正取引委員会「フリーランス・事業者間取引適正化等法」パンフレット（2026年7月・2026年10月確認）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」刷新の限界（2026年・2026年10月確認）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」契約の負担（2025年4月・2026年10月確認）
＊4 公正取引委員会「令和7年度におけるフリーランス・事業者間取引適正化等法第2章の運用状況」最も多い違反（2026年6月・2026年10月確認）