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

教務システムの発注・外注は、学校種別と規模を先に定め、標準機能を軸にRFPと比較条件をそろえて委託先を選ぶことが成功への近道です。

教務システムを導入・刷新するときは、製品を選んで終わりではありません。発注形態、要件の整理、契約範囲、費用、データ移行、年度替わりの運用までを一つの計画として設計する必要があります。この記事では、小中高校の校務支援に含まれる教務系機能と、大学・専門学校の学務システムを念頭に、発注・外注を進める具体的な方法を解説します。

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

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

教務システムの発注で最初に決めるのは、製品名や開発言語ではなく、対象範囲と業務上の優先順位です。小中高校では校務支援システムの教務系機能として学籍、成績、出欠、帳票などを扱い、大学・専門学校では学務システムとして履修、単位、進級、卒業判定、学生ポータルなどを扱うことが多くなります。呼び方が違っても、情報を一度入力して複数の業務で安全に使うという目的は共通しています。

まず、対象が小学校・中学校・高等学校・専門学校・大学のどこなのか、単一校なのか複数校なのか、教育委員会や学校法人の本部まで利用するのかを明確にします。同じ「成績管理」でも、小中学校の評定・通知表と大学の履修登録・単位認定では、必要なデータ構造も承認手順も異なります。教員、教務主任、担任、養護教諭、事務職員、学生、保護者、教育委員会などの利用者を洗い出し、誰が入力し、誰が承認し、誰が閲覧するのかを業務ごとに整理します。

この段階で「全校一斉導入」を前提にすると、例外的な履修、年度途中の転入、自治体独自帳票、個別支援記録などが後から追加されやすくなります。代表校や代表学年を一つ選び、通常の成績確定だけでなく、転入、欠席訂正、進級、卒業判定、調査書出力までを業務シナリオにすると、外注先へ伝えるべき範囲が具体化します。

MUSTには、導入初年度から止められない学籍・在籍管理、履修・時間割、出欠、成績、進級・卒業判定、帳票、権限、操作ログを置きます。WANTには、ダッシュボード、高度な分析、AIによる要約、追加の保護者通知、学習eポートフォリオなどを置きます。重要なのは、WANTを削ることではなく、初期導入の必須範囲と将来拡張の境界を合意しておくことです。

業務の改善効果は「紙が減る」だけで測らず、学籍の重複入力数、成績確定にかかる時間、年度更新の所要日数、帳票の訂正件数、問い合わせ件数、移行後のヘルプデスク対応時間などで測定します。これらを発注前にベースラインとして記録しておくと、導入後に外注先と成果を確認しやすくなります。

教務システムの発注形態はどれを選ぶべきですか？

発注形態は、標準パッケージ・SaaSの導入、パッケージを設定変更して使う方式、既存製品との連携開発、独自システムのスクラッチ開発を比較して決めます。多くの学校では、教務の差別化部分だけを追加開発し、学籍や成績などの共通機能は標準機能に合わせる方式が費用と安全性のバランスを取りやすくなります。

標準パッケージやSaaSは、すでに学校現場で使われている学籍、成績、出欠、帳票、保健、連絡などを短期間で導入しやすい方式です。クラウドならサーバーやOSの更新、バックアップの一部をサービス提供者に任せられ、1校単位で始めてから複数校へ展開する計画も立てやすくなります。一方、自治体独自の帳票や特殊な履修規則に標準機能が合わない場合は、運用を変えるのか、設定で吸収するのか、追加開発するのかを先に判断します。

標準機能中心の導入では、製品デモで一般的な画面を見るだけでは足りません。年度更新、成績確定後の訂正、転入・転出、履修取消、帳票の再出力、権限変更、障害時の連絡を実際の操作シナリオで確認します。標準化できる業務を無理にカスタマイズしないことが、将来のアップデート費用やベンダーロックインを抑えるポイントです。

