自動勤務表ソフトの使い
かた
病棟勤務表事例で見る実践的使い
こなし術
2016.Mar.17 菅原システムズ
自動勤務表は魔法の杖ではありません
• リソースを超えて配置することはできません。
• 計算機に教えるルールが整理されていないと失敗
します。
• 何かを優先することは、何かを捨てることです。
用語集
ソルバ
答えを出す脳、に相当するソフトウェア
制約
勤務のルール
解
制約を満たす答え
ハード制約
必ず満たさないといけない制約。
ソフト制約
出来れば満たしたい制約
オプティマイズ
最適化。エラーの数を1個づつ減らして最小化すること。
リソース
人的資源。使用例）リソースがない➡人がいない
行
横方向の列
列
縦方向の列
充足
制約を満たすこと
エラー
失敗。誤差（目標値からのずれ、ペナルティ）
ボトルネック
その制約を満たすことが難しいために解がない状態
トレードオフ
何かを達成するために別の何かを犠牲にしなければならない
関係のこと。
用語集２
プロジェクトファイル
制約,予定入力や解を収めたお客様専用設定ファイル通常
月毎に名前を変えて作成します。
弊社SE
弊社システムエンジニア
ハードエラー
解が存在しないこと（ソルバが矛盾を認識したときに出すエ
ラー）
solution1
1番目の答え、solution2は、2番目の答え
計算機にルールを入力する前に
• 明文化しましょう。
• 自分ではなく、他人に
理解してもらう文章にし
ましょう。
• 計算機は、曖昧さが苦
手です。
国語が大事
コア機能と希望仕様
コア仕様 - 守らなければならない必要最低限、または禁止事項
希望仕様 - 出来たら実現したい、または出来れば避けたい事項
お客さま
計算機入力(菅原システムズ）
希望仕様
ソフト制約
コア仕様
ハード制約
土台が重要！
コア仕様記述例（お客さま側で作成していただきます）
2交代 夜勤入明け型
夜勤スタッフ24名
看護師長1名 夜勤しない
夜勤入回数は、4回以下3回以上
夜勤明回数は、4回以下3回以上
夜勤回数制限者が1名、夜勤3回以下2回以上
夜勤回数制限＋土日しか夜勤はできないスタッフが1名
休み日勤は6名
平日日勤者は10名以上
夜勤明けの後は休み
土日連続フリー休み1回以上
6日連続勤務禁止（最大連続勤務は5日まで）
最小夜勤間隔は5日以上
休み日勤は各グループから3人以上
希望仕様例（お客さま側で作成していただきます）
夜勤回数はできるだけ平準化
リーダ回数は平準化
夜勤明けは、基本は休み、早番は禁止、休みが不可なら遅番、遅番も不可なら日勤
ケアスタッフは、出来れば平日3人、最低でも平日2人以上
夜勤は、看護師1人以上
制約の入力はお任せください
• 頂いたコア仕様、希望仕様をベースに細かな点を弊
社SEがヒアリングします。
• 計算機への翻訳作業は弊社SEが行います。
改善を経て使えるシステムに
• 一度の制約入力で済むことはありません。
• １００の病棟があるとすると１００の違うルールがあり
ます。
• さらに、月々、細かな変更が発生するのは常です。
最初の数か月は、勤務表作成日に常駐して変更の
仕方をお教えします。サポートなしに、細かい変更
については、出来るようにすることが目標です。
勤務表は行と列の制約から成ります
スタッフ毎の制約：行制約
Day毎制約：列制約
制約が適切だと望みの解が得られます
望ましい解を得
るには、正しい
ルールを教えて
やる必要があり
ます。
制約がないと出鱈目な割り当てとなります。
ソルバは、与えられた制約下で満たす
解を探すだけです。制約がないなら、
自由に割り振ってよいと解釈します。
数独のルール：各行1-9、
各列1-9、各ブロック1-9
がダブることなく割り振
られること
制約に矛盾があるとき解がないと言います
時間内に見
つからない
ときも解が
ないと言い
ます
オプティマイズ時間。通常10秒、
時間を掛けるとき60秒位
複数解出力で、それ以上別解がないとき
solution2(解2)が無かったと言っています。
言い換えると、解１は求められたことが
分かります。
行制約-弊社SEが入力します。
ブランクはハード制約
スタッフ集合指定
ソフト制約
ただし１はリザーブ
最大4個まで可。5は禁止
列制約 弊社SEが入力します
スタッフ集合指定
Day集合指定
1以上1以下=>Onlyone
提出のプロジェクトファイルで求解します。
解が得られるのでチェックして終了
制約はAND集合からなります
夜勤回数4回以下
解は、赤
部集合
平日スタッフ7人以上
制約が多いとそれだけ解の範囲が狭くなります
夜勤回数4回以下
平日スタッフ7人以上
解集合
明けの後は休み
休み日勤は6名
スケジューリングは制約の積み重ね
• スケジューリングは、制約という
積み木の積み重ねです。最後ま
で倒れずに積み重ねができたと
きだけ、解があります。
• 積み重ねは、AND を意味します
。
• 制約という積み木をどんどん積
み上げて行くと、一つ一つの制約
は難しくなくても、すべての制約
を満たさないといけないので次第
に難しくなっていきます。
• 途中で崩れてしまう（矛盾がある
と）と、解がありません。
途中の解
•
•
解が完成しない状態で出して、後はギブアップしてしまうソフトウェアがあ
ります。
しかし、スケジューリング問題は縦と横が複雑に絡んでいて局所部分で
の別解は殆どないことが普通です。（予定入力制約により解の範囲が狭
くなることが原因です。）
• ⇒結局、全体見直しを余儀なくされます。
部分的にブランクにて可能な別解個数を調べる
ハード制約
•
•
•
•
必ず満たすべき制約です。
必ず満たせる制約である必要もあります。
ハード制約を一つでも満たさないと解がありません。
ハード制約のみの場合、いわば、１か０のデジタル
世界です。解があればよし、無ければ＊なにも出力
されません。
• 満たせない可能性のある制約はソフト制約にします。
＊原因解析機構はあります。
ソフト制約
• 必ず満たす必要はないけれど
も、できれば満たしたい制約
です。
• ハード制約は１か０だったのに
対して、ソフト制約は、アナロ
グ的です。
• 個別にみると1か０ですが、全
体として総数で見た場合に、
できるだけ理想に近づける機
構（最適化）が働きます。
• ソルバは、望ましくない勤務を
エラーとして各エラーを加算し
総和数を最小化します。
ソフト制約
レベル１ （最低 、リザーブ 通常使わない）
レベル２
レベル３
７レベルの優先度設定が可能です
小
レベル４
重
要
度
レベル５
レベル６
ハード
レベル７ （最強）
ハード
大
レベル７より強い制約はハード制約になります。重要・基礎的な
部分はハード制約とします。制約の大半はハード制約になります。
ソフト制約は４レベル程度までをお勧めします。
ソフト制約
• 通常意識する必要はあ
りませんが、内部的に
は更に、レベルが分か
れています
予定制約
行制約
列制約
外部制約
ソフト制約設定例 弊社SEが入力します
遅番早番禁止
ハード
明早番禁止
ハード
明休みが望ましい
ソフト制約レベル３
明日勤は望ましくない
ソフト制約レベル２
ソフト制約要因
• 各ソフト制約は適用チェックボックスで適用すること
ができます。
チェックした制約だけ適用される
オプティマイズ
中。エラーの数
を一個一個減ら
します。
ソフト制約設定結果 （年休消化）
•
全員が1回取得のソフト制約に対して殆どの人が年休1回（す）取得出来ている
1個のエラー。ハード制約にしていた
ら解がなかったと言えます。
何を優先するということは、何かを切り捨てること
• 特にリソースの限界に近いシステムでは、ソフト制
約は必須です。
• 優先度の高い制約は優先的に確保されますが、反
対に低い制約は、満足行かない結果になるかもし
れません。
• 何を優先するということは、何かを切り捨てることで
す。高速求解により、この辺のトレードオフを複数パ
ターン試してみることをお勧めします。
• 最も望みの結果に近い、優先レベル設定、エラー数
設定、求解時間をユーザ様自身で発見してください。
制約化するか予定入力か？
• 恒久的な仕様 ➡ 制約化
• 複数の人（将来含む）に当てはまる制約 ➡スタッフ
毎の設定で変更可能な制約化
• その月、そのスタッフだけ ➡ 予定入力
師長さんへ
制約化は
準夜：土曜日以外、日～月可。
深夜：水曜 金曜のみ （日深）可
深準： 準まで連続でできます。第2第3週目に多
めにつけてもらえると助かります
土日祝日勤 可能ですが、土曜日は、保育園が6時
までなので、日祝を多めにしてもらえると助かり
ます。
無理です
その個人だけ・その月だけ
• ⇒制約化するよりも予定入力で入れてしまった方が速い。
GUI設定-スタッフ毎の設定（弊社SEが初期設定します）
運用の経過に伴い増えて
いく傾向があります。
• 各スタッ
フ毎の
属性を
設定
• 月々の
変更は
ほぼこ
のペー
ジの変
更だけ
で対応
スタッフの諸事情を考慮してます
毎月の勤務表作成方法
•
•
•
•
•
•
スケジュール開始日・終了日を変更します。
予定がなけ
前月末の解を今月に移動します。
れば解くの
は容易の筈
解がすぐ出てくることを確認します。
スタッフの休み希望を入力します
解がすぐ出てくることを確認します。
時々解があることを確認しながら、制約化されてい
ない予定入力を入力します。
• 最終リリースで、時間を掛けて求解して終了。
• 必要に応じて複数解のなかから選びます。
スケジュール開始日の設定
スケジュール期間の設定
前月末の解を移動 （解があることを確認をしま
す。）
表示スタート日
スケジュール開始日
前月結果
スケジュール終了日
休み希望を入力します。（解があることを確認）
休み希望
看護師長が考える制約外のこだわりを入力します。
さらに、思いを
追加
求解して解を得ます。
解を入力に戻す
• 解を全部入力に戻して、マニュアルで気に入らない箇所を修
正していくこともできます。（制約化もご検討ください。）
解画面
予定入力編集画面
戻した解をブランクにして再編集／再求解も可能
解がないとき
• 原因解析機構が自動で働きます。指摘された原因を
取り除いてください。
エラーの要因を列
挙します。
エラーの潰し方をナビ
ゲートします。
「解がない」格闘を回避する
•
•
•
•
•
崩れた積み木の原因がどこにある
かを調べるのは技術的にも難しい
問題です。
原因となる要因を列挙する機構を
持っています。通常一つのエラーに
対して複数個の要因を持っていま
す。
複数個のエラーがあると列挙された
要因も多数に渡り原因を特定して
解決するのは難しくなります。
そこで、制約の変更前後で解の存
在を確認しながら少しづつ変更を行
うようにします。
解があったら上書き保存しましょう。
エラーは複
数の要因間
の矛盾で発
生します。
エラー
崩れてしまった原因
を探すのは難しい
要因１
要因２
要因３
エラーが複数あ
るとなおさら難
しくなる
矛
盾
予定入力時のエラーの対処 原因の特定
•
予定入力を全てソフト制約にして解を求めると解が存在するための最小の
変更を知ることが出来ます。
予定変更の最小解を知ることもできます
予定入力と違うと
ころを反転してい
ます。
日勤を準夜にしな
いと解がないこと
が分かります
Restore/Undo機能
• 予定入力においては、Restore/Undo機能が便
利です。入力の巻き戻しが出来ます。
• 編集の途中で解の存在チェック、今行った変更
で解がなかったらUndoで巻き戻す。
Undo
Redo
解が気に食わないとき
•
•
•
•
複数解を見る
ソフト制約優先度をいじる
列方向ならペア禁止制約・ペア制約追加を検討
制約を追加する ➡ 菅原システムズに依頼、また
は、自分で直す
• 解を編集する ➡ 最後の手段。 ただし、元の制約
を無視した変更になっていることが多いです。それ
でもよければ良いのですが、ルーチンワークなら制
約を見直した方がベターです。
ペア禁止・ペア制約
• ペア禁止は、あるスタッフとあるスタッフを同じ勤務
にしたくないときに使います。経験的に多めでもボト
ルネックにはならないようです。
• ペア制約は、プリセプタ・プリセプティの関係あるい
は、会議のように同じ勤務を強制しますが、少数(1
組）でもボトルネックになってしまうことが多いようで
すのでソフト制約とするか期日を指定しましょう。
こんな使い方もー勤務希望に優先度をつける
• 希望が多ければ多いほど、解の空間は狭まり良い
解が得にくくなります。
• 希望数の多い職場ほど、逆にスタッフのQOLを下げ
る要因になっています。
• 例えば、絶対に取リたい休み、できれば取りたい休
みとして優先度をつければ、相互に利益があるので
はないでしょうか？
サポート上での経験ーよくある誤解
• 人間の方が良い勤務表が書ける ➡ある意味正しいで
すが、ある意味正しくありません。計算機に制約を入力する
と否応なく、制約を満たさない答えは排除されます。脳内制
約下で出来るのは、(無意識に）ルールを捻じ曲げる（満たさ
ない）からです。計算機は、融通が利きません。このことに慣
れるのに時間がかかります。同じ制約下なら、人間に勝ち目
はありません。
• 言葉にできないルールがある ➡そうかもしれません。
でもいつも行っているルーチン的な修正ならそれは制約化で
きるかもしれません。是非サポートまでご相談ください。
今までのやり方とは違います
高速求解により、計算機と対話しながら作り上げていく
ことが初めて可能になりました。スタッフの諸事情や
看護師長の思いをこれまでより反映することがこと
が出来ます。
もし、いつも行っているルーチン作業があったならそれ
は制約化、すなわち自動化できる可能性があります
。サポートまでご相談ください。
自動スケジューリングの肝は、制約化にあります。こ
の事を理解して活用することが勤務表という仕事の
設計書を優れたものにする極意です。
道具として使いこなす
• 今まで人間が出来なかった筈の制約は、いつの間にかでき
ることがあたり前のようになってきます。しかし、計算機が
行っているのは、限りある人的資源を最適利用するだけで、
魔法の杖ではありません。資源には限界があるので、あると
ころでそれ以上良い解が得られないということになります。計
算機が得意なのは与えられた制約下で解を素早く見つけ出
すことだけです。
• 一方、計算機に何が重要で何が重要ではないかを教えられ
るのは人間しかいません。また、出てきた複数の結果の良し
悪しを判断できるのも看護師長しかいません。道具を使いこ
なして頂ければ、開発者として望外の喜びです。
•
ご清聴ありがとうございました。

制約の書き方-業務システムで望ましい解を得る