案件に着手したあとに、想定していなかった後戻りが発生し、進行が止まる場面があります。原因を技術力の不足に求めがちですが、着手前に固めておきたい前提が曖昧なまま進んだことが原因になる場合もあります。公正取引委員会やデジタル庁、IPAが公表した資料には、業務委託の現場で繰り返し起きているずれの構造が示されています。この記事では、その構造を1つずつたどりながら、着手前に確かめておきたい項目を整理します。

1. 前提のよりどころになる明示項目

案件を受ける場面で最初に目を通しておきたいのが、明示される項目です。公正取引委員会が公表したパンフレットは、業務委託の依頼者が明示する事項の中に、検査を完了する期日と、報酬の額および支払期日を含めると示しています¹。ここが曖昧なまま進むと、後の工程でずれが生じやすくなります。

明示事項に含まれる検査完了の期日と報酬の支払期日

検査を完了する期日は、成果物をいつまでに確認し終えるかという区切りです。この期日が示されていないと、確認作業がいつまで続くのか見通しが立たず、次の作業に進むタイミングも曖昧になります¹。

報酬の額および支払期日も同じ性質を持ちます。金額と支払いのタイミングが着手前に明示されていれば、追加の対応が生じた場面でも、何を基準に話し合えばよいかが分かります。逆にここが決まっていないと、後から条件を確認し直す手間が発生します¹。

明示が曖昧なときに手戻りが起きる場所

検査完了の期日が共有されないまま作業を進めると、依頼した側と受けた側で「どこまで整っていれば完了か」の認識がそろわないまま検査の段階を迎えることになります。ここで見え方の違いが表面化すると、手直しの範囲や順番を改めて相談する必要が生じます。

報酬の支払期日についても同様です。支払いのタイミングが明確でないと、追加対応が発生した場面で、その対応が当初の範囲に含まれるのか、別に扱うものなのかを判断する材料がありません。着手前にこの2つを確認しておくことが、後戻りを防ぐ最初の一歩になります。

次の2つを並べておくと、着手前の確認がしやすくなります。

明示される事項	明示の内容	手戻りとの関わり
検査を完了する期日	成果物の確認を終える区切り	検査のタイミングの認識をそろえられる
報酬の額および支払期日	報酬の金額と支払いの時期	追加対応が生じた場面の扱いを話し合う基準になる

図の作成：Remogu編集部。明示事項と手戻りの関わりを整理したもので、統計データではありません

次の章では、この明示事項がなぜ近年あらためて追記されているのか、システムの現場から見ていきます。

2. 追記された現行システムへの対策

案件の対象は、新しく作るシステムとは限りません。長く運用されてきたシステムの改修が対象になることもあります。デジタル庁が示す基本方針は、複雑化した現行システムへの対策を追記したと明らかにしています²。

長く運用されてきたシステムの把握にかかる時間

運用期間が長いシステムほど、当初の設計から手が加えられ、構造が複雑になっている場合があります。この複雑さを着手前にどこまで把握できているかが、その後の見積もりや進め方に影響します。

デジタル庁の基本方針が現行システムへの対策を追記した背景には、こうした複雑化したシステムを扱う場面が増えている実情があると考えられます²。把握が浅いまま作業を始めると、想定していなかった依存関係に途中で気づくことになります。

追記の経緯と着手前の確認

基本方針に対策が追記されたということは、現行システムの把握が着手前の重要な工程として位置づけられたと受け止められます。案件を受ける側としても、既存の仕組みをどこまで確認できる状態にあるかを、契約の前に尋ねておく価値があります。

把握が十分でないまま進めた場合に起きる手戻りは、設計のやり直しだけでなく、確認済みと思っていた範囲の再確認にも及びます。着手前の一手間が、後の負担を左右します。

次の章では、この現行システムへの対策と並んで追記された、画面や帳票に関する項目を見ていきます。

3. 項目に加わった画面や帳票の見直し

システムの内部構造だけでなく、利用者が直接目にする部分も見直しの対象に加えられています。デジタル庁の基本方針は、画面や帳票の見直しについても追記したと示しています²。

利用者が触れる部分の変更と影響範囲

画面のレイアウトや帳票の様式は、内部のロジックと比べて変更の影響が見えやすい一方、関係する部署や利用者の数が多く、確認に時間がかかる場合があります。

見直しの対象に画面や帳票が追記されたということは、この確認の手間があらかじめ想定に入れられるようになったと捉えられます²。着手前にどの画面・帳票が対象になるのかを確認しておくと、後工程での認識のずれを防ぎやすくなります。

見た目の変更が、後工程に響く理由

画面や帳票は、利用者の業務の流れそのものに組み込まれています。表示項目や様式が変わると、利用者側の確認や周知にも時間が必要になり、内部の処理だけを直す場合よりも関係者が増えます。

この範囲を着手前に洗い出しておくことが、検査の段階で「想定していなかった画面が対象だった」という手戻りを避ける手がかりになります。

画面や帳票のように目に見える部分だけでなく、現場がそもそも何を優先しているかも、手戻りの起きやすさに関わります。次の章で見ていきます。

4. 品質を最優先とする現場の前提

着手前に確認しておきたいのは、明示される項目や見直しの範囲だけではありません。現場がそもそも何を優先しているかという前提も、手戻りの起きやすさに関わります。IPAの調査は、利用する側の企業が品質を最も優先する事項として捉えていると示しています³。

速さより品質を優先する前提

品質が最も優先される事項として挙げられているということは、進行の速さよりも、出来上がったものの正しさが重視される場面が多いと読み取れます³。

この前提を知らずに、速く終わらせることを優先して進めると、確認の段階で「もっと確かめてほしかった」という食い違いが生じる可能性があります。

