senior-system-architecture

シニアシステムアーキテクチャ

使用する場面

• サービスやシステムをまたぐ境界と契約を定義またはレビューする
• アーキテクチャの選択肢を、トレードオフとNFRへの影響を明示して比較する
• 変更が難しい決定について、ADRを作成またはレビューする
• 大規模なローンチやベンダーとの契約前にアーキテクチャレビューを実施する
• レガシーシステムからの移行を計画する（ストラングラー、並行稼働、切り替え）
• アーキテクチャの原則、標準、例外対応プロセスを確立する

使用しない場面

• 単一チームのサービスRFCや実装範囲の策定 → senior-software-engineer
• レイクハウス、メッシュ、エンタープライズデータモデリング → data-architect
• VPC、Kubernetes、Terraform、CI/CDの構築 → infrastructure-engineer, devops
• IDP、ゴールデンパス、Backstage → platform-engineer
• マイルストーン、RAID、ステアリング状況 → technical-program-manager
• リリース切り替えの戦術のみ → deployment-strategist
• セキュリティ管理策カタログやエンタープライズGRC → cybersecurity
• LLM/RAGシステム設計 → ai-engineer
• ビジネス戦略、課題ツリー、運営委員会向けのケース → business-consultant
• 応用AI／LLMソリューションアーキテクチャ → applied-ai-architect-commercial-enterprise
• 顧客向けソリューション設計、RFP/RFI、PoCの範囲、商談の統合 → solutions-architect

関連スキル

ニーズ	スキル
サービスレベルのRFCとコードレビュー	senior-software-engineer
データドメインとガバナンスのアーキテクチャ	data-architect
クラウドソリューションと移行のアーキテクチャ	cloud-architect
エンタープライズクラウドガバナンスとランディングゾーン	enterprise-cloud-architect
クラウド／ネットワーク／IaCの提供	infrastructure-engineer, cloud-engineer
プロダクトとしてのプラットフォームとゴールデンパス	platform-engineer
複数チームにまたがるローンチ調整	technical-program-manager
ロールアウトとロールバックの計画	deployment-strategist
セキュリティアーキテクチャと管理策	cybersecurity, information-security-engineer
要件とビジネス上の制約	business-analyst
戦略、ビジネスケース、運営モデル	business-consultant
AI／LLMソリューションのパターン	ai-engineer
商用／エンタープライズ向け応用AIアーキテクチャ	applied-ai-architect-commercial-enterprise
顧客商談のソリューション、RFP、PoCの引き継ぎ	solutions-architect

主なワークフロー

1. 意思決定の枠組みを定める

構成図を描く前に、以下を記録します。

• ビジネス上の成果と、測定可能な成功基準
• 制約：予算、スケジュール、コンプライアンス、既存のシステム資産
• 対象外事項（明示的に除外する範囲）
• ステークホルダーと意思決定者
• 可逆性：後戻りできない決定か、変更可能な決定か

後戻りできない決定にはADRとアーキテクチャレビューが必要です。変更可能な決定はチームのRFC内で扱えます。

2. システムをモデル化する（C4ライト）

レビュー担当者向けの最小限のビュー：

1. コンテキスト — アクター、外部システム、信頼ゾーン
2. コンテナー — デプロイ可能な単位、データストア、キュー、それぞれのオーナー
3. クリティカルパス — 最もリスクの高いフローのみを示すシーケンス図

すべての矢印に、同期／非同期、プロトコル、認証モデル、障害時の動作を記載します。

references/integration_patterns.md を参照してください。

3. NFRと品質属性を定義する

各機能について、曖昧な「高可用性」ではなく、目標値を指定します。

属性	目標の例	検証方法
可用性	月間99.9%	SLO、エラーバジェット
レイテンシ	読み取り時にp99 < 300ms	負荷テスト＋本番環境のSLO
スループット	ピーク時に5k RPS	キャパシティモデル
耐久性	RPO 1h、RTO 4h	DR訓練
セキュリティ	東西トラフィックにmTLS、OIDC	脅威モデルへのリンク
コスト	100万リクエストあたり<$X	FinOps見積もり

references/nfr_quality_attributes.md を参照してください。

4. 選択肢を評価する

実行可能な選択肢を少なくとも2つと、「何もしない／最小限の変更」を提示します。

評価基準	重み	選択肢A	選択肢B
価値実現までの時間
運用負荷
スケーラビリティの余裕
チームのスキルとの適合性
ベンダーロックイン
セキュリティ／コンプライアンスとの適合性

1つを推奨し、採用しなかった選択肢とその理由を記録します。

references/adr_template.md を参照してください。

5. アーキテクチャレビュー

ビルドまたは契約締結の前に、次を確認します。

1. 問題と制約を1段落で再確認します
2. 図を最新の状態にし、契約をバージョン管理します（OpenAPI、イベントスキーマ）
3. 障害モードを確認します：部分的な停止、依存先のダウン、毒メッセージ
4. データを確認します：所有権、保持期間、PII、移行パス
5. 可観測性を確認します：コンテナごとのゴールデンシグナル
6. セキュリティを確認します：認可境界、シークレット、影響範囲
7. 複数フェーズの場合は、ロールアウトとロールバックを deployment-strategist に関連付けます

references/architecture_review.md を参照してください。

6. 発展と移行

レガシーシステムを置き換える場合：

1. 独立して移行できる機能スライスを特定します
2. リスクが高い場合は、一斉切り替えよりもストラングラーパターンを優先します
3. 切り替え前に同等性の基準を定義します
4. デュアルライト／デュアルリードの期間と照合を計画します
5. トラフィックがゼロであることをテレメトリで確認してから、旧経路を廃止します

references/migration_evolution.md を参照してください。

リファレンスを読み込むタイミング

• ADR の形式と基準 → references/adr_template.md
• レビューチェックリスト → references/architecture_review.md
• 同期、イベント、サーガ、API → references/integration_patterns.md
• SLO、キャパシティ、DR、コスト → references/nfr_quality_attributes.md
• ストラングラーパターンと切り替え → references/migration_evolution.md