要求事項はどのように収集するのか？要求事項の収集（要求定義）の進め方について解説

2020年8月20日

要求事項の収集の概要

要求事項の収集とは、プロジェクトの目標を達成するために、ステークホルダーからの要望や要求事項を特定し、それらを要求事項文書にまとめていくPMBOKのプロセスです。
ITプロジェクトでいうところの要求定義や要件定義に該当するプロセスです。

ソフトウェア開発などのITプロジェクトでは、要求事項を収集した後に作成される要求事項文書や要求定義書をもとに開発の見積りなどが行われるため、要求事項の収集はコスト管理の面でも重要なプロセスであると言えます。
これらの要求事項は、プロジェクトの企画書やプロジェクト憲章に「このプロジェクトで何を作るのか」ということは記載されているものですが、多くの場合、その記述の内容は洗練されておらず、大まかな目標が掲げられているにすぎません。
また、ステークホルダー登録簿に各ステークホルダーからの要望が記載されていることもありますが、これらの内容はその要求が把握しやすいように整理されたものではありません。
そのため、要求事項の収集ではハイレベルの要求、つまり主要な要求だけでなく、各ステークホルダーからの要望もまとめて、プロジェクトで求められている機能・非機能を整理していきます。

このページでは、PMBOKにおける要求事項の収集プロセスの内容をもとに、ソフトウェア開発などのITプロジェクトで用いられる要求定義や要件定義の知識も使いながら、要求事項の収集の方法を解説していきます。

要求事項の収集のアウトプット

まずは要求事項の収集のプロセスのアウトプットを確認し、このプロセスのゴールを明確にしておきましょう。
要求事項の収集のプロセスのアウトプットは以下の通りです。

  • 要求事項文書（要求定義書）
  • 要求事項トレーサビリティ・マトリックス（要件定義書）

以下、これらの文書について解説していきます。

要求事項文書（要求定義書）

要求事項文書とは、要求事項を集めて整理し、要求事項を一覧化した文書のことです。
ソフトウェア開発においては、要求定義書とした方がなじみが深いかもしれません。

要求事項は以下のようなカテゴリーに分類され、一覧化されます[1]PMBOK第６版、。

  • ビジネス要求事項
  • ステークホルダー要求事項
  • ソリューション要求事項
  • 移管および準備状況への要求事項
  • プロジェクト要求事項
  • 品質要求事項

要求事項トレーサビリティ・マトリックス（要件定義書）

要求事項トレーサビリティ・マトリックスとは、プロダクトの要求事項と要求事項を充足させる成果物の結びつきを示した表です。
PMBOKでは要求事項トレーサビリティ・マトリックスと呼んでいるものの、一般的に「要件定義書」と言った時の内容と大きく変わりはないでしょう。

要求事項トレーサビリティ・マトリックスでは、以下のような事項を記述していきます[2]PMBOK第６版、149頁。。

  • ビジネス・ニーズ、好機、目的および目標
  • プロジェクト目標
  • プロジェクト・スコープとWBS成果物
  • プロダクト設計
  • テスト戦略とテスト・シナリオ
  • ハイレベルの要求事項に対する詳細な要求事項

このようにPMBOKでの要求事項の収集はいわゆる要求定義、要件定義に該当するもので、そのアウトプットも要求定義書や要件定義書に近い文書になります。
要求定義や要件定義はプロジェクトの中でも難易度の高いプロセスであり、それだけでも１冊の本が書けるほどです。
そのため、これから見ていく要求事項の収集のインプットやツールと技法も多岐にわたります。

要求事項の収集（要求定義）のインプット

要求事項の収集（要求定義）のインプットには、以下のようなものがあります。

ここからは、実際に要求事項を収集するために、これらの資料からどのような事柄を読み取っていけばよいのか、解説していきます。

要求事項マネジメント計画書から進め方を確認する

要求事項の収集を本格的に始める前に、要求事項マネジメント計画書を作成していたのであれば、これを確認し、プロセスの進め方に取り入れていきます。
要求事項マネジメント計画書は、要求事項の収集のプロセスのように、要求事項を収集する際の計画をまとめた文書です。
PMBOKでは、要求事項の収集のプロセスの前のプロセスであるスコープ・マネジメントの計画のプロセスで作成されます。
この要求事項マネジメント計画書は要求事項の収集のプロセスのガイドラインとなるので、この文書に沿って進めていくとよいでしょう。
同様に、スコープ・マネジメント計画書も作業範囲（スコープ）を管理する方法について記されているので、こちらもあわせて確認し、要件収集の中でプロジェクトのスコープに影響があった場合にどうするかなどを確認していきましょう。

制約を確認する

要求事項マネジメント計画書を見て、要求事項の収集のプロセスの進め方を確認するとともに、前提条件ログにも目を通し、プロジェクトの制約も把握していきます。

プロジェクトの主要な要求を把握する

プロジェクトの主要な要求事項を把握するために、まずはプロジェクト憲章やビジネス文書、企画書を確認していきます。
ソフトウェア開発の請負を行う場合であれば、プレゼンテーション時に作成した提案書や提供されたRFPなども重要な情報源です。
これらの文書は主要な要求事項（ハイレベルの要求）を把握する際に役に立ちます。
まずは大まかに、「このプロジェクトで何をしなければならないのか」を確認していきましょう。

ステークホルダーからの要望を確認する

プロジェクト憲章などから主要な要望を読み取ったら、次はステークホルダーからの要望を汲み取っていきます。
ステークホルダーからの要望は作成していればステークホルダー登録簿に記載されています。
ステークホルダー登録簿を作成していない場合は、後述するツールと技法で紹介するような、インタビューやアンケートを用いて、ステークホルダーの要望を吸い上げていくとよいでしょう。

