予定していた作業を確実に終わらせる予定のレシピ

プロジェクトマネージャやSEリーダ役の悩みの１つは予定完了日にワークパッケージが完了しないという進捗遅れでしょう。有期限性の特性を持つプロジェクトだからこそ、完了する日に完了しないとスケジュールが遅延してしまい、ドミノ倒しのようにプロジェクトの納期に影響してしまうのだから。

進捗把握の仕方を疑え

いつも、毎回、どのプロジェクトでも予定した作業が遅延してしまうなら、まずは、進捗把握の仕方を疑いましょう。

疑うその前に、作業のプロセスをおさらいします。

予定を作る、作業をする、実績を把握する

まずはこれは正しい姿です。ところが実績把握をして予定どおりに完了していなければこの作業プロセスが変わってしまいます。

予定を作る、作業をする、実績を把握する
遅延の対策を立てる、遅延の対策を実施する、対策の実績を把握する

予定どおり終わらなければ、次に予定していた作業とは別に、終わっていない作業が完了して始末するまでアドオンで乗ってきます。

こうなってしまうのは進捗の把握の仕方に問題があるからです。進捗がトラブるプロジェクトは、得てして進捗を把握したいメッシュと進捗の実績のメッシュの単位がずれているのです。

ちょっと、今ジョインしているプロジェクトの進捗把握の単位が何かを思い出してみましょう。日単位か週単位か。もちろん、プロジェクトチームの中で、で。

日単位であれば、毎日の作業を把握する仕組みがプロジェクトチームの中の作業プロセスとして実装されているはずです。

週単位であれば、週の作業を把握する仕組みが（以下略。

実績の把握の単位を持ち出してきたのは、進捗実績を把握するサイクルは、実は遅れが把握できてたときには、その遅れを取り戻すにはその3倍以上のリソースが必要となることを肝に命じておく必要があるよ、ということを言いたいためです。

図にするとこんな感じ。

凡例　△＝作業予定　▲＝作業実績　□＝予定完了日　■＝実績完了日

①予定　△△△△□
　実績　▲▲▲▲▲　←5稼働日で終わらない

②予定　△△△△□
　予定　　　　　　　△△△△□　←当初予定していた計画。
　　　　　　　　　　　　　　　　　下をやるので手がつかない
　実績　▲▲▲▲▲　▲▲▲▲■　←10稼働日で終わる

③予定　△△△△□
　予定　　　　　　　△△△△□　→　△△△△□　←　翌週にスリップ
　予定　　　　　　　　　　　　　　△△△△□　←当初予定していた作業
　実績　▲▲▲▲▲　▲▲▲▲■　←10稼働日で終わる

これを可視化して把握していないから、②で終わらせますという裏付けもないメンバのコミットを真に受けたり、②で終わらせて欲しいとメンバに無理強いをしたりすることになるのです。

上図で学習できることは、

「予定していた作業が終わらないと未来のチームのリソースを食いつぶすよ」

ということです。じゃあ、その対策はどうすればいいかってことになるのですが。

じゃあ、どうするかといえば予定作業を終わることを把握することですが、把握するサイクルを変えればいいのかってことです。

週次を日次に変えればどうなるでしょう。

やっぱり遅れる作業は遅れるのです。

これは、進捗把握の単位と作業の単位がずれているから生じます。やってしまったこと＝遅れてしまっていることをいくら把握しても早くなったりしないのです。

ではどうすればいいか。予定していた作業を予定どおりに終わらせるレシピです。

進捗把握（＝進捗管理）は日次で把握する

作業は時間単位まで分解する

1日の実作業時間は5時間を上限にする

実作業時間に割り込みをしない

1日の最後に作業のアウトプットをリポジトリにコミットする

大事なことは1日いち日と終わらせることをです。

プロジェクトマネージャの立場であれば、項番3は、フルフルの8時間（1日＝8時間労働の場合）としたいところですが、

進捗把握の時間

コミュニケーション（＝情報共有）の時間

仕様検討、レビューの時間

研修、教育などの間接時間

休暇などの間接時間

など正味の作業時間（＝ドキュメントやコードを書く時間）には直接関わらない、でも必要な時間を控除した上で実時間を設定しなければ、いくら綺麗で整合性のあるスケジュールを作っても必ず遅延します。

でもやっぱり遅れます。パッケージのバグやAPIの動きが想定していない動きをするとか、メンバが風邪で寝込んでしまった、忌引きがあった、などなど想像しようと思えば想像できることを予定に組み込まないでいるからです。

それはプロジェクトの局面やスプリントごとのバファをプロジェクトマネージャがプロジェクトのバッファとして確保しておくことが必要です。

このバッファは誰にも言ってはいけないし、絶対に守らないといけないバッファです。そうしないとプロジェクトを直接回しはしないのにステークホルダーとなっている関係者が（特に身内から）削ろうとしてくるので。