学校管理システム開発の発注/外注/依頼/委託方法について

学校管理システムの発注・外注・委託は、機能の多い会社を選ぶだけでは成功しません。学校種別と業務範囲を先に整理し、RFPで同じ条件を提示したうえで、5年総額・データ移行・運用支援まで比較して委託先を決めることが重要です。

この記事では、学校管理システムを発注する際の形態の選び方、RFPと要件整理の進め方、契約形態、2026年時点の費用相場、委託先の選定方法、見積書の比較ポイントを解説します。公立学校・教育委員会と私立学校・学校法人で異なる判断軸にも触れ、導入後に現場で使われるシステムにするための準備まで具体的に紹介します。

▼全体ガイドの記事
・学校管理システム開発の完全ガイド

学校管理システムの発注・外注で最初に決めること

学校管理システムとは、児童生徒・学生の基本情報、学籍、出欠、成績、健康、進路、保護者連絡などを管理するシステムの総称です。小中高校の校務支援を中心に考える場合と、大学・専門学校の履修、入試、学費、証明書まで扱う場合では、必要なデータ構造も費用も大きく変わります。発注前に「誰が、どの業務で、どのデータを使うか」を決めることが出発点です。

発注形態は、大きくクラウドSaaS、既製パッケージの導入、パッケージへの追加開発、フルスクラッチ開発に分かれます。クラウドSaaSは、標準機能を使える学校や保守担当者が少ない学校に向いています。サーバーの調達や更新を自校で抱えにくく、法令改正や機能更新を受けやすい点が利点です。一方、独自の評価項目や帳票を標準機能で再現できるか、外部サービスとAPIやCSVで連携できるかを確認する必要があります。

パッケージ型は、学籍・出欠・成績・帳票などの実績ある機能を短期間で導入しやすい方法です。学校独自の業務を大幅に変えずに済む反面、要望を追加するほどカスタマイズ費用と将来の改修負担が増えます。フルスクラッチ型は独自業務への適合度を高められますが、要件漏れによる作り直し、納期遅延、担当者の退職後に保守できないリスクがあります。最初からスクラッチを前提にせず、標準機能で業務を見直せる範囲を確認することが大切です。

学校管理システムの発注では、画面やプログラムを作る作業だけでなく、現状調査、要件定義、データ移行、外部連携、権限設定、操作研修、稼働後の問い合わせ対応まで委託範囲に含めます。たとえば、出欠データを移行できても、年度更新や転校処理の手順が設計されていなければ、現場ではExcelへの二重入力が残ります。見積依頼書には、成果物と担当範囲を工程ごとに書き分けます。

公立学校や教育委員会では、複数校の共通運用、自治体のセキュリティポリシー、教職員の人事異動、共同調達を含めます。私立学校や学校法人では、コース制、中高一貫の学年構成、入試・学費・保護者サービス、法人内の複数校管理を含めると適合性を判断しやすくなります。大学・専門学校では、履修登録や単位認定、シラバス、証明書、学納金などを別の業務群として整理します。

発注前の要件整理はどのように進めますか？

発注前の要件整理では、機能一覧を先に作るより、現在の業務を場面ごとに書き出します。文部科学省の次世代校務DXは、クラウド上での校務、場所に縛られない処理、校務系情報と学習系情報の連携を方向性として示しています（出典：文部科学省「次世代の校務DXガイドブック」2025年）。この方針も踏まえ、目の前の紙作業をそのまま画面に置き換えるのではなく、業務の重複や不要な承認を見直します。

まず、入学、転入、転校、進級、卒業、氏名変更などの学籍イベントを並べ、誰がどの画面で登録し、誰が承認し、どの帳票を出力するかを整理します。次に、日々の出欠、遅刻・早退、授業別の出欠、成績入力、評価確定、通知表、指導要録までをつなげます。保健室では健康診断、アレルギー、配慮事項などの閲覧範囲を分け、保護者連絡では欠席連絡、アンケート、配布物、緊急連絡の経路を分けて記載します。