表面化していない要望を探す

プロジェクト憲章に記されているプロジェクトの目標やステークホルダー登録簿に記載された要望というのは、表面化された要望ですが、表にでていない要望というのも多々あります。
ソフトウェア開発などのITプロジェクトでありがちなのは、「どんな動作をしてほしいか」という機能要件（機能要求）はステークホルダーから聞かされるものの、品質やセキュリティなどの非機能要件については議論がなされないということがあります。

このような状態だと、十分にプロジェクトの要望を揃えることができないため、教訓登録簿を見返したり、組織のプロセス資産を確認して、過去のノウハウを利用したり、組織体の環境要因を確認して政府から義務付けられている機能などがないかを調べていきます。

要求事項の収集のツールと技法

以上、要求事項の収集のプロセスの情報源となるインプットを確認してきました。要求事項の収集のプロセスでは多岐にわたる資料を利用していきますが、これだけの資料を使っても、表面化されない要望が隠れているということがほとんどです。
そのため、プロジェクトの要求事項をあぶりだすためにも、要求事項の収集のプロセスでは、さまざまなツールと技法が使用されます。
PMBOKで紹介されているツールと技法は以下の通りです[3]PMBOK第６版、142～149頁。。

これらのツールと技法の詳しい内容は各ページに譲るとして、ここからはこれらのツールと技法の概要を紹介していきます。

専門家の判断

要求定義や要件定義では、そのためだけに専門家を外部から招くこともあり、要求事項の収集のプロセスでの専門家の判断はとくに重要なものになります。
PMBOKでは以下のような知識を有する専門家を想定していますが、この内容に限らず、進めようとしているプロジェクトの知識・経験の豊富な専門家をアドバイザーとして招へいするとよいでしょう[4]PMBOK第６版、142頁。。

  • ビジネスアナリシス
  • 要求事項の引出し
  • 要求事項分析
  • 要求事項文書
  • 以前の類似プロジェクトにおけるプロジェクト要求事項
  • 図解の技法
  • ファシリテーション
  • コンフリクト・マネジメント

データ収集

要求事項の収集のプロセスであのデータ収集とは、そのまま要求事項の収集に他なりません。
要求事項を集めるために、ブレインストーミングやインタビュー、フォーカス・グループやアンケートと調査、ベンチマーキングなどを利用していきます。
ベンチマーキングを除いたデータ収集の手法は、ステークホルダーにインタビューを行うなど、ステークホルダーを巻き込んで要求事項を集めていきます。
ベンチマーキングについては、より客観的に基準となるデータをもって必要とされるパフォーマンスの要求を考え出していきます。

これらのデータ収集の手法については、下記の記事もご参照ください。

データ分析

要求事項の収集のプロセスでは文書分析が行われます。
分析対象として、PMBOKでは以下の資料が紹介されていますが、これらの資料に限らず、インプットとして挙げた各資料も分析していくとよいでしょう。

  • 合意書
  • ビジネス計画書
  • ビジネス・プロセス（インターフェース文書）
  • ビジネス・ルールのリポジトリ
  • 現在のプロセス・フロー
  • マーケティング資料
  • 問題・課題ログ
  • 方針と手続き
  • 法令や規約、条例などの規制に関する文書
  • 提案依頼書
  • ユースケース

データ表現

収集したり、分析したデータは親和図法（KJ法）やマインド・マップの形式で表現されることもあります。

KJ法（新和図法）の画像
親和図法（KJ法）のイメージ
マインド・マップのイメージ図
マインド・マップのイメージ図

親和図法（KJ法）はカードや付箋にアイデアを書き出し、それをグループにまとめていくアイデアの整理法です。
一方、マインド・マップは紙の中心に議題を描き、関連する情報を木の枝や根のようにつなげていきます。

これらの手法については、以下の記事もご参照ください。

意思決定

要求事項の収集の意思決定としては、民主的な投票が行われることもあれば、権限の強いステークホルダーが独裁的に必須の要求事項を選定することもあります。

発注先選定分析の画像
多基準意思決定分析の１つである発注先選定分析の画像

一方で、より客観的な意思決定を行うために多基準意思決定分析を行うこともあります。
多基準意思決定分析では、さまざまな基準を設け、それらの基準の評価を行い、意思決定を行うというものです。
要求事項の収集で多基準意思決定分析を行う場合は、候補に挙がった要求に対し、費用や効果、影響力などの基準で評価し、一定以上の得点の要求だけを取り入れていきます。

人間関係とチームに関するスキル

要求事項の収集では、さまざまな意見を吸い出せるように、そして人によって認識の違いが発生しないように、さまざまな人間関係とチームに関するスキルが使用されます。
上述のPMBOKで紹介されているスキルは、大きく分けて２つあります。

１つは、ノミナル・グループ技法や観察と対話、ファシリテーションのように、ステークホルダーから意見を汲み取るためのものです。
これらのスキルは、議論を盛り上げつつも、うまくコントロールしていくために必要なものです。

他方、コンテキスト・ダイアグラムとプロトタイプは、ステークホルダーやプロジェクト・メンバー間で認識の違いが発生しないよう、理解のしやすい図解や、実際に試作品を作っていきます。

注

注
↑1PMBOK第６版、
↑2PMBOK第６版、149頁。
↑3PMBOK第６版、142～149頁。
↑4PMBOK第６版、142頁。

プロジェクトの概念要件定義,要求定義

Posted by promapedia