- 多くのCTOは管理中心へ移行するが、なおも 自らコードを書いて製品を開発する スタイルを維持している
- 実験的なプロジェクト、緊急の顧客要望、バグ修正という 3種類の開発業務 を通じて、組織内で高いレバレッジを生み出す
- コーディングを続けることで AIツールの実際の有用性と限界 を自ら体感し、技術的意思決定の現実性を確保する
- 管理よりも 問題解決と製品構築に強みと情熱 を置き、それを可能にする組織構造を設計する
- CTOの役割に定型的な型はなく、それぞれの強みと会社の状況に合ったリーダーシップの形 を見つけることが重要
CTOとしてコードを書き続ける理由
- 多くのCTOは時間が経つにつれてコーディングをやめるが、なおも 自ら機能を開発してデプロイする やり方を維持している
- 過去12か月のあいだ、直属のチームメンバーなしで複数の主要機能をリリース
- 単なる趣味ではなく、実際の製品に反映される 中核機能の開発者 としての役割を担っている
- これを「技術リーダーとして最も レバレッジの高い活動 の1つ」と位置づけている
実際に作っている3種類のプロジェクト
1. 長期実験型プロジェクト (Long-horizon experimental projects)
- 組織内で 新しい製品を実際に構築できる人材は非常に限られている
- ほとんどの組織は既存製品の維持と拡張に集中しているため
- 創業者、一部の役員、高い成果を出す個人貢献者（IC）だけが新製品を試す余地を持つ
- 組織構造、ロードマップ上のインセンティブ、限られたリスク予算のため、多くのエンジニアは数か月にわたる不確実なプロジェクトを進められない
- CTOは 顧客のpain pointとアーキテクチャへの深い理解 をもとに、不確実な実験プロジェクトを素早く前に進められる独自の立場 にある
- 失敗例もあったが、大きな成功もあった
- AIチャット製品の例: チームは価値を認めていたものの、時間と余力がなく先送りされていたプロジェクトを、感謝祭休暇の期間にプロトタイプ化
- その後チームと協力し、数百万ドルのARRを生む製品として商用化 に成功
2. 緊急の顧客要望への対応 (Critical customer asks)
- 重要顧客が緊急に必要とする機能が、大口契約や更新の障害 になる状況が発生する
- 現在のスプリントを進めているエンジニアを投入する代わりに、CTOが 素早い意思決定とシステム全体への理解 をもとに直接対応する
- 実例: 年間100万ドル規模の顧客のコンプライアンス対応のための データ削減機能の要望
- チームの初期検討では、顧客が自分でAPI統合を構築するか、製品・法務・エンジニアリング間で複数回の会議が必要だと見込まれていた
- CTOが1日で動くバージョンを構築・デプロイし、顧客関係を維持
3. バグ修正 (Bugfixes)
- 多くの人は驚くが、バグ修正はコードベースのメンタルマップを維持するためのお気に入りの方法の1つ でもある
- 検索結果の3ページ目でページネーションが壊れる理由や、WebSocket接続がちょうど60秒後に切れる理由を追うとき、システム全体を巡ることになる
- コードレビューやアーキテクチャ議論だけでは得にくい 技術的負債への直感的な理解 を得られる
- こうした経験によって、技術投資の方向性と優先順位の決定 に必要な直感を保てる
コーディングを続ける理由
1. 実際に動く技術を把握するため
- Claude Code、Codex、Cursor などの AIツールを毎日使う 経験により、ツールや採用に関する戦略的判断の際に、現実と誇張を見分けられる
- 最近の例: 複雑な統合に触れる機能を vibe-coding で試したが進展せず、自分で手を動かして書いたほうがはるかに早かった
- コード量は多くなかったが、正確なロジックが必要だった（LLMが苦手な領域）
- 一方で別の大きな機能は Claude Code でほぼ全体を開発した
- AIが優れる領域（CRUD、テスト、ボイラープレート）と失敗する領域（精密さ、システムのニュアンス） を把握することは、X上の誇張に基づく意思決定より優れている
- コードの内側にいれば、いつ圧力をかけ、いつ緩めるべきかを感じ取れる
- アーキテクチャが過度に複雑になっている時点や、技術的負債が本当に問題になる時点を察知できる
- レポートのみに依存する管理者は、多くを見落としかねない
2. 自分が得意で楽しめる仕事に集中するため
- 組織づくりや人事管理を特別に楽しんでいるわけではない
- エンジニアリングマネジメントには、人間関係の力学、評価、組織設計が必要になる
- 重要な機能ではあるが、自分の強みがある領域ではない
- だからこそ 優れたエンジニアリングマネージャーやリーダーを採用する
- 彼らのほうがそれを得意とし、楽しんでいる
- CTOは 製品開発、技術的な問題解決、コーディング に集中できる
- スタートアップは「短距離走の連続でできたマラソン」のようなもので、関心を保ち、長く速く走り続けられる仕事 を中心に役割を設計する
- それが長年続けられるやり方であり、会社にとっても非常に重要
3. AIツールがレバレッジを拡張したから
- 数年前までは、戦略的業務をこなしながらコーディング時間を確保するのは難しかった
- 会社の成長に伴い、1日中会議に縛られ、自分の強みの外側で仕事をしていた
- キャリアの中でも特に苦しい時期の1つだった
- 現代のAIツールがこの方程式を根本から変えた（特にここ数か月で）
- 生産性は以前の2〜3倍に向上
- これらのツールは判断力や技術知識を置き換えるのではなく、むしろそれらの価値を高める
- AIツールに「既存のCSVエクスポート形式に合わせつつ、ユーザープロファイルテーブルから追加の3つのフィールドを含むデータエクスポートを作って」と指示すると、たいていコードの大半を正しく生成してくれる
- 何が必要で、どこを見ればよいかを正確に知っている 深いコンテキスト を持っている
- そのコードベース部分に不慣れなエンジニアなら、細部を把握するのにかなり時間がかかる
- 仕事は「すべてのコード行を書くこと」から 「コンテキストを与え、意思決定し、解決策を評価すること」 へと移っている
自分に合ったやり方を見つける
- CTOの役割を考えるうえで、Greg BrockmanのStripeにおけるCTOの役割定義に関するブログ記事 を参考にした
- 複数のCTOと話す中で、役割のあり方には非常に大きな幅がある と認識した
- 技術ビジョナリー型のCTOもいれば、組織ビルダー型、インフラ中心型のCTOもいる
- 共通しているのは、優れたCTOは 自分固有のスキル、関心、会社の状況 を踏まえ、最も大きな価値を生み出せる領域を見極めているということ
- 筆者の場合、それは多くのコードを書くことを意味する
- 組織設計より ソフトウェアを作ることのほうが好き
- 顧客とコードベースへの深い知識 によって、特に高い効果を発揮できる
- 強力なエンジニアリングマネージャーを採用している
- ただし、これは 個人的な道筋であって処方箋ではない
- CTOという役割は非常に柔軟だ
- 組織づくり、製品戦略の策定など、技術リーダーシップは 強み、エネルギーの源泉、会社の必要性に応じて多様 である
- リーダーシップが技術業務を手放すことを意味するのではと不安に感じるエンジニアに向けて: 道は数多く存在する
- 大切なのは、自分が独自に優れている領域 を見極めること
5件のコメント
現職のCTOですが、この文章にはまったく同意しません。
コーディングから離れてはいけないという点には100%共感しますが、会社のプロダクトと関係のないオープンソースをやれば済む話です。初期スタートアップの技術系ファウンダーとしてオールラウンダーに働かなければならない、という観点でのみ有効な話だと思います。
本人はいいだろうけど…
でも会社は？
もらっている給料に見合う仕事をしないと…
実験的なプロジェクトをCTOが直接やるのは不思議ですね。実務担当者たちに十分な時間を与えれば、うまくやり遂げられるはずなのに、という感じです。いちばん不思議なのは、長期の実験的プロジェクトをCTOだけが進めなければならないという点です。自分にリソースを使う権限があるなら、実験的プロジェクトのためのリソースを別途確保して、実務担当者たちに十分な時間を与えれば済む話なのに、と思います。
個人的な道のり……。組織管理の比重が増えすぎないように、うまくマネジメントしていかなければならないのですが……。
Hacker Newsの意見
どの会社に応募するか検討しているときに、CTOが毎週末コードをコミットしていると自慢するブログ記事を見たら、私は逃げる準備をすると思う
リーダーの役割は健全な組織文化を作ることなのに、週末勤務を誇るのはその真逆だ
しかも、法務やエンジニアリングレビューを省略して顧客の問題を1日で解決したと公に語るのは危険なサインだ
初期スタートアップでは文化がまったく異なり、こうした記事はむしろ適切な人材をふるいにかけるフィルターとして機能する
私が書くコードの大半は社内向けのDevEx改善や技術的負債の整理のためだ
法的レビューを省略することはなく、プロダクションコードというよりPoCレベルに限って扱っている
創業者CTOはコードに近い位置にいることが重要だが、バランスを失わないことが鍵だ
CTOの役割は会社ごとに異なる
Greg BrockmanのStripeの事例のように、技術ビジョナリー型のCTOもいれば、組織設計者型のCTOもおり、またインフラ中心のCTOもいる
私の場合はコーディングを楽しみ、顧客とコードベースに深く関わっているので、それが最も大きな価値を生む方法だ
「CTO」という肩書きは定義が曖昧だ
あるCTOは創業者出身で自由にコーディングし、別のCTOは顧客中心で働くうちにコードへのアクセス権を失う
一方で独断的なCTOも存在する
結局のところ、どのタイプのCTOなのかを明確にして初めて、「なぜコーディングするのか」という問いに意味が生まれる
この場合、CTOという名称は単なる役割の区分にすぎない
CTOは戦略と方向性に集中し、VPは日常的なエンジニアリング管理に集中する
その方法が組織づくりであれ、自らコーディングすることであれ問題ではない
管理職が直接コードを書くと、コードレビューが歪み、チームが混乱することがある
結局その人はCTOというより、気持ちはまだ開発者なのかもしれない
CTOがコーディングすること自体に全面的に反対ではないが、このケースではCTOとしての役割遂行が不足しているように見える
実質的な技術リーダーシップは創業エンジニアが担っているのに、報酬ははるかに少ないという構造が問題だ
指揮命令系統がなく、コーディングばかりしているCTOは、戦略よりもシニア開発者の役割に近いと思う
私もそういう提案を受けたことがあるが、結局は形式的なタイトルにすぎなかった
組織が大きくなれば役割は変わると思う
小さなスタートアップではチームと一緒にスプリントを進め、スケジュールが遅れれば原因を解決し、燃え尽きている人を気にかけるのが私の仕事だ
しかし記事を見る限り、チームが話題のAIプロジェクトすら試す余裕がない構造なら、それは組織の問題だ
CTOが自分でコーディングするのではなく、こうしたシステム上のボトルネックを解決すべきだ
会社ごとに「シニア」や「ヘッド」の役割はまったく異なる
CTOがコーディングに過度に没頭したときに生じる問題は明確だ
PRレビューの歪み、本来業務の疎かさ、役割の混乱、チームの自律性の侵害などだ
「CTOはコーディングせず戦略だけやるべきだ」という考え方は機械的な発想だ
テック企業の本質は価値の提供であり、ときにはCTOが自ら大きな機能を1日で実装することが最も価値ある仕事になりうる
KPI会議よりはるかに生産的な1日かもしれない
ときにはCレベルが自ら現場感覚を取り戻すことも必要だ
CTOになった理由が、単に共同創業者だったからという人もいるかもしれない
このアプローチで他社に入った場合、スタッフエンジニアの水準にも届かない可能性がある
最後に、会社のWebサイトの価格ページに実際の価格が載っていない点は混乱を招く可能性があるので、修正が必要だ