00:03
カスタマーサクセスハーモニーラジオで、今回から新しいテーマで少し話していきたいなと思います。
メンバーは引き続きヤギさんとマルタさんにお願いしたいと思います。よろしくお願いします。
よろしくお願いします。
これまで顧客理解って難しいっていうところの話を3人で話してきて、
いろいろ気づきもあったし、なかなか面白い議論ができてきたなと思っています。
その中でも、やっぱりCS自身ってお客さん理解するために気をつけなきゃいけないポイントっていうのが、
各社、各人、皆さん思っているところ分かったし、その中でもやっぱり基本大事なのって
お客さんのことをちゃんと好きになれるかっていう気持ちの部分とかを根っこに持たないとダメだよねみたいなところも分かってきて、
そういう気持ちを持った個人っていう人たちが意欲的に活動していくCSとしてやっていかなきゃいけないのか。
今回からその辺の話というと、CSが本当にやらなきゃいけないことって、CS個人としての話ももちろんあるんですけど、
やっぱり組織としてもどういうふうに仕組み作っていかなきゃいけないっていうのも同じように大事なんで、
その辺りのテーマも見据えながらまた皆さんで話をしていければなと思っています。
この前の話って基本的にはCSの顧客理解の中で、お客さんとの対話というか顧客理解のプロセスってどういうふうにやってますかみたいなことを聞いていく中で、
お客さんとの前傾理解をちゃんと揃えるっていうことの話だったりとか、
あとはコンテクストをちゃんと理解するとか、お客さんの言っていることが全てではないっていう、ちょっと逆説的ですけど、
そういうふうにちゃんと自分の判断基準でお客さんが話している内容も考えれるみたいなところがベースにあって、
お客さん理解を進めていきますっていう話になってきたかなと思います。
でもこれってもうちょっとこういう活動を進んでいくと、お客さんからすると、お客さんがそのCSMの人を頼るとか当てにするみたいなところになっていくのかなっていうところで、
ある種CSの個人としての活動としてはもうちょっとそれを頑張っていくと、お客さんをリードしていく。
つまりCSMがお客さんの事業のゴールをちゃんと示しつつ、お客さんをそこにたどり着かせるために一緒に伴奏するとか、
一緒に取り組んでいくみたいなことをフォーメーションとしては組んでいかなきゃいけないことになるかなと思っています。
その時にリードするっていうのって、お客さんに対して導いていくところをやっていかなきゃいけないんですけど、
03:05
難しいのは、かといってカスタマーサクセスを実行するマネージャーとしては、お客さんにやってもらわなきゃいけないっていうところもあって、
支援を単純にするのではなく、うまく伴奏していかなきゃいけないと。
このところをどういうふうにうまく活動として実践していくかみたいなところで、
お客をリードするって僕、そういうちょっと安直な言葉で表現しちゃってるかもしれないですけど、
この辺りのお客さんの成長に向けて、カスタマーサクセスのメンバーというか、我々が奔走しなきゃいけないとか、
尽力しなきゃいけないみたいなところって、どういうふうに考えたらいいのかなっていうところで、ちょっとご意見をいただきたいなと思うんですけど。
カスタマーサクセスは、僕の勝手な解釈だと、Rise Upに近いのかなと思っています。
目標を設計して、そこに至るまでのマイルストーンを一緒に設計してクリアしていくっていうのが、ある種リードしていくことなのかなっていうのは思うんですけど、
ヤギさんとかの場合いかがですか?
カスタマーサクセスの文脈ですか? リードの方ですね。
リードの方で言うと、そうなんでしょうね。これは業務プロセスとかっていう話じゃないですけど、個人的にはコンサルティング的な仕事をしているので、
研究者なんで、世の中の新しい技術とかを取り入れて、こうやったらいいですよっていうのを提案するんですけど、
自分でやっちゃダメなんですよね、基本的に。意味がなくて、お客さん、クライアントの方が自分たちで実行できなきゃいけなくて、
そうするためにどうしたらいいかってちょっと悩ましいんですけど、自分は手を動かさない線は決めなきゃいけないし、
とはいえ、やってみせないといけない部分が出てきたりするときは、手を動かす部分があるんですけど、ただ自分の責務じゃないっていうところは、ちゃんと線引いとかなきゃいけないのかなというのを感じます。
CSでも同じかどうかわからないんですけど。 こんな感じですけど、どうですかマルカさん。
そうですね、その部分は結構カスタマーサクセスにも近しい部分があるかもしれないですね。割とお客さんがあまり動きづらかったりとか、
壁に当たってたりするときは割とグイッと入るときもある気がするので、そのあたりとかはすごく評価する部分があると思います。
なんかブレーキを踏みながらアクセル踏むみたいな感じ。
調整をしている感じは踏み込みすぎるとちょっと良くないし、ブレーキかけすぎると何も起こらないので、微妙な調整で動いているような感じがある。
でもやっぱりそういう意味だと、ちょっと話が逸れてしまうかもしれないですけど、
06:03
僕らってゴールに向かって進めるとか支援します、搬送しますみたいなことを端的に言っちゃいましたけど、
多分そこに行くまでの進め方とか、ペース配分っていうのはやっぱりありますよね。
いきなり1ヶ月で全部やるみたいな話とかって、もちろんスコープとか範囲がちゃんと決まっていればできない話ではないかもしれないですけど、
お客さんと成功させるみたいな大きな目標に対して一緒に搬送していくっていう時に、
一定のペースっていうか、ある程度望ましいペースっていうところもちゃんとCSM側で見てあげないと、
今ヤギさんの言ったように、あんまりのハイペースでも落ち着いてみたいなこともいるし、
ペースが上がらないと上げなきゃいけないって、多分両方ありますよね。
快適に進められるとか、しっかり進められるみたいな、いいゾーンみたいなのってあるんだろうなっていうのは今の聞いてて思うんですけど、
マルサさんとかの経験とかで言うと、その辺の時間軸って多分サクセス期とかオンボーディング期みたいなところとかで整理はされてると思うんですけど、
ハイペースであればあるほど良いみたいな考え方が実はあったりするんですか?
それともやっぱりペース配分ってやっぱ大事だよねみたいな考えだったりするんですか?
その辺りの捉え方ってちょっと今興味あったんですけど。
なんですかね、もちろんお客とか状況とか会社のプロダクトとかCSのゴールによると思うんですけど、
仮にリードタイムを3ヶ月かかるところを1ヶ月で済ませますっていうのが実現できるのか、
そっちの方がいいと思うし、よりそのゴールに向かってハイペースで早く到達できることに、
お客が負担感を示さない、全然ついてこられるようなことがあれば、
ハイペースであればあるほど良いと思います。
ただ、やっぱりお客さんも実業務、本業の実際に別にやってることがある中で、
自社の製品サービスだけにマインドシェアとか時間のシェアをすごく注ぎでくれるわけではないと思うので、
結構そのハイペースでゴリゴリやりすぎると、お客さんがリハーサルされちゃうとか負荷がかかりすぎですっていうので、
逆にブレーキになっちゃうことは結構ある。
ある程度の期間を区切りつつ、ただそこに必ずしも合わないお客さんもいるので、
そういう適宜調整みたいなのがやっぱり必要になってくる。
なんかあれですよ、家電量販店で声かけてくる、めっちゃかけてくる、
いらないっすみたいなやつ。
かければいいってものではないと。
09:01
ちょっとあり方迷惑ですみたいな。
そういう店員客のパターンがあります。
でもそれって結局、相手との関係性がちゃんと捉えられてないとやりがちですよね。
今のペースの話もちょっと、
まるさんがおっしゃってましたけど、
早くいけそうなお客さんだったら、それは早い方がいいのは決まってて、
問題は早い遅いでなくて、その速さに対してちゃんとついてきてくれるとか、
うまく走ってくれるとか、そういうところがポイントだと思うと、
お客さんのこういう状況とか状態をCS側でちゃんと把握しているかとか分かっていて、
その上でストレッチできるレベルの負荷をかけるのか、
それとも安全なゾーンでまずは支えるのかとか、
多分そこは戦略もあると思うんですけど、
そういったところでちゃんとうまく進めていくっていうところの設計をする上では、
これまで話したお客さんの状況をちゃんと知ってないとできないことかなと。
その話って多分、ハイタッチとかロボタッチとかテクタッチみたいに、
多分CSの話とかってお客さんとの接点っていくつか説明がされてると思うんですけど、
本質的には何か変わんないんじゃないかなっていうふうに今聞いてて思っていて、
つまり何を言いたいかっていうと、別にハイタッチだからリード調整、
お客さんとのペース配分の調整を細かくやれるっていう話でもなくて、
逆にテックだから自動で任せて全部お客さんの状況に応じて調整しなくていいって話でもないと思っているので、
ちゃんとどのフェーズとかどのタッチポイントでもやらなきゃいけない重要なことなんじゃないかなっていうふうに僕は感じてるんです。
そのあたりってすごい共通的な姿勢だなっていうふうに思うんですけど、
そうなった時に結構そういうことできる人ってみんなできるのかとか、
同じようにできるのかっていうところはすごく難しいところかなっていうふうにも思うんですけど、
何だろう、冒頭言ったリードですね。
お客さんをリードするみたいなところって、
誰でも彼でもそんなに簡単にできるものではないというふうに思った時に、
結構人によって良し悪しどうしても出てきちゃうんじゃないかなっていうふうに思うんですが、
丸田さんとかのチームとかでやってた時に、
12:00
そういうふうにうまくそのあたりのリードができないとか、
この人のリードうまいとか、そういったばらつきあった時とかって、
これを組織的にうまく転用するとかっていうのって難しいことだと思うんですけど、
なんかやってきたよとか、こういうところが気づきとしてあったみたいなことってあるんですかね。
リードができないのって、
もちろん一定の基礎ビジネススキルとか、リーダーシップとかコーチング力とか、
すごく極めてジュニアな人材じゃなければ持ち合わせているものであるという前提のもとを進めますけど、
一定ドメインナレッジがあればリードってしやすいと思う。
さらに自社のサービスをどう使ってもらえばうまくいくよねっていう価値パターンがあれば、
それもそれでリードしやすいと思う。
なので、うちのサービスをこういうタイムスパンでこういうふうに使ってもらおうっていう価値パターンみたいなやつとか、
それを説明する資料なりコンテンツなりっていうのは用意して、
集まりそうになった時とか、リードした経験が薄い時とかでもリードしやすいようにして、
そういう仕組みとかを整えたっていうのと、
やっぱりお客さんをリードする上で、リードするってこうある種的実な目標設定とマイルストーン設定と課題解決って思うんですけど、
それがやっぱりお客さんが何に一番困ってて、それをどう突破すればいいのかっていうのを言って、
一緒にやっぱり会話できないとどうしましょうねみたいな困っちゃうんですね。
なので、このドメインナレッジみたいなのは、自社のサービスのドメインのコンサルの方とかとの接点を作って、
その業界に対してプロフェッショナルな知識を持てるようにする場を設けたりはしています。
なるほど。やっぱり仕組み化していかないとチーム的な底上げはできないと思うんですけど、
結構そういう意味だと、ちょっと話を変わっちゃうかもしれないですけど、
そういう仕組み化をできる人たちっていうのはある種すごく優秀な人だと思うんですよね。
そういう人たちって、要は素晴らしいパフォーマンスをどんどん発揮していくじゃないですか、リードしていく姿として。
そうすると、その要求レベルがどんどん上がっていくみたいなところもあるのかなと思ってて、
最初は富士山登るレベルのところのリードをしてたんだけど、富士山登ったお客さんには次は、
いい例えがなかったので、エベレストに上がるみたいな。
15:02
そうなったときって、CSMとしての期待されるレベルというか、規模感とか高度なレベル感みたいなのって
どんどん上がっていっちゃうと思うんですけど、そのあたりってやっぱり答え続けていかないといけないっていう話になったときに、
無理芸のような活動だと思うんですけど、
ここってどういうふうにモチベートとか気持ちを持つとか、
どうやっていくとそこに対して自分の気持ちを持っていけるのかみたいな。
優勝であるがゆえにリードする側ってそういう悩みみたいなのも結構ありそうだなっていうふうに思うんですけど。
あんまりそこは悩んだことはなくて、
基本お客様から求められる要求とか登る山が高くなるっていうのは一方、
ほぼニアリーイコールお客様からいただけるお金が多くなるっていうことだと思うんですね。
あればお客さんとピアワンというカテゴリーに属すると思いますし、
自社の事業成長にすごく貢献してくださると思うんですよ。
主にスタートアップだと、そういう事業成長の伸び率が著しいので、
そういう伸びるお客さんっていうのを相対する機会って結構多いと思う。
かつ、やっぱり事業を伸ばしたいって思いをすごく強く持っているメンバーが多い。
このお客さんにより対応できるようになれば、
多少負荷はかかるとしても、もっと事業成長に貢献できるっていう面白さを
すごくプラスに捉えてくれるメンバーはすごく多い印象で。
かつ、サーバーサクセスって割と20代後半から30代くらいの方、
日本の労働人口的に言えば若手ですよね、がすごく多いので、
かなりカスタマーサクセスみたいな新しい業種にいる方だと、
成長要求とか実行検査の動機とかすごく高いんですね。
例えば今レベル5ですと、お客さんがすごくエベレスト級の成長を遂げて、
止められているCSレベルが10じゃないと対応できません。
大変だなと思いつつ、これは頑張ってレベル10にならないと、
逆にモチベーションが上がってくると思います。
逆にテアしないといけないのは、オーバーワークになっちゃうことがあるんですよ。
逆にそういうことですね。アドレナリンが紛失している状態みたいなのに使って、
燃え尽き果てちゃう前にちゃんと止めないとダメだみたいな。
18:02
そっちの方が逆に心配です。
そうか。
燃え尽き症候群。
そうですね。でも、そういう意味で言うと、
そこはひょっとしたら気持ちの前向きになっているメンバーとかで取り組むと、
逆に言うとそれがやりがい、頑張りがいのある仕事になって、
逆にモチベーションが上がるっていうことになるので、
誰がやってもいいとか、すごく簡単な仕事ばっかりやってても、
その人たちからすると面白くなくなっちゃうっていうところがあるので、
レベルの高い仕事をどんどん作っていかなきゃいけないっていうところも、
リードしていかないと作れないから、
そこを作り出すっていう意味でもとても今大事ですよね。
そうか。
その辺の意気込みみたいなところで言うと、
僕はちょっと今ネガティブなところの捉え方から無理ゲーって言っちゃいましたけど、
逆に言うと、それって成長するために必要なものだから、
成長をするための試練という形で捉えていくっていうのが正しいですよね。
そっかそっか。
その辺の話とかって非常に取り組み方としては、
やっぱりお客さんをある種導いていって、高いレベルにどんどん引き上げていって、
チームのメンバーもその高い課題にどんどん応えていって、
全体としてスキルアップしていくと。
そうすると企業の成長にもつながるし、お客さんの成長にもつながるし、
ウィンウィンだから、CSのMのリーダーとかCS組織を率いる人たちとしては、
やっぱり絶対やりたいことだなっていうふうにすごく腹打ちしました。
そうなった時に、ちょっと話の視点を変えて、
ヤギさんに聞きたいんですけど、
お客さんをリードするっていう状況って、
多分そういうふうにいいチーム、いい組織を作っていくのには
非常に重要なアクティビティだったりとか状態だなっていうふうに思うんですけど、
これプロセスとかでこういう状態とか状況になってるよねみたいなことって、
表現できたりとかするんですかね。
なんかプロセスで見えると面白いなって思っちゃったんですけど。
プロセスで見えるって言うと、プロセスって言ってたぶんあれですよね。
業務モデルで出てきたものを見たらわかるかっていう質問かなと。
そうですそうです。
ちょっとそれは無茶かなと思いました。
可能性があるとするならば、さっきの無理ゲーの話に戻すんですけど、
業務フローっていうか業務プロセスで見た時に無理ゲーって2種類あるんですよ。
1つ目がそもそも無理っていう、
そのタイミングでそのドキュメントは来ないよねとか、
21:03
デッドロップしとるやないかいみたいなやつはそもそも無理なんですよ。
それは一律的に不可能って。
こうできません。
もう無理的になんかおかしいとか論理的に破綻してるみたいな。
それがまずそもそも無理ですっていうのがある。
もう1個はコストが合わないっていう。
時間かな、そういう意味で言ったら。
できるんだけど100年かかりますわ。100年も待てないよねみたいな。
たぶんその2個がおそらく無理ゲーとしてあり得ますと。
ちゃんとしたプロセス設計をした後っていうのは重要なのは、
実はシミュレーションすることっていうのがすごく重要です。
実際それが合理的なのかどうかを検証するという作業。
POCではないか。
実際ちょっと動くかどうか脳内シミュレーションするみたいな。
何回か前にその話したかもしれないですけど、
シミュレーションするっていう話が大事で、
シミュレーションのところは実は2つの側面を見なきゃいけなくて、
1つが機能的合理性という。
そもそも無理かじゃないよねっていうのを確認する。
もう1個が経済的合理性。コストが合うよね。
期間内に終わるよねっていうのを確認するっていうのがあって、
それがちゃんとシミュレーション、そのようなプロセスのシミュレーションが
されてるかどうかっていうのが大事じゃないですかね。
されてれば無理ゲーになってないので、
組織としてうまく回ってる確率が高いかなと思います。
もう1個、シミュレーションした後に、
シミュレーションしてダメだった場合どうするかなんですけど、
ちゃんと再設計してるかどうかですね。
今回のパターンに合わせて、
合わせてここはこうじゃないからこう変えますっていうことを
やってるかどうか。
専門用語かどうかわからないですけど、テーラリングって言うんですけど、
そのプロセスをその現行の状態に合わせ込むっていう
作業をちゃんとやっているかどうかっていうのがやられていて、
ちゃんとシミュレーションされていてっていう組織になってれば、
おそらく多少のことがあってもそんなにグラつかないと思います。
その通りちゃんとプロセスも実行できるし、
プロジェクトもちゃんと回るみたいな世界になってると思うので。
なるほど。
ちょっと難しいけど、今の話を聞いてると、
リードするっていうような、いわゆるポジティブな状況の表現は
難しいんだけど、そもそも無理ゲーみたいに、
論理的におかしいとか好ましくない状況っていうのは、
プロセスを設計するとか、
ヤギさんのやってるモデリングの観点から、
まず回避できますよねっていう話かなっていうふうに聞いてて、
理解したんですけど、
まずここまでって僕の理解した感じ合ってますか?
そうだと思います。
入ったところでそれがリードできてるかどうかまでは判定できないですけど、
リスクは回避できてるかどうかは分かるかなと。
なるほど。
24:02
そうすると無理ゲー自体をちゃんと回避できてるってことは、
リードのさらに土台の前提なんで、
無茶なことになってないと。
たぶんさっきの丸田さんの話も、
無理ゲーっていうよりは、
超えるべき試練だみたいなことは言ってたんですけど、
その超えるべき試練がヤギさんのやってるプロセスの設計の中の話でいうと、
そもそも論理的不正語、要は物理的に不可能とか、
例えばこの売上げを100倍に1ヶ月制とかっていうので、
すでに売上げが1億とかあって、
それを100億にするとかってどう考えても無理じゃんみたいな、
そういうちょっと極端ですけど、
論理的にそれって燃え尽き消耗分というか、
壁も越えらずに消耗だけさせてしまうみたいなことっていうのは、
そういう戦略を考えたりとか業務を設計するレベル時点で、
すでに回避できるようになる術はいっぱいあるよっていうのがある。
なるほど、それはすごく重要ですよね。
結局、プロセスじゃないんですけど、
丸田さんのさっき話してくれた話って、
ある種リーダーとかチームをリードするメンバー、
どういう人たちをうまく配置してチームとして当たっていくかっていうところの
フェーズに移ってると思っていて、
つまりお客さんの成長に伴って規模やレベルが上がれば、
やっぱり一人じゃどうやったって対応できないので、
チームで対応しなきゃいけないっていう時に、
どういう人たちを采配して、
どういう役割で回すかっていうところがすごく重要だと思うんですけど、
そういう時にプロセス上やっちゃダメとかまずいっていう状況になってるかどうかっていうのを
ちゃんと防げるようにしてあげるっていうのは、
プロセスを考えていくとちゃんと見て取れるっていうのは、
それはすごい良いことですよね。
それがちゃんとできていると、プロセス上は捉えられないけれども、
それがうまく回っている状態を作り出していることを
采配している人はある種チームをリードしているので、
当然お客さんのこともリードしてるからチームをリードできてるんだっていうように
つながっていくかなと思うと、
そういうつながり方でプロセスとお客さんのリード状態っていうのが
対応関係が見えてくるだろうなと。
一足取りにはいかないですけど、
根っこの部分とかではすごくつながる話かなっていう風に聞いてて思いました。
ちょっと難しいけど、面白いなっていう話として、
僕は今感じましたけど、どうですかね。
マルザさんとか、プロセスで無理ゲーを回避できるみたいな話って、
どんなふうに思いましたか。
27:01
やっぱりプロセスの可視化みたいなのは、
すごいCSの中で有用だなっていうのは思っていて、
やっぱり業務プロセスとかお客さんの業務理解とか、
そのあたりってすごく今CSとして求めているけど、
なかなかできないところってあると思うんですよね。
いろんな、特に俗人化の脱却であったりとか、
CSの精算性の向上とかスケーラビリティを追うとか、
そのあたりとかはすごい使えるんじゃないかなっていう風には思っています。
一方で、スタートアップってプロダクトがほろほろいい意味で変わるんです。成長していく。
プロダクトが変わっていったり、お客さんの層が拡大していったときに、
その業務モデルをせっかく作ったのに合わせて、
それをどんどん作り変えていくとか、ブラッシュアップしていく必要があると、
そこのスピード感というか、どう追いつかせていくかみたいなのは、
悩みのポイントかもしれないなとは思います。
なるほど。でもそれってあれですよね。
プロセスを設計する人って全員じゃないと思うんですけど、
これ多分、顧客理解のときの建築の図面の話でもしたと思うんですけど、
図面を描ける人っていうのは限られてもいいんですけど、
図面を読める人とか理解できる人っていうのは多分、
多くの人に伝えなきゃいけないって話で考えると、
多分ヤギさんの言ってるようなプロセス設計できるっていうのは、
CSMのリーダーみたいな人はそういうことがかけたりとか、
かけるようなための取り組みとか、投資をするっていうのはある種必要で、
それはあると多分組織的にうまく回すと。
そのときにサービスもそうですし、多分プロセスもそうだと思うんですけど、
水物っていうか常に変わっていくものなので、固定しちゃダメですよね。
多分この話もどっかの回でしてたと思うんですけど、
結局常にアップデートしなきゃいけないっていうことを考えると、
プロダクトの成長に合わせて、やっぱりプロセスを見ていくときに、
やっぱりプロセスが無理ゲーになってないかっていうのは、
ちゃんと見なきゃいけなくて、無理ゲーになってたらすぐ変えないと、
結局それでチームのメンバーが疲弊してしまうとか、
消耗してしまうみたいな話になっちゃうので、
そうならないように手を打つっていう意味でも、
可視化をするレベルをちゃんと開発するスピードとか、
テーマとか内容に動機を多分していくようなことが
いるんだろうなみたいなのを今聞いてて思いますね。
ヤギさんもプロセスって一回作って終わりじゃないと思うんですけど。
30:00
ダメですよ。
ですよね。
棚にしまってもしょうがないので。
見ていったりとか常に確認しなきゃいけないところだと思うんですけど、
大体どれぐらいの感じで見るとかっていうのがあったりします?
業種というか業務の内容によると思うんですよ。
定型業務であれば1回作ったらそんなに変わらない。
毎年年に1回発行する決算書を作りますとかっていうのは
多分年に1回しかないので、
しかも多分あんま変わらないよねみたいなのがあるんですけど。
一方でプロジェクトみたいなものを書くと、
開発のプロジェクトでも何でもいいですけど、
その場合ってやっていく途中で変わるんですよ。
状況がいやいやとか、
外注使ってたら品質の悪みも上がってきましたと。
どうしますかみたいな。
あと不具合が起こったんで、
頑張ってテストしなきゃいけませんみたいな話になると
人突っ込むよねみたいなのがあると、
もともと立てた計画通りなんかいかないわけで、
そしたらその度にプロセス見直さなきゃいけなくて、
これちゃんと現状から見ても最終的にやりたいゴールに
ちゃんと繋がるんだよねっていうのは
常に確認しながら変えるべきとこは変えていく、
省略できるそこは省略したりとか、
これとこれ合わせれるよねとか、
こっちの成果物これに使って別のもの作ったら
実は早く回るんじゃないのとか、
これ今シリアルになったけどパラレルにできるよねとか
っていうのはやりながら進めないといけなくて。
なのでプロジェクト型だと多分走りながら変えていく
っていう世界かなと。
定型業務だと例えば年1だったら
1回作ったらそんな変わんないよねみたいな。
性質によると思うんですよ。
さっきのマルタさんの話、
プロダクトが変わっていくたびに
プロセスは変えるべきだなと思います。
そのパターンでいうと少なくとも。
スタートアップでやってるときだと
多分プロジェクトと同じで状況が多分仮説立てて
試してみて、でもう実は違って
なった瞬間に多分業務プロセスも
アップデートかけなきゃいけなくて
っていうのを多分裏で走らせるべきとは思います。
なんとなく専門家的には。
そっちに手間取るぐらいだったら
物を作れよみたいな思想になるのも
個人的には理解しました。
なので多分あんまりプロセスかける人
世の中にいないなと思うのも
その段なのかもしれないなと。
確かに後回しにはされがちなんですけど
でも結構活動の根幹に影響を与えるような
要素でもあるので、本当は多分これをちゃんと
設計した上で臨んだ方が
事故ったりとか無理げーにならないですよね。
そこはやっぱりそういう取り組みを
ちゃんと取り入れていくっていうところが
大事なんだなと思っていて
それをある種仕組み化をどう考えていくか
33:02
っていうことにもなるのかなと思うと
やっぱりお客さんリードするような
CSを組織として作っていくっていう意味だと
お客さんからこのCSチームもしくはこの会社は
すごく頼れるみたいに思ってもらうっていうところって
絶対仕組み化は避けて通れないので
そこってどうやってやっていくのっていうのは
リードするっていう個人の中の話
少しリーダーとしての采配の話は
今日教えてもらったんですけど
次回仕組みってどういうことをやるとうまく
仕組み化できるんだっけみたいなことを
もうちょっと深もっていくといいかなと思うんで
次回そこぜひやらせてもらえると
嬉しいなと思います
ありがとうございます
よろしくお願いします
