キャディ、hokan、note、Sansan。4社が語る、0→1フェーズのCTOに求められる役割とは【Developer eXperience Day 2023#3】

技術的な方針の決定からエンジニアの採用まで、多岐にわたる業務を担うCTO。特に創業期では、どんな役割を期待されて事業のために何ができるのか、悩むことも多い。

この記事では、事業ドメインはもちろん、歩んできたキャリアも強みも異なる、日本を代表する4社のCTOのパネルディスカッションをご紹介。創業期にCTOとして挑んできた課題、抱えている悩み、そして開発者体験について考えていることを届ける。

• keyboard_arrow_down 0→1フェーズのCTOは、オープンマインドな「テクノロジーのよろず屋」
• keyboard_arrow_down コードは書く？書かない？行き先不明瞭のなかで率先して創る役割を果たす
• keyboard_arrow_down 開発生産性の向上にCTOが求められること
• keyboard_arrow_down さいごに
• keyboard_arrow_down 特別Q＆A

藤倉：経営の一角を担う役職でもあるCTOですが、実際に求められる役割は会社によって違うと思います。そのなかで、皆さんは創業期から携わってきたCTOとして、初期は何を意識していましたか？

小橋：キャディの場合は、自分とCEOの加藤（勇志郎 氏）でスタートした会社なので、CTOといっても、単なるラベルに過ぎなかったです。ボードメンバーの一人として、テクノロジーという武器をどう活かして、会社の成功にコミットするべきかを一番考えていました。

横塚：hokanも最初は僕を含めて3人でしたので、正直CTOとは何なのか、何をやればいいのか、迷いながらも走ってきました。変にCTOの役割を意識せずに、とにかくお客様の成功にコミットしたことが、何よりも企業の成長につながったと思います。

今：基本的に、CxOという役職は「手段は問わないから、自分の実力やスキルセットで会社をいい感じにして」というオーダーをもらっているものだと考えています。CTOというのは、このオーダーを技術面で実現していく役職だと捉えていますね。

特にスタートアップや創業期の企業だと、CTOの役割はプロダクトの性質や、CEOのキャラクターに大きく左右されると思います。noteの場合、創業メンバーはすでにやりたいことのアイディアを明確に持っていたので、自分はそのアイディアを結晶して、プロダクトに落とす役割を担っていました。

小橋：スタートアップは常につくりたい世の中に対して、自分の中で仮説を立てながらそのビジョンに挑んでいるものだと思います。最近だと、その仮説検証の手段としてデクノロジーが挙げられがちです。ただ、自分はCTOとして本当にテクノロジーが最適なのかも、常に考えるようにしています。

創業期において、「つくりたいからとりあえずつくってみる」という開発者の勢いも大事ですが、企業全体を見る者として、レバレッジを利かせられているかも含め、自分を自分で否定できるかも重要だと感じますね。

今：最初の技術方針を適切に決めるのは、CTOの大事なミッションですね。初期に開発者がいなかったり、CEOがテックに詳しくなかったりなど変数が多い中で、企業にとってデリバーのしやすい手段を選ぶのは大事だと思います。極端にいうと、「ゼロイチでプロダクトをつくる必要があるか」という、根本的なところから考えるのが、まさにCTOの仕事かなと。

藤倉：CTOは経営チームにおいて、テクノロジーという手段にもっとも詳しい人でいなければいけないですね。

小橋：それゆえに、特に創業期という人材不足のなか、社内の情報流通や権限周りをどうやって構築するか、いわゆるCIO（最高情報責任者）の役割もCTOが兼任する場合が多いですね。

今：これはCTOあるあるのひとつだと思いますね。

藤倉：スタートアップだと人が増えてオフィスを移転することもありますが、その時に新オフィスのネットワーク設計に対応したりとか。

横塚：これもよくありますね。僕もWi-Fi機器をどうするかから始め、ハードウェアの整備周りを担当した結果、一時期コーポレート本部の担当役員にもなりました。

藤倉：社内の業務をいかに効率化するか、そのために今使える外部からのテクノロジーを どう調達してこられるかも求められています。

今：コンピテンシーでいうと、CTOはオープンマインドな性格が必須かもしれませんね。

藤倉：最初に皆さんが話されていた「企業の成功のためにあらゆる手段を使ってコミットする」という思いがベースにあるから、知らない領域にでもすぐ飛び込めると思いますね。

藤倉：最近CTOとして皆さんが一番注力していることはなんですか？

小橋：キャディは現在エンジニアが100人近く所属しているので、同時並行で動くプロジェクトが複数ある中で、開発者の生産性をどう上げるべきかについて考えています。組織改善の意思決定をするために、エンジニア組織の全体像を改めて把握するところから始めました。

横塚：私の場合、今の時期は新規サービスの立ち上げに週2日くらい費やしています。そのほかの時間は、ボードメンバー間で経営方針のすり合わせを行ったり、ソフトウェア開発のチームに対して週1回のペースで生産性のモニタリングチェックを行ったりしています。

