要求定義要件定義

その要件、テストできますか？

――曖昧な要件を見抜く9つのチェック（BABOK・IEEEという物差し）

公開日 2026年07月28日

これまでの流れと、今回のテーマ

これまで6回にわたって、要件定義の現場で起きている問題を整理してきました。第1回「なぜ要件定義は失敗するのか」では、「完了の基準がない」という問題を3層構造の第三層として取り上げました。第6回「要件の品質とは何か」では、その完了基準を作るための4つの観点——網羅性・一貫性・検証可能性・合意形成——を整理しました。

これらの観点は、実は「現場の経験から導き出されたもの」ではなく、長年にわたる国際的な議論と、数多くのプロジェクトの失敗から体系化されたものです。

システム開発の失敗は、国内外で繰り返されてきました。要件定義の不備が失敗の主要な原因のひとつであることは、国内外の調査でも指摘されています※1。日本国内でもIPA（独立行政法人情報処理推進機構）が、上流工程の作業不備に起因した手戻りが開発プロジェクトの失敗や運用後のトラブルの主因であり続けていると指摘しています※2。海外の調査でも、要件収集の不十分さがソフトウェア失敗の最多原因として挙げられています※3。

要件品質に関する標準は複数存在します。要件エンジニアリングの教育・資格認定を行うIREB、IPAが国内向けに整理した知識体系であるREBOKなども、同じ問題意識から生まれたものです。その中でもBABOK V3とIEEE 29148は、要件定義の品質基準を体系的に整理したものとして国際的に広く知られており、今回はこの2つをベースに整理します。

ただし、標準の内容を網羅的に解説することが目的ではありません。「標準に照らすことで、これまで見えていなかった曖昧さが見えてくる」という体験を、具体的な例を通じてお伝えすることが目的です。

「標準」は、なぜ存在するのか

まず、なぜ標準が存在するのかを考えてみます。

システム開発の失敗のパターンを分析すると、「要件定義の不備」が原因の上位に常に挙がります。そして、その不備の多くは、「何が良い要件か」という基準が共有されていないことに起因していました。

標準は、この「共通の基準」を提供するために生まれました。「この業界で長年積み重ねられた知見を、誰でも参照できる形にまとめたもの」と理解すれば、難解なドキュメントとして身構える必要はありません。

BABOK とは何か

BABOK （Business Analysis Body of Knowledge）は、国際ビジネスアナリシス協会（IIBA）が発行する、ビジネスアナリシスの知識体系です。「ビジネスアナリシス」とは、組織の課題を分析し、解決策を定義する活動全般を指します。

ひとつ注意しておきたいのは、BABOKが定義する解決策は、必ずしもシステム開発とは限らないという点です。業務プロセスの改善、組織体制の変更、人材育成など、システムを使わない解決策もBABOKの対象に含まれています。

しかし現実として、今日の業務変革においてシステムを抜きにして考えることは、ほぼ困難です。業務改善であれ、組織変革であれ、その実現手段としてシステムが関与する場面が圧倒的に多くなっています。その意味で、BABOKが扱うビジネスアナリシスの知見は、システム開発の要件定義と深く結びついており、要件定義はその中核をなす活動のひとつと言えます。

BABOK V3では、良い要求・デザインが備える品質特性※4として、以下の9つを挙げており、例とともに記載します。

アトミックである（atomic）——自己完結しており、他の要求やデザインがなくても理解できる。「月次レポートを自動化し、承認フローも整備する」という要件は、2つの要件が混在しており、この特性を満たしていません。

完全である（complete）——さらに作業を進めるのに十分なものであり、作業を継続できるだけの詳細さを備えている。「承認フローを整備する」という要件だけでは、誰が承認するのか、何を承認するのか、承認できない場合どうなるのかが分かりません。

