ふりかえりを「テーマ選び」から設計する

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。

こんにちは。
kintone開発チームでスクラムマスターをしている、とうま(@toma_cy)です。

スクラムでは、スプリントごとにふりかえりを行います。 そのふりかえりの手法には、KPTやFun/Done/Learn、YWTなど、さまざまなフレームワークがあります。

フレームワークは話すきっかけを作ったり、意見を整理したり、次のアクションにつなげたりするうえで、大きな助けになります。

一方で、最近あらためて感じているのは、ふりかえりは「なんとなく決めたフレームワークを毎回使う場」ではないということです。

大事なのは、チームに今何が起こっているのかを見つめ、その状況に合った方法を選択することだと思っています。

この記事では、私が関わっているチームでの経験をもとに、ふりかえりをチームの状態に合わせることの大切さについて書いてみます。

とりあえず同じふりかえりを続けるだけでよいのか

チームが立ち上がったばかりのタイミングで、まずはKPTから始めてみる。
これはとても自然な始め方だと思います。

Keep、Problem、Tryというシンプルな構造はわかりやすく、ふりかえりに慣れていないチームでも取り組みやすいです。最初の一歩としては、とても良い選択肢です。

ただし、問題はそのあとです。

チームを取り巻く状況は変わります。
チームの人数、プロダクトのフェーズ、リリースの頻度、メンバー同士の関係性、開発プロセス上の課題など、日々少しずつ変化していきます。

それにもかかわらず、理由もなく同じフレームワークを使い続けてしまうと、ふりかえりが形骸化してしまうことがあります。

たとえば、チームのコミュニケーションがうまくいっていないとします。
本当はそこに向き合う必要があるのに、いつもの流れでプロセスやプロダクトの話だけをして終わってしまう。

それでは、目の前にある大きな問題を避けているようなものです。

もちろん、プロセスやプロダクトの話も大切です。
しかし、チーム内のコミュニケーションがうまくいっていない状態で、それらを建設的に話し合うのは簡単ではありません。

明らかに重要な課題があるのであれば、ふりかえりの時間をその課題に向ける。
これは、ふりかえりをより意味のある場にするために大切な考え方だと思います。

今のチームに必要なテーマを選ぶ

ふりかえりで扱うテーマは、スプリント単位の出来事に限らなくてもよいと思っています。

たとえば、次のようなテーマです。

  • 四半期が終わったタイミングで、少し長めの期間を対象にふりかえる
  • 大きめのリリースを行ったあとに、そのリリースに特化してふりかえる
  • チームビルディングに課題を感じているなら、相互理解を深める場として設計する

そういった選択肢も十分にあり得ます。

また、スクラムイベントとしてのふりかえりとは別に、専用の時間を取るという選択もあります。
そこはチームの状況次第です。

ただ、いずれにしても大切なのは、

今このチームにとって、何をふりかえることが一番価値につながるのか

を考えることだと思います。

リファインメントにフォーカスしたふりかえりを 5 回続けた話

実際に、私が関わっているチームでは、リファインメントにフォーカスしたふりかえりを 5 回連続で行ったことがあります。

そのチームでは、PBIをリファインメントする時間を、一定時間確保していました。
しかし、そのリファインメントのためのコミュニケーションがうまくいっていない状態でした。

具体的には、次のような課題がありました。

  • 必要な情報がそろっていない
  • PBIの内容があいまいなまま議論が始まる
  • 議論が収束せず、長時間話してしまう

この状態で、いつも通りのふりかえりをしても、根本的な改善にはつながりにくいと感じました。

そこで、リファインメントに特化したふりかえりを複数回行うことにしました。

毎回、リファインメントに関する課題を洗い出し、改善施策を考え、次に試してみる。
それを 5 回にわたって続けました。

もちろん、他の事柄への内省が手薄になってしまう可能性はあります。
ただ、その時のチーム状況を加味すると、必要なことだったと考えています。

