要求定義の進め方 ｜ 要件定義と何が違う？

要求定義と要件定義、似ている言葉ですが、その意味と役割は異なります。 端的に言えば、要求定義は「顧客がシステムに求める機能や目的を定める」工程で、基本的に発注側で実施・作成されるものです。

それに対して、要件定義は「顧客の求めるシステムを実現するために必要な要件やコストを明確にする」工程で、こちらは発注を受けたSIerやベンダー側で実施・作成されます。

どちらもシステム導入における上流工程に含まれており、これらに不備があると、その後の開発工程すべてに影響が及ぶため、細心の注意を払って取り組むべき工程と認識しておきましょう。

システム開発基本の流れ

　システム開発プロセス

業務改善や業務改革（BPR：ビジネス・プロセス・リエンジニアリング）、あるいはDX（デジタルトランスフォーメーション）に取り組む際のシステム導入は、ほとんどの場合でV字モデルに準じて進められます。 下記の図にあるとおり、ソフトウェア開発は「要求定義」から始まり、「要件定義」へ続き、「設計」＞「実装/開発」＞「テスト工程」を経て、市場へと進んでいきます。

ビルや家屋の建築と同様に、ソフトウェア開発ではすべての工程が相互に結び付き合いながら先へ進んでいくため、下流の工程になればなるほど軌道修正が困難になります。したがって、出発地点の「要求定義」に不備があれば、求めていたイメージ像から大幅に乖離した結果となり、またイチからやり直し……、といった事態が発生してしまうのです。 そうなると、予定していたリリース時期に遅延が生じ、コストが大幅増してしまうほか、場合によってはブランドイメージに傷がつく恐れもあるでしょう。

　要求定義から要件定義までの流れ

システム導入に取り組む際は、まずはシステムに何を求めるか、という要求をまとめなければなりません。あくまで参考程度の例示ですが、要求には下記のようなものが挙げられます。

• • 営業支援システム（SFA：Sales Force Automation）で営業の予算を管理したり、案件ごとの商談進捗を確認したりして情報の一元化を図りたい。

• • 顧客管理システム（CRM：Customer Relationship Management）によって、見込み客や既存顧客の情報を一元管理し、効率的にアプローチできるようにしたい。

• • サプライ・チェーン・マネジメント（SCM：Supply Chain Management）を取り入れて、製造から販売までの工程を最適化し、最低限のリソースで最大限のパフォーマンスを発揮できるようにしたい。

なんのためにシステムを導入するか、どういった恩恵を得たいのか、という要望が不明確だと、実際には不必要な機能までシステムに組み込まれて余分なコストがかかったり、描いた絵図とは異なる残念な結果を招いたりしてしまいます。

発注側がシステムに何を求めるか書き出した文書を「要求定義書」といい、SIerならびにシステムベンダーは要求定義書に基づいて「提案依頼書（RFP：Request For Proposal）」を作成します。

この要求定義書に誤りや記入漏れがあると、不完全な状態でシステム設計が進められることになるため、発注側の担当者は抜かりなく現状とシステム導入後の展望を明確にしておかなければなりません。

ところが、現状分析とシステム導入によって得られる恩恵を可視化することに苦労される企業の担当者は少なくない、というのが実情です。 その理由として、企業規模が大きければ大きいほど業務は枝分かれし、末端の状況まで明確に把握することが困難になったり、そもそもシステムを導入することで何がどう変わるのか、具体的にイメージできなかったりすることが挙げられます。

まさに日進月歩で進化を続けるITの動向を最先端で把握し続けることは容易ではなく、今の世の中にはどんなツールがあって、競合他社ではどのようなIT化がおこなわれていて、自社に最適なIT化とはどういうものなのか、ということを知るためには相応のリサーチが求められます。

もし、ネームバリューだけでシステムの導入を決めたり、同業他社がやっているからという理由だけで見様見真似のIT化を進めてしまったりすると、実際に使ってみたら自社にとっては無用の長物だった、という結果になりかねません。

そのような事態を防ぐためにも、業界知識豊富なコンサルタントを活用してみるのも有効な手段といえるでしょう。

要求定義がまとまれば、それをもとにシステムベンダーは「提案依頼書（RFP：Request For Proposal）」を作成します。このRFP作成にあたって、要求定義書は必ずしも用意しなければならないものではありませんが、発注側とベンダー側の認識を合わせるためにも作成するに越したことはありません。

RFPが作成され、発注側が合意すれば、続いて要件定義書が作成されます。 ベンダーは発注側の要求を叶えるために必要なシステムの要件を精査し、そもそも技術的に可能かどうか、あるいはどういった機能や性能が必要になるか、といった点を要件定義書に取りまとめます。 　要件定義書に問題なければ、発注側とベンダー側の双方が合意したうえで、「基本設計」以降の工程へと進んでゆきます。

