要件定義と要求定義の違いとは？それぞれの考え方や定義書に記載すべき項目

ソフトウェア開発、プロダクト開発領域の新規事業開発前に行う要件定義と要求定義。

言葉が似ているため、違いがよくわからないという方も多いのではないでしょうか。

「要件定義」は開発に必要な機能や実装方法を整理したもの、「要求定義」はユーザー側の求める仕様を定義したものです。

今回は、要件定義と要求定義の基本的な意味や考え方、それぞれの違いについて解説していきます。

関連記事：【開発前チェックリスト付】ソフトウエア・アプリ開発におけるMVP開発ガイドブック

1.要件定義・要求定義とは？

「要件」とは、必要な条件・資格のこと
「要求」とは、必要または当然のこととして相手に強く求めること

という意味があります。

プロダクト開発における「要件定義」「要求定義」とは一体どのような意味をもつものなのでしょうか。

• 要件定義とは、実装すべき機能・達成すべき要件などの仕様を定義すること。
• 要求定義とは、どのような製品を作るのかユーザーが求める仕様を定義すること。

要件定義とは、開発者がプロダクト開発をするための仕様を定義したものです。

要件定義を明文化した「要件定義書」は、ユーザー側の合意・了承を得るためのもので開発者側で作成します。

一方、要求定義はユーザーがプロダクト開発・システムに求める仕様を定義したものです。

要求定義を明文化した「要求定義書」は、プロダクト開発に対するオーダーを記したものになるため、ユーザー側が作成します。

要求定義は、プロダクト開発の上流工程として最も重要なプロセスです。

「要求定義→要件定義→基本設計→詳細設計→開発→テスト→リリース／運用」

という工程のスタートに位置する要求定義は、プロダクトの品質を左右することになります。

2.要件定義書と要求定義書、要求仕様書の違いとは？

「要件定義」と「要求定義」について解説しましたが、それぞれを明文化したものの正式名称や内容は次のとおりです。

・要件定義書：「システム要件定義書」

ユーザー側の要望に沿い、ユーザー側の合意・承認を得るためのも。「開発者側」が作成します。

・要求定義書：「業務要求定義書」

開発業務に対する詳細な仕様や機能のオーダーが記載されており「ユーザー側」が作成します。

・要求仕様書

要求仕様書は、ユーザーの要望をまとめたもので、本来はユーザー側が作成するのですが、開発側で作成するケースが多いです。

要求仕様書の内容が、プロダクト開発に必要な要素を網羅していれば、要件定義書の代用として用いられることもあります。

3.要件定義の考え方

要件定義書には2つの側面があります。

• 要求仕様書の内容を実現するために必要な機能と実装方法をまとめた仕様書
• プロダクト開発に求められている機能について、プログラムの機能・データベース等含めて定義した仕様書

要件定義書は、プロダクト開発における基本設計や詳細設計のベースとなります。

要件定義書には「機能要件」に加えて「非機能要件」としてプロダクトの性能等を記します。

3-1.要件定義の定義項目

要件定義書を作成する際には、機能要件と非機能要件を定義します。機能要件とは開発においてユーザーから求められる機能のこと、非機能要件とは機能以外の品質に関連する部分（ユーザビリティ・性能・セキュリティ等）のことを指します。

・機能要件

プロダクト開発の基本的な流れは「要件定義」→「設計」→「制作」→「テスト」の順。

最初の「要件定義」で決定した事項が後々まで影響してくるため、ユーザーにヒアリングする段階で取りこぼし・相互の認識のズレがないようにしておくことが大切です。

要件定義における機能要件とは、ソフトウェアやプロダクト開発をする際に、実装・搭載すべき機能、必要な性能などに関する要件のこと。

ユーザーにとっては機能要件は最低限必ず必要な機能となり、万が一、未実装である場合はプロジェクトは失敗です。

・非機能要件

実装される要件のうち、機能以外の部分の要件を指します。

例えば、「商品の仕入先を検索する機能は、目的別にして3秒以内に完了してほしい」など、開発・制作側が主な目的としていること以外の要件が該当します。

