はじめに
プロジェクトが完了したとき、その経験を次に活かせるかどうかは、ふりかえりの質にかかっています。
私たちのチームではこれまでレトロスペクティブで「KPT」や「Mad/Sad/Glad」「+Δ」などを実施してきましたが、最後のふりかえりということもあり、今回は少し違うアプローチを試みました。Starfish（スターフィッシュ）と呼ばれるフレームワークです。
「続ける・やめる・増やす・減らす・始める」の5つの軸で振り返るこの手法は、KPTよりも行動への解像度が高く、具体的なネクストアクションに落とし込みやすいのが特徴です。
本記事では、実際にStarfishを使ってふりかえりを行った体験をご紹介します。
Starfishを活用したふりかえりの進め方
1. タイムラインの共有 (5分)
あらかじめ複数名でプロジェクトのタイムラインを作成しておき、ふりかえり参加者に共有しました。
これは、このあと実施する「実際にやったこと」の書き出しに向けた、思い出しのヒントにするためです。
2. 「やったこと・やってきたこと」の書き出し (15分)
次に、具体的なアクションを洗い出すワークに移ります。思い出し漏れを防ぐため、以下の6つのセクションを用意しました。
- スクラム
- 機能開発
- テスト開発
- CI/CD
- 開発全般
- その他
この15分間は、「出来事や感じたことを、とにかく書き連ねる」ことに集中しました。
最初から「これはKeepか？ Stopか？」と仕分けをしようとすると、筆が止まってしまいます。まずはフラットに事実を出し尽くすことで、チーム全員の記憶の解像度を高めるのが狙いです。
また、視認性を高めるため、付箋の色はセクションごとに分けて記載してもらいました。
ワーク実施後はこんな感じになりました。
日々の開発で当たり前に運用していたツールやライブラリ、PBI（プロダクトバックログ項目）のテンプレートに記載していたDoR（準備完了の定義）、DoD（完了の定義）の付箋が上がりました。
このように「当たり前にやっていたこと」をあえて事実ベースで可視化することで、「それは本当に必要だったか？」「期待した効果は得られていたか？」を、この後のステップで冷静に検証できるようになります。
3. 5つの観点へのマッピング (30分)
本来、Starfishは最初からこの5つの観点に沿って付箋を出し始めるのが一般的です。しかし今回はプロジェクトの締めくくりということもあり、あえて事前に「事実と出来事の書き出し」を行うステップを設けました。
ステップ2で洗い出した大量の付箋をチーム全員でディスカッションしながら、「Starfish」のフレームワークに基づいた5つのエリアに分類・マッピングしていきました。
- Keep Doing (続ける)：現在うまくいっており、次も継続したいこと
- More of (増やす)：価値があるので、さらに強化・頻度を増やしたいこと
- Start Doing (始める)：次から新しく取り入れたいこと
- Stop Doing (やめる)：価値を生まないため、即座に中止すべきこと
- Less of (減らす)：完全にはやめないが、かける労力や時間を抑えるべきこと
また各付箋に対して、「なぜそう感じたのか？」といった理由や「次はこうしたい」「こうするべきかも」といったアイディアについても議論し、次に向けたアクションを追記しました。
なおStart Doingについては付箋のマッピング後に意見出しを行ったものを追記しました。
実際にStarfishをやってみて良かったこと
1. 多様な視点からの議論ができた
KPTが3つの観点で整理するのに対し、Starfishは5つの観点で振り返ることができます。
そのため、KPTでは一括りになりがちな課題や改善案も、「やめるのか」「減らすのか」「新しく始めるのか」と切り分けて考えられました。また、うまくいっていたことも「続ける価値があるのか」「さらに強化したいのか」と整理しやすく、議論の方向性が明確になりました。観点が増えることで論点が拡散するのではなく、むしろネガティブに寄り過ぎず建設的に話を進めやすかったです。
2. Keep Doingで「なぜ良かったか」を言語化できた
Keep Doing は、単に「これを続けよう」と確認するための枠ではなく、「なぜそれが機能していたのか」を掘り下げるきっかけになりました。
日々の開発で当たり前に続けていた運用やコミュニケーションは、うまく回っているほど理由を言語化する機会が少なくなりがちです。しかし今回あらためて議論してみると、「この進め方があったから認識合わせがしやすかった」「このルールがあったから手戻りを減らせた」といった背景をチームで共有できました。
たとえば開発者レトロについても、単に継続したい取り組みとして挙げるだけでなく、心理的安全性の向上に寄与していたことをあらためて確認できました。
何を残すかだけでなく、何が良さにつながっていたのかまで認識をそろえられたことで、次のプロジェクトでも再現しやすい学びとして持ち帰れたと感じています。
3. More ofが「さらによくするには」に直結した
今回、特に次のアクションにつながりやすかったのは More of でした。
Keep Doing が現状の良さを確認する観点だとすると、More of は「それをさらに良くするにはどうすればよいか」を考える観点として機能しました。「この進め方は良かったから、次はもっと早い段階で取り入れよう」「このやり方は有効だったので、頻度や適用範囲を広げよう」といった形で、改善の方向性を自然に議論できました。
実際には、「PO受け入れ確認依頼のフローでは Slack のワークフローを活用する」等といった、次の開発ですぐ試せる改善案も出てきました。
4. Less ofで触りづらい運用も見直せた
Less of は、何かを単純に削るための観点というより、「続けるほどではないが、少し重い」「やり過ぎかもしれない」といった運用を見直すきっかけになりました。
今回も、プロダクトバックログに記載していた DoR（Definition of Ready: 準備完了の定義）や DoD（Definition of Done: 完了の定義）の項目について、「なくすべきか」ではなく「少し軽くしたほうがよいか」という形で議論を進めることができました。
こうした項目は、いったん運用に乗ると妥当性を見直す機会が少なくなりがちです。しかし Less of という枠があることで、続けること自体が目的になっていないかを確認しやすくなり、普段はテコ入れしづらい運用を現実に合わせて調整するうえでも有効だったと感じています。
まとめ
今回はプロジェクトの最後にStarfishを導入しましたが、定期的に実施することで、その時々の課題や改善の方向性をより早い段階で捉えられると感じました。
特に今回は、Keep Doingで良かった取り組みの背景を言語化し、More ofで次の改善アクションにつなげ、Less ofで普段見直しづらい運用にも手を入れられました。こうした点は、KPTよりも次の行動に落とし込みやすいStarfishならではの良さだったと感じています。
ふりかえりを「良かった」「大変だった」で終わらせず、今後もこうした場を継続しながら、チームとしての学びを次のプロジェクトに活かしていきたいです。
簡単30秒