ユーザーの要望を調整し、優先順位を含めて整理できたら、今度は社内合意を取り付け、第三者(この場合は調達先候補企業)にRFPとして提示するために、ユーザーの要望をビジネスニーズとして仕様化する、すなわち機能要件として落としていく。

機能要件を作成する時に重要なのが、「ビジネスニーズ」との関連性をトレースできるようにしておくということである。RFPに限ったことではないが、IT部門はユーザー・ヒアリングによって「間接業務のコストパフォーマンスを改善したい。そのためには……」や「見積り予測の精度が悪くて困っている。そのせいで……」といった要望や問題提起を受けると、再構築や保守に着手することになる。そして、作業に着手した途端、ユーザーの話はどこへやら、システムのカットオーバーに向けてひたすら仕様の詰めに入るのである。これにSIベンダーが加わると、話はさらに伝言ゲームの様相を呈してくる。

こうした状況の下、「汗水たらして夜も寝ずにがんばって使いやすいシステムを作りましたよ」と言ってリリースしたシステムは、果たしてユーザーが最初に提示した要望にこたえているのか、あるいはこたえすぎてはいないか。甚だ疑問が残る。

もちろん、IT部門はユーザーの要望にこたえなくてはならない。しかしこたえすぎ、やりすぎてはいけないのである。システム開発のプロジェクトでは大抵、コストと予算に乖離が起こる。その際、金額調整の交渉努力は行われても、本当に必要な機能なのか、予算をオーバーしても盛り込まなければならないのかといったビジネスニーズからの見直しは忘れられがちである。

IT部門は「機能の必要性についてちゃんとユーザーに確認した」と言うかもしれないが、ユーザーとはどのようなポジションにいる人だろうか。確かにそのユーザーにとっては必要な機能かもしれないが、事業部門長や社長の立場から見た場合は違う答えが返ってくるかもしれない。IT部門に示されるユーザーのビジネスニーズは経営や事業における課題を満たすためのものでなくてはならない。

したがって、機能要件も場合によっては企業のトップにまで遡って必要性を追求すべきである。そこまで徹底して機能の必要性を問うことは、ITの専門性の範疇から決して外れてはいない。

以下の表に機能要件の具体的な項目を示した。これらを明らかにするには、要件定義を実施すればよいのである。IT部門に籍を置いたことのある人間なら、システム開発工程について、初期段階で学んだはずである。企業、適用している方法論によって、その呼び方は違っていたとしても。機能要件とは、開発工程の中の要件定義において欲しいものをどのようにしてほしいかということを明らかにしていくことと何ら変わりはない。

主要な機能要件

ただし、調達案件の性質や規模、難易度、自社にとっての重要性といった点で、機能要件の粒度や網羅すべき項目は当然変わってくる。この辺りに関しては本連載を読み返していただきたい。

執筆者プロフィール

石森敦子(Atsuko Ishimori)
株式会社プライド システム・コンサルタント

『出典:システム開発ジャーナル Vol.3(2008年3月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。