2023年6月14日から15日にかけて、日本CTO協会が主催するカンファレンス「Developer eXperience Day 2023」が開催されました。さまざまなテーマのセッションがおこなわれたなかで、本記事では「スタートアップ・創業期CTOの役割とは？」をテーマにしたセッションの内容をお届けします。

セッションには、キャディ株式会社の小橋 昭文氏、株式会社hokanの横塚 出氏、note株式会社の今 雄一氏、日本CTO協会の藤倉 成太理事が登壇。

スタートアップ企業や創業期にジョインされたCTOやエンジニアの方々による、CTOの具体的な仕事内容や苦労した際のヒントが話しあわれました。キャリアの選択肢として、スタートアップ創業期のCTOについて考えるきっかけになればと思います。

登壇者

（以下、敬称略）

• 関連記事：「社員一人ひとりがやりたいことを実現できる」SES企業を作るには？コクーが描くSESの未来像
• 関連記事：メルカリCTOが語る「グローバル企業、開発者体験のあり方」
• 関連記事：エンジニアの転職理由に迫る！今後も長く働き続けてもらうために必要な3つのコト

経営におけるCTOとは

藤倉：CTOは経営の一角を担う役職ですが、実際にどのような役割を期待されているかは会社ごとに異なりますよね。みなさんは「このようなところを目指したい」「CTOとはどうあるべきだ」と考えながらお仕事をされていますか。

小橋：わたしは、社員が数名のフェーズから始めました。会社が大きくなっていくと、責任の分岐や分業も発生すると思いますが、CTOには常に「会社の成功」が求められます。
その中でテクノロジーという武器を生かすのも大切です。レバレッジが効くフェーズも効かないフェーズもありますが、会社の成功にコミットするのが一番重要だと考えています。

横塚：わたしも取締役3人で会社をスタートしました。3人とも会社の成功を一番に願っていて、そのためならなんでもするという感じでした。最初はわたし自身も「CTOとはなんなのか、なにをすればよいのか」と迷いながら、とりあえず走り続けてきました。
CxOでどの役割を分担して、どのような権限でやっていくか、どうマネジメントメンバーを構成していくかは、先のフェーズに進まれた他社事例をみると勉強になります。創業期はとにかくプロダクトをつくって、最初のお客様にひたすら向き合って、お客様の成功にコミットするのが会社の成長につながると思います。

今：CTOに限らずChief ◯◯ Officerは、「手段を問わず自身の実力やスキルセットをもとに、会社をいい感じにして」とオーダーを受けているものだと思っています。CTOは、とくに技術面からそのオーダーに取り組む仕事です。創業期・グロース期・上場後では異なりますから、状況を見ながらいい感じにする必要もあって、難しいですね。創業期は、プロダクトや性質、CEOのキャラクターにもよると思います。当社はCEOもCXOもクリエイタータイプで、癖は強いですが、センスがよくて、やりたいことがある人たちです。「彼らの思いを結晶化すればよいものができるだろう」と考えて、創業期にはエグゼキューションにかなり特化していました。

藤倉：ボードの人々のキャラクターや、ビジネスをする業界にも関係するとは思いますが、やはり「事業の成功にコミットすること」が重要ですよね。わたしも今さんに近い状況で、いろいろなところからアイデアがあがってくるので、エグゼキューションをいかにうまくやるかに苦心していました。みなさんは、ボードとの関係性はいかがですか。

横塚：わたしもどちらかというと、同じタイプかもしれないです。アイデアをどう実現していくかという、エグゼキューション寄りのタイプですね。

小橋：スタートアップはアイデアややりたいこと、つくりたい世界があって、それに対する仮説を考えながら挑戦しますよね。仮説をつくったり、崩れたりの繰り返しです。さきほど「手段を問わず」という言葉もありましたが、会社の方針を決定していく中では、「手段としてITが適切かどうか」を常に意識しています。もちろん、ビルドトラップのような「つくりたいからつくる」という手法もときに重要ですが、レバレッジをきかせられているかも含めて、自分を自分で否定できるかどうかも、留意しているところです。

藤倉：わたしは創業者でもなければ、創業期から入ったCTOでもなくて、一エンジニアとしてSansanにジョインしました。開発のマネジメントをするようになってからは、常に「あの案件どうなったっけ」「あれはいつ出るんだっけ」と、いろいろな人に期待してもらっていました。われわれが機能をデリバーしないとなにも始まらないので、そういった経験も多かったのですが、みなさんはいかがですか。

