テスト自動化の案件では、どこまで確認すれば完了と言えるのか、判断に迷う場面があります。品質の基準は現場の感覚だけで自然に定まるものではなく、あらかじめ合意しておく対象があります。デジタル庁が公開する実践ガイドブックには、テスト計画の段階で確認方法・承認方法・納品物を関係者の間で合意しておくという項目が置かれています。この記事では、その合意の場所と対象を整理します。

1. 品質の基準は、現場で自然には決まりません

ソフトウェアの品質は、直接測れません

テスト自動化の案件を任されると、成果物の完成度をどこまで確かめればよいのか、線引きに迷う瞬間があります。ソフトウェアはハードウェアと違って形が見えないため、品質そのものを直接測ることが困難です。利用時の品質は製品の品質に依存し、製品の品質はプロセスの品質に依存すると整理されています⁵。

この依存関係があるため、資料は品質管理において改善を継続し、高品質なプロセスを目指すことが重要だと述べています。出来上がったものを後から確かめるだけでなく、作り方の側を見る視点が求められます。

フリーランスとして参画するテストエンジニアにとって、この前提は仕事の見え方そのものを変えます。指定された項目を確認して終える作業と捉えるか、プロセスの品質を支える仕事と捉えるかで、クライアントに示せる価値が変わります。

事前に役割分担を把握しておくという前提があります

実践ガイドブックには、テストの前提として、Ｖ字モデルと発注者・委託先事業者の役割分担を把握するという項目が置かれています¹。この記事で扱うのは、モデルの中身の解説ではなく、品質の基準をどこで誰と合意するかという1点です。

この項目が置かれているのは、特定の企業の社内基準ではなく、行政のシステム整備を扱う実践ガイドブックです。発注者と委託先事業者という業務委託の関係のもとで整理されている点は、フリーランスとして参画するテストエンジニアの立場とも重なります。

役割分担が曖昧なまま進むと、確認すべき範囲も、承認する基準も、その場その場で決め直すことになります。合意する場所をあらかじめ決めておけば、進行のたびに基準を作り直す手間がなくなります。

役割分担を先に把握しておく姿勢は、参画したばかりの案件でも役立ちます。誰が確認し、誰が承認するのかが分かっていれば、判断に迷う場面でも、確認すべき相手にすぐたどり着けます。

図の作成：Remogu編集部。実践ガイドブックが示す品質の依存関係を整理したもので、統計データではありません

それでも、依存関係を知っているだけでは、実際に何を測り、何を測りにくいと判断すればよいのかは分かりません。次に、テストで扱う対象を「測れるもの」と「測りにくいもの」に分けて整理します。

2. 測りにくいものを扱っているという前提

見た目や動きは測れても、感じ方までは測れません

テスト自動化の案件で目に見えている作業は、画面の表示や処理の結果といった、数値や合否で表せる部分です。しかし品質にはもう一段深い階層があり、使いやすさの感じ方や、将来の変更のしやすさのように、数値化しにくい要素も含まれます。次の表は、比較的測りやすい観点と、測りにくい観点を並べたものです。どちらも品質を構成する要素であり、測りにくいからといって軽く扱ってよいわけではありません。観点ごとに分けて考えておくと、確認の抜け漏れにも気づきやすくなります。

観点	測れるもの（例）	測りにくいもの（例）
見た目や操作	画面の表示崩れ、ボタンの反応	使いやすさの感じ方
機能	想定した処理が動くかどうか	想定外の使い方への強さ
性能	応答時間や処理件数	利用が増えたときの耐性
保守性	変更にかかった時間	変更のしやすさそのもの

リモートでの参画が前提になる案件では、こうした観点を言葉にして共有しておくことが、進行の速さにもつながります。画面を並べて確認し合う場面が限られる分、あらかじめ基準を言語化しておく効果は大きくなります。

表に挙げた「測りにくいもの」は、担当者の主観に見えても、複数の利用者に共通する感じ方の傾向として捉えることができます。感じ方だからといって、根拠のない話として扱う必要はありません。

