反復開発の中で、探索的テストを どう実施しているか Teppei YAMAGUCHI @ Scrum Fest Niigata 2026 

自己紹介： Teppei YAMAGUCHI © LayerX Inc. 自己紹介 株式会社 LayerX 所属 兼 個人事業主 テスター、コーチ、コンサルタント、プログラマー プロダクトのテスト実践に関わりつつ、組織横断の自動テスト 環境や品質可視化も整備 出版 『ソフトウェアテストをカイゼンする 50 のアイデア』 『Fearless Change』 コミュニティワーク Regional Scrum Gathering Tokyo 実行委員 SQiP 研究会 分科会 4「アジャイルと品質」アドバイザー テスト自動化研究会 お世話係 2 / 20 

今日お話しすること © LayerX Inc. 1〜2 週イテレーションの Web サービス開発チームでの実践例を紹介する 理論の完全版ではなく、イテレーションの中でどう回しているか に絞る 主題は次の 3 点 探索的テストを、テスト設計の不足を埋めるためではなく、不確実さに向き合う実践として位置づけること 探索的テストの対象を、リスクと不明点の大きさで見極めること イテレーションの中に組み込み、学びと改善につなげること 3 / 20 

探索的テストが「ふわっと」しやすい理由 | *1 テスト対象の探索を、観光地を巡るツアーに例え、そのメタファーに基づいて探索する方法。参考：上手な探索的テストとその上達方法について © LayerX Inc. 探索的テストは価値があると広く認識されている しかし現場では、次のような曖昧さが起きやすい イテレーションのどこで実施するのか分からない テストケースで確認する範囲との境界が曖昧 「ツアー を知っている」がどれを使ったら良いのか分からない その結果 時間があるときにやる 得られた気づきがチームに還元されにくい 雰囲気で終わる 4 / 20 

先に結論 © LayerX Inc. 私たちのチームでは、探索的テストを テスト設計の不足を埋めるためのもの とは捉え ていません まず一般的なテスト技法で、確認したいことをある程度は明確にする そのうえで、次のような対象に探索的テストを使う リスクが高いが、まだ未知や不明点が多い部分 実装中に「ここは理解が薄い」と感じた部分 操作しながら理解を深めないと見えにくい部分 つまり、未知や理解不足に対処するための実践 として使っている 5 / 20 

テスト設計と探索的テストを どう使い分けるか 

テスト分析・設計でおこなっていること © LayerX Inc. 要求や仕様、変更点、過去障害、利用文脈から確認観点を出す 必要に応じて次のような技法を使う 同値分割、境界値分析 デシジョンテーブル 状態遷移 ユースケース / 業務フロー その結果、次の 2 つに分かれる テストケースとして確認できる部分 まだ未知や不明点が残る部分 7 / 20 

テストケースと探索的テストの使い分け © LayerX Inc. 主にテストケースで確認するもの 期待結果を事前に明確に書ける 回帰で繰り返し確認したい 説明責任や合意形成が重要 主に探索的テストで確認するもの 試しながら理解を深める必要がある 今回の変更特有の不確実さが大きい 気づきの獲得とリスクの発見が重要 どちらが上位ではなく、役割が異なる。どちらもおこなう。 8 / 20 

探索的テストをおこなう対象の決め方 © LayerX Inc. テスト分析・設計の後で、次の問いを使って対象候補を出す ここにバグがあったときのリスクや影響範囲が大きいか？ 仕様・挙動・利用状況の理解がまだ浅いか？ 変更が複数箇所にまたがっていて予測しにくいか？ 実装者やレビューアが「ちょっと不安」と感じているか？ 候補が複数ある場合は、リスクと不明点の多さで優先する 9 / 20 

よく探索的テストの対象になるもの © LayerX Inc. 新しい業務フローや、初めて扱う複雑な仕様 権限、通知、並行操作、時刻、入力の組み合わせが絡む部分 UI は成立しているが、操作のつながりや違和感が気になる部分 外部サービス連携や、失敗時の復旧導線 10 / 20 

