## Technical Context Repository

### システム全体像の共有
**Architecture Decision Records (ADR)**：
```yaml
adr_template:
  id: "ADR-001"
  title: "マイクロサービス・アーキテクチャの採用"
  status: "承認済み"
  context: |
    - 現在のモノリスの問題点
    - チーム規模の拡大予定
    - 技術的負債の蓄積
  decision: "ドメイン単位でのマイクロサービス分割"
  consequences:
    positive:
      - "チーム独立性の向上"
      - "技術選択の柔軟性"
      - "障害影響範囲の限定"
    negative:
      - "分散システムの複雑性"
      - "運用コストの増加"
      - "データ整合性の課題"

## プロジェクト共通語彙

### Infrastructure Layer
- **Blue-Green Deployment**: 本番環境を2つ用意し、無停止でバージョン切り替え
- **Circuit Breaker**: 障害サービスへのアクセスを一時的に遮断する仕組み
- **Load Balancer**: 複数サーバーに負荷を分散させるシステム

### Application Layer  
- **Domain Model**: ビジネスロジックを表現するオブジェクト群
- **Repository Pattern**: データアクセス層を抽象化する設計パターン
- **Event Sourcing**: 状態変更をイベント列として記録する手法

### Business Context
- **MAU (Monthly Active Users)**: 月間アクティブユーザー数
- **SLA (Service Level Agreement)**: サービス品質保証レベル
- **KPI (Key Performance Indicator)**: 重要業績評価指標

## 抽象化レベル設計

### Level 5: Implementation Details（実装詳細）
**対象者**: 同じ技術領域の専門家
**内容例**:
```python
# Redis Cluster設定によるセッション管理最適化
redis_config = {
    'cluster_enabled': True,
    'cluster_config_file': 'nodes.conf',
    'cluster_node_timeout': 15000,
    'appendonly': True,
    'save': '900 1 300 10 60 10000'
}

## Technical Risk → Business Risk Translation

### リスク評価フレームワーク
```python
class TechnicalRisk:
    def __init__(self, name, technical_impact, business_impact, probability, detection_time):
        self.name = name
        self.technical_impact = technical_impact
        self.business_impact = business_impact  
        self.probability = probability
        self.detection_time = detection_time
    
    def business_risk_score(self):
        return self.business_impact * self.probability * (1 + self.detection_time/24)

# リスク定義例
risks = [
    TechnicalRisk(
        name="データベース容量不足",
        technical_impact="書き込み処理失敗、パフォーマンス劣化",
        business_impact=8,  # 1-10スケール（10=事業停止レベル）
        probability=0.7,    # 3ヶ月以内の発生確率
        detection_time=2    # 問題発覚までの時間（時間）
    ),
    TechnicalRisk(
        name="外部API依存の単一障害点",
        technical_impact="決済機能・通知機能の完全停止",
        business_impact=9,
        probability=0.3,
        detection_time=0.5
    ),
    TechnicalRisk(
        name="レガシーコードの技術的負債",
        technical_impact="開発速度低下、バグ増加",
        business_impact=6,
        probability=0.9,
        detection_time=168  # 1週間（間接的影響）
    )
]

# ビジネスリスクスコアでソート
risks.sort(key=lambda x: x.business_risk_score(), reverse=True)

## 【緊急】システムリスクの報告と対策提案

### 現状認識
**問題**: データベース容量が設計限界の85%に到達
**発生タイミング**: 現在のペースだと3ヶ月後に上限到達
**影響範囲**: 全ユーザー（月間10万アクティブユーザー）

### ビジネスへの影響
**最悪シナリオ（対策なしの場合）**:
- サービス完全停止：最大24時間
- 機会損失：日売上200万円 × 停止日数
- 顧客離脱：推定5,000ユーザー（LTV 1.5億円相当）
- レピュテーション損失：復旧後6ヶ月の新規獲得50%減

### 技術的対策案
**即座対策（1週間以内）**:
- データベースストレージ拡張：月額20万円増
- 不要データの自動削除設定：開発工数40時間

**根本対策（2ヶ月以内）**:
- データ分散アーキテクチャ導入：開発工数300時間
- 予測型容量管理システム構築：開発工数100時間

### 投資対効果
- 対策投資総額：1,200万円
- 回避できる損失：最大3億円（最悪シナリオ）
- ROI：2,400%（リスク回避による価値）

### 推奨アクション
1. 即座対策の緊急実施承認
2. 根本対策の開発リソース確保
3. 類似リスクの全システム点検

## 組織階層別情報フィルタリング

### Executive Level（経営レベル）
**関心事**: 戦略・ROI・競争優位・リスク
**情報フィルタ**:
```python
def executive_filter(technical_info):
    """経営層向け情報フィルタ"""
    return {
        'strategic_impact': extract_strategic_value(technical_info),
        'financial_impact': calculate_roi_and_costs(technical_info),
        'competitive_advantage': assess_market_position(technical_info),
        'risk_factors': identify_business_risks(technical_info),
        'timeline': get_major_milestones(technical_info),
        'resource_requirements': summarize_investments(technical_info)
    }

# フィルタ適用例
technical_details = "マイクロサービス化による技術的負債解消"
executive_summary = executive_filter(technical_details)
# Output: {
#   'strategic_impact': '開発速度2倍向上、市場投入期間短縮',
#   'financial_impact': '年間開発コスト30%削減、ROI 250%',
#   'competitive_advantage': '競合より6ヶ月早い機能リリース実現',
#   'risk_factors': '移行期間中の一時的な生産性低下',
#   'timeline': '設計3ヶ月、実装6ヶ月、移行3ヶ月',
#   'resource_requirements': '追加エンジニア3名、外部コンサル1名'
# }

