探索的テストの外注｜PMが押さえる依頼設計と成果の見極め

複数の受託案件を同時に抱え、テストはエンジニアの兼任で回している。そんな体制では、仕様書に書かれた項目を消化するだけで手一杯になりがちです。

ところが本番で表面化するのは、仕様書のどこにも書かれていない不具合だったりします。画面の組み合わせ、想定外の操作順、データの端の値。定型のテストケースが素通りしてしまう領域です。

こうした「書かれていない穴」を掘るのが探索的テストです。そして、その探索的テストの外注を検討したとき、多くのPMがつまずくのが「成果が見えにくい」という壁です。

「探索的テストの外注は成果が見えにくい」という誤解

「テストケースを何件消化したか」で管理してきたPMほど、探索的テストの委託には戸惑います。渡すケース表がなく、終わったときに手元に残るのがバグ報告と所感だけ。これでは費用対効果を上長に説明できない、と感じるのは自然なことです。

しかし、それは定型テストと同じ物差しで測ろうとするから見えなくなっているだけです。探索的テストは、そもそも測り方が違います。

探索的テストは、James Bach が提唱し、Lee Copeland『はじめて学ぶソフトウェアのテスト技法』でも紹介されるアプローチです。Bach はこれを「テスト設計とテスト実行の同時並行的な学習行為」と定義しました。あらかじめ全ケースを書き出すのではなく、製品を触りながら得た気づきを次のテストに反映していく進め方です。Bach は「次のテストが前のテスト結果に依存するなら、そこには探索的テストの要素がある」とも述べており、この”前の結果が次を決める”という連鎖こそが探索の本質です。

だからこそ、成果は消化件数では表せません。

探索的テストの成果は”バグ件数”ではなく、どこをどう探索し、何に気づいたかで測るものです。これを理解しないまま件数だけを求めると、成果を正しく評価できず、「効果がわからない外注」という誤解が生まれます。

なお、探索的テストの委託とは、この学習型の探索そのものを外部のテスト専門家に委ね、社内では「何を探索してほしいか（狙い）」の設計と「何に気づいたか（成果）」の評価を担う分担のことです。ケース表を丸ごと渡す定型テストの委託とは、役割の分け方が根本的に異なります。

本記事は、この誤解を解いたうえで、探索的テストの委託を成果につなげるための判断材料を整理します。扱う範囲は次の3点に絞ります。

• 委託の判断（そもそも外に出すべきか、どの案件が向くか）
• 依頼の設計（何をどう渡せば表面的な確認で終わらないか）
• 成果の見極め（納品物の質をどう評価するか）

一方で、探索の具体的な操作手順や技法そのものの実施方法には踏み込みません。それは委託先の専門領域であり、PMが押さえるべきは「依頼する側の設計と評価」だからです。

そもそも探索的テストの外注はできるのか｜向く案件・向かない案件

「外部の熟練テスターに探索を任せられるのか」という問いに、結論から言えば、できます。ただし、どの案件でも一律に効くわけではありません。

まず、探索的テストを外注する効果を整理します。

• 仕様書にない不具合を掘れる: 定型ケースが素通りする組み合わせや操作順の穴を突けます
• 属人的なスキルを外から借りられる: 探索には観察力と仮説構築力が要り、社内で育てにくい能力です
• 兼任で回らない現実を補える: 熟練したテスト担当が社内にいない、いても手が回らない状況を埋められます

外注が効くのは、社内に”探索できる人”がいない時ほどです。裏を返せば、探索の勘所を持つ人材が社内で確保できるなら、無理に外へ出す必然性は薄れます。

では、どんな案件が向き、どんな案件は慎重に判断すべきか。目安を表にまとめます。

案件の状況	外注の向き不向き	理由
仕様が曖昧・変更が多い	向く	事前に全ケースを固定できず、探索の学習が効く
社内に探索できる人材がいない	向く	属人的スキルを外から補える
兼任で手が回らず穴が出ている	向く	リソースと観点の両方を補完できる
ドメインが極端に特殊で前提知識が重い	慎重に	情報格差を埋める設計に相応の工数が要る
機密性が高く外部に情報を出しにくい	慎重に	探索に必要な背景を渡せないと成果が出ない
監査証跡や網羅率の証明が要る領域	慎重に	探索の記録は定性的で、厳密なカバレッジ証明には向かない
仕様が単純で定型ケースで尽きる	慎重に	探索の余地が小さく、定型テストで足りる

