マイクロソフトストア米国税金の支払い

 いつの間にか、米国税金の支払フォームが日本語で整備されていました。良くわからずに、今まで米国に30％取られていたのですが、W-8BENが日本語フォームで簡単に出来るようになってちゃんとしたので、その分は0％になるはずです。

Microsoftストア用のW-8BENの作成 #ストアアプリ - Qiita

マイクロソフトの分が15％あるので、今まで約半分取られていたことになります。マイクロソフトの場合、内訳明細も分かりませんし、お客さまがサブスク契約者かどうかも分かりません。

毎月マイクロソフトから外国送金があり、その都度、銀行からマネーロンダリングのチェックが入るのには閉口します。

列制約の目的は、「看護品質の向上」ではない

 列制約とは、縦の列のことです。

トップの日の看護品質をさらに向上させることではなく、最も低い日の看護品質を引き上げて、一定以上の看護品質を保つことが目的です。全ての日が、一定水準以上になるように平準化することが目的になります。平たく言うと、医療事故を防止すること、です。

一般に、列制約については、かなり厳密に運用されていると思います。人力解でも上のような制約エラーが多発する勤務表を見ることは少ないです。これは、管理項目として、実際に日々縦のラインをチェックしている結果であると思います。これに対して、行制約の方は、一般に緩く、頂いた仕様に対して結構なエラーが生じる傾向にあります。

＜上記赤ラインを必要以上に高くとったときの問題＞

下記は、人力では到底できないような複雑な列制約です。

これに対して、予定を元に戻して

求解させれば、スケジュールナース解が出ます。

ほぼ、列制約エラーは、消えました。（初日に出ているのは、先月の人力解の影響です）

人力解とスケジュールナース解とでの比較でみると、

人力解の目的関数値は、UB=877

スケジュールナース解の目的関数値は、UB=141

となっていて、5倍以上の差が生じています。特に、重篤なエラーが少なくなっています。

それなら問題ないじゃないか？と思われるかもしれませんが、実は問題があります。

二つの問題が生じます。

（１）解空間が必要以上に狭まる

（２）メンテナンスが困難になる

メンテナンスのない勤務表は存在しません。組織変更、人事異動、退職、妊娠・出産等により、月々に変更することが付きまといます。制約が複雑であればあるほど程、融通が利かないので、誰かが制約を変更しなければならない確率が高まります。

＜シンプルisベストがお勧め＞

結論としては、現時点で運用中のルールをそのまま仕様化することをお勧めします。往々にして願望を仕様化すると、複雑で高すぎる制約となります。

スケジュールナースを使いこなす上でも、バランス感覚は必要です。Githubにも色々な実践的プロジェクトファイル例を挙げています。どれも、上のような複雑な列制約はありませんので参考にしてください。

変則2交代勤務表レクチャノートコア勤務表解説編

変則2交代勤務表レクチャノート個別仕様編

変則2交代勤務表レクチャノートコア勤務表解説編付録

また、ペア禁止は、汎用的な手段で、経験的にかなり多くを記述しても問題が生じる可能性は低いです。参考にしてください。

仕様書は、願望ではなく、現在運用しているルールを書く

お客さまから仕様書を頂いて、制約に落としプロジェクトファイルを作成しました。この仕様書は、看護師勤務表ですが、今までにない複雑で精緻な仕様でした。特に列制約記述が複雑でした。

 

下は、お客さまの勤務表解（人力解）をスケジュールナースの予定として入力し求解した結果です。Excelデータを整列させ、コピペし、予定入力としています。この際、EXCELデータシート上の勤務表名をスケジュールナースのシフトラベルとしています。これを求解させると、人力解に対して仕様違反の箇所をマークさせることが出来ます。

Excelデータ

Excel上で、2段を１段に整列。空白部を日勤ラベル.に置換

スケジュールナース予定にコピペ

求解

上記の通り、大量のエラーが表示されています。項目ごとに様相は、異なります、全くエラーがない項目もあります。大量のエラーが表示されている項目は、恐らく管理していないと思われます。

看護師長は、縦の列、日々の看護師組み合わせをチェックしている筈です。頭の中にある、ある基準ライン以下であれば、その候補解を却下することによって、一定以上の看護品質を確保してと思います。大量にエラーが出ている項目については、その作業を行っていない、つまり品質確保項目ではない、ということではないでしょうか？　（逆に言えば、それがなくても品質は保てる）

できるだけ看護品質を高めたい、スケジュールナースなら何とかしてくれる？という気持ちの表れだと思いますが、仕様書は、願望を書くところではありません。

仕様書は、現実の今運用している、あるがままのルールを書く　ようにしてください。

願望仕様による弊害は、後述します。　

ブランク状態にもかかわらず、重み3＝土日祭日の日勤の平準化で1個出ている原因の解析

 

行制約で、１回以下のところ、土日祝で２回勤務しているスタッフが１名います。

このソフトエラーを解消するために、許容エラー数を０にしてこの行制約をハード制約化しました。その結果、土日勤務数のエラーは解消しましたが、代わりに、列制約の重篤エラーが発生してしまいました。

