要求定義、要件定義という言葉をよく耳にすると思います。どちらも似たような言葉ですが、全く別の役割を持ちます。
この記事では、要求定義、要件定義、それぞれの意味の違いを説明するとともに、その重要性について解説します。ぜひともご確認ください。
Contents
要件定義と要求定義の違い
クライアントがシステム開発を依頼し、エンジニアがそれを実装しました。しかし、エンジニアの開発したシステムが、クライアントがイメージしていたものと違っていたということが、開発の現場でしばしば起こります。
なぜそのようなことが起こるのでしょうか？
そもそもクライアントは開発に関する知識に乏しく、自分が求めるシステムを開発して貰うには、どのような説明をすれば良いのか分からなかったということが想定されます。また、そのために、受注側に任せきりにしてしまったということもまた想定されます。
そうした事態を未然に防ぐには、クライアントと受注側で発生しうる齟齬を、早い段階でできる限りなくす必要があります。
そうした方法をマニュアル化したものが、要求定義と要件定義です。
クライアントが作成し、その要望をまとめたものを要求定義と言い、それを受けて受注側が作成するものを要件定義と言います。
ここでは、両者について詳しく見ていきます。
要求定義→要件定義の順に作成する
冒頭に述べたように、クライアントが要求定義を作成し、それを受けて、受注側が要件定義を作成します。
このように、ウォーターフォール型開発では、タスクに前後関係があります。先に行うものを先行タスクと呼び、後に行うものを後続タスクと呼びます。先行タスクが終わらなければ、後続タスクに移ることはできません。また、後続タスクに移った後は、先行タスクに戻ることはできません。
実際に、システム開発の基本プロセスを確認してみましょう。
システム開発の基本プロセス
要求定義と似たものとして、クライアントから提案依頼書（RFP）が支給される場合があります。そこには依頼するに至った背景、課題、目標、場合によってはスケジュールや予算などが記されていることがあります。基本的に、RFPは受注前に支給されるものです。
受注後は、要求定義、要件定義、設計、プログラミング、テスト、リリース・保守というのが基本プロセスになります。
つまり、案件化して最初に行うのが、要求定義、要件定義です。
業務要件・機能要件・非機能要件
要件定義は、業務要件、機能要件、非機能要件の3つからなります。そのため、要求定義も、その３つをカバーする内容が望ましいでしょう。それぞれの要件について解説していきます。
・業務要件
システムを開発する上で、クライアントの業務や業務フローについて知る必要があります。どんな業務フローで、どんな課題があるのか。新しいシステムをなぜ必要としているのか。クライアントと受注側でよく話し合い、システムを導入すべき箇所や、プロジェクトのゴールを確定します。
・機能要件
具体的に、どんなシステムを開発するかを決め、やること、やらないことを明らかにします。
例えば、クライアントが新しくサービスを立ち上げたいと思っているとします。また、そのサービスには、管理者サイドの機能が必要だったとします。
ログイン機能はいるのか、投稿機能はいるのか、投稿の承認体制はどうするのか、といった具体的な機能を決めます。このフェイズで決まったものだけを、実装フェイズでは作成していくことになります。
・非機能要件
機能要件以外に策定しなければならない要件もここで確定します。
システムの開発には含まれませんが、実現しなければならない事柄です。例えば、システムを24時間提供するのか、といった可用性と呼ばれる要件や、どの程度のユーザーの利用を想定しているか、といった性能面の要件などです。
他にも運用・保守、セキュリティに関することも、このフェイズで確定します。
要求定義書・要件定義書を作成する目的
もし、要求・要件定義書を作成することなくプロジェクトが進んだ場合、どうなるでしょうか？
上で見てきたように、要件定義では、業務要件、機能要件、非機能要件を定めます。
その３つが曖昧なまま開発フェイズに進んだ状態ということになります。
何をすればよいか、何をしなくてよいのか、ということが曖昧な状態なため、受注側はクライアントの望まないシステムを作成してしまうかもしれません。
そうなれば、クライアントから作り直しを求められるかもしれません。それにより、予算の超過や納期の遅れに繋がります。
ですが、要件定義書を作成し、クライアントと予め合意を得ることができていれば、提出した要件定義書通りのものを作成すれば済みます。
仮にクライアントの意に沿わない箇所が出てきても、要件定義書にない要件ならば、想定外のものとして扱うことが可能になり、追加見積、スケジュールの調整というように対応することも可能です。
また、要件定義を行うことで、プロジェクトの全容を確定することができます。予算とスケジュールも正確に把握することができるようになります。
このタイミングに再見積もりという形で、予算やスケジュールを改めて決定することができれば、予算的にもスケジュール的にもほぼ間違いのないものになるでしょう。
更に、開発段階に入れば、多くの人が開発に携わるようになります。
作成すべきものが、一つの資料にまとまっていることで、誰もが容易に参照できるという点でも有意義です。
このように、要件定義書は上流工程でも下流工程でも様々な目的をもって使用される、重要なものです。
要求定義書の記載項目例
要求定義書に記載される項目は、案件次第で変わりますが、一つ具体的な例を挙げます。
会員制のサイトを運営し、会員に向けて定期的に記事を投稿するサービスを運営する企業を例にします。
そのサイトは、フラッシュで開発されたレガシーなお知らせ機能のため、ファイルアップロードが機能しなくなっていました。
そのため、ファイルをアップする際は、運用会社に依頼して、サーバーにアップロードして貰い、発行されたURLを記事本文に貼り付けていました。
しかし、運営会社に依頼することでコストがかかり、また記事の投稿にも時間を要していました。この機能を使えるようにしたい、というのが今回のオーダーです。
要求定義書には、そうした業務の背景や課題を記載します。
また、そのサイトは、SP対応もしていなかったため、SP対応をして欲しい旨も記載します。その他は現状のシステムをなるべく踏襲してほしかったため、現状のシステムについても可能な限り記載しました。
記事投稿は、3名で行っており、ログインするのは3名、部署をまたぐことはなく、機能的に承認のプロセスは必要ないこと、などです。
こうした内容を明文化し、受注者に支給します。
要件定義書の記載項目例
上記の要求定義書を元に、要件定義書を作成する例を挙げます。
現状のシステムを解析した結果、主要アクティビティとして、ログイン機能、パスワード管理機能、投稿管理画面、記事投稿機能、記事編集機能、トップページの見出し一覧機能、ニュースページの詳細機能があることが分かりました。
これらについて、現状を踏襲する旨が記載されていたため、SP対応のみ実装すれば良いか念のため確認したところ、記事投稿機能で、一部使いにくい箇所があり、その部分の改修も依頼されました。
また、ファイルアップロード機能は一から開発が必要なため、要件を確認したところ、10個のファイルまで一度にアップロードできるようにして欲しい旨を依頼されました。
サーバーに関する要件としてPHPやMySQLの動作が必須だったため、クライアントにはその旨を確認しました。
こうしてまとまったものを要件定義書として、クライアントに提出しました。
誰が・どの書類を作成すべきか
これまで述べてきた通り、要求定義書は、クライアントが作成するものです。要求定義書の内容を受けて、受注者側が作成するものが、要件定義書です。
最終的には、システムを開発する上で必要な要件定義書の完成を目指します。
その意味では、要求定義書は必須ではありませんが、要求定義書があることで、要件定義書の作成はスムーズに行き、クライアントと受注側の認識のずれを抑える効果も期待できます。認識のずれは、システムの品質を左右するため、その意味では要求定義書があることが理想です。
要求定義書と要件定義書を確認し合い、合意形成を行うことができれば、互いの認識のずれを最小化することができるでしょう。
まとめ
受注側は、要件定義書を作成することで、やることやらないことを確定することができます。手戻りによる予算の超過や、納期の遅延といった様々なリスクを低減することができます。
また、クライアントは、要求定義書を作成することで、要件定義の工程をスムーズに進行し、受注者側との認識のずれを極小化することができます。
認識のずれを抑えることができれば、期待通りのシステムが納品される確率があがります。
このように、クライアントにとっても、受注者にとっても要求定義、要件定義書の工程はとても重要なフェイズとなっています。
フリーランスの案件をお探しの方はTechReachにご相談ください。
TechReachを運営する株式会社アールストーンはIT・Web業界特化で15年以上の実績がございます。
そのため、高単価・高品質な数多くの案件紹介が可能です。
また一人のコンサルタントが企業と求職者様の担当を行う「両面型エージェント」を採用しているため、あなたの希望に合う案件がきっと見つかるはずです。
TechReachを活用して、理想の案件を見つけましょう！