主たる目的ではない非機能要件は、必ずしも定義される必要はありませんが、「可用性」「性能／拡張性」「運用／保守性」「移行性」「セキュリティ性」「システム環境」などのカテゴリを満たす形が多いでしょう。

非機能要件については、発注元やユーザーが普段意識していない潜在ニーズについて満たすことになる部分でもあり、細かいレベルまで網羅することで、ユーザーの満足度を高められる要件でもあります。

関連記事：新規事業開発のプロセスとは？5つのステップと３つの成功事例

3-2.要件定義の工程

要件定義と基本設計は混同しやすいですが、工程が異なります。

基本設計は、要件定義をより詳細に明確化していくもの。実際のプロダクト開発の根幹部分を決定するのが基本設計です。

多くの会社では「要件定義」の段階で要求も要件も同時に扱ってしまうケースが多いです。そのため、要求を提示すべきユーザーと要件を特定すべき開発担当者の間で食い違いが生じ、収拾がつかなくなるという問題が生じます。

あるいは、要求が曖昧なまま要件の検討をしたため、開発の段階になってユーザーの求めるものと異なっていることに気づく事態に陥るケースがあるのです。

このような事態を避けるためにも、開発工程の上流工程で実現する範囲の「定義」が必要なのです。

そのために「要求」→「要件」という工程で定義していく必要があるのです。

プロダクト開発の工程には、いろいろなモデルがありますが、代表的な開発工程モデルといえば従来型の「フォーターフォール開発」、最近主流となっている「アジャイル開発」があります。

・要件定義ありきのウォーターフォール開発

引用：https://www.kagoya.jp/howto/it-glossary/develop/what-is-agile/

ウォーターフォール開発は、工程を細かく分け、上流工程から下流工程へと順次進めていく開発手法。最初に行う要件定義や設計が全ての基盤となり、基本的に後からの変更は想定していません。

ウォーターフォール開発のメリットは、1つの工程が完了してから次の工程へ進むため、開発全体の状況を把握しやすく管理が行いやすい点です。

ただし、不具合が発見されると、その修正に多くの時間やコストがかかる点がデメリット。

要件定義や基本設計までさかのぼって修正する必要が生じた場合、大幅な納期遅延につながり、コストが増えてしまいます。

・詳細な要件定義を必要としないアジャイル開発

引用：https://www.kagoya.jp/howto/it-glossary/develop/what-is-agile/

アジャイル開発は、小さな開発単位でPDCAを高速で行う開発スタイル。スピードを優先するプロジェクトに向いています。開発の概要が決定したらすぐに開発工程へ進み、機能単位ごとに「計画→設計→実装→テスト」のサイクルを繰り返しながら、開発していきます。

アジャイル開発は後戻りが前提の開発スタイルなので、基本設計の工程では詳細は決めず、開発作業を進める中で、ユーザーの声を聞きながら都度必要に応じた改善・修正を行っていきます。

開発のスピードが最も大きなメリットですが、工程の進捗・全体の状況の把握が難しいというデメリットがあります。

関連記事：アジャイル開発とは？メリット・デメリットやプロセス手法も合わせて解説！

4.要求定義の考え方や気をつけるべき点とは？

要件定義と同じように、要求定義にも２つの側面があります。

• 発注側／依頼側の要求・要望を記載した仕様書
• 発注側／依頼側の要求・要望の中でもプロダクト開発に必要なものを示した仕様書

要求仕様書に記載する機能一覧は、発注側／依頼側が理解できるようなわかりやすい内容が求められます。

発注側／依頼側が「何を実現したいのか」を明確にするのが要求定義書です。

発注側／依頼側自身も明確になっていない漠然とした要求を導き出し、開発で実現したい（させたい）内容へ落とし込み、明文化したものが要求仕様書です。

4-1.要求定義の考え方

要求仕様書の主体は、あくまでも「ユーザー（発注側／依頼側）」です。しかし、発注側／依頼側では作成スキルがないケースがほとんど。そのため、開発者側が作成するケースが多くみられます。

発注側／依頼側の「これがほしい」「ここはこうしたい」という要求をいかに引き出せるかがポイントです。