あと、新規サービスの立ち上げに関わっているので、最近は結構プログラムを書いています。皆さんは今でもプログラムを書いていますか？

藤倉：私の場合は、マネジメントを始めたあたりでコードを書かない仕事に自分を寄せました。本番のコードはこの7、8年書いていないと思います。

小橋：自分も意図的に本番環境では書かないようにはしています。なぜかというと、書いたあとの運用を自分ひとりではなくチームで実施していく上で、やりやすさを大事にしているからです。

今：私はよく書いていますね。「機械学習が流行ってきたからちょっとやってよ」とか、「検索システム遅いから新しいスタック試してよ」といった形で、最初のプロトタイプをつくることを任されることが多いんです。テストして、実際プロダクトにできると判断したら現場に渡すという、初期探索の役割を担っていますね。

藤倉： 人的リソースや投資が明確に読めなかったり、投資に足りうるプロジェクトなのか判断がつかなかったりする場合は、とにかく手を動かしてプロトタイプを出してみるのはありますね。

今：経営層のやりたいことの抽象度が高すぎると、なかなか現場のメンバーに任せづらいところがあります。「この技術、いい感じかどうか試してみて」とは言えないので、その場合はまず自分でつくってみますね。

藤倉：開発ツールや学習支援などさまざまな面でベストプラクティスが出てきているなか、皆さんはスタートアップのCTOとして、開発者体験の向上にどういうふうに取り組んできたのでしょうか？

横塚：CI/CDのような「当たり前のことを淡々とやる」ところからですかね。最近だと、CTO協会から発表された「DX Criteria」に照らし合わせて、どのタイミングで何を実行すればいいのかを、エンジニアリングマネージャーとすり合わせています。

会社のフェーズが変わると、これまで開発にだけ集中してきたエンジニアが、クライアントとのコミュニケーションの時間を確保したりと、開発以外のタスクに時間を割かなくてはならなくなります。なので、例えばエンジニアが「1日の半分しかコードを書けない」となった場合に、どうしたら定量的に改善できるかもマネージャーと測ったりしていますね。

今：正直にいうと、プロダクトのリリース初期は、あまり開発者体験について考えていませんでした。ただ、関わるエンジニアが増えるにつれて、どう生産性を向上すればよいか考えるようになりました。そこで、開発者組織全体で何らかのルールをつくっておかないと、継続的な体験の向上は図れないと気づいたんです。

私の場合、APIはすべてOpenAPIで定義したうえで、チーム全体で共通認識が取れるようなルールをいくつか策定しました。コードレビューのフローを整えたり、ドキュメントを自動生成できるようにしたりといったルールメイキングは、開発生産性の向上に役立ちましたね。

小橋：私もまさにいま、組織がスケールするにつれて標準化のインパクトが大きくなってくることを実感しています。

自分はもともとWeb界隈出身ではないため、創業期はとりあえずまわりを見て模索しながらやっていました。時間のプレッシャーもあって、「動くものができてから考える」という状況に陥ることも多かったんですね。なので、振り返ってみれば、創業期は何も意識していなかったかもしれません。そしていまは後から是正する形で、ずっと標準化に取り組んでいます。

藤倉：あと開発者体験というと、エンジニアの学習環境をいかにして整えるのも大きな課題ですね。特に創業期だと、リソースが潤沢でないなか、会社に支援してもらうのも難しいですよね。採用競争力を理由にOKしてもらったりするのですが、なかなか投資の効果を証明しにくい部分なので悩むことも多いです。

横塚：学習機会についてCTOが合理的に説明する責任はありつつ、こういう所に投資するべきというビジョンは、創業期から経営層に根付かせていくべきだと思います。初期からカルチャーをつくることは大事ですよね。

小橋：結局、不確定要素がある中でも、意思決定するのが経営だと思います。いざというときに意思決定してもらえるために、エンジニア組織として、採用ブランディングも含め「我々はこうありたい」という部分をしっかり主張するべきだと思います。

藤倉：最後に皆さんから、創業期のCTOとして働くことに関心を持っているエンジニアに、キャリアをつくる上でのアドバイスをいただきたいと思います。

横塚：エンジニア時代は、CTOという肩書に漠然とした憧れを持っていました。ただ、実際になってみると、CTOとしてなにをするべきなのか、初期は深く悩む時期もありました。そうなったときにはCTOの諸先輩方に話を聞いてもらいました。いかにして自分の長所を伸ばし短所を埋めていくべきかに向き合っていくことも大事だと思います。

今：創業期のCTOとはいえ、自分自身ですべてやろうとは思わない方がいいですね。自分の得意不得意を把握して、2～3年後には他の経営メンバーに移譲する事を考えながら仕事をするべきです。自分がそこで苦しんだというのもありますが、全体最適を考えるとチームでプロダクトや組織をつくっていくことがおすすめです。

