システム開発における必須事項「要件定義」とは？その重要性を解説。

システムの「要件定義」とは？

「要件定義」という言葉を聞いたことがあるでしょうか？システム系をはじめとして、IT系の開発案件では必ず必要とされるのが「要件定義」です。

全ての開発案件において、成果物のリリースを含むスケジュールは、この要件定義に沿って組まれていくことになります。つまり要件定義とはシステム開発において必要とされる全ての事柄が明確化された情報を文書として残すことを言います。

要件定義で決めるべきことは、基本的にはシステム開発の最中に行われる実行内容全てです。そして、リリースまでに実施されるべき内容を共有化するために文書化することが求められます。ある一つのシステム開発案件は、製品のリリースという目的があり、いつまでにリリースしなければいけないか？最終的にいくらの予算で抑えなければいけないか？開発メンバーはそれぞれの項目で何人必要か？どのような作業項目があるのか？などが組み合わされて進みます。

開発案件に関わるメンバーがごく少数であれば口頭ベースや、ラフな文書の共有で遂行可能な場合も考えられますが、大規模な開発案件であれば、例えばエンジニアだけではなく営業や業務管理など、いわゆる事務方のスタッフも絡んでくることは珍しくありません。特に営業はクライアントに開発状況の進捗を報告・共有したり、途中でクライアントから修正の要望や見直しの要望があった場合には迅速に現場、クライアント双方と情報共有する必要がありますので、クライアント側に「今はこのような状況です」と示せる指針が必要になります。

クライアント側も、現場が関わった工程管理表などを共有されれば、開発の成功をイメージしやすくなりますし、不安から細かい要求を増やしてしまうことも少なくなります。このように、開発現場全体の業務を円滑に進めるために必要とされるのが要件定義だということになります。

要件定義が曖昧で、抜けや漏れが多い場合はスケジュールが想定通りに消化できず、修正や追加なども増えてしまうことになります。要件定義に入っていないものは想定外の事象だということになってしまうため、開発スケジュールに組み入れられていないからです。要件定義がしっかりとされているかどうかで開発が成功するかどうかを左右すると言っても過言ではありません。

そのため、要件定義を主導する担当者は、開発案件の経験が豊富な人物が務めることが望ましいとされています。

要件定義と要求定義の違いとその関係

システムの開発案件をどう進めればいいのかを考える時に必ず直面するのが要件定義ですが、こうした開発プロジェクトの際に聞かれる言葉として「要求定義」という、要件定義に似た言葉があります。

では要求定義とはどんなもので、要件定義と何が違うのでしょうか？要求定義というのは、クライアントが成果物に対して何を求め、期待しているのかを明確にする作業のことです。クライアントは自分達が欲しいもの。実現して欲しいこと。実装して欲しい機能などを開発者・技術者に伝え、開発する内容を具体的にする必要があります。

つまり、要求定義とは実際の開発作業よりも前に行われることなり、クライアントと開発チームの認識合わせを要求定義を通じて行うことになります。そのため要求定義は要件定義よりも先に行われ、要件定義は要求定義に基づいて設定されることになるのです。

要求定義のほうが要件定義より先に行われるということは、要求定義がうまく行かない場合は要件定義も片手落ちになる可能性が高くなってしまい、最終的には開発プロジェクトそのものがうまく行かない可能性を生んでしまいます。そのため、要求定義の失敗はシステム全体の失敗に直結する、と言われています。

システム開発をゼロから行う場合、一般的な進め方としては、要求定義をまず最初に行い、そこから基本設計や詳細設計、要件定義を行ってから開発を始め、実装とテストを繰り返してクライアントと成果内容を確認してから納品し、稼働が開始される、という流れになります。

つまり、要求定義がないと全体の設計や要件の定義が行えないため、その後の開発スケジュールに大きな影響を及ぼしてしまうことになるのです。

システム要件定義とソフトウェア要件定義の違いとその関係

要件定義よりも要求定義のほうが先に行われるということをご紹介し、要求定義と要件定義の違いについてもご理解頂けたと思います。しかし、実は要件定義の中でも「システム要件定義」と「ソフトウェア要件定義」を分けて行うことになり、この2つにも違いがあります。

読んで字のごとくではありますが、「ソフトウェア要件定義」は開発プロジェクトの中でソフトウェアに関する要件だけを定義した部分のことを言います。対して、システム要件定義とはソフトウェア要件定義も含めた、システムの全体的な要件を定義する作業です。ただし、ソフトウェアがベースとなってシステムが機能することになりますので、ソフトウェア要件定義はシステム全体の要件定義の中で最も重要な項目に関する要件定義だと言うことができるでしょう。

要件定義が重要な理由