今：デリバーのしやすさも大事だと思います。CTOにとっては、最初の技術的な方針を妥当に決めるのも大事なミッションですよね。エンジニアがいない、CEOがテックに詳しくないといったいろいろな変数がある中で、デリバーしやすい方式を選ぶ必要があると考えています。ビルドトラップの話もありましたが、極論「それってShopifyでいいよね」みたいなこともありますから。「本当にゼロイチでプログラミングする必要あるのか」までを踏まえて考えるのが、CTOの仕事だと思います。

藤倉：ときにはモノリシックでいくのも正しい一つの仮説だし、マイクロサービスでいくのも一つの形ですよね。それも含めて、会社にとってのよりよい未来に早く近づくにはどうすべきかを考える。経営チームの中で、自分が一番テクノロジーに詳しくなければならないという自覚もある。その側面で、いろいろな発言をしたり考えたり、ときには説得したりするのが役割ですよね。

小橋：今やITは、すべての組織にとって欠かせない存在になっていますよね。「Google Workspaceをどうやって運用するのか」「社内の権限周りや情報流通をどうするか」など、自社のデータモデリングまでしないといけない場面もあるかと思います。とくにスタートアップはどこも人手不足の状況下で、そういった「データや組織とITの道具をどう合わせていくか」は、テクノロジーの専門性を持ったCTOが考える場面も多いと思います。わたしもずっとやってきたのですが、みなさんはいかがでしょうか。

今：CTOあるあるですね。結構みなさん兼任していて、社内データモデリングもしますよね。

藤倉：スタートアップは人が急激に増えたりして、オフィス移転もよくしますよね。新しいオフィスの ネットワーク設計とかも、あるあるですね。

横塚：わたしもコーポレート本部の担当役員をやっていた時期もあります。請求書周りや社内DXなど。

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

今：コンピテンシーとして、オープンマインドな必要はあると思います。「なんでもやります」ではないですけど。

創業期CTOの役割

藤倉：最初にみなさんがお話しされていた「成功するためならなんでもする」というのがベースにあるかと思います。CTOはテクノロジーのバックグラウンドを持ちながら、なんでもする。

次は、実際にふだんの業務でなにをしているのかお聞かせください。たとえば「これはCTOとしての自分がやっているな」と思われた、最近のお仕事をご紹介いただけますか。

小橋：現在、エンジニア組織が100人規模になり、いろいろなプロジェクトが並行で走り始めています。その中で、「技術スタックをどうするか」「開発者の生産性をどう上げるのか、そもそも上げるフェーズなのか」を考える場面が増えました。言語などもいろいろ試したいけど、統一しなければ運用できない。CTOには、そこで最終的な意思決定をする責任があります。直近の数週間は、社内事情をあらためて把握したり、意思決定の重要性を発信したりといった取り組みを進めているところです。

横塚：最近は、新規サービスの立ち上げに週2日程度使っています。その他に、ボードメンバーと経営に関する方向性のすり合わせ、開発のモニタリングチェック、リーダーとの1on1などもします。

今：ご自身でコードを書いたりはしていますか。

横塚：今年は少し書いていました。あとはお客様を実際に訪問して、フィードバックをいただいたりしています。今さんは書いていますか。

今：あまりよくないかなとは思いつつ、書いていますね。

藤倉：それも人によりますよね。コードを書くことにこだわりやポリシーがあって、書き続けているCTOの方もいらっしゃいます。一方わたしは、CTOを始めたときにすべきことが多く、「こちらのほうがレバレッジをきかせられそう」と感じたことで、コードを書かない仕事に自分を寄せました。明確に決めたわけではないのですが。本番のコードは7、8年は書いていないです。

小橋：負債化したものを運用しているという意味では、少しは書いていますね。よくある「とりあえずなんとかしないと」みたいな瞬発力で、なんとかしちゃったものが負債化している状態です。それらをなくしたり、委譲しなければならないところが残っています。本番の部分は、意図的に避けることが多いです

今：わたしの場合、最初のトライやプロトタイプ作成を任されがちですね。たとえば、「機械学習が流行ってきたからやってみて」「検索システムが遅いから新しいスタックを試して」などですね。最初に実験して、フィージビリティがとれたら現場メンバーに渡したりします。

CTOが考える開発体験

藤倉：今回のカンファレンスは、全体を通じて開発者体験が一つのテーマなので、とくに創業期やスタートアップのころの開発者体験についてもお聞きしたいと思います。
今は、たとえば開発環境やCI/CD、また学習支援などについてもベストプラクティスが出揃っていますよね。あとは会社のフェーズで、「今それは入れるべき」「それはまだ自分たちには合わない」などと考えながら進める場面もあると思います。みなさんは創業期のころの開発者体験について、どのようにお考えですか。

