最近ではpmconfがあったり、いろんな書籍でプロダクトマネジメントという言葉を見かけるようになってきました。
今やプロダクトの価値をより良いものにすることが重要というのは当たり前になっていますが、それをどうやって維持・向上させるのかの方法論についてはなかなか語られていない気がします。
というわけで、今回はこちらの本でプロダクトマネジメントについて勉強してみたのでそのメモです。 まだ腹落ちしきってませんが、頑張って書いてみます。
INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
- 作者:マーティ・ケーガン
- 出版社/メーカー: 日本能率協会マネジメントセンター
- 発売日: 2019/11/01
- メディア: 単行本
tl; dr;
- プロダクトマネジメントとはプロダクトの価値を最大化するための行為
- プロダクトマネージャーは伝導師である
- エバンジェリズム（夢を売ること）が必要
- プロダクトマネジメントには、ロードマップではなくビジョンと戦略が必要
- ビジョンや戦略を実現するための目標は、OKRに則って定められるべき
- 製品発見は4つのリスクについて対処すること
- 価値のリスク
- ユーザビリティのリスク
- 実現可能性のリスク
- 事業実現性のリスク
- ビジョンや戦略、目標に基づき定性的・定量的なOKRを客観的に開発チームが評価・改善できるような文化が必要
背景
スタートアップ期からエンタープライズ期のよくあるプロダクトの変遷
スタートアップにとって、プロダクトとともに成長すると言っても過言ではないです。 このときは、いかに早くマーケットフィットするプロダクトを見つけられるかのスピード勝負になります。
その後、成長期では一度は成功したプロダクトを拡張し、様々な方向にスケールさせる様になっていきます。 この辺から、組織は大きくなり過ぎてコミュニケーションコストが増大し始めます。
さらに成長できたエンタープライズ期では、知らないうちに守りに入ってしまうことが多いそうで、 数年は過去の成功を使って生き延びれるが、ゆっくりプロダクトは成長を止め、やがてプロダクトは衰退してきます。 大体こんな感じです。
この例とは異なり例外的に、成長してきたのが今のGAFAなどのIT業界の巨人と言われる企業ということになります。
イノベーションが起きないワケ
昨今、これだけアジャイルだのリーンだの叫ばれてはいますが、本質的にはウォーターフォールと同じことをずっと行っている開発現場がほとんどです。 そして、そういった開発から革新的なプロダクトが生み出されない理由は、挙げたらキリがありません。
これを解決するには、おそらくかなりダイナミックなマインドチェンジが必要です。 アイデアや計画、マーケットへの投入までの開発、至るところで機動的かつ柔軟な動きがもとめられる一方で、 それらは大企業の経営者のような、経営を安定させる責任を持つ方々にとっては受け入れ難いものです。
機動性を持ったとしても、成功するとは限りません。 ここまでやっていても、ほとんど多くのスタートアップ企業が発生しては消えていくので、どこまで柔軟に対応しようと大きなリスクが伴います。
そんなわけで、そもそも革新的なプロダクト（とそれらを販売する企業）はそもそも出現すること自体が困難で、 特に日本のような保守的な考え方が強い国では計画を慎重に検討してから決定する傾向が強いので余計にイノベーションは起きにくいように感じます。
それでも、新しいテクノロジーを駆使したプロダクトを投入していかないと市場から脱落してしまうので、市場に受け入れられるプロダクトを見極め、その価値を最大化するためのプロダクトマネジメントが今後ますます重要になります。
プロダクトマネジメントとは
目的／ゴール
プロダクトマネジメントについては、こんな感じで紹介されていますね。
プロダクトマネジメントは「プロダクト価値最大化」のための活動
だそうです。 一般的に、何らかのゴールを設定しそこへ安全にたどり着くための管理（マネジメント）をプロジェクトマネジメントと呼ぶのに対し、プロダクトマネジメントはプロダクトの価値を高めプロダクトを終わらせないための活動となっています。
具体的には何するの？
サービスをローンチするまでに、こんなにもたくさんのことが日々行われています。
- 製品発見
- ユーザーはそれを買ってくれるか？
- ユーザーはその使い方がわかるか？
- エンジニアはそれを作れるか？
- ステークホルダーたちの支持が得られるか？
- プロトタイプの作成
- 必ずしもProductである必要はない。これは結構大事。
- 市場への投入
- マーケットフィット
（私の周りでは全然できてませんが、本当はやっているはずなんです。。。）
これらについて活動（マネジメント）することが、プロダクトマネジメントの具体的なタスクということができるでしょうか。
プロダクトマネジメントってどういう体制でやるの？
さて、だんだん視点を「何をやるのか」から「どうやってやるのか」に変えていきます。
プロダクトマネジメントをするにあたって、製品開発チームのあり方についてみていきます。
この本では
- プロダクトマネジャー
- プロダクトデザイナー
- エンジニア
- プロダクトマーケティングマネジャー
などが紹介されていました。実際には、プロダクトの特性に合わせてチームの構成は大きく変わります。 医療系のプロダクトなら、医療知識の専門家が必要ですし、法律系のプロダクトなら法律の専門家、コーヒーのプロダクトならコーヒーの専門家…のように多種多様になります。
細かい役割はおいておいて、チームを作る上でのポイントで気になったのは、
- ピザ二枚ルール（8~12人）
- プロダクトマネジャーは誰の上司でもない（上下関係はない）
- 真の意味でのコラボレーションが推奨される
- その他の条件が同じであれば、なるべく同じ場所で働くほうが良い
- 業務の責任範囲はUX（顧客体験）まで
あたりでしょうか。 深読みするなら、顧客体験を開発する十分に精神的にも物理的にも近いチームが望ましいという感じでしょうか。
プロダクトマネジャー
最近では、プロダクトマネジメントに責任を負う、プロダクトマネジャーという職種も徐々に市民権を得てきました。 基本的にプロダクトマネジメントについて責任を負っているプロダクトマネジャーなので、この文脈ではこのロールが一番重要と予想されます。 ということで、プロダクトマネージャーについてみていきます。
責任範囲
プロダクトマネジャーの責任は
可能性を評価し、何を作って顧客に届けるかを判断すること
だといい、
プロダクトマネジャーこそが製品の成功に責任を持ち、説明責任を負う人
だそうです。
求められる役割・能力
責任に紐づく役割や能力を考えると下記のようなものがあげられるかと思われます。
- 顧客に関する深い知識
- データに関する深い知識
- 自分のビジネスについての深い知識
- 市場に関する深い知識
- 頭がよく、創造的で、粘り強いこと
これだけ見ただけで、もう嫌になってきました。 これ全部できる人って、言い換えるとある種のスーパーマンです。 そんなわけもあって、おそらく会社で一番優秀な人がやるのがいいんでしょう。
プロダクトオーナー？プロダクトマネージャー？
蛇足ですが、過去に何の気なしにこんなことをつぶやいていました。
最近仕事してて思うのは、お客さんがほしいのは優秀なエンジニアじゃなくて、優秀なPOなんだなあということ。
— 野川の側 (@nogawanogawa) 2019年11月8日
ここで疑問になるのはプロダクトマネージャーとプロダクトオーナーは違うのか？ということです。
本書を参考にする限り、プロダクトオーナーの役割はプロダクトマネージャーの一部に過ぎないそうです。 製品の発見を考えてみても、何が効果があるかはPOも考えますが、PdMほどマーケットフィットは気にしない気がします。 （実際にはそこまで考えているPOもたくさんいらっしゃると思いますが） そういう事情もあり、理想的には、プロダクトマネージャーとプロダクトオーナーは同じ人間のほうが良いです。
他に、調べると、こんな感じの資料がありました。
※諸説あるらしいですが、個人的に納得感があったので拝借させていただいております。
やはり、微妙に違うようですね。
プロダクトオーナーはチーム寄り、プロダクトマネージャーは市場寄りのポジショニングとなっているのが興味深いです。
どちらも、マーケットのニーズを踏まえたうえでプロダクトの価値を最大化させることが目的ですが、立場が少しずつ違うので役割もおのずと違ってくるようです。 そして、スピード感ある開発のためにはこれらを同じ人間が兼務することが望ましいですね。
ロールの分類からわかること
ここに挙げた以外にも、エンジニアやユーザーリサーチャー、データアナリスト、テスト自動化エンジニアなど、プロダクトの価値を向上させ続けるためには、実に様々な分野の人間が必要な事がわかります。
エンジニアだけでは本当の意味でのプロダクトは作れないということがよくわかります。 特に、マーケットに投入するということを考えたとき、デザイナーの存在は必須ですし、マーケティングに関しても詳しい人がいないと話になりません。
個人的には、この辺を軽視している輩が周りに結構いる（特にデザイナーやマーケターについては過小評価されやすく後回しにされがちだと感じることが多々ある）ので、未だにそのへんを軽視する風潮は根強いのかなと思ってますが。
目標と計画
プロダクトを考える上で、大きなマインドチェンジをしなければいけないことといえば、目標と計画の考え方でしょう。
従来ではロードマップを作成して、機能単位で開発期間を区切って作り上げていくかと思います。 このロードマップに対する問題点は、次のような問題意識が抜け落ちて作成されている点だといいます。
- まだ実装していないプロダクトが本当に目標を達成できるかわからないうちに期限を約束している
- 仮にプロダクトが価値を持っていたとしても、ユーザー体験を満足させるまでには数回のイテレーションが必要になる
本当に必要なことは、プロダクトによってビジネス上の目標を達成させることのはずです。 しかし、それをわかりやすく進捗状況を把握しようとして、現在のようなロードマップの形式が受け入れられてしまっています。
経営者にとっては受け入れにくいですが、プロダクトマネジメントで必要なのは、何をいつまでに作るかを示したロードマップではなく、（ある程度テスト可能な）目標に対してどうやって解決しようとしているかを示すことが必要になります。 プロダクトマネージャーはこれらを開発チームと共有し、同時にステークホルダーや経営者にこの価値観を浸透させ、合意を得ることも役割の一つとなります。
ビジョンと戦略
製品ビジョンは、だいたい2年から5年ぐらいの間に実現しようと考える未来を描いたものである。 INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
ビジョンは開発チームが手伝いたくなる動機になる。
製品戦略とは、製品ビジョンを現実化する途上で提供を計画している製品あるいはリリースの一連の出来事のことである。 INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
ビジョンによって実現したい未来を示すのに対し、戦略によってたどり着くためのチェックポイントのようなものを示します。
目標
個人的にポイントだと思っているのは、ビジョンはある程度テストできる必要があるということです。 ビジョンの達成にむけて近づけているかは一定期間ごとに測定される必要がある。 でないと、エンジニアはなんのゴールに向けてなんのパラメータを最適化すればよいかに迷ってしまうからです。
ビジネス上の目標の設定方法として、OKR (Objective Key Results) という考え方があります。 目標は定性的に表現し目指す意義を示すべきである一方、指標（Key Results）によってそこに向かってどれだけ近づけたかを測定できるようにします。
これは裏返すと、プロダクトのビジネス上の価値をどうやって定量的に測定するかをエンジニアに事前に示し、絶えずその評価関数を最適化するタスクをエンジニアが行うと言う構図になります。
成功のためのプロセス
「マインドセットは良いから実際どうすりゃいいのか？」という問題はたしかにあって、この本では大量にプロダクトの価値を高めるテクニックが紹介されていました。
製品発見の全体像
製品発見の目的は、4つのリスクに対処することだといいます。
- 価値のリスク
- 顧客はこれを買ったり、これを使うことを選んでくれるか
- ユーザビリティーのリスク
- ユーザーはこれの使い方がわかるか
- 実現可能性のリスク
- これを作れるか
- 事業実現性のリスク
- このソリューションは我々のビジネスに貢献するか
これらのリスクに、確証を持ってYesと言える必要があります。 これらの証拠を集めるためのテクニックはたくさんあるようですが、この本で紹介されていたのは目次を見る感じこんな感じでしょうか。
- フレーミング
- 取り組むべき潜在的な問題を発見する
- プランニング
- 大きな問題を特定し、それにどう立ち向かうか計画する
- アイディエーション
- アイデアを出す、そのために最も重要な問題に的を絞る
- プロトタイピング
- 時間をかけず、最短で試作する
- テスト
- アイデアを迅速に試す
細かいところは本買って読んでください。以下、気になったところだけメモしていきます。
気になったポイント
フレーミング
プロダクトを発見するまでに、様々な問題に遭遇し、それらに対して対処しないといけません。 一方で、すべての問題が検討されない、優先して対応すべき問題が後回しにされるといったことが発生しがちです。
そんなときはフレーミングのテクニックを使用すると良いらしいです。 詳しくは本読んでください。
ただポイントとして、対応できそうな問題ではなく、対応する必要がある問題を客観的に見極めることです。
プロトタイピング
プロトタイピングという言葉は、聞く人にとって様々なイメージがあるようです。
これでおそらくポイントになるのは、実際にものを作るよりコストを最低でも1桁小さく済ませるというコンセプトでしょう。
そのために、オズの魔法使いのようなプロトタイピングもあれば、動的なしくみをすべて排除した静的webサイトが使われることもあります。 何れにせよ、製品の発見にかかるコストを実際に開発するより最低でも1桁減らすことを意識する必要があります。
テスト
なんの問題に（フレーミング）どういう方針で対応するか（プランニング）、そのためのアイデアが洗い出されたら(アイディエーション)、それらをテストする必要があります。 何をテストするかによって内容がだいぶ変わります。
- 顧客はこれを買ったり、これを使うことを選んでくれるか
- ユーザーはこれの使い方がわかるか
- これを作れるか
- このソリューションは我々のビジネスに貢献するか
詳しくは本読んでいただきたいのですが、多分これは決まったやり方はほとんど言えないです。 プロダクトの性質によって、顧客の定義も作る範囲も、コアとなるリスクも、コストも変わってくるので、プロダクトごとに考える必要があるはずです。 逆にいうと、製品発見においては、PdMはここまでをデザインする能力が求められると言えそうです。
ディスカバリースプリント
これは後で別の記事を書くので省略。 (年内には書きたい…)
SPRINT 最速仕事術――あらゆる仕事がうまくいく最も合理的な方法
- 作者:ジェイク・ナップ,ジョン・ゼラツキー,ブレイデン・コウィッツ
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2017/04/13
- メディア: 単行本（ソフトカバー）
文化
ここはもういくらでも出てきます。 個人的に一番大事だと思ったことだけメモします。
良い開発チームがひらめきやアイデアを得るのは自分たちのビジョンや目標からであり、顧客が苦労している様子を見ることや、自分たちの製品を使うことで顧客が生み出すデータを分析すること、実際の問題を解決するために常に新しいテクノロジーを適用しようとすることからである。悪い開発チームは販売部門や顧客から要望を集める。 INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント
顧客中心なのは悪いことではないですが、顧客の言いなりになることとイコールではないですよね。 (本当に顧客が困っていることは顧客自身も自覚してないのかもしれません。)
一方、自分たちの考えを押し通すのはもってのほかです。 なので、ビジョンや戦略、目標についてはステークホルダーと合意しつつ、定性的・定量的なOKRを客観的に開発チームが評価・改善できるような環境が、一番効果が出るのかなと思っています。
その他、参考した資料とか
ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略
- 作者:及川 卓也
- 出版社/メーカー: 日経BP
- 発売日: 2019/10/10
- メディア: 単行本
（↑関連する記事がいっぱいあるので、まだ読んでないやつとか面白そうでした。エムスリーさんの記事は実際にやっている方の意見として非常に参考にさせていただきました。）
感想
インスパイアド読んでるけど、なかなか噛み砕けてない。これは何度も読まないといけない本だなぁ。。。
— 野川の側 (@nogawanogawa) 2019年12月17日
一周通読してみましたが、腹落ちしきっていないというか、理解しきれていないと感じています。 今やっている開発のやり方とは、そもそもの考え方が違っていて、何度も読み直して腹落ちさせたい内容でした。
最後に、
pmconf行きたかったなあ。。。次回こそは。。。
