「SPECTACLEs 2024」は2024年6月5日〜7日に開催された、unerry主催のビッグデータカンファレンスです。本記事は「エンジニアからプロダクトマネージャーを目指す人へのエール」のセッションを書き起こしでレポートします。（実際の発言から意図に変わりのない範囲で編集を加えています）

登場人物

※役職はイベント当時

登壇者自己紹介

（unerry）伊藤：
「エンジニアからプロダクトマネージャーを目指す人へのエール」、セッションを始めてまいります。本セッションでは、#プロダクト筋トレ というコミュニティを主催されている小城さんにプロダクトマネジメントの極意を聞いていきます。

本日のモデレータを担当するunerry伊藤と申します。まずは私の自己紹介をさせていただきます。

1999年にニートから一念発起してITベンチャーに入社。その後いろいろありましたが、2018年にLINE社のスマートスピーカーClovaに出会い、LINE Beaconと連動したプロダクトの試作に取り組みました。Clovaは外国製のものに比べて日本語の性能が大変が良く、衝撃を受けました。その関連でLINE Boot Awordsのハッカソンに参加し、主催者のお一人だった小城さんと出会うことができました。一生忘れられない記憶として刻み込まれています。

それでは小城さん、自己紹介をお願いします。

（SB Intuitions）小城：
よろしくお願いいたします。小城と申します。ご紹介いただいたように、もともとはLINE株式会社でClovaの立ち上げの仕事をしていました。現在はソフトバンク株式会社からSB Intuitions（エスビーインテュイッションズ）株式会社に出向しています。

私は一人のプロダクトマネージャーとして、今まで大変たくさんの失敗をしてきました。その失敗をもとに「あの時どうすれば自分は失敗せずに済んだのかな」とか「もっとうまく進めるにはどうすればいいのかな」といったことを考えておりまして、プロダクト成功の再現性を高めたいと思っております。

その関係で、本を1冊共著で出させていただき（「プロダクトマネジメントのすべて」）、またプロダクトマネージャーやプロダクトづくりに関わる人たちがお互いに切磋琢磨しながら悩み相談や知見を交換できるSlackコミュニティの運営（#プロダクト筋トレ）を行っています。

現在はソフトバンクグループのSB Intuitionsという会社で、日本語の生成AI、LLM、マルチモーダルモデルの提供に向けて、チャレンジをしております。

当社ビジョンにも掲げていますが、DXがそうであるように、生成AIがあらゆる産業の競争力の源泉になるといいなと夢を見ております。

生成AIは、今はまだ、スライドの一番左（上図）に記載したように「作業の効率化・自動化」というシンプルなタスクでしか使われてないんじゃないかと思っています。たとえば文章の要約・翻訳などですね。

でも、それだけではもったいなくて、生成AIはAskAnything、何でも聞けるプロダクトであるからこそ、もっと人の意思決定を支えるパートナーになれるはず。より深いユースケースで生成AIを使うためにはどうすれば良いのか？といった問いに対して、PMF（プロダクトマーケットフィット）できるように頑張っています。

本日はどうぞよろしくお願いいたします。

プロダクトマネジメントとは？定義を考える

（unerry）伊藤：
ありがとうございます。ここからはトークテーマに入っていきましょう。

まずはプロダクトマネジメントの定義についてお伺いします。ここがわからないと迷ってしまう現場の方も多いと思いますので、ぜひ小城さんのお考えを教えてください。

（SB Intuitions）小城：
「プロダクトマネジメントは難しい」「難しいカタカナが輸入されてきた」「（新たに）学ばなければいけない」と皆さんよくお話されています。

しかし、私はプロダクトを成功に導くためにやるべきこと全てがプロダクトマネジメントだと捉えています。つまり、既に事業をされていて、プロダクトを作っているなら、日々皆さんがされていることこそが、プロダクトマネジメントだと思っています。

同時に、プロダクトを作っては成功したり失敗したりといった経験を通して、いろんな人たちの知見が溜まってきたことで、成功のための方法論が徐々に確立されつつあるんじゃないかとも思います。

先人たちがどんな取り組みを経てプロダクトを成功させたのか、もしくは失敗したのかのエッセンスを取り入れることが、プロダクトマネジメントを学ぶことかなと、私は思っていますね。

プロダクト成功のためには、3要素のバランスが鍵

（SB Intuitions）小城：
では、成功してるプロダクトとは？成功とは？というところから紐解いていきましょう。

プロダクトの成功のためにまず大事なのは、ユーザーさんが喜んでいること、ユーザーさんに価値提案ができること。

