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

方向転換をしたのは、顧客にとって価値があるのは、カスタマージャーニーマップ自体ではなくて、それを含めた仮説検証の結果、市場に投下されたプロダクトであるということを実感してからです。カスタマージャーニーマップはプロダクトの前段階。誰が何をどう使うから、何をどう作るか、の「見立て」にすぎないので、意義は大いにあるものの、これだけをレビューしてもしかたがない。やわらかい中間生成物という感じで扱っています。
つまり、ユーザーにその価値を問えないものであるカスタマージャーニーマップに時間とリソースを割いてしっかり作りこむより、これも仮説のひとつとして、見立てられたものをその次のプロセスに素早くのせたい、という意図があります。その次のプロセスとは、エンジニアによるコードだったり、デザイナーによるUIデザインだったりしますが、小さくても動くプロダクトに結びつけるほうが、プロダクトを市場に問う、顧客のもつ価値を実現するという目的においては得策でしょう。
そう考えると、むしろ、カスタマージャーニーマップはダメであればダメであるほどよいのではないでしょうか。なぜなら、プロダクト開発において失敗が許されるのは、「仮説」だけだからです。
机上にあるものこそバンバン失敗してよい
プロダクト開発には大変なコストがかかります。この開発コストの前に、小さい失敗を繰り返して「確からしさ」を備えていきましょうというのが仮説検証です。
ユーザーはどんな人たちなのか? どんな感情をもっているのか? どんなタッチポイントで、どんな行動をとるのか?これらは「どうやらこれが確からしいぞ」という見立てでしかなく、これ自体がそもそも大きくズレていたとか、他にも何十個も見立てられていないものがあったとか、それよりこっちのほうが事業としてはダメージ大きかったとか、あとからいくらでも出てきます。
ですので、つくる前の「仮説」で失敗しておくことはプラスになります。考え方としてはプロトタイピングと近しいものがあるかもしれません。「やわらかい中間生成物」と称したのは、これ自体はいくらでも変わるし、あとからわかったことでいくらでも潰しても凹ませてもいいものだからです。完璧なカスタマージャーニーマップを作ろうとしたところで、しょせん仮説ですから、「正しくないと私たちが困る」になってしまい、なんだかあやしくないでしょうか。カスタマージャーニーマップはユーザーの動きをユーザーの目線で見立てるものなのに、逆に自分たちの考えに沿って・都合のいいように、ユーザーの動きを組み立ててしまうことになりはしないでしょうか。
1枚の絵とインタラクション
「見立てとはいえ、成果物としてきちんとしたものを作らねばならない」と、かつての私は思い込んでいました。じゃあ成果物ってなんなのよという話になりますと、プロダクトは人の手にわたって動いたときに、はじめて「成果物」と呼べるのではないかと考えています。
美しい1枚絵としてのカスタマージャーニーマップは、たしかにそこに美しくそのようにしてあることは成果のひとつとして呼びようもあるのですが、机上にあるこのマップはユーザーに使われるものではありませんし、ユーザーとのインタラクションがのぞめるものでもありません。
机上にあるものはやわらかな仮説です。ユーザーとのインタラクションのために仮説をコードとして、あるいはUIデザインとして動かしてみることで、その仮説がさらに深まったり、または、大きくピボットしたり、気づくことが多いのではないでしょうか。
そんな風に考えるので、カスタマージャーニーマップはバンバン失敗してよく、この手法の実践が大切であるこということでもなく、「ユーザーってどんな人なんだろう」「どんな動きをするんだろう」と、つくる私たちが問うことが、重要なのではないかと思います。
なお、訓練のおかげで、私は妄想していたようなきれいなカスタマージャーニーマップも描けるようになりましたが、べつにモテません。
この記事もどうですか?
-
自分の活動を見える化する「色つき星取表」
この記事は、 ギルドワークス アドベントカレンダー の18日目の記事です。今回は、「色つき星取表」を紹介します。 「色つき星取表」ってなに? 結城浩さんが紹介されている自分の活動を見える化するやり方の1つです。 最近の自分がどんな活動に力を…
-
状況判断で駆動する「機略型のアジャイル開発」
見積もりができない。どうする? 見積もりって大事ですよね。見積もりは何のために行なうものでしょうか?開発が終わるかどうかの見立てを立てたい。そうですね、たいてい使えるお金と時間には制約があるので、やろうとしていることが本当に完了できるのか、…
- DRR
- 正しいものを正しく作る
- アジャイル開発
- OODA
-
「雪山」には一人では登れない、だからリアルなチームが必要②
前半 で市谷が語ったギルドワークスのスタンス。それを実現するためには一人では難しい。ではどんなチームで実現していくのか。ひきつづき市谷がインタビューに答えます。 クライアントとひとつのチームに -前半で伺った仕事のスタンス、仕事ができる人に…
- いきなり最強チーム