構造化の定義と重要性
CS Harmony Radio、前回のシリーズでは カスタマーサクセスにとっての
言語化というテーマで話してきました。 前4回あったんですけど、このシリーズ
を話してきた内容も記事にまとめて おりますので、ぜひご覧いただければ
と思います。よろしくお願いします。
よろしくお願いします。
はい。今回のテーマなんですけれども、 カスタマーサクセスにおける構造化
スキルの重要性というテーマで 話していきたいと思います。こちら
はこれまで話してきた、前シリーズ の業務モデリングのお話と、前シリーズ
の言語化の内容をつなぐような 立ち位置のお話かなと思っていて、
結局、モデリングで自分の頭の中で のシミュレーションだとか、思考
の深掘りみたいな話をしつつ、前シリーズ で言語化で、それをちゃんとお客さん
に発信して理解を深めていく話を してきたんですけど、やっぱり
この中のモデリングとして深掘って いくところの話と、それをアウトプット
で言語と出していくときに、そこの アウトプットをどう作っていく
かっていうところに関しては、構造化 して見せていくっていうのがかなり
大事なところなので、これについて 今回はテーマとして話していきたい
なと思います。
はい。
構造化って、大体皆さんなんとなく イメージはあるとは思うんですけ
れども、一応、じゃあ構造化って 何ですかっていう話をしていきたい
なと思うんですが、構造化の定義 なんですけど、物事の全体を定義
した上で、構成要素と構成要素間 の関係を整理する取り組みである
というふうになっていて、これは ゴールと手段のような関係整理
かなと思うんですよね。つまり何を 言っているかというと、あるゴール
として定めた目標に対して、いろん な手段というのが構成要素として
あって、それの構成要素をちゃんと 分解して関係づけていく。これは
多分いろんな方が普通にスキル的に 持っているところだと思うんですけど、
個人的にはこの要素分解していって ちゃんと関係づけていくっていう
ところは、CSにとっても重要なスキル かなというふうに思っています。
これに関しては、補造課自体、ヤギ さんはモデリングや業務分析を
研究しているんで、その辺について はどういうふうに捉えていますか。
定義としては、暗論ではそうなんですよ ね。基本的には分析と一対になっている
ものかなと思って、分析って何か というと分けますっていう話と、
それの関係性を記述しますっていう、 意味付けしますっていうところ。
CSにとってというよりかは、ビジネス スキルとして基本的によく使う技術
なんじゃないかなと思います。別に この構造課を意識してなくても、
例えば提案資料を作るであったり とか、Excelで何かをまとめるとか、
計算しますとかっていうのもある意味 構造課を作ろうとしているところ
だと思うんで、普通に皆さんやら らせる内容なのかなとは思います。
そういう意味だと、たぶんCS特有 って話ではなくて、標準的なビジネス
スキルっていう側面が大きいかな と思うんですけど、丸田さんはここで
コメントあればお願いします。
CSという仕事自体がお客さまの 業務を理解して、その業務の中に
おける課題解決をどう自社のサービス で実現していくかっていうことを
考える仕事なので、必然的にたぶん そこの構造課をして考えるという
スキル、ベーシックかつ重要になって くるだろうというのは思います。
そうですよね。重要だと皆さん思 っているんで、たぶんこれ自体は
構造化していくことって、ビジネス 上は非常に良いことが大きいっていう
ところだと思うんですけど、じゃあ その辺ってどんなメリットがある
のか、その部分も話していきたい なと思うんですが、構造化できる
ところのメリットって、皆さん思いつく ポイントとかいくつかあるとは
思うので、それぞれ聞いてきたらな と思ってます。まるさんの趣味だと
CSの業務の中で、構造化とかしている ときに感じるメリットとか、業務
的に普段やってたとか、そういう 話があればぜひ教えてほしいん
ですけど。
構造化のメリット
CSにおいて、いかにチャーン率を 下げるかっていうのが大きな命題
の一つになってくると思うんですけど、 チャーン率を下げるためにどう
すればいいかっていったら、お客 さんにとって自社のサービスを
インフラ化する。つまり、当たり 前に使ってもらう、なくてはならない
ものにしてもらうっていうもの がすごく大事なんですけど、それ
において、お客さんの業務フロー の中にいかに自社のサービスを
入れ込んでいくか、それは追加で 使ってもらうでもいいですし、BPR
みたいな形で何かを置き換えて いく、変えていくっていう形でも
いいんですけど、お客さんの業務 がどういうふうな要素に分けられて
それがどういう関係性になっていて、 その中にどうサービスを入れ込んで
いくといいのか、それを戦略として 考えていく上で、例えばプレイブック
とかジャーニーのような形できちん と体系化した上で、チーム全員に
それを理解してもらい、実行できる ように伝えていったりとかは、
すごく大事ですし効果的だと思う ので、そういう業務の中でどう
お客さんにサービスをインフラ として使ってもらうかとか、それを
誰でもできるように体系化して チームに伝えていくかっていう
ときには、すごく構造化をして 語る、構造化をして考えるっていう
のは有効だったなと
ありがとうございます。八木さん、 日々実感されてる立場だと思うん
ですけど、どうですか?
構造を考えるのって、資料を作る 時に個人的には一番よく使うん
ですけど、納得してもらうことに 構造って結構動力で、自分がもや
もやしてるやつをもやもやずっと 喋られるよりかは、構造的に全体
感はこうで、今ここの話をしています よって思ってこういう結論なので
こうなります、みたいな説明をされた 方が得するじゃないですか
そうですね
自分もそうですけど、プレーマーク でもないんですけど、納得感を得る
ということと、自信を持って自分たち が進む上においても構造化って
すごく良いのか、ちょっと重視度 高いんですけど、そういう話かな
とは、そういう意味で人にプレゼン もあるんですけど、自分自身で納得
するにも大事だとは
今の話で自信作ってのはまさに そうで、なんとなく頭の中とか
自分の中でもやっとしたのが形 になるところとしては確かにそうだ
なと思っていて、お二人の話とか でもいくつかポイントになるの
かなと思うのは、やっぱりお客さん に対してどういうふうにアプローチ
してくるとか、どうやったら納得 してもらうみたいなところの話
って、関係者とコミュニケーション を取りやすくするっていうところ
がすごいベースにあるんだろう なっていうところが大きなポイント
なし、それはメリットだなって 思いますと、さらにそれをやる上で
結局ある程度、どこからやるとか どれが大事かみたいな話ってやっぱり
構造化していく中で優先度みたい なのが見えてきて、そういうことが
設定しやすくなるっていうところ も多分自信とか納得感につながる
ところだと思っていて、この優先度 が設定できるっていうところが
非常に良いかなと。そんなときに 優先度を決めるのはなんだっけ
っていう話って、僕らも客理解の 話でしてましたけど、結局どれが
大事かとかってどれやるべきみたいな 話の、やっぱり物事の重要度を設定
するっていうところの課題の本質 みたいなところにやっぱり突き
詰めていく、その辺りをちゃんと 整理していく、そんなところが
メリットとしては大きいなって なると、これってやっぱりお客さん
とコミュニケーションを取る 立場としては、CSってマストな存在
なんで、やっぱりその部分とか だけ考えても非常に大事だし、
そこの中で導いていくときに優先度 決めたりとか、課題本質の内容
を表現する、非常に求められる ので、構造化メリットすごいある
よなっていうところですよね。 多分構造化って少し視点を変える
と関係性を捉えるようなアプローチ だったりするのかなって、個人的
には思っていて、多分構造化する ときの関係性の形によって図式化
というか表現が変わってくるのかな っていうふうに思ってます。
関係性と構造化の本質
思いつく関係性ってパッと思うん だと、方眼する関係性とか、あとは
因果ですよね、よく言われる因果関係 とか。あと因果関係で出てくると
相関みたいなものがあって、こう いった関係いくつかあるかなと、
今の構造化の話につながってくる ところかなと思うと、方眼みたいな
やつって多分ミーシンにも近いん ですが、要素の状況を整理していく
みたいな関係だし、因果だとその要素 自体がどういうふうにつながって
影響与えるかみたいなとこ見てる し、相関はそれよりも弱い関係性
で関係してますよみたいなことを 言ってそうな形には見えるんですけど、
なんだろう、感覚的な話で言っちゃ ってるんであれなんですけど、ヤギさん
から見たときに、構造化するとき って関係性を捉える視点で見た
ときって、こんなふうに関係整理 できるとか、こういう観点で捉える
と、よりそのあたりの構造化の本質 が見えやすくなるとか、どうでしょうか。
そうですね、構造って考えるとき 一番最初に堀さんが提起の方に
質問をされたんですけど、2個ないと だもん、2個以上ないと構造って
その間の意味を作っていくっていう のが大事ですね。この部分と全体
もそうですし、相関の話ちょっと やり始めると、正直2、3時間しゃべ
れるんですよ。
じゃあまた別のときに。
そうですね。面白い場所だけ言うと、 因果関係って我々思ってるのって
相関関係と多分あんまり差がない ですよ。
自分の認知で、例えば太陽は東から 昇りますっていうのは、毎日だいたい
東から昇ってるんで東から昇ります って思ってますけど、経験則に
当てはめてるだけなんで。
結果的に相関だろうが、因果だろう が、あんまり差がなくて。
確かに。
誰が明日西から昇らないって言える っていうのに関しては、
手図学の話になっちゃうんですよ。 突き詰めると因果関係って。
それだけで本ができたりしてるぐらい で。
なるほど。
それを語り始めると厄介なんで 語りませんが、いずれにしろ相関だろう
と因果にしても、基本的に2個の 関係性をどう捉えてるかという
ところが大事なので。
一番重要なのは、混ぜちゃいけない ところ。
部分と全体の関係性を記述してると、 今するならば因果の話は持ち込まない。
因果の話をしてる時に部分全体の話は 持ち込まないと。
2個の関係性はどういう関係性なのか というのをちゃんと捉えた上で
話をしないと、混ざってしまって 何だっけみたいな話になりがちなので。
そこの部分の関係性のところは 注意はそこかなと思います。
因果関係を方言関係でもう一回 捉え直せるとか、抽象度を上げたり
とかするじゃないですか。
ヤギは男性であるっていう命題が あった時に、ヤギは人間なんで
それをそのまま抽象度を上げると 人間は男性であるみたいな言葉になるじゃないですか。
で、間違ってるのはわかるでしょ。 これ簡単な例ですけど。
ここは混ぜてるからそうなる。
確かに。今の話触りだけですけど、 因果と相関の話も
ちょっとさっきヤギさんがおっしゃったように
違いの大差ないっていうのは多分 人の都合というか人の解釈で
これは因果だと言ってるから そういう風に見えてるっていうことですよね。
そう、そうだけです。
これはこれで非常に沼が深そうなんで これはまた別でぜひやりましょう。
はい、ありがとうございます。
多分混ぜないっていうのは大事だと思いながら
形っていうところに関して言ったらいいのかな。
構造化する形って結構モデルみたいなものが 決まってるかなと思っていて
これまでの先人の知恵とか試行錯誤から 修練されてきてるような気もするので
この辺りについて議論というか 話したいなと思っていて。
構造化の形について
構造化の形って何ですかってなったときに
やっぱり思いつくのはさっきの 全体と部分みたいな話で言うと
マトリックスだったりだとか ピラミッドツリーみたいに
マトリックスだと多分全体領域の中で どの領域を占めるみたいな話の
部分の表現としては最適な形だし
ピラミッドツリーみたいなのと 一つのゴールというか形を頂点として
その内容に対する具体要素を どんどん洗い出していく形になると
ツリーの構造になるの これは見えるんですけど
あとは業務の流れみたいなところっていうのも
手順とかでモデルとしては示すので
構造化っていうとこの三つの形っていうのが
割とベーシックにみんな使って 活用してるかなっていう気がするんですが
お二人だとこういうアウトプット よく使いますよみたいな話があれば
マトリックスなのか ピラミッドのツリーなのか
フローなのか それ以外なのか
その辺りの実用でよく使ってるものがあれば
ちょっとコメントもらいたいんですけど
構造化のスキルのメリット
Zoomの中で使ってるって言ったら
表現の仕方は色々あるかもしれないですけど
マトリックス ツリー フローで
だいたいカバーできてるんじゃないかなとは思いました
あ 遠い間出てこないんですけど
ヤギさんかがですか
私もそうです
もう1個考えられるのがネットワーク図みたいのがあるんですけど
ネットワーク図は多分フローにないのかと思うと
これ多分全部可能
自分がどれ使うかっていうと
多分全部通貨
1個ずつ例を言うと
マトリックスの場合だと4章限で書くので
例えばポジションがどうですかみたいな
ターゲットセグメントみたいに言うとそういうやつもありますし
例えば技術の進歩は他社はこうなっているので
うちはこうしていきますみたいなやつを書いたりするとき
マトリックスはよく使います
ツリー構造を書くときに関して言うと
わかりやすいのはKPIツリーみたいなやつ
あとはゴール構造とかね
ゴール構造って何か目的と手段を分解していくようなやつだとそういう
あとロジックツリーはツリーですね
自分がよく使うのはゴールもそうですけど
ファインドマップをよくツールでは使います
これはもう完全にメモ書きする場合と記事録的にする場合と
あと自分で何を考えているのか整理する場合と
両方使っている感じですね
フローは完全に業務フローを書くとき
それなんでそういう
あと問題構造を書くときも
どっちかっていうとフローとか
なので結構全部普通にまんべんなく使っている
なるほど
ちなみにマルザさんはそれぞれ使っているとおっしゃってましたけど
CS業務もしくは普段の活動の中とかで
近度の話で言うと差とかあったりするんですか
CSのメイン業務として
お客さんをこういう手順で支援して
進化といったあれですけど
ステップを踏んで支援していく
育てていくみたいなのがメインなので
そういう意味だとフローとかは結構頻度は多いかもしれないですけど
割とその構造化的スキルであったりとか
その中で使うマトリックス ピラミッドツリー フローズとかは
パソコンのツールで言うところの
Word Excel Power Pointみたいなもので
割とその基礎的にどれでもいつも使うぐらいなものなので
特別これをすごく愛用しているというのはないかもしれないです
ありがとうございます
2人ともどれが偏っているというよりは
全部まんべんなく普段の業務から自然と使っていることなんで
切り取ると構造化って行々しいんですけど
身近な話なんだろうなと
ということは構造化って何ですかって話
普段の業務でやってることに起因する活動で
それに関して一定のスキルを皆さん持って
使われてるっていうところだと思うんですけど
じゃあそういう話って身につくと
どんないいことがあるんだっていうところの話とか
意識せずにやってる部分もあるんで
少し言語化してもらうとか
改めて考えてもらう部分があるとは思うんですけど
身につくスキルってどういうところがあるのかなっていうところを
次回話していきたいと思いますんで
今回はここまでにしたいと思います
ありがとうございます
ありがとうございました
