Q.看護師長が休日以外で、出張又は休みの場合は、１名の副看護師長を日勤とする

 Ans.

この仕様を制約化するには、意図をまず読み取ります。まず、

休日以外で、　⇒　今月平日、

に読み替えます。

出張又は休みの場合は　⇒　日勤ではない場合は、

１名の副看護師長を日勤とする⇒　１名以上の副看護師長を日勤にする

-副看護師長は２名この職場で居るので、１名にすることが意図ではなく、最低どちらか１名に居て欲しい、ということだろうと推察します。（この辺がAI化が難しいところです。言葉通りにすると1名以上ではなくて1名になってしまいます。ちなみに「1名」と「1名以上」では、どちらが解空間が広いでしょうか？明らかに1名以上の方が広いですね。ナーススケジューリングは、多数の制約間の共通集合からなります。一つ一つの制約では、出来るだけ解空間が広い方を選択したい、ということも背景にあります。）

結果、

「今月平日は、看護師長が日勤でない場合、１名以上の副看護師長を日勤にする」

という仕様に置き換えることができます。

次に、制約化を考えます。～（何々）の場合　を考えますが、最初に考えるのは、

列制約化出来ないか？　ということです。往々にして、ペア制約で書きたくなりますが、列制約化出来る場合は、そちらの方がメンテナンス上、ベターな記述になります。

＜列制約化の検討＞

～の場合、は全てのケースを表にしてみましょう。表にしてみると2＾３で以下の8通りがあります。

看護師長　　　日勤　                                         日勤でない

副看護師長A　 日勤                   日勤でない　       日勤                    日勤でない

副看護師長B　 日勤  日勤でない　日勤  日勤でない  日勤  日勤でない　日勤  日勤でない

計        　　　 3      2                2       1              2      1                1      0

上表で、欲しいのは、「全員が日勤でないこと」を避けたい、であるので、

計０の否定　⇒合計１名以上であればよい

ということが分かります。

（最初の仕様を1名として捉えると、8ケースの内3ケースなので３/8となります。ちなみに0名以上が全てのケースで8/8、今回が7/8）

これで列制約化が完了しました。

集合：看護師長または副看護師長

の合計が1名以上、今月平日について、ハード制約しています。

　

Q. Excelでスケジュールナース解を頂きましたが、シート名「勤務予定表」の赤部は予定でしょうか？

 

Ans.

はい、そうです。下記で、「マーク予定入力」オプションを使用することでハード予定部を赤で表示しています。

詳しくは、マニュアル

Excelへの解出力

をご覧ください。

Q.サブスク支払いについて

Q.

久しぶりに、スケジュールナースのホームページを拝見して、懐かしくなりました。

海外向けもやっておられるんですね！

とりあえず、料金体系もサブスクのようなので、それで試してみたいと思います。

しばらく試してみる期間はありますか？

また、ちなみに支払いは、Microsoftアカウントのみでしょうか？

（自分のパソコンは自分のアカウントなので一旦個人で払うことになるので。。。）

Ans.

2１週間位は、無料で行けたように思います。使えなくなったら、サブスクへの案内が出ます。

480円/月かかります。

すみません。支払いはMicrosoftアカウントのみで、クレジットカードしか受け付けないようです。

基本的な操作は、変わっていないと思いますので、ｘｘさまでしたら、問題なく書けると思います。

無料になるサービスもやっているので、こちらもよろしかったらご検討ください。（買い切り版は、現在５万５千円です。）

https://www.nurse-scheduling-software.com/japanese/nurse_scheduling_problem/chapter13/

それでは、よろしくお願いします。

Instance15の最適値が求められない

 開発中のソルバは、速度が数倍に上がっていることもあって、過去求めることが出来なかったインスタンス群(INRC2 8weeks)をかなり解くことが出来ています。で、SchedulingBenchmarksのInstance15に再挑戦してみましたが、最適値とされるUBをLBが上回ってしまいました。

これが意味することは、missing solutionで、ソルバのバグまたはモデリングのエラーです。こうなると、どこに問題があるかを調べるのは非常に困難です。

なので、最適値の世界記録を持っている方にお願いしてそのデータをもらい解析するより方法がありません。世界でそのデータを持っているのは、記録を保持している方、もしくはコーディネータのみで、他の誰も持っていません。

ソルバの性能向上、品質向上には、こうしたベンチマークによるデバッグが欠かせません。共通の土俵であれば、研究者同士で、融通が利きます。(競合関係・ライバル同士ではありますが)

残念なのは、数ある勤務表ソフトで、こうしたベンチマークテスト結果を公表しているのは、日本では、菅原システムズのみであることです。お互いに、共通の土俵で勝負してこそ、性能差、優劣が客観的となり、自らの弱点を知り改善につながると思います。スケジュールナースも、かっては、自分だけのクローズド世界にいましたが、池上先生のベンチマーク、その他世界のベンチマークに取り組むことにより、他ソルバとの客観的な比較が出来、より広い世界を知ることが出来たと思います。

