devsumi-2024-summer

Developers Summit 2024 Summer 発表資料 公開版
https://event.shoeisha.jp/devsumi/20240723/session/5135

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

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

3. 前回までのあらすじ 

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

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

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

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

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

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

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

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

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

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

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

15. 当時の組織図 
 
 

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

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

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

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

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

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

22. 当時のチャットログ 
 
 

23. さらにトラブルが起こる 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

45. 大変なこと 

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

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

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

49. まとめ

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

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

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

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

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

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

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