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

by freee

Slide 1

Slide 1 text

VPoEが語るfreeeの開発組織作りのリアルな話⽵⽥祥 2024年6⽉1⽇

Slide 2

Slide 2 text

2 竹田祥 / yoshi takeda  2018年入社。2022年からVPoEとして各プロダクトやエンジニア組織作りの責任者を担当。趣味は飼っているウサギ(x4)を触りまくることです。  常務執⾏役員 VPoE

Slide 3

Slide 3 text

　 VPoEが語るfreeeの開発組織作りのリアルな話 ● freeeの開発組織のアウトライン ○ 規模や特徴など ● VPoEになってから⾏った組織的な取り組み ○ 「Engineerサクセス」という組織を作った話 ○ 開発チームにおける役割定義の明⽂化を⾏った話 ● VPoEとして組織づくりを考え続けた結果分かってきたこと ○ 組織作りとプロダクト作りは根本的に同じ

Slide 4

Slide 4 text

freeeの開発組織のアウトライン Overview

Slide 5

Slide 5 text

スモールビジネスを、世界の主役に。 5

Slide 6

Slide 6 text

あらゆる業務とデータがつながることで、⾃動化‧可視化に加えてスマートで適切な経営アクションが可能に統合型クラウドERP

Slide 7

Slide 7 text

　 7 freee会計 freee開業 freee福利厚⽣ freeeアプリストア freee⼈事労務 freee会社設⽴ freee受発注 freeeプロジェクト管理 freee資⾦調達 freee申告 freeeカードプロダクトラインアップ freee販売

Slide 8

Slide 8 text

プロダクトリリースと組織スケールの歴史

Slide 9

Slide 9 text

freeeの開発組織 🚀 毎年様々な新プロダクトをリリース 󰝈 開発組織の⼈数はスケールし続けている (特に2021年からは年に100⼈overの増加) 👫 地⽅拠点、グローバル採⽤、未経験者採⽤(タケノコ採⽤) など、多様性の広がりもどんどん加速している

Slide 10

Slide 10 text

　 VPoEになってから⾏った組織的な取り組み

Slide 11

Slide 11 text

前提このあたりでVPoE就任 (= ちょうどやばそうな成⻑カーブ描き始めた時期)

Slide 12

Slide 12 text

● 「毎⽉10⼈以上」「毎年100⼈以上」の⼊社ハード、ソフト両⾯でのケアが重要かつ⼤規模に。 ● 事業成⻑に合わせて、新しいチームが爆誕しまくるリーダーのアサイン、役割分担の重要性がガンガン上昇めちゃくちゃエキサイティングだけど、カオスだらけ！

Slide 13

Slide 13 text

今日はVPoEになってからやったことを少しご紹介 #1 「Engサクセス」という組織を作った話 #2 開発チームにおける役割定義を明⽂化した話 (共通⾔語を作ることの重要性)

Slide 14

Slide 14 text

同じような状況、カオスなフェーズはスタートアップ、ベンチャーあるあるだと思うので何かしら皆様の参考になれば嬉しいです。

Slide 15

Slide 15 text

　 #1「Engineerサクセス」という組織を作った話

Slide 16

Slide 16 text

※去年の技術の日で詳細を喋ったのでぜひ見てください (今日はアウトラインだけを再度紹介) freee 技術の日 2023 TAMARIBA STAGE

Slide 17

Slide 17 text

どういう組織？参考にしたのは「カスタマーサクセス」という職種プロダクトの導⼊⽀援や⼀緒に業務設計を考えたりとあらゆる⽅法でユーザを⽀援する役割 (BtoB SaaS企業ではメジャーなロール) 2022年7⽉にEngineer サクセスチーム誕⽣ 🔥 VPoEである私も勿論がっつり参加この「開発組織版」を作ろう！！

Slide 18

Slide 18 text

どういう組織？開発メンバーの「成功(サクセス)」に繋がることだけを考え、実⾏し続ける専任チーム

Slide 19

Slide 19 text

freeeのエンジニアにとってのサクセス何を⽬指しているの？ユーザにとって価値のあるプロダクトを変化を楽しみながら⽣み出し続けること

Slide 20

Slide 20 text

