経営陣の理解を得られない…PMはどう動く？ Q＆Aコーナー
講演の後半では、参加者からの質問に回答するQ＆Aセッションが展開された。いくつか紹介する。当日答えきれなかった質問にも、山崎氏に回答いただいた。
プロダクトマネージャーと経営陣・他部署の理解
Q プロダクトマネージャー以上の権限を持つ管理者があまり理解を示さずに進めようとする場合、プロダクトマネージャーはどう動くべきでしょうか？
山崎氏：おそらく、経営陣に近い管理者のことだと思いますが、やはり経営陣が何を重視しているかを確認した方が良いと思います。プロダクトマネージャーは経営陣に最も近いですし、経営陣が最も重要とすべき人材ですので、寄り添って信頼を得る必要があります。経営陣の信頼を得られていないと、プロダクトチームも悲惨なことになったり、プロダクト自体もうまくいかなかったりするでしょう。プロダクトマネージャーの自覚として、経営陣とはうまくやることを念頭に置きましょう。
具体的には経営陣が重視していることを聞き、その仮説が正しいかどうかを検証してレポートするところから始めます。7つのシコウの1～4（1.思考、2.指向、3.志向、4.試行）あたりを駆使して、そのアイデアがよいものかどうかを示していきます。ただし、本当にどうしようもない場合もあると思います。そのときは思い切って転職を考えるのも一つの選択肢です。組織をなんとかしたいのか、ユーザーに向き合いたいのか、ご自身が何をしたいかを優先した方がいいでしょう。
Q 経営陣やセールス担当はリリースを優先しがちです。どのようにプロダクト思考を説明、理解してもらいましたか。
山崎氏：私は、期待以上のスピードで作ってリリースします。経営陣やセールスチームが言うこともわかります。ですから、プロダクトのスコープを小さくして、例えば車を作りたいなら、スケボーくらいまでシンプルにします。そして経営陣やセールスチームが何を実現したいのかを優先します。プロダクトの強化はあとからでもできます。自分が思い描く姿というものをバージョン10くらいにして、まずはバージョン1を出して評価します。そのあとからでも自分が作りたいものは作れますから。
早く市場投入して顧客の反応を見られるのはとても良いことなので、プロダクトシコウの1.思考、4.試行、5.施行を使って経営陣やセールスチームと話し合いながらどんどんリリースします。
ただし、機能を1つのリリースにたくさん追加したいという要件が出た場合は要注意です。機能を載せるか載せないかを議論していたら開発が止まってしまいますので、優先順位を決めてリリースごとに素早く実装するようなコミュニケーションをしていくことが有効です。特に「次回以降のリリースに追加します」というコミュニケーションは効果的です。
Q 経営層がプロダクトマネジメントへの理解がない会社で、その重要性を伝えていくよいアイデアはありますか？
山崎氏：創業社長がまだいるなら、創業社長を巻き込みましょう。創業社長はもともとプロダクトマネージャーであることが極めて多いです。たとえ経営層がプロダクトマネジメントについて理解してない会社であっても、創業時にそのサービスやプロダクトを考えた人はいるはずです。そういった人を見つけていくことが重要です。くれぐれも避けてほしいのは、経営層 VS プロダクトチームという対立構造です。これはプロダクトチームにとって何もいいことはありません。経営層の中に味方を見つけて、信頼を得るところから始めましょう。私は、7つのシコウを高いレベルで実践していけば、おのずと経営層の信頼を得られると考えています。
Q 仮説検証について、ビジネス側はブランドイメージや納期、予算を気にしてあまり仮説検証ベースのプロダクトのリリースを許可しないのですが、その場合どのように仮説検証を行っていけばよいでしょうか？
山崎氏：プロダクトの成功を先に定義するのが良いと思います。どの数値がどのくらいになれば成功なのか、いわゆるKGIやKPIツリーを構成して、戦略を明らかにするのが最も近道だと思います。7つのシコウで言うところの「2指向」をうまく使うと良いと思います。
エンジニアバックグラウンドと企画バックグラウンド
Q エンジニアリングバックグラウンドのプロダクトマネージャー育成において気をつけなければいけない点はありますか？
山崎氏：一番は、作り込みすぎないように注意することです。私も気をつけていますが、エンジニアリングバックグラウンドの人は、将来のことを考えてきっちり開発したがる傾向があります。仮説検証やプロトタイピングの段階で作り込みすぎてしまうと、その後、方向転換したくてもできなくなる弊害があります。市谷さんとの対談の記事にもありますが、3カ月の期間があったら1カ月半ぐらいで作るぐらいの勢いでやらないと作り込んでしまいますので要注意です。
Q 企画系のバックグラウンドを持つプロダクトマネージャーはプロダクト思考に向いていない印象があります。どのように実行すべきでしょうか。
山崎氏：企画系の方でもアジャイル開発は学べますし、いくらでも方法論はあります。エンジニアリングバックグラウンドの方でも現場のエンジニアリング離れている方がプロダクトマネージャーを担当されたり、そもそもエンジニアリングバックグラウンドない方がいきなりプロダクトマネージャーになったりするケースもあります。そういう意味では企画系のバックグラウンドでもまったく問題ないと思います。
Q 開発経験なしでプロダクトマネージャーをやっています。開発の知識をどの程度つける必要がありますか。
山崎氏：エンジニアから一目置かれる程度には知識を身につけるのが望ましいと思います。というのも、プロダクトチームをマネジメントするのもプロダクトマネージャーの仕事の1つであり、プロダクトチームの大半を占めるエンジニアに尊敬されることはプロダクトを成功させるため、ひいてはプロダクトマネージャーとして成功するためには重要である場合が多いからです。
Q エンジニアリングバックグランドのプロダクトマネージャーと企画バックグランドのプロダクトマネージャーで、アサインする案件を調整していくことはありますか。もしアサインを変えていく場合、観点を教えてください。
山崎氏：インフラを含めてアプリケーションを1から立ち上げる場合はエンジニアリングバックグラウンドの知識が有効になる場合は何度も見てきました。少なくともエンジニアの言っていることが詳細に理解できないと細部で判断を見誤るリスクが生じます。一方で、すでにインフラやアプリケーションが立ち上がっており、ビジネスとしてのスケールを目指す場合は必ずしもエンジニアリングバックグラウンドの優位性はなく、企画バックグラウンドの活躍の場になることも多く見てきました。必ずしもそうなるという話ではありませんが、参考程度に検討していただければと思います。
評価とスキルアップ
Q プロダクトマネージャーが持つべきスキルを身につける環境もなければ、スキルを持つシニアのプロダクトマネージャーがいない企業もあります。どのようにして身につけていけばよいでしょうか？
山崎氏：これは本当に難しい問題です。プロダクトマネージャーが孤独だという問題に通じますが、プロダクトが少ない会社はプロダクトマネージャーも少ないです。その場合、書籍やセミナー、カンファレンス、プロダクトマネージャー同士の勉強会で身につけていくしかないと思います。
これはハードな回答かもしれませんが、一度自分のキャリアをトレーニングモードに変えて、プロダクトマネージャーがたくさんいる、つまり、プロダクトがたくさんある組織に転職するという裏技もあります。そうすれば、さまざまなレベルのプロダクトマネージャーといっしょにディスカッションしたり学習したりできる機会を得られます。
Q プロダクトマネージャーの評価はどのようにしているのでしょうか？
山崎氏：弊社ではビジネス的なインパクトの大きさで評価しています。長期的に見て、プロダクトの可能性を示した総利益額。例えば5年後、10年後LTV（Life Time Value：顧客生涯価値）の予想など、今後積み上がっていく総利益額がどうなるかで判断します。プロダクトによってどれだけユーザーの困りごとを解決し、その対価をえられるか、という意味でも利益はわかりやすい指標の一つです。どれだけプロダクトが愛されているか、ファンの数やユーザー数などを指標にした方が良い場合もあります。音楽業界でプロデューサーの力量をCDの販売数で評価するようなことと同じですね。
Q 明日から、全く知らない環境でプロダクトマネージャーをやることになった人（PM経験なし）に、山崎さんがかけるアドバイスは何ですか。
山崎氏：まずは社内で師匠を見つけることですね。事業会社では社内にプロダクトマネージャーという肩書でなくても実質的にプロダクトマネージャーとして働いている人が必ずいます。そのような人を見つけて、師事を仰ぐのは一つの方法です。
Q プロダクトマネージャーとして何をどうすることが正しくて、結果的に（チーム的にも開発的にもユーザーに対しても、あらゆる意味で）うまく進めることができるのか迷っています。今どんな行動をとって、シコウを得ていくことがおすすめでしょうか。
山崎氏：どんな名人でも初心者の時期があるように、どんなプロダクトマネージャーでも立ち上がりの時期があると思います。いきなり7つのシコウすべてで100点を目指すのではなく、徐々に点数を高めていくのが良いと思います。アプローチとしては、自分の得意分野を見つけながら部分的に点数を高めていく方法と、全体を俯瞰しながら全体的に点数を高めていく方法の2つがあると思います。どちらでもご自身にあっている方法を選ぶと良いと思います。
その他
Q アジャイル開発において、どういった開発手法を実践していますか？ スクラムを導入されていますか？
山崎氏：スクラムは積極的に導入しています。ただし、全部をスクラムというわけではありません。アジャイル開発にはスクラム以外の方法論もあります。有名なものに、カンバン方式やフロー開発と言われるものがあります。スクラムはイテレーションをきっちり作って、2週間でどんどん回して学びを得て次のイテレーションを作っていくやり方です。カンバン方式やフロー開発はもっとライトで、チケットをベースに開発を進めていきます。プロダクトをリリースして、どんどん PDCAを回していきたいときはカンバン方式やフロー開発の方がよい場合があります。だからプロダクトのファーストリリースまではスクラムで作ってその後カンバン方式やフロー開発に移行してくっていうのが結構多いパターンですね。
Q プロダクトの作る・作らないの判断はどのように行いますか。
山崎氏：突き詰めると作る、作らないの判断ではなく、プロダクトA、プロダクトB、プロダクトCのどれを作るべきか、どれを育てるべきかという話になると思います。なので、プロダクトをつくらない＝別のプロダクトをつくる、育てると考えるとわかりやすいかな、と思います。
