Business Architecture：CapabilityとValue Streamで銀行を分解する
組織図やsystem名ではなく、銀行が継続的に持つ能力と、顧客へ価値が届く流れから変革範囲を設計します。
Business・Application・Data・Technologyを横断し、全体最適の設計へ広げる。
先に学ぶ内容 — Prerequisite: 金融IT・信頼性学ぶこと — LEARNING GOALS
このページで学ぶこと
- Capability・Process・Organizationの違い
- Value StreamとCustomer Journeyの関係
- Capability heatmapによる投資判断
体験49 · CAPABILITY / VALUE STREAM（何ができるかで見る）
Capabilityは、担当部署やアプリの名前が変わると一緒に変わるものか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際のAPI構成を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
Capability（組織としてできること）は、担当部署やアプリの名前が変われば一緒に変わるものだと思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
『振込を実行できる』という能力と、それを実現するAPIの実装は同じものでしょうか？
ヒント2を見る
部署名が変わったら、顧客に振込を届ける能力自体もなくなるでしょうか？
もっと詳しく：この問いで使う専門用語
- Business Capabilityは、組織が成果を出すために持つ安定的な能力です。
- Value Streamは、需要から価値実現までの主要な段階です。
- Capability Heatmapは、能力を戦略的重要度や成熟度、riskで色分けしたものです。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
Business Capabilityは組織が何をできなければならないか、Value Streamは顧客や関係者へ価値が届く段階を表します。
組織図や現在のsystem名から独立して能力を表すと、戦略投資と弱点を長期的に比較できます。
価値段階へ能力、情報、KPI、riskを重ねることで、顧客体験と内部統制を同時に改善できます。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Business Capability
組織が成果を出すために持つ安定的な能力です。
部署再編やsystem更改があっても投資対象を比較できるためです。
顧客認証、振込実行、不正防止、Ledger管理、照合が能力です。
Value Stream
需要から価値実現までの主要な段階です。
内部処理ではなく顧客成果を軸に改善点を見つけるためです。
振込依頼、本人確認、審査、記帳、通知、照合へ分けられます。
Capability Heatmap
能力を戦略的重要度や成熟度、riskで色分けしたものです。
限られた投資を重要な差へ集中するためです。
同時実行と障害再送の検証能力を改善対象として示せます。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
Capabilityは『何ができるか』
| 概念 | 答える問い | 振込の例 |
|---|---|---|
| Capability | 組織として何ができるか | Payment Initiation、Fraud Control、Posting |
| Process | どの順序で実行するか | 入力→認証→検査→記帳→通知 |
| Organization | 誰が責任を持つか | 決済部、事務、IT、risk |
| Application | 何が自動化を支えるか | Web、Payment Service、Ledger |
| Metric | 能力が機能しているか | 成功率、処理時間、差異、損失 |
Value Streamは価値の状態変化
Customer Journeyが利用者の体験を追うのに対し、Value Streamは価値が実現する段階を組織横断で捉えます。両方を重ねると、画面は速いが裏側の照合が手作業という欠落を見つけられます。
- 01Need：顧客がお金を送りたい
- 02Initiate：依頼と同意を受ける
- 03Validate：本人・口座・ruleを確認
- 04Commit：資金とLedgerを確定
- 05Inform：結果と証拠を届ける
- 06Assure：照合・監視・問い合わせで信用を維持
Capability mapを投資へ使う
重要かつ成熟度が低い能力を優先し、単に古いapplicationから順に刷新しません。
| 評価軸 | 問い |
|---|---|
| Strategic importance | 差別化・規制・顧客信頼にどれだけ重要か |
| Maturity | 人・process・data・application・controlが再現可能か |
| Performance | 品質・cost・速度・riskは目標内か |
| Change demand | 商品・制度・量・脅威の変化は大きいか |
| Dependency | 他能力のbottleneckやsingle pointか |
Minibank Capability Map
未実装の外部決済、AML、limit management、case management、24時間operationsは能力gapとして明示します。BIANは銀行能力を考える参照mapですが、そのまま組織やmicroserviceへコピーしません。
- Customer Management：profile、KYC、認証
- Account Management：口座、状態、残高表示
- Payment Management：受付、OTP、実行、冪等性
- Accounting：Ledger、trial balance、reversal
- Risk / Security：RLS、権限、threat control
- Operations：audit、integrity、reconciliation
- Learning Delivery：実装と教材のtraceability
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Business CapabilityとValue Streamの考え方を読んだところで、教材内の参照元で実際のAPI構成を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まず顧客向けAPIがCapabilityをどう実現するかを見て、次に管理画面がOperations能力をどう実現するかを見ます。
教材の参照元を確認する — Source Trail ↓Payment Management能力を実現する複数のAPI。
src/app/api/v1/Operations能力を実現する管理画面群。
src/app/admin/ - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜCapabilityは安定していて、Process（実現方法）の方が変わりやすいと言えるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Capability」と「Process」という2つの言葉を使って書いてみましょう。
ヒント2を見る
能力は安定していて、実現方法は変わりやすいという関係を考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Business Capability、Value Stream、Capability Heatmapの3つを使って、組織を能力で捉える利点を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- Capabilityと実現手段(組織・application)は別だと説明できる
- Value Streamが複数のCapabilityをまたぐと説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1Capabilityは部署やapplicationと同じですか？
違います。Capabilityは何ができるかで、組織やapplicationはそれを実現する手段です。
Q2Value Streamで統制をどこへ置きますか？
価値段階ごとに判断、証拠、risk、責任者を対応付けます。
Q3Heatmapの色は主観で決めてよいですか？
評価基準、証拠、評価者、時点を明示し、比較可能にする必要があります。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- BIAN — Service Landscape
銀行業務capabilityをService Domainとして整理する業界参照構造
- The Open Group — ArchiMate and TOGAF
Business・Application・Data・Technologyを横断して可視化する考え方
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 関連教材 — RELATED LESSON/docs/finance-business関連教材の入口。銀行商品・業務の既存教材
- 現在の実装 — CURRENT IMPLEMENTATION
src/app/api/v1/能力を支える現在のAPI - 現在の実装 — CURRENT IMPLEMENTATION
src/app/admin/管理・会計・運用capability