教務システム開発の発注/外注/依頼/委託方法について

教務システムの発注は、対象範囲の確定、標準機能を軸にしたRFP作成、同一条件での委託先比較の順に進めると、導入後の運用まで見通せます。

発注範囲と方式の決め方から稼働までの流れを、順に説明します。全体像は下の完全ガイドにまとめています。

▼全体ガイドの記事
・教務システム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

教務システムの発注・外注で最初に決めること

発注では、製品名や開発言語を選ぶ前に、対象範囲と業務の優先順位を決めます。小中高校では校務支援の教務系機能、大学・専門学校では学務システムとして扱うことが多い領域です。

小中高校では学籍、成績、出欠、帳票を、大学・専門学校では履修、単位、進級、卒業判定、学生ポータルなどを扱います。扱う業務は異なっても、情報を一度入力し、複数の業務で安全に使うという目的は共通です。

学校種別と利用者の確定

まず、対象校種、導入校数、教育委員会や学校法人本部の利用有無を決めます。小中学校の評定・通知表と大学の履修登録・単位認定では、データ構造や承認手順が異なるためです。

利用者と例外業務を洗い出したうえで、代表校の業務シナリオに当てはめると、外注する範囲が具体的になります。

• 利用者と権限：教員、教務主任、担任、養護教諭、事務職員、学生、保護者、教育委員会ごとの入力者・承認者・閲覧者。
• 例外業務：例外履修、年度途中の転入、自治体独自帳票、個別支援記録の扱い。
• 代表シナリオ：成績確定、転入、欠席訂正、進級、卒業判定、調査書出力を含む一連の流れ。

MUST機能と将来機能の切り分け

初年度から必要な機能と、将来拡張する機能を分けておきます。優先度を分けておけば、初期導入の必須範囲と将来拡張の境界について、発注側と委託先で合意できます。

• MUST：学籍・在籍管理、履修・時間割、出欠、成績、進級・卒業判定
• MUST：帳票、権限、操作ログ
• WANT：ダッシュボード、高度な分析、AIによる要約
• WANT：追加の保護者通知、学習eポートフォリオ

効果を測るには、紙が減ったかだけでなく、業務の数字を導入前に押さえておく必要があります。学籍の重複入力数、成績確定時間、年度更新日数を、まず記録します。加えて、帳票訂正件数、問い合わせ件数、移行後のヘルプデスク対応時間も残しておきます。

教務システムの発注形態の選び方

発注形態は、標準パッケージ・SaaS、設定変更、既存製品との連携開発、スクラッチ開発から選びます。共通機能は標準に合わせ、教務の差別化部分だけを追加開発すると、費用と安全性のバランスを取りやすくなります。

標準パッケージ・SaaSの導入

標準パッケージやSaaSは、学籍、成績、出欠、帳票、保健、連絡などを短期間で導入しやすい方式です。また、クラウドでは、サーバーやOSの更新、バックアップの一部を提供者に任せられます。

導入範囲とデモの結果を照らし合わせ、標準機能のまま運用できる箇所を見極めます。

• 段階導入：1校から始めて、複数校へ広げる計画を立てられます。
• 個別要件：独自帳票や特殊な履修規則は、運用変更、設定、追加開発のなかから対応方法を選びます。
• デモ確認：年度更新、成績訂正、転入・転出、履修取消、帳票再出力、権限変更、障害連絡の操作を試します。
• 標準化：業務を標準機能に合わせると、更新費用やベンダーロックインを抑えられます。

スクラッチ開発・連携開発の選択

スクラッチ開発では、独自制度、特殊な帳票、既存基幹システム、自治体の認証基盤に合わせて業務を設計できます。検討するのは、学校法人全体のデータモデルを変える場合や、独自業務が競争力・教育品質に直結する場合です。

全機能を独自開発すると保守の負担も長期化するため、標準機能との分担を検討します。

