テストの案件では、範囲の説明が「一通り確認します」で終わることがあります。工程書や仕様書に何が書かれているかによって、確認する項目も、戻せる範囲も変わります。ここでは確認した数の多さではなく、工程・文書・責任という3つの手がかりから範囲を組み立てる考え方を整理します。契約の前に何を確かめておくと、あとで話がずれにくいかもあわせて見ていきます。

1. 範囲を決めるのは数ではなく3つの軸

案件の説明で範囲を聞かれると、確認した項目の数で答えたくなります。ただ、数だけでは案件ごとの違いを説明できません。同じ項目数でも、対象になる工程や文書、決める人が違えば、範囲の重さはまったく別のものになります。

確認した数を増やしても、話は噛み合わない

件数を積み上げる説明は、聞く側との認識のずれを埋めません。相手が知りたいのは、どの工程まで見たか、どの文書を根拠にしたか、そして誰がその範囲で良いと判断したかです。件数はその結果でしかありません。

利用する企業は、システムの品質を最も優先する事項として捉えています¹。優先順位が高いからこそ、範囲の説明を数字だけで済ませると、伝わったはずの安心感が薄くなります。

「期待する効果を得られていない」という回答は、比較した4か国の中で最も多くなっています¹⁰。期待と実感の差は、範囲の説明のしかたからも生まれます。

決め手になるのは工程・文書・責任の3つ

1つ目は工程です。要件定義から結合、受け入れまでのどこを対象にするかで、確認する内容は変わります。2つ目は文書です。何を根拠に項目を起こしたかを示せると、範囲の説明に厚みが出ます。3つ目は責任です。最終的に「ここまでで良い」と判断する人が誰かによって、範囲の終わり方が変わります。

この3つは順番に積み上がる関係にあります。工程が決まって初めて文書が絞られ、文書が絞られて初めて誰が判断するかがはっきりします。次の章では、このうち文書から確認項目を起こす部分を見ていきます。

図の作成：Remogu編集部。範囲を決める3つの要素の関係を整理したもので、統計データではありません

2. 確認する項目は文書から起こせる

確認する項目を思いつきで並べると、案件ごとにばらつきが出ます。項目を文書から起こすようにすると、根拠がそろい、説明もしやすくなります。

開発の手法は、いまもウォーターフォール型が中心

開発の手法は、いまもウォーターフォール型が主流です²。工程が順番に進む前提があるからこそ、各工程で確定した文書を、その都度確認項目に落とし込めます。

工程が前後する進め方だと、文書がまとまる前に確認を始めることもあります。その場合は、確定した範囲とこれから変わる範囲を分けて扱うことが助けになります。

文書の種類ごとに、確認する項目が変わる

要件定義と設計は、いまも文書を中心に進められています³。文書の種類によって、書かれている内容も、そこから起こせる確認項目も変わります。次の表は、代表的な文書と、そこから起こせる確認項目の対応を整理したものです。

文書	主に書かれている内容	そこから起こせる確認項目
要件定義書	実現したい業務の流れや利用者の条件	業務の流れどおりに動くかどうかの確認項目
設計書（外部・内部）	画面や機能、データの構成	画面表示・入力の妥当性・データの整合性の確認項目
仕様変更の記録	変更した箇所と変更した理由	変更の前後で挙動が変わっていないかの確認項目
運用手順書	障害時の対応や切り戻しの手順	手順どおりに戻せるかどうかの確認項目

図の作成：Remogu編集部。文書から確認項目を起こす流れを整理したもので、統計データではありません

確認項目を一覧にしておくと、担当者が変わっても同じ基準で確認を引き継げます。

文書から確認項目を起こす流れがそろうと、担当者が変わっても確認の基準がぶれにくくなります。次の章では、この中でも戻せない範囲をどう見るかを取り上げます。

3. 戻せない範囲ほど慎重に確かめる

