この連載では、先が見えない「暗闇プロジェクト」を任された場合に参考になりそうなヒントやノウハウを紹介している。前々回(予期せぬ“危機”に事前に手を打つ秘策)と前回(多数決で仕様を決めて“炎上”、少数意見に目を向けよ)は暗闇プロジェクトに役立つ要件定義の進め方を紹介した。

 暗闇プロジェクトでは、ユーザー側の理不尽な言動や行動にベンダーが振り回されるケースが少なくない。今回はそうした場合に備えるための三つのセオリーを取り上げる。

セオリー1 
相手の土俵で相撲を取らない

 「我々はITの専門家ではないので」。システム導入プロジェクトで、顧客やユーザーがよく口にするフレーズである。こう言っておくことで、何かあった場合の責任を回避したいとする担当者の気持ちが表れている。

 ベンダーは、こうした顧客の態度を嫌がるどころか、むしろ歓迎する。プロジェクト推進の主導権を握りたいと考えていたところ、頼まずとも向こうから提供してくれるからだ。表向きは少し困った顔をしながら、心の中では万歳をさけぶのが普通だ。

 一方で、ITの専門家でないにもかかわらず、あたかも専門家であるかのように振る舞おうとするユーザーもいる。以下に示すのはその例だ。

「アクティビティ定義はしなくてもいいのか」

 ベンダーA社が請け負った要件定義のプロジェクト。キックオフに先立ち、顧客の担当者とシナリオを練ることになった。A社はいつものようにプロジェクト計画書を作成し、内容を説明した。

 説明した内容に対して、顧客が何点か質問し、A社が答える。さらにいくつか修正の要望が入り、A社は対応を約束する。こうした一連の流れを「お約束」として通過し、早々に次のステップに入る。これが通常の流れだ。ところが、そのプロジェクトは違った。