2023/12/25

経営に「技術視点」を。歴代CTO of the Yearが語る、次世代リーダーが果たすべき役割

NewsPicks, Inc. Brand Design Editor
新たなテクノロジーの台頭・進化が著しい昨今、技術的な視点から変化を捉え、経営をリードする「CTO(Chief Technology Officer:最高技術責任者)」の重要性が高まっている。
一方で、他のCxO職と比べても、実際のところCTOに求められていることは何か、具体的には何をしているのか、それを説明できる人はそう多くはないだろう。
エンジニアのキャリアのゴールの1つとさえ思われている、CTOの職能や担う役割とは何か?
2023年11月22日に開催された「Startup CTO of the year 2023 powered by Amazon Web Services」では10周年記念コンテンツとして、歴代Startup CTO of the yearによるスペシャルセッションが実施された。
事業フェーズも個性も異なる歴代CTO of the Yearが集結し、創業期CTOのリアルな苦労や悩みなども語られた本セッション。普段あまり語られることのない「CTOの頭の中」をのぞいてみよう。
※本記事はセッションの内容を再構成しています。実際のセッションの流れや発言とは一部異なる部分があります。
INDEX
  • 三者三様。CTOまでの多様な道のり
  • CTOは「技術に責任を持つ経営者」
  • 心も折れた「PMFの壁」
  • 「自分にしかできない仕事」を突き詰めろ

三者三様。CTOまでの多様な道のり

 今日は、歴代CTO of the Yearが集結した特別セッションということで、それぞれにフェーズも異なるみなさんの視点から、CTOの役割や技術視点の重要性への理解を深める時間にできればと考えています。
 CTOになるまでの道のりを振り返りながら、求められていた役割や苦労話などを聞いていければと。まずみなさんはどのような経緯でCTOになったのですか。
竹内 前職のユーザベースでのCTO経験からお話しすると、当時「CTOに任命された」という明確なタイミングはなかったと思います。
 もともとユーザベースには、業務委託のエンジニアとして2008年の創業時から関わり始めました。
 そして2011年に自分でも経営していた会社を畳み、正式入社するのですが、その際に渡された名刺の肩書きに「チーフテクノロジスト」と書いてあって。そのままいつの間にかCTO的な立場になっていた、というのが実際のところです。
大竹 自分も竹内さんと同じく、自然とCTOになっていったというイメージの方が近いかもしれません。
 そもそもdelyは、大学時代に代表の堀江と僕との共同創業ではじまった会社です。堀江がエンジニアではないので、必然的に僕がプロダクトまわりを一通り全部担当することになり、自然とCTOの役割を担うことになりました。
 そこから一度CTO職を離れ、3年ほど新規事業にコミットした後、今年またCTOに復帰したところです。
小山 私は前職で転職サイト「ビズリーチ」を運営するビジョナルという会社に所属しており、入社後に運よく採用管理システム「HRMOS」の事業立ち上げに携わることができました。
 そこで3年ほど修業して自信がついたタイミングで、スマートラウンドの創業者である砂川に出会いました。彼はビジネス面がすごく得意で、そこに僕が入れば良いチームになるんじゃないかと考え、共同創業に近い形でスマートラウンドに入社しました。
 入社当時はエンジニアとしてリソースの全てをコードを書く時間にあてていたので、そもそも肩書きや役割を特に意識はしていませんでした。そんななか、1年半ほど経ったタイミングで、「CTOをやらないか」と声をかけられ正式にCTO職のポジションにつくことになった次第です。

CTOは「技術に責任を持つ経営者」

 副業や共同創業など、CTOになるまでの道のりも多様であることがわかりますね。
 では次のテーマは「CTOが果たすべき役割」になります。ここ数年CTOというポジションの認知は広がってきた一方で、人によってそのCTO像やイメージは異なる印象です。
 そこでこれまでみなさんはCTOとしてどのような役割を担い、経営をリードしてきたのか伺えればと思いますが、まず竹内さんからいかがでしょうか。
