メールがチケット化されず問い合わせが滞留する
受付メールの取り込み条件が自社の運用と合わず、問い合わせがチケットとして登録されません。申告が届かないため滞留に気づけず、一次応答が遅延します。
GENZ, Inc.
設定した本人以外が確かめる
ヘルプデスクツールの
設定した本人以外が確かめる
ヘルプデスクツールの品質を第三者の視点で検証します
問い合わせ区分・権限・通知の組み合わせは、設定した本人の確認では抜けが残ります。GENZは第三者の視点で、自社の運用条件でのテスト設計と実行を担います。
支援事例
支援実績5,000件以上
ヘルプデスクツールでよくある不具合
ヘルプデスクツールの更改では、設定した本人が確認する体制になりやすく、想定内の操作だけが検証されます。その結果、通知の不達やSLA計測の誤りのように、リリース後になってはじめて判明する不具合が残ります。
メールが
担当の自動振り分けが条件の優先順位を反映せず、別部署へ割り当てられる
振り分け条件の優先順位が適用されず、チケットが所管外の部署へ割り当てられます。転送が手作業での対応となり、通常業務と並行して負荷がかかります。
ステータスを更新しても、問い合わせ元への通知が送信されない
ステータス更新と通知テンプレートの紐づけが反映されず、問い合わせ元へ進捗が届きません。再問い合わせが増え、対応工数が重複して発生します。
営業時間や休日が反映されずSLA超過を検知できない
営業カレンダーや優先度の設定がSLA計測に反映されず、超過を検知できません。集計レポートに未達が現れた時点で、取引先への説明が必要になります。
FAQの検索結果に、公開範囲の対象外である記事が表示される
公開範囲と権限の設定が検索機能に反映されず、社内向け記事が外部の検索結果に表示されます。情報の取り扱いとして監査で指摘されるおそれがあります。
残存した不具合により生じる問題
リリース後に判明した不具合は、問い合わせ対応の現場で順に表面化し、業務停止や監査指摘として積み上がります。
静的テスト（レビュー）でおさえるべき観点
レビューは、設定を適用する前に帳票どうしの記載を照合して誤りを検知する工程です。要件定義書や設計書の段階で不整合を確認しておけば、リリース前テストの手戻りを抑えられます。
想定外の経路から登録された問い合わせが担当者へ通知されず、一次応答が遅延するおそれがあります。
受付チャネルの一覧と、要件定義で定めた受付範囲を照合する
要件定義で受け付けると定めたチャネルと、設定画面で有効化したチャネルを照合します。定義にないチャネルが有効なままだと、想定外の経路から登録された問い合わせが担当振り分けの対象から外れます。
確認する資料
- 要件定義書
- チャネル一覧
- 設定一覧
解決確認の工程が抜けたままチケットが完了となり、未解決の問い合わせが滞留として後から表面化するおそれがあります。
ステータス遷移の規則と、権限マトリクスの編集可能範囲を照合する
ステータス遷移の規則と、役職ごとの編集可能範囲を定めた権限マトリクスを照合します。一次対応オペレーターが「完了」へ直接変更できる設定のままだと、解決確認の工程が抜けたまま記録が確定します。
確認する資料
- 遷移規則書
- 権限マトリクス
- 操作権限表
SLAの集計値と実際の対応状況が一致せず、サポート部門への報告や取引先への説明に誤った数値を使うおそれがあります。
SLA定義と、営業カレンダー・優先度の設定値を照合する
SLA定義書の応答期限・解決期限と、ツールの営業カレンダー・優先度の設定値を照合します。休日の扱いが定義と異なると、期限内に対応してもSLA未達と集計され、レポートが実態と合いません。
確認する資料
- SLA定義書
- 営業カレンダー
- 優先度設定表
差し込み項目が空欄の通知が送信され、問い合わせ元からの再問い合わせが増え、オペレーターの対応負荷が上がるおそれがあります。
通知テンプレートの差し込み項目と、DB設計書の項目定義を照合する
通知メールのテンプレートに差し込む項目と、データベース設計書の項目定義を照合します。定義にない項目を参照するテンプレートは、値が空欄のまま送信され、問い合わせ元が進捗を確認できません。
確認する資料
- 通知テンプレート
- DB設計書
- 項目定義書
履歴の一部が欠落したまま移行が完了と扱われ、監査や障害調査で過去の対応記録を提示できないおそれがあります。
移行対象の問い合わせデータ項目と、移行先のフィールド定義を照合する
移行する問い合わせ履歴のデータ項目と、移行先のフィールド定義を項目単位で照合します。対応する項目が移行先にない場合、履歴の一部が欠落したまま完了と扱われ、過去の問い合わせを参照できません。
確認する資料
- 移行計画書
- データ項目一覧
- フィールド定義書
- 移行対象範囲表
動的テストの設計・実行のポイント
ヘルプデスクツールのテストは、工程を分けて段階的に進めます。各工程で確かめる対象と、確認漏れで起きる不具合を整理します。
STEP 01
ユニットテスト対象: チケット登録画面の入力項目単位
どう確かめるか
ユニットテストで、入力項目の境界値と必須判定をチケット登録画面の単位で確認する
チケット登録画面の単位で、件名や本文の文字数の境界値、必須項目の未入力、区分の選択漏れを検証します。担当振り分け条件と入力値の組み合わせが意図どおり適用されるかを確かめます。
- 01件名・問い合わせ内容の文字数の境界値を検証します
- 02必須項目の未入力時にエラーになるかを確認します
- 03入力値と担当振り分け条件の組み合わせを検証します
OUTPUT入力境界値の確認結果
STEP 02
統合テスト対象: 通知・連携先システムとの受け渡し
どう確かめるか
統合テストでモジュール間の連携を確認する
登録から通知、エスカレーションまでの連携を確かめます。受付チャネルごとの取り込みと、認証基盤や人事マスタとの同期を検証し、連携先の仕様変更で通知が届かなくなる不具合を検知します。
- 01メール・Webフォーム・チャットからの取り込みを確認します
- 02認証基盤・人事マスタとの権限同期を検証します
- 03エスカレーション時の通知と担当者変更を確認します
OUTPUTモジュール間連携の確認結果
STEP 03
システムテスト対象: 受付から解決までの業務全体
どう確かめるか
システムテストで業務シナリオと異常系を確認する
問い合わせの受付から解決、クローズまでの業務シナリオを通しで実行し、SLA計測やレポート集計の正しさを確かめます。通知の不達や権限外の参照といった異常系も、この工程で検証します。
- 01受付から解決・クローズまでのシナリオを実行します
- 02SLA計測と集計レポートの数値を検証します
- 03通知の不達・権限外参照などの異常系を検証します
OUTPUT業務シナリオの検証結果
STEP 04
受け入れテスト対象: 運用部門の実際の手順
どう確かめるか
受け入れテストで運用手順どおりの操作と回帰による不具合を確認する
一次対応オペレーターが運用手順どおりに操作し、業務として成立するかを確認します。設定変更の影響を回帰テストで確かめ、残存する不具合票をリリース判断の材料として整理します。
- 01運用手順どおりの操作で受け入れテストを実施します
- 02設定変更箇所の周辺に回帰テストを実施します
- 03不具合票を残存リスクとして整理し、判断材料にします
OUTPUT運用手順どおりの動作確認
GENZが代行するヘルプデスクツールのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 自社の設定と運用に合わせたテスト項目書を作成します
- 第三者の視点で設定の前提から点検します
- リリース判断の根拠となる報告書を提出します
- 設定変更や自動更新ごとの回帰テストの基準を整理します
問い合わせ運用を止めずに進める第三者検証
比較記事で製品を選んでも、自社の設定が正しく動くかは設定した本人にしか確かめられません。GENZは設定の主体から独立した立場で、自社の運用条件に沿ったテスト設計から実行、報告までを担います。
自社の設定からテスト設計を起こす
問い合わせ区分・担当振り分け条件・権限・通知テンプレートなど、自社で設定した組み合わせを対象にテスト項目書を作成します。
運用から移行まで広く検証
受付チャネル・権限・通知からSLA計測、既存履歴・FAQ記事の移行まで検証範囲に含め、ユニットテストから受け入れテストまでを担います。
今の開発体制のまま伴走する
テストの実行工数をGENZへ移せるため、設定作業と検証を並行して進められます。現在の開発体制や進め方は変えず、工程に合わせて伴走します。
リリース判断と監査で使える形で提出
残存する不具合と確認していない範囲を区別した報告書を、テスト項目書・不具合票とあわせて提出します。監査でも参照できる記録になります。
ご相談から納品までの流れ
ご相談から報告書の納品まで段階的に進めます。各工程で確認結果を共有し、既存の運用に合わせて調整します。
ヒアリング
問い合わせ区分や権限、SLAの設定状況をお聞きし、検証範囲を整理します。
テスト設計と見積もり
テスト観点を設計し、検証範囲と工数、成果物の形式を見積もりで示します。
テストの実施と進捗の共有
実際の操作手順に沿って検証を進め、気づいた点と進捗を定期的に共有します。
報告書の納品と修正後の再確認
検証結果を報告書として納品し、修正箇所は修正後の動作を再確認します。
ヘルプデスクツール導入をご検討中の企業様へ
ヘルプデスクツールの検証範囲と優先順位をGENZにご相談ください
設定の組み合わせが自社の運用条件で正しく動くかは、設定した本人以外の検証で判断材料になります。ご相談では、テスト範囲の整理と優先順位、必要工数の考え方を確認できます。