CTOという現実

今月はあと1本の記事が読めます。その後、無料のLeadDev.comアカウントの登録が必要です。

推定読了時間: 10 分

要点

• CTOの仕事は一つではない。この肩書きは、コードをまだ書いている創業者から、数年エディタを開いていない取締役向けの役員まで幅広い。
• まずは経営者、次に技術者。あなたは技術と事業成果をつなぐ責任を負う。仕事のほとんどは外向き・横向きのものであり、コードに深く入り込むものではない。
• 2026年では、双方でハードルが上がる。より戦略的でありながら、よりハンズオン。

---

ほぼすべてのエンジニアリングの役割において、あなたの同僚は他のエンジニアです。ジュニアであれ、スタッフエンジニアであれ、エンジニアリングマネージャーであれ、あなたは自分と同じような仕事をする人たちの中にいて、思考を確認したり負担を分かち合ったりするために、彼らに絶えず頼っています。CTOになったときに私を驚かせた最初のことは、それが当てはまらなくなるということでした。

私のチームはエンジニアリングチームではありません。私のチームは他の機能別リーダー、CEO、CFO、セールスやプロダクト、マーケティングを率いる人々であり、私たちは一緒に会社を運営しています。そのグループはエンジニアのチームとは全く異なり、そこに属することを学ぶことが仕事の大部分を占めます。

だから、「私は一日何をしているのか」と聞かれたとき、答えは非常に多岐にわたるということです。1時間はアーキテクチャレビューでプロジェクトを深掘りし、次の時間は財務と予算の見通しについて話し、さらにはホスティングコストを調べたり、インシデントに巻き込まれたりします。それは会社の全領域を技術の側面から見たものであり、以前の仕事とはほとんど似ていません。

Your inbox, upgraded.

週刊のエンジニアリングインサイトを受け取り、リーダーシップのアプローチをレベルアップしましょう。

CTOの役割に単一のバージョンはない

CTOの役割が外部から非常に誤解されやすい理由は、それが一つの役割ではないからです。12人規模のスタートアップでは、CTOは通常、ほとんどのコードをまだ書いている創業者です。大企業では、数年コミットをしていない取締役向けの技術役員かもしれません。

どちらも正しく仕事をしていると言えます。なぜなら、仕事とはその会社がその特定の段階で必要とする技術リーダーになることであり、段階は大きく異なるからです。

会社が大きくなるほど、役割は取締役会対応、資本配分、他のリーダーを通じたリーダーシップへと傾き、コードに触れることは少なくなります。スタートアップ寄りの段階ではその逆になります。しかし、どの位置にいても、責任は同じです。

では、私自身の役割はどのようなものでしょうか。Nordhealthは上場企業ですが、規模と成長軌道ではスケールアップに近いものです。私は、製品や技術的な意思決定に深く関わる創業者CTOのような役割を果たしており、上から見守る立場ではありません。

CTOとして、あなたは会社の技術と商業的な未来の関係を所有し、CEOや取締役会に対してその責任を負います。Camille Fournierの簡潔な表現では、CTOはまず経営者であり、次に技術者であるということです。これは、役割を技術ラダーの頂点に立つ「建物の中で最も優れたエンジニア」として想像する人々が時に見逃す部分です。実際には全く違います。

しかし、その責任が私に与える影響は、ほとんどの人が期待するものとは逆です。あらゆることに責任を負うことは、私を仕事から遠ざけるのではなく、むしろ近づけたいと思わせます。そして、私はそれができるように役割を構築してきました。私は真実を探求する組織を望んでおり、技術会社における最も真実なものは私たちが実際に書いているコードです。だからこそ、私はそれに近くにいます。

それが私たちの水曜日のレビューで行っていることであり、すべてのプロジェクトのSlackチャンネルに参加し、AIを使って自社のコードベースやログを調べ、なぜ遅いのか、どうすればより良く構造化できるのかを尋ねる理由です。技術的な状態を保つことは、品質基準が維持され、正しいアプローチを取っていることを知る方法であり、私とすべてのエンジニアの間に直接の線を保つものであり、これは非常に健全だと思います。

