アジャイルにおいて開発の過程や成果を振り返ることは、チームの改善につながる大切な行動です。とくにスクラムにおいては、スプリントごとにレトロスペクティブ（retrospective、ふりかえり）のイベントを実施します。ふりかえりのフレームワークといえば「KPT」がまず思い浮かびますが、実際にはチームの状況やふりかえりの目的に合わせて、さまざまなレトロスペクティブの手法をチョイスするのが望ましいでしょう。
それでは具体的にKPT以外ではどんなフレームワークがあり、それぞれチームがどのような状態のときに用いると効果的なのでしょうか。ブログに「自分がレトロスペクティブで最初はKPTをやるけどそのうちやらなくなる理由」という記事を執筆したソフトウェアエンジニアの大金慧（@bayashimura、ばやし）さんと、その記事で引用された講演資料の発表者で長年エンジニアリングマネージャーを務める小田中育生（@dora_e_m、いくお）さんに、それぞれのふりかえり体験やおすすめの手法について語り合っていただきました。
- そのうちKPTをやらなくなったのはなぜ？
- KPTのネクストステップにおすすめしたいふりかえり手法
- ふりかえりで「見えていなかったリスク」も可視化できる
- ふりかえりのファシリテーションで大切にすべきこと
- いま読みたい注目記事
そのうちKPTをやらなくなったのはなぜ？
── お二人は、ふりかえりにはKPTだけではなく他の手法も取り入れるべきだとブログや講演で指摘されています。なぜそう考えるようになったのでしょうか。
大金さん（以下、ばやし） 5年ほど前の前職での経験ですが、ずっとKPTでふりかえりをしているとどうしても同じプロブレムばかり出るようになり、「これ毎回出ますね」という暗い雰囲気が漂うこともありました。そのころ、たまたま『アジャイルレトロスペクティブズ』という本を読んで「ふりかえりの手法ってめちゃくちゃ種類があるじゃん！」とレトロスペクティブの奥深さに気付かされたのがきっかけです。
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
オーム社小田中さん（以下、いくお） 私も10年前くらいに前職で似た経験をしました。当時、チームのスピードや開発力は申し分なく、メンバー間の関係性もよかったため、ばやしさんとは逆にプロブレムがあまり出てこなかったんです。そのうち「この時間は意味がないんじゃないか」ということになりそうでしたが、ふりかえりは健康診断みたいなものなので、できれば止めたくなかった。それなら視点を変えてみてはどうだろうと考えました。
YWT・Timeline・学習マトリックスをまず試してみた
── 別の視点として実施した手法は何だったのでしょうか。
いくお 試したのは「やったこと」「わかったこと」「次にやること」で振り返る「YWT」です。たまたまそういった方法があると耳にしたので実践してみたのですが、最初は「単にKPTを言い換えただけじゃない？」と、手法を変えて本当に意味があるのか半信半疑でした。ところが実際にやってみるとこれまでになかった意見がたくさん出てきて、視点を変えるだけでこんなに違うのかと驚きました。
YWT：株式会社日本能率協会コンサルティング（JMAC）が、1990年代に開発した「技術KI計画」によるKI活動のなかで生み出された手法。Y（やった）・W（わかった）・T（次にやる）をシートに整理して定期的に実施する。
JMAC公式の用語集「YWT（やったこと・わかったこと・次にやること）」などを参照。
それから、ばやしさんと同じ『アジャイルレトロスペクティブズ』を手にとって、こんなにもたくさん手法があるのかと衝撃を受けました。
ばやし 私は、その本にも紹介されている「Timeline」という手法を試しました。それまで出てこなかった意見も出てきて「面白いな」とそのときに感じたことで、さまざまな手法を試すようになりました。そのうちレトロスペクティブそのものが楽しくなり、今では「KPTしか使わないのはもったいないな」と思います。
Timeline：長期のプロジェクト期間などに起きた事実と感情の両方を時系列に沿って書き出して、チームで共有する。書籍『アジャイルレトロスペクティブズ』『ふりかえりガイドブック』などで紹介されている。
いくお Timelineは私も試してみました。特定のメンバーしか知らなかった事実が明らかになったり、あるメンバーにとってポジティブなことを別のメンバーはネガティブに捉えていたことが分かったりしましたね。
それから「学習マトリックス」を試してみると、普段は恥ずかしくてなかなか伝えられないチームへの感謝が出てきて、そこからポジティブなフィードバックが生まれたこともありました。ふりかえりでは課題を抽出して解決するだけではなく、チームの絆を作る効果もあるんだと気付かされました。
学習マトリックス（The Learning Matrix）：4分割した領域にそれぞれ🙂（よかったこと）・😞（改善が必要）・💡（新しいアイデア）・💐（感謝の言葉）を記入して感情や経験を共有する。書籍『アジャイルレトロスペクティブズ』に掲載。
ファシリテーションを別の人に任せるメリット
── ふりかえりではお二人自身がファシリテーターを務めることが多いのでしょうか。
いくお 私は早い段階で他のメンバーにファシリテーターを任せました。ファシリテーターを務めることで当事者意識も生まれるし、新しい視点も入るからです。ファシリテーターを1回でも務めた人は、その後のふりかえりですごく協力的になるんですよね。だから、メンバーでファシリテーターを一巡させると、チームとして前に進みやすくなるんです。
ばやし 同じく、今はファシリテーターをどんどん変えて実践しています。前職で最初のころは私がずっとファシリテーターをしていましたが、自然と「改善リーダー」や「レトロスペクティブリーダー」みたいな役回りになってしまって。それは他のメンバーの興味関心や当事者意識を奪っているんじゃないかと気付いたのです。それからはファシリテーターを持ち回りにしたり、ランダムにしたりしました。すると皆が新しい手法を持ってきてくれたりして、ふりかえりが盛り上がるようになりました。
── お二人が手法を試していたころ、アジャイルコミュニティで同じような動きもあったのでしょうか。
いくお どうでしょう。現在はふりかえりの第一人者として『アジャイルなチームをつくる ふりかえりガイドブック』の著書もある森一樹（@viva_tweet_x）さんと、そのころ『アジャイルレトロスペクティブズ』の話をしたこともありました。なので興味を持っている人は当時からいたように思います。
アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット
翔泳社KPTのネクストステップにおすすめしたいふりかえり手法
── お二人とも現在は「使えるふりかえり手法」を何種類くらいお持ちでしょうか。
ばやし ストックは10種類くらいです。KPT、Timeline、Lean Coffee、帆船のふりかえり、Starfish、象・死んだ魚・嘔吐、Mad Sad Grad、闇鍋、Like to Like、死亡前死因分析などですね。
いくお 使えることを「再現性をもって効果がある」とするなら、Lean Coffee、Fun/Done/Learn、学習マトリックス、YWT、Timeline、Small Starfish、熱気球、象・死んだ魚・嘔吐、Celebration Grids、帽子の交換で、私も10種類くらいですね。KPTも使いますし、自分で作ったりもします。
ばやし 新しい手法を作るのはすごいですね！
いくお 前職で「既存のふりかえり手法が現場にフィットしない」という課題があって。「なければ作ればいいじゃない」という発想ですね。汎用性はないかもしれませんが、自分たちだけの手法を作るのはそんなに難しくないし、愛着もわくのでおすすめです。
── 使える手法としては、KPT、Timeline、Lean Coffee、帆船のふりかえり（熱気球）、Starfish（Small Starfish）、象・死んだ魚・嘔吐の6つが共通しているんですね。
Starfish ─ KPTに近くプロブレムの解像度が高まる
── それぞれストックのなかで、KPT以外を初めて試すチームにおすすめの手法は何でしょうか。
ばやし まず「Starfish」でしょうか。なぜKPTがこんなに人気なのかを考えると、おそらく業務改善につなげたい気持ちが強いからだと思うんです。KとPで問題を抽出して、Tで改善につなげる。それが「仕事のふりかえり」として分かりやすいですし、シンプルなフレームワークだからファシリテーターの負担もそんなに大きくありません。Starfishなら、そういったメリットを踏襲できます。
Starfish：実施しているプラクティスなどをKeep（続ける）・More of（増やす）・Less of（減らす）・Start（始める）・Stop（止める）の5つに分類する。考案したパトリック・クア（Patrick Kua）のブログや「ふりかえりカタログ」などを参照。また、Small Starfishはこれを前半のKeep・More of・Less ofの3つだけにアレンジしたもの。
参考：The Retrospective Starfish – thekua.com@rest
一方で、KPTのように問題を直接的に抽出するだけでなく、何かを「増やす」あるいは「減らす」という視点が入るところが違いますね。問題に対して「減らせるのか」「減らしていいのか」という会話が発生することもあり、KPTにはないアイデアが出てくる手法です。
いくお 私もStarfishはおすすめします。というのも、プロブレムに対する解像度が高まります。単に「プロブレム」というと「とにかく取り除かないといけない」と認識しがちですが、Starfishではもっと多様なアプローチが出てきます。問題に対するアクションに踏み込みやすい点が優れていますね。
それから先ほど挙げた「YWT」でしょうか。KPTと枠組みが似ているのでハードルも低いし、切り口を変えるだけで物事の捉え方がこんなにも違ってくるんだという驚きを体験できるのでおすすめです。
Lean Coffee ─ 自由テーマの会話から自分たちを知る
── 何かしらKPTと似た手法が続きましたが、KPTとは違う考え方でおすすめの手法はありますか。
いくお 厳密にいえばレトロスペクティブの手法ではありませんが「Lean Coffee」をおすすめします。メンバーが話したいテーマを出し合って投票しますから、チームで気になっているテーマが可視化されます。それぞれのテーマを話す時間は7分に制限されていて、時間になったらいったんストップして会話を続けるか次のテーマに移るかを決める。かなり自律性が求められるフレームワークです。
Lean Coffee：話題をカンバンで整理し、時間を限って順に会話するアジェンダのない会議形式。リーン技術について語り合いたかったジム・ベンソン（Jim Benson）とジェレミー・ライトスミス（Jeremy Lightsmith）が、2009年にシアトルのコーヒーショップで毎週水曜日の朝活として始めた。「Lean Coffee」や「What is Lean Coffee?」を参照。
Lean Coffeeは明確なゴールを求める手法ではありませんから、スプリントレトロスペクティブで「次にすべきこと」を明確化するには向きませんが、内省（reflection）を促すのには適したフレームワークです。
ばやし たしかにLean Coffeeは、KPTのような一般的なふりかえり手法とは考え方が異なりますから「KPTのネクストステップ」としてはハードルが高いかもしれませんが、私も有用な手法だと思います。
というのも、ふりかえりでとらわれがちな「次のアクションを決めなければいけない」という考え方から脱却してもいいのではないかと考えるからです。自分たちは何を考えているのか？ チームのメンバーはどう思っているのか？ 業務改善だけでなく「お互いのことをもっと知ろう」という時間を作ることも必要です。
いくお ふりかえりとは「最終的に次のアクションを出すものだ」という思い込みを解き放つ意味でも、どこかのタイミングでLean Coffeeを行ってみるのはいいかもしれませんね。
ばやし そのテーマを続けるかどうかを7分で決めるのも、フレームワークとしてよくできています。KPTでも「長々と同じプロブレムの話をしたけれど結論は出ませんでした」ということはよくありますから。しかも熱く話しているのは2人だけで、他のメンバーは見ているだけだったりという状態を避けられます。
ふりかえりで「見えていなかったリスク」も可視化できる
── 先ほど小田中さんが言われた「内省に適している」とはどういうことでしょうか。
いくお スプリントレトロスペクティブとは、そもそもスプリント期間に何が起きたのかを「検査」して望ましいこととそうでないものに分け、その後も受け入れて進むか取り除くのかを決めて「適応」するスクラムイベントです。つまり、自分たちがより効果的に活動できるようになるために最も役立つ変更を選び取ることがゴールなのです。
そういう意味で「ふりかえり」と「レトロスペクティブ」という言葉にも違いがあります。ふりかえりはレトロスペクティブより広義で、リフレクション（内省）も含めたものになります。Lean Coffeeなどの手法では、自分たちが思っていることやモヤモヤしていることをぶつけ合い、感情面を深く掘り下げることができます。そのため最終的なアクションにはつながらないかもしれませんが、自分たちの状態を言語化して共有する「リフレクション」には向いているわけです。
── なるほど。この記事ではどちらも取り上げたいですね。ここからはお二人がおすすめの手法を、どんな状況で用いるべきかもあわせてご紹介ください。
帆船のふりかえり ─ チームの目線を合わせる
ばやし 私がおすすめしたいのは「帆船のふりかえり」です。チームの目線がバラバラになっていると感じたら試してみてほしい手法です。他に「熱気球」や「スピードカー」といった構造は同じだけどメタファーが違う手法もあります。
帆船のふりかえり（Sailboat Retrospective）：チームを帆船に見立て、島（ゴール）・追い風（推進要因）・錨（阻害要因）・岩（リスクや障害）の絵を用いた視覚的なメタファーで整理する。ベリンダ・ウォルドック（Belinda Waldock）が2012年にイノベーションゲームとして実施した。先行する手法にルーク・ホーマン（Luke Hohmann）の「Speed Boat」があり、また熱気球（Hot Air Balloon）などのメタファーも使われる。手法の詳細は『ふりかえりガイドブック』に掲載。
いくお 私は熱気球のメタファーを使うことが多いですね。めちゃくちゃおすすめです。
ばやし 帆船のふりかえりでは、チームの「ゴール」はどこなのかという視点がまずあります。最初にゴールを決めるやり方もありますが、私が実施するときにはメンバーそれぞれにゴールを決めてもらい、その障害となる「錨」や、逆にチャンスとなる「追い風」をあげていきます。意外なことに、ぜんぜん違うゴールや錨や追い風があがることがよくあります。KPIの向上がゴールだと考える人もいれば、品質向上をゴールだとするメンバーもいて、チームの目線がそろっていないことを再確認させられます。
いくお 私の場合は、チームがゴールを達成するなどして区切りを迎えたときに使うことが多いですね。というのも、現代の開発だと基本的にひとつのプロダクトをずっと開発し続けるのが一般的です。つまり、あるゴールを迎えた後は、すぐ次のゴールを目指すことになります。このタイミングで帆船（熱気球）のふりかえりを用いると「次はどこを目指すのか」「何がリスクになるのか」といった認識を共有できます。
達成思考型の方は「追い風」をたくさん思い付いてくれるし、リスク回避型の方は「課題」を見付けてくれる。リスク回避型が「追い風」を知ると「それならこのリスクは気にしなくていいね」と考えることができ、逆に達成思考型が「錨」を知って「クリアされないと困る課題」に気付けることもあります。メンバーそれぞれの得意を生かして、ゴールに向かう共通認識を作れることがメリットです。
Celebration Grid ─ 失敗と成功のふりかえりから次に向かう
いくお 個人的な推しは「Celebration Grid」です。チームが得た学びを祝い合って、そこから学んでいくフレームワークです。マトリックスの横軸を「振る舞い」とし、縦軸を「振る舞いの結果」として、それぞれが成功か失敗かを分類して振り返ります。面白いのは「振る舞いとしてはやらかしたけど、結果オーライだった」とか「行動は良かったが、結果は失敗に終わった」というようにさまざまなケースが出てくることですね。
Celebration Grid：チームの活動をPractices（実践）・Experiments（実験）・Mistakes（ミス）の3カテゴリで成功と失敗に分類し、それぞれから得られた学びを称賛する。ユルゲン・アペロ（Jurgen Appelo）が提唱する「Management 3.0」フレームワークのプラクティスとして開発された。『ふりかえりガイドブック』に掲載されている。
ばやし 名前は知っていましたが、具体的には初めて知りました。いい手法だと思ったので試してみたいです。
いくお ぜひ！ この手法はチームの体制が新しくなったなど、大きな変化があったときに活用すると、安心して新しいチャレンジに向かいやすくなるので気に入っています。
注意点としては、人はやはり結果が失敗していると振る舞いについても失敗に分類したくなるので、始める前にフレームワークの意図をしっかりメンバーに伝えたほうがいいかもしれません。一度は失敗に分類されたものでも、ファシリテーターが理由を説明して分類し直してもいいと思います。
Like to Like ─ カードゲームのように楽しめる
ばやし 私が大好きなのは「Like to Like」です。遊びを取り入れた、カードゲームみたいな手法です。
Like to Like：ボードゲーム「アップル・トゥ・アップル」をベースとし、用意した性質（quality）カードに対して各参加者が書いた3種3枚ずつ計9枚のカードをどれか提出し、性質カードに最適なカードを選ぶことでチームの理解と共感を促進する。『アジャイルレトロスペクティブズ』で紹介された。
参考：Retromat「Like to like」
まず性質カードといって「おぞましい」とか「天才」みたいなワードをいくつか用意します。さらに「やめたいこと」「続けたいこと」「新しくやりたいこと」などの行動カードも用意して、場に出た性質カードに対して自分が思う行動カードを出します。するとメンバーそれぞれが「どんな行動をどんなふうに思っているのか」が可視化されます。ボードゲーム感があって、すごく楽しいですよ。
ただし、準備も大変だしルール説明も必要なので、余裕がないときや改善すべきことがある場合にはやめたほうがいいでしょう。中長期的にチームを強くしたいときや伸ばしていきたいときに、チームの相互理解を進めたり雰囲気をポジティブにしたりするのに効果的だと思います。
帽子の交換 ─ 別のロールの立場で考えてみる
いくお 私からは次に「帽子の交換」をおすすめします。これは同僚の椎葉光行（@bufferings）さんが考案した手法で、帽子とは「ロール」のこと。自分が「その立場だったらどう考えるか？」を話し合う手法です。
チームにはエンジニアだけでなくEMやPdM、デザイナーなどさまざまな立場の人がいます。例えばPdMがエンジニアの帽子をかぶって、ある技術的課題を出してきたとします。このときPdM自身は、その課題の難易度が高いと思っていたりするわけです。
それに対してエンジニアが「難しい課題に取り組むのは自分たちの仕事なので、そこは心配しなくて大丈夫ですよ」と共有する。つまり、仕事をするなかで「勝手に相手のことを想像して遠慮していた部分」を意図的に共有する場を設けるわけです。これにより、リアルな声や大きな気付きが得られます。
これはリモートワークでも有効です。現職のチームはフルリモートで関西や北海道など広範囲にメンバーが散っているため、なかなか物理的に集まれません。そうなると、近くにいれば感じられる「空気感みたいなもの」もなかなか分からなかったりします。結果としてPdM・エンジニア・デザイナーなどのメンバーがそれぞれ別のことに没頭してしまうこともあります。そんなタイミングで「帽子の交換」は効果を発揮します。
ばやし 私の現職もフルリモートなのでお互いに遠慮してしまうところはありそうです。この手法はフィットしそうだと感じました。
死亡前死因分析 ─ もしもこの取り組みが失敗するとしたら
── ばやしさんは独自に作った手法などはありますか。
ばやし それはありませんが、一般的にレトロスペクティブには用いられてなさそうで独自に取り入れたものとしては「死亡前死因分析（premortem）」があります。ダニエル・カーネマンの『ファスト＆スロー』で語られていた手法ですね。計画の実行前に「自分たちの計画が失敗したとして、なぜ失敗したかを考える」ことでリスク要因を探る手法です。
例えば「1週間休みをもらって戻ってきたら、開発チームが青ざめた顔でバタバタしていました。何が起きていたかまとめてください」みたいな質問を投げかけて、ディテールまで細かく書いてもらいます。それによって単一障害点であったり、セキュリティ対策の甘さ、なんとなく心で思っていたけれど隠れていたリスクを炙り出すことができます。これは「うまくいっていると思っていても、実際にはリスクがあるんだ」ということを認識してほしいタイミングで実践すると効果的です。
死亡前死因分析：プロジェクト開始前に失敗を仮定し、その原因を特定する手法。ソフトウェア開発では、チームが開発計画やリリースの失敗要因を想定し、潜在的なリスクを事前に洗い出して対策を講じることができる。ダニエル・カーネマン（Daniel Kahneman）が著書『ファスト＆スロー あなたの意思はどのように決まるか？』で紹介した。
象・死んだ魚・嘔吐 ─ なかなか言い出せないことを語り合う
ばやし 似た手法には「象・死んだ魚・嘔吐」もあります。レトロスペクティブでは、たくさんの課題を大量に片付ければいいわけではありません。すぐには解決できないくらい大きいけれど見過ごせない課題（象）に着手するファーストステップとして、すごくいいフレームワークだと思います。
象・死んだ魚・嘔吐（Elephants, dead fish & vomit）：組織が抱える課題を、象（大き過ぎて見て見ぬふり）・死んだ魚（放置するとまずい）・嘔吐（胸中のこと）の3つの観点から見つける。Airbnbが創業当初のコミュニケーション危機に対処するため共同創業者のジョー・ゲビア（Joe Gebbia）が導入した経緯が、書籍『Airbnb Story』に紹介されている。
── 本来ならふりかえりではない死亡前死因分析のような手法を取り入れるのは面白いですね。
ばやし ふりかえりに何を求めるかですね。例えば、チームを理解したりポジティブなマインドにしたりするのが目的であれば、キックオフで実践するようなチームビルディング手法を取り入れてもいいと思います。
いくお 死亡前死因分析については、私は「ふりかえり」ではなく、プロダクトのリリース前に実践することが多いですね。ばやしさんがおっしゃるように、レアケースだけど起きたらまずいリスクを見つけるのに非常に有効です。それをふりかえりとして使うのは、たしかに面白いと思いました。
闇鍋 ─ 意外なテーマから意外な学びが
ばやし それから、ぜひ紹介したいのは「闇鍋」です。私のブログは吉羽龍太郎（@ryuzee）さんの「なぜスプリントレトロスペクティブでKPTをお勧めしないのか」という記事に触発されて書いたものですが、闇鍋はそのryuzeeさんが考案されたフレームワークです。
自分の名前を書く闇鍋と書かない闇鍋がありますが、私は書かないほうが好きです。KPTで「誰が書いたか」が注目されて、例えば影響力が大きなリーダーが提示したプロブレムが話されがちだったりしますが、闇鍋では誰の話題か分からないし、意外なテーマから意外な学びがあったりしてすごく面白いんです。
いくお オンラインではどうやって誰が書いたのか分からなくさせるのでしょう？
ばやし 弊社ではレトロスペクティブでFigJamを使っています。そのため少し手間はかかりますが、他の人に見えないところで話したいテーマを付箋に書き、上から同じ色の図形を重ねます。場に集めて並べ替えてシャッフルし、重ねた図形を取り去ります。
いくお ツールやルールを工夫するのは面白いですね！
通信簿 ─ まとまった期間のふりかえりに
── 小田中さんからもう一つご紹介いただいてもいいでしょうか。
いくお それでは最後に、私が考案した「通信簿」という手法を紹介します。ここまで紹介してきたフレームワークはスクラムチームのスプリントレトロスペクティブで使われるもので、スプリントの周期（1〜4週間程度、もっと短いチームもある）で実施しますが、たまに3ヶ月くらいのまとまった期間について振り返りたいことがあります。そんなときにおすすめです。
やり方は学校の通信簿と同じで、まず評価したい対象を列挙します。そして、それに対して皆で「大変よくできました」「よくできました」「がんばりましょう」のように評価するわけです。その上で、なぜそう思ったのかを話し合い、評価に対する共通見解を生み出します。
ポイントとしては、長期間で起きる認識の違いを明らかにできることです。例えば、とにかく期日通りにリリースできたから「大変よくできました」と思っている人もいれば、リリース直前にバタバタしたからプロジェクトマネジメント観点では課題を感じたという人もいるわけです。
ばやし 長期間のふりかえりでは、私はTimelineを使います。3ヶ月とかの長期になるともう最初のころのことなんて覚えていないので、まず「何が起きたのか？」を時系列で抽出する必要がありますから。
KPTが適している場面と注意すべきポイント
── 最後にKPTについてお聞きします。今回のテーマは「KPTからの脱却」ですが、だからといってKPTがよくない手法というわけでもありませんよね。
ばやし はい。KPTがシンプルで強力なフレームワークであることは間違いありません。ただ、最初に言ったようにプロブレムという言葉がどうしても強く、そこに引っ張られがちです。
いくお まだふりかえりをやったことがなかったり、課題が顕在化していたりする状態ならKPTが適していると思います。課題を見つけてアクションにつなげやすいですし、フレームがしっかりしているので「そろそろ次にいきましょう」というように時間を読みやすいこともメリットです。
ただ、どうしても解決しやすい課題から取り組むことが多くなると思います。難易度が高くてトライしにくい課題よりも、効果が小さいけれどすぐに成功体験を生める課題ばかりに終始する恐れもあります。
ばやし 課題を抽出して改善して解決するKPTのマインドは、日本人のメンタリティ的にも相性がいいと思うんですね。だからこそ「プロブレムを絶対に解決するぞ」という姿勢になってしまうと、解決できない課題が溜まってつらくなりがちです。
KPT：ソフトウェア開発を含むさまざまな活動の実施後に、K（Keep）・P（Problem）・T（Try）の3つで整理するフレームワーク。アジャイルソフトウェア開発宣言の執筆者の1人でもあるアリスター・コーバーン（Alistair Cockburn）が著書『アジャイルソフトウェア開発』（2002、ピアソン・エデュケーション）で紹介した「反省会の出力サンプル（sample poster from reflection）」をもとに、永和システムマネジメントが2000年代前半から「KPT（けぷと）」として「ふりかえり」で使用したところから日本国内に広まった。An Agile Way「KPTを使ったプロセス改善」などを参照。
ふりかえりのファシリテーションで大切にすべきこと
── 手法を変えたとしても、ファシリテーションとして変わらないところはありますか。
ばやし 「ノーム・カースの最優先条項（the prime directive）」ですね。これは「今日見つけたものが何であれ、チームの全員が、その時点で分かっていたことやスキルおよび能力、利用可能なリソースを余すことなく使って、置かれた状況下でベストを尽くした、ということを疑ってはならない」という考え方です
ノーム・カース（Norman L. Kerth）が著書『Project Retrospectives: A Handbook for Team Reviews』において提唱した「Retrospective Prime Directive」は、ふりかえり（レトロスペクティブ）において責任追及ではなく学習と改善を促進することを目的としている。ふりかえりの場を心理的に安全なものとするため、冒頭でこの条項が共有される。
課題を解決するために、人のモチベーションやスキル、持っている情報など、コントロールできない部分を後から責めたところでどうにもなりません。それより「構造でどう変えるのか」にフォーカスすべきです。
いくお 同感です。ふりかえりで課題が出てくると、人は「これは怠惰の証である」と思いがちです。でもそうなると課題を出しにくくなりますよね。それなら「ベストは尽くしたけれど、それでも転ぶのが人である」という考えを前提にして、その上で「起きた課題は全部吐き出そうよ」という空気を作ることが大事です。
── どうしても怒りたがりの人がチームにいるような場合はどうすればいいでしょうか。
いくお マネージャーの立場としては、自分が率先して失敗を開示したり、どうしてもパワーを持っている人がいる場合は申し訳ないけれど事情を伝えて場から外れてもらったりしています。その場にいる皆が「エラい人」だと認識している人が先に失敗を共有することも大切ですね。
── ありがとうございます。今日はお二人からたくさんの手法を紹介いただきましたし、リフレクション（内省）とレトロスペクティブの違いなども勉強になりました。
いくお 明確に検査と適用を行うスプリントレトロスペクティブと、アクションを求めず内省することも含める「ふりかえり」の違いですね。内省することで効果的に検査ができることもありますし、無理にアクションを出そうとしなくていいこともあります。ただし、ふりかえりが「会話だけの時間」になっていないかというチェックは必要です。ときには「ふりかえりのふりかえり」も大事ではないかと思いますね。
ばやし 私も「ふりかえりのふりかえり」は行います。「この手法を皆は楽しんでくれたのかな？」とか「意味があると思ってくれたかな？」ということを認識するためにも、ふりかえりの最後に少しだけ時間をもらって参加したメンバーに感想を聞いたりしています。
── ふりかえり自体も改善していくことが大切なのですね。本日はありがとうございました。
取材・構成：山田井 ユウキ
編集・制作：はてな編集部
- 大金 慧（おおがね・けい） X: @bayashimura
- 信州大学大学院修了後、2015年にNTTコムウェア株式会社に入社。自動テストやアジャイル開発を推進し、アジャイルコーチも務める。2020年に転職してシステム開発の傍ら、開発プロセス改善やチームビルディングを行い、エンジニアリングマネージャーも務める。2023年11月、Linc'well株式会社に入社し、オンライン診療サービスのプロダクト開発に従事。チームリーダーを務める。
ブログ：ばやしのブログ
- 小田中 育生（おだなか・いくお） X: @dora_e_m
- 筑波大学大学院修了後、外資系半導体企業を経て、2009年に株式会社ナビタイムジャパンに入社。プロダクトや開発プロセスのカイゼンを推進しつつスクラムを積極的に導入し、VPoEを務める。2023年10月にエンジニアリングマネージャーとして株式会社カケハシにジョイン。2025年3月からHead of Engineeringを務める。著書に『アジャイルチームによる目標づくりガイドブック』（2024年、翔泳社）など。Developers Summit 2024 Summerベストスピーカー賞 2位、Developers CAREER Boost 2024ベストスピーカー賞 1位。
ブログ：dora_e_m｜note