Highs LPソルバの評価

 INRC2　8weeksでのLPソルバの使用検討を行いました。

下がその結果になります。現在使用中のCLPでは78sec近くかかっていて、これが為に、

全ての検討がネックになってしまっています。少しでも速いソルバが求められるところです。

これに対してHighsのIPMソルバは、crossoverなしで約7秒ですから、10倍近く速いことが分かりました。数年前に評価したときは、あまり変わらなかったと記憶しています。IPMソルバは、warm startが出来ないのが難点ですが、これくらい違えば、役に立ちそうなので、さらに検討してみたいと思います。（Highsアナウンスによれば2024年中にMT化を行うとありました。MT化がなされるとさらに速度アップが期待できます。2025中に実装されることを期待したいと思います。）

一方、HighsのSimplexは、頂けない結果となっています。数年前はDual Simplexしかなかったのですが、Primalもあったのでやってみましたが、惨憺たる結果となりました。CLPの優位性は揺るぎないです。

Highsは、PDLPのオプションとして使用できるようでしたが、本家の実装と比べて違うようで、結果には記していませんが上の本家の値よりかなり遅かったです。また、PDLPは、IPMと違ってwarm　start出来る筈ですが、そのようなソースになっておらず、まだまだ途上という印象です。

（）の数字が、OpenBlasを適用した結果となっています。少しだけ効果がある印象です。

一方本家のCPU版では、BLASを使うIFDEFも記載されていましたが、これが、かなり間違ったソースとなっていました。例えば、次のソースで、ddotを使うような記述があったのですが、これは、daxpyを使うべきでしょう。（その他幾多の箇所を修正しました。）

void AddToVector(cupdlp_float *x, const cupdlp_float weight,

                 const cupdlp_float *y, const cupdlp_int n) {

#ifdef USE_MY_BLAS

#ifdef USE_CBLASS

    

    //for (int i = 0; i < n; ++i) {

    //    x[i] += weight * y[i];

    //}

    cblas_daxpy(n, weight, y, 1, x, 1);

    //    return;

#else

  for (int i = 0; i < n; ++i) {

    x[i] += weight * y[i];

  }

#endif

#else

#define incx (1)

#define incy (1)

  return cblas_ddot(n, x, incx, y, incy);//BUG

#endif

}

以上見たように、規模が大きくなるにつれて、

Simplex ⇒IPM⇒PDLP（PDHG)

という流れは、確定的だと思います。

2024年は、PDLPに関する論文が色々出ました。2025年は、さらに改善されるだろうと予想します。

SchedulingBenchmarksの検討

 INRC2は、行き詰まっているので、気を取り直して、SchedulingBenchmarksを検討してみることにしました。

SchedulingBenchmarks残りの未解決問題は、2問あり、instance23/24です。この問題の課題は、２点あり、

