エンジニア組織のトップたちが語る「私がCTOになった理由」

CTOというキャリアを考える

安尾友佑氏（以下、安尾）：よろしくお願いします。モデレーターを務めさせていただくdely株式会社の安尾と申します。モデレーターをやるのは初めてなのでちょっと緊張してますが、大目に見てください。

今日のテーマとして「なぜCTOになることを選んだのか、CTOになってからの気づき、そして今後エンジニアに求められていることは何なのかなど、熱く語っていただきます」ということなので、今日は熱く語っていただきたいなと思います。

最初に簡単に経歴など、どういう流れで今のポジションに就かれたのか、みなさんに自己紹介していただこうと思います。では、南野さんからお願いしてもよろしいでしょうか。

南野充則氏（以下、南野）：みなさんこんにちは。今回会場を提供しているFiNC Technologiesという会社の代表取締役CEOをやっている南野と申します。最近「みなみの」と間違えられたんですけど、実は「なんの」です。

去年代表取締役CEOに就任したのですが、2013年にFiNCに参画して以来CTOをやっています。

経歴としては、大学の研究としてニューラルネットワークを使った太陽光発電の予測の研究をしてまして、東大の松尾研がいる学科に属してました。その時から起業ブームがあり、僕はもともと高校の時から大学で会社をつくろうというのでこっちに来たので、会社を在学中に2社ぐらい作って、会社を経営していたのがもともとでした。

そのなかで、ヘルスケアのサービスをつくりたいなと思ったときに、当時代表取締役CEO・FiNC創業者の溝口と出会いまして、一緒にヘルスケアのサービスをつくろうということでFiNCに参画しました。

今はFiNCだけではなく、日本ディープラーニング協会の理事もしています。これは松尾先生から「ちょっと手伝ってほしい」とお願いをされて、発起から手伝っているようなかたちでございます。今日はよろしくお願いします。

（会場拍手）

安尾：では、続けて芹澤さん、お願いします。

芹澤雅人氏（以下、芹澤）：こんばんは。株式会社SmartHRから来ました芹澤と申します。CTOをやっています。

SmartHRという会社は労務の問題を解決するSaaSソフトウェアを提供しているのですが、4年前にローンチしまして、僕はそのタイミングからエンジニアとして入って開発業務に携わっております。会社自体はサービスローンチ前から存在していたので、南野さんとは違って創業メンバーではありませんが、プロダクトの初期開発メンバーという立ち位置です。

僕が入った当時は社員数が3名だったのですが、今は約180名になっております。組織が大きくになるにつれて、最初はエンジニアチームのビルディングおよびマネジメントをやるような立場としてVPoEになり、2019年からはプロダクトの開発・運用に関わる部署が5個に分かれまして、その全体的な統括をするような立場としてCTOに就任しました。本日はよろしくお願いします。

安尾：ありがとうございます。では、飯田さん、お願いします。

飯田意己氏（以下、飯田）：こんばんは。クラウドワークスの飯田と申します。

私は、4年前の2015年にクラウドワークスに入社して、ずっとソフトウェアエンジニアとしてやってきました。そのあと、スクラムマスターですとかプロダクトオーナーとかエンジニア以外のところもやって、直近は、マネジメントを主な業務としています。僕だけCTOと名乗っていないのですが、今はVPoEとしてのの業務が主で、組織と事業戦略・技術戦略の全体を見ています。

最近の仕事としては経営の中で議論することが増えてきていて、単にコードを書くというよりも、(経営課題をどのように技術の力で解決していくのかという)技術経営をどうやってやっていくかというところにシフトしてきているなと思っています。よろしくお願いします。

（会場拍手）

安尾：ありがとうございます。よろしくお願いします。

CTOになったきっかけ

安尾：最初はこのセッションのテーマである「なぜCTOになることを選んだか？」から聞いていければと思います。

なかなか自分で選んだわけではないかもしれませんが、そういったところについてお話できる方からお願いします。

南野：それでは僕からお話しさせていただきます。もともと僕は、受託会社を自分で経営していたので、いろんな人からサービスを作ってほしいと言われていて、「こうやったら作れますよ」とか「コストはこのくらいかかります」みたいな話をしていました。ただ結局受託だと限界を感じて、もっと自分でサービス作って大きくしていかないとおもしろいことはできないと思ったので、溝口と一緒にFiNCという会社でヘルスケア領域に挑戦していこうと決めました。

溝口はもともとパーソナルトレーナーとして活動をしていましており、2012年4月にFiNCを設立しました。FiNCはヘルスケアアプリを作っているのですが、そのドメインをすごく熟知していて、それに対して僕はプロダクトや技術の面で経営に参画しようと思ったので、CTOになったというのが僕の経緯ですね。

安尾：なるほどです。最初からCTOとしてジョインされたということですね。

南野：そうですね。けっこう役割は明確になっていて、経営陣の中でも技術を深く触って知っている人が僕しかいなかったので、その部分はやりますよという話で参画したのもきっかけだったりします。

