1. ハリボテの上に何を建てても揺れる
大企業のIT部門でスポットコンサルティングに入ると、繰り返し出会う光景がある。システムは動いている。業務は回っている。だが構造がない。
個別の要件に応じて個別のシステムが作られ、それらがAPIやCSVファイルやExcelマクロで繋がれている。全体像を把握している人間はいない。新しい要件が来るたびに、既存の何かの横に新しい何かが継ぎ足される。
そしてある日、経営層が言う。「エンタープライズアーキテクチャをやろう。」
しかし、ハリボテの上にEAを載せようとすると何が起きるか。既存システムとの整合性の調整、部門間の政治、移行コストの見積もり。本質的な構造設計の議論ではなく、現状をどう正当化するかの議論に時間が消える。
EAの最大の敵は、技術的負債ではない。
「今動いている」という事実である。
2. 初期設計としてのEA
EAには二つの姿がある。
| 後付けのEA | 初期設計のEA | |
|---|---|---|
| 目的 | 現状の整理と改善 | 構造の原則を最初に定める |
| 制約 | 既存システム・組織・政治 | なし（白紙から設計できる） |
| 成果物 | 現状のドキュメント化、段階的移行計画 | 判断基準となる設計原則 |
| リスク | 政治と妥協で骨抜きになる | 実装段階で原則が守られるかどうか |
後付けのEAは「地図を描く作業」に近い。すでに存在する街の道路を測量し、記録する。それ自体に価値はあるが、街の構造は変わらない。
初期設計のEAは「都市計画」に近い。道路を引く前に、水道管と電線をどこに通すかを決める。後から掘り返す必要がない。
3. トキストレージのアーキテクチャ
トキストレージは一人で運営するプロジェクトである。しかし、初期に定めた設計原則がある。
原則1：データはQRコード内に自己完結する
音声も画像もURLパラメータとしてQRコードに埋め込まれ、永続すべきデータは外部サーバーに一切依存しない。運用処理（注文受付・問い合わせ・アクセス解析）にはCloudflare WorkersやGASを活用するが、QRコードに刻まれたデータ自体はそれらと無関係に再生できる。この原則があるから、サーバー障害・サービス終了・企業の倒産が「データ消失」に繋がらない。
原則2：レイヤーごとに責務を分離する
QR生成ツール、物理製造、三層保管（GitHub・NDL・物理媒体）は、それぞれ独立したレイヤーとして設計されている。あるレイヤーの変更が他のレイヤーに波及しない。
原則3：セキュリティはアーキテクチャで担保する
パイプラインを通るデータはすべて公開前提だ。QRコードに刻まれた音声は最終的に物理製品・GitHub・NDLに届く。注文情報としてCloudflare WorkersやGASを経由するが、すべて公開を前提としたデータだ。クレジットカード情報はWiseが直接処理し、パイプラインを一切通らない。パイプラインに秘密が存在しない。コードを公開しているから、隠れた脆弱性が発見される。静的サイトだから、サーバーサイドの脆弱性が存在しない。セキュリティを「追加する」のではなく、守るべき秘密が「構造的に存在しない」設計。
原則4：ガバナンスはレイヤーに応じて設計する
QR生成はクライアントサイドで完結するため、コンテンツの検閲は行わない。物理製造は私的所有物であり、スキャンしない。NDL納本はニュースレターの編集過程を経るため、禁止事項に該当するコンテンツは掲載を見送る。どのレイヤーで何を制御し、何を制御しないかが明確に定義されている。
4. ガバナンスはアーキテクチャに内包される
多くの組織で、ガバナンスはアーキテクチャとは別に議論される。セキュリティポリシー、データガバナンス、コンプライアンス。それぞれ別の文書があり、別の担当者がいて、別の会議体で審議される。
しかし本来、ガバナンスとはアーキテクチャの一部である。「誰が何を制御できるか」は、システムの構造が決める。構造が曖昧なら、ガバナンスも曖昧になる。
トキストレージでは、ガバナンスがアーキテクチャに内包されている。
- プライバシー — サーバーにデータを送らない設計が、データ保護規制への対応を不要にする
- コンテンツ制御 — レイヤーごとに制御の有無と根拠が定義されている
- 透明性 — コードが公開されているから、ガバナンスが口約束ではなく検証可能な事実になる
- 永続性 — QRコードに自己完結するデータは、組織のガバナンス体制が変わっても影響を受けない
ガバナンスを「ルールで縛る」のではなく、
「ルールが不要な構造を設計する」。
5. 規模ではなく構造の問題
EAは大企業のためのものだという誤解がある。数千人の組織、数百のシステム、数十の部門を横断する整理術だと。
しかし、EAの本質は「構造に関する意思決定を、実装より前に行う」ことである。その定義に規模の条件はない。
一人のプロジェクトであっても、最初に構造を決めなければ、機能を追加するたびに「どこに何を置くか」で迷い、判断がぶれ、技術的負債が積み上がる。逆に、原則が最初に定まっていれば、判断に迷わない。新しい機能は、原則に照らして「ここに置くべきだ」と自然に決まる。
大企業でEAが難しいのは、規模が大きいからではない。初期設計なしで走った距離が長いからである。
6. 多段階承認という構造的敗北
後付けのガバナンスが行き着く先は、多段階承認フローである。
構造が曖昧だから、変更のリスクを誰も評価できない。評価できないから、多くの人間に確認を求める。セキュリティレビュー、アーキテクチャレビュー、コンプライアンスチェック、部門長承認。行ったり来たりして開発ライフサイクル全体の推進が阻害される。
これはガバナンスの成功ではなく、アーキテクチャの不在に対する代償である。
構造が明確なら、変更の影響範囲は自明になる。自明なら、承認フローは軽くなる。多段階承認が必要な組織は、「慎重な組織」ではなく、「構造を持たない組織」である。
7. 結論 — 最初の設計が最後まで残る
アーキテクチャは後から追加できない。
最初に設計するか、永遠に不在のまま走り続けるか。
その二択に中間はない。
エンタープライズアーキテクチャとは、フレームワークの名前でも、コンサルティングファームの商品でもない。「構造に関する意思決定を、実装より前に行う」という態度のことである。
トキストレージは一人のプロジェクトだが、初期設計としてのEAがある。だからこそ、QR生成ツールの上に物理製造が載り、その上にNDL納本が載り、さらにその上にコンテンツガバナンスが載っても、構造が揺れない。
大企業であれ一人であれ、問いは同じだ。最初に構造を決めたか。その答えが、プロジェクトの全生涯にわたって効き続ける。