全社プロダクトマネジメント! 職能と職位を乗り越えて若々しいチームを実現しよう/create a agile team beyond roles and ranks

■発表者
https://twitter.com/_N_A_
https://note.com/mryy

■概要
勢いのあるプロダクト開発が「カオス」から「効率と安定」へと変化する過程をたどりながら、意図せず自己組織的にアイデアを妨げる組織を生み出すメカニズムを解説します。

プロダクトマネージャーや組織のリーダーが、良かれと思って進めた効率化の取り組みが、結果的に官僚的なルールや文化を強力に構築し、組織の連携を壊しかねない状況を引き起こす現象です。

・自分の組織における質的解決と量的解決の変化と、その評価の簡単な方法を提示

Transcript

1. V1.2 90min 2024/10/01 V1.0 2024/09/25 Agile Tea Party 2024 witch&wizards inc. 森 雄哉
3. 早い話 プロダクトを作って当てて 組織が大きくなって 連携ができなくなって また連携できるようにする このプロダクト企業の5年間を 数十分で! 2
4. とある 新規プロダクト開発 3
7. ついにリリース! 6
8. ついにリリース! リリースすると 何が起きる? 7
14. オペレーションを 効率化するぞ! 13
25. 半年後… 24
42. 効率がいい組織のはず! 41
43. 効率がいい組織のはず! なのに 思いついたアイデアの 仮説検証に時間がかかる 42
44. 最高に効率のいい組織の 不気味 43
60. 文化が足りないのかも! 効率的に文化を広めよう! 文化も効率化しよう! 65
65. 会社の隅々まで 効率化しよう! 70
66. 会社の隅々まで 効率化しよう! 完了タスクが どんどん増えるぞ! 71
73. 私たちが本当に 欲しかった組織 79
76. いったい 何が起きていたのか 82
77. V1.1 90min 2024/09/30 V1.0 2024/09/25 Agile Tea Party 2024 witch&wizards inc. 森 雄哉
79. ・今あるプロダクトで大ヒットを作る ・事業としてのプロダクトの強みと弱みを明らかにし、 組織とチームが注力できるようにする ・次の施策(プロダクトバックログなど)を 何をやっても効果のあるアクションでぱんぱんにする
83. V1.1 90min 2024/09/30 V1.0 2024/09/25 Agile Tea Party 2024 witch&wizards inc. 森 雄哉
85. 事業会社の健全指標 92
86. 私たちは顧客に プロダクトを通して 何を提供しているのか 93
87. 私たちは顧客に プロダクトを通して 何を提供しているのか 94 問題の解決
88. 顧客にとって お金を払ってでも 解決したい問題を 解決できるから 顧客は代金を払う 95
89. 困ってるほど解決できたら 売上が伸びる この解決の量が増えると 売上が伸びる 96
90. 売上は 顧客にとって重要な問題を 解決した質と量の 遅れた結果 97
91. ところが メディアに取りあげられたり ブームになるとすると一気に 売上はあがる 売上は 外部環境に左右されやすい 98
92. 顧客が興味本位で買って 使わずに放置しても 売上は上がる 99
93. 解決した問題よりも 売上が大きくなったら ゆがみが出る 100
94. 解決した問題よりも 売上が大きくなったら ゆがみが出る 解決できる問題よりも 高い売上を望んでしまったら ゆがみが出る 101
95. サブスク解約忘れの 売上と継続率の高さで ｢うちのサービスは優良です｣ って、なってたらヤバい 102
96. 顧客にとって重要な問題の 解決の質と量を 基準にできるとより健全 103
97. 問題解決の質と量 まずは質から 104
98. 問題解決の質と量 まずは質から 解く問題の価値と 解き方の質から捉える 問題解決 105
105. 組織における 問題解決の全体モデル 112
108. 要素ごとに見ていこう
109. 個人の問題解決 118
113. 職能間の連携 プロダクトマネージャーと開発者の問題解決 122
119. 職位間の連携 現場と上司の問題解決 128
123. 問題解決には2種類の質がある ・より解く価値の高い問題を特定 ・解決の質の高さ 企業の問題解決には連携要素がある ・一人一人の問題解決 ・異なる職能の連携による問題解決 ・異なる職位の連携による問題解決
124. 職能 営業だけでは売るものがない 開発だけでは売れない 職位 現場だけでは事業を始められない 経営だけでは事業を運用できない 一人一人の立場では実現できない プロダクトを協力によって生み出し 顧客の問題を解決する
127. コーチや スクラムマスターは 組織が顧客の問題を 解決できるように関わる
130. どれだけ自分の役割の 問題を解決できても 顧客の問題を解決することに つなげられなかったら 顧客にとっては価値がない
131. 職能と職位を越えて 問題を解決した結果を 顧客にまで届ける必要がある
135. 個人の活躍 異なる職能が協力する 異なる職位が協力する この個人の活躍と協力関係が 顧客まで届いたとき プロダクトが成立する
138. 問題解決の質的四象限で 評価してみよう 148
144. - 左上の象限 - 世の中には品質の高い 売れ残りが無数にある 154
150. 人類のプロダクトの歴史は QCDの歴史 Q:品質 C:コスト D:納期 160
151. 人類のプロダクトの歴史は QCDの歴史 Q:品質 C:コスト D:納期 161
152. 人類のプロダクトの歴史は QCDの歴史 Q:品質 C:コスト D:納期 はやいやすいうまい 162
157. プロダクト開発組織 問題解決の失敗例1 167
158. プロダクト開発組織 問題解決の失敗例1 プロトタイプの罠 168
159. プロダクト開発組織 問題解決の失敗例1 プロトタイプの罠 はやいやすいまずい 169
161. 「はやいやすいまずい」を 見つけるのはプロトタイプ 171
162. 「はやいやすいまずい」を 見つけるのはプロトタイプ ではない 172
163. 「うまい!!」を 早く見つけるのが プロトタイプ 173
164. 遅くても高くても 174
165. 遅くても高くても ｢めちゃくちゃうまい!」 なら客がつく 175
166. はやくても安くても ｢まっず…」 では客はつかない 176
167. プロダクト開発組織 問題解決の失敗例2 QCDの安易な トレードオフは 長期的には競争劣位 177
178. プロダクト開発組織 問題解決の失敗例3 3.00の壁 188
190. 組織の誰もが 「うまくいっている」 と評価しているのに 顧客からの評価は さんざんだったら 評価が間違っている 200
191. 評価が フィードバックを生み出す 評価の質によって フィードバックの 質が左右される 201
192. よりよいフィードバックを 取り込むために 自分達の活動を評価し 評価が機能しているのかも 精査しよう 202
194. 自分達の組織はどこ? 問題解決の質チェック 204
202. 組織の活動を 各個人/職能の連携 職位の連携といった 要素ごとに会話しながら 定性/定量評価してみよう 213
205. 質を何時間、磨いてる? 218
206. 質を何時間、磨いてる? 問題解決の活動に 費やす月あたりの時間は? 219
209. ・価値のある問題を見つける ・解決の技を磨く どちらも時間がかかる 222
210. じゃあ自分の 時間の使いかたは? 223
212. みんなの 時間の使いかたの合計は? 225
216. 解く価値の高い問題を探索し 解決の質を高くする 229
217. 費やしている比率は適切? 顧客の問題を解決できる比率? 競合に勝てる比率? 230
218. かけてるコスト ばっちり把握してる? 231
220. プロダクトを支える活動の 合計を考えると 多額が費やされている 233
221. 年収500万 会社負担は1000万 234
222. 年収500万 会社負担は1000万 10人チームなら1億 100人組織なら10億 235
223. 「資金調達10億!!」と よくニュースで盛り上がるが それに比類する金額が 事業に費やされている 236
224. 顧客にとって 重要な問題の解決に コスト(自分達の時間)を かけよう 237
226. 上記をうまく設計と運用するのも プロダクトマネジメント
227. 投資時間を明らかにしよう
228. 費やしている時間を推定し 自分達の問題解決の質を 評価してみよう 241
231. リリースすると何が起きる? 244
232. リリースすると何が起きる? 大量のタスクの発生!! 245
237. いったい何が 起きはじめたのか 250
246. 質的解決から 量的解決に 組織の関心が変わる
247. 組織的関心の変化は 組織構造と意思決定に 変化をもたらす
248. 量的解決時代 到来
250. 量的解決の初期 263
251. 量的解決の初期 フィッターの誕生 264
252. 量がすごいと 翻弄される 265
253. 1000や2000の 工程が同時に動くゲーム 266
259. 大量タスクに対して 「翻弄される」という認知が 続くと何が起こるか
260. 大量タスクに対して 「翻弄される」という認知が 続くと何が起こるか 「人が足りない!」という 判断をしてしまう
261. 大量タスクに対して 大量採用で解決しようとする
262. しかし単に大量採用しても 採用された新メンバーは 何をすればいいか分からない すぐに活躍できるように 即戦力構造を作る
264. 自分がやると早いこと 他人がやると早いこと
265. 自分がやると早いこと 他人がやると早いこと タスクの分類と 実行の組織システムが 急造される
266. すぐに活躍できる即戦力構造 1.分業 279
269. すぐに活躍できる即戦力構造 2.過去の解決を繰り返す 282
275. 大量を 問題解決の繰り返しで 解決する
276. 質的解決が ｢はやいやすいうまい｣なら 289
277. 質的解決が ｢はやいやすいうまい｣なら 量的解決は ｢広く多く確実に｣ 290
288. どこの店より 「はやいやすいうまい」を
289. どこの店より 「はやいやすいうまい」を どこにいても 「徒歩圏内待たせず同じ味」 で提供できたら大成功
291. 解く価値のある問題を 繰り返し解決することは重要 その代表が医療 308
300. 量的解決と質的解決の違い 318
302. 量的解決と質的解決 仕事の裁量性の違い 320
311. 高度な専門家の仕事は その専門性が 個人の意思に先行し 意思決定の土台を作る
312. 巨人の肩に乗って 高度な仕事を果たす
316. 自分が決めるとは 「好きに決めてもいい」 という意味ではなく
317. 自分が決めるとは 「好きに決めてもいい」 という意味ではなく 価値を伴う独自性を 発揮しなければ ならない意思決定
318. 同じではいけない 独自なだけでもいけない 価値のある独自性が必要
319. たとえば プロダクトの名称は 他社と同一ではダメ 独自の名称に しなければならない
320. 他社のプラクティスは まねていい プロダクトはそのまま まねたら訴えられる
321. 方法も価値も自分が 決めなければならないとは ユニークさを 強制させられている領域
326. プロダクト開発では 企業を越えて伝搬する ベストプラクティスと
327. プロダクト開発では 企業を越えて伝搬する ベストプラクティスと 他社より秀でる独自性 という異なる性質の仕事を 両立する必要がある
329. 量的解決と質的解決 日々の仕事の違い 347
333. 10タスク10完了が 求められる仕事 10チャレンジ1成功 100リターンの仕事
334. 自分の仕事の割合は? 上司は? 連携する部署は?
335. 10チャレンジ1成功の仕事に 10タスク10完了の 期待をしたりされたら 軋轢が生まれる
339. 異なる職能/職位の 仕事の性質を理解して 協力関係を築いていこう
342. これまでは 問題解決の質と量の話 360
343. 顧客にとって重要な問題の解決を 他社より「はやいやすいうまい」を実現し 「広く多く確実に」提供できたら プロダクトは大成功するかも! 361
344. 顧客にとって重要な問題の解決を 他社より「はやいやすいうまい」を実現し 「広く多く確実に」提供できたら プロダクトは大成功するかも! ところが量的解決のために行った 「大量採用と即戦力構造」による 組織的への変化が… 362
345. 人が急に増えると何が起きる? 363
346. 人が急に増えると何が起きる? 人数構成比の変化 364
356. 大量採用すると何が起きるか? 問題解決の質的解決をした 0→1経験者が少数派になり 解決された問題を確実に繰り返す 10→100経験者が多数派に
357. 人数構成比が変化すると 何が起きる? 375
358. 人数構成比が変化すると 何が起きる? 社内事情に詳しい 0→1メンバーによる 調整が追いつかなくなる 376
359. 調整をカバーするために 社内制度が拡充される 377
364. 人が増えたら何をする? 専門分化/機能別組織 383
367. 専門分化/機能別組織が できると何が起きる? 386
368. 専門分化/機能別組織が できると何が起きる? マッチングが 多頻度で発生する 387
371. 専門分化/機能別組織は 非専門家に専門家への依頼を 強制する仕組み この仕組みはマッチングを 引き起こす
372. - 仕事のマッチング問題 - 非専門家の違和感が組織の中で どのように扱われるか 391
381. 非専門家が専門家に相談する労力 ・誰に相談すればいいのか分からない ・どう説明すればいいのか分からない
382. 非専門家が専門家に相談する労力 ・誰に相談すればいいのか分からない ・どう説明すればいいのか分からない 専門分化/機能別組織において 非専門家が取り組むことは 非効率だと見なされるが
383. 非専門家が専門家に相談する労力 ・誰に相談すればいいのか分からない ・どう説明すればいいのか分からない 専門分化/機能別組織において 非専門家が取り組むことは 非効率だと見なされるが 非専門家が専門家に依頼するために かかる膨大な労力は軽視される
384. 「十分な目があればバグは洗い出せる」 リーナスの法則 ところが組織の人は増えても 全員が自分の狭い役割だけを担うなら 組織が見ている範囲は思ったり狭いかも
395. プロダクトオペレーションにおいて フローの向上(リードタイム削減)が 最重要 フローの向上とは どのタスクにいつ着手するべきか (いつまで着手してはならないか)を 基準に実行すること
396. 言い換えると オペレーションプロセスによって 緊急フローの割合が限られているとき 期限に余裕のあるタスクが多いとき フローは向上する
397. 大量採用、分業、即戦力の問題は プロダクトオペレーションの フローを乱す様々な現象を 引き起こすこと
398. たとえば 声の大きい人が独自判断で タスクを差し込めば フローは簡単に壊れる
399. 何からやることが 本当に自信を持って オペレーションの向上に 繋がると信じれないなら 依頼の仕組みを見直そう
401. 大量採用、分業、即戦力構造の状況下で 仕方がなく対応した行動の積み重ねが いかにフローを壊すか 421
402. フローを壊す 緊急フロー構造 422
403. 重要そうで緊急な依頼に 優先対応すると 何が起こるか 423
404. 重要そうで緊急な依頼に 優先対応すると 何が起こるか 仕事が緊急ばかりで 埋め尽くされる 424
412. 全員が緊急なタスクから 処理すると何が起こる?
413. 全員が緊急なタスクから 処理すると何が起こる? すべてのタスクが 緊急になる
414. 緊急にしなければ 後回しにされる
421. 442 442
422. 相手に着手してもらうための 悪気のないズル 仕方が無いからするズル 誠実な依頼は馬鹿を見る 意思決定をしてたら フローを壊してる
424. 緊急フローによって 何が起こるか 445
425. 緊急フローによって 何が起こるか タスクの完了よりも タスクの着手を優先する 446
429. 何からタスクをすべきかが 価値によってではなく 依頼者の権力によって決まる
430. 緊急フローを構築しても 1取引当たりの損益分岐点を 超えられていたら 営業や販促は量的拡大の連続で 収益を伸ばしつづけられる 451
431. とくにソフトウェアプロダクトは 1つのプロダクトを余分に生産する 限界費用がほぼ0なため 量的拡大への偏重が 深刻になりやすい 452
432. 1案件 ちょっとでも儲かれば あとは量で稼ぎがち 価値の高いプロダクト作りが 価値の低い多売へ
433. 緊急/締め切り という疑似権限 454
435. いや、ちょっとまって 何かがおかしい 456
436. 緊急!緊急! そんなことより 顧客が待ってるんだから! 案件逃したら責任取れる? はやくこのタスクに 取り掛かって!! 緊急!緊急!
437. いや、でも… 458
438. 緊急だから 説明なんて必要ないの! あなたの納得は不要なの! とにかくやって!!
439. はい… (異和感あるけど 言葉にできない) 460
440. - 再掲 - プロダクトオペレーションにおいて フローの向上(リードタイム削減)が 最重要 フローの向上とは どのタスクにいつ着手するべきか (いつまで着手してはならないか)を 基準に実行すること
441. 拍車をかけるのが 462
442. 雰囲気問題 463
443. 雰囲気問題 不明瞭な価値の確証で 売上を伸ばす 464
450. 自社は雰囲気で プロダクトを売る 顧客は雰囲気で プロダクトを買う
451. 雰囲気セールスと 緊急フロー/疑似権限は 顧客の問題が解決されて いるかの判断を省略する
455. まともなことをする人が 損をする意思決定構造に なっているときは なにかがおかしい
458. そして 時の試練が 襲いかかる 480
459. 若い組織から 481
460. 若い組織から 年老いた組織へ 482
461. 483 畑村洋太郎『失敗学の法則』
462. 484 複数の部署が 自分の仕事だと 仕事の取り合い 畑村洋太郎『失敗学の法則』
463. 485 複数の部署が 自分の仕事だと 仕事の取り合い きっちりでき あがった役割分担 畑村洋太郎『失敗学の法則』
464. 486 複数の部署が 自分の仕事だと 仕事の取り合い きっちりでき あがった役割分担 畑村洋太郎『失敗学の法則』
465. 役割分担の劣化 487
466. 役割分担の発展期
467. 役割分担の発展期 私がやらなきゃ 誰がやる!
469. 役割分担の衰退期
470. 役割分担の衰退期 私がやらなきゃ
471. 役割分担の衰退期 私がやらなきゃ 誰かやる!
472. 私がやらなきゃ誰がやる! 私がやらなきゃ誰かやる!
473. 若い組織は 誰もが自分が手を出す 口を出す余地がある
474. 能力のある人が もっとできると感じたら 実際に担う機会がある 「やらせてください!」
475. 年老いた組織は
476. 年老いた組織は 口を出すな手を出すな 余計な仕事を増やすな 言われたことをしろ
477. 499 複数の部署が 自分の仕事だと 仕事の取り合い きっちりでき あがった役割分担 畑村洋太郎『失敗学の法則』
479. 役割分担はなぜ劣化するのか 501
480. 役割分担はなぜ劣化するのか 昇進/異動/退職による 経路情報の破棄 502
488. さらに 時の試練が 襲いかかる!! 510
491. もし顧客が増えて 専門性も高まっているなら 顧客理解は深まり
492. もし顧客が増えて 専門性も高まっているなら 顧客理解は深まり 解く価値の高い問題は 発見され放題なはず!
493. 黄金時代を 迎えているはず!
494. ところが現実は より解く価値の高い問題が 新たに見つかるどころか
495. ところが現実は より解く価値の高い問題が 新たに見つかるどころか これまで実現してきた 価値ですら消耗
500. 売れなくなってきた! 522
501. 売れなくなってきた! 次の手を打たないと!! でも時間が無い! 523
502. 売れなくなってきた! 次の手を打たないと!! でも時間が無い! 確実に成功しないと! 効率的にしないと! 524
509. 事例とは 531
510. 事例とは 他社が検証済みの 解決できる価値の高い問題 532
512. 事例ディスカバリー 爆誕
513. 解決された問題の繰り返しが 価値探索まで及んだとき 事例ディスカバリーが発生 (他社の事例をパクる)
515. もし他社の事例で 成功してしまうと 何が起きる? 537
517. しかし事例ディスカバリーは 質的解決の空洞化に直行
519. プロダクト マネジメントの罠 541
523. 大量採用、即戦力のための分業、専門分化、 再解決の繰り返し、社内制度の拡充、かっ ちり決めた役割分担、雰囲気で販売促進、 緊急フロー/疑似権限で対処 事例ディスカバリー…
524. 大量採用、即戦力のための分業、専門分化、 再解決の繰り返し、社内制度の拡充、かっ ちり決めた役割分担、雰囲気で販売促進、 緊急フロー/疑似権限で対処 事例ディスカバリー… 罠 いいアイデアだと思い 短期的には悩みを解決し 分かりやすい報酬をもたらすが 長期的には問題を引き起こし 問題は幽霊のように認識困難で長期化する
525. 人が増えると 組織の連携の難易度は 大きく上がってしまう 547
526. 人が増えると 組織の連携の難易度は 大きく上がってしまう 異なる職位、異なる職能の やり取りで混乱してしまう 548
528. 人が増えると 組織マネジメントの 難易度は大きく上がる
535. 組織の各要素を統合して 組織の全体感を掴もう 557
548. 自分が組織や顧客に どのような貢献をしているのか 分からない 隣の部署や上司が組織や顧客に どのような貢献をしているのか 分からない このような状況なら協力は難しい 570
549. 自分自身、上司、隣の部署が 組織や顧客への貢献を 明らかにすることを通して 協力を育もう 571
550. 全体への統合を 阻むのが 無知/無能/無関心 573
551. 他の職能、他の職位に対して 「知らないできない興味ない」 574
552. 無知であること 無能であること 無関心であることは どれくらい避けるべき? 575
555. 無知/無能/無関心であっても 578
556. 無知/無能/無関心であっても 調べる/試す/好奇心によって 579
557. 無知/無能/無関心であっても 調べる/試す/好奇心によって 知ってる/できる/当事者意識を 新たに獲得できるようになる 580
558. しかし 無知/無能/無関心を 遠ざける罠がある 582
559. 有能さの檻 583
562. 有能さで人を 評価するほど その人は今できることに 注力するようになる 586
563. 私たちは 有能さによって評価され 無能さを避ける そうして現在の有能さに 留まる力学が働く 587
572. 有能さの檻は 短期的には個人評価に繋がるが 長期的には人を 無知/無能/無関心に孤立させる 596
574. 何をすればいいだろう? 598
575. 何をすればいいだろう? 最初の一歩は たどたどしさの受容 599
576. 若々しいチームは 今できることに留まるより もっとできそうことに 踏み出す 600
577. 無知/無能/無関心の たどたどしさを 受け入れる 601
580. 説明のしやすさ 説明の分かりやすさで 意思決定していたら注意
581. ピクサーの ブレイントラスト 606
584. うまくやれないことを うまくやれるように 今日もやっていこう
585. V1.1 90min 2024/09/30 V1.0 2024/09/25 Agile Tea Party 2024 witch&wizards inc. 森 雄哉
590. 問題の質的解決の 全体像 615
597. 問題の量的解決の 全体像 622