GENZ, Inc.

情報システム部門の方へ フィールドサービス管理を第三者がテスト設計から検証

配車・作業報告・請求まで連動するシステムで、何をどこまで確かめるか。その線引きを、テスト設計から第三者の視点で整理します。

支援事例

支援実績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

フィールドサービス管理システムでよくある不具合

フィールドサービス管理システムは、配車・作業報告・部品の在庫引き当て・請求までが連動するため、一箇所の不具合が現場の稼働とバックオフィスの両方に波及します。更改時に確認しておきたい代表的な不具合を挙げます。

同一の技術者に同時刻の訪問予定が重複して割り当てられる

配車の割当処理で同一技術者への重複チェックが働かないと、同時刻に訪問予定が重なり、現場で作業の待機と日程の再調整が発生します。

配車・スケジュール

オフライン入力の同期で作業実績と使用部品が二重に計上される

現場でオフライン入力した作業実績が、復帰時の同期で重複送信されると、実績と使用部品が二重に計上され、在庫数と請求額の両方に差異が残ります。

オフライン同期

保守契約の無償範囲を誤判定し、作業料金の請求を誤る

無償範囲は契約条件の境界値で判定されます。条件の取り違えがあると無償の作業を有償で請求し、訂正とクライアントへの説明対応が発生します。

請求判定・契約条件

受付時刻の記録がずれ、SLAの対応期限の超過判定が誤る

受付時刻と対応開始時刻の記録に差異があると、SLAの対応期限の超過判定が誤ります。日付をまたぐ案件では、サービス水準の報告値が誤ります。

SLA対応期限管理

在庫の引き当てと実在庫がずれ、部品がなく再訪問になる

部品の引き当てを在庫システムと連携する場合、タイミング差で引当数と実在庫に不整合が残ります。現場で部品不足が判明し、再訪問が必要になります。

在庫引き当て連携
02 RISK

残存した不具合により生じる問題

不具合は現場の稼働・請求・監査対応へそのまま影響します。リリース後に残存した場合に起きる問題を、事業レベルと企業レベルに分けて挙げます。

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

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

検証は、画面を操作する前の静的テストから始めます。配車の計算順序・SLAの期限計算・請求項目の定義・オフライン同期・権限設定を設計書と照合し、不整合を検知できれば受け入れテストでの手戻りを減らせます。

配車の計算順序が仕様と一致しないままリリースすると、本来アサインされるべき技術者に案件が回らず、現場では配車の手直しが手作業での対応となる作業として積み上がります。

配車の割当ロジックを、技術者のスキルマスタと稼働の制約条件と照合する

配車の自動割当は、スキルマスタと稼働の制約条件のどちらを先に評価するかで結果が変わります。計算順序を要件定義書と照合し、複数案件が競合した場合の優先順位が仕様と一致するかを確認します。

確認する資料
  • 要件定義書
  • スキルマスタ
  • 割当仕様書
SLAの期限計算に不整合があると、対応期限の超過を誤判定または未検知し、初回修理完了率や顧客満足度といったサービス水準の指標が低下します。

SLAの対応期限の計算順序を、保守契約の条件一覧と照合する

SLAの対応期限は、受付時刻の起算点・営業時間の扱い・休日を含めるかで計算結果が変わります。保守契約の条件一覧と設計書の計算順序を照合し、日付の境界値で期限日が一致するかを確認します。

確認する資料
  • 保守契約書
  • 期限計算仕様
  • 営業日定義
請求データの項目定義が連携先と一致しないと、請求の訂正と再発行が発生し、短期のコスト増と入金の遅延につながります。

請求データの項目定義を設計書と連携先API定義に照合する

請求データを生成する項目は、設計書と連携先のAPI定義で、項目名・桁数・単位が一致しているかを照合します。連携方式がAPI連携かCSVかで照合対象が分かれるため、方式を先に確定させます。

確認する資料
  • 画面設計書
  • API定義書
  • 連携項目一覧
オフライン同期の例外パターンが未定義のままだと、作業実績の二重登録や未送信の滞留がリリース後に表面化し、作業報告の信頼性を損ないます。

オフライン同期仕様を例外パターン一覧と照合する

オフライン入力は、復帰時の同期で二重登録・上書き消失・未送信の滞留が起き得ます。同期仕様書と例外パターンを照合し、通信断・強制終了・同時更新の各パターンに処理の定義があるかを確認します。

確認する資料
  • 同期仕様書
  • 例外一覧
  • 状態遷移図
権限と操作記録の定義が要件と一致しないと、第三者が後から追える証跡が残らず、システム監査の提出の段階で未実施項目とあわせて説明できない状態になります。

権限と証跡の定義を要件と照合する

権限の境界は役割ごとに異なり、どの記録が残るかが監査の説明材料になります。権限設定の一覧とログ出力の仕様を要件定義書と照合し、操作者・日時・変更前後の値が追跡できるかを確認します。

確認する資料
  • 権限一覧表
  • ログ仕様書
  • 要件定義書
  • 監査証跡一覧
04 TEST DESIGN

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

動的テストは段階ごとに検証範囲が異なり、後の段階で見つかった不具合ほど手戻りと現場への影響が大きくなります。

STEP 01 ユニットテスト期限と料金の計算誤りを早期に検出します
どう確かめるか

ユニットテストで、期限計算と料金算出を境界値分析と同値分割で確かめる

SLAの期限計算やサービス料金の算出を、日付・時刻の境界値分析と契約条件の同値分割で検証します。期限の当日と翌日、部品代が加算される境界で計算結果を確かめます。

  • 01SLAの期限計算に境界値分析を適用し、日付・時刻の境界で計算結果を確認します
  • 02サービス料金と部品代の算出条件を同値分割でグループ化し、代表値で検証します
  • 03配車の自動割当がある場合、計算順序が仕様どおりかを入力条件ごとに確かめます
OUTPUT計算結果の検証記録
STEP 02 統合テスト連携の不整合を本番稼働の前に切り分けます
どう確かめるか

統合テストで在庫と会計・請求の連携を異常系まで確認

部品の在庫引き当てと会計・請求システムへの連携を、正常系だけでなく異常系まで確認します。連携が失敗した際の再送、二重計上の防止、CSVの項目欠落時の扱いを確かめます。

  • 01在庫引き当ての結果が基幹の在庫システム側と一致するかを突き合わせます
  • 02会計・請求システムへの連携データを、APIまたはCSVの項目単位で照合します
  • 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にご相談ください

どこまで確かめれば足りるかを、発注側の第三者の視点で整理します。検証範囲の線引きと優先順位を、稟議資料の判断材料として使える形でお示しします。既存の体制に合わせて入ります。