ROI事件ファイル No.407『顧客の旅路を辿る地図』
顧客の旅路を辿る地図
第一章：散乱する情報の海
「私たちは、顧客の情報を見失っています」
HorizonTech社の営業部長は、そう告白した。彼のデスクには、付箋が貼られた顧客台帳、手書きのメモ、印刷されたメール、そして古いExcelファイルが散乱している。
「営業担当者が顧客情報を探すのに、どれだけ時間がかかっているか、ご存知ですか。システム、メール、紙の資料——情報が三つの場所に分散していて、それぞれを確認しなければ全体像が見えないのです」
彼の声には、疲弊が滲んでいた。
「さらに深刻なのは、タスク管理です。上司が指示した内容が口頭やメールに散らばり、誰が何をやっているのか、進捗はどうなっているのか——マネジメントの観点から、全く把握できていません」
営業部長は資料を取り出した。そこには、経営層からの要望が列挙されている。
「業務の見直しが進められる中、顧客管理の一元化は急務です。そして、若手社員の育成や評価の可視化も求められています。部門間のコミュニケーション改善も課題です」
「2026年1月末までにシステムをリリースせよ、という指示が出ています。しかし——」
彼は言葉を区切った。「何をどう一元化すべきなのか。システムに何を求めるべきなのか。それが明確に見えていないのです」
期限は迫っているが、要件が定まっていない。それが、HorizonTech社の現状だった。
第二章：旅の始まりを見る
「この案件には、JOURNEYモデルでのアプローチが最適ですね」
Claudeがホワイトボードに一本の横線を引いた。その線は、左から右へと伸びている。
「JOURNEYモデル——カスタマージャーニーマップとは」と私は説明を始めた。「顧客や利用者が、サービスと出会い、利用し、離れていくまでの一連の体験を、時系列で可視化する手法です」
「ただし、今回の『顧客』は社外の顧客だけではありません」とGeminiが補足した。「HorizonTech社の営業担当者自身も、このシステムの『利用者』です。彼らの業務フローを旅路として捉え、どこに問題があるのかを明らかにします」
営業部長が首を傾げた。「営業担当者の業務を、旅路として見る?」
「ええ」と私は答えた。「例えば、新規顧客との商談が成立した瞬間から考えてみましょう。その後、営業担当者はどのような『旅』をするでしょうか」
[ステップ1：現状の旅路を可視化する]
「まず、現在の業務フローを、ステップごとに分解してください」とClaudeが提案した。
営業部長は考えながら答えた。「新規顧客情報を入手したら、まず既存の顧客台帳で重複がないか確認します。次に、名刺情報をExcelに入力し、初回コンタクトの予定をカレンダーに記入します」
「その後、メールで面談依頼を送り、返信を待ちます。面談が決まったら、過去の類似案件をメールやシステムから検索して、提案資料を準備します」
「面談後は、内容を営業日報に記録し、上司に口頭で報告します。次のアクションが決まったら、またカレンダーに予定を入れ……」
彼は説明しながら、自分でも驚いた表情を見せた。「こうして整理すると、同じ情報を何度も別の場所に入力していますね」
「まさにその通りです」と私は頷いた。「JOURNEYモデルの最初のステップは、現状を時系列で可視化することです。そうすることで、見えてくるものがあります」
Geminiがホワイトボードに、営業部長が説明した業務フローを図示した。顧客情報の入手から、案件クローズまで、12のステップが並んでいる。
「この12のステップの中で」とGeminiが指摘した。「『情報を探す』という行為が5回も出てきます。顧客台帳、メール、システム、紙の資料——毎回、異なる場所を探している」
「そして」とClaudeが付け加えた。「『同じ情報を入力する』行為も4回出てきます。Excelに入力し、カレンダーに入力し、日報に入力し、メールに入力する」
営業部長の表情が曇った。「無駄だらけですね」
[ステップ2：理想の旅路を描く]
「では、理想の旅路を考えましょう」と私は促した。
「もし、情報が一元化されていたら、このプロセスはどう変わるでしょうか」
営業部長は目を閉じて想像した。「新規顧客情報を入手したら、システムに一度入力するだけで、顧客台帳への登録、カレンダーへの予定設定、タスクリストへの追加が自動的に行われる」
「過去の類似案件も、顧客名や業種で検索すれば、システム上で一覧表示される。面談内容の記録も、同じシステム上で行えば、上司はリアルタイムで進捗を把握できる」
「次のアクションが決まったら、それをタスクとして登録すると、自動的に関係者に通知が行く——」
彼は目を開けた。「情報を探す時間も、重複して入力する時間も、大幅に削減できますね」
「それが、理想の旅路です」とClaudeが微笑んだ。「現状の12ステップが、おそらく7ステップ程度に圧縮できるでしょう」
Geminiが整理した。「JOURNEYモデルの第二ステップは、『あるべき姿』を描くことです。現状との差分が、システムに求める要件になります」
[ステップ3：接点を特定する]
「次に、顧客との『接点』を特定します」と私は説明した。
「営業担当者が顧客と接するタイミングは、いつですか」
営業部長が答えた。「初回コンタクト、面談、提案、見積提示、契約締結、納品、アフターフォロー——主にこの7つです」
「それぞれの接点で、営業担当者は何を記録すべきでしょうか」とClaudeが尋ねた。
「初回コンタクトでは、顧客の課題や要望。面談では、詳細なニーズと予算感。提案では、提案内容と顧客の反応——」
営業部長が説明を続けるうちに、あることに気づいた。「これらの情報は、現在バラバラに記録されていて、後から見返すのが困難です」
「そこです」と私は指摘した。「JOURNEYモデルの第三ステップは、顧客との接点ごとに、記録すべき情報を定義することです」
「そして」とGeminiが補足した。「その情報が、次の接点でも参照できるように設計します。例えば、初回コンタクトで聞いた課題が、提案書作成時に自動的に引用できる仕組みです」
[ステップ4：感情の起伏を捉える]
「JOURNEYモデルには、もう一つ重要な要素があります」とClaudeが言った。「それは、『感情』です」
営業部長が不思議そうな顔をした。「感情、ですか」
「ええ。現在の業務フローの中で、営業担当者が最もストレスを感じるのは、どの瞬間でしょうか」
営業部長は即答した。「情報を探しているときです。顧客との面談前に、過去のやり取りを思い出そうとして、メールを何十通も遡る。システムにログインし、紙の資料を引っ張り出し——それでも見つからず、結局同僚に聞く」
「その瞬間、どんな感情になりますか」
「焦燥感と、無力感です。『なぜこんな無駄なことに時間を使わなければならないのか』と」
「それが重要な情報です」と私は強調した。「システム設計において、『ストレスの高い接点』を優先的に改善することで、利用者の満足度は大きく向上します」
Geminiが図に書き足した。「このJOURNEYマップの各ステップに、『感情の起伏』を示すグラフを重ねます。ストレスの高い部分が谷になり、スムーズに進む部分が山になる」
「そして」とClaudeが続けた。「谷が深い部分から優先的に改善していくのです」
第三章：地図から設計へ
営業部長は、ホワイトボードに描かれたJOURNEYマップを見つめていた。
「このマップが、システムの要件定義書になるのですね」
「その通りです」と私は答えた。「現状の旅路と理想の旅路を比較し、その差分を埋めるための機能を洗い出す。接点ごとに記録すべき情報を定義し、データベース構造を設計する。ストレスの高い部分を特定し、UIの優先順位を決める」
「ただし」とGeminiが注意を促した。「最初から全ての機能を実装する必要はありません。むしろ、最もストレスの高い部分だけに絞るべきです」
営業部長が尋ねた。「それは、どの部分でしょうか」
「『情報を探す』行為です」と私は即答した。「現在5回発生している情報検索を、1回で済むようにする。これだけでも、業務効率は大幅に改善されます」
Claudeが提案した。「まず、顧客情報と過去のやり取り履歴を一元管理する基本機能を構築してください。カレンダー連携やタスク管理は、その次のステップです」
「そして重要なのは」と私が付け加けた。「最初の5名の営業担当者に限定して試験導入し、実際の業務で使ってもらうことです。彼らの『旅路』がどう変化するかを観察し、記録する」
「その学びを基に、機能を追加し、他の営業担当者にも展開していく」とGeminiが整理した。
営業部長の表情が明るくなった。「2026年1月末のリリースも、基本機能に絞れば十分間に合いますね」
第四章：旅は続く
「最後に、一つお伝えしたいことがあります」と私は言った。
「JOURNEYマップは、一度作ったら終わりではありません。システムを導入した後も、定期的に更新してください」
「なぜでしょう」と営業部長が尋ねた。
「なぜなら、顧客との関わり方は変化するからです」とClaudeが答えた。「新しいサービスが加われば、新しい接点が生まれます。営業手法が変われば、業務フローも変わります」
「JOURNEYマップを更新し続けることで」とGeminiが続けた。「システムも常に現場に寄り添ったものへと進化していきます」
営業部長は深く頷いた。「分かりました。まずは現状の旅路を、営業担当者全員にヒアリングして記録します」
彼が去った後、Claudeが静かに言った。「JOURNEYモデルは、人の体験に寄り添う手法ですね」
「ああ」と私は答えた。「多くのシステム設計は、『何ができるか』という機能から始まる。しかし、JOURNEYモデルは『利用者がどう感じるか』という体験から始まる」
「そして」とGeminiが付け加けた。「その体験を時系列で可視化することで、本当に必要な機能が見えてくる、と」
窓の外では、冬の陽光が事務所を照らしていた。
二ヶ月後、HorizonTech社から報告が届いた。
5名の営業担当者による試験導入の結果、顧客情報を探す時間が平均65%削減されたという。そして、彼らからのフィードバックを基に、タスク管理機能の詳細仕様も固まり、全社展開の準備が整ったとのことだった。
旅路を描いた地図は、確実に現場を変えていた。
「システムを設計するには、まず利用者の旅路を描け。現状の体験を可視化し、理想の姿を想像し、その差分を埋めよ。そして、最もストレスの高い部分から、小さく改善せよ。JOURNEYモデルが教えるのは、人の体験に寄り添う設計の道筋だ」
