櫻井さんと櫻井さんの書籍について
こんにちは、エールの山田です。この番組は、エール代表の櫻井さんの書籍、まずちゃんと聴くの内容を中心に、聴くや伝えるについて、ざっくばらんに対応しながら深めていこうというポットキャストです。
では櫻井さん、今回もよろしくお願いします。
はい、よろしくお願いします。
だんだんと数を重ねてまいりましたね。
そうですね、楽しい毎回。
5人目のゲストかな、今日。
毎回違う話になりますね。
なんだかんだでね。
そして、だいたい事前の想定と違う話をして盛り上げているんですね。
それそれ。
今日も思わぬところにきっと着地するんじゃないかなと思いますけれども。
はい、ということで、今日のゲスト5人目ということですね。
ソニックガーデンの倉貫義人さんをお招きしております。
櫻井さん、ちなみに倉貫義人さんをご紹介する前に、倉貫義人さんに今回来てもらったら嬉しいなって思った感じとかって何か覚えてますか?
でもやっぱり倉貫義人さんが経営の中で体現されていることって多分本で伝えたいことと結構近いところがあったりするのかなと。
勝手ながらやっぱり思っているところが、いろんな記事やお話やお伺いしている中であって。
全く同じことと違うことまで説明してたりとか、そういうことがあるんじゃないかななんて思ってお話しすると、コラボレーション、化学反応が起きてむしろそうだなというふうには思ってます。
はい、ありがとうございます。ではここからは倉貫義人さんもご登場いただいて進めたいと思います。倉貫義人さんではよろしくお願いします。
はい、よろしくお願いします。
お願いします。簡単にでは最初一言、自己紹介的にしていただいてもいいですか?
はい、倉貫と申します。ソニックガーデンというシステム開発の会社を経営しつつ、クラシコムという北欧暮らしの道具店というECサイトを運営している会社の社外取締役をしており、
普段はもう完全に経営の仕事をしていますが、もともとプログラマーでエンジニアでということで、いいソフトウェアを作りたい一心で会社経営をしてきているという人間でございます。よろしくお願いします。
よろしくお願いします。これはですね、櫻井さん、クラリックさんが楽天の仲山さんとやられているザッソウラジオにも出て本の話をしていましたよね。
はい。
あのー、呼んでいただいてお話をさせてもらいました。
いや、ありがとうございました。
もう途中から、あのー、なんだろう、まさに雑草な感じで。
倉貫義人さんの自己紹介
いや、ほんとね、毎回僕らゲスト来ていただいて、あの特にテーマも決めずに、本の話、最初、とっかかりそこだったんですけど、全然違う話にね。
いや、めちゃくちゃ面白かったですね。
改めてそこのザッソウラジオで話されたこととか、あの本もお読みいただいたんだと思うんですけど、倉貫さんなんか、どんなふうにその櫻井さんの本って印象として今残ってますか。
いや、そうですね。あのー、これ学長とのザッソウラジオに来ていただいた時も話したんですけど、その聴くっていう一言に関して、これだけ深く分解分析する人って、まあそんないないよなみたいな。
その、まあでも僕ら分析マニアなので、その、要は聴くとはまず何か、聴くとは何かを定義することってほぼないと思うんですね。
そこからまず入るっていうのが僕ら好みだったなぁっていうのが、もう、あのー、なんで、もうその抽象化みたいな話もそこでもしたんですけど、ザッソウラジオでもしたんですけど、
その、いかに抽象化をして他に展開するか、もしくはその具体のところをどう分解してその理解するかみたいなことを、そこで聴くにフォーカスしてあんな文章を書く人いるんだっていうのが、あの感想でしたかね。
いや、面白いなぁ。なんかその、もう本題入っていいのか分かんないんですけど、抽象化するときって、一回してみるんですけど例外がクソたくさん出てくるじゃないですか。
出てきますね。
で、この例外が出てくるときが面白いっていうか、なるほどそういう例外があるかーっつって、このなんか抽象化したものをこねこねしてまた変えていくっていう作業が、面白いなーって思いながらいつもやってます。
いやー、それでもプログラマー向きなんですよね。
あ、そうなんすか。え、どういうことですか。
その、僕ももともとプログラマーなんで、そのプログラムを書くときって、その結局、その最近のAIとかはさておき、コンピューターのプログラム命令なので、命令の位置が違うので、その命令した通りにしか動かないんですね。
はいはいはいはい。
命令は、あの、あらゆるケースに対応できるように命令って書けないので、まあ一定抽象化して書くわけですよ。
で、抽象化して書くんだけど、やっぱり例外が出てくると、その例外ごとにプログラム書いていくと、やっぱりね、良くないコードになるんですよ。
なるほど。
プログラミングとコミュニケーション能力について
なので、それを取り込んだ、もう一段抽象化したプログラムにしていくっていうので、
なるほど。
プログラム書くのって全部抽象化していく行為なんですよね。
はーん。
うん。
そんな風に捉えたことなかったけど、すごい面白いですね。
うん。だから、良いプログラムは非常に短くて小さいんですよね。
あー、よく言いますよね。
そう、上手に抽象化されているので、一つのインプットに対していろんなバリエーションの動きができるように作られている。
実は抽象化が高いんですけど、この抽象化下手くそな人は、いっぱいプログラム書かなきゃいけないんですよね。
はいはいはいはい。
なので、実は量が小さい方が抽象化度が高いので、良いプログラムになるっていう。
えっ、その話からいっていいですか?
いや、なんか変な、毎度の
あれですけど。
いや、それってすごい能力だなと。
なんかその、プログラム書くってものすごい具体がわからないと。
はい。はい。
あのー、なんならその行動の裏にある意図であるとか、感情とか、そういったものまで多分汲み取って書かないと、
なんていうか、想定通りの動きをしてくれないじゃないですか。
はい。はい。
っていうその具体を扱えるって話と、抽象化する話って結構能力が違うんじゃないかなって思うんですけど、
この辺ってどういうことなんですか?どういうことなんですか?って質問がすごい荒いんですけど。
いや、でもやっぱりね、良いプログラムを書くときは、それこそ現場へのヒアリングをするとか、
プロダクトオーナーの人と一生懸命議論しつくすみたいなことをして、
その具体を理解しないと抽象化ってできないんですよね。
だから具体をいかに取り込めるのかっていうのがまず一つあり、
それをいかにモデル化っていうんですけど、抽象化してモデルに落とし込むかっていう。
本も具体的な本は本屋に並んでいる一冊や二冊がいっぱいあるけど、
でもあれを知らないと抽象化して、本っていうのは実はISBNが付いたものである。
だから抽象化されてるものですね。
だけどそれを印刷すると、具体はいっぱいたくさんの物理的な本になる。
だけどデータベースに入れるのは抽象化したISBNの方で一行あれば良い。
でもこれも本という種類を具体で見たら、
誰々さんの本、誰々さんの本、どこどこの本っていっぱい、
本もいわゆる商品コードがいっぱいあるとしたら、
それを本というカテゴリーとしてまとめるみたいなことをしていくってことをしていき、
雑貨を扱うのは雑貨みたいな、それをカテゴリー化するみたいなことも
全部具体を見て抽象化していって、プログラムをデータにしていくみたいな仕事をずっとやってましたね。
今ね、ちょっとこの話と聴くって話を無理やり繋げるわけじゃないんですけど、
なんか僕の中で繋がったんでちょっと話をするんですけど、
演劇やってる方って聴くのが上手いってよく言われるんですよ。
それは僕なりの理解なんですけど、
演劇ってその役になりきらないといけないじゃないですか。
だから自分っていうものをなくさないとその役を演じられないんですよね。
だから多分話を聴くときって、それこそwithout judgmentってそういうことだと思うんですけど、
自分というものを一回なしにして、相手が何を考えているのか感じているのかということを感じようとしたり、
一緒に考えようとしたりする姿勢が聴くっていうことなので、
なのでその演劇っていう所作と聴くっていうことって結構親和性が高いんだろうなというふうに思ってるんですね。
なんだけど、そういうことされている方って割と抽象化するのがそんなに得意じゃない方が多かったりする印象があるんですよ。
一方で今言ったエンジニアの方々ってコミュニケーションがあんまり得意じゃないと言われるじゃないですか。
ただこれ聴くっていうスキルを身につけてしまうと、聴いたものを抽象化するっていうのがすごく得意なんだとしたら、
聴くっていうことめちゃくちゃすごい能力高そうだなって今ちょっと思ったんですけど、
その辺って何かエンジニアの方々を散々と一緒に仕事してきている中でどう感じてますかっていう。
いやこれエンジニアの人がコミュニケーション苦手じゃないかっていうのは結構思い込みだなって僕は思ってるんですよ。
はいはいはいはいはい。
なんかこれ多分ステレオタイプとしてエンジニアコミュニケーション能力低い、
その代わりプログラム書けるみたいな、つまり人間が漫画でも何でもキャラクターを考えるときにある強みを持っている人はある弱みがあるんじゃないかって思っちゃうので、
プログラムなんて多分プログラム書ける人からするとプログラム書くなんて僕ら当たり前に書けるんですけど、書けない人からすると魔法みたいに見えると思うんですね。
なので特殊能力、超能力みたいな風に見えた時にせめてコミュニケーション能力低くないと釣り合わない。
なるほど。
っていうのがあって、いやそうじゃないんですと僕から言うとエンジニアの中にもコミュニケーション能力高いやつと低いやつがいるだけですみたいな。
なので大谷翔平選手は言ってもコミュニケーション能力高い、めちゃくちゃ野球できるけどコミュニケーション高い。野球できる奴コミュニケーション能力低いわけじゃない。
でも多分野球選手でめっちゃ野球上手いけどコミュニケーション下手な人もいるし、野球技は下手だけどコミュニケーション高い奴がいるとしたら要はトレードオフじゃないんですよね。
なるほど。
まずその誤解をこれはもう僕は何年もかけてこわだかに言っていかないと誤解が解けないので、いいエンジニアはやっぱりコミュニケーション能力高いですね。
なぜならさっきの話でそのプログラムに落とすコードを書くっていうことは、これ抽象化されたものを具体に落とすっていう仕事なんですね。
はいはいはい。
まずは現場だったりビジネスモデルだったりサービスモデルっていう具体を一度抽象化しないとプログラムコードに落とせない。
なので具体があり、一回抽象化して具体に戻す行為になった時に、プログラムを書くっていうのは一側面の抽象化されたものをコードに落とすだけなので、そこの能力が高いだけだとまだその半分ってことなんですね。
本来であればそのモデル化するという抽象化能力があって、それをプログラムを落とすという具体化能力があって、足し算していいプログラマーになれるって僕は思っていて。
めちゃくちゃ面白い。
抽象化するとこの最初の具体を抽象化する時に必要な能力が、さっきおっしゃった聴くってことだと思ってる。
ので、聴くがないと具体に落とせない、まず抽象化できないから、聴く能力ないのにプログラム、僕からするとね、僕の定義でいういいプログラマーの人は聴く能力絶対いるよなと思ってる感じですね。
いやーなんか今から本を書き直したい気持ちになってしまってるぐらいすごい気づきがあるんですけど、
聴くっていう行為の中で、多分人によって最初の具体を聴きに行くのが得意な人と、それを抽象化するための問いが上手い人と、
抽象化したものをさらに活かすっていうことに具体に落とし込んでいくっていう作業が多分3つあって、
それぞれ多分得意不得意が聴くの中にもみんなある感じがあるんですよね。
なんかこれすごい面白いな。
お客様と一緒に悩みながらいいものを作る
この角度でもう1回聴くっていうのを切ってちょっと整理してみたいと思っちゃった。
なるほどなー。
またさらに聴くが定義細かくなって、よりマニアックに書くものが。
聴くの解像度がまた上がった感じがしましたけど、なんかそのさっきでもおっしゃった、
なんか作るときに作りたい人の聴けなきゃいけないという時に、これ視座の話も、視座というか視点の話か、
その相手の視点に立たなきゃいけないっていう気がしていて、
僕らの会社でシステム開発をするときに基本的にはお客さんがいらっしゃるので、
お客さんのシステムを作るときの大事なスタンスは、問題vs私たちってよく言ってるんですね。
お客さんと私たちっていうのを相対にして聴くっていう風にすると、ずっと聴き出そうとはするんだけど、
相手の目線にはなれないんですよね。僕らがやりたいのは、相手の目線に立つための聴くをしたいっていう。
聴き出すというよりは、聴くことによって相手と目線を一体化したいっていうのがあって、
それは聴くのテクニックというか、聴くのやり方の違いは多分あるんじゃないかなっていう気はしていて、
聴き出すの聴くと、相手の視点になるための聴くの違いって、
これ櫻井さん的に違いはあるんですか?
これはまさにwith judgmentとwithout judgmentの違いとか、
本で書くと、相手に関心を持つことと、相手の関心ごとに関心を持つことと、この違いみたいな説明の仕方をしてるんですけど、
この違いってわかる人っていうか、できる人からすると明確に違うんだけど、
わかりづらい人にはわかりづらい違いじゃないですか。
これってエンジニアの方を、例えば若手のエンジニアの方を育てていくときに、
そのお客さんの視点になるっていうことって、どういうふうに指導したりサポートしていったりされるのかなっていうのが僕はすごい気になったんですけど。
いやーこれね、むずいですね。
言葉としては、お客さんの視座になれよって言われるんですけど、
どう簡単になれるのかみたいなことがあって、
お客さんもそうだし、例えばメンバーの人たちが経営と結構近い資材になってほしいなというか、
議論を一緒にしやすいようになればいいなと思ったときに、
最近の経験で言うと、一つ自分と視座揃ってきたなとか、
視座揃ってきたなっていうのって、
お客さんととある問題、もしくは経営ととある問題に対して、
一緒に悩んでる時間があると、資材揃ってくるって感じはあるんですよね。
これもメタの話で、問題抱えてる人を見てどうしようじゃなくて、
問題そのものに一緒に向き合っていくっていうことをすると、
答えがないようなものに対して、ああでもない、こうでもないって、
ちょうど僕らの会社が今、徒弟制度っていうのを始めていて、
若い人育てるのに、いわゆるOJTで師匠をつけて、
親方と弟子の関係で育てるっていう風にしてるんですけど、
人育てるの難しすぎて、親方たちが僕に相談に来るんですよね。
若いやつがこれで伸び悩んでるとか、若いやつが最近調子良くなくてとか、
もうちょっと伸ばすにはどうすればいいだろうかっていう答えがないことに対して、
僕に相談に来てくれたら、僕も別に答えがないからわからないので、
親方たちと一緒に僕悩むんですよ。
これやっぱりあいつもうちょっとこういうことした方が伸びしろあるからいいんかなとか、
最近元気ないからちょっとセーブした方がいいのかなとかっていうのを、
一緒に悩んでるうちに一体化してくる感じがすごくある。
面白いな。
要は答えのないものに対して一緒に悩むって、
一緒の資材になるやつじゃないっていうのは最近の経験であったことですかね。
今のお話で言うと、
みんなお客さんのこと考えろとか、お客さんの視座に立てとか、
自分の役職の一個上のポジションになって考えるとか、
いろんな言い方をするけど、
お客さんのこと考えろって言ったときに、
多分上の方からすると、
お客さんになりきって、お客さんからは何が見えていて何を感じているのかを、
考えたり感じたりすることをお客さんのことを考えるって言ってんだけど、
でもお客さんのことを僕すごい考えてますって思ってるけど、
それが伝わらない人っていうのは多分こっちからお客さんを見てるっていう。
なんかその違いって、
これうまく説明できるといろんなところに転用されるっていうか。
そうですね。
お客さんのことを、もしくは経営とか上司のことを見てちゃダメなんですよね。
お客さんとか上司とか経営の見てる先を一緒に見ないといけないっていう話ですよね。
そこのお客さんのことを考えるというよりは、
お客さんと一緒に考えろって言った方がいいかもしれないですね。
なるほどな。
なので僕らの会社、
納品のない受託開発っていうシステム開発ってちょっと変わった、
お客様とずっと付き合いしていくシステム開発をしてるんですけど、
それのスローガンが一緒に悩んでいいもの作るっていうスローガンなんですね。
いいな。
いいもの作るだけはエンジニア集団なのでそりゃそうなんですけど、
やっぱり一緒に悩みたいなみたいなところが、
やっぱりそれをそうするのが、お客さんも創出したいんじゃないかなと思ってるっていう感じで、
スローガンにはしてますね。
すごくいいヒントだなと思ったんですけど、
お客さんのこと考えろって言うとわからないんだけど、
一緒に悩めって言われたら、
結果的にお客さんと同じものを見ようとすることになるっていう、
何をしたら自然とそうなるかっていうことの、
何をしたらいいかっていうことがちゃんと示されてるってすごく、
聴くで言うと何なんだろうなって、
without judgementで相手に関心を持つのではなくて、
相手の関心ごとに関心を向けましょうっていうのはその通りなんだけど、
一緒に悩むと同じように、
何をするとそれが自然と起きるのかっていうこととかが、
ちゃんと提示できると、
みんなができるようになっていくのかなっていうことを今感じた。
聴くという行為の重要性
エールで聴くの話をしてる時に、
聴いてもらった体験があってこそ自分が聴けるようになるよねっていうことをよく言ったりするじゃないですかっていうのも、
角度違うけどちょっと似たようなあたりを触ってそうな気がして、
やっぱり体感するとか実体験があるっていうのとつながって、
自分がどう振る舞えばいいかわかるみたいなことって、
なんか実は近いものなのかもしれないですねって聴いてて思いました。
はい、ということで、
だいぶまだいけそうな気もしますが、
もう時間?嘘?
前半がすっかりいい時間だという話が来たので、
一旦前半ここまでにしまして、
後半はちょっと何になるかはまたちょっと、
次回をお楽しみにという感じで全く、
僕もヒントがないですが、
はい、次回にまた続ければと思います。
では、一旦ここまでで、
倉貫さん、櫻井さんどうもありがとうございました。
ありがとうございました。
