なぜガントチャートはプロジェクトで使えないのか

shutterstock_275262593

[この記事は一部PRを含みます]

 

「プロジェクトを計画しよう!」という話になった時、ガントチャートはよく利用されます。しかし、実際に現場でそれがツールとして「使える」かというと、使えなかったりします。

それはなぜなのか、そしてその対策はどうすればいいかをお伝えします。

 

目次

 

そもそもガントチャートとは何か?

「プロジェクト計画と言えばガントチャート」と連想されるぐらい、ガントチャートというツールは一般的です。PMBOKなどのプロジェクトマネジメントに関する教科書にも必ず出てきます。

しかし、ガントチャートがそもそもどういうものなのかを知っている人は多くありません。

 

ガントチャートとは、ヘンリー・ガントという名前のアメリカ人のおじさんが、工事の進捗を確認するために約100年前に生み出したツールです。

ガントチャートが生まれた1903年は和暦で言うと明治36年、日本全体が日露戦争に向かう直前の年です。日本で初めて電話が開通したのは1890年で、当時民間にはほとんど普及していない状況でした。情報のやり取りはもっぱら無線や手紙や伝令(お使い)に頼る時代です。

つまり、ビジネスの変化も今とは比べ物にならないぐらい遅い時代です。そうした時代のツールが現代の高度情報化社会で使えるかというと、「ちょっと厳しいな」というのは直感的に理解できるところだと思います。

ただ、見た目的に分かりやすいところがあるので、今でもエクセルやWebサービスなどで作成して利用されたりしますが、実際に現場で運用してみると、やはりいくつかの理由で難しいところがあります。

 

https://commons.wikimedia.org/wiki/File:Gantt_it.png

 

 

ガントチャートあるある

ガントチャートを今の動きの早いプロジェクトで使ってみるとどうなるか。大体、下記のようなパターンになってしまいます。

  1. 「何をやるか」が決まっていないのになぜか計画前に納期だけ決まっていて、「死守だ!」と言われてそれに間に合わせる計画を作成することになる
  2. 納期がカギなので、ガントチャートを作って逆線表(〆切から逆算した計画)を作る
  3. 何となく形になりそうなのでプロジェクトを開始する
  4. プロジェクト開始後、想定外のトラブルや計画変更が頻発してガントチャートの更新に膨大な時間がかかる
  5. 更新に時間がかかるため、「今どうなっているのか」がわからなくなる(みんなが常に「過去の計画」を見てプロジェクトをやるようになる)
  6. エクセルなどで作成していると、どれが最新版なのかが分からなくなってより混乱する
  7. 誰もガントチャートを見なくなって計画がバラバラになってトラブルが頻発する
  8. プロジェクト炎上

 

プロジェクト計画としては 1の時点でそもそも間違っているのですが、それを横に置いておいたとすると、一番の問題は「ガントチャートは更新に時間がかかる」というところにありそうです。

そこで、変更が簡単なツールを導入したりしますが、それでもなかなかうまくいきません。

なぜか。それは「ガントチャートで分かるのはタスクの割り当てと、その〆切だけだから」です。

 

ガントチャートが現場で使えない理由①:実工数を無視した〆切になりやすい

「ガントチャートあるある」で見たように、ガントチャートは「〆切ありき」で計画されるプロジェクトでよく利用されます。

プロジェクト計画というのは「まず何をやるかを決めて、それに必要な工数を割り出し、無理のない範囲で予算と〆切を設定する」というものですが、特にIT業界では目に見えないソフトウェアを扱っているところもあり、ここの合意を作ることが非常に難しいという事情があります。

 

経営的な事情や営業との兼ね合いで要求と〆切が決まるのは「お金」に関わる話なので、ビジネスとしてある程度しょうがないところがありますが、本来はここを調整していくのがプロジェクトマネージャーやリーダーの仕事です。

例えば、経営者や営業が「4月までに200億円で30階のオフィスマンション兼用のビルを作りたい」と言ってきたとして、「その予算と納期なら20階までのオフィスビルしか作れません」と回答して議論しながら合意をつくるのがリーダーの仕事なのです。

しかし、ソフトウェアは目に見えないので、専門家同士でちゃんと検討せずに「何となくできそうな気がする」という合意でスルッと始まって、プロジェクトの大詰めになって「計画通りできていない」とか「言っていた話と違う」とか「徹夜でやれ」みたいな話になり、予算も納期も大幅に超過して品質もバグだらけでボロボロ、エンジニアも鬱になったり職場が嫌になって離職、みたいな話になったりします。

こうしたプロジェクトは本当にたくさんあるので、社会的に「こういう計画はダメだ」という共通認識が出来てもいいぐらいなのですが、未だに日常的に見かけます。

 

つまり、実工数を無視して間に合わせでそれっぽい計画を作ってしまえるという問題点が、ガントチャートにはあるのです。

 

ガントチャートが現場で使えない理由②:タスクの相互依存関係が見えない

