(57)【要約】【課題】有給休暇の売買を行うための有給休暇売買システムに関し，従業員同士の有給休暇の売買に関する処理を実現するシステムを提供することを目的とする。【解決手段】有給休暇売買システム１において，売り手登録部１１は，有給休暇の売却を希望する従業員（売り手）からの要求により，売り手情報記憶部２７に売り手のレコードを作成する。買い手登録部１２は，有給休暇の購入を希望する従業員（買い手）からの要求により，買い手情報記憶部２８に買い手のレコードを作成する。売買マッチング処理部１４は，売り手情報記憶部２７の売り手のレコードと買い手情報記憶部２８の買い手のレコードとのマッチングを行う。買い手合意処理部１５は，買い手がマッチング結果に合意すると，売り手と買い手との間の有給休暇売買処理を行う。【選択図】図１
2005309949.tif 000002
【特許請求の範囲】
【請求項１】
有給休暇の売却を希望する従業員である売り手と，有給休暇の購入を希望する従業員である買い手との間の有給休暇の売買を仲介するためのコンピュータによる有給休暇売買システムであって，
少なくとも希望売却日数を含む前記売り手の情報を入力し，情報記憶部に登録する第１の手段と，
少なくとも希望購入日数を含む前記買い手の情報を入力し，情報記憶部に登録する第２の手段と，
前記情報記憶部に登録された売り手の情報と買い手の情報とをあらかじめ定められた条件でマッチングさせることにより，前記売り手と前記買い手とを組み合わせる第３の手段と，
前記組み合わされた前記売り手と前記買い手との間の有給休暇の売買を処理する第４の手段とを備える
ことを特徴とする有給休暇売買システム。
【請求項２】
請求項１に記載の有給休暇売買システムにおいて，
前記第４の手段は，前記買い手が前記売り手と前記買い手との組み合わせに合意した場合にのみ，前記組み合わされた前記売り手と前記買い手との間の有給休暇の売買を処理する
ことを特徴とする有給休暇売買システム。
【請求項３】
請求項１または請求項２に記載の有給休暇売買システムにおいて，
前記第３の手段は，少なくとも前記売り手の労働力と前記買い手の労働力との格差，または，前記売り手の賃金と前記買い手の賃金との格差を所定の範囲内に収めるための条件でマッチングを行う
ことを特徴とする有給休暇売買システム。
【請求項４】
請求項１から請求項３までのいずれかに記載の有給休暇売買システムにおいて，
前記第１の手段は，前記売り手の情報があらかじめ定められた条件を満たす場合にのみ，前記売り手の情報を情報記憶部に登録し，
前記第２の手段は，前記買い手の情報があらかじめ定められた条件を満たす場合にのみ，前記買い手の情報を情報記憶部に登録する
ことを特徴とする有給休暇売買システム。
【請求項５】
請求項１から請求項４までのいずれかに記載の有給休暇売買システムが備える前記第１の手段，前記第２の手段，前記第３の手段および前記第４の手段として，コンピュータを機能させるための有給休暇売買システム用プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，有給休暇が余っている従業員と有給休暇が足りない従業員との間の有給休暇の売買を仲介する有給休暇売買システムに関するものである。
【背景技術】
【０００２】
労働基準法により，使用者（例えば，企業など）は，その雇入れの日から起算して６ヶ月間継続勤務した労働者（例えば，企業の従業員）に対して，１０日の有給休暇を与えなければならない（労働基準法第３９条第１項）。さらに，使用者は，１年６ヶ月以上継続勤務した労働者に対して，定められた日数（１日〜１０日，継続勤務年数による）を加算して有給休暇を与えなければならない（労働基準法第３９条第２項）。
【０００３】
これらの日数は，使用者が労働者に対して最低限与えなければならない有給休暇日数であり，使用者は，それ以上の日数の有給休暇を労働者に対して与えることができる。
【０００４】
また，有給休暇の請求権の有効期限は２年であり（労働基準法第１１５条），与えられた年に消化できなかった有給休暇は，その翌年に繰り越して請求することができる。与えられてから２年以上が経過した有給休暇については，その請求権が消滅する。
【０００５】
有給休暇の制度は労働者に休養を与えるための制度であるため，使用者が有給休暇に労働することを条件として，割増金やその他の手当を労働者に支給すること（いわゆる有給休暇の買い上げ）は認められていない。
【０００６】
また，労働者の側から買い上げを要求することも許されていない。これは，有給休暇の買い上げを認めると労働者が有給休暇を取らなくなるため，労働者の健康・安全を確保するために有給休暇を認めた労働基準法の趣旨に反するからである。
【０００７】
ただし，例外的に，使用者が労働基準法で定められている日数以上の有給休暇を労働者に認めている場合などには，使用者がその労働基準法で定めた日数を越える日数部分を買い上げても違法とはならない。また，消滅時効（２年間）や退職時などに消滅した分の有給休暇を買い上げても違法とはならない。
【０００８】
なお，前述したように一部の例外的な状況を除いて有給休暇の売買は認められておらず，有給休暇を売買するということ自体が容易に考えられるものではないため，以下に説明する有給休暇売買システム（有給休暇の売買を行うための計算機システム）に関する先行技術が記載された先行技術文献は，存在しないものと考えられる。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
前述したように，企業（使用者）は，労働基準法で定められている以上の有給休暇を従業員（労働者）に与えることができる。また，従業員は，今年度分の有給休暇について，翌年度に繰り越すことができる。
【００１０】
しかし，忙しい部署の従業員は，なかなか有給休暇を取得することができないため，繰り越されたものについても２年を経過させて消滅させてしまうことが多い。業務の都合上十分な有給休暇を取得できず，休むことのできない従業員は，有給休暇を取得して休んでいる従業員と同様の扱いを受けることに，不公平感を覚える可能性がある。
【００１１】
一方，不況で企業成績が悪化すると，一定時間操業を短縮しなければならない部署が出てきて，その部署の従業員の一部を一時解雇するといった手段を取らざるを得なくなることも考えられる。一時解雇は再雇用されることが前提となるものの結局解雇に変わりないため，一時解雇された従業員は不安を覚え，不当な解雇であるとして企業を訴える従業員も出てくる可能性がある。また，会社は解雇したくないものの病欠あるいはやむを得ない事情により長期間欠勤せざるを得ない従業員もいる。
【００１２】
このような状況に対処するためには，企業は，業務都合上の理由などで十分な有給休暇を取得することができない従業員から前述の例外的に買い取り可能な有給休暇を買い取り，その買い取った有給休暇をやむを得ない事情で休まざるを得ない従業員に対して売却し，その従業員を解雇することなく有給休暇中とすればよい。そうすることで，双方の従業員の満足度を向上させることができる。
【００１３】
しかし，このような有給休暇の売買に関する作業を人手で行うことは容易ではない。有給休暇の売買を行うときには，有給休暇を売却する従業員が売ることが可能な有給休暇を持っているかを確認したり，有給休暇を売却する従業員と購入する従業員とで業務内容や賃金などがマッチするかを確認する必要がある。このような作業を行うために，専門の従業員を用意するのは無駄である。
【００１４】
本発明は，上記の問題点の解決を図り，有給休暇の売買に関する処理を自動的に行うシステムを提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明は，上記の課題を解決するため，有給休暇の売却を希望する従業員である売り手と，有給休暇の購入を希望する従業員である買い手との間の有給休暇の売買を仲介するためのコンピュータによる有給休暇売買システムであって，少なくとも希望売却日数を含む売り手の情報を入力し，情報記憶部に登録する売り手登録手段と，少なくとも希望購入日数を含む買い手の情報を入力し，情報記憶部に登録する買い手登録手段と，情報記憶部に登録された売り手の情報と買い手の情報とをあらかじめ定められた条件でマッチングさせることにより，売り手と買い手とを組み合わせる売買マッチング処理手段と，組み合わされた売り手と買い手との間の有給休暇の売買を処理する買い手合意処理手段とを備えることを特徴とする。
【００１６】
また，買い手合意処理手段は，買い手が売り手と買い手との組み合わせに合意した場合にのみ，組み合わされた売り手と買い手との間の有給休暇の売買を処理することを特徴とする。
【００１７】
また，売買マッチング処理手段は，少なくとも売り手の労働力と買い手の労働力との格差，または，売り手の賃金と買い手の賃金との格差を所定の範囲内に収めるための条件でマッチングを行うことを特徴とする。
【００１８】
また，売り手登録手段は，売り手の情報があらかじめ定められた条件を満たす場合にのみ，売り手の情報を情報記憶部に登録し，買い手登録手段は，買い手の情報があらかじめ定められた条件を満たす場合にのみ，買い手の情報を情報記憶部に登録することを特徴とする。
【００１９】
以上の各手段による処理は，コンピュータとソフトウェアプログラムとによって実現することができ，そのプログラムをコンピュータ読み取り可能な記録媒体に記録することも，ネットワークを通して提供することも可能である。
【発明の効果】
【００２０】
本発明により，特に人手を要することなく，有給休暇の売買の作業を自動的に行うことが可能となる。
【００２１】
本システムは，有給休暇の売り手，買い手および売買を仲介する会社側にとって，次のようなメリットがある。
・有給休暇の売り手である従業員は，法定日数以上の有給休暇の代価を得ることができ，有給休暇を犠牲にして働いている従業員の会社に対する貢献が金銭で報われる形になるので，有給休暇を十分に取っている従業員に対する不公平感が解消される。
・有給休暇の買い手である従業員にとっては，通常の有給休暇より長い休暇が必要なような場合に，長期に渡って欠勤するより長期の有給休暇を取る方が解雇の不安がなく安心である。
・有給休暇売買システムを通じて有給休暇の売買を仲介する会社は，有給休暇の売り手と買い手の双方の従業員の満足度を向上させることができ，新しい福利厚生プランの導入が可能になる。
【発明を実施するための最良の形態】
【００２２】
以下，図を用いて，本発明の実施の形態を説明する。
【００２３】
図１は，本発明の実施の形態における有給休暇売買システムの構成例を示す図である。有給休暇売買システム１は，ＣＰＵおよびメモリを有する計算機システムであり，売買制御部１０と，情報記憶部２０とから構成され，社内ＬＡＮ等のネットワーク３を介して，従業員が使用する複数の端末２と接続されている。また，売買制御部１０は，売り手登録部１１，買い手登録部１２，有給取得日数情報更新部１３，売買マッチング処理部１４，買い手合意処理部１５から構成される。また，情報記憶部２０は，従業員基本情報記憶部２１，職種情報記憶部２２，等級情報記憶部２３，スキル情報記憶部２４，有給取得日数情報記憶部２５，有給法定日数情報記憶部２６，売り手情報記憶部２７，買い手情報記憶部２８から構成される。
【００２４】
売り手登録部１１は，有給休暇の売却を希望する従業員の端末２からの要求に応じて，売り手登録処理を行う。買い手登録部１２は，有給休暇の購入を希望する従業員の端末２からの要求に応じて，買い手登録処理を行う。有給取得日数情報更新部１３は，年度変り時などに，有給取得日数情報記憶部２５の更新処理を行う。売買マッチング処理部１４は，売り手情報記憶部２７のレコードと買い手情報記憶部２８のレコードとのマッチング処理を行う。買い手合意処理部１５は，買い手の合意により成立した売り手と買い手との間の有給休暇の売買に関する後処理を行う。
【００２５】
図２は，本実施の形態における従業員基本情報記憶部のデータ構成例を示す図である。従業員基本情報記憶部２１は，共通部２１ａと個別部２１ｂとに分かれる。共通部２１ａには，各従業員の一般的な共通基本情報として，従業員番号（従業員の識別番号），名前，所属，入社年月日，勤続年月，職種，等級（役職などのランク），本給，職責給，月収，１日当り賃金の情報が記憶されている。個別部２１ｂには，従業員ごとにその従業員がどのスキル（得意とする分野など）を持っているかが，優先度（例えば，得意な順番など）付きで記憶されている。
【００２６】
図３は，本実施の形態における職種情報記憶部のデータ構成例を示す図である。職種情報記憶部２２には，その会社の従業員が従事している職種が記憶されている。
【００２７】
図４は，本実施の形態における等級情報記憶部のデータ構成例を示す図である。等級情報記憶部２３には，その会社の従業員の等級分けが記憶されている。
【００２８】
図５は，本実施の形態におけるスキル情報記憶部のデータ構成例を示す図である。スキル情報記憶部２４には，職種ごとにどのようなスキルがあるかが記憶されている。
【００２９】
図６は，本実施の形態における有給取得日数情報記憶部のデータ構成例を示す図である。有給取得日数情報記憶部２５には，従業員番号，支払日数，繰越日数，合計日数，限度日数，消滅日数，特別取得日数，特別返却日数，総計日数，残日数が記憶されている。
【００３０】
支払日数は，当年度における有給法定日数（法律で定められた最低限の有給休暇日数）と，会社が上乗せして従業員に与える有給休暇日数との合計値である。繰越日数は，前年度の残日数である。合計日数は，支払日数と繰越日数との合計値である。限度日数は，当年度の使用の上限として会社が設定している有給休暇日数（購入した有給休暇日数は含まない）である。
【００３１】
消滅日数は，売却しなければ当年度で消滅してしまう有給休暇日数である。「合計日数≧限度日数」の場合には，合計日数から限度日数を引いた日数となり，「合計日数＜限度日数」の場合には０となる。なお，本実施の形態では，消滅日数の売却の有効期間は１年間（当年度中のみ）としている。
【００３２】
特別取得日数は，当年度において購入した有給休暇日数である。特別返却日数は，当年度において売却した有給休暇日数である。ただし，売却できるのは，有給法定日数を越えた部分である。
【００３３】
総計日数は，当年度中に使用可能な有給休暇日数（購入した有給休暇日数を含む）の総計である。「合計日数≧限度日数」の場合には，限度日数と特別取得日数との合計値となり，「合計日数＜限度日数」の場合には，合計日数と特別取得日数との合計値となる。
【００３４】
残日数は，当年度において使用できる有給休暇日数の残り日数である。残日数の初期値は総計日数である。有給休暇を取得するたびに，残日数は減っていく。
【００３５】
図７は，本実施の形態における有給法定日数情報記憶部のデータ構成例を示す図である。有給法定日数情報記憶部２６には，法律（労働基準法）で定められた最低限の有給休暇日数（必須取得日数）が，勤続年月ごとに記録されている。
【００３６】
図８は，本実施の形態のおける売り手情報記憶部のデータ構成例を示す図である。売り手情報記憶部２７には，登録日時，従業員番号，名前，職種，等級，１日当り賃金，売り日数（売却を希望する日数），優先度１スキル（優先度が１のスキル，以下同様），優先度２スキル，優先度３スキル，予約番号（売買マッチング処理でマッチした買い手の従業員番号），売却種別の情報が記憶されている。売却種別には，有給休暇の売却が，消滅時効となった有給休暇の売却（時効消滅売却）であるのか，有給法定日数を越えた部分の有給休暇の売却（法定日数以上売却）であるのかが記録される。
【００３７】
図９は，本実施の形態における買い手情報記憶部のデータ構成例を示す図である。買い手情報記憶部２８には，登録日時，従業員番号，名前，職種，等級，１日当り賃金，買い日数（購入を希望する日数），優先度１スキル，優先度２スキル，優先度３スキル，売り手特定済表示の情報が記憶される。売り手特定済表示は，売買マッチング処理によりすでにマッチした売り手がいるかを示す。
【００３８】
図１０は，本実施の形態における有給休暇売買の全体の流れを説明する図である。図１０を用いて，本実施の形態における有給休暇売買の全体の流れを大まかに説明する。
【００３９】
本実施の形態では，売り手となる従業員は売却したい有給休暇日数を端末２を用いて会社の有給休暇売買システム１に登録し，買い手となる従業員は購入したい有給休暇日数を端末２を用いて会社の有給休暇売買システム１に登録する。
【００４０】
ここで，本実施の形態で売り手が登録できる有給休暇日数は，
（１）労働基準法で定められている日数（有給法定日数）以上の有給休暇を会社が認めている場合に，その有給法定日数を越えた部分の日数，
（２）消滅時効（２年間）や退職時などに消滅した分の日数，
の範囲内の日数であることが条件となる。
【００４１】
また，本実施の形態で買い手が登録できる有給休暇日数は，
（１）会社がやむを得ないと判断した日数，
（２）全労働日に対して一定割合を切らない日数，
であることが条件となる。
【００４２】
有給休暇売買システム１では，売り手の情報と買い手の情報とのマッチングを行う。本実施の形態では，売り手と買い手とを以下の条件で最適に組み合わせる。
（１）売り手と買い手の職種が等しいこと。
（２）売り手と買い手の等級が等しいこと。
（３）売り手と買い手のスキルが等しいこと。
（４）売り手の売り日数（複数の売り手の売り日数の合計でよい）と，買い手の買い日数とが等しいこと。
【００４３】
ここで，本実施の形態では，売り手と買い手の職種，等級（役職など），スキルなどが等しい場合には，売り手と買い手の「本給＋職責給」がほぼ等しくなるため，売り手と買い手の所定時間あたりの賃金がほぼ等しいものと考える。また，有給休暇の売買では，売り手の方が圧倒的に多いことが予想されるため，買い手がいればマッチングはほぼ成立するものと考えられる。
【００４４】
有給休暇売買システム１は，最適に組み合わされた売り手の情報を，買い手の端末２に提示する。買い手は，端末２に提示された売り手の情報で合意するかを判断する。買い手が合意した時点で売買が成立し，名目上，会社が，売り手の有給休暇を売り手の１日当り賃金で買い上げ，買い手に売り手の１日当り賃金で売ることになる。
【００４５】
ここで，例えば，買い手が６日の有給休暇を希望しているのに対して５日分の売り手しか見つからなかった場合にも，買い手の端末２に売り手の情報を提示するようにしてもよい。このとき，買い手は，５日分でよい場合には合意し，５日分でだめな場合には合意しなければよい。
【００４６】
図１０を用いて，さらに具体的な例を説明する。Ａ氏，Ｂ氏，Ｃ氏，Ｄ氏は，売り手として，それぞれ８日，７日，３日，３日の登録をしている。また，Ｅ氏，Ｆ氏，Ｇ氏は，買い手として，それぞれ，１０日，７日，１０日を登録している。
【００４７】
有給休暇売買システム１は，売買マッチング処理を行う。売り手のＢ氏，Ｃ氏，買い手のＥ氏，Ｆ氏は，職種，等級が等しい（ここでは，１日当り賃金も等しい）と判断される。ここでは，Ｅ氏の方がＦ氏よりも先に登録したものとして，先に登録したＥ氏を優先して処理すると，売り手のＢ氏，Ｃ氏の登録日数の和が，買い手のＥ氏の登録日数と等しいので，Ｅ氏の端末２にＢ氏，Ｃ氏の情報を提示する。
【００４８】
Ｅ氏が，Ｂ氏，Ｃ氏から有給休暇を買うことに合意すると，有給休暇の売買が成立する。Ｅ氏が１０日分の賃金１８万円を支払うこととなり，Ｂ氏は７日分の賃金１２万６千円を，Ｃ氏は３日分の賃金５万４千円を得ることとなる。買い手が見つからなかったＡ氏とＤ氏は買い手待ちの状態となり，売り手が見つからなかったＦ氏とＧ氏は売り手待ちの状態となる。
【００４９】
以下では，より具体的な例について説明する。図１１は，本実施の形態における売り手登録処理フローチャートである。有給休暇を売却する従業員（売り手）は，自らの従業員番号を端末２に入力して有給休暇売買システム１へのログインを行い，売り手登録を要求する。なお，以下では，入力された従業員番号で個人を特定している。
【００５０】
売り手登録部１１は，端末２から売り手登録の要求を受けると（ステップＳ１０），売却対象日数算出処理（ステップＳ１１）を行う。売却対象日数算出処理では，詳しくは図１２に従って後述するように，その売り手が売却可能な有給休暇の日数を算出する。
【００５１】
売却対象日数算出処理（ステップＳ１１）が終了すると，売却対象日数が０であるかどうかを判定し（ステップＳ１２），０でなければ，売却対象日数を売り日数として，売り手情報記憶部２７にレコードを作成する（ステップＳ１３）。０であれば，売却対象日数がない旨のエラーメッセージを端末２に送信する（ステップＳ１４）。
【００５２】
図１２は，本実施の形態における売却対象日数算出処理フローチャートである。まず，売り手の端末２の登録画面上で選択された売却種別が，時効消滅売却であるのか，法定日数以上売却であるのかを確認し（ステップＳ１００），時効消滅売却である場合には，有給取得日数情報記憶部２５の売り手登録を行う従業員のレコードの消滅日数があるかを確認し（ステップＳ１０１），消滅日数があれば，その消滅日数を売却対象日数とする（ステップＳ１０２）。消滅日数がなければ，売却対象日数を０とする（ステップＳ１０３）。
【００５３】
ステップＳ１００において，法定日数以上売却である場合には，従業員基本情報記憶部２１の売り手登録を行う従業員のレコードの勤続年月で有給法定日数情報記憶部２６を参照して必須取得日数を取得する（ステップＳ１０４）。有給取得日数情報記憶部２５の売り手登録を行う従業員のレコードの総計日数から特別返却日数を引いたものが，必須取得日数を越えているかを確認し（ステップＳ１０５），必須取得日数を越えていなければ，売却対象日数を０とし（ステップＳ１０６），処理を終了する。
【００５４】
ステップＳ１０５において，必須取得日数を越えていれば，有給取得日数情報記憶部２５の売り手登録を行う従業員のレコードの総計日数から特別返却日数と必須取得日数とを引いた日数を売却可能日数とする（ステップＳ１０７）。
【００５５】
売却可能日数と有給取得日数情報記憶部２５の売り手登録を行う従業員のレコードの残日数とを比較し（ステップＳ１０８），残日数の方が小さければ，その残日数を売却可能日数とする（ステップＳ１０９）。
【００５６】
売り手の端末２の登録画面上で入力された日数が売却可能日数を越えているかを確認し（ステップＳ１１０），売却可能日数を越えていれば，入力された日数が売却可能日数を越えている旨のエラーメッセージを端末２に送信する（ステップＳ１１１）。売却可能日数を越えていなければ，入力された日数を売却対象日数とする（ステップＳ１１２）。
【００５７】
図１３は，本実施の形態における売り手の登録画面の例を示す図である。図１３（Ａ））の例は，売却種別として時効消滅売却が選択された場合の例であり，図１３（Ｂ）の例は，売却種別として法定日数以上売却が選択された場合の例である。
【００５８】
売却種別として時効消滅売却が選択された場合には，売却対象日数が自動的に計算される。図１３（Ａ）の例では，消滅日数が０だったため売却対象日数が０となり，売却対象日数がない旨のエラーメッセージが表示されている。売却種別として法定日数以上売却が選択された場合には，売却可能日数が自動的に計算され，売り手が希望する売却対象日数を入力する。図１３（Ｂ）の例では，売り手が入力した売却対象日数が売却可能日数を越えているため，売却可能日数を越えている旨のエラーメッセージが表示されている。
【００５９】
図１４は，本実施の形態における買い手登録処理フローチャートである。有給休暇を購入する従業員（買い手）は，自らの従業員番号を端末２に入力して有給休暇売買システム１へのログインを行い，買い手登録を要求する。なお，以下では，入力された従業員番号で個人を特定している。
【００６０】
買い手登録部１２は，端末２から買い手登録の要求を受けると（ステップＳ２０），買い手の端末２の登録画面上で入力された日数を，買取対象日数とする（ステップＳ２１）。
【００６１】
全労働日数に対する買取対象日数の割合があらかじめ定められた割合を越えているかを確認し（ステップＳ２２），越えていれば，全労働日数に対する入力された日数の割合があらかじめ定められた割合を越えている旨のエラーメッセージを端末２に送信する（ステップＳ２３）。
【００６２】
ステップＳ２２において，越えていなければ，その買取対象日数や，買い手の端末２の登録画面上で入力された買取理由などの買い手の情報を，承認者（例えば，買い手となる従業員の上司や人事部の担当責任者など）に回送する（ステップＳ２４）。
【００６３】
承認者からの承認が得られたかを確認し（ステップＳ２５），承認が得られていれば，買取対象日数を買い日数として，買い手情報記憶部２８にレコードを作成する（ステップＳ２６）。承認が得られていなければ，承認が得られなかった旨の通知を端末２に送信する（ステップＳ２７）。
【００６４】
図１５は，本実施の形態における買い手の登録画面の例を示す図である。有給休暇の買取を希望する従業員は，図１５に示す買い手の登録画面において，買取対象日数と買取理由を入力する。この例では，買取対象日数として「１００日」を入力しているが，全労働日数に対する入力された買取対象日数の割合があらかじめ定められた割合（例えば，２割）を越えているため，全労働日の２割を越えている旨のエラーメッセージが表示されている。
【００６５】
図１６は，本実施の形態における有給取得日数情報更新処理フローチャートである。有給取得日数情報更新部１３は，例えば年度替り時などに，有給取得日数情報記憶部２５の全従業員のレコードを更新する。ここでは，ある１人の従業員のレコードの更新に着目した処理の流れについて説明する。また，限度日数は，固定であるものとする。
【００６６】
有給取得日数情報更新部１３は，従業員基本情報記憶部２１のレコードの勤続年月をもとに有給法定日数情報記憶部２６から得られる有給法定日数と，当年度において会社が上乗せする有給休暇日数とから当年度における支払日数を求め，それを書き込む（ステップＳ３０）。残日数を繰越日数に書き込む（ステップＳ３１）。支払日数と繰越日数とを加算し，それを合計日数に書き込む（ステップＳ３２）。
【００６７】
合計日数と限度日数とを比較し（ステップＳ３３），合計日数が限度日数以上であれば，合計日数と限度日数との差を計算し，それを消滅日数に書き込む（ステップＳ３４）。限度日数を総計日数に書き込む（ステップＳ３５）。ステップＳ３３において，合計日数が限度日数より小さければ，消滅日数をクリアする（ステップＳ３６）。合計日数を総計日数に書き込む（ステップＳ３７）。
【００６８】
特別取得日数と特別返却日数とをクリアする（ステップＳ３８）。総計日数を残日数に書き込む（ステップＳ３９）。
【００６９】
図１７は，本実施の形態における売買マッチング処理フローチャートである。売買マッチング処理部１４は，売り手情報記憶部２７のレコードと買い手情報記憶部２８のレコードとを，それぞれ登録日時が早い順に並ぶようにソートする（ステップＳ４０）。また，買い手情報記憶部２８から，売り手特定済表示がない買い手のレコードを抽出する（ステップＳ４１）。
【００７０】
ステップＳ４１で抽出された買い手のレコードから登録日時が早い順に１件を選択し（ステップＳ４２），その選択された買い手のレコードの買い日数を日数カウンタに代入し，スキルカウンタに１を代入する（ステップＳ４３）。
【００７１】
売り手情報記憶部２７から，ステップＳ４２で選択された買い手のレコードと職種，等級が一致する売り手のレコードを抽出し（ステップＳ４４），さらに，その抽出された売り手のレコードから，「日数カウンタ≧売り日数」となる売り手のレコードを抽出する（ステップＳ４５）。
【００７２】
ステップＳ４５で抽出された売り手のレコードから，予約番号がない売り手のレコードを抽出する（ステップＳ４６）。また，ステップＳ４６で抽出された売り手のレコードから，スキルカウンタが示す優先度のスキルがステップＳ４２で選択された買い手のレコードのスキルカウンタが示す優先度のスキルと一致する売り手のレコードを抽出する（ステップＳ４７）。
【００７３】
ステップＳ４７で抽出された売り手のレコードから登録が早い順に１件を選択し（ステップＳ４８），その選択された売り手のレコードの売り日数が日数カウンタ以下であるかを確認し（ステップＳ４９），日数カウンタ以下でなければ，ステップＳ５３の処理に進む。
【００７４】
ステップＳ４９において，日数カウンタ以下であれば，日数カウンタからステップＳ４８で選択された売り手のレコードの売り日数を引いたものを新たな日数カウンタとし（ステップＳ５０），ステップ４８で選択された売り手のレコードの予約番号に，ステップＳ４２で選択された買い手のレコードの従業員番号を書き込む（ステップＳ５１）。日数カウンタが０であるかを確認し（ステップＳ５２），０であれば，ステップＳ５６の処理に進む。０でなければ，ステップＳ５３の処理に進む。
【００７５】
ステップＳ４９においてステップＳ４８で選択された売り手のレコードの売り日数が日数カウンタ以下でないか，または，ステップＳ５２において日数カウンタが０でなければ，ステップＳ４７で抽出されたすべての売り手のレコードについてマッチングを行ったかを確認し（ステップＳ５３），行っていなければ，ステップＳ４８の処理に戻る。すべてのマッチングを行っていれば，スキルカウンタに１を加算し（ステップＳ５４），スキルカウンタが３を越えているかを確認し（ステップＳ５５），３を越えていれば，ステップＳ５６の処理に進む。３を越えていなければ，ステップＳ４６の処理に戻る。
【００７６】
ステップＳ５２において日数カウンタが０であるか，または，ステップＳ５５においてスキルカウンタが３を越えていれば，ステップＳ４２で選択された買い手のレコードの売り手特定済表示に“あり”を書き込む（ステップＳ５６）。
【００７７】
ステップＳ４１で抽出されたすべての買い手のレコードについてマッチングを行ったかを確認し（ステップＳ５７），マッチングを行っていれば，処理を終了する。行っていなければ，ステップＳ４２の処理に戻る。
【００７８】
図１８〜図２３は，本実施の形態における売買マッチング処理の具体的な例を説明する図（１）〜（６）である。以下，図１７の売買マッチング処理フローチャートの流れに沿って，本実施の形態の売買マッチング処理の具体的な例を説明する。なお，図１８〜図２３に示す売り手情報記憶部２７のレコードは１日当り賃金と売却種別が省略されており，図１８〜図２３に示す買い手情報記憶部２８のレコードは１日当り賃金が省略されている。
【００７９】
図１８（Ａ）は，ステップＳ４０において登録日時が早い順にソートされた売り手情報記憶部２７のレコードの例である。また，図１８（Ｂ）は，ステップＳ４０において登録日時が早い順にソートされた買い手情報記憶部２８のレコードの例である。以下，図１８（Ａ），図１８（Ｂ）に示すレコードを用いて，本実施の形態における売買マッチング処理の流れを説明する。
【００８０】
ステップＳ４１において，図１８（Ｂ）に示す買い手情報記憶部２８のレコードから，売り手特定済表示がないレコードを抽出する。ここでは，図１８（Ｃ）に示すように，Ｍ氏，Ｎ氏のレコードが抽出される。
【００８１】
ステップＳ４２において，図１８（Ｃ）に示すレコードから，登録日時が早い順に１件のレコードを選択する。ここでは，図１９（Ａ）に示すように，Ｍ氏のレコードが選択される。ステップＳ４３において，図１９（Ａ）のレコードの買い日数（６日）を日数カウンタに代入し（日数カウンタ＝６），スキルカウンタに１を代入する（スキルカウンタ＝１）。
【００８２】
ステップＳ４４において，図１８（Ａ）に示す売り手情報記憶部２７のレコードから，図１９（Ｂ）（＝図１９（Ａ））に示すレコードと，職種（ＳＥ職），等級（４級）が一致するレコードを抽出する。ここでは，図１９（Ｃ）に示すように，Ａ氏，Ｃ氏，Ｅ氏，Ｇ氏，Ｉ氏，Ｊ氏のレコードが抽出される。
【００８３】
ステップＳ４５において，図１９（Ｃ）に示すレコードから，「日数カウンタ（＝６）≧売り日数」となるレコードを抽出する。ここでは，図１９（Ｄ）に示すように，Ｃ氏，Ｅ氏，Ｇ氏，Ｉ氏，Ｊ氏のレコードが抽出される。
【００８４】
ステップＳ４６において，図１９（Ｄ）に示すレコードから，予約番号がないレコードを抽出する。ここでは，図１９（Ｄ）に示すレコードがすべて予約番号がないレコードであるので，図２０（Ａ）に示すように，そのまま図１９（Ｄ）に示すレコードがすべて抽出される。
【００８５】
ステップＳ４７において，図２０（Ａ）に示すレコードから，図２０（Ｂ）（＝図１９（Ａ））に示すレコードと，スキルカウンタ（＝１）が示す優先度のスキル（優先度１スキル＝プラットフォーム）が一致するレコードを抽出する。ここでは，図２０（Ｃ）に示すように，Ｃ氏，Ｉ氏のレコードが抽出される。
【００８６】
ステップＳ４８において，図２０（Ｃ）に示すレコードから，登録日時が早い順に１件のレコードを選択する。ここでは，Ｃ氏のレコードが選択される。図２０（Ｄ）に示すように，選択されたＣ氏のレコードの売り日数（１日）が日数カウンタ（＝６）以下であるので（ステップＳ４９），日数カウンタ（＝６）からＣ氏のレコードの売り日数（１日）を引いて新たな日数カウンタ（＝５）とし（ステップＳ５０），選択されたＣ氏のレコードの予約番号に，図１９（Ａ）に示すＭ氏の従業員番号（７７７）を書き込む（ステップＳ５１）。
【００８７】
日数カウンタ（＝５）はまだ０ではなく（ステップＳ５２），図２０（Ｃ）に示すレコードにまだマッチングを行っていないレコードがあるので（ステップＳ５３），ステップＳ４８において，図２０（Ｃ）に示すレコードから，次に登録日時が早いレコードを１件選択する。ここでは，Ｉ氏のレコードが選択される。図２０（Ｅ）に示すように，選択されたＩ氏のレコードの売り日数（２日）が日数カウンタ（＝５）以下であるので（ステップＳ４９），日数カウンタ（＝５）からＩ氏のレコードの売り日数（２日）を引いて新たな日数カウンタ（＝３）とし（ステップＳ５０），選択されたＩ氏のレコードの予約番号に，図１９（Ａ）に示すＭ氏の従業員番号（７７７）を書き込む（ステップＳ５１）。
【００８８】
日数カウンタ（＝３）はまだ０ではないが（ステップＳ５２），図２０（Ｃ）に示すレコードにマッチングを行っていないレコードがないので（ステップＳ５３），ステップＳ５４において，スキルカウンタに１を加算する（スキルカウンタ＝２）。
【００８９】
スキルカウンタ（＝２）はまだ３を越えていないので（ステップＳ５５），ステップＳ４６において，図１９（Ｄ）に示すレコードから，予約番号がないレコードを再度抽出する。ここでは，図２１（Ａ）に示すように，すでに予約番号が書き込まれたＣ氏（図２０（Ｄ）），Ｉ氏（図２０（Ｅ））のレコードを図１９（Ｄ）に示すレコードから除き，Ｅ氏，Ｇ氏，Ｊ氏のレコードが抽出される。
【００９０】
ステップＳ４７において，図２１（Ａ）に示すレコードから，図２１（Ｂ）（＝図１９（Ａ））に示すレコードと，スキルカウンタ（＝２）が示す優先度のスキル（優先度２スキル＝アプリケーション）が一致するレコードを抽出する。ここでは，図２１（Ｃ）に示すように，Ｅ氏，Ｊ氏のレコードが抽出される。
【００９１】
ステップＳ４８において，図２１（Ｃ）に示すレコードから，登録日時が早い順に１件のレコードを選択する。ここでは，Ｅ氏のレコードが選択される。図２１（Ｄ）に示すように，選択されたＥ氏のレコードの売り日数（１日）が日数カウンタ（＝３）以下であるので（ステップＳ４９），日数カウンタ（＝３）からＥ氏のレコードの売り日数（１日）を引いて新たな日数カウンタ（＝２）とし（ステップＳ５０），選択されたＥ氏のレコードの予約番号に，図１９（Ａ）に示すＭ氏の従業員番号（７７７）を書き込む（ステップＳ５１）。
【００９２】
日数カウンタ（＝２）はまだ０ではなく（ステップＳ５２），図２１（Ｃ）に示すレコードにまだマッチングを行っていないレコードがあるので（ステップＳ５３），ステップＳ４８において，図２１（Ｃ）に示すレコードから，次に登録日時が早いレコードを１件選択する。ここでは，Ｊ氏のレコードが選択される。図２１（Ｅ）に示すように，選択されたＪ氏のレコードの売り日数（３日）が日数カウンタ（＝２）より大きいので（ステップＳ４９），選択されたＪ氏のレコードの予約は行わない。
【００９３】
図２１（Ｃ）に示すレコードにマッチングを行っていないレコードがないので（ステップＳ５３），ステップＳ５４において，スキルカウンタに１を加算する（スキルカウンタ＝３）。
【００９４】
スキルカウンタ（＝３）はまだ３を越えていないので（ステップＳ５５），ステップＳ４６において，図１９（Ｄ）に示すレコードから，予約番号がないレコードを再度抽出する。ここでは，図２２（Ａ）に示すように，すでに予約番号が書き込まれたＣ氏（図２０（Ｄ）），Ｅ氏（図２１（Ｄ）），Ｉ氏（図２０（Ｅ））のレコードを図１９（Ｄ）に示すレコードから除き，Ｇ氏，Ｊ氏のレコードが抽出される。
【００９５】
ステップＳ４７において，図２２（Ａ）に示すレコードから，図２２（Ｂ）（＝図１９（Ａ））に示すレコードと，スキルカウンタ（＝３）が示す優先度のスキル（優先度３スキル＝データベース）が一致するレコードを抽出する。ここでは，図２２（Ｃ）に示すように，Ｇ氏のレコードが抽出される。
【００９６】
ステップＳ４８において，図２２（Ｃ）に示すレコードにはＧ氏のレコード１件しかないので，Ｇ氏のレコードを選択する。図２２（Ｄ）に示すように，選択されたＧ氏のレコードの売り日数（１日）が日数カウンタ（＝２）以下であるので（ステップＳ４９），日数カウンタ（＝２）からＧ氏のレコードの売り日数（１日）を引いて新たな日数カウンタ（＝１）とし（ステップＳ５０），選択されたＧ氏のレコードの予約番号に，図１９（Ａ）に示すＭ氏の従業員番号（７７７）を書き込む（ステップＳ５１）。
【００９７】
日数カウンタ（＝１）はまだ０ではないが（ステップＳ５２），図２２（Ｃ）に示すレコードにマッチングを行っていないレコードがないので（ステップＳ５３），ステップＳ５４において，スキルカウンタに１を加算する（スキルカウンタ＝４）。
【００９８】
スキルカウンタ（＝４）が３を越えているので（ステップＳ５５），ステップＳ５６において，図２２（Ｅ）に示すように，図１９（Ａ）に示すレコードの売り手特定済表示に“あり”を書き込む。
【００９９】
図１８（Ｃ）に示すレコードにまだマッチングを行っていないレコードがあるので（ステップＳ５７），ステップＳ４２において，図１８（Ｃ）に示すレコードから，次に登録日時が早いレコードを１件選択する。ここでは，図２２（Ｆ）に示すように，Ｎ氏のレコードが選択される。以下，図１９（Ａ）に示すレコードの場合と同様に，図２２（Ｆ）に示すレコードについて，ステップＳ４３〜Ｓ５６の処理を行う。
【０１００】
図１９（Ａ）に示すレコードに対する売買マッチング処理後（図２２（Ｆ）に示すレコードに対する売買マッチング処理前）の売り手情報記憶部２７のレコード，買い手情報記憶部２８のレコードは，それぞれ図２３（Ａ），図２３（Ｂ）に示す通りとなる。
【０１０１】
有給休暇の買い手であるＭ氏からの６日の有給休暇の購入の希望に対して，以上の売買マッチング処理により，有給休暇の売り手であるＣ氏（１日），Ｅ氏（１日），Ｇ氏（１日），Ｉ氏（２日）からの合計５日の有給休暇の売却の希望がマッチした。この後，Ｍ氏は，合意判断を行う。
【０１０２】
図２４は，本実施の形態における買い手合意処理フローチャートである。買い手登録を行っていた従業員（買い手）は，自らの従業員番号を端末２に入力して有給休暇売買システム１へのログインを行い，売買マッチング処理の結果に対する合意判断を行う。なお，以下では，入力された従業員番号で個人を特定している。
【０１０３】
買い手合意処理部１５は，端末２から売買マッチング処理の結果の要求を受けると（ステップＳ６０），売り手情報記憶部２７から，予約番号がログイン時に入力された従業員番号と一致する売り手のレコードを抽出する（ステップＳ６１）。
【０１０４】
ステップＳ６１で抽出された売り手のレコードがあるかを確認し（ステップＳ６２），抽出された売り手のレコードがなければ，まだ売り手が見つかっていない旨のメッセージを端末２に送信し（ステップＳ６３），買い手情報記憶部２８の該当する買い手のレコードの売り手特定済表示をクリアし（ステップＳ６４），処理を終了する。
【０１０５】
ステップＳ６２において，抽出された売り手のレコードがあれば，その抽出されたすべての売り手のレコードについて，１日当り賃金と売り日数とを買い手の端末２に送信する（ステップＳ６５）。
【０１０６】
買い手の端末２の合意画面上で“合意する”と入力されたか“合意しない”と入力されたかを確認し（ステップＳ６６），“合意しない”と入力されていれば，買い手情報記憶部２８の該当する買い手のレコードの売り手特定済表示をクリアし（ステップＳ６７），売り手情報記憶部２７のステップＳ６１で抽出されたすべての売り手のレコードの予約番号をクリアし（ステップＳ６８），処理を終了する。
【０１０７】
ステップＳ６６において，“合意する”と入力されていれば，有給休暇売買処理を行う（ステップＳ６９）。
【０１０８】
図２５は，本実施の形態における有給休暇売買処理フローチャートである。まず，ステップＳ６１で抽出されたすべての売り手のレコードの売り日数の合計を，有給取得日数情報記憶部２５の該当する買い手のレコードの特別取得日数と残日数とに加算する（ステップＳ６００）。また，ステップＳ６１で抽出されたすべての売り手のレコードの売り日数に１日当り賃金を掛けた金額の合計を，買い手が支払う金額として，担当者（経理など）に通知する（ステップＳ６０１）。また，買い手情報記憶部２８から該当する買い手のレコードを削除する（ステップＳ６０２）。
【０１０９】
ステップＳ６１で抽出された売り手のレコードから１件を選択する（ステップＳ６０３）。選択された売り手のレコードの売却種別が，時効消滅売却であるのか，法定日数以上売却であるのかを確認し（ステップＳ６０４），時効消滅売却である場合には，選択された売り手のレコードの売り日数を，有給取得日数情報記憶部２５の該当する売り手のレコードの消滅日数から減算する（ステップＳ６０５）。法定日数以上売却である場合には，選択された売り手のレコードの売り日数を有給取得日数情報記憶部２５の該当する売り手のレコードの残日数から減算し（ステップＳ６０６），選択された売り手のレコードの売り日数を有給取得日数情報記憶部２５の該当する売り手のレコードの特別返却日数に加算する（ステップＳ６０７）。
【０１１０】
ステップＳ６０３で選択された売り手のレコードの売り日数に１日当り賃金を掛けた金額を，売り手への振込み金額として，担当者（経理など）に通知する（ステップＳ６０８）。また，売り手情報記憶部２７から該当する売り手のレコードを削除する（ステップＳ６０９）。
【０１１１】
ステップＳ６１で抽出されたすべての売り手のレコードについてステップＳ６０４〜Ｓ６０９の処理を行ったかを確認し（ステップＳ６１０），行っていなければ，ステップＳ６０３の処理に戻る。行っていれば，処理を終了する。
【０１１２】
図２６は，本実施の形態における買い手の合意画面の例を示す図である。図２６（Ａ））の例は，売買マッチング処理により売り手が見つかった場合の例であり，図２６（Ｂ）の例は，売買マッチング処理によりまだ売り手が見つからない場合の例である。
【０１１３】
図２６（Ａ）に示すように，売り手が見つかった場合には，見つかったすべての売り手について，１日当り賃金と売り日数が表示される。また，すべての売り手の１日当り賃金と売り日数とを掛けた金額の合計が表示される。買い手は，このような画面で合意判断を行う。
【０１１４】
図２６（Ｂ）に示すように，まだ売り手が見つからない場合には，その旨を画面に表示し，後日，再度合意判断を行うように促す。
【０１１５】
図２７は，本実施の形態の有給休暇売買システムにより得られる効果の評価を示す図である。以上説明した本実施の形態の有給休暇売買システム１を導入することによる効果は，図２７に示すように評価することができる。
【０１１６】
有給休暇の売り手（例えば，忙しい部署の人など）は，自分の有給休暇を失うことにより，相当の賃金（売り手の賃金）を代価として得ることができる。これにより，有給休暇を犠牲にして働いている従業員の会社に対する貢献が，金銭で報われるようになる。また，有給休暇を犠牲にして働いている従業員からの有給休暇を十分に取っている従業員に対する不公平感が解消される。
【０１１７】
有給休暇売買システム１により有給休暇の売買の仲介を行う会社は，有給休暇の買い手の労働力を代償として，有給休暇の売り手の労働力を得ることができる。本実施の形態における有給休暇売買システム１では，売り手と買い手との職種，等級などの条件をマッチングしているので，売り手の労働力と買い手の労働力とがほぼ同じであると考えられるため，会社が得るものと失うものとの差はほとんどないものと思われる。
【０１１８】
しかし，買い手の労働力がもともと期待できない場合などもあるので，会社は，期待ができる売り手の労働力が得られる分だけ得をすることとなる。また，有給休暇の売買を福利厚生のプランとして採用することにより，有給休暇の売り手と買い手の双方の従業員の満足度を向上させることができる。
【０１１９】
有給休暇の買い手（例えば，暇な部署の人，やむを得ない理由で長期休暇を取る人など）は，売り手の賃金を代価として支払うことにより，有給休暇を得ることができる。これにより，長期休暇が必要な従業員にとって長期に渡って欠勤するより長期の有給休暇を取る方が解雇の不安がないため，従業員の不安感を取り除くことができる。
【０１２０】
以上，本発明の実施の形態について説明したが，本発明はこれに限られるものではない。例えば，本実施の形態では売り手も買い手も売り手の賃金で有給休暇の売買を行っているが，売り手が売り手の賃金で有給休暇を売却し，買い手が買い手の賃金で有給休暇を購入するようにしてもよい。
【０１２１】
また，労働力と賃金とがほぼ一致するようにマッチングを行うことができるのであれば，売買マッチング処理時の条件を任意に変えてもよい。例えば，売り手と買い手の１日当り賃金の格差を一定の範囲内に定める条件があってもよいし，優先度に関係ないスキルのマッチングを条件としてもよい。
【０１２２】
また，例えば，本実施の形態では，買い手の合意判断により有給休暇売買処理を行っているが，買い手の合意判断を行わずに，自動的に条件がマッチした売り手と買い手との間の有給休暇売買処理を行うようにしてもよい。
【０１２３】
また，例えば，本実施の形態では，１人または複数人の売り手と１人の買い手とのマッチングを行っているが，１人または複数人の売り手と１人または複数人の買い手とのマッチングを行うようにしてもよい。
【図面の簡単な説明】
【０１２４】
【図１】本発明の実施の形態における有給休暇売買システムの構成例を示す図である。
【図２】本実施の形態における従業員基本情報記憶部のデータ構成例を示す図である。
【図３】本実施の形態における職種情報記憶部のデータ構成例を示す図である。
【図４】本実施の形態における等級情報記憶部のデータ構成例を示す図である。
【図５】本実施の形態におけるスキル情報記憶部のデータ構成例を示す図である。
【図６】本実施の形態における有給取得日数情報記憶部のデータ構成例を示す図である。
【図７】本実施の形態における有給法定日数情報記憶部のデータ構成例を示す図である。
【図８】本実施の形態のおける売り手情報記憶部のデータ構成例を示す図である。
【図９】本実施の形態における買い手情報記憶部のデータ構成例を示す図である。
【図１０】本実施の形態における有給休暇売買の全体の流れを説明する図である。
【図１１】本実施の形態における売り手登録処理フローチャートである。
【図１２】本実施の形態における売却対象日数算出処理フローチャートである。
【図１３】本実施の形態における売り手の登録画面の例を示す図である。
【図１４】本実施の形態における買い手登録処理フローチャートである。
【図１５】本実施の形態における買い手の登録画面の例を示す図である。
【図１６】本実施の形態における有給取得日数情報更新処理フローチャートである。
【図１７】本実施の形態における売買マッチング処理フローチャートである。
【図１８】本実施の形態における売買マッチング処理の具体的な例を説明する図（１）である。
【図１９】本実施の形態における売買マッチング処理の具体的な例を説明する図（２）である。
【図２０】本実施の形態における売買マッチング処理の具体的な例を説明する図（３）である。
【図２１】本実施の形態における売買マッチング処理の具体的な例を説明する図（４）である。
【図２２】本実施の形態における売買マッチング処理の具体的な例を説明する図（５）である。
【図２３】本実施の形態における売買マッチング処理の具体的な例を説明する図（６）である。
【図２４】本実施の形態における買い手合意処理フローチャートである。
【図２５】本実施の形態における有給休暇売買処理フローチャートである。
【図２６】本実施の形態における買い手の合意画面の例を示す図である。
【図２７】本実施の形態の有給休暇売買システムにより得られる効果の評価を示す図である。
【符号の説明】
【０１２５】
１    有給休暇売買システム
２    端末
３    ネットワーク
１０  売買制御部
１１  売り手登録部
１２  買い手登録部
１３  有給取得日数情報更新部
１４  売買マッチング処理部
１５  買い手合意処理部
２０  情報記憶部
２１  従業員基本情報記憶部
２２  職種情報記憶部
２３  等級情報記憶部
２４  スキル情報記憶部
２５  有給取得日数情報記憶部
２６  有給法定日数情報記憶部
２７  売り手情報記憶部
２８  買い手情報記憶部
【図１】
2005309949.tif 000003
【図２】
2005309949.tif 000004
【図３】
2005309949.tif 000005
【図４】
2005309949.tif 000006
【図５】
2005309949.tif 000007
【図６】
2005309949.tif 000008
【図７】
2005309949.tif 000009
【図８】
2005309949.tif 000010
【図９】
2005309949.tif 000011
【図１０】
2005309949.tif 000012
【図１１】
2005309949.tif 000013
【図１２】
2005309949.tif 000014
【図１３】
2005309949.tif 000015
【図１４】
2005309949.tif 000016
【図１５】
2005309949.tif 000017
【図１６】
2005309949.tif 000018
【図１７】
2005309949.tif 000019
【図１８】
2005309949.tif 000020
【図１９】
2005309949.tif 000021
【図２０】
2005309949.tif 000022
【図２１】
2005309949.tif 000023
【図２２】
2005309949.tif 000024
【図２３】
2005309949.tif 000025
【図２４】
2005309949.tif 000026
【図２５】
2005309949.tif 000027
【図２６】
2005309949.tif 000028
【図２７】
2005309949.tif 000029