実装スプリント5〜品質向上とテスト

• 日程: Day 16 / セッション 2
• 時間: [9:40-12:20]（途中休憩11:00-11:10を含む）
• 形式: 実習
• ゴール: 画面遷移図・機能設計書に基づいて動作確認を行い、発見した不具合を修正できる
• 学習形式: ハンズオン実習、相互レビュー

昨日まででフィードバックの反映が一段落しました。今日は「作る」から少し離れて、「確かめる」に重心を移します。

ここで考えてみてください。
テストのチェックリスト、ゼロから作る必要があるでしょうか？

実は、みなさんはすでに持っています。Day 5〜8で作った設計書です。画面遷移図は「この通りに遷移するか」のチェックリストに、機能設計書の入力チェック欄は「この通りに弾くか」のチェックリストに、そのまま変わります。

今日やることは3つです。

• 設計書をチェックリストにして、正常系を確認する
• 異常系（変な入力・空入力）と境界値を試す
• ペルソナになりきって操作する

テストとは「作ったものが約束通りに動くかを確かめること」です。では「約束」はどこに書いてあるのか。設計書です。

健康診断に例えてみましょう。医師は「なんとなく健康そうか」を眺めるのではなく、検査項目リストに沿って1つずつ数値を確認します。テストも同じで、「なんとなく動いてそう」ではなく、項目リストに沿って1つずつ確認します。

• 「画面遷移図の矢印を1本ずつたどり、その通りに遷移するか確認する」はテストに該当します。約束（設計書）と実物を突き合わせているからです
• 「適当に画面を触って、エラーが出なかったのでOKとする」はテストに該当しません。確認した範囲が記録されず、漏れが分からないからです

設計書からチェックリストへの変換は機械的にできます。

チェックリストの例です。表計算ソフトでもテキストでも構いません。

[遷移] ログイン画面 → ログイン成功 → 一覧画面に遷移する     … OK
[遷移] 一覧画面 → 詳細ボタン → 詳細画面に遷移する           … OK
[入力] 会員登録: メール欄が空のまま登録 → エラーが表示される … NG! 無言で登録された
[表示] 詳細画面: 設計書にある項目がすべて表示されている       … OK

AIに手伝ってもらうと速くできます。

• 「画面遷移図のテキストを貼る。遷移テストのチェックリストに変換して」
• 「機能設計書の入力チェック欄を貼る。確認すべき操作を表形式で列挙して」

• 結果は「OK / NG」を必ず記録する。記録がないテストは、やっていないのと区別がつかない
• NGを見つけたら「どの画面で・何をしたら・何が起きたか」をセットでメモする。再現手順がない報告は直せない
• よくある間違い: 設計書を見ずに記憶でテストする。記憶は「いま動く仕様」に汚染されているので、必ず設計書と突き合わせる

チェックリストの威力を世界に証明したのは飛行機です。1935年、米軍の新型爆撃機B-17は、ベテラン操縦士のテスト飛行で墜落しました。原因は故障ではなく、操作手順の1つの忘れ。「もはや飛行機は人間の記憶力だけで扱える複雑さを超えた」と悟った軍は、世界初の飛行前チェックリストを導入し、B-17はその後180万マイルを無事故で飛びました。この考え方は後に医療にも輸入され、手術前チェックリストは死亡率を大幅に下げています。ソフトウェアも人間の記憶力を超えた複雑さを持つ点では同じ。設計書というチェックリストがあるみなさんは、1935年の操縦士より恵まれています。

正常系の確認だけでは品質は守れません。ユーザは開発者が想定した通りには操作しないからです。

異常系テストとは、わざと「意地悪な操作」をして、システムが壊れずに優しく断れるかを確かめることです。新車の衝突試験のようなものです。ぶつけるためにぶつけるのではなく、ぶつかっても乗員が守られることを確かめるためにぶつけます。

代表的な意地悪は次の通りです。

