Tweet
Tweet

Slide 1

Slide 1 text

© Findy Inc. 1 開発パフォーマンスを 最⼤化するための開発体制 2024.04.24 Naoto Hamada

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

Slide 4

Slide 4 text

© Findy Inc. 4 Agenda - 開発⼈数の推移 - ①デイリースタンドアップの形骸化 - ②チーム分割(1→2) - ③チーム分割(2→3) - ④今後 - まとめ

Slide 5

Slide 5 text

© Findy Inc. 開発⼈数の推移 5

Slide 6

Slide 6 text

© Findy Inc. 6 開発⼈数の推移 ⼊社時 今⽉

Slide 7

Slide 7 text

© Findy Inc. 7 開発⼈数の推移 ⼤規模リファクタリングのため 他チームから増員

Slide 8

Slide 8 text

© Findy Inc. 8 開発⼈数の推移 開発を加速させるため 採⽤強化中！！

Slide 9

Slide 9 text

© Findy Inc. ①デイリースタンドアップの形骸化 9

Slide 10

Slide 10 text

© Findy Inc. 10 デイリースタンドアップ(朝会)の形骸化 作業状況を発表するだけに場になり 発表内容が薄く他者へのコメントも激減

Slide 11

Slide 11 text

© Findy Inc. 11 デイリースタンドアップ(朝会)の形骸化 - ⼈数が増えたことで複数開発が同時に動く - 直接関わっていない開発に対する関⼼が低下 - 直接関わっていないメンバーに配慮 - 当たり障りのない発表内容になった - コメントがしづらくなった - 同じ機能開発メンバーだけで別途開催されるようになる - ⼈数が多いので時間は15分フルでかかり余裕がない

Slide 12

Slide 12 text

© Findy Inc. 12 仮説 - 1チーム10名を超えておりチーム分割した⽅が良さそう - 分割軸が⾒えておらず意思決定に時間がかかりそう🤔 - チーム分割は先送り - “同じ機能開発メンバーで別途開催” - これの評判は良かった - これだけで良いのでは？

Slide 13

Slide 13 text

© Findy Inc. 13 デイリースタンドアップ分割 - 機能開発ごとに個別の会のみ開催 - 例外として少⼈数開発は合同で開催

Slide 14

Slide 14 text

© Findy Inc. 14 結果 - 個別開催はうまくいくものといかないものが明確になった - 元々、個別開催していたものは有意義な会になった - 新たに始めたものは変わらず形骸化したままだった - 参加者が減ったため時間は短縮された - 兼務により複数出席するメンバーの負担増

Slide 15

Slide 15 text

© Findy Inc. 15 結果 - 個別開催はうまくいくものといかないものが明確になった - 元々、個別開催していたものは有意義な会になった - 新たに始めたものは変わらず形骸化したままだった - 参加者が減ったため時間は短縮された - 兼務により複数出席するメンバーの負荷増 効果は限定的 悪化するメンバーもいたため 1ヶ⽉で戻した🥺

Slide 16

Slide 16 text

© Findy Inc. ②チーム分割(1→2) 16

Slide 17

Slide 17 text

© Findy Inc. 17 ②チーム分割(1→2) ②チーム分割 1→2

Slide 18

Slide 18 text

© Findy Inc. 18 ②チーム分割(1→2) - デイリースタンドアップのみの分割は断念 - チーム分割は分割軸が⾒えておらず時間がかかりそう🤔と 先送りにしていたが、⼩⼿先の対策では解決できないと判 断して検討を開始

Slide 19

Slide 19 text

© Findy Inc. 19 分割軸の検討 - 職能チーム - 職能横断チーム - ドメインで分割 - コンプリケイテッド‧サブシステム(チームトポロジー)

Slide 20

Slide 20 text

© Findy Inc. 20 職能チーム - フロントエンド‧バックエンドの技術の担当領域でチーム 分割 - システムはフロントエンド‧バックエンドで分割されてい るので、システム構成とチーム構成が⼀致する - 技術領域で分業することが多かったのでチームを分割して もやり⽅を変えずにできそう

Slide 21

Slide 21 text

© Findy Inc. 21 職能チーム デメリット - 機能開発をする場合、フロントエンド‧バックエンド両⽅ の対応が必要になるため、チーム間の連携が必要 - チーム間で密なコミュニケーションが必要になり、分割 のメリットが少ない

Slide 22

