組織作りに「プロダクト開発のエッセンス」を取り入れ、不確実性に向き合い続ける / Incorporating the “essence of product development” into organizational development and continuing to face uncertainty

by freee

Slide 1

Slide 1 text

組織作りに「プロダクト開発のエッセンス」   を取り入れ、不確実性に向き合い続ける   Developer Experience Day 2024 

Slide 2

Slide 2 text

2 ⽵⽥祥 / Yoshi Takeda Engineer 2005~ 執⾏役員 VPoE freee株式会社常務執⾏役員 VPoE プロダクトグロース開発本部本部⻑ Product Manager Engineering Manager

Slide 3

Slide 3 text

3 趣味：うさぎ x4を触りまくること。 (個人的な)DX上がりまくり。  

Slide 4

Slide 4 text

　 # 今回お話しすること

Slide 5

Slide 5 text

5 このセッションでは具体的な DX施策というよりは   その土台となる組織作りの進め方、必要なデータの活用方法   などのフレームについて話します。

Slide 6

Slide 6 text

6 こんな方の参考になれば幸いです。     ○ CTOやVPoE、EM、チームリーダーとして良い開発組織   良い開発者体験を作るために日々悩んでおり、夜も眠れない方     ○ それらを感覚だけではなく、少しだけロジカルに自信を持って進めていきたい方  

Slide 7

Slide 7 text

7 前提情報  ○ freeeの事業、プロダクトのご紹介 (超さらっと )  ○ freeeの開発組織のアウトライン   ○ 「Engineer Success」という組織   本題 ○ 組織作りに「プロダクト開発のエッセンス」を取り⼊れる具体的な施策を元にポイントをご紹介

Slide 8

Slide 8 text

会社概要 Corporate Overview

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

10 VISION だれもが⾃由に経営できる統合型経営プラットフォーム。

Slide 11

Slide 11 text

11 従業員数 1,299⼈ ※従業員数は、2023年6⽉末の連結会社の正社員総数

Slide 12

Slide 12 text

Slide 13

Slide 13 text

13 経費精算⼈事労務電⼦契約固定資産請求管理会計⼯数管理販売管理会計‧⼈事労務‧販売管理を核とした統合型経営プラットフォーム電⼦稟議債権債務管理

Slide 14

Slide 14 text

14 2019年 6月期 2020年 6月期 2017年 6月期 2018年 6月期 2021年 6月期有料課⾦ユーザー企業数（件）有料課金  ユーザー企業数 (1)は   約 54万事業所 2022年 6月期 45.1万 2023年 6月期 ※（1） 2024年3⽉末時点。有料課⾦ユーザー企業数には個⼈事業主を含む 37.9万 29.3万 22.4万 16万 12.1万 8.3万 54.3万 2024年 6月期

Slide 15

Slide 15 text

15 最近新キャラが誕生しました (LINEスタンプあります )  Sweee  スイー 

Slide 16

Slide 16 text

　 # 開発組織のアウトライン

Slide 17

Slide 17 text

17 プロダクトとチームの変遷

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

20 新規プロダクトたくさん⼤規模な組織スケール開発拠点拡充グローバルチャレンジ働き⽅アップデート Dev Branding ⼭ほどの etc.. これらの変化、進化を⽀え促進するための機能が組織に必要

Slide 21

Slide 21 text

21 取り組むべきテーマが多すぎて正直なにから⼿をつけたらいいか分からん

Slide 22

Slide 22 text

22 ひとまず開発組織作り専任チームを作ってみたまずは形から

Slide 23

Slide 23 text

23 参考にしたのは「カスタマーサクセス」という職種サービスを契約してくださったユーザに対して能動的に関わり続け、あらゆる⽅法で「ユーザの成功体験」をサポートしていく役割 (BtoB SaaS企業ではメジャーなファンクション) https://www.amazon.co.jp/dp/4862762603 このエンジニア組織版を作ろう！「Engineer Success チーム」を組成

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

27 組織作りのコンセプトとチームはできたが具体的にどう進めればいいんだ‧‧‧

Slide 28

Slide 28 text

　 # 組織作りに「プロダクト開発のエッセンス」を取り⼊れる

Slide 29

Slide 29 text

