ストレッチ専門店 Dr.stretch を運営する 株式会社nobitel でシステム開発に取り組んでいる 奥山 と申します。
私が所属する開発チームでは Dr.stretch の各店舗のトレーナーが日々行っている予約管理、顧客管理、会計等を行うための社内システムの開発・保守を行なっています。
メンバーが4人（うち1人はマネージャー業務も行なっている）と少ないですが、フロントエンド・バックエンドのリプレースおよびリファクタの開始や、現場の声をより把握するための他部署への露出など、特に今年は大きな転換が多かったと思っています。
その過程で、「良かったこと・改善が必要なことをノウハウとしてまとめて今後の開発に活かしたいよね」 という話がチーム内で挙がったため、1ヶ月毎にチーム振り返りをする場を設けることにしました。
この記事では振り返りで採用した "GKPT" についての簡単な紹介と、振り返りを行なってチームがどう変わったかについてお話しします。
振り返りを実施する前の状態
開発メンバーは社内業務のやりとりで Slack を使用しています。
メンバー毎に times_◯◯◯ のような個人用チャンネルが用意されてあり、業務の状況をリアルタイムで報告したり後日に振り返れる状態を作っています。
悩んでいる様子があれば他メンバーがヘルプを出すという場面も多くみられます。
(times の運用についての具体的な説明は記事が多くあるためここでは割愛します)
times 運用自体は便利なのですが、ノウハウやその時何を思っていたのかが分散し検索性があまりよくないという課題もありました。
新メンバー（私）が加入してしばらく経った時期というのもあったので、この機会に振り返りの場を設けようとなって導入したのが GKPT でした。
GKPT とは？
"KPT" というフレームワークが有名ですが、今回採用したのは "GKPT" です。
このフレームワークについて具体的にまとめられている記事がチームメンバーから共有され、振り返りの際に活用できそうということになり運用することにしてみました。
参考元はこちらになります。
KPT に対して "Good" 要素を追加したのが GKPT です。
Keep : 継続して今後もやっていきたいこと
Problem : 問題になったこと、改善が必要なこと
Try : Problem を解決する具体的な方法
Good : 直近の開発でよかったこと、改善したこと ← New!!
Keep を増やしてチーム力を上げるのが目的ですが、 Problem -> Try -> Keep とは別に Good -> Keep のルートが増やせるのが GKPT のメリットです。
ちなみに上記の記事自体は2015年のものですが、2021年に Twitter(現:X)まとめサイト Togetter に「KPT (Keep/Problem/Try) 等のふりかえりで、K (Keep) ネタを増やすみんなの工夫」という内容のまとめがあり、その中でもこの記事が紹介されていました。
実際の様子
ホワイトボードに付箋を貼っていきそれを適宜移動したりまとめたりするのがよくあるやりかたですが、フルリモートのメンバーがいるためホワイトボードは外部のオンラインサービスを使っています。
枠が手書きなのはご愛嬌ということで
以下のような流れで進めています。
- 各個人で Good, Keep を付箋の形で列挙する
（達成できた Try があればこのタイミングで挙げる） - 全体でディスカッションしながら必要に応じて Good を Keep に移動する
- 各個人で Problem を列挙する
- 全体でディスカッションしながら Try を作る
ディスカッションの時間に比重を寄せてだいたい1時間くらいになっていますが、メンバーが増えるとディスカッションの時間も増えるはずなので、各個人での列挙だけ事前にやってもらうやり方もありだと思います。
ちなみに上記のオンラインサービスは Google Jamboard なのですが、2024年末でサービスが終了するようなので今後は別のサービスを使おうと思っています。
やってみてどうだったか
課題を顕在化させつつ Next Action を決められた
各々が感じる課題を並べてチームで議論する場がそもそもなかったので、 times の中に埋まってしまっていた課題をこの場で拾えたのは良かったです。
メンバー数が少ないので埋まっていた課題の数もそこまで多くはなかったですが、より多いメンバーがいるチームだとこの効果がさらに大きくなると思います。
また、課題に対する Try もこの場ですぐに議論されることになるので、メンバー間で重要度やボリュームの認識が合っている状態となり、 着手〜完了までの時間が短縮された と思います。
この話は GKPT ではなく KPT でも同じことが実現できますが、以下の2つの点は GKPT だから引き出せたことだと思います。
チームの品質を Keep しやすくなった
Good は大きく「直近の開発のみに関するもの」「以降の開発にも関係するもの」に分かれると思います。
後者が Keep に移動することがほとんどであるため、 KPT だと潜在化していた Keep を引き出すことができるようになりました。
また、個人がいいと思っていたことが結果的にチームの継続目標に変化することもあるので、これも GKPT ならではの特徴なのかもと思いました。
メンバーのモチベーションアップに繋がった
フロントエンドを React にリプレースすることになった際、業務で React を使ったことがあるのが私ともう1人だけでした。
そのため他メンバーに対して React について教えつつレビューも行っていたのですが、
「○○ さんから新しく ○○ について学んだ」
といった話がバイネームで Good として挙がり、教えていた立場としてはとても嬉しいものでした。
教える立場でなくても チームの底上げを感じれる機会 になりましたし、ノウハウの積み上げにも繋がったのではないかと思っています。
終わりに
まだ GKPT を採用したばかりではありますが、現時点でもいいと思えることが多いため今後もこのやり方を続けてみたいと思います。
やり方を変えたなどあればまた同じように発信したいと思います。
弊社では我々と一緒に改善に取り組んで下さるエンジニアを募集しています！
Discussion