shiftect. for EDUCAについて調べている中で、shiftect.は特許出願済の技術だと知りました。
最初は、個別指導塾向けのスケジューリングSaaSだと思っていました。
毎月の授業予定を自動作成する。
欠席や講師変更に対応する。
保護者側からの振替申し込みまで扱う。
そういう仕組みとして理解していました。
ただ、特許出願済という言葉を見て、少し受け止め方が変わりました。
これは、単なる予定表作成ではないのだと思います。
教室長が頭の中でやっている判断を、スケジューリング技術として扱おうとしているのだと感じました。
個別指導塾の予定作成は、外から見ると、時間割を作っているだけに見えるかもしれません。
でも、現場でやっていることは、まったく単純ではありません。
どの生徒が、いつ来られるか。
どの講師が、いつ勤務できるか。
その講師は、どの教科を担当できるか。
どの学年まで見られるか。
1対2で組ませてよい組み合わせか。
ブースは足りているか。
契約コマ数は合っているか。
残コマはずれていないか。
振替分は正しく扱えているか。
確定済み予定を壊していないか。
こうした条件を、教室長は毎月の予定作成の中で扱っています。
さらに、予定表を作った後にも判断があります。
欠席が入ったとき。
振替が必要になったとき。
講師変更が入ったとき。
追加授業を入れるとき。
保護者側から振替の申し込みが入るとき。
そのたびに、教室長は予定表を見直します。
ただし、全部を作り直すわけではありません。
すでに保護者に案内している予定があります。
講師に伝えている予定があります。
確定済みの授業があります。
他の生徒の授業もあります。
だから、予定が動いたときには、どの授業を動かしてよいか、どの授業は動かしてはいけないかを分ける必要があります。
ここが、個別指導塾の予定作成でかなり難しいところです。
欠席した授業は動かす必要があります。
振替対象になった授業も動かす必要があります。
講師変更が必要な授業もあります。
追加で入れたい授業もあります。
一方で、動かしたくない授業もあります。
すでに確定している授業。
保護者に伝えている授業。
講師に伝えている授業。
他の生徒の通常授業。
できるだけ壊したくない予定があります。
教室長は、これを頭の中で分けています。
どこを固定するか。
どこを動かすか。
どの条件を必ず守るか。
どの条件はできれば守るか。
どの講師なら担当できるか。
どの振替候補なら授業として成立するか。
どの追加授業なら既存予定を壊さずに入れられるか。
この判断は、予定表だけを見ても分かりません。
予定表には、結果だけが出ます。
誰が、いつ、どの講師で授業を受けるか。
そこまでは見えます。
でも、なぜその時間なのか。
なぜその講師なのか。
なぜ別の空き枠ではないのか。
なぜその授業は動かさないのか。
なぜその振替はそこに入るのか。
その理由は、予定表だけでは見えません。
ここに、教室長の頭脳があります。
個別指導塾の教室長は、毎月それをやっています。
条件を扱いながら、成立する予定を探しています。
欠席が入れば、既存予定をできるだけ壊さずに、振替先を探しています。
講師変更が入れば、代わりに入れる講師を探しながら、授業として成立するかを判断しています。
追加授業が入れば、他の予定や残コマとの関係を扱いながら入れています。
これは、経験がある教室長ほど自然にやってしまいます。
だから、外からは見えにくいです。
本人も、特別なことをしている感覚がないかもしれません。
でも、新任教室長に任せると難しい。
教室長が変わると、やり方が変わる。
本部から見ると、なぜその予定になったのか分かりにくい。
複数教室で同じ品質にそろえにくい。
つまり、教室長の頭の中にある判断が、予定業務を支えているのです。
公式サイトで確認したところ、shiftect.は、制約条件のもとで人・時間・場所・設備などを割り当てるスケジューリングエンジンとして説明されています。
また、特許出願済の技術として紹介されています。
ここで教室長として気になったのは、特許の細かい内容ではありません。
出願番号や請求項の話をしたいわけでもありません。
気になったのは、予定表そのものではなく、予定を成立させる考え方です。
最初の授業予定をどう作るか。
作った後に欠席が入ったとき、どう振替を扱うか。
講師変更が入ったとき、どこを動かすか。
追加授業が入ったとき、既存予定をどう守るか。
保護者側からの振替申し込みを、単なる空き枠選択ではなく、授業として成立するものとして扱えるか。
ここが、技術として扱われているのだと思いました。
個別指導塾の振替は、単なる日程変更ではありません。
授業予定の再配置です。
しかも、すでに作った予定の中で行う再配置です。
全部を作り直すわけではありません。
一方で、空いているところに置けばよいわけでもありません。
動かしてよい授業と、動かしてはいけない授業を分ける。
そのうえで、必要な部分だけを再調整する。
生徒、講師、教室の条件を満たして、授業として成立する状態に戻す。
これを教室長が手でやっているから、時間がかかります。
そもそも私は、予定調整に追われるために教室長になったわけではありません。
生徒の学習状況を見たい。
講師と授業の話をしたい。
保護者と向き合いたい。
教室を良くしたい。
本来は、そのために教室長をしているはずです。
それなのに、現実には予定作成、欠席対応、振替先探し、講師変更、追加授業の調整に時間を取られます。
教室長の頭の中で処理していることが多すぎるからです。
私が予定作成や振替対応の時間をゼロにしたいと言っているのは、単に作業が面倒だからではありません。
予定を一つ動かすだけで、他の授業、講師の配置、1対2の組み合わせ、保護者に案内済みの予定まで確認し直すことになります。
その確認に追われていると、本来見るべき生徒や授業のことに時間を使えなくなるからです。
毎月の授業予定を手で組む。
欠席のたびに候補を探す。
講師変更のたびに予定表を見直す。
追加授業のたびに既存予定との関係を確認する。
保護者側から振替の申し込みが入るたびに、裏で成立するかを確認する。
ここに教室長の時間を使いたくありません。
予定調整に追われて一日が終わる状態は、教室長として本来やりたい仕事から離れています。
ただし、授業として成立しない予定では意味がありません。
自動で作られても、講師が教科を見られなければ使えません。
自動で振替されても、1対2の組み合わせが崩れていれば使えません。
ブースが足りなかったり、残コマがずれていたり、確定済み予定を壊していたりすれば、結局、教室長が確認することになります。
だから必要なのは、ただの自動化ではありません。
教室長が頭の中でやっている判断を、仕組みとして扱うことです。
shiftect.は、その判断をスケジューリング技術として扱おうとしているように感じました。
そして、shiftect. for EDUCAは、その技術を個別指導塾の予定作成・変更・振替対応に使うためのSaaSです。
教室長の頭の中にある判断は、外からは見えません。
でも、その判断があるから、個別指導塾の予定は毎月なんとか成立しています。
どの授業を動かすか。
どの授業は動かさないか。
どの講師なら担当できるか。
どの振替なら成立するか。
どの追加授業なら既存予定を壊さずに入れられるか。
shiftect.は、この見えにくい判断を、スケジューリング技術として扱おうとしている。
だから、教室長の頭脳を特許に落とし込んだような技術だと感じました。
教室長としては、予定作成と振替対応の時間をゼロにしたい。
本部としては、教室長の経験や記憶に依存している予定業務を、共通の運用基盤にしたい。
その課題を、特許出願済のスケジューリング技術として扱おうとしているところに、shiftect.の意味があるのだと思います。
- 前ページ
- 次ページ