プロダクトマネージャーについて

Twitter でプロダクトマネージャーについてぶつぶつ呟いていたら、まとめられていました。ありがとうございます。

プロダクトマネージャーについてあれこれ考えていることを、ここらで一旦整理する良い機会かなとも思いましたので、ちょっと文章をこさえてみることにしました。一年ぶりにブログでも書いてみようと思います。

プロダクトマネージャーはユニコーンなのか。なぜそれが必要なのか。プロダクトマネージャーを見つける / 組織で制度化するとはどういうことなのか。それについて自分の考えを述べていこうと思います。

プロダクトマネージャーは新しいユニコーンか?

昨今よくプロダクトマネージャーが話題になっていますが、人によっては「プロダクトマネージャー」 が今自分たちができないことを象徴している/それが登場すれば全てが解決する銀の弾丸的なもの・・・いわゆるユニコーンのように映っているのではないかと思います。それは良くないですね。

願わくば昨今の議論が「だからプロダクトマネージャーがない自分のとこは駄目なんだ」という結論の補強のためにではなく、「どうしたらプロダクトマネジメントの機能を組織に作る事ができるか」とか「プロダクトマネジメントのスコープを明確にすることでよりよい製品開発ができるのかどうか」という前進のための糧になれば良いなと思っています。

その前提で、プロダクトマネージャーなるものが幻なのかどうかについて。

インターネット分野のソフトウェア産業、特に自社開発の Web サービス / SaaS などの製品開発分野において、国内では、プロダクトマネージャーという職種はまだあまり形式化されていません。一方、海の向こうでは状況が異なり、プロダクトマネージャーという職業がソフトウェアエンジニアやデザイナーと同列で存在しています。つまり幻ではありません。

それは以下のような書籍が発行されていることからもその様子が伺えます。

一番目の「世界で闘う〜」は、前半がプロダクトマネージャーとはどういう職業なのかについて体系的に述べつつ AppleGoogleFacebookAmazonMicrosoft などの実例からそれぞれの企業ごとの差を浮き彫りにするという内容です。後半は、面接対策です。つまり、プロダクトマネージャーというポジションが明確に存在していて、それになるにはどうしたらいいのかが述べられています。

二つ目と三つ目は、実際にプロダクトマネージャーとしてのキャリアを積んできた著者が、具体的にその仕事内容とそれをうまくやるノウハウを記した書籍です。Inspired の方は元 eBay のプロダクトマネージャーです。Making It Right の方は未読なのでわかりません。

プロダクトマネージャーはどういう責務を果たすのかについてはそれぞれの本を読むほうが良いと思いますが、「世界で闘う〜」には「プロジェクトが完了して成功を収めるまで、全体を見ていく責任があります」と記されています。また「プロジェクトマネージャー」でも「プログラムマネージャー」でもないと、はっきりと書かれています。

プロダクトマネージャーは、ユーザーの理解とロードマップの企画や提案、製品の企画、ユーザー体験のデザイン、リリースされる製品の品質確保までトータルにマネジメントする役割です。要するに「その製品はあいつが作った」「こいつが考えた」というその人に相当します。(プロジェクトマネージャーやプログラムマネージャーは、プロダクトマネージャーに比較すると、限定というか専門特化された役割の職種という位置づけになります。)

プロダクトマネージャーはいわゆる世間で言うところの「企画職」のようにも見えますが、彼らの役割は企画を立ててあとは開発に任せて終わり・・・ではなく、その後の開発プロセスが回ってる間の開発の支援や開発中の意志決定、製品の品質確保、リリース、その後の改善の企画までをトータルに見ていくので実態としては少し異なるでしょう。

実際、プロダクトマネージャーはエンジニアに寄り添って彼らと一体になって製品を作っていく側面が強いので、「世界で闘う〜」の書籍に登場する企業のほとんどが、プロダクトマネージャーにプログラマーとしてのバックグラウンドを求めています。Google ではコンピューターサイエンスを専攻してきたかどうか、Facebook に至ってはプロダクトマネージャーの採用面接でコーディング試験があるとかなんとか。

もとい、プロダクトマネージャーとはこういう職種で、特に海外ではその職種要件やモデルについてはだいぶ明確化されています。

国内でのこの分野ではあまりそこまで明確になっていない、最近になって議論されはじめたのでは・・・というのが私の実感です。(「この分野」と枕詞を置いたのは、id:antipop さんによると、我々が議論しているプロダクトマネージャーに相当する職業は特に自動車産業の分野における主査制度の中に見て取れるなどの事情からです。参考1, 参考2)

