4週間で KPTをどこまでアップデートてきるかチャレンジ！！！
こんにちは。
この記事は以下のアドベントカレンダーの一環として書かれています。 他の記事もぜひご覧ください。 qiita.com
さて、今回この記事でお伝えすることは、表題の通り、振り返り手法の一つである KPT を アジャイルコーチにフィードバックをもらいながら1週間スプリント × 4回まわすことによって、どこまでチームの振り返りをアップデートできるかチャレンジしたことについて記載します。
この文章から
チームの概要
まずはじめに筆者の属性やチームの状態などを記載します。
前置きとしては長いので、不要な方は 振り返りをやってみた まで飛ばしてください。
筆者個人の属性
- フロントエンドを中心にバックエンドやインフラもかじりつつエンジニア歴6年(記事執筆時点)
- CSMの資格を取得済みでチーム内でもスクラムマスターのような振る舞いもしている(いわゆるエンジニアとの兼任スクラムマスター)
チームの状態
- チームが立ち上がったのは2022/10からで、この記事公開時はまだ2ヶ月しか経ってない
- 今回のこのKPTをアップデートするチャレンジをしたのは11月(チーム発足後2ヶ月目)
- アジャイルやスクラムに対する個々人の理解度や経験値はバラツキあり
- スクラム未経験なメンバーもスクラムやアジャイルな開発をしていくことそのものには好印象
もともとの目的意識
チーム立ち上がり時の10月はわりとチームビルディングやざっくりとした「プロジェクトやチームそのもの」の方向性を議論する時間が大半でした。
議論の結果、大まかな方針が定まり、ある程度それぞれが動き出せそうな状態になり、チームの振る舞いも少し調整しようとなりました。
それまでは簡単なデイリーMTGのようなものはありましたが、定期的に立ち止まりチームとして振り返りができる場がほしいなと思い、以下のように組んでみました。
11月実施したチームの動き
実施した全体の動きは以下のようになりました。
- チームのデイリーMTGは引き続き継続
- 1週間を1スプリントとしてまわしてみる
- 水曜日の夕方にスプリントの終わりとして振り返るを実施、その後プランニングを実施
- 振り返り、プランニングそれぞれ各1時間
- プランニングの1時間はスクラムから考えると短いように思えるが一旦試運転な月でもあるので1時間で様子見することとした
- 振り返り、プランニングそれぞれ各1時間
さて、前置きが長くなってしまい恐縮ですが、以下本題に入っていきたいと思います。
振り返りをやってみた
なぜ4週間連続、なぜKPT
今回本格的に振り返りをするとなった際に チームとして振り返りすることに慣れよう ということを意識しました。
本来の振り返りではチームやそのスプリントの状況によって振り返り手法を変えることで、より詳細にチームの課題感を深堀りすることができるかと思います。
一方でその当時のチームでは振り返りのやり方に気をとらわれ、課題を抽出したり議論を活発に行うことに集中できない可能性があると考え、あえて1ヶ月手法を固定してみました。
振り返り手法を固定にするにあたって KPT を採用した理由としては、
筆者がそもそもKPTを今まで何度も利用してきたことと、「プラスな点(≒keep)」と「マイナスな点(≒problem)」と「どのようにカイゼンするか(≒try)」が1セットになっており、
この手法に沿って進めておけば振り返りするにあたって欲しい観点が一通り体験できると考えたためです。
スクラムマスターである自分とは別にチーム外のアジャイルコーチについてもらい、振り返りを観察していただき、終わったあとにフィードバックをいただきました。
1週目
実際に1週間スプリントをはじめてまわしてみたときのはじめてのKPTの図は以下になります
- ファシリテーターは筆者
- 振り返りのきっかけになればということでよくあるKPTのフレームワークに追加で「出来事」という枠を用意
- 例: 半日全社会がありました、祝日がありました
- 初回ということもあるし、keepやproblemを思いつく限りたくさん書いてほしいなということで少し長めに記載時間を取った(10分程度取っていた認識)
アジャイルコーチからのフィードバック
- ファシリテーター(筆者)がしゃべりすぎ
- 付箋とかをほぼ全部自分が読んで、詳細があれば書いた人に説明してもらったくらい
- 意見を付箋に抽出するためには余裕を持って時間を取るという選択肢だけではなく、たとえば「みなさん手が止まっているようですが、最後に一人一個ずつ、追加でなにか書いてみてください！」など声をかけたりするだけで意外と時間をかけずとも意見が出たりすることもある
- 「きれいに」終わりすぎているように見える
- tryまで出ているが、きちんと「本質的な課題」や「誰かが実は思っている違和感」などをちゃんと抽出した上でtryが出せているのかが怪しい
- 複数出たproblemに対して
全部を一度に解決しようとしてしまっているように
フィードバックを受けて
何がなんでもtryを出さねば…
ファシリテーター(筆者)としては「まずは初回の振り返り、一通りまわして会として着地させたい！」というところに意識が向きすぎていて空回りしていたなと感じたところでした。
特に「付箋すべてに触れなければいけない」「tryを何がなんでも出さなければ」というある種の強迫観念のようなものすらあったなと思います。
その結果として「付箋全部に触れつつ、tryまで出したい」-> テキパキまわすために付箋は一旦自分が読んでしまおう、という振る舞いをしてしまいました。
意見の抽出方法
また、少し違うところとしては2つ目のフィードバックにある意見の抽出方法に関しても気づきをもらえたのはありがたかったです。
チームの中の視点としてはあまり違和感がないとしても、外部の目、特に有識者の目があるとこういった細かなtipsにも発展があるのがよかったです。
2週目
2週目のKPTはこんなかんじでした
- ファシリテーターは筆者が続投
- 別件で「アイスブレイクをはじめにしたほうがその後もみんな発言しやすくなる」という情報を手に入れたので、それを取り入れてみた。完全にプライベートで直近あったこと好きに書いてくださいというコーナーを用意し、そこをしゃべってから実際のKPTに入るようにした
- tryはある程度出せたらよい、ということを意識して進行
アジャイルコーチからのフィードバック
- アイスブレイクがとてもよかった
- 引き続きtryまで頑張って持っていこうという意識が前に出てしまっていたように見えた
- problemを全部見なければ、という意識も同様に感じたので、problemの中で投票して「どれから」話していくか取捨選択してもよさそう
- problemの中に「課題」というよりも「○○しなければいけない」といった具体的なアクション(につながること)などがわりと書かれていた
- keepの中にもkeepではなくいわゆる「good」に近しいものがあった
- 筆者がどの立場でしゃべってるのかたまに不明瞭なときがあった
フィードバックを受けて
アイスブレイク
アイスブレイクが好評だったのはありがたかったです。これはバイアスかもしれませんが、前回と比べて他のメンバーもリアクションが大きかったり、「大丈夫でーす」と声にしてくれることが多かったり、気になった点があったらすぐに言ってくれたりなどポジティブな印象を受けました。
一方でなかなか人のクセというのは抜けないもので、アイスブレイクの付箋も全部確認してしまい、ちょっと時間を使いすぎたかなと思いました。
付箋を書く分にはたくさん書いてもらいつつ、発表自体は一人1コンテンツだけ発表してもらう形式にしてもよかったなというところで次回に実施しようと考えました。
problemの深堀り
どうしてもtryまでたどり着かなければ！という気持ちが出てしまい、前回よりはproblemに出ている内容を話し合う時間に充てれたものの、最後はやはり駆け足になってしまったところはありました。
特にproblemに関してはさっと目を通して多少グルーピングなどをしたあとに投票してしゃべる内容を絞ってしまったほうがよいかもとアドバイスいただけました。
KPTというフレームワーク
今回は前回よりかはマシになったということもあって、KPTのフレームワークとしての観点からのご指摘もありました。
problemに関するものでいえば、メンバーは良かれと思って課題感からそのまま解決策もある程度見える形で書いてくれることがありました。
確かに議論としてはその解決策をそのまま受け入れるとスムーズではあるのですが、「本当に困っている点がそこなのか」であったり、「似たような課題感を持っている人の課題も、その解決策で解決できるのか」が怪しいなと考えました。
そういった点から、ある程度解決策が見えているものに関してもあくまで「課題や困っていること」だけ書いてもらうようにする必要があるなと思いました。
keepに関するところでいうとkeepではなくgood、良かったことなども結構散見されていました。
個人的には上記にもある通り、まずは振り返りに慣れてほしいこと、そして変に「これってkeepであってるかな…」と考え込むくらいであればざっくり「良かったこと」として書いてほしいなという気持ちがありました。
アドバイスいただけたこととして、まずは「good」から書き出して、その中から直接keepとして扱うものや、そのgoodがなぜ起こったかを考え、その起因となった行動などをkeepとして新たに書き出すなどして分けて考えてみるのもよいということでした。
このあたりはまだ厳密にはできてないですが、今後意識してやっていければと思います。
どの視点でしゃべっているのか？
前回のときも多少その影があったのですが、筆者が発言をするときにその発言が誰の視点なのかが曖昧なところが今回如実に出ていました。
端的にいうとファシリテーターの人格なのか、スクラムマスターの人格なのか、エンジニアの人格なのか曖昧でした。
受け取り方次第でその後の議論を惑わせ兼ねないところもあるなと思いそろそろ手を加えねばと思いました。
幸いこの2回でざっくりとは振り返りの雰囲気をメンバーが掴んでくれているということと、どのメンバーも場を回すことが極端に苦手とかではないため、
まずは次回からファシリテーターを当番制にすることにしました。
3週目
- ファシリテーターは別のメンバーが担当
- 雑談コーナーは前回の反省を踏まえて一人1コンテンツだけ発表
- problemの話し合いは付箋に投票することで議論する内容を決定
アジャイルコーチからのフィードバック
- 議論の時間が伸びていてよかった
- 引き続きproblemの付箋で解決策が書かれているものが見受けられる
- 付箋に対するコメントを事前にもらってもよいかも
- 前回のtryができているのかを確認する場があってもよい
フィードバックを受けて
ファシリテーター「じゃない」目線
まず筆者個人の感想として、ファシリテーターじゃないロールとして参加するとこんなにも安心して振り返りに参加できるのか、と感じました(笑)
次の工程や議論を集約させるところに必要以上に神経を尖らせる必要がなく、純粋に気になったところを質問したり、深堀りしたりするように促すことができました。
また、メンバーそれぞれで振り返りをするにあたって微妙にやり方が違うところがまた個性であったり、発見があって良いなとも思ったので、引き続きチームとしてはファシリテーターを交代しながらやりたいと思いました。
結果として議論の時間が伸びたのでよかったです。 ここに関しては今回ファシリテーターを担当してくれたメンバーが過去のフィードバックを活かしてくれたり、時間でしっかり区切ってズバッとやってくれたりしたおかげです。
各付箋との付き合いかた
とはいえ改善はできたものの、前回から引き続き「解決策」まで書いてくれてしまっているところがあったので、次は具体的に「課題や困っていること」だけ書いてもらうように促さなければならないなと思いました。
また、メンバーが多岐に渡って議論を展開してくれるため、各付箋を見て回り、そこに対して一言二言コメントするだけでもわりと時間を要してしまっていることがわかりました。
そのため、事前(keepやproblemを書く時間など)にある程度コメントできそうなものは事前にコメントしてもらうようにしたいと考えました。
あとは前回のtryが実際にどうだったかを観察できるとよいね、というところもあり、その点も次回に反映しようと思いました。
４週目
- ファシリテーターは別のメンバーが担当
- 前回のtryを確認するコーナーを用意
- keepの深堀りも一部実施(これは事前に意図したわけではなく、会の中で自然とそうなった)
- 「problemには困っていることや課題だと思うことだけ書いてください」と事前周知
- 余力があれば遠慮なくmiro上で事前にコメント書いてもらった
アジャイルコーチからのフィードバック
- 前回よりも議論の時間が伸びていてよかった
- 振り返りの段階はどこを意識していたのか
- チームとしてどうありたいのかを意識できるとよい
フィードバックを受けて
期せずして keep の内容での深堀りができたのはよかったです。
端的にいうと「○○がいいかんじに進んでいる」といった内容なのですが、いい感じなのがチームとして合意が取れていつつ、その理由がわりと不明瞭だなと思ったので深堀りをしてみました。
今後も いいこと の深堀りも意識したいなと思いました。
ある程度チームとしての振り返りの型が見えてきたこともあり、その他では細かなところでの指摘はほぼありませんでした。
その代わりもっと本質的なところでご指摘をいただきました。
振り返りの段階
アジャイル開発で欠かせない「ふりかえり」、チームを強くするための3つの段階とは|CodeZine（コードジン）
森さんのお言葉を借りると、振り返りには3つの段階があるといいます
- 立ち止まる
- チームの成長を加速させる
- プロセスをカイゼンする
上記のうちどこを意識していたかと問われました。
その点に関して筆者としては2番目の「チームの成長を加速させる」をその振り返りのタイミングでは意識していたと言いました。
一方でアジャイルコーチからは、「それであれば今回の振り返りでは焦ってtryを見出すところまでやらず。problemの言及に時間を使い切ってしまうのもアリだったのでは？」といただきました。
確かに意識していたことと、実際に起こしたアクションがずれていたのは良くなかかったなと思います。
そして、自分としてはそう思っていたとしても、チーム全体としてどういう意識だったかは曖昧だったなと思い、チーム全体としてどういう段階、どういう目的かを事前に共有すべきだなと考えました。
チームとしての在りたい姿
上記のところか通ずるところとして、「チームとしてどうありたいのか」というところもご指摘いただきました。
漠然とプロセスをカイゼンするだけだとカイゼンしていく向き先があっているのかわからない、適切に自分たちが思う方向に向かって進んでいけているのかわからないなと思いました。
振り返りを通じてチームの輪郭や、良しとされるアクション、推奨されないアクションなども見えてきたのでここいらでワーキングアグリーメントであったり、
「チームとしての在りたい姿」を今一度言語化し、それらを意識して振り返れるようにしたいなと思いました。
1ヶ月を振り返って
今までこのチームに所属する前も振り返りはやっていましたが、ここまで意識して振り返りをしたのははじめてでした。
これまでやってきた振り返りは「tryを出す」ために振り返りをしてしまっていたなと反省しています。
もちろんtryを出すことは大切ではありますが、きちんとチーム内でコミュニケーションが取れており、課題などにちゃんと向き合えることがまずは大事だなと思いました。
そしてその課題を解決するためにtryを出すことはありますが、それは枝葉のhowの部分を改良していくということではなく、チームそのものが学習し続ける習慣を作ることが大切だと思いました。
そしてその行く先としてチームとして自律的に考え、行動していける状態になることがアジャイルなチームなのかと考えています。
今後はそういった「チームにとってのアジャイルな姿」をチーム全員で意識し、その姿になれるよう振り返りを続けていきたいなと思いました。
※上記に書いてあるアジャイル、スクラムに関する内容は極力大本となる思想に沿う形で体現やフィードバックしていただいているつもりですが、一部筆者やフィードバックをしてくれた方の思想寄っているところもあると思うので、あくまでこういった考え方、選択肢もあるというふうに捉えていただけると幸いです。
