はじめに
皆さんはDeep Researchを使っていますでしょうか？
自分は今までChatGPTのDeep Researchしか使ってこなかったんですが、
「そういえば、最近ClaudeとGeminiもよく使っているからこっちのDeep Researchってどんな感じなんだろう？」
と思い立って使ってみたところ想像以上に良かったので記事を書いてみました！
TL;TD
- 結論：納得感＆参照の厚みはClaudeが強かった
- リンク・教材候補の拾い方はGeminiが便利だった
- ChatGPT:拾える情報は多いが、今回は“文章としての腹落ち”が弱めに感じた（※主観）
検証方法
今回はChatGPT, Gemini, Claudeの3つを比べてみました
検証の際に使ったプロンプトは以下の通りです！
このプロンプトは自分がプラットフォームエンジニアとしてどんなキャリアパスがあるんだろうと気になって作ったものです
キャリアパスの相談をした時に下記のような羅針盤を渡されました
そこで内容の精査と補完をしてほしいです
特に業界標準の内容が薄い、また推測に基づいているので調査してほしいです
---
### 求められるスキルのまとめ（年次別レベル目安）
### I. 共通の土台となるスキル（全職種必須）
1. **高度な技術的基礎知識（CS）**
- **1年目（新卒〜）**:
- 業務で使う技術（HTTP, SQLなど）の基礎を理解し、先輩のサポートのもとで使える。
- 応用情報技術者試験レベルの知識（OS, NW, DB）を学習し、言葉を理解できる。
- **3年目（中堅・独り立ち）**:
- 計算量（O記法）を意識したコードが書ける。
- OSやネットワークの基礎知識を使い、簡単なパフォーマンス問題（例: N+1クエリ）の切り分けや特定ができる。
- **5年目（シニア・リード候補）**:
- 自身の専門領域（例: DB, ネットワーク, クラウド）において深い知識を持つ。
- 複雑な障害（例: 特定条件下でのみ発生する性能劣化）の根本原因を特定し、チューニングの議論をリードできる。
2. **システム全体への広い視野（大局観）**
- **1年目**:
- 担当システムの**構成図を読める**。主要コンポーネント（DB, サーバー, API）の役割を説明できる。
- **3年目**:
- 担当システム全体の**詳細な構成**（インフラ、監視、ログ、デプロイ経路）を把握し、他者に説明できる。
- 小規模な変更が、他システム（特に連携先）に与える影響を考慮できる。
- **5年目**:
- **複数のプロダクト（システム群）**がどう連携しているかを把握している。
- 事業全体のサービスレベル（可用性、拡張性）を意識したシステム設計（例: どこで障害が起きうるか、どうスケールさせるか）の議論に参加し、意見を述べられる。
3. **設計能力（課題の抽象化とモデリング）**
- **1年目**:
- 先輩の設計書やコードレビューから、その「**意図**」を読み取ろうと努める。
- 与えられた詳細仕様に基づき、小さな機能（クラス、関数、簡単なAPI）の実装設計ができる。
- **3年目**:
- 曖昧な要件をヒアリングし、技術的な課題に分解できる。
- 変更容易性を考慮した**DB設計（ER図）やAPI設計**を独力で行える。
- **5年目**:
- ビジネス要件や将来の拡張性に基づき、システムの「**境界**」（例: マイクロサービス化の単位）を設計できる。
- 技術的負債とビジネス価値の**トレードオフ**を判断し、大規模なリファクタリング計画を立案・提案できる。
---
### II. 各職種で特に求められる専門スキル
#### 1. 🏗️ プラットフォームエンジニア
- **クラウド技術 (AWS, GCPなど)**
- **1年目**: 主要サービス（EC2, S3など）の役割を理解し、管理画面やCLIで基本的な操作ができる。
- **3年目**: VPC（ネットワーク）、IAM（権限）を含めた環境構築を独力で行え、コストやセキュリティのベストプラクティスを意識できる。
- **5年目**: マルチアカウント戦略、セキュアなネットワーク設計、コスト最適化など、全社的なクラウドガバナンスの設計・運用をリードできる。
- **コンテナ技術 (Docker, Kubernetes)**
- **1年目**: Dockerfileを書き、コンテナをビルド/実行できる。Kubernetesの基本概念（Pod, Service）を理解する。
- **3年目**: 本番環境で動くKubernetesアプリケーションの運用（デプロイ、トラブルシューティング）ができ、マニフェスト（YAML）を修正できる。
- **5年目**: Kubernetesクラスタ自体の設計、構築（またはEKS/GKEなどの高度な設定）をリードできる。Service Meshなど高度な技術の導入を検討できる。
- **自動化 (IaC / CI/CD)**
- **1年目**: 既存のCI/CDパイプラインを利用できる。既存のTerraformコードを読んで理解できる。
- **3年目**: **Terraform**を用いてゼロからインフラをコード化できる。**CI/CDパイプライン**（例: GitHub Actions）を独力で構築・改善できる。
- **5年目**: 全社的なCI/CD基盤の設計や、Terraformの共通モジュール開発など、開発者体験（DX）向上のための戦略的な自動化を推進できる。
- **可観測性 (Observability)**
- **1年目**: 障害時に、指定されたダッシュボードやログツールを見て、エラー箇所を特定できる。
- **3年目**: 担当システムのSLI/SLOを意識し、必要なメトリクスやアラートを設計・実装できる。基本的なトラブルシューティングができる。
- **5年目**: **分散トレーシング**など高度な可観測性プラットフォームの設計・導入をリードできる。SLOに基づいた信頼性向上施策を推進できる。
#### 2. 🏛️ ソフトウェアアーキテクト
- **アーキテクチャパターン**
- **1年目**: モノリス、マイクロサービス等の基本パターンの「言葉と概念」を理解する。
- **3年目**: 担当システムが採用しているパターンのメリット・デメリットを説明でき、そのパターンに沿った設計・実装ができる。
- **5年目**: プロジェクト要件に基づき、複数のアーキテクチャパターンを比較評価し、最適なものを「**論理的に選定・提案**」できる。
- **非機能要件の設計**
- **1年目**: パフォーマンス（N+1問題など）を意識したコードを書こうと努める。
- **3年目**: パフォーマンス、セキュリティ、スケーラビリティを考慮した設計（例: 適切なインデックス、キャッシュ戦略）ができ、負荷試験などを実施できる。
- **5年目**: **高可用性（HA）**、DR（災害復旧）、大規模スケーラビリティ設計など、ミッションクリティカルなシステムの非機能要件を「**ゼロから定義・設計**」できる。
- **技術選定と評価**
- **1年目**: チームが採用している技術（言語、DB）をキャッチアップし、使えるようになる。
- **3年目**: 小規模なプロジェクトや新機能において、必要なライブラリやミドルウェアを比較検討し、選定理由を説明できる。
- **5年目**: 全社的な技術スタックの選定や、新しい技術の導入（PoC: 概念実証）をリードできる。技術的負債の返済計画を立案できる。
- **深いインフラ・DB知識**
- **1年目**: ORM経由でDBを操作でき、SQLの基本的な構文（Joinなど）を理解している。
- **3年目**: SQLの**実行計画**を読み、インデックス設計やクエリチューニングができる。キャッシュ戦略（Redisなど）を理解し、適切に利用できる。
- **5年目**: DBの水平/垂直分割、非同期処理（キューイング）、CQRSなど、システム全体のボトルネックを解消するための高度な設計パターンを導入できる。
#### 3. 👨👩👧👦 エンジニアリングマネージャー (EM)
（注：EMは通常、5年目以降のシニアエンジニアやテックリードを経てから目指すキャリアです。1年目、3年目はその前段階として記述します）
- **ピープルマネジメント**
- **1年目**: （対象外）自身のタスク管理と、先輩・メンターへの適切な「報告・連絡・相談」ができる。
- **3年目**: （テックリード候補として）後輩（新卒・1年目）の**技術的なメンタリング**やコードレビューを担当できる。
- **5年目**: （EMまたはテックリードとして）メンバーの目標設定、1on1を通じたコーチング、キャリア相談、公正な評価など、チームメンバーの「**成長支援**」に責任を持つ。
- **プロセス管理・改善**
- **1年目**: チームの開発プロセス（スクラムなど）を理解し、ルールに従ってタスクを遂行できる。
- **3年目**: チームのふりかえり（レトロスペクティブ）を主導し、開発プロセスの「**小さな改善**」を継続的に実施できる。
- **5年目**: （EMとして）チームの生産性や健全性をデータ（Four Keysなど）で可視化し、ボトルネックを特定。開発プロセス全体の「**大きな改善**」や、他チームとの調整を行う。
- **技術的ビジョンの提示**
- **1年目**: チームの技術的な目標やロードマップを「理解」する。
- **3年目**: （テックリード候補として）チームの技術的負債の解消計画や、小規模なリファクタリングを「提案・実行」できる。
- **5年目**: （EMとして）アーキテクトと協力し、ビジネス目標と連動した「**中長期の技術ロードマップ**」を策定し、チームに浸透させ、実行に責任を持つ。
- **採用と組織設計**
- **1年目**: （対象外）
- **3年目**: 採用面接の面接官（技術評価担当）として参加できる。
- **5年目**: （EMとして）事業計画に基づき、必要な「**チーム体制（組織設計）**」や「**採用要件**」を定義し、採用活動全体をリードできる。
---
結果
別に研究記事ではないので、めちゃくちゃ主観が入っていますが、圧倒的にClaudeが納得感のなるレポートを出してくれました
ChatGPT
驚いたのですが、ChatGPTって時間がめっちゃかかって高精度なレポートを出してくれるイメージがあったのですが、今回の3つの中で一番早く、そして当たり障りのない微妙で分量の少ないレポートが出てきました
(自分の使い方が悪かったのかも？)
かかった時間は20mぐらいで、情報源は117件でした
(出力結果は長いので割愛しますmm)
Gemini
これも驚いたのですが、GeminiのDeep Researchって早い割には精度はあまり...と思っていたのですが、結構情報をまとめてくれていました
ただ、本当に「情報を検索してきたよ！」「情報をまとめてるよ！」という感じで、出力は情報の羅列感を感じました
Geminiはかかった時間や情報源の数を出してくれないので体感にはなるんですがChatGPTと大差ない感じがしました
Claude
これが一番すごかったです
みてください！この情報源と思考時間！
流石に長すぎる気がしますが、それなりに納得感のある出力をしてくれました
出力結果
# エンジニアキャリアパス業界標準精査レポート
## グローバルトップティア企業基準との比較検証
## エグゼクティブサマリー
提供されたキャリアパスフレームワークを、GAFAM、Netflix、Uber等のトップティア企業、および国内主要テック企業の公開基準と徹底比較しました。**全体的に妥当な構成ですが、いくつかの重要な領域で基準が控えめすぎる**ことが判明。特に1年目の技術基礎と3年目の可観測性・信頼性工学が業界標準より薄く、5年目のビジネス連携とコスト意識が不足しています。
**主要発見事項:**
- **1年目:** 基礎は妥当だがアルゴリズム・データ構造、テスト、Git等の明示が必要
- **3年目:** 可観測性3本柱、SLO/エラーバジェット、分散システム基礎が欠落
- **5年目:** ビジネス連携、FinOps、セキュリティアーキテクチャ、カオスエンジニアリングを追加すべき
- **重大な欠落:** Four Golden Signals、DORAメトリクス、心理的安全性、OpenTelemetry
---
## I. 共通基盤スキルの精査
### 1. 高度な技術的基礎知識(CS)
#### **1年目：HTTP, SQLなどの基礎理解、応用情報技術者試験レベル**
**妥当性評価:** ⚠️ **やや低い - 具体性と範囲の拡大推奨**
**業界標準比較:**
- **Google L3:** アルゴリズム・データ構造の強固な基礎、クリーンコード作成
- **Meta E3:** 1-5日タスク完遂、高品質コード・テスト・ドキュメント
- **メルカリMG1:** 開発フロー理解、チーム貢献開始
**修正提案 - 1年目追加項目:**
【コンピュータサイエンス基礎】
- アルゴリズムとデータ構造（配列、リスト、木、グラフ、ソート、探索）
- 計算量の概念理解（O(1), O(n), O(n²), O(log n)）
- HTTP/HTTPS、REST APIの仕組み
- SQL基礎（SELECT, JOIN, WHERE, GROUP BY、インデックス概念）
【開発実践スキル】
- Git基本操作（clone, commit, push, pull, branch, merge）
- プルリクエストワークフロー
- ユニットテストの作成（JUnit, pytest等）
- コードレビュー参加（学習者として）
- デバッグ技法（ブレークポイント、ログ活用）
【開発プロセス】
- Agile/Scrum基本理解
- 報連相（ホウレンソウ）の実践
- チーム開発フローの理解
- ドキュメント作成（README, コメント）
**根拠:** Google L3は「アルゴリズムとコーディング能力」を主要評価軸とし、Meta E3は「品質の高いコード、テスト、ドキュメント」を期待
---
#### **3年目：計算量（O記法）を意識、N+1クエリの切り分け**
**妥当性評価:** ✅ **概ね妥当 - 可観測性と分散システムを大幅強化**
**業界標準:**
- **Google L4:** 中規模プロジェクト独立実行、2-3人リード
- **SRE 3年:** SLO/SLI設計、Kubernetes本番運用、トイル削減30-50%
**重大な追加項目:**
【パフォーマンス最適化】
✓ 計算量（O記法）実践活用
✓ N+1クエリ特定と解決
✓ データベースインデックス設計
✓ キャッシング戦略（Redis, Memcached）
✓ クエリ実行計画の分析
【可観測性 - 最重要な追加】
+ Four Golden Signals実装:
- Latency（レイテンシー）
- Traffic（トラフィック量）
- Errors（エラー率）
- Saturation（飽和度）
+ メトリクス収集（Prometheus）とダッシュボード作成（Grafana）
+ ログ設計とログレベル活用
+ 基本的な分散トレーシング（Jaeger/Zipkin）
+ SLI/SLO定義とエラーバジェット計算
【分散システム基礎】
+ マイクロサービスアーキテクチャ理解
+ API設計（RESTful, GraphQL基礎）
+ 非同期処理（メッセージキュー概念）
+ サービス間通信パターン
【信頼性エンジニアリング】
+ 本番デプロイ経験
+ オンコール参加（エスカレーション付き）
+ インシデント対応とポストモーテム作成
+ ランブック作成と活用
**規模感:** 数千〜数万ユーザー、秒間数千リクエスト、2-3ヶ月プロジェクト
---
#### **5年目：専門領域の深い知識、複雑な障害の根本原因特定**
**妥当性評価:** ✅ **適切 - ビジネス連携とレジリエンスを強化**
**業界標準:**
- **Google L5:** 3-6+人リード、複雑なシステム設計、技術戦略影響
- **Netflix:** システム設計最重要、本番責任感、top of market報酬
**強化項目:**
【専門性深化】
✓ 選択領域の深い専門知識（分散システム、セキュリティ、ML基盤等）
+ 論文読解能力（最新研究キャッチアップ）← Databricksで重視
+ OSS貢献（コード、ドキュメント、イシュー対応）← Airbnbで高評価
【高度な障害対応】
✓ 複雑な分散システム障害の根本原因分析
+ 分散トレーシング高度活用（OpenTelemetry）
+ カスタムツール開発による障害分析
+ MTTR 30分以内達成
+ ポストモーテム文化リード
【ビジネス連携 - 重大な追加】
+ 技術的意思決定とビジネス価値の連携
+ コスト最適化戦略（FinOps実践）
+ ROI分析に基づく技術投資判断
+ エグゼクティブへの技術説明能力
+ 市場競争力を考慮した技術選定
【レジリエンスとスケール】
+ 99.9%+可用性設計（年間9時間未満ダウン）
+ マルチリージョン展開
+ カオスエンジニアリング実践
+ 容量計画（12ヶ月先予測）
+ セキュリティアーキテクチャ（ゼロトラスト、コンプライアンス）
**規模感:** 数十万〜数百万ユーザー、数百万リクエスト/秒、50+サービス、3-9ヶ月イニシアチブ
---
### 2. システム全体への広い視野（大局観）
#### **各レベル評価と補強**
**1年目：構成図を読める、主要コンポーネントの役割説明**
- ✅ **適切** - デプロイフロー理解を追加
**3年目：システム全体の詳細構成把握、他システムへの影響考慮**
- ✅ **適切** - 規模感明示推奨
- **追加:** 影響範囲（Blast Radius）評価、5-15サービス連携把握
**5年目：複数プロダクトの連携把握、事業レベルの設計議論参加**
- ✅ **適切** - ビジネス戦略要素強化
- **追加:** コスト・パフォーマンストレードオフ、M&A時技術統合検討
---
### 3. 設計能力
#### **各レベル評価**
**1年目：設計の意図を読み取る、小機能の実装設計**
- ✅ **適切** - デザインパターン基礎、テスタビリティ追加
**3年目：曖昧な要件のヒアリング、DB/API設計**
- ✅ **適切**
- **強化:** API versioning、認証/認可設計、非機能要件定義
**5年目：システム境界の設計、トレードオフ判断、リファクタリング計画**
- ✅ **適切**
- **強化:** サービスメッシュ、イベント駆動、CQRS、HA/DR、ビジネス影響分析
---
## II. 各職種専門スキルの精査
### A. プラットフォームエンジニア
#### **クラウド技術（AWS, GCP）**
**1年目→3年目→5年目の修正:**
【1年目：基本操作 → 具体化】
- EC2/VM、S3/Storage、VPC基本
- IAM基礎
- マネージドDB（RDS）概念
- 目標: AWS Cloud Practitioner相当
【3年目：独力構築 → 詳細化】
- マルチAZ構成設計
- Auto Scaling、Load Balancer
- Terraform/CloudFormation実践
- コスト最適化基礎
- 目標: Solutions Architect Associate相当
【5年目：ガバナンス設計 → 強化】
- マルチアカウント戦略
+ マルチリージョン/マルチクラウド
+ FinOps実践
+ セキュリティガバナンス
+ DR戦略
- 目標: Solutions Architect Professional相当
---
#### **コンテナ技術（Docker, K8s）**
【3年目：本番運用 → 具体化】
- Kubernetes本番管理
- Helm実践
- Ingress、HPA、StatefulSet
+ RBAC、Network Policy
+ クラスタアップグレード
- 認証: CKA推奨
【5年目：クラスタ設計 → 高度化】
- マルチテナント設計
+ カスタムオペレーター開発
+ サービスメッシュ（Istio, Linkerd）
+ マルチクラスタ管理
+ GPU仮想化
- 認証: CKA + CKAD + CKS推奨
---
#### **可観測性 ⚠️ 最重要強化領域**
**現状問題:** 「ダッシュボード利用」「SLI/SLO設計」は表面的、可観測性3本柱が欠落
**修正提案:**
【1年目：基礎可観測性】
- 既存ダッシュボード読解
- ログ検索とログレベル理解
+ メトリクス基本概念
+ アラート対応とランブック
- ツール: Grafana閲覧、ELK検索
【3年目：可観測性3本柱実装 - 大幅強化】
1. メトリクス:
- Prometheus収集設定
- カスタムメトリクス実装
- Grafanaダッシュボード作成
+ Four Golden Signals実装
2. ログ:
- 集中ログ管理（ELK, Fluentd）
- 構造化ログ設計
- ログ相関ID実装
3. トレース:
- 分散トレーシング基礎（Jaeger, Zipkin）
- スパンとトレース理解
【SLO/SLI/エラーバジェット】
+ SLI定義（可用性、レイテンシ等）
+ SLO設定（99.9%等）
+ エラーバジェット計算と追跡
+ SLOベースアラート
【5年目：統合可観測性戦略】
+ OpenTelemetry実装（業界標準）
+ 統合プラットフォーム構築
+ AI/ML異常検知
+ 容量計画（12ヶ月予測）
+ 組織全体の可観測性基準策定
- KPI: MTTR 30分以内、toil 14%以下
**根拠:** Catchpoint 2024調査で81%が2種類以上のテレメトリ使用、Google SREはFour Golden Signals必須
---
### B. ソフトウェアアーキテクト
#### **重大発見**
業界標準では**アーキテクト職は7-9年経験が最低基準**。5年目の「全社技術スタック選定」は過大。
#### **アーキテクチャパターン**
【1年目：概念理解】
✓ モノリシック理解
✓ 基本デザインパターン（GoF）
- 適切
【3年目：パターン実装】
✓ マイクロサービス基礎実装
+ RESTful API設計ベストプラクティス
+ イベント駆動基礎
+ CQRS概念
+ サーバーレスパターン
- 適切
【5年目：選定・提案 - 調整必要】
「全社技術スタック選定」→ 修正:
- チーム/プロダクトレベルのアーキテクチャ選定主導
- 全社技術スタック選定への提案参加
+ ドメイン駆動設計（DDD）
+ サービスメッシュ
+ ADR（Architecture Decision Records）作成
注記: 全社最終決定は通常10-15年経験のプリンシパル/CTO
---
#### **非機能要件**
【3年目：負荷試験実施 → 拡張】
✓ 負荷試験設計・実施
+ セキュアコーディング実践
+ 認証・認可設計（OAuth2.0, OIDC）
+ 水平スケーリング実装
【5年目：HA/DR設計 → 大幅強化】
✓ HA設計（マルチAZ/リージョン）
+ サーキットブレーカー、リトライ、タイムアウト
+ グレースフルデグラデーション
+ 99.9%+可用性実現
✓ DR設計（RPO/RTO）
+ カオスエンジニアリング
+ ゼロトラストアーキテクチャ
+ コンプライアンス対応（SOC2, GDPR等）
+ FinOps実践（コスト最適化）
---
#### **技術選定とDB知識**
**技術選定:**
- 5年目「全社技術スタック選定」→「主要技術選定リードと全社提案参加」に修正
**DB知識補強:**
【3年目追加】
+ クエリ最適化
+ トランザクション管理
+ レプリケーション設定
+ NoSQL基礎（Redis, MongoDB）
【5年目追加】
✓ シャーディング、CQRS
+ イベントソーシング
+ ポリグロット永続化
+ データメッシュ概念
+ データガバナンス
**欠落要素追加:**
- キャッシング戦略、メッセージキュー、API Gateway、BFFパターン
---
### C. エンジニアリングマネージャー
#### **重大発見と構造的問題**
**業界標準:**
- EM移行は**5-7年IC経験後**（Charity Majors）
- 7年未満は技術スキル減衰リスク大
- 管理職は**昇進でなくキャリアチェンジ**
**現状問題:** 1年目から要素があり、段階的成長パスが不明確
#### **修正提案：時系列明確化**
【1-3年目：IC成長期】
- 非公式メンタリング
- 小規模タスクリード
- プロセス理解と参加
【3-5年目：テックリード/シニアIC】
- 正式メンタリング（1-2名）
- プロジェクトリード
- 採用面接参加
+ テックリード役割
+ オンボーディング主導
【5-7年IC後：EM移行オプション】
- キャリアチェンジとしてのEM
- 2-3年EM経験で基本習得
- その後IC復帰またはSenior EM/Director選択
---
#### **ピープルマネジメント**
【3年目：メンタリング - IC視点】
✓ 1-2名メンタリング
- 技術的ガイダンス中心
- 非公式
- 適切
【5年目/EM移行後：目標設定/1on1/評価】
- 週次1on1（キャリア開発中心）
- OKR/KPI設定とトラッキング
- パフォーマンス評価
+ 継続的フィードバック文化
+ 難しいフィードバック提供
+ 心理的安全性醸成 ← Google最重要因子
+ エンゲージメント測定
+ リテンション施策
+ 燃え尽き防止
+ D&I推進
対象: 5-10名直属管理
---
#### **プロセス管理**
【5年目/EM移行後：Four Keys可視化 - 大幅強化】
【DORAメトリクス実装】
1. デプロイ頻度
2. 変更リードタイム
3. サービス復旧時間（MTTR）
4. 変更失敗率
【SPACEフレームワーク - 重大追加】
1. Satisfaction（満足度・ウェルビーイング）
2. Performance（成果重視）
3. Activity（活動量 - 生産性≠）
4. Communication（コラボレーション）
5. Efficiency and Flow（効率とフロー）
+ フロー効率測定
+ WIP制限
+ ベロシティ最適化（KPIとしない）
- ツール: LinearB, Jellyfish等
**根拠:** DORAは「Accelerate」研究ベース、SPACEはMicrosoft/GitHub研究、単一メトリクスは危険
---
#### **技術ビジョンと採用**
【技術ビジョン - EM移行後】
- チーム技術ロードマップ（6-12ヶ月）
- ビジネス戦略整合
+ 技術的負債管理戦略
+ イノベーション時間確保
+ 技術投資ROI分析
【採用・組織設計 - EM移行後】
- 採用ニーズ定義とJD作成
- 面接プロセス設計
+ 面接官トレーニング
+ 候補者体験最適化
+ ダイバーシティ採用
+ Team Topologiesパターン適用:
* Stream-aligned teams
* Platform teams
* Enabling teams
* Complicated subsystem teams
+ コンウェイの法則考慮
- チーム規模: 4-8名（Will Larson推奨）
---
## III. 重大な欠落項目一覧
### 1. 可観測性3本柱 ⚠️ 最重要
- メトリクス・ログ・トレースの統合理解が欠落
- **追加:** 3年目に3本柱統合、5年目にOpenTelemetry
### 2. Four Golden Signals
- Google SRE監視の基本が欠落
- **追加:** 3年目にLatency, Traffic, Errors, Saturation実装
### 3. DORAメトリクス/SPACEフレームワーク
- エンジニアリング効率性測定が欠落
- **追加:** EM移行後に両フレームワーク実装
### 4. 心理的安全性
- Google Project Aristotle最重要因子が欠落
- **追加:** 3年目理解、5年目/EM醸成リード
### 5. エラーバジェット管理
- SRE実践の中核概念が欠落
- **追加:** 3年目計算、5年目ポリシー策定
### 6. セキュリティアーキテクチャ
- セキュリティバイデザイン、ゼロトラスト欠落
- **追加:** 3年目セキュアコーディング、5年目アーキテクチャ
### 7. FinOps（クラウドコスト最適化）
- コスト意識とビジネス連携が欠落
- **追加:** 3年目可視化、5年目戦略実践
### 8. カオスエンジニアリング
- レジリエンステストが欠落
- **追加:** 5年目実験設計と実行
### 9. OpenTelemetry
- 分散トレーシング統一標準が欠落
- **追加:** 5年目実装
### 10. Team Topologies
- 組織設計パターンが欠落
- **追加:** EM移行後に4チーム型適用
---
## IV. グローバル基準との比較
### GAFAM基準
**L3/Entry（0-2年）:**
- ✅ 基礎は一致
- ⚠️ アルゴリズム・DS明示必要
- ⚠️ テスト作成能力必要
**L4/Mid（2-5年）:**
- ✅ 独立実行一致
- ⚠️ スケール感不明確
- ⚠️ 2-3人リード明示必要
**L5/Senior（5-8年）:**
- ✅ システム設計概ね一致
- ⚠️ ビジネス連携弱い
- ⚠️ 3-6人リード不明確
- ⚠️ 組織影響力未定義
### トップティア企業（Netflix/Uber/Airbnb）
**共通高基準:**
1. システム設計 > LeetCode
2. 分散システム必須
3. オーナーシップ文化
4. 本番責任（オンコール）
5. Keeper Test文化
**提供フレームワークで弱い点:**
- システム設計の深度
- オンコール・インシデント対応
- データ品質・可観測性標準
- プラットフォームエンジニアリング
### 国内トップティア企業
**Mercari:**
- 公開Engineering Ladder（最も透明）
- 9原則、行動ベース評価
- 提供版より体系的
**CyberAgent:**
- 13レベルJBキャリア
- 二軸評価（職務・職能）
- 提供版より詳細
**LINE Yahoo/SmartNews:**
- グレードシステム明確
- 市場価値重視
- 提供版と同等〜上
**共通:**
- ICトラック充実
- 半年評価サイクル
- グローバル基準収束
---
## V. 年次別修正サマリー
### 1年目エンジニア：引き上げ推奨
**現状:** HTTP, SQL基礎、応用情報レベル
**追加必須:**
1. ✅ アルゴリズム・データ構造基礎
2. ✅ Git/PRワークフロー
3. ✅ ユニットテスト作成
4. ✅ コードレビュー参加
5. ✅ デバッグ技法
6. ✅ Agile理解
7. ✅ クリーンコード原則
**規模感:** 数十〜数百ユーザー、1-5日タスク
**認証目標:** AWS Cloud Practitioner、応用情報
---
### 3年目エンジニア：可観測性と分散システム大幅強化
**現状:** O記法、N+1クエリ、DB/API設計
**追加必須:**
1. ✅ **可観測性3本柱**（メトリクス・ログ・トレース）
2. ✅ **Four Golden Signals実装**
3. ✅ **SLO/SLI/エラーバジェット**
4. ✅ オンコール参加（サポート付）
5. ✅ インシデント対応・ポストモーテム
6. ✅ 分散システム基礎
7. ✅ セキュアコーディング（OWASP Top 10）
8. ✅ キャッシング戦略
9. ✅ 1-2名メンタリング
10. ✅ Kubernetes本番運用
**規模感:** 数千〜数万ユーザー、秒間数千リクエスト、2-3ヶ月プロジェクト
**認証目標:** AWS Solutions Architect Associate、CKA
---
### 5年目エンジニア/EM移行期：ビジネス連携とレジリエンス
**現状:** 専門知識、障害対応、システム境界設計
**追加必須:**
1. ✅ **ビジネス戦略連携**（ROI、コストトレードオフ）
2. ✅ **FinOps実践**
3. ✅ **セキュリティアーキテクチャ**（ゼロトラスト、コンプライアンス）
4. ✅ **カオスエンジニアリング**
5. ✅ **OpenTelemetry実装**
6. ✅ **サービスメッシュ**（Istio, Linkerd）
7. ✅ **Kubernetes上級**（オペレーター、マルチクラスタ）
8. ✅ **HA/DR設計**（99.9%+可用性）
9. ✅ **容量計画**（12ヶ月予測）
10. ✅ **技術リーダーシップ**（3-6人リード）
11. ✅ **エグゼクティブコミュニケーション**
**調整項目:**
- 「全社技術スタック選定」→「主要技術選定リードと全社提案参加」
**EM移行:**
- 5-7年IC後にキャリアチェンジ選択肢
- DORAメトリクス・SPACE実装
- 心理的安全性醸成
- Team Topologies適用
**規模感:** 数十万〜数百万ユーザー、数百万リクエスト/秒、50+サービス、3-9ヶ月イニシアチブ
**認証目標:** AWS Solutions Architect Professional、CKA+CKAD+CKS
---
## VI. 実装推奨事項
### 1. スキルマトリックス精緻化
**現状問題:** 概念的記述が多い
**改善例:**
❌ 「クラウド技術の基本操作」
✅ 「AWS EC2/S3/VPC基本、IAM理解、Cloud Practitioner相当」
❌ 「可観測性: ダッシュボード利用」
✅ 「Grafana読解、Four Golden Signals理解、SLO定義」
### 2. 認証目標明示
**1-2年:** AWS Cloud Practitioner、応用情報
**2-4年:** Solutions Architect Associate、CKA、Terraform Associate
**4-6年:** Solutions Architect Professional、CKA+CKAD+CKS
### 3. プロジェクト規模明示
**1年目:** ユーザー登録機能、CRUD API、数百ユーザー
**3年目:** マイクロサービス1つ、数万ユーザー、秒間数千リクエスト
**5年目:** マルチサービス連携、数十万ユーザー、マルチリージョン
### 4. ツール・技術の具体化
各スキルに対応する具体的ツール名を明記:
- 可観測性: Prometheus, Grafana, ELK, Jaeger, Datadog
- IaC: Terraform, CloudFormation, Ansible
- CI/CD: Jenkins, GitLab CI, GitHub Actions, ArgoCD
- コンテナ: Docker, Kubernetes, Helm, Istio
### 5. メンターシップとラーニングパス
- 1年目: 勉強会参加、ペアプログラミング
- 3年目: 勉強会主催、技術ブログ執筆
- 5年目: 社内トレーニング設計、カンファレンス登壇
---
## VII. 最終評価と推奨アクション
### 総合評価
**全体:** ⭐⭐⭐⭐☆ (4/5)
**強み:**
- ✅ 構造が明確（共通基盤+職種別）
- ✅ 3段階の年次区分
- ✅ 基本的な技術要素をカバー
- ✅ Four Keys言及（EMセクション）
**弱点:**
- ⚠️ 可観測性が最大の弱点
- ⚠️ ビジネス連携・コスト意識不足
- ⚠️ セキュリティが薄い
- ⚠️ 具体性不足（ツール名、規模感）
- ⚠️ EM開始時期が不明確
### 優先度別アクションプラン
**🔴 最優先（即座に追加）:**
1. 可観測性3本柱とFour Golden Signals
2. SLO/SLI/エラーバジェット管理
3. アルゴリズム・データ構造（1年目）
4. ビジネス連携・FinOps（5年目）
5. EM開始時期明確化（5-7年IC後）
**🟡 高優先（3ヶ月以内）:**
1. 分散システム基礎（3年目）
2. セキュリティアーキテクチャ
3. DORAメトリクス・SPACE詳細化
4. 心理的安全性
5. 規模感・ツール名具体化
**🟢 中優先（6ヶ月以内）:**
1. OpenTelemetry
2. カオスエンジニアリング
3. Team Topologies
4. 認証目標明示
5. プロジェクト例示
### 次のステップ
1. **即座実施:** 本レポートの修正提案を反映し、ver2.0作成
2. **検証:** 社内シニアエンジニア・EMレビュー実施
3. **パイロット:** 一部チームで試験運用（3ヶ月）
4. **反復:** フィードバック収集し継続改善
5. **公開:** Mercariのように公開も検討（採用ブランディング）
---
## VIII. 参考資料とデータソース
### グローバル企業レベリング
- levels.fyi（報酬・レベルデータ）
- Google/Meta/Amazon公開情報
- Pragmatic Engineer Newsletter
### 業界標準フレームワーク
- Google SRE Book（可観測性、信頼性）
- DORA「Accelerate」（メトリクス）
- SPACE Framework（Microsoft研究）
- Team Topologies（組織設計）
- Charity Majors「Engineer/Manager Pendulum」
### 国内企業
- Mercari Engineering Ladder（公開CC0）
- CyberAgent/LINE Yahoo採用ページ
- 各社エンジニアブログ
### 技術標準
- CNCF（Cloud Native Computing Foundation）
- Kubernetes認証プログラム
- AWS/Azure/GCP認証パス
- OpenTelemetry（可観測性標準）
### 調査レポート
- Catchpoint 2024 SRE Report
- Stack Overflow Developer Survey
- State of DevOps Reports
---
## 結論
提供されたエンジニアキャリアパスは**基礎構造は優秀**ですが、**可観測性、ビジネス連携、セキュリティ、EM開始時期**で業界標準から乖離があります。本レポートの修正提案を反映することで、**GAFAM・トップティア企業基準に匹敵する、グローバルで通用するキャリアフレームワーク**に昇華できます。
特に**可観測性3本柱とFour Golden Signals、SLO/エラーバジェット、FinOps、心理的安全性**の追加は必須です。また、具体的なツール名、規模感、認証目標を明示することで、エンジニアが明確な成長パスを描けるようになります。
この精査結果が、日本のエンジニア育成とキャリア開発の向上に貢献することを期待します。
自分なりの使い分け
最終的に自分は、Claudeに大体の方針を決めてもらった後、細かい情報はGeminiで収集させるようにしています
ただただこの記事はClaudeすごいぞ！ということを伝えたかっただけなので特にオチも何もないんですが(笑)、自分がいつも使っているツールから飛び出して新しいツールを使ってみると割と面白い発見があるかもしれませんね