顧客理解の共有の重要性
おだしょー はい、みなさんこんにちは。CS
Harmony Radioです。前回に引き続き、 今回もVividの磯野さんにお話を
伺っていきたいと思います。磯野さん よろしくお願いします。
磯野 よろしくお願いします。
おだしょー 前回は、どうお客さんの 理解を深めていくかというところを
伺ったんですけれども、今回は、 顧客から得た知見なり情報という
ものをどうチームで共有していく か、そのチームで共有していった
顧客の知見をどんどん深めていく ことで、CSの業務がどういい方向に
変わるかというところをちょっと 伺っていきたいと思います。
まず、顧客理解深めました。その 知見をどうチームに共有していくか
というところを伺っていきたいんです けど、前回、顧客理解ってそもそも
深めるの大事ですか、みたいなところ から聞いたので、今回もちょっと
そこを聞いてみたいと思います。 CSのチーム内で顧客に関する知見
というのを共有していくこと、みんな 同じ情報なり、知見の土壌を揃えて
いくことって大事だと思います。
そうですね。やっぱり共通の顧客 像というか、持っているのと持って
いないのとでは、社内の議論もそう ですし、例えば支援に関するアップデート
だったりとか、こういうことをやったら いいんじゃないかっていう議論
をする際にも、顧客ってこうだよね が揃ってないと、いやいや私は
そんな寂しさいらないと思います とかっていう、そういう議論になって
しまうと思うんですけど、ここが揃 ってると、確かにそのアイデアいい
ねだったりとか、ここで試したやつ こんなのうまくいきましたみたい
なのが、これって私が持ってるお 客さんでもここでも活用できるな
っていうことが瞬時に閃いたり とかっていうふうにしていくので、
これらのお客さんがこういうふう な共通点があるよねっていうこと
が分かっていると、この集合値が 使えるっていう観点で非常に重要
なんじゃないかなと思ってます。
顧客知見の共有方法
結構これ大事だと思いつつ、すごく 難しいなと僕も偶然とかは悩ん
でおいて、例えばCSチームで1年半 やってましたっていう人と、今日
からCSチームですって入ってきた 人とか、やっぱりその顧客理解
の度合いってすごく変わってくる と思うんですよね。そういういろん
なばらつきがあるメンバーがいる 中で、CSチーム内でどう顧客の
知見なり情報なりで共有していけば いい?
そうですね。結構難しいですし、 これが正解っていうのはなかなか
ない部分かなとは思うんですけど、 弊社もいろいろ試している部分
が正直いろいろありますね。結構 分かりやすいのはやっぱり一時
情報をそのまま共有するっていう ので、インタビュー録画してその
ままそれを上げとくっていうのは、 特にオンラインが前世になって
からは、録画っていう行為ってすごく やりやすくなったというか、お客
様の許可を得た上ですけれども、 やっていきやすくなったなとは
思っているので、そういったものは 実はコロナ以降はかなり意識して
録って、特にお客様の重要な発言 があったものはシェアをしてって
いうことは社内では取り組んでいます。 これは一時情報をそのままシェア
するってことでかなり目線は揃う かなとは思います。ただもちろん
一方で時間かかるんですよね、それ。 仮にミーティングが1時間あった
として見るのが1時間、倍速で見た としても30分、重要なとこでって
教えてもらっても15分。テキスト 読むよりは時間かかりますよね
っていうのは結構難しい部分も あるかなとは思いますね。なので
スラックだったりとかで適宜お客 さんの発言っていうものをある
程度一時情報の形で発信していった りとかっていうことはやっていく
にもしたことはないかなという ふうに思っております。大事だな
と思っているのはインプットする こともそうなんですけど、アップ
するときに理解力の深さとか違い って問われるなっていう気はして
いるので、何か共通の作業として 何か一つのものをアウトプット
するっていう行為を通じて顧客理解 が深まるっていうケースはある
かなとは思っています。分かりやすい のがカスタマージャーニング
をみんなで描きましょうっていう ふうなワークショップとかそう
いったプロジェクトをチーム横断 で進めていくとある程度認識が
整うよねみたいなのは、純粋に作った カスタマージャーニングっていう
アウトプットそのものが共通理解 を助けるっていう側面もなくは
ないんですけど、実際のところ はプロセスを共にすることによって
顧客の共通像だり、どこがずれている とかみたいなことが浮き彫りになって
きたりっていう部分がかなると思 ってまして、そういう一緒にアウトプット
するみたいなのは結構効果的なの かなと。ちょっと話しながらになっちゃ
いました。インプットとアウトプット 両方あるかなと思ってて、インプット
のほうは一時情報、オアノット、 動画、音声、テキストみたいなので
いくつかレイヤーがある。あとは 共有のスピードですよね。半年後に
共有されても知らんがなって話 なので、新鮮なものを新鮮なうちに
届ける。インプットの口はいくつか 探して、アウトプットの口は一つ
集約しながらみんなで共同作業 していくっていうのが、顧客に関
する知見をシェアしていくときの ポイントかなと。一番意味ないな
と思うのは、誰か一人が深く理解 して、レポートにまとめてシェア
顧客理解のレベルアップに向けて
するっていうのが最も無駄かな と個人的には思ってます。
おだしょー 最も無駄かなとおっしゃ ってるのは何で?
三沢 そうですね。さっき言った インプットっていうものしかまず
ないじゃないですか。つまりアウトプット っていうところが抜けているので
そこが結構難しいというか、本当に 認識合わせていくっていう観点
によって、やっぱり効果は限定的 になってしまうなっていうのと、
レポートってやっぱり二次創作 物なので、インプットとしては
結構バイアスがかかってるんですよ ね。一人が10人のユーザーに
インタビューして、その10人のユーザー のインタビューからエッセンス
を抽出してまとめましたっていう レポートよくあるんですけど、そこ
ってやっぱり一次情報から二次 情報への転換の際に、ものすごく
いろんな重要な情報が抜けたり あるいは必要な情報が足されたり
するんですよね、仮定として。これ タチが悪いと無意識的にやっちゃ
うので、本人はピュアな顧客情報 を入れたって思っていても、実
体としては全然そんなことない。 これは何をやればわかるかっていう
と、一人のユーザーのインタビュー を二人の人が見て、それをレポート
にまとめてもらうっていうことを やってみるとわかるんですけど、
全然違うレポート出てくるんですね。 これは面白いんですけど。これを
見れば、いかにレポートみたいな アウトプットが対象となるユーザー
ではなく、それを作っている製作 者の意図を反映したものになる
のかっていうことはよくわかる と。10人聞いて誰かがレポート
を作ると、それは顧客のことを 示したものではなく、単純にその
製作者の心理とかを映したもの になってしまいがちなんですよ
ね、どうしても。それはもうやむ を得ないことというか、避けられない
ことというふうなイメージで私は 捉えております。そういう行為って
結構本人はエクスタシー感じるし、 聞いている側も納得感あるんですけど
ゴールである共通の顧客利化を得る っていう観点からは、あんまり
効率が良くないかなとは思っています。
結構ベテランの人とか、あるいは リーダーなのか、顧客理解を一番
深く持っている人が、顧客の情報を 新人のCSMとかメンバーにまとめて
ある程度抽象化して伝えてあげる って、いろんな組織でやっている
気がするんですけど、これよりは どちらかというと一時情報をみんな
で見ながら、そこから出てくる解釈 が変わったとしても、揃えていく
ジャーニーを作るみたいなプロセス を通じて、ちょっと時間をかけて
揃えるのが良い
おだしょー そう思いますね。なので やっぱり1対2対7だと思うんですよ
ね。詳しい人がまとめて教える って、全部座学じゃないですか。
Cityでいったらフィードバックも あるとしても、3割なんですよね。
それどれだけやっても3割なんですよ。 習熟度が足りないと思います。
特にさっき言った2割のフィードバック っていうのも、実践に対するフィードバック
でない限りダメなんですよね。実際 顧客に会ってきましたと、こんな
こと言ってましたと、これって 一般的なんですかね、どうですかね
っていうことに対するフィードバック であれば機能すると思うんですけど
そうじゃないと、なかなか機能しない っていう側面はあるので、それらを
踏まえて考えると、詳しい人がまとめて こうだよって教えるっていうのが
座学なので1割なんですよ。求める 顧客理解のレベル感が10だとしたら
それやってもレベル1にしかな いんです。レベル1なんでレベル
0よりはマシだとは思うんですけど、 レベル1でいいんでしたっけっていう
話は結構疑問があり、ちゃんとレベル 7、8、9までいってほしいよねって
考えるんだったら、そこの実践 に勝るものはないかなと個人的には
思ってます。
おだしょー これはもう少し視点を広げて、
CSチーム内から前者的に、例えば 開発チームだったり営業チーム
だったりに共有していきますって なったら、同じく一時情報をバーッ
と渡したほうがよいか、ある程度 調理した状態で渡してあげるほうが
いいかというといかがですか。
おだしょー そうですね、部署を結構横断
させていくってなってくると、最終 的にはゴールがあるじゃないですか
顧客理解を深めるっていうことによって 得たい果実みたいなものが、その
果実を作る過程には対象となる 部署のメンバーを巻き込んで叱る
べきかなっていうのも、当然その 例えば50人のチームが4つあった
として、営業、マーケ、CS、開発で 50人ずついたとしたら、当然200人
のプロジェクトってわけにはいかない と思って、そしたらより数人のメンバー
っていうのはもちろん思いますと、 ただその人から各チーム内に電波
がなされるっていうことだったり とか、その理解に向けたワークショップ
が行われてるっていうふうなことを やるといいんじゃないかなっていう
ふうには思ってますね。あるとか CSだけがインタビューして、それを
別の人に伝えていくみたいなことは あるんですけど、かかる労力の割
には効果は限定的だなと思うんですね。 それやるくらいだったら、みんな
でユーザーに会う回をやったほうが 100倍早いかなと個人的には思います。
おだしょー さっきの721じゃない ですけど、アウトプットっていう
顧客理解の共有方法と重要性
のをきちんと入れていく、メンバー にきちんと一時情報を入れていき
ながら理解を深めていく、共通認識 を作っていくっていう熟成のさせ
方が利用できますね。
三沢 理想的にはですね、ただ、もちろん
誰かがまとめてルーフするっていう のも別に悪いことではないと思
ってます。もちろんマイナスになる ことはないと思います。ただ、みんな
に到達してもらいたい顧客の理解 のレベル感っていうものを高く設定
すればするほど、そのやり方だけ だと足りない部分っていうのが
つくんじゃないかなっていうの が思うことですね。実際私もやって
たんですよ、めちゃくちゃこれ。 3年ぐらいやってました。私がアウ
インタビューする、それをまとめ る、シェアするっていうのやって
たんですけど、しばらくやって全然 伝わってないことに驚愕してびっくり
したんですよ。でもたまたま一人の ユーザーさんのインタビューを
一緒にやったことがあったんですね。 そしたらこれまでの努力嘘のように
進んだんですよ。この機能欲しい って僕2年前から言ってるよねみたい
なのが、一緒にインタビューして その人がマジで困ってるのを見た
翌日に実装されるみたいなことって 実際あるんですよね。それを見て
これは私がやり方を間違えてたん だなって悟りました。
おだしょー なるほど。それはすごく身に覚えがありますね。
しばやん 人間自分の脳で見聞きしたことしか
信用しない。それはそうじゃないですか。 他人で言ってることって基本的には
会議の目を見て見るじゃないですか。 なんだろうと思う。本能的に。
そのバイアスはやっぱり突破できない ですよね。人間を見ると面白い
ことが脳にすっと入ってくるケース もあったりはするので、そういう
魔力というか力の作用というか、うまく 利用すると顧客理解ってガーン
と進むんじゃないかなと思ってます。
しばやん 確かに社内の情報というよりは
顧客理解レベルの影響
顧客向けの話なんですけど、コミュニティ とかってすごいそれあるんですね。
こっちがオンボーディングで100回 ぐらい言ったことを他のお客さん
から直に、いや、うちこうやって やってるんですよって言ったら
なんかめちゃくちゃ刺さってその 次の日から真似てくれる。確かに
それに近いのかなと思いました。
しばやん かなり近いと思いますね。自分が
知りたいっていうことになってる かとか、人と接するっていうこと
一つとっても、どれぐらい自分の 真剣度が高まってるというか、フロント
度が高いかみたいなのは結構大事 だと思う。
おだしょー ありがとうございます。
しばやん 例えば営業の人にCSを理解 してもらうときも全く一緒だな
と思ってて、結構やりがちで無意味 だなということが動向なんですよ
アポイントの。CSのアポイントに 動向します、支援の様子見ます
っていうのがあるんです。これ結構 やりがちだけど効率悪いなと思って
ます。動向はどこまで行っても動向 にしかならないんですよね。なんか
受動的なんですよ。つまりインプット しかなくて。これが100回動向する
より1回でいいから自分でやって くださいって言うとめちゃくちゃ
はかどります。これも全然違います ね。10回の動向より0.5回でいいから
実践してほしい。じゃあまるまる さんせっかく参加するんだったら
ここは自分でやってください。それが 条件ですみたいな。そういう風にする
と全然違いますね。顧客理解との 浸透度というかレベル感の深まり
度合いは全く違うと思います。
見るよりやるって実践に寄せて いけばいいことってことですね
今後何か共有の場があったら心に 止めておくように
ありがとうございます
そんな顧客理解をチームの中で 共有してみんなで認識を醸成して
いったらっていう後の話なんですけど 顧客理解をじゃあCSチームがきちんと
深めていったらCSの業務ってどういう ふうにいい方向に変わるかっていう
ところを伺ってみたいんですけど CSの例えば呼び方が正しいかどうか
なんですけど顧客理解レベルが 例えば1のところと一時情報を見て
体験してみんなで何かしらプロセス を経てみんなで理解を深めて揃えて
いった顧客理解レベル10みたい になったときにCSの業務ってどういう
ふうに変わっていくの
全然違うものになるだろうなと思 うんですけどもちろんカスタマー
サクセスもいろんな形があるので どういう携帯を取ってるかによります
か例えばハイとテックでは結構 分かれてますっていう仮にそういう
パターンだとした場合に顧客理解 が揃ってないとハイとテック
で言ってること全然違うみたいな ことあり得ると思うんですよね
テックではこうやればできます ってコンテンツとして書いてある
実際の現場で行くとこれ見ても 分かんないんで実際はこうやって
くださいみたいなことを言ってる みたいな顧客理解の解像度があ
らゆると全然起こり得ることだよ なっていうふうに思っていたり
しますお客さまに対して提供 する接点とか体験っていうもの
が違うハグになってしまうっていう ケースが最もレベルが低いケース
においては起こり得ることかな っていうふうに思ってます例えば
お客さんがいらない機能ばっかり 開発されるとかお客さんに売って
はいけない機体って言ってしまう みたいなのも組織の中で顧客理解
の解像度がバラバラであること が起因して起こることかなと思って
ます一方で顧客理解の解像度が高 ければ阿吽の呼吸でっていうと
ちょっと嘘になっちゃうんですけど きちんと連携をした上擦り合わせ
た上でこういう機体値でこういう お客さんに行きましょうお客さん
はこういう機能をしてるのでこういう 開発をやっていきましょうこういう
改善をしていきましょうっていう ふうなのがかなり利害やすくその
結果顧客満足度が実際に高まって いきチャーンだったりとか防げ
顧客理解の生かし方と業務改善
ますしエクスパンションとかお客 さんからの満足度も非常に高まる
と何よりお客さんの解像度が高い と仮に自分一人でもいいんですけど
自分の顧客理解がレベル1とレベル 10だとレベル1だと本当にこう
型通りのことしか言えないみたいな
機械みたいなロボットみたいな ことになっちゃうただレベル10
まで理解できているとお客さんが この辺に困りそうだなっていうこと
例えば事前に分かったりとか仮説 を持てたりとか先回りして提供
できるあるでしょうしそのさっき 言った周辺領域に対しても何かしら
価値を提供できるそうすると当然 満足度っていうのが上がるんで
個人のレベルも上がるし組織間 の連携のアレントも上がるこの
2つの観点によってチャーの抑止 だったりとかLTPの向上っていう
ふうなものが組めるんじゃない かなと思うんですね
おだしょー 東海ワールド本当に 顧客理解を深めていくことがCS
の目指してやっていく業績数値 じゃないですけどKPI向上に直結
していくんですね
三沢 そうですねだと思いますね
おだしょー いろんな形はあると思 うんですけど例えばCSがオンボーディング
しますだったりあるいは契約更新 の何かしらアクションをします
あるいはヘルススポアを作ります とかテクタチの適時適切な顧客
ごとのアプローチの仕方をきちん と設計しますなんかCSでいろんな
業務領域というか範囲というか があると思うんですけど顧客の
こういうことがより分かるよう になりました例えばこんなユースケース
があるこんなゴールを持ってる こんな課題があるっていうのを
どの領域にどう生かしていくの がすごく効果的だと思うんですね
三沢 そうですね基本的なやつは 顧客接点に生かすのが最も効果的
だろうなとは思いますかねお客 さんに作るコンテンツメール
ハイタッチにおけるプレイブック っていうことでもいいですしそういう
機能開発ももちろんセッティング 一つですよね営業ともその一つ
って考えるとやっぱり顧客接点 の改善に生かすのが最も効果的
かなとは思いますね逆に言うと 社内の効率化とかアニュアル化
とかっていうことに関しては別 にそこまで役に立たないとは言
わないんですけれどもここに生か しましょうっていう感じはあん
まりしないかなとは思ってます かね
三沢 これって例えばバーティカル サースとホリゾンちょっとサース
に限っちゃいますサービスがバーティカル で業界型の場合とホリゾンタル
で業界問わずみたいなところで 行くとそれぞれ顧客理解のあり方
もそうですしその知見の生かし方 もちょっと変わると思うんですよ
ね
三沢 はい
三沢 ビービットさんって多分 理解が正しければちょっとホリゾンタル
なほう
三沢 そうですね
三沢 僕の専職みたいに小売り あと小売りの業務を理解してって
結構分かりやすいと思うんですけど ビービットさんってその辺の
顧客理解とかそれを生かすとか どういう定義でどういうふうに
されてるとか
三沢 そうですね我々自身がちょっと 顧客理解の会社であるっていう
辺りの若干手前味噌感もあるな っていうのはもちろん一旦置いて
おいてなんですけれども我々が 顧客理解をするときに結構重要
視してるのはこれは我々がクライアント に言ってることでもあるんですけど
状況をちゃんと大事にしましょう っていうことを言ってるんですよね
ということが属性とかそういうもの じゃないですよねって話をして
ますと例えばB2Bにおけるホリゾンタル サーズってものすごくポピュラー
なことを言えば業界で分けます よね普通に考えるとメーカー通信
メディア教育とかで分けるのが 多分分かりやすいというかあるいは
セルスフォースさんみたいに郵便 番号で分けるっていうのももちろん
一つあると思うんですけれども あるいはエンプラなのか中小企業
SMBなのかっていうふうな分け方 も当然あると思いますいわゆる
そういう属性っていうものがある かと思うんですが属性も当然有効
な分類だとは思うんですけど我々 はそれ以上にお客さんが置かれてる
状況がどういうものだということ をよりクリアに理解した上で状況
をドリブンに考えていきましょう とつまりどういうことかという
と人の行動というものは特に組織 の行動というものはその人が内発
的に持っている属性だったりとか っていうものに左右される部分
も当然ありながらも多くはその 状況その人が置かれている外部
環境で大きく変化するものだという ふうに我々自身よく言ってる部分
はあるんですねなんで我々の中で どういうふうに知見を生かして
いくかっていうと当然業界の分類 ってあります確かにあるんですけど
顧客理解の重要性
それ以上にお客さんがやりたい ことに関する状況例えば社内を
説得したいなのか部下を育成したい なのかみたいな例えばそういう
お客さんが置かれている状況という かチームの中で今どういう立場
どういう状況にあるのかみたいな ことあったりすると思うんですけど
そういうふうなお客さんの置かれている 立場や環境っていうものを理解
した上でそれらが近しい人同士 でコンテンツの在り方だったり
とかを作ったりしてるっていう のはあります例えばお客さんが
移動するっていうときにどういう コンテンツが必要なのかとかそう
いった括りで作っていくっていう ケースは我々のアプローチとして
はよくやっているケースですよね なんでそれはもしかしたらECでも
金融でも同じかもしれないよね みたいなときにはそこは同じもの
として作っていくっていうことは やっていますもちろん業界とか
での話っていうものがないかっていう とあるはもちろんありますしそれが
お客さまの状況とももちろんリンク してる部分もあるのでそういった
部分は当然業界とかあるいはエンプラ SMBみたいなもので分けていくケース
っていうのも当然あるんですけれども 考え方としては状況をベースに
作っているんでそのときにやっぱり 大事なのはどういう状況のお客さん
にはこのコンテンツが効くみたいな プラクティスをシェアしていく
っていうことが生かし方の王道かな というふうには思っていますし
そこの中でパターン化を実際営業 マンとかカスタマーサクセスが
現場で遭遇したときにある程度 把握ができるような形に落とし
込む具体的には分類を可視化して こういうことを言っていたらこういう
業務モデリングの手法
人こういう状況だみたいなこと をパターン化して配布していく
共有していくっていうことが弊社 の中でやると多いかなと
きちんとパターン化をしてこういう お客さんがいたらこういうふう
にしましょうなのかこういうお客 さんの状況がありますよっていう
ような情報をまとめ方が下手 だったんですけどそれを前者に
例えばきちんと浸透できて開発 営業CSサポートもしくは現場レイヤー
から経営レイヤーまできちんと 顧客の知見が前者的に持てたら
それぞれのチームだったり事業 だったりどういうふうに良くなって
いくと思いますか
おだしょー やっぱり会話が通じ やすくなるとかはありますよね
チームオーダーで会話することがどれ ぐらいあるのかっていう話もある
とは思うんですけれどもやっぱり 話してるとなかなか視点が揃わない
っていうことがあったりします 言語が通じないみたいな違う
言語で喋ってるみたいなそういった 部分がそれを言いやすくなって
そういったことによる影響として さっき言ったような体験自体が
全体としてコンセプチュアルに統合 されて統一されていくバラバラ
じゃないみたいなことも効果として は期待できるんじゃないかな
と思いますね
おだしょー めちゃくちゃ勉強 になりすぎてあっという間に時間
が過ぎてしまったんですが最後に 今CSハーモニーのメンバーのほう
で顧客理解を深めることにも使える 業務モデリングの手法を使って
CSをレベルアップできないかみたいな ことを考えていましてちょっと
ご意見いただければと思います
おだしょー はい本当はモデリング なんで絵があるほうが分かりやすい
んですけど言葉で伝えますけど 業務って基本的には何かのインプット
を処理してアウトプットするじゃない ですか成果物を変換かけてアウトプット
の成果物に変えてっていう連鎖に 業務ってなると思うんですけど
業務を書くときって実は2種類あって 処理のほうを書く場合となので
ハーブのほうですねどうやって それをやるのかっていうほうと
何を作るっていうワットのほう やるっていう2つあってプレップ
のモデルって実はワットを繋い でいくっていう成果物を繋いで
いくっていう手法になっています 例えばですけどゆで卵を作る
ときって生卵に熱を加えてゆで卵 になりますっていうときに実際
やり方ハウだとゆでてもいいし 電子レンジ入れてもいいし多分
いろんなやり方あると思うんですけど 卵と熱からゆで卵になるは多分
変わらないと成果物だけ繋いで いくっていうやり方でそのハウ
の部分を取り除くことで分析を するというようなやり方をしています
普通の業務モデルって実はハウ 側を書いてくるんですよねこう
いう手順でやってきますみたい なのを書いてくるんですけどそこ
に注目するんではなくてものが ちゃんと連なるよね情報がちゃんと
連なるよねっていうほうを書いて いこうっていうのをやってます
どういうメリットがあるかという と誰がやってもみんな失敗する
よねっていうのって多分実際そういう システムになっちゃってるじゃない
ですかそれって実は成果物がそもそも 連携できてない場合があって例えば
カレーライス作るっていうのに スパイスがないみたいな話になる
とどう頑張っても作れないみたい なのがあってそれってカレーライス
とかだと分かりやすいんでいいん ですけど実際業務だとよくある
パターンでこの情報が実際来て ないからこれできないよねみたい
なのを分析できるような手法に 以上なっててこれを使うことで
お客さんって大体ここでハマる でしょうみたいなところを可視化
して共有できるような形の取り組み やりたいなというので今やって
顧客理解の応用と定義
いる感じですイメージ分かります かね
大平 はい よく分かりました
おだしょー 大丈夫ですかね 補足っていうか何でこんなこと
そもそもやろうとしてるかっていう 話を少し説明したいんですけど
磯野さんのノートとかWebの記事 なんかも見てて感慨的に近いな
と思ってるのはビービットさん がやってる顧客に刺さる支援の
フレームワークっていったらいいん ですかね
磯野 はいはいはい
おだしょー 問題の何か症状と原因 って違うよねっていうそこの深掘り
みたいなところの話やりたいこと に近いなと思っててカスタマン
スアクセスの課題とかやるべき ことみたいなところの話っていう
のを少し根付かせていくときに 仕組み感みたいなことを考えて
いる担当だったんでそのときに いろんな声を聞いていくと症状
がいろいろ出てくるんですよなんだ けど症状だけを対応すると多分
これは解決しないんじゃないかな と思って症状の原因になるところ
って何なんだろうっていうのを 理解しないと症状を訴えてる人
も実はお客さんのことちゃんと わかってないから言われたことを
伝えてくるし原因がわかってない からどうしてそういう話になってる
のかっていうのもつながってこない なっていうところがあってちょっと
悩んでるときにこのモデリング っていう話と出会ってこれ体の
内容で例えるとレントゲイみたいな ものなんですよねつまり構造とか
骨格みたいなものを浮き彫りにする 方で先ほどお話にあった顧客理解
のところでもそうなんですけど ヒアリングシートで書いてった
ものってアウトプットが一時情報 から二時情報になるときに何か
足されたりとか引かれたりして 変わってくってお話あったと思
うんですけどそれって状態を見て くっていう視点で切り取ると多分
見る人によって見てるポイント とか内容が異なると思うんですけど
レントゲイみたいに骨格みたいな ものを示すものになるとズレが
起きづらいんじゃないかなと思い ましてそういう手法でお客さんの
ことを理解してくとお客さんの こういう課題はこの原因があった
こういうコメントになってるん じゃないのかと因果というかたど
れないかなみたいなことを思って 実際にうまくワークするかっていう
のをマルタさんのところで使って もらってテストしたっていう経緯
があるんですねそれでマルタさん から評価ももらえたんでこういう
考えっていうのも顧客理解の中では 使えるんじゃないかなっていう
ふうに我々ちょっと思っていて 捉え方っていうか広げていきたい
なっていうのを思って取り組んでる っていう感じなんですけど伝わりましたかね
伝わったかどうか私には判断できない
っていうのはありつつ私の中では 理解できました
どうですかね実践大事っていう のも分かりつつ話聞いてて実際
には制約が入ると思うので現実 みんなが集まる物理的な時間とか
そういった条件ってなかなか整える の難しいところもあるのでどっかで
決めるところがあってそれはひょっと したらリーダーとかポジション
みたいな人なのかやっぱりある 程度時間で会う人が出るとあん
のかなと思っててその辺のグラデーション のところとこういう手法論みたいな
ところの話なんか折り合いみたいな ところどっかでありそうなんじゃない
かなと思いながら話は聞いてたん ですけど
結構顧客理解っていうところに 関して応用できる部分はたくさん
ありそうだなっていうふうにお伺い してて思ったっていうのが率直な
所感かなというふうに思ってまして 多分八木さんがおっしゃっていた
のがハウドリブンじゃなくてフォアット ドリブンで理解をしていきましょう
っていうことだとは思ったんですけ れどもそのフォアットの中でも
フォアットの中にどんな要件が 含まれているのかどういう要素
がないとフォアットが成り立たない のかっていうことを多分割と詳細
に理解をする多分八木さんの例 で言うとレントゲンで理解する
っていう話だと思うんですけれども そこの要素分解をちゃんとして
おくことによってハウドリブン が一定自動的に定義される部分
があるよねっていうことだと思 ってましてもしそうだとしたら
顧客理解っていうことって2つある かなと思ってまして自分自身が
どう顧客理解をしてそれを業務 にどう生かすかって話と誰かの
顧客理解を組織にどう運営させて いくかっていう2つの話があるかな
っていうふうにはお伺いして と思いました一つ目の自分が顧客
をどう理解するかっていう観点 で言うとまさに要素を分解して
理解していくっていう話だったり とかそこの話は意味があるかな
と思って冒頭で前回お話しさせて いただいたようなゴールを理解
しましょうっていう話があった と思うんですけどこのゴールを
理解するっていうのはカレーライス っていうところのカレーライス
が出来上がっておいしいっていう 状態だと思うんですけどこのカレー
ライスが出来上がっておいしい っていう状態には一体どういう
要素が含まれてないとおいしい っていう状態が成り立たないんだ
っていうことをどういう解像度 で理解するかっていうことがある
顧客理解の重要性
程度可視化されていたりすると まずはそれを作るためにはこの
材料とかこのハウだよねっていう ふうな話が出てくるっていうこと
と同じように顧客のゴールという ものをお客さん昇進したらいい
よねだけじゃなくてその昇進 みたいな条件の中にはこうやって
成果が具体的に出ているする上司 が知っている部下が成長している
みたいな要素が必要だよねとその 要素が達成されたようにはじゃあ
我々の支援を得らなきゃいけない よねっていうふうに理解へと発展
していくっていうふうな観点で このプロセスというかモデルみたいな
ものがまず一つ目の話として自分が 顧客をどう理解するかっていう
観点では非常に応用が効くもの なんじゃないかなっていうふう
に思いますあえて違う点を言う としたらアウトプットっていう
ものがいわゆるものなのか顧客 の状態なのかっていうところの
差は確かにあるかなとは思うん ですけどそういう分うまく応用
できると活用できそうでもう1個の 自分が誰かが得た顧客理解という
ものを組織にどう反映していく かっていう観点では1対2対7っていう
とその1とか2の観点としてはめちゃ くちゃ価値がありそうだなっていう
ふうに思っていて実践をカバー するかっていうところに関して
はどちらかというと人間育成したい 対象だったりとか理解を促したい
方々がどれぐらい能動的になる かっていうふうな話だったりも
するので一旦モデリングをする っていう観点ではスコープ外として
やってもいいのかなと思ってました その上で何かしらインプット
を与えるだったりとか何かしら のフィードバックをするっていう
ときにそういう顧客が目指してる 状態に関する要素感だったり
とかレイヤー感だったりっていう ものに関する解像度が高いこと
は非常に価値があるなっていう ふうに思ってますし前回申し上げ
た顧客理解って尺度がいろいろ あるんですよねみたいなことの
難しさってまさにこういうふう な部分かなと思っていて顧客を
理解するっていうハウでいうと いろいろインタビューとかアンケート
とかいろいろある中でその顧客 を理解してる状態からどういう
お客さん成功をつくるっていう 観点ではこれこれをちゃんと理解
しないといけないねっていうもの の要素感が明らかになっていたり
共通認識が取れていたり全ての 会話がそれによってなされて
みたいな状態は顧客理解を深める っていう観点においてはものすごく
効果的なんじゃないかなと思って いたので応用がきそうな観点
つまり自分が理解するっていう 観点もそして理解を組織に組み
合わせるっていう観点その二つの 観点で価値があるんじゃないかな
と思ってました以上です
おだしょー すごい口頭だけの 説明だったにもかかわらずバッチリ
理解していただいてきれいな回答 ありがとうございます
おだしょー とてもありがたい ありがとうございました
おだしょー さすがでございます 今回ですね顧客理解をどう深めて
それをどうチームで共有して業務 に生かしていくかっていうところ
を話していきましたが本当に磯野 さんからいろいろな目から鱗な
試験情報を考えをいただけて 私もすごく勉強になりましたし
きっとこのラジオを聞いてくだ さる方々もすごくぐわっと目を
取っているんじゃないかなと思います 本当に今日はありがとうございました
磯野 はい ありがとうございました
