cto-advisor

cto-advisor skill の概要

cto-advisor は何に使うものか

cto-advisor は、整理されていないエンジニアリング上の懸念を、CTO レベルの構造化された判断材料に変えるためのテクニカルリーダーシップ skill です。アーキテクチャ判断、技術的負債の優先順位付け、エンジニアリング指標、技術評価、チーム拡大、戦略計画などに向いています。単なるコードレベルの助言ではなく、選択肢ごとのトレードオフ、実行順序、経営層にも説明できる理由付けが必要な場面で特に役立ちます。

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

cto-advisor skill は、何を直すべきか、作るべきか、買うべきか、測るべきか、組織をどう変えるべきかを判断する必要がある創業者、CTO、VP of Engineering、スタッフエンジニア、プラットフォームリード、プロダクト志向の技術マネージャーに適しています。特に、スケーリング上のボトルネック、はっきりしないアーキテクチャ選択、積み上がった技術的負債、「12か月の技術ロードマップを作ってほしい」といったリーダーシップからの依頼など、文脈が一部しか揃っていない状況で有用です。

汎用プロンプトとの違い

通常のプロンプトでも幅広い提案は得られます。cto-advisor skill はそこに、ADR 形式の意思決定記録、DORA や生産性指標、技術評価マトリクス、技術的負債の分類、チーム拡大の計算といった、再利用しやすい CTO 向けフレームワークを加えます。実用上の価値は単なる「助言」ではありません。エンジニアリング上の曖昧さを、優先順位付きの選択肢、測定可能なリスク、次に取るべきアクションへ変換しやすくなります。

cto-advisor が最も力を発揮する領域

cto-advisor は、技術、人、コスト、信頼性、デリバリー速度にまたがる問題を扱う Strategic Planning に向いています。システムの背景、現在の制約、事業目標、障害や失敗の兆候を提示できるほど効果的です。一方で、きわめて専門的な実装デバッグ、特定ベンダー製品の深いチューニング、正式なレビューが必要な法務・コンプライアンス判断には向きません。

cto-advisor skill の使い方

cto-advisor のインストールと最初に読むファイル

skill は次のコマンドでインストールします。

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

インストール後は、まず SKILL.md を読み、起動範囲とリーダーシップ向けワークフローを理解します。そのうえで、目的に応じて次のファイルを確認してください。

• references/architecture_decision_records.md：アーキテクチャ選択と ADR の出力形式
• references/engineering_metrics.md：DORA、品質、生産性、信頼性の指標
• references/technology_evaluation_framework.md：build-vs-buy やベンダー選定
• scripts/tech_debt_analyzer.py：技術的負債のスコアリングロジック
• scripts/team_scaling_calculator.py：エンジニアリング組織の人員計画と構造設計

このリポジトリは大きなランタイムに依存しません。ただし補助スクリプトは Python ファイルなので、ローカルで実行したい場合は Python 3 を利用できるようにしておきます。

cto-advisor をより有効に使うための入力

この skill は、プロンプトに事業目標、現在のエンジニアリング状況、制約、検討中の選択肢、意思決定の期限が含まれていると最も効果を発揮します。文脈なしに「どんなアーキテクチャにすべきですか？」と聞くのは避けましょう。代わりに、判断の前提となる要因を提示します。

より強いプロンプト例：

Use cto-advisor to evaluate whether our SaaS platform should move from a modular monolith to services. Current team: 18 engineers, 2 platform engineers, weekly deploys, 99.5% uptime target, PostgreSQL bottlenecks, customer growth from 200 to 1,000 accounts in 12 months. Constraints: 6-month roadmap, limited DevOps capacity, compliance audit in Q3. Produce an ADR-style recommendation with options, risks, migration phases, and metrics to track.

これにより、流行りのアーキテクチャ助言に流れるのではなく、トレードオフを踏まえて判断するための十分な情報を skill に与えられます。

意思決定のための実践ワークフロー

多くのリーダーシップ判断では、次の 4 ステップで進めると扱いやすくなります。

1. 意思決定を定義する：問題、事業上の成果、時間軸、譲れない制約を明確にします。
2. 構造化された分析を依頼する：意思決定の種類に応じて、ADR、技術評価マトリクス、負債解消計画、チーム拡大モデル、メトリクスダッシュボードを依頼します。
3. 前提を検証する：出力が、インシデント頻度、デプロイデータ、チームのスキル、コスト見積もりなど、未検証の事実に依存していないか確認します。
4. アクションへ変換する：30/60/90 日計画、担当者、マイルストーン、リスク、測定可能な成功基準を求めます。

