Application Landscape：銀行のApplication Portfolioを支配する
application一覧は資産台帳ではありません。各applicationのbusiness責任、data、連携、criticality、cost、risk、lifecycleを可視化し、投資・統合・廃止を判断します。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Application・Component・Serviceの区別
- LandscapeとPortfolio評価
- 重複・依存・廃止不能を見つける方法
体験52 · APPLICATION LANDSCAPE（台帳で支配する）
applicationの数が少ないほど良いarchitectureか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際のapplication構成を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
applicationの数が少ないほど、良いarchitectureだと思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
少ないapplicationは、常に低いriskを意味するでしょうか？
ヒント2を見る
Next.jsとJava Payment Serviceは、なぜ両方存在するのでしょうか？
もっと詳しく：この問いで使う専門用語
- Application Catalogは、applicationの責任と特性を構造化した台帳です。
- Business Fitは、現在と将来の業務能力をどれだけ支えるかです。
- Dispositionは、維持、投資、移行、統合、廃止などの処置方針です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Application Landscapeはapplication名の一覧ではなく、提供能力、所有者、利用者、data、連携、費用、risk、寿命を管理します。
Portfolio判断ではBusiness Fit、Technical Health、Operational Risk、Economic Valueを分けて評価します。
重複applicationを即座に統合せず、移行risk、規制証拠、業務継続、退出可能性を含めて処置を決めます。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Application Catalog
applicationの責任と特性を構造化した台帳です。
未知の依存や所有者不明を減らすためです。
Next.js、Payment Service、Supabase Auth、PostgreSQLを登録します。
Business Fit
現在と将来の業務能力をどれだけ支えるかです。
技術が新しいだけでは投資価値を判断できないためです。
Payment Serviceが必要な振込ruleと運用を満たすか評価します。
Disposition
維持、投資、移行、統合、廃止などの処置方針です。
評価を具体的なportfolio行動へ変えるためです。
legacy経路は検証完了まで維持し、その後の判断条件を定めます。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
何をapplicationとして管理するか
microserviceの数をapplication数と機械的に一致させません。owner、release、data、運用、廃止を独立管理する単位で定義します。
| 概念 | 意味 | Minibank |
|---|---|---|
| Application | 独立してlifecycle・ownerを持つsolution | Next.js app、Payment Service |
| Component | application内の配布・責任単位 | Docs、Admin、Customer、RPC client |
| Application Service | businessへ提供する機能 | Payment Initiation、Account Inquiry |
| Interface | 外部へ見せる契約 | HTTP API、PostgREST RPC |
| Technology Platform | applicationを実行する基盤 | Node runtime、JVM、PostgreSQL |
最低限のApplication Catalog
- business owner・technical owner・support team
- 提供serviceと利用者
- 所有dataと参照data
- inbound / outbound interface
- criticality・SLO・RTO/RPO
- runtime・deployment・region・provider
- cost・license・support期限
- security classification・internet exposure
- lifecycle：invest、tolerate、migrate、eliminate
Portfolioを4軸で評価
fitが高くhealthが低いapplicationはmodernize、fitが低くcostが高いものはretire候補です。ただしdata保持、法的証拠、下流依存を解消してから廃止します。
| 軸 | 高い場合の問い |
|---|---|
| Business fit | 戦略capabilityへ貢献するか |
| Technical health | support、security、保守性、testは十分か |
| Operational risk | 停止影響、復旧、single point、属人性はどうか |
| Economic value | run/change costに見合う価値か |
Minibank Landscape
Next.jsとJavaのPayment入口が並行する現在は、正規経路、traffic選択、契約互換、監視、rollbackを明示する必要があります。
| Application | 責任 | 主な依存 |
|---|---|---|
| Next.js | UI、BFF、既存API、Docs | Supabase Auth / PostgREST |
| Payment Service | Java Payment API、型付き境界 | PostgREST RPC |
| Supabase Auth | identity・token | 利用者credential |
| PostgREST | Data API / RPC bridge | PostgreSQL |
| PostgreSQL | 業務rule、Ledger、Audit、SoR | migration・backup・operations |
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Application CatalogとBusiness Fitの考え方を読んだところで、教材内の参照元で実際のapplication構成を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずNext.js側のapplication定義を見て、次に共通のData API設定を見ます。複数applicationがどう1つの正式記録へ集約するかを確かめましょう。
教材の参照元を確認する — Source Trail ↓Next.js applicationの依存関係。
package.jsonData APIとlocal platform設定。
supabase/config.toml - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜapplication portfolioの評価には、Technical HealthだけでなくBusiness Fitも必要なのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Business Fit」という言葉を使って書いてみましょう。
ヒント2を見る
application数を減らすこと自体が目的にならない理由を考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Application Catalog、Business Fit、Dispositionの3つを使って、application portfolioの評価方法を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- application数の少なさは良さの指標ではないと説明できる
- Business Fitが投資判断に必要だと説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1application数を減らせば必ず良いArchitectureですか？
違います。重要なのは能力、risk、cost、変更容易性、回復性の全体結果です。
Q2Technical Healthだけで廃止を決められますか？
決められません。Business Fit、data、規制、移行risk、代替能力を確認します。
Q3Minibankのapplication台帳に何を加えるべきですか？
owner、SLO、data、upstream/downstream、認証、release、復旧、費用、lifecycleです。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — 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/app/Next.js applicationのroute landscape - 現在の実装 — CURRENT IMPLEMENTATION
services/payment-service/Java application - 現在の実装 — CURRENT IMPLEMENTATION
supabase/config.tomlData APIとlocal platform設定