でも、ちょっと難しいのは、価値提案の「ありがとう」の対価としてのお金が返ってこないと、次のユーザー価値を提案できなくなってしまうので、ユーザー価値と事業収益の間で血が巡っているような状態が、すごく大事だと思います。

そしてもう一つ大事なのがビジョンの実現です。

ビジョンがないと、価値提案の方向がバラバラになり、プロダクトが発散してしまいます。「そのプロダクトって何なんだっけ？」「事業ってどこに向かってるんだっけ？」といった指針がなくなると、どこに何のリソースを投下すればいいのかがわからなくなってしまう。

そうならないために、私たちは会社として、事業として、どういう世界を作りたいのかをしっかり定義して、その実現に向けてユーザーに価値を提案する。その結果として事業収益をあげる、といった3つのバランスが取れている状態がプロダクトの成功かと思っています。

プロダクトを捉える４階層：仮説のミルフィーユ

（SB Intuitions）小城：
「プロダクト」について、頭の中で捉えている4つの階層（「仮説のミルフィーユ」）を言語化した表を書いてみました。

私はもともとソフトウェアエンジニアだったので、「プロダクト」と言えば、それはソフトウェアを指すのかなと以前は思っていました。

この表は上に行けばいくほど抽象的で、下に行けばいくほど具体的なことが書かれているのですが、ソフトウェアはこの一番下のHow階層にあります。UIがあって、設計・実装されて、それがGTM（Go To Market）されているという要素がソフトウェアにはあると思います。

でも、プロダクトマネジメントでは、どうしてそのHowを選択したのか、なぜ今それなのか、といった観点が必要です。

たとえばUIなら、What階層にあるユーザー体験に沿って、「このユーザー体験を提案するために、ボタンは赤いべきだ」といったことが決まります。

さらに、そのユーザー体験の良し悪しを評価するのはWhy階層です。私たちは誰のどんな課題を解決して、どんな状態にしたいのかという定義があるからこそ、課題解決のためには、「こんな体験が必要ですよね」と決定できるのです。

そして、そのユーザーさんをどんな状態にしたいのかを紐解くのがCore階層。Coreはミッションやビジョンのようなものですね。

私はこれを「仮説のミルフィーユ」と呼んでいるのですが、一番上のミッション、ビジョンが一番下のHow階層であるUIまで届くように、プロダクトに強い軸をどう通すかが大事だなと思っています。

WhatやHowだけで捉えられたプロダクト例 / 蛇足のだそ君

（SB Intuitions）小城：
この「仮説のミルフィーユ」の軸がうまく通っていない時に何が起きるのかについては、普段から変な魚のスライドでご紹介してるので、これも載せてみました。

もとのプロダクトが向かって左側の魚の絵だったとしましょう。

この魚をもっと良くしようと思ったプロダクトマネージャーのうち、

イラストだと捉えたある人は「もっと魅力を強めるためには、鼻があったほうがかわいいんじゃない？」と思って鼻をつけました。

競合プロダクトを見た別の人は「ヒレがすごく格好良いのが人気らしい」と考えてヒレをつけてみました。

そうこうしていると、突然偉い人が「もう水中の時代は終わりだ！これからは陸上の時代だ！」と言い出して他社と差別化するために足を生やすことになりました…。

これ、絵に描くのは簡単ですが、いちエンジニアとして骨格的にここに足を生やすのとかめちゃめちゃ難しいと思いますし、相当工数かかるんですよね。

で、すごく頑張って作ったにもかかわらず、右の魚を欲しい人はいるのかと考えると、かわいいイラストが欲しかった人は確実に要らないと思いますし、陸上も全然速くは走れないだろうなという状態になるんじゃないかなと思っています。

この3人は、みんなプロダクトを良くしようと思って頑張りました。でも、プロダクトに軸が通ってなくて、「このプロダクトは何であるのか？」という定義がされてなかったことが問題だったのだと思います。

Fit & Refine で一気通貫 プロダクトに軸を通す

（SB Intuitions）小城：
先程の魚のようにならないために必要なのが、この「仮説のミルフィーユ」に立ち戻ることです。

ヒレや足はHow階層のUIにあたりますが、ヒレと足、それぞれが目的とするユーザー体験の間で整合が取れていなかったのではないかと思っています。

当初のプロダクトとして、誰をどんな状態にするために使われる魚だったのかの定義が合っていたなら、先程みたいにヒレと足が両立することは、なかったのではないでしょうか。

そこで必要だと思うのが、このスライドにあるFitとRefineという概念です。

