PM（プロジェクトマネジャー）は、リーダーとマネジャーの両方を兼ね備え、その時々に応じて使い分けなければならない。

マネジメント中心のFさんのケース

　Fさんは、ある中堅システムインテグレーターのPMである。主任クラスであり数人の部下を抱える。Fさんは常日頃から、会社組織だろうがプロジェクトだろうが上に立つものに一番重要なスキルはマネジメントであると考え、その知識習得に対して精力的に自己研さんを重ねていた。そんなFさんが大手通信会社の大規模システム開発のPMとして選ばれたときの出来事だ。

　マネジメントに関しては豊富な知識を持つと自負するFさんは、プロジェクトの開始当初から精力的に動いた。要件定義フェーズ着手時点で既に総合テストフェーズまでの詳細な工程表や、リソース配分を考えた体制図、各種プロセスに必要なフォーマット・手順書などが出来上がっていた。

　このFさんの仕事ぶりを目の当たりにしたプロジェクトメンバーは当初こそ面食らっていたものの、「信頼おけるリーダー」として受け入れたのだった。

　Fさんとしては万全の体制でのプロジェクトスタートだった。スタートしてからもFさんは徹底していた。管理こそ全てであるとばかりに、毎日の進捗管理、要員の勤怠管理、収支管理、日時ベースの生産性の管理と大車輪の働きを見せた。

　Fさんは、こういう大規模プロジェクトでは、メンバーの体調管理が特に重要であると考えていた。そこで、メンバー間の夜の付き合いについて、プロジェクト完了までの間は基本的には行わないようにと指導した。「飲みに行く暇があったらキッチリと仕事をし、早く帰って次の日に備える」というものだった。

　業務時間中の雑談にも厳しく、計画された時間をオーバーする場合には残った仕事と今後必要となる時間を30分単位で報告させもした。これらは全て「計画通りに進める」ためのマネジメントであるとFさんは信じていた。

　Fさんは、「これならば当初の予定を上回る成果が出るだろう」と思っていた。しかし、Fさんの思いと裏腹に、プロジェクトが進むにつれて生産性はみるみる下がっていった。そのうち、メンバーの間からは「これじゃ管理じゃなくて監視だな」という声すら聞こえるようになってしまっていた。

　そして、単体テストが終わるころになると「Fさんの言いつけ通りに実行しましたよ。何か問題があったらFさんに聞いてください」と言うようにまでなっていたのである。

　プロジェクトの雰囲気はすっかり悪くなってしまった。こうなってしまっては、うまくいくものも行かなくなってしまう。生産性は下がり、品質も劣化した。予定していた工期も予算も全てオーバーする。計画通りにいかないことにFさんはいら立ち、Fさん流の「マネジメント」を強化する。悪循環である。結果的に、何とか納品はできたものの、納期遅延・予算オーバーで、かつ稼働後もバグが頻発する結果となってしまったのである。