前述したように、以前はプロダクト開発の主流だった「ウォーターフォール開発」では、ユーザー側の「要求定義」を「要件定義書」に書き換えて、基本設計や詳細設計に引き継いで開発を進めていました。

一方で、スピードを重視する最近の主流は「アジャイル開発」です。アジャイル開発では、開発工程の境界が曖昧なので、実際に開発を進めながらユーザーの要望を確認し、仕様書に加えていくスタイルです。

4-2.要求仕様書に記載すべき項目とは？

要求仕様書の記載内容は特に決まっていませんが、基本的には要望や要求事項・予算・リリース時期などが主な内容です。発注側／依頼側に詳しい担当者がいない場合が多く、開発担当側が作成することが多いです。

要求仕様書に記載する主な項目は以下のとおりです。

• プロダクト開発の目的

何のためにプロダクト開発をするのか、目的を明確化

• 基本方針

プロダクト開発における基本方針やテスト方針の記載。

• 機能一覧

詳細機能については詳細設計書などの仕様書に記載されるため、ここでは大まかな機能について記載。

• その他

要件定義書と兼ねている場合には、開発体制・開発環境・開発予算・開発スケジュールなどの項目も網羅。

要求仕様書は、発注側／依頼側の要求と開発者側で合意を得るためのものであり、その後の開発の指示書の役割も果たす重要なものです。

しかし、いくら要求仕様書をしっかり作りこんでも、開発途中で例外が出てきたり、実際に開発している途中で違う要求がでてくる、ということもあります。

また、実際のところ発注側／依頼側で本当に必要な機能とそうでないものの区別がついていないケースも多いもの。

例えば、高度なセキュリティを要求するシステム開発をする場合、現在は二段階認証などの厳重なセキュリティ対策が施されるケースが多いでしょう。開発者側は、発注側／依頼側からそのような要求がなかったとしても、提案することが必要なこともあります。

その逆に、場合によっては発注側／依頼側の無理な要求を退けることが必要な場面も。

発注側／依頼側と開発者、どちらか一方的なものではなく、お互いの信頼のもとに「できること・できないこと」を明確にしながら要求定義をまとめていくことが求められます。

4-3.要求定義で気をつけておく点

要件定義は、要求定義をもとに作成するため、要求定義に不備やもれがあると、その後の工程に影響を及ぼしかねません。

要求もれにより、要求定義に仕様が実装・搭載されないと、結果としてユーザー満足度の得られない製品ができあがってしまいます。

アジャイル開発のように、機能単位の小さなものでPDCAを回しながら行う開発は、ユーザーのフィードバックをすぐに受けられるため、ユーザーの求めるものと乖離することなく開発を進められます。

DeFactoryでは、クオリティを担保させつつも、納期をしっかり守るアジャイル開発を得意としています。アジャイル開発経験のあるマネージャーがプロジェクトの管理を行うので、スケジュールやプロジェクト管理に不安がある方でも、安心してお任せいただけます。

関連記事：MVP開発とアジャイル・リーンとの関係性とは？DX推進への活用

5.まとめ：「新規事業開発」に関する支援を承ります

要件定義書・要求定義書、また要求仕様書についてもご紹介しました。要件定義は、プロダクト開発の基本設計や詳細設計の元となり、要求定義はユーザーがプロダクト開発に求めるものを定義したものです。

プロダクト開発がはじめてのケースでは、要件定義なんてとてもハードルが高いと感じる人もいるかもしれません。

しかし、プロダクト開発に何を求めるのか「要求」を定義するのであれば比較的取り組みやすいのではないでしょうか。

DeFactoryでは、アイディア着想、ユーザーヒアリング、テストマーケティング、アジャイル・MVP開発と、プロダクト開発における立ち上げ支援を全力サポートいたします。 

また、経験豊富なエンジニアと事業開発経験者で、開発だけでなく事業設計から「一気通貫」した伴走を行います。 事業開発や立ち上げを検討しているご担当者様がいらっしゃいましたら、問い合わせページから資料請求や無料相談などお気軽にご連絡くださいませ。

【DeFactoryの3つの特徴】

・最短14営業日程度で納品
・事業構築力、スピード、高品質を実現する体制
・キャンペーンにより事業構想フォローを無料実施