ふりかえり

一言でいうと

チームが一定期間の仕事の進め方を見直し、次の期間に試す改善策を決める場です。

提唱者と登場年

ソフトウェア開発のふりかえりを手法として体系化した文書に、Norman L. Kerthが2001年に刊行した『Project Retrospectives: A Handbook for Team Reviews』があります。Kerthはこの本で、ふりかえりの冒頭に確認する「最優先指令（Prime Directive）」を示しました。「何が見つかったとしても、その時点でわかっていたこと、本人の技能と能力、使えた資源、置かれた状況のもとで、全員が最善を尽くしたと理解し、心から信じる」という内容です。

同じ2001年に公開されたアジャイルソフトウェア開発宣言の原則も、「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します」と定めています。スクラムでは、スプリントの最後に行うスプリントレトロスペクティブがこの場にあたります。

何を解決するか

チームの進め方を、初期に決めたまま固定させないことが目的です。スクラムガイドは、スプリントレトロスペクティブの目的を、品質と効果を高める方法を計画することとしています。チームは直前の期間について、個人、相互作用、プロセス、ツール、完成の定義を点検します。

最優先指令が示すとおり、ふりかえりは誰の失敗かを特定する場ではありません。個人を責める場になると、参加者は問題を口に出さなくなり、仕組みの欠陥が表に出なくなります。この場が機能するには、発言によって評価が下がらないという信頼が、チームの中に必要です。

実際の進み方

期間の終わりに、チーム全員が時間を区切って集まります。スクラムガイドは、1か月のスプリントでスプリントレトロスペクティブを最大3時間とし、期間が短ければ時間も短くするとしています。チームは起きた出来事を共有し、うまくいったこと、問題だったことを挙げ、次に試す改善策を少数に絞って決めます。

KPTは、続けること（Keep）、問題（Problem）、次に試すこと（Try）の3つに分けて書き出す形式です。スクラムガイドは、最も影響の大きい改善にできるだけ早く対処するとし、改善策を次のスプリントバックログに加えることもできると書いています。

導入でよくある失敗

• 改善策を決めても担当と期限を決めず、次回に同じ問題が挙がる
• 管理職が同席して評価の場になり、表面的な意見しか出なくなる
• 毎回同じ形式を繰り返して形骸化し、開催そのものが省略される

求人票にこの語がある場合に読み取れること

「ふりかえりを定期的に実施」と書かれている場合、チームが自分たちで進め方を変える裁量を持つ組織だと推定できます。ただし開催していることと、改善策が実行されていることは別です。候補者には、直近のふりかえりで決めた改善策と、それが実際に何を変えたかを確認してください。具体的に答えられる人は、場を機能させる条件を理解しています。

隣接手法との違い