2025年5月31日土曜日

Q.新人の夜勤回数だけは、制約をキープしたい

 Ans.新人の夜勤回数の制約レベルを上げて、重みを独立に変更できるようにします。

以上です。


2025年5月30日金曜日

Q. 水土は、早番・日勤2名以上

 Ans.

今月水土という曜日集合を作ります。

列制約で制約します。

以上で完了です。

<Notes>

既に、Defaultで、早番・日勤共1名以上という制約が存在します。その特殊ケースである今回の制約は、何ら矛盾することがないので、書き連ねることが出来ます。

2025年5月29日木曜日

Q.夜勤責任者および週末責任者

 Q.

■ 責任者に関する制約

夜勤責任者:

夜勤者3名(夜勤専門)のうち、必ず1名は「夜勤責任者グループ」から選出され勤務

する必要あり


週末責任者:

土日祝日の勤務には、必ず1名は「週末責任者グループ」から選出され勤務する必要

あり

Ans.

グループ集合で、責任者のレベルを定義します。


スタッフ定義で責任者を定義します。

グループ集合で、責任者レベル1を定義します。

制約します。

以上です。

<Notes>

当初、責任者レベル6まで定義していましたが、実際的には、一つだけにしたようです。


2025年5月28日水曜日

Q. あるスタッフは、出来ない遅番の種類がある

 Ans. 管理上分ける必要があるシフトは、分割します。

出来ない種類の遅番を遅3として追加します。


遅番集合を定義します。

遅番集合で制約します。

遅3のスタッフ毎のシフトを設定します。


遅番集合と、遅3に関わる制約を変更追加します。

遅3の回数を平準化します。

遅3の間隔を制約します。

遅3の回数を定義する集合を設定します。




以上で実装終了です。

2025年5月27日火曜日

Q.Xさんは、1日のうち早番を行い、かつ生活相談員としても活動する。どちらも早番、生活相談もカウント管理したい

 Ans.

シフトは、1日に1個だけです。早番シフト、生活相談シフトは、各々単独の仕事のみになってしまいます。そこで、早番付生活相談(短早)というシフトを新たに追加します。



早番集合、生相集合というシフト集合を新たに追加し、それをカウントするように変更します。


早番をカウントします。(短早を含みます。)


生活相談のカウントには、短早を含むようにカウントします。

新たに追加した短早は、全員に初期チェックが入るので、必要な人以外はスタッフ毎のシフトを外します。

以上で完了です。

<Note>

この例では、1日のうち複数の業務を行うシフトが1個だけですので、シフト型勤務表のままにしました。このタイプが2~3個のうちはシフト型勤務表のままで対応可能です。それ以上に状態数が多い場合は、タスク型勤務表にすることをお勧めします。

2025年5月26日月曜日

Q.責任者制約その他について

Q. 

夜勤当日:

夜勤専門スタッフが夜勤に入る場合 → 遅番スタッフは 3名 必須

夜勤専門以外のスタッフが夜勤に入る場合 → 遅番スタッフは 2名 必須


夜勤明け翌日:

夜勤専門スタッフが夜勤明けの場合 → 早番スタッフは 2名 必須

夜勤専門以外のスタッフが夜勤明けの場合 → 早番スタッフは 1名 必須


水曜・土曜の特例:

水曜日および土曜日は、早番・遅番・日勤スタッフの合計で4名以上 必須


新たな制約

■ 責任者に関する制約

夜勤責任者:

夜勤者3名(夜勤専門)のうち、必ず1名は「夜勤責任者グループ」から選出され勤務

する必要あり


週末責任者:

土日祝日の勤務には、必ず1名は「週末責任者グループ」から選出され勤務する必要

あり


夜勤責任者と週末責任者が選出されるに制約したつもりですが、解がおかしいので原

因を追究していただければ幸いです。


Ans.

仕様とプロジェクトファイルを拝見しました。大変申し上げにくいのですが、無償で行うレベルではないと判断いたしました。

選択肢として下記二つを提案したいと思います。

1)今回1回限りの対応 1万2千円 (ZOOM1回レクチャ付)

2)プロジェクト作成サービス 5万5千円 (1年間サポート、期間内の変更を承ります。ZOOM回数の制限はありません)


いずれかをお選び頂きたくお願いします。

1)の場合は、お安くできますが、また仕様変更が発生した場合に、また、再度費用発生の可能性があります。

2)通常のプロジェクト作成サービスと同じですが、既にライセンスをお持ちですので、その分差し引いた額になっています。

ご検討をお願いいたします。

なお、1)2)に関係なく既に作業には着手しております。


2025年5月25日日曜日

Q. 準夜の後の遅番、早番を禁止

 Ans.

遅番・早番があるのは、介助員だけですので、介助員のみの制約としています。



2025年5月23日金曜日

看護研究でスケジュールナースを使う場合は無償で提供します