一貫性がある（consistent）——特定されたステークホルダー・ニーズに沿ったものであり、他の要求と矛盾していない。「リアルタイムでデータを更新する」という要件と、「低コストでシステムを運用する」という要件が並んでいた場合、この2つは場合によって相反します。個々の要件だけを見ると問題がなくても、要件の集合として矛盾が生じていないかを確認する必要があります。

簡潔である（concise）——無関係あるいは不必要なものが内容に含まれていない。

実現可能である（feasible）——あらかじめ合意したリスクとスケジュールと予算の範囲内で妥当であり、実行可能である。「来月末までに、既存システムと全面連携する新機能をリリースする」という要件は、技術的には可能でも、スケジュールの制約から現実的でない場合があります。合意された制約の中で実行できるかどうかを、要件を定義する段階で確認する必要があります。

曖昧さがない（unambiguous）——要求が、ソリューションが関連するニーズを満たすか満たさないかをはっきりさせられるように、明確に記述されなければならない。「できる限り速く」「適切に」という表現は、この特性を満たしていません。

テストが容易である（testable）——要求やデザインが実現されたことを検証できる。「使いやすい画面にする」という要件は、何をもって「使いやすい」と判断するのかが定義されていなければ、実現したかどうかを検証できません。「初めて使うユーザーが、3クリック以内に目的の操作を完了できる」のように、確認できる形に落とし込む必要があります。

優先順位が付いている（prioritized）——重要性と価値の観点から、他の全要求と比較して格付けされている、分類されている、あるいは協議が済んでいる。複数の要求をすべて「必須」として扱ってしまうと、限られた開発期間の中で何を優先すべきかが判断できなくなります。MoSCoW法（Must・Should・Could・Won't）のような形で優先度を明示することが、この特性を満たす具体的な方法のひとつです。

理解が容易である（understandable）——受け手が普段使用する用語を用いて表現されている。専門用語が多用された要件定義書は、顧客の合意形成を難しくします。

IEEE 29148とは何か

IEEE 29148は、要件エンジニアリングに関する国際標準規格です。IEEEはInstitute of Electrical and Electronics Engineers（電気電子学会）の略で、技術標準の策定において世界的な権威を持つ組織です。

IEEE 29148は、システムおよびソフトウェアエンジニアリングにおける要件のプロセスと要件の品質について定めています。BABOKがビジネスアナリシス全般を扱うのに対して、IEEE 29148はより技術的な観点から要件の品質を定義しています。

IEEE 29148では、個々の要件が備えるべき品質特性として、以下の9つを挙げています※5。なお、以下についてはJIS X 0166:2021からの引用であり、原本では「要件」は、「要件（要求事項）」と記されていることを補足します。

－必要であること

要件は、本質的な能力、特性、制約及び／又は品質要因を定義する。

そのような個々の要件を、まとめられた要件の集合が含まない場合、能力又は特性の不備が存在することになり、他の要件を実装してもそれを満たすことは不可能である。要件は、時間の経過によって無効になったものではなく、現在有効なものである。失効日又は発効日が予定されている要件は、明確に識別される。

－適切であること

要件の特定の意図及び詳細度は、それが参照するエンティティ（実体）のレベルに対して適切である［エンティティ（実体）のレベルに対して抽象度が適切である。］。これには、実装の独立性を可能な範囲で許容し、アーキテクチャ又は設計に対して不必要な制約を課さないことを含む。

－曖昧でないこと

要件は、一意に解釈できるよう記述されている。要件は単純に記述されており、かつ、理解しやすい。

－完全であること

要件は、その要件を理解するために他の情報を必要とすることがないように、エンティティ（実体）のニーズを満たすために必要な能力、特性、制約又は品質要因を十分に記述している。

－単独であること

要件は、単一の能力、特性、制約又は品質要因を記述している。

－実現可能であること

要件は、受容可能なリスクの下、システム制約（例えば、コスト、スケジュール、技術）の中で実現が可能である。

－検証可能であること

要件は、要件の存在するレベルにおいて、顧客の満足を得る程度に証明（検証）可能なように構造化され、言語化されている。要件が測定可能である場合、検証可能性が高まる。

