devsumi-2024-summer - Speaker Deck

Slide 1

Slide 1 text

オーナーシップは誰のものか   プロダクトマネージャーに頼らないプロダクトマネジメントへの挑戦     2024/07/24 Developers Summit 2024 Summer  

Slide 2

Slide 2 text

自己紹介  - onigra  - 鈴木雄大（Takehiro Suzuki）a.k.a yudai   - Classi株式会社プロダクト本部副本部長プログラマ   - X（Twitter）@onigra_   - Shinjuku.rb 3代目オーガナイザー  

Slide 3

Slide 3 text

前回までのあらすじ  

Slide 4

Slide 4 text

前回までのあらすじ       - 2020年  - Classiで発生した2つの問題を繰り返さないために我々が取り組んでいること   - セキュリティインシデントと大規模障害を経てClassiは開発組織をどう変化させたのか   -  

Slide 5

Slide 5 text

前回までのあらすじ       - 2021年  - Developers Summit 2021   - 全国一斉休校によって教育プラットフォームの「Classi」に起こった大障害〜サービス・組織をどう変化させたのか〜   - 2021年Classiに起こった変化の振り返り  

Slide 6

Slide 6 text

GOAL & NOT GOAL   - GOAL（狙っていること）   - 自分がプロダクト開発や組織運営を行う中で悩んだことや実体験をもとに、試行錯誤したり、向き合った課題の内容を共有します   - エンジニアとしてプロダクト開発や組織運営に関わる中でモヤモヤを感じている方に、何か得るものがあれば幸いです  

Slide 7

Slide 7 text

GOAL & NOT GOAL   - NOT GOAL（狙っていないこと）   - プロダクトマネージャーという職能を否定するものではない   - また、対立を煽るものでもない   - 特定の個人を貶めるものではない   - 本発表で話した内容を「正解」として他者に求めるものではない  

Slide 8

Slide 8 text

前回までのあらすじ   - 2020年、2021年はサービスの安定稼働のための開発に全力を尽くした   - 結果、Classiはそう簡単に落ちないサービスになった  

Slide 9

Slide 9 text

一方で、売上が犠牲になった  

Slide 10

Slide 10 text

一方で、売上が犠牲になった       - 当然だが、それが続いては事業は立ち行かなくなるので、2022年は売上を上げるための開発も積極的に行う  - それを目指した組織変更も行なった   - チームトポロジーを参考に新組織の編成を考えた話  

Slide 11

Slide 11 text

2022年はじまってしばらく経ち...       - 相談がひたすら発生するようになった  

Slide 12

Slide 12 text

相談の内容       - 人が足りないので足して欲しい   - 事業目標達成できないのでエンジニアを採用・異動してほしい   - 優先順位がつけられないので判断してほしい  

Slide 13

Slide 13 text

「人が足りない」を深掘りすると       - 無理のある計画   - 生産能力に対してやることが多い   - 実現可能性の検証と合意がされていない   - トラブルや想定外の事象に対する計画の変動が考慮されていない  

Slide 14

Slide 14 text

「優先順位がつけられないので判断してほしい」を深掘りすると       - チームを横断する仕事が進まない   - 意思決定の競合やそれに伴うコミュニケーションのトラブルが発生し、上位の人間に相談が多発する 

Slide 15

Slide 15 text

当時の組織図      

Slide 16

Slide 16 text

ここで競合が起こっていた          

Slide 17

Slide 17 text

マトリクス組織       - 機能別組織と事業部制組織を掛け合わせた組織   - 製品・市場への適応と機能統合によるメリットの両方盛り込む   - 大きな意思決定のたびに、製品・市場の要求と機能部門の要求が対立する可能性があり、そのたびごとにどちらの軸を優先するか、トップが意思決定を行う   - ダイナミックに2つの要求をバランスさせる意図を持ってマトリクス組織は採用される   - 実際は製品・市場への適応が優先されるケースが多い印象   - 引用: 組織デザイン 

Slide 18

Slide 18 text

