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

個別受注生産システムでよくある不具合

個別受注生産システムの不具合は、製番に紐づく仕様・手配・原価の連携部分で起きやすく、頻度の低い操作で初めて表面化します。リリース判断の材料として押さえたい代表的な不具合を挙げます。

設計変更が手配済みの部品の発注数量へ反映されない

設計変更通知が発注データへ反映されないと、旧仕様の数量のまま部品が届き、手直しと在庫調整の工数が発生します。

設計変更の未反映

特急オーダーの割り込みで他案件の納期回答が再計算されない

割り込みで工程が詰まっても既存案件の納期が再計算されないと、回答済みの納期と実績が不整合のまま出荷計画が進みます。

納期の未再計算

製番別の間接費の計算順序が設計と異なり実績原価に差異が発生する

間接費の配賦が設計どおりの順序で行なわれないと、製番別の実績原価に差異が出て、見積もりとの対比も次の受注判断にも使えません。

原価計算の差異

見積もりから受注への転記で改訂前の仕様と単価が残存する

転記時に改訂前の単価が残ると、受注データと請求金額が一致せず、売上計上と債権管理の帳票で不整合が判明します。

改訂前データの残存

繰返生産と個別受注生産で在庫の引当数量が二重に計上される

同一品目を両方式で共有する運用で引当が二重に計上されると、引当可能数量が不足表示になり、手配指示が出せなくなります。

在庫の二重計上
02 RISK

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

検証の範囲が絞れずに残った不具合は、リリース後の業務で表面化します。個別受注生産の生産管理システムでは、納期・採算・監査対応へ問題が現れます。

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

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

個別受注生産システムのテストは、画面を操作する前の設計書の段階で不具合の芽を摘めます。製番・手配・納期・原価の仕様が複数の資料に分かれて書かれているため、資料同士を照合するレビューの観点を整理しました。

製番の採番規則を確かめないまま開発が進むと、受け入れテストの直前になって受注と製番の紐づけが成立しないことが判明し、発注仕様の手戻りとしてスケジュール全体が延びます。

製番の採番規則を受注仕様書とDB設計書で照合する

製番の採番規則は、受注仕様書に書かれた管理単位とDB設計書のキー定義が一致しているかを照合します。不整合を見落とすと、受け入れテストで製番の発行が仕様どおりに動かないことに気づけません。

確認する資料
  • 受注仕様書
  • DB設計書
  • 製番管理仕様書
設計変更の反映範囲が定義されないままリリースされると、変更後の部品表と手配データの間に不整合が残り、製造現場で誤った部品の手配が続くおそれがあります。

設計変更の反映範囲を部品表の定義と手配ロジック仕様で照合する

設計変更は、変更通知が部品表のどの構成レベルまで反映されるかを、部品表の定義と手配ロジックの仕様で照合します。反映範囲の定義がないと、手配済みの部品に変更が及ばず、やり直しが発生します。

確認する資料
  • 部品表の定義
  • 手配ロジック仕様
  • 設計変更手順書
納期計算の計算順序が要件と異なるまま運用に入ると、発注元へ回答した納期と実際の工程が合わず、納入遅延と再見積もりが発生して受注の継続に影響します。

納期計算の計算順序を生産計画の要件とAPI定義で照合する

納期計算は、生産計画の要件に沿った計算順序になっているかをAPI定義と照合します。工程の読み込み順や休日の扱いが要件と異なると、現場の実態と合わない日付を納期として回答します。

確認する資料
  • 生産計画の要件
  • API定義
  • 納期計算仕様書
原価の配賦基準と計算順序の相違を見落とすと、製番別の実績原価が誤って集計され、見積もりとの差異を次の受注判断へ反映できず、採算の悪い仕様の受注が繰り返されます。

原価の配賦基準と計算順序を原価要素の定義と仕訳一覧で照合する