（SB Intuitions）小城：
Fitは、各階層間での整合性がとれているか確認しましょうということ。こう書くと当たり前に思われるかもしれません。しかし、ある課題についてブレストしていたにもかかわらず、気づいたら良いWhatと思えるものが出てきて、もともと解決したかった課題と全然違う方向になっていたというのは、あるあるな話だと思っています。

特に階層を飛び越える時には、Fitしてるかなと確認することがすごく大事だと思っています。

もう一つはRefineです。

この「仮説のミルフィーユ」の話をすると、「上から下にズドーンと、ミッションやビジョンをもとに仕様を決めていったらいいのね。ウォーターフォールなのね！」って思われてしまうことがあります。

でも、プロダクト作りは仮説検証の繰り返し。できるだけクイックに、CoreからHowに、上から下への行ったり来たりをできるのかが大事だと考えています。

一度上の層を決めたら終わり、といった話ではなくて、下まで行ってユーザーに当てて、仮説検証ができたら、その結果をもって上の層の解像度を上げられないかを考えることがすごく大切です。

まとめますと、プロダクトマネジメントで一番大事なのは、CoreからHowまで1本の勝てる筋を通すことだと思っています。複数ある軸の中から一番いい1本を選んで、それに向けてチーム全体が同じ方向を向いて取り組んでいくことが、私はプロダクトマネジメントだと思います。

（unerry）伊藤：
ありがとうございます。「蛇足のだそ君」、大好きです。非常にわかりやすいお話でした。大勢の方がこの図をご覧になって、現状の自分の仕事と比べて「ここが違ったんだ！」という気づきを得られるのではないかと思います。

私もプログラミングをする中で「この機能をつけるのは何の意味があるのかな？」と戸惑う経験もありました。そこをはっきり声に出していくのが、やっぱりプロダクトマネージャーの意思であり、力であり、成功に導くための大きな要素だと思います。

（SB Intuitions）小城：
絵にするとわかりやすいですが、プロダクトになるとぱっと見てわからなくなってしまうものだとも思います。私たちにとって何がヒレで足なのかを考えることがすごく難しいなと日々思ってます。

WEB開発プロダクトとデータ活用プロダクトの違い

（unerry）伊藤：
ありがとうございます。では次のテーマです。

2つあるのですが、まずは「WEB開発プロダクトとデータ活用プロダクト」の違いについて。プロダクトそのものや、プロダクトマネジメントにおける両者の違いについて小城さんはどうお考えでしょうか？

（SB Intuitions）小城：
WEB開発プロダクトとデータ活用プロダクトの線の引き方は、グラデーションだなと思っています。

私自身、今はLLMを作っており、それはめちゃめちゃデータ活用プロダクトだなと思います。しかし、前職で携わってきたWEB開発プロダクトにおいても、レコメンド機能などデータを活用して意思決定が必要なシーンはありました。また、今のトレンドとしてはAIを活用をして、どんどん良いプロダクトを作っていこうという流れがあるので、WEB開発プロダクトと呼ばれるものも、データ活用プロダクトの一面を持たなければいけないんじゃないかなと思っています。

ただ、プロダクトの作り方としては確かに違いがあると気づいたところもあります。

これまでのWEB開発プロダクトでは、人間がデザインや機能を一つずつ作って、何を作れば何ができるのかを把握しながらルールベースに構築してきたと考えています。人が手厚く、作り込めることがプロダクトの強さだったのではないかと思います。

でもデータ活用プロダクトでは、たとえばホーム画面に何が表示されるのかを、開発者である私が一つ一つデザインするのではなくて、ユーザーにパーソナライズされた、レコメンドされたものが出るように変わっていきます。私の「おもてなしの心」みたいなものは出せず、データに任せるようになるのが、大きな違いだなと思っています。

そこは使い分けかなとも思っていますね。

データプロダクトマネージャーが身につけるべきスキルとは？

（unerry）伊藤：
ありがとうございます。最近ではデータ活用プロダクトを管理する、データプロダクトマネージャーという新しい職種も聞かれるようになりました。データプロダクトマネージャーが特に身につけるべきスキルはあるでしょうか？

（SB Intuitions）小城：
たとえばWEB開発プロダクトなら、作りたい機能や画面を実現できるか否かについては明らかな場合が多いと思うのですが、データ活用プロダクトでは不確実性が大きいと思っています。

その不確実性を超えていくことは、データプロダクトマネージャーに求められることですが、それだけでは「PoCが上手くいきましたね」という話で終わってしまうので、実現にかかったコストをどう回収するのかまでを考えなければなりません。

