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
ProductZine webiner資料
Search
yuta ishizaka
October 28, 2021
Business
0
54
ProductZine webiner資料
noteの一人目PMが語る「自律分散型チーム」の作り方
yuta ishizaka
October 28, 2021
Tweet
Share
More Decks by yuta ishizaka
See All by yuta ishizaka
s-dev talks #2 〜チームビルディング〜 LT資料
yutaishizaka
3
620
業務ハックのためのPFDのすゝめ
yutaishizaka
1
290
スタートアップ2人目エンジニアのリアル
yutaishizaka
2
430
product_kaizen_night
yutaishizaka
1
640
意外と簡単!「この商品を買った人はこんな商品も買っています」を作ってみよう
yutaishizaka
3
740
Other Decks in Business
See All in Business
KRAF Impact Report 2024(日本語版)
kraf
0
210
enechain company deck
enechain
PRO
8
94k
ネクストビートコーポレートガイド/corporate-guide
nextbeat
3
77k
成功をつなげる プロジェクトマネジメントの探求 / Exploring Project Management to Continuous Success
tunepolo
0
170
決算審査意見書自動作成ツール 改良プロジェクト
tokyo_metropolitan_gov_digital_hr
0
290
なぜ施策優先度を意思決定しなければならないのか? 経験から得た要因と対策
mkitahara01985
2
200
freee + Product Design FY24 Q2
freee
4
9.4k
経験やセンスに頼らずに成果を出すためのチームマネジメント実践ガイド / Team Management Without Relying on Experience or Intuition
happy_imafuku
4
11k
Azure Functions HTTPトリガーにおけるタイムアウトでハマったこと
recruitengineers
PRO
2
150
概要
_connect
0
690
株式会社ワンコイングリッシュ 会社説明資料
oce_recruit
1
7.2k
Go See!で見つけるプロダクト開発の突破口とその実践法
ta0o_o0821
0
140
Featured
See All Featured
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
How to train your dragon (web standard)
notwaldorf
88
5.7k
VelocityConf: Rendering Performance Case Studies
addyosmani
326
24k
KATA
mclloyd
29
14k
Visualization
eitanlees
146
15k
The Cost Of JavaScript in 2023
addyosmani
45
7k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
Reflections from 52 weeks, 52 projects
jeffersonlam
347
20k
Automating Front-end Workflow
addyosmani
1366
200k
Docker and Python
trallard
42
3.1k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
32
2.7k
Transcript
None
note inc. noteの一人目PMが語る 「自律分散型チーム」の作り方 note株式会社 プロダクトマネージャー 石坂優太
3 新 卒でメーカーの「パイオニア」にソフトウェアエンジニアとして入 社し、7年ほ ど、カーナビゲーションシステムの開発やプロジェクトマネジメントに従事。その 後 、 求 人 サービスの「ビズリーチ」、リテールテックのスタートアップでエンジニ
ア・プロダクトマネージャー・マーケティング等を経験し、2019/5にnoteへエンジ ニアとして入社。2021/3ごろよりプロダクトマネージャーを担当。 プロダクトマネージャー 石坂優太
note inc. あらゆるクリエイターが文章やマンガ、写真、音声等のコンテンツを自由に投稿することができ、 ユーザーはそのコンテンツを楽しんで応援できるメディアプラットフォーム 4
note inc. 今日話すこと • 自律分散型チームとはなにで、どんなときに必要になるのか • noteでは具体的にどんな取り組み方で推進してきたのか •
発生した課題と、どう解決してきたか 5
note inc. 自律分散型チームとはなにで、 どんなときに必要になるのか 6
note inc. 自律分散型チームとはなにか 7 今日のウェビナーでは、 取り組むべき課題を自ら考え、決定し、実行するチーム を指します。
note inc. 自律分散型チームとはなにか(イメージ) 8 プロダクトオーナー ・事業目標の決定(Why) ・課題の特定(Why) ・ソリューションの検討(What)
チーム ・ソリューションのインプット(What) ・開発(How) プロダクトオーナー ・事業目標の決定(Why) チーム ・事業目標のインプット(Why) ・課題の特定(Why) ・ソリューションの検討(What) ・開発(How) これではない これ
note inc. 自律分散型チームはどんなときに必要か 9 • 一定規模以上の組織 ◦ ひとりの意思決定者でハンドリングできる規模を超えたとき ▪
別々の課題を解く複数のチームをつくる必要性が生じる • 変化が激しい事業環境 ◦ 小さな意思決定を状況に応じて日々高速に積み重ね、方向修正していく必要がある 環境 ◦ 達成したいことに対して、解くべき課題、適切な解き方が日々変わる
note inc. noteではなぜ自律分散型のチームが必要になったか? 10 • 主な要因は、組織の拡大 ◦ 2019/5 全社員で約40名、開発チーム約15名
◦ 2021/5 全社員で約150名、開発チーム約50名 ◦ サービスの成長にともない、2年間で3倍以上の規模になっているが、開発のやり方 にはほとんど変化がなかった • 大きなミッション(=達成のために組織規模が必要になる)を掲げていることと、変化の激し い事業環境に身をおいているため、もともと自律分散型の組織を志向してはいたが、現実 的に機能させるための仕組みの整備が追いついていない 状態
note inc. これまでの開発体制イメージ 11 プロダクトオーナー (CEO/CXO) プロダクトオーナーが PdMの役割を果たし、 アジャイルのスタイルで開発。 カイゼンチーム
短期的な機能開発 PJTチームA PJTチームB PJTチームC PJTチームD 中長期的な機能開発 プロダクトオーナーが 開発すべき機能を決定し、 機能ごとにPJTチームを組成。 PJTの進め方に迷いが生じた場合、逐一プ ロダクトオーナーと相談。
note inc. 課題 12 • CEO/CXOで意思決定可能なサイズを超えたことにより、下記のような問題が発生、また は予見できた ◦ 組織拡大するほど意思決定がボトルネックになり効率が落ちていくサイクルに陥る
▪ 人が増えても成果が増えない、ということが起きる ◦ 日々の細かな意思決定のオーバーヘッドが増え、実行スピードが低下したり、方針 が誤ったまま進んでしまうケースが増える ◦ 開発メンバーにとってストレスが高い状態になり、モチベーション悪化する ◦ これらの結果として、ミッション実現のスピードが落ち、会社およびプロダクトの競争 力が低下する
note inc. noteでは具体的にどんな 取り組み方で推進してきたのか 13
note inc. 自律分散型の組織をつくるポイント 14 • 前提、意思決定の質とスピードは 「知識」と「情報」でほぼ決まる ◦ 知識の例 ▪
課題に対して一般的にうまくいきやすい施策はなにか ▪ 施策の技術的な実現難易度はどの程度か ◦ 情報の例 ▪ いまの事業成績はどんな状況なのか ▪ 会社としてなにを重点課題と捉えているのか ◦ 意思決定がうまい人・チームというのは、この両方を高度に備えている人・チーム ◦ 組織全体に両方が手に入る状態を再現することが、自律分散型の組織をつくるポイント ▪ 意思決定に必要な知識を集約した体制をどうつくるか ▪ 自ら学習し知識をつけていくサイクルをどう構築するか ▪ 情報が、必要な人に適切な粒度できちんと届く状態をどう設計するか
note inc. 具体的にやった・やっていること 15 • 目標設計を変える ◦ タスクにアサイン→目標・課題にアサイン •
意思決定のツールを整える ◦ データ活用の強化 ◦ 情報流通の促進
note inc. 目標設計を変える:タスクにアサイン→目標・課題にアサイン 16 プロダクトオーナー PJT チームA プロダクトオーナー チームA 以前のアサイン
変更後のアサイン PJT チームB PJT チームC チームB チームC 機能Aの開発 機能Bの開発 機能Cの開発 課題Aの解決 課題Bの解決 課題Cの解決
note inc. 目標設計を変える:タスクにアサイン→目標・課題にアサイン 17 • 重要なのは、考える対象となるスコープが変わること ◦ 「タスクの達成」ではなく「課題の解決」に目を向ける ▪ 課題に目を向けることで、取得する知識・情報が変わる
▪ PJT単位でチームを解散しないため、課題領域に対する知識が個人とチームに積 み上がる ▪ 結果、だんだん意思決定がうまくなっていく
note inc. 意思決定のツールを整える:データ活用の強化 18 • データ活用の目的は、意思決定に重要な「知識」を自ら獲得できるツールになること ◦ 「仮説立て」「実行」「データによる結果事実の振り返り」のサイクルを回して、経験知識を蓄積していく ◦ これを繰り返していくことで、仮説立て・意思決定の速度・質が上がっていくことが重要
◦ 意思決定がうまい人は最初からうまいわけではなく、過去にこれを無数に繰り返してきたから意思決定がうまく なっている • 主にやったことはみっつ ◦ データによる事実と解釈を共有する場を増やす ▪ 事業のKPIをWeeklyで確認し議論する場の設置 ◦ 施策ごとに、結果をデータで判断する仕組みの導入 ▪ 企画ドキュメントフォーマットに項目として追加 ◦ データを触れる人を増やすための基盤整備 ▪ データを扱いやすくしていくことで、ハードル・苦手意識をなくす
note inc. 意思決定のツールを整える:情報流通の促進 19 • 意思決定には、情報が必要 • 特にnoteで課題となったのは、抽象度の高い情報は豊富だが、解像度の高い情報が不足している点 ◦ 足りている情報
▪ ミッション(長期目標) ▪ グロースサイクル(基本指針となるKPIモデル) ◦ 足りていない情報 ▪ それぞれが取り組むべき短期目標 • 大きな目標の中で、自分自身は特にどの課題に注力するべきかという情報 • 小さな組織で中央集権的に意思決定する体制では問題にならないが、自律的に判断していくた めには必要 ▪ 事業状況 • 事業として特に課題となっていて取り組むべき課題はなにかという情報 • PMがハブとなって、短期目標の設計と、事業状況のチームへの共有を推進
note inc. 発生した課題と、 どう解決してきたか 20
note inc. 取り組んでいく過程で発生した課題 21 • 意思決定の質・スピードと権限移譲のバランス難しい問題 • アジャイルチームに対する知見、姿勢の全社浸透問題
• 組織構造変化による、一時的な負荷増
note inc. 意思決定の質・スピードと権限移譲のバランス難しい問題 22 • スタートアップの初期は創業者および経営メンバーが意思決定することが多く、深いドメイン知 識や経験知識から、意思決定の質・スピードが優れている場合が多い • いきなり権限を大きく移譲すると、質・スピードの面でギャップが大きくなりやすい ◦
とくに、意思決定に慣れた経験豊富なメンバーが社内に多くない場合は注意 • 短期的にはもともとの意思決定者と合議の形式をとるほうがいい場合もある ◦ 権限移譲は目的ではなく手段 なので、権限移譲そのものに固執しない ◦ もともとの意思決定者に伴走してもらったほうが学習が早く進むなら、それを選ぶほうが良い ◦ 学習が進んできたら、移譲する範囲を増やせばよい
note inc. 自律分散型の組織に関する知見、姿勢の全社浸透問題 23 • 一般的に、自律分散型のチーム体制に変える場合は、各開発メンバーの取り扱う業務範囲は 広がる ◦ 開発だけでなくそもそもどの課題に取り組むべきかにも関わるようになる ◦
どう振る舞うべきか迷う人、チームも出てくる • 変える理由についてしっかり説明し、目指すスタイルについて示す必要がある ◦ 会社をとりまく事業環境、ミッションの性質と紐付けて、どういう組織になる必要があるか ら何をするのか、しっかり説明する ◦ 具体的な事例を示して、全社での共通知識化する ▪ どう動くべきか迷ったときに自身で学習できるようにする
note inc. 組織構造変化による、一時的な負荷増 24 • 中央集権的な意思決定から自律分散型の意思決定に変える場合、たいていは組織の形も変 える必要があり、エンジニア・デザイナー・PMといった職種の必要人数が変化する • noteでは、主にデザイナーとPMが不足した ◦
エンジニア5-6人に対し、デザイナー1、PM1未満ぐらいのバランスでスタート ▪ 理想的には、エンジニア3、デザイナー1、PM1ぐらいのバランスでチームを構成し たい ◦ とはいえ、先に組織を変えてしまわなければメンバーを揃える力学も働かないので、十 分揃ってなくても変えてしまう決断もときには必要 ◦ 組織設計に合わせて採用強化など行い、解消しつつある
note inc. まとめ 25
note inc. まとめ 26 • 自律分散型のチームは、一定規模以上の組織、変化の大きい事業環境の場合に必要に なる • 自律分散型の組織をつくるポイントは、組織全体の「知識」と「情報」を引き上げること
◦ 学習できる仕組みをつくる ◦ 意思決定に必要な情報が手に入るようにする
None