－正しいこと

要件は、変換元のエンティティ（実体）のニーズを正確に表現したものである。

－適合すること

個々の項目は、要件を書くためのものとして承認された標準的テンプレート及びスタイルに適合している（そのような指定がある場合）。

なお、IEEE 29148では個々の要件の品質特性とは別に、要件セット全体の品質として追跡可能性（Traceability）も定義しています。「この要件はどのヒアリングのどの発言から来ているのか」を記録しておくことが、なぜ重要なのかは第5回「議事録から要求を抽出する」でお伝えしたトレーサビリティの問題と直結しています。

標準に照らすと、何が見えてくるか

ここで、実際の現場でよく見られる要件を、BABOK V3・IEEE 29148をベースにした観点で分析してみます。

例①：「できる限り速く処理する」

曖昧でないこと（BABOK V3の「曖昧さがない」、IEEE 29148の「曖昧でないこと」）の観点では、「できる限り速く」は人によって解釈が異なります。検証可能であること（BABOK V3の「テストが容易である」、IEEE 29148の「検証可能であること」）の観点では、何秒以内なら合格なのかが定義されていないため、テストできません。どちらの観点からも、この要件は品質基準を満たしていません。「3秒以内に処理を完了する」のように、数値で定義し直す必要があります。

例②：「承認フローを整備する」

完全であることの観点では、誰が承認するのか、何を承認するのか、承認できない場合の処理は何か、という情報が欠落しています。単独であること（アトミックであること）の観点では、「整備する」という表現の中に複数の機能が含まれている可能性があります。「〇〇部長が、発注申請書に対して承認または却下を行う。承認期限は申請から3営業日以内とし、期限超過の場合はシステムから自動リマインドを送信する」のように、具体化する必要があります。

例③：「セキュリティを強化する」

曖昧でないことの観点では、「強化」が何を指すのかが定義されていません。検証可能であることの観点では、強化されたかどうかをテストする基準がありません。必要であることの観点では、「強化」という言葉だけでは、なぜ強化が必要なのかという根拠も不明です。

「標準を知っている」と「使える」は別のことです

第4回「初級SEが要件定義で迷うポイント」でお伝えしたことと同じ構図が、ここでも現れます。

BABOK V3やIEEE 29148を読んで、品質特性の一覧を頭に入れることはできます。しかし、実際のヒアリングの最中や、書き上がった要件定義書を前にしたとき、「この要件は検証可能か」「この表現は明確か」という問いを、リアルタイムで自分の要件に適用できるかどうかは、別の能力です。

「できる限り速く」という表現を自分で書いてしまうSEは、BABOK V3を知っているかどうかに関わらず、現場では珍しくありません。知識があっても、書いた時点では「伝わるだろう」という感覚が優先されてしまうからです。

標準が本当に力を発揮するのは、「知識として持っている」ときではなく、「実際の要件に対して、自動的に適用されるとき」です。チェックリストとして使う、レビュープロセスに組み込む、あるいは何らかの仕組みとして機能させる——そういった形で初めて、標準は現場の品質を変える力を持ちます。

あるべき論だけでは、現場は動かない

しかし、ここで正直に認めなければならないことがあります。

BABOK V3やIEEE 29148の品質特性をすべて満たそうとすると、要件定義の作業量は大幅に増えます。「アトミックであること」を徹底すれば、ひとつの要件を複数に分割する作業が必要になります。「追跡可能性」を確保しようとすれば、すべての要件に発生源の記録を紐づける作業が発生します。「検証可能であること」を担保しようとすれば、すべての要件に受入基準を設定する必要があります。

これを現場のすべてのプロジェクトで、すべての要件に対して行うことは、現実的ではありません。プロジェクトには納期があり、予算があり、人員には限りがあります。「標準に完全に準拠した要件定義書」を作ることよりも、「とにかくシステムを動かすこと」が優先される場面のほうが、圧倒的に多いのが現実です。

