通信の届かない場所で入力した点検記録が同期後に残らない
電波の届かないピットや地下の設備で入力した点検記録が、復帰後の同期で消えると、実施の証跡が残らない。操作試験だけではこの条件が抜ける。
GENZ, Inc.
製造業の保全DXに
設備保全アプリの
製造業の保全DXに
設備保全アプリの受け入れを、第三者のテストで確かめる
設備保全アプリの稼働可否を会議体へ上程する際、確認の十分性が問われます。GENZは第三者として、確認した範囲と残存リスクを分けた結果をお渡しします。
支援事例
支援実績5,000件以上
設備保全アプリで見落とされやすい不具合
設備保全アプリの受け入れでは、限られた現場動員の時間で操作確認だけを済ませ、通信条件・権限・移行データの整合が見送られやすい。見送った範囲は稼働直後に表面化し、不具合か運用誤りかを切り分ける材料が残らない。
通信の
設備台帳の階層を変えたあとに保全履歴が紐づかない
設備コードを付け替えて移行すると、件数は一致しても過去の保全履歴が別の設備へ紐づく。突き合わせ方法が決まらないまま稼働に進むと判明が遅れる。
保全計画の生成日が工場の稼働カレンダーとずれる
保全計画の生成が稼働カレンダーや休日設定とずれると、点検予定が非稼働日に立ち、作業指示の連鎖が崩れる。仕様書のレビューではこのずれが見えない。
写真や測定値が欠けたまま作業指示が発行される
写真や測定値が欠けたまま作業指示が発行されると、現場は判断材料なしに作業へ向かう。必須項目の制御を現場端末の実機で確かめていないと起きる。
予備品の引き当てと完了記録が二重に計上される
予備品の引き当てと完了記録が二重に計上されると、在庫数が実物とずれ、手配の遅れで設備の停止が延びる。在庫連携は開発側の範囲から漏れやすい。
見落とした不具合が現場と経営に及ぼす影響
受け入れテストで見送った確認は、稼働後に記録の欠落や計画の不整合として出ます。現場の切り分けに留まらず、証跡と投資判断の前提にまで広がります。
受け入れ前に見直したいテストの観点
受け入れテストは現場の協力時間の制約から操作確認で終わりがちです。しかし設備保全アプリでは、端末・通信・移行データ・権限のように操作の見た目では確かめられない観点が稼働後の不具合の出どころになります。
この確認を外すと、通信の届かない場所で入力した点検記録が同期されずに欠落し、法定点検の実施証跡として使えない状態のまま稼働してしまうおそれがあります。
現場の端末と工場内の通信環境を含めた実機での確認
開発ベンダーのテストは開発環境で行われるのが通例で、現場の端末機種や工場内の通信状況は対象に入らないことがあります。通信が届かない場所で記録を保持し、復帰時に同期されるかを実機で検証します。
確認する資料
- 端末一覧
- 通信環境図
- 点検経路表
この確認を外すと、保全履歴が誤った設備へ紐づいたまま蓄積され、故障傾向の分析や予防保全の判断材料が成立しなくなるおそれがあります。
既存の設備台帳と保全履歴の移行データの紐付け確認
既存の設備台帳と保全履歴の移行は、件数の一致だけでは足りません。階層構造の再編や設備コードの付け替えを伴う場合、移行後に過去の履歴が正しい設備へ紐づくかを個別に突き合わせます。
確認する資料
- 移行仕様書
- 台帳対応表
- 移行件数表
この確認を外すと、保全計画の生成漏れや作業指示の重複に気づかず、点検の抜けや部品手配の遅れを通じて設備停止時間が伸びるおそれがあります。
点検周期から計画と作業指示が生成される流れの確認
点検様式と点検周期の設定から保全計画が生成され、作業指示へ連鎖する流れは、設定の解釈がずれると計画全体に波及します。周期の起点・休日の扱い・繰り越しまで設定どおりかを検証します。
確認する資料
- 点検周期表
- 計画生成仕様
- 作業指示様式
この確認を外すと、予備品の在庫数や保全費の金額が基幹システム側と合わず、棚卸や月次決算のたびに手作業の突き合わせが残るおそれがあります。
基幹システムへ渡すデータ項目と数量の突き合わせ
基幹システムへ連携する構成では、予備品の引き当てや保全費の計上が連携先のデータと食い違わないかを突き合わせます。仕様の確認だけでは自社の設備コード体系に照らした不整合が見つかりません。
確認する資料
- 連携仕様書
- コード対応表
- 帳票突合表
この確認を外すと、外部の作業者が意図しない範囲の台帳や履歴を閲覧・更新できる状態が残り、誤操作と情報の持ち出しの両方をあとから追えなくなるおそれがあります。
権限の境界と外部の保守協力会社の操作範囲の確認
作業者・職長・管理者で権限が異なり、保守協力会社へ外部アカウントを付与する運用では境界が増えます。権限を超えた操作ができないこと、外部の作業者が他設備の履歴へ触れられないことを確認します。
確認する資料
- 権限設計書
- アカウント一覧
- 外部委託契約
- 操作権限表
テスト外注でGENZが担う四つの範囲
外注した側は、確認した範囲と残ったリスクを文書で受け取れる状態になります。GENZが担う範囲は、計画から証跡の整理までの四つです。
STEP 01
対象範囲と前提条件をそろえる対象機能・データ・端末・環境の四つを指定します
どう確かめるか
対象範囲を合意するテスト計画と完了基準の設計
設備台帳・点検記録・保全計画・作業指示のうち、どの機能をどの端末と環境で確認するかを合意し、完了基準を定めます。スコープがここで決まるため、見積の前提条件としても使えます。
- 01確認の対象とする機能と点検業務のシナリオの棚卸し
- 02対象とする端末の機種と工場内の通信条件のすり合わせ
- 03完了基準と合格判定の考え方を含む前提条件の取り決め
OUTPUT観点表とテストケース
STEP 02
観点表とテストケースをつくる保全業務の流れに沿って観点を組みます
どう確かめるか
設備保全の業務の流れに沿ったテスト観点の設計
日常点検の記録から異常報告、作業指示、部品交換まで、保全業務の流れに沿って観点を組みます。通信が届かない場所での記録保持や権限違いの操作など、操作確認では抜けやすい観点を含めます。
- 01点検記録から異常報告と作業指示までの業務シナリオ作成
- 02権限違いの操作と通信が届かない条件を扱う観点の追加
- 03観点表から実施手順と期待結果を伴うテストケースへの展開
OUTPUTテスト実施の記録
STEP 03
テストを実施して不具合を起票する発生条件を添えて全件の証跡を残します
どう確かめるか
現場の端末と実際の通信条件に近い環境での実施
現場で使うモバイル端末と管理画面の両方を用意し、実際の通信条件に近い環境で検証します。開発環境だけの確認では現れない、端末とネットワークに依存する不具合を意図的に発生させて検証します。
- 01現場で使う端末での点検記録の入力と同期の動作検証
- 02通信が届かない場所での記録保持と復帰時の同期の確認
- 03発生した不具合について発生条件と再現手順を添えた起票
OUTPUT不具合の一覧と起票
STEP 04
確認した範囲と残ったリスクを報告する稼働の判断に使える粒度で報告します
どう確かめるか
発生した不具合の管理と切り分けに使う証跡の整理
発生した不具合は発生条件と手順を添えて起票し、修正の有無に関わらず全件の証跡を残します。稼働開始のあとに不具合か運用誤りかを切り分ける際の判断材料として使える形式で整理します。
- 01確認済みの機能・データ・端末・環境の範囲の一覧化
- 02修正せずに残る不具合と稼働後の運用での回避策の整理
- 03稼働可否の判断を会議体へ上程するための報告書の作成
OUTPUT確認範囲と残リスクの報告書
社内で実施する場合と外部に任せる場合の分かれ目
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 実機と通信条件の確認を現場の協力時間に依存しない
- 移行データの紐付けを体系的に確認する手順が得られる
- ベンダーのテスト範囲の過不足を指摘できる評価軸を持てる
- 確認済みの範囲と残存リスクを会議体へ説明できる
対応できるテストの形態と対象範囲
社内実施と外部委託の境目は、人手の有無だけではありません。GENZは受け入れ、移行、更新、内製からの切り替えを第三者として検証し、確認した範囲と残した範囲を会議体へ示せる形で渡します。
設備保全アプリの受け入れテスト
現場端末と通信条件、設備台帳の階層、権限境界を含めて稼働前に検証し、確認済みの範囲と残存リスクを分けて報告します。
既存システムからの移行に伴うデータ確認
既存の設備台帳と保全履歴を移したあと、紐付けと点検周期の生成が保たれているかを確認し、不整合を画面で追える記録にします。
機能追加や定期更新のあとの回帰テスト
機能追加や定期更新の適用後に、異常報告から作業指示への連鎖と予備品の引き当てが崩れていないかを検証します。
内製アプリから専用システムへの移行テスト
内製で不足しがちな観点を洗い出し、専用システムへの移行後に台帳と履歴が日常の保全業務で使える状態かを確認します。
ご相談から報告までの流れ
設備保全システムの受け入れ検証は、ご相談から報告まで四つの段階で進めます。各段階の内容を示します。
検証の対象と開始の予定をうかがう
開発の進捗と更改の予定、現場端末での確認範囲を伺います。
テスト範囲とお見積をお示しする
設備台帳や権限設計を踏まえ、工数の考え方とお見積をお示しします。
ご契約のうえテスト設計に着手する
成果物の定義を契約に明記し、点検経路や権限境界に沿った設計に着手します。
実施結果をご報告し次の改修につなぐ
確認済みの範囲と残る不具合を報告書にまとめ、稼働判断にご活用いただけます。
受け入れと改修工程の第三者検証
設備保全アプリのテスト範囲からご相談ください
どこまで確認し、どこを残すかの線引きは、着手前のご相談で決まります。GENZがテスト範囲の整理と優先順位、必要工数の考え方を示し、稟議に使える形でお渡しします。