知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-19
(45)【発行日】2024-08-27
(54)【発明の名称】仲介サーバ
(51)【国際特許分類】
G06Q 30/06 20230101AFI20240820BHJP
G06Q 50/10 20120101ALI20240820BHJP
【ＦＩ】
G06Q30/06
G06Q50/10
【請求項の数】
11
(21)【出願番号】P 2020117783
(22)【出願日】2020-07-08
(65)【公開番号】P2022015127
(43)【公開日】2022-01-21
【審査請求日】2023-07-07
(73)【特許権者】
【識別番号】520200229
【氏名又は名称】江端 一将
(74)【代理人】
【識別番号】100138221
【弁理士】
【氏名又は名称】影山 剛士
(72)【発明者】
【氏名】江端 一将
【審査官】塩田 徳彦
(56)【参考文献】
【文献】特開２００３－１３２１５４（ＪＰ，Ａ）
【文献】特開２００５－１９０４５２（ＪＰ，Ａ）
【文献】特許第６７１３５８８（ＪＰ，Ｂ１）
【文献】国際公開第２０２０／０６６３９９（ＷＯ，Ａ１）
【文献】特開２００７－２００２１０（ＪＰ，Ａ）
【文献】特開２００６－３４４１４８（ＪＰ，Ａ）
【文献】就活ブログ｜就活塾で学ぶ大手内定100の方法 成績が悪い…就活での影響と、成績証明書の重要度について，［online］，2020年01月14日，［2024年4月26日検索］，＜ＵＲＬ：https://naitei-lab.com/blog/seisekisyoumeisyo-syukatsu/＞
【文献】さっぽろ圏奨学金返還支援事業を実施します！，［online］，2020年05月22日，［2024年4月26日検索］，＜ＵＲＬ：https://web.archive.org/web/20200529093733/https://www.city.sapporo.jp/keizai/koyo/syougakukin/syougakukin.html＞
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００－９９／００
(57)【特許請求の範囲】
【請求項1】
教育機関で管理されている求職者の入学から卒業に至るまでの人材情報を少なくとも格納するデータベースと、求人者に関連する求人者端末と、前記求職者に関連する求職者端末とをネットワークを介して仲介する仲介サーバであって、前記求人者端末から、前記求人者の希望条件を示す求人者希望条件情報を受信する求人者希望条件受信部と、
前記求人者希望条件受信部が受信した求人者希望条件情報と、前記データベースに含まれる人材情報とを照合して、前記求人者の希望条件に合致する求職者を検索する求職者検索処理部と、を備え、
前記人材情報は、前記求職者がどの教育機関を受験し、合格したかを示す情報を含む、
仲介サーバ。
【請求項2】
請求項１に記載の仲介サーバであって、前記求職者検索処理部が検索した求職者に関する情報を基に、前記求人者端末に一覧で表示可能な求職者データを生成して前記求人者端末へ送信する求人者表示処理部を備える、
仲介サーバ。
【請求項3】
請求項１又は請求項２に記載の仲介サーバであって、前記求人者からの送信要求に応答して、前記求職者検索処理部が検索した求職者に関連する求職者端末に、求人者から求職者への逆オファーに関する情報である逆オファー情報の送信処理を行う逆オファー情報送信部を備える、
仲介サーバ。
【請求項4】
請求項１乃至請求項３の何れか一項に記載の仲介サーバであって、前記人材情報には、前記求職者の成績又は属性を履歴または時系列で管理可能な情報が含まれる、
仲介サーバ。
【請求項5】
請求項４に記載の仲介サーバであって、前記人材情報には、資格の有無、前記教育機関に在籍中の成績の伸び具合、前記教育機関に在籍中の素行面の良し悪し、メンタルストレスに対する強度が含まれる、
仲介サーバ。
【請求項6】
請求項１に記載の仲介サーバであって、前記データベースには、さらに、前記求人者の特性を示す特性情報が含まれており、
前記求職者端末から、前記求職者の希望条件を示す求職者希望条件情報を受信する求職者希望条件受信部と、
前記求職者希望条件受信部が受信した求職者希望条件情報と、前記データベースに含まれる特性情報とを照合して、前記求職者の希望条件に合致する求人者を検索する求人者検索処理部と、を備える、
仲介サーバ。
【請求項7】
請求項６に記載の仲介サーバであって、前記求人者検索処理部が検索した求人者に関する情報を基に、前記求職者端末に一覧で表示可能な求人者データを生成して前記求職者端末へ送信する求職者表示処理部を備える、
仲介サーバ。
【請求項8】
請求項６又は請求項７に記載の仲介サーバであって、前記求職者からの送信要求に応答して、前記求人者検索処理部が検索した求人者に関連する求人者端末に、求職者から求人者へのオファーに関する情報であるオファー情報の送信処理を行うオファー情報送信部を備える、
仲介サーバ。
【請求項9】
請求項６乃至請求項８の何れか一項に記載の仲介サーバであって、前記特性情報には、少なくとも配属先又は給与体系が含まれる、
仲介サーバ。
【請求項10】
請求項１乃至請求項９の何れか一項に記載の仲介サーバであって、前記人材情報には、前記求職者の入学から卒業に至るまでの成績情報が含まれ、
前記成績情報の被提示者には、前記求職者及び当該求職者の親権者が含まれる、
仲介サーバ。
【請求項11】
請求項１乃至請求項１０の何れか一項に記載の仲介サーバであって、前記教育機関又は前記求職者に対する前記求人者の入金及び出金に関する決済を代行する決済代行部を備える、
仲介サーバ。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、求人者に関連する求人者端末と、求職者に関連する求職者端末とをネットワークを介して仲介する仲介サーバに関する。
【背景技術】
【0002】
従来、求職者と求人者（求人企業）とのマッチングに関するサービスが普及している。
【0003】
例えば、特許文献１に示すような従来のマッチングシステムにおいては、医学生を求める医療機関と就職先を求める医学生とが夫々希望条件又は各種情報をサーバに登録したうえで、サーバが互いの条件に合致するものを抽出する構成が開示されている。
【先行技術文献】
【特許文献】
【0004】
【文献】特許２０１６－８５６２４号
【発明の概要】
【発明が解決しようとする課題】
【0005】
昨今では、業種に関わらず、求人者と求職者のマッチングにおいて、その高いマッチング精度が求められており、特に、医療業界においては、従来医学生が医療機関に就職する方法として学校推薦による割合が高く、医療機関としては、医療機関に適合する医学生を広く探したいという傾向がある。その際に、医療機関と医学生のマッチングの精度を高めるためには、医学生が教育機関を卒業した時点だけの情報だけでは情報量として不十分である。例えば、教育機関に在籍中における医学生の成績の伸び具合など、ある程度まで時間を遡った情報を加味して採用の可否が判断されることが好ましい。ところが、特許文献１では、医学生が教育機関を卒業した時点における、医学生に関する情報のみを用いて、医療機関と医学生とのマッチングが行われるので、より優れた医学生を欲する医療機関の要望に応えることが難しかった。
【0006】
そこで、本発明は、求職者に関する情報をより充実させて、就職を希望する求職者と、就職先である求人者との適合性を高めることを目的とする。
【課題を解決するための手段】
【0007】
本発明の一態様における仲介サーバは、教育機関で管理されている求職者の入学から卒業に至るまでの人材情報を少なくとも格納するデータベースと、求人者に関連する求人者端末と、前記求職者に関連する求職者端末とをネットワークを介して仲介する仲介サーバであって、前記求人者端末から、前記求人者の希望条件を示す求人者希望条件情報を受信する求人者希望条件受信部と、前記希望条件受信部が受信した求人者希望条件情報と、前記データベースに含まれる人材情報とを照合して、前記求人者の希望条件に合致する求職者を検索する求職者検索処理部と、を備える。
【発明の効果】
【0008】
本発明によれば、求職者に関する情報をより充実させることができ、ひいては、就職を希望する求職者と、就職先である求人者との適合性を高めることができる。
【図面の簡単な説明】
【0009】
【図1】本発明の第一実施形態に係るマッチングシステムを示すブロック構成図である。
【図6】本発明の第一実施形態に係る、マッチング方法に係るフローチャートの一例である。
【図7】本発明の第二実施形態に係るマッチングシステムを示すブロック構成図である。
【図11】志願者端末に表示される更新通知ページを示した画面構成例である。
【図12】志願者端末に表示される一覧ページを示した画面構成例である。
【図13】本発明の第二実施形態に係る、マッチング方法に係るフローチャートの一例である。
【図14】本発明の第三実施形態に係るマッチングシステムを示すブロック構成図である。
【図15】本発明の第三実施形態に係る、マッチング方法に係る概略説明図である。
【図16】医師情報ＤＢ２００又は求人情報ＤＢ３００におけるデータ登録のフローチャートである。
【図17】医師がマッチングシステム３を使用する場合のマッチング方法に係るフローチャートである。
【発明を実施するための形態】
【0010】
以下、本発明の実施形態について図面を参照して説明する。なお、以下に説明する実施形態は、特許請求の範囲に記載された本開示の内容を不当に限定するものではない。また、実施形態に示される構成要素のすべてが、本開示の必須の構成要素であるとは限らない。
【0011】
（実施形態１）
＜構成＞
図１は、本発明の第一実施形態に係るマッチングシステムを示すブロック構成図である。本システム１は、求職者である学生の就職活動を支援する就職活動管理システムであり、ネットワークＮＷを介して就職情報又は各種手続き（会社説明会の申し込みなど）を仲介する会員登録制の就職情報サイトを提供する機能に加えて、会員である学生の就職活動に関する情報を当該学生の所属する教育機関（例えば、高等学校、高等専門学校、専門学校、短期大学、四年制大学、大学院など、文部科学省に登録されている学校）の端末に提供する機能を有する。
＜構成＞
図１は、本発明の第一実施形態に係るマッチングシステムを示すブロック構成図である。本システム１は、求職者である学生の就職活動を支援する就職活動管理システムであり、ネットワークＮＷを介して就職情報又は各種手続き（会社説明会の申し込みなど）を仲介する会員登録制の就職情報サイトを提供する機能に加えて、会員である学生の就職活動に関する情報を当該学生の所属する教育機関（例えば、高等学校、高等専門学校、専門学校、短期大学、四年制大学、大学院など、文部科学省に登録されている学校）の端末に提供する機能を有する。
【0012】
ここで、本発明の実施形態における仲介サーバ４００が提供する会員登録制の就職情報サイトの機能例について説明する。この就職情報サイトでは、学生が登録を行うと、各学生にログイン用のユーザＩＤとパスワードＰＷが付与される。学生は、登録以後、ログイン画面にて付与されたユーザＩＤとパスワードＰＷを入力することで、就職情報サイトにおける種々のサービスを受けることが可能となる。就職情報サイトは求職者端末のウェブブラウザまたはアプリケーションを介して提供されることができる。
【0013】
学生は、例えば、各企業の採用情報を閲覧したり各企業に対して資料請求を行ったり、各企業の会社説明会への参加を申し込んだりすることができる。また、企業によっては、採用試験又は面接の申し込みを就職情報サイトで受け付けるサービス、合格通知を就職情報サイトで行うサービスを利用することもあり得る。ここで、学生の親権者は、図示しない親権者端末より学生と同じユーザＩＤとパスワードＰＷもしくは親権者専用のユーザＩＤとパスワードＰＷにより就職情報サイトにログインすることができ、学生の就職情報サイトにおける全部または一部の行動履歴を閲覧ができることとしてもよい。
【0014】
マッチングシステム１は、図１に示すように、データベースＤＢ１００と、求人者に関連する求人者端末２００と、求職者に関連する求職者端末３００と、仲介サーバ４００と、により構成される。
【0015】
データベースＤＢ１００と、求人者端末２００と、求職者端末３００と、仲介サーバ４００とは、ネットワークＮＷを介して接続される。ネットワークＮＷは、インターネット、イントラネット、無線ＬＡＮ（Local Area Network）又はＷＡＮ（Wide Area Network）等により構成される。
【0016】
求人者端末２００は、上述の通り、人材の採用活動を行う求人者である各企業の採用担当者に関連する端末である。求人者端末２００は、例えば、パーソナルコンピュータ又はタブレット端末等の情報処理装置であるが、スマートフォン、携帯電話、ＰＤＡ等により構成しても良い。各企業の採用担当者は、この求人者端末２００を利用して、仲介サーバ４００が提供する就職情報サイトに採用情報の登録を行う。なお、この就職情報サイトは、上述したように、企業の会社説明会の参加申し込みの受け付け、採用試験の申し込みの受け付けなどの機能を有し、各企業の採用担当者はこれら機能を利用可能となる。また、企業側に学生が採用情報の配信を希望する旨を伝える（エントリーする）ことで、当該企業は会社説明会の開催に関する情報又は採用情報を任意のタイミングで学生に配信可能となる。
【0017】
求職者端末３００は、就職を希望する求職者である学生に関連する端末である。求職者端末３００は、例えば、パーソナルコンピュータ又はタブレット端末等の情報処理装置であるが、スマートフォン、携帯電話、ＰＤＡ等により構成しても良い。学生は、この求職者端末３００を利用して、上述した就職情報サイトにアクセスする。
【0018】
仲介サーバ４００は、データベースＤＢ１００と、求人者端末２００と、求職者端末３００とを仲介する。仲介サーバ４００は、上述した就職情報サイトで収集した情報を利用して、求人者と求職者とのマッチング処理を行う装置である。仲介サーバ４００は、例えば、ワークステーション又はパーソナルコンピュータのような汎用コンピュータとしてもよいし、或いはクラウド・コンピューティングによって論理的に実現されてもよい。本実施形態においては、説明の便宜上仲介サーバとして１台を例示しているが、これに限定されず、複数台であってもよい。
【0019】
昨今では、特に、医療業界において、医療機関と医学生とのより高いマッチングの精度が求められている。マッチングの精度を高めるためには、医学生が教育機関を卒業した時点だけの情報だけでは情報量として不十分である。例えば、教育機関に在籍中における医学生の成績の伸び具合など、ある程度まで時間を遡った情報を加味して採用の可否が判断されることが好ましい。ところが、従来のシステムでは、医学生が教育機関を卒業した時点における、医学生に関する情報のみを用いて、医療機関と医学生とのマッチングが行われるので、より優れた医学生を欲する医療機関の要望に応えることが難しかった。ここで、「医療機関」とは、例えば、２０床以上のベッドを有する病院の他、１９床以下のベッドしか有さない診療所または医院若しくはクリニック等の医療サービスを提供可能な機関を指し、常勤・非常勤を問わずに医師が勤務している機関である。医療機関では医師を雇用しており、不足の医師を補うために、医学生（医師）の求人を行うものである。
【0020】
そこで、本実施形態においては、医療系の教育機関で管理されている求職者の入学から卒業に至るまでの人材情報を用いて、医療機関と医学生とのマッチングを行うことができるようにした。なお、当該人材情報の詳細については後述する。
【0021】
次に、図１に示したデータベースＤＢ１００並びに仲介サーバ４００の機能構成について説明する。
【0022】
＜データベースＤＢ１００＞
図１に示すように、データベースＤＢ１００は、学生情報ＤＢ１１１と、採用情報ＤＢ１１２と、を備える。
図１に示すように、データベースＤＢ１００は、学生情報ＤＢ１１１と、採用情報ＤＢ１１２と、を備える。
【0023】
＜学生情報ＤＢ＞
学生情報ＤＢ１１１は、学生に関する情報（当該学生の就職希望又は就職活動に関する情報を含む）である学生情報を管理するためのデータベースである。学生情報のうち後述する人材情報を除いた情報は、例えば、求職者端末３００はもちろんのこと、学生の所属する教育機関に設置されている端末からもネットワークＮＷを介してアップロード可能である。図２は、図１に示した学生情報ＤＢ１１１の詳細なデータ構成例を示す説明図である。図２に示すように、学生情報は、例えば、学生を一意に特定する識別子である「ユーザＩＤ」に関連づけて以下の情報を格納する。
学生情報ＤＢ１１１は、学生に関する情報（当該学生の就職希望又は就職活動に関する情報を含む）である学生情報を管理するためのデータベースである。学生情報のうち後述する人材情報を除いた情報は、例えば、求職者端末３００はもちろんのこと、学生の所属する教育機関に設置されている端末からもネットワークＮＷを介してアップロード可能である。図２は、図１に示した学生情報ＤＢ１１１の詳細なデータ構成例を示す説明図である。図２に示すように、学生情報は、例えば、学生を一意に特定する識別子である「ユーザＩＤ」に関連づけて以下の情報を格納する。
【0024】
「氏名」は、「ユーザＩＤ」で特定される学生の氏名である。「学校名」は、「ユーザＩＤで特定される学生が所属する学校の名前である。「専攻」は、「ユーザＩＤ」で特定される学生が所属する学部又は学科の名前である。
【0025】
「希望業種」は、「ユーザＩＤ」で特定される学生が就職を希望する業種に関する情報である。「希望職種」は、「ユーザＩＤ」で特定される学生が就職を希望する職種に関する情報である。「希望勤務地」は、「ユーザＩＤ」で特定される学生が就職を希望する勤務地に関する情報である。「企業名」は、「ユーザＩＤ」で特定される学生が就職を希望する企業名に関する情報である。
【0026】
＜人材情報＞
人材情報は、例えば、学生の所属する教育機関で管理されている学校端末（不図示）から吸い上げた情報である。人材情報の取得方法の一つには、学校側担当者が仲介サーバ４００により提供されるホームページの所定のウェブ画面にアクセスしてユーザＩＤおよびパスワードを入力することにより認証され、人材情報を入力並びにその入力内容を学生情報ＤＢ１１１にアップロードできる構成とすることができる。人材情報の取得方法のもう一つには、求人者端末２００を構成するローカルサーバ等から例えばＣＳＶ（Comma Separated Value）形式等により人材情報をダウンロードして、その人材情報を学生情報ＤＢ１１１にアップロードできる構成とすることができる。さらなる別の取得方法として、教育機関以外の第三者が人材情報を管理している場合も想定され、この場合には、例えばＡＰＩ経由で人材情報が第三者から取得されてもよい。
人材情報は、例えば、学生の所属する教育機関で管理されている学校端末（不図示）から吸い上げた情報である。人材情報の取得方法の一つには、学校側担当者が仲介サーバ４００により提供されるホームページの所定のウェブ画面にアクセスしてユーザＩＤおよびパスワードを入力することにより認証され、人材情報を入力並びにその入力内容を学生情報ＤＢ１１１にアップロードできる構成とすることができる。人材情報の取得方法のもう一つには、求人者端末２００を構成するローカルサーバ等から例えばＣＳＶ（Comma Separated Value）形式等により人材情報をダウンロードして、その人材情報を学生情報ＤＢ１１１にアップロードできる構成とすることができる。さらなる別の取得方法として、教育機関以外の第三者が人材情報を管理している場合も想定され、この場合には、例えばＡＰＩ経由で人材情報が第三者から取得されてもよい。
【0027】
「保有資格」は、「ユーザＩＤ」で特定される学生が保有する資格であって、自由に記入できて就職に影響しそうな資格、語学、スキル、自己ＰＲ等（例えば、ＴＯＥＩＣ得点、ＴＯＥＦＬ得点）に関する情報である。資格には、作業療法士、歯科衛生士などの国家資格が含まれ得る。この場合、資格の有無に関する情報は、「ユーザＩＤ」で特定される学生が使用する求職者端末３００から取得されてもよく、国家資格試験を運営する国家試験運営本部などの公的機関から取得されてもよい。
【0028】
「成績の伸び具合」は、「ユーザＩＤ」で特定される学生が学校に在籍していた期間内における成績の伸び具合に関する情報（例えばＧＰＡ（Grade Point Average：成績指標値））である。ＧＰＡを導入した成績の査定は、Ｓ（９０点以上）、Ａ（８０点以上、９０点未満）、Ｂ（７０点以上８０点未満）、Ｃ（６０点以上７０点未満）、Ｆ+（５０点以上６０点未満）、Ｆ（５０点未満）に大別される。例えば、学生の成績を履歴として、または時系列で示す情報（伸び率）として、学生が大学１年生の時は、成績査定が「Ｃ（６０点平均）」であったが、大学４年生の時には、「Ｂ（７５点平均）」に伸びたといった情報や、学生が５０人中５０位で入学したが卒業時には上位５位の中にランクインしていたといった情報を挙げることができる。
【0029】
「素行面の良し悪し」は、「ユーザＩＤ」で特定される学生が学校に在籍していた期間内における素行面の良し悪し（例えば、他の学生の足を引っ張る学生か否か等）に関する情報である。例えば、学生の属性（この例では素行面）を履歴として、または時系列で示す情報（伸び率）として、入学当初は授業に欠席しがちな学生であったが、卒業間際には皆勤賞をとるほどの学生に変貌していた等の情報を挙げることができる。
【0030】
「メンタルストレス」は、「ユーザＩＤ」で特定される学生のメンタルストレスに対する強度（例えば、公知のＦＦＳ(Five Factors ＆ Stress)理論を活用したメンタルストレスに対する強度）に関する情報である。例えば、学生の属性（この例ではメンタル面の強さ）を履歴として、または時系列で示す情報（伸び率）として、入学当初は体調不良で学校を休みがちな学生であったが、卒業間際には皆勤賞をとるほどの学生に変貌していたといった情報や、打たれ強いか弱いか、辛抱強いかそうでないか等の情報を挙げることができる。具体的な数値として、入学初年度は欠席回数が年間５０日であった学生の欠席回数が卒業年度には年間５日に減っていた等の情報を挙げることができる。
【0031】
その他、教育の場において、授業をはじめとした直接生徒に関する業務や仕事を担っている担当教員のコメント（大学１年～４年までの大学生活（前期＋後期の計８回分））は、学生の素行面を客観的に判断するうえで重要な情報源となり得る。特に、手先の器用さが求められる医療系の仕事においては、学生の手先が器用か不器用かについてはその学生の採否を判断するうえで重要な情報源となり得る。
【0032】
「活動内容情報」は、「ユーザＩＤ」で特定される学生の就職活動に関する情報である。「活動結果情報」は、「ユーザＩＤ」で特定される学生の就職活動の結果に関する情報である。ここで、「活動内容情報」及び「活動結果情報」の具体例について図３を用いて説明する。図３は、図２に示した「活動内容情報」及び「活動結果情報」の各データの構成例を示す説明図である。図３に示すように、「活動内容情報」及び「活動結果情報」のデータ構成内容１１１Ａは、以下の情報を含み得る。
【0033】
＜活動内容情報＞
まず、「活動内容情報」のデータ構成例について説明する。「エントリー情報」は、「ユーザＩＤ」で特定される学生が就職情報サイトに登録した日時、パスワードに関する情報である。「サイトの利用回数」は、「ユーザＩＤ」で特定される学生が就職情報サイトにログインした回数を示す情報である。「エントリー数」は、「ユーザＩＤ」で特定される学生が就職情報サイトにおいて採用を希望する企業に対してその旨を登録した数を示す情報である。なお、「エントリー数」は、会社説明会への参加を申し込んだ企業数に関する情報、又は、資料請求した企業数に関する情報により代替され得る。
まず、「活動内容情報」のデータ構成例について説明する。「エントリー情報」は、「ユーザＩＤ」で特定される学生が就職情報サイトに登録した日時、パスワードに関する情報である。「サイトの利用回数」は、「ユーザＩＤ」で特定される学生が就職情報サイトにログインした回数を示す情報である。「エントリー数」は、「ユーザＩＤ」で特定される学生が就職情報サイトにおいて採用を希望する企業に対してその旨を登録した数を示す情報である。なお、「エントリー数」は、会社説明会への参加を申し込んだ企業数に関する情報、又は、資料請求した企業数に関する情報により代替され得る。
【0034】
「会社説明会予約数」は、「ユーザＩＤ」で特定される学生が就職情報サイトにおいて会社説明会への参加を申し込んだ数に関する情報である。「選考試験予約数」は、「ユーザＩＤ」で特定される学生が就職情報サイトにおいて選考試験（例えば筆記試験など）への参加を申し込んだ数に関する情報である。「面接予約数」は、「ユーザＩＤ」で特定される学生が就職情報サイトにおいて面接試験への参加を申し込んだ数に関する情報である。
【0035】
＜活動結果情報＞
まず、「活動結果情報」のデータ構成例について説明する。「会社説明会参加履歴」は、「ユーザＩＤ」で特定される学生が就職情報サイトで申し込んだ会社説明会へ参加した履歴に関する情報（例えば、会社説明会に参加した企業数に関する情報、各会社説明会の開催日時に関する情報）である。「選考試験参加履歴」は、「ユーザＩＤ」で特定される学生が就職情報サイトで申し込んだ選考試験を受験した履歴に関する情報である。「面接参加履歴」は、「ユーザＩＤ」で特定される学生が就職情報サイトで申し込んだ面接試験を受験した履歴に関する情報である。
まず、「活動結果情報」のデータ構成例について説明する。「会社説明会参加履歴」は、「ユーザＩＤ」で特定される学生が就職情報サイトで申し込んだ会社説明会へ参加した履歴に関する情報（例えば、会社説明会に参加した企業数に関する情報、各会社説明会の開催日時に関する情報）である。「選考試験参加履歴」は、「ユーザＩＤ」で特定される学生が就職情報サイトで申し込んだ選考試験を受験した履歴に関する情報である。「面接参加履歴」は、「ユーザＩＤ」で特定される学生が就職情報サイトで申し込んだ面接試験を受験した履歴に関する情報である。
【0036】
「内定獲得履歴」は、「ユーザＩＤ」で特定される学生が就職情報サイトを利用する企業から内定を獲得した履歴に関する情報である。「就職先企業情報」とは、「ユーザＩＤ」で特定される学生が内定を貰った企業の中から最終的に就職先として選んだ企業に関する情報である。
【0037】
＜採用情報ＤＢ＞
次に、図２に示した採用情報ＤＢ１１２の詳細なデータ構成例について説明する。採用情報ＤＢ１１２は、各企業などにおける学生の採用に関する情報である採用情報を管理するためのデータベースである。図４は、図１に示した採用情報ＤＢ１１２の詳細なデータ構成例を示す説明図である。図４に示すように、採用情報は、例えば、企業を一意に特定する識別子である「企業ＩＤ」に関連づけて以下の情報を格納する。
次に、図２に示した採用情報ＤＢ１１２の詳細なデータ構成例について説明する。採用情報ＤＢ１１２は、各企業などにおける学生の採用に関する情報である採用情報を管理するためのデータベースである。図４は、図１に示した採用情報ＤＢ１１２の詳細なデータ構成例を示す説明図である。図４に示すように、採用情報は、例えば、企業を一意に特定する識別子である「企業ＩＤ」に関連づけて以下の情報を格納する。
【0038】
「企業名」は、「企業ＩＤ」で特定される企業の名称である。「業種」は、「企業ＩＤ」で特定される企業が属する業種を特定する情報である。「採用要領」は、「企業ＩＤ」で特定される企業の採用に関する情報であり、職種・仕事の内容に関する情報である、「勤務内容」、「勤務地」、「勤務条件」及び「採用予定数」などの情報を含む。
【0039】
「イベント情報」は、「企業ＩＤ」で特定される企業の「会社説明会情報」及び「採用試験情報」が含まれ得る。「会社説明会情報」には、会社説明会の開催予定に関する情報である「開催予定情報」と、会社説明会の開催履歴に関する情報である「開催履歴情報」が含まれる。「採用試験情報」には、採用試験の内容及び開催予定に関する情報である「開催予定情報」と、採用試験の開催履歴に関する情報である「開催履歴情報」が含まれる。「採用結果情報」は、「企業ＩＤ」で特定される企業の採用結果に関する情報（例えば、採用予定数に対する内定数の比率など）が含まれる。
【0040】
以上で、データベースＤＢ１００に格納される各ＤＢ１１１、１１２のデータ構成例に関する説明を終え、以下では、図１に示した仲介サーバ４００の機能構成の説明に戻る。
【0041】
【0042】
通信部４１０は、ネットワークＮＷを介して、データベースＤＢ１００と、求人者端末２００と、求職者端末３００と通信を行うための通信インターフェースであり、例えばＴＣＰ／ＩＰ等の通信規約により通信が行われる。
【0043】
記憶部４２０は、各種制御処理又は制御部４３０内の各機能を実行するためのプログラム、入力データ等を記憶するものであり、ＲＡＭ、ＲＯＭ等から構成される。また、記憶部４２０は、求人者に関連する各種データを格納する求人者データ格納部４２１、求職者に関連する各種データを格納する求職者データ格納部４２２等を有する。さらに、記憶部４２０は、データベースＤＢ１００と、求人者端末２００と、求職者端末３００と通信を行ったデータを一時的に記憶することもできる。なお、各種データを格納したデータベース（図示せず）が記憶部４２０又は仲介サーバ４００外に構築されていてもよい。
【0044】
制御部４３０は、記憶部４２０に記憶されているプログラムを実行することにより、仲介サーバ４００の全体の動作を制御するものであり、ＣＰＵ又はＧＰＵ等から構成される。制御部４３０の機能として、求人者希望条件受信部４３１と、求職者検索処理部４３２と、求人者表示処理部４３３と、逆オファー情報送信部４３４と、求職者希望条件受信部４３５と、求人者検索処理部４３６と、求職者表示処理部４３７と、オファー情報送信部４３８と、決済代行部４３９と、を有する。
【0045】
これら求人者希望条件受信部４３１、求職者検索処理部４３２、求人者表示処理部４３３、逆オファー情報送信部４３４、求職者希望条件受信部４３５、求人者検索処理部４３６、求職者表示処理部４３７、オファー情報送信部４３８及び決済代行部４３９は、記憶部４２０に記憶されているプログラムにより起動されてコンピュータ（電子計算機）である仲介サーバ４００により実行される。
【0046】
求人者希望条件受信部４３１は、求人者である企業の採用担当者が操作する求人者端末２００から就職情報サイトに対する企業の採用情報を求人者希望条件情報として受け付けて、採用情報ＤＢ１１２に格納する処理を行う機能を有する。ここで、採用情報とは、図４に示した企業ＩＤに関連付けられた各種情報である。具体的に、求人者希望条件受信部４３１は、求人者端末２００から就職情報サイトに採用情報を登録する場合には、求人者端末２００にて表示される採用情報登録画面を提示する。この採用情報登録画面は、就職情報サイトに必要な情報（図４の「企業名」、「業種」、「採用要領」、「イベント情報」など）を採用担当者が入力可能な画面である。登録された企業は、求人者端末２００による就職情報サイトへのログイン後に設定画面を表示して、学生のエントリーを受け付けるサービス、会社説明会の開催案内を提示するサービス、会社説明会の参加申し込み受け付けサービスなど、就職情報サイトの種々の機能を利用する設定を行い得る。
【0047】
求職者検索処理部４３２は、求人者希望条件受信部４３１が求人者希望条件情報として受け付けた採用情報と、学生情報ＤＢ１１１に含まれる学生情報（人材情報を含む）とを照合して、企業の希望条件に合致する学生を学生情報ＤＢ１１１から検索する機能を有する。検索処理は、基本的には、学生情報ＤＢ１１１上で実行されるが、検索条件によってはそれに関連するＤＢも検索され得る。絞り込み条件（個々の検索条件）は、大きくは、企業情報・選考情報、採用情報、学生情報等に分類され得る。これらの分類における検索条件は検索においては全てＡＮＤで結合される。検索条件としたくない場合にはデータを入力しなければよい。
【0048】
企業の採用担当者が検索画面において所望の検索条件を入力し、検索ボタンを押すと、入力された検索条件が求人者端末２００から仲介サーバ４００に送信される。就職情報サイトでは、求職者検索処理部４３２が求人者端末２００から受信した検索条件に従って学生情報ＤＢ１１１を検索し、検索条件に合致する学生を抽出する。
【0049】
求人者表示処理部４３３は、求職者検索処理部４３２が検索した学生に関する情報を基に、求人者端末２００に一覧で表示可能な求職者データを生成して求人者端末２００へ送信する機能を有する。求人者表示処理部４３３は、例えば、求職者検索処理部４３２の検索結果（抽出された人数、抽出された学生の姓名、学生ＩＤ、学校名、学部のリストなど）をその表示画面とともに求人者端末２００に送信する。すると、求人者端末２００において、検索結果画面が表示される。この画面には、該当者の人数（抽出された学生の人数）、抽出された学生の具体的な情報（上述した学生の姓名、学生ＩＤ、学部など）が表示される。
【0050】
逆オファー情報送信部４３４は、求人者である各企業の採用担当者からの送信要求に応答して、求職者検索処理部４２３が検索した学生に関連する求職者端末１００に、各企業の採用担当者からから学生への逆オファーに関する情報である逆オファー情報の送信処理を行う機能を有する。具体的に、逆オファー情報送信部４３４は、求職者検索処理部４２３が検索した学生の学生情報ＤＢ１１１を参照し、その学生に送信すべき逆オファー情報（申し込み可能な就職説明会に関する情報、面接申込に関するリストなど）をその表示画面とともに求人者端末２００に送信する。求職者端末１００においては、説明会／面接一覧画面が表示される。当該画面のリストにおいて、「申込可」のセルが例えばクリックされると、そのセルに対応する説明会／面接に参加申込を行ったことになり、「申込済」のセルが例えばクリックされると、そのセルに対応する説明会／面接の申し込みを取り消すことになる。学生が申込又はキャンセルを行った旨は求人者端末２００に送られる。
【0051】
求職者希望条件受信部４３５は、求職者端末１００から、求職者である学生の希望条件を示す求職者希望条件情報を受信する機能を有する。求職者の希望条件は、例えば、「希望業種」、「希望職種」、「希望勤務地」等である。
【0052】
求人者検索処理部４３６は、求職者希望条件受信部４３５が受信した求職者希望条件情報と、採用情報ＤＢ１１２に含まれる特性情報とを照合して、求職者の希望条件に合致する求人者である企業を検索する機能を有する。特性情報は、「企業ＩＤ」で特定される企業の特性に関する情報であり、少なくとも「配属先」又は「給与体系」が含まれる。
【0053】
求職者表示処理部４３７は、求人者検索処理部４３６が検索した求人者に関する情報を基に、求職者端末１００に一覧で表示可能な求人者データを生成して求職者端末１００へ送信する機能を有する。求職者表示処理部４３７は、例えば、求人者検索処理部４３６の検索結果（抽出された企業の数、抽出された企業の企業名、企業ＩＤ、業種、採用要領のリストなど）をその表示画面とともに求職者端末１００に送信する。すると、求職者端末１００において、検索結果画面が表示される。この画面には、該当する企業数（抽出された企業の数）、抽出された企業の具体的な情報（上述した企業名、企業ＩＤ、業種など）が表示される。
【0054】
オファー情報送信部４３８は、求職者である学生からの送信要求に応答して、求人者検索処理部４３６が検索した求人者に関連する求人者端末２００に、求職者から求人者へのオファーに関する情報であるオファー情報の送信処理を行う機能を有する。オファー情報には、企業から学生に提示される条件である採用条件が含まれ得る。採用条件には、例えば、年収額、勤務地、職種、その他の就業の条件等の情報が含まれ得る。
【0055】
決済代行部４３９は、教育機関又は求職者に対する求人者の入金及び出金に関する決済を代行する機能を有する。具体的に、決済代行部４３９は、求職者端末１００からの入力に基づいて、入試検定料又は入学料その他学費の決済を行うものである。ここでの決済は、例えば、学生の親権者により設定されたクレジットカード・電子マネー等により行われ得る。
【0056】
＜処理の流れ＞
図６を参照しながら、本実施形態のシステム１が実行する求職者と求人者とのマッチング方法の処理の流れについて説明する。図６は、本発明の第一実施形態に係る、マッチング方法に係るフローチャートの一例である。
図６を参照しながら、本実施形態のシステム１が実行する求職者と求人者とのマッチング方法の処理の流れについて説明する。図６は、本発明の第一実施形態に係る、マッチング方法に係るフローチャートの一例である。
【0057】
ここで、本システム１を利用するために、求人者及び／または求職者は、求人者端末２００、求職者端末３００各々のウェブブラウザまたはアプリケーション等を利用して仲介サーバ４００にアクセスし、初めてサービスを利用する場合は、求人者基本情報等、求職者基本情報等を各々入力し、既に、求人者、求職者のアカウントを取得済の場合は、例えばＩＤとパスワードを入力する等の所定の認証を受けてログインすることで、サービスが利用可能となる（ステップＳ１００）。この認証後、ウェブサイト、アプリケーション等を介して所定のユーザインターフェースが提供され、図６に示すステップＳ１０１へ進む。
【0058】
まず、ステップＳ１０１の処理として、求人者希望条件受信部４３１は、求人者端末２００から就職情報サイトに対する企業の採用情報を求人者希望条件情報として受け付けて、採用情報ＤＢ１１２に格納する。
【0059】
次に、ステップＳ１０２の処理として、求職者検索処理部４３２は、求人者希望条件受信部４３１が求人者希望条件情報として受け付けた採用情報と、学生情報ＤＢ１１１に含まれる学生情報（人材情報を含む）とを照合して、企業の希望条件に合致する学生を学生情報ＤＢ１１１から検索する。この求人者である企業による検索に際し、求人者側に公開される学生の情報は例えばテスト成績・希望待遇などのデータのみであり、氏名・住所・電話番号・学校名などの個人を特定するデータは公開されず、例えば、これらの個人データは企業による指名を学生が受諾した場合のみ求人者側に公開される。これは学生のプライバシーを保護するとともに、求人者側に客観的データによる学生選抜を促すためでもある。
【0060】
次に、ステップＳ１０３の処理として、求人者表示処理部４３３は、求職者検索処理部４３２が検索した学生に関する情報を基に、求人者端末２００に一覧で表示可能な求職者データを生成する。
【0061】
次に、ステップＳ１０４の処理として、求人者表示処理部４３３は、生成した求職者データを求人者端末２００へ送信する。送信した結果は、例えば一覧表の形式で求人者端末２００の画面に表示され、かつ表示結果が企業側ＤＢに保存される。
【0062】
以上、本実施形態のマッチングシステム１によれば、求職者検索処理部４３２において、求人者希望条件受信部４３１が求人者希望条件情報として受け付けた採用情報と、学生情報ＤＢ１１１に含まれる学生情報（求職者である学生の入学から卒業に至るまでの人材情報を含む）とを照合して、企業の希望条件に合致する学生を学生情報ＤＢ１１１から検索するので、学生が教育機関に入学した時点まで時間を遡った情報を加味して採用の可否が判断され得る。「遡った情報」には、教育機関が行う入学試験の合否、つまり、どこの教育機関を受験して、どの程度の成績で合格したか等を示す、入学時の成績情報が含まれ得る。このため、求職者である学生に関する情報をより充実させることができ、ひいては求職者と求人者のマッチング精度を高めることが可能となる。とりわけ、教育機関による推薦で学生の就職先が決まる傾向が強い医療業界においては、いろいろな戸口から学生を受け入れたいという医療機関の採用担当者のニーズに対して的確に応えることができる。
【0063】
（実施形態２）
以下、添付図面を参照しながら、本発明の第二の実施形態に係るマッチングシステムについて詳細に説明する。なお以下、第一の実施形態で説明した要素と同一の要素については、同一の符号を付して詳細な説明を省略する。
以下、添付図面を参照しながら、本発明の第二の実施形態に係るマッチングシステムについて詳細に説明する。なお以下、第一の実施形態で説明した要素と同一の要素については、同一の符号を付して詳細な説明を省略する。
【0064】
本実施形態のマッチングシステムは、学生の募集から入学手続きに至るまでの入試手続を一元管理し得るように構成される。図７は、本発明の第二実施形態に係るマッチングシステムを示すブロック構成図である。本実施形態における入試手続とは、入学試験の管理に留まらず、例えば、オープンキャンパス（学校説明会）の予約・入学金の振り込みといった入試前後の手続きも対象としている。
【0065】
当該マッチングシステム２は、図７に示すように、各学校に設けられる複数の管理端末５００と、各志願者に関連する複数の志願者端末６００と、各管理端末５００と各志願者端末６００とを仲介する仲介サーバ４００と、により構成される。ここで、志願者の親権者は、図示しない親権者端末より志願者と同じユーザＩＤとパスワードＰＷもしくは親権者専用のユーザＩＤとパスワードＰＷにより入試情報サイトにログインすることができ、志願者の入試情報サイトにおける、志望校に関する情報を含む、全部または一部の行動履歴を閲覧ができることとしてもよい。
【0066】
管理端末５００は、例えば、パーソナルコンピュータ又はタブレット端末等の情報処理装置であるが、スマートフォン、携帯電話、ＰＤＡ等により構成しても良い。
【0067】
志願者端末６００は、例えば、パーソナルコンピュータ又はタブレット端末等の情報処理装置であるが、スマートフォン、携帯電話、ＰＤＡ等により構成しても良い。
【0068】
次に、図７に示した管理端末５００、志願者端末６００、仲介サーバ４００の機能構成について説明する。
【0069】
＜管理端末５００＞
管理端末５００は、少なくとも当該学校の入試に関連する情報をウェブサイト等として配信するサーバとしての機能と、志願者の入試手続に関する情報を記憶するデータベースとしての機能を発揮し得るように構成される。
管理端末５００は、少なくとも当該学校の入試に関連する情報をウェブサイト等として配信するサーバとしての機能と、志願者の入試手続に関する情報を記憶するデータベースとしての機能を発揮し得るように構成される。
【0070】
【0071】
学校情報ＤＢ５１１は、当該学校を一意に特定する識別子である「学校ＩＤ」が示す学校の各種イベントに関連する学校情報を格納する。当該学校情報は、例えば、オープンキャンパス・入試日程等の情報を少なくとも含むものであり、ウェブサイト等として公開できるようなデータ形式で格納されている。
【0072】
志願者情報ＤＢ５１２は、当該志願者又は当該志願者の使用する志願者端末６００を一意に特定する識別子である「志願者ＩＤ」と、管理端末５００が設置されている学校に対する「志願者ＩＤ」が示す志願者の入試手続状態とを対にした志願者データを記憶するものである。入試手続状態とは、「志願者ＩＤ」が示す志願者が、その学校においてオープンキャンパスに申し込んでいるか否か、入学願書の提出が行われているか否か、入試検定料の振り込みを行ったか否か等の状態を含むものである。これにより、学校ごとの志願者データを参照することにより、志願者が現在入試手続においてどのような状態にあるかを把握し得る。
【0073】
＜志願者端末６００＞
志願者端末６００は、例えば、仲介サーバ４００から送信される各種のデータを表示したり、各学校への入学願書を電子的に作成したりするための機能を備える。
志願者端末６００は、例えば、仲介サーバ４００から送信される各種のデータを表示したり、各学校への入学願書を電子的に作成したりするための機能を備える。
【0074】
図９は、図７の志願者端末６００の機能ブロック構成図である。図９に示すように、志願者端末６００は、通信部６１０と、記憶部６２０と、制御部６３０と、を備える。なお、第一実施形態の部位４１０、４２０と、本実施形態の部位６１０、６２０とは、順に同様のものであるので、詳細な説明を省略する。
【0075】
制御部６３０は、記憶部６２０に記憶されているプログラムを実行することにより、志願者端末６００の全体の動作を制御するものであり、ＣＰＵ又はＧＰＵ等から構成される。制御部６３０の機能として、出願データ生成部６３１と、様式チェック部６３２と、を有する。
【0076】
出願データ生成部６３１は、志願者端末６００への入力又は当該志願者端末６００に記憶されているデータに基づいて、志願者が志望する学校ごとのフォーマットに合わせた願書データを作成する機能を有する。出願データ生成部６３１は、各学校の願書のフォーマットに関するデータを記憶したり管理端末５００又は仲介サーバ４００から取得したりする。そして、出願データ生成部６３１は、一度入力された志願者の所属校名、年齢等の基本的なデータについては記憶しておき、別の学校の願書を作成するときにはそのデータを利用可能に構成してある。
【0077】
様式チェック部６３２は、上述した願書データに含まれる写真データ・調査書類等の様式（書式）が予め定められた基準を満たすかどうかをチェックし、当該基準を満たさない場合には新たな願書データを要求する機能を有する。様式チェック部６３２は、例えば、写真データの焦点を検出し、写真における志願者の顔のあるべき位置においてあっているかどうかを検定する。ここで、写真データが不鮮明であり、入試会場において本人確認が困難なものになる場合には、願書を修正するように表示する。また、様式チェック部６３２は、例えば先に作成した別の学校の願者との整合性・試験日程の重複等についてもチェックするようにしてある。例えば試験日程に重複があり、志願者による受験が不可能である場合にはその旨を示す警告を志願者端末６００の画面に表示する。
【0078】
＜仲介サーバ４００＞
仲介サーバ４００は、各管理端末５００と各志願者端末６００とを仲介するものであり、各学校において学校情報ＤＢ５１１に更新があり、オープンキャンパス・入試日程等の学校情報を志願者に対して通知する機能と、複数の学校を志望する志願者に対して各学校の入試手続状態をまとめて一覧ページとして提供する機能と、を有する。
仲介サーバ４００は、各管理端末５００と各志願者端末６００とを仲介するものであり、各学校において学校情報ＤＢ５１１に更新があり、オープンキャンパス・入試日程等の学校情報を志願者に対して通知する機能と、複数の学校を志望する志願者に対して各学校の入試手続状態をまとめて一覧ページとして提供する機能と、を有する。
【0079】
図１０は、図７の仲介サーバ４００の機能ブロック構成図である。図１０に示すように、仲介サーバ４００は、通信部４１０と、記憶部４２０と、制御部４３０と、を備える。なお、第一実施形態の部位４１０、４２０と、本実施形態の部位４１０、４２０とは、順に同じものであるので、詳細な説明を省略する。
【0080】
制御部４３０は、記憶部４２０に記憶されているプログラムを実行することにより、仲介サーバ４００の全体の動作を制御するものであり、ＣＰＵ又はＧＰＵ等から構成される。制御部４３０の機能として、志願者ＩＤ受付部４４０と、志望受付部４４１と、志望校情報記憶部４４２と、志願者情報設定部４４３と、学校情報取得部４４４と、更新通知部４４５と、志願者情報取得部４４６と、ページ生成部４４７と、決済管理部４４８と、期限通知部４４９と、を有する。
【0081】
志願者ＩＤ受付部４４０は、志願者端末６００から志願者ＩＤを受け付ける機能を有する。志願者ＩＤは、例えば志願者が初めて当該マッチングシステム２を利用する際に付与される一連の番号（例えば、受験申込に係る識別番号）であり、例えば、一出願一ＩＤとなるように志願者端末６００ごとに割り振られる番号である。
【0082】
志望受付部４４１は、志願者端末６００から志願者の志望する学校を受け付ける機能を有する。志望受付部４４１で受け付けられた学校は、志願者ＩＤと志望する学校を示す学校ＩＤとを対にしたＩＤ－志望校情報データとして志望校情報記憶部４４２に記憶される。
【0083】
志願者情報設定部４４３は、志望受付部４４１で受け付けられた志願者の志望する学校の志願者情報ＤＢ５１２に対して志願者データを作成して記憶させる機能を有する。すなわち、志願者情報設定部４４３は、ある志願者から志望が有った学校に対してのみその志願者の志願者ＩＤを開示し、その志願者ＩＤと入試手続状態とからなる志願者データを各学校に作成させて記憶させる。従って、志望されていない学校の志願者情報設定部４４３には、志願者に関する情報は記憶されていない。
【0084】
ここで、「志願者データ」とは、例えば、受験者（志願者）自身の個人情報であり得る。例えば、受験者の氏名、住所・郵便番号、生年月日、電話番号、緊急連絡先、メールアドレス、出身高等学校、高校コード、予備校名、予備校コード、性別、出願資格（○○学校卒業・大検合格等）、保護者氏名、受験回数、大学入試センター試験の試験場コード、大学入試センター試験受験番号、受験先情報などが該当し得る。「受験先情報」とは、受験先・受験内容に関わる情報であって、例えば、学部、学科、入試形態（通常入試／記述式／面接／ＡＯ入試／推薦／小論文／マークシート方式／試験無し等）、日程、試験会場、合格発表日などが該当する。さらに、「志願者データ」には、各受験者に割り当てられた「受験番号」、デジタル受験票の「閲覧回数（発行回数）」なども含まれ得る。なお、ここで挙げた受験情報はあくまでも一例であり、どのような志願者データを管理するかは試験の内容等に応じて適宜設計すればよい。これらの受験情報のうち願書（志願票・調査書等）に記載された事項については、願書の記載事項を受験担当者が手入力することで、あるいは、ＯＣＲまたはＯＭＲ（マークシート）によって自動入力することで、志願者情報ＤＢ５１２に登録される。また、学生個人が入力した内容はすべて志願者データの対象となり得る。具体的な入力内容の例としては、学校が入力しない情報、医療関係以外の資格（秘書・弁護士等）の有無、アルバイト経験（ボランティア活動など）、アピール情報、経歴に繋がる情報、写真、テキストなどを挙げることができ、プライバシー設定も可能である。また、学生同士のコミュニケーションなどは親に見せないようにできる。ただし、お金回りは親に見せるように設定され得る。公的書類（経歴書など）はデータ入力すれば、仲介サーバ４００の志願者情報設定部４４３が生成し管理し得る。
【0085】
学校情報取得部４４４は、前記志願者ＩＤ受付部１０に受け付けられている志願者ＩＤの示す志願者が志望するいずれかの学校の学校情報が更新された場合に、その学校情報を 対応する学校情報ＤＢ５１１から取得する機能を有する。このとき取得される学校情報は全てであっても良く、一部だけであっても良い。学校情報の取得方法は特に限定されず、例えば、ＬＩＮＥ（登録商標）、Ｓｌａｃｋ（登録商標）等のＳＮＳサイトを活用して取得され得る。また、学校情報取得部４４４は、例えば、予め設定された所定期間ごとに各学校の学校情報ＤＢ５１１を参照し、更新の有無をチェックし得る。そして、更新が有った場合には志願者端末６００において更新に関連する表示を生成するために必要な学校情報を少なくとも取得するように学校情報取得部４４４は構成される。
【0086】
更新通知部４４５は、志願者ＩＤ受付部４４０に受け付けられている志願者ＩＤの志願者端末６００に対して、少なくとも学校情報取得部４４４により更新された学校情報を取得したことを通知する機能を有する。更新通知部４４５は、例えば、図１１に示すような更新通知ページを学校情報取得部４４４が取得した学校情報に基づいて生成し、志願者端末６００に対して送信するように構成される。図１１は、志願者端末に表示される更新通知ページを示した画面構成例である。更新通知ページには、学校側から学生側に提示（オファー）される募集要項の情報が含まれ得る。募集要項の細目には、例えば、「試験制度」「受験日」「受験場所」「受験必須教科科目」が含まれる。
【0087】
このように、志願者情報設定部４４３、学校情報取得部４４４、更新通知部４４５は、夫々が連携することにより、例えば、リアル／オンライン説明会（オープンキャンパス）の日程・入試日程等の学校情報が更新された場合にはその学校を志望する志願者に対して自動的に通知する前記募集・広報ツールとしての機能を発揮し得る。
【0088】
志願者情報取得部４４６は、各学校の志願者情報ＤＢ５１２から、志願者ＩＤ受付部４４０に受け付けられた志願者ＩＤを含む志願者情報データを夫々取得する機能を有する。
【0089】
ページ生成部４４７は、志願者情報取得部４４６で取得された複数の志願者情報データに基づいて、ある志願者の複数の大学における入試手続状態が一覧表示される一覧ページを生成する機能を有する。一覧ページの一例としては、例えば、図１２に示されるようなものが挙げられる。図１２は、志願者端末に表示される一覧ページを示した画面構成例である。より具体的に、一覧ページは、志願者が仲介サーバ４００に対して登録している志望する学校の名前と、各学校の入試手続状態が夫々対になった表形式のものである。
【0090】
決済管理部４４８は、志願者端末６００からの入力に基づいて、入試検定料又は入学料の決済を行うものである。ここでの決済は、例えば、志願者により設定されたクレジッ トカードや電子マネー等により行われ得る。
【0091】
期限通知部４４９は、学校ごとに予め定められた所定期日までに 決済管理部４４８による入試検定料又は入学料の振込が無い場合には、志願者端末６００に対して最終期限が近付いていることを事前に通知する機能を有する。
【0092】
＜処理の流れ＞
図１３を参照しながら、本実施形態のシステム２が実行する学校と志願者とのマッチング方法の処理の流れについて説明する。図１３は、本発明の第二実施形態に係る、マッチング方法に係るフローチャートの一例である。
図１３を参照しながら、本実施形態のシステム２が実行する学校と志願者とのマッチング方法の処理の流れについて説明する。図１３は、本発明の第二実施形態に係る、マッチング方法に係るフローチャートの一例である。
【0093】
ここで、本システム２を利用するために、志願者は、志願者端末６００のウェブブラウザまたはアプリケーション等を利用して仲介サーバ４００にアクセスし、初めてサービスを利用する場合は、志願者基本情報等を入力し、既に、志願者のアカウントを取得済の場合は、例えばＩＤとパスワードを入力する等の所定の認証を受けてログインすることで、サービスが利用可能となる。この認証後、ウェブサイト、アプリケーション等を介して所定のユーザインターフェースが提供され、図１３に示すステップＳ２０１へ進む。
【0094】
まず、ステップＳ２０１の処理として、志望者は志望する候補であるお気に入りの大学について、志願者端末６００を介して仲介サーバ４００が提供するウェブサイトにおいて入力する。
【0095】
次に、ステップＳ２０２の処理として、ステップＳ２０１の処理で入力された大学については志望受付部４４１において受け付けられて、志望校情報記憶部４４２において志願者ＩＤと学校ＩＤとが対になったＩＤ－志望校情報が記憶及び更新される。
【0096】
次に、ステップＳ２０３の処理として、志願者がお気に入りに登録していた学校の学校情報ＤＢ５１１においてリアル／オンライン説明会（オープンキャンパス）や入試日程に関する学校情報の更新が行われる。
【0097】
次に、ステップＳ２０４の処理として、その更新情報を仲介サーバ４００の学校情報取得部４４４が取得する。
【0098】
次に、ステップＳ２０５の処理として、仲介サーバ４００の更新通知部４４５は、学校情報の更新があったことを志願者端末６００に対して通知するとともに、ページ生成部４４７は、登録されている大学の入試手続状態を更新して新たな一覧ページを生成して志望者に対する提供を開始する。
【0099】
次に、ステップＳ２０６の処理として、志願者は志願者端末６００を介して、定期的に配信される一覧ページ又は各大学の学校情報を参照する。出願する大学が定まった志願者は、志願者端末６００の出願データ生成部６３１が提供するフォーマットに基づいて、志望大学の願書を作成する。
【0100】
次に、ステップＳ２０７の処理として、志願者端末６００の様式チェック部６３２により写真データの適否又は入試検定料の納付等に関するチェックが行われる。
【0101】
次に、ステップＳ２０８の処理として、志願者端末６００の出願データ生成部６３１で生成された出願データが、該当する学校の管理端末５００に送信されて、管理端末５００の志願者情報ＤＢ５１２において志願者ＩＤと入試手続状態が対になった志願者情報として記憶及び更新される。
【0102】
次に、ステップＳ２０９の処理として、仲介サーバ４００の志願者情報取得部４４６は、例えば、志願者端末６００によるアクセスがある度に、志望校情報記憶部４４２に登録されている志願者の志望する複数の大学の志願者情報ＤＢ５１２を参照し、夫々の入試手続状態を取得する。
【0103】
次に、ステップＳ２１０の処理として、ステップＳ２０９の処理で取得された入試手続状態に基づいて、ページ生成部４４７は一覧ページを更新し、志願者端末６００に対して配信する。この結果、 志願者は各大学に対して個別にアクセスすることなく一覧ページを取得し志願者端末６００の画面に表示するだけで各大学の入試手続の進行状態を自動的にチェックすることができる。
【0104】
以上、本実施形態のマッチングシステム２によれば、入学試験に関する情報を含む様々な学校の情報を一元的に管理することができ、情報の入手が容易であり、受験生の地理的、時間的及び経済的な負担を軽減することができ、志望校の選択も容易となる。特に、誰がどこの学校のオープンキャンパスに参加し願書を取り寄せたり実際に受験したりしたか等といった情報は、学校を卒業した時点での学生情報（求職者である学生の入学から卒業に至るまでの人材情報を含む）に掛け合わせて人材を評価するうえで極めて重要である。
【0105】
なお、コンピュータによる採点処理が可能なマークシート方式で試験が行われる場合には、スコアが何点であったか等の成績情報・合否に関する情報を学生情報に含めても良い。この結果、仲介サーバ４００において、学生の成績管理が可能となる。
【0106】
（実施形態３）
以下、添付図面を参照しながら、本発明の第三の実施形態に係るマッチングシステムについて詳細に説明する。なお以下、第一の実施形態で説明した要素と同一の要素については、同一の符号を付して詳細な説明を省略する。
以下、添付図面を参照しながら、本発明の第三の実施形態に係るマッチングシステムについて詳細に説明する。なお以下、第一の実施形態で説明した要素と同一の要素については、同一の符号を付して詳細な説明を省略する。
【0107】
本実施形態のマッチングシステムは、医療関連業者が管理・運営しているものとする。「医療関連業者」とは、医療機関等を顧客として、薬剤・医療関係機器等の納入、医療機関で使用する各種機器のレンタル・リース・ファイナンス・割賦販売、医業に関する人材紹介、医業に関する人材派遣、医療施設の設計・施工・リフォーム・保守管理、保険商品の販売、医療機関の経営コンサルタント等の業務を少なくとも１つは実施している業者である。「医療関連業者」は、企業等からの依頼で人材の引き抜きオファー（申し入れ）を出すヘッドハンティングなども行い得る。勿論、医療関連業者の依頼に基づいて第三者がマッチングシステムを管理・運営してもよい。なお、マッチングの概念には、困っている人に対して適切な就職先をリアルタイムで引き合わせること、期間限定（例えば５年）でサービス提供者同士によるトレードが行われること、ヘルプ要員を派遣すること、グループを跨いだ病院間での人的サポートが行われること、引っ越し・移住・口コミ、暇を持て余している有資格者を獲得すること、が含まれる。
【0108】
図１４は、本発明の第三実施形態に係るマッチングシステムを示すブロック構成図である。マッチングシステム３は、図１４に示すように、医師に関連する医師用端末７００と、求人担当者に関連する求人端末８００と、医師用端末７００と求人端末８００とを仲介する仲介サーバ４００と、により構成される。「医師求人担当者」は、医療機関において医師の求人を担当している担当者であって、必ずしも医師である必要はない。なお、医療機関による医師の求人は、原則、勤務医としての求人であるが、新型コロナウイルスで困っている（助けて欲しい）求人サイドにとっては、国際的な人の採用（例えば、フィリピン人を訪問介護要員として採用）、国際的な人に対する就職支援（引っ越し・家探し等）の求人業務も行い得る。
【0109】
仲介サーバ４００には、転職を希望している医師の個人情報等を管理する医師情報ＤＢ２００と、医療機関における医師の求人情報等を管理する求人情報ＤＢ３００と、が接続されている。そして、仲介サーバ４００の検索機能を用いることにより、医師用端末７００と、求人端末８００とから所定のＤＢ２００、３００の検索処理を可能としている。
【0110】
図１４では、仲介サーバ４００は１台の装置で構成しているように表示しているが、複数台のサーバ装置を組み合わせて構成してもよく、全体として後述する機能を満たしていればよい。特に、必要に応じて、Ｗｅｂサーバ装置、ファイアウォール等を設けてもよい。
【0111】
医師用端末７００は、医師による仲介サーバ４００へのアクセスを可能とするパーソナルコンピュータ等の端末装置である。医師は、医師用端末７００を用いることによって、医師情報ＤＢ２００への個人情報等の入力、 並びに、求人情報ＤＢ３００の検索が可能となっている。
【0112】
求人端末８００は、医療機関の医師求人担当者による仲介サーバ４００へのアクセスを可能とするパーソナルコンピュータ等の端末装置である。医師求人担当者は、求人端末８００を用いることによって、求人情報ＤＢ３００への求人情報等の入力、並びに、医師情報ＤＢ２００の検索が可能となっている。
【0113】
なお、転職を希望する医師、医師求人担当者が、各端末７００、８００を用いて直接的に所定のＤＢ２００、３００への情報入力あるいは検索を行ってもよいが、マッチングシステム３を管理・運営している医療関連業者の所定の担当者が、医師、医師求人担当者に代わって所定の入力作業及び検索作業を行ってもよい。
【0114】
仲介サーバ４００には、さらに、医師評価装置９００が接続されている。医師評価装置９００は、医師情報ＤＢ２００に登録された医師の技能情報を用いて医師の能力評価を行うべく構成される。さらに、医師評価装置９００は、求人情報ＤＢ３００に登録された求人情報と、医師情報ＤＢ２００に登録された医師の技能情報から、医師求人担当者の所属している医療機関と医師との適合性評価を行い得る。
【0115】
本実施形態では、医師評価装置９００は、マッチングシステム３の管理者が仲介サーバ４００とともに管理しているが、医師評価装置９００は、他のシステム管理者によって管理されても良い。
【0116】
医師情報ＤＢ２００には、転職を希望する医師の名前情報、住所情報、連絡先電話番号情報、Ｅ－ｍａｉｌアドレス情報等の個人情報と、専門科目情報、希望年収情報、希望勤務地情報等の勤務条件情報等の他に、技能情報等も登録されている。医師評価装置９００は、医師情報ＤＢ２００に登録された技能情報に基づき、医師の能力評価、及び、医療機関の求人情報に対する医師の適合性評価を行う。
【0117】
医師の能力評価は、例えば、人物評価、学会評価、研究業績評価、治療経験評価、臨床評価等の項目によって行われる。各項目は、例えば、ポイント制で評価され得る。このようにポイントの割り付けを行って評価することにより、医師の能力を客観的に比較することができ、医師情報ＤＢ２００に登録された医師に対して、能力の優劣による順位付け、ランク分け、あるいはタイプ別分類等を行うことができる。
【0118】
＜人物評価＞
人物評価は、例えば、「感受性」「人間関係」「情報収集力」「協調性」「積極性」「信頼度」「責任感」「指導力」「統率力」「管理能力」の１０項目について、それぞれポイント制で自己評価させ、その評価結果を医師情報ＤＢ２００に入力させている。さらに、転職を希望している医師の上司・同僚等の第三者によって評価を行ってもらい、そのデータを医師情報ＤＢ２００に入力させている。そして、医師評価装置９００は、自己評価の獲得点数と、客観評価の獲得点数との合計点を人物評価のポイント数として算出する。
人物評価は、例えば、「感受性」「人間関係」「情報収集力」「協調性」「積極性」「信頼度」「責任感」「指導力」「統率力」「管理能力」の１０項目について、それぞれポイント制で自己評価させ、その評価結果を医師情報ＤＢ２００に入力させている。さらに、転職を希望している医師の上司・同僚等の第三者によって評価を行ってもらい、そのデータを医師情報ＤＢ２００に入力させている。そして、医師評価装置９００は、自己評価の獲得点数と、客観評価の獲得点数との合計点を人物評価のポイント数として算出する。
【0119】
＜学会評価＞
学会評価は、例えば、科目別の学会における地位・役職等情報と、専門領域の学会における地位・役職等情報とを医師情報ＤＢ２００に入力させて評価しているものである。そして、医師評価装置９００は、例えば、科目別の学会において、「理事」「評議員」「指導医」「認定医」「会員」に応じたポイントを割り付ける。また例えば、医師評価装置９００は、専門領域の学会において、「理事」「評議員」「指導医」「認定医」「会員」に応じたポイントを割り付ける。そして、医師評価装置９００は、科目別の学会におけるポイントと、専門領域の学会におけるポイントとの合計を学会評価のポイント数として算出する。
学会評価は、例えば、科目別の学会における地位・役職等情報と、専門領域の学会における地位・役職等情報とを医師情報ＤＢ２００に入力させて評価しているものである。そして、医師評価装置９００は、例えば、科目別の学会において、「理事」「評議員」「指導医」「認定医」「会員」に応じたポイントを割り付ける。また例えば、医師評価装置９００は、専門領域の学会において、「理事」「評議員」「指導医」「認定医」「会員」に応じたポイントを割り付ける。そして、医師評価装置９００は、科目別の学会におけるポイントと、専門領域の学会におけるポイントとの合計を学会評価のポイント数として算出する。
【0120】
＜研究業績評価＞
研究業績評価は、例えば、執筆論文数情報と、学会発表数情報とを医師情報ＤＢ２００に入力させるべく構成される。そして、医師評価装置９００は、執筆論文数の評価では、英文論文であって筆頭論文の発表編数に応じてポイントの割り付けを行い、邦文論文であって筆頭論文の発表編数に応じてポイントの割り付けを行い、英文論文であって共著論文の発表編数に応じてポイントの割り付けを行い、邦文論文であって共著論文の発表編数に応じてポイントの割り付けを行うべく構成される。また、学会発表数の評価では、外国ないし招待公演であって筆頭演者としての発表回数に応じてポイントの割り付けを行い、それ以外の発表における筆頭演者としての発表回数に応じてポイントの割り付けを行い、外国ないし招待公演であって共同演者としての発表回数に応じてポイントの割り付けを行い、それ以外の発表における共同演者としての発表回数に応じてポイントの割り付けを行うべく構成される。そして、医師評価装置９００は、執筆論文数におけるポイントと、学会発表数におけるポイントとの合計を研究業績評価のポイント数として算出する。
研究業績評価は、例えば、執筆論文数情報と、学会発表数情報とを医師情報ＤＢ２００に入力させるべく構成される。そして、医師評価装置９００は、執筆論文数の評価では、英文論文であって筆頭論文の発表編数に応じてポイントの割り付けを行い、邦文論文であって筆頭論文の発表編数に応じてポイントの割り付けを行い、英文論文であって共著論文の発表編数に応じてポイントの割り付けを行い、邦文論文であって共著論文の発表編数に応じてポイントの割り付けを行うべく構成される。また、学会発表数の評価では、外国ないし招待公演であって筆頭演者としての発表回数に応じてポイントの割り付けを行い、それ以外の発表における筆頭演者としての発表回数に応じてポイントの割り付けを行い、外国ないし招待公演であって共同演者としての発表回数に応じてポイントの割り付けを行い、それ以外の発表における共同演者としての発表回数に応じてポイントの割り付けを行うべく構成される。そして、医師評価装置９００は、執筆論文数におけるポイントと、学会発表数におけるポイントとの合計を研究業績評価のポイント数として算出する。
【0121】
＜治療経験評価＞
治療経験評価は、専門科目によって評価形態が大きく異なるため、以下においては、外科の場合と、内科の場合を例に挙げて説明する。
治療経験評価は、専門科目によって評価形態が大きく異なるため、以下においては、外科の場合と、内科の場合を例に挙げて説明する。
【0122】
外科における治療経験評価は、例えば、「臨床経験年数」「術後合併症率」「手術死亡率」「手術 経験数」「難易度別手術経験」の５項目について医師情報ＤＢ２００に所定の入力を行わせ、評価を行うべく構成される。医師評価装置９００は、「臨床経験年数」に関しては、臨床経験年数に応じたポイントを割り付けるべく構成される。「術後合併症率」に関しては、術後合併症率に応じたポイントを割り付けるべく構成される。「手術死亡率」に関しては、手術死亡率に応じたポイントを割り付けるべく構成される。「手術経験数」に関しては、手術経験数に応じたポイントを割り付けるべく構成される。「難易度別手術経験」では、各手術を難易度に応じてあらかじめ区分しておき、医師情報ＤＢ２００には、実施した手術の症例数と、 術後の合併症の発生例数とを入力させるべく構成される。そして、医師評価装置９００は、手術ごとに経験点数を算出する。斯くして、医師評価装置９００は、上記した「臨床経験年数」「術後合併症率」「手術死亡率」「手術経験数」「難易度別手術経験」の５項目におけるポイントの合計を治療経験評価のポイント数として算出する。
【0123】
内科における治療経験評価は、例えば、「年間入院症例数」「月間外来症例数」「診療技能」「 診療知識」の４項目について医師情報ＤＢ２００に所定の入力を行わせ、評価を行うべく構成される。医師評価装置９００は、「年間入院症例数」に関しては、年間入院症例数に応じたポイントを割り付けるべく構成される。「月間外来症例数」に関しては、月間外来症例数に応じたポイントを割り付けるべく構成される。「診療技能」に関しては、各診療技能項目に対して自己評価させたデータを医師情報ＤＢ２００に入力させている。また、「診療知識」に関しては、各診療知識項目に対して自己評価させたデータを医師情報ＤＢ２００に入力させている。そして、医師評価装置９００は、診療技能評価表での合計点数と、診療知識評価表での合計点数との総計点数を算出し、総計点数に応じたポイントを割り付けるべく構成される。斯くして、医師評価装置９００は、「年間入院症例数」「月間外来症例数」 「診療技能」「診療知識」の４項目におけるポイントの合計を治療経験評価のポイント数として算出する。
【0124】
＜臨床評価＞
臨床評価も専門科目によって評価形態が異なるため、以下においては、外科の場合と、 内科の場合を例に挙げて説明する。
臨床評価も専門科目によって評価形態が異なるため、以下においては、外科の場合と、 内科の場合を例に挙げて説明する。
【0125】
外科における臨床評価は、例えば、「紹介率」「手術技量に対する自己評価」「手術技量に対する第三者評価」の３項目について医師情報ＤＢ２００に所定の入力を行わせ、評価を行うべく構成される。ここで、紹介率とは、例えば、「個人への紹介例数」と「外科への紹介で主治医となった例数」との和を「外科全体の紹介例数」で割った値の百分率である。医師評価装置９００は、「紹介率」に関しては、紹介率に応じたポイントを割り付けるべく構成される。「手術技量に対する自己評価」に関しては、自己の専門領域における手術技能を例えば５段階評価で「５」と評価した場合には８ポイント、「４」と評価した場合には７ポイント、「３」と評価した場合には５ポイント、「２」と評価した場合には３ポイント、「１」と評価した場合には２ポイントを割り付けるべく構成される。「手術技量に対する第三者評価」に関しては、人物評価の場合と同様に、転職を希望している医師の上司・同僚等の第三者によって当該医師の手術技能を５段階評価してもらい 、「５」と評価した場合には８ポイント、「４」と評価した場合には７ポイント、「３」 と評価した場合には５ポイント、「２」と評価した場合には３ポイント、「１」と評価した場合には２ポイントを割り付けるべく構成される。そして、医師評価装置９００は、「紹介率」「手術技量に対する自己評価 」「手術技量に対する第三者評価」の３項目におけるポイントの合計を臨床評価のポイント数として算出する。
【0126】
内科における臨床評価は、例えば、「臨床経験年数」「紹介率」の２項目について医師情報ＤＢ２００に所定の入力を行わせ、評価を行うべく構成される。ここで、紹介率とは、例えば、「個人への紹介例数」と「内科への紹介で主治医となった例数」との和を「内科全体の紹介例 数」で割った値の百分率である。医師評価装置９００は、「臨床経験年数」に関しては、臨床経験年数に応じたポイントを割り付けるべく構成される。「紹介率」に関しては、紹介率に応じたポイントを割り付けるべく構成される。そして、医師評価装置９００は、「臨床経験年数」「紹介率」の２項目におけるポイントの合計を臨床評価のポイント数として算出する。
【0127】
＜処理の流れ＞
図１５を参照しながら、本実施形態のシステム３が実行する医師と医療機関とのマッチング方法の処理の流れについて説明する。図１５は、本発明の第三実施形態に係る、マッチング方法に係る概略説明図である。
図１５を参照しながら、本実施形態のシステム３が実行する医師と医療機関とのマッチング方法の処理の流れについて説明する。図１５は、本発明の第三実施形態に係る、マッチング方法に係る概略説明図である。
【0128】
以下において、図１５に基づいて、医師が医師用転職支援システムを用いて転職先となる医療機関を検索する場合について説明する。
【0129】
ここで、本システム３を利用するために、医師情報ＤＢ２００には、転職を希望する医師によって情報が入力されているものとする（ステップＳ３０１）。また、求人情報ＤＢ３００には、医療機関の医師求人担当者によって求人情報が入力されているものとする（ステップＳ３０２）。
【0130】
まず、転職先を検索する医師は、医師用端末７００を用いてマッチングシステム３にアクセスし、適宜の検索条件、すなわち、希望する勤務条件等を入力して検索を開始する（ステップＳ３０３）。
【0131】
マッチングシステム３は、入力された検索条件に基づいて検索を実行し、検索結果を医師用端末７００に出力する（ステップＳ３０４）。
【0132】
上記の検索結果を確認した医師は、転職先として適当と思われる医療機関が見つかった場合には、マッチングシステム３に対して引き合わせ要求を行う（ステップＳ３０５）。
【0133】
引き合わせ要求を受けたマッチングシステム３は、医師が指定した医療機関の求人担当者に引き合わせ依頼があることを通知して（ステップＳ３０６）、当人同士での打合せを行わせる。
【0134】
打合せの結果、医療機関による医師の採用が決定した場合には、採用した医療機関の求人担当者は、マッチングシステム３に対して採用決定登録を行う（ステップＳ３０７）。
【0135】
＜医師の初期登録＞
なお、マッチングシステム３を使用する医師は、ユーザー登録として医師情報ＤＢ２００に所定の情報の登録を予め行う。図１６は、医師情報ＤＢ２００におけるデータ登録のフローチャートである。
なお、マッチングシステム３を使用する医師は、ユーザー登録として医師情報ＤＢ２００に所定の情報の登録を予め行う。図１６は、医師情報ＤＢ２００におけるデータ登録のフローチャートである。
【0136】
図１６に示すように、医師が、医師用端末７００を用いて仲介サーバ４００にアクセスすると（ステップＴ３０１）、仲介サーバ４００は、医師用端末７００の画面に医師用登録情報入力画面（不図示）を表示し、当該医師用登録情報入力画面に設けた入力欄に入力を行わせる。入力の終了後、入力情報は仲介サーバ４００に送信される（ステップＴ３０２）。
【0137】
仲介サーバ４００は、送信されてきた入力情報を医師情報ＤＢ２００に登録し保存する（ステップＴ３０３）。なお、医師情報ＤＢ２００への登録にともなって、管理ＩＤ又はパスワードの発行が行われても良い。
【0138】
医師用登録情報入力画面には、少なくとも、医師の氏名、生年月日、連絡先住所、連絡 先電話番号、Ｅ－ｍａｉｌアドレス等の基本情報と、専門科目、職歴、希望科目、希望給 与、希望勤務地、開業希望等の勤務条件情報の入力欄とが設けられている。
【0139】
なお、医師がマッチングシステム３を利用する場合には、上記した医師の能力評価に必要となる「人物評価 」「学会評価」「研究業績評価」「治療経験評価」「臨床評価」の５項目の基礎情報の入力までを行わせるべく構成される。この場合、第三者による評価が必要な項目があるため、必要に応じてマッチングシステム３の管理者、すなわちマッチングシステム３を管理・運営している医療関連業者の担当者と医師とが直接面談を行って、所定の情報を収集してもよい。
【0140】
＜医療機関の初期登録＞
なお、マッチングシステム３を使用する医療機関の求人担当者は、ユーザー登録として求人情報ＤＢ３００に所定の情報の登録を予め行う。図１６は、求人情報ＤＢ３００におけるデータ登録のフローチャートである。
なお、マッチングシステム３を使用する医療機関の求人担当者は、ユーザー登録として求人情報ＤＢ３００に所定の情報の登録を予め行う。図１６は、求人情報ＤＢ３００におけるデータ登録のフローチャートである。
【0141】
医療機関の求人担当者が、求人端末８００を用いて仲介サーバ４００にアクセスすると（ステップＴ３０４）、マッチングシステム３は求人端末８００の画面に求人情報入力画面（不図示）を表示し、当該求人情報入力画面に設けた入力欄に入力を行わせる。入力の終了後、入力情報は仲介サーバ４００に送信される（ステップＴ３０５）。仲介サーバ４００は、送信されてきた入力情報を求人情報として求人情報ＤＢ３００に登録し保存する（ステップＴ３０６）。なお、求人情報ＤＢ３００への登録にともなって、管理ＩＤ又はパスワードの発行が行われても良い。
【0142】
求人情報入力画面には、少なくとも、医療機関の名称、所在地、施設情報、担当者名 、連絡先電話番号等の基本情報と、求人科目、年齢制限情報、勤務条件、福利厚生設備情 報等の採用条件情報の入力欄とが設けられている。
【0143】
＜医師による転職先（医療機関）の検索＞
以下において、図１５に示したように医師が転職先を検索すべくマッチングシステム３を使用する場合におけるマッチングシステム３の動作について、図１７を用いて説明する。図１７は、 医師がマッチングシステム３を使用する場合のマッチング方法に係るフローチャートである。
以下において、図１５に示したように医師が転職先を検索すべくマッチングシステム３を使用する場合におけるマッチングシステム３の動作について、図１７を用いて説明する。図１７は、 医師がマッチングシステム３を使用する場合のマッチング方法に係るフローチャートである。
【0144】
まず、マッチングシステム３を用いて検索を行う医師は、医師用端末７００を用いて仲介サーバ４００にアクセスする（ステップＴ４０１）。ここで、本実施形態では、医師は、転職先として医療機関を希望しているものとし、マッチングシステム３において求人情報の検索を行うものとする。
【0145】
仲介サーバ４００にアクセスすると、マッチングシステム３は、医師用端末７００の画面に検索条件入力画面（図示せず）を表示し、医師は、医師用端末７００の入力装置を用いて同検索条件入力画面に設けた入力欄に入力を行い、入力の終了後、検索条件を仲介サーバ４００に送信する（ステップＴ４０２）。
【0146】
仲介サーバ４００では、医師用端末７００から送信されてきた検索条件に基づいて検索を開始する（ステップＴ４０３）。
【0147】
検索の結果、検索条件にヒットした求人情報の登録情報がなかった場合には（ステップ Ｔ４０４におけるＹＥＳ）、仲介サーバ４００は、医師用端末７００にヒット件数が０件であるという情報を送信し、医師用端末７００の画面にその旨を表示する。
【0148】
医師は、ヒット件数が０件で合った場合には、医師用端末７００を介して、検索を終了するか、又は、検索条件を変更して再度検索を実行するかを選択し（ステップＴ４０５）、再度検索を実行する場合には、ステップＴ４０２に戻って検索条件の再入力を可能とする。
【0149】
一方、検索条件に基づく検索の結果（ステップＴ４０３）、ヒットした求人情報があった場合には（ステップＴ４０４におけるＮＯ）、仲介サーバ４００は、医師用端末７００の画面に検索結果の表示を行う（ステップＴ４０６）。
【0150】
医師は、医師用端末７００の画面に表示された検索結果において、求人担当者との面談を希望する求人条件の医療機関を見出した場合には、仲介サーバ４００に対して当該医療機関の求人担当者との面談の要求を行う（ステップＴ４０７）。
【0151】
なお、面談を希望する求人情報の医療機関がなかった場合にはステップＴ４０２に戻り、検索条件を変更しての再検索を可能としている。
【0152】
面談の要求を受けた仲介サーバ４００は、面談日時の設定を行い（ステップＴ４０８）、医師と医療機関の求人担当者に面談日時の通知を行って両者を引き合わせる。面談日時の通知は、Ｅ－ｍａｉｌの他にも、ＬＩＮＥ、Ｓｌａｃｋ等のＳＮＳサイトを用いた通知であってもよいし、電話連絡であってもよく、面談日時情報を通知することができればよい。
【0153】
医師は、マッチングシステム３からの面談日時の通知を確認し、また、医療機関の求人担当者もマッチングシステム３からの面談日時の通知を確認し、所定の面談日時において医師と医療機関の求人担当者とが面談を行う。
【0154】
面談の結果、両者が合意に達しない場合には、そのまま終了し、 両者が合意した場合には、医師は合意に基づいて設定された勤務開始日から医療機関に勤務する。
【0155】
一方、医療機関の医師求人担当者は、求人端末８００を用いてマッチングシステム３にアクセスし、求人端末８００の画面にマッチングシステム３の採用決定登録画面（不図示）を表示させ、当該採用決定登録画面に設けた入力欄に求人端末８００の入力装置を用いて入力を行い、入力した採用決定情報をマッチングシステム３に送信して採用決定登録を行う。
【0156】
採用決定情報を受信したマッチングシステム３は、医師情報ＤＢ２００に登録された採用が決定した医師の登録情報を削除し、さらに、求人情報ＤＢ３００に登録された採用が決定した求人情報を削除する。
【0157】
従来、医師国家試験に合格することにより医師となった者は、出身大学の医局に入局し 、医局の人事に基づいて勤務先が決定されていることが多い。かかる医局は、医師の人事に極めて強い影響力を有しており、医局から外れて医師として仕事をする場合には自身で開業するか、民間の医療機関に勤務する方法があるものの、 医局に所属する医師がそのような選択を行った場合には、それ以後は医局の人事管理から外れることによって、その医師の自己管理負担が極めて大きくなるために、医局から離脱しにくくなっていた。
【0158】
かような背景の下で、医療機関により良い人材を紹介して、医療機関の繁栄あるいは医療機関の存続を図る一方で、転職を希望する医師には、その医師の能力に応じた転職先を紹介することにより医師の転職を促すことができる転職支援システムの実現が求められていた。
【0159】
この点、本実施形態に係るマッチングシステム３によれば、仲介サーバ４００には、登録された技能情報に基づいて医師の能力評価を行う能力評価手段を設けたことによって、当該能力評価手段によって医師情報ＤＢ２００に登録された医師の客観的な差別化を行うことができ、医師を採用する採用先により適合した医師の判別を行いやすくすることができる。したがって、転職を希望する医師と転職先の医療機関との適合性を向上させることができるので、転職を希望する医師が極めて容易に転職先を見つけ得る。
【0160】
以上、開示に係る実施形態について説明したが、これらはその他の様々な形態で実施することが可能であり、種々の省略、置換および変更を行なって実施することが出来る。これらの実施形態および変形例ならびに省略、置換および変更を行なったものは、特許請求の範囲の技術的範囲とその均等の範囲に含まれる。
【符号の説明】
【0161】
１、２、３ マッチングシステム １００ データベース、２００ 求人者端末、３００ 求職者端末、４００ 仲介サーバ、ＮＷ ネットワーク
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
