私の関わるいくつかのチームではよくふりかえりをします。ScrumチームがSprint毎に行う「Sprint Retrospective」であったり、フロントエンドエンジニアのチームが隔週で行う「カイゼンミーティング」であったり、呼び名や頻度や内容は様々ですが、定期的に自分たちの行動を思い返し何らかの学びを得る活動をしています。

今回は、これらのふりかえりを私がどのように設計しているかについて、ふりかえってみようと思います。せっかくなのでテンプレートという形で書き出してみます。

ちなみにこの記事では「過去のある期間を振り返って気づきや学びを得て、今後の行動に反映する一連の活動」を ふりかえり と呼び、ふりかえりの一貫として開催されるミーティングを ふりかえりミーティング と呼び分けることとします。

ふりかえりの大枠をデザインする

いきなりふりかえりミーティングについて考え出すのではなく、ふりかえりそのものの目的から考えていきます。

ふりかえりの目的

  • [誰に] [どうなってほしい]
  • [誰が] [どうなりたい]
サンプル
  • 「チームメンバーに」「開発プロセスをより良くしてほしい」
  • 「チームメンバーに」「継続的な改善を習慣づけてほしい」
  • 「マネージャーの私が」「チームメンバーが今の体制についてどう感じているか知りたい」

ふりかえり目的の達成基準

どんな状態になっていれば、または何ができあがっていれば、上で設定した目的が達成されたと判断できるかを明確にします。

  • [状態] になっている
  • [最終成果物] が完成している
サンプル
  • 「チームが最も優先して対処すべき課題について共通認識を持っている」
  • 「開発プロセスを改善するための具体的なTODOリストが完成している」

条件・制約

ふりかえりミーティングを設定するにあたって考慮しておいたほうがいいことを洗い出しておきます。以下の項目を基本セットとし、状況に応じて追加で洗い出します。

  • ふりかえりに使える [時間] × [頻度]
  • ふりかえりの [参加人数]
  • 参加者それぞれの [所在地]
  • ふりかえりミーティングに使える [スペース(オンライン/オフライン)]
  • ふりかえりミーティングに使える [ツール]

個別のふりかえりミーティングをデザインする

今回のふりかえりミーティングで目指す「フェーズ」

ふりかえりミーティングで話し合われる内容は、大きく3つのフェーズに分類できます。ふりかえりの目的を達成するためには最終的にどのフェーズまで話し合う必要があるか、そして今回のふりかえりミーティングではどのフェーズまで進めたいかを考えます。プロジェクトを完了させるためにマイルストーンを引くようなイメージです。

フェーズ 概要
発散フェーズ まずは参加者の意見やアイデアを出し切ります
深堀フェーズ 意見やアイデアについてディスカッションをし、理解を深めたり、取捨選択をしたり、考えを発展させたりします
解決フェーズ 結論を出したりActionに落とし込んだりして、ディスカッションを収束させていきます

実際のミーティングの場では、これらのフェーズが明確に分かれていないこともあります。ディスカッションするうちに盛り上がって更に多くの意見が出て…といった具合に発散フェーズと深堀フェーズをいったりきたりすることってありますよね。それ自体は悪いことではありません。

ただ、事前にどのフェーズまで到達したいかの目星をつけておくことで、ファシリテーションがしやすくなります。
例えば「どんなに議論が盛り上がったとしてもラスト15分では解決フェーズに移ろう」と心の準備をしておくことで、ラスト15分までの時間で発散と深堀をいったりきたりしても焦ることなくファシリテーションできたりします。

余談ですが、チームができたばかりの時期にはよく「お互いにどんなことを感じたか、どんな気持ちだったかを知り合うこと」を目的としたふりかえりをするようにしています。これは発散フェーズまでのふりかえりと言えるでしょう。

今回の参加者の属性

ふりかえりミーティングの参加者が毎回同じ顔ぶれになるとは限りません。役割ごとに集まって少人数で意見を出し合うふりかえりミーティングを開催することもあるでしょうし、ステークホルダーがゲスト参加して一緒にふりかえりミーティングをすることもあるでしょう。参加者の属性や関係性を把握することで、より参加者に合った手法を選択できます。

  • 参加者の人数
    • 人数が多すぎて全員の意見を集めきれない可能性はないか？
    • 人数が多すぎて参加者が発言する際に心のハードルが上がる可能性がないか？
    • (本来参加してほしい人数に比べて)人数が少なすぎて意見が偏る可能性がないか？
  • 参加者の関係性
    • 同じ立場・役割の人は何人いるか？
    • 初対面の人はいるか？
    • 評価者・被評価者の関係の人はいるか？
  • それぞれの参加者の参加場所
    • 一堂に会するのか？ その場合、話しやすい座席構成にできそうか？
    • テレビ会議でするのか？ その場合「ひとりだけテレビ会議」など発言しにくい環境になっていないか？

実際には、これらの懸念点がまったくない状態をつくるのはけっこう難しいですよね…。私の属するチームは東京と福岡の多拠点なので、テレビ会議の懸念は特に起きがちです。
事前に払拭できずファシリテーションでカバーする場面などもあり、そのためにも事前の情報収集が大切になります。