• 空入力: 必須項目を空のまま送信する
• 過剰入力: 1000文字の名前、巨大な数値を入れる
• 型違い: 数値欄に「abc」、日付欄に「昨日」と入れる
• 連打: 登録ボタンを素早く2回押す（二重登録されないか）
• 順序破り: ブラウザの「戻る」で前の画面に戻ってもう一度送信する

ここで考えてみてください。
「年齢欄に -1 を入れる」と「年齢欄に 200 を入れる」。どちらも試す価値があるのはなぜでしょうか？

どちらも「ありえない値」ですが、弾かれる理由が違うからです。-1は下限の外、200は上限の外。境界値の考え方では、許可される範囲の「ちょうど境目」と「その1つ外側」を必ず試します。

境目の両側を試すことで、チェック漏れを両方向から見つけられます。

AIは意地悪の名人です。テスト観点を出してもらいましょう。

• 「会員登録フォームの項目一覧を貼る。各項目に対する異常系テストの観点（境界値を含む）を表で出して」
• 「『空入力でエラーになること』を確認したら無言で登録された。機能設計書ではエラー表示が約束されている。修正方針を相談したい」

異常系チェックの記録例です。

[異常] 予約日に過去の日付を入力 → エラー表示       … OK
[異常] 数量欄に 0 を入力 → エラー表示              … NG! 0件で予約できてしまう
[異常] 登録ボタンを2回連打 → 1件だけ登録される      … NG! 2件登録された
[境界] 文字数欄に51文字を入力 → エラー表示          … OK
[境界] 文字数欄に50文字を入力 → 登録成功            … OK

• 異常系の「正解」は機能設計書（Day 8）に書いたはず。書いていなければ、いまチームで決めて設計書に追記する
• エラーのときも「ユーザに優しく断る」のが目標。技術的なエラー画面がそのまま出るのは発表でも事故になる
• 直したら昨日学んだデグレード確認を忘れずに。入力チェックの追加は登録処理全体に波及しやすい

テスト技術者の間で愛されているジョークがあります。「QAエンジニアがバーに入る。ビールを1杯注文する。ビールを0杯注文する。ビールを99999999杯注文する。トカゲを注文する。ビールを-1杯注文する。何も注文しない。——そして最初の本物の客が入ってきて、トイレの場所を聞いた。バーは炎上した」。さんざん意地悪な注文を試したのに、誰も想定しなかった操作で壊れる。テストの本質と限界を1つの小話で表した名作です。だからこそ次のトピック、「想定外を見つけるためにユーザの目で操作する」が効いてきます。

チェックリストのテストは「約束通りか」を確かめます。しかし「約束自体が使いにくい」ことは見つけられません。そこで最後の仕上げが、ペルソナになりきった操作です。

Day 3で作ったペルソナを思い出してください。名前、年齢、生活パターン、インターネットの使用状況。その人が、CJM（To-Be版）のシナリオ通りに初めてこの製品を使う場面を演じます。

• 「ペルソナの目的（例: 予約を取る）だけを頭に置いて、説明書なしで最初から操作する」は該当します。ユーザは説明書を読まないからです
• 「開発者がいつもの手順で目的の画面に直行する」は該当しません。それは操作ではなく確認作業だからです

なりきり操作で記録するのは不具合だけではありません。

• 迷った場所（どのボタンか分からず止まった）
• 不安になった場所（押した結果が分からなかった）
• 言葉が通じなかった場所（ペルソナには専門用語だった）

AIにペルソナを演じてもらう方法もあります。

• 「ペルソナのプロフィールを貼る。この人物として、画面の文言『○○を登録』を見たときの感想を言って」
• 「CJM（To-Be版）を貼る。この体験シナリオを、操作手順のテストシナリオに変換して」

記録の例です。

[なりきり] 一覧画面で「どれを押せば予約できるか」3秒迷った
  → ボタンの文言を「選択」から「この時間で予約」に変更したい（チームに提案）
[なりきり] 登録後にトップへ戻され、登録できたのか不安になった
  → 完了メッセージを表示する案をチームで検討
