次のような大変丁寧なご質問を頂きました。この質問の優れた点は、問題箇所の説明であることは、勿論ですが、、再質問の余地がなく、必要にして十分な情報が盛り込まれています。しかも、ご自分でトライして、このようにしたけれどもダメだったと、記述されていることです。
このように記述して頂くと、どこで躓いているのかが分かるので、大変ありがたいです。
「夜勤」というシフトを今まで、各Grから一人づつ、計2名確保していたけれども、新しく、どちらのGrにも属せる人が居た場合は、上のように制約したい、とのことですね。これに対する私の一次回答は次です。
夜勤というシフトを二つに分けるのよいかと思います。
夜勤＝夜勤ナース業務 または 夜勤支援業務
とします。
次の3つの制約で、所望の動きになると思います。
１）1<=夜勤ナース業務<=2
２）夜勤支援業務<=1
３）2<=夜勤<=2
３）番目の制約は、夜勤する人は、変わらず2人、という制約です。これは異論ないと思います。１）番目の制約は、ナース夜勤でみると、上の二つのケースでみて、2人のナースの方が夜勤する場合と、1人のナースと1人の支援業務の方の場合があります。どちらのケースでも、最低ナースは一人確保されている必要があります。最大で2名は異論ないと思います。２）番目の制約は、二つのケースで見ると、0名もしくは１名となります。
一つのシフトは、同じ人には二つ割り当てられることはなく、常に一つという性質を利用して制約します。スタッフプロパティ上の集合は、どちらの集合にも属する場合が出てくるので、仕事を分けるには、シフトを分けることが必須になります。（今後、さらに夜勤の種類が増える場合には、タスクを使うことで、シフトとタスクの分離が出来、メンテナンス性がよいものとなりますが、今回の場合は、シフト分割でよいでしょう。）
分かりづらければ、現在のプロジェクトファイルを送って頂ければ、それに上記を追加変更いたします。
ということで、具体的にプロジェクトを変更していきます。
夜勤シフトのチェックを外します。
すると、次のようになります。
勤務者数で参照されているので、勤務者数のチェックを外します。
多くの箇所で参照されているので、グループ毎の設定をオフにします。
行制約も同様です。
削除した「夜勤」を二つにシフトにします。夜勤ナースと、夜勤支援という二つのシフトを追加しました。
シフト集合を追加しました。このとき、「夜勤」は、元の「夜勤」と同じ名前にしておくのがポイントです。
行制約で前の夜勤ラベルは、トでした。元のシフト「夜勤」は無くなりましたが、新しくシフト集合の「夜勤」は、存在しています。ソフトが参照しているのは、ラベルではなく、名前の方です。名前「夜勤」は、変わっていないので、パターンを弄る必要はなく、グループの適用をオンにしていけばよいだけで済みます。
殆ど全てのグループの適用をオフにし、その後オンにしました。中身を弄るのは、唯一列制約部分になります。
グループ集合は新たに次を作成しました。
スタッフプロパティで夜勤支援を追加し、動作を確認します。
何故かナース2人を許容しているのですが、そのケースはありませんでした。試しにナース二人を予定で勤務させましたが、その場合は確かにその通りになりました。原因はよくわかりませんが、ナース勤務が多忙であるとすれば、説明が着くかもしれません。
以上で、実装終了です。基幹となるシフトを変更すると、多数の箇所に影響を及ぼすのは、必然です。多くの制約でそのシフトを参照しているので、制約毎にオフしていくと何がなんだか分からなくなってしまいますが、グループのオフであれば、何とか記憶の範疇ではないでしょうか？
しかし、上のようにすれば、それほど手間ではありません。
その他にもタスクを用いる方法、Pythonを用いる方法等を思いつきますが、多分、今回の方法が一番分かりやすいと思います。
＝>早速、見て頂き、返信を頂きました。
ブログを拝見させていただき、修正版も確認しました。
こちらの希望通りの仕様となっており感動いたしました。
精読しましたところ私が混乱していたところが理解でき、また新たに勉強になった部
分もあり大変助かりました。
とのことで、安堵しました。これも、また嬉しいのは、どうだったかが記載されていることです。納得行く答えに辿りつくことが出来たかは、こちらも気になっているものです。
このようなお返事を頂くと大変ありがたいです。
してみると、最初の質問の仕方から、Closeに至るまで首尾一貫しているのは、相手に対する気遣いではないか？と思います。他人であり、普段の状況が分からない私に対して、分かりやすいようにご自分の問題を図示を駆使した説明することは、簡単なようで実は、難しいことです。
こうした、日本語能力の高さと言いますか、広く言えばコミュニケーション能力は、「制約を弄る」ということにおいて、重要な能力の指標だとも思います。「制約をする」とは、日本語で５W１Hを規定することに他なりませんから。
図示をするのは、面倒なことです。でもその作業をすることにより自分の考えをまとめることに繋がり、なおかつ、相手にも分かり易い説明になる、結局、一番早い問題FIX方法ではないでしょうか？ と思った次第です。
対照的な例は、
で述べました。
私は、一次回答をするのに5分もかかっていません。問題を直ぐに理解できたからです。
鋭い方は、一次回答は、図示を言葉にしただけであることに気づくかもしれません。実際、図を見ながら、回答しました。言い換えると、ここまで記述できるなら、制約化できるまであと一歩のところだった、ということが言えます。
プロジェクトを修正するのに30分位、スクショを取りながらブログ文章を書くのに3時間位かかっています。他人に説明するということは、それだけ手間がかかるということです。しかし、その結果として、以降、今回の学習により同様の問題は独力でFIXできるようになる、という成果が得られます。
今回の問題は、比較的高度な、それでいてありそうな問題です。独力でこのレベルを操れるようになったならば、開発者として望外の喜びです。そして、こんなときは、こういう風にすればいいんだ、ということを皆さまには、頭の隅に入れてもらって何かの折に参考にして頂けたら、幸いです。
0 件のコメント:
コメントを投稿