「慎重に」は「外注できない」ではありません。情報共有の設計や契約形態の工夫でカバーできる余地があります。ただし、監査対応で「どの条件を何％網羅したか」を数値で証明する必要がある領域だけは、性質上、探索的テストの守備範囲外だと割り切るのが安全です。逆に、その設計を省いて出すと、次に述べる「丸投げの失敗」に直結します。

スクリプト（定型）テストの外注との違い

探索的テストの委託を難しく感じる原因の多くは、定型テストの外注と同じ感覚で進めてしまう点にあります。両者は渡すものも測り方も違います。

まず違いを表で整理します。

観点	定型（スクリプト）テストの外注	探索的テストの外注
渡すもの	テストケース・手順書	探索の狙い・対象範囲・リスク仮説
範囲の明確さ	事前に確定できる	実行しながら絞り込む
依頼の難易度	ケースがあれば比較的容易	狙いと背景の共有設計が要る
成果の測り方	消化件数・合否	発見欠陥の質・気づき・カバー領域
向く場面	仕様が固まり回帰確認が中心	仕様が曖昧・想定外の穴を掘りたい

この違いを一言で言えばこうです。

定型は”ケースを渡す”、探索的は”狙いを渡す”。渡すものが違えば測り方も変わる。

大切なのは、両者は対立するものではないという点です。Copeland も、スクリプトテストと探索的テストを二者択一ではなく道具箱の使い分けとして位置づけています。目の前の課題に応じて、意味のある道具を選べばよいという考え方です。

実務では、2つを組み合わせて発注するのが現実的です。

• 定型テストで土台を固める: 仕様どおり動くか、回帰で壊れていないかを網羅的に確認する
• 探索的テストで穴を掘る: 定型が触れない組み合わせや想定外の操作を掘り下げる

土台を定型で押さえたうえで、限られた時間を探索に振り向ける。この組み合わせが、兼任体制で穴が出やすい受託開発とは特に相性が良い進め方です。

発注の順序も意識しておくと効果的です。先に定型テストで既知の仕様どおりの動作を固め、そのうえで探索に入ると、探索担当は「ここは確認済み」という前提から出発できます。すでに潰れている項目に時間を使わずに済むため、限られた探索の時間を、まだ誰も踏み込んでいない組み合わせや境界条件に集中させられます。逆に、探索を先に単独で回すと、定型で拾えるはずの初歩的な不具合に探索の時間を食われ、本来の”書かれていない穴”にたどり着く前に予算が尽きるということが起こりがちです。

探索的テストを委託すべきか判断する軸

外注が「できる」ことと「今この案件で委託すべき」ことは別です。判断を後押しする条件と、立ち止まるべき条件を分けて見ていきます。

委託を後押しする条件は次のとおりです。

• 社内に探索の勘所を持つ人がおらず、育てる時間もない
• リリース直前に定型消化で手一杯になり、探索まで手が回らない
• 過去に本番で「書かれていない不具合」が出てクライアント信頼を損ねた
• 仕様変更が多く、事前にケースを固定しきれない

一方、立ち止まるべき条件もあります。

• 委託先に背景を共有する窓口や時間を、社内側が用意できない
• ドメインが特殊すぎて、前提説明だけで膨大な工数がかかる
• 機密上、探索に必要な情報を外部に出せない

ここで見落としがちなのが、窓口の問題です。窓口を用意できないなら、外注そのものより先に情報共有の設計を考えるべきです。共有する相手がいない状態で丸投げしても、表面的な確認で終わります。

また、判断は「全部を外に出すか、内製で抱えるか」の二択にする必要はありません。内製と組み合わせる発想が有効です。

• 仕様の背景を最も知る社内メンバーが探索の起点となる観点を出す
• そのうえで、手が足りない領域や社内の視点が届かない領域を外部に委ねる

迷ったときは、後押しする条件と立ち止まるべき条件のどちらが多く当てはまるかを数えてみてください。後押し条件が優勢で、かつ窓口を用意できるなら、委託を前向きに進めてよい案件です。逆に、立ち止まる条件、とりわけ窓口が用意できない・機密上情報を出せないという条件が一つでも強く効くなら、その状態のまま出すのは危険です。まず社内側の準備を整えてから発注に進むほうが、結局は早道になります。

内製と外注のどちらが自社にとって得かを整理したい場合は、テストの内製と外注を比較した判断の物差しもあわせて参考にしてください。全部を外に出す前提を一度崩すことで、委託範囲がむしろ明確になります。

丸投げが失敗を生む理由と、依頼設計のしかた

