監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
要求定義 方法とは、発注側が「何を実現したいか」という要求を引き出し、整理し、合意できる形にまとめるための進め方を指します。利用者やステークホルダーの困りごとや目的を言葉にし、優先順位をつけ、後続の要件定義へ渡せる状態にする作業です。PMにとっては、作るものの範囲と目的を関係者とそろえる、最初の土台づくりにあたります。
要求定義の目的は、発注側が抱える課題や実現したいことを明らかにし、関係者の間で「なぜこのプロジェクトをやるのか」を共有できる状態にすることです。ここがあいまいなまま設計へ進むと、作ったものが現場の困りごとと噛み合わず、手戻りが生じやすくなります。
要求定義と要件定義は、扱う抽象度が異なります。要求定義は「請求書の処理に時間がかかっているので短くしたい」といった、発注側の言葉で語られる目的やニーズを扱います。要件定義は、それを受けて「請求データをシステムで自動照合する」といった、作り手が実装を判断できる粒度へ落とし込みます。要求定義が What よりさらに手前の Why と Want を、要件定義が What と How の入口を担うと考えると整理しやすいでしょう。
PMの立ち位置も変わります。要求定義ではビジネス部門や利用部門の責任者、場合によっては経営層と向き合い、目的と優先順位の合意を取りに行きます。要件定義では開発ベンダーや設計担当と向き合い、実現方法の整合を取ります。この順番を飛ばすと、関係者それぞれが別の目的を思い描いたまま進み、受け入れ段階で認識のずれが表面化しがちです。
要求定義の方法は、おおむね次の順序で進めると扱いやすくなります。登場人物と成果物をセットで押さえておくと、抜けに気づきやすくなります。
ヒアリングでは、相手の言葉をそのまま要求にせず、その背景にある目的まで掘り下げることが要点です。「この画面が欲しい」という声の裏に「月末の確認作業を減らしたい」という目的があるなら、画面以外の解決策も検討の余地に入ります。
要求を集める方法にはいくつかの型があり、対象や段階によって使い分けます。軸は「誰から・どの深さで引き出すか」です。
集めた要求は、そのままでは重複や矛盾を含みます。似た要求をまとめ、対立する要求は意思決定者に判断を仰ぎ、どれを今回の範囲に入れるかを決めます。このとき「やらないこと」も明記しておくと、後から範囲が膨らむのを防ぎやすくなります。優先順位は、効果の大きさと実現のしやすさといった複数の軸で見ると、関係者が納得しやすい並びになります。
要求定義でつまずく形には、いくつか典型があります。あらかじめ知っておくと、兆候に早く気づけます。
もう一つ注意したいのは、要求定義を一度で終わらせようとしないことです。実際には、要件定義や設計を進める中で新しい要求が見つかることもあります。最初から完璧を目指すより、主要な目的を固めたうえで、変更が出たときにどう扱うかの手順を決めておくほうが現実的です。変更管理の仕組みと結びつけておくと、要求の追加が出ても混乱を抑えやすくなります。
要求定義を自分で進められるPMは、作られたものを管理するだけでなく、何を作るかの入口から関わるポジションに近づきます。関係者の目的を引き出し、対立する要求を整理して合意へ導く力は、上流工程やコンサルティングに近い役割で評価されやすい部分です。
職務経歴や面接の場でも、どの立場の関係者と、どんな成果物を使って、どう合意形成したかを具体的に語れると、担える範囲の広さが伝わります。要件定義や設計の経験に加えて、その手前の要求を扱った経験を言葉にしておくと、プロジェクトの目的から任せられる人材として見てもらいやすくなるでしょう。
要求定義と要件定義はどう違いますか。
要求定義は、発注側が実現したい目的やニーズを発注側の言葉で整理する工程です。要件定義は、それを受けて作り手が実装を判断できる粒度へ落とし込む工程です。要求定義で何を・なぜを固め、要件定義でそれをどう作るかの入口を決める、という順序で進みます。
要求定義は誰が主体で進めるのですか。
発注側が主体となり、ビジネス部門や利用部門、意思決定者が要求の出し手になります。PMはその間に立ち、関係者から要求を引き出し、優先順位の合意を取りまとめる進行役を担うことが多いです。作り手であるベンダーと向き合うのは、主に後続の要件定義以降になります。
要求が多すぎてまとまらないときはどうすればよいですか。
まず誰が最終的に判断する意思決定者かを明確にします。そのうえで、効果の大きさと実現のしやすさといった軸で要求を並べ替え、今回やることとやらないことを分けます。すべてを一度に満たそうとせず、主要な目的に絞って合意する進め方が現実的です。