問題の構造と定義
では、CS Harmony Radio の番外編を始めていきたいと思います。よろしくお願いします。
よろしくお願いします。
えーとですね、今回も小難しいシリーズ。
孤立にやる小難しいシリーズ。
小難しい。
じゃあ、八木さんの興味のある。
興味のあるように喋ります。
前回、問題構造の話をしたんですけど、今日は問題の構造。
問題構造ではなくて、問題の構造。
これは、世の中の定義のところも兼ね合いがあるのと、あとちょっとこれは私の経験から出てきた部分もちょっとあって、それをちょっと合わせて話したいなと思ってます。
まず問題の構造なんです。問題の構造というか、問題の定義ですね。問題の定義をまずしたいなと思ってて。
問題というものの定義からってことですね。
これ、Googleってもらうと多分出てくるんですけど、問題の定義とかでGoogleといろんな書き方があるんですけど、基本的には問題を定義すると、現状と理想のギャップって大体出てくると思います。
言い方を変えると、as-isとto-beのギャップ。
要素として見ると出てくるのは、今なのか現状なのかありますけど、as-isっていう状態、状況と、こうなりたいっていうto-beと、それの間にギャップがあるっていう、3個要素が出てきますっていうのが、世の中で一般的に言われている問題の定義ですね。
これ自身は多分こうでしょうかねと、個人的に思います。
これにのっとってお話をするんですけど、ここからは似た言葉にお話をしたくて、問題そのものは大丈夫なんですけど、似た言葉で課題っていうやつがあるではないですか。
ありますね。
いろんな言い方をしますけど、君の課題はなんだみたいな話で文脈もあるし、ビジネス上の課題みたいな話もあるし、そういうのをよく言葉にする。
これが何で起こるのかっていうのを少し今日お話したいなと。
冒頭から結構ややこしい話が展開されてる感じですよ。
まず問題の構造なんで、問題と言われてるやつの構造がどうなってるかを明らかにするのが、今日やるテーマのメインで。
問題と課題の関係
そのために、まず問題の定義っていうのは何かっていうのを決めましたと。
これが、as is と to be とあった上でのギャップというのが問題ですよっていう話があって、これを問題と言うと。
その問題という定義は一旦済んだのだが、似た言葉で課題というものがありますと。
その課題というのは、多様な意味合いがあるっていうことだと思うんで、混乱を生みやすいですよね。
というところまでついてきました。
なんでこんな話をしてるかというと、問題という言葉と課題という言葉をあまり普通の人は使い分けてないと思います。
確かに。
問題っていうのはさっきの定義の構造、基本的には多分そこに対してノーっていう人はほとんどいないと思うんですけど。
課題というものがこれをどこのことを言ってるのかが実はちょっとよく分かってなくて、同じことじゃなかったりする場合があるんですよ。
もう少し具体的に言うと、さっき言ったAs-IsとTo-Beとギャップが3つあります。
もう1つ付け加えるならば、そのギャップを埋めるための解決策っていうのもこの問題を取り巻く環境の中に出てくる。
問題と全然違うんですけど、解決策が出てくるんです。
この4つを全部課題って呼びます人は。
例えばAs-Isのことを課題って言ったりもするし、To-Beのことを課題って言ったりするし、ギャップ自体は問題と同じ意味で課題って言ったりもするし、解決策を課題って言ったりもします。
これちょっと分かりづらいんで、もう少し具体的に話をすると、例えば会社の課題ですって言ったときに、例えば社長とかがですね。
うちの課題は2030年に売上2倍達成だっていう風に言ったりするじゃないですか。
それってTo-Beを言ってるんですよね。今じゃないから、こうなりたいTo-Beって言ってます。
そこで、例えばうちの課題は売上が伸び悩んでることだって言ったりもします。
これはAs-Isを言ってます。今の困ってること。
さらにですけど、うちの課題はCustomer Relationship Management、CRM導入だって言ったりもします。
これ解決策を言ってるんですよね。でも日本語的に聞いても違和感ないじゃないですか。
おだしょー ないですね。
これが、要は課題なんですかって聞くと、いろんなこと言われる厳選です。
なので、まず課題という言葉が出てきたとき、もしくは課題を問うときに、
気にしなきゃいけないことの一つで、この多義性があるので、本当に例えば問題解決したいです、
お客さんの問題を解決したいですって言ったときに、お客さんは正確に言うと問題を聞いても課題と思って
言ってくる人が結構いるので、どれのことを話してるんだというのを、
ちゃんと認知しないとややこいことが起こります。
分類の重要性
初めに今回のメインテーマはそこです。なので、この構造がAzure2Bのギャップなんです。
関連事項として解決策という四つ目のやつが出てきますっていう状況の中で、
単に例えばワークショップやってもいいですし、ヒアリングでもいいですし、
商談のタイミングでもいいんですけど、課題なんですか?みたいな話で聞くとかすると、
全部のパターンが出てきます、基本的には。そこまで分解して、
普通、お客さんなしは見てないんで、普通には考えてないんで、全部出るというのが基本としてあります。
これが厄介で、そうするといっぱい出ちゃうんですよ。4種類あるから、基本的には。
4種類あるのでいっぱい出てくるし、なんだったら流度感違く見えるんですよ。
さっきのCRMの導入と売上2倍とかって意味ちょっと違うじゃないですか。
そうですね、確かに。
これ扱いづらいんで、世の中的にはどうするかというとグルーピングするんです。
これとこれ似てるって。これがまた厄介で、そうすると中小度が高まるんですよね。
これとこれは例えば客の管理の話だと。客管理です、みたいな。客管理っていうカテゴリーに分類していくんですけど。
例えば50個出たとしましょう、課題が。グルーピングして10個にしましたと。
だいたいそれを一気通貫で検討することで普通ないので、
例えば10個にまとまったねってなった時点で、じゃあ今日は1回まとまったからやめようかって。
結果的にじゃあ1回打ち上げしようかみたいな話になる。
打ち上げするかとか置いといて、次の日にやりましょうとかになるんですよね。
作業的に大変だから。
そうなると、次の日とか別日にやったときに、グルーピングされた問題に対しては解決策を出そう。
いっぱい出そうみたいな感じになると思うんですけど。
そのときに考えるのは、グルーピングされたことに対して解決策を考えるじゃないですか。
もともと出してた課題に対してじゃないんですよ。
そうすると出てきた解決策で、もともと出した課題って言って出したやつが解決できるとは限りなくて。
なるほど。
これちょっと私はN対N対N問題って呼んでるんですけど。
いっぱい出したやつをマージして何か名前つけると、そいつに対しての解決策を考えるんですけど。
それって元にあったグルーピング前のやつに対して考えてないので、当たんのそれみたいな。
全然遠くなってるけどどうしたみたいな感じになる場合があって、これちょっと厄介ですと。
話はちょっと見えてきましたけど、今回の話は構造の話だけど。
入れ子になっているような気もしなくもないけど、かといって飛び飛んでるんですよね。
複数の構造の入れ子を繋いでまた出してるから、これ難しいな。表現が難しいな。
でも言いたいことはすごくよく分かりました。
混乱してる状態だけ認知してもらえればまずいかなと思ってて。
これに対してする解決策も実はあって、これって課題という言葉を文字面通りそのまま出してしまって、
さっきの最初に言った問題の定義の分類を無視して、全部そのままフラットに扱うからこういうことが起こるんですよ。
なのでまず問題をちゃんと適切に捉えることが大事だと思います。
AZUIZUの話してるのか2Bの話してるのか、それとも解決策の話をしてるのか。
っていうところをちゃんと切り分けてあげると、実は数多いって、
もし例えばいっぱい出そうねっていっぱい課題が出た時にも、整理がきつく数で。
本来やらなきゃいけないのは、まずAZUIZUがどういう状況で、
それに対して2Bを阻害している本当のギャップのところは何なのっていうところが大事なのであって、
そこを捉えに行くっていうのは非常に重要。
そこの分類を先にしましょうねっていうのが、今回言いたいことの2つ目。
そうですね。なんか問題定義とアプローチの話、まあまあジャンプしてるけど。
ジャンプしてる。
そうですね。これどうしようかな。
ここまでの話で差し込んじゃっても大丈夫ですか。
もちろんもちろん。
おっしゃるように、課題っていう言葉に対して目標もあれば現状もあれば、
今回定義した問題もあれば施策も全部課題っていう言葉に違法感されちゃってるのが厄介な話では、
まあそもそもありますよねっていうところなんで、
本当は言い換えた方が丁寧なんでしょうねっていうのはまずちょっと聞いてて思いましたと。
だからうちの課題はっていう時ってそれ目標ですよねみたいな話だと思うんですよね。
だからうちが目標を達成するための課題は売上げに倍達成することだみたいな話じゃないですか。
だから何かしら抜け落ちてる。
そうですね。全部言えば多分正しい。
そう、正しく言えば正しい解釈ができるんだけれども、
主語の欠落
日本語特有の業館で会話していくときに主語とか抜け落ちちゃったりとかすると結構そこっていうのが難しいよね。
みたいな話は確かにそうだなところなんで、
それを丁寧に拾っていかないとまずダメなんだろうなっていうのは思ったところで、
それが解決策につながるんだろうなっていう。
それだと多分そこ意識していれば割と対応できるんだろうなっていうふうに思ったんですけど、
逆にちょっと気になったのは、
八木さんこういう問題提起してる一方で、その辺の区別は多分聞きながらしてるじゃないですか。
その時にその確認をしたらこの問題って対策できているのではないかなと思ったんですけど、
課題感はあるんですかっていうのがちょっと気になりましたけど。
直接自分がヒアリングしたりとかしてるタイミングでは過ごしてくので全然大丈夫です。
なるほど。
他人が作った資料とか、他人が作りましたものに対しては整理してあげないといけないので、困りもちもちです。
よくわかりました。
前回話したモデリング界のスピーキングとかの話にもちょっと通じますけど、
解釈をちゃんと戦わせてないとそれは読み解けないですね、確かに。
なるほどね。
そうなんですよ。
曖昧なもののまま流していくと起きますよね。
基本的に全部。
だから曖昧だなと思ったらそれをちゃんと曖昧のままにしないようにしていくって姿勢がむちゃくちゃ大事なんだろうけど。
なんか訓練。
そう、訓練ですよね。
訓練なんだろうなってちょっと思って聞いてました。
この話とか結構すると、そうですねってなりやすくて結構、
じゃあちょっと考えてみますとかそうなるんですけど。
できないんですよね。
しばらく経ってもう一回見るとやっぱりなってなくて、また考えていってるし。
多分、結構ちゃんと腹落ちある体験しないと改めない話のよくある典型的なところだと思うんですけど、
深刻な課題とか悩みごとにぶち当たるところまでいかないと、物事としての反省とか後悔みたいなものが弱いと抜けちゃいますよね。
だから痛い目に合わないとこういうのって教訓にならないから。
痛い目を擬似的にでも合わないとダメなんじゃないかなってちょっと思っちゃいましたけど。
痛い目もあるんですけど、これを整理したことで良かった時も。
そうですね。でも良かった体験もあんまり言ってもらえる感じがしないですよね、これって。
なんとなく喋ってる人からすると脳内ではその通り喋ってるから、それをただ改めて復唱されてる感覚で、
そうですね、みたいな話になっちゃうんで。
俺が言いたかったこととか私が言いたかったことはまさにこれなんだ的な言語化の話まで言ってないから。
頭で思ってることを丁寧に言ってくれたら、そうですねって話になりがちですよね。
そうすると、なんでこれわざわざ聞いてくるんだろうって下手したら思われちゃうところもあるなっていう。
そうですね、これは。
罠というか、結構問題としては取るに足らないような話だと思いがちだけど、結構深刻な話になるやつですね。
さっきのグルーピングするようなやつでやっていくと、深掘りできてないんですよね。
せっかく考えたら具体的な内容があるのに丸っとしちゃうから、結構二人になっちゃうし。
そうですね、もう一時情報が丸まってっちゃうと、結局グルーピングしたやつの解像度も下がっちゃうから、
いいグルーピングになってない時点で、それについて対応策考えていくとあんまり効果的じゃないですよね。
というのが起こりやすいという。
なるほど。ただ一方で結構言葉って、そんな明確にそれに1位に決まるわけではないので難しいかなと思うのと、自分も反省だなと思うのは、
問題って今回定義しましたけど、何ならさっきまで話した課題って言葉を問題に置き換えても言えちゃうこともあるから。
問題と課題がどう違うんだみたいな話とかも結構人によっても全然感覚違うんで。
この辺りって仕事として取り組む場合は割とこの言葉の定義というか、明らかにするものに対しての要素の決めっていうのをちゃんとしとかないと。
例えば金万の書の解釈に合わせるとかでも全然いいと思うんですけど、何かしらルールがあれば。それぞれの書の解釈で言っちゃうと、やっぱりその解釈を擦り合わせたりとか戦わせる場がないと絶対何かおかしなことになっちゃって。
解釈と反省
ヤギさんの課題という想定で話した整理の期待値は、その人にとっての課題っていう言葉と全然違うものになってると、何か全然違うアウトプットになったりとか、アウトプット的に物足りないとか、これじゃ不十分だみたいな話になりがちですよね。
ちょっと道逸れるかもしれないですけど、そういう意味で言うと、私は課題という言葉を基本的には使わない。
なるほど、いい作戦ですよね。
基本的にはって言ったのは裏があって、意図的に使うときはあります。これはあえて喋ってほしいとき。
確かに。
詐欺性がむしろあるんで、何答えても。相手側が自分が思った課題について喋れる状態にできるんで、そういうときはあえて使います。課題話してくださいっていう。
いい意味で幅広く捉えてもらいたいっていう場合も、状況としてはよくあるので、伝えるときはそれでもいい場合もあるじゃないですか。
限られた時間の中でエッセンスやニュアンスとしてはこういうことなんだっていうのを伝えるときに、ある種汎用的な言葉を使って伝えるっていうのは正しいんですけど、
自分がそこをリサーチとか調べて明らかにしていくっていうときに、それがなあなあだとやっぱりまずい。具合が悪い。だからそこのモードが切り替わってちゃんと進めれるかどうかっていうことが大事ですよ。
そうですね。だから引き出しのための言葉なんでキーワードとして課題なんですかって思いますけど、ただこちらは何について喋ってるんだろうっていうのは確認した上で、
特に気をつけるのはソリューションを言っている場合、解決策は何でそれが欲しいんですかとかって聞かないと本当に何が起こっているかがわからないんで。
確かにそうですね。基本は解決策って課題と表裏一体なので、何かしら想定している課題を解決するためのソリューションなんですけど、結構落ちちゃってますよね。その課題のなぜならばみたいな話がない場合が多いので。
なぜならば聞いていくと、説明してもらえればそれで課題は明らかになるし、もっとやばいとか具合が悪いんだと、意外にそのなぜならばがうまく答えられないと、試作ありっきになっているっていうところが実は課題。
課題と問題
今回でいうと、問題どっちで言ったらいいんだろう、なんか混乱してきちゃいましたけど、そこが一番本当は手を打たなきゃいけないみたいな、そんなこともありますよねっていうのは感じますね。
おだしょー 課題を聞いたときに解決策というパターンであるのが何とかがないっていうパターンがある。
CRMがないっていうのは、CRMっていう解決策があれば、多分何か自分が良くないと思っていることが解決できると思ってるんですけど、
逆に言うとCRMがないことで起こっていることの方が多分問題点なので、そっちは何でしょうっていうのが非常に重要な感じですかね。
ヒアリングすると、私の前で何とかがないって言うと、何とかがないって言うのに厳密にめっちゃ聞いてくるので、多分嫌がられる。
ないって言うのって、なくて済んでるんだとしたら困ってないかもしれないっていう話もちょっとある。
おだしょー それもある。
だから結局、何が何がないんですよねみたいな話って、じゃあ今どうしてるんですかっていう話で、それがどれぐらい時間とか負担とかかかってるよねみたいな話がないと、
これないって困ってるんですって本当は言えないんだけど、何かその辺りを丁寧に拾っていくっていうところが必要なんで、やっぱりそういうのって問題を明らかにしていくときは共通的に大事なんだよね。
そうですね。そういう意味でちょっと近しいのは、今の堀さんの話に近いのは、たぶん2B側がその人にとっては当たり前なんだけど、こっちが認知できてないっていうときが結構あったりするんで、その辺は何かそこも聞きません。
何のためにそれがどうなりたいからそれが欲しいんだと言っとるみたいなところがすごく重要で、その辺が喋ってる人って当たり前だと思ってるんで、きっとこっちもそう思ってるよねみたいなスタンスでやはり来てしまうけど、自分たちもそうじゃないですか。
あんまり当たり前だと思ってることをわざわざ口にしないというのがあるんで、わからないところはちゃんと聞かないといけないっていうのがこの辺の大事なポイントだし、こちらも何か問題点を言うときは、こうなりたくて、今こうだからそこにこういうギャップがあるんで、それが問題だと思ってるっていうスタンスで話をしないと理解してもらえないという感じかと思います。
そうですね、嫌がられますけど、でも細かいなと思われるぐらい解像度を高めて見ていくみたいな話はやっぱりいりますよね、本当に。
そこが確認できてないと、そもそも課題と思っていることが、その人は課題と思ってても、あたから見たら課題でない場合もあるし、違うところの方がそもそも手を打たなきゃいけない話もあると思うんで。
逆に言うと期待されるのって、そういうところを何とかしてほしいみたいな話で、たぶんプロジェクトにヤギさんが入っていくとしたら、結局そういうのって観察するしかないと思うんですけど、割とアナログ不直な部分っていうのは対話の中だとあるし、それで落ちがちなところを逆に拾いにいかなきゃいけないところが、最終的な成果の良し悪しを決めるところとしてもむちゃむちゃ効いてくるような。
「課題」という言葉を避ける理由
嫌がられても聞くとか、くどいなと思われても聞いて確認していくっていうのは後肯定になればなるほど生きてくるところかなって個人的に思いますけどね。
ありがとうございます。
それ最初で嫌がられてるから飛ばそうみたいな話になっちゃうと、何となく弱い主張とか根拠が飛ばしい提案内容になりがちかなっていうのは思いますね。
そういう深掘りをしたほうがいいなって思うんですけど、自分の仕事じゃなくて節材で入ったりすると、どこまでやるかなみたいな。
関わり方によってはってことですか。
仕事増えるしね。
それはなんかあれですね、構造のジレンマに陥ってるってことですね。フルコミットで頑張ったら良くないことになるっていうのはねじれてますよね。
話がだいぶ長くなってきましたけど、やっぱりどうやったら改善とか良くなっていくのかっていうのは、見えてる人がいないと結構問題再発しがちなところかなと思うんで。
そうですね。そこに対して監視する目が必要なのと。
あとどこから始めるといいかって、この辺なんか本とかもあるんで、それはそれで読んでもらえればいいのかと思うんですけど、個人的には何とかがないって書きたくなりやすいんで、何とかがないって出たときだけ気をつければまずいいかなと思って。
ヒアリングとかしてたりお客さんの話とか聞いてても一番多いのは何とかがない。
よくあるのは時間がないとかそういうやつですね。
時間がないは結構深掘りがいのある際ですね。
それは門前払いをしてる感じもしなくもない。
それも含めて聞いていくと定の良いことはっていう話なのか、ちゃんと中身わかってないのか、本当に時間がないのかっていうのは。
それ分かれていくんですね。
分かれていくんで、深掘りがいはあるんだろうなと思うんですけど。
表面的すぎるなっていうのはある。
何とかがないというのが気をつければまずはいいかなという気がします。
何々がないみたいな課題感が上がってくるときほどバクッとしてる感じはしますね。
リソースが足りないとかもよく聞きますけど。
リソースが足りないもん別にじゃあどこから持ってきて補填したら解決するんですっけって話とはちょっと違うじゃないですか、基本的には。
リソースがないからそのリソース補充したら解決するって話はほとんどないんで。
聞いたことないですよね。
でもよく人入れましょうみたいな話とかリソース補充しましょうみたいな話にはなるんですけど。
そうじゃないところに本当は課題があるなとは思いますけどね。
課題と問題の定義の違い
課題と問題がちょっとややこしいんであれですけど。
今回の話はニアリイコールで使っちゃってますけど。
世の中はそうだから大丈夫です。
世の中は僕みたいに気持ち悪い人そんなにないから。
ちなみに参考までに聞きたいんですけど、八木さん課題って言葉使わないってことは基本的には問題って言葉で統一してるってことですか。
基本的に。
なるほどですね。
でも確かに自分なりの定義決めておくのはいいですよね。
あとはそれをちゃんと一緒に働く人とはうまく共有するってところは一つ最初にやっといた方がいいんだろうなとか。
それも思ったんですけど。
ちゃんと決めとければそれでぶれないんで。
そういうのはすぐにできる話だなと思っていいなと思いました。
はい。
こんなところでここ難しいし、次回も展開していきたいと思います。
ここ難しいですね。
今日は以上でありがとうございます。
ありがとうございます。
![[IS]顧客理解と課題提案](https://image.listen.style/img/IA751RRFkFr_iVFU0Mu0ZXd1JMzFAGVerdP9-ugA_j4/resize:fill:80:80/aHR0cHM6Ly9kM3Qzb3pmdG1kbWgzaS5jbG91ZGZyb250Lm5ldC9zdGFnaW5nL3BvZGNhc3RfdXBsb2FkZWRfbm9sb2dvLzExNDQwNzM5LzExNDQwNzM5LTE3Mjg0NDY3ODIzMTMtMmFhMDEyZDEyNGU1Yi5qcGc.avif)
