ふりかえりを振り返る

これは スタンバイ Advent Calendar 2021 の9日目の記事です。

はじめに

スタンバイのCTO室にいる高原です。昨年度は LeSS（Large-Scale Scrum）のスクラムマスターを担当させていただいてました。
我々CTO室は、プロダクト組織全体のプロダクトロードマップ遂行と技術ロードマップ遂行を側方支援し、プロダクトが価値を生み出すアジリティと持続可能性と両立できるよう組織開発を行うチームです。

さて、皆さんのチームでも「ふりかえり（Retrospective）」が定着しているところが多いのではと思います。
アジャイルな現場でもそうじゃない現場でも、チームワークを改善するうえで「ふりかえり」が与える効能は非常に大きいことが、実体験として積み上がってきてて、『ふりかえりはチームワークに欠かせない仕掛け』だなぁとしみじみ思っている今日この頃です。

スタンバイはこの春にプロダクト全体での LeSS からサブプロダクトごとの自立チーム開発体制へと移行しました。それから半年が過ぎて各チームの営みに個性が出てきていることを miro や Slack などから垣間見てきました。
そこで、ここらあたりであらためて「ふりかえり」ってどんな目的で(why)、どんなアジェンダを話すもので(what)、どんなやりかたや工夫ができるか(how)・・・といったあたりを思い返して、各チームの取り組みや事例の共有などもしておきたいなと考えました。

以下本稿は、社内LT会「StanBy Conference」で発表した内容をベースに、発表後の後日談や図表を加えて、反対に社内実施状況レポートの細かすぎる部分を差し引いたかたちで再編集したものです。

ふりかえりの目的 を振り返る

まず「目的」を再確認しておこうと思って参考図書やWebをざっと探してみたのですが、意外と「ふりかえりの目的」を明記している文章がないことに気付きました。とはいえ、なにごともwhyのない議論は無意味になりがちなので、目的はハッキリしておきたいところです。

そこで、立ち返って、ふりかえりの前提条件を考えると・・
同じ（または類似の）環境下でチームワークが継続すること
と言えると思います。じゃないと、ふりかえっても結果を活用できないからです。

そのうえで、ふりかえりの目的を再定義すると・・
これからのチームワークをカイゼンすること
と言えそうです。ふりかえりを行う状況によって議論するスコープやテーマを絞ったほうが効果的な時もあると思いますが、共通する目的は「これからのチームワークをカイゼンすること」に集約できると思いました。

ふりかえりの流れ を振り返る

次に、ふりかえりを行う流れを再確認していきます。
ふりかえりについて書かれた代表的な書籍二つを参照して、流れ＝ステップを書き出してみました。

上記のとおり両書籍でほぼほぼ共通しています。太字にした核心部分となる３つのステップについて内容を補足して書き出してみます。

データを収集する｜出来事を思い出す
実際に起こったことを客観的に見返して、良かったことや
良くなかったことをピックアップし、共通理解をする。
⬇
アイデアを出す｜アイデアを出し合う
話す事象を選んで、要因を分析して、
これまでよりカイゼンするためのアイデアを出し合う。
⬇
何をすべきかを決定する｜アクションを決める
出たアイデアを優先付けして、具体的なTRYを出したり、
チームのルール（Working Agreement）を更新する。

これらの事前に行う「場づくり」も効果的なふりかえりに重要ですし、それ以前に、今回のふりかえりの「目的」をしっかり設定できていることが大切でしょう。それらによって、以下で採り上げる様々なふりかえりの「手法」のどれをチョイスするかの判断も変わってくると思われます。

また事後には、いま実施した「ふりかえり」自体についても振り返って次回のカイゼンを試みることが両書籍で推奨されています。
本稿も「ふりかえり」自体を振り返った際に読み返していただけるものになれば良いなと考えながら書き進めています。

さて、ふりかえりの「手法」として数多くのプラクティスがあると思いますが、ふりかえりの流れの中のどこでどういった狙いで使うべきかを意識して効果的に使い分けられているでしょうか？
今回は、上記で核心部分とした３つのステップそれぞれについて、どんな手法とどんな特徴があるかを振り返って整理しておきたいと思います。

データを収集する手法 を振り返る

実際に起こったことを客観的に見返して、良かったことや良くなかったことを（主観的に）ピックアップして、それらの共通理解を図る。
・・・そのための手法にはどんなものがあるでしょうか？

客観的データを集める
スプリントバックログ、ベロシティ、バーンダウンチャート、バグの収束数／時間、障害発生レベル／復旧時間などなど、チームの活動実績を示す定量的なデータをできるかぎり集めます。
データというまさに客観的な事実を見つめて考え、議論することで、チームの生産性に直結するようなインサイトが得られる可能性が高いはずです。
また、データを集めてこようとすると欲しいデータが取れていない事実に気付くこともあり、それ自体がカイゼンの意味を持つこともあるでしょう。

イメージ

