はじめに
プロジェクトが終わるとよかったよかったで終わらせてしまいがちではないでしょうか?
いわゆる振り返りですが、重要とはわかっていつつそもそも何を振り返ればいいのか?などからわかりません。
そこで私も整理しつつ、重要性を確認したいと思います。
尚、この記事ではプロジェクト終了後にフォーカスしたいと思います。
何を話すか?
こういったミーティングを行うとどうしても反省会になりがちです。
確かに反省点は話し合うべきものの内の一つですが、トピックとしては以下3点でしょう。
- 成長できた点
- 成功体験として次回も継続したいこと
- 反省点について次回どうすればよいか?
どのように開催するか?
オープンに話すことができる状態が好ましいです。
ので、上司やリーダーはあまり否定的な言葉は発しないようにした方がよいでしょう。
また、事前に振り返りの為のフレームワーク (何を話すか?のもの)を作成しておきましょう。
振り返りの例
- 成長できた点
データベース設計において概念設計に携わることができたため、構築するシステムに対しデータ中心アプローチを意識しての設計を学ぶことができた。
パフォーマンスの問題を解消したことにより、DBのチューニングについて学ぶことができたため、 次回設計時には最初から取り入れることができそうである。 - 成功体験として次回も継続したいこと
共通となるコンポーネントをGitに配置、submodule化することによって、他プロジェクトにおいても 活用可能な状態にできた。
以後継続して共通コンポーネント化を進めることで開発コストの低減につなげられると考える。
スタンドアップミーティングを毎日行うことにより自身の進捗を振り返ることができるほか、他メンバーからのフォロー、もしくは他メンバーへのフォローを積極的に実施できていた。 - 反省点について次回どうすればよいか?
設計局面において事前の相談があまりできておらず、大きく手戻りが発生した。
要件定義書などから不明な点、認識合わせが必要な点はリーダーに逐次相談することで 手戻りのない開発を行いたい。
リーダーより
リーダとしてフォローアップが適切ではなかった点もある。
次回プロジェクトにおいては要件定義書の読み合わせなど、設計の前提となる知識を共有する場を設け あやふやな点がなるべく発生しないよう努めたい。
いかがでしょうか?
こういった例を最初にしめしてあげることも重要で、何を書けばいいのだろう・・・という担当者の疑問も 解消できそうです。
終わりに
私自身ちゃんとできているか?というところは怪しげなところです。
今回どのような振り返りをすべきか？についてはAIの助力を受けたところですが
確かに過去在籍していた組織では同じようなアプローチをとっていたなと思い出しました。
自分で整理していても、メンバーがどのようなところを成長できたか、是正したいのか?という点を吸い上げることができるため、やはり重要であるなと考えます。