こんにちは！READYFORでプロダクトマネージャーをしているkecy (@kecbigmt)です。こちらは「READYFORアドベントカレンダー2021」23日目の記事です。
今回は、READYFOR史上に残る大規模開発を裏で支えた、「振り返り」の工夫について書きます。
振り返り、やっていますか？
振り返りなしでアジャイル開発を語るのは難しいと言っても過言ではないほど、アジャイルなメジャーな手法では「振り返り」の重要性が強調されていると思います。
振り返りのフレームワークとしてよく使われるのは「KPT」。
- Keep（今後も続けたいこと）
- Problem（問題点）
- Try（問題を解決するためのアクションプラン）
の3つを洗い出して次の改善に繋げようというものです。
キャッチーで分かりやすく、手軽に取り入れやすい素晴らしいフレームワークです。
ですが、私が担当している「継続寄付」というサービスの開発においては、このシンプルなフレームワークを使いこなすことができませんでした。
この記事では、KPTを使おうとしてどんな問題が起きたのかを取り上げ、KPTの代わりに考案した振り返りのフレームワークをご紹介します。
そのフレームワークを先に軽く紹介すると、
Keep、Problem、Tryの代わりに、
- 👏 Clap：みんなで祝いたいこと・感謝したいこと・やってよかったこと
- 🤔 Issue：課題だと思うこと・解決策のアイディア
- 🧊 Icebox：話しきれなかったIssueの一時保存場所
- 💪 Try：Issueに対する解決策の案
- 👍 Keep：意識的に続けた方が良い習慣
- ✍️ Knowledge：将来に活きる学び
の6つの領域をホワイトボード上で作って、それを一定の手順で利用することで、チームの振り返りを促進するものです。
頭文字を無理やり取って「CITKフレームワーク」とでも呼びましょうか。音にするならシートック？ですかね？
詳しくは記事の後半で取り上げます。
KPTを使いこなせない！
まず、KPTによる振り返りを行なったときにどんな問題が発生したかを、その背景となる開発事情とともに書いていきます。
背景は「とにかく開発が大変だった」というよくある話なので、読み飛ばしても構いません。
背景：継続寄付という難題
2021年11月24日、クラウドファンディングプラットフォーム「READYFOR」は、さまざまな困難の解決に立ち向かうユーザー（実行者）のみなさまに向けて「継続寄付 ※」というサービスの提供を開始しました。
※サービス紹介： readyfor.jp
これにより、実行者のみなさまが、短期間で単発の支援を集めるクラウドファンディングだけではなく、月額の決済により継続的な支援を行う「マンスリーサポーター」をREADYFORの中で集めることをできるようになりました。
...10年以上の歴史を持つクラウドファンディングのプラットフォームに「継続寄付」という新しい支援の仕組みを導入する開発。
キックオフから7ヶ月以上の期間を要し、開発後期には社内の大半のエンジニアを巻き込む一大プロジェクトとなりました。
開発初期から昨今にいたるまでのREADYFOR開発経験を持つ"生き字引"、@toyocさんをして「これまでで最大級の規模だったのでは」とまで言わしめるほど、READYFORにとっては大きなチャレンジでした。
私は継続寄付のテクニカルプロダクトマネージャー（TPM*1）として、その開発を担う「継続寄付開発スクワッド」をリードする立場でした。
そこで頭を悩ませたのが不確実性の高さです。
10年以上の歳月を経て積み重ねてきたコード資産。それに向き合った初期メンバーは入社してまだ数ヶ月のエンジニアたちでした。
要件定義、仕様策定、設計、そして実装を進めていきますが、思いもよらぬ仕様や技術的負債と対面することも多く、なかなか思ったような開発スピードを出すことができません...。
KPT振り返りの悩み
そんな前途多難な船出となった継続寄付の開発。
必死にアジャイルのやり方を学び、毎週KPTによる振り返りを実施していましたが、チームを改善するどころか返ってネガティブな効果さえ表れていました。
1. Keepが出てこないと雰囲気が悪くなる
これは非常に大きい。
ファシリテーター「この1週間で今後もKeepしたいと思ったことを挙げていきましょう！」 チーム全員「...」
このような状況が続きました。
こうなると、改善をするどころか「この1週間で何ひとつ上手くいったことはなかった」という空気をチーム全員で共有してしまうことになり、さらなる悪循環を生んでしまいます。
2. Problemについて議論しきれずに時間切れとなり、うやむやになってしまう
あるあるではないでしょうか？
毎週Problemはどんどん挙がってくるけど、限られた会議時間の中では解決策が出てこず、未解決のProblemだけが議事録の中で積み重なっていく。。
これもチームの雰囲気が悪化することを助長してしまいます。
3. 前回のTryを実行できたかを追うことができない
これは単純にKPTのやり方が下手なだけですが、毎回振り返りのたびに「KPTだからまずはKeepから...」となってしまうと、前回のTryを実行できたのか・その成果はどうだったのかという視点が抜けてしまいます。
特に、Googleドキュメント上で定例会議ごとの議事録にKPTを書き込んでいく方法を採っていたため、前回のTryを振り返るには前回の議事録まで遡る必要がありました。
これも改善の効果を大きく下げてしまいます。
なぜKPTを使いこなせなかったのか
KPTにまつわるこういった悩みの数々はなぜ起きたのか、尺の都合で細かくは取り上げませんが、以下のように考えてました。
- 振り返りの中でチームメンバーを承認しあう仕組みがない
- Keepを「チームとして良かったこと・Keepすべきこと」と考えてしまうと意見を挙げるハードルが高い。個人の学びをチームの学びにすることもできるはず
- 毎回の振り返りが毎週の議事録の中で分散してしまい、学びや課題が蓄積しない
KPTの代替策：CITKフレームワーク
ただただKPTの実践方法がまずかったというのも重々承知の上で、「これらを解決する振り返りの枠組みって考えられるだろうか？」という思いで実験的にやってみたのが、冒頭で取り上げたCITKでした。
- 👏 Clap：みんなで祝いたいこと・感謝したいこと・やってよかったこと
- 🤔 Issue：課題だと思うこと・解決策のアイディア
- 🧊 Icebox：話しきれなかったIssueの一時保存場所
- 💪 Try：Issueに対する解決策の案
- 👍 Keep：意識的に続けた方が良い習慣
- ✍️ Knowledge：将来に活きる学び
この6つの領域を持つホワイトボードを用意して、その上で付箋を貼ったり移動させたりをすることで、チームの改善に取り組みます。 （役目を終えたアイテムを片付けるためのArchiveという領域もあります）
READYFORはフルリモートの体制を維持しているので、私たちのチームではFigJamを利用してオンライン上で振り返りを行なっていました。
各領域の使い方
まずはそれぞれの領域についての説明です。
👏 Clap
みんなで祝いたいこと、個人的にやって良かったこと・学んだこと、嬉しかったこと・楽しかったこと、誰かに一言感謝したいこと などを書く
- チーム全体やお互いを承認して、良い習慣や言動を強化する
- Try、Keep、KnowledgeのタネになりそうなものはIssueに移す
- 振り返りのミーティングが終わったらすべてアーカイブに移して、テンションが上がらないときに見返す
🤔 Issue
何かを改善するアイディアの提案や解決が必要な課題など、みんなで話し合いたいことを挙げる
- 振り返りのミーティングの中で何かしら結論を出すか、Iceboxに移す
- 解決策の案が出たら：
- 次の振り返りまでに試せるのであれば、Issueとその案をTryの領域に移す
- すぐには試せないのであれば、Issueとその案を将来の教訓としてKnowledgeの領域に移す
- ミーティングが終わったらこのエリアに残っているIssueは全てアーカイブに移す
🧊 Icebox
ミーティング中に結論の出なかったIssueを一時保管
次の振り返りが終わるまでに必ず結論を出す
💪 Try
Issueとそれに対応する解決策の案を並べる
- 次の振り返りまでに解決策を試してみる
- 試した結果が出たら：
- 基本、アーカイブに移す
- 習慣化できそうなことはKeepに移す
- 問題を解決できなかったらその問題をIssueのエリアに戻して、再度解決策を話し合う
👍 Keep
意識的に続けたほうが良い習慣を並べる
- ちゃんと続けることができているかを点検して、改善が必要な習慣はIssueにする
- 意識しなくても続けられるほど定着した習慣、仕組みに組み込まれた習慣、続ける意味がなくなった習慣はアーカイブする
✍️ Knowledge
- すぐには試すことができない解決策や効果的だったけど習慣化できない解決策など、振り返りで得られた学びを記録しておく
- エリアがいっぱいになったら社内wikiに学びを書き込んで、カードはアーカイブに移動する
📦 Archive
使い終わったカードを残しておく（定期的に整理）
振り返りの流れ
このボードを使って、以下のような流れで振り返りを行います。
みんなでClap
みんなで祝いたいこと、個人的にやって良かったこと・学んだこと、嬉しかったこと・楽しかったこと、誰かに一言感謝したいことをシェアする
ここが重要です！ お互いやチームを承認する時間であり、個人の学びをシェアする機会でもあります。
「みんなが健康だった」「体重がちょっと減った」のような内容でも書き込みやすい雰囲気を作りましょう。
TryとKeepの見返し
- 前回決めたTryの結果はどうだったか？ - Keepを続けられているか？
このボードで前回も振り返りをやったなら、きっとTryやKeepの領域に付箋があるはずです。 そこを確認して、振り返りのメンテナンスをしましょう。
できていないTryや結局解決しなかったIssueがあったら、Issueの領域に移しておきます。
Issueを出し合う
- 今をもっと良くする方法はないか？ - 解決が必要な課題はないか？
KPTでProblemやTryの意見を出し合うのと同じです。 また、Clapの中で「この学びはチームで活かせそうだよね！」というものがあったら、Issueに移動しておきます。
Issueについて議論
- どうすればもっと良くなるか？ - 何を試せば前に進めるか？
これはKPTでProblemを見ながらTryを考える時間と同じです。 Issueを解決するにはどうすれば良いかをみんなで話し合います。
もしClapから移動してきた付箋があったら、どうしたら個人の学びをチームのTryにできるかを考えます。
挙がったIssueが多い場合は各自でシールやアイコンをつけると良いでしょう（私たちの場合はFigmJamの+1アイコンをつけています）。
クリーンアップ
ClapとIssueを空にする
大きな特徴です。ClapとIssueは毎回きれいに片付けます。 話しきれなかったけど重要なIssueはIceboxに入れて、次回に持ち越します。
これによって散らかりがちなホワイトボードの付箋の数を抑え、必要な付箋はストックします。
CITKによる成果と結び
これによってチームの振り返りが劇的に改善した！！！
という締めくくりができれば良かったのですが、まだまだ発展途上のフレームワークです。
- Iceboxに付箋が溜まってしまう
- なかなかTryを日々の業務で実践できない
などなど、課題はたくさんあります。
しかし、Clapにより確実にチームの雰囲気は良くなりましたし、何が課題なのかを見失うこともなくなりました。 このフレームワークを使った振り返りによって
- 「人に聞かないと手が止まりそう」となったらSlackのHuddleを提案する・迷ったら言う（今ダメならいつ大丈夫かについて話す）
- 口頭で話しているとき、大事なことは話しながら Slackにスレッドを作ってメモしよう
- 月曜日までにマージできそうか？を朝会で聞こう（火曜終わりのスプリントで動いています）
などの習慣も生まれました。
これからも振り返り力向上のためにいろいろな工夫を行なっていきます。アップデートがあったらまた発信するので、ぜひREADYFOR Tech Blogをウォッチしてくださいね！
最後にCITKのチートシートを付録として貼っておきます：
明日はプロダクトエンジニアs-moriさんの投稿です！お楽しみに！
*1:継続寄付はプロダクトマネージャー2人体制で開発しました。どのような役割分担で進めたかは @laura_koの記事でご覧いただけます：tech.readyfor.jp
