GENZ, Inc.

開発側から独立した 反社チェックツールの判定を、開発側から独立した立場で検証する

ベンダー任せでは、稟議と監査で「誰が確かめたか」を説明できません。GENZは開発側から独立した立場で判定と連携を検証し、受け入れに使える成果物を残します。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

反社チェックツールで見落とされる不具合

反社チェックツールは、画面の動作確認では判定の正しさを確かめられません。表記ゆれや同姓同名の扱い、更新後の結果の差、取り込みの欠落は、受け入れで見落とされ、稼働後の判定ばらつきや監査指摘として表面化します。

表記ゆれと同姓同名で検索の対象を取り違える

「株式会社」の有無や旧字体の違いで別対象となり、一致すべき取引先が検索に出ません。同姓同名の個人を取り違え、無関係の候補者へ確認を求めます。

名寄せの精度

データベースの更新後に同じ対象名の結果が変わる

データベースの更新を境に、同じ対象名の検索結果が変わります。前回は非該当だった取引先が該当へ変わっても、どちらを正とするかの根拠がありません。

結果の再現性

基幹システムとの連携で対象データが取り込まれない

取引先マスタや人事システムからの連携で、文字コードや項目長の違いで一部の対象データが取り込まれません。登録件数と突き合わせるまで気づけません。

連携取り込み

大量件数の一括チェックで処理が途中で欠落する

一括チェックで大量件数を流すと、途中で処理が打ち切られ、結果が返らない対象が残ります。投入件数と照合しなければ、未処理のまま記録されます。

一括処理の欠落

権限設定と操作ログが規程どおりの形で残らない

検索結果を記録しても、検索時点のデータベース状態が残らなければ、あとから根拠を再現できません。権限設定や操作ログの出力も規程を満たしません。

ログと証跡の保存
02 RISK

検証しないまま運用を続けた場合に起きること

受け入れで検証を省略したまま運用を続けると、不具合は現場の判定ミスや監査指摘として表面化します。見落としが業務と経営へ及ぼす影響を整理します。

業務上の問題対応を行う担当者の様子を写した写真。
03 REVIEW

反社チェックツールのテストで確認する観点

反社チェックツールの受け入れでは、画面が仕様どおり動くかの確認に留まりがちです。判定の妥当性を確かめるには、基準と検索条件の対応、名寄せの挙動、更新前後の差、連携の入出力、証跡の保存という観点が必要です。

基準と検索条件がずれたまま運用が始まり、見落としが発生するおそれがあります。

判定基準と検索条件がもれなく対応しているかを確かめる

コンプライアンス部門が定めた判定基準の文言を、そのまま検索条件へ写しても意図どおり動きません。基準の各項目がどの検索条件と対応するかを表に起こし、抜けのないことを確認します。

確認する資料
  • 判定基準書
  • 検索条件一覧
  • 基準対応表
同姓同名の誤判定や対象外の取りこぼしが現場へ流れるおそれがあります。

同姓同名を含む対象で名寄せの吸収範囲を確かめる

同姓同名や表記ゆれを含む対象名が、想定どおりに名寄せされるかを確かめます。吸収範囲はベンダーの非公開仕様に属することが多く、仕様説明を待つのではなく、テストデータで挙動を検証します。

確認する資料
  • 対象名一覧
  • 期待結果
  • 判定結果
更改後に結果が変わっても、どちらを正とするか説明できないおそれがあります。

データベース更新の反映と同じ対象名での結果の差を確かめる

データベースの更新前後で同じ対象名の結果が変わることがあります。ベンダー更改時は特に差が出やすく、新旧の結果を突き合わせて差の原因を説明できる状態にしておきます。

確認する資料
  • 更新通知
  • 新旧結果
  • 差分一覧
対象データの欠落に気づかず、未チェックの取引先が残るおそれがあります。

一括取り込みでの連携の入出力と取り込み漏れを確かめる

取引先マスタや人事システムからの一括取り込みで、対象データの欠落や重複がないかを確かめます。期待結果を用意したテストデータで、取り込み件数と内容を突き合わせて検証します。

確認する資料
  • 連携仕様書
  • 取込データ
  • 件数突合表
監査で根拠の再現を求められても、説明できないおそれがあります。

社内規程が求める権限と証跡の保存要件への適合を確かめる

判定の根拠と検索時点の情報が、社内規程と監査の求める保存要件を満たす形で残るかを確認します。権限設定と操作ログの出力範囲も、規程との突き合わせで確認します。

確認する資料
  • 社内規程
  • 操作ログ
  • 権限設定表
  • 判定記録
04 TEST DESIGN

反社チェックツールを対象とした第三者テストの内容

導入・受け入れ・定常運用の各場面で、GENZが判定品質を第三者の視点から検証します。

STEP 01 対象範囲と判定基準のヒアリング基準と検索条件の差を具体例で揃えます
どう確かめるか

対象範囲と判定基準にもとづくテスト計画と観点の設計