いっぽう、この手法を毎週・毎スプリントやるのはコストが高いかもしれません。そう感じる場合は『客観的データを集めて行うふりかえりを、月１回（または四半期に１回）必ず行うなどと決めてスケジュールを確保しておくとかもお薦めです。もしくは、ふりかえりのスコープ・テーマをあるていど絞って、先ずそのテーマに沿ったデータが何かをすり合わせてから集めてくるというやり方もよいのではと思います。

Timeline
時系列に「事実」や「感情」をマッピングして文字通りタイムラインを作ることで、どんなことが起こったかを思い出して、起こったことについて良かったことや改善点を洗い出す。
この手法は、スプリントのように短い期間でも、プロジェクトという長い期間でも、あるイテレーション・一定期間内に発生した出来事を振り返るのに適していると思います。

上は1週間スプリントの Timeline イメージ、下はプロジェクト期間の Timeline で出来事を書き出してから感情を書き出しているイメージ

他にもいろいろな手法が書籍やWebで紹介されています。気になっているけど未だ直接やったことがないものもありまして・・

Team Rader（チームが重視するいくつかの要素を軸にしてレーダーチャートを各自で作ってもらうプラクティス）のようにメンバーひとりひとりの受けとめ方を見比べられるものとか

sail-boat（島：ゴール、追い風：機会、錨：阻害要因、岩：リスク）や、hot-balloon（上昇気流：機会、荷物：阻害要因、雲：リスク）のような、誰もが分かりやすいメタファーを使うことで、未来も含めた中長期的な視点で考えられるものとか

機会があれば試していきたいと思います。

アイデアを出す手法 を振り返る

話す事象を選んで、要因を分析して、これまでよりカイゼンするためのアイデアを出し合う。
・・・そのための手法にはどんなものがあるでしょうか？

まず前半部分、話す事象を選ぶところまで見ていきます。

グルーピング
類似するものをグルーピングすることで、まとめて議論したり選んだりすることができます。皆さんもよく行っているのではないでしょうか。

グルーピングの代表的手法である「KJ法」では、グルーピング → 並べ替え → 文章化 を手順としていますが、いま一緒にグルーピングしてコンテキストが揃っている状態なら、文章化（各グループのラベリング）まで行わなくても次の議論に進められると思います。
逆に、グルーピングまでに時間を使ったので日を改めて再開するような時は、再開時に思い出せるよう、皆でラベリングをして終わっておいたほうがよいかもしれませんね。

ドット投票
こちらも皆さんよく使われているのではと思いますが、付箋にドットシールを貼って、どれを優先して議論するか投票によって決める手法です。
制限時間を決めてその間は話さずに投票することで集団思考を回避しつつ、全員参加ができるので、公平性・納得性も高いと思われます。
また、評価基準や賛同レベルでシールの色を変えるやり方もありますし、ひとり何票までにするかをその場で決めることも多く、ファシリテーター目線では参加者とインタラクションを行えるよい機会だったりもします。

グルーピングした後にドット投票をしたイメージ（右側）

評価軸へのプロット
少し前にアジャイルコーチの方に助言を求めつつカタチにした手法です。
当時は、ふりかえりでチームの生産性など中長期的な課題へのフォーカスが弱いという悩みを抱えているチームがありました。
それは半分妥当でもあって、仮に日々の働き方に大きな違和感を抱えたままで「生産性もへったくれもない」状況に陥っていれば、急ぎカイゼンする必要があるでしょう。ですが、例えば障害発生とかチーム外から何か指摘を受けた時とかに、直近で感情を揺さぶられた事象ばかり優先度を上げてしまいがちになっているという現象も起こっているようでした。

そこで、議論対象を選ぶときに『近視眼的になり過ぎない』仕掛けとして、予めチームで決めた評価軸にプロットする作業を挟むことで、優先度を客観視する仕掛けを加えてみました。

評価軸の例：
・プロダクト品質への影響が大きい〜小さい
・チームワークへの影響が大きい〜小さい

イメージ

このようなプロットを投票の前に行うことで、自分たちが大切にしたいことにフォーカスできる効果が得られると思います。

それでは後半へ。要因を分析して、よりカイゼンするためのアイデアを出し合う・・部分も見ていきたいと思います。

なぜなぜ分析（Five Whys）
事象に対して「なぜ？」の回答を繰り返し繋げていくことで、表面的な謝罪のうような定性面にではなく、要因・定量面に向き合ってロジカルに根本原因へと到達する議論ができるとされています。
その場しのぎで終わらない議論のために、勇気を出してもう一回「それはなぜ起こっていると思いますか？」と問い合える文化を作りたいですね。

Fishbone Diagram（特性要因図）
フィッシュボーン図は「QC七つ道具」の一つとしてPM界隈でも有名です。
大骨を描く際に、4M（Methods, Machines, Materials*, Man-power）、4P（Place, Procedure, People, Plicies）などのカテゴリ分類に沿うことで、必然的にマルチな観点で議論が行えそうです。

* Materials は「原料・材料・資材」という意味だが、ソフトウェア業界の文脈では「道具・ツール・資料」などの意味で使われることが多い。
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き Esther Derby and Diana Larsen 著／角 征典 訳 オーム社（2007/9/25）

何をすべきかを決定する手法 を振り返る

