GENZ, Inc.

第三者の検証チーム BOM管理ツール更改の部品表不整合を第三者が稼働前に検証

ベンダーのテストと自社の受け入れテストの境界が定まらないまま稼働日が近づく案件で、構築側とは別の立場で検証工程を担い、会議体へ提出できる記録を残します。

支援事例

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

BOM管理ツール更改で見落とす部品表の盲点

BOM管理ツールの更改では、機能の比較までは進む一方で、自社の部品番号体系と員数の持ち方で期待どおりに動くかという確認が、選定から受け入れまでの各場面で抜け落ちます。この節ではその穴を整理します。

設計部品表から製造部品表への変換結果の照合

設計部品表から製造部品表への変換結果を現行の出力と突き合わせる手順と要員がなく、正しさを確認しないまま移行判定に進む案件があります。

変換の照合

移行した部品構成の階層と員数の全件確認

移行した部品構成の階層と員数は全件で確認したい対象ですが、件数が多く現場の目視と抜き取りに留まり、階層の不整合が稼働後まで検知されません。

階層と員数

設計変更の承認経路と権限設定の確認

設計変更の起票から承認までの経路を設定どおりに流す確認は、設計部門の繁忙期に試験用の起票を依頼しにくく、権限設定の誤りが切替後に表面化します。

承認経路

基幹システムと生産管理システムへ渡すデータの突合

基幹システムと生産管理システムへ渡す連携ファイルの内容を現行の結果と突き合わせる手順がなく、員数の不整合が所要量計算の入力へ入ります。

連携の突合

管理方式の変更に伴う運用手順の確認

サマリ型からストラクチャ型へ管理方式を変更する更改では、運用手順のどこをどこまで再確認するかの基準がなく、確認範囲が担当者ごとに変わります。

運用の再確認
02 RISK

確認が足りないまま稼働させた場合に業務へ現れる影響

確認が足りないまま稼働すると、部品構成の不整合が欠品・過剰在庫や原価差異として表面化し、手配の停滞から期末の確認作業まで波及します。

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

テストの外注を検討する前に整理しておく確認事項

部品表管理ツールの更改で受け入れテストを外注する前に、社内で固めておく事項があります。更改の範囲、移行データの対応表、テスト分担、判定基準、立ち会い要員を整理すると、見積もりとテスト設計の精度が上がります。

据え置く範囲の線引きが曖昧なまま外注すると、委託したテストと社内の確認の間に抜けが生じ、更改の対象範囲の一部が誰にも確認されないまま稼働するおそれがあります。

更改の対象範囲と据え置く範囲の線引き

設定と移行の手が入る範囲と、据え置く範囲を一覧にします。サマリ型からストラクチャ型へ方式が変わる場合は運用手順も変更対象に含め、スコープ外の機能を明記して認識の差を防ぎます。

確認する資料
  • 対象範囲一覧
  • 据え置き機能表
  • 変更管理簿
移行元と移行先の対応表がない場合、移行後の件数と階層の一致確認はベンダーの作業報告への依存に留まります。発注側が独自に突合する手順がなく、部品構成の不整合を検知できないおそれがあります。

部品構成データの移行元と移行先の対応表の有無

現行の部品構成データと新ツールの階層構造の対応表があるかを確認します。移行後の件数と階層の一致を発注側で突合できるよう、部品番号と員数の持ち方を移行前に記録しておきます。

確認する資料
  • 移行対応表
  • 部品番号規則
  • 員数定義書
テストの分担が契約の文面だけで定まらないまま着手すると、設計部品表から製造部品表への変換確認のような業務シナリオの検証が両者の範囲外に落ち、境界の確認が抜けたまま受け入れ判定へ進むおそれがあります。

ベンダーが実施するテストと自社が担うテストの分担

ベンダーの契約範囲はユニットテストと統合テストまでで、業務シナリオの確認は発注側の作業として線が引かれる場合があります。製造部品表への変換確認など、自社が担う範囲を契約文書で確かめます。

