承認基準: 例とベスト プラクティス

承認基準とは

承認基準とは、製品、ユーザー ストーリー、または作業のインクリメントを完成させるためにそれらが満たさなければならない条件のことです。承認基準は明確・簡潔でテスト可能なステートメントのセットであり、顧客に良い結果をもたらすことに焦点を当てています。承認基準は、どのように解決策にたどり着くかではなく、タスクで求められる最終的な結果に焦点を当てています。

承認基準とユーザー ストーリー

承認基準とユーザー ストーリーの違いは、承認という言葉によって明確にされています。この 2 つの概念は相互に関連していますが、目的が異なります。

ユーザー ストーリーは、バックログ グルーミングに不可欠な、製品バックログの項目の背後にある理由を明らかにします。顧客のニーズを要約し、求められる機能や特徴の概要を示し、開発作業の理論的根拠を示します。

承認基準では、項目を完成させるために満たすべき条件を定めます。この基準によって、開発プロセスの成功の度合いを測定し、提供される機能がユーザーの要件と一致するようにします。

「顧客としては、探している品目を簡単に見つけられるように、名前で製品を検索したい」というユーザー ストーリーを考えてみましょう。これに対応する承認基準として、次のことが含まれる場合があります。

• 検索機能は、入力した製品名と完全に一致する結果を返す必要がある。
• 検索機能は、入力した製品名と部分的に一致する結果を返す必要がある。
• 検索結果は、明確に整理して表示する必要がある。

ユーザー ストーリーは、ユーザー中心の視点で機能や特徴を説明します。承認基準は、実装の成功に関してより技術的で測定可能な定義を提供します。

適切な承認基準の特徴

効果的な承認基準には、明確なコミュニケーションと円滑な開発プロセスを可能にするいくつかの重要な特徴があります。その重要な要素の内訳は以下の通りです。

1. 明確さと簡潔さ: 承認基準は、開発者、製品所有者、テスターを含むすべての関係者が簡単に理解できるように、平易な言葉で書きます。専門用語や曖昧な表現を避けます。簡潔かつ直接的に表現し、特定の結果に焦点を当てます。
2. テストの容易性: 適切に書かれた承認基準は明確に検証可能です。各基準では 1 つ以上の明確なテストが可能で、実装された機能が定義済みの要件を満たしているかどうか判別できる必要があります。これにより客観的な評価が可能になり、誤解の余地がなくなります。
3. 結果: 実装の技術的な詳細よりも、求められる結果やユーザー エクスペリエンスに焦点を当てます。基準では、機能の構築方法ではなく、機能の目標を定義する必要があります。これにより、開発者に権限を与えると同時に、最終製品をユーザーのニーズに合わせることができます。
4. 測定可能性: 可能な限り、測定可能な用語で基準を表現します。これにより、テストで合否を明確に判定できます。たとえば、「検索結果ページは視覚的に魅力的であるべきです」と表現するより、「検索結果ページに表示する製品画像の最低解像度は 300x300 ピクセルにすべきです」と表現する方が良い基準でしょう。
5. 独立性: 理想的には、承認基準は互いに独立している必要があります。これにより、個別にテストと評価が可能になり、テストのプロセスが合理化されます。

承認基準が必要なのはなぜですか?

承認基準は、明確なコミュニケーションを促進し、曖昧さを軽減して、プロジェクトの成功を確かなものにします。主なメリットを詳しく見てみましょう。

• 整合性と共通の理解: 承認基準では、機能やユーザー ストーリーの要件を明確に定義することで、開発者、製品所有者、テスターを含むすべての関係者の間で共通の理解が築かれます。この整合性により、誤解が最小限に抑えられ、全員が同じ目標に向かって取り組むことができます。
• 曖昧さとやり直しの軽減: 承認基準は、具体的な完了の定義 (DoD) を示し、主観や誤解を招く可能性を排除します。この明瞭さは、ユーザーの期待に応えていない機能に起因するやり直しを防ぐのに役立ちます。
• テスト効率の向上: 適切に定義された承認基準は、明確でテスト可能な要件に直接反映され、評価のためのロードマップが提供されて効率的なテストが促進されます。
• プロジェクト管理の強化: 承認基準はプロジェクト マネージャーにとって貴重なツールです。基準を満たすたびに機能の実現に一歩近づくので、進捗をより適切に追跡できます。
• 関係者の満足度の向上: 承認基準は、機能がユーザーの要件を満たすようにすることで、関係者の満足度を高めます。明確なコミュニケーションと適切に定義された期待事項は、エンド ユーザーに価値を提供するより高品質の製品につながります。