この棚卸しでは、理想の機能だけでなく、現場が困っている例を3件以上集めます。たとえば「年度更新のたびに名簿を手入力する」「成績確定後の訂正履歴が追えない」「養護教諭に不要な成績情報まで見えてしまう」といった具体例です。RFPでは、これらのシナリオを提案会社のデモ課題にします。カタログの機能名より、実際に5分から10分で処理できるかを見たほうが比較の精度が上がります。

すべての要望を必須にすると、開発費も納期も膨らみます。法令上必要な帳票、学籍と成績の整合性、最小権限、バックアップ、年度更新などは必須要件に置き、画面の色や便利な通知などは希望要件として分けます。公立の複数校では全校共通にする項目と学校ごとに設定できる項目を分離します。私立では、独自の評価方式を守る部分と、標準機能に合わせて業務を変更できる部分を分けます。

成果指標は「導入すること」ではなく、導入後に測れる数値で決めます。たとえば、年度更新の名簿作成時間を従来の何時間から何時間に減らすか、保護者の欠席連絡を電話から何％デジタル化するか、帳票作成の二重入力を何件なくすか、問い合わせの一次回答を何営業日以内にするかです。指標があると、提案会社の説明を「便利そう」という印象ではなく、達成可能性で評価できます。

学校管理システムのRFP作成と委託先選定の進め方

RFPは、提案依頼書とも呼ばれ、発注者が解決したい課題、対象範囲、前提条件、納期、提出物、評価方法を提案会社へ同じ条件で伝える文書です。口頭説明だけで見積を依頼すると、会社ごとに想定範囲が変わり、安い提案が機能不足なのか、別費用を計上していないだけなのか分からなくなります。RFPには、学校種別、学校数、児童生徒数、教職員数、既存システム、データ件数、利用端末、連携先、希望稼働時期を記載します。

RFPの要件欄には、機能名だけでなく受入条件を書きます。「成績管理に対応」ではなく、「教科、観点、評価期間を設定でき、入力後に担任・管理職が確定し、確定後の変更履歴を権限者が確認でき、指定帳票を出力できる」と書くイメージです。さらに、既存データの抽出形式、文字コード、欠損値の扱い、移行リハーサルの回数、並行稼働の期間を明記すると、移行費用を比較しやすくなります。

提案書に求める項目は、システム構成、画面デモの手順、担当者の経歴、導入実績、体制図、工程表、課題管理方法、障害時の連絡先、保守時間、SLA、再委託先、契約終了時のデータ返却方法です。費用は初期導入、設定変更、追加開発、移行、連携、研修、月額、保守、バックアップ、解約時の作業に分けて提示してもらいます。記載がない項目は「含まれる」と決めつけず、質問票で確認します。

委託先を選ぶ際は、学校向けの導入実績があるかだけでなく、自校と似た学校種別、規模、複数校展開の経験があるかを見ます。教育委員会であれば、自治体間の調整、標準化、共同利用、ヘルプデスクを担当できるかが重要です。学校法人であれば、法人内の意思決定を支援し、中高や複数キャンパスのデータを分けながら連携できるかを確認します。導入校数だけで優劣を決めないことがポイントです。

デモでは、発注者が用意した同じシナリオを全社に実施してもらいます。児童生徒の転校、学年更新、出欠の訂正、成績確定後の修正、指導要録の出力、権限のない利用者による閲覧拒否、障害発生時の連絡を確認します。画面の見た目よりも、入力回数、エラー時の戻し方、履歴の追跡、CSV出力、現場の操作研修のしやすさに注目します。質問への回答が「標準機能」「設定で対応」「追加開発」「対応不可」のどれか明確な会社は、見積の透明性も高くなりやすいです。

契約形態と検収条件を発注前に決めます

