Excelで工程表を書いてはいけない
さる8月、翔泳社主催の「PM
Conference 2008」に招かれて講演をした。テーマはプロジェクト・コントロールの技法論で、私が長い間、エンジニアリング業界とIT業界の二足のわらじを履いてきた経験から、両者の比較を論じたものだった。最近のIT業界における「プロジェクト・マネジメント」の認識の普及進展はめざましいものがある。これに対して、エンジニアリング業界は過去10年以上、EVMSの徹底化以外とくに主立った進歩はない。にもかかわらず、両者の違いはいまだ歴然としたものがあり、それはとくにプロジェクト・コントロールの基本であるWBSやコントロール・リストなどの使い方で明瞭だ、というのが論旨だった。
ところで、この講演の中で、「工程表のガントチャートをExcelで書いてはいけない」と強調した点が、どうも多くの聴衆の注意を引いたらしい。終わってからのアンケートでも、そこに関する感想が少なくなかったし、講演後、直接私のところに質問に来られた方もいた。“じゃあどうしたらいいんだ?”“何か良いツールはあるのか?”というのが率直な疑問らしい。
Excelでガントチャートを書きたくなる理由は、私もよく分かる。まず、事実上すべてのPCにのっており、誰でも読み書きできる。縦横に罫線があり、ガントチャート作成に便利に思える。お絵描きの道具がそろっていて、すぐに矢印を引ける。担当者の名前や作業量なども表に書き込める。必要なら、さらに引出し線だの注釈だの好きなコメントを書いていける。実に便利である。
にもかかわらず私が、Excelで工程表を書いてはいけない、と説明したのには三つの理由がある。第一の理由は、クリティカル・パスが見えないことだ。プロジェクトの出発点から、全作業の完了までの経路の中で、時間的に最長の経路をクリティカル・パスとよぶ(日本語では「隘路」だ)。プロジェクト全体の納期は、このクリティカル・パスの長さに等しい。したがって、プロジェクトの納期短縮を図りたかったら、どこがクリティカル・パスになっているかを見つけ出して、それを短くすることを考える必要がある。
コスト=原価管理の世界では、プロジェクトのコストは、すべてのアクティビティのコストの足し算になる。大小を問わずどのアクティビティで1円節約しても、全体予算の1円節減に直結する。だからコスト・マネジメントでは、基本的にすべてを軽重なく公平に見ていく必要がある。ところがスケジューリングの世界では、クリティカル・パスの長さだけがプロジェクト全体の期間を決める。非クリティカルなアクティビティについていくら期間短縮の努力を払っても、全体には何の影響もでない。そこでタイム・マネジメントでは、重要な管理対象と重要でないものが峻別される。これがマネージャーにとって最も大きな違いだろう。
Excelで工程表を書いてしまうと、ここが見えなくなってしまう。「だったら太線にしたり、赤く表示したらいいじゃないか」というのは浅知恵というものだ。クリティカル・パスは、作業が進むにつれて(その進捗や遅延にしたがい)しばしば他の経路に移ってしまうことを忘れている。このため、潜在的にクリティカル・パスになりやすい経路を、「サブクリティカル・パス」と呼んで、最初から注意しておく必要がある。CPMの技法論でいえば、フロート日数=ゼロの経路がクリティカル・パスになる。そこで、フロート日数が(たとえば)2週間以内の経路をサブクリティカルとして認知しておく、などの工夫がいるのだ。Excelの線表では、このフロート日数が見えてこない。
第2の理由は、先行作業が遅れた場合の影響範囲がわかりにくい、ということだ。実際問題として、プロジェクトというのは遅れるものなのである。これは、最初に作成する工程表が「ターゲット日程」を表しているものである以上、当然のことだ。そこで、実務上問題となるのは、前方の作業が遅れたとき、後ろの方のアクティビティが着手するのはいつになるのか、という点だ。これはとくに、担当者や担当部署が異なるときは悶着のタネだ。ところが、Excelの線表というのは、一つの線を延ばしたら、後ろにつながる線を全部、自分の手で書き直さなくてはならない。当然、ここにはミスが入り込む可能性も出てくる。
3番目の理由は、スコープの追加や、WBSの変更に対応した修正が面倒であることだ。これは第2の理由とも通じるが、部分的な修正が全体の変更につながる、というのがプロジェクト・ネットワークの性質である。これを、書き手がすべて自分の頭の中で追いかけなくてはならない。そして、追加変更は、プロジェクトに宿命的について回るものである。
結局、Excelで書いたガントチャートは、ロジック無き「絵」にすぎないのだ。プロジェクトの工程表とは、背後にロジック・ネットワーク・スケジュールを持っていなければならない。ここが根本的な認識のズレなのである。Excelで工程管理してはいけない。私の主張は、この点にある。
じゃあ、工程表どんなツールで描いたらいいのか?--こういう質問が出てくる点が、まあいかにもIT業界らしいな、と感じてしまう。こちらは考え方の話をしたつもりなのに、いつの間にかツール論になっている。ツールとはさみは使いようだから、上記のことさえ忘れなければ、別にExcelを使うこと自体がわるいわけではない。まあ、不便だが。
それでも、何かのツールを推奨しろ、という話になると、ちょっと困ってしまう。Microsoft
Projectは誰もがまず思いつく製品だろうが、いくつか理由があって、私はMS Projectはあまりおすすめしない。たとえば後続のアクティビティをすぐに見つけにくい、だとか、アクティビティ数が増えていくとひどく重くなるとか、は機能的問題だからまだしも、Forecastという概念がないとか、プロジェクト全体の締切というものがクリティカル・パスの長さとは別に規定されているとか、概念自体に違和感を感じる。
米国でのある調査でも、MS Projectはもっとも多く購入されているが、もっとも使われていないプロジェクト・マネジメント・ソフトだという結果が出ている。そもそも、この製品を出しているMicrosoft自体、自社の主力製品をリリースする際、期日変更や早期パッチの常習犯になっていないだろうか。自社のプロジェクトをきちんとマネジメントできない会社の製品を、私はあまり信用したくない。むろん、ツールは使いよう次第。現在この製品で十分うまく仕事を回している人に対してまで、使うのをやめろと主張するつもりはない。限界を知った上で、ツールを使い倒すのが、プロの仕事というものだろう。
じゃあ、そういうおまえ自身は何を使っているのか? そういう質問もあるだろう。私自身は、二つの製品をほぼ毎日使っている。一つは、Primavera Project Planner(略称P3)だ。これはエンジニアリング業界では事実上の世界標準であり、海外のほとんどの顧客から、これを使え、と指定される。P3は、いわば超高級Microsoft
Projectであり、とくに1,000以上のアクティビティからなるプロジェクト計画では、ほぼこれ以外に使い物になるソフトはないと言っていい。
そのかわり、これは「プロの使う道具」である。機能が多く、スキルが必要だ。どうしても、スケジュール・コントロール専門職のツールになってしまう。おまけに、世界中で広く使われているVer.
3は英語版だ。最新のVer. 6は日本語も通るが、高くて重くて人気がない。しかも、Primavera社は先月、とうとうOracle社に買収されてしまった。この先、旧バージョンがどうなっていくかは誰にも分からない。いずれにせよ、日本国内での仕事で、かつアクティビティ数が50から100程度の工程表には、P3はおすすめではない。
ちなみに、私がもう一つ使っているのは、ソフトブレーン社の「e工程マネージャー」である。これは、かつて企画段階に私自身が参画した製品なので、私が使っているのは当然だし、ここで何か言っても宣伝にしか聞こえないだろうから、あまり詳しく述べるつもりはない。Ver.
3になってだいぶん良くなったが、改善すべき課題はまだ多いと私自身は感じている。
それにしても、どんなツールが良いのか? という問に対しては、こう答えるしかない。まず、あなた(の会社)は、それにいくら払う用意があるのか。数万円か、数百万円か? それはつまり、プロジェクト・マネジメントの向上にいくら価値を認めるのか、という問いかけである。プロジェクトの失敗で数千万の赤字を出した経験のある企業は少なくない。なのに、プロマネに数万円の工程表作成の道具代を配ればどうにかなるだろう(これだってあわせれば百万にはなるだろうが)、という楽観的なポリシーで運営されているとしたら、“グッド・ラックを”というのが唯一の回答かもしれない。それが「ツール」と言えるのかどうかは自信がないが。