個別指導塾の教室長、やることが多すぎる

shiftect.は、教室長の頭脳を特許に落とし込んだような技術だった

Wed, 01 Jul 2026 23:20:17 +0900

shiftect. for EDUCAについて調べている中で、shiftect.は特許出願済の技術だと知りました。

最初は、個別指導塾向けのスケジューリングSaaSだと思っていました。
毎月の授業予定を自動作成する。
欠席や講師変更に対応する。
保護者側からの振替申し込みまで扱う。
そういう仕組みとして理解していました。

ただ、特許出願済という言葉を見て、少し受け止め方が変わりました。

これは、単なる予定表作成ではないのだと思います。
教室長が頭の中でやっている判断を、スケジューリング技術として扱おうとしているのだと感じました。

個別指導塾の予定作成は、外から見ると、時間割を作っているだけに見えるかもしれません。
でも、現場でやっていることは、まったく単純ではありません。

どの生徒が、いつ来られるか。
どの講師が、いつ勤務できるか。
その講師は、どの教科を担当できるか。
どの学年まで見られるか。
1対2で組ませてよい組み合わせか。
ブースは足りているか。
契約コマ数は合っているか。
残コマはずれていないか。
振替分は正しく扱えているか。
確定済み予定を壊していないか。

こうした条件を、教室長は毎月の予定作成の中で扱っています。

さらに、予定表を作った後にも判断があります。

欠席が入ったとき。
振替が必要になったとき。
講師変更が入ったとき。
追加授業を入れるとき。
保護者側から振替の申し込みが入るとき。

そのたびに、教室長は予定表を見直します。

ただし、全部を作り直すわけではありません。
すでに保護者に案内している予定があります。
講師に伝えている予定があります。
確定済みの授業があります。
他の生徒の授業もあります。

だから、予定が動いたときには、どの授業を動かしてよいか、どの授業は動かしてはいけないかを分ける必要があります。

ここが、個別指導塾の予定作成でかなり難しいところです。

欠席した授業は動かす必要があります。
振替対象になった授業も動かす必要があります。
講師変更が必要な授業もあります。
追加で入れたい授業もあります。

一方で、動かしたくない授業もあります。
すでに確定している授業。
保護者に伝えている授業。
講師に伝えている授業。
他の生徒の通常授業。
できるだけ壊したくない予定があります。

教室長は、これを頭の中で分けています。

どこを固定するか。
どこを動かすか。
どの条件を必ず守るか。
どの条件はできれば守るか。
どの講師なら担当できるか。
どの振替候補なら授業として成立するか。
どの追加授業なら既存予定を壊さずに入れられるか。

この判断は、予定表だけを見ても分かりません。

予定表には、結果だけが出ます。
誰が、いつ、どの講師で授業を受けるか。
そこまでは見えます。

でも、なぜその時間なのか。
なぜその講師なのか。
なぜ別の空き枠ではないのか。
なぜその授業は動かさないのか。
なぜその振替はそこに入るのか。
その理由は、予定表だけでは見えません。

ここに、教室長の頭脳があります。

個別指導塾の教室長は、毎月それをやっています。
条件を扱いながら、成立する予定を探しています。
欠席が入れば、既存予定をできるだけ壊さずに、振替先を探しています。
講師変更が入れば、代わりに入れる講師を探しながら、授業として成立するかを判断しています。
追加授業が入れば、他の予定や残コマとの関係を扱いながら入れています。

これは、経験がある教室長ほど自然にやってしまいます。
だから、外からは見えにくいです。
本人も、特別なことをしている感覚がないかもしれません。

でも、新任教室長に任せると難しい。
教室長が変わると、やり方が変わる。
本部から見ると、なぜその予定になったのか分かりにくい。
複数教室で同じ品質にそろえにくい。

つまり、教室長の頭の中にある判断が、予定業務を支えているのです。

公式サイトで確認したところ、shiftect.は、制約条件のもとで人・時間・場所・設備などを割り当てるスケジューリングエンジンとして説明されています。
また、特許出願済の技術として紹介されています。

ここで教室長として気になったのは、特許の細かい内容ではありません。
出願番号や請求項の話をしたいわけでもありません。

気になったのは、予定表そのものではなく、予定を成立させる考え方です。

最初の授業予定をどう作るか。
作った後に欠席が入ったとき、どう振替を扱うか。
講師変更が入ったとき、どこを動かすか。
追加授業が入ったとき、既存予定をどう守るか。
保護者側からの振替申し込みを、単なる空き枠選択ではなく、授業として成立するものとして扱えるか。

ここが、技術として扱われているのだと思いました。

個別指導塾の振替は、単なる日程変更ではありません。
授業予定の再配置です。

しかも、すでに作った予定の中で行う再配置です。
全部を作り直すわけではありません。
一方で、空いているところに置けばよいわけでもありません。

動かしてよい授業と、動かしてはいけない授業を分ける。
そのうえで、必要な部分だけを再調整する。
生徒、講師、教室の条件を満たして、授業として成立する状態に戻す。

これを教室長が手でやっているから、時間がかかります。

そもそも私は、予定調整に追われるために教室長になったわけではありません。
生徒の学習状況を見たい。
講師と授業の話をしたい。
保護者と向き合いたい。
教室を良くしたい。
本来は、そのために教室長をしているはずです。

それなのに、現実には予定作成、欠席対応、振替先探し、講師変更、追加授業の調整に時間を取られます。
教室長の頭の中で処理していることが多すぎるからです。

私が予定作成や振替対応の時間をゼロにしたいと言っているのは、単に作業が面倒だからではありません。
予定を一つ動かすだけで、他の授業、講師の配置、1対2の組み合わせ、保護者に案内済みの予定まで確認し直すことになります。
その確認に追われていると、本来見るべき生徒や授業のことに時間を使えなくなるからです。

毎月の授業予定を手で組む。
欠席のたびに候補を探す。
講師変更のたびに予定表を見直す。
追加授業のたびに既存予定との関係を確認する。
保護者側から振替の申し込みが入るたびに、裏で成立するかを確認する。

ここに教室長の時間を使いたくありません。
予定調整に追われて一日が終わる状態は、教室長として本来やりたい仕事から離れています。

ただし、授業として成立しない予定では意味がありません。
自動で作られても、講師が教科を見られなければ使えません。
自動で振替されても、1対2の組み合わせが崩れていれば使えません。
ブースが足りなかったり、残コマがずれていたり、確定済み予定を壊していたりすれば、結局、教室長が確認することになります。

だから必要なのは、ただの自動化ではありません。
教室長が頭の中でやっている判断を、仕組みとして扱うことです。

shiftect.は、その判断をスケジューリング技術として扱おうとしているように感じました。
そして、shiftect. for EDUCAは、その技術を個別指導塾の予定作成・変更・振替対応に使うためのSaaSです。

教室長の頭の中にある判断は、外からは見えません。
でも、その判断があるから、個別指導塾の予定は毎月なんとか成立しています。

どの授業を動かすか。
どの授業は動かさないか。
どの講師なら担当できるか。
どの振替なら成立するか。
どの追加授業なら既存予定を壊さずに入れられるか。

shiftect.は、この見えにくい判断を、スケジューリング技術として扱おうとしている。
だから、教室長の頭脳を特許に落とし込んだような技術だと感じました。

教室長としては、予定作成と振替対応の時間をゼロにしたい。
本部としては、教室長の経験や記憶に依存している予定業務を、共通の運用基盤にしたい。

その課題を、特許出願済のスケジューリング技術として扱おうとしているところに、shiftect.の意味があるのだと思います。

教室長としても、本部としても、コマ組みを仕組みにしたい

Wed, 01 Jul 2026 22:00:35 +0900

ここまで、個別指導塾の予定作成について書いてきました。

最初は、教室長の仕事が多すぎるという話でした。
授業を見るだけでは終わらない。
保護者対応がある。
講師対応がある。
面談がある。
教室運営がある。
そのうえで、毎月のコマ組みがあります。

さらに、予定表を作った後にも仕事は続きます。
欠席が入る。
振替が必要になる。
講師変更が入る。
追加授業を入れる。
残コマを確認する。
確定済み予定をできるだけ壊さずに再調整する。

