Tsuzura

要件と受入条件の決め方

AIで開発を始める前に、要件・受入条件・テストケースの違いを整理し、一機能分の条件と確認方法を決める手順です。

公開日
更新日

要件は「何が必要か」を示し、受入条件は「どうなれば、その要件を満たしたと判断するか」を示します。実装を始める前に両方を決めておくと、人やAIが推測で補った部分と、関係者が決めた内容を分けられます。

作りたい動作を言葉で説明できても、どこまで実装すれば完成かは決まっていない人向けの記事です。読み終えると、一機能分の要件、対象外、受入条件、確認方法を一枚にまとめ、内容を関係者と確認して設計へ進める状態か判断できます。プログラミングの知識は前提にしません。画面設計、技術選定、テストコード、セキュリティ設計の詳細は扱いません。

なぜ要件と受入条件が必要なのか

要件と受入条件は、作る内容と完成の判定を、実装前にそろえるために必要です。どちらもないまま作り始めると、決まっていない部分を実装者が補うことになります。コードが動いても、必要な結果と違えば完成ではありません。

曖昧な要望のまま実装すると何が起きるか

「入力できるようにする」「使いやすくする」といった要望だけでは、対象となる利用者、入力できる条件、保存後の結果、失敗時の扱いが決まりません。人が実装してもAIが生成しても、空白には何らかの仮定が入ります。

仮定そのものが問題なのではありません。確認していない仮定が、決定済みの要件として実装されることが問題です。要件と受入条件を先に分ければ、決めたこと、まだ決めていないこと、完成時に確かめることが見えるようになります。変更が必要になったときも、どの条件と確認を更新するか追えます。

要件、受入条件、テストケース、テスト結果の違い

要件は、利用者が目的を達成するために必要な条件や能力、またはシステムが守る制約を表します（IEEE Computer SocietyのSWEBOK Guide）。

受入条件は、実装を受け入れるために満たす条件です。テストケースは、その条件を確かめるための具体的な前提、入力、操作、期待結果を定めます。テスト結果は、実際に確かめて得た記録です。

利用者の立場から必要な機能を短く記したものを「ユーザーストーリー」と呼びます。受入条件をもとに実装とテストへ進む方法の一つに、受入テスト駆動開発（ATDD）があります（ISTQB Foundation Level Syllabus v4.0.1）。開発方法によって呼び方や順序は異なりますが、この記事では次の問いで区別します。

用語 答える問い 記録する内容
要望 何をできるようにしたいか 最初に出た希望や困り事
要件 何が必要か 必要な能力、結果、制約
受入条件 どうなれば満たしたと言えるか 合否を決める条件と期待結果
テストケース 何をどう確かめるか 前提、入力、操作、期待結果
テスト結果 実際にどうなったか 実行結果、差異、合否の証拠

受入条件は要件を詳しく記すためにも使えるため、要件と受入条件が必ず別々の文書になるとは限りません（SWEBOK Guide）。この記事では、書類の名前ではなく、答える問いと判断の順序を区別します。

要件を一つに絞る

最初に、一回の実装で達成する結果を一つに絞ります。一つの要件につき、一つの合否を判定できる大きさにすると、どこまで作り、何を確かめればよいかを説明しやすくなります。

利用者、必要な結果、理由を決める

人が使う機能では、利用者、必要な行動や結果、その理由を分けます。ユーザーストーリーの代表的な書式も、この三つでできています（GOV.UK Service Manual）。決まった言い回しを使う必要はありません。

  • 利用者：誰が使うのか
  • 必要な結果：何をできるようにするのか
  • 理由：その結果が何のために必要なのか

別のシステムやスケジュールから始まる処理では、それを「利用者」ではなく「起点」として記録します。理由を説明できない場合は、必要な結果より実装方法が先に決まっている可能性があります。

今回の対象と対象外を分ける

対象には、今回完成させる結果だけを書きます。関連していても今回は作らないものは、対象外として残します。書かずに省くと、実装中に追加すべきか判断できません。

入力、出力、利用できる人、既に決まっている制約も確認します。ただし、必要な理由がない画面形式、ライブラリ、データベース製品まで先に固定する必要はありません。要件には、実現方法ではなく必要な結果を書きます（NASAの要件記述ガイド）。互換性や規則によって方法を固定する必要があるなら、制約と理由を一緒に記録します。

一つの項目に複数の合否判断が混ざっていないかも確認します。一部が成功しても別の部分が失敗し得るなら、別の要件へ分けたほうが判定しやすくなります。

制約、仮定、未決事項を分ける

ここでは、作業中の情報を次のように区分します。これは本記事で使う整理であり、すべての組織に共通する文書規格ではありません。

  • 制約：守る必要があると確認できており、理由を説明できる条件
  • 仮定：現時点では正しいと置いているが、まだ確認していない前提
  • 未決事項：選択肢や判断する人が残っている項目
  • 対象外：今回は扱わないと決めた範囲

四つを同じ欄へ混ぜないことが大切です。未決の値には、理由、解決するための行動、責任者、期限を残します（NASAの要件記述ガイド）。本記事では、選択肢が残る未決事項にも同じ四点を記録します。仮定は、未確認であることを明記して確認します。

