ソースコードを見ずに技術力を見抜く方法

ソースコードを読まなくても、技術組織の実力は評価できます。それどころか、コード以外の情報の方が組織の実態を正確に映すことが多いです。

ソースコードを財務諸表で読む

技術組織の評価に財務の枠組みを当てはめると、情報の役割が整理しやすくなります。

ソースコード ＝ バランスシート（B/S）。今まで積み上げてきた技術資産と技術負債の状態を映します。コードの品質・構造・規模は、その組織がこれまでどのような判断を積み重ねてきたかの結果です。しかし B/S 単体では「今どれだけ稼いでいるか」はわかりません。

開発プロセスのフロー情報 ＝ 損益計算書（P/L）。PR のマージ頻度・デプロイ速度・コミット頻度・バグ修正サイクルは、技術組織が「今この瞬間にどれだけの速度で価値を生み出しているか」を示します。財務でいえば営業利益率に相当し、組織の現在の生産性を直接映します。

コードレビューだけに頼るのは、B/S しか読まずに投資判断をするようなものです。P/L に相当するフロー情報を合わせて読むことで、はじめて技術組織の全体像が見えます。

B/S と同様、コードの読み方は文脈で変わる

財務において B/S の数値を単独で判断できないように、ソースコードの状態も事業フェーズや組織規模を踏まえて解釈する必要があります。

スタートアップ（CTO + 数人のチーム）でコードが粗削りな場合、必ずしも危険信号ではありません。財務でいえば、意図的に負債を使ってレバレッジをかけ成長を加速させている状態です。技術負債を積みながら市場検証を優先している場合、P/L に相当する開発速度（デプロイ頻度・機能リリースペース）が高ければ、合理的な判断として評価できます。重要なのは「なぜそうなっているか」を経営チームが認識しているかどうかです。

大規模チーム（エンジニア20〜50名）で同じコードの粗さがある場合、意味は大きく変わります。負債の総量が組織の処理能力を超えている状態——財務でいえば実質的な債務超過——の可能性が高いです。誰もコードベース全体を把握しておらず、P/L に相当する開発速度も低下し始めているケースが多いです。

「コードが汚い＝技術力が低い」という一元的な判断は、「負債比率が高い＝悪い企業」という誤解と同じ構造です。評価は常に、事業フェーズ・チーム規模・戦略意図とセットで行う必要があります。

「コードを見せてもらわないと技術力はわからない」という思い込みが、技術DDを「エンジニアにしかできない作業」にしています。これは誤解です。本稿では、非エンジニアの投資家・M&A担当者でも実施できる技術力の評価フレームワークを整理します。記事末尾には、ページ上でその場に使えるインタラクティブな診断ツールも掲載しています。

なぜソースコード以外の情報が重要か

コードレビューには本質的な限界があります。

限界1：スナップショットしか見えない

コードは「今この瞬間の状態」を映すだけです。6ヶ月前に書かれたコードが今も動いているのか、それとも先週書き直されたのかは、コードを読んでも判断できません。組織が「良いコードを書ける」のか、それとも「良いコードが書けるエンジニアが先週退職して今は残骸だけ」なのかも区別できません。

限界2：なぜその判断をしたかが見えない

良いコードと悪いコードを区別することはできても、なぜそのアーキテクチャを選んだか、なぜその技術スタックになったか、技術負債を認識しているのかしていないのかは、コードからは読み取れません。意思決定の質は、コードではなくプロセスと会話に現れます。

限界3：組織の実態が見えない

1人の天才エンジニアが書いた美しいコードも、10人の平均的なエンジニアが協調して書いたコードも、コードそのものからは区別がつきにくいです。しかし投資・買収の文脈では、組織として再現可能な技術力があるかどうかが重要です。

コードを読まないのではなく、コード以外の情報を優先して読む——これが非エンジニアによる技術評価の基本姿勢です。

開発プロセスから読み取る技術力

GitHubやGitLabのリポジトリへのアクセスが得られれば、コードを読まなくても多くのことがわかります。主に確認すべきは3つの指標です。

1. PRのパターン

プルリクエスト（PR）は「コードレビューの現場」であり、技術組織の文化がそのまま可視化されます。

レビューコメントが「LGTM」1行だけで埋め尽くされているリポジトリは危険信号です。形式的なレビューは行われているものの、実質的な品質チェックが機能していない可能性が高いです。

2. デプロイ頻度とコミット頻度

最近30〜90日のコミット履歴・デプロイ記録から、組織の実際の開発速度がわかります。評価の視点は2点あります。

