2022 年 7 月から株式会社ログラスに業務委託として関わっている近藤です。
ログラスではスクラムによる開発体制を採用しています。この数ヶ月でスクラムイベントの 1 つであるスプリント・レトロスペクティブ（ふりかえり）の改善に取り組みました。この記事では主に次の対象者向けに、改善した内容について紹介します。
- スクラムに取り組んでいる人
- ふりかえりのやり方、効果に悩んでいて、改善したい人
- ファシリテーションに興味がある人
※ 以下、記事中ではレトロスペクティブのことを省略してレトロと呼びます。
経緯
改善前、レトロでは Miro を使った KPT[1] を次の流れで行っていました。
- スプリントで完了したチケットの確認（Jira の Backlog 確認）
- KPT 作成の非同期ワーク[2]（以下、KPT ワークと呼びます）
- 各参加者が KPT 内容を発表
- 付箋のグルーピング
- Try についての議論
ファシリテーターは直前にランダムで決めていました。参加者・ファシリテーターとして何度か参加した後、とあるレトロの場で私は次のような Problem と Try を出しました。
きっかけとなった Problem と Try の付箋
- Miro の操作でロスしている時間が多く、議論の時間が少ない（議論の質が上げられない）
- 過去の KPT（付箋の内容）を構造化して記録できていない（検索・参照できない）
- 過去の Try のレビューができていない（Try の追跡・完了の確認ができていない）
私にファシリテーターの経験があることもあり、この Try を機にチームのレトロ改善に取り組みました 💪
取り組んだこと
目的の確認と目標の設定
まず、あらためてスクラムガイドを確認し、チームとしてのレトロの目的を再定義しました。
スクラムガイド抜粋
スプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することである。
スクラムチームは、個⼈、相互作⽤、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発⽣したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。スクラムチームは、⾃分たちの効果を改善するために最も役⽴つ変更を特定する。最も影響の⼤きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加することもできる。
スプリントレトロスペクティブをもってスプリントは終了する。スプリントが 1 か⽉の場合、スプリントレトロスペクティブは最⼤ 3 時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。
目的
スプリントレトロスペクティブの目的は、スプリント内で行ったプロセスを振り返り、議論、共有することで次スプリントの品質や効果を高めること
そして、目的にあわせてレトロの目標（ゴール）を次のように定めました。
目標（ゴール）
- 次回以降のスプリント品質を向上させる Next Try が決まっている
- チーム、部署間の課題をオーバーオールレトロにエスカレーションする
短い時間で成果を出すためには、参加者が一丸となってゴールへ走り抜けるのが必要になります。参加者間で「なんでレトロをやるか」「何のための Next Try か」の認識を合わせることは重要です。
また、レトロでは時折チームで解決できない問題が課題として挙がることがあります。ログラスでは複数のチームがスクラムを行っており、LeSS を取り入れたオーバーオールレトロスペクティブを実施しています。チームで解決できる課題か、そうでないかについても議論することにしました。
課題と制約の整理
目的を整理したところで、改善（課題）点について整理します。先述した課題も鑑みて、次の内容について改善しようと考えました。
- 次スプリントの品質や効果を高める Try を出すために、議論の質を向上する
- Next Try を追跡し、完了しているか定期的に確認をする
- 議論の履歴を残し、検索・参照可能にする
特に議論の質については具体的に次のことを改善点としました。
- 非同期ワーク（KPT）を効率化する
- 各参加者の意見の発散を促進する（KPT の量を増やす）
- 意見の構造化（グルーピング）を高速にする
- Next Try を決める議論の時間を増やす
改善点を明確にしたところで、次に制約についても考えました。議論の質を上げられない原因が仮に議論時間の不十分である場合、単純にレトロの時間を増やせば良いです。しかし実際は参加者のスケジュールの確保が難しいなどあり、そう都合良くはいきません。
ログラスではスプリント期間を 1 週間に設定し、レトロの時間（タイムボックス）を 50 分[3]としています。この設定は不変としました。そのため、50 分間で質の高い Next Try を生み出すため工夫を凝らす必要があります。
Notion 化
「非同期ワーク（KPT）を効率化する」、「議論の履歴を残し、検索可能にする」という観点から、まず見直したのは Miro を使ったワークでした。レトロ自体は十分に機能していたのですが、付箋の操作に時間を要したり、KPT の管理が難しいという課題がありました。
これまでのレトロで利用していた Miro のボード
⚠️ Miro に関する補足
補足をしておくと、Miro を使った KPT がダメなわけではありません。
KJ 法[4]を代表する付箋を用いたワークは優秀なブレインストーミングです。今回は制限時間が短いこともあり、付箋操作を初めとしたゴールを目指すことに対する本質的では無い操作を極力省き、よりワークに集中することを目指しました。時間が十分にあり、参加者の発想や気付きを促すことが重要になる場合は、視覚情報に強くアプローチできる Miro が適切だと考えます。
これまでのレトロでは特に Miro の諸操作に時間がかかっており、まとまった時間として見えにくいタイムロスが発生していました。また、ファシリテーターや参加者の Miro 習熟度によっても進行の円滑さに差が出やすく、別の方法を探すことにしました。
今回はレトロを Notion 化することを選択しました。ログラスでは Notion を普段から活用しており、メンバーは操作に十分習熟しています。レトロ DB を作ることでテンプレート化もでき、準備にかかるコストも少なくできます。
レトロ を管理している Notion DB
後述する議事設計では、順序立てられた議事次第を進めることでレトロが進行する設計にしています。誰でもテンプレートに沿うことでレトロを運用できるようにすることは、ファシリテーションの属人化を防ぐ観点からも有用です。
議事次第に沿って作られた Notion テンプレート（スクリーンショットが大きいので閉じています）
議事次第に沿って作られた Notion テンプレート（個々の議事については後述）
議事設計
ファシリテーションにはチーム活動を共有、発散、収束、決定という 4 つのプロセスに分けて設計する方法論[5]があります。このプロセスを参考にレトロを再設計をしました。
上記の中から、次の内容について説明していきます。
- 目的・ゴールの掲示（共有）
- 出来事の掲示（共有）
- 非同期作業の設計
- KPT ワーク（発散）
- グルーピング（収束）
- 議論・まとめ（決定）
- Try の追跡（共有）
目的・ゴールの掲示（共有）
チーム活動では、参加者が協力してゴールを達成していく雰囲気が重要です。冒頭で参加者が集まる目的と達成すべきゴールの認識を必ず合わせます。他にも時間などのゴールを達成するために必要な情報を共有することが大事です。
レトロのテンプレートの冒頭に先述した目的、ゴールを記載しました。
レトロのテンプレートの冒頭
出来事の掲示（共有）
Notion 化した直後、数人の参加者の KPT が Miro と比べて減少しました[6]。対象の参加者にヒアリングしたところ、スプリントでの出来事が思い出せないという意見がありました。1 週間のスプリントとはいえ、40 時間分の活動のふりかえりになり、思い出せないのも無理のないことです。これまでは他の参加者の KPT を見て思い出し、記載時間を延長するなどしていたため十分な KPT の数が確保できていたと予想しています。
この対策として非同期作業（KPT）を始める前に、スプリントで発生した出来事を共有することにしました。
スプリント中の出来事を掲示、挙げてみると結構ある
ここに記載する内容はレトロ開始の数時間前に参加者に対して、今スプリントで何があったかを Slack で募集します。KPT ワーク中はこちらの一覧を画面共有しています。
実は KPT が減少した参加者全員が別のチームに移動してしまったため[7]、課題に対する改善効果の計測ができていません。ただ、この改善によってよりユニバーサルなレトロになったという実感があります。
非同期作業の設計
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 を決めるために足りていない情報・論点は何か
- 誰・何が Next Try において重要か
- 議論の中で具体的になっていないことは何か
- 議論が脱線していないか
ファシリテーターは質問や傾聴などといった対話に関するファシリテーションのスキルを使って議論を手助けします。例えば情報が足りていなければ発言を促し、まとめるために具体化が必要であれば問いかけて収束を試みます。タイムマネジメントを行い、適切なタイミングでクロージングを行います。
Try の追跡（共有）
Next Try が決定したら、KPT ボードにあらためて記載をします。KPT ボードには Next Try プロパティを設けており、これをフィルタして掲示する DB View を KPT ボードの前に設置しています。
次のレトロの KPT ワーク直前に Try の進捗確認する
次回の KPT ワークの直前にこの DB View を確認し、進捗の確認します。
改善前後の全体像
当初行っていた Miro レトロと、改善後の Notion レトロの全体像は次になります。
改善後、議論の時間は 1 議題につき約 5 分程だったのが 10 分ほどに倍増しました。改善前と比べて、やることが増えているにも関わらず議論の時間も増えています。これには次の観点があります。
- ふりかえりに必要な情報を事前共有することで、KPT の量・質・時間効率が向上した
- KPT 発表中に書記がグルーピングすることで選択・議論に迅速に移行できるようになった
- 時間を意識し、付箋の操作などを省略することでタイムロスを改善できた
改善前は参加者が十分な数の 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 絵文字があります。
ナイスなファシリテーターに贈られる Emoji
これまでいくつかの組織でファシリテーション改善の取り組みをしてきましたが、この短期間でここまで実感できる成果がでるのは初めての経験でした。全員がファシリテーションに対する感度が高く、改善意欲が高いためだと思っています。こういった改善活動が楽しんでやれている側面もあり、推進している身としてとても気持ちよく取り組めました。
レトロ中の様子、結構わいわいやってます
また、今回の記事は同アドベントカレンダーの 4 日目の村本さんの記事にあるスクラムイベントのオーナー運用の一環です。スクラム全体の運用改善に興味があればこちらも見てください！
アドカレ的な締め
明日、株式会社ログラス Product チーム Advent Calendar 2022 の 18 日目は小林さん（@mako_makok）による「なんとなく使わない Gradle」です。お楽しみに！
参考文献
-
【徹底解説】正しい「KPT」が仕事の成果を生み出す！進め方のコツ、現場の事例を紹介 | SELECK [セレック] ↩︎
-
本来の KPT では Keep、Probrem、Try をそれぞれ時間を区切って記載しますが、時間短縮のため一度に記載しています。 ↩︎
-
スプリント期間が 1 週間の場合、キャパシティを考慮するとレトロスペクティブは 1 時間以内に設定することが良いため（参考） ↩︎
-
減少の理由については他にも仮説を立てていました。対象の参加者は特に Miro での操作に習熟している参加者だったので、Notion 化による弊害が出ていたのいう内容です。とはいえ普段の業務は Notion 上で問題無く利用できているため、基本的には回数を重ね慣れていくと期待していました。 ↩︎
-
7 名のチームだったんですが、新チームが発足されるにあたり 2 名が移動して 5 名になりました。はてブで指摘があったんですが、単純に組織拡大の影響で闇とかは無いです！ ↩︎
株式会社ログラスは「良い景気を作ろう。」をミッションに、企業経営を推進する次世代型経営管理クラウド「Loglass 経営管理」を開発し提供しています。
Discussion