Slide 22 text

© Findy Inc. 22 職能チーム デメリット - 機能開発をする場合、フロントエンド‧バックエンド両⽅ の対応が必要になるため、チーム間の連携が必要 - チーム間で密なコミュニケーションが必要になり、分割 のメリットが少ない メリットが少ないので 不採⽤

Slide 23

Slide 23 text

© Findy Inc. 23 職能横断チーム - フロントエンド‧バックエンドが混在したチーム - 担当領域は絞らない - 全体で優先度の⾼いものから着⼿できる - チーム内で機能開発が完結するのでチーム間の密な連携が 不要になる

Slide 24

Slide 24 text

© Findy Inc. 24 職能横断チーム デメリット - 複数チームで同じシステムを触るためコンフリクト懸念 - コンフリクトしないためにチーム間の連携が必要

Slide 25

Slide 25 text

© Findy Inc. 25 職能横断チーム デメリット - 複数チームで同じシステムを触るためコンフリクト懸念 - コンフリクトしないためにチーム間の連携が必要 コンフリクト懸念 不採⽤

Slide 26

Slide 26 text

© Findy Inc. 26 ドメインで分割 - フロントエンド‧バックエンドが混在したチーム - ドメインを意識してチームごとに担当領域を決める - 担当ドメインを分けることでコンフリクト減少 - 特定チームに優先度が⾼い開発が偏る可能性がある - 来期ロードマップの注⼒領域を参考に偏らないよう に分割

Slide 27

Slide 27 text

© Findy Inc. 27 ドメインで分割 - 来期注⼒領域の⼀部は複雑性が⾼くバックエンドに開発が 集中することがわかった。そのため、ドメインで分割した 場合にバランスよく職能横断チームを結成することが困難

Slide 28

Slide 28 text

© Findy Inc. 28 ドメインで分割 - 来期注⼒領域の⼀部は複雑性が⾼くバックエンドに開発が 集中することがわかった。そのため、ドメインで分割した 場合にバランスよく職能横断チームを結成することが困難 バランスよく 分割できないので 不採⽤

Slide 29

Slide 29 text

© Findy Inc. 29 コンプリケイテッド‧サブシステム - 来期注⼒領域には、複雑性が⾼い領域があることがわかっ たので、その領域をコンプリケイテッド‧サブシステム チームとして分割する - 来期の注⼒領域と親和性が⾼い - チーム間で触る領域が被らない チームトポロジー https://pub.jmam.co.jp/book/b593881.html コンプリケイテッド‧サブシステムチーム - 複雑性が⾼く専⾨的な知識やスキルが必 要とされるサブシステムを管理するチー ム

Slide 30

Slide 30 text

© Findy Inc. 30 コンプリケイテッド‧サブシステム - 来期注⼒領域には、複雑性が⾼い領域があることがわかっ たので、その領域をコンプリケイテッド‧サブシステム チームとして分割する - 来期の注⼒領域と親和性が⾼い - チーム間で触る領域が被らない チームトポロジー https://pub.jmam.co.jp/book/b593881.html コンプリケイテッド‧サブシステムチーム - 複雑性が⾼く専⾨的な知識やスキルが必 要とされるサブシステムを管理するチー ム 採⽤

Slide 31

Slide 31 text

© Findy Inc. ストリーム アラインド 31 ②チーム分割(1→2) - 複雑な領域をコンプリケイテッドサブシステムチームが担 当 - その他はストリームアラインドチームが担当 PdM フロントエンド エンジニア バックエンド エンジニア コンプリケイテッド サブシステム バックエンド エンジニア

Slide 32

Slide 32 text

© Findy Inc. ③チーム分割(2→3) 32

Slide 33

Slide 33 text

© Findy Inc. 33 ③チーム分割(2→3) ③チーム分割 2→3

Slide 34

Slide 34 text

© Findy Inc. 34 2チームに分割後、下記の課題が顕在化 - 担当領域の境界があいまい - コンプリケイテッドサブシステムとのやりとりは ”X-as-a-Service” が推奨されているが、同⼀システムの ため境界が曖昧 - 両チームの知識が必要で認知負荷が軽減できていない - エンジニア増加により1チームの⼈数が増加 - PdM増加によりPdMが担当領域ごとに分業するようになっ た

Slide 35

Slide 35 text

