勤務表の設計は2012年8月を使う

2012年8月は、31日あり、土日回数が8回です。月単位で勤務表を作成している職場では、一番つらい月になります。ですから、この月で検証しておくことは、勤務表設計で意味があります。

前回行った正循環は、2019年11月で、祝があり、しかも30日、公休が9、計10の休みがあり、楽な月です。そこで、厳しい月、2012年8月でも可能かどうかを検証します。
この月は、公休8で、祝もありません。

求解し、もっとも厳しい月でも完全正循環が実現可能なことが分かりました。

ところで、目的関数値が2000になっています。
重み1000に対応するのは、行制約レベル6です。
そこで、行制約レベル6の記述を確認します。

夜勤回数8回が満足できていない箇所が1000x2=2000ですから、2箇所あることが分かります。
一番上の図の左ペインを見ると、確かに、夜勤回数が9回(=5+4)になっているスタッフが2人いることが分かります。
重み1000の脇の許容エラーは、１に設定されています。これは、制約8回Maxのところ、1だけ緩和して9回までは許すことを意味しています。つまり9回Maxでハード制約されています。
もし、9回のスタッフが一人いるとエラーカウント１になります。8回のスタッフは、エラーカウント0です。
このように許容エラーは、ソフト制約が際限なく緩和されることを防止する働きがあります。
（ちなみに、許容エラー0にするとハード制約8回Maxという意味になります。）

ところで、9回のスタッフが2人出ることが分かりましたが、これを数学的に確かめてみましょう。

夜勤可能スタッフは、23人、31日稼動、深夜3人、準夜勤3人ですから、

夜勤可能数スタッフ23人、夜勤回数8回で、可能か？
	スタッフ数	日数	必要コマ数
準夜勤	3	31	93
深夜勤	3	31	93
			186
	夜勤回数	夜勤可能スタッフ数	可能コマ数
	8	23	184

これより、必要コマ数に対して2コマ足りないことが分かります。23人8回で廻すことは不可能で、
9回の人が2人、もしくは、10回の人が1人必要なことが分かります。ところで、10回は、上記制約で
禁止されているので、必ず9回の人が2人発生する、ということになります。

<許容エラーの役割>
もし許容エラーという制約がないものとすると、9回2人、10回1人どちらもCost=2000で、Costに差がありません。ソルバは、の仕事は、目的関数値の最小化だけであり、どちらに転ぶかは制御できません。つまり10回の人が1人発生する可能性があることになります。

以上は、希望年休を全く取っていない検討ですが、実場面では、さらに厳しくなります。希望休みは、予め決められた予定を入れてシミュレーションをお勧めします。

本プロジェクトは、OneDriveプロジェクトサンプル/完全正循環　フォルダにあります。
公式リリース時にも、同フォルダにプロジェクトはあります。