wwwave tech ブログ

株式会社ウェイブのエンジニアブログです。 ここではエンジニアの目線から会社の話や技術的な話をしていきたいと思います。

ウェイブのKPTを紹介します

二回目の記事を任されました! switchが欲しいSWです。

ウェイブでは隔週、エンジニア全員で集まって「ふりかえり」を行っています。 「ふりかえり」とは、現場での活動を振り返り、次の改善アクションを考える改善活動の一つになります。 進め方のフレームワークとしてはKPTを選択いたしました。 KPTを少しずつ拡張、変化させながら運用を始めて2年。 現在どのようにKPTを進めているかとウェイブでのKPTの雰囲気をお伝えしていきたいと思います!

前提

本記事ではKPTをある程度知っていることを前提に書いております。 KPTについては素晴らしい記事がたくさんありますので、本記事ではウェイブ独自の要素について紹介いたします。

KPTとは?

KPTとは改善活動に用いる思考のフレームワークのひとつです。
Keep/Problem/Tryの単語のイニシャルをつなげたものになります。 ホワイトボードなどに下記の図を引いて、付箋紙などを貼っていって使うのが一般的です。

  • Keep=良かったこと、今後も続けること
  • Problem= 悪かったこと、問題点
  • Try=今後の活動でためしたいこと

f:id:sys_wwwave:20170804105133p:plain

ウェイブのGKKPTA

ウェイブではKPTに「G、K、A」を加えた形で運用しています。 エンジニアメンバーが増えていく中で、司会の負担が大きくなり、KPTの時間が長くなってしまうなどの問題も出てきました。そこで、効率化しようと試行錯誤して要素を追加していったものになります。
以前は紙と付箋でやっていたのですが、現在はlinoというWEBサービスを使って運用しています。WEB上で付箋を使った運用ができ、期限と担当者をつけられるので、紙からの移行としてはいい感じに使えると思います。

  • Good=良かったこと
  • Keep=今後も続けること
  • Knowledge=ルール化、定着したこと
  • Problem=悪かったこと、問題点
  • Try=今後の活動でためしたいこと
  • Action=やること

f:id:sys_wwwave:20170804094001p:plain

追加した要素について

Good

良かったことを貼る項目です。
KPTのKeepでは良かったことや続けていきたいことを出していきます。続けていきたいことの付箋は残して、良かったことの付箋は毎回剥がすのですが、これはどっちだっけ?となることが多く、明確にして剥がしやすくするためにGoodを追加しました。剥がしていいかどうかの判断がスムーズになりましたし、Goodの項目が明確になったので、意見も出しやすくなったかなと思います。

Knowledge

基本、Keepの付箋はシートに残しておくのですが、定着したもの、浸透したものは付箋を剥がしていきます。ただ、定着したといっても、剥がした後で新しいメンバーが加わったときなど、何か形にして残していないと暗黙知になってしまいます。そこで、剥がしたものをアーカイブするところとしてKnowledgeという別のシートを用意しました。社内ルールを書いたドキュメントを作れるとベストですが、運用のコストを下げるため、アーカイブするだけにして、カジュアルな運用にしています。

Problem

横軸に頻度、縦軸に影響度をとったメトリクス図を追加しています。 Problemの原因追求をしていく時、全てのProblemを議論していると時間が足りません。重要度を明確にし、話し合うべきProblemをわかりやすくするために、メトリクス図を元に付箋を貼っています。付箋の位置で、エンジニアメンバー全員のそのProblemへの重要度の認識を合わせられるので、議論もスムーズに進みます。

Action

実際に実行するタスクを貼る項目です。
Tryでは試したいことを出していき、その中から実際に実行するタスクを選んでいきます。KPTのTryではシートからどれが実施するタスクなのか目印を付けないとわかりません。そこで、Actionという枠を作ることで明確にしています。Actionはそのタスクのtodoリストのような役割になります。

GKKPTAの進め方

  1. 前回の「ふりかえり」のActionとKeepとProblemをチェック
  2. KeepとGoodとProblemを出していく
  3. KeepとProblemを共有する
  4. Tryを出していく
  5. Tryの中からActionに移すものを多数決で決める
  6. Actionの担当者を立候補で決める

前回の「ふりかえり」のActionとKeepとProblemをチェック

Actionのチェックでは、Actionの実行によって解決したProblemを剥がしていきます。Keepのチェックでは、Keepで定着した付箋を確認して、Knowledgeに移していきます。

Keep(Good含む)とProblemを出していく

時間短縮のため、KeepとProblemはその場で考える時間は設けず、事前に書いてきてもらうようにしました。もう一つの効果として、その場の短い時間で良かったこと、困ったことを考えるとなかなか思い出せなかったりするのですが、事前にゆっくり考えたり、日頃から書き溜めることでKeepとProblemを出しやすくする狙いもあります!

KeepとProblemを共有する

KeepとProblemの共有では、前のステップで出したKeepとProblemについて、何が良かったのか、何が原因だったのかを掘り下げて、問題の本質を探っていきます。 全部の問題を議論していると時間が足りなくなるので、メトリクス図で優先度を決め、重要そうなものを中心に話し合っていきます。 議論が白熱したり、発散(笑)しやすくなるので、そこをうまく仕切る腕が司会の人に試されるステップでもあります(汗)。

Tryを出していく

質より量を意識して、ブレストのようにTryを出していきます。 実現可否はおいてといて、やりたいこと、改善できそうな案をとりあえずだしてもらうことで、意外な改善案が出ることを期待します。

Tryの中からActionに移すものを多数決で決める

Tryの中から次の「ふりかえり」までに実行したいものをActionに移して行きます。この時、自分が担当者になるかは別にして、そのTryをやるべきかどうかで挙手してもらいます。挙手した人がやればいいとなると挙手しづらくなるので、そのようにすることで積極的な挙手を促しています。過半数を超えたらActionに移します。
今回の「ふりかえり」でActionにならなかったTryには2ヶ月の期限を付けてシートに残すようにします。以前は、今のタイミングではなかなか実行できないがすぐ剥がすほどじゃない微妙なTryが、シートに残り続けてしまっていました。せっかく出してくれた意見を剥がすのはもったいなぁと思っていたのですが、期限をつけて、過ぎたら剥がすようにすることで、スッキリした運用ができるようになりました。2ヶ月という期限はなんとなくでつけたのですが、いい感じで回せているので、このままで続けて様子を見てみたいと思っています(笑)。

Actionの担当者を立候補で決める

立候補でActionの担当者を決めています。自分から手を上げてもらうことで、「ふりかえり」への当事者意識を持ってもらう狙いがあります。 エンジニアメンバーがプロジェクトのスケジュールなどで忙しく、誰も担当者が決まらない場合は、期限をつけてTryに戻します。

実際の「ふりかえり」風景

linoの一つのアカウントをエンジニアメンバーで共有して、各々が自分のPCから付箋を貼りながら意見を出していっています。 f:id:sys_wwwave:20170807093139j:plain

まとめ

ウェイブで使っているKPTをベースとしたGKKPTAというものを紹介いたしました。
最初はエンジニアメンバーだけで始めた「ふりかえり」も、一部のプロジェクトでは企画メンバーも含めた形で実施されるようになりました! 私達もまだ試行錯誤している段階ですが、KPTがうまくいかないという方に何か参考になれば幸いです。