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

方向転換をしたのは、顧客にとって価値があるのは、カスタマージャーニーマップ自体ではなくて、それを含めた仮説検証の結果、市場に投下されたプロダクトであるということを実感してからです。カスタマージャーニーマップはプロダクトの前段階。誰が何をどう使うから、何をどう作るか、の「見立て」にすぎないので、意義は大いにあるものの、これだけをレビューしてもしかたがない。やわらかい中間生成物という感じで扱っています。
つまり、ユーザーにその価値を問えないものであるカスタマージャーニーマップに時間とリソースを割いてしっかり作りこむより、これも仮説のひとつとして、見立てられたものをその次のプロセスに素早くのせたい、という意図があります。その次のプロセスとは、エンジニアによるコードだったり、デザイナーによるUIデザインだったりしますが、小さくても動くプロダクトに結びつけるほうが、プロダクトを市場に問う、顧客のもつ価値を実現するという目的においては得策でしょう。
そう考えると、むしろ、カスタマージャーニーマップはダメであればダメであるほどよいのではないでしょうか。なぜなら、プロダクト開発において失敗が許されるのは、「仮説」だけだからです。
机上にあるものこそバンバン失敗してよい
プロダクト開発には大変なコストがかかります。この開発コストの前に、小さい失敗を繰り返して「確からしさ」を備えていきましょうというのが仮説検証です。
ユーザーはどんな人たちなのか? どんな感情をもっているのか? どんなタッチポイントで、どんな行動をとるのか?これらは「どうやらこれが確からしいぞ」という見立てでしかなく、これ自体がそもそも大きくズレていたとか、他にも何十個も見立てられていないものがあったとか、それよりこっちのほうが事業としてはダメージ大きかったとか、あとからいくらでも出てきます。
ですので、つくる前の「仮説」で失敗しておくことはプラスになります。考え方としてはプロトタイピングと近しいものがあるかもしれません。「やわらかい中間生成物」と称したのは、これ自体はいくらでも変わるし、あとからわかったことでいくらでも潰しても凹ませてもいいものだからです。完璧なカスタマージャーニーマップを作ろうとしたところで、しょせん仮説ですから、「正しくないと私たちが困る」になってしまい、なんだかあやしくないでしょうか。カスタマージャーニーマップはユーザーの動きをユーザーの目線で見立てるものなのに、逆に自分たちの考えに沿って・都合のいいように、ユーザーの動きを組み立ててしまうことになりはしないでしょうか。
1枚の絵とインタラクション
「見立てとはいえ、成果物としてきちんとしたものを作らねばならない」と、かつての私は思い込んでいました。じゃあ成果物ってなんなのよという話になりますと、プロダクトは人の手にわたって動いたときに、はじめて「成果物」と呼べるのではないかと考えています。
美しい1枚絵としてのカスタマージャーニーマップは、たしかにそこに美しくそのようにしてあることは成果のひとつとして呼びようもあるのですが、机上にあるこのマップはユーザーに使われるものではありませんし、ユーザーとのインタラクションがのぞめるものでもありません。
机上にあるものはやわらかな仮説です。ユーザーとのインタラクションのために仮説をコードとして、あるいはUIデザインとして動かしてみることで、その仮説がさらに深まったり、または、大きくピボットしたり、気づくことが多いのではないでしょうか。
そんな風に考えるので、カスタマージャーニーマップはバンバン失敗してよく、この手法の実践が大切であるこということでもなく、「ユーザーってどんな人なんだろう」「どんな動きをするんだろう」と、つくる私たちが問うことが、重要なのではないかと思います。
なお、訓練のおかげで、私は妄想していたようなきれいなカスタマージャーニーマップも描けるようになりましたが、べつにモテません。
この記事もどうですか?
-
誰にも相談できない、”ぼっち”スクラムマスターが集まってみた
状況 プロジェクトマネージャー、スクラムマスターなどチームに1人のことが多いロールをしている。 問題 自分1人で考え込んでしまう。 視点やアイデアの範囲が狭くなる。 こんなことをやってみた 週に1時間程度、スクラムマスターが集まって話す場が…
- スクラムマスター
-
チームに新しい仲間がやってきた時に行う3つのこと
状況 チームに新しい仲間がやってくる。 こうなってほしい できるだけ早くチームに溶け込んでほしい。 チームとしてのパフォーマンスがあがってほしい。 困り事 何もしないとお互い様子見になったりして、なかなかチームのパフォーマンスがあがらない。…
- チーム
-
ビジネスモデルキャンバスをソフトウェアにするための開発
堤さん、飯野さんから「ビジネスモデルキャンバスを中心においたグループウェアをつくる」と聞いたとき、そのチャレンジに高揚感を覚えました。 いよいよそれを作るのか!と士気が高まる一方、どんなカタチにすれば良いのか必ず頭を悩ますだろう!とさっそく…