「プロダクトマネージャーがプロダクトマネジメントを失敗させる!?」大企業病の罠を乗り越え若々しいチームを実現する/Traps of Optimization in Product Management 2024

moriyuya

January 11, 2024

Tweet Share

Transcript

1. V1.2 2024/03/25 60min V1.0 2024/01/11 Regional Scrum Gathering Tokyo 2024

   witch&wizards inc. 森 雄哉

2. 2

3. 3

4. とある 新規プロダクト開発 4

5. 5

6. ついにリリース! リリースすると 何が起きる? 6

7. 7

8. 8

9. 9

10. 10

11. 11

12. オペレーションを 効率化するぞ! 12

13. 13

14. 14

15. 15

16. 16

17. 17

18. 18

19. 19

20. 20

21. None
22. None

23. 半年後… 23

24. 24

25. 25

26. 26

27. 27

28. 28

29. 29

30. 30

31. 31

32. 32

33. 33

34. 34

35. 35

36. 36

37. 37

38. 38

39. 39

40. 効率がいい組織のはず! 40

41. 効率がいい組織のはず! なのに 思いついたアイデアの 仮説検証に時間がかかる 41

42. 最高に効率のいい組織の 不気味 42

43. 43

44. 44

45. 新しいアイデアを試す リードタイムが伸びている! 45

46. 46

47. 47

48. 49

49. 50

50. 51

51. 52

52. 53

53. 54

54. 55

55. 56

56. 57

57. 58

58. 文化が足りないのかも! 効率的に文化を広めよう! 文化も効率化しよう! 59

59. 60

60. 61

61. 62

62. 63

63. 会社の隅々まで 効率化しよう! 64

64. 会社の隅々まで 効率化しよう! 完了タスクが どんどん増えるぞ! 65

65. 66

66. 67

67. 68

68. 69

69. 70

70. 71

71. いったい 何が起きていたのか 72

72. V1.2.1 2024/03/25 60min V1.0 2024/01/11 Regional Scrum Gathering Tokyo 2024

    witch&wizards inc. 森 雄哉
73. None

74. ・今あるプロダクトで大ヒットを作る ・事業としてのプロダクトの強みと弱みを明らかにし、 組織とチームが注力できるようにする ・次の施策(プロダクトバックログなど)を 何をやっても効果のあるアクションでぱんぱんにする

75. 77

76. None

77. 79

78. None

79. 81

80. 82

81. None

82. V1.2 2024/03/25 60min V1.0 2024/01/11 Regional Scrum Gathering Tokyo 2024

    witch&wizards inc. 森 雄哉

83. 87

84. None
85. None

86. プロダクト開発組織の 健全指標 90

87. 私たちは顧客に プロダクトを通して 何を提供しているのか 91

88. 私たちは顧客に プロダクトを通して 何を提供しているのか 92 問題の解決

89. 顧客にとって お金を払ってでも 解決したい問題を 解決できるから 代金を払う 93

90. 困ってるほど解決できたら 売上が伸びる この解決の量が増えると 売上が伸びる 94

91. 売上は 顧客にとって重要な問題を 解決した質と量の 遅れた結果 95

92. ところが メディアに取りあげられたり ブームになるとすると一気に 売上はあがる 売上は 外部環境に左右されやすい 96

93. 顧客が興味本位で買って 使わずに放置しても 売上は上がる 97

94. 解決した問題よりも 売上が大きくなったら ゆがみが出る 98

95. 解決できる問題よりも 高い売上を望んでしまったら ゆがみが出る 99

96. サブスク解約忘れの 売上と継続率の高さで ｢うちのサービスは優良です｣ って、なってたらヤバい 100

97. 顧客にとって重要な問題の 解決の質と量を 基準にできるとより健全 102

98. まずは質 103

99. 解く問題の価値と解き方の ｢質｣から捉える問題解決 104

100. 105

101. 106

102. 107

103. 108

104. None