一方、私の古巣の話になってしまうのですが、株式会社はてなでは私が在籍していた当時は「ディレクター」という肩書きで、各サービスのサービス開発責任者は明確に定められており、開発において企画やロードマップ策定も含めたリーダーシップを発揮することを求められていました。これはプロダクトマネージャーに相当する役割であると思います。自分もいくつかのサービスのディレクターを担当したことがありました。

また、グリーではゲーム開発の責任者には "PM" という肩書きがついており、主にエンジニア組織のメンバーがその役割に就くことが慣習になっていました。(PM は記憶が定かであれば "Product" の P だったと思います) グリーの PM は製品の企画責任だけでなく事業責任も負っていました。

それから、これは伝聞ですが、任天堂ではゲーム開発の現場でエンジニアやデザイナーの経験を積んだ人が、その後ディレクターとなってゲーム開発の責任者に就き、ゲームの企画やデザインをその人が考える・・・というキャリアパスがあるということでした。

昨今技術顧問を務めている Kaizen Platform, Inc. には明確にプロダクトマネージャーのポジションがあります。

というわけで、国内ではまだ体系化されていないことはあっても、プロダクトマネージャーに相当する職業がないわけではない・・・ということもわかります。

やはりアメリカという国は役割の明確化と組織のシステム化が非常に得意な国ですから、プロダクトマネージャーも例に漏れずその姿が明確になっている感じですね。日本は、曖昧模糊とした中から徐々に役割が定まっていくみたいなところがありますから、こちらも例に漏れずといった状況でしょうか。

プロダクトマネージャーがなぜ必要か?

ここからが本題です。前振り長くてすみません。

昨今自分が「プロダクトマネージャーが〜」とたびたび発言しているのには、当然ですがそれが必要だと思っているからそう発言しているわけですが、ではなぜプロダクトマネージャーが必要なのでしょうか?

細かく理由をいろいろと並べることもできるのですが、これに関してはシンプルに考えれば良いです。それはより良い製品やサービスを作るためには「健全な意志決定の偏らせ」、つまりある種の独裁制が必要だと思っているからです。

このブログを読んでくださっている方々にはソフトウェアエンジニアの方が多いでしょう。エンジニアの方々なら、言わんとしていることは実感としてわかっていただけるのではないかと思います。

例えば大きなシステムを作るとき、その根幹のアーキテクチャや設計を、その場にいる十数人で合議制で決めるべきか。答えは NO で、アーキテクトとして「できるやつ」に任せるべきでしょう。大きな建造物を建てる時に最初の基礎工事が重要になるように、大きなシステムを作る場合は根幹を支える基本アーキテクチャがその下地として重要になります。ソフトウェア設計においてこのときアーキテクチャに求められるのは一貫性です。システム全体に跨がるアーキテクチャに一貫性をもった設計を行うには、経験的に、大人数で合議制で決めるのではなく少ない人数で取り組むべきだということは多くの人が賛同する事柄ではないでしょうか。

また、オープンソースソフトウェアにおいても優しい終身の独裁者 という言葉で語られるように、優れたプロジェクトには決まって特定のリーダーがいて、ソフトウェアのデザインやプロジェクトの意志決定において独裁的な役割を果たしているとも言われます。

・・・要するに、よい物を作りたかったらそのデザインはできるやつに任せるべき・・・という単純な理由なんです。合議制では良いものは作れない。

従って開発組織においても、製品開発の責任者を曖昧にするのではなく、できるやつにデザインや意志決定を任せたほうがいい、つまり「健全な意志決定の偏り」があったほうがいい・・・それを制度として実現するなら「プロダクトマネージャー」という役割を明確化することだろうというのが自分なりの結論です。

プロダクトマネージャーはもともといた

そんな理由から、組織内で誰に製品ロードマップや企画やデザインを託すのかという話になっていくのですが、よくよく考えると企業の創業期にはだいたい創業メンバー・・・典型的には創業者がその役割を果たしていることが少なくないということに気がつきます。

