2014年10月10日金曜日

意見書・補正書 提出

10月8日、オンラインで提出しました。

座して、結果を待ちます。

来年のソルバ競技会ためのFeasitility Studyを行っています。二つの異なるアイデアがあるので、それの検証準備を行っています。11月中に有る程度効果を確認しないと、競技会は毎年4月にエントリーなので間に合いません。

2014年10月4日土曜日

意見書・補正書の作成方法

  1. 禁反言の原則
  2. 一致->似通った (自白しない)
  3. WORD買った方がよい(標準) 
  4.  
表:html Tableは出願ソフトでエラーになるので、イメージで作成するしかない。しかし、
WORD表ー>PDFでやると出願ソフトの印刷イメージは、圧縮されすぎ判読不可になってしまう。
なので、表だけ、10.5ポイントから14ポイント且つ太字でとして、PDF->キャプチャソフトでCOPY貼り付けという面倒な手順を踏まなければならない。

2014年9月24日水曜日

特許作成上の留意点2

今日も、弁理士さんと打ち合わせ。次回9月30日(火曜)

明細書: 抽象ー中間ー具体 色々なレベルで書くことにより対応が取りやすい。クレームは勿論重要ではあるけれども、それにも増して明細書の文章が重要。図面やフローチャートは極端に言えば、なしでもよい。裏返せば、それほどに明細書に書く文章が重要であり、図面なしでも理解してもらえる文章としなければならない。

1)一回定義したものは、前記
2)同じ前記になってしまうので、手段ごとに名前をつける。または、第一手段、第二手段等
3)ブロック図が第一に必要
4)内的付加と外的付加(いろいろな要素を限定すればするほど、
従来技術との差異が出て進歩性が認められ易くなる反面、実は、特許権の権利範囲が狭くなってくる) 難しい..
5)半角は好まれない全部全角にする
6)括弧がきは、紛らわしいので使わない




以上


2014年9月1日月曜日

特許作成の留意点

新しく特許を書く場合の留意点

  1. 拒絶理由通知書が来ることを前提
  2. 先に紹介した本を読んでおくこと
  3. 国語が大事
  4. なにより、どの引用例にもない本願発明だけの要件とそれによる効果が大事
  5. 頼りになる弁理士さんに相談
以上が、今回学んだことです。

2014年8月29日金曜日

拒絶理由通知書を受領

先週、審査請求していた特許の拒絶理由通知書を頂きました。「拒絶」というのは、愛を告白して、拒絶されたような心境です。嘆いていても始まらないので、とりあえず、本を購入しました。


一人でできる特許出願、手続き補正書の書き方
新・拒絶理由通知との対話

です。どちらの本も有益な情報が書いてありました。なるほど、「どの引用例にもない本願出願だけの要件とそれによる効果」が一番重要なのですね。

しかしながら、やはりソフトウェア特許で専門性が高い個別案件は、個人でやるのもここら辺が限界です。なので地元仙台で、頼りになる弁理士さんを探して相談にのってもらっています。

とりあえず、60日以内に意見書と、手続き補正書を出さないとアウトです。
To be continued...

2014年8月11日月曜日

運用中の制約追加

勤務表の設定というのは、一度設定したらそれで終りというものではありません。
刻々と変化する状況に応じて、変えていかなければなりません。

そういった状況で力を発揮するのが行列制約です。~ならば、~でないなら、~である。~でない、等、日本語で制約のプログラムが可能になっています。新しいのは、それをGUIだけで、書けることです。今月だけの制約を書くのでしたら、これ以上強力なGUIは、ちょっとないのではないかと思います。

http://www.nurse-scheduling-software.com/tutorial/settings_of_monthly_changes.htm


2014年7月18日金曜日

正循環勤務表の検討

少し整理してみました。この辺、結構重要な問題だと思いますが、勤務表作成者の側からの報告が殆どないので、具体パターンについて検証してみました。
http://www.nurse-scheduling-software.com/tutorial/investigation_of_regular_rotation.htm

未だ書きかけですが、時々Updateして行こうとおもいます。

2014年6月18日水曜日

Giant sudoku solver by nurse rostering software

I would like to introduce my nurse rostering solver "schedule-nurse".

