『アジャイルレトロスペクティブズ』に学ぶふりかえりの 5 フェーズ

『アジャイルレトロスペクティブズ』という舌を噛みそうなタイトルの本があります。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

この本は、舌を噛みそうかどうかとは一切関係がなく、「ふりかえり」の手引きです。
ふりかえりには、

• うまくいったことに自信がつき、また再現が可能になる（よい習慣が定着する）
• うまくいかなかったことに対して、改善案を出し、また実際に行うことができる
• チームでやれば、目標を共有できる

といったメリットが盛りだくさんなので、みんなやるといいと思います。

この本では、主にソフトウェア開発チームで行うふりかえりのやり方について、様々な提案を行ってくれているのですが、僕がふだん自分だけのために、一人で行っているふりかえりにもうまく取り入れられている部分があるので、紹介します。

ふりかえりの 5 フェーズ

『アジャイルレトロスペクティブズ』によると、ふりかえり＝レトロスペクティブは 5 つのフェーズに分けて行うことができます。
少し長くなりますが、それが簡潔に示された本書冒頭の一節を引用します。

　まず、Dana は、レトロスペクティブの目的、フォーカス、所要時間をチームに知らせた。次に、時間の使い方を説明した。そして、簡単なチェックインを使って全員に口を開いてもらい、チームの約束を確認してもらった。
　それから、チームの不具合データを確認して、イベントやフラストレーションを感じたことについて尋ねた。こうすることで、各自が自分の知っているデータだけで考えるのではなく、みんなが同じデータについて考えることができた。そして、チームメンバーに事実（不具合データ）と感情（フラストレーションの所在）を調査してもらった。
　データを解釈し、パターンを導き出すよう促した。
　レトロスペクティブでフォーカスした目標を達成するために、チームが手法を発見し、選択し、計画を行う手伝いをした。
　時間通りにレトロスペクティブを終了した。進捗を評価する方法を確認した。最後に、参加者に感謝の意を示した。
　Dana は以下の明確な構成に従っていたのである。

1. 場を設定する
2. データを収集する
3. アイデアを出す
4. 何をすべきかを決定する
5. レトロスペクティブを終了する
   (pp.4)

というわけで、【ふりかえりの 5 フェーズ】は「場を設定する」に始まり、「レトロスペクティブを終了する」に終わる、ということになります。

これから、僕が個人的なふりかえりでこの 5 フェーズをどのように活用しているかを紹介します。

なお、僕は一日のふりかえり、一週間のふりかえり、一ヶ月の振り返り、大きめの課題（チケット）単位のふりかえり、等を行っていますが、【ふりかえりの 5 フェーズ】を用いているのは、大きめの課題（チケット）単位のふりかえりです。

これは、（小規模な）プロジェクト単位のふりかえり、あるいはユーザーストーリー単位のふりかえり、という風に読み替えてもらっても差し支えないと思います。作業期間でいうと概して数日～ 2 週間くらいのものです。

1. 場を設定する

場を設定することで、参加者はこれから行う作業に意識を集中することができる。また、レトロスペクティブに集まったチームが目標を再確認することもできる。さらに、議論をするのに適した雰囲気を作り出す効果もある。 (pp.5)

一人だと、「わざわざ "場を設定する" だなんて」という印象を覚えるかもしれません。でも、ないよりはある方がよいと感じます。

具体的には、その課題について思い出しながら、「この課題では、こういうところに苦労した。でも、このへんがうまくいってよかった。こういうところから課題と改善点を引き出せそうな感じがする。さて、はじめよう。」みたいな感じで、ほんの 1 分程度ですませてしまいます。

これで、なんとなくふりかえりのざっくりした方向付けと、ふりかえりをするぞー、という勢い、リズムがつきます。

2. データを収集する

1 ～ 2 週間程度のイテレーションでデータを収集するなんてバカげていると思われるかもしれない。しかし、（中略）データを収集すれば、すでに起きたことについて共通の理解を得ることができる。
……
まずは、イベント、メトリクス、機能、完了したストーリーといった、客観的なデータの収集から始める。
(pp.8)

あえて「共通の理解」を作る必要がないような一人でのふりかえりでも、やはりデータは大事です。
データがないと、思い込みによる誤った前提に基づいてアクションを決めることになりかねません。