ソフトウェア開発のスタートアップにおいては、プロダクトのアイデアが全くないという状態でスタートアップが始まることは希 (そういうスタートアップもあるはあるけどだいたいポシャる) で、そのアイデアは創業者が持っていることが多いでしょう。また、昨今は創業メンバーにエンジニアやデザイナーを含めて回せ・・・というのがセオリーになっていることからもわかるとおり、創業期にはそのアイデアをもった創業者とそれを実現するエンジニアやデザイナーが小さな机の上でああでもないこうでもないと言いながら最初の製品を作り込んでいくわけです。そしてその作った製品で事業を興せるものなのかどうか、実際にユーザーに使わせてみて、その結果を見ながら会社や製品の方向性を定めていく・・・そんなプロセスを否が応でも経ることになります。

この創業者というのは、改めてみるとプロダクトマネージャーそのものですよね。(そしてこのプロダクトマネージャーである創業者自身がエンジニアで、一緒に開発しているなんてことも珍しくないです。)

つまりスタートアップが会社として成長するためには、まともなプロダクトが必要不可欠であり、まともなプロダクトができあがってくる背景には暗黙のうちに組織にプロダクトマネージャーに相当する人間がいて、創業者がだいたいそれだったりする、ということです。

しかし組織がその後成長してくると、創業メンバーというのは往々にしてその役割が変化し、製品開発から組織運営や会社経営の方にフォーカスせざるを得ないという状況に遭遇します。その組織の拡大期に、製品開発組織の構造化に自覚的でなかった組織は、「誰にプロダクトを任せるか」という視点を欠いて、プロダクトマネージャーに相当する機能を失ってしまうか、その役割を薄めてしまう・・・ということが起こります。

自分が主張したいのは、組織の中でその「健全な意志決定の偏り」を取り戻すために、プロダクトマネジメントの機能を組織内に作ってそれを実現すればいいじゃないということなのです。

プロダクトマネージャーを見つける?

重要なことは「プロダクトマネージャという職種を作る」ということ、それ自体ではありません。「健全な意志決定の偏り」を実現することです。従って、たとえプロダクトマネージャーなるポジションがない会社でもそれが実態として実現されているならそれで構わないでしょう。

先に述べたとおり、小さな企業では「そうしなければ回らない」という必然的な背景からプロダクトマネージャーに相当する人間がそこにはいるものです。一方で、大きな会社ではそれが失われていることも多い。失われているなら、作りましょう、そういう話ですね。

プロダクトマネージャーを育てるとか見つけるのは大変という議論があります。自分もそう思います。プロダクトマネージャーはサービスや製品の責任者であり、その人の意志決定如何によって製品が劇的に良くなることもある一方で、劇的に悪くなることもまたあるという両刃の剣です。それが「できる」という人間を外から探してくるのは、まあ骨の折れる仕事というか、それに成功さえすればある意味その会社は勝ったみたいなところがあります。それぐらいいないというか、大変なんですよね。

一方で、実現したいのは、やはり偏らせだということは忘れたくないですね。今いる組織の中にも「この人に任せればうまくいく」という人間はそれ相応にいたりするものではないでしょうか。その人に偏らせればよいというのも一考に値しそうです。同じ開発プロジェクトでも、あの人がいるなら安心してみてられるというのであれば、その「あの人」はプロダクトマネージャーになれる可能性は高いです。プロダクトマネージャーにはエンジニアリングやデザインのバックグラウンドが求められることが多いので、相関的に開発組織の中から見つかることも多いですが、案外セールスの中にプロダクトに熱い情熱と深い顧客理解を持ったメンバーがいるなんてことも珍しくはなく、実際自分はセールス出身のメンバーがその後プロダクトマネージャーになって華開く、なんて場面を目の前でみたこともあります。

その上で、じゃあプロダクトマネージャーって、どういうことをその責務とするの・・・という議論が先に紹介した書籍などに詳細に記されているということもお忘れなく。どういうことが上手な人が、プロダクトマネージャーに向いているのか。そのヒントがそこにあるでしょう。単に意志決定を偏らせれば良いわけではないですからね。あくまで、できるやつに偏らせるということが大切です。(たびたび記しているように、相応にエンジニアリングのバックグラウンドが求められるなどはそれなりに意外なポイントだったりすると思います。)

プロダクトマネジメントの機能を組織の中でどう作っていくか、という議論はまだまだ始まったばかりという気もしますが、一方で実現したいことはもっとシンプルに「いい物を作るために誰に任せたらいいか」ということだと思います。そう考えれば、そんなに夢物語のようなことでもないような気がしてきませんか?

追記

Product Manager の役割についてよく書かれている記事を教えてもらいました。参考にどうぞ。