学校給食管理システムの発注は、業務の整理、RFPの作成、契約と見積の比較の順に進めると、現場に合う導入につながります。
業務の範囲の決め方から、発注形態、RFP、契約、費用、委託先の選定、失敗への備えまでを、発注を進める順に追っていきます。
▼全体ガイドの記事
・学校給食管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
学校給食管理システムを発注・外注する前に整理すべき全体像
発注で最初に行うのは、システム化する業務を決めることです。給食業務には、献立・栄養・食材・発注・納品・衛生記録の領域があります。製品を探すのは、その後の仕事になります。
給食費の賦課・徴収・収納・減免・督促は、給食業務とは別の業務領域です。一つの製品で両方を実現できるとは限らないため、発注側は業務の境界と連携方法を先に確認します。
献立・栄養・発注の管理領域
献立・栄養・発注の領域は、現場で毎日使う機能が中心になります。栄養士や栄養教諭が使うため、栄養基準の判定に加えて、前回献立の再利用や季節メニューも見ておきます。
複数校への展開、特別食の扱いやすさも、同じように確かめます。さらに、Excelから置き換わるかどうかに加えて、登録から承認、印刷、現場確認までの流れが短くなるかも、選定の基準になります。
- 献立と栄養：献立作成、食品・料理マスタ、日本食品標準成分表に基づく栄養計算、食数集計
- 食材と納品：食材の見積依頼・発注、納品・検収、原価計算
- 安全と帳票：アレルギー対象食品の確認、調理指示書や帳票の出力
給食費の賦課・収納の管理領域
給食費管理では、対象となる業務と、公会計化に伴う調整事項を確認します。公会計化を伴う場合は、教育委員会のほか財政、会計、住民情報、学校、金融機関との調整が必要になります。
- 管理情報：児童生徒・保護者情報、食数、喫食・欠食、請求額、減免
- 収納業務：口座振替、納付書、入金消込、督促、滞納、会計帳票
- 外部委託費：システム導入費、収納代行費、通知発送費、金融機関手数料を分け、費目をそろえて比較
一体調達と分割調達の判断
一体調達は、窓口と責任範囲をまとめやすい一方で、製品の得意領域の外にある機能が追加開発になりやすい方法です。分割調達では、献立管理を専門パッケージ、給食費を自治体向け収納システムに分け、APIやファイル連携でつなぐ方法もあります。
統合は手段として扱い、業務の連続性、個人情報の受け渡し、障害時にどこまでを誰が受け持つか、将来の更新時期から判断します。
発注形態の選び方
発注形態は、既製パッケージ、クラウドサービス、個別開発を基本に比べます。
学校数や食数が増減する自治体では、導入時の機能に加えて、制度変更や組織再編にどこまで柔軟に対応できるかも評価します。
判断に迷うときは、標準機能で業務の八割を実現する構成から検討します。そのうえで、自治体固有の連携や帳票だけを追加する形にすると、費用と納期を抑えやすくなります。
標準業務が固まっている自治体に向くパッケージ導入
パッケージ導入は、利点と、追加開発が増える条件を分けて見ます。
- 導入しやすさ：献立、栄養計算、食材発注、帳票などの定型機能を、短い期間で入れられる
- 運用準備：実績のある画面と帳票で要件定義の負担が減り、現場研修の計画を立てやすい
- 追加開発：独自帳票や学校ごとの承認手順に合わせるほど、作り込みが増えます
一方で、標準機能に合わせて運用を変えられる部分と、法令・安全上変えられない部分を分けて評価します。
クラウド利用での複数拠点の共有と運用負担
クラウド利用では、複数拠点での共有と運用の負担を中心に確認します。
- データ共有：学校、給食センター、教育委員会の間で、同じ情報を見やすい
- 運用負担：サーバ更新やバックアップを自前で行う手間を減らせる
- 接続条件：ネットワーク分離、LGWAN-ASP、接続回線、保存場所、障害時の代替手段を見る
- 料金条件：利用者数、拠点数、食数、帳票、保守範囲によって変わるため、月額と合わせて見る
- 5年間の総額：初期設定、移行、研修、サポートに加え、契約終了時のデータ返却・削除まで含めて比べる
独自業務と連携要件が大きい場合のスクラッチ開発
独自の制度や連携が多い場合に、スクラッチ開発を比較の候補に入れます。
- 適する要件：独自の給食費制度、複雑な公会計、保護者申請、既存基幹システムとの連携
- 生じる負担：仕様決定、テストケース作成、制度改正時の改修、異動後の保守引継ぎ
- 併用案：給食固有機能はパッケージ、自治体固有の連携は追加開発にする
RFPと要件整理の進め方
RFPは、解決したい業務課題と、受託者に提案してほしい範囲を示す文書です。現場の要望をそのまま書き並べると、各社の解釈が分かれ、見積を比べにくくなります。
そこで、要件は共通の言葉で整理しておきます。現状と目的、利用者とデータ、帳票と非機能要件を明確にし、納期と評価方法もあわせて書き込みます。
担当者別の現行業務フロー
まず、業務フローに含める担当者と作業を洗い出します。
- 担当者：栄養士、栄養教諭、調理員、学校事務、教育委員会、会計担当、保護者
- 日々の作業：入力・確認の担当、帳票の受け渡し、献立確定と食数締めの時刻
- 例外を含む業務：欠食連絡、納品・検収、アレルギー食の指示・配食確認、請求・消込
- 管理対象：月次・日次・臨時業務、紙、個人Excelのファイル名・保存年限、重複マスタ
誰がいつ何を入力し、誰が確認して、帳票をどこへ渡すのかを、一覧にして見える形にします。さらに、紙や個人のExcelも含めて洗い出します。
必須機能と提案機能の書き分け
要件表では、項目を「必須」「できれば必要」「提案に任せる」に分けます。そのうえで、必須機能と、アレルギー事故を防ぐ確認手順は、はっきり書いておきます。
- 給食業務：献立・栄養計算、食数集計、発注・納品、必要帳票
- 安全と管理：食品アレルギー照合、権限・操作ログ、バックアップ、データ出力
- アレルギー手順：児童生徒情報の登録、献立照合、調理指示、配食確認、変更履歴、最終承認者
事故を防ぐには、対象食品の表示に加えて、業務手順として一連の確認ができることを要件に含めます。
連携・移行・非機能要件の具体化
見積の差が出やすいのは、移行、連携、認証、ネットワーク、帳票の条件です。そのため、これらの条件を具体的に示しておきます。
- 連携対象：住民基本台帳・学齢簿、会計・金融機関とのデータ受け渡し
- 連携仕様：連携元・先、データ項目、更新頻度、形式、エラー再処理、テスト用データ、文字コード
- データ移行：既存データ、退校・進級・転校時の扱い
- 非機能要件：利用者数、同時接続数、画面応答、バックアップ、障害連絡、復旧目標、ログ保存、権限、暗号化、データ返却
吹田市の仕様書は、57拠点153人の利用規模を示しています。また、児童生徒・アレルギー情報の連携、原則全データ移行、開発・テスト・研修環境も要件です。
（出典：吹田市「学校給食システム構築・運用保守委託業務」仕様書、2024年）
学校給食管理システムの契約形態の選び方
契約形態では、納品物と、要件が変わったときにリスクを負う側を決めます。システム本体から研修、保守、収納代行、追加改修までを一つにまとめる方法と、構築と運用を分ける方法があります。
契約名が同じでも中身は異なるため、まず成果物と検収条件を確かめます。次に、変更管理と障害対応を見ます。再委託、知的財産、データの帰属も、契約書に書かれているかを確認します。
請負契約の納品物と検収条件
請負契約は、合意したシステムや帳票、移行結果を受託者が完成させ、発注者が検収する形です。要件が固まったパッケージ導入や、仕様を定めた追加開発に向く契約です。
- 機能確認：機能要件、栄養計算、アレルギー表示、請求・消込、権限を確かめる
- 運用確認：実データに近いテストと、帳票印刷、障害時の復旧
- 契約条件：完成の定義が曖昧だと、修正が追加費用になりやすい
要件整理や伴走支援に向く準委任契約
準委任契約は、発注者と受託者が協力して、要件整理と現状調査、プロジェクト管理、運用設計を進める場合に使いやすい形です。たとえば、学校や給食センターごとに業務が異なり、完成仕様を決めきれない場合には、要件定義だけを準委任にして、その成果をもとに構築契約へ移る方法もあります。
作業時間を提供する形になりやすいため、契約書や実施計画で取り決めを細かく定めておく必要があります。月次の納品物や会議体、課題一覧、意思決定の期限が対象です。作業範囲と追加作業の承認手順も、あわせて書き込みます。
リース・保守・収納業務の期間と範囲
自治体では、構築後の利用をリースにし、保守やヘルプデスクを複数年の契約にする場合があります。また、公会計化ではシステム保守と収納業務を別々に委託することもあります。
函南町は、令和7年度の構築と、令和8年度から令和12年度までの保守・収納業務を分けて、5年間の提案限度額を示しました（出典：函南町「給食費等管理システム導入・運用収納業務」実施要領、2025年）。
システム費とは別に、契約期間や、物価・制度変更に伴う費用を見ます。利用者の追加や帳票の改修、収納件数に応じた費用も、分けて確かめます。
学校給食管理システムの費用相場の目安
費用を左右するのは、まず学校数、児童生徒数、調理場数です。そのほかに、対象業務や既存の連携、帳票数も関わります。移行、研修、保守、収納業務の有無によっても、費用は変わります。
紹介する数字は、公開価格や自治体資料から把握できる範囲で、公的な平均額ではありません。また、初期費用だけでなく、5年間の総保有コストに置き換えて比べます。
限定導入の初期費用の参考線（300万〜600万円程度）
初期価格は、導入する業務の範囲と対象校数を分けて見ると、比べやすくなります。
- 対象範囲：献立・栄養・発注、または給食費管理の一部を既製パッケージで導入
- 小中2校まで：290万円
- 小中5校まで：390万円
- 小中6校以上：490万円
この価格は、i_Toolsのオンプレミス参考価格です。システム本体、帳票、セットアップ、カスタマイズ、ミドルウェア・データベースを含みます（出典：i_Tools「学校給食費管理システム 導入費用・ランニングコスト・保守内容」、確認時点2026年）。
ただし、サーバ環境構築費と消費税は含まれていません。初期300万〜600万円程度を目安にできますが、学校数や連携によって見積は変わります。
複数校・公会計・連携を含む場合の費用幅（800万〜2,000万円以上）
構成に含める業務が広がるほど費用も上がるため、対象範囲ごとに見積を比べます。
- 複数校の統合：献立・発注・アレルギー・帳票に移行や基幹連携を加える
- 公会計・収納：住民情報連携、保護者通知、減免・督促、収納代行も対象にする
複数校の統合では、初期費用を800万〜2,000万円程度から見積もることがあります。さらに、公会計化や収納代行まで加えると、費用はもっと大きくなります。
函南町の公募では、構築業務の提案限度額が1,650万円、収納業務構築の提案限度額が1,869,000円でした。5年間の業務を含む総額は1億2,859万9,000円です。
（出典：函南町「給食費等管理システム導入・運用収納業務」実施要領、2025年）
これは特定自治体の最大規模の事例なので、一般的な価格とは断定しないようにします。
移行・保守・リースを含む5年間の総額
大規模更新では、初期構築費よりデータ移行や複数年の利用費が大きくなる場合があります。
秋田市の令和8年度資料では、データ移行経費として623万7,000円を計上しました。新システム導入経費も6,102万円を計上しました。5年間の保守管理委託費は1,584万円、システムリース料は4,518万円です。
（出典：秋田市「学校給食費管理システム更新・運用経費」、2026年）
公開例からは初期で1,500万〜6,000万円超の幅も考えられます。ただし、期間と対象業務が異なるため、他自治体の数字をそのまま予算に組むことはできません。
- 導入作業：初期設定、要件定義、設計、追加開発、データ整理・移行、連携、テスト、研修
- 運用費：ヘルプデスク、サーバ・回線、ライセンス、保守、制度改正、帳票改修
- 収納関連：収納代行、通知発送
安価に見える提案でも、別紙の前提や、利用者・学校・帳票の追加単価が分からなければ、稼働後に予算が膨らむことがあります。
委託先の選定と見積比較で確認すべきポイント
委託先は、同規模自治体や共同調理場での経験と、現場業務への理解で見ます。機能の数や営業資料の見栄えだけで選ぶことはしません。さらに、既存連携、移行と研修の体制、稼働後の制度改正への対応も確認します。
候補を2〜4社に絞り、同じRFP、サンプルデータ、評価項目をもとに提案と見積を依頼すると、公平に比べられます。
自治体規模と対象業務をそろえた実績確認
「導入実績あり」の表記では、規模や業務の違いが見えにくいため、比較の際に確認する条件をそろえます。
- 規模と業務：学校数、食数、調理場数、献立系か給食費系か
- 環境と期間：クラウドかオンプレミスか、連携先、稼働までの期間
- 導入後の状況：現在も保守中か、障害対応や移行課題をどう解決したか
可能であれば、同規模自治体への照会、匿名化した画面デモ、障害対応の事例も確かめます。製品が実在していても、自治体の業務やネットワークに合うとは限りません。
作業と前提をそろえた見積比較
比較表には、費用と作業範囲を並べ、各社の見積に含まれる前提を照らし合わせます。
- 費用項目：初期、月額・年額、保守、移行、連携、研修、サポート
- 追加時の費用：追加開発、帳票、利用者・学校追加、契約終了時のデータ出力
- 移行の範囲：クレンジング、項目変換、リハーサル、検証、旧システムとの並行稼働
「データ移行込み」といっても、その範囲は会社ごとに異なります。そこで、質問への回答を「含む」「含まない」「条件付き」に分けて、議事録と見積内訳に反映します。
導入後の体制と安全管理の評価項目
導入の成否は、本稼働の日よりも、その後の給食業務が安定して回るかで決まります。そのため、支援体制と情報管理を比較の基準に入れます。
- 支援体制：責任者、問い合わせ窓口、現場訪問、研修教材、操作マニュアル
- 継続運用：担当者異動時の引継ぎ、制度改正、食品マスタ更新への対応
- 情報管理：役割別権限、個人認証、操作ログ、暗号化、バックアップ、再委託管理、事故報告期限
児童生徒の氏名、保護者情報、アレルギー情報を扱うため、安全管理の条件は要件と契約の両方に含めます。
発注・外注で起こりやすい失敗と対策
計画が不十分だと、導入後に現場の負担が増えることがあります。また、当初の見積を超える追加開発が発生する場合もあります。
学校給食では、アレルギー対応や欠食・転校などの例外が起きます。調理場ごとの差や年度更新、給食費制度の変更なども、後から加わりがちです。そのため、試行、検証、承認、並行稼働の計画まで発注仕様に含めます。
表示機能だけに頼らないアレルギー対応
アレルギー対応は、登録から配食までの一連の流れで考えます。対象食品を赤字で表示するのは、その一部にすぎません。
- 登録と承認：登録者と承認者を分け、献立確定時に照合する
- 変更時の確認：献立変更があれば再確認を必須にする
- 配食記録：配食時は人が確認し、その記録を残す
文部科学省の食物アレルギー対応指針を参照して、自治体のマニュアルを具体的な操作に落とし込みます（出典：文部科学省「学校給食における食物アレルギー対応について」）。
データ移行を最後の一作業にしないための早めの準備
移行対象によって、事前に決めるデータや確認事項が変わります。
- 対象データ：食品・料理マスタ、献立履歴、学校・学年・クラス、児童生徒・保護者
- 会計と安全情報：アレルギー、請求・入金履歴
- 整理と検証：重複、表記揺れ、退校者、年度切替、旧コード、匿名化データ、件数照合、現場確認
現行データは、除外する対象と変換ルール、切戻しの方法を決めてから移します。秋田市の更新資料では、構築と別に移行費を計上したうえで、稼働前の運用テストと操作説明会も予定しています。
移行を発注者と受託者のどちらが担うのかは、責任者と納期とあわせて明記しておきます。
小さな試行とKPIによる本稼働の判断
全校一斉に切り替える前に、1校または1調理場で業務を通して試し、現場への影響を測ります。
- 試行する流れ：献立登録、食数確定、発注、納品、アレルギー確認、帳票出力
- 業務KPI：入力・帳票作成時間、発注修正件数、食数確定後の変更件数
- 安全・会計KPI：アレルギー確認時間、問い合わせ件数、請求・消込の差戻し件数
判断の際は、ログイン人数よりも、現場の負担と安全確認の改善を見ます。そのうえで、段階的に展開します。
よくある質問
発注では、機能に加えて、給食業務の範囲、自治体の調達手続き、現場の運用、個人情報の安全管理も確かめる必要があります。よくある質問には、判断の基準もあわせて答えます。
献立管理と給食費管理は同じシステムにすべきですか？
必ずしも同じシステムにする必要はありません。献立・栄養・発注と給食費の賦課・収納では、得意とする製品が異なることがあります。
業務範囲、連携の安定性、障害時の受け持ち、5年間の総額から、一体調達と分割調達を比べます。統合する場合は、どのデータを正とするかもRFPに書いておきます。
自治体でもクラウド型の学校給食管理システムを使えますか？
利用できる場合もありますが、自治体のネットワーク、認証、個人情報保護、委託先管理に合うかを確かめる必要があります。
LGWAN-ASP、ネットワーク分離、保存場所は、要件として書きます。バックアップ、障害時の代替、契約終了時の返却・削除も、要件に加えます。実際の環境で、デモと疎通テストを行います。
クラウドという名称だけで、安全性や安さを決めつけないことが大切です。
予算要求のために何を準備すればよいですか？
予算要求の概算には、規模、対象、調達条件を整理しておきます。
- 規模：学校数、調理場数、児童生徒数、利用者数
- 業務と既存環境：対象業務、現行システム、帳票数、連携先、移行対象
- 導入条件：希望稼働時期、保守年数
限定パッケージ、統合導入、公会計・収納を含む案など、三案程度を作ります。そのうえで、初期費用と5年間の運用費を分けて概算します。
公開事例は参考になりますが、業務の範囲は自治体ごとに異なります。そのため、金額をそのまま流用せず、前提条件を併記します。
発注先に見積を依頼するとき何を渡せばよいですか？
見積を依頼するときは、業務、データ、調達条件をまとめて渡します。
- 業務と規模：現行フロー、学校・調理場・食数、利用者と権限
- データと連携：食品・料理・児童生徒マスタ、帳票例、連携先、移行対象
- 契約条件：セキュリティ、希望日程、保守、納期、検収
アレルギーや給食費収納の例外処理は、匿名化したサンプルを使って伝えます。そのうえで、前提、対象外、追加時の単価、作業分担を見積書に記載してもらいます。
まとめ
発注・外注では、献立・栄養・発注と給食費・収納を分けて考え、必要に応じて連携を設計します。
発注形態は、パッケージ、クラウド、スクラッチ、ハイブリッドのうちどれが合うかを、現場の標準化や自治体固有の制度から比べます。さらに、ネットワーク、保守体制、5年間の総額も見ます。
発注前のRFPと比較条件の準備
製品を比べる前に、業務フローと必須要件を言葉にしておきます。移行や連携はもちろん、アレルギー確認、安全管理、導入後の支援も同じように書き出します。
初期費用に加えて、ライフサイクル費用で比べます。移行や研修、保守、リース、制度改正、収納も、その費用に含めて考えます。
候補会社には、同じRFPとサンプルデータを示します。そのうえで、実績、提案、担当体制、追加費用の透明性を確かめます。
小規模試行から本稼働までの進め方
本稼働までは、試行、運用・保守の整備、見積依頼の順に進めます。
- 本稼働前に1校または1調理場で、献立登録、食数確定、発注、納品、アレルギー確認、帳票出力、給食費処理を試します。
- 作業時間、確認漏れ、差戻し、問い合わせの状況を測ります。
- 文部科学省の食物アレルギー対応や教育情報セキュリティの考え方を自治体の手順に反映し、現場が無理なく続けられる運用を整えます。
- 障害や制度変更に対応できる保守を、契約に組み込みます。
- 運用と保守を整えてから委託先に提案と見積を依頼し、発注後の手戻りを減らします。
▼全体ガイドの記事
・学校給食管理システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。