© Findy Inc. 35 2チームに分割後、下記の課題が顕在化 - 担当領域の境界があいまい - コンプリケイテッドサブシステムとのやりとりは ”X-as-a-Service” が推奨されているが、同⼀システムの ため境界が曖昧 - 両チームの知識が必要で認知負荷が軽減できていない - エンジニア増加により1チームの⼈数が増加 - PdM増加によりPdMが担当領域ごとに分業するようになっ た チーム間コミュニケーションが多い →チーム間を疎結合にしたい

Slide 36

Slide 36 text

© Findy Inc. 36 2チームに分割後、下記の課題が顕在化 - 担当領域の境界があいまい - コンプリケイテッドサブシステムとのやりとりは ”X-as-a-Service” が推奨されているが、同⼀システムの ため境界が曖昧 - 両チームの知識が必要で認知負荷が軽減できていない - エンジニア増加により1チームの⼈数が増加 - PdM増加によりPdMが担当領域ごとに分業するようになっ た メンバーが増えたことで PdM×エンジニアで担当領域別 チームを作れるのではないか？

Slide 37

Slide 37 text

© Findy Inc. チーム① チーム② チーム③ 37 ③チーム分割(2→3) - 担当領域ごとにチーム分割 - PdM - エンジニア(フロントエンド‧バックエンド) PdM フロントエンド エンジニア バックエンド エンジニア PdM フロントエンド エンジニア バックエンド エンジニア PdM フロントエンド エンジニア バックエンド エンジニア

Slide 38

Slide 38 text

© Findy Inc. 38 ③チーム分割(2→3) - 機能開発がチーム内で完結するようになり認知負荷軽減 - 優先度やリソース調整はチーム内のPdMとコミュニケー ションするだけでよくなりコミュニケーション負荷軽減 チーム① チーム② チーム③ PdM フロントエンド エンジニア バックエンド エンジニア PdM フロントエンド エンジニア バックエンド エンジニア PdM フロントエンド エンジニア バックエンド エンジニア

Slide 39

Slide 39 text

© Findy Inc. ④今後 39

Slide 40

Slide 40 text

© Findy Inc. 40 ④今後 - 機能開発軸では最適化され、スケールできるイメージがで きた - 複数チームで同じシステムを触っているため、アーキテク チャにも反映させたい(コンウェイの法則) - アラートや問い合わせ、技術的負債解消など改善活動も適 切に分業したい - みんなでよしなにが難しい⼈数 - 開発チーム専属のQAやデザイナー - 今はリソースの関係で専属は難しい

Slide 41

Slide 41 text

© Findy Inc. まとめ 41

Slide 42

Slide 42 text

© Findy Inc. 42 まとめ - 朝会分割は1ヶ⽉で戻し、1→2へのチーム分割も3ヶ⽉後に は⽅針を変えた - 失敗の連続なのでは？？ - トライして課題を抽出できたので成功！！ - 失敗してもすぐに戻せるものはすぐにトライすべき！ - 朝会分割はアンケートもとって⼗分準備したつもりだっ たがやってみたら微妙だった‧‧‧ - やってみないとわからないことは多い！！ - ※事前準備を怠っても良いということではない

Slide 43

Slide 43 text

© Findy Inc. 43 まとめ - 朝会分割は1ヶ⽉で戻し、1→2へのチーム分割も3ヶ⽉後に は⽅針を変えた - 失敗の連続なのでは？？ - トライして課題を抽出できたので成功！！ - 失敗してもすぐに戻せるものはすぐにトライすべき！ - 朝会分割はアンケートもとって⼗分準備したつもりだっ たがやってみたら微妙だった‧‧‧ - やってみないとわからないことは多い！！ - ※事前準備を怠っても良いということではない - とはいえ 次々に⽅針転換することは リードする⽴場としては ⼼苦しい... それでもトライできている理由は...

Slide 44

Slide 44 text

© Findy Inc. 44 まとめ やっぱりやめます！を前向きに受け⼊れ てくれるメンバーの存在！超絶感謝 🙏 ※メンバーの優しさに⽢えすぎず、事前に頭出ししたり、実施 理由の丁寧な説明は引き続きやっていきます💪

Slide 45

Slide 45 text

© Findy Inc. 45 続いては Findy 2023下期 全社MVP shootaさんより ⾃⼰改善からチームを動かす！ 「セルフエンジニアリング マネージャー」のすゝめ 引⽤: https://note.com/findy_magazines/n/na4bbdce1ba3f