技術的負債を扱う場合は、scripts/tech_debt_analyzer.py を実行または確認し、アーキテクチャ、コード品質、インフラ、セキュリティ、パフォーマンスの各カテゴリがどのように重み付けされているかを理解してください。チーム拡大を検討する場合は、提案された職種比率をそのまま受け入れる前に scripts/team_scaling_calculator.py を確認します。

ジョブ別プロンプト例

技術的負債の場合：
Use cto-advisor to prioritize technical debt across architecture, infrastructure, security, and performance. Our main pain points are manual deployments, low test coverage, slow queries, and outdated dependencies. Create a severity-ranked remediation plan with business impact, effort, dependencies, and first 3 actions.

技術評価の場合：
Use cto-advisor to compare Kafka, RabbitMQ, and managed cloud queues for event-driven order processing. Include functional requirements, non-functional requirements, TCO, operational burden, team expertise, exit risk, and a scoring matrix.

エンジニアリング指標の場合：
Use cto-advisor to design an engineering metrics dashboard for a 35-person product engineering org. Include DORA metrics, quality indicators, reliability metrics, measurement method, target ranges, and behaviors to avoid incentivizing.

cto-advisor skill FAQ

cto-advisor は初心者にも向いていますか？

はい。完成された経営戦略ではなく、意思決定のフレームワークが必要な場合には向いています。初心者は、用語の定義、例、段階的な理由付けもあわせて依頼するとよいでしょう。ただし、最終的な提案は、対象システム、組織、事業上の制約を理解している人が必ず確認する必要があります。

cto-advisor を使うべきでない場面は？

セキュリティ承認、法務・コンプライアンス判断、財務予測、本番アーキテクチャの正式承認における最終判断者として cto-advisor を使うべきではありません。分析を構造化し、トレードオフを可視化し、意思決定記録のドラフトを作ることはできますが、実際の意思決定はシステムデータ、関係者の入力、専門家レビューによって検証されるべきです。

cto-advisor はアーキテクチャ skill とどう違いますか？

アーキテクチャ専用の skill は、通常システム設計に焦点を当てます。cto-advisor skill は、アーキテクチャをより広いリーダーシップ判断の一部として扱います。ロードマップとの整合、チームキャパシティ、技術的負債、デリバリー指標、採用への影響、コスト、リスク、ガバナンスまで含めて検討します。そのため、単独の設計図を作る用途よりも、部門横断の計画づくりに向いています。

小規模チームやスタートアップにも合いますか？

はい。小規模チームは、過剰設計を避ける、build-vs-buy を比較する、採用計画を立てる、どの負債を許容するかを決める、といった用途で活用できます。重要なのは、スタートアップ特有の制約を明確に書くことです。具体的には、ランウェイ、チーム規模、顧客対応の緊急度、運用上どこまで許容できるか、何をシンプルなまま保つ必要があるかを示します。

cto-advisor skill を改善する方法

より明確な文脈で cto-advisor の出力を改善する

cto-advisor の結果を最も早く改善する方法は、曖昧な目標を、意思決定に使える文脈へ置き換えることです。現在のチーム規模、アーキテクチャ、デプロイ頻度、インシデント履歴、コスト上限、顧客成長、コンプライアンス要件、既知の制約を含めてください。指標がない場合は、そのことを明記し、判断前にどのデータを集めるべきかを skill に特定させます。

注意すべき失敗パターン

主なリスクは、チームの実行能力に対して理想化されすぎた提案を受け取ることです。現在持っている以上のプラットフォーム成熟度、自動化、人員、予算を前提にしている計画には注意してください。また、事業課題との結び付きがないまま、マイクロサービス、重いガバナンス、広範なメトリクスプログラムを勧める出力も疑って確認すべきです。

戦略から実行へ反復する

最初の出力を得たら、優先順位付けを強制するフォローアップ質問をします。

• What assumptions would change this recommendation?
• What is the smallest reversible next step?
• Which option is best if we optimize for 6-month delivery speed?
• Which risks need executive approval?
• Turn this into an ADR with negative consequences included.

これにより、cto-advisor の利用は一度きりの提案ではなく、意思決定ワークフローになります。

リポジトリ内のフレームワークとスクリプトで検証する

回答を採用する前に、同梱されている reference をチェックリストとして使ってください。アーキテクチャ提案は references/architecture_decision_records.md と、メトリクス提案は references/engineering_metrics.md と、ベンダー比較は references/technology_evaluation_framework.md と照合します。定量的な計画では、生成された数値を権威あるものとして扱うのではなく、Python スクリプトを確認または調整して使ってください。