小橋：私はまだ創業から5年過ぎたところなのですが、ここまで振り返ってみると、本当に周りにいる仲間は自分とは違ったスキルを持った人ばかりです。それで助けられた場面が多いと感じますし、最初はそういう仲間をそろえてカバーできる範囲を拡げていくことが大切だと思います。創業期は何でもやる覚悟を持って、つくりたい世界をつくることにコミットするのが非常に重要なので、これから創業される方はぜひチャレンジしてください！

対談セッション後、レバテックLABから4社のCTOの皆さんに特別取材を実施。CTOとして最近課題に思っていることや、CTOの役割のひとつでもある組織の情報発信に対する考え方について伺いました。

——最近の組織や事業において、皆さんがCTOとして悩んでいることは何でしょうか？

小橋：まずは言語を跨いで開発組織をつくるところですね。当社は現在2か国に開発拠点があり、かつ事業部も2つあるので、情報流通なども含めどうやってひとつの組織として成立させるかという設計に苦労しています。最近は組織間の意思疎通のために、ひたすら同時通訳をやっているので、冗談で「Chief Translation Officer」のCTOだと自称するぐらいです（笑）

あとはセッションでも言及した通り、開発組織の生産性向上を技術という軸で取り組むこと。組織のスケールに伴い、技術の標準化にも少しずつ着手していきたい。これまでにはなかったチャレンジですね。

横塚：私の場合は技術的負債に直面する時期に入ったと感じていますね。そのため、新しいプロダクト開発と並行で、粛々とテコ入れをするという方針に舵を切っていければと思って、いま模索中です。エンジニア採用の面においても、福利厚生なども含めた条件面など、ブランディングや総合力で会社として採用競争に打ち勝っていかなければならないというところにも日々頭を悩ませています。

あとは、組織拡大に伴って、今まで在籍したエンジニアが築いたカルチャーを次のエンジニアにどう浸透させていくか、良くない文化があればそれをどう壊すかというところは常に考えていますね。

今：NetflixやYouTubeのように、ユーザーの皆さんがnoteを毎日訪れたくなる、何時間も滞在したくなるような体験をどうつくっていくかがいまの課題ですね。そのために、チームを横断してデータ運用ができる体制を構築していく必要があり、難易度が高いと感じています。そこに大きく貢献できるのが機械学習なので、それを活かせる組織をどうつくっていくかが今後の大きなテーマですね。

藤倉：Sansanはこれまで、名刺特化型のOCRエンジンであれば、誰にも負けない自信があるチームをつくってきました。しかしいまは、もっと広い意味での技術力を用いて他の追随を許さないものをつくって行くフェーズに入ったと思います。

名だたるビッグテック企業がある中で、技術をプロダクトに転換し事業のグロースに結び付け、まだ誰も見たことがない景色を見に行かなければならないですね。

——今日のようなイベント登壇も含め、組織の情報発信の重要性をどう捉えていますか？

小橋： CTOとしては「採用」という文脈が強くなりがちなのですが、自分たちがどうありたいか、あるいはどうあるのかが発信できていれば、発信の量はそこまで関係ないと思います。

今後一緒に仕事をしてくれる方の求める人生やキャリアに我々の事業が重なっているかどうかは面接でも見極めますが、先方にもこちらの方向を認識いただいたうえでお話しするのが理想的かなと。

横塚：無理しすぎずにやることも大切ですよね。タイミングによっては一時的に露出が増えることもありますが、俯瞰で見ると継続的に取り組んでいくことは大事です。多少のムラはありますが、ずっとやり続けなければならないことなので「ちょっとずつやっていこう」くらいの気持ちでいます。

今：noteでは、組織での取り組みを積極的に情報発信していこうという雰囲気がすでに社内にあるので、エンジニアチームで技術ディベートや勉強会をしていると、「これ、記事にできませんか！」とオウンドメディアのチームから聞かれたりもします。

「これ誰が見るんだろう」と一見思うような記事でも、蓋を開けたら意外とじわじわ広がっているんですね。勉強会やカンファレンスなどで「あの記事見ました」「もっと詳しく教えてください」と言われると、エンジニアにとって情報発信を続けるモチベーションになります。とりあえず世に出してみて、1年後に反応がくるくらいのノリで、気長に構えてみてもいいんじゃないかと思っています。

藤倉：テックブログに関して、Sansanではテックブランディングチームをつくって支援しています。ちょっと書いてみたいものの、何をどう書いていいか分からないというエンジニアも結構いますので、テーマのすり合わせから、初稿の壁打ち、広報チェックまで伴走する形になります。1～2回記事を書くことでペースがつかめて、少し自信がついたというメンバーもいますね。

一方で個人的には、情報発信には各人得手不得手があり、それを見極めたうえで、自分に合った、長く続けられる発信方法を選んだほうがいいと思いますね。私自身は執筆への興味が湧かないので、あまりブログは書いていませんが、何を考えているかを話すことはできるので、よくインタビューに出させていただいている感じですね。

文・中島佑馬