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

Transcript

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

2. 2 ⽵⽥ 祥 / Yoshi Takeda Engineer 2005~ 執⾏役員 VPoE freee株式会社 常務執⾏役員 VPoE プロダクトグロース開発本部 本部⻑ Product Manager Engineering Manager
3. 3 趣味：うさぎ x4を触りまくること。 (個人的な)DX上がりまくり。 

4. 　 # 今回お話しすること
5. 5 このセッションでは具体的な DX施策というよりは 
 その土台となる組織作りの進め方、必要なデータの活用方法 
 などのフレームについて話します。
6. 6 こんな方の参考になれば幸いです。 
 
 ◦ CTOやVPoE、EM、チームリーダーとして良い開発組織 
 良い開発者体験を作るために日々悩んでおり、夜も眠れない方 
 
 ◦ それらを感覚だけではなく、少しだけロジカルに自信を持って進め ていきたい方 

7. 7 前提情報
 ◦ freeeの事業、プロダクトのご紹介 (超さらっと )
 ◦ freeeの開発組織のアウトライン 
 ◦ 「Engineer Success」という組織 
 本題 ◦ 組織作りに「プロダクト開発のエッセンス」を取り⼊れる 具体的な施策を元にポイントをご紹介
8. 会社概要 Corporate Overview
9. 9 スモールビジネスを、世界の主役に。 

10. 10 VISION だれもが⾃由に経営できる 統合型経営プラットフォーム。
11. 11 従業員数 1,299⼈ ※従業員数は、2023年6⽉末の連結会社の正社員総数
13. 13 経費精算 ⼈事労務 電⼦契約 固定資産 請求管理 会計 ⼯数管理 販売管理 会計‧⼈事労務‧販売管理を核とした 統合型経営プラットフォーム 電⼦稟議 債権債務 管理
14. 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月期
15. 15 最近新キャラが誕生しました (LINEスタンプあります )
 Sweee
 スイー

16. 　 # 開発組織のアウトライン
17. 17 プロダクトとチームの変遷
18. 18 freeeの開発組織の特性 ‧新プロダクトを毎年リリース ‧ 開発組織の⼈数はスケールし続けている   (特に2021年からは年に100⼈overの増加) ‧地⽅拠点、グローバル採⽤、未経験者採⽤など  多様性の広がりもどんどん加速している
19. 19 このあたりでVPoEに就任 (= ちょうどやばそうな成⻑カーブ描き始めた時期)
20. 20 新規 プロダクト たくさん ⼤規模な 組織 スケール 開発拠点 拡充 グローバル チャレンジ 働き⽅ アップデート Dev Branding ⼭ほどの etc.. これらの変化、進化を⽀え 促進するための機能が組織に必要
21. 21 取り組むべきテーマが多すぎて 正直なにから⼿をつけたらいいか分からん
22. 22 ひとまず開発組織作り専任チームを作ってみた まずは形から
23. 23 参考にしたのは「カスタマーサクセス」という職種 サービスを契約してくださったユーザに対して 能動的に関わり続け、あらゆる⽅法で 「ユーザの成功体験」をサポートしていく役割 (BtoB SaaS企業ではメジャーなファンクション) https://www.amazon.co.jp/dp/4862762603 このエンジニア組織版を作ろう！ 「Engineer Success チーム」を組成
24. 24 開発メンバーの「成功体験(サクセス)」に 繋がることだけを考え、実⾏し続ける専任チーム
25. 25 freeeのエンジニアにとってのサクセス ユーザにとって価値のあるプロダクトを 変化を楽しみながら最速で⽣み出し続けること
26. 26 そこに繋がることはなんでもやる ユーザにとって価値のあるプロダクトを 変化を楽しみながら最速で⽣み出し続けること
27. 27 組織作りのコンセプトとチームはできたが 具体的にどう進めればいいんだ‧‧‧
28. 　 # 組織作りに 「プロダクト開発のエッセンス」 を取り⼊れる
29. 29 VPoEになって組織作りにフォーカスしている中で 「組織作りはプロダクト開発と⾮常に似ている」ことに気付いた ユーザ理解 調査‧分析 設計‧実⾏ 要求定義 評価
30. 30 組織作りをプロダクト開発のプロセスに沿って進めてみた ユーザ ＝ 開発組織のメンバー ①メンバーや組織を深く理解し ②組織に必要なことを⾒極め ③実際に試してみて ④結果を⾒ながら改善していく この仮説検証サイクルを⾼速で回す ユーザ理解 調査‧分析 設計‧実⾏ 要求定義 評価
31. 31 組織作りにプロダクト開発の概念を取り⼊れることの効果 • 不確実性の⾼い活動に対して「思考の拠り所」を作ることができる ◦ プロダクト開発には不確実性に向き合う叡智が詰まっている。「プ ロダクト開発だとどうするだろう？」という拠り所になる • 普段慣れ親しんでいる概念なので認知負荷が低く、話が早い ◦ フェーズの概念や⽤語など、既に共通認識、概念が⼀定ある ◦ 組織作りとかHRって遠い存在でしょ？という前提を壊せる
32. 32 数年やってみた結論：めちゃくちゃオススメです。 ユーザ理解 調査‧分析 設計‧実⾏ 要求定義 評価
33. 　 # 各フェーズごとのポイントと 具体的な施策の例
34. 34 まずはこのフェーズ ①メンバーや組織を深く理解し ②組織に必要なことを⾒極める ①ユーザ理解 調査‧分析 ③設計‧実⾏ ②要求定義 ④評価 組織作りにおける意思決定に 根拠を⽰し、仮説を作る
35. 35 今の組織状態 の把握 構造としては意外とシンプル、ただ本気で向き合えているか ⽬指したい 組織状態 の可視化 実現のために 必要な組織施策
36. 36 今の組織状態 の把握 構造としては意外とシンプル、ただ本気で向き合えているか ⽬指したい 組織状態 の可視化 実現のために 必要な組織施策 ⼈増えすぎて良くわからん... まだ先だし変化も⼤きい から具体性が... テーマが多すぎて どれから⼿をつければ...
37. 37 今の組織状態 の把握 このそれぞれに対するfreeeのアプローチ事例をご紹介 ⽬指したい 組織状態 の可視化 実現のために 必要な組織施策 事例① Engineer Success ダッシュボード 事例② 3年分の開発組織のポートフォリオ
38. 38 まずはこちらのアプローチ ⽬指したい 組織状態 の可視化 実現のために 必要な組織施策 今の組織状態 の把握 事例① Engineer Success ダッシュボード
39. 39  ユーザ理解 調査‧分析 - freeeでの事例① 「Engineer Success ダッシュボード」の作成 
 ◦ 取り扱っているデータ 
 1. 基本情報や評価などの定量データ 
 2. 対話やサーベイ等による定性データ 
 3. 開発チーム共通の役割定義を元にした can/will/expect
 
 ◦ これらのデータを掛け合わせて、あらゆる角度から分析できる 
 ➢ いわゆるタレマネを本気でやっている状態 

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

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

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

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

