遅延は挽回できるのか
下書きを練っていたら
プロジェクトはなぜ失敗するのか：第11回 実績工数がない進ちょく報告はまず疑え - ITmedia キャリア
がちょうどいいタイミングで上がってきた。
この記事ではEVMという手法に1つの解を求めているわけだが。
さて、タイトルに戻る。
遅延は挽回できるのか。
極論すれば
- できない
に尽きる。
あまりにも、極端なので、条件をつけてみる。
- 何か手を打てば、遅延を挽回して期限を守ることができる。
- 「遅れが出てきたが、がんばって挽回します」は、かなりの確率で挽回できない。
これらについて、掘り下げてみる。
進捗の遅延が発生してしまったとき、どんな手段が取りうるか。
とりうる手段はこんなものだろう。1．もともと用意していたバッファを消化
2．残業／徹夜／休日出勤
3．他のタスクを短縮
4．追加人員の投入
1．もともと用意していたバッファを消化
プロジェクトマネジメントの教科書どおりの対応です。ただし、以下の点に気をつけなければらないです。
- リスクバッファの必要性を認めてもらえず短納期、低コスト開発を迫られることがある（多い）
- リスクバッファを作業ごとに積み上げると必要以上に大きくなるため、大きなタスクのまとまりにバッファを継ぎ足すなど、スケジュールマネジメントのスキルが問われる
- クリティカルパス上のタスクの遅延に対してバッファを行使するときは、周辺タスクへの影響度も大きい。
このレベルの手段で改善されるうちは、まだまだ青信号と言ってもよいでしょう。
2．残業／徹夜／休日出勤
時間をお金で買う行為（手当てや割り増しを払わないのは現行法上では違法になるでしょう）で、悲しいかな、最も有効な手段だと思います。
これらにより、当初の期限を維持できる可能性は高いです。
逆に言うと、
- 最初からこれらをスケジュールに組み込むのは、プロジェクトマネジメントにおける自殺行為。
- これらの手段は、遅延時間がその合計時間を超えた時点で赤信号である。（実際には能率の問題があるので、合計より小さい）
ということでもある。
この手段を行使する必要がある場合、黄色信号が灯っているんだということを強く意識することが必要です。
「休日挽回すりゃいいでしょ」という発想は、最初から予定に入れているのと同じなので、みずからチキンレースをやっているようなものです。
3．他のタスクを短縮
3番目に置いたが、禁断の手段と考えたほうがよい。が、やってしまうシーンを見かけることも多い。なぜダメか。
そりゃ「必要だから、それだけの期間と人員を、その（短縮されようとしている）タスクに割り当てたんでしょ？（本当はいらなかったの？）」
という視点がスッポリ抜けていることがほとんどだから。
プロジェクト・スコープの調整や、諸般の事情などから、
「やらなければいけないこと」自体が当初予定よりも減っている場合には、有効な手段となる。
が、本来やるべき仕事量はそのままに、他のタスクを短縮するのは、
無いはずのものをあるかのように偽装しているに過ぎないのだ。
*1
偽装はいずれ顕在化する。取り返しが付かないほど大きな化け物に成長してから、姿を現す。
4．追加人員の投入
古くから言われているように、「人を追加すれば、工期が短縮できる」というのは間違いであることが多い。人員投入には、知識、状況の共有の為の負荷が既存メンバーにのしかかるなど、多くの副作用を持つ。
これが効果を発揮するのは、以下のケースでしょう。
- クリティカルパス外のタスクを実施中の要員を一時的に振り向けて、少ない負荷で遅延タスクのスピードを加速させ、あとでその借りを返す方策が立てられる
- ナレッジトランスファーの必要性の小さいタスクが転がっている
- その人員投入は、作業者の投入ではなく、マネジメント力の強化である
2番目については、多くのデスマでは使えないことが多い。
そんなきれいにタスクが切り出せるくらいに管理が出来ているなら、デスマにならないからだ。
要件定義書や設計書がない、記述が甘い、更新されていない、などだ。
思い切って、まったく手をつけていない領域がある場合（やる気を疑われるが）については、まだ救いがあるか。
もともと何も無いのだから、ナレッジトランスファーコストがかからない。
正攻法で埋めるだけ。
3番目については、これが意外と根本療法として効果を発揮することが多い。
が、実現できないことも多い。
プロジェクトマネージャよりも上の階層の介入による強権発動でもない限り、
火をつけるのもプロジェクトマネージャ、鎮火するのプロジェクトマネージャ、ってケースが多いから。
自分で消せないマッチポンプ、もしくは、子供の火遊び。
「がんばって挽回します」が挽回できない理由
進捗が80％でとまっているケース、なんてのがよく例に挙げられる。これはいったいどういう事象かというと、
- 別のタスクが割り込んできて、最後の詰めが出来ない。
- 手をつけ始めたはいいが、細かいところでFixできない問題が発生している*2
- 仕事を抱え込んでいる
といったところでしょう。
マネジメントが手を差し伸べることで、改善できる余地が十分にあります。
が、往々にして「ぢゃ、がんばれ」で終わってしまう。
文化的背景として
- マネジメントの怠慢。
- 責任感によるオーナーシップと自己完結の意味のはき違え。
責任を果たすにも色々あるが、
「誰の手を借りてもいいが、受け持ったタスクをゴールまで持っていく」のがオーナーシップ。
誰の手も借りずに１人でやり遂げろ、というのは、マネージャとしてもメンバーとしても間違ったスタンス。
完成品を期待している人（多くは発注者）にとって、自己完結性なんてのはどうでもいい。
期待したものが期待した時期に出来上がってくればいいのだ。
ここの認識がズレている文化においては、「がんばります」は死亡フラグみたいなものだ。
１週間たっても２週間たっても何も変わらないだろう。
まとめ
遅延は、その対策が具体的な手段に結び付けられていない限り、挽回されない。遅延の解消に有効な手段は限られている。
スケジュールや人員構成の組みなおしは、相応のコストがかかる。（クラッシングコストという）
それでだめなら、目標自体を下げるしかない。その選択肢を「ないもの」としてはいけない。
これらの判断、時期を誤ったとき、デスマーチの予兆は本物に進化する。
こうしたことが、発注者、受注者の意思決定権限者の間で共有されていないければ、
デスマの破壊力は飛躍的に大きくなる。
IT業界において、「泥」と聞いて、中の人が反応するのは、「泥そのものの汚れ感」なのだと想うが、
その背景にあるのは、「泥縄」的仕事のなのでは無いだろうか。
管理能力を磨かないままPMなんて肩書きつけられた人のしたで、
わかりきったようなリスクを爆発させて、その対策を後から後からやっつける、
そんな経験をしている人が多いのではないかと考察する。
IT業界では、
求人募集ではマネージャーがもてはやされつつ、
求職者にとってマネージャーがもてはやされない、
皮肉な現状。
どげんかせんといかん。
