前回の続き——見つけた不具合を「直す」入口へ
前回のP-07では、変更のたびに既存のテストを自動で走らせ、過去の機能が壊れていないかを守る回帰テストを学びました。テストは不具合を見つける装置でしたが、見つけた不具合をどう直すかはまだ扱っていません。ここからのP-08は、P-02で区別したデバッグ、つまり原因を特定して直す活動の入口に立ちます。そしてその入口にあたるのが、これから学ぶ再現条件です。
このスライドのポイント
- P-07: 回帰テストで「以前動いていた機能が壊れていないか」を自動で守った
- テストは不具合を「見つける」装置。まだ「直す」は扱っていない
- P-08からはデバッグ（原因の特定と修正）の入口に立つ
- その入口が「再現条件」
定義——再現条件は5点セット
再現条件とは、同じ不具合をもう一度起こすための5点セットです。環境はどの機器やブラウザで起きたか、入力は何を入れたか、手順はどの順で操作したか、期待結果はM-09で決めた受入条件どおりどうなるはずか、実際の結果はA-07で学んだとおりエラーの文言を原文のまま、の5つを揃えます。P-02で分けたデバッグの入口は、この再現にあります。なぜなら、再現しない不具合は原因を特定できず、直せないからです。
このスライドのポイント
- 再現条件＝同じ不具合をもう一度起こすための5点セット
なぜ必要か——「たまに変になる」では直せない
再現条件を揃えないと、報告は「たまに変になる」という一言で止まってしまいます。この状態のままAIに修正を頼むと、どこが悪いか分からないまま、当てずっぽうの変更が積み上がっていきます。しかも、直ったかどうかも確かめられません。もう一度その不具合を起こせないのですから、修正が本当に効いたのかどうかを判断できないのです。だからこそ、直す前にまず再現するのです。
このスライドのポイント
- 再現条件を揃えないと、報告は「たまに変になる」で止まる
- この状態でAIに修正を頼むと、当てずっぽうの変更が積み上がる
- 直ったかどうかも確認できない（もう一度起こせないため）
- 再現できないことが、修正を空回りさせる根本原因
構造——5点セットの報告テンプレートと「たまに」の掘り方
5点セットは、そのまま不具合報告のテンプレートになります。環境・入力・手順・期待結果・実際の結果を上から埋めていくだけで、追いかけるための材料が揃います。厄介なのは「たまに」という言葉です。「たまに」の正体は、多くの場合まだ見つかっていない条件です。処理の順序が絡むならF-04で学んだ非同期の順序を、特定の値のときだけ起きるならデータ依存を、特定の機器でだけ起きるならB-06の環境依存を疑って、条件を掘っていきます。
このスライドのポイント
- 5点セットはそのまま不具合報告のテンプレートになる（上から埋める）
- 「たまに」の正体は、多くの場合まだ見つかっていない条件
- 掘る観点:
具体例——「申請がたまに失敗する」を追い込む
例として「申請がたまに失敗する」を5点セットで追い込んでみます。まず環境を切り分けると、パソコンでは起きず、スマートフォンでだけ起きると分かります。次に入力を変えて試すと、添付した写真が3MBを超えたときに失敗すると判明します。「スマートフォンで写真が3MB超のとき」まで絞れた瞬間、この不具合は「たまに起きる不具合」から「必ず起きる不具合」に変わります。必ず起こせるようになった不具合は、もう直せる不具合です。
このスライドのポイント
- 題材:「経費申請がたまに失敗する」
- 環境で切り分け → パソコンでは起きず、スマートフォンでだけ起きる
- 入力を変えて試す → 添付写真が3MBを超えたときに失敗すると判明
- 「スマートフォンで写真が3MB超のとき」まで絞れた瞬間、必ず起きる不具合に変わる
- 必ず起こせる不具合＝直せる不具合
技術サンプルカード——5点セットの記入例
スライドの表は、先ほどの申請失敗を5点セットで記入した例です。これはA-07で学んだ7つの情報の渡し方と、D-06の切り分け3点セットの報告を、不具合報告向けにまとめ直した集大成にあたります。実際の結果の欄では、エラーの文言を要約せず原文のまま貼るのが要点です。この表をそのままAIに渡せば、AIも同じ土俵で原因を考えられます。AIへの質問例は「この不具合の再現条件を特定するために、私が試すべき操作の組み合わせを提案してください」です。
このスライドのポイント
- 種別: table（再現条件の記入例）
- 目的: 不具合を、そのままAIに渡せる報告に整える
- サンプル本体:
混同しやすい概念——「たまに」と「ランダム」
混同しやすいのが、「たまに起きる」と「ランダムに起きる」の違いです。何の条件もなく本当にでたらめに起きる、いわゆるランダムな不具合は、ほとんど存在しません。「たまに起きる」の裏には、ほぼ必ず、まだ特定できていない条件が隠れています。ですから「ランダムだから仕方ない」と諦めるのではなく、隠れた条件を探しにいく姿勢が正解です。この一歩が、再現への近道になります。
バイブコーディングでの確認点——再現をテストとして保存する
AIに不具合を報告するときは、5点セットを埋めてから渡すことを習慣にしてください。埋まらない欄があること自体が手がかりで、その欄を特定する作業はAIと一緒に進めてかまいません。そして再現できたら、その再現をP-04で学んだテストとして保存します。すると、そのテストはP-07の回帰の網に加わり、同じ不具合の再発を自動で見張ってくれます。再現をテストとして保存すると資産になる——これは、直したはずの不具合が資産に変わる瞬間です。
このスライドのポイント
- AIに不具合を報告するときは、5点セットを埋めてから渡す
- 埋まらない欄があること自体が手がかり。その欄を特定する作業はAIと一緒に進めてよい
- 再現できたら、その再現をP-04の単体テストとして保存する
- 保存したテストはP-07の回帰の網に加わり、再発を自動で見張る
- 再現をテストとして保存すると資産になる——不具合が資産に変わる瞬間
一問一答とまとめ
一問一答です。デバッグの入口は何でしょうか。（間）答えは、再現です。同じ不具合を確実に起こせるようにすること、それがすべての出発点でした。30秒まとめとして、再現条件は環境・入力・手順・期待結果・実際の結果の5点セットであり、再現しない不具合は直せない、を覚えてください。次回は、再現できた不具合の原因を覗くための3つの道具へ進みます。関連資料は「バグ報告テンプレート」と「エラー文の読み方」です。
このスライドのポイント
- 一問一答:「デバッグの入口は？」
- 30秒まとめ: 再現条件＝環境・入力・手順・期待結果・実際の結果の5点セット／「再現しない不具合は直せない」
- 次回: 再現できた不具合の原因を覗く、3つの道具へ
- 関連資料: 「バグ報告テンプレート」「エラー文の読み方」
