CTOとしてなぜコードを書くのか

2025年10月25日原文(assembled.com)

概要

多くのCTOがコードから離れている中、私は今も積極的にコードを書き続けている現状。
CTOがコードを書くことで得られる独自の価値と役割分担の重要性。
AIツールの進化により、戦略業務とコーディングの両立が可能になった変化。
CTOの役割は会社や個人の強みによって柔軟に設計できるという提案。
技術リーダーとして自分に最適な働き方を見つけることの大切さ。

CTOでありながらコードを書く理由

多くのCTO は管理業務や会議に追われ、 コードを書く時間が減少 する傾向。
私は 直属の部下を持たず、 実際に多くのコードを出荷 するスタイルを継続。
「空き時間の趣味」 ではなく、 「四半期ごとに大きな機能をリリース」 する実践。
技術リーダーとして 最もレバレッジの高い活動 と実感。

CTOが手がけるコーディングの種類

長期的な実験的プロジェクト の推進
- 組織内で新規プロダクトを生み出せる人材はごく少数。
- 新しいアイデアの実現 には、 顧客課題とアーキテクチャの理解 が不可欠。
- 例：AIチャットプロダクトのプロトタイプを短期間で構築し、収益化に成功。
緊急性の高い顧客要望 への即応
- 重要顧客の要望がビジネス上の大きな分岐点となる場合に 迅速な対応 が必要。
- 既存のエンジニアを割くより 自らが全体像を把握し素早く実装。
- 例：法令遵守のための機能を1日で実装し、顧客満足と契約維持に貢献。
バグ修正によるコードベースの把握
- バグ修正は システム全体の構造把握 に役立つ重要な手段。
- 実際に手を動かすことで 技術的負債や改善ポイント を直感的に把握。

コードを書く理由

現場感覚の維持
- Claude CodeやCodexなどの AIツールを日常的に活用 し、 実際に役立つ技術 を見極め。
- AIの強みと弱みを体感し、 戦略的なツール選定や採用判断 に活かす。
- コードに触れることで アーキテクチャの複雑化や技術的負債 を肌で感じ、的確な判断が可能。
自分の強みと情熱を活かす
- 組織構築や人事管理よりも ソフトウェア開発や技術課題の解決 に情熱と強み。
- 優秀なエンジニアリングマネージャーを採用し、 自分は開発に集中。
AIツールによる生産性向上
- AIツールの進化で 戦略業務とコーディングの両立 が可能に。
- AIを使いこなすにはドメイン知識や判断力 が不可欠で、むしろこれらのスキルがさらに重要に。
役割の柔軟性と自分らしい働き方
- Greg Brockman（Stripe CTO）のブログを参考に、 CTOの役割設計には多様性 があると認識。
- 技術ビジョン、組織構築、インフラ重視など、会社や自分の強みに応じて最適化。
- 自分の文脈では「たくさんコードを書くCTO」 が最適解。

CTOの役割設計とキャリアのヒント

技術リーダーが必ずしも管理業務に専念する必要はない という事実。
自分の強み・情熱・会社の状況 に応じて役割をカスタマイズする柔軟性。
AI時代のCTOは「コードを書く技術リーダー」も十分に成立 するという提案。
エンジニアのキャリアパス として「技術を極めるリーダー像」も選択肢。

採用案内・謝辞

AI活用型カスタマーサポートツールの開発 を推進中、 手を動かす技術者を募集中。
Calvin French-Owen、Dan Robinson、Dave Story、Cai Wangwiltに議論のサポート、Whitney Beyerにドラフトレビューの謝辞。

Hackerたちの意見

こういう記事はちょっと難しいよね。「CTO」ってタイトルには明確な意味がないからさ。うちの「CTO」は、会社の中で誰よりもコードを書いてると思うけど、それは彼が創業者から引き継いだCTOの肩書きを持ってるからで、実際には「好きなことを何でもやっていい」ってことなんだよね。私たちはそれに満足してるし、彼のやりたいことはほとんどいつも素晴らしいから。これがCTOの一つの定義だね。もう一つのCTOのタイプは逆の意味で、「顧客向けの仕事をしすぎて、エンジニアリングの権限を奪われた創業者」って感じかな。これが他のタイプよりも一般的なアーキタイプだと思う。さらに、毒性のあるCTOの定義もあって、「エンジニアリングの最終決定権者」とか、「エンジニアリング全体のエグゼクティブマネージャー」とかね。自分がどんなCTOなのかを具体的にしないと、なぜコードを書くのかっていう問いが面白くならないと思う。

