tech-stack-eval

技術スタックの評価

使用する場面

• 新規プロジェクトでフロントエンド／バックエンドのフレームワークやライブラリを比較する
• 特定のワークロードに適したクラウドプロバイダー（AWS と Azure と GCP）を評価する
• リスクと工数を評価しながら、技術移行を計画する
• 隠れたコストを含めて TCO を算出し、内製か購入かを判断する
• オープンソースライブラリの継続性とエコシステムの健全性を評価する

次の場合は使用しないでください：判断が単純な場合（チームの好みに従う）、技術がすでに指定されている場合、または本番環境で緊急の問題が発生している場合。

必要なコンテキスト

startup-context から取得する情報：プロダクトの種類、チームのスキル、技術スタック、フェーズ、規模、予算。また、以下も確認してください：

• どのような問題を解決しようとしていますか？（解決策ありきの考え方には異議を唱えてください）
• 譲れない要件（パフォーマンス、コンプライアンス、チームの習熟度）
• 各選択肢に対するチームの経験とスケジュールの厳しさ（期限が厳しい場合は、使い慣れたツールが有利です）
• スケーラビリティ要件に影響する成長予測

ワークフロー

1. 判断内容を明確にする — 具体的に何を決めるのか、実際の要件は何かを確認します。問題を定義する前にユーザーが技術を選んでいる場合は、異議を唱えてください。
2. 候補を特定する — 現実的な選択肢を2～4個挙げます。明らかに不適切な選択肢は早い段階で除外します。
3. 重み付けした評価基準を定義する — 以下の主要な一覧から6～8個の基準を選びます。ユーザーの優先事項に基づいて重みを割り当てます（合計＝100％）。
4. 各候補を採点する — 各基準を1～5で評価し、各スコアに1行の根拠を添えます。
5. エコシステムの健全性を評価する — GitHub の活動状況、npm/PyPI での採用状況、コミュニティの強さ、企業の支援、今後の傾向（成長、安定、衰退）を評価します。
6. TCO を算出する — コンピューティング、ストレージ、帯域幅、ライセンス、エンジニアリング時間（初期設定＋継続的な作業）、運用オーバーヘッドを含め、5年間の総コストを予測します。スタートアップでは、通常、エンジニアリング時間が最大のコストです。
7. 移行経路を分析する — 移行の場合は、工数、リスク、スケジュールを見積もり、段階的なアプローチ（ストラングラーフィグパターン）を推奨します。
8. 推奨事項を提示する — 明確な根拠と確信度を添えて、最適な選択肢を示します。曖昧さを解消するための追加質問なしに「場合によります」で済ませないでください。

出力形式

# Tech Stack Evaluation: [Decision Title]

## Decision Context — what we are choosing and why it matters
## Candidates — table: technology, version, license, one-liner
## Evaluation Criteria — table: criterion, weight, why it matters
## Scoring Matrix — table: criterion (weight), scores per option, weighted total
## Ecosystem Health — table: GitHub stars, weekly downloads, last release, open issues, major users
## TCO Estimate — table: cost category by option over 12 months or 5 years
## Security & Compliance — vulnerability history, compliance readiness (SOC 2, GDPR)
## Recommendation — clear winner, rationale, confidence level, caveats
## Migration Path (if applicable) — phased plan with timeline and rollback strategy

フレームワークとベストプラクティス

主要な評価基準

6～8個を選び、重みを割り当てます（合計＝100％）。

• パフォーマンス — 特定のワークロードにおけるスループット、レイテンシー、リソース効率
• 開発者エクスペリエンス — ツール、デバッグ、ドキュメントの品質、エラーメッセージ
• 学習曲線／チームの習熟度 — 現在のチームが生産性を発揮できるようになるまでの時間
• エコシステムとライブラリ — パッケージ、統合、サードパーティーのサポート
• メンテナンスと長期的な存続性 — リリース頻度、企業の支援、バスファクター
• 採用候補者の層 — 市場と給与帯における開発者の確保しやすさ
• スケーラビリティ — 書き直しをせずに10～100倍の成長に対応できること
• コスト／ベンダーロックイン — TCO と、後から移行が必要になった場合の切り替えコスト
• セキュリティとコンプライアンス — 脆弱性への対応実績、コンプライアンスツールの準備状況

