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
630
意外と簡単!「この商品を買った人はこんな商品も買っています」を作ってみよう
yutaishizaka
3
740
Other Decks in Business
See All in Business
Ampersand Company Profile
cuebicventures
PRO
0
230
Company Introduction Slides
recruiting
0
1.1k
会社紹介資料
ldf_tech
1
320
スタートアップのマネージャーに役立つ視座/A useful perspective for startup managers
dskst
6
1.2k
Godot 会社紹介資料(開発職向け) / Godot Pitch Deck
godot
0
1.1k
急成⻑スタートアップで働くことで得られるもの / 株式会社IVRy(社内LT会)
miyashino
0
1.2k
HireRoo Culture Deck(日本語)
kkosukeee
1
24k
会社案内資料
mkengineering
1
160
【DearOne】Dear Newest Member
hrm
2
6k
M&A Cloud Advisory Partners 採用ピッチブック
macloud
1
13k
バイセルのものさし(Ver. 1.1)
buyselltechnologies
0
190
【metimo】「『似合う』を楽しもう。」
hinalin
0
560
Featured
See All Featured
Designing for Performance
lara
604
68k
Embracing the Ebb and Flow
colly
84
4.5k
The Language of Interfaces
destraynor
154
24k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
[RailsConf 2023] Rails as a piece of cake
palkan
52
4.9k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Making Projects Easy
brettharned
115
5.9k
Scaling GitHub
holman
458
140k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
16
2.1k
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