メンバーがオーナーシップを発揮しやすいチームづくり

2025/01/22 開催
ファインディ現場メンバーはFindy Team+をどう活用してる？
ーオンボーディングと振り返りの工夫
https://developer-productivity-engineering.connpass.com/event/340363/

登壇資料

Transcript

1. © Findy Inc. 2025.01.22 ファインディ現場メンバーはFindy Team+をどう活⽤してる？ 1 メンバーがオーナーシップを 発揮しやすいチームづくり 浜⽥ 直⼈ Naoto Hamada (ham)
2. © Findy Inc. 2 開発⽣産性が向上する⽅法を探求しているエンジニア！ Ruby / Rails / React / TypeScript / AWS Agile / DevOps / Developer Productivity / DevEx Stock Investment 浜⽥ 直⼈ Naoto Hamada (ham) @hamchance0215
3. © Findy Inc. ここまでの発表いかがでしたか？ 3
6. © Findy Inc. 6 Findy Team+(チームプラス)とは？ 開発⽣産性の可視化、開発プロセスの伸びしろの発⾒、継続的 な改善をサポート 6 ⽣産性可視化 ⽣産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー･配置･ツールの伸びしろを可視化‧最適化) ⽂化づくり‧⾃⼰組織化 (メンバーの⾃発的な改善促進、改善を称賛する⽂化作り) データ 連携 Engineer Engineer 開発組織ブランディング (エンジニアは、開発⽣産性が⾼い組織で働きたい) Recruit Biz
7. ※2025年1⽉時点
8. © Findy Inc. 8 Agenda - チームの変遷 - シニアエンジニアのみの⼩さいチーム - 10名を超えたチーム - 技術領域で分けたチーム(不採⽤) - システム構成に寄せたチーム - ストリームアラインドチーム - まとめ
9. © Findy Inc. チームの変遷 9
10. © Findy Inc. シニアエンジニアのみの ⼩さいチーム 10
11. © Findy Inc. Team+開発チーム 11
 シニアエンジニアのみの⼩さいチーム - エンジニア10名未満 - 経験年数が⻑く⾃律した エンジニアで構成 - 1つのイシューに1,2名ア サインして担当者がよし なに進める EM
12. © Findy Inc. 12
 シニアエンジニアのみの⼩さいチーム - 必要最低限のレールのみ定義して⾃由に開発を進める ◦ 細かくプルリクエストを作る⽂化 ◦ 必要最低限の開発プロセスを定義 ▪ レビューやQAのルールなど ◦ 開発パフォーマンスを可視化し、変化を正確に観測 Four Keys 1PRあたりのリードタイム
13. © Findy Inc. 13
 シニアエンジニアのみの⼩さいチーム - ⾃律した⼩さなチームでは、必要最低限のレール を敷きつつ、⼀⼈⼀⼈の裁量に任せることでパ フォーマンス⾼く開発を進めることができる ◦ マネジメントを最⼩限にできる - EMも開発できるため、チーム全体の開発量を最⼤ 化することができる ◦ 少⼈数チームでは1名のアウトプット増減が全 体に与える影響が⼤きい プルリク作成数/⼈/⽇ EM 合計
14. © Findy Inc. 10名を超えたチーム 14
15. © Findy Inc. Team+開発チーム 15
 10名を超えたチーム - 経験年数の短いメンバー も増加し、メンバー数が 10名を超えてきた - チーム外からのコミュニ ケーションパスが煩雑に EM
16. © Findy Inc. Team+開発チーム 16
 10名を超えたチーム EM PdM ◦◦の件、 誰に相談するのが 適切だろう...
17. © Findy Inc. Team+開発チーム 17
 10名を超えたチーム EM PdM - EMを結節点にすること で、チーム外からのコ ミュニケーションパスが 明確になる
18. © Findy Inc. Team+開発チーム 18
 10名を超えたチーム EM PdM - EMは開発チームに所属 しており、チーム状況を 把握できているため、(こ の規模であれば)問題なく ハンドリングできる
19. © Findy Inc. Team+開発チーム 19
 10名を超えたチーム EM PdM - メンバーは⼜聞きになる ため、オーナーシップが 低下しやすい - ⼀⼈⼀⼈オーナーシップ を持ちましょう！という のは簡単だが...
20. © Findy Inc. Team+開発チーム 20
 10名を超えたチーム EM PdM - メンバーは⼜聞きになる ため、オーナーシップが 低下しやすい オーナーシップは メンバー⼀⼈⼀⼈の意識だけではなく 発揮しやすい環境を作り込む
