チームの立て直し施策をGoogleの 『効果的なチーム』と見比べてみた

Transcript

1. チームの立て直し施策をGoogleの 『効果的なチーム』と見比べてみた Tatsuhiko Mitsui
2. この資料の内容 ❏ チームがあまりよろしくない状態だったのをここ最近までに立て直したの で、どういうことを実践したか ❏ その実践したことをGoogleの「効果的なチーム」と比較し、どういった要素 を満たしていたのかを確認する ❏ ※2024/12時点の内容です
3. そもそもチームの立ち直しとは？
4. 運悪く一時的にやばい状況になってました！！！ ベテランの離脱 人の異動 予定されていた チーム分割
5. 人の入れ替わり(エンジニアonly) ここが一番しんどかった
6. 課題感 ❏ チームが未成熟 ❏ メンバーとしても入りたての人が多くオンボーディングがまだまだ ❏ チームとしての「型」もほぼ0から作り直し ❏ ドメインとソースコードが複雑かつ膨大で1つの課題をやりきるのにも大変 ❏ ちょっとした実装ミスがインシデントにつながったり、思わぬところに飛び火する ❏ 現時点である程度全体像掴むのに半年近くかかり、一人前になるのに1年くらいかかってしま う
7. 施策の紹介
8. やったこと ❏ アジャイルっぽくした ❏ 「相談会」という枠を用意した ❏ みんなで仕様のドキュメント化(今回は割愛)
9. スクラム アジャイルっぽくした ❏ Before ❏ PdMがタスクを用意し、それを手が空いてるエンジニアが受け取り実装する状態 ❏ チーム内受託みたいになっていた、お互いに助け合うモチベーションがわかない構図 ❏ After ❏ 明確にスプリントのタイムボックスを設けた ❏ プランニングを実施するようにし、「そのスプリント内での優先度」を明確にするようにし た ❏ チーム内のWIP制限としてまずは1〜2とした
10. 「相談会」という枠を用意した ❏ 毎日14:00~15:00、チームのエンジニアが必ずmeetに集合する時間 ❏ 困りごとをシェアして解決するようにしたり、モブプロしたりする ❏ ※ネタがぱっと思いつかなくても誰かの実装物をモブプロしたり、PRレ ビューしたりなど必ずワイワイするようにしました
11. 「意識したこと」から見てみると
12. 個人的にチームを立て直すときに意識したこと ❏ やばいチームだという空気が作られると本当に取り返しがつかなくなるので 「必ずなにかは進んでる、終わった」という状態を作る(←アジャイル化) ❏ 「前に進んでいる」という実感を内外で得る ❏ みんなで進める、困っていたらみんなで解決する(←相談会) ❏ そのとき「チームで出せるベスト」をちゃんと尽くす ❏ 困ること、うまくいかないことだらけなのでその困難は「あなたのせいじゃないよ」という 雰囲気にし、気軽に課題感をシェアしてもらうようにする ❏ 孤独や無力感を感じさせないようにする。
13. ではここでGoogleの「効果的なチーム」について 見てみましょう
14. https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness#introduction
15. チームの効果性に影響する因子 ❏ 心理的安全性 ❏ 相互信頼 ❏ 構造と明確さ ❏ 仕事の意味 ❏ インパクト
16. 心理的安全性 > 心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネ ガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。心理的安全 性の高いチームのメンバーは、他のメンバーに対してリスクを取ることに不安を感じていません。自分の過ちを認めたり、質問をした り、新しいアイデアを披露したりしても、誰も自分を馬鹿にしたり罰したりしないと信じられる余地があります。 ❏ 当初から「みんなでやるのが当たり前」という空気を作り、そもそも相互に コミュニケーションしないと成り立たないようにしたので聞く、フィード バックするというのが自然にできるようになった ❏ 「困ったら相談会で聞く、解決する」という文化を作れたので新しい方が入 られてもワイワイするのが普通、気軽に聞いていい状態にできている
17. 相互信頼 > 相互信頼の高いチームのメンバーは、クオリティの高い仕事を時間内に仕上げます（これに対し、相互信頼の低いチームのメン バーは責任を転嫁します）。 ❏ 信頼と呼べるものは相互理解と実績によって積み上がるものなのかと思いま す ❏ モブプロや共同の作業を通じてお互いを把握することや、貢献を認識できま す ❏ そもそも「みんなで進む」ということを主軸に置くことによって責任転嫁や 無関心な状態を減らしてこれました
18. 構造と明確さ > 効果的なチームをつくるには、職務上で要求されていること、その要求を満たすためのプロセス、そしてメンバーの行動がもたら す成果について、個々のメンバーが理解していることが重要となります。目標は、個人レベルで設定することもグループレベルで設 定することもできますが、具体的で取り組みがいがあり、なおかつ達成可能な内容でなければなりません。Google では、短期的な 目標と長期的な目標を設定してメンバーに周知するために、「目標と成果指標（OKR）」という手法が広く使われています。。 ❏ 計画や(短期の)目標などはアジャイル化によって実現できたかと思っていま す ❏ チームとしてしっかり目標を目指すというところは今後の課題
19. 仕事の意味 / インパクト > チームの効果性を向上するためには、仕事そのもの、またはその成果に対して目的意識を感じられる必要があります。仕事の意 味は属人的なものであり、経済的な安定を得る、家族を支える、チームの成功を助ける、自己表現するなど、人によってさまざまで す。 > 自分の仕事には意義があるとメンバーが主観的に思えるかどうかは、チームにとって重要なことです。個人の仕事が組織の目標 達成に貢献していることを可視化すると、個人の仕事のインパクトを把握しやすくなります。 ❏ 個々人の仕事の意味/意義やそれらの組織や社会に対するインパクトについて はまだまだ改善の余地があるなと思います(※やっと最近ここの目を向けるこ とができるようになってきた)
20. チームの現状 ← だいぶ担保できている ← 突き詰めていきたい ※チームの成熟度を表すわけではありません
21. 改めてどうしていたのかをふりかえる
22. ふりかえり ❏ どういうことをしていたのか ❏ みんなで協力しながら一歩ずつゴールに向かって進んでいくチームを作っていた ❏ 結果どうだったか ❏ 「みんなで協力」と「ゴールに向かって進む」という点では「効果的なチーム」の要素と似 たようなことが出来ていたと思う ❏ 結果としていいチームはある程度作れたと思う ❏ 結構困難な局面もあった中、チーム一丸となって進んでこれた
23. その他雑感 ❏ 「みんなで協力」という文化ははじめに作らないとあとからはだいぶ難しい と思う(今までの経験も踏まえ) ❏ コミュニケーションの場の作り方はどんな方法でもよいと思うが、個人的に はmeet/zoomで顔を出すようにして、多少冗長でも積極的に同期でコミュニ ケーションをしたほうがよいと思っている ❏ 個人的に単純接触効果や自己開示や共感による関係性向上の影響は大きいと思う ❏ GatherやDiscordなどの音声onlyのつながり方だと結構人を選んだり、ベースとなる関係性 が大事になってくる気がしている ❏ もちろん対面でもよい
24. 「相談会」は本当に効果的なのか① ❏ エンジニアには一定「集中して作業に取り組む時間」はあったほうがよい ❏ ただしそれでプロダクトが効果的に成長するのはチームや個々人がとても成 熟している必要があると思う ❏ 成熟度が低い人とのコミュニケーションやチームの状態だと、その集中して 取り組む時間≒フィードバックサイクルの無い時間が長くなり、その分手戻 りが多くなったり、タスクが完了するまでのリードタイムは長くなり、生産 性があまり高くなく、ナレッジのシェアなどもあまり活発にならなくなる可 能性があると思います ❏ →そういう意味ではチームが未成熟の場合にはこの相談会や枠を必ず決めて 集まって同期する場があることは効果的だと思います
25. ❏ 一方でチームが成熟していたり、不確実性が低く、すばやく手を動かせる場 合は相談会といった施策は不向きかもしれません ❏ また別の観点でいくと、そもそも固定のMTG枠などを取らずともGatherや Discordなどに常駐してすばやくやり取りができるチーム体制、関係性が気 づけていると不要になるかもしれません ❏ ただし、このコミュニケーションスタイルは人数が増減、変更されたときに維持できるか怪 しいので、普遍性のある仕組みに落とし込めたらよいのかなと思います 「相談会」は本当に効果的なのか②
26. おしまい