進捗状況の「見える化」による、メンバーの意識の向上
チーム開発では、作業を分担して進めるため、個々のメンバーは往々にして、自分が担当する作業以外は見えにくくなってしまう。
だが、本稿で提案する管理手法では、チームのメンバー全員でWBSを作成し、開発がスタートした後は各自が実績を記入する。当然、WBSに書かれているプロジェクトの進捗状況は、チームのメンバー全員が見ることができる。
そのため、開発プロジェクトの全体像や工数、進捗状況に対して、メンバー全員が共通認識を持つことができる。その結果、メンバーがそれぞれ、開発プロジェクトに対して高い意識を持って取り組むようになる。
開発プロジェクトの全体像を認識することで、メンバーはそれぞれ、自分が担当する作業が全体の中でどのような位置付けになっているかを考えながら作業を進めるようになる。例えば、納期までにどれだけの余裕が確保されており、作業の遅れがどのような影響を及ぼすか、といったことを考えられるようになる。
また、作業の進捗状況や残りの作業工数などを、常に意識しながら作業を進めていくようになる。その結果、作業の遅延など、進捗上の問題にも早く気づくようになる。
作業規模の過小評価の防止
これまでの筆者の経験では、項目の洗い出しをせず、大まかな計画しか立てずに作業を始めていた技術者に、WBSを作って見積もりをし直してもらうと、大幅に工数が膨れ上がることが多い。これは、大まかな計画は楽観的に過ぎて過小になりやすい、ということを表している。
だが一方で、WBSに基づく見積もりが大きくなり過ぎることも多い。WBSによる見積もりは、作業項目ごとの工数を積み上げる方式であるため、下記のような理由で過大になりやすい。
- 個々の項目の工数を、0.5日または1日単位で算出するため、誤差が積み上がり、大きな値となる。
- 作業日程に余裕を持たせたい心理から、個々の項目にそれぞれ余裕を含めてしまい、積み上げると余裕の分量が大きな値となる
見積もりをした当人も、算出された工数の大きさに驚くことになる。この見積もりは現実的ではないので、見直しをかけ、余裕や誤差などを絞り込むことになる。
だが、いったん見積もりを算出し、そこから工数を削減する、という過程を踏むことで、担当者は、開発プロジェクトにはそれほどの余裕はないことを認識することができる。その結果、規模を過小評価したまま作業を始めてしまうことがなくなる。
週間進捗報告の弊害からの脱却
ソフトウェア開発プロジェクトでは、チームのメンバーに毎週、週間進捗報告の提出を求めて、プロジェクト・マネージャはそれを元に進捗管理を行う、ということが多い。だが、これには大きな弊害がある。
週間進捗報告には、先の１週間に何を行ったかという結果と、次の１週間に何を行うつもりかという予定が書かれている。だが、たいていの場合、それらについての評価が書かれていない。例えば、作業は遅れたのか、今後も遅れる見込みなのか、新たな作業は発生したのか、といった点まで、きちんと書かれていることは稀である。こうした評価のない週間進捗報告は、ただの日記に過ぎず、次の１週間の予定も信頼できない。
一般的な週間進捗報告の例
また、報告が１週間ごとであるため、プロジェクトが遅れていることをすぐに認識できない。進捗会議も、週間進捗報告に合わせて１週間ごとに開催されることが多く、対応が遅れてしまう。時には、チームのメンバーが、プロジェクトの遅れや問題点をすぐに報告せず、週間進捗報告の日まで黙っている、ということすら起こり得る。
筆者の開発業務では、WBSを進捗管理の中心に置き、各自が毎日WBSを記入することを、進捗管理の上で最も重要な作業と位置付けた。WBSには、プロジェクトのすべてが明確な数値で記載されている。従来の週間進捗報告と比べると、数値を書き換えるという、より単純な記入方法ながら、各メンバーが進捗として報告すべきことが、漏れなく、かつ正確にプロジェクト・マネージャに伝わりやすくなっている。
また、進捗会議は、プロジェクトの状況に変化があったり、計画を見直した時に、必要に応じて行うこととした。定期的な進捗会議を廃止することで、必要な打ち合わせは適宜行われるようになり、チームのメンバーも、何か問題が生じた場合にはすぐにそれを知らせるようになった。
なお、筆者の開発業務では、週間進捗報告も併用している。但し、これは進捗管理には使用しない。後から振り返った時のために、記録を残しておくことだけを目的とした、ただの日記として位置付けている。よって、記述内容については、先の１週間に何を行ったかという結果と、次の１週間に何を行うつもりかという予定のみで問題はない。