• 長期保守：制度改修、担当者の交代、障害、脆弱性対策を、継続して担います。
• 連携構成：標準パッケージを中核に、LMS、学生ポータル、認証基盤、学校徴収金、自治体基盤とは、APIまたはCSVでつなぎます。
• 連携要件：項目、更新頻度、再送、個人情報の受け渡し、停止時の手順を定め、一覧とサンプルデータで検証します。

クラウドとオンプレミスの比較

クラウドは、端末とネットワークがあれば場所の制約を受けにくく、サーバーの調達や更新の負担も抑えられます。一方、オンプレミスは、校内や自治体のネットワーク、既存設備に合わせやすい方式です。

設置形態だけで安全性を判断しないよう、運用負担と安全要件を同じ条件で比べます。

• 運用負担：オンプレミスでは、サーバー、バックアップ、災害対策、更新を自組織か委託先が担います。
• 比較条件：プライベートクラウドや閉域網を含め、利用場所、認証、データ所在、障害時の代替手段を並べて比べます。
• ガイドライン：文部科学省のガイドラインは2025年3月に改訂され、改訂事項にはクラウド利用、情報資産の分類、強固なアクセス制御などが含まれます。
• RFPの安全要件：二要素・多要素認証、最小権限、ログ、暗号化、脆弱性対応、バックアップ、復旧目標、再委託管理を確認します。

RFPと要件整理の進め方

RFPは、業務課題、対象範囲、前提条件、期待成果、提案依頼事項を同じ条件で伝える依頼書で、価格だけを尋ねるものではありません。

条件の粒度がそろわないまま相見積もりを取ると、A社は移行費込み、B社は開発費のみという比較になります。その結果、契約後に追加費用が膨らむことがあります。

現状業務とデータの棚卸し

教務主任のほか、担任、養護、進路、事務、情報担当、教育委員会などに聞き取りを行い、学籍管理、成績・出欠への転記、帳票の承認者を業務フローとして描きます。

聞き取りの内容に加え、管理データ、識別方法、移行履歴の範囲もそろえておきます。

• データ台帳：紙台帳、Excel、旧システム、LMS、認証基盤、保護者連絡ツールの項目と管理責任者を記録します。
• 識別・履歴：氏名変更、転校、休学、退学、クラス変更、同姓同名、旧字体を想定し、児童生徒・学生IDの原本を決めます。
• 移行範囲：直近年度、在籍者の全期間、卒業生を含む全履歴のどれを対象にするかで、費用と期間が変わります。

RFPへの機能・非機能・移行条件の記載

機能要件には、学籍、入学・転入・転出、履修、時間割を含めます。さらに、出欠、遅刻・早退、試験を書き出します。評定、単位、進級・卒業判定も、同じ粒度で書き出します。

委託先には、機能の実現方法と運用・契約の条件を、同じ粒度で回答してもらいます。

• 機能範囲：保健、進路、帳票、保護者・学生への通知まで含めます。
• 実現方法：標準、設定変更、個別開発、外部連携のどれにあたるかを、機能ごとに尋ねます。
• 性能・運用：画面・帳票数、年度更新・例外処理の操作回数、利用可能時間、同時接続数、応答、復旧目標を確認します。
• 安全・終了条件：バックアップ世代、ログ保存期間、認証、権限、暗号化、脆弱性診断、保守窓口、サポート時間を定めます。
• 契約終了時：データ返却形式、移行支援、削除証明、仕様書・設定情報の引き渡しを書面で求めます。

要件が抜けたままでは、稼働後の運用費や乗り換え費用を、委託先どうしで比べられなくなります。

デモとPoCによる現場適合性の確認

デモでは営業資料の説明だけでなく、学校側が用意したシナリオを委託先に操作してもらいます。そのシナリオは、4月のクラス編成から始まり、年度途中の転入、欠席訂正、成績締め、評定承認、調査書出力、保護者通知までを一続きで実演します。

