監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
要求定義の手法とは、発注側や利用者が「何を実現したいか」という要求を引き出し、整理し、関係者の間で合意できる形にまとめるための進め方の総称です。ヒアリングやワークショップ、業務フローの観察などを組み合わせ、断片的な要望を目的ごとに束ね、優先順位を付けていきます。後工程の要件定義や設計の土台になるため、手法の選び方が全体の手戻りの量を左右します。
要求定義の段階でPM（プロジェクトマネージャー）が目指すのは、関係者の頭の中にある期待を、抜けや重複の少ない一覧に変えることです。この時点では「どう作るか」ではなく「なぜ必要か」「誰が困っているか」を明らかにします。手法はそのための道具であり、集めた声を目的ごとに分類し、投資に見合うものを絞り込むために使います。
目的の軸で手法を見ると、大きく三つの狙いに分かれます。
三つは順番に進むというより、行き来しながら精度を上げていくものと考えると扱いやすくなります。
手順の軸で見ると、要求定義は「聞く」「書く」「確かめる」の流れで進みます。それぞれに向く手法と、残すべき成果物があります。
集めた内容は要求一覧表に落とし込みます。一件ごとに、要求の内容・出どころ・目的・優先度を列にして並べると、後の要件定義へ引き継ぎやすくなります。最後に関係者へ内容を読み合わせ、認識のずれを確かめてから次工程に渡します。この確認を省くと、設計段階で「そういう意味ではなかった」というやり直しが起きやすくなります。
要求定義でよく起きるつまずきは、手法そのものより運用の仕方に原因があることが多いようです。典型的な形をいくつか挙げます。
もう一つ注意したいのは、合意の記録を残さないことです。口頭で決めたつもりでも、時間が経つと解釈が分かれます。要求一覧表に合意日と確認者の役割を書き添えておくと、後から経緯をたどれます。手戻りを完全に消すことは難しいものの、記録の習慣があるとやり直しの範囲を小さく抑えられます。
要求定義と要件定義は言葉が似ていますが、扱う対象が異なります。違いを「誰の視点か」「何を決めるか」の軸で整理すると分かりやすくなります。
順序としては要求定義が先にあり、その内容を受けて要件定義が具体化を進めます。要求があいまいなまま要件に進むと、作り手が前提を推測で埋めることになり、ずれが生まれやすくなります。
隣接する考え方として、アジャイル開発では要求を一度に固めず、プロダクトバックログという形で並べ、優先度の高いものから段階的に詳しくしていきます。最初にすべてを決めきるウォーターフォール型の進め方とは、要求を確定させる時期が違うと捉えると整理しやすくなります。どちらが優れているかではなく、対象となる業務の変わりやすさに応じて使い分けるものです。
要求定義の手法を使いこなせることは、PM（プロジェクトマネージャー）にとって上流工程を任される土台になります。関係者の期待を引き出し、目的ごとに整理し、優先順位を付けて合意に導く一連の動きは、要件定義や計画づくりにそのままつながるためです。とくに複数部門が関わる案件では、誰からどの順で何を聞き、どんな成果物に残したかという進め方そのものが、PMの力量として評価されやすくなります。
転職を検討する場面でも、要求定義での具体的な役割は語りやすい材料になります。どんな手法で要望を集め、どのように優先順位の合意を取り付け、手戻りをどう抑えたかを、成果物名とともに説明できると、担当工程の広さが伝わります。手法の名前を知っているだけでなく、現場で使い分けた経験を言葉にできるかどうかが差になりやすい領域です。
要求定義の手法はどれか一つを選べばよいですか。
一つに絞る必要はありません。ヒアリングで個別の声を引き出し、ワークショップで部門横断の論点をまとめ、業務フローの観察で言葉にならない動きを補うというように、目的に応じて組み合わせるのが一般的です。対象業務の複雑さや関係者の数を見て選びます。
要求定義と要件定義は何が違いますか。
要求定義は発注側や利用者の視点で「何を実現したいか」を決める工程です。要件定義は作り手の視点で「何を満たせば実現できるか」を具体化する工程です。要求定義が先にあり、その内容を受けて要件定義が機能や性能の条件へ落とし込みます。
要求が次々と増えてしまうときはどうすればよいですか。
すべてを同じ重みで扱わず、目的への貢献度と実現の難しさを軸に優先順位を付けます。今回対応しないものを一覧に明示し、関係者と合意しておくと、後からの追加や蒸し返しを抑えやすくなります。合意した日と確認者の役割も記録しておくと経緯をたどれます。