00:04
前回まで、マルタさんの実際の取り組みをいろいろ聞いてきたんですけど、
最終的に行き着いたのが、やっぱりお客さんのことを好きになれるかどうかっていう、
すごく、何でしょうね、基本的というか根源的なところの話に立ち返ってきたのが、
とても面白いなというふうに、僕は思って話を聞いてました。
今日はですね、そういうお客さん理解を望む姿勢っていうのを続けてきた先って、
ある種お客さんのことを導いていくというか、リードしていく。
その辺りについて、今日はお話できると良いなというふうに思ってます。
この辺りって、結構経験が物を言う世界のように見えてるんですけど、
でもそれだけじゃないよなっていうところもちょっとあると思っていて、
ヤギさんからモデリングの話って、以前の回で教えてもらってるんですけど、
モデリングの手法を知ってると、ヤギさんはある種お客さんの話を聞いてるようで聞いてないみたいなことを言っていて、
それ面白いなと思ってて、それをやりつつでも、議論はちゃんとあるところのゴールに落とし込んでいくっていうことをやられてるじゃないですか。
それってお客さん理解をある程度のベースでしてるから、
リードしてるっていうふうにも見て取れるんですけど、
その辺りの感覚とか、そういうのができるようになってきたなみたいなところで、
経験踏まえて少し教えてほしいなと思うんですけど。
お客さんというか、やってるクライアントとか関係者が納得するようになったのが、
絵にするようになってからかなと思います。
一番最初に絵にしてすごく上手くいったなと思うのは、問題構造を描いた時が最初なんですけど、
それって正直自分からすると当たり前の頃描いてるなと思って描いてるんですけど、
見えてる人は新鮮だったりとか、そうなんだよねって言ってくれたりとか、
描いたのが実体験場あって、入社初めかな、それこそ。
一年目ですか?
一年目の時。
早いですね。一年目から芯を食ったようなことをやってるわけですね。
それすごいっすね。
一人で行ってこいって言われると、なんか全部一人でやらされる。
ある種ハードな環境だったわけですね。
なるほど。
OJTなんかでぶち込んでくる。
実案件でOJTやるみたいな。
なるほど。
正確に言うと一年目じゃないか、二年目かな。
それでもその話を聞くと、経験値だけじゃ必ずしもなさそうですね。
そこが現体験であって、例えば業務を描く時も主要で大事なところっていうのと、
03:04
そうでもないようなところって、その辺はもう嗅覚になってるのかもしれないんですけど、
ここは深掘るべきだろうみたいなのがあって、
そこまで来ると多分経験値にもなってて、
なんでこれは聞かんでいいやろうみたいなのがあるかなって気がしますね。
なるほど。経験っていうもので嗅覚っていうふうにも表現されてましたけど、
それはある種、これ大事じゃないみたいなものっていうのが能力的に備わってるんだけど、
それは多分最初の2年目でいろいろ打ち込まれた時の辛い経験とかから、
一生懸命手を動かしたところの経験から多分養われてきているお話なのかなっていうふうに思いました。
辛かったわけじゃないですよ。
辛かったわけじゃない。
でもすごいですね。
そういう意味だとヤギさんがその仕事をそもそも好きだとか向いてるっていうのもきっとありますよね、今の話を聞いてると。
たまたまいいのを予算してくれましたね。
いいスタディがあったと。
ただでもさっきすごいなって思ったのは、経験の話で言うと、
正しいとか意味のある経験をできるかできないかみたいなのって、
ある種指導する人とかにかかってるじゃないですか。
適度な難しさみたいなところってあると思うんですけど、
それもたまたま本当にいいのが来たっていう感じだったんですか?
なんなんですかね。
そこまでわからないのと、もともともらわれてたことと違うことをやってるんですけど。
何したいんですかっていうのを最初聞いてましたね。
だからその部分はわかりました。
特定の技術とか特定のやり方が何でそれをしたいんですかっていうか、
どのためにしたいんですかっていう話はまず聞いて。
そうすると本当の目的みたいなのが出てくるんで、
これやるんだとしたらこっちの方がいいんじゃないですかって、
自分の得意な方に持ってくって。
それもでも多分ある種テクニックですよね、きっとね。
前の回でも言ったけど、コンテクストを大事にするっていう話に近いと思うんですけど、
お客さんの前提を理解しながら、お客さんの文脈に合う形で、
でも自分のテリトリーにうまく持っていくみたいな、
多分そういう術だと思うんですけど。
それ自体を多分、もともと好きなのかそういう素養があったのかなっていう気も。
なんかそれやろうと思っても意外に簡単にできないような気もするんですけどね。
どうなんだろうな。
個人的に理由がわからない作業をやりたくないんですよ。
06:01
これらのとこに一人でぶっこまれたら、
研究所の専門家として見てくれるんで、答えてくれるんですよ。
そっか、もうお客さんからすると、
研究者っていうもう肩書きで見てくれてるので、
別にその新人かどうかはわからないから。
新人なのでちょっと色々揉めてたらしいですよ。
それはまあそうですよね。
お客さんからするとこの人大丈夫っていうのはちょっとありますよね。
でもそれって多分さっきの話だと成功してるんで、
あるタイミングからお客さんはヤギさんのことを
吹かせるとか委ねていったポイントがあったと思うんですけど、
それがやっぱりさっき言った絵を描くところにつながるんですかね。
問題の構造で描いたら2年目になるんですけど、
その前に調査して、色々ドキュメントとかそれこそ読ませてもらって、
こうなってませんかっていう仮説ベースのパワポですけどね、
何かすることで描いて、
悪循環起こってません?みたいなのは作ったんですよ。
それはだいぶ感謝されて、そこから話はしやすくなったかなって。
たぶんブレイクスルーはそういうところにあって、
ホワイトボードで描いたものを見てくれて、
それで議論できる立場にいるって信用されてないとできないですね。
そういう意味だと、ヤギさん業務プロセスを研究されてると思うんですけど、
それって会社に入ってから研究してるっていうよりは、
学生の時からその研究をずっとされてたんですか?
会社に入ってからです。
業務プロセスなど何も知りませんでした。その頃は。
大学はパソコンでシミュレーションする系の研究をしてたので。
難しい質問してもいいですか?
どうぞ。
ヤギさんご自身のそういう医療域とか、
学習スピードとかもあると思うんですけど、
それだけ早くモデリングをできたってことは、
学生時代にやられてたことに通ずるものがあったんじゃないかなと思って、
モデリングというものを要素抽出したいというか、
リバースエンジニアリングしてみたいんですけど、
モデリングっていうもので、
もうちょっと抽象的に要素を出していくと、
どういうものとどういうものとどういうもの、
もしくはスキル、スキル、スキル、知識でもいいんですけど、
どういう要素に分かれて、それの掛け算でモデリングっていうものが成り立ってる?
こういう要素を並べてみますね。
それを大学時代でやってて、
今思い起こすと近しいかなって思うのと比べると、
まず僕、博士課程まで大学いたので、
論文書かなきゃいけないっていうのが普通にありまして、
09:00
論文書くんですけど、理論系の研究室にいたので、
実験系じゃなくて、理論立ててこれを検証する、
それをコンピューターシミュレーションで検証するみたいな研究やってたんですよ。
数式いじってみたいなのも含めてやるんですけど、
そういうやり方をしてたので、
スクラップ&ビルドをめっちゃします。
理論立てて、仮説立ててみて、やってみてダメだったみたいな。
実験系も近しいのかもしれないですけど、
スクラップ&ビルドが多分必要と思います。
自分が最初に思ったことと違うことが普通に起こるので、
なんでそれを捨て去る。
最初に作った仮説っていうのはやらないといけない。
もう1個は、コアの理論部分、研究でやってたのが、
コアの理論部分が1個筋にあるんですけど、
ドクター論文通そうとすると、
国際会議とかで3本ぐらい普通に発表しなきゃいけないんですよ。
1個のテーマなんですけど、
3つぐらいそこから出し取るみたいな、
3番台ぐらいまで取るみたいな感じのやり方を、
少なくともうちの研究室がやってるというか、
そういうタイプの研究だったので、
その視線を変えること、
ここから見るとこの事象ってこう見えるよねみたいなのが、
変えられることですよね、言い方を変えると。
変えられないと、
多分同じことを深掘りする方向にしか行かないんですけど、
それってこっちから見るとこういう意味があるよねみたいなのか、
こういうふうに攻めるとこういうことがあらたにわかるんじゃないの、
みたいなのが大事なので、
今も実は研究やってるときも同じ、
それはそのときに鍛えられた気がしますね。
あとはそうですね、
作ったものをシミュレートできなきゃダメですね。
業務プロジェクトでいうと、
これで業務が回りそうだなって思えるとか、
これでちょっと落とし穴あるよねってわかるとか、
そうやってシミュレートなんです。
多分論文であったりとか、
理論を考えたりするときもシミュレーションが必要で、
例えば反例ないよね、
ちゃんとすぐ思いつくような反例がなければ、
ある程度大丈夫そうだなとかっていうのはあるじゃないですか。
シミュレートできると予測も立たないので、
シミュレートの力はいりますね。
シミュレート力がないと、
無駄な仮説めっちゃ作ることになるんですよ。
仮説って作らないと、
これ絶対ないだろって仮説はいらんので正直。
今の話を聞いてると、
むちゃむちゃやってることと繋がりがあるなって思って聞いてましたけど、
スクラップ&ビルドもそうですし、
やっぱり3番出し取るっておっしゃってましたけど、
それってモデリングの説明のときの説明まさにそのものですよね。
12:01
軸を変えるって。
最後に説明してくれてた仮説検証を自分の中でまずやって、
確からしいかどうかっていうのを確認するっていうのも、
とても大事なことかなというので、
学問そのものじゃないですけど、
多分行動原理がすごく今やってる仕事に繋がってるのかなって聞いてて、
僕はちょっと感じましたけど。
丸田さんが今のリバースエンジニアに向けてきたのかなって。
でもすごく涼しいものがあるっていうのを感じておりました。
ありがとうございました。
その今のヤギさんのモデリングに繋がるような研究をしてたときの行動のところとかで、
もうちょっと聞いてみたいなと思ったところがあるんですけど、
ヤギさんの頭の中にはそのスクラップ&ビルドで得た経験、
かつそれまで見てきたいろんなものの軸の中のアプローチを合算して計算して、
脳内でいろいろ考えることによってパターンっていうか、
こうなった時にはこういう風になるんじゃないかみたいなテンプレートみたいなものが形作られていくような気がするんですけど、
あるところから出来てくるから、さっきの話でなんかこれ聞いたことあんなとか、
これやったなみたいな話を聞くと予測がつくみたいな話に繋がってるのかなっていう風に話を聞いてて、
ちょっと僕は今思ったんですけど、感覚的にはそんな感じですか?
感覚的にはそんな感じですね。
前に、ちょっと何個か前のエピソードで話してたんですけど、
マップを持ってかつ仮説を持って臨むっていうのが多分近しいのかなって。
マップってだと経験とかに基づかないと実際はちゃんと作れないので、
もちろん本を読んだりとかインプットで作れる部分は実際はあると思いますけど、
限界があるんで、そこが蓄積になっていくんじゃないかなって気は。
なるほど。
そっか、でもそれが蓄積されたり溜まってくると多分対応パターンとか、
解決するためのある種鉄板みたいな、そういう対応がもうできてきますよねきっと。
そうですね。
大体こういう話来たらこの話に悩んでるよねみたいなことがもう見えるので、
そしたらこういうことしてあげると基本的には解決するはずでしょみたいなことは想定できますよね。
そこまで見えちゃうと、その時に言われてる枝端の細かな話でチューニングしていけば、
基本的にお客さんにやりたいこととか解決したいことに必ずたどり着くんだけど、
その時にスタート地点が微妙にずれてるだけで、そこに行く道は大体わかるし、
ゴールの目安も見えてるから、そこがこういう理解をした上、
かつさっきみたいなお客に対応できるところの問題構造を絵に描くっていう行動として、
15:07
冒頭話はあったんですけど、そのところに行くと解決する手段もセットで持ってるから、
そうするとこの人についていくと自分の悩み解決してもらえるみたいなことになって、
お客さんからするとすごく頼りがいのあるとか、信頼できるCSMの人が思ってもらえるっていうことになるのかなっていう、
そんなところですかね。
小循環に回ると思いますね。
確かに小循環に回りますね。
そうするとそこが得意だって思われるので、
じゃあ得意なやつに任せようってなるので、同じような本件をやりにくくなるんですよ。
キャラ立ちしますね。
逆に引消しをさせられる場合があるんで。
そういうジレンマはあるかもしれないですけど、キャラ立ちできるっていうのはすごくいいですよね。
ある種、期待値がすごくわかりやすい話なので、
本当最初の時に話しましたけど、CSMって期待値調整が非常に大事じゃないですか。
そういう意味だと、この人ってこういう問題解決か、こういう問題取り扱うことに対して長けてるっていうことがわかってると、
お客さんもCSMに対して期待することが明確に設定しやすいので、話がしやすいんだろうなと。
コミュニケーションコストが下がると言ったらいいんですかね、その相互理解の。
そこは多分すごく楽ですよね、きっとね。
解決パターンっていうのって、そんなに多くないんじゃないかなっていう気もしてるんですよ。
要は、条件とか細かい話を落としていくといっぱいできると思うんですけど、
抽象化していったら修練していくと思うので、そこの対応付けができてると、
大体どんな問題が来てもいけるなみたいな状態になるかなと思っていて、
自信が持てるんじゃないかなっていうふうに思うんですけど、
その辺りって例えばヤギさんとかが案件相談の方が、マルトさんもそうですけど、
相談を受けるっていう時に、むちゃむちゃドキドキすることってあんまないんじゃないかなと思ってるんです。
逆に言うと、やっぱり準備はもちろんしていきますし、いろんな設定はしていきますけど、
意思決定とか、相談依頼、困り事の方向感は、お客様それぞれの部分は結構あるので、
なんだかんだ読めない部分っていうのは一定存在しますし、
それがあるので結構緊張するというか、どうなるんだろうなっていうと、
少し確実性の恐怖みたいなのは持て望みますよって毎回。
18:00
常に毎回ずっとやり取りしてても、必ずとも確実にこれが出てくるって分かってたら、
そんなに身構えないですけど。
たぶんそれは当然あると思うんですけど、そうじゃなくて、
要は頭抱えちゃうとか、これどうしていいんだみたいな話っていうのは、
そこまで不安な状態には陥らないのではないのかなという。
その意味であればおっしゃる通りですね。
別に全ての問題が解決できるというような考えはもちろん持ってないですけど、
解決できるものはある程度パターンがあったりとか、
逆に例えばカスタマーサービス業界で言うと、
CCOクラスの人間を採用したいんだけどどうすればいいんだろう、みたいな。
なかなか人がいないけどみんな欲しい、みたいな悩んでる。
解決が難しい問題ですよね。
いって、それは皆さん悩んでて難しいですよっていう、
できないという状況を説明するっていう打ち返し方をするっていうのは。
それもまさにすごく大切なことだと思ってて、
対応するパターンとしてできませんって言えることもすごく重要だし、
それが言えるかどうかって結構多分勇気がいるんですよね。
でもそれが言えるところまで持っていけるっていうのが、
ある種自信なのかなというふうに僕はちょっと捉えていて、
今の話って多分やっぱりそういうベースがあるんだなっていうのが分かりましたね。
ヤギキさんも多分似たような感覚はあるんじゃないかなと思うんですけど、どうですか?
特定分野とか自分が今やってる分野に関しては大体何でも打ち返しますね。
ですよね、やっぱりそうですよね。
ただそこになるのにはちょっと時間かかるかなというのは若干。
1年目、2年目の話で言うと、これできませんを最初は言えないんですよね。
それはそう思います。
本当に最初に突っ込まれた時はソフト開発系の手伝いで入ってたんですけど、
ソフトウェア開発なんて僕は知らないですし。
なので当時横浜に住んでて、
シバーの方にクライアントがいて、
帰りは東京駅に降りて、
クライアントの時に言われた単語を一応メモっといて、
東京駅で降りると丸山あるじゃないですか。
あ、ありますね。
そこに行くんですか。
そこで本屋でガーって全部その辺の本買って読んで、
本当にあったりで知ってますっていう顔をして、
知識ガーってつけて、ちゃんと会話できるようなレベルまで。
持ってくるのにはちょっとかかりますね。1ヶ月か2ヶ月ぐらいはそういう。
それでも十分早いと思いますけど。
21:03
会話ができるだけですよ。中身全然まだわからなかったので。
言ってる単語は見たことあるレベル。
あとこういう単語は隣にあったなぐらいのレベルでしかないんで。
まあでもそれって多分業界知識とか知見になるんで、
やっぱりそこは身につけとかなきゃいけないよねっていう基礎的なところの話ですね。
そうですね。
それができたら多分今みたいな、
要はスクラップ&ビルドを当然っていう望む姿勢と、
あとモデリングと同じようにいくつかの軸で見るって
トライ&エラーのアプローチができるってことと、
それを脳内の中で検証してるっていう話をセットにする中に、
そのお客さんが使ってるとかお客さんの業界の中で
やり取りされてる常識的な知識とか知見っていうのを
インストール徐々にしていくと対応できる問題の幅が増えていくんで、
その中でこういう解決ができるよねみたいなところに
たどり着くことができるのかなっていうふうには思います。
ある多分どっかの業界を知ると、
その後多分他の業界に行った時も早くはなるんじゃないかな。
でもそうだと思いますね。
多分ビジネスなんで共通的なところとかありますよねきっとね。
製造業と小売とかで一見違いそうに見えても、
実はサプライチェーンとかで見た時には
調達してきて出荷してとかそういったとこの大きな流れの中で
重なる部分は実は結構あったりとかするんで、
そういうのを見ていくと違いと同じところが分かると
多分知識的には厚みがすごい増えますよね。
同じところは同じって分かると対応できるし、
違うとこが違うって分かると、
その違いをどういうふうに解決するのかっていうのは
また新しいノウハウにもなるし、
取扱い問題としては何か増えていくものが増えていけば増えていくほど
その軸の顧客理解のベースを持っていれば
対応できる幅がどんどん増えていくことになるんじゃないかな
っていうふうには思うので、
パターン化できる力を持っていると
究極的に言えばどんな課題とかに関しても打ち返せる。
もちろん解決パターンとして持てない課題も当然あると思うんですよね。
例えば風呂を不審にしてくれみたいなのとかって
今買えないですみたいなのももちろんあるし、
さっきのマルチさんの人を雇うみたいなすごく難しい問題も
難しいっていうふうに言えるっていうのは
それをある種解決パターンというふうに捉えると
いろんなものがどんどん増やしていけることができるので
パターンをうまく作れるっていう
そこの部分を実はCSMとかCS組織の中にうまく
24:03
組み込んでいくことが重要じゃないかなみたいなことは
今話してて僕はすごく感じましたね。
なかなかそれって俗人性も高いと思うんですよね。
なぜなら脳内で検証してるとか
スクラップ&ビルド当然って姿勢って結構難しいと思いますし
誰しもが大事に育ててきたものを壊された時に悲しくなるんですけど
あるしヤギさんのその姿勢って否定されて当然だよねみたいな
ところをスタンスとして持っているところはすごく大事だと思うんですよ。
人に否定されたら嫌ですよ。
嫌なのもわかるんですけど嫌なんですけど
人によっては固執する人いるじゃないですか。
要はダメだよとか良くないよって言われても
良くないことを受け止めるんじゃなくて
良くないことを言った人を否定するとか
良くないと言われたことの現象自体を
なかったことにするみたいな。
でもそれって多分今回の話のような文脈で言うと
多分よろしくないんだと思っていて
ある人だって仮説じゃないですか。
作ってるのって。
仮説なんだから間違ってるっていうのも当然あるわけで
合ってるか合ってないかわかんないものを作ってるのに
合ってるはずだって思い込むことは危険だよねみたいな。
これはそうです。
っていう姿勢だと思うんですね。
もちろん否定されたら悲しいんですけど
でも否定されたりとか反対意見を言われることに
合理性があったり納得感があれば
それは学びになりますよね。
それはもちろん全然。
どっちでも合ってる可能性をたぶんもともと考えてれば
必ずありますし。
理論が通ってるんであれば全然。
そこが逆に言うと話してて面白いところになったりする部分でもあるじゃないですか。
全部予定調査だと飽きてきちゃうと思うんですよね。
飽きますよね。
ロープレイでレベル99まで上げたら
暇でやることなくなるのと同じじゃないですか。
歯応えがないみたいな。
大体同じなの。
3年通り。
飽きるんですよ。
それは絶対飽きると思う。
それは新しいことをやりたくなりますよね。
でもそれって正しいですよね。
それは言い方が悪いですけど
ある種、否定をとか反対をという形になる場合もあるけど
新しい視察とか気づきを求めているからに
儚らないと思うので
そこがすごく大事ですよね。
やっぱりあと
モデリングの話は重要だなと思ったのは
やっぱりスクラップ&ビルドの視線も通じますけど
27:00
どれかがダメだった時に
執着しないでいれるかって
違う視点で見る可能性をちゃんと考えられるかどうかに
僕は結構つながるかなと思ってて
固執する人って
それが全てって思いがちじゃないですか。
そうだよね。
そうじゃない道もあるよねみたいなのって
ある程度そういうふうに
社会人ぐらいになってくるところで
いろんな経験を得てる人とかだったら
多分共有できる考え方だと思うので
そこを持っていると
自分の固執
要は仮説に固執せずに
それがダメならこっちから行こうみたいなことを考えて
その時にスクラップ&ビルドした経験をもとに
自分の脳内で
より自分も賢くなるわけですよね脳内検証するから
反論をする脳内の自分が
これでいいのかっていうところの指摘のレベルも上がるので
より良い仮説の精度が高まったものが出てくるっていうことになるから
非常にそこで
アップデートされていくっていうところで
そこがCSの人の行動原理の中に組み込まれていくと
人問題の解決にも引いては繋がっていくかな
業界自体が底上げされていくと
多分優秀な人がどんどん増えてくるので
そうすると任せたいって人が社内の中から出てくれば
別に雇わなくても
この人育てたらなるじゃんみたいになるのが
実は一番合理的な方法だと思うので
そういうところにも本当は行くんじゃないかなっていうので
すごく話してきましたけど
顧客理解というのがむちゃむちゃやっぱり大事で
それをちゃんと高めていくことができると
すごく自分のキャラ立ちやキャリアもしくは
CS業界にとってもとても良いことになるんじゃないかなっていうことが
分かってきた気分に今僕はなってますが
どうですかマルタさん
そこを隔離させていくのはおっしゃるとおり大事ですよね
ヤギさんはどうと思います
なんかすいません僕だけ一人ちょっと盛り上がった感じで
二人があんまりのたこない返事をしたんで
あれ?みたいなちょっと思ってますけど
全部言ってくれたんで
読まないなっていう
コメントは代弁されてしまった
すいませんなんかコメント泥棒してたっていう
でもそれがさっきの話にも通じますけど
箱たいのがないと逆に不安になるとか飽きてしまうみたいな
そういうところにもなるのかなっていうところで
30:01
なかなかそのあたりのバランス感は難しいところはあるなと思いつつも
やっぱり手法っていうか多分考えをどういうふうにうまく根付かしていくかとかっていうのは
考えていく必要があるかなっていうのはなんか見えてきたなと思うんで
そのあたりをまた今度違うときにお話しするのがいいかなと思ってるんで
それを少しまたやっていきましょう
よろしくお願いします