測りにくいものほど、先に基準を決めておく必要があります

数値で表しにくい観点は、テストが終わったあとにまとめて評価しようとすると、担当者の感覚に頼ることになります。感覚に頼った判断は、担当者が変わるたびに揺れます。だからこそ、何を確認し、誰が承認するのかを、作業に入る前の段階で合意しておくことが有効です。

この考え方は、テスト自動化の案件においても変わりません。自動化して確認する対象そのものが、事前に合意した基準に沿っているかどうかが問われます。

測りにくいものを扱っているという前提に立つことは、テストエンジニアとしての説明力を高めることにもつながります。感覚を言葉に変える力が、合意の土台になります。

リモートで参画する案件では、担当者同士が同じ画面を見ながら確認し合う場面が限られます。測りにくい観点ほど、あらかじめ言葉で合意しておく必要性が高まります。

測りにくい観点があることを踏まえたうえで、次はその基準を実際にどこで合意すればよいのかを見ていきます。

3. 合意する場所は「テスト計画段階」です

合意しておく4つの対象

実践ガイドブックは、テストを実施する際に取得するテストエビデンスの対象について、テスト計画の段階で受託者と確認方法や承認方法、納品物を関係者の間で合意しておく必要があると明記しています³。取得するエビデンスの対象・確認方法・承認方法・納品物という4つが、合意しておくべき中身です。

この4つは、どれか1つを決めれば済むものではありません。対象を絞り込んでも、承認する人が決まっていなければ、完了の判断はまた揺れます。4つをまとめて合意しておくことが、進行を安定させる前提になっています。

図の作成：Remogu編集部。実践ガイドブックが挙げるテスト計画段階での合意対象を整理したもので、統計データではありません

エビデンスの対象は、何を証拠として残すかという範囲そのものです。確認方法は、その証拠をどう確かめるかという手順です。承認方法は、誰がどう判断すれば完了と認められるかという基準です。納品物は、最終的に何を提出するかという成果物の形です。

参画する側から、この4つを先に提案しておくことも、合意を早める一つの方法です。何を確認し、どう承認してもらうかを自分の言葉にしておくと、認識のずれを防ぎやすくなります。

対象があらかじめ言葉になっていれば、完了を報告する場面で、認識の違いが表面化しにくくなります。報告のたびに基準を説明し直す手間も減ります。

合意を後回しにすると、進行の途中で基準が動きます

この4つを決めないまま作業に入ると、途中で「これはエビデンスとして必要か」「誰が確認すれば承認になるのか」といった疑問が、そのつど発生します。あらかじめテスト計画の段階で合意しておけば、進行中に基準を作り直す手戻りを防げます。

合意のタイミングを早めることは、手戻りを防ぐだけでなく、クライアントとの信頼関係にもつながります。基準が明確な状態で仕事を始められることは、双方にとって安心材料になります。

対象を絞り込む合意ができたところで、次はエビデンスそのものの扱い方を見ていきます。

4. エビデンスは多いほど良いわけではありません

取得しすぎると、コストに跳ね返ります

実践ガイドブックには「テストのエビデンスを取得するメリット・デメリット」という参考が置かれています。画面キャプチャやログ、テスト実行前後のデータといった、すべてのエビデンスの取得を安易に求めると、不要なものまで求めすぎてコストにつながることが示されています⁴。エビデンスを求める側と用意する側、どちらか一方の問題ではなく、対象をあらかじめ絞り込んでおくことが、双方にとっての合意事項になります。

エビデンスを求める背景には、進行が見えないことへの不安があります。だからこそ、対象をあらかじめ絞り込み、双方が納得できる範囲を決めておくことが、不安を解消する近道になります。

何を、何のために記録するのか

エビデンスは種類によって記録する内容が異なり、取得の負担も異なります。次の表は、実践ガイドブックが挙げる主なエビデンスの種類と、それぞれが何を記録するためのものかを整理したものです。取得する対象を種類ごとに切り分けておくと、必要なものと不要なものの線引きがしやすくなります。種類ごとの目的を先に共有しておけば、確認する側と用意する側の認識も揃いやすくなります。

