振り返りのフレームワークを作った話

タイトル通りです

自分が「インフラエンジニア採用できなくて1人チームで死ぬ」みたいな嘆きをしていたのをご存じの方もこれを読まれているかもしれませんが、おかげさまでインフラエンジニアの採用がうまく行き、いつの間にかインフラチームのリーダーみたいなことをやるようになってしまったのですが、チームで使っている振り返りのフレームワークが良い感じになったような気がするので久しぶりにブログでも書いて供養するかと思った次第です

なんか知らんけど社内で横展開されて評判がよかったんです
あとリファラルの報奨金おいしい

忙しい人向け

こちらのgistに置いてあるのでよしなに見てください

振り返りフレームワーク備忘 · GitHub

忙しくない人向けの使い方の解説

所要時間

  • 先月まで3人チーム、今月から4人チームで使っていますが、週に1回の頻度でだいたい30分くらいかければ終わります

前提条件

  • うちの会社では社内WikiにGrowiを使っていて、それにHackMDをくっつけてWiki上で振り返りをやっています
  • よくありがちなカンバンツールは全く使ってないです
  • ファシリテーターはとにかく気を抜いて運営しましょう

前回のアクションができたか確認

  • 前回の振り返りでリスト化した、改善のためのアクションが実行できたかどうかを振り返ります
  • アクションが やれた のか やれたとは言えない のかだけチームで合意してサクッと次に行きます
    • たまに「これやれたとは言えないけど今思うと別にやんなくてよかったよね」ってなることもあります

よかったこと

  • 3分とか5分くらいでその週のよかったことをみんなで箇条書きします
  • 脳みそをアホにして良さそうなことはガンガン書いていきます
  • 書き終わったらみんなで眺めます
  • 箇条書き以外の補足があれば書いた人が補足します

改善したいこと

  • これも5分くらい時間を取ってその週に起こったイケてないことを箇条書きします
  • ちょっとでも直したいなーと思ったことはとりあえず書きます
  • 細かい話は後にして、とりあえずここでは書いたことをみんなで眺める程度にします
  • アクションがやれたとは言えなかったときにここにそれを書いたりします

振り返りの分析

  • 主に(というかほぼ常に)改善したいことに書かれた内容について、主に以下のことを議論します
    • なぜ起きてしまったのか、 原因の深掘り
    • それを 防ぐための取り組み をどうしたらいいか考える
    • 取り組みが現実的かどうか( アクションとしてすぐ実行できるか どうか)
  • 議論してもしょーもないことは議論しません
    • 例えばチームが立ち上がったばっかりの時点での「タスクにつけたストーリーポイントがいい感じにならない」みたいなのとか
  • ここでは特に時間を意識しません
    • と言うよりも、なぜか毎回いい感じの時間に議論が終わるので気にしたことがないです
  • ここに書いてて思ったけど項目名変えたほうがいいな

アクション

  • 改善するためにすぐ実行できるアクションをリスト化します
  • ここに並ぶアクションはチケット化するまでもないちょっとしたものだったり、日々の習慣における意識づけを変えてみるようなものだけです
  • すぐに実行できないようなもの(例えばサーバーの設定を変更してナントカカントカ)みたいなのはチケット化します
    • そういうのは「サーバーの設定を変更してナントカカントカする」というチケットを作るアクションを作ります

以上、だいたいこんな感じです

作った経緯

そもそも振り返りのフレームワークなんて世の中に溢れかえっているのに、なんでこんなの自作したんだよって話

自分としてはよくあるKPTみたいなのって凄くかたっ苦しい印象があるのでメッチャやりたくないんですよね(振り返り大事なのでやるけど)
KPTやりまーす」って呼ばれただけで身構えちゃう人って自分だけじゃないと思うんですけど、実際どうなんでしょうか?

ユルそうなYWTとかもそうですけど、とにかく「振り返りのフレームワークこれです!どん!」って出されるとなんか身構えちゃう(のでフレームワークに名前つけたりはしてないです)

ということで、アジャイル的に改善を継続していくために振り返りは必要だが、ユルい感じでやりたい、と思って作ったのがこのフレームワークになります

最初は今のような項目ではなく、振り返りをやり始めた1年くらい前は↓の項目しかありませんでした

  • よかったこと
  • 改善したいこと
  • アクション

時が経つと「そもそもなんでこのアクションにしたんだっけ?」ってなっちゃうので、ちゃんとその経緯を残すための場所を作ったのが1回目の更新

あとは「先週のアクションも振り返らないとアクション立てる意味ねーだろ」ってなって前回のアクションを追加したのが2回目の更新です

このフレームワークを使い始めたときは2人チームで、その時のことを思い出すとメンターとメンティーの関係でこれ使うのもアリっぽいなと思ってます

余談

この振り返りで結構気に入ってることが2つあって、

1つは自分で作ったやつなのでうまく行かなかったら他のフレームワーク探す、とかじゃなく足りなかった部分が見えてきたら雑に足したり引いたりがやりやすいこと

もう1つはアクションを出すための分析をするという項目が明確に存在していることです

これKPTとか他のフレームワークでもそうだと思うんですけど、カンバンとかでproblemに対するアクションを議論してる時って経緯が結論に至った経緯が残りづらいと思うんですよね
(実はそんなことないかもしれないけど、自分がいた場所ではそういう文化は無かった)


ということで、イチから振り返りの方法を考えるのもアリだと思うのでググって出てくるフレームワークでなんかしっくり来ない時はやってみるのもいいと思います
「お前がやってることはこのフレームワークと同じだぞ」というのを知ってる人がいたらコッソリ教えてください

社内の一部にはTwitterがバレてるのでついでに書いておきますが、インフラチームでは普段毎週水曜日の17:00から振り返りをやってます
興味がある人は見に来てくださって大丈夫です、勝手にカレンダーのMeetから入ってきてください

あとこれ超大事なんですけど、弊社ではAIを活用したサービスを作るプロジェクトをリードできるアプリケーションエンジニアが足りないです
AI様を社会に実装するためのタイピング肉体労働をしたい人がいたら声かけてください

ghelia.com