校務支援システム開発の進め方/やり方/流れや方法/手法/工程/手順

校務支援システム開発は、業務とデータの流れの整理、標準機能を軸にした選定、段階的な移行と研修の順に進めます。この順で進めると、現場への定着につながります。

開発の全体像、6つの導入フェーズ、費用と見積もりの確認方法の順に説明します。全体像は下記の完全ガイドもご覧ください。

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

校務支援システム開発の全体像

校務支援システムの対象業務を4領域に分けたハブ図
日々の記録から教育委員会向けの集計まで、扱う範囲が広がります。

校務支援システムは、教職員の日々の事務処理と、教育委員会の集計・管理を支える業務システムです。

成績処理だけに対象を絞ると、学籍や出欠、保健、保護者連絡との二重入力が残り、期待した効果が出にくくなります。

導入前に、発注側と開発会社で利用者と業務範囲を定め、どの業務を共通化するかを合意しておきます。そのうえで、画面の数よりも、データが業務間をどう流れるかを確認することが大切です。

対象になる主な業務とデータ

対象業務は、教職員の日々の校務から教育委員会向けの集計まで広がり、大きく4つの領域に分かれます。

  • 児童生徒情報:名簿、学籍、進級進学。
  • 学習・生活記録:出欠、遅刻・早退、成績・評価、通知表、指導要録、調査書。
  • 時間割・健康・指導:週案、授業時数、健康診断、保健室来室、生徒指導記録。
  • 校務・組織連携:予定共有、校務文書、徴収金、保護者連絡、教育委員会向け統計・帳票との連携。

年度初めには、学齢簿から情報を取り込み、担任や学級を更新します。そのうえで、出欠と成績を登録し、通知表や指導要録を出力するまでの流れを、一続きで確認します。

データの受け渡しも、この業務シナリオに沿って確認します。学校ごとのExcel再入力が残る場合、導入後も転記ミスと作業時間が発生します。そのため、二重入力を防ぐ連携方法やCSV入出力も要件に含めます。

標準化と学校ごとの柔軟性のバランス

紙帳票やExcelを、すべて同じ形で再現しようとすると、学校ごとの例外処理が増え、カスタマイズ費用と保守の負担が膨らみます。

  • 標準化:紙帳票やExcelをそのまま再現せず、共通業務を標準機能に合わせる方針。
  • 個別対応:地域や校種で差が必要な帳票に絞った追加。
  • 追加判断:標準化を先に合意し、特別な帳票は必要性と費用負担を確認してから追加すると、導入範囲を広げやすくなります。

文部科学省の「次世代の校務DXガイドブック」では、長崎県の共同調達事例が紹介されています。その事例は、3市町村・114校で標準機能と帳票を原則として導入したものです(出典:文部科学省「次世代の校務DXガイドブック」、2025年)。

導入する側は、利用者の要望を聞きながらも、すべてを個別仕様にしない判断が必要です。

ポイント

対象の業務範囲と、どの業務を共通化するかを導入前に利用者と合意できているかが判断の目安です。データが業務間をどう流れるかも、同じ基準で確かめておく必要があります。

校務支援システム開発の進め方(6フェーズ)

校務支援システムのテストと受入確認に関する4つの観点を並べた図
通常業務と例外処理の両方を押さえる構成です。

開発・導入は6つのフェーズで進みます。最初に要件を整理し、製品・開発会社を選定してから、設計開発に入ります。その後、テストを経て稼働し、定着へと進みます。

次の段階に必要な情報は、前倒しで確認しておきます。年度切替、異動、入試、通知表作成の時期は作業が集中するため、製品は通常月のデモだけで決めず、繁忙期の業務シナリオで検証します。

フェーズ1:要件整理と現状把握