マトリクス組織の問題点       - マトリクス組織は機能部門長と製品・市場マネージャーのパワーバランスの取り方にも考慮が必要  - 妥協や問題回避が行われた場合、問題は解決せずに現場の不満がたまる   - 問題直視も強権も期待できない組織でマトリクス組織を設計すると、問題解決のほとんどをミドル（中間管理職）が行い続けることになる   - 引用: 組織デザイン 

Slide 19

Slide 19 text

意思決定の競合       - 競合はあって当然だが、要求を集約し、検査して合意に至ることができない   - 広い視野のビジネス目標ではなく、チームの内部目標に集中してしまう  

Slide 20

Slide 20 text

考えられるソリューション       - 俺が意思決定の競合を解決する  

Slide 21

Slide 21 text

問題は認識できたが       - 越権行為になることを懸念   - ハレーションが発生し、退職につながる可能性も高い   - 何より、自分自身がプログラマとしてやりたい仕事ではない   - 当時、ずっと葛藤していた  

Slide 22

Slide 22 text

当時のチャットログ      

Slide 23

Slide 23 text

さらにトラブルが起こる  

Slide 24

Slide 24 text

さらにトラブルが起こる       - 当時進めていた機能開発のプロジェクトが炎上   - 事業計画上重要な位置付けにあった  

Slide 25

Slide 25 text

最初に相談を受けた時の感想   - はいはいスコープ調整スコープ調整  

Slide 26

Slide 26 text

と思っていたが…   - スコープ調整が不可能なことがわかってきた  

Slide 27

Slide 27 text

掘り下げると…   - ビジネス要求の実現可能性が考慮されないまま、リリース日だけ決まっていた  

Slide 28

Slide 28 text

ビジネス要求の検証と合意ができていない   - ビジネスとエンジニアリングの3wayハンドシェイク   - 結果なんとかしたが、消耗が激しく、組織に対する不信感を持つメンバーも増え、ダメージが大きかった 

Slide 29

Slide 29 text

以上の出来事から   - 今はプロダクトをマネジメントできていない   - このままではまともなプロダクト開発はできない   - まともなプロダクト開発ができる組織になるには、根本から何か変える必要がある  

Slide 30

Slide 30 text

決心した  - ハレーション覚悟で組織もプロセスも変えることを決心した  

Slide 31

Slide 31 text

これらの問題をまとめて解決するために考えたこと  - プロダクト組織、営業組織、CS組織、全ての組織が同じ目標を目指す状態   - ビジネス要求の実現可能性を検査し、合意してプロダクトの意思決定を行う仕組み  

Slide 32

Slide 32 text

プロダクト組織と営業組織が同じ目標を目指せる状態  

Slide 33

Slide 33 text

答えは単純   - 「売上・利益目標の達成」を全ての部署の目標にすればいい  

Slide 34

Slide 34 text

「売上・利益目標の達成」目指した時に、追うべき指標は何か？ 

Slide 35

Slide 35 text

これも単純   - 契約継続率  - 新規顧客獲得数 

Slide 36

Slide 36 text

ビジネス要求の実現可能性を検査し、合意してプロダクトの意思決定を行う仕組み  

Slide 37

Slide 37 text

プロダクトマネジメントトライアングル  

Slide 38

Slide 38 text

考えていたこと   - プロダクトの意思決定を行うために必要な専門性と知識を持った専門家が集まり、意思決定を行える状態  - 専門家がそれぞれの専門性を用いて要求の検証を行い、合意を行う  

Slide 39

Slide 39 text

答えになった「プロダクトボード」というアイディア   - チーム横断でサービス全体を舵取りするプロダクトボードの話  

Slide 40

Slide 40 text

プロダクトボード   - 「プロダクトの意思決定を行うための専門性と知識を持った人が集まり、プロダクトの意思決定を行う組織」そのものだった   - プロダクトボードには営業の専門家、カスタマーサポートの専門家、エンジニアリングの専門家、運用の専門家、デザインの専門家、などに参加してもらっている   - 自分はエンジニアリングの専門家として参加している   - 組織図上で上位にあるマネジメントチームではない  

Slide 41

Slide 41 text

2023年はこの体制でいくことにした   - プロダクト本部の誕生と組織変更の狙い  

Slide 42