これを毎回、教室長が手でやっています。

教室長としては、この時間をゼロにしたいです。
予定作成に時間を使いたくありません。
振替対応にも時間を使いたくありません。
講師変更のたびに予定表を見直したくありません。
追加授業のたびに、既存予定との関係を確認したくありません。
保護者操作による振替のたびに、裏で成立するかを確認したくありません。

ただし、何でも自動で入ればよいわけではありません。
授業として成立しない予定では意味がありません。

個別指導塾の予定は、空いているマスに授業を置くだけでは成立しません。
生徒が来られる時間。
講師が勤務できる時間。
講師が対応できる教科。
講師が対応できる学年。
1対2の組み合わせ。
ブース数。
契約コマ数。
残コマ。
振替分。
確定済み予定。
こうした条件を満たして、初めて授業予定として成立します。

だから、私が求めていたのは、予定表を表示する仕組みではありませんでした。
欠席連絡を受け付ける仕組みだけでもありませんでした。
講師シフトを集める仕組みだけでもありませんでした。
AIに条件を整理してもらうことでもありませんでした。

必要だったのは、授業予定を自動作成し、作成後の欠席・講師変更・保護者操作による振替・追加授業まで一連で扱う仕組みでした。

毎月のコマ組み。
欠席後の振替。
講師変更。
追加授業。
残コマ調整。
確定済み予定を守った再調整。
これらは別々の仕事ではありません。
同じ授業予定の中でつながっています。

ここを分けてしまうと、現場は楽になりません。

自動作成はできる。
でも振替は手作業。
これでは、欠席が入るたびに教室長の仕事が戻ってきます。

振替受付はできる。
でも振替後の予定全体は教室長が確認する。
これでは、保護者操作の裏側で教室長の仕事が残ります。

講師シフトは集められる。
でも授業配置は教室長が決める。
これでは、予定作成の重い部分は残ります。

教室長として本当に変えたいのは、そこです。
毎月の授業予定を手で組む時間。
欠席や振替のたびに候補を探す時間。
講師変更や追加授業のたびに予定表を見直す時間。
保護者操作による振替のたびに成立するか確認する時間。
ここをゼロにしたいのです。

一方で、本部業務として見ると、別の課題もあります。

個別指導塾の予定作成や振替対応は、教室長の経験に依存しやすいです。
どの生徒をどの講師に入れるか。
どの1対2の組み合わせを避けるか。
どの授業を動かしてよいか。
どの授業は動かしてはいけないか。
欠席後の振替をどこに入れるか。
講師変更でどこまで予定を見直すか。
こうした判断が、教室長の頭の中に入りやすいです。

教室長が慣れていれば、何とか回せます。
生徒の都合を覚えている。
講師の得意不得意を覚えている。
保護者の希望も覚えている。
1対2の相性も覚えている。
残コマや振替分も見ながら、予定を組んでいく。

でも、それは仕組みではありません。
教室長の経験と記憶で回している状態です。

本部としては、この状態を変えたいです。
教室長が変わっても、同じ考え方で予定を組めるようにしたい。
新任教室長でも、予定作成や振替対応を回せるようにしたい。
複数教室でも、教室ごとに判断がばらつきすぎないようにしたい。
なぜその予定になったのかを、本部側でも把握できるようにしたい。

特に、個別指導塾の本部は、現場へのグリップが弱くなりやすいです。

コンビニ本部は、商品、仕入れ、物流、POS、販促、店舗運営の型を持っています。
飲食チェーン本部は、メニュー、仕入れ、調理手順、接客、店舗設計、原価管理を持っています。
集団塾本部は、教材、カリキュラム、広告、PR、合格実績づくり、講座設計を提供しやすいです。

一方で、個別指導塾は、授業も、講師配置も、振替対応も、各教室で完結しやすいです。
本部が提供できる価値が、広告、ブランド、募集支援、管理システム、研修に寄りやすくなります。

それだけでは、本部のグリップは強くなりにくいです。
加盟教室や教室長側から見ると、他チェーンへの鞍替えや離脱もしやすくなります。
日々の教室運営の中核を自分たちで回しているなら、本部が変わっても運営できると思われやすいからです。

だからこそ、予定作成と振替対応を仕組みにする意味があります。

個別指導塾の現場で毎月発生している重い業務。
誰を、いつ、どの講師に入れるか。
欠席後の振替をどう扱うか。
保護者操作による振替をどう成立させるか。
講師変更でどこまで動かすか。
追加授業を既存予定にどう入れるか。
この中核業務を、本部側が共通の運用基盤として提供できれば、本部の強みになります。

本部が教室をグリップするためには、各教室に共通の運用基盤を提供する必要があります。
広告やブランドだけではなく、毎月の予定作成、欠席対応、講師変更、保護者操作による振替、追加授業の再調整まで、本部側が仕組みとして提供できることが重要です。

公式サイトで確認したところ、shiftect.は、個別指導塾だけのサービスではなく、制約条件のもとで人・時間・場所・設備などを割り当てるスケジューリングエンジンとして説明されています。
また、将来的には、外部サービスや業界別システムに組み込まれるブラックボックスAPIとして、OEM提供することも想定されているとされています。

そうなれば、個別指導塾本部は、自社ブランドの仕組みとして、各教室に予定作成・変更・振替対応の運用基盤を提供できます。
教室側から見れば、本部から離れることは、広告やブランドを失うだけではありません。
毎月のコマ組み、振替対応、講師変更、追加授業の再調整を支える仕組みを失うことになります。

ここに、本部のグリップ力が生まれると思います。

shiftect. for EDUCAは、個別指導塾の授業予定を自動作成し、保護者操作による自動振替まで一連で扱うSaaSです。

土台にあるshiftect.は、制約条件のもとで予定を成立させるためのスケジューリングエンジンです。
shiftect. for EDUCAは、その土台を個別指導塾の現場業務に接続したものです。

個別指導塾には、個別指導塾特有の条件があります。
講師の対応教科。
講師の対応学年。
1対2の組み合わせ。
ブース数。
契約コマ数。
残コマ。
振替期限。
確定済み予定。
保護者操作による振替。
こうした条件を扱わなければ、授業予定として成立しません。

shiftect. for EDUCAでは、毎月の授業予定作成、欠席対応、講師変更、保護者操作による振替、追加授業、残コマ調整、確定済み予定を守った再調整を一連で扱います。

教室長としては、予定作成と振替対応の時間をゼロにしたい。
本部としては、教室長ごとの経験や記憶に依存している予定業務を、共通の運用基盤にしたい。
この二つは、同じ課題の別の見え方だと思います。

現場では、教室長の時間が削られています。
本部では、各教室の運用が属人化しています。
加盟教室との関係では、本部が握れる中核機能が少なくなりやすいです。

だから、コマ組みを仕組みにしたいのです。

予定表を作るだけではありません。
欠席連絡を受け付けるだけでもありません。
講師シフトを集めるだけでもありません。
AIに条件を整理してもらうだけでもありません。

授業予定を自動作成する。
欠席後の振替を扱う。
保護者操作による振替を、授業として成立する条件の中で扱う。
講師変更が入ったときに、必要な部分を再調整する。
追加授業が入ったときに、既存予定をできるだけ壊さずに入れる。
この一連の予定業務を、仕組みにしたいのです。

教室長としても、本部業務としても、ここを変えたいです。

教室長が毎月手で予定を組み続ける状態を終わらせたい。
欠席や振替のたびに、手で候補を探す状態を終わらせたい。
講師変更や追加授業のたびに、予定表全体を見直す状態を終わらせたい。
本部が、教室長の頭の中にある判断を把握できない状態を終わらせたい。
加盟教室に対して、広告やブランドだけではない本部の強みを持ちたい。

そのために、個別指導塾のコマ組みを仕組みにしたいのです。

shiftect. for EDUCAで、教室長に依存していたコマ組み、変更対応、振替対応を、本部が各教室に提供できる運用基盤にしたいのです。

関連ページ：
shiftect. for EDUCA

shiftect. for EDUCAは、個別指導塾の一連の予定業務をどう扱うのか

