現役CTOが経営視点を持ったきっかけは？　CTO/VP of Eになれるエンジニア、なれないエンジニア - Part1

CTO/VP of Eになれるエンジニア、なれないエンジニア

司会者：それでは、さっそく登壇者のみなさまにお入りいただきたいと思います。みなさま、拍手でお迎えください。どうぞよろしくお願いします。

（会場拍手）

あらためてご紹介をさせていただきます。クライス＆カンパニー顧問の及川さんです。

（会場拍手）

WAmazingの舘野さんです。

舘野祐一氏（以下、舘野）：よろしくお願いします。

（会場拍手）

司会者：FiNC Technologies、南野さんです。

南野充則氏（以下、南野）：よろしくお願いします。

（会場拍手）

司会者：では、及川さん、よろしくお願いします。

及川卓也氏（以下、及川）：あらためまして、こんばんは。及川と申します。よろしくお願いいたします。第1部は1時間ちょっとですが、司会からご紹介ありました南野さん、舘野さんとで話をしていきたいと思います。

今日のお題は「CTO/VP of Eになれるエンジニア、なれないエンジニア」です。ちょっと刺激的なタイトルでもあります。

必ずしもCTOとVPoEを目指すことがすべてではないなと思いつつも、最近こういった開発系のトップポジションとしていろいろ語られることも多くなっています。ですので、こういったポジションがどういうポジションかということを理解した上で、自分に合っているかどうか、もし目指すとしたらどんなことが必要かということを、この3人で紐解けていけたらいいかなと考えております。

この汐アカに何回か出られた方はご存じだと思うんですけれども、「Sli.do」を使ってオンラインで質問をいただこうと思っています。もしかしたら質問を出されたとしても、それに関係なく普通に我々が話すかもしれないんですけれども、スキップするだけですので、あまり気にせずに聞きたいなと思うことをどんどん書いていってください。

それでは、登壇者です。簡単に自己紹介していきたいと思います。私はもうこの業界30年ぐらいおりまして、長く外資系企業でソフトウェアの開発をやっていた人間です。

外資系3社のあとに「スタートアップ」と書いてあるのは、Incrementsという会社です。「Qiita」というプログラマのための情報共有コミュニティサービスの企画・開発に携わりました。

その後、いろいろな会社の技術支援やアドバイザをやり、2017年よりこの会社の顧問という立場で、基本はIT人材の流動をお手伝いしております。よろしくお願いします。

では、舘野さんお願いします。

エンジニアリングマネージャー、技術部長、CTOのキャリアを歴任

舘野：はい。みなさんこんにちは。舘野といいます。私は大学卒業してからずっとIT業界なので、だいたい16年ぐらい携わっています。

仕事としては、最初のキャリアとして受託開発の会社に入り、その後2006年に「はてな」というWebサービスを運営している会社にジョインしました。

はてなに最初に入ったときは、一ソフトウェアエンジニアとして開発を行って、2009年頃から「はてなブックマーク」というソーシャルブックマークサービスのエンジニアリングマネージャーとして「はてなブックマーク」の運営等々をやっていました。

その後2010年にマネージャー等々をやってみた上で、「やっぱり自分としてはもっといろんなソフトウェアのコードを書いてみたい」というところがあって、再び一エンジニアとして新しい場所でチャレンジしてみようかなと2010年にクックパッドに入社しました。

最初はソフトウェアエンジニアの立ち位置から入社してやっていて、1年半ぐらい一ソフトウェアエンジニアとして開発を行っていたんですけど、その時の自分は、自分の書いているソフトウェアがどんどん世の中をよくしていけばいいかなという考え方でしたが、やっぱり組織に所属する以上は自分1人の力に限界を感じるところがありました。

ちょっとモヤッと思っていたところ、その当時「技術部長にならないか？」というお誘いの声があったんですね。その時は「自分の力というのを、1人の個人ではなくて、組織として最大化するにはどうしたらいいんだろう？」というのをちょうど考えていたフェーズでもあったので、「じゃあ引き受けます」ということで、当時の10数人ぐらいのエンジニアリングのマネジメントの部署のトップになりました。それで、技術部長としてクックパッドの中のエンジニアの組織づくりを行ってきました。

それをやっていたなかで、2014年のタイミングです。ちょうど当時のクックパッドのCTOが海外のクックパッドの子会社の社長をやることになって、CTOのポジションが空いたタイミングがありました。その時に「クックパッドでCTOやらない？」というところでお声がけがかかります。その時は、一技術部長としていろいろやってきたんですけど、エンジニアとして、よくある「エンジニアの生産性って何だ？」「エンジニアの価値って何だ？」を考えていたフェーズでした。