105. 110

106. 問題解決の順序の 失敗パターン 1.どう解くか(How) 2.なにを解くか(What) 111

107. 問題解決の順序の 失敗パターン 1.どう解くか(How) 2.なにを解くか(What) 成功パターン 1.なにを解くか(What) 2.どう解くか(How) 112

108. プロダクト開発組織の 問題解決 113

109. None
110. None

111. 117

112. 118

113. None

114. 売上は 顧客にとって重要な問題を 解決した「質と量」の遅れた結果 120

115. 売上は 顧客にとって重要な問題を 解決した「質と量」の遅れた結果 RSGT2023は｢質｣の話 121

116. RSGT2024は｢量｣と 質と量の組織的相互作用の話 122

117. None

118. 124

119. リリースすると何が起きる? 125

120. リリースすると何が起きる? 大量のタスクの発生!! 126

121. None
122. None
123. None
124. None

125. いったい何が 起きはじめたのか 131

126. None
127. None
128. None
129. None
130. None

131. 137

132. 質的追求から 量的追求に 組織的関心が変わる

133. 組織的関心の変化は 組織構造と意思決定に 変化をもたらす

134. 量的追求時代 到来

135. None

136. 量的追求の初期 142

137. 量的追求の初期 フィッターの誕生 143

138. 量がすごいと 翻弄される 144

139. 1000や2000の 工程が同時に動くゲーム 145

140. None
141. None

142. 148

143. 149

144. 150

145. 大量タスクに対して 「翻弄される」という認知が 続くと何が起こるか 151

146. 大量タスクに対して 「翻弄される」という認知が 続くと何が起こるか 「人が足りない!」という 判断をしてしまう 152

147. 大量タスクに対して 大量採用で解決しようとする 153

148. しかし単に大量採用しても 採用された新メンバーは 何をすればいいか分からない 154

149. しかし単に大量採用しても 採用された新メンバーは 何をすればいいか分からない すぐに活躍できるように 即戦力構造を作る 155

150. 156

151. 自分がやると早いこと 他人がやると早いこと

152. 自分がやると早いこと 他人がやると早いこと タスクの分類と 実行組織システムが 急造される

153. すぐに活躍できる即戦力構造 1.分業 159

154. 160

155. 161

156. すぐに活躍できる即戦力構造 2.過去の解決を繰り返す 162

157. 163

158. 164

159. 165

160. 166

161. 167

162. 168

163. 169

164. 解く価値のある問題を 繰り返し解決することは重要 その代表が医療 170

165. None
166. None
167. None

168. 仕事の裁量性 174

169. 175

170. 176

171. 177

172. 178

173. 179

174. 180

175. None

176. 182

177. 183

178. 高度な専門家の仕事は その専門性が 個人の意思に先行し 意思決定の土台を作る

179. 巨人の肩に乗って 高度な仕事を果たす

180. 186

181. 187

182. 188

183. 自分が決めるとは 「好きに決めてもいい」 という意味ではなく

184. 自分が決めるとは 「好きに決めてもいい」 という意味ではなく 価値を伴う独自性を 発揮しなければ ならない意思決定

185. 同じではいけない 独自なだけでもいけない 価値のある独自性が必要

186. たとえば プロダクトの名称は 他社と同一ではダメ 独自の名称に しなければならない

187. 他社のプラクティスは そっくりまねていい プロダクトはそのまま まねたら訴えられる

188. 方法も価値も自分が 決めなければならないとは ユニークさを 強制させられている領域

189. 196

190. 197

191. 198

192. 199

193. プロダクト開発では 組織を越えて収斂する ベストプラクティスと

194. プロダクト開発では 組織を越えて収斂する ベストプラクティスと 他社より秀でる独自性 という異なる性質の仕事を 両立する必要がある

195. ここまでの流れ 210

196. None
197. None
198. None

199. 大量採用すると 何が起こるか? 214

