デザイン思考×サービス開発 実践知

開発チームのためのデザイン思考効果測定とデータ活用の実践

サービス開発の現場でデザイン思考を取り入れる際、多くのエンジニアの方々から「効果が測定しにくい」「開発の意思決定にどう繋げれば良いか分からない」といった声をお聞きします。ユーザー中心のアプローチであるデザイン思考は、その特性上、短期的な成果や定量的な効果が見えづらい側面があるためです。しかし、デザイン思考で得られたインサイトやアイデアを、サービスの成長に繋がる具体的な開発項目として推進していくためには、その成果を適切に測定し、データに基づいた意思決定を行うことが不可欠です。

この記事では、デザイン思考の実践によって得られる成果をどのように定義し、測定し、そして日々の開発業務における意思決定や優先順位付けに活用していくかについて、具体的な方法や考え方をご紹介します。

なぜデザイン思考の成果測定が必要か

デザイン思考は、ユーザーの深い理解に基づき、潜在的なニーズや課題を発見し、革新的な解決策を生み出すプロセスです。このプロセスを通じて、ユーザーにとって真に価値のあるサービスを開発できる可能性が高まります。しかし、その取り組みが単なるアイデア出しやワークショップで終わってしまい、実際のサービス改善や新規機能開発に結びつかないという課題も少なくありません。

成果を測定することには、以下のような重要な意義があります。

• 開発リソースの適切な配分:限られた時間や人員の中で、どのアイデアや機能開発に注力すべきかを判断するための客観的な根拠となります。
• 投資対効果の明確化:デザイン思考にかけた時間やコストが、ユーザー行動の変化やビジネス目標の達成にどれだけ貢献しているかを可視化できます。これにより、経営層や他部門への説明責任を果たしやすくなります。
• チームの共通認識醸成:成果指標を共有することで、開発チームだけでなく、プロダクトマネージャー、デザイナー、マーケターなど、関係者全員が同じ目標に向かって協力する意識を高めることができます。
• 継続的な改善サイクルの構築:測定結果から学びを得ることで、デザイン思考のプロセス自体や、生み出された解決策を継続的に改善していくサイクルを確立できます。

デザイン思考は「作って終わり」ではなく、「作ってユーザーに届け、その反応から学び、改善する」という反復的なプロセスの一部と捉えるべきです。成果測定は、この「学び」の部分を具体化するために不可欠な要素です。

「成果」をどう定義するか：アウトカムに焦点を当てる

デザイン思考における「成果」を考える上で重要なのは、アウトプット（Output）とアウトカム（Outcome）を区別することです。

• アウトプット: デザイン思考の活動自体によって生まれた直接的な成果物。例：ペルソナ、カスタマージャーニーマップ、アイデアリスト、プロトタイプ、ユーザーテストレポートなど。
• アウトカム: ユーザーの行動やサービス・ビジネスにもたらされた間接的でより深い変化。例：ユーザーの利用頻度増加、特定機能の利用率向上、タスク完了率の上昇、顧客満足度の向上、解約率の低下、売上増加など。

私たちが測定し、開発の意思決定に活用すべきは、この「アウトカム」です。デザイン思考で得られたインサイトやアイデアが、実際にユーザーの行動を変え、サービスの成長に貢献しているかを定量・定性的に捉えることが目標となります。

具体的な成果測定指標の例

デザイン思考から生まれたアイデアやプロトタイプを基に開発された機能やサービス改善が、どのようなアウトカムをもたらしたかを測るための指標には、様々なものがあります。以下に、開発チームにとって特に身近な例をいくつか挙げます。

• ユーザー行動に関する指標:

  • 特定のタスク完了率: ユーザーが目的の操作（例: 会員登録、商品購入、問い合わせなど）を完了できた割合。デザイン思考で発見されたユーザーの課題に対する解決策が、使いやすさや分かりやすさを向上させたかを確認できます。
  • 機能利用率/頻度: 新機能や改善された機能が、どれくらいのユーザーに、どれくらいの頻度で利用されているか。ユーザーのニーズに合致しているか、価値を感じてもらえているかの指標となります。
  • 滞在時間/離脱率: 特定のページや機能におけるユーザーの滞在時間や離脱率。ユーザーエンゲージメントの深さを示唆します。
  • 操作ステップ数: 特定のタスク完了までに要する操作ステップ数。プロセス改善による効率化の度合いを測れます。