Wed, 01 Jul 2026 21:54:39 +0900

ここまで、個別指導塾の予定作成について書いてきました。
毎月のコマ組み。
欠席対応。
講師変更。
保護者操作による振替。
追加授業。
残コマ調整。
確定済み予定を守った再調整。
これらは、別々の仕事のように見えます。

でも、現場ではつながっています。

毎月の予定表を作る。
その予定に欠席が入る。
振替が必要になる。
講師変更が入る。
追加授業を入れる。
残コマを確認する。
確定済みの予定はできるだけ動かさない。
それでも、授業として成立する状態に戻す。

これを、教室長が毎回手でやっています。

教室長としては、この時間をゼロにしたいです。
予定作成に時間を使いたくない。
振替対応に時間を使いたくない。
講師変更のたびに予定表を見直したくない。
追加授業のたびに、既存予定との関係を確認したくない。
保護者操作による振替のたびに、裏で成立するかを確認したくない。

ただし、何でも自動で入ればよいわけではありません。
授業として成立しない予定では意味がありません。

生徒が来られる時間。
講師が勤務できる時間。
講師が対応できる教科。
講師が対応できる学年。
1対2の組み合わせ。
ブース数。
契約コマ数。
残コマ。
振替分。
確定済み予定。
こうした条件を満たして、初めて授業予定として成立します。

だから、個別指導塾に必要なのは、単なる予定表ではありません。
単なる欠席受付でもありません。
単なる講師シフト管理でもありません。
単なるAIによる条件整理でもありません。

必要なのは、授業予定の自動作成と、作成後の変更・振替・追加授業の再調整を、一連の予定業務として扱うことです。

ここで、shiftect.と shiftect. for EDUCA の違いを明確にしておきます。

シフテクト株式会社の公式サイトで詳しく確認したところ、shiftect. は、制約条件のもとで予定を成立させるためのスケジューリングエンジンとして説明されています。
個別指導塾だけのサービス名ではありません。

予定を組む現場では、業界が違っても制約条件があります。
誰が対応できるか。
いつ対応できるか。
どの条件を必ず守るか。
どこを動かしてよいか。
どこを動かしてはいけないか。
どの範囲を再調整するか。
こうした条件の中で、成立する予定を作る必要があります。

その土台になるのが shiftect. です。

一方で、shiftect. for EDUCA は、その shiftect. を個別指導塾向けに使うためのSaaSとして位置づけられています。

個別指導塾には、個別指導塾特有の予定業務があります。
毎月の授業予定作成。
欠席対応。
講師変更。
保護者操作による振替。
追加授業。
残コマ調整。
確定済み予定を守った再調整。
講師の対応教科。
講師の対応学年。
1対2の組み合わせ。
ブース数。
契約コマ数。
振替期限。

shiftect. for EDUCA は、こうした個別指導塾の条件を、shiftect. のスケジューリングエンジンに接続して扱う仕組みです。

つまり、shiftect. は予定を成立させるための土台です。
shiftect. for EDUCA は、その土台を使って、個別指導塾の予定作成・変更・振替対応を一連で扱うSaaSです。

shiftect. for EDUCAで扱いたいのは、個別指導塾の一連の予定業務です。

毎月の授業予定を自動作成する。
欠席が入った授業を振替対象として扱う。
保護者操作による振替を、授業として成立する条件の中で扱う。
講師変更が入ったときに、必要な部分を再調整する。
追加授業が入ったときに、既存予定との関係を確認する。
残コマや振替分を予定作成の中で扱う。
確定済み予定をできるだけ壊さずに再調整する。

これらを別々の機能として並べるだけでは、現場の課題は解決しません。
個別指導塾の現場では、全部が同じ予定表の中で起きているからです。

たとえば、欠席が入ったとします。
欠席を記録するだけなら、それほど難しくありません。
問題は、その後です。

その授業をどこに振り替えるのか。
どの講師が対応できるのか。
その講師は教科と学年に対応できるのか。
1対2の組み合わせは成立するのか。
ブースは足りるのか。
振替期限や残コマは合っているのか。
確定済み予定を壊していないのか。

ここまで確認しなければ、振替は成立しません。

講師変更も同じです。
代わりの講師が空いているだけでは足りません。
その講師で、その授業が成立するかを確認する必要があります。

追加授業も同じです。
空いているところに足すだけでは足りません。
追加したことで、既存予定や振替候補や講師配置が崩れないかを確認する必要があります。

つまり、個別指導塾の予定業務は、作成後の変更まで含めて一つの流れです。

shiftect. for EDUCAでは、この流れを一連で扱えるようにしたいのです。
毎月の授業予定を作るときも、欠席後の振替を扱うときも、講師変更を扱うときも、追加授業を扱うときも、同じ授業予定の中で判断します。

ここで重要なのは、動かしてよい授業と、動かしてはいけない授業を分けることです。

すでに保護者に案内している授業。
講師に伝えている授業。
確定済みの授業。
できるだけ動かしたくない予定があります。

一方で、欠席した授業。
振替対象になった授業。
講師変更が必要な授業。
追加で入れたい授業。
動かす必要がある予定もあります。

全部を作り直すのではなく、必要な部分だけを再調整する。
既存予定をできるだけ守りながら、授業として成立する状態に戻す。
この考え方が、個別指導塾の現場では重要になります。

教室長が手でやっていることも、実際にはこの判断です。
どこを動かすか。
どこを固定するか。
どの条件を必ず守るか。
どの候補なら振替として成立するか。
どの講師なら代わりに入れられるか。
どの追加授業なら既存予定を壊さずに入れられるか。

この判断を、毎回教室長の頭の中だけで行う状態を変えたいのです。

教室長としては、予定作成と振替対応の時間をゼロにしたい。
本部としては、教室長ごとの経験や記憶に依存している予定業務を、共通の運用基盤にしたい。

shiftect. for EDUCAは、そのために、個別指導塾の予定作成、変更、振替、追加授業を一連で扱う仕組みです。

ここを分けてしまうと、意味が変わります。

自動作成はできる。
でも振替は手作業。
これでは、欠席が入るたびに教室長の仕事が戻ってきます。

振替受付はできる。
でも振替後の予定全体は教室長が確認する。
これでは、保護者操作の裏側で教室長の仕事が残ります。

講師シフトは集められる。
でも授業配置は教室長が決める。
これでは、予定作成の重い部分は残ります。

だから、shiftect. for EDUCAで大事なのは、最初の自動作成だけではありません。
保護者操作による自動振替まで、同じ予定業務として扱うことです。
さらに、欠席、講師変更、追加授業が入った後の再調整までつながっていることです。

個別指導塾の教室長にとっては、予定作成と振替対応の時間をゼロにする意味があります。
個別指導塾本部にとっては、各教室で完結しがちな現場運用の中核を、共通の仕組みとして提供できる意味があります。

広告だけではなく、ブランドだけでもなく、管理システムだけでもない。
予定作成、変更、振替対応という、現場で毎月発生している中核業務を仕組みにする。
ここに、shiftect. for EDUCAの意味があります。

個別指導塾本部にとって、予定作成と振替対応を仕組みにする意味

Wed, 01 Jul 2026 21:45:51 +0900

個別指導塾の本部は、現場へのグリップが強くなりにくい。
これは、集団塾、飲食チェーン、コンビニなどと比べると、かなり大きな違いだと思います。

コンビニ本部は、商品を握っています。
仕入れを握っています。
物流を握っています。
POSを握っています。
販促を握っています。
店舗運営の型も持っています。
加盟店から見れば、本部から離れると、商品、物流、仕入れ、システム、販促の多くを失うことになります。

飲食チェーンも同じです。
メニューがあります。
仕入れがあります。
調理手順があります。
接客の型があります。
店舗設計があります。
原価管理があります。
販促があります。
本部が握っている領域が広いので、現場は本部の仕組みの中で運営することになります。

集団塾も、本部が提供しやすいものがあります。
教材。
カリキュラム。
広告。
PR。
合格実績づくり。
講師研修。
経営ノウハウ。
教室運営の型。
集団授業では、同じ教材、同じ進度、同じ講座設計を複数教室に展開しやすい部分があります。

