Slide 1

Slide 1 text

© Findy Inc. 2025.01.22 ファインディ現場メンバーはFindy Team+をどう活⽤してる? 1 メンバーがオーナーシップを 発揮しやすいチームづくり 浜⽥ 直⼈ Naoto Hamada (ham)

Slide 2

Slide 2 text

© Findy Inc. 2 開発⽣産性が向上する⽅法を探求しているエンジニア! Ruby / Rails / React / TypeScript / AWS Agile / DevOps / Developer Productivity / DevEx Stock Investment 浜⽥ 直⼈ Naoto Hamada (ham) @hamchance0215

Slide 3

Slide 3 text

© Findy Inc. ここまでの発表いかがでしたか? 3

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

© Findy Inc. 6 Findy Team+(チームプラス)とは? 開発⽣産性の可視化、開発プロセスの伸びしろの発⾒、継続的 な改善をサポート 6 ⽣産性可視化 ⽣産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー・配置・ツールの伸びしろを可視化‧最適化) ⽂化づくり‧⾃⼰組織化 (メンバーの⾃発的な改善促進、改善を称賛する⽂化作り) データ 連携 Engineer Engineer 開発組織ブランディング (エンジニアは、開発⽣産性が⾼い組織で働きたい) Recruit Biz

Slide 7

Slide 7 text

※2025年1⽉時点

Slide 8

Slide 8 text

© Findy Inc. 8 Agenda - チームの変遷 - シニアエンジニアのみの⼩さいチーム - 10名を超えたチーム - 技術領域で分けたチーム(不採⽤) - システム構成に寄せたチーム - ストリームアラインドチーム - まとめ

Slide 9

Slide 9 text

© Findy Inc. チームの変遷 9

Slide 10

Slide 10 text

© Findy Inc. シニアエンジニアのみの ⼩さいチーム 10

Slide 11

Slide 11 text

© Findy Inc. Team+開発チーム 11
 シニアエンジニアのみの⼩さいチーム - エンジニア10名未満 - 経験年数が⻑く⾃律した エンジニアで構成 - 1つのイシューに1,2名ア サインして担当者がよし なに進める EM

Slide 12

Slide 12 text

© Findy Inc. 12
 シニアエンジニアのみの⼩さいチーム - 必要最低限のレールのみ定義して⾃由に開発を進める ○ 細かくプルリクエストを作る⽂化 ○ 必要最低限の開発プロセスを定義 ■ レビューやQAのルールなど ○ 開発パフォーマンスを可視化し、変化を正確に観測 Four Keys 1PRあたりのリードタイム

Slide 13

Slide 13 text

© Findy Inc. 13
 シニアエンジニアのみの⼩さいチーム - ⾃律した⼩さなチームでは、必要最低限のレール を敷きつつ、⼀⼈⼀⼈の裁量に任せることでパ フォーマンス⾼く開発を進めることができる ○ マネジメントを最⼩限にできる - EMも開発できるため、チーム全体の開発量を最⼤ 化することができる ○ 少⼈数チームでは1名のアウトプット増減が全 体に与える影響が⼤きい プルリク作成数/⼈/⽇ EM 合計

Slide 14

Slide 14 text

© Findy Inc. 10名を超えたチーム 14

Slide 15

Slide 15 text

© Findy Inc. Team+開発チーム 15
 10名を超えたチーム - 経験年数の短いメンバー も増加し、メンバー数が 10名を超えてきた - チーム外からのコミュニ ケーションパスが煩雑に EM

Slide 16

Slide 16 text

© Findy Inc. Team+開発チーム 16
 10名を超えたチーム EM PdM ○○の件、 誰に相談するのが 適切だろう...

Slide 17

Slide 17 text

© Findy Inc. Team+開発チーム 17
 10名を超えたチーム EM PdM - EMを結節点にすること で、チーム外からのコ ミュニケーションパスが 明確になる

Slide 18

Slide 18 text

© Findy Inc. Team+開発チーム 18
 10名を超えたチーム EM PdM - EMは開発チームに所属 しており、チーム状況を 把握できているため、(こ の規模であれば)問題なく ハンドリングできる

Slide 19

Slide 19 text

© Findy Inc. Team+開発チーム 19
 10名を超えたチーム EM PdM - メンバーは⼜聞きになる ため、オーナーシップが 低下しやすい - ⼀⼈⼀⼈オーナーシップ を持ちましょう!という のは簡単だが...

Slide 20

Slide 20 text

© Findy Inc. Team+開発チーム 20
 10名を超えたチーム EM PdM - メンバーは⼜聞きになる ため、オーナーシップが 低下しやすい オーナーシップは メンバー⼀⼈⼀⼈の意識だけではなく 発揮しやすい環境を作り込む

