【イベントレポート】元マイクロソフトの萩原氏が語る ―VUCAの時代でも永く愛されるプロダクト開発・デザインの考え方とは―
23,000名(※2023年10月末時点)のプロの経験・知見を複数の企業でシェアし、経営課題を解決するプロシェアリングサービスを運営する当社では、毎月10回程度のウェビナーを開催しております。
2022/09/15回では、ビジネスサイドと開発サイドのコミュニケーションがうまくいかずプロダクト開発が進まないとお悩みの新規事業責任者・経営企画責任者の皆様に向けて、元マイクロソフトでSaaS成長支援コンサルティングのプロ
萩原氏に、プロダクトづくりのメソッドについて教えていただきました。
「新規事業を推進する上で、ビジネスサイドと開発サイドのコミュニケーションがうまくいかない」
「プロダクトの価値を設定しきれない」
こうしたお悩みを持つご担当者様はぜひご覧ください。
萩原 雅裕氏
Prodotto合同会社 代表
NTTデータ、ベイン・アンド・カンパニー、日本マイクロソフト、米マイクロソフトコーポレーションを経て、創業期のワークスモバイルジャパン株式会社に参画し、「LINE WORKS」の立ち上げ・成長に携わる。4年連続市場シェアNo.1、導入社数30万社超、ARR78億円（2021年現在）までの成長に貢献。プロダクト責任者、マーケティング責任者、カスタマーサクセス責任者、戦略担当役員などを歴任。現在はProdotto代表としてSaaS成長支援コンサルティングを提供。
佐々木 博明
プロシェアリング本部 エンタープライズ推進チーム マネジャー
ディー・エヌ・エー、リクルート、ビズリーチにてWebマーケティングや新規事業立ち上げなど幅広く担当。その後、PERSOL INNOVATION FUND合同会社でHRTech企業への投資案件やM&A業務に従事。サーキュレーション入社後は大手企業様へのDXや新規事業の支援に従事。製造業・流通業・通信など幅広い業界に対して、DX推進に必要なマーケティング・セールス・ECの戦略立案、業務・システム改革、組織改革などのコンサルティング実績を持つ。
山中 かれん
イベント企画・記事編集
新卒で大手人材紹介会社に入社し、IT・コンサル業界の中途採用における課題解決に従事。ベンチャー中小企業から大手外資系企業まで幅広い採用支援を経験後、社内組織営業力向上に向けた研修立案、商品企画に携わる。サーキュレーションではプロ人材の経験知見のアセスメント業務とオンラインイベントの企画〜運営を推進。
※プロフィール情報は2022/09/15時点のものになります。
Contents
価値観の多様化に対応するにはユーザーの声を拾うことが重要
VUCAの時代が到来し社会的にさまざまな変化が起きている中、プロダクトを取り巻く世界でも価値観の多様化が進んでいる。従来はモノを所有していたところから現在はサブスクリプション型などを通して「利用」する形態が普及し、さらに「体験」を軸にした新しい楽しみ方に起点が置かれつつある。
ユーザー体験を重視したプロダクト開発を実施しようとする際は、ついユーザーの行動データを参照しがちだ。しかし行動データは普遍的ではある一方、ユーザー自身の意見やインサイトが見えづらくなる。より良い開発アイデアでVUCA時代でも永く愛されるプロダクトを生み出すなら、ユーザーフィードバックやユーザーインタビューにより重点を置くべきだと考えられる。
プロダクト開発にありがちな状況3選
「ユーザーの声を拾う」というのは、当たり前のようで難易度が高い。今回はまず、プロダクトづくりでありがちな状況を3つ挙げ、その中から開発のヒントをつかむところからスタートした。
1.開発の自社都合開発
第一にありがちなのが、顧客ニーズよりも企業側の都合を優先させたプロダクトアウト型の開発をしてしまうケースだ。冒頭で述べたようなユーザーのニーズやターゲットの実態、インサイトを理解しないまま自社都合で開発を進めてしまうため、最終的に「使われない機能」が完成してしまう。
これを踏まえ、元マイクロソフトの萩原氏が顧客の実態を把握するために工夫していることについて伺った。
萩原：シンプルに顧客のところへ行くことです。例えばサラリーマンが働いているようなオフィスと店舗のスタッフが働く職場では、環境が全く違います。店舗にデスクはありませんし、パソコン画面は小さくて、普段は仕舞ってあります。この状況下で、自分たちが作ろうとしているプロダクトはどういう風に受け入れられるのか、どこをアジャストすればいいのか、わかることがたくさんあります。
さらに言うなら、エンドユーザーを見ましょう。プロダクトをプランしているときは市場や購入の意思決定者を意識してしまいますが、最終的に利用するエンドユーザーについて考えなければ、製品は受け入れてもらえません。
2.営業の顧客意見鵜呑み
佐々木：今のお話に関連して、営業サイドが顧客の意見を聞いてあれこれやってほしいと開発サイドに言うケースもあるかと思いました。そのときに適切な開発スコープが必要だと思うのですが、営業側はどのようなフィードバックを渡すべきなのでしょうか。
萩原：営業が「顧客はこういう機能があったら買うと言っている」という話はよくあるのですが、開発サイドからすると「本当か？」と疑問に思うことはありますよね。そのときに必要なのは、顧客がどんな事業をやっていてどんな仕事のスタイルで働いていて、何かを導入するときにどういうところを気にするのかなど、顧客の要望の背景を丁寧に共有する姿勢です。背景があるからこそ、意思決定のポイントが生まれているはずですからね。
3.CSの視野狭窄的アプローチ
営業と同様にCSサイドからも顧客の要望は上がってくるが、CSはあくまで担当顧客の話をするため、必ずしも要望の優先順位が高いとは限らない。開発サイドからしてみると、全ての機能開発を行うわけにもいかない事情もある。本来、有益であるはずのCSからの情報を有効活用するには、どのようなアプローチをすると良いのだろうか。
萩原：CSとして顧客と向き合うと相手を成功させることに集中してしまいがちですが、顧客の意見がプロダクトにとってどういう位置づけになるのか、同じ事象が別のケースでも起こり得るのかなどの要素を整理して、開発サイドに伝えましょう。プロダクトが進化した結果、似たようなケースが起きたときに対応可能になればハッピーです。
ビジネスサイドと開発サイドとの共創事例
ここまでの話を見てもわかる通り、プロダクト開発やデザインはもちろん改善プロセスにおいても、ビジネスサイドと開発サイドの共創は必須だ。
プロダクトづくりの手順は開発、リリース、グロースの3つのフェーズに分けて考えられるが、「共創」の観点ではどのような課題があるのか、解決のポイントともに伺っていった。
［Case.1］開発／前提を共有する
佐々木：萩原さんはこれまでさまざまなプロダクト開発に携わってきたからこそ、開発段階で前提を共有する難しさを感じていると伺っています。このあたりにはどのようなポイントがあるのでしょうか？
萩原：いろいろな企業をご支援する中で感じるのは、プロダクトオーナーや創業者の方たちが、非常に強い原体験を持っていることです。「こんな不便をこうしたら解決した」という、トピックに対する強いパッションがあるわけですね。その人たちが見えている範囲や深さは、一般の人よりもはるかに広くて深い。その場合、開発をする前に「普通の人のリアリティ」とすり合わせて、提供する内容を削ぎ落としていかなければなりません。あれもこれもと作っても、ユーザーにとってはまだそんなに必要ない状態だからです。
ターゲット顧客はどういう状態で、そのトピックに対してどれぐらいの成熟度を持ち、これまでどの程度試行錯誤をしてきたのか。こうした市場調査からは測れない状況を言語化して共有し、共通認識を持つ必要があります。
［Case.2］リリース／誰に何が刺さったのかを理解する
佐々木：共通言語を持って開発し、ターゲットとなる顧客に向けて商品をリリースするわけですが、会社によって利用状況の多寡が生まれるというのはよくあるケースだと思います。リリース後の機能強化や機能追加については、どういう観点で判断をすると良いのでしょうか。
萩原：これも現場に行くのが一番速いですね。大きな契約をしてくれた顧客に目が行きがちになりますが、大手企業は徐々にしかプロダクトを使いません。一方で小規模な顧客はガンガン使っているので、多くのフィードバックが得られます。どうしてそのプロダクトがハマったのか、そもそもどうやって知ったのかなどを聞いてみると、意外なポイントが見えてくることも多いです。
これはリリースしてみて初めてわかる部分です。次からは特定できたポイントを強めに打ち出していけば、よりリアルに顧客にアジャストできると思います。
［Case.3］グロース／プロダクトを再定義する
佐々木：次のフェーズはすごく難しいですね。いざ売上を伸ばしていこうと思ったときになぜか売れない、という話はゼロではありません。このときプロダクトの再定義が必要になるケースもありますが、どのようなやり方、考え方をすればいいのでしょうか。
萩原：自分たちの強みが急に通用しなくなる背景には、いわゆるアーリーアダプターからアーリーマジョリティへの移行があると言われます。同じ製品カテゴリでも、熱量を持って自分で工夫をしながら先行で使ってくれていた人と、「とにかく買ったらすぐ使える」機能を求めている人とでは、全くニーズが異なります。
そうなると訴求ポイントが全く変わりますし、マーケティングやインサイドセールス、フィールドセールスでどんなトークをすればいいのかなども考慮しなければなりません。そこを乗り越えると、本当にグロースしていけると感じますね。
プロダクトの価値を最大化する推進メソッド
次に、具体的にプロダクトの価値を最大化するための推進メソッドについても教えていただいた。開発、リリース、グロース時のどの段階においても変わらず活用できるため、ぜひ押さえておきたい。
ユースケースを把握/整理
最初に重要なのが、ユースケースを把握・整理することだ。大前提として、自ら現場に足を運び、非言語情報も得る必要がある。
萩原：エンドユーザーを間近に見ると、例えば「導入推進者が実はすごく現場に気を遣っている」といったパワーバランスも見えてきます。そういった目に見えない部分の理解を深めると、プロダクトにも反映できますね。
佐々木：スライドのポイント2にある「5つの要素を押さえる」とはどういう意味ですか？
萩原：フォーマットというほどでもありませんが、インサイトが得られる5つの要素のことです。すなわち、「どんな社員が」「どんな業務をしていて」「どの機能を」「どう適用・活用し」「どんな成果や価値を得ているのか」です。
これらを深掘りすると、顧客自身も気付いていなかったプロダクトの良さや価値が見えてきます。
キー・シナリオを特定
佐々木：ユースケースを把握・整理できたら、今度はキー・シナリオを作っていくことになります。シナリオ作成のポイントについて、ヒントを教えていただけますか？
萩原：スライドのポイント1が一番大事です。最初に立てる事業計画はあくまで想定ですが、ユースケースで顧客にヒアリングすると、想定と違う部分も含めて実態がわかってきます。これを踏まえて、顧客がどこに価値を感じてくれたのか、どんなことを言っていたのか、導入目的は何だったのかなどを大きく分類、整理しましょう。多くても3つのユースケースとしてまとめられると、複数の部署間でプロダクトが目指すべき方向を認識しやすくなります。
佐々木：ユースケースを取ってきたらマッピングして、仮説通りかどうかを見るということですね。
GMT戦略を実行
佐々木：ユーザーもシナリオも決まった後は、GTM（Go-to-Market）戦略を実行すると思います。個人的にはスライドにあるポイント1の「一気通貫のGTM戦略を立てる」が重要だと思うのですが、どんなことをするのでしょうか。
萩原：これは失敗談なのですが、各部署が役割分担をしてビジネスを進めるうちに、それぞれ違う範囲をカバーしようという話になりがちなんですね。しかし各部門が同じ方向を見て力を集結しないと、GTMは上手くいきません。そのためのツールがキー・シナリオです。キー・シナリオを通じて同じ絵を見ていると、成果も出やすくなりますね。
プロダクトフィードバック
佐々木：プロダクトフィードバックは、主に開発リソースの話につながるのかなと思っています。ここも基本的にキー・シナリオで会話をすればいいのでしょうか？
萩原：そうですね。開発リソースは有限なので振り分けに悩む上、エンジニアはどちらかというと新機能を作りたくなるものです。しかしキー・シナリオを見て顧客が新機能よりも機能改善を求めていると認識できれば、優先順位付けができるようになります。ビジネス・開発サイドが「自分たちが今何に注力しているのか」「なぜ機能改善をしているのか」をキー・シナリオにもとづいて会話すれば目線が合いますし、リリース後のマーケティング活動にもつながってくると思います。
永く愛されるプロダクト開発・デザインの考え方まとめ
今回のウェビナーのポイントを「すぐに取り組んでいただきたいこと」としてまとめると以下のようになる。
今回ご紹介したウェビナーで使用した資料は、未公開部分も含め以下のリンクからDLできます。永く愛されるプロダクト開発・デザインの考え方にご興味を持たれた方は、ぜひご活用ください。
元マイクロソフトの萩原氏が語る ―VUCAの時代でも永く愛されるプロダクト開発・デザインの考え方とは―
