Architectural Discovery プロセス

大規模案件の kickoff は、「反復開発」と「段階ゲート」を二層で回すのが現実的である。 delivery 側は agile に反復してよいが、 architecture 側は distinct phase と decision gate を持つべきである。 major system の life cycle を phase と Key Decision Points で区切る考え方は複雑系で特に有効であり、 同時に DORA が示すように delivery performance は throughput と instability の両面で継続測定される。 つまり「architecture は gate で締める、 implementation は iteration で回す」二重運転である。

Discovery から始める — design ではなく

最初の手順は、 design からではなく architectural discovery から始めるべきである。 design 文書は discovery が終わってからしか正しく書けない。 discovery のステップは次の通り。

第一に、 owner、 infra / security / data / operations の代表と短い interview を行う。引き出すべき項目は: business goal、 promised capability、 unacceptable failure、 required compliance、 expected partner experience。この時点で具体的な technical 解は議論しない。

第二に、 SEI の Quality Attribute Workshop (QAW) に相当する短時間の集約 session を行う。 availability、 latency、 security、 interoperability、 auditability、 modifiability などの quality attribute を、 抽象な要求ではなく具体的な scenario に落とす (例: 「東京 site が 6 時間切断したとき、 大阪 site の inference は既存 model で degraded mode で動き続ける」)。

第三に、 ATAM (Architecture Tradeoff Analysis Method) 的に「どの quality がどの quality と衝突するか」を見える化する。 availability vs cost、 latency vs security、 modifiability vs simplicity の trade-off は隠したまま設計を進めると後から衝突する。ここまでやって初めて、 feature list ではなく architectural problem が定義されたと言える。

PoC の対象を「不可逆 decision」に絞る

discovery で問題が定義できたら、次は 高リスク領域だけを PoC で潰す。 PoC の対象は「novel で expensive to reverse な decision」に絞るべきで、すべてを prototype する必要はない。 PoC の役割は実装サンプルではなく、 architectural decision の根拠材料である。

典型的な PoC 候補:

• Tenant isolation の実装方式 (namespace、 cluster、 account 単位の分離強度)
• Site 障害時の degraded mode (中央 control plane 切断時に edge が何をどこまで継続できるか)
• Distributed auth の trust chain (federation、 token propagation、 revocation latency)
• Inference workload の autoscaling 指標 (request count では不適切、 GPU memory pressure や queue depth が候補)
• Audit trail の整合性 (multi-region で順序保証どこまで取るか)

architect の checklist でも、 high-risk assumption の working code 検証と、 rejected option を含む decision record の維持が強く勧められている。 PoC で「動かなかった」結果は、 ADR の “rejected options” 欄に残すことで再検討時の重複コストを下げる。

軽量だが formal な technical plan

project 全体には「軽量だが formal な」 technical plan が必要である。 NASA の Systems Engineering Management Plan (SEMP) はそのまま導入する必要はないが、発想は極めて有用である。 つまり「どの process を、どの粒度で、どの phase に、誰が責任を持って適用するか」を先に書く、ということ。

SEMP-like document に含めるべき項目:

• phase 区分と Key Decision Point (KDP) の定義
• tailoring 方針 (どの phase でどの process を簡略化するか)
• decision authority matrix (誰がどの種類の決定を下すか)
• review template と review cadence
• technical risk process (識別・評価・mitigation・closure)
• external effort 統合 ruleset (datacenter team、 silicon team、 partner integration)

特に external effort が混ざる案件では、 source selection、 performance monitoring、 external products の transfer / integration を plan に含めるべきである。 future hardware (silicon) や partner 統合を視野に入れる project では、この SEMP-like architecture operating manual が極めて有効に機能する。

文書を作ること自体は目的ではなく、文書を review forum と implementation feedback ループに接続する ことが肝である。書いただけで運用されない SEMP は無いより悪い。