リファインメントに対して集中的にふりかえりを行うことで、問題の輪郭が少しずつ見えてきました。
また、メンバーそれぞれがリファインメントに対して感じていることや、期待していることも明らかになっていきました。

その結果、単に「リファインメントの進め方を直す」だけではなく、チームとして何を大事にしたいのか、どこに認識のズレがあるのかを話すきっかけにもなりました。

この経験から、ふりかえりの価値は「毎回まんべんなく話すこと」だけではなく、今いちばん向き合うべき課題に対して、チームで対話できることにもあるのだと感じました。

ふりかえりから相互理解のワークショップへ

さらに、リファインメントにフォーカスしたふりかえりを続ける中で、別のテーマも見えてきました。

それは、メンバー同士が「お互いに何を期待しているのか」をもっと知りたい、ということです。

リファインメントのやりづらさは、単にプロセスや情報整理の問題だけではありませんでした。
チーム内での期待値や、コミュニケーションの前提が十分にそろっていないことも影響しているように見えました。

こうしたズレは、リファインメントの進め方を直すだけでは埋まらないので、お互いを理解し合うチームビルディングの要素が必要だと感じていました。

そこで、ふりかえりの結果を受けて、お互いを知るためのワークを行いました。
それぞれが大事にしていることや、チームメンバーに期待していることを共有し、相互理解を深める時間です。

もし、漫然とKPTを続けていたら、相互理解のワークにはたどり着けなかったと思います。

チームにとって重要な課題にアプローチするには、どんな場にするのかを意図的に考えるのが大切です。

ふりかえりを設計するときに意識したこと

ここまでは、「何をふりかえるか」というテーマ選びの話をしてきました。

ただ、扱うテーマを正しく選べたとしても、ふりかえりの場そのものがうまく機能していなければ、その課題に向き合うことはできません。 適切なテーマを選ぶことと、そのための場をつくることは、いわば両輪です。

目的が定まったら、次はそれをどう場に落とし込むかです。 ふりかえりは、目的を決めた瞬間に良くなるわけではなく、実際の進め方に落ちて初めて機能します。

進め方に関する、重要な要素をいくつか挙げてみます。

  • アジェンダ
  • ファシリテーション
  • ふりかえりのフレームワーク
  • ふりかえるためのツール
  • 時間の取り方
  • 参加しやすい場づくり

このうち、ここからは「時間・場づくり・ツール」の 3 つの観点に絞って、私が実際に意識していたことを紹介します。

というのも、私がジョインした当初、そのチームではふりかえりがあまり機能しておらず、まさにこの 3 つに課題があったからです。

たとえば、次のような状態でした。

  • 余った時間でふりかえりをしていて、おざなりになりやすい
    • 30 分も取れないことがしばしばあった
  • 議題を挙げる人が限定的だった
    • 議題を挙げるハードルが高そうだった
    • 使用しているツールや、場の雰囲気にも影響がありそうだった

ふりかえりの時間をきちんと確保する

まず取り組んだのは、「余った時間でふりかえりをしていて、おざなりになりやすい」という課題です。

余った時間でふりかえりを行うと、どうしても「残った時間でやるもの」という印象になります。

そうなると、メンバーが主体的に参加する意欲も下がりやすいですし、集中もしづらくなります。

そこで、ふりかえりは別途 1 時間の枠をしっかり取るようにしました。
まずは、ふりかえりをチームにとって大切な時間として扱うことにしました。

話し始めやすい小さな段差を用意する

次に向き合ったのは、「議題を挙げる人が限定的で、挙げるハードルが高そうだった」という課題です。

いきなり「課題を出してください」と言われると、心理的なハードルが高いことがあります。
特に、まだ場に慣れていない場合や、意見を出すことに慎重なメンバーがいる場合はなおさらです。

そこで、誰でも挙げやすいお題を用意しました。

たとえば、まずは「今スプリントでやったこと」を、どんな小さいことでもよいので挙げてもらう。
そこから本題のふりかえりに入っていく、という流れです。

