変則２交代の希望シフト統計を基に実装に関する一考察

次のような体感統計となりました。

１位：休み

２位：明休

３位：入（休入、日入)

４位：日

１位の休みは、当然として、意外に多いのが、明けの後の休み、これは、明けの後の休みが当然ではない、の裏返しではないでしょうか？

３位の入りは、休入、日入まで、指定したものがあります。これは、長入明パターンを阻害します。

「明けの後の２連休を出来る限り多く」、というのが多くの職場で要求されるパターンですが、それに関して、最も効率がよいのは、長入明パターンだけで構成される職場です。

仮に、入り回数が４回以下という条件であれば、

長入明休休..長入明休休..長入明休休..長入明休休

という状態となり、４週８休の条件下で、全ての明けを２連休とできる可能性が高まります。

入り回数が５回以上なら、その条件は物理的に満たせません。

理想的には、

■入り回数４回以下

■全員、長入明パターンのみ

■勤怠システムは、長入り差を＋-１まで許容する

であることです。長入明パターンのみで構成されれば、長入差は、自動的に＋－１以内となり、重い＝＝制約を使わなくてもよくなります。

しかし、現実には、

■入り回数５回以上がある。（職場によっては、殆ど６回のところもある）

■上記のように個人の希望により、長入明パターンだけには、できない。

■勤怠システムのなかには、長入差は、＋－０を強制される場合がある

等により、上記理想条件をキープ出来ずに、２連休達成は、物理的に不能な場合が存在します。また、長入パターンだけに出来なければ、長勤務者数、入り勤務者数を揃えるために、また、新たな勤務、単独長(長休）,遅出　等が必要になってきます。そうすると、長入差を埋めるための、非番や、半休といったものが必要となり、複雑な条件を達成するため、求解性能の劣化が懸念されます。

上記希望シフトに着目します。それは、長日希望が一つもないことです。数ある希望シフトで、長日が一つもないということは、出来れば長日はやりたくない、ということが伺えます。それに対して、入り希望はあり、長入明パターンを阻害する希望シフトが入り込むことがありえます。

以上の知見から、次のような二つのグループに分ける発想を得ました。

■A　長入明パターンだけのグループ

■B  長だけ、単長あり、休入、日入り等、イレギュラーパターンを含むグループ

Aグループだけで、見れば、長入明勤務者数列は、常に自動的に一緒になります。また、長入差は、自動的に各スタッフで＋－１を保証できます。

Bグループだけで見ると、長入明勤務者数は、一緒になりません、また、長入差も存在することになります。長だけの人は、半休もしくは非番とセットにする必要があります。Aグループの長入明勤務者数は、常に一緒であるので、Bグループの長入明勤務者数も常に一緒であることが必要です。つまり、Aグループ、Bグループ単位で長入明勤務者数が一緒である必要があります。具体的には、Bグループに長だけ行う人だけが場合は、長入明勤務者数一緒列が常に成立しないので、長を行わないことがあるスタッフを組み入れる必要があります。（月毎にグループ人員を入れ替える案もあります。）

このようにする背景は、Aグループが大半とし、少数のBグループとすることで、煩雑な部分を限定することができ、結果として、処理速度の向上、結果的に、明け後２連休の達成度を上げることにつながる、ということがあります。

本来は、全スタッフをBグループとしても、同じ求解品質となることが理想ですが、残念ながらそうではありません。Aグループは、シンプルパターンのみ構成され、一見自由度がないように見えますが、行列の要件に対して達成しやすいパターンであるとも言えます。解空間は減少しているように思えますが、真の解に近いパターンのみが生き残り易いとも考えられます。

それに対して、Bグループは、煩雑なシフトに対して、行列要件を満たすことが必要となります。特に＝＝処理は、AL1にとって重い処理となります。

Bグループでは、Bグループパターン用の特入りを追加します。(Aグループ内では、特入りは、不可です。)

これは、日特入、休特入を可能にする入りです。希望シフトでこれを記入することが可能となります。また、Bグループでは、各スタッフ、

■長日数<=２＊非番数＋半休＋特入り

■長日数＞＝特入り-１

に制約します。これにより、長の余り数は＋０－１に制約されます。

この処理が重いのは、多数のシフトがこの等式に拘わっていて、なおかつ、>=と<=により両サイドから制約されることにあります。なので、Bグループはなるべく小さく、しかし、十分にBグループ内で、長入明勤務者数列が一緒に出来るようなスタッフ数としてください。

通常は、ソルバの性質にユーザは深く立ち入る必要はないのですが、こと長日数差が制約として必要となる場合は、以上のような観点での制約設計とすることが、皆の幸せにつながる(希望の通り易さ）と思います。

なお、長日数差が勤怠システムの中で制約の必要なければ、非番、半休は必要ないし、＝＝処理も不要となるので、上記のような面倒なことは、必要ありません。