エビデンスの種類	記録する内容	求めすぎたときの影響
画面キャプチャ	見た目の結果	枚数が増え、確認の負担が増す
ログ	処理の経過	量が膨らみ、確認の範囲が広がる
テスト実行前後のデータ	状態の変化	保管や照合の手間が積み重なる

種類ごとの負担を把握しておくと、エビデンスを追加で求められた場面でも、何を優先すべきかを判断しやすくなります。判断の基準を持っておくことは、対応の速さにもつながります。

種類ごとに何を確認したいのかを先に決めておけば、取得するエビデンスの量は自然に絞られます。集めてから減らすより、初めから対象を決めておくほうが、双方の負担は小さくなります。

エビデンスの範囲を必要以上に広げないよう、参画する側から取得する種類を提案してみることもできます。目的に合わせて種類を絞ることは、双方の負担を減らす合意の一部です。

取得したエビデンスを種類ごとに分けて保管しておくと、あとから確認したい範囲だけを取り出しやすくなります。整理の手間は、確認や引き継ぎの場面で効いてきます。

エビデンスを提出するタイミングも、あらかじめ合意しておくと段取りを立てやすくなります。日々の確認と納品時の確認とでは、必要な粒度が異なります。

エビデンスの扱い方が整理できたら、次は役割分担とテスト環境という、合意のもう一つの軸を確認します。

5. 役割分担と環境は、セットで決めます

役割分担を明確にする項目があります

実践ガイドブックには、テストにおける役割分担と必要な環境を明確にするという項目が置かれています²。発注者と委託先事業者の間で、どちらが何を担うのかを先に整理しておくことが前提になっています。

役割分担が明確であることは、テストの結果を誰がどう受け止めるかにも関わります。確認した内容をどちらが承認するかが決まっていれば、報告のたびに承認者を探す手間がなくなります。

テストには、本番環境とは別の環境が必要です

テストを実施するためには、基本的に本番環境とは別のテスト環境が必要になります⁷。この環境の準備や調整は、早い段階から始めておく作業として位置づけられています²。

環境が分かれていれば、確認作業の影響が本番のデータやサービスに及ぶ心配もありません。参画したばかりの担当者でも、安心して確認を進められる土台になります。

環境の用意が後手に回ると、テストの開始そのものが遅れます。役割分担が決まっていることよりも、環境が実際に動く状態で用意されていることのほうが、進行のよりどころになります。

参画する側から見ると、テスト環境の状態は着手前に確認しておきたい項目のひとつです。誰が用意し、いつ使える状態になるのかを早めに共有してもらえると、見積もりや進行の計画も立てやすくなります。

リモートで参画する場合、環境の状態を実際に目で確かめる機会は限られます。だからこそ、環境がいつ、どのような状態で使えるようになるのかを、言葉で共有しておくことが重要です。

役割分担と環境が整ったら、最後に評価そのものの視点を、結果からプロセスへ移していきます。

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

6. 結果ではなく、進め方を見る

結果だけを見た場合と、進め方を見た場合の違い

品質は測りにくいという前提に立つと、評価のしかたも変わります。最終的に動作したかどうかという結果だけを見る進め方と、確認の手順や見直しの仕組みそのものを見る進め方では、見えてくるものが違います。次の表は、その視点の違いを整理したものです。どちらの視点も必要ですが、結果だけに偏ると、変化への対応が後手に回りやすくなります。

観点	結果だけを見た場合	進め方を見た場合
何を確認するか	最終的に動作したかどうか	確認の手順が明確かどうか
変化への対応	その場ごとに判断する	手順そのものを見直す
積み上がるもの	個別の合否の記録	品質を生み出す体制

結果だけを見る進め方は、うまくいっている間は問題が見えません。しかし変化が起きたときに、何を直せばよいのかが分かりにくくなります。進め方そのものを見ておくと、変化への対応が早くなります。

改善を続けることが、高品質なプロセスにつながります

