GENZ, Inc.

SCMソフトウェア SCMソフトウェアのテストを第三者の目で代行

SCMソフトウェアの改修では、どこまでテストすれば十分かを自社だけで示しにくくなります。実装側とは別の目で範囲を設計し、稟議や監査に使える記録を残します。

支援事例

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

SCMテストでつまずきやすい点

SCMソフトウェアの更改や大規模改修では、テストの手順そのものより、確認する範囲の決定と記録の形式でつまずく場面が多くあります。ここでは、在庫・出荷・請求を扱う現場で実際に起きる詰まりを整理します。

在庫と出荷の数字が合わず、どの工程で生じた差異か切り分けられない

出荷・在庫・請求の数値に差異が出ても、事前のテスト記録が残っていないと、想定内の挙動か不具合かを判断できず、切り分けに時間を要します。

差異の切り分け

業務部門の受け入れテストが、通常業務と並行のまま期日を迎える

受け入れテストは業務部門が通常業務と並行で進めるため消化件数が伸びず、未消化の項目を残したままリリース判断の期日を迎えてしまいます。

受け入れの遅延

基幹システムや倉庫管理システムとの境界が、担当の空白地帯になる

基幹システムや倉庫管理システム、企業間データ連携との境界部分は、どちらの担当でテストするか決める場がなく、空白地帯として残ります。

連携境界の空白

定期アップデートのたびに、回帰テストの範囲を一から決め直している

定期アップデートのたびに回帰テストの範囲を都度の判断で決める運用では、前回との差分を説明できず、確認済みの範囲が蓄積しません。

回帰範囲の都度判断

テスト結果の記録が担当者ごとに異なり、説明資料を作り直している

テスト結果の記録形式が担当者ごとに異なると、運営会議や投資判断の会議へ上程するたびに説明資料を一から作成する工数が発生します。

記録形式のばらつき
02 RISK

確認が足りないまま本番を迎えたときに起こること

テストケースの不足や責任分界の未決着のままリリースを迎えると、確認の抜けが出荷・請求・締め処理の形で表面化します。

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

SCMソフトのテスト外注を判断する材料

テスト外注の可否は、費用の大小ではなく「何をどこまで確認できるか」を示せるかどうかで決まります。SCMソフトウェアの業務範囲と接続範囲を整理し、判断の材料となる根拠を先に作ります。

この整理をしないままだと、見積の根拠が勘に依存し、上程時に費用の妥当性を説明できないおそれがあります。

業務の流れに沿って、確認する範囲を先に決める

調達・生産・在庫・物流・販売の業務フローを単位に、確認する条件を洗い出します。月次・年次の締め処理もテスト対象のシナリオに含め、工数見積の根拠を過去の勘ではなく範囲の定義から作ります。

確認する資料
  • テスト計画書
  • 業務フロー図
  • 範囲定義書
この整理をしないままだと、境界部分が空白のまま残り、連携先との不整合が本番稼働後に見つかるおそれがあります。

取引先や社内システムとの境界を、確認の単位として定義する

基幹システム・倉庫管理・企業間データ連携との接続点を一覧化し、どちら側が何を確認するかを文書で定めます。担当の空白地帯として残りがちな境界部分を、漏れのない確認の単位に置き換えます。

確認する資料
  • 接続一覧表
  • 責任分界表
  • 結合仕様書
この整理をしないままだと、実装側の報告の粒度で判断が止まり、自社として確認できた範囲を言語化できないまま期日を迎えるおそれがあります。

実装を担う側とは別の立場で、テストを設計し実行する

GENZは実装を担わない第三者の視点で、テストを設計し実行します。開発側の「単体・結合は完了」という報告とは別に、仕様との照合で得た結果を示し、受け入れ工程へ判断を持ち越さない状態にします。

確認する資料
  • テスト仕様書
  • 結果報告書
  • 不具合一覧
この整理をしないままだと、確認済みの記録が欠落し、定期アップデートのたびに回帰範囲を都度判断する運用が続くおそれがあります。

大規模な改修でも、どこまで確認したかの根拠を残す

更改や大規模改修では、スプリントに伴走してテストを実施し、確認済みの範囲を案件ごとに記録します。次の改修や定期アップデートで回帰範囲を決める際に、前回との差分を説明できる状態にします。

確認する資料
  • 回帰範囲表
  • 差分記録表
  • 実施記録
この整理をしないままだと、稼働後に数値差異が出た際、想定内の挙動か不具合かの切り分けに時間がかかるおそれがあります。

稟議や監査で参照できる形式に、記録をそろえる

テスト計画・実施結果・確認の証跡を、稟議や監査でそのまま参照できる形式にそろえます。テスト外注費の妥当性を上程のたびに一から説明する負担を、記録の側から減らします。

確認する資料
  • 証跡一式
  • 稟議資料
  • 監査証跡
  • 結果要約表
04 TEST DESIGN

ご提供するテスト支援の範囲と内容

SCMソフトウェアの更改・改修にあわせ、テストの計画から証跡の整備までを一貫してご提供します。

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

SCMソフトウェアのテスト支援の体制

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

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

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

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

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

専門ノウハウを即戦力で

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

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

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

  • 第三者の視点でテストを設計・実行し、リリース判断の根拠を作ります
  • 基幹・倉庫・企業間連携まで含む大規模システムのテストを網羅します
  • 改修スプリントに伴走し、期日までにテストケースを作成・実行します
  • 上程や監査で参照できる証跡の形式でテスト結果を記録に残します
06 SERVICE

SCMソフトウェアの周辺領域もあわせて支援します

SCMソフトウェアの改修の影響は、接続する基幹システムや倉庫管理、取引先とのデータ連携へ広がります。GENZでは、こうした周辺領域を含めた範囲でテストを設計し、実行します。

SVC 01

基幹システムとの連携部分のテスト

改修後の画面や帳票が会計・販売管理の処理と食い違わないか、入出庫から締め処理までの業務の流れに沿って検証します。

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

倉庫管理・物流システムとの動作確認

倉庫管理システムへの出荷指示や在庫の引当が正しく連携するかを確認し、出荷業務が止まらない状態にあることを確かめます。

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

取引先との企業間データ連携の確認

取引先や物流事業者とのデータの受け渡しは取り決めが接続先ごとに異なります。接続先の単位で送受信の結果を確認します。

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

稼働後の定期アップデートに伴う回帰テスト

クラウド型では提供側の更新のたびに既存機能へ影響が出るおそれがあります。更新ごとに検証し、記録を再利用できる形で残します。

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

お問合せから支援開始までの流れ

テスト範囲の区切りが固まっていなくても、ご相談の段階から整理を始められます。

テスト範囲についてのお問合せ

フォームまたは電話でご連絡ください。更改の日程が未定でもお受けします。

現状の課題と対象範囲のヒアリング

対象システムの構成と業務上の制約を伺い、確認の不足する範囲を特定します。

テスト計画のご提案とお見積の提示

テスト範囲と優先順位、必要工数の根拠を示した見積をお出しします。

ご契約とテスト設計・実行の開始

ご契約後、既存の開発チームと連携しながら、テスト設計と実行を開始します。

テスト範囲の現状整理のご相談

SCMソフトウェアのテスト体制について、まずは現状からご相談ください

現行のSCMソフトウェアの構成と改修計画を伺ったうえで、確認が必要なテスト範囲と優先順位、関連システムへの回帰テストの要否を整理してお返しします。社内説明にもご利用いただけます。