ORの世界では、最適化問題とは目的関数を決め、それを制約条件の中で最大化する手法の研究だと考える。私自身は、スケジューリング問題を最適化の文脈でとらえることに、一貫して反対してきた(「スケジューリングは最適化の問題ではない」参照)が、世の中の主流がその方向で認識していることは確かだ。

ところで、スケジューリング問題における納期は目的関数たりうるか、などというと疑問に思われる方もいるだろう。生産計画の目的が利益最大化であることは自明ではないか? 納期は順守が原則だから、制約条件であるはずではない、と。

答えはYESでもありNOでもある。疑問に思う人は、つぎの問題を考えてみてほしい:今、営業部に客先から急な引合いが入って、ある製品Xについて納期を答えなければならない。工場はすでに計画にそって動いているから、この注文は飛びこみ扱いになる。スケジューラーは工場設備の能力余裕を調べ、いつだったらその製品Xが製造可能かを計算する。しかし、あいにく今の計画のままでは、営業の希望する納期は満たせそうもない・・

このとき、計画担当者のとりうる行動は二つある。営業部に「納期は守れません」と答えるか、さもなければ現在の実行計画の内で、納期余裕のありそうな製造オーダーを後ろに動かして、飛び込みの注文が希望に間に合うようにするかだ。あなただったら、どちらにするだろうか。

後者が正解、のように思えるかもしれない。しかし、そこには一つの仮定がある。それは、希望納期に遅れたらその引合いは失注するだろう、という仮定だ。これが本当かどうかは、営業部が客先に本音を確認してみないと、じつは分からない。もしかしたら、分納によって一部は後からでもいい、と言ってくれるかもしれない。金額による、かもしれない。ようするに、計画者には判断しようがないのである。納期予想の確度は需要側の性質できまるからだ。

このように、納期を制約条件と決めつけるのは危険であるため、たいていのAPSには納期からのずれを目的関数に組み入れる機能を持っている。そして、納期遅れの最小化問題として解いたり、あるいは納期遅れにペナルティを設定して金額に換算し、利益からこれを引いて目的関数としたりする。

納期のように、一種の制約条件ではあるが、ペナルティ項目として目的関数に組み入れ可能な(いいかえれば、ある程度は破ってもいい)ものを、「ソフトな制約条件」と呼ぶ。OR的なアプローチでスケジューリング問題を解くときには、ソフトな制約条件の目的関数化を活用して、いかに制約を緩和し、解空間の大きさ(自由度)を広げるかが、テクニックの一つなのである。