ここが本記事の背骨です。探索的テストの外注で成果が出るかどうかは、依頼設計でほぼ決まります。

なぜ丸投げが失敗するのか。探索的テストは「製品を理解しながら穴を探す」活動である以上、対象への理解が浅いままでは深い探索になりません。定型テストなら手順書どおりに動かせば一定の成果が出ますが、探索は違います。

問題になるのが情報格差です。あるBtoBアプリのテスト代行の振り返りでは、開始時にアプリの全体像を掴めていなかったために、本来1回の操作で済む確認に余計な時間がかかった、という声が出ています。

内製開発と違い、外部の委託先には開発の経緯・裏仕様・設計思想が自然には伝わりません。この情報格差を埋めるフェーズを意図的に設計しないと、探索は表面的な動作確認で止まってしまいます。

同じ振り返りでは、一見遠回りに見える「全体像の把握」に最初に時間を投資したほうが、トータルの作業時間はむしろ短縮されるという教訓も得られています。急がば回れ、というわけです。

だからこそ、依頼設計の起点はここに置くべきです。

探索的テストの外注は、全体像・裏仕様の情報格差を埋めるフェーズを設計して初めて成果が出る。この設計を省くと、丸投げは”時間を買っただけ”で終わることになります。

その意味で、依頼先に求めたいのは「一緒に情報格差を埋めてくれる相手」です。背景を渡せばそれを咀嚼し、不明点を質問で返してくる。そうした伴走型の姿勢がある相手を選ぶことが、探索の委託では一般的な選定基準になります。

テストチャーターで探索の狙いを渡す

具体的に何を渡すのか。中心になるのがテストチャーターです。チャーターとは、探索の狙いを短くまとめた「探索の指針」で、全ケースを書き出すものではありません。チャーターに書くとよい要素は次のとおりです。

• 探索の狙い: 何を確かめたいのか（例: 決済まわりの異常系の耐性）
• 対象範囲: どの機能・画面を探索するか、どこは対象外か
• リスク仮説: どこが壊れやすいと考えているか、過去に問題が出た領域
• 優先領域: 限られた時間をどこに厚く配分してほしいか
• 時間ボックス: 1セッションあたりの目安時間（区切って進める）

チャーターは最初から完璧に作り込む必要はありません。着手のハードルは低く、最初は狙いと対象範囲を書いた簡易版1〜2枚で十分です。むしろ、社内が持つ懸念を外注先に渡し、外注先の質問を受けて共同でドラフトを詰めるほうが、情報格差も同時に埋まります。運用しながら精度を上げていけば、準備過多で着手が遅れる事態は避けられます。

セッションベースで探索の進捗を可視化する

チャーターと合わせて共有したいのが、セッションベースの進め方です。探索をタイムボックスで区切り、各セッションで「何を狙い、何を触り、何に気づいたか」を記録し、終わりにデブリーフィング（振り返り共有）で確認する。この「タイムボックス＋セッションレポート＋デブリーフィング」を管理単位にする考え方は、SBTM（セッションベースドテストマネジメント）として体系化された確立手法です。

この単位で進めてもらうと、探索という一見つかみどころのない活動が、セッション単位の進捗として可視化されます。外注で最も不安な「今どこまで進んだのか」が見えるようになるのは、大きな利点です。

優先順位の共有も欠かせません。テスト項目を並べるだけでなく、重要度・リスク・確認のしやすさで順位づけするところまでが、実はテスト設計の一部です。ここを委託先任せにせず、社内側の懸念を優先領域として渡すことで、限られた時間が効くところに集中します。

依頼前の段取りをより体系的に整えたい場合は、テスト代行を依頼する前の準備の段取り5観点も参考になります。情報共有フェーズの設計は、丸投げを避ける最初の一歩です。

探索的テストの外注で成果を見極める

依頼を設計したら、次は納品された成果をどう評価するかです。ここでもバグ件数は探索の質を表さず、何をどこまで探索し、何に気づいたかを見ることが軸になります。

件数だけで評価すると、浅い場所で拾った軽微な不具合が多い報告のほうが「成果が大きい」と見えてしまいます。それは探索的テストの価値を取り違えた評価です。見るべき観点は次のとおりです。

• 発見欠陥の質: 重大度は高いか、見つけにくい不具合か、仕様の隙間を突いたものか
• カバー領域の可視化: どこを探索し、逆にどこには時間を割けなかったか
• デブリーフィングの中身: 気づき・懸念・仮説が言語化され、次の一手につながるか
• 再現性: 発見した不具合が、手順と環境つきで再現できる形で報告されているか