デモとPoCでは、現場の操作性と、実データに近い条件での適合性を確かめます。

• 現場確認：複数校の担当者が、入力負荷、画面、エラー復帰、権限による表示を確認します。
• PoC・先行導入：不確実性が大きい場合に、代表校や代表学年で実施します。
• 検証対象：サンプルデータで名寄せ、帳票、連携、権限、ネットワーク、研修時間を確かめます。
• 事前合意：成功条件、期間、費用、本契約への移行条件を定め、試験の長期化を防ぎます。

教務システムの契約形態と分担

教務システムの開発には、要件がまだ固まっていない工程と、完成物を定義できる工程が混在します。そのため、要件定義、設計・開発、移行の各工程について、一括で契約するか工程ごとに分けるかを検討します。研修・導入支援、保守・運用も、同じ観点で見直します。

契約形態は価格だけで決めず、変更が起きる工程と、その責任の所在を対応させて考えます。

請負契約の成果物と検収

請負契約は、合意した仕様に基づいて成果物を完成させ、発注者が検収する工程に適しています。

• 成果物：画面、帳票、API、移行結果、テスト仕様書、操作マニュアルを定めます。
• 検収条件：重大障害、未解決事項、受入テスト期間、修正回数、仕様変更手続きを記載します。
• 仕様の具体化：「使いやすく」「既存と同じ」といった表現は、画面例や業務シナリオに置き換えます。
• 制度変更：法令・ガイドライン対応を無償更新に含めるか、追加費用にするかを確認します。

準委任契約による伴走と変更対応

準委任契約は、専門家の作業や支援を一定期間受ける形に向いています。現状分析、要件定義、プロジェクト管理、意思決定支援、運用改善などに使われます。

作業時間や体制を基準にするため、優先順位を変えやすい一方で、完成責任や品質基準は別途定める必要があります。

• 契約の分担：要件定義を準委任、開発・検収を請負、稼働後を保守契約に分ける方法があります。
• 契約間の条件：成果物の権利、秘密保持、再委託、個人情報、障害責任、終了時の引き継ぎをそろえます。
• 費用の参考：仕様変更リスクを含む請負は、準委任より1.3〜1.5倍程度高い場合もあります。

これは一般的な参考情報です。工数、品質保証、責任の分け方によって変わるため、固定の係数ではありません。

発注者と委託先の役割分担

発注者と委託先の責任を決めたうえで、学校側も意思決定に加われる体制を整えます。

• 発注者：優先順位、業務ルール、個人情報の利用目的、最終的な受入判断を担います。
• 委託先：技術、設計、開発、テスト、移行支援、操作教育、保守が役割です。
• 学校側の体制：業務責任者、情報セキュリティ責任者、現場代表、意思決定者を置きます。
• 会議運営：頻度、課題管理表、決定期限、変更承認者、エスカレーション先を決めます。
• 複数校の要望：共通要件、設定で吸収する要件、個別対応する要件に分けます。

委託先に任せきりにすると、現場に合わない標準化や、使われない追加機能が増えやすくなります。一方で、明確な決定期限を置いておけば、繁忙期にも判断が遅れにくくなります。

教務システムの費用相場と見積もりの内訳

費用は、学校数、児童生徒・学生数、教職員数によって変わります。機能、帳票、移行データの範囲も費用を左右します。さらに、外部連携、研修、サポートの有無でも差が出ます。統一された公定価格があるわけではありません。

以下の数字は、公開料金と業務システム一般の費用情報を教務システムに当てはめた参考レンジです。初期費用だけでなく、移行・連携・研修・保守を含めた5年間の総額で比べます。

方式別の費用レンジ

導入範囲ごとの参考レンジを把握したうえで、公開料金と推定額を分けて比べます。