ソフトウェアの品質管理では、改善を継続し高品質なプロセスを目指すことが重要だと整理されています⁶。一度決めた基準を守り続けることよりも、基準そのものを見直し続ける姿勢のほうが、長い目で見た品質を支えます。

基準を守ることと、基準を見直すことは、矛盾する行為ではありません。むしろ両方を並行して進めることが、変化を伴う案件でも品質を保つ支えになります。

基準を一度決めて終わりにせず、案件が進むたびに見直す姿勢は、テストエンジニアとしての価値を積み重ねる土台になります。積み重ねた見直しの経験は、次の案件でも活かせます。

進め方そのものを評価対象にする視点は、単発の案件だけでなく、長期にわたって参画する案件でも、信頼を積み重ねる材料になります。

ここまで見てきたように、品質の基準は、テスト計画の段階で確認方法・承認方法・納品物を合意しておくことで安定します。ここからは、案件選びや参画にあたってよく寄せられる疑問を、Q&A形式で確認します。

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

7. よくある質問

テスト自動化の案件では、どのような経験が評価されますか

テスト計画の段階で確認方法や承認方法を関係者と合意できる経験は、実践ガイドブックが挙げる項目とも重なります³。エビデンスの対象をあらかじめ絞り込みながら進められる経験も、あわせて評価されやすい要素です。合意した内容を記録として残せる経験も、参画先からの信頼につながります。

品質の基準を事前に合意しないまま進めると、何が起こりますか

確認方法や承認方法があいまいなまま進めると、完了の判断がそのつど変わりやすくなります。テスト計画の段階で対象を合意しておくことが、そうした揺れを防ぐ前提になっています³。基準が揺れるたびに手戻りが発生し、進行全体の遅れにもつながります。

テスト環境は案件ごとに用意されているのですか

テストには基本的に本番環境とは別のテスト環境が必要になり⁷、その準備は早い段階から進める作業として位置づけられています²。用意のしかたは案件によって異なるため、参画時に確認しておくと安心です。環境の状態を早めに共有してもらえると、着手後の手戻りを減らせます。

テストエンジニアの案件はリモートで進めやすいですか

Remoguに掲載されている案件の90%以上がフルリモート可能です⁸。ただし環境の整え方や確認の進め方は案件によって異なるため、参画前にクライアントとすり合わせておくことをおすすめします。合意した内容を記録に残しておくと、リモートでのやり取りでも認識のずれを防げます。

品質の基準を、案件の中でどうやって記録に残せばよいですか

テスト計画の段階で合意した確認方法・承認方法・納品物は、短いメモや議事録の形で残しておくだけでも役立ちます。合意した内容を文書として残しておくと、参画期間の途中で担当者が替わっても、基準がぶれずに引き継がれます。

品質の基準は、現場の空気で自然に決まるものではありません。テスト計画の段階で、確認方法・承認方法・納品物を関係者の間で合意しておくことが、その後の進行を安定させます。合意の中身を記録に残しておけば、案件が進むあいだ、判断の拠り所として使い続けられます。

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

出典・参考情報

＊1 デジタル庁「デジタル・ガバメント推進標準ガイドライン」DS-120 実践ガイドブック（2025年5月）
＊2 デジタル庁「デジタル・ガバメント推進標準ガイドライン」DS-120 実践ガイドブック（2025年5月）
＊3 デジタル庁「デジタル・ガバメント推進標準ガイドライン」DS-120 実践ガイドブック（2025年5月）
＊4 デジタル庁「デジタル・ガバメント推進標準ガイドライン」DS-120 実践ガイドブック（2025年5月）
＊5 デジタル庁「デジタル・ガバメント推進標準ガイドライン」DS-120 実践ガイドブック（2025年5月）
＊6 デジタル庁「デジタル・ガバメント推進標準ガイドライン」DS-120 実践ガイドブック（2025年5月）
＊7 デジタル庁「デジタル・ガバメント推進標準ガイドライン」DS-120 実践ガイドブック（2025年5月）
＊8 Remoguサイト公開情報（案件の90%以上がフルリモート可能）