原価は、配賦基準と計算順序が原価要素の定義と一致しているかを仕訳一覧と照合します。配賦の順序が設計と異なると製番別の実績原価が誤って集計され、月次締めの後になってから差異が判明します。

確認する資料
  • 原価要素の定義
  • 配賦ルール定義
  • 仕訳一覧
承認フローと権限の不整合を放置すると、規程で定めた承認を経ない手配や登録が可能な状態が残り、システム監査で内部統制上の指摘を受ける原因になります。

承認フローと権限の設定を業務規程と画面遷移設計書で照合する

承認フローと権限は、業務規程で定めた承認の段取りと画面遷移設計書の権限設定が一致しているかを照合します。規程にない操作が画面で許可されていると、承認を経ずに手配が進みます。

確認する資料
  • 業務規程
  • 画面遷移設計書
  • 権限設定一覧
  • 承認フロー定義
04 TEST DESIGN

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

動的テストでは、計算の正しさとモジュール間の連携、運用手順との整合を確かめます。その結果がリリース判断の材料になります。

STEP 01 ユニットテスト計算部品ごとに境界値と同値分割で確かめる
どう確かめるか

納期と原価の計算部品を境界値と同値分割で確かめる

納期回答と製番別原価は、個別受注生産システムの計算部品の中核です。GENZは配賦率や工程日数へ境界値と同値分割を適用し、端数や基準日またぎで誤計上されないことを検証します。

  • 01配賦率・日数の境界値と同値分割を設定する
  • 02端数処理と基準日またぎの期待値を定義する
  • 03計算順序どおりの結果になるか検証する
OUTPUTテスト項目書と期待値一覧
STEP 02 統合テストモジュール間の連携をデータの受け渡しで確かめる
どう確かめるか

受注・設計・手配・原価のモジュール間の連携をデータの受け渡しで確かめる

受注登録から部品表、手配、原価集計へとデータが渡る箇所は、単独の画面確認では検出できません。GENZは入力データと受け側の計上結果を突き合わせ、欠落や二重計上がないことを確認します。

  • 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の支援

製番管理の構造を前提に、第三者の視点でテスト設計から実行・報告までを担います。製番の発行や原価配賦の仕組みを一からご説明いただく手間を減らし、個別仕様のどこを検証対象とするかの線引きからご提示します。

SVC 01

受注仕様からテスト設計を起こす

設計変更や特急オーダーの割り込みを踏まえ、個別仕様のどの部分を検証対象とすべきかを製番単位で線引きし、テスト設計へ反映します。

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

見積もりから原価確定までを検証範囲に含める

見積もりから受注・設計・手配・進捗・売上・原価確定まで、どの業務工程を検証範囲に含めるかを工程名で示してご確認いただけます。

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

既存のテスト標準と不具合票に合わせる

既存のテスト標準と不具合票の様式へ合わせて進めます。独立品質管理部門がある体制でもPM兼務の体制でも、現在の運用のまま組み込めます。

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

判断と監査に使える形で報告

テスト項目書・不具合票・報告書を、リリース判断会議とシステム監査でそのまま使える構成で提出します。次の改修でも再利用できます。

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

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

個別受注生産システムの検証は、現状の確認から修正後の再確認までの段階に分けて進めます。

現状の検証範囲と課題のヒアリング

現在の検証範囲と進行上の課題を伺い、個別仕様の作り込み箇所を洗い出します。

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

洗い出した範囲でテスト項目の案を作成し、工数と費用の見積もりを提示します。

テストの実施と進捗・不具合票の共有

テストを実施し、進捗と不具合票を共有します。不具合か仕様かも切り分けます。

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

結果を報告書にまとめて納品し、修正箇所は回帰テストで再度確認します。

個別受注生産システムの検証をご検討中の企業様へ

検証の範囲と優先順位をGENZへご相談ください

見積もりから原価までのどこを検証範囲に入れるかを、GENZへご相談いただけます。現行の業務フローをもとにテスト範囲と優先順位を整理し、必要工数の考え方までご提示します。