１）超大規模につきコンパイルできない(128GBメモリでも不可）

２）リニアソルバが、遅すぎる

１）については、strandmarkさんの方法があります。

First-order Linear Programming in a Column Generation Based Heuristic Approach to the Nurse Rostering Problem

ヒューリスティクスな方法を取っているために、厳密な下界が求められないという問題があります。厳密解を求めようとすると１）がネックになります。また、リソース制約下の最短距離問題は、一般にラベリングアルゴリズムが用いられますが、検討するまでもなく遅すぎて使い物にならないでしょう。１）については、ひとまず置いておいて、２）について検討してみます。

First Orderの検討

GitHub - COPT-Public/cuPDLP-C: Code for solving LP on GPU using first-order methods

これと、Simplex Solver CLPとの比較をしてみました。誤差は、1e-5に設定しています。

cPDLPCPU  cuPDLP(Quadro P1000)  CLP

instance19 46.7sec    21.6sec 2.6sec

instance20 14.8sec    6.7sec 9.6sec

instance21 41.5sec   16.2sec 78sec

規模が小さいとき（instance19以下）は、明らかにCLPが速いです。しかし、規模が大きくなってくるinstance20以上から、逆転する傾向となります。「大規模では、SimplexではなくIPMで」、がこれまでの定石でしたが、これからは、GPUも選択肢の一つになる、ということです。OR業界でのイノベーションです。

instance22/23の規模は、instance21の数倍以上なので、CLPでは、数分以上という値となり、もはや現実的ではありません。高性能CPUにすれば、2倍までは期待できますが、Simpilexは、マルチスレッドの恩恵が殆ど得られないことが分かっているので、CPUで何とかすることは出来ません。

cPDLPCPUは、FirstOrderのCPUバージョンで、GPUではなくCPUでFirstOrderを実行した値になっています。

ソースでは、cupdlp_def.hで、定義してコンパイルしたときの値です。

#ifndef CUPDLP_H_GUARD

#define CUPDLP_H_GUARD

#define CUPDLP_CPU 1

今のGPUを使用したとしても、instance23/24では、1分を超えてしまうので、やはり遅すぎます。出来れば、数秒以内、最悪でも１０秒以内としないと、現実的な時間内に解くのは難しいと思います。

ところが、Paper/MIPソルバのベンチマークで使われているのは、H100等であり、50万以上します。

2312.14832

S62495_1710893775487001l6SK.pdf

なので、価格的にフェアな比較にはなっていないと思います。

現実的な路線で、クラウドで使用可能なのは、4090クラスです。

GPUのスペック一覧 #GPGPU - Qiita

一方、P1000という上記GPUのCUDA数は、６４０、ベースクロックが1.3GHzです。GPUを最近の高性能の物に置換するとすると、

後述の理由によりメモリ16GBは、欲しいので、RTX 4060Ti

を考えると、CUDA数・クロック数比から、

4352/640*2.31/1.3=12倍

P1000に対して、最大で12倍の性能向上が見込める計算にはなります。よって目標の10秒以内を見込むことが出来ます。最悪、クラウドを使えば、4090を使用できるでしょう。いずれにせよ、GPUを使用することにより、リニアソルバ問題は、目途がついた、と考えています。COPTを使用しなくても、GPUで代替え可能であろう、と結論します。

一方でLLMの検討用にクラウドではなく、ローカルでそこそこ動くGPUが欲しくなります。AIが作成した記事のようですが、

ローカルLLMを構築する際のGPU選び：RTX4090、RTX4080 SUPER、RTX4070 Ti SUPER、RTX4060 Ti - CaCCラボ

これによれば、VRAM16GBは、必須です。よって、RTX4060Ti　16GBを選定しました。

次の課題は、超大規模問題を如何にコンパイルするか？です。

プロジェクト作成サービス ーサブスク連携版（３カ月３万３千円）の廃止について

背景 

■プロジェクト作成サービスをご利用されるお客さまの殆どは、買い切り版をご利用されること

■サポート期間が３カ月では、足りない場合があること

■十分余裕を持った期間（１年）と夏季・年末年始等の特別期間を含んだ期間とすることでより安心して頂けること

により、プロジェクト作成サービスは、サブスク連携（３カ月３万３千円）を廃止し、買い切り版サポート１年付（税込み１１万円）のみとすることにしました。

適用は、４月以降とします。よろしくご理解の程お願いいたします。

Q.勤怠勤務表への落とし込みについて

 Ans.

プロジェクト作成サービスでは、ご希望がある場合、勤怠勤務表へのExcel出力も行います。

勤怠管理ソフトと連携させたい (nurse-scheduling-software.com)

Q.遅番の人数が数日０人の解となってしまいます。

 Ans.

プロジェクトファイルを拝見したところ、確かに遅番が０人のところが多くなっています。

当該制約は、下記レベル３になっていました。慣例ですと、この重みは、３で軽い制約の部類となります。そこで重みがソフト制約の中では最も重いレベル７に変更してみます。

求解します。

遅番の重みは、増したのでその効果が表れ、全日で１名を確保できました。

目的関数値UBの変化を見てみましょう。変更前と、

変更後です。

変わっていないことに注目してください。特に重み３のエラー数は変わっていません。重み３は、遅番重みを３→７に変更したので、その分のエラー数は少なくなってしかるべきですが、その分別なエラー（今回は、早番が主体）が増えていて、目的関数値自体は変化していないことが分かります。

重みで、優先度は如何様にも変えることができますが、

一方で、リソース制限下において、あちらを立てればこちらが立たずのトレードオフの関係にあります。

重みを変えることで、リソース制限下で、管理者の欲する狙い目に近づけることは出来ますが、この例のように、他への影響は、避けて通れない、ということを心しておきましょう。

一般には、両方満足させる解は、リソース（人的資源）を増やさないと物理的に無理です。最適化システムにおいては、限界までリソースを使い切っているので、目的関数値自体は、あまり変化しないのです。

例外として、例えば、チームA/Bで偏りがあるときは、全体リソース制約下での物理制約ではないので、チームA/Bの偏りを改善すれば、改善することが出来ます。

Q.ハード制約の増加がエラー減少に貢献する場合もありますか？

 Q　質問内容の概要

・ハード制約が増えることで、基本的にエラーが発生(ソフト制約の違反)する確率が高まるというイメージがあります。

しかし、逆にハード制約の増加がエラー減少に貢献する場合もありますか？

 Ans.

ハード制約の増加⇒解空間の減少⇒ソフトエラーの増加（＝UB＝目的関数値）の増加

が、原則的な動きです。ですので、正しい理解をされています。

これを覆す例は、多分、目にする機会は殆どない、と思います。（絶対にない、とは言い切れないです。）

Q.●質問の背景

・スケジュールナースブログの2025年1月8日投稿内容についての質問です。

　この投稿では、連続6連勤(夜勤明けを含む)を禁止するハード制約は設けられていたものの、

　「3日勤＋長日勤は禁止」のハード制約が存在しなかったため、「長日勤の次は夜勤」、「入りの前は長日勤」という

ソフト制約を違反したシフトが作成された、という内容だったと理解しています。

Ans.はい。その通りです。が、記事の書き方が良くなかったです。誤解を生んでしまいました。

上の制約は、先月での制約です。

先月勤務解を前提とすると、今月にソフト制約エラーとなってしまうのは、必然です。避けようがありません。つまり問題は、先月解にあり、悪いのは先月解にあります。

このようなソフトエラーが、今後発生しないようにするには、記事のような制約を追加すれば良い、という主旨の内容です。当然過ぎ去った過去は、変えようがないので、その効果が表れるのは、来月以降となります。

ところが、先月に戻って、制約追加した解を示したので、誤解が生じてしまいました。

書き方が悪かったので反省しています。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

・これまで、ハード制約が増えるほど解の選択肢が狭まり、エラーの発生率は高まるというイメージを持っていました。

しかし、今回のブログ事例では、ハード制約を増やすことでエラーの発生を減少させたようにも見えました。

今後のシフト作成において、ハード制約を設定する際の考え方の参考にしたいを考えています。そのため、

ハード制約の増減とエラー発生の増減との関連性について、適切な捉え方をご教示いただければ幸いです。

(※具体的な数字ではなく、感覚的な捉え方を知りたい)

 

・今回のブログ事例においては、解の選択肢が多すぎたために、スケジュールナースはエラーを２つ含むシフトを最適解と

判断してしまった。しかし、ハード制約を増やして選択肢が減らした結果、エラー０のシフトにたどり着けた、という認識でも

大丈夫でしょうか。

 

 

 

 

 

 

 

・これまで、ハード制約が増えるほど解の選択肢が狭まり、エラーの発生率は高まるというイメージを持っていました。

しかし、今回のブログ事例では、ハード制約を増やすことでエラーの発生を減少させたようにも見えました。

今後のシフト作成において、ハード制約を設定する際の考え方の参考にしたいを考えています。そのため、

ハード制約の増減とエラー発生の増減との関連性について、適切な捉え方をご教示いただければ幸いです。

(※具体的な数字ではなく、感覚的な捉え方を知りたい)

 

・今回のブログ事例においては、解の選択肢が多すぎたために、スケジュールナースはエラーを２つ含むシフトを最適解と

判断してしまった。しかし、ハード制約を増やして選択肢が減らした結果、エラー０のシフトにたどり着けた、という認識でも

大丈夫でしょうか。

Q.夜勤の人数が2人にならず０～４とバラバラに出てしまいます

 Ans.

プロジェクトファイルを拝見したところ、列制約グループ１の適用がチェックされていませんでした。これにより、このページ全体の制約が適用されなくなっています。

適用にチェックを入れ、設定ボタンを押します。

すると、新しいソフト制約が適用された、と解釈され当該制約グループでのソフト制約の適用がオフになった状態となります。これも、そのままですと、制約が無視された状態となってしまいますので、

適用にチェックを入れ、相応の重みを設定します。（慣例的に、左のレベルと同じ重みにします）

これで、求解ボタンを押して頂ければ、問題なく制約が効くようになります。

＜まとめ＞

■何か変更したら、ファイル名を変更することを心掛けましょう。（前の状態に戻りたい場合に必要になります。）

■メモ欄で、変更履歴を書いておきましょう。（ファイル名の変更だけでは、何をしたファイルか忘れてしまいます。）

Q.スケジュールナースについて、医院側で何を準備すればよいでしょうか？

 Ans.

＜設備＞

スケジュールナースは、Windowsストアアプリです。ですから、物理的には、Windows11が動くPCが必要になります。

＜カスタムルールを如何に設定するか？＞

難しいのは、如何にして貴医院にマッチした勤務のルールをスケジュールナースに設定するか？です。その方法として、安い順に示すと、

■１）チュートリアルを参照して、ご自分で設定する

チュートリアルを参照して貴医院のルールをスケジュールナースに設定します。

■２）本を参照して、ご自分で設定する＞

チュートリアルだけでは、分からなかった場合、本をお買い求めいただき、ご自分で設定します。

■３）プロジェクト作成サービスを利用する

それでも、設定方法が不明の場合は、プロジェクト作成サービスをご利用ください。

プロジェクト作成サービスは、税込み11万円で、サブスクではなく買い切り版になります。1年間のZOOMサポート付です。詳しくは、こちらをご覧ください。

まとめると、

従いまして、どのやり方で貴医院のルールを実装するか、によります。

＜お勧め＞

プロジェクト作成サービスのご利用が、一番手っ取り早くかつ確実です。菅原システムズは、１年間、無償で、仕様変更を承ります。

また、ZOOMによるサポートが1年間付きますので、ソフトの操作に自信が持てない場合でも、安心してご利用頂いております。（ZOOMで共有画面にして、ソフトの操作をその都度、お教えしております）

これにより、どなたでも操作・設定・改変の習得が、可能です。

Q.Ｅmailでの相談をした場合、返答に平均どのくらい 時間を要しますか？

 Ans.

一般のサブスクユーザよりもプロジェクト作成サービスの方が、優先度が高いです。

現状、サブスクユーザでも、24時間以内に回答しております。

また、プロジェクト作成サービスでは、ZOOMで、共有しながら説明・理解・操作して頂くことの方が良いように感じていますが、ユーザさまの意思を尊重します。

Q.AI勤務表について

Ans.

　勤務表の最適化エンジンの能力といわゆるAIとは、無相関です。

https://speakerdeck.com/recruitengineers/brainpad-meetup-umetani?slide=5

こちらで説明されている、「AIで問題解決：プレスリリースの実態」の通り、実際に勤務を解くのは、アルゴリズムに基づいて動くソフトウェア（ソルバ）であって学習に基づくAIではありません。

＜ソルバを、人間が開発するのは今後も変わらない＞

例えば、乗算器を構成するのに、通常は、論理的な手続きで解くのが普通だと思いますが、これをAI学習に基づいて解いた方が速くて正確であるとは、識者は考えないでしょう。同じように、リニアモデリングによる勤務最適化解は、乗算器のように数理的な面が支配的であると考えています。ヒューリスティクス関係のソルバで、AI的なアプローチを使うことで数％の向上が図れた、という報告は挙がっているものの、現状を打破するような革新的な成果は得られていないのが現状です。それについては、将来も変わることはないだろう、と考えています。実装方法が論文で示されていれば、AIがそれを学習し真似ることは可能かもしれません。しかし、商用ソルバは、その実装方法がオープンではないので、（スケジュールナースもアルゴリズムを公開していません。）トップに位置することは、当分ないでしょう。

＜モデリングの可能性＞

AIの応用が望めるのは、ソルバではなくモデリングにあります。モデリングとは、コンピュータにこういう解が欲しいと伝えること　の事です。スケジュールナースでは、制約を記述することによってお客さま専用のカスタム勤務表を実現しています。現状、このモデリングは、一般の方はもちろんITエンジニアでも一定の学習努力が必要で、一言で言うと難しいです。多分世界で一番、勤務表を作っている私ですら、時折、頭を悩ませる問題に出くわします。それ故、プロジェクト作成サービスが存在するのですが、私の持つ深い経験や知見をAIに学習させAIに置き換えることは、大いに可能性があると考えています。スケジュールナースでも課題として捉えています。

Q.予定入力でエラー発生

 Q.

年末にいただいた労働基準法上の宿日直許可関係の制約に対応済みのファイルに

予定入力して実行してみたところ、ｘｘ先生のところでエラーが発生して

解が求まらない状態になりました。修正、お願いできないでしょうか。

Ａｎｓ．

＜不具合再現＞

次のように解のないエラーとなっています。

●Schedule.名前の部分をダブルクリックします。

すると、XX先生の先月勤務28日でのエラーであることが分かります。この灰色.ラベルは、宿直関係がないことを表すシフトラベルです。

今度は、

●　予定入力タスク制約.ｘｘ 2025-01-28 1をダブルクリックします。

すると、今度は、同じ先生の勤務(内科）の予定タスクが表示されます。

以上二つがエラー要因のヒントです。

解がない原因は、ハード制約間の矛盾です。上記２予定制約を音読してみましょう。

■XX先生２８日は、宿日直勤務がない

■XX先生２８日は、内科宿日直勤務

これは、明らかに矛盾です。つまりハード制約間の矛盾です。恐らくは、手入力で先月実績の勤務に変更したのでしょう。

シフトは勤務なし手動変更したものの、タスクをメンテナンスするのを忘れていた

というのが原因です。タスクを採用した勤務システムでよくある間違いです。

■エラーを無くすには、タスクの予定をシフトに合わせてブランクとすればよいです。

■面倒であれば、先月全体をソフト制約にするという手もあります。

矛盾があったとき、何が真実かは、恐らくは作成者しか分かりません。エラーを修正するには、真実を知っている管理者が行うのが確実です。

新しい勤務表作成形態

 あるユーザさまに教えて頂いたので紹介します。

今まで、勤務表というのは、

■師長が作ってそれで終わりであり、誰も師長の作成方針は知ることがない

と思っていたのですが、その職場ではそうではなく、

＊＊＊＊＊

■副師長や、主任が勤務表を作成する。作成後に師長が承認をする場合があります。

勤務表作成に複数人が関わる場合、コミュニケーションが必要になります。

コミュニケーションが生じると、思考の見える化と、制約の共有が必要になります。

メリットとしては、

・副師長や主任が勤務表を作成した後で、師長に「ここが違う」「ここのメンバーがよくない」と言われることをなくせる

・複数人いる副師長や主任が、交代で作成する場合、「求解」のクリックで勤務表が作成されるので、誰がつくっても同じ質が保てる。

・異動で勤務表の作成者が変わっても、ファイルを引き継ぐことと、設定した制約の意図を申し送るだけで済む

長々と記載しましたが、

要は、勤務表の作成者と承認者が異なる場合があるということでした。

回答になっていると嬉しいです。

＊＊＊＊＊

とのことです。なるほど、それであれば、

■看護師長の依怙贔屓問題

■個別スタッフの特殊対応　

等も上の間で共有することによって、より俯瞰的公平が担保されるということですね。　この方法は、メリットしか思いつかない素晴らしい方法だと思います。

こういうことについても情報交換の場があれば、と思いました。

➡DiscordでCommunityを作ることも閃いたのですが、現状そこまでユーザ数が多くないので止めました。

自動勤務表作成に関して、テクニカルな事は、スケジュールナースサポートに聞けば解決しますが、他の職場での具体的なやり方について、聞いてみたいこともあると思います。私も、ユーザさまの所属や、個人情報を出す訳にもいかないので、直接やり取りしてください、というのも出来ないもどかしさがあります。強いご要望があれば、再考することにします。

Q. 特定の日の設定で、 ユーザ定義曜日の適用のチェックを外すとコンパイルエラー

 Q.

設定＞曜日定義＞特定の日の設定で、

ユーザ定義曜日の適用のチェックを外すと、

「（ユーザ定義曜日名）should have at least one members」

と表示され、コンパイルの準備中

コンパイルに失敗しましたと解が表示されてしまい勤務表が作成されません。

解が表示されないため、チェックを再度入れて求解しても、

「（ユーザ定義曜日名）should have at least one members」

と表示され、元に戻りません。

これまで使用して、初めての経験のため

何が原因かわかりません。

解決法を教えていただけますでしょうか。一度定義した

不具合が生じたファイルと、生じる前のファイルを添付させて頂きます

Ans.

特定の日のチェックを外す場合には、参照されている箇所のチェックを全て外してから、チェックを外してください。

不具合再現

下で、「待機」のチェックを外します。

コンパイルすると、PHSは、少なくとも一つのメンバーを持つべきというエラーが生じています。

従い、どこかで「PHS」が定義されている筈です。

⇒曜日集合のところで参照していました。

設定ボタンをこの時点で押すと、当該箇所が「待機」を参照していて、「待機」は存在しません。とのＧＵＩ側エラーメッセージが出ます。これが問題箇所になります。（また、曜日集合は、空白メンバーは許していないので、ｘｘshould have at least one membersのエラーが出ます。これは、ソルバ側のエラー検出になります。）

スケジュールナースの内部では、待機という参照は、無効になっており、これがために適用を再度入れても元に戻らなくなってしまいます。（この時点でファイル保存をすると待機がなくなった状態で保存されてしまいます。）

元に戻すには、待機を再度チェックを入れ、設定ボタンを押します。

参照している曜日集合で、待機が今回、GUI上は未だ残っているので、設定をボタンを押せば復帰します。

もう少し、詳しいエラーメッセージを出せば、解決は早いと思いますので、次回リリースでの改善を検討します。お手数をおかけし申し訳ございません。また、ご指摘誠にありがとうございました。

Q.薬剤部で使用できますか？

 Ans.　仕様を頂かないと、正確にはお答えできません。

仕様をお送り頂ければ検討いたします。

スケジュールナースは、シフトという概念の他にタスクという機能を使用することが出来ます。

さらに、スケジュールナースは、ノーコードプラットフォームでありますが、必要であれば、Pythonという言語を用いて制約することが出来ます。

医療・介護系のみならず、変わったところでは、県立図書館のカウンター、厨房のシフト、派遣シフト業務、鉄鋼工場のシフトに至るまで、多種多様なシフトをこなしてきた実績があります。恐らく、対応業種数という意味で、恐らく日本で一番こなしてきたのではないか？と考えております。

いわゆる勤務表ソフトの範疇で、「スケジュールナースに出来ないのであれば、他の誰も出来ないでしょう。安心してご検討ください。」と回答しています。

Q.解をドラッグ＆ドロップで変更できますか？

 Ans.

出来ません。

これも、スケジュールナースをあまりご存じなくて、よくある質問の一つです。

■勤怠勤務システムに落とすときに、解を変更するのは、スケジュールナースは関知しません。その意味では、ご自由にやって頂いて構いません。

■推奨する方法は、予定として書き込むことです。制約を満たした解が出ます。（もしくは、解がない）そちらの方が安全かつスマートです。

人間が解を変更する場合の問題は、制約を無視することが多々あることです。特にナーススケジューリング勤務表は、縦横の糸が張り巡らされていることに注意を要します。

それでも今回は（制約を無視して）良い・仕方ない、という考え方は場当たり的対応です。ハード制約を無視して良いのならば、そもそも、そのハード制約は無くてもよかったのではないでしょうか？ソフト制約にしても然りです。自身が決めたルールは、一貫しているからこそルールでしょう。

最適化ソルバは、トータルとしての制約違反を最小にするように動作します。予定も制約の内の一つ、ハード制約にもソフト制約にも出来ます。予定として所望の勤務を割り当てれば、ものの１ー２分で解は出るのですから、予定として書き込む方をお勧めします。

Q.手術看護師がいつの頃からか2名になってしまいました。

 Ans.

プロジェクトファイルを拝見したところ、昔の仕様（下記）になっていました。

１）オペ看が2人

２）オペ看1人オペ看ペアグループより1人#オペ看が1人の場合は、オペ看ペアグループより1人ペアとする

３）オペ看0人 オペ看が0人の場合は、手術看護師不在時グループより2人　さらにその中でも優先2人が存在

そこで、現プロジェクトをその時点（２０２３年６月に下記のように仕様変更しています）の言語制約と列制約に置き換えました。

①手術担当看護師はどちらか1名、平日に在中させる。

②手術看護師は日・祝日の日勤はしない。　夜勤はする。

③手術看護師2名不在時は中堅看護師をペアにする。

恐らくは、

昔のプロジェクトファイルベースで何か修正をしたことが原因

であろう、と思れます。

対策としては、

■プロジェクトファイルのバージョン管理をしっかり行う

ことは、当然ですが、そのほか、下記のようにメモ欄に変更履歴を残しておくことも有効かと思います。

昔のプロジェクトファイルは、昔の履歴状態のままなので、求解時に気づくと思います。

   

Q.制約名 平日休みの数が6名を超えない金の６を変えても何も変わりません

 Ans.

制約名は、動作に影響を及ぼしません。その目的は、他の制約と区別することにあります。

離婚して名前が変わったとしても、本人は本人のままで変わらないです。同じように制約名が変わったとしても、制約の中身は変わりません。（別な例えとしては、制約名は住所のようなものです。区画整理や、市の等号合併により、住所が変わったとしても、その家の造りは、変わりません。）

ですから、例えば、ＡでもＢでも名前は何にしても同じです。

実際に動作を変更するには、

最大、最小の数値を変更することによって初めて作用します。

Q.長日勤・入りが先月部から連続しないときがあります。（ブランク予定でもエラー0になってくれない）

 Q.ブランク予定ですが、

      次のようなエラーが消えません

Ans.

　先月勤務表での制約不足です。次の青部制約を追加してください。

　制約最終日に長日勤となる連続４勤務を防止します。これにより、先月から６連続勤務とならないように、必ず休みが入ります。

**ご注意：

上図では、先月制約から変更しているため今月部にまたがるところのソフトエラーが消えています。今月から適用する場合は、その効果が出るのは、来月以降となります。

Q.ご相談依頼

 Q.当院は師長及び理事長が勤務表の作成をしておりました。 今後はソフトを導入し、各スタッフの希望に沿いつつも、ある程度公平にした勤務表を作りたいと思っています。

 もしよろしければご相談に乗っていただければ幸いです。

Ans.

⇒恐れ入りますが、ZOOM予約は、プロジェクト作成サービスのご利用が前提となっております。無償でのZOOM相談は、基本的には行っておりませんのでご理解の程お願いいたします。

スケジュールナースを使いこなすのに必要なのは、国語力

 正月に、親戚の高専生がゲームプログラマを目指している、というのを聞いて、老婆心ながら、「プログラマになるなら国語力が大事だよ。」

と言ってしまいました。そう言っているのは、私だけではないようで、

プログラミング教育にはどうして国語が必要と言われるのか？ | ティーチャーズメディア

国語力とプログラミング力の関係　解説編：【写真】天才プログラマに聞く10の質問（4）（1/2 ページ） - ＠IT

「子どもを無理矢理プログラミング教室に通わせる必要はない」…大学教授が解説"小中高での必修化"本当の価値（プレジデントオンライン） - Yahoo!ニュース

スケジュールナースを使う上においても同じことが言えると思っています。スケジュールナースは、プログラムじゃないじゃん、と言われるとその通りです。スケジュールナースは、ノーコードプラットフォーム、という見方はある意味正しいです。

しかし、実は、皆さんは、「制約プログラム」をGUIで書いています。コンピュータに指示するというのは、GUIではありますが、言葉で指示をしていることに同じです。言葉なしでは、一切動きません。言葉という指示があって、スケジュールナースは、動きます。

仕様を人に伝える、にしてもそうです。ユーザさんの中で、お医者さんやら看護師勤務表を作っておられる方がいらっしゃいます。この方は、現役ではないのですが、いわゆる事務屋さん、だと思います。そういう方が、畑違いの仕様をまとめて提示してくれていて、非常に助かっています。で、その力の源泉は国語力であると思う次第です。使いこなすのに、ITエンジニアである必要はない、という証明だと思います。

プログラムでも、最初からコーディングすることはありません。何を実現するかというのは、企画書や仕様という日本語という言葉で形にすることで明示することから始まります。概念や目的等、抽象的な要件は、日本語という言葉から始まります。

このユーザさんのように、事務または事務長さんであるユーザさんは結構多いと思います。（訪問クリニック、産科クリニック、脳神経外科クリニック、数病棟の公立病院等、サポート経験からの推測です。）

人と人とのコミュニケーションに長けているということ、人の話を聞くこと、理解してまとめること、これは、全て国語力です。なので、別に看護師長である必要はない、ということだろうと思います。勿論、看護師長自身が使いこなせれば、それがベストですが、制約をメンテナンスする人が、看護師長である必要はありません。

男性か女性かという点においては、経験上、男性の方が国語力の優位性が高いと思います。何故かは分かりません。男性の方がロジカルである傾向があるからかもしれません。

女性がビジネスで活躍するには「ロジカルシンキング」をもっと学ぶべき？（横山信弘） - エキスパート - Yahoo!ニュース

性別を問わず、どんなにITリテラシーに疎くても、国語力とやる気さえあれば、サポート出来る自信はあります。言葉のコミュニケーションさえできれば、必ず前に進めることが出来るからです。

ちなみに、今までに出会ったなかで、国語の達人と思うのは、弁理士さんです。特許の請求項をクレームと言うのですが、クレームでは、日本語で論理的なことを漏れなく明確に記載する必要があります。私が書いたクレーム原案は、殆ど跡形もなく添削されて別なクレームになるのが普通です。それは、特許クレームという一見複雑怪奇な文章ではありますが、見事に精緻で一分の隙もない文にする日本刀の研師のような作業です。これを成すには国語力、ということをおっしゃっていたのを思い出しました。

その弁理士さんは、推敲の際、句読点を区切りながらクレームをよく音読していました。正しいかどうか常に反芻しながら頭を回転させていたのでしょう。で、

スケジュールナースで制約が思い通りに動かないとき、制約を音読してみる、

というのをお勧めしています。自分が今書いた制約が、確かに意図通りであるか？反芻することで、バグを発見できるかもしれないからです。

従前の入力スタイルによる求解の仕方

 まずは、ブランク予定で、UB=0を確認しておきます。

UB=０になっています。

スタッフの希望や、決まった予定を入力します。入力したらロックします。

全部ロック　します。

ロックした部分は、黄色になります。

求解してUB=0になっていることがベストです。UB=0とならなくても、許容範囲であるかどうかが、ポイントになります。許容範囲でないとすれば、予定を変更する必要があるということですが、それはまた別の機会に。許容範囲内であると仮定して話を進めます。

さらに、自分が良いと思う勤務を入力していきます。黄色部以外が入力したところです。

途中、途中で求解します。

その都度に、解が存在し、そのベスト解が提示されます。それは、これ以降人間が如何に入力しようとも、それ以上に目的関数値は、変わることはない、ということです。（解が固定されるという意味ではなく、コンピュータが示した勤務品質の値UB（目的関数値）を下回る割り当てを物理的にも能力的にも人間が出来る筈がないという意味です。）それが、気にいらなければ、

取り消し、やりなおしにより、入力途中まで戻って再トライします。以上が従前スタイルによる勤務表作成の仕方です。

同じスタイルではありますが、違いは、解が存在する保証があること、そしてベスト解よりも良い解（目的関数値が低い）が存在しないことが違います。自分が入力した勤務パターンでは、其のあとにどんなに頑張っても相応のエラーとなってしまう将来が示されることです。

この違いは、大きいと思います。安心できるのでは、ないでしょうか？

入力の仕方は、従前のやりかたと全く同じです。しかし、良いと思った勤務パターンを入力していっても、スケジュールナースが示す将来のベスト解がエラーだらけ、ということに早晩気づくことになるでしょう。散々入力した挙句に、結局は、スケジュールナース解を採用、もしくは、部分の修正ということに落ち着く、　と思います。いつも同じ修正が入るならば、それは制約を追加した方が時間の節約になる、ということになろうかと思います。