データプロダクトマネージャーって、一見すごくテックな役割のようにも見えますが、どれだけの投資が必要がわからない中で、データを活用しながら課題を解決して、お金を生んでくる方法を考えなきゃいけないと思うと、すごくビジネス面も強いお仕事だなと思います。

身につけるべきスキルについては、普通のプロダクトマネージャーよりテック的な意味でもビジネス的な意味でもハイレベルなものが求められるのではないかと最近思っています。

（unerry）伊藤：
ありがとうございます。見えにくいところではありますよね。データに関する嗅覚みたいなものが必要なのでしょうか？

（SB Intuitions）小城：
そうですね。でも嗅覚をどうすれば身につけられるのかは、実は経験に頼るところが多いんだろうなとも思います。スキルというよりも、経験が必要な領域なのかもしれないですね。

エンジニアからプロダクトマネージャーに転身するには？

（unerry）伊藤：
弊社でも、エンジニアからプロダクトマネージャーに転身をするメンバーがおりまして日々悩み苦しんでいます。そこで、現場からのお悩み相談です。

エンジニアからプロダクトマネージャーに上手く転身するためには、どうすれば良いのでしょうか？おすすめの方法を聞いてみたいと思います。

（SB Intuitions）小城：
いちプロダクトマネージャーとして、「エンジニアからプロダクトマネージャーになりたい！」と思っていただけるのは、すごく嬉しいです。

で…すごく残念な真実ではあるのですが…

私を含め、実は「気づいたらプロダクトマネージャーと呼ばれていた」とか、「自分の仕事がプロダクトマネジメントだったと気づいた」というパターンの方が、目指してなった場合よりも正直多いんじゃないかと思います。

でも、やはり年月が経ったことで、プロダクトマネージャーになるためのラダーが整理されつつある、というのが今なんだろうという実感もあります。

なので、いきなり一流のシニアなプロダクトマネージャーを目指すよりも、まずはプロダクトマネージャー1年生になるためにはどうすればいいかを考えると、すごくいいんじゃないかなと思っています。

会社に一人しかプロダクトマネージャーがいない場合は全部やらなきゃいけないですが、一般的にはシニアなプロダクトマネージャーとアソシエイトのプロダクトマネージャーの仕事は、だいぶ分かれてきていると見ています。

シニアのプロダクトマネージャーがやるのは、プロダクト全体の戦略を考えて、どのタイミングでどういう戦術を実行していくかをロードマップに落とし込んでいくこと。また、そのロードマップをマネジメントするのが仕事であり、その結果として、いくらの売上をどう達成するかまでの責任を持ってる人もいるかなと思います。

エンジニア職種からいきなり、シニアなプロダクトマネージャーを目指すのは結構大変です。一方、最初に目指すと良いだろうアソシエイトプロダクトマネージャーの仕事は、シニアがロードマップを描いて、タイミングやお金の稼ぎ方などイシューの分解をした後から始まると思われます。課題解決のために、どんな機能をどう提供するべきかを考えるのが、アソシエイトプロダクトマネージャーの仕事ですね。

エンジニアからプロダクトマネージャーを目指す人が、つけるべき「癖」とは？

（SB Intuitions）小城：
エンジニアさんは機能を作るのが得意なので、どんな機能があるといいのかは、きっと考えられると思います。

でもプロダクトマネージャーの立場では、その機能はどんな課題を解決するかとか、課題を解決するために複数ある機能案に優先度をつけたりだとか、善し悪しの判断も必要です。

なので、エンジニアからプロダクトマネージャーを目指す方は、自分たちが作った機能がどんな効果をもたらすか、ユーザー体験的にもビジネスモデル的にも解き明かしていく癖をまずつけるのがいいのではないかと思います。

プロダクトマネージャーが書いたPRD（プロダクト要求仕様書）を読み、その機能はどんな目的で、なぜやるのかを自分の言葉でも語れるようにして、機能からどんなWhyがあるのかを読み解けるようになるのが、プロダクトマネージャー1年生に向けた1歩なんじゃないかなと思っています。

（unerry）伊藤：
ありがとうございます。確かにエンジニアはPRDを目にする機会が多いので、その意味では転身に近いところにいると思います。

（SB Intuitions）小城：
おっしゃるとおりだと思います。

ただ、私はエンジニアからプロダクトマネージャーになった時に驚いたことがありました。

エンジニア時代には、まさにPRDを書くのがプロダクトマネージャーの仕事だと思っていたのですが、本当に大事なのは仕様書に書いてあることではなく「なぜその仕様書が選ばれたのか」ということ。そこにプロダクトマネージャーとして考える時間を使っているのだなと最近思うようになりました。