要件整理では、役割ごとのヒアリングを行い、要件に優先度を付けます。その際は、「成績管理」のような業務を担当者と作業まで分解し、必須の要件とそうでない要件を分けておきます。

  • ヒアリング対象:教育委員会、校長・教頭、担任、養護教諭、事務職員、ICT支援員など。
  • 現状確認:ツール・紙帳票、入力・承認者、データ受渡し、年度更新、例外処理、困る時間帯。
  • 業務の具体化:「成績管理」を、評価確定から通知表出力までの担当者と作業に分解します。
  • MUST:法令・必須帳票、個人情報保護、年度更新、認証・権限。
  • SHOULD・WANT:保護者連絡や学習系連携はSHOULD、分析機能はWANTにします。

業務フローに落とし込むと、必要な機能と権限がはっきりします。さらに、要件の優先度を分けておくと、予算と納期を守りやすくなります。

成果物は、業務、データ項目、帳票、連携、権限の各一覧です。加えて、非機能要件と受入条件も成果物に含めます。これらは、見積もりと受入確認の基準としても使います。

フェーズ2:製品・開発会社の選定

選定では、機能の数よりも、校種、学校数、教職員数、既存システム、ネットワーク、標準化方針への適合度を見ます。そのうえで、自組織の条件と運用に合うかを確認します。

  • パッケージ・SaaS:初期費用と更新の負担を抑えやすく、制度改定への対応も期待できます。
  • スクラッチ開発:柔軟に作れる一方、費用・期間・将来保守の責任が大きくなります。
  • 組み合わせ:校務の中核に標準製品を使い、独自連携だけを追加開発する構成。

なお、パッケージやSaaSでは、独自帳票や特殊な運用を標準機能に合わせる必要があります。導入する側は、自組織がどこまでの運用変更を受け入れられるかを見極めます。

提案依頼書には、対象校、利用者数、移行対象データ、必須帳票を記載します。加えて、API・CSV連携、認証、バックアップ、監査ログの条件も示します。障害連絡、研修、データ返却条件も明記しておきます。

デモでは、名簿登録から通知表出力まで操作し、現場の担当者に評価してもらいます。実績は、学校数だけでなく、同じ校種や規模での稼働年数も確認します。

問い合わせ件数や年度更新の支援方法も確認すると、導入後のサポートを比べられます。さらに、各社に同じ業務シナリオを示して、提案を比較します。

フェーズ3:設計・開発・データ移行準備

設計とデータ移行の準備では、権限設定からリハーサルまでを並行して具体化します。

  • 権限設計:校長・教頭、担任、養護教諭、事務職員、教育委員会管理者ごとに閲覧・更新範囲を定めます。
  • 組織変更:異動、兼務、非常勤職員のアカウント、退職者の停止、代理入力に対応します。
  • 移行準備:旧システムやExcelの項目を対応付け、重複や表記ゆれを整理します。
  • 移行確認:帳票、権限ごとの表示、年度更新後の状態をリハーサルで確かめます。

旧データでは、氏名、学年、学級、在籍状態、保健情報、過去成績について、対象年度と保存期間を決めておきます。

リハーサルは設計と並行して始め、本番直前の修正と再移行に使える時間を確保します。確認では、件数だけでなく、表示や更新後の状態も見ます。

フェーズ4:テストと受入確認

受入確認では、機能だけでなく、業務で実際に使えるかを段階的に検証します。

  • テスト範囲:業務シナリオ、連携、権限、性能・障害復旧、脆弱性・セキュリティ、移行データ。
  • 例外シナリオ:学級編成、転校、進級、卒業、年度末の成績確定、通知表の再発行。
  • 受入条件:担当者が手順どおりに正しい帳票を出せること。
  • 稼働判定:不具合と改善要望を分け、責任者と期限を定めます。

代表校や先行利用者によるパイロットでは、操作時間、入力ミス、問い合わせを記録します。あわせて、通常業務と例外処理の両方を検証します。

重大な不具合、回避策が必要な不具合、次期改善の要望を分けておくと、稼働を判断するうえで必要な対応が見えてきます。

フェーズ5:稼働と初期運用

