Good/Bad と 事実/気持ち から始める「ふりかえり」の手引き
これはなに
世の中の3人~8人程度のソフトウェア / システム開発チームの多くは，俗に言う「アジャイルな開発手法」のプラクティスを実践し，1週間から1ヶ月に1度といった定期的なタイムボックスを設けてチームの開発プロセスや成果物などを対象とした「ふりかえり」をしていると思います。
そして，日本の多くの現場では，「KPT」と呼ばれる Keep (続けること) / Problem (問題になっていること) / Try (次のタイムボックスで新しく試みること) を挙げる方法による振り返りをしているのではないかと思います．
私が開発リードを務めているチームでは，KPT とは違ったフレームワークで週に1度のふりかえりを行っていて，割とうまくいっていると思っているので，それを紹介しようと思います．
KPT は「チーム」のふりかえりには向かない
最近個人的に思っているのは，KPT はチームのふりかえりには，適していないとまでは言わずとも，あまり向いていないのではないかということです．
よくある KPT の進め方は，K / P / T のそれぞれ，つまり「チームが続けるべきこと」「問題になっていること」「次のタイムボックスで試みること」を付箋に書いたり，その内容を順番に発言したりして発表していくかと思います．これをチームの振り返りのフレームワークとして用いると，いくつか不都合なことがあるのではないかと考えています．
透明性を担保するフェーズが無い
アジャイル開発フレームワークの一つであるスクラムは，「検査 (Inspection)」「適応 (Adaption)」「透明性 (Transparency)」 を3つの柱としています．透明性を担保した上で，それまでのチームの生産性や成果物などを検査し，変化や問題に対して適応していく，ということですね．
学習や改善のループを表す 「PDCA」という言葉の「Check」も，改善のループの中で行ったアクションに効果があったのか，計画通りに行動ができているのかを確認するというフェーズです．
これらの考え方に共通しているのは、全ての改善活動は，まず現状の把握から始まる，ということです。
「K/P/T をチームメンバーが思いのままに挙げる」というアクティビティからふりかえりを始めてしまうと，直近のタイムボックスにてチームに起きた事実を振り返るタイミングが無いのが問題だと思っています． 「前回の KPT で出た Try やアクションを振り返ることから始める」というチームもあるかと思いますが，そもそも透明性を担保するべきなのは ふりかえり で出た事項だけでなく，チームの日々の仕事で起こったこと全体ではないでしょうか．
チームのアクションは個人が決めるのではなくチームが決めるべき
「次のタイムボックスに何を続けるか」「次のタイムボックスに何を試してみるか」の主語は，当然ながら「チーム」であるべきです． *1 しかし、チームが主語になる Keep / Problem / Try をチームメンバー各々が挙げるというアクティビティには、いくつか欠点があります。
例えば、あるメンバーにとってやってみたいと思う Keep や Try という具体的なアクションが挙がっても、それが本当にチームで取り組むべきアクションであるかどうかは別なこともあるでしょう。チームで実際に何に取り組むかを決める上で、一度チームメンバーが挙げた項目を否定しなければいけないというのは、ふりかえりに参加するチームメンバーにとっての心理的安全を阻害する要因にもなってしまう可能性があるでしょう。
それに、そもそも対処したい問題に関する視座が揃っていないでアクションの話をしてもファシリテーションコストがかかってしまうのも、限られたふりかえりの時間を無駄にしてしまう要因となってしまいます。
透明性の担保から始める「Good/Bad」と「事実/気持ち」
では私のチームではどうやっているかというと，横軸に「Good/Bad」，縦軸に「事実/気持ち」という2軸でマトリクスを書いて，そこにチームメンバー各自が思いついたことを付箋に書いて貼っていく，というアクティビティから初めています．*2
上半分の「事実」パートには、そのタイムボックスで起きた事実を書き出します。写真の右上なら「良い事実」や「前向きな事実」を書くことになるので、例えば、「xxx のユーザーストーリーマッピングがうまく行った」とか「平均のレイテンシーが 2 ミリ秒を切った」「差し込みでの作業対応が減った」といったことでしょうか。
下半分の「気持ち」パートには、ネガティブなものだと「不安」とか「愚痴」「辛い」といったもの、ポジティブなものだと「心地よい」とか「皆に知ってほしい」「楽しい」といったような話を書いていきます。例えば左下の象限は「良くない気持ち」「後ろ向きな気持ち」を書く場なので、他のチームはなんで柔軟に対応してくれないのか…」とか「XXX とのシステム接続がうまく行くか不安」といった内容を書いたりします。
自分の挙げる項目がこの4象限のどこに当てはまるのかはメンバー各自の裁量に任せています。
チームメンバーから付箋が出きったら、順番に付箋の内容を読み上げながら翌タイムボックスで実践するアクションを参加者で検討していくように話を進めていきます。
Good な項目で、翌タイムボックスでの仕事の生産性を上げる施策として取り組めないか、Bad な項目は根本な原因を考えたり、それに対するチームとしての取り組みができないかを考えます。
4象限のどこから始めてどういう順に会話を進めていくかはファシリテーションの裁量だと思うのですが、自分はいつも「Good な事実」から始めて「Bad な事実」「Bad な気持ち」「Good な気持ち」という風に、反時計回りに進めるようにしています。良い事実を確認することでふりかえりの雰囲気を明るくし、後ろ向きな事実や気持ちに向き合いつつ、最後には前向きな気持ちをチームで共有することでポジティブな雰囲気を作ってスプリントを終えるようにしたい、というのが狙いです。
何が良いか
この形でふりかえりをやるようになって3スプリントくらいになるのですが、以下に述べるような良い点があると思って続けています。
事実を洗い出した上でチームで取り組むことを議論させるように持っていきやすい
チームメンバーに書き出してもらうのは、「良い事実」とか「良くない気持ち」といった 現状の確認 であり、具体的なアクションではありません。そのため、前述したような、最初にアクションから考えてしまうことによるファシリテーションコストのムダも減らせます。
また、事実を並べた上でチームで議論してアクションを決定するという流れを作ることで、「チームで決めたこと」という納得感を作った上で翌タイムボックスで改善活動に取り組むという流れを作りやすいのも良いところです。
「気持ち」という欄でチーム内の共感を生みやすい
最初は「Good / Bad」という1つの軸のみで事実を振り返るというかたちで振り返りを進めていたのですが、「クリック率にフォーカス出来るのが楽しい」「xxx をリファクタしておきたい」「テストデータをもう少し拡充させたい」といった、事実とは少々違った話題が多く出るようになり、その中にこそチームの改善のヒントがあるだろう、ということで後から導入したのが「事実と気持ち」という軸でした。
それまでの振り返りでも「気持ち」にまつわる付箋は各参加者が書き出していたのですが、明示的に欄として設けることで、その流れを促進することが出来るようになり、ふりかえりの内容が一段と濃いものになったように思っています。
なにより、ふりかえりの中で「気持ち」を表明することを促すことで、他のチームメンバーもその気持ちに対する共感を表すこともでき、結果としてチームビルディングにも良い影響があるのが良いところです。
ときには愚痴っぽい話がメインになってしまうこともあるかと思いますが、最終的に前向きに改善に臨むためのアクションを議論するようにファシリテーションをするようにさえすれば、ふりかえりの主目的である改善活動をしつつ、チームワークの醸成にも一役買っているのかな、と思っています。
KPT でやっていけないわけじゃない
KPT にしろ、今回紹介した「Good/Bad と 事実/気持ち」にしろ、議論を行う上でのフレームワークはファシリテーションを行う上での道具でしかないし、結局はファシリテータに高いファシリテーション能力があったり、チームが充分に自律し自己組織化していれば、どんな形式でふりかえりを行ってもチームや日々の仕事を改善していくことは出来ると思います。
ではフレームワークは何のためにあるかといえば、やらなくてよいことをやらずに済ませるようにすることでムダを省いたり、ファシリテーションスキルが高くない中でもある程度のパフォーマンスを出せるようにするためなのだと思います。
もし普段 KPT でふりかえりを行っていて、どこか上手く行っていないような気がするという場合は、今回紹介した進め方でふりかえりを試してみても良いのではないでしょうか。
じゃぁ KPT ってどういうときに有効なの？
記事の特性上、「KPTってイケてない」と思われてしまうような方もいらっしゃるのではないかな、という危惧が無いわけではないのですが、KPT 自体が悪いわけでもありません。
KPT が向いているのは、個人のコーチングやメンタリングをする文脈ではないでしょうか。なぜなら、トレーナーやメンティーが、自省を踏まえて自分の裁量で各種アクションを決めれば良いからです。トレーニーやメンティーが自分の Keep するべきことや Problem になっていることや Try することを自分なりに考えた上でトレーナーやメンターとの 1 on 1 のミーティングに臨んだり、1 on 1 の中で KPT の各項目を埋めていったりするのは非常に有効だと思います。
