Journey Map Ops とは何か　カスタマージャーニーマップはマネジメントツールに進化する？

こんにちは、シニアサービスデザイナーの赤羽です。

コンセントの「ひらくデザイン」を読んでいただいている方の中には、カスタマージャーニーマップをつくった経験のある方も多いと思います。しかし、実際につくってみると、なかなか思ったようにうまくいかないこともありますよね。

たとえば、カスタマージャーニーマップに関するよくあるケースとしてこんな声が聞かれます。

「ワークショップでみんなとつくったときは盛り上がったけど、つくった後にどうすれば良いかがわからない……」
「社内で活用しようとすると、いろいろな人からまた別の意見が出て、結局あまり使いこなせない……」

そう、サービスデザインのメソッドは数あれど、実は、カスタマージャーニーマップは最も「つくって終わり」になってしまいがちなツールの１つなんです。カスタマージャーニーマップが、ビジネスに関わる多くの人が聞いたことのあるメジャーなデザインメソッドであるにもかかわらず、です。

この記事のテーマ「Journey Map Ops（ Journey Map Operations ）」は、そんな状況下にあるカスタマージャーニーマップを「もっとビジネス全体に、より継続的に、より効果的に活用できないか？」という課題感から生まれた考え方です（2020年に発行された、サービスデザインの未来について考察したBirgit Mager氏著『The Future of Service Design（サービスデザインの未来）』においても、「Managing Service Design at Scale（サービスデザインの拡大のマネジメント）」の章で紹介されています）。

最も多くの人にサービスデザインの参考書として活用されているであろう『THIS IS SERVICE DESIGN THINKING.』や『This is Service Design Doing』の主著者の1人であり、またスタートアップの More than Metrics社の共同設立者でCEO でもあるMarc Stickdorn氏によって提唱されているこの比較的新しいアイデアの「Journey Map Ops」は、提唱者であるMarc自身でも、その導入支援実績は10数社程度のみなので、まだ実践を通して進歩している途上の概念です。

しかし個人的には、顧客視点によるサービス改善や事業開発を超えた、より包括的な顧客体験のマネジメントの方法論として、Journey Map Opsは重要な考え方ではないかと思っています。それが今回、この記事を書くことにした理由です。

いろいろなOps

Journey Map Opsという言葉を初めて聞いたという方でも、「DevOps」という言葉は聞いたことがあるかもしれません。すごくざっくり言えば、DevOpsとは、「Development（開発）のやり方を、その後工程であるデプロイやリリースがラクになるような形で行っていこう」というものです（異論は受け付けます）。

DevOpsの実現と実行のためには、ツールの活用などはもちろんですが、それ以上に組織のルールや組織形態のあり方自体についても変革することが必要になります。ちなみに、個人的にはこのGene Kim氏著のシリーズ書籍がストーリー仕立てでわかりやすかったです。

• 『The DevOps　逆転だ！　究極の継続的デリバリー』（Gene Kim、Kevin Behr、George Spafford 共著　日経BP　2014年）
• 『The DevOps　勝利をつかめ！　技術的負債を一掃せよ』（Gene Kim 著　日経BP　2020年）

このDevOps以外にも、「DesOps」（デザインがより価値を発揮できるような文化、組織、コミュニケーション、エコシステム、プロセスをデザインする）や「ResearchOps」（UXリサーチやデザインリサーチを、より効果的で、多くの人がその成果を活用できる、もしくはリサーチに取り組むことができる環境を設計する）といった概念が生まれてきています。

これら「Ops」に共通していることは、「それぞれの専門領域に閉じず、組織やプロセスをつなぎ、それぞれの作業の無駄を省いて効率化し、得られる成果を最大化していこう」ということです（ちなみにググってみたところ「SalesOps」や「MarketingOps」という概念も出てきたのですが、システム活用による効率化と最適化、といった部分へのフォーカスが強く、少し意味合いの異なる印象を受けました）。

そもそも個人で完結する仕事以外では、何かをつくって／やって終わり、にはなりません。自分の仕事の終わりは、その成果を引き継ぐ誰か他の人の仕事の始まりです。

