GENZ, Inc.

監視制御システムの検証 SCADAソフトの更改と改修を、作った側とは別の目で検証する

更改の試運転と切替判断の材料づくりを担うご担当者様へ。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

引き渡し前に第三者として確かめる観点

切替の判断材料をそろえるには、構築ベンダーとは別の視点で、何をどこまで確かめるかを言語化しておく必要があります。引き渡し前に第三者として確かめる観点と、確認を省いた場合に起こり得る状態を整理します。

確かめなければ、表示の値と実際の計測値がずれたまま切り替わり、日報や帳票の値の食い違いとして切替直後に現れます。

表示項目と収集点の対応、換算と単位がそろっているか

監視画面の表示項目が、どの収集点の値を映しているかを対応表で確かめます。換算式や単位のずれは画面の作り込み側に潜み、現行系との突き合わせで見つかります。切替前に潰せば直後の切り分けが減ります。

確認する資料
  • 入出力対応表
  • 換算定義書
  • 単位一覧表
確かめなければ、警報が発報しない、あるいは復帰しない条件が残ったまま切り替わり、運転判断の遅れにつながるおそれがあります。

警報のしきい値と発報・復帰の動きが設計と合っているか

警報のしきい値が設計どおりに設定されているか、発報と復帰の動きが仕様どおりかを確かめます。同時多発の条件は本番設備では発生させられないため、模擬信号で確かめる枠を別に取ります。

確認する資料
  • 警報設計書
  • しきい値一覧
  • 発報試験記録
確かめなければ、欠測のある記録が要件を満たさない状態で切り替わり、あとから遡って原因を照合する工数が発生します。

記録の採取周期と欠測時の扱いが取り決めどおりか

記録の採取周期と欠測時の扱いが、取り決めどおりに動くかを確かめます。保存期間の要件は案件ごとに異なるため、要件定義書との照合が起点になります。帳票の値と記録データの突き合わせも含めます。

確認する資料
  • 記録要件書
  • 採取周期表
  • 帳票照合表
確かめなければ、待機系への切り替えが初めて本番で試されることになり、切替判断の根拠が印象に寄ってしまいます。

待機系への切り替えが想定した時間内に収まり、記録が途切れないか

通信の途絶や待機系への切り替えを発生させて、切り替えが想定した時間内に収まり、記録が途切れないかを検証します。検証環境の有無と用意の担い手は、範囲合意の段階で決めておきます。

確認する資料
  • 冗長構成図
  • 切替試験記録
  • 通信断試験表
確かめなければ、事象調査の際に操作の経緯を記録で示せず、切替前後の責任が同じ会議で混ざる状態が続きます。

操作の記録が権限の区分ごとに必要な粒度で残るか

誰がいつどの操作をしたかの記録が、権限の区分ごとに必要な粒度で残るかを確かめます。操作履歴は切替後の調査で経緯を並べる際のよりどころになり、欠けると原因の切り分けが記憶の比較に戻ります。

確認する資料
  • 権限設計書
  • 操作記録様式
  • 保存期間定義
  • ログ確認手順
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

テストを担う体制と発注側との役割の分担

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

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

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

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

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

専門ノウハウを即戦力で

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

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

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

  • 作った側とは別の目で試験項目と証跡を点検します
  • 停止時間に収まる検証範囲と打ち切り点を整理します
  • 稟議で示せる範囲と費用の対応を明確にします
  • 次の更改へ引き継げる検証記録を文書で残します
06 SERVICE

更改の場面に合わせて選べる支援の形

確かめる範囲の切り分けは、案件の規模と進行によって分かれます。GENZは開発の途中から伴走してテストを進める形と、大規模な監視システムを網羅する形を持ち、作る側とは別の主体として結果を記録に残します。

SVC 01

開発に伴走してテストを進める

構築の進行に合わせ、仕様が固まった部分から順にテスト項目を組み、本番設備を止めずに条件を発生させて検証します。

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

大きな監視システムを網羅して確かめる

対象機能・対象環境・対象期間の三点で範囲を切り、大規模な監視システムでもどこまでを対象とし、どこを対象外とするかを先に示して検証します。

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

受け入れ判断の材料を第三者としてそろえる

作る側から受け入れ判断までの材料を、第三者の視点でそろえ、稟議で範囲と費用の対応を説明できる形でご提示します。

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

監査や報告で示す記録をまとめて残す

検証した範囲と結果を証跡として整理して残し、次の更改や監査の場でそのまま示せる記録としてお渡しします。

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

問合せから報告と引き継ぎまでの流れ

問合せから報告、次の更改への引き継ぎまで、確かめた範囲を記録として残す流れでご支援します。

問合せの受付と現行構成の共有

初回相談で課題を整理し、費用と進め方を明確にご提示します。

確かめる範囲と概算見積の提示

更改の計画と停止可能な時間を伺い、確かめる範囲と概算費用をお示しします。

検証計画の合意とテストの実施

テスト計画と項目表に合意いただいたのち検証を実行し、進み具合を共有します。

結果の報告と次の更改への引き継ぎ

検証の範囲と残課題をまとめ、次の更改や監査で示せる記録としてお渡しします。

構築ベンダーとは別の目で確かめる

SCADAソフトの検証範囲を、現行の構成を見るところから相談する

現行構成の棚卸しから入り、テスト範囲の切り分けと優先順位、必要工数の見立て、受け入れ判断の材料として使える形で整理してお返しします。計画段階でも切替直前でもご相談ください。