ここで注意したいのが、カバー領域の読み方です。探索的テストのカバレッジは”触れた機能・観点のマップ”という定性的なものであり、C0/C1のような定量的なコードカバレッジ値とは別物です。「どの画面・どの観点に触れ、どこは未着手か」が地図として示されていれば十分で、数値化されていないことを欠点と見なす必要はありません。

特にデブリーフィングは、探索的テストの成果が最も現れる場です。バグ一覧だけでなく、「ここは怪しいがまだ掘り切れていない」「この操作系は仕様の意図が読み取れなかった」といった懸念や仮説が出てくるかを見てください。こうした「まだ確信は持てないが気になる」という報告は、一見すると成果として数えにくいものです。しかし、そこにこそ次のリリースで顕在化しかねないリスクの芽が隠れています。懸念を拾い上げ、次の探索や修正の優先度に反映できるかどうかが、外注を単発の作業で終わらせず、品質を底上げする継続的な取り組みに変えられるかの分かれ目です。件数の多い報告よりも、深い懸念が一つ書かれた報告のほうが価値が高い、という感覚を持っておくと評価を誤りません。

そして、この成果評価はPMの負荷を過度に増やすものではありません。評価に必要なのは、デブリーフィングへの短時間の同席と、チャーター単位のレポート確認程度で足ります。全ケースをレビューする定型テストの検収と違い、セッションの区切りごとに「狙いに沿えたか・何に気づいたか」を対話で確認すれば足りるため、片手間の兼任でも回せる粒度です。

判断の目安として、成果評価のチェック表を用意しました。

見極めの観点	良い成果の兆候	注意すべき兆候
発見欠陥の質	重大・見つけにくい不具合が含まれる	軽微・表層的なものに偏る
カバー領域	触れた範囲と未着手範囲が地図で示される	どこを見たか不明で件数だけ
デブリーフィング	気づき・懸念・仮説が言語化される	合否や件数の報告に留まる
再現性	手順・環境つきで再現できる	「たまに出る」で終わり追えない
仕様との関係	仕様の隙間・矛盾を指摘できる	仕様どおりかの確認に留まる

こうした観点で評価する姿勢は、探索的テストが場当たり的な操作とは違う、規律ある活動であることの裏返しでもあります。品質確保を体系的に捉える視点は、IPA（情報処理推進機構）のような公的機関が示すソフトウェア品質の考え方（IPA）とも通じるものです。

成果を継続的に高めるには、委託先との連携そのものを設計することも有効です。テスト代行との連携で品質を保つコツもあわせて確認すると、評価と改善のサイクルが回しやすくなります。

準委任契約で”探索力”のある依頼先を選ぶ

成果の評価軸がわかっても、そもそも探索力の低い相手に依頼すれば良い成果は出ません。契約前に見極めておきたいのが、委託先の探索力です。

探索的テストは、注意不足で焦点の定まらない場当たり的テストとは明確に区別される、スキルと経験を要する規律ある活動です。この点は JSTQB（JSTQB）が整理するテスト知識体系でも、探索的テストが体系立った活動として位置づけられていることからもうかがえます。だからこそ、相手の力量が成果を大きく左右します。

契約前に確かめたいサインは、大きく3つです。

• 観点の広さ: 機能だけでなく、データ・状態・タイミング・異常系まで視野に入るか
• 仮説力: 「ここが壊れやすい」と根拠を持って狙いを立てられるか
• 報告の質: 気づきや懸念を、判断に使える形で言語化できるか

これらを見るために、契約前に次のような点を聞いてみるとよいでしょう。

• 過去にどんな探索でどんな不具合を見つけたか、具体例を語れるか
• 情報が足りないとき、どんな質問を返してくるか
• 探索の狙いをどう記録し、どう報告する運用か
• 定型テストと探索的テストをどう使い分けているか

探索の考え方を自分の言葉で語れる相手は、丸投げでなく一緒に格差を埋めてくれる可能性が高いと言えます。逆に、件数や合否の話に終始する相手は、探索の価値を提供しにくいかもしれません。

契約形態の相性も見ておきましょう。探索的テストは、成果物を事前に確定できず、探索の対象や優先領域を都度再設計しながら進める活動です。そのため、成果物の完成と契約不適合責任を負う請負より、善管注意義務のもとで業務の遂行を約束する準委任のほうが馴染みます。狙いに沿って探索を進め、その過程と気づきを評価する働き方は、準委任の考え方と合致するわけです。

