Chief Architect の成果物

architecture を人依存にしないために、 Chief Architect は最初から「single source of truth」を持つべきである。 central repository を置き、 decision、 diagram、 policy、 review 結果、 risk、 PoC、 運用基準をそこに集約する。 single source があると review が速くなり、 audit や incident response にも効く。 Chief Architect が交代しても「architecture state」が継承可能になることが目的である。

必須の初期成果物 8 点

1. Architecture Charter (SEMP-like Technical Plan)

project の scope、 phase、 review gate、 tailoring 方針、 decision 権限、 technical risk process を定義する文書。 cross-domain で external effort が絡むなら必須。 NASA SEMP の発想を tailoring したものでよく、 100 ページの大作にする必要はない。 重要なのは「誰がどの decision を下すか」「どの phase でどの review が走るか」「risk はどう識別・追跡・closure するか」が一意に書かれていること。

2. System Context と Domain Map

C4 model 的な system context、 container、 component、 deployment の図を使い、 partner、 edge site、 control plane、 data plane、 外部依存の関係を可視化する。 図は 1 種類で全てを表現しようとせず、 zoom level ごとに別図を持つのが実務的。 system context (最外周) → container (主要 deployable 単位) → component (内部構造) → deployment (物理配置) の 4 階層で十分なことが多い。

3. Quality Attribute Scenario カタログ

availability、 latency、 security、 auditability、 portability、 modifiability などを scenario と優先順位 で表にしたもの。 feature backlog より先に必要である。各 scenario は刺激 (stimulus)、 環境 (environment)、 反応 (response)、 反応指標 (response measure) の 4 要素で書く。 「important」のような形容詞ではなく、「99.9% monthly availability で 43 分 / 月 error budget」のような測定可能形式で書く。

4. Interface Catalog と Ownership Matrix

API、 event、 schema、 identity federation、 key 管理、 site 間通信、 future hardware interface を 列挙し、 owner と compatibility rule を持たせる。 interface は contract として扱い、変更は backward compatibility ルールに従う。 owner 不在の interface は腐敗するので、必ず誰かに割り当てる。 versioning policy (semver か date-based か、 deprecation period 何ヶ月か) も明記する。

5. ADR Log (Architecture Decision Records)

append-only の意思決定記録 で、 options considered、 decision、 trade-offs、 confidence、 superseded 関係まで残す。 architecture の記憶装置である。 採用 option だけでなく rejected options を残すことが鍵で、これによって「半年後に同じ議論を 0 から再開する」浪費を防げる。 ADR 1 件は 1〜2 ページが目安、それ以上は分割するか別文書に切り出す。

6. Threat Model と Control Baseline

threat modeling の結果、 zero trust の前提、 secure SDLC、 supply-chain controls、 container / microservices の security baseline をまとめる。 STRIDE や PASTA などの方法論は project に合わせて 1 つ選び、混在させない。 baseline は default で適用される control set として記述し、 exception は明示的な ADR で justify する。

7. Reference Architecture と PoC 結果

正式採用前の high-risk decision を、 architecture pack と benchmark / failure test の形で根拠化する。 PoC は architecture の言い訳ではなく、逆に意思決定の証拠である。 PoC が「動かなかった」結果も同等に価値があり、 ADR の rejected options 欄に直結する。 reference architecture は完成形ではなく、「現時点で最もよく分かっている形」のスナップショットでよい。

8. Operating Scorecard

SLO、 error budget、 DORA、 cost、 compliance、 availability、 incident readiness の baseline を持つ scorecard。 architecture が deliver している価値を 数値で管理できるようにする。 月次 / 四半期で review し、 trend を見る。 scorecard 単発の値より、 trend の方向と速度の方が判断材料として強い。

成果物を機能させるための 3 原則

第一に、全成果物を 1 つの central repository に置く。複数 tool に分散すると ownership が曖昧になり、 audit 時に再構成コストが膨らむ。 magi のような GitHub-based KB でも、 Confluence でも構わないが、「ここを見れば現状が分かる」場所を 1 つに絞る。

第二に、append-only と immutable の使い分けを明確にする。 ADR は append-only (decision を取り消すときは新 ADR で supersede)、 reference architecture は immutable snapshot を tag つきで保存する。 mutable にすると過去の decision の context が失われる。

第三に、review forum と implementation feedback ループに接続する。書いただけで運用されない artifacts は無いより悪い。 ARB、 design review、 PoC retrospective が定例として動き、その結果が artifacts に反映される循環を作る。 architecture は文書ができたときではなく、 review と implementation に接続されたときに初めて機能する。