はじめに

タクシーアプリ「GO」のアプリ開発チームには、PdM, デザイナー, iOS/Android エンジニア, QA メンバが所属しており、約 10 名のメンバーで構成されています。 2 週間ごとの Sprint でチーム内の活動が行われており、その最終日にはレトロスペクティブミーティングにてチームメンバ全員で「振り返り」をおこなっています。

当初は KPT による振り返りしていましたが、よりチームにマッチした振り返り手法を模索し、KPT 以外の手法を採用することになりました。本記事では、我々が日々行っている振り返り手法とその効果について紹介します。

KPT による振り返りとその課題

KPT という振り返り手法があります。Keep, Problem, Try の 3 軸に対して意見を出し合うものです。

KPT はシンプルで分かりやすく、チーム始動当初はこの振り返り手法を活用していました。

しかし、Sprint を重ねるごとにやや形骸化しつつあると感じるようになりました。

我々のチームにおける KPT での課題を以下に挙げます。

Try がほとんど出てこなく、Keep と Problem の共有だけで終了してしまうことがある
- 締めが Problem の共有だと少し暗い雰囲気でレトロスペクティブを終えることになる
Try が出たとしても、個人の短期的な TODO になる傾向が高い
Try の宣言だけになり、実行までに時間がかかることがある（最悪見送りになる）

つまり「Try がうまく活用できていない」これに尽きます。

幸い、Keep や Problem は毎回たくさん出ていたので、振り返ること自体はできていましたが、Sprint ごとに改善を積み重ねていくことができていませんでした。

また、プロジェクト終了後にはプロジェクトごとの「タイムライン（時系列で Keep, Problem を記載）」を作成するという振り返りも別途行われていました。

こちらに関しては、振り返り時に当時の記憶を思い出すことができなかったり、Sprint での KPT と重複した振り返りになっていることもあり、効率よく実施されていませんでした。

上記を解決すべく、2つの振り返り手法を採用し、各 Sprint のレトロスペクティブミーティングにて実施することにしました。

その詳細と効果を以下に紹介します。

プロジェクトごとの時系列による振り返り

今までプロジェクト終了後に行っていた時系列による振り返りを各 Sprint ごとに実施するようにしました。

以下の手順で振り返りを実施します。

プロジェクト開始時にタイムラインを用意する
- 1 週間ごとに破線で区切り、時系列でチームメンバの声を付箋で貼れるようにする
感情ごとに色分けされた付箋をあらかじめ用意しておく
- チームメンバはこの付箋を利用して振り返りを行う
レトロスペクティブミーティングにて、その Sprint に該当する期間に「感情に紐づく」意見を各自貼る
プロジェクトで起きたできごと（感情に紐付かないできごと）を記載する
チームメンバ全員に記載した意見を共有する
プロジェクト終了後に、Sprint を通して作成されたタイムラインを元に全体の振り返りを行う

上記の 3 から 5 を Sprint ごとに実施し、都度タイムラインを作成していくという流れです。

プロジェクトごとのできごとを細かく思い出せるよう記録し、チームメンバの意見は感情とセットで投稿するようにしました。

どういうスタートを切ったのか、開発中盤で発生した苦難、プロジェクト全体で健全な状態を保てたか、など、あとから俯瞰してみたときに感情の波を知ることができます。

長期のプロジェクトの場合、プロジェクト終了後に振り返りをしたとしても、なかなか当時のことを思い出すのが難しく印象が強かったことしか振り返られないという課題がありました。

Sprint ごとに振り返ることで、より詳細に精度の高い振り返りができるようになったと思います。

学習マトリックスによる振り返り

前述のとおり、タイムライン作成を Sprint ごとに行うようにしましたが、プロジェクトに紐付かないチーム活動や個人タスクなどの振り返りも必要です。

そこで、「学習マトリックス」という手法を参考に Sprint 全体の振り返りを行うことにしました。

以下の 4 つの軸を元に振り返りを行います。

😁 よかったこと / 続けたいこと
🙁 うまくいかなかったこと / 変えたいこと
💡 新しいアイデア / 気づき
💐 感謝したいひと / こと

以下の手順で振り返りを実施します。

Sprint 内で起きたこと・感じたことなどを上記に分類して付箋で書き出す
- 業務以外のプライベートな内容も歓迎
書き出された内容をチームメンバ全員で共有
- 上記の 4 項目を上から順番に共有する

今までの KPT での振り返りを元に、どういった意見がチームから出てきやすいかを分析し、より実態にあった項目を設けました。

Keep, Problem は今までもきちんと振り返られていたので、「😁 よかったこと / 続けたいこと」「🙁 うまくいかなかったこと / 変えたいこと」として、ほぼ同じフォーマットにしました。

Problem は、課題をそのまま書き出すだけでなく、「どうすればよかったか」「今後どうしていけばよいか」といった +Δ 要素を強めにしています。

「💡 新しいアイデア / 気づき」は、ひらめいたことや初めて知ったことなどを共有する項目になります。

ひらめきや気づきを共有すると、他の人にとっても有益な情報になることが多い印象です。

そして「💐 感謝したいひと / こと」で振り返りを締めます。ありがとうを伝える場として設けました。

自チームメンバに対してでもよいですし、他のチームメンバやプロダクト自体でもよいです。

当初は、この項目は 2, 3 件くらい投稿されれば十分かなと思っていましたが、実際にやってみると平均 13 件の投稿があり素敵な場となりました。

小さなことでもチームメンバから感謝の気持ちを伝えられると嬉しいですし、心理的安全性も高まりモチベーションの向上にも繋がります。

振り返りの締めが感謝の共有になることで、明るい気持ちで終えられるのもよい点だと思います。

Sprint ごとに小さな改善を積み重ねる

上記に加え、KPT の「Try」要素をブラッシュアップした取り組みも実施しています。

振り返りで出てきたアイデア・課題などから次の Sprint で取り組めることがないかを議論します。

その際に重要となる考え方として以下の 3 つがあります。

チームに対して効果のあるものかどうか
チームとして取り組む内容かどうか
次の Sprint 内で完結できる取り組みかどうか

なるべく個人タスクになるようなものを避け、チームとしての活動という着眼点をブレないように気をつけています。

そして、あまりに大きなアクションを設定すると、結局やらずじまいになってしまうので、必ずやりきれる範囲になるよう調整しています。

たとえ小さなアクションでも、Sprint ごとに継続して実施できれば、大きな改善に繋がるはずです。

おわりに

本記事では、タクシーアプリ「GO」のアプリ開発チームにおける振り返り手法について紹介しました。これら以外にも様々な振り返り手法は存在します。自分たちのチームに合った振り返り手法を模索し、ブラッシュアップしていくことが大切だと思います。よりよいアプリに仕上げられるよう、日々の振り返りを糧にこれからも取り組んでいきたいです。