開発チームが喜ぶ「受け入れ基準」の書き方
「受け入れ基準」の粒度って開発チームで結構バラバラ
開発依頼を投げるとき、バックログを起票して、その中にユーザーストーリーと受け入れ条件を書いて開発チームに依頼するフローを取っているところは結構多いと思います。
ユーザーストーリーはフォーマット（<ユーザー>として<達成したいゴール>したい。なぜなら<理由>だからだ。）が広く認知されていますが、受け入れ基準は「プロダクトオーナーがリリース許可とする判定基準」程度にしか紹介されないことがしばしばあり、ベストプラクティスも共有されにくい傾向があると思います。
それも無理はなくて、「何が満たされていればリリースしてよいか？」という問いに対する回答は、プロダクトの種別、リリース頻度、開発チームの練度その他諸々の開発環境によって千差万別です。そのため、すべての開発チームにとって適切な受け入れ基準のフォーマットを紹介するのは非現実的だったりします。
しかし、その結果、開発チームに依頼するときに「細かい仕様は開発側でいい感じにしてください」「詳細は実装しながら決めましょう」前置きをしたうえで、**不十分な受け入れ基準に基づいて開発する運用になっているチームをしばしば見かけます。**特に経験の少ないプロダクトマネージャーや小規模のプロダクトチームにおいて顕著な印象です。
そこで、開発チームが爆速で開発できる受け入れ基準の書き方を共有したいと思います。前述の通り、すべての開発現場で適切な粒度感・フォーマットでは無いと思いますが、8割から9割の現場では開発チームでは喜んでもらえるのではないかと思っています。
この記事は、以下のような悩みを抱えている方に読んでいただけると幸いです
・「ざっくりしてて開発着手できない」 と開発チームに指摘されている方
・開発中の手戻りが多くて、生産性が低いと感じている方
・リリースされたものが想定していたものと違うことが多いと感じている方
「ざっくりこんな感じ、あとはいい感じにお願いします」は大体いい感じにならない
まず初めに私の受け入れ基準に対するスタンスですが、私は、「受け入れ基準には仕様をしっかり書くべき」という立ち位置です。
なぜならば、不十分な受け入れ基準は開発フェーズのいたるところでイヤな問題を引き起こすからです。
例えば以下のような問題です。
・開発進行中に仕様がツギハギのように決まっていくので、一貫性がなく完成度も低い仕様がリリースされる
・開発者、プロダクトマネージャー、QAで認識の齟齬が発生するので、スプリントレビューでの**差し戻しが増える。**プロダクトマネージャーが意図しない仕様でリリースされる
・仕様を記述したドキュメントが残っていないので、**ソースコードを解析しないと仕様がわからない。**その仕様に決まった背景も曖昧。
こういった問題は、非常にストレスフルでチームのモメンタムを少しずつ、確実に低下させます。
そのため、私は受け入れ基準には仕様をしっかり書くべきだと考えています。
付け加えるならば、受け入れ基準は少なくともリリースされるまではSSoT(信頼できる唯一の情報源)とするべきです。そのためには、開発期間中も継続的にメンテナンスし、最新性、正確性を維持し続けるべきです。
受け入れ基準が満たすべき３つのポイント
受け入れ基準には仕様をしっかり書くべきだとお伝えしましたが、では**「しっかり」書かれた仕様**とはどういったものでしょうか？
次の3つのポイントから判断すると良いと思ます。
- 仕様を具体的に記載する
- 記載内容が複数の解釈をうまない
- 影響範囲を網羅的に記載する
仕様を具体的に記載する
特に画面上の挙動や表示に関する仕様は可能な限り具体的に記載すると良いです。具体的であればあるほど、仕様を解釈したり読解する時間が短くなるので、開発チームは実装に集中できます。
このプロセスはプロダクトマネージャー自身にとっても恩恵があります。プロダクトマネージャーはバックログを依頼する前に、仕様を具体的にイメージする必要が生まれるので、イケている仕様かどうか、仕様の矛盾点や不安点を自ら評価ができるようになります。その結果、バックログリファインメントを非常に生産的な場にすることができます。
【❌悪い例】
・ユーザー名のカナを登録できるようにする
→ 🤔どこで？カナはカタカナのみ？半角カナは？【⭕️いい例】
・画面 ユーザー情報詳細 に 入力項目 ユーザー名（カナ） を追加
・必須, 全角カタカナ, 20文字以内
・入力項目 ユーザー名 の下に表示
・以下略…..
記載内容が複数の解釈をうまない
受け入れ基準に記載されている文章が別の意味で解釈されないように表現や単語にしっかりと注意を払いましょう。
仕様を書いたプロダクトマネージャー本人はその仕様に至った試行錯誤、背景がしっかり頭に入っているかもしれませんが、その仕様を受け取る開発チームは受け入れ基準に書かれている情報以外知りようがありません。**仕様が曖昧であれば様々な解釈ができてしまい、混乱してしまいます。
**また、時間が経つにつれ仕様作成者本人も当時のコンテクストを忘れてしまい、異なる解釈をしてしまう可能性も十分あります。
記載内容を一意に定める工夫として、以下のようなものがあります。
- 画面で使用している文言に統一して記述する : 画面名や要素名、ユーザー権限など、画面上で使用している文言はドキュメントにおいても、画面上の文言を使用し、ドキュメントやチーム内での会話に出てくる単語と画面上の表現に乖離が生まれないようにしましょう。これを発展させて、ユビキタス言語を策定することも望ましいです。
- 仕様を構造化する : 仕様を記述するときは箇条書きとインデントを用いて、文書を構造化しましょう。そうすることで、どの要素についての言及なのか。文書間の関係性はどういったものなのかはっきりと意識できます。
- 最新の仕様だけを端的に書く : 議論の過程や仕様の変遷など、最新の仕様以外の情報は受け入れ基準とは別のところに記載し、仕様以外の情報に目が囚われることを防ぎましょう。多くのバックログ管理ツールではコメント機能や変更履歴などの便利な機能が実装されているので積極的に活用しましょう。
【❌悪い例】
・ユーザーログイン履歴画面を作成
・<顧客セグメント>にヒアリングした結果、必要性を認識
・ユーザーのすべて1ヶ月分のログインを確認できる
・エンジニアと議論した結果、パフォーマンスを考慮して1ヶ月分のログインに限定する
・この仕様で目的が実現できるか悩ましい。。。
・履歴画面は管理者がアクセスする
→🤔画面名は結局「ユーザーログイン履歴」・「履歴」どっち？管理者って「ユーザーの権限名」・「システム管理者」？仕様以外のノイズが多すぎる。。。【⭕️いい例】
・画面 ログイン履歴 を新規作成
・ユーザー（管理者権限）のみ閲覧可能
・当該顧客に紐づくユーザーログイン情報を以下の表形式で表示
・ユーザー名, ログイン日時
・直近1ヶ月分のログイン情報のみ表示する
・以下略…
影響範囲を網羅的に記載する
新たな要素を追加すると、副次的に別の画面も修正する必要がしばしば発生します。そういうときは、すべての影響範囲を網羅的に記載しましょう。
実装のヌケモレの防止に繋がりますし、影響範囲を網羅的に検討してみると、実装困難な場所が見つかり、仕様自体見直す必要が出てきたりもします。
【❌悪い例】
・画面 ユーザー情報詳細
・入力項目 ユーザー名（カナ） を追加
→ 🤔 一覧画面は？検索項目は？CSVは？admin画面は？【⭕️いい例】
・画面 ユーザー情報新規作成
・入力項目 ユーザー名（カナ） を追加
・画面 ユーザー一覧
・入力項目 ユーザー名（カナ） を追加
・画面 ユーザー一覧
・検索項目 ユーザー名（カナ） を追加
・画面 ユーザー情報編集
・入力項目 ユーザー名（カナ） を追加
・以下略…
受け入れ基準のおすすめフォーマット
受け入れ基準が満たすべき３つのポイントを紹介しましたが、これらを満たす受け入れ基準を書くことはけっこう大変です。そこで、受け入れ基準のおすすめフォーマットを紹介します。
このフォーマットに従って受け入れ基準を記述すれば、３つのポイントを６〜７割は自動的に満たすことができると思います。
【受け入れ基準のおすすめフォーマット】
・要件（機能要件・非機能要件）
・対象画面
・対象要素
・仕様
・（備考）
要件
要件はユーザーストーリーをユーザーが実施するタスク単位で細分化したもので、次のように記述します。
<ユーザー>は<実施するタスク>できる
中規模以上のユーザーストーリーでは、ユーザーストーリーに複数の要件が含まれていることがしばしばあり、対象画面単位で仕様を書いてしまうと、**複数の要件が混ざってしまい、ユースケースが想像しづらくなってしまいます。
**そこで、要件で仕様をまとめることで、ユーザーストーリーの見通しを良くすることを目的とします。そのため、ユーザーストーリーが小規模であれば、要件の記述は省略して構いません。
ユーザーストーリーと要件の違いは、単体でユーザーに価値を提供できているかどうかです。 ユーザーストーリーはユーザー提供価値を満たしているように記述しますが、要件はユーザーストーリーをユーザーのタスク単位に分割したものなので、単体でリリースしてもユーザーへの提供価値は向上しません。
【ユーザーストーリー】
・管理者ユーザーはユーザーを管理できる【要件】
・ユーザー（管理者権限）はユーザー情報を新規登録できる
・ユーザー（管理者権限）はユーザー情報を編集できる
・ユーザー（管理者権限）はユーザー情報を検索・閲覧できる
・ユーザーは自身のユーザー情報を閲覧できる
対象画面
修正対象となる画面名を記載します。
ユビキタス言語にて画面名が整理されいる場合はそれを使用すればよいですが、そうでない場合は、各画面にH1要素として表示されている文言や、アプリケーションのヘッダー、パンくずで表示されている文言を使用すると認識の齟齬が生まれにくいので望ましいです。
修正対象となる画面が階層構造の下に位置する場合、すべての親階層の画面名も記載するとより明瞭で望ましいです。（例. ユーザー一覧 > ユーザー情報編集）
画面自体を新しく作成する場合は、対象画面の末尾に、「〜を新規作成」と記載すると修正なのか新規作成なのか一目で判断できるのでおすすめです。
・ユーザー（管理者権限）はユーザー情報を新規登録できる
・画面 **ユーザー情報新規登録 **を新規作成
対象要素
修正対象となる要素名を記載します。
要素名は次のフォーマットで記載するとわかりやすいです。
<要素種別> **<要素ラベル>
**要素種別例 : 入力項目、表示項目、検索項目、ボタン、リンク、テーブル、カードなど
要素ラベルはそのまま画面に表示される前提で文言を選択してください。
要素自体を新しく作成する場合は、対象要素の末尾に、「〜を新規作成」と記載すると修正なのか新規作成なのか一目で判断できるのでおすすめです。
・ユーザー（管理者権限）はユーザー情報を新規登録できる
・画面 **ユーザー情報新規登録 **を新規作成
・入力項目 ユーザー名（かな） を新規追加
仕様
修正対象となる要素の具体的な挙動を記載します。
記載すべき挙動は要素種別によって大きく異なります。要素種別ごとの記載すべき挙動として代表的なものをまとめると以下のようになります。
【要素共通】
・表示位置
・表示条件
【入力項目】
・入力種別 : テキスト・ラジオボタン など
・入力制限 : 必須・文字数・文字種 など
・選択肢 : ラジオボタンやプルダウンのとき
・初期値
・活性・非活性条件
・フォカースした・外したときの挙動
【表示項目】
・表示文言 : そのまま実装できる完成した文言が望ましい
・表示スタイル : 太文字、色 など
・as-is, to-be : 表示文言は変更箇所が分かりづらいのでas-is, to-beを併記する
【検索項目】
・入力項目と同じ
・検索ロジックの挙動 : 完全一致・部分一致、検索対象など
【ボタン】
・表示文言
・活性・非活性条件
・クリック時の挙動 : 入力バリデーションロジック・エラー文言も含める
【リンク】
・表示文言
・活性・非活性条件
・クリック時の挙動
【テーブル】
・テーブルヘッダーの文言
・テーブルボディに表示する要素
・表示スタイル
・ソート順 : ソート項目、昇順・降順
・表示数
・ページネーションの有無 : なし・ページネーション・無限スクロール など
【カード】
・カード内の要素 : 小階層で表示
・ソート順
・表示数
・ページネーションの有無・ユーザー（管理者権限）はユーザー情報を新規登録できる
・画面 ユーザー情報新規登録 を新規作成
・入力項目 ユーザー名（かな） を新規追加
・テキスト、必須、２０文字以内、ひらがなのみ
・初期値 : 空欄
備考
仕様には含まれないが、記述しておくべきことがある場合に記述します。例えば、以下のような要素を記述することを想定しています。
- 新たな概念や文言の定義
- スコープ対象外
- 仕様や議論の背景
- 実装仕様で発生するオペレーションの留意点
- 想定している設定例やユースケース
FAQ
Q. なんで箇条書きなの？テーブル表記のほうが一般的じゃない？
**A. 作成速度、可搬性、表示密度の観点から箇条書きを採用しています。
**テーブル表記は全く否定されるものではありませんし、チームがすでにテーブル表記での仕様記述をしている場合は、それに従うべきだと思います。
ただ、箇条書きには以下のようなテーブル表記にまさる点がいくつもあると考えているため、新規に表記を選択できる場合は箇条書きを採用しています。
- 仕様作成速度が早い : 箇条書きは要素間の移動や新たな項目の作成、小階層の作成などすべての作業をキーボードで完結できるツールがほとんどです。そのため、フォーマットの調整や作成に注意をそらされず、仕様作成に集中できるため、作成速度が早いと感じています
- 他ツールへの可搬性が高い : 表はコピペで別のツールに貼り付けるときの挙動が大きく異なります。そのため、意図しないレイアウト崩れや調整などが発生することがしばしばあるため、可搬性の高さでは箇条書きに軍配が上がると思います
- 表示密度が高い : 多くの場合、要素は一行、内容は複数行になるため、表形式にすると、要素列はホワイトスペースとなり、画面内の表示密度が下がってしまいます。
Q. こんなに仕様を具体的に書くと開発チームのやる気が削がれない？
**A. 受け入れ基準を分担して書きましょう。
**受け入れ条件は誰でも書くことができますし、協力して書くことも素晴らしいことです。チームの状況に応じて、要件だけをプロダクトマネージャーが書き、対象画面から仕様までは開発チームが書くなど分担することで、やらされている感は払拭できると思っています。
ただ、「実装したほうが早いから、受け入れ基準はしっかり書かない」というのは反対です。私は受け入れ基準をしっかり書くことは「リファインメントで開発チームからよりよい改善案を受け入れるための準備」と捉えています。
受け入れ基準をしっかり書かないと、リファインメントを通じて、開発チームやBizdevなどステークホルダーから幅広いフィードバックを頂いて、より洗練された仕様に磨き上げる機会を失うことになります。
そうならないためにも、受け入れ基準には可能な限り具体的に仕様を記述されているべきと境は考えます。
Q. どういう仕様がいいか開発チームと議論しないと決められないバックログでは適用できないのでは？
A. 前工程として、仕様策定を目的とした調査バックログを作成すると良いです。
技術的、デザイン的に野心的なバックログを提案する場合に、このような懸念が発生します。
しかし、どのような野心的なバックログであっても、具体的な仕様を決めないと実装は不可能なので、どこかでこの粒度の受け入れ条件を作成する必要があります。
ですので、開発依頼をする前工程として、仕様を策定するために不確実な点を調査・検討する調査バックログを作成することをおすすめします。
調査バックログの受け入れ条件今回ご紹介したフォーマットとは異なるものになると思います。
例えば、調査バックログの受け入れ条件を次のようにすると見通しよく開発できると思います。
・XXX機能を実装するために適切なアーキテクチャが決まっている
・XXX機能を必要とする顧客とユースケースが明らかになっている
・XXX機能の開発バックログのリファインメントが完了している
もう一本記事を読んでいただけると嬉しいです
このサイトではプロダクトマネジメント、組織マネジメントに役立つ情報を毎週発信しています。
この記事が面白かった、ためになったと思う方は、以下のリンクからもう一本記事を読んでいただけると大変嬉しいです！！
では、また！