【読書メモ】 プロダクト開発が失敗する根本的原因 by INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
はじめに
最近またプロダクトマネジメント関連の本を読んでいて、最近は、INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント という本を読んでいます。プロダクトマネジメント関連の名著で有名ですね。
この本は、プロダクト開発を成功するさせるための要素を組織だったり、開発プロセスだったり、さまざまな切り口から説明してくれているのですが、しょっぱなからそもそもプロダクト開発が失敗する原因について説明しています。
このプロダクト開発が失敗する原因が、自分にとっては衝撃的というか、ハッとさせられたことだったので、読んで学んだことの要点と感想を書いていこうと思います。
製品開発が失敗する根本的原因
圧倒的多数の企業が アイデア → ビジネスケース → ロードマップ（工程表）→ 要求事項 → デザイン（設計）→ ビルド（製造）→ テスト → デプロイ（展開）という開発プロセスで製品開発を行って失敗する、と書かれています。
このプロセスの問題点
アイデアの時点で、販売主導やステークホルダー主導の製品につながってしまうこと。さらに、この開発プロセスでは、開発チームへの権限委譲が行われず、開発チームはただの傭兵に過ぎないこと。
どれだけの利益が得られるかと、そのコストがどれだけかかるかが大事だが、このプロセスのビジネスケースの段階ではそのどちらもはっきりわからない。
ロードマップを立てたとしても、アイデアの少なくとも半分がうまくいかないこと。ユーザーは私たちが思うほどその機能に心躍らされないし、すごく気に入ったとしてもそれを実現するのに必要な資金や時間が足りないから。また、可能性が証明されたアイデアでさえも、それで事業収益を得るためには、時間がかかること。
このプロセスでは、エンジニアのために要求事項を文書化することが中心になるので、そのそもプロダクトマネジメントとはいえず、プロジェクトマネジメントになってしまうこと。
デザインが入るのが遅すぎること。
エンジニアの介入が遅すぎること。エンジニアはこの議論プロセスに招かれることすらない。
ビルド（製造）のタイミングでようやくスプリントを回すため、アジャイル開発の原理や主要な利点を取り入れるのが遅すぎる。
このプロセス全体がプロジェクト中心になってしまっていること。プロジェクト全体がアウトプットであり、製品がアウトカムになるため、最終的には何かがリリースされるが、それは目的に合致したものではない。
このプロセスの最大の欠点は、すべてのリスクが最後に来ること。顧客実証が行われるのが遅すぎる。
このプロセスを実行することに忙しくなってしまい、組織が本来選択すべきだったことの機会損失が発生してしまうこと。
感想
自分のチームではスクラム開発をもとにプロダクトを作っていますが、まさに結構この本のプロセスに似たことをやっているなと、ハッとさせられました。
取り組んでいるのがプロダクトのリプレイスですが、旧プロダクトの仕様を改善するための議論にエンジニアを呼ぶのが遅いのが課題です。
もっと早いタイミングで議論に参加してもらえれば、最小工数で最大工数を叩き出せたかも、と。
自分の仕事のプロセスを変える必要があるかなと思いました。そして、そのプロセスを変えるのはそこまで難しくないのかなと。
たたき台や仮置きの結論ベースに議論に巻き込めば、エンジニアも嫌な顔せず議論に入ってくれることは過去の経験からわかっているし。
この記事が気に入ったらサポートをしてみませんか？