学校管理システムの休校日設計｜祝日・繰り返し授業・臨時開講を混同しない要件

休校日をカレンダーへ入れたのに、毎週の授業がいつも通り表示される。予定から消すと、今度は振替や受講回数の説明ができなくなる。休校の管理は、日付を赤くするだけでは終わりません。

学校管理システムの休校日設計とは、学校が開講しない日や時間帯を、繰り返し授業と個別の予定へどう反映するかを決めることです。祝日、学校独自の休日、講師の休み、生徒の欠席を分け、既存予定に対する扱いと新規予約の扱いを明確にします。

最初に決めるのは、自動でどの予定を変えるかではありません。どの拠点に、どの期間、何を適用し、例外を誰が認めるかです。その後に、授業を残す、休講の状態へ変える、振替を検討するという判断をつなげます。通知と受講回数の処理も、休校登録だけで勝手に確定させない設計が必要です。

本稿は、語学学校などが導入相談や改修依頼で使う要件の整理です。特定の学校の運用実績や、当サイトで紹介する製品の実装済み機能を示す記事ではありません。例はすべて合成データです。公式のカレンダー仕様と、学校が決める業務ルールを区別して説明します。

この記事で分かること

• 休校、祝日、講師の休みを別の条件として管理する方法
• 繰り返し授業と臨時開講の優先関係を決める手順
• 影響確認、通知、受講回数、境界日のテストに必要な項目

休校日と祝日をどう分けて管理するか？

同じ休日でも何が異なるか？

祝日は、公的な暦に載る日付です。一方、学校がその日に授業を行うかは、学校自身の運用判断が加わります。本稿は、特定の国の祝日や労務上の義務を案内するものではありません。システムへ休日情報を取り込んでも、それだけで学校の休校を確定しないという設計上の区別です。

学校独自の休日や、設備の点検による休校もあります。これらを全部「休日」の一種類で保存すると、日付の根拠と、授業への適用範囲が見えなくなります。名称、区分、対象、開始と終了、決定した担当者を分けて持てば、なぜその予定が受け付けられないかを説明できます。

講師が休む場合は、学校全体が閉まるわけではありません。他の講師や別の教室では授業を行えるかもしれません。生徒の欠席も、学校の開講可否とは別です。予定がない状態に見えても、原因が違えば対応する相手や受講回数の扱いが変わります。

休校の適用範囲には何を持たせるか？

表は横にスクロールして比較できます。

この表は、公的な休日制度の分類ではありません。学校の業務をシステム要件へ整理するための提案です。小さな学校なら、一つの拠点だけでも構いません。複数拠点を持つ場合は、全体設定が一部へ誤って広がらないことと、対象外の拠点が止まらないことを確認します。

オンライン授業は、校舎の休校と同じとは限りません。設備点検で一校舎を閉じても、別の場所から開講する予定は残る場合があります。反対に、学校全体が事務対応を休むなら、オンラインでも休校にする判断があり得ます。どちらが正解かをシステムが推測せず、運用として明示します。

一覧画面では、休校の理由を必要な範囲で表示します。管理者が知る詳しい事情と、生徒へ案内する説明を同じ欄にしない方が扱いやすくなります。個人の事情を含む情報は、予定を見る全員へ公開しません。予約できない理由が分かることと、内部の詳細を見せることを分けます。

日付と時間帯の境界をどう決めるか？

「一日休み」はどの時刻を指すか？

一日単位の休校を、単に深夜の時刻へ変換して保存すると、別の地域の画面で前日や翌日へずれることがあります。日付そのものを表す情報と、時刻を伴う予定を区別します。学校の暦としての一日なのか、ある瞬間から別の瞬間までの停止なのかを先に決めることが必要です。

カレンダーの標準仕様であるRFC 5545では、日付だけの値と、時刻を含む値が区別されています。また、予定の終了はその時点を含めない形で説明されています。自社システムが同じ保存方式を採用する義務を本稿が述べるわけではありませんが、外部カレンダーとの受け渡しでは、この意味を照合する必要があります。RFC 5545