確認する資料
  • 契約範囲書
  • テスト分担表
  • 検収条件書
判定基準と証跡の保管方法が未定の場合、差異が出た際に移行データの誤りか設定の誤りか運用手順の未徹底かの切り分けができず、復旧と原因調査が同時に走り、確認の記録が残らないおそれがあります。

受け入れ判定の基準と証跡の保管方法

変換結果、員数、基幹システムへの連携ファイルを現行と突き合わせる判定基準と、証跡の様式と保管方法を決めます。差異が出た場合に誰が原因を調べるかも、判定に進む前に取り決めておきます。

確認する資料
  • 判定基準書
  • 証跡様式
  • 保管手順書
立ち会い要員を確保できない場合、テスト設計の工数が不足し、確認が現場の目視と抜き取りに留まります。員数と階層の全件確認ができず、数量差異が稼働直後の手配と棚卸しで表面化するおそれがあります。

設計部門と生産管理部門の立ち会い要員の確保

設計部門と生産管理部門の確認要員を、繁忙期を考慮して確保します。兼務配置の場合はテスト設計の工数が不足し、確認が目視と抜き取りに留まるため、立ち会いの日程と工数を事前に調整します。

確認する資料
  • 要員計画表
  • 日程調整表
  • 工数見積もり書
  • 立ち会い記録
04 TEST DESIGN

GENZが担うBOM管理ツール検証の範囲と進め方

GENZは、部品表データの移行から受け入れ、連携、証跡までを第三者として検証します。

STEP 01 現行の部品表運用と更改範囲の聞き取り運用実態と更改範囲を整理します
どう確かめるか

部品構成データの移行検証

現行の部品構成データと移行後のデータを突合し、件数と階層、員数の一致を検証します。ベンダーの作業報告に依存せず、発注側の材料として差異の有無を判定材料にまとめます。

  • 01現行の部品表の運用と管理方式を聞き取ります。
  • 02更改の対象範囲と据え置く範囲を整理します。
  • 03移行対象の件数と階層の深さを確認します。
OUTPUT移行データの検証
STEP 02 テスト計画とテスト設計の作成範囲と優先順位を計画に落とします
どう確かめるか

設計変更ワークフローの受け入れテスト

設計変更の起票から承認までの経路について、想定される業務シナリオで動作を検証します。承認段数と権限の設定が運用どおりに働くかを確かめます。

  • 01検証範囲と優先順位を定めた計画を作成します。
  • 02業務シナリオに基づくテスト設計を行います。
  • 03判定基準と証跡の様式を取り決めます。
OUTPUTワークフローの受入検証
STEP 03 テスト実行と不具合の収束管理不具合の切り分けと収束を管理します
どう確かめるか

周辺システムとの連携テスト

CADやPLM、基幹システムとの受け渡しを検証します。連携ファイルの内容と所要量計算の入力となる員数が現行の結果と一致するかを突き合わせます。

  • 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

お問い合わせから検証開始までの流れ

お問い合わせから検証開始まで、範囲の確認と計画の合意を経て進みます。全体の流れは次のとおりです。

お問い合わせと更改概要の確認

更改の対象範囲、稼働予定日、現在の進行状況を確認します。

検証範囲の確認とお見積もりの提示

移行データの件数や連携先を踏まえ、検証範囲と費用のお見積もりを提示します。

ご契約とテスト計画の合意

ご契約後、検証の対象・判定基準・期間を定めたテスト計画を合意します。

テスト設計と検証の開始

業務シナリオに基づくテスト設計を行い、計画に沿って検証を開始します。

部品表更改の受け入れテスト相談

BOM管理ツールの検証範囲について、現状の整理からご相談ください

テスト範囲の整理、優先順位、必要工数の考え方、連携テストの要否まで、第三者の視点で検証を担うGENZがお答えします。稼働日までの残り期間から逆算した進め方もご提案できます。