エコシステムの健全性スコア

レベル	基準
活況	定期的なリリース（3か月未満）、採用の拡大、複数の企業スポンサー、活発なコミュニティ
安定	定期的なリリース（6か月未満）、安定した採用状況、確立されたコミュニティ、衰退の兆候なし
要注意	リリース頻度が低い（12か月超）、ダウンロード数の減少、主要なメンテナーの離脱、貢献者が少ない

TCO の算出フレームワーク

最低12か月分（インフラストラクチャの判断では5年間）を予測します。対象は、コンピューティング、ストレージ、帯域幅、ライセンス、エンジニアリング時間（初期設定＋継続的なメンテナンス時間×人件費）、運用オーバーヘッド（監視、オンコール）、隠れたコスト（トレーニング、移行ツール、二重運用）です。

スタートアップでは、通常、エンジニアリング時間が最大のコストです。 ホスティング費用を月額200ドル削減できても、運用に追加で40時間のエンジニアリング時間がかかる技術は、結果として損失になります。

移行リスク評価

リスクレベル	基準
低	追加的な変更で、データ移行は不要、並行稼働が可能、2週間未満
中	データ移行または API の変更が必要、2～8週間、段階的な移行が可能
高	中核システムの置き換え、8週間超、ダウンタイムまたは一斉切り替えが必要

ストラングラーフィグパターンを使用します。新しいトラフィックを新システムにルーティングし、旧システムは段階的に移行します。常にロールバックできる状態を維持してください。具体的な切り替え期限を設定します。移行が中途半端なシステムは最悪の結果です。

確信度

レベル	スコア	解釈
高	80～100%	明確な勝者があり、データが強固で、優位性に大きな差があります
中	50～79%	トレードオフがありますが、注意事項を踏まえても推奨案は妥当です
低	< 50%	判断が難しく、データも限られているため、決定前に概念実証を行うことを推奨します

よくある意思決定のアンチパターン

• 履歴書重視の開発 — 適合性ではなく、履歴書に書ける技術を選ぶこと
• ハイプサイクルの罠 — 安定性が証明される前に、話題性がピークの技術を採用すること
• 早すぎる最適化 — 1台の Postgres で負荷を処理できるのに、分散システムを導入すること
• サンクコストの誤謬 — 過去の投資を理由に移行を拒むこと
• チームのスキルを無視する／解決策先行の思考 — 誰も知らない技術を選ぶこと、または問題を定義する前に技術を選ぶこと

関連スキル

• architecture-design — 技術スタックの決定が、より広範なシステム設計につながる場合に連携します
• cicd-setup — 選定した技術向けに CI/CD を構成する場合に連携します

例

プロンプトの例：「SaaS ダッシュボードで React と Vue を比較してください。優先度は、開発者の生産性（40%）、エコシステム（30%）、パフォーマンス（30%）です。」

出力例：

## Scoring Matrix
| Criterion (weight)       | React | Vue  |
|--------------------------|-------|------|
| Developer Productivity (40%) | 4/5   | 4/5  |
| Ecosystem (30%)          | 5/5   | 4/5  |
| Performance (30%)        | 4/5   | 5/5  |
| **Weighted Total**       | **4.3** | **4.3** |

Confidence: Medium (55%). Scores are nearly identical. Recommendation: React,
but only because your team has 2 years of React experience (not captured in
the matrix). If the team were greenfield, Vue's developer experience gives it
a slight edge. This is close enough to warrant team preference as the tiebreaker.

プロンプトの例：「現在 Heroku を月額 2,400 ドルで利用しています。AWS に移行すべきでしょうか？」

出力例：

## TCO Estimate (12 months)
| Category             | Heroku    | AWS               |
|----------------------|-----------|-------------------|
| Compute              | $1,200/mo | $480/mo (ECS)     |
| Database             | $800/mo   | $350/mo (RDS)     |
| Add-ons              | $400/mo   | $120/mo           |
| Engineering (setup)  | $0        | $12,000 one-time  |
| Engineering (ongoing)| 2 hrs/mo  | 8 hrs/mo          |
| **Annual Total**     | **$28,800** | **$18,000**     |

Break-even at month 14. At Series A with a team of 6, wait until Heroku hits
$4,000/mo — engineering hours are better spent on product right now.