手段の目的化とは
CS Harmony Radioです。よろしくお願いします。
よろしくお願いします。
今回からあまりモデリング編とか番外編とか言わずに、話題をそれぞれ持ち寄って話していくっていう形にしていきたいなと思うので。
年明けになりましたし、新年一発目。
年明けにしてはだいぶ経ってますけど、すいませんって感じ。収録自体は年明けって感じですね。
とはいえ、話す内容は基本的には顧客理解を高めていくって観点で話していくんで、カスタマーサクセスに関わるところもあれば、そうでないところも含めて話していこうかなと思ってます。
なので、ぶっちゃけもちろんネタとかあまり変わってないんですけど、今回は僕の方から持ってきた話でちょっと話したいなと思っているテーマがありまして、
手段の目的化ってどうやったら防げるのかっていう話ですね。
ちょっと大きいテーマなんですけども、結構よく起きるじゃないですか。
はい、よくありますよ。
よくあるってことは再現する問題っていうことなので、これに関しては手が打てるんじゃないのかなみたいなことを思ってまして、
そこについてしっかり考えてみたいなと。
というところがあってですね。まず冒頭、なんでこんなことを持ったのかっていう話なんですけど、
最近とかもカスタマーサクセスの会話してるときにちょっと驚いたことがありまして、取り組んでる人からしたらわりと当たり前の話もあるんですけど、
クラスやってない方からすると新しい観点だったり考え方だったりする部分もあるんで、本とか読んだ影響で会話してくるパターンもあるんですよね。
そうすると、CSの概念とか本質的理解は一旦差し置いといて、CSの手法とかのジャーニーマップ作りたいみたいな話とか、
プレイブック作りたいみたいな、ヘルススコア設計したいみたいな話あるんですけど、そもそもこの事業ってちゃんとそういうことってできるようになってるんですかみたいな話とかがあんまり検討されてなかったりとかするんですよね。
そもそもってやつですね。
そもそも。で、なんでそれやりたいかも、CSの概念とかに沿って考えると、基本的にはお客さんを事業成長させていくため、UIのサクセスさせるためとかって話があると思うんですけど、
より効率とか自動的にお客さんを管理できたりするんじゃないかみたいな、あんまりサクセスとかそういう話じゃなくて手法をやりたいみたいな。
そういう手法をやりたいと思っているところにちょうどよくこんな考え方があるからやってみたいとか、そういうニュアンスの相談が強かったんで、
これなんかCSの話なのかよくわかんないなみたいな風に感じるくらいの曲解もあって、コメントに困ったっていうところですよね。
目的の構成要素と関係性
で、こういう話って結構あるなと思ってて。
カスタマーサクセスと関係ない場合でもっていいんですね。
そうです。カスタマーサクセスの場合はまだマシだと思うんですけど、まだそんなことあんまり起きないと思うんですけど、バズワードとかだとむっちゃ起きてて、
だとAIとかね。ちょっと前だとWeb3とか言ってましたよねみたいな。もう最近聞かなくなってきましたけど。
聞かないですね。
ちょっとねじれるとDXとかね。
そうですね。DXまだいますね、名前は。
そういうところの話でいくと、それをやることが目的化されてませんかみたいな話になかなっていることが多いなと思ってるんですよ。
そうですね。
で、これって昔から起きてるなっていう僕認識なんですよ。
昔からありますね。
今に起きたことじゃないじゃないですか。
そうですね。
だからずっと繰り返すってことはなんか理由があるんですよ。
構造的問題ですよね。
そう。なんで構造的問題になったら、いわゆるモデリングできるじゃないですか。
だから構造的問題をちょっと明らかにすると、そこを多少なりとも防げたりとか、考え方的に予防をはれるとか、そういうこともあるんじゃないかなと思いまして。
その辺の話をしたいなと思いますと。
で、抽象度高いテーマではあるんですけど、手段の目的化ってよく言われる話の、じゃあ目的と手段ってちゃんと一応は決めといた方がいいよねっていう話で、
これがないと多分話がさらにちょっと違かると思うんで、そこの話からしていきたいなと思うんですけど、目的っていうものはまずは定義で言うと、最終的に成し遂げようとする事柄や目指すべき到達点を目的としますね。
手段はあることを実現させるために取る方法っていうふうにしますと。
なので、この定義2つ並べてみると、目的って成し遂げたい事柄があって、それに対する実現方法に手段がありますよねっていうことになるじゃないですか。
だから、モデリング観点で考えると、目的っていうのの構成要素の中に手段がありますよねっていう、ちょっと抽象度高いですけど、そういうことになるかなと思うので。
目的っていうものは手段を含んでいるはずだから、手段が目的化するってことはなんか反転してるからなんかおかしいんですよね、きっとね。
そうなったくると、ちょっと次に話したいなと思うのは、じゃあ目的って他にどういうこと考えると、その構成要素として成立するものがあるんですかねみたいな話があると思っていて。
そこをちゃんと見ていくと、いわゆる手段と目的だけの関係なのか、違うものもあるのかみたいなところもあると思うんですよ。
だからそこがちょっとまず整理するポイントかなというふうに思ってるんで、それを特化代わりに少し考えていきたいなと思いますと。
そうすると目的って、ちょっと抽象的なんで、一回もう少し具体的にすると、企業の活動で目的って何ですかとかっていう話になると、基本的に企業のビジョンとかで書かれてるものがあるじゃないですか。
企業ビジョンみたいな。これが成し遂げたいことを書いてますよね。我々こういうことをします。それが目的じゃないですか。
そうなると、そのための達成するための手段っていうのが、達成するための取り組みが手段であるっていうことになりますよね。
でなると、じゃあ目的と手段があって、ビジョン決めました。そのために取り組みやります。でなるとうまくいくんかなみたいなところだと思うんですけど、ここっていろんな捉え方あるし考え方があるんで、意見様々ですけど。
手段を実行するための要素と計画の重要性
例えば僕の観点の整理で言うと、取り組みっていうものだけだと、何をどうやっていいかわかんないから、計画がいるんじゃないかなと思ったりするわけですよ。
実行計画?
そうそうそう、実行計画ですね。事業計画と言ってもいいと思うんですけど。で、なんでそういう話するかというと、だいたい上場企業って中期経営計画みたいなもの出すじゃないですか。
出しますね。
だから計画って必ず事業の目的とか持った企業体としては発信してるものだし作ってるものだから、計画っていうのはいるんじゃないかなっていうことだと思うんですよね。
で、そこの中にこういうことをやってきますみたいなことが書かれるわけですよね。で、それを具体的に実装したりとか実現するための取り組みが手段じゃないですか。
何々活動とか何々組織での何々の取り組みみたいな。計画の中にはそこの具体的な進め方までは書かれないので、基本的にはこういうことを考えてこういう視点とかKPI決めて達成してきますみたいなことを語ってるっていうものだから、目的達成するためには計画もいるんじゃないかなっていう、そういうふうに僕は思いますと。
はい、言いますね。
なんでまあ多く言うとこの計画っていうのがないと手段だけあっても難しいんじゃないかなっていうふうに思いますってところなんですね。
そうすると手段が目的化するっていう話になっていった時に計画がすっ飛ぶんじゃないかなっていう気がするわけですよ。
計画を作るのがつまり大変だから手段の方に走るから手段の目的化になるのではないかみたいなことがまあ一つの仮説ですよ。本当そうなってるかわかんないけど。
そういうふうにもなんか取れるかなと思ってて、その時にじゃあまず手段っていうものをもうちょっとブレイクダウンするとどんな要素があるかなっていうところですけど、これもいろいろ多分考え方はあるんですけど、
例えば僕のその観点の切り口だと手段ってものにフォーカスするとまず手段なんでやることがあると。そうすると実はやるリソースがいるじゃないですか。
リソースっていうのは人物、金、今だと情報もあると思うんですけど、そういうリソースがないとまずダメですよねと。要は手段を実行する人たちとか実行する資源みたいなものがいると。
で、この実はそれだけやるとうまくいくかっていうと計画がいると思っていて、いわゆるその手段を実行する実施計画みたいなものがいると思うんですよね。そうすると計画とリソースっていうものがあると手段が実行できるのではないかみたいなことなんですよ。
計画って今日行々しく言ってますけど、いわゆるこういうことやろうとかっていうのを決めないといけないじゃないですか。組織だと。一人だったら自分の中でこれやろうと決めてこれやればいいと思うんですけど、例えば5人とか10人とか複数人がいた場合は、我々はこういうことをこういうタイムスケジュールでこんな風に取り組んでいきましょうねみたいなことをある種計画しないと、
それで合意しないとみんな動かないし動かせないと思うので、そういうことがいりますよねっていう。たぶんそこの中には倫理とかもっと細かい要素あるんですけど、バクッと言うと計画とリソースがあると手段っていうのは実行できるんじゃないかなっていうところなんじゃないかなと思うんですよ。
この流度でバクッと話すと、事業計画って何いるんですかみたいな話があるかなと思ってまして、これに関して言うと外部の情報と内部の情報があるんじゃないかなと思うんですよね。計画作るとき。
会社の内部と外部ですね。
「手段の目的化」について
それって例えばリソースみたいなものとして現れているものもあれば、目的みたいなものもあると思うんですよ。ここちょっとややこしいと思うんですけど、つまり計画を考えるときって、今までの目的を達成した状態だとしたらまた新しい目的を作るんで、なんかそういうふうに目的自体もアップデートされるみたいなこともあるんで、内部ってそういったことの話もある上でリソースもあるかなみたいな感じなんですよね。
で、外部はじゃあ市場環境って何ですかって話になると、基本的には市場のトレンドとか動向とか、マーケットサイズみたいないわゆる市場分析で分かるようなことが出てくるっていうところじゃないですか。
なので事業計画ってそういう外部のものの環境を見て、内部の環境も見ながら作っていくもんだろうなっていうところなんじゃないかなっていうふうに思うわけですよね。そうなってくると、じゃあ手段の目的かって何で生み出されるかって話のちょっと仮説というか想像なんですけど、計画作るのが大変、特に外部環境とか調べたりするのが、
コストとかリソースかかるから、そこが大変だから手段だけ実行する方が楽な時にそういうことが起きるんじゃないのかなっていうイメージなんですよ。言い方変えるとなんか実現コストが低いんじゃないかなと思ってて。
手段をやろうとするコストっていうことね。
計画された手段を実行するコストっていうことなんですけど、目的達成のためには計画しなきゃいけない。計画するときに計画に対してすげえコストかかるから手段だけ考えて実行するっていう方に流れがちなんじゃないかなっていうふうに思うわけですよ。
それは何でそう思うかっていう話なんですけど、3つあるかなと思ってて。1個目はですね、やればいいんじゃないかなと。ちょっと単純な理由なんですけど。
そう思ってる人がやればいいと思ってる。
手段を実行するにもコストがむちゃかかるってところで言うと、手段はコストがまず低いから、まずやりますっていうことを目的化しちゃうと、もうやれば良くなるんで、そこで手段実行しやすくなるっていうことになるでしょうっていうのが理由その1。
理由その2が、これ多分企業組織のサイズがでかくなってくると起きるかなと思うんですけど、責任を取る必要がない。まあ言い換えると責任を曖昧にできるっていうところかなっていう。
そのやることに対する責任を曖昧にできる。
そうそうです。つまり何言ってるかというと、立ち上げてその取り組みっていうのが効果出るまで5年ぐらいかかりますみたいなプロジェクトだとすると、その5年後もその立ち上げた人が関わってる。
手段の目的化の理由
いるかどうかわからん。
そう、わからんじゃないですか。
わからんですね。
そうすると担当変わる頃には自分が実行してたやつとかって、もう自分担当じゃないみたいなことになると、立ち上げた時の行動は評価されるけど、その行動したことで目的達成されたかどうかっていうのを見る時には自分はいない状態になってるみたいなことがあると、曖昧になりがちなんですよね、きっと。
それがシンプルだったら辿っていくと、いやいやそもそも考えたあなたが悪いじゃないですかみたいな話になるかもしれないですけど、関係者が増えれば増えるほど複雑になるんで、いやこの人の責任だけとは言い切れないみたいな話になると、もう曖昧になってくるんで、そうすると結局現在やってる人でどうにかしようみたいな話になると、責任を取る矛先としても自分がやる必要がなくなるから、
やった人はやった後その後、やったことだけで評価されるみたいな構図があるのではないかなっていうふうに思います。で、3点目が情報操作しやすいってことかなと思って。
これ何言ってるかというと、さっきの事業計画みたいなところの話って、大変ですよねって話したじゃないですか、作るのってなると、手段だけで考えた場合って別に事業計画まで必要ないんじゃないですか。いわゆる手段を実行するために作業計画みたいなものはいるんですけど、リソースと作業計画があればできますと。
でもその時に目的との整合性を合わせるっていう時には、事業計画をちゃんと作る責任はないんだけれども、その事業として必要なことをやるっていう時に、事業計画で集めてきたりとか整理する要素をつまみ食いできる状況になると思うんですよ。
そうなると、例えばバズワードとかって、今こういうキーワード流行ってますみたいなことって、本当に自分たちの事業に必要かどうかは置いといて、世間とか市場でそういうニーズがあるよっていうものを取ってきて取り組みしましょうみたいなこととかっていうのはやりやすい。それが本当に必要かどうかっていうのは、ちゃんと事業の計画を考えるぐらいしっかり精査しないと判断できないんだけれども、
手段ベースで考えた場合は、そこまで精査する必要がない状態でも実行できてしまうので、上位要素をうまくつまみ食いして持ってこれてしまうっていうことになると、こういうこと大事って言われてるからまあそうかみたいな話とかで、推進側としては、うまくつまみで持ってきて説明しやすいんじゃないかなっていう気がするんですよね。それが情報操作しやすいっていうことです。
ちょっとあってかわかんないので確認ですけど、走りながら考えれるからいいっていうことですね。
まあそれもありますね。いわゆる都合よく取られるってことですよね。つまり、今だったらAIって入れましょうとか、AIって事業に対してすごい影響ありますっていう話とかって言えるじゃないですか。
「手段の目的化」の防止策
例えばここのこういう事業でこんだけ影響ありますっていう話とかって、すぐ引き合いに出せると思うんですけど、ただ事業計画とか中期経営みたいなところで考えるときに、事業としての上り方とか考えるときに、そのAI自体のリスクとか懸念みたいなところまでは、本来は考えてそういうことって計画に織り込んでいくところを、
そういう負のリスク名みたいなことはあんまり見ずに、こういうこと大事だっていうところとかを取ってきて実行するための後ろ盾にしたりすることがしやすいっていう、そういうイメージですね。伝わるかな。伝わってるかな。
意味はわかります。
だから、結構都合よくそういういろんな情報を取ってきて説明できちゃうんじゃないかなっていう気がするんですよ。整合性がそこまで求められないというか。
なんかでもヤギさんが腹落ちしてない感じがするけど。
最後のがちょっと解釈的にどうなのか。理由1、2はなんとなってる?
おだしょー 走りながら考えるっていうのは、例えばどんなイメージ?
POCやりましょうみたいな。とりあえずやってみて考えましょうみたいなのはよくあるパターンかな。それなのかなと思って聞いたんですけど、ちょっと違う感じ。
おだしょー それではないですね。それも一種の情報操作だと思うんですけど、つまりやることが目的なんで、成果はいったんいいけど、やらせるためにこういう取り組みしたいですよねみたいなことを言うっていうところですかね。
今のヤギさんの話はどっちかというと、やればいいみたいな。やるといいっていう話に近いかなって気がします。僕の中だと。POCしましょうもん。POCをすることが目的になってるから。
おだしょー うんうん。それはそうですね。
それってPOCやるとわかりやすいからじゃないですか。
おだしょー なんか説明しやすくなるとか。
そうそうそう。やりましたということでアウトプットが出るということになるので、やれば良いだけみたいな。
おだしょー 1個目の理由に近い。
そう、1個目の理由に近い。情報操作はいわゆる説明がしやすいって感じですかね。
おだしょー 社外の説明とか。
そうですね。中の層。なぜなら目的の場合は社外も見ますけど、手段の場合って中だけでいいと思うんですよ。議論が基本的に。
おだしょー 中だけ説得できればいいかな。
手段を実行するときって別に投資家の承認まで得ないじゃないですか。
もちろん目的達成とか企業のビジョンとか計画は承認はあるんですけど、やるときはそこまで見ないですよね。だから説明コストが低いんですよね。
おだしょー なるほど。
そのときの理論武装として情報操作しやすい。
おだしょー なんとなくわかりました。完全に一致してる気がしてないですけど、一旦大丈夫です。
ちょっとこれいろいろ捉え方あるんで、僕は3点あると思いますって感じですね。他にもあるかもしれないし、もうちょっと修練できるかもしれないですけど。
こういうことで生み出されてるんだと思うんですよね。だから結局やると手柄にもなるし、それに対して責められることが少ないみたいなことになると、やりがちなんじゃないかなって気がするんですよ。
だから手段の目的かみたいなことって、その組織構造的に複雑で曖昧になればなるほど起きがちなのではないかなというふうに思います。これはちょっと予想ですけど。
つまり組織が複雑ででかくなると起きがちになるってことは、企業が成長すると起きがちっていうことじゃないですか。
なので、大きくなると成りやすい構造だよねって話かなと思うと、それを防ぐにはどうしたらいいでしょうかみたいなことがちょっとあるかなと思っていて。
そこについて観点まではなんかちょっとあるかなと思ってるんで、その観点の話をすると、やっぱり目的に立ち回らないとダメですよって話ですね。
つまり目的の構成要素の手段なんだから、その手段が目的の構成要素とちゃんと整合性取れてるかどうかを確認せずやってるのが問題なんで、前提条件が整ってないけどやっちゃってるってことじゃないですか。
整つまり。ってことは前提条件確認すれば基本的には防げるんじゃないかなっていうことですよね。
で、難しいのはその前提条件の確認の仕方が難しいんじゃないかなっていう気がするんですよ。
前提条件の確認の重要性
分かってない人とかが、実行しようとしてる人をちょっと待ってっていうことを言えるだけの前提の確認の仕方がむずい。
で、さっきの情報操作みたいな話は、まあそういうところでも言えるかなと。
つまり、これって本当に今やる必要あるんですかみたいな話をしたとしたときに、
いやいや今こういうふうに先生AI来てて、今こういう取り組みしないとダメじゃないですかみたいなこととか言われるときに、
明確に反論する術がなかったりとかしちゃうと、まあ確かにそれも一理あるなみたいなことになって通しちゃうと、
実は目的とちゃんと整合性が取れてない実行手段が、そういうときに通って実行されてしまうみたいな。
そんな感じが起きるかなっていうところなんで、前提チェックが甘いのではないかみたいなことが起きてしまってて。
だからその前提条件をどう確認するかっていうのがむちゃむちゃ大事なんじゃないかなっていう。
そうですね。それをその通りだと思います。
結構すごい当たり前のこと言ってるんですけど、でもその当たり前が、
そんなに長い時間話して当たり前のことが難しいってことですよね。
そうですね。ちょっと話を膨らませるわけじゃないんですけど、付け加える感じになるかと思うんですけど、
手段と目的の関係性ってロジック的に言うと、必要条件ロジックっていうロジックになるんですよ。
目的の何とかのために何とかっていう手段をしなきゃいけない。
このロジックって何かっていうと、前提条件が裏に隠れてて、それが成り立たないと整理しないんですよ。
例えば売り上げ上げるために生成AIを入れますって話だとすると、
何かの条件、生成AIを入れて何らかの条件があるから売り上げが上がるっていう、
何らかの条件が明確になってない状態でやると、
生成AIっていう要素はいるかもしれないけど、目的まで達成しないって状態になる。
とある条件のもとにその手段をやると目的を達成するっていう、とある条件っていうのが必ずいるんで、
多分それが前提条件。
で、それが基本的には経営計画とか、ああいう計画の中に織り込まれて検討されているはずじゃないですか。
基本的にはね。
そうですね。だからそれを補完する情報がそこにあって、だからこれをやるとこの目的に達すんだっていうのが。
っていうのが計画としては書かれてて、
で、それをちゃんとそこに合わせて実行したらうまくいくし、
手段として正しいことが打てるはずなのに、そうならないってことはどっかが曲がっているっていうのの話が、
前提条件がちゃんとそこを確認せずにいくっていう。
で、なぜ確認しないかっていうと確認すると大変だからっていう。
かつ、確認しなくても実行できてしまうから。
そうですね。
で、実行してできてしまう理由は前提条件の確認をする人をうまく丸め込みやすいからみたいな。
っていうことが構造的にあるんじゃないかなっていう予想ですね。
次回の対策について
というのが1回目、当たり前の話なんですけど、これ多分むちゃむちゃやるの難しいんですけど、
じゃあどうやったらそのあたりっていうのを防げるかみたいな話が対策の話だと思うんで、
ちょっと次回話していきたいなと思います。
はい、わかりました。
じゃあ次回引き続きよろしくお願いします。
はい、よろしくお願いします。
