＜シフト数が多すぎる＞
シフト数は、25程度を目安としてそれ以下になるように心がけてください。
次は、良くない例です。
■業務外日勤カウントあり
■業務外日勤カウントなし
という二つの非自動化シフトにすれば、十分だと思います。その他は、上の別名にすればOKではないでしょうか？ 勿論、管理を別にする必要がある（例えば、個別に人数を制約する必要がある）場合には、使えませんが、同じ管理でよければ、同じシフトにしてシフトの削減を行うべきです。
別名にすれば、メモリを食いませんので、いくら定義してもソルバの負担にはなりません。このお客さまの場合、こうした感じで50以上のシフトが定義されていました。この状態では、ソルバの負担は、測り知れないことになっていると思います。シフトは出来る限り削減してください。
制約を変更したら、直ぐに動作を確認しない方が多いです。
一つ変更、一つ求解確認が基本です。
一つ一つの制約の中身は、
■Day集合
■グループ集合
■シフト集合
から出来ています。各々制約上で集合を確認してください。
人間は間違えます。制約は、プログラムと違い、書いたその場で、動作を確認できるのですから、一つ一つStep by Step、動作を確認して、積み上げていくことが出来ます。そうした方が、結果として早いと思います。
＜ ブランク予定で、必ず解があることの保証＞
開発段階・デバッグ途中では、ブランク予定で、解がないことはあり得るのですが、本稼働場面で、ブランク予定で解がない事態は、絶対に避けなければなりません。
ブランク予定で必ず解があることが保証されていれば、予定を入れて仮に解がなくても、予定を全部ソフト制約にすれば、解は必ずある筈です。予定変更された部分が問題箇所という特定が直ぐできます。機械的な手順で難しいことはありません。本稼働時は、原因解析をすることなく、機械的に処理します。
ところが、ブランク予定で、解がないということは、その原因の解析をしないといけないということであり、スキルを要する仕事になってしまいます。原因の分析は、制約の中身について知らないと出来ない作業です。
また、毎月の予定に対して制約を弄ることは、完成したプロジェクトでは行いません。制約は予定に関わらず不変であること、が安定稼働の条件と考えます。
もし、予定を全部ソフト化しても解がない、つまり、ブランク予定にしても解がないならば、設計不備です。ブランク予定では、どのような月であっても解が存在することを保証をしておくことは、プロジェクト設計の礎です。
どのような月であっても、必ず解が存在するプロジェクトにするには、どうすればよいでしょうか？施設によりその条件は、異なるので一概には言えませんが、月の公休数や祝日数に関係していることが多いので、敢えてそういう条件の悪い月で試して解があれば、一応安心できるでしょう。（ただし、先月からの条件も絡んでくるので、絶対大丈夫とは言えません。）
いずれにせよ、ブランク予定で、先ず解のある状態にしておくことは、基礎中の基礎です。まずは、ブランク予定で開発を進めて、ブランク予定では、必ず解があるようにしてください。
ハード制約が多すぎるプロジェクトも、よくみかけます。ハード制約が一つでも満たせないなら、解がない状態になってしまいます。「ハード制約は、必ず満たさなければ、いけない制約」という理解は、されていると思いますが、必ず満たせる制約である必要もあるのです。逆に言えば、少しでも満たせない可能性がある制約は、ソフト制約にする必要があります。その意味で、「こんなにハード制約があって満たせるの？」という疑問が沸いてくるプロジェクトを拝見することがあります。
行制約と列制約は、互いに干渉しあうので、以下のA）B）いずれかにするのが基本です。
A）列制約がハード制約主体 ⇒行制約はほぼソフト制約とする
B）行制約がハード制約主体 ⇒列制約は、ほぼソフト制約とする
その中で、どうしても実現したい制約のみ（１個か２個程度）をハード制約とします。
行と列どちらもハード制約主体となっているプロジェクトは、解がない状態となる率が高いです。特にリソースを使い切るプロジェクト、いわゆる「人がいない」職場では、解がない状態となる確率が高いでしょう。
