🌠

創業初期CTOが将来の「技術的な北極星」になるために

に公開
CTO
スタートアップ
エンジニアリング
技術戦略
idea

🎧 この記事のテーマについて、AI同士で対話させたPodcastも作りました。 🎧
Spotify

はじめに

私自身小さなスタートアップでCTOになってから、1年が経ちました。「あるべき姿」を見失わないように、自分への言い聞かせも込めて、今の考えを言語化してみました。

創業初期のスタートアップにおける技術開発は、まさに「戦場」です。
明日のPMFを模索しながら、手元のコードを書きなぐる日々。そんな中で、「将来のエンジニア組織のこと」なんて考えている暇はない、というのが本音かもしれません。

しかし、組織が拡大し、あなたがコードを書く手を止めたとき、そこには何が残るでしょうか？

もしそこに残るのが「あなたにしか読めないスパゲッティコード」と「誰も理由を知らない技術スタック」だけだとしたら、それは技術的負債というより、組織の時限爆弾になりかねません。

この記事では、CTOが将来のチームにとっての「技術的な北極星（道標）」であり続けるために、今のうちから少しずつ仕込んでおける 技術的投資 について話します。

この記事で扱うこと

  • ADR（Architecture Decision Records）: 技術選定の「Why」を残す軽量な手法
  • プリンシプルの言語化: 暗黙知を排除し、カルチャーをコード化する
  • 技術的負債の戦略: 「破綻」ではなく「成長痛」にするための付き合い方
  • DX（Developer Experience）: 初日からCI/CDや環境構築に投資する意味
  • 権限移譲: 「コードを書かないCTO」への脱皮と求心力

1. 「Why」を残す：ADRによる意思決定の追体験

開発が進むと、必ず新しく入ってきたメンバーにこう聞かれる日が来ます。「なんでここはRDBじゃなくてNoSQLを選んだんですか？」

その時、当時のコンテキストを鮮明に思い出せるでしょうか。「なんとなく流行っていたから」ではなく、当時のリソース制約やビジネス要件に基づいた「理由」があったはずです。

ここでおすすめしたいのが ADR（Architecture Decision Records） の導入です。完璧なドキュメントを書く必要はありません。重要なのは、「どんな文脈で、どんな決定をして、どんなトレードオフを受け入れたのか」をセットで残すことです。

軽量なADRのテンプレート例

たとえば、リポジトリの docs/adr/ ディレクトリに、以下のようなMarkdownファイルを放り込んでおくだけでも十分です。

# ADR-001: 認証基盤としてAuth0を採用する

## Context
サービスのMVP（Minimum Viable Product）リリースまで残り1ヶ月。認証機能の実装工数は極力削りたい。
また、将来的にエンタープライズ向けのSSO対応が見込まれるが、現状のメンバーに認証周りの深い知見を持つエンジニアがいない。

## Decision
自前実装やFirebase Authではなく、Auth0を採用する。

## Consequences
- ユーザー管理画面の実装コストがゼロになった。
- 将来のSSO対応への道筋がついた。
- ただし、MAUが増えた際のランニングコストは自前実装やFirebaseより高くなるリスクがある（シリーズA以降で再検討が必要になる可能性）。

書くのにかかる時間は5分〜10分程度です。しかし、これが数年後、「なぜこの複雑な同期処理があるのか？」という疑問に対する強力な回答になります。

正直なところ、リリース直前の修羅場でこれを書くのは精神的にタフです。「後で書く」と言いたくなります。ですが、後で書かれたドキュメントはたいてい美化されています。迷いやトレードオフが生々しいうちに記録することにこそ価値があります。

※ こちらの内容は「創業初期のスタートアップで『開発スピードを殺さずに』ADRを運用する技術」でも詳しく紹介しています。

2. 「暗黙知」を排除する：プリンシプルの言語化

初期メンバーだけで開発していると、「阿吽の呼吸」で済んでしまうことが多々あります。「エラーハンドリングはこうするよね」「テストはこのレベルまで書くよね」といった共通認識です。

しかし、メンバーが増えた瞬間、この阿吽の呼吸は崩壊します。これを防ぐには、早い段階で エンジニアリング・プリンシプル（行動指針・設計思想） を言語化しておく必要があります。

具体的なアクション

きれいな標語を作る必要はありません。実務的なガイドラインとして機能させましょう。

  • コードレビューの基準: 「動けばOK」なのか「可読性重視」なのか。
  • 技術選定のスタンス: 「枯れた技術」を好むのか、「最新のトレンド」を攻めるのか。
  • 品質への考え方: テストカバレッジを絶対視するのか、クリティカルパス重点主義なのか。

