プロダクトマネージャーという仕事

Aki Hirohara

2023年4月28日 17:33

マネーフォワードビジネスカンパニーでMid Market 領域のCPO（Chief Product Officer）を担当しているヒロハラです。

最近、さまざまな場で、プロダクトマネージャーの重要性が語られることが増えてきました。

また、プロダクトマネージャーに適性がある人ってどんな人だろう？という話も良く聞かれます。

そんな訳で、今回はプロダクトマネージャーという仕事について書いてみたいと思います。

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

プロダクトマネージャーとは、シンプルに言えば「プロダクトの責任者」で、ときには「ミニCEO」と呼ばれることもある、などと良く言われています。

一方で、少し掘り下げていこうとすると、プロダクトマネージャーという仕事は定義が非常に曖昧で、プロダクトや事業の置かれている状況によっても役割が異なり、一人として同じ仕事をしている人がいない、などと言われることが多いです。

プロダクトの成功のためになんでもする人

個人的には、そんな曖昧で定義が難しいプロダクトマネージャーという仕事が好きなのですが、いまは時代的にも各職種にわかりやすい定義が求められることが多いので、マネーフォワードビジネスカンパニー（以下MFBC）では、CPO室が発足した2021年に、プロダクトマネージャーを、

「プロダクトの成功のためになんでもする人」

と定義しました。

ここからは、「プロダクトの成功」をさらに明確にするために、「プロダクト」と「成功」についてもう少しブレイクダウンしてみます。

プロダクトとは

SaaS企業のようなソフトウェア業界で、「プロダクト」と聞いてわかりやすくイメージするものとしては、ソフトウェアそのもの、だと思います。

狭義には、その理解でも正しいのですが、ユーザーに価値を届けるにあたって必要となるのはソフトウェアそのものだけではなく、その周辺にあるBPOサービスやオンボーディングツール、カスタマーサポートなど、各種サービスも含まれます。

そのため、MFBCにおける「プロダクト」とは、

「ソフトウェアのみならず周辺サービスまでを含むものすべて」

と定義しています。

ソフトウェアだけでなく周辺サービスまで含みますので、プロダクトはエンジニアだけいれば作れるものではなく、ビジネス系の部門も含めてみんなで一緒に協力して作っていくもの、ということになります。

よくビジネスサイド、プロダクトサイドという言葉が使われることがありますが、個人的には、自社でプロダクトを開発し提供している会社では、どの部門もプロダクトサイドになるのが正しいと思っています。

プロダクトの成功とは

次に、プロダクトの「成功」についてです。

「成功」についてよく議論になるのが、売れているプロダクトが成功なのか、良いプロダクトが成功なのか、というものです。

過去から、いろいろなプロダクト関係者と話をする中で、
「うちのプロダクトが一番良くできているプロダクトだと自負しています！一番売れているのは競合他社のプロダクトになりますが、あのプロダクトは全然良くないんです！」
という話を聞くことが意外と多いのですが、これを聞くたびに個人的にはいつも、なんかカッコ悪いなーと思っていました。

多くのユーザーに使われていないという事実こそがユーザーからの一番の評価なのですから、作り手が一番良いと思っているにも関わらず多くのユーザーに使われないのであれば、なぜ使われないのかもっと真摯に考えるべきだと思います。

一方で、毎年シェアNo.1を取り続けているにも関わらずユーザーからの評判が全く良くないというプロダクトについても、全くカッコいいとは思えません。

そんな背景から、MFBCにおける「プロダクトの成功」とは、

「ユーザーに価値を届けると同時に、ビジネスの成功にも貢献する」

と定義しました。

MFBCにおけるプロダクトマネージャーとは

つまり、MFBCにおけるプロダクトマネージャーとは、

「自身が担当するプロダクト（ソフトウェアのみならず周辺サービスまでを含む）で、ユーザーに価値を届けるとともにビジネスの成功にも貢献するために、なんでもする人」

となります。

プロダクトマネジメントトライアングル

そんなプロダクトマネージャーに必要なスキルセットを語る上で、必ず登場するのがこちらの「プロダクトマネジメントトライアングル」です。

引用： The Product Management Triangle（Product Logic）

シンプルにいうと、「エンジニア」「ビジネス」「ユーザー」の３つの領域のスキルをすべて求められるということになります。

この時点ですでに、そんな人世の中にいるのかな？と思わされるレベルかもしれません（笑）

引用： The Product Management Triangle（Product Logic）

そして、良く見るのは、各領域の間まで詳細に埋められた、こちらの図になります。