例えば説明用の合成例として、11月1日から11月3日の手前までを休校の区間にするなら、対象の日付は11月1日と2日です。「終了日」を画面で2日と表示するか、内部で3日の開始を持つかは別の設計です。利用者に見せる意味と、内部で比べる値が一致することを確かめます。

時刻付きの授業はどう判定するか？

表は横にスクロールして比較できます。

日時の入力欄があるだけでは、タイムゾーンまで決まるとは限りません。MDNの説明では、HTMLの日時入力の一種であるdatetime-local自体には、タイムゾーンを設定する手段が含まれていません。入力された時刻を、学校のどの地域の時刻として扱うかは、アプリ側の設計で確かめます。MDNの日時入力の説明

授業が休校の区間をまたぐ場合も、判断が必要です。終了が休校の開始と同じ時刻ならどうするか、開始が再開時刻と同じなら受け付けるか、少しでも重なる授業を止めるか。どれも境界の扱いなので、曖昧にすると担当者ごとの判断になります。学校が採用する条件を文章とテストで残します。

合成データでの境界確認では、休校開始の直前に終わる授業、期間中の授業、終了直後に始まる授業を分けます。実際の祝日や生徒の予定を使う必要はありません。特定の日付を選ぶ理由は、カレンダー上の本当の休日だからではなく、判定の境界を確かめるためです。

日付の表示形式も、読む人に合わせて意味が分かるようにします。数字だけの短い表記は、月と日の順序を読み違える可能性があります。年月日や曜日、時刻の基準を明確にし、確認画面では対象期間を読み直せるようにします。入力の便利さと、確定前の確認を両立させることが大切です。

終了日を入力する画面で何を確かめるか？

利用者が「この日まで休み」と入力する画面では、内部の終了値がその日を含むかどうかを意識しなくても使える説明が必要です。入力欄の名称、確認画面の文章、実際に止まる授業が一致することを確認します。利用者向けには終了日を含む表示を採用し、内部では翌日の開始を持つ方式も考えられますが、変換が正しいかは別に試します。

期間を編集したときも、拡大した部分と短くなった部分を分けて見ます。休校を延ばすなら、新しく対象となる授業があります。短くするなら、以前止めた授業を再開するかという判断が生まれます。期間を保存し直すことだけで、既存の案内と回数処理まで自動で戻さない設計を検討します。

繰り返し授業と例外をどう扱うか？

毎週の予定を削除するだけでは何が困るか？

繰り返し授業は、毎週のルールと、各回の予定を分けて考えます。休校日に当たる一回だけを変更するのか、その後の予定も変えるのかで影響が違います。カレンダー上から見えなくなればよいという要件だけでは、どの範囲を変更するかが決まりません。

個別の回を単純に消すと、もともと予定がなかったのか、休校により実施しないのかが分からなくなる場合があります。振替や受講回数の説明が必要なら、元の授業との関係を残す設計を検討します。保存方式は製品によりますが、業務上必要な説明ができることを受入条件にします。

RFC 5545には、繰り返しの予定から除外する日付を表す仕組みがあります。ただし、外部カレンダーで除外されたことと、学校の受講回数がどう扱われるかは別です。カレンダーの表現だけに、料金や回数の判断まで任せないようにします。規格が定める予定の意味と、学校が決める運用を区別します。

臨時開講を認める条件はどう決めるか？

表は横にスクロールして比較できます。

例外は「この予定だけ通す」という操作で終わらせません。対象の拠点、授業、時間帯、承認者を限定します。全体の休校を無効にして一件だけ登録すると、他の予定まで受け付けられる状態になるかもしれません。例外のために広い条件を外さないことが重要です。

定期授業を先に生成してある方式と、表示時にルールから作る方式でも、影響の確認方法が変わります。前者なら生成済みの回をどう更新するか、後者なら個別変更をどう保持するかを確認します。導入相談では、内部方式を細かく指定するより、休校追加後に既存の予定がどう見え、どう予約判定されるかを質問すると、運用の確認につながります。