• ビジネスに関する指標:

  • コンバージョン率 (CVR): サービスや機能の利用を通じて、ユーザーが目標とする行動（購入、申し込みなど）に至った割合。直接的なビジネス貢献度を示す重要な指標です。
  • 解約率 (Churn Rate): ユーザーがサービス利用を停止した割合。ユーザーの継続利用を妨げていたペインポイントの解消や、提供価値の向上が解約率低下に繋がることがあります。
  • 顧客単価 (ARPU: Average Revenue Per User): ユーザー一人あたりの平均収益。新機能によるアップセル/クロスセルへの貢献などを測れます。

• ユーザーからの定性的なフィードバック:

  • ユーザーテストでの発言や行動: プロトタイプや開発済み機能に対するユーザーの生の声や操作中の様子から、課題や評価を収集します。
  • アンケート/インタビュー: サービス利用後や特定の機能利用後などに実施し、満足度や改善点、新たなニーズなどを深掘りします。
  • NPS (Net Promoter Score): ユーザーがサービスを他者に推奨する可能性を測る指標。顧客ロイヤルティの向上度合いを示唆します。
  • App Store/Google Playレビュー、SNS上の言及: 公開されたユーザーの意見を収集し、評価や課題を把握します。

どの指標を追うべきかは、デザイン思考で解決しようとしている具体的な課題や、開発している機能の目的に応じて設定することが重要です。

測定方法とツールの活用

これらの指標を測定するためには、様々なツールや手法を活用します。

• Web/アプリ分析ツール: Google Analytics, Amplitude, Mixpanelなどを用いて、ユーザーの行動データを収集・分析します。特定のイベント計測やファネル分析を設定することで、具体的な行動指標を追跡できます。
• A/Bテストツール: Optimizely, VWOなどを用いて、異なるバージョンのUIや機能を一部のユーザーに提供し、どちらがより高いコンバージョン率や利用率を達成するかを検証します。デザイン思考から生まれた複数のアイデアをデータに基づいて評価するのに有効です。
• ヒートマップ/セッションリプレイツール: Hotjar, FullStoryなどを用いて、ユーザーがページ上でどのようにマウスを動かしているか、どこをクリックしているか、どのようにスクロールしているかなどを可視化します。ユーザーの実際の利用状況を詳細に把握し、デザインやレイアウトの課題発見に役立ちます。
• ユーザーテストプラットフォーム: UserTesting.com, Lookbackなどを用いて、リモートまたは対面でユーザーテストを実施・記録します。ユーザーがプロトタイプや機能を操作する様子を観察し、直接フィードバックを得ます。
• アンケートツール: Google Forms, SurveyMonkey, Typeformなどを用いて、構造化されたアンケートを実施し、定性・定量の両面からユーザーの意見を収集します。
• カスタマーサポート/フィードバック収集ツール: Zendesk, Intercomなどや、サービス内に設置したフィードバックフォームを通じて、ユーザーからの問い合わせや意見を集約・分析します。

開発チームは、これらのツールから得られるデータを読み解き、デザイン思考で得られたインサイトや仮説と照らし合わせるスキルを磨くことが求められます。

測定結果を開発の意思決定に繋げるプロセス

デザイン思考の成果測定は、単にデータを集めること自体が目的ではありません。測定結果を分析し、そこから得られた学びやインサイトを、今後の開発の意思決定に効果的に繋げることが最も重要です。

1. 目標設定と仮説構築: デザイン思考の定義フェーズやアイデア出しフェーズで特定されたユーザー課題やニーズに基づき、「この機能改善（または新機能）によって、ユーザーのこの行動が、このように変化するだろう」という具体的な仮説を立てます。そして、その仮説の成否を判断するための明確な成果指標（KPI: Key Performance Indicator）を設定します。 例：「ユーザーが特定のタスクを完了するまでのステップ数を削減することで、完了率がX%向上する」

2. 計測設計と実装: 設定したKPIを測定するために必要なデータ計測の仕組みを設計し、開発に組み込みます。分析ツールでのイベントトラッキング設定や、A/Bテストの実装などがこれにあたります。開発の初期段階で計測設計を行うことが、後から効率的にデータを収集するために重要です。

3. 開発とリリース: デザイン思考で生まれたアイデアやプロトタイプを基に、機能を開発し、ユーザーにリリースします。この際、一度に完璧なものを作ろうとせず、仮説検証に必要な最小限の機能（MVP: Minimum Viable Product）からリリースすることも有効です。

