この記事は、アソビュー！ Advent Calendar 2024の18日目（表面）です。

はじめに

こんにちは。アソビューの新規事業開発チームでバックエンド開発を担当している進藤です。今回は、半年ほど前に結成された開発チームがスクラムのふりかえり手法として取り入れているFun, Done, Learn（以後FDL表記）についてご紹介します。この記事では、FDLを実際に導入して感じたメリット・デメリット、さらに私たちが行った工夫（+α）についてお伝えします。

簡単に経歴をお話しすると、私は昨年まで某SIerで10年間Javaエンジニアとして、ウォーターフォール型開発（以後WF表記）を中心に経験を積んできました。WFでは、要件定義からリリースまでが直線的で予測可能なプロセスを重視しますが、アソビューにジョインしてからはアジャイル開発やスクラムの手法に触れることで、これまでと異なる開発の魅力や課題に気づきました。特に、半年ほど前から配属している新規事業開発チームでは、その新規事業という特性上、スピード感を持った意思決定と適応力が求められる中で、スクラムの「ふりかえり」プロセスの重要性を実感しています。

FDL（Fun,Done,Learn）について

FDL（Fun, Done, Learn）は、2018年のScrum Coaches Retreat in Okinawaで提唱されたふりかえり手法です。スプリント終了後、チームが以下の3つの視点からふりかえりを行います。

Fun（楽しかったこと）: チームメンバーのモチベーションや喜びに焦点を当てる
Done（達成したこと）: チームや個人が成果として得たものを確認する
Learn（学んだこと）: スプリント中の経験から得た知見や改善点を共有する

この手法の最大の特徴は、そのシンプルさと柔軟性にあります。具体的な進め方は以下の通りです。

付箋を使った意見出し：各メンバーがスプリント中に感じたことや達成したことを付箋に書きます。
ボードへの貼り付けと共有：Fun、Done、Learnの3つのカテゴリに分けて、付箋をボードに貼ります。付箋を貼る際に、他のメンバーにその内容を説明します。（もし可能であれば）発表を聞いているメンバーは、発表している付箋に対しスタンプを押すなどリアクションすると尚良しです。
議論を通じた共有と次のアクションへの展開：カテゴリ間の重なりを含めて議論を深め、スプリント全体を俯瞰します。

多くのチームが採用しているふりかえり手法のひとつにKPT（Keep, Problem, Try）があります。（私自身アジャイルとその実践のためのフレームワークとしてのスクラム歴がまだ1年弱のためKPT以外の経験がないのですが）、ここではKPTとFDLを比較してみます。全体的にFDLは感情的にポジティブな側面に重点を置いているため、新しいチームや心理的安全性が低いチームでも導入しやすい手法と言えます。一方、改善点の具体化という点では、KPTほどの強みはありません。

手法	特徴	メリット	デメリット
KPT	成功事例（Keep）、問題点（Problem）、改善案（Try）に分けて振り返る	課題解決志向で具体的なアクションプランが生まれやすい	問題解決に集中しすぎて、チームの感情面やモチベーションが軽視されることがある
FDL	楽しさ（Fun）、達成（Done）、学び（Learn）に分けて振り返る	感情面を含む広い視点で振り返ることで心理的安全性が高まり、チームの一体感が醸成される	問題解決や具体的なアクションプランが生まれにくいことがある

ここからは、チームのふりかえりとして実際にFDLにトライしてみたうえでの気づきについて書いてみようと思います。

実際に導入してみて気がついたこと

気づいたメリット

ファジーさが思考を促す

チームとしてふりかえりを実践するとなれば、どんな手法であってもコミュニケーションは必要です。しかしFDLの場合（個人的な感覚ですが）、ふりかえりの場に提供されるスプリント内の取り組みや挑戦に対する実績・所感・提案といった情報よりも、それを発信している個人によりフォーカスが当たっている印象があります。私たちが行なっていたFDLはKPTと違って、「これはKeepです、次はProblemです、最後にTryです」といったようなカテゴリ毎の区切りがありません。一人ずつリレー方式で、書いた付箋を「どのカテゴリなのか」「カテゴリの中のどの位置なのか」を説明しながら貼り出していきます。

