「Engineerサクセス」という組織を 作って感じた開発組織作りのポイント / Key-Points-for-Creating-a-Development-Organization

Transcript

1. 　 「Engineerサクセス」という組織を 作って感じた開発組織作りのポイント 2023.08.22
2. 2 ⽵⽥ 祥 / Yoshi Takeda Engineer 2005~ 執⾏役員 VPoE freee株式会社 常務執⾏役員 VPoE プロダクトグロース開発本部 本部⻑ Product Manager Engineering Manager
3. 　 3 趣味：うさぎx4を触りまくること うさぎを触るとあらゆることがどうでも良くなるのでオススメ
4. 　 今⽇話すことのざっくりサマリー
5. 5 • 開発組織をより良くすることにフォーカスする専任の組織を作った。 • 試⾏錯誤しながら1年以上たち、⼤事なことがいくつか⾒えてきた。 組織規模や会社のフェーズに依存しない話も多く、ぜひシェアしたい。 • 役職やロールに限らず、チームで開発している全ての⽅に通⽤する話 なので、少しでも皆さんの⽇々の仕事のプラスになれば嬉しいです 👍
6. 　  freeeの開発組織のアウトライン 
7. スモールビジネスを、世界の主役に。 7
8. 　 8 プロダクトラインナップ freee会計 freeeアプリストア freeeカード freee福利厚生 freee人事労務 freee受発注 freee開業 freee会社設立 freee工数管理 freee資金調達 freee申告 freee請求書 freee販売
9. 会社全体の従業員数 1,299⼈ ※従業員数は、2023年6⽉末の連結会社の正社員総数
10. 10 進化の軌跡：プロダクトとチーム プロダクト リリース freee会計 API公開 サービス 分割開始 チーム制 導入 クラウド ERP コンセプト発 表 マイクロ サービス化 開始 基盤投資 加速 プラット フォーム 構想 新規 プロダクト加 速 グローバ ル開発 freee 人事労務 freee 会社設立 freee開業 freee申告 freee finance lab設立 freee アプリストア freee プロジェクト管 理 freee カード Unlimited
11. 　  「Engineerサクセス」という  組織を作った話 
12. 12 開発メンバーの「成功(サクセス)」に 繋がることだけを考え、実⾏し続ける専任チーム どういう組織？
13. 13 freeeにおいての「サクセス」 ユーザにとって価値のあるプロダクトを 変化を楽しみながら最速で⽣み出し続けること
14. 14 どういう組織？ 参考にしたのは「カスタマーサクセス」という職種 BtoBのSaaSを提供する企業では⼀般的なファンクション 例えばfreeeにおけるカスタマーサクセス(ざっくり) 「ユーザの業務を成功に繋げる」 ための⽀援を⾏う役割 導⼊⽀援や⼀緒に業務設計を考えたりとあらゆる⽅法でユーザを⽀援する。 この「開発組織版」を作ろう！ = 2022年7⽉にEngineer サクセスチーム 爆誕 🔥
15. 15 ※どんなことをやってきたのかは 後半のセッションをお楽しみに！
16. 　  組織に向き合い続けて感じた   開発組織作りで⼤事なこと3選 
17. 17 1. プロダクト開発と組織作りは⾮常に良く似ている 2. データドリブンと⼈情ドリブンを⾏き来する 3. 楽なショートカットは基本ない 組織に向き合い続けて感じた開発組織作りで⼤事なこと3選 
18. 18 1.プロダクト開発と組織作りは⾮常に良く似ている 天の声 「良い組織作ってください」 なにからやればいいんだ‧‧‧
19. 19 1.プロダクト開発と組織作りは⾮常に良く似ている 天の声 「良いプロダクト作ってください」
20. 20 1.プロダクト開発と組織作りは⾮常に良く似ている ユーザ理解 調査‧分析 設計‧実装 要求定義 評価
21. 21 1.プロダクト開発と組織作りは⾮常に良く似ている ユーザ理解 調査‧分析 設計‧実装 要求定義 評価 組織作りも 基本的な流れは⼀緒 テーマを決めて サイクルを回す
22. 22 いくつかポイントをゆるっと書いていきます  ユーザ理解 調査‧分析 • ユーザ＝エンジニア、チームメンバー、組織の仲間 ◦ 距離は近いが、プロダクトのユーザを理解するくらい本気で向き合う ◦ 近いからといって相⼿を理解するのに⼿を抜かない • 定量と定性、両⾯を使って理解する ◦ timesをみる、ヒアリングをする、サーベイをとる ◦ データを活⽤する(在籍年数、グレードなどなど)
23. 23 いくつかポイントをゆるっと書いていきます 要求定義 • 本当に必要としているものは？逆に求めていないものは？ ◦ ユーザ理解を元に仮説をしっかり作る。 ◦ 制度や組織の話になると何故かここがわりとザルになりがち。 ▪ 会社都合で誰も求めてない制度とかできたりする ◦ プロダクト開発と⼀緒でMVPが定義できればお互いハッピー
24. 24 いくつかポイントをゆるっと書いていきます 設計‧実装 • スモールスタートする！ ◦ 制度や組織の話になると何故か⼤きくなりがち ▪ いきなり全社適⽤したり。 ◦ プロダクトと同じで、実際やってみないと分からないこと多い ▪ 特定のチーム、部署でプロトタイピングするなど⼯夫する
25. 25 いくつかポイントをゆるっと書いていきます 評価 • ユーザ理解と⼀緒で定量と定性、両⾯を使って評価する ◦ 定量だけでは計りづらいことも多い。 ◦ 逆に定性だけだと声の⼤きな主張に引きづられることも。 • 評価をしっかり受け⽌め、しっかりアップデートする ◦ 頑張って設計してやったことには愛着が湧くw ◦ 冷静に客観的に判断する(こういうのもプロダクト開発と⼀緒ですね)
26. 26 　 　 プロダクト開発と組織作りは近しい ↓ 良いプロダクトを作れる集団は 良い組織も作れるはず(逆も然り)
27. 　 正直ここまで覚えて帰ってもらったらOK あとはおまけです 😸
28. 28 2.データドリブンと⼈情ドリブンを⾏き来する 相⼿は⼈なので。 定量、定性 両⽅のバランスが⼤事
29. 29 3.楽なショートカットは基本ない ユーザ理解 調査‧分析 設計‧実装 要求定義 評価 これもプロダクト開発 と⼀緒。 ⼈、組織に 真摯に向き合い続ける しかない。 起点はここ
30. 30 　 　 ご清聴ありがとうございました！