次のソフト制約で、許容範囲を超えています

 ソフト制約でのハードエラーの解析です。

この場合のソフト制約というのは、数を数える制約、不等式制約または、基数制約と呼んでいる類の制約です。ソフト制約なのにハードエラーとは、何事か？　と思われるかもしれませんが、数を数える制約には、必ずその限界が暗黙のうちに設定されています。その値が、エラー許容量です。この範囲を超えたらハードエラー、解がない状態になります。

いつものように、当該箇所に飛びます。

ちょっと待ってください。エラー箇所は、行制約グループ２と言っているにも関わらず、行制約グループ１が表示されています。これは、同じ名前があるときの問題です。正しくは、次の箇所です。

レベル７に設定されていますから、この範囲が逸脱していたということです。下限が4に設定されていますから、０の人が居ることを想定すると、エラー許容量を４にする必要があるということです。

試しにエラー許容量を３→4にしてみると、解はありました。つまり、0回しかやらない人が必ず存在する、ということを意味しています。

大量のエラーが発生し、時間もかかっています。恐らく何か記述ミスがあるのでしょうが、ここまでくれば、何が起きているは、解を見れば分かると思います。

特休エラーで解がない

 こんな風に出た場合は、解がない状態です。

求解ページには、赤でエラー箇所が表示されています。赤丸部分をダブルクリックして当該箇所に飛びます。

一つは、6連休勤務禁止制約です。

シフト予定で、特が並んでいます。恐らくこれが原因でしょう。

「特」は、何かを見ます。特休のようです。

有公休ラベルで、特休が漏れているようですので、特休を追加しました。

これで、ハードエラーを解消することが出来ました。

解がない場合は、原因箇所に飛び、何が起きているか？　何と何が矛盾しているか？を観察しましょう。

INRC2 8WEEKS 全く歯が立たない

 全く歯が立ちません。一筋縄ではいかないことが判明しました。何か、イノベーションがないと厳密解を得るのは、とても難しいです。3日間廻しても厳密解である証明は、一つも得られませんでした。

気を取り直して、新しい手法を投入して解くことを考えます。そのための第一歩は、サブプロブレンに分割することです。

次のTraineeは、TR集合の人だけが、そのタスクを実行でき、その他のスタッフは出来ないことが分かります。

制約があるのは、Traineeに関して制約があるのは、次の列制約だけです。

言語制約では、そのスタッフのみで閉じており、TR集合以外との演算がありません。

なので、問題をTR集合とそれ以外で分割できます。分割した問題内の最適値が全体集合での最適値になります。このためには、TR集合内だけの演算で閉じていることが要件です。全ての演算をチェックして、このチェックがOKになったときだけ問題を分割できます。

問題を分割したとき、解きやすいのは、小さい方です。6人しかいなければ、例えばMIPソルバでも解ける規模です。なので、大きい方の問題に注力して解けばよい、ということになります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ヘルスケアOR 拝聴しました

ZOOMで拝聴しました。

ゲノム解析のお話は、面白かったです。伊藤真理先生を拝見できなかったのは残念でした。

ここでも、クラウドサーバ力が、医療サービスひいては国力に比例するような感じを持ちました。(国内でもAWSやAuzureに匹敵するクラウドサーバがあれば、少しでもデジタル赤字を減らせると思うのですが。)

本題のNSPですが、同業者の方が少なくとも二人いらっしゃいました。また、スケジュールナースユーザの方もお見受けしました。視聴者の方の数も3講演で一番多く質問も多彩で関心の高さが伺えました。

で、私が考えるNSPの現在の問題は、以下の２点です。

A）■職場の数だけモデルがあり、モデル化をどのように構築しメンテしていくか？です。EUのように専門のコーディネータが居ればよいのですが、日本の現状では、看護・介護師長や、上に立つ医師がそれをやるしかなく非常にハードルが高いです。

