Confluence でチームワークを変革しましょう。チームのコンテンツ コラボレーション ハブとして、Confluence を選ぶ理由をご確認ください。
承認基準とは: 例とベスト プラクティス
承認基準によって明確なコミュニケーションが促進されます。また、承認基準は期待事項を定義するのに役立ちます。承認基準は、機能やユーザー ストーリーが完全であるために満たさなければならない特定の条件の概要を示すものであり、「完了の定義」と呼ばれることもあります。
実際に成果を上げるソフトウェアを構築する秘訣とは何でしょうか。製品マネージャーや製品所有者にとって、的を射た機能を構築するための鍵となるのは、承認基準を明確にすることです。
明確な承認基準がないと、チームは混乱し、目的を達成できず、無駄な労力を費やすおそれがあります。しかし、承認基準とは具体的に何であり、どうすれば適切に作成できるのでしょうか。
この記事では、承認基準の概要、実例、ユーザー ストーリーとの違い、開発プロセスにとって重要である理由、および独自の承認基準の作成方法を詳しく説明します。
承認基準とは
承認基準とは、製品、ユーザー ストーリー、または作業のインクリメントを完成させるためにそれらが満たさなければならない条件のことです。承認基準は明確・簡潔でテスト可能なステートメントのセットであり、顧客に良い結果をもたらすことに焦点を当てています。
承認基準は、どのように解決策にたどり着くかに焦点を当てるのではなく、タスクで求められる最終的な結果です。
アジャイル手法では、承認基準は事前に定義された要件と見なされます。具体的には、ユーザー ストーリーが完了したと見なされるために満たす必要がある条件です。また、デリバリーを成功させるために必要な特定の条件を概説するアジャイル要件ドキュメントの一種としても機能します。
承認基準とユーザー ストーリー
承認基準とユーザー ストーリーは、よく一緒に議論されますが、製品開発では根本的に異なる役割を果たします。この違いを理解することは、ユーザー志向でありながら迅速なデリバリーを実現するバックログを作成する上で不可欠です。
ユーザー ストーリーは「理由」を明確に示し、ユーザーの視点から機能の目的と価値を伝えます。
承認基準は「成功とは何か」を定義し、その目的を明示的で検証可能な実装要件に変換します。
適切に作成されたユーザー ストーリーは、顧客のニーズ、意図された行動、根本的な動機を捉えます。このフレーミングにより、バックログ項目が実際のユーザー価値に結び付けられ、バックログ グルーミングや優先順位付けの際に不可欠なコンテキストが提供されます。
たとえば、次のようなユーザー ストーリーがあるとします。
顧客として、製品を名前で検索して、探しているものを簡単に見つけられるようにしたい。
このストーリーは方向性を決めているだけで、実装については特に規定していません。
一方、承認基準は意図をストーリーが完了したかどうかを判断する明確でテスト可能な条件に変換します。スコープに沿ってチームの足並みを揃え、曖昧さを排除し、QA や関係者に測定可能な基準を提供します。たとえば次のようなものです。
検索機能は、入力した製品名と完全に一致する結果を返す。
検索機能は、入力した製品名と部分的に一致する結果を返す。
結果は、明確で整理されたユーザーフレンドリーな形式で表示される。
ユーザー ストーリーと承認基準の組み合わせにより、チームは適切な機能を適切な方法で構築できるようになります。
適切な承認基準の特徴
質の高い承認基準には、内容を簡単に理解して検証できるようにし、デリバリーを効果的にサポートするいくつかの重要な特徴があります。一般的な特徴は次のとおりです。
明確性と簡潔性
言いたいことを正確かつシンプルに伝えましょう。承認基準は、すべての関係者 (エンジニアリング、QA、設計、製品など) が同じように解釈できる簡単明瞭な文体で記述してください。
簡潔な結果重視の内容にしましょう。専門用語や解釈の余地を残すような表現は避けてください。
テスト可能性
すべての基準は客観的に検証できる必要があります。個々の基準を、要件が満たされているかどうかを客観的に確認する 1 つ以上の実行可能なテストに手際よくマッピングしてください。
テスト可能性により、主観性が完全に排除され、「完了」が実際に何を意味するのかを全員が率直に判断できるようになります。
結果
手順ではなく、結果を説明しましょう。強固な基準は、ユーザーが体験すべきことを説明するものであり、それを構築するために必要な技術的な手順ではありません。
これにより、エンジニアに問題解決の機会を与えながら、最終的な動作をユーザーの期待に沿うものにすることができます。
測定可能性
可能であれば、期待値を定量化して明確な合格/不合格のしきい値を作成します。この場合、精度を高めることでテストがスピードアップし、手戻りが減ります。
「結果ページの見栄えが良い」のような曖昧な記述は置き換えましょう。代わりに、「各製品画像が最低 300×300 ピクセルの解像度で表示される」のような測定可能な記述を使用してください。
依存性
各基準は独立して成り立っています。基準が独立しているため、テストが簡素化され、結合度が下がり、何かが失敗した際の課題の診断が容易です。
基準が相互に依存することで意義を持つ場合は、おそらく基準を書き直す必要があります。
承認基準が必要なのはなぜですか?
承認基準は、明確性を高め、手戻りを減らし、構築しようと思っていたものを確実に提供するための最も強力なツールの 1 つです。承認基準をプロセスに恒久的に組み込むべき理由は次のとおりです。
足並みの統一と共通理解: 成功がどのようなものかを明確に示すことで、エンジニアリングから QA、関係者まで、全員が同じ認識を持つことができ、予期しない事態につながる思い込みを避けられます。承認基準は、何を構築するのか、そしてなぜ構築するのかに関する共通の取り決めとして機能します。
曖昧さと手戻りの削減: 明確な「完了」の定義 (DoD) は、手戻りを防ぐ最短の道です。曖昧な期待は終わりのない反復を招きます。明確な基準があれば、主観 (およびスコープ クリープ) を排除できます。事前に明確化しておくことで、後から修正するよりも必ずコストが安く済みます。
テスト効率の向上: 明確に定義された承認基準は、QA チームにテスト実行のブループリントを提供します。これらは検証可能なステップに直接変換できるため、機能が期待に応えているかどうかを簡単に確認したり、期待に応えていない箇所を容易に特定したりできます。
強化されたプロジェクト管理: プロジェクト マネージャーにとって、承認基準は非常に重要です。承認基準によって機能が測定可能な複数のチェックポイントに分割され、進捗が可視化されてリスクを軽減できます。それぞれの基準を確実に満たすことが、デリバリーに向けた明確な一歩となります。
関係者満足度の向上: 機能が常に期待に応えることで、関係者はプロセスと製品を信頼するようになります。明確な承認基準は、現実的な期待値を設定し、曖昧さを最小限に抑え、ユーザーのニーズを真に満たす成果の提供に役立ちます。
承認基準は、ビジョンの作成から実行までの橋渡しをします。意図を足並みの一致に、足並みの一致をアクションに、そしてアクションを確実なデリバリーに変えます。
チームが迅速に行動し、かつ適切な機能を構築することを望むなら、承認基準は必須です。
承認基準の書き方
ソフトウェア開発を成功させるには、適切に定義された承認基準を作成することが不可欠です。指針となる重要なステップとヒントをいくつか紹介します。
1. ユーザー ストーリーから始める
承認基準に関連したユーザー ストーリーを参照してください。そうすることで、基準と求められる機能を関連付けることができます。
2. 成果を決定する
ユーザー エクスペリエンスと期待される結果の基準を表現します。その機能はユーザーに対してどのような結果をもたらすべきですか? 実装の技術的詳細にとらわれないようにしてください。
3. 全体的なテスト容易性を確保する
各基準を使用して、明確かつ検証可能なテストができることを確認します。これにより、機能が要件を満たしているかどうか客観的に評価できます。
4. 測定可能性を判定する
可能な限り、測定可能な条件を使って基準を数値化します。これにより、テストで合否を明確に判定できるようになります。
5. 独立性を重視する
個別にテストできる独立した基準を目指します。これにより、テストのプロセスが合理化され、依存関係が回避されます。
開発チームの基準と併せて、UAT (ユーザー受け入れテスト) の基準を組み込むことを検討してください。UAT の基準は、機能が使いやすさの観点から期待に応えるようにすることに重点を置いています。
6. コラボレーションを促進する
作成プロセス時のコラボレーションを促進します。製品所有者、ソフトウェア開発者 (または開発チーム)、その他の関係者を関与させて、あらゆる視点を反映した一連の包括的な基準となるようにします。
7. レビューして改良する
開発全体を通して、承認基準を見直して改良していくようにします。理解が深まるにつれて、基準を調整して最新の情報を反映させることを検討します。
8. 明確かつ簡潔にする
誰もが理解できる明確で簡潔な言葉を心がけましょう。専門用語や曖昧な表現は混乱を招く可能性があります。
誰が承認基準を書くべきですか?
アジャイル ワークフローとアジャイル手法の環境で承認基準を書くことは、個人の作業というより共同作業です。代表的な役割の内訳は以下の通りです。
製品所有者: 顧客のニーズと製品のビジョンを深く理解すると同時に、ディスカッションを始めて、求められる機能の概要を示す上で重要な役割を果たします。
開発チーム: 技術的な専門知識を活用して基準の活用可能性とテストの容易性に関する貴重なインサイトを提供します。また、明確な評価を可能にする基準を組み立てる適切な方法を提案します。
スクラム マスター (該当する場合): チームのディスカッションを導き、全員が発言する機会を持てるようにする進行役です。また、基準がベスト プラクティスに準拠したものになるようサポートします。
製品所有者がプロセスを開始することもできますが、最終的な基準は、すべての関係者の視点を統合した共同作業の成果であるべきです。
この協力的なアプローチによって、共通の理解が促進され、成功を収める製品を生み出す可能性が高まります。
承認基準の例
以下は、承認基準が適切に記述されている、より洗練された例です。各例では、ユーザー ストーリーが、「完了」の意味を定義する具体的で測定可能な基準に明確に結び付いています。
例 1: 製品検索
ユーザー ストーリー: 顧客として、製品を名前で検索して、探しているものをすばやく見つけられるようにしたい。
承認基準:
検索語句と完全に一致するすべての製品が返される。
ユーザーが 3 文字以上入力すると部分一致が返される。
検索結果には、製品名、画像、価格が明確で整理されたレイアウトで表示される。
検索結果ページではページネーションがサポートされており、1 ページあたり最大 20 項目が表示される。
結果が見つからない場合、「結果が見つかりません」というメッセージと役立つ次のステップが表示される。
例 2: アカウント情報の編集
ユーザー ストーリー: 登録ユーザーとして、プロファイルを最新の状態に保つためにアカウント情報を編集したい。
承認基準:
ユーザーは、アカウント設定内の [プロファイルの編集] セクションにアクセスできる。
ユーザーは自分の姓、名、メール アドレス、電話番号を更新できる。
システムによって必須フィールドが検証され、無効な情報または不足している情報に対してエラーが表示される。
[保存] をクリックすると、システム内のユーザー情報が正常に更新される。
更新が正常に完了すると、確認メッセージが表示される。
更新が失敗した場合、対応可能なエラー メッセージが表示される。
例 3: ユーザー アクティビティ レポート
ユーザー ストーリー: 管理者として、ユーザー アクティビティとエンゲージメントを追跡するためのアクティビティ レポートを生成したい。
承認基準:
管理者ダッシュボードに専用の [レポート] セクションが含まれている。
管理者は、ログイン、製品ビュー、購入など、主要なユーザー アクティビティに関するレポートを生成できる。
レポートを日付範囲とユーザー タイプでフィルタリングできる。
管理者は、CSV や PDF を含む少なくとも 2 つの形式でレポートをエクスポートできる。
レポートを生成できない場合に明確なエラー メッセージが表示される。
これらの例は、強力な承認基準がユーザー ストーリーを実現可能でテスト可能な要件に変換する方法を示しています。この構造に従えば、一貫してユーザーの期待に応える機能を提供し、開発全体を通じて曖昧さを軽減できます。
一元化されたプラットフォームを活用して明確な承認基準を作成する
全員が一元化されたスペースで作業すると、承認基準の作成、追跡、共有が非常に簡単になります。そのため、多くのチームが承認基準の管理に Jira を使用しています。
ストーリーの説明や [承認基準] フィールドに直接、簡単に承認基準を配置できます。また、Jira の書式設定ツール (箇条書きやチェックボックスなど) を使って、進捗を追跡したり、要件の明確性を保ったりすることができます。
さらに、設計図を添付したり、Confluence ドキュメントにリンクしたりすることで、関連するすべてのコンテキストに簡単にアクセスできるようになります。より一貫性がある完全な承認基準を作成できるようサポートが必要な場合は、Jira の AI ソリューション Rovo がギャップを特定し、改善を提案します。
これらの機能とツールを組み合わせることで、曖昧さが軽減され、よりスムーズな開発プロセスを実現できます。今すぐ始めましょう。
承認基準: よくある質問
承認基準と DoD (「完了」の定義) との違いは何でしょうか?
承認基準と DoD はプロジェクトの成功には不可欠ですが、目的が異なります。承認基準は、エンド ユーザーの要求を達成するためにユーザー ストーリーで遂行する必要がある特定の機能に重点を置いています。
DoD では、開発作業すべてにおける広範な品質基準を定めています。これらには、コードの品質やドキュメントなどの非機能的な要素が含まれています。
承認基準では、ユーザー ストーリーで実行する必要がある機能を定義しますが、DoD ではチームが開発作業を完了させる方法に対する全体的な品質基準を概説します。
承認基準を記述するタイミング
理想的なタイミングはさまざまですが、考慮すべき重要な時期がいくつかあります。1 つ目は、バックログ リファインメント セッション時に最初の基準を特定する際です。チームはユーザー ストーリーについて話し合い、具体化します。
もう 1 つの適切な時期は、スプリント計画時です。次のスプリントで予定されているユーザー ストーリーの承認基準をチームが協力して確定します。こうすることで、基準を最新の状態に保ち、直近の合意が反映されるようにします。
開発が始まる前に承認基準を定義し、期待事項を明確にして開発プロセスを円滑に進められるようにします。
承認基準を記述する際の課題は何ですか?
チームが直面する一般的な課題の 1 つは、基準の不明確さです。そのため、誤って解釈してしまう可能性があります。また、チームは、過度に具体的な基準と不明瞭すぎる基準をうまく両立させるのに苦労することもあります。
実行すべきタスクに関して関係者間で意見が対立すると、プロセスを妨げる可能性があります。また、すべての詳細を網羅したくなる場合もありますが、煩雑になり、最終的には承認基準の効果がなくなる可能性があります。