要求定義でおさえておくべきポイント

　プロジェクトの目的を明確にする

IT化、DXに取り組む際は、そもそも“なんのためにシステムを導入するのか”という達成すべき目的を明確にしておかなければなりません。 ほとんどの場合、業務改善や業務効率化を叶えるためにシステム導入が検討されますが、何をもって改善・効率化とするか、導入前と導入後の差異を把握しておく必要があります。

　現状分析から理想像を導き出す「As-Is/To-Be分析」

業務改善・業務効率化のプロジェクトでは、「As-Is/To-Be分析」という手法がよく用いられます。As-Is（現状）の業務フローを図に起こし、課題となる部分（ボトルネック）を特定することで、To-Be（あるべき姿）を導き出す分析手法です。 これにより、現状維持すべき点と改善すべき点を可視化することができ、システムに必要な要件（機能・性能）を見極められるようになります。

　QCD：Quality（品質）Cost（費用）Delivery（納期）のバランスを考える

プロジェクトを進めるうえで大切になるのが、QCDのバランスを考えることです。 このQCD（品質・費用・納期）は三竦みの関係となっており、 ・コスト減＞利益率向上　しかし　品質低下＞手戻り増加＞遅延発生

・品質向上＞顧客満足度向上　しかし　コスト増＞利益率低下 といったように、どこかで問題が生じれば相互に影響し合うため、それぞれの状況を把握しながら、ちょうどよいバランスを見定め、維持することが重要です。

要求定義の進め方 ｜ 目的と骨子の明確化

　プロジェクト憲章を作成する

要求定義に取り掛かる際は、初めに「プロジェクト憲章」を作成しましょう。 プロジェクト憲章（Project Charter）とは、プロジェクトの開始時に作成される重要な文書で、プロジェクトの正当性を確立し、目的・範囲・目標・関係者などの基本的な情報を記載したものです。 以下に、プロジェクト憲章に関する重要なポイントを記載します。

目的と正当性

プロジェクトの目的と正当性を明示しましょう。プロジェクトがなぜ実施されるのか、という点について、ビジネス上の観点から戦略的に重要であることを示します。プロジェクトの背景や動機、問題の陳述なども含まれます。

プロジェクトの範囲

プロジェクトの範囲を定義することで、プロジェクトが何を含み、何を含まないのかを明確にします。範囲の境界・主要な成果物・納期・予算・リソースの制約などが含まれます。

目標と成果物

プロジェクトの目標や主要な成果物を明記します。成否を分ける基準や期待される成果物の特定要件、品質基準なども記載されます。

プロジェクトの関係者

プロジェクトに関係する主要なステークホルダーを識別し、それぞれの役割と責任を明確にします。スポンサーや顧客、プロジェクト・マネージャー、チームメンバーなどの関与について記載します。

承認と権限

プロジェクト憲章は、プロジェクトの承認者やスポンサーによる承認を得るための有効な手段となります。プロジェクトの範囲や目標に同意し、プロジェクトの開始を承認する人物を明記します。

　要求定義書の目次

これまでに述べてきたとおり、要求定義はすべての始まりとなる工程であるため、ここを疎かにすると、川上からの濁流が川下まで汚染してゆくように、プロジェクト全体の成否に大きな影響が及ぼされます。

そのような事態を防ぐために、少なくとも下記の項目は要求定義書に記載しておかなければなりません。

ステークホルダー（利害関係者）の特定

プロジェクトに関与するステークホルダーを特定し、そのニーズや要求を把握します。関係者の意見や期待を収集するために、インタビューやヒアリング、ワークショップなどのコミュニケーション手法を使用します。

ビジネス目的と目標の明確化

プロジェクトのビジネス目的と目標を明確にします。プロジェクトがなぜ実施されるのか、どのような価値や利益が得られるのかを定義します。

要求事項の特定

プロジェクトに関連する要求事項を特定します。ステークホルダーの要求や期待、ビジネス上の要件などを洗い出し、文書化します。

要求事項の整理と整合性の確保

特定された要求事項を整理し、関連性や優先順位を評価します。重複した要求事項や矛盾した要求事項を特定し、解決策を見つけます。

要件の文書化

特定された要求事項を具体的な要件として文書化します。要件は明確で一意であり、測定可能で検証可能でなければなりません。要件の文書化には、要件定義書や要件仕様書などの文書を使用します。

要件のレビューと承認

文書化された要件を関係者にレビューしてもらい、フィードバックを収集します。要件の正確性や完全性を確認し、関係者の承認を得ます。

変更管理

プロジェクトが進行するにつれて、要求事項や要件に変更が生じることがあります。変更要求を受け入れ、適切な変更管理プロセスを実施します。

