仕様上は、連続勤務9日を禁止にすればよいのですが、9日という長いパターンは、
■長いパターンソルバ負担大
■連続勤務8日禁止は、容易と思われる
ことから、連続勤務8日を禁止 で実装しています。
Ans.
先月部には、本設定を適用しない」オプションをオンにしてください。本設定は、ハード制約ですが、このオプションをオンにすると、本設定は無視(前月部は、全スタッフが全シフトオンになります)されるので、前月部と今月部の制約が異なるハードエラーとなる問題を回避することが出来ます。
パターン最後で制約する(パターン後方タイプ)のは、好ましくありません。パターンの最初が制約最終日の場合、次の月のパターン日は、無視されてしまうからです。
これに対して、パターン最初(パターン前方タイプ)で見ていれば、先月からのパターンで効いてくれるので、問題なく作用します。
特に、パターン後方タイプのパターン最後が休日というパターンは問題です。制約最終日がパターン最初である場合は、次月が休日であっても効きません。
次のパターンは、本来は、後方パターンですが、前方パターンに変更した例です。
次の日が休日入りである場合は、呼び出し(オンコール)タスク禁止という例ですが、前方パターンに変換しています。
GUIで書けます。
■Aは、土日
■Bは、平日
になります。仕様的には、下のような仕様で一見難しそうに見えるのですが、
A=夜=入り または 明け
つまり、土日の夜勤数と
B=代休=x
つまり、平日の代休数
が等しい
と等号関係で記述出来ます。なので、Python を使うことなくGUIで記述可能となります。
お客さまの許可を頂いたので公開します。
現在、開発中のプロジェクトになります。正確には、5年前からお使い頂いていたのですが、最近、大きな変更要求を頂き有償プロジェクト変更を行うこととなりました。
これから、ご要求仕様に対してUpdateを行っていきます。
Q.
2020年よりスケジュールナースを利用させていただき、大変助かっております。この5年間、勤務形態も様々な変更があり、勤務表作成時の追加作業が増えてまいりました。スケジュールナースの導いてくれた「解」で完結できることを希望しております。
Excel スタッフ毎のシフト・タスクのエラー表示改善
■行制約 Day空集合に対して、ハード制約・ソフト制約に関係なく無視に変更
ハード制約は、無視していましたが、ソフト制約は無視していませんでした。今回、行制約Day空集合に対しては、全部無視にソルバを統一しました。
上で第6週は、Empty Day集合ですが、ソルバ上でのエラーは0です。(実行されません)
GUI解上では、黄色マーキングされる場合があります。
■解のコピー追加
解のコピーをすることが出来ます。
この使い道としては、「最小0」で、とりあえずの様子を見るための記述にします。
■ タスク予定基数制約部にリフレッシュを追加
基数制約編集後は、リフレッシュして編集を確定させてください。
Q.
予定入力についてですが、ある日の勤務で「日勤以外」を希望する場合、当院では「当直・明け・休み」のいずれかを希望することになるのですが、そのような予定入力のやり方は設定されていますか?
Ans.
シフト定義の脇にシフト集合のタブがあります。
それで、欲しいシフト集合を合成していただけますでしょうか?
例を添付しますので参考にしてください。
今後、プロジェクト作成サービスプロジェクトおよびレクチャに使用したプロジェクトは、全てお客さまの許可を頂いた上で、
NotebookLM上で、メンテナンスをすることにしました。
個人情報は全て秘匿しますが、シフト・タスク・グループや、グループ集合は、そのまま公開となります。
NoteboolLM上でメンテナンスすることの利点は、
1)他のユーザ実装を参考に出来る
2)実際的な実装マニュアルに出来る
3)何年後かに、担当者が変わったとしても自職場の実装思想、仕様等は、NotebookLM上で共有されており、引き継ぎが楽。
です。
私にとっても、単にマニュアルを見てもらうだけのご質問には、案内をしなくてもよくなり、双方にとってメリットしかありません。
ご理解の程、よろしくお願いいたします。
ご相談を機に、お客さまが作成したプロジェクトファイルを拝見させていただくときがあります。
で、気づくのは、物凄く沢山の予定と制約群があることです。お客さま自身が一から記述したプロジェクトというのは、担当者が変わったりして何年も引継がれてきた資産だと思います。
ではありますが、大体の傾向として、
■ハード制約が多すぎる
■冗長な制約が多い
■予定が多すぎる
ように思います。
で、それを見てしまうと添削したくなってしまい、無償レクチャをオファーすることがあります。勿論、強制ではなく、業務が立て込んでいればお断りして頂いて構いません。
(お客さまの許可が得られたならば、添削例をアップします。)
また、既に私が設計した5年前のプロジェクトも未だ現役で頑張っている例もお見掛けしました。スタッフ名は大分入れ替わっていましたが、ほぼ設計時のままでした。
このように永く使っていただけることも多いのですが、共通しているのは、ルールは初期設計時から、変わっているということです。
初期設計時のままルールが同じであれば、何の問題もないのですが、現実の世界で、ルールが不変の職場は存在しないと言ってよいでしょう。
其のたびに、菅原システムズ等の業者に頼むよりは、
自分達でメンテナンス出来る力をつけておいた方がよい、
というポリシーに数年前より変更したのは、上のような背景があるからです。
グーグル「NotebookLM」入門:信頼できる自分だけのAIアシスタントを作るには? | Business Insider Japan
なるほど、取り込まれるのは、テキストがコピーされることなので、ソースを更新するには、
1)ソースを選択して削除
2)再度ソースを取り込み
する必要があるようです。
はい、サイトを更新したらこの処理を忘れないようにします。
下は、NotebookLMを開いた様子です。
クリックするとソースが表示されます。
次は、チャットで「夜勤の平準化」と入力してみました。
記事のソースが表示されるので、参照したい箇所を素早く見つけだすことが出来ます。
是非ご活用頂きたいと思います。
これで調べたけれども、なお不明な場合に、サポートをご活用頂くのが望ましいと思います。
まとめると、
1)スケジュールナースNotebooklm上で質問
2)1)で不明な場合にサポートに質問(プロジェクトファイル添付が望ましい)
3)菅原システムズの作業時間が一定時間以下ならば、無償サポート。
4) 大抵は、無償サポートとなります。(経験的には、5%程度以下が有償サポートになります。)有償になる場合、お見積りを提出し有償サポートを申し受けます。 (例は、こちら)
ということになります。
近い将来の構想としては、RPAツールの内製化 とAIモデリングの開発を予定しています。
しかし、それは、上記2)3)の代替えにしかならず、4)がAIモデリングに置き換わることはほぼない、という見解です。
ところで、「仕様から制約に落とし込むには?」と質問して、
https://schedule-nurse.blogspot.com/2024/09/blog-post_10.html
がソース表示されることを期待していたのですが、それらしい回答は得られませんでした。
明示的にソース追加してみたのですが、「ドメイン制限によりインポート出来ない」とのメッセージが出てインポートそのものが出来ないことが原因のようです。
具体的な操作ではなくて、こういう抽象度の高い質問に対する回答は、やはり資料を提供した方がよいので、折を見て、どこかのPDFに入れ込もうと思います。どこかに入れておきさえすれば、後は、NotebookLMが探してくれるので、探す手間がかかりません。
そういった地道な作業を繰り返し行うことで、回答品質が上がっていくはずです。
https://notebooklm.google.com/notebook/62d80db8-458e-4928-9a97-020357dc34c6
グーグルアカウントがあると、スケジュールナースに関する情報を閲覧することが出来ます。
スケジュールナースの機能と文書は膨大で、初心者から上級者まで、各々のレベルに応じた目的の情報を探すのは容易ではありません。しかし、これがあると情報を整理して見ることが出来ます。
次の動画で、男女の会話部分は、NOTEBOOKLMが作成したものです。サイトを読み込ませ、若干のプロンプト追加1回で、作成しました。動画部分は、男女の会話に合わせて、適当に私がコピペしたものです。
私が書いていないことも会話していますが むしろ核心をついている、ようにも見えて驚くばかりです。
例えば、勤務表作成サービスを、「伴走サービス」と言っていますが、本サイト・ブログを探しても、その言葉は一切使っていません。しかし、的を得ている言葉だと思いますしこれ以上に端的な表現も思いつきません。AIが書いた人間以上に本質を言葉で表現出来ている、本当に凄いことだと思います。
最近、お客さまとZOOMすることが多くて、結果、録画ZOOM容量がひっ迫していることが多いです。
個別にダウンロードをお願いしておりましたが、今後は、
■お客さまの方で必要がある場合にはダウンロードして頂く
■ダウンロードする場合は、1週間以内とする(一週間を過ぎたものは削除します)
ということにしたいと思います。よろしくお願いいたします。
保有する4件の特許のうち最初の2件、登録特許5807978と、5807980の特許が、11年目を迎えようとしています。長い年月が経ちましたが、アルゴリズム1は、改善を行いつつも基本的には当初の特許クレーム通りの実装で変わりがありません。
特許維持のため特許年金送付処理を行いました。
10年を超えると減免措置はなくなり特許維持に結構かかります。
手続きとしては、
1)納付番号を取得
2)Payeasyで納付
3)納付書送付
となります。期限までに納めないと権利が消失してしまいますが、現在は、Remindサービスがあることに気づき、登録しました。
これですと1カ月ないし2カ月前にメールが届くので、忘れる心配がありません。
CuoptとHighs最新版(1.11.0)でCUPDLPのWarmStartがサポートされたようです。実装を見ると、CuoptとHighs実装は、共にCOPT版のCUPDLPを基礎にしているものの同じではないようです。
Cuoptの方は、RMMを使っています。GPUを使ったボトルネックは、メインGPUメモリの帯域問題の他に、CPUとの通信速度が極めて遅いことがあります。特に小規模のLPの場合、一回の計算サイクルが短く、相対的にCPUとの通信速度がボトルネックになってしまいます。反対に、大規模LPでは、計算サイクルが長く相対的に問題にはなりえません。RMMを使えば小規模LP時の問題を回避できるのですが、残念ながらRMMは、Windowsではサポートされていません。恐らくはデバイスドライバ関連の問題だと思うので、多分、今後も変わることはないでしょう。。従い、Windowsでは、Cuopt版をそのまま使用することは出来ないと思います。この辺はサーバAPIとして使ってくれ、というスタンスかもしれません。また、SPMV改善は未だなされていないようです。
SPMV改善がなされれば、COPT版と明確な差異となる筈です。こちらは、メインGPUメモリの帯域問題を改善するので、大規模であればあるほど、その寄与度合いは上がるはずです。なので、NVIDAも本気で取り組むはずです。Mittleman Benchmarkに現れると思いますので、結果を待ちたいと思います。
とりあえず、HIGHSは、RMMの問題はないと思いますので、HIGHSをそのままポートしたいと思います。また、近い将来Cuopt版でSPMV改善がなされると思うのでそちらもWatchして行きたいと思います。
来るべきAIプロンプトによるモデリング実装のために、とりあえず勉強しなければ、
と思っていました。
久保先生のビデオ。面白いです。
NotebookLMを使って、男女の会話を自動生成したようです。
これ凄いですね。自然すぎて、ビックリです。
【1番使える‼️】無料のGoogle最強AI「NotebookLM」に日本語版音声Audio Overview機能が爆誕!徹底解説
スケジュールナースで、どうすれば良いか分からないときは、リソースを指定して、NotebookLM化しておくと、ヒントになると思います。スケジュールナースは、日々アップデートしているのであまり古い情報は見ないようにした方がよいでしょう。(ハルシネーション対策)
リソースの検索先を示しておきます。
本ブログ (スケジュールナースⅢ以降・2021年以降)
しかし、どんなに情報整理しても、分からない制約が存在する可能性はあります。ありきたりのよくある制約については、解る可能性がありますが、そうではない制約もあるかもしれません。その場合は、サポートをご活用ください。
モデリングは、私自身悩むこともまれではありません。看護師・介護士関連では、ほぼ定型的な処理ですので、悩むことはないのですが、新規の他業種プロジェクトでは、本当に悩むことがあります。お客さま自身が仕様を分かっていないことがあること、にも起因していると思いますが、それだけではなく、どういうモデリングをしたら上手くそしてメンテナンスが容易なプロジェクトになるかというのは、試行錯誤の部分が多々ある、ということでもあります。私自身・そしてお客さまもよく分かっていない、そうした問題は、依然として存在し、AIから最も遠い領域であると思います。
消えるプログラマ、残るソフトウェア開発者 と言われているように、お客さまとの開発作業が含まれている分野が最後は残ると思います。
最近のサポートにおいて、ZOOMは必須で、多いときは週に4回位こなします。ZOOMで、お客さまのご質問に答えたり、その場でご要求を実装したりします。実装するのは、私ではなくお客さまPCを共有して、私の指示を基にお客さまのスケジュールナース上で実装していきます。そうするのは時間がかかるのですが、少しでも覚えて頂くことを目的としてお客さまご自身で手を動かして頂くことを行っています。しかし、その場でやって頂くのは、定型処理であり、ありふれた制約であることが殆どです。
で、思ったことですが、それを私の代わりにAIにやらせるには、ちょっとハードルが高すぎるということです。そもそもGUIを直接に弄るのは難しい、そこでRPAツールを使えばどう?という発想が生まれてきます。
一方、何かスケジュールナース上で、看護研究で、勤務パターンによる急な欠勤者による影響度の調査、というテーマがあったとしましょう。この場合、パラメータを変えて大量の求解処理の必要があります。それをいちいち手で行うのはやってられない、RPAツールで出来ないか?という発想があると思います。
市井のツール、Power Automateを少し弄ってみたのですが、例えば特定の予定セルを操作するのは、とてもつもなく面倒で遅いということです。これは、外部からアプリの中身は分からないので、仕方がないということだと思います。
ならば、ツールに頼るのではなく、スケジュールナース自身で、スケジュールナースGUIを直接プログラミング言語で操作できるライブラリがあれば、その目的に叶うことになります。現状は、Pythonで制約処理と、ポスト処理を各々別プロセスで行わせていますが、それとは別に、Pythonで、GUIを操作できるようにしたいと思います。いわば、RPAツールの内製化です。
夢は、日本語で指示すると、例えば「遅番を分けて!」と指示すると遅番シフトを分けて、自動的に遅番⇒遅番集合にしてくれる、みたいな定型処理・ありきたりの処理の自動化を実現させることです。モデリング的発想だと、一気にモデル化しようとするから訳がわからなくなりますが、一つ一つの制約を実装・変更・追加・確認しながら組み込んで行ければ、人間と対話しながら人間の理解できるペースで実装できる、というところが、モデリングコンペティションのそれとは実際的に違います。
そのためには、やはりGUIとの橋渡し部分で、PythonでGUIを操れるようにする必要がある、ということです。
現状は、NSP問題の解決に注力していて余力がないのですが、来期以降取り組みたいテーマです。全てのNSP問題の解決は勿論ですが、市井のモデリングをAIと対話しながら出来るようになって、初めてスケジュールナースが完成する と思います。
Ans.
解を見ると最大夜勤回数設定の多い方が、夜勤間隔エラーを生じています。
以上です。
<Notes>
一般に、予定が入力されていない状態(ブランク予定)よりUBが良くなることはありません。制約を追加変更したときは、必ずブランク予定で求解し、UB==0を確認しましょう。
もしも、UB==0になっていなかったのなら、原因を解析しリーズナブルなエラーであるかどうかを見極めるようにしましょう。
Ans.
ペア制約AならばBで実装します。
仕様的には、
■今月の毎日について、夜勤専門スタッフが1名以上入りならば、遅出が3名以上
■今月の毎日について、夜勤専門スタッフが1名以上明けならば、早出が2名以上
となります。演算子「または」は、1名以上(≧1) と同じ意味になります。
以上で実装終了です。
<Notes>
この制約も、Default仕様に対する特殊ケースなので、矛盾しません。書き連ねることが出来ます。
ペア集合の不等式制約結果は、黄色・赤色マーキングが現在出来ません。要改善アイテムとしてリストしています。