別の人の付箋が自分ならもう少し別の位置かもしれない、カテゴリが違うかもしれないという思考が、好きな場所に貼れるというファジーさによって自然と生まれやすいのです。「なぜこの人はこう考えるのか、それはなぜ自分とは違うのか」などの感想をもとに気になったポイントを全員で共有し、チームとしての改善アクションや継続するべきアクションを導き出していけることがFDLの強みのひとつです。

楽しい雰囲気の醸成

Funカテゴリを設けることで、チーム全体がポジティブな雰囲気が生まれる感覚がありました。ふりかえりがただの業務報告や問題提起の場ではなく、「楽しい時間」として認識されることは、チームの参加意欲を高める要因になります。特に新しいメンバーが加わったばかりのタイミング（私のチームではUIデザイナーがプロジェクトの途中から参画しています）や、心理的安全性が十分に醸成されていない初期状態においては、Funカテゴリが緊張感を和らげ、会話のきっかけを生む役割を果たしてくれました。

さらに、このFunカテゴリは、業務に直接関係することだけでなく、業務外での出来事や些細な喜びも付箋に書き出せる点が特徴です。例えば、「モンハン新作、割と発売日もうすぐで歓喜」や「防災グッズを備蓄し始めた」といったプライベートな内容が共有されることで、チームの空気が一気に和やかになります。この柔らかい雰囲気が、結果的に他のカテゴリでの発言のしやすさにもつながっていると感じました。ただし、楽しい雑談ばかりに偏るとふりかえり本来の目的が薄れてしまうため、各メンバーが一定のバランスを意識することも重要です。

メンバーの個性が見える

各メンバーが感じた「楽しいこと」や「学んだこと」を共有する中で、業務上のスキルや成果だけでは見えない一人ひとりの個性が明らかになる場面が増えました。たとえば、「各画面に検索パネル設置したことでよりサイトらしくなった」といったコメントから、チームメンバーのモチベーションの源泉が垣間見えたり、「精算周りの有識者と有益な意見交換ができた」という発言から、学びへの意欲が伺えたりします。

これらの発言は、普段の業務中には意識しづらい「チームメンバー個人の人間性」や「価値観」を共有するきっかけとなり、自然とお互いへの理解が深まります。こうした理解は、業務遂行時のコミュニケーションを円滑にするだけでなく、信頼関係の構築にも寄与します。

心理的安全性の向上

FDLのふりかえりでは、直感的でポジティブな要素を中心に議論が進むため、メンバー間の心理的安全性が保たれつつも、本質的で率直な意見交換がKPTよりもスムーズにできていると感じました。特にFunやDoneといったカテゴリは、個人の努力や達成を認め合う場となり、自然とチーム全体に温かい雰囲気が広がります。このような環境では、意見を述べたり、感じたことを率直に伝えたりすることへの心理的なハードルが低くなります。

心理的安全性の向上がスプリント全体の成果にどのように影響したのかを短い紙幅で証明することは難しいですが、チームメンバーの発言頻度が増え、議論が活発になった点は顕著でした。これにより、スプリント中に気づいた改善点や課題がスムーズに共有され、結果的にプロセス全体の質が向上しました。たとえば、「プルリクのマージが良いタイミングでできず後続のタスクの変更がうまく進められないことがある」といった意見が、ふりかえりを通じて初めて出てくるケースもありました。

また、心理的安全性が高まることで、「質問や相談がしやすい環境」が整い、スプリント中の不安や問題を早期に解消する流れが自然と生まれました。これが結果的に、チームとしての一体感やプロジェクトへの集中力を高める効果を生んでいると感じます。また、これは最初から意図していた効果ではないのですが、私のチームでは毎週実施されるふりかえりをWikiのひとつのページに過去分も含め履歴として残しています。集まる会によっては、ボードに貼り出されていく付箋が特定のカテゴリに偏るタイミングが何度かあり（リリース前の追い込み時期など）、これは印象としても「チームが同じ方向を向くことができている」ことを視覚的に強める効果がありました。

気づいたデメリット

具体的なアクションプランに結びつけにくい

FDLは感情的なふりかえりに焦点を当てる特性があるため、次のスプリントで具体的に何を改善すべきかが明確になりにくいケースがありました。導入したばかりの初期段階ではたとえば、「楽しかったこと（Fun）」や「達成したこと（Done）」を共有する時間が盛り上がる一方で、「具体的な改善点をどのように実行するか」についての議論が手薄になる場面が見られました。