200. 大量採用すると 何が起こるか? 人数構成比の変化 215

201. 216

202. 217

203. 218

204. 219

205. 220

206. 221

207. 222

208. 223

209. 224

210. 大量採用すると何が起きる? 225

211. 大量採用すると何が起きる? マネジメントリソースが さらに足りなくなる 226

212. マネジメントリソースの 少なさをカバーするために 社内制度が拡充される 227

213. 228

214. 229

215. 230

216. 231

217. 人が増えてきたら何をする? 専門分化/機能別組織 233

218. None

219. 専門分化/機能別組織が できると何が起きる? 236

220. 専門分化/機能別組織が できると何が起きる? マッチングが多頻度発生する 237

221. - 仕事のマッチング問題 - 非専門家の違和感が組織の中で どのように扱われるか 238

222. 239

223. 240

224. 241

225. 242

226. 243

227. 244

228. None
229. None
230. None
231. None
232. None
233. None
234. None
235. None
236. None
237. None
238. None

239. 分かりやすい重要そうで 緊急な依頼に優先対応すると 何が起こるか 257

240. 分かりやすい重要そうで 緊急な依頼に優先対応すると 何が起こるか 仕事が緊急ばかりで 埋め尽くされる 258

241. 緊急フロー構造 259

242. 260

243. None
244. None

245. 263

246. 264

247. 265

248. 266

249. みんなが 緊急なタスクから 処理すると 何が起こる?

250. すべてのタスクが 緊急になる

251. すべてのタスクが 緊急になる 緊急にしなければ 後回しにされる

252. None
253. None

254. 275

255. 276

256. 277

257. 278

258. 279 279

259. 誠実な依頼は 馬鹿を見る 意思決定構造に

260. None

261. 緊急フローによって 何が起こるか 283

262. 緊急フローによって 何が起こるか タスクの完了よりも タスクの着手を優先する 284

263. 287

264. None
265. None

266. 何からタスクをすべきかが オペレーションプロセス ではなく 依頼者の権力によって 決まるようになる

267. 緊急フローを構築しても 1取引当たりの損益分岐点を 超えられていたら 営業や販促は量的拡大の連続で 収益を伸ばしつづけられる 291

268. とくにソフトウェアプロダクトは 1つのプロダクトを余分に生産する 限界費用がほぼ0なため 量的拡大への偏重が 深刻になりやすい 292

269. 1案件 ちょっとでも儲かれば あとは量で稼ぎがち 293

270. 価値の高いプロダクトと うたいつつ 価値の薄利多売へ

271. 緊急/締め切り という疑似権限 297

272. 298

273. いや、ちょっとまって 何かがおかしい 301

274. 緊急!緊急! そんなことより 顧客が待ってるんだから! 案件逃したら責任取れる? はやくこのタスクに 取り掛かって!! 緊急!緊急!

275. いや、でも… 303

276. 緊急だから 説明なんて必要ないの! あなたの納得は不要なの! とにかくやって!!

277. はい… (異和感あるけど 言葉にできない) 305

278. 拍車をかけるのが 306

279. 雰囲気問題 307

280. 雰囲気問題 不明瞭な価値の確証で 売上を伸ばす 308

281. 309

282. 310

283. 自社は雰囲気で プロダクトを売る 顧客は雰囲気で プロダクトを買う

284. 雰囲気が蔓延すると アウトカムが本当に 生じているか怖くなり 顧客検証に及び腰になる

285. 脳内で理想の 振る舞いをしてくれる ペルソナにインタビュー してしまう

286. 雰囲気セールスと 緊急フロー/疑似権限は 質的判断を省略する

287. 過剰な量的追求の プレッシャーが 質的判断の省略を さらに促す

288. 自分たちも 何万も何十万も 雰囲気で本を買っては 積んでいる

289. とりあえずで積んでいたら 本を選ぶ選球眼は 一向に上達しない