これらを PRINCIPLES.md としてリポジトリに置いておくだけで、新入社員のオンボーディングコストが激減します。さらに、コードレビュー時の指摘が「個人の好み」ではなく「チームの合意事項」に基づいたものになるため、無用な対立を防ぐ効果もあります。

3. 捨てる勇気と残す知恵：技術的負債の戦略化

「技術的負債は悪だ、ゼロにすべきだ」という意見もありますが、創業初期のスタートアップにおいてそれは現実的ではありません。PMF前の最優先事項はビジネスの検証速度だからです。

重要なのは、無自覚に負債を溜め込むのではなく、「意図的に借金をする」 感覚を持つことです。

  • 借金の判断基準: 「今は汚いコードだが、今週中に機能をリリースしないと契約が取れない」という場合、それは合理的な負債です。
  • 返済計画: 負債を作るときは、チケットやTODOコメントに「いつ、どのような条件で返済するか（リファクタリングするか）」を明記します。

CTOとしての心構えは、負債を「破綻」の原因にせず、組織が大きくなるための「成長痛」としてコントロール可能な状態に保つことです。「ここはあえて汚く書いた。なぜなら〜」と説明できる状態であれば、それは負債ではなく戦略の一部です。

4. 初日から作るDX

「CI/CDパイプラインの整備？ ローカル開発環境のDocker化？ 人が増えてからでいいでしょ」

そう思うかもしれません。しかし、リソースが限られる創業初期だからこそ、開発者体験（DX）への投資 はレバレッジが効きます。

手作業でのデプロイや、複雑怪奇なローカル環境構築手順は、ただでさえ少ないエンジニアの時間を奪います。また、優秀なエンジニアほど「快適にコードが書ける環境」を重視します。

  • CI/CD: テスト実行やデプロイの自動化は初日から（なんならコードを書く前から）入れる。
  • ローカル環境: docker-compose up 一発で環境が立ち上がるようにする。

これらが整備されていることは、採用時の強力なアピールポイントにもなります。「この会社は技術を大切にしている」というブランディングは、ここから始まります。

5. コードを書かないCTOへの脱皮

組織が拡大するにつれ、CTOであるあなたが最も優秀なコーダーであり続けることは難しくなります。むしろ、あなたがコードを書き続けることがチームのボトルネックになる瞬間が必ず来ます。

「技術的な北極星」であり続けるためには、ハンズオンからの卒業（権限移譲） と向き合う必要があります。

  • コードからアーキテクチャへ: 実装の詳細ではなく、システム全体の設計やデータフローのレビューに注力する。
  • トレンドのキュレーション: 最新技術をすべて自分で試すのではなく、どの技術が自社の課題解決に役立つかの「目利き」に徹する。

現場を離れることに不安を感じるかもしれませんが、あなたの役割は「最高のコードを書くこと」から「チーム全員が最高のコードを書ける状態を作ること」へシフトします。信頼されるCTOは、自分がいないと回らない組織ではなく、自分がいなくても自律的に回る組織を作れる人です。

実務での導入ステップ：どこから始めるか

いきなりこれら全てを完璧にこなすのは不可能です。まずは小さく、効果が見えやすいところから始めましょう。

  1. まずはADRを1枚書く: 次のミーティングで決める技術選定や設計変更について、簡単なメモを残してみてください。フォーマットは適当で構いません。
  2. CI/CDを整備する: もし手動デプロイをしているなら、今すぐ自動化しましょう。これは将来必ず「やっておいてよかった」と思うはずです。
  3. 「やらないこと」を決める: プリンシプルの第一歩として、「うちのチームではこれはやらない（例：過剰な抽象化）」を明文化してみましょう。

落とし穴と限界

ここで挙げた施策には「やりすぎ」のリスクもあります。

  • ADRの形骸化: 些細な変更までADRに残そうとすると、書くこと自体が目的化し、開発スピードが落ちます。アーキテクチャや、将来の負債になりうる重要な決定だけに絞りましょう。
  • 早すぎる最適化: DXへの投資は重要ですが、PMFも見えていない段階でKubernetesの完全なクラスタを組むのはオーバースペックかもしれません。

常に「今のビジネスフェーズにおいて、これは過剰投資ではないか？」と自問自答するバランス感覚が求められます。

まとめ

創業初期のCTOにとって、「技術的な北極星」になるとは、技術力でマウントを取ることではありません。

「なぜその技術を選んだのか（ADR）」を語り継ぎ、「どう開発すべきか（プリンシプル）」を示し、「快適に開発できる環境（DX）」を用意する。

これらは地味な作業ですが、将来あなたの組織に参加するエンジニアにとっては道標となるはずです。

Discussion