vpe-advisor

vpe-advisor skill の概要

vpe-advisor の用途

vpe-advisor は、スタートアップのエンジニアリングリーダー、創業者、暫定的な経営・技術責任者に向けた、VP of Engineering 視点の運営アドバイス skill です。デリバリーのスループット、採用ファネルの健全性、チーム設計、本番運用の規律について、構造化された支援が必要なときに役立ちます。特に「どのアーキテクチャを選ぶべきか？」ではなく、「エンジニアリング組織として、どう出荷し、採用し、チームを組み、本番を安定運用すべきか？」を考える場面に向いています。

向いているユーザーと意思決定

vpe-advisor skill は、実務上の運営判断に直面しているチームに適しています。たとえば、スプリントのベロシティが落ちている、PR の待ち時間が長い、インシデントが繰り返し発生している、採用計画が目標に届いていない、チーム分割や Engineering Manager の追加タイミングに迷っている、といった状況です。Strategic Planning にも有用で、あいまいな組織課題を、DORA メトリクス、ファネル転換率、squad/tribe/chapter 構造、マネージャー追加のトリガー、オンコールの持続可能性、デプロイ頻度、ポストモーテム文化といった意思決定領域に落とし込めます。

汎用プロンプトとの違い

vpe-advisor は、広いリーダーシップ論を返すのではなく、4つの焦点を絞った参照ファイルと、3つの決定論的な Python ツールに基づいて提案します。参照ファイルは意思決定ロジックを説明し、スクリプトは JSON 入力からデリバリーのスループット、採用ファネルのギャップ、チーム構造の推奨を計算するためのものです。そのため、通常の「VP Engineering として振る舞って」というプロンプトよりも、運営面の足場が明確です。

インストール前に理解しておきたい境界

vpe-advisor は、CTO、アーキテクチャ、プロダクト戦略、HR コンプライアンスの skill ではありません。Conway’s Law やその運営上の含意については扱えますが、アーキテクチャの責任範囲は別にあります。また、デプロイ回数、リードタイム、インシデント、ファネル各段階の件数、人数、マネージャー数、業務ストリームの複雑さなど、ある程度正確な入力に依存します。意見だけを渡す場合は、実用的な運営計画ではなく、方向性レベルの助言になると考えてください。

vpe-advisor skill の使い方

vpe-advisor のインストールと最初に確認すべきファイル

skill manager を使って、リポジトリパスからインストールします。例:

npx skills add alirezarezvani/claude-skills --skill vpe-advisor

インストール後は、まず SKILL.md を読み、起動範囲と想定されている質問パターンを把握してください。そのうえで、実際の計画セッションで使う前に、次のファイルを確認します。

• references/delivery_throughput.md
• references/engineering_hiring_funnel.md
• references/eng_team_structure.md
• references/production_discipline.md
• scripts/delivery_throughput_analyzer.py
• scripts/eng_hiring_funnel_calculator.py
• scripts/eng_team_structure_designer.py

参照ファイルはマネジメント判断の考え方を説明し、スクリプトは入力スキーマと決定論的な閾値を示します。

vpe-advisor を効果的に使うための入力

vpe-advisor skill を有効に使うには、漠然とした不満ではなく、実際の運営データを用意してください。有用な入力には、次のようなものがあります。

• チーム規模、IC 数、EM 数、director 数、squad 数、進行中の work stream
• デプロイ頻度、リードタイム中央値、MTTR、変更失敗数、サイクルタイムの各段階
• 採用目標、ATS ファネル件数、オファー承諾率、採用充足までの中央値
• 現在のオンコールローテーション人数、インシデント頻度、デプロイモデル、ポストモーテムの習慣
• 計画期間、制約条件、いま決める必要がある判断

弱いプロンプトは「エンジニアリングチームが遅く感じます」です。より良いプロンプトは次のようになります。「We have 22 ICs, 3 EMs, 3 squads, 4 work streams, weekly deploys, 8-day median lead time, PR review wait of 30 hours, and 4 hires needed this quarter. Use vpe-advisor to identify the highest-leverage operating fix.」

付属スクリプトを実務で使う

構造化された JSON を用意できる場合、スクリプトが役立ちます。skill フォルダからローカルで実行するか、作業ディレクトリにコピーして使います。

python scripts/delivery_throughput_analyzer.py metrics.json

python scripts/eng_hiring_funnel_calculator.py funnel.json