週のほとんどは他者との関わり

仕事が経営者であるため、そのほとんどはエンジニアではない人々との会話で成り立っています。私はCEOに報告するので、彼とは常に話していますし、プロダクト担当VPとは毎日、しばしば数時間ごとに話しています。セールス、マーケティング、オンボーディングのC-suiteの同僚たち、さらには顧客とも多くの時間を費やし、彼らの問題を解決したり、次の方向性を理解したりしています。私自身のエンジニアリングリーダーシップグループは、その週のミーティングの一つに過ぎず、中心ではありません。

私は毎週に意図的な形を与えようとしています。放置すれば完全にミーティングで埋め尽くされてしまうからです。私たちはR&Dのためのノーミーティングデーを火曜日と木曜日の2日間設けており、チームと私自身の深い集中のための2日間を守っています。

月曜日は1on1とシニアリーダーシップミーティングで、確実に長いToDoリストが生まれます。水曜日はプロジェクトレビューで、CEO、プロダクト担当VP、そして私がプロジェクトを率いる人々と一緒に座り、最新のビルドを確認し、デザインの批評を行い、停滞している決定を解除します。

金曜日は部署全体に文章を書きます。この規模では、文章を書くことが話しかけられる人数を超えて人々に届ける方法だからです。

この構造は、文脈の切り替えや高い workload に対処する上で非常に役立っており、常に2日の集中日があることを知っているので、他の日が絶えず中断されてもそれほどストレスを感じません。

More like this

誰も教えてくれなかったスキル

あなたの技術スキルは当然のものとされ、それがあなたがCTOになる理由でもあります。しかし、私が学ばなければならなかったスキル、そしてこの役割を目指す人にぜひ真剣に取り組んでほしいスキルは、会社の財務を読むことです。

それが教えてくれるのは、決定の「見かけの価格」ではなく、真のコストを見ることです。不快な部分は、最善のエンジニアリングの答えと最善の財務の答えがしばしば異なる方向を指すことです。仕事の大きな部分は、それらの間の正しいトレードオフを見つける責任を負い、反対方向に傾いていたかもしれない部屋に対してその判断を説明することです。

物事にかかるコスト、あるいは将来的にかかる可能性のあるコストを理解することは、エンジニアリングにおいて非常に過小評価されています。組織がしばしば、エンジニアが自分たちの決定の実際のドルコストを常に見られるように構造化されていないからです。

表面上は純粋に技術的な決定のように見え、私たちが最初に間違えた例を挙げます。私たちは使用量の初期見積もりに基づいて監視をホスト型Grafana Cloudに移行し、セルフホストの必要がないという望ましい状況にしました。

成長するにつれて、実際に保存したい量がより明確になるにつれ、その価格モデルは私たちにとってスケールしなくなり、継続する場合のコストは正当化できない水準に向かっていました。そこで現在は、セルフホストして運用するバージョンに移行し、契約終了時に切り替えるために構築を進めています。

エンジニアの本能は、ベンダーへの支払いを続け、実装チームをプロダクト業務に専念させることですが、財務的な問いかけは、そのような選択が、最初にモデル化した軌道ではなく、実際に進んでいる軌道でどれだけのコストを生むかということです。

セルフホストにも、構築と運用にかかるエンジニアリング時間の実際のコストがあります。だから仕事は、四半期の作業量が少ない方を選ぶのではなく、長期的な視点で両者を正直に比較検討し、残りを先送りしないことです。私たちの決定を後押ししたのは、完全な財務的コントロールとサプライズの不在でした。なぜなら、セルフホストにより、高速な最近のストレージにどれだけ残し、安価な長期アーカイブにどれだけ移すかを自分で決められるため、成長し続ける中でコスト曲線を自ら形作れるからです。

