長日勤補償の有無による看護師QOLの評価

 ユーザ要求による実装と、通常の夜勤数・長日数の設定とで、勤務品質がどのように変化するかを見ていきましょう。

プロジェクトでは、簡単にマクロで切り替えられるように実装しています。

ユーザ要求による場合は、「ユーザ要求による実装」の行の値（D1）を１にして「設定」ボタンを押すことで設定されます。ソフト制約を有効にする場合は、2行目のD2を１にします。

３行目は、それに伴うパラメータの変更のためにのものです。ソフト制約でない場合は、範囲を（Min0，Max０）→(Min0,Max1）に変更する必要があります。そのため、D2の値をそのまま使います。

該当箇所は、以下になります。

日本語文字列が化けているのは、Python変数として文法エラーが出ないように問題となるキャラクターをスケジュールナースが自動追加変更している為です。

マクロで以下の１）２）を切り替えます。

１）ユーザ要求による長日勤務日数補償あり。半日休日を０．５公休をとカウントし補償する。公休日数は、±０．５で変化する。できれば、長日と夜勤数が同じになる（±0）となるソフト制約あり

２）長日勤補償なし、夜勤回数範囲は３－５回、長日勤回数範囲も同じ範囲に制約する

結果

１．予定あり

以下のような予定が入っています。８月で大量の夏休みが発生しています。

１）補償あり

行制約レベル４のエラー数が１８個あります。これは、夜勤明け後２連休できなかったケースが１８回あったことを示しています。(スタッフ２８人で、平均夜勤数は４回程度です。）

２）補償なし

夜勤数は、下のスタッフプロパティシートで規制されています。長日勤も同様に記述可能ですが、そもそもユーザ要求は、長日差±１以内、できれば０であるために、記述せずブランクにしています。

評価の切り替えの都度、長日勤数の書きこみ・クリアが面倒なので、この評価時は、Pythonで夜日勤範囲を読み込み、同じ範囲に長日数を設定しています。

２．予定なし

予定をAllClearした状態での比較です。明け後の2連休は全て満足しています。理想パターン日日長夜明休（レベル１ソフト）に対してだけ、差が出る結果となっています。

１）補償あり

２）補償なし

＜考察＞

補償なしとすることで、

夜勤２連休エラー　：8個から18個に増加しています。

求解時間：　　　92秒から176秒に増加

この原因は、そもそも重い制約であることに加えて長日補償付加による解空間の減少と考えられます。予定なしにしても同様の傾向が観察されており、長日補償に纏わる普遍的事象と考えます。

シフト勤務を少しでも楽にするための変則2交代が、勤怠システムの要請のために、自らのシフト勤務を厳しいものにしています。言い方は良くないですが「自分で自分の首を絞めている」、とも言えるのではないでしょうか？

一般化した変則2交代 (nurse-scheduling-software.com)

勤怠システムが柔軟でさえあれば、今月で補償することは拘らず、来月以降の累計による年休等での補償で解決する問題です。長日移行時には、是非考えて頂きたいと思います。

本題とは、関係ないのですが、予定がなければ、公休が１０個の基準月であるために、明け後の2連休が難なく実現出来ています。言い方を変えると、自分達の希望の多さが明け後2連休の実現を阻害している、とも言えます。（今回平日日勤7名以上に対して殆ど実現出来ていないという問題もあります。希望の多さが組織としての目標の実現も阻害しています。）

2連休を実現出来ていないスタッフが誰になるかは分かりません。言い換えれば、希望を多く出した者勝ちのシステムになっている、ように思えます。これも、多くの職場で見られる事象です。

少ないリソース下で、どう組織の目標(事故に対するリスク軽減）を実現し公平なスタッフのＱＯＬを実現するのは、管理者としての腕の見せ所だと思います。これからの師長さん、管理者は、こうしたツールを使いこなす技量が管理技術として求められるのではないでしょうか？