「要件定義書」とは何のこと？必要な項目のサンプルや注意点について解説！

要件定義書とは？要件定義書の目的

要件定義書はシステムやアプリケーションなどの開発を行う際に、エンドユーザーである顧客が要望する内容を、システムエンジニアなどのエンジニアが技術的な見地を交えて作成する「まとめ文書」のことです。また、この要件定義書を作成するためには何度かの打ち合わせが行われ、その中で顧客が何を求めていて、どんな製品やシステムを開発したいと思っているのかを確認することになります。この過程のことを要件定義と呼びます。

この要件定義で決まった事柄を文書にまとめたものが要件定義書です。要件定義にもエンジニアは参加し、要件定義書はエンジニアが作成するのですが、この段階ではプログラミングなどの開発作業は実際には行われません。実際に開発作業が行われるのは要件定義で顧客の要望事項が明確化され、要件定義書が正式に顧客と開発チームの間で双方合意により承認された後のことになります。

要求仕様＆要求仕様書との違い

要件定義を行い、要件定義書を作る前提として、顧客からの開発要望があるということがあります。顧客が望むシステムやアプリケーションがあり、それを具体化させることが開発になるわけですが、要件定義を行うためにはまず顧客が具体的に何を要求しているのかを明確化する必要もあります。

基本的に要求仕様は顧客がまとめ、要求する仕様内容がまとめられた文書のことを要求仕様書と呼びますが、顧客は開発を専門にしているわけではないため、技術的に難しい要求や、現実的には不可能だと思われる要求も記載されることが多々あります。しかし、まずは具体的な要望や要求がわからないことには技術的に可能かどうかということや、そもそも何を開発すればいいのかということもわからないため、要求仕様をまとめ要求仕様書を作成することは非常に重要なことだと言えるでしょう。

基本的に顧客がまとめると書きましたが、実際には要件定義と要件定義書の作成と合わせて行うことがあります。要求仕様のまとめと要件定義を同時にまとめ、要求仕様書と要件定義書を同時並行で作成することもあります。

RFPとは？

要求仕様や要件定義、そして要求仕様書や要件定義書を作成する過程において、顧客側が「RFP」を提示してくることがあります。RFPとは「Request For Proposal」の略で、日本語では「提案依頼書」と呼ばれる書類です。

要求仕様の内容をベースにしてエンドユーザーが開発側に提出するものなのですが、簡単に説明すると「こういう内容のものを作りたいので、良いアイディアや技術的なアドバイスがあれば教えて下さい」という要望を伝えるための文書です。

どのようなシステムやアプリケーションであるか。必要だと考えているハードウェアはどのようなものを想定しているか(サーバーやその他機器類など)。開発しようとしてるのはどのようなサービスで、どんなコンセプトのものか。どの程度のユーザーが使うことを想定していて、どのような最終形を目指しているのか。依頼したいのはどのようなことで、どのような条件で依頼したいのか。想定している契約内容はどのようなものか。などなど、一例としてここまで記載してきたような事柄を記載して開発側と発注側(エンドユーザー)が共有することになります。

開発側は提示されたRFPを読み込んだ上で、エンドユーザーがどのようなものを求めているのかを把握し、現時点で想定されている開発項目や内容を確認して、「自分達ならこうする」「こうしてはどうか」という提案内容をまとめていきます。このようにして開発側から届いた提案書の内容を最終的にエンドユーザーが確認し、どの企業に開発を正式発注するかを決定することになります。

民間企業同士の取引の場合は、最初から決め打ちのような形になっていることも多く、最終的に発注することになる前提ではあるものの、経緯や開発内容、要求仕様や要件定義などをしっかりと明文化して残すためにRFPと提案書のやり取りをすることも多いのですが、官公庁や公的機関の場合は一般競争入札になることが多いため、複数の会社にRFPを送付されることが多く、そのRFPに対して提出された複数の提案書を比較検討し、最終的に発注先が決定されることが多いです。

要件定義書に記載すべき項目の代表例

要件定義書とは何かということや、要件定義書が作成されるまでの過程についてご説明してきましたが、実際の要件定義書の内容をサンプルとして、どのような項目が記載されるべきかということもご紹介します。

要件定義書は開発プロジェクトにとって無くてはならないもので、要件定義書が無い開発というのは考えられません。例えば以前から進んでいる開発案件に途中から参加することになったり、年次更新のタイミングで別の開発チームなどから開発の継続を引き受けることなどもありますが、その際には必ず以前の要件定義書や、作り直す場合はサンプルの要件定義書などをもらって確認しておくことが必要です。

それでは、実際に要件定義書に記載すべき項目のいくつかをサンプルとして解説していきましょう。

システムに関する項目

要件定義書における最大のキーポイントはシステム全体の構成に関する項目です。この項目で「どのようなコンセプト、どのような目的のシステムなのか」ということを明確にしておかなければなりません。

