大規模プロジェクトの進捗管理にガントチャートは向いていない ― 現実的な可視化の考え方
itpjstudy
プロジェクト管理の可視化手法として、ガントチャートは広く知られています。タスクとスケジュールを一望できるため、「可視化といえばガントチャート」と考える方も多いかもしれまえｓん。
しかし、大規模で関係者が多く、課題や変更が日常的に発生するプロジェクトにおいては、ガントチャートが機能しないケースも少なくありません。
- 前提となる計画がすぐに変わる
- 修正のたびにガントチャート全体を更新する必要がある
- 更新が追いつかず、最新でない可視化が残り続ける
今回は、なぜ大規模プロジェクトではガントチャートが有効に機能しにくいのかを整理したうえで、どうすれば可視化を実現できるのかをお話していきます。
なお、可視化の本質、失敗パターン、見える化の実現方法の全体構造については、可視化の全体像記事をご参照ください。
ガントチャートが前提としているプロジェクト像
ガントチャートは「計画が安定している」ことを前提としている
ガントチャートは、「最初に計画を立て、その計画に沿って進める」という考え方を前提としています。具体的には、以下のような状況です。
- 作業内容が事前に洗い出されている
- タスクの順序や依存関係が大きく変わらない
- スケジュール変更は例外的である
この前提が成り立つ場合、ガントチャートは「計画との差分を確認する」ための強力なツールになります。
- 工程が決まっている業務
- 過去に何度も繰り返しているプロジェクト
- 関係者が少なく、調整が少ない
といったケースでは、ガントチャートは今でも十分に有効です。今回扱うのは、ガントチャート向き・不向きの問題です。
大規模プロジェクトの現実
日々、計画を揺るがす課題や変更が発生する
大規模プロジェクトでは、計画時点では想定できなかった事柄が次々に発生します。
- 要件の追加・変更
- 関係者間の認識差による手戻り
- レビューでの差し戻し
- 外部要因による遅延
これらは「想定外」ではなく、ある程度起きることを前提に進める必要がある出来事です。
この変更、ガントに反映するとどこまで直す必要があるんだっけ…
1つの変更が広範囲に影響する
大規模プロジェクトでは、タスク数が非常に大きくなります。タスク数が増え、依存関係が複雑になるほど、
- 1つの作業の遅れ
- 1つの仕様変更
が、複数の工程に連鎖的に影響します。その結果、ガントチャート上では多数のタスクを同時に修正する必要が生じます。そうして、次第に、延々と続くガントチャートの修正に悩まされるようになります。
ガントチャート運用で起きがちな問題
メンテナンスが目的化してしまう
ガントチャートを正確に保とうとすればするほど、
- 日付調整
- タスクの追加・削除
- 依存関係の引き直し
といった作業が増えていきます。本来注力すべきは、
- 課題への対応
- 判断と調整
であるにもかかわらず、「管理のための管理」に時間を取られてしまいます。
最新でない可視化が誤解を生む
更新が追いつかなくなると、
- 実態と合わないスケジュール
- 説明資料としてだけ存在するガントチャート
が残ります。結果として、「ガントチャートは参考にしない」という状態になり、可視化そのものが形骸化します。
大規模プロジェクトに求められる可視化の考え方
1つの図で全てを管理しようとしない
大規模プロジェクトでは、以下の2つが必要になります。
- 関係者が多く、タスクも多岐に渡るため、同じ全体像を共有できるようにする
- 多岐に渡るタスクについて、日々の進捗や課題を詳細に把握する
これらは性質が異なるため、1枚で同時に可視化を満たそうとすると、どちらも中途半端になります。
細かい計画より、状況が分かることが重要
ガントチャートでは、タスクの依存関係を押さえるため、自分のタスクの前後のタスクも細かく書かれてあります。しかし、自分の担当ではないタスクの計画を細かく見せられても、あまりよく理解できません。
大規模プロジェクトで本当に知りたいのは、自分にタスクに影響する現在の状況についてです。
- どこが止まっているのか
- なぜ進まないのか
- どこで判断が必要なのか
そういった観点では、ボリュームの大きすぎるガントチャートは用を足しません。
解決策❶ 中日程スケジュールによる全体共有
パワーポイントなどで、重要なマイルストンだけ示す
全体共有には、中日程レベルのスケジュールが適しています。細かい依存関係はあえて描きません。
- 主要タスクのみ
- 開始と終了
- マイルストーン中心
全員が同じ認識を持つための可視化
上記のようなレベル感であれば、
- 経営層
- 関係部門
- 現場
が同じ図を見て会話できます。修正も容易なため、「変更前提」のプロジェクトでも破綻しにくいです。
精緻だが非常に細かい表を見るよりも、誰の目にも分かりやすいシンプルな絵を見た方が、関係者間の共通認識を得やすいです。特に、大規模プロジェクトでは、全体が見えなくなりがちですから、こういったレベル感の絵で、他チームとの依存関係も確認することが有用です。
解決策❷ エクセル表による柔軟な進捗管理
成果物 × 作業ステップの表形式で管理する
個々の進捗管理には、ガントチャートではなく「表形式」が向いています。
例. 設計タスク管理
| 作成者 | レビューワー | 設計 | レビュー | 修正 | ユーザ確認 | |
| 機能A | Aさん | Xさん | 完了 | 完了 | 完了 | 6月26日完了 予定 |
| 機能B | Aさん | Xさん | 完了 | 完了 | 着手済 | 6月30日完了 予定 |
| 機能C | Bさん | Xさん | 完了 | 7月21日開始 予定 | 7月28日開始 予定 | 8月4日完了 予定 |
追加・削除・期日変更が容易
- 成果物の追加・削除
- 作業ステップの変更
が、行・列の操作で完結します。そのため、状況変化に合わせて管理方法を変え続けることができます。
大規模プロジェクトでは、仕様変更による機能の追加や、課題などによる手戻り、日程変更が頻発しますので、こういったエクセル表の方が格段にメンテナンスしやすいです。
実務上のステータスが簡単に見える
エクセル表は、縦軸・横軸の整理された表ですから、各タスクがどのステータスにいるのかが一目瞭然です。
- ユーザ確認待ち
- レビュー後、修正中
- レビュー待ち
といった状態が、そのまま可視化されます。
そして、作業開始予定日が過去日になっている場合は、遅延していると簡単に分かります。
ガントチャートが悪い訳ではありません。しかし、大規模で複雑なプロジェクトには向かない場合があることも事実です。大事なことは、プロジェクトの性質に合った手法を選ぶことです。
スケジュールの全体像は粗く・共有しやすくすること。日々の進捗管理は柔軟に更新できる形を選ぶことが、有用だと考えます。
なお、可視化の本質、失敗パターン、見える化の実現方法の全体構造については、可視化の全体像記事で整理しています。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
