ユーザー価値提供につながる開発とは？
本記事は株式会社ココナラ Advent Calendar 2024 25日目の記事です。
最終日の記事をお読みいただきありがとうございます。
株式会社ココナラ 執行役員 VPoEの村上です。皆にはむーさんと呼ばれています。
本記事では、日頃のプロダクト開発で心がけているユーザー価値提供について、これまで自分なりに考えてきたことを言語化していきたいと思います。
もちろん、これが正解だというつもりはなく、いろんな形のユーザー価値提供の形があると思いますのであくまでその一例程度に捉えてもらうのがよいかもしれません。
ユーザー価値とは何か？
そもそも、タイトルに掲げている「ユーザー価値」とは一体何でしょうか？
まず 価値 というのは、辞書を参照してみると「その事物がどのくらい役に立つかの度合い、値打ち」という意味になります。
では ユーザー価値 はどうなるでしょうか？辞書にその用語は存在しませんので以下の通り定義してみました。
「有意義な体験や満足感」というのは、例えば何かの問題解決や目標達成ができたり、また喜びや感動を得られたりすることなどを指しています。
ここで私が特に重視しているのは、「機能の提供までではなく、機能提供の先にある付加価値を高めること」 がユーザー価値だという点です。
ここで言う付加価値とは、なにかユーザーが抱える問題を解決したり、生活が豊かになったり、社会的に意義のあることなどの要素を含んでいます。
自分なりに整理してみると、以下の3種類に分類できます。
- 機能的価値
- 情緒的価値
- 社会的価値
それぞれを具体的に説明していきたいと思います。
▷機能的価値について
機能的価値とは、ユーザーが特定の目的を達成したいと考える際、プロダクトが提供する機能によって直接的な成果が得られることを意味します。
機能的価値の具体例としては以下のようなものがあります。
- 検索機能が高速かつ正確である
- リアルタイムに表示される（翻訳など）
- 単純作業が自動化される
- セキュリティ対策が強固で安全にデータが保護される
- 作業が自動化され業務が効率化される
機能的価値は、機能に紐づく価値であり、それなしでは目的が達成できず必要不可欠である場合が多いです。
この機能的価値については、誰しもが普段からよく考えている部分であり、仕様書・企画書に記載されているものになるので、あえてここで細かく言及する必要はないかと思います。
ただ注意が必要で、機能的価値の落とし穴が１つあります。
それは 機能的価値を追求し機能が豊富になってくると、１つ１つの機能は価値があっても全体としては価値が下がることがある ということです。
例えば、機能が多すぎてごちゃついているプロダクトは、学習コストが高く操作性も複雑になり、本当に必要な機能が見つけにくくなるという問題があります。
最近では、スマートフォンアプリが多用されますが、小さい画面の中で頻繁に利用しない機能が多数搭載されてしまうと、かえって使いにくくなったり誤操作を誘発することにもなりかねません。
これは弊社としても他人事ではなく、向き合っていかなければならない問題だと考えています。
話が変わりますが、機能的価値の延長として、機能提供までのリードタイム も同様にユーザー価値に影響を与えるものだと考えています。
同じ機能的価値をもつ場合、当然ながら早く機能提供（＝リリース）できたほうがユーザーがより早く恩恵を得られることから、リードタイムも大事な要素となります。例えばリリースが1ヶ月遅れるということは、その１ヶ月の間ユーザーが対象機能を使えないことになりますし、その結果売上増加も見込めなくなります。
後述の施策優先度の項目でも説明しますが、機能を増やすこととリードタイムを減らすことは一般的にはトレードオフの関係になりがちです。
そのため、どのようなバランスを取るべきかは内部でしっかり議論し、落とし所を決めていく必要があります。
▷情緒的価値について
情緒的価値とは、「〇〇ができる」といった機能的価値とは違い、ユーザーがプロダクトを使うことで得られる「快適さ」や「満足感」など感情的な部分に影響する価値を意味します。
情緒的価値の具体例としては以下のようなものがあります。
- 操作に迷わず直感的で洗練された美しいUI
- レトロで懐かしさを喚起するデザイン
- エラー画面の工夫などユーモアや遊び心がある要素
- 心揺さぶるドキュメンタリーなど、感動を与えるコンテンツ
上記のような情緒的価値は、機能的価値に比べて必然性は低いように思えます。なぜならその価値がなくてもユーザーがやりたいことは実現できるからです。
では、なぜ情緒的価値が必要なのでしょうか？
私は、以下の理由により情緒的価値にもこだわることが重要だと考えます。
- 感情が意思決定に大きく影響するため
- プロダクトの愛着を生むため（ブランドロイヤリティ）
- 競合プロダクトとの差別化要因になるため
- ユーザー体験全体を向上させるため
- 情緒的体験が口コミ効果につながりブランド認知度を向上させるため
人間は、感情的な生き物でありすべて合理的な判断だけになるとは限らず、時には感情に依存した意思決定を下すことがあります。
例えば、Starbucks Rewardsを例にあげてみます。
これは端的に言えばポイント管理機能になりますが、単にポイント数値を表示しその数値がただ積み上がっていくだけのものではありません。
そこでの体験としては、購入ごとに「スター」がたまる仕組みがあり、加えて以下のようないろんな工夫が施されています。
- スター数とゴールまでの距離の可視化でゲームのアイテム収集に似た体験
- 期間限定イベントによるゲームミッションを実施するような体験
- ゴール達成時の視覚デザインによるFBでゲームの勝利や報酬獲得感を演出
このように質素になりがちなポイント管理機能も、工夫によってはゲームのような体験を演出することができ、楽しみながら使うことができるようになります。
これは当然ながらなくても成立する価値ではありますが、満足度の向上や愛着を高める要素としてあったほうがいい場面もあるというのは容易に想像できるかと思います。
近年ではAI活用が活発で、ユーザー一人ひとりの好みや行動パターンに合わせてパーソナライズされるようになってきています。このように情緒的価値については、個人に特化した調整が進み、より深い満足感を得られるような時代になってきているように思います。
▷社会的価値について
社会的価値とは、プロダクトが解決する社会的課題や役割を明確にすることで、プロダクトの社会的貢献を知ってもらうことを意味します。
社会的価値は、さきほどの機能的価値や情緒的価値に比べて抽象的で分かりにくいものです。
どうしてこの社会的価値も、プロダクト開発において考慮する必要があるのでしょうか？
近年、環境問題への関心が高まる中、大規模なプラットフォームを中心に環境負荷軽減に取り組むことで持続可能な社会を目指すことが求められています。その上で各企業は、社会的責任（CSR）として、責任ある行動を取るとともに、説明責任を果たす必要があります。
例えば以下のような取り組みなどがあります。
社会的価値を認識してもらうことで、ユーザーが社会の一員としてその実践に貢献しているという感覚を持つことができます。
例えば、環境に配慮したプロダクトを選ぶことで得られる満足感やコミュニティ活動に貢献するサービスを利用することで得られる達成感などが挙げられます。
ただ、社会的価値については比較的大きな企業が取り組むことが多く、企業によっては深く考慮しないこともあります。
本記事では、説明したいスコープとズレてしまうため詳細な説明については割愛します。
どうやったら価値提供につながるのか？
では、上記のようにさまざまなユーザー価値がある中で、どのような点を考慮しながら開発していけばよいのでしょうか？
ユーザー価値提供につながる開発を行う上で、大事だと思う観点が３つあります。
-
- ユーザー視点での問題定義
-
- ユーザー価値の優先順位付け
-
- 仮説検証とイテレーションの推進
以降それぞれについて説明します。
1. ユーザー視点での問題定義と施策化
価値提供を推進していくためには、ユーザーが抱える課題や潜在的なニーズを正確に把握していなければなりません。
ユーザーニーズをよりクリアに把握するために、一般的には以下の手法などが使われます。
- ユーザーインタビューやアンケート調査
- ユーザージャーニーマップの作成
- ペルソナやジョブ理論の活用
ちなみにココナラでも、以下のような形でユーザーニーズを把握する努力をしています。
他にもいろんな手法が存在しますが、どのようにニーズを把握するのが良いでしょうか？
最適な手法は、状況や目的によって異なると思います。
前章で説明した価値分類で言うと、機能価値は比較的定量的に把握する事が多く、情緒的価値は定性的に把握する事が多いように思います。社会的価値については、そもそも上記のような方法とは全く別の検討から発生すると思います。
ここで機能的価値提供に焦点を当てて、私が心がけている点を参考までに紹介します。
- ① マクロ視点で分析し、全体のユーザーニーズの傾向を把握する（仮説を立てる）
- ② ミクロ視点で分析し、一人ひとりのユーザーの具体的なニーズを把握する（仮説を机上検証する）
以下、それぞれ簡単に説明していきます。
①マクロ視点分析
①については、対象となるユーザー母集団全体の傾向を把握しようとすることを指しています。
必ずしも全ユーザーでなくてもよく、ある特定セグメントのユーザー全体という捉え方でもかまいません。例えば、〇〇円以上購入しているユーザーだったり、特定のカテゴリを出品しているユーザーなどを想定するイメージです。
これらのユーザー群に対して、ユーザーメトリクスを取得し、ダッシュボード化を行っています。
ユーザーメトリクスの情報源としては、システムの行動ログなどの情報を活用しています。
画像内容はサンプルです
画像内容はサンプルです
上記のようなダッシュボードを活用し、ユーザー行動の過程において何がボトルネックになっているのか、どういう部分に改善の余地があるのかを見極めます。
また同様にアンケートなどにもくまなく目を通し、上記の判断に齟齬がないかを確認・検討します。
上記を行うことで、例えば以下のようなインサイトが得られることがあります。
- ユーザーが何度も検索を繰り返しており、目的の商品にすぐにたどり着けていない状況がある
- 自分で探して閲覧した商品より、レコメンドされた商品を購入する確率が高い
- トップページで強調している主要機能が実はあまり利用されていない
ダッシュボードなど定量化したものをうまく活用することで、容易に全体傾向を把握できるようになります。全体傾向がわかるとある程度改善するための仮説が立てられるようになります。
ただこれだけでは正直ざっくりとした傾向しか分からず、課題の雰囲気を掴むことくらいしかできません。なにかボトルネックをうまく見つけられたとして、それがどんな原因で発生しているのか読み取ることは難しいです。
②ミクロ視点分析
そこで②を活用します。②は、一人ひとりのユーザーに焦点を当ててその人の動きを観察することで、具体的にどのようなところで困っているのかを詳細に把握するということを指しています。
これはいろんな方法で行います。
まず前提として①を経て、「〇〇の画面にボトルネックがあるな」という仮説を立てているとします。その場合、ユーザーイベントなどの場に参加し、対象セグメントのユーザーだと思われる方に直接疑問をぶつけてみて仮説を机上検証します。
ここで結構よくあるのが、思ったほどボトルネックになっていないということや、逆に思わぬところがボトルネックになっているということです。
- 実は検索で、目的の商品にたどり着いているが、複数の商品と比較するためにその後も検索を繰り返していた
- 商品カテゴリによってレコメンドが貢献する度合いも大きく異なる
- トップページで強調している主要機能は、使われていないのではなく別の導線からいけるのでその導線が使われていないだけ
ダッシュボードなど定量化したもののみでは、全体傾向は掴めても正確に情報を掴みきることは難しいため、実際に対面で確認をとり、本当にそこが困りポイントなのかを確認することは何よりも重要だと思います。
また別の方法として、システムのログを細かく読み解いて一人ひとりの動きを見ることで仮説検証をしたりもします。
1〜2人程度のログ確認ではサンプル数が少ないので、可能な限り多くのユーザーの動きを見て本当に仮説通りなのかを確認するようにしています。
上記のような対応を行うことで、ユーザーの解像度を上げるように心がけています。
無事ユーザーニーズを把握できたら、後はそれを明文化し施策に落とし込むだけです。
特に一人ひとりレベルの調査までできていれば、施策提案の際にもより解像度の高い提案をすることができ、採択される可能性も高まります。
2. 施策の優先順位付け
上記のような方法で、ユーザー解像度の高い施策提案をすることができるようになります。
次に考えないといけないのは、施策の優先順位付けです。
施策は当然自分の提案するものだけでなく、複数あるはずです。開発リソースは限られているため、施策の優先順位付けが重要です。
では、どうやって優先順位を決めると良いのでしょうか？
価値の高さを基準に優先順位を決められると良いのですが、価値というものは必ずしも定量化できるものではなく、優劣を決めるのが難しいです。そこで、何らかの代替指標や制約条件を加味しながら優先順位を考えていくことになります。
会社の状況や考え方によって、優先順位を決める観点は異なりますが、一般的には以下のような観点が使われると思います。
| 優先度設定の観点 | 概要説明 |
|---|---|
| 売上インパクト | 売上（＝価値の総和）への影響が大きいと考えられるほど優先度が上がる |
| 開発規模感（粗見積り） | 規模が小さいほど価値提供が早まるため、優先度が上がる。 また一方で実現可能性が低い場合、価値提供できない可能性があるため優先度は下がる |
| 緊急性 | 障害、期間限定イベント等緊急性を要するものは、急激な価値の変化が予想されるため優先度が上がる |
| 市場感 | 競合プロダクトがすでに実施しているなど、市場として価値提供が当たり前になりつつある場合、優先度があがる |
| 中長期観点でのリスク対策 | 利用ツールのEOLなど、中長期でみたときにリスクがある場合、価値の毀損につながるため優先度が上がる |
| 別施策との依存関係 | 施策間で機能提供の順序依存がある場合、価値提供の依存関係を考慮し先に出すものほど優先度が上がる |
| その他会社独自の基準 | ビジョン/ミッションに沿っているなど、会社としての価値提供の方向性がマッチしている場合、優先度が上がることがある |
どの観点においても定量的に判断することは難しいです。そのため、各観点を定性・定量両面で総合的に分析し、最終的にはプロダクトオーナーによる意思決定を行うのが普通です。
ここで大事なのは、どんな意思決定においても、結果だけでなくその意思決定の経緯や理由をしっかりと記録に残すこと が重要です。
この背景や経緯の記録は、面倒なので省略されがちです。
ただ、しっかり整備していると以下のように後々助かることが多いため、多少面倒でも作成することをおすすめします。
- 今後類似の施策をやる際に、意識した観点や意思決定方針を参考にできる
- 施策の振り返りの際に、意思決定に見直すべき点がないかを見直し、次に活かすことができる
- 結果だけみると意思決定が妥当ではないと思える場合でも、背景や理由があることで関係者が納得できる
- 優先順位を見直す際に、それぞれの施策の判断基準が明確なので比較しやすい
3. 仮説検証とイテレーションの推進
施策の優先順位が決まったら、あとは優先順位の高いものからリソースを確保し開発を行います。
最初に開発する上で大事なのは、リーンスタートアップでいうところのMVP(Minimum Viable Product)の実践です。
MVPの詳細については、こちらの記事などを参考にしてください。
ユーザー視点での問題定義と施策化の章でも軽く仮説検証について触れましたが、あくまでそのフェーズの仮説検証は机上の検証であり、想像・イメージの域を超えません。実際の仮説検証は、何かしらプロダクト/機能をリリースしなければ十分な検証はできません。
そこで、プロダクト/機能をリリースしてから正確に仮説検証しようとするのですが、リリースまでに長期間かかってしまうと仮説検証の時期が遅くなってしまいます。ユーザー視点の問題定義をしっかりやっていたとしても、そこで定義した解決策が求められていない可能性も大いにあります。
そのような場合には、迅速に改善を繰り返し、真にユーザーが求めているものを早期に見つけていく必要があります。そのために、最初のリリースは極力小さく開発する必要があります。これがMVPが重要な理由です。
ではMVPとしてどこまで開発すればよいでしょうか？
１つの考え方としては、MVPは仮説検証可能な必要最小限の機能 と認識するとわかりやすいかもしれません。
検証したい仮説がある場合、その検証に必要ない機能は一旦削れないか検討することが重要です。機能を削るためには、あらかじめ仮説を明文化しておくことが重要です。
一例として、以下の観点に沿って仮説を明文化していくことをおすすめします。
| 仮説を明文化する項目 | 概要説明 |
|---|---|
| 背景・目的 | なぜこの施策をやるのかの背景や目的を説明する |
| ターゲットユーザー | この施策によって恩恵を得られるユーザー層を明示する 可能なら対象外のユーザー層も明示する |
| 解決したい課題 | この施策によって解決したい課題を具体的に列挙する ※抽象的ではなく具体的に表現するのが大事です |
| 開発スコープ（最小） | 上記課題を解決するための最小の開発スコープ（機能）を定義する |
| 計測方法（検証方法） | 課題が解決されているかどうかを計測する方法を定性・定量両面で明示する |
上記のように仮説を整理していると、必要最小限の機能の取捨選択がしやすくなります。
また、イテレーションを高速で回していくために、短期間での開発・リリースをしていきたいところです。
ただし、実際の開発においては以下のように必ずしも削れない場合もあるため、そこは臨機応変な対応が求められます。
- MVPには必要ないが、ユーザー体験上一貫性や整合性などの観点でなくてはならないもの
- 公開まで一切秘密裏に進めており、事業上ビッグバンリリースが避けられない場合
開発・リリースが完了したら、あとはイテレーション（仮説検証＆修正）を回します。
事前に設定した計測方法を用いて、結果を分析し改善の方向性を見極めていきます。
最初から想定通りになることは稀なので、微調整は必須になります。一方で、想定を大きく外している場合には、状況によっては撤退（＝開発した機能の削除）も考慮する必要があります。
このあたりは、事業責任者と相談しながら推進していくことになると思います。
また、イテレーションを成功させるためには、開発チームだけでなく、デザインチーム、マーケティングチームなど様々な部門の協力が不可欠です。関係部署と密に連携しながらイテレーションの方向性をすり合わせていくことをおすすめします。
技術的な選択とユーザー価値提供のバランス
上記のような方針で、ユーザー価値につながる開発を推進できると思います。
一方で悩ましいのが 技術負債の対応 です。
ユーザー価値提供ばかりを追い求めた開発を推進してしまうと、気づかぬうちに技術負債がたまりすぎて返済できないということはよくあります。
技術負債も、中長期的な観点で言えば生産性低下につながり、間接的にユーザー価値提供を阻害する要因にもなりますので計画的に対応していかなければなりません。
では、ユーザー価値提供の開発と技術負債解消の開発について、どのようにバランスをとれば良いでしょうか？
バランスは、会社のフェーズやシステムの規模感によって大きく変わります。
スタートアップが0→1で開発した新規プロダクトは、規模も小さく技術負債も全く気にしなくて良い状態だと思います。
一方で、10年以上開発・運用し大規模化・複雑化したシステムは、レガシー部分も残っており当然技術負債も溜まっている状態だと思います。その場合は、優先度を高めて技術負債にも対応していかなければなりません。
上記のように状況によって判断基準は異なりますが、スケジュールを考えるうえで大事な観点があります。
※ 本来、ギリギリになる前に対応できるのが一番良いです、というのは補足しておきます。
なぜ、上記のように考えるのかについて簡単に説明します。
技術負債はエンジニア以外への説明難易度が高く、また今やらなくてもすぐに問題が起きるわけではないため、優先度が上がらないことが比較的多めです。
ただ、中長期的に確実に問題になることは明らかです。そうなってしまってからでは時すでに遅しで、最悪の場合事業を一時ストップして解消に当たることもよく見かけます。
事業サイドとしても、事業ストップするリスクを追うくらいなら、少しずつリソースを使って継続的に技術負債解消をしたほうがいいという判断になります。
そこで、手遅れになるタイミングを見極めてその前までに手を打っておくことが重要です。
では、手遅れになるタイミングというのはどのように見極めるのが良いでしょうか？
以下に一例をリストアップします。
| 手遅れだと判断する状況 | 放置すると発生しうるリスク |
|---|---|
| スケーラビリティの限界 | ・数年後に、ユーザー数やデータ量の増加等によりサーバーの負荷が限界を超え捌けなくなる。 その際、スケールアップ/アウトをしようとしてもコスト的に許容できなくなる。 ・対応しないと、パフォーマンス低下やサイトダウンに繋がる。 |
| 生産性の著しい低下 | ・数年後に、ソースコードのLOCが膨大になり、認知の限界を超えてしまう。 ・その結果、開発の際に毎回調査の時間を追加で取ったり、予期せぬ不具合を防ぐために多くのテストに時間をかけるようになる。 |
| 運用・保守性の限界 | ・数年後に、非効率なアーキテクチャ/設計等によりリリース後の障害でアラートが多発し、残対応にも多くの時間をかける必要が出てくる。 ・また規模が大きくなると属人化が加速し、その担当者が不在になると誰も知らない状況が発生し、原因特定だけで数日かかり保守が回らないようになってくる。 |
| 技術の陳腐化（セキュリティリスク増大等） | ・数年後に、利用しているフレームワークやツールのサポートが終了（EOL）し、セキュリティリスクや互換性の問題が発生する。 ・一部の依存関係が全体に影響を及ぼす事があり、容易に新しい技術を使えないという問題も発生する。 ・この点については、採用面でも影響があり選ばれにくくなる |
上記の観点は、しっかりと関係者間で会話し意思疎通を図っておくことが重要です。
上記について、それぞれざっくりと何年後に起きそうかを試算・検討します。あまり正確な数値はでないので、あくまで現在の延長で捉えた場合に、どこまでの期間だったら耐えられそうかをイメージする程度です。
それが決まればあとは、それぞれについて以下のステップでマイルストーンを策定します。
- 技術負債解消のマイルストーン策定ステップ
- 対象の負債について根本的な解決方針（年単位の大方針）を決める
- 社内の主要な関係者で大方針の合意を形成する
- 上記大方針を月単位の中方針に分解する
- 上記各中方針について、それぞれ担当割当と手遅れにならないスケジュールを設定する
- スケジュールどおりに開発を推進する
単にスケジュールを策定しただけでは、全く説得力がないため当然優先順位も上がりません。一方で手遅れになるタイミングを見定めたスケジュールにすることで、 数年後に大きな問題にならないように今これをやらないといけない ということを説明できるようになるので格段に説得力が増します。
ただ、事業上そうは言っても優先度が上がらないケースはあったりするので、このあたりは事業責任者との継続的な対話が必要な部分となります。
ココナラでも、技術負債への対応は完璧に実現できているわけではありません。そのため、継続的な課題としてどう向き合っていくべきかを検討しています。
余談
ユーザー価値提供を追求することは、副次的な効果も生むことになります。
私は、以下のような良いスパイラルができるようになると考えています。
- ユーザー価値提供ができれば、より多くのユーザーに利用してもらえるようになる
- 利用が加速することで、事業の売上や収益性が改善する
- 収益があがれば、人員や技術への投資もしやすくなり、待遇面も改善する
- 人員や技術への投資が行えれば、よりユーザー価値提供にコミットできるようになる
ユーザー価値提供は、まさに上記のような良いスパイラルを起こしていくための最初の大事な１歩になる部分です。妥協せず常に意識し続けて行くことが重要だと考えています。
今後の展望
本記事では、ユーザー価値提供を中心に据えた開発について、私が日頃意識していることを書き出してみました。
これは抽象的なテーマであり、正解がないもの・会社それぞれのやり方があるものだと思います。
また、一度決めたらそれで終わりではなく、環境の変化に応じて絶えずブラッシュアップしていく必要があるものだと思うので、引き続き刷新していきたいと思います。
さいごに
これで、私たちの初めてのAdvent Calendarが無事に完結しました！
初めての試みで手探りの部分もありましたが、日々新しい記事を公開しながら、チーム全員で知見を共有する楽しさや学びの深さを改めて実感しました。
最後まで読んでいただいた皆様、本当にありがとうございました！
この取り組みが少しでも皆様のお役に立てていれば幸いです。
これからも引き続き、技術やアイデアを発信しながら成長していきたいと思いますので、どうぞよろしくお願いいたします。
それでは、良い年末をお過ごしください！🎄✨
ココナラに興味をもっていただいた方やもっと詳細に話を聞いてみたい方がいましたら、SNS等気軽にご連絡ください。
また現在募集している求人については以下をご確認ください。
カジュアル面談希望の方はこちら。
Discussion