なお、準委任で外注先に情報を渡す際は、指揮命令ではなく「情報提供と狙いの共有」にとどめるのが原則です。日々の作業指示で相手の裁量を奪う進め方は偽装請負と見なされかねないため、渡すのはあくまでチャーターと背景情報にします。契約形態の選び方の詳細はテスト外注の準委任と請負の選び方と判断軸で整理しているので、契約の詰めはそちらに委ねます。

見積もり時に確認すべき費用の単位

上長を説得するうえで避けて通れないのが費用感です。とはいえ探索的テストは成果物を固定しない性質上、定型テストのような「1ケースいくら」の単純な相場では測りにくく、金額だけを先に決め打ちすると実態と合いません。大切なのは、金額そのものより何が費用の単位になっているかを見積もり時に必ず確認することです。

確認しておきたい単位は、主に次のとおりです。

• 稼働の単位: 準委任なら人日・人月など、何をもって稼働をカウントするのか
• セッションの単位: 週あたり何セッション、1セッション何時間で進めるのか
• 最小発注の目安: 最低何日・何セッションから受けてもらえるのか
• 含まれる成果物: セッションレポート・デブリーフィング・不具合報告のどこまでが標準に含まれるか
• 追加が発生する条件: 情報格差を埋める初期フェーズや再テストが別費用になるか

これらの単位が揃えば、同じ土俵で複数社を比較でき、社内で「なぜこの費用なのか」を説明する材料も揃います。逆に単位が曖昧なまま金額だけを比べると、安く見えた見積もりが最小発注や追加条件で膨らむ、といった食い違いが起きがちです。相場を鵜呑みにするのではなく、単位を揃えて比較する。これが費用対効果の議論を地に足のついたものにします。

複数社から見積もりを取るときは、こちらから渡す前提条件を揃えておくのも有効です。同じチャーター、同じ対象範囲、同じ期間を各社に提示すれば、返ってくる見積もりの差が「単価の差」なのか「想定している稼働量の差」なのかを切り分けられます。前提を揃えずに金額だけを並べると、各社が別々の範囲を想定した見積もりを比べることになり、比較が成り立ちません。発注側が土俵を用意することが、公平な比較の前提になります。

もう一つ、見積もり段階で握っておきたいのが、初回の情報共有フェーズをどう扱うかです。前段で述べたとおり、全体像や裏仕様の格差を埋める工程を省くと探索は浅くなります。この工程を「準備だから無償で」と暗黙に期待すると、委託先はコストを回収できず、結果として説明の粒度が下がったり、格差を埋めきらないまま探索に入ったりします。むしろ初期のキャッチアップを正式な稼働として見積もりに含め、そのぶん本番の探索が短縮される前提で全体を組むほうが、トータルの費用対効果は高くなります。安さではなく、どこに時間を使うと成果に効くかで見積もりを読むことが、費用の議論では欠かせません。

まとめ｜探索的テストの外注を成果につなげるために

探索的テストの外注は、「成果が見えにくい」という誤解さえ解けば、兼任体制の穴を埋める有効な選択肢になります。最後に、判断から見極めまでの流れをおさらいします。

• 判断: 社内に探索できる人がいない案件ほど効く。全部外注せず内製と組み合わせる
• 依頼設計: 全体像・裏仕様の情報格差を埋めるフェーズを設計する。チャーターで狙い・範囲・時間ボックスを渡す
• 成果の見極め: 件数でなく、欠陥の質・カバー領域・デブリーフィング・再現性で評価する
• 依頼先選び: 観点の広さ・仮説力・報告の質を契約前に確かめ、準委任の相性も見る
• 費用の確認: 金額の相場より、稼働・セッション・最小発注などの”単位”を見積もり時に揃える

上長を費用対効果で説得するときは、この価値を言語化するのが近道です。探索的テストは、本番で表面化する前に見えない品質リスクを前倒しで検知し、定型テストが取りこぼす観点の抜け漏れを補完します。前段で整理した費用の単位と組み合わせれば、本番バグによる手戻りやクライアント信頼の毀損を、事前の把握できるコストで抑える投資だと説明でき、稟議は通りやすくなります。

そして、月曜から始められる最小の一歩は決して重くありません。まずは自社案件のどこに「書かれていない穴」が出やすいかを棚卸しし、簡易版のチャーター1枚に「探索してほしい狙いと対象範囲」を書き出す。そこから始めれば十分です。テスト体制の見直しを具体的に進めたい方は、テスト体制の見直しを相談するところからでも、次の一手が見えてくるはずです。