backcheck事業部の前田です。
backcheck開発チームでは2週間ごとに振り返りを実施しています。
わりといい感じなので、手法と気をつけているポイントを紹介します。
・・・と言いつつも、特に凄いことをやっているわけではなく、とても一般的な方法です。
振り返りの目的
詳細な話を始める前に、振り返りの目的をまとめておきましょう。
なぜ振り返りをするのでしょうか。
それは、プロセスや文化、組織をより良くするためです。
では、なぜプロセスや文化、組織を良くしないといけないのでしょうか。
それは、プロダクトの価値は、プロセスや文化、組織に反映されるからです。
ソフトウェアの価値は「技術力」によってのみ支えられていると、エンジニアは盲信しがちです。
それは間違っていないのですが、プロセスも同等に重要です。
たとえば誰も要らない機能を「とてもすごい技術力」で作ったとしても、プロダクトの価値は全く上がらないでしょう。
むしろ価値としては下がることもあるでしょう。
また、技術力は抜きにして、無駄な作業を減らせばその分、価値のある機能を作る時間を増やせるかも知れません。
成功循環モデルでも、「結果の質を上げるためにはまず関係の質を上げろ」という話が出てきます。
このように、プロセス改善をすることで、より良いものを、より早く、より高品質で作れるようになります。
振り返りの手法
KPTを使用しています。
KPTを使用している理由としては、「一番メジャーだから」です。
なぜメジャーなものが良いのかというと、情報量が多いからです。
KPTについて気になることがあったとき、メンバーは自分で検索をして調べることができます。
逆にFun Done Learnなどのマイナーな方法を使用すると、まだまだ文献が出回っていないので、「調べたけどよくわからなかった」となりがちです。
ファシリテータに知識が充分にあり、振り返りに慣れている場合にはマイナーな方法でも良いかもしれませんが、私のチームは振り返り初心者なので、メジャーな方法を選択しました。
KPTの概要
ざっとKPTの概要をまとめます。
まず、以下のものをメンバーに挙げてもらい、共有します。
Keep: 良かったこと・継続したいこと
Problem: つらかったこと・問題だなと感じたこと
その結果から、
Try: 改善したいこと・試してみたいこと
を導き出し、改善策を見つけます。
振り返りの参加者
開発メンバーとプロダクトマネージャーで行っています。
また、振り返りで参加できる人数のは3~5人までにしています。
2人以下の場合は、あまり相乗効果を期待できないので、形式張らずにラフな話し合いにします。
6人以上になると発言の機会が減ったり、ダラダラした雰囲気が出ます。
その場合は2チームに分け、後で合流して共有をします。
振り返りの時間
5人で2週間分の振り返りで、60分程度です。
始めたばかりの頃は100分程度かかっていました。
振り返りの流れ
以下の流れでやっています。
- (場の設定)
- 前回のTryの復習
- Keepの共有
- Problemの共有
- 改善したい項目を決める
- Tryの作成
- まとめ
ひとつずつ見ていきましょう。
場の設定
振り返りに限らず、ミーティングをする場合は「場の設定」を行います。
アイスブレイクなんかがそうですね。
「アジャイル・レトロスペクティブ」という本ではアイスブレイクは振り返りの場の設定に望ましくないと書かれていますが、私は全然アリだと思います。
むしろ紹介されている「チェックイン」の手法を使用したりすると、日本人にあまりない文化のため、メンバーの頭に「？」が浮かんだ状態になったりします。
私はここでの目的は
- リラックスする
- 発言しやすくする
などを置いています。
特に「一度も発言していない状態から発言する」というのは心理的にやりにくいので、場の設定のタイミングで全員一度は何かしらの発言をしてもらうようにしています。
「ooさんは今日のお昼、何食べました？」とかでオッケーです。
・・・と、長々と書きましたが、私のチームでは省略することが多々あります。
私のチームでは振り返りは、いわゆる「ミーティングデー」の一環として行われるためです。
振り返りの前のミーティングで既に場が設定されている場合、場の設定はスキップしてしまいます。
前回のTryの復習
前回の議事録を見ながら、
- 前回のTryをやったか
- 前回のTryをやってどのように変化したか
を確認します。
ここでのゴールを「Tryをやったかどうか」と誤認してしまう人が多いのですが、ここでのゴールは「Tryをやった結果、改善されたか」です。
ここで「毎回Tryを忘れる」という場合は、Tryをやる仕組みや習慣づくりについて話したほうが良いでしょう。
「忙しくてできなかった」という場合は、「木こりのジレンマ」になっている可能性があります。
Tryのコストが高いか、業務との優先順位をどのように付けるかについて話しましょう。
Keepの共有
以下の手順で行っています。
- それぞれでKeepを書き出す(3分)
- Keepの共有
以下、注意している点です。
Keepの対象
そのまま和訳すれば「継続」ですが、ここでは単純に「良かったこと」も挙げてもらっています。
振り返りは「反省会」ムードになりがちです。
良かったことを先に挙げてもらうことで、振り返り全体の空気感を明るくし、前向きに振り返りをできる環境にする側面もあります。
Keepの書き方
なるべく付箋など、文字数に上限を決められるもので書きます。
Keepに文字を書きすぎてしまうと、後で全体を俯瞰して見づらくなってしまいます。
「最小限でかつ伝わる」書き方で書くようにします。
Keepを書くとき
そのまま開始するとなぜか「他の人と話してはいけない」という暗黙のルールが形成されるので、 「他の人と相談しても全然OKです！！」ということは明示的に伝えます。
共有方法
順番を決めて、最初の人が1枚共有したら次の人が1枚共有し、さらに次の人が・・・と続けていきます。最後の人まで回ったら最初の人に戻り、全員がすべてのKeepを共有するまで行います。
共有のタイミングでは、長く話しがちになります。
「その人のすべてのKeepを共有してから次の人が共有する」という手法を取ると長く話しやすくなってしまうので、「1枚共有したら次の人」で、必要・重要なことのみを共有してもらいます。
Problemの共有
以下の手順で行っています。
- それぞれでProblemを書き出す(3分)
- Problemの共有
基本的にはKeepの共有と同じことに注意していきます。
Problemではそれに追加して以下を注意します。
解決策は出さない
問題を考えると一緒に解決策も提示したくなりますが、ここでは解決策は出さないようにします。
基本的に1人で考えた解決策よりも、複数人で考えた解決策のほうが優れています。
三人寄れば文殊の知恵ですね。
なので、解決策はTryを作成する際に、チームで考えるようにします。
特定の人への攻撃
(私のチームでは発生してませんが・・・)
「ooさんのせいで」など書かれているものが共有された場合は要注意です。
基本的に「チーム vs 問題」という構図を目指していくので、このような場合は、その問題の背景にあるプロセスや慣習の問題を考えるように話の方向性を導きます。
あまりにこのケースが多いようであれば、振り返り後に個人的に説得をするか、全体で「なぜ個人を攻撃してはいけないか」を説明し、ルール化したほうが良いです。
改善したい項目を決める
挙がったKeep、Problemから改善したい項目を決めます。
ひとり3票で、得票数の多い1~2つについてTryを考えていきます。
このプロセスはTryを絞るだけでなく、「個人の関心事」を「チームの関心事」に変化させる役割もあります。
たまにTryを考える際に「私のためにみんなに負担かけさせたくないです」のような事を仰る方がいます。
投票という行為を通じて「あなたのためじゃなくてチームのためにやるんですよ」という流れを作ります。
以下、注意点です。
KeepもOK
改善というとProblemに目が行きがちですが、Keepに票を入れても全然OKです。
Keepが選ばれた場合は、「それをより良くするためにはどうするか」がTryになります。
Tryにできるのは2つまで
挙がった問題すべてに対処したくなりますが、グッとこらえて対応するものを絞ります。
すべてに対応しようとすると、ひとつひとつの精度が落ち、「Tryだけどやれなかった」ものが多くなりがちになります。
また、人間は大量の変化には馴染みづらいので、文化や慣習にならずにただ「Tryを実行しただけ」になってしまいます。
さらに、プロセス改善をしすぎると、その分、業務する時間が減り、「プロセス改善してたので業務が進みませんでした」のような事象が発生します。
そのため、なるべくやる価値の高い変化だけに絞り込みます。
もし選ばれなかったものの中に重要なものが紛れている場合、次回にも同じものがKeepかProblemに挙がってくるはずです。 そしてそれが本当に重要なのであれば、次回、投票で選ばれ、改善されるはずです。
Tryの作成
投票で選ばれたものについて、「どのようにすれば改善できるか」をチームで考え、改善項目を出していきます。
ここでは、以下の流れで行っています。
- 投票で選ばれたものの事象についての深堀りと理解
- Tryを作成する
以下、注意点です。
事象についての共有理解をつくる
事象については誰かが観測してKeep, Problemに挙げたものです。
そして、投票を通じてチームがその事象に関心を持っていることがわかっています。
KeepやProblemを共有する場ではなるべく必要最小限の共有に抑えていたので、ここで詳細な情報をチームで把握します。
この事象を挙げた人に詳しく話してもらったり、他の人からその事象がどのように見えているかについて話すと良いです。
必要であれば「5つのなぜ」や「根本原因分析」などのテクニックを使用するのも良いでしょう。
「チーム vs 問題」を意識する
「ooさんのせいで」のような話になると裁判になってしまうので、なるべく「チーム vs 問題」になるようにします。
「私の能力が低かったので」も同じです。チームの話にシフトさせていきましょう。
基本的に、人間性や能力などは前提条件なので覆すことができません。仕組みやプロセスを調整して問題解決できるようにしていきます。
発散して収束させる
一般的に、「最初に出された解決策はあまり役に立たない」と言われています。
Tryを作成する際は、ブレストの要領でまず広く解決策を募ります。
ここでの敷居はなるべく下げたほうが良いため、ファシリテータは率先して敷居を下げられるような解決策を出していくと良いでしょう。
ある程度、解決策が出揃ったら、解決策をまとめていきます。
実現不可能なものや効率性の悪いものを落としたり、複数のアイデアを合体させたりします。
最終的に、各事象に対してのTryは1~2つ、全体でのTryは3つまでに収まるように調整します。
ベイビーステップを意識する
作成したTryが大きすぎる場合(次の振り返りまでの完了しない場合)は、そのTryを分解し、「最初の一歩」の部分をTryとします。
振り返りのまとめ
最後に、Tryのもととなった事象とTryの内容をまとめ、振り返りを終了します。
記事のまとめ
backcheck開発チームで行っている振り返りの方法をまとめてみました。
改めてKPTの構図を見てみると、「デザインのダブルダイヤモンド」のような、2回の発散と収束があることがわかりますね。
KPTは一見簡単そうに見えますが、結構考えるべきポイントが多く、難しかったりします。
この記事がみなさんのKPTライフの参考になれば幸いです。
