テスト自動化の案件で最初に問われるのは、ツールを使いこなせるかどうかではありません。発注側が読む文書を見ると、増えているのはテストに関する決めごとのほうです。デジタル庁の実践ガイドブックは2025年5月27日の改定で、方針の決め方や役割分担、証跡の扱いに関する項目を相次いで追加しました。この記事では、その改定をもとに、案件の着手前に合意しておきたい項目を整理します。

1. 発注側が読む文書に、テストの項目が増えた

実務者の視点で書かれた参考文書

テスト自動化の案件に入る前に、まず知っておきたい文書があります。デジタル庁が公開している「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」です。プロジェクトを運営する職員の視点に立って、実務的なノウハウや実例、ひな形などを記載した標準ガイドライン参考文書であると示されています¹。

発注側が普段どのような基準でテスト工程を捉えているかは、案件に参画してから初めて分かることが多いものです。けれど、この文書は公開されているため、打診の段階で中身を確かめられます。ここに書かれている項目が、実際の案件で聞かれる問いの土台になっています。

この文書は2025年5月27日に改定されています¹。改定のたびにテストに関する項目が見直されるということは、発注側の関心がそこに向いていることの裏返しでもあります。まず何が変わったのかを、順番に見ていきます。

非機能要件のテスト工程が名指しされた

今回の改定でまず目を引くのは、「非機能要件のテスト工程を詳細に確認する」という項目が追加されたことです²。画面や機能が動くかどうかだけでなく、性能や安定性といった非機能の面まで、テスト工程として名指しで確認する対象に加わりました。

非機能要件は、成果物の見た目だけを追っていては気づきにくい領域です。だからこそ文書として明記し、案件の中で確認する工程を持たせる形にしたと読み取れます。機能テストだけを見ていればよい案件は、これから限られていく方向にあります。

出典：デジタル・ガバメント推進標準ガイドライン 実践ガイドブック（デジタル庁、2025年5月27日改定）をもとに作成

この改定を知っているかどうかで、打診の場での振る舞いは変わります。非機能要件のテスト工程がどこまで含まれるのかを、案件の説明を聞いた側から尋ねられる場面と、尋ねられてから慌てて答える場面とでは、その後の進み方がまるで違います。

案件の打診を受けた時点で「非機能要件のテストをどこまで担当するか」を確かめておくことが、後工程で慌てない備えになります。次に、テストの方針をどう決めるかを見ていきます。

2. 方針は「リスクと重要度」で決める

重要度の記載が増えた意味

「リスクを踏まえてテストの方針を決める」という項目には、重要度に関する記載が追加されています³。すべての機能を同じ深さで確認するという発想ではなく、リスクの高い部分から重点を置くという考え方の裏づけです。

重要度で線を引くという読み方は、テストを手薄にしてよいという意味ではありません。全体を均一に塗りつぶすより、濃淡をつける設計のほうが、限られた時間の中では機能します。むしろ、どこに力を注ぐかを発注側とすり合わせる材料が増えたということです。

この項目が案件の打診段階で見えていると、どこに重点を置くつもりかを早い段階で尋ねられます。あとから「思っていたテストの深さと違う」となるより、最初にすり合わせておくほうが、双方にとって進めやすくなります。

打診の場で確かめる問い

打診の場で交わす言葉は、抽象的な「品質を担保できますか」ではなく、具体的な問いに変えたほうが伝わります。重要度に応じて濃淡をつけるという考え方を踏まえると、確かめておきたい観点はいくつかに絞られます。下の表は、そのうち着手前にすり合わせておきたい問いを整理したものです。案件によって答えは変わりますが、問いの型そのものは共通して使えます。

観点	打診の場で確かめる問い
テストの重点	どの機能をリスクが高いと位置づけているか
深さの基準	重要度によって確認の深さをどう変える想定か
対象の範囲	非機能要件のうち、どこまでを工程に含めるか
合意の時期	テストの方針をいつまでに固める想定か

表に挙げた問いは、どれも「何を、どのくらいの深さで見るか」という一点に集約されます。リスクの高い機能から重点を置くという考え方さえ共有できていれば、個々の項目は案件ごとに形を変えても構いません。

この4つの問いを打診の段階で尋ねられるようになると、契約後に「思っていたより深いテストを求められた」という食い違いを避けやすくなります。逆に、何も尋ねずに引き受けると、着手後にリスクの捉え方のずれに気づいて、スケジュールを組み直す場面が増えます。

次の章では、この重要度の話とセットで追加された、役割分担と環境の項目を見ていきます。

3. 役割分担と環境が、先に決まる

誰が何を持つかが先に決まる

「テストにおける役割分担と必要な環境を明確にする」という項目には、疎通確認やテストを実施する優先度や重要度に関する記載が加わりました⁴。役割分担と環境の準備は、テストの中身を決める前段階として扱われています。

役割分担が先に決まるということは、着手してから「誰がこの確認を担当するのか」を探る場面が減るということでもあります。発注側とテストを担当する側のどちらが、どの確認に責任を持つかが、案件の早い段階で言葉になります。

