このページについて

このページでは、以下について記載している。

• 要件定義工程の定義
• 要件定義は、いつ実行されるべきか？
• そもそも、要件定義で何をするのか？
• なぜ、私は要件定義をしなければならないのか？

---

定義

要件定義工程とは、基本設計に先立ち、要望と制約を入力として、合意した要件を要件定義書として文書化し、後工程の前提資料として承認を得る工程である。

要件定義工程の位置づけ

システム開発において、要件定義は基本設計の入力となる

開発ライフサイクルの中で、要件定義工程は上流工程に属する。

要件定義工程の成果は、基本設計工程の入力となり、運用テストおよびシステムテストで検証される。

運用テストをユーザー側で行う場合、UAT（ユーザー受入テスト）と呼ばれることがある。

プロジェクトマネジメントにおいて、要件定義はスコープ管理の基準になる

契約上の合意点として機能し、変更要求の是非を判断する拠り所となる。

そもそも、要望を出す主体（顧客）と、実現する主体（ベンダ）が異なっているからこそ、要件定義が必要とされる。要件定義の工程としての役割は、顧客とベンダ側の間で「何を作るか」「どの条件で作るか」を合意し、契約・設計の基盤を整えることにある。

要件定義工程のスコープ

要件定義は「正しいゴールの姿」を描く工程であり、「その道筋（方法）」は後続の工程に委ねられる。

要件定義は、顧客の要望やシステム化の目的に対して、要件が妥当である = それが実現されれば、要望が叶えられる ことを検証し、保証する。

後工程は、要件定義で定めた「正答」に向けて設計・開発を行う。そのため、要件定義のミスは、後工程で取り返すことができない。

要件定義で、すること・しないこと

すること

• 「何を実現するか」を決める
• 実現するものが、顧客の要望や目的に対して妥当なものか、検証する。

しないこと

• 「どう実現するか」は設計の役割
• 実際のプログラムや詳細な画面設計はここでは定めない

要件定義工程のゴール

要件定義工程の入出力

要件定義では、要望やプロジェクト目的を、制約の下で要件に変換する

要件定義では、ステークホルダーが協力して、プロジェクト目的を達成する業務要件を整理し、それらを実現するためのシステム化要件を、予算や納期などの制約の下、調整し、妥当性を検証し、その内容を合意する。

要件定義工程の入力：要望(Stakeholder Need)、プロジェクト目的(Project Objectives)、制約(Constraint)

用語の定義はこちら → ⚖️2.2 工程の定義

• 何を実現するか(What)、だけでなく、なぜそれを実現したいのか(Why) も明らかにしなければならない。
• 顧客側からRFPなどで提示された、いわゆる「受領資料」の内容だけでなく、要件定義フェーズ中に新たに発見される制約や要望も存在する。
• ベンダー側にも要望や制約が存在する。例えば、用意できる人員の数や質、採用可能な技術スタックは、明確な制約になる。

要件定義工程の出力：要件定義書(Requirement Specification)

要件定義書の定義はこちら → 🚧2.3.1 要件定義書とは？

• 顧客と合意形成した要件を、公式に記録する唯一のドキュメント。
• 単なるドキュメントではなく、顧客と開発側の合意の証であり、契約・品質・スコープを規定する中核的な資産である。
• 要件定義書の不備は、手戻り・追加コスト・顧客不満足につながる。

なぜ、適切な要件定義が重要なのか？

システムが達成すべきゴールを顧客と合意する工程だから

システム開発における失敗の多くは、実装やテストの不具合ではなく、要件の誤解や合意不足から始まる。

要件定義は、顧客とベンダーが「システムで何を実現するか」を正しく理解し、合意するための工程であり、成果物である 要件定義書 は、プロジェクト全体を導く「共通の契約」となる。

スポーツと異なり、システム開発プロジェクトには審判がいない。そのため、ゴールの位置や形、成立条件を合意し、明文化していなければ、その判定についてトラブルが増え、しかも解決しなくなる。

逆に、要件定義を丁寧に行えば、トラブルの可能性を大幅に減らし、成功の確率を高められる。

「役に立つ」システムを設計できる唯一の工程だから

要件定義は、顧客の要望やシステム化の目的に対して、要件が妥当である = それが実現されれば、要望が叶えられる ことを検証し、保証する。

後工程は、要件定義で定めた「正解」に向けて設計・開発を行う。そのため、要件定義のミスは、後工程で取り返すことができない。

---

次のページ → 🚧要件の品質特性