レッスン7：サービスデザインとブループリント——裏側まで含めて設計する

このレッスンで学ぶこと

画面の外側で体験が壊れる理由を理解する
サービスブループリントの 4 つの層を説明できる
サービスブループリントを使って、部門をまたぐ設計上の課題を洗い出せる
既存業務の制約と折り合いをつけながら設計を進める考え方を身につける

レッスン6では、設計の前提としてのアクセシビリティを学びました。ここまでのレッスンは、主に画面という「見える部分」を中心に扱ってきました。しかし、利用者の体験は、画面の中だけで完結しているわけではありません。このレッスンでは視点を広げ、画面の裏側にある業務や仕組みまで含めて設計する「サービスブループリント」を扱います。

画面の外側で体験が壊れる

どれほど画面の設計が優れていても、その裏側にある業務や仕組みが整っていなければ、利用者の体験は途中で壊れてしまいます。具体的な場面で考えてみましょう。

ある申請システムで、利用者は画面上の案内どおりに、迷うことなく申請を完了できたとします。ここまでは、レッスン4と 5 で学んだ情報設計と仕様の書き方が功を奏している状態です。ところが、その申請を受け取った社内の担当者が、旧来の紙の業務フローに合わせて処理をしているため、確認の返答が 2 週間も届かないとします。利用者から見れば、「申し込みはスムーズだったのに、その後は何も起きない」という不満の残る体験になります。

この例が示すのは、画面の中だけを見ていては、体験全体の質を保証できないという事実です。利用者が実際に触れる画面は、体験というものの、ごく一部の断面にすぎません。画面の向こう側には、それを支える業務や、担当者、システム間の連携が存在しています。この裏側までを含めて設計する視点が、サービスデザインと呼ばれる考え方です。

もう 1 つ、別の場面でも確認してみましょう。ある窓口では、利用者からの問い合わせに対応するチャット機能を新しく導入しました。画面上のチャットの返答は、文言も丁寧で、表示速度も申し分ありません。しかし、チャットの裏側では、担当者が複数の別システムを行き来しながら情報を探しているため、1 件の問い合わせに答えるまでに長い沈黙が生まれていました。利用者から見れば、「返答は丁寧なのに、なぜか待たされる」という体験です。ここでも、画面の質と、それを支える裏側の仕組みの質は、別々に評価しなければならないことがわかります。

💡 ポイント 画面の使いやすさを高める取り組みは、それだけでは不十分です。画面の先にある業務が整っていなければ、利用者が感じる不満の根本原因は残ったままになります。

サービスブループリントとは

サービスデザインの視点を、具体的な図として書き表す手法が、サービスブループリントです。サービスブループリントの発想は、1980 年代に発表された、サービス設計に関する考察に遡るとされています。画面や接点だけでなく、それを支える裏側の業務までを 1 枚の図に並べて可視化する点が、大きな特徴です。

サービスブループリントは、次の 4 つの層で構成されます。

利用者の行動：利用者が実際に何をするかという行動の流れ
目に見える接点：利用者から見える画面や、人とのやり取りなど、利用者と直接触れる部分
裏側の業務：目に見える接点を支えるために、社内の担当者が行う業務
支援する仕組み：裏側の業務をさらに支える、システムや制度、外部の連携先

flowchart TD
    subgraph L1["利用者の行動"]
        A1[申請内容を入力する] --> A2[送信する] --> A3[確認の連絡を待つ]
    end
    subgraph L2["目に見える接点"]
        B1[入力画面] --> B2[送信完了画面] --> B3[確認メール]
    end
    subgraph L3["裏側の業務"]
        C1[担当者が内容を確認する] --> C2[担当者が承認処理を行う] --> C3[担当者が確認メールを送る]
    end
    subgraph L4["支援する仕組み"]
        D1[申請管理システム] --> D2[承認の権限設定] --> D3[メール配信の仕組み]
    end
    A1 -.-> B1
    A2 -.-> B2
    A3 -.-> B3
    B1 -.-> C1
    B2 -.-> C2
    B3 -.-> C3
    C1 -.-> D1
    C2 -.-> D2
    C3 -.-> D3