この逸話は、役割があなたに求めるものを美しく示しています。それは「最善の技術的答えを持つ人」であることをやめ、技術を所有する会社オペレーターになることです。この考え方は、組織のどのレイヤーでも実践できます。予算権限を委ねられるずっと前から、技術的な議論で勝つ方法は、技術的な洗練さではなく、コストと会社へのコミットメントの言語で議論することです。この思考を先取りする価値はあります。

AIがCTOの仕事を変えている

AIは、ここ数年で他の何よりも任務を変えました。私は部署全体に毎日使用するよう促し、私たちのコードのほとんどは今や手書きではなく生成されています。現在は主にClaude Codeを使用しており、次にCursor、Codexの順です。

しかし、より大きな変化は会社全体に及び、エンジニアだけでなく全員に、自分の仕事の周りの作業を自動化するよう教えています。そして、私はそれに大きく関与しています。

業界は依然としてAIの利益を正確に測定することに苦戦していますが、私にとって重要なのは結果であり、それはすでに具体的なものです。私たちはもはや、1人のエンジニアがどれだけ生み出せるかの上限を知りません。そして、利用可能なツールでどれだけ高品質にできるかを探求する旅の途中にいます。

同じ財務のレンズは、私の採用に関する考え方も変えます。新たなエンジニアは単なる給与の項目ではありません。役割の周りのすべてを数えると、それはその数倍のコミットメントであり、元に戻すのは遅く、1人がどれだけ生み出せるかについての昨年の前提に対して行うものです。そして、まさにその前提をAIが書き換えつつある今です。

そこで今年、私は経営チームとエンジニアリングリーダーたちと異なるデフォルトに合意しました。席数を固定し、すでにいる人々でどれだけ生産的で効率的になれるかを発見することにしました。誰かが辞めた場合、バックフィルについて話し合う前に約3ヶ月間その席を空けておき、本当に痛みを感じたときにのみ採用します。

目的は節約するお金ではありませんでした。ハードリミットは、より良い行動を確実に促す唯一の方法だと私は発見しました。それは、デフォルトで人を増やすのではなく、範囲を削るか、より賢い方法で問題を解決するかを考えることです。

制約のない会社がすべてを追いかけて採用するのに対し、私たちは新機能や新市場をどれだけ取り入れるかに意図的な蓋をし、そうでなければ作っていた良いアイデアにもノーと言わなければなりません。制約は組織にただお金を使うのではなく、より深く考えることを強いるものであり、それは非常に良い実践だと思います。

ベルリン • 2026年11月9日・10日

エンジニアリングリーダーシップはこれまでになく速く動いています。
LeadDev Berlinで、他のリーダーたちがどのようにペースを保っているかをご覧ください。

見た目以上に難しい部分

この仕事で最も難しいのは、私が最初に述べたことです。あなたはエンジニアリングの頂点に立ち、もはや自然なエンジニアのチームに頼ることができなくなります。

最も重い決定、つまり人とお金に関する決定は、まさにその影響を受ける人々と常に話し合えるわけではなく、建物の中にあなたの席と全く同じ問題を抱えている同僚はいません。

私がそれに対処するために見つけた唯一の方法は、信頼できるプロフェッショナルのネットワークを構築することです。会社内に数人、ほとんどは社外にいて、最も難しい判断を一人で下す前にどこかで検証してもらうのです。

CTOの役割に就くことは、自分の会社を始めない限り難しいものであり、優れた技術者であることだけではありません。あなたは会社オペレーターになりたいと思う必要があります。もしそれが望む道なら、技術についてそうであったように、ビジネスや業界についても好奇心を持ってください。それが、誰も宣伝しない仕事の半分だからです。

私は別途、ここに至るまでの曲がりくねった道のりについて書きましたが、予想していなかったのは、それが私のモチベーションをどれだけ変えたかということです。今では、優れた製品を構築することだけでなく、優れた会社を成長させることに、より関心を持っています。