• 標準クラウド：1校あたり初期0〜30万円程度、月額2万〜5万円程度が参考です。
• パッケージ導入：複数校で移行・帳票設定・研修を含めると初期100万〜800万円程度です。
• 自治体・法人全体：連携、権限、移行を含めると500万〜3,000万円程度が目安です。
• 独自開発・大規模連携：1,500万〜5,000万円以上となる可能性があります。

School Engineの料金表では、小中学校は1校あたり月額22,000円、高等学校は1校あたり月額44,000円です。初期導入費用はいずれも330,000円です（出典：株式会社システムディ「School Engine」料金表、2026年8月確認）。

EDUCOMはC4thクラウドスタンダードの1校あたり月額38,500円（税込）の例を公開しています。ただし、2023年4月時点の価格で、変更の可能性があります（出典：株式会社EDUCOM「C4thクラウドスタンダード」、2023年）。

独自開発の金額は学校数や要件で変わる推定レンジです（出典：NotebookLM事前Q&Aおよび株式会社ripla「教育機関向けシステム開発の見積相場や費用／コスト／値段について」、2026年）。

見積書の費目の内訳

見積もりは、初期作業、継続費用、契約一式の内訳に分けて確認します。

• 導入作業：要件定義、管理、設計、設定・開発、テスト、データ整備・移行を分けます。
• 導入支援：連携、認証、端末・ネットワーク、研修、マニュアル、稼働後支援が含まれるかを確認します。
• 継続費用：利用料、ユーザー・学校・学生数に応じた従量料金、保守、窓口、バックアップ、監視、追加ストレージの有無と金額。
• 変更対応：帳票、制度改定、連携先の仕様変更への対応費。
• 一式項目：「導入支援一式」などは、作業、回数、担当者、完了条件を尋ねます。

初期費用が安くても、5年間の利用料や移行、研修、追加開発を加えると、総額が高くなる場合があります。逆に、標準機能、保守、更新を含む提案は、総額で有利になることもあります。

5年間のTCOによる比較

5年間のTCO（総所有コスト）は、導入費用と運用費用を合算し、学校側の作業負担も考慮して比べます。

• 費用項目：初期費用に、月額・年額の利用料、保守、移行、追加開発、連携、研修を加えます。
• 運用負担：端末・ネットワーク、障害対応、制度変更、学校側の作業時間も考慮します。
• 比較ケース：「標準機能のみ」「移行・研修込み」「連携込み」「独自帳票込み」で見積もります。
• 契約条件：追加開発単価、最低発注額、有効期限、価格改定、データ返却費を確認します。

システム費用が安くても、二重入力が残れば教職員の負担は続きます。価格差の理由を説明できない提案は、いったん保留にします。

教務システムの委託先選定と見積比較のポイント

委託先は、機能数や知名度だけでなく、学校種別への理解、移行・年度更新の経験、セキュリティ、導入後支援、提案の透明性で比べます。

小中学校・教育委員会向けの統合型校務支援と、大学・専門学校向けの学務システムでは、業務の前提が異なります。そのため、自校に近い規模や制度の実績を確認します。

学校種別と導入規模の実績

導入実績は、校数だけでなく、対象校種や運用規模、自校との近さで評価します。

• 規模と範囲：校種、学校数、利用者数、移行履歴年数、稼働時期、連携システムを確認します。
• 導入後の状況：定着状況、運用差の標準化、障害・制度変更への対応を尋ねます。
• 現場の声：同じ校種の担当者に、導入前後の負荷や問い合わせ対応を聞きます。

株式会社システムディが2025年10月に公開した東京富士大学の事例では、10年以上利用した学務システムからクラウド版Campus Planへ移行しました。ポータルやLMSとの連携によって、業務の属人化軽減と、学修成果を見えるようにすることを目指しています（出典：株式会社システムディ「東京富士大学 Campus Plan導入事例」、2025年10月27日）。

機能の一覧だけでなく、導入前の課題と導入後の変化も確かめます。

移行・研修・保守の体制