4. データ収集と分析: 機能リリース後、設定したKPIやその他の関連データを収集し、分析ツールを用いてユーザーの行動を詳細に分析します。収集したデータが、当初立てた仮説を支持するのか、反証するのかを検証します。

5. インサイト抽出と学習: データ分析の結果から、ユーザーが実際にどのようにサービスを利用しているのか、どのような課題に直面しているのかといった、新たなインサイトや学びを抽出します。仮説が間違っていた場合でも、その原因を深掘りし、なぜユーザーの行動が期待通りにならなかったのかを理解することが重要です。これは次のデザイン思考や開発のインプットとなります。

6. 開発バックログへの反映: 得られたインサイトや学びを基に、今後の開発ロードマップやバックログを見直します。「ユーザーがこの機能でつまずいているから、UIを改善しよう」「この機能の利用率が高いので、さらに発展させよう」「想定と異なる行動が見られたため、ユーザーインタビューで深掘りしよう」といった形で、具体的な開発タスクやデザイン思考の次なる活動に落とし込みます。この際、データやユーザーのフィードバックという客観的な根拠に基づいていることが、チーム内での合意形成を円滑に進める上で役立ちます。

このプロセスを継続的に繰り返すことで、デザイン思考で得られたユーザー中心の視点と、データに基づいた合理的な意思決定を両立させ、サービスの質を着実に向上させていくことができます。

チーム全体での実践と共通理解

デザイン思考の成果測定とデータ活用は、特定の担当者だけでなく、開発チーム全体で取り組むべき課題です。

• 共通言語の確立: デザイナー、プロダクトマネージャー、エンジニアなど、チームメンバー間で共通の目標指標（KPI）を持ち、データ分析の結果やユーザーのフィードバックについて対話する機会を設けます。
• データへのアクセスと理解促進: チームメンバーが必要なデータにアクセスできる環境を整備し、データの読み解き方や分析結果の意味について共有会などを開催します。
• 「なぜ」を問う文化: 開発する機能が「なぜ」ユーザーに価値を提供するのか、「なぜ」特定の指標に貢献するのかを常に問い、共通認識を持つようにします。
• 振り返りの実施: スプリントレビューや定期的なミーティングで、開発した機能の成果指標を確認し、ユーザーの反応やデータから何を学んだかをチーム全体で共有します。

エンジニアは、データ計測の実装や分析環境の構築、そして分析結果を技術的な実現可能性と照らし合わせながら、意思決定プロセスに貢献することができます。

実践上の注意点とヒント

• 完璧を目指さない: 最初から全ての指標を完璧に測定しようとせず、最も重要と思われるいくつかの指標から計測を開始します。
• 計測しやすい設計を考慮: 開発段階で、将来的なデータ計測やA/Bテストの実施を考慮した設計を取り入れることで、後々の工数を削減できます。
• 定量と定性の両面から捉える: 数字として現れる定量データだけでなく、ユーザーテストでの声やアンケートの自由記述といった定性的なフィードバックも重視し、なぜその数字になったのか、ユーザーはどのように感じているのかを理解するように努めます。
• 失敗を恐れない: 設定した仮説がデータによって否定されたとしても、それは貴重な学びです。失敗からインサイトを得て、次の挑戦に繋げることがデザイン思考の本質でもあります。
• 小さなサイクルで回す: アジャイル開発のスプリントに合わせるなど、短いサイクルで「開発→リリース→測定→学習」を回すことで、素早く仮説検証を進めることができます。

まとめ

デザイン思考をサービス開発の現場で真に活かすためには、単にユーザーの課題を発見したり、斬新なアイデアを生み出したりするだけでなく、それが実際のユーザー行動やビジネス成果にどのように結びついているのかを測定し、そこから得られる学びを次の開発に繋げていくプロセスが不可欠です。

デザイン思考によって特定されたユーザー課題やニーズに対する解決策が、実際にどのようなアウトカムをもたらしたのかを、定量・定性の両面から測定します。そして、その測定結果を客観的な根拠として、開発ロードマップの検討、機能の優先順位付け、リソース配分の判断といった日々の意思決定に活用します。

この実践を通じて、開発チームはユーザー中心の視点を保ちつつ、データに基づいた合理的な判断を下せるようになります。これは、不確実性の高いサービス開発において、手戻りを減らし、サービスの成功確率を高めることに繋がります。デザイン思考で得られたインサイトを「ふわふわしたもの」で終わらせず、データという確かな根拠と結びつけることで、サービスの成長を加速させていきましょう。