一番ベーシックなプロジェクトの振り返り

5 min readMar 16, 2020

雑記です。

今日、長期で実施していた開発プロジェクトが見事ゴールした。期間としては、多分キックオフをやってから、紆余曲折あって半年くらいはかかっているのではないかと思う。自分たちのプロダクトでここまで長いスパンでひとつのプロジェクトを実施していくのは結構珍しかったので、どんな振り返りをやったら次に繋がるんだろ？っていうのは悩ましかった。

で、こんなツイートをしたら過去一緒に仕事したの同僚たちからいろいろとアドバイスを受けて、いい人たちやな…って思ってありがたかった。

あまりに長いプロジェクトを振り返るので、いろいろと工夫がいるかな…と思ったけど、最終的には一番ベーシックな振り返り方法で実施して、ある程度納得感は得られたので今後の自分のためにも振り返って書いておく。

ちなみにこのプロジェクトにおいて、自分はエンジニアリングのリソースではなく、ディレクターとしての関わり方だった、という前提。

また、この振り返りのファシリテータは自分だった。（が、それはディレクターである必要はない。）

プロジェクト目標に対しての達成度を共有

まずは、プロジェクトが目指していたゴールがなんだったのかをちゃんと振り返って共有しておく。

キックオフした時に何を目指していたのか、そこに対してどんなレベル感で達成していたのかを事実だけ率直に共有する。ここはディレクターの役目で、誰かの主観ではなく、できるだけ客観的で定量的な結果を共有する。

以下は例。

目標（例）

〇〇という機能をN月M日までにリリースすることを目標とする。

達成度（例）

求められている機能のうち、MVPとされる部分はリリースされた。
スケジュール目標に関しては、当初の目標よりもN日遅延した。

Fact(事実)の共有

長期プロジェクトを振り返る場合、そもそも過去の記憶を掘るが難しい。時間軸と発生事象を振り返りを実施する前に整理しておく。

プロジェクト中に起こった印象的なFactを、事前にみんなでDocumentツールに書き起こしておく。叩きはディレクターが作り、それをみんなで肉付けしていくように1週間前くらいから呼びかける。

実際にKPTをやっていく時にこれを参照しながら振り返っていく。

Keep/Problem/Tryによる振り返り

いわゆる一般的なKPT振り返り手法だけど以下のことを気をつけて実施した。

まず、付箋紙とペンを使ってアナログな形式でやる。デジタルツールを使って黙々とやるのではなく、体と手を動かすことで脳を活性化させて良いアイデアを生み出したいと思った。

その他注意事項
・特定の個人や特定のチームを非難するような発言はNG
・あくまで発生した事象やプロセスに対しての課題を上げること
・プロダクト自身の改善ポイントについてはスコープ外
・技術的な内容・デザイン固有の問題、などチームに閉じたものでもいったん全部吐き出す（あとで仕分けする）

Keep/Problemを抽出する (20min.)

このプロジェクトの進行中に発生した事象やプロセスについて以下の観点でK/Pを付箋に書いて貼っていく。また、付箋には書いた人の名前を記述しておくこと。

Keep: 今後も開発プロセスに取り入れることでプロジェクトの進行にとって良いと思われる物事
Problem: 別のプロジェクトで同じことが発生した場合に、プロジェクトの進行の健全性を阻害すると思われる課題

Keepを振り返る (10min.)

壁に貼られたKeepを読み上げ、プロセスに導入すべき内容かどうかを議論する。
書いた人を順番に指名していき、書いた人が補足しながら説明する。
今後意識できるようにするために、印象的なKeepには印をつける。

Problemの重要度について投票する (5min.)

すべてのProblemに対してTryすることはできないので、重要度が高いものをフォーカスして優先的にTryしてくこととする。

そのために、壁に貼られたProblemについて「重要度が高い」と思われるものをひとり「3つ」まで選択して印をつける。

注意
・この際、「各チームで解決すべき」と感じるものについては、各チーム用のPoolに入れていく。
・ファシリテータは後ほどチームで取り組むように促す。

休憩 (10min.)

休憩は重要。一回頭を冷やす。

重要度の高いProblemについてのTryを考える (10min.)

重要度の高いProblemのうち、最大上位3つに対して、その課題を解決するためにTryすべきことを付箋に書いていく。

重要度の高いProblemについてのTryを決める (20min.)

挙げられたTryをについて、実施するものを決めるために以下の議論をする。以下の2点が合意できない場合はTry不能ということで、書いてくれた人には申し訳ないけど、勇気を持ってこの場からは却下する。

できる限り短期間でTry可能な内容になっているか？
Tryする主体はどのチームか？誰か？の合意をする

こんな感じだった。

結局は普通のKPTなんだけど、長期のプロジェクトを振り返るのに、重要なのはFactを事前に整理することと、あとは、長期にしてもTryすることは2つか3つに絞ること。

明確なゴールしたときの成果をちゃんと共有できるかも大事。ここをうやむやにすると、なんだかよくわからなくなるので、主観を省いた客観的な達成度の示し方も割と重要ではないかと思う。

振り返りはプロジェクトの最後に実施すると思うので、いかに雰囲気よくできるかがファシリテータの腕ってかんじはするけど、それはとっても難しい。