休校の取り消しも慎重に扱います。すでに代わりの日程を案内しているのに、元の授業が自動で復活すると二つの予定が残る可能性があります。設定の取消と、授業を再開する判断を分け、影響する予定を見てから確定します。元の状態へ戻せばすべて解決するとは限りません。

講師や教室の空き確認は、臨時開講でも別途必要です。休校の例外が認められたことは、時間や場所の重複がないことの証明にはなりません。既存の二重予約防止の条件を通した上で、例外として開講するという順序を考えます。本稿の中心は、その前提となる休校と例外の扱いです。

休校登録前に何をプレビューするか？

設定を保存する前に影響を読めるか？

新しい休校を登録する際は、対象期間に何件の授業があるかだけでなく、その状態を確認します。すでに実施済みの授業、予約が確定している授業、まだ受け付けていない予定では、変更の扱いが異なります。単に件数を示すだけでは、何を変えてよいか判断できません。

プレビューには、拠点、日時、定期授業か個別予定か、現在の状態、変更後の候補を並べます。担当者が元の予定へ戻れる参照もあると、特殊な事情を確かめやすくなります。生徒名などの個人情報は、確認する担当者に必要な範囲で見せる設計にします。

変更後の候補は、そのまま自動実行の指示である必要はありません。「休講の対象」「個別確認が必要」「適用しない」のように、判断するための状態を分けられます。学校のルールが決まっていない場合、先にその判断を確定させます。システムが空欄を推測して埋めないことが大切です。

何を一緒に変更してよいか？

表は横にスクロールして比較できます。

休校設定の保存と、影響する予定の変更と、通知の送信を分けると、どの操作まで済んだかを追いやすくなります。ただし、分けた結果として途中の状態が放置されないように、未完の処理を一覧で確認できることも要件になります。安全に段階を分けることと、最後まで追うことは両方必要です。

確認中に別の担当者が予定を変更した場合も想定します。古いプレビューで確定する前に、対象の予定が同じ状態かを再確認する設計を検討します。直前に予約が追加されたのに影響一覧に出ない、といった状態を防ぐためです。詳しい実装方法はシステムによりますが、更新が競合した際の表示と再確認の手順は受入条件にできます。

大量の授業へ一括で適用するなら、まず合成データで限定した範囲を試します。対象と結果を比較し、実施済みの授業や対象外の拠点に変化がないかを確かめます。本番の予定を、動作を確かめるためだけに変更する必要はありません。戻し方も、実行前の条件として決めます。

プレビューで影響がゼロだった場合も、意味を確認します。本当に授業がないのか、対象の拠点や期間を間違えたのか、権限の範囲で見えていないのかを区別します。ゼロ件だから安全だと一律に判断せず、設定した条件と見ている範囲が合っているかを読み直します。

影響の確認を途中で止められるか？

確認画面で対象が想定と違うと分かった場合、確定せずに戻れることが必要です。戻っただけで一部の授業が変更されていないかを試します。設定の下書きと、実際に適用された状態を区別し、途中の操作が外部の通知へ進まないことも確かめます。キャンセルできる画面があるだけでは、変更が起きていない証明にはなりません。

一括処理が途中で止まった場合は、適用済みと未適用を識別できる記録を残します。どこまで進んだか不明なまま最初からやり直すと、通知や回数の処理が重複する可能性があります。完了した対象を確認し、残ったものをどう進めるかを担当者が判断できることを、改修相談の確認項目にします。

この点は、学校の規模だけで省略できません。予定の件数が少なくても、変更途中の状態が分からなければ、利用者へ正しい案内をできないからです。複雑な管理画面を増やす必要はありませんが、何が確定し、何が残っているかを追える状態は保持します。

通知・振替・受講回数をどうつなぐか？

休校が決まった後に何が残るか？

