この記事は何
日々朝会などでマネジメントしているメンバーの進捗を聞いていると「進捗悪いです」というワードが出てくることがしばしばあります。
このワードが出てきた時にマネージャーとして僕が判断し行なっていることをまとめます。
開発組織を想定して記事は書いていますが、開発タスク以外でも、開発組織以外でも参考にできる内容だと思っています。
それぞれご自身の組織に照らせ合わせながら読んでいただけると嬉しいです。
進捗が悪くなる要因
コミュニケーションについて書く前に、まずはなぜ進捗は悪くなるのかの要因についてまとめたいと思います。
僕は、ほとんどの場合進捗が悪くなる場合は以下の三つのパターンに当てはまると考えています。
- 知識・経験不足
- 例: タスクの中で出てきた問題が解決できていない
- 差し込みの発生
- 例: タスク外のことを色々やっている
- タスクボリュームの見積りミス
- 例: やることが思ったよりも多かった
これらの三つの要因に対して上手くチームの動きをキャリブレーションしていくことで、
進捗の回復を狙うことが主なアプローチになります。
それぞれの要因に対してできるアクション
前項で挙げた要因に対して、チームとして取れるアクションは以下のパターンが多いかなと考えています。
知識・経験不足
知識・経験不足の場合は知っている人がサポートすればすぐに解決し、前へ進めることが多いです。
なので、このサポートにどれだけ早いタイミングで入れるかが重要だと考えています。
メンバーが何かしら自身で解決できない問題に遭遇している場合は
- その問題を解決できるメンバーが他にいないか
- 解決できるメンバーのキャパシティ的にサポートに入れるか
を把握し、問題を素早く取り除くことを狙います。
差し込みの発生
差し込みで進捗が悪くなっている場合は、その差し込みの対応を本当にその人がやらないといけないかを判断することが重要だと考えています。
メンバーが差し込みの対応に追われアサインされたタスクが上手く進められていない場合は
- 他のメンバーはキャパシティ的に余裕があるか
- 差し込みタスク/アサインされているタスクは他のメンバーでも対応可能か
- 差し込みタスク/アサインされているタスクは誰がやることで素早く進むか
- 知識・経験的な観点
- 逆に誰がやってもパフォーマンスが変わらないタスクか
を把握し、チーム全体でのタスクの分散、平準化を狙います。
タスクボリュームの見積りミス
タスクボリュームがシンプルに多い場合にできることは、そこからできるだけ進捗を悪化させないこと、すでに進捗として深刻な場合は他のメンバーを当ててスピードを出せるかが重要だと考えています。
メンバーが想定よりもやることが多く進捗が悪くなっていることを把握した場合は
- 今他に持っているタスクはないか
- 対象のタスクは分割できるか
- 他のメンバーと分担して対応ができるか
を把握し、チーム全体でタスクを分けて対応するか、対象のタスクに集中できる状態を作ることを狙います。
最後に
進捗が悪い時、そんなにやれることがたくさんあるわけではありません。
しかし、逆にいうと今回紹介したパターンを把握しておくと、チームとしての動きの判断もしやすくなると思います。
各メンバーの進捗が悪いかを把握するためには、正しく状況を把握できる必要もあります。
以前朝会で状況を把握し、チームのアクションの改善を行うために僕が行なっていることも記事にまとめているのでよかったら参考にしてみてください。