テストエンジニアとして業務委託の打診を受けたとき、渡された要件定義書と設計書の対応関係が、誰の手でも整理されていない状態のまま実行が始まる場面があります。実行を始める前にこの状態を放置すると、後になって漏れの責任を引き受ける立場に回りやすくなります。デジタル庁の実践ガイドブックは、要件と設計の突合を後工程の手戻りを防ぐための工程として位置づけています。この記事では、実行の前に合意しておくと扱われ方が変わる3つの点を整理します。

1. テストの案件で見られているのは、実行より前の段取り

任されるのが実行だけだと思っていた案件で、テストケースの元になる要件定義書が更新されないまま渡される場面があります。目の前の項目を消化するほど、抜けている観点があるのではという不安が積み上がっていきます。

この不安の正体は、実行の技術が不足していることではなく、入り口で定めておく合意が整っていないことにあります。合意の中身さえつかめれば、不安の輪郭ははっきりします。

実践ガイドブックは、この入り口の合意についてある考え方を示しています。次の項目から、その内容を1つずつ確認していきます。

手戻りを防ぐために、突合が前工程に置かれている

実践ガイドブックは、要件定義と設計内容の突合について、後工程における要件漏れによる手戻りを防止し、イレギュラーな開発コストの増大を抑えるために極めて重要だと述べています¹。実行の前に置く工程として位置づけられている点が、テストの案件を評価する軸を変えます。

手を動かす前の段階で要件と設計の対応関係を確かめておくと、実行の途中で見つかる矛盾の数そのものが変わります。この工程を飛ばしたまま実行に入ると、矛盾に気づくたびに差し戻しの相談が発生し、進行そのものが止まりやすくなります。

実行の技術は前提。差が出るのは合意の有無

テストケースを丁寧に書ける技術よりも、実行に入る前に何を合意したかという段取りのほうが、参画後の扱われ方を左右します。実行の腕はいわば前提で、そこから先の評価は段取りに委ねられています。

この後の3つの項目では、要件と設計の突合、変更の記録、エビデンスの対象という順に、入り口で合意しておく中身を具体的に見ていきます。

図の作成：Remogu編集部。実践ガイドブックが示す考え方をもとに整理したもので、統計データではありません

2. 合意1｜要件と設計をどう突き合わせるか

要件定義書と設計書を並べて開いても、どこまで対応が取れているかを一目で判断できる状態になっている案件ばかりではありません。対応関係を頭の中だけで追おうとすると、抜けに気づく前に実行が進んでしまいます。

実践ガイドブックは、この対応関係を可視化する型としてRTM（Requirements Traceability Matrix）を示しています²。名称を知っておくだけで、次に何を求められているかの見通しが変わります。

RTMという整理の型を知っておく

RTMは要件と設計の対応を一覧で管理する考え方で、実践ガイドブックはこれをRTMとして整理した例だと紹介しています²。ひな形をそのまま覚える必要はなく、要件を単位として並べ、対応の有無を記録するという考え方をつかんでおけば十分です。

道具の名前を先に押さえておくと、案件に入った直後に整理の形式を尋ねられたときも、要点を外さずに答えの方向を示せます。

列挙と反映済の記録が、抜け漏れを防ぐ

実践ガイドブックは、RTMの左側に要件定義書の項目全てを要件単位で列挙すると説明しています³。感覚で拾うのではなく、列挙そのものを作業として区切ることで、拾い残しが起きにくくなります。

その上で、設計書案に要件が正確に反映されていた場合は「反映済」と記録すると説明されています⁴。反映の有無を1語で記録できる形にしておくと、後から見返した人にも状況が伝わりやすくなります。

反映済という言葉に統一しておくと、複数人が同じ記録を見たときの解釈のずれも小さくなります。列挙の作業よりも、記録の言葉をそろえるほうが、後から効いてきます。

突合の記録に置く列を先に決めておく

細かな様式を作り込むよりも先に、記録として残す列の種類を決めておくと、案件ごとに形式が変わっても対応しやすくなります。以下は、その列を整理したものです。

列	記録する内容	見る観点
要件の単位	要件定義書の項目を要件ごとに分けたもの	拾い残しがないか
対応状況	設計書案に要件が反映されているかの状態	反映済か未対応か
変更の有無	要件から変わった箇所があるか	変更理由が明確か
承認の記録	変更をプロジェクトとして承認したかどうか	跡が残っているか

