“なぜ？”で終わらせない！次の一手が見つかるPIVOT流振り返り術
こんにちは。PIVOTプロダクトチームのエンジニアをしている、楠瀬（@indiamelaaa）です。
突然ですが、一年の終わりにやることといえば、皆さんは何を思い浮かべますか？
…そうですね、振り返りですよね！
仕事でもプライベートでも、「この一年、何があったか」を振り返る機会が増える時期かと思います。
今回はそれにちなんで、私たちが最近新しく作った「プロジェクトの振り返りの型」についてご紹介しようと思います。
チームの規模が大きくても小さくても応用できる方法ですので、ぜひ参考にしてみてください。
背景
PIVOTでは、2024年11月にWeb/iOSアプリのホーム画面を大幅にリニューアルしました。
（2024年12月にAndroidもリリース済み）
これは開発チームにとって大きなチャレンジでしたが、無事にリリースすることができ、ユーザーからもさまざまな反応をいただきました。
しかし、プロダクトをより良くし続けるためには、「何がよかったのか」「何がうまくいかなかったのか」を改めて整理し、具体的な改善策をチーム内で共有する必要があります。
これまでも振り返り自体は行っていたものの、プロジェクトの振り返り手法が定まっていなかったため、
振り返りのたびに「どうやって進行すればいいのか」を毎回ゼロから考えなければいけない
問題点や成功事例を出すだけで終わり、ネクストアクションが曖昧なまま閉会してしまう場合がある
振り返りのクオリティにばらつきがあり、「再現性」が低い
といった課題がありました。
そこで、今後のプロジェクトにも活かせるように振り返りを仕組み化・テンプレート化しようという話になり、作成に至ったのです。
振り返りの目的
振り返りの型を決めるにあたり、まず考えたのはプロジェクトにおける「振り返りの目的」でした。
私たちが考える、振り返りを行う一番の目的は、成功事例を再現できる形で残し、失敗や課題を次回に持ち越さないようにすることです。
ただ「やったね！」で終わらせるのではなく、具体的なアクションを導き出してメンバー全員が行動を変えられる状態を目指そうと考えました。
そして、私たちはこの目的に沿うように、振り返りのテンプレートを決めました。
振り返りテンプレートの概要
Miroというツールを使用して、振り返りを行なっています。
今回作成したテンプレートのイメージが、こちらの画像になります。（拡大してご覧ください）
…パッと見てもわかりにくいですね。それぞれの項目に分けてご説明します。
テンプレートに含まれる主な項目
効果検証結果(左上)
私たちはプロジェクトごとに、どのような効果を得られたのかを検証しています。ここでは、リリース後の検証による数値変化などをまとめる欄です。
タイムライン(左)
時系列に沿って振り返る領域です。以下のように付箋の色を分けながらペタペタ貼っていきます。
黄色：当時の出来事や決定したこと （例：キックオフ、実装開始、リリース…）
ピンク色：うまくいったこと （例：設計段階で、適切な人に仕事を依頼して無駄な作業が少なかった）
青色：問題だと思ったこと （例：デザイン作業の中で仕様の落とし込み精度が低く、定義されていないことが多かった）
なお、「時間軸に関わらないもの」（画像中央）は、プロジェクト全体を通して感じた「うまくいったこと」「うまくいかなかったこと」を記入する場所になります。
Why → 次回PJに活かすアクション(右)
タイムラインの「うまくいったこと」「問題だと思ったこと」の付箋を深掘りする領域です。
それぞれのトピックについて「なぜうまくいったのか」「なぜ問題だと思ったのか」を深堀りし、そこから次回のプロジェクトでどんな行動を取るかを具体化するための欄を用意しています。
振り返りの進め方
上記のテンプレートを使用した、振り返りの進行について解説します。
1. 事前準備
振り返りの役割を決めます。私たちのチームでは、どの役であっても、誰でも担当できるようにしています。
ファシリテーター（進行役）
議事録係
タイムキーパー
ファシリテーターは、テンプレートから新しいフレームを作成し、以下の内容を記載します。
効果検証の結果
当時の出来事
うまくいったこと
問題だと思ったこと
ファシリテーターはチームメンバーに対してMiroのリンクを共有し、チームメンバーは「うまくいったこと」「問題だと思ったこと」を付箋で書き出します。
ここまでを事前に行っておくことで、当日は議論に十分な時間を割くことができます。
2. 当日の進行（目安：1時間）
ドット投票（5分）
チームメンバーが書き出した「うまくいったこと」「問題だと思ったこと」の付箋から、より深く話し合いたいものを投票で選びます。
投票の基準として、いいね的な感情にはドットを付けないようにしていて、あくまで「今後のプロジェクトに継続して活かせそうなもの」や「今後のプロジェクトまでに解決したいもの」に対してのみドットを打ちます。深掘りディスカッション（45分）
投票数の多いものから順に議論を進めます。話し合いたいトピックが決まったら、その付箋を右側（「うまくいったこと」「問題だと思ったこと」欄）へ移動し、さらに「Why → 次回PJに活かすアクション」へと流れるように深掘りしていきます。トピックが「うまくいったこと」の場合
なぜうまくいったのか（Why）を追求し、誰がやっても再現できる形がないか確認します。
再現性がなければ、どうすれば再現性を持たせられるか話し合います。
決定した対策を、次回のプロジェクトで試す具体策として明確にします。
トピックが「問題だと思ったこと」の場合
なぜ問題だと思ったのか（Why）を洗い出し、原因を掘り下げます。
どうすればその問題を起こさずに済むのか、具体的な改善策を考えます。
決定した対策を、次回のプロジェクトで試す具体策としてまとめます。
アクション決定 & クロージング（10分）
議論で出てきたアイデアを整理し、具体的なネクストアクションを決定します。その際、担当者やスケジュールも設定し、実行に移しやすい状態にすることが重要です。
この振り返りの型のポイント
一連の流れを俯瞰できる
タイムライン上に出来事を時系列で並べることで、プロジェクト全体の流れを一目で確認しやすくなります。
たとえば「どのタイミングで大きな仕様変更が入ったのか」「どのフェーズでコミュニケーション不足が起きやすかったのか」などを俯瞰できるため、ミーティングで「なんとなく覚えている」レベルではなく、具体的な事実に基づいた議論ができるようになります。
次のプロジェクトに活かすことにフォーカスした議論ができる
「なぜうまくいったのか」「なぜ問題が起きたのか」を深掘りするだけでなく、「再現性を持たせるには？」「どうやったら次回は同じ問題を起こさずに済むか？」といった問いをテンプレートに盛り込むことで、ファシリテーターの経験値に左右されずに、今後のプロジェクトへ直接活かせる改善策を引き出しやすくなります。
こうした仕組みがあることで、ディスカッションが目的に沿ったアクション決定へと自然につながりやすくなります。
ディスカッションにおけるTips
議論を深めていると、1つのトピックだけに時間をかけすぎて、ほかの重要な議題を消化できなくなることがありませんか？
私たちはそんな問題に対して、リーンコーヒー（Lean Coffee）方式を参考にしながら、以下のようなルールを設けて時間を管理しています。
(参考: Lean Coffee | Start one in your city!)
短い時間を設定
各トピックに対して短いタイムボックスを設定します。
私たちの場合、5分前・3分前・1分前の3つをタイムボックスを設定しています。「続けるか、次へ進むか」をその都度確認
最初は5分間議論を行い、時間が来たら、参加メンバーに「もっと話し合う必要があるかどうか」を確認します。
「まだ議論が足りない」という意見が多ければ次の3分間延長し、「そろそろ次へ進もう」という意見が多ければ次のトピックへ移ります。
3分間経過したら、再度話し合う必要があるか確認し、まだ必要という意見が多ければ、1分間延長します。まとまらない場合は後日改めて対応
時間を延長しても着地点が見えない場合は、別途ミーティングを設定し、改めて深掘りすることにしています。
このようにリーンコーヒー方式を取り入れておくと、限られた時間の中で複数トピックをバランスよく検討できるだけでなく、参加者全員が「いま何が必要なのか」を考えながら議論を進めやすくなります。
結果的に、優先度が高いテーマに集中しつつ、他の話題も公平かつ効率的に扱えるようになるのです。
おわりに
いかがでしたでしょうか。
まだこの型で運用して間もないのですが、実際に使い始めてから、目的に沿った議論をスピーディに行うことができていると感じています。
今後もこれをアップデートしながら、プロダクト開発のスピードと品質をより高めていきたいと考えています。
もし参考になったと思っていただけたら、ぜひこの型を活用してみてください。その際は、気づいたことをフィードバックをいただけると嬉しいです。
それでは、良いお年をお過ごしください。
最後までお読みいただき、ありがとうございました！