Slide 42 text

やってみて   - とにかく話が早くなった   - 「こういう売り方をしたいからこういうことはできないか」という話が全て集まるようになった   - 「誰々に確認してみます」みたいなことが減った  

Slide 43

Slide 43 text

結果  - 定量  - 会場限定  - 定性  - 会場限定 

Slide 44

Slide 44 text

ネガティブな出来事   - 会場限定 

Slide 45

Slide 45 text

大変なこと  

Slide 46

Slide 46 text

プロダクトボードが承認機関と見られがち   - 確かに承認機関の側面はある   - 実際にリーダー層が多くアサインされている   - 繰り返すが、組織図上で上位にあるマネジメントチームではない  

Slide 47

Slide 47 text

自分にタフな意思決定が求められる構造は変わっていない   - さすがに限界がある   - HRBP（Human Resource Business Partner）の能力が必要   - 意思決定に絡めるリーダー層を徐々に増やしていくしかない  

Slide 48

Slide 48 text

自分に「お伺い」を立てないと新しいことができない状態になっていないか   - 自分が開発組織の生産能力以上にやることが投入されないように、防護壁になっている   - 不健全なヒエラルキーを産んでいないか   - 技術でビジネスを引っ張る状態になりたい   - やはり最後の拠り所は技術力  

Slide 49

Slide 49 text

まとめ 

Slide 50

Slide 50 text

まとめ  - Classiはプロダクトと事業のコントロールができていなかった   - 原因は主に3つ  - 営業組織とプロダクト組織が同じ事業目標を見れていない   - 組織間の意思決定の競合が解決できない   - ビジネス要求の実現可能性が検証されていない   - 解決するために行ったことは2つ   - 営業組織とプロダクト組織は同じ事業目標を設定する   - ビジネス要求の実現可能性を検査し、合意してプロダクトの意思決定を行う会議体を作る   - そこにはプロダクトの意思決定を行うために必要な専門性と知識を持った人間が参加する 

Slide 51

Slide 51 text

注意点  - たぶんプロダクトボードという体制だけを真似してもうまくいきません   - 部屋の中の象（The elephant in the room）に向き合い続ける覚悟が必要   - Classiには「エンジニアがやばいって言ってるとやばいんだな」と経営陣が理解してくれる土壌もある  - 最終的には気合いと勢いと覚悟  

Slide 52

Slide 52 text

オーナーシップは   誰のものだったのか？  

Slide 53

Slide 53 text

オーナーシップが足りないのは自分だった   - 意思決定を行うための知識や専門性が足りないのであれば、自分が行えばいい   - プロダクトマネジメントはプロダクトマネージャーだけが行うものではない   - プロダクトの意思決定を他人に押し付けるのをやめた   - 「それはプロダクトマネージャーが決めることだ」という態度を取るのをやめた   - オーナーシップは誰が持ってもいい   - 役割、職能は関係ない  

Slide 54

Slide 54 text

To be continued   - 今プロダクトボードは、全員がプロダクトオーナーシップを持って運営していると感じている  

Slide 55

Slide 55 text

これらの事象には一人では立ち向かえなかった   - Classiのエンジニア組織は時間をかけて、チームでマネジメントに取り組める状態を作り続けている  - この積み重ねが無ければ乗り越えられなかった   - 当時、議論を重ねて一緒に課題に立ち向かってくれたClassiのエンジニア組織のマネージャーたちにはこの場を借りて感謝申し上げます  

Slide 56

Slide 56 text

参考資料  - チーム横断でサービス全体を舵取りするプロダクトボードの話   - 株式会社エスエムエス TECH BLOG   - ビジネスとエンジニアリングの3wayハンドシェイク   - Marginalia  - 書籍「組織デザイン」読書メモ   - onigra.github.io  - 組織デザイン  - 沼上幹 (著)  - 最強の戦略人事  - リード・デシュラー (著), クレイグ・スミス (著), アリソン・フォン・フェルト (著), 土井哲 (翻訳)   - スクラム導入後にアジリティが減少してしまう理由   - MJ (Michael James)  - ザ・ゴール  - エリヤフ・ゴールドラット (著)  