エンジニアストーリー by Qiita
日本最大級のエンジニアコミュニティ、Qiita プロダクトマネージャーの木尾の俊文です。
この番組では、日本で活躍するエンジニアをゲストに迎え、キャリアやモチベーションの話を深掘りしながら、
エンジニアの皆さんに役立つヒントを発信していきます。
今回のテーマは、CTO視点でのエンジニアリングです。
今回はですね、CTOの方と一緒にエンジニアリングについて、いろいろ語っていけたらなと思っています。
はい、ということで、ゲストにはレイヤーXCTOでCTO協会理事の松本勇気さんにお越しいただいています。
僕もですね、今日お話しできてとても楽しみにしていたので、すごくワクワクしています。
では本日のゲストを紹介します。レイヤーXCTOでCTO協会理事の松本勇気さんです。
よろしくお願いします。
はい、それでは簡単に自己紹介お願いします。
はい、今の肩書きでいくと、レイヤーXという会社の代表取締役兼CTOという
立場で、今会社の経営の方をさせていただいております。
で、あとそれ以外に今ありましたけれども、CTO協会、だいたい今日本中のスタートアップとか
いろいろな会社のCTOが700名ほどですね、所属しているコミュニティがありまして、
それを運営している一般社団法人日本CTO協会というところで、理事もさせていただいております。
その他今、2社ほど社外取締役などもしておりまして、
会社のガバナンスとかそういったところも含めて、割とエンジニアリング以外もいろいろと取り組ませていただいておるようなところです。
ではですね、まず
松本さんにですね、お伺いしたいなと思っているのが、
本当にあの若くから、いろいろ僕も調べさせていただいたんですけども、GNOCの
ところからDMMさんだったりとか、あと今レイヤーXさんでもCTOってところを
務められているのかなと思うんですが、
学生時代からどんなキャリアを実際積んできたのかというところ、もう少し
細かくお伺いしてみたいなと思っているんですが、学生時代ってどういうことをやっていらっしゃったんですか。
そうですね、あの学生時代、プログラミング始めたのが
大学2年か3年ぐらいなんですよ。 そうなんですね。
プログラミング始めたのも、起業がきっかけみたいなところがあって、
大学2年か3年のときに、最初起業しようと思ったんですね、エンジニアよりも先に。
会社始めようかなって、その年は始めなかったんですけども、知人の
OBと、あと友人と一緒に起業しようとしたという年があって、
そこからやらなかったんだけども、そこからこう
他にも起業したい人たちといろいろ会っているうちに、
松本さん一緒にやりませんかというのをお誘いいただいて、
で、その当時、友人がCEOをやって、僕がCTOをやると。
ほぼじゃんけんで決めたみたいなノリですよね。
で、そんなノリで
CTOを落として、僕のエンジニアキャリアが始まったということで、本当に最初からCTOだったんですよ。
プログラミングも、そこから始めたと言っても過言じゃない。授業は一応とったんですけど、
ちゃんと、いわゆるプロダクト作りなんか始めたのは、もうそのぐらいですね。
そうだったんですね。じゃあ、大学でこう、例えばコンピューターサイエンスとかを専攻してたとか、そういうわけでもない
ですかね。そうですね。2年生というとまだ教養課程なので、東京大学の方に出身なんですけど、
教養課程だったので、特にこう、コンピューターサイエンスを専門にとっているってこともなく、
大学3年の時に、一応機械系と情報系両方取れそうな学科にはいたんですけども、
もうその時には起業してしまってたので、はい。もうずっと独学でプログラミングをやっていたっていうのが正しいですね。
そうなんですね。ありがとうございます。なんか、なかなかこう、結構その
エンジニアとして経営やっていらっしゃる方って、もともとエンジニアリングが好きで、プロダクト作ってたらそれが
サービスとしてうまくいったんで、経営もやってますみたいな方が多かった
印象があるので、僕は。なんかすごい、結構違うタイプの今、経営を積んでいらっしゃるんだなってお話聞いてて感じました。
確かに周りは結構、昔からプログラミングをやっていますとか、
なんかこう、小学生からゲームプログラミングから入りましたとか、そういった知人が多いんですけど、
自分自身はなんか全然そういうタイプでもなかったので、ちょっとこう、特殊なタイプだったかもしれないですね。
先ほどあのお話の中にまたと思うんですけど、最初起業したいってお話あったじゃないですか。
だからそもそもなんで起業したいって、こう学生時代からこう思ったのか、みたいなところをお伺いしてもいいですか。
一番最初は、まあ自分の親も自営業だったので、そもそもこう起業というものが身近だったのと、
大学のOBにそそのかされたみたいなところもありますよね。起業一緒にしましょうよみたいな。
それまでは普通に意識高い学生、いわゆる意識高い学生で、外資系コンサル行こうかなとか、
なんかそんなことを考えてたような人間だったんですけど、そこから起業っていうものに触れて、
自分で業を作って稼ぐ、仕事を作って稼ぐ、これ面白いなみたいな感じになってきて、
そうなると自然と2010年頃なんで、SNS全盛ですかね。
ミクシーとかFacebookとかが大きく日本でも流行っていて、SNS作ろうぜとかそういう話に自然となっていって、
だったらプログラミング必要だよねみたいになってきた。それが楽しかったから起業してたみたいなところがありますよね。
そうなんですね。ありがとうございます。実際もう学生時代からってなると、実際働いて、
会社員として働いたご経験っていうのはない状態からいろいろやってらっしゃるのかなと思うんですけど、
実際そこからもうゼロから経営入ってみて大変だったこととか、しんどかったことみたいなもしあればお伺いしてみたいです。
いやしんどいことしかないですよね。お金の受け取り方すらわからないわけですよ。
請求書という概念すら知らないみたいな、今請求書のサービスやってる会社やってますけど、
起業した当時って請求書って何?領収書って何?違いはよくわからんみたいなレベルで経営してるわけですよ。
経営といってももう本当大学のサークル活動に近いレベルですよね。
なんかもの作って、なんか出しては見るけど広告の打ち方もわからなければみたいな、なんかものだけがあるみたいな状態で、
もうその辺で手探り手探りでいろんな人に会ったり出資をしてもらったりしながらだんだん勉強してったみたいな感じですし、
プログラミングも初めてなんで、どこから手をつけたらみたいなレベルですよね、その時は。
なので一生懸命調べて、パイソンという言語があるのかと、当時ちょっとよかったのはGoogle App Engine使ったんですよ、
GCPが登場する前のGoogle App Engine、それを使ってサーバーサイド書いて、当時まだリアクトもビューも影も形もない時代なんで、
JQueryと当時出たばっかりのPushState APIを使って、今で言うとこのシングルページアプリケーションを全力で作ってたっていう、
なんもわからんので、ひどいコードが10万行くらい生成されているみたいな感じですね。
そうなんですね。なかなかその当時のWebアプリケーションとかWebサービスを作ってた当時の雰囲気とかあんまり知らなかったので、
お話聞いてて、そんな感じだったんだなというふうに思いました。
ではちょっとまた違うご質問させていただこうかなと思うんですけど、その中でいろいろ最初わからないところからいろいろやって、
なんとかずっといろんなことやってらっしゃったと思うんですけど、
天気というかちょっと軌道に乗り始めたなみたいなことを感じるタイミングってあったりしましたか。
4社目がGNOSHIなんですよね。実は今行った会社1社目が1年目うまくいかず、
またその後フリーランスと知人の会社の立ち上げ足隠れ鉄だったり、もう1社時間割のサービス作ったりしていて、
その頃までは本当に師匠もそんなにいない、みんな周りも学生みたいな状態で開発してたので、
一時期IBMの人とかにいろいろ教えてもらったりとかしてたんですけど、ほとんど手探り状態だったので、
GNOSHIって会社ができるぞと、会社になるので来てくれないかということで、
誘われて2つ返事で入ったんですけども、そこでやっぱりいろんなシニアな人にも会えたっていうのが一番大きな転機だったんじゃないかなと思いますね。
そうだったんですね。初めてのキャリアがGNOSHIさんだと僕は思ってたので、その前からもやっぱりいろんな挑戦しながら失敗もしながら、
失敗だらけですね。 やってらっしゃったってことだったんですね。ありがとうございます。
いやなんかもう今のお話聞いている感じ、本当にいろんなことをすごいやってらっしゃるなっていうふうに感じていて、
本当にもう学生時代自分と比べたら、自分何やってるんだろうね、気持ちになるようなすごい本当にキャリア積んでらっしゃるなと思ったんですけど、
今聞いてた感じ、ただたまたま運が良かったとかそういうことでは本当になくて、やっぱ自分から行動を起こし続けてらっしゃるなというふうに今感じたんですけど、
なんでその行動をし続けられたのかみたいな原動力みたいなところをお伺いしてみたいんですが、
技術設計した先に技術設計だけじゃなくてそれを実現できる人も連れてくるみたいな その双方、人とソフトウェアと見ていくみたいなのがCTOとしてはよくやっていることですね
ありがとうございます じゃあCTOとしてこう何ですかね もう自分がプロダクトを作るってよりもそもそもやっぱりその先ほどお話しあった4社
その経営というところの観点でプロダクトとか全体的な技術ってところこういう方向に持っていき たいよねっていうその旗振りをするみたいな
そういう役割というか そうですねなんかそのテックリードとかがいわゆるシステムの システムっていう単位でアーキテクチャ設計に責任を持っているとして
PDMがプロダクトって単位でその責任を持っているとして 事業部長が事業って単位で見てるとしたら僕はその会社っていう単位でアーキテクチャを考えているみたいな
そういうイメージを持っていただけるとなんかその深くまあなんだろう 範囲がより広いアーキテクチャを作ってるみたいなそんなイメージですね
ちょっとまた質問僕がちょっと気になっていることみたいなところをお伺いしてみたいなって思うんですが
やっぱりその経営観点みたいなところで いわゆるそのテックっていうところかけるその経営っていうところの観点で考えるとよく
議題として出やすいのがやっぱ技術的不採みたいな話あるかなと思っていて やっぱ目の前の事業とかプロダクトのグロースっていうところと
トレードオフの議論になりがちな気はするんですよね その技術的不採ってものをそもそもどうやって捉えているのかとか
普段こういうふうにそこを扱ってますみたいなところが何かあればお伺いしてみたいなって思ってます
まず書いたプロダクトは絶対不採ですよね なのでまあその前提があって
ただなんかこう例えば早く作ると技術的不採が増えるとかあれはなんか違うなと思ってるんですよね
技術的不採ってどこから生じるかっていうとなんか事業の変化に対してずれたソフトウェアになっていること
まあなんかもともと例えばこうwikiを試行していたけどSNSになったみたいな
なんかそういうケースがあった時になんか全然それってソフトウェアアーキテクチャ違うわけですよ理想は
なんだけどそれをこう無理やりこう昔のアーキテクチャでやっちゃっているとこれは大きな技術的不採になってくるなと思っていて
変化への追従みたいなところが一番大事だと思ってるんですね
するとさっさと間違うみたいな方に振ってできる限り早く答えにたどり着くことが一番不採を抑える方法
トータルでは不採を抑える方法なんじゃないかなっていうのが一つ思っているところなのと
あとはですねもともともないことなんですけどやっぱり技量で不採の生まれる量なんて全然変わるなと思っていて
同じ1ヶ月かけて作ったものでもやっぱりこう今うちの社内にいるメンバーたちを見ていると
なんか僕が学生の時の1ヶ月の行動と彼らの書く行動はもう全然違うと
当然ながらリファクタリング可能性とかもきちんと考慮されているテストもあるCIがあってCDがあって
品質指標なんかも見ていてQAのプロセスもちゃんと組まれていてっていう状態と
なんかわかんないから一生懸命調べながら作ってますっていうプロダクトだと当然生まれる不採の量が違うので
一番大事なのは良いチームを組むことが技術的不採に抗うもともこもない答えかなと思っています
でそうですねその中でも長期と短期であるべきアーキテクチャが違ったりもするんで
少なくともその2つ短期と長期で議論が白熱するような状態を作っておくことも当然やっておくべきかなと思っているので
そこの中でバランス取りながら作っていくと比較的中長期でも変化に追従できるソフトウェアになるんじゃないかなと思っています
変化に追従できれば僕は開発体験が多少落ちていたとしても事業的に見れば不採ではないと思ってるんですね
なんか事業の変化についていけないこと自体が一番の問題なので
なんか明日こういう方向に家事を切ろうと思ってるって言った時にすいません私のプロダクトだと1年かかりますって言われたらこれって失敗なわけですよ
そうじゃなくてなんかこっちに行きます右に行きますって言われたらちゃんと右に家事を切れるように
変化しやすい捨てやすいプロダクトづくりですね僕がいつも言ってるのは
捨てやすい行動を書くっていうのを意識するようにっていうのをやってます
なるほどありがとうございますどっかのイベントでもちょうど同じようなお話しする中で
やっぱりソフトウェアって生物だよねみたいな話は語られることはやっぱり過去もあったなーって今お話し聞きながら感じてて
やっぱりプロダクトって生まれた時点から例えば言語とかもバージョンどんどん新しいの出ていくし
何も触らなくてもどんどん不採が溜まっていくみたいなものだと思うのでまさにそこを常に最新であることっていうところが
常に良いっていうよりも常にやっぱりそこを自分たちが変化したい時に自由に変化できる状態をしっかり担保するために
ここまではちゃんと担保するとかここまで切り分けていろいろできるようにするみたいなことを考えていくのが大事なのかなっていうような
今お話し聞きで僕も感じました
まあこれを言うと賛否両論はあるんですけどやっぱり最新のソフトウェアに追いついているかってことよりも
自分たちが事業上を達成したい変化に追従できていて達成したい非機能要件をちゃんと満たせているかみたいな
この観点がどれぐらいの視点で担保できているのかだけだと思うんですよね
逆に最新に寄りすぎたから何か問題が出てくるみたいなことも当然あると思ってます
個人的には何か事業
事業っていうと何か固い仕事みたいな話になるんですけど
もっと言うとユーザーが欲しいものがちゃんと早く届くようにすることに一番頭を使おうぜだと思ってますし
まあそのためにはそうですね負債を減らす意味ではシンプルに作ろうっていうのが一番大事な
一番っていうか大事なことなんじゃないかなと思います
ありがとうございます
ちょっと最後1個だけ聞いてもいいですかこの回で
ちょっと今お話いろいろ聞いている中でやっぱりその経営っていうところでCTOみたいな役割として
いわゆるエンジニアリングがわかる方が入ってらっしゃることってすごい価値あるなっていうふうに感じたんですけど
その一方でCTOみたいな役割がない会社さんとかも多いと思うんですねやっぱり実際問題
ソフトウェア作っててもその経営陣にエンジニアリングがわかる人はいないみたいな会社多かったりすると思うんですけど
その中でとはいえやっぱりそういう技術っていうところの観点でプロダクトを良くしていきたいみたいな思いを持っている人がもしいたとしたら
なんかどういう動きしていくと良さそうかみたいなところがもしアドバイスがあればお伺いしてもいいですか
僕はやっぱり経営陣にどうやって入っていくかっていう視点を持つのがまあ最初かなと思っていて
なんかその当然僕はよくCEOあの起業家の集まりとかもあるんでよくいやソフトウェアはわからんのに経営してるって僕的に意味がわかんないんですけどってよく言うんですよ
そうするとなんかこうコンサル出身とかの人たちにいや文業が大事だって言われてる
もうそういうこと言われるとちょっとピキッと聞きながら いやいやそうではないですよって話をするんですけどね
ただあのとはいえこう双方歩み寄っていくことが大事かなと思っているので
あのもし自分がなんかそこでまあよりこう自分がプロダクトとかソフトウェアをより良くしていきたいと思うのであれば
その自分がより良くしていきたいと思っている方向性と会社のような迎えたい方向性
例えば社長だったりとか経営人が向かいたい方向性これがどうやったら寄り添うのかっていう視点を持っていくのと
それをですねあの経営人の言葉で語れるかみたいなまあその部分に注目した方がいいかなと思っています
相手に理解してもらえないことは相手も取り入れることができないんで相手の言葉で今こう考えれば確かに今社長とかCEOとかが
これは大事なことだと言ってくれるだろうみたいなそういうふうにこうなんだろうな相手とのコミュニケーションをしていくというか
僕はまあ言葉選ばずに言うと攻略していくっていう言ってるんですけど相手のこうなんか思考パターンとかを読んでいって
こういう言葉でこういう風なモチベーションでこういうことを語ればおそらくこの人は動くっていうのを丁寧に分析して
それをベースにきちんと技術戦略を寄り添わせて作っていくことでそれはあのそのままあの経営からの信頼にもつながって
結果としてそれがCTOになるってことにつながっていくと思うんですよね
なるほどありがとうございますまさにこういないなら自分がこう経営っていうところに対して入っていくみたいな
こうスタンスっていうのはなんかまさに松本さんらしい誤解と成果確かにそれができたら確かに
自分がCTOになればいいんだみたいなのはあの感じましたありがとうございます
なんかでも今お話聞いている中でやっぱり改めて感じたのがなんかその経営陣にただ求めるだけではなくて