学校管理システムの契約では、要件定義と開発を同じ契約にするか、工程ごとに分けるかを検討します。要件が固まっていない段階で、すべてを完成保証の請負契約にすると、双方の想定がずれて変更管理が難しくなります。反対に、目的や成果物が明確な開発工程まで準委任だけにすると、完成状態や検収の責任が曖昧になりやすいです。契約方式は法務・調達担当者と確認し、工程ごとに適した責任分界を定めます。

請負契約は、合意した仕事の完成と成果物の引き渡しを中心に責任を定める契約です。画面、帳票、連携機能などの完成条件が明確な追加開発で検討しやすい形式です。準委任契約は、要件整理、現状調査、運用設計、プロジェクト支援など、専門家の作業や役務の提供を中心に定めます。要件が変わりやすい初期フェーズでは、作業範囲、稼働時間、成果物、報告方法を具体的に書くことが必要です。

SaaS利用契約では、月額や年額の利用料だけでなく、利用者数・学校数の数え方、機能追加の告知、サービス停止、バックアップ、障害対応、データ保管場所、契約終了後の返却形式を確認します。追加開発がある場合は、SaaS利用契約と開発契約の優先関係も明確にします。契約書だけでなく、仕様書、SLA、個人情報の取扱い、再委託先一覧、見積内訳を契約書の別紙として紐づけると、後の認識違いを抑えられます。

検収条件は「システムが納品された」では不十分です。RFPで示した業務シナリオをもとに、学籍情報を登録してから出欠・成績・帳票へ正しく反映されること、権限ごとに見える情報が異なること、エラーや訂正の履歴が残ること、想定人数で処理時間が許容範囲に収まることを確認します。年度更新や一括登録は本番直前にしか試せない場合があるため、テスト用データでリハーサルを行い、未解決の課題は一覧化します。

データ移行の検収では、件数が一致するだけでなく、氏名、学年、所属、出欠、評定、健康情報などの項目が正しい列に入り、文字化けや重複がないか確認します。移行元のExcelに誤りがある場合の修正担当も決めます。検収後に見つかった不具合の無償対応期間、瑕疵の定義、緊急障害の復旧目標、問い合わせの受付時間を契約に反映すると、稼働後の責任分界が明確になります。

学校管理システムの費用相場と5年総額

学校管理システムの費用は、学校数、児童生徒数、利用者数、対象機能、データ移行量、連携数、帳票の独自性、研修と保守の範囲で変わります。目安として、標準的なクラウドSaaSは1校あたり初期0万〜50万円、月額2万〜10万円程度、パッケージへの軽微な設定変更は初期100万〜300万円程度、追加開発が大きい場合は300万〜1,000万円以上が想定されます。これは公開価格と一般的な開発工数を組み合わせた編集部試算であり、確定価格ではありません。

公開価格を確認できる例として、株式会社システムディのSchool Engineでは、校務支援が小中学校1校あたり月額22,000円、高等学校が月額44,000円、初期導入費用が1校330,000円（税込）です（出典：株式会社システムディ「校務支援システム School Engine」料金ページ、2026年8月確認）。校務支援だけを5年間使う単純計算では、小中学校が33万円＋2.2万円×60か月で165万円、高等学校が33万円＋4.4万円×60か月で297万円です。

この金額には、学校ごとのデータ移行、現地研修、個別帳票、外部連携、通信環境、追加サポートが含まれない場合があります。学校用グループウェアや学校徴収金を追加すれば月額も変わります。公開価格は比較の起点として有効ですが、自校の5年TCOを計算するときは、初期導入費、月額、保守、移行、連携、研修、端末やネットワーク、契約終了時のデータ返却費を別々に足します。

見積書では、開発費が安く見えても、移行や研修が「別途」とされていることがあります。移行対象の年度数、データの形式、クレンジングの有無、移行リハーサルの回数を確認します。API連携では、相手システム側の仕様変更対応、連携監視、障害時の再送、認証方式まで費用に含めます。帳票は、標準帳票の設定なのか、帳票レイアウトの新規開発なのかを分けます。