この、特に大企業などでは組織のサイロ化によって分断されてしまいがちな領域を、共通知化したり組織的に最適化することを目指していこう、というわけです。コラボレーションを原則の１つとするサービスデザインには親和性のある考え方ともいえるかもしれません。

そして Journey Map Ops（他の略称に倣えば 「JmOps 」などになるでしょうか） もまた、これらの考え方に共通した部分をもっています。

３種のカスタマージャーニーマップ

カスタマージャーニーマップにはいろいろなつくり方がありますし、それに含まれる要素もさまざまです。立場や経験により異なった認識をもっていて、そこから食い違いが生じることは、カスタマージャーニーマップの活用を難しくしている1つの要因ではないでしょうか。さて、Journey Map Opsの提唱者であるMarc Stickdorn氏は、彼の独自の視点から、カスタマージャーニーマップを3つの種類に整理しています。順番に見ていきましょう。

1. ワークショップ・ジャーニーマップ（WORKSHOP MAPS）

「ワークショップ・ジャーニーマップ」は、文字通り、ワークショップでつくられるジャーニーマップです。ホワイトボードに付箋を貼ってつくる……という、皆さんにとっても親しみのあるものではないでしょうか。ワークショップの参加者全員で顧客ターゲットの一連の行動を考え、協働的にジャーニーマップをつくり上げることで、共通した顧客体験のイメージを醸成します。多くの場合、仮説ベースや、既存の顧客に関する知識、既存のリサーチデータをもとにつくられます。このジャーニーマップはワークショップの一環として解決策のアイデア出しのベースなどにも使われますが、一度つくったり使ったりした後は活用されず、しまい込まれるケースがほとんどではないでしょうか。

2. プロジェクト・ジャーニーマップ（PROJECT MAPS）

「プロジェクト・ジャーニーマップ」は、なにがしかの、顧客体験の改善や創造に関わるプロジェクトの成果物としてつくられます。「事実に基づいた共通認識」をつくるためのバウンダリーオブジェクト（異なった背景や専門職能をもった人たちをつなぎ、同じ土台の上で議論することを促すもの）として機能するのが特徴です。

ジャーニーマップの時間軸の長さや階層の深さ、そこに描かれる要素は、対象とするサービスや顧客によって個別に定義されます。このジャーニーマップは最初期にはワークショップ・ジャーニーマップと同様に仮説ベースで描かれることが多いかもしれませんが、プロジェクトの進行に従い、よりリアルな顧客の声や体験を反映したものへと進化していきます。また、問題点を特定するための現状（As-Is）のジャーニーマップを作成した後、未来（To-Be）の姿を描いたジャーニーマップへと発展させていく、といった使い方が多いように思います。ちなみにコンセントではカスタマージャーニーマップを説明する際に下図のような4象限（Inside-out / Outside-in と As-Is/To-Be）に分けて整理することがありますが、同様のことを指しているといえます。

しかしプロジェクトが終わった後には、やはり机にしまい込まれてしまうことが多いですね。プロジェクト後の活用ケースとして、たとえば、カスタマージャーニーマップを大判ポスターとして印刷しオフィスに貼り出して、常に社員に顧客イメージや課題認識を共有する場合などもあります。これは組織の顧客理解の指針となる効果的な使い方です。しかし、Journey Map Opsの観点で活用することで、より戦略的に、組織全体で顧客体験を向上させることができます。

3. マネジメント・ジャーニーマップ（MANAGEMENT MAPS）

「マネジメント・ジャーニーマップ」は、顧客体験マネジメントのために運用（Ops = Operation) するカスタマージャーニーマップです。このマップは、一つひとつはプロジェクト・ジャーニーマップと同様ですが、いろいろな部署や組織のレイヤーで実施されている各プロジェクトのマップを横断し、接続するものです。これにより、相互接続されたジャーニーマップを戦略的にマネジメントし、組織の提案するカスタマーエクスペリエンスを管理することができます。

Marc Stickdorn氏は、図のようにこのマネジメント・ジャーニーマップを「LEVEL 0」（ハイレベル）、「LEVEL 2」（ディテール / 詳細）、「LEVEL 3」（ミクロ / 細部）の3つの階層に分けて説明しています。もちろん、組織やサービスの状況によって階層はさらに細かく分かれる場合もあるでしょう。