44. 44 ※ ここは少しコンテクストが深いので、補足 
 freeeの開発組織では ⼈、チーム、プロダクトが増えていき 開発において求められる仕事や役割が多様化し、複雑に。
45. 45 Engineer Successチームが主体となり freeeで求められるロール定義とラダーの明⽂化を進め freee内で役割分担を語る際の「共通⾔語」とした
46. 46 PdL Product Lead 役割、ロール EM Engineering Manager TL Technical Lead IC Individual Contributor インパクトを出す 主な領域 プロダクト 組織‧⼈材 技術 技術 ※卓越した専⾨性 インパクトを出す 主なアプローチ チームで チームで チームで 主に個⼈で
47. 47 [余談] 価値提供に責任を持つロールめちゃくちゃ盛り上がっていますが freeeでも2023年頃からこのロール(PdL)がプロダクト開発のコアになっています。 https://speakerdeck.com/niwatakeru/about-product-engineer
 https://speakerdeck.com/shnjtk/layerx-improve-development-pr oductivity-of-product-engineers

48. 48 各ロールに求められる責務の概要
49. 49 各ロールに求められる 責務の詳細、責任の段階
50. 50 たとえばこんな使い⽅ Middle EM Middle PdL Junior PdL(若⼿エンジニア) x 2 新規プロダクト開発チームを組成する際に必要な構成を表現
51. 51 たとえばこんな使い⽅ Middle EM Middle PdL Junior PdL(若⼿エンジニア) 新規プロダクト開発チームを組成する際に必要な構成を表現
52. 52 takeda
 ③ 開発組織共通の役割定義を元にした can/will/expect   に具体的なパラメータを当てはめるとこういうイメージ • can / 本人+マネージャーの認識 
 ◦ Middle PdL, Junior EM を担当できる 
 
 • will / 本人の意思 
 ◦ 今後 Senior PdL を目指していきたい 
 
 • expect / マネージャーが設計 
 ◦ 今後 Senior PdL として活躍して欲しい 

53. 53 各メンバーに関する人事データが一元的に集まっている状態 
 もちろん横断的な分析も可能 (セグメンテーション、傾向把握など )
 ③ 開発組織共通の役割定義を元にした can/will/expect ① 基本情報や評価などの定量データ ② 対話やサーベイ等による定性データ
54. 54 ロールとラダーの分布(=組織のケイパビリティ) と そのロールの体験、コンディション PdL
 EM
 TL
 IC
 例えば、このダッシュボードがあるとこういうことができる #1 junior
 middle
 戦略理解、納得感 ワクワク感 体調
55. 55 PdL
 EM
 新卒⼊社者の成⻑状況とキャリアイメージの把握 PdL
 EM
 TL
 IC
 例えば、このダッシュボードがあるとこういうことができる #2 FY23 新卒⼊社 can will
