KPTがうまくいっていないと感じている人たちへ

saitotakahiroPosted by

この記事はGRIPHONE Advent Calendar 2021 14日目の記事です。

こんにちは、バックエンドエンジニアの斎藤です。
今回はチーム運営としてKPTを実施しているけど、イマイチうまくいっていないと感じている人たちに向けて改善提案をさせていただきます。

はじめに

チーム運営において、課題解決を目的にKPTを実施しているプロジェクトは多く存在すると思います。

しかし、KPTをやっていても”なかなか効果を実感できなかったり”、”Tryが貯まっていくだけで実践する時間がとれなかったり”することがあると思います。

ここでは “なぜうまく行かないのか” を掘り下げて、では “どうすれば上手くいくのか” について、私なりのやり方を共有して行きたいと思います。

なぜKPTがうまくいかないのか?

KPTがうまくいかない理由は大きく2点あると思っています。

  1. チーム内の方向性が定まっていない
  2. Tryを決めるだけでいつどうやって実行するかを決められていない

チーム内の方向性が定まっていない

漠然とKPTを実施していると、玉石混交の項目があがってきて、個人的なProblemだけどチーム的には重要度が低い課題にまで対応してしまい、そちらにリソースを割かれて本当に大切なProblemの対応ができなくなってしまうことがよくあります。

ですので、KPTを実施する際はまずチームの目指す目標をしっかりすり合わせる必要があります。私はチームビルディングの一環としてよく価値観ブレスト(造語)を実施しています。

価値観ブレストとは?

価値観ブレストとは、メンバーそれぞれがチームとして求めている価値観を明らかにするブレインストーミングのことです。

今回のケースでは下記3点についてメンバーの価値観を深堀りすると良いです。

  • プロダクト視点
    • 今のプロダクトをどうしたいのか?
  • チーム視点
    • 理想的なチームはどういうチームか?
  • エンジニア視点
    • どういうエンジニアになりたいのか?

これらの質問をメンバー1人1人にヒアリングし、お互いが何を求めているのかをはっきりさせ、全員が納得できる方向性をすり合わせます。

目標の方向性がすりあったならば、目標に沿ったタスクのみ実行するように取捨選択をしていけば、上記の図のように効果的に目標とする状態に近づけることが可能になります。

Tryを決めるだけでいつどうやって実行するかを決められていない

チーム運営では日々Problemは発生しています。
それに対して都度Tryも決めていくとなると、Tryの数も大量になってしまいます。

大抵の場合はTryの内容は決めるけど、いつ誰が対応するのかまで決めきれず、結局個人任せの運用になってしまいます。

結果として、Tryだけ大量に積まれていき、負担だけ増える悪循環にハマってしまいます。

ではどうすれば良いのかですが、当たり前なのですがTryを決めた時に “いつ誰がどうやって対応するのか” までしっかり決めきるようにします。

今回はバックエンドエンジニアにおける実践例を紹介します。
「運用●年目のゲーム開発チーム」を想定してみて下さい。

運用の長いチームほど技術負債が貯まってきて、解消するにしても運用時の機能開発でリソースがいっぱいになって改善対応の時間が取れないことがよくあります。

そういう際に下記のような分類毎にTryのやり方を変えています。

  1. 規模の大きい案件
  2. 規模の小さい案件
  3. チームで共通認識を持ったほうが良いような案件

規模の大きい案件

規模が大きくすぐに対応できないような案件は、重要だけど緊急じゃない案件がほとんどです。

そういう場合はいつまで経っても対応する時間ができることはないので、通常の機能開発と同列としてしっかりスケジュールを決めてリソースを確保して対応するしかありません。

この際、チームに対してしっかりと説明して納得してもらう必要があるので、本当に重要な案件だけこちらで対応しています。

規模の小さい案件

規模の小さい、数時間で対応可能な案件は、定期的に時間を設けてその時間内に対応するようにします。
私のチームの場合は週一で1時間確保し、Tryに関するタスクを確実にさばくようにしています。

こちらは「規模の大きい案件」ほど重要でなくても良いので、とにかく一個一個確実に実行することで、KPTとしての効果を実感しやすくなります。

チームで共通認識を持ったほうが良いような案件

チーム内で共通認識を作りたい案件はモブプロや勉強会を実施しています。

プログラム内の共通処理のリファクタリングとかメンバーがみんな触る可能性がある処理ではチームメンバー全員が見ている中で議論しながら実装します。

また、PHPの最新のバージョンにバージョンアップする際などでは、最新バージョンで追加される機能についてみんなで確認しながら、どれをチームに導入するかを話しながら認識をすり合わせたりしています。

おわりに

今回の内容を軽く図にまとめてみました。

それぞれのチームにとって状況は異なるとは思いますのでそのまま導入できないとは思いますが、何かしらチームを改善するヒントを得られたのなら幸いです。