00:04
CS Harmony Radioです。
よろしくお願いします。
今回は前回の鈴木で、課題とソリューションのどちらが大切か、すごい上位のタイトルで話してましたけど、
前回の話で、課題とソリューションのどっちが大切かは、ちょっとまだ判断としては結論づけてないけれども、
ただ、課題があるからソリューションが生み出されるっていうので、前後関係で言うと、まず課題がないとソリューションってあっても、
その価値が埋めないよね、みたいなところまでが話してきたところですかね。
じゃあ、後編そのあたりを少し話していく感じにしたいなと思うんですけど、課題がないとソリューションが価値がないのではないか、みたいな話。
ちょっとそれ逆の聞き方すると、課題がないとソリューションは不要なんでしょうか。つまり解決策は不要なんでしょうか。これについてどう思います。
それ多分そうなんじゃないですか。多分言葉の定義的にいいんですけど、ソリューションというのを日本語にすると解決策だと思うんですけど、
解決策という日本語は何かを解決する策なのに、何かをがなくなった瞬間に解決する策の意味がなくなって、
おそらくそうなんじゃないかと思いますよ。
これ前編の話の整理しましたけど、課題だと多義性があるので問題として言葉を定義し、かつソリューションっていうものを問題解決と捉えた場合は、
問題が存在しなければ問題解決は不要なのか、おそらくイエス。
イエスという話かなと。
そうですよね。ここも当たり前じゃんって思うんですけど、
ここはいい世の中には何か課題がよくわからないソリューションがいっぱいあるなと思うわけですよ。
これはなぜそんなことが起きてるのかっていうことだと思っていて、
そんな時に、その不要なものをいっぱい生み出してるのか本当にっていうところもちょっとあるかなと思うんですよ。
僕の感覚なんですけど、おそらく不要なものがほとんど多いんだと思うんですよ。
なんですけど、その不要っていうものって、時間軸を加えて考えると、現時点で不要だっていうことじゃないですか。
そうですね。
なので、妄想してるとか将来の課題に対してソリューション作ってらっしゃる方もいると思うんですよね。
いますね。
そういうことを考えると、実は課題がまだないけれども、そういった課題が生まれることを見越して、
ソリューションっていうのが生み出されているかもしれないし、何ならうがった見方をすると、
そういうソリューションがあることによって、そういった課題が明らかになって、その課題認識するみたいなこともあるような気がするんですよ。
例えば、車のない世界とかで早く移動するって時に、せいぜいここまでしか行けないよねみたいな、
03:03
そういう馬使ってこれぐらいだよねみたいな話とかがあった時に、移動としての課題認識って、
ソリューションがないと、そういうのって自分としての問題認識が広がらないじゃないですか。
そうすると、このソリューションがあることによって、それが広がるっていうこともあるので、
実はソリューションがあることによって、この課題あったわっていうふうに、課題が存在するっていう状況もちょっとあるかなって気がするんですよね。
だから、元の問いで課題が存在しなければソリューションは不要なのか、おそらく僕もイエスだと思ってるんですけど、
課題としては、なんか潜在課題と顕在課題のどっちに当てようとしてるかっていうところが多分あると思っていて、
世の中に出てるソリューションは、潜在してる課題だけじゃなくて、潜在的な課題に対してもアプローチしようとしてるものも出てるから、
なんかそこでソリューションっていうものが多くなるし、
あと、そのアプローチのやり方ってちょっと違ったら、ソリューションの型が生まれると思うので、パターンが。
そうするとパターン的にどんどん増えていくよねっていうので、数が多くなるかなって感じですよね。
あともう一個あるかなと思うのは、潜在課題だったものがもう解決されてほとんど課題じゃなくなっちゃうみたいなことも逆にあると思うんで、
そういうのがまだ残ってるってパターンもあるかもしれないですよね。
なんでそのソリューションが不要なのかみたいな話っていうと、おそらくそうなんだけど、なんかちょっと引き出すようなシチュエーションとか例外的なものもあったりするんだろうなっていうのと、
潜在的な課題に当ててるっていうことだと思うんですよね。
そうすると結局課題も今あるものだけじゃないものに対して当ててくってことが大事だとする前提で考えたときに、
課題とソリューションどっちが大切かって言われると、あえてどちらかって言うとやっぱり僕は課題じゃないかなっていうふうに思うんですよね。
もちろん前後あるんで課題だろうっていう話もあるんですけど、課題ってまだまだ掘り起こされてないものがいっぱいあるってことじゃないですか逆に言うと。
とか諦めちゃってるやつ。例えば絶対病気にならないとかっていう世界とか、今ないやろうとか思ってるかもしれないですけど、別にそんなことってやってみないと分からなくて実現できるかもしれないですよね。
そうすると健康でいられないことが実は課題とか、今でも痩せ薬って出てきてますけど、太っててもいいっていう状態が太ってると良くないから、
それ課題だよねみたいな話になるとそのソリューションがまあ価値をさらに発揮するっていうところだと思うんで、結局課題じゃないよねって思ってるようなことも実は潜在的には課題であって、
それがちゃんと健在化するみたいなことが起きてソリューションが始めて価値を生むんで、結局課題がやっぱり先行してるから、課題がないと価値って埋めないよねっていう話になるとやっぱり解決策は課題より後に来るんで、
06:08
やっぱり課題が大事なんじゃないかなっていう、当たり前のような話ですけど、前編でも話した事業開発の話とかでも、やっぱり先に課題確認からするってことは課題の方が大切だってことですよね。
ソリューションを先に作っちゃってる人はそういう課題をもう見えてるわけなので、やっぱり課題から行ってるよねとか、
でなるとやっぱり課題を明確にしていかなきゃいけないと思うんですよ。つまり潜在的なものもこれ課題じゃないのっていう風に明確にするっていうことが多分大事なんじゃないかなって気がするんですよね。課題が大事だとしたならば。
元々のお題としてはなんとなくそういう話なんですけど、でも次にそうなるとじゃあ課題って潜在的な課題の話どう明確にしていったらいいんだっけみたいな話が出てくるじゃないですか。
ここについていくつかアプローチがありそうな気もするんですけど、例えばヤギさんとかだとそういうふうに曖昧な課題とか、多分コンサルの場合だとよくあると思うんですけど、課題認識をさせるところがまず仕事の趣味。
こことかってどんなアプローチ取ったりやり方してるとかってあったりしますか。
これ多分問題の構造の話を課題の話をしたときにもちょっとしたと思うんですけど、コンサル的に考えると問題を定義できたら7割8割ぐらい解決できてる状態と正確に定義できたら。
なんでかっていうと目標が明確になるので動きが取りやすくなるという絶対そうかなとは思ってますけど、特にふわっとしたことを言ってくるお客さんとかがいたときは、まず目的は何ですかっていうのを明確にするというところですかね。
があって、問題の構造ってAzure 2Bのギャップなので、2B側がどうなりたいのっていうところだと思います。ちょっとこれ戻っちゃいますけど。
スタッフさんが言ってたソリューションから入って潜在の課題が見えてくるっていうお話って多分ソリューションが入ることでAzure 2B側が明確になって2Bが見えるんだと。
だからそこが問題だっていうふうに認識できるっていうのが多分あり得る話かなと思ってて。そういう意味で言うとそこの構成要素が曖昧だと少なくとも課題定義の部分が曖昧なので、そこをまず最初に認識でやるっていうのが大事なのかなと思います。
まさにその通りですよね。さっきの話の内容も踏まえて言ってもらったと思うんですけど、課題を明らかにしていくっていうことがむちゃむちゃ大事っていうのはその通りだと思うんですけど、具体的にその辺りってどういう取り組みをしながら明確にしていきますか。
例えば僕ら議論してるじゃないですか。なんでこういう一つの対等な関係でそのお題について話し合うっていうこともある種課題認識する上では非常に大事だと僕は思ってるんですよね。
09:10
そうですね。
そういうこともあると思うし、コンサルティングとかでやってるんだとしたら具体的な手法とかツールみたいなもので使ってやっていくみたいなこともあるとしたときにそんなことも伺えればなと思うんですか。
そういう意味で一つあるのがこれの中でもポッドキャストでも散々言ってますけどプレップモデルみたいな業務プロセスを書くっていうのが一つあります。
ある意味その問題構造を明らかにするという部分と、あとはこれもポッドキャスト上でも話したことあると思うんですけど、因果関係図みたいなのを書いていく。
問題の構造を明らかにしましょうよというところを書いていくのがツール道具立てとしてはあります。
かつ多分大事にしなきゃいけないのが言葉をしっかり捉える意味をなるべくですけど、人間なので一緒には全くならないですけど努力をする。
相手方が思っていることは何なのかということを理解する努力をするっていうのが根底にはある。
ツール道具立てとして見たら例えばプレップみたいな業務プロセスか、因果関係図みたいな因果関係を書くっていうのを私は使いますっていう感じですね。
ありがとうございます。やっぱり結局Azure Easeを明らかにしていく。つまり課題にフォーカスするっていう話だと思うので、散々ソリューションの事例とか周りのソリューション選考の話してきましたけど、
でもヤギさんがしたとおり、そっちってよりは現状のAzure Easeとしての課題が何かみたいな話の方に寄ってるアプローチだと思うんですね。
だからまずは課題が大事だからそういう発想でそういう行動してるんだと思うんですけど、そうするとやっぱり大事なのが業務プロセスとかお客さん何やってるかっていう現状の状態を正しく知る。
でそれを言葉として共有していくみたいなことがむちゃむちゃ大事で、いわゆるAzure Easeをしっかりと具体化してそれを解像度を高めていくと、そっから先の2Bもちょっとなんとなく見えてくるよねって話ですね。
あとはちょっと気をつけてることは構造を捉えるつもりで基本は言ってます。
これちょっとアンチパターンになると思うので、アンチ的に何か多分やると混乱するのでお勧めしませんっていう意味で言いますけど、
時間を中に入れちゃうととても混乱すると。
例えば世の中がこうなってきてるよねみたいな話が中に入り込んじゃうと、今の話っていうのか未来の話っていうのか何なのかがわからなくなる。
しかもそれ予測なのか事実なのかわからなくなるので、できるだけ基本今のスナップショットを書く。
書くなら書くとか捉えるなら捉えるっていう風に集中することを私はします。
12:02
今の話はその通りで、やっぱり混ざらないようにするってことはむちゃむちゃ大事ですよね。
その中で言ったときに、今みたいに課題をシャープにしていくとソリューションの形もシャープになっていくじゃないですか。
ある種コンサルティングみたいなものも一つの問題を明確にするソリューションだから、ちょっとここややこしくなるかもしれないですけど、
何が問題か分かってない人に問題これですよって明確にする解決策として価値を生んでるわけですよね。
おーっと日本語が分かりづらかったけど、はいそうです。
ちょっとややこしいこと言っちゃいましたけど。
ある種これって何か汎用的なソリューションじゃないですか。
課題、どんな困り事か分かんないから課題特定からして、それに対してあなたの困ってることこれだからこれに対してこういうことやったほうがいいですよみたいなことを導いていくようなアプローチだと思うんですけど、
そういうアプローチの話ってなると結構そのソリューションとしてはすごく分かりづらいというか距離感がある話にもなるかなと思ってて、
多分これちょっと話それちゃうとこ行ってる気もしますが、課題が明確になったほうがソリューションとしての分かりやすさもだいぶ出てくるなってことをちょっと言いたいなと思ってて、
つまり何でもこれ使えますよみたいなソリューションだとそういうのも結構世の中あると思うんですけど、
なんかそれだと結局なんか価値がよくわかんなくなる問題が出てくると思うんで、なんかどっかで明らかにすることをしないといけなくて、
そうすると結局あれもこれもそれもやりたいんだけど結局やりたかったのどれなんだっけみたいな話とかの課題の重要度とかに紐づいてきたりするじゃないですか。
これもヤギさんやってそうなんですけど、そうなると今みたいにこう困ってることがわからないとか困ってることがいっぱいあるから、
なんかどれが困ってるかよくわかんないみたいになる人っていっぱいいると思うんですけど、そこの優先順位みたいなことってつけていかなきゃいけないと思うんですけど、複数ある場合。
それだからどういうふうにされたりしてますか。
何個かあって、一つはまず因果関係とかを作るんであれば問題の根本的なところっていうのはそんなに数が減るんでまずそういう減らし方します。
言い方を変えると風邪の症状がいっぱいあって鼻水が出ますかね、ありますとか咳が出ますかっていうのに際してそれぞれの薬を処方するんじゃなくて、
インフルエンザとしたらタミフルを処方しますだと思うので、そっち側の原因側になるべく近づけるようにしますっていうのが一つ。
それは多分課題の重要度みたいなところだと思うんですよ。根本的なものを見つけていくっていうところが一つあります。
もう一つは実際それが受けている影響度。
例えばすごい熱ですし、しんどいですみたいなところなのか、熱はそうでもないけど鼻水が止まらなくてずっと息苦しいですな。
そういう重みがあると思って、その重みのところでどっち側に寄りますかみたいな話だというのがもう一つ。
15:03
最後は実は問題空間側じゃない方の話として解決策側の話になるんですけど、
手持ちの解決策が一番効力があるやつに近いものを選ぶ。
単純に費用対効果が高そうなものを選ぶ。
優先順位の話としてですね。
もう一回整理すると重要度で1個を選びますって話があって、それがいわゆる影響度の大きさっていうところで測っていくって話が1個と、2つ目何でしたっけ?
影響度が2つ目で、1個目が因果関係に近い方。だから根本原因に近い方。
でも根本原因が高いってことは影響度も高いってことですよね?
影響度っていうのはどっちかというと問題の大きさ、例えば金額なんかそういう意味でちょっと言いました。
じゃあ課題としての本当の真意みたいな話が1つあるのと、それとは別にこの課題が発生するときの影響のデカさみたいなところで見てるっていうのと、
これを解決したらコストパフォーマンスいいというか、実施コストが安いみたいな。
あと緊急度みたいな話もあるかも。
緊急度もあると思う。
その辺複合的に見ていくっていうことなんですよね。きっとね。今の話で。
なんでそうなると、結局課題の切り取り方っていうのがむっちゃ大事ですよねって話になるんだろうなと思って。
この話で言うと解像度を上げるという書籍があるんですけど、課題と解決策と価値の関係性を分かりやすく整理してくれてて。
これまで話した内容にかなり近いこと言ってるんですけど、まず課題が解決策の前提になってますと。
それはここでも話したじゃないですか。で、課題と解決策のマッチングで価値が生まれてますよっていう話なんですけど、
じゃあ価値の大きさって何に比例するかっていうと、解決策に比例しますと。大きさに比例しますと。
ただ一方で、その上限を決める要素は課題ですって言ってるんですよ。
これちょっと説明がややこしいので、具体的な話で言うと、例えば、価値が100になるような解決策を提供している状態があるとするじゃないですか。
その時に、課題が100あったらベストですよね。つまり困ってることに対してフルフル答えられる解決策を提供してると。
じゃあ課題が100じゃなくて1000ですっていう状態になったら、900の伸びしろがあるっていうことになるわけですよ。
つまり、その解決策で100しか解決できてないんで、価値的には。残り実は困ってることがまだ900ありますと。
だからこれのソリューションだけだと、やりたいことの一部しか解決できていません。世の中そういうこといっぱいあると思うんですけど。
そうなると、課題としてのデカさがあるんで、その解決策って磨けばどんどんどんどんさらに向上していくと、価値がどんどん増えるっていうことなんで、これもいい状態かなと思うんですけど。
18:07
逆に良くないなっていうのが、課題が10しかないってなると、解決策の100の90が損なわれて、価値が10しかないってことになっちゃうんですね。
つまり、トゥーマッチ。家電製品とか多いと思うんですけど、あれもこれもついてるけど、結局これいらんみたいなのあるじゃないですか。
使わないっすみたいな。
そうそうそう。これがあればいいのに、いろんな機能あるけど別に使わないみたいなのと一緒で、なんかあっても意味がないみたいな状態になってるっていう話があって。
そうなると、この観点もあって、僕、課題の方が大事だなと思うんですけど、結局解決策で規定できる大きさって、課題の大きさに依存しちゃうんだと思うんですよね。
ってなると、結局課題をどれだけでかく、解決策とフィット感高く切り取れるかっていうことが、実はむちゃむちゃ大事で、コンサルティング的にもそういう部分を明らかにするってことは、たぶん実は喜ばれるんじゃないかなって気がするんですね。
つまり、課題は明確になったけど、解決策と全然ひも付かない課題だと、若干嬉しいけど、本当に嬉しくないじゃないですか。解決できないから。
困ってますよね。でもどうしたらいいですかって話になっちゃうんで。そうなると結局、一番いいのが、例えばこの課題100で、解決策100で、価値今100でって状態に持ってけると、たぶん一番いい講座だと思うんですね。
その時の瞬間のスナップショットとしては。
かぶさくなく。
そう。か課題でかく切り取ってみせるみたいな。そういうことを考える。やっぱ課題の切り取り方っていうのがまずむちゃむちゃ大事だし、
ヤギさんもさっきで、結婚されてまず課題を明確にするってことが大事って言ってたのと通じるかなみたいなことで。
課題の方がやっぱり大事になるんじゃないかなみたいなのを、書籍を読んだ時の話も何かちょっと思い出しながら話したんですけど、
数量みたいなことってあんまり議論しないんですけど、実は何かそういう関係性あるんじゃないかなっていう。僕結構腹打ちしたんですけど、どう思います?
それはそうじゃないですか。課題のサイズに応じて価値があってのはその通りだと。
要は課題が小っちゃいのに価値がいっぱいあるなんてことはないし、っていうのはこの通りだと。それでスレッショードされてるのもそうですし、
そのために解決策が莫大にでっかいやつ持ってきても、それはちょっとずいぶん使わないとこ多いねみたいな話になるのはそう思います。
寺田 なっちゃいますよね。この辺のさじ加減が多分絶妙だと、いいとかすごいってなるんじゃないかなって気がするんですよね。
寺田 解決策でかい話は結構いろんなところで起きている話だと思うんですけど、一方で課題もあんまりでかくしちゃうと、結局解決策が小さすぎるとなんか嬉しくないじゃないですか。
廣瀬 そうですね。
寺田 伸びしろ10倍ぐらいまで今日はなんとかなるっていう話だったんですけど、解決策1ぐらいしかないのに、課題が1万とかってなったらやってもやらなくても一緒じゃないみたいになっちゃうんで。
廣瀬 やる気が起きないレベルのものですね。
21:01
寺田 そうすると、課題を多分10ぐらいのサイズでうまく切って、解決策としてのフィッティングしていかなきゃいけないとかっていう話なんだろうなみたいな。
廣瀬 そうですね。
寺田 っていうところも考えると、課題が大事っていうか、課題の切り取り方とか、課題の見取り方がむちゃ大事なんじゃないかなっていうのが話してて思った感じですかね。
廣瀬 確かにそうです。スコープというか定義の仕方というか、そういうのは非常に重要なポイントになっていますね。
寺田 そうですね。モデリングもそういうのの見取り方とか、見方の観点を一つ見るものさしだと思うんですけど、結局課題も潜在、顕在考えたら、潜在含めるとむちゃむちゃでかくなるじゃないですか。
寺田 でなるとやっぱり、そこをどういうふうにうまく見取れるかっていうのがむちゃむちゃ大事だなっていう。
寺田 それはお客さん側のAzizも見る話もあれば、時間軸入れるとややこしくなるって言ったんですけど、将来トレンドとか将来の状況みたいなことも見通した上で、大きくなりそうな課題をこれ大きくなるよっていうふうに言えるような見取り方するっていうのも高度かもしれないですけど、できるとより良いんだろうなみたいな、そんなことを話してて思った感じですけど。
寺田 時間の観点とか確かに。
寺田 その潜在課題扱うとなると、今課題じゃないやつってなると、将来課題になると時間の話入ってきちゃうかな。
寺田 それって実際そうなるか置いといて、ロードマップとかを引くときにそういうのを考慮しながら行きますね。
寺田 そうすると納得感があるというか、たぶんお客さんの中、正確に言うと納得感もあるんでしょうけど、結果的に予算を取ったりとか、Goldarnに説明したりとか、それで融資してもらったりとか、そういうのが入ってくるので、結果的にそういうのの納得性のために必要だったりするのが出てくるかなと思いますね。
寺田 さっきの話で時間事故とかないってあくまでも現状分析っていうことに意識があったからそういうコメントだったと思うんで、取り扱いとしてはそこの話も含めて見とれるっていうのがいいよねっていうことなんだろうなと。
寺田 はい。
寺田 はい、ということで、なんかすごい大冗談なお題で話しますけど、一歩深掘れた話ができたような気がするので、満足です。
寺田 はい。
寺田 ということで、本日は以上としたいと思います。
寺田 はい。
寺田 ありがとうございます。
寺田 ありがとうございます。