python scripts/eng_team_structure_designer.py team.json

各スクリプトは、ファイルを渡さない場合でも埋め込みサンプルで実行できます。これはスキーマを理解するのに便利です。スクリプトの出力は、プロンプト内の根拠として使ってください。結果をチャットに貼り付け、vpe-advisor に運営上の推奨、リスク、30-60-90 日計画へ変換するよう依頼します。

Strategic Planning 向けのプロンプトパターン

Strategic Planning で vpe-advisor を使う場合は、ブレインストーミングではなく意思決定メモとして依頼を組み立てます。

“Use vpe-advisor. Context: [company stage, headcount, product pressure]. Data: [delivery, hiring, team structure, production metrics]. Decision needed: [what to change this quarter]. Constraints: [budget, hiring freeze, reliability risk, roadmap deadlines]. Output: diagnose bottlenecks, rank interventions, explain tradeoffs, and propose a 30-60-90 day operating plan.”

このプロンプトが有効なのは、あらゆるエンジニアリングマネジメント施策を列挙させるのではなく、競合する VPE レバーの中から選ぶための十分な文脈を skill に渡せるからです。

vpe-advisor skill FAQ

vpe-advisor はアーリーステージのスタートアップにも向いていますか？

はい。特に、デリバリー、採用、オンコール規律が非公式なやり方だけでは回らなくなった段階で有用です。5人のエンジニアリングチームでも、スループットや本番運用の習慣を診断する助けになります。ただし、構造に関する推奨では、あえて「まだプロセスを増やさない」と判断することもあります。

vpe-advisor を使わないほうがよい場面は？

システムアーキテクチャ、技術選定、報酬ポリシー、法的な HR プロセス、パフォーマンスマネジメントの主要ツールとして vpe-advisor を使うべきではありません。運営上の症状を特定することはできますが、ドメイン専門家、雇用法務の専門家、アーキテクチャレビューの代替にはなりません。

AI に VPE アドバイスを聞くのと何が違いますか？

通常のプロンプトは、モデルの一般知識に大きく依存します。vpe-advisor skill は、具体的な意思決定フレーム、健全な範囲、アンチパターン、スクリプトに裏付けられた計算をエージェントに与えます。これは、一般的なリーダーシップ表現ではなく、再現性のある診断が必要なときに重要です。

vpe-advisor には完璧なメトリクスが必要ですか？

いいえ。ただし、正直な概算は必要です。DORA、ATS、インシデントデータが不完全な場合は、その旨を明確にしてください。部分的なデータからでも推論できますが、推定値と実測値が分けられているほど、出力の質は高くなります。

vpe-advisor skill を改善する方法

助言を求める前に vpe-advisor への入力を整える

最もよくある失敗は、十分な運営データなしに推奨を求めることです。vpe-advisor を呼び出す前に、現在のチームトポロジー、デリバリーメトリクス、採用ファネル、インシデントとオンコールの状態、意思決定を迫っている事業上の制約を、1ページ程度のスナップショットにまとめてください。これにより、出力が汎用的なエンジニアリングリーダー向けチェックリストになるのを防げます。

推奨だけでなくトレードオフを尋ねる

VPE の仕事では、多くの場合「どの痛みを受け入れるか」を選ぶ必要があります。「add EM」「split squads」「reduce WIP」「tighten incident review」「increase sourcing volume」などの選択肢を比較させてください。強いフォローアッププロンプトには、「What is the hidden cost of this recommendation?」や「What metric should improve first if this is working?」があります。

最初の回答後は根拠を追加して反復する

最初の出力のあと、実行不可能な点、政治的に難しい点、データと矛盾する点をフィードバックしてください。例: 「We cannot hire an EM this quarter, and the platform team owns three critical services. Revise the plan using only role clarification, WIP limits, and deployment-process changes.」これにより、vpe-advisor は理想状態の組織設計ではなく、実装可能な計画を出しやすくなります。

自社の運営モデルに合わせて skill を拡張する

vpe-advisor をローカルで改善するには、自社固有のベンチマーク、インシデント重大度の定義、採用ステージ名、チームトポロジー上の制約、デプロイポリシーを追加します。追加内容は意思決定に役立つ形にしてください。自社で実際に使っている閾値、例、アンチパターンで参照ファイルを更新します。スクリプトを追加する場合は、エージェントが安定して呼び出せるよう、明確な JSON スキーマと決定論的な出力という現在のパターンを保ってください。