Sudoku is NP-Complete
Nurse Scheduling Problem is NP-Hard.
Both can be solved by constraint programming.
You don't need to write program on how to solve, you only need to write constraint for the problem.
Nurse rostering software "schedule-nurse" is fast enough to solve huge blank sudoku, though it is not exclusive sudoku solver. It is free software, you can develop your own pencil game. From the point of another view,it  may be the tool to get answer(SAT/UNSAT) for other fields of  problem.It's just fun...


Is there a limit or maximum size to how big can be made?
That is the natural question. Crrent software can generate up to 36x36 sudoku. But the latest study shows 81x81 sudoku is possible within reasonable time. As for 100x100 sudoku, I can say it's very hard and challenging problem. To the best of my knowledge, I don't know such a sudoku generator.

2014年6月13日金曜日

プレゼンテーション

KingSoftというPowerPoint互換ソフトで作成しました。

http://www.nurse-scheduling-software.com/tutorial/schedule_nurse_presentation.ppt

動画にする機能はないのですが、細かい点を除けばほぼ互換(PowerPoint2003)が
とれています。

しょうがないので、ビデオでキャプチャすることにしました。

2014年6月12日木曜日

勤務シフト表自動生成ソフトの評価

とりあえず、VirtualBox上で、評価してみました。
結果はこちらです。

http://www.nurse-scheduling-software.com/tutorial/test_bench2.htm

強く思ったのは、もし低レベルのソフトでシフト表を作成すると影響を最も被るのは、スタッフナースになるということ。希望の休みが取れなかったり、理不尽なシフトを強いられる可能性が高くなる、人の生活がかかっているのに...こんなにひどいとは思わなかったのでちょっとショックを受けました。

早くメジャーに上がらなくては!

2014年6月11日水曜日

スケジューリングソフトの評価

今まで、特許を書くことを第一優先にしていたので、他のソフトを評価する余裕がありませんでした。で、アピールポイントは何か?と考えていたら、やはり他と比較してみるのがよろしかろうという結論に達しました。

評価環境を整えるために、Virtual環境を構築しました。Windowsは、Microsoftがよかろうと思いきや、VirtualPCは、WindowsInstall途中でErrorになってしまい立ち上げに失敗。代わりにVirtualBoxでやってみると、問題なくInstallできました。任意時点のSNAPSHOTを取れるので、いつでも前の状態に戻せます。使い勝手もVirtualBOXの方がよい感じです。

で、肝心の評価状況ですが、

あ社:起動せず。32Bit版・64Bit版でトライも致命的エラーで立ち上がりませんでした。
いソフト:ほぼよい感じで動きます。評価できそう。エラーチェックが甘いがソルバは真面目に作ってありそう。
うソフト:ひどいです。よくこれでお金を頂けるなあと感心。評価データを採取するには、制約を大分緩めなければならない。

なるほど、こういうソフトばっかりだから、看護師長から見ると、ソフトは...になるのですね。

2014年6月6日金曜日

36x36数独ソルバー

→Update記事です。

内部の変数と式数です。
 100715 472635

この数独パズルは、平均的なナーススケジューリング問題より規模が大きいです。
さすがに、コンパイルが重くなりまして、10解出力で18秒かかっています。
36x36のソルバというと、殆どないと思います。さらにブランク状態から連続して解を求める例は、見渡したところないので、速度は世界一と言ってよいと思います。なお、解析的に答えを出す方法は、

http://en.wikipedia.org/wiki/Sudoku_solving_algorithms
にBlank Sudoku gridsとして載っています。

数独は、通常バックトラッキングで、穴埋め問題を解きますが、全部がブランクだと、この方法では、規模が大きいときに破綻してしまいます。そこで、なんらかの探索方法が必要になってきます。

関連する文献としては、数理計画として解く方法、
http://www.is.titech.ac.jp/~okamoto/PDF/2007/puzzleip.pdf

SATにエンコードする方法
https://www.ipsj-kyushu.jp/page/ronbun/hinokuni/1002/C-5/C-5-4.pdf

SMTソルバを使う方法
http://bach.istc.kobe-u.ac.jp/sugar/puzzles/sugar-puzzles.pdf

スケジュールナースでは、9x9から出発して、16x16、25x25、そして36x36まで解きました。

->
2017RAMP講演でMIP Solver CPLEXとの比較について触れました。100x100まで解きました。







36シフトの入力画面です。

10解のうちのひとつです。