3. 合意2｜変わったときに何を残すか

要件定義書どおりに進めていたつもりでも、設計が進むうちに当初の内容から変わっている箇所が見つかることがあります。

問題になるのは変わったこと自体ではなく、その変更が誰の判断で認められたのかという跡が残っていないことです。

実践ガイドブックは、この点についてある基準を示しています。

変更理由を明確にする

実践ガイドブックは、要件から変更があったものについて、変更理由を明確にするとともに、変更することをプロジェクトとして承認したかについても確認すると説明しています⁵。理由と承認という2つを分けて記録する形が示されている点が要点です。

理由だけを書き残しても、誰がその変更を認めたかが分からなければ、後になって責任の所在を巡る話し合いに時間を取られやすくなります。

「変わったこと」より「承認の跡があるか」を見る

変更点の数を数えることよりも、承認の跡が残っているかどうかを確認するほうが、後工程での揉め事を防ぐ手がかりになります。変更の多さよりも、承認の抜けのほうが後から重く響きます。

次の項目では、この承認の跡と並んで合意しておきたいエビデンスの対象について確認します。

図の作成：Remogu編集部。実践ガイドブックが示す考え方をもとに整理したもので、統計データではありません

4. 合意3｜エビデンスの対象を先に決める

テストを進めている途中で、想定していなかった証跡の提出を後から求められ、対応に追われる場面が案件によっては起こります。

この後出しを防ぐ鍵は、証跡として何を残すかを実行に入る前の段階で決めておくことにあります。

エビデンスの対象を事前に合意する

実践ガイドブックの改定では、取得するテストエビデンスの対象を事前に合意するという項目が加えられています⁸。何を残すかを後から広げるのではなく、入り口で線引きしておく考え方が明確になった形です。

対象を先に決めておくと、実行の途中で追加の証跡を求められたときも、当初の合意に照らして話し合う土台ができます。

対象を決める作業そのものは重くありません。項目を洗い出し、クライアントと合意する時間を実行の前に確保できるかどうかが分かれ目になります。

道具はツールでもExcelでも構わない

実践ガイドブックは、突合の管理についてツールでなくともExcel等で突合確認することもあると述べています⁶。特定の道具を使いこなす技術よりも、何を合意しているかという中身のほうが重視されている点が読み取れます。

道具選びに時間をかけるよりも、対象の合意を先に固めておくほうが、案件が変わっても持ち運べる考え方になります。

エビデンスの対象を決めるときの観点

対象を決める際に、何を基準に線引きするかをあらかじめ整理しておくと、合意の場での話し合いがまとまりやすくなります。以下は、その観点をまとめたものです。

観点	確認する内容
取得する範囲	どの工程・どの機能の証跡を残すか
保管の形式	画面の記録か、ログか、帳票か
合意のタイミング	実行の前に決めているか、後から追加されていないか
確認する相手	クライアントと対象を協議しているか

図の作成：Remogu編集部。実践ガイドブックが示す考え方をもとに整理したもので、統計データではありません

5. 3つの合意があると、非機能面まで手が届く

実行の途中で手一杯になり、非機能面の確認まで手が回らないまま案件が進んでいく場面があります。

非機能面が後回しになる背景には、機能面の確認だけで手いっぱいという事情に加えて、前の3つの合意が整っていないことが影響しています。

機能面と非機能面をそれぞれ確認する

実践ガイドブックは、機能面としてシナリオテストや業務サイクルテスト等、非機能面として負荷テスト・セキュリティテスト・縮退テスト等をそれぞれ確認すると説明しています⁷。機能面だけでなく非機能面も並べて確認する対象として位置づけられている点が要点です。

機能面の確認に追われている状態では、非機能面の項目まで手を伸ばす余力が残りにくくなります。

非機能面は、前の3点が片付いて初めて視野に入る

要件と設計の突合、変更の承認の跡、エビデンスの対象という3つの合意が整理されていると、機能面の確認にかかる時間そのものが短くなり、非機能面まで意識を向ける余地が生まれます。

逆に3つの合意が定まっていない案件では、機能面の確認だけで実行の時間が埋まり、非機能面は後回しにされやすくなります。合意が整理されている案件のほうが、担える範囲そのものが広がります。