スクラッチ開発は、独自の制度、特殊な帳票、既存の基幹システム、自治体の認証基盤などに合わせて業務を設計できる方式です。学校法人全体のデータモデルを作り替えたい場合や、既存システムにない業務が競争力・教育品質に直結する場合に検討します。ただし、制度変更に合わせた改修、開発担当者の交代、障害対応、脆弱性対策を長期に負担するため、全機能を独自開発する判断には慎重さが必要です。

現実的には、標準パッケージを中核にして、LMS、学生ポータル、認証基盤、学校徴収金、自治体基盤とAPIまたはCSVで連携する構成が有力です。連携を外注する場合は、データ項目、更新頻度、エラー時の再送、個人情報の受け渡し、連携停止時の業務手順までを要件に含めます。「連携できる」という営業説明だけで判断せず、項目一覧とサンプルデータで検証します。

クラウドは、端末とネットワークがあれば場所を選ばず利用しやすく、サーバー調達や更新の負担を抑えられます。オンプレミスは、校内・自治体のネットワーク要件や既存設備に合わせやすい反面、サーバー、バックアップ、災害対策、更新作業を自組織または委託先が担います。プライベートクラウドや閉域網も含め、利用場所、認証、データ所在、障害時の代替手段を比較します。

2025年3月改訂の文部科学省「教育情報セキュリティポリシーに関するガイドライン」では、クラウドサービス利用、情報資産の分類、強固なアクセス制御などが改訂されています。教務システムのRFPでは、二要素認証または多要素認証、最小権限、操作ログ、暗号化、脆弱性対応、バックアップ、復旧目標、委託先の再委託管理を確認項目にします。クラウドだから安全、校内だから安全という単純な決め方は避けます。

RFPと要件整理はどのように進めますか？

RFPは、委託先に価格だけを尋ねる書類ではなく、学校の業務課題、対象範囲、前提条件、期待する成果、提案してほしい内容を同じ条件で伝えるための依頼書です。RFPの粒度が低いまま相見積もりを取ると、A社は移行費込み、B社は開発費のみという比較になり、安い提案を選んだ後に追加費用が膨らみます。

現状把握では、教務主任だけでなく、担任、養護、進路、事務、情報担当、教育委員会などからヒアリングします。学籍をどこで管理し、成績や出欠へどのように転記し、最終的にどの帳票を誰が承認しているかを、業務フローとして描きます。紙台帳、Excel、旧システム、LMS、認証基盤、保護者連絡ツールなどのデータ項目と管理責任者も一覧化します。

特に重要なのが、名寄せと履歴の扱いです。氏名変更、転校、休学、退学、年度をまたぐクラス変更、同姓同名、旧字体などを想定し、学生・児童生徒を識別するIDをどのシステムが原本として持つのかを決めます。移行対象を「直近年度だけ」「在籍者全期間」「卒業生を含む全履歴」のどれにするかで、費用と作業期間が変わります。

機能要件には、学籍、入学・転入・転出、履修、時間割、出欠、遅刻・早退、試験、評定、単位、進級・卒業判定、保健、進路、帳票、保護者・学生への通知を記載します。各機能は「対応できるか」だけでなく、標準機能、設定変更、個別開発、外部連携のどれで実現するかを回答してもらいます。画面数や帳票数だけでなく、年度更新や例外処理の操作回数も確認します。

非機能要件には、利用可能時間、同時接続数、レスポンス、障害時の復旧目標、バックアップ世代、ログ保存期間、認証方式、権限の粒度、データ暗号化、脆弱性診断、保守窓口、サポート時間を含めます。契約終了時のデータ返却形式、移行支援、削除証明、仕様書や設定情報の引き渡しも書面で回答を求めます。これらが抜けると、稼働後の運用費や乗り換え費用を比較できません。

デモでは、営業資料に沿った説明を受けるだけでなく、学校側が用意したシナリオを操作してもらいます。たとえば、4月のクラス編成、年度途中の転入、欠席の訂正、成績の締め、評定の承認、調査書の出力、保護者への通知を一続きで実演します。操作する担当者を複数の学校から招き、入力負荷、画面の分かりやすさ、エラーからの復帰、権限による見え方を確認します。