出たアイデアを優先付けして、具体的なTRYを出したり、チームのルール（Working Agreement）を更新する。
ここまでの、データを収集する〜アイデアを出すステップでは過去のデータや感情を思い出して要因分析を進めてきましたが、この段階から、いよいよ未来にフォーカスを当てて打ち手を考えていきます。
・・・そのための手法にはどんなものがあるでしょうか？

Short Subjects（短い話題）
お馴染みの「KPT」など数多くのバリエーションがあります。
例えば...
・Stop Doing / Start Doing / Keep Doing
・KPT（Keep / Problem / Try）
・YWT（やったこと / わかったこと / 次にやること）
・Fun / Done / Learn
・+ / Δ（plus / delta）
などなど。
そういえば、先日、miroのテンプレートを「retrospective」で検索したら9種類も出てきました（2021年11月末時点）。余談でしたw

KPT や +/Δ と比べると Fun/Done/Learn（右側） の
フォーマットに重なりが存在することが興味深い

これらは感情からフォーカスして事象を洗い出すアプローチとして、データを収集する手法としても使うことができます。
客観的事実からフォーカスして事象を洗い出すアプローチと意識的に使い分けてみるとよいかもしれません。
このように、ふだん使い慣れた手法でも、自分たちはどのステップのためにどんな意図で使っているか再確認してみるのも有意義かもしれません。

SMART Goals
そして、アクションを計測できる目標とアクションプランを立てる際に意識するとよさそうな問いが「SMARTになっているか？」です。
・Specific（具体的で）
・Measurable（測定可能な）
・Achievable（達成可能な）
・Realistic / Related / Relevant（適切な目標に関連した）
・Time-Based / Time-bound（期限など時間制約がある）

画像検索した中でこなれたデザインに見えたので引用したToolsheroの絵

こうして今より未来をカイゼンする TRY や新しい行動指針を決められたら、バックログに積んで実行したり、チームの Working Agreement を更新したりして変化に取り組んでいくことができます。
これらの効果をまた次回ふりかえって・・カイゼンのスパイラルをぐるぐると回しながらチームが上昇していくイメージでしょうか。

社内の実施状況や事例 を振り返る

ここまでの、ふりかえり再確認の旅、おつかれさまでした。
最後に、スタンバイ各チームのふりかえり実施状況についてヒアリングした結果を共有させていただきます。

実施頻度

よく採り上げられるテーマ
・チーム内の仕事の進め方
・チーム外との仕事の進め方
・イレギュラー対応をして気付いたこと
・チケットの消化率、見積りの精度
・システムの課題点
チームの属性によっても頻出テーマの傾向が異なってました。

カイゼン事例
・全体の進捗を掴みにくい →マイルストーンを全員で確認するようにした
・QAリードタイムが長い →上流工程から参加して先回りするようにした
・トラブル対応が属人化 →他の人もメンテできるようドキュメントを書くようにした
・割り込み対応に時間を取られる →届いた依頼の背景を確認して、優先度判断を通してから対応に取り掛かるルールにした
・AC（Acceptance Criteria＝受け入れ条件）を満たしても課題が解決しない →チケットの背景を意識して対応できるように who, what, why を明記するようにした／してもらうようにした

後日談 も振り返る

以上のような内容で社内LTをさせてもらった後にあった会話を書き添えておきます。

長く所属しているメンバー（むしろふりかえりの先輩）からはこんな意見が

意見の方向性が偏ってきたなとか、意見の出る量が落ち着いてきたなとか、マンネリ化してきたなとか感じることがあるので、どんどん新しいやり方を探してきて入れ替えてみている。

最近入社したメンバーからはこんな意見も

この会社に来てからは、ふりかえりを個人の責任に帰着させてしまうことがないので、安全さを感じている。以前の職場では、こういう場面で「詰められる」ことが多く、言いたいことを言える状況ではなかった。

後者は典型的なアンチパターン・・ヤバいですよね。
今回詳しく触れなかったのですが、ふりかえりの最初のステップ「開始する（場を設定する）」がちゃんとできていない可能性が高そうですし、そもそも目的を間違えてしまっているようです。こういうかたちでやってしまうと、逆にチームワークにマイナスが生じそうですね・・・。

まとめ

・ふりかえりはチームワークをカイゼンする重要なイベントだと思います。
・ふりかえりの目的や、進め方のステップをたまには再確認して、いろいろな手法に  try していただくのもよいのではと思います。

・・・というわけで、
一年を振り返るタイミングでの「ふりかえり」のお話でした。
普段ちゃんとwhyに向き合っている皆さんからすると「そんなの当たり前」な内容だったかもしれませんが、ご容赦ください。
また、皆さんのチームで使っている手法や事例、気付きなどを教えていただけると嬉しいです。

2022年も、よりよいチームワークでよりよい成果を出していきたいですね！

参考文献

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き Esther Derby and Diana Larsen 著／角 征典 訳 オーム社（2007/9/25）

アジャイルなチームをつくる ふりかえりガイドブック 森 一樹 著 翔泳社（2021/2/17）

【社内連絡】スタンバイ図書に上記2書籍のラインナップを完了しています