スコアリングの計算順序が仕様と異なり、閾値付近の申込で判定が逆になる
スコアリングの計算順序が仕様と異なると、閾値に近い申込で可決と謝絶が入れ替わります。計算順序そのものを検証項目に含めなければ検出できません。
GENZ, Inc.
金融機関のご担当者様へ
融資審査システムを
金融機関のご担当者様へ
融資審査システムを第三者の視点で検証します
融資審査システムの更改では、審査ロジックの変更に伴う誤りがリリース後に判明します。GENZは業務構造からテスト設計を起こし、第三者の視点で検証します。
支援事例
支援実績5,000件以上
融資審査システムでよくある不具合
融資審査システムでは、審査ロジックの誤りが画面表示ではなく与信判定そのものに現れます。ここでは、受け入れテストで見逃されやすい不具合の型を順に挙げ、どの工程で検出できる状態かを整理します。
スコアリングの
信用情報の照会が未応答のまま可決される
信用情報の照会が未応答のまま処理が進み、照会結果を参照せず可決されます。応答異常を再現して検証しない限り、正常系のテストでは表面化しません。
書類の数値が桁や単位を誤って取り込まれ、審査の入力値が変わる
申込書や源泉徴収票をOCRで取り込む場合、桁や単位を誤った値が審査の入力値になります。原本との照合を検証しないと、誤った年収で判定されます。
差し戻し後に状態が戻らず、営業店と本部で決裁が止まる
差し戻し後に案件の状態が営業店側と本部側で不整合となり、決裁が止まります。状態遷移を検証範囲に含めないと、稼働後の問い合わせで判明します。
商品条件の改定が格付判定と自己査定の区分に反映されない
商品条件の改定が審査判定へ反映されても、格付判定と自己査定の区分へ反映されません。波及先を回帰テストに含めないと、決算の説明に影響します。
残存した不具合により生じる問題
残存した不具合は、リリース後に与信判定・自己査定・監査対応へ波及します。それぞれの問題がどのように生じ、どこまで業務を圧迫するかを整理します。
静的テスト（レビュー）でおさえるべき観点
設計書の段階で審査基準との差異を検出できれば、受け入れテストで問題が表面化する前に修正へ戻せます。レビューの観点を融資審査システム固有の構造に合わせて整理します。
審査基準の条件が設計書へ反映されないまま実装が進み、受け入れテストの段階で大規模な手戻りが発生するおそれがあります。
審査基準と設計書の判定条件を照合する
融資企画が提示する商品条件・スコアリング条件・例外運用と、設計書の判定条件の記述を項目ごとに照合します。口頭で補足された例外運用が設計書へ反映されていないまま工程が進むのを防ぎます。
確認する資料
- 審査基準書
- 商品条件一覧
- 基本設計書
計算順序や端数処理の差異が残ると、与信判定の結果が審査基準と一致せず、本来可決すべき申込の謝絶や与信方針から外れた可決が起きるおそれがあります。
計算順序と端数処理を設計書とDB項目定義で突き合わせる
属性・信用情報・担保評価・スコアリングから与信判定へ至る計算順序と、利息や端数処理の定義を、設計書とDB項目定義で突き合わせます。判定条件が正しくても、順序が異なれば判定結果は一致しません。
確認する資料
- 基本設計書
- DB項目定義書
- 計算仕様書
信用情報照会の応答仕様が未定義のままだと、照会結果の欠損時に判定が誤った入力値で実行され、リリース後に表面化するおそれがあります。
信用情報照会のAPI仕様を設計書の記述と照合する
個人信用情報機関との照会・応答のAPI仕様を、設計書の記述と照合します。応答項目の桁数・欠損時の扱い・タイムアウト時の挙動が設計書に明記されていないと、テスト環境での期待値を置けません。
確認する資料
- API仕様書
- 基本設計書
- 外部接続定義
権限と状態遷移の不整合が残ると、決裁権のない者が案件を承認できる、または稟議の記録が欠落し、内部監査での是正指摘につながるおそれがあります。
審査決裁の権限と状態遷移を照合する
審査決裁の権限（支店長・本部の決裁ライン）と案件の状態遷移を照合します。保留案件の回付先や取消の条件が設計書と運用の取り決めで異なると、稟議の記録が残らない事態になります。
確認する資料
- 権限定義書
- 状態遷移表
- 決裁運用規程
異常系の取り決めが曖昧なまま稼働すると、障害時に仕様どおりの挙動と不具合の切り分けができず、原因調査に人員が取られるおそれがあります。
異常系の記述を運用の取り決めと照合する
外部接続の断・OCRの読み取り失敗・照会応答の欠損といった異常系を、運用の取り決めと照合します。異常時に営業店が手作業で対応する条件が設計書に書かれていないと、稼働後に切り分けができません。
確認する資料
- 基本設計書
- 運用設計書
- 例外処理定義
- 営業店運用手順
動的テストの設計・実行のポイント
動的テストは、ユニットテストから受け入れテストまでの各工程で、審査ロジックの正しさと業務シナリオの整合を段階的に検証します。
STEP 01
ユニットテスト境界値の前後で判定区分が変わることを確かめる
どう確かめるか
ユニットテストでスコアリングと判定条件の境界値を同値分割と境界値分析で確かめる
スコアリングの計算順序と与信判定の条件分岐を対象に、同値分割で代表値を選び、境界値分析で限度額やスコアの閾値の前後を確かめます。誤った区分へ振り分ける実装をこの段階で検出します。
- 01スコアリング条件を同値分割し、代表値で判定結果を検証します
- 02限度額と金利の境界値で条件分岐の正しさを確かめます
- 03審査ロジックの計算順序が設計書どおりかを確認します
OUTPUTテスト設計書
STEP 02
統合テスト外部接続の応答は擬似応答で用意する
どう確かめるか
統合テストでモジュール間の連携を擬似応答と異常系で確かめる
個人信用情報照会などの外部接続は擬似応答を用意し、応答遅延やタイムアウトを発生させて検証します。書類データ化との接続点では、読み取り結果の不整合が審査の入力値へ渡る経路を確かめます。
- 01個人信用情報照会の擬似応答で正常系の連携を確かめます
- 02応答遅延とタイムアウトを意図的に発生させて検証します
- 03書類データ化の結果が審査入力値へ渡る経路を確認します
OUTPUTテスト項目書
STEP 03
システムテスト営業店連携を含む業務シナリオで通す
どう確かめるか
システムテストで申込受付から結果回答・決裁までの業務シナリオを通して確かめる
申込受付から自動審査、担保評価、決裁、結果回答までを業務シナリオとして通し、商品条件ごとの判定と帳票を検証します。営業店連携を含む操作順序で、工程間のデータの引き継ぎを確かめます。
- 01申込受付から結果回答までの業務シナリオを通します
- 02商品条件ごとの判定結果と帳票の出力を検証します
- 03決裁への回付と稟議の記録の連携を確かめます
OUTPUT不具合票
STEP 04
受け入れテスト検証範囲の根拠をリリース判断へ示す
どう確かめるか
受け入れテストで商品条件ごとの判定結果と帳票を、業務側の基準で確かめる
融資企画部門が提示する商品条件と審査基準に沿って、判定結果の妥当性を業務側で確かめます。全件を人手で確認できない仕様では、代表条件の選定根拠を示せる検証範囲が判断材料になります。
- 01商品条件ごとの代表ケースで判定結果を確かめます
- 02審査基準と判定結果の照合を業務側と行います
- 03検証範囲の根拠をリリース判断の資料へ反映します
OUTPUT結果報告書
GENZが代行する融資審査システムのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 受け入れテストの設計と項目書作成をまるごと代行します
- 融資審査の業務構造を踏まえて検証範囲を設計します
- 査閲・監査の説明に使える報告書と証跡を納品します
- 回帰テストの範囲を根拠とともに提示します
融資審査の業務構造からテスト設計を起こす支援
受け入れテストは、個人信用情報照会・担保評価・スコアリング・与信判定の計算順序を踏まえて設計しないと、審査業務の不整合を見落とします。GENZはベンダーとは別の立場で、業務構造から検証範囲を組み立てます。
審査ロジックからテスト設計を組み立てる
審査の計算順序と判定条件を整理し、代表条件と境界値を根拠づけて選んだテスト項目書を作成します。
申込から格付の受け渡しまでを検証
申込受付から自動審査、決裁、格付判定への受け渡しまで、業務の流れに沿って検証します。
既存の工程を変えずに並行して検証
ご担当者様の工程や様式を作り替えず、開発の進行と並行して検証の手を足します。
判断と監査に使える成果物で納品
テストの実施記録・不具合票・収束の記録を、リリース判断と監査対応の双方に使える形で納品します。
ご相談から納品までの流れ
受け入れテストの外注は、相談から納品まで順に進みます。各工程で何を決め、何をお渡しするかを示します。
ヒアリング
システムの構成と商品条件、リリース期日を伺い、検証範囲を整理します。
テスト設計と見積もり
整理した範囲をもとにテスト設計を進め、項目数と工数、費用を提示します。
テストの実施と結果の共有
テストを実施し、不具合票の起票と収束状況を共有しながら確認を繰り返します。
報告書の納品と再確認
結果を報告書にまとめて納品し、査閲や監査での説明に使える粒度かを確認します。
無料相談・見積もりのご案内
融資審査システムのテストをどこまで行なうか、範囲と優先順位からご相談ください
製品選びの次に残るのは、自行側の受け入れテストの設計です。審査ロジックの計算順序に沿って、検証範囲の決め方と項目の優先順位を一緒に整理し、社内説明に使える形でお渡しします。