興味深い論文です。 

https://www.jstage.jst.go.jp/article/janap/21/1/21_7/_pdf/-char/ja

このような研究はもっとなされてもよいと思います。

常々提起している、「休み希望無制限の職場で、出した者勝ちになる問題」、あるいは、変則2交代勤務における急な欠勤者の対応割り当ての困難化等、看護師勤務表は、看護品質と直接に関わってくる重要なテーマですが、残念ながら、現場サイドの研究は多くありません。

そこで、その方面での議論を活発化させることを目的として、無償で提供することにしました。

看護品質の担保と看護師QOLのバランス

看護研究でスケジュールナースを使う方については、無償で提供することにします。研究終了後も、そのまま病棟1ライセンス分として継続使用することができます。

提供形態は、こちらになります。

ストア買い切り版

審査はありませんが、所属と研究目的についてはお知らせください。(進捗・結果報告等の義務はありません。)

また、必要でしたら初期設定のZOOMレクチャを開催します。(複数の参加者による聴講・実習となる可能性があることをご承知ください。)

ご質問・ご希望のかたはサポートまでお問い合わせください。





Q.前後に夜勤のない土日2連休を1回以上

 Ans.


3交代勤務者の金曜日の準夜がないこと月曜日の深夜勤務がないことが条件になります。

介助者については、夜勤のない人もいるので、単純に土日連休としています。



2025年5月22日木曜日

Q.夜勤で男性のみを避けたい

 Ans.女性が1名以上居るようにします。


グループ定義を下記のように追加します。


スタッフプロパティシートを設定します。

列制約で制約します。

なお、看護師長以外の女性集合は、以下のグループ集合で作っています。

解です。


2025年5月21日水曜日

Q.準夜3人深夜2人、準夜は看護師2名としたい

 Ans.

看護師長・看護師・介助員をグループ定義で定義します。


スタッフプロパティを設定します。

列制約で制約します。

解です


2025年5月20日火曜日

Q.介助員の設定方法

 Q.介助員は、日勤をしない。準夜や早番・遅番のみを行わせたい。また、看護師は、遅番早番を行わない

Ans.

スタッフ毎のシフトで、担当しないシフトのチェックを外します。その際、「先月部には、本設定を適用しない」のオプションにチェックを入れておくのが吉です。


プロジェクト修正済です。





2025年5月19日月曜日

Q. (他の)皆さんは解を変更しないでやれているのでしょうか?

 Ans.

勤務表作成サービスで作成されたプロジェクトにおいては、特に解を変更する必要はない?と認識しております。解を変更する必要があるのは、一般には欠勤者対応により勤務の変更があったときです。(スケジュールナースの場合は、解を変更することは推奨していなくて、予定を変更することを推奨しています。)

それを除けば、特に解を変更する理由はないという認識です。もし、毎回変更する必要があるなら、それはモデリング不足の可能性が高いです。サポートまでご相談ください。


2025年5月17日土曜日

Q.本当にこんな複雑なことを皆さんやっているのですか?

 Ans.

<スケジュールナースの操作>

スケジュールナースの操作については、「そうです」という回答になります。

プロジェクトファイルが完成しているならば、勤務表作りは、従来の手作業で作るやり方と本質的には同じです。違うのは、手作業の場合は、途中解の存在があるかないか分からない状態で進むしかないのに対して、スケジュールナースの場合は、「どんなにこれから頑張ってもこれ以上良い解は、ないですよ。」という未来の解が求解で即、明示されることです。

<制約の設計・メンテナンス>

一方、スケジュールの操作とは別に、制約を設計したりメンテナンスをしていくのは、全ての方が行っているということではありません。

勤務表作成サービスを利用されている方は、初期時にその必要はありません。しかしメンテナンス上、将来あり得る変更については、そのやり方を学んで頂く必要があります。1年間という長い時間の中で、変更のご要求を受け付け、その場その場でそのやり方を学んで頂く方法に数年前から変更しました。この理由として、勤務表作成ルールは、自然に変更が発生していくものであり、結局は、ご自身で学んで頂くことが、永く使い続けることが出来ると考えたからです。それは、仕様⇒制約化⇒スケジュールに組み込みという一連の流れをご自身で行うことを意味します。

多病棟の病院では、各師長さんは、スケジュールナースを操作はしますが、基本的に制約のメンテナンスは行いません。事務部門や看護管理部門のZOOMレクチャを受けた担当者が制約のメンテナンスを行うことになります。しかしながら、クリニックや介護関係さらに個人でサブスクをご購入頂いた方は、費用上、中々そういう訳にもいかないと思いますので、ご自分で学習して頂くことが必要です。そのためのガイド本(自動勤務表: これからはじめる | 菅原孝幸 | 工学 | Kindleストア | Amazon)が出ていますので、そちらで学習して頂きたいと思います。