確認する範囲を考えるとき、戻せるかどうかは大きな分かれ目になります。壊れたときに元に戻せる範囲であれば、確認をあとから足すこともできます。戻せない範囲は、先に慎重に見ておく必要があります。

戻せる範囲と、戻せない範囲がある

ITのリスク管理と業務継続計画を整備している企業は、全体の5〜6割程度です⁵。整備が及んでいない領域では、障害が起きたときに戻す手順そのものが定まっていない可能性があります。

戻せない範囲は、確認をあとに回せません。案件を受ける段階で、どこまでが戻せる範囲なのかを確かめておくと、あとになって慌てずに済みます。

整備の度合いは企業によって差がある

構成管理のツールがどこまで整っているかは、確認できる範囲の広さに直結します。ツールが整っていれば、変更の履歴をたどって戻す範囲を特定できますが、整っていなければ、その特定自体が難しくなります。次の表は、整備の状況と、戻せない範囲との関係を整理したものです。

項目	状況	戻せない範囲との関係
ITのリスク管理と業務継続計画	整備している企業は全体の5〜6割程度5	未整備の領域は、障害時に戻す手順が定まっていない可能性がある
構成管理ツール（ユーザー企業）	導入している企業は約3割6	変更履歴をたどれない範囲が残りやすい
構成管理ツール（ベンダー企業）	導入している企業は約4割6	開発側でも管理の範囲に差が出る

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

整備の度合いをあらかじめ聞いておくと、戻せない範囲の見積もりがしやすくなります。

構成管理のツールを導入している企業は、ユーザー企業で約3割、ベンダー企業で約4割にとどまります⁶。導入の有無を確かめることは、戻せる範囲を見積もる手がかりになります。

4. 「ここまでで良い」と決める人がいない

範囲の終わりを決めるのは、項目の数ではなく人です。誰が「ここまでで良い」と判断するかが曖昧なままだと、確認は際限なく広がっていきます。

意思決定を担う責任者を置いていない企業がある

意思決定を担う責任者を置いていない企業は、約半数に上ります⁹。判断する人がその場にいないと、範囲の終わりを決める材料が集まりにくくなります。

案件を受ける側からすると、誰に確認すれば範囲の合意になるのかを、早い段階で確かめておく意味があります。

品質を優先する姿勢と、線引きの難しさは両立する

利用する企業は、システムの品質を最も優先する事項として捉えています¹。優先度が高いからこそ、担当者は範囲を広げる方向に判断しがちで、線引きが先送りになりやすくなります。

品質を優先する姿勢と、決める人の所在は別々に確かめておくと、範囲の合意はより具体的になります。

次の章では、この前提を支える仕組みが実際にどこまで動いているかを見ていきます。

5. 自動で回っている前提が崩れている

確認の範囲を狭くできる場面として、自動で検知される仕組みが挙がることがあります。ただ、その前提が実際にどこまで整っているかは、案件によって差があります。

DevOpsやモデルベース開発は、まだ限られた範囲にとどまる

DevOpsやモデルベース開発は、ベンダー企業を除くと導入している企業が少ない状況です⁴。自動で回っている前提を置く前に、その案件でどこまで整っているかを確かめておきたいところです。

自動化された仕組みがある案件と、まだ手作業が中心の案件とでは、確認する範囲の重さがまったく違います。

設計の土台からして、整っていない領域がある

モジュール性やデータモデルを意識した設計は、変更の影響範囲を机上で見通しやすくする土台になります。この土台がまだ整っていない場合、確認の範囲は自動化の有無だけでなく、設計そのものの単位から見直すことになります。次の表は、前提にされやすい仕組みと、実際の導入状況、確認しておきたい点を整理したものです。

モジュール性やデータモデルを意識した設計に取り組む企業は、ユーザー企業を中心にいまも少ない状況です⁷。

