UXploration

Explore the art of UX persuasion | UX デザインの理論と実践

お知らせ - Blog を引っ越します

約10年続いたこのブログを止め、新たに公開する個人サイト(mariosakata.com)にブログを移行していくことにしました。

mariosakata.com

昔から、個人サイトを持つことが夢でした。それが今、mariosakata.com として実現できたことを嬉しく思います。目的は、セルフブランディングを強化するためにこれまで培ってきたナレッジや経験、課外活動を紹介しているメディアや情報を一か所に集約させるためです。

とはいえ、まだ過去の記事を中心にアクセスされていることが多いため、ブログはしばらくは削除しない方針でいます。少しでも誰かの役に立っているのであれば、これまでの痕跡として残したいと思います。

新しく始める「reVision」というブログでも、自分の専門領域である UX デザインやプロダクトマネジメントについて触れていく予定です。今後とも変わらずによろしくお願い致します。よろしければ Twitter もフォローしてやってください。

 坂田一倫

バリュー・プロポジションを言語化してみよう!

この記事では、プロダクトやサービスの提供価値を言葉でシンプルに説明する方法をご紹介します。

--

プロダクトやサービスを開発している中で、聞かれるとちょっとドキッとしてしまう質問があります。

そのプロダクトの価値ってなんですか?

なぜドキッとしてしまうかと言うと、どのような言葉で説明すれば納得がいく回答になるのか、戸惑ってしまうためです。

プロダクトやサービスは何かしらのユーザーないしは社会の問題を解決しています。解決しているからこそ、存続していると思っています。そのため、プロダクトやサービスの価値はなんですか?という問いに対する回答には、どんな人の、どのような課題を解決しているのかが明確に具現化されていなければ、自身を持って答えることができずにモヤモヤが残ってしまいます。 

そもそもなぜ具現化する必要があるのか?

ぼくが好きな言葉のひとつに以下があります。

Customers don't care about your solution. They care about their problems.(ユーザーはソリューションに興味はない。ユーザーが興味があるのは、自分自身がどのような問題を抱えているからである。)

米サンフランシスコで多くのスタートアップのアクセラレータープログラムを提供している 500 Startups の Dave McClure 氏の言葉です。

ソリューションはなんであれ、ユーザーはプロダクトを利用するきっかけとして、自身が抱える問題が解決されるのか否かを気にしています。そのため、どのようなソリューションでも、どんな問題を解決してくれるのかが具現化されていないと、ユーザーとの距離が遠ざかってしまって、つくることだけに注力してしまいがちです。それはチームにとってもよくありません。

結果としてリスクが膨らみ続け、ユーザーに使わなくなったり、改善に向けて検討を開始する際にプロダクトやサービスの存在価値を問う場面に直面してしまって、あたふたして逆戻りしてしまいます。ぼくも以前、その状況に陥ったことがありました。「解決したいこと」よりも「開発したいこと」が先行してしまい、開発して満足してしまうケースです。

どのように言語化すべきか?

具現化するためには、まず言語化する必要があります。言葉で表すことができなければ、もちろん伝達することはできませんよね。

そんな居心地の悪さから打破するためには、プロダクトやサービスの提供価値の言語化が効果的です。それも、対象の価値が一目でわかるようにすることです。

f:id:separate-ks:20190829152049j:plain

プロジェクトチームでバリュー・プロポジション・ステートメントのアイディアを考えている様子。後ろでカメラに向けに笑っているのはぼくと Pivotal Labs のもう1人の PM です(笑)

そこで今回ご紹介したいのは、Pivotal Labs でプロダクトやサービスの提供価値を言語化する手段の一つとして用いられているバリュー・プロポジション・ステートメントです。以下がそのフォーマットです。

〜は(ペルソナ)
〜のとき(コンテキスト)
〜ができていないだろう。(課題)

この〜は(ソリューションまたは機能)
〜とは違い(競合またはいまの解決策)
〜をすることによって(提供価値)
〜は(ペルソナ)
〜できる。(ユーザーが得られるアウトカム) 

 

イメージしやすいように、例を挙げてみます。