## 技術的問題のエスカレーション判断

### 自動エスカレーション条件
```yaml
escalation_rules:
  immediate_escalation:
    conditions:
      - "production_downtime > 30_minutes"
      - "security_breach_detected == true"
      - "data_corruption_risk == 'high'"
      - "customer_impact > 1000_users"
    
    notification_chain:
      - "tech_lead (Slack + Phone)"
      - "engineering_manager (Slack + Phone)"  
      - "cto (Phone)"
      - "ceo (Phone, if impact > 10000_users)"
    
    information_template:
      - "問題の概要（1行）"
      - "影響範囲（ユーザー数・売上）"
      - "推定復旧時間"
      - "暫定対策の有無"
      - "根本原因調査状況"

  scheduled_escalation:
    conditions:
      - "project_delay > 2_weeks"
      - "budget_overrun > 20_percent"
      - "team_velocity_drop > 30_percent"
      - "technical_debt_threshold_exceeded == true"
    
    notification_chain:
      - "engineering_manager (Email)"
      - "product_manager (Email)"
      - "department_head (Weekly Report)"
    
    information_template:
      - "現状と計画の乖離"
      - "原因分析"
      - "対策案（複数オプション）"
      - "意思決定が必要な事項"
      - "推奨アクション"

  advisory_escalation:
    conditions:
      - "architectural_decision_required == true"
      - "resource_allocation_change_needed == true"
      - "technology_adoption_decision == true"
      - "team_structure_optimization == true"
    
    notification_chain:
      - "tech_lead (Discussion)"
      - "engineering_manager (Meeting)"
      - "architecture_committee (Formal Review)"
    
    information_template:
      - "決定が必要な事項"
      - "選択肢と評価"
      - "推奨案と根拠"
      - "実装タイムライン"
      - "リスクと軽減策"

## 高効率コミュニケーション・パターン集

### Pattern 1: Technical Spike Communication
**用途**: 技術調査結果の共有
**構造**:
```yaml
spike_report_template:
  objective: "何を調べたかったか"
  approach: "どのような方法で調査したか"  
  findings:
    technical_feasibility: "技術的実現性の評価"
    performance_characteristics: "性能・スケーラビリティ"
    integration_complexity: "既存システムとの統合難易度"
    learning_curve: "チームの習得コスト"
  
  recommendation:
    primary_option: "推奨選択肢"
    rationale: "推奨理由（定量的根拠）"
    alternatives: "代替案（長所・短所）"
  
  next_actions:
    immediate: "すぐに実行すべきアクション"
    planned: "計画的に進めるアクション"  
    decisions_needed: "意思決定が必要な事項"

# 実装例
spike_report = {
  'objective': 'フロントエンド状態管理ライブラリの選定',
  'findings': {
    'redux_toolkit': {'score': 85, 'pros': ['豊富な実績', '充実したエコシステム'], 'cons': ['学習コスト', 'ボイラープレート']},
    'zustand': {'score': 90, 'pros': ['シンプル', '高性能'], 'cons': ['エコシステム小', '実績少']},
    'recoil': {'score': 70, 'pros': ['React統合', '直感的API'], 'cons': ['実験的', 'Facebook依存']}
  },
  'recommendation': {
    'primary_option': 'zustand',
    'rationale': '小規模チームでの開発速度重視、既存Reactスキルの活用',
    'risk_mitigation': 'Redux Toolkitへの移行パスを確保'
  }
}

### PSI Communication Template

**Problem（問題）**:
- 現象: 何が起きているか（観測可能な事実）
- 影響: ユーザー・ビジネスへの具体的な影響
- 緊急度: いつまでに解決が必要か

**Solution（解決策）**:
- 根本原因: 問題の本質的な原因
- 対策案: 具体的な解決手段（複数選択肢）
- 実装アプローチ: どのように実現するか

**Impact（効果）**:
- 期待効果: 解決によって得られる価値
- 投資対効果: コストと効果の定量的評価
- リスク軽減: 回避・軽減されるリスク

### 実践例
Problem:
- API応答時間が平均3.2秒（SLA目標1.0秒の3倍超過）
- ユーザー離脱率が15%増加、顧客満足度スコア0.8ポイント低下
- 競合他社比で2倍遅く、競争劣位が顕著

Solution:
- 根本原因: N+1クエリ問題とインデックス不足
- 対策: クエリ最適化（バッチロード）+ インデックス追加
- 実装: 2週間（設計1週間、実装・テスト1週間）

Impact:
- 応答時間1.0秒達成（SLA準拠）
- 離脱率改善による売上15%回復
- サーバーリソース30%削減（コスト月20万円減）

## 避けるべきコミュニケーション・パターン

### Anti-Pattern 1: "Technology for Technology's Sake"
**問題**: 技術的興味を理由とした変更提案
**典型的な発言**:

❌ 過度に複雑な資料:
- 50ページのアーキテクチャ資料（5分の説明のために）
- 全ての技術詳細を網羅したドキュメント
- 読み手の関心・専門性を無視した一律説明

✅ 最適化された資料:
- エグゼクティブサマリー（1ページ）
- 詳細版（必要に応じて参照）
- 聞き手に応じたバージョン管理