前提にされがちな仕組み	実際の導入状況	確認しておきたい点
DevOpsやモデルベース開発	ベンダー企業を除くと導入している企業は少ない状況4	自動で検知される前提の範囲がどこまでか
モジュール性やデータモデルを意識した設計	ユーザー企業を中心にいまも少ない状況7	影響範囲を机上で把握できるかどうか

前提が崩れている領域ほど、確認の範囲は狭めにくくなります。次の章では、この前提と実際の手応えの差を見ていきます。

6. 期待と実感のあいだにある差

範囲を丁寧に決めても、それだけで「うまくいっている」という実感にはつながらないことがあります。品質を優先する姿勢と、実際に得られる効果とのあいだには、まだ差が残っています。

品質を優先しているのに、効果を実感できていない

「期待する効果を得られていない」という回答は、比較した4か国の中で最も多くなっています¹⁰。範囲を確かめる作業そのものが目的になると、この差はさらに埋まりにくくなります。

利用する企業は、システムの品質を最も優先する事項として捉えています¹。優先しているからこそ、実感が伴わないときのずれが大きく感じられます。

実感の差を埋めるのは、範囲の合意

効果を実感できるかどうかは、確認した項目の数ではなく、範囲についての合意がどれだけ具体的だったかに左右されます。工程・文書・責任という軸に立ち返ると、どこで実感が薄れているかを見つけやすくなります。

Remoguは、リモートワークの案件に特化したエンジニアマッチングです。案件の90%以上がフルリモート可能で、テスト設計や実行の経験を、場所を選ばずに活かせる案件も並んでいます。

次の章では、この合意を実際に書面へ落とす順番を整理します。

7. 範囲を書面に落とす順番

確認する範囲が固まったら、最後に書面に残します。口頭の合意だけでは、あとになって「聞いていない」という行き違いが起きやすくなります。

確認項目を書面に落とす順番

要件定義と設計はいまも文書を中心に進められているので³、書面に落とす順番も文書の流れに沿わせると迷いにくくなります。まず対象の工程を書き出し、次に確認項目を一覧にし、戻せない範囲を明記したうえで、決める人の合意を得る、という順番です。

図の作成：Remogu編集部。範囲を書面に落とす手順を整理したもので、統計データではありません

この順番を毎回同じ形にしておくと、案件が変わっても書面の作り方に迷わずに済みます。

取引ごとの手間を減らすのは、最初の合意

取引ごとに手間や工数がかかる点は、課題として挙げる企業が目立ちます⁸。範囲を書面に落とす手順が毎回変わると、この手間はさらに増えます。

最初に合意した書面をひな形として使い回せると、取引ごとの手間は減っていきます。範囲の合意は、一度で終わる作業ではなく、案件を重ねるたびに整えていくものです。

テストの範囲が案件ごとに違うのはなぜですか

対象になる工程、根拠にする文書、そして「ここまでで良い」と決める人が案件ごとに違うためです。この3つが変われば、同じ確認項目の数であっても範囲の重さは変わります。

戻せない範囲は、どこを見て判断すればよいですか

ITのリスク管理や業務継続計画、構成管理のツールがどこまで整っているかが手がかりになります⁵。整備が及んでいない領域ほど、戻す手順そのものが定まっていない可能性があります。

範囲を書面に落とすときに、最初にすることは何ですか

対象の工程を書き出すことから始めます。工程が決まると根拠にする文書が絞られ、確認項目と戻せない範囲が明確になり、最後に決める人の合意へとつながります。

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸（2025年4月・2026年8月確認）
＊2 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」工程の前提（2025年4月・2026年8月確認）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月・2026年8月確認）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」確認の自動化（2025年4月・2026年8月確認）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」止まる備え（2025年4月・2026年8月確認）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」構成の把握（2025年4月・2026年8月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」境界の不在（2025年4月・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」契約の負担（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」決める人（2025年4月・2026年8月確認）
＊10 総務省「令和7年版 情報通信白書（デジタル活用の動向）」効果の実感（2025年7月・2026年8月確認）