この図は、申請から確認までの一連の流れを、4 つの層に分けて示しています。上から下に向かって、利用者に近い層から、それを支える裏側の層へと並んでいます。それぞれの層の要素は、点線でつながっており、利用者の行動が、どの接点を経て、どの裏側の業務に支えられているかを追うことができます。

📝 補足 サービスブループリントは、1 回作って終わりにするものではありません。業務の変更やシステムの更新があるたびに見直し、常に実態に近い状態を保つことで、初めて設計の役に立つ道具になります。

サービスブループリントの作り方

サービスブループリントを実際に描く手順を、段階を追って確認しましょう。

対象とする範囲を決める：利用者が最初に接点を持つ場面から、目的を達成し終える場面まで、どこからどこまでを描くかを決める。範囲を広げすぎると、1 枚の図にまとめきれなくなる
利用者の行動を書き出す：想像ではなく、観察や記録にもとづいて、利用者が実際に取る行動を時系列で並べる
目に見える接点を対応させる：利用者の行動の 1 つずつに対して、それに対応する画面ややり取りを書き出す
裏側の業務を洗い出す：それぞれの接点を成立させるために、社内でどのような業務が行われているかを、担当者への聞き取りをもとに書き出す
支援する仕組みを確認する：裏側の業務を支えているシステムや制度、外部の連携先を書き出す
層をまたぐつながりを線でつなぐ：利用者の行動から支援する仕組みまで、どの要素がどの要素と結びついているかを線で示す

この手順で難しいのは、4 番目の裏側の業務を洗い出す段階です。画面を担当する部門だけでは、裏側の業務の詳細まで把握しきれないことが多く、担当する部門の協力が欠かせません。最初から完璧な図を目指さず、わかる範囲を書き出し、空白のまま残った部分を、関係者への確認を通じて少しずつ埋めていく進め方が現実的です。

図を完成させる過程では、層と層のあいだの「つながりが見えない箇所」に、特に注意を払いましょう。利用者の行動と、それに対応する接点が見つからない箇所、接点と、それを支える裏側の業務が見つからない箇所は、担当が曖昧なまま放置されている可能性を示しています。空白そのものが、貴重な発見になることも珍しくありません。

🔰 初学者の方へ 最初のサービスブループリントは、大きな模造紙や、共同で編集できる文書に、付箋や短い文で書き出していく形で十分です。きれいに整えることよりも、まず全体を書き出してみることを優先しましょう。

4 つの層を 1 つずつ確認する

4つの層を、それぞれもう少し詳しく確認しましょう。

利用者の行動

利用者が、目的を達成するまでに実際に取る行動を、時系列で並べたものです。レッスン3で扱ったユーザビリティテストや、レッスン1で扱った観察の考え方が、この層を正確に描くための材料になります。想像だけで行動を書き出すのではなく、実際の観察にもとづいて描くことが望まれます。

目に見える接点

利用者が直接触れる部分です。画面だけでなく、窓口での対面のやり取り、電話でのやり取り、送られてくるメールや通知など、利用者が「相手からの反応」として認識するものすべてが含まれます。レッスン4と 5 で扱った情報設計や仕様の書き方は、主にこの層の質を高めるための技法にあたります。

裏側の業務

目に見える接点を成立させるために、組織の内部で行われている業務です。担当者による確認作業、承認の手続き、部署間での情報の受け渡しなどが該当します。この層は、利用者からは直接見えないため、これまで設計の対象として意識されにくい部分でした。

支援する仕組み

裏側の業務をさらに支える、システムや制度、外部の連携先です。業務で使われている情報システム、承認の権限を定めた社内規程、外部の取引先とのやり取りの仕組みなどが含まれます。この層に制約があると、裏側の業務も、その上の接点や利用者の行動も、思うように改善できないことがあります。

