要件定義とは？作成までの流れや必要な能力について基礎から解説

システム開発やサイト制作において重要な工程である「要件定義」。今回は要件定義について理解を深めたい方に向けて、作成までの流れや必要となる能力、さらによく挙がる質問への回答も交えてご紹介いたします。

要件定義とは

要件定義とは、主にソフトウェアやシステム開発の現場において、求められる機能や性能、期待される結果などを「要件」として明確にするプロセスを指します。Requirements Definitionの略として「RD」と呼ばれることもあり、要件をドキュメントにまとめたものが要件定義書です。

要件定義は開発工程の序盤に行われ、その後の設計や開発の根幹となります。開発工程の進行に伴い、関係者の間で「そもそも顧客が求めているものはなにか」を確かめるために要件定義に立ち返ることも多く、プロジェクトが達成すべき目的を見失わないようにする役割も果たします。

誰が要件定義を行うのか

要件定義書の作成は、発注するクライアント側ではなく主に開発側が行います。しかし、要件を明確にするためには、クライアントをはじめとしたステークホルダー全体の協力が不可欠です。開発側で誰が要件定義を担当するかは企業の体制やプロジェクトによって異なりますが、SE（システムエンジニア）、PM（プロジェクトマネージャー）、Webディレクターといったポジション・職種が担当することが多いと言えるでしょう。

要件定義書で定義すること

ここでは要件定義書で定義すべき要件について解説します。各要件において、ユーザーの要求に対して可能なことと、そうでないことを明確にすることが重要です。

業務要件

業務要件は、システム化の対象となる業務の流れを明確にしたものです。どのような属性のユーザーがどのような業務を行なっているのかをAs-Is（現状）とTo-Be（導入後）に分けて整理し、システムで実現したい業務の内容を決めていきます。また、新規事業のようにまだ業務の流れが定まっていないような場合は、想定される業務を業務フロー図に落とし込みます。

システム/インフラ要件

業務要件を踏まえ、どのようにシステム化するのかを明らかにしたものがシステム/インフラ要件です。ネットワーク環境やサーバ構成をはじめ、システム内で利用するソフトウェアやデータベース、クラウドサービスなどシステムの実現に必要な環境を明確にしていきます。

機能要件

業務要件のシステム化を実現するため、必要となる機能を具体的に落とし込んだものが機能要件です。たとえばECサイトを構築するのであれば、決済機能やカート機能、会員登録機能などが必要な機能となるでしょう。機能要件は開発の要となる部分であり、いかにここを漏れなく洗い出せるかが非常に重要となります。

非機能要件

クライアントが機能面以外で求めている要件を、非機能要件といいます。システム全体の品質や性能をどの程度保証するかを定めるために必要な要件であり、セキュリティやパフォーマンス性能、保守運用などの要素が含まれます。

要件定義の進め方

要件定義フェーズでは具体的に何をするべきなのか、ここではその工程やフローについて説明します。適切なプロセスを踏むことで、抜け漏れのない要件定義書を作成できます。

1ヒアリングと調査

クライアントは、最初からすべての要求を言語化できるわけではありません。たとえば「サイトデザインを変えたい」という言葉の裏には、「売上をアップしたい」という要求があるかもしれないのです。ヒアリングを通じてこうした「真の要求」を掘り起こし、システムに求められる要件へと落とし込むことが大切です。

また、「自分たちの要求が本当に実現可能なのか」をクライアントが判断できないケースもあるため、ヒアリングの際にでた要求を丸呑みするのではなく、実現可能性を調査したうえで、可否を回答するようにしましょう。

2要件の優先順位を明確にする

予算やスケジュールなどの都合から、すべての要件をプロジェクト内で反映できるとは限りません。ヒアリング結果をもとにクライアントと調整し、その要件が必ず実現したい「必須要件」なのか、できれば実現したい「希望要件」なのかといったように優先順位を明確にするようにしましょう。優先順位が明確になれば、全体のスケジュールも立てやすくなります。

3要件定義書への反映

ここまで整理した要件を、「要件定義書」の形にドキュメント化します。システムの概要や目的を記載すると共に、各要件を業務要件やシステム要件、機能要件、非機能要件などに分類してまとめていきます。

要件定義はなぜ重要なのか？

要件定義は、クライアントと開発側が要件についてコミットする作業とも言えます。要件定義が定まらないまま設計、実装、テストといったフェーズまで作業が進めば、クライアントが求める成果物が作られず、手戻りが発生してしまう可能性が高くなります。最悪の場合、想定していた開発期間や予算を守れず、期日までの納品が難しくなってしまうこともあるでしょう。

要件定義書は開発の重要なエビデンスであると同時に、プロジェクトの成功率をあげる大きな役割を担うものなのです。

要件定義に必要な能力とは

要件定義では、クライアントやステークホルダーたちとコミュニケーションを図りながら要件を固めていくため、さまざまな角度からの能力が求められます。ここでは要件定義に必要な能力について説明します。

先述の「要件定義の進め方」で説明したように、要件定義ではクライアントの言葉の裏に隠れた「真の要求」をくみ取ることが重要になります。単に話を聞くだけではなく、クライアントと信頼関係を構築し、意思疎通をスムーズに行える能力が求められます。

要件定義書で定義された要件は、各工程で合理性のある仕様や設計に落とし込まなければなりません。そのためには成果物の全体像を俯瞰し、要求に基づいたシステム要件を正確に把握する能力が求められます。要件定義を行う人物がプログラマーやエンジニアである必要はありませんが、システム設計を理解できる程度の技術的な知見は必要になるでしょう。

要求の実現可否を判断するためには、納期や予算を考慮しながら適切な工数を算出し、スケジュールに落とし込む能力が求められます。また、開発チームの各スタッフとの工数確認や、スケジュール合意といった調整作業をスムーズに行える力も必要です。

要件定義書は、のちに成果物の改修等が生じた際にも参照される可能性が高い資料であり、第三者が見ても理解しやすいものでなければなりません。要件を明確に定義し、かつ読みやすい文書を構築できる能力が求められます。

要件定義と混同されやすい用語との違い

システム設計には多岐にわたる用語があり、「要件定義」と混同されやすいものも存在します。ここではそれらを整理して違いを述べていきます。

要求定義は、要件定義の前工程にあたります。クライアントがビジネスで実現したい希望を扱うのが「要求定義」であり、要求定義を踏まえてシステムで実現すべきことを定義したものが「要件定義」です。

要件定義をもとに、要件を満たす機能を明確にするフェーズが基本設計です。それぞれの機能がどういったものなのか、機能同士はどう繋がるかなどを決定します。

仕様書とは、システムに関する仕様を詳細に記した文書です。備えるべき機能や性能、満たすべき要件などを文章や図表で記載します。プロジェクトによっては要件定義の内容も仕様書に含むことがあるかもしれませんが、基本的には要件定義の後工程である基本設計や詳細設計フェーズで、仕様書が作られることになります。

要件定義についてよく挙がる疑問

要件定義をスムーズに進めるには高いスキルが必要なことから、SNS上などでもさまざまな疑問が挙がっています。いくつかピックアップしてご紹介します。

まとめ

要件定義はプロジェクトの根幹をなすものであり、おろそかにすると最悪の場合プロジェクトの炎上や中止にも繋がります。クライアントと開発側がコミットした内容をエビデンスとして残し、プロジェクトをスムーズに進めるためにも、改めて要件定義の重要性に目を向けてみてはいかがでしょうか。