このプロダクトマネジメントトライアングルについては、詳細に語られている記事等がさまざま存在しますので、今回のnoteでは、MFBCでこだわっているポイントのみ書いていこうと思います。

すべての領域を自分でできる

まず重要なのは、プロダクトマネージャー自身が、「エンジニア」「ビジネス」「ユーザー」の３領域それぞれの仕事をできる能力を持っているということです。

理想的には、エンジニアとしても、ビジネス（セールスやマーケなど）としても、ユーザー（MFBCの場合、経理や人事など）としても、他社からスカウトが来るくらいのレベルで仕事ができるのが望ましいのですが、さすがにそれは難しいので、少なくとも、マネーフォワード社内のエンジニア部門、ビジネス部門、バックオフィス部門、どの部門に異動したとしても、一人前のメンバーとして活躍できるレベルを求めています。

プロダクトの成功のために「なんでもする」のが仕事ですから、当然、最低限すべての部門で実際に仕事ができるレベルのスキルを持っている必要があります。

私自身は、ファーストキャリアが「ユーザー」、セカンドキャリアが「エンジニア」、そのあとプロダクト責任者（当時はプロダクトマネージャーという言葉はなかった）となり、「ビジネス」と「エンジニア」を５：５くらいで担当していたという経歴で、偶然にも３つの領域それぞれを仕事として経験することができたのですが、最近は、日本でもジョブ型雇用などが進み、現実的にこの異なる３領域の仕事をすべて経験するというのは難しくなっています。

MFBCでは、プロダクトマネージャー候補として採用した若手社員に、まずはエンジニアを経験してもらい、その後ビジネスやユーザーへとローテーションした上でプロダクトマネージャーを目指してもらうといった、特別なキャリアステップを模索中です。

各部門と協力しプロダクト作りを進められる

実際の現場では、プロダクトマネージャーが３つの領域すべてを自分でやる訳ではなく、むしろ、それぞれの領域のメンバーと一緒にプロダクトを作っていくことになります。

プロダクトチームとして機能するためにも、プロダクトマネージャーがそれぞれの領域のメンバーから信頼されるだけの知見とスキルを持ち、チームとしてプロダクトの成功に向かうことが求められます。

また、プロダクトの成功のために、それぞれの領域で必要となる専門性を持ったメンバーを社内外から絶えず探し、できる限りベストなメンバーを集め、よりプロダクトの成功に近づくことができるプロダクトチームを作っていくことも重要になります。

もちろん、各領域で人が足りなかったり、うまくいかないことがあったりした時には、プロダクトマネージャー自らがその領域の仕事を拾い、自ら実行することでプロダクト作りを前に進めることが必要です。

プロダクトの成功のためになんでもする人なのですから、常にそのような気概とどの領域の仕事もやり遂げられる能力が必要になります。

３つの領域の間に落ちる仕事を拾い、間に挟まれる課題を調整する

プロダクト作りを進めていくと、この３つの領域の間（例えば、エンジニアとビジネスの間、ビジネスとユーザーの間、など）でさまざまな課題が発生します。また各領域の間では、それぞれの部門の価値観の違いなどから、コミュニケーショントラブルや、もっとストレートに言えば揉め事のようなことも良く起こります。

この、間に落ちる課題を拾い、間で発生するコミュニケーショントラブルを整理し、問題をひとつずつ解決することでプロダクトを成功に導くのも、プロダクトマネージャーの重要な役割になります。

３つの領域の外側もプロダクトマネージャーの仕事

「エンジニア」「ビジネス」「ユーザー」という３つの領域だけでも、ほぼ不可能なレベルの領域の広さなのですが、プロダクトの成功に向けては、この３領域のどこにも属さない、つまり３つの領域の外側で重要な課題が発生することも山ほどあります。

プロダクトマネージャーの仕事を、「プロダクトの成功のためになんでもする人」と定義していますので、この３つの領域の外側で起こる課題も、すべてプロダクトマネージャーが解決すべき仕事、ということになります。

MFBCのプロダクトマネージャーに必要なスキル

MFBCでは、中小、中堅、成長企業向けのバックオフィス向けSaaSプロダクトを提供しており、特に直近は、中堅成長企業のための、『マネーフォワードクラウドERP』の各プロダクトの成功のために全力で取り組んでいます。

ここからは、そんなMFBCのプロダクトマネージャーに特に必要なスキルについて書いてみようと思います。

知識ではなく理解

経理や人事など、いわゆる業務システムを作っている仕事をする上で、よく言われるのが、「ドメイン知識」の重要性ですが、個人的にこの「ドメイン知識」という言葉はNGワードです。

