Chief Architect 最初の 90 日

最初の 90 日は「architecture pack」を完成させる期間ではなく、「architecture system」を稼働開始させる期間である。 文書は手段、 cadence と decision forum が目的である。 30 日 × 3 ブロックの分割は、複雑性を順次積み上げる構造で、 各 block の出口が次の block の前提になる。 加速のために順序を圧縮しようとすると、後段の cadence が文書の量に押しつぶされて止まる。

0–30 日 — 定義する期間

最初の 30 日は「調べる」より「定義する」期間である。 owner と主要 lead への interview を終え、次の初版を作る:

• architecture charter 初版 — mission、 scope、 phase、 decision authority、 tailoring 方針
• domain map 初版 — system context、 主要 container、 partner 接続、 edge / control plane / data plane の関係
• quality attribute scenario 初版 — availability、 latency、 security、 auditability、 modifiability の具体 scenario と response measure
• risk register 初版 — top 20 程度の technical / operational / commercial risk の identification と severity 評価

この時点のゴールは「全部わかること」ではなく、「何を今決め、何を先送りし、何を実験で潰すか」が明文化されることである。 QAW と systems engineering 的な early concept exploration がここで効く。

注意点:

• charter v1 は 5–10 ページ に収める。 50 ページ書こうとすると 30 日では終わらない
• domain map は完璧を目指さず、 v0.5 として共有して反復する
• scenario は 10–20 個でよく、後から追加する。最初から 100 個出すと優先順位が消える
• risk register は ownership と review cadence (月次か週次か) を最初から決める

30 日終了時の review で、 owner と 主要 lead が「読んだ」「合意した」までいかなくても 「読んで反論を提出した」 状態になっていれば成功である。

31–60 日 — Architecture Pack を作る期間

次の 30 日は「architecture pack を作る」期間。 以下を出す:

• tenant / resource model — /org → /account → /project → /site → /cluster の階層と policy 適用点
• identity / governance blueprint — federation 方式、 token lifecycle、 policy-as-code の deploy path
• control plane / data plane の failure model — 中央切断時の degraded behavior、 reconcile 戦略
• initial ADR 群 — top 10 程度の architecturally significant decision を ADR 化
• 主要 interface catalog — internal / external API、 event schema、 partner integration の owner 付き一覧
• high-risk 領域の PoC 結果 — tenant isolation、 distributed auth、 inference autoscaling 等の検証結果

ここで重要なのは、 detailed design の量ではなく、後で高価に壊れる decision を少なくすること である。 50 個の component を中途半端に設計するより、 5 個の不可逆 decision を確実に decided / deferred / experimenting に分類する方が価値が高い。

PoC のチェックリスト:

• novel か (既知技術の組み合わせなら PoC 不要)
• expensive to reverse か (設定変更で巻き戻せるなら PoC 不要)
• 複数 sub-decision の前提になっているか (前提が崩れる影響が大きいほど優先度高)

rejected option も含めて decision を残す。半年後に再検討する人 (自分自身を含む) のコストを下げる最大の手段である。

61–90 日 — Governance を稼働させる期間

最後の 30 日は「governance を稼働させる」期間。 以下を動かし始める:

• lightweight な ARB (architecture review board) — 隔週 1 回、 1 時間以内
• central repository — 全成果物の single source of truth
• review template — design review、 ADR review、 PoC retro の標準フォーマット
• approval rule — どの decision が ARB を必要とし、どの decision が team-local で済むか
• exception process — baseline からの逸脱をどう justify / track / closure するか
• operating scorecard — SLO、 DORA、 cost、 incident readiness の baseline 値設定

self-service の最小単位として、1 つか 2 つの golden path を作る。 例: 「partner 向け新 service を deploy する path」「new edge site を onboard する path」。 完璧でなくてよいが、 documented で再現可能なものにする。

observability baseline、 policy baseline、 SLO baseline を置いて、ここから measurable に運用が始まる。 architecture は文書ができたときではなく、 review と implementation に接続されたとき に初めて機能する。

90 日の出口条件

90 日の出口条件は明確である。「Chief Architect として start できた」と言えるのは、 architecture pack があるからではなく、少なくとも次の状態がそろったときである:

1. mission と scope が一文で説明できる — 30 秒以内で stakeholder に語れる
2. top 10 前後の architecturally significant decision が ADR 化されている — rejected option も含めて
3. critical interface が owner 付きで一覧化されている — orphan interface ゼロ
4. 3〜5 個の高リスク前提が PoC 済み — green / red / inconclusive の判定が出ている
5. SLO / DORA / risk review の cadence が動き始めている — 実際に 1 回以上 review が完了している

ここまで行けば、「設計者」から「architecture system の運営者」へ移行できている。 設計者は decision を出すたびに work を生むが、運営者は cadence と forum と template を稼働させて、 decision が自動的に流れる system を持つ。

92 日目以降は「architecture pack の精緻化」ではなく、「operating cadence の steady state 化」「partner integration の本格化」「次の phase gate の準備」へ移行する。 90 日 plan は完了する目的の plan であり、 完了後は同じ方法論を継続するのではなく、 次のレベル (multi-region、 federation、 silicon integration 等) の architectural problem へ stack を切り替える。