イテレーション中にどう組み込むか 

イテレーションの中で実施するタイミング © LayerX Inc. PR 作成後 何をするか：実装者以外も含めて探索する 狙い：実装者の不安を潰す。実装者視点の偏りを減らす リリース前 何をするか：重要・リスクの高い変更だけまとめて探索する 狙い：他の PR や環境違いなどの見落としを減らす 12 / 20 

実際の進め方 © LayerX Inc. 1 セッションは 30〜60 分程度に区切ることが多い セッション開始前に最低限だけ決める 対象 今回の狙い 気にするリスク 必要なら、オススメのツアーや触り方を決める 実施中は次をメモする 何を試したか バグ、改善できると良さそうな点 終了後に、バグや改善点の共有、それらの対応可否などを話し合う 13 / 20 

例：機能把握に自信がなく、高リスクな部分を変更するとき © LayerX Inc. 例：利用者の権限を細かく設定できる機能を新規で開発する テスト設計で担当者が分かる範囲での網羅的な項目は書けたが、不安が残った 権限の波及範囲 権限を組み合わせた場合の挙動 このときにおこなったこと テスト設計で作成した網羅的な項目に基づくテスト実施 次に 60 分の探索的テスト時間を確保して、チーム全員を招待して、探索的テストを皆で実施 発見内容から、バグの修正や弱そうなところの再テスト項目の検討 14 / 20 

探索の進め方の補助として、ツアーをどう使うか © LayerX Inc. ツアーは「探索的テストそのもの」ではなく、視点を与える補助輪と考えている そのため、私はツアー名ではなく、使う意図で説明することが多い 例えば以下のように説明して、ツアーを使ってもらっている 「初めて触る人に説明するつもりで基本動線を見てもらえませんか？」 「こんな条件めったにないと思うモノから見てもらえませんか？」 「せっかちな人の気分で触ってもらえませんか？」 「優柔不断だったり、ミスしやすい人の気分で触ってもらえませんか？」 毎回ツアーを使うわけではありません 狙いや不安が明確なら、普通にそれらに対する仮説ベースで進める 15 / 20 

「雰囲気で終わらせない」ためにおこなうこと © LayerX Inc. セッションごとに、最低でも次を残す 対象 狙い 試した・確認したこと 見つかったこと 加えて、見つかったことの共有や議論をおこなう 共有や議論をおこなうことで、チーム全員の理解向上や以降のバグ発見につながる 16 / 20 

探索的テストが機能しているかをどう見るか © LayerX Inc. 実施の有無ではなく、次の変化があるかを見る セッション中に参加者のテスト対象に対する理解が深まっているか 「何となく不安」が言語化され、その不安が減っているか 仕様理解の増加や設計の改善につながる 逆に危ないサイン チームの一部の人だけがやる 何を見たか残らない 見つけたことが次の改善につながらない 17 / 20 

まとめ 

明日からどう始めるか 探索的テストは、ふわっと実施するものではなく、テスト設計で捉えきれない不確実さに向き合い、チーム の学びを増やし、不安の解消や次の設計やテストにつなぐための実践 © LayerX Inc. 30 分でよいので、何かの機能を対象に、狙いを決めたセッションを入れる ツアーは暗記しなくてよく、視点が欲しいときに参考にする 各自の探索が終わったら、チーム全体での共有や議論を必ずおこなう 19 / 20 

ご清聴ありがとうございました を、みなさんの現場でも具体化するきっかけになれば嬉しいです © LayerX Inc. 探索的テストを、テスト設計の不足を埋めるためではなく、不確実さに向き合う実践と してどう位置づけるか 探索的テストの対象を、リスクと不明点の大きさでどう見極めるか イテレーションの中でどう回し、学びにつなげるか 20 / 20