VCの技術評価はステージごとに重点が変わる。シードでは「人」、シリーズAでは「プロダクト・技術の実現性」、シリーズBでは「スケーラビリティと組織」を見る。この3段階の視点を理解することで、投資家は適切なリスク判断を下せ、スタートアップ側は正しい準備ができる。
なぜVCが技術力を評価するのか
テクノロジースタートアップの企業価値の大部分は、技術そのものか、技術によって構築されたプロダクト・ユーザー基盤に依存している。M&AにおけるTech DDが「問題発見・減点法」であるのに対し、VCの技術評価は本質的に「加点法」だ。この技術が市場を取れるか、このチームがそれを実現できるか、という問いに答えることが目的となる。
もうひとつ重要な点がある。VCは数週間で投資判断を下さなければならない。M&Aのように数ヶ月かけてコードベースを精査する余裕はない。そのため、限られた時間でシグナルを読み取る技術評価の「型」が必要になる。その型こそが、ステージ別の評価フレームワークだ。
ステージ別の技術評価基準
シード — 「この人がこの問題を解けるか」
シードステージでは、コードベースの品質やアーキテクチャの洗練度は評価の中心ではない。プロトタイプが動いていれば十分で、それよりも「CTOはこの技術領域を深く理解しているか」「問題の本質を技術的に把握しているか」を見る。
評価の重点はCTOの技術力・経験、技術的ビジョンの明確さ、プロトタイプの実装速度だ。特に「この問題を解くために、なぜこの技術スタックを選んだか」を説明できるかどうかは重要なシグナルになる。根拠なくトレンドの技術を選んでいる場合は、判断軸のなさを示している。
シリーズA — 「技術がプロダクト・マーケット・フィットを支えられるか」
シリーズAでは、MVPから本格プロダクトへの移行が始まる段階だ。ユーザーが増え始めており、技術が実際の負荷に耐えられるかどうかが問われる。また、初期の技術的負債がどの程度蓄積しているか、それをコントロールできているかも評価ポイントになる。
採用力も重要だ。シリーズAの資金調達後はエンジニアの採用が本格化する。「このCTOのもとで働きたいと思うエンジニアが集まるか」という観点で、技術ブログの発信実績やOSSへの貢献、GitHubのアクティビティを確認するVCも増えている。アーキテクチャの方向性が合理的かどうかも、この段階から確認される。
シリーズB — 「技術がスケールに耐えられるか」
シリーズBになると、Tech DDの深度はM&Aに近づく。ここでは技術的スケーラビリティとエンジニアリング組織の成熟度が最重要評価項目となる。100万ユーザーに対応できるアーキテクチャか、技術的負債は管理可能な水準か、インシデント対応プロセスは確立されているかを精査する。
組織面では、CTOが個人プレイヤーからエンジニアリングマネージャーへ移行できているかがポイントだ。会社の成長に合わせてリーダーシップスタイルを変えられないCTOは、シリーズC以降でボトルネックになるリスクがある。
ステージ別評価マトリクス
| ステージ | 評価の重点 | 主な評価項目 | 許容される弱点 | Red Flag | 一般的な評価期間 |
|---|---|---|---|---|---|
| シード | 人・ビジョン | CTO経歴、技術ビジョン、プロトタイプ品質 | コード品質低い、スケーラビリティなし | 技術スタック選定に根拠なし、CTOがコードを書けない | 1〜2週間 |
| シリーズA | プロダクト実現性 | アーキテクチャ方向性、技術負債管理、採用力 | モノリシック構成、テスト不足 | 技術負債が制御不能、CTOが採用できていない | 2〜4週間 |
| シリーズB | スケール・組織 | スケーラビリティ、組織成熟度、インシデント管理 | 一部レガシーシステムが残存 | 大規模障害の繰り返し、CTOが個人プレイヤーのまま | 3〜6週間 |
評価重点のシフト図
[シード] [シリーズA] [シリーズB]
人・ビジョン → プロダクト実現性 → 組織・スケール
(60%) (50%) (50%)
┌─────────┐ ┌─────────┐ ┌─────────┐
│ 人材 │ │技術実現性│ │スケール │
│ (CTO) │ │(PMF支援) │ │ (組織) │
└─────────┘ └─────────┘ └─────────┘
コード品質は 技術負債を 技術負債を
問わない 許容範囲内に 管理できているか
各ステージの技術評価チェックリスト
シードステージ チェックリスト
| # | チェック項目 | 確認方法 | 重要度 |
|---|---|---|---|
| 1 | CTOは技術領域に深い専門知識を持つか | 経歴確認、技術ディスカッション | ★★★ |
| 2 | 問題に対する技術的アプローチが明確か | ホワイトボードセッション | ★★★ |
| 3 | プロトタイプが実際に動作するか | デモ確認 | ★★★ |
| 4 | 技術スタック選定に合理的な根拠があるか | インタビュー | ★★☆ |
| 5 | CTOが自らコードを書けるか | GitHub確認、コーディング課題 | ★★☆ |
| 6 | 競合技術との差別化点を説明できるか | インタビュー | ★★☆ |
| 7 | 技術チームの構成計画があるか | 採用計画確認 | ★☆☆ |
| 8 | 知的財産(IP)の帰属が明確か | 契約書確認 | ★★☆ |
シリーズA チェックリスト
| # | チェック項目 | 確認方法 | 重要度 |
|---|---|---|---|
| 1 | アーキテクチャが現在の規模に適しているか | アーキテクチャ図レビュー | ★★★ |
| 2 | 技術的負債の把握と優先度付けができているか | バックログ確認 | ★★★ |
| 3 | 主要なメトリクス(応答時間、稼働率等)を計測しているか | 監視ダッシュボード確認 | ★★★ |
| 4 | デプロイ頻度とインシデント対応の記録があるか | CI/CDパイプライン確認 | ★★☆ |
| 5 | エンジニア採用の実績・パイプラインがあるか | 採用実績確認 | ★★☆ |
| 6 | 主要エンジニアの退職リスクはないか | 組織インタビュー | ★★☆ |
| 7 | セキュリティの基本対策が施されているか | セキュリティレビュー | ★★★ |
| 8 | 技術ドキュメントが最低限存在するか | ドキュメント確認 | ★☆☆ |
| 9 | 外部依存(OSS、APIサービス)のリスク管理があるか | 依存関係確認 | ★★☆ |
シリーズB チェックリスト
| # | チェック項目 | 確認方法 | 重要度 |
|---|---|---|---|
| 1 | アーキテクチャが10倍の負荷増に対応できるか | 負荷試験結果、アーキテクチャ設計書 | ★★★ |
| 2 | エンジニアリング組織にマネジメント層があるか | 組織図確認 | ★★★ |
| 3 | 技術的負債の返済計画が実行されているか | スプリント計画確認 | ★★★ |
| 4 | SREまたはDevOpsプラクティスが確立されているか | インフラチーム構成確認 | ★★☆ |
| 5 | セキュリティ監査の実施実績があるか | 監査レポート確認 | ★★★ |
| 6 | 採用プロセスが組織的に回っているか | 採用KPI確認 | ★★☆ |
| 7 | 障害対応(ポストモーテム)の文化があるか | インシデント記録確認 | ★★☆ |
| 8 | データガバナンスの基本方針が存在するか | データポリシー確認 | ★★☆ |
| 9 | 技術ロードマップが経営計画と連動しているか | ロードマップ確認 | ★★★ |
| 10 | CTOがエグゼクティブとして機能しているか | 取締役会/経営会議への参加確認 | ★★★ |
スタートアップCTOが「見られている」ポイント
投資家がCTOや技術チームを評価する際、表面的な技術スキル以上に重視する「隠れた観点」がある。
技術的意思決定の記録(ADR)があるかどうかは、エンジニアリング文化の成熟度を示す強いシグナルだ。「なぜこのデータベースを選んだか」「なぜマイクロサービスにしなかったか」という意思決定の記録は、技術的な判断軸があることを示す。
技術ブログ・OSSへの貢献・登壇実績は採用力の代替指標として機能する。外部への発信力があるCTOのもとには優秀なエンジニアが集まりやすい。シリーズAからBにかけて、この指標は重要度が上がる。
CTO/技術チーム評価スコアリングシート
| 評価項目 | シード重要度 | シリーズA重要度 | シリーズB重要度 | 評価(1-5) |
|---|---|---|---|---|
| 技術領域の専門知識 | ★★★ | ★★★ | ★★☆ | |
| 問題解決・意思決定能力 | ★★★ | ★★★ | ★★★ | |
| コーディング能力 | ★★★ | ★★☆ | ★☆☆ | |
| アーキテクチャ設計力 | ★★☆ | ★★★ | ★★★ | |
| チームビルディング・採用力 | ★☆☆ | ★★★ | ★★★ | |
| 技術的負債の管理 | ★☆☆ | ★★☆ | ★★★ | |
| 外部発信・ブランディング | ★☆☆ | ★★☆ | ★★★ | |
| 経営・ビジネス理解 | ★☆☆ | ★★☆ | ★★★ | |
| 技術ビジョンの明確さ | ★★★ | ★★★ | ★★★ | |
| ADR・ドキュメント文化 | ★☆☆ | ★★☆ | ★★★ |
技術評価の落とし穴
VCが技術評価で陥りがちなミスは3つある。
(1) バズワード技術を使っているだけで高評価してしまう
生成AI、ブロックチェーン、マイクロサービス——トレンドの技術を使っているだけで高評価するのは危険だ。重要なのは「なぜその技術を選んだか」の合理性であり、目的なく最新技術を採用しているスタートアップは、コストが高く意思決定が遅くなるリスクがある。最新技術に飛びついた会社が2年後に後悔するパターンは珍しくない。
(2) CTOの言葉を鵜呑みにし、コードを見ない
「スケーラブルなアーキテクチャです」という説明は誰でもできる。実際にGitHubのコミット履歴、コードレビューの文化、テストカバレッジを確認することが必要だ。シリーズAからBでは、外部の技術アドバイザーを使ったコードレビューを検討すべきだ。
(3) 早すぎる段階でスケーラビリティを要求する
シードのスタートアップに「100万ユーザー対応できますか?」と問うのは的外れだ。この段階でスケーラビリティを追求すると、PMFを見つける前にエンジニアリングリソースを消耗する。評価基準は常にステージに応じた「適切な水準」である必要がある。
よくある質問
Q. VCはスタートアップの技術力をどう評価しますか?
ステージによって重点が異なります。シードではCTOの技術力と経験、シリーズAではプロダクトの技術的実現性、シリーズBではスケーラビリティとエンジニアリング組織の成熟度を重点的に評価します。M&AのTech DDが減点法であるのに対し、VCの技術評価は「この技術が市場を取れるか」という加点法の側面が強いのが特徴です。
Q. シードステージでコード品質は重視されますか?
シードではコード品質やアーキテクチャの完成度は重視されません。それよりもCTOの問題解決能力、技術的ビジョンの明確さ、プロトタイプの実装速度が重要な評価ポイントです。「動くプロトタイプがある」「技術スタック選定に根拠がある」という2点を満たせていれば、シードのTech DDとしては十分なケースが多いです。
Q. スタートアップがVC評価に備えるべき技術的な準備は?
技術的意思決定の記録(ADR)、シンプルなアーキテクチャ図、主要メトリクスの計測(デプロイ頻度、障害復旧時間等)を準備しておくことが推奨されます。ステージに応じた適切な水準の技術管理を示すことが重要で、シードなら「なぜこの技術を選んだか」を語れること、シリーズAなら技術的負債の把握と管理計画、シリーズBならスケーラビリティの実績データが有効です。
まとめ――技術評価は「ステージに合った眼鏡」で見る
全ステージに共通する唯一の評価基準があるとすれば、「この技術チームは学習し適応できるか」だ。市場・技術・組織の変化に対応し続けられるチームかどうかは、シードからIPOまで一貫して重要な問いとなる。
- シードでは人・ビジョン、シリーズAではプロダクト実現性、シリーズBではスケール・組織を重点的に評価する
- バズワード技術の採用より、技術選定の合理的な根拠を重視する
- 早すぎる段階でスケーラビリティを要求しない。ステージに合った基準で評価する
- CTOの技術力だけでなく、採用力・外部発信力・ビジネス理解度もステージが上がるほど重要になる
- ADRや技術ドキュメントの有無は、エンジニアリング文化の成熟度を示す強いシグナル
DE-STKのTech DDサービスでは、投資ステージに応じたスタートアップ技術評価の支援を行っています。技術的モートの構築方法やCTO評価の詳細についても合わせてご覧ください。