🔰 初学者の方へ 4 つの層を初めて描くときは、完璧を目指さず、まず知っている範囲でざっくりと書き出してみましょう。書き出してみることで、自分たちがどの層について詳しく知らないかが、かえって明確になります。

部門をまたぐ設計

サービスブループリントを描く作業には、大きな副次的効果があります。それは、1 つの部門だけでは全体を描き切れないという事実に、関係者自身が気づく点です。

画面を担当する部門は、目に見える接点についてはよく把握していますが、裏側の業務がどう動いているかまでは、詳しく知らないことが少なくありません。逆に、裏側の業務を担当する部門は、日々の業務には精通していても、利用者が画面上でどのような行動を取っているかまでは、把握していないことがあります。

サービスブループリントを、複数の部門の担当者が集まって一緒に描くことで、それぞれが把握している範囲を持ち寄り、全体像を 1 枚の図として完成させることができます。この過程そのものが、部門をまたいだ共通理解を作る機会になります。

⚠️ 注意 部門をまたいで議論を進める際、それぞれの部門が「自分たちの業務に問題はない」という前提で話し始めると、議論が対立的になりがちです。目的は誰かの落ち度を指摘することではなく、利用者にとっての体験がどこで途切れているかを、全員で確かめることにあると、最初に共有しておくことが大切です。

具体的な進行の例を見てみましょう。画面を担当する部門の担当者が「送信完了画面まではスムーズに進んでいる」と発言したとします。ここに、裏側の業務を担当する部門の担当者が「実は、確認の処理には毎回 1 週間ほどかかっている」と加えると、これまで別々に把握されていた情報が、初めて 1 つの図の上でつながります。どちらの部門も、自分たちの担当範囲では問題を認識していなかったかもしれませんが、2 つの情報を並べることで、「送信は早いのに確認が遅い」という、利用者から見た体験全体の課題が浮かび上がります。

この浮かび上がった課題に対して、画面を担当する部門は「確認にかかる日数を、送信完了画面で伝えられないか」と提案でき、裏側の業務を担当する部門は「処理の順番を見直せば、日数を短縮できるかもしれない」と検討を始められます。1 つの図を挟むことで、これまで別々に動いていた部門が、同じ課題に向けて協力できるようになります。

既存業務の制約とどう折り合うか

サービスブループリントを描くと、しばしば、裏側の業務や支援する仕組みに大きな制約が見つかります。長年運用されてきた業務の手順や、簡単には変更できない社内規程、外部の取引先との契約上の制約などです。

こうした制約が見つかったとき、すべてを一度に取り払おうとすると、現実的ではない大がかりな計画になってしまいます。まず取り組むべきは、制約そのものを取り払うことではなく、制約がある中でも、利用者から見える接点をどう補えるかを考えることです。

先ほどの申請システムの例で言えば、裏側の承認業務の手順そのものをすぐに変えられない場合でも、「確認までに、通常どのくらいの日数がかかるか」を、送信完了画面の時点で利用者に伝えることはできます。裏側の業務が変わらなくても、目に見える接点の側で、利用者の不安を減らす工夫は可能です。

制約を根本から解消する取り組みと、制約がある中で接点の側から補う取り組みは、対立するものではありません。短期的には後者で応急的に対応しつつ、中長期的には前者に向けて、関係部門との調整を進めるという、2 段階の進め方が現実的です。

💡 ポイント サービスブループリントは、裏側の業務まですべてを一度に作り変えるための計画書ではありません。まずは、現状のどこに体験の途切れがあるかを可視化し、短期と中長期、それぞれでできることを整理するための道具として使いましょう。

制約の種類も、あらかじめ整理しておくと、折り合いのつけ方を考えやすくなります。

手順の制約：長年決まった順序で行われてきた業務手順。変更には関係者の合意形成が必要になる
規程の制約：社内規程や承認権限の定めによるもの。変更には正式な手続きが必要になる
外部との契約の制約：取引先や委託先との契約条件によるもの。自社の判断だけでは変更できない
人員の制約：業務にあたる人数や、専門知識を持つ担当者の数によるもの。短期間での増強が難しい

制約の種類によって、解消にかかる時間も、必要な調整の相手も異なります。手順の制約であれば、比較的短期間で見直せる可能性がありますが、外部との契約の制約は、交渉や契約更新のタイミングを待つ必要があり、時間がかかります。サービスブループリントを描く段階で、見つかった制約がどの種類に当たるかを整理しておくと、次のレッスンで扱う改善提案の優先順位づけにも役立ちます。

flowchart LR
    subgraph Before["現状"]
        direction TB
        b1[送信完了画面] --> b2[担当者が確認]
        b2 --> b3[1 週間後に連絡]
    end
    subgraph After["接点側の応急対応"]
        direction TB
        a1[送信完了画面] --> a2[目安日数を表示]
        a2 --> a3[担当者が確認]
        a3 --> a4[1 週間後に連絡]
    end
    Before -.応急対応として.-> After

この図は、裏側の確認業務そのものはすぐに変えられない状況でも、目に見える接点の側に「目安日数を表示する」という一手を加えるだけで、利用者が抱える不安を和らげられることを示しています。裏側の制約を解消する取り組みと並行して、こうした接点側の応急対応を組み合わせることが、現実的な進め方です。

サービスブループリントとユーザビリティテストの組み合わせ

サービスブループリントは、それ単体で完結する手法ではありません。レッスン3で扱ったユーザビリティテストと組み合わせることで、より実態に近い図を描けます。

利用者の行動の層は、想像だけで描くと、担当者の思い込みが混ざり込みやすい部分です。実際に利用者を観察し、思考発話法で得られた発言を、行動の層に反映させることで、より正確なサービスブループリントに近づきます。同様に、裏側の業務の層も、担当者への聞き取りや、実際の業務記録を確認することで、想像ではなく実態にもとづいた図に仕上げることができます。

観察にもとづいて描かれたサービスブループリントは、単なる理想図ではなく、いまどこで体験が途切れているかを示す、根拠のある地図になります。この地図があることで、次のレッスンで扱う、組織的な改善提案の土台を作ることができます。

裏側の業務についても、同じ姿勢が求められます。担当者に「業務の手順を教えてください」とだけ尋ねると、本来あるべき手順、つまり建前としての手順が語られることがあります。実際には、その手順どおりに進まない例外的な対応が日常的に発生している場合も少なくありません。可能であれば、担当者への聞き取りに加えて、実際の業務の様子を見せてもらう、あるいは記録として残っているやり取りを確認するなど、複数の方法で実態を確かめることが、精度の高いサービスブループリントにつながります。

📖 もっと詳しく サービスブループリントを描く作業自体が、社内で「利用者の視点から自分たちの業務を見直す」という経験を、関係者にもたらします。図が完成すること自体よりも、この見直しの経験を関係者と共有できることに、大きな価値があると捉えるとよいでしょう。

まとめ

このレッスンでは、以下のことを学びました。

画面の設計がどれほど優れていても、裏側の業務が整っていなければ、利用者の体験は途中で壊れてしまう
サービスブループリントは、利用者の行動・目に見える接点・裏側の業務・支援する仕組みという 4 つの層で構成される
サービスブループリントを複数の部門で一緒に描くことで、部門をまたいだ共通理解を作れる
既存業務の制約は、一度にすべて取り払おうとせず、短期的な接点の工夫と中長期的な調整を組み合わせて折り合いをつける
サービスブループリントは、ユーザビリティテストなど観察にもとづく情報と組み合わせることで、実態に近い地図になる

次のレッスンでは、ここまで学んできた技法を単発の改善で終わらせず、組織で測り続ける仕組みへとつなげる方法を扱います。改善提案を通すための書き方や、UX を継続的に運用する視点まで、本コースの締めくくりとして学びます。

確認クイズ

このレッスンの理解度をチェックしましょう。