shiodaifuku.io

プロジェクト振り返りが嫌いな理由

この記事はしおだいふく Advent Calendar 2020 9日目の記事です。 昔どこかに書いたかもしれない1ポエムの改訂版です。

先日「障害振り返りはいいぞ」という話を書いたばかりで、プロジェクト振り返りはやめろという話を無矛盾に展開できるかはわかりませんが、 細かいことは気にせずに、プロジェクト振り返りの場でよく使われるフレームワークのKPTを中心にディスっていこうと思います。

こんなプロジェクト振り返りは嫌だ

僕がプロジェクト振り返りを嫌っている主な理由は、ほとんどの振り返り会がそのプロジェクトにおける問題点の分析と対策に終始してしまうためです。 KPTでいうと、Pばっかりに注目が集まっちゃうアレです。 振り返りの場でそのプロジェクトにおける課題とか事象の原因とかを深掘りしていっても、僕のそんなに多くない経験上意味のある結論が得られたことはほとんどありません。

プロジェクトは理解がとても困難な生き物です。 たとえば「スケジュールに余裕をもって進められた」という良かった点があがったとしましょう。 その真因を探ろうとすると、 スーパーエンジニアの生産性が死ぬほど高かったという属人的でチームとして再現できない話にたどりついたり、 別な事情でプロジェクトの期日が伸びていたとかそもそも見積もりが甘かったのではないかとか最悪単に運が良かったのではないかとか言う話になって決定的な要因がわからなかったり、 実は裏で誰かがプロジェクトがうまくいくように(その人にとっては当たり前すぎて言語化できない)こっそり活動をしていたため議論の俎上にすら載らなかったりします。

ダメなKPT

KPTを採用するとやらかしがちですが、「次のプロジェクトでもKeepできるように頑張ろう」とか「次のプロジェクトではProblemが起こらないようにしよう」とか考えて、 Tryを設定するのは避けたほうがいいんじゃないかなと思います。

上にも書きましたが、プロジェクトは理解がとても困難なので、今回良かった(Keepしたい)ことが次のプロジェクトでも同じ方法で再現できるとは限りません (し、Keepの妥当性=次のプロジェクトでも再現させるべきかについてもまた別途検討する必要があります (し、Keepしようと思って何かを変えた結果Problemになったりしたら目も当てられません))。 同様に今回の失敗の原因を明確化することで類似のProblemを回避することができるとは限りません。 そんな感じで設定されたTryはナンセンスと言わざるを得ません。やめましょう。

こんな振り返り会なら意味があるかもしれない

プロジェクトの最中にはさまざまなイベントが発生したりしなかったりします。 発生したやつに思いを馳せることはまぁできなくはないですが、顕在化しなかったけどしたらヤバかったであろうリスクを事後に洗い出すことは極めて困難です。

そこらへんの洗い出しをクソ真面目にやって振り返りとすることを殊更に否定はしませんが、我々は忙しいエンジニアであり無限に時間があるわけではありません。 振り返り会のアウトプットをもって組織がどうとかプロセスがどうとかを考えるのはヒマな人に任せておけばよいでしょう。 僕が運悪く振り返り会に呼ばれてしまった場合は、勝手に成功イメージを共有することを目的とすることにしています。

そのために僕が重要だと考えているのは、他のメンバーがプロジェクト中にどんなことを感じていたかをKeepやProblemを読んで理解することです。 Keepに挙げられている項目はそのプロジェクトに関わったメンバーが「よかった」と感じている話なので、 これはまさにプロジェクト成功のイメージそのものです。 Problemはその逆で、失敗イメージと言えるでしょう。

各メンバーはプロジェクト作業をする中で無意識のうちに数々の決断をしています。 僕のようなひねくれた人間が振り返りの場を有効活用するためには、他のメンバーが下した決断がどういう思考に基づくものだったのかを推測するチカラが要求されます。 「この人はこういう状態がハッピーなんだな」とか「こういう状態にツラみを感じているんだな」という情報をもとに 自分が次に行動する際の判断基準を改良し、メンバーが幸せな状態を維持するための情報を得る場にすると振り返り会が有意義なものになる気がします。

KPTの結果を共有してチームを改善しようとかいうのはマジでクソ寒いからやめてほしいです。 ぶっちゃけ組織の改善とかはどうでもいいです。周囲がどうあれ自分のチカラで組織を成功に導けるようにスキルを磨くほうがよっぽど有意義です。

良い振り返りのためのKPTの書き方

というわけで、KeepとかProblemはプロジェクトを進めている最中に感じたことをリアルタイムに、かつ素直に記録してもらえるのが一番嬉しいです。 他人に自分がどう思っていたかを理解してもらうためのものなので、チームの役にたてようとか余計なことを考えて見栄っ張りなかっこいいことを書く必要はまったくありません。 画一的な解釈ができるようにしておく必要もありません。 どうせ何を書いたってあなたが思っていたことを正確に理解してくれる人なんていません読んだ人が良いように解釈してくれます。

同様にTryについても意味があることが誰にでも容易にわかる改善を挙げる必要はありません。 他のメンバーが書いた内容に思いを馳せた結果、自分がやろうと思ったことを勝手に宣言するだけでよいのです。 それがうまくいかなかったら3日後くらいにやめるのでもいいわけです。

KeepをKeepしようとするな

最後にこれだけは言っておきたいのですが、Keepに書かれたことをKeepしようとするとプロジェクトのたびに苦しみが増えるだけなのでやめましょう。 プロジェクトとはただでさえ攻略困難なモンスターです。意味があるかどうかわからん手枷を装備して挑むものではありません。

「特に変わったことはしていないけれども、終わってみたら前回Keepに書いたことが今回も達成できてた」くらいを目指すのが幸せなんじゃないかな!


  1. 原典は会社の勉強会かなにかでお気持ち表明したときの資料です。類似の内容をQiitaに書いた気がしますが、アカウントを捨てたのでわかりません。

最新記事

  1. Cloud RunでgRPC streamingができるようになったので動かしてみたりした
  2. 2020年の執筆業まとめ
  3. アーキテクチャを設計する仕事とは
  4. 決済システムを設計するときに忘れてはならないたった1つの大切なこと
  5. third-party cookieと2020年