仕様に関しては、ソフトウェア、スケジュールナースには依存しないことに注意してください。複雑なのは、スケジュールナースではなく、仕様自体です。つまり、暗黙のうちに勤務表作成者は、大変色々な事を考えて作成しています。それを機械化するには、ルールの明示からまず始めることが必要です。実は、この部分が最も大きなバリアであって、そこを乗り越えられれば、殆ど障害はない、と言ってもよいと思います。まずは仕様から整理されることをお勧めします。

参考 

仕様とは?

https://www.nurse-scheduling-software.com/japanese/publications/lecture_notes_for_operations_of_rostering_projects.pdf#page=6

其の後に、モデリングという作業が必要になります。スケジュールナースのシフトを何にするかというのは、こちらをご覧ください。

https://www.nurse-scheduling-software.com/japanese/publications/lecture_notes_for_basic_project_file_description.pdf#page=21

2025年5月16日金曜日

Q.全く動きません

 Q,6連勤をしない、土日休みは必ずつける、2連休の間隔は14日以上あけない、夜勤間隔は3日以上あけ、できるだけ常勤の夜勤回数を平均化する等が出来ていません。



Ans.「解がない」状態となっています。「解がない」状態とは、で何か言っている状態です。「解がない」ときの解は、意味がありません。見ないでください。

「解がない」とは、ハード制約間の矛盾によって引き起こされます。具体的には、Kindle本(自動勤務表: これからはじめる | 菅原孝幸 | 工学 | Kindleストア | Amazon)を読んで頂き、ハード制約とソフト制約についてとは何か?から学んで頂く必要があります。

看護師勤務表作成は、簡単ではありません。一つ一つの制約を丹念に積み重ねる作業が必要となります。一朝一夕に出来ることはありません。これは、看護師勤務表作成の本質的複雑さに起因します。どんなにAIが発達したとしても、問題そのものの複雑さは変わりようがないことに注意してください。この問題を計算機に真面目に解かせたいならば、生半可な気持ちでは、立ちゆきません。焦らず、ゆっくりと一つ一つ理解しながら進めてください。

それでは、具体的なエラーの解消方法を説明します。

1)指摘されている制約の中身を見る

赤丸をダブルクリックして

制約の当該箇所を見ます。
土曜日に公休でないことを禁止、つまり、土曜日は公休にする、というハード制約になっていることが分かります。


もう一方も同様に、

祝日の公休は、祝休み(公休でない)を制約しています。これはやはりハード制約になっています。


以上が、解のない状態に至るヒントになります。

一方で公休である、他方で公休でないという矛盾の日が存在すれば、解がない状態となります。つまり、土曜日かつ祝日の日がある、これが原因です。

これを解消するには、どちらの制約をオフにすれば、OKです。

または、ソフト制約化を行います。
(元になったプロジェクト(病棟3交代Newは、ソフト制約化済みです。))



2025年5月14日水曜日

Q木曜日基準の週4勤務

 Q.その月で完結することはなく、木曜基準の1週間ごとに週4勤務のスタッフがいます。

Ans.

月に跨るので、完璧に行うには、端数となる週がないようにします。つまり、丸々1週間となる区間の整数倍の区間となるようにします。そのために、次のように区間の定義を変更します。

来月の最初の水曜日に制約終了日を設定します。そうすると、丁度5週間分のWEEKとなります。週4のスタッフは、来月水曜日まで制約することになります。その他の夜勤数等のカウント数制約は、今月区間(6月)に限定する必要があるので、そのように曜日集合を定義します。


実装

曜日集合の作成

制約開始日を基準にそれよりー6日まで見ると1週間になります。

その1週間の中に必ず木曜日が一つだけあります。

後は、それを基準に1Week,2ndWeekを作っていきます。
第5週まで作ります。

行制約で1週から5週まで勤務4回にハード制約しています。

カウントする制約については、青部を「今月区間」に変更しています。


数をカウントしている次も青部を変更しています。


グループ集合で週4を定義します。

週4にすると、公休数が8では、矛盾してしまうので、対象者の公休数はブランクにします。

対象者は、週4勤務になっています。


次月処理

次月は、今月分まで、予定が入ってきます。他に予定が入ってこないなら、これをそのまま利用してもよいです。また、新たにブランク予定としてしまってもよいです。その場合でも、月始めは、先月まで見て、週4となるように新たに割り振るので問題ありません。

今月部分(先月から見ると来月部分)まで作成したのは、週4勤務の解があることを保証するためです。少なくとも他の予定が入ってこなければ、解が存在することは、先月の解で保証済です。

制約終了日は、次次月水曜日とします。


制約終了日は、自動でOK(-6)です。

解を予定に送ります。

カットしてもOKです



プロジェクトは、以下です。


なお、初期プロジェクトに対して以下を修正しました。