形骸化させない進捗会議の準備、運営、狙い

進捗会議の会議設計をどのようにしているかで、そのプロジェクトのリスクに対する考え方が垣間見ることができる。

会議設計

まず、会議を設計するという概念はほとんどないのではないかと思うのが会議の狙いを考えずにこれまで週次でやってきたから、このプロジェクトも週次の開催にした、というケースばかりだからだ。

進捗会議であれ、他の会議であれ、会議自体は情報収集を目的として行うかプロジェクトの意思決定のいづれかの目的で行う。

＃会議運営のノウハウについては過去のエントリで検索していただきたい。

こと、進捗会議は情報収集のために開催する。プロジェクトマネジメントの観点でマネジメントにレポーティングをするのが主な目的である。もちろん、予実較差の観点でのリスクマネジメントもあるが、悪魔でも較差が生じた場合である。

話を戻して、会議設計は会議の目的から設計する。プロジェクトマネジメントの観点で週次で報告する義務があれば最低限どの開催頻度は週次となるがプロジェクトマネージャの判断としてもっと短い開催サイクルで行っても良い。

つまり、プロジェクトマネージャがプロジェクトの特性、例えばリスキーなプロジェクトであると何かしらのプロジェクト計画上で識別したリスク要因から設定して良いのだ。

会議の無駄化

エンジニアの時間は、生産的な時間を如何に捻出するかで生産性が左右される。チーム全員を集めた会議に延々と費やすのは生産性を自ら下げているようなものだ。

更に言えば、その会議でさえ、正しい情報を収集することができなかったり、意思決定に至らなければ、同じように貴重な時間をドブに捨てるようなものである。

だから会議設計をして、目的どおりに開催しなければいけない。

形骸化の始まり

やらされ感や参加すること自体に抵抗を感じると途端に形骸化が始まる。進捗会議は得てして、それも第1回目から形骸化しがちになる。なぜなら、進捗会議が作業計画の矛盾を抱えたまま計画が着手され、対策も何もしないで実績報告である予実較差の可視化とアクションプランのオンパレードになるか、それをエンジニアが面倒くさがり隠蔽を始めるからだ。

形骸化させない準備

1回目の会議開催前から会議を形骸化させないための広報を行う。

出席を必要とする会議出席者のみの徹底。
開始時間の厳守。1人が遅れることで時間を守る他のメンバが待たされる時間を無くす。誰だって待たされるのは嫌である。
報告する時間枠を決める。
報告する項目をあらかじめ決めておく。予実較差、困っていること、広報したいこと。極論を言えば、予実較差が0なら報告しなくて良い。もちろん、実績は現物確認する。
主催者、つまりプロマネであっても周知事項は進捗会議の場のアジェンダに入れない。それは別の手段で広報させる。
報告書（様式にする必要はない。開発ツールでも良い）に書いていないことは話させない。
報告中は口を挟ませない。
困っていることは解決策を検討するために関連する最小限の担当者の名前を出し、検討する場だけを決める。進捗会議の中で課題を検討し始めることで会議が形骸化するためだ。

どれも当たり前だと思っても現実にこうしたルールルを守れていないなら当たり前ができていないということだ。そこからのレベルのチームであることを認識することも大事なことである。