ソルバの検証は、Excelに解を貼り付けてブロック内の和でチェックします。
GUIが対応していないので、現在は無理ですが、81x81までは行けることが分かっています。それ以上どこまで行けるかについて、検討中です。
->時間はかかりますが、100x100までは、行けることを確認しました。
In conclusion, we can say our solver solves 100x100 sudoku matrix finally.Jun.24.2015

2014年6月5日木曜日

25x25 数独ソルバ

25x25数独は、変数数、式数で以下の通りとなりました。
32607 154556
これぐらいだと、ナーススケジューリング問題の典型的な規模になります。
さすがに、解の出力速度は、遅くなり0.8 sec/1解/Thread/となりましたが
ブランクの数独を連続的に解くスピードは、世界最高の可能性があります。
 
シフトを25個定義しています。
解を10個出力しています。


 


Excelに解を貼り付けてソルバを検証しています。






 



2014年6月4日水曜日

16x16 数独ソルバ

もコーディングしてみました。Version123までは、シフトの数は12まででしたので、16まで拡張する必要があり、GUIとソルバもこれに対応してみました。
シフトの定義です。内部シンボルはA,B,C,,,ラベルは1,2,3...と定義しています。
9x9数独と同様に16x16数独ソルバは、ブランク数独に対して0.2sec/Thread の速度で、別解を出力することができます。この速度に勝る数独専用ソルバはあるでしょうか?

ソルバが出力した解です。10解を出力しています。
 
Excelでソルバの検証、解をExcelに貼り付けて、数独ブロックの和が136になることを確認しています。


内部の変数と式数は、
8014 38709
でした。この規模の数独だと、未だ通常のナーススケジューリング問題の方が数倍規模が大きいです。

2014年5月31日土曜日

プリセプタ、プリセプティ - ソフト制約を使いこなす

プリセプタ、プリセプティの制約は、禁止に比べると厳しいです。組み合わせ禁止は、その人以外を選択しなければよいので、選択の余地は大きいのですが、その人以外駄目になると選択の自由度がありません。そのために全夜勤を満たすのはとても難しいのです。でも、

1)できるだけ、プリセプタ、プリセプティの関係を満たしたい
2)何が何でも、プリセプタ、プリセプティの関係を満たしたい

1)は、ソフト制約にすれば実現できます。
2)2)は、予定制約をソフト制約とし、プリセプタプリセプティの制約レベルをそれより高くするか、あるいは、ハード制約とすれば実現できます。

あるICUからデータをお借りして、実際にやってみます。(スタッフ名は匿名です。)

最初に予定入力の画面です。かなり予定が入っていますね。果たして解はあるでしょうか?





プリセプタプリセプティは、問題になることが予想されるので、ソフト制約にしてあります。
下のようにソフト制約レベル4を設定しています。

 













下の状態で、求解してみます。







 
 

やはり、解はありませんでした。行制約4で、問題があると言っています。








ソフト制約4は、プリセプタプリセプティです。
一人あたりの許容エラーを下のように1から2に増やして再トライしてみます。



今度は解がありました。やはりプリセプタプリセプティがネックだったのですね。
数の下のペインで○がプリセプタプリセプティが成功したところ、xが3箇所ありますが失敗したところです。
この3箇所は、予定入力を全て満足する最小の数です。つまり、予定入力を満足するためには、プリセプタプリセプティエラーは、最小3個必要となり、2個以下では、予定は満足しないということです。この場合、async_timeがでていないので、解は厳密解で、物理的に入らないということです。逆に言うと、入らない中でもスケジュールナースは、頑張って詰めこんで、3個のエラーで済ますことができた、ということなのです。
上記1)の命題である、「できるだけプリセプタプリセプティの関係を満足させる」は、以上で実現できました。


 
次に、何がなんでもプリセプタプリセプティの関係を満足させる方法の説明です。
上で見たように、プリセプタプリセプティと、予定とを全て満足させる方法はありません。(物理的に入らない)
そこで、予定入力のソフト制約レベル5よりも、プリセプタプリセプティの制約レベルを高くします。
下のように、ソフト制約レベルを6にします。

