アジャイル開発でふりかえりをやってプロセスを改善するのが難しいというお話。
ふりかえりってなんだっけ
XP でいえば「リフレクション」（内省）
スクラムでいえば「レトロスペクティブ」
日本国内では「ふりかえり」
※ 漢字の振り返りではなくひらがなの「ふりかえり」がよく使われている。意図して使い分けられている（PF 時代のころから？）
目的はどれも、次よりよく仕事をするために何を変えるかを考えて実行すること
※ 逆に言えば、型どおり仕事をする主義へのアンチテーゼにも見える
ふりかえりではプロセスを改善する
というだけではないのですが（例えば関係性や、立ち位置の認知共有でも「よりよく仕事をする」が達成できるならそれもアリだと思う。
とはいえ、どう仕事を進めるかという点では、プロセスや環境の改善が必要になることがままある。
ふりかえりでプロセスを改善するのが難しくなりがちだ
よく見かけるシチュエーションが、
- 課題：XX に課題があり、完成しなかった。
- 分析：XX で使っている A ライブラリを B ライブラリに変更する
- アクション：B ライブラリの導入
みたいなもの。
何がイマイチなのか
発生した課題（XX が完成しなかった）は認知されているように見える
分析もされて、問題（A ライブラリがクソ）の特定もされているように見える
アクション（Bライブラリに乗り換え）も明確になっているように見える
一方で、明らかになったのは今回の問題とその対処であって、
この「問題が課題と生み出してしまった構図」については触れられていないので、次も同じような「構図」が同様の問題を引き出してしまう。
（もちろん、A ライブラリに起因する同様の問題は発生しなくなるが）
よって解決する影響先が低いことにより再現性が低い（≒ふりかえりのアクションの ROI が低い）状態になってしまうため、この状態はイマイチととらえられそう。
どういうアクションだとよさそうか
たとえば、A ライブラリに課題があることが「完成しなかった」に紐づいてしまった理由は何かを深掘りするとよいことが起こりやすい（気がする）
なぜ課題＝終わらないとなったのか？他の開発アイテムは課題があっても遅れないのでは？ではなぜ今回のケース（PBI？）ではそれを発症したのか？
（それがAライブラリであろうということは想像できる）
では A ライブラリでなくても発生するとしたらどんなときか？A ライブラリを使っているということは何が特有だったのか？そしてそれが遅延につながった理由はなんだろうか？
完成しなかったということは、課題の解消が時間がかかったということなのか、課題の検知が遅れたということなのか？課題が発生しないようにする（ライブラリを差し替える）方針とは別に考えないといけないことを見落としていないか？とかを考えるとよさそうではある。（たとえば、課題を相談しにくい雰囲気になっていないか？とか）
なぜそうした観点を持つことが難しいのか
かならずしもそれが理由というわけではないが、過程に踏み込んでしまうということは、自分たちの内面の課題と向き合うことになってしまうことも一因な気はしている。
「ユーザーが理解していなくて」「ライブラリがいまいちで」といった、自分たちのプロセスの外へ問題を移動すると、自分たちは傷つかなくて済むので、間違いなく安心。
確かに、過程を深掘りすると反省会チックになり、Happy なスクラムチームが壊れてしまうのではという懸念がある。
（一方で、それが心理的安全性が高くない状態であろうことは想像はつく）
プロセスにフォーカスできてないと気づく方法はあるか？
とくにこれといったモノはない気がするけど、PBI になるようなアクションであれば、たぶんプロセスにフォーカスしていないことが多い。
PBI のインクリメントが導入されるのはあくまでプロダクトで合ってチームではないので。
どうすればイマイチでなくなるか
今のことろこれだ、って体系的にまとめてない
- どうイマイチになっていると気づけるか
- どうすればよりプロセスにフォーカスできるか
- どうすれば内面にフォーカスすることにチームで勇気を持てるか
とかいろいろ考えることはありそう。
スクラムマスターとしてどう振る舞うとよいだろうか
- アクションの ROI はともかくふりかえりをやる
- プロセスの話にしましょう、とファシリテーションする
- チームがプロセスの話ができるように働きかける
- チームがプロセスの話に踏み込めない要因を観察し、環境を整える
とか？いろいろありそう。
