旧態依然とした開発現場では、進捗管理にムダな時間を費やしている。進捗管理は、チームの開発スピードを管理する。アジャイル開発のプラクティスを参考に効果的な進捗管理の方法を紹介する。

今回のポイント
  • 個人の進捗ではなく、チームの開発スピードを管理する。
  • 進捗は、すべての関係者から見えるようにしておく。
  • 効果的に進捗を管理するには「チケット管理」「カンバン」「反復」「少人数チーム」「バーンダウンチャート/バーンアップチャート」「パーキングロットチャート」というプラクティスが有効である。

 本連載は、ウォーターフォール型の開発プロセスにアジャイル開発のプラクティスを部分的に組み込み、プロジェクトに潜む様々なムダを排除する「ハイブリッドアジャイル」を提案している。今回は、アジャイル開発のプラクティスを参考に、プロジェクトの進捗を効果的に管理する手法を解説する。

ガントチャートでは計画通りに進捗しない

 プロジェクトの進捗を管理する手法は様々だが、現在多くの開発現場で用いられているのは、ガントチャートではないだろうか(図1)。ガントチャートは、機能やWBS(Work Breakdown Structure)単位に作業の開始と終了の期間を線表で表し、計画と実績の進捗を作業単位で管理するものだ。個々の作業の進捗を管理するのに適しており、マイルストーンも示せるので進捗報告会議の資料としても使いやすい。

図1●ガントチャートの例
[画像のクリックで拡大表示]

 また、ガントチャートは作成ツールが多いのもメリットだ。専用のソフトウエアやプラグインが数多く提供されているだけでなく、表計算ソフトでも容易に作成できる。このような理由からガントチャートを使った進捗管理を導入しているプロジェクトは多い。

 しかし、ソフトウエアの開発現場では、ガントチャートで作成した計画が予定通りに進まず、頻繁にスケジュールを見直している、といった話をよく聞く。なぜガントチャートでは、うまく進捗管理ができないのだろうか。まず、その理由から説明しよう。

 ガントチャートは、1896年にポーランドのKarol Adamiecki氏によって、建設現場や製造業の生産管理のスケジュールを可視化する手法として考案された。それを米国のHenry L, Gannt氏が紹介したことで一気に普及したと言われている。つまり、ガントチャートはソフトウエア開発のために特別に考えられたものではないのだ。

 建設現場や製造業であれば、労働者ごとの生産性の差はそれほど大きくない。ところが、ソフトウエア開発では、プログラマによって生産性に10倍以上の差が生じることもある。このプログラマの生産性の差と、ソフトウエアという目に見えないものを生産することが、ガントチャートで計画したスケジュールをいとも簡単に崩してしまうわけだ。

 管理するWBSの粒度が大きければ、プログラマの生産性に差があっても平均化されるため、ガントチャートによる進捗管理は有効だといえる。しかし、開発する機能を細かくWBSに分けて、担当する開発者ごとに進捗を管理するといった用途には、ガントチャートは向いていない。

 図1の「作業B1」を例に考える。このガントチャートは、開発者の平均生産性を割り出し、各担当者に実装する機能を割り当てたものだ。作業B1は3日遅れであり、このまま進めると担当者Yがその後予定している「作業B2」から「作業B5」は再スケジュールしなければならない。このように平均生産性から求めた工数で、プログラマ単位にスケジュールすれば、生産性の違いによって計画はあっさりと崩れてしまう。

 しかもスケジュール管理者は、日々プログラマに進捗を確認しなければならない。ガントチャートの修正に掛かりっきりになることもあるだろう。その結果、プロジェクトに進捗管理の専任者を設けるようなことになってしまう。これは人的リソースのムダにつながる。

問題の把握が遅れ、管理工数がかかる

 ガントチャートには、問題の把握が遅れるというデメリットもある。例えば、プログラマのT君に5日間で完成させる作業が与えられたとしよう。ところがT君にほかの作業が割り込んできて、初日の作業が遅れ気味になってしまった。この時点でT君は遅延を報告するだろうか。おそらく、まだ予定通りと報告するだろう。2日目や3日目ではどうだろうか。遅れ気味でもまだ頑張れば挽回できると思い、予定通りと報告するに違いない。T君の作業は遅れたまま進み、4日目や最終日の5日目になって終了できそうもないと諦める。ここで、ようやく遅延が報告されるわけだ。

 作業期間が5日程度なら、リソースを追加投入して遅延を挽回できるだろう。ところが作業の予定期間が数週間、数カ月ならばどうだろうか。遅延の影響はさらに大きくなり、遅れを取り戻すのは不可能になる。

 また、ガントチャートは管理に工数がかかる。特に表計算ソフトなどで進捗管理用のガントチャートを作成している場合は、進捗管理の専任者が開発者から進捗報告を受けて、スケジュール表を更新するだろう。これでは、開発者の報告時間と進捗管理専任者の登録時間、スケジュールの見直し時間など、ムダな時間が多く発生してしまう。

 そもそも進捗管理は、開発チームが円滑にプロジェクトを進めるためにするものだ。進捗管理によってムダな作業が増え、プロジェクトの進行の妨げになってしまっては元も子もない。

 散見する悪い例の1つに、社内のプロジェクト状況報告会のためだけに進捗管理をしているというものがある。報告会で状況を説明して、遅延していれば言い訳を記載し、頑張って回復させる、と言うだけならムダな作業である。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。今なら有料会員(月額プラン)が4月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら