こんにちは。今日は、当ブログでも何度か取り上げたジャーニーマップについて。
このジャーニーマップですが、簡単に言えば、ユーザの体験を図示したものです。本ブログの常連(笑)、みんなの銀行とセブン銀行のネタで一度作成させていただきました。
agile-beginners.hatenablog.com
当時は、教科書通りに書くことを嫌い、かなり改変（というか今見返せば、改悪）してこのブログオリジナルな劣化版ジャーニーマップとして記載しましたが、まぁ、こんな感じです。
正直、当時この劣化版ジャーニーマップを書きながら、こんな感じで本当に良いのか？と違和感はあったのですが、やっぱり間違って描いてたなぁと今更思います。
どういうことかということ、このジャーニーマップは、ユーザの体験に基づき、どのような機能(または組織)やサービスがユーザとタッチポイントを持つのかを示し、リアルな体験を整理するフレームワークです。
したがって、縦軸に機能を並べるのは誤りではないのですが、過去記事のようにそれぞれのユーザの要求に対してバラバラに作成するとおそらく落とし穴にハマる。
もちろん、ユーザの行動に従って、どの機能がどのような「経験」をタッチポイントで提供するのか？を振り返り整理するという目的に使うのはOKです。
しかしながら、それに囚われ過ぎてしまうと、サービス提供側が提供したいサービスに特化したジャーニーマップを作ってしまい、結果として、ユーザにとって不利益な顧客体験が出来上がってしまうのではないか、ということを懸念しています。（これが落とし穴）
具体例で示しましょう。とある一般コンシューマ向けの有償サービスで自分のID /パスワードがわからず、ヘルプデスク/サービスデスクに連絡をしたという状態を考えてください。つまり、L1はユーザIDのリセットサービスを提供している。（今時セルフリセットできるでしょって話は横に置いておいてくださいwww）
そして、この有償サービスプロバイダーは自社の他のサービスも使って欲しいため、コンタクトを取ってくれたすべてのユーザに、どのような追加サービスを提案したらいいか、常に機会を探るという方針のもと、L1は「追加のサービス提案サービス」という内部サービスを自社の事業部門に提供している、という状態です。
ここまで前提。
この時、このユーザはとにかく自分が契約しているサービスを可能な限り早く再度使えるようにしたいはずです。
そして、このサービスプロバイダーのL1は、他のサービスを提案する機会を常に探っている。
では、この「ユーザIDのリセットサービス」と「追加のサービス提案サービス」を何も考えず同時実行するとどうなるか。
サービスが使えず困っているユーザに、IDのリセットサービスを提供する前に、こんなサービスに興味ありますか？とアンケートを取ってしまう。一般的に考えれば、キレます。
いやどう考えてもそんなことありえないと思うのですが、それぞれのサービスを独立して管理し、実行すると、この摩訶不思議な顧客体験は起きる可能性があります。筆者は体験しました。（その企業の名誉のために、社名も具体的なサービス名も明かしませんが）
ただ、この最低最悪な体験は非常に重要な示唆を含んでいると思うのです。
それぞれのサービスを個別に、まるでサイロのように無結合(疎結合でも、密結合でもないという意味)で管理すると、サービスを使えず困っているユーザに別の新規サービスを勧めるというようなことを、無邪気にしてしまう。（感情を害していると言うことにすら気が付かない）
これはユーザにとっても企業にとっても悲劇です。
だからと言って、これを回避するためにジャーニーマップはユーザ視点に立ってサービス提供前に作るべきかと言われると、それもまた違うと思うのです。なぜなら、ユーザ一人一人に合わせてジャーニーマップを作ると膨大になり、費用対効果が釣り合わないためです。
ジャーニーマップの最も効果的な使い方は、大きくは3つ。
- これから作成するサービスに対して、どの機能がどこでどのような顧客体験を提供することが体験を強化、または補完することになるのかをクリアにするために使う（サービスの事前検証）
- 既存サービスによる顧客体験であれば、その経験は意図したものであるかを検証するために使う(既存サービス単体で見た時の事後検証)
- 最後に、増えすぎたサービスが効果効率的な顧客体験を維持しているかを検証するため(サービスのリファクタリングと言う意味合いでの検証。Lessons Learnedに近いかも)
こう、、、サービスの設計文書類として保管し作成物にすると言うより、サービスの現状やサービスとサービスを組み合わせた時の現状の可視化ツールとして使う。それが、ジャーニーマップなのではないか、と思います。
