このドキュメントは
こんにちは。iRidge Advent Calendarの22日目を担当してみます。
ここ最近、社内の様々なプロジェクトのふりかえりに参加する機会があり、ふりかえりをする上でも様々な工夫があるなと気づくことが多くありましたので、それをガイドラインという形でまとめてみました。参考になれば幸いです。
「ふりかえり」とは
プロジェクトのふりかえりとは何か、改めて整理してみました。
ふりかえりは、プロジェクト完了後に、プロジェクトで起きた計画や事実をふりかえり、次のプロジェクトに活かせる知見を発見・共有する目的で開催しています。 継続的な改善、仕組み化 を推進するために非常に重要な活動だと認識しています。
ふりかえりのやり方
司会者を用意する
関係者が多いプロジェクトのふりかえりの場合、プロジェクト内部のメンバーだけでふりかえりを実施すると、利害関係にある立場同士で言い合いになってしまい、望ましくない進行になる恐れがあります。適切な司会者を用意することでこの問題を防ぎ、円滑に進行することができるようになります。プロジェクトに直接関係しない人を司会者にすると、発生した問題について冷静に判断して処理することができるようになります。
最初に「問題 vs 私たち」という構図を確認する
上とやりたいことは同じですが、ふりかえりのミーティングの開始時に、 「問題 vs 私たち」 という構図であることを改めて確認します。後述のKPT、YWTの項目を列挙する時も、特定の個人を攻撃するような記載は控えるように周知します。
QCDの観点でプロジェクトを確認する
プロジェクトを評価する上で、QCD（品質、コスト、納期）の観点から確認すると、プロジェクトの概要が把握できます。例えば以下のような観点から、◎、○、△、×のような評価をしてプロジェクト関係者と認識合わせをします。
- 品質
- リリース後不具合の発生件数
- コードレビュー率
- 単体テストのカバレッジ率
- コスト
- プロジェクト全体の原価
- 稼働の予算と実績
- 納期
- 納期遅延の有無
- マイルストーン（要件定義、設計、開発、テスト、リリースなど）のスケジュールの計画と実績
プロジェクト計画時に挙げたリスクの対応を評価する
弊社では、プロジェクト開始時にプロジェクト計画をレビューし、考えられるリスクと対策の一覧を作成しています。ふりかえりの時にそのリスクと対策の妥当性について確認することで、次回のプロジェクトではより適切な計画ができるようになります。リスクは以下の観点で評価しています。
- ○:顕在化しなかった
- △:顕在化したが影響少ない
- ×:顕在化して影響があった
KPT、YWT手法を使って振り返る
ふりかえりの定番、 KPT(Keep、Problem、Try） を使い、関係者の意見を引き出します。KPTについては各所で説明があるので、ここで説明することはしません。KPT以外にも YWT（やったこと、わかったこと、次にやること） を採用しても良いでしょう。
各項目はGoogleスプレッドシートにみんなで事前に書き込んでもらうか、付箋に直接書き込んでもらうことが多いです。4~5人くらいの小グループに分けて意見出しを繰り返すと、全員の意見を反映しやすくなります。（大人数だと発言しない人がどうしても出てくる）
次に活かす
ふりかえりでえた知見は共有し、次のプロジェクトに活かすようにします。プロジェクトに失敗はつきものですが、同じような失敗を起こさない工夫が必要です。必要に応じて、仕組み化を検討します。個人の頑張りに期待しないような対策であることが望ましいです。
おわりに
ふりかえりについて、ふりかえってみるのはなんとなく年末にふさわしい気もしますね！書き終わってみて、今年一年を振り返ってみたいなと思いました。