このようにすれば、予定入力よりも制約レベルが高くなるので、満足するでしょう。
下はこのときの求解条件です。
行ソフト制約6がプリセプタプリセプティのソフト制約です。何が何でも実現なので、許容エラーは0に設定します。
下がこの条件下での解です。プリセプタプリセプティは、全て○になりました。代わりに予定の変更箇所が3箇所出ています。3箇所は、画像反転しています。この3箇所は、プリセプタプリセプティを満足する、最小の値でこれより小さい値は存在しません。(物理的にはいらない)。また、求解数は、10回に設定していますが、2解しかでていません。これは、求解条件で、同じ予定変更の組み合わせを禁止設定しているからです。(ただし、最初の2解は同じことがあります。)つまり、プリセプタプリセプティを満足する予定変更の個数は、最小3個で、その組み合わせは、提示してあるものが全てになります

 上の二つの解を出すのに、要した時間は、2分くらいです。
 
この二つの結果を見てどちらを選ぶか、あるいは、さらに条件を振ってみるかは、評価者たる人間でしか行えないことです。
この事例は、ソフト制約を使いこなす高度な例ではありますが、いずれにしても求解条件とソフト制約レベルをいじっているだけなので、慣れれば使いこなせるようになると思います。「守りの勤務シフト表から攻めの勤務シフト表へ」 パラダイムシフトしてみませんか?

2014年5月30日金曜日

数独とシフト勤務表の等価性

下は、サンプルフォルダに入っている数独プロジェクトです。(実際に難問が入っていて解く様子が見られます。)この問題は、フィンランドの数学者が3ヶ月かかって作った世界一難しい問題といわれているその世界では、有名な問題です。数独の名人でも、数日かかるとされているこの問題をスケジュールナースは、1秒もかからずに解く事ができます。
勤務表を解くアルゴリズムでも説明していますが、勤務表の込み入った拘束条件を満たす解の解法というのは、方程式を解くようなものではなく、基本的には探索によるものです。その意味で数独のパズルとナーススケジューリングというのは、同じ種類の問題なのです。ただ、皆さんの抱えているナーススケジューリング問題というのは、実はこの数独を解く難しさからすると2桁から3桁程度難しいです。

ここで難しいという定義は、制約を式に置き換えたときの規模を言います。下記は、スケジュールナースのソルバが示す内部の状況です。

                                    変数 式の数
数独             738    3249
池上2ShiftData    25542  114302
池上3ShiftData1.1 67512  325062


必ずしも、解く時間と上記の規模は比例関係に有る訳ではないのですが、ある程度の相関関係が
知られており、問題の規模でいうと、2桁程度違うことが分かります。皆さんが普段やられている規模は、池上ShiftData2-3位の規模です。ですから、数独より2桁難しいパズルを毎月解いているというのは、あながち間違っていません。

数独は、全部ブランクのときの値です。それは、世界一難しい問題ではないだろう?という疑問があるかもしれませんが、全部ブランクが、一番難しいのです。というのは、論理的には、解けなくて仮定を置かないと解けなくなるからです。数独専用のソルバでやってみると、この事が実感できる筈です。(やった事はありません。)

スケジュールナースでは、このくらいの小さい規模ではマルチスレッドをオフにしているのですが、ブランク数独を0.2sec/個(Core i5 3GHz)位で解き続けられます。はたして、スケジュールナースに勝てる専用ソルバはあるでしょうか?

難しいナーススケジューリング問題に対して、まだ、紙と鉛筆、あるいはExcelで立ち向かおうとする人には、名人の数日と一秒の探索能力の差を思い起こして欲しいな、と思います。



2014年5月29日木曜日

世界一難しい数独を解いてみる

勤務表ソフト スケジュールナースで解いてみました。

動画はこちら


Version123のプロジェクトサンプルフォルダに入っているので、遊んでみてください。

2014年5月25日日曜日

勤務シフトソフトのスタンダード化

スケジュールナースは、日本の勤務シフト自動配置ソフト、defact standard を目指しています。



今週から、マニュアル・プレゼン動画・雑誌投稿原稿を作っていこうと思います。その前に勤務シフトソフトのあるべき姿を下記にまとめてみました。

1. 物理限界まで探索する能力
2.一つの勤務表から、複数の勤務シフト表案へ
3.配置できない箇所を指摘するのではなく、どうしたら配置できるかを提示する
いずれも、スケジュールナースのユニークなところです。

つづく

2014年5月22日木曜日

特許出願手続き

出願には、出願手数料を支払う必要があります。支払い手続きは、

1)出願ソフトを起動
2)補助タブで、納付番号取得(オンライン)
3)2)で得た納付番号をPayEasyで納める(オンライン) 特許出願は15000円です。
4)2)で得た納付番号を出願書類の電子現金納付の箇所に書く


