プロジェクト計画を記述する方法としてほとんどのチームがガントチャートを使用していると思う。
逆にガントチャート以外の表記方法を使用しているチームを見たことが無い。
ガントチャートのサンプル
ガントチャートには計画書として致命的欠陥がある。
それは作業と作業の依存関係を記述しないということだ。
例えばシステムのA画面の基本設計と詳細設計と開発には依存関係がある。
A画面の基本設計が終わってからでなければ、A画面の詳細設計には着手できない。
A画面の詳細設計が終わってからでなければ、A画面の開発には着手できない。
システム開発の現場ではこの作業と作業の依存関係を無視した計画が必ずと言って良いほど行われる。
多くの場合、マネージャーは最初は依存関係を意識したガントチャートを書くのだが、一部作業が遅延したり逆に早く終わったりして前後関係が変わったり、予想外の割り込み作業が(発注元から)入ったり、計画の変更が相次ぐと、だんだん依存関係が分からなくなり、「詳細設計と開発の工程が重なる」といった依存関係のある作業が重なったり前後逆のガントチャートを書いてしまうものなのだ。
「マネージャーが無能だ」と言ってしまうことも出来るが、私はそれだけの問題ではないと思う。
情技師(ITエンジニア)が設計書を見なければ開発出来ないように、マネージャーは計画書やWBSを見なければマネジメントできない。
計画書であるガントチャートに依存関係が記述されていないのなら、依存関係を意識した管理は不可能だろう。
どこで依存関係を認識しろというのだろう。
現実のシステム開発プロジェクトで依存関係の重複や逆転が頻繁に起こることからもガントチャートという使用している道具に問題があるのは明白だと思う。
海外はどうか知らないが、日本のSIer業界では頑なにWBSとガントチャートの組み合わせで、計画書を記述する。
そしてその欠陥を解消しようとしたという話は聞いたことがない。
明らかに現場で問題が発生しているにも関わらずだ。
Redmine などを使用して「タスク管理」のレベルで問題解決に取り組んだという話は良く聞くが、根本的な計画の段階で実現不可能な計画を立てていたらタスク管理のレベルでは対処できないと思う。
やり方は色々あると思う、答えは一つではない。
ガントチャートは計画の一部しか表記できない
WBSとガントチャートを組み合わせている時点で、ガントチャートが計画の全てを表記できないのは明白だと思う。
ガントチャートが好まれるのは分かりやすいからだ。
ガントチャートが分かりやすいのは情報量が少ないからだ。
情報量が少ないのは必要な全ての情報を記載しないからだ。
つまりガントチャートだけでは計画の全貌は確認できないということになる。
ガントチャートは「何時なにをやるのか」と「現在の進捗」を知るためだけに必要最小限の情報を記述したレポートに過ぎない。
計画の全てが記載されているわけではない。
ガントチャートだけで計画を立てたり、計画変更するのは無謀なのだ。
依存関係を可視化できる表記法は既にある
依存関係を記載する表記法は「基本情報処理技術者試験」にも登場する「アローダイアグラム」がある。
(ちょっとしか登場しないので失念している人も多いと思う)
これは PERT（Program Evaluation and Review Technique）というプロジェクトマネジメントモデルの計画書の表記方法だ。
アローダイアグラムは「PERT図」とも呼ばれる。
PERTについての詳細な解説は以下の書籍「計画の科学」に書かれているので興味のある人は読んで見たら良いと思う。
PERTについて解説しているサイトもあるのでここでは詳しい解説はしない。
システム開発でマネージャーを務める人はPERTやアローダイアグラムの存在は知っていると思う。
知っているのに何故使わないかと言えば、いくつかのしがらみによるものだと思う。
(1)顧客や業務担当者や上司がPERT図を読めない
(2)プロジェクトメンバーがPERT図を読めない
(3)PERT図を書くのに手間と時間がかかる
(4)PERTを計画立案に採用すると時間がかかるがその時間を確保する事に、上位者の理解が得られない。
と言ったところではないだろうか。
(1)はユーザー教育すれば解決するのだが、受託開発業界では顧客と受託者の間に「お客様は神様です」という隷属関係が生じることが多いので、ユーザー教育自体が行えない事が多い。
その為、ユーザー(発注元)はいつまで経っても発注スキルが身につかないという、笑えない状況になっている所は多い。
ユーザー教育が出来るような顧客と受託者の関係を作るべきだろう。
(2)はメンバーを教育すれば済む話だが、SIer業界では「人的レバレッジ」を採用している会社が多く、情技師が必要になったら必要な人数だけ派遣のような形で人員を集め、終わったら解約するということを繰り返している。
この体制では教育するのはコストと労力の無駄なので、出来るだけ教育しないで即戦力として使える人材を浪費するようになる。
業界全体でこんなことやっているから「人材不足」になるのだが、この体制では一般の情技師が保有する知識の最大公約数の知識と技術しか使えなくなってしまう。
PERT図は使われることがほとんどない為、誰でも知っているガントチャートを使うことになるのだ。
私は業界の体制自体に問題があると思う。
どうすれば良いかをここで書くことはできないが、別の記事で書きたいと思う。
(3)は時間がかかって当たり前である。
はっきり言えばガントチャートによる計画立案は「手抜き仕事」であり、計画立案に時間をかけないのが間違いなのだ。
PERTによって計画立案を熟考することが正常だと思う。
(4)が一番問題で、顧客や業務担当者や上司などの上位者がガントチャートによる手抜き計画立案が「正しい」と思い込んでおり、PERTによって計画立案を熟考すると「怠けている」「もたもたしている」と判断してしまう。
PERTで熟考していると上位者が「何をノロノロやっているんだ!俺なんかもっと早く線表書けるぞ!」と仕事の邪魔をするのが一般的な業界の風土である。
そしてガントチャートで依存関係無視した計画を無理矢理決行し炎上を繰り返すのだ。
この国は親も教師も上司も社長も顧客も皆、「早くしろ早くしろ早くしろ早くしろ早くしろ」連呼を延々と繰り返して計画を破綻させる。
大東亜戦争のときから、この国は何も変わっていない。
PERT図は簡略化して書けば良い
PERT図にはルールが多く、厳密にPERT図を書くのは難しいが、簡略化したルールで書けばそれほどでも無い。
依存関係を記述できればそれだけで計画の精度が向上するのだから、必要最小限のルールだけ守ってPERT図を書けば良いと思う。
最小減のルールは以下の5つだけだ。
(A)アロー(PERT作業)
「ログイン画面の基本設計書作成」「テスト仕様書作成」のような「作業」をPERTでは「線分」や「矢印」で記述する。
ここではこれを「アロー」と呼称する。
アローにはその「作業の名前(ネーム)」と「所要時間(タイム)」を併記する。
<2020年07月11日修正>「ライン」という呼称を「アロー」に変更しました。
(B)イベント(PERTイベント)
作業の開始点と終了点を丸で記述する。
これを「イベント」と呼ぶ。
厳密ではないが前工程から順番に①、②、③、④のように丸の中に番号を書く。
番号は多少前後逆転しても良い。
番号はそれぞれのイベントを区別する為の識別子でしかない。
アローの前後を必ずイベントで挟んで記述する。
(C)パス
アローには必ず「所要時間(タイム)」を併記している。
これがPERTでは重要で、それぞれの枝を辿って合計所要時間を算出する。
これによって全体の所要時間と、時間に待機時間が発生する工程が発見できる。
この合計所要時間をここでは「パス」と呼称する。
<2019/4/17追記>
この説明は誤解を招きやすいので追記します。
パスとは計画の「経路」のことです。
計画は依存関係によって複数の経路が発生するのでそれぞれを区別する言葉です。
後の「書き方」の説明で例を記載してます。
この説明は誤解を招きやすいので追記します。
パスとは計画の「経路」のことです。
計画は依存関係によって複数の経路が発生するのでそれぞれを区別する言葉です。
後の「書き方」の説明で例を記載してます。
(D)クリティカルパス
パスの中で最も時間のかかるパスを「クリティカルパス」と呼ぶ。
要するに最大値である。
クリティカルパスがプロジェクトに要する時間である。
クリティカルパス上のアローが遅延するとプロジェクトが遅延する。
それ以外アローは多少遅れてもプロジェクト全体は遅れない。
全てのアローで「早くしろ早くしろ早くしろ早くしろ早くしろ」と叫ぶ必要はないわけだ。
(E)ダミー
作業Aと作業Bが両方終わらないと作業Cに取りかかれない場合に、作図上の都合で作業Aと作業Bの終端イベントを一つにできない場合がある。
この時、依存関係を所要時間ゼロのアローで結んで表記する。
このアローの事を「ダミー」と呼ぶ。
書き方
PERT図は基本的に左から右に向かってイベントとアローを書き込んでいく。
(上から下でも良い)
アローには必ずネームとタイムを併記する。
アローはイベントを挟んで依存関係を表す。
依存関係のないアローは並行して書く。
左が前工程で右が後工程だ。
並行する作業は縦に枝分かれする。
左から右に向かって成長する木のように。
枝は増えるだけでなく繋がって収束し減る場合もある。
上図では「詳細設計02は、基本設計02と詳細設計01が完了していなければ着手できない」という依存関係を表している。
基本設計01と基本設計02は依存関係が無く、同時並行で進められる。
基本設計02と詳細設計02の依存関係は「ダミー」で結んでいる。
後で改めて説明するが上図の場合、
(1)→(2)→(4)→(5)と、
(1)→(3)→(4)→(5)の2つの「パス」がある。
それぞれの所要時間の合計は、
(1)→(2)→(4)→(5)が、24+48+48=120h
(1)→(3)→(4)→(5)が、16+0+48=64h
なので最大値の120hの(1)→(2)→(4)→(5)が、クリティカルパスである。
ちなみにこれをガントチャートにすると以下のようになる。
以下にシステム開発のPERT図のサンプルを提示する。
PERT図サンプル(1755×1241px):小さくて見えない場合は画像保存して見てください
上記のサンプルでは以下の依存関係がある。
基本設計が完了しなければ詳細設計に着手できない。
詳細設計が完了しなければ開発に着手できない。
開発が完了しなければ結合テストに着手できない。
(単体テストは開発に含まれる)
結合テストが完了しなければ業務テストに着手できない。
「01」モジュールは前工程の「03」と「05」が終わらなければ着手できない。
(最初の基本設計は例外)
「02」と「03」は「01」が完了しなければ着手できない。
「05」は「04」が完了しなければ着手できない。
無理に小さく書いたので入り組んで見えるが、実際はもっと横に広げて書けば良いので、もっとすっきりと書ける。
これは左から右へ流れるように書いているが、上から下へ流れるように書いても良い。
クリティカルパス
パスを並べて合計タイムを比較してみよう。
<パス1>
基本設計01(16h)→基本設計02(8h)→詳細設計02(16h)→開発02(24h)→結合テスト02(16h)→業務テスト(24h)
16+8+16+24+16+24=104h
<パス2>
基本設計01(16h)→基本設計03(12h)→詳細設計01(16h)→詳細設計03(16h)→開発01(48h)→開発03(24h)→結合テスト03(16h)→業務テスト(24h)
16+12+16+16+48+24+16+24=172h
<パス3>
基本設計04(24h)→詳細設計04(16h)→開発04(16h)→結合テスト04(16h)→業務テスト(24h)
24+16+16+16+24=96h
<パス4>
基本設計04(24h)→基本設計05(16h)→詳細設計01(16h)→詳細設計03(16h)→開発01(48h)→開発03(24h)→結合テスト03(16h)→業務テスト(24h)
24+16+16+16+48+24+16+24=184h
<パス5>
基本設計04(24h)→基本設計05(16h)→詳細設計05(16h)→開発05(16h)→結合テスト05(16h)→業務テスト(24h)
24+16+16+16+16+24=112h
<パス6>
基本設計04(24h)→基本設計05(16h)→詳細設計01(16h)→詳細設計03(16h)→開発05(16h)→結合テスト05(16h)→業務テスト(24h)
24+16+16+16+16+16+24=128h
実際はダミーのパスも列挙しなければならないし、他にもパスはあるのだが、説明が長くなるので省略する。
パスの中で最も時間がかかる(最大値)のは184hの「パス4」である。
これがクリティカルパスであり、プロジェクトの総所要時間である。
他のパスには待機時間が生じる。
「パス4」は遅れてはならないパスである。
ここが遅れるとプロジェクトが遅れ納期延長(リスケ)が必要となる。
簡略化したPERT図を書くのはそれほど難しくないと思う。
専用のツールもあるようだが、顧客・上司・社長・メンバー全員が閲覧できるファイル形式である必要があるので、取りあえずExcelのオートシェイプで書いてみてはどうだろう。
パワポはお勧めしない。
横幅に制限があるので計画書向きでは無い。
簡略化PERTは難しくない
PERTは難しくない。
PERT図を書くだけならガントチャートと難易度は変わらない。
依存関係を視覚化できるのでガントチャートよりマネジメントが容易になる。
面倒なのはクリティカルパスだが、パスをリスト構造で表に登録して自動でクリティカルパスを求めるプログラムでも組めば即答である。
専用ツールもいくつかあるが、簡略化したPERT図はExcelで容易に書ける上に、Excelファイルなら客先でもどこでも閲覧できるので専用ツールの必然性を私は感じない。
PERT図はもっと複雑なルールや使い方があるのだが、最初から使いこなせるわけはないし、関係者全員がPERTを完全に使いこなすのはほぼ無理だと思う。
だから簡略化PERT図をExcelで扱うのが良いと思う。
ガントチャートは進捗が見やすいが、それしかメリットが無い。
ただ、現在はガントチャートはプロジェクト管理ツールで自動作成されるのでツールがあるならガントチャートの方が作りやすい。
依存関係を管理できるプロジェクト管理ツールも当然あるだろう。
PERT図対応のツールは多くない。
そこが難点である。
依存関係を視覚化して管理できるだけでもメリットがあるので、PERTをお勧めしておく。
