プロダクトとチームの課題を解決する「KPT」

こんにちは、デザイナーの西尾です。即戦力人材と企業をつなぐ転職サイト「ビズリーチ」でUIデザインを担当しています。

私が所属する「ビズリーチ」プロダクトチームは、2018年2月現在でPM（プロダクトマネージャー）が約5人、エンジニアが約45人、デザイナー／フロントエンドエンジニアが約10人と、社内では比較的大所帯のチームです。その中でも求職者様向けのC側と、企業様向けのB側、インフラでチームが分かれ、さらにプロジェクトごとに小さなチームに分かれて、日々プロダクト開発に取り組んでいます。

大規模なプロダクトなど関わる人数が多くなると、例えば納期遅延やミスコミュニケーションによる情報伝達ロスなど、大小様々な問題が起こるのではないでしょうか。それは、私たちのプロダクトチームにおいても同様です。

そんな時、私たちは「KPT（ケプト）」を用いて解決しています。今回は、その解決方法「KPT（ケプト）」についてご紹介します。チームの課題解決や、チームビルディングなどに役立つ情報をお届けできれば幸いです。

KPTとは？

KPTとは、Keep／Problem／Tryの三単語の略で、プロジェクトや行動を振り返る際に、下記の3つに分けて整理するフレームワークです。

• Keep:良かったこと、続けていきたいこと
• Problem:悪かったこと、改善すべきこと
• Try:次に試すこと

プロジェクトや行動における「Keep」と「Problem」をチームメンバー個人で書き出し、「Keep」「Problemに」から、次に試す「Try」をチーム全員で意見交換しながら導き出すのがKPTの基本です。

KPTはチーム単位で行うこともできますが、個人単位でも十分に有効な振り返り手法です。前述したように「Keep」や「Problem」の書き出しはあくまでも個人で行うので、社内では個人の振り返りとして活用する人もいます。

「ビズリーチ」プロダクトチームのKPTの進めかた

「ビズリーチ」のプロダクトは、二週間単位でリリースサイクルを回しており、毎回KPTを行いリリースを振り返るようにしています。 KPTメンバーはプロジェクト単位の、PM、エンジニア、デザイナーの合計６～７名ほどです。ビズリーチでは、「MTGは基本的に25分以内」という全社ルールがあります。そこで限られた時間で終わらせるために、事前に下記をスプレッドシートに記載しています。

• Keep（開発する中でよかったこと、続けたいこと）
• Problem（開発する中で問題だったこと）
• Try（Problemを解決するために次にやること） これらを元に、当日はファシリテーターが進行して振り返りを進めます。

実際にどのような振り返りがあったか？

KPTにおいて出た声を、一部ご紹介します。

【Keep】

• エンジニアAさんからのタスクリマインドのおかげで直前で慌てることなく、無事にプロダクトをリリースすることができた（byデザイナー）
• PMのレビュー会で、施策のコンフリクトにMさんが気づくことができ、直前での仕様変更を回避することができた』（byエンジニア）

Keepは基本的にポジティブな内容が多いです。普段あらたまって言わないことでも、みんなで共有することでチームの雰囲気がより良くなり、心理的安全性の醸成にも繋がっています。 次に、Problemで上がったことと、それを解決するためのTryの一部です。

仕様のすり合わせについて

【Problem】

• 『仕様が詰め切れていなかったため、リリース直前で仕様漏れが発覚しバタバタしがちだった』（byエンジニア）
• 『仕様を詰め切れておらず作業しながら要件定義を進めたため、リリースが遅れてしまった』（byエンジニア、デザイナー）
• 『エンジニアの中では、既存のスタイルを踏襲してすすめると思っていた機能が、実は新しいデザインが必要だとあとから気づいた。、上流工程の段階で連携ができていればよかった』（byエンジニア）
• 『ワイヤー段階でユーザー体験を細かいところまで意識できておらず、実装直前での文言修正や表示タイミングの仕様変更が生じた』（byデザイナー）

仕様のすり合わせがスムーズに行えていなかったという意見が目立ちました。 大規模なプロダクトではと画面数が多く、仕様も複雑になってきます。もちろん関わる人数も増えます。その際、デザイナー・エンジニア・PMはそれぞれ連携して仕様の認識やスケジュールに齟齬がないようにすすめていかなければいけません。 それを解決するTryは下記のようにまとまりました。

【Try】

• プロジェクトチーム内で進捗状況をこまめに共有するために、毎朝毎夕5分ずつ進捗共有する時間を設ける

その結果、うまく作業が進んでいないときもすぐにアラートをあげることができたり、リカバリできる状態を保てるようになりました。 この他に出されたTryは、

• 職種にかかわらず、担当する案件にアサインされたメンバーは職種を超えたレビュー会に参加する。（例えば、エンジニアがデザインレビュー会に出る、デザイナーがPMレビュー会に出る、など）

これにより、職種間での仕様理解の差異が減少し、前提を共有できているので、より円滑なやり取りができるようになりました。

効果検証について

また、グロース施策を行った後の効果検証が十分に行えていないのではという意見もPloblemで上げられました。

• 施策を打つ前後の分析や考察が浅い（byエンジニア）
• 施策の効果検証計画が薄い（byデザイナー）

これに対するTryは、

• 施策の効果検証用シートを作って、定期的にチームで数値を共有する会を設ける。

その結果、デザイナーやエンジニアも施策の数値効果を意識できるようになりました。数値を読み解くことで原因を考えたり、ネクストアクションを提案する動きも生まれはじめました。

KPTを取り入れて変わったこと

上記は一部の具体例ですが、チームでKPTを行うことで、プロダクトの理解や個々人のチームに対する意識がより強くなり、下記のような効果がありました。プロダクトの品質向上はもちろん、チームビルディングや、デザイナーの発言や行動においてもよい方向に転じているなと感じています。

• デザイナー、エンジニア、PMの連携やコミュニケーションが密になり、仕様漏れやバグが減少したため、スケジュール通りに進められるようになった。
• 以前は遅延した理由を知らなかったが、KPTによって理解が深まり、他職種をリスペクトするようになった。
• 普段なかなか話さない感謝の気持ちを改めて伝えることで、チームの雰囲気がよくなった。
• リリース後施策の効果共有を行うことで、デザイナーの数値意識が高まった。
• 職種を超えたコミュニケーションにより仕様理解が深まり、デザイナーも積極的に開発に加わることでデザイナーの影響力が上がった。

さいごに

このように、「ビズリーチ」プロダクトチームでは定期的にKPTを行い、リリースだけでなく、個人の振る舞いやチームのあるべき姿について振り返るようにしています。

個人が普段感じているけれども言い出せない課題感も、KPTという場を活用してチームに共有することができ、具体的解決策まで落とし込めるようになりました。

さらに、職種によって差があった仕様理解や数字意識を、全職種で共有できたことで、私たちデザイナー自身が、PM・エンジニアと一緒になって、積極的に開発やチーム作りに参加できるようになりました。

プロダクトのリリースだけでなく、他のプロジェクトや様々なチームにおいてもKPTは有効な課題解決や連続的な成長のための手段だと実感しています。私たちのチームでも、これからも活用しより良いチーム、プロダクトを作っていきたいと思います。