既存のスケジューリングシステムの多くは「与えられた条件で計算する」という構造で設計されている。
条件を入力し、システムが計算し、結果を出す。
この構造は初回の時間割生成には機能する。
しかし日常業務には耐えられない。
なぜか。
個別指導塾の時間割は、生成した瞬間から変化し続ける。
欠席、講師の変更、新規入会、条件の更新。
これらは毎日発生する。
「与えられた条件で計算する」システムは、変化が起きるたびに全ての条件を再入力して全体を再計算することを前提にしている。
しかし全体を再計算すれば、確定済みの配置が変わる可能性がある。
確定済みの配置が変われば、生徒・講師・保護者への連絡が発生する。
これが毎日繰り返されるとすれば、現場で運用することはできない。
問題はさらに深い。
月曜日の16時に講師Aと授業が入っている生徒Bが、今週だけ月曜日に来られないと連絡してきたとする。
このとき管理者が解かなければならない問題は、「全ての生徒と講師を最初から組み直す」ことではない。
すでに確定している他の生徒・講師の配置はそのままにしながら、生徒Bだけを別の日時に動かせる空きがあるかどうかを探すことだ。
しかもその空きは、生徒Bが来られる時間帯であり、講師Aまたは代替可能な講師が勤務しており、教室に席があり、NGペアの生徒がいない、という全条件を満たす必要がある。
これは「新しい問題を最初から解く」のではなく、「すでに成立している配置の上で、特定の変化だけを吸収する」という問題だ。
「与えられた条件で計算する」最適化とは、問題の構造が根本から異なる。
shiftect.はこの区別を制御構造の出発点に置いている。
業務の状態に応じて、何を前提条件として固定し、何を探索対象とするかをシステムが自動的に決定する。
初回の全体生成、確定済み配置を固定した再生成、振替先だけを探索する自動振替。
これらは全て、同一の制御構造で処理される。
「与えられた条件で計算する」のではなく、「業務の状態に応じて問題の構造を決める」という一段上の制御が、shiftect.の核心だ。
この制御構造が、特願2026-026989として出願している技術の本体であり、shiftect. for EDUCAが日常のスケジュール管理を極限までなくし、本来の業務を遂行できる環境を作り出せる理由だ。