上で見た通り、ガントチャートは全体の〆切しか意識していない計画になってしまうため、タスクの相互依存関係が見えません。

「この計画で行けますか?」とガントチャートを作って関係するチームや自分のチームのメンバーに共有したとき、人々が何を気にするかというと、「自分が割り当てられたタスクと、その〆切」だけです。なぜなら、ガントチャートにはそれしか表現されていないからです。

 

これもあるあるなのですが、ガントチャートで計画して実際にプロジェクトを始めてみると、よくこんなトラブルが発生します。

  • リーダー「Aさん、◯◯という作業の〆切が来週水曜日なので進捗教えてください」
  • 担当者A「いやこのタスクやるんなら、Bさんから✕✕の情報をこの形で貰わないとダメだよ
  • リーダー「えっそんな前工程が必要なら先に教えて下さいよ」
  • 担当者A「いや計画はあなたの仕事でしょ。俺も他の業務で忙しいんだから、そのプロジェクトのことばかり気にしていられないよ
  • リーダー「じゃあBさん、この情報ください」
  • Bさん「その情報は社内規定に基づいて、これこれこのフローで申請してください。最短で10営業日で回答できます
  • リーダー「詰んだ…

 

書いてて涙がちょちょ切れますが、こういうケースは本当によくあります。さらに困ったことに、こうしたトラブルは特に他部署との調整が頻発する納期直前で起こりがちです。

こうした場合、大体リーダーと担当者AもしくはBとの間でケンカになって「あいつが悪い」「こいつが悪い」みたいな話になってしまうのですが、誰が悪いわけでもなく、そもそも計画時点でタスクの相互依存関係を把握できていないことが問題なのです。

(ガントチャートでは「イナズマ線」という、タスクの〆切を繋げたラインが引けますが、これはあくまでも記載されたタスクの進捗を繋げた線なので、タスクの相互依存関係を示すものではありません。)

 

イナズマ線の例 http://www.it-innovation.co.jp/wordpress/wp-content/uploads/2014/04/hironaka_chart110111b.gif

 

 

ガントチャートが現場で使えない理由③:納期に頼ると「学生症候群」と戦うことになる

もう一つ、ガントチャートで計画を作ることのマイナスポイントは、メンバーが学生症候群に陥ってしまうことです。

学生症候群とは何かというと、「〆切直前にならないとタスクに着手しない」という症状のことです。

 

情報システム用語事典:学生症候群(がくせいしょうこうぐん) – ITmedia エンタープライズ

納期のある作業を行う際に、余裕時間があればあるほど、実際に作業を開始する時期を遅らせてしまうという、多くの人間に見られる心理的行動特性のこと。

 

自分のプロジェクトマネージャーとしての経験では、約95%の社会人がこの学生症候群に罹患しています(笑)。

…いや、笑い事ではないのですが。

下の図はちょっと茶化して学生症候群のことをグラフ化したものです。ほとんどの人はこういう形で仕事をします。

青い線が生産性を表していて、棒グラフの赤が「知らんがな」と思っている時期、黄色がパニック状態、緑が実稼働、紫が「自分に腹が立って次はちゃんとやろうと思う」時間、水色が「〆切を過ぎて気づいたイケてるアイディア」です(笑) http://blog.nearfuturelaboratory.com/2012/11/16/the-creative-process-as-seen-by-ben-pieratt/

 

しかし、多くの人が〆切ベースで仕事をしてしまうのも現代においてはしょうがないところもあります。

多くの企業が余裕を持っていない今、プロジェクトが通常業務とは別にアサインされていたり、複数のプロジェクトの掛け持ちも一般的にあります。また、プライベートで家庭の事情があったりすることもあるでしょう。そうした状況で〆切を提示されると、普通の人は何となく自分で「これぐらいかかるな」と工数を見積もって、ギリギリに終わるように仕事を進めるのです。

そして、作業時間の見積りが甘かったり、想定外の出来事が発生すると、ズルズルとそれぞれのタスクが後ろにズレていって、プロジェクト全体もズレていきます。最終的に、プロジェクトの納期直前にしわ寄せが来て、プロジェクトが炎上するハメになるのです。

プロジェクトの期間設計にはバッファ(時間的な余裕)を見積もることが必要ですが、この学生症候群には有効な対策にはならないのです。

 

また、実際にIT系のプロジェクトをやったことがある人には理解できると思いますが、ソフトウェアは建築工事と違って、「1日目の進捗率は期間10日の1/10」という形にはなりません。例えば、期間10日間のタスクで8日間考え続けて、最後の2日で仕上げた資料やプログラムがとても優れていた、ということは普通にあるのです。

ガントチャートは時間経過とともにタスクの進捗率を記載したりしますが、ソフトウェアのように検討や設計に重点が置かれたプロジェクトには、この進捗率が通常は当てはまらないのです。

