■ タスク予定基数制約部にリフレッシュを追加
基数制約編集後は、リフレッシュして編集を確定させてください。
この機能は、タスクプロジェクトである必要がありますが、シフトプロジェクトでもタスクプロジェクトにすることは、割に簡単に出来ます。
2025年6月18日水曜日
2025年6月17日火曜日
Q「日勤以外」を希望する場合の予定入力の仕方
Q.
予定入力についてですが、ある日の勤務で「日勤以外」を希望する場合、当院では「当直・明け・休み」のいずれかを希望することになるのですが、そのような予定入力のやり方は設定されていますか？
Ans.
シフト定義の脇にシフト集合のタブがあります。
それで、欲しいシフト集合を合成していただけますでしょうか？
例を添付しますので参考にしてください。
2025年6月16日月曜日
NotebookLM化によるメンテナンス
今後、プロジェクト作成サービスプロジェクトおよびレクチャに使用したプロジェクトは、全てお客さまの許可を頂いた上で、
NotebookLM上で、メンテナンスをすることにしました。
個人情報は全て秘匿しますが、グループや、グループ集合は、そのまま公開となります。
NoteboolLM上でメンテナンスすることの利点は、
１）他のユーザ実装を参考に出来る
２）実際的な実装マニュアルに出来る
３）何年後かに、担当者が変わったとしても自職場の実装思想、仕様等は、NotebookLM上で共有されており、引き継ぎが楽。
です。
私にとっても、単にマニュアルを見てもらうだけのご質問には、案内をしなくてもよくなり、双方にとってメリットしかありません。
ご理解の程、よろしくお願いいたします。
2025年6月15日日曜日
ZOOMからMEETに変更します
ZOOM容量が直ぐにひっ迫するので、GOOGLE MEETに変更することにしました。
MEETは、ブラウザベースで動くので専用アプリをインストールする必要はありません。
が、ブラウザは、CHROMEにした方が良いよいです。
録画ファイルも3カ月間有効となります。よろしくお願いします。
2025年6月14日土曜日
お客さまのプロジェクトファイル
ご相談を機に、お客さまが作成したプロジェクトファイルを拝見させていただくときがあります。
で、気づくのは、物凄く沢山の予定と制約群があることです。お客さま自身が一から記述したプロジェクトというのは、担当者が変わったりして何年も引継がれてきた資産だと思います。
ではありますが、大体の傾向として、
■ハード制約が多すぎる
■冗長な制約が多い
■予定が多すぎる
ように思います。
で、それを見てしまうと添削したくなってしまい、無償レクチャをオファーすることがあります。勿論、強制ではなく、業務が立て込んでいればお断りして頂いて構いません。
（お客さまの許可が得られたならば、添削例をアップします。）
また、既に私が設計した5年前のプロジェクトも未だ現役で頑張っている例もお見掛けしました。スタッフ名は大分入れ替わっていましたが、ほぼ設計時のままでした。
このように永く使っていただけることも多いのですが、共通しているのは、ルールは初期設計時から、変わっているということです。
初期設計時のままルールが同じであれば、何の問題もないのですが、現実の世界で、ルールが不変の職場は存在しないと言ってよいでしょう。
其のたびに、菅原システムズ等の業者に頼むよりは、
自分達でメンテナンス出来る力をつけておいた方がよい、
というポリシーに数年前より変更したのは、上のような背景があるからです。
2025年6月13日金曜日
NotebookLM入門
グーグル「NotebookLM」入門：信頼できる自分だけのAIアシスタントを作るには？ | Business Insider Japan
なるほど、取り込まれるのは、テキストがコピーされることなので、ソースを更新するには、
１）ソースを選択して削除
２）再度ソースを取り込み
する必要があるようです。
はい、サイトを更新したらこの処理を忘れないようにします。
2025年6月12日木曜日
スケジュールナースNOTEBOOKLMの中身 活用方法
下は、NotebookLMを開いた様子です。
マインドマップを開いた様子です。
クリックするとソースが表示されます。
次は、チャットで「夜勤の平準化」と入力してみました。
記事のソースが表示されるので、参照したい箇所を素早く見つけだすことが出来ます。
是非ご活用頂きたいと思います。
これで調べたけれども、なお不明な場合に、サポートをご活用頂くのが望ましいと思います。
まとめると、
１）スケジュールナースNotebooklm上で質問
２）1)で不明な場合にサポートに質問(プロジェクトファイル添付が望ましい）
３）菅原システムズの作業時間が一定時間以下ならば、無償サポート。
４） 大抵は、無償サポートとなります。（経験的には、5%程度以下が有償サポートになります。）有償になる場合、お見積りを提出し有償サポートを申し受けます。 (例は、こちら)
ということになります。
近い将来の構想としては、RPAツールの内製化 とAIモデリングの開発を予定しています。
しかし、それは、上記２）３）の代替えにしかならず、４）がAIモデリングに置き換わることはほぼない、という見解です。
ところで、「仕様から制約に落とし込むには？」と質問して、
https://schedule-nurse.blogspot.com/2024/09/blog-post_10.html
がソース表示されることを期待していたのですが、それらしい回答は得られませんでした。
明示的にソース追加してみたのですが、「ドメイン制限によりインポート出来ない」とのメッセージが出てインポートそのものが出来ないことが原因のようです。
具体的な操作ではなくて、こういう抽象度の高い質問に対する回答は、やはり資料を提供した方がよいので、折を見て、どこかのPDFに入れ込もうと思います。どこかに入れておきさえすれば、後は、NotebookLMが探してくれるので、探す手間がかかりません。
そういった地道な作業を繰り返し行うことで、回答品質が上がっていくはずです。
2025年6月11日水曜日
スケジュールナースNotebookLM一般公開について
https://notebooklm.google.com/notebook/62d80db8-458e-4928-9a97-020357dc34c6
グーグルアカウントがあると、スケジュールナースに関する情報を閲覧することが出来ます。
スケジュールナースの機能と文書は膨大で、初心者から上級者まで、各々のレベルに応じた目的の情報を探すのは容易ではありません。しかし、これがあると情報を整理して見ることが出来ます。
次の動画で、男女の会話部分は、NOTEBOOKLMが作成したものです。サイトを読み込ませ、若干のプロンプト追加1回で、作成しました。動画部分は、男女の会話に合わせて、適当に私がコピペしたものです。
私が書いていないことも会話していますが むしろ核心をついている、ようにも見えて驚くばかりです。
2025年6月10日火曜日
ZOOM録画に対するお願い
最近、お客さまとZOOMすることが多くて、結果、録画ZOOM容量がひっ迫していることが多いです。
個別にダウンロードをお願いしておりましたが、今後は、
■お客さまの方で必要がある場合にはダウンロードして頂く
■ダウンロードする場合は、１週間以内とする（一週間を過ぎたものは削除します）
ということにしたいと思います。よろしくお願いいたします。
2025年6月9日月曜日
特許支払い期限通知サービス
保有する4件の特許のうち最初の２件、登録特許5807978と、5807980の特許が、11年目を迎えようとしています。長い年月が経ちましたが、アルゴリズム１は、改善を行いつつも基本的には当初の特許クレーム通りの実装で変わりがありません。
特許維持のため特許年金送付処理を行いました。
10年を超えると減免措置はなくなり特許維持に結構かかります。
手続きとしては、
１）納付番号を取得
２）Payeasyで納付
３）納付書送付
となります。期限までに納めないと権利が消失してしまいますが、現在は、Remindサービスがあることに気づき、登録しました。
これですと1カ月ないし2カ月前にメールが届くので、忘れる心配がありません。
2025年6月8日日曜日
CuoptとHighs(1.11.0)がWarmStartをサポート
CuoptとHighs最新版(1.11.0)でCUPDLPのWarmStartがサポートされたようです。実装を見ると、CuoptとHighs実装は、共にCOPT版のCUPDLPを基礎にしているものの同じではないようです。
Cuoptの方は、RMMを使っています。GPUを使ったボトルネックは、メインＧＰＵメモリの帯域問題の他に、CPUとの通信速度が極めて遅いことがあります。特に小規模のLPの場合、一回の計算サイクルが短く、相対的にCPUとの通信速度がボトルネックになってしまいます。反対に、大規模LPでは、計算サイクルが長く相対的に問題にはなりえません。RMMを使えば小規模LP時の問題を回避できるのですが、残念ながらRMMは、Windowsではサポートされていません。恐らくはデバイスドライバ関連の問題だと思うので、多分、今後も変わることはないでしょう。。従い、Windowsでは、Cuopt版をそのまま使用することは出来ないと思います。この辺はサーバAPIとして使ってくれ、というスタンスかもしれません。また、SPMV改善は未だなされていないようです。
SPMV改善がなされれば、ＣＯＰＴ版と明確な差異となる筈です。こちらは、メインGPUメモリの帯域問題を改善するので、大規模であればあるほど、その寄与度合いは上がるはずです。なので、NVIDAも本気で取り組むはずです。Mittleman Benchmarkに現れると思いますので、結果を待ちたいと思います。
とりあえず、HIGHSは、RMMの問題はないと思いますので、HIGHSをそのままポートしたいと思います。また、近い将来Cuopt版でSPMV改善がなされると思うのでそちらもWatchして行きたいと思います。
2025年6月7日土曜日
2025年6月6日金曜日
生成AIと最適化の未来
久保先生のビデオ。面白いです。
NotebookLMを使って、男女の会話を自動生成したようです。
これ凄いですね。自然すぎて、ビックリです。
【1番使える‼️】無料のGoogle最強AI「NotebookLM」に日本語版音声Audio Overview機能が爆誕！徹底解説
スケジュールナースで、どうすれば良いか分からないときは、リソースを指定して、NotebookLM化しておくと、ヒントになると思います。スケジュールナースは、日々アップデートしているのであまり古い情報は見ないようにした方がよいでしょう。（ハルシネーション対策）
リソースの検索先を示しておきます。
本ブログ （スケジュールナースⅢ以降・2021年以降）
しかし、どんなに情報整理しても、分からない制約が存在する可能性はあります。ありきたりのよくある制約については、解る可能性がありますが、そうではない制約もあるかもしれません。その場合は、サポートをご活用ください。
モデリングは、私自身悩むこともまれではありません。看護師・介護士関連では、ほぼ定型的な処理ですので、悩むことはないのですが、新規の他業種プロジェクトでは、本当に悩むことがあります。お客さま自身が仕様を分かっていないことがあること、にも起因していると思いますが、それだけではなく、どういうモデリングをしたら上手くそしてメンテナンスが容易なプロジェクトになるかというのは、試行錯誤の部分が多々ある、ということでもあります。私自身・そしてお客さまもよく分かっていない、そうした問題は、依然として存在し、AIから最も遠い領域であると思います。
消えるプログラマ、残るソフトウェア開発者 と言われているように、お客さまとの開発作業が含まれている分野が最後は残ると思います。
2025年6月5日木曜日
RPAツールの内製化
最近のサポートにおいて、ZOOMは必須で、多いときは週に4回位こなします。ZOOMで、お客さまのご質問に答えたり、その場でご要求を実装したりします。実装するのは、私ではなくお客さまPCを共有して、私の指示を基にお客さまのスケジュールナース上で実装していきます。そうするのは時間がかかるのですが、少しでも覚えて頂くことを目的としてお客さまご自身で手を動かして頂くことを行っています。しかし、その場でやって頂くのは、定型処理であり、ありふれた制約であることが殆どです。
で、思ったことですが、それを私の代わりにAIにやらせるには、ちょっとハードルが高すぎるということです。そもそもGUIを直接に弄るのは難しい、そこでRPAツールを使えばどう？という発想が生まれてきます。
一方、何かスケジュールナース上で、看護研究で、勤務パターンによる急な欠勤者による影響度の調査、というテーマがあったとしましょう。この場合、パラメータを変えて大量の求解処理の必要があります。それをいちいち手で行うのはやってられない、RPAツールで出来ないか？という発想があると思います。
市井のツール、Power Automateを少し弄ってみたのですが、例えば特定の予定セルを操作するのは、とてもつもなく面倒で遅いということです。これは、外部からアプリの中身は分からないので、仕方がないということだと思います。
ならば、ツールに頼るのではなく、スケジュールナース自身で、スケジュールナースGUIを直接プログラミング言語で操作できるライブラリがあれば、その目的に叶うことになります。現状は、Pythonで制約処理と、ポスト処理を各々別プロセスで行わせていますが、それとは別に、Pythonで、GUIを操作できるようにしたいと思います。いわば、RPAツールの内製化です。
夢は、日本語で指示すると、例えば「遅番を分けて！」と指示すると遅番シフトを分けて、自動的に遅番⇒遅番集合にしてくれる、みたいな定型処理・ありきたりの処理の自動化を実現させることです。モデリング的発想だと、一気にモデル化しようとするから訳がわからなくなりますが、一つ一つの制約を実装・変更・追加・確認しながら組み込んで行ければ、人間と対話しながら人間の理解できるペースで実装できる、というところが、モデリングコンペティションのそれとは実際的に違います。
そのためには、やはりGUIとの橋渡し部分で、PythonでGUIを操れるようにする必要がある、ということです。
現状は、NSP問題の解決に注力していて余力がないのですが、来期以降取り組みたいテーマです。全てのNSP問題の解決は勿論ですが、市井のモデリングをAIと対話しながら出来るようになって、初めてスケジュールナースが完成する と思います。
2025年6月4日水曜日
2025年6月3日火曜日
2025年6月2日月曜日
Q. ブランク予定でUBが０にならない
Ans.
解を見ると最大夜勤回数設定の多い方が、夜勤間隔エラーを生じています。
以上です。
<Notes>
一般に、予定が入力されていない状態（ブランク予定）よりUBが良くなることはありません。制約を追加変更したときは、必ずブランク予定で求解し、UB＝＝０を確認しましょう。
もしも、UB==0になっていなかったのなら、原因を解析しリーズナブルなエラーであるかどうかを見極めるようにしましょう。
2025年6月1日日曜日
Q.夜勤専門スタッフが入りならば、遅出３名以上、明けならば、早出２名以上
Ans.
ペア制約AならばBで実装します。
仕様的には、
■今月の毎日について、夜勤専門スタッフが１名以上入りならば、遅出が３名以上
■今月の毎日について、夜勤専門スタッフが１名以上明けならば、早出が２名以上
となります。演算子「または」は、１名以上（≧1) と同じ意味になります。
以上で実装終了です。
＜Notes＞
この制約も、Default仕様に対する特殊ケースなので、矛盾しません。書き連ねることが出来ます。
ペア集合の不等式制約結果は、黄色・赤色マーキングが現在出来ません。要改善アイテムとしてリストしています。
2025年5月31日土曜日
2025年5月30日金曜日
Q. 水土は、早番・日勤２名以上
Ans.
今月水土という曜日集合を作ります。
以上で完了です。
＜Notes＞
既に、Defaultで、早番・日勤共１名以上という制約が存在します。その特殊ケースである今回の制約は、何ら矛盾することがないので、書き連ねることが出来ます。
2025年5月29日木曜日
Q.夜勤責任者および週末責任者
Q.
■ 責任者に関する制約
夜勤責任者：
夜勤者3名（夜勤専門）のうち、必ず1名は「夜勤責任者グループ」から選出され勤務
する必要あり
週末責任者：
土日祝日の勤務には、必ず1名は「週末責任者グループ」から選出され勤務する必要
あり
Ans.
グループ集合で、責任者のレベルを定義します。
以上です。
＜Notes＞
当初、責任者レベル６まで定義していましたが、実際的には、一つだけにしたようです。
2025年5月28日水曜日
Q. あるスタッフは、出来ない遅番の種類がある
Ans. 管理上分ける必要があるシフトは、分割します。
出来ない種類の遅番を遅3として追加します。
遅3のスタッフ毎のシフトを設定します。
以上で実装終了です。
2025年5月27日火曜日
Q.Xさんは、1日のうち早番を行い、かつ生活相談員としても活動する。どちらも早番、生活相談もカウント管理したい
Ans.
シフトは、1日に1個だけです。早番シフト、生活相談シフトは、各々単独の仕事のみになってしまいます。そこで、早番付生活相談（短早）というシフトを新たに追加します。
早番集合、生相集合というシフト集合を新たに追加し、それをカウントするように変更します。
早番をカウントします。（短早を含みます。）
以上で完了です。
＜Note＞
この例では、1日のうち複数の業務を行うシフトが1個だけですので、シフト型勤務表のままにしました。このタイプが２～３個のうちはシフト型勤務表のままで対応可能です。それ以上に状態数が多い場合は、タスク型勤務表にすることをお勧めします。
2025年5月26日月曜日
Q.責任者制約その他について
Q.
夜勤当日：
夜勤専門スタッフが夜勤に入る場合 → 遅番スタッフは 3名 必須
夜勤専門以外のスタッフが夜勤に入る場合 → 遅番スタッフは 2名 必須
夜勤明け翌日：
夜勤専門スタッフが夜勤明けの場合 → 早番スタッフは 2名 必須
夜勤専門以外のスタッフが夜勤明けの場合 → 早番スタッフは 1名 必須
水曜・土曜の特例：
水曜日および土曜日は、早番・遅番・日勤スタッフの合計で4名以上 必須
新たな制約
■ 責任者に関する制約
夜勤責任者：
夜勤者3名（夜勤専門）のうち、必ず1名は「夜勤責任者グループ」から選出され勤務
する必要あり
週末責任者：
土日祝日の勤務には、必ず1名は「週末責任者グループ」から選出され勤務する必要
あり
夜勤責任者と週末責任者が選出されるに制約したつもりですが、解がおかしいので原
因を追究していただければ幸いです。
Ans.
仕様とプロジェクトファイルを拝見しました。大変申し上げにくいのですが、無償で行うレベルではないと判断いたしました。
選択肢として下記二つを提案したいと思います。
１）今回1回限りの対応 1万2千円 (ZOOM1回レクチャ付)
２）プロジェクト作成サービス 5万5千円 （1年間サポート、期間内の変更を承ります。ZOOM回数の制限はありません）
いずれかをお選び頂きたくお願いします。
１）の場合は、お安くできますが、また仕様変更が発生した場合に、また、再度費用発生の可能性があります。
２）通常のプロジェクト作成サービスと同じですが、既にライセンスをお持ちですので、その分差し引いた額になっています。
ご検討をお願いいたします。
なお、１）２）に関係なく既に作業には着手しております。
2025年5月25日日曜日
2025年5月23日金曜日
看護研究でスケジュールナースを使う場合は無償で提供します
興味深い論文です。
https://www.jstage.jst.go.jp/article/janap/21/1/21_7/_pdf/-char/ja
このような研究はもっとなされてもよいと思います。
常々提起している、「休み希望無制限の職場で、出した者勝ちになる問題」、あるいは、変則２交代勤務における急な欠勤者の対応割り当ての困難化等、看護師勤務表は、看護品質と直接に関わってくる重要なテーマですが、残念ながら、現場サイドの研究は多くありません。
そこで、その方面での議論を活発化させることを目的として、無償で提供することにしました。
看護研究でスケジュールナースを使う方については、無償で提供することにします。研究終了後も、そのまま病棟１ライセンス分として継続使用することができます。
提供形態は、こちらになります。
審査はありませんが、所属と研究目的についてはお知らせください。（進捗・結果報告等の義務はありません。）
また、必要でしたら初期設定のZOOMレクチャを開催します。（複数の参加者による聴講・実習となる可能性があることをご承知ください。）
ご質問・ご希望のかたはサポートまでお問い合わせください。
Q.前後に夜勤のない土日2連休を1回以上
Ans.
3交代勤務者の金曜日の準夜がないこと月曜日の深夜勤務がないことが条件になります。
介助者については、夜勤のない人もいるので、単純に土日連休としています。
2025年5月22日木曜日
Q.夜勤で男性のみを避けたい
Ans.女性が１名以上居るようにします。
グループ定義を下記のように追加します。
2025年5月21日水曜日
2025年5月20日火曜日
Q.介助員の設定方法
Q.介助員は、日勤をしない。準夜や早番・遅番のみを行わせたい。また、看護師は、遅番早番を行わない
Ans.
スタッフ毎のシフトで、担当しないシフトのチェックを外します。その際、「先月部には、本設定を適用しない」のオプションにチェックを入れておくのが吉です。
2025年5月19日月曜日
Q. （他の）皆さんは解を変更しないでやれているのでしょうか？
Ans.
勤務表作成サービスで作成されたプロジェクトにおいては、特に解を変更する必要はない？と認識しております。解を変更する必要があるのは、一般には欠勤者対応により勤務の変更があったときです。（スケジュールナースの場合は、解を変更することは推奨していなくて、予定を変更することを推奨しています。）
それを除けば、特に解を変更する理由はないという認識です。もし、毎回変更する必要があるなら、それはモデリング不足の可能性が高いです。サポートまでご相談ください。
2025年5月17日土曜日
Q.本当にこんな複雑なことを皆さんやっているのですか？
Ans.
＜スケジュールナースの操作＞
スケジュールナースの操作については、「そうです」という回答になります。
プロジェクトファイルが完成しているならば、勤務表作りは、従来の手作業で作るやり方と本質的には同じです。違うのは、手作業の場合は、途中解の存在があるかないか分からない状態で進むしかないのに対して、スケジュールナースの場合は、「どんなにこれから頑張ってもこれ以上良い解は、ないですよ。」という未来の解が求解で即、明示されることです。
＜制約の設計・メンテナンス＞
一方、スケジュールの操作とは別に、制約を設計したりメンテナンスをしていくのは、全ての方が行っているということではありません。
勤務表作成サービスを利用されている方は、初期時にその必要はありません。しかしメンテナンス上、将来あり得る変更については、そのやり方を学んで頂く必要があります。1年間という長い時間の中で、変更のご要求を受け付け、その場その場でそのやり方を学んで頂く方法に数年前から変更しました。この理由として、勤務表作成ルールは、自然に変更が発生していくものであり、結局は、ご自身で学んで頂くことが、永く使い続けることが出来ると考えたからです。それは、仕様⇒制約化⇒スケジュールに組み込みという一連の流れをご自身で行うことを意味します。
多病棟の病院では、各師長さんは、スケジュールナースを操作はしますが、基本的に制約のメンテナンスは行いません。事務部門や看護管理部門のZOOMレクチャを受けた担当者が制約のメンテナンスを行うことになります。しかしながら、クリニックや介護関係さらに個人でサブスクをご購入頂いた方は、費用上、中々そういう訳にもいかないと思いますので、ご自分で学習して頂くことが必要です。そのためのガイド本(自動勤務表: これからはじめる | 菅原孝幸 | 工学 | Kindleストア | Amazon)が出ていますので、そちらで学習して頂きたいと思います。
仕様に関しては、ソフトウェア、スケジュールナースには依存しないことに注意してください。複雑なのは、スケジュールナースではなく、仕様自体です。つまり、暗黙のうちに勤務表作成者は、大変色々な事を考えて作成しています。それを機械化するには、ルールの明示からまず始めることが必要です。実は、この部分が最も大きなバリアであって、そこを乗り越えられれば、殆ど障害はない、と言ってもよいと思います。まずは仕様から整理されることをお勧めします。
参考
仕様とは？
其の後に、モデリングという作業が必要になります。スケジュールナースのシフトを何にするかというのは、こちらをご覧ください。
2025年5月16日金曜日
Q.全く動きません
Q,6連勤をしない、土日休みは必ずつける、2連休の間隔は14日以上あけない、夜勤間隔は3日以上あけ、できるだけ常勤の夜勤回数を平均化する等が出来ていません。
Ans.「解がない」状態となっています。「解がない」状態とは、赤で何か言っている状態です。「解がない」ときの解は、意味がありません。見ないでください。
「解がない」とは、ハード制約間の矛盾によって引き起こされます。具体的には、Kindle本(自動勤務表: これからはじめる | 菅原孝幸 | 工学 | Kindleストア | Amazon)を読んで頂き、ハード制約とソフト制約についてとは何か？から学んで頂く必要があります。
看護師勤務表作成は、簡単ではありません。一つ一つの制約を丹念に積み重ねる作業が必要となります。一朝一夕に出来ることはありません。これは、看護師勤務表作成の本質的複雑さに起因します。どんなにAIが発達したとしても、問題そのものの複雑さは変わりようがないことに注意してください。この問題を計算機に真面目に解かせたいならば、生半可な気持ちでは、立ちゆきません。焦らず、ゆっくりと一つ一つ理解しながら進めてください。
それでは、具体的なエラーの解消方法を説明します。
１）指摘されている制約の中身を見る
赤丸をダブルクリックして
土曜日に公休でないことを禁止、つまり、土曜日は公休にする、というハード制約になっていることが分かります。
祝日の公休は、祝休み（公休でない）を制約しています。これはやはりハード制約になっています。
一方で公休である、他方で公休でないという矛盾の日が存在すれば、解がない状態となります。つまり、土曜日かつ祝日の日がある、これが原因です。
または、ソフト制約化を行います。
これを解消するには、どちらの制約をオフにすれば、OKです。
（元になったプロジェクト(病棟3交代Newは、ソフト制約化済みです。））
登録:
投稿 (Atom)