テストの経験を4つの層で書き出す

自分がこれまで担ってきたテストの経験を振り返るときも、機能面と非機能面を分けて棚卸しすると、次の案件でどの層まで担えるかを示しやすくなります。以下は、その層を整理したものです。

案件の90%以上がフルリモート可能です⁹。非機能面まで担える経験を言葉にできていると、リモートで進める案件でも、実行だけでなく判断の部分まで任せてもらえる話し合いにつながります。

層	担ってきた内容の例
実行	テストケースの実施と結果の記録
突合	要件と設計の対応関係の確認
変更管理	変更理由と承認の記録の整理
非機能	負荷・セキュリティ・縮退テスト等の確認

図の作成：Remogu編集部。実践ガイドブックが示す考え方をもとに整理したもので、統計データではありません

6. まとめ

テストの案件で評価されるのは、実行の丁寧さだけではありません。要件と設計の突合、変更の承認の跡、エビデンスの対象という3つを実行の前に合意できているかどうかが、扱われ方を大きく左右します。

この3点は、どれも特別な道具や資格を必要としません。実践ガイドブックが示す考え方を知り、案件に入る前にクライアントと言葉を交わしておくだけで、後工程での手戻りや後出しの依頼に振り回されにくくなります。

3つの合意を積み重ねた先には、非機能面まで含めた確認を任される案件が見えてきます。実行だけでなく判断の部分を担える経験として、これまでの仕事を言葉にしてみることが次の一歩になります。

まずは自分のテストの経験を4つの層に沿って書き出し、テスト・QA分野の案件を確認しながら、どの層まで任せてもらえそうかを照らし合わせてみましょう。登録して自分の経験に合う条件を確かめてみることも、次の一歩になります。

7. よくある質問

要件定義書が最新でない場合はどうするか

要件定義書が更新されていない状態そのものを問題として抱え込む必要はありません。実践ガイドブックが示すRTMの考え方に沿って、現状の要件定義書に載っている項目をまず要件単位で列挙し、設計書案との対応を確認するところから始めれば、更新の遅れがある案件でも合意の土台を作れます²。更新が必要な箇所が見つかったら、それ自体を変更として扱い、理由と承認の記録に乗せていく形で対応できます⁵。

エビデンスの要求が後から増えるのを防げるのか

実践ガイドブックの改定は、取得するテストエビデンスの対象を事前に合意する項目を加えています⁸。実行に入る前にこの対象を明文化しておけば、後から追加の要求が来たときも、当初の合意に照らして話し合う土台ができます。対象を隅々まで固定できる保証まではありませんが、後出しの要求に対して交渉できる材料を持てる点が変わります。

突合は誰の仕事なのか

突合の記録を最終的に確認し、変更を承認するかどうかを判断するのはクライアント側の役割です。テストエンジニアの役割は、要件と設計の対応状況を正確に整理し、判断に必要な材料を過不足なく揃えて提示することにあります。承認の判断そのものを引き受ける立場ではなく、判断できる形に整える立場だと捉えておくと、役割の境界がはっきりします。

自動化の経験はこの3点とどう関係するか

自動化の経験があるかどうかにかかわらず、要件と設計の突合、変更の承認の跡、エビデンスの対象という3つの合意は、実行の方法とは別の階層にある話です。自動で実行するか手動で実行するかを選ぶ前提として、この3点を合意しておく必要がある点は変わりません。自動化の技術そのものを論じる記事ではないため、ここでは3つの合意との関係にとどめます。

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

出典・参考情報

＊1 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第7章 設計・開発（要件定義と設計内容の突合）（2026年6月12日）
＊2 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第7章 設計・開発（突合資料の例）（2026年6月12日）
＊3 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第7章 設計・開発（RTMの構成）（2026年6月12日）
＊4 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第7章 設計・開発（RTMの記載）（2026年6月12日）
＊5 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第7章 設計・開発（変更の扱い）（2026年6月12日）
＊6 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第7章 設計・開発（突合の手段）（2026年6月12日）
＊7 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」第3編第1章（第7章 設計・開発の紹介）（2026年6月12日）
＊8 デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」改定履歴（Step3-3-I の追加）（2026年6月12日）
＊9 Remoguサイト公開情報（フルリモート可能案件の割合）