組織内にプロダクトマネジメントを定着させるには？ PMの権限の範囲は？
セッションの後は、参加者から多くの質問が寄せられた。3名は自らの経験を踏まえて、真摯に回答した。当日答えきれなかった質問についても、回答いただいた。
Q．組織内でプロダクトマネジメントを定着させるにはどうすればよいでしょうか？
中島氏：僕は社内のプロダクトマネージャー第1号でした。いきなり全て変えようとか、急に自分が取り仕切るのではなく、成功事例を作って、少しずつ信頼を獲得していくっていうことが大事だと思います。プロダクトマネージャーがいることで、うまくプロジェクトが進むという実例を作って、そこから輪を広げていくことが必要なのかと思います。
土岐氏：結構ボトムアップで、他のチームにもどんどん話を聞いて、ビジネスチームとの連携なども少しずつ作ってくことが定着につながっていくと思います。
Q．プロダクト組織での情報共有はどうしていますか？
土岐氏：大きく2つあります。1つ目がプロダクトウィークリーレポートで、リリースされた機能などの簡単なニュースを毎週共有しています。最低限知っておいてほしい情報は3行でまとめて共有したりしています。もう1つがOKRウィンセッション（従業員の達成を発表する会）です。こちらは2週間に1回やっています。一方的な発表の場にならないよう、ラジオ番組のような形式になっています。
大塩氏：OKRウィンセッションは、目標を持っているメンバーから開発を実際に担当しているメンバーに対しての一方的な情報共有になりがちで、参加メンバーとしては結構退屈になりがちです。そこを参加型にする工夫をみんな頑張っていますね。
Q．プロダクトマネジメントの導入のとき、外部のコンサルタントなどを招聘することは検討しましたか？
中島氏：われわれは福岡で仕事しています。当時周りにプロダクトマネージャーという肩書の人はあまりいなかったと思います。必然的に自分たちで試行錯誤していく形になりました。
土岐氏：私も最初実はプロジェクトマネージャーとして入社したわけではなくて、入社後にプロダクトマネージャーになり、中島さんとともに試行錯誤してきました。
大塩氏：そこで、やみくもに試行錯誤しても無駄骨になってしまうので、データを見るっていうのが大事ですね。データを根拠に、今ここに課題があるから、ここを埋めようというロジックにつながります。データを見る文化は、私たちのプロダクトマネジメントを変えた印象があります。
Q．機能制限の意思決定において注意した点をお教えください。
土岐氏：重要なのが企業のミッションやビジョンの連携です。データだけだとそこの部分で抜け落ちてしまいますので、組織がたどり着きたい未来に対して、今やろうとしていることあっているのかを測ることが重要です。機能制限のときはかなり議論をして、CEOを含めて戦略立てるメンバーでかなり悩みながら決定した記憶があります。みんなが腹落ちするまできちんとロジックを話し合って決めました。
中島氏：地図のダウンロード制限の話は、僕が言い出したと思います。ずっとデータを見ていて、みんな地図をダウンロードしているので、そこに価値を感じてくれると確信しました。議論の際は、健全な形で制限を入れられることを念頭に置きました。
Q．プロジェクトマネジメントとプロダクトマネジメントの違いをお教えください。
中島氏：プロダクトマネージャーをやっていく上ではプロジェクトマネジメントも必要なスキルです。プロジェクトマネジメントはどう作るかや、いつまでにリリースするかなどが主なスコープになります。一方プロダクトマネージャーは、何を作るのか、どうインパクトを出すのかに注力します。小さな組織では、プロダクトマネージャーがプロジェクトマネジメントも兼ねる部分はあるでしょう。
土岐氏：プロダクトマネージャーはリリースも含め、全体的にどうアウトカムを得ていくかが責任範囲になります。弊社ではプロジェクトごとに話し合いながら責任範囲を区切っています。
Q．プロダクトマネージャー＝ミニCEOという考え方もあるようですが、プロダクトマネージャーの権限についてはどうされていますか？
中島氏：決定権者として力を振りかざすというのとは全然違います。プロダクトマネージャーは信頼が基本です。人事権を使わずに、コミュニケーションして納得・信頼してもらうことが大事だと思いますね。
大塩氏：権限が強い、えらい人ではないですね。「面倒くさいことをやってくれる人」というと、語弊があるかもしれないですが、そういったポジションだと思います。開発プロジェクトでは、主役はデザイナーやエンジニアといった、実際に手を動かして生み出す人たちです。プロダクトマネージャーは脇役で、彼らが困ったときに支えるような立ち位置にいるというマインドセットでプロジェクトを動かせると、信頼につながっていくと思います。
土岐氏：最終的な責任を持つ覚悟は絶対必要ですが、全部自分で決めるってわけではなくて、あくまでもサポートしながらも決まったことに責任を持つ感じです。ちょっと変な方向に行きそうだったら止める権利もあります。どっちにしてもなぜそうするかの説明責任は常に伴います。開発チームには、機能をどう作るかに集中してほしいです。
Q．多岐にわたるPM業務のなかで手の抜き方のコツみたいなものはあったりしますか？ それとも手を抜かずすべて全力で取り組むことが求められるのでしょうか？
土岐氏：すべてに全力で取り組みたいところですが、時間的な制約もあり現実的に無理です。「手を抜く」というよりも、できる限り仕組みを作って「人に任せる」ことを考えています。「時を告げるな、時計を作れ」という言葉がありますが、少し面倒でも「時計を作る」＝「仕組みを作る」という意識は持つようにしています。とはいえ、やはりどうしても手を動かさなければいけない場面もあるのでなかなか大変ですね。
Q．「三点支持」の比喩では、３つのポイントを安全にして４つ目のポイントでリスクを取りに行くようなことを想像したのですが、発表を聴きそういった意味合いではないと理解しました。リスクを取りに行くときにどこまで地固めをするかは、何を意識しているでしょうか。
大塩氏：3つの要素のうちどれかが疎かになってもプロダクト開発は成功しないことを説明するために、三点支持という言葉で例えることにしました。3つの要素を鼎立した状態で第四の要素を取りに行くという意味までは含んでいません。
新たなリスクに挑戦する際は、それが顧客の課題を突いているか（これはご認識のとおりデータ集めや調査によって仮説の確度を高めていきます）、もしくは会社として顧客に訴えかけたい確固たるビジョンに基づいたものであるかということが大切かと思います。（大塩）
Q．競合比較はどのように行っていますか？ ユーザーに対してアンケートで聴取したりしていますでしょうか。
中島氏：競合アプリ・サービスを極力使って分析するようにしていますし、競合製品のアップデート情報などはアンテナを張って追いかけています。利用状況などの分析は外形的にわかる範囲で調べて比較しています。ユーザーアンケートで競合についての情報を集めることは行っていませんが、App Store/Google Play のレビューで他社製品に言及してある際は確認するようにしています。重要なのは単なる比較ではなく、どこに彼我の強み・弱みがあるのかだと思います。弱みは無視できないものなのか、それとも放っておいてもよいものなのか、弱みを補強することでユーザーのペインを解決出来るのかという観点で判断すると良いと思います。
Q．エンジニアの経験があったからこそ、良かったこと、生かされたことはありますか？
土岐氏：技術的な前提や難易度、アーキテクチャについてある程度予測がつき、エンジニアとのコミュニケーションも取りやすい点は、やはり経験があって良かったことですね。あと、ちょっとしたデータ抽出・加工にもSQLやPythonを使うこともあり、少しでもプログラミングができているとやれることは広がると思います。一方で欠点としては、「どう解決するか」というエンジニアリング的な解決方法（HOW）から考えてしまって、Why、Whatが後回しになってしまうことがあるとも感じています。
中島氏：エンジニアの気持ちがわかることがメリットだと思います。 プロダクトマネージャーはデザイナー、エンジニアの力を借りないと製品を世に送り出すことは出来ません。良い協力関係を築くために、過去にエンジニアだった経験は活きてくると思います。
