要求定義（要求エンジニアリング）とは何か？要求定義書作成の進め方をわかりやすく解説【プロジェクトマネジメントの基礎】
プロジェクトが始まると、関係する人物（ステークホルダー）を洗い出します。
その活動が終わった後は、プロジェクトで開発する製品やサービスに要望を持つ人から話を聞き、何を実現させるかを決める「要求定義（要求エンジニアリング）」を実施します。
今回はこの要求定義について解説していきます。
https://ssaits.jp/promapedia/concepts/fundamentals-of-pm-02....何故要求定義が必要なのか？
要求定義のお話を詳しくしていく前に、「何故要求定義が必要なのか？」を解説し、要求定義の目的を明らかにしていきましょう。
要求定義が何故必要かを一言で答えると、「自分の欲しいものを正しく伝えることは難しいから」です。
たとえば、あるお客さんがあなたに「ムシを殺す薬を作って欲しい」と頼んだとします。あなたはどのような薬をその人に作ってあげたら良いでしょうか？
部屋の中のハエなどを退治する殺虫スプレーかもしれませんし、農業用の殺虫剤かもしれません。
そして、苦労して作った殺虫剤をお客さんに渡すと「ちがう！私が欲しかったのは飼っている犬の体のムシを下す薬だ！」と言われたらどうでしょうか？
これは極端な話ですが、要求定義をしないままにプロジェクトを進めると、同じようなトラブルが頻発してしまいます。
要求定義の流れ
要求定義は以下のように進行していきます[1]Roger S. Pressman（著）、Bruce R. Maxim（著）、SEPA翻訳プロジェクト（訳）『実践ソフトウェアエンジニアリング(第9版) 』オーム社、2021年、76頁。。
- 方向づけ
- 要求獲得
- 精緻化
- 交渉
- 仕様化
- 妥当性確認
ここからは、要求定義の流れを詳しく追っていきます。
方向づけ
方向づけとは、開発しようとしているソフトウェアやプロジェクトの進路を決めることです。
たとえば「どのようなユーザーが求めているのか？」「どのような市場があるのか？」などを決めていきます。自分たちのゴールがどこにあるのかを共有することで、認識の相違によるプロジェクトのトラブルを防ぐことができます。
方向づけはプロジェクトが始まる前に固めておければよいのですが、まだの場合は下記の記事を参考に、方向づけを進めていくことをおススメします。
要求獲得
要求獲得では、ビジネス目標を達成するために、システムにどのような機能や非機能が必要かを洗い出していきます。
要求獲得のためによく使われる手法がブレインストーミングです。ステークホルダーたちとブレインストーミングを実施することで、効率よく要求を獲得することができます。
他には重要なステークホルダーへのインタビューや専門家のアドバイスなどによって、要求を洗い出していきます。
精緻化
精緻化とは、要求獲得で得られた要求の詳細を考えていくことです。ただ単に「お客さんがお問い合わせできるツールが欲しい」というようなあいまいな要求をもとに開発を進めると、さきほど紹介した「ムシを殺す薬」のように、開発したものと、要求を出したステークホルダーの認識が違うという事態がおきかねません。
そのため、要求を精緻化し、認識の齟齬が発生しないようにしていきます。
精緻化の際は、樹形図を使うことで、情報の整理がしやすくなります。
「ターゲットは誰か？」「いつ使うか？」「何色にするか？」などの情報を樹形図にまとめていくと、求めている機能が視覚的に把握しやすくなります。
しかし忘れてはいけないことは、ツールや手法に偏重せず、ステークホルダーの話を丁寧に聞くことです。
要求を整理する手法は樹形図以外にも多く存在しますが、その意味をステークホルダーが理解できなければ意味がありません。
ステークホルダーの話に耳を傾け、専門的な言葉を使わず、わかりやすく図解するなどの努力が大切です。
交渉
多くの場合、要求の精緻化が完了した後は交渉の段階に入ります。
交渉の代表例が、要求の優先順位づけです。
予算や期間が限られている中で、すべての要求を叶えることが難しいという状況は多々あります。そうした中で、どの要求を優先して実現するのかという交渉を、ステークホルダー間で行わなければなりません。
また、要求を実現するために使用しようと考えている人的・物的資源が、他のプロジェクトでも使用を予定しているということもあります。
たとえば、プログラマーのAさんにしかこの機能は実現できないのに、このプロジェクトと同時に動いている他のプロジェクトでも、Aさんへの依頼を考えているという場合は、プロジェクト間での交渉が必要になります。
仕様化
実現する要求が決まれば、その内容を仕様化（文書化）し、ステークホルダー間で認識の齟齬が生まれないようにします。
システムに対する要求の仕様化の際は、各要求について以下のような情報をまとめていきます[2]アラン・M・デービス（著）、萩本順三・安井昌男（監修）、高嶋優子（訳）『成功する要求仕様 失敗する要求仕様』日経BP、2006年、150～152頁。。
- 入力
- 出力
- 機能
- 環境
- パフォーマンス
入力とは、開発しようとしているシステムにどのような情報を入力するのかを示しています。
出力は、入力した情報に対してどのような情報を表示するのかを意味します。
機能は、「クリックすると図が表示される」というような、システムの機能のことです。
環境はシステムを動かす環境のことです。オフラインで操作するのか、それともオンラインを想定しているのか、デスクトップパソコンで利用する予定なのか、それともスマートフォンで使うのかなどを示します。
パフォーマンスはいわゆる非機能を指します。たとえば「入力した後、出力がでるまでの時間」や「同時に接続可能な人数」など、機能の質にかかわるような部分を明示します。
以上のような情報を中心に仕様化を進め、要求仕様書を作成していきます。
妥当性確認
最後の妥当性確認では、要求仕様書を中心に再度要求を確認していきます。
「実現が難しそうな要求はないか」「両立しない要求がないか」などをチェックし、要求仕様書にまとめられた要求がプロジェクトで実現可能かどうかを確認していきます。
要求の変更を想定しておく
要求を追跡できるようにする
要求はプロジェクトの開始前後に洗い出していきますが、これらの要求はプロジェクト中に変化することもあります。
そのため、要求仕様書は後から変更しやすく、一覧性のあるものにしておくとよいでしょう。
PMBOKには要求事項トレーサビリティ・マトリックスという手法がありますが、これにならい、要求とその内容を表組の形にしておくと、管理がしやすくなります。
要求事項トレーサビリティ・マトリックスについては、下記の記事をご参照ください。
要求の変更を管理する
プロジェクト中に発生した要求の変更については、すべて受け入れるのではなく、要求の変更が妥当かどうかを判断しなければなりません。
こうした活動をPMBOKでは統合変更管理と呼んでいます。
統合変更管理では、管理委員会などを設け、要求の変更を整理しながら、その対応の可否を判断していきます。
統合変更管理について、詳しくは下記の記事もご覧ください。
要求定義が終わったら
要求定義が終わった後、プロジェクトマネジャーは計画の段階に入っていきます。つまり、要求されたことを実現するために、「どのような作業が必要なのか」「どのくらいの時間が必要なのか」「どのくらいの費用がかかるのか」を考え、計画書にまとめていきます。
一方、開発の責任者は要求定義書の内容をもとに要件定義を実施します。
要求定義と要件定義はお互いに重複する部分がありますが、要求定義がステークホルダーの要求を聞き、「何が求められているのか」というプロジェクトのゴールを整理していくのに対し、要件定義は「開発するシステムが実現しなければならないこと」を整理していきます。
- 要求定義：欲しいものを整理して、ゴールを明確にする
- 要件定義：実現する機能を整理して、何をするかを明確にする
要件定義については、下記の記事もご参照ください。
