大人数会議のカオス化を防ぐ 振り返りフレームワークを考えてみた 大谷 紗良

期間：キックオフからは約１年、開発期間は約半年 規模：主な開発チームだけでも２チーム、デザイナー・QA・PdM含めて15人くらい この体制での開発は一旦一区切り 今後また複数チームで開発するプロジェクトがあったときに活かせる振り返りがしたい プロジェクトの振り返りをしよう

しかしざっと 15人もいる 大人数会議あるある 話が発散しすぎる 発言してない人が 出がち 議論する時間が 取れない 前提情報の共有状況 のばらつき 今後もこの体制で開発するなら思い切って半日くらいかけるのもいいけど・・・ みんなもう次の開発に入っているし１時間くらいである程度コンパクトにやりたい

前提情報の共有状況のばらつき問題 １年前のことなんて覚えてない プロジェクト参加タイミングも参加者によって異なる

主要なイベントは先に書いておく 短めの制限時間内にどんな小さなことでもいいのでみんなで書く → ハードル低めのタスクを短時間に集中してやる時間でアイスブレイクを兼ねる 「タイムライン」をアイスブレイクとして用意する 20yy/ mm キック オフ 20yy/ mm 開発 開始 20yy/ mm リリー ス xxx xxx xxx xxx xxx

話が発散しすぎる問題 期待している状態とのギャップを洗い出したいが 参加者ごとに期待する内容や対象が大きく異なると 議論が発散しすぎてしまうのではないか

今回の振り返りで焦点を当て、深掘りしたいポイント ● プロジェクトが成功だったのか ● 成功要因 ● 失敗要因 ● 次に活かせるアクション

プロジェクトの成否の観点とは 四天王ですよねぇ！ 出典『アジャイルサムライ』（ Jonathan Rasmusson 著）

中心に四天王を置く

観点ごとに気づきを書き出す ● Good ● Bad ● チャレンジ ● 予想外 ● リスク ● そぼぎ ● etc… XX でよかっ た よかった つらかっ た

気づきを起点に要因を深掘りし、アクションに落とし込む 「なぜXXを実現できたのか」を確認して KeepとTryの形に落とし込み XX でよかっ た よかった つらかっ た ● Good ● Bad ● チャレンジ ● 予想外 ● リスク ● そぼぎ ● etc…

順番に話を聞くと時間がかかるけど 自由に話していると発言していない人が出がち 発言してない人が出がち問題

付箋は話しながらグルーピング A A' A+ 進行役だけでなく参加者自身にもグルーピングしてもらう 付箋に名前を書いてもらうと話をふりやすい、グルーピングがあっているか確認しやすい グルーピングしながら自然な流れで会話できる

付箋の内容を集約しつつ進行すると時間短縮はできるが 付箋を書いていない人を取りこぼしてしまいがち 今回は一言コメントを順番に聞く時間を最後にとった 感謝タイムでもある 議論パートと別に順番に話を聞くパートを用意する

まとめ 今回行った振り返りの流れ 1. タイムライン 2. 四天王KPT 3. 一言タイム

● 観点を絞ったおかげで話が発散しすぎた感触はなかった ● グルーピングしながら話すと意見の差分に焦点をあてて話せるのも効率的 ● みんなで振り返りの振り返りを簡単でいいからやれたらよかった ○ 時間がなくて諦めてしまったけどぱっと５段階評価つけてもらうだけでも 振り返りの振り返り

参考 ● アジャイルサムライ　四天王 ● アジャイルなチームをつくる ふりかえりガイドブック ● おまけ：時間があればおすすめしたい、じっくり振り返れるフレームワーク ○ LIFULLでふりかえりにLDJ（Lightning Decision Jam）を使ったら良いことしかなかった話し。

Thank you!