「やっぱり一エンジニアが活躍するのには、その力を会社の事業価値だったりユーザー価値にしっかりとつなげなくてはならない」と思っていた時でした。「経営視点からのエンジニアとしてどういうことができるんだろう？」というところに興味を持っていたタイミングでもあったので、お声がけがかかって、執行役CTOというかたちでクックパッドの役員として、CTOとして2年ちょっとやりました。

みなさんご存じかもしれませんが、その後にクックパッドの中でいろいろありました。タイミング的にも離れるタイミングだったので、そこからは約半年ぐらい、いろいろな会社のお手伝いをしていました。

その中で、現職であるWAmazingの立ち上げ当時、WAmazingの社長の加藤という者と出会いました。「あ、この事業は非常におもしろそうだな」と思って、今のWAmazingにジョインして、そこでCTOをやっております。というのがざっくりとした経歴です。

経営者で、CTO

及川：ありがとうございます。では、続きまして、南野さん、よろしくお願いします。

南野：はじめまして、南野と申します。現職はFiNC Technologiesの代表取締役兼CTOをやっています。元々、大学研究室の所属は、今AIで有名な松尾教授がいるところで、東京大学工学部のシステム創成学科に在籍していました。当時からニューラルネットとか流通システムの開発をやっていました。

大学に入ったのも、発起人として起業したくて大学時代から、何社か会社をつくったり、どこかの新規プロジェクトに入れてもらって開発を行ったりしていました。

なので、卒業したらそのまま自分の持っている2社を経営していたといった状況でした。もちろん4人ぐらいでやっていた小さな会社だったので、開発メインの仕事が多くありました。

ビジネスモデルとしては、自分たちで作って、それを一緒に新規事業つくりましょうとか、あとは受託開発を受けて、納品するみたいなかたちが多かったんですけど、自分でサービス作っていきたいなという思いがありました。

自分でサービスを作っていくには、どこかの市場にサービスを投入しなきゃいけないといったところで、ヘルスケアがすごい自分の中ではしっくりきて興味がありました。「ヘルスケアやっていきたいな」と思っていた時に、代表取締役のCEO 溝口と出会いました。

溝口は、元々パーソナルトレーニングを18年間やっていて、栄養と運動に詳しいので、「じゃあ一緒にやりましょう」とFiNCに参画したのがきっかけです。

最初にFiNCに入った時は、CTOとして入りました。もともとは自分が経営していた会社の代表取締役で、営業もしますし、事業計画も考えるし、もちろん技術的なところも作りますといったところを全て自分でやってきました。そこからCTOというかたちで、もちろん経営もしますけども、基本、技術の戦略を作ったり、「FiNCに必要な技術は、どういう技術を選定していくの？」みたいなところをメインでやってきました。

そこから、約70名ほどのチームを1から作ったのがCTOとしてやったことです。そこから次は2018年9月に代表として着任し、2018年10月1日付けで「FiNC」から「FiNC Technologies」に社名変更に20日しました。さらにテクノロジードリブンな会社にしていこうといった感じで代表になったのが去年です。

今のメインとしては、会社の資金調達から事業計画、あとは事業部門長を見ながら、エンジニア組織。今は新しくポジションを作ってそのメンバーと回しているといったようなかたちになります。今日はよろしくお願いします。

及川：はい。あらためまして、よろしくお願いいたします。

ちょっとだけ個人的な話をすると、舘野さんも南野さんも実はけっこう前からの知り合いなんです。南野さんとは東大にある先生のところにお話に行ったことがありまして。あれ何年前でしたっけ？

南野：ええと、10年前ぐらいです。

及川：もう10年前？　「その時に実はそこにいました」というのをあとでFiNCを手伝うようになった時に言われて、「あっ、いたんかい」という感じでびっくりしました。

舘野さんとは、普通にGoogleの時にお仕事を一緒にしてっていうことで、本当にエンジニアとエンジニアのやりとりしていたところからの付き合いなので。まさかその時、そのあとの仕事でCTOになってお付き合いがあると思いませんでした。

CTOの1日

及川：このあとがっつり話していきたいんですけど、最初にカジュアルに一問一答で即答に近いかたちでお話しいただきたいことを聞いていきたいと思います。今でもコードを書いていますか？

南野：書いてます。

舘野：書いてます。

及川：おっ。注目している技術は？

