前回の記事で、アーキテクチャチームが複数プロダクトを持つ会社で何を主軸にすべきかを整理した。プラットフォーム化、データ戦略、技術標準のガバナンスなど、横断的な基盤整備と標準化は、アーキテクチャチームの仕事として自然に語られる。
ただ、私がアーキテクチャチームに本当に期待しているのは、「堅牢なアーキテクチャを提供すること」そのものではない。標準化や属人化を防ぎ、誰もが安全に、組織のルールに沿って設計と実装ができる環境をつくることだと考えている。
属人化が組織の資産にならない理由
組織が大きくなるほど、プロダクトのコードベースも膨らみ、複数プロダクトを持つことが当たり前になる。その過程で生まれるのが、アーキテクチャチームのような横断組織だ。課金基盤、認証・認可、共通基盤、プロダクト間の設計標準などは、プロダクトチームだけでは回らない。
問題は、その知見がアーキテクト本人の頭の中に閉じ込められてしまうことだ。
その人が永久に組織にいるわけではない
定年、転職、異動のいずれかは起きる。アーキテクト本人しか知らない判断基準や、口頭でしか伝わっていない失敗談は、会社の資産にはならない。言語化されていない部分がメンバーに共有されていなければ、同じ過ちを繰り返す。
アーキテクチャチームが提供すべきものは、「この人に聞けばわかる」という依存関係ではなく、その人がいなくても同じ品質の判断ができる仕組みだと思っている。
言語化は陳腐化する。それでもやるべき理由
「ドキュメントに起こすと陳腐化が始まる」という指摘は正しい。コードと乖離した設計書、更新されない ADR、誰も読まない Wiki。経験上、放置したドキュメントは確実に古くなる。
それでも、属人化されているよりは圧倒的に有効だ。陳腐化したドキュメントは、少なくとも「かつてこう考えていた」という痕跡が残る。属人化された知識は、その人が去った瞬間に消える。
| 状態 | 陳腐化のリスク | 知識の継承 |
|---|---|---|
| 属人化 | 低い | その人がいなくなれば消える |
| 言語化（放置） | 高い | 痕跡は残るが信頼性が下がる |
| 言語化（更新） | 中程度 | 継承と鮮度のバランスが取れる |
課題は「言語化するかどうか」ではなく、「陳腐化しない仕組みをどう作るか」だ。
Skillとして言語化する
Skillsを入れればAIは賢くなるわけではないという記事で書いた通り、Skillが効くのはAIが知らないことを教えるときだ。一般的なアーキテクチャパターンや設計原則は、モデルがすでに十分な量を持っている。Skillに書いてもノイズになりやすい。
一方で、会社固有の業務ドメイン知識はAIの知識圏外だ。テナント分離の判断基準、過去の障害から学んだ制約、プロダクト間連携でハマった罠などが該当する。こここそがSkillに書くべき中身になる。
AIが知っていること → Skillに書かない（ノイズ）
AIが知らないこと → Skillに書く（価値が出る）
昨今のSkillsの仕組みは、言語化した知識を動的にロードする形式になっている。常時すべてを読み込むのではなく、タスクに応じて必要なSkillだけを起動する（Progressive Disclosure）。これは陳腐化問題への一つの答えにもなる。
- 設計レビューの文脈では、アーキテクチャレビュー用のSkillが起動する
- 認証基盤の改修では、認証・認可のSkillが起動する
- 使われないSkillはコンテキストを圧迫しない
さらに、Skill自体のメンテナンスもAIに任せられる。ルール変更があったとき、関連Skillの更新をAIが提案し、差分を確認してマージする。こうした運用サイクルを回せば、Wiki時代より更新コストは下がるはずだ。
アーキテクチャレビューへの応用
Skillsの文脈で最も効果が出やすいのが、アーキテクチャレビューだと考えている。
これまでアーキテクト本人が行っていたレビューは、その人の経験と勘所に依存していた。「なぜこの設計はダメなのか」を説明できても、それが言語化されていなければ、代理のレビューは品質が落ちる。
Skill化すると、レビューの流れが変わる。
- Skillに沿った自動チェック。決められたルール（テナント分離、API設計規約、セキュリティ要件など）をSkillが先に確認する
- 例外の明示。ルールから外れる設計には「なぜ外したか」を記述させる
- 人間による最終確認。ルール適合と例外理由が整理された状態で、人間はより質の高い判断に集中できる
最終確認を人間が行う必要は変わらない。ただ、Skillが先に走ることで「その人がいないと回らないレビュー」から「誰でも一定品質のレビューができる」状態に近づける。
Skillに書くもの、書かないもの
Skillsの中身は、一般化できるほど薄くなる。業務知識や組織固有の制約が標準化・抽象化されていけば、残るのは「何を使うべきか」という選択ルールだけになる。
| カテゴリ | Skillに書くか | 理由 |
|---|---|---|
| 一般的な設計パターン | 書かない | AIがすでに知っている |
| 自社のテナント分離方針 | 書く | 会社固有の判断基準 |
| 過去の障害から得た制約 | 書く | 経験則はAIの学習データにない |
| プロダクト間連携のルール | 書く | 組織の合意形成の結果 |
| 「REST APIはこう書く」 | 書かない | 業界標準に寄せればSkillは不要 |
| 「うちのAPIはこの形式で書く」 | 書く | 自社標準はAIが知らない |
ただし、システムアーキテクチャには制約がある。可用性要件、コンプライアンス、マルチテナント設計などの領域は、完全にSkillゼロにはできない。一般論と自社固有の境界線の中で、最低限守らなければならないSkillを定義する必要がある。
目指す状態
整理すると、アーキテクチャチームが目指すべき状態はこうだ。
- 各アーキテクチャ文脈に最低限のSkillを定義する。認証、課金、データ連携、API設計など、文脈ごとに「これだけは守れ」というSkillを持つ
- レビューにSkillを組み込む。設計レビューの前段でSkillがチェックし、例外は明示させる
- Skill自体をメンテナンスする仕組みを持つ。陳腐化を放置せず、変更があったらSkillも更新する
- 属人化に依存しない。特定の人がいなくても、同じ品質の判断とレビューが再現できる
前回の記事で書いた「各プロダクトが速く動けるための土台を作り、プロダクト間の矛盾を防ぐ」という主軸は変わらない。Skillsは、その土台の上に判断の再現性を載せるための手段だ。
アーキテクトがコードを書くより「何を直す順番か」を決めるフェーズに入った組織ほど、Skill化の効果は大きい。そこで必要なのは個人の技術力ではなく、組織としての判断基準を次の世代に渡す仕組みだからだ。
まとめ
アーキテクチャチームの仕事は、堅牢なシステムを一人で作ることではない。誰もが安全に設計・実装できる環境をつくり、属人化された知見を組織の資産に変えることだ。
言語化は陳腐化する。それでも、属人化よりはるかにマシだ。そして今は、その言語化をSkillsという形式でAIに渡し、レビューとメンテナンスの両方に活かせる時代になった。
一般論はAIに任せ、自社固有の知識だけをSkillに残す。各文脈の最低限のSkillと、それを使ったレビューの仕組みが、属人化に依存しないアーキテクチャ組織への一歩になると考えている。