システム開発において、要件定義については良く耳にするかと思いますが、「要求定義」について明確に説明できるという方はそう多くはありません。そこで本記事では、システム開発の要求定義について、概要をはじめ要件定義との違い、工程や成果物、ポイントなどを徹底解説いたします。
要求定義とは
要求定義とは、非技術者であるクライアントの目的及びニーズをヒアリングし、これから開発するシステムに何を求めているのか、そもそもなぜシステム開発をするのかを技術者であるベンダーが明確にする工程のことです。
もちろんヒアリングした内容だけを明確にすれば良いと言うことではなく、非技術者が言葉にできていない部分についても想像を張り巡らせつつ、過剰及び過少な要求はないかなど、最終的に実現可能なシステムの形を明確にする必要があります。
要求定義と要件定義の違い
よく耳にする要件定義とは、技術者がシステム開発するために定義する仕様のことを指します。つまり、非技術者であるクライアントが求めている要求をどのようなシステムで実現するのかをより具体的に考え、概要や機能要件、非機能要件などを定義するのです。
一方要求定義は、前述したとおり、あくまで非技術者であるクライアントからヒアリングを実施し、目的やニーズなどから開発するべきシステムはどのようなものなのか、なぜ開発が必要なのかを明確にすることであり、言葉は似ていても要件定義とは異なる意味を持ちます。
また、一般的なシステム開発工程としては、まずはじめに要求定義を行ってから要件定義を行い、基本設計、詳細設計、などと進めていきます。このことからも、要求定義は要件定義の前に行うべきものであり、本来要件定義の中で一色単にされない別工程という認識となります。
要求定義の工程
要求定義の工程は、下記のようにさらに細かく分類することができます。
- プロジェクトの目的を明確にする
- 現状から理想形を明確にする
- 品質やコスト、納期を明確にする
プロジェクトの目的を明確にする
要求定義を行う際、なぜ非技術者であるクライアントがシステム開発を行いたいと考えるに至ったのかという現状の課題と、その課題を解決するためにどのようなシステム開発を行うのかといったプロジェクトの目的を明確にする必要があります。
現状から理想形を明確にする
プロジェクトの目的を明確にしたら、非技術者であるクライアントが現状抱えている課題を踏まえながら、業務フローについて図に表すなどして業務の可視化を行い、さらにシステム開発後の理想形の業務フロー図も作成して、それぞれの業務の課題を照らし合わせつつ、開発するシステムについて搭載すべき機能などをすり合わせていきます。
品質やコスト、納期を明確にする
どれくらいの品質のシステムをどれくらいのコストや納期で開発するのかを非技術者であるクライアントに確認し、合意をとることも必要です。
要求定義の注意点
要求定義を行う際には、特に次の3点に気を付ける必要があります。
- プロジェクトが複雑化する
- クライアントの目線と開発者の目線は異なる
- 要件定義と一色単にしない
プロジェクトが複雑化する
何度も述べていますが、システム開発において要求定義では非技術者であるクライアントの目的やニーズ、要求を具体化します。しかし、クライアントが求める理想のシステムは、単に業務が効率化されれば良いというものではなく、あくまでビジネスの成長に欠かすことができない経営基盤の1つとして捉えられることが多くなってきており、だんだん複雑化してきているという現状があります。
そのため、要求定義の時点で、本当にクライアントが求めている正確な要求というものを明確にすること自体が難しかったり、明確にできても、プロジェクト自体がとても複雑なものだったりと様々な問題が生じる場合があるため、どこかで落とし所を見つけなければならないことも多々あるでしょう。
クライアントの目線と開発者の目線は異なる
当たり前のことですが、非技術者であるクライアントの目線と、技術者であるベンダーの目線は異なります。特にクライアント側は、要求定義の段階で、知識がないからとベンダーに多くを任せてしまうと、本来求めている使いやすいシステム開発ではなく、ベンダーが開発しやすいシステム開発に気づかずうちに舵を取られてしまい、最終的に完成したシステムが実際の現場では使用しにくく結果的に従業員達に利用されないものとなってしまうこともあるため、知識がなくとも、任せっきりにせず、要求をきちんとベンダーに伝えることが大切です。
もちろんベンダー側ももし多くを任せられることになったとしても、クライアントの目線で本当に使いやすいシステムなのかを所々で立ち止まって考える必要があるでしょう。
要件定義と一色単にしない
前述したように、要件定義と要求定義は本来異なり、別の工程となるべきものですが、多くの場合、要件定義の段階で要求及び要件のどちらも取り扱うことが多いという現状があります。しかし、それでは、非技術者であるクライアントの本来の要求を明確にする作業が曖昧なまま要件も並行して定義していくことになってしまうため、最終的に完成したシステムを納品した段階でクライアントが求めていたものと大きく異なるという事態になりかねません。
このことからも、あくまで要求定義を行ってから要件定義を行うように徹底することが大切です。
要求定義の成果物
要求定義での主な成果物としては次の2点が挙げられます。
- RFP（提案依頼書）
- 提案書及び見積書
- 要求仕様書
RFP（提案依頼書）
RFP（提案依頼書）とは、非技術者であるクライアントがベンダーに対して提案を依頼するためのドキュメント資料のことです。
RFP（提案依頼書）は、相見積もりをとる際にも用いられることがあり、具体的には、システム開発の目的をはじめ、自社の概要や組織体系、業務内容、現状抱えている課題、課題に対して達成したい理想的な形、開発するシステムに求める要求、プロジェクトに対しての自社の体制及び役割、技術者であるベンダーに依頼したい範囲、予算、想定納期、ベンダーに提案して欲しい事項などをまとめたものになります。一方でベンダーはクライアントから受け取ったRFP（提案依頼書）を要件定義に活用できます。
提案書及び見積書
非技術者であるクライアントからのRFP（提案依頼書）に対して、技術者であるベンダー側からの回答の役割を持つ資料が提案書及び見積書です。
具体的には、システムの提案をはじめ、プロジェクトの進行方法、ベンダーの体制及び役割などを、クライアントから提示された予算及び納期を踏まえて作成されます。
要求仕様書
正式な依頼となったら、ベンダーはRFP（提案依頼書）と提案書及び見積書を取りまとめ、よりわかりやすく要求仕様書を作成しておくとよりスムーズです。
要求定義のポイント
要求定義の段階では、様々な問題が出てきますが、解決するポイントをご紹介いたします。
要求仕様書を図式化及びレビューする
RFP（提案依頼書）などをもとに作成された要求仕様書は、文字だけでなく図式化したり、関係者間でレビューを実施することで非技術者であるクライアント及びベンダーの中でのギャップを埋めておくことができます。また、クライアントには可能な限り実際に使用するであろう現場の従業員を含めたレビューをしてもらうことが大切です。
まとめ
要求定義とは、本記事では、概要をはじめ要件定義との違い、工程や成果物、ポイントなどを徹底解説いたしました。
要件定義の中で要求定義も行われることが慣例化されている場合も多くありますが、本記事で述べた通り、本来は要求定義と要件定義は分けるべき工程です。非技術者であるクライアントのニーズにしっかりと応えるためにも、要求定義をきちんと行うようにしましょう。
