今日の問い
その要件が満たされたと、画面を触って誰でも同じように判定できますか。
30秒でつかむ
要件は「検索機能を作る」ではなく、利用者が達成するタスクとして書きます。受入条件は、そのタスクが意図どおり成立したかを判定する、具体的で検証可能な条件です。
実装方法を細かく固定するのではなく、入力、行動、結果、重要な例外を揃えます。
30秒図解 · LESSON 11
流れ図
要望を検証可能な仕事へ変える
利用者の行動と完了条件を分離して書きます。
- 01状況
- 02やりたい仕事
- 03期待する結果
- 04受入条件
CLUE · 見抜く手掛かり
完了を観察できる文になっているか
TRAP · ありがちな罠
画面部品を要件として並べる
原則
「分かりやすい画面にする」という要望は、作り手ごとに解釈が変わります。AIは不足した条件を補って実装できますが、その補完が利用者の状況に合う保証はありません。
Scrum.orgの解説では、受入条件は個別のProduct Backlog Itemが、顧客、ユーザー、ほかのシステムに受け入れられるための条件です。全体へ共通する品質基準とは役割が異なり、その項目固有の期待動作と範囲に焦点を当てます。
まずユーザーのタスクを「状況、行動、達成したい結果」で書きます。次に正常系だけでなく、結果なし、入力不備、処理失敗など、タスクを左右する状態を選びます。各条件は、画面を操作した第三者が合否を判断できる表現にします。
たとえば「教室を検索できる」では足りません。「対象年齢と曜日を選んで検索すると、両条件を満たす教室だけが表示される」「0件なら条件を変える方法が示される」まで書けば、意図と検証がつながります。
受入条件は実装後の採点表ではなく、作る前に認識を揃える契約です。
受入条件を、個別の作業項目が満たすべき期待動作と要件として扱い、共通の品質基準と区別する考え方を支える。
良い例と惜しい例
曖昧な要望と検証できる条件
AIへの指示例
目的: MVPの主要経路を、利用者のタスクと検証可能な受入条件へ変換する
制約: CSSやライブラリ名で実装方法を固定しない。正常系だけで完了扱いにしない
参照: in-out-scope.md、ux-strategy.md、success-criteria.md
受入条件: 各タスクに開始状況、利用者の行動、期待結果を示し、主要タスクには空、入力不備、失敗の条件も含める
確認問題
セルフチェック
1. 受入条件として最も適切な記述はどれですか。
最終制作へ反映する
success-criteria.mdにタスク別の受入条件を加える
MVPの主要タスクを一つ選び、正常、結果なし、入力不備、処理失敗から必要な状態の受入条件を書く。
Acceptance criteria
- 各条件に入力または開始状況、利用者の行動、観察可能な結果がある
- 第三者が画面を操作して、主観に頼らず合否を判定できる
今日のまとめ
- 要件は利用者が達成するタスクとして書く
- 受入条件は個別のタスク固有の期待動作を検証可能にする
- 次は、公開後の成果と悪化を同時に判定する指標を置く