システム開発では、完成後になって、
「仕様どおり作ったはずなのに、発注者からOKが出ない」
「どこまでできれば完成なのか決まっていなかった」
「使いやすくしてほしいと言ったが、期待していたものと違った」
といった問題が起きることがあります。
こうした認識ズレを防ぐために重要なのが受入条件です。
受入条件とは、簡単に言えば、
「何ができれば、この要件を満たしたと判断するのか」
を具体的に決めたものです。
例えば、
「顧客検索機能を作る」
だけでは、完成条件が曖昧です。
そこで、
- 顧客名で検索できる
- 電話番号で検索できる
- 顧客名は部分一致検索できる
- 該当データがない場合は0件と表示する
- 一般ユーザーは閲覧権限のある顧客のみ検索結果に表示される
まで決めれば、完成したかどうかを判断しやすくなります。
この記事では、業務システム・Webシステム開発を想定して、受入条件の決め方、具体例、受入テストとの違い、よくある失敗まで解説します。
受入条件とは
受入条件とは、機能やユーザーストーリーについて、発注者が受け入れ可能と判断するための具体的な条件です。
例えば、ユーザーストーリーが、
営業担当者として、顧客を検索したい。問い合わせ時に対象顧客をすぐ確認したいから。
だったとします。
これだけでは、
「顧客検索とはどこまでできればよいのか」
が分かりません。
そこで受入条件として、
- 顧客名で検索できる
- 電話番号で検索できる
- メールアドレスで検索できる
- 顧客名は部分一致に対応する
- 検索結果から顧客詳細へ移動できる
と定義します。
これにより、発注者・開発者・テスターが同じ完成イメージを持ちやすくなります。
受入条件を決める目的
受入条件の目的は、細かい仕様を増やすことではありません。
重要なのは、
「完成したかどうかを客観的に判断できる状態を作ること」
です。
例えば、
使いやすい顧客検索画面にする
という要件では、人によって「使いやすい」の基準が違います。
一方、
顧客名・電話番号・担当者を条件に検索できる
なら、満たしているか確認できます。
システム開発では、できるだけ「感覚」ではなく「確認可能な条件」へ変えることが重要です。
受入条件と機能要件の違い
受入条件と機能要件は似ています。
整理すると、
機能要件
システムで何ができる必要があるか
受入条件
その機能ができたと、どう判断するか
です。
例えば、
機能要件
顧客を検索できること。
受入条件
- 顧客名で検索できる
- 電話番号で検索できる
- 担当者で検索できる
- 複数条件を組み合わせられる
- 条件をクリアして再検索できる
となります。
受入条件は、機能要件を検証可能な状態まで具体化するものと考えると分かりやすいでしょう。
受入条件と受入テストの違い
こちらも混同されやすいポイントです。
受入条件
何を満たせばOKなのかを決めます。
例えば、
顧客名の部分一致で検索できる。
受入テスト
その条件を実際に満たしているか確認します。
例えば、
前提
「株式会社ABC」が登録されている。
操作
検索欄へ「ABC」と入力して検索する。
期待結果
検索結果に「株式会社ABC」が表示される。
つまり、
受入条件＝合格基準
受入テスト＝合格基準を確認する作業
です。
受入条件の決め方7ステップ
受入条件は、いきなりテスト項目から考えるのではなく、要件から順番に具体化すると整理しやすくなります。
STEP1｜業務上の目的を確認する
まず、
「なぜこの機能が必要なのか」
を確認します。
例えば顧客検索なら、
問い合わせがあったとき、顧客情報を短時間で確認したい。
という目的があります。
目的が分かれば、必要な検索条件も考えやすくなります。
STEP2｜ユーザーを明確にする
誰が利用するかを整理します。
例えば、
- 営業担当者
- 営業管理者
- システム管理者
です。
同じ顧客検索でも、権限によって検索可能範囲が異なる場合があります。
STEP3｜正常系を整理する
まず、通常どおり操作した場合の条件を決めます。
例えば、
- 顧客名で検索できる
- 電話番号で検索できる
- 検索結果を一覧表示する
- 顧客詳細を開ける
などです。
STEP4｜例外系を整理する
次に、通常とは違うケースを確認します。
例えば、
- 該当データがない
- 入力値が不正
- 必須項目が未入力
- 重複登録
- データが削除済み
などです。
業務システムでは、正常系だけでは受入条件として不十分なことがあります。
STEP5｜権限を確認する
例えば、
一般営業担当者は自部署の顧客のみ検索可能
営業管理者は全部署の顧客を検索可能
とします。
機能自体は動いていても、権限制御が正しくなければ業務システムとして受け入れられない場合があります。
STEP6｜非機能条件が必要か確認する
例えば、
顧客検索できる
だけでなく、
通常利用時は3秒以内に検索結果を表示する
という性能条件が必要な場合があります。
ほかにも、
- 同時利用
- セキュリティ
- ログ
- バックアップ
などが受入に関係する場合があります。
STEP7｜誰でも判定できる表現にする
最後に、
OKかNGか判断できるか
を確認します。
例えば、
素早く表示する
では判断できません。
通常利用時に3秒以内に表示する
なら判断できます。
良い受入条件の5つの特徴
1．具体的である
悪い例：
分かりやすく表示する。
良い例：
顧客一覧に顧客名、担当者、電話番号、最終対応日を表示する。
2．テスト可能である
悪い例：
十分な検索性能を持つ。
良い例：
通常利用時、検索結果を3秒以内に表示する。
3．利用者が明確である
悪い例：
顧客情報を編集できる。
良い例：
営業担当者は、自分が担当する顧客情報を編集できる。
4．正常系だけではない
例えば、
顧客を登録できる
だけでなく、
必須項目が空欄の場合は登録できず、対象項目にエラーを表示する
まで考えます。
5．必要以上に実装方法を固定しない
例えば、
PostgreSQLの○○機能を使って検索する
まで書く必要は通常ありません。
発注者側で重要なのは、
何ができれば受け入れられるか
です。
技術的な実現方法は設計で決められる場合があります。
顧客管理システムの受入条件例
ユーザーストーリー
営業担当者として、顧客を検索したい。問い合わせ時に対象顧客をすぐ確認したいから。
受入条件
- 顧客名で検索できる
- 電話番号で検索できる
- メールアドレスで検索できる
- 顧客名は部分一致検索できる
- 複数条件を組み合わせられる
- 検索結果に顧客名・担当者・電話番号を表示する
- 該当する顧客が存在しない場合は0件と表示する
- 一般ユーザーには閲覧権限のある顧客のみ表示する
ここまで決まれば、完成条件がかなり明確になります。
在庫管理システムの受入条件例
ユーザーストーリー
倉庫担当者として、商品の現在庫を確認したい。出庫可能な数量を判断したいから。
受入条件
- 商品コードで検索できる
- 商品名で検索できる
- 拠点別在庫を確認できる
- 現在庫数を表示する
- 引当済数量を表示する
- 利用可能数量を表示する
- 在庫0の商品も表示できる
- 権限のない拠点の在庫は表示しない
予約システムの受入条件例
ユーザーストーリー
利用者として、空いている日時を予約したい。
受入条件
- 予約可能な日時を一覧表示する
- 満席の日時は予約できない
- 名前・メールアドレス・人数を入力できる
- 必須項目が未入力なら登録できない
- 予約完了後に完了画面を表示する
- 予約完了メールを送信する
- 定員を超える人数では予約できない
承認ワークフローの受入条件例
ユーザーストーリー
上司として、部下から提出された申請を承認したい。
受入条件
- 自分が承認者となっている申請を一覧表示できる
- 申請内容を確認できる
- 承認できる
- 差し戻しできる
- 差し戻し時はコメント入力を必須とする
- 承認済み申請を再度承認できない
- 承認日時・承認者を記録する
ログイン機能の受入条件例
「ログインできる」だけでも、複数条件があります。
例えば、
- 正しいメールアドレス・パスワードでログインできる
- パスワードが誤っている場合はログインできない
- 存在しないユーザーではログインできない
- 無効化されたユーザーではログインできない
- ログイン成功後はダッシュボードへ移動する
- 未ログイン状態では認証必須画面へアクセスできない
などです。
CRUDだけでは受入条件として足りない場合がある
業務システムでは、
「登録・参照・更新・削除できる」
だけでは実務上の条件が不足することがあります。
例えば顧客削除について、
顧客を削除できる
とします。
しかし業務上、
「取引履歴のある顧客は削除してはいけない」
というルールがあるかもしれません。
その場合、
- 取引履歴がない顧客は削除できる
- 取引履歴がある顧客は削除できない
- 削除できない理由を画面に表示する
まで受入条件にします。
重要なのは、データ操作ではなく業務ルールまで確認することです。
Given／When／Thenで受入条件を書く
複雑な受入条件は、Given／When／Then形式で整理できます。
例：満席の予約
Given
定員10名のイベントに10名予約済みである。
When
別の利用者が1名で予約を実行する。
Then
予約は登録されず、「満席のため予約できません」と表示される。
日本語で、
前提条件
定員10名で、現在10名予約済み。
操作
1名で予約する。
期待結果
予約できず、満席メッセージが表示される。
としても構いません。
現場担当者が理解しやすい形式を使います。
【コピペ用】受入条件テンプレート
■ 要件ID
FR-
■ ユーザーストーリーID
US-
■ 機能名
○○機能
■ 利用者
○○担当者
■ 目的
○○するため
■ 受入条件
AC-01：
AC-02：
AC-03：
AC-04：
■ 正常系
・
■ 例外系
・
■ 権限
・
■ 性能・非機能
・
■ 未決事項
・
■ 判定
□ OK
□ NG
□ 条件付きOK
受入条件を一覧管理する方法
ExcelやGoogle Sheetsなら、例えば次の形式で管理できます。
| ID | 要件ID | 受入条件 | 優先度 | 状態 |
|---|---|---|---|---|
| AC-001 | FR-010 | 顧客名で検索できる | Must | 確定 |
| AC-002 | FR-010 | 電話番号で検索できる | Must | 確定 |
| AC-003 | FR-010 | 3秒以内に結果表示 | Should | 検討中 |
要件IDと紐付けると、どの条件がどの機能に対応しているか追跡しやすくなります。
ユーザーストーリーから受入条件を作る方法
例えば、
営業担当者として、顧客の過去の対応履歴を確認したい。担当変更後もスムーズに対応したいから。
というユーザーストーリーがあります。
まず、
「何が見られれば業務目的を達成できるか」
を考えます。
すると、
- 対応日時
- 担当者
- 対応方法
- 対応内容
が必要だと分かります。
さらに、
- 新しい順に表示する
- 100件以上でもページ分割して確認できる
- 閲覧権限のあるユーザーだけ表示できる
などを整理します。
つまり、
ユーザーストーリー → 業務上必要な状態 → 受入条件
と具体化します。
受入条件はいつ決める？
理想的には、開発開始前に主要な受入条件を整理します。
例えば、
業務要件
↓
ユーザーストーリー
↓
機能要件
↓
受入条件
↓
設計
↓
開発
↓
受入テスト
という流れです。
開発完了後になって、
この機能はこう動くと思っていた
と条件を追加すると揉める原因になります。
ただし、プロトタイプ・レビューなどで新しい要件が分かった場合は、受入条件を更新することもあります。
重要なのは、変更を関係者で合意して管理することです。
受入条件を誰が決める？
開発会社だけで決めるものではありません。
例えば、
- 業務担当者
- 発注側責任者
- PM
- 開発担当
- テスト担当
などで確認します。
特に、
業務として本当に受け入れ可能か
を判断できるのは発注者側です。
一方、技術的に検証可能な条件へ整理するには開発者・SEの知識も必要です。
そのため双方で合意することが重要です。
受入条件と検収条件の関係
システム開発では、受入条件と合わせて「検収」という言葉も使われます。
受入条件は、
個々の機能・要件を満たしたか判断する基準
として使われます。
一方、検収条件は、
契約上、成果物全体を受領・検収する条件
として扱われる場合があります。
例えば、
- 必須機能の受入テストがすべて合格
- 重大障害が0件
- 指定成果物がすべて納品済み
などです。
請負開発などでは、契約上の検収条件と各機能の受入条件を整合させておくことが重要です。
「バグが1件でもあったら受入不可」は適切？
案件によりますが、すべての不具合を同じ扱いにすると判断しにくくなります。
例えば、
Critical
ログインできずシステム全体を利用できない。
Major
主要業務を完了できない。
Minor
表示位置が数pxずれている。
では影響が大きく異なります。
そこで、
Critical・Majorが0件であること
Minorは対応期限を合意したうえで受入可能
など、障害レベルごとの扱いを決める方法があります。
受入条件でよくある失敗
失敗1｜「正常に動くこと」で終わる
何をもって正常とするのか分かりません。
具体的な結果へ分解します。
失敗2｜「使いやすいこと」と書く
主観的で判定できません。
操作数や表示内容など、確認可能な条件へ落とします。
失敗3｜正常系だけ決める
エラー・差し戻し・満席・重複などの例外条件も整理します。
失敗4｜権限を忘れる
機能が動くだけでなく、適切なユーザーだけが操作できることも重要です。
失敗5｜非機能要件を無視する
検索結果が30秒かかっても「検索できる」ことにはなります。
業務上必要なら性能条件も決めます。
失敗6｜開発終了後に受入条件を追加する
発注時・要件定義時に合意していない条件を後から追加するとトラブルになりやすくなります。
失敗7｜細かく決めすぎる
内部実装まで固定すると、開発側の設計自由度を不必要に奪う可能性があります。
受入条件は原則として、
利用者から見て何ができるか
を中心にします。
要件の優先度によって受入条件も整理する
例えば、
Must
- 顧客名で検索できる
- 電話番号で検索できる
Should
- 担当者で絞り込める
Could
- よく使う検索条件を保存できる
とします。
これによって、初回リリース時に、
「何が満たされていないと受け入れられないのか」
を明確にできます。
受入条件から受入テスト項目を作る
例えば受入条件が、
顧客名の部分一致で検索できる
なら、テスト項目は、
| 項目 | 内容 |
|---|---|
| 前提 | 株式会社ABCが登録済み |
| 入力 | ABC |
| 操作 | 検索ボタンを押す |
| 期待結果 | 株式会社ABCが表示される |
となります。
つまり、受入条件が具体的であれば、受入テストも作りやすくなります。
逆に、テスト項目が作れない受入条件は、まだ曖昧な可能性があります。
受入条件をレビューするチェックリスト
【基本】
□ 誰が利用するか明確か
□ 何を実現する要件か明確か
□ 業務目的とつながっているか
【判定可能性】
□ OK／NGを判断できるか
□ 曖昧な言葉が残っていないか
□ 数値化できるものは数値化したか
【業務】
□ 正常系を確認したか
□ 例外系を確認したか
□ 承認・差し戻しを確認したか
□ 業務ルールを反映したか
【権限】
□ 誰が閲覧できるか決めたか
□ 誰が登録・更新できるか決めたか
□ 操作できない場合も確認したか
【非機能】
□ 必要な性能条件を決めたか
□ セキュリティ条件を確認したか
□ ログ等の条件を確認したか
【管理】
□ 要件IDと紐付いているか
□ 優先度が決まっているか
□ 関係者でレビューしたか
□ 未決事項を分離したか
受入条件に関するよくある質問
受入条件はすべての機能に必要ですか？
すべてを同じ詳細度で書く必要はありません。
ただし、業務上重要な機能、認識ズレが起きやすい機能、複雑な業務ルールを持つ機能には明確な条件を設定した方がよいでしょう。
受入条件は何個くらい書けばよいですか？
件数に決まりはありません。
「完成したか判断できるだけの条件が揃っているか」で判断します。
大きすぎる場合は、ユーザーストーリーや機能自体を分割する方法もあります。
受入条件と仕様書は同じですか？
同じではありません。
仕様書はシステムの詳細な動作・画面・データなどを記載します。
受入条件は、その要件を満たしたか判断するための基準です。
受入条件を途中で変更できますか？
可能ですが、発注者・開発者で影響範囲を確認して合意することが重要です。
追加開発・スケジュール変更につながる場合があります。
発注者側で受入条件を全部作る必要がありますか？
必ずしもありません。
業務上必要な条件は発注者が提示し、開発会社と一緒にテスト可能な形へ具体化する方法があります。
hiro-dev-labの要件定義・業務システム開発支援
hiro-dev-labでは、Webシステム・業務システムについて、実装だけではなく要件整理から対応しています。
例えば、
- 現状業務ヒアリング
- As-Is・To-Be業務整理
- 業務要件整理
- ユーザーストーリー整理
- 機能要件整理
- 受入条件整理
- 画面一覧・プロトタイプ整理
- 非機能要件整理
- データ・権限設計
- Java・Python・TypeScriptによるWebシステム開発
などを検討できます。
例えば、
「必要な機能はある程度決まっているが、何をもって完成とするか決まっていない」
という場合でも、
業務目的 → ユーザーストーリー → 機能要件 → 受入条件 → 受入テスト
という流れで整理できます。
受入条件は「あとから文句を言うため」ではなく「開発前に完成を定義するため」のもの
受入条件で重要なのは、開発会社を厳しく評価することではありません。
本来の目的は、
発注者と開発者が、開発前に「ここまでできれば完成」と合意すること
です。
例えば、
顧客検索を作る
ではなく、
- 誰が使うのか
- 何で検索できるのか
- 何を表示するのか
- 0件の場合どうするのか
- どの権限まで見られるのか
- 必要なら何秒以内か
まで決めます。
受入条件を作るときは、
- 業務目的を確認する
- 利用者を決める
- 正常系を整理する
- 例外系を整理する
- 権限を整理する
- 必要な非機能条件を追加する
- 誰でもOK／NGを判断できる表現にする
という順番で考えると整理しやすくなります。
そして、その条件から受入テストを作成します。
「完成条件が曖昧なまま開発が進んでいる」
「発注者と開発会社の認識ズレを減らしたい」
「ユーザーストーリーから具体的な受入条件へ落としたい」
「要件定義から設計・開発まで相談したい」
といった段階からでも、業務上必要な条件を一つずつ整理できます。
要件定義・業務システム開発について相談する