倉抜きです。中山です。ザッソウラジオは、倉抜きとがくちょこと中山さんで、僕たちの知り合いをゲストにお呼びして、雑な相談の雑草をしながら、イルコをしゃべりしていくポッドキャストです。
えー、今月は2人トーク会が2回ありまして、今回は2回目のフリートーク会となります。よろしくお願いします。
お願いします。
あれですよね。毎回5周目の男として、大島さんが登場する。
大島さんが登場するはずですが、今回はスケジュールの都合が合わず、登壇できないということになりました。
5周目が2人会ということですね。
2人会ということと、ちょうどですね、僕は来月6月10日に私の新刊が発売に。
おめでとうございます。
ありがとうございます。人が増えても速くならない。変化を応用せよという、もうほんと何年ぶりかな。
雑草以来の本なので、短丁だとおり久しぶりに出す本を出すことになりましたので。
せっかくなので、大島さんがいない間にちょっと僕の告知会とさせていただけたらと思っております。
本についての雑草。
はい。あれですよ。1年ぐらい前からずっと言ってたやつですよ。
そうですよね。
そうですそうです。
で、クラシコムの社外取り、くらぬきさんがやっていて、
もともとその背景として、青木さんがエンジニアの考えというか視点というか資座というかが、
経営者として変わらないとどういうふうに関わっていいのかもわからないんだよねみたいなところから、
くらぬきさんどうなの?っていう質問、そこから始まってるみたいな。
そうですね。
そうでしたよね。
そうそうそう。
いやもう本当ね、もともとのもともとは、あれですよ、学長の紹介で青木さんとつないでもらって、
で、クラシコムっていうのは、北欧クラシの、ご存知の方も多いと思いますが、
北欧クラシの道具店っていうECサイトを運営してるんですけど、
そちらがね、昔はショッピングモールで運営してたんですけど、
ある時からショッピングモールだけじゃなくて、自分たちでいろいろやっていこうということで、
自分たちシステムを作ってね、内製して、ECもやったりドラマやったりっていうのをしてたんですけど、
そうするとやっぱり社内でエンジニアがいないと内製していけないので、
エンジニア組織をしっかり作っていこうみたいなタイミングで、
僕と青木さんが知り合うことが、学長のきっかけで知り合うことができて、
内製していくにあたり、エンジニアのマネジメントどうしていくのかとか、
ビジネスの中にシステムがあるので、そのシステムとかソフトウェアをどう扱っていくと効果的なのかみたいなところとか、
っていうのが、なかなか知見がある人が世の中にあまりいないねっていうか、
経営とテクノロジー両方やった人いないねっていうことで、
じゃあ僕が良ければということで、社外取締役ということで、一緒に経営させてもらう形になり、
その中でやっぱり、僕自身はずっとエンジニアのマネジメントをしてきた人間だし、
ソフトウェア開発を、自分でコードも書いたし、それを作るところのマネジメントもしてきた人間なので、
ソフトウェアの世界においての当たり前って結構あるんですよね。
それほど表題になっているように、人が増えても早くならないよね、みたいなことが分かってはいるんだけど、
一方で、青木さんは、いわゆる普通の経営というか、いわゆるECをずっと経営されてきたっていう、
ビジネスの世界においての経営をされてきているので、どうすればオペレーションがうまくいくのかとか、
どうすればマーケティングがうまくいくのかっていうことを専門にされてきた中で、
普通に考えちゃうと、内製しているシステム、もうちょっと生産性を上げたいなと思ったら、
人を入れようとか、若い人でもいいから入れておくと、生産性が2倍にはならないけど、
1.2倍くらいにはなるかなっていう発想になりがちじゃないですか。
青木さん、それは違うと。
今のエンジニア、中堅クラスのエンジニアが2人くらいいるときに、
3分の1を若いエンジニアにしちゃうと、むしろ生産性が落ちちゃいますよみたいな話とか、
っていうのをさせてもらったりだとか、いわゆるソフトウェアを作っていくときに、
新機能をどんどん作ろうみたいになっちゃうんだけど、
新機能ばっかりにリソースかけちゃうと、実はバージョンアップとかメンテナンスとかが置き去りになってしまうと、
どっかの段階で崩壊してしまうので、一定の時間メンテナンスにリソースがかかないと、
どっかで大崩壊起きちゃうみたいな話とか、っていう、
いわゆる普通の経営者の人が、青木さん普通じゃないんだけど。
普通じゃない。
でも、経営畑だけで経営してきた人が考える施策と、
エンジニアマネジメント、ソフトウェアマネジメントの世界とのギャップがやっぱり結構あるなっていう。
そこのギャップが埋めれたらいいかなっていうのを、ずっとClassicomでお話ししてきた中で、
青木さんがすごく、ザストラジオに出てきてもらった時もあれだったんですけど、
素朴な質問してくれるんですよね。
それこそ、世の中の経営者の人とかは、そんな分からないこと分からないって言いにくい人たちもいっぱいいる中で、
分かんないことスッと分かんないって言ってくれて、
でも、それ分かんないんだ、分かんないとしたらどう説明すると一番、
プログラミングしてない人にも分かるようになるのがどうすれば説明できるのかなみたいなのを、
ちょっと僕も考えるようになり、そこの言語化がめちゃくちゃ進んだので、
これちょっともう、一冊本にできるぐらいにネタとして余ってきたなみたいな。
エンジニア向けに本を書くのではなくて、
僕自身もずっとビジネス系の本を書かせてもらったので、
今まであまりやってなかったですね。ソフトウェアの世界で技術書は書いたことあるし、
ビジネス書の世界でビジネスの話は、マネジメントとか組織の話は書いたことあるんだけど、
ビジネスの方にエンジニアの時の経験を書くというか伝えるってことは、
今までしてなかったんですけど、
ちょっとなんか、そろそろやってもいいかなみたいな気持ちに、
やれるかもなみたいな感じになり、そこでの経験をまとめたのが今回の本になったという感じですね。
まだ読んでないんですけど、面白そう。
例えばまさに青木さんみたいな立場の人が読んだら面白そうっていうのはもちろんわかるけど、
それそうじゃない人がこんな風に楽しめそう、面白がれそうみたいなのって、
どんな感じですか?抽象化するとというか。
そうなんですよ。
作っている間に今回のプロモーションに手伝ってくださっている方とかにも読んでもらったりすると、
もちろんシステムの世界とかソフトウェアの世界のことなんだけど、
クランキさんこれ実は新規事業でも当てはまりますねみたいな話だったり、
実はこれ経理の世界でも当てはまるんですよねみたいな話を聞いたり、
僕はソフトウェアだからこそだと思ったことなんだけど、
人が増えても早くならないって、新規事業なんかもまさしくそうだよって言われてみたら思ったし、
実はいろんなクリエイティブな仕事とかにはまさしく全然通用するなっていう風になるし、
経営している経営チームの人たちも経営の人が増えたら会社がうまくいくかっていうと、
いやいや人が増えても早くならないなみたいな、経営者を3人にしたら3倍の会社になるかってならないなみたいなのと、
同じことだったり、面白かったのは経理の人とかも実は0から1を作り出さなくても、
やっぱり結局人が増えても早くならないってどこでもありますよねみたいな話になっちゃう話なので、
これは僕自身はこの具体の部分に関してはソフトウェア開発って文脈である意味例示をしているけれども、
実は現代のお仕事にとっては結構どこにでも通用するあるあるなんじゃないか、
クリエイションとオペレーションみたいなことかもしれないですね。
そこにいろんなところに応用効くんじゃないかなっていうのが、
少しですけどね、読んでいただいたというか見ていただいた方々の反応を見て感じているっていうところはありますね。
なるほど。
あとは青木さんにも、青木さんに最初に読んでもらって言っていただいたところで、
タイトルにサブタイトルにつけた変化を応用せよってキーワードにも通じるんですけど、
僕の視点、くらぬきの視点というか、青木さんが言っていたくらぬきさんの視点は、
どこがユニークかなっていったときに、変化とか変わっていくものとか、
ソフトウェアとかビジネスとか柔らかいものとかに対して、
いわゆるそこのスタンスがユニークですねって言われていて、
わからないものとかリスクのあるものとか変化しそうなものを見たときに、
人間だとそこをきっちり整理しようとか、きっちり理解しようとか、きっちり統計を取ろうとか、
もしくは数字化しようとか定量化しようとか、
もしくはマネジメントするっていうことは、つまびらかにすることであるみたいな、
コントロールすることですね、ガバナンスしてコントロールすることだと、
なんか考えがちなんだけど、もうわからないものはわからないって受け入れるんですねみたいな、
ふんわりしたものはふんわりしたものを受け取ったままだけど、
それを良い感じに保つっていうことをしてるっていうのが、きっちりした方からすると、
ちょっと変わってるなと思うスタンスですねって話で、
僕自身も確かにそうだなと思っていて、もうわかんないのはわかんないからしょうがないからって、
だけどわかるとこだけ、コントロールできるとこだけコントロールしようみたいなことだったり、
ソフトウェアなんかそうなんですけど、大きいものを一気に作ろうとすると、
わかんないこと多すぎて失敗するから、わかる範囲に小さくして、
ちょっとずつ作っていくとか、ちょっとずつ理解していくとか、
ちょっとずつやっていったら途中で変わったとしても方向転換しやすいよねとか、
っていうスタンスでいるっていうのが僕のスタンスなので、
それがこのサブタイトルに変化をコントロールしようではなく、
カタカナは使わないっていうことを考えてプログラムコンテンツを作ったのですよ。
ブラウザって言わないようにするんで。
いやいや、大事ですよ。
大事ですよね。
その、人間わからない言葉が出た瞬間に、ちょっと思考停止っていうか、自分もそうですよね。
他の業界でね。
言われたときに、なんかわかったふりするとか、頭の中に、耳には入ってるけど頭に入らないみたいなことが起きるので、
その聞きなれる言葉に書く、直すっていうのはあれですね。
あと今回あれです。僕今回の本で頑張ったことは、さっきの英語カタカナ出さない縛りみたいなのと、
あとは短くするっていう、本自体のボリュームを密度を高めて文章量を減らすっていう、
ページ数がちょっとだいぶ減ったかな。結構短くしてるんですよ。薄めの本にしてる。
で、よく前から言ってるじゃないですか、薄い本出したい。薄い本出して、薄くてもちゃんと価値があるのが、
安崎さんのときに出てましたけどタイパがいいじゃないですか。タイムパフォーマンスが。
タイパのいい本って、その方が価値があるんじゃないかと。
分厚くて金額が高いのは当たり前だけど、金額は変わらないのにページ数が少ないって。
タイパはいい。昔の人からすると、なんか高いな、薄いのに高いなって思っちゃうけど、
分厚い方がいいなって思っちゃうかもしれないけど、タイパで考えたら薄くて密度が高い方が絶対良いんじゃないかという、
仮説というかね。僕ら自身もそうじゃないですか。タイパのいい本の方が好きじゃないですか。
後で読み替え好きにもなりますしね。
なので今回は136ページなんで、これはね、ちょっと自分の中ではドキドキするんですよ。
グズグズいっぱい書くタイプの人間なので、今回削りに削って、それでも編集さんにいっぱい削られて、
いやいや削りますか、削ろうかみたいなことで削りに削ったので、
グズグズ書ききれなかった部分だけカットした部分は、後でブロッカーなんかで、そっちはグズグズ書いてみたら良いかなと思ってますけど。
面白いですね。タイパがいい本って、確かにこれから大事なキーワードになる。
いや、そこをね、切り開きたいですよね。タイパを意識したいですよね。
洋書とかね、翻訳本とかめちゃくちゃタイパ良くないですもんね。