一方で、個別指導塾は少し違います。
授業は、生徒ごとに違います。
講師も教室ごとに違います。
生徒の通える時間も違います。
講師の勤務可能時間も違います。
保護者対応も教室長に寄りやすいです。
講師採用も地域や教室ごとの差が出ます。

そして、予定作成、欠席対応、講師変更、振替対応、追加授業の調整も、各教室で完結しやすいです。

ここが大きいです。

個別指導塾本部が提供できるものは、どうしても広告、ブランド、募集支援、管理システム、研修に寄りやすくなります。
もちろん、それらも大事です。
ただ、それだけでは本部のグリップは強くなりにくいです。

なぜなら、個別指導塾の現場で一番重い運用は、各教室の中で回っているからです。

誰を、いつ、どの講師に入れるか。
どの講師が、どの教科と学年を見られるか。
どの1対2の組み合わせを避けるか。
欠席した授業をどこに振り替えるか。
保護者操作による振替をどう成立させるか。
講師変更が入ったとき、どこまで予定を動かすか。
追加授業を入れるとき、既存予定を壊さないか。

この部分は、個別指導塾の現場運用の中核です。
そして、多くの場合、教室長の経験と記憶に依存しています。

加盟教室や教室長側から見ると、本部が握っている領域が少なければ、他チェーンへの鞍替えや離脱もしやすくなります。
広告やブランドが変わっても、日々の教室運営の多くを自分たちで回しているなら、別の本部に移っても運営できると思われやすいからです。

これは、本部にとってかなり大きな問題です。

コンビニであれば、本部から離れると商品も物流もPOSも仕入れも変わります。
飲食チェーンであれば、メニューも仕入れも調理手順もブランドも変わります。
集団塾であれば、教材、カリキュラム、講座設計、広告、合格実績づくりが変わります。

でも、個別指導塾では、教室長が現場で予定を組み、講師を動かし、振替を処理し、生徒対応をしている場合、本部が変わっても現場運用のかなりの部分は残ってしまいます。
だから、本部の存在価値が広告やブランドだけに寄ると、グリップが弱くなります。

本部としては、ここを変えたいはずです。

個別指導塾本部にとって必要なのは、単に加盟教室を増やすことだけではありません。
各教室が本部の仕組みを使い続ける理由を持つことです。
他チェーンに移ると困るものを、本部が持つことです。
本部だからこそ提供できる現場運用の中核を持つことです。

その意味で、予定作成と振替対応を仕組みにすることは、かなり大きいと思います。

個別指導塾の予定作成は、単なる事務作業ではありません。
生徒、講師、教室の条件を見ながら、授業として成立する予定を作る仕事です。
そして、作った後も、欠席、講師変更、保護者操作による振替、追加授業によって、何度も再調整が必要になります。

この一連の予定業務を各教室任せにしている限り、本部は現場運用の中核を握れません。
教室長ごとにやり方が違う。
教室ごとに振替対応の速さが違う。
講師変更時の判断が違う。
1対2の組み合わせの考え方が違う。
残コマや振替分の扱いも、教室長の確認力に依存する。
こうした状態になります。

本部が本当に強くなるには、この部分を共通の運用基盤にする必要があります。

毎月の授業予定を自動作成する。
欠席が入ったときに、振替対象を扱える。
保護者操作による振替を、授業として成立する条件の中で扱える。
講師変更が入っても、確定済み予定をできるだけ壊さずに再調整できる。
追加授業が入っても、既存予定や残コマとの関係を見ながら扱える。

これが本部の仕組みとして提供できれば、意味は大きく変わります。

教室長の手作業を楽にするだけではありません。
本部が、各教室で完結しがちな現場運用の中核を提供できるようになります。
加盟教室から見ても、その仕組みを使う理由が生まれます。
他チェーンへ鞍替えすると、その運用基盤を失うことになります。

これは、広告やブランドとは違う本部の強みになります。

個別指導塾本部にとって、予定作成・変更・振替対応を仕組みにすることは、単なる業務効率化ではありません。
教室長支援だけでもありません。
本部が各教室を支える中核機能を持ち、離脱や他チェーンへの鞍替えを防ぐための強みになると考えています。

shiftect. for EDUCAは、個別指導塾の授業予定を自動作成し、保護者操作による自動振替まで一連で扱う仕組みです。
毎月の予定作成。
欠席対応。
講師変更。
保護者操作による振替。
追加授業。
残コマ調整。
確定済み予定を守った再調整。
これらを、各教室の教室長だけに任せるのではなく、本部側が共通の運用基盤として提供できるようにすることに意味があります。

個別指導塾の本部は、現場へのグリップが弱くなりやすい。
だからこそ、予定作成と振替対応を仕組みにすることが、本部の強みになります。

広告だけではなく、ブランドだけでもなく、管理システムだけでもない。
現場で毎月発生している、予定作成、変更、振替対応という中核業務を本部が支えられること。
ここに、個別指導塾本部にとってのshiftect. for EDUCAの意味があると思っています。

関連ページ：
shiftect. for EDUCA

本部としては、shiftect. for EDUCAで属人化をなくしたい

Wed, 01 Jul 2026 21:44:12 +0900

個別指導塾の予定作成や振替対応は、教室長の経験にかなり依存しています。
どの生徒をどの講師に入れるか。
どの1対2の組み合わせを避けるか。
どの授業を動かしてよいか。
どの授業は動かしてはいけないか。
振替をどこに入れるか。
講師変更が入ったとき、どこまで予定を直すか。
こうした判断を、教室長が毎回行っています。

教室長としては、その判断をしているつもりはないかもしれません。
毎月の予定作成の中で、自然にやっている。
欠席連絡が来たら、いつものように振替先を探している。
講師変更があれば、頭の中で候補を考えている。
追加授業があれば、空いているところを探して入れている。
現場では、そういう感覚になりやすいです。

でも、本部として見ると、これはかなり危うい状態です。
なぜその予定にしたのかが、本部から見えないからです。

予定表には結果だけが出ます。
火曜日18時にAさん。
水曜日20時にBさん。
土曜日16時にCさん。
このように、誰がいつ授業を受けるかは分かります。

でも、なぜその時間なのか。
なぜその講師なのか。
なぜその1対2なのか。
なぜ別の空き枠を使わなかったのか。
なぜその振替をそこに入れたのか。
なぜその授業を動かさなかったのか。
その理由は、予定表だけでは分かりません。

ここが、属人化です。

本部としては、教室長を責めたいわけではありません。
むしろ、教室長が現場で抱えている判断が多すぎるのだと思っています。
生徒の都合。
講師の都合。
教科。
学年。
1対2。
ブース。
契約コマ数。
残コマ。
振替分。
確定済み予定。
保護者への案内状況。
講師への連絡状況。
これらを同時に見ながら、予定を作り、変更し、振替しています。

この判断を教室長の頭の中だけに置いておくと、本部は運用を標準化できません。
新任教室長に引き継ぐときも難しくなります。
複数教室で同じ品質にそろえることも難しくなります。
本部が支援しようとしても、どこで困っているのかが見えにくくなります。

たとえば、ある教室では振替対応が早い。
別の教室では、振替対応が後回しになり、月末にまとめて調整している。
ある教室では講師固定を強く意識している。
別の教室では空いている講師を優先している。
ある教室では1対2の組み合わせを慎重に見ている。
別の教室では時間が合えば組ませている。

どれが正しいかという話ではありません。
問題は、その判断基準が見えないことです。
本部としては、どの条件を見て判断しているのかを把握したいのです。

KoBEToolで予定表を見ることはできます。
Comiruやwagacoで欠席連絡や振替申請を見ることはできます。
Airシフトで講師の勤務希望を見ることはできます。
ChatGPTやGeminiで条件を整理することもできます。

ただ、それだけでは属人化はなくなりません。
予定表が見えても、なぜその配置になったのかは分かりません。
欠席連絡が見えても、その後の振替先をどう決めたのかは分かりません。
講師シフトが見えても、どの生徒をどの講師に入れるかは決まりません。
条件を文章で整理しても、実際の予定を誰がどう直すかは残ります。