環境についても同じ扱いです。テストに必要な環境がいつ、どちらの手で用意されるかは、スケジュールを左右する要素です。ここが後回しになると、テスト自体の着手がつまずきやすくなります。

環境の用意も同じ扱いになった

優先度や重要度の記載が加わったということは、役割分担と環境の準備にも濃淡をつける発想が持ち込まれたことを意味します⁴。すべての確認を同じ手順で並べるのではなく、重要な確認から環境を整えるという順序が生まれます。

この順序を知っていると、案件の打診段階で「環境の用意はどちらが担当するか」「優先して整える確認は何か」を尋ねる材料になります。曖昧なまま進めるより、役割と環境を先に言葉にしておくほうが、参画後の手戻りを抑えられます。

実際の打診の場では、役割分担の話は「どこまで対応できますか」という聞き方で来ることが多いものです。ここで環境の用意まで含めて確認しておくと、着手後に想定していた環境が整っていない、という足止めを避けやすくなります。

出典：デジタル・ガバメント推進標準ガイドライン 実践ガイドブック（デジタル庁、2025年5月27日改定）をもとに作成

役割分担と環境が先に決まる、という流れが見えたところで、次は案件の中心にある自動化の扱いを見ていきます。

4. 自動化は両面で扱われている

メリットとデメリットが両面で置かれている

「テストツールを有効活用する」という項目には、自動テストを導入するメリット・デメリットの参考が追加されました⁵。ここで大事なのは、メリットだけでなくデメリットも並べて置かれているという構成そのものです。

自動化を進めれば課題がすべて解決する、というほど単純な話ではありません⁵。この文書がメリットとデメリットの両方を参考として示している以上、自動化は無条件によいものではなく、案件ごとに向き不向きを判断する対象として扱われています。中身の具体的な内容はこの記事では確認していないため、ここでは触れません。

メリットだけを語るより、デメリットとあわせて判断した経緯を語るほうが、両面を理解して選んだことが伝わります。「自動化しました」だけでなく、「どこを自動化し、どこは手動に残したか」という判断の跡を残せると、経験に厚みが出ます。

自動化の経験を語るときに、メリットだけを並べる場合と、デメリットも含めて判断の経緯を語る場合とでは、伝わり方が変わります。両面を踏まえて選んだ経緯を語れると、実際の案件でどう向き合ってきたかが伝わりやすくなります。

結果の確認方法も明記される

あわせて、「テスト結果の確認方法を明記する」という項目も追加されています⁷。自動テストを入れるかどうかだけでなく、結果をどう確認し、誰が見るかまでが、案件の中で言葉にする対象になっています。

確認方法が明記される対象になったということは、テストを実行して終わりではなく、その結果をどう扱うかまでが仕事の範囲に含まれるということです。ここを曖昧にしたまま自動化だけを進めると、確認方法をめぐって後から調整が発生しやすくなります。

図の作成：Remogu編集部。実践ガイドブックの記載を踏まえて整理したもので、メリット・デメリットの具体的な内容を示すものではありません

自動化を持ち込む前に合わせる項目

メリットとデメリットの両面が置かれているという前提に立つと、自動化を案件に持ち込む前に決めておきたい項目が見えてきます。下の表は、対象範囲・評価軸・結果の確認・手動との分担という4点を、着手前に合わせておく項目として整理したものです。案件ごとに答えは変わりますが、確かめる項目そのものは共通して使えます。

観点	確かめておく事項
対象範囲	どの工程・どの機能を自動化の対象にするか
評価軸	メリットとデメリットのどちらを重く見るか
結果の確認	結果を誰が、どのように確認するか
手動との分担	自動化しない部分をどう担当するか

この4点を打診の段階ですり合わせておくと、着手後に「自動化の範囲がずれていた」という手戻りを避けやすくなります。証跡についても同じ考え方が広がっているので、次の章で見ていきます。

5. 証跡は「対象を事前に合意する」

エビデンスは事前合意の対象

「取得するテストエビデンスの対象を事前に合意する」という項目が新たに追加されました⁶。エビデンスをどこまで取得するかは、案件が始まってから決めることではなく、着手前に合意しておく対象として明文化されています。

事前に合意するという言葉が明文で置かれた意味は小さくありません。エビデンスを求められて手が止まる、という不安は、対象が曖昧なまま進んでしまうことから生まれます。先に合意できていれば、あとから範囲を広げられて困る場面を抑えられます。

エビデンスの対象を事前に合意できている案件と、そうでない案件とでは、テストの終盤にかかる負担が変わります。対象が決まっていれば取得する証跡を見通せますが、決まっていなければ範囲が後から広がりやすくなります。

どこまでのエビデンスが必要かは案件によって異なります。この文書が示しているのは分量ではなく、「対象を事前に合意する」という進め方そのものです⁶。

品質を見える形にする、という締め

