PHS待機問題の対応構想

なるべくPythonでの記述をなくして、GUIだけで記述できないかを検討しました。

新しく、PhaseVarというオブジェクトを作れば、対応できそうだ、という結論に至りました。

PhaseVarというのは、PhaseとTask・Task集合を結びつけるオブジェクトになります。

PhaseVar
PhaseVar名	ラベル	色	Phase0(午前）	Phase1(午後）	Phase2(拘束）
日勤			日	日
午前			日
午後				日
拘束日勤			日	日	拘束集合
午後拘束				日	拘束集合
午前拘束西			日		西

 さらにPhaseVarの集合を定義すればより汎用的でしょう。
（また、PhaseVarは、OneDayに限定されることはない、翌日に跨ってもよさそうです。）

例えば、日勤は、午前午後共　働くという意味の変数になります。午前という変数は、Phase0上に日(Task)があったときにアサートされる変数です。日勤拘束という変数は、日勤の上にさらに拘束集合(TaskAggregate)がアサートされる変数です。このように、シフトベースで作っていたシフトラベル名が、フェーズで改めて明確に定義されるという風にも理解できます。

こうしたオブジェクト郡を定義して行制約で使えるようにします。この構想にすると、設計構造上、大変更が必要になってしまいます。今までTask周りは、殆どPythonのお世話にならずには書けない事態に陥っていましたが、逆に殆どPythonを使わずに書ける可能性が出てきました。また、Python制約では、基数制約については、GUI表示を実現していますが、その他については、計数表示できない、複数解に対応していない等、色々制限があります。これら諸問題も同時にクリアできます。

これらの実装には、一ヶ月程度かかると思います。AWS対応以上に変更インパクトがあります。SC3正式リリース、及びAWS　DOCKER対応は、上記問題の解決後としておよそ6週間遅延します。

大変大きなインパクトではありますが、Pythonを500行書くよりは、GUI数十行で済ませたい、実際に書いてみて、切にそう思いました。