退職日を過ぎてもアカウントが停止されず残る
人事データの登録時刻と停止処理の実行時刻に不整合があると、退職日を過ぎてもアカウントが残り、社外から業務データへ到達できる状態が続きます。
GENZ, Inc.
第三者検証サービス
SaaS管理ツールの
第三者検証サービス
SaaS管理ツールの連携とコスト集計を検証します
SSO・SCIM連携の設定からID単位のコスト集計まで、受け入れの検証範囲を整理し、リリース判断とシステム監査に使える報告書として納品します。
支援事例
支援実績5,000件以上
SaaS管理ツールでよくある不具合
SaaS管理ツールはSSO・SCIM連携やコスト集計を担い、連携先SaaSごとのAPI仕様差や日付の境界値による不具合が起きやすい対象です。放置すれば請求額の差異や退職者アカウントの残存として表面化します。
退職日を
入社日当日になってもアカウントが発行されていない
発行処理が入社日の当日と前日のどちらで実行されるかを確認していないと、入社日当日にアカウントが発行されず、新入社員が業務を始められません。
取得したアカウント数が契約ライセンス数と一致しない
連携先SaaSごとにAPIの取得頻度や権限モデルが異なるため、取り込めたアカウント数が契約ライセンス数と一致しないまま集計の母数になります。
稼働中のアカウントが休眠として判定される
ログイン実績の集計期間や判定ロジックの確認がないと、稼働中のアカウントが休眠と判定され、解約・停止の対象として誤って計上されるおそれがあります。
コストレポートの課金対象ID数が請求額と合わない
課金対象IDの集計定義がツール側の仕様と契約条件で異なると、コストレポートの数値が請求額と合わず、差異の原因特定に部門間の往復が発生します。
残存した不具合により生じる問題
検証が行われないまま運用を続けると、不具合はアカウント管理・請求・意思決定のそれぞれの場面で表面化し、監査での指摘やコスト増として残ります。
静的テスト（レビュー）でおさえるべき観点
SaaS管理ツールの導入では、ベンダーの動作確認が設定反映の確認にとどまり、自社の業務シナリオを通した検証は発注側が担います。実行前に設計書や契約条件を照合する静的テストでおさえるべき観点を整理します。
項目の対応づけを検証した記録が残っていなければ、退職者のアカウントが停止されない事象が起きたとき、人事データの登録遅れか連携処理の不備かを判別できず、原因調査が部門間の往復になります。
人事データとSaaS管理ツールの項目対応を照合する
人事システム側の項目定義と、SaaS管理ツールが取り込む項目の対応表を照合します。入社・異動・退職のどの項目がアカウントの発行・停止の起点になるか、記載の抜けがないかを確認します。
確認する資料
- 人事項目定義書
- 項目対応表
- 連携設定一覧
取得仕様の差異を照合していなければ、取り込めた件数と契約ライセンス数が一致しているかを確認する手段が設定画面の表示だけになり、集計の母数が確からしくないまま利用状況とコストの数値を提出することになります。
API定義と、連携先SaaSごとの取得仕様・権限の範囲を照合する
API定義書と連携先SaaSごとの取得仕様を照合します。取得頻度・ページング・必要な権限はSaaSごとに異なるため、取得件数と契約ライセンス数の突き合わせ方まで記載があるかを確認します。
確認する資料
- API定義書
- 権限設定表
- 取得件数照合表
付与ルールの設計が雇用区分の体系と一致していなければ、兼務者への権限付与が過剰または不足のまま運用が進み、棚卸しのたびに手作業での対応となる例外が積み上がります。
付与ルールの設計書と、雇用区分・権限区分の体系を照合する
権限付与ルールの設計書と、自社の雇用区分・部門権限の体系を照合します。兼務者や契約形態の違いで付与すべき権限が変わる場合、設計書上のルールで一意に決まるかを確認します。
確認する資料
- 権限設計書
- 雇用区分表
- 付与ルール表
集計条件と契約条件が一致していなければ、課金対象IDの定義変更の局面で請求額の差異として表面化します。従業員数に比例するため、判明が遅れるほどコスト増は拡大します。
課金対象IDの集計条件と、契約条件の記載を照合する
課金対象IDの集計条件と、提供元との契約条件の記載を照合します。休眠アカウント・兼務者の重複・退職者の除外時点の定義が双方で一致しているかを確認します。差異は請求額の差として表面化します。
確認する資料
- 集計条件定義
- 契約条件書
- 課金ID一覧
異常系の仕様が未定義のままリリースすれば、入退社日の境界値やAPI応答の失敗時にどう動くかを誰も説明できず、リリース可否の判断材料として検証の十分性を示せません。
異常系の仕様と例外処理の記載を照合する
外部APIの応答遅延・失敗時の挙動、入退社日の境界値、同一人物が複数SaaSで異なるIDを持つ場合の突合など、異常系の仕様と例外処理の記載を照合します。仕様が未定義のままの箇所を洗い出します。
確認する資料
- 異常系仕様書
- 例外処理一覧
- 突合ルール表
- ID対応表
動的テストの設計・実行のポイント
SaaS管理ツールの検証は、入社から退職までの業務シナリオを軸に、段階ごとの工程に分けて進めます。
STEP 01
テスト設計業務シナリオから検証範囲を定義する
どう確かめるか
テスト設計: 業務シナリオから入退社の処理と集計の検証範囲を絞り込む
入社・異動・退職の一連の処理とコスト集計を業務シナリオとして洗い出し、日付の境界値や同一人物の複数IDの突合といった異常系のテスト観点を加えて、検証範囲を絞り込みます。
- 01入社から退職までの業務シナリオの洗い出し
- 02異常系のテスト観点を加えたテスト項目書の作成
- 03管理対象SaaSの変動を前提にした検証範囲の線引き
OUTPUT検証範囲と優先順位の一覧
STEP 02
統合テストモジュール間の連携の不整合を検出する
どう確かめるか
統合テスト: 人事システムと連携先SaaSの間のモジュール間の連携を確かめる
人事システムからの登録が連携先SaaSへ正しく反映されるか、SaaSごとに異なるAPIの仕様と権限のもとで取得したアカウント件数が契約ライセンス数と一致するかを確認します。
- 01人事データとの項目の対応づけの確認
- 02取得したアカウント件数と契約ライセンス数の照合
- 03SSO・SCIM連携の権限設定の確認
OUTPUT連携部分の確認記録
STEP 03
システムテスト日付の境界値を（意図的に）発生させて検証する
どう確かめるか
システムテスト: 入社から退職までの一連の処理と境界値を確かめる
入社日・退職日という日付の境界値でアカウントの自動発行・自動停止が期日どおりに動くかを、（意図的に）発生させて検証し、課金対象IDの集計結果と請求額の突き合わせまで行います。
- 01入社日・退職日の境界値での自動発行・自動停止の検証
- 02同一人物が複数SaaSで異なるIDを持つ場合の突合の検証
- 03課金対象IDの集計ロジックと請求額の突き合わせ
OUTPUT境界値の検証結果一覧
STEP 04
受け入れテストと回帰テスト判断材料として残し、変更後の影響を確認する
どう確かめるか
受け入れテストと回帰テスト: リリース判断の材料と連携追加後の影響を確かめる
検証範囲・検出した不具合・未検証として残した範囲をリリース判断の材料として整理します。連携先SaaSの追加やツール側の仕様更新のたびに、回帰テストの範囲を決める基準を持てます。
- 01検証範囲と不具合一覧のリリース判断材料への整理
- 02未検証として残した範囲の明示
- 03連携追加・仕様更新後の回帰テスト範囲の設定
OUTPUT判断材料と回帰テスト結果
GENZが代行するSaaS管理ツールのテストの種類
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 連携追加のたびに回帰テストの範囲を再設計する負荷がなくなる
- 入退社日やAPI失敗など異常系の観点を網羅した項目書が得られる
- リリース判断と監査の両方で使える検証記録の様式が整う
- 管理対象が変動する前提でのテスト設計の考え方を持てる
検証範囲を第三者視点で設計するGENZ
SaaS管理ツールの検証では、社内の経験則だけでは観点の抜けに気づけない領域があります。GENZは発注側に立つ第三者として、検証範囲の設計から報告書の納品まで、既存のベンダー体制を組み替えずに関与します。
業務シナリオを起点にテスト設計する
入社・異動・退職の業務シナリオから逆算してテスト項目を組み立てます。実際の操作の流れに沿って検証範囲を決めるため、抜けを防げます。
連携先SaaSの追加分まで検証範囲に含める
管理対象のSaaSは棚卸しのたびに変わるため、連携先の追加や仕様更新を検証の契機として定義し、追加分も範囲に含めます。
既存の導入ベンダー体制に重ねて関与する
導入ベンダーの作業範囲はそのままに、発注側の検証だけを追加します。スプリントへ並行して参画するため、支出の重複という障壁が生じません。
リリース判断と監査に使える報告書を納品
検証範囲・検出した不具合・未検証の範囲を記録した報告書を納品します。リリース判断の材料とシステム監査の証跡の両方に使える形です。
ご相談から納品までの流れ
相談から納品までは、ヒアリング、テスト設計と見積もり、テストの実施、報告書の納品の順で進めます。
ヒアリング
対象の連携構成と人事データの対応関係、ベンダーの作業範囲を確認します。
テスト設計と見積もり
検証範囲を線引きし、テスト項目と成果物、期間、費用を提示します。
テストの実施と進捗の共有
検証環境でテストを実施し、不具合票で管理して週次で進捗を共有します。
報告書の納品と再確認
検証範囲・不具合一覧・未検証の範囲を記した報告書を納品し、再確認します。
ご検討中の企業様へ
SaaS管理ツールの検証範囲と優先順位をGENZにご相談ください
SaaS管理ツールの受け入れで何をどこまで検証するかは、構成要素ごとに整理できます。GENZへご相談いただければ、検証範囲と優先順位、必要工数を稟議に使える水準でお示しします。