竹内 そうですね。ユーザベース時代に何を求められていたかという視点で話すと、僕に対して得意ではないマネジメントや組織づくりは求められていませんでした。
 逆に求められていた役割を一言でいうと、「会社の未来をつくること」です。
 プロダクトをどのように顧客に届けるのか。新しく技術的な課題が発生したとき、素早く解決できるよう、いかに先回りして手を打っておけるか。
 これら未来をつくるための開発にリソースを集中することが、私の主な役割でした。当時と比較して、CTOと組織論が密接になってきた近年の潮流からすると、自分は少し毛色が違うのかも、と思いながら最近過ごしてはいます。
大竹 僕は基本的に、「CTOは経営者である」というのがまず前提にあります。そのうえで尖っている専門性が「技術領域」にある。この整理が、自分的には一番しっくりくるかなと。
 そもそも一言でCTOといっても、フェーズによってやるべきことは大きく変わりますよね。創業フェーズは当然自分でコードを書いたり、ユーザーインタビューをしたり、プロダクト開発に関わることは全てやらないといけない。
 その後、組織が10人を超えるとマネジメントの必要性が出てきて、採用にも注力しないといけなくなります。
 いまdelyの開発メンバーは60名ほどになりますが、ワンプロダクトから複数事業を運営する会社になったので、事業ごとの人数の最適配分を意思決定するには経営を十分に理解しないと成り立ちません。
 なのでCTOとして企業成長をリードするためにも、常に経営目線を持ち続けながら、自分自身も変化に適応し続ける必要性を日々感じています。
小山 僕も大竹さんの意見に近いのですが、CTOは「技術に責任を持つ経営幹部」という理解をしています。
 やっぱり会社のフェーズや事業、CTO自身の個性によっても役割は全然変わってくるし、そのために必要なスキルセットも全く異なります。
 それこそ採用活動に全力の人もいれば、技術を極めたいと思う人もいる。でも共通しているのは、それが「会社の経営に貢献する」点です。
 人と事業とお金の適切なバランスを考え、リソースを配分するのが経営者の主な仕事だと思いますが、そこに「技術的な視点」をもたらせるのがCTOであるという認識をしています。

心も折れた「PMFの壁」

 特に創業期からCTOとしてご活躍されたきたみなさんにとって、あまり普段理解されない苦労や悩まれたことなどもあったと思います。
 大変だったことやつらかったことは山ほどあると思いますが、ぜひみなさまの苦労からCTOの頭の中を少しでものぞければと思いますがいかがでしょうか。
大竹 やっぱり「PMF(プロダクトマーケットフィット:マーケットに適した商品やサービスを提供できている状態のこと)」までは相当つらかったですね。
 プロダクトをつくり、1ヶ月くらいで「違うな」とピボットすることを何度も繰り返すわけですよ。これ何回やればいいんだろうという感じで、でもどこかでPMFするだろうと歯を食いしばりながら耐えていた日々でした。
 いまはあの時期を乗り越えたことで会社として強くなれたなと客観的に思えますが、当時は本当につらかったですね。
 心が折れたときはなかったんですか?
大竹 心が折れそうなこともありましたよ(笑)。
 ピボットする際にCEOの堀江と意見が分かれることもありましたが、でも毎回そこで対話を通じて整理し、もう一度モチベーションを高めて取り組んでいました。
 最初から戦略的に綺麗に伸ばせればそれに越したことはないですが、実際にはそんな上手くは行かないので、プロセスはなんでもいいからとにかく最終的に伸びるプロダクトをつくるという覚悟が重要だと思います。
 辞めていく人もいる中で、残ってくれているメンバーと夜中まで語り合ったりして。非合理な部分でモチベーションを上げて、何とか耐えていたと思います。
小山 僕も大竹さんと全く同じですね。PMFする前、スマートラウンドも3年ほど無風な時期がありまして。
 最初はエンジニア3人くらいで、とにかく勢いに任せて開発していました。でもリリースしても全然反応がない。
 そうした状況のなかでは、成長意欲やビジョンへの共感もだんだんと薄れてくると思うんです。実際、これまで弊社のエンジニア組織を卒業したメンバーは2名だけになりますが、どちらもPMF前です。
 大竹さんが仰る通り、この時期はもう、人間的なコミュニケーションで何とかモチベーションを高めていくしかないですよね。
