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