Architecture Modeling：図を意思決定・影響分析・移行へ使う
良いarchitecture modelは情報量が多い図ではなく、特定のstakeholderの問いへ答えるviewです。モデル、viewpoint、catalog、matrix、ADRを使い分けます。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Model・View・Viewpointの違い
- Catalog・Matrix・Diagram・ADRの使い分け
- cross-layer traceabilityによる変更影響分析
体験48 · EA MODELING（図を意思決定へ使う）
詳しい情報を1枚の図に全部詰め込むほど、良いモデルになるか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際のarchitecture mapとtraceabilityの例を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
詳しい情報を1枚の図に全部詰め込むほど、良いarchitecture modelになると思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
経営者と運用担当者は、同じ詳しさの図を必要とするでしょうか？
ヒント2を見る
図の美しさと、意思決定に使える性質は同じでしょうか？
もっと詳しく：この問いで使う専門用語
- Viewpointは、誰のどの関心に答えるかを定めた表現方法です。
- Traceabilityは、目的、要件、設計、実装、test、運用証拠をたどれる性質です。
- ADRは、重要な設計判断の背景、選択肢、結論、結果を残す記録です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Architecture Modelは現実そのものではなく、特定の関係者が特定の判断をするための見方です。
catalog、matrix、diagram、ADRを使い分け、要件から実装・運用証拠まで追跡できる形にします。
図の美しさではなく、所有者、更新時点、根拠、未解決事項が明確で意思決定に使えることが品質です。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Viewpoint
誰のどの関心に答えるかを定めた表現方法です。
経営者と運用者では必要なdetailが違うためです。
経営には能力とrisk、開発にはservice依存、運用には障害経路を示します。
Traceability
目的、要件、設計、実装、test、運用証拠をたどれる性質です。
変更の影響と統制の実在を説明するためです。
二重送金防止要件からidempotency制約とtestまで追跡します。
ADR
重要な設計判断の背景、選択肢、結論、結果を残す記録です。
後から理由を失い、同じ議論や誤った変更を繰り返さないためです。
金融判断をDB RPCに置いた理由などを記録できます。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
1枚ですべてを説明しない
同じrepositoryから目的別viewを作れることが理想です。別々のPowerPointが独自の事実を持つと、更新時に矛盾します。
| Stakeholder | 関心 | 適したView |
|---|---|---|
| 経営 | 投資が能力とriskへどう効くか | capability heatmap、roadmap |
| 業務 | 顧客価値と例外を誰が担うか | value stream、process、actor |
| 開発 | service・data・APIの境界 | context、container、dependency |
| 運用 | 障害がどこへ波及するか | runtime、dependency、failure domain |
| Security | identity・data・trust boundary | data flow、threat model |
| 監査 | ruleからcontrolと証拠を追えるか | traceability matrix |
4種類のartifact
| Artifact | 答える問い | 例 |
|---|---|---|
| Catalog | 何が存在するか | application、data entity、technology standard一覧 |
| Matrix | 何と何が関係するか | capability×application、data×owner |
| Diagram | 構造・流れ・依存はどうか | context、data flow、deployment |
| ADR | なぜこの判断をしたか | 選択肢、trade-off、前提、結果 |
Cross-layer traceability
この鎖があれば、DB制約変更が顧客契約へ与える影響、business rule変更がAPI・data・testへ与える影響を追えます。
- 01Driver：二重送金riskを下げる
- 02Requirement：同じrequestは資金移動1回
- 03Business Rule：受付番号を操作単位で再利用
- 04Application：Idempotency-Keyを受けるAPI
- 05Data：owner＋keyのuniqueとfingerprint
- 06Technology：transactionとunique constraint
- 07Evidence：retry・concurrency testとaudit
Model hygiene
Minibankではコード参照をSOURCE TRAILとして教材へ結び、文章だけの保証と実装済みの証拠を分けています。
- elementにowner・lifecycle・criticalityを持たせる
- logicalとphysical、currentとtargetを混ぜない
- 矢印へ意味・方向・同期/非同期を付ける
- model上の名称をcode・API・data catalogと結ぶ
- 更新triggerと鮮度を定義
- 網羅性より意思決定に必要な深さを選ぶ
- 図にない手作業・外部provider・運用者もmodel化
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
ViewpointとTraceabilityの考え方を読んだところで、教材内の参照元で実際のarchitecture mapとtraceabilityの例を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まず視覚的なarchitecture mapの実装を見て、次に要件が回帰testまで追跡できるかを見ます。
教材の参照元を確認する — Source Trail ↓現在の視覚的architecture map。
src/components/docs/ArchitectureMap.tsx要件が実装まで追跡できるかを検証する回帰test。
scripts/regression/ - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜ良いarchitecture modelは『情報量の多さ』ではなく『特定の問いに答えられること』で評価されるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Viewpoint」という言葉を使って書いてみましょう。
ヒント2を見る
1つの要件が実装・testまでどう追跡できるか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Viewpoint、Traceability、ADRの3つを使って、良いarchitecture modelの条件を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- 関係者ごとに必要なViewpointが違うと説明できる
- 要件から実装・testまで追跡できることが品質だと説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q11枚の巨大な構成図で全員へ説明できますか？
難しいです。関係者と問いごとにViewpointを分け、共通要素を関連付けます。
Q2図を作ればArchitecture判断は完了ですか？
いいえ。選択肢、根拠、trade-off、決定者、影響と検証条件が必要です。
Q3古い図を信頼できるようにするには何が必要ですか？
所有者、最終確認日、情報源、現行か将来像かの表示、更新契機が必要です。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- The Open Group — ArchiMate and TOGAF
Business・Application・Data・Technologyを横断して可視化する考え方
- The Open Group — TOGAF Standard, 10th Edition
Enterprise Architectureの方法、領域、governance、migration planningの基礎
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
src/components/docs/ArchitectureMap.tsx現在の視覚的architecture map - 関連教材 — RELATED LESSON/docs/architecture関連教材の入口。関連コードを持つ教材model
- 未確認 — UNKNOWN
services/payment-service/README.md仕様資料。現行実装との一致は未確認。Java側layer構造の説明