Ans.
現在の設定箇所は、下記で、ペア制約 AならばBを用いています。
ここを>=２にすれば良いように思いますが、>=２に関しては既に列制約で一般制約として制約済です。
ペア制約では、特殊ケースについて記述しています。今回の変更によって、特殊制約は不要になったのですから、以下のようにペア制約のチェックを外すだけで事足ります。
しかし、求解して確認してみると 解がありません。ソフトの許容範囲エラーです。エラーの数が許容範囲を超えているがために起きているハードエラーです。この手のエラーは許容範囲を拡大することで解消することが出来ます。
赤字●部分をダブルクリックして当該制約に飛びます。
ソフトレベルがどちらもレベル７であることが分かります。
列制約レベル７の許容数を見ると０になっています。
とりあえず、１にしてみます。
求解してみると、解はありました。
レベル７のエラーは重篤エラーとして赤でマークされています。
同じレベル７制約である、夜勤数も許容エラー数を１としているがために夜勤数もエラーとなってしまいました。ソルバは、目的関数値UBを最小の結果を求めています。現状の制約状態を変えない限り、このエラー数は必然です。（ただし、エラー箇所は必然ではありません）ソルバは、
UB総和をこれ以上小さくする割り当ては存在しない、と言っています。
この解が気にいらず、列制約も変えたくない、ということでしたら予定（ハード制約）をソフトにして、予定変更を認めるしかありません。リソースの限界を使い切ってる、物理限界を超えているので、他に選択肢はありません。以下は、その手順です。
再度レベル７の許容エラー数を０にします。エラー情報を見ると１１月１６日に集中していることが分かります。
そこで、１１月１６日の予定を選択して、
ソフト制約にして
レベル７にしてみます。
１６日のセルの枠が茶色になりました。
重みを１０にして、予定は出来るだけ変えるな！という指示にします。適用は新たなソフト制約なので、チェックが入っていません。チェックして求解してください。
解は、存在します。重み１０のエラーが１個なので、予定が１個変更されていることが分かります。
しかし、１１月１６日、誰かの予定が変更されている筈です。予定変更数最小（重み最大）を指示したので、変更数は最小になっています。（この辺は人間業では到底出来ないと思います！
スタッフ２３の予定が休日からC（夜勤専従夜勤入り）に変更されています。
予定で見ると、
休みが夜勤入りに変更されています。
以上の作業を行うのに慣れれば３分です。機械的な手順だけで難しいところは何もありません。
介護士勤務シフト表の最適化の実際は、上のようなちょっと面倒な作業が必要になる場合もあります。リソースの限界を使い切っていることを分かるのは、多分スケジュールナースだけだと思います。その上で対処方法は、上で見たように色々あります。何がベストなのかは、管理者だけが知っています。私も分かりません。
＜人的リソースを使い切った場合の対処法まとめ＞
■「解がない」のは、ハード制約間に矛盾があるからです。
■エラーメッセージをよく見て当該箇所をソフト制約化します。
＜スケジュールナースと他のソフトウェアとの違い＞
スケジュールナースでは、ハード制約と、ソフト制約と明確に分かれています。あえて、ユーザさまにその理解を強いている、とも言えます。他のソフトウェアは、この区分がなく、内部的には、全てをソフト制約にして組んでいます。このことの弊害は、ユーザにとって、絶対に落とせない制約とそうでない制約との区分けができなくなることです。そもそもソルバ能力の実力差を指摘したいところではあるのですが、それとは別に根本的な設計思想が違います。一言で言うなら「人的リソースが厳しい」向けのソフトウェアです。
他のソフトウェアでは、どうでしょうか？解はとりあえず出るでしょう。しかし「何故かエラーが沢山出る、でも原因が良く分からない」、で終わってしまうのではないでしょうか？その結果、制御できないエラーだらけの（望んでいない）勤務表になってしまうことでしょう。
スケジュールナースでは、何が絶対か？をユーザさまご自身に委ねています。その結果しばしば、「解がない」事態に陥る結果となります。言い換えると、ユーザさまご自身で限界の線を定めていることになります。「解がない」とは、ユーザさまが定めた絶対線を超えることを意味します。
＜許容数０の意味＞
上のソルバ設定で許容エラー数が０になっている箇所が散見されます。これは、最大最小制約において、その許容数が０つまり、本来ソフト制約である制約をハード制約化していることを意味しています。私が設定したものではなく、ユーザさまが意図してハード制約化したものと推察されます。
何故、ユーザさまご自身で、ハード制約とソフト制約の区分化を強いるのか？というと、そのユーザにとっても物理限界までリソースを使い切る、ことを主眼にしている、からです。
限界線をユーザさまご自身で決めその物理限界まで使い切るソフトウェアだからこそ、初めて出来る指摘です。スケジュールナースの固有技術です。（特許６３６４６３８）
＜解がない事態を解消する方法は無数にある＞
エラーメッセージに基づいて、指摘箇所をソフト制約化するのですが、実は、上記以外にも方法はあります。数理的には無数にある、と言ってもよいと思います。僅か二つの例を提示したのですが、実は、他の制約を緩める方法は、いくらでもあります。が、大別すれば、上の２方法に分類される、ということです。
＜正解を知っているのは管理者だけ＞
二つの方法のうちどちらが管理者が求めているものでしょうか？私も分かりません。正解を知っているのは、現場を預かる管理者だけでしょう。たった1個の予定変更を取るか、人が居ない方を取るか、判断するのは管理者です。その職場にもっとも適した緩和方法は、その管理者だけが知っています。この先AIが発達したとしても、私がどちらの案が管理者の求めているものか分からないように、AIも無数にある緩和方法の正解を分かることはないと思います。
大切なことを決めるのは何時でも人、管理者であるべき、がスケジュールナースの設計思想です。
