調整役にならないためには？ 組織に"PM"という存在をどう伝える？ 当日答えきれなかった質問も
また、当日答えきれなかった質問についても、以下のように補足・回答していただいた。
- 調整役にならないために重要なことは？
- PMとして特定ドメインにピボットをする際の注意点
- PMと組織の役割の相関の理想は？
- 最近現場にプロダクトマネージャーが来たが、チームが正しく役割を認識できていない
- プロダクトマネージャー、プロジェクトマネージャーの違い（当日の補足）
- ユーザーと共同するためのポイント
- （機能開発の優先度付けを）営業に決めてもらうと「問題への主体性」の観点が落ちてしまう？
- 修士卒でPMになる場合、どう深掘りしていくか？
- 限られた開発リソースの中で、追加機能の判断軸は？
- プロダクトマネージャーに向いている性格、資質
- 組織内でPMを正しく認識してもらうためには？
- どの状態になればPMFを達成できていると言えるか？
- プロダクトの付加価値として、どういう優先順位の決め方をすべきか
- （ユーザー理解のために）自身サービスをの無理してでも使ったほうがいいのか、それとも自身が使う気になるサービスにしていくほうがいいか？
つまらないと思った仕事に疑問を持つこと。調整役は楽しくないと思います。楽しくない仕事はなにかがおかしいと考えること。そこに自分がやるべき意義があるのか考え、やる必要がない場合は自分がいなくても回る仕組みをつくることです。（及川氏）
「誰かがこう言ったから」ではなく、自分の意見として口に出すこと。（小城氏）
プロダクトマネージャーとしての意志をはっきり示す。（曽根原氏）
Q：PMとしてドメイン間（BtoB、BtoCやMobile、AR/VR等）で、ピボットをする際に注意すべき点、専門知識や業界特有のニーズの把握の仕方などを教えて頂けますと幸いです。
まずは「自分は何も知らない。だからなんでも知りたい」というメンタルを持つこと。業界知識の基本と用語を学び、その上で業界がどんな力学や業界慣習で動いているかを学ぶ（スポーツで言えばルールを学ぶ感じ）。どんなプレイヤーがどのような価値を提供しているか業界全体を俯瞰する視点でまずは頭に地図を作る。そのうえで自分が持っているこれまでのスキルや経験がどうその業界や会社で価値になるのかを考えながら、専門知識を深める。（曽根原氏）
新しいドメインは楽しいので、楽しさを追求すれば良いと思います。楽しいと思えないドメインへのピボットはやめておいた方が良いです。（及川氏）
Q：PMという役割と組織においての役職の相関はどのような姿が理想でしょうか？
理想は会社のあらゆる部門がプロダクトのことを考えられるプロダクト志向な組織。PMはそうした声に耳を傾け、顧客にとって最適な価値を導き出せる。（曽根原氏）
役職とPMには相関はありません。役職者はあくまでもステークホルダーの一部です。PM組織の役職者は自分のメンターであるとともに、大きい粒度のプロダクトを考える人であるはずなので、ビジョンを共有し、ディレクションを揃えていく必要があります。（及川氏）
Q：エンジニアです。最近現場にプロダクトマネージャーが存在するようになったのですが、チーム全体でまだ役割を正しく認識できてない状態なのかなと思っています。そのような現場でエンジニアやデザイナーなど周りのメンバーがフォローするようなことができればいいかなと思っているのですがどのような振る舞いをしていくのが良いでしょうか？
プロダクトマネージャーは孤独を感じることが多いので、そのように考えているメンバーがいることが何よりの心の支えだと思います。まずはその姿勢をプロダクトマネージャーに伝えること、そしてプロダクトマネージャーがメンバーを巻き込んで改革を起こそうとしているときに、一番の賛同者になっていただけるとプロダクトマネージャーの心理的安全性が担保されて良い仕事ができるようになるのではないでしょうか。（小城氏）
プロダクトマネージャーがいないことによって生じている問題をまずは共有し、その解決を一緒に考えていくという姿勢で臨むと良いと思います。（及川氏）
Q：プロダクトマネージャー、プロジェクトマネージャーの違いを皆さんの視点で回答いただけると幸いです。（当日の補足）
どちらもPから始まり、日本ではそのどちらもがPMと略されることから間違われやすい役割となっていますが、この2つはそもそもの概念からして異なるために違いを説明するというのも難しいものです。
まず、プロジェクトマネジメントのゴールは、品質・リソース・期間の3つの軸でその目的となる要件を満たすことです。そして、プロダクトマネジメントのゴールはプロダクトを成功させることです。この2つはプロダクトをより良くしていくために、いくつものプロジェクトを実施していくという関係です。
プロダクトがスマホアプリであれば、そのアプリをリリースするというプロジェクト、ユーザー数を100万人に達成させるプロジェクトなどを実施してプロダクトを成功に導いていきます。また、プロジェクトは階層構造を取りますのでアプリをリリースするというプロジェクトには、ユーザーニーズをヒアリングするプロジェクトや、ログインフローを実装するプロジェクトなど、複数のプロジェクトが含まれるでしょう。
まとめますと、スマホアプリを成功させることがプロダクトマネージャーの責任です。そして、「ログインフローを実装するプロジェクト」が予定された期日、予定された人数、予定された品質で進行することに責任を持つのがプロジェクトマネージャーの責任範囲です。（小城氏）
Q：準委任でユーザーの話を聞きながら開発を行っていますが、「ユーザーの問題」にいま一歩踏み込めていないように感じます。ユーザーとも共同するためのポイントがありましたらアドバイスいただけないでしょうか。
いくつかありますが、まずしっかりとチームビルディングすることから始める必要があるかと思います。また、ビジョンをしっかりと策定し、共有することでしょうか。（及川氏）
例えば、時間を取って一緒にカスタマージャーニーマップやユーザーストーリーマッピングを実施してみるのはどうでしょうか？ 実際のユーザー体験を一緒に議論することで、議論が空中線にならず、具体的な認識を合わせることができるため、おすすめです。（小城氏）
Q：（機能開発の優先度付けを）営業に決めてもらう、だと「問題への主体性」という観点が落ちてしまうのではないでしょうか？ 開発速度の最大化、という意味では良いのですが。
PMは問題への主体性と、収益性も同時に考える必要があります。BtoBの場合どのような顧客からどのくらい収益を上げられるかを一番良く知っているのは営業です。そこで営業チームの収益インサイトを最大限活用しながら顧客にとっての課題を主体的に考えるというスタンスをPMはとります。（曽根原氏）
Q：USでは修士卒でPMになるキャリアがあるとお聞きしましたが、その場合どのように深掘りをしていくのでしょうか？ 自分の理解としては、ある分野を深掘りするのが良いと思っています。
講演でも話したとおり、PMは研究者ではありませんので、特定の分野を深掘りするだけではPMとしてキャリアを確立できません。USの場合は修士卒であっても最初はPMインターンとして最初のキャリアを積みながら、自分にたりないところを広げていきます。（曽根原氏）
Q：限られた開発リソースの中で、追加・改善する機能の判断をすると思いますが、 追加機能の判断軸はどのように考えていますでしょうか。
プロダクトの成功は「ビジョンの達成」「ユーザー価値の最大化」「収益の最大化」の3つのバランスです（参考：連載第10回）。機能を追加するときの判断軸もこれに等しいかと思います。また、この3つの判断軸からプロダクトの指標をつくることになります。指標については第11回をお読みください。（小城氏）
Q：プロダクトマネージャーに向いている性格、資質などありましたら、教えてください。
「やり遂げる」「建設的な議論をする」「勉強熱心」の3点は必須かと思います。先日、プロダクトマネージャーの方向けにどのような素養が必要であるかをアンケートを取らせていただいた結果を公開しているので、こちらもご参考ください。（小城氏）
Q：組織内で"PM"という存在の役割を正しく認知してもらうには、どのような行動や発信をしていくべきでしょうか？
第8回の「プロダクト組織移行へのヒント」をぜひご参考下さい。（小城氏）
Q：スタート後にまずは、PMF（Product Market Fit）を目指すことになると思いますが、どの状態になればPMFを達成できているのかを、どのように定義したほうがよいですか？
お金を払ってでもプロダクトを使ってくれる顧客がいる状態。（曽根原氏）
曽根原さんの言う通りですが、加えて、予想通りに進めば（ユーザーが増えて、マネタイズも進めば）プロダクトを継続成長させていけるというエビデンスを示せる状態。（及川氏）
Q：BtoBプロダクトで、ターゲットが業種職種ともに360度を対象にしている場合、プロダクトの付加価値として、どういう優先順位の決め方をすべきだと思いますか？
二兎追う者は一兎も得ずです。360度を対象にしているとしても、内部的なロードマップ上はターゲットをセグメントに分けて、戦略的に1つ1つのセグメントの付加価値を上げていくと良いと思います。（小城氏）
Q：ユーザーの問題を把握するためには自身がユーザーになるとありましたが、 私のライフスタイルではあまり自身のサービスを使う用途が無いので無理してでも使ったほうがいいのか、それとも自身が使う気になるようなサービスにしていくほうがいいのでしょうか？
難しい問題ですね。例えば、私たちは今書籍というプロダクトを作っています。私たちは当然ですが書き手であるため、読者（ユーザー）として、このプロダクトを使うことはできません。
それでも、自分自身の頭を一度真っ白にして読者の視点で本を読み返してみることや、ペルソナを設定してそのペルソナを自分に憑依させてプロダクトに向き合うことができます。そういった意味で、自分自身がユーザーとなる時間を持つのが良いと思います。
また、プロダクトマネージャーは「ユーザーの問題の専門家」です。プロダクトマネージャー自身がプロダクトを使って必要な機能を洗い出すことも重要ですが、ユーザーがどうしてそのように考えるのかに共感し、寄り添うためにプロダクトを体験しておくことが必要です。自分がプロダクトを使うという体験を利用して、ユーザーの問題を分析することを意識するのが良いかと思います。（小城氏）