「ドメイン知識」とは、法制度に関する知識、業務に関する知識、顧客やマーケットに関する知識、などを総合したものになるのですが、ここで、この「知識」という言葉が非常に問題になります。

法制度や業務、顧客やマーケットについて、知っているか知らないかという「知識」が重要なのではなく、分かっているか分かっていないかという「理解」が重要なのです。

ひとつひとつ、なぜそのような業務なのか、なぜそのような法制度なのか、なぜそのようなマーケットになっているのか、背景や理由を説明できるレベルで「理解」していくことが、プロダクトを作る上でとても重要です。

特に、ERPのような専門的で複雑なプロダクトを作る上では「誰よりも広く誰よりも深いドメイン理解」は必須の要件です。

重要なのは、ただ知識として覚えることではなく、自ら必死に考えて仮説をたて、それを検証することを繰り返しながら、時間がかかっても一つずつ理解していくことです。

ヒアリングではなくデモ

知識と理解の話にもつながりますが、プロダクトマネージャーが、プロダクト作りの初期に、いきなりヒアリングを始めることがあります。個人的に、これも完全にNGです。

プロダクトマネージャーは、プロダクトが解決すべき課題や、マーケット、顧客について、誰よりも「理解」している必要があります。

その理解している内容を社内外で語り、その語られた内容に対する周囲のリアクションを注意深く観察することで何かを感じ、なぜそのようなリアクションになるのかを考えて、自身の理解をブラッシュアップしさらに深めていくことが重要です。

「経理業務で何かお困りのことはありますか？」というようなヒアリングは最も良くない例です。このような質問をされても、お客様は当たり障りの無い回答しかできません。そして、その当たり障りの無い回答をユーザーの真の課題と思い込んでプロダクトを作ってもうまくはいくはずがありません。

「経理業務で一番お客様がお困りなのは、月次決算がなかなか締められないことだと思っていまして、特に月末月初に現場からの情報がなかなか集まらないことが一番の課題ではないでしょうか？そこを解決する手助けができればと、我々のプロダクトでは、このようなことができるようになってまして・・・（デモが続く）」と、デモを続けていけば、お客様はその内容に反応し的確に具体的にフィードバックしてくれるはずです。「すごく我々の課題をわかってくれてますね」と言ってもらえることもあるでしょうし、「我々の課題はちょっと違いますね」と言われることもあるでしょう。「ちょっと我々の課題とはズレてるので、全体の業務フローや課題など説明させて頂きますね」などと言ってもらえればラッキーです。お客様が真剣に自分たちの課題について説明してくださる状況になったら、そこでは徹底的にお客様の話に耳を傾けましょう。このような状況を作るには、まずこちらの仮説を真剣にぶつけることが大事なのです。

そのようにして得られたお客様のフィードバックをもとに、自分たちの仮説をブラッシュアップし、またその内容をデモし、と繰り返すことで、自分たちの理解を深めていく、これがプロダクトを成功させるために最も重要となるプロセスです。
（なお、ここであげたデモスクリプトは例ですので、この内容へのツッコミはご遠慮ください。笑）

地道に何度も仮説検証を繰り返すことが、誰よりもドメイン理解を深めていくことにつながっていきます。

MFBCでは、「PdM Bootcamp」というタイトルで、プロダクトマネージャーがデモをしまくることで自身のドメイン理解を深めていくという独自のPdM育成プログラムを実施しています。

積み上げではなく逆算

SaaSが一般的になる中で、まずは小さく作ってリリースし、その上でスピード感をもってバージョンアップを繰り返していくことの重要性が語られるようになりました。

これは、変化の激しい現代のビジネスの進め方という点で非常に有効です。

ただ一方で、最初に最終的なゴールを描かないまま進んでいるなら、これは非常に問題です。

プロダクトマネージャーは、常に、プロダクトが完成したときの世界観、つまり最終的なプロダクトのゴールを描く必要があります。この世界観を、ユーザーも含むすべての関係者に伝え、共感を得て、チーム全体をプロダクトの成功に向かわせることが求められます。

プロダクトの成功こそが目指すべきことですから、プロダクトが成功した状態をわかりやすく描き示すことがとても重要です。

ERPは比較的昔からある普遍的なプロダクトなので、いつの時代も誰が描いてもプロダクトのゴールは同じようなものになると思われがちです。

しかし、『マネーフォワードクラウドERP』は、例えばSaaSの中にファイナンス機能を組み込む「Embedded Finance（＝組み込み型金融）」など、SaaS x Fintechの力で、これまで想像もできなかったような世界を実現しようとしています。

