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

devsumi-2024-summer

onigra
July 23, 2024

 devsumi-2024-summer

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

onigra

July 23, 2024
Tweet

More Decks by onigra

Other Decks in Business

Transcript

  1. 自己紹介
 - onigra
 - 鈴木雄大(Takehiro Suzuki)a.k.a yudai 
 - Classi株式会社

    プロダクト本部 副本部長 プログラマ 
 - X(Twitter)@onigra_ 
 - Shinjuku.rb 3代目オーガナイザー 

  2. 前回までのあらすじ 
 
 
 - 2020年
 - Classiで発生した2つの問題を繰り返さないために我々が取り組んでいること 
 -

    セキュリティインシデントと大規模障害を経てClassiは開発組織をどう変化させたのか 
 - 

  3. 前回までのあらすじ 
 
 
 - 2021年
 - Developers Summit 2021

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

  4. GOAL & NOT GOAL 
 - GOAL(狙っていること) 
 - 自分がプロダクト開発や組織運営を行う中で悩んだことや実体験をもとに、試行錯誤した

    り、向き合った課題の内容を共有します 
 - エンジニアとしてプロダクト開発や組織運営に関わる中でモヤモヤを感じている方に、何 か得るものがあれば幸いです 

  5. GOAL & NOT GOAL 
 - NOT GOAL(狙っていないこと) 
 -

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

  6. 「人が足りない」を深掘りすると 
 
 
 - 無理のある計画 
 - 生産能力に対してやることが多い 


    - 実現可能性の検証と合意がされていない 
 - トラブルや想定外の事象に対する計画の変動が考慮されていない 

  7. マトリクス組織 
 
 
 - 機能別組織と事業部制組織を掛け合わせた組織 
 - 製品・市場への適応と機能統合によるメリットの両方盛り込む 


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

  8. マトリクス組織の問題点 
 
 
 - マトリクス組織は機能部門長と製品・市場マネージャーのパワーバランスの取り方にも考慮が必 要
 - 妥協や問題回避が行われた場合、問題は解決せずに現場の不満がたまる 


    - 問題直視も強権も期待できない組織でマトリクス組織を設計すると、問題解決のほとんどをミ ドル(中間管理職)が行い続けることになる 
 - 引用: 組織デザイン

  9. 問題は認識できたが 
 
 
 - 越権行為になることを懸念 
 - ハレーションが発生し、退職につながる可能性も高い 


    - 何より、自分自身がプログラマとしてやりたい仕事ではない 
 - 当時、ずっと葛藤していた 

  10. 自分にタフな意思決定が求められる構造は変 わっていない 
 - さすがに限界がある 
 - HRBP(Human Resource Business

    Partner)の能力が必要 
 - 意思決定に絡めるリーダー層を徐々に増やしていくしかない 

  11. まとめ
 - Classiはプロダクトと事業のコントロールができていなかった 
 - 原因は主に3つ
 - 営業組織とプロダクト組織が同じ事業目標を見れていない 
 -

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

  12. 注意点
 - たぶんプロダクトボードという体制だけを真似してもうまくいきません 
 - 部屋の中の象(The elephant in the room)に向き合い続ける覚悟が必要

    
 - Classiには「エンジニアがやばいって言ってるとやばいんだな」と経営陣が理解してくれる土壌も ある
 - 最終的には気合いと勢いと覚悟 

  13. 参考資料
 - チーム横断でサービス全体を舵取りするプロダクトボードの話 
 - 株式会社エスエムエス TECH BLOG 
 -

    ビジネスとエンジニアリングの3wayハンドシェイク 
 - Marginalia
 - 書籍「組織デザイン」読書メモ 
 - onigra.github.io
 - 組織デザイン
 - 沼上 幹 (著)
 - 最強の戦略人事
 - リード・デシュラー (著), クレイグ・スミス (著), アリソン・フォン・フェルト (著), 土井 哲 (翻訳) 
 - スクラム導入後にアジリティが減少してしまう理由 
 - MJ (Michael James)
 - ザ・ゴール
 - エリヤフ・ゴールドラット (著)