以前所属していた組織では振り返り文化が根付いていましたが、今の組織ではプロジェクトが終わった、または一段落ついた時に振り返る文化があまりなかったので、担当プロジェクトで振り返りを行ってみたので共有します。
プロジェクト振り返りの目的
以下のような目的を持って行いました（根付いている会社では普通のことかもしれません）
- 担当したプロジェクトの経験を次のプロジェクトに活かす
- 組織全体のノウハウを蓄積する
プロジェクト振り返りだけではなく、障害やインシデントのような大きなトラブル時でも同様に行った方が効果があります。
振り返りの方法
今回の振り返りではKPTを利用しました
KPTとは
プロジェクトを「Keep（続ける）」「Problem（問題）」「Try（挑戦）」の3つの観点で振り返るフレームワークで、良かった点、悪かった点、次へのアクションが明確になり、チームの改善サイクルを高速化する手法です
実際に用いた手順
- ホワイトボードやオンラインツール（Miroなど）を使い、KPTのフレームを用意する
- 今回はMiroを利用
- 書き出し：時間を決めて付箋等にKeepとProblemを思いつく限り書き出す（個人作業）
- 共有・グルーピング：参加者で付箋を貼りながら共有して似た内容を纏める（共同作業）
- 深掘り・Tryの決定：Problemの原因を話し合い、解決策をTryとして具体的に設定する（共同作業）
- 担当・期限の決定：Tryを実行する担当者と期限（次の振り返りまで）を明確に決める（共同作業）
今回行った振り返り
担当したプロジェクトはAIを用いたレコメンドサービスの開発でした（実案件を書けないのでボカシて書いています）
書き出しやグルーピングした内容
- Keep ※一部を抜粋
- システム監視のノウハウが溜まった
- Vertex AI Vector Searchのノウハウが溜まった
- 打ち合わせ毎にステークホルダーとの間で決議事項の事前準備、決定事項の証跡を残す進め方が行えた
- Problem ※一部を抜粋
- スケジュール終盤での要件変更が発生、複数のステークホルダー間の調整が必要になった
- 依頼事項や仕様確認を文書化して認識のズレを防ぎたかった
- 要件定義前のフィジビリを行っておけばよかった
- コードレビューをもっと行っておけばよかった
深掘り・Tryの決定
深堀りした結果、以下のようなTryを決定
- システム監視のノウハウが溜まった→監視ポリシーの標準化
- 要件定義前のフィジビリを行っておけばよかった→技術選定を行えるようなフィジビリ工程を全体スケジュールで確保
- コードレビューをもっと行っておけばよかった→PR自動レビューの利用
まとめ
将来的な振り返りの文化を根付かせる第1歩としては良い機会だったかと思います。
振り返りで終わるだけでなく、Tryで決めた具体的に「次に何をやるのか」を実施することで、ノウハウの蓄積やプロジェクトの質の向上を実現するためActionの実行は必須です