何を⽬指しているの？ユーザにとって価値のあるプロダクトを変化を楽しみながら⽣み出し続けること何を⽬指しているの？そこに繋がることはなんでもやる

Slide 21

Slide 21 text

　新規プロダクトたくさん⼤規模な組織スケール開発拠点拡充グローバルチャレンジ働き⽅アップデート Dev Rel etc.. 開発組織に必要なチャレンジ、変化、進化を⽀え、促進するために必要なことをなんでもやる⽇常的なケアから、制度設計まで。

Slide 22

Slide 22 text

作って2年くらい経ったけど、ぶっちゃけどう？

Slide 23

Slide 23 text

むしろ作ってなかったら正直危なかったかも思い切ってチャレンジして本当に良かった

Slide 24

Slide 24 text

● 組織の話はロングスパンだし、カロリーも多く使う ● この速度での組織のスケールはマジで⼤変w (痛感した) ● 凄いスピードでプロダクトを⽣み出しつつ同時に組織テーマに向き合うのは本当に⼤変。組織作りの起点となったり、整理する専任チームがいるだけで組織の安定感が⼤幅に変わってくる。本当におすすめ。組織に向き合う専任チームがいるという安⼼感の⼤きさ

Slide 25

Slide 25 text

組織に向き合う⼟台ができるとより深いテーマに取り組めるようになる (※次ページへの前振りです)

Slide 26

Slide 26 text

　 #2 開発チームにおける役割定義を明⽂化した話 (共通⾔語を作ることの重要性)

Slide 27

Slide 27 text

組織スケールによって生まれた組織的な課題⼈、チーム、プロダクトが増えていき開発において求められる仕事や役割が多様化

Slide 28

Slide 28 text

● エンジニアとして価値を出すために何をしたら効果的なのか分からん - グレードの定義が抽象度⾼く、場⾯によっては迷いの元に。 - ⽬標設定を活⽤できていない、評価の納得感の不⾜ ● マネージャーがあらゆることをやらないといけない - ピープルマネジメント、技術リード、プロジェクトマネジメント ● キャリアパスの選択肢が狭いように感じる - 昔からいるなんでもできる⼈がなんか⽬⽴ちがち - 新しい⼈が活躍しづらいように⾒える組織スケールによって生まれた組織的な課題

Slide 29

Slide 29 text

Engサクセスが主体となりロール定義とそのラダー(段階)の明⽂化を進めた

Slide 30

Slide 30 text

30 PdL Product Lead 役割、ロール EM Engineering Manager TL Technical Lead IC Individual Contributor インパクトを出す主な領域プロダクト‧基盤組織‧⼈材技術技術 ※卓越した専⾨性インパクトを出す主なアプローチチームでチームでチームで主に個⼈で

Slide 31

Slide 31 text

各ロールに求められる責務の概要

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

各ロールに求められる責務の詳細、責任の段階

Slide 34

Slide 34 text

このロール定義を作ったことで⽣まれた⾯⽩い事例＝共通⾔語化を作ることの価値

Slide 35

Slide 35 text

#1 ⽬標設定の具体化

Slide 36

Slide 36 text

Before 「1年後にチームのリーダーとして働きたいです。」 #1 ⽬標設定の具体化

Slide 37

Slide 37 text

After 例1 「1年後に PdLのmiddleレベルのロールで会計プロダクトのPdMと協業しながらプロダクトを進化させる⽴場で働きたいです。」 #1 ⽬標設定の具体化

Slide 38

Slide 38 text

After 例2 「1年後に TLのseniorレベルのロールで課⾦基盤を作るチームのアーキテクチャ設計をリードする⽴場で働きたいです。」 #1 ⽬標設定の具体化

Slide 39

Slide 39 text

#1 ⽬標設定の具体化 ● ⽬指したい状態がより明確にイメージできる&表現できる ● ⾃分⾃⾝＋そのマネージャーも同じ認識が持てるためより具体的な⽬標設定、成⻑に向けたプランの設計ができる ● 評価においても、ロールに対する責務を軸に判断ができる開発内の共通⾔語ができたことによる価値

Slide 40

Slide 40 text

#2 キャリアパスのモデル化 (先⾏事例の型化)

Slide 41

Slide 41 text

現 VPoEの経験の変遷満たすべき要素社内のシニアエンジニアの歴史を可視化

Slide 42

