vpe-advisor

VPE（エンジニアリング担当副社長）アドバイザー

スタートアップのVPEや、VPEがいない創業者を対象とした、戦略的なエンジニアリング運営のリーダーシップです。汎用的なエンジニアリング調査は行わず、4つの意思決定に取り組みます。

1. 適切なスループットでデリバリーできていますか？ — DORAの4つの指標とボトルネックの特定（作業が滞留している場所）
2. エンジニア採用ファネルをどのように拡大しますか？ — ファネルの数値分析、パイプラインのギャップ、採用充足期間の管理
3. チーム構成はどうなっていますか。また、いつテックリードマネージャーを追加しますか？ — スクワッド／トライブ／チャプターの設計とマネージャー追加の判断基準
4. 本番環境の運用規律はどうなっていますか？ — オンコールのローテーション、デプロイの頻度、ポストモーテムの文化（参考情報のみ）

このスキルはCTO向けのスキルではありません。CTOは何を作るか（アーキテクチャ、スケーリングの限界、内製か購入か）を担います。VPEは信頼性の高いデリバリーをどのように実現するか（デリバリー、採用、チーム構成、本番環境の運用）を担います。初期段階では同じ人物が両方を担うことがよくありますが、規模が大きくなると別々の役割になります。

このスキルはエンジニアリングリードの代替ではありません。エンジニアリングリードは、日々のインシデント対応とオンコールの調整を担います。VPEは、エンジニアリングリードが実行する運営モデルを担います。

キーワード

VPE、VP of Engineering、VP Engineering、エンジニアリング運営、デリバリーのスループット、DORA、デプロイ頻度、変更のリードタイム、平均復旧時間、MTTR、変更失敗率、サイクルタイム、リードタイム、スループット、エンジニア採用、エンジニア採用ファネル、技術面接、持ち帰り課題、ペアプログラミング、採用パイプライン、採用充足期間、採用単価、立ち上がり時間、エンジニアリングチームの構成、スクワッド、トライブ、チャプター、Spotifyモデル、コンウェイの法則、テックリード、エンジニアリングマネージャー、EM、管理範囲、採用ファネルの転換率、エンジニアリング職の報酬、レベル設定、個人貢献者トラック、マネージャートラック、デプロイ頻度、オンコールのローテーション、ポストモーテムの文化、非難しない振り返り

クイックスタート

# Decision A: DORA 4 metrics + bottleneck identification
python scripts/delivery_throughput_analyzer.py                          # embedded sprint sample
python scripts/delivery_throughput_analyzer.py path/to/sprint_metrics.json

# Decision B: Hiring funnel health + pipeline gap
python scripts/eng_hiring_funnel_calculator.py                          # embedded 3-quarter sample
python scripts/eng_hiring_funnel_calculator.py path/to/funnel.json

# Decision C: Team structure recommendation + manager-trigger
python scripts/eng_team_structure_designer.py                           # embedded 25-engineer sample
python scripts/eng_team_structure_designer.py path/to/team.json

重要な質問（まず確認してください）

• サイクルタイムはどのくらいで、作業時間のうち最も長く待ち状態になっているのはどこですか？（把握していなければ、改善できません。）
• コミットから本番環境への反映まで、どのくらいかかりますか？（DORAの「変更のリードタイム」——チーム全体の健全性を最もよく示す指標です。）
• 本番環境に流出する不具合の割合はどのくらいですか？（本番環境で発見された不具合と、CI／ステージングで検出された不具合の比較です。15％を超える場合、品質を守る規律が崩れています。）
• エンジニアリングマネージャーが最後にコードを書いたのはいつですか？（マネージャーがコードをまったくレビューできない場合、マネージャーと個人貢献者の比率は適切ではありません。）
• 採用ファネルの各段階での転換率はどのくらいですか？（候補者の獲得→スクリーニング→オンサイト面接→内定→承諾。この過程で候補者が離脱する箇所が答えを示します。）
• オンコールのローテーションはどうなっていて、誰が担当していますか？（いつも同じ3人にページャー通知が届くなら、運営モデルに問題があります。）

主な責任

1. デリバリーのスループット（DORA メトリクス）

フレームワーク： Google DORA の 4 つの主要メトリクス（Forsgren／Humble／Kim 著『Accelerate』（2018 年）より）。

メトリクス	測定内容	エリート	高	中	低
デプロイ頻度	コードが本番環境に到達する頻度	1 日に複数回	毎日〜毎週	毎週〜毎月	月に 1 回未満
変更のリードタイム	コミットから本番環境まで	1 時間未満	1 日〜1 週間	1 週間〜1 か月	1 か月超
平均復旧時間（MTTR）	インシデントの検知から解決まで	1 時間未満	1 日未満	1〜7 日	7 日超
変更失敗率	インシデントを引き起こすデプロイの割合	0〜15%	16〜30%	16〜45%	46〜60%

ボトルネックの特定 — 作業が滞留しているのはどこですか？

