塾・スクールの予約システム発注で決めておくこと｜振替対応の仕様の伝え方

先日、ある英会話スクールを運営する方から相談を受けました。「予約システムを外注したのに、振替のルールが思っていたのと違う仕様で納品されてしまった」と。話を聞くと、発注時に渡した資料には「振替対応あり」としか書いておらず、振替の期限や回数の上限、キャンセル料の発生タイミングといった細かい取り決めを一切詰めていなかったそうです。結論から言うと、これは仕様の伝え方の問題であり、発注側が事前に業務フローを言語化していれば防げたトラブルです。つまり、システムそのものの良し悪し以前に、発注者が「何を作ってほしいか」を具体的に伝えられていないケースが本当に多いんです。

塾やスクールの予約システムは、単なる「日時を選んで予約する」機能だけでは成り立ちません。振替対応、月謝の徴収、講師のシフト管理、保護者への連絡、体験レッスンの受付など、教育業界特有の複雑な業務フローが絡みます。この記事では、「スクール 予約システム 発注」を検討している個人事業主や中小企業の担当者、教室運営者の方に向けて、外注前に決めておくべき仕様の整理方法、費用相場、依頼先の選び方を具体的に解説します。

スクール向け予約システムの市場動向と発注の現状

まず、なぜ今このテーマで悩む発注者が増えているのかを、マクロな視点で整理しておきます。

教育・習い事業界のデジタル化は、この数年で急速に進みました。2024年以降、電話やLINEでの予約受付から、専用の予約システムへ切り替える教室・スクールが増加傾向にあります。背景には、少子化による生徒獲得競争の激化と、講師・事務スタッフの人手不足という2つの構造的な要因があります。

電話しか予約の手段がない場合、お客様は営業時間内にスクールへ連絡する必要があり、受講を思い立ったときに、すぐ申し込めないこともあります。一方、予約システムを導入したスクールならば、24時間いつでもレッスンの申し込みが可能です。 出典: rsvia.co.jp

この指摘は、単なる利便性の話にとどまりません。教室側から見ると、電話対応の人件費を削減しながら、機会損失(営業時間外の申込を逃すこと)を防げるという、経営面でのメリットが大きいのです。

一方で、既製のSaaS型予約システム(STORES予約、リザービアなど)をそのまま導入すればよいケースと、自社の業務フローに合わせてカスタマイズが必要なケースが混在しているのが実情です。特に、振替レッスンの回数制限、月謝の自動引き落とし、複数校舎をまたいだ予約管理といった独自ルールを持つスクールほど、既製サービスの標準機能だけでは対応しきれず、開発会社やフリーランスエンジニアへの外注(発注)を検討することになります。

この「既製品で足りるか、外注が必要か」の判断を誤ると、無駄な開発費用が発生したり、逆に既製品の制約に業務を無理やり合わせて現場が混乱したりします。まずはこの判断軸を明確にすることが、発注の第一歩です。

既製サービスと外注開発、どちらを選ぶべきか

既製の予約システムで足りるケース

一般的な個人塾、単一校舎の音楽教室、ヨガスタジオなど、予約フローがシンプルなケースでは、既製のSaaS型予約システムで十分対応できることが多いです。

教室・スクールの予約管理、在籍管理、顧客管理、会費徴収に対応しています。受講生の欠席や振替手続き、月謝の徴収を、STORES予約を通して生徒自身や管理者がオンライン上のみで完結させることができます。 出典: stores.fun

このように、月額数千円から数万円程度の既製サービスには、振替・会費徴収・顧客管理の基本機能がすでに用意されています。まずは自社の業務フローを紙に書き出し、既製サービスのデモを実際に触ってみて、8割以上の業務がカバーできるかを確認するのが先決です。

外注(カスタム開発)を検討すべきケース

以下のような要件がある場合は、既製サービスの標準機能だけでは対応が難しく、外注によるカスタム開発や、既製サービスのAPI連携によるカスタマイズを検討する必要があります。

・複数校舎・複数講師の予約枠を一元管理し、講師ごとの空き状況を自動計算したい ・振替の回数上限や有効期限を、コースごとに細かく設定したい ・既存の会員管理システムや会計ソフトと予約データを連携させたい ・独自のポイント制度、紹介割引、家族割引などの料金体系を予約時に自動計算したい ・LINE公式アカウントと連携し、予約確認や振替案内を自動送信したい