要件定義がここまで重要視されるのは明確な理由があります。それは、クライアントと開発チームの間でしっかりと合意形成がされた状態で開発がスタートしていることを相互に確認できるようにするためです。

「どんなソフトウェアや機能が搭載されていて」「どのような目的で」「どんなシステムがリリースされるか」ということが明文化されていないと、開発の軸がブレてしまい最終的な成果物がクライアントから検収を受けられなかったり、手戻りを起こして様々な開発コストが二重にかかってしまうことにもなりかねません。

開発チーム全体とクライアントとの合意形成に使われるだけではなく、要件定義で定められた事柄が文書化された要件定義書は、開発チーム内の技術者達にとっては「開発のロードマップ」であり、目指すべき場所が記されたものです。開発中に生じた疑問があったとしても、要件定義書を見れば自分の行っている作業内容や進捗状況が、本来の目的にあっているかどうかがすぐわかるようになっています。

要件定義書には「機能情報関連図」のように、システムに組み込まれる各種ソフトウェアがどのうに相関関係を気づかれているべきかという「あるべき姿」が含まれています。機能テストなどを行う場合にはこれらの情報を元に状況の共有や報告が行われることになります。

システム要件定義の基本的な進め方

では、実際にシステム要件定義を行う時にはどのようなことが行われるのでしょうか？

重要性はここまでにご説明してきたように高いとはいえ、実施する内容としては、開発を進めていく上で絶対に必要なことを一つ一つ確認しながら文書化していくというのが実際の内容です。

実際に行われるのは次のような項目です。

1.課題と目標の明確化

何か新しいシステムを開発する時というのは、今のままでは効率が悪かったり、現状を改善するための何か。つまり解決したい課題があると考えるのが一般的です。

したがって、新しいシステムを開発するにあたっては、何のためにシステム開発を行うのか？という大元の目的と、どのような課題を解決するためのものなのかという理由を明らかにしておくことが大切です。ここを抑えておかないと、開発を進める最中に目的と理由を見失い、本来の開発目的からずれてしまうことに繋がってしまいます。

また、課題と目標が明確になっていれば、開発の途中で内容の確認や調整、あるいは変更が行われる場合でも合意形成のベースになる根拠＝共通認識になるため、認識合わせにも役立ちます。

2.全体的なシステム構成の明確化

次に必要なのはシステムの全体構成を明確化することです。

「システム」と一言で言っても、実態には様々なケースがあります。Webサーバーで稼働させるためのシステムもありますし、ネットワークには接続させないで使用するスタンドアローンシステムもあります。PCのみ、タブレットのみなど、デバイスを限定したシステムもあり得ます。

単純なことですが、どのデバイスで稼働させることを前提にしているのか？ネットワークへの接続は想定されているのか。されているのであれば複数IDによる同時接続やマルチユーザーログインなどは実装するのか？などなど、想定される使用ケースを限定したり、明確化しておく必要があるのです。

仮にこの段階で明確化されずに残ってしまった要素は、その要素を実装しなければいけない場面が現れた時にイレギュラーケースとして扱われることになり、本来なら計上されるはずがなかった追加の開発コストや、これまでの修正作業が必要な場合はその修正コストも計上されることになってしまいます。

場合によっては追加のハードウェアを必要とする場合もあるため、システムの全体構成については可能な限り細かく正確に明確化することが求められます。

3.機能要件の定義

全体的なシステム構成を明確化した後は、詳細部分を詰めていきます。システム要件定義は多くの場合、機能要件と非機能要件の2つにわけて定義されます。

機能要件とは、実際にシステムが稼働した時に実行される機能そのものに関する要件。

対して非機能要件とは、拡張性や運用性、保守性やセキュリティの強度など、実際の機能以外の要件のことを言います。

機能要件は業務中に使用する機能に関わるものであるため、稼働開始後に現状の業務をどのように改善することができるかということを説明する内容が含まれることになります。そのため、記載されるべき内容としては「現状の業務フローと効率性に関する詳細」があり、その後に「今回のシステム開発によって、どのような点が改善され、その改善が現行の業務フローにどのような好影響を与えるか」というものになります。

現行の業務フローと改善後の業務フローを並列して定義することによって、開発され運用されるシステムが実際に与える効果について、より明確に示すことが可能になります。これらの現行フローと「目指すフロー」を実際のフロー図に書き起こすこともよく行われます。両方のフローを対比させることで現行フローのどこに問題があり、なぜそれを改善させるために新しいシステムの開発が必要なのかを可視化させることが可能だからです。

4.非機能要件の定義

