受入条件

前回のストーリーに「合否線」を足す

前回のM-08では、要求を「誰として・何をしたい・なぜなら」の3部で書くユーザーストーリーを学びました。ストーリーは価値の向かう先を固定しますが、それだけでは「どうなれば完成か」という判定線は引けません。この講義では、そのストーリーを満たしたと判断できる条件のリスト、受入条件を扱います。ストーリーが向かう先を決め、受入条件が到達したかどうかを決める、という関係です。

このスライドのポイント

• M-08: 要求を「誰として・何をしたい・なぜなら」の3部で書くユーザーストーリーを学んだ
• ストーリーは価値の方向を固定するが、「どうなれば完成か」の判定線は別に要る
• この講義の役割: ストーリーを満たしたと判断できる条件のリストを作る

受入条件の定義と「観測可能」

受入条件とは、要件やストーリーを満たしたと判断できる、観測可能な条件のリストです。A-07で紹介した「OKと判定できるチェック項目」の正式版にあたります。ここで最も大切なのが観測可能という性質です。観測可能とは、誰がやっても同じ判定になることを指します。「使いやすい」は人によって判定が変わるため条件になりませんが、「3タップ以内で申請が完了する」なら誰が確かめても結果は同じです。受入条件には、正常時だけでなく、A-08で決めた例外、つまり異常時の振る舞いも含めます。

このスライドのポイント

• 受入条件＝要件やストーリーを満たしたと判断できる、観測可能な条件のリスト
• A-07で「OKと判定できるチェック項目」と紹介したものの正式版
• 観測可能＝誰がやっても同じ判定になる（例:「使いやすい」は不可／「3タップ以内で申請完了」は可）
• 正常時だけでなく、A-08で決めた例外（異常時の振る舞い）も条件に含める

なぜ必要か——「これじゃない」の往復を止める

受入条件がないと、完成の基準が人によって変わります。作った側は「できました」と言い、頼んだ側は「これじゃない」と返す。その往復が延々と続きます。特にAIとの協働では、受入条件がそのままAIへの合格ラインになります。A-07で7種類の情報を渡す練習をしたとき、受入条件の欄を埋めた方は、その効き目をすでに体感しているはずです。判定線を先に引いておくことが、無駄なやり直しを防ぎます。

このスライドのポイント

• 受入条件がないと、完成の基準が人により変わり「できました／これじゃない」が往復する
• AIとの協働では、受入条件がそのままAIへの合格ラインになる
• A-07で受入条件の欄を埋めた経験がある人は、その効き目を体感済みのはず

構造——ストーリーから3〜5個へ展開する

受入条件は、1つのストーリーから3個から5個ほどに展開します。目安は、正常の条件を2つ、異常の条件を1つ、そして境界の条件を1つです。境界とは、値がちょうど区切りに乗る場合の振る舞いです。「ちょうど1万円はどちらに入るのか」という問いは、E-05で見た境界の考え方そのものです。境界は抜けやすく、しかも事故が起きやすい場所なので、受入条件に必ず1つ入れる流儀を身につけてください。

このスライドのポイント

• 1つのストーリー → 受入条件3〜5個へ展開
• 目安: 正常2つ・異常1つ・境界1つ
• 境界＝値がちょうど区切りに乗る場合の振る舞い（「ちょうど1万円はどちら？」＝E-05で見た問い）
• 境界は抜けやすく事故が起きやすいので、必ず1つ入れる

具体例——スマホ申請ストーリーの受入条件

前回のスマホ申請のストーリーで具体化します。受入条件はたとえば次の4つです。1つ目、金額と日付と写真を入れて申請でき、一覧に表示される。2つ目、金額が空のままだと送信できず、理由が表示される。3つ目、ちょうど1万円のときは上長の承認に回る。4つ目、通信に失敗しても入力した内容が消えない。1つ目が正常、2つ目が異常、3つ目が境界、4つ目も異常時の振る舞いです。どれも、確認する人が違っても同じ判定になる書き方になっています。

このスライドのポイント

• ストーリー:「申請者として、レシートを撮った瞬間に申請を済ませたい」の受入条件例
• ① 金額・日付・写真で申請でき、一覧に出る（正常）
• ② 金額が空だと送信できず、理由が表示される（異常）
• ③ ちょうど1万円は上長承認になる（境界）
• ④ 通信失敗時は入力内容が消えない（異常）

技術サンプルカード——受入条件の点検表

技術サンプルは、いまの4つの受入条件を表にしたものです。種別は表、目的は受入条件が観測可能かどうかを1件ずつ点検することです。表には、区分と条件、そして観測可能かの自己点検列を設けます。読み方のポイントは2つあります。1つは、区分が正常・異常・境界にわたっていること。もう1つは、右端の列がすべて「可」になっていること、つまり主観的な表現が残っていないことです。AIに条件を作らせたときも、この表の形で観測可能かを点検させてください。

このスライドのポイント

• 種別: table
• 目的: 受入条件が観測可能かを1件ずつ点検する
• サンプル本体:

混同しやすい概念

混同しやすい組を2つ確認します。1つ目は、A-07で見た期待結果と受入条件です。期待結果は「どうなれば正しいか」という方向を示し、受入条件は「OKと判定できる合否線」を示します。方向と合否線は別物です。2つ目は、観測可能な条件と主観的な条件です。「見やすい」「速い」は主観で、人により判定が変わります。「一覧が3秒以内に表示される」は観測可能で、誰が測っても同じです。

このスライドのポイント

• 期待結果（A-07・方向）vs 受入条件（合否線）の再訪
• 観測可能な条件 vs 主観的な条件

バイブコーディングでの確認点

バイブコーディングでの使い方はこうです。AIに実装を頼む前に受入条件を渡し、完成の報告時には「受入条件ごとの合否」を1件ずつ報告させます。この型が、品質の底を支えます。AIへの質問例は次のとおりです。「このストーリーの受入条件を、正常・異常・境界を含む4個から6個で提案してください。観測できない表現があれば直してください」。ここで作った受入条件は、後のカテゴリPで学ぶテストの入口にもなります。

このスライドのポイント

• AIへ実装を依頼する前に受入条件を渡す
• 完成報告時は「受入条件ごとの合否」を1件ずつ報告させる
• この型が品質の底を支え、後のカテゴリPで学ぶテストの入口になる
• AIへの質問例:「このストーリーの受入条件を、正常・異常・境界を含む4〜6個で提案してください。観測できない表現があれば直してください」

まとめと次回

一問一答です。受入条件に必須の性質は何でしょうか。（間）答えは、観測可能であること、つまり誰が確認しても同じ判定になることです。30秒まとめです。受入条件は、ストーリーを満たしたと判断できる観測可能な条件のリストで、正常・異常・境界を含め、AIへの合格ラインになります。次回はカテゴリMの最終回、作る順番と対象外を決める優先順位とスコープへ進みます。関連資料は「テスト観点プロンプト50」と「PRD簡易テンプレート」です。

このスライドのポイント

• 一問一答:「受入条件に必須の性質は？」→ 観測可能（誰が確認しても同じ判定になる）
• 30秒まとめ: 受入条件＝ストーリーを満たしたと判断できる観測可能な条件のリスト。正常・異常・境界を含め、AIへの合格ラインになる
• 次回: カテゴリM最終回、作る順番と対象外を決める優先順位とスコープへ
• 関連資料:「テスト観点プロンプト50」「PRD簡易テンプレート」