南野：僕はDeep Learningにすごく注目しています。

舘野：僕は実はWAmazingの中国法人の社長もやっていまして、今は中国のIT技術っていろんなところでエキサイティングなんです。なので、中国系の技術には非常に注目しているところであります。

及川：典型的な1日を教えてください。

南野：だいたい朝8時ぐらいからミーティングが始まります。、結構幅広く事業を見ているのでミーティングが多く、各部門ごとにミーティングしていくというかたちです。あとは定例で朝ミーティングします。ランチは、だいたい外部の人もしくは社内のメンバーとランチを食べる予定が入っています。昼13時からまたミーティングが始まり、18時ぐらいに全部終わりますと。

そこから、採用や社内のモチベーションアップのためのイベントに参加したり、会食に行ったりして、その後も空いている時間があればコードを書いています。

舘野：僕のほうも、朝起きてだいたい8時ぐらいから言語を学習します。プログラミング言語じゃなくて中国語なんですけど、中国語をだいたい1日1時間〜1時間半、日によっては先生を呼んでやっていたりするのが朝の開始です。

私の場合はけっこう曜日によってやることを変えていまして、基本的に水曜と木曜はできるかぎり会議を入れないようにしてるんですよ。その時に技術リサーチや実装をバーっと集中して作る、というふうに分けることが多いです。

ほかの日にいろいろな会議から面接からさまざまな会社行事を入れてやっているというところで、けっこう曜日によって頭のコンテキストをスイッチしながら仕事をすることが多いです。

及川：「ノーミーティングデイ」を作ったりミーティングを重ねたりして、コンテキストスイッチを少なくするのは私もやっていたんですが、そんな感じなんですね。

舘野：はい、そのとおりです。

及川：なるほど。わかりました。今一番大事にしてることはなんでしょうか？

南野：自分の時間の使い方を大事にしていますね。

舘野：今ですと、意思決定の確度をどう上げられるのかというのはいつも考えているところです。やっぱり意思決定を間違えると会社全体にダメージを与えてしまうので。まだまだ未熟で「どうやったらそこの精度を上げられるんだろう？」というのは日々考えながらやっております。

CTOとはどんな仕事か？

及川：これは逆になるかもしれない。今一番困っていることはなんですか？

南野：「スケールする組織づくりをどうしていくか？」が一番悩んでいるというか取り組んでいることです。

及川：舘野さん、いかがでしょう？

舘野：僕はエンジニアの採用です。

及川：おお（笑）。

はい、ということで、もう少し深く聞きたいなというところもあるかもしれないので、それは質問で書いていただくか、もしくは第2部のほうで質問していただいてもよろしいかなと思います。

じゃあ、いくつかトピックを決めて深掘りしていきたいなと思います。

最初です。これはけっこう各社によっても違うなと思いますし、みなさんも疑問に思われているところかもしれません。まずは「CTOの役割」。「CTOってどんな仕事ですか？」ともし聞かれたらどのようにお答えされますか？

南野：僕からでいいですか？　経営状態を理解して、リソースやお金の問題もあると思いますけど、そういったヒト・モノ・カネをきちっと理解して、技術の選定やプロダクトの作り方を決めていくというのがCTOとしての一番の役割かなと、個人的には思っています。

及川：なるほど。

舘野：僕も同じで、本当に技術を持っているなかでどういう経営の意思決定をしていくのかがCTOの役割だと思っています。おっしゃるとおり、けっこうその会社によって違うところがありますよね。

CTOの技術がコアコンピタンスの会社ですけど、例えば「ディープラーニング」、今の流行りの言葉で言うと「AI」みたいなところをその会社の強みとして持っているところって、CTOがそこの部分を研究部門を引っ張っていくのが大切な会社もあります。

でも、弊社WAmazingは、ある意味「旅行×IT」の会社です。そうすると「旅行業界の事業を理解して、どういうふうにそれを技術として反映して、会社のプロダクトに落とし込んで成功に導くか？」みたいなところがミッションとしてあると思いますね。

そこは会社や組織によって異なるかなとは思うんですけど、やっぱりCTOが持っている技術の力をベースに経営の意思決定として関与していくっていうところが大切なのかなとは思っています。

及川：なるほど。やっぱり先ほどのお2人の自己紹介とかCTOになられた経緯のところでも、今言われた「経営視点」という言葉が何回も出てきていましたね。

経営視点にスイッチしたきっかけ

