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

方向転換をしたのは、顧客にとって価値があるのは、カスタマージャーニーマップ自体ではなくて、それを含めた仮説検証の結果、市場に投下されたプロダクトであるということを実感してからです。カスタマージャーニーマップはプロダクトの前段階。誰が何をどう使うから、何をどう作るか、の「見立て」にすぎないので、意義は大いにあるものの、これだけをレビューしてもしかたがない。やわらかい中間生成物という感じで扱っています。
つまり、ユーザーにその価値を問えないものであるカスタマージャーニーマップに時間とリソースを割いてしっかり作りこむより、これも仮説のひとつとして、見立てられたものをその次のプロセスに素早くのせたい、という意図があります。その次のプロセスとは、エンジニアによるコードだったり、デザイナーによるUIデザインだったりしますが、小さくても動くプロダクトに結びつけるほうが、プロダクトを市場に問う、顧客のもつ価値を実現するという目的においては得策でしょう。
そう考えると、むしろ、カスタマージャーニーマップはダメであればダメであるほどよいのではないでしょうか。なぜなら、プロダクト開発において失敗が許されるのは、「仮説」だけだからです。
机上にあるものこそバンバン失敗してよい
プロダクト開発には大変なコストがかかります。この開発コストの前に、小さい失敗を繰り返して「確からしさ」を備えていきましょうというのが仮説検証です。
ユーザーはどんな人たちなのか? どんな感情をもっているのか? どんなタッチポイントで、どんな行動をとるのか?これらは「どうやらこれが確からしいぞ」という見立てでしかなく、これ自体がそもそも大きくズレていたとか、他にも何十個も見立てられていないものがあったとか、それよりこっちのほうが事業としてはダメージ大きかったとか、あとからいくらでも出てきます。
ですので、つくる前の「仮説」で失敗しておくことはプラスになります。考え方としてはプロトタイピングと近しいものがあるかもしれません。「やわらかい中間生成物」と称したのは、これ自体はいくらでも変わるし、あとからわかったことでいくらでも潰しても凹ませてもいいものだからです。完璧なカスタマージャーニーマップを作ろうとしたところで、しょせん仮説ですから、「正しくないと私たちが困る」になってしまい、なんだかあやしくないでしょうか。カスタマージャーニーマップはユーザーの動きをユーザーの目線で見立てるものなのに、逆に自分たちの考えに沿って・都合のいいように、ユーザーの動きを組み立ててしまうことになりはしないでしょうか。
1枚の絵とインタラクション
「見立てとはいえ、成果物としてきちんとしたものを作らねばならない」と、かつての私は思い込んでいました。じゃあ成果物ってなんなのよという話になりますと、プロダクトは人の手にわたって動いたときに、はじめて「成果物」と呼べるのではないかと考えています。
美しい1枚絵としてのカスタマージャーニーマップは、たしかにそこに美しくそのようにしてあることは成果のひとつとして呼びようもあるのですが、机上にあるこのマップはユーザーに使われるものではありませんし、ユーザーとのインタラクションがのぞめるものでもありません。
机上にあるものはやわらかな仮説です。ユーザーとのインタラクションのために仮説をコードとして、あるいはUIデザインとして動かしてみることで、その仮説がさらに深まったり、または、大きくピボットしたり、気づくことが多いのではないでしょうか。
そんな風に考えるので、カスタマージャーニーマップはバンバン失敗してよく、この手法の実践が大切であるこということでもなく、「ユーザーってどんな人なんだろう」「どんな動きをするんだろう」と、つくる私たちが問うことが、重要なのではないかと思います。
なお、訓練のおかげで、私は妄想していたようなきれいなカスタマージャーニーマップも描けるようになりましたが、べつにモテません。
この記事もどうですか?
-
トレードオフスライダーで「基準」の可視化を行なう
ギルドワークス市谷です。 プロジェクトを始める際にやるべきこととして 「インセプションデッキ」 づくりがあります。アジャイルサムライで紹介されてから数年が経ちますが、未だその意義が色褪せることはありません。タイミングにより作り損ねてしまった…
-
ギルドワークスに参加して、プロダクトづくりの価値観が変わりました 〜 ギルドメンバーインタビュー Vol.1 ソフトウェアエンジニア兼プロダクトオーナー見習い Takahashi Toshiaki 〜
ギルドワークスのなかにはいったいどんな人がいて、いま何を考えているのか…メンバーのリアルな姿をインタビューを通してお伝えします。 第一回目は、ソフトウェアエンジニア兼プロダクトオーナー見習いTakahashi Toshiakiが登場。時節柄…
-
「場合分け」の書き方あれこれ
ギルドワークスの増田です。 以前に書いた リファクタリングのエッセンス の続編です。 場合ごとのロジックの書き分け(条件分岐)は、プログラミングの基本ですね。if-then-else 構文は、良く使われる「場合分け」の記述方法です。 今回は…