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

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

予知保全ソフトウェアの判定は、実行して初めて合否が決まる側面があります。実行前のレビューで、要件と設計の記述が検証可能な形かを照合します。判定ロジックの合否基準を後工程へ持ち越さないための観点です。

照合しないまま実装が進むと、設備ごとの正常の範囲が判定ロジックに反映されず、特定の設備で誤検知と見逃しが繰り返されます。リリース後に保全員からの不信として表面化します。

判定区分の定義を、設備ごとの正常状態の定義と照合する

判定区分(正常・注意・異常など)の定義が、設備ごとの正常状態の定義と一致しているかを照合します。設備によって正常の範囲が異なるため、共通の区分だけで定義すると、誤検知と見逃しが起きます。

確認する資料
  • 要件定義書
  • 正常状態定義書
  • 判定基準書
境界値の項目がないままだと、運用中にしきい値を変更した際の判定の変化を誰も確かめられず、調整のたびに不具合か設定の問題かの切り分けが現場とベンダーの間で往復します。

しきい値と学習対象期間の設定仕様を、境界値のテスト項目書と照合する

しきい値と学習対象期間の設定仕様を、境界値をまたぐ入力で判定がどう変わるかを項目化したテスト項目書と照合します。上限・下限・境界ちょうどの値が抜けると、設定変更で意図しない判定が出ます。

確認する資料
  • 設定仕様書
  • テスト項目書
  • 設定値一覧
通知条件と通知先の不整合を見逃すと、アラートが担当者へ届かないまま設備が停止し、原因調査では通知の到達記録がないため心証だけの報告になります。

通知条件の仕様を、判定区分と通知先の一覧と照合する

通知条件の仕様が、判定区分ごとの通知先の一覧と矛盾していないかを照合します。「注意」判定の通知先が一覧にない、担当の変更が反映されないといった不整合があると、アラートが届かず点検が遅れます。

確認する資料
  • 通知条件仕様書
  • 通知先一覧
  • 判定区分表
連携の定義を照合しないと、作業指示や部品在庫へのデータの欠落が受け入れテストの直前まで見つからず、リリース判断の材料が作れず審査で差し戻されます。

連携インターフェースの定義を、保全管理システムのDB設計書と照合する

判定結果から保全管理システムへ渡る項目の定義を、作業指示・部品在庫・保全履歴の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の検証

予知保全ソフトウェアは、センサー、エッジコントローラ、分析ソフトウェア、基幹システム連携で成り立ちます。GENZは発注側・ベンダーに属さない立場で、構造全体から検証範囲を設計し、実施から報告までを担います。

SVC 01

構造から導くテスト設計

センサーからの収集、判定ロジック、基幹システムへの連携という構造からテスト観点を導き、境界値と異常系の設計に落とします。

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

工程ごとに検証範囲を定める

ユニットテスト・統合テスト・システムテスト・受け入れテストの工程ごとに、どこまでを外注範囲とするかを成果物の単位で定めます。

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

既存体制を変えずに検証工程を組み込みます

ベンダーが実装を進める案件でも、発注側のQA配置を組み替えずに、受け入れ側の判断材料を作る工程として組み込めます。

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

審査に出せる不具合票と報告書を残します

テストの実施記録を不具合票と報告書の形で納品し、独立品質管理部門の審査やシステム監査へそのまま提出できる状態で残します。

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

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

ご相談から納品までの流れをご説明します。初回のご相談では、検証範囲のたたき台づくりからご一緒します。

設備構成と連携範囲のヒアリング

設備構成と連携箇所、判定の設定範囲をうかがい、検証の対象を特定します。

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

工程と成果物の単位へ分解したテスト設計と見積もりをご提示します。

テストの実施と結果の随時共有

テストを実施し、判定の挙動と通知の到達を随時共有し、不具合票を起票します。

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

合否の根拠を整理した報告書を納品し、修正後の回帰テストの結果も残します。

無料相談・見積もり受付中

予知保全ソフトウェアの検証範囲と優先順位をGENZにご相談ください

判定機能と連携部分の検証範囲を、ユニットテストから受け入れテストまでの工程単位で整理し、優先順位と必要工数の考え方をお示しします。回帰テストの要否もあわせてご確認いただけます。