「LEVEL 0」とは、たとえば、顧客のライフサイクルのようなものです。そして「LEVEL 2」とは、LEVEL 0のジャーニーマップの任意のステップ（段階）にズームインして、数時間から数日という異なる時間軸で顧客のより詳細な個別性の高い文脈を捉え表現します。さらにズームインすると、ユーザー利用フローやエクスペリエンスジャーニーといわれるような、より細かいインターフェースの具体的な操作レベルなどにまで落とし込んだジャーニー（LEVEL 3）になっていきます。これらの違いは、基本的に時間軸のみです。それぞれズームイン／ズームアウトする視座の違いによってまったく異なった見た目のジャーニーになりますが、マネジメント・ジャーニーマップにおいては、すべて同じサービスの顧客体験を描写しています。

いずれかのレイヤーのカスタマージャーニーマップのタッチポイントや顧客の声、利用データが更新されると、必ず、それと接続された上位下位のカスタマージャーニーマップに影響と変化が生まれます。それをチェックしフィードバックし続けることで、ハイレベル（LEVEL 0）からミクロ（LEVEL 3）までが接続されたジャーニーマップは有機的に進化し続け、アジャイルなサービスの改善と、それが事業に与えるインパクトをシームレスに検証・評価することが可能になる、というわけです。

このような「マネジメント・ジャーニーマップをつくり、運用していくこと、そしてそれを支える組織、プロセス、システムをデザインしていくこと」がJourney Map Opsです。

どうやってJourney Map Opsを始めるか？

手始めに

一度に、企業に関わるすべてのサービスの、すべての顧客体験のマネジメント・ジャーニーマップをつくることはとても大変そうですが、まずはご自身が担当しているサービスのハイレベルのジャーニーマップをつくり、少なくともそれより少し詳細なレベルのジャーニーマップをつくる、などから始めるのが手をつけやすいのではないかと思います。

たとえば、すでにわかっている顧客にとってのペインポイント（不満や不安を発生させる体験）を掘り下げたり、もしくは、カスタマージャーニーでビジネスの成果や重要な意思決定に関わるポイントにフォーカスしたり、といったところから始めてみる。また、サービスに関わるプロジェクト・ジャーニーマップをすでにもっているのであれば、その一段上のレイヤーのハイレベルのジャーニーマップをつくり、それとプロジェクト・ジャーニーマップを接続することを出発点とするのも、既存のリソースが活用できるので取り組みやすい始め方です。

組織と人材 - ジャーニーマップ・コーディネーターとカスタマージャーニー・マネージャー

Journey Map Opsを運用し、サービス提供組織を顧客中心志向にしていくためには、組織の中に「ジャーニーマップ・コーディネーター」という役割を置くことをMarc Stickdorn氏は提案しています。では、ジャーニーマップ・コーディネーターとはどんな存在なのでしょうか？　

彼／彼女たちはサービスの異なる範囲をそれぞれ担当しています。そして、その担当範囲のカスタマージャーニーを把握しアップデートしていくことに責任をもちます。ジャーニーマップ・コーディネーターは他のチームのジャーニーマップ・コーディネーターと連絡を取り合い、組織の壁やサイロを越えた関係を築き、継続的に情報を収集・共有します。さらに、さまざまな部署でどのようなプロジェクトが進行しているのかを把握し、また、それらが自分たちの担当範囲のジャーニーの顧客体験にどのような影響を与えるのか（もしくは、与えないのか）を考えます。そして、最もハイレベルのジャーニーを担当するのは、そのサービスの顧客体験の責任者（ビジネス責任者を兼ねることもある）ということになります。

また、定常的に情報交換をするとはいえ、全体像を共有するためには定期的に組織の中のジャーニーマップ・コーディネーターを集めて共有会議を開催することが必要になります。組織の個性にもよりますが、Journey Map Opsを導入している会社のケーススタディでは、毎週、毎月、もしくは四半期ごとなどのペースで共有会議が開催されています。よりサービス志向、よりアジャイル志向の組織風土であればあるほど、共有会議のスパンは短くなります。しかし、急激な変化は組織の肉離れやスタッフの反発を招きますので、無理のない頻度から開催していくのが吉です。