教務システムの成否は、稼働日よりも移行と定着で決まります。そのため、委託先の担当範囲、移行方式、研修と稼働初期支援を合わせて評価します。

• 移行作業：抽出、変換、名寄せ、欠損確認、リハーサル、差分移行、検証、旧システム保存の担当を決めます。
• 切り替え計画：移行回数、並行運用の期間、旧システムの停止時期を決めます。
• 研修と支援：管理者に加え、担任、教務、事務、養護、非常勤職員向けに用意します。
• 見積もり項目：マニュアル、短い動画、窓口、初期の常駐・オンライン支援、障害連絡網を含めます。

learningBOXが2025年7月に公開した鹿島教育グループの事例では、出席情報の自動連携により入力作業が約2,900時間削減されたと報告されています（出典：learningBOX「鹿島教育グループ導入事例」、2025年7月24日）。

同じ効果が自校でも出るとは限りません。そのため、現状の入力時間を計測し、目標を設定します。

個人情報と委託先管理

学籍、成績、健康診断、指導記録、家庭環境、保護者連絡は、漏えいした際の影響が大きいため、情報管理と委託先の統制を確認します。

• データ管理：利用目的、保存地域・設備、アクセス担当者の範囲。
• 委託先の統制：再委託先、開発者権限、管理者アカウント、操作ログ、バックアップの扱い。
• 終了時の処理：退職者アカウントの削除、媒体廃棄、契約終了時の削除証明。

個人情報保護委員会は2025年6月、2023年4月から2025年4月までに小中高校・特別支援学校で報告された約450件の漏えい等事案を分析しました。また、紛失や情報共有ツールの操作ミスにも注意を促しています（出典：個人情報保護委員会「学校における個人情報の漏えい等事案を踏まえた個人情報の取扱いに関する留意点」、2025年6月25日）。

さらに、誤送信、帳票持ち出し、権限設定ミス、委託先への連絡手順も評価します。

発注から稼働までの進め方と失敗を防ぐ方法

発注後は、要件定義から設計・設定へ進みます。次に、開発・連携とテストを行います。そのうえで、移行、研修、リハーサルを経て、本番稼働と安定化へ進みます。

4月や学期初めは業務が集中します。そのため、稼働日から逆算して、移行と研修を計画します。

期間の目安は、標準クラウド導入で1〜3か月、移行・帳票設定を含むパッケージ導入で3〜6か月です。複数校や独自連携では6〜12か月、スクラッチ開発では9〜18か月以上です。

テストと移行リハーサルの複数回実施

受入テストと移行リハーサルを設け、業務の流れと本番データの整合性を確かめます。

• 業務テスト：単体・結合に加え受入テストを行い、学籍から履修、出欠、成績、帳票への連携を確認します。
• 例外テスト：権限外の閲覧、入力訂正、連携停止時の再処理、繁忙期相当の操作量を試します。
• 移行リハーサル：初回、データ修正後、本番前に実施し、件数、欠損、重複、氏名、成績合計、単位数、帳票を照合します。

移行結果は、現場の担当者が確認します。あわせて、旧データの保存期間、参照方法、バックアップ、個人情報の削除手順も決めておきます。

稼働初期の支援とKPI

本番直後の混乱に備えて、支援体制と効果を測るKPIをあらかじめ定めておきます。

• 問い合わせ対応：窓口、回答目標、重大障害の連絡先、代替運用、休日・夜間対応、周知方法を決めます。
• 定着支援：初年度の定例会で問い合わせを分類し、マニュアルや画面を改善します。
• 業務KPI：成績処理・年度更新時間、二重入力・帳票訂正・データ不整合の件数を測ります。
• 運用KPI：問い合わせ解決時間、障害復旧時間、利用率を定期的に見ます。
• AI機能：追加する場合は、利用目的、誤判定時の確認者、ログ、説明責任を決め、教員の最終判断を残します。

