要件定義

定義

要件定義とは、「ソフトウェアが満たすべき条件を、検証可能な形で特定し、関係者間で合意する活動」である。

認識を揃える活動は他にもある。デザインレビュー、キックオフミーティング、スプリントプランニング。いずれも「認識合わせ」ではある。要件定義がこれらと異なるのは、以下の3つの性質が同時に成立する点にある。

問題空間の記述：「何を解くか」を定める。「どう解くか」ではない

検証可能な合意基準の設定：「これを満たせば正しい」と判断できる条件を提供する

合意の根拠の明示：なぜその要件がその形になったのか、何を採り何を捨てたのかの判断根拠を残す。これにより、前提が変わったとき要件を再評価できる

デザインレビューは解決空間（どう作るか）を扱うため1つ目を満たさない。キックオフは方向性の共有であり、検証可能な条件までは設定しないため2つ目を満たさない。スプリントプランニングはスコープと完了の定義を扱うが、なぜその要件がその形になったかの判断根拠までは記録しないため3つ目を満たさない。3つの性質のうちどれかが欠ければ、それは要件定義ではなく別の活動である。

役割：なぜ必要か

ソフトウェアは目に見えない。建築なら模型を指差して「ここが違う」と言えるが、ソフトウェアにはそれがない。だから言葉と構造で完成像を共有し続ける必要がある。

要件定義が不在のまま開発を進めると、以下が起こる。

エンジニアが「言われた通り作った」と言い、PMが「そうじゃない」と言う

仕様変更が頻発し、影響範囲を誰も把握できなくなる

リリース後に「そもそも誰のために作ったのか」という問いが浮上する

すべて認識のズレが解消されないまま工程が進んだ結果である。

ただし、要件定義を行えばこれらが起こらないわけではない。要件定義書が存在するプロジェクトでも認識はズレる。重要なのは、ズレが生じたとき「何に立ち戻るか」の基準を持っているかどうかである。要件定義はズレを消す魔法ではなく、ズレを検出し修正するための基盤である。

構造：4つのレイヤー

要件定義は4つのレイヤーを同時に扱う。上から下への一方通行ではなく、相互にフィードバックし合う関係である。

code:mermaid

graph TD

P -->|"目的なき要求は<br>ただの思いつき"| D

D -->|"検証可能な条件に<br>変換する"| R

C -.->|"横断的に作用"| P

C -.->|"横断的に作用"| D

C -.->|"横断的に作用"| R

R -->|"矛盾の発見"| D

D -->|"目的の再検討"| P

style P fill:#4A90D9,color:#fff

style D fill:#7B68EE,color:#fff

style R fill:#E67E22,color:#fff

style C fill:#95A5A6,color:#fff

table:まとめ

レイヤー 中心の問い 例

目的 なぜ作るのか 「解約率を下げたい」「法改正に対応する」

要求 誰が何を望んでいるか 「管理者が従業員データをCSV出力したい」

要件 何を満たせば合意とするか 「管理者が従業員一覧画面から、最大10万件のデータを5秒以内にCSV出力できること。出力項目は氏名・部署・入社日とする」

制約 何に縛られるか 「個人情報保護法により、出力ログの90日間保持が必要」「既存APIとの互換性」「Q3までにリリース」

要求と要件の区別

上の表で、要求と要件は同じ「CSV出力」を扱っている。違いは検証可能性と合意精度にある。

要求は「誰が何を望んでいるか」の記述である。「CSV出力したい」は意図として理解できるが、完了判定ができない。何件まで対応するのか、どの項目を含むのか、何秒以内なのか。読み手によって解釈が分かれる

要件は要求を「合意・検証可能な条件」に変換したものである。「10万件を5秒以内」「出力項目は氏名・部署・入社日」と書けば、テスト可能であり、満たしたかどうかを客観的に判定できる

つまり要求→要件の変換とは、「解釈の余地を、合意によって狭めていく作業」である。要求が「何を望んでいるか」の表明であるのに対し、要件は「何をもって満たされたとするか」の定義である。

制約の横断性

制約は特定のレイヤーに属さない。予算・法令・技術的負債・スケジュールといった制約は、目的の範囲を狭め、要求の優先順位を変え、要件の粒度を変える。全レイヤーに横断的に作用する。上の例では、個人情報保護法という制約が「出力ログの90日間保持」という追加要件を生んでいる。制約は要件を増やすだけでなく、目的そのものを変えることもある。特にスケジュール（納期）は独特の二面性を持つ。法改正の施行日や契約上の納期は外部制約として要件に作用する一方、要件の量と複雑さから導出されるスケジュールは要件定義の出力でもある。入力と出力の両面を持つため、スケジュールは要件を最も頻繁に変形させる制約となる。

境界：要件定義でないもの

要件定義と設計・仕様の関係は、二項対立ではなくスペクトラム（連続的なグラデーション）である。

code:mermaid

graph LR

style A fill:#4A90D9,color:#fff

style B fill:#9B59B6,color:#fff

style C fill:#E74C3C,color:#fff

典型的な対比は以下の通りである。

table:まとめ

要件定義であるもの 要件定義でないもの

問題空間の定義（何を解くか） 解決空間の設計（どう解くか）

ステークホルダー間の合意形成 開発チーム内の技術的意思決定

目的・課題の分析結果 ユーザー発言のそのままの転記

検証可能な受け入れ基準 曖昧な期待や希望のリスト