本部としてなくしたいのは、ここです。
予定作成、欠席対応、講師変更、保護者操作による振替、追加授業の判断が、教室長の経験や記憶だけに依存している状態です。

新任教室長が入ったときに、前任者の頭の中を引き継げない。
なぜその生徒はこの講師なのか分からない。
なぜこの1対2を避けていたのか分からない。
なぜこの振替を先に入れていたのか分からない。
なぜこの授業は動かさない前提だったのか分からない。
こういう状態をなくしたいのです。

本部として必要なのは、教室長の判断をなくすことではありません。
現場判断は必要です。
生徒の様子。
講師との相性。
保護者から聞いている希望。
その日の教室の状況。
こうしたものは、現場で見る必要があります。

ただし、予定作成や振替対応の基本部分まで、毎回教室長の頭の中で処理する状態は変えたいです。

どの条件を必ず守るのか。
どの条件はできれば守るのか。
どの授業を固定するのか。
どの授業を動かしてよいのか。
振替はどの条件を満たせば成立するのか。
講師変更ではどこまで予定を見直すのか。
追加授業を入れるとき、既存予定にどう影響するのか。
こうした判断の土台を、仕組みの中で扱えるようにしたいのです。

shiftect. for EDUCAで解決したい属人化は、まさにここです。
毎月の授業予定を自動作成する。
保護者操作による自動振替を扱う。
欠席、講師変更、追加授業が入った後も、同じ条件の中で再調整する。
そのときに、教室長が毎回すべてを手で判断しなくてもよい状態にしたいのです。

属人化をなくすというと、人の判断を消すように聞こえるかもしれません。
でも、そうではありません。
人が判断すべきところと、仕組みで扱うべきところを分けたいのです。

教室長が見るべきなのは、生徒や講師の状態です。
授業の質です。
保護者対応です。
教室の運営です。

一方で、毎月の授業予定を手で組むこと。
欠席のたびに振替候補を手で探すこと。
講師変更のたびに予定表全体を手で見直すこと。
保護者操作による振替のたびに、裏で成立するか確認すること。
ここは、できることなら教室長の手作業から外したいのです。

本部としても、そこを教室長任せにしたくありません。
予定作成と振替対応が教室長ごとに違うと、教室ごとの運用品質も変わります。
教室長が変わると、やり方も変わります。
新任教室長は、前任者の判断を推測しながら進めることになります。
経験のある教室長に確認が集中します。
これでは、複数教室で安定した運用はできません。

本部としては、予定作成・変更・振替対応の属人化をなくしたい。
誰が教室長でも、同じ条件を見て、同じ考え方で予定業務を回せる状態にしたい。
そのうえで、現場ごとの事情は教室長が判断する。
この形にしたいのです。

shiftect. for EDUCAは、個別指導塾の授業予定を自動作成し、保護者操作による自動振替まで一連で扱う仕組みです。
だから、本部としては、予定作成や振替対応を教室長ごとの経験だけに頼る状態から変えられると考えています。

本部としては、属人化をなくしたい。
予定作成も、変更対応も、振替対応も、教室長の頭の中だけで処理される状態を終わらせたい。
そのために、shiftect. for EDUCAで、個別指導塾の一連の予定業務を仕組みにしたいのです。

教室長としては、変更・振替・追加授業の再調整時間もゼロにしたい

Wed, 01 Jul 2026 21:35:25 +0900

毎月のコマ組みに時間を使いたくない。
これは、個別指導塾の教室長としてかなり強い本音です。
ただ、予定作成の時間をゼロにしたいだけでは足りません。

個別指導塾の予定表は、作った後に必ず動きます。
欠席が入ります。
講師変更が入ります。
保護者操作による振替が入ります。
追加授業も入ります。
そのたびに、予定表を見直すことになります。

だから、毎月の授業予定を自動作成できても、その後の変更や振替を教室長が手で直すなら、現場の負担は残ります。
予定表を作る時間がゼロになっても、欠席や振替のたびに教室長が動くなら、結局そこで時間を使います。
私がゼロにしたいのは、そこです。

欠席連絡が来るたびに、振替先を手で探したくありません。
講師変更が入るたびに、代わりの講師を手で探したくありません。
追加授業を入れるたびに、既存予定とのぶつかりを手で確認したくありません。
保護者が振替操作をするたびに、教室長が裏で成立するかを確認する状態にもしたくありません。

教室長としては、変更・振替・追加授業の再調整時間もゼロにしたいのです。

ただし、何でも自動で動けばよいわけではありません。
授業として成立しない変更では意味がありません。

振替先として空いている時間がある。
それだけでは足りません。

講師がいる。
それだけでも足りません。

生徒が来られる。
それだけでも足りません。

その時間に、その生徒を、その講師で入れてよいか。
その講師は教科と学年に対応できるか。
1対2の組み合わせは成立するか。
ブースは足りているか。
振替分として正しく扱えるか。
残コマはずれないか。
確定済み予定を壊していないか。
ここまで見なければ、変更後の予定として成立しているとは言えません。

欠席対応で重いのは、欠席を記録することではありません。
その後に、授業として成立する振替先を決めることです。

振替対応で重いのは、保護者から希望日時を受け付けることではありません。
その希望日時に、本当に授業を入れてよいかを判断することです。

講師変更で重いのは、代わりの講師が空いているかを見ることではありません。
その講師で、その生徒の授業が成立するかを判断することです。

追加授業で重いのは、空いているところに授業を足すことではありません。
追加したことで、既存予定や振替候補や講師配置が崩れないかを確認することです。

ここを教室長が毎回手でやっている限り、予定業務の負担はなくなりません。

shiftect. for EDUCAで解決したいのは、毎月の自動作成だけではありません。
作った後に入る欠席、講師変更、保護者操作による振替、追加授業まで、一連の予定業務として扱うことです。

最初に作った予定には、すでに生徒、保護者、講師の予定が乗っています。
だから、変更が入ったからといって、全部を作り直したいわけではありません。
確定済みの授業はできるだけ守りたい。
保護者に案内済みの予定は動かしたくない。
講師に伝えている予定も壊したくない。
他の生徒の授業もできるだけ動かしたくない。

必要なのは、全部を作り直すことではありません。
動かしてよい授業と、動かしてはいけない授業を分けることです。
そのうえで、必要な部分だけを再調整することです。

欠席した授業。
振替対象になった授業。
講師変更が必要な授業。
追加で入れたい授業。
こうした授業だけを対象にしながら、既存予定をできるだけ壊さずに成立する予定へ戻す。
ここを自動で扱えるようにしたいのです。

保護者操作による振替も同じです。
保護者が候補日時を選ぶだけでは、振替は成立しません。
その候補が授業として成立している必要があります。

その時間に対応できる講師がいるか。
教科と学年は合っているか。
1対2の相手として問題ないか。
ブースは足りるか。
振替期限や残コマの扱いは合っているか。
確定済み予定とぶつからないか。
ここまで満たして、初めて保護者操作による振替を自動で扱えると言えると思います。

単なる空き枠選択では、教室長の仕事はゼロになりません。
保護者が選んだ後に、教室長が裏で確認するなら、結局その時間は残ります。
承認する。
修正する。
別候補を探す。
講師に確認する。
保護者に連絡し直す。
これでは、振替対応の重い部分が残ります。

教室長としては、そこに時間を使いたくありません。
保護者操作による振替も、授業として成立する条件を満たしたうえで自動的に扱えるようにしたいのです。

講師変更も同じです。
ある講師が来られなくなったとき、空いている講師を入れればよいわけではありません。
その講師が、その教科を見られるか。
その学年に対応できるか。
1対2の2人を同時に見られるか。
その生徒との相性は大きく問題ないか。
既存予定を壊さずに入れ替えられるか。
ここまで見ます。

これを毎回、教室長が手で確認していたら、時間はゼロになりません。
講師変更も、予定全体の再調整として扱える必要があります。

追加授業も同じです。
空いているマスに足せばよいわけではありません。
追加授業を入れた結果、他の振替候補が消えることがあります。
講師の余裕がなくなることがあります。
ブースが埋まることがあります。
通常授業や振替分との区別がずれることがあります。
だから、追加授業も一連の予定業務の中で扱う必要があります。

