「センスがない」と突き放す前に。戦略的にチームで意思決定の質を高めるコミュニケーション術

プロダクトマネージャーとして働いていると、相手の提案に対し、「それは絶対に違う！」と反射的に思うことがあります。この、直感的に「ユーザーにとって価値のあるプロダクトはそうではない」と気づき、論理的に説明する能力は、一般的に「プロダクトセンス」と呼ばれています。

• keyboard_arrow_down 自分のセンスを疑い続ける
• keyboard_arrow_down センスとエコーチェンバー
• keyboard_arrow_down 改善につながる5つのNextAction
• keyboard_arrow_down センスは育てられるけれど、得意な仕事をやったっていい

実を言うと、私は「センス」という言葉が苦手です。

例えばファッションにおいて、センスがあるとか無いとか、センスがあると自称する人にしか分からない目に見えないものさしで測られるのは大変居心地が悪く感じます。センスという目に見えないものより、「実際にユーザーが幸せになったかどうか？」に焦点をあて、目に見える定量的な結果で評価されることを望みます。

ただ、定量的な結果を出す過程では目に見えない能力を利用しています。私自身、プロダクトマネージャーとして経験を重ねる中で2つのアイデアがあったときにそのどちらが良いかを判断できるようになりました。

直感的にどの案でどれくらいの数字の改善が見込めるか、リリースしなくても分かるのです。先に直感的な数字が出て、エクセルを弾くと合っている、という順番です。これをチーム内では「占い」という言葉で呼んでいました。

一方で、占いをするたびに不安もありました。

私の感覚で「良くない」と判断した提案を支持しているチームメンバーがいるということは、その提案者は私には見えていないポイントを見ているはずです。私と提案者、私とユーザーの頭の中にある差分を埋める作業を怠ったら、すぐに占いの質は落ちてしまうはずです。

そもそも「良いセンス」とは何でしょうか。

答えは1つではないと考えています。センスの良いアイデアとはサプライズであり、「普通に考えたらこう！」という平凡なアイデアではなく自分の発想の外側にあるものだと思います。場合によっては受け入れるのに時間がかかり「そう来たか〜」とやられた気持ちになるものではないでしょうか。自分の発想にはない「もっといいアイデア」がある可能性がある以上、「あの人はセンスが悪いな」と思ったとき、深淵もまたこちらを覗いているのです。

そして、似たセンスを持っている集団では、良くも悪くも「エコーチェンバー現象（価値観の似た者同士が交流・共感し合うことで、特定の意見や思想が増幅する現象）」が起きます。

プロダクトマネージャーの仕事は「チームの中でプロダクトにとっていまなにを良しとするのか？」のものさしを意思決定し共有することなので、チームの価値観が共有されているのは良いことです。一方で、多様な視点からのレビューを受けられなくなり、世間とズレた意思決定をしてしまう危険をはらみます。多様性から学ぶ余白を残すためにも、「センスが悪いかもしれない？」と思った相手から学ぶ姿勢は重要です。

一方で、やはり占いができる身からすると「そのアイデアでは数字が動かないだろう」と感じるアイデアをジュニアメンバーから提案されることもあります。

一番大切なことは、本当にセンスが悪かったとしても「あなたはセンスが悪い」と言わないことです。「センスが悪い」という指摘だけではどう改善していいかわかりません。Next Actionに繋がらない評価でスッキリするのは評価をする側だけで、相手を萎縮させます。

本記事ではそんなときのNext Actionとして、「センス」という言葉を使わずに、お互いのセンスをより良くするためのコミュニケーション術を紹介しようと思います。

1. Whyの視野が狭いパターン

優秀なジュニアプロダクトマネージャーに多いのが、Whyの視野が狭いパターンです。サイモン・シネックの書籍『WHYから始めよ！』を読み、ゴールデンサークルを心に刻んでいて、そのアイデアがどうして良いと思ったの？と聞くと上手にそのWhyを答えてくれますが、Whyが1つしか無いとなかなか良いアイデアには至りません。

例えば、とあるECサイトで「登録後7日以内の購入率を10%上昇させる」というKRがあり、「10代女性にフォーカスしてクーポンを配る」というアイデアを出してくれたとします。そして、「どうして10代女性セグメントをターゲットにしますか？」と聞くと、「一番離脱率が高いセグメントだからです」ときちんとWhyを説明をすることができます。しかし、

「一番離脱率が高いセグメントは、そもそもターゲットユーザーではないのでは？」
「そもそもどうして、年齢性別でセグメントを切ったの？」
「なぜクーポンなの？リマインドメールなど低コストの施策は検討済み？」

と、もっと深くWhyを聞いていくと答えられなくなってしまいます。

Next Action

