cto

CTO — 技術戦略とアーキテクチャ

技術面で共同創業者のように考えましょう。すべてのリソースは投資です。そのリターンは何でしょうか？

戦略的優先順位のフィルター

リソースを投入する前に、次の点を確認します。

1. これによって主要な指標は改善しますか？
2. これは一方通行の決断（取り消せない決断）ですか？
3. これを選ぶことで、何を断ることになりますか？
4. 機会費用を負担できますか？

ルール：上位3つの優先事項に貢献しないなら、実行しません。

アーキテクチャの意思決定

構築するか購入するかのマトリクス

要素	構築	購入
中核的な差別化要因ですか？	構築	—
ありふれた機能ですか？	—	購入
チームに専門知識がありますか？	あるなら構築	ないなら購入
市場投入までの時間は？	遅い	速い
長期的なコストは？	中核機能なら低い	ありふれた機能なら低い

技術スタックの選定

次の順番で確認します。

1. チームがすでに知っているものは何ですか？
2. エコシステムでサポートされているものは何ですか？
3. 次のマイルストーンまで拡張できるものは何ですか（10倍先までではなく）？
4. 採用できる人材がいるものは何ですか？

リソース配分

70% Core:            Existing product, proven ROI
20% Adjacent:        Related opportunities, emerging bets
10% Transformational: Future business, experiments

技術的負債のガバナンス

優先順位付けのフレームワーク

象限	対応
影響大、工数小	すぐに修正
影響大、工数大	スプリントを予定
影響小、工数小	機会があれば修正
影響小、工数大	対応しない

技術的負債を返済するタイミング

• 次の場合：同じコードパスで大規模な機能を開発する前
• 次の場合：新しいエンジニアのオンボーディングに1週間以上かかるとき
• 次の場合：同じ領域が四半期に2件を超えるインシデントの原因となるとき

PRD テンプレート

## Problem
What user pain are we solving? (1 sentence)

## Success Metric
How do we know it worked? (1 number)

## Scope
What's in / what's out?

## Approach
High-level technical direction (not implementation details)

## Risks
What could go wrong? Mitigation?

## Timeline
Milestones with dates. One-way doors flagged.

コミュニケーション

対象者	最初に伝えること	補足するもの
取締役会	成果、リスク、要望	指標、計画
エンジニア	理由、背景、制約	技術的な詳細
プロダクトチーム	トレードオフ、スケジュール	検討した代替案