わたしの場合は、エンジニアに対して「よりよい環境を提供したい」と思っていますが、すべてにおいてお金がかかります。だから会社に対して、「どのような利益があるか」をどう説明するか、どの切り口からストーリーにしていくかを意識しています。たとえば、開発環境をすぐに構築できる環境にしようと思ったら、「いま採用を頑張っていて、毎月毎週どんどん人が入ってくる。彼らがボタン一つで環境をつくれたら、素早く仕事に入れる。そのぶんタイムラグが少なくなって、コストのオーバーヘッドを小さくできる。だから経営にとって、この投資は意味がある」と説明すると予算がとりやすかったんです。こうしたストーリーをどうつくるかというコツがつかめるまでは、試行錯誤だった記憶があります。

横塚：CI/CDなどの、当たり前にやらなければいけないことを淡々とやっていましたね。ちょうどこの時期にCTO協会からDX Criteriaが出たので、エンジニアリングマネジャーと「これはこのタイミングでやっていこうか」と合わせつつ、徐々に進めていきました。やはりソフトウェアエンジニアは、アーキテクチャを考えてコードを書くことに100%の時間を使うべきという前提はすりあわせていました。もちろん、お客様とセッションすることも大事かと思いますが。

藤倉：たとえばCI/CDの環境も、もちろん整備できたほうがよい。一方で、エンジニアが少なくて、みんながマニュアルでデプロイできるなら「その環境いるんだっけ」となりますよね。さらに人数が増えると、特定の人しか手動でデプロイできないのは、環境として厳しい。ではほかの人に覚えてもらうかというと、事故につながる恐れがある。それなら環境整備をして、誰でもできるようにしたほうがスケールするので、「最初はなくてもよい」みたいな判断をわたしの場合はしがちです。 「なにをやらない」というのも、一つの判断ではあると思います。

今：わたしもそうでした。noteもリリース前まではHerokuで開発していたので、CI/CDはまったく考えていませんでした。ただ、エンジニアが増えると生産性にもヒットするようになりましたね。なんらかの秩序というかルールを決めないと、体験が悪くなってしまうので、「どのようなルールを敷くか」が重要だと思います。たとえばベタですが、オープンAPIで定義してレビューを通し、自動的にドキュメント生成もできるようにして、認識がぶれないようにしました。最近だとモジュラーモノリスという、モジュラーごとにモノリスを分解していくことも企画しました。こうしたルールメイキングを考えていくのが、生産性にヒットするフェーズかなと思います。これから100人、200人と増えて、組織が分かれたり、さらにフェーズも上がったりするとおそらく別の課題が出てきますよね。

小橋：当社も最初は数人しかいませんでしたし、当時は誰か1人しかできない業務というのはありませんでした。時間のプレッシャーがあると、人も増えて本番運用が始まるまでは「動くものができてから考えよう」となりがちで、わたしも悩みましたね。わたし自身、Web界隈出身じゃなかったのもあって、創業期にはよくわかっていなかったんですよね。その中で正しい意思決定ができないので、とりあえず探索しながら、みんなで学びながら進めていました。今になって考えると、よくも悪くもあとから是正しにいっているというか、標準化に向かって動いている感じです。組織の規模が大きくなると、標準化などのインパクトがより大きくなるというのは、実際に感じているところです。

藤倉：エンジニアには、学習の機会を多く持ってもらいたいし、会社から多少なりとも支援できたほうがいいですよね。さきほどお話ししたように、それを正当化するのも難しいなと感じます。みんなが成長して、知識が豊富になれば、開発がよりよいものになるのは間違いないですが、なかなか証明がしにくい。そこで、わたしはもう「採用競争力です」と言っています。「採用競争力がないと、エンジニアが採れないので」というと、OKしてもらいやすい。ここでどうやって正当化というか、どのような理由をつけて意味のあるものにしていくかに悩むことが多いですね。

今：カルチャーも大事かなと思います。CTOに説明責任はありつつ、説明しきるとなると、どうしても難しいところがありますから。いま振り返ってみると、創業初期から企業のカルチャーとして「最初からここに投資していく」と、根付かせていくべきだったかもしれないと思います。

小橋：最初は、不完全な情報の中で意思決定するのが経営だと思います。データドリブンと言いながら、実際データは3割くらいしかない場面もあって、最後はえいやで決める責任も権限も持っていますから。

藤倉：なりたい姿や理想や仮説があって、「このような世界に近づけるのではないか」と思いながら進めて、結果が違ったら「間違いでした」と勇気を持って引っ込める。それでまた、先に進むというのはありますね。間違いのない、たしかな情報だけで意思決定できることは、まずありえないですからね。

（文：谷口智香）

― presented by paiza