理論 NEW
サービスデザインとデザイン思考の違いと統合 — UXをビジネス全体に広げる視点
デザイン思考とサービスデザインはしばしば混同されるが、異なる問いに答えるフレームワークだ。「体験の設計」から「体験を支えるシステムの設計」への拡張を、具体例とともに解説する。
8分で読める
「サービスデザインとデザイン思考はどう違うのか」——ワークショップでこの問いが出るたびに、少し立ち止まって考えます。正直、最初から明確な答えを持っている人はほとんどいません。
一行で言うなら：デザイン思考は「何を・なぜ作るか」を問い、サービスデザインは「それを支えるシステムをどう設計するか」を問います。
デザイン思考の焦点：問題定義と解決策の発見
デザイン思考の5フェーズ（共感→定義→発想→プロトタイプ→テスト）は、「正しい問題を見つけ、正しい解決策を発見する」ためのプロセスです。
共感でユーザーの現実を掴み、定義で解くべき問題を絞り込み、あとは発想・試作・テストで形にしていく。出力は「方向性の確信」です。
強みは「点」にあります。「このユーザーが、この状況で、このタスクを完了するとき、どんな体験になるか」——その一点を深く掘ることに集中します。
サービスデザインの焦点：体験を支えるシステム全体の設計
サービスデザインは、「体験がどのように生み出されるか」というシステム全体を設計します。
サービスデザインが扱うのは、顧客が直接触れる「フロントステージ」だけでなく、顧客には見えない「バックステージ」の運営プロセスも含みます。
例えば、ホテルのチェックインという体験を考えます。デザイン思考のアプローチでは、「チェックインカウンターでのユーザー体験をどう改善するか」に集中するかもしれません。サービスデザインのアプローチでは、その体験を支える「予約システムと客室管理システムの連携」「フロントスタッフのトレーニングプログラム」「清掃スタッフのシフト設計」「部屋の準備状況の通知フロー」を一体として設計します。
チェックインの体験は、フロントスタッフのスクリーンに映る情報の質に左右されます。その情報は、どのシステムがどのタイミングで更新するかによって決まります。この「見えないシステム」を設計することがサービスデザインの核心です。
サービスブループリント：バックステージを可視化するツール
サービスデザインの代表的なツールがサービスブループリントです。
サービスブループリントはカスタマージャーニーマップを縦軸方向に拡張したもので、以下の層で構成されます。
- エビデンス：顧客が体験を通じて触れる物理的・デジタルなもの
- 顧客行動：顧客がするアクション
- フロントステージのスタッフ行動：顧客と直接接触するスタッフの行動
- バックステージのスタッフ行動：顧客には見えないスタッフの行動
- サポートプロセス：体験を支えるシステム・IT・プロセス
ワークショップでよく起こるのは、ブループリントを作り始めると「バックステージ」の欄に書くことが見つからないパターンです。実際には、フロントでの1分間の体験の背後に、20-30分分のバックステージプロセスが存在することがほとんどです。これが「書けない」ということは、バックステージが設計されていないことを意味します。
ジャーニーマップ：橋渡しとしての役割
カスタマージャーニーマップは、デザイン思考とサービスデザインの橋渡しとなるツールです。
デザイン思考の文脈では、ジャーニーマップは「共感フェーズで収集したデータを整理し、ユーザーの体験全体を可視化する」ために使います。痛点（Pain Points）や機会（Opportunities）を発見するための分析ツールとして機能します。
サービスデザインの文脈では、ジャーニーマップは「現在の体験のAs-Is」と「設計する体験のTo-Be」を表現するために使います。そして各タッチポイントの「To-Be体験」を支えるバックステージの設計へと展開していきます。
どちらを使うべきか：問いの違いで選ぶ
実際にやってみると、多くのプロジェクトで「デザイン思考とサービスデザインのどちらを使うか」ではなく、「どの段階でどちらの視点が必要か」という問いになります。
| フェーズ | 主に使う視点 |
|---|---|
| 問題を発見・定義する | デザイン思考（共感・定義・発想フェーズ） |
| 解決策をシステムとして設計する | サービスデザイン（ブループリント・プロセス設計） |
| 試作して検証する | デザイン思考（プロトタイプ・テストフェーズ） |
| 本番実装のための組織設計 | サービスデザイン（バックステージの設計・KPI設計） |
実際には、デザイン思考でユーザーインサイトを得て問題を定義し、サービスデザインで解決策をシステムとして実装設計するという組み合わせが最も機能します。
統合の失敗パターン
参加者からの声として多いのは、「デザイン思考でいいアイデアが生まれたのに、実装段階でバックステージの設計が追いつかず、体験が形骸化した」という経験です。
例えば、「チェックインをモバイルアプリで非対面化する」というアイデアが生まれても、清掃完了と客室準備状況をリアルタイムでアプリに反映するシステムがなければ、「アプリからチェックインしたのに部屋に入れない」という最悪の体験が生まれます。
これはデザイン思考が悪いのではなく、「デザイン思考で発見した解決策をサービスデザインで実装設計する」というプロセスが欠けていた結果です。
サービスデザインが開く「組織設計」の視点
サービスデザインのもうひとつの重要な側面は、「体験の質は組織の構造によって決まる」という認識です。
優れた顧客体験を提供するためには、フロントスタッフが必要な情報と権限を持っている必要があります。それは採用・トレーニング・評価システムの設計の問題であり、部門間の情報共有の設計の問題でもあります。
この視点に立つと、「顧客体験の設計」は自動的に「従業員体験（Employee Experience）の設計」と不可分になります。これが、デザイン思考をサービスデザインに統合したときに開かれる、組織変革の視点です。
実践者への示唆：次のプロジェクトに統合する
デザイン思考のワークショップを終えた後、「次のステップ」としてサービスブループリントの作成を提案することで、「アイデアを実装まで持っていく」経験を積めます。
具体的には、デザイン思考の定義フェーズで特定した「最も重要な課題」に対して、その解決策が実際に機能するための「バックステージプロセス」を1枚のブループリントとして描いてみてください。書こうとして書けない部分が、実装の課題を先取りして教えてくれます。
参考文献
- Marc Stickdorn & Jakob Schneider, This Is Service Design Thinking, BIS Publishers, 2011
- Marc Stickdorn et al., This Is Service Design Doing, O’Reilly, 2018
- G. Lynn Shostack, “Designing Services That Deliver”, Harvard Business Review, January–February 1984（サービスブループリントの原論文）
- Nielsen Norman Group, “Service Blueprints: Definition”, nngroup.com, 2017