なぜ遅れたのか？いつできるのか？
タイトルはいろんなプロジェクトでPMからよく言われた言葉だった。
いつも責められているようで辛かった。へとへとに疲弊し、頭が回らない。遅れの原因がなにかもわからない。見積もりが甘かったせいじゃないか。自分のスキルが足りないせいだ。仕様変更が相次いだせいだ…。いろんな言葉が頭をよぎるけど、見積もりが甘かったです、頑張りますとしか言えない。そんなのは理由にならないと叱られ、いつできるのか？と聞かれる。根拠もなく明日には…としかいえず、その翌日も結局間に合わず、同じ光景が毎日繰り返されていた。
最近になってPMを担当するようになった。過去の光景を思い出しつつ、どうすべきだったかを振り返っている。PM経験の浅い自分が語るのはちゃんちゃらおかしいけど、この先振り返るためにも、考えを書き出しておこうと思う。よりよい方法が見つかれば変えていけばいい。
タスクの分割
タスクを適切に分割し、担当と期日を決める。
分割の単位は数日で達成できる分にする。担当のスキルに合わせて期日を決める。
タスクは一人でこなせるほうがよいが、複数人で担当するときはリーダーを決める。
進捗確認
メンバーがタスクを開始したら定期的に状況を確認する。
メンバーの性格に合わせて確認の頻度を調整する。細かく確認したほうがパフォーマンスの出るメンバーもいれば、ある程度任せたほうが良いメンバーもいる。
メンバーに進捗報告を任せない。悪い報告はなかなか上がらない。自分から聞きに行く。
遅れの分析
タスクの進捗が予定より遅れたとき、なぜ遅れたのか？と責めない。
見積もりの前提と現実にズレがあるから遅れる。それを解消しない限り遅れは続く。再見積もりさせても結局ズレる。
どこに時間がかかったのか。それは解消したのか、今も続いているのか。メンバーだけで解決するのか、PMもヘルプできることがあるのか。
PMもメンバーと共に問題に取り組む姿勢を見せる。そして、行動する。
再見積もり
いつできるのか？
これだけを聞かれて正確に見積もれるメンバーは少ない。遅れていることに苦しみ、PMのプレッシャーまで感じる状況で、正しく答えを出せるはずがない。
PM・メンバーで協力して再見積もりを行う。残っているタスクを洗い出し、そこに潜むリスクを洗い出す。その上で工数を見積もる。
遅れの責任
遅れの責任はPM・メンバーの双方にある。
明確なタスクと期限を設定すれば、ほとんどのメンバーはそれを達成しようと努力する。
PMの仕事はメンバーの不安や雑念を取り除き、タスクに集中できるようにすることだ。
