この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。今回は前回（情報は「質」より「量」、ヒアリングで「なぜ」は禁句）に続いて、現場における要求定義の心得に焦点を当てたセオリーを見ていくことにしよう。
セオリー4
矛盾している回答を「歓迎」する
ユーザー（仕様ホルダー）からシステムに対する要求を計画通りに取得・整理できている。とても望ましい状況のように思えるが、暗闇プロジェクトではリスクの兆候と捉えるべきである。「暗闇」に挑戦しているのではなく、頭の中にでき上がっているテンプレートを現場に当てはめている可能性が高いからだ（図3）。
暗闇プロジェクトではゴールが見えていても、そこに至るまでのルートを暗中模索で探っていかなければならない。その過程で、メンバーの勘違いや間違い、考えの変化があって当然である。
様々なユーザーから矛盾した意見が出るのはもちろん、同一人物からも矛盾だらけ、あるいは前言撤回の要望が出る場合もある。暗闇プロジェクトではそれを含めて歓迎すべき、というのがセオリーの四つめだ。それは難しいプロジェクトを進めているあかしとみなせる。それを示すのが、相当昔に実施した、金融業界の中堅3社の合併に伴う営業支援システムの刷新プロジェクトである。
「前と言っていることが違うじゃないか」
プロジェクトは始まる前から「難しいだろう」と予測できるものだった。基幹系は3社のシステムをそれぞれ継続して利用することになったが、営業プロセスはツールを含めて統一。その支援システムも3社で統合して一新する方針に決まった。
営業支援システムは、外回りの営業や販促員に携帯型PCを配布し、顧客や見込み顧客に対して、その場で見栄えのするプレゼンを見せる、資料を印刷する、ほぼリアルタイムで上司の意思決定を確認する、といった作業を可能にする。当時としては先進的な機能であり、野心的な開発プロジェクトだった。
