長期間のふりかえりって難しくないですか？ - tebiki Tech Blog

Jun Seida

Published in

tebiki-techblog

Nov 5, 2024

Tebiki株式会社で「tebiki現場教育」のプロダクトエンジニアを担当している清田です。

「tebiki現場教育」の開発チームではスクラムを導入しており、1週間のsprintごとにレトロスペクティブでふりかえりを行っています。

一方で、規模が大きい機能のリリース等をきっかけとして、sprintごとの短期間のふりかえりではなく、普段とは違う長期間のふりかえりをやる機会もあるかと思います。

我々のチームでも長期間のふりかえりを実施する機会があったのですが、そこで難しさを感じたと同時に学びを得たので、今回はその内容についてお話ししたいと思います。

事例1「スキルマップ開発全体のふりかえり」

実施の背景

「tebiki現場教育」にて新規機能であるスキルマップ機能が2024年春頃にリリースされました。

スキルマップ機能開発はこれまでの機能開発と比べて開発規模や不確実性が大きく、多くの課題を抱えながら開発を進めてきました。

また、機能検討から最初のユーザ公開に至るまで、半年以上の歳月を要した開発となりました。

sprintごとにふりかえりは行っていましたが、今回の対応を俯瞰して振り返ることで、新たな学びやTRYが得られると考え、スキルマップ開発全体のふりかえりを実施することになりました。

ふりかえりの目的

ふりかえりの目的は、前述の背景欄に沿ったものを設定しました。

スキルマップ開発全体を俯瞰して振り返ることで、sprintごとのふりかえりだと得づらい、学びや気付きを得ること
上記の学びを活かして、今後の機能開発をより良いものにしていくこと

ふりかえりの流れ

ふりかえりのアジェンダは以下のように設定しました。

「当日」
・全体で実施
　・ふりかえりの目的/流れの説明（5分）
・チームに分かれて実施   
　・タイムラインでのふりかえり（15分）
　　→タイムラインに沿って、事実とそれに対する感情を記入する
　・タイムラインの付箋に関して、感想/質問タイム（10分）
　・付箋のグルーピング（10分）
・全体で実施
　・両チームでグルーピングした付箋をマージする（10分）
　　→似ているグループをまとめる
　・今後、深堀りして話したいグループに対して投票（5分）
　・深堀りしたいグループ（ふりかえりのトピック）を3つ決定（5分）

「別日に実施」
　・深堀りトピックに対して、TRYを出す会を実施

まず、ふりかえり手法は、「タイムライン」をベースとしました。

「タイムライン」は我々のチームが普段のふりかえりで毎回使用している手法であり、慣れている手法の方がメンバー的にもふりかえりがしやすいだろうと判断し、こちらの手法を選択しました。

今回のスキルマップ機能においては、2つの開発チームが並行して開発を行っていたため、チームごとに分かれてタイムラインを作成しました。

また、振り返る期間は半年以上となっており、その場で思い出すのに時間がかかりすぎることを予想したため、ふりかえりの主催メンバーが主要なイベントの付箋を事前に貼っておくなどの工夫を行いました。

そして、大量のタイムラインの情報をそのまま扱うのは難しいため、一度付箋をグルーピングをしてから、深堀りをするためのトピックを抽出することにしました。

タイムラインの付箋からトピックを選択して深堀りを行うというのも、我々のチームが普段のふりかえりで毎回使用しているやり方でした。

今回のふりかえりは参加人数が多く、また長丁場になることが予想されたことから、選択されたトピックの深堀りは、別枠で時間をとることにしました。

結果

上記のふりかえりを実施後、主催メンバー内でトピックの内容を確認したのですが、今後の深堀りの仕方を決めるのに難儀しました。

「改めて深堀りの時間を取っても、新しい学びやTRYに繋がらない結果になってしまいそう」という懸念が生じたためです。

投票されたトピックは、過去のsprint中で何度も話題にあがったテーマであり、過去のふりかえりの焼き直しになってしまうことが予想されました。

結局、3つあるトピックのうち、1つのみを別会で深掘ることにし、残りの2つは実施を見送りました。

そのため、ふりかえりとしては「もっとうまくやれたのでは？」と悔いが残る結果となってしまいました。

要因としては、普段のふりかえりと同じアプローチでふりかえりを行っていたため、そこから得られた意見も同じになってしまったことが挙げられるかと思います。

当初は、ふりかえる期間を単純に伸ばせば、それだけでも新しい視点が得られると期待していましたが、実際はふりかえり方に更なる工夫が必要であることを学びました。

事例2「スキルマップの評価設定機能と習得状況機能の開発ふりかえり」

実施の背景

前述のスキルマップ機能のリリース後も、1つの開発チームで継続して機能追加を行っていました。

そして、今回はその機能追加のうち、おおよそ３ヶ月程度を要した「評価設定機能」「習得状況機能」の開発が終わったタイミングでふりかえりを行うことになりました。

ふりかえりを行った理由は、前述の事例と同様、俯瞰して振り返ることで新たな学びやTRYが得られると考えたためです。

ただ、ふりかえりを行うにあたって、前回の事例での反省点を踏まえたうえで、構成を練りたいと考えていました。

ふりかえりの目的

ふりかえりの目的は以下の通りに設定しました。

「評価設定機能」「習得状況機能」の開発完了を祝い、感謝を伝え合うことで、チームの士気を高めること
「評価設定機能」「習得状況機能」がビジネス環境にどのような影響を及ぼしたかを把握することで、今後よりビジネス価値の高い開発を行うための学びを得ること
「評価設定機能」「習得状況機能」の機能特性を把握し、今後の開発プロセスに活かせる気づきを得ること

まず、今回のふりかえりでは、「感謝」や「お祝い」の要素を入れました。

今までだと、各Epicの対応が完了しても、特に何事もなくチームの活動が進んでしまうことが多かったため、今回の区切りで上記の要素を盛り込むことで、チームの雰囲気をより良くしたいと考えました。

また、「開発した機能がどういう特性を持つものだったか」「開発した機能がビジネス環境にどのように影響を与えたか」といった事後的な情報を知ることで、新たな学びが得られると考えました。

ふりかえりの流れ

ふりかえりのアジェンダは以下のように設定しました。

・ふりかえりの目的/流れの説明（5分）
・「我々は顧客にどういった影響を与えたか？」を知る（20分）
・「我々が提供しようとした価値と解決策」について、振り返る（10分）
・「我々が実際に提供した価値とその方法」について、振り返る（10分）
・Win Learn Try（30分）
・感謝を送り合う（5分）
・ふりかえりの感想記載（3分）

まず「我々は顧客にどういった影響を与えたか？」を知るために、今回追加した機能へのフィードバックを社内のビジネスサイドの方々から集め、参加者同士で内容を確認しました。

フィードバックには、「顧客の変化」「社内のビジネスサイドの変化」「機能がこうなったらよかった」「今後、機能がこうなって欲しい」といった内容が記載されていました。

フィードバックを確認する中で、気づいたことや感想を付箋で貼っていき、学びを都度共有しました。