8月28日に『Explore It! プロダクトの価値と自信を高める探索的テスト実践ガイド』（エリザベス・ヘンドリクソン著、スクラムフェス新潟訳、ZEN大学出版会）が発売されます。訳者のひとりとして、この本の中身を紹介します。
テストの本ですが、プロダクトマネージャーやプロダクトオーナー、つまり要件を定義する人にこそ読んでほしい一冊です。AIがコードを書く時代に求められているのは、コーディング技術ではなく、プロダクトのふるまいを探索し、驚きを発見する探検家。本書は、ソフトウェアを未知の大地に見立てて踏み込む、その技術を教えてくれます。プログラミングの知識がなくても読めるように書かれています。
テスト＝チェック＋探索
本書の序盤に、著者ヘンドリクソンの同僚のこんなため息が出てきます。机の上に積まれた厚さ1インチのテストケースの山を指して——「どれだけたくさんのテストを書いても、どれだけたくさんのテストケースを消化しても、一番深刻なバグが見つかるのは決まって手順書から外れた操作をしたときなのよ」。
心当たりのある人は多いのではないでしょうか。データ、構成、相互作用、タイミングのバリエーションは無限にあり、すべてを事前のテストケースでカバーすることは論理的に不可能です。だから本書は、テスト戦略が答えるべき質問を2つに分けます。「ソフトウェアは、想定される条件のもとで意図した通りに動作しますか？」——これは事前に設計したテストでチェックできます。「その他のリスクはありますか？」——こちらに答えるのが探索です。両方やって、はじめて「テスト完了」。
つまり、ソフトウェアは「お願いしたとおりにできている」ことのチェックだけでは足りず、「おかしなことが起きていない」ことの探索が必要なのです。解説を寄せてくださった和田卓人さんは、この「テスト＝チェック＋探索」という整理を「既知を既知にピン留めするのがチェックであり、未知を既知に持ってくるのが探索である」と読み解いています。探索が未知を切り開き、自動テストがそれをピン留めして、既知の陣地が広がっていく。探索的テストは自動テストと対立するものではなく、両輪なのです。
第I部 基礎の確立（第1〜5章）——探索を「設計された実験」にする
第1章の冒頭に登場するのは、初期のコンピューターENIACの逸話です。ネズミがケーブルをかじるリスクに対して、開発チームは推測で議論する代わりに、飢えたネズミに候補のケーブルを与えてみました。結果、ネズミの好むケーブルは採用を見送られます。テストの本質は「リスクに関する質問に答えるための経験的証拠を集める実験を設計すること」——本書を貫く定義です。
探索を方向づける道具が「チャーター」です。モデルは、ジェファーソン大統領が探検家ルイスとクラークに与えた大陸横断の指令。「どこを探索するか（ターゲット）」「何を使うか（リソース）」「どんな情報を発見したいか」の3要素で、探索のミッションを短い一文にします。チャーターの種は、要件、ステークホルダーからの質問、既存の成果物から拾えます。プロダクトの最悪の事態がニュースの見出しになる想像からリスクを洗い出す「悪夢の見出しゲーム」というチームワークショップも紹介されます。
続く章では、探検家の基礎体力を鍛えます。観察の章のタイトルは「ところで、ムーンウォークする熊を見ましたか？」。人間は注意を向けたものしか見えない——だからこそ意識的に視点を変え続け、コンソールやログも使って「見えないものを見えるようにする」技術が要ります。バリエーションの章では、揺さぶるべき「変数」の見つけ方を学びます。サイズ、深さ、タイミング、相対的位置……。Therac-25の放射線事故やアリアン5の爆発を招いたのは、まさにこうした「とらえにくい変数」でした。そして評価の章では、仕様書に書いていなくても「これはおかしい」と判断するための基準——「決して〜ない／常に〜する」というNever/Alwaysルール、内部一貫性、標準規格との比較——が示されます。
第II部 次元を追加する（第6〜9章）——「次に何を試すか」を系統的に生み出す
探索が行き詰まるのは、たいてい「次に何を試せばいいか」が尽きたときです。第II部は、プロダクトを分析する軸を4つ追加して、試すべきバリエーションを系統的に生み出せるようにします。
ひとつめは手順と相互作用。画面の名詞と動詞を組み合わせ、ランダムな操作を混ぜ、ペルソナになりきって「その人ならやりそうなこと」を徹底的にやってみる。ふたつめはエンティティと関係性。プロダクトが扱うモノを洗い出し、それぞれをCRUD（作成・読み取り・更新・削除）で攻め、データの流れを追いかける。みっつめは状態遷移。状態とイベントのモデルを描くと、「この状態でこのイベントが起きたら何が起こる？」の答えを誰も知らないセルが「???」として浮かび上がります。ここが驚きを発見する絶好の機会です。よっつめはエコシステム。システムを取り巻く依存関係を図にして信頼境界を見つけたら、探検家の仕事はその信頼をあえて裏切ってみることです。
第III部 文脈に沿って考える（第10〜13章）——現場に持ち帰る
第III部は、身につけたスキルを現場の文脈に合わせて使う方法です。UIのないAPIやWebサービス、プログラミング言語そのものも探索できます。ドキュメントも仕様書もない既存システムは、まず偵察セッションで全体を把握し、発見を記録・共有しながら正体を突き止めていきます。「恐怖の再現不可能なバグ」を、エビデンス収集と変数のブレインストーミングと状態モデルで追い詰める方法も、この部にあります。
私が特に推したいのは第12章「要件の探索」です。探索の対象はソフトウェアだけではありません。要件定義の会議で「What If?（もしも？）」を投げかけ、関係者どうしの思い込みのギャップを実装前に発見する。仕様書を鵜呑みにせず、疑問を投げかけ、モデルを描きながら読む「アクティブリーディング」。要件を定義する人にこそ読んでほしいと言った理由が、この章にあります。
最終章は、探索をチームの日常に統合する方法です。早く、頻繁に探索する。探索の工数を確保し、見積もり、いつ終えるかを判断し、ステークホルダーに報告する。専任の探検家を置くチームも、全員で探索するチームも、探索を「後付け」ではなく第一級の活動として扱う——それが本書の結論です。
付録と解説
付録は2本。探索的テストのスキルを見極める採用面接の方法と、現場でそのまま使える「テストヒューリスティック・チートシート」です。各章末には演習も付いています。
そして日本語版には、和田卓人さんによる解説「『Explore It!』: 才能から技術へ」を収録しました。「バグの臭いがするんだよ」としか説明してくれなかった伝説のテストエンジニアの思い出から始まり、才能だと思われがちな探索を再現可能な技術に還元する本書の価値を語っています。才能はスケールしませんが、技術はスケールします。
この本ができるまで
本書の翻訳は、スクラムフェス新潟の有志によるオンライン読書会から始まりました。機械翻訳の原稿を手掛かりに一章ずつ読み進めていたところ、翻訳権は取得済みなのに翻訳が止まっていると知り、それなら読書会の続きを出版まで持っていこう——と動き出したのがこの本です。実務者が実務者のために書いた本を、現場の実務者たちが自らの手で翻訳しました。『実践アジャイルテスト』のジャネット・グレゴリーは本書を「テスターだけでなく、開発チーム全員の机に置かれるべき本」と評しています。
原題の副題は「リスクを減らし、自信を高める」ですが、日本語版では「プロダクトの価値と自信を高める」としました。探索的テストは防御的な活動ではなく、プロダクトについてまだ誰も知らない情報を発見し、チームの意思決定を支える価値創造の活動だからです。
指示に書かれていない暗黙の期待は、AIがコードを書く時代にはますます伝わりません。今こそ、探索的テストを。
『Explore It! プロダクトの価値と自信を高める探索的テスト実践ガイド』 エリザベス・ヘンドリクソン著／スクラムフェス新潟訳／ZEN大学出版会（発売：KADOKAWA） https://www.kadokawa.co.jp/product/302607002898/
