フレームワーク活用ガイドひとことで言うと#
成果物を「完成」と見なす条件を、作業に着手する前に関係者全員で合意しておく手法。「何ができたらOKか」を数値・チェックリストで定義し、検収時の認識ズレと手戻りを防ぐ。
押さえておきたい用語#
- 受入基準（Acceptance Criteria）
- 成果物が「合格」と判定されるための具体的な条件リスト。機能要件・非機能要件・品質水準を含む。
- 成果物（Deliverable）
- プロジェクトの各フェーズで生み出される具体的なアウトプットを指す。設計書、プロトタイプ、コード、報告書などが該当する。
- 検収（Acceptance / Sign-off）
- 受入基準に照らして成果物を合否判定する公式プロセス。合格すれば次フェーズに進み、不合格なら差し戻される。
- トレーサビリティ
- 要件から成果物、テストまでの追跡可能性。どの基準がどの要件に紐づくかを明示する考え方。
成果物受入基準の全体像#
こんな悩みに効く#
- 「完成です」と言われたが、期待していたものと違った
- 検収のたびに「ここが足りない」「聞いていない」と揉める
- 品質の合格ラインが人によって違い、判断がブレる
基本の使い方#
プロジェクトで生み出す成果物を一覧化し、それぞれに「何が求められているか」を洗い出す。
- 機能要件: 「ユーザーがログインできる」「CSVエクスポートが動作する」など
- 非機能要件: 「レスポンス2秒以内」「同時接続100人に耐える」など
- 品質要件: 「単体テストカバレッジ80%以上」「誤字脱字ゼロ」など
漏れを防ぐため、発注者・開発者・テスト担当の3者で棚卸しするのが望ましい。
曖昧な表現を、誰が見ても合否を判定できる形に書き換える。
| 曖昧な表現 | 判定可能な基準 |
|---|---|
| 使いやすいUI | 初見ユーザーが主要タスクを3分以内に完了できる |
| 高速に動作する | 95パーセンタイルのレスポンスが2秒以内 |
| バグが少ない | 重大バグ0件、軽微バグ5件以内 |
| セキュリティが高い | OWASP Top10の脆弱性検査を全項目パス |
ポイントは「数値」「Yes/No」「比較対象」のいずれかで書くこと。
策定した基準を文書化し、発注者・受注者の双方が確認・承認する。
- 基準書はプロジェクトの共有フォルダに置き、いつでも参照できるようにする
- 途中で要件が変わった場合は、基準も変更し再合意する（変更管理と連動）
- 「合意した基準にない項目で不合格にしない」というルールを明確にする
成果物が提出されたら、基準書をそのままチェックリストとして1項目ずつ判定する。
- 全項目合格 → 正式に検収完了・次フェーズへ
- 不合格項目あり → 具体的な差異を記録し、修正範囲と期限を合意
- 判定が微妙なもの → 基準の曖昧さが原因なので、基準自体を改善する
具体例#
状況: 従業員12名のWeb制作会社が、中堅メーカー（従業員300名）のコーポレートサイトリニューアルを受注。予算800万円、納期3ヶ月。過去に「イメージと違う」で2回やり直した苦い経験がある。
策定した受入基準（抜粋）
| カテゴリ | 基準 | 判定方法 |
|---|---|---|
| デザイン | ワイヤーフレーム承認後のデザインカンプと差異なし | 画面比較ツールで差分5%以内 |
| 表示速度 | Lighthouse Performanceスコア 90以上 | Chrome DevToolsで計測 |
| レスポンシブ | iPhone SE〜27インチモニターで崩れなし | 実機5台+BrowserStackで確認 |
| SEO | 全ページにmeta description・OGP設定済み | Screaming Frogでクロール確認 |
| セキュリティ | SSL証明書設定・混在コンテンツなし | SSL LabsでA以上 |
結果: 検収時に「表示速度がスコア87だった」という1項目だけ不合格。画像圧縮の追加対応で3日後に再検収し、全項目合格で納品完了。基準がなかった頃の「なんとなく気に入らない」という差し戻しがゼロになった。
状況: 従業員450名の食品加工メーカーが、新しい充填ラインを1億2,000万円で導入。設備メーカーとの間で「稼働率の定義」を巡って前回トラブルになったため、今回は受入基準を事前に策定。
基準の構成
- 性能基準: 充填速度 毎分120本以上、充填量誤差 ±1.5%以内
- 品質基準: 不良率 0.3%以下（1万本中30本以内）
- 稼働基準: 連続8時間運転で計画外停止 2回以内、復旧時間15分以内
- 安全基準: CE適合証明書、非常停止ボタン全箇所動作確認
検収プロセス
- FAT（工場出荷前テスト）: 設備メーカーの工場で基準の80%を確認
- SAT（現地受入テスト）: 自社工場で実際の原料を使い全基準を確認
- 2週間の試運転期間で稼働データを取得し、最終判定
前回は「稼働率95%」の定義が双方で違い3ヶ月揉めたが、今回は「計画外停止」の回数と時間で定義したことで判定が明確になり、SAT完了から正式検収まで 5営業日 で決着がついた。
状況: 人口18万人の地方自治体が、住民情報システムを刷新。契約額3億5,000万円、開発期間18ヶ月。過去のシステム導入では検収が半年遅延した経緯がある。
工夫した点
受入基準を「フェーズ別」に分割し、段階的に検収する方式を採用。
| フェーズ | 主な基準 | 検収タイミング |
|---|---|---|
| 要件定義 | 業務フロー図が現行業務と一致、例外パターン網羅率 95%以上 | 3ヶ月目 |
| 設計 | 画面遷移図が要件定義書と整合、レビュー指摘対応率 100% | 6ヶ月目 |
| 開発 | 単体テスト合格率100%、結合テスト合格率 98%以上 | 12ヶ月目 |
| 総合テスト | 全業務シナリオ250件を実行し合格率 100% | 15ヶ月目 |
| 移行・本番 | データ移行件数の差異0件、本番稼働後1ヶ月の重大障害0件 | 18ヶ月目 |
最終的に開発フェーズで結合テスト合格率が96.2%となり1回差し戻しが発生したが、基準が明確だったため「どこを直せばいいか」が即座に特定でき、予定より2週間の遅延で収まった。前回プロジェクトの半年遅延と比べれば大幅な改善となっている。
やりがちな失敗パターン#
- 基準が曖昧なまま着手する — 「高品質であること」のような定性的な基準は検収時に揉める原因。必ず数値かYes/Noで判定できる形にする
- 基準を作るが合意しない — 片方だけが作った基準は「聞いていない」と拒否される。双方の署名・承認を必ず取る
- 全基準を最後にまとめて検収する — 大規模プロジェクトで最後に一括検収すると手戻りが巨大になる。フェーズごとの段階検収が有効
- 基準を途中で更新しない — 要件変更があったのに基準が古いまま。変更管理プロセスと受入基準の更新を連動させる
よくある質問#
Q: 「高品質」や「使いやすい」といった曖昧な表現をどう数値化しますか？ A: 「高品質」であれば「バグ件数：リリース後30日以内に重大バグ0件」、「使いやすい」であれば「ユーザビリティテストで5人中4人が迷わず目的の操作を完了できること」のように、観察・計測できる形に変換します。「どうなったらOKと言えるか？」を依頼者に問い返すことが基準の具体化につながります。
Q: 受入基準は着手前に合意することがなぜ重要なのですか？ A: 完成後に合意しようとすると、依頼者は「イメージと違う」という主観で評価し、受注者は「仕様通り作った」と主張するすれ違いが起きます。着手前の合意は双方の解釈を一致させる唯一の機会です。特に「非機能要件（速さ・安定性）」は後から追加すると手戻りが大きいため、事前確定が必須です。
Q: フェーズ別の段階検収はどのように設計しますか？ A: プロジェクトのフェーズ（設計→開発→テスト→リリース）ごとに「この時点で確認する基準」をあらかじめ定義します。例：設計フェーズ検収「画面モックが仕様書の機能を網羅している（Yes/No）」、開発フェーズ検収「単体テストカバレッジ80%以上」。各フェーズ末に検収を行うことで最終段階での巨大な手戻りを防ぎます。
Q: 要件変更があった場合、受入基準はどう更新すればよいですか？ A: 変更管理プロセス（変更要求書の起票・承認）と受入基準の更新を必ず連動させます。「口頭で変更を依頼した」だけでは基準が古いままになります。変更要求書に「影響する受入基準と更新内容」を記載し、双方が署名してから変更を着手するフローにすることで基準と実態のズレを防げます。
まとめ#
成果物受入基準は「何ができたらOKか」を事前に定量化し、関係者全員で合意する仕組み。機能要件・非機能要件・品質基準の3つの柱で基準を構成し、数値またはYes/Noで判定できる形に書く。検収時はその基準をチェックリストとして使い、合否を客観的に判定する。事前合意があれば「イメージと違う」という主観的な差し戻しを防げる。