ここまでを別々にすると、現場は楽になりません。

自動作成はできる。
でも振替は手作業。
これでは、欠席が出るたびに教室長の仕事が戻ってきます。

自動振替はできる。
でも講師変更は手作業。
これでは、講師の予定が変わるたびに教室長の仕事が戻ってきます。

追加授業は手で入れる。
これでは、講習期や追加申込のたびにまた予定表を見直すことになります。

個別指導塾の予定業務は、最初の作成だけではありません。
作った後の変更まで含めて一つの仕事です。
だから、自動作成と自動振替と再調整は、分けて考えるものではありません。

同じ生徒。
同じ講師。
同じ教科。
同じ学年。
同じ1対2。
同じブース。
同じ契約コマ数。
同じ残コマ。
同じ確定済み予定。
この同じ授業予定の中で、最初の作成も、振替も、講師変更も、追加授業も起きています。

だから、shiftect. for EDUCAで解決したいのは、一回だけ予定表を作ることではありません。
予定作成、欠席対応、講師変更、保護者操作による振替、追加授業を、一連の予定業務として扱うことです。
そして、教室長が毎回手で候補を探し、手で確認し、手で直す時間をゼロにすることです。

ここは「減らしたい」ではありません。
本音では、ゼロにしたいです。

ただし、授業として成立しない予定では意味がありません。
だからこそ、生徒・講師・教室の条件を満たした自動作成と、その同じ条件の中で行う自動振替が必要になります。

教室長としては、変更・振替・追加授業の再調整時間もゼロにしたい。
毎月の予定作成だけではなく、作成後に続く変更対応まで、教室長の手作業から外したい。
そのために、shiftect. for EDUCAで、予定作成・変更・振替対応を一連の予定業務として仕組みにしたいのです。

教室長としては、shiftect. for EDUCAで毎月のコマ組み時間をゼロにしたい

Wed, 01 Jul 2026 21:32:40 +0900

個別指導塾の教室長として、毎月のコマ組みに時間を使いたくありません。
本音では、ゼロにしたいです。

毎月、生徒の受講可能時間を確認する。
講師の勤務可能時間を確認する。
講師が対応できる教科を確認する。
学年も見る。
1対2の組み合わせを考える。
ブース数を見る。
契約コマ数を見る。
残コマを見る。
振替分も確認する。
これを教室長が手で見比べながら予定表を組む状態は、できることなら終わらせたいです。

予定作成は、教室長の仕事の中でもかなり重いです。
しかも、まとまった時間を取られます。
授業前の準備。
講師対応。
保護者対応。
面談。
教室運営。
そうした仕事がある中で、毎月の予定作成に大きな時間を使うことになります。

教室長としては、本来そこに時間を使いたいわけではありません。
生徒の学習状況を見たい。
授業の質を見たい。
講師と話したい。
保護者対応を丁寧にしたい。
教室全体の状態を整えたい。
本来の教務や運営に時間を使いたいのです。

それなのに、毎月のコマ組みに時間を取られます。

なぜ時間がかかるのか。
理由は、予定表のマスを埋めるだけではないからです。

生徒が来られる時間がある。
それだけでは決まりません。

講師が勤務できる時間がある。
それだけでも決まりません。

ブースが空いている。
それだけでも決まりません。

その講師が、その生徒の教科を担当できるか。
その学年を見られるか。
1対2で組ませてよい相手がいるか。
同じ時間帯に無理な組み合わせになっていないか。
契約コマ数が合っているか。
残コマや振替分がずれていないか。
ここまで見て、ようやく授業として入れられるかを判断できます。

だから、個別指導塾のコマ組みは、単なる予定表作成ではありません。
生徒、講師、教室の条件を満たして、授業として成立する予定を作る仕事です。

これを毎月、教室長が手でやっています。
そこが重いのです。

KoBEToolで予定表を管理できても、最後にどこへ授業を入れるかは教室長が判断しています。
Comiruやwagacoで欠席連絡や振替申請を管理できても、授業予定そのものを組む仕事は別です。
Airシフトで講師の勤務希望を集めても、どの生徒をどの講師に入れるかは決まりません。
ChatGPTやGeminiに条件を整理させても、その予定が授業として成立しているかは教室長が確認することになります。

私が求めているのは、そこではありません。
毎月の授業予定を、生徒・講師・教室の条件を満たした形で自動作成することです。

もちろん、何でも自動で入ればよいわけではありません。
授業として成立しない予定では意味がありません。

講師が教科を見られない。
学年に対応できない。
1対2の組み合わせが悪い。
ブース数を超えている。
契約コマ数が合っていない。
残コマや振替分がずれている。
こうした予定表が自動で出ても、結局、教室長が直すことになります。

それでは意味がありません。

教室長として求めているのは、自動で作られた予定をまた人が全部確認する状態ではありません。
生徒、講師、教室の条件を満たしたうえで、授業として成立する予定を自動作成することです。
そして、教室長が毎月一から条件を見比べて組む時間をゼロにすることです。

shiftect. for EDUCAで解決したいのは、ここです。

毎月の授業予定を、単なる表として作るのではなく、制約条件のもとで授業として成立する予定として作る。
生徒の受講可能時間。
講師の勤務可能時間。
講師の対応教科。
講師の対応学年。
1対2の組み合わせ。
ブース数。
契約コマ数。
残コマ。
振替分。
こうした条件を扱ったうえで、授業予定を作る。

これを、教室長が手でやるのではなく、仕組みとして扱いたいのです。

ここで大事なのは、毎月の自動作成だけで終わらないことです。
個別指導塾の予定は、作った後に必ず動きます。
欠席が入ります。
講師変更が入ります。
保護者操作による振替が入ります。
追加授業も入ります。

だから、毎月の自動作成は、単独の機能として見てはいけないと思っています。
自動作成した予定が、その後の欠席・講師変更・振替・追加授業にもつながっていなければ、現場は楽になりません。

最初だけ自動で作る。
その後は教室長が手で直す。
これでは、結局また教室長の仕事が戻ってきます。

教室長として本当に求めているのは、毎月の予定作成から、その後の変更・振替まで一連で扱うことです。
ただ、その入口として、まず毎月の授業予定を自動作成できることが重要です。

毎月のコマ組み時間をゼロにしたい。
この本音は、かなり強いです。

手で組むことに慣れている教室長ほど、何とかできてしまいます。
生徒の予定を覚えている。
講師の得意不得意を覚えている。
1対2の相性も覚えている。
残コマや振替分も見ながら、何とか組む。
でも、それは教室長の力で無理やり回しているだけです。

本部として見ても、この状態は良くありません。
教室長が変われば、同じように組めるとは限りません。
新任教室長にいきなり任せるのも厳しいです。
複数教室になれば、教室長ごとの差も出ます。
だから、毎月の予定作成を教室長の経験だけに頼る状態は変えたいのです。

shiftect. for EDUCAで毎月のコマ組み課題を解決したい理由は、そこにあります。
予定表を表示するためではありません。
条件を整理するためだけでもありません。
生徒・講師・教室の条件を満たして、授業として成立する予定を自動作成するところに意味があります。

教室長としては、毎月の授業予定作成に時間を使いたくありません。
本音では、ゼロにしたいです。
そのうえで、授業として成立しない予定では意味がありません。

だから、shiftect. for EDUCAで、毎月のコマ組みを自動作成し、その後の変更・振替まで一連で扱いたいのです。

関連ページ：
shiftect. for EDUCA

私が求めていたのは、自動作成と自動振替を一連で扱う仕組みだった

Wed, 01 Jul 2026 21:30:00 +0900

個別指導塾のコマ組みについて調べてきて、ようやく分かってきたことがあります。
私が求めていたのは、単に予定表を管理する仕組みではありませんでした。
欠席連絡を受け付ける仕組みでもありませんでした。
講師シフトを集める仕組みでもありませんでした。
AIに条件を整理してもらうことでもありませんでした。

教室長として本当に求めていたのは、毎月の授業予定を自動で作る仕組みです。
そして、作った後の振替まで自動で扱える仕組みです。