僕の場合、作業ログ*1から

• 作業期間（開始日時 - 終了日時）
• 作業工数（予定と実績）*2

を拾い集め、作業ログの作業記録を見ながら軽く分析を行って、コメントをつけます。 作業ログには作業当時の苦労したところや感情が「記録」されているので、もともと主観的なデータとはいえ、ふりかえりにおいてはかなり客観的な情報として役に立ちます。

ほんとうに客観的なデータとしては作業期間と工数だけしか集めていませんが、準客観的なデータとしての作業ログの、目立った部分を抜粋するだけで、かなり「客観的」なデータが一揃い集まると感じています。

3. アイデアを出す

ここでようやく、「なぜ？」と問いかけたり、違ったやり方について考え始めたりするときがきた。アイデアを出すとき、チームはデータを参照して、強みや以前のイテレーションで上がった課題を確認する。
(pp.11)

ここでは、「データを収集する」フェーズで集めたデータを眺めて、よかったところや問題点等を分析し、プラクティスに落としたり、対策を練ったりします。（いわゆる KPT 的に考えます）
実際のところ「データを収集する」フェーズとの間で「収集」と「分析」という風にくっきり分けているわけではなく、このフェーズで作業ログからさらにデータを拾ってくることもあります。

ゆるやかではあっても、フェーズが分かれていることで、事実と考えたこととをある程度区別して扱うことができているように感じます。

4. 何をすべきかを決定する

この時点でチームは、試みや改善点のリストを持っている。そこから上位の項目を選択して（通常、1 イテレーションにつき 1～2 つ）、何をすべきかを計画しよう。
(pp.12)

というわけで、いよいよふりかえりの「成果」が生まれるフェーズです。

ここでやることは（一人の場合）ほとんどありません。
「アイデアを出す」フェーズで既にある程度分析が終わって課題・タスク化までだいたいできているので、あとはそれらを <Keep> と <Try> とに分けて*3、やるぞ、と思うだけです。

ただ、大事なのが、「本当にやれる（コミットできる）ことだけを選ぶ」ことです。一回のふりかえりで課題が 10 も上がっていたら、たぶんすべてにはコミットできないでしょう。
重要度、実行の容易さ、見込まれる改善の大きさ、やりたさ、等を考慮して、僕はだいたい一度に（多くても）3 つか 4 つくらいだけを選ぶようにしています。

やると決めたことにコミットしないと、ふりかえりの成果は十分上がりません。（もちろん、まったくないというわけではありませんが……）

5. レトロスペクティブを終了する

昔から出会いは別れの始まりというように、レトロスペクティブにも終わりはやってくる。バシッとレトロスペクティブを終了させて、参加者（と彼らのエネルギー）を無駄にしないこと。
(pp.13)

おつかれさまでした。と書いて、終わりにします。
はじまりの「場を設定する」もそうでしたが、一人なので、ちょっとむなしいです。

それだけではむなしいので、ふりかえり全体の感想とかを綴ったりします。
だいたい「充実したふりかえりになってよかった」的な感想になってポジティブな気分になる効用があるので、このフェーズもあえて飛ばさないほうがよいです。

まとめ

というわけで、僕は個人のふりかえりを『アジャイルレトロスペクティブズ』が示す 5 つのフェーズにしたがって行い、とてもうまくいっています。
ちなみに時間で言うと、いつも 1 ポモドーロか 2 ポモドーロ、すなわち 30 分～ 1 時間程度ですんでいます。

業務を改善できて、おまけに楽しいので、みなさんもぜひふりかえりしましょう。

ちなみに『アジャイルレトロスペクティブズ』にはこれら 5 フェーズのそれぞれで活用できる様々なプラクティスが豊富に紹介されているので、ふりかえりに興味のある方、ふりかえりがうまくいかず悩んでいる方などは買ってみて損のない本だと思います。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

*1:作業ログについては、「作業ログのすすめ - この国では犬が」をどうぞご参照ください。

*2:実際には工数とポモドーロ数を集めています。また、消化した 1 ポモドーロあたりの工数も割り出します。ポモドーロについては「ポモドーロと Trello によるタスク管理（2 of 3 : ポモドーロ編） - この国では犬が」あたりをご参照ください。

*3:ここには Problem は出てきません。Problem は「何をすべきか」ではないからです。