稼働方式と初期運用の要点は、自治体の規模や切替時期に合わせて決めておきます。

  • 導入方法:全校一斉、先行校からの段階導入、機能別の段階導入から選びます。
  • 先行校展開:学校数が多い自治体では、先行校で標準手順と問い合わせ対応を固めてから展開すると安全です。
  • 一斉稼働準備:移行凍結日、旧環境の参照期間、訂正方法、障害時の代替手段を定めます。
  • 稼働後対応:窓口、優先度、回答期限、ベンダーへの連絡経路を明確にします。
  • 状況確認:月次でログイン率、入力完了率、帳票作成時間、問い合わせ、未解決課題を見ます。

年度切替で全校が同時に稼働する場合は、移行凍結日や切替後の訂正方法を事前に決めておきます。初月に出た質問は、操作マニュアルや追加研修に反映します。そのうえで、月次の数値と問い合わせから、現場が困っている機能を把握します。

フェーズ6:定着と継続改善

異動してくる教職員が毎年学べる仕組みを整え、稼働後の改善方法も決めておきます。

  • 継続研修:5分程度の操作動画、年度初めのチェックリスト、役割別マニュアルを用意します。
  • 相談体制:FAQと校内の相談担当者を設け、詳しい教員への問い合わせ集中を避けます。
  • 運用確認:管理職に入力状況や情報共有を確認するルールを伝えます。
  • 定期見直し:半年または年度ごとに、利用状況、カスタマイズ、データ品質、セキュリティログを点検します。
  • 継続管理:半年または年度ごとに、バックアップ復元、契約更新条件、データ返却を確認します。

制度改定や、帳票・端末・ネットワークの変更、外部サービスの追加があると、稼働後も要件は変わります。変化があれば、要件も更新します。

データは、標準形式で出力できるか、解約時にどの形式でいつ返却されるかを確認しておきます。

ポイント

要件の優先度、繁忙期の業務シナリオでの検証、移行と研修の計画が、どのフェーズでも揃っているかが判断の目安になります。

校務支援システム開発の費用相場と内訳

校務支援システムの見積もり費用を4領域に整理したパネル図
導入時だけでなく、運用と契約終了時まで費用範囲を確認できます。

費用は、単校の標準クラウド、複数校の共同利用、自治体全体の構築・移行・運用で大きく異なります。公開価格は自治体案件にそのまま当てはめにくいため、比較できるレンジと公的調達事例を分けて見ます。

2026年時点の一般的な目安では、クラウド型は初期0〜50万円程度、月額2〜10万円程度です。一方、オンプレミス型は初期100〜300万円程度、年間保守10〜50万円程度で、対象範囲やオプションによって変動します。

単校の標準クラウド導入にかかる費用

単校の標準クラウド費用は、初期費用と継続費用を分けて比べます。

  • 標準クラウドの目安:既製サービスは初期設定、アカウント登録、データ登録支援、操作研修を含め、初期0〜50万円程度、月額2〜10万円程度です。
  • 公開価格例:School Engineは小中高の初期導入費33万円(税込)です。
  • 総額比較:月額だけでなく3〜5年で、初期設定・利用料、年度更新支援・問い合わせ対応、データ移行、研修、追加アカウント、保護者連絡を比べます。
  • 別予算:ネットワーク改修や端末更新はシステム費用から分けます。

School Engineは、学校種別によって月額料金が異なります(出典:株式会社システムディ「School Engine」公式料金情報、2026年確認)。

これは製品価格の一例で、連携、追加帳票、現地支援を含むとは限りません。必要なオプションが多いと、表示価格より高くなる場合があります。

複数校・自治体全体の構築費用

複数校や自治体全体の場合は、導入費と利用費の対象範囲を分けて比べます。

  • 導入作業:要件定義、環境構築、認証・ネットワーク、データ移行、登録支援・研修、運用設計が加わります。
  • 共同調達例:長崎県の3市町村・114校は基盤を初期約1,600万円で構築しました。
  • 単独導入の参考値:1校あたり初期10〜20万円、月額4万円程度の当時の目安があります。
  • 自治体公募例:松阪市の公募では、導入費上限991万1,000円、利用費上限7,008万9,000円(税込)です。

