Architecture Governance：原則を投資・標準・ロードマップへ変える
Architectureは描いて終わりではありません。原則、意思決定権、例外、標準、投資portfolio、移行roadmapを通じて、日々の変更を目標状態へ収束させます。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Architecture Principleの作り方
- Review・例外・技術標準の統制
- 価値とriskを両立する移行roadmap
体験47 · EA GOVERNANCE（原則を投資へ変える）
Architecture原則は、例外なく全員が常に守るべき絶対ルールか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際の切替設定とmigration履歴を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
Architecture原則は、一度決めたら例外なく全員が常に守るべき絶対ruleだと思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
例外を『隠す』ことと『記録して管理する』ことは同じでしょうか？
ヒント2を見る
原則から外れる判断には、何が必要でしょうか？
もっと詳しく：この問いで使う専門用語
- Architecture Principleは、複数案件で繰り返し使う判断の基準です。
- Decision Rightは、誰が提案し、誰が承認し、誰がriskを引き受けるかという権限です。
- Exception Registerは、標準から外れる判断と解消計画の記録です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Architecture Governanceは、原則、意思決定権、review、例外、有効期限、証拠を定め、設計判断を再現可能にします。
Roadmapは案件一覧ではなく、能力・依存関係・risk低減・移行価値を時間軸へ配置したものです。
例外を禁止するのではなく、理由・補償統制・期限・解消責任者を管理し、永続的な抜け道にしないことが重要です。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Architecture Principle
複数案件で繰り返し使う判断の基準です。
担当者ごとの好みではなく、経営方針に沿って選ぶためです。
正式残高はLedgerから説明できること、外部入力を信頼しないことなどです。
Decision Right
誰が提案し、誰が承認し、誰がriskを引き受けるかという権限です。
合議の曖昧さと無責任な決定を防ぐためです。
業務上限、security例外、DB変更で承認者を分けます。
Exception Register
標準から外れる判断と解消計画の記録です。
一時的例外が見えない恒久仕様になるのを防ぐためです。
legacy経路の継続条件と撤去判定を記録できます。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
原則は標語ではなく判断規則
| 原則 | 理由 | 設計への影響 |
|---|---|---|
| Ledger is authoritative | 金額根拠を再現する | 残高cacheを直接正としない |
| Caller context is preserved | 権限昇格を防ぐ | 利用者tokenを最終判断地点まで伝搬 |
| Financial writes are idempotent | 通信再送を安全にする | request identityとfingerprintを永続化 |
| Private by default | 公開面を最小化 | private schema・最小権限・明示的API |
| Evolution is reversible | 変更riskを抑える | feature flag、互換期間、rollback条件 |
誰が何を決めるか
reviewは承認印の会議ではありません。重大な不可逆判断を早く発見し、代替案・trade-off・証拠を残す場です。
| 場 | 決めること | 決めないこと |
|---|---|---|
| Executive / Portfolio | business優先度、risk appetite、投資 | 個別class設計 |
| Architecture Board | cross-domain原則、標準、例外、target整合 | teamの日次実装 |
| Domain Architecture | domain model、service/data ownership | 他domainの内部詳細 |
| Delivery Team | 原則内のsolution、test、運用 | 全社標準の無断変更 |
| Risk / Security / Operations | control、耐性度、受入証拠 | 価値判断の単独決定 |
例外を隠さず管理する
- 01標準から外れる理由とbusiness価値を記録
- 02security・運用・cost・移行riskを評価
- 03代替controlと適用範囲を定義
- 04期限・owner・解消条件を承認
- 05inventoryで追跡し期限時に再評価
- 永久例外を暫定対応と呼ばない
- 製品名でなく必要capabilityを基準にする
- architecture debtを利息・事故影響・変更頻度で優先付け
- 例外の集中から標準自体の不適合も学ぶ
Roadmapはproject一覧ではない
MinibankのJava Payment Serviceも、既存経路削除ではなく追加、比較、検証、段階切替、旧経路廃止判定というroadmapで扱います。
| Wave | 価値 | Architecture exit criteria |
|---|---|---|
| 0 可視化 | 現状riskを把握 | inventory・owner・data flowが揃う |
| 1 Guardrail | 新規負債を止める | 標準API、identity、observabilityを利用可能 |
| 2 Strangler | 新能力を段階移行 | traffic切替と旧経路rollbackを検証 |
| 3 Data transition | 正式記録を統合 | dual-writeせず照合済み移行 |
| 4 Retirement | costとriskを削減 | 利用ゼロ、data保持、契約終了、復旧不要を承認 |
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Architecture PrincipleとException Registerの考え方を読んだところで、教材内の参照元で実際の切替設定とmigration履歴を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まず経路切替の設定を見て、次にmigrationの積み上げ履歴を見ます。原則がどう実装へ反映されるかを確かめましょう。
教材の参照元を確認する — Source Trail ↓legacy/javaを検証する設定境界。
src/lib/config/paymentBackend.ts変更判断を順序付きで残すDB履歴。
supabase/migrations/ - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜArchitecture原則には、例外を『隠す』のではなく『記録して期限管理する』仕組みが必要なのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Exception Register」という言葉を使って書いてみましょう。
ヒント2を見る
例外を放置すると何が起きるか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Architecture Principle、Decision Right、Exception Registerの3つを使って、原則を投資判断へつなげる方法を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- 例外は隠さず記録し期限管理すると説明できる
- 原則が実装の具体的な判断へ反映されていると説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1Architecture Reviewは設計者を取り締まる会議ですか？
いいえ。重大riskと横断依存を早く発見し、意思決定を支援する仕組みです。
Q2Roadmapを機能の納期順に並べるだけでよいですか？
不十分です。前提能力、data移行、運用準備、risk低減、切戻しも配置します。
Q3例外承認に最低限必要なものは何ですか？
理由、影響、補償統制、責任者、有効期限、解消または再審査条件です。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- The Open Group — TOGAF Standard, 10th Edition
Enterprise Architectureの方法、領域、governance、migration planningの基礎
- 金融庁 — 金融機関のITガバナンスに関する論点・プラクティス
経営戦略、IT戦略、DX戦略、次世代architecture、投資・risk・人材の統合
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 関連教材 — RELATED LESSON/docs/java-minibank-architecture関連教材の入口。Java追加architectureと既存経路の関係
- 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/変更判断を順序付きで残すDB履歴