安尾：ちなみに、その時は人数はどれぐらいだったんですか？

南野：最初は本当に5人とか6人とかではじめました。

マネジメントのおもしろさ

安尾：ありがとうございます。では、芹澤さんお願いします。

芹澤：先ほど自己紹介でも述べたのですが、組織の成長に合わせてCTOに任命されたので、もともと強い気持ちで目指していたわけではありませんでした。

個人的にはVPoEが割と気に入っていて、エンジニア組織のマネジメントってすごくおもしろいなと思っていたのですが、会社が100人を超えたくらいのタイミングで、社長の宮田から「もっと経営的な視点でプロダクト開発の舵取りをしてほしい」と言われたんですね。

経営的な視点、というワードには正直ピンと来なかったのですが、その頃立ち上がっていた PM やプロダクトデザインといったグループを横串でマネジメントする立場には興味があり、そのための肩書きとしての CTO に興味を持ち、承諾したというのが経緯の詳細です。ちなみに、CTO というポジション自体は、前任者がやめて以来特に代わりは立てておらず、長らく空きの状態でした。

安尾：ありがとうございます。飯田さんはどういったきっかけでしたか？

飯田：そうですね、僕も芹澤さんとだいぶ似てるなと思ったんですが、僕も2年前ぐらいに当時のCTOが辞めて、そのあとCTOに誰を置くかという話があまりされなくて、当時僕がマネージャーをやっていたので、成り行きで部長という肩書きになりました（笑）。そのあとで、もう少し経営のところにも関わっていくということで、今年の5月から執行役員をやっています。

昔のCTOは技術的に尖っているタイプで、あまり経営にがっつり入っていくスタイルではないように見えていました。僕はもともとジェネラリストタイプの人間だったので、前のCTOが得意としていたところとギャップが大きく、現場からの期待値には応えられないと感じたので、CTOとは名乗らずに開発系の経営に携わる人という立ち位置で、実質的には幅広くやっているんですが、そういう経緯でやってきています。

安尾：ありがとうございます。進んでやられた方もいれば、成り行きでやった方もいるということでした。

CTOになるにはどうすればいいか？

芹澤：さきほど「どうやったらCTOになれますか？」という質問がSlidoで見えたんですけど、スタートアップに入ってがんばっていれば、不可抗力的になれる可能性が高いです。

（一同笑）

飯田：それはありますね（笑）。

芹澤：まだ小規模のスタートアップでがんばっていれば、いつかなれるかもしれないです。

安尾：でも、そうは言ってもエンジニアの人って複数人いると思うんですけど、なぜ自分だったと思いますか？

芹澤：自分で言うのもあれですけど、わりとコミュニケーションができるというか。技術だけという感じではなくて、ビジネスサイドのことも理解できたり、あとはソフトスキル……自分で言うと恥ずかしいですね。

（一同笑）

そのあたりを評価していただきまして、VPoEに任命されたという経緯もあります。ソフトスキルはけっこう重要かなと思います。

安尾：なるほど。技術力だけじゃなくて、ビジネススキル、ソフトスキルみたいなところですね。

芹澤：そうですね。CTOって僕も以前は技術がすごく得意な人がなるものだと思っていたんですけど、Web 系 IT 業界のCTOに関して言うと、ソフト面が強い人のほうが多いのかなという印象です。マネジメント能力というか。あとは、ビジネスに理解があるとか、経営をわかっている人が多いなとも思いましたね。そこは価値観がすごく変わりました。

安尾：南野さんは、なにかそれについて思うところはありますか？

南野：VPoEなりCTOで役割分担はすべきだなとは思っていますが、CTOはやはり経営をすごく理解するべきだと思っています。3年かけて何を作っていくのであったり、そのときに技術のどこが一番差別化要因になってくるのかを見極めて、どこに投資するのかを判断する能力はすごく大事だと思いますし、それをリードしないといけないと思うので、CTOは経営をしっかり理解してほしいなとは思いますね。

人生で最も影響を受けた本

安尾：ありがとうございます。ここでガラッと話は変わりますが、「今までの人生で一番影響を受けた本とかって何ですか？」という質問。なにか思い当たりますか？

南野：僕は去年代表になったんですけど、代表になった時にいろんな取締役・社外取締役から「この本を読め」と言われた本があって。『CEO』という本なんですけど。

安尾：CEO？

南野：「CEOに任命されたらあなたはどうしますか？」みたいな本なんですよね。その本に僕はけっこう影響を受けました。

「その役職に就いたら、90日間でどれだけ成果をあげられるかが大事だ」「CEOになれと言われた時からどれだけ準備できるか、そのポジションで活躍できるかが大事だ」ということが書かれている本です。例えばGEの社長が任命されたときはどうだったなど、ケーススタディも書かれているすごくおもしろい本で、今までの人生で影響を受けた本に近いかなと思っています。