長崎県の事例は、文部科学省の「次世代の校務DXガイドブック」に掲載されています。市町単独導入時の参考値も、同資料によるものです(出典:文部科学省「次世代の校務DXガイドブック」、2025年)。

松阪市の公募は2025年に行われ、小中学校向けのSaaS型です。利用費の対象は2026〜2028年度です。

この数字は、複数校を対象とした約3年契約の公募上限で、単校の相場とは別に見る必要があります。出典は、松阪市教育委員会「松阪市小中学校統合型校務支援システム構築及び保守管理」公募資料(2025年)です。

見積もりに含めるべき費用項目

見積もりでは、導入作業、運用支援、契約条件を分けて範囲を確認します。

  • 導入作業:要件整理・プロジェクト管理、ライセンスまたは利用料、初期設定、画面・帳票追加、外部連携、データクレンジング・移行。
  • 環境・品質:ネットワーク・認証、テスト、研修、稼働立会い。
  • 運用支援:ヘルプデスク、保守、制度改定対応、バックアップ、監査対応を含めます。
  • 契約条件:更新時の利用料、最低利用期間、解約時の返却、追加開発単価を確認します。

見積書は「一式」とせず、対象校数、利用者数、作業回数、支援時間、成果物を記載してもらいます。

加えて、データ移行の対象年度、旧システムの参照期間、年度更新支援、追加帳票、現地研修、障害時の代替運用も確認します。そのうえで、学校側の作業は金額と時間に換算し、導入後の実負担を比べます。

ポイント

単校の公開価格と複数校の公募上限は分けて見て、初期費用、月額、移行、研修、保守、別予算を同じ範囲で比べられているかが判断の目安です。

校務支援システムの見積もりを取るポイント

導入単位、データの状態、帳票数、連携方式、研修方法によって見積もりは変わります。現状と目標を資料にまとめ、各社に同じ条件で提案を依頼します。

価格表だけでなく、業務がどう変わるか、誰が何を担当するかも確認します。条件をそろえておくと、提案の違いを判断できます。

RFPに入れる要件チェックリスト

RFPには、業務の内容や規模、システム要件を記載します。見積もりの前提をそろえるため、次の事項を確認します。

  • 対象範囲:学校種別・校数、児童生徒数、教職員数、利用者の役割を記載します。
  • 機能・移行:必須機能、標準・独自帳票、連携先、移行年度、稼働希望時期を示します。
  • クラウド・復旧:保存場所、可用性、バックアップ、障害復旧目標を確認します。
  • セキュリティ:アクセス制御、多要素認証、監査ログ、脆弱性対応、委託先管理、事故報告を定めます。

文部科学省のガイドライン(2025年3月版)は、クラウド利用、情報資産の分類、アクセス制御を扱います。SaaS型パブリッククラウドの利用も、その対象です。この内容は同ガイドラインに記載されています(出典:文部科学省「教育情報セキュリティポリシーに関するガイドライン」、2025年)。

ISMSの取得状況に加えて、クラウド事業者との責任分界、管理者権限、ログの保管期間、バックアップ復元テスト、事故時の連絡順を具体的に確認します。

複数社を同じ条件で比較する方法

機能、費用、工程、提供会社の役割を、同じ条件で比べます。

  • 機能差:標準機能、設定、追加開発のどれで対応するかを分けます。
  • 費用:初期・月額・保守、移行、研修、連携・追加帳票・ネットワークを並べます。
  • 工程:要件整理、移行リハーサル、先行校、受入テスト、年度切替、稼働後支援を確認します。
  • 提供体制:製品会社と認証・ネットワーク・データ連携を設計するSI会社の役割を分けます。

総額は3年または5年で算出します。学校数が少なく標準機能が中心であれば、公開価格と導入支援が明確なサービスが候補になります。

県域や大規模な自治体では、共同調達、ゼロトラスト型ネットワーク、既存資産との連携、ヘルプデスク、全校研修を一括で設計できる会社を比べます。

