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
チームの立て直し施策をGoogleの 『効果的なチーム』と見比べてみた
Search
Mitsui
January 06, 2025
Programming
0
1.8k
チームの立て直し施策をGoogleの 『効果的なチーム』と見比べてみた
Mitsui
January 06, 2025
Tweet
Share
More Decks by Mitsui
See All by Mitsui
チームのアジャイルな活動
maroon8021
0
110
Valueを使ったふりかえりをやってみた
maroon8021
0
120
TypeScript でつくるフルスタック環境の紹介
maroon8021
2
990
Other Decks in Programming
See All in Programming
Memory API : Patterns, Performance et Cas d'Utilisation
josepaumard
0
140
新しいPHP拡張モジュールインストール方法「PHP Installer for Extensions (PIE)」を使ってみよう!
cocoeyes02
0
400
監視 やばい
syossan27
10
9.6k
State of Namespace
tagomoris
4
1.8k
DataStoreをテストする
mkeeda
0
290
Do Dumb Things
mitsuhiko
0
440
リストビュー画面UX改善の振り返り
splcywolf
0
150
AIコーディングエージェントを 「使いこなす」ための実践知と現在地 in ログラス / How to Use AI Coding Agent in Loglass
rkaga
3
470
The Nature of Complexity in John Ousterhout’s Philosophy of Software Design
philipschwarz
PRO
0
120
AWS で実現する安全な AI エージェントの作り方 〜 Bedrock Engineer の実装例を添えて 〜 / how-to-build-secure-ai-agents
gawa
8
830
Vibe Codingをせずに Clineを使っている
watany
17
6.3k
RuboCop: Modularity and AST Insights
koic
2
1.4k
Featured
See All Featured
Fireside Chat
paigeccino
37
3.4k
Speed Design
sergeychernyshev
29
900
Become a Pro
speakerdeck
PRO
27
5.3k
It's Worth the Effort
3n
184
28k
Rebuilding a faster, lazier Slack
samanthasiow
80
8.9k
Adopting Sorbet at Scale
ufuk
76
9.3k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.4k
Docker and Python
trallard
44
3.3k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
13
680
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
5
550
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
30k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Transcript
チームの立て直し施策をGoogleの 『効果的なチーム』と見比べてみた Tatsuhiko Mitsui
この資料の内容 ❏ チームがあまりよろしくない状態だったのをここ最近までに立て直したの で、どういうことを実践したか ❏ その実践したことをGoogleの「効果的なチーム」と比較し、どういった要素 を満たしていたのかを確認する ❏ ※2024/12時点の内容です
そもそもチームの立ち直しとは?
運悪く一時的にやばい状況になってました!!! ベテランの離脱 人の異動 予定されていた チーム分割
人の入れ替わり(エンジニアonly) ここが一番しんどかった
課題感 ❏ チームが未成熟 ❏ メンバーとしても入りたての人が多くオンボーディングがまだまだ ❏ チームとしての「型」もほぼ0から作り直し ❏ ドメインとソースコードが複雑かつ膨大で1つの課題をやりきるのにも大変 ❏
ちょっとした実装ミスがインシデントにつながったり、思わぬところに飛び火する ❏ 現時点である程度全体像掴むのに半年近くかかり、一人前になるのに1年くらいかかってしま う
施策の紹介
やったこと ❏ アジャイルっぽくした ❏ 「相談会」という枠を用意した ❏ みんなで仕様のドキュメント化(今回は割愛)
スクラム アジャイルっぽくした ❏ Before ❏ PdMがタスクを用意し、それを手が空いてるエンジニアが受け取り実装する状態 ❏ チーム内受託みたいになっていた、お互いに助け合うモチベーションがわかない構図 ❏ After
❏ 明確にスプリントのタイムボックスを設けた ❏ プランニングを実施するようにし、「そのスプリント内での優先度」を明確にするようにし た ❏ チーム内のWIP制限としてまずは1〜2とした
「相談会」という枠を用意した ❏ 毎日14:00~15:00、チームのエンジニアが必ずmeetに集合する時間 ❏ 困りごとをシェアして解決するようにしたり、モブプロしたりする ❏ ※ネタがぱっと思いつかなくても誰かの実装物をモブプロしたり、PRレ ビューしたりなど必ずワイワイするようにしました
「意識したこと」から見てみると
個人的にチームを立て直すときに意識したこと ❏ やばいチームだという空気が作られると本当に取り返しがつかなくなるので 「必ずなにかは進んでる、終わった」という状態を作る(←アジャイル化) ❏ 「前に進んでいる」という実感を内外で得る ❏ みんなで進める、困っていたらみんなで解決する(←相談会) ❏ そのとき「チームで出せるベスト」をちゃんと尽くす
❏ 困ること、うまくいかないことだらけなのでその困難は「あなたのせいじゃないよ」という 雰囲気にし、気軽に課題感をシェアしてもらうようにする ❏ 孤独や無力感を感じさせないようにする。
ではここでGoogleの「効果的なチーム」について 見てみましょう
https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness#introduction
チームの効果性に影響する因子 ❏ 心理的安全性 ❏ 相互信頼 ❏ 構造と明確さ ❏ 仕事の意味 ❏
インパクト
心理的安全性 > 心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネ ガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。心理的安全 性の高いチームのメンバーは、他のメンバーに対してリスクを取ることに不安を感じていません。自分の過ちを認めたり、質問をした り、新しいアイデアを披露したりしても、誰も自分を馬鹿にしたり罰したりしないと信じられる余地があります。 ❏ 当初から「みんなでやるのが当たり前」という空気を作り、そもそも相互に コミュニケーションしないと成り立たないようにしたので聞く、フィード バックするというのが自然にできるようになった
❏ 「困ったら相談会で聞く、解決する」という文化を作れたので新しい方が入 られてもワイワイするのが普通、気軽に聞いていい状態にできている
相互信頼 > 相互信頼の高いチームのメンバーは、クオリティの高い仕事を時間内に仕上げます(これに対し、相互信頼の低いチームのメン バーは責任を転嫁します)。 ❏ 信頼と呼べるものは相互理解と実績によって積み上がるものなのかと思いま す ❏ モブプロや共同の作業を通じてお互いを把握することや、貢献を認識できま す
❏ そもそも「みんなで進む」ということを主軸に置くことによって責任転嫁や 無関心な状態を減らしてこれました
構造と明確さ > 効果的なチームをつくるには、職務上で要求されていること、その要求を満たすためのプロセス、そしてメンバーの行動がもたら す成果について、個々のメンバーが理解していることが重要となります。目標は、個人レベルで設定することもグループレベルで設 定することもできますが、具体的で取り組みがいがあり、なおかつ達成可能な内容でなければなりません。Google では、短期的な 目標と長期的な目標を設定してメンバーに周知するために、「目標と成果指標(OKR)」という手法が広く使われています。。 ❏ 計画や(短期の)目標などはアジャイル化によって実現できたかと思っていま す
❏ チームとしてしっかり目標を目指すというところは今後の課題
仕事の意味 / インパクト > チームの効果性を向上するためには、仕事そのもの、またはその成果に対して目的意識を感じられる必要があります。仕事の意 味は属人的なものであり、経済的な安定を得る、家族を支える、チームの成功を助ける、自己表現するなど、人によってさまざまで す。 > 自分の仕事には意義があるとメンバーが主観的に思えるかどうかは、チームにとって重要なことです。個人の仕事が組織の目標 達成に貢献していることを可視化すると、個人の仕事のインパクトを把握しやすくなります。
❏ 個々人の仕事の意味/意義やそれらの組織や社会に対するインパクトについて はまだまだ改善の余地があるなと思います(※やっと最近ここの目を向けるこ とができるようになってきた)
チームの現状 ← だいぶ担保できている ← 突き詰めていきたい ※チームの成熟度を表すわけではありません
改めてどうしていたのかをふりかえる
ふりかえり ❏ どういうことをしていたのか ❏ みんなで協力しながら一歩ずつゴールに向かって進んでいくチームを作っていた ❏ 結果どうだったか ❏ 「みんなで協力」と「ゴールに向かって進む」という点では「効果的なチーム」の要素と似 たようなことが出来ていたと思う
❏ 結果としていいチームはある程度作れたと思う ❏ 結構困難な局面もあった中、チーム一丸となって進んでこれた
その他雑感 ❏ 「みんなで協力」という文化ははじめに作らないとあとからはだいぶ難しい と思う(今までの経験も踏まえ) ❏ コミュニケーションの場の作り方はどんな方法でもよいと思うが、個人的に はmeet/zoomで顔を出すようにして、多少冗長でも積極的に同期でコミュニ ケーションをしたほうがよいと思っている ❏ 個人的に単純接触効果や自己開示や共感による関係性向上の影響は大きいと思う
❏ GatherやDiscordなどの音声onlyのつながり方だと結構人を選んだり、ベースとなる関係性 が大事になってくる気がしている ❏ もちろん対面でもよい
「相談会」は本当に効果的なのか① ❏ エンジニアには一定「集中して作業に取り組む時間」はあったほうがよい ❏ ただしそれでプロダクトが効果的に成長するのはチームや個々人がとても成 熟している必要があると思う ❏ 成熟度が低い人とのコミュニケーションやチームの状態だと、その集中して 取り組む時間≒フィードバックサイクルの無い時間が長くなり、その分手戻 りが多くなったり、タスクが完了するまでのリードタイムは長くなり、生産
性があまり高くなく、ナレッジのシェアなどもあまり活発にならなくなる可 能性があると思います ❏ →そういう意味ではチームが未成熟の場合にはこの相談会や枠を必ず決めて 集まって同期する場があることは効果的だと思います
❏ 一方でチームが成熟していたり、不確実性が低く、すばやく手を動かせる場 合は相談会といった施策は不向きかもしれません ❏ また別の観点でいくと、そもそも固定のMTG枠などを取らずともGatherや Discordなどに常駐してすばやくやり取りができるチーム体制、関係性が気 づけていると不要になるかもしれません ❏ ただし、このコミュニケーションスタイルは人数が増減、変更されたときに維持できるか怪 しいので、普遍性のある仕組みに落とし込めたらよいのかなと思います
「相談会」は本当に効果的なのか②
おしまい