要求定義はプロジェクトの成功のために重要なステップであり、ステークホルダーとの良好なコミュニケーションや要件の明確な文書化が必要です。柔軟性と適応性を持ちながら、要求事項を適切に特定し、関係者との共有と合意を確保することが重要です。

要求定義と要件定義の関連性

業務要求―業務要件／機能要求―機能要件｜各項目の結びつき

要件定義は、要求定義をもとに実施される工程です。 したがって、双方の各項目は、プロジェクトの要求事項を明確化し、具体的な要件を定義するために密接に結びついています。

背景・目的

要求定義では、プロジェクトの背景や目的を明確にします。これにより、要件定義ではどのような機能や要件が必要になるか理解しやすくなります。

業務要求―業務要件

要求定義では、プロジェクトが対象とする業務プロセスや要求事項を特定します。要件定義では、これらの業務要件を具体的なシステム機能や操作に落とし込みます。業務要件から派生した機能要件が要件定義で定められます。

次の機能要件は業務要件に紐づいて作成されるため、対象の業務を明確に洗い出すことが大切です。一般的には「業務フロー」を図に起こすことで、業務を可視化して一覧にします。

機能要求―機能要件

機能要件は、要件定義で定められる具体的なシステムや製品の機能に関する要件です。これは、要求定義で特定された業務要件をもとにして定義されます。機能要件では、システムが提供する必要がある操作、データ処理、ユーザー・インターフェースなどが明示されます。

非機能要件

非機能要件は、要件定義で定められる機能以外の要件です。要求定義では、システムや製品に関する品質要求や制約条件が明確にされます。要件定義では、これらの非機能要件を具体化し、システムの性能、セキュリティ、信頼性などを明示する必要があります。

対象となる項目が最も多くなるフェーズですが、IPA（独立行政法人 情報処理推進機構）によって、「非機能要求グレード」が規定されているため、こちらと照らし合わせることで項目漏れを防ぐことができます。IPAが定める「非機能要求グレード」には、主に下記の項目が挙げられています。

●可用性

可用性とは、システムが正常に動作し、利用可能な状態にある時間の割合を意味します。高い可用性を持つシステムは、利用者にとって中断や障害の影響を最小限に抑えることができます。

●性能・拡張性

性能とは、システムの処理速度や応答時間、リソース使用量などの面における能力を意味します。

拡張性とは、システムが将来的な需要や規模の変化に柔軟に対応できる能力を指します。

●運用・保守性

運用・保守性とは、システムの運用や保守作業の容易さや効率性を指します。運用性が高いシステムは、管理やモニタリングが容易であり、保守性が高いシステムは、変更や修正にかかる負担が少なく済みます。

●移行性

移行性とは、システムやデータの移行作業の容易さや安全性の度合いを意味します。システムやプラットフォームの変更、データの移行などが必要な場合、移行性が高いシステムはスムーズな移行が可能です。

●セキュリティ

セキュリティは、システムやデータの保護を意味します。適切なアクセス制御、データの機密性、セキュリティ脆弱性への対策などが含まれます。セキュリティが確保されたシステムは、機密情報やプライバシーの保護に貢献します。

●環境・エコロジー

環境・エコロジーは、システムの環境への影響や持続可能性に関連します。エネルギー効率、リサイクル性、廃棄物の削減など、環境への配慮が考慮されたシステムは、持続可能な社会に貢献します。

これらの項目は、非機能要求の一部であり、システムやソフトウェアが要求を満たすために重要な要素となります。具体的な要求レベルや重要性は、プロジェクトやステークホルダーのニーズに応じて詳細に定義されます。

ソフトウェア品質とは|上流工程が重要|品質を学ぶ で紹介した下記２つの障害例は非機能要件の考慮漏れが原因であると考えられます。

＜不具合起因の障害例＞

• • みずほ銀行、システム障害

• • NTTドコモ通信障害

「要求定義―要件定義」に不備があると、以降の開発工程でも見落とされたまま先へ進み、リリース後にシステム不具合が発生することもあります。製品やサービスが市場に出てから不具合が発覚すると、修正に莫大なコストが必要になりますし、ブランドイメージに大きな傷がつき、社会的信用は著しく損なわれてしまうことでしょう。

まとめ・要求定義の進め方ガイド

要求定義と要件定義は、顧客の要望を洗い出し、プロジェクトの目的やニーズを明確にするためのものとして、密接に連携しています。要求定義によって明確化された要求事項をもとに、要件定義で具体的な機能要件や非機能要件が定められます。相互に補完し合うことで、要求定義と要件定義はプロジェクトのスコープと要件の整理に貢献するのです。

　具体的な要求定義書に記載する内容については、下記ボタンから「要求定義の進め方ガイド」をダウンロードしてください。