① 頻度の一貫性：毎日コミットが積まれているか、それとも特定の日に数百コミットがまとめてpushされているか。後者の場合、コード管理が属人化している可能性があります。

② 頻度のトレンド：3ヶ月前と比べてコミット頻度が増えているか、減っているか。技術負債が蓄積されて開発速度が落ちている組織は、コミット頻度が徐々に低下する傾向があります。

3. Issueとバグ報告の管理状態

Issueトラッカーの状態は、組織の課題管理能力を映します。

観察ポイント	健全なシグナル	要注意なシグナル
Issueの件数	適度にオープン・クローズされている	何百件もオープンのまま放置
優先度の付け方	ラベル・マイルストーンで整理されている	優先度付けなく積まれている
バグの解決速度	クリティカルなものは数日以内に対応	数ヶ月前のバグが未対応のまま
リグレッション	同じ問題が繰り返し発生していない	同じバグが複数回報告されている

ドキュメントと障害履歴から読み取る技術力

コードより雄弁なのが、ドキュメントと過去の障害への対応履歴です。

ドキュメントが映す組織の成熟度

「ドキュメントがない」という事実そのものが評価の材料になります。成熟した技術組織は、新しいメンバーが自走できるようにドキュメントを整備する習慣があります。逆に、口頭伝承に頼っている組織は、キーパーソンが退職したとたんに知識が消えます。

確認すべき3種類のドキュメントと、それぞれ「どのような形式であるべきか」を示します。

① アーキテクチャドキュメント

システム全体の構成と主要なコンポーネントの関係を説明する文書です。以下のような内容が記載されているかを確認します。

# システムアーキテクチャ概要

## 全体構成
[図またはテキストでシステムの概要を記載]

## 主要コンポーネント
- フロントエンド: Next.js（Vercel）
- バックエンドAPI: Node.js / Express（AWS ECS）
- データベース: PostgreSQL（RDS）+ Redis（ElastiCache）
- 認証: Auth0

## データフロー
ユーザーリクエスト → CloudFront → ALB → ECS → RDS

## 外部依存サービス
- 決済: Stripe
- メール: SendGrid
- 監視: Datadog

## スケーラビリティの現状と課題
現在のボトルネック: DBの書き込みが単一ノード
対処計画: 2025Q3にリードレプリカを追加予定

口で説明すれば分かる」レベルでは、新メンバーのオンボーディングに数ヶ月かかります。このレベルの文書が存在しない場合は要注意です。

② ADR（Architecture Decision Records）

技術的な意思決定の記録です。「なぜそのデータベースを選んだか」「なぜマイクロサービスにしなかったか」という判断の根拠が残っているかどうかは、組織の判断の質と継続性を示します。

# ADR-012: 認証基盤にAuth0を採用する

**ステータス**: 承認済み（2024-08-15）

**背景**
ユーザー数が5万を超え、SSO・MFA対応の要望が複数顧客から来ている。
自前実装はセキュリティリスクが高く、維持コストが大きい。

**決定**
Auth0を採用する。

**選択肢と却下理由**
- Firebase Auth: Google依存が高い。マルチクラウド方針と合わない
- Cognito: AWSロックインが強まる。現在のマルチクラウド方針と合わない
- 自前実装: セキュリティ専門家が社内にいない段階での実装はリスクが大きい

**トレードオフ**
- メリット: MFA・SSO・コンプライアンス対応が早期に実現できる
- デメリット: 月額コストが増える。MAU課金のため大規模化時のコスト試算が必要

**結果の評価期限**: 2025-02-15

このような記録が蓄積されていれば、組織の技術的な判断が根拠を持って行われていることがわかります。

③ 障害対応手順書（Runbook）

本番環境でトラブルが起きたとき、誰でも対応できる手順が文書化されているかを確認します。

# Runbook: DBコネクション枯渇時の対応

**発生条件**: アラート「DB接続数 > 80%」が発火したとき

**影響範囲**: 全APIエンドポイントのレスポンス遅延・タイムアウト

**事前確認**
1. 現在のコネクション数を確認: `SELECT count(*) FROM pg_stat_activity;`
2. 長時間実行クエリを確認: `SELECT pid, query, state, query_start FROM pg_stat_activity ORDER BY query_start;`

**対処手順**
1. 原因が特定のクエリの場合: `SELECT pg_terminate_backend(pid) WHERE pid = [問題のpid];`
2. 原因が急激なトラフィック増加の場合: オートスケールが動いているか確認（AWS ConsoleのECS画面）
3. 即時解消できない場合: メンテナンスモードを有効化（手順はdocs/maintenance.mdを参照）