休校の登録が済んでも、生徒や講師がその変更を知っているとは限りません。通知する相手と、連絡する内容を確認します。学校全体の案内と、個別授業の変更案内では、必要な情報が異なります。同じ人へ重複して通知する可能性も含め、どの案内が何を伝えるかを整理します。

送信を開始したこと、配信の仕組みが受け付けたこと、相手が読んだことは別です。どこまで確認できるかは利用する連絡手段によります。システムの状態を、実際より先の段階として表示しないことが大切です。確認できない場合は、未確認として運営側が追えるようにします。

文面には、対象の日付と時刻、影響する授業、今後の案内を入れます。複数の地域へ連絡するなら、どの地域の時刻かを明記します。振替がまだ決まっていない段階で、代替日が確定したように案内しないようにします。休校の事実と、次に相談する内容を分けます。

回数と振替の状態はどう整理するか？

表は横にスクロールして比較できます。

料金や受講回数の規則は学校によって異なります。本稿は、返却や消化をどちらにすべきかを一律に決めません。大切なのは、休校という理由と、回数へ与える結果を説明できることです。内部の処理と、入会時や予約時に案内した条件が食い違っていないかを確認します。

振替先が決まる前に、元の予定と受講権の関係を残します。一覧では休講と振替済みを区別し、未調整の授業を見つけられるようにします。予定の見た目だけがきれいになり、調整する仕事が見えなくなる状態を避けます。担当交代でも続きが分かることが必要です。

通知に失敗した場合は、予定の変更を繰り返すのではなく、通知の状態を確かめます。授業の確定と連絡を同じボタンで行うシステムでも、再操作により重複や別の変更が起きないかを確認します。結果が不明なまま同じ送信を繰り返す運用は、利用者の混乱につながります。

学校からの案内と講師個人の連絡が併存する場合も、内容を合わせます。最新の予定をどこで確認するかを決め、変更後の案内が旧予定を参照していないかを点検します。個別に丁寧な連絡をしていても、見る場所ごとに日付が違えば、利用者はどれを信じてよいか分かりません。

受入テストと更新の担当をどう決めるか？

どの境界を合成データで試すか？

導入前の確認では、通常の休校日だけでなく、対象外になるはずの予定を用意します。学校全体の停止と拠点だけの停止、全日の休みと一部時間の停止を分けます。見た目に休日が表示されることと、予約の判断が正しいことを別々に確かめます。

本稿に付属する合成検証では、半開区間として設定した休校期間に対し、開始直前で終わる授業、期間内の授業、終了と同時に始まる授業、別拠点の授業、明示的に認めた例外を確認します。これは要求した判定条件を小さく確かめる試験です。実際の学校管理システム、外部カレンダー、通知や回数処理の動作を証明するものではありません。

表は横にスクロールして比較できます。

繰り返しの授業では、一回だけの例外と、今後すべての変更を別々に試します。休校を追加する前に個別変更した予定が、登録後にも残るかを確認します。取り消し操作では、振替済みの元予定が勝手に復活しないかを点検します。通常の登録成功だけでは見つからない条件です。

暦の更新を誰が確認するか？

公的な祝日情報を使う場合は、情報の出所と確認した日を記録します。取り込んだデータが、学校の営業上の休日を自動で決めるわけではありません。追加や変更があったとき、誰が学校への適用を判断するかを決めます。本稿では、特定の国の翌年の祝日一覧は確認して掲載していません。

更新のたびに全予定を作り直す前提にしないことも大切です。すでに確定した授業、個別の例外、実施済みの記録を保持し、どこに影響するかを見ます。古い情報を置き換えるときは、変更前の条件と適用した日時が分かる記録を残します。カレンダーが新しくなったことと、必要な案内が済んだことも分けます。

受入条件は、操作と期待結果の組み合わせで書きます。「休日機能がある」だけでは確認できません。「対象拠点の全日休校を追加したとき、期間内の未実施授業が一覧に出て、別拠点は変更されない」のようにすると、導入先や開発者と同じ結果を見られます。例外と取消の条件も同じ形式で残します。

