https://www.amazon.co.jp/dp/4820727508 ## PART1 一流 IT 企業から学んだこと ### Chapter 6 製品開発が失敗する根本的原因 アイデアが出てから実際にリリースされるまでのフローについて、失敗の一例が紹介されている。 かなりあるあるだと思う。今の職場もこれまでも職場もだいたいこんな感じの開発フローとなっている。 アジャイルは導入しているが、エンジニアの参加も含めて一連のプロセスのかなり後の方になってしまっているので、アジャイルの利点を享受しきれていない。市場と対話するのが実際に機能ができてからになり蓋を開けてみれば誰もその機能は使われなかったという悲劇が起こっている。ある機能を作ることでどれだけの利益が得られて、どれだけのコストが掛かるのかが分からないまま、開発が決定した後にエンジニアがアサインされてしまっている。 ### Chapter7 リーンとアジャイルを超えて 優れた開発チームが取り入れている 3 つの幻想 - リスクには最後ではなく最初に取り組む - 製品の定義付けとデザインは順を追ってではなく、協調させながら同時に実行される - 大切なのは機能を実行することではなく、問題を解決することである ## PART2 成功するための組織と人 ### 製品開発チーム 優れた製品開発チームの原則とそれを構成するメンバーの役割と責任が説明されている。そしてプロダクトマネージャー視点で各メンバーとの協調の仕方が説明されている。 ### スケールアップに必要な人々 ## PART3 成功するための製品 ### 製品開発ロードマップ ロードマップもアウトカムベースでする。 市場投入を指定された期日で行う責任が生じる場合は必ずある。その際はハイインテグリティコミットメントをするのが良い。コミットメントにおける悩みの根本的原因はその時期が早すぎることであり、その時点では実現可能性が分からなく、アイデアに価値があるのかも分かっていないことが多い。なので、すぐにコミットメントをするのではなくそれらを検証する時間を取り、提供価値や提供時期やビジネスにおける価値についてより精度の高いコミットメントをすることができる。 ### 製品ビジョン ### 製品の目標 ## PART4 成功するためのプロセス ### 製品の発見 #### Chapter33 製品発見の原則 製品発見の目的は以下のリスクに対処することである。 - 価値のリスク 顧客はこれを買ったり、これを使うことを選んでくれるだろうか？ - ユーザビリティのリスク ユーザーはこれの使い方がわかるだろうか？ - 実現可能性のリスク 私たちはこれを作れるだろうか？ - 事業実現性のリスク このソリューションは私たちのビジネスに貢献するだろうか？ これらのリスクに対して、主観ではなく客観的なエビデンスを根拠として持つ必要がある。 ### 発見のフレーミングテクニック ### 発見のプランニングテクニック ### 発見のアイディエーションテクニック ### 発見のプロトタイピングテクニック ## PART5 成功するための文化 プロダクトマネージャーを対象とした本です。時間とお金は限られていてその中でいかに価値のあるものを作ることに時間を割くかということが大事で、そのために必要な登場人物や価値の見極め方、文化の醸成についてがプロダクトマネージャー視点で説明されています。プロダクトマネージャーのあるべき姿とプロダクトのあるべき姿はニアリーイコールだと思うので、プロダクトに関わるその他の人が読んでも損はないと思います。一方で具体的なテクニックなどにかなりの章が割かれているので軽くプロダクトがどうあるべきかなどを知りたい場合は冗長化もしれないです。内容的には Lean Startup や Lean UX と被るところが多いので大枠については 1 章だけで充分だと思います。 本書を読むだけでは分からなかったこと。絶対解はないのでこれについては考えるしかない。 - 利益 / 価値をどう定義するか 価値のあるなしは分かったとして、どれくらい価値があるかというのはフェーズや機能によっては難しいかも。 SaaS だと作った機能が直接収益に結びつかないと思う。複数の機能がある場合にどちらを優先するのかなど。 ノーススター指標のような SaaS プロダクトとして追いかけている指標に対する効果やユーザーストーリーでカバーをできていないところを埋めていくなどがある？ - 利益の時間軸はどう評価するべきか 開発工数は同じと仮定して、開発後すぐに 1000 万の利益を生む機能と 3 年後に 1 億円の利益を生む想定の機能のどちらを優先するか。 現在のキャッシュフローやランウェイなどにも左右されそう。 - 複数の基準での利益がある場合の優先順位の決定方法 ノーススター指標の〇〇が X％向上、〇〇万円の売上向上、CS の負荷を〇〇％減らしましょうというバックログがあった場合にどういうロジックで決定するか。頑張って 1 つの指標に統一する？ある種、決め打ちでフェーズごとに注力する目標を変えていく？ - 理想の開発フローへの移行のファーストステップ 現状があった上でどう理想の開発フローへ移行していくか。まずは価値の定義 / 価値を評価するところからか。