このユニットの結論
要望は「こうしてほしい」という声、要件は「システムが何をすべきかとして合意し、確かめられる形にしたもの」です。
要望をそのまま作ると、作る人ごとに解釈が変わります。要望を要件に変える作業が、要件定義の中心です。
1. 何の話か
このユニットは、要件定義の入口の話です。
業務部門からは、たくさんの声が上がります。
- 「請求を早く出したい」
- 「入力の手間を減らしたい」
- 「間違いに気づけるようにしたい」
これらは大切な要望です。しかし、このままでは、何を作ればよいか、完成したかどうかをどう確かめるかが決まりません。
2. なぜ必要か
要望のまま開発に渡すと、
- 開発者が自分の解釈で作る
- 業務部門は「思っていたものと違う」と感じる
- テストで何を確かめれば合格なのか分からない
ということが起きます。
要件にするとは、誰が読んでも同じ意味になり、確かめられる形にすることです。
3. このユニットで分かること
- 要望と要件の違い
- 要望を要件に変えるときに確認すること
- 要件の整理で、AIが支援できることと人間が決めること
4. 要望を要件に変える
| 要望 | 要件 | |
|---|---|---|
| 形 | 「こうしてほしい」という声 | 「システムは〜する」という決まりごと |
| 主語 | 困っている人 | システム（または業務） |
| 確かめ方 | 決まっていない | テストや確認で確かめられる |
| 状態 | 出された段階 | 関係者が合意し、確定した段階 |
例（教材上の例）:
- 要望：「請求を早く出したい」
- 要件の候補：「承認済みの取引から、請求データを作成できること」
- さらに確認すること：「早く」とは何日以内か、誰がいつ使うか、対象の取引はどれか
要望の背景にある「なぜ困っているか」を聞くと、本当に必要な要件が見えてきます。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件の要件と業務
- 約1,500件の要件
- 業務リーダー：P-005 藤本 遥（経理業務リーダー）、P-006 川村 美咲（プロジェクト管理業務リーダー）、P-007 松本 健太（営業・契約業務リーダー）
- AIへ最終委任しないことの一つに「要件確定」がある
アステリア案件の個々の要件の内容は、正本に記載がありません。未確定 このユニットの例は、すべて教材上の例です。
5. THINK — 「使いやすくしてほしい」
業務部門から「新しい画面は、今より使いやすくしてほしい」という要望が出ました。
問題
これを、そのまま要件一覧に載せてよいでしょうか。
判断例を開く
判断
そのままでは要件になりません。
確認すること:
- 今、どの作業で、何に困っているのか
- 誰が、どのくらいの頻度で使うのか
- 「使いやすい」を、どう確かめるのか（入力項目の数、操作の手順、間違いの起きにくさなど）
要望の背景を聞き、確かめられる形に言い換えます。
6. よくある失敗
- 要望をそのまま要件一覧に写す
- 「〜できること」とだけ書き、対象や条件がない
- 要望を出した人だけで決め、影響を受ける他部門に確認しない
- 合意した日と合意した人を残さない
7. 成果物との接続
- REQ-002 要件一覧：要件を一覧にして管理する
- REQ-006 要件確定記録：いつ、誰が、どの要件を確定したかを残す
危機演習 CR01 要件定義が終わらない では、要件定義が終わらない状況を体験します（学習上の接続です。正式な対応関係ではありません）。
8. AI WORKFLOW — 要望を要件の候補に言い換えさせる
AIは、話し言葉の要望を、要件の形に言い換える下書きに役立ちます。会議記録から要望を抜き出させることもできます。
指示例:
「次の要望を、『システムは〜する』という形の要件候補に言い換えてください。あいまいな言葉（早く、使いやすく、など）には、確認すべき質問を付けてください。数値や対象は推測で決めないでください。」
9. REVIEW — AIの言い換えを確認する
- 元の要望の意図から、ずれていないか
- AIが数値や対象を勝手に決めていないか
- 1つの要望が、複数の要件に分かれるべきではないか
- 要望を出した人に、言い換えを確認したか
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 良い要件の性質と、あいまいな言葉の検査
要件が満たすべき性質
要件には、満たすべき性質があります。世界で共有されている要件工学の国際規格（ISO/IEC/IEEE 29148）では、おおむね次のように整理されています。
- 必要である：この要件がないと、業務または目的が成り立たない
- 明確である：読む人によって解釈が変わらない
- 確かめられる：テストや確認で、満たしたかどうかを判定できる
- 実現できる：技術・費用・期間の範囲で作れる
- 1 つである：1 件の要件に、複数のことが混ざっていない
- 追跡できる：出どころ（要望、業務の場面）と、先（設計、テスト）がたどれる
要件一覧の 1 件ごとに、この性質で点検すると、要望のまま混ざっているものが見つかります。
あいまいな言葉を機械的に探す
「速く」「使いやすく」「適切に」「必要に応じて」「など」「可能な限り」。こうした言葉は、要件の中では解釈を読む人に委ねます。一覧をこの言葉で検索し、1 件ずつ、数値か条件か、確かめる方法に置き換えます。置き換えられないなら、まだ要件ではなく要望です。
受け入れ基準を添える
「確かめられる」を具体にする方法として、要件ごとに受け入れ基準を添えます。世界で共有されている書き方の 1 つは、「前提（この状態で）・操作（これをしたら）・結果（こうなる）」の 3 つで書く形です。この形で書けない要件は、何を確かめるかが決まっていません。
測り方の例
- 要件一覧のうち、あいまいな言葉を含む件数
- 受け入れ基準が添えられている要件の割合
- 1 件に複数のことが混ざっている要件の数
現場で確かめる問い
- 要件一覧を、あいまいな言葉で検索したことがあるか。何件あるか
- 受け入れ基準が添えられている要件は、全体のどれくらいか
- 「1 件に 1 つ」になっていない要件を、分けているか
- 要件の性質の点検を、誰が、どの時点で行っているか
アステリア案件の要件一覧で、あいまいな言葉の点検や受け入れ基準の有無がどうだったかは、正本に記録がありません。記録なし
10. 人間が判断すること
- どの要望を要件として採用するか
- 要件の内容を確定するか
- 複数の部門の要望がぶつかるとき、どちらを優先するか
要件確定は、AIへ最終委任しない事項です（正本の方針）。
11. 判断演習
次の要望を、要件の候補に言い換えてみてください。あわせて、業務部門に確認する質問を3つ書いてください。
「月末の作業をもっと楽にしたい」
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
要望は出発点、要件は合意して確かめられる約束です。
要望の背景を聞き、誰が読んでも同じ意味になる形に変えることが、要件定義の仕事です。