このような世界観を描くにあたっては、広く深いドメイン理解は当然必要となりながらも、旧来型のドメイン理解に引っ張られずに、新しいテクノロジーやトレンドを積極的にキャッチアップした上での柔軟な発想力と想像力、理想のゴールを描く力も求められることになります。

MFBC CPO室では、今期、「PdM Workshop」というタイトルで、プロダクトのゴールを描く、独自の実践型ワークショッププログラムに力を入れて取り組んでいます。こちらの内容は、また別のnoteで詳しく書いていけたらと思っています。

プロダクトマネージャーに必要なマインド

ここまで、プロダクトマネージャーに必要なスキルについて書いてきました。すでに、圧倒的な広さと深さが必要ということがわかり、こんなの一体誰ができるの！？と思われているかもしれません。

ただ、個人的には、ここまで書いたスキルをすべて持ち合わせても、プロダクトマネージャーに必要な要素の10%程度ではないかと思っています。

残りの90%を占めるものは何かというと、スキルではなくマインドです。

ここからは、プロダクトマネージャーに必要なマインドについて書いていこうと思います。

圧倒的当事者意識

冒頭で、プロダクトマネージャーの定義は、「プロダクトの成功のためになんでもする人」と書きました。

この「なんでもする」が、思っているほど簡単ではありません。ほとんどの人は、こんなことまで自分の仕事なんだろうか？、少なくともこれはあの部署の仕事じゃないのか？といったことを言い、課題に向き合うことをやめてしまうのです。

プロダクトの成功の最終責任者なのであれば、最後はすべて自分でなんとかしなければいけません。（念のためですが、自分だけでなんとかするという意味ではなく、自分が中心となってみんなと協力してなんとかするという意味です）

プロダクトに関わるあらゆる課題を自分ごとと捉えて解決に導き、プロダクトを成功に近づける

プロダクトマネージャーは、そんな「圧倒的当事者意識」を持っている必要があります。

プロダクトマネージャーに必要な３つの領域のスキルを高いレベルで持っていたとしても、いざそれぞれの領域で課題が起こったときに、その課題を自分ごとと捉えて解決しようとしないのであれば、高いスキルを持っていても意味がありません。

私が好きな考え方に

「プロダクトの成功は、そのプロダクトに関わったすべてのメンバーのおかげ。一方、プロダクトの失敗は、すべてプロダクトマネージャーの責任」

というのがあります。

これを、きれいごとではなく、心から本音で思えているかが、圧倒的当事者意識を持っている、ということではないかと思います。

永遠に作り続ける

ERPのような複雑なプロダクトは特に、プロダクトを作り育て完成させるのに10年単位の膨大な時間がかかります。

ここで重要になるのが、プロダクトマネージャーが、最低でも10年、できるなら半永久的にプロダクトの成功を目指してプロダクトを作り続けることです。

たまに、プロダクトの1stリリースを迎えた直後くらいに、「あと1年くらいでこのプロダクトは作り終わるので、次のキャリアを考えています」などと言うプロダクトマネージャーがいたりしますが、これは成功しないプロダクトの典型例です。

そもそも、SaaSの1stリリースはゴールではなくスタートです。

1stリリースを迎え、ようやくスタートラインに立ち、そこから5年10年とプロダクトを永続的に成長させていく。グローバルでSaaSの巨人と言われるような企業には、リリースから20年以上たつようなプロダクトも多くありますが、成功しているプロダクトは例外無く1stリリース時よりも今のほうが大きな開発投資をしています。

つまり、1stリリースの頃よりも、20年たった今のほうがはるかに多くの機能強化をしている、つまりまだまだやるべきことがたくさんあるということです。

トレンドに左右されやすいto Cのプロダクトとは違い、バックオフィス向けの業務プロダクトは30年とか50年という単位で、ユーザーに使われ続ける可能性があるものになります。

このような領域のプロダクトマネージャーは、常に未来のプロダクトを探求し続け、継続的にプロダクトを進化させ、半永久的に自身の担当するプロダクトの成功にコミットする覚悟があるかという点も、重要なポイントと思います。

誰からもリスペクトされる存在になる

プロダクトマネージャーがどれだけ有能で、どれだけ圧倒的当事者意識を持っていたとしても、現実的に、ひとりでプロダクトを作るということはありません。多くの場合、社内のエンジニアリング部門やビジネス部門、そしてその他関連部門、社外ではパートナー企業やもちろんユーザー企業に至るまで、多くの人と一緒にプロダクトの成功を目指すことになります。

そんな中、さまざまな場面で意思決定を行っていくプロダクトマネージャーは、関係するすべての人から常にリスペクトされる存在である必要があります。