└

記事は面白かったよ、CTOの定義が幅広い中でね。CTOの一般的な定義について、どうやってやるかではなく、やるべき仕事の観点から合意できるのか気になるな。例えば、CTOの仕事は会社が技術的に競争力を保つことだと言えるかもしれない。それを組織を作ることで実現するならそれでいいし、自分でコードを書くことで実現するならそれもありだよね。

└

創業者が持てるタイトルで「創業者」よりも重要なのは「CEO」だけだよ。彼は自分をCTOと呼んでるけど、それはいいとして、実際には彼は技術的な共同創業者で、そう振る舞ってる（そして、それは会社にとって非常にポジティブなことのようだね）。CTOの肩書きやこの記事の全体のポイントはあまり関係ないし、彼が共同創業者でなければこの状況は成り立たなかったと思う。創業者は必ずしも望まない役割に押し込まれるべきではないという良い教訓だと思うけど、CTOの肩書きは本当に関係ないよね。

└

このコメントは、今までのコメントの中で一番理にかなってると思った。さらに言えば、多くの企業にはエンジニアリングのVPとCTOがいることも強調できるよね。その場合、CTOはもっと「戦略的」な大局的な仕事をすることが多くて、VPEが日常のSWE管理や基準設定を担当するんだ。でも、それにもいろんなスタイルがあるよね。

└

以前、Cレベルの人たちが一般社員と一緒に働いてる会社で働いてたことがあるんだ。ケンブリッジの優秀なEE学位を持ってる、知的な人たちだったよ。彼らは自分の強みを理解していて、自分たちが作った会社をより良い人に任せることにしたんだ。

└

「CTO」というタイトルには明確な意味がないからです。私たちの「CTO」はコードを書いています。アーメン。私はCTOですが、ほとんどの時間をコーディングに費やしています。中小企業に呼ばれて、彼らの基盤技術を現代にアップデートし、ワークフローを改善するためのLOBアプリを作り、最終的にはその分野で使っているEMRを置き換える新しいものを構築するために来ました。私には直属の部下はいません。臨床医や医者がいる会社で、技術者は私を含めて2人だけです。予算やレポートを作成する必要もありません。でも、その特定の会社での私の役割を考えると、このタイトルが唯一意味のあるものでした。誰かに聞かれるたびに「でも、実際にはCTOの仕事はしてないんだけど」と付け加えなきゃいけません。

ちょっと不人気かもしれないけど、面白いテーマだから反論を投稿するね。質問はこうだ：コードを書くせいで、CTOの責任リストにあることを何をやってないの？その理由の一つが「楽しんでるから」って言ってるけど、新しいプロダクトを出せるのは組織の中で数人だけってのは…心配だよね。CTOがこれを解決したいと思うのは当然だけど、CTOがそのプロダクトを出すのが最も効率的な時間の使い方とは思えない。これを正しく読んでるなら、要するに「自分の地位と自由度のおかげで、実験的なプロジェクトに数ヶ月も取り組めるけど、チームに同じことをさせていない」ってことだよね。200人から400人の会社でこの態度を直接見たことがあって、上層部からのメッセージは「イノベーションは民主化できない」ってフレームだった。数年間それを見てきて、これは良くないモデルだと思う。CTOは技術的なビジョナリーだけど、コードを書くことは高いレバレッジの活動じゃない。良いスタートアップのCTOは、会社の成長に伴って役割を何度も変える必要があるし、リーダーとしての深い影響を理解しないのはよくある落とし穴だと思う。Assembledの場合、Crunchbaseによると従業員は100人から250人だって。500人から1000人に近づくなら、CTOとしてのコードを書くことについて再評価することを真剣にお勧めするよ、少なくとも今のあなたのレベルではね。一つ技術的な質問なんだけど、特定の機能のMVPを「水を通すため」に開発して、他のチームに「プロダクション準備が整った状態」にするために渡すことってある？次の懸念に取り組む前に、長期的な実験を終わらせる時間がないときはどうなるの？これらの質問をするのは、私がこのシステムが失敗するのを見たポイントだからで、あなたにとってもそれが問題だったことがあるのか興味があるんだ。

