2.1 プロダクトマネージャーの2種類の仕事
プロダクトマネージャーには2種類の仕事がある（図表2-1）。プロダクトを育てることと、ステークホルダーをまとめプロダクトチームを率いることである。プロダクトマネージャーは、中長期の戦略立案、ビジョンの構築、プロダクトのビジネス、開発、UX（User Experience：ユーザー体験）のすべてのプロセスに携わり、ステークホルダーの承認を得たうえでプロダクトに関係する意思決定に責任をもつ。
図表2-1 プロダクトマネージャーの2種類の仕事
しかし実際に、プロダクトマネージャーが1人ですべての意思決定をするとなると、そこがボトルネックになってしまう可能性がある。それを支えるのがプロダクトチームの存在である。プロダクトマネージャーはプロダクトチームに意思決定の権限を委譲して、チームとして最善の意思決定ができる基盤を整える。
プロダクトを成功に導くためにプロダクトマネージャーが幅広い役割と責任範囲をもつことから、「ミニCEO」とよばれることがある。実際にはプロダクトマネージャーとCEOの役割には大きな差があるが、両者に共通して求められるのは、プロダクトの成功のために必要なことすべてに目を配り、こだわり抜くことである。
大企業のように事業に多くのメンバーが関わる場合にはCEOが自ら手を動かすことはほとんどないが、スタートアップの場合にはCEOが自ら手を動かすことも多いだろう。たとえば、専門性が必要とされるタスクがあったときにスタートアップのCEOが取るべき手段は、専門性があるメンバーを外から探すか、自分も含めた誰かが専門性を身につけるかの二択となる。専門性の獲得方法を主体的に検討しなければならない。同様に、プロダクトマネージャーもプロダクトを成功させるための武器が足りない場合には主体的に探す姿勢が求められる。
一方で、プロダクトマネージャーとCEOでは権限とその責任範囲が異なる。CEOは経営事項すべての責任を担い、そのための権限を有す。最終的には社員の採用や育成と評価、会社の組織戦略の立案と実施、企業活動を行うための資金確保も含めたすべての責任をもつ。プロダクトマネージャーは人事権を有さず、予算獲得のために外部からの資金調達を単独で行うことはできない。
つまり「プロダクトマネージャーはミニCEOである」とは、「プロダクトマネージャーはCEOのようにプロダクトの成功を自分ごととして成し遂げる情熱や強い興味、好奇心をもつ役職である」ということである。したがって、CEOのような経営や財務にまで及ぶ幅広い知識がなくてもプロダクトマネージャーは務まる。
2.1.1 プロダクトマネージャーに必要な3つの領域
プロダクトマネージャーの仕事に必要な領域はビジネス、UX、テクノロジーの3つである（図表2-2）。ビジネスはプロダクトが市場でユーザーを獲得し、収益を上げることができるかを判断する領域。UXはユーザーが本当に求めているものを発見し、使われる形で提供するための領域。テクノロジーはその実現可能性を判断する領域である。
図表2-2 プロダクトマネージャーの仕事に必要な3つの領域
プロダクトマネージャーの役割はこの3つの交差領域であるともいわれ、これらの領域に基づいてプロダクトを舵取りしていくことがプロダクトの成功への近道となる。
2.2 プロダクトとは
2.2.1 プロダクトとプロダクト群
プロダクトマネージャーの仕事はプロダクトを成功させることである、と述べた。では、そもそもプロダクトとは何か。本書では、プロダクトを「市場において顧客となりうる個人や団体に価値を提案するもの」と定義する。
主にITを活用したプロダクトに焦点をあてて解説をしており、ソフトウェアのみならずパソコンやスマートフォンのようなハードウェアやOS、ブラウザ、さらにはクラウド技術などにも幅広く適応できるようなプロダクトマネジメントについて取り扱う。
また、1つのプロダクトはユーザー価値の違いによって複数のプロダクトに分割できる。加えて、プロダクトには複数の機能が含まれ、共通のビジョンをもった複数のプロダクトをプロダクト群としてまとめることもある。
あるSNSプロダクトを例に考えると、このプロダクトの中には、文章や写真を投稿する機能、友だちの投稿をタイムライン上で閲覧する機能、投稿に「いいね」でリアクションをする機能などがあるとする（図表2-3）。また、SNS上でつながっている友だちと個別にメッセージのやりとりをする機能もある。この場合、開かれた関係性でのコミュニケーションを目的とするSNSとしてのプロダクトと、閉じた関係性でのコミュニケーションを目的とするメッセンジャーとしてのプロダクトの2つを１つのプロダクト群として一括することができる。
図表2-3 あるSNSプロダクト群を分解した例
1つのプロダクトを複数に分割したり、プロダクト群として一括に扱ったりすることで、1人のプロダクトマネージャーがもつ責任範囲を限定することができる。たとえば、プロダクト群全体に責任をもつAさん、SNSはBさん、メッセンジャーはCさんといった要領で、複数のプロダクトマネージャーで分担できる。
また、新人のプロダクトマネージャーにはSNSプロダクト中の「いいね」機能のみをプロダクトと見立てて担当してもらうのもよいだろう。ミニCEOとして小さなプロダクトを成功させる経験を重ねることで、やがて大きなプロダクトの意思決定ができるプロダクトマネージャーとして素早く自立していくことができる。
プロダクトマネージャーが複数人いる組織の中では、どのプロダクトマネージャーがどこまでの範囲を管理するのかを明確化することも重要となる。プロダクトマネージャーの役割分担についてはPART Ⅳで改めて述べる。ここでは、プロダクトとは大きなプロダクトやプロダクト群だけを指すのではなく、複数人で分担してつくり上げていくものであることも知っておいてほしい。
2.2.2 事業とプロダクトの関係
近年、プロダクトは事業であるともいわれるようになった。従来は、事業の中にプロダクトをつくる開発部署をもつことが一般的だったが、ITが事業の中心で活用されるにつれて事業とプロダクトの垣根が曖昧となってきた。
たとえば、これまでのカスタマーサポートはユーザーからの問い合わせ一つひとつに対して、人間が回答するのが一般的であり、プロダクトをつくる開発部署とは別の部署だった。しかし、プロダクト自体にユーザーのオンボーディング（初回利用）を補助する機能や、チャットボットがユーザーの質問に答えるフォームをつけることで、ユーザーはカスタマーサポートに問い合わせる代わりに、プロダクトを利用する体験の中で戸惑いを解消するようになった。
この新しいカスタマーサポートの概念は、サポートの域を超えて能動的に働きかけることからカスタマーサクセスとよばれている。このように、従来はプロダクトの外で別の組織が担当していた業務が、IT活用によって自動化され、より効率よく運用できる仕組みとしてプロダクトの中に取り込まれることで、プロダクトの範囲が広がっていった。これにより、ユーザーはプロダクトの中で体験を完結できるようになり、プロダクトの外の組織が担当していた業務は最適化され、よりユーザー価値を高めるための仕事に専念できるようになった。
本書では、過去にプロダクトとよばれていたプロダクトチームによるアウトプットである成果物を狭義のプロダクト、現在のように事業との垣根がなくなったカスタマーサポート部署や成果物を販売するための営業部署を含めたほうを広義のプロダクトとよぶ（図表2-4）。たとえば、カスタマーサポート部署の従来の仕事は機能として狭義のプロダクトに多く含まれるようになったが、そこで解決できなかった特異なケースに対応するためのカスタマーサポート部署は広義のプロダクトの中に含まれる。
図表2-4 狭義のプロダクトと広義のプロダクト
一般的にプロダクトといったときに、成果物単体を指している狭義の意味で使われていることもあれば、アウトプットとそれに付随する広義の活動すべてを指していることもあるため、どちらの意味を指しているかは注意してコミュニケーションを取るようにしてほしい。本書で取り扱うプロダクトは広義のプロダクトである。つまり、プロダクトマネージャーは事業（≒プロダクト）の成功に責任をもたなければならないことになる。
プロダクト≒事業であるなら、プロダクトマネージャー≒事業責任者（事業部長）なのだろうか。その答えは、組織によって最適なものを探してほしい。事業収益の土壌となるプロダクトをつくることと、実際にそのプロダクトをもって営業し売上を拡大することは役割を分けることもできる。その結果、売上を含む事業責任をプロダクトマネージャーの責任外とする組織もあれば、そうでない組織もあり、各メンバーのスキルセットやプロダクトの特性に応じて責任範囲を決めるとよいだろう。
しかし、すべてをプロダクトマネージャーが背負い込むとプロダクトマネージャーがボトルネックになることがある。たとえば、売上に関する責任をプロダクトマネージャーに求める場合には、エンジニアチームとの関わりに別の担当を置くなど、最適なメンバーに権限を委譲することも意識しなければならない。
2.2.3 プロダクトとプロジェクトの違い
プロダクトとプロジェクトは混同されやすい。どちらもPから始まり、プロダクトマネージャー、プロジェクトマネージャーともに日本ではPMとよばれることから対比して語られることも多いが、そもそも概念が異なるため比較するものではない。
プロジェクトはある目的のもと、開始時期と終了時期が定義された活動のことを指す。プロジェクトの管理対象は品質（Quality）、費用（Cost）、納期（Delivery）の頭文字を取ってQCDとよばれる。プロジェクトの管理を中心としたプロセスがいくつか体系化されており、それに則って活動を管理することをプロジェクトマネジメントとよぶ。
一方、プロダクトにはプロジェクトでは必須となる終了時期があらかじめ定められていない。価値を提案し続ける、終わりがないプロダクトが理想であり、企画段階でプロダクトの終了時期を考えることはない。
プロダクトはプロジェクトを内包する概念である。たとえば、プロダクトに新しい機能を追加するとき、その新機能の企画から提供までのプロセスはプロジェクトである。図表2-5に示すように、プロダクトの成功に向けて複数のプロジェクトを実施していくことになる。
図表2-5 プロダクトとプロジェクトの関係
プロダクトの成功のためにはプロジェクトが成功していることが望ましい。プロジェクトマネジメントはプロダクトマネジメントの一部であるともいえる。日本ではプロダクトマネージャーが新しい概念であり、プロジェクトマネージャーのあとにできたといわれることがある。しかしプロダクトマネージャーはIT業界に限らず古くから存在しており、IT業界でもいまから40年以上前から存在する。
プロダクトマネージャーが注目されるようになったのは、ソフトウェアによって事業を大成功させた企業が多く出現するようになった1990年代からであろう。MicrosoftやGoogle、Facebookなど米国のIT企業の成功秘訣を探る中、それらの企業にプロダクトマネージャーがいたことが大きなきっかけである。また、日本ではプロジェクトマネージャーのことをPMとよび、プロダクトマネージャーもPMあるいはPdMとよぶ人もいる。一方、欧米ではプロダクトマネージャーをPM、プロジェクトマネージャーをPJMとよんでいる。
こうした背景を踏まえて筆者は、プロダクトマネージャーをPM、プロジェクトマネージャーをPJMとする呼称を採択している。
2.3 プロダクトをつくるチーム
2.3.1 プロダクト志向のチームとは
プロダクトはその企画や企画の意図通りに動作する機能、ユーザーの操作性を考えたデザインなどから構成される。それぞれの担当者が自分の担当領域に責任をもって遂行するのはもちろん必要だが、それ以外の領域には一切興味がない状態ではよいプロダクトは生まれない。
チームメンバー全員がプロダクトをまるで自分の子どものように愛し、自分の担当領域だけではなく、プロダクト全体のことを考えることを「プロダクト志向」とよぶ。たとえばエンジニアならば、ソフトウェアとしての設計や実装だけでなく、自分の書いたプログラムがどのようにユーザーに使われ、事業に価値を与えるかを考える姿勢のことを指す。
プロダクトを成功させるチームは、プロダクト志向のチームである。メンバー全員がプロダクトを自分ごととして捉え、プロダクトをよくしていくことにこだわり抜く。プロダクトに愛着をもち、「これは私のプロダクトだ」といってあちこちでプロダクトを宣伝して回る。電車の中で見ず知らずの人が自分たちの手がけるプロダクトを使っていると喜び、知人が競合のプロダクトを使っていると悲しむ。日々の生活の中で、自社のプロダクトを使ってもらうためにはどうすればよいか考え、その考えをチーム内で議論してプロダクトに反映することができる。
こうしたプロダクト志向の組織では、部署の目標とプロダクトの成功がつながっている。部署ごとの目指す方針に差異がなく、プロダクトの成功に非協力的な部署もない。営業はプロダクトがターゲットとするユーザーかどうかを判断し、ユーザーからの要望であったとしてもプロダクトの成功につながらないものにはNOといえる。開発はプロダクトの価値を高めるための方法を模索し、カスタマーサクセスはどうすればユーザーがヘルプ機能に頼らずにプロダクトを使いこなせるのかを考える。部署を越えてチーム全員がプロダクトの成功に能動的に関わるが、意思決定をする人は決まっており、その決定は尊重される。
また、プロダクトをよくするためのチャレンジを厭わない。チャレンジしたことが称賛され、失敗することも当然だと考えられている。プロダクトをよくするための試みが仮説と検証であることを理解していて、素早く仮説を検証し、小さく失敗を繰り返しながら失敗を次に活かしていく。そのためにチーム全員が協力し、ユーザーに受け入れられることがなかった仮説も次の学びを得るための必要な仕事であったと受け入れられる。
2.3.2 機能型組織とプロダクトチーム
一般的にプロダクトマネージャーは各機能型組織から必要なメンバーを獲得して組織に横串を通すようなプロダクトチームを構成する（図表2-6）。プロダクトチームのメンバーに対して人事権をもつのは機能型組織の上司であり、プロダクトマネージャーは人事権をもたない。
図表2-6 機能型組織とプロダクトチーム
そのために、プロダクトマネージャーは各機能型組織のマネージャーと議論をして、チームメンバーを割りあててもらい、そのメンバーとともにプロダクトをつくっていく。
ただし、組織がプロジェクト型組織とよばれるような、機能型の組織体制ではない場合にはプロダクトマネージャーが人事権を有してピープルマネジメントを担うこともある。その際は、本書で述べるプロダクトマネージャーとしての役割とピープルマネージャーとしての役割を兼任している状態となる。なお、本書ではピープルマネージャーの役割については取り扱わない。
2.3.3 代表的なプロダクトチームのメンバー
（1）プロダクトチームのメンバー例
プロダクトをつくるために必要なメンバーの全体像や各メンバーが担うべき役割については明確な正解がなく、組織によって異なるのが現実である。ここでは、プロダクトチームの1つの例となるメンバー構成を紹介する（図表2-7）。実際の組織でどのように役割を分担するのかについては、プロダクトの特性やチームメンバーの適性に応じて検討してほしい。たとえば、アジャイル開発のスクラムを採択する場合には、プロダクトオーナーやスクラムマスターといったメンバーも必要になる。
たとえば、1人の担当者が図表2-7に記載されている複数の役割を兼務することや、反対に1つの役割を複数人で担うこともあるだろう。もし1人で複数の役割を担うときには、チームに対してどの役割としての意見をいっているのかを明確にすることや、特定の視点が失われてしまわないように役割を切り替えて考えることを意識してほしい。
図表2-7 プロダクトチームのメンバー例
（2）ステークホルダーの例
プロダクトマネージャーがプロダクトに関して意思決定できる十分な権限をもつことが望ましいが、プロダクトマネージャーだけでは意思決定できない事項も多い。その際には、プロダクトマネージャーの報告経路および決裁経路をたどり、最終的には経営陣やそれに相当する意思決定者の判断も仰がなければならない。また、ステークホルダーとよばれる図表2-8のような役割をもつ人とのコミュニケーションが必要になる。
図表2-8 プロダクトをとりまくステークホルダーの例