こうした要件は、既製サービスのカスタマイズオプションで対応できる場合もありますが、要件が複雑になるほど、フリーランスエンジニアや開発会社への個別発注が現実的な選択肢になります。

発注前に決めておくべき仕様の整理

ここが最も重要なポイントです。冒頭で紹介した振替対応のトラブルは、発注者が仕様を言葉にしないまま「振替対応あり」とだけ伝えたことが原因でした。行政書士として契約書のトラブルを見てきた立場から言うと、口約束や曖昧な指示は、後から「言った・言わない」の水掛け論になりやすく、フリーランス保護新法の観点からも、発注時点で業務内容を明確にすることが発注者・受注者双方を守ることにつながります。

振替対応のルールを数値で決める

振替対応は、スクール予約システムの中で最もトラブルが起きやすい機能です。発注時には、以下の項目を必ず数値で決めて伝えてください。

・振替可能な回数の上限(例: 月2回まで) ・振替の申請期限(例: レッスン開始24時間前まで) ・振替の有効期限(例: 申請から30日以内に消化) ・当日キャンセルの扱い(振替対象外にするか、別枠でキャンセル料を発生させるか) ・講師都合による休講時の振替は無制限にするか

これらを箇条書きでリストアップし、発注先に渡す仕様書に明記するだけで、認識のズレは大幅に減らせます。

月謝・料金体系のロジックを整理する

月謝制のスクールでは、予約システムと料金計算のロジックが密接に絡みます。

・月謝は固定制か、回数制(週1回コース、週2回コースなど)か ・月の途中入会・退会時の日割り計算はどうするか ・きょうだい割引、複数コース受講割引などの割引ロジックはあるか ・クレジットカード決済、口座振替、コンビニ払いのどれに対応するか

決済機能を含める場合は、決済代行会社(freeeやStripeなど)との連携が必要になるケースが多く、この部分は開発工数に大きく影響します。見積もり段階で「決済連携あり/なし」を明確にしておかないと、後から追加費用が発生しやすい箇所です。

講師・スタッフの権限設計

複数の講師やスタッフが同じシステムを使う場合、権限の設計も忘れずに仕様に含めてください。

・講師は自分の担当コマだけ閲覧・編集できるのか、全体を見られるのか ・事務スタッフは料金変更や振替承認の権限を持つのか ・保護者(生徒本人ではなく)がログインして予約する場合、生徒との紐付けはどう管理するか

これらは開発着手後に変更しようとすると、データベース設計からやり直しになることも多く、手戻りのコストが大きい部分です。発注前の仕様確認で、必ず詰めておくべきポイントです。

費用相場と料金の内訳

スクール向け予約システムの発注費用は、要件の複雑さによって大きく幅があります。ここでは目安となる相場感を示します。

既製サービスのカスタマイズ費用

既製のSaaS型予約システムに、簡易的なカスタマイズ(表示項目の変更、割引ロジックの追加程度)を依頼する場合、フリーランスエンジニアへの発注で5万円〜15万円程度が相場です。既製サービス側の管理画面設定作業(初期設定代行)であれば、3万円〜8万円程度で対応してもらえるケースもあります。

フルスクラッチ開発の費用

振替管理、月謝計算、複数校舎対応、LINE連携などを含むフル機能の予約システムをゼロから開発する場合、規模にもよりますが50万円〜200万円程度が一般的な相場帯です。開発会社に依頼すると、ディレクション費用や保守体制が上乗せされるため、同じ要件でもフリーランスへの直接発注より20%〜40%ほど高くなる傾向があります。

保守・運用費用

システム納品後も、法改正対応、決済システムのアップデート対応、不具合修正などの保守が必要です。月額1万円〜5万円程度の保守契約を結ぶケースが多く、この費用も発注時の見積もりに含めて確認しておくべきです。

仲介会社を通す場合とフリーランスへの直接依頼の違い

制作会社や開発会社に依頼すると、営業担当・ディレクター・エンジニアという複数の役割にコストが発生し、その分だけ見積もりに中間マージンが乗ります。一方、フリーランスエンジニアへ直接依頼すれば、仲介にかかる手数料が発生しないため、同じ要件でも総額を抑えられる可能性があります。特に、要件が明確に整理できている場合は、フリーランスへの直接発注のほうがコミュニケーションの層が少なく、仕様変更への対応も速いというメリットがあります。