不確実性が大きい場合は、代表校・代表学年でPoCまたは先行導入を行います。PoCの目的は「製品が動くこと」ではなく、実データに近いサンプルで名寄せ、帳票、連携、権限、ネットワーク、研修時間を検証することです。PoCの成功条件、期間、費用、検証後に本契約へ移る条件を発注前に合意すると、試験がそのまま無期限の追加開発になる事態を避けられます。

教務システムの契約形態と分担を決めるポイント

教務システムでは、要件が固まっていない工程と、完成物を定義できる工程が混在します。そのため、要件定義、設計・開発、データ移行、研修・導入支援、保守・運用を一つの契約にまとめるのか、工程ごとに分けるのかを検討します。契約形態を価格だけで選ばず、変更が起きる場所と責任の所在を対応づけることが重要です。

請負契約は、合意した仕様に基づくシステムや帳票、設計書などの成果物を完成させ、発注者が検収する形に向いています。画面、帳票、API、移行結果、テスト仕様書、操作マニュアルなど、何をもって完成とするかを契約書や仕様書に記載します。検収条件には、重大障害の定義、未解決事項の扱い、受入テストの期間、修正回数、仕様変更の手続きを含めます。

請負で注意したいのは、契約時点で決めた仕様と現場の期待がずれることです。「使いやすくする」「既存と同じにする」などの曖昧な表現は、画面例や業務シナリオに置き換えます。学校制度や帳票が変わった場合、法令・ガイドライン対応を無償アップデートに含めるのか、追加費用とするのかも確認します。

準委任契約は、専門家の作業や支援を一定期間受ける形に向いています。現状分析、要件定義、プロジェクト管理、ユーザー側の意思決定支援、運用改善など、成果物だけでは評価しにくい工程で使われます。作業時間や体制を基準にするため、発注者が優先順位を変えやすい反面、完成責任や品質基準が自動的に決まるわけではありません。

要件定義は準委任、開発と検収は請負、稼働後は保守契約という分け方もあります。準委任と請負を組み合わせる場合は、成果物の権利、秘密保持、再委託、個人情報の取扱い、障害時の責任、契約終了時の引き継ぎを契約間で矛盾なく定めます。一般的な参考情報では、仕様変更リスクを含む請負の方が準委任より1.3〜1.5倍程度高く見積もられる場合もありますが、工数、品質保証、責任分界によって変わるため、固定の係数として扱わないことが大切です。

発注者は、学校としての優先順位、業務ルール、個人情報の利用目的、最終的な受入判断を担います。委託先は、要件を実現する技術、設計、開発、テスト、移行支援、操作教育、保守を担います。ベンダーに丸投げすると、現場に合わない標準化や、誰も使わない追加機能が増えやすくなります。発注者側にも、業務責任者、情報セキュリティ責任者、現場代表、意思決定者を置きます。

プロジェクト会議の頻度、課題管理表の形式、決定期限、変更要求の承認者、エスカレーション先を決めておくと、年度替わりの繁忙期でも判断が遅れにくくなります。複数の学校や部署が関係する場合は、学校ごとの個別要望をそのまま開発項目にせず、共通要件、設定で吸収する要件、個別対応する要件に整理して合意します。

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

教務システムには、学校数、児童生徒・学生数、教職員数、対象機能、帳票数、移行データ、外部連携、研修、サポート範囲によって大きく変わる統一公定価格はありません。したがって、以下の金額は公開料金と業務システム一般の費用情報を教務システムに当てはめた参考レンジです。実際の発注では、初期費用だけでなく、移行・連携・研修・保守を含む5年間の総額で比較します。

1校で標準機能を中心にクラウド導入する場合は、初期費用0〜30万円程度、月額2万〜5万円程度が一つの参考になります。実際に、株式会社システムディのSchool Engine公式料金表では、校務支援が小中学校で1校あたり月額22,000円、高等学校で月額44,000円、初期導入費用が各330,000円と掲載されています（出典: 株式会社システムディ「School Engine」料金表、2026年8月確認）。株式会社EDUCOMも、C4thクラウドスタンダードについて1校あたり月額38,500円（税込）の料金例を公開していますが、同社ページには2023年4月時点の価格で変更の可能性があると明記されています（出典: 株式会社EDUCOM「C4thクラウドスタンダード」、2023年）。