これは、議題を挙げる行為の練習にもなります。

最初から大きな課題を出すのではなく、まずは簡単に乗り越えられる小さな段差を用意する。
それを少しずつ高くしていくことで、いつしか大きな段差も越えられるようになる。

ふりかえりに限らず、ワークショップを設計するときには、この考え方がとても大切だと思っています。

ツールも場づくりの一部として選ぶ

最後は、「使用しているツールや、場の雰囲気にも影響がありそうだった」という課題です。

私たちのチームでは、Miroを使うことで、気軽に付箋を出しやすいようにしました。

個人的には、リアルな場で集まり、わいわい話しながらふりかえるのがベストだと思っています。
ただ、リモートやハイブリッドの環境では、そうもいかないこともあります。

その点、Miroのようなツールは、現実の付箋ワークに近い感覚を作りやすいです。
アイコンの動きや、誰かが文字を入力している様子がリアルタイムで見えるので、「一緒に作業している」感覚が生まれやすいです。

場を温めるうえでも効果的ですし、ファシリテーションの観点でも役立ちます。

たとえば、付箋が出るスピードや参加者の様子を見ながら、時間を早めに切り上げるか、もう少し待つかを判断できます。
場の状態を見ながら進行を調整できるので、ふりかえりの効果を高めることにもつながります。

3 つの取り組みを経て

これらの取り組みを続けた結果、ふりかえりの様子は少しずつ変わっていきました。

以前は限られたメンバーしか意見を出していませんでしたが、今では多くの人が付箋を挙げてくれるようになりました。

1 時間の枠をしっかり取ったことで、重要なテーマについて深く議論できるようになりました。 また、今まで出てこなかったような問題提起や、改善アクションのアイディアも増えました。

もちろん、まだまだ改善の余地はあります。
それでも、以前と比べるとふりかえりの質は格段に向上したように感じています。

まずは「ふりかえりのふりかえり」から

チームにとって最適なふりかえりを選ぶには、チームに何が起こっているのかを観察し、冷静に分析することが大切です。

直近のスプリントだけを見るのではなく、これまでの流れを俯瞰してみる。
そのうえで、今チームにとって本当にふりかえるべき観点は何かを考える。

これは、とても価値があります。

とはいえ、日々の開発で忙しい中、ふりかえりそのものを見直す時間を取るのは簡単ではありません。
スクラムマスターがいれば考えやすいかもしれませんが、いないチームでは後回しになってしまうこともあると思います。

そこでおすすめしたいのが、「ふりかえりのふりかえり」です。

ふりかえりの時間を使って、ふりかえり自体について話してみる。

たとえば、次のような問いをチームで話してみます。

  • 今のふりかえりは役に立っているか
  • 話したいことを話せているか
  • いつも同じ話題に偏っていないか
  • 今のチームにとって、本当にふりかえるべきテーマは何か
  • やり方を変えるとしたら、どんな形がよさそうか

こうしたことをチームで話すだけでも、ふりかえりをより良くするきっかけになります。

いきなり大きく変える必要はありません。 まずは今のふりかえりがチームにとってどういう時間になっているのかを、チームで確認してみる。 それだけでも十分だと思います。

おわりに

ふりかえりのフレームワークは便利です。
KPTも、その他のフレームワークも、うまく使えばチームの改善を助けてくれます。

ただし、フレームワークを使うこと自体が目的になってしまうと、チームにとって本当に大切な課題を見逃してしまうことがあります。

ふりかえりは、チームに向き合う時間です。

  • 今、チームに何が起こっているのか
  • 何を話すことが、次の一歩につながるのか
  • そのためには、どんな場を設計するとよいのか

そういったことを考えながら、チームの状況に合ったふりかえりを選んでいきたいと思っています。

まずは一度、チームで「今のふりかえりってどうだろう?」と話してみるのはいかがでしょうか。