シリーズ: 要件定義とはそもそも何か
- 要件定義の目的とゴールとは
- 要件定義の重要ポイント〜要望・要求・要件を見極める
- 事業・業務・システムの3階層で要件を捉える
- 業務フロー図で見える化する業務プロセスからシステム要件への道筋
- ユースケースとロバストネス図によるシステム要件定義
- システム要件定義の成果物〜設計へのインプットを作成する
- 要件定義とソフトウェアアーキテクチャ設計
- 要件定義とクラス設計
- 要件定義とデータベース設計
- 要件定義と画面設計
- 要件定義とAPI設計
- 要件定義とバッチ処理設計
- 要件とは何か（本記事）
- 非機能要件とは何か
- 要件定義を学ぶ人におすすめの書籍まとめ
- 移行要件とは何か
- 要件定義のプロセスと成果物を体系的に理解する【全体像まとめ】
- 要件定義と設計の関係を体系的に理解する【全体像まとめ】
TRACERYプロダクトマネージャーの haru です。
これまでの連載では「要件定義とは何か」について解説してきました。
この記事では、その前提となる「要件」とは何かについて説明します。
日本の現場に特有の「要求」と「要件」の区別
要件定義の重要ポイント〜要望・要求・要件を見極める - TRACERY Lab.（トレラボ）では、「要望」「要求」「要件」を以下のように整理しました。
| 種類 | 説明 |
|---|---|
| 要望 | ステークホルダーからの初期の希望やアイデア、ニーズ |
| 要求 | 要望を取捨選択し、整理、構造化したもの |
| 要件 | 要求を取捨選択し、実現対象として合意したもの |
日本の開発現場では「要求分析」と「要件定義」のように「要求」と「要件」を明確に区別して用いることが多い一方、英語圏では "Requirement" という一語で包括的に扱われます。
ISO/IEC/IEEE 29148: 2018*1は、システム・ソフトウェアの要求エンジニアリングに関する国際標準規格です。
これを基にした日本産業規格であり、日本語化されたJIS X 0166: 2021*2では、Requirementを「要件（要求事項）」と訳していて、「要求」と「要件」は区別していません。
では、なぜ日本の現場では要求と要件を区別しているのでしょうか。
「要望」「要求」「要件」を分けるメリット
「要望」「要求」「要件」を分ける最大のメリットは、発散（要望）→整理（要求）→合意（要件）という段階的な流れを明確にできることです。
最終的に要件を確定するには、工数や実現可能性といった制約条件を考慮する必要があります。しかし、要望を整理する段階から制約条件を過度に意識すると、発想が限定され、真に望ましい姿を描けなくなる恐れがあります。
そこでまずは制約条件を取り払った理想像を「要求」として表現し、その後に制約条件を加味して「要件」として合意するという二段構えを取ることで、本来あるべき姿を見失わず、かつ現実的に実現可能な要件へと落とし込むことが可能になります。
要件の階層
要件はさらに階層として分類できます。ここではトレラボの別の記事（事業・業務・システムの3階層で要件を捉える - TRACERY Lab.（トレラボ））で紹介した階層化と、国際標準規格での分類、そしてその2つの対応付けについて紹介します。
事業・業務・システムの3階層で要件を捉える - TRACERY Lab.（トレラボ）では、要件を以下の3階層に分類しました。
| 種類 | 説明 |
|---|---|
| 事業要件 | 事業で目指す目的のために、実現すべきと合意した事項 |
| 業務要件 | 事業要件を達成するために、各業務プロセスで具体的に実現すべきと合意した事項 |
| システム要件 | 業務要件を満たすために必要なシステムの機能、性能、運用条件などを定義し、実現すべきと合意した事項 |
このように、各部門が事業要件に基づいた業務要件とシステム要件を設定し、具体的に業務を構築することで、組織全体として「スピーディーな意思決定」という目的に近づくことができます。
事業、業務、システムが有機的に連携することで、組織全体の目的を一貫性を持って効果的に達成できるようになります。
上述した、ISO/IEC/IEEE 29148: 2018（JIS X 0166: 2021）では、要件を以下の4つに分類しています。
- ビジネス要件
- 利害関係者要件
- システム要件
- ソフトウェア要件
これら4つの要件を「事業要件」「業務要件」「システム要件」に対応付けると、下図のようになります。
なお、トレラボの一連の記事で「事業」「業務」「システム」という用語を用いているのは、共通フレーム2013*3に準拠しているためです。また、「ソフトウェア要件」は「システム要件」に内包されるものと考え、同様に扱っています。
システムとソフトウェアの関係については、システム開発におけるシステムとは何か - TRACERY Lab.（トレラボ）を参照してください。
最後に
本記事では、「要件」の定義について説明しました。
よく言われるように、分類は理解の第一歩です。
システム開発の要件定義では、現場で得られる多様な情報を「要望」「要求」「要件」に分けて整理することで、目の前の事象の解像度を高め、全体像を体系的に把握できます。
また、「事業要件」「業務要件」「システム要件」といった階層構造に分類することで、事業、業務、システムが有機的に連携し、組織全体の目的を一貫性を持って効果的に達成できるようになります。
こうした要件の分類や階層を関係者間で共通理解しておくことが、認識の齟齬を防ぎ、品質の高いシステム開発へとつながります。
- 次回の記事は、非機能要件とは何かについて説明します。
*1:Systems and software engineering — Life cycle processes — Requirements engineering。購入サイト
*2:システム及びソフトウェア技術--ライフサイクルプロセス--要求エンジニアリング。購入サイト
*3:ソフトウェア、システム、サービスのライフサイクル全体に必要な作業項目や役割などを包括的に規定した共通の枠組み。関係者が「同じ言葉を話せる」ようにするためのガイドライン。発注者と受注者の間で解釈の相違が起きないよう「共通の物差し」として機能し、システム開発プロセスを標準化して効率化を図る目的で、独立行政法人 情報処理推進機構(IPA)がISO/IEC 12207(JIS X0160)をベースに日本独自の要素を追加して策定した。
