言葉で仕様は言えないけれども、良くない解であるのは言える

 ヘルスORでの池上先生の話で、「何度も師長に解を見せに行っては其のたびに指摘され、何度も、何度も、何度もそれを繰り返した」　というお話がありました。

通常の勤務表作成においても、全く同様のプロセスを辿り、その通りだと思います。

A) ■頂いた仕様以外に仕様がある

ということです。言葉では言えないけれども、良くない解であることは分かる訳です。私は、これを脳内仕様と称しています。

対策は、簡単で、納得いくまで、良くない解の特殊例を一般化して、それを仕様として追加して行けばよいのです。脳内仕様は、普段隠れています。しかし、解という特殊例を見ると、途端に脳内から外界に向けて「こうではない」と言えるのです。問題はその先で、その特殊例を、言葉としてまとめられるか？にあります。これを言える人とそうでない人の両方が存在することは確かで、ここに能力差、スキル差が存在すると思います。自動勤務表作成において最も大事なスキルは、プログラミングスキルでもIT能力でも集合の理解でもなく、この部分にある、と思っています。言葉として提示頂けなければ、制約として落とし込むことは決して出来ません。

B）■頂いた仕様と実績とがかけ離れている

もう一つ、人間の特性として特筆すべきことは、脳内仕様と、実績とはかけ離れている、ということです。上のプロセスで全てを仕様化しそれをハード制約とすると、絶対と言って良いくらい解がありません。人間が普段思っていることは、完璧に出来ている筈という思い混みがあるようです。が、実は、完璧というのは、殆どなくて実態は穴がある、否、むしろ穴だらけが普通、ということです。脳内で思っているだけで、きちんと計測管理されたものではないためです。これまで色々な実績勤務表を見ていますが、殆どの仕様をソフト制約にしておかないと、人力解勤務表では解がないのが普通です。自動勤務表では、ここに第一のバリアが存在します。

これを認めて前に進める人と、どうしても納得できない人がいます。別に師長を責めているのではなく、単にデータがそうなっているという客観的事実だけなのですが、自己防衛に終始して前に進めない方がいます。こちらが求めているのは、A)スキルで、「それを言葉としてどのように表現できますか？」ということです。欲しいいのは、仕様とその実現優先度だけなのです。どれを取りどれを捨てるべきかは、管理者にしか分かりません。特にここは絶対に外せないというところは、ハード制約化しますので、ご指示頂きたいのです。でも、ハード制約指示であっても実態勤務表は出来ていない、というのはよくあります。

C)　■解について納得できない方がいる

トレードオフについて、ご納得いただけない方がいらっしゃいます。特に自分で勤務表を作った経験がない、または少ないとトレードオフについて理解が難しいかもしれません。この意味で、これよりも良い解はない、ということを常に示せるのが理想である、ということは変わりがありません。ソルバの仕事であり、開発者としての責務だと思っています。

D）■リニアモデルの最適解が自分の最適解ではない

池上先生のおっしゃっていた通りです。この対策として、スケジュールナースでは、非線形のエラー許容量という概念で、非線形のハード制約を持っています。これ以外にもあるかもしれません。が、それは予定として埋めてしまえばよいし、必要ならそれをソフト制約化すればよいのです。部分解を予定としてコピペすることも出来ます。そうしたことは、単純にソフトの技や、慣れ、使い方の類だと思います。

脳内仕様を変換し終えた自動勤務表においては、、職場の数だけモデルが必要です。そしてそのQOLは、もはや人間では到底なしえない高みに達しています。議論は、その高いレベルでの議論になっていることに注意してください。穴だらけの勤務表とトレードオフについての議論をしている勤務表とでは、次元がそもそも異なるのです。

細かすぎる細部を気にされている方も、どうかと思います。元は穴だらけのQOLだったのです。それに気づかなかっただけですが、それは無視しておいて、非常に細部のところを気にされるのもどうか？という気がします。少なくとも人力解よりは遥かに良くなったのですから、適当なところで打ち切る度量がマネージャとして必要ではないか？とも思います。全部を満足する解はないことは、証明出来ているのですから、後は、どれを選ぶかだけです。