1.出願

 これをオンラインで特許庁に送ります。送るのは、出願ソフトで、出願タブー>送信ファイル
簡単願書作成ソフトで作成したHTMLファイルを選ぶと、送信形式のファイルにしてくるようです。
この際、モノクロに変換されます。白黒だけで作成していても、形式が256色になっているとWarningがでます。注意するのは、簡単願書作成で問題なかった図も、送信形式の図をチェックすると解像度が大分落ちていることです。(今時、無理して圧縮をかける必要は無いはずですが...)
しかも、プリンタに印刷してみないと実際の図の具合がどうなっているか分からないので、プリンタによるチェックは必須です。

無事にオンラインで送ると出願番号が割り振られるので、その出願番号で、

 2.早期審査に関する事情説明書
 3.出願審査請求書

を書きます。特許明細書本体と上記は、いずれも、簡単願書作成ソフトで作成します。

これらは、同じ出願ソフトの出願タブで同じように行います。

それとは、別に以下を送りました。

オフライン(特許庁に郵送)
  1. 審査料金減免申請書
  2. 非課税証明書
 以上です。

2014年5月20日火曜日

特許2

現在、2通目の特許申請を書いています。

前回の特許は、ソルバの高速化に関するものでしたが、今回は、本質的に勤務表作成に関するものです。

ところで、本特許の申請前に製品にその機能を実装し、マニュアルに書くことはできません。というのは、一旦世の中にでてしまうと「公知の技術」になってしまって、特許性が認められなくなってしまうのです。それが、自分の書いたものであるならよいのではないか?というのは通りません。一部例外はありますが、特許に関するものは、申請前にWebに載せることは禁物です。

そういう訳で、現在、Tutorial、中途半端になっているのはそういう事情からです。申し訳ありません。

2014年4月25日金曜日

休日勤務の出勤回数を平等に

休日出勤の回数は、不平等感の強いもののひとつですが、これも制約を一つ追加すれば、解決可能です。

最初は制約なしでの結果です。休日出勤回数が3回から7回とばらついています。
7回の人から見ると、「なぜ私だけ..」 になってしまいます。

 そこで制約を追加します。kというのは、出勤勤務の集合で、
k=S | J | N
になっています。Sは、深、Jは準、Nは日勤です。休日のkの数を制限すれば、平等化が実現できます。

 下は、殆どなにも制約していないに等しいです。(最初の図を出力するために使用)
 4<=k<=6 にして制約しています。
 確かに休日出勤数は、4から6日の間に収まりました。(ちなみに5日以下の設定解がありませんでした。)
看護師スケジューリングソフト、スケジュールナースで求解時間は、3秒でした。

2014年4月18日金曜日

勤務表 人間とコンピュータの違い


 
実際にスケジュールナースをガイドしながらやってもらうと、絶対にできない制約(物理的に実現不能な制約)をコンピュータにやらせようとして「解がない!」、 バグではないか?と疑いの眼差しで眼を向けられることがあります。この制約で、前月もできているのだから、出来るはずだ、というのが妻の主張です。前月は、妻ではない別な看護師長が書いた勤務表です。それならばということで、前月の人間が作った勤務表を見ると、これが全然制約を守れていない訳です。勤務表を作ったときは、ルールがあるのだと思いますが、実際に作る段では、そのルールを守ることが出来なくて、部分的に捻じ曲げて(無視して)作っているのではないでしょうか? コンピュータに制約を入力すると、コンピュータは、勝手に捻じ曲げて緩めてはくれませんので、配置できない、解がない、エラーになってしまう訳です。

 大抵の場合、手入力した勤務表実績を入力しそれに対して解を求めると、(つまり初期入力で埋まった状態なので、解は一個以上、一個以下になるはずです。)解がありません と報告すると思います。 実はそれは看護師長さん自身が考えて手入力されたものは、伺ったルールからは、部分的に外れてしまっていることが多いのです。職場のルール、自分の中でのローカルルールをきちんと紙に書いてそれを一個のエラーもなく守る、というのはそれだけで、大変な事だという事でしょう。

コンピュータは、その意味で融通が利かないとも言えるかもしれません。でも、ちょっと立ち止まって、もっと良い制約はないか?と考えて欲しいのです。スケジュールナース的に言えば、勤務表づくりの大半は、制約設計です。

