CTOがいないスタートアップの技術意思決定 — PMとエンジニアだけで「誰が何を決めるか」を設計する
「誰かが決めてくれるはず」という暗黙の前提が崩れたとき、CTO不在スタートアップの技術開発は止まります——あるいは、誰かが無断で決め続けることで後から取り返しのつかない技術的方向性が積み上がります。
解決策はCTOを採用することだけではありません。技術意思決定を構造として設計することで、CTO不在でも機能するガバナンスを組織に埋め込むことができます。本稿では、CTO不在スタートアップが陥りやすい意思決定の空白パターンを整理し、PMとエンジニアだけで運用できる技術ガバナンスの最小構成を解説します。
CTO不在で生まれる「技術意思決定の空白」
技術意思決定の空白は、3つの典型的なパターンで現れます。
パターン1：「お互いに相手が決めると思っていた」
PMは「技術的なことはエンジニアが判断するもの」と考え、エンジニアは「仕様はPMが確定するもの」と考えます。非機能要件（パフォーマンス・セキュリティ・スケーラビリティ）はどちらの管轄でもないまま放置されます。問題は、非機能要件こそがシステムの持続可能性を左右する判断であることです。
パターン2：「リードエンジニアが全部決めている」
実装の判断だけでなく、アーキテクチャ・技術選定・採用基準まで1人が担っています。これは短期的に機能しますが、その人物が離職したとき、意思決定の根拠がどこにも残っていません。また、リードエンジニアが「全部決める」状態は過負荷であり、燃え尽きのリスクも高くなります。
パターン3：「毎回ゼロから議論している」
似たような判断を毎回会議で再議論します。「このAPIはRESTにするかGraphQLにするか」「このデータはDBに持つかキャッシュするか」——基準がないため、議論が収束するまでに時間がかかります。さらに、判断の一貫性が失われ、後から見ると矛盾した設計が混在しています。
この3パターンに共通するのは、意思決定の型が存在しないことです。CTOがいれば、自然とこの型を提供する役割を担います。CTO不在では、それを人ではなく「設計」として代替する必要があります。
意思決定の3レイヤー
技術意思決定を整理するとき、まず「どの層の決定か」を区別することが出発点になります。
| レイヤー | 内容 | 例 | 判断頻度 | 覆しやすさ |
|---|---|---|---|---|
| 技術戦略 | 「なぜこの技術方向性か」 | 内製 vs 外部SaaS、プラットフォーム選定、スケール方針 | 四半期〜年単位 | 低（変更コスト大） |
| アーキテクチャ | 「どのように設計するか」 | DB設計、サービス分割、API設計方針 | 月〜四半期単位 | 中 |
| 実装 | 「具体的に何を書くか」 | 関数の実装方法、ライブラリの選択 | 日次〜週次 | 高（局所的） |
この3レイヤーは、決定の影響範囲と覆しやすさが大きく異なります。実装層の決定は局所的で覆しやすい性質を持ちます。アーキテクチャ層の決定は数ヶ月の開発に影響し、変更コストが高くなります。技術戦略層の決定は会社の事業モデルにまで影響し、誤った方向に進んでしまうと取り返しに数年かかることもあります。
CTO不在スタートアップが特に注意すべきなのは、アーキテクチャ層の意思決定を誰も担っていない状態です。実装はエンジニアが日々行い、技術戦略はCEOやPMが「このプロダクトをどうしたいか」という形で関与します。しかしアーキテクチャ層は、その中間にあるがゆえに空洞になりやすい構造を持っています。
アーキテクチャの判断と評価軸についてはアーキテクチャパターン入門：モノリス・マイクロサービス・サーバーレスを判断軸としてで詳しく解説しています。
誰が何を決めるか：意思決定オーナーマップの設計
空白を埋めるための最初のステップは、各レイヤーの意思決定オーナーを明文化することです。以下は代表的なCTO不在スタートアップ（CEO + PM + リードエンジニア + エンジニア数名）における意思決定オーナーマップの例です。
| 意思決定の種類 | オーナー | 相談先 | 最終決定方法 |
|---|---|---|---|
| 採用する技術スタックの変更 | CEO / PM | リードエンジニア | 合議（全員同意） |
| 新機能のアーキテクチャ方針 | リードエンジニア | PM | リードエンジニア単独 |
| 既存機能のリファクタリング優先度 | リードエンジニア + PM | CEO | 書面での提案→承認 |
| 外部SaaSの導入 | PM + リードエンジニア | CEO | コスト閾値で分岐 |
| 日次の実装判断 | 担当エンジニア | リードエンジニア | 担当者単独 |
| インフラ・セキュリティ構成の変更 | リードエンジニア | CEO | 変更前にSlack通知→承認 |
| 新規エンジニア採用の技術評価 | リードエンジニア | PM / CEO | リードエンジニア単独（最終合否はCEO） |
このマップを設計するとき、2つの原則があります。
原則1：「オーナー」と「最終決定方法」を分離する
オーナーは「この判断の責任を持つ人」であり、必ずしも単独で決めるわけではありません。合議・提案→承認・単独決定の3パターンを使い分けることで、スピードと品質のバランスをとれます。重要度が高くかつ覆しにくい判断ほど合議に、日常的で覆しやすい判断ほど単独決定に振るのが基本です。
原則2：コスト閾値などの客観基準を入れる
「外部SaaSの導入はPM + リードエンジニア判断だが、月額10万円を超える場合はCEO承認が必要」のように、数値で決定経路を分岐させると、判断の遅延が起きにくくなります。「誰に相談すべきか」の判断も自動化されます。
この設計が機能しなくなるパターン：提案が消える問題
上記のマップを使う際に見落としやすい落とし穴があります。「合議（全員同意）」や「書面での提案→承認」を求める項目は、敷居が高くなりすぎると提案そのものが上がらなくなるという問題です。
技術スタックの変更やリファクタリングの優先度引き上げは、CEOやPMの視点から見ると「コストの大きな判断」に映りがちです。承認プロセスが重いと、エンジニア側の説明コストが高くなり、正当なリアーキテクチャの提案がそもそも議題に上がらなくなります。一度「NG」になると以後の議題からも消えていき、技術負債を返済しながらも負債が積み増されていく構造が続きます。
CTOがいる場合は、エンジニアリングの方向性を受け取り、予算・優先度の中で取捨選択を行う役割を担います。CTO不在のチームでは、方針自体を承認する判断者がいないため、同じ経路では機能しません。
対策は2点です。技術スタック変更やリファクタリングの提案は「否決か承認か」の二択ではなく、「優先度をつけて保留し、技術定例（後述）の定期議題として生き続けさせる」 プロセスにすることが有効です。また、提案フォーマットを軽量化し、エンジニアが気軽に出せる仕組みにすることで、提案が上がらなくなる萎縮を防げます。
軽量な技術ガバナンス：ADR・技術定例・エスカレーション基準
意思決定オーナーマップだけでは不十分です。実際の運用には「記録」「定期的な見直し」「エスカレーションのルール」が必要になります。
ADR（Architecture Decision Record）
ADRとは、技術的な意思決定の背景・選択肢・結論・トレードオフを1ページで記録するドキュメントです。フォーマットは以下の5項目が最小限です。
- 背景: 何を決める必要があったか
- 選択肢: 検討した選択肢と各々の長短
- 決定: 何を選んだか
- 理由: なぜそれを選んだか
- 結果: この決定がもたらすトレードオフ
ADRはGitHubのリポジトリにMarkdownファイルとして保存するだけで構いません（例: docs/adr/001-database-selection.md）。重要なのは「なぜそう決めたか」を残すことで、後から参照したとき「この選択はなぜ?」という疑問が即座に解消されます。
CTO不在のチームでは、意思決定の根拠が個人の記憶に依存しやすい状況があります。ADRによって、それを組織の記憶に変えることができます。特にリードエンジニアが離職した場合、ADRなしでは設計の前提が全て失われます。
技術定例
週次または隔週で、リードエンジニアを中心とした30〜60分の技術定例を設けることを推奨します。議題は以下の3点に絞るとよいでしょう。
- 進行中の技術的課題の共有（ブロッカーの早期発見）
- 今後の設計判断の事前合意（後戻りの防止）
- ADRの作成・レビュー（意思決定の記録）
重要なのは、PMも同席することです。技術的な議論をエンジニアだけで閉じてしまうと、ビジネス要求と技術判断の乖離が起きやすくなります。PMが同席することで、「この技術的制約が、その機能のスケジュールに影響する」という変換がリアルタイムで行われます。
なお、技術定例はアジェンダを事前に共有し、30分で終わる設計にすることが継続性の鍵です。「また長い議論になる」という心理的障壁が、定例の形骸化を招きます。
エスカレーション基準
「誰がどんなとき上に判断を仰ぐか」を明文化することも欠かせません。以下は実際に機能しやすいエスカレーション基準の例です。
エンジニア → リードエンジニア
- 設計の判断に2時間以上悩んだとき
- 複数の技術選択肢が浮かんで比較検討が必要なとき
- 設計変更が他のコンポーネントに影響しそうなとき
リードエンジニア → PM / CEO
- 技術的方向性の変更が事業判断を必要とするとき（例: 外部APIへの依存度変更）
- チームの稼働が持続不可能な状態になっているとき
- 外部委託やツール調達の検討が必要なとき
- セキュリティ・コンプライアンス上のリスクを発見したとき
「2時間以上悩んだらエスカレーション」という基準は一見シンプルですが、実際にはこの基準がないと「迷惑をかけたくない」という心理が働き、一人で抱え込みが発生します。基準を明文化することで、エスカレーションが「できない人がすること」ではなく「正しいプロセスを踏んでいること」として位置付けられます。
外部の力を借りるべき判断点
上記の設計を実装しても、以下のような状況では社内だけで完結させようとしないことが原則です。
プラットフォームの根本的な再設計が必要なとき（モノリスからマイクロサービスへの移行、クラウドプロバイダーの変更など）は、経験のある外部の視点が不可欠です。誤った判断は数ヶ月の開発リソースを消費します。
セキュリティ基準を達成する必要があるとき（個人情報保護法・SOC2・PCI-DSSなど）は、コンプライアンスの専門知識を持つ人材が必要です。「たぶん大丈夫」で進めた結果が、後の監査で問題になるケースは少なくありません。
CTOレベルの技術戦略判断が連続して必要なとき（大型の技術提携、重要な採用判断、M&Aに伴うデューデリジェンス対応）は、技術顧問や外部アドバイザーを起用する判断が合理的です。
CTOを採らずに技術力を補う具体的な選択肢——技術顧問・フラクショナルCTO・受託・内製の使い分け——については別稿で詳述します。
まとめ：技術意思決定の設計は一度で完成しない
本稿で解説した意思決定オーナーマップ・ADR・技術定例・エスカレーション基準は、いずれもシンプルな仕組みです。しかし、これらを「ゼロから設計する」ことと「何となく運用されている」状態では、組織への影響が大きく異なります。
スタートアップのフェーズが変わるたびに、意思決定の範囲と深度が変化します。PMF前とPMF後では、アーキテクチャ判断の重要性も頻度も異なります。定期的にオーナーマップとADRを見直すことが、長期的な技術的健全性を保つ鍵になります。
CTO採用の判断タイミングについてはスタートアップがCTOを採用すべきタイミングと判断基準を参照ください。また、CTO不在のまま投資後に顕在化しやすい技術リスクのパターンは投資後に発覚しがちな技術リスク10選で整理しています。
Tied株式会社では、CTO不在スタートアップへの技術ガバナンス設計支援から継続的な技術アドバイザリーまで、段階に応じたサポートを提供しています。お気軽にご相談ください。