新規プロダクトや大きな機能のリリース、大規模リニューアルなど、長い時間かけて行うプロジェクトは少なからず発生します。 みなさんは、そのようなプロジェクトのふりかえりは上手く行えていますか？また、オンラインでのふりかえりはどのように行っていますか？この記事では、長期間のプロジェクトに対するふりかえりの方法を、どのように準備して行なっていったかをご紹介します。

今回のふりかえり会の全体像

今回のふりかえりではmiroを用いて下記の流れで行いました。それぞれのプラクティスの内容については、前編で説明しています。

ふりかえり事前会アジェンダ

  1. 参画時期の共有（プラクティス1）
  2. 起こったことの共有（プラクティス1）

ふりかえり本会アジェンダ

  1. 本日のチャレンジ宣言（アイスブレイク）
  2. 良かったこと、気になったことを共有（プラクティス1）
  3. インタビュー×3（プラクティス2）
  4. 課題の狙いを定める（プラクティス3）
  5. OST形式による課題の深掘り（プラクティス3,プラクティス4）
  6. Next Actionを定める（プラクティス5）
  7. ふりかえり会のふりかえり

以下の画像のようなmiroボードを用意しました。画像内の丸数字は、上記のアジェンダの数字と対応しています。

ふりかえり会の全体像

今回は前編と後編の2回に分けて、どのようにふりかえり会の準備・設計を行ったのか紹介します。

チーム分けを考える

前編でお伝えしたプラクティスを用いる際、「参加者全員だと人数が多い」「様々なロールの人が集まっている」「メンバー間で知っていることの差が大きい」という状況であるため、議論を参加者全員で行うことが難しいと考えました。そこで、人数やメンバー構成について考えることにしました。

ワークの人数を考える

オンラインでのふりかえり会は、オフラインでのふりかえり会以上に、下記の理由からグループワークの人数設定を考慮する必要があります。

この考えと、今回のふりかえり会の目的1「チーム全体の共通認識を持つ」を両立させるため、下記の方針でチーム分けを考えました。

チーム構成を考える

今回のふりかえり会の目的1では「チーム全体の共通認識を持つ」と定めました。 しかし、今回のふりかえり会は開発者・SRE・QAというロールの参加者がいます。そのロールを混ぜて、全ての事実内容について共通認識を持つことは、今回は難しいと判断しました。ただし、ふりかえり会の後半に行う課題の議論はチームを混ぜて行うことが可能だと考えました。

今回のワークにおけるチーム構成を考える

以上の適正人数とチーム構成の考えを元に、メンバー構成について下記4種類を使い分けることにしました。

グループワークのチーム構成

今回の場合、それぞれのアジェンダで下記のようなグループ分けにしました。

  1. 参画時期の共有…同一ロール内ワーク
  2. 起こったことの共有…同一ロール内ワーク
  3. 本日のチャレンジ宣言…個人ワーク＆同一ロール内ワーク
  4. 良かったこと、気になったこと共有…同一ロール内ワーク
  5. インタビュー×3…同一ロール内グループワーク
  6. 課題の狙いを定める…個人ワーク
  7. OST形式による課題の深掘り…ロール混合グループワーク
  8. Next Actionを定める（プラクティス5）…個人ワーク
  9. ふりかえり会のふりかえり…個人ワーク

グループワークの構成を考える

今回のプロジェクトの課題「長期間のプロジェクトであり、人も固定されていなかったため、知っていることの差が激しそう」を解消するために、同一ロール内グループワークで行う「インタビュー」のプラクティスでは、グループ構成を事前に検討しました。

その場でグループを決めてしまうと、グループ全員が最近参画した人となってしまう可能性があるため、必ず1人は初期からプロジェクトに参加していた人にしました。

また、初期からいた人がプロジェクトの全てを知っているわけではないので、3回に区切ってグループの入れ換えを行う形にしました。その結果、以下のようなグループ分けをしました。（数字はプロジェクトに参画した順番）

グループ分けの例（数字はプロジェクトに参画した順番）

時間構成を考える

ここまでのプラクティスをすべて行うと、全部で3時間を超えるふりかえり会となってしまいます。 そこで、下記の2点の工夫をしました。

ふりかえり事前会と本会の2回に開催を分ける

「1. 参画時期の共有」と「2. 起こったことの共有」は、本会の前日までに事前に行いました。 これにより、当初は連続3時間のふりかえり会だったものが、30分＋2時間半のふりかえり会になりました。

それにより、下記の2点のメリットがありました。

1時間に1回は休憩を入れる

オンラインの場合、他の人の目があまり無い分、長時間の集中が難しいです。そこで、1時間に1回を目安に休憩を入れるようにしました。

アイスブレイクを考える

ここまでで、ふりかえり会の骨格はほとんど作成完了しました。最後に、ふりかえり会の本会のアイスブレイクを考えることにしました。

今回のように30人を超える大人数でふりかえりを行うと、どうしても「よく発言する人」と「あまり発言しない人」が出てきがちです。人間の性格上、どうしても発言量の差は出てきてしまうものの、この発言量の差は少なくしたいと考えていました。

そこで今回は、「発言量の差が出てしまう」という問題を解消するようなアイスブレイクである「本日のチャレンジ宣言」を採用しました2。

「本日のチャレンジ宣言」とは、普段の自分は行うことができていないことを付箋に書き出し、今回だけチャレンジするというものです。

例えば、以下のようなものがあります。

チャレンジ宣言の例

このアイスブレイクにより、下記の効果が期待できます。

その他の細かい工夫

以上により、ふりかえり会の設計が完成しました。 その他の細かい工夫として、下記のような取り組みも行いました。

開催結果と参加者の感想

開催した結果は以下の図のようになりました。

開催結果

会の最後に「ふりかえり会のふりかえり」と題して、参加者に自由に感想を書いてもらいました。下記のような感想をもらいました。

おわりに

今回は長期間のプロジェクトにおけるリモートでのふりかえり会でのチーム構成と時間構成の考え方を紹介しました。

ここで押さえておきたいポイントは下記の3つです。

今回のプロジェクトの状況は読者の皆さんと全く同じ状況ではないため、全く同じプラクティスができるわけではないと思います。

ただし、上記のポイントや前編で記載したポイントはどんなプロジェクトの状況でも考えるべき点だと思いますので、これらのポイントを押さえながら皆さんもふりかえりを行ってみてください。

  1. 今までのリモートでのグループワークの経験上、「2人にすると沈黙が長く続いてしまう」「6人以上だと喋らなくなる人が出てきてしまう」という考えがあったため、3人から5人のグループ構成にしました。 ↩︎

  2. 参考文献ふりかえりのチェックイン・チェックアウトに使える問いかけ集ーチャレンジ宣言 ↩︎

  3. もちろん、付箋の内容は本人に書いてもらうため、期待通りの付箋の内容になるとは限りません ↩︎

ブロッコリー
ブロッコリー

QAエンジニア。前職からテストやQAに関わってきた経験を活かし、現在は如何に有効なテストを開発者に書いてもらうか指導・啓蒙している。認定スクラムマスター、認定スクラムデベロッパー。社外活動としては、ソフトウェアレビューシンポジウム(JaSST Review) 実行委員長・WACATE（若手テストエンジニア向けワークショップ）実行委員など。