プロジェクト管理と聞けば真っ先にイメージされることの多い“ガントチャート”。皆さんは、ガントチャートを活用してプロジェクト管理業務を行っていますか？
主にソフトウェア開発などの分野で使用されているガントチャートですが、現在は業界業種を問わず、様々なプロジェクトでガントチャートが使われています。しかし、作成したガントチャートをプロジェクト管理に活かせているかという点に関しては、そうではない企業の方が多いという事実もあります。
上手く活用すればプロジェクトを円滑に進めるための武器になり、便利なガントチャートや工程管理は、なぜ現場で使えず、機能しないのでしょうか？
今回は現場で使えない理由を考えながら、ガントチャートの基礎を説明しつつ、初心者でもわかりやすい使い方を紹介していきます。
ガントチャートとは
ガントチャートというプロジェクト管理ツールが生まれたのは、実に100年以上も前の話です。
1903年にアメリカ人の機械工学者であり、経営コンサルタントでもあったヘンリー・ガントが工事進捗やプロジェクトスケジュールを確認するためにチャートを考案しました。当時の日本といえば東京に山手線が開通したり、小学校教科書が国定となったり、世論が日露戦争へと傾いてく変化の激しい年でした。
また、プロジェクトのコミュニケーション手段といえば手紙や無線、伝令などが一般的で、まだ電話が本格的に普及していない時代です。現代社会と比較するとあまりにも違った環境、違った文化形式がありました。
そんな中で生まれたガントチャートは、時代とビジネスと共に少しずつ変化してきました。しかし、その本質は今も変わらず、私たちは情報化社会である現代においても、100年以上も前のプロジェクト管理ツールに頼っているのです。
よくよく考えてみれば、そんな時代に生まれたプロジェクト管理ツールが現代社会にフィットするとは考えづらいものです。実際に、プロジェクト管理の現場ではまったく機能していないガントチャートを多数見かけることがあります。
しかしこれは、ガントチャート自体に問題があるのではなく、どちらかというとプランを作成・編集する“人”に大きな問題があるのです。
現場でガントチャートが機能しない理由
プロジェクト管理手法やノウハウを体系立ててまとめたガイド、PMBOK(Project Management Body of Knowledge)でも、ガントチャートの活用が登場します。それほどにプロジェクト管理に重要なツールであるにも関わらず、現場で機能しない理由とは何でしょうか
実工数を無視したプロジェクト計画を作れてしまうこと
たとえば建設業のプロジェクトでは、資材や成果物はすべて目に見えるものなので、予算や締め切りの調整を行う上で顧客からの理解を得やすいという特徴があります。「200億で100階建てビルを造れ」と言われても、「200億では50階建てまでしか造れません」と言えば、そこに反論してくる人は少ないのです。
しかしソフトウェア開発の現場ではそうもいきません。ソフトウェアという製品自体目に見えないものであり、専門家同士で話し合って予算や納期を検討することも多くありません。このとき実際にガントチャートを使ってプロジェクトの初期計画を組んでみると、「案外できそう」というフワッとした理由で合意してしまうことがあるのです。
しかし実際には実工数を無視した計画だったり、プロジェクト中のトラブルをまったく予期していない計画だったりします。そうなるとガントチャートで作成した初期計画が全く無意味というほど、破たんしたプロジェクトになってしまうのです。
タスク同士のプロジェクト依存関係が見えない
ガントチャートの基本は締め切りがあって、それに対してタスクごとの計画と実績を入力や記録をしていくことで進捗を管理します。しかし、タスク同士のそれぞれの依存関係はまったく見えません。
例えば次のようなことが起きます。
Aさんがあるタスクを完了させるために、Bさんから〇〇という情報を得なければなりません。しかし、プロジェクトマネージャーはその前工程について知らなかったために、ギリギリになってBさんんに〇〇という情報の提供を要求します。しかし、Bさんは会社規定に従って〇〇という情報を提供するためには今から10日間かかると言います。その結果プロジェクトが大幅に遅れ、プロジェクトチーム全体が無理を強いられるようになるのです。
このようなケースの例ではなく、本当に頻繁に起こるケースです。ガントチャートの特徴を理解していがために、こうしたトラブルが発生します。
締め切りベースでプロジェクトや仕事が進んでしまう
ガントチャートによって各タスクやＴＯＤＯの締め切りを設定すると、プロジェクトメンバーは“締め切りベース”でタスクをこなすようになります。つまり、開始は遅れ締め切りギリギリになるまでタスクを完了させないということです。
本来なら効率を上げ、前倒しでタスクを完了させてしまうことがベストなのですが、余裕のあるプロジェクトは締め切りの際に、どうしてもギリギリで終わらせようという考えが生まれてしまうのです。
逆に、残工数で開発や複数の仕事が進んでしまうこともプロジェクトの終盤には多く見られる光景です。当初計画のガントチャートは崩壊し、プロジェクトの終盤には「残りの工数でどれだけ作れるのか」がプロジェクトの最大のポイントになり、できる範囲で進めるしかない状況に陥ります。
ガントチャートを作ること自体が目的になり更新されない
プロジェクト全体のガントチャートを作成すると、それなりに手間をかけた大作が出来上がります。このとき、ガントチャートを作ったこと、用意したこと自体に満足してしまって、その後の更新がされないというケースが少なくないのです。
ガントチャートには計画と実績を登録し進捗管理を行うという目的と、計画変更時にも柔軟に対応するという目的があります。もちろん計画変更に応じて更新されなければ、ガントチャートはまったくの無意味です。
Excelのガントチャートは変更が大変なので、かなりの労力をかけて作ったガントチャートを触る気にもならないということも、現実的なユーザー心理としてもあるのでしょう。
更新に時間がかかるためタイムラグが生まれる
計画変更を反映させ、ガントチャートの更新を意識しても機能しない場合があります。更新までに時間がかかってタイムラグが生まれるせいで、間違ったタスク遂行やプロジェクト進行がなされてしまうケースです。Excelファイルであれば更新までに１日以上かかってしまい、このようなケースが起こることもあるでしょう。
Excelで管理しているためどれが最新版なのかわからなくなる
多くの企業がプロジェクト管理ツールとしてExcelを使用しており、ガントチャートもExcelで作成する場合がほとんどです。しかし、Excel表で管理していると、次第に最新版のガントチャートが一体どれなのか、どこにあるのかわからなくなってしまうこともあります。Ａパターン、Ｂパターン、Ｃパターンとシュミレーションリストを作っているうちに、ゴチャゴチャになり、わけがわからなくなることを体験した方もいると思います。
そうなると適切な更新もできなくなるので、結局ガントチャートが機能しなくなってしまうのです。
誰もがガントチャートを表示・確認しなくなる
こうした管理環境が続いていると、最後には誰もガントチャートを表示・確認しなくなります。
誰かがExcelファイルのマクロを壊してしまい、「この進捗状況はおかしい」と感じ、確認しなくなることもあるでしょう。
ガントチャートを正しく機能させるためには
まず、ガントチャートをExcelで作成しプロジェクト管理している環境は廃止すべきです。個人や小規模プロジェクトなら問題ないでしょうが、規模が大きくなるにつれExcelでの管理は限界になります。そもそもExcelは“表計算ソフト”であることを忘れないでください。
次に、プロジェクト管理ツールの導入を検討しましょう。統合型プロジェクト管理ツール SI Object Browser PMライト版（有料 次の章で詳しくご説明）には視覚的に操作できるガントチャート作成と、それをプロジェクトメンバー内で簡単に共有できるシンプルな機能が整っています。現在の進捗状況が把握できたり、スケジュールのリスケも簡単に行うことができます。また、製品によってはタスク同士の依存関係をはっきりさせたり、ルール定義によって実工数を意識したガントチャート作成が可能です。
プロジェクト管理ツール SI Object Browser PM（以下、OBPM）ライト版（工数管理とガントチャート）
プロジェクト管理ツールOBPMライト版という OBPMシリーズの製品ラインナップが追加されました。
プロジェクト管理ツールOBPMライト版は、従来のOBPMよりも機能限定版となっております。主に工数管理とガントチャートによるスケジュール管理機能が中心のプロジェクト管理アプリケーションです。
OBPMライト版が生み出されたきっかけは、以下のようなユーザー様や会員様、メディアからの声（オーダー）でした。
・OBPM（フル機能版）だとプロジェクト管理におけるスコープが広く、原価管理や調達管理については、既存の仕組みがあり不要で、そちらを利用しなくてはならない。
・既存システム間との二重入力やインターフェース連携することまでは必要性を感じていない。
・プロジェクト管理については、障害管理やＱＡ、ドキュメント管理他は、オープンソースソフトウェアをオンライン利用やドロップし利用している。
・特定グループや複数プロジェクトのガントチャートと工数予実を管理できれば良い。
ユーザー様からは、ガントチャートだけでなく、統合管理ツールとして進捗報告や工数EVMが把握できて、状況が見えるところが優れているという評価をいただいております。
その一部を公開したいと思います。
成果物とWBSの標準化
OBPMは、「ドメイン」という単位で「プロジェクト管理するための標準テンプレート」をたくさん用意することができます。
ドメインは、製品ラインナップにより制約がありますが、11～15機能の複数の標準テンプレートを作成し運用することができます。
その中の「工程タスク成果物登録」という画面について説明します。工程タスク成果物登録はWBSを定義する画面です。
「WBSを標準化するってどういうこと？どうしたら良いの？」と、ユーザー様よりよくご質問をいただきます。
WBSを標準化するポイントは、3つあります。
１）プロジェクトの作業に必要な局面（工程）を洗い出す。
２）工程ごとに必要となる（と考えられる）成果物を洗い出し、リスト化する。
３）成果物を作成するために必要な作業（タスク）を第１～２階層（レベル）で定義する。
ドメインは、標準化を目的としていますが、あまり凝った作りにすると、逆に現場がそのままでは適用し辛いものになってしまったり、そもそも考えや検討が進まず、纏まらなくなくなってしまうため、過去に成功したプロジェクトやベテランPLからヒアリングして、若手PLの底上げを目的とした定義を行うのが良いのではないかと考えます。
進捗基準とガントチャート
次に、実際のプロジェクトにおける進捗基準とガントチャートについて説明します。
皆さんはガントチャートのタスクはどのように作成されていますか。
開発・エンジニア系のプロジェクトにおいては、担当者レベルのタスクは、どのような単位で作成されていますか。
私見となりますが、担当者レベルのタスクについては、大きく2通りあると考えています。
１）機能や画面・帳票単位で作成している
２）１人日～４人日のアクティビティレベルで作成している
それぞれで管理した場合の進捗率の基準はどのように定義していますか。
担当者の感覚で入力する属人的な管理であったり、運用ルールを決めているプロジェクトもあると思います。
OBPMは、進捗率の基準を決めて入力することができます。
用途を交えながら説明していきます。
■機能や画面・帳票単位で作成する
例えば、設計工程であれば、着手：10%、設計書作成：40%、内部レビュー：50%、内部レビュー結果反映：60%、顧客レビュー：80%、顧客レビュー結果反映：100%、と言った感じで、成果物作成におけるチェックポイントを設け、進捗率のルールを決定します。
この方法を採用した場合、PLは、作業進捗をわかり易くイメージできるメリットがあります。
OBPMは、この進捗率の定義をドメインで予め設定することができます。ただし、この方法は、進捗がどこまで進んだかは分かりますが、作業が予定通り進んでいるのか、遅れているのか状態が把握しづらいと行ったデメリットがあります。
■アクティビティレベルで作成する
同じように設計工程で考えてみます。
例えば、先程定義した進捗率をあるタスクの１階層下のタスクとして定義します。
その上でスケジュール期間を１～４日程度で引っ張ります。進捗率は、作業日付（カレンダー）に対して遅れか進みかを入力していきます。こうすることで、作業が予定通り進んでいるかどうか、すぐに把握することができます。
ただし、この方法は、作業経過日数に対して入力していくため、該当日数の予定作業が完了していないのに感覚で進捗を進めてしまう恐れがあります。
また、タスクの入力が細かくなり管理が煩雑となるといったデメリットもあります。
プロジェクトの規模や状況を見て、うまく両者を組み合わせて、生産性の高いガントチャートを作り進捗管理することが重要となってきます。
ガントチャートと進捗報告・EVM
プロジェクトメンバが進捗率を入力したら、PLは、プロジェクト進捗報告を纏めていきます。
OBPMは、進捗報告をPMや上長向けに報告する機能が備わっています。また、進捗報告を実施することで、報告時点のEVMをプロットして、プロジェクトの進捗状況をリアルに表示することができます。
EVMを確認することでプロジェクト別の傾向が見えてきます。いくつかのプロジェクトの停滞状況が続き、遅れや課題が発生していることも一括で見える化できます。
そのため、ガントチャートの進捗実績の正確性が重要なものとなってきます。
プロジェクト管理するためのガントチャート
ここまで、プロジェクト管理するためのガントチャート（計画作成）についてご覧いただきました。
しっかりと入力して管理されているプロジェクトもありますが、ガントチャートを作り管理するのは面倒くさいものです。前PLのガントチャートのフォーマットをそのまま流用していますが、理解が浅いため不便さを感じています。もしくは、属人化しており、他のメンバがメンテナンスできないなど課題もあるでしょう。
ガントチャートは、誰が見てもわかるような進捗状況や残タスク・担当者がわかるように作成すべきです。そのためには、ずっと私が各ページやサイトで述べてきたようなWBSの標準化や進捗管理の基準が決め手となります。
プロジェクトを成功させるためのガントチャートって、どのようなものなのか・・？
お客様や契約・開発手法の前提やカテゴリーがいくつかあるかもしれませんが、一度じっくり考えてみてください。何か新しい気づきが生まれることでしょう。
その際、OBPM導入をご検討していただけますと幸いです。（細かな料金や利用規約につきましては、弊社営業にお問い合わせいただくか、問合せフォームに投稿をお願いします）
皆で共有できる分かり易いガントチャートを作って、成功プロジェクトを増やしていきましょう！
なお、進捗管理のポイントをまとめた資料もご用意していますので、こちらもぜひご活用ください。