ここでいう判断者は、必要な結果と受入可否を決める責任や権限を持つ人です。低リスクな個人試作では、作る本人が判断者になる場合もあります。未決事項が受入条件、権限、扱うデータ、費用、公開範囲に影響するなら、判断者が決めるまで次へ進みません。影響しない場合は、誰がいつ決めるかを残します。停止する範囲は、リスクと組織の規則に合わせます。

受入条件を書く

受入条件には、外から確かめられる状態や結果を書きます。「適切に動く」「使いやすい」のように人によって判定が変わる言葉だけでは、合否を決められません。

外から確認できる結果を書く

開始状態によって結果が変わる場面を書く場合は、前提、操作や出来事、期待結果が分かるようにします。規則を箇条書きや表でまとめる場合は、一つの文へすべてを詰め込みません。必要な前提、操作、期待結果をそれぞれ別の項目として追えるようにします。内部のクラス名や関数名ではなく、利用者、接続先、記録、通知などに現れる結果を中心にします。

要件を満たしたかは、テストだけでなく、実演、成果物の検査、計算やモデルによる分析でも確かめられます。受入条件は、これらの方法で満たしたと示せる状態にします（NASAの要件記述ガイド）。

関係する拒否、失敗、権限差を選ぶ

正常に進む条件だけでは、入力や外部処理が予定どおりでない場合に完成と判断できません。ユーザーストーリーの受入条件には、成立する場面と、成立しない・拒否される場面の両方を含めます（ISTQBのシラバス）。

次の表では、成立する場合を「通常」、成立しない場合を「拒否」と「失敗」に分け、結果を変える「権限」も別に確認します。これは小さな一機能向けに本記事で整理した観点です。標準で定められた分類ではなく、すべての例外を網羅するものでもありません。今回の利用場面で結果が変わるものだけを選びます。

観点 決める内容
通常 条件がそろったときの結果
拒否 入力不足や業務条件不成立のとき、何を変更せず何を返すか
失敗 外部処理等が失敗したとき、成功扱いにせず次に何をできるか
権限 実行できる主体と、できない主体に対して何を変更しないか

すべての機能に四種類をそろえる必要はありません。利用者への結果やリスクが変わる条件に絞ります。

個人情報、決済、認証、外部への書き込みが関わる場合は、本記事の受入条件だけで実装開始を判断しません。組織の規則に従ってセキュリティ要件、権限、承認者を別に決め、適切な責任者がいない場合はここで止めます。

一般的な開発工程だけではセキュリティを詳しく扱わない場合があります。そのため、安全な開発の実践を工程へ組み込む必要があります（NIST SP 800-218）。

書式は内容に合わせて選ぶ

ユーザーストーリーの受入条件には複数の書式があります。場面を表す書式、箇条書きや入出力表で規則を表す書式、明確で曖昧でなければ独自の書式も使えます（ISTQBのシラバス）。

短い結果なら箇条書きで足ります。開始状態によって結果が変わるなら「前提（Given）・操作（When）・期待結果（Then）」に分け、入力の組み合わせが多いなら表が向いています。Given・When・Thenは任意の書式であり、使っただけで条件が完全になるわけではありません。

確認方法を対応づける

受入条件ごとに、誰が何を使って確かめ、どの結果なら合格かを対応づけます。方法を書けなければ、受入条件が曖昧か、必要な環境や資料がまだない可能性があります。

テスト、実演、検査、分析から選ぶ

確認方法は、次の四つから選びます（NASAのProduct Verification）。

  • テスト：決めた条件で実際に処理を動かし、得たデータを期待値と比べる
  • 実演：実際に操作し、必要な動作を確認する。テストほど詳細なデータ取得を前提にしない
  • 検査：画面、設定、文書、記録などを見て、決めた特徴があるか確かめる
  • 分析：計算、モデル、または既に得た検証結果を使って判定する

一つの受入条件に複数の方法を組み合わせても構いません。自動テストだけが確認方法ではありません。一方、変更のたびに同じ確認が必要な条件は、繰り返し可能な手順にし、自動化できるかを検討します。

受入条件からテストケースを作る

ユーザーストーリーを受入テスト駆動開発（ATDD）で進める場合、受入条件から、前提、入力、操作、期待結果を具体化したテストケースを作り、手動または自動で実行します（ISTQBのシラバス）。この記事ではATDDを前提としませんが、確認方法を具体化するときにも、受入条件とテストケースを同じように区別します。

一つの受入条件に、条件や入力の組み合わせに応じて複数のテストケースを対応させる場合があります。数を一対一にそろえることより、どの受入条件をどの確認が支えるか追える状態を優先します。

テスト結果を合否判断へ戻す

実行後は、実際の結果と期待結果の差を記録します。差があれば、実装の問題なのか、受入条件の不足なのか、要件自体を見直すのかを判断します。

テストが通ったことは、書かれた条件を満たす証拠です。要件が利用者の目的に合っていることや、書かれていない安全条件まで証明するものではありません。判断者が結果を確認し、受入、修正、要件の見直しを選びます。

