Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

freee
July 23, 2024
2.8k

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

freee

July 23, 2024
Tweet

Transcript

  1. 2 ⽵⽥ 祥 / Yoshi Takeda Engineer 2005~ 執⾏役員 VPoE

    freee株式会社 常務執⾏役員 VPoE プロダクトグロース開発本部 本部⻑ Product Manager Engineering Manager
  2. 7 前提情報
 ◦ freeeの事業、プロダクトのご紹介 (超さらっと )
 ◦ freeeの開発組織のアウトライン 
 ◦

    「Engineer Success」という組織 
 本題 ◦ 組織作りに「プロダクト開発のエッセンス」を取り⼊れる 具体的な施策を元にポイントをご紹介
  3. 12

  4. 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月期
  5. 20 新規 プロダクト たくさん ⼤規模な 組織 スケール 開発拠点 拡充 グローバル

    チャレンジ 働き⽅ アップデート Dev Branding ⼭ほどの etc.. これらの変化、進化を⽀え 促進するための機能が組織に必要
  6. 39  ユーザ理解 調査‧分析 - freeeでの事例① 「Engineer Success ダッシュボード」の作成 
 ◦

    取り扱っているデータ 
 1. 基本情報や評価などの定量データ 
 2. 対話やサーベイ等による定性データ 
 3. 開発チーム共通の役割定義を元にした can/will/expect
 
 ◦ これらのデータを掛け合わせて、あらゆる角度から分析できる 
 ➢ いわゆるタレマネを本気でやっている状態 

  7. 41 takeda
 ① 基本情報や評価などの定量データ • 基本的な社員情報 
 ◦ 在籍年数
 ◦

    報酬
 ◦ 所属の変遷 など
 
 • 評価情報
 ◦ Qごとの評価 
 ◦ 入社からのグレードの変遷 など

  8. 42 takeda
 ② 対話やサーベイ等による定性データ • 対話による情報 (※共有範囲は非常に限定的 )
 ◦ 新規入社メンバー全員との入社

    2on1
 ▪ with VPoE & successメンバー
 ◦ VPoEとしての日常的な観察、うろうろ など
 
 • サーベイによる情報 
 ◦ コンディション (体調、メンタル )
 ◦ 本人視点での組織評価、わくわく感の変遷 など

  9. 43 takeda
 ③ 開発組織共通の役割定義を元にした can/will/expect • can / 本人+マネージャー の認識


    ◦ 既に実行できるロール、ラダー 
 
 • will / 本人の意思 
 ◦ 今後目指したいロール、ラダー 
 
 • expect / マネージャーが設計 
 ◦ チームや会社としての期待値として 
 今後担っていって欲しいロール、ラダー 

  10. 46 PdL Product Lead 役割、ロール EM Engineering Manager TL Technical

    Lead IC Individual Contributor インパクトを出す 主な領域 プロダクト 組織‧⼈材 技術 技術 ※卓越した専⾨性 インパクトを出す 主なアプローチ チームで チームで チームで 主に個⼈で
  11. 50 たとえばこんな使い⽅ Middle EM Middle PdL Junior PdL(若⼿エンジニア) x 2

    新規プロダクト開発チームを組成する際に必要な構成を表現
  12. 52 takeda
 ③ 開発組織共通の役割定義を元にした can/will/expect   に具体的なパラメータを当てはめるとこういうイメージ • can /

    本人+マネージャーの認識 
 ◦ Middle PdL, Junior EM を担当できる 
 
 • will / 本人の意思 
 ◦ 今後 Senior PdL を目指していきたい 
 
 • expect / マネージャーが設計 
 ◦ 今後 Senior PdL として活躍して欲しい 

  13. 56  ユーザ理解 調査‧分析 のポイント • 近道は意外とない。一次情報から触れていき、把握していくことが大事 
 ◦ 土台を作るまでは大変だが、メンバー 1人1人の解像度をできる限り上

    げ流努力を惜しまない。これが後々の意思決定の質に直結する。 
 
 • 定量と定性、両面のデータをミックスして使う 
 ◦ 相手は人なので、定量データだけでは見えない行間も多い 
 
 • 継続的にいつでもこのデータを参照できるようにしておく 
 ◦ 組織的な意思決定をする際に必ず側に置いておき根拠を持つ 

  14. 58  ユーザ理解 調査‧分析 - freeeでの事例 ② 「開発組織のポートフォリオ」の作成 
 ◦ 現在〜3年後までの組織構成の内訳の可視化

    
 1. 組織全体の人数 
 2. (先述の)ロール、ラダーの分布、人数 
 3. 各属性(例えば JP, global や 新卒, 中途 など)の分布、人数 
 4. 他にも多数の切り口で具体的な人数と割合をシミュレート 
 
 ◦ これを毎年事業状況に応じてアップデートし続ける。 

  15. 60  ユーザ理解 調査‧分析 のポイント • リアルな状況を織り込みつつも、縮こまらず理想像をイメージする 
 ◦ 現実的な案に落としていくといつの間にか保守的になりすぎる 


    ▪ +現実的すぎるとシンプルに面白くない。 
 ◦ 開発的な理想を考えイメージを広げる 
 
 • このイメージは経営メンバーと認識を合わせ続ける 
 ◦ これは開発組織への将来的な投資イメージそのもの 
 ▪ ここがずれていると、今後の事業やプロダクトに対する認識自体 がずれたまま進んでしまう可能性がある。 

  16. 63 freeeでの使い⽅の⼀例(リアルなやつ) • FY27の組織&プロダクトのスケール見据えると 
 このままでは Middle EMがxx人、Senior PdLがxx人足りない! 


    ◦ willに該当ロールを挙げている人の成長支援を整えよう 
 ◦ 採用計画、 JDをこのGAP、ロール定義を元にアップデートしよう 
 ◦ (ちなみにwill/canを踏まえると異動調整はめっちゃスムーズ )
 

  17. 67 • 必ず前フェーズの結果を元にした仮説を持って進める ◦ 組織テーマは無限に湧いてくるので、選択と集中が超⼤事 • スモールスタートする ◦ 制度や組織の話になると何故かいきなり⼤きくなりがち ◦

    プロダクトと同じで、実際やってみないと分からないこと多い ▪ 特定のチーム、部署でプロトタイピングするなど⼯夫する  設計、実⾏フェーズのポイント
  18. 69 • 感覚だけではなく、必ずデータをしっかり⾒る ◦ ここまでに意思決定の基盤ができていれば、そこに必ず影響がある (例えば先述の Engineer Success ダッシュボードに現れてくる) ◦

    むしろそういうデータドリブンなサイクルが回るような設計にしておく • 現実に向き合い、どんどんブラッシュアップする ◦ 組織的な取り組みは思ったより成果が出ないことも多い ◦ スモールに試しつつ、どんどん改善していく  評価フェーズのポイント