「ルックバック」でより良いプロジェクトにつなげよう！
プロジェクトが終わった後、みなさんはどうしてますか？
なんとな～く振り返って一人反省してみたり…で終わってたりするケース多いと思います。
「それではもったいない！！」ということで、今回はプロジェクト終了後の振り返り「ルックバック」についてお話したいと思います。
ルックバック（弊社ではこう呼んでます！）とは、プロジェクト終了後に改めて携わったメンバーがそれぞれの作業を振り返り、反省点や今後の改善に向けての意見を出し合う場のことで、スパイスワークスでも以前から実施はしていましたが、今回初めて参加をしました。
進め方としては、アジャイル開発などでよく使われる「KPT」というフレームワークを用いて、最終的に実施項目を実現難易度によって区分する、という手法を取っています。
今回は、大規模システムが絡んだ某ウェブサイトのリニューアルプロジェクト後に実施したルックバックをもとに、進め方や気付いた点についてお伝えしたいと思います。
◆「KPT」：
「K：keep＝今後も続けること」
「P：problem＝問題なので、やめること」
「T：try＝今後、試してみたいこと」
【事前準備】
参加人数が多いので会議時間を短縮するために、事前に参加メンバーにはKPTの各項目について、どんな些細な点でも良いのでまとめてもらいました。
例えば・・・、
「keep」
- 頻繁にクライアントとのミーティングを設けていたので、密に連絡を取れたことが良かったと思う。
- Backlogを使い始めて、ログを追いやすかったこと。
- AWSの構築に詳しくなった。
などなど。
「problem」
- 最初はとてもゆとりのあるスケジュール感だったがシステムフェーズに入る頃にはギリギリになっていた。
- リリース時に注意する点を書き出し（てはいたが）見落としていたので、開発中からメモしていっていればよかった。
- Backlogはログを追いやすく良かったが、課題のたてかたが難しいと感じた。
などなど。
「try」
- 要望リストについては、社内でもクライアントとの間でも書き方が統一されたら、とても使いやすいのでルールがあるといいと思う。
- 今回は基本的にPCとSPは別のテンプレートとして作成したが、この規模のシステムが絡んだサイトでレスポンシブ化に挑戦してみても良いと感じた。
- 空いている時間は前倒しで仕事をやることで、キツイ時に余裕をもたせること。
などなど。
【ルックバック会議】
最初の30分で事前資料を元に全員の意見を集約し、「類似する内容」でグループ分け。
残りの30分でグループ化された「try」の項目を、
難易度（低）：すぐにできること
難易度（中）：運用に負担がかかるが実施できること
難易度（高）：予算・期間を設定して実施するもの
に分類し、具体的なスケジュールと手段に落とし込みました。
↓最終的にこんな形でまとめてみました！！↓
【やってみて気づいたこと】
- 事前準備はしたものの、時間が全然足りなかった。
- ブレスト同様、人の意見を否定すること無く、全員が1度ずつ話せる機会を作るように進行すると良い。
- 大きく分けて「社内向け」「クライアント向け」の課題がでてくる。
→「社内向け」の課題は、内部的な課題として今後の案件へ活かせるように！
→「クライアント向け」の課題は、ユーザーの使い勝手が向上し、結果クライアントへの効果が高くなることをポイントに選ぶのが重要！
社内だけで完結するのではなく、クライアントも交えて行なうと、関係性も深まり今後より良いプロジェクトになると感じたので、次回は是非「クライアントとルックバック」したいと思いました！
プロジェクトの「振り返り」はやはり大事ですね～。オススメです！