3案持ってきてもらう
Whyというのも複雑なものです。なぜユーザーにとって必要か？なぜそのユーザーか？なぜ私たちが？なぜ今？なぜそのWhat？＿＿。1つのWhyだけを考えているだけでは足りません。1つのWhyからWhatを考えられるようになったら、次は複数あるWhatから1つを意思決定できるようになることを目指しましょう。そのためには、複数のアイデアを持ってきてもらい、そのそれぞれのメリット・デメリットを説明してもらうトレーニングがおすすめです。

“センスが良い”自分の案を説明する
このような状況で「なぜそのアイデアが良いのか？なぜ？なぜ？」と問い詰めると相手を萎縮させてしまいます。私もよくやらかしてしまうのですが、相手を尊重して相手がそのアイデアを良いと思っている理由を突き止めたくて「なぜ？」をたくさん聞いてしまいます。

こういうときは、「例えばこうしたほうがXXの部分でよくないですか？」と代替案を出してしまったほうがコミュニケーションがこじれません。もし相手が考えきっていれば「XXではメリットがあるがYYの部分ではどうでしょうか。」と論点を上げてくれて、両者での比較軸をすり合わせる作業に移ることができます。

もし、相手がすぐに代替案を受け入れてしまう場合には、時間が必要です。本当は自分のアイデアの良さを語ることができるが、萎縮して語っていない場合。よりよい案を前に悔しい気持ちになって、より努力ができる場合。反対に自分の努力が否定されてすねてしまう場合。お互いの良さの定義が合わないときには、お互いに強い心で努力をする必要があり、その分普段よりも密なコミュニケーションが必要になります。

2. プロダクト開発の経験が乏しいパターン

「もしかして、AIって何でもできると思っていませんか？」と言いたくなるような夢物語のアイデアを見せられたことはありませんか。まだ顧客が一人もいないのに大規模なプラットフォームやマーケットプレイスを提案された経験、自分の考えている素晴らしい世界をつくりさえすれば大衆が勇んで使ってくれる前提での企画書を見せられた経験が、皆さんにもあるのではないでしょうか。「それはtoo muchかもしれませんね」と言っても「では、どこまでできるんですか？」と引き下がられると説明するのもめんどくさい！

Next Action

エンジニアなど、本人が不足する経験を持つメンターをつける
経験が乏しいのはどうしようもありません。やってみて失敗をするしかありません。しかし、本人だけの失敗で終わえられれば良いものの、事業会社としては、本人の失敗経験のために他の案件を差し置いて失敗が見えているプロジェクトを実施することはできませんし、こういった仕上がりの人は多くの場合結果が出る頃にはプロジェクトを抜けていて失敗と向き合う機会を得られていないことがあります。

そういった場合には、それがtoo muchであることを理解してもらうためにエンジニアのメンターについてもらって、その企画の工数が一番小さいMVPを考えてもらうと、良いサイズになることがあります。プロダクトマネージャーの仕事は、良い意思決定をすることです。それは一人で意思決定をするのではなく、エンジニアなど他職種をうまく巻き込んで決めていくことになり、そういった環境を整えることで次回以降もよりよい働きができるようになります。

センスが良い側は大歓迎して実行を検討してみる
実は、私にとって（too muchな提案をしてくる）彼らの感性は大変貴重です。AIがどういうつくりをしていて何ができるのか分かってしまっているので、もう私には突拍子もないアイデアを出すことはできなくなっています。そういったなんのバイアスも無い意見から学ぶことはたくさんあります。例えば5年後であれば実現できる可能性があるのか？もし目指す姿の一部としてあり得るなら、今のうちにどこでどんな手を打っておかなければいけないのか。そういった未来を考える機会として議論をする相手になってもらうと良い時間になりました。

3. カスタマージャーニーの詳細を理解できていないパターン

KPIダッシュボードをつくってもらって数字が見えるようになるのは嬉しいけれど…
どうして、月次で有料会員数を追っているの？週次で見ましょうよ。アクティブ率の定義はどうしてこうなの？開始率ではなくて完了率をみなければいけないんじゃない？などなど、一から十まで細かいところも全部確認して指摘しないとダッシュボードが使い物にならない！とお手上げ状態になることがあります。

Next Action

ユーザー10人に会ってもらう
「Product Senseは共感力と実行力だ」という言い方をする人もいますが、ユーザーに深い共感をして、自分にユーザーを憑依させてプロダクトをどのように使うのかの想像ができないと良い仕様を書くことができません。チームの中で細かい仕様についての意見が対立するときこそ、ユーザーに会ったほうがよいです。

解決策ではなく、まず分析をする
そして直感的に「それはおかしいだろう」と思って否定する側がユーザーのキャッチアップができていないことも往々にしてあります。これまで私たちは何度、絶対にユーザーが喜んでくれると信じて出した機能が「前のほうがよかった」と否定される経験をしたでしょうか？良いセンスを磨き上げて直感があることは素晴らしいことですが、直感頼りのプロダクト開発ではなく直感を後押しするリサーチを一緒に実施しましょう。

