Chief Architect 立ち上げ playbook

大規模 AI インフラ事業の Chief Architect は、最初に「全レイヤーを設計し切る」のではなく、「architecture mission の定義・先送り基準・quality 評価軸・decision forum」を制度化することから始めるべきである。本シリーズは CNCF / NASA SEMP / SEI ATAM / DORA など複数のリファレンスに依拠し、最初の 90 日で機能する operating system を構築する手順をまとめる。

なぜ Chief Architect は最初を間違えやすいか

大規模で長期 lifecycle を持つ system program は、 software project のメンタルモデルでは破綻する。理由は 3 つある。第一に、 architectural decision の不可逆性が高く、後から低コストで巻き戻せない。第二に、 stakeholder が partner、 security、 operations、 future hardware まで広範に分散する。第三に、 quality attribute (availability、 latency、 security、 modifiability 等) が要件として現れず、シナリオに具体化しない限り設計に反映されない。

この 3 つを踏まえると、最初の仕事は「決めること」ではなく「決め方を決めること」になる。具体的には mission 定義、 decision forum、 quality 評価尺度、 risk register、 review cadence の整備である。これらが揃って初めて、複数の team が並列に実装しても全体が整合する。

このシリーズの構成

全体を貫く 3 つの原則

第一は architecture は gate で締める、 implementation は iteration で回す という二重運転である。 delivery が agile であっても、 architectural decision は phase と Key Decision Point で区切るべきであり、両者を混同すると不可逆 decision が sprint 単位で量産される。

第二は architect はヒーロー化しない という制度設計である。 formal review の目的は architect を最終承認者にすることではなく、 security / development / infrastructure / operations の視点を早期に入れて rework を減らすことにある。 review process には shepherd がいても、 single overall decision maker は置かない。

第三は 非機能要求は願望ではなく measurement system である。 reliability は SLO/SLI、 delivery は DORA 5 指標、 security は threat model と control baseline、 cost は scorecard で常時測る。 required quality は文書ではなく運用 system として実装されたとき初めて機能する。