上司から、漠然とした作業指示を受けて、どうしたら良いか悩んだことはないだろうか。「来週までにこのドキュメントを仕上げておいて」「いくつか案を出しておいて」。このような指示を受けると、「来週とは具体的には何日？」「仕上げるってどの程度？」「いくつかって、二つなのか三つなのか？」と悩んでしまう。

　PMは忙しいもの。そのため、どうしても指示の内容が漠然となりがちである。しかし、だからといって漠然とした指示が許されるわけではない。漠然とした指示によって失敗した、PMのBさんのケースを紹介しよう。

すべてが漠然とした指示のBさん

　システムインテグレータK社に勤めるBさんは、SEの経験が長く、PMになったのは数年前であった。気さくな性格で後輩に慕われているが欠点もあった。それは、漠然とした指示を行うことだった。

　BさんがPMを担当したあるプロジェクトでの出来事である。そのプロジェクトは技術的な難易度が高かった。特にハードウエアとミドルウエアについては、ユーザー企業からの指定で、K社においてそれまで利用実績のない製品を使うことになっていた。そこでBさんは万全を期して、非機能要件の定義や基盤設計に当たって、実機を用いたトライ＆エラーで最適なパラメーターを決めていった。

　K社としても、今回のプロジェクトは比較的難しいプロジェクトになることが予測されたため、チームには中堅エンジニアを通常より多く配置し、若手メンバーは数人にとどめた。メンバーは、厳しいプロジェクトになることを事前に知らされていた。

　プロジェクトがスタートすると、案の定多くの難題が降りかかってきた。BさんはPMとして、一つひとつ丁寧かつ着実に対処していった。しかし課題が多いということは、PMとしての仕事が忙しいことを意味する。要件定義が中盤に入る頃には、Bさんの忙しさはピークに差し掛かっていた。

　あるとき、Bさんは若手メンバーのYさんに、「既存システムから送られてくるトランザクション量について分かりやすくまとめておいて」と指示した。Yさんは、具体的にどんな報告を想定しているのか分からなかったが、忙しさのなかで険しい顔をしているBさんを見ていると聞くことができなかった。そこでYさんは自分なりに考えて、測定した1日分のトランザクションデータごとに、1秒単位の折れ線グラフを作成した。それら30日分のグラフは1日分ずつ、表計算ソフトのシートを分けて記載した。Yさんは手を抜かず、3日を掛けてこの報告資料を作った。

　しかし報告資料を見たBさんの反応は冷たかった。「なにやっているんだよ。トレンドを見たいわけじゃない」「1日のなかで特異点があるかどうかが分かればいいんだ」「なんで1カ月分も見なきゃならないんだ。曜日変動がないことくらい分かるだろう」「こんなデータ分析に3日も掛けるなよ」。そんな辛らつな言葉を、Yさんに浴びせた。Yさんは怒られながら、心のなかで「時間がかかったのは指示が悪いからだ。それをすべてこちらの責任にするなんて」と思っていた。

　別のメンバーOさんとの間にはこんなやりとりがあった。Bさんは「今日のホワイトボードの結果をまとめておいて」と指示した。Oさんは、その日の会議結果とホワイトボードの内容をWord文書としてまとめてBさんに持って行った。するとBさんはこう怒鳴った。「なにやってるんだよ。会議の内容聞いていなかったの。ホワイトボードの内容を基にプレゼンするのだから、普通はPowerPointで作るでしょう」。Oさんは、「だったらPowerPointファイルを作るように最初から言ってほしかった」と思ったが、Bさんの形相を見ると何も言えなかった。

　Bさんの漠然とした指示によるトラブルが重なり、次第に現場はどんよりとした空気で包まれるようになった。メンバーは自己防衛するために、Bさんから仕事を頼まれると具体的な指示内容を聞き出そうと根掘り葉掘り聞くようになった。Bさんにとってみれば、何か指示するたびにしつこく細かい内容まで聞かれるので「自分で判断できないのか」と感じるようになった。

　こうしてBさんとメンバーのすき間は日に日に広がっていった。そのうちBさんは、メンバーに仕事を依頼しなくなった。大小さまざまな仕事を一人で抱え込んだBさんは体調を崩しがちになり、社内の出荷判定会議で不合格になった日を最後に休職した。