21. © Findy Inc. Team+開発チーム 21
 10名を超えたチーム EM PdM - メンバーは⼜聞きになる ため、オーナーシップが 低下しやすい [⽅針] 結節点がなくても良いくらい スモールチームにする
22. © Findy Inc. 技術領域で分けたチーム (不採⽤) 22
23. © Findy Inc. 23
 技術領域で分けたチーム Findy Team+のシステムアーキテクチャ (https://findy-tools.io/companies/findy/39/7)
 - フロントエンドとバックエンドはAPI連携(疎結合)
24. © Findy Inc. 24
 コンウェイの法則‧逆コンウェイ戦略 - コンウェイの法則 ◦ 組織が設計するシステムは、その組織のコミュニケー ション構造を反映したものになる - それを逆⼿にとる戦略が「逆コンウェイ戦略」 ◦ 理想のシステムアーキテクチャを実現するために、まず そのアーキテクチャをサポートするような組織構造に変 ⾰するという考え⽅があります。つまり、作りたいシス テムから逆算して組織をデザインするということです
25. © Findy Inc. - コンウェイの法則 ◦ 組織が設計するシステムは、その組織のコミュニケー ション構造を反映したものになる - それを逆⼿にとる戦略が「逆コンウェイ戦略」 ◦ 理想のシステムアーキテクチャを実現するために、まず そのアーキテクチャをサポートするような組織構造に変 ⾰するという考え⽅があります。つまり、作りたいシス テムから逆算して組織をデザインするということです 25
 コンウェイの法則‧逆コンウェイ戦略 システムはFEとBEで分かれている 開発チームも同じ区切りで 分ければよいのでは？
26. © Findy Inc. BE FE 26
 技術領域で分けたチーム - Webアプリケーション開 発において、1つの開発 を実施するためにFE/BE の両⽅必要なことが多 く、チームが分かれても 協業が必須 EM EM
27. © Findy Inc. BE FE 27
 技術領域で分けたチーム - 開発時はFE/BEでプロ ジェクト(緑枠)を組んで 活動することになる - ほとんどの時間をプロ ジェクトの枠組みで過ご すことになりチームの存 在意義が薄い EM EM
28. © Findy Inc. BE FE 28
 技術領域で分けたチーム - 開発時はFE/BEでプロ ジェクト(緑枠)を組んで 活動することになる - ほとんどの時間をプロ ジェクトの枠組みで過ご すことになりチームの存 在意義が薄い EM EM チームの存在意義が薄いので 不採⽤
29. © Findy Inc. システム構成に寄せたチーム 29
30. © Findy Inc. 30
 システム構成に寄せたチーム Findy Team+のデータインポートのアプリケーションアーキテクチャを大公開！
 (https://tech.findy.co.jp/entry/2024/12/10/080000)
 - 外部サービスの連携部分が開発も運⽤も重い
31. © Findy Inc. 31
 システム構成に寄せたチーム Findy Team+のデータインポートのアプリケーションアーキテクチャを大公開！
 (https://tech.findy.co.jp/entry/2024/12/10/080000)
 - アーキテクチャの境界でチーム分割 EM EM
32. © Findy Inc. 32
 システム構成に寄せたチーム Findy Team+のデータインポートのアプリケーションアーキテクチャを大公開！
 (https://tech.findy.co.jp/entry/2024/12/10/080000)
 - 「外部サービスの連携」と「画⾯の開発」を独⽴して開発 することができれば、分割軸としては適切 EM EM
33. © Findy Inc. 33
 システム構成に寄せたチーム Findy Team+のデータインポートのアプリケーションアーキテクチャを大公開！
 (https://tech.findy.co.jp/entry/2024/12/10/080000)
 - 画⾯に何を表⽰したいか把握していないと、外部サービス から取得すべきデータが判断できない 画⾯に 何を表⽰したい？
34. © Findy Inc. 34
 システム構成に寄せたチーム Findy Team+のデータインポートのアプリケーションアーキテクチャを大公開！
 (https://tech.findy.co.jp/entry/2024/12/10/080000)
 - 外部サービスから取得できるデータを把握していないと、 画⾯に何をどのように表⽰できるのか判断できない どんなデータが 取得できる？
35. © Findy Inc. 35
 システム構成に寄せたチーム Findy Team+のデータインポートのアプリケーションアーキテクチャを大公開！
 (https://tech.findy.co.jp/entry/2024/12/10/080000)
 - お互いに深い理解が必要で、分けるメリットが薄い ◦ 数ヶ⽉でやめました 相互理解
36. © Findy Inc. ストリームアラインドチーム 36
37. © Findy Inc. 37
 ストリームアラインドチーム - ストリームアラインドチームとは、価値のある単⼀の仕事 のストリームに沿って働くチームのことだ。 - さらに、なるべくそのチームだけですばやく安全に顧客や ユーザーに価値を届けられるように、チームに権限が委譲 されている。他のチームへの仕事の引き継ぎは必要ないと いうことだ。 https://pub.jmam.co.jp/book/b593881.html

38. © Findy Inc. FE BE 38
 技術領域で分けたチーム - チーム(⾚枠)とプロジェ クト(緑枠)を逆にする EM EM
39. © Findy Inc. 39
 ストリームアラインドチーム FE FE BE FE BE BE BE BE BE - 技術領域を横断したフル スタックチーム FE FE FE EM EM
40. © Findy Inc. 40
 ストリームアラインドチーム FE FE BE FE BE BE BE BE BE - 密に連携が必要な PdM‧QAもチームに紐付 ける - 各チームはプロダクト KPIをベースの開発 ◦ KPI ▪ 今まで価値提供できてい なかった企業へ拡⼤ ▪ 利⽤企業の利⽤率向上 FE FE FE EM EM PdM PdM QA QA
41. © Findy Inc. 41
 ストリームアラインドチーム FE FE BE FE BE BE BE BE BE - PdMがチームに所属する ことで、メンバーと直接 コミュニケーションしや すい体制 - 結節点がなく、メンバー がオーナーシップを発揮 しやすい環境 FE FE FE EM EM PdM PdM QA QA
42. © Findy Inc. 42
 ストリームアラインドチーム FE FE BE FE BE BE BE BE BE - EMのやるべきマネジメ ントは「ピープルマネジ メント」。「プロジェク トマネジメント」や「テ クニカルマネジメント」 はメンバーへ委譲 - 意思決定の範囲が広が り、メンバーがオーナー シップを発揮しやすい環 境 FE FE FE EM EM PdM PdM QA QA
43. © Findy Inc. 43
 ストリームアラインドチーム FE FE BE FE BE BE BE BE BE - EMのやるべきマネジメ ントは「ピープルマネジ メント」。「プロジェク トマネジメント」や「テ クニカルマネジメント」 はメンバーへ委譲 - 意思決定の範囲が広が り、メンバーがオーナー シップを発揮しやすい環 境 FE FE FE EM EM PdM PdM QA QA オーナーシップを発揮しやすい環境に向けて ‧メンバーが⼀次情報を取得しやすい ‧⼗分な権限を保有しており意思決定できる ‧EMがチームに所属して並⾛する
44. © Findy Inc. 44
 ストリームアラインドチーム FE FE BE FE BE BE BE BE BE - EMのやるべきマネジメ ントは「ピープルマネジ メント」。「プロジェク トマネジメント」や「テ クニカルマネジメント」 はメンバーへ委譲 - 意思決定の範囲が広が り、メンバーがオーナー シップを発揮しやすい環 境 FE FE FE EM EM PdM PdM QA QA この⽅針でチーム拡⼤中！！ (現在 6チーム 💪💪💪💪💪💪)
45. © Findy Inc. 45
 ストリームアラインドチーム - パフォーマンスの推移(2022年7〜12⽉→2024年7〜12⽉) Four Keys 1PRあたりのリードタイム
46. © Findy Inc. 46
 ストリームアラインドチーム - パフォーマンスの推移(2022年〜2024年) ◦ 稼働⼈数を増やしつつ、パフォーマンスを維持 ‧稼働⼈数: 約3倍 ‧1⼈あたりのプルリク作成数  ‧3〜4件を維持
47. © Findy Inc. まとめ 47
48. © Findy Inc. - プロダクトのフェーズやメンバーの属性やケイパビリティ によって最適なチームの形は異なる ◦ 1つの型に固執せず、その時々に最適な形を求め続ける - Howは状況により変わるが、オーナーシップを発揮しやす いチームづくりという観点はどの状況でも当てはまる - 開発チームのパフォーマンスはデリケード、少しの変化で 崩れたり、気付かぬうちに変化したりします。常に観測し て意思決定に活⽤しましょう(Powered by ) 48
 まとめ