要件定義をしたはずなのに、なぜ開発現場は絶望するのか
要件定義をしたはずなのに、なぜ開発現場は絶望するのか
〜車を作る例えで考える、要求定義を要件定義と呼んでしまう問題〜
はじめに
要件定義は終わっているはずなのに、
設計に入った瞬間から「決まっていないこと」に気づくことがある。
- どこまで作ればOKなのか分からない
- 何を優先すべきか分からない
- 判断すると「それは想定と違う」と言われる
この状態は、技術力の問題ではないことが多い。
原因はもっと手前、要件定義と要求定義が混ざっていることにある。
車を作る例で考える開発フェーズ
「速く移動したい」という要求から、車を作ると考えてみる。
要求
速く移動したい
これは「なぜ欲しいか」という目的の話で、
まだ「何を作るか」も「どこまでできれば良いか」も決まっていない。
要求定義
自分用の車を作って、全国を移動して活躍したい
目的が少し具体化され、「車を作る」という解決策が選ばれている。
ただし、この時点ではまだ次のような点が曖昧なままだ。
- どれくらい速ければいいのか
- 何人乗れれば十分なのか
- 法規制をどこまで考慮するのか
- 予算はいくらまで許されるのか
解決策の検討（なぜ“車”なのか）
要求定義の段階で、
いきなり「車を作る」と決めてしまうことは多い。
しかし本来はその前に、
「本当に車で解決するのが最適か？」
を一度だけ確認するフェーズがある。
たとえば、
- 既存の車を購入する
- レンタカーやカーシェアを使う
- 他の移動手段を組み合わせる
といった選択肢を踏まえた上で、
それでも「自分用の車が必要」と判断できて初めて、
「車を作る」という解決策が確定する。
この確認が省略されると、
後工程で「そもそも作る必要があったのか？」
という議論が再燃しやすくなる。
システム開発でも、
「新規開発」「既存システム改修」「SaaS導入」「運用変更」
のどれで解決するかを決めないまま要件定義に入ると、
後から前提がひっくり返ることがある。
要件定義
ここで初めて、
「何ができていれば、この要求は満たされたと言えるか？」
を決める。
・公道を走れるサイズの車である
・車検が通る（法規制を満たす）
・最大4人乗れる
・予算は◯円以内
重要なのは、
YES / NO で判断できる条件になっていること。
これを満たさない車は
「要求を満たしていない」と判断できる。
設計（どう作るか）
要件定義で
「何を満たせばOKか」が決まったら、
次は 「どうやってそれを実現するか」 を考えるフェーズに入る。
たとえば今回の例であれば、
・車種はコンパクトカーにする
・ガソリン車にする
・FF駆動にする
といった判断がここに入る。
これらは、
要件（公道を走れる／4人乗れる／予算内）を満たすための
実現手段の選択であり、
本来は技術者の判断領域になる。
システム開発でも同様に、
API構成やDB設計、画面構成といった具体的な作り方は
要件ではなく設計で決めることになる。
「要件定義っぽい要求定義」の例
多くの現場で「要件定義」として渡される内容は、
実際には次のような形になっていることが多い。
・誰でも使いやすい画面にしたい
・処理はできるだけ速くしたい
・将来の拡張にも対応できるようにしたい
・業務で困らないようにしたい
一見するともっともらしいが、
次の問いに答えられない。
- 「誰でも」とは誰か
- 「速い」とはどの程度か
- 何を犠牲にしても拡張性を優先するのか
- どこまでできれば「困らない」と言えるのか
これは要求の説明であって、
満たしたかどうかを判断できる要件にはなっていない。
設計に入った瞬間に起きること
この状態で設計に入ると、技術者はこうなる。
- 何かを決めないと進めない
- でも決めていいか分からない
- 決めると後から否定される
技術者が絶望する理由は
「難しいから」でも「技術力が足りないから」でもない。
判断しないと前に進めないのに、
判断していい権限がない
この構造にある。
要件定義で本当にやるべきこと
要件定義は「全部を決める場」ではない。
やるべきことは、次の3つだけ。
- 満たしたと言える条件を決める
- 絶対に守る制約を決める
- 決まっていないことを「未決」として明示する
特に3つ目が抜けると、
- 決まっていないのに決まっていた扱い
- 後出し仕様
- 手戻り地獄
が発生する。
現場で使える確認の一言
要件が足りないと感じたとき、
こう聞くだけで状況が前に進むことが多い。
- 「どこまでできていればOKですか？」
- 「これは設計判断で進めても大丈夫ですか？」
- 「未決の点を洗い出してもいいですか？」
責めるためではなく、
判断を前に進めるための質問。
おわりに
「要件定義をやったのにうまくいかない」現場の多くは、
実は要件定義が失敗しているのではない。
要求定義を要件定義と呼んでしまっているだけだ。
- 要求は「なぜ」
- 要件は「満たしたと判断できる条件」
この線が引けるだけで、
開発は驚くほど楽になる。
Discussion