290. しかし一冊ずつ 精査していたら 時間が足りなくなる 価値に対して雰囲気で 手を出してしまう

291. None
292. None
293. None

294. 誠実な依頼は 馬鹿を見る 意思決定構造に

295. まともなことをする人が 損をする意思決定構造に なっているときは なにかがおかしい

296. None

297. 332

298. そして 時の試練が 襲いかかる 333

299. 若い組織から 年老いた組織へ 334

300. 335 畑村洋太郎『失敗学の法則』

301. 336 複数の部署が 自分の仕事だと 仕事の取り合い 畑村洋太郎『失敗学の法則』

302. 337 複数の部署が 自分の仕事だと 仕事の取り合い きっちりでき あがった役割分担 畑村洋太郎『失敗学の法則』

303. 338 複数の部署が 自分の仕事だと 仕事の取り合い きっちりでき あがった役割分担 誰も引き受けない 仕事がたくさん 畑村洋太郎『失敗学の法則』

304. 役割分担の劣化 342

305. 役割分担の発展期

306. 役割分担の発展期 私がやらなきゃ 誰がやる!

307. None

308. 役割分担の衰退期

309. 役割分担の衰退期 私がやらなきゃ

310. 役割分担の衰退期 私がやらなきゃ 誰かやる!

311. 私がやらなきゃ誰がやる! 私がやらなきゃ誰かやる!

312. 若い組織は 誰もが自分が手を出す 口を出す余地がある

313. 能力のある人が もっとできると感じたら 実際に担う機会がある 「やらせてください!」

314. 年老いた組織は

315. 年老いた組織は 口を出すな手を出すな 余計な仕事を増やすな 言われたことをしろ

316. 354 複数の部署が 自分の仕事だと 仕事の取り合い きっちりでき あがった役割分担 誰も引き受けない 仕事がたくさん 畑村洋太郎『失敗学の法則』

317. None

318. 役割分担はなぜ劣化するのか 356

319. 役割分担はなぜ劣化するのか 昇進/異動/退職による 経路情報の破棄 357

320. None
321. None
322. None
323. None
324. None
325. None

326. 役割分担は できた瞬間から 劣化が始まる

327. 役割分担の設計意図は 仕事のガイドだったのに

328. 役割分担の設計意図は 仕事のガイドだったのに いつのまにか厳守すべき ルールになっていく

329. 年老いた組織は 今のメンバーの意思より 過去のルールを重視する

330. 繰り返しで 解決しきれない問題を 解決しようとするとき 事態は悪化する

331. None

332. さらに 時の試練が 襲いかかる!! 383

333. 384

334. 385

335. もし顧客が増えて 専門性も高まっているなら 顧客理解は深まり

336. もし顧客が増えて 専門性も高まっているなら 顧客理解は深まり 解く価値の高い問題は 発見され放題なはず!

337. 黄金時代を 迎えているはず!

338. ところが現実は より解く価値の高い問題が 新たに見つかるどころか

339. ところが現実は より解く価値の高い問題が 新たに見つかるどころか これまで実現してきた 価値ですら消耗

340. None
341. None

342. 394

343. 395

344. 売れなくなってきた! 396

345. 売れなくなってきた! 次の手を打たないと!! でも時間が無い! 397

346. 売れなくなってきた! 次の手を打たないと!! でも時間が無い! 確実に成功しないと! 効率的にしないと! 398

347. None
348. None

349. 401

350. 402

351. 403

352. 404

353. 事例とは 405

354. 事例とは 他社が検証済みの 解決できる価値の高い問題 406

355. 407

356. 事例ディスカバリー 爆誕

357. 解決された問題の繰り返しが 価値探索まで及んだとき 事例ディスカバリーが発生 (他社の事例をパクる)

358. 410

359. もし他社の事例で 成功してしまうと 何が起きる? 411

360. 412

361. しかし事例ディスカバリーは 質的追求の空洞化に直行

362. None

363. プロダクトマネージャーが プロダクトマネジメントを 失敗させる 415

