権限のない利用者の画面に個人番号が表示される
権限とユーザーの組み合わせを確認しきれないまま運用を始めると、参照権限のない担当者に個人番号が表示され、安全管理措置の不備として扱われます。
GENZ, Inc.
その検証、誰が確認？
マイナンバー管理ツールを
その検証、誰が確認？
マイナンバー管理ツールを第三者視点で検証します
本人が立てた観点を本人が確かめる構造では、抜け漏れがリリース判断の場で表面化します。GENZがテスト設計から報告まで第三者の視点で担います。
支援事例
支援実績5,000件以上
マイナンバー管理ツールでよくある不具合
マイナンバー管理ツールの不具合は、権限設定や収集経路、システム連携、破棄処理の境界値で起きます。個人番号の誤表示や誤提供は安全管理措置の不備に直結するため、どこで起きやすいかを先に押さえます。
権限の
扶養親族の個人番号が別の従業員に紐づけて登録される
扶養親族の番号は従業員と紐づけて管理されるため、登録時の誤りがあると別の従業員の扶養親族として登録され、届出データへ誤った番号が出力されます。
給与システムとの連携で個人番号の保持状態が反映されない
給与・人事システムとの連携で保持状態が反映されないと、登録済みの番号が未登録として扱われ、収集状況の一覧と実態が一致しないまま督促が進みます。
保管期限を過ぎた個人番号が破棄処理の対象から外れる
破棄処理は保管期限の当日・翌日という境界値で挙動が異なります。年に数回しか発生せず確認の機会が少なく、期限超過分が対象から外れたまま残ります。
正しい形式の個人番号が受け付け時に不備として差し戻される
収集経路の設定が変わると、正しい形式の番号が不備として差し戻され、従業員への再提出依頼と差し戻し対応の工数が増えます。
残存した不具合により生じる問題
リリース後に残った不具合は、検証上の問題にとどまりません。人事部門の工数と安全管理措置の運用に、そのまま影響します。
静的テスト（レビュー）でおさえるべき観点
マイナンバー管理ツールの確認漏れは、テストの実行前に、設計書と運用ルールの不整合として文書の段階で検出できます。権限・保管期限・連携・帳票・リビジョンの観点ごとに、照合する資料と確認の要点を整理します。
照合しないまま運用を開始すると、権限のない利用者へ個人番号が表示され、安全管理措置の不備として扱われるおそれがあります。
権限設計書とシステムユーザーの登録内容を照合する
システムユーザーの一括登録と権限設計の組み合わせは件数が多く、全件の動作確認は現実的ではありません。権限設計書とユーザー一覧を照合し、設計どおりの権限が付与されているかを文書上で確認します。
確認する資料
- 権限設計書
- ユーザー一覧
- 操作権限表
期限判定の基準が食い違うと、保管期限を過ぎた番号が残存し、内部監査で破棄記録との整合を示せなくなるおそれがあります。
DB設計書の保管期限項目と運用ルールの保管期間を照合する
保管期限を過ぎた個人番号の破棄は、期限の当日・翌日という境界値で挙動が異なります。DB設計書の保管期限項目と運用ルールの保管期間を照合し、期限判定の基準日が一致しているかを確認します。
確認する資料
- DB設計書
- 運用ルール
- 保管期限表
突合キーの不整合を見逃すと、別人の番号が給与データへ紐づき、誤った番号のまま届出が進むおそれがあります。
連携仕様書の突合キーと給与システム側の項目定義を照合する
給与・人事システムとの連携では、突合キーの定義に不整合があると別人の番号が紐づきます。連携仕様書の突合キーと給与システム側の項目定義を照合し、型・桁数・一意性が一致しているかを確認します。
確認する資料
- 連携仕様書
- 項目定義書
- 突合キー表
様式改定への追随漏れは、欠落項目のある帳票が届出先へ提出され、是正対応と再提出のコストが発生するおそれがあります。
届出様式の記載項目と帳票設計書の出力項目を照合する
届出様式の改定は帳票の出力項目へ反映されます。届出様式の記載項目と帳票設計書の出力項目を照合し、改版に出力定義が追随しているかを確認します。欠落項目のまま届出先へ提出される事態を防げます。
確認する資料
- 届出様式
- 帳票設計書
- 出力項目表
リビジョンの影響範囲を切り出せないと、確認していない範囲が残ったまま適用が進み、障害時に原因の切り分けができなくなるおそれがあります。
リビジョンの変更内容と自社の設定・連携仕様を照合する
製品のリビジョンは継続して更新され、変更内容が公開されています。変更内容と自社の設定・連携仕様を照合し、影響する機能を切り出して回帰テストの範囲を決めます。
確認する資料
- 変更内容一覧
- Webマニュアル
- 設定一覧表
- 回帰範囲表
動的テストの設計・実行のポイント
マイナンバー管理ツールの検証は、段階ごとに対象を分けて設計します。段階別の着眼点と確認漏れが起きやすい箇所を整理します。
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は第三者の視点でテスト設計から実行・報告までを担い、既存の進め方のまま検証工程を足します。
設計書と運用ルールの照合から始めます
検証の起点は貴社の仕様書・設計書と運用ルールです。リビジョンの変更内容から影響範囲を切り出し、設計書との照合で検証範囲を決めます。
収集から破棄まで一貫して検証
収集・保管・利用・破棄の流れを、給与・人事システムとの連携まで含めて通して検証します。暗号化設定や本人確認手段の変更にも対応します。
現行体制のまま検証を足せます
発注側主導でもベンダー主導でも、QAがPM兼務でも独立部門でも、現行の体制のまま検証だけを差し込めます。既存工程との分担も調整します。
検証済みと未検証を同じ報告書に書く
検証した範囲と残る範囲を同じ報告書に記載し、技術部門以外の方が判断できる粒度で示します。証跡は内部監査で照合できる形で管理します。
ご相談から納品までの流れ
マイナンバー管理ツールの検証は、ヒアリングから報告書の再確認までの工程に分けて進めます。
ヒアリング
製品形態や連携先、収集経路、権限設定の状況を伺い、検証の前提を確定します。
テスト設計と見積もり
テスト観点を整理し、検証範囲と優先順位、必要工数を見積もります。
テストの実施と進捗の共有
合意した項目書に沿ってテストを実施し、不具合票と進捗を定期的に共有します。
報告書の納品と再確認
検証済みと未検証の範囲を分けた報告書を納品し、内容の再確認にお答えします。
まずは無料相談で検証範囲を整理
マイナンバー管理ツールの検証範囲と優先順位をGENZにご相談ください
相談では、テスト範囲の整理と優先順位、必要工数の考え方、周辺システムの関連テストの要否まで、第三者検証の進め方をご提示します。リリース判断と監査対応に使える材料をお渡しします。