第7章 7.2 ← 7.0 プロジェクトの終わらせ方
ふりかえりを、反省会にしないこと
ふりかえりが機能しない現場では、たいてい同じことが起きています。人の話になっているのです。誰のミスだったかを確かめる会になると、出てくる言葉は「気をつけます」だけになり、次も同じところでつまずきます。
この記事の要点
- 対象は人ではなく進め方です。「どういう仕組みだと、そうなるか」を聞いてください。
- 最初に話す人を変えるだけで、出てくる話がかなり変わります。上の人が総括すると終わりです。
- 終わり方は「次に変える1つ」。担当と期日つきで。11個の改善案は、実質ゼロです。
- 解散する前にやってください。人が散ってからでは集まりません。
- 途中でもやる価値があります。終わってからより、まだ直せる段階のほうが効きます。
反省会と、ふりかえりの違い
この2つは似た場に見えますが、出てくるものがまったく違います。違いは参加者の性格ではなく、場の設計から生まれます。
人ではなく、進め方を対象にする
いちばん大事な設計がこれです。同じ出来事でも、問いの立て方で出てくる答えがまったく変わります。
- 「なぜ確認を飛ばしたのですか」→ 人への問い。返ってくるのは弁明か沈黙です。
- 「どういう状況だと、あの確認は飛ばされるのでしょうか」→ 仕組みへの問い。返ってくるのは「あの時期は他の作業が重なっていて」「そもそも確認の担当が決まっていなかった」といった、直せる情報です。
この言い換えは、意識すればすぐできます。主語を人から状況に変えるだけです。そして進行役が最初にこの型で話すと、後に続く人もその型で話します。
最初に話す人を、変える
日本の会議では、立場が上の人が先に総括する形になりがちです。これをふりかえりでやると、そこで終わります。その後に違うことを言える人はいません。
効くのは、いちばん困っていた人から話してもらうことです。いちばん残業した人、いちばん板挟みになった人。その人の話が最初に出ると、場の性質が決まります。「困ったことを言っていい場だ」と全員が理解します。
進行役は、その人に事前に一言かけておくとよいでしょう。「明日のふりかえりで、いちばん大変だったところを最初に話してもらえませんか」。準備があれば話しやすくなります。4.2で扱った根回しの、良い使い方です。
次に変える1つだけを決める
ふりかえりで改善案が11個出ると、達成感があります。そして何も変わりません。11個の新しい習慣を同時に始められる組織は存在しないからです。
だから、終わり方はこう決めておきます。次に変える1つを、担当と期日つきで決めて終わる。
「次回は、要件定義の最後に運用担当への確認を30分入れる。田中さんが立ち上げ時にタスクとして登録する。」
これなら実行されます。そして次のふりかえりで「あれ、やってみてどうでしたか」と聞ける。変わったかどうかを確認できる形になっていることが、11個との決定的な違いです。
残りの10個は、記録として残しておけば構いません。捨てる必要はありません。ただ、今回動かすのは1つです。
KPTを使うなら、Tを1つに絞る
日本のチームでは、Keep（続けること）・Problem（困ったこと）・Try（次に試すこと）の3つに分けて出す進め方が定着しています。使いやすい枠組みですが、Tryを5つも6つも出すと機能しません。Tryは1つ。そして担当と期日をつける。この2点さえ守れば、KPTでもそれ以外の形でも結果は同じです。
解散する前に、そして途中でも
ふりかえりは、人が散る前にやってください。プロジェクトが終わると、メンバーはそれぞれ次の案件に移ります。1か月経ってから集めようとしても、全員の予定は合いません。
そしてもうひとつ。終わってからでなくても構いません。むしろ途中でやるほうが効きます。
要件定義が終わった時点、テストが始まる前。この時点でふりかえると、出てきた改善をこのプロジェクトで使えます。終わってからのふりかえりは、次のプロジェクトのためのものですが、途中のふりかえりは今のためのものです。
長いプロジェクトなら、月に一度30分でも構いません。5.4で扱った反復型では、この短い周期のふりかえりが最初から組み込まれています。ウォーターフォールで進めていても、この部分だけ取り入れることはできます。
ひとりでもやれます
兼任やひとり情シスで、集める相手がいない場合もあります。それでもふりかえりには価値があります。
ひとりでやるときは、次の3つを書くだけです。予想と違ったこと。次も同じやり方をするか。次に1つだけ変えるとしたら何か。15分で終わります。
そして書いたものを残しておいてください。次のプロジェクトの立ち上げ時に読み返せば、それだけで前回と同じ失敗を避けられます。個人としての学び方は10.1で詳しく扱います。
ABではこう見えます
AB Projectsでは、ふりかえりの記録をプロジェクトWikiに置いておけます。日付と、出た話と、決めた1つ。これが数プロジェクトぶん溜まると、自分たちの弱点の傾向が見えてきます。
そして「次に変える1つ」は、次のプロジェクトのタスクとして登録するのがいちばん確実です。記録の中に書いただけでは、次の立ち上げのときに誰も読み返しません。タスクとして置いておけば、期日が来たときに表に出ます。
このページで使った言葉
- ふりかえり
- 進め方そのものを見直す場です。アジャイルの文脈ではレトロスペクティブとも呼ばれます。くわしく →
- KPT
- Keep・Problem・Tryの3つに分けてふりかえる進め方です。日本のチームで広く使われています。くわしく →
- 教訓
- 次回に活かすために残す学びです。具体的に書き、次のプロジェクトが見つけられる場所に置いて初めて機能します。くわしく →
- 根回し
- 会議の前に個別に話しておくことです。最初に話す人に事前に頼んでおくのは、その良い使い方です。くわしく →
- スプリント
- 反復型で使う、短い固定期間です。区切りごとのふりかえりが最初から組み込まれています。くわしく →
- 課題
- すでに起きていて、対処しないと進まない事柄です。ふりかえりで出た改善案は、課題ではなくタスクにします。くわしく →
あわせて読みたい
7.3 知識の引き継ぎ
ふりかえりの記録を、どこに置いておくか。
10.1 続けて伸ばす
ひとりでやるふりかえりと、その記録の使い方。
8.2 失敗から学ぶ
崩れたプロジェクトが、内側からどう見えていたか。