FAQ
ここでは、KPTを使った振り返りを行った際につまづきやすい点と、その対応策について解説します。
意見が出ない
この業界にはシャイな方が多いようで、振り返りを取り入れた直後によく見られる現象です。振り返りでは、各項目について質問し、後は各人に任せて意見を出してもらうのが基本ですが、新しい取り組みの場合はみなさん遠慮がちになってしまうこともあるでしょう。
このような時は、イレギュラーですが司会者が1人ずつ指名して意見収集するのも1つの手です。または、紙に自分の意見を書いてもらいます。このとき司会者は出た意見について評価はしないでください。あくまでも、出た意見はすべて受け入れてホワイトボードに書き込みましょう。そうすることによって、どんな発言でも許されるんだという感覚をメンバに植え付けます。これで、次回からは、いろいろな意見が出てくることと思います。
ホワイトボードのスペースでは書ききれない
これは、司会者が発言者の意見をうまくまとめきれていないことが原因と考えられます。発言者の意見をすべて書いていては、スペースも時間も足りなくなります。また、Tryの部分を次回見直す場合に、非常にたくさんの文章を読まないとわからないようでは困ります。司会者は発言者の意見を箇条書き、キーワードでうまくまとめるように努力することが必要です。
どうしても時間がかかってしまう
まずは、振り返り全体を何分で終わらせるか目標時間を設定しましょう。それから、その時間をメンバにも伝えます。次に、Keepに何分、Problemに何分、Tryに何分というように細分化したタイムスケジュールを考えておきます。これを頭に入れて時計を見ながらやっていくと良いでしょう。
また、司会者は参加者の意見を記録しながら次の意見を聞くようにすると、テンポ良く進むので良いでしょう。ちょうどRISCチップのパイプライン処理のようなイメージです（図3）。
長続きしない
1回の時間が長すぎるようなら短く終わるよう工夫して、なるべく軽量な取り組みにコーディネートしてください。ヘビーなプロセスは長続きしません。また、毎週金曜日の13時にやるというように決めてしまって、リズムを作るのもよいでしょう。
Tryの内容から次の行動が想像できない
Keep、Problemの中には具体的でないもの、たとえば「楽しかった」や「きつかった」など感情的な内容があったとしてもかまいません。逆にそのような内容はチームのノリをよくしてくれる場合が多いでしょう。しかし、Tryで「頑張る」など感情的な内容では次の取り組みで何をすればよいのかわからないので良くないでしょう。具体的な行動を書くべきです。
Tryの内容が予定になっている
たとえば、Aモジュールの開発という業務の中でプロセス改善を考えていて、KPTを導入したとします。このとき、Tryに「Aモジュールの詳細設計」と書く人が時々います。これは、プロセスの取り組みではなく、業務の計画です。KPTはPDCAサイクルによって自己成長を助けるためのツールですので、業務の計画とは分けて考えることをお勧めします。
いかがでしたか。KPTを自分たちのツールに使ってみようという気になっていただけたでしょうか。何か新しいことをやるには、つまづきはつきものです。そこを乗り越えるためのツールが、今回ご紹介したKPTを使った振り返りです。ぜひ自分たちのチームでやってみてください。きっと自己成長のためのツールであることを実感できると思います。
次回は「カード駆動型開発」です。お楽しみに。
