Jiraで受け入れ条件を書く：実践例で学ぶ

「顧客が通知設定を変更できる」というJira課題は、実装を始めるまでは明確に見えます。変更はすぐ保存されるのでしょうか。保存に失敗したらどうなるのでしょうか。明日も設定は残るのでしょうか。どのメールが影響を受けるのでしょうか。

受け入れ条件は、こうした未回答の問いを、合意された観察可能な結果に変えます。変更を依頼する人、作る人、レビューする人が同じ期待に基づいて働けるようにします。

このガイドでは、架空の顧客ポータル機能の条件を作り、曖昧な要件を改善し、Power PackのDefinition of Done & ACに実用的なリストを追加します。始めるのに特別な書式は不要です。明確な条件と結果があれば十分です。

受け入れ条件とは？

受け入れ条件は、特定の仕事を受け入れるために満たすべき状態を示します。その項目の期待される結果に焦点を当てます。Atlassianは、完成した仕事のより広い品質基準を表す完了の定義とは区別しています。Atlassianの受け入れ条件ガイドを参照してください。

この例なら「保存した通知の選択が、再ログイン後も選択されたままである」が受け入れ条件です。「実装がレビューされている」は共通の完了の定義に属します。

この区別が各リストを役立つものにします。受け入れ条件は機能が合意通りかを示し、完了の定義は仕事がチームの広い完了基準を満たすかを示します。

どちらのリストにも、実装の全手順を書く必要はありません。「データベースのフィールドを作成する」は必要な開発タスクかもしれませんが、顧客やレビュー担当者に設定が正しく動くかを伝えません。

顧客にとっての一つの結果から始める

架空の課題は「顧客が週次サマリーメールを制御できるようにする」です。目指す結果は、ログイン中の顧客が重要なアカウントメッセージを変えずに、週次サマリーを受け取るか選べることです。

条件を書く前に、いくつかの範囲を合意します。設定には明示的なSaveボタンがあります。顧客は自分の設定だけを変えます。対象はまだ送信キューに入っていないサマリーです。すでにキューにあるメッセージは、この課題の配信規則の対象外です。

これらは説明用に作った仕様です。そのまま製品要件としてコピーするのではなく、自分たちの実際の動作を決めてください。

短い範囲のメモがあれば、長いリストに背景のすべてを詰め込まずに済みます。チームはJiraの説明に、今回扱うのはアカウント設定ページの一つの選択項目だと記載します。配信日の選択、メールアドレス変更、他の顧客の設定管理は別の仕事です。

これで、この具体的な変更が動くかを判定する結果に条件を集中できます。

まず通常の流れを書く

大部分の顧客が通ると想定する操作から始めます。開始条件、操作、観察できる結果を普通の言葉で書きます。

例えば「ログイン中の顧客が週次サマリーをオフにして保存に成功すると、アカウント設定を開き直した際に週次サマリーがオフで表示される」です。確認者は開始状態を作り、操作し、結果を調べられます。

「設定が正しく保存される」より有用です。どの設定が変わり、いつ有効になり、どう確かめるかが分かります。

逆方向も必要です。オフにはできてもオンにできない操作部品は不完全です。逆の動作に独立した検証が必要なら、条件も分けます。

関係のない結果を一つに押し込まないでください。保存、キーボード操作、メール配信、エラー処理はいずれも重要かもしれませんが、巨大な一項目では、どこが未解決か示しにくくなります。

失敗と境界のケースを加える

通常の流れは保存が成功する前提です。その前提が崩れた場合に顧客が何を見るべきかを考えます。

チームは「保存要求が失敗したらエラーを表示し、成功メッセージは出さない。開き直したときは以前の保存値が残る」と決めます。これにより、チームのテスト環境で試せる具体的な失敗ケースができます。

次に機能の境界を確認します。週次サマリーの設定がパスワード再設定メールを止めてはいけません。また、顧客の選択は新しいログインセッションでも残る必要があります。異なる観点なので別の条件にします。

「すべての例外を処理する」とは書かず、重要なケースを名指しします。何が失敗しうるか、何は影響を受けてはいけないか、後で何が起きるか、という3つの問いが役立ちます。

期待する結果を合意できないなら、実装が進みすぎる前に未決事項として記録します。未回答の質問は、チェックリストに入れただけでは使える条件になりません。

受け入れ条件リストの具体例

以下は架空の課題の最初の完成稿です。各項目は別々に検証できる結果を表します。