複数校でのパッケージ導入、データ移行、帳票設定、研修を含める場合は初期100万〜800万円程度、自治体や学校法人全体で連携・権限・移行を行う場合は500万〜3,000万円程度が目安です。独自要件のスクラッチ開発や大規模な連携を含める場合は1,500万〜5,000万円以上となる可能性があります。これらは学校数や要件で上下する推定レンジであり、特定の金額を約束するものではありません（出典: NotebookLM事前Q&Aおよび株式会社ripla「教育機関向けシステム開発の見積相場や費用／コスト／値段について」、2026年）。

見積書では、要件定義、プロジェクト管理、画面・帳票設計、設定・開発、テスト、データクレンジング、移行リハーサル、本番移行、外部連携、認証設定、端末・ネットワーク対応、研修、マニュアル、稼働後支援を分けてもらいます。「導入支援一式」「カスタマイズ一式」のような項目は、作業内容、回数、担当者、完了条件を質問します。

ランニング費用には、利用料、ユーザー・学校・学生数に応じた従量料金、保守、ヘルプデスク、バックアップ、監視、追加ストレージ、帳票変更、制度改定対応、連携先の仕様変更対応が含まれるかを確認します。初期費用が安い提案でも、5年間の利用料、移行、研修、追加開発を合算すると高くなる場合があります。逆に初期費用が高い提案でも、標準機能、保守、アップデートが含まれていれば総額で有利なことがあります。

5年間のTCOは、初期費用に、月額・年額の利用料、保守、データ移行、追加開発、連携、研修、端末・ネットワーク、障害対応、制度変更対応を加えて計算します。さらに、学校側の運用時間も考慮します。たとえば、入力の二重管理が残れば、システム費用が安くても教員や事務職員の隠れた負担が続きます。

見積比較では、同じ前提で「標準機能のみ」「移行・研修込み」「連携込み」「独自帳票込み」の複数ケースを出してもらうと、要件と費用の関係が見えます。追加開発の単価、最低発注額、見積有効期限、価格改定の条件、契約終了時のデータ返却費も確認します。価格差の理由を説明できない提案は、安くても高くても保留します。

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

委託先は、機能の多さや知名度だけでなく、学校種別への理解、移行と年度更新の経験、セキュリティ体制、導入後の支援、提案内容の透明性で比較します。小中学校・教育委員会向けの統合型校務支援と、大学・専門学校向けの学務システムでは、似た機能名でも業務の前提が違います。自校と近い規模・制度の導入実績を確認することが重要です。

実績を確認するときは、導入校数だけでなく、対象校種、学校数、利用者数、移行した履歴年数、稼働時期、連携システム、導入後の定着状況を聞きます。複数校・自治体の案件なら、学校ごとの運用差をどのように標準化したのか、障害や制度変更へどう対応したのかを確認します。可能であれば、同じ校種の現場担当者から、導入前後の負荷や問い合わせ対応について話を聞きます。

2025年10月に公開された株式会社システムディの東京富士大学の事例では、10年以上利用した学務システムからクラウド版Campus Planへ移行し、ポータルやLMSの連携で業務の属人化軽減と学修成果の可視化を目指しています（出典: 株式会社システムディ「東京富士大学 Campus Plan導入事例」、2025年10月27日）。このように、製品機能だけでなく、既存業務の課題と導入後の変化を確認できる事例を選びます。

教務システムの成否は、稼働日よりも移行と定着で決まります。委託先が、データの抽出、変換、名寄せ、欠損確認、移行リハーサル、差分移行、検証、旧システムの保存をどこまで担当するかを確認します。年度替わりに一度だけ移行するのか、並行運用を何週間行うのか、旧システムをいつ停止するのかも決めます。

