振り返りはカイゼンの元
こんにちは！
自炊する時に毎回といっていいほどニンニクに頼ってしまう、HITO-Link CRM開発チームの近藤です！
今回は題名の通り、HITO-Link CRM開発チームがどんな振り返りしているのかをご紹介したいと思います！
HITO-Link CRM開発チームの振り返り
開発チームでは主に下記の3つの単位での振り返りを「KPT」という手法を使って行っています。
・Sprint毎の開発振り返り
・テスト振り返り
・クォーター毎の開発振り返り
これらの振り返りを行うことで様々な「カイゼン」が出来ました。
なので今回は各単位でどんな趣旨で振り返りをしているのかをご紹介できればと思います！
※「KPT」については、」詳しく書いてある記事が数多く存在するので、気になった方は調べてみてください！
Sprint毎の開発振り返り
・趣旨：2週間のSprintの間に出た、続けていきたいことや問題点を振り返る
この振り返りでは2週間Sprintの開発面についての振り返りを行っています。
実装や開発プロセスの良し悪しを振り返り、問題点はそのままにせずに具体的なタスクに落とし込むことまでを行ってます。
実装しずらい、後々技術負債になりそうなど、開発してて些細でも思ったことを出し合うことで「カイゼン」の種を生み出すことが出来るので、些細なことでもディスカッションするようにしています。
上記のような振り返りを行った結果、Sprint毎の開発振り返りからは下記のような「カイゼン」が生まれました。
・処理を簡潔にするためのリファクタリング
・UTコード実装の効率化
・事前設計のプロセスの改善
テスト振り返り
・趣旨：発生バグやテストプロセスについて振り返る
この振り返りではテスト面の振り返りを行っています。
発生したバグの傾向を話し合ったり、テストプロセスの良し悪しを振り返り、上記の振り返りと同じように具体的なタスクに落とし込むことまでを行ってます。
テストで発生したバグについては、今回発生したものだけを見てもなかなか「カイゼン」は出てこないので、前に発生したバグも念頭に置きながらディスカッションをするようにしています。
上記のような振り返りを行った結果、テスト振り返りからは下記のような「カイゼン」が生まれました。
・テスト観点の継続的なアップデート
・テスト仕様書作成フロー改善
・バグ管理方法の改善
ちなみに上記のテスト仕様書作成フロー改善では、仕様書作成を開発プロセスの最初に行うようにし、開発プロセスをテスト駆動的フローにすることが出来ました👏👏
クォーター毎の振り返り
・趣旨：クォーター毎の開発全体について振り返る
この振り返りではクォーター毎の開発全体の振り返りを行っています。
そのクォーターで何をしたのかを振り返りながら、俯瞰的な視点で開発全体の振り返りを行っています。
開発チームだけでなく、デザインチームやビジネスチームとの関わり合いも視野に入れながら、このクォーターの良し悪しを振り返りを行うようにしています。
上記のような振り返りを行った結果、クォーター毎の振り返りからは下記のような「カイゼン」が生まれました。
・開発プロセスの改善
・デザインプロセスの改善
・プロダクトレビューの実施方の改善
まとめ
今回HITO-Link CRM開発チームの振り返りについて書いてきましたが、
振り返りは「高頻度・狭いスコープ」で行った方がいいと感じました。
上記で紹介した単位の振り返りを行う前は低頻度で、広いスコープの振り返りをしていました。この時は振り返りの密度が低くくなってしまい、なかなか「カイゼン」に繋がらないことが多々ありました。
なので皆さんも「高頻度・狭いスコープ」で振り返りをやってみてはいかかでしょうか！！！！
▽どうでもいいこともつぶやく近藤のTwitter
▽HITO-Link CRMについて
▽弊社コミュニティのエントリーフォームです
この記事が気に入ったらサポートをしてみませんか？