こんにちは！kintoneのAndroidエンジニア、トニオ（@tonionagauzzi）です。
この記事は、CYBOZU SUMMER BLOG FES '24 Agile/Scrum Stage DAY 2の記事です。
私がこれまで実践してきたスクラムにおけるふりかえり（レトロスペクティブ）で心がけてきたことについてお話しします。
はじめに
この記事で取り扱う範囲
この記事では、私が今まで実践してきたふりかえり手法4つそれぞれの強みと感想を説明します。
一般論ではなく、私が今までに実践してきたやり方なので、すべてのチームにそのまま適用できる形とは限りません。しかし、新しく始める際のヒントにはなるのではないかと思います。
「ふりかえりのベストプラクティス」みたいな一般論は、この記事では取り扱いません。
私とふりかえりの出会い
私がはじめてふりかえりに参加したのは2018年ごろで、前職でスクラムチームに初参加したのがきっかけでした。
そのチームではスクラムに関する勉強会や読書会を積極的に開いており、中でもふりかえりはあらゆる手法を試していました。その中で、独自の手法 OPT やCLK-GTR も生まれました。
今思えばふりかえりに力を入れていたチームで、そのチームはなんでも遠慮せずに話して行動を変えていける強みがありました。私もその影響を受けて多くのことを学びました。
最近のふりかえり事情
転職後も引き続きスクラムを実践しています。もともとは対面で行っていたふりかえりですが、今は基本的にリモートワークなので、Miroを使ったオンライン通話でのふりかえりに移行しています。
前職と同様にチームで試行錯誤を重ねました。最初はKPTを使っていましたが、徐々に手法を変え、現在のSDAという手法に落ち着きました。各手法については、後ほど詳しく説明します。
一方で、今年の Regional Scrum Gathering Tokyo (RSGT) のセッション「ふりかえりカタログをみんなで一緒に作ろう！」を視聴して、世の中にはたくさんのふりかえり手法があることを知りました。
実際、自分たちのチームにとってどんな手法がベストなのかは答えが出ていません。今の状態はベターだと思いますが、今後も状況の変化に適応したり、色々な手法を試していきたいと思います。
それでは、各ふりかえり手法の説明を始めます！
KPT (Keep/Problem/Try)
KPTは「Keep, Problem, Try」の略です。ふりかえりの基本的な手法のひとつで、以下の3つをチームで話し合います。
| 項目 | 説明 |
|---|---|
| Keep | 継続すべきこと。うまくいったことや、今後も続けたいことを挙げます。 |
| Problem | 問題点。改善が必要な点や、うまくいかなかったことを挙げます。 |
| Try | 試したいこと。次のスプリントで試してみたいアイディアや改善策を考えて決めます。 |
KPTの良いところは、シンプルでわかりやすい点です。
はじめてふりかえりを行うチームや、まだスクラムに慣れていないチームにとっては取り組みやすい手法です。
ふりかえり手法で迷ったらKPTを導入することも多いです。
私の経験では、KPTを使うと 「今のままでよいこと」と「改善したいこと」の両方を各個人がチームに伝えられること、そしてチームとして具体的なアクションプランを立てやすいことだと感じました。
YWT (やったこと/わかったこと/次にやること)
YWTは「やった、わかった、次やりたい」の略です。この手法では、以下の3つの観点からふりかえります。
| 項目 | 説明 |
|---|---|
| やった | 成功したことや達成したことを挙げます。 |
| わかった | 学んだことや気づいたことを挙げます。 |
| 次やりたい | 次に試してみたいことや改善策を考えて決めます。 |
YWTの良いところは、ポジティブなフィードバックを重視しつつ、学びを次のアクションに繋げられる点です。
KPTばかりで単調に感じたり、問題点が少なくなってきたときに現状を理解するために取り入れたことがあります。
私の経験では、YWTを使うことでメンバーがどのような成功体験やモチベーションを感じているかを知れて、メンバー同士の理解が深まり、成長につながる前向きなアクションを決めやすいと感じました。
象/死んだ魚/嘔吐
Airbnbの共同創業者、ジョー・ゲビア氏が提唱した手法です。この手法は少しユニークで、以下の3つの観点からふりかえります。
| 項目 | 説明 |
|---|---|
| 象 | チーム全員にとって既知の、規模が大きい問題や課題を「象」に例えて挙げます。 |
| 死んだ魚 | チーム全員にとって既知の、緊急性が高い問題や課題を「死んだ魚」に例えて挙げます。 |
| 嘔吐 | チーム全員にとっては未知の、個人が抱えるストレスや不満を吐き出す場として使います。 |
象は、大きくて目立つので最初は全員が気にしますが、見慣れると誰も口に出さなくなります。
慣れてしまって見ないふりをしている事実を取り扱います。
死んだ魚は、象と違って時間が経つと悪臭を放つので、早めに処理する必要があります。
このまま放置しておくとまずい問題を取り扱います。
嘔吐は、個人が内面に抱える問題意識や気持ちです。吐き出すまで、周囲の人は気付きません。
普段の業務で話せていないことを取り扱います。
この手法の良いところは、チーム内の隠れた問題やストレスを表面化できる点です。
「いつかやらなければ…」「いつか話したい…」と思っている問題を取り扱うことができます。
また、課題を何か別のものに例えることで、メンバー同士が責任を押し付けあうことを防ぎ、チーム全員で課題と向き合おうという一体感が感じられます。
私の経験では、この手法を使うことでチームメンバーが本音を出しやすくなり、各メンバーの不安を解消し、安心して課題と向き合える効果がありました。
SDA (Share/Discussion/Action)
私たちが現在使っているフォーマットです。SDAは「Share, Discussion, Action」の略です。最初に共有したいことを貼って、その中から話したいことを選び、具体的なアクションに繋げます。
以下の項目をファシリテーター（以下、ファシリ）主導で順番に進めていきます。
| 項目 | 説明 |
|---|---|
| 最優先司令 | 最初に、定形文を読み上げます。 |
| 🙌やったー🙌 | 喜びを感じたことを挙げます。 |
| 共有したいこと | チーム内外で議論したこと、実験したこと、何かに対する感想、メンバーへの感謝などをざっくばらんに挙げます。 |
| 話したいこと | 共有したいことの中から「話したい！」と思ったものを、誰でも自由に移します。移し終えたら、どれから話すかをファシリが決めます。 |
| アクション | 話したいことを話す中で結論が出たら、アクションを書いて貼ります。 |
最優先司令について
「どんな道をたどったにせよ、当時の知識・技術・能力・利用可能なリソース・状況の中で、みんなができる限り最高の仕事をしたはずです。それを心から信じます。」という文章です。Project Retrospectivesの著者、Norman Kerth氏が提唱したものです。
（出典：https://kawaguti.hateblo.jp/entry/2018/09/06/125428 ）
メンバー全員がそれぞれの思う最良の結果を目指して賞賛に値する仕事をしたという前提を最初に口に出しておくことで、「これから仕事に対して低い評価を受けるかもしれない」「意見を出したいけど批判として受け取られるかもしれない」などといった不安を無くして、意見を出しやすくします。
🙌やったー🙌について
「小さな成果でも祝福し、自分たち自身で成功を認めるようにしましょう。自分の周りの人に、あなたはすばらしいと伝えましょう。みんなの仕事を認めましょう。毎日、毎週、毎年です。あらゆる困難な状況で、ポジティブさは大きな違いをもたらします。」という文章は、アジャイルリーダーシップ（著書：Zuzi Sochova氏）の複数箇所からの引用です。
🙌やったー🙌の時間は、アイスブレイクとしてリラックスするために行います。また、日々の業務に追われる中で忘れがちな小さな感謝を周りの人に伝える時間としても機能します。
話したいことの選び方
話したいことを選ぶ際、移す作業は、だいたい1分以内に行います。移し終えたら、必要に応じて投票や確認をしつつ、ファシリが話す順番を決めます。
このやり方は「リーンコーヒー」に似ていますが、票数で選ぶのではなく、ファシリが順番を最終決定するところに違いがあります。票数で決めれば単純明快なのですが、「これは話したらすぐに結論が出そうなので、先に話そう」とか「これは2週連続で話せていないから優先度を上げよう」などといった臨機応変な判断は、人間のファシリだからこそできるのだと考えています。
SDAの効果
SDAには、個人で抱えている課題をチームに対してオープンにし、課題について考えることを全員に促す効果があります。一方で、話題が課題ばかりに偏らず、ポジティブフィードバックも出やすいように工夫しています。
私の経験では、この手法を使うことで時間内に具体的なアクションがいくつか定まるようになりました。
チームをまたいだふりかえりで使うと、互いのチーム内の出来事を共有できます。実際、社内で複数チーム合同のふりかえりをする際にもこの手法が使われており、限られた時間内で多くの人の意見を集めつつ、具体的なアクションを決めることができています。
SDAを始めた経緯
元はアジャイルコーチの天野（@ama_ch）が発案し、全体ふりかえりと呼ばれる複数チーム合同のふりかえりで使われていた手法でした。
私のチームでは他の手法を先に試していましたが、時間内に話しきれない話題が増えてきて、翌週持ち越しになったまま改善の熱が冷めてしまうことがありました。それを防ぐため、「円卓会議」という名を冠したふりかえりの延長戦をしていた時期もありました。
そこに新しく加わったメンバーから「決められたタイムボックス内でもっと具体的なアクションを決めたい」という意見が挙がりました。それを受けて社内で使われているSDAに変えてみたところ、延長戦になる前にアクションが定まる効果があったため、この方法に落ち着きました。
ふりかえりで心掛けていること
ここからは、手法の話から離れて、私がふりかえりで心掛けていることをお話しします。
健全なふりかえりとはどんなふりかえりか。私は、過去の遺産や他のメンバーの仕事・意見には敬意を払いつつ、これから改善や成長をしていくために必要なことを話し合って決められていることだと思います。
それを実現するために私が気をつけていることとしては、以下があります。
敬意を伝えながら本心を出す
ふりかえりの目的はチームの改善や成長なので、気づいたことはできるだけ言葉に出せると良いですが、一方で伝え方も気をつけないといけません。
過去の古いコードをけなしたり、個人を評価したり、人を傷つけるような発言があるとチームの士気が下がってしまいます。
しかし、私も誤解していましたが、ポジティブなことしか言わないのが良いわけではなく、言いにくいことでも深刻に受け取られないように言えたほうがよいのです。
たとえば、「この取り組みが失敗して残念」という意見を出す場合、ネガティブな表現だけでは、そこまで残念に感じていない人は共感しづらいでしょうし、最善を尽くして行動した人が責められたように感じることもあります。
そこで、「みんな頑張ったはずだけど、残念ながらこの取り組みは失敗だった」と、行動したことには敬意を示すような表現ができていると、「そう、最善を尽くしたんだけどね」「どこがどうだったらよかったのかな」と、共感を得やすくなるうえに要点を話すことができます。
うまく傾聴する
自分と違う意見の人に対して、傾聴し、共感することも大事です。
同じ結果を見て、「失敗して残念だ」と落ち込む人がいれば、「この程度は失敗ではない」と思っている人、「失敗だけど学んだ」とポジティブに捉える人もいます。
いろんな感じ方をする人がいて、一部の人が意見を主張したままにしておくと、「この人はどうしてマイナスにばかり考えるんだろう」「失敗を認めたく無いのかな」みたいな疑問が残りかねません。
疑問を疑問のまま残しておくと、「相手にそう思われたくない」からと顔色を伺って仕事するようになり、心理的に安全とは言えない状態になってしまいます。
そうならないように、「なぜ失敗したと感じたか」「なぜ残念だと感じたか」を話し合い、相手から自分と違う意見が出てきたら背景を聞き出すことが重要です。
本人の意見をしっかり傾聴すれば、「感じ方の違いはあれど、学びを次に生かしたいという気持ちは全員共通である」といった健全な方向に話が進みます。
自分と違う意見に無理して同意する必要はありません。相手に共感し、一部だけ同意できる部分があるとわかれば、それだけで具体的な次のアクションに繋がるのです。
伝え方や聞き方も重要です。同じ言葉でもひとりひとり受け止め方は異なります。結成して間もないチームだと最適な言葉をかけづらいものです。
チームワークを続けていく中で、徐々に信頼関係が生まれ、「安心して言う/聞く」バランス感覚をみんなで身につけていければ良いと思います。
細かいTips
他に心がけていることとしては、以下があります。
1. 安心できる環境を作る
チームメンバーが評価や批判を恐れずに安心して場に参加できるよう、ルールの合意やアイスブレイクなどを最初に行います。
2. 目的を明確にする
ふりかえりの目的を明確に決め、共有しておきます。たとえば、改善点を見つけて次のスプリントで活かすなどです。ふりかえりが不満をぶつける場所だと思われたりしないように気をつけます。
3. タイムボックスを守る
あらかじめ時間を決め、その時間内で話し合いを終えるようにします。時間を守ることで集中力を保ち、効果的な議論ができます。
4. 発言をスルーしない
ふりかえりで取り扱えなかった議題や少数派の意見も、必ず一言は口に出した上で翌週に持ち越すことを決めます。「ちゃんと聞いてもらえる」という安心感が生まれ、メンバーの士気の低下を防ぐからです。
5. 具体的なアクションを設定する
ふりかえりで出た改善点やアイデアは、具体的なアクションプランを忘れず設定します。誰が何をいつまでに行うのかを明確にすることで、次のスプリントでの実行可能性が高まります。
6. 良かった点にも目を向ける
ポジティブなフィードバックと改善点のバランスを取ることが重要です。失敗や課題ばかりでなく成功したことや良かった点もふりかえり、チームの士気を高めます。
7. ファシリの役割を明確にする
ふりかえりをスムーズに進行させるために、ファシリの役割を明確にします。ファシリは議論が偏らないようにしたり、自分自身が議論に熱中して進行が疎かにならないようにし、全員が発言できるようにサポートします。
8. バリエーションを持たせる
毎回同じ形式でふりかえりを行うとマンネリ化する可能性があります。さまざまなフォーマットや変化を取り入れて、メンバーの関心を引き続けたり、ふりかえり自体を改善・成長させていきます。
さいごに
私が参加するスクラムのイベント（Scrum Masters Night!など）でも、ふりかえりの話題はよく出ます。
多様な個性を持つメンバー同士がチームワークをしていく中で、ふりかえりはチームの成長に欠かせない重要なプロセスだと感じています。
ふりかえりがマンネリ化していないかどうか、ちゃんと機能しているかをときどきしっかりと考え、現在のチームに合った方法を模索しながら、より良いふりかえりを目指していきたいと思います。
以上、私が実践してきたふりかえりの手法と普段心掛けていることを紹介しました。
皆さんのチームでふりかえりをする際に、参考にしていただけると嬉しいです！