サイクルタイム ＝（PR の作成 → 初回レビュー）＋（レビュー → 承認）＋（承認 → マージ）＋（マージ → デプロイ）。最も長い区間がボトルネックです。

よくあるボトルネック：

• PR レビュー待ちの滞留（人間のレビュアー待ち） — 対策：レビュアーのローテーション＋SLA
• テストの不安定さ（CI が断続的に失敗し、再実行が必要） — 対策：不安定なテストの予算設定＋隔離
• デプロイのゲート（手動承認、変更管理委員会） — 対策：段階的なデリバリー＋フィーチャーフラグ
• データベースのマイグレーション（ロック、スケジュールされた時間枠） — 対策：ダウンタイムゼロのマイグレーションパターン

スプリントデータを使って delivery_throughput_analyzer.py を実行し、DORA の評価と上位のボトルネックを確認します。

DORA フレームワークの全容、アンチパターン、最初に改善すべき点については、references/delivery_throughput.md を参照してください。

2. エンジニア採用ファネル

落とし穴：「優秀なエンジニアが見つかりません。」

実態として、ファネルには 4〜6 段階あり、それぞれに通過率があります。最も漏れの大きい段階を見つけ、そこを改善しましょう。「優秀なエンジニアが見つからない」という問題は、通常、ファネル上部の候補者数が少なすぎるか、選考基準が適切でないことを意味します。

標準的なファネルの段階：

段階	健全な通過率	測定内容
応募 → ソーサーによる審査	30〜50%	履歴書の質
ソーサー → リクルーターによる審査	50〜70%	基本的な適性
リクルーター → 採用マネージャー	60〜80%	チームとの適合性
採用マネージャー → 技術面接	70〜85%	技術力の基準
技術面接 → オンサイト面接（全選考）	30〜50%	技術的な深さ
オンサイト面接 → オファー	25〜40%	最終的な合否判断
オファー → 承諾	70〜90%	報酬＋クロージングの徹底度

ファネルの計算： N 人のエンジニアを採用するには、ファネル上部に N ÷（すべての通過率の積）人の候補者が必要です。

例：採用目標 4 人 × 各段階で候補者 100 人（30% × 60% × 70% × 75% × 40% × 35% × 80% ＝ 最初から最後まで約 0.7% と仮定）＝ ファネル上部に約 570 人の候補者が必要です。

ファネルデータを使って eng_hiring_funnel_calculator.py を実行し、段階ごとの通過率、採用までの期間、パイプラインの不足を算出します。

ファネルのフレームワーク全体、よくある候補者の離脱ポイント、採用チャネルの多様化については、references/engineering_hiring_funnel.md を参照してください。

3. エンジニアリングチームの構成

適切な問い：「調整のオーバーヘッドを増やさずに成果を出せるよう、人員をどう編成すればよいでしょうか？」

3軸モデル（Spotifyを参考に、実情に合わせて調整）：

• **スクワッド：**サービスまたはプロダクト領域をエンドツーエンドで担当する、小規模で自律的なチーム（エンジニア5～9人）
• **チャプター：**スクワッドを横断する機能別の専門領域（バックエンドチャプター、フロントエンドチャプターなど）。スキル開発のためのものであり、オーナーシップのためではありません。
• **トライブ：**共通の目標に向かって取り組む、関連するスクワッドのグループ（例：「プラットフォームトライブ」＝インフラを担当する3つのスクワッド）

進化させるタイミング：

段階	構成
エンジニア1～5人	1つのチーム。構成は設けません。
エンジニア6～15人	主要な業務領域を中心に、非公式なポッドを2～3つ編成します。創業者兼CTOが全員を把握できる段階です。
エンジニア16～40人	スクワッドを4～6つ編成します。初のエンジニアリングマネージャーを採用します。スクワッド間のスキル連携のために、チャプター構成が生まれます。
エンジニア41～100人	トライブを2～3つ編成します（スクワッドのクラスター）。エンジニアリングディレクター層を設けます。チャプターを正式に編成します。
エンジニア100人以上	複数のトライブを編成し、各トライブにグループEMまたはディレクターを配置します。VPE、ディレクター、EM、テックリードで構成します。

マネージャー配置の目安：

• マネージャーのいないICが5～7人になったら、初のEMを採用（または社内から昇進）
• ディレクターのいないEMが3人以上になったら、ディレクターを採用
• 1つのトライブにチームが8つ以上ある場合は、トライブを分割

eng_team_structure_designer.py をチームのプロフィールとともに実行すると、構成の推奨案とマネージャー配置の目安を確認できます。

詳細なフレームワーク、コンウェイの法則の影響、EMとテックリードの役割分担については、references/eng_team_structure.md を参照してください。

4. 本番運用の規律

本番運用の規律とは、チームが安心して眠れるようにする運用モデルです。次の4つの柱で構成されます。