364. 416

365. None

366. プロダクト マネジメントの罠 418

367. 419

368. 420

369. 大量採用、即戦力のための分業、専門分化、 再解決の繰り返し、社内制度の拡充、かっ ちり決めた役割分担、雰囲気で販売促進、 緊急フロー/疑似権限で対処 事例ディスカバリー…

370. 大量採用、即戦力のための分業、専門分化、 再解決の繰り返し、社内制度の拡充、かっ ちり決めた役割分担、雰囲気で販売促進、 緊急フロー/疑似権限で対処 事例ディスカバリー… 罠 いいアイデアだと思い 短期的には悩みを解決し 分かりやすい報酬をもたらすが 長期的には問題を引き起こし

     問題は幽霊のように認識困難で長期化する

371. PMF!! グロース!! 423

372. PMF!! グロース!! 上場!! 失速!! 424

373. PMF!! グロース!! 上場!! 失速!! アドバイザリーの罠 425

374. 426

375. 427

376. 無理してグロース!

377. 無理してグロース! 最後の力で上場!

378. 無理してグロース! 最後の力で上場! 無理をほのめかす アドバイザリーに注意

379. プロダクト運営における 致命傷とは

380. プロダクト運営における 致命傷とは メンバーにとって 挽回が大変すぎて 転職した方がずっと楽な 状況にしてしまうこと

381. None

382. V1.2 2024/03/25 60min V1.0 2024/01/11 Regional Scrum Gathering Tokyo 2024

     witch&wizards inc. 森 雄哉

383. V1.2 2024/03/25 60min V1.0 2024/01/11 Regional Scrum Gathering Tokyo 2024

     witch&wizards inc. 森 雄哉

384. 若々しいチームを実現するぞ 440

385. 無知/無能/無関心 441

386. 無知であること 無能であること 無関心であることは どれくらい避けるべき? 442

387. 443

388. 444

389. もし無知/無能/無関心を 避けているなら 価値の発見に失敗する 446

390. プロダクトはユニークで なければならない 聞いたこともないことを しなければならない 447

391. 分かった価値しか やっていないなら 448

392. 分かった価値しか やっていないなら 技術で勝っても 価値で負ける 449

393. できる技術しか やっていないなら 450

394. できる技術しか やっていないなら 価値で勝っても 技術で負ける 451

395. 無知/無能/無関心であっても 454

396. 無知/無能/無関心であっても 調べる/試す/好奇心によって 455

397. 無知/無能/無関心であっても 調べる/試す/好奇心によって 知ってる/できる/当事者意識を 新たに獲得できるようになる 456

398. しかし 無知/無能/無関心を 遠ざける罠がある 458

399. 有能さの檻 459

400. 460

401. 461

402. 有能さで人を 評価すればするほど その人は今できることに 注力するようになる 462

403. 私たちは 有能さによって評価され 無能さを避ける そうして現在の有能さに 留まる力学が働く 463

404. 464

405. 465

406. 466

407. 467

408. 有能さの檻は 短期的には個人評価に繋がるが 長期的には人を 無知/無能/無関心に引き込む 468

409. 469

410. 何をすればいいだろう? 470

411. 何をすればいいだろう? 最初の一歩は たどたどしさの受容 471

412. 若々しいチームは 今できることに留まるより もっとできそうことに 踏み出す 472

413. 踏み出した瞬間は ゴミアイデア ド下手くそ 473

414. None

415. ゴミアイデア ド下手くそ やらかしてないなら 有能さの檻に 閉じ込められているかも 475

416. 無知/無能/無関心の たどたどしさを 受け入れる 476

417. 477

418. 479

419. 説明のしやすさ 説明の分かりやすさで 意思決定していたら注意

420. 481

421. やってみないと 分からないの罠 482

422. すぐに白旗をあげて 「やってみないと分からない」 483

