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

スクール管理システムの発注・外注は、現場業務を棚卸ししてSaaS・パッケージ・カスタム開発を比較し、要件・契約・費用・データ移行の条件を揃えて複数社へ依頼する方法が基本です。

スクール管理システムを導入したいものの、「既製サービスで足りるのか」「開発会社へ何を伝えればよいのか」「見積書の金額をどう比べるのか」と迷う事業者は少なくありません。学習塾、英会話教室、音楽・ダンス・スポーツ教室、資格・研修スクールでは、月謝、予約、振替、兄弟・世帯管理、保護者連絡などの業務ルールが異なるため、機能一覧だけを見て委託先を決めると、導入後に追加費用が発生しやすくなります。本記事では、発注形態の選択からRFPの作り方、契約形態、2026年時点の費用レンジ、委託先の選定、見積比較、稼働後の保守までを一通り解説します。

▼全体ガイドの記事
・スクール管理システム開発の完全ガイド

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

発注前に決めるべきことは、システムの名称や画面デザインではなく、導入対象の業務と成功条件です。スクール管理システムは、生徒・保護者・講師・講座・予約・出欠・請求・連絡のデータをつなぐ業務基盤です。何を一元化し、誰の作業をどれだけ減らしたいのかを先に言語化すると、発注形態と見積の妥当性を判断しやすくなります。

まず、直近1か月の業務を「入会・体験」「在籍変更」「授業予約」「欠席・振替」「月謝請求」「入金確認」「保護者連絡」「講師シフト」「退会」に分けて記録します。たとえば、月謝の入金消込に毎月何時間かかるか、振替処理が何件あるか、同じ情報を何人が何回入力しているかを数えます。削減したい時間やミスを数値で示せれば、開発費を単に安くするのではなく、投資対効果で比較できます。GXOの2026年記事でも、教室数が増えるほどExcelや電話による管理負担が膨らむ課題が示されています。

学習塾や習い事教室が重視するのは、学籍や校務の管理よりも、入会、月謝、予約、出欠、振替、保護者連絡、継続率、校舎別売上です。学校法人向けの校務支援システムを参考にする場合でも、そのまま要件へ移すのではなく、自社の収益と現場運用に必要なデータへ置き換えます。未成年者の個人情報や成績を扱う点は共通しますが、利用者の権限や契約主体、保護者との連絡方法は異なるため、対象業態をRFPの冒頭に明記することが重要です。

発注形態はSaaS・パッケージ・カスタム開発から選ぶ

発注形態は、現状の業務を製品に合わせられるか、独自ルールをシステムへ反映する必要があるかで決めます。最初からスクラッチ開発に決めるのではなく、既製サービスのデモと要件の適合表を作り、差分が本当に事業上必要かを確認します。1〜3校舎で標準機能を使えるならSaaS、標準機能を活かしつつ帳票や連携だけを調整するならパッケージやハイブリッド、独自の請求・多校舎・基幹連携が競争力に直結するならカスタム開発が候補になります。

SaaSは、契約後すぐに使い始めやすく、サーバー運用やアップデートを自社で抱えにくい点が利点です。生徒管理、予約、出欠、月謝、保護者連絡などが標準機能で足りる場合は、開発会社へ大規模な発注をするより、導入支援や初期設定の範囲を見積もってもらう方法が現実的です。一方で、生徒数課金、校舎数課金、オプション、決済手数料、通知料が増えると月額が変わるため、100人・500人・1,000人の利用条件で5年間の総額を確認します。

パッケージは、業務に必要な基盤が用意されており、初期設定や追加ユニットで自社に合わせる方式です。予約や請求は既製機能を使い、会計・決済・LINE・入退室端末だけをAPIやCSVでつなぐハイブリッドにすると、開発範囲を抑えながら業務差分へ対応できます。株式会社大和コンピューターのPlatinum Schoolは、公開料金で受講者規模別のプランとオプションを示しており、既製部分と追加機能の切り分けを考える際の比較材料になります。

複数コースの合算請求、兄弟割引、日割り、休会・復帰、独自の振替期限、フランチャイズ本部の集計、既存基幹システムとの連携などが標準サービスの制約になる場合は、カスタム開発を検討します。ただし、要望をすべて盛り込むと予算も納期も膨らみます。最初のリリースでは生徒・契約・予約・出欠・請求を中核にし、AI授業報告や高度な分析は第2段階へ回すなど、段階的な発注にします。