承認基準は、ビジョンとデリバリーの間のギャップを埋めます。全員が目標を理解し、その目標を達成するために協力するコラボレーション環境が促進されます。

誰が承認基準を書くべきですか?

アジャイル ワークフローとアジャイル手法の環境で承認基準を書くことは、個人の作業というよりは共同作業です。代表的な役割の内訳は以下の通りです。

• 製品所有者: 顧客のニーズと製品のビジョンを深く理解している製品所有者は、ディスカッションを始めて、求められる機能の概要を示す上で重要な役割を果たします。
• 開発チーム: 技術的な専門知識を持つ開発チームは、基準の実現可能性とテストの可能性に関する貴重なインサイトを提供します。明確な評価が可能な基準を組み立てる適切な方法を提案できます。
• スクラム マスター (該当する場合): スクラム マスターは、チームのディスカッションを導き、全員が発言権を持てるようにする進行役です。また、基準がベスト プラクティスに準拠したものになるようサポートすることもできます。

製品所有者がプロセスを開始することもできますが、最終的な基準は、すべての関係者の視点を統合した共同作業の成果であるべきです。この協力的なアプローチによって、共通の理解が促進され、成功を収める製品を生み出す可能性が高まります。

承認基準の書き方

ソフトウェア開発を成功させるには、適切に定義された承認基準を作成することが不可欠です。指針となる重要なステップとヒントをいくつか紹介します。

1. ユーザー ストーリー: 承認基準に関連したユーザー ストーリーを参照してください。そうすることで、基準と求められる機能を関連付けることができます。
2. 結果: ユーザー エクスペリエンスと期待される結果の基準を表現します。その機能はユーザーに対してどのような結果をもたらすべきですか?実装の技術的詳細にとらわれないようにしてください。
3. 明確さと簡潔さ: 誰もが理解できる明確で簡潔な言葉遣いを心がけます。専門用語や曖昧な表現は混乱を招く可能性があります。
4. テストの容易性: 各基準について、明確かつ検証可能なテストができることを確認します。これにより、機能が要件を満たしているかどうか客観的に評価できます。
5. 測定可能性: 可能な限り、測定可能な用語を使って基準を数値で表します。これにより、テストで合否を明確に判定できるようになります。
6. 独立性: 個別にテストできる独立した基準を目指します。これにより、テストのプロセスが合理化され、依存関係が回避されます。
7. ユーザー受け入れテスト (UAT): 開発チームの基準に加えて UAT の基準を組み込むことを検討します。UAT の基準は、機能が使いやすさの観点から期待に応えるようにすることに重点を置いています。
8. コラボレーション: 作成プロセス時のコラボレーションを促進します。製品所有者、開発チーム、その他の関係者を関与させて、あらゆる視点を反映した包括的な基準となるようにします。
9. レビューと改良: 開発全体を通して、承認基準を見直して改良していくようにします。理解が深まるにつれて、基準を調整して最新の情報を反映させることを検討します。

これらの手順とヒントは、明確なコミュニケーション、効率的なテスト、プロジェクトの成功を促進する承認基準を策定するのに役立ちます。

承認基準の例

適切に書かれた承認基準の例をいくつか示します。

例 1

ユーザー ストーリー: 顧客としては、製品を名前で検索して、特定の品目を簡単に見つけたいと思っています。

• 承認基準:
  • 検索機能は、入力した製品名と完全に一致する結果を返す必要がある。
  • 検索機能は、入力された製品名と部分的に一致する (少なくとも 3 文字が一致する) 結果も返す必要がある。
  • 検索結果は、製品名、画像、価格を含み、明確に整理されて表示される必要がある。
  • 検索結果ページでは、ページネーションで 1 ページあたり最大 20 項目を表示できる必要がある。