56. 56  ユーザ理解 調査‧分析 のポイント • 近道は意外とない。一次情報から触れていき、把握していくことが大事 
 ◦ 土台を作るまでは大変だが、メンバー 1人1人の解像度をできる限り上 げ流努力を惜しまない。これが後々の意思決定の質に直結する。 
 
 • 定量と定性、両面のデータをミックスして使う 
 ◦ 相手は人なので、定量データだけでは見えない行間も多い 
 
 • 継続的にいつでもこのデータを参照できるようにしておく 
 ◦ 組織的な意思決定をする際に必ず側に置いておき根拠を持つ 

57. 57 今の組織状態 の把握 次はこちらのアプローチ (※これを先ほどのダッシュボードと組み合わせると超強⼒) ⽬指したい 組織状態 の可視化 実現のために 必要な組織施策 事例② 3年分の開発組織のポートフォリオ
58. 58  ユーザ理解 調査‧分析 - freeeでの事例 ② 「開発組織のポートフォリオ」の作成 
 ◦ 現在〜3年後までの組織構成の内訳の可視化 
 1. 組織全体の人数 
 2. (先述の)ロール、ラダーの分布、人数 
 3. 各属性(例えば JP, global や 新卒, 中途 など)の分布、人数 
 4. 他にも多数の切り口で具体的な人数と割合をシミュレート 
 
 ◦ これを毎年事業状況に応じてアップデートし続ける。 

59. 59  事業やプロダクトの計画から逆算した数字 ＋ 開発組織としてありたい像の意思ごめ サンプル(データはダミー、項⽬は多少リアル)
60. 60  ユーザ理解 調査‧分析 のポイント • リアルな状況を織り込みつつも、縮こまらず理想像をイメージする 
 ◦ 現実的な案に落としていくといつの間にか保守的になりすぎる 
 ▪ ＋現実的すぎるとシンプルに面白くない。 
 ◦ 開発的な理想を考えイメージを広げる 
 
 • このイメージは経営メンバーと認識を合わせ続ける 
 ◦ これは開発組織への将来的な投資イメージそのもの 
 ▪ ここがずれていると、今後の事業やプロダクトに対する認識自体 がずれたまま進んでしまう可能性がある。 

61. 61 今の組織状態 の把握 ここまで⼟台ができれば、意思決定はかなりしやすくなる ⽬指したい 組織状態 の可視化 Engineer Success ダッシュボード 3年分の開発組織のポートフォリオ
62. 62 ここまで⼟台ができれば、意思決定はかなりしやすくなる この前後のGAPはなにか どうやったら埋めていけるか を考えればOK 👍 Engineer Success ダッシュボード 3年分の開発組織のポートフォリオ 今の組織状態 の把握 ⽬指したい 組織状態 の可視化
63. 63 freeeでの使い⽅の⼀例(リアルなやつ) • FY27の組織&プロダクトのスケール見据えると 
 このままでは Middle EMがxx人、Senior PdLがxx人足りない！ 
 ◦ willに該当ロールを挙げている人の成長支援を整えよう 
 ◦ 採用計画、 JDをこのGAP、ロール定義を元にアップデートしよう 
 ◦ (ちなみにwill/canを踏まえると異動調整はめっちゃスムーズ )
 

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

65. 65 実はここまでに書いた意思決定の⼟台が作れると この後の「実⾏&評価」はかなり進めやすくなります。 なので、今回はさらりとポイントだけ紹介します。
66. 66 ①ユーザ理解 調査‧分析 ③設計‧実⾏ ②要求定義 ④評価
67. 67 • 必ず前フェーズの結果を元にした仮説を持って進める ◦ 組織テーマは無限に湧いてくるので、選択と集中が超⼤事 • スモールスタートする ◦ 制度や組織の話になると何故かいきなり⼤きくなりがち ◦ プロダクトと同じで、実際やってみないと分からないこと多い ▪ 特定のチーム、部署でプロトタイピングするなど⼯夫する  設計、実⾏フェーズのポイント
68. 68 ①ユーザ理解 調査‧分析 ③設計‧実⾏ ②要求定義 ④評価
69. 69 • 感覚だけではなく、必ずデータをしっかり⾒る ◦ ここまでに意思決定の基盤ができていれば、そこに必ず影響がある (例えば先述の Engineer Success ダッシュボードに現れてくる) ◦ むしろそういうデータドリブンなサイクルが回るような設計にしておく • 現実に向き合い、どんどんブラッシュアップする ◦ 組織的な取り組みは思ったより成果が出ないことも多い ◦ スモールに試しつつ、どんどん改善していく  評価フェーズのポイント
70. 　 # まとめ
71. 　 　 プロダクト開発と組織作りは⾮常に近しく その概念を応⽤することで より良い意思決定に繋げることができる
72. 　 　 プロダクト開発と組織作りは近しい ↓
73. 　 　 プロダクト開発と組織作りは近しい ↓ 良いプロダクトを作れる組織は 良い組織も作れるはず(逆も然り)
74. 74 　 　 ご清聴ありがとうございました！