だからといって、「現実的でないから使わない」という結論が正しいかというと、そうとも言えません。

型にはめることが足かせになる場面は確かにあります。プロジェクトの規模・リスク・予算によって、どの品質特性をどこまで担保するかは変わるべきです。小規模な社内システムと、金融機関の基幹システムでは、求められる品質の水準がまったく異なります。

問題は「標準を使うか使わないか」ではなく、「何のために使うのか」という目的の明確さです。

標準は、「すべてを守るべきルール」ではなく、「何が欠けているかを気づかせてくれるものさし」として使うのが現実的です。「自分の要件定義書を標準に照らしてみたとき、どこに穴があるか」を確認するための道具として使う。その使い方であれば、現場の制約と両立できます。

あるべき論だけで現場は動かない。しかし、あるべき論を知らなければ、何が足りないかも分からない。この両方を持つことが、要件定義の品質を少しずつ上げていくための現実的なアプローチだと考えています。

「権威」ではなく「道具」として使う

BABOK V3やIEEE 29148をベースにした品質基準を提示したとき、顧客やステークホルダーに対して客観的な根拠をもって説明できることは、現場での説得力を高めます。

「私の経験上、この書き方は問題です」という主張は、経験の浅いSEには難しい。しかし「BABOK V3・IEEE 29148をベースにした品質チェックでは、この表現は検証不可能な記述として検出されます」という説明は、経験に依存せずに使えます。

これは、標準を「権威」として振りかざすことではありません。長年の知見をもとに体系化された「道具」として使うということです。ものさしを持てば、測れる。測れれば、説明できる。説明できれば、改善できる。

要件定義における標準の価値は、「正しさの証明」ではなく、「共通のものさし」を提供することにあります。

まとめ

BABOK V3とIEEE 29148は、要件の品質特性を体系的に整理した国際標準です。BABOK V3はアトミック・完全・一貫性・簡潔・実現可能・曖昧さがない・テストが容易・優先順位・理解が容易という9特性を、IEEE 29148は必要・適切・曖昧でない・完全・単独・実現可能・検証可能・正しい・適合するという9特性を定義しており、前回整理した4つの観点（網羅性・一貫性・検証可能性・合意形成）とも深く対応しています。

BABOK V3はシステム開発に限らずビジネス課題の解決全般を対象としていますが、今日の業務変革においてシステムを抜きにすることは現実的には困難です。その意味で、BABOK V3の知見はシステム開発の要件定義と切り離せない関係にあります。

標準に照らすことで、「なんとなく書いた要件」の中に潜む曖昧さや欠落が、具体的に見えてきます。ただし、標準はすべてを守るべきルールではありません。プロジェクトの規模やリスクに応じて、どの特性をどこまで担保するかを判断する必要があります。あるべき論だけで現場は動かない。しかし、あるべき論を知らなければ、何が足りないかも分からない。標準を「権威」としてではなく「ものさし」として使うことが、要件定義の品質を現実的に上げていくための第一歩です。

※1 本稿における「国内外の調査」とは、以下の※2・※3に挙げる調査を指します。

※2 IPA（独立行政法人情報処理推進機構）／SEC（ソフトウェア高信頼化センター）「上流工程の作業不備に起因した手戻り」に関する調査・ガイドブック（2017年公開）より。上流工程の重要性が指摘されて久しいにもかかわらず、作業不備に起因した失敗やトラブルは依然として解消されていないと報告されています。

※3 Beta Breakers「Understanding 2023 Software Stats & QA Role」（2023年）によれば、不十分な要件収集がソフトウェアプロジェクト失敗の最多原因（39.03%）として挙げられています。

※4 IIBA（国際ビジネスアナリシス協会）『BABOK Guide V3』日本語版、「要求とデザインの品質特性」（p.138）より。

※5 JIS X 0166:2021（ISO/IEC/IEEE 29148の日本語訳規格）より、個々の要件が備えるべき品質特性を要約。