architecture-decision について
Architecture Decisionは、設計案の比較、トレードオフの記録、技術的負債の管理を支援するソフトウェアチーム向けのスキルです。万能な構成を想定せず、状況に応じたパターン選択を重視します。
主な機能
- 01アーキテクチャ案を比較
- 02状況に応じてパターンを選定
- 03アーキテクチャ決定記録を作成
- 04品質特性を評価
- 05リファクタリング手法を記録
- 06技術的負債を分類・追跡
活用シーン
- 01アーキテクチャパターンの選択
- 02技術選定の根拠の記録
- 03技術的負債への対応計画
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/architecture-decisionを入力して読み込まれたか確認します。
詳細
アーキテクチャの意思決定
アーキテクチャの意思決定を体系的に評価し、トレードオフを記録して、状況に適したパターンを選択します。パターン選択、ADR の作成、技術的負債の管理に役立つフレームワークを提供します。
このスキルを使用するタイミング
次の場合にこのスキルを使用してください：
- 技術を選定するとき
- アーキテクチャパターンを評価するとき
- アーキテクチャ決定記録を作成するとき
- 技術的負債を評価するとき
- 設計の選択肢を比較するとき
次の場合はこのスキルを使用しないでください：
- 実装コードを書くとき
- 要件に取り組むとき（requirements-analysis を使用してください）
- システム全体の設計を行うとき（system-design を使用してください）
基本原則
意思決定は状況によって変わります。 どのパターンも、常に良い、または悪いとは限りません。最適なアーキテクチャとは、最も洗練されたものではなく、保守性と進化のしやすさを保ちながら、その目的を最もよく果たすものです。
トレードオフの三角形
アーキテクチャ上のあらゆる意思決定には、トレードオフが伴います。
| 頂点 | 最大化する方法 | コスト |
|---|---|---|
| シンプルさ | モノリス、同期通信、単一 DB | スケーラビリティの限界 |
| 柔軟性 | マイクロサービス、イベント駆動、プラグイン | 複雑さによるオーバーヘッド |
| パフォーマンス | キャッシュ、非正規化、最適化されたコード | 保守性 |
バランスを取るための戦略：
- シンプルに始め、必要に応じて複雑さを加える
- 最適化の前に測定する
- 抽象化を利用して意思決定を先送りする
- 段階的に進化させる
品質特性
パフォーマンス
- 指標：応答時間（p50、p95、p99）、スループット、リソース使用率
- 戦術：キャッシュ、負荷分散、非同期処理
スケーラビリティ
- 次元：水平、垂直、弾力的
- パターン：ステートレスサービス、シャーディング、イベントストリーミング
信頼性
- 指標：稼働時間、MTBF、MTTR
- パターン：サーキットブレーカー、再試行、冗長化
保守性
- 要素：可読性、モジュール性、テスト容易性
- パターン：クリーンアーキテクチャ、DDD、SOLID
コンテキストとパターンの対応関係
チームの状況
| 状況 | 推奨パターン | 避けるもの |
|---|---|---|
| 小規模チーム | モノリス、垂直スライス、共有 DB | マイクロサービス、複雑な抽象化 |
| 複数のチーム | サービス境界、API 契約 | 共有状態、密結合 |
規模の状況
| 状況 | 推奨パターン | 理由 |
|---|---|---|
| スタートアップ | まずはモノリス、垂直スケーリング | 開発速度を最適化する |
| エンタープライズ | サービスメッシュ、水平スケーリング | 運用規模に合わせて最適化する |
意思決定マトリックスのテンプレート
| 選択肢 | 一貫性 | 柔軟性 | スケーラビリティ | 複雑さ | コスト | 合計 |
|---|---|---|---|---|---|---|
| 選択肢 A | 5 | 2 | 3 | 2 | 3 | 15 |
| 選択肢 B | 3 | 5 | 4 | 3 | 3 | 18 |
| 選択肢 C | 2 | 3 | 5 | 1 | 2 | 13 |
状況の優先度に基づいて、各要素に重みを設定してください。
アーキテクチャ決定記録（ADR）のテンプレート
# ADR-[NUMBER]: [TITLE]
## Status
[Proposed | Accepted | Deprecated | Superseded]
## Context
[What is the situation requiring a decision?]
### Requirements
- [Requirement 1]
- [Requirement 2]
### Constraints
- [Constraint 1]
- [Constraint 2]
## Decision
[What is the decision?]
### Justification
- [Reason 1]
- [Reason 2]
## Consequences
### Positive
- [Benefit 1]
- [Benefit 2]
### Negative
- [Drawback 1]
- [Drawback 2]
## Alternatives Considered
### [Alternative 1]
Reason rejected: [Why]
### [Alternative 2]
Reason rejected: [Why]
アーキテクチャのリファクタリングパターン
抽象化による分岐
- 現在の実装を覆う抽象化を作成する
- 抽象化の背後に新しいソリューションを実装する
- 新しい実装に切り替える
- 古い実装を削除する
ストラングラーフィグ
- 境界を特定する
- 新機能向けに新しいソリューションを実装する
- 古い機能を段階的に移行する
- 古いシステムを廃止する
並行実行
- 新しいソリューションを実装する
- 古いものと新しいものを並行して実行する
- 結果を比較する
- 確信が持てたら切り替える
技術的負債の管理
負債のカテゴリ
| 種類 | 例 | 解消戦略 |
|---|---|---|
| 設計 | 抽象化の不足、密結合 | リファクタリングスプリント |
| コード | 重複、複雑さ、不適切な命名 | 継続的なクリーンアップ |
| テスト | テストの不足、不安定なテスト | テストの改善 |
| ドキュメント | ドキュメントの不足、古い図 | ドキュメント作成スプリント |
指標
- 負債比率： 負債の解消作業 / 全作業（目標 < 20%）
- 金利： 負債によって追加で必要となる作業量
- 負債の上限： 許容できる負債の最大量
アンチパターン
巨大な泥団子
症状： 明確な構造がなく、すべてが互いに依存しています 対策： 境界を特定し、モジュールを抽出して、インターフェースを確立します
分散モノリス
症状： サービスをまとめてデプロイする必要があり、同期呼び出しが連鎖し、データベースを共有しています 対策： 関連するサービスを統合し、非同期通信を導入して、データベースを分離します
黄金のハンマー
症状： あらゆる問題に単一の解決策を適用し、パターンを無理に当てはめています 対策： 代替案を学び、客観的に評価して、選択肢をプロトタイプ化します
関連スキル
- system-design - ADR を用いたシステム設計全般
- code-review - 実装の検証
- task-decomposition - アーキテクチャ作業の分解
- requirements-analysis - 制約の把握
コメント
Markdown 対応