読者です 読者をやめる 読者になる 読者になる

ぱと隊長日誌

ブログ運用もエンジニアとしての生き方も模索中

なぜ遅れたのか?いつできるのか?

なぜ遅れたのか?いつできるのか?

タイトルはいろんなプロジェクトでPMからよく言われた言葉だった。
いつも責められているようで辛かった。へとへとに疲弊し、頭が回らない。遅れの原因がなにかもわからない。見積もりが甘かったせいじゃないか。自分のスキルが足りないせいだ。仕様変更が相次いだせいだ…。いろんな言葉が頭をよぎるけど、見積もりが甘かったです、頑張りますとしか言えない。そんなのは理由にならないと叱られ、いつできるのか?と聞かれる。根拠もなく明日には…としかいえず、その翌日も結局間に合わず、同じ光景が毎日繰り返されていた。

最近になってPMを担当するようになった。過去の光景を思い出しつつ、どうすべきだったかを振り返っている。PM経験の浅い自分が語るのはちゃんちゃらおかしいけど、この先振り返るためにも、考えを書き出しておこうと思う。よりよい方法が見つかれば変えていけばいい。

タスクの分割

タスクを適切に分割し、担当と期日を決める。
分割の単位は数日で達成できる分にする。担当のスキルに合わせて期日を決める。
タスクは一人でこなせるほうがよいが、複数人で担当するときはリーダーを決める。

進捗確認

メンバーがタスクを開始したら定期的に状況を確認する。
メンバーの性格に合わせて確認の頻度を調整する。細かく確認したほうがパフォーマンスの出るメンバーもいれば、ある程度任せたほうが良いメンバーもいる。
メンバーに進捗報告を任せない。悪い報告はなかなか上がらない。自分から聞きに行く。

遅れの分析

タスクの進捗が予定より遅れたとき、なぜ遅れたのか?と責めない。
見積もりの前提と現実にズレがあるから遅れる。それを解消しない限り遅れは続く。再見積もりさせても結局ズレる。
どこに時間がかかったのか。それは解消したのか、今も続いているのか。メンバーだけで解決するのか、PMもヘルプできることがあるのか。
PMもメンバーと共に問題に取り組む姿勢を見せる。そして、行動する。

再見積もり

いつできるのか?
これだけを聞かれて正確に見積もれるメンバーは少ない。遅れていることに苦しみ、PMのプレッシャーまで感じる状況で、正しく答えを出せるはずがない。
PM・メンバーで協力して再見積もりを行う。残っているタスクを洗い出し、そこに潜むリスクを洗い出す。その上で工数を見積もる。

遅れの責任

遅れの責任はPM・メンバーの双方にある。
明確なタスクと期限を設定すれば、ほとんどのメンバーはそれを達成しようと努力する。
PMの仕事はメンバーの不安や雑念を取り除き、タスクに集中できるようにすることだ。