レトロスペクティブで何をやるか考える時の流れ

# 概要
この記事では、私がレトロスペクティブで、どんなアクティビティをやるか考えるときの流れをまとめています。
今チームが揉めてる、上手く行ってる、そう行った状況によって、ふりかえりへの取り組み方は変わると私は考えています。
じゃあどうするの、というのがこの記事の主旨です。
自分のアンチョコでもありますが、同じようなことに頭を割いているスクラムマスターなどの役職の人のヒントになるといいなと思っています。

# 記事の流れ
この記事は、次のような流れで書かれています。

1. どういったことをレトロスペクティブを決めるときに考慮に入れるか
1. 注意することの優先順位とその条件ごとに実施したいアクティビティ
1. 終わりに。この記事の注意点について

なにを考えて、どういった結論にするかの順で書いています。
読むのが面倒な人は優先順位とアクティビティに飛んで、前に戻って読んでも良いかと思います。

# どういったことをレトロスペクティブを決めるときに考慮に入れるか
チームは何かの区切りで振り返りをします。
スクラムならスプリントの区切り、他のやり方でもアジャイルだったら定期的に決まったスパンでやるでしょうか。
その時、考慮するのは、チームの置かれている状況です。
私の場合、以下のことを考慮に入れます。

- チームが取り組んでいるタスク/プロジェクトは上手く行っているか
- チーム内の人間関係に変化は発生していないか
- プロジェクトは区切りのタイミングか
- スケジュールに変化は発生していないか(プロジェクトの状況変化の一つではあります)

それぞれの詳細を見ていきましょう。

## タスク/プロジェクトは上手く行っているか
大前提です。タスク/プロジェクトが上手く行っていない状況での振り返りでするべきことは決まっています。
上手く行っていない問題点へのフォーカスです。それ以外のことはできません。
早く問題を明確にし、対処することが重要です。
でなければ、チームメンバーはもしかしたら振り返りの時間にこんなことを言うかもしれません。
「こんなことをしてる場合ですか？」

## チーム内の人間関係に変化は発生していないか
これは主に二つのパターンが考えられます。
一つ目は、人が増えた/減った場合。
プロジェクトが長くなると、だんだんと人が増えたり、時には減ったりします。
その変化が顕著な場合は、振り返りでそのことを踏まえた方がいいでしょう。例えば六人メンバーに二人入ったり二人辞めたりは、大きな変化です。
増えた場合は、これまでに何をしていたかも知らないので、やり方の説明から入る必要もあります。

二つ目のパターンは、チームの人間関係に不和が起きている場合です。
あまり起きてほしくありませんが、人間なのでそういうこともあります。
不和は何に起因しているでしょうか。
性格？技術的な志向の不一致？
問題の洗い出しであれば、振り返りで取り組むべき問題です。
これに関しては、最悪チーム内で解決できない可能性については考慮に入れるべきでしょう。ただし、それはこの記事の範囲を超えるので、別の記事や書籍などを参照してください。個人的には、人事に裁量がある人と相談することをお勧めします。

## プロジェクトは区切りのタイミングか
プロジェクトのリリースが済んだ時やプロジェクト開始から数ヶ月など適当な時期的な区切りまで、そろそろ一息入れてもいい時期があります
そういう時、ちょっとした変化を考慮します

## スケジュールに変化は発生していないか
ちょうど年末年始にまたいでこの記事を書き始めましたが(書き上げるまでにだいぶ空きました)、この時期は休む人と働く人がいたりして、チーム一丸で働くという状況にならなかったりもします。
スケジュール上の変化も考慮すべきかもしれません。

## 特に何もない時
何事もなければ、同じことを継続的に続けるのもいいと思います。あまりしょっちゅう違うことをするのは疲れてしまうので(準備する方も大変)。
メンバーの志向によって、そこは変えられると理想的です。定期的に刺激を与えて、チームが良い振り返りをできるよう働きかけていくのも大事です。

# 注意することの優先順位とその条件ごとに実施したいアクティビティ
以上を踏まえて、どの条件を優先するか、その条件ではどんなアクティビティを実施するかの一例を挙げます。
各アクティビティは、そのアクティビティを紹介している記事を一例としてリンクしています。

## タスク/プロジェクトは上手くいっているか
タスク、プロジェクトの状況が、まずは最優先です。
上手くいっていないときは、まずその問題に向かい合うことが大前提です。