及川：ただ一方、おニ人みたいなかたちの経営視点を持っているエンジニアが少ないのも事実かなと思います。この会場の方もそうかもしれないですし、もしくは会場に来ていないような一般のエンジニアって、「僕はビジネス苦手です。好きなコードだけ書きたいです」と思う人も多いと思うんですよ。

南野さんは2社起業されたじゃないですか。起業されたときから、どこかで経営的な視点があったのかなと思います。一方で、舘野さんは先ほどの経緯を見ると、最初は一エンジニアでスタートして、どこからか経営視点を持たれているようになったじゃないですか。まず舘野さんに聞きたいんですけど、そのきっかけとかは何なんですか？

舘野：そうですね。及川さんと10数年前に初めて会った時って本当にただの一エンジニアで、僕自身も本当にコード書くことが大好きだったので、自分自身は今から考えると「絶対にこういうところに来たくないな」と思っちゃう立ち位置だったんですよね。

及川さんの言うところで、どこでそこがスイッチしたのかというと、クックパッド時代に印象的だったところがあります。僕はクックパッドで技術部長をやっていた時に、当時の社長から「もしお前が自分が社長やるんだったら、お前、自分自身どう動いてほしいの？」というお題をもらったんですね。

つまりどういうことかというと、「トップから見て、エンジニアってどういうふうに会社でワークするのが一番いいことなんだろうか？」と疑問を投げかけられた時に、技術を活かしてどういうふうにユーザー価値・事業価値につなげていくことができないと、その会社において技術って、ある意味独りよがりというか、実際のところはすごくがんばっても価値につながらないものになってしまう、というのがありました。

その時に「じゃあ、この技術をどういうふうに経営につなげていったらいいんだろう？」というところで、ある意味、その視野が広がったというか、技術のことだけを考えているんじゃなくて、「会社全体を見た上で技術をどう活用する？」というのが本当に会社全体・エンジニア全体にとって価値があることなんだというふうに考えが広がりました。そこが非常に強いきっかけだったかなと今でも記憶しております。

及川：なるほど、わかりました。

経営に興味をもった理由

及川：南野さんの場合も学生時代からというのがあったと思うんですけれども、それでも学生時代で普通に理系で研究もやられていたなかで、なぜ経営的なところに興味を持たれたんですか？

南野：経営に興味を持ったのは、祖父が起業家だったことが影響しています。。祖父がカステラ会社を経営していて、その姿を見たり、高校のときにそこで働いていたことがあり、経営者っておもしろいなと思いながら見ていました。自分でやりたいことをものにして売るのはすごい素晴らしいことだなと思いました。

大学を選んだのも、起業するために一番適したところがいいなと思って選んだので、元々起業することは大学に行く時に決めてました。

なぜソフトウェアにしたのかというと、やっぱり小さいところから試せたり、資金がなくても進められたり、信頼が少ないときから活躍できるといったらやっぱりソフトウェアかなというのはありました。

大学1〜2年は教養学科として、「どの学科にもいけるよ」という教養を進めるようなコースでしたが、3年で（専攻を）選ぶ時に、ソフトウェアで起業しようと思ったので、ソフトウェアの研究室にした感じですね。それで経営視点がだんだんついてきた。

でも、最初の頃はそんなことはあんまり考えてなくて、本当に「お客さんにどうやってバリュー返せるのかな？」というのが一番大事でした。最初に1円稼ぐのがすごい大変でしたし、お金ってすごい稼ぐのが難しいなというのは、起業した当初は思っていました。もちろん今も稼ぐのって大変だと思うんですけど。

大学の時から「自分のコードであったり自分の技術をどうやってお金に変えられるかな？」というのはずっと考えていて、その部分が一番大きいですかね。

どれだけユーザーを喜ばせられるか

及川：わかりました。今は「経営」という言葉で語ってはいますが、やはりおニ人の中にあるもう1つの共通点というのは、「事業に対する思い」かなと思うんですね。

ですから、舘野さんの自己紹介の時にあった事業価値、「ユーザーに何を価値を提供できるか？」とか、南野さんもヘルスケアというものに対して思いを持っていると思うんです。一般的なエンジニアっていうのは、事業に対しての熱意がないことも多いんじゃないかと思います。

本来ならばどこかの企業に就職するというときに、その事業、もしくはその会社自身が目指す方向に対して共感度が非常に高いことが望まれるんですが、やはりそんなでもない人たちもいると思うんですよ。

そういう人たちが多少そういった経営視点・事業視点というものをしっかり持つようにしていくためには、「自分の興味ある事業をやっている会社に転職しろ」というのが1つあるかもしれないですが、そうできないときになにかアドバイスありますか？