非機能要件とは、拡張性や運用性、保守性やセキュリティの強度など、実際の機能以外の要件のことだということはご紹介しました。機能要件と同様に、この非機能要件も、実際の開発作業開始前に明確化しておかなければならない要素だと言われています。

非機能要件に含まれるものとされている中に「性能」に関するものがありますが、この性能に関する要件が明記されていなかったために、結果としては処理量過多になってしまい、最終的にPCがクラッシュしてしまったというケースもあります。性能面での定義は重要で、現代では多くの場合においてPCなどの性能がアップしているために問題が顕在化することは少なくなっているものの、だからこそ見落とされがちな落とし穴だとも言えます。

理論上では問題のない開発内容だったとしても、それが現実に運用可能なものでなければクライアントにとって使いやすいシステムだとは言えません。機能要件と非機能要件が双方ともに必要とされているのは、このような「理想と現実のミスマッチ」を減らすためだということが言えるでしょう。

5.予算、スケジュール、プロジェクトのメンバー構成、コミュニケーション手段の確認

開発プロジェクト全体の予算とスケジュール、開発に携わるメンバーの構成や、どのようにコミュニケーションを取るかなどについても定義しなければなりません。

システム要件で明確化した内容を実現させるために必要なハードウェアコストや、作業工数などから算出される人的コストを総合的に計算して作業単価(多くの場合は時間単価で計算)を算出し、設定します。こういったコストも細かく算出しなければ、最終的に必要とされる予算を決めることができません。もしこのような確認を怠ってしまうと、実際に必要な開発予算が足りなくなり、プロジェクトが最終的に赤字になってしまうことになりかねません。

機材の調達コストも重要ですが、同じかそれ以上に考慮しなければいけないのが人的コストです。開発内容によっては実装機能が多岐に渡るため、それぞれの分野に精通した技術者に加わってもらう必要がありますが、手当たりしだいに参加してもらうとその分の人件費が開発予算に上乗せされてしまいますので、本来であれば最終的にクライアントに請求される金額も増額されることになります。

そのため、進め方としてはラフなスケジュール案を組んでおき、要求定義を明確化した段階で仮の参加メンバーを想定することで予算組みのミスマッチを防ぐことが可能です。

6.要件定義書の作成

最後に行うのが「要件定義書の作成」です。要件定義書には、ソフトウェア要件も含めたシステム要件、開発に必要な予算を含めた全ての情報が盛り込まれることになります。

要件定義書は、それを読めば「どのような開発プロジェクトなのか」が一目瞭然になるレベルまで細かく明確に記載ｓれていることが理想的です。ただし、場合によってはまずラフな要件定義書を作成しておき、2回目の打ち合わせなどを経て最終的な確定版を作成することもあるようです。

いずれにしても、要件定義書がしっかりとしていればプロジェクトメンバーにも安心感を与えられますし、逆に言えば要件定義書のクオリティーが低い状態では開発がうまくいかない可能性も出てきてしまいます。要件定義書の作成には最大限の注意を払うことが求められます。

システムの要件定義をスムーズに進めるためには必要なこと

システムの要件定義は開発プロジェクトにとって生命線とも言える重要な事項であることをご紹介してきました。

では、開発に失敗しないためのクオリティーの高いシステム要件定義を行うために必要なこととはどのようなことなのでしょうか？

理想的なのは、クライアント側も自社の担当営業にも、一定レベルのIT知識やスキルを身につけてもらうことが理想です。開発メンバーとして困ることの一つに、現実には難易度が非常に高かったり、場合によっては不可能とも言えることを、要求者側が知らないために無理強いしてくるということがあげられます。クライアント側にIT知識を持ってもらうことは場合によっては難しいこともありますが、少なくとも自社の担当者には開発メンバー側の心情を理解できるレベルまではIT知識や一定のスキルを身につけてもらうほうがいいでしょう。

それと同時に、開発側に必要なこととしてはクライアント側の事情や業務実態を理解することがあげられます。技術的に難易度の高い要求をクライアントがして来たとして、一瞬立ち止まって「なぜクライアントがそのような要求をしているのか」を理解することで、別の解決策を提示できることもあるからです。

まとめ

ここまで、システムの要件定義とは何か、についてご紹介してきました。要件定義と要求定義の違いや、要件定義がなぜ必要なのかという根本的なことについても解説しました。開発プロジェクトは技術メンバーだけで進められるものではなく、発注者、クライアント側の要望や希望があってはじめて始まるものだとも言えます。要件定義書は重要ですが、要件定義書を作成することは目的ではありません。要件定義書を作成する仮定で行われるコミュニケーションを通じて、発注者側と開発側が相互理解を深め、円滑に開発を進められる環境を作ることが本来の目的だということを抑えておくようにしましょう。