実施するアクティビティ：[**象・死んだ魚・嘔吐**](https://no-kill-switch.ghost.io/elephants-dead-fish-vomit/)

「象・死んだ魚・嘔吐」は言い出せない問題を言い出すためのアクティビティです。
チームに問題が生じているときは、まずは問題をチーム全体が認識することが大事です。
個人で抱えている問題や不満も出してもらいます。
対策は難しいかもしれません。それでも、問題を口から出すだけでも状況は良くなります。

## 人間関係に不和が起きている場合
人間関係の問題は、把握でき次第対策を打ちましょう。
初期に対応しないとこじれる可能性が高いです。
そして人間関係の問題に対して、スクラムマスターの立場から関わるならば、やるべきことは人対人の問題ではなく、それを人対問題に置き換えることをするべきです。

実施するアクティビティ：[**Speed Car**](https://www.funretrospectives.com/speed-car/)

ここで実施するアクティビティは一つの目安です。他にもいい方法があるかもしれません。
「Speed Car」は自分たちの開発速度を下げている問題は何か、という形で問題にフォーカスできるため、こうした時に使い勝手がいいように感じています。
ここで問題がさらにこじれるようであれば、その対応はチームリーダーや上司の役割に移るべきでしょう。

## プロジェクトの区切りのタイミングの場合
ここまでが緊急性の高い問題でした。ここからはもう少し緩く、都合のいいタイミングを考えて実施すればいいでしょう。
プロジェクトの区切りでは、そこまでの総括を実施します。

実施するアクティビティ：[**Timeline**](https://www.funretrospectives.com/timeline-driven-by-feelings/), [**Story of Story**](https://www.funretrospectives.com/the-story-of-a-story/)

「Timeline」はやったことがある人も多いでしょう。時系列とやったことを並べることで、何をやったかを思い出します。思い出すことがメインになるので、ここからさらに問題にどう取り組むかは別のアクティビティを用意した方がいいです。漠然とやるとあまり効果がないので、思い出すための材料を十分に用意するか、きちんと時間をとって、コミュニケーションの時間を多くした方がいいです。
「Story of Story」は、何をやったか、リリースしたかが明確にしやすければ、取り組む価値があります。チームでは先日プロジェクトの区切りに実施しましたが、かなり順調に進んでいるプロジェクトだったため、何が効果的だったかをあぶり出すのに上手く機能してくれました。

## スケジュールに変化が発生した場合
人の休みや変則的なスケジュールである場合は、条件に合わせてフレキシブルに動きます。
普段のアクティビティを短く実施することや、きちんと記録が残せるアクティビティに切り替えるなどして対応します。
具体的なアクティビティは後述の「普段から実施するアクティビティ」の延長でやります。
向いている方法があるかもしれませんが、チームの学習コストと見合わないため、このためだけに採用することはないです。

## 人の増減が発生した場合
人が増えたり減ったりした場合には、別のアクティビティを実施します。ただ、これはふりかえりのタイミングにこだわる必要はないです。
人が入ってすぐやちょっと様子を見てから実施するなど、ふりかえりのタイミングにこだわらない方がいいです。

実施するアクティビティ：[**ドラッカー風エクササイズ**](https://tech.pepabo.com/2017/07/07/the-drucker-exercise/)

他にもいろんなアクティビティがありますが、代表例として。
その人ごとのこだわりがわかっていると、コミュニケーションしやすくなるように思います。
実施後にホワイトボードでやったなら写真を残すなどして、記録を残して後で確認できるようにしましょう。


## 普段から実施するアクティビティ(上記条件とマッチしない場合)
普段から実施するものは、長くない期間(一週間から二週間)ごとに実施するので、ややこしくなく、取り組みやすいものが良いと考えています。
ここで上げるのは一例ですが、無難なものをチョイスしているつもりです。

実施するアクティビティ：[**YWT**](https://www.jmac.co.jp/glossary/2021/09/ywt.html), [**Fun/Done/Learn**](https://www.ogis-ri.co.jp/otc/hiroba/others/ActivityPocket/FunDoneLearn.html)

「YWT」は「やったこと」「わかったこと」「次にやること」を示すため、次への課題を考えることが流れに含まれており、書きやすいのが利点です。まずやってみる方法として使いやすいと感じます。
「Fun/Done/Learn」は少し癖がありますが、「やったこと」をアウトプットする性質上、意見が出やすいです。その後のアクションに結びつけるのは難しいので、別アクティビティを考えるか、現状の把握に使うに留めるのが使いやすいです。
それ以外にもいろんな方法がありますが、どれをやるにしてもチームメンバーの雰囲気や感じ方によってやる方法を変えましょう。一人一人違いますし、チームもチームごとに違うので、どこでも上手くいく方法はないです。


# 終わりに。この記事の注意点について
以上のように考えて、ふりかえりを実施しています。
これはあくまで目安であることに注意してください。
チームは生き物です。含まれている人間が生き物なので。
そこに柔軟に対応することが最も求められる仕事です。
人間は一人一人違うので、ふりかえりが好きな人、意見を話すのが好きな人、書くことが好きな人、いろんな人がいます。
その集まりであるチームがよりよく動くためにどうするかは、きちんと人をみて考えましょう。
唯一の正解はないです。実施するアクティビティだけではなく、そのアクティビティをどう運営するか、にも考えることは多いです。

この記事では、どういうチーム状況で、どんなアクティビティを実施するかを書いてきました。
そのアクティビティをどう実施するか、についてはいずれ別記事を作成する予定です。