DebTab

  • ホーム
  • DevTabとは
  • 記事一覧
    • きたえる
    • かえる
    • つくる
    • みちびく
    • たばねる
    • つたえる
かんたんログイン
Githubでログイン
Githubアカウントでかんたんにログインして、DevTabをもっと便利に使おう。

DebTab成長しつづけるデベロッパーのための情報タブロイド

DebTab

ログイン

検索 検索

カスタマージャーニーマップ、失敗のすゝめ

写真藤田 淳子

つくる

2016.04.13

ポイントポイント

0

カスタマージャーニーマップとは、ウェブサイトやサービスを利用する顧客がどのようなプロセスで、どのようなタッチポイントをもって、どのような感情と思考をもってどのような体験をするのかを1枚絵のように視覚化したものです。その名の通り、「顧客(カスタマー)の旅(ジャーニー)をしるした地図(マップ)」です。

メジャーな手法ですので、ここで詳細な説明は行いませんが、ユーザーの感情や行動が全体像として図解されていることや、図解ゆえに関係者が集まって議論しやすいなどの利点があるため、サービス企画やウェブサイト制作時によく使われる手法です。

私たちギルドワークスでもユーザーの動きを見立てる方法として、カスタマージャーニーマップを利用しています。 ユーザーストーリーマッピング、サービスブループリントなども利用していますが、カスタマージャーニーマップはユーザーの感情や思考やモチベーションも関連させられるところが優れているのではないかと思っています。

きれいなカスタマージャーニーマップを描けたらモテる…そう信じていた時代が私にもありました…

私自身にはかつて、カスタマージャーニーマップを美しく描くこと、誰もが見て納得できるものにすること、プロジェクトの経典のようなものにすること、などを目指していた時期がありました。 今はわりと雑に…言い換えるとわりとざっくばらんに行っております。カスタマージャーニーマップを見ながらご飯を食べたりするのでたまにごはんつぶがついてたりします。

方向転換をしたのは、顧客にとって価値があるのは、カスタマージャーニーマップ自体ではなくて、それを含めた仮説検証の結果、市場に投下されたプロダクトであるということを実感してからです。 カスタマージャーニーマップはプロダクトの前段階。誰が何をどう使うから、何をどう作るか、の「見立て」にすぎないので、意義は大いにあるものの、これだけをレビューしてもしかたがない。やわらかい中間生成物という感じで扱っています。

つまり、ユーザーにその価値を問えないものであるカスタマージャーニーマップに時間とリソースを割いてしっかり作りこむより、これも仮説のひとつとして、見立てられたものをその次のプロセスに素早くのせたい、という意図があります。 その次のプロセスとは、エンジニアによるコードだったり、デザイナーによるUIデザインだったりしますが、小さくても動くプロダクトに結びつけるほうが、プロダクトを市場に問う、顧客のもつ価値を実現するという目的においては得策でしょう。

そう考えると、むしろ、カスタマージャーニーマップはダメであればダメであるほどよいのではないでしょうか。 なぜなら、プロダクト開発において失敗が許されるのは、「仮説」だけだからです。

机上にあるものこそバンバン失敗してよい

プロダクト開発には大変なコストがかかります。 この開発コストの前に、小さい失敗を繰り返して「確からしさ」を備えていきましょうというのが仮説検証です。

ユーザーはどんな人たちなのか? どんな感情をもっているのか? どんなタッチポイントで、どんな行動をとるのか? これらは「どうやらこれが確からしいぞ」という見立てでしかなく、これ自体がそもそも大きくズレていたとか、他にも何十個も見立てられていないものがあったとか、それよりこっちのほうが事業としてはダメージ大きかったとか、あとからいくらでも出てきます。

ですので、つくる前の「仮説」で失敗しておくことはプラスになります。考え方としてはプロトタイピングと近しいものがあるかもしれません。「やわらかい中間生成物」と称したのは、これ自体はいくらでも変わるし、あとからわかったことでいくらでも潰しても凹ませてもいいものだからです。 完璧なカスタマージャーニーマップを作ろうとしたところで、しょせん仮説ですから、「正しくないと私たちが困る」になってしまい、なんだかあやしくないでしょうか。カスタマージャーニーマップはユーザーの動きをユーザーの目線で見立てるものなのに、逆に自分たちの考えに沿って・都合のいいように、ユーザーの動きを組み立ててしまうことになりはしないでしょうか。

1枚の絵とインタラクション

「見立てとはいえ、成果物としてきちんとしたものを作らねばならない」と、かつての私は思い込んでいました。 じゃあ成果物ってなんなのよという話になりますと、プロダクトは人の手にわたって動いたときに、はじめて「成果物」と呼べるのではないかと考えています。

美しい1枚絵としてのカスタマージャーニーマップは、たしかにそこに美しくそのようにしてあることは成果のひとつとして呼びようもあるのですが、机上にあるこのマップはユーザーに使われるものではありませんし、ユーザーとのインタラクションがのぞめるものでもありません。

机上にあるものはやわらかな仮説です。 ユーザーとのインタラクションのために仮説をコードとして、あるいはUIデザインとして動かしてみることで、その仮説がさらに深まったり、または、大きくピボットしたり、気づくことが多いのではないでしょうか。

そんな風に考えるので、カスタマージャーニーマップはバンバン失敗してよく、この手法の実践が大切であるこということでもなく、「ユーザーってどんな人なんだろう」「どんな動きをするんだろう」と、つくる私たちが問うことが、重要なのではないかと思います。


なお、訓練のおかげで、私は妄想していたようなきれいなカスタマージャーニーマップも描けるようになりましたが、べつにモテません。

"仮説検証型アジャイル開発"の資料のお申込み

共感した

ポイントポイント

0

取り消す

この記事に共感したら、何度でも押してこの記事のポイントをみんなでアップしよう。

自分の感想を残す

この感想は、サイトに公開されることはなく自分にしか見えません。自分の考えのログを残すために感じたことを登録し、のこしておきましょう。あとで振り返ったときに、あのとき自分はこう考えていたのかということを知ることにより、あなたの成長へとつながります。

Githubでログイン

Githubアカウントでかんたんにログインして、DevTabをもっと便利に使おう。

  • ひとつ前の記事

    チームが自律的になるには安全な場がまずは必要

  • ひとつ後の記事

    関西ITベンチャーの憂鬱と魅力

この記事もどうですか?

2018年に参照したVue.js関係のリンク集

2018年お世話になったVue.jsリンク集 これはギルドワークスイベントカレンダー 4日目の記事と…

つくる

2018.12.04

ポイント
4

状況判断で駆動する「機略型のアジャイル開発」

見積もりができない。どうする?  見積もりって大事ですよね。見積もりは何のために行なうものでしょうか…

つくる

たばねる

2017.12.24

ポイント
4

AWS Amplify を利用して最速で会員登録をつくる

この記事は、ギルドワークス Advent Calendar の11日目の記事です。 Amplifyと…

つくる

2018.12.11

ポイント
0

シェア
  • Twitter
  • このエントリーをはてなブックマークに追加
  • Google Plus

ログインして
ブックマーク

  • Twitter
  • このエントリーをはてなブックマークに追加
  • Google Plus
  • ログイン
LINE@

新しい記事が出たときや、注目の記事などを
定期的にLINEでお知らせしていきます

LINEで登録

LINEイメージ

DevTab
成長しつづけるデベロッパーのための情報タブロイド

株式会社ギルドワークス
https://guildworks.jp
  • プライバシーポリシー
  • お問い合わせ

Copyright © GuildWorks Inc. All Rights Reserved.

ページのトップへ