プロジェクトマネージャーによるスケジュール管理や管理された現場担当者が実施するタスク管理にとってもっとも混乱をきたすもの。それは

　スケジュール変更

です。

原則として、”情報”に対して行える基本アクションと言うものはデータベースアクセスなどに代表されるように、参照を除けば

　・追加
　・変更(更新)
　・削除

の３種しかありません。

当然、スケジュールと言うものも言い換えれば”日程管理情報”であって、日頃の仕事を進めるにあたってみなさんの頭の中にあるこれらのスケジュールは、参照を除けば追加、変更、削除しかされないものとなっているのではないでしょうか。

たとえば５日間のとあるタスクを進めている際に他の作業が１日割り込まれたり、逆にその分の歪みを解消するために既存の５日作業から１日分を切り出して他人に振ったりなんてことを毎度実施すればするほど混乱してはいかないでしょうか。

データベースアクセスでいえば

　統計情報が乱れて、
　インデックスの再構築を実施しないと性能が出なくなる

ような現象と同じです。
当然、そうなれば本来のパフォーマンスは出せません。

よって、スケジュールの遵守を中心としたタスク管理においては、一度計画を綿密に立ててしまえば極力変更しないようにすることが肝要です。

スケジュールが大幅に乱れるときというのは、期日・期限を順守することが難しくなるだけでなく、決まってコストや品質にも影響を与えるようになっています（逆もまた然りです）。

プロジェクト活動というものは原則として…いえビジネスというものは原則として「有期性」が備わっていますので、仮にコストや品質などほかの要素の優先度がどんなに高かったとしても、それがスケジュールを守らなくていい理由にはなりません。

優先度の高低にかかわらず、スケジュールの順守は必達事項なのです。

プロジェクトにおいて各タスクというのは

　deliverable

な構成要素となっています。すべてのタスクを部品と見立てたとき、それらの部品を１つ残らず組み立てると製品…つまりはプロジェクトの完成を見ることになります。ゆえに過去構成要素である部品の組み立てには順序性というものが出てきます。

当然ながらタスクの優先度付けは「期日が差し迫っている順」です。

お客さまが指摘したとしても、バグが出たとしても、実はそういった事象はタスク優先度の前後に大きく関係しません。スケジュールの遵守に影響が出る場合を除けば、期日が差し迫っている順以外に優先していいものはありません。

少なくともクリティカルパスに影響を与える場合には、いかなるタスクも割り込ませることは推奨しません。割り込ませないようにうまく誘導することが一番です。

どうしても計画にないタスクを割り込ませる必要がある場合は、クリティカルパスに影響がないタイミングまで調整する必要があります。それほどまでにクリティカルパスというのはプロジェクト全体の成否を揺るがしかねない重要な要素となっています。

ＱＣＤ（品質・コスト・期限）のなかで「Ｄ（delivery：期日）」を遵守するためにはクリティカルパスを乱さないことは絶対にはずせない条件となります。逆にクリティカルパスに影響が出なければ、たいていのスケジュール調整が可能となります。

たとえば、テスト作業を進めている際にある不具合が生じたとしましょう。

その際、判断アルゴリズムはこうでなければなりません。

if（その不良を解決しなければ、他の作業まで進まない場合）{
　　スケジュールに割込みを入れ、不良対応を優先する;
　　優先順位が変わることで影響を受けるタスクを整理する;
　　スケジュール自体の再調整を行う;
　　お客さまを含む関係者全員に、理由を添えて変更内容および影響内容を周知する;

} else {
　　当該テスト項目を飛ばし、次のテストを進める;
　　すべてのテストがいったん終了したら、不良個所を最後に対策＋再テストを実施する;

}

スケジュールを管理する場合はそのスケジュールをできるだけ実現し、周囲に不安や心配などをさせないよう

　1. 優先度付けのルール決め
　2. 変更条件の基準決め

が非常に重要な役割を持ちます。

これらが無いままなんとなくスケジュール管理をしていると、マネージャーの管理負担も、開発担当者の作業負担も、指数関数的に増大することでしょう。