29 VPoEになって組織作りにフォーカスしている中で「組織作りはプロダクト開発と⾮常に似ている」ことに気付いたユーザ理解調査‧分析設計‧実⾏要求定義評価

Slide 30

Slide 30 text

30 組織作りをプロダクト開発のプロセスに沿って進めてみたユーザ＝開発組織のメンバー ①メンバーや組織を深く理解し ②組織に必要なことを⾒極め ③実際に試してみて ④結果を⾒ながら改善していくこの仮説検証サイクルを⾼速で回すユーザ理解調査‧分析設計‧実⾏要求定義評価

Slide 31

Slide 31 text

31 組織作りにプロダクト開発の概念を取り⼊れることの効果 ● 不確実性の⾼い活動に対して「思考の拠り所」を作ることができる ○ プロダクト開発には不確実性に向き合う叡智が詰まっている。「プロダクト開発だとどうするだろう？」という拠り所になる ● 普段慣れ親しんでいる概念なので認知負荷が低く、話が早い ○ フェーズの概念や⽤語など、既に共通認識、概念が⼀定ある ○ 組織作りとかHRって遠い存在でしょ？という前提を壊せる

Slide 32

Slide 32 text

32 数年やってみた結論：めちゃくちゃオススメです。ユーザ理解調査‧分析設計‧実⾏要求定義評価

Slide 33

Slide 33 text

　 # 各フェーズごとのポイントと具体的な施策の例

Slide 34

Slide 34 text

34 まずはこのフェーズ ①メンバーや組織を深く理解し ②組織に必要なことを⾒極める ①ユーザ理解調査‧分析 ③設計‧実⾏ ②要求定義 ④評価組織作りにおける意思決定に根拠を⽰し、仮説を作る

Slide 35

Slide 35 text

35 今の組織状態の把握構造としては意外とシンプル、ただ本気で向き合えているか⽬指したい組織状態の可視化実現のために必要な組織施策

Slide 36

Slide 36 text

36 今の組織状態の把握構造としては意外とシンプル、ただ本気で向き合えているか⽬指したい組織状態の可視化実現のために必要な組織施策⼈増えすぎて良くわからん... まだ先だし変化も⼤きいから具体性が... テーマが多すぎてどれから⼿をつければ...

Slide 37

Slide 37 text

37 今の組織状態の把握このそれぞれに対するfreeeのアプローチ事例をご紹介⽬指したい組織状態の可視化実現のために必要な組織施策事例① Engineer Success ダッシュボード事例② 3年分の開発組織のポートフォリオ

Slide 38

Slide 38 text

38 まずはこちらのアプローチ⽬指したい組織状態の可視化実現のために必要な組織施策今の組織状態の把握事例① Engineer Success ダッシュボード

Slide 39

Slide 39 text

39 ユーザ理解調査‧分析 - freeeでの事例① 「Engineer Success ダッシュボード」の作成   ○ 取り扱っているデータ   1. 基本情報や評価などの定量データ   2. 対話やサーベイ等による定性データ   3. 開発チーム共通の役割定義を元にした can/will/expect    ○ これらのデータを掛け合わせて、あらゆる角度から分析できる   ➢ いわゆるタレマネを本気でやっている状態  

Slide 40

Slide 40 text

40 「Engineer Success ダッシュボード」の作成、活用   イメージしやすいように私 (takeda)というエンジニアを例に説明  

Slide 41

Slide 41 text

41 takeda  ① 基本情報や評価などの定量データ ● 基本的な社員情報   ○ 在籍年数  ○ 報酬  ○ 所属の変遷など    ● 評価情報  ○ Qごとの評価   ○ 入社からのグレードの変遷など 

Slide 42

Slide 42 text

42 takeda  ② 対話やサーベイ等による定性データ ● 対話による情報 (※共有範囲は非常に限定的 )  ○ 新規入社メンバー全員との入社 2on1  ■ with VPoE & successメンバー  ○ VPoEとしての日常的な観察、うろうろなど    ● サーベイによる情報   ○ コンディション (体調、メンタル )  ○ 本人視点での組織評価、わくわく感の変遷など 

Slide 43

Slide 43 text