私自身、行政書士として独立する前に別の業務でシステム発注を経験したことがあります。そのときは複数の制作会社から見積もりを取り、金額だけを比較して一番安い会社に決めてしまいました。結果として、要件定義の詰めが甘く、追加費用が次々と発生し、最終的には最初の見積もりの1.5倍近い金額になってしまった経験があります。見積もりの安さだけで選ぶのではなく、要件定義にどれだけ時間をかけてくれるかを比較軸に入れるべきだったと、今振り返ると強く思います。

失敗しない依頼先の選び方

教育業界の業務フローを理解しているか

予約システムの開発自体はどのエンジニアでも技術的には可能ですが、振替や月謝計算といった教育業界特有のロジックを一から説明する手間を考えると、過去に塾・スクール・教室向けのシステム開発経験があるエンジニアや開発会社を選ぶほうが、要件定義の工数を大幅に削減できます。過去の実績や類似案件の有無を、発注前に必ず確認してください。

見積もりの内訳が明確か

「一式○○円」という大まかな見積もりだけを提示する依頼先は避けたほうが無難です。画面設計、データベース設計、決済連携、テスト、納品後の保守といった工程ごとに費用が分解されている見積もりを提示してくれる依頼先のほうが、後からの追加費用トラブルが起きにくい傾向にあります。

契約書・業務委託契約の有無

2024年施行のフリーランス保護新法により、フリーランスへ業務委託する際は、業務内容・報酬額・支払期日などを書面(または電子データ)で明示することが義務付けられています。「知り合いだから」「口約束で大丈夫だろう」という進め方は、発注者・受注者双方にとってリスクです。契約書を作成してくれない、あるいは口頭だけで進めようとする依頼先は避けるべきです。

※このケースで契約内容に不安がある場合は、行政書士や弁護士に契約書のチェックを依頼することをおすすめします。

保守体制の有無

納品して終わりではなく、その後の運用中に不具合が出たり、法改正で決済ルールが変わったりすることがあります。納品後の保守・サポート体制があるかどうかを、契約前に必ず確認してください。

業務委託契約で明記すべき項目

行政書士の視点から、スクール予約システムの発注時に契約書へ盛り込むべき項目を整理します。

・業務範囲(要件定義、設計、開発、テスト、納品後の保守のどこまでを含むか) ・納期と納品物の定義(ソースコード一式の納品か、稼働中のシステムへのアクセス権のみか) ・報酬額と支払いスケジュール(着手金、中間金、納品後の残金の割合) ・追加費用が発生する条件(仕様変更、機能追加の際の見積もり方法) ・知的財産権の帰属(開発したソースコードの著作権が発注者に譲渡されるか) ・秘密保持(生徒の個人情報を扱うため、NDAの締結は必須と考えてください) ・契約解除の条件

特に、ソースコードの著作権の帰属は見落とされがちな項目です。著作権が受注者側に残ったままだと、後から別の業者に保守を依頼する際に自由に改修できないという事態が起こり得ます。発注段階で、著作権譲渡の条件を契約書に明記しておくことを強くおすすめします。

発注後のよくあるトラブルと対処法

仕様の認識違いによるやり直し

発注時に伝えた仕様と、納品されたものが違うというトラブルは、教育業界特有の複雑な業務フローが原因で起きやすいものです。対処法としては、開発着手前に画面イメージ(モックアップ)を共有してもらい、実際の操作フローを双方で確認するステップを必ず設けることです。

追加費用の請求

「振替対応あり」とだけ伝えて発注し、後から「回数制限も設定してほしい」と追加要望を出すと、追加費用が発生するのは当然です。こうしたトラブルを避けるためにも、この記事で紹介した仕様整理のチェックリストを、発注前に自分自身で一度埋めてみることをおすすめします。

納期の遅延

繁忙期(新学期前の3月、9月など)に開発を依頼すると、開発会社側のリソース不足で納期が遅れることがあります。導入したい時期から逆算して、余裕を持ったスケジュールで発注することが重要です。

発注前に自社でできる準備

外注する前に、発注者側で以下の準備をしておくと、要件定義の工数が減り、結果として見積もり金額も抑えられます。

・現在の予約受付の流れをフローチャートにして書き出す ・振替・キャンセル・月謝に関する既存のルールを文書化する ・既製サービスのデモをいくつか触ってみて、足りない機能をリストアップする ・生徒数、講師数、校舎数などの規模感を数値で整理する

これらの資料を発注前に用意しておくだけで、依頼先とのやり取りがスムーズになり、認識のズレによる手戻りを防げます。