RFPと要件整理で発注内容を具体化する

RFPは、開発会社やサービス提供会社へ同じ条件で提案と見積を依頼する文書です。分厚い仕様書を完成させる必要はありませんが、目的、対象業態、利用者、業務フロー、必須要件、希望要件、連携、移行、セキュリティ、納期、予算の考え方を揃えます。口頭で伝えた要望を各社が別々に解釈すると、安い見積と高い見積が違う範囲を計算しているだけになるため、比較できる単位にすることがポイントです。

要件整理では、通常処理だけでなく例外処理を記載します。たとえば「欠席を登録する」だけでなく、当日欠席、無断欠席、振替権利の発生、振替期限、振替先の定員、キャンセル料まで定義します。「月謝を請求する」場合も、複数コース、兄弟割引、教材費、日割り、休会、返金、未収金、決済失敗後の再請求を整理します。業務担当者、校舎責任者、講師、保護者、本部経理がどの画面で何をするのかを線でつなぐと、必要な権限も見えてきます。

要件は、開発初日に必要な「必須」、初期導入の効果を高める「優先」、将来の拡張候補である「将来」に分けます。必須要件には、生徒・世帯情報、契約・受講、講座・クラス、予約・出欠、請求・決済、保護者への通知、権限と監査ログを置きます。将来要件には、成績分析、動画教材、AIによる授業報告、需要予測などを置き、初回見積に含めるか、別フェーズの参考見積にするかを明示します。受講者数、校舎数、同時アクセス数、通知件数などの前提も数字で記載します。

RFPには、現行のExcel項目、帳票、月謝計算のルール、予約カレンダー、通知文面、権限一覧、外部サービスの契約情報、データ件数の概算を添付します。既存データを移行する場合は、列名の揺れ、重複、退会者の扱い、保護者と生徒の紐付け、保存期間を確認します。CSVやAPIでデータを取り出せるか、解約時に全データを返却できるかも、RFPの質問項目に入れておくとベンダーロックインを避けやすくなります。

契約形態と発注範囲を分けてリスクを管理する

スクール管理システムの発注では、要件定義、設計・開発、テスト・移行、運用保守を一つの契約にまとめる方法と、フェーズごとに契約を分ける方法があります。要件が固まっていない段階で全工程を一括発注すると、追加変更の金額や責任範囲が曖昧になりやすいです。最初は要件定義を準委任で依頼し、仕様と優先順位が固まった後に開発部分を請負で発注するなど、成果物と不確実性に合わせて契約を分けます。

請負契約は、合意した機能や成果物を完成させる範囲に向いています。画面一覧、機能仕様、テスト項目、納品物、検収条件、納期が比較的明確な場合は、費用と成果の関係を管理しやすくなります。ただし、契約後に「やはり別の振替ルールにしたい」「月謝の締め日を変更したい」となると、変更管理が必要です。変更の受付方法、影響調査、追加見積、承認者、納期の扱いを契約書や別紙に定めます。

準委任契約は、要件整理、業務ヒアリング、技術検証、継続的な改善、アジャイル開発のように、作業や専門知識の提供を委託する範囲に向いています。要件が変化しやすい新規事業や、既存サービスとの連携方式を検証する段階では、作業時間や体制を管理しやすい方法です。一方で、完成責任や品質保証が自動的に決まるわけではないため、作業内容、担当者、レビュー方法、成果物、月次報告、終了条件を別途明確にします。

契約書では、知的財産権、ソースコードの帰属、第三者サービスの利用、再委託先、秘密保持、個人情報の取扱い、障害時の連絡、バックアップ、脆弱性対応、損害賠償の上限、保守時間、解約時のデータ返却を確認します。個人情報を含む受講履歴や成績を扱う場合は、委託先のアクセス権限、ログ保存、削除依頼への対応、海外クラウドの利用、事故発生時の報告期限まで具体化します。IPAもITサービス委託のセキュリティ対策では、契約と第三者検証で責任を担保する考え方を示しています。

