要件定義書

要件定義書の書き方

要件定義とは¶

要件定義とは、あるシステムや製品に必要な機能や性能、制約条件などを明確に定める作業のことです。

つまり、ユーザーが何を望んでいて、どのような結果を期待しているかを整理・言語化し、それに基づいて開発を進めるための出発点です。

要件定義が不十分なまま開発が始まってしまうと、次のような問題が起きやすくなります：

つまり要件定義とは、 期待に沿わないものを作ってしまうリスク や、不要なコスト・遅延のリスク を避けるために行う非常に大事な工程なのです。

「品質担保」や「成功の鍵」といった表現がされることも多いですが、個人的にはこれは システム開発をとにかく失敗させないために必要なプロセス だと考えています。何度も失敗を経験してきた立場から、少しでも同じ轍を踏まずに済むよう、この内容を通じて学びを共有できればと思います。

要件定義に入る前に、まずは「誰が、何を、なぜ、いつまでに、どこまで、どうやって」求めているのか、という情報を整理しましょう。これはいわゆる 5W1H の観点で考えると非常にスムーズです。

以下の表は、5W1Hを使った要件整理の例です。

5W1H	整理すること	ポイント
Who（誰が）	登場人物・関係者の整理	プロジェクトに関与する人を洗い出す。特に「誰が最終判断をするのか」は重要。意思決定者が不在だと炎上します。
What（何を）	作るものの定義	「口頭でなんとなく決めた」は危険。明文化が必要。「顧客が本当に必要だったもの」の図を参照。
When（いつまでに）	納期・スケジュール	期間が限られている場合は、優先順位付けやスコープの切り分けが必要になります。
Where（どこまで）	スコープ・対象範囲の明確化	スコープが不明瞭だと後で「ここも入れて」「これもやって」となりがち。最初に決めることが重要。
Why（なぜ）	プロジェクトの背景や目的	作ること自体が目的にならないよう、なぜこの開発が必要かを共有しましょう。
How（どうやって）	実現方法・環境・技術方針	技術的な制約、利用するツール、基本的な仕組みなどを簡単に押さえておくとスムーズです。

要件定義で整理した内容は、ドキュメントとして記録し、関係者で共有・合意を得ることが重要です。

この「要件定義書」が、以降の設計・開発・テストすべての基礎資料となります。

ドキュメントは次のような構成を意識すると良いでしょう：

要件定義書は一度作って終わりではありません。

開発の過程で変更が生じることもあるため、更新履歴を明確に管理することが重要です。

バージョン管理の例：

バージョン	日付	変更内容	担当者
1.0.0	2021-07-12	○○の要件を追加、△△を追記	鈴木