私は、コンピュータを使った勤務表の最大のアドバンテージは何かと、ずっと考えてきたのですが、最近になって、少し見えてきました。それは、複数の違った見方が出来る事です。紙と鉛筆で作れば、平均11時間かかってできる勤務表は1個です。 それが、スケジュールナースでは、ほぼ、看護師スタッフの入力時間だけで済みます。でもそれだけでは、例えば1/11にしかなりません。
例えば、今月は、リーダ養成のために、ここを少し空けてみたら、配置できるか?とか、この日の日勤を少し増やせないか?とか、その月に限っても色々試してみたいパターンが本当はあるのではないでしょうか?本当は、試して、良さそうだったらそっちを使いたいけれども、苦労して作った勤務表をもう一回やる気にはならない、というのが本当の所ではないでしょうか?少なくとも、その要求に対する能力をスケジュールナースは有しています。

11時間後のたった一個の勤務表と、いくつかの異なる見方をした勤務表候補。前者は選択の余地はありません。後者は、看護師長のどちらが理想に近いかという、評価して選ぶという所に大きな違いがあります。

しかし、いくつかの試したパターンの結果を評価できるのは、人間たる看護師長だけです。そのトレードオフのバランスを決めるのも人間たる看護師長だけです。コンピュータでは、そういう評価はできません。コンピュータは、制約に対して答えを出すことしかできません。


そのためには、何が必要か?制約をその場で書き換えて、すぐに答え出せるソフトの他に、制約をその場で書けるスキルが必要になります。現実の現場の勤務表を見ていると、実は、同じ制約の月の勤務表というのは、あまりなくて、なにかしら変更があるものです。フレームワークの勤務表はあったとして、少しの変更をその場で書けるスキルは、やはり必要だなと感じています。とりあえず、基本的なソフトの使い方は、Skypeによるサポートでなんとかなるとは思いますが、制約そのものを追加変更するスキルの向上は、難しいと感じています。なにかよい手立てはないでしょうか?


2014年4月17日木曜日

祝日の平準化

5月は、祝日が多いので、例えば、看護師スタッフのある人の祝日数が0で、ある人が3日祝日だったりすると、不公平ですね。看護師スタッフから文句が出てこないようにするために、看護師長は日夜奮闘されていると思いますが、鉛筆と紙と消しゴムでしこしこやるよりも、制約をひとつ追加しよう!、と言いたいです。

祝日のシフトをHとして、祝日一回以上に制約します。
 結果です。祝日が3回の看護師スタッフが2人いますね。
不公平だと感じる人がいるかもしれません。
 1人以上2人とすれば、
 祝日3回のスタッフはいなくなります。
看護師勤務表作成ソフト スケジュールナースで求解時間は4秒でした。

2014年4月16日水曜日

特許の審査請求

特許というのは、出願だけでは特許になりません。特許請求を行って、特許庁の審査官が審査をして特許性を認めて初めて特許として認められる訳ですね。スケジュールナースは、特許出願は済ですが、審査請求はしていませんでした。通常は、1年半位、様子見の期間があるのですが、要件を満たすと早期審査請求という技が使えます。そこで、今日、特許の審査請求手続きを行いました。出願もそうですが、審査請求も特許庁のオンラインで行います。オンラインは、出願ソフトというのが、特許庁からダウンロードできます。また、特許作成は、簡単願書作成というソフトがあり、作成上不備を指摘してくれたりします。簡単願書作成で作成した願書を出願ソフトで、特許庁にオンラインで送るのですが、これが面倒でした。住基ICカードで認証しながらやらないといけないのです。多分、出願ソフトと認証ソフトは連動しているのだと思いますが、認証ソフトがハングしたりして結構、問題が多かったです。ともあれ、なんとか提出しました。

提出物は、

オンライン
  1. 早期審査に関する事情説明書
  2. 出願審査請求書
オフライン(特許庁に郵送)
  1. 審査料金減免申請書
  2. 特許料減免申請書
  3. 非課税証明書

でした。

ー>上記オフラインは間違っていました。
特許料減免申請書は特許査定になってから申請してください。





2014年4月15日火曜日

会議の制約

副看護師長や主任との打ち合わせは、どのようにしていますか? この日にする、と決めてしまうよりも、スケジュールソフトに任せた方が良いと思います。なぜなら、解の探索空間の減少を最小に留める効果が期待できるからです。全てのスケジューリングソフトは、解を探索しますが、探索空間はできるだけ大きいほうが良い解を得られるチャンスが大きくなるのです。