**エスカレーション**
30分以内に解消できない場合は [担当者] に連絡

「担当者しか対応できない」状態は、属人化の最も深刻な形態です。Runbookがなく、障害対応が特定の人物の頭の中にしかない組織は、その人物の退職で運用が崩壊するリスクがあります。

障害履歴が映すエンジニアリング文化

重大インシデントの後、ポストモーテム（事後検討）が行われているかどうかは、組織の学習能力を映します。適切に実施されているポストモーテムは、以下のような構成になっています。

# ポストモーテム: 2024-11-15 決済API 4時間ダウン

**インパクト**
- 影響期間: 2024-11-15 14:32〜18:41（4時間9分）
- 影響ユーザー: 約2,800名（決済試行が失敗）
- 売上損失: 推定 ¥3,200,000

**タイムライン**
14:32 アラート発火（エラーレート 5% 超過）
14:40 担当者が確認開始
15:10 原因特定（Stripeのwebhookエンドポイントが証明書更新後に疎通失敗）
16:00 暫定対処（証明書を旧バージョンにロールバック）
18:41 恒久対処完了・サービス全面復旧

**根本原因**
証明書の自動更新スクリプトがStipeのwebhook受信エンドポイントのパスを
更新対象から除外していなかった。

**再発防止策（担当・期限付き）**
1. 証明書更新時のwebhookエンドポイント疎通確認をCIに追加（田中 / 11月末）
2. Stripeとの疎通を監視するヘルスチェックを追加（鈴木 / 12月第1週）
3. 証明書更新の事前テスト手順をRunbookに追記（山田 / 11月末）

**学び**
外部APIとの疎通確認は証明書更新の影響範囲として明示的に検討すべき。

確認すべきポイントは3つです。

1. 再発防止策が具体的か：「気をつける」「確認する」では再発防止になりません。「自動テストを追加した」「Runbookに手順を追記した」という構造的な対処が担当者・期限付きで記録されているかどうかが重要です。

2. 同じ問題が繰り返されていないか：過去2年分の障害報告に、同じ種類のインシデントが複数回登場していないかを確認します。繰り返すということは、根本対処ができていない証拠です。

3. 障害の粒度が適切か：小さな障害でも記録されているか、大きな障害しか記録されていないかで、組織の障害に対する感度がわかります。

エンジニアとの会話で使う5つの質問

ここまでの情報収集を踏まえた上で、エンジニア（特にCTOやテックリード）との面談では以下の5つの質問を使います。目的は「正解を確認する」ことではなく、「思考プロセスの健全さを観察する」ことです。

質問① 今すぐ直したい技術的な問題は何ですか？

この質問への回答が「特にないです」「全体的にうまく動いています」であれば、課題認識がないか、正直に話していないかのどちらかです。どんな技術組織にも改善したい問題は存在します。即座に2〜3つ具体的に挙げられるCTOは、現場の実態を把握しています。

健全な回答例：「DBのクエリパフォーマンスが特定のページで遅くなっていて、N+1問題が残っています。優先度を上げて来週から対処予定です」

質問② ユーザー数が現状の10倍になったら、システムのどこが詰まりますか？

「大丈夫です」「スケーラブルな設計にしています」という回答は避けたいものです。真に優れたエンジニアは、自分たちのシステムのボトルネックを正確に把握し、それに対処する計画を持っています。

健全な回答例：「認証サーバーが先に詰まります。現在のアーキテクチャだと水平スケールしにくい設計になっているので、ステートレス化を半期のロードマップに入れています」

質問③ 過去の技術選定で後悔している判断はありますか？

失敗を語れるかどうかは、学習能力と誠実さの両方を測ります。失敗を語れないCTOは、問題を認識していないか、表面的な回答しかしないかのどちらかです。具体的な失敗と、そこから何を学んだかを語れるエンジニアは信頼できます。

質問④ エンジニアの採用で最も重視するのは何ですか？

「優秀な人材」「問題解決能力」という一般論ではなく、具体的な採用基準が語れるかどうかを見ます。「モノリスからマイクロサービスに移行する際に必要なスキルセットがあること」「ドキュメントを書く文化に馴染める人」といった具体性が、採用思想の成熟度を示します。

質問⑤ 技術負債をどう管理していますか？

「技術負債はない」という回答は即座に要注意サインです。「技術負債リストを持っていて、新機能開発とのバランスで四半期ごとに優先度を再評価しています」という回答は、負債を認識し管理している成熟した組織を示します。