新しい勤務表作成形態

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

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

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

と思っていたのですが、その職場ではそうではなく、次のように教えて頂きました。

＊＊＊＊＊

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

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

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

メリットとしては、

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

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

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

長々と記載しましたが、

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

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

＊＊＊＊＊

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

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

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

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

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.

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

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

**ご注意：

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