Architect の役割定義

大規模 AI インフラ事業における Chief Architect は、 chief software architect ではなく chief systems architect に近い位置にいる。 個別 component の設計そのものより、 system 全体の boundary、 trade-off、 interface、 quality criteria、 technical risk を成立させることが本来の責務だからである。 architect は stakeholder から入力を集め、 business context を理解し、 happy path だけでなく observability や supportability まで含めて設計し、 accepted risk と rejected option を明文化する。 cross-domain の大型案件では、これに interface 管理と external contribution の統合責任が加わる。

chief systems architect としての mission 定義

mission 文は次のように書けると強い。「私は、 partner 企業向け AI infrastructure の software scope に対して、 architecture principles、 quality attributes、 interface contracts、 decision rules、 validation criteria を定義し、複数 team が独立に実装しても全体が整合する状態を作る」。

この定義の要点は manager 的責務と architect 的責務を分離している ことである。人員・予算・ sprint 管理は owner / PM 側に残しつつ、 architect は architecture vision、 architecturally significant requirements、 critical interfaces、 high-risk assumption の検証、 review readiness を保持する。

定義を曖昧にすると 2 通りの失敗が起きる。第一は architect が manager 化してしまい、 sprint の進捗管理に時間が取られて architectural decision を下すための調査時間が無くなる。第二は architect が個別 component の implementer 化してしまい、 partner 統合や cross-domain interface の議論に出席できなくなる。 mission 文は両方の drift を防ぐための文書化された防壁になる。

「最終承認者」になってはいけない理由

architect は 最終承認者であり続ける人 (hero) になってはいけない。 formal な architecture review の仕組みを作る理由は、 architect をヒーロー化するためではなく、 security、 development、 infrastructure、 operations などの視点を早期に入れて rework を減らすためである。 review process には shepherd がいてもよいが、その人は single overall decision maker ではない、という整理は極めて重要である。

作るべきなのは「すべてを自分で決める権限」ではなく、「どの decision を、どの forum で、どの evidence に基づいて決めるか」という制度である。具体的には:

• architecturally significant decision のみ ARB (architecture review board) に上げる
• それ以外は team-local decision に委譲し、 ADR で記録だけ残す
• conflict が生じたときの escalation path と tie-breaker 役を事前に決めておく
• 「architect の hero approval 待ち」が定常 critical path にならないよう capacity を設計する

ヒーロー型 architect は短期的には decision velocity が出るが、長期的には rework を増やす。早期に他視点を取り込めなかった decision は、 implementation が進んでから security レビューや SRE レビューで覆ることが多く、結果として最も高くつく。

owner / PM との責務境界

owner / PM (project manager) と architect の責務境界は、 mission 定義の段階で明文化しておくと後からの摩擦が減る。一般的な分担は次の通り。

Owner / PM 側の責務:

• 人員配置・予算・採用
• sprint planning と backlog 管理
• stakeholder への進捗報告
• delivery commitment と timeline 調整
• vendor / partner との commercial 交渉

Architect 側の責務:

• architecture mission と principle の定義
• architecturally significant requirements の特定
• critical interface contract の設計と owner 任命
• high-risk assumption の PoC 計画と結果評価
• ADR log の維持と decision forum の運営
• review template、 quality attribute scenario、 threat model の baseline 提供

境界が曖昧になりやすいのは、 capacity planning (人がどこに足りないか) と risk-driven scope decision (何を delay するか) の領域である。これらは 2 者の co-decision として運用するのが現実的で、どちらか一方が単独で決めると、もう一方の base assumption を破壊しやすい。週次の owner-architect sync を定例化し、決定事項は ADR ではなく decision log (より軽量) に残すのが穏当である。