着手後に表面化する優先順位のずれ

品質を優先する現場では、検査の基準も厳しめに設定されていることが少なくありません。この基準を着手前にすり合わせておかないと、検査の段階で初めて基準の高さに気づくことになります。

着手前に「何を確認されるのか」を尋ねておくことは、後の手戻りを減らす手がかりになります。

品質が優先される背景には、開発の進め方そのものも関係しています。次の章では、その進め方を見ていきます。

5. 開発手法はいまもウォーターフォールが主流

現場が品質を優先する背景には、開発の進め方そのものも関わっています。IPAの調査は、開発手法として依然としてウォーターフォール型の手法が主流であると示しています³。

今も中心にある段階を追って進む手法

ウォーターフォール型の手法は、要件定義、設計、実装、検査というように、段階を順番に進めていく手法です。前の段階が固まってから次に進むため、後の段階で見つかった問題は、前の段階まで戻って直すことになります。

この手法が今も主流であるという前提を知っておくと、着手前にどの段階まで固まっているのかを確認する重要性が見えてきます³。

段階が進むほど大きくなる後戻りの負担

要件定義の段階で見つかった認識のずれは、修正の範囲が限定的です。一方、検査の段階で初めて見つかったずれは、設計や実装まで戻って直す必要があり、負担が大きくなります。

着手前にどの段階の内容がどこまで固まっているかを確認しておくことは、後戻りの規模を小さくする手がかりになります。

段階を追って進む手法の下では、品質の確認が最後の段階に集まりやすくなります。次の図は、この2つの前提を重ねて示したものです。

図の作成：Remogu編集部。開発の段階と品質確認の重なりを整理したもので、統計データではありません

6. 文書中心で進む要件と設計

段階を追って進める手法のもとで、要件定義や設計がどのように行われているかも見ておきたい点です。IPAの調査は、要件定義と設計はいまもドキュメントを中心に行われていると示しています³。

今も変わらない文書中心の進め方

要件定義書や設計書といった文書に決めごとを残しながら進める方法は、口頭でのやり取りだけに頼るよりも、後から見返せるという利点があります。この進め方が今も中心にあるという調査結果は³、案件を受ける側にとっても、文書に残っている内容がそのまま前提になることを意味します。

裏を返せば、文書に書かれていない部分は、前提として共有されていない可能性があるということでもあります。

取り組みが少ないモジュール性とデータモデルの設計

同じ調査は、モジュール性やデータモデルを意識した設計に取り組む企業は依然として少ないと示しています³。

この設計への取り組みが十分でない状態のまま着手すると、後になって構造上の変更が必要になった際に、影響範囲を洗い出す作業が大きくなりやすくなります。

着手前に確認する観点は、次の3つです。

観点	現場でよく見られる傾向
開発の進め方	段階を追って進むウォーターフォール型の手法が主流です3
要件定義・設計	文書を中心に決めごとを残しながら進めます3
モジュール性・データモデルの設計	意識した設計に取り組む企業は依然として少数です3

図の作成：Remogu編集部。文書化が進んでいる領域と設計の作り込みが進んでいない領域を整理したもので、統計データではありません

文書に残っている内容と、まだ整っていない設計の領域を分けて把握しておくことが、着手前の確認をより具体的にします。次の章では、契約の場面に目を移します。

7. 契約の手間と、着手前に確かめる項目

では、契約の場面では何が課題になっているのでしょうか。IPAの調査は、システム開発の契約では取引ごとに手間や工数がかかる点を課題に挙げる企業が多いと示しています³。

課題になっている契約の手間とモデル契約への理解

取引のたびに契約内容を一から検討する手間がかかるという課題は、依頼する側にとっても負担です。同じ調査は、モデル契約そのものを知らないとする企業も多いと示しています³。

モデル契約とは、契約で定めておきたい項目をあらかじめ整理したひな型のことです。これを知らないまま個別に契約内容を作ると、検査完了の期日や報酬の支払期日といった項目が漏れやすくなります。

実際に起きている明示義務違反

公正取引委員会が公表した運用状況では、取引条件の明示義務違反が1,126件（41.3%）にのぼると示されています⁴。

この数字は、明示が必要な項目が実際に漏れる場面があることを表しています。着手前に自分から確認する姿勢が、手戻りだけでなく、こうした食い違いを防ぐことにもつながります。

手戻りを防ぐ着眼点は、能力を高めることではなく、着手前に前提を確認する行動そのものにあります。確認する項目を自分の中で持っておくことが、次の案件でも役立ちます。

確認する項目	確認するねらい
検査を完了する期日	検査のタイミングの認識をそろえる1
報酬の額と支払期日	支払いのタイミングを事前に共有する1
契約に伴う手間の見通し	契約内容の準備にどれくらい時間がかかるかを把握する3
モデル契約の内容	契約条件のひな型を事前に確認する3

図の作成：Remogu編集部。着手前に確認しておきたい項目を整理したもので、統計データではありません

着手前に確認する項目は、案件を選ぶ場面でもそのまま使えます。今回整理した項目を、次の案件を検討する際の手がかりにしてください。

8. よくある質問

検査を完了する期日は、どのような場合に明示されますか

給付の内容について検査する場合は、検査を完了する期日が明示事項に含まれます¹。

現行システムの改修では、画面や帳票も確認の対象ですか

デジタル庁の基本方針には、複雑化した現行システムへの対策が追記されています²。画面や帳票の見直しについても追記されているため、対象になるかどうかを着手前に尋ねておけます²。

モジュール性やデータモデルを意識した設計に取り組む企業は、どちらで少数ですか

IPAの調査は、特にユーザー企業を中心に依然として少ないと示しています³。

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

出典・参考情報

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