研修は、管理者向け説明会だけでなく、担任、教務、事務、養護、非常勤職員などの役割別に用意します。操作マニュアル、短い動画、問い合わせ窓口、稼働初期の常駐・オンライン支援、障害時の連絡網を見積書に含めます。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や現場の課題に結びつくものから優先します。AI機能を追加する場合も、教育データの利用目的、誤判定時の確認者、ログ、説明責任を先に決め、教員の最終判断を残します。

よくある質問

教務システムの発注では、方式や費用だけでなく、データ移行、契約終了時の扱い、現場の定着まで質問しておくことが大切です。ここでは、発注前に特に相談が多い項目を回答します。

一般的な学籍、成績、出欠、帳票などは、実績のあるパッケージやSaaSを基盤にする方が、導入期間、制度改定、保守の負担を抑えやすくなります。独自制度や特殊な連携が学校の重要な業務に直結する場合は、その部分だけを設定変更や追加開発で補う方法を優先し、全機能のスクラッチ開発は長期の保守体制まで確保できる場合に検討します。

1校の標準クラウド導入なら初期0〜30万円程度、月額2万〜5万円程度が参考になり、移行・帳票設定・研修を含むパッケージ導入は初期100万〜800万円程度、複数校や自治体での連携を含むと500万〜3,000万円程度が目安になります。独自開発では1,500万〜5,000万円以上になる可能性もありますが、いずれも学校数、機能、データ量、連携、保守範囲で変わる推定レンジです。公開料金の有無にかかわらず、5年間のTCOで見積もりを比較します。

移行できるかどうかは、旧データの項目、形式、欠損、重複、保存期間、文字コード、個人を識別するID、旧システムからの出力方法で決まります。RFPの段階でサンプルデータを渡し、移行対象、名寄せルール、移行回数、検証方法、旧データの保存方針を委託先に確認します。移行費用を一式にせず、抽出、変換、クレンジング、取込、照合、再移行に分けることが重要です。

利用目的、アクセスできる担当者、保存場所、再委託先、暗号化、認証、操作ログ、バックアップ、脆弱性対応、事故時の報告、契約終了時の返却・削除を契約と仕様書に記載します。学校側の管理者権限を委託先が常時持つのか、作業時だけ付与するのかも決めます。文部科学省のガイドラインと設置者の規程を確認し、機能・契約・運用の三つを合わせて安全性を評価します。

まとめ

教務システムの発注・外注では、最初に学校種別、対象校数、利用者、業務範囲、標準化できる業務と独自要件を整理します。そのうえで、標準パッケージ・SaaS、連携開発、スクラッチ開発を比較し、RFPには機能要件だけでなく、性能、認証、ログ、移行、研修、保守、契約終了時のデータ返却まで記載します。

発注前は、対象校種・規模、MUST機能、標準化する業務、移行対象、連携先、セキュリティ要件、契約方式、検収条件を文書でそろえます。委託先からの提案を同じ条件で比較できる状態にし、学校側の責任者と意思決定の期限も明確にします。

選定では、初期費用だけでなく、5年間のTCO、移行リハーサル、研修、ヘルプデスク、障害対応、制度変更、データ返却まで確認します。PoCや受入テストで現場適合性を確かめ、導入後はKPIを見ながら追加開発と運用改善の優先順位を見直します。

費用は、1校の標準クラウドなら初期0〜30万円程度・月額2万〜5万円程度、移行や研修を含む導入なら初期100万〜800万円程度、複数校・自治体や独自連携なら500万〜3,000万円程度を参考にできますが、確定額ではありません。公開価格と自校の見積もりを分け、5年間のTCO、年度更新の支援、データ移行の確実性、障害時の対応、現場に定着するまでの伴走体制で委託先を選びます。

最後に、最安値の提案を選ぶのではなく、同じ業務シナリオと前提条件で複数社を比較し、PoCや移行リハーサルで実現性を確かめます。教務システムは学生・児童生徒の情報を長期に扱う基盤であるため、発注時点で導入後の運用と契約終了後の移行まで見通しておくことが、失敗を防ぐ最も実務的な方法です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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