「スニダン」開発組織の構造に込めた意図 ～組織作りはパッションや政治ではない！～

CTO達が考える、開発組織の構造とその意図
https://hack-at-delta.connpass.com/event/314224/

Transcript

1. 2024/04/22 CTO達が考える、開発組織の構造とその意図 「スニダン」開発組織の構造に込めた意図 ～組織作りはパッションや政治ではない！～ @rinchsan
2. CTO @SODA inc. ◦ 2020年10月に入社 ◦ Webエンジニア → VPoE (2022/01) → CTO (2023/10) ⇧⇧⇧ Backend Engineer @CyberAgent ◦ 2019年新卒入社 バックエンドエンジニア ◦ Go / AWSでサービス開発 Masaya Hayashi - @rinchsan X@rinchsan
3. 目次 SODA、スニダンについて 1 組織作りとは？ 2 SODAの組織デザイン 3 SODAの組織開発 4
4. SODA、スニダンについて 1
5. 鑑定付き 利用者数 No.1 スニーカー・トレカ フリマアプリ
6. MAU リクエスト数 ソースコード プロダクトの急成長
7. 3年半で 100万人 → 600万人 MAU プロダクトの急成長
8. 負荷スパイク（人気スニーカー発売など） 1万〜2万 rps 平常時 1,000〜2,000 rps リクエスト数 プロダクトの急成長 ※ 3年半前のデータはありません。
9. Goファイル数 約7,900ファイル Goコード行数 約1,370,000行 ソースコード - Go プロダクトの急成長 ※ 3年半前はファイル数900、コード行数13万。
10. Dartファイル数 約4,800ファイル Dartコード行数 約540,000行 ソースコード - Dart プロダクトの急成長 ※ ちょうど3年半前からFlutterへのリプレイスを開始
11. プロダクト開発組織 デプロイ頻度 組織の急拡大
12. 3年半で エンジニア 2名 → 45名 プロダクト開発組織全体では 4名 → 55名 プロダクト開発組織 組織の急拡大
13. Monthlyで 60回 〜 90回 Dailyで 3回 〜 4.5回 デプロイ頻度 プロダクトの急成長
14. 組織作りとは？ 2
15. 組織デザイン 組織開発 組織作りとは？
16. 組織デザインとは？
17. どのような組織体制にするか どのような権限を持たせるか 組織デザインは組織のハードウェア
18. 組織開発とは？
19. バリューや行動指針 何を評価するか 組織開発は組織のソフトウェア
20. 組織作りにおいて重要なこと
21. 🙅 政治やパッション
22. クラックしない、ハックする 当てずっぽうで動かない 研究に基づく指標・方針を参考に 🙅 政治やパッション ※ まぁでも結局やっぱり、パッションとかでいうと重要だったりはする
23. どうやって組織デザイン・組織開発を？
24. 採用 育成 評価 どうやって組織デザイン・組織開発をやっていく？ ※ 今日は、強いて言えば育成と評価にカテゴライズされる話になっている気がします
25. つまり
26. 採用する 育成する 評価する 組織デザインに必要なハードスキルを持った人材を
27. 採用する 育成する 評価する 組織開発に必要なソフトスキルを持った人材を
28. なぜ組織デザイン・組織開発が重要？
29. 不確実性の高いビジネス領域では 高い生産性・自律性が競争力に なぜ組織デザイン・組織開発を考えないといけないか
30. アジャイルな動きが重要 高い生産性が競争力となる 常に生産性の改善が必要 現状維持は衰退 不確実性が高いビジネス領域では
31. SODAの組織デザイン 3
32. エンジニア 2名 → 15名 2020/10 〜 2021/12
33. 拡大の様子と発生した課題
34. 少ない人数でドンドン開発していく！ ぼく CTO レビュー お願いします！ はい！ コード 書きまくるぞ！ こっちのIssue やります！ このIssue やります！ 最初は2人ですべてを「よしなに」。ほとんどの会社がこうでしょう。
35. 少ない人数(?)でドンドン開発していく...？ レビュー お願いします！ こっちのIssue やります！ コード 書きまくるぞ！ レビュー しますね！ コレやります！ すみません、 遅延してます！ ココどうなって るんですか？ 「予期せぬ遅延」や「既存実装への質問」など少しずつ不穏な空気が
36. コレ、思ってた よりも大変だ... なかなかタスク 終わらん... すみません、 遅延してます！ 少なくはない人数(確信)でもドンドン開発していく！ レビュー お願いします！ レビュー遅く なって すみません！ ココどうなって るんですか？ スミマセン、 遅れてます！ よくわからんけ どApprove… まぁ書いてる人 が一番理解して るから大丈夫... さらに不穏な空気が漂い出す・・・ ※ 誇張しています
37. とりあえず手を動かす 工数見積りは軽めで スケジュール遅延は仕方ない ガンガン作っていくことを優先
38. 事業成長 と、それを第一に考える組織文化 得られたもの
39. もちろん課題も発生
40. (1/5) 成果物が属人化していく・・・ 知らない！ たいへんそう！ この機能、 変更したいです この機能、 変更したいです あ、一瞬ですね ※ 誇張しています 心当たりがある方も多いのでは…？
41. (2/5) 他人のタスクへ無関心になっていく・・・ あのスケジュール じゃ大変じゃない のかなぁ コレ課題に感じてる のは私だけかも。 言わなくていっか たいへんだ... 頑張るって言って るから大丈夫だよ ※ 誇張しています 最悪の場合、「個人事業主の集まり」に…
42. (3/5) 仕様理解やコードレビューが大変に・・・ コードレビュー おねがいします！ でもきっと書いた人 が一番理解してる からあってるよね... コレ、この実装 でいいのかな... 知らない仕様の キャッチアップ たいへんだ... ※ 誇張しています レビュー時間が長いとPRサイズを大きくしたい悪循環に…
43. (4/5) スケジュールも予測しづらく・・・ じゃあベテランさん おねがいします！ ワシがやれば 1日でできる！ 私なら3日 かかるなぁ... 僕がやったら 1週間かかりそう なのにすごい！ ※ 誇張しています もちろん個人で差が出るのは当たり前だが…
44. (5/5) PdMの認知負荷が高まり、価値あるものに集中しづらく・・・ リリース 遅れそうです！ こちらの返信 まだですか！ ※ 誇張しています ここの仕様 どうしますか？ あれ、これ、 仕様違うの？ 1人で悩んでて 今日何も 進んでない... え、これ、 今日まで！？
45. 「フロー効率」を高めることで改善する
46. “仕事を「終わらせる」こと を優先する” 「フロー効率」を高めるとは https://techblog.tebiki.co.jp/stop-starting-start-finishing-f601e2b2600e ※ 記事内では「フロー効率」というワードは出てきません。 リソース効率重視 フロー効率重視
47. 「フロー効率」は「アジャイル開発」とセット 仕事のサイズを最小の価値にして状況の変化に対応する 引用：https://techblog.tebiki.co.jp/stop-starting-start-finishing-f601e2b2600e
48. どういう組織デザインをするか
49. フルサイクルなチームを作り、バリューストリーム全体に関わる 引用：https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325 アイデア 顧客 バリューストリーム PdM デザイナー エンジニア アナリスト マーケ ・・・
50. “驚くべき開発ツールを持 ち、設計、開発、テスト、 デプロイ、運用、サポート といったフルソフトウェア ライフサイクルへの責任を 持つ開発チームだ。” 「フルサイクルなチーム」とは 引用：Netflixにおけるフルサイクル開発者―開発したものが運用する https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325
51. 連携が取りやすいチームサイズ バリューストリーム全体に関わる 「フルサイクルなチーム」を作るには
52. 連携が取りやすいチームサイズ バリューストリーム全体に関わる 「フルサイクルなチーム」を作るには
53. “We try to create teams that are no larger than can be fed by two pizzas” ピザ2枚で満腹になる サイズでチームを作る AWS Whitepapers, Amazon.com (2014) https://docs.aws.amazon.com/ja_jp/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html ※ ただし、ピザはアメリカンサイズとする。
54. “スクラムチームは、敏捷性 を維持するための十分な小 ささと、スプリント内で重 要な作業を完了するための 十分な大きさがあり、通常 は10人以下である。” 『スクラムガイド』 (2020) https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
55. “チームとは、5人から9人 のメンバーからなる安定し たグループで、共有された ゴールのために働く単位の ことだ。” 『Team Topologies』 (2021)
56. 連携が取りやすいチームサイズ バリューストリーム全体に関わる 「フルサイクルなチーム」を作るには
57. “You build it, you run it.” 作ったら運用しろ Werner Vogels, CTO of Amazon.com (2006) https://queue.acm.org/detail.cfm?id=1142065 2007年〜2008年あたり本格化したDevOpsムーブメントの先駆者
58. “ストリームとは、ビジネス ドメインや組織の能力に 沿った仕事の継続的な流れ のことだ。” 『Team Topologies』 (2021) “ストリームアラインドチー ムとは、価値のある単一の 仕事のストリームに沿って 働くチームのことだ。”
59. つまり、職能横断なチームを作り、バリューストリーム全体にフルサイクルに関わる 引用：https://techblog.cartaholdings.co.jp/entry/2019/02/04/171325 アイデア 顧客 バリューストリーム PdM デザイナー エンジニア アナリスト マーケ ・・・
60. でも実は…
61. マーケ部署との連携が弱くなることも… エンジニア エンジニア PdM え！そのキャンペーン 来週からですか！？ こういう条件で ユーザにクーポンを 付与したいです！ マーケ 理想から外れていることを理解できれば、課題解決に動ける
62. タスク量の差でリソース効率への誘惑に負けてしまうことも… バックエンド エンジニア バックエンド エンジニア バックエンド エンジニア フロントエンド エンジニア フロントエンド エンジニア 忙しい忙しい！ ひまだな また別の こっちのタスク やりましょうか！ 理想から外れていることを理解し、許容範囲を超えないよう注意すればよい
63. 課題は常に発生し続けるもの
64. 明確な方向性や豊富な知識で 課題を解決し続ける 課題は常に発生し続けるもの
65. SODAの組織開発 4
66. エンジニア 2名 → 15名 2020/10 〜 2021/12
67. 拡大の様子と発生した課題
68. 特にVALUEや行動指針は作っていなかった ぼく CTO レビュー お願いします！ はい！ コード 書きまくるぞ！ こっちのIssue やります！ このIssue やります！ 2人でよしなにやっている間は特に問題は発生せず
69. 決めてもらうことが当たり前に これレビュー お願いします！ 次なにをすれば いいですか？ コレどうしたら いいですか？ あ、これダメ なんですか？ 次第にCTOなど特定の人の意思決定がボトルネックに CTOなど こうして ください！ レビュー 遅れてます！ ※ 誇張しています
70. スケールしていける体制を作り改善する
71. チームが自律的に課題発見・解決 組織成果の最大化 それらを体現する人を評価 組織がスケールするとは
72. どういう組織開発をするか
73. チームが自律的に課題発見・解決 組織成果の最大化 それらを体現する人を評価 ひたすら伝えていく
74. ただ伝えるだけでなく先人の知恵も借りる
75. チームが自律的に課題発見・解決 組織成果の最大化 それらを体現する人を評価 先人の知恵を借りる
76. “エンジニアリングで重要な のは「どうしたら効率よく 不確実性を減らしていける のか」という考え方なので す。” 「エンジニアリング」とは
77. “課題解決できたかどうかと いう結果だけを見ていると 運良く結果が出ることもあ るので、この能力を高めて いくうえでは、課題解決に 至るまでの学びを整理し、 再現性を意識させることも 効果的です。” 「再現性」と「言語化」
78. チームが自律的に課題発見・解決 組織成果の最大化 それらを体現する人を評価 先人の知恵を借りる
79. “アジャイルな方法論では、 プロダクトをきちんと届け るために、イテレーション を終わらせて「完成」させ るためならどんな作業でも 引き受ける覚悟のあるメン バーによる、チームワーク と連携を重視します。” 『ELASTIC LEADERSHIP』(2017)
80. “スタッフエンジニアの日々 のスケジュールは（中略） 基本的には共通している。 技術的な方向性を設定およ び修正し、スポンサーある いはメンターとして行動 し、組織の意思決定をサ ポートする” 『スタッフエンジニア』(2023) ※ 自分1人では出せない課題解決の幅と質を出すにはスポンサーのような動きが重要
81. Four Keys も便利
82. Four Keys 『LeanとDevOpsの科学』で登場した4つのキーメトリクス 引用：https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
83. “なぜソフトウェアデリバリ のパフォーマンスが重要で あるのか、それがいかにし て収益性、生産性、市場占 有率といった組織的パ フォーマンスの指標だけで なく、効率性、有効性、顧 客満足度、組織的使命の達 成といった非営利指標にも 影響するのかを考察した。” 『LeanとDevOpsの科学』(2018)
84. DevOps Capabilities Four Keysの指標を改善していくために必要な27個の技術・プロセス・文化 引用：https://cloud.google.com/architecture/devops
85. Four Keysを活用した自律的な改善
86. デプロイ頻度やリードタイムを改善するための様々な取り組み レビューコスト 高くない？ レビューまでの リードタイム 長くない？ いや、アサイン されたら すぐにしよう！ DevOps Capabilitiesに登場する「小さいバッチ」や「同期的レビュー」の実施 PRの作成数を増 やそう！ PRの変更行数 小さくする？
87. でも実は…
88. Four Keys改善にマンネリを感じてしまうことも… エンジニア エンジニア エンジニア あんまり 変わらんなぁ 手軽に大きく指標を改善する取り組みがサチってくる
89. チームでの課題発見・言語化・解決の難易度が上がり… エンジニア エンジニア エンジニア 何したら いいんだろう 「今うまくいってるからよくない？」の現状維持バイアスが出てくる
90. 課題は常に発生し続けるもの
91. 明確な方向性や豊富な知識で 課題を解決し続ける 課題は常に発生し続けるもの
92. まとめ
93. 🙅 政治やパッション
94. クラックしない、ハックする 当てずっぽうで動かない 研究に基づく指標・方針を参考に 🙅 政治やパッション ※ 研究とまではいかずとも、書籍で紹介されていたり他社事例が複数あったりでも十分
95. クラックしない、ハックする 当てずっぽうで動かない 研究に基づく指標・方針を参考に 🙅 政治やパッション ※ 研究とまではいかずとも、書籍で紹介されていたり他社事例が複数あったりでも十分