スクール管理システムの費用相場と見積の内訳

費用は、利用人数、校舎数、請求ルール、外部連携、権限、データ移行、保守範囲によって変わります。2026年時点の公開情報を整理すると、既製SaaSは初期費用0〜20万円程度、月額2万〜10万円程度、カスタム開発の基本型は200万〜400万円程度、連携や多校舎管理を含む統合型は400万〜800万円程度という参考レンジがあります（出典: GXO「学習塾・スクール管理システム開発の費用相場」、2026年）。これは市場全体の統計ではなく、事業者が公開する目安です。

既製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年間の総保有コストで考えます。SaaSは月額が積み上がり、利用者増加やオプション追加で上がる可能性があります。カスタム開発は初期費用が大きい一方、保守、クラウド、追加開発、セキュリティ対応が継続します。小規模のSaaSを月額5万円で使う場合、単純計算の5年分は300万円ですが、決済手数料や初期支援は別です。カスタム開発も同じ条件で、開発、保守、連携費、移行費を加えて比較します。数字は前提条件とセットで提示してもらうことが重要です。

委託先の選定と見積比較のポイント

委託先は、知名度や見積の安さだけでなく、スクール業務への理解、要件定義の進め方、開発後の保守、データとセキュリティの扱いを確認して選びます。候補は3〜5社程度に絞り、同じRFP、同じ質疑回答、同じ前提条件で提案を受けます。提案書の機能数よりも、現場の例外業務をどこまで理解し、未確定事項と追加費用の条件を正直に示しているかを重視します。

候補会社には、学習塾、英会話、音楽・スポーツ、研修など、自社に近い業態の導入事例を確認します。事例の数だけでなく、受講者数、校舎数、利用者の種類、月謝や予約の複雑さ、移行データ量、稼働後の保守体制を質問します。可能であれば、経営者向けの画面だけでなく、受付担当、講師、保護者が使う画面をデモしてもらいます。保護者がスマートフォンで欠席や振替を完了できるか、講師の入力が増えないかを確認することが定着率に直結します。

見積書は、総額だけでなく、要件定義、設計、機能ごとの実装、連携、テスト、移行、教育、保守、クラウド、決済・通知の費用に分解します。「一式」と書かれた項目が多い場合は、含まれる成果物、作業時間、前提条件、除外項目を質問します。A社は決済連携を含み、B社は別料金という違いがあれば、総額を揃えて比較します。工数、人月、単価、期間、担当体制も確認し、安い理由が要件の抜けになっていないかを見ます。

未成年者の氏名、住所、保護者連絡先、出欠、成績、決済情報を扱うため、SSL対応だけで判断してはいけません。権限分離、管理者の多要素認証、操作ログ、バックアップ、脆弱性診断、パッチ適用の期限、障害時の復旧目標、委託先と再委託先を確認します。文部科学省は2025年3月に教育情報セキュリティポリシーに関するガイドラインを公表しており、教育データ標準でもデータ内容や技術規格の標準化が進められています。学校法人でなくても、教育データを扱うシステムの発注では、将来連携できるデータ構造と責任分界を意識します。

IPAの委託事例では、OSSをカスタマイズした予約システムで、URLの変更によって他人の受講状況や成績が見える脆弱性と、パッチ未適用の問題が取り上げられています（出典: IPA「プラクティス5-3」、2026年閲覧）。価格や開発実績と同じように、脆弱性が見つかった場合の修正責任、第三者検証の有無、解約時のデータ取得方法を契約前に確認することが大切です。

発注後の進め方と失敗を防ぐポイント

発注先が決まった後も、任せきりにすると現場とシステムのずれが広がります。発注者側に責任者を置き、要件の決定者、現場代表、経理、個人情報管理の担当を明確にします。要件定義、設計、実装、テスト、移行、教育、稼働判定の節目ごとに承認し、変更は記録して予算と納期への影響を確認します。

全校舎へ一度に展開せず、1校舎または1クラスで予約・出欠・保護者連絡などを試します。導入前後で、受付の入力時間、欠席・振替の処理時間、月謝確認時間、電話件数、保護者の利用率、講師の入力率を計測します。機能が動くかだけでなく、現場が使い続けられるかを判断します。NotebookLMのリサーチでも、限定範囲で試行して費用対効果と現場の反応を確認してから本格導入する進め方が示されています。