改定では、「見えない品質を見える状態にする」という項目の記載内容が、ソフトウェアの品質管理及びプロセス改善に関する内容に修正されています⁸。品質を見える形にすることが、テストの仕事の締めくくりとして位置づけられていると読み取れます。

あわせて、事例・参考の一覧には「アジャイル開発におけるテスト」「テストの目的と業務シナリオを明確にする」が挙げられています⁹。目的とシナリオを先に明確にするという考え方が、この文書全体を貫く姿勢として繰り返し出てきます。

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

エビデンスの対象を事前に合意し、品質を見える形にして締めくくる。この一連の流れを踏まえると、自分がこれまで担当してきたテスト自動化の経験も、同じ順番で言葉にできます。下の表は、対象範囲・判断・確認方法・エビデンスという4つの層に分けて、経験を書き出すための整理です。

層	書き出す内容
対象範囲の層	どの工程・機能を自動化の対象にしたか
判断の層	メリットとデメリットのどちらを重く見て選んだか
確認方法の層	結果をどう確認する仕組みにしたか
エビデンスの層	どのような証跡を、誰と合意して残したか

図の作成：Remogu編集部。経験を整理するための枠組みであり、統計データではありません

4つの層で書き出せると、「自動化しました」で止まっていた経験に厚みが出ます。次の章で、ここまでの内容を振り返ります。

6. まとめ

ここまで見てきたように、テスト自動化の案件で問われているのは、自動化したかどうかという二択ではありません。方針の重要度、役割分担と環境、自動化の両面の判断、エビデンスの対象。この文書が改定のたびに言葉にしてきたのは、決めごとの中身です¹。

これらの項目は、政府情報システムの案件を運営する職員に向けた文書に基づいています¹。とはいえ、着手前に何を合意しておくかという進め方そのものは、他の案件でも参考にできる考え方です。

方針の重要度、役割分担と環境、自動化の両面、エビデンスの対象。この4点を打診の段階で確かめられるようになると、契約後に条件のずれに気づいて慌てる場面は減っていきます。逆に、何も確かめずに引き受けると、同じずれに着手後になって向き合うことになります。

自分がこれまで担当してきたテストの経験を、対象範囲・判断・確認方法・エビデンスという4つの層で言葉にできれば、初めて組む相手にも伝わりやすくなります。Remoguは、案件の90%以上がフルリモート可能なリモートワーク案件特化のエンジニアマッチングです¹⁰。まず登録して、自分の経験に合う条件を確かめてみることが、次の一歩になります。

7. よくある質問

自動化していないと評価されないのですか

この文書は自動テストについてメリットとデメリットを参考として示しており、自動化していないことがそのまま評価を下げる、とは示されていません⁵。評価の材料になるのは、自動化するかどうかの判断を、対象範囲や役割分担、確認方法とあわせてどれだけ言葉にできるかという点です。自動化していない場合も、その判断に至った理由を語れれば、同じように材料になります。

エビデンスはどこまで取ればよいのですか

分量について、この文書から確認できることはありません。示されているのは「取得するテストエビデンスの対象を事前に合意する」という進め方です⁶。どこまで取るかは案件ごとに異なるため、着手前に対象をすり合わせておくことが、後から範囲を広げられて困る事態を防ぎます。合意していない状態で進めると、終盤になって証跡の追加を求められ、作業が読みにくくなる場面が増えます。

公共の案件だけの話なのですか

この文書が対象としているのは政府情報システムの案件です¹。他の案件にそのまま当てはまる決まりごとではありませんが、方針の重要度、役割分担と環境、エビデンスの対象を着手前に合意するという進め方は、案件の種類を問わず参考にできる考え方です。打診の場でこの4点を尋ねる側に回れると、案件の種類が変わっても同じ準備が使えます。

テスト自動化の経験は、どう書けば伝わるのですか

「自動化しました」で止めず、対象範囲・判断・確認方法・エビデンスという4つの層に分けて書き出すと伝わりやすくなります。とりわけ、メリットとデメリットのどちらを重く見て選んだかという判断の跡は、経験の厚みとして伝わる部分です。まず登録して、自分の経験がどの案件で活きるかを確かめてみるのも一つの進め方です。

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

出典・参考情報

＊1 デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」概要（2025年5月27日）
＊2 デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」改定履歴（2025年5月27日）（2025年5月27日）
＊3 デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」改定履歴（2025年5月27日）（2025年5月27日）
＊4 デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」改定履歴（2025年5月27日）（2025年5月27日）
＊5 デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」改定履歴（2025年5月27日）／事例・参考の一覧（2025年5月27日）
＊6 デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」改定履歴（2025年5月27日）（2025年5月27日）
＊7 デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」改定履歴（2025年5月27日）（2025年5月27日）
＊8 デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」改定履歴（2025年5月27日）（2025年5月27日）
＊9 デジタル庁「デジタル・ガバメント推進標準ガイドライン 実践ガイドブック」第3編第7章 事例・参考の一覧（2025年5月27日）
＊10 Remoguサイト公開情報（フルリモート可能案件の割合）