ストーリー

標準化の判断フレームワーク

3つの判断軸

標準化の深度マトリクス

標準化の深度:

強制 ──┐
       │ セキュリティ基準
       │ 認証・認可方式
       │ 機密データの取り扱い
       │─────────────────────── Must（必須）
       │ API設計規約
       │ ログ・監視標準
       │ デプロイメントプロセス
       │ 推奨言語・フレームワーク
       │─────────────────────── Should（推奨）
       │ コーディングスタイル
       │ テストフレームワーク
       │ 開発ツール
任意 ──┘─────────────────────── May（参考）

標準化すべき領域の特定

領域別の推奨標準化レベル

標準化しない判断も重要

標準化の範囲を決めるプロセス

4ステップのプロセス

Step 1: 候補の列挙
  └── 棚卸し結果から標準化候補を網羅的に列挙

Step 2: 重要度の評価
  ├── 安全性スコア（1-5）
  ├── 一貫性スコア（1-5）
  └── 効率性スコア（1-5）

Step 3: レベルの判定
  ├── 合計12点以上 → Must候補
  ├── 合計8-11点 → Should候補
  └── 合計7点以下 → May候補 or 対象外

Step 4: ステークホルダーレビュー
  ├── 技術リードからのフィードバック
  ├── セキュリティチームのレビュー
  └── エンジニア代表の意見聴取

評価シートの例

標準化ドキュメントの構造設計

推奨される構造

技術標準ドキュメント体系:

tech-standards/
├── README.md                    # 標準の目的、適用範囲、レベル説明
├── must/                        # Must（必須標準）
│   ├── security.md             # セキュリティ基準
│   ├── authentication.md       # 認証・認可標準
│   ├── logging.md              # ログ標準
│   └── data-handling.md        # データ取り扱い基準
├── should/                      # Should（推奨標準）
│   ├── languages.md            # 推奨言語・フレームワーク
│   ├── api-design.md           # API設計規約
│   ├── testing.md              # テスト戦略
│   ├── architecture.md         # アーキテクチャパターン
│   └── deployment.md           # デプロイメント標準
├── may/                         # May（参考ガイドライン）
│   ├── coding-style.md         # コーディングスタイル
│   ├── documentation.md        # ドキュメント作成ガイド
│   └── tooling.md              # 推奨ツール一覧
├── decisions/                   # ADR（アーキテクチャ決定記録）
│   └── NNNN-title.md
└── radar/                       # テクノロジーレーダー
    └── current.md

各ドキュメントの共通テンプレート

「標準化の範囲を決めることは、組織の技術的自由度の設計だ。どこまで自由を残し、どこを揃えるか。この判断がエンジニアリング組織の性格を決める」 — 田中VPoE

まとめ

チェックリスト

• 標準化の3つの判断軸（安全性、一貫性、効率性）を理解した
• 各領域の推奨標準化レベルを理解した
• 標準化しない判断の重要性を理解した
• 標準化ドキュメントの構造設計を理解した

次のステップへ

次は「言語・フレームワーク戦略」を学びます。Should レベルの標準の中核となる、推奨言語とフレームワークの選定方法を身につけましょう。

推定読了時間: 30分