00:07
くらぬきです。
中山です。
ザッソウラジオは、くらぬきと学長こと中山さんで、僕たちの知り合いをゲストにお呼びして、雑な相談の雑草をしながら、イルコをしゃべりしていくポッドキャストです。
先月7月は、テーマでおしゃべりしてみようということで、老僧思想についておしゃべりしましたが、8月はまた再びゲスト会に戻ってまいりました。
ということで、今月8月のゲストは、近畿大学の山縣正幸さんです。よろしくお願いします。
よろしくお願いします。
最初にちょっと山縣さんをご紹介して雑草を始めたいなと思いますが、山縣さん、企業行動論や企業発展のご専門で、現在は近畿大学経営学部経営学科教授として経営やビジネスの研究をされています。
経営が2つもつくので、経営の真ん中ってことですね。
大学の山縣正幸ゼミのテーマは、価値創造のデザイン、さまざまなステークホルダーの期待を満たすために、サービスデザインや意味のイノベーションなどのデザイン経営のアプローチで、企業がさまざまなステークホルダーに対し、どうやって価値をつくり提供していくかを考えていくゼミだということでした。
ゼミのテーマが、ミッションがですね、学びも遊びもガチでということで、雑草ラジオのリスナーさんとはですね、かなり共通点があるんじゃないかなということで、今日はいろいろお話ししていきたいなというふうに思っております。
さあ、ということで、どっから話しましょうか。
久しぶりのゲスト会だと、なんかやり方忘れましたね。
この前、くらぬきさんと北海道のぼっちのところに遊びに行ったときに、ぼっちが山形さんの話をされたんですよね。
ぼっちは山形さんのところに、大阪、大阪?
そうですね、はい。一度、私が勤めている大学に大阪に来られたときにおいでくださったんですよ。
もともと別のところで、オンラインではご縁があったんですけども、実際に大阪の出張されたときにわざわざ来てくださって、それで話をしたっていうのが、直接お会いしたのはその1回だけです、まだ今のところ。
山形さん、さっそうラジオいかがですかって聞いたら、すぐはいはいってお返事をいただいて、今日に至り。
昨日の山形さんのフェイスブックで、くらぬきさんの新刊読み終わった感想が、僕にとっては謎のキーワード満載だったんですけど、ちょっとこの辺から伺っていってよいですか。
03:07
はい、ぜひぜひ。すいません、私、あれフェイスブックなんですけども、もともとインスタグラムの方で買った本をいつもアップロードするっていうのを一つの習慣にしているんです。
交渉病って書いて、本を買う病気。購入の恒例、交渉病。どっちかというと、お金がなくても本を買ってしまうタイプで。
くらぬきさんの本が出たっていうのはもちろん存じ上げてたんですけども、なかなかちょっとドタバタして読めてなかったんですけど、やっとゆっくり読めたんで、読んでみると非常にすごく面白かったというか、
ある意味で私のプログラミング自体に縁があるわけではないんですけども、プログラミングとかっていうものを軸に経営っていうのを見るとこういうふうに描けるんだっていうのがすごく面白かったとこですね。
もうちょっと具体的に言うとどういう感じですか。
この中でやっぱりソフトウェアっていうのか、プログラミングっていうのが使われる状況っていうんですかね、それが結構予測不能っていうのがやっぱり面白いというか、
実は多分普通のものの場合、いわゆる製品みたいな場合でも多分そういう面ってあるんだろうけど、
例えばペットボトルのお茶をいきなり凍らしてドンキ代わりにするっていう人もいるかもしれないけど、普通は想定できない。
けれどもソフトウェアの場合って実は、使い方って書いてあってもその通りに使ってくれないケースが多いってなると、
普通の製品、いわゆるものづくり系よりも予測不可能性っていうんですかね、が高い。
そこが軸になって経営っていうのを見てやると、やっぱり捉え方っていうのはすごく変わってくるよなっていうのは改めて読んでて、すごく面白かったとこでしたね。
このルーマンからブライシャーへと繋がって出てきた複合性の克服という概念を補助線にして読んだっていうのはそのあたりと関係するってことですか。
すいません、ややこしい書き方して、ルーマンっていうのがもうだいぶ前なくなったドイツ人の社会学者で、社会システム理論っていう領域の人なんですけど、
面白いんだけどものすごくややこしく書く人で、投げ出したくなるような本なんですけど、この一本。
もうちょっと簡単に言えばって思うことは多々あるんですけど。
ただちょっと面白いのが、世の中にいろんな可能性があって、それとどれと関係を持ち得るかっていうんですかね。
関係をつなげるかって限界があるわけですよね、もちろん。
06:03
その中でそれを選び取るというか、そういうあたりに結構議論のポイントの一つがあって、そうなるとまさにソフトウェアの場合って何が起こるかわからないって考えると、
どういった状況を想定するのかっていうのが、ソフトウェアとかを作り込んでいくというか、組み立てていくときに結構重要なポイントになると。
っていうのって、まさにどういう状況が起こり得そうかっていう頻度とかも含めて結構考えてるのかなっていうのを、
この本を読みながら思ってて、それってまさにどういう状況が起こるのかをイメージしながら、
選び取っていってると。にもかかわらずまた予測不可能なことも起こってくる。
っていうのにまた対処していくっていうあたりが、まさに関係性をどれぐらい選べるかっていう点で、
これは複合性って呼んでるんですけど、それを単にちっちゃくするっていうよりも、乗り越えていくみたいな感じをすごく感じて、
単にややこしいものを単純化するっていうことだけでもないというか、
シンプルにはするんだけど、いろんな状況に対応できるようにしておくと。
逆にソフトウェア側を複雑にしすぎると、そっちが操作不可能になってしまうっていうあたりが考え方としてすごく近いなっていうのを、
これ学生なんかにも授業で言うと、たまに真面目な学生ほどギョッとするんですけど、
企業ってお客さん選べるんやでって話したときに、は?みたいな顔をする学生がやっぱりいるんですよね。
むしろそれは望ましい反応なんですけど、こっちからすると。
でもやっぱり全てのお客さんに対応するなんていうのは当然できないわけで、
どういう人にお客さんになってもらいたいかっていうのを企業側も考えてるってなると、
実はお客さんが企業を選ぶだけじゃなくて、実は企業もお客さんを選ぶっていう、
どの関係性を選び取っていくかっていうのが、実は経営にとっては大事だよみたいな話を結構授業でもするもんですから、
まさにそこら辺を読み解いていくっていうか考えていくときに、
このソフトウェアってすごくそこの部分が大きそうだなっていうのを読んでて、
個人的には感じたっていうのが、わけのわからない最初の文章だったと。
なるほど。今の話、倉瀬さん的にはどんな感じですか?
今の話、僕的には、この本って結構ソフトウェアの具体的な話を書いてるんだけど、
09:07
経営とかソフトウェア以外の人が読んでもらったときに、結構インスピレーションを広く感じてもらって、
そこから発想を広げてもらえるって、僕的には自分が本を読むときに一番好きな本の読み方って、
その本の中身をそのまま受け取るんじゃなくて、受け取って触発されて、
自分のもともと持ってたやつから、これソフトウェアだったらこうだったとか、
これ経営で言ったらこうだった、自分の文脈の中で結構ひらめきがある本が好きなんですけど、
今回そんな風に捉えてもらっているのは、僕的には僕が好きな本の読み方をしてもらっているのを、
僕の本にやってもらえて、すごく嬉しいなと思っていて、
ルーマンとか社会学とかのことは僕はわかんないですけど、
山本先生の文脈の中でひらめきというか、つながりを感じてもらえる読み方はすごく嬉しいなと思いましたね。
そう言ってもらえるとめちゃくちゃ嬉しいです。
これゼミメンバーにも読んでみてほしいって書いてありましたけど、
ゼミの学生さんにはどんな風に、どんな意味で読んでもらいたいになっているんですか?
特に今学生には企業さんとかと一緒にプロジェクトをしてもらってるんですね。
しかもそのプロジェクトをやるときに、普通だとこれをやりましょうってかなり厳密に決めるというか、
結構がっちり決めることが一般的だと思うんですけど、
それだったら実は私あんまりやる意味ないなと個人的には思ってるんですね。
なので、大きなざっくりとしたテーマは私とプロジェクト先の企業さんとかと話はするんですけども、
細かいところというか、学生がやりたいこともあるだろうしと思って、
学生とかチーム、だいたい3,4人で1チーム組むんですけど、
伺ったときとかに、こんなことやりたいとかっていうのをプロジェクト先さんに話をして、
もちろんできること、できないことってあるんで、それは話をしながら決めていくんですけども、
そこから考えてもらうっていうのをやってて、
だから具体的に動き出すまでに2ヶ月ぐらいかかってしまうっていうケースが多いんですけど、
この本読んでるとまさに立場が違う人っていうんですかね。
っていうのが一緒にやっていくときのっていう話、まさに使う人と作る人っていう点でもそうだと思ったんですけども、
ソフトウェアのユーザーの人とエンジニアの人が継続的に話をしながら組み立てていくっていうところなんかは、
実は私のところのゼミでやってるプロジェクトをやるときの発想とすごく近いなというふうに思ったので、
そのあたりが自分たちのやりたいことっていうふうに、そこばっかり閉じこもられても仕方がないですし、
12:08
一方で言われたことだけやってても仕方がないので、
そういう点で継続的に会話をするというのかな、
推しながら作り上げていくっていうあたりはすごくヒントになるんじゃないかなっていうので、
読んでみてっていうふうに書いたっていうところでしたね。
まさに2ヶ月始まってない、全然進んでないけど、人増やしたほうがいいんじゃないのって言われてたよね。
それは必要な2ヶ月ですからね。
だからすごくその時期は、プロジェクトにもよりますけど、学生は悩むというか、
何していいのかわからない状態になるケースも結構あります。
それも本当に新規事業に近いんですよね、プロジェクトを立ち上げるっていうのがね。
何をするのかみたいなところを考えるのが、結局新規事業も何をするのかが難しいっていうか、
やること決まっていればそんなに難しくないんだけど、やること決まってはない状態が新規事業だとしたら、
それを考えていくフェーズが一番難しいんだけど、そこは人増やしても早くならないっていうのが、
ソフトウェア開発と新規事業が似てるっていうのと同じで、おそらくそのプロジェクトみたいな、
学生さんと企業さんとのプロジェクトみたいなのも同じことが起きてるのかなって、今話し聞いてて思いましたね。
そうですね、なので人数も、これ学生だからっていうのもあるんですけど、
1チーム5人を超えることは絶対しないっていうのは、
これはもうフリーライダーが出ちゃうっていうのももちろんあるんですけども、
やっぱり人数が多くなると、それぞれの個々の考え方とかが反映されにくくなるっていう部分もあるのと、
あとはやっぱり、別に個々を狙ってるわけではないんですけど、追い詰められない。
人数が多くなると油断ができやすいので、
大体3人から5人の範囲内で企業さんと一緒にやらせてもらってるっていう感じで進めてますね。
まさに楽天の出展してるネットショップの店長さんとかが、
例えばちょっとページ作ったんだけどどうかなとか言って見せてくれたりする時とかに、
どう?って言われても、その商品買うの僕じゃないので、
僕がいいですねって言っても売れなかったら意味ないじゃないですか。
なので出してみて、お客さんの反応を見て、
そこからどうするかっていうのをまた考えたらいいんじゃないですかって冷たいことを言って、
15:06
だんだん相談されなくなってきたっていうプロセスは経てきたんですけど。
それで一番うまくできるのは、やっぱり一人店長の人とかが早いですね。
誰とも相談しなくても、お客さんからのフィードバックとかリアクションを見ながら、
自分なりにまた仮説立てて、ちょっとここ直したらどうなるかなって言ってやってみてみたいなのを繰り返しが早くて、
で、やっぱり一人店長をやってると全部自分ごとというか、
全体を見ながら自分で全部チューニングしていくので、
めっちゃ成長が早くなるっていうことが起こりました。
試行錯誤しやすくなるのは、人数少ない方がしやすいのがしやすいですよね。
そういう意味で言うと、僕楽天に入ってほどなくECコンサルタントっていう役目ができたんですけど、
その時最初9人いて、何やったらいいかよくわかんないんですよね。
何やったらネットショップの売上が上がるかとかもまだよくみんなわかってないし、
なので、9人がそれぞれに自分でいろいろ工夫しながらやるっていう体制になってて、
みんなやり方、やってることとか違うんですよ。
メール出すの得意な人もいれば電話しながら喋るの上手い人がいろいろいたりとかっていうのがあって、
で、そのうち誰かがうまくいき始めるみたいなことが起こるのをそれ真似させてもらっていい?
とか言って他の人が取り入れつつ、また自分なりに試行錯誤をするみたいなことをやっていくと、
結構いろんなやり方あるんだなっていうのと、
そういうやり方をするとこういうリアクションがあるっていうことなんだなみたいなのが、
共有が早く進むようになっていったので、
試行錯誤って9人いたら、9人で1つの試行錯誤をするより、
絶対急遽試行錯誤をやる状態を作った方が早くなるよなって思ってます。
そういう意味ではあれなんですよね。
実はプロジェクト先も大企業さんとは実は全然やってないんですね。
基本的に中小企業さんがほとんどで、
それは理由もあって、私もそうですし、
学生が社長というか最終意思決定権者と話ができるっていうのが、
実はプロジェクトやるときの一つの原則。
私がやってる分に関しては、
どうしても全然知らないところで話が変わっちゃうっていうふうになると、
18:03
学生の場合は特に折れやすい部分も当然あるっていうのもありますし、
あともう一つは、全体像が見えておいてほしい。
例えばその企業さんがどういうふうな感じで、
ものを作ってお客さんに届けて使ってもらってるのかっていうのをイメージしながら、
やっぱりやるのは細かいことなんだけど、
これはクラウキさんの本の中でも出てた気がするんですけども、
全体像は意識しながら、やるのはちっちゃくなるというか、
限定された範囲でやるんだけど、
やっぱり全体の中にどう繋がっていくかっていうか、
どう位置づけるかみたいなことはいつも意識しておいてねっていう話は、
やっぱりよくする。
今中村さんおっしゃったみたいに、
一人で全体像が見えてるというか、
一人一人が全体像まで一応イメージができてるっていうところは結構、
やる時には意識はしてるところです。
うまくいってるかどうかは別の問題として。
全体像ね。
いつも学長が言ってるやつですね。
最初から最後まで全部やる。
一気通貫で、商売として一気通貫でやるみたいな話と、
分業で一部だけやるっていう話と、
商売としての面白さみたいなのはやっぱり一気通貫のところだよねみたいな話を
いつも言ってる話と。
僕の本でも、分業なるべくしない方がいいって書いてるんですよね。
一気通貫って書いてありましたよね。
書いてる。
分業した方が生産性が出るお仕事と、
分業しない方が成果が出るお仕事が、
やっぱり種類があるのかなと思っていて、
僕はソフトウェア開発、プログラミングっていうのは、
分業しない方が成果が出る。
分業しちゃうと何作ってるのか分からないっていうのもあるんですけど、
作ってる最中に、そもそも前段階の設計から見直した方がいいねっていう発見があった時に、
分業してると直せないとか、
作ってる最中にこの作り方しないで、
もっとお客さんの言ってる要件変えた方が、
お客さんと一緒に要件変えた方が簡単に楽にできるみたいなことがわかった時に、
分業してると前の工程のところに何段階も伝言ゲームで戻さなきゃいけなくなるので、
もう戻せないみたいな。
4回伝言ゲームしてたら、もう4回元のところに戻して、
いや、このやり方変えませんかって言えないっていう風になっちゃうので、
もう戻れないですけど、
これ分業してなかったら、
そこをビカビカさせるよりこういう動きした方がいいんじゃないですかって言ったら、
21:01
実はやりたい人は画面ビカビカさせるのか、
グラグラ動かすのかどっちでも良いんだけど、
分かんないけどビカビカさせてくれってエンジニアに言ったら、
ビカビカさせるのめちゃくちゃ難しいけど、
エンジニア頑張って作っちゃうって、
分業して起きちゃうやつで、
これ実はグラグラさせる方が楽ですって言えたら、
グラグラで良いですよってなるんだけど、
これ分業してたら無理なんですよね。
だから、後からやってみてる途中で分かって直すような仕事の場合は、
分業しない方が良いけど、
さっきのペットボトルで、
たくさん飲み物作るってなってたら、
製造工程まで行った後、
これやっぱり味変えた方がいいねって多分ないので、
それは人増やしたら、
もしくは装置を増やしたら早くなるっていうのと、
種類が違うなっていう感じがしていて、
医師の小売の人も、
中小企業さんで結構新しいことやるって言った時も、
分業してやっても早くならないっていうのは、
そういうことなのかなっていう感じですよね。
分業か一気通貫かの話でいくなら。
そういう意味では、さっき私ちょっと分業って言葉、
一瞬混乱して使っちゃった気が、
今話しながら思い出しちゃったんですけども、
プロジェクトやる時、分業というよりも、
私、数学得意じゃない、
数学的な言葉を使うのは今からすごく怖いんですけども、
相次いってあるじゃないですか、合同と相次いって、
大きさは違うけど、
それに近いイメージでプロジェクトをやってるってとこあります。
分けるというよりも、規模のちっちゃい版っていうんですかね、
全体像を投資でやるんだけども、
学生がそんな大きいこと、企業全体のことってできないので、
形としてはよく似ているというか、
全体をやらないと終わらないんだけども、
規模としてこじんまりとするというか、
簡潔しやすいっていうのは意識してるかも。
だからその意味では分業じゃなくて、
どっちかというと、
掃除というイメージかもしれないです。
規模小さく一気通貫してるっていうこと。
そうですね。
僕も学生で体験をしたこととしては、
大きすぎる会社に途中から入って、
よくわかんないなと思って、
ちっちゃい会社に入ってみようって言って、
20人の会社に行き、
そこが何年かで何千人とかに大きくなったんですけど、
20人のときの全体像で、
こういう機能とこういう機能はこういうふうにつながってるようなのが、
分かった上ででっかくなると、
それは大きくなっても、
結局あそことあそここういうふうに影響しあったりするようなのが、
分かる感覚が持てたので、
24:00
その掃除っていうのはとても意味があるというか、
機能する気がします。
エンジニアの育成もそうなんですよね。
システムって作ってると大きくなるので、
企業で扱うシステムって大体大きいんですよ。
若い社員が入ると、
例えば事業会社さんとかで若い社員が入ると、
どこの仕事をするかっていうと、
その大きなシステムの一部だけ作ることになりますね。
メンテナンスするとか、ちょっと画面変えるとか、
ユーザーの予防に合わせてデータの持ち方変えるとか、
ぐらいはしていくんだけど、
ゼロから作って最後まで作るっていう経験をする機会が
なかなかないんですよ。
だけどエンジニアとしては、
全くゼロのところから1行目から書いて、
それを全部書いていって最後動くところまでっていう、
一気通貫のアプリ開発ができた方が、
やっぱり得られる経験値としては圧倒的に大きいんですよね。
もちろんどっちも経験値は得られるんだけど、
大きなシステムの一部だけ作り続けていくっていうよりは、
小さいシステムでもいいから全部作るっていう方が、
経験を得られるっていうのと、
今の話近いなって感じがするし、
多分サッカーとかも、
ずっとドリブルの練習とかパスの練習だけして、
Jリーガーになるじゃなくて、
練習だけど、ゲームするんじゃない?
試合するんじゃない?っていう感じがしていて、
それは掃除の話と育成の話って、
通じる感じがするなっていう感じはしましたね。
掃除で小さいほうが、
育つにも育ちやすいのかなっていうのは、
感じましたね。
もしかしたら、学生の人たちと接している時間が長いからこそ、
山形先生なりの若者のどう育つのかとか育てるのかみたいなのって、
今のところからも知り得られそうだなって思ったので、
今も早くも20分経ったので、
第1回としては、簡単なご紹介としてはこれなんですけど、
その辺の人の若者の育成みたいな話は、
今日聞いてみたいテーマだなと、
何か思いましたね。
ちゃんとできるかどうか。
これは僕からの雑な相談のやつです。
いい、はい。
ということで、第1回としてはこの辺で終わりにして、
引き続き第2回、第3回と続きますので、
引き続きよろしくお願いします。
はい、よろしくお願いします。
では、また来週。