[なりきり] 「会員区分を選択」の意味が分からなかった
  → ペルソナには専門用語。「あなたの種類を選んでください」へ

• 迷い・不安は不具合票と同じ重みで扱う。発表会の聴衆も「初見のユーザ」だから
• 文言の変更は手軽だが立派な品質向上。コードの大改造より効果的なことが多い
• 直すかどうかはチームで合意してから。なりきりで見つけた改善案も「事前に報告して調整」のルール通り

自社製品を社員が日常的に使って問題を見つける文化を「ドッグフーディング（自分のドッグフードを食べる）」と呼びます。語源は1970年代の米国のドッグフードのCMで、宣伝役の俳優が「私は自分の犬にもこれを与えている」と語ったこと。1988年、マイクロソフトの管理職が「我々も自分のドッグフードを食べるべきだ」という件名のメールを送り、開発中の製品を社内で強制的に使わせたのが広まりの始まりとされます。作った本人たちが毎日使えば、ユーザが出会う不便に先に出会える。みなさんのなりきり操作は、22日間でできる最小のドッグフーディングです。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「正常系・異常系・境界値の違いを、身近な例で説明して」
• 「テストで見つけた不具合に優先順位をつける基準は？」
• 「実務のテストには単体テスト・結合テスト・受入テストなどの種類があると聞いた。今日やっているのはどれに近い？」

朝会で決めた分担に従い、テストと修正を行います。

1. チェックリスト作成（9:40-10:00）: 担当機能について、画面遷移図・機能設計書からチェックリストを作る。AIに変換を手伝ってもらってよい
2. テスト前半（10:00-11:00）: 正常系→異常系→境界値の順に確認し、OK/NGを記録する。NGは再現手順つきで不具合リストに集める
3. 休憩（11:00-11:10）
4. 修正と再確認（11:10-12:00）: 不具合リストの優先度の高いものから修正する。修正後はデグレード確認も行う
5. なりきり操作（12:00-12:20）: ペルソナになりきり、CJMのシナリオを最初から通して操作する。迷い・不安も記録する

• テスト済みの機能（チェックリストにOK/NGの記録があるもの）
• 不具合リスト（再現手順・対応状況つき）
• なりきり操作の記録（迷い・不安・専門用語のリスト）
• 更新済みかんばん

• チェックリスト作りに時間をかけすぎないこと。20分で切り上げ、確認に時間を使いましょう
• 不具合が直せないときは、AIに「再現手順・期待する動き・実際の動き」の3点セットで相談すると的確な答えが返ってきます
• 全部は直せません。「発表のデモ導線上の不具合」を最優先に直しましょう
• 修正のたびに「同じデータを使う他の機能」の確認を。昨日のデグレード確認リストがそのまま使えます

今回学んだことを一言でまとめると、**「テストとは、設計書という約束と実物を突き合わせ、意地悪と、なりきりで想定外を炙り出すこと」**です。

• 設計書はそのままチェックリストになる（書いた過去の自分に感謝）
• 異常系は境界の両側を試す（正常系・異常系・境界値の3軸）
• ペルソナの目は、約束自体の使いにくさを見つける

このあとの終会で、残った不具合の優先順位を決めます。次回Day 17は実装最終日。新機能は追加せず、最終仕上げと通し動作確認で「発表で動く製品」に仕上げます。

以下の問いに答えられるか確認してみましょう：

• 設計書のどの文書が、どんなテストのチェックリストになるか対応づけて言えるか
• 異常系テストの観点を3つ以上挙げられるか
• 境界値テストで「-1と200」を両方試す理由を説明できるか
• 「チェックリストのテスト」と「なりきり操作」で見つかるものの違いを説明できるか

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: 自チームで使っている開発ツール・実行環境の公式ドキュメント
• 発展課題: 「テストの自動化とは何か。今日の手動テストのうち自動化できるのはどれか」をAIと議論してみましょう

このセクションは、受講者が理解を深めることをサポートする参考情報です。