Slide 21

Slide 21 text

© Findy Inc. Team+開発チーム 21
 10名を超えたチーム EM PdM - メンバーは⼜聞きになる ため、オーナーシップが 低下しやすい [⽅針] 結節点がなくても良いくらい スモールチームにする

Slide 22

Slide 22 text

© Findy Inc. 技術領域で分けたチーム (不採⽤) 22

Slide 23

Slide 23 text

© Findy Inc. 23
 技術領域で分けたチーム Findy Team+のシステムアーキテクチャ (https://findy-tools.io/companies/findy/39/7)
 - フロントエンドとバックエンドはAPI連携(疎結合)

Slide 24

Slide 24 text

© Findy Inc. 24
 コンウェイの法則‧逆コンウェイ戦略 - コンウェイの法則 ○ 組織が設計するシステムは、その組織のコミュニケー ション構造を反映したものになる - それを逆⼿にとる戦略が「逆コンウェイ戦略」 ○ 理想のシステムアーキテクチャを実現するために、まず そのアーキテクチャをサポートするような組織構造に変 ⾰するという考え⽅があります。つまり、作りたいシス テムから逆算して組織をデザインするということです

Slide 25

Slide 25 text

© Findy Inc. - コンウェイの法則 ○ 組織が設計するシステムは、その組織のコミュニケー ション構造を反映したものになる - それを逆⼿にとる戦略が「逆コンウェイ戦略」 ○ 理想のシステムアーキテクチャを実現するために、まず そのアーキテクチャをサポートするような組織構造に変 ⾰するという考え⽅があります。つまり、作りたいシス テムから逆算して組織をデザインするということです 25
 コンウェイの法則‧逆コンウェイ戦略 システムはFEとBEで分かれている 開発チームも同じ区切りで 分ければよいのでは?

Slide 26

Slide 26 text

© Findy Inc. BE FE 26
 技術領域で分けたチーム - Webアプリケーション開 発において、1つの開発 を実施するためにFE/BE の両⽅必要なことが多 く、チームが分かれても 協業が必須 EM EM

Slide 27

Slide 27 text

© Findy Inc. BE FE 27
 技術領域で分けたチーム - 開発時はFE/BEでプロ ジェクト(緑枠)を組んで 活動することになる - ほとんどの時間をプロ ジェクトの枠組みで過ご すことになりチームの存 在意義が薄い EM EM

Slide 28

Slide 28 text

© Findy Inc. BE FE 28
 技術領域で分けたチーム - 開発時はFE/BEでプロ ジェクト(緑枠)を組んで 活動することになる - ほとんどの時間をプロ ジェクトの枠組みで過ご すことになりチームの存 在意義が薄い EM EM チームの存在意義が薄いので 不採⽤

Slide 29

Slide 29 text

© Findy Inc. システム構成に寄せたチーム 29

Slide 30

Slide 30 text

© Findy Inc. 30
 システム構成に寄せたチーム Findy Team+のデータインポートのアプリケーションアーキテクチャを大公開!
 (https://tech.findy.co.jp/entry/2024/12/10/080000)
 - 外部サービスの連携部分が開発も運⽤も重い

Slide 31

Slide 31 text

© Findy Inc. 31
 システム構成に寄せたチーム Findy Team+のデータインポートのアプリケーションアーキテクチャを大公開!
 (https://tech.findy.co.jp/entry/2024/12/10/080000)
 - アーキテクチャの境界でチーム分割 EM EM

Slide 32

Slide 32 text

© Findy Inc. 32
 システム構成に寄せたチーム Findy Team+のデータインポートのアプリケーションアーキテクチャを大公開!
 (https://tech.findy.co.jp/entry/2024/12/10/080000)
 - 「外部サービスの連携」と「画⾯の開発」を独⽴して開発 することができれば、分割軸としては適切 EM EM

Slide 33

Slide 33 text

© Findy Inc. 33
 システム構成に寄せたチーム Findy Team+のデータインポートのアプリケーションアーキテクチャを大公開!
 (https://tech.findy.co.jp/entry/2024/12/10/080000)
 - 画⾯に何を表⽰したいか把握していないと、外部サービス から取得すべきデータが判断できない 画⾯に 何を表⽰したい?

Slide 34

Slide 34 text

© Findy Inc. 34
 システム構成に寄せたチーム Findy Team+のデータインポートのアプリケーションアーキテクチャを大公開!
 (https://tech.findy.co.jp/entry/2024/12/10/080000)
 - 外部サービスから取得できるデータを把握していないと、 画⾯に何をどのように表⽰できるのか判断できない どんなデータが 取得できる?

Slide 35

Slide 35 text

© Findy Inc. 35
 システム構成に寄せたチーム Findy Team+のデータインポートのアプリケーションアーキテクチャを大公開!
 (https://tech.findy.co.jp/entry/2024/12/10/080000)
 - お互いに深い理解が必要で、分けるメリットが薄い ○ 数ヶ⽉でやめました 相互理解

Slide 36

Slide 36 text

© Findy Inc. ストリームアラインドチーム 36

Slide 37

Slide 37 text

© Findy Inc. 37
 ストリームアラインドチーム - ストリームアラインドチームとは、価値のある単⼀の仕事 のストリームに沿って働くチームのことだ。 - さらに、なるべくそのチームだけですばやく安全に顧客や ユーザーに価値を届けられるように、チームに権限が委譲 されている。他のチームへの仕事の引き継ぎは必要ないと いうことだ。 https://pub.jmam.co.jp/book/b593881.html


Slide 38

Slide 38 text

© Findy Inc. FE BE 38
 技術領域で分けたチーム - チーム(⾚枠)とプロジェ クト(緑枠)を逆にする EM EM

Slide 39

Slide 39 text

© Findy Inc. 39
 ストリームアラインドチーム FE FE BE FE BE BE BE BE BE - 技術領域を横断したフル スタックチーム FE FE FE EM EM

Slide 40

Slide 40 text

© 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

Slide 41

Slide 41 text

© Findy Inc. 41
 ストリームアラインドチーム FE FE BE FE BE BE BE BE BE - PdMがチームに所属する ことで、メンバーと直接 コミュニケーションしや すい体制 - 結節点がなく、メンバー がオーナーシップを発揮 しやすい環境 FE FE FE EM EM PdM PdM QA QA

Slide 42

Slide 42 text

© Findy Inc. 42
 ストリームアラインドチーム FE FE BE FE BE BE BE BE BE - EMのやるべきマネジメ ントは「ピープルマネジ メント」。「プロジェク トマネジメント」や「テ クニカルマネジメント」 はメンバーへ委譲 - 意思決定の範囲が広が り、メンバーがオーナー シップを発揮しやすい環 境 FE FE FE EM EM PdM PdM QA QA

Slide 43

Slide 43 text

© Findy Inc. 43
 ストリームアラインドチーム FE FE BE FE BE BE BE BE BE - EMのやるべきマネジメ ントは「ピープルマネジ メント」。「プロジェク トマネジメント」や「テ クニカルマネジメント」 はメンバーへ委譲 - 意思決定の範囲が広が り、メンバーがオーナー シップを発揮しやすい環 境 FE FE FE EM EM PdM PdM QA QA オーナーシップを発揮しやすい環境に向けて ‧メンバーが⼀次情報を取得しやすい ‧⼗分な権限を保有しており意思決定できる ‧EMがチームに所属して並⾛する

Slide 44

Slide 44 text

© Findy Inc. 44
 ストリームアラインドチーム FE FE BE FE BE BE BE BE BE - EMのやるべきマネジメ ントは「ピープルマネジ メント」。「プロジェク トマネジメント」や「テ クニカルマネジメント」 はメンバーへ委譲 - 意思決定の範囲が広が り、メンバーがオーナー シップを発揮しやすい環 境 FE FE FE EM EM PdM PdM QA QA この⽅針でチーム拡⼤中!! (現在 6チーム 💪💪💪💪💪💪)

Slide 45

Slide 45 text

© Findy Inc. 45
 ストリームアラインドチーム - パフォーマンスの推移(2022年7〜12⽉→2024年7〜12⽉) Four Keys 1PRあたりのリードタイム

Slide 46

Slide 46 text

© Findy Inc. 46
 ストリームアラインドチーム - パフォーマンスの推移(2022年〜2024年) ○ 稼働⼈数を増やしつつ、パフォーマンスを維持 ‧稼働⼈数: 約3倍 ‧1⼈あたりのプルリク作成数  ‧3〜4件を維持

Slide 47

Slide 47 text

© Findy Inc. まとめ 47

Slide 48

Slide 48 text

© Findy Inc. - プロダクトのフェーズやメンバーの属性やケイパビリティ によって最適なチームの形は異なる ○ 1つの型に固執せず、その時々に最適な形を求め続ける - Howは状況により変わるが、オーナーシップを発揮しやす いチームづくりという観点はどの状況でも当てはまる - 開発チームのパフォーマンスはデリケード、少しの変化で 崩れたり、気付かぬうちに変化したりします。常に観測し て意思決定に活⽤しましょう(Powered by ) 48
 まとめ