• アカウント設定を開くと、現在保存されている週次サマリーの設定が表示される。
• 週次サマリーをオフにして保存に成功した後、設定を開き直すとオフで表示される。
• 週次サマリーをオンにして保存に成功した後、設定を開き直すとオンで表示される。
• 保存に成功した後、ログアウトして再ログインしても選択が維持される。
• 保存が失敗したらエラーを表示し、成功の確認は表示せず、設定を開き直すと以前の保存値が表示される。
• 設定をオフにした顧客には、保存成功後に新しくキューに入る週次サマリーを送らない。
• 設定をオンにした顧客は、既存のスケジュール規則に従い、次の週次サマリーの対象になる。
• 週次サマリーをオフにしても、顧客が要求したパスワード再設定メールは受け取れる。

配信の項目はキュー内のメッセージに関する範囲の合意に依存します。すでに送信中のメールを設定が取り消すと誤解されないよう、この背景を課題に残します。

これらの条件には実行可能な検証方法も必要です。配信動作については、テスト環境でどうサマリーを発生させ、または確認するか決めます。文章が明確でも、必要なアカウントや配信の証拠に誰もアクセスできなければ検証は難しくなります。

登録前に曖昧な条件を改善する

短い文章の確認が、後の長い意見の食い違いを防ぐことがあります。各項目を読み、2人が成功を違う意味で理解しないか考えます。

最後の例だけで使いやすさが証明されるわけではありません。曖昧な一文を、限定的でも役立つ確認に変えています。より広い使いやすさの目標には調査や複数の合意した観察が必要かもしれません。

作り上げた精密さにも注意します。「2秒以内に応答」と加えるのは測定可能に見えますが、本当の約束になります。性能のしきい値を入れる前に、その条件と理由を合意します。

Power Packに条件を入れる

Jira課題でDefinition of Done & ACカードを見つけ、Acceptance Criteriaを選びます。Definition of Doneとは別のリストなので、入力前に選択タブを確認します。

一つの条件ならタイトルを入力してAddまたはEnterを使います。簡潔でも期待する結果を保ったタイトルにします。多くの背景が必要なら、Jiraの説明やリンクしたチーム文書に置きます。

複数ならBulk ImportでMarkdownの箇条書きを貼り付けます。上の項目は各行の前にハイフンとスペースを付ければ使えます。チェックボックス形式のMarkdownも対応しています。

取り込み後に項目を確認します。現在のリストへの追加なので、同じ内容を再取り込みすると既存項目が重なる場合があります。チェック済みMarkdownは完了状態で入ります。現在の課題で実際に検証済みでない限り、未チェックから始めます。

誤った項目がある場合は、新しい文言をチームで確認して追加し、古い項目は確認メッセージを経て削除します。合意した範囲に影響する変更なら、課題内の説明や議論も分かりやすく保ちます。

完了にする前に結果を確認する

実装前に、検証に関わる人に条件を読み合わせてもらいます。開始条件の不足や、使えるテスト環境では観測できない結果に気づくかもしれません。

実装後は各結果を検証し、通常のJiraや文書の運用で根拠を残します。合意した結果を満たしたらDoneを選びます。後の発見で再確認が必要なら、再度選んで未完了に戻します。

例えばページを再読み込みすると設定が残るのに、再ログインすると初期化されるかもしれません。ページを開き直す条件は合格でも、セッション間の保持は未完了です。別項目にすることで、この有用な違いを保てます。

Power Packはリストの完了を記録します。テストを実行したり、誰がレビューしたかを自動的に確定したりしません。担当者名付きの確認や日付付きの結果が必要なら、通常の手順で明示的に記録します。

両方の件数を使い、証明とは取り違えない

Acceptance CriteriaとDefinition of Doneにはそれぞれ完了数と総数があります。Ready for Releaseは、両リストが空でなく、両方の全項目が完了した場合だけ表示されます。それ以外はIn Verificationです。

これは入力されたリスト状態の要約です。すべての重要な動作が条件に含まれることや、根拠が確かなことは判定できません。Jiraのワークフロー遷移の強制やマージの阻止も行いません。

この通知課題では8つの受け入れ条件がすべて完了していても、Definition of Doneのサポート案内が未完了かもしれません。機能の結果は合格しても、チーム全体の完了合意には残る項目があります。

次のJira課題を一つ選びましょう。顧客向けの結果を書き、重要な条件と結果を合意し、共通の完了の定義と一緒にPower Packへ入れます。実装者と検証者で読み合わせます。最初は当然に思えた一文の裏に潜む思い込みを減らせます。

• Atlassian — 受け入れ条件とは？