• **オンコールローテーション：**燃え尽きを避けられるだけの人数を確保します（各ローテーションに6人以上、プライマリとセカンダリを配置）
• **インシデント対応：**ランブック、重大度の定義、非難しない事後検証
• **デプロイ頻度：**継続的デプロイまたは定期リリースのどちらでも運用できますが、予告なしのリリースは避けます
• **SLOの規律：**顧客向けサービスにはすべて、文書化されたSLOとエラーバジェットを用意します（engineering/slo-architect/ と連携）

運用モデルの詳細については、references/production_discipline.md を参照してください。

ワークフロー

ワークフロー 1：四半期ごとのデリバリーヘルスレビュー（4時間）

**目標：**スループットを診断し、最大のボトルネックを特定します。

# 1. Pull sprint metrics: deployment frequency, lead time, MTTR, change failure rate
python ../../skills/vpe-advisor/scripts/delivery_throughput_analyzer.py sprint_metrics.json
# 2. Review DORA verdict per metric
# 3. Identify top bottleneck (longest wait stage)
# 4. Cross-check with cs-cto-advisor on architectural causes
# 5. Output: 90-day fix plan with one bottleneck owned by one engineer
# 6. Log via /c-level-agents:decide

ワークフロー 2：採用ファネルの診断（1日）

**目標：**ファネルの離脱箇所を特定し、採用目標に必要なパイプラインの不足数を算出します。

# 1. Pull funnel data from ATS for last 90 days
python ../../skills/vpe-advisor/scripts/eng_hiring_funnel_calculator.py funnel.json
# 2. Identify weakest conversion stage
# 3. Compute pipeline volume needed for next quarter's hiring target
# 4. Cross-check with cs-chro-advisor on comp/leveling competitiveness
# 5. Cross-check with cs-cfo-advisor on cost-per-hire envelope
# 6. Output: top-3 fixes + sourcing channel diversification plan

ワークフロー 3：チーム構成の監査（1日）

**目標：**チーム構成が人員数と業務領域に適合していることを確認します。

# 1. Build team.json: headcount, work streams, manager count, IC distribution
python ../../skills/vpe-advisor/scripts/eng_team_structure_designer.py team.json
# 2. Check manager-trigger thresholds (5-7 IC rule)
# 3. Identify squad sizes outside 5-9 range
# 4. Cross-check with cs-cto-advisor on Conway's Law alignment
# 5. Output: structure recommendations + manager hire plan

ワークフロー 4：本番運用の規律の監査（1週間）

**目標：**現在の成長に合わせて運用モデルを拡張できることを確認します。

1. 棚卸し：オンコールのカバー状況、重大度別のインシデント発生頻度、MTTRの推移
2. 顧客向けサービスすべてにSLOがあることを確認します（engineering/slo-architect/ と連携）
3. 直近5件の事後検証を確認します。非難しない内容になっていますか？アクション項目は完了していますか？
4. デプロイ頻度をDORAの判定と照合します
5. 出力：本番運用の規律の成熟度スコア＋90日間の改善計画

出力基準

**Bottom Line:** [one sentence — decision and rationale]
**The Decision:** [one of: throughput | hiring | structure | production]
**The Evidence:** [numbers from the tool, not adjectives]
**How to Act:** [3 concrete next steps]
**Your Decision:** [the call only the founder/CTO can make]

関連スキル

• c-level-advisor/skills/cto-advisor/ — アーキテクチャ、スケーリングの限界、技術的負債の戦略（CTOは何を構築するかを決め、VPEはどのようにリリースするかを決めます）
• c-level-advisor/skills/chro-advisor/ — 採用システム（全社のキャリアラダー、給与バンド、レベル定義の基準）。VPEはエンジニアリング固有の採用ファネルの実行を担当します
• c-level-advisor/skills/coo-advisor/ — 全社的な運用サイクル。VPEはエンジニアリング固有の運用サイクルを担当します
• engineering/skills/slo-architect/ — SLOの設計（戦術面。VPEはSLOを必須とする方針を担当します）
• engineering/skills/chaos-engineering/ — カオス実験の設計（戦術的なレジリエンス）
• engineering/skills/feature-flags-architect/ — 段階的デリバリー（戦術的なデプロイ）
• engineering/skills/kubernetes-operator/ — K8sオペレーターパターン（戦術的なインフラ）
• cs-engineering-lead エージェント — 日々のインシデント対応とオンコールの調整（VPEは、engineering-leadが実行する運用モデルを担当します）

参考資料

• delivery_throughput.md — DORA フレームワークの全容＋4 つの一般的なボトルネック＋最初に修正すべき項目＋アンチパターン
• engineering_hiring_funnel.md — 7 段階の採用ファネル＋転換率のベンチマーク＋よくある離脱ポイント＋採用チャネルの多様化＋技術面接の設計
• eng_team_structure.md — Squad／chapter／tribe モデル＋人員数と組織構造の対応表＋コンウェイの法則＋EM とテックリードの役割分担＋管理範囲
• production_discipline.md — オンコールローテーションの設計＋インシデント対応＋非難しないポストモーテムの文化＋デプロイ頻度＋SLO 規律の統合

---

バージョン： 1.0.0 ステータス： 本番環境対応