こんにちは！エンタメ領域のDXを推進するブロックチェーンスタートアップ、Gaudiyでエンジニアをしている土居（@taro_engineer）です。
僕は普段、コミュニティや決済などの基盤を開発するPlatformチームで、バックエンドを中心に担当していますが、週次から毎日へとふりかえりの仕方を変えました。
ふりかえりはどのチームでも実践していると思いますが、よくあるのが「ふりかえって課題を洗い出せたものの、それが改善につながらずに忘れられてしまう」ことではないでしょうか。
そこで今回は、2ヶ月ほどチームでうまく運用できているレトロスペクティブの方法について、運用の工夫とともにお伝えしたいと思います。
チームの改善やDXの向上に取り組みたい方に、ご参考になると嬉しいです！
- 1. なぜ「毎日」ふりかえることにしたか
- 2. Gaudiy流・レトロスペクティブと運用の工夫
- 3. レトロスペクティブから実際に生まれた改善たち
- 4. 現在感じている課題と今後改善したいこと
- 5. さいごに
1. なぜ「毎日」ふりかえることにしたか
Gaudiyのふりかえりの歴史から言うと、元々はプロジェクトが終わるごとに実施していました。
背景として、Gaudiyではブロックチェーンを活用したファンコミュニティサービスを開発していますが、新規コミュニティの開発もあれば、既存コミュニティの新機能開発などもあり、常に複数のプロジェクトが進行しているような状況です。
大小さまざまなプロジェクトがありますが、大体2週間〜3ヶ月ほどの期間になるため、プロジェクト終了時のふりかえりだけでは十分な頻度を確保できていませんでした。
そこで、毎週金曜に開発チームでふりかえりを行うようになったのですが、それでも「1週間なにをしていたか、その時なにを感じていたかを思い出せない」「記憶が曖昧で事実にバイアスがかかってしまう」「ふりかえり自体に時間がかかる」といった問題がありました。
また、ふりかえりによって改善案がたくさん上がってきても、そのすべてを実行に移すまでには時間がかかるし、正確なイシューを捉えて次の改善にうまく結びつけることができていませんでした。
Gaudiyの事業は進むスピードが速く、不確実性が高いことを開発で取り扱っているため、チームの改善もアジャイル的に進める必要があると感じて、ふりかえりを「毎日」実施する運用に変えました。
2. Gaudiy流・レトロスペクティブと運用の工夫
このふりかえり手法を、Gaudiyでは「レトロスペクティブ」と呼んでいるので、その運用方法と意識していることをご紹介してみたいと思います。
※厳密なレトロスペクティブではないですが、「Don’t just Do Agile, Be Agile」という言葉があるように、アジャイル的な開発手法に固執するのではなく、アジャイルな状態であることが大事だと考えています。
まず運用としては、毎日実施している夕会で、10分間のレトロスペクティブを設けています。
10分間にした理由としては、毎日行うのでふりかえりに対する時間的コストや心理的コストをなるべく下げたかったのと、実際に何度か試したところ、1日分のふりかえりであれば10分程度でできることがわかった、ということがあります。
また、レトロスペクティブの観点は「👍良かった！」「👎惜しかった... 」「💪変えてこう！」「🧠今日のナレッジ」の4つにしています。KPTをベースにしながら、独自の項目を設定しました。
ここで大事にしているのは「ふりかえりが、次の改善アクションにきちんとつながるか」という点です。
KPTもシンプルで使いやすいですが、Problemはたくさん出てきたけど、具体的なTryにつながらない…といったことはよく起こりがちかなと思います。「ここを、こう改善していこう」と意思決定しても、それが実行に移されなければ意味がないので、それを解決する仕組みを取り入れたいと考えました。
そこでGaudiyでは、毎日のレトロスペクティブで「良かったこと」をたくさん出すように意識して、それを汎用化させることでチーム全体の改善を促しています。
というのも「良かったこと」は、だれかの実績なので他のメンバーも取り入れやすく、「惜しかったこと」を改善するTryよりも再現性が高いため、チームへの浸透率が高いです。各人の良い行動をチームみんなで真似していくイメージです。
また、ふりかえりの最後に「今日のナレッジ」を設けることで、ただふりかえるだけで終わらせず、個人の良い動きをチームのナレッジに昇華させるアクションにつなげています。ちなみに最近では「今日のナレッジ&ドキュメント」という項目に改良して、プラス担当者も決めることでナレッジ蓄積を意識しています。
もちろん良くなかったことの改善も大事なので、「惜しかったこと」に対してもチームで改善に動けるような工夫を取り入れています。そのひとつが、パターン・ランゲージの作成です。
たとえば、ある日のレトロスペクティブで「もう少し早く、Pull Requestを出すくらいのタイミングで、ステークホルダーと一緒に実際に開発したものを触りながら仕様漏れがないかの確認や改善を試みれるといいよね」といった声がありました。
そこから生まれた「ちょいデモ」というパターン・ランゲージは、手戻りが起きる可能性を極力避けるために、実際にチームでよく活用されています。
3. レトロスペクティブから実際に生まれた改善たち
運用開始してから数ヶ月ほどうまく回っていますが、ここでは、実際に生まれた改善アクションについていくつかご紹介してみたいと思います。
3-1. レビュー待ちPull Requestが解消され、開発全体のスピードが上がった
ある程度要件が決まり、不確実性が少なくなってくると、開発に集中してコードをゴリゴリ書いていくフェーズになります。このフェーズは開発のスピードが一段と上がるので、チーム全体のPull Requestがたくさん出てくるようになりますが、自分の開発とレビューのバランスを取るのがわりと難しかったりします。結果的にレビューが溜まってしまい、全体の開発スピードが鈍化することがありました。
そうした状況に対し、ある日のレトロスペクティブで「レビュー待ちのPull RequestがないかをSlackで尋ねたら、そこからチームでレビューを解消する動きが生まれた」ことが、良かったこととして挙げられていました。
そこで、あるメンバーが自律的に実践してくれていた「レビューの時間を決めて解消する」という動きをチームで取り入れるため、「全員でレビューするタイミングをつくる」ことをNext Actionにしました。
レトロスペクティブでチームとしてのActionを決めると、また同じような状況があった際に、気づいた人が行動に移すことができているなと感じます。
3-2. 開発とコンテキストが異なる全社的なことにも、率先して参加した
またある日のレトロスペクティブでは、「全社宛ての依頼に対して、〇〇さんが率先して対応していた」ことが良かったこととして挙げられていました。
この良かったことの共有から、実際、また同じようなことがあった際に、チームのみんなが意識して行動に移すことができました。
開発に集中していると、コンテキストが違う全社系の依頼をついつい見過ごしてしまうことがありますが、全社目線をもって改善していこうというチームの意識に変わりました。ナレッジ化まではいかなくても、チーム全員として何が良い行動なのかの意識醸成につながったかなと思います。
3-3. フロー効率を取り入れて、チームの生産性を向上した
さいごは、惜しかったことからの改善です。ひとつのチームが持つコンテキストが広がり、各人が別々のコンテキストのタスクを抱えていたことで、お互いのレビューをする際のコンテキストスイッチにコストがかかったり、今誰が何をやっているか把握しづらくてヘルプしづらいといった課題がありました。
結果として、チーム全体の生産性を下げているのでは？ ということがレトロスペクティブで挙がっていたため、「次はフロー効率でやってみよう」というNext Actionが生まれました。
こうした改善は、レトロスペクティブでなくても誰かの発案から実行に移せると思いますが、誰でも気がつける状態や、行動に移せる状態まで昇華していくためには、チームのレトロスペクティブで意識レベルの共有を行い、再現性を高めていくことがポイントだと思っています。
4. 現在感じている課題と今後改善したいこと
毎日のレトロスペクティブを導入したことで、以下のようなメリットを感じています。
- 記憶が新しいのでふりかえりに時間がかからない
- ある事象に対するリアルな気持ちを忘れにくい
- 改善アクションが格段に増え、すぐに実行できる
特に、やはり3つ目の「小さく、すばやく」改善していけることが一番のメリットかなと感じます。
改善点を溜め込んでしまうと、Next Actionを決めてもそれを消化していくのに時間がかかるし、そもそもの状況が変わってたり、さらに負債が溜まってしまうこともあるので、毎日ひとつずつでも改善していくことが大事だと思います。
一方、以下については今後の課題として、これから改善していきたいと思っています。
① 定量的な観測はできてない
「変えていこう！」に挙げられたことがどのくらいチームに浸透したか、また実際に改善できたかの効果検証については、いまは定性的な感覚になってしまっています。これに対するひとつの解決策として、パターン・ランゲージの作成や活用があると思うので、定量的に測れるアクションにつなげていきたいです。
② チームに閉じている改善が多い
チーム内のふりかえりはうまく回っていますが、改善の影響範囲はチーム内であることが多いので、今後は全社への浸透もしていきたいと思っています。メンバーの自律的な改善から、チームの改善、そして組織全体の改善につなげていきたいです。
また、レトロスペクティブのやり方自体も、試行錯誤しながら常にアップデートしています。最近では、Next Actionにつなげるまで深ぼれないことがあることから、ふりかえりの時間を10〜20分間に設定し、柔軟に調整する形にしています。
5. さいごに
今回は、Gaudiyの開発チームで実践しているレトロスペクティブについて紹介させていただきました。Gaudiyのクレドのひとつでもある「Be Agile」なカルチャーが伝わっていたら嬉しいです。
今回、ブログを書く上でふりかえってみて思ったのは、チーム全体の改善を促すには、良くなかったことを改善するだけでなく、良いことを再現性のあるものに昇華することがアジャイルな組織では大切なのでは、ということです。
また、大きな目標を掲げて、大きな改善めざすのはもちろん良いことですが、そのためにも、毎日コツコツ小さな改善を積み上げることが大事だし、結果としてそれがチームの大きな改善につながっていくと感じています。
僕たちもまだまだ改善途上で、他社の開発チームの良いところもどんどん取り入れていきたいと思うので、初Meety作ってみました（笑）。チームの改善やDX向上に取り組まれている方、関心のある方、ぜひお話ししましょう！
オープン勉強会などもやってますので、よければ遊びにいらしてください！
