レトロスペクティブを導入した理由

これまでプロジェクト単位での振り返りはしていたのですが、プロジェクトの期間が長く

気になったことを忘れてしまう
改善のスピードが遅い

といった問題が発生していました。

そのため、スピード感を持って気になったことを改善していくための仕組みとしてレトロスペクティブを取り入れました。

レトロスペクティブの進め方

レトロスペクティブはスプリントの最終日にエンジニアのみで30分程度行っています。

KPTという振り返りのフレームワークを使用して、

良かったこと
気になること
今後取り組むこと

をブレストする形にしています。

「今後取り組むこと」には担当者をアサインして、その人がリーダーシップを持って解決まで進める形にしています。また、翌週に取り組みの進捗などをチーム内で確認するようにしています。

レトロスペクティブを通して改善したこと

2023年5月末くらいからレトロスペクティブを開始したのですが、実際に改善したことをいくつかリストアップしてみます。

プランニングポーカーの導入
アプリチームとの連携方法の検討
デイリースクラムの導入
コードレビューを朝と夜に必ず行うようにルール化
QAフローの整備とドキュメント作成
スクラム勉強会の開催
今後取り組む予定の課題の内容を事前に把握して設計や仮実装を行う体制を構築
課題の起票フォーマットの作成
会議のファシリテーターをローテーション制に変更

上記で挙げたもの以外にも改善したことはいくつかあるのですが、この中から3つほど取り上げて詳細に説明したいと思います。

プランニングポーカーの導入

これまではタスクの担当者を1人決めて、「その人が頑張る！」といった進め方だったのですが、このやり方だと

見積もりが担当者だけの感覚値になってしまうため、既存仕様の把握漏れがあった場合に見積もり以上の時間がかかってしまう
チームメンバーがどういったタスクを進めているのかわかりにくい
（チームメンバー間でタスクの内容を把握していないので）困った時にチームメンバーに相談しづらい
設計に不備があった場合にレビューのタイミングで大きな手戻りが発生する

といった問題が発生していました。

そこでプランニングポーカーを導入し、チームメンバー全員で一つ一つのタスクを細かく分割した上で見積もる形にしました。見積もりのタイミングでチームメンバー同士で話し合ってざっくりとした設計も行うようにしています（APIのエンドポイントや簡単なClass設計など）。

このようにすることで、チームメンバー同士がどういうタスクを行なっているか把握できるようになりました。さらに、タスクを細かく分割しつつ設計も一緒に行なっているので、担当者が困った時に適宜サポートを行ったり、タスクを受け渡すといったこともできるようになりました。

デイリースクラムの導入

これまではチーム内で日々の情報共有を行っていなかったので、スプリントの終盤になってタスクが終わらなそうというアラートが上がる問題が発生していました。

そこで、毎日の終業間際にデイリースクラムを導入して日々の情報共有を行う場を作りました。

これにより、いつでもアラートを上げて問題を相談できる場ができて、スプリントの終盤でアラートが上がるといったことは起きなくなりました。また、チームメンバー内でタスクの受け渡しを行うなどサポートし合う動きが生まれるようになりました。

コードレビューを朝と夜に必ず行うようにルール化

これまでは明示的にコードレビューの時間を設けていなかったため、スプリントの終盤までコードレビューがされずスプリントが終わるギリギリでコードレビューが行われていました。スピード感を持ってユーザーに機能を届けることが求められているのですが、コードレビューが障壁になりリリースが遅れるという事態が発生していました。

そこで、始業後と終業前のタイミングとコードレビューをする時間を明示的に設けるようにルール化しました。また、チームメンバーで画面を共有してコードレビューをしながら話し合う場も用意しています。

これにより、コードレビューがされずにリリースが遅れるといった自体は発生しなくなりました。

レトロスペクティブを導入した感想

レトロスペクティブを導入したことで、日々生まれる課題に対して積極的に取り組むことができるようになったと思います。導入前の問題として挙げていた「気になったことを忘れてしまう」や「改善のスピードが遅い」も無事に解決されたと思います。さらに、何か課題が生まれた時に前向きに改善しようという姿勢がチーム内に醸成されており、雰囲気も以前よりよくなった気がします。

今後もレトロスペクティブを通して新たな改善に取り組んでいきたいです！