
2025.02.18
AIが「嘘のデータ」を返してしまう アルペンが生成AI導入で味わった失敗と、その教訓
プロダクトの理想と現実はなぜ乖離しがち?プロダクト作りに潜む問題を考える(全1記事)
リンクをコピー
記事をブックマーク
すずけん氏(以下、すずけん):簡単に自己紹介します。鈴木健太郎といいます。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とか、開発チームのメンバーとして大事なこととしては、希望リリース日の必然性を早めに握っておいたほうがいいという感じです。
リリース予定日を「対外公表したい」「対外公表するぞ」みたいになっても、「いや、なんでしなきゃいけないんですか」と、極力内部にとどめておく。あとは、リリース予定日に出せないと何が起こるのかをちゃんと確認しておく。
あとはリリース予定日が変えられないという条件があるなら、ちゃんと実装要件を減らせないかなどを事前に調整しておく。確認を極力早め早めにやっておくことが、怪物を生み出さないため、「こんなはずじゃなかった……」を生み出さないために大事なんじゃないかなと思っています。
最後にまとめです。今回の3つに関して、それぞれ問題だったり解決策みたいなものを出しました。これだけがすべて正解じゃないとは思いますが、ある解決策のケースとして(出したもの)です。
プロダクトマネージャーは、顧客重視みたいなことも当然言われますが、開発者、ビジネスの要件を汲んだり、ちゃんとここで説明しないといいものが作れなかったり、バランスが取れないものになってしまったりすることはあるので、開発者、ビジネスの各部門とも正しく連携を取って、「どうしてこうなった……」(というよう)なプロダクトが世の中から少しでも減ることを祈願していますという感じで締めたいと思いまーす。ありがとうございました。
関連タグ:
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
第20回エクゼクティブメンターイベント「今、「ひと」と組織が共創する〜働き方の未来へ」
2024.12.07 - 2024.12.07