例 2

ユーザー ストーリー: 登録ユーザーとして、プロファイルを最新の状態に保つためにアカウント情報を編集したい。

• 承認基準:
  • ユーザーは、アカウント設定内の [プロファイルの編集] セクションにアクセスできる。
  • ユーザーは自分の姓、名、メール アドレス、電話番号を編集できる。
  • ユーザー情報の変更はすべて、[保存] ボタンをクリックして保存する必要がある。
  • ユーザー情報が更新されると、確認メッセージが表示される。

例 3:

ユーザー ストーリー: 管理者として、ユーザー アクティビティに関するレポートを生成し、ユーザー エンゲージメントを追跡したい。

• 承認基準:
  • 管理者ダッシュボード内に専用のレポート セクションがある。
  • 管理者は、ログイン、製品ビュー、購入など、さまざまなユーザー アクティビティに関するレポートを生成できる。
  • ユーザーは、日付範囲やユーザー タイプでレポートをフィルタリングできる。
  • ユーザーはさまざまな形式 (CSV、PDF など) でレポートをダウンロードできる。

これらの例では、承認基準によりユーザー ストーリーを具体的・測定可能・テスト可能な条件に置き換える方法を示しています。この構造に従うと、企業は明確で簡潔な承認基準を作成して、ユーザーのニーズを満たす機能を開発して提供できるようになります。

Jira で明確な承認基準を記述する

効果的な承認基準は、ソフトウェア開発を成功させるための基礎になります。承認基準によってユーザーのニーズと技術的な実装のギャップを埋め、全員が同じ認識を持ち、最終製品で価値を提供できるようにします。

プロジェクトの成功には、明確・簡潔・テスト可能な承認基準が不可欠です。明確に定義された基準は、円滑なコミュニケーションを促進し、テストを合理化し、最終的にはより望ましいプロジェクトの成果につながります。

Jira を使用して、アジャイル プロジェクト管理チームの承認基準を最適化しましょう。Jira では、課題内で承認基準のカスタム フィールドを有効化できるため、これらの基準をソートして、すべての関係者が簡単にアクセスできるようにすることが可能です。

Jira のカスタム フィールドや、上述した実践方法を活用することで、チームは開発ライフサイクル全体を通して承認基準を明確かつ効果的に保ち、開発プロセスをより効率的で協調的なものに改善できます。

承認基準: よくある質問

承認基準と DoD (「完了」の定義) との違いは何でしょうか?

承認基準と DoD はプロジェクトの成功には不可欠ですが、目的が異なります。承認基準は、エンド ユーザーの要求を達成するためにユーザー ストーリーで遂行する必要がある特定の機能に重点を置いています。DoD では、開発作業すべてにおける広範な品質基準を定めています。これらには、コードの品質やドキュメントなどの非機能的な要素が含まれています。承認基準では、ユーザー ストーリーで実行する必要がある機能を定義しますが、DoD ではチームが開発作業を完了させる方法に対する全体的な品質基準を概説します。

承認基準を記述するタイミング

理想的なタイミングはさまざまですが、考慮すべき重要な時期がいくつかあります。1 つ目は、バックログ リファインメント セッション時に最初の基準を特定する際です。チームはユーザー ストーリーについて話し合い、具体化します。もう 1 つの適切な時期は、スプリント計画時です。次のスプリントで予定されているユーザー ストーリーの承認基準をチームが協力して確定します。こうすることで、基準を最新の状態に保ち、直近の合意が反映されるようにします。開発が始まる前に承認基準を定義し、期待事項を明確にして開発プロセスを円滑に進められるようにします。

承認基準を記述する際の課題は何ですか?

チームが直面する一般的な課題の 1 つは、基準の不明確さです。そのため、誤って解釈してしまう可能性があります。また、チームは、過度に具体的な基準と不明瞭すぎる基準をうまく両立させるのに苦労することもあります。実行すべきタスクに関して関係者間で意見が対立すると、プロセスを妨げる可能性があります。また、すべての詳細を網羅したくなる場合もありますが、煩雑になり、最終的には承認基準の効果がなくなる可能性があります。