実装しない制約

 顧客の要求を全て実装する訳ではありません。

スケジュールナースは、制約で解を求めるシステムですが、制約には、良い制約と悪い制約があります。良い制約システムとは、効率の良い制約で、求める解に、少ない制約で解が得られるシステムです。反対に悪い制約システムとは、効率の悪い制約で、求める解に、多大な制約リソースを使いそれでいて、中々求める解に到達しないシステムです。

様々な制約を実装してきて、必ずしも、顧客の要求全てを実装することが、効率良く、求める解に到達することではない、ということがあります。

効率の悪い制約とは、どのようなものがあるでしょうか？

例1　夜勤のペア組を全て異なるものしたい

仮にこれを実装したとして、どれだけ求める解に近づけるか?　ということが視点としてあります。例えば、HCUでは、４：１であり、１6床のとき、４人、２４床のとき夜勤６人が常に必要となります。ICUは、２:1であり16床のとき、8人、２４床のとき夜勤12人が常に（日勤、ロング日勤、入り、明けに関係なく）必要となります。

全て異なることを制約するとなると、HCU夜勤人数は、通常３人/夜勤要員24人なので、通常だと48人必要になります。なので、その組み合わせ総数は、48C6となります。

それが、一月(31日)に渡って一緒にならないことを保証するには、48C6*31の計算項が必要になります。380416872がその総数です。多大な計算リソースが必要となり、実際的には破綻してしまいます。

もう一つの視点は、効果です。多くの場合、解を見ていて、まず、目に付くのは、スタッフ間の夜勤数のばらつきだったり、2連休の数だったり、各スタッフの夜勤の集中度合いだったりするのが常です。

申し上げているのは、そういう主制約をまず実装して、それでも余裕があるならば、さらに制約を追加することも意味がありますが、そうではなく、それすら達成していない状態で、実装したとしても殆ど意味がないばかりか、主制約の実現を邪魔しかねない

ということです。この制約の場合、計算リソースを馬鹿食いするだけでなく、主制約の実現を邪魔する制約となる可能性が高い

ということが言えます。それならば、最初から実装しない方が良いのです。

制約が効率の良い制約か、そうでないかは、実装を検討してみないと判りませんし、経験を積まないと見通しを得るのは難しいです。

一言で言えば、「労多くして益なし」制約は実装しません。

効率の悪い制約例は、Kindle本でも述べているので参考にしてください。