└

また、「CTOの責任リスト」なるものがあるかのように示唆してるね。企業はCTOにxやyのポートフォリオを与えることができるけど、会社がタイトルの重要性に達する頃には、VP/EやVP/PMがカバーしない「本質的なCTOの責任」を考えるのは難しい。私が思いつく唯一のことは「組織全体のアーキテクチャの監視」で、これはかなり毒性のある役割だと思う。CTOがいろいろやってる組織では、彼らを別の形の帽子をかぶったVP/E（またはVP/PM）として考える方が通常は理にかなってると思う。まだコードを書くVP/Eについての面白い記事が書けそうだね！

└

特定の機能のMVPを開発して「水をパイプに通す」ために、それを他のチームに渡して「本番準備完了」にすることがある？あなたの考え方が気に入ったし、CTOがここで何をすべきだと思っているのか知りたい。

└

こういう「CTOは自分の好きなことをやるべきじゃなくて、責任のリストをこなすべきだ」っていうロボット的な考え方には、いろいろ問題があるよね。君は、テック企業でコーディングが高いレバレッジにならないと思ってるの？会社が存在する理由をもう覚えてないの？君の言う通り、ただ人に生活を提供して、仕事で幸せにさせるためじゃないよね。絶対にそうじゃない。会社の唯一の目的は価値を提供することだけど、その価値をROIや四半期の数字を良く見せるための曖昧な影響以外に定義できないんじゃない？どんな会社でも、難しい機能を合理的な時間内に出荷できる開発者は少数で、その中には創業者で半分のコードを書いたCTOも含まれることがほとんどだよ。特定のコードベースでの経験が何年も必要だから、どんなことをしても、他の誰かが同じレベルに達するまでには何年もかかるかもしれないし、製品が大きくなりすぎて、もう誰もそれができなくなるかもしれない。もしCTOが1日で大きな機能を出荷できる立場にいるなら、彼らがそれをやるべきじゃないと主張するのは非常に難しいよ。彼らのスケジュールで1日をもっと価値のある使い方があるとしたら、CEOとKPIについて話し合うこと？そんなのクソだね。これは君も気づいてるかもしれないけど、私にとっても近い話だよ。でも、時々Cレベルの人たちが trenches に戻って、サラリーマンが直面していることを感じるのは賛成だよ。彼らは第三者の意見だけで物事を解決できないからね。

私の経験もかなり似てるよ（ただ「不満なジョン」の期間がもう少し長いけど）。このアプローチは今の私の実践にとても近い。いくつかのレポートがあって、R&Dのリーダーシップチームを運営してるけど、できるだけディレクターたちに委任してる。組織が必要とするところでは手を動かすけど、他の部分では組織を責任を持たせ、エンジニアたちをインスパイアし、大局を見失わないようにするのが私の仕事だと思ってる。これに疑問を持つ人には、アドリアン・ニューイーの「How to Build a Car」をお勧めするよ（レッドブル・レーシングのCTO）。でも、はっきり言っておくと、もしCTOとして「特定のプロジェクトを運営できるのは自分だけだからコードを書く」ってだけなら、その問題をまず解決するのがあなたの仕事の一部だと思う。やっぱり自分が一番やりやすいけど、イノベーションプロジェクトを運営したり、顧客と関わったりするために（多くの）他の人を常に配置しておくべきだよ。

戦略に関心を持たずにコードを書く時間があるなら、「CTO」という肩書きを持つ人を真剣に受け止めるのが難しいな。私は「CTO」になる「機会」をいくつか経験したけど、それは実際には「エクイティ」の約束がある名ばかりの低賃金のシニア開発者に過ぎなかった。

Hacker Newsで議論の続きを見る

ハクソク