この記事は株式会社ログラス Productチーム Advent Calendar 2022 の 17 日目の記事です
2022 年 7 月から株式会社ログラスに業務委託として関わっている近藤です。
ログラスではスクラムによる開発体制を採用しています。この数ヶ月でスクラムイベントの 1 つであるスプリント・レトロスペクティブ（ふりかえり）の改善に取り組みました。この記事では主に次の対象者向けに、改善した内容について紹介します。
※ 以下、記事中ではレトロスペクティブのことを省略してレトロと呼びます。
改善前、レトロでは Miro を使った KPT[1] を次の流れで行っていました。
ファシリテーターは直前にランダムで決めていました。参加者・ファシリテーターとして何度か参加した後、とあるレトロの場で私は次のような Problem と Try を出しました。
きっかけとなった Problem と Try の付箋
私にファシリテーターの経験があることもあり、この Try を機にチームのレトロ改善に取り組みました 💪
まず、あらためてスクラムガイドを確認し、チームとしてのレトロの目的を再定義しました。
スクラムガイド抜粋
スプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することである。
スクラムチームは、個⼈、相互作⽤、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発⽣したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。スクラムチームは、⾃分たちの効果を改善するために最も役⽴つ変更を特定する。最も影響の⼤きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加することもできる。
スプリントレトロスペクティブをもってスプリントは終了する。スプリントが 1 か⽉の場合、スプリントレトロスペクティブは最⼤ 3 時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。
スクラムガイド 2020.11
目的
スプリントレトロスペクティブの目的は、スプリント内で行ったプロセスを振り返り、議論、共有することで次スプリントの品質や効果を高めること
そして、目的にあわせてレトロの目標（ゴール）を次のように定めました。
目標（ゴール）
次回以降のスプリント品質を向上させる Next Try が決まっている
チーム、部署間の課題をオーバーオールレトロにエスカレーションする
短い時間で成果を出すためには、参加者が一丸となってゴールへ走り抜けるのが必要になります。参加者間で「なんでレトロをやるか」「何のための Next Try か」の認識を合わせることは重要です。
また、レトロでは時折チームで解決できない問題が課題として挙がることがあります。ログラスでは複数のチームがスクラムを行っており、LeSS を取り入れたオーバーオールレトロスペクティブを実施しています。チームで解決できる課題か、そうでないかについても議論することにしました。
目的を整理したところで、改善（課題）点について整理します。先述した課題も鑑みて、次の内容について改善しようと考えました。
特に議論の質については具体的に次のことを改善点としました。
改善点を明確にしたところで、次に制約についても考えました。議論の質を上げられない原因が仮に議論時間の不十分である場合、単純にレトロの時間を増やせば良いです。しかし実際は参加者のスケジュールの確保が難しいなどあり、そう都合良くはいきません。
ログラスではスプリント期間を 1 週間に設定し、レトロの時間（タイムボックス）を 50 分[2]としています。この設定は不変としました。そのため、50 分間で質の高い Next Try を生み出すため工夫を凝らす必要があります。
「非同期ワーク（KPT）を効率化する」、「議論の履歴を残し、検索可能にする」という観点から、まず見直したのは Miro を使ったワークでした。レトロ自体は十分に機能していたのですが、付箋の操作に時間を要したり、KPT の管理が難しいという課題がありました。
これまでのレトロで利用していた Miro のボード
⚠️ Miro に関する補足
補足をしておくと、Miro を使った KPT がダメなわけではありません。
KJ 法[3]を代表する付箋を用いたワークは優秀なブレインストーミングです。今回は制限時間が短いこともあり、付箋操作を初めとしたゴールを目指すことに対する本質的では無い操作を極力省き、よりワークに集中することを目指しました。時間が十分にあり、参加者の発想や気付きを促すことが重要になる場合は、視覚情報に強くアプローチできる Miro が適切だと考えます。
これまでのレトロでは特に Miro の諸操作に時間がかかっており、まとまった時間として見えにくいタイムロスが発生していました。また、ファシリテーターや参加者の Miro 習熟度によっても進行の円滑さに差が出やすく、別の方法を探すことにしました。
今回はレトロを Notion 化することを選択しました。ログラスでは Notion を普段から活用しており、メンバーは操作に十分習熟しています。レトロ DB を作ることでテンプレート化もでき、準備にかかるコストも少なくできます。
レトロ を管理している Notion DB
後述する議事設計では、順序立てられた議事次第を進めることでレトロが進行する設計にしています。誰でもテンプレートに沿うことでレトロを運用できるようにすることは、ファシリテーションの属人化を防ぐ観点からも有用です。
議事次第に沿って作られた Notion テンプレート（個々の議事については後述）
ファシリテーションにはチーム活動を共有、発散、収束、決定という 4 つのプロセスに分けて設計する方法論[4]があります。このプロセスを参考にレトロを再設計をしました。
上記の中から、次の内容について説明していきます。
チーム活動では、参加者が協力してゴールを達成していく雰囲気が重要です。冒頭で参加者が集まる目的と達成すべきゴールの認識を必ず合わせます。他にも時間などのゴールを達成するために必要な情報を共有することが大事です。
レトロのテンプレートの冒頭に先述した目的、ゴールを記載しました。
レトロのテンプレートの冒頭
Notion 化した直後、数人の参加者の KPT が Miro と比べて減少しました[5]。対象の参加者にヒアリングしたところ、スプリントでの出来事が思い出せないという意見がありました。1 週間のスプリントとはいえ、40 時間分の活動のふりかえりになり、思い出せないのも無理のないことです。これまでは他の参加者の KPT を見て思い出し、記載時間を延長するなどしていたため十分な KPT の数が確保できていたと予想しています。
この対策として非同期作業（KPT）を始める前に、スプリントで発生した出来事を共有することにしました。
スプリント中の出来事を掲示、挙げてみると結構ある
ここに記載する内容はレトロ開始の数時間前に参加者に対して、今スプリントで何があったかを Slack で募集します。KPT ワーク中はこちらの一覧を画面共有しています。
実は KPT が減少した参加者全員が別のチームに移動してしまったため[6]、課題に対する改善効果の計測ができていません。ただ、この改善によってよりユニバーサルなレトロになったという実感があります。
50 分間の制限を変えずにレトロの質を上げるには、非同期作業の設計が重要になります。これまでも非同期作業だった KPT ワークをさらに改善したことと、グルーピングを非同期化したことについて説明します。
KPT ワーク（発散）
Notion 上で KPT を行うために、DB 機能を利用しています。これはアセンド株式会社の丹羽 CTOが考案した方法で、許可を貰って使っています。
Notion DB を使った KPT ボード
参加者全員が 5 分間で 1 行につき 1 つの KPT を記載します。列は名前、KPT 内容、KPT の種類の順になっています（細かい工夫は沢山あるため、やり方などはあらめて別記事で解説する予定です）。この方法で一番意識しているのはふりかえり項目の生産性です。質の良い議論のためには、最初に十分な発散をしておくことが大事です。名前と KPT 種類の選択、KPT 内容の記載で終わるため、どんどん KPT を生産できます。参加者によってはこの方法で毎回 10 - 15 程の KPT を記載できています。全て Notion 上に保存されるため、検索・参照できるメリットもあります。
5 分間の作業の後、持ち時間 1 人 2 分で内容を発表します。最初は 3 分で行っていましたが、タイムマネジメントを意識することで参加者が短く端的に話すことができるようになり、今は 1 人約 1 分 30 秒ほどで発表をしています。
グルーピング（収束）
メンバーが KPT の内容について発表している間に、書記がグルーピングを同時進行します。近いトピックで箇条書きにし、前後関係や親子関係がある場合は箇条書きのブロックを移動させて構造化します。参加者の全員が発表した後、グルーピングしたどの内容について議論するか投票をします。
発表内容をトピックスにまとめて、投票し、議論するトピックを決める
投票結果から 2 - 3 程選び、良かった内容の深堀りや課題の改善について議論します。このやり方にすることでグルーピングの時間が削減され、投票も効率化し、5 分程度の余裕が生まれました。
深堀する KPT 対象を選択した後、いよいよ議論が始まります。この時ファシリテーターは常にゴールに到達することを意識するため、次のようなことを考えます。
ファシリテーターは質問や傾聴などといった対話に関するファシリテーションのスキルを使って議論を手助けします。例えば情報が足りていなければ発言を促し、まとめるために具体化が必要であれば問いかけて収束を試みます。タイムマネジメントを行い、適切なタイミングでクロージングを行います。
Next Try が決定したら、KPT ボードにあらためて記載をします。KPT ボードには Next Try プロパティを設けており、これをフィルタして掲示する DB View を KPT ボードの前に設置しています。
次のレトロの KPT ワーク直前に Try の進捗確認する
次回の KPT ワークの直前にこの DB View を確認し、進捗の確認します。
当初行っていた Miro レトロと、改善後の Notion レトロの全体像は次になります。
改善後、議論の時間は 1 議題につき約 5 分程だったのが 10 分ほどに倍増しました。改善前と比べて、やることが増えているにも関わらず議論の時間も増えています。これには次の観点があります。
改善前は参加者が十分な数の KPT が出るまで記載時間の延長をしていたため、終了時刻が安定せず、後の時間に影響が出やすい状態でした。改善後は時間内に十分な数の KPT が出るようになりました。現在では 5 分間 5 - 6 人の参加者で毎回約 50 程の KPT が記載されるようになりました。
多くの KPT があり、十分に発散されている状態から議論することで局所的な議論に陥ることが防げます。そして、これだけ議論に使えるの時間があると 3 議題を扱う場合もあります。これにより Next Try が量産され、改善のスピードが向上していることを感じます。
Next Try が追跡できており、改善活動の進捗を定期的に確認できるようになりました。
Next Try の進捗確認
議論の質が上がったかどうかの判断は難しいですが、他チームからレトロの成果物を評価されることがありました。改善後のレトロで議論した Problem をオーバーオールレトロにエスカレーションし、その内容について好意的なコメントを貰っています。
オーバーオールレトロに挙げた Problem に対するコメント（タコスは感謝を表現してます）
また、レトロの改善をはじめてからすぐに、他のチームからの見学者希望者を招くことがありました。見学後、レトロ DB を使ったテンプレートの横展開が発生し、レトロ改善の動きが他のチームにも生まれています。この自立性と柔軟さはログラスの組織力の強さだとあらためて感じました。
質・量共に良い Next Try が出ることでスプリントの改善速度が向上しました。それはレトロ自体にも当てはまります。現在は次の改善に取り組んでおり、その一部も紹介します。
「レトロのレトロ」という項目をレトロのテンプレートの末尾に追加しました。これはレトロの後、非同期でレトロ自体に対するフィードバックをするものです。改善はファシリテーションにとってとても重要な要素です。チーム活動の質を向上させるため、レトロのような定期的な活動は常に改善していくのが理想的です。
テンプレートの末尾に追加したレトロのレトロ
改善点がある場合はレトロのテンプレートを編集することで、次回のレトロ進行に即反映できます。実験的に試せる改善のループを高速に回しています。
ログラスでは Four Keys を初めとした生産性指標の監視をはじめました。レトロでもこの指標を KPT ワーク前に確認しています。チームの傾向を監視することで新たな改善の気付きにしたい狙いがあります。
Findy Team+ のサイクルタイム分析を用いた生産性指標のレビュー
ファシリテーションについて、私への属人化が発生しているのは健全でありません。議事設計やテンプレートだけでは無く、ファシリテーターとしてのテクニックなども含めた内容をレクチャーする機会を作っています。
ファシリテーターはチームに 1 人だけいれば良いというわけではありません。参加者全員がファシリテーターとしてのスキルが高いと、議論の質が驚くほど高くなることを私は身をもって体験したことがあります。組織のファシリテーション力を上げることは全てのチーム活動の向上に繋がります。
ログラスでは 10 分勉強会という文化があり、こちらでファシリテーションの基礎について話しました。今回の改善でも用いたファシリテーションのプロセス設計の内容が主になります。
勉強会中の様子（10 分勉強会）
研修でもない限り、体系的にファシリテーションを学ぶ機会は無いということに私も気付かされました。ファシリテーション能力がすでにある人でもこれまでの経験の中で独学している人が多く、基礎的な内容でもとても盛り上がりました。
さらにチームでは質問入門というタイトルの勉強会を行いました。
議論に入ると、私はファシリテーションのテクニックを活用しています。参加者の発言を促し、意見を傾聴し、対話の中で効果的な問いかけを行い、ゴールへ伴走するのがファシリテーターの役割の 1 つです。
このようなテクニックを身に付けるには、テクニックの概要を理解し、実際にファシリテーターとして実践してみることが大事です。勉強会ではレトロで私が特に活用している問いのテクニックについて解説しました。
勉強会中の様子（質問入門）
クローズドクエスチョンやオープンクエスチョンなどの基本的なテクニックの解説の後、簡単なワークを行いました。普段のコミュニケーションでも質問の仕方を意識することで、発言を容易にしたり、より多くの情報を引き出したりすることが出来ます。
この勉強会の後、参加者からレトロのファシリテーターの後任を選出して「レトロのレトロ」でフィードバックしています。
ふりかえり（スプリント・レトロスペクティブ）のプロセスを見直し、結果的に議論の時間が 2 倍になり、成果が向上した取り組みについて説明しました。非同期作業を多く取り入れ、事前情報の共有を十分に行うことがこの改善の肝となる観点です。
ログラスはもともとファシリテーションに関するリテラシーが組織的にとても高いと感じていました。そんな文化を象徴するナイスファシリという Slack 絵文字があります。
これまでいくつかの組織でファシリテーション改善の取り組みをしてきましたが、この短期間でここまで実感できる成果がでるのは初めての経験でした。全員がファシリテーションに対する感度が高く、改善意欲が高いためだと思っています。こういった改善活動が楽しんでやれている側面もあり、推進している身としてとても気持ちよく取り組めました。
レトロ中の様子、結構わいわいやってます
また、今回の記事は同アドベントカレンダーの 4 日目の村本さんの記事にあるスクラムイベントのオーナー運用の一環です。スクラム全体の運用改善に興味があればこちらも見てください！
明日、株式会社ログラス Product チーム Advent Calendar 2022 の 18 日目は小林さん（@mako_makok）による「なんとなく使わないGradle」です。お楽しみに！
脚注
/assets/images/4211756/original/b3831c9b-59a3-4da4-87f8-2867f9798924?1572278245)
/assets/images/4211756/original/b3831c9b-59a3-4da4-87f8-2867f9798924?1572278245)
/assets/images/4211756/original/b3831c9b-59a3-4da4-87f8-2867f9798924?1572278245)
/assets/images/11406098/original/b3831c9b-59a3-4da4-87f8-2867f9798924?1670294802)