423. すぐに白旗をあげて 「やってみないと分からない」 ではなく 顧客のために考え抜いた結果の 「やってみないと分からない」 484

424. 485

425. コスパの檻 486

426. 487

427. 488 B -2000年 0年 2000年 100 10 1 0.1 0.01

     0.001 0.0001 Bresnahan, T. F., & Gordon, R. J. (1997). The Economics of New Goods: National Bureau of Economic Research Studies in Income and Wealth. 参考文献『ポール・ローマーと経済成長の謎』

428. 一度PMFしたら 技術も価値も追求しなくていい? PMFの罠 489

429. None
430. None

431. 価値の宝を見つけたら どうする? 492

432. 価値の宝を見つけたら どうする? 次の宝を探しに行く 493

433. None
434. None
435. None
436. None
437. None
438. None

439. トヨタ自動車工業の設立 1937年8月28日 量産自動車初代クラウン発売 1955年1月1日 18年かけてる (実態はもっと長い) 500

440. 無知/無能/無関心と共に 技術と価値の質を ずっと追求しつづけよう 501

441. うまくやれないことを うまくやれるように 今日もやっていくぞ

442. None

443. 罠を乗り越える 513

444. None

445. チームで罠について たどたどしく話そう 516

446. 答えを求めすぎれば 事例ディスカバリーの 罠にはまる 517

447. どんなに優れた答えでも 自分達の理解を越えると 使いこなせず翻弄される 518

448. 背伸びもせず 卑屈にもならずに 自分達の現在の理解から 会話を始めよう 519

449. None

450. 解決した問題よりも 売上が大きくなったら 罠を踏む 522

451. 解決した問題よりも 売上が大きくなったら 罠を踏む 解決できる問題よりも 高い売上を望んでしまったら 罠を踏む 523

452. 手っ取り早く価値に 手を伸ばせば 罠にかかる 524

453. チームで罠について たどたどしく話すことから はじめよう 525

454. None

455. 質を取り戻す 528

456. 価値の追求は 評価が難しい 529

457. None
458. None

459. 私たちが慣れ親しんだ プロダクトの 質的追求の枠組みが すでにある 532

460. NPVxyz 533

461. NPVxyz New Product Ver.x.y.z プロダクトにおける価値の度合い 534

462. New Product 535 Ver.x.y.z

463. 価値の追求では 最初からy.zレベルを 狙わない 536

464. 新しいプロダクトとして出せる NPレベルの価値を いつだって狙おう プロダクトバックログを 何をやっても効果のある アイテムでぱんぱんにしよう 537

465. 新プロダクトを作れるくらいの 価値を狙って探索し 543

466. 新プロダクトを作れるくらいの 価値を狙って探索し そこまでに至らない価値を x.y.zの順で既存プロダクトに 取り込む 544

467. New Product Ver.x.y.z NPとXレベルを 多頻度に実行することで 顧客の価値を継続的に 飛躍させる 545

468. バックログアイテムを 顧客の視点のNPVxyzで 評価してみよう 546

469. xyzそれぞれの価値を 顧客は認識しているのか 聞いていこう 547

470. None

471. 549

472. FC/SFC黄金時代 xレベルプロダクトを3年以内に コンスタントに作り続ける 550

473. None
474. None
475. None

476. 554

477. 555

478. 556

479. None
480. None

481. - 外れてほしい予言 - Webサービス、SaaSなどは 中長期的に渡って プロダクトマネジメント人材の 薄さに悩まされつづける 559

482. None

483. 昇進/異動/転職 サイクルベースで プロダクト開発組織の 質を追求しつづけよう 561

484. 罠を知り、乗り越え 大きな価値の実現と 滑らかなオペレーションを 短サイクルで両立していこう 562

485. 価値の黄金時代を 実現していくぞ! 563

486. V1.2 2024/01/16 60min V1.0 2024/01/11 Regional Scrum Gathering Tokyo 2024

     witch&wizards inc. 森 雄哉