■ 1. 背景と問題意識
- ユーザーストーリーにはフォーマットが広く認知されているが、受け入れ基準については「プロダクトオーナーがリリース許可とする判定基準」程度にしか紹介されず、ベストプラクティスが共有されにくい
- プロダクトの種別、リリース頻度、開発チームの練度などによって適切な受け入れ基準は千差万別であり、すべての開発チームに適したフォーマットを紹介するのは非現実的
- その結果、「細かい仕様は開発側でいい感じにしてください」という不十分な受け入れ基準に基づいて開発する運用になっているチームが多い
- 対象読者:
- 「ざっくりしてて開発着手できない」と開発チームに指摘されている方
- 開発中の手戻りが多く、生産性が低いと感じている方
- リリースされたものが想定と違うことが多いと感じている方
■ 2. 不十分な受け入れ基準が引き起こす問題
- 受け入れ基準には仕様をしっかり書くべきというスタンスが主張される
- 不十分な受け入れ基準が引き起こす問題:
- 開発進行中に仕様がツギハギで決まるため、一貫性がなく完成度が低い仕様がリリースされる
- 開発者、プロダクトマネージャー、QA間で認識の齟齬が発生し、スプリントレビューでの差し戻しが増える
- 仕様を記述したドキュメントが残らず、ソースコードを解析しないと仕様が分からなくなる
- これらの問題はチームのモメンタムを少しずつ、確実に低下させる
- 受け入れ基準は少なくともリリースされるまでSSoT（信頼できる唯一の情報源）とすべきであり、開発期間中も継続的にメンテナンスして最新性と正確性を維持すべき
■ 3. 受け入れ基準が満たすべき3つのポイント
- 仕様を具体的に記載する:
- 特に画面上の挙動や表示に関する仕様は可能な限り具体的に記載する
- 具体的であるほど、仕様の解釈や読解に費やす時間が短縮され、開発チームは実装に集中できる
- プロダクトマネージャー自身にとっても、仕様を具体的にイメージする必要が生まれ、仕様の矛盾点や不安点を自ら評価できるようになる利点がある
- 記載内容が複数の解釈をうまない:
- 開発チームは受け入れ基準に書かれている情報以外を知ることができないため、仕様が曖昧だと混乱を招く
- 時間の経過とともに仕様作成者本人も当時のコンテクストを忘れ、異なる解釈をする可能性がある
- 一意に定めるための工夫として、画面上の文言を統一して使用する、箇条書きとインデントで仕様を構造化する、最新の仕様だけを端的に書くといった手法がある
- 影響範囲を網羅的に記載する:
- 新たな要素を追加すると副次的に別の画面も修正が必要になることが多いため、すべての影響範囲を網羅的に記載する
- 実装のヌケモレ防止につながり、実装困難な箇所の発見にも役立つ
■ 4. 受け入れ基準のおすすめフォーマット
- フォーマット構造:
- 要件（機能要件・非機能要件）
- 対象画面
- 対象要素
- 仕様
- （備考）
- 要件:
<ユーザー>は<実施するタスク>できるの形式で記述する- ユーザーストーリーをユーザーが実施するタスク単位で細分化したもの
- ユーザーストーリーは単体でユーザーに価値を提供するが、要件はタスク単位の分割であり単体ではユーザーへの提供価値は向上しない
- ユーザーストーリーが小規模であれば要件の記述は省略可能
- 対象画面:
- 修正対象となる画面名を記載する
- 画面に表示されているH1要素、ヘッダー、パンくずの文言を使用すると認識の齟齬が生まれにくい
- 階層構造の下に位置する場合は親階層の画面名もすべて記載する（例: ユーザー一覧 > ユーザー情報編集）
- 画面を新規作成する場合は末尾に「〜を新規作成」と記載する
- 対象要素:
<要素種別> <要素ラベル>の形式で記載する（要素種別例: 入力項目、表示項目、ボタン、テーブルなど）- 要素ラベルは画面に表示される文言をそのまま使用する
- 要素を新規作成する場合は末尾に「〜を新規作成」と記載する
- 仕様:
- 要素種別ごとに記載すべき挙動の代表例がある
- 要素共通: 表示位置、表示条件
- 入力項目: 入力種別、入力制限、選択肢、初期値、活性・非活性条件、フォーカス時の挙動
- 表示項目: 表示文言、表示スタイル、as-is/to-be
- ボタン: 表示文言、活性・非活性条件、クリック時の挙動（バリデーションロジック・エラー文言含む）
- テーブル: テーブルヘッダー文言、表示要素、ソート順、表示数、ページネーションの有無
- 備考:
- 仕様には含まれないが記述が必要な情報を記載する
- 対象例: 新たな概念や文言の定義、スコープ対象外、仕様や議論の背景、オペレーションの留意点、想定ユースケース
■ 5. FAQ
- 箇条書きとテーブル表記について:
- 作成速度・可搬性・表示密度の観点から箇条書きを採用している
- 箇条書きはキーボードで作業が完結するため仕様作成に集中しやすい
- テーブルは他ツールへのコピペ時にレイアウト崩れが発生しやすく可搬性が低い
- 多くの要素が一行で収まるためテーブルにするとホワイトスペースが多くなり表示密度が下がる
- 詳細な仕様記述と開発チームのモチベーションについて:
- 受け入れ基準の記述はチームで分担できる（例: 要件はPMが書き、対象画面から仕様は開発チームが書く）
- 「実装したほうが早いから受け入れ基準はしっかり書かない」という姿勢は否定される
- 受け入れ基準をしっかり書くことは、リファインメントで開発チームやステークホルダーからフィードバックを受け、仕様を洗練させるための準備と位置づけられる
- 開発チームとの議論が必要なバックログへの適用について:
- 仕様策定を目的とした調査バックログを前工程として作成することで対応できる
- どのような野心的なバックログでも具体的な仕様が決まらなければ実装は不可能であるため、いずれこの粒度の受け入れ基準が必要になる
- 調査バックログの受け入れ基準の例: 適切なアーキテクチャが決まっている、必要とする顧客とユースケースが明らかになっている、開発バックログのリファインメントが完了している