スコープ管理

受入基準うけいれきじゅん

受入テスト品質基準完了条件スコープ管理検収要件定義

受入基準について教えて

簡単に言うとこんな感じ！

「このシステム、合格！」って言えるための採点基準だよ。注文した料理が「ちゃんと出来てるかどうか」を判断するメニューの写真みたいなもの。「ここまでできたらOK」って事前に決めておくことで、発注側とベンダー側のすれ違いをなくすんだ！

受入基準（Acceptance Criteria）とは、発注したシステムや機能が「完成した」と見なすために満たすべき条件を、事前に明文化したものです。「何ができていれば納品OK」かをあらかじめ合意しておくことで、検収（納品物の確認・承認）をスムーズに進めることができます。

受入基準がないまま開発を進めると、「うちはこれで完成のつもりだった」「いや、こういう動きを期待していた」というトラブルが頻発します。特にシステム発注では、言葉の解釈のズレが後から大きな手戻りやコスト増につながるため、受入基準の明確化は非常に重要です。

受入基準は要件定義の段階で作成し、受入テスト（ユーザー受入テスト、UAT）の合否判定に使われます。「テストに合格すること＝受入基準を満たすこと」という形で、開発の最終ゴールを明確にする役割を担います。

受入基準は「あいまいな表現」を排除し、誰が見ても同じ判断ができるように書くことが重要です。

受入基準の書き方として、GWT形式（Given-When-Then）がよく使われます。アジャイル開発で普及した書き方ですが、従来型の発注でも使いやすいフォーマットです。

Given（前提）: 登録済みユーザーが、正しいIDとパスワードを入力している
When（操作）:  「ログイン」ボタンをクリックしたとき
Then（結果）:  ホーム画面に遷移し、ユーザー名が画面右上に表示される

「ちゃんと動く」「使いやすい」といったふわっとした表現をGWT形式に変換するだけで、認識のズレが大幅に減ります。

1970年代〜: ウォーターフォール型開発の普及とともに、「検収」の概念が整備される。大型システム開発における契約・納品の判断基準として受入基準が重要視されるようになった
1990年代: ISO 9000シリーズ（品質マネジメント規格）の普及により、納品物の品質基準を文書化することが広まる
2001年: アジャイルソフトウェア開発宣言（Agile Manifesto）が発表され、「動くソフトウェア」を重視する考え方が広まる
2000年代後半: スクラム（Scrum）やBDD（振る舞い駆動開発）の普及により、Given-When-Then形式が受入基準の標準的な記述方法として定着
2010年代〜: クラウドサービスやSaaS導入の増加により、受入基準は「カスタマイズ範囲の合意」としても活用されるようになった

この3つはよく混同されます。それぞれの役割を整理しておきましょう。

受入基準は発注者側が主体的に作成・合意するものです。「ベンダーが書いたものにサインするだけ」では、自社にとって本当に必要な条件が抜け落ちるリスクがあります。

規格番号	内容
ISO/IEC 25010	ソフトウェア品質特性モデル（機能適合性・性能効率性・使用性など）。受入基準の品質観点の整理に活用される
ISO/IEC/IEEE 29119	ソフトウェアテスト国際規格。受入テストの計画・設計・実行の標準的プロセスを定義