ここを分けて考えると、現場の感覚からずれます。

毎月の予定作成だけ自動化されても、欠席が入るたびに教室長が振替先を探すなら、まだ重いです。
欠席連絡を受け付けられても、その後の振替先を教室長が手で探すなら、まだ重いです。
講師シフトを集められても、どの生徒をどの講師に入れるかを教室長が判断するなら、まだ重いです。
保護者が振替希望を出せても、その候補が授業として成立するかを教室長が毎回確認するなら、まだ重いです。

私がゼロにしたいのは、そこです。

毎月の授業予定を手で組む時間。
欠席や振替のたびに、手で候補を探す時間。
講師変更が入ったときに、予定表を開いて見直す時間。
追加授業を入れるたびに、既存予定との整合を確認する時間。
保護者操作による振替のたびに、生徒、講師、教科、学年、1対2、ブース、残コマを教室長が見比べる時間。

ここに教室長の時間を使いたくありません。
本音では、ゼロにしたいです。

ただし、何でもよいから自動で入ればよいわけではありません。
個別指導塾の予定は、空いているところに授業を置けば終わるものではないからです。

生徒が来られる時間。
講師が勤務できる時間。
講師が対応できる教科。
講師が対応できる学年。
1対2の組み合わせ。
ブース数。
契約コマ数。
残コマ。
振替分。
確定済み予定。
これらを同時に扱わなければ、授業として成立しているとは言えません。

だから、私が求めていた自動作成は、ただマスを埋めることではありません。
生徒、講師、教室の条件を満たして、授業として成立する予定を自動で作ることです。

そして、私が求めていた自動振替も、ただ空いている枠を保護者が選べることではありません。
保護者が振替操作をしたときに、その振替が授業として成立するかまで扱えることです。

この時間に生徒は来られるのか。
講師は勤務できるのか。
その講師は教科と学年に対応できるのか。
1対2の組み合わせは成立するのか。
ブースは足りているのか。
振替分として正しく扱えるのか。
確定済み予定を壊していないのか。

ここまで扱えなければ、振替先として使えるとは言えません。

個別指導塾の振替は、日程変更ではありません。
授業予定の再配置です。
しかも、すでに作った予定の中で行う再配置です。

だから、自動作成と自動振替は別々の話ではありません。
最初に授業予定を作るときも、保護者操作で振替が入るときも、扱う条件はつながっています。

生徒。
講師。
教科。
学年。
1対2。
ブース。
契約コマ数。
残コマ。
振替分。
確定済み予定。

同じ条件の中で、最初の予定も作ります。
同じ条件の中で、振替も扱います。
同じ条件の中で、講師変更や追加授業も見直します。

ここを別々にすると、現場は楽になりません。

自動作成はできる。
でも振替は手作業。
これでは、欠席が出るたびに教室長の仕事が戻ってきます。

振替受付はできる。
でも振替後の予定全体は教室長が確認する。
これでは、保護者操作が入るたびに教室長の判断が戻ってきます。

講師シフトは集められる。
でも授業配置は教室長が決める。
これでは、予定作成の一番重い部分が残ります。

私が求めていたのは、こういう分断された仕組みではありませんでした。
授業予定を自動で作り、保護者操作による振替まで、同じ予定業務の中で扱える仕組みです。

ここで、shiftect. for EDUCAが扱う領域は、これまで見てきた仕組みとは違うと感じました。

予定表を管理するだけではない。
欠席連絡を受け付けるだけではない。
講師シフトを集めるだけではない。
AIに条件を整理させるだけではない。

生徒、講師、教室の条件を満たして授業予定を自動作成する。
作った後に、欠席、講師変更、振替、追加授業が入っても、同じ条件の中で再調整する。
保護者操作による振替も、空き枠選択ではなく、授業として成立するかを扱う。

ここを一連で扱うところに、私は意味があると思っています。

教室長の時間を使わない状態にしたい、というだけなら、言葉としては簡単です。
でも、実際にそうなるには、予定作成と振替対応の時間が消えなければ意味がありません。
予定表を作った後に欠席が入るたび、教室長がまた手で探すなら変わりません。
保護者が振替操作をするたび、教室長が裏で確認するなら変わりません。

教室長としては、そこに時間を使いたくありません。
予定作成にも、振替対応にも、教室長の時間を使わない状態にしたいのです。

もちろん、授業として成立しない予定では意味がありません。
自動で作られても、講師が教科を見られなければ使えません。
自動で振替されても、1対2の組み合わせが崩れていれば使えません。
ブースが足りなかったり、残コマがずれていたり、確定済み予定を壊していたりすれば、結局、教室長が確認することになります。

だから必要なのは、ただの自動化ではありません。
生徒、講師、教室の条件を満たした自動作成です。
そして、その同じ条件の中で行う自動振替です。

ここまで来て、私が求めていたものがはっきりしました。
私が求めていたのは、自動作成と自動振替を一連で扱う仕組みでした。

毎月の授業予定を自動で作る。
作った後の欠席や講師変更にも対応する。
保護者操作による振替も、授業として成立するかを扱う。
追加授業が入っても、既存予定をできるだけ壊さずに再調整する。

この一連の予定業務を、教室長が毎回手で判断しなくても済む状態にしたい。
そのために、shiftect. for EDUCAで、自動作成と自動振替を一連の予定業務として扱いたいのです。

関連ページ：
shiftect. for EDUCA

私が求めていたのは、生徒・講師・教室の条件を満たして授業を成立させ続ける仕組みだった

Wed, 01 Jul 2026 21:05:46 +0900

個別指導塾のコマ組みについて、ここまでいろいろ書いてきました。
KoBEToolのような予定表管理。
Comiruやwagacoのような連絡管理や振替受付。
Airシフトのような講師シフト管理。
ChatGPTやGeminiのような対話型AI。
コマグミくん、塾コマ、T-sixのようなコマ組みや時間割作成に近い仕組み。
FREEMINDのMK5 Engineのような座席配当や個別配当。
それぞれを見てきました。

どれも役割はあります。
予定表を見やすく管理すること。
欠席連絡や振替希望を受け付けること。
講師の勤務希望を集めること。
時間割やコマ割りを作ること。
座席や個別配当を考えること。
条件を整理すること。
こうした役割は、個別指導塾の運営に関係しています。

ただ、ここまで見てきて、ようやくはっきりしました。
私が求めていたのは、そのどれか一つではありませんでした。

予定表を管理したいだけではありません。
欠席連絡を受け付けたいだけでもありません。
講師の勤務希望を集めたいだけでもありません。
AIに条件を整理してほしいだけでもありません。
最初のコマ割りだけを作りたいわけでもありません。

私が求めていたのは、生徒・講師・教室のいろいろな条件を満たしながら、授業として成立する予定を作る仕組みでした。
そして、作った後に欠席・講師変更・振替・追加授業が入っても、既存予定をできるだけ壊さずに、授業として成立する状態へ戻し続ける仕組みでした。

個別指導塾の予定作成は、空いている時間を探すだけでは終わりません。
空き枠がある。
それだけでは授業は入れられません。

生徒が来られる。
それだけでも授業は入れられません。

講師が空いている。
それだけでも授業は入れられません。

その時間に、その生徒を、その講師で、その教科で、その学年で入れてよいか。
1対2なら、相手になる生徒との組み合わせは問題ないか。
ブースは足りているか。
契約コマ数は合っているか。
残コマや振替分は正しく扱われているか。
確定済み予定を壊していないか。
ここまで見て、ようやく授業として入れてよいかを判断できます。

ここが、個別指導塾のコマ組みで本当に重いところです。

予定表のマスだけを見れば、空いているように見える時間はあります。
でも、そこに授業を入れられるかどうかは別です。
講師がいても、教科が合わないことがあります。
教科が合っても、学年が合わないことがあります。
生徒が来られても、1対2の組み合わせが難しいことがあります。
ブースが空いていても、残コマや振替分の扱いがずれることがあります。
候補があっても、確定済み予定を動かす必要が出ることがあります。

だから、個別指導塾の予定作成は、単なる予定表作成ではありません。
授業として成立するかどうかを見続ける仕事です。

