現代のシステム構築・導入プロジェクトの多くは、前例がない、あるいは経験がないといった、先の見えない「暗闇プロジェクト」と言える。この連載では、暗闇プロジェクトを任された場合に参考になりそうなヒントやノウハウを紹介している。

 今回から新シリーズとなる。しばらくの間、暗闇プロジェクトにおける顧客接点のマネジメントに関するトピックを取り上げることにしたい。今回と次回は、現場における要求定義の心得に焦点を当てて、六つのセオリーを紹介しよう。

セオリー1
「ヒアリングの相手が分からない」前提で始める

 要求定義はシステム企画を具現化するための最初のステップであり、システム開発プロジェクトの基本である。中でも要件のヒアリングは非常に重要な作業の一つだ。この作業が不十分だとシステムの品質に大きな問題が生じ、プロジェクトの最後の最後まで尾を引くことになる。

 ところが暗闇プロジェクトでは、「そもそも誰に何をヒアリングすればよいのかすら分からない」ところからスタートせざるを得なくなるケースがある。情報システム子会社A社が直面したのはこうした問題だ。

「トップが勝手におたくを入れたんだ」

 A社は当時、親会社からの圧力もあって外販志向を強めようとしていた。親会社はそれなりの規模であり、親会社向けとはいえ規模の大きなプロジェクトの経験を通じてノウハウや知識を蓄積していた。こうした知見を、外部の顧客に対するコンサルティング・開発に生かすことを狙っていたわけだ。

 このタイミングで、B社向けプロジェクトの話が持ち上がった。A社のトップが個人的な人脈を駆使して取ってきた案件である。B社はA社の親会社との資本関係はなく、A社にとって初の「外向け」の仕事となった。

 A社の担当者は、これまで名乗ったことがない「コンサルタント」という肩書きでB社を訪問した。ところがB社の現場には「外部からコンサルタントが来る」という情報がほとんど伝わっていなかった。不快な表情で「何しに来たの?」と尋ねるマネジャーもいた。現場からは「あの話、本当だったのか」といった声も聞こえてきた。