Slide 42 text

組織内のポジションに対するスキルのプロット例えば、VPoEを⽬指すならどういうスキルを⾝につけるべきか可視化 (RPGのスキルマップみたい)

Slide 43

Slide 43 text

● 毎回freeeのエンジニア1⼈にフォーカスをあてて社内で配信する番組 ● これまでのキャリアについてインタビュー形式で語ってもらう ■ ⽣まれた時から今に⾄るまでの⼈⽣録 ● これを⾒たメンバーがキャリアの歩み⽅の参考にしたり新しい価値観やこれまでにない視野を得られるように。エンジニア波瀾万丈伝

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

#1 ⽬標設定の具体化 ● 先⼈の経験をモデルに落とせるようになった。 ● 抽象度の⾼いレイヤー(xx部⻑、CTO、VPoEなど)に求められるケイパビリティをある程度分解して表現できるようになった。 ● この⼆つにより、キャリアパスを具体的に⽴てやすくなった。開発内の共通⾔語ができたことによる価値

Slide 47

Slide 47 text

めちゃくちゃいいことばっかり書いてますが‧‧‧ 「組織全体に対する共通的な概念を⽣み出す」という仕事のプレッシャーや浸透させるためのメッセージングの難しさなど⼤変なこともたくさんあるので、時間はかかります。 (※これは次回の技術の⽇で話すので来年も来てください 🐰) でもその時間をかけるだけの価値は間違いなくあると感じます。

Slide 48

Slide 48 text

　 VPoEとして組織づくりを考え続けた結果分かってきたこと

Slide 49

Slide 49 text

プロダクト開発と組織作りは⾮常に良く似ているユーザ理解調査‧分析設計‧実装要求定義評価

Slide 50

Slide 50 text

プロダクト開発と組織作りは⾮常に良く似ているユーザ理解調査‧分析設計‧実装要求定義評価組織作りも基本的な流れは⼀緒テーマを決めてサイクルを回す

Slide 51

Slide 51 text

いくつかポイントをゆるっと書いていきますユーザ理解調査‧分析 ● ユーザ＝エンジニア、チームメンバー、組織の仲間 ○ 距離は近いが、プロダクトのユーザを理解するくらい本気で向き合う ○ 近いからといって相手を理解するのに手を抜かない ● 定量と定性、両⾯を使って理解する ○ timesをみる、ヒアリングをする、サーベイをとる ○ データを活用する(在籍年数、グレードなどなど) ○ あらゆるデータを使いまくる。

Slide 52

Slide 52 text

いくつかポイントをゆるっと書いていきます要求定義 ● 本当に必要としているものは？逆に求めていないものは？ ○ ユーザ理解を元に仮説をしっかり作る。 ○ 制度や組織の話になると何故かここがわりとザルになりがち。 ■ 会社都合で誰も求めてない制度とかできたりする ○ プロダクト開発と一緒でMVPが定義できればお互いハッピー

Slide 53

Slide 53 text

いくつかポイントをゆるっと書いていきます設計‧実装 ● スモールスタートする！ ○ 制度や組織の話になると何故か大きくなりがち ■ いきなり全社適用したり。 ○ プロダクトと同じで、実際やってみないと分からないこと多い ■ 特定のチーム、部署でプロトタイピングするなど工夫する

Slide 54

Slide 54 text

いくつかポイントをゆるっと書いていきます評価 ● ユーザ理解と⼀緒で定量と定性、両⾯を使って評価する ○ 定量だけでは計りづらいことも多い。 ○ 逆に定性だけだと声の大きな主張に引きづられることも。 ● 評価をしっかり受け⽌め、しっかりアップデートする ○ 頑張って設計してやったことには愛着が湧くw ○ 冷静に客観的に判断する(こういうのもプロダクト開発と一緒ですね)

Slide 55

Slide 55 text

　プロダクト開発と組織作りは近しい ↓ 普段プロダクトを作っている集団なら良い組織も作れる（はず！）そう考えると組織作りが楽しくなるかも。

Slide 56

Slide 56 text

　といいつつ、実際には試⾏錯誤の連続なので組織作りに悩んでいる⽅、ぜひお話ししたいです。ぜひ声をかけてください。ご清聴ありがとうございました！

Slide 57

Slide 57 text

No content