さらにいくつかのサービスをまたいだ顧客体験全体のマネジメントの責任者として、サービスの顧客体験の最高責任者とは別に「カスタマージャーニー・マネージャー」という役割を設定することが、サービスデザインの国際カンファレンスなどで提案されています。

ミクロなジャーニーから、ディテールレベル、ハイレベルへと情報を接続していくので、ハイレベルでは大量のプロジェクトジャーニーの情報が集約されることになります。そうすると多くの場合、異なるサービスチームのプロジェクト間で重複や矛盾が発生します。この矛盾を解決したり、重複や無駄を整理したりするために、個別のサービス責任とは別の役割が必要となるわけです。またサービス同士のつながりを俯瞰し、異なったサービス単位のジャーニーマップ・コーディネーターの情報交換を促進する仕組みのデザインなども、カスタマージャーニー・マネージャーの職域です。

そして、最終的には顧客体験に関わる、

• 共通した言葉遣いや言語
• 共通したツール
• 共有された視点

を組織の態度や文化として定着させていくことを目指していきます。

Journey Map Opsに使える！ デジタルシステム

Journey Map Opsを効率的に運用していくためには、DevOpsなどと同様にデジタルシステムによる支援が必要です。いくつかJourney Map Opsに使えそうな代表的なソフトウェアをご紹介します。

Smaply

まず本命はSmaplyです。サービスデザイナーが立ち上げたソフトウェア・スタートアップだけあって、カスタマージャーニーマップをつくるための機能はとても充実しています。サービスデザイナー的には、ペルソナ、エコシステムマップ、カスタマージャーニーマップ（サービスブループリント）をそれぞれ相互接続しながら管理できたり、各ツールのポスターサイズの出力がワンタッチでできるなど、とても有用です。コンセントの事例でいうと西日本旅客鉄道株式会社様のプロジェクトなどで活用しています。

さらに、最近のアップデートで各レイヤーのジャーニーマップを簡単に接続する機能や、ExcelやGoogleスプレッドシートに入力した顧客体験に関わるデータの自動連携、Googleアナリティクスとの連携、アジャイルプロジェクト管理ツールであるJiraとの連携など、Journey Map Opsを行うための機能が充実してきています。僕はSmaplyのカスタマーマネージャーとは定期的にやり取りをしているのですが、近いうちに日本語版対応も考えているそうです。ただ、ワークショップ・ジャーニーマップをつくるためのリアルタイムのオンラインコラボレーションには対応していません（2021年6月執筆時点）。

Miro

Miroはコロナ禍の影響で日本でかなりメジャーになったオンラインホワイトボードです。実はMiroでも「Link to」という機能を使って、同じボード内の付箋をボード内で接続させることができます。すでにMiroを使っていて、新しいツール導入にはハードルがある……といった場合に、Journey Map Opsを試しに小さく始めるのに向いています。カスタマージャーニーマップのテンプレートも提供されていますね。またSmaplyと違い、オンラインのリアルタイムなコラボレーションが可能です（というか、もともとそのためのツールです）。

UXPressia

UXPressiaというツールもあります。これはMiroとSmaplyの間くらいのツールで、ビジュアル性の高いカスタマージャーニーマップを簡単につくることができ、また、リアルタイムでのオンラインコラボレーションが可能です。ただし相互接続はできないですし、人力で関係性を整理する必要があります。

余談：（サービス）デザインの組織導入の「トロイの木馬」としてのJourney Map Opsツール

サービスデザインを組織的に導入しようという際に、「トップダウンで始めるのが良いか？　それともボトムアップで始めるべきか？」ということは、よく議論にのぼるテーマです。なんとなく海外企業にはトップダウンでスピード感をもって進むようなイメージがありますが、しかし、実際にはそう見せることがうまい、というケースも多々存在します。

何かしら新しい取り組みや変革を推進しようというときには、どの国のどの人種であったとしても、変化を拒む抵抗勢力が存在します。抵抗の仕方が積極的か消極的かの差は文化によって異なるようですが、結局、トップダウンにしろボトムアップにしろ、少しずつ成功事例をつくり、説得し、受け入れてもらうという地道なプロセスが、定着のためには欠かせません（もちろんトップダウンの方が、予算の問題や組織の問題などはクリアしやすいですが）。結局両方必要です。

