04. 使いたい、をカタチにするための秘訣（2）
タイガースパイクのUXデザイナー、マイマイこと佐藤麻衣子です。
前回に引き続いて、2021年5月12日にタイガースパイク 東京オフィスとしてはじめて開催したウェビナー講演内容をご紹介します！！
前回は最先端のプロダクトの作り方Tips5つのうち、1と2、仮説をつくる/ 価値をためすをご紹介しました。
今回はTips3-4（価値をきめる / 価値をかえる・ふやす）をご紹介していきます。
なお、本記事は5/12に開催されたタイガースパイクの自社ウェビナーをご参加いただけなかった方にもお伝えしようと編集してお届けしています。
Tips 3. 価値をきめる：ユーザーストーリーに対して最小の機能をあてはめる
「ユーザーストーリーに対して最小の機能を当てはめる」即ち「MVP」を決めるポイントです。
ここまでの「体験のデザイン」では、アイディアを出し、それをユーザーに実際に試すことで、ユーザーのニーズやプロダクトの持ち得る価値の可能性を広げ、探していくところにフォーカスが置かれていました。一方で、ここからは実際にUIデザインをしたり、プロダクトを開発したりというフェーズ。つまり、実際に「How」を決めて実行に移していくフェーズです。
実際にUIデザインをしたり、開発することはとても時間がかかります。そして、作りたいものはいつだってどんどん膨れ上がっていくものです。
良いユーザー体験を求めて実際に開発を続けていくと、いつまでもリリースできないプロダクトになってしまいます。結局それではプロダクトはユーザーの手に届かず「使えないもの」になるのです。
その状況を防ぐために「MVP」はあります。「ユーザーが使いたいと思えるプロダクトをどれだけ最小限の工数で作ることができるのか」という問題に対する秘訣がこちらです。
「発散」から「収束」への転換点を設ける
具体的な秘訣の一つ目がこちらです。「体験のデザイン」から「MVP」に移行するときに「『発散』から『収束』への転換点を設けること」です。少し抽象的ですが、このイメージを持つことが大切です。MVPに向けて、開発する対象をどんどん絞り込んでいかないと早くリリースすることはできません。
上の図がそのイメージですが、実際のプロジェクトではこんな直線的には進みません。「体験のデザイン」が終わったからそのまま「MVP」に移行するとは限らず、実際はMVPを考えながら「ユーザーストーリーをもう少し考え直さなければいけないね」ということになり、順繰り進んでいきます。
どちらにせよとても重要なのが、中心にある「コアバリュー」です。このコアバリューが「どうして後半の開発フェーズにおいて必要なのか？」の話をします。まず「コアバリュー」はビジネスやマーケティングのためにある言葉ではないのです。実際にプロダクトを計画してデザインして開発していくメンバーが「このプロダクトってなんのためにあるの？」という「共通理解を作るため」に存在します。このコアバリューがあることで前半の「体験のデザイン」を「実際に開発するもの（MVP）」として絞り込んでいくことが可能になるので、とても重要になります。
ユーザーストーリーを起点にプロダクトバックログを作成する
次に大切になるポイントが「ユーザーストーリーを起点にプロダクトバックログを作成する」です。「プロダクトバックログ」という言葉が初めて出てきたので、説明いたします。
プロダクトバックログとは、プロダクトを設計していく上で最も大切なドキュメントです。（後ほど実物をお見せして詳細をご説明いたします）ビジネスの観点や体験のデザイン、UIデザインの成果物、開発の計画や品質管理のようなさまざまな観点が含まれている、多目的なドキュメントです。そこで一番最初にかかれるのが「ユーザーストーリー」です。体験のデザインの成果物であり「ユーザーにこういう体験をしてほしい」ということが書かれているものです。
つまり、ユーザー体験からプロダクトの設計を始めることが大切。それがここのTipsです。
上記の図は開発事例の中の「良いパターン」とよくある「失敗パターン」を示したものとなります。
良いパターンとしては、出たアイディアを「ユーザーストーリー」という形で体験に落とし、その体験を「機能要件」として実際のプロダクトに落とす。機能要件になったものを「UIデザイン」に落としていく。というルートを辿るものです。
一方で、よくある失敗パターン（ありがちな落とし穴）としては「この機能、良いんじゃないかな」というアイディアからいきなり「機能要件（〇〇画面、△△機能というようなもの）」を作り始めてしまうことです。何が悪いかと言いますと、結局「企画して開発したのは良いけれど、ユーザーの方を向いていないので、使ってもらえないプロダクトになりがちになってしまう」ところです。
なので、あくまでも「ユーザーストーリー」「ユーザーの体験」をもとに機能要件に落としていくことが２つ目のポイントです。
MVPの順位付けの方法
３つ目のポイントは、絞った機能を実際にどのような順番で開発していくかの順位付けの方法です。プロダクトオーナー向けの本にはよく「プロダクトオーナーの最大の使命はROI（Return on Investment ＝ 投資収益率）を決めること」と書かれています。でも実際にそのプロダクトにおける「Returnとは？」「Investmentとは？」と聞かれると、答えに苦しむ人も多いのではないでしょうか。
そこで、上記の図を見ていただきたいのですが、ここでいう「ユーザーへのインパクト」が「ROIのReturn（＝提供できる価値）」になります。縦軸がその大きさを示しています。一方のInvestmentは横軸の「開発工数」です。これらの「ユーザーへのインパクト」と「開発工数」の大小を天秤にかけながらROIを考えていきます。
「ユーザーへのインパクトが強いものを作りたい」かつ「開発工数が少ない」ものがあれば最高です（左上の象限）。ただ、そんなものはなかなか見つかりづらく、実際には右上の象限の「開発工数はかかる」けれど「ユーザーへのパクトが強い」もの。左下の「開発工数は小さい」けれど「ユーザーへのインパクトも小さい」もの。この２つをうまく織り交ぜながら、プロダクト開発を進めていくことになります。
ただ、初期のMVP開発は01から始めていくので、いかに左上の「ユーザーへのインパクトが強く」「開発工数が少ない」象限のものを見つけ、集中できるかがMVPを豊かにするコツになります。
Tips 4. つくる：ユーザーストーリーを元にKPIを設定し、定量的に測って改善する
続いてのTipsは実際の「つくる」工程でのTipsです。要約すると「KPI ( Key Performance Indicator ）の立て方」です。
ユーザーが使いたいと思えるものを作っていくにあたっては、継続的な改善が必要です。前段のMVPはあくまでも「Minimum」なものですので、そこから継続的に学びつつ、測りながらどんどん改善していく必要があります。
ただ、一方でビジネスのゴールの達成をしていかなければならないのも、プロダクト開発
の現実です。これらのプロダクトの成長、ビジネスの成長の為には適切なKPI設定が欠かせないです。ただ、ビジネス的な観点だけで作られたKPIでは使いたいと思えるプロダクトには近づけていけません。使いたいと思えるプロダクトに向けたKPIを設定するにはどのようにしていけばよいか。そのポイントがこのTipsである「ユーザーストーリーを元にKPIを設定し、定量的に測って改善する」です。具体的に３つのポイントをお伝えします。
ユーザーが欲しいのは 「ドリル」 ではなく 「穴」
体験の価値とビジネスの価値は両方大切です。ですが、その両方が常に同じかというと違うと思います。こちらの図にあるのは古典的な例ですが「ユーザーが欲しいのは 『ドリル』 ではなく 『穴』 」なのです。
この場合に、例えばビジネス側の人が工具メーカーの人だとしたら「ドリルを作って販売する」というソリューションを提供することによって、双方の価値を満たすことができます。
一方で、ビジネス提供者側がドリルを作る会社ではないのにドリルを作ろうとすると、ビジネス側のやることとしては非常に負荷が高く、体験の価値に対してアンバランスなものになってしまいます。
もしビジネス側がサービスを提供する会社であれば「人材を派遣する」というソリューションを提供する方が体験の価値とビジネスの価値のバランスが取れた解決策となるのではないかと思います。
つくる工程において気をつけなければならないのは「体験の価値」と「ビジネスの価値」のどちらかに寄り過ぎたものにならないように気をつけることです。両方の視点において実現可能なものにすることが大切になってきます。リーンの「最適な解決策」「適切な内容でできるか」になりますので、ビジネスと体験の価値の両方で見ていくことがポイントです。
プロダクトバックログに「計測方法」を必ず記載する
前段の「体験のデザイン」つまりユーザーストーリーに繋がっていきますが、ここはビジネス観点も加味して検討されています。しかし、これが実際のプロダクトとなってユーザーに価値が届いたのか？という観点になると、それをどのように測っていくのかが重要なポイントです。
先ほど、プロダクトのドキュメントとして重要なものに「プロダクトバックログ」があるとお伝えしました。上記の図がプロダクトバックログの一項目となります。タイガースパイクでは標準的にAtlassian社のJiraを使っているので、実際にはJiraのチケットという形で表現されています。
このプロダクトバックログの雛形ですが、随所に様々な工夫が凝らされており、項目が多いものになっています。この中には機能要件も入っていますし、最終的に「どのような項目をテストしてリリースするか」という受け入れ条件、あるいはUIデザインの成果物も入っています。
この様々な情報が集約されたプロダクトバックログの一つの項目が「計測方法」の項目です。この計測方法が埋まっていないとプロダクトバックログが完成しないのです。どういうことかというと、プロダクトバックログは体験のデザイン、ユーザーストーリーからスタートしていて、そこから機能要件が足されたりしていきます。しかし、ユーザーストーリーから機能、その機能をどのように計測するかまでが一揃いでないとプロダクトバックログが完成しない仕組みになっているのです。この仕組みによって、実際に作った機能やその先にあるユーザー体験が必ず計測される状態になります。
プロダクトバックログの具体例を一つご紹介します。
体験:
- ユーザーはイベント参加の日時を忘れることなく、確実に当日イベント参加することができる
機能要件:
- イベント参加予約前日 19時に対象ユーザーに対して参加リマインドメールを送信する
- メールの内容
- イベントのタイトル
- イベントの参加日時
- イベント会場の住所
- ...
計測:
- メールの開封率
- 当日キャンセル率の前月との比較
このようにかならず「計測」の項目をおくことで、ユーザーに価値ある体験が届いたかを必ず計測することが大切になります。
ただ、ここで一つお伝えしておきたいのが「ここで計測されたデータ」が、この機能を作ったからには「必達の達成目標」というわけではないということです。計測されたデータがどのように使われているかというと、実際のプロダクトがどれだけユーザーに体験を届けられたかを測るための指標として使われています。先ほども申し上げたように、MVPをからまずは小さく作ってそこから改善するのが「ユーザーが使いたい」と思うプロダクトを作っていくプロセスなので、この後さらなる改善の為にこの計測データを使っていくのが、この計測データの使い方です。
実際の計測方法
次のポイントは「実際にどのように測っているのか」です。
ここはかなり実際的な話となるので、使っているツールの話になります。
例えば...
・モバイルアプリでは「Firebase」
・Webでは「Google Analytics」
などを使用しています。（もちろん他のツールも存在しますし、使うこともあります）
これらを使うことによって、
・ユーザーがどのページを見たか
・ユーザーがどのボタンを押したか
など、具体的なユーザーの行動を計測できます。
一方で、アプリケーションから取れるデータはそれらだけではなく、データベースに蓄積された情報などもあります。
例えば...
・予約データ
・会員登録のデータ
などです。
このような「ユーザー行動のデータ」と「蓄積されたデータ」とを一箇所に集約していくことが見やすいデータを作っていく上でのベストプラクティスです。
これらの計測したデータを常に確認できるように見やすいデータダッシュボードを、MVPを作る段階、リリースする段階から一緒に揃えておくことをお勧めします。
さて、ここまででTips5つのうちの4つまでご紹介してきました。
次回はTipsの5つ目、「価値をかえる・ふやす」のパートに入り、このシリーズも最終回となります。ぜひ、更新をお待ちください！
--------
コンセントリクス・カタリスト（旧タイガースパイク）では、モットーである「使いたい、をカタチに」を実現することで社会をより豊かにしていく仲間を募集しています。ぜひ一緒に新しい「価値創出」をすべく、あなたのご経験を活かしてみませんか？詳しくは下記の採用ピッチ資料、もしくはWantedlyをご覧ください。