献立の栄養価が丸めと計算順序の違いで現行の値と一致しない
現行と新システムで丸めの位置や計算順序が異なると、同じ献立でも栄養価の値が一致せず、栄養基準を満たしているか確認できません。
更改・改修の受け入れテストで、何をどこまで確かめるか。その線引きを、ベンダーの検証とは別の立場から業務フローにもとづいて一緒に設計します。
支援実績5,000件以上













更改や改修では、ベンダー側のテストを通っていても、発注側の業務条件で不具合が判明する場合があります。栄養価計算、アレルギー対応、給食費の調定、食材発注の各機能で、稼働前に確認したい不具合の例を挙げます。
現行と新システムで丸めの位置や計算順序が異なると、同じ献立でも栄養価の値が一致せず、栄養基準を満たしているか確認できません。
対応の開始日と終了日の判定が誤ると、期間内の児童生徒が対応表に出力されず、除去食の調理指示を出せないおそれがあります。
月途中の転入・転出が調定に反映されないと、実人数と調定額が合わず、会計担当が差異の原因を手作業で追うことになります。
献立の変更が発注数量へ反映されないと、変更前の数量の発注データが納入業者へ送られ、食材の過不足を当日に人手で調整することになります。
外字を含む児童生徒の氏名や食材名が文字化けすると、口座振替データや対応表で対象を特定できず、帳票の再発行と確認が必要になります。
給食は授業日ごとに提供され、残る不具合は稼働当日から業務に影響します。アレルギー対応の誤りは健康被害、給食費の誤りは会計処理の混乱を招きます。
設計書に書かれていない仕様は、開発が進むほど受け入れテストの段階でしか見つけられなくなります。現行の帳票と運用知識を設計書へ照合し、検証範囲の根拠を文書として残すことが、開発前のレビューの役割です。
栄養価計算の丸め位置や計算順序は、運用知識として残り、設計書に反映されないまま開発が進む場合があります。現行の出力帳票と設計書上の計算結果を突き合わせ、数値の差異を開発前に確認します。
アレルギーの個別対応は、除去・代替の判定条件が現場の運用で決まっている部分があります。設計書の条件分岐と栄養教諭の運用実態を照合し、学校・調理場へ出力する対応表の内容が一致するかを確認します。
給食費の調定・減免の区分は、会計システムへ連携するデータの正しさに直結します。DB設計書の項目定義と連携仕様を照合し、転入・欠食・月途中の異動など例外処理の扱いが一致しているかを確認します。
児童生徒の在籍データは、給食費の調定の元データになります。提供元システムの様式と取り込み側の項目定義を照合し、項目の欠落や形式の相違によって取り込みエラーが起きないかを確認します。
自校方式と給食センター方式では、献立の適用単位と発注の集約単位が異なります。システムのマスタ定義と調理場の構成資料を照合し、献立表・発注帳票の出力単位が調理の実態と一致するかを確認します。
学校給食管理システムの更改では、計算・連携・帳票・運用手順を段階ごとに分けて検証し、稼働可否の判断材料を揃えます。
栄養価計算と給食費の調定額の算出は、同値分割と境界値で入力の区切りを整理し、基準値ちょうどの値、端数、欠食を含む条件を項目化します。仕様書にない計算順序はベンダーへ確認します。
児童生徒の在籍データの取り込みから調定・収納、会計システムへの連携までを通しで検証します。転入・転出や月途中の異動、口座振替データの様式と金額の一致を確かめ、突合記録として残します。
献立の登録から栄養価計算、食材発注、アレルギー対応表、献立表の配付までを、業務手順どおりに通して確認します。単独調理場と共同調理場で適用単位が異なる場合は、両方の条件で確認します。
栄養教諭や会計担当に実機で日次の操作を試してもらい、結果を不具合票と合わせて整理します。管理職が稼働可否を判断できる材料として提出できる形にまとめます。
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
受け入れテストの検証範囲は、テスト項目の一覧ではなく、対象システムの業務フローから導き出すものです。GENZは、開発を担う受託ベンダーとは別の第三者として、検証範囲の設計から報告書の作成までを支援します。
献立の登録から給食費の調定まで、業務の流れに沿って検証の観点を設定し、テスト項目へ展開します。範囲の根拠は設計として残します。
制度変更の施行日に向けて期間が限られる場合は、改修の影響範囲をもとに対象を絞り込み、検証する範囲と検証しない範囲を事前に合意します。
ベンダーが行なう開発側のテストとは別に、発注側の視点でテストを設計・実行します。既存の体制のまま、開発と並行して検証を進められます。
検証した範囲・未検証の範囲・不具合票の状態がわかる報告書を納品します。稼働可否の説明と庁内のシステム監査に使える粒度で整理します。
学校給食管理システムの受け入れテストは、次に挙げる工程で進めます。各工程で合意形成の材料をお渡しします。
現行の帳票と仕様書を確認し、献立・アレルギー・給食費の流れを聞き取ります。
検証範囲と優先順位を設計し、必要工数の考え方を添えて見積もりを提示します。
設計したテスト項目を実行し、不具合票と検証の記録を週次で共有します。
稟議や監査に使える報告書を納品し、修正後の回帰テストを実施します。
学校給食管理システムの受け入れテスト設計
検証範囲の線引きの根拠が示せず、稟議や監査への説明が進まないご担当者様へ。GENZは、業務フローから検証範囲と優先順位を一緒に設計し、必要工数の考え方まで整理してお渡しします。