Wantedly 開発チームブログ
エンジニアの森田です。
チームでKPTをやってみました。その時に考えたことなどを書きたいと思います。
社内発表資料です。
アジャイル開発や反復型開発ではイテレーション(繰り返しの単位)ごとに作業の振り返りが推奨されるが、そのためのチーム反省会などでよく用いられるフォーマットである。
http://www.itmedia.co.jp/im/articles/0905/19/news143.html
KはKeep、PはProblem、TはTryをそれぞれ表します。イテレーションの単位でチームで振り返りを行い、良い点(Keep)、問題点(Problem)、具体的な改善項目(Try)を軸にミーティングをします。基本的な流れは、Problemが具体的なTryになり、Tryが解消したら、消える。またはKeepに昇華します。KeepはProblemやTryに関係なく、上げていくこのが良いと思います。
社内で新規サービスを作ることになり、4名のチームが結成されました。サービス自体、アイディアのみがある状態から始まったので1週間ごとに見た目や機能が変更されていきます。既存のサービスのメンテナンスとはまた違う状況で、よりよいコミュニケーションとプロセスを作っていこうとやってみることにしました。
イテレーションの単位は1週間。会議室に集まり、タスクの棚卸を行った後に実施しました。扱う内容は、現在開発中のプロダクトを中心にはするものの特に限定はしませんでした。プロダクトの改善や方向性などを話しましたが、扱う内容で一番多かったのは仕事の進め方に関するものでした。
KPTというとホワイトボードに付箋というのが一般的ですが、私たちのチームでは、 Coggle というオンライン・マインドマップ・ツールを利用しました。
ホワイトボードに書き出すことと比較すると利点は下記の通りです。
決めたルールは「批判しない」ということのみです。目指すところは、チームでよいプロダクトを作ることです。できているひとができていない人を批判して、批判された人が心を入れ替えるということではありません。そして、リラックスした状態で、ただ、仕事をする上で「問題に思っていること」「改善したいこと」「うまくいっていること」を共有しました。
普通、ProblemがTryになり、それがKeepになるという流れがありますが、私たちのチームでは、Problemに対して、Tryにすることなく、そのままProblemでいつづけることがありました。TryになりやすいものはTryにして解決していくのですが、なかなかそうなりづらいものもあります。そういうものに関してはも書き出しておくことで、2,3週間すると改善案が出てきて自然と消えていったりしました。
チームは僕以外KPTは初めてで、最初は、K、P、Tそれぞれどのような基準で出せば良いのかわかりませんでした。特に決まったルールもないので、各自、自身の判断で上げていきました。量もとても多くなったのですが、数を重ねていくうちにチーム内である程度共通の認識が生まれて、項目数も少なくなってきました。
多岐に渡るのですが、目立つものとして、
などなどです。
目の前の問題を解決するといったわかりやすいよさもありましたが、それと同じかそれ以上に良いと思ったのは、もう少し形のない問題について話すことができたことです。継続的学習や、サービスの本質、日々ちょっとだけ困っている細かいことなど。 日々ちょっとだけ困っていること というのは、とても重要で、それを共有することで答えを持っている人が見つかり、改善していくことができました(ちなみに僕はGithubの@メンションを見落としがちということなどを書きました)。
小さな問題を一つ一つ解消していくことで、最初は、殆ど変化がないように感じられますが、それを繰り返してゆくことで少しずつ業務の無駄がなくなり、知識も共有され、チーム感が出てきたように感じています。
改善に関する格言を調べてみると、このようなものが見つかりました。
Continuous improvements in any area eventually transform the operation.
ピータードラッガーの言葉なのですが、自分なりに訳すと「継続的な改善は全てを変える」ということになります。継続的に改善を続けていくことで、最初は小さな変化かもしれないのですがそれが少しずつ積もって、足腰が鍛えられ、物事がうまく回るようになります。それを繰り返していくことで、始めた頃とは全く異なるような成長を遂げられるのではないかなと思いました。