こんにちは。アプリ開発支援部所属の中島です。
以前の記事ではいくつかのレトロスペクティブの紹介をしましたが、今回はレトロスペクティブのアンチパターンについて、アジャイルトレーニングの内容と私の経験をもとに紹介します。
私がこれまで所属していたチームは 5、6 人程度の小規模なチームで、ほぼ全員がエンジニアでした。アジャイル開発で取り組んでおり、2 週間ごとにレトロスペクティブを行っていました。
今回はKPTを使ったレトロスペクティブを行っている前提で、以下のアンチパターンについて一つ一つ解説していきます。
非難、文句を言う
レトロスペクティブはチームのうまくいった点、いかなかった点を整理し、そこから継続的に改善していくために行うものです。非難したり文句を言ったりすると心理的安全性がさがってしまい、レトロスペクティブでの発言がしづらくなるだけでなく、それ以外の場面での生産性にも影響してしまいます。
もし非難や文句を誰かが言い始めたり、個人の問題へ焦点があたりはじめたりしたら、ファシリテーターが焦点を個人の問題からチームの問題に戻してあげる必要があります。
問題点が偏る
どうしてもエンジニアチームだと技術的な問題点に偏りがちです。しかし、以前の記事でも説明したように、レトロスペクティブの目的は特にプロセスに対して検査、適応を行っていくものです。そのスプリントでプロセスよりも技術的課題が多いことも当然ありますが、もしそのような状況になった場合は一度プロセス視点から考えなすようにしてはいかがでしょうか。実はプロセスを改善すれば一緒に解決する問題かも知れません。
問題を深堀りしない
一見問題が単純そうだと、問題を深堀りせずに直接解決策を考えてしまいがちです。その原因が別のところにあったときは根本的な解決にいたらずに、似たような問題が繰り返し現れてしまうことがあります。それどころかより悪化してしまう方法をとってしまうことすらあります。
Retrospectives Antipatterns の例では、ある問題に対してペアプログラミングを増やす施策をとりましたが、実際にはペアプログラミングにかかる準備時間やチームの心理的安全性を考えると実施するべきではなかったとあり、解決策として 5 How 分析やフィッシュボーン分析を使うことが勧められています。
5 How 分析はどのように（How）問題解決するかを繰り返し考える手法です。フィッシュボーン分析は解決したい問題を背骨で表し、そこから大骨、小骨、孫骨に要因を細かく分解して視覚化する手法です。
必ずしもやらなくて良いですが、解決手法を考えたり要因を分析したりするのに有用な手法ですので、もし行き詰まった場合はぜひ利用してみてください。
すべての Problem を解決しようと Try を挙げまくる
改善をしようとする意識が強すぎるあまり、Try を挙げすぎてしまうことがあります。その意識自体は悪いことではないのですが、実際にその Try を実行する時間は有限です。2 週間スプリントで 10 個、20 個の Try があっても、すべては実行できないですよね。 また、レトロスペクティブの時間も限られているため、Problem が多くでている場合はすべてを解決しようとすると前述のように問題を深堀りできず、表面的な Try ばかりになってしまうこともあります。
どちらの場合も優先度をつけることが大切です。出ている Problem や Try には優先的に取り組むべきものがあるはずです。影響度や緊急性はもちろん、投票や複数人から同じ意見が出ているかなどから決定しても良いでしょう。
前回の Try の結果を確認しない
繰り返しになりますが、レトロスペクティブの目的はプロセスに対する検査、適応です。解決すべき問題に対して適応できているのかは確認しなければいけません。Try の結果、うまくいっていないのであればその Try 自体に何か問題があったはずです。逆にうまくいったのならば、うまくいった要因の分析をしましょう。
Try を実施する前に想定していた効果と、実際にやってみて見えてきた効果は異なることはよくあります。副次的に何か別の効果があるかもしれません。そのため良い結果、悪い結果に関わらず、Try してみて得られたものを振り返ることが重要です。
ネガティブな意見ばかりを出す
うまくいかなかったスプリントのレトロスペクティブではネガティブな意見ばかりが出てしまうことも多くありました。また、エンジニアは課題解決が好きな人が多いため、その影響もあったのか全体的に Keep よりも Problem が多い傾向にありました。
Problem が出ること自体が問題ではないですが、そればかりだとチームの士気も下がりますし、既に良いところをさらに伸ばす活動が少なくなってしまいます。
これに対処する方法はいくつかありますが、ここでは2つご紹介します。
まずは Retrospectives Antipatterns で紹介されている対策のひとつに挙げられている positivity retrospectives です。その名の通りポジティブなことだけを対象としたレトロスペクティブで、数スプリント単位で開催します。KPT で行う場合は Keep のみになるでしょう。数スプリント分の意見がまとまるため、普段よりも多くのポジティブな意見が集まるはずです。
もう 1 つはプロジェクトに関係ないことも許容して、1 人 1 つは Keep を出すようにすることです。KPT ではポジティブな気持ちで開始できるように Keep から始めます。個人的な内容であっても Keep はあったほうが、その後の Problem にポジティブな気持ちで向かえるように、関係ない内容であっても出せるようにします。
最後に
アンチパターンを 6 つご紹介しましたが、私も過去のレトロスペクティブで何度か経験しており、あのときこうすればよかったと思うこともいくつか発見できました。特にネガティブな意見ばかり出てしまうときは個人的な Keep を出すことで対処していましたが、positivity retrospectives を試すのも有効だったのではないかと感じています。
アジャイル宣言の 12 の原則にもある通り、定期的な振り返りを通じて効率を高めていくことが大切です。また、振り返りにもアンチパターンはあり、それを知り、防ぐことで振り返り自体の効率を高めることができます。
今後のレトロスペクティブでこれらのアンチパターンに陥ったら、整理した対処法を実践しようと思います。みなさまのレトロスペクティブでも今回ご紹介した内容がお役に立てば幸いです。
