品質保証：『テストが通った』を信頼の証拠へ変える
金融システムの品質は、障害がないことを願う活動ではありません。要求品質を定義し、設計・実装・移行・運用の各段階で予防と検知の証拠を積み上げる活動です。
金融ITの技術選択、品質保証、安定稼働、業界の変化を設計判断へつなげる。
先に学ぶ内容 — Prerequisite: 銀行システム / ソフトウェア工学学ぶこと — LEARNING GOALS
このページで学ぶこと
- 品質を機能・非機能・データ・運用で捉える方法
- test pyramidと金融固有の検証
- release可否を証拠で判断する品質gate
体験41 · FINANCIAL QUALITY（証拠としての品質）
テストの本数が多いほど、そのシステムの品質は高いと言えるか確かめよう
まずは予想をひと言。本文を読んだ後、教材内の参照元で実際のtest層を確認します。
- 01まず予想する — PREDICT
まずここだけ：思ったことをひと言書く
テストの本数が多ければ多いほど、そのシステムの品質は高いと言えると思いますか？
正解でなくて大丈夫です。「〜だと思う」から始めてみましょう。
ヒント1を見る
同じ種類のtestを100個増やすことと、違う層のtestを1個増やすことは同じ価値でしょうか？
ヒント2を見る
test件数と、検証されたriskの種類は同じものでしょうか？
もっと詳しく：この問いで使う専門用語
- Quality Gateは、次の工程やreleaseへ進んでよいか判断する条件です。
- Failure Injectionは、意図的にtimeoutや障害を起こして挙動を試すtestです。
- Reconciliationは、別の記録どうしを突き合わせる検査です。
日常語で理解する — PLAIN LANGUAGE
まず、ここだけつかむ
金融systemの品質は、完成後にbugを探すだけではなく、最初に必要な品質水準を決めて各工程へ作り込む活動です。
unit、API、DB、競合、障害注入、性能、security、E2E、照合は、それぞれ異なる失敗を確かめます。
test件数ではなく、重要riskと期待結果をどの証拠で確認したかを基にreleaseを判断します。
順番に理解する — DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Quality Gate
次の工程やreleaseへ進んでよいか判断する条件です。
重要な未確認riskを見える形で止めるためです。
型検査、回帰test、build、照合手順などを組み合わせます。
Failure Injection
意図的にtimeoutや障害を起こして挙動を試します。
成功経路だけではrollback・retry・復旧を証明できないためです。
RPC途中失敗や応答消失後の再送を検査対象にします。
Reconciliation
別の記録どうしを突き合わせます。
予防を抜けた欠落・重複・不均衡を本番でも検知するためです。
transfer、journal、cached balanceを検査します。
発展 — ADVANCEDもっと詳しく確認する最初の学習では読まなくても問題ありません。仕組みをもっと深く理解したい場合に開いてください。
品質は後工程の検査ではなく、最初に決める要求
『高品質』『安定している』は、そのままでは測れません。正確性、可用性、性能、security、回復性、監査可能性、保守性などを、対象業務に必要な水準へ具体化します。
すべてを最高水準にするのではなく、重要業務と顧客影響に応じて目標・測定方法・受入基準を決めます。
| 品質観点 | 振込で確かめる例 |
|---|---|
| Functional correctness | 正しい条件で正しい状態と金額になる |
| Data integrity | 借貸一致、重複なし、孤立記録なし |
| Security | 本人・対象・操作権限を各境界で確認 |
| Performance / Capacity | peakでも目標時間内、限界時は安全に抑制 |
| Reliability / Recovery | 途中失敗、再送、切替後も正しく収束 |
| Auditability | 誰がいつ何を判断・変更したか追跡可能 |
| Operability | alert、dashboard、runbookで担当者が対応可能 |
予防と検知を重ねる
| 段階 | 予防 | 検知・証拠 |
|---|---|---|
| Requirement | 不変条件・非機能・例外を定義 | review、acceptance criteria |
| Design | 責任・権限・transaction・failure modeを設計 | architecture review、threat model |
| Code | 型、validation、constraint、安全なdefault | static analysis、unit test、code review |
| Integration | 安定した契約、idempotency、timeout | contract、API、DB integration、concurrency test |
| Release | 小さな変更、feature flag、rollback | canary、smoke、migration verification |
| Production | 冗長化、rate limit、権限分離 | SLI、audit、reconciliation、incident review |
金融処理のtest portfolio
- Unit：Money、状態判定、error mappingなど小さな規則
- Property / invariant：任意の入力でも借貸一致、金額保存、許可遷移
- Contract：API・message・SQLSTATE・schema互換性
- DB integration：constraint、RLS、RPC、transaction、rollback
- Concurrency：同一口座・同一key・承認競合を別connectionで実行
- Failure injection：timeout、通信断、依存先停止、partial failure、retry
- Performance：通常・peak・burst・長時間・容量限界
- Security：認証・認可・入力・秘密・dependency・脆弱性
- E2E：BrowserからLedger・Audit・顧客表示まで
- Reconciliation：業務記録、台帳、残高cache、外部明細を照合
本番変更の品質gate
gateは書類を増やすためではなく、重大な未確認事項を可視化し、誰がriskを受け入れるか決めるためにあります。変更の危険度に応じて深さを変えます。
- 01要件・設計・risk・変更範囲がreview済み
- 02自動testとsecurity checkが合格
- 03data migrationと照合手順を検証
- 04性能・capacity・依存先制限値を確認
- 05監視・alert・runbook・on-callを準備
- 06段階releaseとrollback判断条件を承認
- 07release後に業務metricと整合性を確認
Minibankの品質証拠と限界
MinibankにはDB/RPC regression、API test、Playwright E2E、DB constraint、Audit、Reconciliationがあります。これらは異なる失敗を検知する防御線です。
一方、Java Payment Serviceのtest、広範なmulti-session競合、負荷・耐久、multi-region DR、実運用当番は教材確認時点で十分な証拠がありません。既存test件数を本番銀行相当の証明に使ってはいけません。
体験学習の続き · LEARNING LOOP
ここまで読めましたか？続けて確認してみましょう
Quality GateとReconciliationの考え方を読んだところで、教材内の参照元で実際のtest層を確認し、自分の言葉で説明してみます。
- 02仕組みを確かめる — CONCEPT CHECK
画面操作なしで、仕組みを確かめる
この仕組みは、Mini Bankの画面には現れません。次のEvidenceとCode Trail、教材本文だけで理解を進めます。
- 03証拠を確認する — EVIDENCE
何を見たか、1つずつ確かめる
Evidence（判断の根拠となる記録）を確認したらチェックします。各項目の「何を見るか」を手がかりにしてください。
画面を開けない項目は、Source Trail（教材の参照元）と教材の説明で確認できます。失敗を実際に起こす必要はありません。
- 04コードの処理経路を追う — CODE TRAIL
コードを書く必要はありません
ここでは「説明されている仕組みが、実際のMini Bankのどこに実装されているか」を確認します。まずは日本語の役割説明を読み、入力した依頼がどこへ渡るかをつかみましょう。コードの全文を読む必要はありません。
まずDB/RPCの回帰testを見て、次にBrowser E2Eの実装を見ます。異なる層が何を検証しているかを確かめましょう。
教材の参照元を確認する — Source Trail ↓DB/RPCとAPIの回帰検査。
scripts/regression/Browser E2Eの実装。
e2e/full-journey.spec.ts - 05自分の言葉で説明する — EXPLAIN
LEVEL 1 — やさしい説明（まずここだけ）
なぜテストの件数ではなく、『どのriskをどの層で検証したか』が品質の証拠になるのでしょうか？ 短い2文を目安に説明してください。
日常語だけで完了できます。専門用語の数や正誤を自動採点するものではありません。
ヒント1を見る
「Quality Gate」という言葉を使って書いてみましょう。
ヒント2を見る
E2Eテストだけで確認できないものを考えてみましょう。
もっと詳しく：LEVEL 2 — 専門用語を使った説明（任意）
Quality Gate、Failure Injection、Reconciliationの3つを使って、品質保証が複数層の証拠を重ねる理由を説明してみましょう。
挑戦する場合は、上の説明欄に追記できます。追加しなくても完了できます。
説明の確認ポイント — Checkpoint- test件数ではなく検証したriskの種類が重要だと説明できる
- Minibankの証拠に及ぶ範囲と限界を説明できる
理解を確かめる — CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1test件数が多ければ高品質ですか？
件数だけでは判断できません。重要risk、境界、失敗、期待結果を覆っている必要があります。
Q2E2Eだけですべて確認できますか？
できません。DB権限、constraint、競合などは専用の低い層のtestが必要です。
Q3release gateにはtest以外に何が必要ですか？
migration、capacity、security、監視、runbook、rollback、release後照合などです。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
業界・外部の参照元 — INDUSTRY / EXTERNAL SOURCE
業界資料・参考文献
一般論と業界知識の根拠です。外部サイトを新しいタブで開きます。
- IPA — 高信頼ソフトウェアとは
高信頼を品質特性と定量的尺度で捉える基礎資料
- IPA — ソフトウェアの高品質化のための予防と検知
障害再発防止へ向けた品質保証手法
- 金融庁 — 電子決済等取扱業者のシステム品質に関する着眼点
test方針、capacity、取引急増、外部連携を含む監督上の観点
教材の参照元 — SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
- 現在の実装 — CURRENT IMPLEMENTATION
scripts/regression/DB/RPCとAPIの回帰検査 - 現在の実装 — CURRENT IMPLEMENTATION
e2e/full-journey.spec.tsBrowser E2Eの実装 - 過去の実装 — HISTORICAL IMPLEMENTATION
supabase/migrations/constraint・transaction・audit・reconciliation - 現在の実装 — CURRENT IMPLEMENTATION
services/payment-service/今後Java test portfolioを追加する対象