開発パフォーマンスを最大化するための開発体制

2024/04/24
「チームと個人の可能性を最大化する - パフォーマンスを落とさない体制構築とセルフマネジメント方法」で登壇したスライド
https://developer-productivity-engineering.connpass.com/event/315860/

Transcript

1. © Findy Inc. 1 開発パフォーマンスを 最⼤化するための開発体制 2024.04.24 Naoto Hamada
2. © Findy Inc. 2 開発⽣産性が向上する⽅法を探求しているエンジニア！ Ruby / Rails / React / TypeScript / AWS Agile / DevOps / Developer Productivity / DevEx Stock Investment 浜⽥ 直⼈ Naoto Hamada (ham) @hamchance0215
3. © Findy Inc. 3 Findy Team+(チームプラス)とは？ 開発⽣産性の可視化、開発プロセスの伸びしろの発⾒、継続的 な改善をサポート 3 ⽣産性可視化 ⽣産性向上 事業開発スピード加速 (開発スピードの向上により、仮説検証スピードも加速) 開発プロセス改善 (開発フロー･配置･ツールの伸びしろを可視化‧最適化) ⽂化づくり‧⾃⼰組織化 (メンバーの⾃発的な改善促進、改善を称賛する⽂化作り) データ 連携 Engineer Engineer 開発組織ブランディング (エンジニアは、開発⽣産性が⾼い組織で働きたい) Recruit Biz
4. © Findy Inc. 4 Agenda - 開発⼈数の推移 - ①デイリースタンドアップの形骸化 - ②チーム分割(1→2) - ③チーム分割(2→3) - ④今後 - まとめ
5. © Findy Inc. 開発⼈数の推移 5
6. © Findy Inc. 6 開発⼈数の推移 ⼊社時 今⽉
7. © Findy Inc. 7 開発⼈数の推移 ⼤規模リファクタリングのため 他チームから増員
8. © Findy Inc. 8 開発⼈数の推移 開発を加速させるため 採⽤強化中！！
9. © Findy Inc. ①デイリースタンドアップの形骸化 9
10. © Findy Inc. 10 デイリースタンドアップ(朝会)の形骸化 作業状況を発表するだけに場になり 発表内容が薄く他者へのコメントも激減
11. © Findy Inc. 11 デイリースタンドアップ(朝会)の形骸化 - ⼈数が増えたことで複数開発が同時に動く - 直接関わっていない開発に対する関⼼が低下 - 直接関わっていないメンバーに配慮 - 当たり障りのない発表内容になった - コメントがしづらくなった - 同じ機能開発メンバーだけで別途開催されるようになる - ⼈数が多いので時間は15分フルでかかり余裕がない
12. © Findy Inc. 12 仮説 - 1チーム10名を超えておりチーム分割した⽅が良さそう - 分割軸が⾒えておらず意思決定に時間がかかりそう🤔 - チーム分割は先送り - “同じ機能開発メンバーで別途開催” - これの評判は良かった - これだけで良いのでは？
13. © Findy Inc. 13 デイリースタンドアップ分割 - 機能開発ごとに個別の会のみ開催 - 例外として少⼈数開発は合同で開催
14. © Findy Inc. 14 結果 - 個別開催はうまくいくものといかないものが明確になった - 元々、個別開催していたものは有意義な会になった - 新たに始めたものは変わらず形骸化したままだった - 参加者が減ったため時間は短縮された - 兼務により複数出席するメンバーの負担増
15. © Findy Inc. 15 結果 - 個別開催はうまくいくものといかないものが明確になった - 元々、個別開催していたものは有意義な会になった - 新たに始めたものは変わらず形骸化したままだった - 参加者が減ったため時間は短縮された - 兼務により複数出席するメンバーの負荷増 効果は限定的 悪化するメンバーもいたため 1ヶ⽉で戻した🥺
16. © Findy Inc. ②チーム分割(1→2) 16
17. © Findy Inc. 17 ②チーム分割(1→2) ②チーム分割 1→2
18. © Findy Inc. 18 ②チーム分割(1→2) - デイリースタンドアップのみの分割は断念 - チーム分割は分割軸が⾒えておらず時間がかかりそう🤔と 先送りにしていたが、⼩⼿先の対策では解決できないと判 断して検討を開始
19. © Findy Inc. 19 分割軸の検討 - 職能チーム - 職能横断チーム - ドメインで分割 - コンプリケイテッド‧サブシステム(チームトポロジー)
20. © Findy Inc. 20 職能チーム - フロントエンド‧バックエンドの技術の担当領域でチーム 分割 - システムはフロントエンド‧バックエンドで分割されてい るので、システム構成とチーム構成が⼀致する - 技術領域で分業することが多かったのでチームを分割して もやり⽅を変えずにできそう
21. © Findy Inc. 21 職能チーム デメリット - 機能開発をする場合、フロントエンド‧バックエンド両⽅ の対応が必要になるため、チーム間の連携が必要 - チーム間で密なコミュニケーションが必要になり、分割 のメリットが少ない
22. © Findy Inc. 22 職能チーム デメリット - 機能開発をする場合、フロントエンド‧バックエンド両⽅ の対応が必要になるため、チーム間の連携が必要 - チーム間で密なコミュニケーションが必要になり、分割 のメリットが少ない メリットが少ないので 不採⽤
23. © Findy Inc. 23 職能横断チーム - フロントエンド‧バックエンドが混在したチーム - 担当領域は絞らない - 全体で優先度の⾼いものから着⼿できる - チーム内で機能開発が完結するのでチーム間の密な連携が 不要になる
24. © Findy Inc. 24 職能横断チーム デメリット - 複数チームで同じシステムを触るためコンフリクト懸念 - コンフリクトしないためにチーム間の連携が必要
25. © Findy Inc. 25 職能横断チーム デメリット - 複数チームで同じシステムを触るためコンフリクト懸念 - コンフリクトしないためにチーム間の連携が必要 コンフリクト懸念 不採⽤
26. © Findy Inc. 26 ドメインで分割 - フロントエンド‧バックエンドが混在したチーム - ドメインを意識してチームごとに担当領域を決める - 担当ドメインを分けることでコンフリクト減少 - 特定チームに優先度が⾼い開発が偏る可能性がある - 来期ロードマップの注⼒領域を参考に偏らないよう に分割
27. © Findy Inc. 27 ドメインで分割 - 来期注⼒領域の⼀部は複雑性が⾼くバックエンドに開発が 集中することがわかった。そのため、ドメインで分割した 場合にバランスよく職能横断チームを結成することが困難
28. © Findy Inc. 28 ドメインで分割 - 来期注⼒領域の⼀部は複雑性が⾼くバックエンドに開発が 集中することがわかった。そのため、ドメインで分割した 場合にバランスよく職能横断チームを結成することが困難 バランスよく 分割できないので 不採⽤
29. © Findy Inc. 29 コンプリケイテッド‧サブシステム - 来期注⼒領域には、複雑性が⾼い領域があることがわかっ たので、その領域をコンプリケイテッド‧サブシステム チームとして分割する - 来期の注⼒領域と親和性が⾼い - チーム間で触る領域が被らない チームトポロジー https://pub.jmam.co.jp/book/b593881.html コンプリケイテッド‧サブシステムチーム - 複雑性が⾼く専⾨的な知識やスキルが必 要とされるサブシステムを管理するチー ム
30. © Findy Inc. 30 コンプリケイテッド‧サブシステム - 来期注⼒領域には、複雑性が⾼い領域があることがわかっ たので、その領域をコンプリケイテッド‧サブシステム チームとして分割する - 来期の注⼒領域と親和性が⾼い - チーム間で触る領域が被らない チームトポロジー https://pub.jmam.co.jp/book/b593881.html コンプリケイテッド‧サブシステムチーム - 複雑性が⾼く専⾨的な知識やスキルが必 要とされるサブシステムを管理するチー ム 採⽤
31. © Findy Inc. ストリーム アラインド 31 ②チーム分割(1→2) - 複雑な領域をコンプリケイテッドサブシステムチームが担 当 - その他はストリームアラインドチームが担当 PdM フロントエンド エンジニア バックエンド エンジニア コンプリケイテッド サブシステム バックエンド エンジニア
32. © Findy Inc. ③チーム分割(2→3) 32
33. © Findy Inc. 33 ③チーム分割(2→3) ③チーム分割 2→3
34. © Findy Inc. 34 2チームに分割後、下記の課題が顕在化 - 担当領域の境界があいまい - コンプリケイテッドサブシステムとのやりとりは ”X-as-a-Service” が推奨されているが、同⼀システムの ため境界が曖昧 - 両チームの知識が必要で認知負荷が軽減できていない - エンジニア増加により1チームの⼈数が増加 - PdM増加によりPdMが担当領域ごとに分業するようになっ た
35. © Findy Inc. 35 2チームに分割後、下記の課題が顕在化 - 担当領域の境界があいまい - コンプリケイテッドサブシステムとのやりとりは ”X-as-a-Service” が推奨されているが、同⼀システムの ため境界が曖昧 - 両チームの知識が必要で認知負荷が軽減できていない - エンジニア増加により1チームの⼈数が増加 - PdM増加によりPdMが担当領域ごとに分業するようになっ た チーム間コミュニケーションが多い →チーム間を疎結合にしたい
36. © Findy Inc. 36 2チームに分割後、下記の課題が顕在化 - 担当領域の境界があいまい - コンプリケイテッドサブシステムとのやりとりは ”X-as-a-Service” が推奨されているが、同⼀システムの ため境界が曖昧 - 両チームの知識が必要で認知負荷が軽減できていない - エンジニア増加により1チームの⼈数が増加 - PdM増加によりPdMが担当領域ごとに分業するようになっ た メンバーが増えたことで PdM×エンジニアで担当領域別 チームを作れるのではないか？
37. © Findy Inc. チーム① チーム② チーム③ 37 ③チーム分割(2→3) - 担当領域ごとにチーム分割 - PdM - エンジニア(フロントエンド‧バックエンド) PdM フロントエンド エンジニア バックエンド エンジニア PdM フロントエンド エンジニア バックエンド エンジニア PdM フロントエンド エンジニア バックエンド エンジニア
38. © Findy Inc. 38 ③チーム分割(2→3) - 機能開発がチーム内で完結するようになり認知負荷軽減 - 優先度やリソース調整はチーム内のPdMとコミュニケー ションするだけでよくなりコミュニケーション負荷軽減 チーム① チーム② チーム③ PdM フロントエンド エンジニア バックエンド エンジニア PdM フロントエンド エンジニア バックエンド エンジニア PdM フロントエンド エンジニア バックエンド エンジニア
39. © Findy Inc. ④今後 39
40. © Findy Inc. 40 ④今後 - 機能開発軸では最適化され、スケールできるイメージがで きた - 複数チームで同じシステムを触っているため、アーキテク チャにも反映させたい(コンウェイの法則) - アラートや問い合わせ、技術的負債解消など改善活動も適 切に分業したい - みんなでよしなにが難しい⼈数 - 開発チーム専属のQAやデザイナー - 今はリソースの関係で専属は難しい
41. © Findy Inc. まとめ 41
42. © Findy Inc. 42 まとめ - 朝会分割は1ヶ⽉で戻し、1→2へのチーム分割も3ヶ⽉後に は⽅針を変えた - 失敗の連続なのでは？？ - トライして課題を抽出できたので成功！！ - 失敗してもすぐに戻せるものはすぐにトライすべき！ - 朝会分割はアンケートもとって⼗分準備したつもりだっ たがやってみたら微妙だった‧‧‧ - やってみないとわからないことは多い！！ - ※事前準備を怠っても良いということではない
43. © Findy Inc. 43 まとめ - 朝会分割は1ヶ⽉で戻し、1→2へのチーム分割も3ヶ⽉後に は⽅針を変えた - 失敗の連続なのでは？？ - トライして課題を抽出できたので成功！！ - 失敗してもすぐに戻せるものはすぐにトライすべき！ - 朝会分割はアンケートもとって⼗分準備したつもりだっ たがやってみたら微妙だった‧‧‧ - やってみないとわからないことは多い！！ - ※事前準備を怠っても良いということではない - とはいえ 次々に⽅針転換することは リードする⽴場としては ⼼苦しい... それでもトライできている理由は...
44. © Findy Inc. 44 まとめ やっぱりやめます！を前向きに受け⼊れ てくれるメンバーの存在！超絶感謝 🙏 ※メンバーの優しさに⽢えすぎず、事前に頭出ししたり、実施 理由の丁寧な説明は引き続きやっていきます💪
45. © Findy Inc. 45 続いては Findy 2023下期 全社MVP shootaさんより ⾃⼰改善からチームを動かす！ 「セルフエンジニアリング マネージャー」のすゝめ 引⽤: https://note.com/findy_magazines/n/na4bbdce1ba3f