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

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

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

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

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

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

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

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

ふりかえり会の全体像

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

今回のプロジェクトの状況とふりかえり会の経緯

Visionalグループ内のとあるプロダクトで、長期間に及ぶリニューアルプロジェクトがありました。そして、そのリニューアルプロジェクトのふりかえり会を開くにあたり、私がファシリテーションを行うことになりました。

今回のリニューアルプロジェクトは下記のような状況でした。

目的の設定

対象が長期間となる場合は話す内容が多くなるため、ふりかえり会自体も長時間になります。長時間のワークショップでもスムーズな進行にするためには、会の設計の事前準備が大切です。

まずは、今回のふりかえり会の目的を考えることにしました。今回は下記の課題があるように感じました。

そこで、下記の目的でふりかえりを行うことにしました。

目的に沿ったプラクティスを考える

課題の解消及び、目的1「チーム全体の共通認識を持つ」を達成するためには長期間をふりかえる必要があったので、タイムラインを使ったプラクティスをベースにして、インタビューのプラクティスを活用することにしました。

また目的2「プロジェクトを見直すことで、未来の行動を決定する」を達成するために、課題に着目したOST形式のプラクティスをベースにして、妄想のプラクティスや赤シール・青シールによるNext Actionの明示化を行うことにしました。

次節以降で、採用したプラクティスの説明をしていきます。

プラクティス1：タイムライン

「タイムライン」とは、出来事や感情を時間軸で整理する方法です1。今回は下記のようなフレームを作成しました。

タイムラインのフレーム

タイムラインのフレームを作成するにあたり、下記の点を工夫しました。

プラクティス2：インタビュー

最近参画したメンバーは過去の状況を知らない可能性が高く、共通の理解を得るために「インタビュー」のプラクティスを活用します。

インタビューによって変わる姿

このプラクティスでは、最近参画したメンバーがインタビュアー、プロジェクト開始当初から参画していたメンバーがインタビューを受ける人になって、プラクティス1で出てきた「気になったこと」の付箋を中心にインタビューします。

なお、謝罪の記者会見でのインタビューではなく、雑誌の取材のような感覚で臨むと良いです3。

インタビュー

このプラクティスでは、原因追及だけでなく、それが発生した後どんな困ったことに繋がったのかを聞くように、インタビューの例を示す工夫をしました。

以下の画像で示したインタビュー例のうち、「そのあとにどんな困ったことが起こったの？」という質問は特に重要です。この質問に対して、「いや、別に何も困ってないけど…」というような回答が出てくる場合は、「問題だったこと」ではなく「解決したかったこと」である可能性があります。

例えば、画像の例のように「コードレビュー不足」を問題点と考えている場合、「コードレビューをもっとしっかり行いたかった」という願望の可能性があります。それに対して、「そのあとにどんな困ったことが起こったの？」と聞く4ことで、staging環境が動かなくなった原因の1つであることが分かりました5。

インタビューした結果、事象や感情の繋がりがある部分には、矢印で結ぶようにしました。これにより、昔に起こった出来事が、今現在でも問題として続いていることに気付けます。

インタビュー例

もしも、「気になったこと」の付箋が多すぎて選ぶことができないとなった場合は、下記の表にあるような文章表現の付箋を探すと良いです。この表は『ソフトウェアプロセス改善手法 SaPID入門 現場力を引き出すシステムズアプローチ』のp52「表3.4 文章表現5つの禁則」に記載されています6。

付箋の記載スタイル 付箋の具体例 深掘り方法
体言止め・紋切型 モラル
計画		 内容を具体化して生々しい出来事を記載する。
不足型・不十分型 レビュー不足
テストが不十分		 不足・不十分となっている内容を具体的に示す。
不足していることで発生している出来事を明確にする。
対策型 □□基準が存在しない それがないために発生している困った出来事や状態を記載する。
疑問型 ◯◯スキルに問題あり？ 疑問に思った経緯や背景・出来事を具体的に記載する。
断定型・推論型 Aさんはやる気がない
最初からムリな計画なのではないか？		 そう考えた経緯や背景・出来事を具体的に記載する。

この中でも、まずは「不足型・不十分型」と「対策型」に狙いを絞って付箋を選ぶとスムーズにインタビューできると思います。インタビューした結果、「特に具体的に困った出来事は無い」という回答を貰った場合、「気になったこと」として書いたものの、実は現時点では困っていないかもしれません。

プラクティス3：OST形式による課題の深掘り

タイムラインおよびインタビューのプラクティスでは、時間軸で整理できる一方で、1つの課題に注目して深堀りをするのは難しいです。 そこで、複数人が気になっている課題をOpen Space Technology(以下、OST)形式7で分かれて深掘りすることにしました。

OSTを実施するまでの手順は下記の通りです。

  1. 「気になったこと」の付箋の中で、特に自分が気になっている付箋を1つ選ぶ
  2. 何を選んだのか、なぜその付箋を選んだのか発表する
  3. みんなの発表を聞いて、特に気になった付箋2つに黄色のシールを貼る
  4. 黄色のシールが多かった付箋をピックアップする
  5. それぞれの付箋ごとに気になる人同士で集まりグループを作り、グループワークを行う

