(57)【特許請求の範囲】
【請求項１】
コンピュータに、
ユーザの識別子と該ユーザにより設定された希望日時とを含む希望データを格納する希望データ格納部に格納されている前記希望データ、および所定期間内の日時と該ユーザとを対応付ける配置のルールに基づいて、該希望データと該ルールの少なくとも一部とを満たす該配置に関する第１のスケジュールを生成し、
前記第１のスケジュールをデータ格納部に格納し、
前記データ格納部に格納されている前記第１のスケジュールと、前記ルールとを比較し、
比較した結果に基づいて、前記第１のスケジュールが前記ルールを満たさない配置を含むか判定し、
前記第１のスケジュールが前記ルールを満たさない配置を含むと判定した場合に、前記ユーザ毎に過去の希望実現状況に関するデータを格納している希望実現状況データ格納部に格納されているデータに基づいて前記希望データ格納部に格納されている前記希望データに含まれる一部の希望日時を除外し、
前記希望データのうち除外された希望日時以外の希望日時に基づいて、第２のスケジュールを生成し、前記第２のスケジュールを出力する
処理を実行させるためのスケジュール生成プログラム。
【請求項２】
前記第２のスケジュール生成において、
前記ルールを満たさない配置を含まない前記第２スケジュールを生成するまで、前記希望日時のうち、除外する希望日時を変更することを特徴とする請求項１記載のスケジュール生成プログラム。
【請求項３】
前記希望データが、前記ユーザによる前記希望日時に対する希望の強弱を表す希望度をさらに含み、
前記コンピュータは、さらに、
前記希望実現状況データ格納部に格納されている前記過去の希望実現状況に関するデータと前記希望度とに基づいて、前記希望データに含まれる各前記希望日時に対する各優先順位を決定する処理を実行し、
前記希望日時を削除する処理において、各前記希望日時に対する前記各優先順位に基づいて、該希望日時のうち除外すべき希望日時を決定することを特徴とする
請求項１または２記載のスケジュール生成プログラム。
【請求項４】
前記過去の希望実現状況に関するデータが、過去希望日時が実現された第１の回数及び過去希望日時の第１の総数と、実現された過去希望日時の希望度と実現されなかった過去希望日時の希望度の差である満足度とを含み、
前記優先順位を決定する処理において、
前記過去の希望実現状況に関するデータと前記希望データとに基づいて、前記ユーザ毎に、前記希望データに含まれる前記希望日時の数および前記第１の回数との和である第２の回数、前記希望日時の数と前記第１の総数の和である第２の総数、及び前記満足度である第２の満足度を算出し、
前記希望データに含まれる各前記希望日時について、前記第２の総数に対する前記第２の回数の割合に応じた希望実現度と当該希望日時についてのユーザについての前記第２の満足度とから、ユーザ総合満足度を算出し、
前記ユーザ総合満足度に基づいて、前記希望日時についての希望度の割合である希望優先度を算出し、
前記希望優先度を昇順にソートすることで、前記希望データに含まれる前記希望日時の優先順位を決定する
ことを特徴とする請求項３記載のスケジュール生成プログラム。
【請求項５】
コンピュータが、
ユーザの識別子と該ユーザにより設定された希望日時とを含む希望データを格納する希望データ格納部に格納されている前記希望データ、および所定期間内の日時と該ユーザとを対応付ける配置のルールに基づいて、該希望データと該ルールの少なくとも一部とを満たす該配置に関する第１のスケジュールを生成し、前記第１のスケジュールをデータ格納部に格納し、
前記データ格納部に格納されている前記第１のスケジュールと、前記ルールとを比較し、
比較した結果に基づいて、前記第１のスケジュールが前記ルールを満たさない配置を含むか判定し、
前記第１のスケジュールが前記ルールを満たさない配置を含むと判定した場合に、前記ユーザ毎に過去の希望実現状況に関するデータを格納している希望実現状況データ格納部に格納されているデータに基づいて前記希望データ格納部に格納されている前記希望データに含まれる一部の希望日時を除外し、
前記希望データのうち除外された希望日時以外の希望日時に基づいて、第２のスケジュールを生成し、前記第２のスケジュールを出力する
処理を実行するスケジュール生成方法。
【請求項６】
ユーザの識別子と該ユーザにより設定された希望日時とを含む希望データを格納する希望データ格納部に格納されている前記希望データ、および所定期間内の日時と該ユーザとを対応付ける配置のルールに基づいて、該希望データと該ルールの少なくとも一部とを満たす該配置に関する第１のスケジュールを生成し、前記第１のスケジュールをデータ格納部に格納する手段と、
前記データ格納部に格納されている前記第１のスケジュールと、前記ルールとを比較する手段と、
比較した結果に基づいて、前記第１のスケジュールが前記ルールを満たさない配置を含むか判定する手段と、
前記第１のスケジュールが前記ルールを満たさない配置を含むと判定した場合に、前記ユーザ毎に過去の希望実現状況に関するデータを格納している希望実現状況データ格納部に格納されているデータに基づいて前記希望データ格納部に格納されている前記希望データに含まれる一部の希望日時を除外する手段と、
前記希望データのうち除外された希望日時以外の希望日時に基づいて、第２のスケジュールを生成し、前記第２のスケジュールを出力する手段と、
を有するスケジュール生成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、スケジュール生成技術に関する。
【背景技術】
【０００２】
例えば看護師の勤務スケジュールを生成するような場合に、各看護師の希望の他に、業務遂行上満たすべき条件（人員の数、連続出勤が基準を超えないこと、夜勤が連続しないといった禁止勤務パターンとならない、勤務看護師のスキルレベルについての条件を満たしている、患者の症状等に合わせるなど）を満たした勤務スケジュールを生成することが求められる。。従来は、看護師の希望とこのような条件とを全て満たすように勤務スケジュールを生成できない場合には、勤務スケジュールを作成する管理者（看護師長など）が、業務遂行上満たすべき条件を優先して勤務スケジュールを生成することになる。
【０００３】
一方、例えば勤務者の希望する条件および過去に作成した勤務シフトの実績に基づいて勤務シフトを作成するような従来技術が存在している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−２６９２５６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ここで、業務遂行上満たすべき条件を優先して勤務スケジュールが作成された場合に、希望を実現できない看護師に不満がたまってしまう。しかし、従来の勤務スケジュール作成において、希望を採用する場合と希望を採用しない場合との判断は管理者の最良によるところが大きく、必ずしも、各看護師が公平に希望を実現しているか否かは考慮されていなかった。つまり、従来の勤務スケジュール作成においては、勤務公平な選定を自動的に行うことはできない。さらには、勤務スケジュールを作成する管理者の負担や手間も大きくなる。
【０００６】
また、特許文献１に開示された技術は、例えば業務遂行上満たすべき条件（例えば人員の数など）を満たす勤務シフトを作成することができない。
【０００７】
このような勤務スケジュールだけではなく、施設の利用など様々なスケジュール生成においてスケジュールに基づいて配置される人員の希望を反映させる場合には、上で述べたような問題が存在しているが、適切な解決策は示されていない。
従って、本技術の目的は、一側面として、複数のユーザに対してできる限り公平に希望を実現するようにスケジュールを生成するための技術を提供することである。
【課題を解決するための手段】
【０００８】
本方法は、（Ａ）ユーザの識別子と該ユーザにより設定された希望日時とを含む希望データを格納する希望データ格納部に格納されている希望データ、および所定期間内の日時と該ユーザとを対応付ける配置のルールに基づいて、該希望データと該ルールの少なくとも一部とを満たす該配置に関する第１のスケジュールを生成し、第１のスケジュールをデータ格納部に格納するステップと、（Ｂ）データ格納部に格納されている第１のスケジュールと、上記ルールとを比較し、比較した結果に基づいて、第１のスケジュールが上記ルールを満たさない配置を含むか判定するステップと、（Ｃ）第１のスケジュールが上記ルールを満たさない配置を含むと判定した場合に、ユーザ毎に過去の希望実現状況に関するデータを格納している希望実現状況データ格納部に格納されているデータに基づいて、希望データ格納部に格納されている希望データに含まれる一部の希望日時を除外し、希望データのうち除外された希望日時以外の希望日時に基づいて、第２のスケジュールを生成し、第２のスケジュールを出力するステップとを含む。
【発明の効果】
【０００９】
複数のユーザに対してできるだけ公平に希望を実現するようにスケジュールを生成できるようになる。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施の形態のシステム構成図である。
【図２】図２は、スケジューリングサーバの機能ブロック図である。
【図３】図３は、希望入力画面の一例を示す図である。
【図４】図４は、実施の形態に係る処理フローを示す図である。
【図５】図５は、希望データ格納部に格納されるデータの一例を示す図である。
【図６】図６は、患者ＤＢに格納されるデータの一例を示す図である。
【図７】図７は、必須人員データの一例を示す図である。
【図８】図８は、スケジュール表形式の希望データの一例を示す図である。
【図９】図９は、初期スケジュール表の一例を示す図である。
【図１０】図１０は、第２スケジュール生成処理の処理フローを示す図である。
【図１１】図１１は、満足度ＤＢに格納されるデータの一例を示す図である。
【図１２】図１２は、希望優先度を説明するための図である。
【図１３】図１３は、希望優先度を説明するための図である。
【図１４】図１４は、希望優先度の算出例を示す図である。
【図１５】図１５は、希望優先度の順位付けの一例を示す図である。
【図１６】図１６は、第２スケジュール生成処理を説明するための図である。
【図１７】図１７は、特定の希望入力を削除後の希望データの一例を示す図である。
【図１８】図１８は、第２スケジュール生成処理において生成されたスケジュール表の一例を示す図である。
【図１９】図１９は、第２スケジュール生成処理の処理フローを示す図である。
【図２０】図２０は、第２スケジュール生成処理を説明するための図である。
【図２１】図２１は、第２スケジュール生成処理を説明するための図である。
【図２２】図２２は、第２スケジュール生成処理を説明するための図である。
【図２３】図２３は、本実施の形態に係る処理フローを示す図である。
【図２４】図２４は、第３スケジュール生成処理の処理フローを示す図である。
【図２５】図２５は、第３スケジュール生成処理を説明するための図である。
【図２６】図２６は、第３スケジュール生成処理を説明するための図である。
【図２７】図２７は、第３スケジュール生成処理を説明するための図である。
【図２８】図２８は、第３スケジュール生成処理を説明するための図である。
【図２９】図２９は、第３スケジュール生成処理を説明するための図である。
【図３０】図３０は、第３スケジュール生成処理を説明するための図である。
【図３１】図３１は、第３スケジュール生成処理を説明するための図である。
【図３２】図３２は、第３スケジュール生成処理を説明するための図である。
【図３３】図３３は、基礎データの一例を示す図である。
【図３４】図３４は、更新後の満足度ＤＢに格納されるデータの一例を示す図である。
【図３５】図３５は、本実施の形態に係る処理の検証を説明するための図である。
【図３６】図３６は、本実施の形態に係る処理の検証を説明するための図である。
【図３７】図３７は、本実施の形態に係る処理の検証を説明するための図である。
【図３８】図３８は、本実施の形態に係る処理の検証を説明するための図である。
【図３９】図３９は、本実施の形態に係る処理の検証を説明するための図である。
【図４０】図４０は、本実施の形態に係る処理の検証を説明するための図である。
【図４１】図４１は、コンピュータの機能ブロック図である。
【発明を実施するための形態】
【００１１】
図１に、本技術の一実施の形態に係るシステムを示す。以下は、看護師の勤務スケジュールを生成するためのシステムを一例に説明する。図１に示すように、本実施の形態に係るシステムにおいては、例えばＬＡＮ（Local Area Network）であるネットワーク１に、看護師長が操作する例えばパーソナルコンピュータである師長端末５と、看護師が操作する例えばパーソナルコンピュータである複数の看護師端末７と、本実施の形態における主要な処理を実施するスケジューリングサーバ３とが接続されている。スケジューリングサーバ３は、例えばログイン管理機能、看護師などの勤怠管理などの他の機能を有する場合もあるが、本実施の形態における主要部ではないので、以下では説明を省略する。また、師長端末５及び看護師端末７は、スケジューリングサーバ３へログインしているユーザに応じて切り替わるようにしてよいし、専用の端末であってもよい。さらに、パーソナルコンピュータ以外の装置が端末として機能する場合もある。
【００１２】
次に、図２にスケジューリングサーバ３の機能ブロック図を示す。スケジューリングサーバ３は、ルールデータベース（ＤＢ）３１と、患者ＤＢ３２と、指示入力部３３と、スケジュール生成部３４と、スケジュールデータ格納部３５と、スケジュール処理部３６と、希望入力部３７と、希望データ格納部３８と、満足度ＤＢ３９と、希望優先度算出部４０と、スケジュールＤＢ４１と、基礎データ格納部４２と、満足度ＤＢ更新部４３と、出力部４４とを有する。
【００１３】
希望入力部３７は、例えば看護師端末７から受信した希望データを希望データ格納部３８に格納する。スケジュール生成部３４は、例えば指示入力部３３からの指示に応じて、ルールＤＢ３１及び患者ＤＢ３２のデータに従って、希望データ格納部３８に格納されているデータ等に対してスケジューリング処理を実施して、処理結果をスケジュールデータ格納部３５に格納する。スケジュール処理部３６は、スケジュールデータ格納部３５とルールＤＢ３１と希望データ格納部３８とに格納されているデータを用いて処理を実施し、最終的なスケジュールのデータをスケジュールＤＢ４１に登録する。なお、場合によっては、スケジュール処理部３６は、スケジュール生成部３４及び希望優先度算出部４０と連携する。希望優先度算出部４０は、満足度ＤＢ３９及び希望データ格納部３８に格納されているデータを用いて、希望データ格納部３８に格納されているデータを更新する。また、スケジュール処理部３６は、スケジュールＤＢ４１に登録されたスケジュールを生成するために用いた希望データから満足度ＤＢ３９を更新するためのデータを生成し、基礎データ格納部４２に格納する。満足度ＤＢ更新部４３は、基礎データ格納部４２及び満足度ＤＢ３９に格納されているデータを用いて満足度ＤＢ３９を更新する。出力部４４は、スケジュールＤＢ４１に登録されたスケジュールのデータを、要求元の端末などに出力する。
【００１４】
次に、図３乃至図４０を用いて、スケジューリングサーバ３の動作を説明する。例えば、看護師端末７からのアクセスに応じて、スケジューリングサーバ３の希望入力部３７は、希望入力ページデータを看護師端末７に送信し、看護師端末７は希望入力ページデータを受信すると、希望入力ページを表示装置に表示する。例えば図３に示すような希望入力画面が表示される。図３の例では、既にログインしている状態であって、看護師名又はユーザＩＤを表示すると共に、希望日と希望勤務形態と希望度とを含む希望データセットを１又は複数入力するようになっている。図３の例では、既に３つの希望データセット（以下、希望データセットで表される希望入力を希望と呼ぶ場合もある。）が入力されている。なお、希望勤務形態は、例えば日勤、休暇、早出、遅出、夜勤、準夜勤などである。また、希望度は、希望の強弱（又は重要度）を表す度合いであって、ここでは１０段階で表示される。但し、１が最も弱い希望であり、１０が最も強い希望である。また、本実施の形態では、１月の希望数には上限があり、同一日の複数希望は入力できないものとする。さらに、１月の希望度の合計にも上限があるものとする。このようにして入力された希望データセットは、看護師による指示に応じて、看護師端末７からスケジューリングサーバ３へ送信される。
【００１５】
スケジューリングサーバ３の希望入力部３７は、看護師端末７から希望データセットを受信すると、希望データ格納部３８に格納する（図４：ステップＳ１）。希望データ格納部３８には、例えば図５に示すようなデータが格納される。図５の例では、看護師名又はユーザＩＤと、希望日と、希望勤務形態と、希望度と、希望優先度とを登録するようになっている。但し、本ステップでは希望優先度については登録されない。
【００１６】
例えば、一定期間看護師によるこのような希望データセットの入力を受け付けた後、看護師長は、師長端末５を操作して、スケジュール生成をスケジューリングサーバ３の指示入力部３３に対して指示する。指示入力部３３は、師長端末５からの指示に応じて、スケジュール生成部３４にスケジュール生成を指示する。スケジュール生成部３４は、指示入力部３３からの指示に応じて、希望データ格納部３８に格納されている希望データに対してスケジューリング処理をルールＤＢ３１及び患者ＤＢ３２に従って実施し、初期スケジュール表を生成して、スケジュールデータ格納部３５に格納する（ステップＳ３）。本実施の形態に係るスケジュール生成部３４は、ルールＤＢ３１及び患者ＤＢ３２に従ってスケジュールデータを生成する既存のスケジュール生成エンジンである。
【００１７】
本実施の形態におけるルールＤＢ３１には、各勤務形態についての人員数についてのルールと、許容される連続出勤日数についてのルールと、禁止勤務パターンについてのルールと、看護師等が有するランクについての禁止ランク組み合わせについてのルールと、回避すべき看護師の組み合わせについてのルールとが登録されている。禁止勤務パターンは、例えば夜勤は二日連続は不可といったようなパターンを含む。また、禁止ランク組み合わせについてのルールは、例えば新人同士の夜勤は不可といったルールを含む。すなわち、ルールＤＢ３１には、看護師等と勤務日及び勤務状態（時間帯の概念を含む）とを対応付けるためのルールを格納する。
【００１８】
また、患者ＤＢ３２には、例えば図６に示すようなデータが格納される。図６の例では、患者ＩＤと、患者名と、病名と、重症度と、必須看護ランクと、入院予定日と、退院予定日とが登録されるようになっている。例えば、必須看護ランクが高いほど、ランクの高い看護師を割り当てることになる。
【００１９】
スケジュール生成部３４は、ルールＤＢ３１に登録されている、各勤務形態についての人員についてのルールと、患者ＤＢ３２の必須看護ランク等とから、スケジュールを生成すべき期間の各日について必須人員構成を決定するという前処理を実施する。そうすると、例えば図７に示すような必須人員データが生成され、本実施の形態ではルールＤＢ３１に登録される。図７の例では、各日付及び各勤務形態について算出された必須人員数のデータが含まれている。
【００２０】
その後、スケジュール生成部３４は、上で述べたルール及び希望データ格納部３８に格納されている希望データセットに含まれる看護師の希望を満たしつつ、可能な限り必須人員数を満たすようにスケジュールを生成する。このような処理は従来から行われているので、これ以上述べない。
【００２１】
なお、以下での説明がし易いように、希望データ格納部３８に格納されている希望データセットをも、スケジュール表と同様の形式で希望データとして表すものとする。すなわち、図８に示すように、各看護師について、日毎に希望の勤務形態及び希望度とを配置したテーブルとして表す。例えば「日（３）」は、日勤を希望度３で希望したことを表す。同様に、「休（７）」は、休暇を希望度７で希望したことを表す。
【００２２】
そして、スケジュール生成部３４は、例えば図９に示すような初期スケジュール表を生成する。図９の例では、各看護師について、日毎の勤務形態の割り当て結果を含む。但し、上でも述べたように、この段階では全ての看護師の全ての希望を満たすように割り当てを行っており、必須人員数を満たせていない場合がある。なお、図９の例では、希望度を示すことで、希望の勤務形態が設定されている部分を示している。また、図９の例では、必須人員数を満たせていないエラー及び不足人数の合計についても示されているが、ステップＳ３ではまだエラーは判断されていない。
【００２３】
その後、スケジュール処理部３６は、スケジュールデータ格納部３５に格納されている初期スケジュール表に対して、エラーが存在しているか確認する（ステップＳ５）。ここでは、各日について、各勤務形態の人員数を計数し、図７で示した各勤務形態の必須人員数と比較し、計数された人員数が必須人員数に達していなければエラーと判断する。なお、以下の処理で不足人数が用いられる場合もあるので、各勤務形態についての不足人数を計数した上で、図９の最下行の数字で示すように不足人数の合計を計算しておく。そして、初期スケジュール表において全くエラーが存在していない場合には（ステップＳ７：Ｎｏルート）、端子Ａを介して図２３のステップＳ１９の処理に移行する。
【００２４】
一方、初期スケジュール表においてエラーが存在している場合、スケジュール処理部３６は、第２スケジュール生成処理を実施する（ステップＳ９）。第２スケジュール生成処理については、図１０乃至図２２を用いて説明する。
【００２５】
スケジュール処理部３６は、希望優先度算出部４０に指示を行って、希望優先度算出部４０は、指示に応じて希望データ格納部３８に格納されている各希望データセットについて希望優先度を満足度ＤＢ３９に格納されているデータを用いて算出し、希望データ格納部３８に格納する（図１０：ステップＳ２１）。
【００２６】
満足度ＤＢ３９には例えば図１１に示すようなデータが格納されている。図１１の例では、看護師毎に、満足度、希望入力の数である希望数の履歴、実現された希望入力の数である希望実現数の履歴、及び希望実現率とが登録されるようになっている。満足度ＤＢ３９における満足度は、実現された希望についての希望データセットに含まれる希望度と実現されなかった希望についての希望データセットに含まれる希望度との差である。希望数の履歴については、例えば６ヶ月分及び合計が含まれ、希望実現数の履歴についても同様である。希望実現率については、希望実現数の合計／希望数の合計（希望実現度は１００倍した値）で算出される値である。
【００２７】
ステップＳ２１では、今回全ての希望入力が実現されたと仮定した上で、看護師毎に第２の満足度を算出する。具体的には、看護師毎に、第２の満足度＝過去の満足度＋今回の希望データセットに含まれる希望度合計、で算出される。さらに、同様の仮定の下、第２の希望実現率についても看護師毎に算出する。具体的には、看護師毎に、第２の希望実現率＝（直近５ヶ月前からの希望実現数合計＋今回の希望入力の数）／（直近５ヶ月前からの希望数合計＋今回の希望入力の数）、で算出される。さらに、希望優先度は、看護師毎に、以下のように算出される。
【００２８】
【数１】
0005533570.tif 000002
ここでＡ＝注目する希望データセットに含まれる希望度、Ｂ＝第２の満足度、Ｃ＝第２の希望実現率×１００（＝第２の希望実現度）である。
【００２９】
（１）式の分母は、第２の満足度の二乗と第２の希望実現度の二乗との和の平方根となっている。これによって個人の総合的な満足度、すなわち個人総合満足度を表している。第２の希望実現度は、回数として希望が実現された度合いを表しているが、これだけでは個人の総合的な満足感を表すことはできない。すなわち、希望度が低い希望ばかりが実現されて、希望度が高い希望について実現されなければ、満足感が大きくなることはないためである。従って、希望実現度のこのような問題を補うため、実現された希望度及び実現されなかった希望度の差で表される第２の満足度が使用されている。この点を図１２及び図１３を用いて説明する。
【００３０】
例えば、図１２に示すように、各看護師について、第２の満足度、第２の希望実現度及び個人総合満足度が計算されたものとする。
【００３１】
これをグラフで表すと図１３のようになる。図１３の例では、横軸が第２の満足度を表しており、縦軸は第２の希望実現度を表しており、このような平面に、看護師Ａ、Ｂ及びＣをプロットしている。個人総合満足度は、この平面の原点からの距離を表しており、原点から遠いほど大きな値となり、総合的な満足感が高まる。逆に、第２の満足度＝１００、第２の希望実現度＝１００を基準点とすると、この基準点から近いほど、総合的な満足感が高くなる。図１３では、基準点から等距離のラインを円弧で表しており、基準点からの角度が異なっていても同様の満足感のある点を分かりやすくしている。
【００３２】
（１）式においては、分母をこのような個人総合満足度に設定して、分子には注目する希望の希望度を設定しているので、満足感の高い看護師の方が希望優先度は小さい値となり、満足感の低い看護師の方が希望優先度は大きな値となる。一方、今回の希望度が大きい値であれば希望優先度は大きな値となり、今回の希望度が小さい値であれば希望優先度は小さな値となる。
【００３３】
但し、（１）式は一例である。例えば、上では第２の満足度と、第２の希望実現度とについては平等に扱うことを前提としているが、重み付けを行うように変更することも可能である。さらに、平方根を算出しているが、平方根を算出しなくても同様の値が得られる。
【００３４】
ステップＳ２１を実施することで、図５の希望優先度の列に値が設定される。
【００３５】
このように希望優先度が算出されると、スケジュール処理部３６は、希望優先度に基づき希望入力を昇順でソートする（ステップＳ２３）。例えば、図１４に示すように各希望入力について希望優先度が算出されると、図１５に示すように希望優先度が小さい順に順位付けが行われる。図１５に示した数値が順位を表す。上でも述べたように、希望優先度が小さい場合には、希望度が小さい値であるか、既に満足感の高い看護師についての希望であるので、優先して希望入力を削除するものとする。ここでは、２０１０年７月２日における看護師Ｂの希望入力が最も低い希望優先度となっている。
【００３６】
そして、スケジュール処理部３６は、カウンタｉを１に設定し（ステップＳ２４）、希望データにおいてｉ番目の希望優先度の希望入力を仮に削除する（ステップＳ２５）。図１６において丸印で示すように、希望データにおいて、最も低い希望優先度となっている希望入力である「２０１０年７月２日における看護師Ｂの希望入力」を仮に削除すると、希望データは図１７に示すような状態となる。これによって満たすべき条件が減ったことになる。例えば、希望データ格納部３８に格納されている希望データをコピーして、コピーの希望データから削除対象の希望入力を削除する。
【００３７】
そうすると、スケジュール処理部３６は、スケジュール生成部３４にスケジューリング処理の実施を指示し、スケジュール生成部３４は、特定の希望入力が削除された後の希望データに対してスケジューリング処理をルールＤＢ３１及び患者ＤＢ３２に従って実施し、スケジュール表を生成して、スケジュールデータ格納部３５に格納する（ステップＳ２７）。この処理は、特定の希望入力が削除された後の希望データを用いる点以外は、ステップＳ３の処理と同じであるからこれ以上述べない。
【００３８】
例えば、図１８に示すようなスケジュール表が生成されたものとする。図９に示した初期スケジュール表と比較すると、多少割り当てられる勤務形態が変化している。
【００３９】
そして、スケジュール処理部３６は、スケジュールデータ格納部３５に格納されているスケジュール表とルールＤＢ３１に格納されている必須人員データ（例えば図７）とを比較して、必須人員数が満たされない日が存在するか、すなわちエラーが存在しているか判断する（ステップＳ２９）。図１８の例えば最下行に示すように、エラーが残ってしまっている。
【００４０】
エラーが存在していなければ（ステップＳ３１：Ｎｏルート）、スケジュール処理部３６は、エラーなしを例えば今回生成したスケジュール表に対して設定して（ステップＳ３３）、端子Ｃを介して元の処理に戻る。このように、希望優先度が低い順に削除対象を入れ替えて、エラーがなくなったところで処理を終了すれば、削除される希望入力を最小限に抑えて、すなわち不満が生じる看護師を最小限に抑えてスケジュール生成が行われることになる。
【００４１】
一方、エラーが存在していれば（ステップＳ３１：Ｙｅｓルート）、スケジュール処理部３６は、希望データを元に戻す処理を実施する（ステップＳ３５）。例えば、特定の希望入力を削除した後の希望データを破棄し、希望データ格納部３８に格納されている元の希望データを有効化する。そして、スケジュール処理部３６は、カウンタｉを１インクリメントし（ステップＳ３７）、端子Ｄを介して図１９の処理に移行する。
【００４２】
図１９の処理の説明に移行して、スケジュール処理部３６は、カウンタｉが希望入力総数を超えたか判断する（ステップＳ３９）。超えていない場合には、端子Ｅを介してステップＳ２５に戻る。一方、カウンタｉが希望入力総数を超えている場合には、スケジュール処理部３６は、エラーありを例えば今回生成したスケジュール表に対して設定して（ステップＳ４１）、元の処理に戻る。
【００４３】
このように、希望優先度の小さい順に削除対象の希望入力を変更してスケジューリング処理を実施しても、エラーが解消しない場合がある。
【００４４】
例えば、図１８でエラーの存在が確認されると、図２０に示すように、最も低い希望優先度となっている希望入力である「２０１０年７月２日における看護師Ｂの希望入力」を元に戻し、２番目に低い希望優先度となっている希望入力である「２０１０年７月１日における看護師Ｃの希望入力」を選択する。そして、図２１に示すように、２番目に低い希望優先度となっている希望入力である「２０１０年７月１日における看護師Ｃの希望入力」を仮に削除して、スケジュール生成部３４に、スケジューリング処理を実施させる。そうすると、例えば図２２に示すようなスケジュール表が生成される。図１８のスケジュール表と比較すると、２０１０年７月１日についてはエラーが解消しているが、他の部分にエラーが残ってしまっている。従って、以下説明を省略するが、２番目に低い希望優先度を元に戻し、３番目に低い希望優先度となっている希望入力を仮に削除する。このような処理をエラーが解消するまで繰り返す。なお、本例では、最も高い希望優先度の希望入力を削除してもエラーが解消しなかったものとする。
【００４５】
図４の処理の説明に戻って、スケジュール処理部３６は、スケジュールデータ格納部３５に格納されているスケジュール表に対してエラーが設定されているか確認する（ステップＳ１１）。処理は端子Ｂを介して図２３の処理に移行する。
【００４６】
図２３の処理の説明に移行して、スケジュール処理部３６は、エラーが設定されているか判断する（ステップＳ１５）。エラーがなければステップＳ１９に移行する。一方、エラーが設定されている場合には、スケジュール処理部３６は、第３スケジュール生成処理を実施する（ステップＳ１７）。第３スケジュール生成処理については、図２４乃至図３４を用いて説明する。
【００４７】
スケジュール処理部３６は、スケジュールデータ格納部３５に格納されている初期スケジュール表から、不足人数合計が最大の日を特定する（図２４：ステップＳ５１）。例えば、初期スケジュール表が図２５に示すようなもので、最下行に示す数値が不足人数合計であるものとする。そうすると、図２５の例では、２０１０年７月１日が特定される。
【００４８】
そして、スケジュール処理部３６は、特定された日の残余の希望入力のうち希望優先度が最も低い希望入力を希望データ（繰り返し処理を実施した場合には前回のステップＳ５３の処理で生成された削除後の希望データ）から削除した希望データを生成し、例えばメインメモリなどの記憶装置に格納する（ステップＳ５３）。図２５の例では、２０１０年７月１日に２つの希望入力が含まれており、図２６に示すように、看護師Ｃの希望入力の方が希望優先度が低い。従って、図２７に模式的に示すように、希望データから２０１０年７月１日における看護師Ｃの希望入力を特定し、図２８に示すように削除後の希望データを生成する。
【００４９】
なお、特定された日に残余の希望入力が存在していない場合には、不足人数合計が次に多い日を特定し、その日における残余の希望入力のうち希望優先度が最も低い希望を希望データから削除する。
【００５０】
その後、スケジュール処理部３６は、スケジュール生成部３４に対してスケジューリング処理の実施を指示し、スケジュール生成部３４は、削除後の希望データに対してスケジューリング処理をルールＤＢ３１及び患者ＤＢ３２に従って実施し、スケジュール表を生成して、スケジュールデータ格納部３５に格納する（ステップＳ５５）。この処理は、特定の希望入力が削除された後の希望データを用いる点以外は、ステップＳ３の処理と同じであるからこれ以上述べない。
【００５１】
例えば、図２９に示すようなスケジュール表が生成されたものとする。図２５に示した初期スケジュール表と比較すると、２０１０年７月１日のエラーは解消し、その他も不足人数が減っている。なお、ステップＳ５５では、不足人数は計算されていない。
【００５２】
そして、スケジュール処理部３６は、スケジュールデータ格納部３５に格納されているスケジュール表とルールＤＢ３１に格納されている必須人員データ（例えば図７）とを比較して、必須人員数が満たされない日が存在するか、すなわちエラーが存在しているか判断する（ステップＳ５７）。エラーが存在している場合には、各勤務形態についての不足人数を合計して不足人数の合計を計算する。なお、図２９の例では、最下行に示すように、エラーが残ってしまっているとする。
【００５３】
エラーが存在している場合には（ステップＳ５９：Ｙｅｓルート）、スケジュール処理部３６は、ステップＳ５５で生成されたスケジュール表から、不足人数合計が最大の日を特定する（ステップＳ６１）。図２９の例では、２０１０年７月４日が特定される。そしてステップＳ５３に戻る。
【００５４】
ステップＳ５３に戻ると、看護師Ａと看護師Ｃの希望入力が残っており、図１４からすると、図３０において丸で示すように、看護師Ｃの希望入力の方が希望優先度が低いことが分かる。従って、２０１０年７月４日におけるこの看護師Ｃの希望入力をさらに削除した希望データ（例えば図３１）を生成する。このように、第３スケジュール生成処理においては、累積的に希望入力を削除してゆき、なんとか早期にエラーなしのスケジュール表を生成するようにする。
【００５５】
再度ステップＳ５５でスケジュール表を生成すると、例えば図３２に示すようなスケジュール表が得られたものとする。図３２の例では、まだエラーが残ってしまっている。そこで、最も不足人員が多い日を特定するが、図３２の例では、２０１０年７月４日及び２０１０年７月３日が特定される。このように複数の日が特定された場合でも、それらの日の中で、最も希望優先度が低い希望入力を特定する。図１４からすると、図３２の例では、２０１０年７月３日における看護師Ｂの希望入力が特定され、削除される。
【００５６】
このような処理をエラーがなくなるまで繰り返して、ステップＳ５９でエラーなしと判断されると（ステップＳ５９：Ｎｏルート）、スケジュール処理部３６は、エラーなしとなったスケジュール表に対してエラーなしを設定する（ステップＳ６３）。そして元の処理に戻る。
【００５７】
このようにして、エラーをなくすために不足人員総数が多い日から順番に、希望優先度を加味した形で、希望入力を累積的に削除して、エラーのないスケジュール表を生成する。
【００５８】
なお、この処理でエラーがなくならない場合も可能性としては存在するが、そのような場合にはどのように人員を配置してもエラーとなる。従って、根本的な人員不足については想定しないものとする。
【００５９】
図２４の処理の説明に戻って、スケジュール処理部３６は、スケジュールデータ格納部３５に格納されており且つエラーなしが設定されているスケジュール表のデータ又はエラーがなかった初期スケジュール表のデータを、スケジュールＤＢ４１に登録する。また、スケジュール処理部３６は、エラーなしが設定されているスケジュール表を生成する際に用いられた希望データ、又は初期スケジュール表にエラーがなかった場合には初期の希望データから、満足度ＤＢ３９を更新するための基礎データを生成し、基礎データ格納部４２に格納する。
【００６０】
仮に、図２７に示すような希望データにおいて、２０１０年７月２日における看護師Ｂの希望入力のみ実現できなかった場合、図３３に示すような基礎データを生成する。すなわち、各看護師について、希望入力毎の希望度と当該希望度から算出される満足度と希望数と希望実現数とが算出されるようになっている。なお、希望入力毎の希望度は、実現された場合には正の値とし、実現されなかった場合には負の値とする。そうすると、希望度を合計すれば今月の満足度になる。希望数は希望入力の数であり、希望実現数は実現された希望入力の数である。「実現された」というのは削除せずに希望データに残っているということである。
【００６１】
そして、満足度ＤＢ更新部４３は、基礎データ格納部４２に格納されている基礎データを用いて満足度ＤＢ３９を更新する（ステップＳ１９）。満足度ＤＢ３９は、図１１から図３４に示すような状態に更新される。具体的には、満足度については図３３に示すような今回の満足度を過去の満足度に加算する。さらに、希望数の履歴については、最も古い希望数のデータを破棄して、図３３に示すような今回の希望数を登録すると共に、希望数の合計を計算し直す。同様に、希望実現数の履歴については、最も古い希望実現数のデータを破棄して、図３３に示すような今回の希望実現数を登録すると共に、希望実現数の合計を計算し直す。さらに、希望実現率についても、更新後の希望数の合計と更新後の希望実現数の合計とから（希望実現数の合計）／（希望数の合計）で希望実現数を計算し直す。
【００６２】
以上のような処理を行うことで、次回のスケジュール生成時に用いられるデータが用意される。
【００６３】
その後、出力部４４は、スケジュールＤＢ４１に格納されているスケジュール表のデータを、例えばスケジュール生成指示を行った師長端末５に送信する（ステップＳ２０）。師長端末５は、スケジュール表のデータを受信し、表示装置に表示する。このようにすれば、エラーのないスケジュール表が得られる。すなわち、看護師長の手間は大幅に削減されている。また、上でも述べたように、看護師の満足感を反映した指標で、希望入力の優先順位付けが行われて、エラーをなくすために当該優先順位に従って希望入力を削除するので、より満足感を公平に与える形でスケジュール表が生成される。
【００６４】
上で述べた処理では、３段階でスケジュール表を生成している。１段階目のスケジュール表は、全ての希望入力を満たすように生成した初期スケジュール表である。２段階目のスケジュール表は、初期スケジュール表でエラーがある場合に、希望優先度に従って削除すべき希望入力を入れ替えつつ生成したスケジュール表である。そして、３段階目のスケジュール表は、第２段階目のスケジュール表にエラーが解消できない場合に、エラーの程度の大きい順及び希望優先度の順で希望有力を削除して生成したスケジュール表である。
【００６５】
本実施の形態では、全体の満足感は１段階目のスケジュール表でエラーがなければ最も高く、２段階目になれば１段階目のスケジュール表により満足感は低下し、３段階目になるとさらに低下する。この点を検証しておく。
【００６６】
例えば、図３５に示すように、全ての希望入力が実現された場合を想定する。すなわち、初期スケジュール表が採用され、図３５の基礎データが得られた場合には、図３６に示すような満足度ＤＢ３９のデータ（一部のみ）が得られる。満足度、希望実現率及び個人総合満足度については、図３４のデータを生成した場合と同様の演算で得られる。一方、全体満足度については、個人総合満足度の総和として算出される。
【００６７】
次に、最も希望優先度が低い、２０１０年７月２日における看護師Ｂの希望入力のみが実現されなかった、すなわち２段階目のスケジュール表が採用された場合を考える。そうすると、図３７に示すような基礎データが得られ、図３８に示すような満足度ＤＢ３９のデータ（一部のみ）が得られる。このように看護師Ｂの個人総合満足度が下がってしまい、全体満足度も低下している。
【００６８】
さらに、２段階目でエラーなしのスケジュール表を生成できず、仮に希望入力のうち最も希望優先度が高い、２０１０年７月５日における看護師Ａの希望入力を削除することでエラーのない３段階目のスケジュール表が生成された場合を想定する。そうすると、図３９に示すような基礎データが得られ、図４０に示すような満足度ＤＢ３９のデータ（一部のみ）が得られる。このように看護師Ａの個人総合満足度が下がってしまい、全体満足度もさらに低下している。
【００６９】
このように段階が上がるほど徐々に満足感が下がってしまうので、各段階で可能な限り早期にエラーのないスケジュール表を生成して、全体の満足感をできるだけ維持しようとしている。
【００７０】
以上本技術の一実施の形態を説明したが、本技術はこれに限定されるものではない。例えば図２に示したスケジューリングサーバ３の機能ブロック図は一例であって、実際のプログラムモジュール構成と一致しない場合もある。
【００７１】
また、処理フローについても、処理結果が変わらない限り、処理順番を入れ替えたり、並列実施するようなことも可能である。
【００７２】
例えば、２段階目のスケジュール表の生成と、３段階目のスケジュール表の生成は、希望優先度さえ計算できてしまえば並列に実施できる。２段階目のスケジュール表生成でエラーのないスケジュール表ができた場合には、その時点で処理を打ち切れば３段階目のスケジュール表の生成を並列に行っても問題はない。このようにすれば、２段階目のエラーのないスケジュール表ができなかった場合には、直ぐに最終的な解を得ることができるようになる。
【００７３】
なお、上でも述べたが、看護師の勤務スケジュール生成にのみ適用可能なのではなく、他の勤務スケジュール生成に適用可能である。さらに、過去の希望実現状況を加味して公平に満足感を与えるようにスケジューリングする他の技術分野にも、適用可能である。
【００７４】
さらに、日単位で勤務形態を設定するようになっているが、他の時間単位であってもよい。
【００７５】
なお、上で述べたスケジューリングサーバ３、師長端末５及び看護師端末７は、コンピュータ装置であって、図４１に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本技術の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【００７６】
以上述べた本実施の形態をまとめると、以下のようになる。
【００７７】
本実施の形態に係るスケジューリング方法は、（Ａ）所定期間内における予定設定希望（少なくとも時間についての指定を含み、他の付随する条件を含むこともある）とユーザの識別子とを含む希望データを格納する希望データ格納部に格納されている希望データに対するスケジューリング処理を予め定められたルールに従って実施させることによって第１のスケジュールを生成させ、データ格納部に格納するステップと、（Ｂ）データ格納部に格納されている第１のスケジュールが、上記ルールに従っていない部分を含むか確認するステップと、（Ｃ）第１のスケジュールが上記ルールに従っていない部分（例えば人員不足が発生している部分）を含む場合には、ユーザ毎に過去の希望実現状況に関するデータを格納している希望実現状況データ格納部に格納されているデータに基づいて希望データ格納部に格納されている希望データに含まれる一部の予定設定希望を削除し、当該削除後の希望データに対するスケジューリング処理を上記ルールに従って実施させることによって上記ルールに完全に従っている第２のスケジュールを生成させ、スケジュールデータ格納部に格納する第２スケジュール生成ステップとを含む。
【００７８】
このようにすることで、希望実現状況を加味した形で実現できない予定設定希望を特定するようにすれば、複数のユーザに対してできるだけ公平に予定設定希望を実現するようなスケジュールを生成できるようになる。
【００７９】
なお、上で述べた希望データが、予定設定希望の強弱を表す希望度をさらに含むようにしてもよい。その際には、上で述べた第２スケジュール生成ステップが、（Ｃ１）希望データに含まれる各予定設定希望について、希望実現状況データ格納部に格納されている上記過去の希望実現状況に関するデータと希望度とから優先順位を決定する優先順位決定ステップと、（Ｃ２）希望データに含まれる予定設定希望のうち削除すべき予定設定希望を優先順位の低い順に変更しつつ、削除後の希望データに対するスケジューリング処理を、第２のスケジュールが生成されるまで繰り返させるステップとを含むようにしてもよい。
【００８０】
このようにすれば実現できない予定設定希望をできるだけ優先順位の低いものにして、満足感の低下を最小限に抑えることができる。
【００８１】
さらに、上記過去の希望実現状況に関するデータが、予定設定希望が実現された回数及び予定設定希望の総数と、実現された予定設定希望の希望度と実現されなかった予定設定希望の希望度の差である満足度とを含むようにしてもよい。この場合、上で述べた優先順位決定ステップが、（Ｃ１１）上記過去の希望実現状況に関するデータと希望データから、ユーザ毎に、希望データに含まれる予定設定希望が実現されたとした場合を仮定して上記予定設定希望が実現された回数である第２の回数、上記予定設定希望の総数である第２の総数及び上記満足度である第２の満足度を算出するステップと、（Ｃ１２）希望データに含まれる各予定設定希望について、当該予定設定希望についてのユーザについての第２の総数に対する第２の回数の割合に応じた希望実現度と当該予定設定希望についてのユーザについての第２の満足度とから算出されるユーザ総合満足度に対する当該予定設定希望についての希望度の割合である希望優先度を算出するステップと、（Ｃ１３）希望優先度を昇順にソートすることで、希望データに含まれる予定設定希望の優先順位を決定するステップとを含むようにしてもよい。
【００８２】
このようにすることで、客観的な希望優先度を算出できるようになる。具体的にはユーザ総合満足度によって、実現された予定設定希望の回数だけではなく、実現された予定設定希望の希望度を反映した満足度も考慮されて、ユーザの感じる満足感を数値化できるようになっている。
【００８３】
また、上で述べたユーザ総合満足度が、希望実現度の二乗と希望実現度の二乗とを加算することで算出されるようにしてもよい。なお、これらを重み付け加算してもよいし、さらに平方根を算出するようにしてもよい。
【００８４】
さらに、上で述べた第２スケジュール生成ステップが、（Ｃ３）優先順位が最も高い予定設定希望を希望データから削除した後の希望データに対するスケジューリング処理を実施したが、第２のスケジュールが生成されなかった場合、スケジュールデータ格納部に格納されている第１のスケジュールにおいて、ルールに基づき最も修正すべき、スケジューリングの単位時間を特定する単位時間特定ステップと、（Ｃ４）上記希望データから、特定した単位時間についての予定設定希望のうち優先順位が最も低い予定設定希望を削除し、当該削除後の希望データに対するスケジューリング処理をルールに従って実施させることによって、第３のスケジュールを生成し、データ格納部に格納する第３スケジュール生成ステップと、（Ｃ５）データ格納部に格納されている第３のスケジュールがルールに従っていない部分を含む場合には、第２のスケジュールが生成されるまで、第１のスケジュールの代わりに第３のスケジュールについて単位時間特定ステップを実施し且つ削除後の希望データを上記希望データとして第３スケジュール生成ステップを実施するステップとをさらに含むようにしてもよい。
【００８５】
このようにすれば、ルールを満たすようにスケジュールを生成することができるようになる。また、単位時間をベースにエラーを解消するようになっているが、希望優先度による優先順位も用いられているので、可能な限り実現できない予定設定希望による満足感の低下を抑制できている。
【００８６】
なお、上で述べた希望データが、予定設定希望の強弱を表す希望度をさらに含む場合がある。その場合には、上で述べた第２スケジュール生成ステップが、（ＣＣ１）希望データに含まれる各予定設定希望について、希望実現状況データ格納部に格納されている上記過去の希望実現状況に関するデータと希望度とから優先順位を決定する優先順位決定ステップと、（ＣＣ２）スケジュールデータ格納部に格納されている第１のスケジュールにおいて、ルールに基づき最も修正すべき、スケジューリングの単位時間を特定する単位時間特定ステップと、（ＣＣ３）希望データから、特定した単位時間についての予定設定希望のうち優先順位が最も低い予定設定希望を削除し、当該削除後の希望データに対するスケジューリング処理をルールに従って実施させることによって、第３のスケジュールを生成し、データ格納部に格納する第３スケジュール生成ステップと、（ＣＣ４）データ格納部に格納されている第３のスケジュールがルールに従っていない部分を含む場合には、第２のスケジュールが生成されるまで、第１のスケジュールの代わりに第３のスケジュールについて単位時間特定ステップを実施し且つ削除後の希望データを希望データとして第３スケジュール生成ステップを実施するステップとを含むようにしてもよい。このようなバリエーションも可能である。
【００８７】
なお、上で述べたような処理をコンピュータに実施させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭなどの光ディスク、光磁気ディスク、半導体メモリ（例えばＲＯＭ）、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、ＲＡＭ等の記憶装置に一時保管される。
【００８８】
以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。
【００８９】
（付記１）
コンピュータに、
ユーザの識別子と該ユーザにより設定された希望日時とを含む希望データを格納する希望データ格納部（図２：３８）に格納されている前記希望データ、および所定期間内の日時と該ユーザとを対応付ける配置のルールに基づいて、該希望データと該ルールの少なくとも一部とを満たす該配置に関する第１のスケジュールを生成し、前記第１のスケジュールをデータ格納部（図２：３５）に格納し、（図４：Ｓ３）
前記データ格納部に格納されている前記第１のスケジュールと、前記ルールとを比較し、比較した結果に基づいて、前記第１のスケジュールが前記ルールを満たさない配置を含むか判定し、（図４：Ｓ５）
前記第１のスケジュールが前記ルールを満たさない配置を含むと判定した場合に、前記ユーザ毎に過去の希望実現状況に関するデータを格納している希望実現状況データ格納部（図２：３９）に格納されているデータに基づいて、前記希望データ格納部に格納されている前記希望データに含まれる一部の希望日時を除外し、前記希望データのうち除外された希望日時以外の希望日時に基づいて、第２のスケジュールを生成し、前記第２のスケジュールを出力する（図４：Ｓ９−図２３：Ｓ１７）
処理を実行させるためのスケジュール生成プログラム。
【００９０】
（付記２）
前記第２のスケジュール生成において、
前記ルールを満たさない配置を含まない前記第２スケジュールを生成するまで、前記希望日時のうち、除外する希望日時を変更することを特徴とする付記１記載のスケジュール生成プログラム。
【００９１】
（付記３）
前記希望データが、前記ユーザによる前記希望日時に対する希望の強弱を表す希望度をさらに含み、
前記コンピュータは、さらに、
前記希望実現状況データ格納部に格納されている前記過去の希望実現状況に関するデータと前記希望度とに基づいて、前記希望データに含まれる各前記希望日時に対する各優先順位を決定する処理を実行し、（図１０：Ｓ２１、Ｓ２３）
前記希望日時を削除する処理において、各前記希望日時に対する前記各優先順位に基づいて、該希望日時のうち除外すべき希望日時を決定することを特徴とする（図１０：Ｓ２５−図１９：Ｓ３９）
付記１または２記載のスケジュール生成プログラム。
【００９２】
（付記４）
前記過去の希望実現状況に関するデータが、過去希望日時が実現された第１の回数及び過去希望日時の第１の総数と、実現された過去希望日時の希望度と実現されなかった過去希望日時の希望度の差である満足度とを含み、
前記優先順位を決定する処理において、
前記過去の希望実現状況に関するデータと前記希望データとに基づいて、前記ユーザ毎に、前記希望データに含まれる前記希望日時の数および前記第１の回数との和である第２の回数、前記希望日時の数と前記第１の総数の和である第２の総数、及び前記満足度である第２の満足度を算出し、（図１０：Ｓ２１）
前記希望データに含まれる各前記希望日時について、前記第２の総数に対する前記第２の回数の割合に応じた希望実現度と当該希望日時についてのユーザについての前記第２の満足度とから、ユーザ総合満足度を算出し、前記ユーザ総合満足度に基づいて、前記希望日時についての希望度の割合である希望優先度を算出し、（図１０：Ｓ２１）
前記希望優先度を昇順にソートすることで、前記希望データに含まれる前記希望日時の優先順位を決定することを特徴とする（図１０：Ｓ２３）
付記３記載のスケジュール生成プログラム。
【００９３】
（付記５）
コンピュータが、
ユーザの識別子と該ユーザにより設定された希望日時とを含む希望データを格納する希望データ格納部（図２：３８）に格納されている前記希望データ、および所定期間内の日時と該ユーザとを対応付ける配置のルールに基づいて、該希望データと該ルールの少なくとも一部とを満たす該配置に関する第１のスケジュールを生成し、前記第１のスケジュールをデータ格納部（図２：３５）に格納し、（図４：Ｓ３）
前記データ格納部に格納されている前記第１のスケジュールと、前記ルールとを比較し、比較した結果に基づいて、前記第１のスケジュールが前記ルールを満たさない配置を含むか判定し、（図４：Ｓ５）
前記第１のスケジュールが前記ルールを満たさない配置を含むと判定した場合に、前記ユーザ毎に過去の希望実現状況に関するデータを格納している希望実現状況データ格納部（図２：３９）に格納されているデータに基づいて、前記希望データ格納部に格納されている前記希望データに含まれる一部の希望日時を除外し、前記希望データのうち除外された希望日時以外の希望日時に基づいて、第２のスケジュールを生成し、前記第２のスケジュールを出力する（図４：Ｓ９−図２３：Ｓ１７）
処理を実行するスケジュール生成方法。
【００９４】
（付記６）
ユーザの識別子と該ユーザにより設定された希望日時とを含む希望データを格納する希望データ格納部に格納されている前記希望データ、および所定期間内の日時と該ユーザとを対応付ける配置のルールに基づいて、該希望データと該ルールの少なくとも一部とを満たす該配置に関する第１のスケジュールを生成し、前記第１のスケジュールをデータ格納部に格納する手段と、
前記データ格納部に格納されている前記第１のスケジュールと、前記ルールとを比較する手段と、
比較した結果に基づいて、前記第１のスケジュールが前記ルールを満たさない配置を含むか判定する手段と、
前記第１のスケジュールが前記ルールを満たさない配置を含むと判定した場合に、前記ユーザ毎に過去の希望実現状況に関するデータを格納している希望実現状況データ格納部に格納されているデータに基づいて前記希望データ格納部に格納されている前記希望データに含まれる一部の希望日時を除外する手段と、
前記希望データのうち除外された希望日時以外の希望日時に基づいて、第２のスケジュールを生成し、前記第２のスケジュールを出力する手段と、
を有するスケジュール生成装置。
【符号の説明】
【００９５】
３  スケジューリングサーバ
３１  ルールＤＢ
３２  患者ＤＢ
３３  指示入力部
３４  スケジュール生成部
３５  スケジュールデータ格納部
３６  スケジュール処理部
３７  希望入力部
３８  希望データ格納部
３９  満足度ＤＢ
４０  希望優先度算出部
４１  スケジュールＤＢ
４２  基礎データ格納部
４３  満足度ＤＢ更新部
４４  出力部
【図１】
0005533570.tif 000003
【図２】
0005533570.tif 000004
【図３】
0005533570.tif 000005
【図４】
0005533570.tif 000006
【図５】
0005533570.tif 000007
【図６】
0005533570.tif 000008
【図７】
0005533570.tif 000009
【図８】
0005533570.tif 000010
【図９】
0005533570.tif 000011
【図１０】
0005533570.tif 000012
【図１１】
0005533570.tif 000013
【図１２】
0005533570.tif 000014
【図１３】
0005533570.tif 000015
【図１４】
0005533570.tif 000016
【図１５】
0005533570.tif 000017
【図１６】
0005533570.tif 000018
【図１７】
0005533570.tif 000019
【図１８】
0005533570.tif 000020
【図１９】
0005533570.tif 000021
【図２０】
0005533570.tif 000022
【図２１】
0005533570.tif 000023
【図２２】
0005533570.tif 000024
【図２３】
0005533570.tif 000025
【図２４】
0005533570.tif 000026
【図２５】
0005533570.tif 000027
【図２６】
0005533570.tif 000028
【図２７】
0005533570.tif 000029
【図２８】
0005533570.tif 000030
【図２９】
0005533570.tif 000031
【図３０】
0005533570.tif 000032
【図３１】
0005533570.tif 000033
【図３２】
0005533570.tif 000034
【図３３】
0005533570.tif 000035
【図３４】
0005533570.tif 000036
【図３５】
0005533570.tif 000037
【図３６】
0005533570.tif 000038
【図３７】
0005533570.tif 000039
【図３８】
0005533570.tif 000040
【図３９】
0005533570.tif 000041
【図４０】
0005533570.tif 000042
【図４１】
0005533570.tif 000043