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

静的テスト(レビュー)でおさえるべき観点

権限の付与・失効の条件は、人事側と設備側の設計書に分かれて書かれ、どちらにも全体が揃いません。動的テストの前のレビューで照合基準を決めておくと、受け入れテストの項目に落とせない条件を設計段階で洗い出せます。

照合基準がないままレビューを進めると、権限の残存を設計書の段階で検出できません。

権限グループと扉・ゲートの対応表を、組織図と区域の管理基準と照合する

権限グループと扉・ゲートの対応表は、組織図の所属単位と区域の管理基準と照合します。所属と区域の両方を基準にしないと、異動後に不要な権限が残る組み合わせを見落とします。

確認する資料
  • 権限対応表
  • 組織図一覧
  • 区域基準書
失効の基準日が確定しないと、退職者の権限が残る期間を誰も説明できません。

権限の失効条件を、人事部門の手続の基準日とシステムの適用日で照合する

権限の失効条件は、人事部門の手続の基準日と、システム側で権限を失効させる適用日で照合します。両者に時間差があると、その期間は権限が残存したまま記録に現れません。

確認する資料
  • 失効条件表
  • 人事基準日表
  • 適用日定義
連携項目の桁の不整合は、稼働後の権限の欠落として初めて表面化します。

人事システム連携の項目と桁をAPI定義とDB設計で照合する

人事システム連携では、従業員番号や所属コードの連携項目と桁を、API定義とDB設計書で照合します。桁や形式が異なると取り込みで欠落し、特定の従業員だけ権限が付与されない事象が残ります。

確認する資料
  • API定義書
  • DB設計書
  • 連携項目表
出力項目が監査要件に合わないと、指摘への追加確認が毎期の固定工数として残ります。

記録の保持期間と出力項目を、社内規程と監査の確認要件で照合する

入退室記録の保持期間と出力項目は、社内の文書管理規程と監査部門の確認要件で照合します。制限が機能することを確かめた手続の記録がないと、監査のたびに同じ指摘が繰り返されます。

確認する資料
  • 保持期間表
  • 社内規程類
  • 監査要件表
拠点差を設計段階で洗い出さないと、拠点展開の遅延と運用の二重化が発生します。

拠点ごとの機種・世代の構成一覧を、権限配信と記録形式の仕様で照合する

拠点ごとにリーダーやゲートの機種・世代が異なるため、構成一覧を権限配信と記録形式の仕様で照合します。ある拠点で成立した設定が他拠点で成立しない組み合わせを設計段階で特定します。

確認する資料
  • 拠点構成表
  • 機種一覧表
  • 配信仕様書
  • 記録形式表
04 TEST DESIGN

動的テストの設計・実行のポイント

入退室管理システムの検証は、権限の判定、連携、通行制御、運用手順の工程に分けて設計し、工程ごとに検証範囲を限定します。

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

GENZが代行する入退室管理システムのテスト

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

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

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

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

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

専門ノウハウを即戦力で

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

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

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

  • 拠点・扉・権限の代表組み合わせを基準付きで絞り込めます
  • 権限の残存や記録の欠落を発生させて検証できます
  • 電気錠・ゲートと管理ソフトウェアをまたぐ検証を一括で任せられます
  • リリース判断と監査に使える検証範囲と結果の記録が残ります
06 SERVICE

検証範囲を根拠とともに示す支援

どこまで確かめれば足りるかは、権限・記録・設備の組み合わせから根拠を持って絞り込めます。GENZは、発注側・構築ベンダーのいずれにも属さない第三者として、テスト設計から報告書の納品までを担います。

SVC 01

権限と記録の流れからテスト設計

人事データから権限の付与・失効の流れをたどり、退職後の権限残存や記録の欠落が起きる条件を洗い出して、テスト項目書へ反映します。

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

管理ソフトと拠点設備をまたいで検証する

管理ソフトウェア側と扉・電気錠・セキュリティゲート側で担当が分かれる構成でも、両方をまたいだ動作をひとつの体制で検証します。

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

既存の体制に第三者として加わる

既存の体制やベンダーとの関係はそのままに、検証機能だけを追加します。テスト設計・項目書作成・実行の単位でご依頼いただけます。

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

検証範囲を監査に使える報告書で納品

何をどの範囲で確かめ、どこを実施しなかったかを第三者が追える報告書で納品します。リリース判断とシステム監査の指摘対応にそのまま使えます。

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

ご相談から納品までの流れ

入退室管理システムの検証は、拠点構成と権限体系の確認から始め、報告書の納品まで進めます。

拠点構成と権限体系のヒアリング

扉・ゲートの配置と権限グループ、人事データ連携の条件を伺います。

テスト設計と見積もりのご提示

ヒアリング内容をもとにテスト項目を設計し、検証範囲と費用を提示します。

テストの実施と不具合票の共有

実機のリーダーとゲートを含む環境でテストを実施し、不具合票を随時共有します。

報告書の納品と修正後の再確認

検証範囲と結果を報告書として納品し、修正箇所は改めて発生させて検証します。

検証範囲の整理から始められます

入退室管理システムの検証範囲と優先順位をGENZにご相談ください

拠点や機種の差を踏まえ、どこまで確かめるかを要件と運用に合わせて絞り込みます。ご相談では、テスト範囲と優先順位、必要工数の考え方、関連テストの要否までお示しします。