時間の無駄？進捗会議が泥沼にはまる理由：新任PMがついやってしまうNG集（3）（2/2 ページ）

» 2011年05月16日 00時00分公開

[水口和彦，ビズアーク]

肝に命じましょう。PMの関心事とメンバーの関心事は違います

　「分母の変化が反映されない」……この問題は、前回述べた「プチ隠蔽体質」の1つです。プチ隠蔽体質が発生するのは、そもそも「PMの関心事とメンバーの関心事が、必ずしも一致しないところ」にも原因があります。

　PMの関心事は、言うまでもなく「各工程が順調に進んでいるか？」「その工程がいつ完了するか？」「そのメンバーの手がいつ空くか？」でしょう。もっと端的にいえば「やれてないことがどれだけ残っているか？」です。

　一方、メンバーは必ずしもそう考えません。報告の場では「自分はこれだけの作業をこなした」ということをアピールしたい気持ち、つまり、「分子」を強調したい気持ちが強まります。それでつい正確な報告、「分母」の報告がおろそかになるわけです。このような心理が働くことを、PMは常に考慮すべきです。

進捗管理の精度を上げるためのポイント

　こうした「進捗率」による問題を避け、進捗管理の精度を上げるための解決策の1つとして、「管理する対象（工程）を細かくする」方法はそれなりに有効です。

　「○日間かかる」という工程をそのまま管理するのではなく、その中にある個々のタスクを管理対象にするのです。各タスクを「完了／未完了」という2つの状態で管理すれば、「進捗率○○％」といった曖昧な管理はしなくても済みます。工程ごとにタスクをまとめて、完了数を集計すれば、精度の高い進捗率を出すことも可能です。

　工程を細かく分割して管理するには、詳細かつ精度の高い計画が必要になります。計画を作る手間はかかりますが、実用性に乏しい「進捗率」を使わずに済むのは大きなメリットですし、実際に上記のような管理方法を用いるプロジェクトは増えています。

　頭痛の種である「進捗率」に悩まされなくて済むようになる――これはPMにとって喜ばしいことです。しかし、注意すべき点があります。いかに管理方法を変えたとしても、メンバーが報告する「分母の変化が反映されない」という問題が消えるわけではない、ということです。

　ある工程で何か問題が発生した場合、担当メンバーが問題を報告せずに1人で抱え込んでいれば、やがてプロジェクトは炎上します。この場合、一見すると問題は「なぜ問題があるのに言わなかったのか？」であるかのように見えます。しかし、問題の本質は、進捗率と同じところにあります。つまりメンバーが「仕事の分母を変化させない」という点です。

「分母の変化」に関する情報を報告してもらえば万事OKです

　ですから、重要なのはどんな管理方法を用いるかではありません。PMが常に留意しなくてはならない点は、メンバーに「分母の変化」に関する情報を報告させることです。

　「分母の変化」に関する情報とは、「必要な工数が、当初の見込みに比べて増えたか減ったか」という情報です。

「なぜ進捗会議を行うのか」という進捗管理の意義と目的
プロジェクトを運営するために必要な情報は何か
PMとして聞きたい情報は何か

　まずは、上記の項目をメンバーに周知徹底しましょう。その上で進捗状況と「分母の変化」に関する情報を報告させます。その際は「予定の工数で終わるか？」というイエス／ノー型の質問ではなく、「予定の工数と比べてどのくらい増えそう？」あるいは「追加でどんなタスクが発生してる？」といった具体的な聞き方の方が効果的です。

　また、「プチ隠蔽体質」の壁を越えるためには、

チーム内のコミュニケーションを活性化させる
信頼関係の構築

など、心理的な安心を築いていくことも必要です。もし自分がメンバーなら、進捗が遅れるたびにガミガミ言うPMには進捗の遅れを素直に伝えたくありません。

　ただ、信頼関係の構築は長期的な取り組みのため、すぐにプロジェクト管理を改善したいなら、しばらくは「いつ終わる」方式を導入した方が現実的です。

もし社長が「もう絶対に進捗会議なんてしない」と言ったら？

　ここで、ちょっと話を蒸し返しますが、そもそも進捗会議は本当に必要なものでしょうか？「そんなの必要に決まってる！」と即答したPMの皆さん、ちょっと考えてみてください。

　もし、「うちの会社は絶対に進捗会議を行わない」と社長が断言した場合、あなたはどうやって進捗管理を行うでしょうか？

　進捗会議をしないとすれば、PM自身がメンバーそれぞれに進捗を聞いていくしかありません。気の遠くなるような作業に思えますが、この方法は意外と合理的な面があります。

　もし、進捗会議をやめて、PMが各メンバーと個別に面談すれば、各メンバーが拘束される時間は少なくなります。2時間の会議の代わりに10分の面談で済むなら、メンバーはきっと歓迎するでしょう。会議で拘束される時間が減りますし、他メンバーの報告に付き合う必要もなくなります。

　一方、PMにとっては1人1人に確認していく手間がかかりますが、拘束される時間の合計は進捗会議の場合とあまり変わらないことに気が付くでしょう（話し合う議題そのものは基本的に同じですから）。

でも、やっぱり必要な進捗会議

　実際、メンバーの技術レベルが高く、皆が相応の問題解決能力を持っている場合、つまり「あまり問題が発生しない平穏プロジェクト」の場合は、このやり方でも十分に機能します。平穏プロジェクトの場合は、「進捗会議なし」の方法を思い切って検討してみる価値があります。

　しかし、そうでない場合――スキルが未熟なメンバーがいるプロジェクト、問題が発生しがちなプロジェクト（つまりは、ほとんどのプロジェクトということですが）では、この方法はうまく機能しないでしょう。問題が起こった場合は、その場で問題をどう解決するか知恵を出し合ったり、誰が手を貸すかを話し合ったりする必要があります。このような「問題解決」の場として、進捗会議は非常に有効です。

　つまり、よほどスキルの高いメンバーがそろっていて、問題もほとんど出ない夢のようなプロジェクトの場合でない限り、進捗会議を行うことには合理性があります。会議で情報を共有し、解決案を話し合うことで、チームの生産性を高めることができるからです。

　「進捗会議は無駄だ！」と一蹴するのではなく、「メンバーとPMによる問題解決の場」として、進捗会議を再度、見直してみましょう。

問題解決重視の「ハイブリッド型・進捗会議」はいかが？

　さて、現場で働くプログラマやPMに「進捗会議は必要だと思いますか？」と質問すると、かなり意見が分かれます。なぜか、それは進捗会議に、「状況報告」「問題解決」という2つの側面があるからではないでしょうか。

　プログラマの中には、「問題解決」のためなら喜んで手を貸すし、そのための時間は惜しまない、という人が多いように思います。しかし、彼らは往々にして、単なる「状況報告」を好みません。「そんな退屈なものに付き合わされるのは勘弁！それだったら開発させろ！」という意見をよく聞きます（特に、プログラマとして優秀な人ほど、そういう傾向があると感じます）。

　であるなら、進捗会議は「問題解決」に重点を置いてみてはいかがでしょうか。

　まず、PMはあらかじめ個々のメンバーから進捗状況を吸い上げておき、問題点をピックアップしておきます。次に、全メンバーを集め、その問題点について話し合うわけです。「状況報告は個々に、問題解決は会議で行う」というハイブリッド方式です。

　これなら、メンバーが拘束される時間は最小限で済みますし、状況報告に付き合わされてテンションが下がることもありません。PMにとってはちょっと大変ですが、メンバーにはメリットの多い方法です。