【失敗から学ぶ】：要件定義で「要望」を聞いてしまうと起きること
Proz＋要件定義の場で、現場の要望を丁寧に聞いたはずなのに、
後工程になって
「そんな話は聞いていない」
「想定と違う」
といった声が上がることが多くありませんか。
このような経験は、多くのプロジェクトで見られます。
要件定義で問題が起きているように見えるため、
「要件定義が難しい」
「要件定義の進め方が悪かったのではないか」
と考えられがちですが、
実はその原因は、要件定義そのものにあるとは限りません。
要件定義は、ニーズを初めて把握する工程ではない
多くの方が「要件定義」という言葉には馴染みがあります。
プロジェクトが始まると、
「では要件定義を始めましょう」という流れになることも珍しくありません。
ただ、ここで一つ立ち止まって考えてみたいのです。
要件定義とは、
ニーズを初めて把握する工程ではありません。
要件定義は、
すでに整理されたニーズを、どのような形で実現するかを定義する工程です。
つまり、要件定義に入る前の段階で、
- 何に困っているのか
- なぜそれが問題になっているのか
- どんな状態になれば価値が生まれるのか
といったニーズが、ある程度整理・分析されている必要があります。
この準備が不十分なまま要件定義に入ると、
要件定義の場で初めて
「それってどういう意味ですか？」
「本当に必要なのは何ですか？」
という会話が始まります。
結果として、
要件定義が“実現方法を決める場”ではなく、
“ニーズを探る場”になってしまいます。
なぜ日本では、要件定義で要望を聞いてしまうのか
では、なぜ日本のプロジェクトでは、
要件定義の段階で初めてニーズを探るような進め方になりがちなのでしょうか。
一つの背景として、
開発ベンダーと契約してからプロジェクトが始まる
という進め方があります。
日本では、
開発ベンダーとの契約をもってプロジェクトが正式に立ち上がり、
その最初の工程として「要件定義」が位置づけられるケースが多く見られます。
そのため、
プロジェクトが動き出す＝要件定義が始まる、
という認識が強くなり、結果として
要件定義の場が、ニーズを把握する場になってしまうのです。
本来であれば、
「何を変えたいのか」
「どんな課題を解決したいのか」
といったニーズは、開発ベンダーと契約する前に、
ユーザー企業の中である程度整理されているべきものです。
しかし現実には、
社内で十分な業務理解やニーズ分析を行う時間や役割が確保されないまま、
プロジェクトが始まってしまうことも少なくありません。
要望を聞くこと自体が、問題なのではない
ここで誤解してほしくないのは、
要望を聞くこと自体が悪いわけではないという点です。
現場の声には、業務上の違和感や課題のヒントが多く含まれています。
問題になるのは、要望を聞いたことで
「ニーズを整理したつもり」になってしまうことです。
要望は、現時点で困っていることや、こうしてほしいという表現であり、
その背景にある理由や判断基準まで含んでいるとは限りません。
要望をそのまま要件として扱ってしまうと、
後工程で初めて
「本当はそこまで必要なかった」
「前提が違っていた」
といったズレが表面化します。
要件定義が機能するかどうかは、その前で決まる
要件定義で起きる失敗の多くは、要件定義の進め方そのものではなく、
要件定義に入る前の準備に原因があります。
要件定義が本来の役割を果たすためには、
その前に、
- 業務がどのように回っているのか
- どこで判断が行われているのか
- 何が暗黙の前提になっているのか
といった点を理解し、
ニーズを分析し、課題として整理しておく必要があります。
この準備があることで、
要件定義は初めて、
「ニーズをどう形にするか」を考える工程として機能します。
おわりに
要件定義で「要望」を聞いてしまうことは、
個人のスキル不足や努力不足によって起きているわけではありません。
日本のプロジェクトの進め方や、役割の置き方といった構造の中で、
起きやすい現象だと言えます。
だからこそ、要件定義の場に入る前に、
業務を理解し、ニーズを整理する役割が重要になります。
ビジネスアナリストが前もって業務理解を行い、
ニーズを分析し、課題として整理しておくことで、
要件定義は本来の力を発揮します。
当社では、要件定義そのものの支援だけでなく、
要件定義に入る前の業務理解やニーズ整理を重視した
ビジネスアナリスト育成・伴走支援を行っています。
「要件定義がうまくいかない理由が、実はもっと手前にあるのではないか」
そう感じた方は、お気軽にご相談ください。
