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

受け入れテストの検証範囲は、テスト項目の一覧ではなく、対象システムの業務フローから導き出すものです。GENZは、開発を担う受託ベンダーとは別の第三者として、検証範囲の設計から報告書の作成までを支援します。

SVC 01

業務フローを起点にテスト設計を行なう

献立の登録から給食費の調定まで、業務の流れに沿って検証の観点を設定し、テスト項目へ展開します。範囲の根拠は設計として残します。

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

検証の範囲を事前に合意する

制度変更の施行日に向けて期間が限られる場合は、改修の影響範囲をもとに対象を絞り込み、検証する範囲と検証しない範囲を事前に合意します。

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

第三者として既存体制のまま検証

ベンダーが行なう開発側のテストとは別に、発注側の視点でテストを設計・実行します。既存の体制のまま、開発と並行して検証を進められます。

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

検証の記録を監査向け報告書にまとめる

検証した範囲・未検証の範囲・不具合票の状態がわかる報告書を納品します。稼働可否の説明と庁内のシステム監査に使える粒度で整理します。

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

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

学校給食管理システムの受け入れテストは、次に挙げる工程で進めます。各工程で合意形成の材料をお渡しします。

ヒアリング

現行の帳票と仕様書を確認し、献立・アレルギー・給食費の流れを聞き取ります。

テスト設計と見積もり

検証範囲と優先順位を設計し、必要工数の考え方を添えて見積もりを提示します。

テストの実施と結果の共有

設計したテスト項目を実行し、不具合票と検証の記録を週次で共有します。

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

稟議や監査に使える報告書を納品し、修正後の回帰テストを実施します。

学校給食管理システムの受け入れテスト設計

学校給食管理システムの検証範囲と優先順位をGENZへご相談ください

検証範囲の線引きの根拠が示せず、稟議や監査への説明が進まないご担当者様へ。GENZは、業務フローから検証範囲と優先順位を一緒に設計し、必要工数の考え方まで整理してお渡しします。