00:04
CS Harmony Radioの番外編を始めていきたいと思います。
普段は堀井さんが仕切っていただいてますけど、番外編はヤギが仕切りたいと思っております。
よろしくお願いします。
この番外編はどういう趣旨でやろうかというところなんですけど、
そもそも本編ってカスタマーサクセスについて語っているところなんですけど、
番外編の方はちょっと難しい話をしたいなと思っていて、
聞きたくない人は聞かなくても良いです。
私の興味のあるところを聞くお二人に聞きたいなと思って、
仕切りを私がやるという形で撮らせてもらいたいなと思ってます。
番外編の第1回なんですけど、ちょうど本編もエピソード1が全部公開されたタイミングで今撮ってます。
中で出てきた単語にプレップモデルっていうのがちょっと別だと思うんですけど、
これについて少し説明しようかなと思っております。
何のこっちゃいってなると思うので、その説明がまず最初になった方が良いかと。
番外編の最初のテーマ、プレップモデルというものについて語りたいなと思います。
お二人に最初聞くこと実はないんですけど、まず何なのかっていうのを語るので、
私の方から語りますけど、第3本編の中で業務モデリングの話を私の方からさせてもらってました。
この業務モデリングって業務のフローを書きますっていうことです。
業務の流れを書くというものになってます。
この辺は学術的な部分にはなっちゃうんですけど、業務をどう書くのかっていうモデリングなんで何かの観点で書くことになる。
業務ってどうやって書きますかって言った時に、よくあるのがフローチャートみたいなやつですね。
作業を書いていくみたいなやつです。
この順番に来て、この場合だとこう分かれて、この時はこうしますみたいな感じの書かれ方をするっていうのがよくあるパターン。
プレップモデルって実はそれとは全然違う書き方をする手法になっていて、
業務そのものって実はその作業であるプロセスっていうものと、それをプロセスに入力になっている成果物で、
何かのプロセスがその入力物を加工したりとか変換したりとかして出力するっていうのが業務として一連の流れであります。
例えば、じゃがいもとか人参とか入力物として捉えて、それを調理しますと。
最終的にカレーってものができます。
入力があって変換の調理するっていう処理があって、出力でカレーみたいなものが出来上がりますっていう。
大体この3つの要素が基本は絡まって連続していくっていうのが基本的な業務の考え方になっています。
03:06
先ほどのフローチャートっていうのはその調理をするっていうところが書かれています。
料理でいうと、材料の部分があるんですか、レシピの中。
そこが入力物になっていて、手順、皮を剥いてみたいな話とか煮ますとか水を入れて中火でみたいなところがプロセスにあたる。
この2側面が書いてある。
このフローチャートの方はその処理の方を書いていますというものになります。
一方でプレップモデルって何を書いているかというと、その入力物と出力物のものの方を書いていますという形です。
端的に言うとこれだけにはなるんですけど、実際どういうものかっていう細かな紹介はポトギャスの紹介文の方に載せておくので、そちらを見ていただけるといいかなと思います。
言葉だけで伝えるのはすごい難しいものなので、そっちを具体的に見てもらえると嬉しいかなと思っています。
端的に言うとその出力物の関係性を書いていくものになっていて、
これのメリットは何かというと、手順で書いていくとみんな手順で書いているものをよく見慣れているので、問題点とかに気づきづらいですよね。
実は成果物のつながりでものを見ると、モデリングの観点を成果物の方に切り替えてあげると、
実際普段わからないことがわかるっていうのが多分一つ大きなメリットになっているかなと思います。
というのが簡単な説明です。
詳しいのはホームページの方を見てもらえると助かります。
というところで、今回の番外編では実際にマルタさんに一回体験してもらったことがあります。
マルタさん、実際にやってみてどうでしたか?
ありがとうございます。
そうですね、複雑なお客さんの業務だったりとか、
その裏側にある、なぜその業務をしているのか、どの辺りが課題なのか、
みたいなところがすごくわかりやすく可視化されたという意味ではすごく良かったなと思います。
少しお客さんの業務の流れみたいなものを洗い出すところは、言語化の整理だったりとか、
ちょっとそういうところは発生はしたんですけど、逆にプレフを作る過程でそこもうまく整理されたので、
実際に客理解を深めるという意味ではすごく良かったです。
ありがとうございます。
なんかこう使いましたとか、ちょっとお話できる範囲でいいんですけど。
やっぱりCSの設計をするときに、お客さんのどういう業務の流れの中で、
自社のサービスをどう使ってもらうか、そのときにどういう課題をどう解決して、
CSがどう支援をしていくかみたいなものを、より設計しやすくなったりとか、
同じチームのメンバーとかに向いてもらって、
こううまく理解を深めていってもらうとかが進んだり、
06:02
機能開発の面とかで、客設定の薄い開発チームのメンバーとかにも、
そこのお客さんの業務だったりとか、サービスをどう使ってもらっているか、
どこが課題なのかというところの説明なんかにもすごくうまく使えたなという印象があります。
ありがとうございます。
一応堀さんも一緒にプレップを書くときにやってもらって、
一応各ところに参加してもらっていたんですけど、
どうかの方から見ていると思います?
丸太さんがすごい感動してたっていうのが、僕は一番印象的だったんですね。
なぜそこに印象的に残ったかというと、
実は僕プレップっていうものの考えとかやってるところに立ち会ったことは、
実際には何度かあったんですよ。
ただ、自分が関係ない業務とか内容で、たまたま行きがかり上立ち会ってたっていうことがあって、
そこの凄さとか、感動してる体験の現場に出会いくわしてなかったので、
ピンときてなかったんですけど、
なぜそうピンときてないかというと、やってることって非常にシンプルというか、
別に何か機をてらったものはないですね。
単純にヤギさんがファシリテイトしながら、丸太さんから言葉を引き出していく。
そのところで引き出している言葉が、さっき説明してもらったように、
手順の流れではなくて、その手順の流れとして必要になる、
欠かせない要素って何ですかっていうのを聞いていくんで、
問いとしてはすごい新鮮なんですけど、
やってることは普通のファシリテーションのような風景なんですけど、
それをやっていくときに、
丸太さんが自分の思考が整理されていく感覚があるところとか、
確かにみたいにすごく納得してるっていうところに、
僕はすごくこのアプローチはいいものなんだなっていうのを、
逆に受けてる人の反応から見て気づいたっていうのが、
印象というか感じたところですね。
ありがとうございます。
そういう意味でいうと、私もやってて思うんですけど、
すごく感動してくれることがいっぱいあるんですけど、
やってる方はそんな普通にやってない。
なんかあれなんですね。
自分ではあんまり感じづらいんですけど、
外れたことはあんまりないんですけど、
なんとなくなんで感動してくれるのかよくわからんっていうのが、
よくあるなと。
で、一旦このCSハーモニーラジオでお話ししてる、
カスタマーサクセスの業界で、
このプレップっていうのを使っていけるといいかなというのは、
少し思っていてですね。
ジャーニーマップであったりとか、
ヘルスコア、プレイブックって、
この3つって結構すごく重要だなと思っていて、
勝手に3点セットって呼んでますけど、
CS3点セット。
この3つって、
このプレップを一旦仲介すると、
勇気的にというか、
意味的につながって、
09:01
いもずる的に作れるんじゃないかなというのは、
今ちょっと考えてるところです。
ちょっと研究者としてですけど。
この3点セット、
ジャーニーマップ、ヘルスコア、プレイブック作るのって大変です。
っていうのはまず聞きたいなと思って。
および、この整合性を取るのって、
すごい大変だなと思うんですけど、個人的には。
どうなのかな、実のところはっていうのはちょっとお聞きしたいですけど。
じゃあ、まるたさんどうです?
まるたさん 確認なんですけど、
プレップを使って作るのは大変ですか?
竹内 ではなくて、一般的にの方です。
まるたさん ありがとうございます。
竹内 それであれば結構苦労されている会社さんが多い印象です。
ジャーニーマップのところは、
カスタマージャーニーっていうマーケティングであったりとか、
いろんなところで言われているものがあるので、
なんとなく作りやすいは作りやすいと思うんですけど、
やっぱり既存のお客さんとか、
いろんなプロダクトの活用の方法とかを考えると、
割とあちこち分岐していったりとか、
お客数が拡大していったときに、
例えばあるお客さんの中で拠点が10個あって、
最初1個をトライして、残りの9個に後から拡大していったり、
ジャーニーが戻ったりするんですよね、また1からの説明。
そういうのがいろいろあったりして、
少し苦労されている会社さんはいらっしゃるなというイメージです。
プレイブックヘルスストアに関しては、
これはカスタマーサクセスの専門領域というか、
ここで出てくるものなので、まだまだやっぱり知見も足りなければ、
世の中に出ている作り方という意味での事例とかも少ないので、
やっぱりここをどうすればいいんだろうというのはすごく悩まれている、
大変だと感じられている方が多いと思います。
やっぱりこのきちんとお客の理解に基づいて、
ジャーニーを引いた後にヘルスストアをきちんと取って、
それに基づいてプレイブックを作ってアクションを打っていくみたいなのをできると、
すごく綺麗なCSができるなとは思っています。
すごく整合性を取るのが大事だとは個人的には思っています。
ありがとうございます。
森さんいかがですか?
ほぼマルトさんの意見と同意です。
その上で、なんでそういうふうに難しいのかなという話をしたいのと、
あとそこに対してマルトさんと一緒に取り組んださっきのプレップのワークというのが、
少し解決の糸口になったんじゃないかなという体験の話があるので、
その話を2つちょっと合わせて説明したいなと思います。
やっぱりなんで難しいかというところで言うと、
僕らも再三本編で話しましたけど、
顧客の理解というところに成果物が大きく依存するんですよね。
12:01
社内でも実際にジャーニーマップみたいなものとか作る場とかに立ち会ったりしてるんですけど、
結構難しいのが、ペルソナみたいなのをベースに考えていった時に、
ある種理想的な動きとか、こうなってほしいという願望が入ってくるようなジャーニーになっちゃうというところがあって、
それは共有する上で非常に分かりやすいし、
みんなをモチベーション上げるのもすごくいいんですけど、
でも本当の顧客理解をした上で作ってないと、
そこがずれていくと、ペルススコアもずれちゃうし、プレイブック自体もずれていくというところで、
作りやすい反面、それぞれの認識とか概念としての捉え方とか、
お客さん像とかっていうのが相づらいジレンマがあって、
それを揃えるってところがすごく難しいんだけど、
作ること自体は簡単にできちゃうので、
作ってみようみたいなところでいった時に、
うまくハマってればいいんですけど、
ハマってないとちょっと辛いなっていうのがあるかなっていうふうに思ってます。
その意味で言うと、難しいところで言うと、
活用するシチュエーションとか主体が違うのをうまくつながなきゃいけないところがちょっと難しいかなと思ってて、
ジャーニーマップってある種、CS組織とかサービスを提供する側から見たお客さんの動きですよね。
感情の変化に合わせて。
それを基にプレイブックで自分たちのCS組織としてどういうアプローチをするのかっていうのが整理されていくので、
読者は一緒なんだけど対象としている人たちがちょっと違うっていうのがあります。
さらにヘルススコアっていうのはサービスそのものから出てきた情報とかお客さんの行動みたいなところから、
何をモニタリング指標として取り扱うかっていうところで、
ジャーニーマップもプレイブックにも影響を及ぼすんですけれども、
これ自体を出てくるところっていうのはお客さんの方の現場にあって、
そこからどういう情報を見ていけばいいんだっていうところとかを、
ジャーニーとかプレイバックにつないでいくところに意味を捉えた上で、
そこのアクションに紐づけるところまで少し距離感があるなっていうところが難しいかなっていうところですね。
そのあたりっていうのはプレイプを使うと距離が縮まるんじゃないかなっていうふうに思っているのが僕の意見。
なんでそう思ったかっていうと、
マルサさんと一緒にやったワークショップの時にプレップを作ったんですけど、
その次にそのプレップを元に一緒にKPIツリーも整理したんですよね。
そうですね。
そのKPIツリーって何になるんですかってなると、
まさにヘルススコアだと思っていて、
結局そこの中で達成したいお客さんのKPI、
15:01
そのKPIを達成するのにサービスとして見なきゃいけない情報なんだっていうのが、
KPIツリーとして紐づく形で整理できたなと思っていて、
そうするとそのKPIツリーを見ていくとお客さんがやりたいことがこういうことで、
それをやるためにはCS組織としてこういうところを挙げなければいけない。
それはこういうサービスから出てくるログ情報とか、
お客さんから出てくるフィードバックとかを見ると判断できるよねみたいなことが、
結構端的に整理できた感覚があって。
で、マルサさんもそのところで見たときには、
その成果物については認識の相互もなかったので、
たぶんある種整理しやすいとか、
観点が違うからこそつなげやすいものではないかな、
みたいなことはちょっと思っているんで、
そのあたりが整合性を取る上では結構いいんじゃないかな、
みたいなふうに思ってるっていうので、
ちょっと質問に対して答えみたいなこと言っちゃいましたけど、
そんな感じの印象を持っています。
ありがとうございます。
てな感じですかね。
私の興味の範囲と喋りたい範囲が終わったら終了するというのが、
番外編かなと思っているので、こんな感じで、
ちょっと締めさせていただきたいなと思います。
その前に、僕一個だけちょっとこのテーマで話したいことがあって、
いいですか。
やっぱりこのプレップ分かりづらいぞ問題が結構あるじゃないですか。
皆さんなんかプレップって何ですかって言われるときに、
どう説明すると伝わりやすいのかなみたいなことで、
ヤギさんが一番頭悩ませてると思うんですけど、
僕もなんかこの本編のポッドキャスト喋ってきて、
ちょっとなんかこういうふうに捉えてるんですけどっていうのがあるんで、
なんかちょっと意見をもらいたいなと思って、
ポッドキャストの本編とかでも、
医療的なメタファーで問題解決の話を説明したところがあって、
症状と原因とかですね。
で、その中で僕プレップってレントゲンかMRIじゃないかなって、
ちょっと思い始めてるんですよ。
なるほどなるほど。
確かにそうかもしれないですね。
イメージレントゲン。
そう、イメージレントゲンか、
でもねちょっとMRIだと思ってる理由もちょっと言いますね。
レントゲンとMRIだと思ってる理由は、
これってプレップやってみないとわかんないんですけど、
普通認識してないものを無理っくり、
てか、あえて認識させるっていうところで負荷がかかってるんで、
結構自分でやるのってうまくできないんですよね。
で、僕らも自分の骨見えないじゃないですか。
だけどレントゲンみたいなそういう特殊な機器を使うと、
自分のことなんだけど自分じゃよくわからないものがちゃんと映し出せる。
18:02
っていうところがすごく近いかなと思ってるんですよ。
で、それがレントゲンかつMRIと思ってて、
どっちかっていうとMRIよりかなって僕が思ってるのは、
ちょっと時間かかるんです。
あの、僕らのプレップっていうのは、
僕らのプレップっていうのは、
30分くらい固定されて、
その間に時間をかけて丁寧に買っても正確なデータ発信をしてくれる。
そこまで気軽にいきなり取れるものじゃなくて、
MRIみたいに30分くらい固定されて、
その間に時間をかけて丁寧に買っても正確なデータ発信をしてくれる。
というところが私は思っているんですよ。
そうですね、そうですね。
をかけて丁寧にでも正確なあれは 骨じゃなくてある種人の体の中
ですけどそういうようなものを 映し出す例えば脳の形とかそういう
のって我々自身の認識とか視覚 情報からは得られないんだけれども
自分たちの体として大事な情報 だけどそれを取るには丁寧に時間
かけないと取れないというところ がプレップでワークショップで
そこを紡いでいく作業とちょっと 似てるっていうのと患者さんになる
のはワークショップを受ける人 っていうのは少し我慢して耐えない
とそういう情報が出てこないぞ っていうところもちょっと近い
かなと思っててビジネスのmriです みたいなのが実は近いんじゃない
かなって最近思ってるんですけど どう思いますっていう投げかけ
締めようとしたところに対して の差し込みなんですけど
いい観点だなと僕は思いました けど丸田さんどうですか
面白いですね確かに上手くプレップ の特徴をすごく見表してるなという
感じがしました
最近これmriかもって思ったんで どっかで言いたいなって思って
てちょうどいう機会があったんで よかったです
わかりましたじゃあmriとしてちょっと やっていきましょう
そうですね例えとして分かりやすいん だったらぜひ採用していただける
と本家の方のプレップやってる 方にも意見をもらって今度教えて
ほしいなと思います
そうですね医者の人だととにかく 具合悪くなって危なそうだとしたら
レントゲンもしくはmri取りましょう って気軽に言うじゃないですか
見えないのでそういうレベルになる といいなと逆に思います
でも今本当にそういうふうに使 われてますよねそれじゃないと
先生とかお医者さんも診断できない 状況になってきてるってことは
情報としてすごい重要なんだけど 自分たちは取れないからそういう
テクノロジーを使って情報を取る だからプレップっていうのもそういう
テクノロジーの一つなんだろう なっていうふうには思います
21:00
まだ市民権がないのでmriとはこういう ものでいいんですっていう説明
から入るのができないので市民権 を得たいですね
そうですねレントゲンでもいい と思うんですけどねレントゲン
かmriかそんな感じなんだろうな と思ってます
ありがとうございますいいまとまり になったような気がします
では漫画編1回目は終了させても らいたいと思いますありがとうございます
ありがとうございました