失敗しやすいリスクと対策

導入時と契約後に起こりやすいリスクは、要件・移行・運用・契約の観点ごとに対策を示します。

  • 要件の偏り:異なる校種・役割の利用者を要件整理と受入テストに参加させます。
  • 過剰な個別化:標準機能を基本とし、追加要望は効果、費用、保守、共通化で優先します。
  • 移行・研修不足:移行データを検証し、研修を一度で終わらせない計画にします。
  • 障害・制度変更:サポート時間、休日対応、復旧目標、復元手順、連絡窓口を契約に記載します。
  • 返却条件の未確認:クラウドの責任範囲と契約終了時のデータ返却を確認します。

クラウドを使う場合も、セキュリティを事業者任せにせず、教育委員会とベンダーの責任範囲を確認します。さらに、契約更新の前には、利用率と改善効果を見直し、必要に応じて機能を減らします。

ポイント

各社の見積もりを同じ業務シナリオと同じ前提で比べられているかが判断の目安です。前提がそろわないまま金額だけを比べると、提案の違いを読み違えやすくなります。

校務支援システム開発についてよくある質問

導入の計画では、費用、期間、クラウドの安全性、既存データの扱いがよく問われます。判断が分かれやすい点を、質問の形で整理します。

校務支援システムは1校あたりいくらかかりますか?

標準的なクラウド型は、初期0〜50万円程度、月額2〜10万円程度が比較の目安です。ただし、追加費用は、データ移行、独自帳票、連携、研修、ネットワークによって変わります。

システムディのSchool Engineは初期導入費用33万円(税込)を公開しています。製品単体の価格で、すべての導入案件にそのまま当てはまる金額ではありません。

クラウドとオンプレミスはどちらを選ぶべきですか?

サーバー更新、バックアップ、制度改定の負担を抑え、複数校で標準化するならクラウドが有力です。一方、既存設備や自治体独自のネットワーク要件を活かす場合は、オンプレミスやプライベートクラウドも候補です。

判断は、データ保存、アクセス制御、障害復旧、責任分界、将来の移行性を同じ条件で比べたうえで行います。

開発・導入にはどのくらいの期間が必要ですか?

標準クラウドを単校に導入する場合、要件確認、設定、データ登録、研修を含めて2〜6か月程度が一つの目安です。複数校の共同調達は、6〜12か月程度です。

独自帳票、複数システム連携、大規模なデータ移行を含む開発は1年以上になる場合があります。いずれも一般的な工程から見た目安で、年度切替、調達手続き、セキュリティ審査によって前後します。

既存の学齢簿やExcelのデータは移行できますか?

CSVなど標準形式で出力できれば移行できる可能性は高いですが、項目名、コード、氏名表記、在籍状態、過去年度の保存範囲は確認しておく必要があります。

移行前にデータを整理し、テスト移行と帳票確認を行います。さらに、見積もりには、対象年度、件数、変換作業、検証回数、旧システムの参照期間を明記してもらいます。

まとめ:現場定着から逆算する校務支援システム開発の進め方

業務とデータの流れの整理

開発は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズで進みます。そのうえで、学校ごとの業務とデータの流れを把握し、MUSTとWANTを分けます。

連携や独自帳票の範囲は、標準機能を基本に決めます。単校の公開価格と自治体の調達費は分けて、移行、研修、保守を含めた3〜5年の総保有コストで比べます。

導入後の定着までを含めた契約と計画

選定時の確認事項と導入後の運用体制を、次のとおり整理します。

  • 選定時の確認:年度更新、異動、例外処理、受入テスト、障害対応・セキュリティ、データポータビリティを確認します。
  • 参考情報:文部科学省のガイドラインや共同調達事例を参考にします。
  • 運用方針:教育委員会と学校が同じ運用方針を持てるようにします。
  • 継続改善:導入後も研修と改善を続け、校務の負担を減らします。
  • 目標:必要な人が必要な情報を安全に使える状態を目指し、製品や開発会社の選定基準にします。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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