Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
組織作りに「プロダクト開発のエッセンス」 を取り入れ、不確実性に向き合い続ける / Incor...
Search
freee
July 23, 2024
0
2.5k
組織作りに「プロダクト開発のエッセンス」 を取り入れ、不確実性に向き合い続ける / Incorporating the “essence of product development” into organizational development and continuing to face uncertainty
freee
July 23, 2024
Tweet
Share
More Decks by freee
See All by freee
freee + Product Design FY25 Q2
freee
4
9.2k
freeeのモバイルエンジニアについて
freee
1
180
10分でわかるfreeeのQA
freee
1
3.9k
10分でわかるfreee エンジニア向け会社説明資料
freee
18
530k
freeeの福利厚生と働き方
freee
1
65k
品質の高速フィードバックへの取り組み / Commitment to Fast Quality Feedback
freee
4
980
LGBTQ__support_WOMEN_女性として働くということ_DEI
freee
2
500
QAエンジニア_Summer Internship説明会(26卒)
freee
0
260
権限管理基盤の開発とQAの今 / Authority Management Infrastructure Development and QA Now
freee
1
3.4k
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
10
790
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
It's Worth the Effort
3n
183
27k
The Cost Of JavaScript in 2023
addyosmani
45
6.9k
The Pragmatic Product Professional
lauravandoore
32
6.3k
Building Adaptive Systems
keathley
38
2.3k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.3k
Designing for humans not robots
tammielis
250
25k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
159
15k
Become a Pro
speakerdeck
PRO
25
5k
Transcript
組織作りに「プロダクト開発のエッセンス」 を取り入れ、不確実性に向き合い続ける Developer Experience Day 2024
2 ⽵⽥ 祥 / Yoshi Takeda Engineer 2005~ 執⾏役員 VPoE
freee株式会社 常務執⾏役員 VPoE プロダクトグロース開発本部 本部⻑ Product Manager Engineering Manager
3 趣味:うさぎ x4を触りまくること。 (個人的な)DX上がりまくり。
# 今回お話しすること
5 このセッションでは具体的な DX施策というよりは その土台となる組織作りの進め方、必要なデータの活用方法 などのフレームについて話します。
6 こんな方の参考になれば幸いです。 ◦ CTOやVPoE、EM、チームリーダーとして良い開発組織 良い開発者体験を作るために日々悩んでおり、夜も眠れない方
◦ それらを感覚だけではなく、少しだけロジカルに自信を持って進め ていきたい方
7 前提情報 ◦ freeeの事業、プロダクトのご紹介 (超さらっと ) ◦ freeeの開発組織のアウトライン ◦
「Engineer Success」という組織 本題 ◦ 組織作りに「プロダクト開発のエッセンス」を取り⼊れる 具体的な施策を元にポイントをご紹介
会社概要 Corporate Overview
9 スモールビジネスを、世界の主役に。
10 VISION だれもが⾃由に経営できる 統合型経営プラットフォーム。
11 従業員数 1,299⼈ ※従業員数は、2023年6⽉末の連結会社の正社員総数
12
13 経費精算 ⼈事労務 電⼦契約 固定資産 請求管理 会計 ⼯数管理 販売管理 会計‧⼈事労務‧販売管理を核とした
統合型経営プラットフォーム 電⼦稟議 債権債務 管理
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 最近新キャラが誕生しました (LINEスタンプあります ) Sweee スイー
# 開発組織のアウトライン
17 プロダクトとチームの変遷
18 freeeの開発組織の特性 ‧新プロダクトを毎年リリース ‧ 開発組織の⼈数はスケールし続けている (特に2021年からは年に100⼈overの増加) ‧地⽅拠点、グローバル採⽤、未経験者採⽤など 多様性の広がりもどんどん加速している
19 このあたりでVPoEに就任 (= ちょうどやばそうな成⻑カーブ描き始めた時期)
20 新規 プロダクト たくさん ⼤規模な 組織 スケール 開発拠点 拡充 グローバル
チャレンジ 働き⽅ アップデート Dev Branding ⼭ほどの etc.. これらの変化、進化を⽀え 促進するための機能が組織に必要
21 取り組むべきテーマが多すぎて 正直なにから⼿をつけたらいいか分からん
22 ひとまず開発組織作り専任チームを作ってみた まずは形から
23 参考にしたのは「カスタマーサクセス」という職種 サービスを契約してくださったユーザに対して 能動的に関わり続け、あらゆる⽅法で 「ユーザの成功体験」をサポートしていく役割 (BtoB SaaS企業ではメジャーなファンクション) https://www.amazon.co.jp/dp/4862762603 このエンジニア組織版を作ろう! 「Engineer
Success チーム」を組成
24 開発メンバーの「成功体験(サクセス)」に 繋がることだけを考え、実⾏し続ける専任チーム
25 freeeのエンジニアにとってのサクセス ユーザにとって価値のあるプロダクトを 変化を楽しみながら最速で⽣み出し続けること
26 そこに繋がることはなんでもやる ユーザにとって価値のあるプロダクトを 変化を楽しみながら最速で⽣み出し続けること
27 組織作りのコンセプトとチームはできたが 具体的にどう進めればいいんだ‧‧‧
# 組織作りに 「プロダクト開発のエッセンス」 を取り⼊れる
29 VPoEになって組織作りにフォーカスしている中で 「組織作りはプロダクト開発と⾮常に似ている」ことに気付いた ユーザ理解 調査‧分析 設計‧実⾏ 要求定義 評価
30 組織作りをプロダクト開発のプロセスに沿って進めてみた ユーザ = 開発組織のメンバー ①メンバーや組織を深く理解し ②組織に必要なことを⾒極め ③実際に試してみて ④結果を⾒ながら改善していく この仮説検証サイクルを⾼速で回す
ユーザ理解 調査‧分析 設計‧実⾏ 要求定義 評価
31 組織作りにプロダクト開発の概念を取り⼊れることの効果 • 不確実性の⾼い活動に対して「思考の拠り所」を作ることができる ◦ プロダクト開発には不確実性に向き合う叡智が詰まっている。「プ ロダクト開発だとどうするだろう?」という拠り所になる • 普段慣れ親しんでいる概念なので認知負荷が低く、話が早い ◦
フェーズの概念や⽤語など、既に共通認識、概念が⼀定ある ◦ 組織作りとかHRって遠い存在でしょ?という前提を壊せる
32 数年やってみた結論:めちゃくちゃオススメです。 ユーザ理解 調査‧分析 設計‧実⾏ 要求定義 評価
# 各フェーズごとのポイントと 具体的な施策の例
34 まずはこのフェーズ ①メンバーや組織を深く理解し ②組織に必要なことを⾒極める ①ユーザ理解 調査‧分析 ③設計‧実⾏ ②要求定義 ④評価 組織作りにおける意思決定に
根拠を⽰し、仮説を作る
35 今の組織状態 の把握 構造としては意外とシンプル、ただ本気で向き合えているか ⽬指したい 組織状態 の可視化 実現のために 必要な組織施策
36 今の組織状態 の把握 構造としては意外とシンプル、ただ本気で向き合えているか ⽬指したい 組織状態 の可視化 実現のために 必要な組織施策 ⼈増えすぎて良くわからん...
まだ先だし変化も⼤きい から具体性が... テーマが多すぎて どれから⼿をつければ...
37 今の組織状態 の把握 このそれぞれに対するfreeeのアプローチ事例をご紹介 ⽬指したい 組織状態 の可視化 実現のために 必要な組織施策 事例①
Engineer Success ダッシュボード 事例② 3年分の開発組織のポートフォリオ
38 まずはこちらのアプローチ ⽬指したい 組織状態 の可視化 実現のために 必要な組織施策 今の組織状態 の把握 事例①
Engineer Success ダッシュボード
39 ユーザ理解 調査‧分析 - freeeでの事例① 「Engineer Success ダッシュボード」の作成 ◦
取り扱っているデータ 1. 基本情報や評価などの定量データ 2. 対話やサーベイ等による定性データ 3. 開発チーム共通の役割定義を元にした can/will/expect ◦ これらのデータを掛け合わせて、あらゆる角度から分析できる ➢ いわゆるタレマネを本気でやっている状態
40 「Engineer Success ダッシュボード」の作成、活用 イメージしやすいように私 (takeda)というエンジニアを例に説明
41 takeda ① 基本情報や評価などの定量データ • 基本的な社員情報 ◦ 在籍年数 ◦
報酬 ◦ 所属の変遷 など • 評価情報 ◦ Qごとの評価 ◦ 入社からのグレードの変遷 など
42 takeda ② 対話やサーベイ等による定性データ • 対話による情報 (※共有範囲は非常に限定的 ) ◦ 新規入社メンバー全員との入社
2on1 ▪ with VPoE & successメンバー ◦ VPoEとしての日常的な観察、うろうろ など • サーベイによる情報 ◦ コンディション (体調、メンタル ) ◦ 本人視点での組織評価、わくわく感の変遷 など
43 takeda ③ 開発組織共通の役割定義を元にした can/will/expect • can / 本人+マネージャー の認識
◦ 既に実行できるロール、ラダー • will / 本人の意思 ◦ 今後目指したいロール、ラダー • expect / マネージャーが設計 ◦ チームや会社としての期待値として 今後担っていって欲しいロール、ラダー
44 ※ ここは少しコンテクストが深いので、補足 freeeの開発組織では ⼈、チーム、プロダクトが増えていき 開発において求められる仕事や役割が多様化し、複雑に。
45 Engineer Successチームが主体となり freeeで求められるロール定義とラダーの明⽂化を進め freee内で役割分担を語る際の「共通⾔語」とした
46 PdL Product Lead 役割、ロール EM Engineering Manager TL Technical
Lead IC Individual Contributor インパクトを出す 主な領域 プロダクト 組織‧⼈材 技術 技術 ※卓越した専⾨性 インパクトを出す 主なアプローチ チームで チームで チームで 主に個⼈で
47 [余談] 価値提供に責任を持つロールめちゃくちゃ盛り上がっていますが freeeでも2023年頃からこのロール(PdL)がプロダクト開発のコアになっています。 https://speakerdeck.com/niwatakeru/about-product-engineer https://speakerdeck.com/shnjtk/layerx-improve-development-pr oductivity-of-product-engineers
48 各ロールに求められる責務の概要
49 各ロールに求められる 責務の詳細、責任の段階
50 たとえばこんな使い⽅ Middle EM Middle PdL Junior PdL(若⼿エンジニア) x 2
新規プロダクト開発チームを組成する際に必要な構成を表現
51 たとえばこんな使い⽅ Middle EM Middle PdL Junior PdL(若⼿エンジニア) 新規プロダクト開発チームを組成する際に必要な構成を表現
52 takeda ③ 開発組織共通の役割定義を元にした can/will/expect に具体的なパラメータを当てはめるとこういうイメージ • can /
本人+マネージャーの認識 ◦ Middle PdL, Junior EM を担当できる • will / 本人の意思 ◦ 今後 Senior PdL を目指していきたい • expect / マネージャーが設計 ◦ 今後 Senior PdL として活躍して欲しい
53 各メンバーに関する人事データが一元的に集まっている状態 もちろん横断的な分析も可能 (セグメンテーション、傾向把握など ) ③ 開発組織共通の役割定義を元にした can/will/expect ①
基本情報や評価などの定量データ ② 対話やサーベイ等による定性データ
54 ロールとラダーの分布(=組織のケイパビリティ) と そのロールの体験、コンディション PdL EM TL IC 例えば、このダッシュボードがあるとこういうことができる #1
junior middle 戦略理解、納得感 ワクワク感 体調
55 PdL EM 新卒⼊社者の成⻑状況とキャリアイメージの把握 PdL EM TL IC 例えば、このダッシュボードがあるとこういうことができる #2
FY23 新卒⼊社 can will
56 ユーザ理解 調査‧分析 のポイント • 近道は意外とない。一次情報から触れていき、把握していくことが大事 ◦ 土台を作るまでは大変だが、メンバー 1人1人の解像度をできる限り上
げ流努力を惜しまない。これが後々の意思決定の質に直結する。 • 定量と定性、両面のデータをミックスして使う ◦ 相手は人なので、定量データだけでは見えない行間も多い • 継続的にいつでもこのデータを参照できるようにしておく ◦ 組織的な意思決定をする際に必ず側に置いておき根拠を持つ
57 今の組織状態 の把握 次はこちらのアプローチ (※これを先ほどのダッシュボードと組み合わせると超強⼒) ⽬指したい 組織状態 の可視化 実現のために 必要な組織施策
事例② 3年分の開発組織のポートフォリオ
58 ユーザ理解 調査‧分析 - freeeでの事例 ② 「開発組織のポートフォリオ」の作成 ◦ 現在〜3年後までの組織構成の内訳の可視化
1. 組織全体の人数 2. (先述の)ロール、ラダーの分布、人数 3. 各属性(例えば JP, global や 新卒, 中途 など)の分布、人数 4. 他にも多数の切り口で具体的な人数と割合をシミュレート ◦ これを毎年事業状況に応じてアップデートし続ける。
59 事業やプロダクトの計画から逆算した数字 + 開発組織としてありたい像の意思ごめ サンプル(データはダミー、項⽬は多少リアル)
60 ユーザ理解 調査‧分析 のポイント • リアルな状況を織り込みつつも、縮こまらず理想像をイメージする ◦ 現実的な案に落としていくといつの間にか保守的になりすぎる
▪ +現実的すぎるとシンプルに面白くない。 ◦ 開発的な理想を考えイメージを広げる • このイメージは経営メンバーと認識を合わせ続ける ◦ これは開発組織への将来的な投資イメージそのもの ▪ ここがずれていると、今後の事業やプロダクトに対する認識自体 がずれたまま進んでしまう可能性がある。
61 今の組織状態 の把握 ここまで⼟台ができれば、意思決定はかなりしやすくなる ⽬指したい 組織状態 の可視化 Engineer Success ダッシュボード
3年分の開発組織のポートフォリオ
62 ここまで⼟台ができれば、意思決定はかなりしやすくなる この前後のGAPはなにか どうやったら埋めていけるか を考えればOK 👍 Engineer Success ダッシュボード 3年分の開発組織のポートフォリオ
今の組織状態 の把握 ⽬指したい 組織状態 の可視化
63 freeeでの使い⽅の⼀例(リアルなやつ) • FY27の組織&プロダクトのスケール見据えると このままでは Middle EMがxx人、Senior PdLがxx人足りない!
◦ willに該当ロールを挙げている人の成長支援を整えよう ◦ 採用計画、 JDをこのGAP、ロール定義を元にアップデートしよう ◦ (ちなみにwill/canを踏まえると異動調整はめっちゃスムーズ )
64 freeeでの使い⽅の⼀例(リアルなやつ) • グレードxxになると次のグレードに上がる平均期間が大幅に伸びている ◦ この層に対して効果的なチャレンジアサインができているのか ▪ 評価キャリブレの際に次のアサインまで具体的に話そう
65 実はここまでに書いた意思決定の⼟台が作れると この後の「実⾏&評価」はかなり進めやすくなります。 なので、今回はさらりとポイントだけ紹介します。
66 ①ユーザ理解 調査‧分析 ③設計‧実⾏ ②要求定義 ④評価
67 • 必ず前フェーズの結果を元にした仮説を持って進める ◦ 組織テーマは無限に湧いてくるので、選択と集中が超⼤事 • スモールスタートする ◦ 制度や組織の話になると何故かいきなり⼤きくなりがち ◦
プロダクトと同じで、実際やってみないと分からないこと多い ▪ 特定のチーム、部署でプロトタイピングするなど⼯夫する 設計、実⾏フェーズのポイント
68 ①ユーザ理解 調査‧分析 ③設計‧実⾏ ②要求定義 ④評価
69 • 感覚だけではなく、必ずデータをしっかり⾒る ◦ ここまでに意思決定の基盤ができていれば、そこに必ず影響がある (例えば先述の Engineer Success ダッシュボードに現れてくる) ◦
むしろそういうデータドリブンなサイクルが回るような設計にしておく • 現実に向き合い、どんどんブラッシュアップする ◦ 組織的な取り組みは思ったより成果が出ないことも多い ◦ スモールに試しつつ、どんどん改善していく 評価フェーズのポイント
# まとめ
プロダクト開発と組織作りは⾮常に近しく その概念を応⽤することで より良い意思決定に繋げることができる
プロダクト開発と組織作りは近しい ↓
プロダクト開発と組織作りは近しい ↓ 良いプロダクトを作れる組織は 良い組織も作れるはず(逆も然り)
74 ご清聴ありがとうございました!