Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
devsumi-2024-summer
Search
onigra
July 23, 2024
Business
4
1.8k
devsumi-2024-summer
Developers Summit 2024 Summer 発表資料 公開版
https://event.shoeisha.jp/devsumi/20240723/session/5135
onigra
July 23, 2024
Tweet
Share
More Decks by onigra
See All by onigra
THE GOAL
onigra
3
64
第一種低層住居専用地域
onigra
0
230
jaws-ug-ecspresso-meetup-20230808
onigra
0
1.7k
ginza-ruby-kaigi-01
onigra
4
980
PHP-CS-FixerとかAtomとか
onigra
1
1.3k
プログラミング初心者でも始められるコミュニティへの参加と貢献
onigra
4
740
Techblog Deep Dive Meetup #1
onigra
0
1.8k
とある業務オペレーション自動化の話
onigra
0
960
about tsudura
onigra
0
250
Other Decks in Business
See All in Business
AIを活用した住家被害認定支援ツールの開発
tokyo_metropolitan_gov_digital_hr
0
570
三井物産グループのデジタル証券〜ホテル・イビス大阪梅田〜徹底解説セミナースライド(20241126)
c0rp_mdm
0
1k
デジタル人材EXPO展示資料
driven
0
110
20分で分かる!Control Towerが実現できる効率的なマルチアカウント管理
o2mami
0
290
【エンジニア採用】BuySell Technologies会社説明資料
buyselltechnologies
1
53k
【リクロマ株式会社】20241123_会社紹介資料
takahiro4545
0
460
kintoneを活用した緊急通行車両確認手続の迅速化
tokyo_metropolitan_gov_digital_hr
0
530
Theoria technologies:About Us
theoriatec2024
1
3.6k
21.11.2024 Nuevos formatos de comunicación entre distribuidores y comercializadoras de electricidad
neuroenergia
PRO
0
160
経験やセンスに頼らずに成果を出すためのチームマネジメント実践ガイド / Team Management Without Relying on Experience or Intuition
happy_imafuku
3
5k
20241129_A08_Copilotなしの生活が考えられなくなった件
ponponmikankan
1
1.8k
【エンジニア職】中途採用向け会社説明資料(テックファーム株式会社)
techfirm
0
4.1k
Featured
See All Featured
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.2k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Docker and Python
trallard
40
3.1k
A Tale of Four Properties
chriscoyier
157
23k
Unsuck your backbone
ammeep
669
57k
Being A Developer After 40
akosma
87
590k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
410
Done Done
chrislema
181
16k
Transcript
オーナーシップは誰のものか プロダクトマネージャーに頼らないプロダクトマネジメントへの挑戦 2024/07/24 Developers Summit 2024 Summer
自己紹介 - onigra - 鈴木雄大(Takehiro Suzuki)a.k.a yudai - Classi株式会社
プロダクト本部 副本部長 プログラマ - X(Twitter)@onigra_ - Shinjuku.rb 3代目オーガナイザー
前回までのあらすじ
前回までのあらすじ - 2020年 - Classiで発生した2つの問題を繰り返さないために我々が取り組んでいること -
セキュリティインシデントと大規模障害を経てClassiは開発組織をどう変化させたのか -
前回までのあらすじ - 2021年 - Developers Summit 2021
- 全国一斉休校によって教育プラットフォームの「Classi」に起こった大障害 〜サービ ス・組織をどう変化させたのか〜 - 2021年Classiに起こった変化の振り返り
GOAL & NOT GOAL - GOAL(狙っていること) - 自分がプロダクト開発や組織運営を行う中で悩んだことや実体験をもとに、試行錯誤した
り、向き合った課題の内容を共有します - エンジニアとしてプロダクト開発や組織運営に関わる中でモヤモヤを感じている方に、何 か得るものがあれば幸いです
GOAL & NOT GOAL - NOT GOAL(狙っていないこと) -
プロダクトマネージャーという職能を否定するものではない - また、対立を煽るものでもない - 特定の個人を貶めるものではない - 本発表で話した内容を「正解」として他者に求めるものではない
前回までのあらすじ - 2020年、2021年はサービスの安定稼働のための開発に全力を尽くした - 結果、Classiはそう簡単に落ちないサービスになった
一方で、売上が犠牲になった
一方で、売上が犠牲になった - 当然だが、それが続いては事業は立ち行かなくなるので、2022年は売上を上げるための開発も 積極的に行う - それを目指した組織変更も行なった
- チームトポロジーを参考に新組織の編成を考えた話
2022年はじまってしばらく経ち... - 相談がひたすら発生するようになった
相談の内容 - 人が足りないので足して欲しい - 事業目標達成できないのでエンジニアを採用・異動してほしい
- 優先順位がつけられないので判断してほしい
「人が足りない」を深掘りすると - 無理のある計画 - 生産能力に対してやることが多い
- 実現可能性の検証と合意がされていない - トラブルや想定外の事象に対する計画の変動が考慮されていない
「優先順位がつけられないので判断してほしい」 を深掘りすると - チームを横断する仕事が進まない - 意思決定の競合やそれに伴うコミュニケーションのトラブルが発生し、上位の人間に相談
が多発する
当時の組織図
ここで競合が起こっていた
マトリクス組織 - 機能別組織と事業部制組織を掛け合わせた組織 - 製品・市場への適応と機能統合によるメリットの両方盛り込む
- 大きな意思決定のたびに、製品・市場の要求と機能部門の要求が対立する可能性があり、 そのたびごとにどちらの軸を優先するか、トップが意思決定を行う - ダイナミックに2つの要求をバランスさせる意図を持ってマトリクス組織は採用される - 実際は製品・市場への適応が優先されるケースが多い印象 - 引用: 組織デザイン
マトリクス組織の問題点 - マトリクス組織は機能部門長と製品・市場マネージャーのパワーバランスの取り方にも考慮が必 要 - 妥協や問題回避が行われた場合、問題は解決せずに現場の不満がたまる
- 問題直視も強権も期待できない組織でマトリクス組織を設計すると、問題解決のほとんどをミ ドル(中間管理職)が行い続けることになる - 引用: 組織デザイン
意思決定の競合 - 競合はあって当然だが、要求を集約し、検査して合意に至ることができない - 広い視野のビジネス目標ではなく、チームの内部目標に集中してしまう
考えられるソリューション - 俺が意思決定の競合を解決する
問題は認識できたが - 越権行為になることを懸念 - ハレーションが発生し、退職につながる可能性も高い
- 何より、自分自身がプログラマとしてやりたい仕事ではない - 当時、ずっと葛藤していた
当時のチャットログ
さらにトラブルが起こる
さらにトラブルが起こる - 当時進めていた機能開発のプロジェクトが炎上 - 事業計画上重要な位置付けにあった
最初に相談を受けた時の感想 - はいはいスコープ調整スコープ調整
と思っていたが… - スコープ調整が不可能なことがわかってきた
掘り下げると… - ビジネス要求の実現可能性が考慮されないまま、リリース日だけ決まっていた
ビジネス要求の検証と合意ができていない - ビジネスとエンジニアリングの3wayハンドシェイク - 結果なんとかしたが、消耗が激しく、組織に対する不信感を持つメンバーも増え、ダメージが大 きかった
以上の出来事から - 今はプロダクトをマネジメントできていない - このままではまともなプロダクト開発はできない - まともなプロダクト開発ができる組織になるには、根本から何か変える必要がある
決心した - ハレーション覚悟で組織もプロセスも変えることを決心した
これらの問題をまとめて解決するために考えたこ と - プロダクト組織、営業組織、CS組織、全ての組織が同じ目標を目指す状態 - ビジネス要求の実現可能性を検査し、合意してプロダクトの意思決定を行う仕組み
プロダクト組織と営業組織が同 じ目標を目指せる状態
答えは単純 - 「売上・利益目標の達成」を全ての部署の目標にすればいい
「売上・利益目標の達成」目指 した時に、追うべき指標は何 か?
これも単純 - 契約継続率 - 新規顧客獲得数
ビジネス要求の実現可能性を 検査し、合意してプロダクトの 意思決定を行う仕組み
プロダクトマネジメントトライアングル
考えていたこと - プロダクトの意思決定を行うために必要な専門性と知識を持った専門家が集まり、意思決定を 行える状態 - 専門家がそれぞれの専門性を用いて要求の検証を行い、合意を行う
答えになった「プロダクトボード」というアイディア - チーム横断でサービス全体を舵取りするプロダクトボードの話
プロダクトボード - 「プロダクトの意思決定を行うための専門性と知識を持った人が集まり、プロダクトの意思決定を 行う組織」そのものだった - プロダクトボードには営業の専門家、カスタマーサポートの専門家、エンジニアリングの専門 家、運用の専門家、デザインの専門家、などに参加してもらっている
- 自分はエンジニアリングの専門家として参加している - 組織図上で上位にあるマネジメントチームではない
2023年はこの体制でいくことにした - プロダクト本部の誕生と組織変更の狙い
やってみて - とにかく話が早くなった - 「こういう売り方をしたいからこういうことはできないか」という話が全て集まるようになった - 「誰々に確認してみます」みたいなことが減った
結果 - 定量 - 会場限定 - 定性 - 会場限定
ネガティブな出来事 - 会場限定
大変なこと
プロダクトボードが承認機関と見られがち - 確かに承認機関の側面はある - 実際にリーダー層が多くアサインされている - 繰り返すが、組織図上で上位にあるマネジメントチームではない
自分にタフな意思決定が求められる構造は変 わっていない - さすがに限界がある - HRBP(Human Resource Business
Partner)の能力が必要 - 意思決定に絡めるリーダー層を徐々に増やしていくしかない
自分に「お伺い」を立てないと新しいことができな い状態になっていないか - 自分が開発組織の生産能力以上にやることが投入されないように、防護壁になっている - 不健全なヒエラルキーを産んでいないか -
技術でビジネスを引っ張る状態になりたい - やはり最後の拠り所は技術力
まとめ
まとめ - Classiはプロダクトと事業のコントロールができていなかった - 原因は主に3つ - 営業組織とプロダクト組織が同じ事業目標を見れていない -
組織間の意思決定の競合が解決できない - ビジネス要求の実現可能性が検証されていない - 解決するために行ったことは2つ - 営業組織とプロダクト組織は同じ事業目標を設定する - ビジネス要求の実現可能性を検査し、合意してプロダクトの意思決定を行う会議体を作る - そこにはプロダクトの意思決定を行うために必要な専門性と知識を持った人間が参 加する
注意点 - たぶんプロダクトボードという体制だけを真似してもうまくいきません - 部屋の中の象(The elephant in the room)に向き合い続ける覚悟が必要
- Classiには「エンジニアがやばいって言ってるとやばいんだな」と経営陣が理解してくれる土壌も ある - 最終的には気合いと勢いと覚悟
オーナーシップは 誰のものだったのか?
オーナーシップが足りないのは自分だった - 意思決定を行うための知識や専門性が足りないのであれば、自分が行えばいい - プロダクトマネジメントはプロダクトマネージャーだけが行うものではない - プロダクトの意思決定を他人に押し付けるのをやめた
- 「それはプロダクトマネージャーが決めることだ」という態度を取るのをやめた - オーナーシップは誰が持ってもいい - 役割、職能は関係ない
To be continued - 今プロダクトボードは、全員がプロダクトオーナーシップを持って運営していると感じている
これらの事象には一人では立ち向かえなかった - Classiのエンジニア組織は時間をかけて、チームでマネジメントに取り組める状態を作り続けて いる - この積み重ねが無ければ乗り越えられなかった - 当時、議論を重ねて一緒に課題に立ち向かってくれたClassiのエンジニア組織のマネージャー
たちにはこの場を借りて感謝申し上げます
参考資料 - チーム横断でサービス全体を舵取りするプロダクトボードの話 - 株式会社エスエムエス TECH BLOG -
ビジネスとエンジニアリングの3wayハンドシェイク - Marginalia - 書籍「組織デザイン」読書メモ - onigra.github.io - 組織デザイン - 沼上 幹 (著) - 最強の戦略人事 - リード・デシュラー (著), クレイグ・スミス (著), アリソン・フォン・フェルト (著), 土井 哲 (翻訳) - スクラム導入後にアジリティが減少してしまう理由 - MJ (Michael James) - ザ・ゴール - エリヤフ・ゴールドラット (著)