今回のふりかえり手法

目指すフェーズが決まり参加者の属性を把握したので、これらを踏まえていよいよ手法を考えます。手法については、事前に決めきるより取り得る選択肢をいくつか用意しておくことが多いです。ミーティングの状況に応じて対応できるようにするためです。

手法は調べるとたくさん出てきますし、アレンジすることで無限に増えるので、ここでは手法選びで気をつけていることを挙げます。

✓ 発散フェーズで気をつけていること

このフェーズで特に大事にしていることはいかに発言しやすい場を作るかと、言語化が難しい感覚や違和感をいかに表現してもらうかです。具体的には以下のようなことを考えます。

  • Keep/Problem/Try などの意見を集める指標は、状況に応じてアレンジする
    • Problem に『反省文』ばかりが集まるときは「困難だったこと」などに置き換える、など
    • Try に『曖昧な行動』が集まるときは「Tryを実現するためのAction」などの指標を増やす、など
  • 論理的な意見だけでなく、感情・感覚・違和感を出してもらうような指標を使う
    • 「モヤッとしたこと」「みんなに聞いてみたいこと」「ぼやき」など
    • 状況に応じて「改善案」などの主張が強く取られる言葉を「試してみたいこと」などの柔らかめの言葉に置き換える
  • 全員が意見を出しやすい仕掛けをする
    • ふりかえりミーティング中の内職が気になるときは、ペンと付箋を使うことで気持ちを切り替えてもらう
    • 一人で考える時間とみんなで話す時間とを明確に分ける
    • 座らずにホワイトボードの前に立って集まる
    • 「意見を発表した後は次に意見を出してほしい人を指名する」などのルールを参加者みんなで作る
  • 言語化しにくい意見を集めるときは、文字や言葉以外の方法も使う
    • モチベーションを折れ線グラフで表現する
    • 付箋の色やドットシールの色で感情を使い分ける
    • 納得度合いを0~3点で判断し、点数の数だけドットシールを貼る
  • 全員に最低1回は意見を声に出してもらい、ふりかえりミーティングに参加するスイッチを入れてもらう
  • 意見やアイデアを「チームの意見」と意識してもらうために、無記名にする
✓ 深堀フェーズで気をつけていること

このフェーズでは、深堀りするトピックを選択し集中することに意識を向けます。ただし、どの意見やアイデアも等しく大切な参加者の声です。どれかを蔑ろにすることなく深堀りすることが重要であり、難しいポイントでもあります。そのために、意見の関連付けや優先順位について、合意をとることがあります。

  • 出してもらった意見は全員が見渡せるように並べる
    • 付箋で出してもらった場合は、大きな模造紙やホワイトボードに貼り付ける
    • 意見を口頭で発表してもらう場合は、ホワイトボードなど見えるところにメモをとる
  • 出してもらった意見が多いときは関連性のある意見を近くにまとめて並べる
    • 関係性を見出してもらい、さらに発想が広がることに期待する
    • 関係性がバイアスになりそうなときはあえてランダムに並べることも
    • カテゴライズ、二次元マッピング、相関図、など情報にあったまとめ方を提案する
  • 出してもらった意見すべてを1回のミーティングで深堀りしようとしない
    • ディスカッションが盛り上がると1トピック20〜40分くらいかかりがち
    • ミーティングの時間と目指すフェーズを考慮しながら何トピック話せそうか目星をつける
    • どのトピックから話すのか優先順位を決めるために投票してもらう
    • 投票では「話すもの・話さないもの」を決めるのではなく、「話す優先順位」を決めるだけ。投票の少ない意見を切り捨てない
✓ 解決フェーズで気をつけていること

解決フェーズで大事なことは実行可能性を高めることに尽きます。

  • Actionは具体的にする
  • Actionの期限を短めに設定する(短い期間で達成できるActionに分割する)
  • Actionが大きくなりすぎてしまったり抽象的になってしまう場合は、先行指標をつくる
  • Actionが出すぎてしまう場合は上限数をつくる
  • Actionアサイン前に、Action実行に割り当てられる時間を見積もっておく
  • ふりかえりミーティングを定期開催している場合は、Actionの粒度を「次のミーティングまでにできること」にする(同時に開催頻度を増やし、1度のミーティング時間やActionのサイズを小さくすることも)
  • ふりかえりミーティングを定期開催している場合は、一度のミーティングで必ずしも「発散→深堀→解決」と一周させなくても良い

まとめ

こうして書き出してみると、私がふりかえりをデザインするときは「発散フェーズ」を比較的強めに意識していることがわかります。思い返すと、議論がヒートアップしてしまうことよりも牽制しあって意見が出ないことのほうが多かったので、自然とそちらに意識が向いたのだと思います。

当然ですが環境が変われば気をつけることは変わりますし、このデザイン方法がそのまま利用できない場面も出てくると思います。そうなったときにも揺るがない部分は何なのかを言語化していきたいと、ここまで書き出して気づきました。得にふりかえりをするのに適した人間関係あたりが重要になってきそうな予感です。いずれそのあたりもブログに書けるようになれたらと思います。

それでは、お互い良きふりかえりライフを。