カテゴリPの位置づけ——変更を確かめる関所
前のカテゴリOでは、変更を安全に運ぶための道を整えてきました。ここからのカテゴリPは、その道の関所にあたります。運んできた変更が、そもそも良いものなのかを確かめる章です。バイブコーディングでは、コードを書くのはAIですが、その出力が業務で使えるかを見極めるのは人間の仕事です。テストは、そのAIの出力を受け取ってよいかを判断する検収装置になります。
このスライドのポイント
- カテゴリOで「変更を安全に運ぶ道」を整えた
- カテゴリPは、その道の関所——「その変更は良いものか」を確かめる章
- バイブコーディングでは、テストがAIの出力の検収装置になる
- まず、確かめる物差しである「品質」を定義する
品質の定義——6観点の束
品質とは、「動くかどうか」という一本の物差しではなく、複数の観点の束です。この講座では6つの観点でとらえます。要件充足は、M-05やM-09で決めた条件を満たしているか。正確性は、計算やデータが正しいか。使いやすさは、H章で見た操作のしやすさ。安全性は、A-09やJ-06で触れた守りができているか。速度は待たされずに動くか、保守性は後から直しやすいかです。M-06で決めた非機能要件が、ここで確かめる対象として戻ってきます。
このスライドのポイント
- 品質＝「動くかどうか」の一軸ではなく、6つの観点の束
なぜ6観点が要るのか
この6つを知らないと、「動きました」という一言を完成の合図として受け取ってしまいます。しかし、動くが遅い、動くが危険、動くが直せない、という状態は、どれも動いてはいます。一軸だけで評価すると、これらをすべて見逃します。AIは指示された範囲を「動く」ところまでは作りますが、6観点まで自発的に確かめてはくれません。だからこそ、確かめる物差しを人間が持っておく必要があります。
このスライドのポイント
- 6観点を知らないと「動きました」＝完成という一軸評価になる
- 見逃すもの: 動くが遅い／動くが危険／動くが直せない
- AIは「動く」ところまでは作るが、6観点を自発的には確かめない
- だから、確かめる物差しを人間が持っておく必要がある
6観点の構造——確かめる問いの一覧
構造として、6観点を1枚の表で並べます。各観点に「確かめる問い」と「関連する既出講義」を添えると、どこで学んだ内容がどの観点につながるかが見えます。ここで大切なのは、すべての観点を最高水準で満たす必要はない、という点です。どの観点をどこまで求めるかは、M-06で決めた水準しだいです。社内で数人が使うツールと、多数の利用者が使うサービスとでは、求める速度も安全性の重さも変わります。
このスライドのポイント
- 6観点を1枚の表で並べ、「確かめる問い」と「関連する既出講義」を添える
具体例——「申請機能が動く」を6観点で再点検
具体例として、経費アプリの申請機能を見てみましょう。申請ボタンを押すと保存される、ところまでは確かに動いています。しかし6観点で点検し直すと、確認済みは要件充足と使いやすさくらいで、残る4観点は未確認でした。正確性では消費税の端数処理は正しいか、安全性では他人の申請が見えてしまわないか、速度では件数が増えても待たされないか、保守性では後から承認ルールを変えやすいか。「動く」の裏に、確かめていない観点が並んでいます。
このスライドのポイント
- 経費アプリの「申請機能が動く」を6観点で点検し直す
- 確認済みは要件充足と使いやすさの2つ、残る4観点は未確認だった
技術サンプル——品質6観点の点検表
スライドの表は、この6観点の点検表を実際に埋めた記入例です。種別は表、目的は1つの機能を6観点で自己点検することです。観点ごとに確認結果と根拠の欄を設け、未確認の欄を「未」のまま残すのがコツです。その「未」がそのまま、これから確かめるべき宿題の一覧になります。AIへの質問はこうです。「この機能を品質6観点で自己評価してください。未確認の観点はどれですか」。
このスライドのポイント
- 種別: table
- 目的: 1つの機能を品質6観点で自己点検し、未確認の観点を可視化する
- サンプル本体（経費アプリ申請機能の記入例）:
混同しやすい概念——「動く」と「品質が高い」
混同しやすいのは、「動く」と「品質が高い」の違いです。動くことは、あくまで最低条件です。品質が高いとは、6観点で確認を済ませた状態を指します。デモの画面で一度動いて見えることと、業務で毎日使えることの間には、大きな距離があります。この距離を埋める作業が、これから学ぶテストの全体像です。
バイブコーディングでの確認点
確認の習慣として、AIの「できました」には、必ず「どの観点まで確認済みですか」と返しましょう。この一言だけで、AIは自分の出力の確認範囲を言語化せざるを得なくなります。テストは、AIの出力を受け取ってよいかを判断する検収装置です。以降の講義では、この確認を、具体的な道具へと形にしていきます。今は、確かめる物差しを持ったことが成果です。
このスライドのポイント
- AIの「できました」には「どの観点まで確認済みですか」を返す習慣をつける
- この一言で、AIは自分の出力の確認範囲を言語化せざるを得なくなる
- テストは、AIの出力を受け取ってよいかを判断する検収装置
- AIへの質問例: 「この変更は、品質6観点のうちどこまで確認しましたか」
まとめと一問一答
最後に一問一答です。品質の6観点は何でしょうか。（間）答えは、要件充足・正確性・使いやすさ・安全性・速度・保守性の6つです。30秒でまとめます。品質は「動くか」の一軸ではなく、6観点の束でした。動くは最低条件にすぎず、6観点で確かめて初めて品質が高いと言えます。テストは、その確認を担う検収装置です。次回は、不具合を見つける活動と、原因を特定して直す活動の違いを整理します。関連資料は「AIアプリの品質評価シート」と「テスト観点プロンプト50」です。
このスライドのポイント
- 一問一答: 「品質の6観点は？」→ 要件充足・正確性・使いやすさ・安全性・速度・保守性
- 30秒まとめ: 品質は「動くか」の一軸ではなく6観点の束。動くは最低条件で、6観点で確かめて初めて品質が高いと言える。テストはその確認を担う検収装置
- 次回: 見つける活動（テスト）と直す活動（デバッグ）の区別へ
- 関連資料: 「AIアプリの品質評価シート」「テスト観点プロンプト50」
