GENZ, Inc.

テスト外注のご相談 電子納品ソフトの改修を、第三者のテストで受け止める

版と分野の組み合わせで膨らむ検証を、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

テストを引き受ける前に確かめていること

検証を引き受ける前に、GENZが必ず確認する項目があります。対象となる要領の版からリリース判断の記録まで、次の観点で現状を整理したうえで、テスト範囲の見積に入ります。

対象版の取り違え

対象となる要領・基準の版と、検証を適用する範囲

電子納品のチェックシステムは旧版もダウンロード提供されており、複数の版が併存します。どの版までを検証対象に含めるかを先に固定しないと、版と分野の掛け算で範囲が膨らみ、見積が成立しません。

確認する資料
  • 対象版の一覧
  • 適用範囲の定義
  • 改定履歴の記録
分野間の確認漏れ

対応している分野と、出力する成果品の構成と種類

工事完成図書や測量成果など、対象業務ごとに異なる要領・基準が存在します。土木、建築、設備、測量のどの分野を対象とし、どの成果品を出力するかを確認し、分野ごとの点検内容の違いを洗い出します。

確認する資料
  • 対応分野の一覧
  • 成果品の構成表
  • 図面形式の一覧
回帰範囲の縮小

いま残っているテストケースと、過去の不具合の記録

既存のテストケースがどこに、どの版の基準で残っているかを確認します。過去の不具合記録と突き合わせることで、回帰テストで見るべき既存分野と、今回の改修で新たに見るべき範囲を分けられます。

確認する資料
  • 既存テストケース
  • 不具合対応の記録
  • 回帰範囲の一覧
受け入れ境界の曖昧化

開発をどう進めているかと、品質保証を担う人の配置

内製と委託のどちらがどの工程を担い、品質保証がどこに置かれているかを確認します。開発側の確認と受け入れ側の確認の境目が曖昧だと、どちらも確かめていない範囲があとから見つかるためです。

確認する資料
  • 開発体制の構成
  • 外注範囲の仕様
  • 検証担当の配置
判定根拠の散逸

リリースの可否を判断する場で求められる記録の形

出荷可否を諮る会議で、どの形の記録が求められるかを確認します。判定の根拠が担当者の記憶と手元の表計算に残る状態では説明が感触に頼るため、確認した範囲と残る懸念を示せる形を先に決めます。

確認する資料
  • 受け入れ判定基準
  • テスト結果の集約
  • 会議資料の様式
  • 残課題の一覧
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

検証をどこまで預けるかを、体制に合わせて選ぶ

検証をどう進めるかは、案件に合わせて選べます。開発と並行して進める形から、広い範囲をまとめて預ける形まで、要員と期日に合わせて組み合わせられます。

SVC 01

開発と並行してテストを進める

自社の開発工程と並行してテストを進めます。繁忙期の前に検証を終える体制として、要員不足を補いながらリリース計画に工程を合わせます。

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

版と分野の広い範囲をまとめて検証する

版と分野の組み合わせで膨らんだ検証範囲を、まとめて引き受けます。どの組み合わせをどの深さで確認するかを、テスト設計の段階で整理します。

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

第三者の視点で検証の工程を預かる

発注側でも開発側でもない立場で、設計から実行までの工程を預かります。開発委託先の確認をそのまま受け入れる形とは異なる判定が残ります。

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

検証の記録をあとから参照できる形で残す

テストケースと判定基準、結果の記録をあとから参照できる形で残します。出荷可否を諮る会議や、次回改修の切り分けにそのまま使えます。

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

お問合せからテスト開始までの流れ

改修の着手日から逆算した日程で進められるよう、ご相談から契約までの流れを順に整理しました。

お問合せと現在の改修状況のご連絡

改修の状況と対象の要領・基準をお知らせください。期日が近くても承ります。

状況の共有と範囲のすり合わせ

内製で回す範囲と外注へ切り出す範囲の線引きを、改修計画に沿って整理します。

検証範囲のご提案とお見積の提出

検証範囲と工数の根拠を示す見積書を提出します。稟議の材料にお使いください。

ご契約と準備を経たテストの開始

ご契約後、準備期間を踏まえた開始日でテストに入り、着手日に間に合わせます。

改修の着手日に間に合わせるために

電子納品ソフトの検証について相談する

ご相談では、対象の版と分野の組み合わせから検証範囲を整理し、優先順位と必要工数の考え方、関連テストの要否までお示しします。社内説明に使える状態でお渡しします。