電車の新しい乗り換え案内アプリを開発していると過程して、ペルソナの名前はタカシさんとします。ユーザーリサーチで特定した、ビジネスにとってもユーザーにとっても優先度が高く、解決すべき問題にアプローチするための提供価値を、バリュー・プロポジション・ステートメントにあてはめてみると以下のようになります。

タカシさんは
目的地(駅)に向かうために電車に乗るとき
ちゃんと時刻通りに電車が動いているかどうかを必要なときに把握できていないだろう。

このプロダクトは
(競合のプロダクト名)とは違い
正確かつ最新の運行情報を提供することによって
タカシさんは
どの電車を利用すればよいか自信をもって選ぶことができる。 

 

実際のプロジェクトではコンテキストや課題をもっと具体的に記載していますが、提供価値をこのようにステートメントとして言語化することによって、冒頭の質問をされたときに、チーム全員が自信をもって回答することができるようになりました。

つくったあとはどうするべきか?

バリュー・プロポジション・ステートメントのいいところは、以下がひとまとまりで表現されていることです。

  • 誰が、どんなときに、どのような問題に直面しているのか
  • 他と比較して、なぜこのプロダクトでなければ解決できないのか
  • プロダクトの価値を届けることで、ユーザーが得られることはなにか

そして、このプロダクトでなければいけない理由をビジネスとユーザーの双方から捉えることで、北極星を見失わずに済みます。

バリュー・プロポジション・ステートメントはつくっただけで満足するのではなく、常に振り返ることが大切です。時間の経過と共にユーザーもマーケットも変わっていくため、様々な調査を進めながら変化に合わせて柔軟に更新し続けていく必要があります。

そのためには継続的にユーザー調査を実施することをお勧めします。プロダクトマネージャー、プロダクトデザイナー、エンジニアなどメンバー全員で優先度が高いと判断したユーザーの課題を解決するための価値が反映されているか、がポイントになります。

もしお時間がある方はぜひやって見てください😆 そして、やってみた感想などをコメントなどでフィードバックしていただけると嬉しいです。

*Originally published at https://link.medium.com/f2M5wdzAxZ on Aug 15, 2018. Pivotal Labs Tokyo の公式ブログに掲載した記事の転載です。

デザイナーからプロダクトマネージャーへのキャリアパスの探求

約2年ぶりの、久々の投稿です。この空白期間、僕は Pivotal Labs Tokyo という会社でプロダクトマネージャーとして仕事をしていました。いまも、変わらずにプロダクトマネージャーとして楽しい1日を送っています。

よく活動休止をしていたバンドが充電期間を得て復活!というニュースを耳にしますが、この記事をいま書くにあたって同じような心境にいる気がしています。この2年間はもちろんのこと、社会人になってから10年以上のキャリアを遡って故 Steve Jobs が口にした、Connecting the Dots を実践してみようと思ったことがきっかけで、いまこの記事を書いています。

その過程で僕が辿り着いたひとつの結論は、デザイナーからプロダクトマネージャーへのキャリアパスは、ありと言うことです。デザイナーないしは UX デザイナーのキャリアパスの先にあるものはなにか、という問いに対するひとつのアイディアになればいいな、と思っています。

f:id:separate-ks:20151225113414j:plain

これまでのキャリア・フロー

ざっくりとまとめると、僕のキャリアは以下の通りに流れていきました。

  1. ビジュアルデザイン:バナーや特集ページなどをデザイン
  2. IA(インフォメーション・アーキテクト):特集ページやウェブサイトの画面設計
  3. UX デザイン:ウェブサイト全体のリニューアルとプロジェクトマネジメント
  4. 経営企画:新規事業の立ち上げ
  5. UX 戦略:ユーザーセグメントごとの中長期戦略設計

いま振り返ってみると、自身がやりたかったことへの本質に近づいてきている気がしています。

  • ウェブサイトのレイアウトやサイト構造を設計していると「誰のために」つくるべきか?という問いにもっと関わって行きたいと考えるようになり、
  • UX デザインを基軸としたリニューアルを担当していたときは「なぜ」つくるべきか?という問いにもっと関わって行きたいと考えるようになり、
  • 新規事業をゼロから立ち上げた際は「正しいもの」とはなにか?という問いに関わって行きたいと考えるようになり、
  • ウェブサービスの中長期戦略を設計していたときは「どのように」つくるべきか?つくり続けていくべきか?という問いに関わって行きたいと考えるようになりました。