判定基準の文書と対象範囲を確認し、同姓同名や表記ゆれを含む対象をどう扱うかを観点へ落とします。画面が動くかではなく、判定が基準どおりかを確かめる設計にします。

  • 01判定基準の文書を確認し、検証の対象範囲を確定します
  • 02業務の判定基準と検索条件の差を具体例で洗い出します
  • 03連携する取引先マスタや人事システムの仕様を把握します
OUTPUTテスト計画書と観点表
STEP 02 テスト設計とデータの準備同姓同名・表記ゆれの対象を含めます
どう確かめるか

期待結果との判定結果の突き合わせと差分の整理

想定した結果とツールの出力を突き合わせ、差異がツール側の挙動によるものか運用によるものかを切り分けます。判定のばらつきがどこから生じたかを説明できる状態にします。

  • 01同姓同名や表記ゆれを含むテストデータを用意します
  • 02観点ごとの期待結果を判定基準から導き、文書へ残します
  • 03受け入れ期日から逆算し、範囲の優先順位と実施順を決めます
OUTPUT判定差分の一覧と原因
STEP 03 テストの実施と差異の切り分け差異の原因がツール起因か運用起因かを分けます
どう確かめるか

更改・連携追加にともなう切り替え前後の再検証

ベンダー更改や連携追加の前とあとで、同じ対象名の結果がどう変わるかを検証します。切り替えたあとの結果を正とする根拠を、差分の比較から整理します。

  • 01設計した観点に沿ってツールを実行し、結果を記録します
  • 02期待結果との差異を一覧化し、原因の方向を特定します
  • 03ベンダーへの確認が必要な論点を仕様の問いへ整理します
OUTPUT更改時の再検証結果
STEP 04 報告と改善点の引き渡し検索時点を含めて監査で再現できる証跡を残します
どう確かめるか

あとから再現できる受け入れと監査で使える証跡の整備

検索時点のデータベース状態を含む証跡を整備し、あとから根拠を再現できる形で引き渡します。受け入れの合否材料と内部監査への回答の両方に使えます。

  • 01差異の切り分け結果と判定の水準を報告書としてまとめます
  • 02現場の運用ルールへ反映すべき改善点を整理して引き渡します
  • 03ベンダー更改や連携追加の際に再検証が必要な範囲を示します
OUTPUT監査用の証跡一式
05 RATIONALE

テストを外部へ委託したあとの運用の姿

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

ノートPCを前に担当者同士が相談しているオフィスの写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • 判定の正しさを第三者の検証結果で説明できる状態になります
  • 更改前後の結果の差について、理由を特定して運用を切り替えられます
  • 監査で求められる判定根拠の記録を、再現可能な形で保持できます
  • 判断のばらつきを仕組みで減らし、問合せ対応の負担を抑えられます
06 SERVICE

反社チェックツールの検証で提供するメニュー

反社チェックツールの検証は、開発側から独立した立場で行なうからこそ、稟議と監査で説明できる材料になります。GENZは、テスト計画の段階から稼働後の再検証まで、範囲を区切ってご依頼いただけます。

SVC 01

受け入れ判定に使えるテスト計画を作成する

テスト観点の洗い出しと優先順位付けをご一緒し、受け入れ判定に使える計画書として整理します。稟議資料へ載せられる粒度でお渡しします。

リスク要因と優先順位を示す無文字の図解。
SVC 02

テストの設計と実施を引き受ける

判定基準どおりに動くかのテストケースを設計し、期待結果と照合します。合否の根拠とともに記録し、受け入れと監査で参照できる形で残します。

複数のシステムや連携先にまたがる確認範囲を示す無文字の図解。
SVC 03

開発の工程と伴走して検証する

更改や連携追加の工程に合わせ、仕様変更のたびに範囲を区切り検証します。リリース前にずれを洗い出し、修正の要否を判断できる形で戻します。

計画から報告までの流れを示す無文字の図解。
SVC 04

稼働後の再検証を継続して担う

稼働後はベンダーの仕様変更や更新に合わせて再検証し、前回との差を確認します。差の理由を説明できる記録を残し、判断のばらつきを抑えます。

確認対象の領域を区分して示す無文字の図解。
07 FLOW

ご依頼から報告までの流れ

問合せ、お見積、ご契約と準備、実施と報告の各段階で確認する内容を示します。

フォームまたは電話でのお問合せ

ツール更改の時機と受け入れ判定の期日を伺い、ご相談の内容を整理します。

検証範囲の確認とお見積の提出

テスト対象の範囲と優先順位、必要工数を整理し、お見積を提出します。

ご契約と資料の受領・テストの準備

判定基準と受け入れ基準の資料を預かり、テスト設計の準備を進めます。

テストの実施と結果報告書の提出

テストを実施して報告書にまとめ、合否判断の材料としてお渡しします。

開発側から独立した第三者検証のご相談

反社チェックツールの検証について相談する

相談の場では、検証範囲の区切り、確かめる項目の優先順位、必要な工数の見通し、稼働後の再検証の要否まで整理してお渡しします。期日が迫る段階でも、範囲を限定した着手をご提示できます。