少なくとも、プロダクトマネージャーは、全ての関係者から、「この人にまかせておけば大丈夫、この人で失敗するなら仕方ない」と思ってもらえる人であるべきです。

ここで、なかなかリスペクトを得られないプロダクトマネージャーの多くは、「自分はエンジニア経験が無いからエンジニアから信頼されない」とか、「自分はまだ若いから年長者に認められない」とか、「自分のことを理解してくれない周りが悪い」とか、誰かのせい何かのせいにしたりしますが、周囲からリスペクトを得られないのは、結局自分のどこかに課題があるということです。

リスペクトを得るために必要な要素はさまざまありますが、結局は、絶えず誰よりもひたむきにプロダクトの成功のために働き、誰よりもプロダクトを通して世の中を良くしていきたいという情熱を持ち続けている、そんな人がプロダクトマネージャーとしてプロダクトを日々地道に作り続けていった先に、少しずつ周囲からの信頼が積み上がっていくのではないかと思います。

最強のプロダクトカンパニーになるために

ここまで、プロダクトマネージャーに必要なスキルとマインドについて書いてきました。

こんな、スキルもマインドも最強のプロダクトマネージャーがいたら、どこの会社でもどんな条件を出してでも採用したいと思うのではないでしょうか？（笑）

自分で書いていて心苦しいですが、もちろん私自身もすべてを満たしているなどとは到底言えず、まだまだ、日々、理想的なプロダクトマネージャーを目指して修行を続ける毎日です。

ただ、仮にこのような理想的なプロダクトマネージャーがいたとしても、そのプロダクトマネージャーだけではプロダクトの成功は難しいかもしれません。

最後に、次々とプロダクトが成功する、最強のプロダクトカンパニーになるために必要なことを書いていきたいと思います。

すべてはプロダクトの成功のために

冒頭で、プロダクトマネージャーは、「プロダクトの成功のためになんでもする人」と書きました。

そのプロダクトマネージャーは、必要な３領域すべてを実行できる能力を持ち、圧倒的当事者意識をもってすべてを自分ごととして捉え取り組み、関わるすべての人と協力してプロダクトを作っていきます。

ただ、プロダクトは、プロダクトマネージャーひとりでは作ることはできません。

どんなプロダクトであっても、例外無く、プロダクトマネージャーを中心としたチームで作り育てていくことになります。

そのプロダクトチームに集まるメンバー全員が、
「プロダクトの成功のために、自身の領域においてなんでもする人」
であるというプロダクトチームこそが、最強のプロダクトカンパニーなのではないかと思います。

例えばエンジニアであれば、「プロダクトの成功のために、エンジニアリングの領域においてなんでもする」という状態です。

プロダクトの失敗の原因の多くは、プロダクトマネージャーのスキルやマインドが足りないことに起因するのですが、仮にここまでで書いたような理想的なプロダクトマネージャーがいても成功できないケースがあるとしたら、それはプロダクトマネージャー以外のメンバーがプロダクトの成功とは違うものを目指してしまっているときではないかなと思います。

例えば、ビジネスチームは、プロダクトの成功よりもKPIの達成を目指している、エンジニアチームは、プロダクトの成功よりも技術力の追求を目指している、といった感じです。

プロダクト作りに関わるすべてのメンバーが、「プロダクトの成功のために、自身の領域でできることをなんでもする」という状態になったときに、次々とプロダクトが成功する、最強のプロダクトカンパニーになれるのではないかなと思います。

「すべてはプロダクトの成功のために」

プロダクト作りに関わるメンバーもまた、圧倒的当事者意識を持ち、他の部門のメンバーやプロダクトマネージャーと協力しながら、自分の専門領域においてはなんでもすることで、プロダクトの成功を目指す、そんなプロダクトチームが最強だなと思うのです。

さいごに

かなりの長文になりましたが、プロダクトマネージャーという仕事について、個人的な意見も交えて書いてみました。

冒頭に書いたとおり、プロダクトマネージャーという仕事の定義はとても曖昧で、それぞれの会社それぞれの状況で、理想とするプロダクトマネージャー像もさまざまだと思います。

もし今回のnoteに興味を持って頂いたプロダクトマネージャーの方がいらっしゃったら、ぜひ交流させて頂けたらうれしいです。

また、このnoteをきっかけに、マネーフォワードのプロダクトマネージャーに興味をもったという方がいらっしゃいましたら、ぜひぜひお気軽にご連絡頂けたらと思います。

これからも、マネーフォワードクラウドのすべてのプロダクトの成功を目指して、頑張っていきたいと思います。

Work illustrations by Storyset