Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
組織作りに「プロダクト開発のエッセンス」 を取り入れ、不確実性に向き合い続ける / Incor...
Search
freee
July 23, 2024
0
2.8k
組織作りに「プロダクト開発のエッセンス」 を取り入れ、不確実性に向き合い続ける / 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 FY24 Q2
freee
4
9.5k
freeeのモバイルエンジニアについて
freee
1
210
10分でわかるfreeeのQA
freee
1
8.3k
10分でわかるfreee エンジニア向け会社説明資料
freee
18
530k
freeeの福利厚生と働き方
freee
1
66k
品質の高速フィードバックへの取り組み / Commitment to Fast Quality Feedback
freee
4
1.1k
LGBTQ__support_WOMEN_女性として働くということ_DEI
freee
2
510
QAエンジニア_Summer Internship説明会(26卒)
freee
0
270
権限管理基盤の開発とQAの今 / Authority Management Infrastructure Development and QA Now
freee
1
3.6k
Featured
See All Featured
Making Projects Easy
brettharned
116
6k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
2
290
Raft: Consensus for Rubyists
vanstee
137
6.7k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Optimizing for Happiness
mojombo
376
70k
Reflections from 52 weeks, 52 projects
jeffersonlam
347
20k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.6k
The Invisible Side of Design
smashingmag
298
50k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.3k
Visualization
eitanlees
146
15k
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 ご清聴ありがとうございました!