Marc Stickdorn氏のホワイトペーパーに、この組織導入をテーマにした「10 TIPS ON HOW TO EMBED SERVICE DESIGN IN ORGANIZATIONS」があるのですが、やはり同様のことをいっています（このホワイトペーパーはService Design Networkのタスクフォースに関連する個人活動で翻訳済みなので、許可が取れたら日本語版を公開したいと思います）。ちなみに、他にも「サービスデザインを押し込む（PUSH）でなく引き込む（PULL）のアプローチを取ろう」とか、「その企業の既存のプロセスをハックしよう」とか、彼の経験からきている興味深い考察がいろいろ含まれているのですが、その中の１つに「ソフトウェアをサービスデザインのトロイの木馬として使おう」という提案があります。

彼が実際にサービスデザインを支援していた会社の中に、ここ2、3年、おもしろい傾向が見られるそうです。彼らのクライアントは、まずジャーニーマップを描くソフトウェアを導入して、その結果として、特定のチーム、あるいは組織全体に顧客中心の考え方を導入することに成功し始めているということです。

どういうことかというと……「新しい考え方」「新しいプロセス」を導入することには多くの抵抗があるのが常ですが、「新しい業務用ソフトウェア」の導入への抵抗は、それよりも大分穏やかになる傾向にあります。なんとなく、皆さんの会社でも思い当たることがあるのではないでしょうか？

そこで……発想を逆転して、サービスデザインのためのカスタマージャーニーマップの正しさなどにはこだわらず、顧客体験について考える必要性のある部署に、ジャーニーマップを書いたり管理する「ソフトウェア」を導入することから始めるわけです。ある会社の実際のケースでは、ソフトウェアの導入後、そこで描かれたジャーニーマップに関して、当初は外部のサービスデザイナーから批評を受けるなどして考え方やつくり方を学んだそうです。その後、このチームは自主的に社員同士で相互批評会を行うようになりました。そしてある日突然、チームメンバーたちは「自分たちはまったく裏付けのない仮定に基づいてカスタマージャーニーマップを作成している」ということに気づいたそうです。そして、その思い込みに基づくジャーニーに即して思い込みでサービスをつくることはとてもリスキーだと感じるようになり、自主的に顧客の調査を求めるようになっていきました。そこからサービスデザインの実践を始め、時間をかけて組織に顧客中心主義の考え方が定着していった……ということです。

さらに、ジャーニーマップの一層の活用を目指して、Journey Map Opsを行うことが社員から自主的に提案される、とまでなれば理想的ですね。

まとめ

サービスデザインは最終的には組織のサイロを超えた人間中心の変革を定着させることを目指しますが、いきなりそのゴールに一足飛びにたどり着くことは困難です。「顧客中心でビジネスやサービスを考えなくてはならない」ということは、近年多くの市場や企業、そこで働く人々に、特別ではない、当然のこととして受け入れられるようになってきました。そしてそのために、ビジネスにおける「デザイン」活用の重要性についても、「『デザイン経営』宣言」などをきっかけとして普及してきているように思います。しかし、それでもまだまだ「デザイン」という言葉には抵抗を感じたり、自分とは遠いものと感じる人たちは多いのではないでしょうか。

一方でカスタマージャーニーマップは、マーケティングやカスタマーサクセス、CRMなどの文脈でも使われ、多くの人や現場に受け入れられている比較的親しみやすいツールです。そのため、ここまで説明してきたように、Journey Map Opsのアプローチであれば、現在のカスタマージャーニーマップの活用や顧客理解に関する課題感、ソフトウェアによる仕事の効率化など、取り組みを始めるための入口をさまざまな形で設けられることが考えられます。また、どこから手を付けて、どのような手順で進めていくべきかといったことも、ある程度具体的になっており、理解がしやすいように思います。

個人的には、より良い顧客体験や従業員体験、サービスのあり方に近づけるのであれば、呼び方はサービスデザインでもチェンジマネジメントでもDXでもブランディングでも、なんでも良いと思います。あなたの組織でもJourney Map Opsのアプローチがより良い方向への変化を進めるために活用できそうであれば、ぜひ一度試してみてはいかがでしょうか。