流れを考える。

(1)作業を一人頭どーのこーのとして管理する
　↓
(2)各人に作業が発生する
　↓
(3)各人がそれぞれの作業を遂行しようと配置につく
　↓
(4)誰かが作業につまるイベント発生
　↓
(5)他の誰かが助けると、助けた人の進捗に遅れが生じる。
　↓
(6)助けた人がんばる。
　↓
(7)ちょとだけリカバリできる。
　↓
(8)誰かが作業につまるイベント発生
　↓
(9)助けた人的に無視したい気持ちに駆られるが、そーすると詰まったやつの作業が進まない。
　↓
(10)全体進捗を思い、自分のならばなんとかできるやと思い、助ける。
　↓
(11)助けた人の進捗に遅れが生じる。
　↓
(12)助けた人がんばる。
　↓
(13)くりかえしていると限界点が見えてくる。
　↓
(14)助けた人の仕事分割して楽にしよう作戦を管理者が発案
　↓
(15)項目単位での割り振りしか考えられてないため、分割むり。
　↓
(16)ってか、割り振ったらまた進捗の遅れ要因になるので分割を避ける。
　↓
(17)「そいつにしか出来ないこと」と公認される
　↓
(18)でもスケジュール変わらない
　↓
(19)がんばらねばねば。
　↓　　　　　　　　↓
(20)がんばり成功　がんばり失敗

管理は「各個人」として行いたいのだが、
現実は「だれかに頼って各個人の作業がすすむ」ということから離れられない。
この陥りやすい状態に陥ったとき、
管理方法をそのまま適用しつづけることは、プロジェクト失敗への道をひた走ることになる。
なぜならば、管理とはリスクの早期発見早期解決のための情報収集が目的であるのだが、
この場合、管理方法がリスク増加の要因となっているからである。

だれかが助けれる仕事ってのは技術的には易しい部類のことが多い。
単に「今」知らないからとかできないから詰まるのであって、
知っているものからすれば詰まる要因でもなんでもない。
ので。
詰まってとまって誰かの時間を割いて解決への道を歩むよりは、
誰かと一緒に詰まりながら解決しながらやるほうが問題解決までの時間は短くてすむ。
それに気が楽だ。

ってーのが普及するといいな。
世の中に気配と流れはあれども、
現場に行き渡るまでにはまだまだ時間がかかりそうだ。ヽ(´ー`)ノ
とりあえず。目の前の仕事仕事。