私たちはなんでテストするんだっけ? Ver.Scrum Matsuri 2026

Have you lot ever actually stopped to think about why we test in product development? in Scrum Matsuri 2026.

Transcript

1. 私たちは なんで テストするんだっけ ？ あらためてテストの意味を考える Scrum Matsuri 2026 おおひら ゆうすけ
2. から来ました
3. おおひら ゆうすけ • ただ（そこにいるだけ）のテスター • 好きなスクラムイベント スプリントレビュー • 好きな本 闘うプログラマー • 好きなプロトコル LDAP
4. イントロダクション
5. コーディングをAIに任せる 人間がコードを読まない・介入しない時代になりつつある • プロンプト → ハーネス → ループ • AIの出力を環境（テスト・ドキュメント・ツール）で制御する • エージェントを自律的に回し続ける • 複数エージェントを協調させる
6. テストが重要？ テストは「信頼」を担保する装置 • Robert C. Martin（Uncle Bob）のポスト https://x.com/unclebobmartin/status/2080257779395154409
7. テストが重要？ テストは「信頼」を担保する装置 • "My current strategy is to not read any of the code written by my agents.” AIエージェントが書いたコードは、もう読まない。代わりにユニ ットテスト、エージェントを厳格な制約で取り囲む、Gherkinテ スト、QA手順、品質メトリクス、ミューテーションテスト、カ バレッジ など。すべての関門を通過するからこそ、生成されたコ fi ードに very high con dence（非常に高い信頼） を持てる
8. その「テスト」は何を指しているのか？ • 多くの場合、それは「正しく動いているか」の確認を指している • もちろんそれは大事。でも、テストの意味はそれだけ？ あらためてテスト活動の意味を考えませんか
9. 私たちは なんでテストするんだっけ？
10. 本日のながれ 目次 1. テストの基本概念 テストの目的／V&V／チェッキングとテスティングテストオラ クル問題／ホリスティックテスト／アジャイルテスト4象限／品 質ナラティブ 2. AIエンジニアリングとテスト 3. 自分たちでテストを考えよう 4. まとめ
11. テストの基本概念
12. テストの目的 ISTQB CTFL v4.0 より • 要件、ユーザーストーリー、設計、コードなどの作業成果物を評価する • 故障を引き起こし、欠陥を発見する • テスト対象の必要なカバレッジを確保する • ソフトウェア品質が不十分な場合のリスクレベルを下げる • 指定された要件が満たされているかを検証する • テスト対象が契約上、法的、規制上の要件に準拠していることを検証する • ステークホルダーに情報を提供し、根拠ある判断をしてもらう • テスト対象が完成し、ステークホルダーの期待どおりに動作するかを妥当性確 認する • テスト対象の品質に対する信頼を積み上げる
13. Veri cation & Validation 成果物の正しさを2つの視点で確認する考え方 • Veri cation（検証）: ｢仕様｣通りか • 出力が「入力（仕様・前工程の要求）」通りに正しく作れているか • Validation（妥当性確認）: 「ユーザーの要求」通りか • 出力が「もともとのユーザーの要求」に合っているか • Barry Boehmの説明 • Veri cation = Are we building the product right? （正しく作っているか） • Validation = Are we building the right product? （正しいものを作っているか） fi fi fi 出典: B. Boehm (1979) V&Vガイドライン論文 / ISTQB CTFL Syllabus v4.0
14. チェッキングとテスティング テスト活動の「性質」を分ける考え方 • 「テスト」には性質の違う2つの活動がある Michael Bolton が提起（2009）、James Bach と共に精緻化 （2013） • チェッキング（checking）: 期待結果が決まっていることを 確認 する • 「Aを入れたらBが返る」合否を機械的に判定できる。自動化しやすい • テスティング（testing）: まだ分からないことを 探索 し情報を得る • 「問題はないか？」と問う。人の知恵と判断が要る ※この線引きは絶対ではなく、良いチェッキングにも知恵が要るという議 論もある（Dinwiddie, Kaner ほか）
15. ホリスティック･テスト テスト活動は特定のフェーズではなく全フェーズで行われる • Janet Gregory & Lisa Crispin 提唱 • DevOpsループの各アクティビティにテストをマッピングする 探索→計画→理解→ビルド→デプロイ→リリース→観察→学び • ホリスティック=「全体観」 • チーム全体・製品組織・顧客まで含めて品質を考える。 • 始まりも終わりもない
16. ホリスティック･テスト テスト活動は特定のフェーズではなく全フェーズで行われる
17. ループ左側 気づきつなげるテスト • 探索（Discovery） • アイデアの検証。「この問題は解く価値があるか」を問う • 計画（Planning） • リスク特定と品質特性の優先順位付け。受け入れテストの検討を始める • 理解（Understanding） • 実例マッピングやプロトタイプなどで、あいまいな要求を具体例に落とす素早いフ ィードバックを得て、仕様を固める • ビルド（Building） • ユーザーストーリーやフィーチャーを実装し、TDDなどを活用して可能な限り早く テストする • 自動テストがリグレッションスイートになっていく
18. ループ右側 学びにつなげるテスト • デプロイ（Deploying） • 複数環境に展開し、パフォーマンスやセキュリティなど品質特性を検証する • リリース（Releasing） • フィーチャートグルやカナリアリリースなどで段階的にユーザーに届ける • 観察（Observability） • 本番のイベントを記録し、顧客がどう使っているかを観る • エラー監視だけでなく、利用パターンの発見も含む • 学び（Learning） • 観察から仮説を立て、検証する。学びが次の「気づき」に戻る
19. アジャイルテスト4象限 テスト活動を整理するためのフレームワーク Brian Marick 原型 を作りLisa Crispin & Janet Gregory が発展させた ※ 各象限のテスト種類は例
20. アジャイルテスト4象限 テスト活動を整理するためのフレームワーク • 2軸で分類: ビジネス面／技術面 • Q1｜技術 チームを支援／製品を批評 支援: ユニット / コンポーネントテスト • Q2｜ビジネス 支援: 機能・ストーリーテスト / 受け入れテスト • Q3｜ビジネス 批評: 探索的テスト / ユーザビリティ / UAT • Q4｜技術 批評: 性能 / 負荷 / セキュリティ • 使い方 • 自分たちのテストをマッピングし、各テストの目的は何か？偏り や手薄な象限がないかを整理する
21. 3つの品質ナラティブ 品質の語られ方 • 品質ナラティブ • 企業で品質について考えたり話したりしている、その「語られ方」 • （Ronald Cummings-John & Owais Peer『LEADING QUALITY』より） • 3つのナラティブがある • ① 責任ナラティブ（The Ownership Narrative） • 誰が品質に責任を持つかが語られている • ② テストナラティブ（The "How to Test" Narrative） • 品質向上につながる 正しいテスト技法・ツールはどれか が語られている • ③ 価値ナラティブ（The Value Narrative） • 品質に投資した場合の 見返り（ROI） が語られている • 品質・テストについて話すとき、それが3つのどのナラティブの話なのかを意識すると議論がか み合いやすい
22. AIコーディングとテスト
23. AIコーディングで語られる「テスト」とは何か テストの考え方で整理する • 品質ナラティブ • 主に テストナラティブ（どう・どのツールでテストするか） • V&V • 主に Veri cation（仕様どおりに作れているか） • チェッキング/テスティング • 主に チェッキング（既知の期待結果との照合） • ホリスティック/4象限 • 主に ビルド段階のQ1（技術 支援） が中心 • なぜこう偏るのか？ fi • 正解がある領域はテストが作りやすく自動化しやすい
24. テストオラクル問題 生成AIは「プロダクトとして何が価値か」､｢何を作るべきか｣は判断しにくい • テストオラクル • ある入力に対する 正しい出力（期待結果）を教えてくれる情報源 • テストの基本構造は、実際の出力を、オラクル（期待結果）と照らし合わせること • テストオラクル問題 • その「正しい出力」を判定すること自体が難しいという問題 • オラクルが はっきりある 領域と、あいまいな 領域がある: • はっきりある例: 「入力Aなら出力はB」。仕様書・期待値・既存テストで判定できる （Veri cation寄り） • あいまいな例: 「この機能はユーザーにとって価値があるか」。正解が一つに定まら fi ない（Validation寄り）
25. AIコードディングで手薄なところ 傾向として手薄になりやすいのは オラクルがあいまいな「何を作るべきか」 • 品質ナラティブで言えば → 価値ナラティブ • V&Vで言えば → Validation • チェッキング/テスティングで言えば → テスティング • ホリスティック/4象限で言えば → ループ左側（気づき・理解）と 右側後半（観察・学び）、Q3（探索的テスト） ※ あくまで傾向。顧客の利用データからAIが価値を分析するなど、 あいまいな部分でAIを活用する例もある → 自チームの状況で考える
26. 自分たちでテストを考えよう
27. 私たちでテストを組み立てる テストアーキテクチャを考える • 自分たちをやっているテストを整理して組み立てる 参考：テストを導くためのテストアーキテクチャの組み立て方 https://speakerdeck.com/goyoki/cetam
28. 私たちのテストを見つめ直す ホリスティックテストやアジャイルテストの4象限で手薄な部分を整理する 事例 • 顧客理解が浅い→顧客の声を聞く • 気づき・理解（Q2・Q3）：何が価値かを顧客から知る • 仕様の共通認識があわない→具体例で合意を作る • 計画・理解（Q2）：あいまいな仕様を言語化する • 想定外が漏れる→探索的テスト • ビルド（Q3）：作ったものから想定外を見つける • 仮説を確かめたい→本番でのテスト • 学び（Q3・Q4）：段階リリースで本番で仮説を確かめる • 顧客の利用状況が見えない→オブザーバビリティ強化 • 観察（Q4）：本番で実際どう使われているかを観る
29. 事例:顧客の声を聞く 何が価値かを顧客から探る • 課題 • 「何を作るべきか」の判断基準が、チームの中だけでは分からない • 方法 • ユーザーインタビュー、利用観察、フィードバック収集 • 多くの人は「テスト」と思っていないが、「正しいものを作ってい るか」のオラクルを顧客から手に入れる活動 • AIはコードを生成できるが、「これがユーザーにとって価値がある か」というオラクルは持っていない。顧客から得るのは人の仕事 • 顧客の声を聞く活動を、テスト活動として位置づけ直してみる
30. 事例:具体例で認識を合わせる あいまいな仕様を言語化する • 課題 • 抽象的な要件だけではチームの認識がずれる（仕様があいまい） • 方法 • 開発前に、PO・開発者・テスターで具体例を出し合う場を作る • Speci cation by Example（SbE） • 具体的な例で仕様を定義 • 合意した具体例は、そのまま受け入れテストの判定基準になる • 他にも合意を形式仕様（機械が検査できる形）で書き、Alloy fi Analyzerで検査可能にする（AIが記述を支援できる）
31. 事例:想定外を見つける 全員で探索する • 課題 • 決めた手順で確認するだけでは、想定していない問題は見つからない • 方法 • 探索的テスト • テスト設計・実行・学習を同時並行で進める。チャーターで「何を・ なぜ・どう探索するか」を短く定義 • コード生産が速くなるほど、作ったものから学ぶ活動の価値が増す。 • AIにチャーターの壁打ちを頼めば、テストの発想や切り口も広がる • チェッキングでは見つかりにくい問題を発見する
32. 事例:仮説を確かめたい 本番でテストする • 課題 • 早期に仮説を確かめたいが､リリースの影響が大きい • 方法 • 本番でのテスト（Testing in Production） • カナリアリリース（一部ユーザーに先行）／フィーチャートグル（公開タイ ミングを切り替え） • 実際のユーザーに対して、本番で仮説を確かめる（Katrina Clokie『A Practical Guide to Testing in DevOps』） • 段階的にリリースして、リスクを抑えながら本番で学ぶ • 重要な機能を、一部ユーザーへの段階リリースで出してみる
33. 事例:どう使われているか知りたい オブザーバビリティの強化 • 課題 • 「作って終わり」だと、本番で意図どおり価値が届いているか分からない • 方法 • プロダクトの利用状況を本番で計測し、観察する • 顧客がどの機能をどう使っているか。使われていない機能はないか。想定 と違う使い方はないか • V&Vの軸で見れば、これは Validation（要求に合っているか）を本番の事 実で問う活動 • 顧客の利用データからAIを活用が価値を分析することもできる • 「使われ方」を観る計測を1つ入れてみる
34. まとめ
35. 自分たちのテストを考える 「私たちはなんでテストするんだっけ？」を自分たちの文脈で問い直すことが出発点 • いろいろなテストの考え方 • V&V／チェッキング・テスティング／ホリスティック／4象限 ／品質ナラティブ／オラクル問題 • これらは自分たちのテストを見つめ直すレンズ • 4象限の中身も手薄になりやすい側も、あくまで例・あくまで 傾向。当てはまるかは自分たち次第 • レンズを当てて問い直すと自分たちの手薄なところが見えてくる • チーム､状況によって違う
36. AIコーディングとテストオラクル問題 生成AIは私たちのテストに2つの変化をもたらした • ① チェッキングから解放してくれる • ハーネスエンジニアリング等で、チェッキング（答え合わせ）が開発プロセスに組 み込みやすくなった • コード生産はAIが自律的に動き、人が監視する形（human on the loop）へ → Veri cationは加速する • ② テスティングの幅を広げてくれる • Vibe Codingのツールで、テストの試行が速くなる • AIが壁打ち相手になり、テストの発想・切り口を広げてくれる • テストオラクル問題 • AIはオラクルがはっきりしているのが得意 fi • オラクルがはっきりしていないところは人の力がまだ必要
37. 自分たちが作るものに向き合う • ｢プロダクトとして何が価値か」､｢何を作るべきか｣ • 正解がないチェッキングが難しい部分はテスティングで確かめる • 「何を作るべきか」､｢何が価値か｣をテストする
38. 私たちはなんで テストするんだっけ？
39. この問いを自分たちの チームで考えてみてください
40. おわり ご視聴ありがとうござ いました。