稼働直前にExcelを渡すだけでは、表記ゆれや重複が残り、現場の混乱につながります。移行対象、データクレンジングの担当、テスト移行の回数、旧システムを参照できる期間、退会者データの扱いを決めます。受付、校舎責任者、講師、保護者向けに操作説明を分け、マニュアルと問い合わせ窓口を用意します。稼働後30日、60日、90日で利用率と未処理件数を確認し、保守契約で対応する範囲と追加開発にする範囲を切り分けます。

失敗例として、機能を増やしすぎて現場の入力が増える、RFPに例外業務がなく追加費用が続く、最安値だけで選んで保守体制が弱い、データ返却条件を確認せず解約時に移行できない、決済や通知の従量費を見落とす、といったケースがあります。これを防ぐには、必須機能を絞り、デモで現場の操作を確認し、見積の前提・除外・変更条件を文書化します。AIを使う場合も、授業報告や問い合わせの補助に限定し、個人情報を学習に利用しない設定、人手確認、ログ保存を設計します。

よくある質問（FAQ）

スクール管理システムの発注では、費用だけでなく、業務適合性、データ、契約、保守まで確認する必要があります。ここでは、発注前によく寄せられる疑問へ直接回答します。

参考レンジは、既製SaaSが初期費用0〜20万円程度・月額2万〜10万円程度、カスタム開発の基本型が200万〜400万円程度、統合型が400万〜800万円程度です（出典: GXO、2026年）。ただし、利用者数、校舎数、請求ルール、連携、移行、保守で変わるため、特定金額をそのまま予算化せず、同じ要件で複数社から見積を取得します。

完成した詳細仕様書まで作る必要はありませんが、目的、対象業態、業務フロー、必須要件、利用者権限、データ件数、外部連携、移行条件、納期、予算の前提は整理します。特に欠席・振替、休会・復帰、兄弟割引、返金、決済失敗などの例外を添付すると、提案の精度が上がります。要件定義自体を開発会社へ委託する場合は、まず準委任で要件整理を発注し、その成果を次の開発契約へ引き継ぐ方法もあります。

標準的な生徒管理、予約、出欠、月謝、保護者連絡で足りる1〜5校舎程度なら、SaaSから始める方法が合理的です。独自の請求、複雑な振替、フランチャイズ集計、既存基幹との連携が事業上必須なら、パッケージ拡張やカスタム開発を比較します。判断に迷う場合は、1校舎でPoCを行い、削減時間と現場の利用率を確認してから本格発注します。

移行できるケースが多いですが、CSVの形式、項目名、重複、欠損、日付や住所の表記、保護者と生徒の紐付けを整理する必要があります。見積では、データ抽出、クレンジング、テスト移行、本番移行、移行後の照合を分けて確認します。退会者や過去の成績をどの期間保存するか、解約時に自社へ返却できるかも発注時に合意します。

権限分離、管理者認証、操作ログ、暗号化、バックアップ、脆弱性診断、パッチ適用、障害時の復旧、再委託、個人情報の削除・返却、事故時の報告期限を確認します。APIや外部通知を使う場合は、連携先の障害が起きたときの代替手段と責任分界も必要です。教育データをAIへ入力する場合は、学習利用の有無、保存場所、検索権限、人手確認の方法を契約と運用ルールに反映します。

まとめ

スクール管理システムの発注・外注では、まず入会、予約、出欠、振替、月謝、保護者連絡などの現状業務を棚卸しし、削減したい時間とミスを明確にします。そのうえで、SaaS、パッケージ、ハイブリッド、カスタム開発を業務適合性と5年間の総コストで比較します。

RFPには、対象業態、業務フロー、例外処理、利用者権限、データ件数、連携、移行、セキュリティ、保守、解約時のデータ返却を記載します。候補会社は3〜5社程度に絞り、総額ではなく作業範囲、工数、除外項目、追加変更の条件、契約形態を同じ表にして比べます。要件が固まらない場合は要件定義を先行発注し、開発範囲を確定してから段階的に進めます。

最初から全機能を完成させるのではなく、1校舎・1業務の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を創業。