新規投稿者 高津徹太郎
投稿日 6/2(月) 20:06:09
返信も含め全削除
３．現状工程計画の問題点
前２回の講座で現状の工程計画作成手順を確認したが、このような工程計画の立て方で工程管理が機能し管理効果が生まれたであろうか。結論から言えば“否”であろう。
現状では管理サイクルが回っていないが管理をしていると勘違いしている。勘違いしている要因は次の二つに分けることができる。一つはラフプランをブレークダウンするという工程表の“作成上の問題”であり、もう一つは計画と実績の比較を管理とする“解釈上の問題”である。
（１）計画作成上の問題
①実績データを再利用する仕組みになっていない
現実的な視点でラフプランから書き始める理由を探ると、作成者の記憶を呼び起こすための手続きなのである。個人が頭脳に記憶していることは断片的にしか思い起こせないためこの手続きが必要なのである。このような不確実なデータではとうてい“管理サイクルを回している”状態とは言えず、工期やクリチカルパスの計算、工期短縮や山積・山崩など科学的な検討ができない。真の管理には現状のままを活字で記録したデータが不可欠である。
②ネットワーク工程表上の問題
ネットワーク工程表の基になるＰＥＲＴはバーチャートを改良し“コンピュータ処理”を前提にして開発したものである。ラフプランをブレークダウンする方式を技術的に評価すると“バーチャート工程表”の欠点がそのまま残っていることが分かる。バーチャート工程表の欠点とは順序関係が不明なためある作業の遅れや進みが他の作業や全体工期にどの様に影響するかが分からないことにある。現状のラフプランはバーチャートを更に大まかに表現したものであるため曖昧さが増幅される仕組みである。例えラフプランをネットワーク形式で表現したとしても計画データを“記憶”に頼っていては科学的処理ができず管理にはならない。なお、ラフプランをネットワーク工程表で表現すると別な問題発生のおそれがあるがこれは改めて述べることにしよう。
③ＰＥＲＴ機能を生かすラフプランの利用
ラフプランをブレークダウンして作る計画でもネットワーク工程表の特徴を生かせる方法がある。それは着工前に全工程を実施工程表（週間工程表）のレベルまでブレークダウンすれば良いのである。こうすると各作業に投入資源数や所要時間が設定できるため全体工期、クリチカルパス、山積・山崩、工期短縮などを科学的に検討できるようになる。
しかし現状ではこれを行わないのである。その理由を尋ねると着工時は業務が重なるため忙しくて書けないと言う。しかし “詳細工程を覚えていないので時間を掛けても書けない” ことが本音であろう。繰返しになるが上記のようにＰＥＲＴ機能が生きた計画が作れても、実績データを次の計画に使うという管理サイクルを回さなければ真の管理にならないことは申すまでもない。
（２）解釈上の問題
工事現場で行う“管理”とは、管理工学上の管理であり、工事を施工する上において起こる問題を主に数理的な手法を用いて行うことをいう。
しかし、これを曖昧に捉え、“計画と実績のチェック”を“管理”と誤解している人が多い。管理でも種々のチェックを行うがチェックだけで管理が達成される訳ではない。計画工程表と実績工程との比較が必要なのは中間前払いのための出来高チェックや工期内工期のチェックなどの場合である。これらは管理とは言わず「監視」や「監理」という表現が似合うであろう。
（３）管理サイクルのポイント
管理サイクルで重要な行程はActionである。ActionはCheck（検査）を行った際に見つけたミスに対する行動である。Actionは、①当該ミスの是正。②ミスの再発防止処置。③ミス情報を次のPlanに伝える。という三つの行為に分かれる。Actionの中でも管理サイクルに重要なのは②と③である。②は検討時間等を考えると大掛かりになるであろう。③は検討が不要で費用が掛からない。もし③のみを実施した場合でも（計画時や実施時にミス情報が分かっているから）ミスが再発しにくい計画が作れ、また、施工でもミスが再発しにくくなって管理行為が生きてくる。
|