プロダクトマネージャー1年生が業務に活かしたビジネス書籍5選
はじめに
株式会社Mobility Technologiesで、タクシーアプリ「GO」の法人向けサービス「GO BUSINESS」のプロダクトマネージャー（PdM）を担当しているTannyです。こんにちは。
私は社会人6年目になりましたが、PdMという職種を担当し始めたのは昨年からです。最初はPdMがどんな役割なのかもよくわかっていなかったので、とりあえず色々なビジネス書を読んで勉強してみることにしました。
今回は、そんなPdM 1年生の私が読んできたビジネス書の中で、業務にも活かすことのできたものを5冊紹介します。PdMの視点でどういう学びが得られたかも記載していますので、PdMになりたての方の参考になればと思います！
1. 『プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで』
プロダクトが成功した姿だけを見ると、プロダクトマネージャーは華やかな職種に見えるかもしれない。だが実施は、プロダクトを成功に導くためには学ばなければならないことが膨大にあり、一つひとつを着実に粘り強くこなさなければならない泥臭い仕事である。
PdM業務の「すべて」をこの1冊で
プロダクトマネージャーとして業務を進めていく上で必要な知識が「すべて」一冊に収められているのがこの本です。プロダクトマネージャーの教科書として、定番化しつつありますね。
本書ではまず、PdMの基本的な業務である、「ビジョン（Core）の策定」「課題（Why）の特定」「解決策（What）の検討」「機能（How）の実装」の進め方について体系的にまとめられています。それぞれのフェーズで活用できるフレームワーク（バリュー・プロポジションキャンパス、カスタマージャーニーマップなど）も実用例付きで紹介されており、「型」に沿って仕事を進める方法を学ぶことができます。まずはこの手順を実践することで、「企画チームの要望を仕様に落とし込むだけの人」から「プロダクトマネージャー」へとステップアップできるでしょう。
また、プロダクトは一度だけ開発・リリースして終わりではなく、その後も成長させ続けることが求められます。本書では、プロダクトのステージ（0→1、1→10、10→100）の違いや、それぞれのステージでPdMに求められる、ふるまいについても整理されています。私はGOという10→100のプロダクトと、GO BUSINESSという0→1のプロダクトに関わっているため、この違いを明確にできたのは大きな学びでした。
周辺業務の基礎知識も身につける
この本の特筆すべきところは、事業戦略・マーケティング・UIデザインなど、プロダクト開発と運用に必要な周辺知識も網羅していることです（後半の1/3弱のボリュームを割いています）。PdMは多くの職種の方と関わりますが、それらの人と会話するために必要な知識は、ここからほとんど把握することができました。
例えば、私はマーケティングの知識が全くなく、LTVとかCACといった用語がさっぱり分からなかったのですが、これらの基礎知識は本書で学ぶことができました。さらには、「ネットワークの仕組み」や「データベースの仕組み」といったシステム開発の基礎知識も分かりやすくまとめられているため、技術職出身でないPdMの方にもおすすめです。
この本の学び
いきなり機能を考えるのではなく、Core→Why→What→Howの順番で、ユーザー課題の解決方法を考える
プロダクトの成長状態に応じて3つのステージがあり、それぞれのステージでPdMのふるまい方は異なる
事業戦略・マーケティング・UIデザインなど、PdMと関わりのある専門分野の基礎知識について
2. 『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』
プロダクトマネージャーは、時間の大部分を、製品開発チーム、主要なステークホルダー、顧客と共に仕事をすることに使わなければならないし、顧客に愛され、ビジネスに貢献するソリューションを発見しなければならない。
プロダクトマネージャーの使命を知る
こちらは社内の先輩PdMの方におすすめしてもらった1冊です。本書では、なぜ従来のやり方（例：ウォーターフォール開発）ではプロダクト開発がうまくいかないのか、どうやれば顧客に愛されるプロダクトを開発できるのか、そのためにプロダクトマネージャーは何をすべきなのかが熱く語られています。
課題解決にフォーカスする
私はこれまで、「ロードマップに書かれた機能をスケジュール通りに実装したけど、結果に結びついていない」というケースに何度か遭遇してきました。以下の状況に共感する人も多いのではないでしょうか。
本当に問題なのは、「ロードマップ」と題された文書にアイデアのリストを書いた途端、どれだけ多くの免責事項が書かれていても、会社中の人々がそれらの項目を約束事項として理解してしまうことである。
本書では、機能がロードマップではなく「課題解決」にフォーカスし、課題解決に向けて「製品開発チーム」を率いていく方法を学ぶことができます。
私たちは本質的な問題を解決する必要があるということだ。ただ機能を提供すればいいのではない。
先に挙げた『プロダクトマネジメントのすべて』との違いは、本書は「プロダクトマネージャー」という職種に焦点を当て、ロードマップに注力してしまいがちな組織の中で、PdMがどのように課題解決を達成するかを説明していることでしょうか。「『プロダクトマネジメントのすべて』を実践できるような理想的な環境は持ってないよ」と感じる方にはおすすめです。ぜひ両方とも読んでみて、「INSPIRED」されましょう！
この本の学び
「ロードマップ」には機能ではなく、解決したい課題を書く。その課題を発見するのはPdMの仕事。
優れた「製品開発チーム」を構築し、率いていくのもPdMの仕事。
3. 『スクラム 仕事が４倍速くなる“世界標準”のチーム戦術』
物事を進めるには二つのやり方がある。多額の予算を費やしながら何も生まない、従来のウォーターフォール型か、少ない人員と短い期間で、より質の高いものを低コストで多く提供できる、この新しい方法か。
スクラムの本質を知る
前の職場で、「Scrum Inc.認定スクラムマスター研修」を受けた時に頂戴した本です。開発チームでスクラムを導入していて、なぜスクラムが必要なのかを体系的に知っておきたい人におすすめです。
著者の「ジェフ・サザーランド」はスクラムの生みの親であり、本書ではどのようにしてスクラムを形作っていったか、その根拠とともに説明されています。そのため、「スプリント」や「プランニング」といったスクラムの要素が、どのような意図を持って構築されているかを理解することができます。
これらの要素がどんなメリットをもたらしているのか、スクラムをうまく実践できていない時にどんなデメリットが生じているのかが分かるため、もっと上手に、スクラムの各種イベントを原則に沿って実践したいと思えるようになりました。
スクラムが目指すこと
この本を読んで気づいたことは、スクラムとは、仕事を「ムリ・ムラ・ムダ」なく進めるための方法だということでした。そうすることで、最も効率よく成果を出すことができるようになります。スクラムの各種の決まり事は、それをチームで実践する手助けになります。
この本の学び
マルチタスクは失敗の元。同時に複数のことをしようとすると、スピードが落ち、結局どれもうまくいかない。
ヒーローはいらない。華々しい頑張りや努力は仕事の進め方に問題があるものと認識するべき。
必要な分だけ計画する。ずっと先のことまで計画しようとしない。チームがさしあたり目の前に仕事がある状態であれば良い。
これもおすすめ｜『トヨタ生産方式』
余談ですが、この本を読んでちょっと驚いたことがあります。それは、スクラムの考え方の多くは「トヨタ生産方式」を参考にして作られているということです。日本の製造業で成果を上げていた手法を、プロダクト開発の進め方に応用したのがスクラムだったんですね。
スクラムの本質をもっと学んでみたいという方は、以下の書籍もおすすめです。およそ40年前に書かれた本ですが、現代の仕事の進め方にも適用できる考え方がまとめられています。
4.『多様性の科学 画一的で凋落する組織、複数の視点で問題を解決する組織』
チームで難問に挑む際にまずやるべきことは、問題そのものをさらに精査することではない。むしろ大事なのは、一歩下がってこう考えることだ。我々がカバーできていないのはどの分野か？無意識のうちに「目隠し」をして盲点を作ってしまっていないか？あるいは画一的な人間ばかりで問題空間の片隅に固まっていないか？
複数の視点で課題を解決する
PdMの仕事とは、課題を発見し、それをプロダクトで解決することだと学びました。ただし、問題を正しく認識するためには、チームの多様性こそが重要であると教えてくれたのが本書です。まずは以下の図をご覧ください。
図の右上は、PdMが一人で課題を考えている時の状態ですね。そして右下は、同じチームのPdM同士で議論している状態です。「問題空間」を幅広くカバーするためには、左上の状態を目指す必要があります。これは、PdMだけでなく、エンジニア・デザイナー・CSチーム・企画チームなどなど、プロダクトに関わる様々なチームと議論した状態です。
私がPdMとして一人でPRD（要求仕様書）を書けるようになった時、他の人にレビューしてもらうと必ず抜け漏れを指摘されていました。その結果、「PRDの精査が足りないのでは？」と考えて、自分一人での精査に時間をかけてしまう傾向がありました。しかしこの本を読んで、一人では認識できる範囲に限界や偏りがあるため、むしろ積極的に関係者と議論し、どんどん指摘をもらうべきだと考え方が変わりました。今では、解決したい課題と関わりそうな人と積極的に議論し、忌憚なき意見を集めるようにしています。
平均値の罠
また本書では、プロダクトのユーザーもまた多様であるということに改めて気付かせてくれます。米軍の航空機のシート設計の事例では、「あらゆるパイロットの体格の平均値」に合わせてシートを設計したところ、誰にもフィットしないシートが出来上がっていた、という例が紹介されています。
これはプロダクト開発でも同じですね。「平均的なユーザー」に合わせてプロダクトを設計すると、そんなユーザーは存在しないという状況が発生する可能性があります。課題を考える時には、「本当にそのユーザーは居るのか」という点に着目したり、個々のユーザーにフィットするように、機能にカスタマイズ性を持たせることも重要です。
イノベーションを起こす
「誰でも一定の枠組みで物事を捉えている」と指摘する本書ですが、その枠組みを外すための手法も取り上げています。その中でもお気に入りなのが「前提逆転発想法」です。問題の核となる前提条件を逆転させてアイデアを生み出すというものです。これは具体例がなるほどと思いました。
タクシー会社で考えてみるとどうだろう？大前提は「タクシー会社にはタクシーがある」。その逆は「タクシー会社にはタクシーがない」だが、20年前にそんなことを言ったら頭がおかしいと思われて終わりだったろう。しかし今日、タクシーを1台も持たないタクシー会社が世界的に大成功を収めている。User（ウーバー）だ。
チームで仕事をする全ての人に読んでもらいたい名著ですが、1人で孤立しがちだと言われるPdMという職種には特におすすめです。
この本の学び
誰でも一定の枠組みで物事を捉えているが、その枠組みは自分には見えない。複雑な問題に対応するは、多様な視点が必要となる。
集団にはリーダーが必要。しかしリーダーが懸命な判断を下すためには、その集団内で多様な視点が共有されている必要がある。
平均値が適切に使用されれば、複数の人々の視点や意見を活かせる。しかし不適切な場合は、複数の人々に平均的な機能を押しつけることになる。
これもおすすめ｜『失敗の科学』
この本を気に入った方は、同じ筆者の著作である「失敗の科学」もおすすめします。人は本能的に失敗を遠ざけてしまうが、失敗から学習することこそが、次の成長に必要だということを教えてくれます。PdMの業務に失敗はつきものですが、これを読めば失敗に対する向き合い方がガラリと変わります。
5. 『PLG プロダクト・レッド・グロース 「セールスがプロダクトを売る時代」から「プロダクトでプロダクトを売る時代」』
もしグーグルで検索する前に、利用料を支払わなければならないとしたら？
もしウーバーを始めて利用する前に、デモを申請するようにと言われたら？
もしスラックに登録する前に、営業担当者と話す必要があるとしたら？
プロダクトの価値を伝えてプロダクトを売る
ユーザーの課題を解決する素晴らしいプロダクトを開発できたとしても、それがユーザーの元に届かなければ意味がありません。本書では、プロダクトの力でプロダクトを売る、「プロダクト・レッド・グロース（PLG）」の考え方について、なぜPLGが必要とされているのか、どのような手順でPLGに転換するか、と言った内容を、具体例とともに説明しています。
プロダクトの価値をいち早く伝える方法を学ぶ
冒頭で引用したように、サブスクリプションサービスやアプリなど、私たちは「試したい時にすぐに試せる環境」に慣れています。そのため、プロダクトを使い始めるまでに大量の個人情報の入力が必要だったり、ログインしてもプロダクトの価値を理解できなかったりすると、ユーザーはすぐに離脱してしまいます。Googleアカウントですぐにログインできるサービスや、ログイン後にウェルカムメールを送ってくるサービスは、PLGを取り入れていて、これらの課題に対応していることがわかります。
全てのプロダクトで、今すぐに営業チームを廃止して完全なPLGに移行するというのは非現実的です。しかし、「プロダクトにいち早く触れてもらうためのアカウント作成フローの見直し」「プロダクトの価値を伝えるためのメール文面の改善」「マニュアルを読まなくてもプロダクトを使える説明」などの施策は、プロダクトの改善施策として、PdMの力でも導入することができます。
プロダクト自体の機能はある程度実装できていて、次はユーザーへの届け方を見直したいと考えているPdMの方にはおすすめの一冊です。
この本の学び
購入プロセスにおいて、プロダクトの利用体験が重視されるようになった現在、PLGの重要性が高まっている。
まずはプロダクトの価値を理解し、その価値をプロダクトを通じて届ける方法を、営業チーム・CSチーム・マーケチーム・プロダクト開発チームは考える
プロダクトを利用開始するために必要な情報は最小限に絞る。ログインしたユーザーにはウェルカムメールやオンボーディング機能を通じて、プロダクトの価値を理解し、体験してもらう。
おわりに
今回は、私が読んだビジネス書の中で、業務にも活かせていると感じたものを紹介しました。いかがだったでしょうか。
私はどちらかというと、個社・個人の成功事例が書かれた本よりも、原理・原則がまとめてある本の方を好んで読んでいる気がします。その方が、いろんな業務やプロダクトに応用できるからです。今後は、もう少し個別の内容に特化した本（例えば、1つのフレームワークに関する専門書など）のインプットも増やしていき、より専門的な知識も身につけたいと考えています。
みなさんもおすすめの書籍があれば、コメント欄で教えていただけると嬉しいです！
この記事が気に入ったらサポートをしてみませんか？