チーム内でやる進捗会議はムダ

ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。

チームリーダーはソフトウェア開発プロジェクトのボトルネック

ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメンバーのハブとして常に忙しく、チームの生産性のボトルネックになりがちだ。
チームの進捗管理役をチームリーダーに負わせてしまうと、ただでさえ忙しいチームリーダーの仕事が増す。さらに、チームリーダーからプロジェクトマネージャへの報告会議を対面で行った場合、貴重なチームリーダーの作業時間を奪ってしまう。週に40時間のワークタイムがあったとして、チームリーダーが進捗管理タスクを2時間、進捗報告会議に2時間割くと、実にチームリーダーの1割の時間をムダに捨てることになる。もし「進捗を管理する」というタスクをチームリーダーから引き剥がすことが出来れば、チームリーダーのワークタイムが1割増加するし、それ以上の価値を得ることができるはずだ。

見えて数えられるなら管理できる

チームリーダーに進捗を管理させる理由は単純で、チームリーダーでなければ進捗が測れないからだ。ソフトウェア開発の作業進捗は斬新的ではない（作業時間をかけただけ作業が進むわけではない）ので、どれだけ進捗しているのかを把握するのにもスキルが必要だ。

少し話題が逸れるが、アジャイル開発プロセスでは基本的に作業途中の進捗は管理しない。機能（フィーチャ）が完成したかどうかのゼロイチ管理だ。それが良いことかは別の話だが、見通しが良いことには違いがない。

結局、見えない進捗を管理するのであればチームリーダーに頼らざるを得ない。逆に言えばチームリーダーに頼らないで良いように進捗を見えるようにできればチームリーダーに頼らなくても良くなる。

以前あるプロジェクトで「歩き回って管理する」ということを試したことがある。PMとして普段からチームメンバーの席を歩き回り、今やっていることを観察する。また構成管理ツールのログを毎日チェックして誰が何の作業をやっているのか把握する。チーム内のドキュメントレビューは共通表紙の文章回覧形式にして、机の上に積み上げるようにすれば、ボトルネックがどこにあるかもすぐわかるようにする。それを観察する。一週間観察した内容をもとに、顧客向けの進捗報告を予想で作成してから、チームリーダーたちに「間違いがないか」「見落としがないか」をチェックしてもらっていた。

この仕組みはアナログな部分も多かったけれどうまくいった。結局、そのプロジェクトでは1年くらいチーム内の進捗会議は開かなかった。チーム内の進捗会議をやっていたら、50週×6人×4時間で1200時間くらいを失っていたかと思うとゾッとする。