そして、これらの WHAT? FOR WHOM? WHY? HOW? の問いが共通の思考回路となっていました。この問いへの最適解を追求し続けたいという想いがあって、いまに至るのだと思います。

火付けとなったコミュニケーション

今日、サービスデザインの普及によってビジネスとデザインが少しづつ融合し始めていると感じています。そのハーモニーは、僕は当時から特に意識していたこともあって、いまとなってはとてもワクワクしています。

しかし、ここにくるまでは、デザイナーないしは UX デザイナーとしてのキャリアが最も長かったこともあり、ユーザー視点の重要性を強く主張しすぎるあまりに、事業サイドのチームとよく対立することがありました。

そして、組織体系として事業を横断してプロジェクトにコミットしていく、いわゆるコストセンターとしての横串組織に属していたため、十分に自身の価値を発揮することができていないと、自分を攻めたときもありました。

  • ユーザーリサーチを実施するための時間とコストは確保できているのか?
  • この機能は本当にユーザーのためになるのだろうか?
  • リリースした後のユーザーの反応はちゃんと見ているのだろうか?

このような問いが常に頭をよぎり、敵対的、反抗的、と言われてもおかしくないコミュニケーションが続いていました。ところが、いま思い返すと、自分自身がコミュニケーション先の相手のことを理解しようとしていなかったような気がします。

そこで僕は思いました。自らが事業側にシフトしてプロダクトやサービス開発に関わっていけば、その理由がわかるかもしれない。

それがきっかけとなって、プロダクトマネージャーという仕事に出会いました。

プロダクトマネージャーとしての脳トレ

僕はいま、サンフランシスコに本社を置く Pivotal Labs Tokyo という Lean XP の思想をもとにクライアントと一緒にプロダクトをつくる、アジャイル開発コンサルティング会社に勤めています。詳しい内容は Pivotal Labs Tokyo のブログを覗いてみてください。

medium.com

僕がこれまで出会うことがなかった、Pivotal Labs が推奨している Lean XP というソフトウェア開発のメソドロジーは、自分が抱いていた課題感を払拭してくれました。詳細は前述のブログで触れますが、特徴としては以下のようなものがあります。

  • ビジネスとユーザー双方の視点から解決すべき課題の優先度をつける
  • 解決すべき課題は、ユーザーの観点から捉える
  • 優先度はビジネスバリューが高い・低い に加えて ユーザーバリューが高い・低いで考える
  • 優先度が高いものからひとつづつ開発をする
  • 開発を小さく進めてリスクを最小限に抑える
  • ユーザーからのフィードバックをもとに続けるか/見直すか/止めるかを判断する

Pivotal Labs のプロダクトマネージャーはざっくり説明すると、ビジネスに特化した視点でプロダクト開発に携わるポジションで、ビジネス上の課題を解決するためのプロダクトとはなにか、というマインドを常に保つ必要があります。このマインド・シフトは現在も進行形ですが、ビジネス上の課題は、ユーザーが直面している課題が数値などによって反映されたものとして捉えると、ユーザーの課題を解決することはビジネス上の課題を解決するに等しいということも言えるのではないでしょうか。

終わりに

Pivotal Labs のプロダクトマネージャーとして働き初めて約2年、過去に僕が直面していたビジネスニーズとユーザーニーズの対立によって生まれる摩擦を最小限に抑えるための手段が、ここに来て増えていきました。どちらか一方という会話ではなく、可能な限り、双方にとっての Win-Win な状態をつくりだすにはどうすればいいかというコミュニケーションが中心となっていることを肌で感じています。

視点は違えどユーザーの課題という共通言語は保ちつつ、全部はできないというサービス開発の前提に立つことが最も大事で「ならばどれから着手していこうか」というその場で発生する会話は対立ではなく、協議に等しくなっていきます。ユーザーにとって価値のあるプロダクトやサービスを開発・運営していくことは関わる者であれば誰もが望むことだと、プロダクトマネージャーになって思いました。だからこそ、プロダクトマネージャーはデザイナーのキャリアパスの行き着く先として、ありだと思います。

This work is licensed under a Creative Commons Attribution 4.0 International License.
Others, like quotes and images belong to its original authors.