1. はじめに：仕様書だけでは見つけられない“本当のバグ”
「全部テストケースは通っていたのに、ユーザーからバグが上がってきた」
これは、私があるWebシステムの開発で実際に経験したことです。
バグの原因を調査したところ、それは**仕様に明記されていない“期待動作”**を見落としていたことに起因していました。
具体的には：
- フォーム送信後にブラウザバック → 入力内容が残っているのはOK？NG？
- ログイン後、複数タブを開いたときの状態整合性は？
- 同時操作時、サーバー側の整合性は保たれるか？
これらはすべて「探索的テスト（Exploratory Testing）」の出番です。
そして、1人では見落とす視点も、ペアで行えば拾える。
この記事では、探索的テストの中でも特に現場で実践しやすく、**チームの学びと品質を両立できる「ペア探索テスト」**に焦点を当てて解説します。
2. 探索的テストとは？ウォーターフォール型との違い
💡 定義（James Bachによる定義）
“探索的テストとは、学び、設計、実行を同時に行うテストのアプローチである。”
つまり、計画通りに進める従来のテストとは異なり、「試しながら考え、考えながら試す」という反復的な手法です。
📊 比較表：仕様ベーステスト vs 探索的テスト
| 項目 | 仕様ベーステスト | 探索的テスト |
|---|---|---|
| 設計と実行 | 分離（事前に設計） | 同時進行 |
| 柔軟性 | 低 | 高 |
| ドキュメント依存度 | 高い | 低い（仮説思考重視） |
| 不具合検出力 | 明文化された仕様には強い | 未知・曖昧な部分に強い |
| スキル依存 | 低〜中 | 高（好奇心と分析力） |
3. ペア探索テストの進め方：現場の実例をベースに
ここでは、私が実際に関わった**社内申請管理システム（React + Node.js + PostgreSQL）**を題材に、ペア探索テストの実践方法を詳しく紹介します。
🛠 ステップ1：テストチャーターの作成（目標設定）
探索的テストでも「何を、なぜテストするか」は事前に明確にしておく必要があります。
🎯 テストチャーター例：
目的：新しい申請画面において、以下の観点での挙動を確認
・入力データの保存・バリデーション
・承認フローの画面遷移
・モバイル表示時のレイアウト崩れ
制約条件：時間は40分。バグ報告はJiraに登録。
ポイントは、完璧な計画ではなく、行動の「方向性」だけ定めること。
👥 ステップ2：ロール分担（ドライバー／ナビゲーター）
ペア探索テストでは、2人1組で以下のような役割分担をします。
- ドライバー（操作者）：実際にシステムを操作し、動作確認を行う。
- ナビゲーター（観察者）：記録・仮説立案・ツッコミ役を担う。
⏱ 15〜20分ごとにロールチェンジすることで、偏りを防ぎ、多様な視点が得られます。
🔍 ステップ3：セッション中の探索と記録
記録は超重要です。以下のようにログを残していきます。
📄 探索ログ例（Notionを使用）
| 時刻 | 観察 | 仮説 | コメント |
|---|---|---|---|
| 10:12 | データ入力後に自動保存されない | onBlurイベントが無い？ | UX的に不便 |
| 10:20 | スマホ表示時にSubmitボタンが消える | CSSのmedia queryか？ | モバイルUX崩壊 |
| 10:30 | 承認ルート選択後に「戻る」すると選択がクリアされる | stateの保持漏れ？ | 状態管理のバグ可能性あり |
🛠 使用ツール
| 目的 | ツール例 |
|---|---|
| 探索ログ | Notion / Google Sheets / Linear |
| 画面録画 | OBS / Loom / Gyazo GIF |
| バグ登録 | Jira / GitHub Issues / Backlog |
4. 現場で役立つTipsと落とし穴
✅ 実践Tips
- 仮説 → 実験 → 観察 → 修正 のループを意識する
- ペア間の会話を録音 or テキスト化することで後から振り返りやすい
- サーバーログやNetworkタブも積極的に確認する（UIだけでは見えない挙動がある）
⚠️ よくある失敗と対策
| 失敗例 | 対策 |
|---|---|
| テスト目的が曖昧 | 事前にチャーターを作成し、共有 |
| 一人が操作も記録も担当して疲弊 | 役割を分担し、交代を明確に |
| 終了後の成果共有が弱い | デブリーフィングで全体に学びを伝える文化を作る |
5. 応用編：SBTMとペア探索の組み合わせ
🧭 SBTM（Session-Based Test Management）とは？
ペア探索テストをチームや組織で継続的に行うには、「SBTM」の導入がおすすめです。
📦 SBTMの構成要素
- チャーター：目的と対象領域を定義
- セッション：45〜90分程度の実行単位
- ログと記録：学び・発見・仮説を記録
- デブリーフィング：レビューと共有タイム
📌 SBTM向けのツール例
- TestBuddy（無料でも使えるログ支援）
- Xray Exploratory App
- PractiTest（SaaS型QAプラットフォーム）
6. 拡張：探索的テスト×AIの未来
🤖 AIにできること
| 領域 | AI活用例 |
|---|---|
| ログ自動要約 | 会話ログや記録の構造化（ChatGPT, Claudeなど） |
| 異常検知 | テストデータの統計的異常検出 |
| 自動探索 | RPAと組み合わせて画面自動探索・スモークチェック |
🧠 実験アイデア
- ChatGPTをナビゲーター役にする（仮説・質問・検証を支援）
- スクリーン録画から行動ログを生成し、AIに改善提案させる
7. まとめ：探索的テストは「動く仕様書」を育てる文化
✅ 探索的テストの強み
- 計画外のバグやUX課題を発見しやすい
- 開発者・テスター間の理解を深める
- 好奇心とスキルを活かす場になる
⚠️ 難しさ
- テスターの思考力・仮説力が求められる
- 証跡を残す工夫が必要（ツール・ログ活用が鍵）
🚀 チームに広げるには？
- **「やってみよう」ではなく「一緒にやろう」**と誘うこと
- 成果を見える化し、チームの成功体験として記録する
🗣 最後に：次の開発スプリントで、ペア探索やってみませんか？
日々のQA活動に少しだけ余白を設けて、探索的な視点を取り入れてみるだけでも、見える世界は変わります。
探索的テストは、仕様に縛られた開発から、本質に向き合う開発へシフトするための武器になります。