こうした「見せかけの進捗率」に惑わされて、リーダーやマネージャーが担当者に成果物を途中で出させたり日報を書かせたりしたりもしますが、担当者は中途半端なものを出すのを恐れたり、報告の準備に余計な労力をかけてしまって、結果的にプロジェクトの生産性を下げることもしばしばあります。

 

対策としてのクリティカルパスマネジメント

「ガントチャートが使えないのは分かった、じゃあ何を使えばいいと言うんだ!」という声もあるでしょう。確かに、もう2016年になったのに未だに1903年に生まれたツールを使っているのはなぜかというと、他にいいものがないからです。

しかし、文句を言っていてもしょうがありません。プロジェクトの成功率を上げるためには学習と前進あるのみです。

 

代替案になるのは、プロジェクトを「クリティカルパス法」で計画を初期段階から明確にして関係者に共有することです。

クリティカルパスとは、各タスクの相互依存関係と工数を図で表現したものです。こちらはデュポン、ジェネラル・ダイナミクス、アメリカ海軍が生みの親で、第二次世界大戦後の1950年代、宇宙競争や軍拡、電子機器開発などの近代工業化社会の中で生まれました。

 

PERTネットワーク図で表したクリティカルパス。どのタスクがどのタスクに依存していて、どれくらい工数がかかるかを表現している。

 

クリティカルパスの最も優れている点は、誰が見てもタスク同士の相互依存関係が明確にわかるところです。真ん中の30と書いてあるタスクを片付けないと、40や50のタスクが完了しないことは誰の目にも明らかです。

(ちなみに、上のようなプロジェクトで一番盲点になりやすいのは40から50への工期の考慮です。こうした部分が計画から漏れていると、大幅なプロジェクト遅延につながります。)

 

また、計画に変更が発生した時に、どのタスクが他のどのタスクに影響しているかも明確にわかるため、緊急事態への対応にとても優れています。(よいプロジェクトマネージャーやリーダーの力量は、トラブルへの対応時に出るものです。)

 

クリティカルパス法はご説明したガントチャートの問題点を全て解決できます。

  • ガントチャート:実工数を無視した〆切になりやすい
    • ⇒ クリティカルパス:タスクの積み上げでプロジェクトを設計することができる
  • ガントチャート:タスクの相互依存関係が見えない
    • ⇒ クリティカルパス:誰が見ても一目瞭然
  • ガントチャート:納期に頼ると「学生症候群」と戦うことになる
    • ⇒ クリティカルパス:プロジェクトにおけるタスクの重要性がわかるので、メンバーからの協力を得られやすい

 

特に重要なのが3つ目のポイントで、実際にクリティカルパスでプロジェクトを管理してみると、他部署などからの協力が得られやすいことに気がつくでしょう。

実際にタスクを振られる側の心理からしても、ガントチャートで仕事と〆切を押し付けられるよりは、クリティカルパスでプロジェクトの一部に貢献できるのだと思えるほうがやる気が湧きますし、実際にタスクを早めに片付ければ、他のメンバーにもその貢献を示すことができるのです。

 

ただ1点だけ問題が…

このように、クリティカルパス法はとても優れたプロジェクトマネジメント技術ですが、1点だけ問題があります。

 

クリティカルパス法を使えるソフトウェアが世の中に極めて少ないのです。

ガントチャートはちょっとググるだけでエクセルのマクロから有料の専用ソフトウェア、Webサービスまでたくさん出てきますが、クリティカルパス法が使えるソフトウェアはほとんどありません。

私はエクセルの描画機能で作っていましたが、それも結構な手間がかかってしまいます。簡単にネットワーク図が作れて、しかもオンラインでメンバーと共有することができれば、バージョン管理の問題なども気にしなくて済みます。

 

というわけで、私達が作りました(ここからはちょっと宣伝です)。

マンモスチームワークというサービスで、クリティカルパス法をウェブブラウザ上で簡単に表現することを可能にしました。

projectmap

それぞれのタスクの相互依存関係を簡単に作って共有できます。計画変更もクリックとドラッグ&ドロップで出来るので簡単です。現在は工数計算はできませんが、次期バージョンで可能になる予定です。

 

登録はもちろん無料で、大幅にパワーアップする次期バージョンまでは制限無しで無料でお使いいただけます(しかも今ご登録いただければ、課金版リリース時にクーポンを発行します)。

もしプロジェクト管理でお困りでしたら、ぜひ試してみてください。フィードバックも大歓迎です。

 

Masayoshi Hashimoto

「フロントライン通信」編集長。業務経験は15年を超え、メディアサイトから数千万人規模の会員システムまで、10社で80件以上のプロジェクトのマネジメントを実施。2011年にスタートアップを立ち上げ、多くの人がプロジェクトをより成功できるためのツール「マンモスプロジェクト(Mammoth Project)」を開発。世界中の現場で戦うチームを応援することを人生の使命とする。

You may also like...

コメントを残す

メールアドレスが公開されることはありません。