検索
プロジェクトの停滞・遅延を招く「変動性」「従属性」
連載第15回で紹介したC社の場合、自社内に大工等は在籍しておらず、全て外注専門業者を利用します。電気工事、設備工事、屋根工事等、全ての工事はその専門の外注会社に発注し、これを取りまとめ、計画し、工事の進捗を管理するのがC社の仕事です。
全工程のタスクを社内で実施できる場合（そんな場合はないですが）には、社内の個々のタスクの担当者が頻繁に顔を合わせることができ、工事案件に対してリスクを検討する機会は比較的設けやすいですが、全てのタスクを外注専門業者へ発注するC社のような会社の場合、それはままなりません。
実際、各タスクを専門業者へ外注する場合、各タスクの工事期間と金額を確認するのみで、「変動性」と「従属性」からくる工事のリスク（作業が停滞・遅延するリスク）については全く話し合いの場が持たれていませんでした。実際に工事が始まってみないとリスクの把握はできないという状況だったのです。
このような状況のままでは、個々のタスクについてどのような問題が工事開始後に生じるのか見当もつかないままです。
「変動性」と「従属性」に対して何も手を打たなければ、工事が遅れることは当たり前です。建設工事が遅れないように、工事を管理する側からできることは、「変動性」と「従属性」をしっかりコントロールすることです。
工程タスクの遅れを後から取り戻すのは至難の技
そうは言うものの、実は、変動性のコントロールは極めて困難です。実施したことがないタスクが大半である場合、どれだけの時間がかかるのかを見積もるのは不可能だからです。
ですから、変動性に対するコントロールは、個々のタスクに遅れが生じても全体の納期遅れが生じないように「プロジェクト・バッファー」と呼ばれるバッファーで事後的に管理することになります。これは、個々のタスクに含まれるバッファーをそぎ落とす代わりに、プロジェクトの後ろに設定するバッファーをいいます。
各種の専門工事をロスなく繋いで全体の工事を管理するのがC社の仕事ですから、「従属性」の管理はとても重要です。前工程のタスクが終わったらすぐに次の工程へ引き継ぐ、タスクを受け継いだ後工程はすぐにタスクを開始する、並行して進めることができるタスクについては並行作業を積極的に採用する……などです。
ある工程のタスクに遅れが生じると、その遅れを後工程で取り戻すことは理論的にも至難の業です。ですから、建設工事の前工程だから多少遅れても後工程が取り戻してくれるだろうという呑気な考えでは必ず工事は遅れます。
