Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
大人数会議のカオス化を防ぐふりかえりフレームワークを考えてみた
Search
sara.ohtani.mt2
December 27, 2024
Business
0
380
大人数会議のカオス化を防ぐふりかえりフレームワークを考えてみた
15人以上で1年規模のプロジェクトのふりかえりを1時間でしよう!!!!!!
sara.ohtani.mt2
December 27, 2024
Tweet
Share
More Decks by sara.ohtani.mt2
See All by sara.ohtani.mt2
【供養】DynamoDBでも部分一致検索したかった
smatsu
1
930
サンプル発話からVUXを考える
smatsu
0
95
Other Decks in Business
See All in Business
GMOフィナンシャルHD 会社紹介資料
gmofh_hr_team
0
50k
社会の中のわたしの技術 ─ 自分の地図の描き方 #wttjp
yotii23
0
250
Morght 会社紹介資料_LAST UPDATED 2025.7
morght
1
3.6k
株式会社カウシェ Company Deck
kauche
2
200k
ソリューションデザイナの紹介
laboroai2016
0
280
How to use ‘Economies of Empowerment’ to get the benefits of both speed and scale - AgileAus 2025
matthewskelton
PRO
0
180
AIUX is Agentic UX
kan
0
280
Arches 会社説明資料/ HR Deck
arches0501
0
13k
セーフィー株式会社(Safie Inc.) 会社紹介資料
safie_recruit
6
350k
アウトカムファーストな専門技術組織の構築と運用のための取り組み / Efforts to Build and Operate an Outcome-First Technical Expertise Organization
lycorptech_jp
PRO
3
360
国内ランサムウェア3事例から学ぶ中小病院におけるサイバーセキュリティ対策 / Cybersecurity Learned from Cases
henryofficial
0
160
メモ帳マニュアル
takamiyata
0
210
Featured
See All Featured
Documentation Writing (for coders)
carmenintech
72
4.9k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
The World Runs on Bad Software
bkeepers
PRO
69
11k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
The Pragmatic Product Professional
lauravandoore
35
6.7k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Rebuilding a faster, lazier Slack
samanthasiow
82
9.1k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Producing Creativity
orderedlist
PRO
346
40k
Six Lessons from altMBA
skipperchong
28
3.9k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Transcript
大人数会議のカオス化を防ぐ 振り返りフレームワークを考えてみた 大谷 紗良
期間:キックオフからは約1年、開発期間は約半年 規模:主な開発チームだけでも2チーム、デザイナー・QA・PdM含めて15人くらい この体制での開発は一旦一区切り 今後また複数チームで開発するプロジェクトがあったときに活かせる振り返りがしたい プロジェクトの振り返りをしよう
しかしざっと 15人もいる 大人数会議あるある 話が発散しすぎる 発言してない人が 出がち 議論する時間が 取れない 前提情報の共有状況 のばらつき
今後もこの体制で開発するなら思い切って半日くらいかけるのもいいけど・・・ みんなもう次の開発に入っているし1時間くらいである程度コンパクトにやりたい
前提情報の共有状況のばらつき問題 1年前のことなんて覚えてない プロジェクト参加タイミングも参加者によって異なる
主要なイベントは先に書いておく 短めの制限時間内にどんな小さなことでもいいのでみんなで書く → ハードル低めのタスクを短時間に集中してやる時間でアイスブレイクを兼ねる 「タイムライン」をアイスブレイクとして用意する 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. 一言タイム
• 観点を絞ったおかげで話が発散しすぎた感触はなかった • グルーピングしながら話すと意見の差分に焦点をあてて話せるのも効率的 • みんなで振り返りの振り返りを簡単でいいからやれたらよかった ◦ 時間がなくて諦めてしまったけどぱっと5段階評価つけてもらうだけでも 振り返りの振り返り
参考 • アジャイルサムライ 四天王 • アジャイルなチームをつくる ふりかえりガイドブック • おまけ:時間があればおすすめしたい、じっくり振り返れるフレームワーク ◦ LIFULLでふりかえりにLDJ(Lightning
Decision Jam)を使ったら良いことしかなかった話し。
Thank you!