研修費は、管理者向け、教職員向け、養護教諭向け、教育委員会向けに分け、対面かオンラインか、録画教材が残るか、異動者向けの追加研修があるかを確認します。保守費は、受付時間、回答期限、現地訪問、バージョンアップ、法改正対応、バックアップ、障害復旧を含めて比べます。月額が最安の提案ではなく、同じ範囲をそろえた5年総額で比較することが重要です。

見積比較と委託先選定で失敗しないポイント

見積比較では、金額の大小だけでなく、前提条件と将来の変更費用をそろえます。提案会社ごとに学校数、利用者数、データ件数、連携先、研修回数、保守時間が違えば、合計金額を比べても意味がありません。比較表には、要件ごとの対応可否、対応方法、追加費用、納期への影響、提案書の該当ページを記録します。選定会議で「なぜこの会社を選んだか」を説明できる状態が理想です。

要件の回答は、「標準」「設定変更」「個別開発」「外部サービス連携」「対象外」の5区分に分けると比較しやすくなります。個別開発の場合は、初期費用だけでなく、将来のバージョンアップ時に再改修が必要か、別会社へ移管できるかを尋ねます。対象外の場合は、代替運用で教職員の作業が何分増えるかを見積もります。価格の低さが、発注者側の手作業を増やす提案になっていないか確認します。

評価点は、たとえば機能適合25点、移行・連携15点、セキュリティ15点、導入体制15点、操作性10点、保守・SLA10点、5年TCO10点のように、価格以外にも配点します。点数の割合は案件に合わせて変えますが、現場定着と運用継続を評価項目に入れることが大切です。学校管理システムは毎日使う基幹業務なので、導入時の価格差より、5年間の手戻りや問い合わせ対応の差が大きくなる場合があります。

委託先を選ぶときに見落とされやすいのが、契約終了時の出口です。児童生徒・学生データの所有権、返却される項目、CSVやJSONなどの形式、文字コード、画像や添付ファイルの扱い、返却費用、返却期限、サービス上の消去証明を確認します。データを取り出せても、項目定義やコード表がなければ次のシステムへ移せないため、データ辞書とAPI仕様書の提供条件も確認します。

再委託がある場合は、クラウド基盤、データセンター、サポート窓口、開発会社の役割と所在地を把握します。障害が起きたときに学校が連絡する窓口、一次回答の時間、復旧目標、状況報告の頻度を決めます。契約終了後に一定期間だけ参照できる移行支援環境を用意できるかも聞いておくと、将来の入れ替えで交渉力を失いにくくなります。

2026年時点のセキュリティと学校管理システムの動向

学校管理システムは、氏名、生年月日、出欠、評点、健康情報などを扱うため、便利さだけでなく安全管理を発注条件にします。文部科学省は令和7年3月に教育情報セキュリティポリシーに関するガイドラインを改訂し、教育委員会などが自組織のポリシーを策定・見直す際の参考として公開しています（出典：文部科学省「教育情報セキュリティポリシーに関するガイドライン」令和7年3月）。RFPには、自校のセキュリティポリシーと照合する質問を含めます。

最低限、教職員、管理職、養護教諭、事務職員、教育委員会、保護者ごとの最小権限を設定できるか確認します。多要素認証、端末や場所を含むアクセス制御、通信中と保存中の暗号化、操作・閲覧・出力の監査ログ、アカウントの異動・退職処理、バックアップの世代数と復元テストを確認します。健康情報や配慮事項を成績担当者が閲覧できないように、項目単位で制御できるかも重要です。

障害や災害を想定し、復旧目標時間、復旧時点、代替連絡手段、学校への報告方法、年1回以上の復旧訓練の有無を確認します。クラウドだから安全とは限らず、委託先の運用設計と学校側のアカウント管理が必要です。認証情報を共有しない、異動者の権限を速やかに止める、出力したファイルを端末に残さないなど、システム外の運用ルールもRFPと研修に含めます。