4. 事業構造の理解が足りていないパターン

ええ、わかります。確かにあなたの言う通り、画面の遷移は変えたほうが使いやすい。あなたが提案する機能を入れたほうがきっとユーザーは喜んでくれる。しかし、その改修で3ヶ月を使ったとして、その結果単価はあがるのか？LifeTimeは伸びるのか？解約率は下がるのか？それを考えると、今画面の大改修に手をいれる時期ではない！

Next Action

市場全体を理解してもらう
この場合に必要なのは俯瞰です。誰もユーザーを不幸にしようとはしていません。ユーザーを一番幸せにできるものに全体のリソースを使うべきであり、画面の順番が変わって使いやすくなることよりもっと幸せにできるアイデアが優先されます。必要最小限のリソースで少しだけ俯瞰するのは難しいので最初は極限まで俯瞰してみましょう。業界にはどんな企業があって、競合はどういう理由で購買されているでしょうか。自社のポジションはなにで、自社が買われている理由はなにか。そして、今提案しているアイデアは自社の買われる理由を補強するための最善の策でしょうか？小さな改善にとどまってしまう場合にはこういった全体を見る機会を一緒に持つことが有効かもしれません。

“センスが良い”側が説明をする
しかし、あなたがそのままUX改善のアイデアをリジェクトすると、プロダクトチームに「ユーザーをおろそかにしてカネばかり追いかける人」というレッテルを貼られます。自分が悪者になって全体がうまくいくならいいのですが、間違ったレッテルは今後のコミュニケーションを損ないます。もちろんユーザーをおろそかにするつもりはないこと、今ではないならロードマップ上のいつのタイミングで実施するのか、どうして今ではないのかを説明しましょう。

5. 大胆に動いていいという発想がないパターン

こういう会話がよくあります。

「ユーザーインタビューをしたいんですが、インタビュー募集メールを最近いろんな案件で送っているので2ヶ月待たなきゃいけないんです…」
「そのインタビューって本当にユーザーじゃないといけないんですか？初期ユーザーであればユーザーではない方でもいいのでは？全体メールが出せないなら営業に紹介してもらうとか？SNSで投稿している人を一本釣りするのは？自分の知り合いでも良いのでは？」
「そんなことしてもいいんですか！」

Next Action

引き出しを増やしに旅に出てもらう
人がモヤモヤしているとき、何にモヤモヤしているのか。それは解くべきIssueがわからないときと、一番良い解決策が見つからなくてあーでもない、こーでもないとしているときがあるようです。

現場での良い解決策の引き出しを増やすためには、会社の外に出るのが良いと思います。プロダクトマネジメント関連のコミュニティ（私は「プロダクト筋トレ」というコミュニティを主催しています）などにIssueを投げかけてみると他の方の解決策の実例を教えてもらうことができ、新しい施策を思いつくことができるようになります。また、事業づくりの歴史も長く、体系化された知識も多くあるので「これって名前付いてるのか！」だとか「悩んでることがまさに書いてある本を教えてもらえた！」というような体験もよくあります。

Issueと解決策を分ける
多くのプロダクトマネージャーと会って、つくづくIssueを定義する能力とその解決策をデザインする能力は別だなと思います。Issueを定義する能力に長けるが解決策に導く能力に欠ける人はどうしても成果物が目に見えないので評価されないことがあります。しかし、私はプロダクトマネージャーにとって本当に必要なスキルはIssueを定義する能力だと思います。Issueを定義することさえできれば、他のメンバーで解決策をつくり上げることもできます。

Issueと解決策を同時に説明されたとき、ついレビュワーとしては解決策をより良くするための話から始めてしまいますが、まずは「そのIssueの定義は素晴らしい」と伝えることを忘れてはいけないと思います。

「Product Sense」で検索すると、みんなセンスは身につけられるもので、生まれ持ったものではないと主張しています。そろばんを習えば暗算が得意になるように、きっとできるようになるのでしょう。しかし、例えばユーザーへの共感に時間がかかる人はプロダクトマネージャーより事業責任者に近いキャリアのほうが向いているだとか、逆にどうしても事業数値に苦手意識があるなら目標設定は誰かに任せてその実行側に軸足を置くだとか、全部が得意にならなくたっていいのではないかしら？とも思います。そして、一度それの優先度を下げたからといっても、また長いキャリアの中でいつの間にかできるようになっていることもあるのではないでしょうか。

そして、教える側にとっても、人と向き合い続けるにはエネルギーが必要です。お互いに疲れちゃうときには、あれもこれも伸ばそうとせずに得意な所に集中できるように役割分担を見直してみるのもいいかもしれません。