はじめに

こんにちは、森です。

Scrum Fest Osaka 2020は、6/26-27に開催された、オンラインでの大規模カンファレンスです。
今回、チームメンバーの島田さんが参加したワークショップについてレポートを記載してくれたので、そちらを乗せておきます。
（森は今回、自身の登壇が被ってしまったためこのワークに参加していません…。残念。）

今回、NRI asleadのチームメンバー2人で参加しています。

こんにちは、島田です。

この記事では、Scrum Fest Osaka 2020 2日目 #oblove（オブラブ） 14:00-14:45で行われた、KPTAフレームワークによるふりかえりのワークショップに関するふりかえりです。
ワークショップを通して得られた個人的な学びや感じたことを記載しています。

ふりかえりの手法として広く知られているものとして、以下のふりかえり手法がありますが、今回のワークショップでは、新しいふりかえり手法のKPTAとはどういうものか、アクティビティを通して体験しました。

• YWT
• KPT
• PDCA

KPTAワークショップ

実際に参加した45分間のワークショップでは、以下のアクティビティを実施しました。

1. KPTAの説明
   1. KPTでよくあること
   2. KPTAとは
   3. KPTA体験ワークショップの進め方
2. KPTA体験ワークショップ
   1. 自己紹介
   2. アクティビティ（１回目）
   3. KPTAでふりかえり
   4. アクティビティ（２回目）
3. まとめ

KPTでよくあること

「１．KPTAの説明」の中では以下のようなTryが出される場面が多いとのことでした。

• 実行可能でないもの
• 効果が少ないもの
• 落とし込めてないもの

このようなTryを出しても、ただこなすだけの形骸化したふりかえりとなってしまい、結局実施されないままになってしまう可能性が高いです。

また、きっちりとふりかえりの目的や進め方の認識を持てていないと、意味のないふりかえりになってしまうどころか、KPTはつらいものとなってしまう危険性があるとのことした。

• 責任追及になりがち
• 成果を実感できなくなっていく

本来前を向いてカイゼンをしていくための場が責任追及の場になってしまうのはつらいですよね。

KPTAとは

KPTAはふりかえりフレームワークのKPTを拡張した手法です。
Keep、Problem、Tryに加え、ふりかえりの内容を次の活動のカイゼンにしっかり活かすための具体的なアクションに落とし込む、Actionのフェーズを設けています。

KPTA体験ワークショップ

ワークショップでは２，３名のグループに分かれ自己紹介をしたのち、協力してジグソーパズルを完成させるというワークをしました。

アクティビティ（１回目）

初対面の方と共同作業するため、まずは自己紹介をしました。時間が限られているため、自己紹介をしたあとはすぐにワークに取り掛かりました。
動き方もぎこちなく、会話を少ないままとりあえず動いたという感覚でした。
結果、圧倒的に時間が足りず、ほとんど完成できません。

KPTAでふりかえり

１分間のアクティビティ（１回目）実施後に、５分でKPTAを用いたふりかえりを実施しました。
ふりかえりではContinuous KPTAというツールを使い、Keep・Problem・Try・Actionを付箋に書き出して共有しました。

ふりかえりでは付箋に書き出した内容を見ながら感じたことを共有しました。

• Keep:全体像が見えないのでまずは把握しようと動き出しが早かった
• Problem:お互いの作業がかぶってしまうことがあり、動きづらかった。
• Try：枠の右側と左側で担当を分けて、それぞれパズルを埋めていく

といった話をしました。

ここでふりかえりの時間切れとなりました。
Actionのフェーズではありますが、エリアで分けて作業を進めるという方針で合意できたため、アクティビティ（２回目）を開始しました。

アクティビティ（２回目）

アクティビティ（２回目）は、１回目の続きから作業を再開しました。
ふりかえりでのTry通り作業領域を分けたため、パズルを当てはめていく作業がスムーズに進み、時間内に完了まで持っていくことができました。

ワークショップのふりかえり

ふりかえり時にTryとして「左右で領域を分割してピースをはめていく」を挙げましたが、これは本来Actionに書く内容で、Tryとしては「作業領域を分割して作業する」といった内容が入ってくるのかなと思います。
具体的な案には落とし込めているものの、いきなりHowに入ってしまっているため、思考が展開しづらくなってしまったように思います。
Whatを一度書き出したうえでHowに入っていくというプロセスを踏むことで、より視野の広いHowが出てくるのではないかと考えています。
この点は、スクラムでの「価値」（What）に視点を置き、受入条件を満たせる方法であれば手段（How）は問わないという考え方に通ずるところもあるのではないかと感じました。

アクティビティ（２回目）ではパズルを完成させることができたものの、ほぼ作業が完了したと思ったタイミングで、実は２つのピースの場所が逆であり、バタバタするという一幕がありました。
これは、ピースをバラけさせた際に右側にはめるべきピースを左寄りに、左側にはめるべきピースを右寄りに置いてしまっていたため、それぞれの作業者が自分の領域にはめるべきでないピースを手に取りやすかったというが１つの原因としてあったのではないかと考えています。
この点について再びふりかえりを実施できそうだなと感じました。

まとめ

ふりかえりを通して最終的に「"実行可能"なアクションを出せているか／なっているのか」という観点を参加者が意識することが必要なのだと理解しました。
その仕組みとして、Tryで終わらずActionというフェーズを明に設けるというのポイントだと個人的に考えています。
また、業務の中で「手段が目的化する」ことがよくあると個人的に感じています。
What（Try）とHow（Action）を明確に分けることで、両者を混同してしまうことや発想の幅が狭まってしまうことを防ぎやすい点も１つのポイントなのではないかと感じました。