まず、会議の要件について考えてみます。

会議の要件

  1. 会議資格者(スタッフプロパティで設定する。副看護師長等)だけが会議に参加する
  2. 会議は日勤時に行う
  3. 会議は、全会議資格者が揃ってはじめて開催可能
  4. 会議が長引く可能性があるので深夜入り(次の勤務が深夜)は入れない
  5. その月の会議回数は、複数回があり得る
次に、この条件を、コンピュータに解る言葉、制約に置き換えます。

  1. "会"というシフトを設ける。性質は日勤に準じる
  2. その月の会議回数はマクロ(今月の会議回数)で指定する
  3. 資格者はスタッフプロパティで設定
  4. 会議の後は深夜を禁止する
  5. 資格者は、今月の会議回数、過不足なく会議を行う
  6. "資格者が揃って"  ー>ペア強制を使う

という感じでプログラムしていきます。
”今月の会議数”というマクロを設定しています。(次月以降はここだけを変えればよい。)

会議というシフト変数を作ります。名前をC、ラベルを”会”としています。

会議に参加する人プロパティリンクを変更します。 (青色部)
 Day制約は、祝日でも、休診日でもない日にCを追加します。
会議のパターンを定義(青部)しています。

 日勤の定義をmとしています。m=N | C です。Nは、今までの日勤定義でしたが、
一般化した日勤をmとして、mに関する制約にしています。

 
 
今月の会議数を2に設定したときに得られた解です。
 
 どこまで確保可能かをやってみました。この例の場合11日まで可能でした。
12日に設定するとTimeout(20秒)で見つかりませんでした。

スケジューリングソフト スケジュールナースでこの求解に109秒かかりました。













2014年4月14日月曜日

年休消化の制約

5月は31日あり、かつ休みが多いので年休消化するには良い月です。そこで、年休消化する制約を考えてみましょう。スタッフがある程度取ってくれた方が後の月の勤務計画表の作成が楽という動機がブラックな制約ですが、最終的にはそれが皆の幸せにつながると信じてやる事にしましょう。

年休というのは、通常勤務希望として初期設定されますが、今回の年休消化は、他の制約を優先し満たして上で取得可能なら取得する という制約になります。つまり、通常の年休とは、性質の異なる年休です。通常の年休は、静的に決まっているのに対して、初期設定としては決まっていない動的に変わる年休、スケジュールする年休なので、シフトのラベルを変える必要があるということが分かります。

このスケジュールする年休のラベルを”す”と現すことにします。左がそのシフトの設定になります。制約内での名前を小文字のh、ラベルを”す”にします。休みに関係するグループxの仲間としてhも加えます。












下は

下は上の制約を入れる前の結果です。






今月の年休数というマクロを作成し1に設定して求解すると
問題なく求まります。この段階ではエラー0(ie.全看護師スタッフが年休を取得可能)なので、3秒で求まりました。
 
 
次に、今月の年休数を2に設定すると、下のような結果になりました。ご覧のように、全スタッフが年休を取得できている訳ではありません。その理由は、日勤者数にあります。スタッフに年休を与えるということは、その分日勤スタッフ数が減少します。際限なく年休を与えるができないのは、日勤者数制約が有るためです。この場合12人以上の制約を与えています。下のペインを見ると全日12人になっています。つまり、これ以上年休を与える余裕がないところまでスケジュールナースは頑張ったという事です。
(一番最初の日勤者数の違いを比較してみるとよく分かると思います。)
 
この制約をハード制約とすると「解がありません」になりますが、ソフト制約を指定することによって、エラー数を最小化するところまで自動的に求めてくれます。今回の求解時間は、看護師勤務表作成ソフトスケジュールナースで、79秒でした。

2014年4月10日木曜日

5月の連休の設定

5月の連休は、祝日と公休の扱いが暦通りではないのでその対処方法を記します。

3交代勤務者
5月3日祝
5月4日公
5月5日祝
5月6日祝

3交代勤務者でない人
5月3日公
5月4日公
5月5日祝
5月6日祝

夜勤が有る人とない人で祝日の設定が異なる場合がありますが次のようにするとよいでしょう。

