Enterprise Architecture：銀行全体を1枚の意思決定体系として見る
Enterprise Architectureは巨大な構成図ではありません。経営目的からBusiness・Data・Application・Technologyをつなぎ、現在地、目標、移行順序、投資判断を一貫させる仕組みです。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Enterprise Architectureが解く問題
- 5つのarchitecture領域の関係
- Baseline・Target・Transitionを使った変革設計
体験46 · EA FOUNDATIONS（全体を1枚の意思決定体系に）
銀行のシステム全体を1枚の構成図に描ければ、それで十分か確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際の並行経路を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
銀行のシステム全体を1枚の構成図に描ければ、Enterprise Architectureとして十分だと思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
図は現在の状態と将来の状態のどちらを表すべきでしょうか？
ヒント2を見る
Business・Data・Application・Technologyは、それぞれ独立に最適化してよいでしょうか？
もっと詳しく：この問いで使う専門用語
- Architecture Domainは、全体をBusiness・Data・Application・Technologyなどの観点に分けた領域です。
- Baseline / Targetは、現在の姿と到達したい将来の姿です。
- Transition Architectureは、最終形へ一度に移れないときの中間状態です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Enterprise Architectureは、経営目的をBusiness・Data・Application・Technologyの設計へつなぎ、部分最適を防ぐための経営能力です。
現在地、目標像、移行段階を分けて表し、価値・risk・cost・実行可能性を同じ意思決定の場で扱います。
完成した大図面を作ることが目的ではなく、重要な変更を一貫した原則と根拠で選べる状態を作ることが目的です。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Architecture Domain
全体をBusiness・Data・Application・Technologyなどの観点に分けた領域です。
異なる専門家の検討を分担しつつ、相互依存を見失わないためです。
振込能力、Ledger data、Next.jsとPayment Service、実行基盤を横断して扱います。
Baseline / Target
現在の姿と、到達したい将来の姿です。
理想論ではなく、差分と移行仕事を明確にするためです。
legacy振込経路をBaseline、検証済みJava経路をTarget候補として比較できます。
Transition Architecture
最終形へ一度に移れないときの中間状態です。
大規模変更中も業務を安全に継続するためです。
legacy経路を維持しつつJava経路を段階検証する状態が該当します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
部分最適を全体の失敗にしない
商品部門が速さだけ、開発部門が技術だけ、data部門が統合だけ、運用部門が安定だけを最適化すると、同じ顧客を別々に管理し、重複systemと手作業が増えます。
Enterprise Architectureは、stakeholderの関心、守る原則、能力、情報、system、platform、投資を共通の判断軸へ置きます。すべてを中央集権化するのではなく、全社共通とdomain自治の境界を決めます。
| 領域 | 中心となる問い | Minibankで見るもの |
|---|---|---|
| Enterprise | 何のために、どこを変え、どう移行するか | 学習銀行の目的と全体roadmap |
| Business | 誰へどんな価値をどの能力で届けるか | KYC・口座・振込・会計・運用 |
| Data | どの事実を誰が所有し、どう意味を保つか | customer、account、transfer、journal |
| Application | どのapplicationがどのserviceを担うか | Next.js、Payment Service、PostgREST |
| Technology | どの実行・通信・security基盤で支えるか | Vercel相当、JVM、Supabase、PostgreSQL |
5領域は別々の図ではなく因果関係
- 01経営目標：安全な振込学習を提供する
- 02Business capability：本人確認・口座・振込・記帳・監視
- 03Information：本人・口座・依頼・取引・仕訳・監査
- 04Application service：受付、認可、実行、照会、管理
- 05Technology service：compute、identity、database、network、observability
Baseline・Target・Transition
Targetだけ描くと移行不能な理想図になります。既存取引を止めず、dataを二重管理する期間やrollbackまで含むTransition Architectureが重要です。
| 状態 | 目的 | 成果物 |
|---|---|---|
| Baseline | 現在の事実と痛点を理解 | system inventory、依存、cost、risk、data flow |
| Target | 到達したい能力と原則を定義 | capability map、target landscape、NFR |
| Gap | 不足・重複・廃止候補を特定 | gap matrix、risk、dependency |
| Transition | 安全に価値を出す中間状態 | work package、roadmap、exit criteria |
| Outcome | 投資がbusiness結果を出したか確認 | KPI、SLI、cost、risk reduction |
Minibank Architecture Curriculumの読み方
この15章は既存Architecture、Domain Modeling、Transaction、Security、Reliability教材を置き換えません。既存教材を全社設計の視点で再読する上位mapです。
- Enterprise Architectureで目的・原則・roadmapを決める
- Business Architectureで能力・価値・rule・例外を定義
- Data Architectureで正式記録・意味・品質・lifecycleを設計
- Application Architectureで責任境界・連携・進化を設計
- Technology Architectureでruntime・security・capacity・復旧を設計
- 各領域をtraceabilityでつなぎ、testと運用証拠へ落とす
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Baseline/Target/Transitionの考え方を読んだところで、教材内の参照元で実際の並行経路を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まず既存のAPI境界を見て、次に追加されたJava経路を見ます。BaselineとTargetがどう並行しているかを確かめましょう。
教材の参照元を確認する — Source Trail ↓既存(legacy)のNext.js API境界。
src/app/api/v1/追加されたJava経路。並行するTransition状態を探します。
services/payment-service/ - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜEnterprise ArchitectureはBusiness・Data・Application・Technologyを別々に最適化するのではなく、一体で扱う必要があるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Baseline」と「Target」という2つの言葉を使って書いてみましょう。
ヒント2を見る
既存教材とこの章がどう役割分担しているか考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Architecture Domain、Baseline / Target、Transition Architectureの3つを使って、部分最適を防ぐ考え方を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- 個別最適が全体の失敗につながると説明できる
- BaselineとTargetの間にTransitionが必要だと説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1Enterprise ArchitectureはIT標準だけを決める活動ですか？
いいえ。経営目的、業務能力、data、application、technologyと移行を一体で扱います。
Q2Targetだけ描けば移行できますか？
できません。Baselineとの差、依存関係、Transition、投資順序、risk低減策が必要です。
Q3Minibankで最初に追跡すべき関係は何ですか？
顧客価値と規制要件から、業務rule、data、service、基盤、運用証拠までの関係です。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- The Open Group — TOGAF Standard, 10th Edition
Enterprise Architectureの方法、領域、governance、migration planningの基礎
- The Open Group — ArchiMate and TOGAF
Business・Application・Data・Technologyを横断して可視化する考え方
- 金融庁 — 金融機関の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/architecture関連教材の入口。既存の銀行・会計・security教材
- 関連教材 — RELATED LESSON/docs/transaction-design関連教材の入口。設計・運用・信頼性の中上級教材
- 関連教材 — RELATED LESSON/docs/financial-it-stack関連教材の入口。金融IT stackと信頼性教材