ITに関わるプロジェクトは多様化する一方だ。新規事業やサービスの開発、業務改革などと密に絡み、あらかじめゴールを設定できない状況で開始せざるを得ないケースも少なくない。

　この連載では、そうした先が見えないプロジェクトを「暗闇プロジェクト」と呼び、この種のプロジェクトを担当するマネジャーにとって参考になりそうなヒントやノウハウを紹介している。

　プロジェクトには様々なステークホルダー（利害関係者）が関わる。実は顧客以上に厄介で面倒なのは、社内関係者のコントロールだ。今回からしばらく、暗闇プロジェクトを進める際にマネジャーが知っておくべき社内コントロールの心得を紹介する。

　今回と次回は主に、エンジニア出身の新任マネジャーが陥りやすい注意点を中心に見ていく。

セオリー1
マネジャーは自信満々にウソをつくべき

　エンジニアからつい最近、マネジャーとなったA氏。といいつつ、仕事をするうえでの目線や価値観は、まだ開発リーダーを務めていたときと変わらない。

　A氏は、開発の現場にいた頃には全く縁が無かったたぐいの問題処理に追われた。メンバーの突然の離脱、先方の担当者の変更、顧客が求めていた重要機能の見落とし、といったものだ。

正確で詳細な情報をメンバーに与えたところ、不安が増大

　プロジェクト会議で、A氏はこうした課題について逐一、詳細な内容をメンバーに伝えていた。中には、現場のメンバーが知る必要がないレベルの情報も含まれていたが、A氏はそうした情報を含めて「皆で共有することか大切」と固い信念を持っていた。

　それには理由がある。A氏が開発リーダーを務めていたあるプロジェクトで、早期対応のタイミングを逸し、進捗が大幅に遅れた。上司がトラブルに関する情報を全く開示しなかった、というのが理由である。A氏はこの経験から、「プロジェクトの状況を隠そうとするのは悪」と強く思うようになった。マネジャーとなった今も、その思いは変わらない。

　ところが正確で詳細な情報をメンバーに与えたところ、A氏の意に反して、メンバーはかえって不安を感じるようになった。「本当にこのプロジェクトは大丈夫なのか」との疑念が個々のメンバーの中で渦巻いてしまったのである。

　プロジェクトの状況は次第に悪化していった。メンバーからは「あの若手マネジャーでは心もとない」との声が上がり始めた。結局、プロジェクトの途中にもかかわらず、部長はマネジャーの交代を決めた。