要件の品質とは何か
――良い要件は「詳しい」だけではない
「良い要件」を、説明できますか？
突然ですが、「良い要件とはどういうものか」を、今すぐ説明できるでしょうか。
「詳しく書いてある要件」でしょうか。「顧客が納得している要件」でしょうか。「抜け漏れのない要件」でしょうか。
どれも間違いではありません。しかし、それぞれが「良い要件」の一側面しか捉えていないことも確かです。そして、「詳しく書いてある」「顧客が納得している」「抜け漏れがない」という判断自体が、どれも主観的で、測りにくいものです。
第1回「なぜ要件定義は失敗するのか」で、「第三層：完了の基準がない」という問題をお伝えしました。「要件定義が完了した」という状態を判断する客観的な基準が、多くの現場に存在しないという話です。
今回は、その問いにより具体的に答えます。要件の品質を「感覚」ではなく「基準」で語るための考え方を整理します。
「詳しい」だけでは、不十分な理由
まず、「詳しく書いてあれば良い要件だ」という考え方の限界から始めます。
「毎月末日の23時に、売上データを集計し、PDF形式で経理部長宛に自動送信する」という要件があったとします。これは、詳しく書かれています。しかし、これだけでは「良い要件」と言えるでしょうか。
いくつかの問いを立ててみます。
「経理部長が不在の場合、誰に送りますか？」——これに答えられなければ、要件として不完全です。
「売上データの集計範囲はどこからどこまでですか？」——これが曖昧なままでは、実装段階で解釈が割れます。
「月末が土日の場合、処理はいつ実行されますか？」——これが定義されていなければ、例外ケースでシステムが止まります。
「この要件が満たされているかどうか、どうやって確認しますか？」——テストできない要件は、完成したかどうかを判断できません。
詳しく書かれているように見えても、「検証できるか」「例外ケースをカバーしているか」「曖昧な表現が残っていないか」という観点から見ると、多くの要件には穴があります。
「詳しい」という評価は、情報の量についての判断です。しかし、要件の品質は情報の量だけで決まるものではありません。
要件の品質を構成する、4つの観点
では、要件の品質はどのような観点から評価すべきでしょうか。国際的な標準であるBABOK・IEEEをベースにすると、大きく4つの観点に整理できます。
① 網羅性（完全性）——必要なものが、揃っているか
要件として定義すべき内容が、漏れなく記述されているかどうかです。
第3回「要件定義で抜け漏れが起きる理由」でお伝えした「暗黙知に起因する欠落」や「ステークホルダーの漏れ」は、まさにこの網羅性の問題です。「書いてある」だけでなく、「書くべきことがすべて書いてある」状態が必要です。
網羅性を評価するためには、「何が揃っていれば完全と言えるか」という基準が必要です。基準がなければ、欠落に気づきようがありません。
② 一貫性——矛盾が、ないか
複数の要件の間に、矛盾や相反する記述がないかどうかです。
たとえば、「リアルタイムでデータを更新する」という要件と、「低コストでシステムを運用する」という要件が並んでいた場合、この2つは場合によって相反します。リアルタイム処理には相応のインフラコストがかかるからです。
あるいは、「承認は部長が行う」という記述と、「部長不在時は代理承認不可」という記述と、「緊急時は即時処理を優先する」という記述が並んでいた場合、緊急時に部長が不在だったらどうなるのか、という矛盾が生じます。
個々の要件は正しく見えても、全体として整合性が取れているかどうかは、別の問いです。
③ 検証可能性——テストできるか
要件が満たされているかどうかを、客観的に確認できるかどうかです。
「できる限り速く処理する」「使いやすい画面にする」「十分なセキュリティを確保する」——これらは要件として記述されることがありますが、いずれも検証できません。「できる限り速く」が何秒を指すのか、「使いやすい」の基準が何なのか、「十分なセキュリティ」がどのレベルなのかが定義されていないからです。
テストできない要件は、完成したかどうかを判断できません。完成判断ができなければ、受け入れ基準も定まらず、顧客との合意が成立しません。
④ 合意形成——ステークホルダーが、納得しているか
要件の内容について、関係する全員が理解し、合意しているかどうかです。
「顧客にOKをもらった」という状態は、合意形成の必要条件ですが、十分条件ではありません。「誰が」OKを出したのか、「何に対して」OKを出したのかが重要です。
第3回でお伝えしたように、打ち合わせに参加していないステークホルダーが存在する場合、その人の視点は要件に反映されていません。形式的にOKをもらっていても、実質的な合意が形成されていないケースがあります。
また、「OKをもらった」という事実と、「その要件の内容を理解した上でOKをもらった」という事実も、別のことです。専門用語が多く含まれた要件定義書を、顧客が真に理解した上で合意できているかどうかは、慎重に確認する必要があります。
曖昧な表現が、品質を下げる
要件の品質を下げる要因として、特に注意が必要なのが「曖昧な表現」です。
「できる限り」「なるべく」「適切に」「十分に」「速やかに」——これらの言葉は、要件の中に頻繁に登場します。しかし、これらはすべて、人によって解釈が異なる言葉です。
「できる限り速く処理する」という要件を見て、顧客は「1秒以内」をイメージしているかもしれません。一方、開発者は「現在の処理と比べて改善されていれば良い」と理解するかもしれません。どちらも「できる限り」という言葉の解釈として、間違いではありません。
この解釈の違いは、システムが完成するまで表面化しません。顧客が「1秒以内」を期待していたのに、実際には3秒かかるシステムが完成したとき、初めて認識のズレが明らかになります。
曖昧な表現は、書いた時点では「なんとなく伝わった気がする」状態を作り出しますが、後工程に進むほど問題を拡大させます。検証可能性の観点から言えば、曖昧な表現が含まれる要件は、テストの設計ができない——つまり、品質が担保できない要件です。
品質は、測れなければ管理できない
ここで、第1回でお伝えした「第三層：完了の基準がない」という問題に戻ります。
要件定義が完了したかどうかを判断するためには、品質の基準が必要です。しかし、その基準を「感覚」に依存している限り、完了判断は客観的にできません。
品質の4つの観点——網羅性・一貫性・検証可能性・合意形成——を用いれば、少なくとも「何を確認すれば品質を評価できるか」という問いに答えることができます。
たとえば、「曖昧な表現を含む要件が何件あるか」は、検証可能性の観点から品質を測る指標になります。「OKを取れていないステークホルダーが何人いるか」は、合意形成の観点からの指標になります。「例外ケースが定義されていない機能要件が何件あるか」は、網羅性の観点からの指標になります。
これらを数値として把握できれば、「要件定義がどこまで完了しているか」を、感覚ではなく数値で語ることができます。
「なんとなく十分だろう」から「この指標がこのレベルに達したから完了と判断できる」への転換。これが、要件定義を「勘に頼るフェーズ」から脱却させるための、具体的な一歩です。
品質の評価は、一度では終わらない
もうひとつ、重要な点があります。要件の品質評価は、要件定義が「完了した」タイミングで一度行えばよいものではありません。
要件定義は、一度書いたら終わりではなく、ヒアリングを重ねながら徐々に育てていくプロセスです。最初のヒアリングで得た情報をもとに要件を書き、次のヒアリングで新しい情報が加わり、要件が更新される。その過程で、新たな矛盾が生じたり、以前は検証可能だった要件が曖昧になったりすることがあります。
つまり、品質の評価は、要件定義のプロセス全体を通じて、継続的に行う必要があります。「書いた時点では良い要件だった」が、「追記・修正を経て、整合性が崩れた」というケースは、現場では珍しくありません。
要件定義書は生きたドキュメントです。一度品質を確認したからといって、その後も品質が保たれているとは限りません。継続的に、かつ一貫した基準で評価し続けることが必要です。
まとめ
要件の品質は、「詳しく書いてある」かどうかだけでは評価できません。網羅性・一貫性・検証可能性・合意形成という4つの観点から、複合的に評価する必要があります。
特に「検証可能性」は見落とされがちです。「できる限り」「なるべく」「適切に」といった曖昧な表現は、書いた時点では伝わった気がしますが、後工程に進むほど問題を拡大させます。テストできない要件は、完成したかどうかを判断できない要件です。
そして、品質は測れなければ管理できません。4つの観点を指標として数値化することで、「要件定義がどこまで完了しているか」を感覚ではなく客観的に語ることができます。また、品質評価は一度では終わりません。要件定義は更新され続けるドキュメントであり、継続的かつ一貫した基準での評価が必要です。
この問題に、仕組みで向き合うツールがあります。
AiRee（アイリー）は、要件定義の完了度をスコアで可視化するAIプラットフォームです。「勘」に頼らず、構造的な欠落を検出します。
現在（2026年7月31日まで）、10社限定で無償トライアルを受付中です。
［先行トライアルに応募する →］ ［資料をダウンロードする →］
最後までご覧いただきありがとうございました。
メルマガ登録をしていただければ、コラムが更新された時にお知らせします。
また、AI要件定義プラットフォーム AiRee（アイリー）の情報も合わせてお届けします。