はじめに
こんにちは、テクニカルディレクターのTSUZUです。
みなさんKPTは好きですか？
「KPTなんて知らんがな、海外のプロレス団体か何かかよ」
って感じでこのページを閉じようとしてる人もいると思うんですが、まぁまぁ少しだけ思い留まって以下のページなどを見てもらえると嬉しいです。
【徹底解説】正しい「KPT」が仕事の成果を生み出す！進め方のコツ、現場の事例を紹介
ざっくりいうと
- Keep : 継続してやっていきたいこと
- Problem : 今現在の困りごと
- Try : これから試みること
を話し合ってプロジェクトいい感じに回してこうぜ、っていう定期的に行う振り返り会みたいなものですね。
KPTを行うことで、「いいところをお互いに褒め合い、困ってることについて話し合い、課題の解決に向けてやること決める」というのを1つの会議でまとめてできるわけです。
そのため、最近ではさまざまな企業で取り入れられるようになったそうです。
僕はBiTT開発事業部という部署におり、この事業部ではシステム開発やアプリ開発をセブのメンバーと一緒に行っています。そのため、社内外問わず、時には英語でミーティングをリモートでやっています（通訳を担当されている皆様いつもありがとうございます！）
最近オフィスに行かずに在宅勤務で仕事をする会社が増えている関係で、対面で実施してたKPTをリモートでやることになってさぁ大変、という話をちらほら聞くようになりました。
というわけで、リモートKPTで工夫していることについて書いていきます。もちろんKPT自体のやり方についてもざっくり説明しますし、KPT以外のリモート会議で使える知識もあります。
アルファベット3文字を見るとすぐに海外のスポーツ団体を思い浮かべちゃう、2年前の僕みたいな人にも読んでもらえると嬉しいなぁと思います。
目次
KPTで使うもの
オフライン時のKPTで使うもの
多く、KPTでは以下の道具を使います。
- ホワイトボード
- 付箋
- ペン
「このご時世にそんなアナログな」って感じだと思うんですが、意外とこれが主流なんですね。
いろんな理由があると思うんですが、「ホワイトボードに向かって色々書いたり、付箋貼ったり剥がしたりするのがかっこいい」というのがまずは挙げられるかと思われます。
ただ、リモートだとこれらが全部使えないので、ドヤ顔で付箋をペタペタすることができないのが非常に悔やまれますね。
リモートKPTで使うもの
そのため、僕たちは以下のようなスプレッドシートを使ってKPTを行っています。
もっと大層なツール使ってるのかと思って期待していた方、ごめんなさい。もちろん、導入時にTrelloやAsanaなどのかんばんボード機能を使う方法も検討しました。ただ、僕たちBiTT開発事業部はクライアントワークが多く、お客様ごとに使用するツールもまちまちだったりします。
そのため、どのお客様でも大抵は使用されているGoogleスプレッドシートをメインとすることにしました。使用するツールについては、プロジェクトごとに使い慣れているツールを適宜選択してもらうのがよいと思います。
気をつけていること3選
1.Keepはめっちゃ出す
リモートだと基本的にはテキストベースでの会話になるので、僕みたいに文章力のない人間は感謝の気持ちが正しく伝わってなかったりする場合があるんですね。
なので、対面で感謝の気持ちを伝えられるKeepの時間にはここぞとばかりにお礼をいうとよいのかなぁと思ったりしています。
ここでは個人名挙げて感謝を伝えても全然OKでよすね。「あのときは助かったよJhon! どうもありがとう!!」みたいな。
セブとやるときは拍手とかしちゃいますもん。
「Thank you so much!!」「Oh yeah!!」とか言っちゃって。
2.Problemで個人名は挙げない
一転して、Problemでは個人の問題を指摘するのではなく、プロジェクト全体の課題について検討するのがよいとされてるみたいです。
例えば僕が上司に「TSUZUさんの書くコードが全然イケてなくて、もううんざりなんすよ」と言われたとします。
すると何が起こるかというと、次の日から僕は謎の腹痛に見舞われ、二度とその姿を見るものはなかった……みたいなことになりかねないわけです。
上記は大袈裟だとしても、個人名を挙げてしまうと、いろんな人がいる場でその人だけを指摘する格好になってしまい、KPT実施に対して前向きな気持ちを持ちづらくなりそうです。
そういうのは1on1とかの方が向いている気がします。
例え個人に紐付く課題があったとしても「担当エンジニアごとにコードの品質に差がある」みたいな言い方をしる方がよさそうです。そこから「じゃあプロジェクト全体としてどういう改善ができるんだろう？」という提案ができそうですね。
3.Tryは次回の実施までに解決できる粒度で
実施期間が隔週なら2週以内で、1ヶ月ならそれ以内で解決できるTryを出したほうがいいみたいです。
月一のKPTで半年かかるTryを定めてしまうと5ヶ月間はそのTryが残り続けるわけで、「せっかくKPTやったのに課題解決している感じがしないなぁ……」みたいになってモチベーションが低下しちゃいます。
KPTは1回やって終わりじゃなくて、定期的にやってプロジェクトを改善していくのが目的です。気長にやっていこうじゃないですか。
半年かけないと解決ができないTryが出たときは「次のKPTまでに、ここまでは解決しよう」みたいに課題を分割できるとよさそうですね。
おわりに
お読みいただきありがとうございました。
少しでも皆さんの助けになれば幸いです。
以上、テクニカルディレクターのTSUZUでした。