この傾向は、ふりかえりが抽象的な内容で終わりがちな場合に顕著です。たとえば、「タスク管理がうまくいかなかった」というLearnの意見が出たとしても、それを「どう解決するか」という具体的なアクションプランにまで落とし込むプロセスが不足してしまうことがありました。その結果、同じ課題が次のスプリントでも繰り返されるリスクがあると感じました。

また、Funカテゴリで共有されたポジティブな内容に引きずられて、議論のフォーカスが「改善」よりも「楽しさ」の共有に偏ってしまう場合もあります。これにより、ふりかえりが「気持ちをリフレッシュする場」としては有効でも、「プロセス改善の場」としての役割を果たしきれないという課題が浮かび上がりました。

ネガティブな意見が出にくい

FDLの特徴である「楽しい雰囲気」は一方で、ネガティブな意見を出しにくくする要因にもなり得ます。心理的安全性が高いと感じられる場であっても、人というのは課題や不満を自分からストレートに発信することに慎重になる心理があります。特に、ポジティブな話題が中心となるふりかえりでは、課題を指摘することが場の空気を壊すのではないかという懸念は想像に難くありません。

たとえば、「特定のタスクでのコミュニケーションが不足していた」や「進行が遅れてしまった」という指摘が必要な場合でも、それを表す適切なカテゴリがないことや、それを言い出しづらい空気が存在することもあります。このような状況では、課題が表面化しないまま次のスプリントに進んでしまい、結果的に大きな問題に発展するリスクが生じてしまいます。

チームでFDLのデメリットをどのように改善したか（+αの部分）

FDL+α: 「P（Problem）」の導入

これらのデメリットに加えFDLの強みのひとつにファジーであることが思考を促すことがメリットであると書きましたが、曖昧さを一定許容していることによって認識を揃えることにそれだけ時間もかかります。これらの克服するため、私たちのチームではFDLに「P（Problem）」を追加しました。

このカテゴリを通じて、スプリント中に感じた課題や改善点を明確化し、次のアクションプランに結びつけることを可能としています。FDLそれぞれのカテゴリに対するメンバー間の共有とは別に数分から10分程度を時間を設け、Problemの付箋もボードに貼り出していきます。書き出す内容がFDLと関連づいているかどうかについては制限を設けていません（これには現段階で特に明確な理由はありません）。

最終的に出揃った付箋の中からチーム全体もしくはメンバー個別に掲げるネクストアクションを洗い出し、次のスプリントでのTry事項としてボードに書き出しておきます。

P（Problem）を加えた効果

このオリジナルな改善によって、クイックに前回のスプリントから今回のスプリントへの連続性が生まれ、スプリントごとの学びが具体的な行動に反映されるようになりました。チーム全体で課題を共有することで、例えば若手エンジニアが自主的に日報を書き日々のタスクの見える化を実践し、遅れやタスクの取りこぼしがないか意識化する習慣が生まれたり、リリースまでの作業手順をドキュメント化することで定型的な作業に対するメンバー個別の判断から生まれるケアレスミスを軽減する動きが活発になる、という具体的なネクストアクションが生まれました。

最後に

スクラムを日常的に実行、推進していくためにはいくつものプロセスやテクニカルタームが存在し、今回は1単位の作業期間（スプリント）を振り返る（スプリントレトロスペクティブ）手法のひとつとして、FDLの実践例をご紹介しました。弊社プロダクト部でもチーム毎に行なっているふりかえり手法は様々で、別の記事になっているものもありますのでご興味があればぜひ読んでみてください。 tech.asoview.co.jp

数ヶ月間FDLを実践することによって、メリットであるチーム一体感の醸成と心理的安全性の高いチームビルディングを享受するとともに、オリジナルの要素としてPROBLEMの要素を追加する試みがありました。これにより次のスプリントでの具体的なアクションプランを検討する機会を設けることができ、手元の作業のみならず長期間に渡るチーム開発としての効率性を意識しつつ業務に取り組めるようになったと実感しています。

現在アソビューでは「生きるに、遊びを。」をミッションに、一緒に働くメンバーを募集しています！ご興味がありましたらお気軽にご応募ください。 www.asoview.com

speakerdeck.com