まず、下のようにスケジュール開始日を5月1日にします。
 
 
次の曜日の定義を開きます。最初は下のようになっているはずです。
 
 
祝の定義を下のように変更しましょう。”祝”は、3交代用用のラベル流用します。
変更する部分は、
・祝の行 変更
・振り替え休日の行 クリア
・夜勤のない人の行 追加
です。




それから、夜勤のない人用の祝を定義します。”し”とすることにして、上のお達しの定義を入れます。”し”の属性は、ユーザ絶対月日 にします。(この属性の意味は、今月だけ意味を持つという意味です。来月になると忘れます。)

次にパターンの定義の行制約で夜勤なしの人は、最初次のようになっています。

この意味は、

もしも、祝だったら、H 勤務 (祝)
もしも、休診日だったら Y 勤務(公)
その他は、 N 勤務(日勤)

という定義になっています。今、夜勤のない人の祝日は、”し”と定義したので、
下のように直します。

以上で、定義完了です。
 


2014年4月2日水曜日

連続休みを2回以上、連続休み間隔は2週間程度で平準化 その3

問題は、休み間隔を2週間程度とする、という仕様です。
言い換えると、短すぎても駄目だし、長すぎてきも駄目ということです。
ただ、このままでは、漠然しすぎていますね。

この実装は難しいですが、
以下を頑張って読んでいただくと、制約が書けるようになります。

もう少し具体的に考えるために、1ヶ月を4区間で、区切って考えます。

1 2 3 4
休  休       -Good!
    休   休-Good!

もし、第1週目が、休みのときは、第3週目が休みであれば、仕様にマッチします。
同様に、第2週目が、休みのときは、第4週目が休みであればよいですね。
以上が、仕様上許される全てのパターンで、これ以外の休みパターン、

1 2 3 4
休       休 -NG Too Long
休休     -NG  Too Short
    休休         -NG   Too Short
   休休     -NG   Too Short
   
  
は、すべて不可になります。
そうすると、どういう制約にすればよいでしょうか?

パターン1:1週目に一回かつ3週目に一回
パターン2: 2週目に一回かつ4週目に一回

制約: パターン1  OR  パターン2

という制約を書けばよいことになります。そうすれば、パターン1または、パターン2どちらか、
または、両方の制約が満足されますから、約2週間間隔で2回以上のの休みが取れることになります。

正確には、約2週間の最小は、1週間で、最大は、3週間になりますが、あまり範囲を狭くしすぎると
「解がない」可能性が高まるので、とりあえず、この制約でやってみましょう。

<続く>


  
 

2014年3月31日月曜日

連続休みを2回以上、連続休み間隔は2週間程度で平準化 その2

下は、連続休み2回以上の制約です。
パターンのところが新しいです。ひとつひとつ見ていきます。
まず、$S関数ですが、パターンの加算に関する制約です。
$S(min, max, type, pattern...)
これ自体は、今までの最大、最小と同じ意味で、
type 0:  min<= X <=max
type 1:  X>=min
type 2:             X<=max

という制約になります。上の
$S(2,0,1..)
は、最小2以上 という制約になります。

$P(n, パターン)
nは、パターン開始日n のnです。
$P(1, xx)は、パターン開始日1のところの日をxのスタートとする
という意味です。ここでは、スケジュール開始日の第一日目がxで
第2日目もxであるならマッチして、$P(1,xx)の結果は1を返します。
マッチしなければ、0を返します。

$P(2,!xxx)は、パターン開始日2のところの日をxのスタートとするという
意味になります。パターン開始日2がスケジュール日(1月1日から1月29)の間
マッチするする部分を$Sで加算することになります。

まとめると、
最初の日のxxと、最初の日から1月29日まで!xxxにマッチする部分を
加算して、2以上という制約になります。

面倒ですが、「連続休みを2回以上」という制約にしたい場合は、
この行をコピペすればよいです。

勿論、xの定義、第一日の定義、スケジュール日の定義は各々の環境で違ってくるでしょうが、
単に置き換えればよいだけです。

なお、日の定義は左のようになっています。









これで平準化前の「連続休みを2回以上」制約が記述できました。
この結果は、勤務表自動作成ソフト スケジュールナースで、14秒かかりました。

今回は、前回と違って、分離した2回以上連続休みしか数えないので、公公公を 2連続休み2回とカウントする不具合はありません。




できれば、休み間隔は、公公-- 2週間--公公
にできればより良い(平準化)、というご要望がありました。
明日実装してみたいと思います。