ストーリー
田
田中VPoE
今月のテーマは「技術標準」だ。率直に言う — うちの会社に技術標準はない
あなた
えっ、それは問題じゃないですか？各チームがバラバラの技術を使っていて、ナレッジが蓄積されないという話は以前から聞いています
あ
田
田中VPoE
その通りだ。フロントエンドだけでもReact、Vue、Svelte、Angular。バックエンドはNode.js、Go、Python、Java。データベースはPostgreSQL、MySQL、MongoDB、DynamoDB。チームが好きな技術を選んでいる
あなた
逆に、ガチガチに標準を決めすぎると技術の進化に追いつけなくなるリスクもありますよね
あ
田
田中VPoE
まさにそこだ。厳格すぎる標準は創造性を殺す。かといって標準がなければ組織としてのナレッジが蓄積されない。バランスの取れた技術標準を策定するのが今回のミッションだ
あなた
「ちょうどいい標準」を見つけるのは難しそうですね
あ
田
田中VPoE
だからこそ、まず現状を正確に把握することから始める。何がどこで使われているのか。何が問題になっているのか。全体像を掴もう
なぜ技術標準が必要なのか
標準がない組織で起きること
技術標準が存在しない組織では、以下のような問題が顕在化します。
| 問題領域 | 具体的な症状 | 影響度 |
|---|---|---|
| ナレッジの断片化 | チームごとに異なる技術を使い、知見が共有されない | 極めて高い |
| 人材流動性の低下 | 別チームへの異動時に一から学び直しが必要 | 高い |
| 採用コストの増大 | 「何でもあり」で求人の訴求ポイントが曖昧に | 高い |
| セキュリティリスク | 統一的なセキュリティ基準がなく、脆弱な実装が放置される | 極めて高い |
| 運用負荷の増大 | 多種多様な技術スタックの運用・監視が必要 | 高い |
| 品質のばらつき | チームによってコード品質やテスト水準が大きく異なる | 高い |
厳格すぎる標準で起きること
一方で、標準を厳しくしすぎると別の問題が生じます。
| 問題領域 | 具体的な症状 | 影響度 |
|---|---|---|
| 技術的停滞 | 新しい技術を試せず、技術の進化に取り残される | 極めて高い |
| エンジニアの不満 | 「なぜこの技術を使わなければならないのか」という反発 | 高い |
| イノベーション阻害 | 最適な技術選定ができず、プロダクト競争力が低下 | 高い |
| 形骸化 | 実態に合わない標準が守られなくなり、信頼を失う | 高い |
| 採用への悪影響 | 「古い技術しか使えない会社」というイメージ | 中〜高い |
標準化のスペクトラム:
自由放任 厳格統制
├─────────────────────────────────────────┤
↑ ↑
カオス 官僚主義
ナレッジ断片化 イノベーション阻害
セキュリティリスク エンジニア離反
↓ ここを目指す ↓
┌─────────────────────┐
│ ガイド付き自律性 │
│ (Guided Autonomy) │
└─────────────────────┘「標準の目的は制約ではない。組織の生産性を最大化するための共通基盤を作ることだ。エンジニアが”車輪の再発明”に時間を使わず、本質的な問題に集中できるようにする」 — 田中VPoE
技術標準の3つのレベル
技術標準は強制力の違いにより3つのレベルに分類できます。
| レベル | 名称 | 強制力 | 例 | 逸脱時の対応 |
|---|---|---|---|---|
| Must | 必須標準 | 強制 | セキュリティ基準、認証方式、ログフォーマット | 例外には承認が必要 |
| Should | 推奨標準 | 推奨 | 言語・フレームワーク選定、アーキテクチャパターン | 理由があれば逸脱可能 |
| May | 参考ガイドライン | 任意 | コーディングスタイル、命名規則、ツール選定 | チーム判断に委ねる |
各レベルの具体例
Must（必須）:
├── 全サービスはOAuth 2.0/OIDCで認証すること
├── 機密データはAES-256で暗号化すること
├── ログは構造化JSON形式で出力すること
└── 脆弱性スキャンをCI/CDに組み込むこと
Should（推奨）:
├── 新規サービスはTypeScriptまたはGoで実装すること
├── データベースはPostgreSQLを第一候補とすること
├── マイクロサービス間通信はgRPCを推奨すること
└── テストカバレッジは80%以上を目標とすること
May（参考）:
├── フォーマッタはPrettier/gofmtを推奨する
├── IDEはVS Codeを推奨する（共有設定あり）
├── コミットメッセージはConventional Commitsに準拠する
└── ドキュメントはMarkdownで記述する技術標準の成功事例と失敗事例
成功事例：Google の技術標準
| 特徴 | 内容 |
|---|---|
| サポート言語を限定 | C++、Java、Python、Go、TypeScript に絞り込み |
| 強力なツーリング | 標準に準拠させるためのリンター・フォーマッタ・ビルドツールを整備 |
| 生きたドキュメント | Google Engineering Practices として公開・継続的に更新 |
| 文化としての浸透 | コードレビューで標準への準拠を自然にチェック |
失敗事例：「標準はあるが誰も守っていない」パターン
| 原因 | 説明 |
|---|---|
| 策定プロセスに現場が関与していない | 一部の「偉い人」が決めた標準に対する反発 |
| 自動化されていない | 手動でのチェックに依存し、形骸化 |
| 更新されない | 3年前の標準が今も「最新」として存在 |
| 例外処理がない | 正当な理由があっても逸脱できず、闇で無視される |
| メリットが伝わっていない | 「なぜこの標準に従うべきか」が説明されていない |
Month 5 のロードマップ
| Step | テーマ | 得られる成果 |
|---|---|---|
| 1 | 技術標準の現状を棚卸しよう | 技術スタック一覧、テクノロジーレーダー、技術的負債の評価 |
| 2 | 標準化の範囲と深度を決定しよう | 言語戦略、アーキテクチャ標準、品質標準の設計 |
| 3 | 標準策定プロセスを確立しよう | RFC/ADRプロセス、レビュー体制、例外処理 |
| 4 | 標準の普及戦略を実行しよう | 採用促進、ツーリング、教育プログラム |
| 5 | 標準の進化サイクルを設計しよう | 進化サイクル、効果測定メトリクス、非推奨化プロセス |
| 6 | 技術標準体系を完成させよう | 統合技術標準体系ドキュメント |
「技術標準は”法律”ではない。“共通言語”だ。組織が同じ方向を向いて走るための地図を一緒に作ろう」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| 標準がない問題 | ナレッジ断片化、人材流動性低下、セキュリティリスク |
| 厳格すぎる問題 | 技術的停滞、イノベーション阻害、エンジニア離反 |
| 目指す姿 | ガイド付き自律性（Guided Autonomy） |
| 3つのレベル | Must（必須）、Should（推奨）、May（参考） |
チェックリスト
- 技術標準がない組織で起きる問題を理解した
- 標準が厳格すぎる場合のリスクを理解した
- Must/Should/May の3段階を理解した
- Month 5のロードマップを把握した
次のステップへ
次は「技術スタックの棚卸し」を学びます。組織で使われている技術の全体像を体系的に把握する方法を身につけましょう。
推定読了時間: 15分