なお、OST形式にする時は、最低でも3人以上がいる状態にしました。（なぜ3人以上を条件にしているかは後編の記事で紹介します）

プラクティス4：Goodに繋がる妄想

課題の深掘りをする際は、プラクティス2「インタビュー」に加えて、Goodに繋がる妄想を自由に出してもらいました8。

例えば、「Aさんに作業が集中する」という課題があったとします。

まずはインタビューのプラクティスを用いることで、下記のような付箋が出ます9。

Aさんに作業が集中に対してインタビューを行った結果

このうえで、「あり得なさそうだけど、今回の議題が課題にはならなくなる妄想（Goodに繋がる妄想）」をしてもらいます10。

Goodに繋がる妄想を追加

Goodに繋がる妄想をしたら、これを全力で否定する内容を考えてもらい、付箋を上書きします。

Goodに繋がる妄想を否定する

これによって、新たな問題点が見つかるかもしれません。例えば今回の例の場合、「Aさんだって会社を休む時がある」という付箋を出したことで「Aさんが休暇中の時って問題起きそうだよね…？」と気付くことができました。

新たな問題点

逆に、付箋を上書きできない（否定できない）のであれば、実は課題ではなかったのかもしれません。

このプラクティスの最後に、問題点同士で因果関係のあるものを線で結びます。

このように行うことで、注目していた課題に対してさらに別の課題が連鎖していく様子が分かるようになります。

問題点同士の結びつき

プラクティス5：赤いシールと青いシール

ここまでのタイムラインやOST形式の課題の深掘りによって、KPTでいうKeepとProblemをたくさん議論しました。

ここからTryやNext Actionといったものを導き出すために、赤いシールと青いシールのプラクティスを行いました。なお、この手法はソフトウェアプロセス改善手法の1つ「SaPID」の一部を参考にしています11。

まず、課題の深掘りを行った中で、特に問題となっている付箋に赤いシールを貼ってもらいます。

次に、赤いシールを貼った付箋を解決するきっかけとして、一番負荷が少なく解決できそうな課題に青いシールを貼ってもらいます。

シールを貼った図

カイゼンをする時は最初の一歩が大切です。そして、その一歩目は小さな一歩を選ぶべきです。そのため、最終的に解決したい課題を赤いシール部分と意識しつつも、一歩目を踏み出すための狙いとして青いシールを貼ってもらいます。

おわりに

本記事では、長期間のプロジェクトのふりかえりとして実際に用いたプラクティスを紹介していきました。

今回のプラクティス選択でのポイントは以下の6点です。

もしも、今回行ったプラクティスおよびファシリテーションに興味がある場合、SaPID Bootcampへの参加をオススメします。1年に約1回の頻度で開催されています。今回のプラクティスの大部分はSaPIDの流れを参考にしました。

次回の記事では、プラクティスを実際のふりかえり会に落とし込むにあたり工夫した、メンバー構成や時間構成などのポイントを紹介します。

  1. 参考文献 『ふりかえり読本　実践編　〜型からはじめるふりかえりの守破離〜』 p59 3.6.2 Timeline ↩︎

  2. 参画時期の記入は、参考文献にも無い項目です。これは、チームの状況に合わせてカスタマイズした結果です。 ↩︎

  3. 謝罪の記者会見の感覚だと、インタビューを受ける人は「自分の非はあまり言わないようにしよう」と考え、インタビュアーは「どうやって非を認めさせよう？」と考えてしまい、腹の探り合いになってしまうため良くありません。雑誌の取材のように、「実はあの時は◯◯で…」と、当時の内容を赤裸々に話せるような場になることが大切です。 ↩︎

  4. 参考文献 『ソフトウェアプロセス改善手法 SaPID入門 現場力を引き出すシステムズアプローチ』 p53 表3.5 禁則表現への対応例 ↩︎

  5. ちなみに、よく知られるプラクティス「なぜなぜ思考」は、原因追及が中心のプラクティスです。時間軸で考えると、問題点よりも昔の事象が沢山出てきます。今回は問題点よりも未来の事象の繋がりを知るために「なぜなぜ思考」を活用しませんでした。 ↩︎

  6. 表のヘッダー部分の表記が参照元とは異なっています。今回のふりかえり会の状況に合わせるため、ヘッダー部分の表記を変更しています。 ↩︎

  7. 参考文献　Wikipedia - オープン・スペース・テクノロジー ↩︎

  8. これは私の知る限り、オリジナルのプラクティスです。 ↩︎

  9. なお、ここでも時間軸を意識して、左側が過去、右側が未来となるように付箋を配置します。 ↩︎

  10. この付箋は無邪気に出すことが大切です。変に真面目に出そうとすると、思考を広げることを妨げてしまいます。 ↩︎

  11. 参考文献『ソフトウェアプロセス改善手法 SaPID入門 現場力を引き出すシステムズアプローチ』 p61 STEP4 改善ターゲット検討・特定 ↩︎

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

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