システム開発プロジェクトでは、要件定義フェーズで利用部門のユーザーにヒアリングをかけ、要件を確定する場面がある。この要件ヒアリングでは、システムの設計や開発に必要な要件を洗い出すことが欠かせない。

 このときPM(プロジェクトマネジャー)は、利用部門の業務で必要になることがまれな、レアケースの要件に振り回されてはいけない。せっかく要件を取りまとめてもコストを超過するほど要件が膨らみがちになる。そうなると、ユーザー企業のプロジェクト責任者から、要件を承認してもらえず、設計や開発といった次フェーズに進められないという事態が起こってしまうからだ。

キーパーソンの要件を取りまとめたTさんのケース

 中堅SIベンダーに勤務するTさんは、入社して10年近く、営業管理や調達管理などのシステム開発にSEとして数多く携わってきた。その実績を評価され、メーカーA社の営業管理システム開発プロジェクトのPMに抜擢された。Tさんの営業管理システム開発の経験を、A社のシステム利用部門である営業部の責任者、K部長も高く評価していた。

 プロジェクトの序盤。TさんたちSIベンダーのSEは、全国各地にあるA社の本社の利用部門や営業所で、要件ヒアリングを行った。現状の業務をヒアリングし、問題点とシステムに必要な要件を洗い出していく。

 SEの人数も限られていたので、本社の利用部門への要件ヒアリングをTさんが担当することになった。あらかじめK部長から「本社のベテラン営業Nさんはキーパーソンだよ」と教えてもらっていたこともあり、Tさんは利用部門のキーパーソンであるNさんにヒアリングをかけることにした。

 「Nさんから詳しい要件を聞き出すことがこの要件定義のキモだ」。Tさんはそう思ってNさんとのヒアリングに臨んだ。Tさんは営業管理システムのポイントは理解しているため、ヒアリングは順調に進んでいった。Nさんも非常に前向きで協力的だったこともあり、「現場ではこんなときにシステムに機能がないので困っている」「システムにこのような処理ができたら現場は非常に助かる」と、詳しい要件が示された。

 Nさんからの要件は合理的な理由と併せて示されたこともあり、Tさんは要件の必要性に納得した。「現状業務の課題を踏まえてこれだけ要件が整理できた。K部長にこの要件をレビューしてもらっても問題はないだろう。もう大丈夫だ!」。Tさんはほっとした。

 TさんがK部長に、取りまとめた要件一覧をレビューしてもらった。ところが、「特急品対応のためのEDI機能といった、業務でもレアなケースのための要件が多すぎます。このような要件を実現するとなると、いくらお金があっても足りませんよ」と、NGの指摘を受けてしまったのだ。

 Tさんは、Nさんから聞いている現場の課題や要件の必要性を詳しく説明した。K部長としては、「Nさんは、現場に詳しいかもしれないが、それは今の仕事の仕方をよしとしてしか考えてない。仕事の仕方を変えようという発想が足らないのだ」「君たち(Tさんのこと)も、Nさんが言ったことを、うのみにしないでくれよ。君たちは要件が増えたほうが仕事になるからいいのかもしれないが、もっと要件の必要性を考えてくれよ」と、叱られてしまった。K部長から承認を得られなかったので、Tさんは要件定義を再度やり直すことになってしまった。