【PdM Days】DAY4①「魔法のような製品をいかにして生み出すか」
多彩な領域のプロダクトマネージャー（PdM）が集結し、プロダクトづくりに関する様々なセッションを発信するカンファレンス「PdM Days」。全体を通してのテーマは「枠を超えて、未来のまんなかへ」。セッションを通じて第一線で活躍するPdMの視点を獲得し、これまでの自分の枠を超えて未来に挑戦する。そのきっかけを提供し、日本のプロダクトづくりに貢献していきたいという思いが込められています。
今回は、2月17日に行われたオンライン講演「魔法のような製品をいかにして生み出すか」の模様をお届け。人々を熱狂させ、大きく伸びていくプロダクトを生み出すことはPdMにとって大きな目標の一つ。そんな魔法のような製品をつくるには、何が重要で、どのような取り組みをしていくべきなのか。これまで「YouTube」「Uber」「Figma」と、人々を熱狂させるプロダクトに携わり続けてきた山下祐樹氏（Figma, Inc.Chief Product Officer）にご講演いただきます。
※2024年2月17日開催の「PdM Days〜魔法のような製品をいかにして生み出すか」から、内容の一部を抜粋・編集しています。
「魔法のような体験」を届けることは、信じられないほど困難
Figmaの山下と申します。このPdM Daysはプロダクトマネージャー（以下、PdM）デザイナー、エンジニアの皆さんが、それぞれのプロダクト作りのスタンスや理想を共有する場と伺っています。今回、私もその一人として経験をシェアすることで、少しでも皆さんのプロダクト作りに役立てば幸いです。
私は日本にルーツを持ち、現在はアメリカで暮らしていますが、学生時代はシンガポールやマニラなど様々な都市で生活した経験があります。多彩な文化に触れることにより、さまざまな視点から物事を考える機会が与えられたと思っていて、この経験をデザイナーとしての仕事に活かすよう努めています。
キャリアにおいても「Microsoft」「YouTube」「Uber」「Figma」と複数の企業を経験してきました。共通点は、いずれも素晴らしいデザインカルチャーがあること。それは、企業として様々なビジネスプライオリティがあるなかで、あえて「超一流のユーザー体験」にこだわって投資してくれる点です。英語では、このようなユーザー体験を「magical experience（魔法のような体験）」と言います。
どの会社も「素晴らしい体験を届けたい」と口にしますが、実際にはこのような環境が整っていないのが現実です。魔法のような体験を届けることは、信じられないほど困難な戦いなのです。
それは、なぜなのか？ 現場では、次のような決まり文句に出くわします。
「これってKPIに影響する?」
「想定のスコープを超えます！」
「次のリリースでいいんじゃない?」
「後から改善していけばいい」
「それは本当にMVPに必要なのか」
「それは優先度を“低”に下げましょう」
これらはすべて、満点を取りに行くよりも「合格点でOK」という言葉に聞こえます。これでは魔法を作れませんよね。
実際、魔法のような体験は理屈からは生まれません。人々を驚かすような魔法をかけるには、いつも通りの考え方や成功体験を忘れて、新しい道を探る努力が必要です。それには相当なエネルギーや想像力が必要で、通常の組織であればギブアップしてしまうでしょう。魔法のような体験、プロダクトを作るために、どのようにして理屈を超えるのか。そのヒントやコツについて、私の経験からお話しします。
魔法のようなユーザー体験の構築を妨げる「OKRの罠」
ビジネスリーダーの皆様はよくご存知かと思いますが、プロダクト開発を行うときに OKR（Objective and Key Results）を掲げるのは非常に大事なことです。魔法のような体験への投資に納得してもらうには、どのようなOKRがふさわしいのでしょうか? 容易には思い浮かびませんよね。
それでもOKRを仮に作るとしたら、次のような手順を踏むかもしれません。
ロジカルに考えますと、素晴らしい体験の構築によりユーザーを満足させることができれば、さらにプロダクトを使ってもらえてユーザーと良い関係が保てるはずです。
その結果として利用回数の増加、YouTubeの場合は総再生時間の増加など、重要なビジネス指標が増大していきます。
この考え方には何の問題もありません。しかし、それをOKRに置き換えようとすると、2つの選択肢に集約されてしまいます。
選択肢の1つ目は「ユーザーの満足度」という部分にOKRを設定することです。 NPS（Net Promoter Score）、あるいは主要な機能の使用率を参照して顧客満足度を測定したいとします。こういった指標を取るとき、周りの人々はすぐに責め立ててきます。「NPSは、これを測定する最良の方法でしょうか？」「重要でない利用指標に基づいているのはなぜですか？」「NPSを動かすことでリテンションが動くことを実際に証明しましたか？」といった批判が出てくるのです。
では、ユーザーの満足度に基づいたOKRと正反対のアプローチはどうでしょう？ それが2つ目の選択肢「誰もが納得するビジネス指標」をOKRにする方法です。ただ、このような目標を掲げた場合、短期的に結果が出やすいプロジェクトを優先して取り組むことになりがちです。そのため、魔法のようなユーザー体験の構築が後回しになってしまいます。これが、いわゆるOKRの罠です。
私がFigmaに着任した際、次のようなチームOKRを目にしました。
「デザインシステムコンポーネントを挿入するユーザーの割合を増やす」
当時、チームはシンプルに、カスタマーフィードバックに呼応して開発を進めていました。それにも関わらず、OKRに基づこうとすると、このような中途半端な目標で後付けで正当化させようとしてしまいます。一見、正しく見えますが、チームの全員が積極的に考え、毎日の行動のモットーになるような指標では全くありませんでした。そして、このようなあまりにも視野の狭いOKRでは、チームの方向性、哲学などを確認することができませんよね。
ですから、私がFigmaに着任して最初にしたことはOKRの廃止でした。物議を醸すのは承知の上で、自分のチームで達成したいことを、ヘッドラインにして書くように言いました。
ヘッドラインとは、年末に振り返ったときに「何を達成したか」をチームで共有できるような内容です。これならチームの方向性や哲学について議論しやすくなります。ヘッドラインはそこまで精密に測定することはできませんが、大体の成績で評定すればいいのです。OKRを崇拝する人には多少不満かもしれませんが、実はスタートアップのようにスピードが求められる環境ではこのような目標の方がダイレクトで分かりやすいです。
プロダクトへの「愛」は測定できない。しかし、全てはそこから始まる
最近、私は友人のMadhuと話す機会がありました。彼はNotionやRobinhoodといった、素晴らしいデザインカルチャーを持つ企業で働いた経験があります。
Madhuは「素晴らしい体験を築くことが理にかなっている」ということを、どのようにデザイン・エンジニアを志向する理系人材に伝えるべきかを教えてくれました。
彼はまず、前提として全ての企業は成長を望んでいると言いました。そして、企業とそのプロダクトの利用を伸ばす重要な方法の一つは、すでにプロダクトを使っている人が「他の人にも利用を勧めること」であると。グロースの世界では、これはVirality K-factorと表現され、紹介、招待、連絡先のインポートといったものがあります。
プロダクトが人々の話題に上るために最も確実な方法は、素晴らしい体験を提供することだとMadhuは信じています。世界と共有したくなるような魔法の瞬間を届けるのだと。
例えば、Madhuが勤めていたRobinhoodでは、スクリーンショットがいかにソーシャルシェアされているかを重要視していました。みんなに魔法のような体験について話してもらう。そして、このユーザーの愛を通して広がり、成長していく。これが実際のプロダクト戦略です。
この話が全てのプロダクトに当てはまるとは言いません。他のグロースの手段として、たとえば「他社よりも安くプロダクトを提供する」というやり方もあるでしょう。ただ、さまざまな方法の中で、比較的手軽な手段として「素晴らしい体験の構築」を検討すべきですよね。
とはいえ、問題はそれの測定ができないことです。
そこでMadhuが提案したのは、彼が「LUV」と呼ぶ、この枠組みです。
つまり、「LOVE（愛）」「UTILITY（実用性）」「VALUE（価値）」です。先ほどの話とも似ていますが、この流れはとてもシンプルです。
・人々はあなたが作っているものを好きになります（LOVE）
・好きになると、より頻繁に使うようになります（UTILITY）
・すると、それに対価を払います（VALUE）
このうち、VALUEを測定するのは非常に簡単で、Revenueのような指標が典型です。また、UTILITYに関しても、週単位のアクティブな使用率、エンゲージメント指標などで簡単に測定することができます。
かし、LOVEだけは同じ精度で測定できません。Madhuの場合、Robinhoodではアプリストアのレビュー、スクリーンショットの共有、NPSなどを利用して、LOVEを大まかに測定していました。これらから分かるのは「ユーザーがどう満足しているか」という大まかなイメージです。彼らが満足していれば、何にそれを感じているのか。逆に不満であれば何が気に入らないのかといったことです。
それをABテストできるレベルまで測定することはできませんよね？ でも、測定できないから優先しないという考え方は間違っています。私たちは時に、指標のプレッシャーから解放される必要があるということです。
ここまでは、魔法のような体験を得られるプロダクトを作るために、目標がどうあるべきかについて話しました。では、実際に魔法をかけるにはどうすればいいのでしょうか?
理屈を超えた情熱を持つ
魔法をかける際に最も重要な材料の一つは「理屈を超えた情熱」を持つことです。
素晴らしいものを作るためには、チームに相当な時間と努力を求めなければなりません。ただ、メンバーを理屈で説得するのは難しく、理屈を超えた情熱を引き出す必要があります。
「典型的な理屈っぽいエンジニア」に対して、PdMが「このユーザー体験をもう少し磨き上げたい」と交渉するとします。彼らは反発し、どれだけ時間がかかるか主張し、その優先順位を下げるよう要求してくるでしょう。ただ、それがエンジニア発のアイデア、あるいは自身が推進したいものだった場合は、リソースに関する交渉はぐっと楽になるはずです。これが理屈と情熱の差なのです。
バグに対する態度も同じです。一般的に、バグを修正してもらおうとする場合、エンジニアは何人のユーザーが影響を受けたのか、確実な数字を求めます。そのデータに基づいて修正すべきバグの優先順位を決めるのは、最も合理的な考え方です。
しかし、実際にそのバグを目撃したエンジニアは、そうしたデータに関係なく、一目散に修正したがります。
こんな話もあります。あなたがデザイナーで、何週間も解決策を模索したものの、完璧ではない2つの案しか思いつかなかったとします。そこで合理的なデザイナーはトレードオフの議論を進め、欠点のある2つの選択肢から選ぼうとします。
対して、理屈を超えた情熱を持つデザイナーは、「もっといい方法があるはずだ」と主張するでしょう。「良いもの」と「素晴らしいもの」の違いを生み出すのは、こうしたプライドです。
これを養うための魔法の公式はありません。自分の中でやる気を見つける必要があります。あるいは、やる気のある人を見つけなければなりません。
Uberでは「友人や家族に見せたい」という理由でプロジェクトに愛情を注ぐエンジニアを見つけるように心がけていました。また、Figmaのデザイナーたちは、ユーザーであるデザイナー仲間の体験を「できるだけ素晴らしいもの」にすることに対し、各々が責任を感じています。
たとえば、Figmaのデザイナー Marcinは、タイプグラフィーとキーボードに対して情熱を注いでいます。その情熱はキーボードに関する本を出版するほどのものでした。彼の理屈を超えた情熱は「バリアブルタイプ」を例とする魔法のような体験を生み出し、この機能を実現するために、デザイナーにも関わらず自らコードまで書いてしまいました。
いつものルーティンを作らない
魔法をかけるために必要な2つ目の材料は「いつものルーティンを作らない」ことです。
以前、私がUberの配車アプリのリデザインに取り組んでいた時に、CEOのTravisから進捗を尋ねられました。そこで、「様々なステークホルダーに意見を聞くためのミーティングに時間を費やしている」と伝えたところ、Travisは「それは時間がかかりすぎる。最大7人を選び、オフィスではない場所で仕事をするように」と命じました。そして、「デザインが出来上がるまでは戻ってこないように」と言ったんです。
Travisは毎日のミーティングや大企業的な進捗管理が、チームがクリエイティブに集中するだけの十分な余裕を与えてくれないことを見抜いていました。
こうした彼の見立ては正しかったようです。再構築された配車アプリに実装された、いくつかの魔法のような体験は、この劇的な作業環境のリデザインによって生まれました。
Figmaでも同じようなことが起こりました。私たちは『FigJam』をリリースする数ヶ月前に、現在のプロダクトを取締役会で見せました。その際、『FigJam』の差別化要因は何か？という質問に対し、CEOのDylanは「『FigJam』は楽しくあるべきだ」と発言しました。彼は、現在出回っている仕事場で使うツールはちっとも楽しくないと考えていて、取締役会のフィードバックで「『FigJam』はこれまでより、もっと楽しくなるはずだ」という見解を述べたのです。
Dylanはチームに対し、圧倒的な存在になるためには、この点にもっと注力する必要があると伝えました。リリースまで2ヶ月しかありませんでしたが、「FigJam」のデザイナーとPdMを担当していたジェニーとエミリーはこの指示を受け、デザインチーム全体の大規模なスプリントを組織し、それを「FigJam FunJam」と名付けました。
このチームは楽しく、革新的なアイデアをたくさん考案しました。現在の「FigJam」のユニークで楽しい機能はここから生まれたのです。たとえば、感情を表すリアクション機能、顔のスタンプ、ハイタッチ、カーソルチャットなどです。
もし、いつものルーティーンにこだわっていたら、チームは残ったバグやタスクを全て片付け、リリースが近づくにつれてプロダクトを安定させることにリソースを費やしていたでしょう。リリース直前に優先順位を変えたり、新たに楽しい機能を思いついたりすることもなかったでしょう。つまり、「FigJam」の魔法の多くは失われていたということです。魔法を生み出すには、時にはペースや環境を変えたり、いつもと違う方法を取ったりすることが必要なのです。
魔法のような体験は普通のやり方では生まれません。魔法の創造を動機づけるには、人々の理屈を超えた情熱を引き出す必要があるのです。そして、通常のルーティーンを変更することで惰性から逃れ、魔法をかけるための余裕を与えなければなりません。これこそ、私が日々の仕事で心がけていることです。
私のセッションが皆さんの情熱に少しでも火を灯して、魔法のようなプロダクトが生み出されることを心より願っています。本日はありがとうございました。
お知らせ｜プロデザ室は仲間を募集しています
プロダクトデザイン室の募集情報は〈こちら〉のサイトからご確認いただけます。ぜひご一読ください☆
https://blog.recruit-productdesign.jp/
お願い｜noteのフォローをお願いします！
こちらのnoteアカウントをまだフォローしていない方！ぜひフォローしてくださいね。皆さんのキャリアやお仕事に役立つ記事を発信していますので、絶対損させませんよ！！！
お願い｜できれば公式X（旧twitter）もフォローをお願いします
プロダクトデザイン室の公式X（旧twitter）ではイベントの見どころやオリジナルコンテンツを更新しています。ぜひフォローしてください。
https://twitter.com/Recruit_PD_PR