カスタマージャーニーマップとは、ウェブサイトやサービスを利用する顧客がどのようなプロセスで、どのようなタッチポイントをもって、どのような感情と思考をもってどのような体験をするのかを1枚絵のように視覚化したものです。その名の通り、「顧客(カスタマー)の旅(ジャーニー)をしるした地図(マップ)」です。
メジャーな手法ですので、ここで詳細な説明は行いませんが、ユーザーの感情や行動が全体像として図解されていることや、図解ゆえに関係者が集まって議論しやすいなどの利点があるため、サービス企画やウェブサイト制作時によく使われる手法です。
私たちギルドワークスでもユーザーの動きを見立てる方法として、カスタマージャーニーマップを利用しています。ユーザーストーリーマッピング、サービスブループリントなども利用していますが、カスタマージャーニーマップはユーザーの感情や思考やモチベーションも関連させられるところが優れているのではないかと思っています。
きれいなカスタマージャーニーマップを描けたらモテる…そう信じていた時代が私にもありました…
私自身にはかつて、カスタマージャーニーマップを美しく描くこと、誰もが見て納得できるものにすること、プロジェクトの経典のようなものにすること、などを目指していた時期がありました。今はわりと雑に…言い換えるとわりとざっくばらんに行っております。カスタマージャーニーマップを見ながらご飯を食べたりするのでたまにごはんつぶがついてたりします。

方向転換をしたのは、顧客にとって価値があるのは、カスタマージャーニーマップ自体ではなくて、それを含めた仮説検証の結果、市場に投下されたプロダクトであるということを実感してからです。カスタマージャーニーマップはプロダクトの前段階。誰が何をどう使うから、何をどう作るか、の「見立て」にすぎないので、意義は大いにあるものの、これだけをレビューしてもしかたがない。やわらかい中間生成物という感じで扱っています。
つまり、ユーザーにその価値を問えないものであるカスタマージャーニーマップに時間とリソースを割いてしっかり作りこむより、これも仮説のひとつとして、見立てられたものをその次のプロセスに素早くのせたい、という意図があります。その次のプロセスとは、エンジニアによるコードだったり、デザイナーによるUIデザインだったりしますが、小さくても動くプロダクトに結びつけるほうが、プロダクトを市場に問う、顧客のもつ価値を実現するという目的においては得策でしょう。
そう考えると、むしろ、カスタマージャーニーマップはダメであればダメであるほどよいのではないでしょうか。なぜなら、プロダクト開発において失敗が許されるのは、「仮説」だけだからです。
机上にあるものこそバンバン失敗してよい
プロダクト開発には大変なコストがかかります。この開発コストの前に、小さい失敗を繰り返して「確からしさ」を備えていきましょうというのが仮説検証です。
ユーザーはどんな人たちなのか? どんな感情をもっているのか? どんなタッチポイントで、どんな行動をとるのか?これらは「どうやらこれが確からしいぞ」という見立てでしかなく、これ自体がそもそも大きくズレていたとか、他にも何十個も見立てられていないものがあったとか、それよりこっちのほうが事業としてはダメージ大きかったとか、あとからいくらでも出てきます。
ですので、つくる前の「仮説」で失敗しておくことはプラスになります。考え方としてはプロトタイピングと近しいものがあるかもしれません。「やわらかい中間生成物」と称したのは、これ自体はいくらでも変わるし、あとからわかったことでいくらでも潰しても凹ませてもいいものだからです。完璧なカスタマージャーニーマップを作ろうとしたところで、しょせん仮説ですから、「正しくないと私たちが困る」になってしまい、なんだかあやしくないでしょうか。カスタマージャーニーマップはユーザーの動きをユーザーの目線で見立てるものなのに、逆に自分たちの考えに沿って・都合のいいように、ユーザーの動きを組み立ててしまうことになりはしないでしょうか。
1枚の絵とインタラクション
「見立てとはいえ、成果物としてきちんとしたものを作らねばならない」と、かつての私は思い込んでいました。じゃあ成果物ってなんなのよという話になりますと、プロダクトは人の手にわたって動いたときに、はじめて「成果物」と呼べるのではないかと考えています。
美しい1枚絵としてのカスタマージャーニーマップは、たしかにそこに美しくそのようにしてあることは成果のひとつとして呼びようもあるのですが、机上にあるこのマップはユーザーに使われるものではありませんし、ユーザーとのインタラクションがのぞめるものでもありません。
机上にあるものはやわらかな仮説です。ユーザーとのインタラクションのために仮説をコードとして、あるいはUIデザインとして動かしてみることで、その仮説がさらに深まったり、または、大きくピボットしたり、気づくことが多いのではないでしょうか。
そんな風に考えるので、カスタマージャーニーマップはバンバン失敗してよく、この手法の実践が大切であるこということでもなく、「ユーザーってどんな人なんだろう」「どんな動きをするんだろう」と、つくる私たちが問うことが、重要なのではないかと思います。
なお、訓練のおかげで、私は妄想していたようなきれいなカスタマージャーニーマップも描けるようになりましたが、べつにモテません。
この記事もどうですか?
-
AWSクレデンシャルの漏洩を未然に防ぐgit-secrets
この記事は、 ギルドワークス アドベントカレンダー の10日目の記事です。 業務でAWSを触ることもあり、AWSクレデンシャル情報に触れる機会も増えてきました。 AWSアクセスキーの漏洩の話を聞くこともときどきあり、漏洩を未然に防ぐために …
-
TDD Kataのすゝめ
この記事は、 ギルドワークス アドベントカレンダー の三日目の記事です。 テスト駆動開発は難しい テスト駆動開発とは、もう殆どの皆さんには説明の必要はないでしょうが、 テストを先に書き、その後に実装を行う という開発方法です。テスト駆動開発…
- TDD
-
普段の作業を少し楽にするコマンドラインツール
この記事は、 ギルドワークスアドベントカレンダー の記事です。 突然ですが、 プログラマの三大美徳 を皆さんご存知でしょうか? 怠惰・短気・傲慢 という、普通だと美徳ではいえないような性質を指します。その心は、ちょっとでも無駄な作業をなくし…