将来的にCTOなどの経営視点を持つというのは、最初は自分がやっている会社の事業に対してもっと価値を見出すとか、もっと事業に対して愛着を持つ・共感を持つところから始まると思うんですけれども、それをやるためになにかいいステップとかっていうのはありますかね？

南野：僕が一番大事だと思ってるのは、やっぱりお客さんを知ることですね。「どれだけお客様を喜ばせられるか？」だと思うんですよ。

なので、もちろん自分が好きな事業でお客さんを喜ばせられたらベストだと思うんですが、その選択肢がない場合は、お客様の目線で「自分がもしお客様だったら何をされたらうれしいか？」「自分のサービスを使っているお客様ってどういう人なのか？」の解像度を上げていく。あとは周りの友達にそんな人がいるんだったら、その人とよく飲みに行ったりとか、そういうところから始めていくのがいいんじゃないかと個人的には思ったりします。

コードの価値を問う

及川：なるほど。舘野さんはいかがでしょう。「はてな」は自分もユーザーでしたし、「はてな」が好きで入ったというところはわかりやすいんですが、次に料理に行き、次にまた旅行やインバウンド中心のところに行って、事業がバラバラのところへ行っていると思います。必ずしも最初からそれが好きでということではなかったこともあると思うんですね。

そこでどうやって事業に対して共感を持ち、経営視点でというところまでの視点を持つようになったかを教えていただきたいなと思うんですけど。

舘野：やっぱり僕自身がエンジニアとかとよく会話するのは、「自分が書いている1行1行のコードの、そのコードの価値がどこにつながっているのか考えてみよう」というところはよく話しています。

本当に技術が好きなエンジニアもいるんですよ。でも、自分がやっている技術って、必ずなにかがアウトプットになっているんですね。

それが、例えば管理系の機能だとすると、社内で使うとか、それで仕事が回って生産性が出しやすくとか、このコードを書くことによってメモリ使用の効率がよくなってサーバの台数を減らすことができるようになったとか、そのコードを書くことによってユーザーにとってなにか違った体験を与えることよって、そこに価値が生まれると。自分自身がエンジニアリングをしていることの価値というのは、必ずなにかに結びついているんですよ。

その「なにか」というのがなんなのかを考えてみようという話をしますし、やっぱり目標を決めるときにそのなにかというのは具体的に自分が一番やりたいことです。

例えば、エンジニアにとって「いや、俺すげえTypeScript大好きなんだけど、TypeScriptを仕事にどうにか使えないかな？」って思うのが事例としてあるじゃないですか。そしたら逆に「『それを使うことによってどういう価値に結び付けられるのか？』ができると、うちの会社で自由にTypeScriptをガリガリ書いて、そこのプロダクト作っていけるだろう」みたいな話をする。

そうすると、「今困っているこの部分のUIがこう変わることによって、ユーザーの行動が変わって、ECサイトなら例えばコンバージョンが上がりやすくなる」とか、管理画面においてだったら「スタッフの時間を減らすことができる」とか、なにかの価値に必ずつなげることができるので、そのつなげる価値を考えられる。そして「めちゃくちゃ自分自身がやりたいやりたい技術をバンバンやっていって、かつ、それが価値につながるから、そういうのを考えていこうよ」みたいな話をする。

それでエンジニアはみんなけっこう考えてくれて、「あっ、自分のやってるコードってこの価値につながっているんだ」を言葉にしてやれるようになっていきます。その中から徐々に事業やユーザーがさらに具体的なかたちとして、考えとして広がっていくのかなと思っています。

そういうことを考えてみるのが大事なんじゃないのかなと。僕自身も初期は考えましたし、そういうのをほとんどの方はできるようになると思うので、コミュニケーションしつつ考えてもらうようにしています。

及川：なるほど。とてもすてきだなと思うんですけれど、なにかもしそれをエンジニアがやれなかったならば……。事業サイドだけで決められると。KPIは勝手に決まり、本当に営業の数字を上げるだけと。極端にネガティブな言い方をしてしまってはいますが、「これを上げるためにこの機能が絶対当たると思うから、あなた作ってください」というかたちになってくる。誰かからゴールを与えられるというかたちになってしまうと思います。

一方で、今仰られたみたいに、本来これを作っているのは何かに貢献できるはずだと。おそらくそれはどこかで結びつくはずなんですよね。なので、そこをぜひエンジニア視点で、エンジニアからも提案して考えて行動してほしいというメッセージかなと思います。