カスタマーサクセスにおける構造化スキルの重要性
CS Harmony Radio。前回まで、マトリックスとツリーとフローの中でも、フローの話かなり深掘りして盛り上がったかなと。
でですね、じゃあCSの中でこういった構造化の話、特に静的動的っていうもので言うと、静的なものはマトリックスとかツリー、動的って言うとフローになると思うんですけれども、
丸田さん、このあたりってどういうふうに業務の中で使っていて、デファクトみたいなものがあったり、どんなものをツールとして使ってらっしゃる方が多いんですかね。
そうですね、やっぱり一番多いのはシンプルにジャーニー、フロープロセスだとは思います。
CSでよく使われているお客様のライフサイクル、成熟度として、オンボーディング、アダプション、エクスパーションみたいなのがあるんですけど、
お客さんの成熟度を横軸として、縦軸にお客様がやるべきことであったりとか、それぞれのセグメントの中、それぞれのステップごとのゴールとか目標、
あとはお客様がそれぞれのステップの中でこういう行動を取る上で問題点、課題点が起きますよ。それをCSがどういうふうに解決していく、支援していくべきですよ。
っていうようなものをまとめるジャーニー、ロードマップみたいなものを作るのは割と一般的かなとは思います。
サービスであったりCSの活動によっては、お客様が例えばB2Cのように何百ものすごく多い、かつ一人当たり、一客当たりの単価はすごく低いので、
お客様をハイタッチで詳しく知りに行くというか、一社一社細かくケアできないようなときとかはマスで見ていくようなことをしていくので、
そういうときは例えばマトリックスで、お客様の分類って大体今この辺にいるよね、この辺にいるよね、というような少し大雑把に分けていくような見方もしたりするので、そういうときはそういうのを使いますし、
逆にものすごく一社当たりの単価が高くて、すごくコンサルに近いようなものすごい手厚い支援をしていくときとかは、
一社一社目標を分解していったり、今やっていることの要素を構造化して、ここが課題なので、こういう課題を打ち抜くためにこの数値目標を狙って、このサービスを使っていきましょう、達成していきましょうみたいなことを話していくこともあるので、
そういうときはKPIツリーとか結構使ってお客さんと会話していったり、お客さんの課題を構造化していったりすることはありますね。
今の中でいうと、ジャーニーマップとKPIツリーっていうのはよく聞くかなと思うんですけど、マッピングの話のマトリックスって業界的なものって呼び名みたいなものってあったりするんですか?
CS独自のものではないですね。普通のお客さんもセグメンテーションするようなマトリックスです。
やっぱりCSの中でも汎用的に使われているのっていうのは、やっぱりジャーニーとかKPIツリーなんだろうなっていうところだと思うんですけど、
あとは普通にビジネスの中でも使っているものを活用していくと思うので、
丸田さんがおっしゃったように、マトリックスのフレームワークみたいなもので、多分各社いろいろ取り入れているかなと。
フレームワークだという意味なのって、PESTみたいなものとか3Cとか5FORCEとかいろいろあると思うので、
そういうのを使ってやってきつつ、ジャーニーマップっていうのがフローとしてはよく皆さんが作っているものかなと。
その意味で言うと、多分動的な話っていうのが、前回もすごく扱いが難しいっていうところがあったので、
ここから少しヤギさんに聞いていきたいんですけれども、いわゆるジャーニーマップみたいなものって、前回の議論で言うと、
ユニバーサル、ワールドリ、アトミックみたいなところで行ったときに、一般的にはどの領域のところになりがちで、
その領域になったときっていうのは、こういう部分を構造として見るときには気をつけた方がいいとか気づいたところがあれば。
型化してその業界のお客さんに使えるようにしようとすると、アトミックじゃダメで、
アトミックって完全に作業レベルなんで、お客さんのすごい特化した話になっちゃって、
じゃあ多分基本上手くならないので、ワールドリクラスが必要ですと。
ちなみにユニバーサルってもう一般論なんで、多分それ作ってもあんまり誰も嬉しくないと思うんですよ。
だから何だろう正しい表現かわかんないですけど、オンボーリングがあってアダプションがあってエクスポンションがありますぐらいの話って、
それだけ聞いても何にも使えないと思うんですけど、多分それがワールドリっぽいぐらいのイメージになってもらえると。
ユニバーサルのイメージになるので、ワールドリってもう少し具体的に落ちていて、
自社のサービスとかをオンボーディングするときはこうだよねみたいなところが書かれるべきで、
アトミックはさらにそれがお客さんに提供された場合どうだよねみたいなことが書かれなきゃいけないんだと思うんですけど、
作るところで気をつけなきゃいけないのはカタカみたいな話に近いんですけど、
ワールドリって広くいろんなところでも同じようにしないといけないので、
ある意味、すごく個別になってはいけないんですけど、
ジャーニーマップ内集はプロセスみたいなものを作ろうとすると、
目の前のお客さんに対してのものを作ろうとしちゃうじゃないですか。
抽象化というか一般化みたいなところを盛り混ぜながらやらないとワールドリの部分は作れないので、
そこらへんが難しさじゃないかなと思います。
曲がるという意味がありますね。
前回も振る舞いという流れの動的な部分と構造の静的な部分を混ぜてしまうと、
コントロールが効かないというか、わけわからなくなってしまうというところがあったので、
ちゃんと区別することが大事だという話があったかなというところを考えると、
今の話ってワールドリのレベルでプロセスを整理していかなければいけない反面、
カタカを目指そうとすると、構造面によってそこを整理していかないと難しいことになる。
ジャーニーマップって個別のお客さんを見ていくことになるので、
ワールドリなんだけれども、見るところって振る舞いの部分が強いが故に、
そこをカタカするというところにすごくジレンマが生じやすい部分なのかなというふうに聞いてて、
改めて感じたんですけど。
振る舞いを振る舞いだと思っちゃってると、実はちょっと難しいんですよ。
ワールドリって構造で捉えようねって言われてる領域なので、
なるほど。
普通はプロセスとかジャーニーマップも振る舞いで見ちゃうんですよ。
振る舞いってユニバーサルとアトミックの表現領域なので、
例えばうまくいってないパターンのことを言うと、
ジャーニーマップでもいいんですけど、
すごい細かいプロセスみたいなものが作られるパターンと、
すごく漠然としているものが作られるパターンが両極に分かれているんですよ。
それ振る舞いに注目してるんでそうなるんですけど。
本来はワールドリ領域みたいな構造を捉えたいので、
できる人はできるんですよ。
細かなところから構造面だけ引っ張り上げて他に持っていけるよねっていうふうなことができる人はいるんですけど、
そこの部分は意識した方がいい。
意識すると多分カタカとかっていうのに向いていくんじゃないかなと思います。
つまりサンドイッチされてるわけですね。
振る舞いという、フローの中の振る舞いという、
ユニバーサルとアトミックレイヤーにワールドリという構造のものが挟まれてるんで、
振る舞いになりやすいっていう構造上の特性があるっていうことですかね。
なるほどですね。
ここってこれまでも我々が話してきた、言語化でもそうですけど、
具体と抽象の行き来、これに近くて2つのモードを行ったり来たりするっていうところが非常に難しいんだけども、
それをやれるとかなり効果が高いっていうところのポイントなのかなと思うと、
CSSの中の構造化でいったときに、やっぱりジャーニーマップってどこのチームもほぼ間違いなく作るところだと思うので、
これを構造面でちゃんと正しく記載できるジャーニーマップがあると、
カタカナが非常にしやすくなるんだろうなっていう期待感はすごい今持ちましたけど、
プレップモデルを使った構造化アプローチ
なかなか難しいからできてないっていう現実はあるにせよ。
やっぱり構造でジャーニーマップを書くって結構難しいと思うんですけど、
意識しても書きづらいんじゃないかな。
そうですね。結構スキルの問題はすごくあると思います。
ジャーニーマップの作成もそうですし、前段階の構造化スキル自体も持っている方、持っていない方、
減って増えてある方、結構バランスは悪いなという気はしていて、
本当にその構造化スキルの部分がすごく強化されれば、
CSの戦略設計とか、ジャーニーを作るとか、お客さんの新作を考えるとか、
かなりスムーズになるんじゃないかなとは思います。
ある意味、業界課題、人材課題っていうのは一つなのかもしれないですね。
そうですよね。多分、課題はあるんだけど、
それを自分でやるにも限界あるところのポイントなのかなというふうに、
ちょっと見て取れているところがあって、
その辺りって多分、これまで我々Podcastの中でも話してますけど、
モデリングの手法を取り入れて改善していくアプローチを今取っているっていうところがあって、
これがプレップモデルって言われているものかなと思います。
これについては、過去のPodcastの中でも少しずつ触れてはいるんですけれども、
構造物を見る視点になって表現できる構造化というか、構造を描き表す手法になっているので、
それを使うと、このワールドリーで描くべき構造が描きやすくなる手法なのかなと思うんですけど。
他にもあるかもしれないんですけど、
あまり構造面に着目したフロー作成の技法ってあんまりないので、
特殊なのかなとは思うんですけど、見抜いてるかなとは思いますね。
これって、業務的なカタカナ話とかでビジネスを考えたときに、
この構造化のスキルの話とセットで多分順番みたいなところもあると思うんですよね。
つまり、プロセスを整備しましょうっていうのにラーニングマップもあれば、
お客さんの中の目的と手段というか、どういうことを達成したい、
そのためにどういったものをクリアしていかなきゃいけないといわれるKPIツリーのものもあれば、
いわゆるフレームワークでマトリックスを使うみたいなお話もあって、
これってそれぞれがバラバラにやるっていうよりは、
ある種流れとかお客さんの状態に応じて適切にそれを出しながら
コミュニケーションを取っていくっていうことが必要になるかなというふうに考えると、
このプレップモデルっていうのを使って、
そのワールドリング部分を構造化していくと、
どういったところにつながっていくのかな、
そのあたりでどういうふうにアプローチされてますかね。
2個あります。1個目の話をまずします。
1個目のほうは、まず目の前のお客さんとかそういう
顧客に対するものをどうプレップとかを使ってアプローチするかで、
我々考えていることはどうなのかっていうと、
お客さんの業務ってそもそもプロセスなので、
業務プロセスとか業務フローなので、
完全に動的なものですと。振る舞い型なんです。
どうやっても当たり前なんです。
その中から構造的に問題を見つけたりとかっていうのに
プレップモデルを作ります。
なので、Azizの業務からAzizの業務フロー、
業務プロセスをプレップで構造化して作りますと。
この辺からはもう少し経営みたいな話になるので、
ここの出来上がったプロセス、業務フローから
KPIのツリー上の構造を作ります。
これも完全構造体です。
だから業務プロセス側の構造部分を取り出して、
経営レベルのKPIの部分の構造部分を取り出すというのを
まずAziz側でやります。
そうした上で、例えばシステムであったりサービスみたいなのを
入れた後どうなるかというのを明らかにするために、
Azizのお客さんのKPIはこうなんだけど、
2Bでこうなって欲しいっていうのを作れると思うんですよ。
ここの数字が上がるからこうよくなったり。
それを作り出して、それを実現するためには
どういう業務プロセスになるべきかもプレップレベルで見ます。
こういうふうに変わるだろうと。
Azizが2Bに変わる。
それが実際、今のお客さんにとってはどういう振る舞いになるのか。
振る舞いに落とすところはプレップの中から落としていくみたいな、
上に上がって下がるみたいな絵を描いてるんですけど。
逆VGって呼んでます。
これちょっと背景があった。
ソフトウェア開発でVGプロセスっていうのがあるので、
それの逆なんで逆VG。
絵みたいな感じですね。上にとつ。
それが1個目。
まずそもそもどういうふうにしていくかという話と、
今回もう1個の方なんですけど、
一般お客さんに対してはそういう動きをするんですけど、
それをある意味型化していくみたいな話があって、
型化するときってより一般化していかないといけなくて、
構造化によるスケーラビリティ
他のお客さんにも伝えるような話をしないといけないので、
そういうところは出来上がったものを複数集めた上で
共通コードに向けて、もう一度構造化するっていう作業が必要。
そもそもワールドリとかユニバーサルとかアトミックとかっていう
言い方をしてるかって、
カーネギーメロン大学がもともとソフトウェア開発で
プロジェクトになるじゃないですか、ソフトウェア。
プロジェクトがうまく安定しないと品質いいものを作れないっていうのがあって、
それを要は共通項を出して標準的なプロセスから
ある程度の品質を担保したものが作れるだろうっていう仮説のもとに
そういうのをやってた、今もやってるんですけど、
ものがベースにつなってます。
もともとはNASAがロケットを打ち上げるためのソフトウェアを
ちゃんと品質よく作りたいみたいなのがあって、
そうしたときにソフトウェアの品質って結構バラつくんで、
ある程度の担保して、ちゃんとしたプロセスから
ちゃんとしたものが生まれるだろうっていう形で、
どういうふうにものを作るというのか。
共通項何なのかみたいなのをまとめ上げてたのがあるんです。
それがさっき言った構造面の部分のところに当たるんですけど、
構造面を集めていくとさらに標準プロセスみたいなのが作れるんですよ。
標準プロセスから、実際は各プロジェクトって毎回違うんで、
テイラリングっていって自分のとこに持ってくるみたいなのが、
一番適切なやつを持ってきて、
自分の環境に合わせてカスタマイズして、
さらにそれをプロジェクトに実行するみたいなレイヤーを持ってるんですけど、
ある意味すごいでっかいやつをちゃんと型化した事例に多分なってて、
多分それのようなことが最終的にはできるだろうなとは個人的には思っています。
顧客への適応と共通項の発見
2個目は1個ずつの顧客に対して逆V字でモデリングするっていうのがあるんですけど、
それを蓄積していくと最終的にはその共通項が見出せて、
自社にとっての標準的なものが作れると。
標準的なものから顧客に対してより合わせたものを提供することで、
品質高くかつ効率よくみたいなものが実現できるんじゃないかっていうのが考えてるところですね。
ありがとうございます。
すると、まずは個別の話と型化してスケールする話と2つあるっていうところかな、
どういうのが分かりました。
今の話ってまずは業務フローから入って、
業務プロセスをフルマイトゥー構造っていう形で、
まずフルマイメンから取ったものを構造に変換して、
その構造に変えたらKPIツリーとか、
いたしたらマトリックスのように構造体のほうとは親和性が高くなるので、
その業務構造を経営構造につながるようにKPIツリーで構造化して、
経営層とコミュニケーションを図っていくと。
そこのAzuzuを描くから、どういう形で目指していきますかっていう2Bの構造は、
Azuzuの構造から2Bに何を変えるかで分かるので、
現場から上がっていって経営に行って、また現場に下るっていうので逆V字だっていうことですよね。
カスタマーサクセスもライトサクセスとディープサクセスみたいな話もあると思うんですけど、
やっぱり現場レベルのライトサクセスをやるところの部分から入りつつも、
経営のディープサクセスっていうところにもちゃんとタッチしていく。
両方コミュニケーションできるっていう入り方かなというところで、
丸田さん、サクセスも最近2つに分かれてきてるじゃないですか。
それだと、このアプローチってライトとディープそれぞれちゃんとカバーできていく流れにもなってるかなっていうふうに思うんですけど、
そのあたりどう感じます?
そうですね。割とライト、ディープともにすごく使いやすいなと思います。
特にディープに関しては、割とお客さんのことをすごく深く理解して入り込んでいかないといけない部分もあるので、
そこのところはすごく使いやすいだろうな、有効だろうなと思います。
お客さん単体ではなくて、CSがカバーしている複数のお客さんを考えたときには、
ライトサクセスに着眼点を当てたとしても、一社一社全てカスタマイズしていくってなかなか難しいと思うので、
多種多様な現場を少し小さく構造化して、
どのお客さんの現場にもきちんと当てはまっていくよねっていう動き方とか打ち出し方をしていく必要があると思うんですよね。
そのときにも共通項を見つけてきちんと構造化してあげるとかはすごく有効かなと思いました。
今回の構造化のテーマですけど、構造化しておくとやっぱりスケールさせやすいっていうのとか、
それをナレッジとして活用しやすいっていう特性は非常にありそうかなというので、
どうしても振る舞いってなっちゃうと、なかなか堅かしづらいっていう部分があって、
捉えやすい部分、面、その辺りの難しさっていうのは、
こういうアプローチでいろいろ担保できそうなところをお話ししても見えてきたかなというところですね。
ちなみになんですけど、またヤギさんに質問すると、
このプレップみたいなのをやる前とかって、その前にも多分お客さんとのコミュニケーションが必要だと思うんですけど、
そういうときっていうのは、一般的なフレームワークのようなものとかを使ったりとかしてコミュニケーションするんですかね。
いずれこのプロセスレベルのコミュニケーションから入るっていうよりは、
お客さん理解みたいなところがまずあるのかなと思っていて。
プレップやるときも実は、大きな流度感のとき、ユニバーサルレベルの話ですけど、
お話はもう普通に振る舞いで聞きます。
何してるんですか、大きくは。みたいなところは先に整地で捉えておいて、
一個ずつ中身を砕いていくタイミングで構造面に移るっていう。
なるほど。
基本的なヒアリングみたいなところから入っていく方が同じ感じだと思います。
それと今回構造化なので、今ツリーとフローは出てきたんですけど、
マトリックスの使い方みたいなところもあると、
それは割といろんなところで多分出てくる、ちょくちょく出てくるかなと思うんですけど、
前段のところの要は言語化の話というとか、
お客理解とかの対話とか、会話の中とかでも当たり前のように使う領域としては、
このマトリックスって使っていくところかなっていう気もするんですけれども、
その辺はどうですか?
これ多分小木さんとかマルサさんと一緒なんですけど、
コミュニケーションと構造化の活用
話してる時にマトリックスでまとめた方が良さそうだなって思う瞬間あるじゃないですか。
ありますね。
その時に使ってるに過ぎないので、
必ず使いますかと言われると使いはしない。必ずじゃないので、
そんな感じだと思います。多分皆さんと同じ使い方だと思います。
そうですよね。先ほどやっぱりマルサさんの話でもマッピングみたいなお話とか、
多分それってケースバイケースあるけど、
使うシチュエーションって何かしら軸を使って整理するとか、
そういう時にちゃんとミニシーにするとか、
そういうシチュエーションがつどつどあるんで、
そういう時に使っていきながら、
それがコミュニケーションの最初から最後まであるっていう感じですかね。
やっぱり構造化の肝って一番取り扱いの難しいフローっていうものを
うまく攻略していくと、
ツリーとかマトリックスみたいなところとの併用とか、
活用っていうところにもつながっていく。
かつ、CSの文脈でいうと、
このフローをちゃんと攻略すると、
ライトサクセス、ディープサクセスにつながるような
KPIツリーとか、そういった構造化モデルをちゃんと作って、
型化できていく可能性が高いアプローチができるっていうところまでが
見えてきたっていうところで。
これだけ難しさの理由があるんです。
静的なもので、ツリーって構造であるじゃないですか。
ツリーって抽象度のコントロールがしやすいんですよ。
親と子の関係で見入れるじゃないですか。
抽象度の流動感がおかしかったら気づけるんですよ。
同じくマトリックスも気づけるんですよ。
フローに出てくるやつって抽象度がわからないんですよ。
検証の仕様がなくて。だから難しいんですよ。
それってやっぱり構造化の形が起因してるっていうことになるんですかね。
だから構造で見ないと抽象度の回低いみたいな話ってわかりづらくて。
流れで見ちゃうとなんとなく見えちゃうので、わからない。
多分どれかだけ使うっていうよりは、必ず3つ併用しながら
1つの対象を捉えてみていくっていう話が肝なのかもしれないですね。
今の話にもかかってて。
なるほど。ありがとうございます。
構造化っていうところのお話はできたので、
いったんこのシリーズは以上としたいと思います。
ありがとうございます。
ありがとうございました。