独自データから見えるスクール予約システム発注の実態

在宅ワーク・フリーランスの求人マッチングサービスを長年運営してきた立場から見ると、スクール向けシステム開発の案件は、教育業界特有の業務ロジックを理解しているエンジニアへの需要が年々高まっている分野の一つです。実際にアプリケーション開発のお仕事を見ると、予約管理や顧客管理を含む業務システム開発の案件は、単純なWebサイト制作案件よりも要件定義に時間をかける傾向が強く、発注者・受注者双方が事前の仕様整理を丁寧に行っている案件ほど、後々のトラブルが少ない傾向にあります。

20年この市場を見てきた立場から言えば、長く付き合いが続く発注者と受注者の関係には共通点があります。それは、単発の作業依頼ではなく、「この人に任せておけば安心」という信頼関係を、最初の発注時点で丁寧に作っているという点です。仕様書を丁寧に作り込む発注者ほど、受注者側も高い品質でこたえようとする傾向があり、結果として長期的な保守・改修の依頼にもつながりやすくなります。

また、額面だけを見て金額の安さで依頼先を選ぶと、前述したような追加費用トラブルに発展しやすいというのも、運営者として見てきた実感です。中間マージンが乗らない直接取引は、発注者にとっては同じ予算でより多くの要件を依頼できる余地が生まれ、受注者にとっては手数料0%の分だけ手取りが厚くなるという、双方にとって得のある構造になります。この"額面より手取り"という構造は、単なる価格競争ではなく、発注者と受注者の間に対等な信頼関係を築くための土台になるものだと感じています。

システム開発の発注においては、ソフトウェア作成者の年収・単価相場のような客観的なデータを事前に確認しておくことも、適正な見積もりかどうかを判断する材料になります。相場感を知らないまま発注すると、高すぎる見積もりを提示されても気づけないというリスクがあるためです。

なお、予約システムの発注そのものではなく、生徒獲得のための集客面で悩んでいるスクール運営者の方には、SNS運用代行 フリーランスで稼ぐ！発注者視点で成功の秘訣と注意点を解説の記事も参考になります。予約システムを整えても、そこに導く集客導線が弱ければ、システム投資の効果は半減してしまいます。予約システムの発注と並行して、集客面の外注も検討する価値があります。

発注時に使える確認リスト

最後に、発注前に自分自身でチェックできる項目をまとめておきます。

・振替の回数上限、期限、有効期限を数値で決めたか ・月謝計算のロジック(日割り、割引、コース別料金)を整理したか ・決済方法(クレジットカード、口座振替など)を決めたか ・講師・スタッフの権限設計を考えたか ・複数校舎がある場合、校舎ごとの予約枠管理の方法を決めたか ・見積もりの内訳(設計・開発・テスト・保守)が明確な依頼先を選んでいるか ・業務委託契約書を交わす予定になっているか ・ソースコードの著作権の帰属を確認したか ・納品後の保守体制があるか

このリストを埋めてから発注に進めば、冒頭で紹介したような「振替対応の仕様が違った」というトラブルは、かなりの確率で防げます。法律はあなたの味方です。契約と仕様書をきちんと整えることが、発注者自身を守る最大の武器になります。

よくある質問

Q. スクールの予約システムを外注する場合、費用相場はどれくらいですか？

既製サービスの簡易カスタマイズなら5万円〜15万円、振替管理や月謝計算を含むフルスクラッチ開発なら50万円〜200万円程度が目安です。決済連携の有無で大きく変動します。

Q. 既製の予約システムとフルスクラッチ開発、どちらを選べばいいですか？

振替回数やコースごとの料金体系がシンプルなら既製サービスで十分です。複数校舎の一元管理や独自の割引ロジックが必要な場合は、カスタム開発を検討してください。

Q. 振替対応の仕様を発注時にどう伝えればいいですか？

振替可能な回数、申請期限、有効期限、当日キャンセルの扱いを数値で明記した仕様書を作成し、開発着手前に依頼先と画面イメージを共有して認識をすり合わせてください。

Q. フリーランスに直接発注するメリットは何ですか？

開発会社を通す場合に発生する中間マージンがない分、同じ予算でも総額を抑えやすく、仕様変更への対応も速い傾向があります。ただし契約書の締結は必須です。

無料で案件を掲載する

入力は3分ほど。掲載料も取引手数料も0円です。@SOHOに登録しているフリーランス・副業ワーカーから、早ければ当日中に最初の応募が届きます。