今日は、「イシューの見極め方」について、話したいと思います。

こちらの記事がとても好評で、いいねが増え、ビューが自分の記事の中でダントツ1位になりました。

なので、今日はその続きとして、チームとしては、イシューの洗い出しを上記の記事で行い、活動を進めるという話をしましたが、マネージャーとして、メンバーには言わないイシューのの見極め方

をお話ししたいと思います。

なぜ、メンバーに言わない部分があるかというと、マネジメントにおいて具体的な指示をするマネジメントはあまり良くないと考えているからです。その詳細は、以下の記事を参考にいただけると、と思います

メンバーには言わずに、外側から本質的なイシューへ解決を促すのがマネージャーの役割だと思っています。
で、今日はマネージャーとしてどのイシューに優先的に手をつけるべきだと思っておけば良いか？の見極める観点をお話ししたいと思います。

1.アウトプットにインパクトがあるか？

アウトプットのインパクトの例でいうと、まず１つ目が、実施した時の効果が高いものがあります。この機能を入れると売上が30%上がります、とか、リピート率が10%上がりますとか、開発効率が50%向上しますとかとか。実際に試算ができ、効果が高いものは、イシュー度が高いと言えます。

まあ、このような試算ができるものは、当たり前の話で、皆さん普通にやっていると思います。ただ、現実の現場の話で言えば、試算ができないものの方が多いのではないでしょうか？

なので、一つレベルが上のイシューの見極め方としては、「仮説」を立てることです。「仮説」を立てることで、わかることがあります。それは、暗黙の前提としている常識です。

ひとつ前の前提としている常識で言えば、「物はみんなできるだけ高く売りたい」「ウイスキーはロックで飲むもので、味の濃さが大事」「携帯にはたくさん機能があった方が良く、機能勝負」「車にはカーナビが必須」などです。

ものづくりをする上で、このような常識はないでしょうか？若い方はわからないかもしれないですが、昔は上記前提がありました。ただ、今の令和時代はどうでしょうか？

• 「物はみんなできるだけ高く売りたい」→ヤフオクではなく、メルカリを使う

• 「ウイスキーはロックで飲むもので、味の濃さが大事」→ウイスキーは炭酸で割って、ハイボールで飲む物。薄めの角が韓国などで人気

• 「携帯にはたくさん機能があった方が良く、機能勝負」→日本の機能満載のガラケーはなくなり、シンプルなiPhone主流

• 「車にはカーナビが必須」→カーナビは必要なく、スマホのアプリで道案内

というようになっていないでしょうか？ものづくりにおいて、このような常識のにとらわれて、物を作っていても、ユーザーが真に求める物は、作ることができません。

「常識が否定されるもの」これが一番インパクトがあり。世の中に求められているものになります。

話が少しそれましたが、この無意識の常識というのを気づく手段として、「仮説」を立てるという作業があります。

なぜ、自分達はこの機能を導入するのか？を深く考えることが大事で、それを「言語化」することが大事です。まず、「言語化」できないということは、頭の中で考えがまとまっていないということになります。この「言語化」ができていない時というのは=考えが緩い状態の証明になります。

例えば、
「ユーザーは、アプリを導入したときの設定が複雑で、離脱しているからチュートリアルを入れて、設定をわかりやすくしたい」
と考えたとします。そして、導入してみて、よくあるのが結果、チュートリアルが長すぎて、途中で離脱が増えている。という状況です。

では、ここで暗黙の前提としている常識はどこでしょうか？

• 設定が複雑でユーザーが離脱している

• チュートリアルでユーザーは学習する

本当にユーザーはチュートリアルを理解できるでしょうか？真に取り組むべきは、設定の複雑さの解消ではないでしょうか？デフォルト設定でいかに定着をしてもらうか？WEBからアプリへ誘導したのであれば、アプリでのメリットを明確に伝え、そこまでの道を最短にするなど、取れるアプローチというのが他にもあることがわかります。

そして、一番怖いのが、「チュートリアルでユーザーは学習する」という前提です。どうでしょうか？この前提が崩れたとき、取り組みの崩壊が見えないでしょうか？

というので、本当に「ユーザーはチュートリアルで学習をするのか？」の問いに対して、ペーパープロトタイプなどでしっかり検証をした方が良いというのがわかります。

このように、仮説を立てることで、自分達が何を「前提」としておいているか？がわかり、その「前提」が崩れたらやばいものから調査などの活動をするのが、マネージャーとして、チームを最短で成功に導く秘訣になります。

そのため、「仮説」を自分の中で「言語化」して立てて、アウトプットにインパクトがあるか？を自分の中で確認しておくと良いでしょう。そして、されにその仮説の中に、これまでの暗黙の常識を確認して置けると、よりインパクトが強い仮説を生み出すことができます。

2.説得力があるか？受け手に十分に伝えれるか？

「仮説」には、もう１つ使い所があります。それは、この仮説の話をした時に、説得力があり、受け手に十分伝わるか？ということです。受け手に十分伝わるというのは、Fαctを用いて説明ができるということです。

例えば、チュートリアルが分かりづらいということを言っても、人によっては、特に分かりづらいということはないということもあると思います。プロダクトを作って、その世界しか見ていないと、中の人の感覚というのはだんだん鈍化していきます。それは、毎日見ていたり、考えたりしているので仕方がないことです。

でも、何も前提を知らない人がみると、操作方法が全然わからないってことはよくあると思います。それを「チュートリアルが分かりづらい」から変えましょうと言っても、やっぱり伝わらないことが多いと思います。

なので、Fαctを用いて説明ができることが大事です。「チュートリアルが分かりづらい」の場合、どのように説明すればよいか？というと

• 新規ユーザーの50%はチュートリアルの途中でログがなくなり離脱している

• ユーザービリティ調査をして、最後まで辿り着けたのは10人中3人だった

というように、調査をしてFactを作って、説明をする必要があります。実際に世の中にリリースしているものであれば、ログを使うのが早いですし、プロトタイプの状態であれば、定性調査をするというのが証明する方法になります。

(以下、調査スキルを身につけるために参考になる記事も書いてます)

プロダクトマネージャーであれば、スペシャリストでなくても、ある程度調査スキルをに見つけておくというのは、このように人をFactを用いて説得できるようになるので、必要なスキルと考えて良いでしょう。

調査系のスキルについては、YK_DATAのnoteで、不定期に記事にしているので、よかったらフォローしてもらえると嬉しいです。

3.これをそのままメンバーには言いません

最後に、マネージャーとしてこの記事を見ている人向けにお話しするマネジメントのポイントですが、上記の仮説や調査を伝えて、そのままメンバーに実行してもらっても、おそらくうまくいきません。

なぜなら、仮説の検証というのは、自分で仮説を立てて、検証するから面白いのであって、人が言われた物をやっても、取り組みのクオリティが上がりません。メンバーに仮説を立てて、一緒にメンバーの考えに寄り添って、その検証をするというのが一番効果的です。

まとめ

この記事が誰かの参考になれば幸いです。
インスタグラムもしておりますので、フォローよろしくお願いします