Architect 学習ロードマップ

学習の優先順位は「広く浅く」ではなく 境界を決めるために深く学ぶ である。 Chief Architect は 5 つの深い柱を持ち、その柱の交点で trade-off を判断するのが仕事である。 全ての technology を equally に深く知ろうとすると深さが出ず、 結果として decision の根拠が weak になる。 以下は AI インフラ事業向けの優先順位だが、 domain が変わっても上位 2 項目 (systems engineering と platform engineering) はほぼ普遍である。

第一優先 — Systems Engineering

interface management、 risk management、 phase gate、 tailoring、 compliance matrix 的な考え方を理解すると、 software architect の視界が一段広がる。 software 外の future scope (datacenter、 silicon、 partner integration) を破綻させずに吸収する 共通言語 がここから来る。

具体的に学ぶべき教材:

• NASA Systems Engineering Handbook (NASA/SP-2016-6105) の SEMP / KDP / tailoring の章
• INCOSE Systems Engineering Handbook の interface management
• SEI / CMU の ATAM と QAW の元論文

software-only の architect から system-level architect へのジャンプは、ここを学ばないと起きない。

第二優先 — Platform Engineering の Product Thinking

internal platform は infra の寄せ集めではなく、「internal customer の体験を設計する product」である。 self-service、 golden path、 shared roadmap、 open forum、 reusable capability の設計を学ぶと、 UI、 dashboard、 API、 automation engine、 data service を 1 つの platform experience に束ねられるようになる。

主要リファレンス:

• CNCF Platforms White Paper
• Team Topologies (Skelton & Pais)
• Internal Developer Platform / Platform Engineering の最新文献

product manager のメンタルモデルが必要で、 backlog 駆動ではなく user journey 駆動で考える訓練を要する。

第三優先 — Cloud Control Plane 設計

multi-account / landing zone / identity / governance / policy / resource isolation / degraded mode を 体系で理解 することが重要である。 ここを誤ると後から auth、 secret、 quota、 audit、 billing、 compliance が全部ばらばらに生える。 逆にここを押さえると、分散認証、計算資源 allocation、仮想化、 BI dashboard、 API 設計の多くが自然に整列する。

学習リソース:

• AWS / Azure / GCP の Well-Architected Framework (3 つとも読む)
• Multi-account / landing zone のリファレンス実装 (AWS Control Tower、 Azure Enterprise Scale)
• Open Policy Agent (OPA) の policy-as-code 設計

「クラウドで何ができるか」ではなく「クラウドの制御面はどう構造化すべきか」を学ぶ。

第四優先 — Reliability / Observability / Security の一体運用

Well-Architected の非機能 pillar、 SLO と error budget、 DORA、 vendor-neutral telemetry、 threat modeling、 zero trust、 secure SDLC、 supply chain integrity を 1 つの operating model として学ぶ。 大手 partner が評価するのは機能量より「障害時にどう振る舞うか」「根拠ある統制があるか」である。

主要文献:

• Google SRE / SRE Workbook (SLO / error budget の bible)
• DORA State of DevOps Report 各年版
• NIST SSDF (Secure Software Development Framework)
• OpenTelemetry の semantic conventions
• SLSA (Supply chain Levels for Software Artifacts)

これらを 個別に学ぶのではなく 、 operating cadence (monthly review、 quarterly retro、 incident postmortem) の中で連動させる感覚を養うのが肝である。

第五優先 — AI Inference Platform の実務論

kernel 開発や chip 設計に深く入る必要はまだないが、 GPU-aware scheduling、 inference autoscaling metric、 edge survivability、 data residency、 protocol integration の現状は把握しておく。 特に MCP は ecosystem 的には重要 だが、現時点では enterprise readiness が発展途上なので、 core dependency ではなく周辺 integration として扱う目線が有効である。

学ぶべきトピック:

• Kubernetes Device Plugin と GPU Operator
• vLLM / TensorRT-LLM などの inference engine の autoscaling 指標
• model serving の cold start / warm pool 設計
• MCP の現状仕様と enterprise readiness gap (governance、 audit、 supply chain)
• inference workload の cost model (per-token、 per-second-GPU、 reserved capacity の交差点)

ここは進化が速いので、「永続的な knowledge」と「半年で陳腐化する detail」を区別して学ぶ。 永続的なのは設計原則 (control / data 分離、 SLO 駆動、 multi-tenancy)、 陳腐化するのは specific tooling (今の Kubernetes API バージョン等)。

学習を decision に接続する習慣

5 領域を学ぶこと自体は手段にすぎない。 重要なのは、各領域での学習を ADR や interface catalog に 具体的な根拠として appendix することである。「なぜこの decision か」の justification 欄に「DORA の Elite cluster は deployment frequency on-demand を達成しているから」のような形で学習成果が現れる状態が、 学習の deliverable である。

書籍を読了することではなく、 実 project の decision に根拠が増えることが学習の measurable outcome である。