大竹 実際delyの場合は、PMFまでの苦しかった時期って、せいぜい1年半くらいなんですよ。いま考えると一瞬に思えるんですが、その当時はその時間が無限に長く感じるものなんですよね。
 竹内さんはいかがですか。
竹内 僕は正直いうと、自分の会社もあったのでプレッシャーがなかったんですよね。もしユーザベースに何かあっても、自分の会社に注力すれば良いと思っていました。でも逆にそれが良かったのかなと。
 2008年頃はまだスタートアップという言葉も一般的じゃないし、優秀なエンジニアも来る時代ではありませんでした。採用が難しかったので、コードの8割は僕が書いていて。僕が辞めたら会社は潰れるだろうな、と思いながらも、それはそれで楽しくやれてたんですよね。
 保険があるからこその余裕、というのは少し特殊かもしれませんが、あまり深く考えすぎずに目の前のことをこなしていく方が、PMFの壁を乗り越えやすいのかもしれないなと、聞いていて思いましたね。

「自分にしかできない仕事」を突き詰めろ

 それでは最後に次世代CTOの方々に向けて、アドバイスやメッセージをお願いできますか。
小山 そうですね。特に創業期はこれまで得た自分の知識や常識を、一度捨て去る必要があることを覚えておいた方が良いかもしれません。
 書籍やブログ、SNSをはじめ、すでに世の中には沢山の情報が用意されています。これらはたしかにとても参考になる一方で、スタートアップは過去の常識が通用しない世界でもあります。
 たとえば僕自身、前職と同じツールを当然のようにスマートラウンドでも導入したのですが、それが使いにくいと大不評でした。そういう細かい点から考え直し、一度身についたものをアンラーニングすることの大切さを実感しました。
竹内 たしかにすでに世の中にある情報を参考にすること自体は大切な一方で、すでにそれは一般化した情報になっていることも認識する必要があると思います。
 そうなるとネット上の情報をただ闇雲に追うことは少し違う気がしていて。経営者として、また技術責任者として、「自分にしかできないことは何か?」を常に考えることが大切だと思います。
 そのうえでわからないことが出てきたら、実際に経験した先輩の失敗談を聞くのがおすすめです。クローズドの場じゃないと、話せないことも沢山あるので。
 すぐにアクセスできる情報よりも、実際に足を運び生で聞いた情報の方が、先人の知恵を活かすうえでは有効なことが多いです。
大竹 僕はこれからのスタートアップは「人を増やしすぎない」という発想も大切だと思います。
 エンジニアはいればいるほど良いと考える人もいますが、そうではないケースもあると思っています。
 開発速度が上がることを期待して人を増やしたものの、コミュニケーションパスが増えて1人あたりの生産性が落ちてしまう、自由度が下がってしまうというデメリットも大きいと思います。
 特に最近はクラウドやAIを最大限活用することで、1人あたりの開発生産性をどんどん高めることができるようになっています。一方で、エンジニアを採用する難易度はどんどん上がる一方です。
 今後を見据えるならば、そのプロダクト開発にどのような人材が何人必要なのか、戦略的に整理して採用計画を立てることが重要になると思います。もちろんそれを見極めるのは簡単ではありませんが、経営者であるCTOがクラシルやAIなどツールの発展も踏まえて適切なエンジニアチームのサイズ・編成を意思決定することが必要になると思います。
 また広く参加者の方に向けてのメッセージとして、ソフトウェアをつくること自体のハードルはどんどん下がっているので、まずは自分の考えるプロダクトをつくってみることからはじめてみる。
 そうしてスタートアップの世界に飛び込む仲間がどんどん増えると個人的にはうれしいです。ここから世界を変えるような次世代CTOの方が生まれる未来を楽しみにしています。