KPT をしたら「T が今までできていなかった理由」まで深掘りするようにしてる

振り返りをする際に KPT のフレームワークがシンプルかつ強力なのでよく使っている。

そして加えて、タイトルの通りだが「Try をこれまでできていなかった理由」についてもその場で考えるようにしている。

単に「これまでやってみようと思ったことがなかったから」ならいいが、そうではないこともしばしばあって… そういうときに、結局 Try が全く実行されないような事態が起きうるので。

ちょっと抽象的すぎるので具体例を紹介。

  • スクラムのスプリントレトロスペクティブで「A さんにコードレビューが集中しすぎてボトルネックになり、全体が遅くなっている」という Problem が出た。

  • Try として「コードレビューはいろんな人にお願いしよう、特にバックエンドは B さんも得意だから任せよう」となった。

  • しかし実際には「リリースするコードはすべて A さんのレビューを必須にする」という監査都合の組織のルールがあったため、結局 A さんもレビューする必要があり改善はされなかった。残念。

これくらいわかりやすい例はなかなか起きないかもしれないが…解決策を実行する前に「そもそもその解決策を取らなかったのはなぜか?」と立ち止まって改めて考えることで、見えていなかった暗黙の前提に気付くことがある。

  • 「インシデントは小さいものでもどんどん報告して解消しよう」vs.「インシデント発生数が評価に直結するため報告したくない」

  • 「ペアプロ・モブプロをもっと促進しよう」vs.「日中リモートワークをする際には子供が昼寝しているため、声を出すのは強力避けたい」

  • 「夜間や週末に Slack でやり取りするのをやめよう」vs.「上司がしているから自分もしなければと思っていた」

のような感じで、暗黙の前提が影響して改善策が失敗することは本当にたくさんある。言い換えればここまで先に考慮しておけば、より成功確率の高い解決策を実践できるようになる。

アジャイルに改善活動を積み重ねて行きたい昨今、振り返りの質アップにぜひ。

@yamat47
ソフトウェアエンジニアやったりマネージャーやったり。 @yamat47