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

ProductZine webiner資料

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.

ProductZine webiner資料

noteの一人目PMが語る「自律分散型チーム」の作り方

Avatar for yuta ishizaka

yuta ishizaka

October 28, 2021
Tweet

More Decks by yuta ishizaka

Other Decks in Business

Transcript

  1. 3 新 卒でメーカーの「パイオニア」にソフトウェアエンジニアとして入 社し、7年ほ ど、カーナビゲーションシステムの開発やプロジェクトマネジメントに従事。その 後 、 求 人 サービスの「ビズリーチ」、リテールテックのスタートアップでエンジニ

    ア・プロダクトマネージャー・マーケティング等を経験し、2019/5にnoteへエンジ ニアとして入社。2021/3ごろよりプロダクトマネージャーを担当。 
 
 
 プロダクトマネージャー 
 石坂優太

  2. note inc. 自律分散型チームとはなにか(イメージ)
 8 プロダクトオーナー ・事業目標の決定(Why) 
 ・課題の特定(Why) 
 ・ソリューションの検討(What)

    
 チーム ・ソリューションのインプット(What) 
 ・開発(How) 
 プロダクトオーナー ・事業目標の決定(Why) 
 チーム ・事業目標のインプット(Why) 
 ・課題の特定(Why) 
 ・ソリューションの検討(What) 
 ・開発(How) 
 これではない
 これ

  3. note inc. 自律分散型チームはどんなときに必要か
 9 • 一定規模以上の組織
 ◦ ひとりの意思決定者でハンドリングできる規模を超えたとき 
 ▪

    別々の課題を解く複数のチームをつくる必要性が生じる 
 • 変化が激しい事業環境
 ◦ 小さな意思決定を状況に応じて日々高速に積み重ね、方向修正していく必要がある 環境
 ◦ 達成したいことに対して、解くべき課題、適切な解き方が日々変わる 
 
 

  4. note inc. noteではなぜ自律分散型のチームが必要になったか?
 10 • 主な要因は、組織の拡大
 ◦ 2019/5 全社員で約40名、開発チーム約15名 


    ◦ 2021/5 全社員で約150名、開発チーム約50名 
 ◦ サービスの成長にともない、2年間で3倍以上の規模になっているが、開発のやり方 にはほとんど変化がなかった
 • 大きなミッション(=達成のために組織規模が必要になる)を掲げていることと、変化の激し い事業環境に身をおいているため、もともと自律分散型の組織を志向してはいたが、現実 的に機能させるための仕組みの整備が追いついていない 状態
 
 

  5. note inc. これまでの開発体制イメージ
 11 プロダクトオーナー (CEO/CXO) プロダクトオーナーが
 PdMの役割を果たし、
 アジャイルのスタイルで開発。
 カイゼンチーム

    短期的な機能開発 
 PJTチームA PJTチームB PJTチームC PJTチームD 中長期的な機能開発 
 プロダクトオーナーが
 開発すべき機能を決定し、
 機能ごとにPJTチームを組成。
 PJTの進め方に迷いが生じた場合、逐一プ ロダクトオーナーと相談。

  6. note inc. 課題
 12 • CEO/CXOで意思決定可能なサイズを超えたことにより、下記のような問題が発生、また は予見できた
 ◦ 組織拡大するほど意思決定がボトルネックになり効率が落ちていくサイクルに陥る 


    ▪ 人が増えても成果が増えない、ということが起きる 
 ◦ 日々の細かな意思決定のオーバーヘッドが増え、実行スピードが低下したり、方針 が誤ったまま進んでしまうケースが増える 
 ◦ 開発メンバーにとってストレスが高い状態になり、モチベーション悪化する 
 ◦ これらの結果として、ミッション実現のスピードが落ち、会社およびプロダクトの競争 力が低下する
 

  7. note inc. 自律分散型の組織をつくるポイント
 14 • 前提、意思決定の質とスピードは 「知識」と「情報」でほぼ決まる
 ◦ 知識の例
 ▪

    課題に対して一般的にうまくいきやすい施策はなにか 
 ▪ 施策の技術的な実現難易度はどの程度か 
 ◦ 情報の例
 ▪ いまの事業成績はどんな状況なのか 
 ▪ 会社としてなにを重点課題と捉えているのか 
 ◦ 意思決定がうまい人・チームというのは、この両方を高度に備えている人・チーム 
 ◦ 組織全体に両方が手に入る状態を再現することが、自律分散型の組織をつくるポイント 
 ▪ 意思決定に必要な知識を集約した体制をどうつくるか 
 ▪ 自ら学習し知識をつけていくサイクルをどう構築するか 
 ▪ 情報が、必要な人に適切な粒度できちんと届く状態をどう設計するか 

  8. note inc. 目標設計を変える:タスクにアサイン→目標・課題にアサイン
 16 プロダクトオーナー PJT チームA プロダクトオーナー チームA 以前のアサイン


    変更後のアサイン
 PJT チームB PJT チームC チームB チームC 機能Aの開発 機能Bの開発 機能Cの開発 課題Aの解決 課題Bの解決 課題Cの解決
  9. note inc. 意思決定のツールを整える:データ活用の強化
 18 • データ活用の目的は、意思決定に重要な「知識」を自ら獲得できるツールになること
 ◦ 「仮説立て」「実行」「データによる結果事実の振り返り」のサイクルを回して、経験知識を蓄積していく
 ◦ これを繰り返していくことで、仮説立て・意思決定の速度・質が上がっていくことが重要


    ◦ 意思決定がうまい人は最初からうまいわけではなく、過去にこれを無数に繰り返してきたから意思決定がうまく なっている
 • 主にやったことはみっつ
 ◦ データによる事実と解釈を共有する場を増やす
 ▪ 事業のKPIをWeeklyで確認し議論する場の設置
 ◦ 施策ごとに、結果をデータで判断する仕組みの導入
 ▪ 企画ドキュメントフォーマットに項目として追加
 ◦ データを触れる人を増やすための基盤整備
 ▪ データを扱いやすくしていくことで、ハードル・苦手意識をなくす

  10. note inc. 意思決定のツールを整える:情報流通の促進
 19 • 意思決定には、情報が必要
 • 特にnoteで課題となったのは、抽象度の高い情報は豊富だが、解像度の高い情報が不足している点
 ◦ 足りている情報


    ▪ ミッション(長期目標)
 ▪ グロースサイクル(基本指針となるKPIモデル)
 ◦ 足りていない情報
 ▪ それぞれが取り組むべき短期目標
 • 大きな目標の中で、自分自身は特にどの課題に注力するべきかという情報
 • 小さな組織で中央集権的に意思決定する体制では問題にならないが、自律的に判断していくた めには必要
 ▪ 事業状況
 • 事業として特に課題となっていて取り組むべき課題はなにかという情報
 • PMがハブとなって、短期目標の設計と、事業状況のチームへの共有を推進

  11. note inc. 意思決定の質・スピードと権限移譲のバランス難しい問題
 22 • スタートアップの初期は創業者および経営メンバーが意思決定することが多く、深いドメイン知 識や経験知識から、意思決定の質・スピードが優れている場合が多い
 • いきなり権限を大きく移譲すると、質・スピードの面でギャップが大きくなりやすい
 ◦

    とくに、意思決定に慣れた経験豊富なメンバーが社内に多くない場合は注意
 • 短期的にはもともとの意思決定者と合議の形式をとるほうがいい場合もある 
 ◦ 権限移譲は目的ではなく手段 なので、権限移譲そのものに固執しない 
 ◦ もともとの意思決定者に伴走してもらったほうが学習が早く進むなら、それを選ぶほうが良い 
 ◦ 学習が進んできたら、移譲する範囲を増やせばよい 

  12. note inc. 自律分散型の組織に関する知見、姿勢の全社浸透問題
 23 • 一般的に、自律分散型のチーム体制に変える場合は、各開発メンバーの取り扱う業務範囲は 広がる
 ◦ 開発だけでなくそもそもどの課題に取り組むべきかにも関わるようになる
 ◦

    どう振る舞うべきか迷う人、チームも出てくる
 • 変える理由についてしっかり説明し、目指すスタイルについて示す必要がある
 ◦ 会社をとりまく事業環境、ミッションの性質と紐付けて、どういう組織になる必要があるか ら何をするのか、しっかり説明する
 ◦ 具体的な事例を示して、全社での共通知識化する
 ▪ どう動くべきか迷ったときに自身で学習できるようにする

  13. note inc. 組織構造変化による、一時的な負荷増
 24 • 中央集権的な意思決定から自律分散型の意思決定に変える場合、たいていは組織の形も変 える必要があり、エンジニア・デザイナー・PMといった職種の必要人数が変化する
 • noteでは、主にデザイナーとPMが不足した
 ◦

    エンジニア5-6人に対し、デザイナー1、PM1未満ぐらいのバランスでスタート
 ▪ 理想的には、エンジニア3、デザイナー1、PM1ぐらいのバランスでチームを構成し たい
 ◦ とはいえ、先に組織を変えてしまわなければメンバーを揃える力学も働かないので、十 分揃ってなくても変えてしまう決断もときには必要
 ◦ 組織設計に合わせて採用強化など行い、解消しつつある