VPoEが語るfreeeの開発組織作りのリアルな話 / VPoE talks about the real story of building Freee's development organization

Transcript

1. VPoEが語るfreeeの 開発組織作りのリアルな話 ⽵⽥ 祥 2024年6⽉1⽇
2. 2 竹田 祥 / yoshi takeda
 2018年入社。2022年からVPoEとして各プロダク トやエンジニア組織作りの責任者を担当。趣味は 飼っているウサギ(x4)を触りまくることです。
 常務執⾏役員 VPoE
3. 　 VPoEが語るfreeeの開発組織作りのリアルな話 • freeeの開発組織のアウトライン ◦ 規模や特徴など • VPoEになってから⾏った組織的な取り組み ◦ 「Engineerサクセス」という組織を作った話 ◦ 開発チームにおける役割定義の明⽂化を⾏った話 • VPoEとして組織づくりを考え続けた結果分かってきたこと ◦ 組織作りとプロダクト作りは根本的に同じ
4.  freeeの開発組織のアウトライン   Overview 
5. スモールビジネスを、世界の主役に。 5
6. あらゆる業務とデータがつながることで、⾃動化‧可視化に加えてスマートで適切な経営アクションが可能に 統合型クラウドERP
7. 　 7 freee会計 freee開業 freee福利厚⽣ freeeアプリストア freee⼈事労務 freee会社設⽴ freee受発注 freeeプロジェクト管理 freee資⾦調達 freee申告 freeeカード プロダクトラインアップ freee販売
8. プロダクトリリースと組織スケールの歴史
9. freeeの開発組織 🚀 毎年様々な新プロダクトをリリース 󰝈 開発組織の⼈数はスケールし続けている   (特に2021年からは年に100⼈overの増加) 👫 地⽅拠点、グローバル採⽤、未経験者採⽤(タケノコ採 ⽤)   など、多様性の広がりもどんどん加速している
10. 　 VPoEになってから⾏った組織的な取り組み
11. 前提 このあたりでVPoE就任 (= ちょうどやばそうな成⻑カーブ描き始めた時期)
12. • 「毎⽉10⼈以上」「毎年100⼈以上」の⼊社 ハード、ソフト両⾯でのケアが重要かつ⼤規模に。 • 事業成⻑に合わせて、新しいチームが爆誕しまくる リーダーのアサイン、役割分担の重要性がガンガン上昇 めちゃくちゃエキサイティングだけど、カオスだらけ！
13. 今日はVPoEになってからやったことを少しご紹介 #1 「Engサクセス」という組織を作った話 #2 開発チームにおける役割定義を明⽂化した話   (共通⾔語を作ることの重要性)
14. 同じような状況、カオスなフェーズは スタートアップ、ベンチャーあるあるだと思うので 何かしら皆様の参考になれば嬉しいです。
15. 　 #1「Engineerサクセス」     という組織を作った話
16. ※去年の技術の日で詳細を喋ったのでぜひ見てください (今日はアウトラインだけを再度紹介) freee 技術の日 2023 TAMARIBA STAGE
17. どういう組織？ 参考にしたのは「カスタマーサクセス」という職種 プロダクトの導⼊⽀援や⼀緒に業務設計を考えたりと あらゆる⽅法でユーザを⽀援する役割 (BtoB SaaS企業ではメジャーなロール) 2022年7⽉にEngineer サクセスチーム 誕⽣ 🔥 VPoEである私も勿論がっつり参加 この「開発組織版」を作ろう！！
18. どういう組織？ 開発メンバーの「成功(サクセス)」に 繋がることだけを考え、実⾏し続ける専任チーム
19. freeeのエンジニアにとってのサクセス 何を⽬指しているの？ ユーザにとって価値のあるプロダクトを 変化を楽しみながら⽣み出し続けること
20. 何を⽬指しているの？ ユーザにとって価値のあるプロダクトを 変化を楽しみながら⽣み出し続けること 何を⽬指しているの？ そこに繋がることはなんでもやる
21. 　 新規 プロダクト たくさん ⼤規模な 組織 スケール 開発拠点 拡充 グローバル チャレンジ 働き⽅ アップデート Dev Rel etc.. 開発組織に必要なチャレンジ、変化、進化を ⽀え、促進するために必要なことをなんでもやる ⽇常的なケアから、制度設計まで。
22. 作って2年くらい経ったけど、ぶっちゃけどう？
23. むしろ作ってなかったら正直危なかったかも 思い切ってチャレンジして本当に良かった
24. • 組織の話はロングスパンだし、カロリーも多く使う • この速度での組織のスケールはマジで⼤変w (痛感した) • 凄いスピードでプロダクトを⽣み出しつつ 同時に組織テーマに向き合うのは本当に⼤変。 組織作りの起点となったり、整理する専任チームがいるだけで 組織の安定感が⼤幅に変わってくる。本当におすすめ。 組織に向き合う専任チームがいるという安⼼感の⼤きさ
25. 組織に向き合う⼟台ができると より深いテーマに取り組めるようになる (※次ページへの前振りです)
26. 　 #2 開発チームにおける役割定義を明⽂化した話   (共通⾔語を作ることの重要性)
27. 組織スケールによって生まれた組織的な課題 ⼈、チーム、プロダクトが増えていき 開発において求められる仕事や役割が多様化
28. • エンジニアとして価値を出すために何をしたら効果的なのか分からん - グレードの定義が抽象度⾼く、場⾯によっては迷いの元に。 - ⽬標設定を活⽤できていない、評価の納得感の不⾜ • マネージャーがあらゆることをやらないといけない - ピープルマネジメント、技術リード、プロジェクトマネジメント • キャリアパスの選択肢が狭いように感じる - 昔からいるなんでもできる⼈がなんか⽬⽴ちがち - 新しい⼈が活躍しづらいように⾒える 組織スケールによって生まれた組織的な課題
29. Engサクセスが主体となり ロール定義とそのラダー(段階)の明⽂化を進めた
30. 30 PdL Product Lead 役割、ロール EM Engineering Manager TL Technical Lead IC Individual Contributor インパクトを出す 主な領域 プロダクト‧基盤 組織‧⼈材 技術 技術 ※卓越した専⾨性 インパクトを出す 主なアプローチ チームで チームで チームで 主に個⼈で
31. 各ロールに求められる責務の概要
33. 各ロールに求められる 責務の詳細、責任の段階
34. このロール定義を作ったことで ⽣まれた⾯⽩い事例 ＝共通⾔語化を作ることの価値
35. #1 ⽬標設定の具体化
36. Before 「1年後にチームのリーダーとして働きたいです。」 #1 ⽬標設定の具体化
37. After 例1 「1年後に PdLのmiddleレベルのロールで 会計プロダクトのPdMと協業しながら プロダクトを進化させる⽴場 で働きたいです。」 #1 ⽬標設定の具体化
38. After 例2 「1年後に TLのseniorレベルのロールで 課⾦基盤を作るチームのアーキテクチャ設計 をリードする⽴場 で働きたいです。」 #1 ⽬標設定の具体化
39. #1 ⽬標設定の具体化 • ⽬指したい状態がより明確にイメージできる&表現できる • ⾃分⾃⾝＋そのマネージャーも同じ認識が持てるため より具体的な⽬標設定、成⻑に向けたプランの設計ができる • 評価においても、ロールに対する責務を軸に判断ができる 開発内の共通⾔語ができたことによる価値
40. #2 キャリアパスのモデル化 (先⾏事例の型化)
41. 現 VPoEの経験の変遷 満たすべき要素 社内のシニアエンジニアの歴史を可視化
42. 組織内のポジションに対するスキルのプロット 例えば、VPoEを⽬指すなら どういうスキルを ⾝につけるべきか可視化 (RPGのスキルマップみたい)
43. • 毎回freeeのエンジニア1⼈にフォーカスをあてて社内で配信する番組 • これまでのキャリアについてインタビュー形式で語ってもらう ▪ ⽣まれた時から今に⾄るまでの⼈⽣録 • これを⾒たメンバーがキャリアの歩み⽅の参考にしたり 新しい価値観やこれまでにない視野を得られるように。 エンジニア波瀾万丈伝
46. #1 ⽬標設定の具体化 • 先⼈の経験をモデルに落とせるようになった。 • 抽象度の⾼いレイヤー(xx部⻑、CTO、VPoEなど)に求められる ケイパビリティをある程度分解して表現できるようになった。 • この⼆つにより、キャリアパスを具体的に⽴てやすくなった。 開発内の共通⾔語ができたことによる価値
47. めちゃくちゃいいことばっかり書いてますが‧‧‧ 「組織全体に対する共通的な概念を⽣み出す」という仕事の プレッシャーや浸透させるためのメッセージングの難しさなど ⼤変なこともたくさんあるので、時間はかかります。 (※これは次回の技術の⽇で話すので来年も来てください 🐰) でもその時間をかけるだけの価値は間違いなくあると感じます。
48. 　 VPoEとして組織づくりを考え続けた結果  分かってきたこと 
49. プロダクト開発と組織作りは⾮常に良く似ている ユーザ理解 調査‧分析 設計‧実装 要求定義 評価
50. プロダクト開発と組織作りは⾮常に良く似ている ユーザ理解 調査‧分析 設計‧実装 要求定義 評価 組織作りも 基本的な流れは⼀緒 テーマを決めて サイクルを回す
51. いくつかポイントをゆるっと書いていきます  ユーザ理解 調査‧分析 • ユーザ＝エンジニア、チームメンバー、組織の仲間 ◦ 距離は近いが、プロダクトのユーザを理解するくらい本気で向き合う ◦ 近いからといって相手を理解するのに手を抜かない • 定量と定性、両⾯を使って理解する ◦ timesをみる、ヒアリングをする、サーベイをとる ◦ データを活用する(在籍年数、グレードなどなど) ◦ あらゆるデータを使いまくる。
52. いくつかポイントをゆるっと書いていきます 要求定義 • 本当に必要としているものは？逆に求めていないものは？ ◦ ユーザ理解を元に仮説をしっかり作る。 ◦ 制度や組織の話になると何故かここがわりとザルになりがち。 ▪ 会社都合で誰も求めてない制度とかできたりする ◦ プロダクト開発と一緒でMVPが定義できればお互いハッピー
53. いくつかポイントをゆるっと書いていきます 設計‧実装 • スモールスタートする！ ◦ 制度や組織の話になると何故か大きくなりがち ▪ いきなり全社適用したり。 ◦ プロダクトと同じで、実際やってみないと分からないこと多い ▪ 特定のチーム、部署でプロトタイピングするなど工夫する
54. いくつかポイントをゆるっと書いていきます 評価 • ユーザ理解と⼀緒で定量と定性、両⾯を使って評価する ◦ 定量だけでは計りづらいことも多い。 ◦ 逆に定性だけだと声の大きな主張に引きづられることも。 • 評価をしっかり受け⽌め、しっかりアップデートする ◦ 頑張って設計してやったことには愛着が湧くw ◦ 冷静に客観的に判断する(こういうのもプロダクト開発と一緒ですね)
55. 　 プロダクト開発と組織作りは近しい ↓ 普段プロダクトを作っている集団なら 良い組織も作れる（ はず！） そう考えると組織作りが楽しくなるかも。
56. 　 といいつつ、実際には試⾏錯誤の連続なので 組織作りに悩んでいる⽅、ぜひお話ししたいです。 ぜひ声をかけてください。 ご清聴ありがとうございました！