最後に、日常の担当者が画面を使って確認します。設定できる人と、問い合わせへ答える受付の人が違う場合でも、最新の休校と個別例外を説明できる必要があります。操作説明を読めることだけでなく、なぜその授業が止まったかを確認できることを、運用の完成条件にします。

導入先へ渡す要件をどうまとめるか？

最初の資料では、現在の休校の決め方、対象拠点、授業の作り方、休校後に必要な作業を整理します。画面の希望だけを並べるより、今どの判断で困っているかを書く方が、必要な機能を話し合いやすくなります。既存の道具で運用できる部分と、改修が必要な部分も分けられます。

例えば、「休校日が表示できること」に加え、「確定済みの授業がある場合は影響一覧を見てから判断できること」「個別の例外が全体設定の更新で失われないこと」を書きます。さらに、通知や回数へどの結果を渡すかを記載します。実装方法を決める前でも、業務上の完成条件は具体化できます。

確認に使う合成例も資料へ添えます。学校全体の休み、拠点だけの休み、一件だけの臨時開講を用意し、期待する結果を明記します。これらは本番に存在する事例である必要はありません。新しい担当者や導入先が、同じ条件で同じ結果を確認できることに意味があります。

相談の最後には、未決のルールを残します。振替の期限、回数の返却、講師への連絡を誰が決めるかなど、学校側の判断が必要な項目を、開発者の推測で埋めないためです。先に決めるべき運用と、仕様として確認する内容が分かれば、導入の前後で同じ議論を繰り返す負担を減らせます。

よくある質問

祝日カレンダーを連携すれば休校管理は完成しますか？

祝日の情報と、学校が開講するかの判断は別です。対象拠点、オンライン授業の扱い、既存の予定への適用、例外の承認を決めます。連携したことだけで通知や受講回数の処理まで完了したとは判断しません。

休校日は予定を削除してもよいですか？

業務によりますが、元の授業と休校の理由、振替の関係が必要なら、その説明を残せる方式を検討します。単に消すと、もともと予定がなかった状態と区別できない場合があります。履歴や回数の扱いを確認して決めます。

一部の授業だけ開講できますか？

その運用を採用するなら、例外の対象と承認者を限定します。学校全体の休校を解除して一件を通すのではなく、対象の予定だけに適用する設計を検討します。講師や教室の重複確認は別に必要です。

休校の取消で元の授業を自動復活させるべきですか？

振替や通知が進んでいる可能性があるため、一律には決められません。取り消しの影響をプレビューし、元予定と変更先、回数の状態を確認します。設定を戻すことと、授業を再開する判断を分けると整理できます。

合成検証が通れば本番でも安心ですか？

合成検証は、設計した判定条件の一部を確かめるものです。実システムでは、画面、保存、同時更新、カレンダー連携、通知、受講回数を別途確認する必要があります。試していない部分まで合格とは扱いません。

休校の一件を、予定と連絡まで通して確認する

まず、架空の拠点と授業を用意し、一件の休校を追加します。影響する予定、対象外の予定、例外、振替、案内を順に確認します。日付の登録だけで終わらず、利用者へ説明できる状態まで追えることが目標です。

学校管理システムの案内と学校運営の記事一覧では、関連する検討の入口を確認できます。相談時は、学校管理の問い合わせ窓口から、拠点、休校の種類、繰り返し授業の扱い、今困っている操作をお知らせください。生徒や講師の個人情報を送る必要はありません。記載した設計が既存製品にすべて実装済みと保証するものではありません。

出典・確認範囲

運営・編集：タゲンゴ。原稿確認日：2026年10月29日。公開予定日：2026年11月1日。予定日当日の祝日や仕様を再確認したという意味ではありません。

公式参照：RFC 5545のカレンダー仕様、MDNの日時入力。日付、時刻、繰り返しと除外の仕様を確認する資料として使用しています。学校の休校、振替、回数の扱いは編集上の要件提案です。合成検証は境界条件の限定的な確認であり、顧客データ、取材、製品の実稼働結果は使っていません。