文部科学省の令和7年度以降のICT環境整備方針では、2029年度までに次世代の校務システムを導入済みの自治体の割合と、ロケーションフリーで校務処理を行う自治体の割合を100％とする方向が示されています（出典：文部科学省「令和7年度以降の学校におけるICT環境の整備方針」2025年）。そのため、2026年時点の発注では、校内サーバーをクラウドへ移すかどうかだけでなく、学習系との接続、場所を問わないアクセス、データ連携、災害時の継続性を確認する必要があります。

教育委員会が複数校をまとめて発注する場合は、システムをそろえるだけでは不十分です。株式会社ケイズが公開する鳥取県の事例では、県内全小中179校を対象に、共同調達、業務の標準化、帳票統一、研修、ヘルプデスクを組み合わせています（出典：株式会社ケイズ「全国初 統合型校務支援システムを県内全小中179校に一斉導入」）。共同調達では、学校ごとの例外を増やすより、共通運用と設定で吸収できる範囲を先に合意します。

よくある質問（FAQ）

最後に、学校管理システムを発注・外注するときに寄せられやすい質問へ回答します。費用や導入期間は要件で変わりますが、発注者が確認すべき判断軸を押さえると、提案会社との打ち合わせを具体化できます。

独自業務が多く、標準機能で重要要件を満たせない場合はスクラッチ開発を検討しますが、まずはパッケージやクラウドSaaSのFit & Gapを確認することをおすすめします。費用、納期、保守要員、将来の制度変更まで含め、標準機能に業務を合わせられる範囲を見極めて選びます。

標準的なクラウドSaaSは初期0万〜50万円、月額2万〜10万円程度、パッケージの追加開発は初期100万〜1,000万円以上が目安です。複数校の共同利用や大学の基幹学務では、移行、連携、ネットワーク、研修、保守を含めて数千万円以上になる場合もあります。月額だけでなく、5年総額と契約終了時のデータ返却費まで見積書で確認します。

標準的なクラウドSaaSの設定中心なら1〜3か月、パッケージの設定変更なら3〜9か月、追加開発が大きい場合は6〜15か月、フルスクラッチや複数校共同利用では12〜24か月以上が目安です。データ移行と研修を後回しにすると稼働直前に負荷が集中するため、RFP段階から移行リハーサル、パイロット校、並行稼働の期間を工程に入れます。

相談しても問題ありませんが、1社の提案だけで要件を決めないことが大切です。まず現場の業務と課題を棚卸しし、複数社へ同じRFPとデモシナリオを提示します。要件定義の支援を依頼する場合は、相談の成果物、費用、提案会社の選定から独立した助言ができるかを確認すると、発注者に必要な比較軸を保ちやすくなります。

まとめ

学校管理システムの発注・外注・委託では、最初に学校種別、対象業務、利用者、導入校数、既存データ、連携先を整理します。そのうえで、クラウドSaaS、パッケージ、追加開発、スクラッチの違いを比較し、RFPに業務シナリオと受入条件を記載します。

見積比較では、初期開発費や月額だけで判断せず、データ移行、帳票、API連携、研修、保守、バックアップ、障害対応、契約終了時のデータ返却を含む5年TCOでそろえます。委託先は、実績の数だけでなく、同じ学校種別・規模での導入体制、デモの具体性、標準・設定・追加開発の説明、SLAと再委託の透明性で評価します。

最後に、現場教職員、情報担当、管理職、調達・法務担当を選定体制に加え、必須要件と希望要件、デモシナリオ、評価配点、検収条件を合意します。導入後の年度更新、人事異動、問い合わせ、障害、データ返却までを最初から設計しておけば、学校管理システムは単なる名簿管理ではなく、校務を継続的に改善する基盤になります。

▼全体ガイドの記事
・学校管理システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。