以前のコラムでIT化プロジェクトの日程の理解が甘いと事故に繋がる可能性が高いことをお伝え致しました。今回は、その実務について詳しく解説させていただきます。
ソフトウェアの開発が含まれるような複雑なプロジェクトの日程を立てる為には、日程計画（ガントチャートなどとも呼びます）がそもそもどうやって作られるべきものなのかを理解する必要があります。
解説をシンプルなものにするため、ここでは家の庭にブロック塀を建てる、というプロジェクトを例にしてみます。
これは比較的簡単なプロジェクトなので、図１の様に表にいきなり日程を記述していく書き方でも問題ありません。

【図１】

ところが、図１を良く見ると、各仕事（タスクと呼びます）の間に矢印の線が引かれています。これは、
理論的に先に終了させておかないと次を開始できないタスク
を意味します。これを先行タスクと呼びます。
さて、ブロック塀はご存じの通り、地面に土木工事で溝を掘り、そこに鉄筋を立ててコンクリートを流す基礎工事を行い、そこにブロックを積み上げていきます。
ということは、基礎工事が終わる前にブロックを積み始めることは理論的にできません。
そのような関係をガントチャート上に表すのは、紙面が複雑になってしまうので、ガントチャートを書く前に図２に示すスケジュールネットワーク図（PERT図とも呼ぶ）を書くことが効率的で漏れの発生を防ぐコツです。

【図２】
図２を見れば、資材を発注し、現品が到着したら工事を始める・・・という前後の順番関係が一目瞭然です。
仮に、ブロック納品の前にブロック積工事をスタートする日程になっていたら、これは段取りとしては全くダメな計画と言えます。
この様にシンプルなプロジェクトなのであれば、常識外れのおかしな日程が立案されることは少ない（というか皆無になる）はずですが、IT系の日程にはその論理的な矛盾が多く含まれているケースがあることに注意を払う必要があります。
よくあるご相談では、「要件を定義する期間が終わり、その後ITベンダーさんが開発作業をしていたのですが、唐突に”完成しました”と言ってきました。当社側のメンバーは何も確認していないのに完成と言われても困ります。」といった導入者側の困惑の声です。
この場合、ITベンダーさんが立てるべきスケジュールネットワークは
開発作業の先行タスクは、御客様との要件レビュー
であるべきですし、
完成の先行タスクは、開発レビュー
であるべきです。
きちんと緻密な日程計画を立案してくれるITベンダーさんが大半ではありますが、中には思いつきで日程を引いてしまうプロジェクトマネージャーさんもいらっしゃることは残念なことです。
このように、複雑な日程表を提示された際に漫然と眺めるだけで終わるのは非常に危険なことです。複雑すぎてポイントが良くわからないようであれば、
スケジュールネットワーク図（PERT図）を要求する
自社が、決定・作業などをしなければならないタスクを日程に明示してもらう
の二点を依頼するのが良いでしょう。
少し面倒なので、この部分の確認を省略してしまう購入者側責任者も見受けられますが、プロジェクトの失敗を未然に防ぐ為には絶対に必要な行動です。
技能と慣れが必要なプロセスとなりますが、是非習得され、プロジェクトの失敗を防ぐ行動をして頂ければと思います。