前提の変化に応じて再評価される合意 一度確定したら変えない聖典

なぜ分けるのか。

1. 「何を」と「どう」を混ぜると、最初に思いついた実装案に固定され、より良い解決策が検討されなくなる

2. 読み手が違う。経営者向けとエンジニア向けを一つにすると、どちらにも読みにくくなる

3. 変更の影響判断ができなくなる。要件変更なのか仕様変更なのかを区別できなければ、判断コストが際限なく膨らむ

ただし、分離すべきは「成果物」であり「思考」ではない。実務では、設計の知識を参照しなければ要件を定義できない場面が頻繁にある。ER図を見せながらステークホルダーと合意形成することもある。重要なのは「混ぜるな」ではなく、「今この議論は要件の話か、設計の話かを全員が自覚している状態を保て」ということである。

境界領域：非機能要件の扱い

非機能要件はすべてが境界領域にあるわけではない。導出元によって性質が異なる。

問題空間から一意に導出できるもの：「データは日本国内のサーバーに保存すること」（法令由来）、「監査ログを1年間保持すること」（コンプライアンス由来）。これらは解決空間の知識がなくても、法令・制約・ビジネス要求から決定できる

問題空間で閾値は定まるが、妥当性の検証に解決空間の知識を要するもの：「応答時間は3秒以内」。ユーザー体験の観点から「これ以上は許容できない」という閾値はビジネス判断として設定できるが、「3秒が現実的か」の判断には技術的見積もりが必要になる

解決空間の知識なしには定義自体ができないもの：「可用性99.9%」は現行インフラの構成を知らなければ99.9%と99.99%の差がコストにどう影響するかわからず、合意の根拠を持てない。セキュリティ要件は脅威モデルという解決空間の知識がなければ「何から守るか」を定められない

先の4レイヤーで「10万件を5秒以内」を要件の例として挙げたが、この数値は2番目と3番目の性質を併せ持つ。「大量データの出力が実用的な時間で完了すること」は要求から導けるが、「10万件・5秒」という具体値は技術的実現可能性の見積もりを経て設定されたものである。

このように、非機能要件の多くは「何を達成すべきか」という問い（問題空間）と「何が実現可能か」という知識（解決空間）の接点に位置する。問題空間と解決空間は断絶しているのではなく、非機能要件という領域で常に接触している。

境界事例：データモデリング

データモデリングも同様に、抽象度の層によって性質が変わる。

概念データモデル（「従業員」「部署」の関係）→問題空間の構造化→要件定義の一部

論理データモデル（正規化、属性の型）→要件と設計の境界領域

物理データモデル（テーブル定義、インデックス）→明確に設計

この境界を意識的に管理できるかどうかが、要件定義の精度に直結する。

3つの原則

1. 目的なき要求を立てるな：「なぜ必要か」に答えられない要求は、優先順位をつけることも、不要になったときに捨てることもできない

2. 合意の対象と実装の詳細を区別せよ：要件の議論でER図やAPI定義を参照すること自体は問題ない。だが、成果物として要件と設計を同じ場所に混在させると、ステークホルダーは読むのをやめ、エンジニアは要件を読み飛ばす。思考では行き来しつつ、アウトプットはレイヤーを分けて記述する

3. 完了条件を曖昧なまま放置するな：「使いやすいこと」は要件ではない。「初回利用者が3ステップ以内に目的の操作を完了できること」が要件である

本質：要件定義とは「工程」ではなく「態度」である

要件定義には対称的な2つの危険がある。

ウォーターフォール的な危険：「要件定義フェーズが終わったから確定した」と思い込む。現実には法律・市場・ユーザーの期待は変わり続ける

アジャイル的な危険：「反復的に開発するから要件の明示的合意は不要」と思い込む。動くソフトウェアを見せても、目的レイヤーの合意がなければ「動いているが求めていたものではない」という結果になる

どちらの根も同じである。要件定義を特定の工程やイベントに閉じ込めようとする発想が問題の本質にある。

要件定義の本質は、「今、自分たちは何のレイヤーの話をしているのか」を常に意識し続ける態度である。

設計レビューの最中に「それは目的の話か、実装の話か」と問い直せること

仕様変更の依頼を受けたときに「要件が変わったのか、解決手段が変わったのか」を区別できること

スプリントレビューの場で「要求を満たしているか、仕様通りに動いているだけか」を見極めること

この態度は観測できる

「態度」と言うと精神論に聞こえるかもしれない。だが、態度が機能しているチームとそうでないチームには観測可能な差分がある。

table:まとめ

場面 態度がないチーム 態度があるチーム

仕様変更依頼が来たとき 即座に工数見積もりに入る 「これは要件変更か、解決手段の変更か」を最初に確認する

スプリントレビュー 「仕様通り動いています」で終わる 「この実装は元の要求を満たしているか」を問い直す

ステークホルダーとの会議 要件と設計が混在したまま議論が進む 「今は何のレイヤーの話をしているか」を全員が共有している

要件の曖昧さに気づいたとき 開発者が自分の解釈で埋める 未確定であることを明示し、意思決定者にエスカレーションする

プロジェクト途中で前提が変わったとき 仕様書だけを修正する 目的レイヤーまで遡り、要件への影響を再評価する

この態度を持つチームは、開発手法や組織形態に関係なく、要件定義を正しく行っている。逆に、どれほど立派なテンプレートを埋めても、この態度がなければ要件定義は機能しない。