導入効果を定期的に確かめ、追加開発は、KPIや現場の課題に結びつくものから優先します。

よくある質問

発注では、方式や費用だけでなく、データ移行、契約終了時の扱い、現場定着についても確認します。発注前によく寄せられる質問を、順に取り上げます。

教務システムはパッケージとスクラッチ開発のどちらがよいですか？

一般的な学籍、成績、出欠、帳票は、実績のあるパッケージやSaaSを基盤にすると、導入期間、制度改定、保守の負担を抑えやすくなります。

独自制度や特殊な連携が重要業務に直結する場合は、その部分を設定変更や追加開発で補います。全機能のスクラッチ開発は、長期の保守体制を確保できる場合に検討します。

教務システムの発注費用はどのくらいかかりますか？

標準クラウドは1校あたり初期0〜30万円程度、月額2万〜5万円程度が参考です。移行・帳票設定・研修込みのパッケージは初期100万〜800万円程度です。

複数校や自治体連携では500万〜3,000万円程度、独自開発では1,500万〜5,000万円以上となる可能性があります。いずれも学校数、機能、データ量、連携、保守範囲で変わる推定レンジです。

公開料金があるかどうかにかかわらず、見積もりは5年間のTCOで比べます。

既存のExcelや旧システムのデータは移行できますか？

可否は、旧データの項目と形式、欠損の状態で決まります。重複や保存期間も判断材料になり、文字コードや識別IDも影響します。さらに、旧システムからの出力方法も関わります。

RFPの段階でサンプルデータを渡し、移行対象、名寄せルール、回数、検証方法、旧データの保存方針を確認します。

移行費用は一式にせず、抽出、変換、クレンジング、取込、照合、再移行の項目に分けて示してもらいます。

委託先に個人情報を預けるときの注意点は何ですか？

委託先に個人情報を預けるときは、契約と仕様書に条件を記載します。まず、利用目的、アクセス担当者、保存場所を明確にし、再委託先も確認します。暗号化、認証、操作ログ、バックアップの扱いも定めます。さらに、脆弱性対応、事故時の報告、契約終了時の返却・削除も盛り込みます。

学校側の管理者権限を、委託先に常時持たせるか、作業時だけ付与するかも決めます。そのうえで、文部科学省のガイドラインと設置者の規程を確認し、機能・契約・運用を合わせて安全性を評価します。

まとめ

発注・外注では、学校種別、対象校数、利用者を整理します。そのうえで、業務範囲、標準化する業務、独自要件を洗い出します。方式を比べたうえで、RFPには機能、性能、認証を記載します。さらに、ログと移行、研修、保守、契約終了時のデータ返却も記載します。

発注前に合意しておく確認事項

対象校種・規模、MUST機能、標準化する業務、移行対象、連携先、セキュリティ要件、契約方式、検収条件を文書にまとめます。提案を同じ条件で比べられるようにし、学校側の責任者と意思決定の期限も明確にします。

稼働後まで見据えた委託先選定

稼働後を見据え、費用と支援体制、実地検証の結果を合わせて委託先を評価します。

• 総額：5年間のTCO、制度変更、データ返却まで確認します。
• 支援体制：移行リハーサル、研修、ヘルプデスク、障害対応、年度更新支援を比べます。
• 標準クラウド：初期0〜30万円程度、月額2万〜5万円程度が参考です。
• 移行・研修込み：初期100万〜800万円程度、複数校・自治体連携は500万〜3,000万円程度が参考です。
• 実現性：同じシナリオで複数社を比べ、PoCや移行リハーサルで確かめます。

費用は確定額ではありません。公開価格と自校の見積もりを分けて比べます。

児童生徒・学生の情報は長く扱うため、定着までの伴走体制と契約終了後の移行も見通しておきます。そのうえで、KPIを確認して運用を改善します。

▼全体ガイドの記事
・教務システム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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