この制約を見ると、土日祝に２名づつ勤務すべきところ１名の箇所が１日生じています。この制約が要求しているコマ数は、１１月の場合１２日＝12x2で24コマになります。

ところが、休日出勤可能者は、下記ブランク部合計で24名になります。全員が1回だけ休日勤務すれば、上記24コマは、ギリギリ供給可能という計算にはなりますが、他の休日制約の影響を考えると、余裕がない状態と断じざるをえません。つまり、リソース余裕がないことが原因と考えられます。

＜まとめ＞

予定が入ると、上記は、予定ハード制約の影響が出てきて、真の原因を見つけ出すのが困難となるので、ブランク予定のうちに、原因を特定しておくことをお勧めします。

こうした問題の多くは、行制約と列制約の矛盾で、供給コマ数と消費コマ数の関係で説明できます。

行制約のソフトエラーの要因は、列制約コマ数が原因だった訳ですが、このように着目するソフト制約をハード制約化して、その結果何が浮かび上がってくるのか？を見るのが原因解析の一手法です。

Q.夜呼び出しは、最大週に1回（日～土）

 日～土を指定があります。まともに実装するのは面倒で、夜呼び出し間隔で1週間未満を禁止にする方が簡単です。この方式は、1週間未満のあらゆる2回を禁止するので、題意の（日～土）仕様を含んでいます。

このプロジェクトの場合は、呼び出しは、タスクなので、以下のように実装しています。

DDR5の相性問題

 DDR5は、4枚刺しは、推奨されていないようです。実際48GBメモリ2枚＋16GBメモリ2枚では、起動しませんでした。

DDR5の異サイズ4枚刺ししてみた #自作PC - Qiita

マザーボードのマニュアルにも同一ロット4枚刺しが記述されていたのですが、同一メーカ品の同一仕様4枚,4x48=192GBで、何とか動いてくれました。

しかし、やはり同じに動いているようではないようです。

これからAIをローカルで試してみたい方は、GPUはなしとしても、メインメモリは32GBでは不足すると思うので要注意です。

グラフコンパイルーメモリ問題

 メモリ問題から、全基数制約をコンパイルするのを諦めて、TIME制約とWEEKEND制約のみコンパイルします。

そうしたときに要するRoster1個あたりのメモリ所要量です。

                       コンパイルメモリ所要　　コンパイル時間　グラフメモリ所要量

instance23  48GB 　　　　　　　　　45分　　　　　　　0.7GB

instance24  140GB                                       2-3時間　　　　　　1.5GB

このために、メモリを32GB⇒48GB⇒96GB⇒192GBまでDDR5を増量しました。instance23で、グラフコンパイルだけで、丸2日、instance24で2週間程度かかります。

＜コンパイル時間問題＞

こんなに時間がかかるなら、別な方法を検討したくなりますが、実は、この問題は、クラウドを使えば現在でも解決できます。というのは、スタッフ毎に独立してコンパイルが可能だからです。リソース無尽蔵のクラウド資源を使えば、並列にコンパイル可能です。つまり、リソースさえ気にしなければ、全スタッフを2時間でコンパイルは出来ます。

＜コンパイルメモリ問題＞

グラフのコンパイルに192GBメモリが必要です。AIに10年後の予測をしてもらったところ、AI需要等により64-256GBになるとのことでした。

よって、10年後では、標準的なPCで十分に対処可能になると予測します。

＜グラフメモリ問題＞

instance24は、150staffなので、平均1.5GBだとすると1.5*150=225GB > 192GB で足りません。

Diskに退避した場合、現在の高速SSD+対応ボードを使うと14GB/secの転送レートで、メモリ転送レートと比べて、そんなに遅くはありません。以前のHDDを使った転送レートと比べれば雲泥の差です。それでもGraph処理レートよりもDisk転送レートの方が遅い可能性が高いので、できるだけメモリ上で圧縮処理した方が得策とみます。

＜グラフ縮約＞

一度LBが算出されれば、後は、厳密解に拘る必要はありません。つまりLB算出までは、Fine、それ以降は、Coarseで制御します。グラフ処理速度は、グラフ規模で一意に決まるので、グラフを極小化することで、処理速度を向上させます。

まとめると、

LB算出までは、厳密解を得るために、多少時間がかかってもグラフの縮約は用いません。

LB算出以降は、実用的なBranch＆Bound速度とするために、グラフの縮約を用いて高速化を図ります。

以上の検討により,

■instance24のコンパイルに192GBメモリ48x4

■必要ならば、メモリ上でグラフ圧縮処理

■LB算出後のグラフ縮約

を行うこととします。

さすれば、グラフメモリ問題は解決できる、と結論します。

とりあえず、instance24のグラフメモリをDISKに保存中です。この予備処理に2週間程度かかる予定です。一旦グラフメモリを保存することが出来たならば、後はそれを用いてさらにアルゴリズムの検討を行うことが出来ます。HIGHSの新IPMは、GITHUBを見るとかなり期待出来る速度となるようです。これにより、課題要素は、それぞれクリアできるのではないか？と期待されます。