ダイレクト・ガントチャート方式の問題点 〜 やはりExcelで工程表を書いてはいけない (1)

このほど、自分で「マイ・ベスト・セレクション」なる本を編んでみた。過去17年間に書いてサイトに公開した数百の記事の中から、自分が気に入っているベスト12を選んで、ePub形式の電子書籍をつくってみたのだ。まあ書籍といっても、素人のつくった手製(手編み?)の本で、いってみればβバージョンではある。ベスト・セレクションの中には、アクセス数の多かった記事も入れたが、目立たないけど愛着のある記事も選んだ。多少は文章に手を入れたつつも、なるべく発表当時のスタイルを残している。

ところで、わたしのサイトには、アクセス数で言うとダントツ1位の記事がある。「Excelで工程表を書いてはいけない」(http://brevis.exblog.jp/9052344/)という、2008年11月24日の記事だ。もう9年前の記事だが、いまだに毎週のBlog記事ランキングのトップに位置し続けている。

そして、実を言うと、これほど評判のわるい記事もない。それは、コメント欄を見ていただければ分かる。当サイトのコメント欄は、明らかに広告宣伝と分かるもの以外は原則、消さないことにしている。コメントの8割以上が、まあ、ぼろくそな批判である。

批判の主旨は、「お前はExcelを批判しているが、かわりの提案をしていない」というものが多い。たしかにその通りで、これは批判者の方が正しい。「Excelのかわりにこのツールを使えば大丈夫だよ」というソリューションを書いていないから、記事の前半で提起した問題意識が、後半で腰砕けになっている、という風に読める。かわりにわたしは、「自分で考えましょう」みたいな書き方をしているからだ。

しかし、そんなに程度の低い記事だったら、なぜあっという間に忘れられてしまわなかったのか。なぜいまだに、毎日かなりの数の閲覧があるのか。そして、なぜ皆、Excelのかわりを求めて読みに来て、回答が書かれていない、と怒って帰って行くのか? −−もちろん、Excelで描く工程表が、やはり不便だからだ。

では、わたし自身は、実際の仕事では何を使っているか。

わたしは現在、経営企画部門におり、プロジェクトのライン部門は5年前に離れている。ライン部門にいた時は、じつはPrimavera Project Planner(略称P6)をつかっていた。Primavera P6は、いわゆる大規模なエンジニアリング系プロジェクトでは、ほとんど国際的な標準ツールになっている。

今でもわたしは、ちょっと込み入ったプロジェクトのスケジュールを考えるときは、Primaveraを使いたくなる。それだけ便利だからだ。

ただし、これはプロのツールである。

プロとは、"Project Control Manager”とか"Schedule Engineer"とか呼ばれる職種・ポジションの人達を指す。そもそもこういう職種自体、多くの業種には馴染みがないと思う。大規模プロジェクトをつねに遂行している組織でなければ、こういう専門職種は必要ないからだ。ちなみにプロジェクト・マネジメントはゼネラリストの仕事だと思っている人が多いが、じつは、スケジュール、コスト、品質、ドキュメントなどの要素別に専門分化している、プロマネのためのスタッフ職種があるのだ。米国PMIには資格試験まである。

それはともかく、Primaveraというソフトウェアは、きちんとトレーニングを受けなければ、使えないし、使っても意味がない(出力の意味が読み取れない)。値段は1本約30万円。まあ、プロの道具としては安いとわたしは思う。

参考までに、Primaveraの画面の一つ(典型的なガントチャート表示と、各Activityの属性を示すサブペイン)のスナップショットをつけておく。Primaveraでは、Activityには自由にカテゴリーと属性を定義でき、その順にソートしたりフィルタリングしたりできるようになっている。もちろん、リソース負荷山積みによるヒストグラム表示なども、よく用いる。
e0058447_09063235.png
では、それほど大きくない、もっと日常的なプロジェクトを組む場合、わたしは何を使うか? −−じつは、Excelで工程表を書くことが多い。

なんだBlog記事の主張と矛盾してるじゃないか! とお怒りの読者もいるかもしれない。いや、だが元の記事を、よく読んでほしい。別にわたしは、ガントチャートを画くのにExcelを使うこと自体がわるい、といっているわけではない。「Excelで工程管理してはいけない」と書いているのだ。

『工程管理する』とはどういう意味か。それはもちろん、工程(日程とかスケジュールと読み替えても良いが)の計画とコントロールである。

  • プロジェクトのスタートにあたり、工程表(ガントチャート)を作成し、定期的にアップデートすること
  • 進捗上の問題を検知し、対策を立てて問題解決をすること
  • それによって、プロジェクトの最終納期を目標通り収まるようコントロールすること、そして
  • 社内・社外の関係者に、先々の予定を立て準備できるようにすること

これが工程管理だ。そして、こういうひとまとまりの仕事を、Excelの絵1枚だけで済まそうとすると、相当に苦労するよ、と申し上げているのである。

2008年に書いた問題のサイト記事では、Excel工程管理について、とくに実行段階に入ってからのトラッキングとアップデートが大変だと書いた。しかし、もう一つの問題があることに、最近気がついた。それが、「ダイレクト・ガントチャート方式」である。

3ヶ月ほど前のことになるが、研究会仲間のY氏からメールをもらった。Y氏は、問題プロジェクトの火消しのために、海外に駐在されているところだった。この時期、わたしは「プロジェクト&プログラム・アナリシス研究部会」の仲間とともに、新しいPM教育のプログラムを作成していた。それに際して、Y氏がコメントを送ってくれたのである。

わたしたちのつくった研修カリキュラムでは、最初にプロジェクトのWBS構成と、アクティビティを表すカード数十枚を、受講者に配る。受講者はグループを組んで、各アクティビティのインプットとアウトプットを見ながら、アクティビティ間の順序関係(ロジック)を理解する。そして、アクティビティ・カードを模造紙の上に並べて、ロジック・ネットワークを作成する。ここは手作業で、ワイワイ言いながら、結構時間のかかる部分だ。その上で、PERT/CPMの計算をして、余裕日数(フロート)=0となるクリティカル・パスを見つけ、納期を予測する、という段取りになっている。

コンピュータソフトを使わず、あえて紙の手作業、それもグループ単位の演習にしたのは、言葉にして話し合う方が、より頭に残りやすいからである。

そしてこの演習では、プロジェクト計画立案の本来のプロセス(の一部)を、順を追って理解してもらうことに主眼がある。本来のプロセスとは、

(1) スコープ定義
(2) WBSの作成
(3) Activityリスト(WBS辞書)作成 →アウトプット(成果物)とインプットの定義
(4) ロジック・ネットワーク作成
(5) クリティカル・パス法(PERT/CPM)計算
(6) スケジュールの決定
(7) コスト見積

という流れである。このプロセスをきちんとやるのは面倒で、時間がかかるが、計画の精度が高まり、うっかりした見落としがなくなる。

ところで、Y氏はメールの中で、しばしば現実には「ダイレクト・ガントチャート方式」が行われている、と指摘された。ダイレクト・ガントチャート方式とは、プロマネがプロジェクト計画をつくる際に、WBSやアクティビティ・ネットワークを作成せず、いきなりスケジュール・ガントチャートを描き始めるやり方である。

「プロマネのハンドリングでさばける範囲であれば、Activity Networkを作成するより、ダイレクトにガントチャートを作成する方が負担にならない」とY氏は指摘する。しかし、「その範疇を超えた、(より規模の大きな)プロジェクトに対して、Activity Networkとクリティカルパスの概念を理解していないプロマネが、ガントチャートでマネジメントしようとすると、失敗プロジェクトに陥る。」−−これがY氏の経験から見た観察であった。

ちなみにY氏は、「ソフトウェア業界ではActivity Networkを作っていないケースが非常に多い」とも書いている。これは、そうだろうと感じた。いや、わたしの見るところでは、その前にそもそも、「WBS」とか「Activity」という概念のレベルで、誤解や混乱があるのである。

(この項続く)


by Tomoichi_Sato | 2017-12-02 15:05 | プロジェクト・マネジメント | Comments(0)
<< プロジェクト計画のロジックとは... メーリングリストの登録受付を開... >>