エンジニア目線では選ばれた結果しか見えていなかったのですが、プロダクトマネージャーである自分の仕事には、仕様書を書くことだけでなく「何の仕様書を書くのか」を決める部分が含まれる。そこに気づいたのは、エンジニアからプロダクトマネージャーに転身して以降、自分の中で解像度が上がった瞬間だったなって思います。

（unerry）伊藤：
なるほど。なんでそれを選んで書いたのか、ですね。

（SB Intuitions）小城：
良いアイディアって複数の課題を解決できるものだと思いますし、思いついた機能アイディアを全部実装するわけにもいきませんから、一番効果があるのはどれなのかを考えなきゃいけないですよね。

（unerry）伊藤：
限られたヒト、カネ、モノで、何をどこへ向かって、やるかですね。

（SB Intuitions）小城：
そうですね。どこにどうリソースを配分して未来を作るのか、そこを考えることができればロードマップを描けるんじゃないかと思います。

一つのPRDが書けるようになって、他との善し悪しがわかるようになって、その結果としてどんなビジネスがあるのかわかるようになって、ロードマップが管理できる、というようなラダーを登っていくのが、よくある今の流れかなとは思ってます。

（unerry）伊藤：
主に大変わかりやすい解説です。ありがとうございます。

スタートアップと大企業におけるプロダクトマネジメントの違いとは？

（unerry）伊藤：
本日最後のテーマです。unerryのようなスタートアップと、大企業とではプロダクトマネジメントに違いがあるかどうかをお聞きしたいなと思います。

（SB Intuitions）小城：
ありがとうございます。

そうですね。すごく抽象化すると、プロダクトマネジメント自体に違いはないと思うのですが、それを具体的にどう進行するかだとか、何を大事に進行するかという点では、違いが出てくるかと思っています。

一番は人数の違い。私は十数人のスタートアップも2万人超の大企業での経験もありますが、少人数組織の場合は、マーケティング担当1人、プロダクトマネージャー1人、デザイナー1人みたいな形で、お互いの職種間のコミュニケーションはスムーズだと思う反面、自分の役割は全部自分でしなければならなかった。

大企業側では、たとえばマーケティングでも専門化がされていて、マーケティング〇〇課、△△課、××課といった組織がありますよね。関わる人数が増えるので知識量やスキルセットはスタートアップより大きなものを得られますが、みんなが同じ方向を向くことの難易度は上がるとは思っています。

プロダクトマネジメントの観点では、先ほどお話した「仮説のミルフィーユ」における4つの階層において全員が同じ認識を持つために、より言語化をして、よりストーリーテリングを行って、といったことが必要だと大企業に来て今、すごく思っています。

（unerry）伊藤：
ありがとうございます。小城さんは両方を経験されてるからこそ、よくわかるということですね。ありがとうございました。

小城さんからみなさまへのメッセージ

（unerry）伊藤：
本日はお時間いただいてありがとうございます。最後に一言お願いできればと思います。

（SB Intuitions）小城：
プロダクトマネジメントは本当に難しい仕事だと思うのですが、その理由の一つが、1プロダクトに1人しかプロダクトマネージャーがいないことなんじゃないかなと思っています。他の人から学んだり、誰かからフィードバックをもらったり、誰かを目標にしたりすることが、すごく難しい職種です。

そこで、他社のプロダクトマネージャーさんと交流できる場っていうのがあるといいのでは？と思い、#プロダクト筋トレ というSlackコミュニティを運営しています。

もしプロダクトマネジメント、プロダクトマネージャーにご興味ある方いらっしゃれば、ぜひご参加いただければと思います。より良いプロダクトマネジメントについて一緒に考えていければと思いますので、お悩みの方はぜひご参加いただければと思います。

また、現在は、国産のLLMを作るSB Intuitionsという会社に所属しているのですが、全方位エンジニア、プロダクトマネージャー、その他職種含めて採用中になります。ご興味あればぜひカジュアル面談させてください。

今日はお時間いただいてありがとうございました。

（unerry）伊藤：
小城さん、貴重なお話をありがとうございました。

プロダクト筋トレコミュニティはこちら
https://www.productkintore.org/

SB Intuitions株式会社　採用情報はこちら
https://www.softbank.jp/recruit/career/positions/list/?tag=sb_intuitions

株式会社unerry　採用情報はこちら
https://hrmos.co/pages/unerry

• #SPECTACLEs
• #データアナリスト
• #データを楽しむ
• #仲間募集