一枚の要件メモにまとめる

次の書式は、ここまでの定義と確認項目を、一機能分の記録にまとめた本記事独自のものです。標準で定められた必須様式ではありません。項目を埋めることではなく、実装者と判断者が同じ結果を想定できる状態を作るために使います。

# 機能名

## 利用者の目的
- 利用者または起点:
- 必要な結果（合否を一つに絞る）:
- 必要な理由:

## 範囲
- 今回の対象（今回完成させる結果だけ）:
- 今回の対象外:
- 入力:
- 出力:
- 制約（確認した根拠と理由も記す）:

## 仮定と未決事項
- 仮定（未確認と明記する）:
- 確認する人・期限:
- 未決事項:
- 判断する人・期限:
- 未決のままなら次へ進まない条件:

## 受入条件
- 受入条件1（必要なら前提・操作・期待結果に分ける）:
- 受入条件2:

## 確認計画（実装前）
| 受入条件 | 確認方法 | 期待結果 | 確認する人 |
|---|---|---|---|
| 受入条件1 |  |  |  |

## 実装前の判断
- 要件レビューへ進む / 判断者へ戻す
- 判断日:
- 判断者（次へ進む可否を決める責任・権限を持つ人）:

## 要件レビュー結果
- 設計へ進む / 実装へ進む / 判断者へ戻す
- 判断日:
- 判断者:

## 確認結果（実装後に記入）
| 受入条件 | 実際の結果 | 判定 | 証拠の場所 |
|---|---|---|---|
| 受入条件1 |  | 合格 / 不合格 |  |

## 受入判断（実装後）
- 受け入れる / 修正する / 要件を見直す
- 判断日:
- 判断者（受入可否を決める責任・権限を持つ人）:

受入条件の数は固定しません。必要な結果を重複なく判定でき、現在の利用場面に関係する拒否や失敗も確認できる数にします。記入中に対象が増えたら、一回の実装を分けられないか見直します。

AIへ渡す

AIを使う場合、本記事では一枚の要件メモを一回分の作業として渡します。目的、対象、対象外、受入条件、制約、確認方法を分け、未決事項を推測で補わないよう明記します。

AIへ渡す作業には、解く問題、合否を判断できる受入条件、変更対象の指示を含めます。この書き方は、GitHub上のコード一式を調べて変更するAI機能であるGitHub Copilot cloud agentの公式ガイドにも示されています。これはCopilot固有の推奨であり、すべてのAIに共通する仕様ではありません。

関連するファイルや既存の決まりが分かるなら、その場所も示します。分からない場合は、AIに調査結果を先に出させ、変更前に人が対象を確認します。

Copilot cloud agentはコードや機密情報へアクセスし得るため、生成した変更を人が確認してからプロジェクトへ取り込みます（リスクと対策の説明）。他のAIを使う場合も、その製品が読める情報、使える道具、変更できる範囲、承認の仕組みを個別に確認します。

未確定の業務判断をAIに補わせたまま反映しません。また、認証、個人情報、本番環境に関わる重要な変更は、必要な責任者が確認するまで反映しません。生成後は、受入条件に対応する確認を実行し、変更内容が目的と既存の設計に合うかを人が見ます。テストとは別に、要件、既存のコードの分け方、プロジェクトの目的への適合も確認します（GitHubのAI生成コードのレビューガイド）。

次の工程へ進むか判断する

要件レビューでは、判断者が要件メモの内容に矛盾がないか、未決事項、受入条件、確認方法に漏れがないかを確かめ、「設計へ進む」「実装へ進む」「判断者へ戻す」のどれかを記録します。次の項目を説明できれば、そのレビューへ進めます。

  • 利用者または起点、必要な結果、理由が決まっている
  • 今回の対象と対象外を分けている
  • 一つの要件に複数の合否判断を混ぜていない
  • 実現方法を固定する制約には、確認した根拠と理由がある
  • 仮定と未決事項に、確認する人と期限がある
  • 受入条件から、外から確かめられる期待結果を判断できる
  • 関係する拒否、失敗、権限差を確認している
  • 受入条件ごとの確認方法と判断者が決まっている

この一覧だけで実装開始や安全性が保証されるわけではありません。

実現可能性、性能、セキュリティ、プライバシー、運用、法令、組織の承認など、機能に応じて別の確認が必要です。結果やリスクを左右する未決事項が残る場合や、適切な判断者がいない場合は、次へ進みません。

データ構造、認証、外部連携、性能などを決める必要がある場合は、要件メモへ詳細を詰め込まず、該当する設計へ進みます。コードの分け方を決める段階では、コードアーキテクチャの種類と選び方を参照できます。設計を追加せずに実装できる範囲でも、組織の手順や責任者の承認が必要なら、それを先に完了します。

画面だけで完結するか、バックエンド、保存先、外部サービスが必要かを分ける場合は、作りたいサービスに必要な仕組みを決めるへ進みます。

要件と受入条件は、一度決めたら変えられない契約ではありません。新しい事実が分かったら、変更理由、影響する受入条件、確認方法を更新します。変更内容の判断を実装者やAIの推測に委ねず、人が決めた内容として残します。

出典