「要件」にも種類があり、実際にシステムやアプリケーションを使うエンドユーザー目線で設定される「業務要件」と、技術的視点から考えられた「システム要件」があります。例えば商用目的で開発され、運営側とユーザー側の双方が使うことを想定したシステムの場合は、業務要件とシステム要件の両方が明示されている必要があります。

当然ですが開発する目的やシステムを導入するための目的なども明確化されている必要があります。目的がはっきり設定されていなかったり明らかになっていない場合は、技術的には開発可能で開発作業が進んだとしても、少しずつ本来の目的から外れてしまうことも無いとは言えません。「そもそも何をするための開発案件なのか」という「そもそも論」として語れる目的があるか無いかはとても重要なのです。

業務フローについても明確に記載することが必要です。「文字を入力したら自動的に検索される」であったり、「メールを送信したら送信したメール内容を自動的にコピーして保存する」などのシステム的なフローは、例え私達が日常生活では当たり前に使っているものだったとしても本来は「当然のこと」ではありません。システムやアプリケーションである以上は、「わざわざそのように作られている」のが現実なのです。

つまり「何がどうしてどうなるか」ということはプログラムの一種であり、システム化されてはじめて運用可能な状態になるため、それを要件定義書の中にまとめておく必要があります。

機能要件に関する項目

発注者側が求めている機能のことは機能要件と呼ばれ、システムが実際に開発完了になり運用が始まった際には「何ができ、どのように動くか」ということが明文化されます。これは言ってみれば開発案件全体の指標になる内容であり、エンジニアやその他の技術者にとって開発案件全体のゴールとして目指すべきものになります。

実際に記載される内容としては要件定義の中でも最初の段階で定義されている基本的な事が多いです。データの種類やシステム全体の構造、及び実行されるべき処理や処理後に実行される命令などが具体的に明記されることになります。機能要件が記載されるべき理由としては、発注者側が要求を伝えているものの、技術的な見地での完成形に関しては具体的なイメージが持てていない場合に備えるためです。そのため、機能要件について記載する時には特にしっかりと発注者にヒアリングを行い、細かく議事録などを取って明文化していく必要があります。また、このような確認・ヒアリングを行っている過程で発注者側に新たなイメージが膨らんでしまい、「あれもこれも」となってしまうことも可能性としてあり得るので、実際の開発予算が項目ごとにどれくらいかかるのかということも合わせて明示しておくと現実味を持たせながら話すことができるでしょう。

非機能要件に関する項目

発注者が求める実際の完成品に必要な機能以外で、付加価値となるようなもののことを非機能要件と言います。例えばシステムやアプリケーションの効率性や性能面で優れた点。さらにはセキュリティの強靭さや保守・運用のしやすさやアフターサービス等に関する項目です。実際に完成品を使用するエンドユーザーに直接関連性がなくても、製品自体の価値を高められるような要素が非機能要件にあたります。

通常は機能要件を具体化させた後で非機能要件を洗い出すことになります。多くの場合、発注者は完成品に盛り込みたい具体的な機能や価値についてはイメージできるのですが、製品がリリースされた後の付加価値的な要素についてはイメージしづらいことが多いです。最終的には非機能要件のサンプルとなるような事例をエンジニア側から具体例として提示し、なぜそのサンプル事例のようなものが求められ、必要とされるのかについて発注者側に説明する作業も求められます。

要件定義書をスムーズに作成するために必要なこと

良い要件定義書のサンプル条件としては、次のことが挙げられます。

専門知識がなくても内容が分かる

要件定義書は発注側と開発側が共有するものです。ただし、発注する側は技術的な専門知識がない場合も多く、要件定義書のサンプル事例も持ち合わせていないことが多々あります。そのため、開発側が要件定義書を提示する際にはわかりやすいサンプル事例などを挙げて、専門知識がない人でも理解しやすいように作ることが求められます。

専門用語や相手にわからない単語が頻出してしまう要件定義書を提示してしまうと相手から不親切な開発陣だと思われてスムーズなコミュニケーションができなくなり、開発に支障をきたす可能性もあるので気をつけるべきでしょう。

問題の解決策が記載されている

発注者側に専門知識がないことも考慮に入れると、問題点や課題をサンプルとして羅列するのは避けるべきです。そのような単語の羅列を見ても、発注者側はどうしたらいいかわからないことも多いからです。問題点や課題を列記すること自体は問題ありませんが、その代わりに解決策のサンプルも提示してあげると印象は正反対になり、しっかりと課題解決まで導いてくれそうな開発陣だという信頼感を得ることも可能になるでしょう。

まとめ

要件定義書とはどんなものなのか？どのようなことを書くべきかという項目のサンプルや、スムーズに要件定義書を作成するために必要なポイントなどを紹介してきました。開発案件にはつきものの要件定義書ですが、発注者の背景によっては要件定義というものがどういうものなのかもわかっていない場合があります。そのような時にはわかりやすいサンプル事例を使って丁寧に説明するのが良いでしょう。逆に自分が発注者側になる場合には、開発陣と連携を深めるために、要件定義から積極的に参加してみるのが良いでしょう。