43 takeda  ③ 開発組織共通の役割定義を元にした can/will/expect ● can / 本人+マネージャーの認識  ○ 既に実行できるロール、ラダー     ● will / 本人の意思   ○ 今後目指したいロール、ラダー     ● expect / マネージャーが設計   ○ チームや会社としての期待値として   今後担っていって欲しいロール、ラダー  

Slide 44

Slide 44 text

44 ※ ここは少しコンテクストが深いので、補足   freeeの開発組織では⼈、チーム、プロダクトが増えていき開発において求められる仕事や役割が多様化し、複雑に。

Slide 45

Slide 45 text

45 Engineer Successチームが主体となり freeeで求められるロール定義とラダーの明⽂化を進め freee内で役割分担を語る際の「共通⾔語」とした

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

47 [余談] 価値提供に責任を持つロールめちゃくちゃ盛り上がっていますが freeeでも2023年頃からこのロール(PdL)がプロダクト開発のコアになっています。 https://speakerdeck.com/niwatakeru/about-product-engineer  https://speakerdeck.com/shnjtk/layerx-improve-development-pr oductivity-of-product-engineers 

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

50 たとえばこんな使い⽅ Middle EM Middle PdL Junior PdL(若⼿エンジニア) x 2 新規プロダクト開発チームを組成する際に必要な構成を表現

Slide 51

Slide 51 text

51 たとえばこんな使い⽅ Middle EM Middle PdL Junior PdL(若⼿エンジニア) 新規プロダクト開発チームを組成する際に必要な構成を表現

Slide 52

Slide 52 text

52 takeda  ③ 開発組織共通の役割定義を元にした can/will/expect に具体的なパラメータを当てはめるとこういうイメージ ● can / 本人+マネージャーの認識   ○ Middle PdL, Junior EM を担当できる     ● will / 本人の意思   ○ 今後 Senior PdL を目指していきたい     ● expect / マネージャーが設計   ○ 今後 Senior PdL として活躍して欲しい  

Slide 53

Slide 53 text

53 各メンバーに関する人事データが一元的に集まっている状態   もちろん横断的な分析も可能 (セグメンテーション、傾向把握など )  ③ 開発組織共通の役割定義を元にした can/will/expect ① 基本情報や評価などの定量データ ② 対話やサーベイ等による定性データ

Slide 54

Slide 54 text

54 ロールとラダーの分布(=組織のケイパビリティ) とそのロールの体験、コンディション PdL  EM  TL  IC  例えば、このダッシュボードがあるとこういうことができる #1 junior  middle  戦略理解、納得感ワクワク感体調

Slide 55

Slide 55 text

55 PdL  EM  新卒⼊社者の成⻑状況とキャリアイメージの把握 PdL  EM  TL  IC  例えば、このダッシュボードがあるとこういうことができる #2 FY23 新卒⼊社 can will

Slide 56

Slide 56 text

56 ユーザ理解調査‧分析のポイント ● 近道は意外とない。一次情報から触れていき、把握していくことが大事   ○ 土台を作るまでは大変だが、メンバー 1人1人の解像度をできる限り上げ流努力を惜しまない。これが後々の意思決定の質に直結する。     ● 定量と定性、両面のデータをミックスして使う   ○ 相手は人なので、定量データだけでは見えない行間も多い     ● 継続的にいつでもこのデータを参照できるようにしておく   ○ 組織的な意思決定をする際に必ず側に置いておき根拠を持つ  

Slide 57

Slide 57 text

57 今の組織状態の把握次はこちらのアプローチ (※これを先ほどのダッシュボードと組み合わせると超強⼒) ⽬指したい組織状態の可視化実現のために必要な組織施策事例② 3年分の開発組織のポートフォリオ

Slide 58

Slide 58 text

58 ユーザ理解調査‧分析 - freeeでの事例 ② 「開発組織のポートフォリオ」の作成   ○ 現在〜3年後までの組織構成の内訳の可視化   1. 組織全体の人数   2. (先述の)ロール、ラダーの分布、人数   3. 各属性(例えば JP, global や新卒, 中途など)の分布、人数   4. 他にも多数の切り口で具体的な人数と割合をシミュレート     ○ これを毎年事業状況に応じてアップデートし続ける。  

Slide 59