B）■アカデミックの興味は、未解決のナーススケジューリングの厳密解がどこにあるか？ということです。NP困難な問題領域ではありますが、組み合わせ最適化問題としてどこまで解けるものなのか？その限界は、今、一体どこにあるか？を明らかにすることです。

＜職場の数だけモデルがある＞

Aについては、スケジュールナース勤務表作成サービスがあります。看護師・介護士・医師当直表、その他あらゆる業種のフルカスタム制約での勤務表が出来ます。月々の勤務表は、変化していきます。メンテナンスのない勤務表は存在しません。大事なことは、自分達でメンテナンス出来るようにすることです。それには、職場のルールに沿ったプロジェクトファイルがあったとして、それを改変・変更できるようにならなければいけません。単に勤務表を作れればよい、というのは誤った見方です。自分達でメンテナンス出来て初めて、使える勤務表になります。そのために必要なのは、まず職場のルールに合った制約ファイルとその変更の仕方を学習することです。

ご利用ください。ZOOMによるレクチャ・勘所の解説付きです。今まで、こちらから実装不可能という理由で依頼をお断りしたことは一度もありません。（無料で開始できるので、気やすく取り掛かれるためか途中で音信普通になる不埒な方が、たまにいらっしゃいます。それを除けば実装成功率１００％です。）

変わったところでは、県立図書館のカウンタ業務にも使われているそうです。また、施設での厨房業務の割り当てでも使われているそうです。私もプロジェクトファイルを見たことがないので、どのような形態かは分かりません。また、古くは、東京Key放送局ののシフト勤務でも使われています。現在は分かりませんが、マニュアルもあまり整備されていない時代によく独力で作れたなあと感心します。

このように力さえあれば、独力で設計記述でき、独力でモデル化できる世界で唯一かつ世界最高性能のプラットフォームです。殆どの場合、プログラミング言語Pythonを使わずに制約化可能です。

今までで、一番難しかったのは、地方都市公立病院の医師当直表があります。こちらは稼働を始めました。「公開してよい」との許可は既に頂いていますので、安定したら公開します。このプロジェクトでは、私でも数日間、どのように実装すべきか悩みました。このように、モデル化の難易度は、その職場依存です。一概にどんな職場でも独力で出来るとは言えません。そんな時でも、この勤務表作成サービスというSafetyネットがあるのは心強いと思います。

＜ナーススケジューリング問題のNP困難限界はどこにあるか？＞

Bについては、今年中に、古今東西、提出された全てベンチマーク問題について厳密解を与えることを計画中です。具体的には、INRC2　8Weeksで11問、SchedulingBenchmarksで2問です。これらが未解決の問題群です。ご期待ください。ヘルスケアORでも科学立国としての国力低下の指摘されていますが、ことナーススケジューリング問題の研究については、世界をリードしているという自負があります。

先月の予定入力 タスク予定も変更が必要

 先月の勤務表が、スケジュールナースでの解ではない場合、あるいは、実態が異なる場合は、先月部の予定を実態に合わせ修正する必要があります。その際、シフト予定を修正した場合は、それに伴うタスク予定も修正する必要があります。

次のようにエラーが出で解がない場合を考えます。

赤丸をダブルクリックして当該制約部に飛びます。

タスク予定では、28日は、整形診療業務になっています。しかしシフト予定では、灰色ラベル（当直勤務なし）になっています。つまりシフト予定とタスク予定が矛盾しています。

この原因は、

シフト予定を実態に合わせ変更したものの、タスク予定は、スケジュールナース解のままになっていた

と思われます。

解がない場合の処方は、「矛盾を解消する」以外ありません。

基本的には、タスク予定も実態に合わせ変更する必要があります。

しかしながら、矛盾を解消することが目的ならば、タスク予定を入力する必要はありません。今回は、タスク予定を全てクリアすることで、余計な手間をかけないことにします。

クリアしました。

これで解がないエラーが解消されました。

ヘルスケアOR ZOOMのURLが届く

 幹事は、神戸大学の伊藤真理先生だったのですね。

是非とも最初から聴講しないと。