スクラムマスターが語るKPTの課題、なぜKeepからTryが出ない？#1 成功から学ぶAppreciative Inquiry活用術

はじめに

こんにちは！メンバーズでスクラムマスターをしている大和です。

役割柄、これまでさまざまなチームのふりかえりに参加してきたのですが、その中でずっと気になっていることがあります。

「KPTで、KeepからTryを出すのって難しくないですか？」

※当記事は、連載「スクラムマスターが語るKPTの課題、なぜKeepからTryが出ない？」シリーズの第一回になります。第二回、第三回は以下からご覧ください！
（※第1回目の公開を起点に、10/22と10/23に公開予定です。更新まで今しばらくお待ちください。）

• スクラムマスターが語るKPTの課題、なぜKeepからTryが出ない？#2 Keepを「探究」する4Dサイクルの問いかけガイド

• （最終回）スクラムマスターが語るKPTの課題、なぜKeepからTryが出ない？#3 成果物だけではない、ふりかえりの真の価値

KPTでよくある話

皆さんご存知「ふりかえりフレームワークの定番」であるKPTは、期間中に起きた出来事をKeep、Problem、そしてTryの3つに分けることで、チームに思い出しや内省、そしてカイゼンアクションの創出を促します。

Keepには「今後も続けたい or より強化・深化させたい取り組み」を、Problemには「解決・解消したいチームの障害・課題」をそれぞれ書きます。そこから「チームやプロセス、プロダクトをより良くするために改善できることってなんだろうね？」を考える……というのがよくある流れですね。

実際にやってみると、Problemからは比較的スムーズにTryが出てきます。

例えば

• 「レビューがなかなか進まなかった」

• 「タスクを取りすぎて、後半がかなり苦しくなった」

• 「仕様について、途中で認識のずれが見つかり手戻りが発生した」

こうした出来事、課題に対して、

• 「プルリクエスト、もう少し小さく分けてみよう」

• 「次のスプリントでは、タスクにWIP制限をかけてみよう」

• 「着手前に、仕様を確認する時間を作ってみよう」

といったアイデアが、あまり悩むことなく湧いてくると思います。

もちろん、あらゆるProblemに対してではないと思いますが、「この問題をどう解決・改善しようか？」という会話は、かなり自然にできるのではないかと思います。

一方、Keepになるとどうでしょうか。

• 「ペアプロがうまく機能し、属人化の解消が進んでいる」

• 「スプリントレビューで、ステークホルダーと今後についての良い会話ができた」

• 「困ったときに、チーム内で相談しやすい雰囲気ができている」

うーん、素晴らしい！Keepがたくさん出てくると嬉しいし、テンション上がりますよね！

よし！じゃあこのまま「これらKeepを、次スプリント以降さらに活かすために何ができそう？」を考えてみましょう！

すると、なぜか急に皆の口数が減ってしまいました。 しばらくして出てきた言葉は

「引き続きやっていく、でいいんじゃないですか？」

……いやまあ、そうですよね。 Keep、つまりうまくいっていることなのだから、そのまま継続すればいい。わざわざ何かを変える必要はない。

ただただ頷いてしまいそうになりますが、それだけで、本当にそのKeepは継続できるんでしょうか？

そして、KeepとProblemに対して、私たちはなぜここまで異なる反応をしてしまうのでしょうか？

ふりかえりは「問題解決」に向かいやすい

Problemには、すでにチームメンバーの意識にのぼっている「困りごと」が現れます。私が参加してきたふりかえりでは、そういった「このままでは困る」に対して、割とスムーズにTryが出てきました。

「レビューに時間がかかってしまう。。。」 => 「そうだ、プルリクエストのサイズを小さくしよう」

「問題があるから、解決・解消したい」という考え方は、仕事の場だけでなく、普段の生活でも（ほぼ無意識的に）用いられる考え方ではないでしょうか。

• 朝寝坊した！ =>これからは目覚まし時計を増やそう。

• 忘れ物をした！ =>これからは前日のうちに玄関へ置いておこう。

