Runner in the High

技術のことをかくこころみ

開発チームの振り返りタイミングのパターン

考えることがあったので雑にメモ。

1. 毎週末(木曜日or金曜日)

  • 最も一般的なパターン。木曜日ないし金曜日にその1週間を振り返る。
    • 1スプリントを1weekと置いていれば毎週何らかの成果物があるはずなので、それに対する振り返りがこの時間にあたる。
  • 毎週30分-1時間近くの時間を毎週ブロックすることになる。
  • 振り返りで出てきたトライを翌日からすぐに始められない(土日に入ってしまう)ため、トライ実施のモチベーションに懸念が残る。
    • 週明けにトライの内容を再確認するなどの工夫で解決できる可能性がある。

2. 毎週明け(月曜日or火曜日)

  • 1の問題点であったトライ実施のモチベーションが改善され、翌日からモチベーション高くトライを意識できる。
  • 一方で、振り返る内容は先週のものになるためメンバの振り返りに対するモチベーションが低くなる懸念がある。
    • 振り返りに対するモチベーションの低下すごく致命的で、これが起きてしまうとそもそも振り返りの時間そのものが遊んでしまう。
    • 開発過程での課題を記録しておいてもらうなどの方法も考えられるが、基本的に人間は「忘れずになにかをやる」というのは不可能であると考えたほうがよいため、あまりまともなアイデアではない。

3. 開発アイテム終了後

  • 定期での振り返りを実施しないかわりに、開発アイテム単位で振り返りを実施する。これによって毎週1時間を必ずブロックされることがなくなる。
  • 少なくとも毎週定期で振り返りをするよりも凝縮されたものにはなるが、一方で開発期間が長いアイテムの場合には開発中に発生した課題を誰かが記録していないとすぐに情報が失われてしまうため、振り返りのタイミングで「なにも覚えてない」の状態になる懸念がある。
  • 「振り返りをするアイテム」と「振り返りをしないアイテム」の定義も必要になる。
    • 開発メンバ全員、開発メンバ個々人、リーダー/マネージャで見えている風景が異なるため、振り返りのモチベーションに対する合意をとるコストが発生する場合もある。この意思決定をナアナアにしたり無視したりすると今度は振り返りに対するモチベーションに影響がでる。

4. 振り返りを不定期実施にする

  • 朝会のタイミングで問題定期をしてもらうなど、不定期的になんらかの問題が起きたタイミングで開発プロセスに対する改善を加える。
  • 一方で、集団で話しながら振り返りをするということがなくなり視点が個々人に閉じるため、振り返りの対象が近視眼的なものになる懸念がある。
  • メンバーのモチベーションにもよるが「場がなければ行動を起こせない」という性質のチームであると基本的に自主的な改善は発生しない。

振り返りのROI

「振り返り」はチームの中で気づいた改善点や強みを共有しあうことで改善のサイクルを回し、より効率のよい開発を行えるようにするための重要なプロセスのひとつである。

一方で我々の時間は有限であり、週あたりの労働時間において「振り返り」が占める時間と、その「振り返り」から生まれる結果に対して、振り返りを実施する人間は気を配る必要がある。振り返りをしたからと言って必ずしもチームのアウトプットの質が改善されるわけではなし、振り返りをしなくても自律的に改善が行われるチームもある。振り返りをしなくても自動的にチームが良くなるような高ROIなチームなら、敢えて時間をとる必要もない。

そのようなチームはいわゆる自己組織化されたチームと呼ばれるものであるが、そのようなチームにおいてはルール化/フレームワーク化された仕組みはただ単に形骸化するどころか逆にチームのパフォーマンスの足かせにもなるため、注意が必要だと言える。