安尾：ありがとうございます。スッと出てくるのはすごいですね。芹澤さんはなにかありますか？

芹澤：一番と言われると難しいですが、人生に影響を与えた本ということで言えば、僕はもともと文系で、プログラミングは子供の頃から趣味的にやってたぐらいなんですね。大学も文系の学部に通っていて、就職活動に際しても「商社あたりにしようかな」と思っていたんです。そんな時に『ハッカーと画家』という本に出逢いました。

これは Paul Graham が書いた本なんですけど、それを読んで「プログラミングでこんなに世界を変えられるんだな」と思って。当時ちょうどスマホが流行り始めていたのもあり、IT 業界面白そうだなと興味が出て、今に至るという感じです。この業界に入るきっかけとなった本なので、人生に影響を与えたといえますね。

いまだにたまに読み返すことがあって、20年近く前に書かれたエッセイ集なんですが、驚くことに現代にも通じることが書かれています。ぜひまだ読まれていない方は読んでみてください。

安尾：ありがとうございます。飯田さんはありますか？

飯田：そうですね、ちょっと人生というスケールの回答はぱっと思い浮かばないのですが、今の仕事でいくと、『エンジニアリング組織論への招待』は影響を与えていると思います。

ベタな感じですが、技術的な課題というのはだいたい組織の課題みたいなこともあるかなと思っていて、そこに対してエンジニアリングの考えを持ってどうやってそこに向かっていくのかが体系的にまとまっています。

当時、自分1人で読むんじゃなくて、デザインやプロダクトの執行役員とか、あと副社長も交えて、この本の読書会をやりました。そのおかげで、これからエンジニアリング組織をどうしていくのかという意識が揃えられたというか。

安尾：読書会というのはどんな感じでやられたんですか？

飯田：1章ごとにみんなで読んで、気になったところやいいなと思ったところはどんどん付箋を書いていって、最後にみんなで順番に共有しながら理解を深めていくということをやりました。それを数ヶ月ぐらい続けて知見を積み重ねていく形でやりました。

安尾：おもしろいですね。ありがとうございます。

良いエンジニアの定義

安尾：もう1個いきたいと思います。「よいエンジニアとはどんなエンジニアだとお考えですか？」。けっこう難しい質問なのかなと思うんですけど、どうでしょうか？

南野：エンジニアって楽したい人が多いかなと思っているんですね。なので、サボるのうまいエンジニアが僕はいいエンジニアかなと思っています。サボるといっても働かないで寝るとかじゃなくて、「できるだけ楽に開発をして、できるだけ楽に成果をあげる」みたいなことを考えられるエンジニアが僕はすごくいいエンジニアだと思います。

エンジニアはやっぱりユーザーの理解もしないといけないですし、ビジネスの理解もしなきゃいけなくて、そのなかでROIと工数を見て一番最適な手法を提案してやってしまうエンジニアが最高だなと僕は思ってます。

安尾：パッと言える範囲でいいんですけど、具体的にどういった事例がおありか、ご自身の経験の中であったりしますか？

南野：FiNCアプリの例で言うと、睡眠の予測アルゴリズムが作っている人たちがいるんですが、睡眠の予測のアルゴリズムというのは、最初はスピードが重いので、送れる人も限られていたんですよね。

その時に、違うチームのエンジニアが出てきて「すぐ直しますよ」とか言ってサクッと直してくれたんです。それって楽をしていて、ROIいいじゃないですか。インパクトがすごく大きいみたいな事例がありましたね。

安尾：すごいですね。ありがとうございます。芹澤さんはいかがでしょうか？

芹澤：僕も同じような考え方です。弊社において優秀、というか重宝されるタイプのエンジニアは、顧客の課題にフォーカスした行動ができる人です。最終的なゴールはお客さんの課題や社会の課題を解決することなので、あくまでその選択肢の1つとして技術と向き合っていける人は強いですね。

お客さんの課題を直に聞いてしまうと、なんとかして技術で解決しようと思うじゃないですか。そうじゃなくて、「実は技術に関係ない部分の仕組みをちょっと変えるだけで解決するんじゃないか」とか。「プログラミングが必要になるときもあるし、必要じゃないときもある」みたいな考え方です。課題を解決するための手札を、プログラミングを含めて多く持っている人が強いですね。

安尾：ありがとうございます。飯田さん、いかがでしょうか？

飯田：同じような感じですが、違う観点で言うとすると、自分で考えて「自分はこういうことを調べて、こういう理由に基づいてここはこう実装すべきだ」みたいな考えを表明できる人は強いなと思います。

そうやって不安だったりわからないことに対して誰か強い人に「どうしたらいいですかね？」って聞きたくなることもあると思いますが、それで答えを求めてしまうと自分で考える力が成長しません。

それが十分なアイデアじゃなかったとしても、なにかしらできる範囲で、その当時その時点でできる範囲で考えを表明して、周りを巻き込んで前に進んでいくスタイルで仕事ができる人はいいエンジニアかなと思います。