• 説明が伝わらなかった…..。 =>次からは資料に図を用意しよう。

自身がぶつかった問題から学び、あるべき姿と現状の差分（ギャップ）に対して解決策を考える/計画する。 様々なチームとふりかえりを共にしてきましたが、この「問題の原因を考えて解決策を探す」という考え方は、どのチームであっても基本的なものだったように思います。

では、KeepからTryを見つけたい場合はどうでしょうか。 上手くいっているのであれば、少なくとも困ってはいないですよね。今すぐ何かを変える必要もない。むしろ下手に変えてしまうと、せっかくうまくいっているものを壊してしまうかもしれません。 そうして導かれるTryは、自然と「継続する」という形をとります。

失敗からは「学ぶ」、では、成功からは？

ここで、私自身の経験から、学生時代のテストを例に考えてみます（人によっては嫌な思い出かもしれませんが）。

先生から答案用紙を返却されて、間違っていた問題に赤いバツがついていたら、

「どこで間違えたんだろう？」

と見直しますよね。

計算を間違えたのか。公式を覚えていなかったのか。そもそも問題の意味を勘違いしていたのか。 「何が原因だった？」と問いを立てて、次に同じ問題が出たときは正解できるよう対策します。それが学力向上につながる、推奨されるべき行動だと信じていました。

では、正解していた問題はどうしていたか。「よかった！正解だった！」と喜びこそすれ、その先で思考を深めることはなく、そのまま次の問題に目を移していました （正解を喜ぶこと自体はとても大事なことだと思います！）。

「なぜ自分はこの問題に正解できたんだろう？」

「今回上手くできた考え方を、ほかの問題にも使えないだろうか？」

なんて、一問一問考えていた記憶は、正直なところありません。

正解＝問題なし！ 当時の私は、それ以上考える必要を感じていませんでした。

振り返ってみると、仕事でも似たようなことをしている気がします。 障害が起きれば原因を調べる。見積もりが外れたり、納期に遅れればその理由を考える。 会議が上手くいかなければ改善策を考える。

ただ、「今日の会議、めちゃくちゃ良かったね！」そうなったときに 「なぜ今日はこんなに良かったんだろう？」 まで話した場面は、私が見てきた中ではかなり少なかったように思います。

もしかしたら、私たちは 「失敗から学ぼうとする」のには慣れている一方、「成功したこと、上手くいったことから何を学べるだろう？」と考えることに、それほど慣れていないのかもしれません。

そう考えると、これまで私が見てきたふりかえりで、KeepからTryが出にくかったのも不思議ではありません。 「チームの成功」を前にして「では、より良くするために次は何をしますか？」と聞かれても、「いや、上手くできたことだし……」と困ってしまう......

KeepからTryを出そうとすると、なぜか場が静まり返ってしまう。その沈黙は、メンバーがアイデアを持っていないからではなく、「上手くいっているのに、一体何を変えればいいのだろう？」という、とても素直な反応から生まれたのかもしれません。

ただ、もしKeepの中にもチームが学び・成長するための材料がたくさん眠っているのだとしたら、「上手くいった。良かった！」 だけで終わってしまうのは、ちょっともったいない気がしますよね。

では、そもそも「成功から学ぶ」とはどういうことなのでしょうか。自分なりにあれこれ考えていた中で出会ったのが、Appreciative Inquiry（アプリシエイティブ・インクワイアリー）という考え方でした。

今あるものの中から、最良の状態を発見する

Appreciative Inquiryは、組織にある問題や不足だけを見るのではなく、「その組織が最も上手く機能していたとき」 に目を向け、そこにある強みや経験をもとに未来を作っていこうとするアプローチです。

Appreciative Inquiryの実践は、以下の4Dサイクルという考え方を用いて行っていきます。

• Discovery: 発見。何が上手くいっているのかを見つける

• Dream: 理想を描く。その良さがもっと発揮された未来を考える

• Design: 設計する。その未来に近づくための方法を考える