これは、最初の予定作成だけの話でもありません。
欠席連絡が1件来るだけで、また同じ判断が必要になります。
振替先を探すときも、同じ条件を見ます。
講師変更が入ったときも、同じ条件を見ます。
追加授業を入れるときも、同じ条件を見ます。
講習期になれば、通常期とは違う日付単位の条件も重なります。

つまり、予定作成、欠席、講師変更、振替、追加授業は別々の仕事ではありません。
同じ授業予定の中で起きている、一連の業務です。

ここを分けて考えると、現場の負担は見えなくなります。
予定表は作れる。
でも、欠席後の振替は別。
欠席連絡は受け付けられる。
でも、振替後の予定全体は別。
講師シフトは集められる。
でも、どの生徒をどの講師に入れるかは別。
AIで条件は整理できる。
でも、その結果を実際の授業予定として成立させるのは別。
これでは、教室長の仕事は軽くなりません。

教室長が毎回やっているのは、情報を眺めることではありません。
それらの情報を重ねて、授業として成立する配置を決めることです。

生徒の都合。
講師の都合。
教科。
学年。
1対2。
ブース。
契約コマ数。
残コマ。
振替分。
確定済み予定。
保護者への案内状況。
講師への連絡状況。
こうしたものを見ながら、どこに授業を入れるかを決めています。

さらに、作った予定を簡単には壊せません。
一度決めた予定には、生徒、保護者、講師の予定が乗っています。
だから、欠席や振替が入っても、全部を作り直したいわけではありません。
動かしてよい授業と、動かしてはいけない授業を分けたい。
必要なところだけ直したい。
既存予定をできるだけ守りたい。
これが現場の感覚です。

ここまで来て、私が探していたものが何だったのかが見えてきました。

私が探していたのは、予定表を表示する仕組みではありませんでした。
振替希望を受け付ける仕組みでもありませんでした。
講師シフトを集める仕組みでもありませんでした。
AIに表を作ってもらうことでもありませんでした。

生徒・講師・教室の条件を満たしながら、授業として成立する予定を作ること。
作った後も、欠席・講師変更・振替・追加授業に合わせて、必要な部分だけを再調整すること。
この一連の予定業務を扱う仕組みを求めていたのだと思います。

shiftect. for EDUCAを見たとき、ここがこれまで見てきた仕組みと違うと感じました。
予定表を作ることだけを見ているのではなく、授業として成立するかどうかを見ている。
欠席や振替を、予定表の外側にある別作業として見るのではなく、同じ授業予定の中で起きる変更として扱う。
この考え方が、私が求めていたものに近いと感じました。

もちろん、教室長の判断が不要になるわけではありません。
生徒の様子。
講師との相性。
保護者から聞いている希望。
その日の教室の状況。
こうしたものは、現場で見る必要があります。

ただ、その判断をすべて教室長の頭の中だけで抱える状態は変えたいのです。
どの条件を見ているのか。
どの授業を固定するのか。
どの授業を動かしてよいのか。
どの振替を優先するのか。
どの組み合わせを避けるのか。
こうした判断の材料を、予定業務の中で扱えるようにしたいのです。

本部としても、ここは重要です。
予定表だけを見ても、なぜその配置になったのかは分かりません。
なぜその振替をそこに入れたのか。
なぜその講師にしたのか。
なぜその1対2を避けたのか。
なぜその授業を動かさなかったのか。
この理由が見えないと、教室長ごとの経験や記憶に依存した運用になります。

複数教室で同じ考え方で運用するには、予定作成・変更・振替を一連で扱う必要があります。
予定作成だけ標準化しても足りません。
欠席連絡だけ管理しても足りません。
講師シフトだけ集めても足りません。
それらを使って、授業として成立する予定にし続けるところまで見なければ、本部としては標準化できません。

だから、私が求めていたのは、生徒・講師・教室の条件を満たして授業を成立させ続ける仕組みでした。
予定作成、欠席、講師変更、振替、追加授業を分断せず、一連の予定業務として扱う仕組みです。

その考え方を、個別指導塾向けに扱うものとして見ているのが、shiftect. for EDUCAです。

関連ページ：
shiftect. for EDUCA

個別指導塾のコマ組みで見ると、各サービスの役割はかなり違う

Wed, 01 Jul 2026 20:47:25 +0900

個別指導塾のコマ組みについて調べていくと、いろいろなサービスやAIが出てきます。
名前だけを見ると、どれも近いものに見えます。
ただ、実際に扱っている領域はかなり違います。

ここまでの記事で見てきたものを、あらためて一行ずつ整理しておきます。

KoBEToolは、個別指導塾のコマ管理、座席表、スケジュール管理を扱う仕組みです。

Comiruは、保護者連絡、指導報告、入退室、請求など、塾と保護者・生徒のコミュニケーションや業務管理を扱う仕組みです。

wagacoは、塾やスクールの生徒管理、予約・振替管理、指導報告、連絡、決済などを扱う仕組みです。

Airシフトは、スタッフの希望シフト収集やシフト表作成を扱う仕組みです。

らくしふは、シフトの回収、作成、共有などを扱う汎用的なシフト管理の仕組みです。

oplusは、シフト管理や勤怠管理を扱う汎用的なシフト管理の仕組みです。

コマグミくんは、学習塾・個別指導教室の時間割やカリキュラム作成に近い仕組みです。

塾コマは、講師と生徒の予定をもとにコマ割りを自動作成する仕組みです。

T-sixは、生徒個別の月間カレンダー、教室掲示用の日別カレンダー、講師用スケジュールを扱う時間割自動作成ソフトです。

FREEMINDのMK5 Engineは、個別指導の座席配当や個別配当を扱う仕組みです。

atama＋は、AIを用いた学習システムとして、学習内容や演習を支援する仕組みです。

Qubenaは、児童・生徒の習熟度に合わせて問題を出すAI型教材です。

ChatGPTは、条件整理、考え方の言語化、文章作成などに使える対話型AIです。

Geminiは、文章作成、計画、アイデア出しなどに使える対話型AIです。

shiftect. for EDUCAは、個別指導塾の授業予定を自動作成し、保護者操作による自動振替まで一連で扱うスケジューリングSaaSです。

こうして並べると、同じように「塾」「予定」「シフト」「AI」に関係しているように見えても、役割はかなり違います。

予定表を管理する仕組みがあります。
保護者連絡や振替申請を管理する仕組みがあります。
講師の勤務希望を集める仕組みがあります。
時間割やコマ割りを作成する仕組みがあります。
座席配当や個別配当を扱う仕組みがあります。
学習内容を支援するAI教材があります。
条件を整理してくれる対話型AIがあります。

それぞれに役割があります。
ただ、教室長として本当にゼロにしたいのは、予定表を見る時間ではありません。
欠席連絡を受け付ける時間だけでもありません。
講師シフトを集める時間だけでもありません。
AIに条件を整理してもらう時間だけでもありません。

ゼロにしたいのは、毎月の授業予定を手で組む時間です。
欠席や振替のたびに、手で候補を探す時間です。
講師変更や追加授業のたびに、予定表全体を見直す時間です。
保護者操作による振替が入るたびに、教室長が生徒、講師、教科、学年、1対2、ブース、残コマを見比べる時間です。

だから、単に予定表が見えるだけでは足りません。
欠席連絡を受け付けるだけでも足りません。
講師シフトを集めるだけでも足りません。
AIに条件を整理してもらうだけでも足りません。

個別指導塾のコマ組みで本当に問題になるのは、予定作成、欠席、講師変更、振替、追加授業が同じ授業予定の中でつながっているかどうかです。
そして、その一連業務を、教室長が毎回手で判断しなくても済む状態にできるかどうかです。

その意味で、shiftect. for EDUCAは、予定表管理、連絡管理、講師シフト管理、AI教材、対話型AIとは違う位置にある仕組みです。

私が探していたのは、予定表を作るだけの仕組みではありません。
生徒、講師、教室の条件を満たして授業予定を自動作成し、保護者操作による振替まで、授業として成立するかを見たうえで自動的に扱える仕組みです。

各サービスの役割を分けることで、shiftect. for EDUCAで扱いたい課題もはっきりしました。