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設計書
  • 業務フロー図
  • 画面項目一覧
入金連携の仕様差異を残すと、請求と入金の消し込みが一致せず、会計側との金額の不整合として表面化します。

会計システムと入金データの連携仕様を先方資料と照合する

受付から入金までを一括管理する構成では、会計システムや金融機関の入金データとの連携が発生します。連携仕様の資料と照合し、ファイル形式・項目の対応・消し込みの時期に齟齬がないかを確認します。

確認する資料
  • 連携仕様書
  • レイアウト定義
  • 消し込みルール
権限の検証記録がないと、セキュリティ事象が起きた際に影響範囲の特定に時間がかかり、説明責任を果たせません。

役割ごとの参照・更新の範囲を、権限設定の一覧と運用規程で照合する

情報システム部門・施行部門・会員管理・経理では参照と更新の権限が異なります。権限設定の一覧と運用規程を照合し、役割ごとの範囲に過不足がないかを確認します。検証記録が説明責任の材料になります。

確認する資料
  • 権限設定一覧
  • 運用規程
  • 役割分担表
変換規則の漏れを残したまま移行すると、稼働直後に突合作業と原因調査が同時に発生し、安定化までの期間が延びます。

移行対象の項目と変換規則を仕様と照合する

更改では既存システムや紙台帳から会員・施行履歴の移行が発生します。移行対象の項目と変換規則を仕様と照合し、桁欠け・文字コード・日付形式の変換漏れがないかを確認します。

確認する資料
  • 移行項目一覧
  • 変換規則書
  • 移行計画書
  • 旧帳票サンプル
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

GENZが代行する葬祭システムのテスト

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

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

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

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

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

専門ノウハウを即戦力で

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

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

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

  • ベンダー外の範囲を埋めるテスト設計
  • 繁忙期を避けたテスト実行体制
  • 稟議・経営会議で説明できる報告書
  • 回帰テストの根拠となる検証記録の保存
06 SERVICE

葬祭業務の工程から起こすテスト設計支援

葬祭システムの更改では、ベンダーの検証が終わった後に施行管理・会員管理の受け入れテストが残ります。GENZは施行・互助会・請求・法要の工程に沿って検証範囲を定め、テスト設計から実行・報告までを担います。

SVC 01

工程を起点にテスト設計を組み立てる

見積もり・施行予定・会員・掛金・請求の工程順にテスト項目書を起こし、対象に含める範囲と含めない範囲の判別基準を示します。

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

移行データと外部連携まで検証範囲に含めます

既存システムや紙台帳からの会員・施行履歴の移行データと、会計システムとの入金消し込み連携まで検証範囲に含めて確認します。

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

テスト工程だけを分担

開発ベンダーを替えず、テスト工程だけを切り出して受け持ちます。開発の進行と並行して検証を進め、繁忙期に自部門の人手を割かずに済みます。

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

検証結果と残る不具合を報告書に

実施した検証範囲・確認できた内容・残存する不具合と影響を報告書にまとめ、稟議と経営会議での説明に使える記録として残します。

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

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

ご相談から報告書の納品まで、設計資料の確認を起点に進めます。各段階で合意した内容を次へ引き継ぎます。

現行の設計書と課題のヒアリング

設計書とテスト項目書の有無、未確定の仕様、繁忙期の制約を伺います。

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

検証範囲と優先順位を整理し、テスト設計の方針と見積もりをご提示します。

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

合意した範囲でテストを実施し、検出した不具合を不具合票で共有します。

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

実施項目と結果、残る不具合を報告書にまとめ、修正後に再確認を行います。

検証範囲の整理から相談できる

葬祭システムの検証範囲と優先順位から、GENZへご相談ください

現在の設計書やテスト項目書の状況、未確定の仕様、繁忙期の制約をお聞きし、検証範囲と優先順位を整理してご提示します。開発ベンダーを替えず、テスト工程だけのご相談からお受けします。