• Destiny: 実現していく。実際に動き、試しながら育てていく

（資料によって最後のDをDeliveryと表記することもあるようですが、この連載ではDestinyに統一します。）

一般的な問題解決型の変化を「問題を特定する → 原因を分析する → 解決策を考える」とするならば、Appreciative Inquiryは「今あるものの中から、最良の状態を発見する」ところから始める方法です。

私はこの考え方を知ってすぐに「……あれ？これってKeepからTryを発見する上で非常に有効なアプローチになるのでは？」と考えました。

Keepを「ゴール」ではなく「スタート」にする

例えば「今回のスプリントレビュー、ステークホルダーとの対話がすごく良かったね！」というKeepが見つかったとします。 いつものProblem中心の思考であれば、特に問題は起きていないので「良かったね！次回もやっていこう！」で終了です。

しかし、Appreciative Inquiryを用いた考え方では、ここはむしろスタート地点 になります。

まずDiscoveryのための問い。

「あのレビューの場の何が良かった？」

話してみると、

「いつもの機能説明だけじゃなくて、途中でAさんが『この先、この機能をユーザーにどう使ってほしいですか？』って聞いたところから話が広がったよね」

という出来事が見つかったとします。

続いてDream。

「こんな感じで、毎回ステークホルダーとプロダクトの未来について話せるレビューになったら、どんな場になるだろう？」

さらにDesign。

「その状態を今後も再現するために、何かできることはある？」

こうした問いを重ねることで、例えば 「次回は、デモする機能ごとにステークホルダーへ聞いてみたいことを一つ用意してみたらどうだろう？」 というアイデアが出てくるかもしれません。

うまくいった出来事を「成功！やったね！」で閉じてしまうのではなく、4Dアプローチをもとにした問いで掘り下げてみる。 こうすることで「Keepから何かTry出そう！」といきなり言われるよりも、ずいぶん考えやすくなりそうです。

成功から学び、探究する

Appreciative Inquiryは、良かったことを見つけて終わるのではなく、実際に上手く機能した経験や、その背景にある強みを探り、そこから望ましい未来を描いていきます。 ここで重要なのは、4Dサイクルの中でチームに投げかけられる「何が良かったんだろう？」「次に試せることは？」という問いです。

少し前に、私は、

「失敗から学ぼうとする」のには慣れている一方、「成功したこと、上手くいったことから何を学べるだろう？」と考えることに、それほど慣れていないのかもしれません。

と書きました。

しかし、そこに「何が良かったんだろう？」という問いが加わることで、成功は「終点」ではなく、チームを学習と探究の旅に連れ出してくれる「起点」へと変わります。

KeepからTryを発見するのに必要だったのは、Keepを単に「継続するもの」として見るのではなく、「探究するもの」としても扱うことだったんですね。

おわりに

今回は「KPTで、KeepからTryを出すのって難しくないですか？」という問いを発端に、私たちが「成功」からなかなか「学び」や「次のアクション」を見出せない理由について考えてみました。

そして、Appreciative Inquiryの考え方を軸に「成功から学ぶ」ための具体的な方法についても見てきました。

この記事を読み終わったら、ぜひ一度あなたの過去のふりかえりボードを見直してみてください。Keep欄に置かれた付箋の内容が、これまでと少し違って見えてくるはずです！

また、ここまで読んで、 「なるほど！じゃあ次のふりかえりから『なんで上手くいったんですか？』って聞けばいいのね！」 と思うかもしれません。

はい！と元気よく答えたいところなのですが......すいません、たぶんそれだけでは上手くいかないと思います。というのも、その問いによってKeepについて考えるきっかけは作れても、問いの抽象度が高く、チームは「うーん、なんでだろう？」で止まってしまうことが多いからです。

では、Keepを探究し、Tryにつなげるためには、実際にどんな問いを使えばいいのでしょうか。

次回は、チームがKeepを深く掘り下げ、具体的なTryを生み出すための「実践的な問いかけ」について、さらに詳しく掘り下げていきます。それでは、また！