答え。

歴史的に受け入れ基準の定義は、テスターや開発チームの手に委ねられてきました。しかし、スケーラブルなアジャイルプロセス（SAFe, LeSS, Scrum-of-Scrums）への移行に伴い、形式的なテストシナリオなしでは、大規模プロジェクトに関与するさまざまな参加者（ビジネス、テスト、開発、サポート）が異なる期待を持つリスクが生じます。それぞれがタスクの完了を異なる方法で解釈する可能性があります。

マルチチームまたは分散プロジェクトの問題は、責任の異なるゾーンや異なるプロセスとツール、言語や文化的な違いがあることです。詳細に検討された要件でさえも、対立するまたは不完全な受け入れ基準に変わる可能性があり、それによってバグやビジネスの不満が発生します。

解決策は、受け入れ基準の形成の初期段階にシステムアナリストを関与させ、チーム間での要件の調整を行い、シナリオやエッジケース（edge-cases）を共通のデモやグループワークショップで厳格に形式化し、共同で議論することです。

主な特徴：

• 受け入れ基準は明確で、測定可能で、再現可能で、検証可能であるべきです。
• 基準の事前合意（手動チェックリスト＋期待されるデータ/動作の例）。
• 相互トレーシング：基準は常に要件、ケース、ユーザーストーリーを参照し、各目標を追跡できるようにすべきです。

意地悪な質問。

受け入れ基準の定義を完全にテスターに任せても良いか？

いいえ、アナリストは参加する義務があります。彼だけがビジネスコンテキストの全体を把握し、要件のすべてのニュアンスを知っています。

受け入れ基準にはポジティブシナリオだけをカバーすれば良いか？

いいえ、必ずネガティブおよび境界ケース（edge cases）を追加しなければなりません。そうしないと、実装やテストにおいてギャップが生じる危険があります。

マルチチームプロジェクトで受け入れ基準を口頭で定義することはできるか？

いいえ、口頭の合意は分散した相互作用に耐えられず、対立を引き起こします。基準は必ず形式的に合意されます（例：Gherkin/BDDや構造化されたチェックリストの形で）。

一般的な間違いやアンチパターン

• 受け入れ基準が「デフォルト」で定義され、要件や仕様への参照がない。
• 最終チームからのフィードバックがない。
• 異なるチーム間のコンポーネント間の相互作用シナリオを無視する、特に統合時に。

実生活の例

ネガティブケース： 銀行アプリケーションの受け入れ基準は、機能の送金に関して一つのチームとのみ合意されました。二つ目のチームは、最初の基準グループを考慮せずに内部インターフェースを実装したため、トランザクションIDのフォーマットの不一致が生じました。

長所：

• 実装の迅速な開始。

短所：

• APIのリファクタリングが必要。
• 競合の調整にかかる時間の浪費。

ポジティブケース： アナリストは、参加すべてのチームと可視化されたシナリオおよび詳細に関する一連のワークショップを実施し、Confluence/JIRAに受け入れ基準を必ず文書化し、要件との双方向トレーシングを行いました。

長所：

• 曖昧さの排除。
• 潜在的なバグの迅速な検出と回避。

短所：

• 事前合意にかかる時間の増加。