スクール管理システムの発注は、業務を整理して発注形態を選び、要件・契約・費用・データ移行の条件を揃えて複数社に依頼し、見積と導入後の範囲を比べる流れで進めます。
業務ルールは教室ごとに異なるため、機能一覧だけで委託先を決めると、導入後に追加費用が発生しやすくなります。
▼全体ガイドの記事
・スクール管理システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
スクール管理システムの発注・外注で最初に決める事項
発注前に決めるべきなのは、画面デザインや製品名ではなく、導入の対象となる業務と成功の条件です。スクール管理システムは、生徒や保護者、講師、講座のデータを一つにつなぐ業務基盤です。予約や出欠、請求、連絡の業務も、このデータをもとに回ります。
まず、何をひとつにまとめ、誰の作業をどれだけ減らしたいのかを言葉にしておくと、発注形態と見積の妥当性を判断しやすくなります。
目的は機能導入ではなく業務改善
まず、直近1か月の業務を、入会から退会までの流れに沿って記録します。入会・体験、在籍変更、授業予約など、現場で繰り返している作業を一つずつ書き出すのが出発点です。たとえば、月謝の入金消込に毎月何時間かかっているか、振替処理が何件あるか、同じ情報を何人が何回入力しているかを数えます。
削減したい時間やミスを数字で示せると、開発費の安さだけでなく、投資対効果で比べられます。また、GXOの2026年記事でも、教室数が増えるほどExcelや電話による管理負担が膨らむ課題が示されています。
学校向けではなくスクール事業者向けの定義
学習塾や習い事教室が重視するのは、学籍や校務の管理よりも、入会、月謝、予約の業務です。出欠と振替、保護者連絡も大切にされ、さらに継続率と校舎別売上も見られます。
学校法人向けの校務支援システムを参考にする場合も、そのまま要件に移すのではなく、自社の収益と現場運用に必要なデータに置き換えて考えます。
未成年者の個人情報や成績を扱う点は共通しますが、利用者の権限や契約主体、保護者との連絡方法は異なります。そのため、対象業態をRFPの冒頭に明記し、前提を揃えておきます。
発注形態の選び方（SaaS・パッケージ・カスタム開発）
発注形態は、現在の業務を既製の製品に合わせられるか、独自のルールをシステムに反映する必要があるかで決まります。
スクラッチ開発に最初から決めるのではなく、既製サービスのデモを見て、要件との適合表を作ります。そのうえで、差分が本当に事業上必要かを確かめます。
発注形態の違いは、校舎数と業務ルールをもとに、次の基準で比べます。
- SaaS：1〜3校舎で標準機能だけで足りる場合に候補になります。
- パッケージ・ハイブリッド：既製機能を生かしたうえで、帳票や外部連携を調整する場合に適します。
- カスタム開発：独自の請求、多校舎運営、基幹連携が競争力に直結する場合に検討します。
SaaSを選ぶケース
SaaSは、契約後にすぐ使い始められ、サーバー運用やアップデートを自社で抱えずに済む点が利点です。生徒管理や予約、出欠などの基本業務が標準機能で足りる場合は、開発会社へ大きく発注するより、導入支援や初期設定の範囲を見積もってもらう方法が現実的です。
一方で、生徒数課金や校舎数課金、オプションが増えると、月額が変わります。決済手数料や通知料も加わるため、100人・500人・1,000人の利用条件で5年間の総額を確認します。
パッケージやハイブリッドを選ぶケース
パッケージは、業務に必要な基盤があらかじめ用意されており、初期設定や追加ユニットで自社の業務に合わせる方式です。予約や請求は既製機能を使い、会計・決済系、LINE、入退室端末だけをAPIやCSVでつなぐハイブリッドにすると、開発範囲を抑えながら業務の差分に対応できます。
株式会社大和コンピューターのPlatinum Schoolは、受講者規模別のプランとオプションを公開料金で示しています。既製部分と追加機能を切り分けて考える際の比較材料になります。
カスタム開発を選ぶケース
複数コースの合算請求や兄弟割引、日割りが標準サービスの制約になる場合は、カスタム開発を検討します。さらに、休会・復帰や独自の振替期限、フランチャイズ本部の集計、既存基幹システムとの連携が必要な場合も、カスタム開発を比べる対象になります。
ただし、要望をすべて盛り込むと、予算も納期も膨らみます。最初のリリースでは、生徒・契約・予約を中核にし、出欠と請求もその範囲に含めます。AI授業報告や高度な分析は第2段階へ回し、段階的に発注します。
RFPと要件整理による発注内容の具体化
RFPは、開発会社やサービス提供会社に同じ条件で提案と見積を依頼するための文書です。
分厚い仕様書を完成させる必要はありませんが、目的と対象業態は揃えておきます。利用者と業務フロー、必須要件と希望要件も、各社に同じ形で示します。連携や移行、セキュリティ、納期、予算の考え方も、同じ前提で見積もれるように整えます。
口頭で伝えた要望を各社が別々に解釈すると、安い見積と高い見積が、違う範囲を計算しているだけになります。そのため、比べられる単位に揃えておくことが大切です。
例外までを含む業務フロー
要件整理では、通常処理だけでなく例外処理も書き出します。たとえば「欠席を登録する」だけでなく、当日欠席、無断欠席、振替権利の発生まで定義します。振替期限、振替先の定員、キャンセル料も含めます。
「月謝を請求する」場合も、同じように例外を整理します。複数コースや兄弟割引、日割り、教材費の扱いが対象です。休会や返金、未収金、決済失敗後の再請求も確かめます。
業務担当者や校舎責任者、講師が、どの画面で何をするかを線でつなぎます。保護者や本部経理も並べると、必要な権限が見えてきます。
必須・優先・将来の区分
要件は、開発初日に必要な「必須」、初期導入の効果を高める「優先」、将来の拡張候補の「将来」に分けます。必須要件には、生徒・世帯情報、契約・受講、講座・クラスを置きます。予約・出欠、請求・決済に加えて、保護者への通知、権限と監査ログも必須に含めます。
将来要件には、成績分析や動画教材、AIによる授業報告、需要予測などを置きます。初回見積に含めるか、別フェーズの参考見積にするかを明示します。受講者数や校舎数、同時アクセス数、通知件数などの前提も、数字で記載します。
RFPに添付する資料
提案の前提を揃えるため、手元にある次の資料をRFPへ添付します。
- 現行のExcelの項目、帳票、予約カレンダー
- 月謝計算のルール、通知文面、権限一覧
- 外部サービスの契約情報と、データ件数の概算
既存データを移行する場合は、列名の揺れや重複を確かめます。退会者の扱い、保護者と生徒の紐付け、保存期間も確認が必要です。
CSVやAPIでデータを取り出せるか、解約時に全データを返却できるかも、RFPの質問項目に入れておくと、ベンダーロックインを避けやすくなります。
契約形態と発注範囲の分け方とリスク管理
発注の方法は、要件定義、設計・開発、テスト・移行、運用保守を一つの契約にまとめる方法と、フェーズごとに契約を分ける方法の2つがあります。
要件が固まらないまま全工程を一括で発注すると、追加変更の金額や責任範囲があいまいになりがちです。
最初は要件定義を準委任で依頼し、仕様と優先順位が固まってから開発部分を請負で発注するなど、成果物と不確実性に合わせて契約を分けます。
請負契約が向く範囲
請負契約は、合意した機能や成果物を完成させる範囲に向いています。たとえば、画面一覧や機能仕様、テスト項目、納品物が明確であれば、費用と成果の関係を管理しやすくなります。検収条件や納期も比較的はっきりしていれば、なお安心して進められます。
ただし、契約後に「やはり別の振替ルールにしたい」「月謝の締め日を変更したい」となると、変更管理が必要です。変更の受付方法や影響調査、追加見積を契約書や別紙に定めます。承認者と納期の扱いも、あらかじめ決めておきます。
準委任契約が向く範囲
準委任契約は、要件整理や業務ヒアリング、技術検証などのように、作業や専門知識の提供を委託する範囲に向いています。継続的な改善やアジャイル開発も、この範囲に当たります。要件が変わりやすい新規事業や、既存サービスとの連携方式を検証する段階では、作業時間や体制を管理しやすい方法です。
一方で、完成責任や品質保証は自動的には決まりません。そのため、作業内容や担当者、レビュー方法を別途明確にします。成果物、月次報告、終了条件も、契約の中で定めておきます。
契約書で確認する項目
契約時には、開発中と終了時の双方で責任があいまいにならないよう、次の項目を確認します。
- 知的財産権、ソースコードの帰属、第三者サービスの利用
- 再委託先、秘密保持、個人情報の取扱い
- 障害時の連絡、バックアップ、脆弱性対応、保守時間
- 損害賠償の上限と解約時のデータ返却
個人情報を含む受講履歴や成績を扱う場合は、契約の中身をさらに具体化します。委託先のアクセス権限やログ保存、削除依頼への対応を定め、海外クラウドの利用や事故発生時の報告期限まで決めます。
IPAのITサービス委託のセキュリティ対策でも、契約と第三者検証によって責任を担保する考え方が示されています。
スクール管理システムの費用相場と見積の内訳
費用は、利用人数や校舎数、請求ルールによって変わります。外部連携や権限、データ移行、保守範囲も、金額を左右します。
2026年時点の公開情報では、既製SaaSは初期費用0〜20万円程度、月額2万〜10万円程度です。カスタム開発の基本型は200万〜400万円程度、連携や多校舎管理を含む統合型は400万〜800万円程度という参考レンジがあります（出典: GXO「学習塾・スクール管理システム開発の費用相場」、2026年）。これは市場全体の統計ではなく、事業者が公開する目安です。
既製SaaSの料金の読み方
既製SaaSは、初期設定費と月額基本料に分けて確認します。そのうえで、受講者数や校舎数に応じた従量料金や追加ユーザーに加え、決済手数料や、SMS・LINEなどの通知料も見ていきます。
たとえばPlatinum Schoolは、公式料金ページで在籍生徒数10〜100人向けのライトプランを月額1万円から示しています。100〜1,000人向けのベーシックプランは月額2万4,000円から、1,000人以上向けのヘビープランは月額6万2,000円からです（出典: 株式会社大和コンピューター「Platinum School 料金プラン」、2026年閲覧）。
また、株式会社GMOメディアのコエテコマネージャー byGMOも、生徒1人あたり月額100円からの料金体系を案内しています（出典: GMOメディア、2026年閲覧）。公開料金は比較の材料にとどまるため、自社のオプションや税、決済費を含めた総額は、別に計算します。
カスタム開発の内訳
カスタム開発では、要件定義や設計、実装、テストに費用がかかります。さらに、データ移行や操作教育、リリース支援、保守も費用の内訳になります。
概算の考え方として、要件定義は10〜15%、設計は15〜20%、実装は40〜50%という区分があります。テスト・移行・教育は15〜25%程度です。この区分に沿うと、予算がどこに配分されているかを把握しやすくなります。
決済、SMS、LINEなどの連携費や、クラウド、端末の費用は、開発費に含まれない場合があります。脆弱性診断やデータクレンジング、運用保守も、別になることがあります。そのため、初期費用と月額費用を分けて記載してもらいます。
5年間の総保有コストによる比較
発注先の提案を比べるときは、初期費用だけでなく、5年間の総保有コストで考えます。SaaSは月額が積み上がるため、利用者の増加やオプションの追加で、総額が上がる可能性があります。
カスタム開発は初期費用が大きい一方で、保守やクラウドの費用が続きます。追加開発やセキュリティ対応も、継続して発生します。小規模のSaaSを月額5万円で使う場合、単純計算の5年分は300万円ですが、決済手数料や初期支援は別です。
カスタム開発の提案も、同じ条件で、開発費と保守費、連携費、移行費を加えて比べます。数字は、前提条件とセットで示してもらうことが大切です。
委託先の選定と見積比較のポイント
委託先は、スクール業務への理解や要件定義の進め方、開発後の保守を確認して選びます。知名度や見積の安さだけでなく、データとセキュリティの扱いも見ておきます。
候補は3〜5社程度に絞り、同じRFP、同じ質疑回答、同じ前提条件で提案を受けます。提案書の機能数よりも、現場の例外業務をどこまで理解しているか、未確定事項と追加費用の条件を正直に示しているかを重視します。
業態と類似案件の確認
候補会社には、自社に近い業態の導入事例を確認します。学習塾や英会話、音楽・スポーツ、研修などが例になります。
事例の数だけでなく、受講者数や校舎数、利用者の種類を質問します。さらに、月謝や予約の複雑さ、移行データ量、稼働後の保守体制も聞いておきます。
可能であれば、経営者向けの画面だけでなく、受付担当、講師、保護者が使う画面をデモしてもらいます。保護者がスマートフォンで欠席や振替を終えられるか、講師の入力が増えないかを確かめることは、定着率に直結します。
見積書の同じ項目への分解
見積書は、総額だけでなく、要件定義や設計、機能ごとの実装、連携の費用に分解します。テストや移行、教育の費用も、同じ項目に分けます。保守、クラウド、決済・通知の費用も、分けて見ます。
「一式」と書かれた項目が多い場合は、含まれる成果物と作業時間、前提条件、除外項目を質問します。A社は決済連携を含み、B社は別料金という違いがあれば、総額の条件を揃えて比較します。
工数や人月、単価、期間を確認します。担当体制も見たうえで、安い理由が要件の抜けになっていないかを確かめます。
セキュリティとデータ返却の評価
未成年者の氏名や保護者連絡先、出欠、成績、決済情報を扱うため、SSL対応の有無だけでなく、セキュリティ全体で判断します。権限分離や管理者の多要素認証、操作ログ、バックアップの状態を確認します。脆弱性診断やパッチ適用の期限、障害時の復旧目標、委託先と再委託先も確かめます。
文部科学省は2025年3月に、教育情報セキュリティポリシーに関するガイドラインを公表しています。教育データ標準でも、データ内容や技術規格の標準化が進められています。学校法人でなくても、教育データを扱うシステムを発注する際は、将来連携できるデータ構造と、どこまでを誰が受け持つかを意識します。
IPAの委託事例では、OSSをカスタマイズした予約システムで、URLの変更により他人の受講状況や成績が見える脆弱性と、パッチ未適用の問題が取り上げられています（出典: IPA「プラクティス5-3」、2026年閲覧）。価格や開発実績と並べて、脆弱性が見つかったときの修正責任や、第三者検証の有無、解約時のデータ取得方法を契約前に確認しておきます。
発注後の進め方と失敗を防ぐポイント
発注先が決まった後も、任せきりにすると現場とシステムのずれが広がります。発注者側には責任者を置き、要件の決定者と現場代表を明確にします。経理や個人情報管理の担当も、あわせて決めておきます。
要件定義や設計、実装、テストといった節目ごとに承認します。移行、教育、稼働判定の節目も、承認の対象です。変更は記録し、予算と納期への影響を確認します。
1校舎・1業務からのPoC
全校舎へ一度に広げず、1校舎または1クラスで予約や出欠、保護者連絡を試します。導入の前後では、受付の入力時間や欠席・振替の処理時間、月謝確認時間を計ります。電話件数、保護者の利用率、講師の入力率も計ります。
機能が動くかだけでなく、現場が使い続けられるかも判断材料にします。NotebookLMのリサーチでも、限定した範囲で試し、費用対効果と現場の反応を確かめてから本格導入する進め方が示されています。
移行・教育・稼働後支援の決め方
稼働直前にExcelを渡すと、表記ゆれや重複が残ったまま、現場の混乱につながります。そのため、移行対象やデータクレンジングの担当、テスト移行の回数を先に決めます。旧システムを参照できる期間や、退会者データの扱いも決めておきます。
操作説明は、受付や校舎責任者、講師、保護者ごとに分けて用意します。マニュアルと問い合わせ窓口も用意します。
稼働後は、30日、60日、90日の節目で利用率と未処理件数を確認します。そのうえで、保守契約で対応する範囲と、追加開発にする範囲を切り分けます。
よくある失敗と回避策
失敗例には、機能を増やしすぎて現場の入力が増えるケースや、RFPに例外業務がなく追加費用が続くケースがあります。ほかにも、最安値だけで選んで保守体制が弱い、データ返却の条件を確かめずに解約時に移行できない、決済や通知の従量費を見落とす、といった例があります。
これを防ぐには、必須機能を絞り、デモで現場の操作を確かめます。あわせて、見積の前提や除外、変更条件を文書にしておきます。
AIを使う場合は、授業報告や問い合わせの補助に限定します。個人情報を学習に使わない設定や人手による確認、ログの保存も、設計しておきます。
よくある質問（FAQ）
スクール管理システムの発注では、費用だけでなく、業務適合性やデータ、契約、保守まで確認する必要があります。発注前によく寄せられる疑問に、それぞれ答えます。
スクール管理システムの開発費用はいくらですか？
参考レンジは、既製SaaSが初期費用0〜20万円程度・月額2万〜10万円程度、カスタム開発の基本型が200万〜400万円程度、統合型が400万〜800万円程度です（出典: GXO、2026年）。
ただし、利用者数や校舎数、請求ルールによって変わります。連携や移行、保守の範囲でも差が出るため、特定の金額をそのまま予算にせず、同じ要件で複数社から見積を取ります。
RFPはどこまで作ってから発注すべきですか？
完成した詳細仕様書まで作る必要はありませんが、目的や対象業態、業務フロー、必須要件は整理しておきます。利用者権限やデータ件数、外部連携も整理します。移行条件、納期、予算の前提も、揃えておきます。
特に、欠席・振替や休会・復帰の例外を添付すると、提案の精度が上がります。兄弟割引や返金、決済失敗などの例外も、あわせて添付しておくと安心です。
要件定義自体を開発会社へ委託する場合は、まず準委任で要件整理を発注し、その成果を次の開発契約へ引き継ぐ方法もあります。
SaaSとカスタム開発はどちらがよいですか？
標準的な生徒管理や予約、出欠、月謝、保護者連絡で足りる1〜5校舎程度なら、SaaSから始める方法が合理的です。独自の請求や複雑な振替、フランチャイズ集計、既存基幹との連携が事業上必須なら、パッケージ拡張やカスタム開発を比較します。
判断に迷う場合は、1校舎でPoCを行い、削減時間と現場の利用率を確認してから本格発注します。
既存のExcelデータは移行できますか？
移行できるケースが多いですが、CSVの形式や項目名、重複、欠損を整理する必要があります。日付や住所の表記、保護者と生徒の紐付けも確かめます。
見積では、データ抽出やクレンジング、テスト移行、本番移行を分けて確認します。移行後の照合も、項目として並べてもらいます。退会者や過去の成績を保存する期間と、解約時に自社へ返却できるかも、発注時に合意します。
委託先のセキュリティは何を確認すべきですか？
権限分離や管理者認証、操作ログ、暗号化を確認します。バックアップや脆弱性診断、パッチ適用、障害時の復旧も見ます。さらに、再委託や個人情報の削除・返却、事故時の報告期限まで確かめます。
APIや外部通知を使う場合は、連携先で障害が起きたときの代替手段が必要です。どこまでを誰が受け持つかも、あわせて決めておきます。
教育データをAIへ入力する場合は、学習利用の有無や保存場所、検索権限を確かめます。人手による確認の方法も、契約と運用ルールに反映します。
まとめ
実行の第一歩は、入会、予約、出欠、振替、月謝、保護者連絡の業務を洗い出すことです。そのうえで、削減したい時間とミスを数字で確かめます。
続いて、SaaSやパッケージ、ハイブリッド、カスタム開発を、業務との適合性と5年間の総コストで比べます。
発注前に整えるもの
RFPには、対象業態や業務フロー、例外処理を書きます。利用者権限やデータ件数、連携、移行の条件も加えます。セキュリティや保守、解約時のデータ返却についても触れます。
候補会社は3〜5社程度に絞り、総額ではなく、作業範囲や工数、除外項目を同じ表にして比べます。追加変更の条件や契約形態も、同じ表に含めます。要件が固まらない場合は要件定義を先行発注し、開発範囲を確定してから段階的に進めます。
小さく試してからの本格導入
最初から全機能を完成させるのではなく、1校舎・1業務のPoCで、入力率や処理時間、電話件数、保護者の利用率を確かめます。
個人情報を扱う以上、契約でどこまでを誰が受け持つか、権限、ログを合意しておくことが大切です。脆弱性への対応やバックアップ、データ返却も、費用の安さより長期的な安心につながります。
▼全体ガイドの記事
・スクール管理システム開発の完全ガイド
▼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を創業。