記帳は完了したが残高が更新されず、日次の勘定が合わない
記帳処理は正常終了したのに残高テーブルが更新されず、窓口の残高照会と日計表の合計が一致しない状態が発生します。
GENZ, Inc.
金融の勘定処理を知る
勘定系システムの
金融の勘定処理を知る
勘定系システムのテストを第三者の視点で引き受けます
更改の稟議とは別に、テスト外注費の稟議を通す必要があります。何を検証し、何を検証していないかを根拠とともに説明できる材料づくりから、GENZが入ります。
支援事例
支援実績5,000件以上
勘定系システムでよくある不具合
勘定系システムの不具合は、記帳や計算の結果が帳票や画面で確かめられる形で現れます。入出金・振込・利息計算の処理で起きる代表的な失敗を、検証で発見すべき状態として整理しました。
記帳は
受付応答を確認せずに再送し、同一の振込が二重に処理される
受付応答がタイムアウトした振込を結果の確認なく再送すると、同一の振込依頼が二重に計上され、預金者の口座から重複して引き落とされます。
利息計算の計算順序が仕様と異なり、全口座に一律の誤差が生じる
利息計算で端数処理と日数計上の順序が仕様と異なると、全口座に一律の誤差が生じ、修正には全件の再計算が必要になります。
締め時刻をまたぐ受付が翌営業日扱いになり、当日入金が反映されない
締め時刻をまたいだ受付が翌営業日扱いになると、当日扱いを期待した入金が当日の残高に反映されず、預金者の資金繰りに支障が生じます。
基盤更改後に金額の丸めが変わり、移行前後で残高が一致しない
基盤更改で金額の丸め方式が変わると、移行前後で残高が一致せず、差異の原因特定に新旧両系統の突き合わせ作業が必要になります。
残存した不具合により生じる問題
残存した不具合は画面の誤表示だけに留まりません。日次の勘定の締め、決算の確定、監査への証跡提示という、業務の継続そのものへ波及します。
静的テスト（レビュー）でおさえるべき観点
勘定系システムのレビューでは、プログラムを動かす前の設計書や仕様書の段階で、業務仕様との不一致を検出します。入出金・決済・残高管理・利息計算を対象に、照合先の文書を定めたうえで観点を絞り込みます。
照合を省くと、科目定義の抜けが本番の仕訳の誤計上として残り、月次の決算処理で差異が計上されてから修正と再計算が発生します。
勘定科目の定義と仕訳一覧を、業務部門の商品仕様と照合する
預金・融資・為替の商品仕様書に定められた勘定科目と仕訳の対応が、設計書の仕訳一覧へ漏れなく反映されているかを照合します。科目の新設を伴う改修では、照合の抜けが仕訳の誤計上として残ります。
確認する資料
- 商品仕様書
- 勘定科目表
- 仕訳一覧
計算順序の解釈違いは、利息計算の結果の差異として特定の条件の口座にだけ現れ、リリース直後の安定化の時期に判明して原因の切り分けに時間がかかります。
利息計算の計算順序と端数の扱いを、金利体系の規定と照合する
利息計算は、金利の適用順序・端数処理・起算日の扱いが規定と一致しているかを、計算順序の記述まで照合します。「規定どおり」とだけ書かれた箇所は、具体の計算手順へ置き換える対象になります。
確認する資料
- 金利規定
- 利息計算仕様書
- 端数処理定義
整合条件の定義不足は、残高と取引明細の不整合として日次処理のたびに検出され、調査のたびに運用担当の工数が割かれる状態が続きます。
DB設計書のテーブル定義を、残高と取引明細の整合条件と照合する
残高テーブルと取引明細テーブルの定義が、日次処理の締め後に両者が一致する条件を満たすかを照合します。更新タイミングの定義が曖昧だと、照合処理で差異が計上され、残高の不整合として表面化します。
確認する資料
- DB設計書
- 残高管理仕様書
- 日次処理定義
電文項目の不一致は、振込の未了や組戻しとして窓口・コールセンターへの問い合わせへ波及し、責任分界が未定義のままだと原因調査が自行と中継側の間で停滞します。
振込電文の項目定義を、決済ネットワークの電文仕様と照合する
外部の決済ネットワークへ送る振込電文の項目定義が、接続先の電文仕様と桁数・コード体系で一致するかを照合します。接続部分は自行側と中継側で検証範囲が分かれるため、責任分界の取り決めも確認します。
確認する資料
- 電文仕様書
- 接続設計書
- 責任分界取決め
必須項目の欠落は、取引の受付後に処理が失敗する状態として預金者側へ影響が及び、チャネル系と勘定系のどちらの改修かをめぐる調整が発生します。
チャネル系との境界のAPI定義を、取引受付の必須項目と照合する
ATM・インターネットバンキングなどのチャネル系との境界のAPI定義が、取引受付の必須項目を持つかを照合します。必須項目の欠落は受付時に検知されず、勘定系側で処理が失敗して表面化します。
確認する資料
- API定義
- 取引受付仕様書
- 必須項目一覧
- チャネル連携設計書
動的テストの設計・実行のポイント
動的テストは、ユニットテストから受け入れテストまでの各工程で対象と観点を組み立て、実行結果を判断材料として残します。
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の支援
並行稼働の期間と要員から逆算すると、検証できない項目が残ります。GENZはテスト設計の起点から入り、何を検証し何を検証していないかを根拠とともに宣言できる状態へ整理します。
設計書のレビューからテスト設計を起こします
要件・設計書のレビュー段階から関与し、テスト設計を自ら起こします。勘定処理や利息計算の構造を踏まえ、検証範囲と優先順位を組み立てます。
支援実績から検証範囲を提案
金融など多業種の第三者検証経験をもとに、大規模システムでどこまでの範囲を取るべきかを提案し、絞り込みを根拠づけます。
どちらの体制にも加わります
発注側主導・ベンダー主導のどちらの体制にも、既存のQA配置を組み替えずに加わります。足りない検証機能だけを外から補う形で支援します。
判断と監査に使える報告書を納品
テスト計画・テスト項目書・不具合票・リリース判断の記録を揃った形で納品します。システム監査への証跡提示と承認資料にご利用いただけます。
ご相談から納品までの流れ
勘定系システムの検証は、請負範囲の線引きと証跡の形式が論点になります。工程ごとの進め方を示します。
ヒアリング
更改の時期やベンダーとの請負範囲、検証に残せる期間と工数の前提を伺います。
テスト設計と見積もり
検証範囲とテスト項目を設計し、工数と期間を示した見積もりを提出します。
テストの実施と進捗の共有
テストを実施し、不具合票と進捗を共有します。開発工程と並行して進めます。
報告書の納品と再確認
検証範囲と残存リスクを記した報告書を納品し、監査の証跡として再確認します。
ご相談から検証範囲の整理まで
勘定系システムの検証範囲と優先順位をGENZへご相談ください
初回のご相談では、勘定系システムの検証範囲と優先順位の整理、必要工数の考え方をご提示します。開発体制を組み替えずに加わる形を前提に、見積もりの前提条件まで揃えてお渡しします。