Slide 59 text

59 事業やプロダクトの計画から逆算した数字＋開発組織としてありたい像の意思ごめサンプル(データはダミー、項⽬は多少リアル)

Slide 60

Slide 60 text

60 ユーザ理解調査‧分析のポイント ● リアルな状況を織り込みつつも、縮こまらず理想像をイメージする   ○ 現実的な案に落としていくといつの間にか保守的になりすぎる   ■ ＋現実的すぎるとシンプルに面白くない。   ○ 開発的な理想を考えイメージを広げる     ● このイメージは経営メンバーと認識を合わせ続ける   ○ これは開発組織への将来的な投資イメージそのもの   ■ ここがずれていると、今後の事業やプロダクトに対する認識自体がずれたまま進んでしまう可能性がある。  

Slide 61

Slide 61 text

61 今の組織状態の把握ここまで⼟台ができれば、意思決定はかなりしやすくなる⽬指したい組織状態の可視化 Engineer Success ダッシュボード 3年分の開発組織のポートフォリオ

Slide 62

Slide 62 text

62 ここまで⼟台ができれば、意思決定はかなりしやすくなるこの前後のGAPはなにかどうやったら埋めていけるかを考えればOK 👍 Engineer Success ダッシュボード 3年分の開発組織のポートフォリオ今の組織状態の把握⽬指したい組織状態の可視化

Slide 63

Slide 63 text

63 freeeでの使い⽅の⼀例(リアルなやつ) ● FY27の組織&プロダクトのスケール見据えると   このままでは Middle EMがxx人、Senior PdLがxx人足りない！   ○ willに該当ロールを挙げている人の成長支援を整えよう   ○ 採用計画、 JDをこのGAP、ロール定義を元にアップデートしよう   ○ (ちなみにwill/canを踏まえると異動調整はめっちゃスムーズ )   

Slide 64

Slide 64 text

64 freeeでの使い⽅の⼀例(リアルなやつ) ● グレードxxになると次のグレードに上がる平均期間が大幅に伸びている   ○ この層に対して効果的なチャレンジアサインができているのか   ■ 評価キャリブレの際に次のアサインまで具体的に話そう    

Slide 65

Slide 65 text

65 実はここまでに書いた意思決定の⼟台が作れるとこの後の「実⾏&評価」はかなり進めやすくなります。なので、今回はさらりとポイントだけ紹介します。

Slide 66

Slide 66 text

66 ①ユーザ理解調査‧分析 ③設計‧実⾏ ②要求定義 ④評価

Slide 67

Slide 67 text

67 ● 必ず前フェーズの結果を元にした仮説を持って進める ○ 組織テーマは無限に湧いてくるので、選択と集中が超⼤事 ● スモールスタートする ○ 制度や組織の話になると何故かいきなり⼤きくなりがち ○ プロダクトと同じで、実際やってみないと分からないこと多い ■ 特定のチーム、部署でプロトタイピングするなど⼯夫する設計、実⾏フェーズのポイント

Slide 68

Slide 68 text

68 ①ユーザ理解調査‧分析 ③設計‧実⾏ ②要求定義 ④評価

Slide 69

Slide 69 text

69 ● 感覚だけではなく、必ずデータをしっかり⾒る ○ ここまでに意思決定の基盤ができていれば、そこに必ず影響がある (例えば先述の Engineer Success ダッシュボードに現れてくる) ○ むしろそういうデータドリブンなサイクルが回るような設計にしておく ● 現実に向き合い、どんどんブラッシュアップする ○ 組織的な取り組みは思ったより成果が出ないことも多い ○ スモールに試しつつ、どんどん改善していく評価フェーズのポイント

Slide 70

Slide 70 text

　 # まとめ

Slide 71

Slide 71 text

　　プロダクト開発と組織作りは⾮常に近しくその概念を応⽤することでより良い意思決定に繋げることができる

Slide 72

Slide 72 text

　　プロダクト開発と組織作りは近しい ↓

Slide 73

Slide 73 text

　　プロダクト開発と組織作りは近しい ↓ 良いプロダクトを作れる組織は良い組織も作れるはず(逆も然り)

Slide 74

Slide 74 text

74 　　ご清聴ありがとうございました！