すずけん氏（以下、すずけん）：簡単に自己紹介します。鈴木健太郎といいます。Twitterは「すずけん」という名前でやっています。39歳です。新卒はWebディレクターからスタートして、今はTimersという会社でLead Product Managerを務めています。（スライドを示して）このあたりが会社の遍歴です。
私の担当している運営サービスを簡単に紹介します。Timersでは「Famm」という子育て家族向けのサービスを運営しています。写真の共有や撮影会、ママ向けのキャリアスクールや出張撮影などをやっています。（スライドを示して）私はこの左上の家族向けの写真共有や、動画共有のサービスを運営しています。
プロダクトの理想と現実の乖離
ということで自己紹介は終わりにして、今日お話ししたいことに移ります。
先ほどお話ししたとおり、私はTwitterでPM向けの話や体験記みたいなものを語ったりしています。（スライドを示して）1ヶ月か2ヶ月前ぐらいにこんな画像を投稿したら、いいねを5,000近くと1,000リツイートぐらいいただいて。「わかる、この状況」みたいに、けっこうみなさんに共感いただいた画像です。
これは、海外のPMのコミュニティに投稿されていた画像で、それがおもしろかったので日本語に訳して共有したらバズッたという感じです。しかも、「わかるわかる」「あるある」みたいな感じで共感を得られた画像だったので、やはりみんなこういう問題に遭遇しているんだろうなと。
今日はこの問題について、10分LTで全部は話しきれないので、3つに絞って、「なんでこんな問題が起きちゃうのか」「こんな解決策があるんじゃないか」というのを、Tips的に紹介しようかなと思っています。
開発者の解像度が低くなってしまう問題と対策法
ではまず1つ目です。開発者の理解（解像度）がなぜか低くなってしまう問題。先ほどの『モナ・リザ』のMVPやプロダクトゴールでは解像度が高かったのに、開発者に渡ると急に解像度が低くなってしまう問題。なんでだろう。
1つの問題のケースという感じですが、「プロダクトの提供価値が説明しきれていなくないですか」ということを、まずプロダクトマネージャーの方とかには言いたいなという感じです。
開発メンバーに対してキックオフとかプロジェクト説明をする時に、「こんな機能を開発してください」「この機能はこんなので」みたいな感じの説明を終始していて、「そもそもプロダクトのどんな課題を解決したいんだっけ」とか、「こういう価値を提供したいんです」というところが説明できていないケースがあります。
開発メンバー的には、渡されたり合意した機能仕様書どおりにそのまま開発して「これでいっか」みたいな状況に陥ってしまうので、「結局何作るんだ、これ」「ゴールはなんだ？」みたいな、解像度が低い問題の状況になっちゃうんじゃないかと考えられます。
解決例として「こんなやり方が1例としてあるよ」という提案です。開発内容のWhyとWhatの部分はちゃんと説明する。説明することはみんなやっているかもしれませんが、共感してもらうことがすごく大事なんじゃないかなと。
例えばリーンキャンバスとかバリュープロポジションキャンバスみたいな、ワークショップのようなかたちでユーザー価値とか顧客価値の考えを作ることを時間を取って一緒にやってみたり、見てもらったりするとか。
あとは、顧客ターゲットになり得る人のユーザーインタビューに同席してもらったり、今の時代だと動画を録画して一緒に見るのもいいんじゃないかなと思っています。
プロダクトの提供価値の解像度をちゃんと高めて、それを機能に落とし込んでいくアプローチを取れば、開発者の理解は上がるのかなと考えています。
営業が売りたいものが想定外過ぎる問題と対策法
では2つ目。営業が売りたいものが想定外過ぎる問題です。先ほどの『モナ・リザ』に比べてポップ過ぎるだろう（笑）ということが、なぜ発生してしまうかという問題を紐解きたいと思います。
たぶんいろいろあると思います。敵対するのは簡単ですが、営業チームの事情をちゃんと理解して、物事を話したりだとか、「なんでこんな提案が来たんだろう」ということを理解するほうがいいんじゃないかという感じです。
なので、例えばシックな『モナ・リザ』の絵に対して、なぜ営業が「ポップなほうがいいんじゃないですか」みたいな提案をし出すのか、その背景を知っていますか？ と。それを理解しないと、やはりなかなか折り合いがつかないですよね。そもそも担当の営業が追っている目標をちゃんと知らないと、こう言い出す理由や背景もやはり理解できないです。
または、営業の人がこのプロダクトを見た時、そしてプレゼンした時に、対面する顧客がどんな反応を示すかがきちんと想像できていないと、ファーストインパクト重視なものを提案されて、「それを受け入れないとやってもらえないのかな」みたいになるという感じです。
こちらの話をするのも大事とは思っていますが、一方で、同じ会社内の営業の事情をちゃんと理解してみるのも解決策の1つとしてあるんじゃないかなと。
例えば「（営業チームの）部署目標ってなんでしたっけ」みたいなところだったり、あとは営業の席に機会があるんだったら、ちゃんと同席させてもらうのも1つ解像度を高めるためだったり、余計な機能を作らないための正しいアプローチの1つなんじゃないかなと思っています。
リリース内容が理想からかけ離れている問題と対策法
では最後。これが一番悲惨なケースです。『モナ・リザ』を作るつもりが、とんでもない怪物を生み出してしまう。リリース内容が理想からかけ離れている問題です。なぜ起きてしまうのかという感じですが、2つの問題を提案します。
1つが、各所からの要望に優先順位がつけられていないという話です。PMみたいな人には、優先順位をつけるとか、意思決定を求められたりします。しかし、意思決定できないケースというのもけっこうあると思っています。そういう人がPMをなんとなくやったり要望を受け入れまくったりすると、当然開発チームは疲弊し混乱して、間に合わない、ぐちゃぐちゃなものを作るしかないような状況になるかなと思っています。
なので、PMが「その要望に対応しないと本当に問題が起こりますか」ということを、ちゃんと突き詰めて考えることは、非常に大事なんじゃないかなと思います。そうしないと、優先順位がつけられない。「誰がプロダクトの最終意思決定者なのか」をはっきりさせるのが1つ、解決案としてあるかなと思っています。
例えば「PMの人が意思決定者です」みたいな立ち位置になっていたはずが、「いや実は社長がああ言っていまして」とか、「ナニナニ部長がこう言っていまして」みたいなケースに飲まれたりする場合があるなら、もうその人を表に引きずり出して「意思決定をしてください」みたいに促すのもPdMの仕事なんじゃないかなと思っています。
別に自分だけで意思決定しなくてよいという感じですね。ただし、整合性を取る必要はあると思うので、そこはPdMの仕事かなと思っています。
あとは複数部署から要望がきて、「どの要望や部署の優先度が高いのかわからーん」みたいなのがあったら、まず各部署に優先度整理をしてもらうというアプローチもあるんじゃないかなという感じですね。
あとは、プロダクトゴールに合っていない要望、整合性の取れていない要望は、「No」をちゃんと説明することです。シンプルな機能を売りにしているのに「なんかたくさん機能を付けたい」みたいな話があったら、それは「No」を説明すべきかなと思っています。
あともう1つは、なぜかリリース予定日が品質や顧客の期待より優先になってしまう問題です。これは、リリース日が近づけば近づくほど盲目的になってしまうかなと。
間に合わないものを期限までに作ろうとしている。そして「もしかしたらなんとかなるかもしれない」「なんとかなるだろう」と思って、結局なんともならないで、ひどい怪物を生み出してしまうケースはけっこうあるんじゃないかなと。その時にPMとか、開発チームのメンバーとして大事なこととしては、希望リリース日の必然性を早めに握っておいたほうがいいという感じです。
リリース予定日を「対外公表したい」「対外公表するぞ」みたいになっても、「いや、なんでしなきゃいけないんですか」と、極力内部にとどめておく。あとは、リリース予定日に出せないと何が起こるのかをちゃんと確認しておく。
あとはリリース予定日が変えられないという条件があるなら、ちゃんと実装要件を減らせないかなどを事前に調整しておく。確認を極力早め早めにやっておくことが、怪物を生み出さないため、「こんなはずじゃなかった……」を生み出さないために大事なんじゃないかなと思っています。
PdMは開発者、ビジネスの各部門との連携も必要
最後にまとめです。今回の3つに関して、それぞれ問題だったり解決策みたいなものを出しました。これだけがすべて正解じゃないとは思いますが、ある解決策のケースとして（出したもの）です。
プロダクトマネージャーは、顧客重視みたいなことも当然言われますが、開発者、ビジネスの要件を汲んだり、ちゃんとここで説明しないといいものが作れなかったり、バランスが取れないものになってしまったりすることはあるので、開発者、ビジネスの各部門とも正しく連携を取って、「どうしてこうなった……」（というよう）なプロダクトが世の中から少しでも減ることを祈願していますという感じで締めたいと思いまーす。ありがとうございました。
