JP2024103987A - Business information providing system, computing device, and method - Google Patents

Abstract

To provide an applicant with information capable of understanding capability which is taken as important in a labor market.SOLUTION: A work information provision system (1) which provides an applicant applying a recruiting business with work information on the recruiting business comprises: an applicant device (300) operated by the applicant; and a computer device (100) which can communicate with the applicant device (300), and access a database in which the work information is registered for each offering matter. The computer device (100) estimates evaluation of the labor market with respect to the capability about the work for each type of the capability about the work, on the basis of the work information included in each of the plurality of offering matters, and displays an estimated result on the applicant device (300).SELECTED DRAWING: Figure 1

Description

This disclosure relates to a job information providing system, computing device, and method for providing job information of a job to applicants who apply for the job.

Many applicants flock to jobs with favorable conditions. In order to be selected from among many other applicants, applicants must make an effort to constantly improve their skills so that they can demonstrate their high capabilities to the job seeker.

Patent document 1 describes a career counseling system that provides users with additional courses based on their career history to meet the recruitment requirements of companies.

JP 2003-331093 A

According to the system described in Patent Document 1, a user can acquire new skills by studying additional courses based on their career history. However, it is unclear whether the new skills acquired based on their career history match the skills required in the labor market. For this reason, there is a possibility that the user's efforts to acquire new skills will be wasted.

This disclosure has been made to address the above-mentioned issues, and its purpose is to provide applicants with information that will enable them to understand the skills that are valued in the labor market.

The job information providing system according to a first aspect of the present disclosure is a job information providing system that provides job information of a job to an applicant who applies for the job, and includes an applicant device operated by the applicant, and a computing device that communicates with the applicant device and can access a database in which job information is registered for each recruitment case, and the computing device estimates the labor market's evaluation of job-related abilities by type of job-related ability based on the job information included in each of a plurality of recruitment cases, and displays the estimation results on the applicant device.

A computing device according to a second aspect of the present disclosure is a computing device that provides job information of a job to an applicant who applies for the job, and includes a communication interface that communicates with an applicant device operated by the applicant, and a processor that accesses a database in which the job information is registered, and the processor estimates the labor market's evaluation of job-related abilities by type of job-related ability based on the job information included in each of a plurality of recruitment cases, and displays the estimation results on the applicant device.

A method according to a third aspect of the present disclosure is a method for providing job information of a job to an applicant who applies for the job, and includes the steps of communicating with an applicant device operated by the applicant, accessing a database in which the job information is registered, and estimating a labor market evaluation of job-related abilities by type of job-related ability based on the job information included in each of a plurality of recruitment cases, and displaying the estimation results on the applicant device.

This disclosure makes it possible to provide applicants with information that allows them to understand the skills that are valued in the labor market.

1 is a block diagram showing an overview of a matching system as an example of a business information providing system. 2 is a block diagram showing the configurations of a sharing server, a recruiter device, and an applicant device. FIG. FIG. 2 is a diagram illustrating an example of a company database. FIG. 4 is a diagram illustrating an example of a member database. FIG. 4 is a diagram illustrating an example of a community database. FIG. 2 is a diagram illustrating an example of a recruitment request database. FIG. 13 is a diagram showing an example of a side job database. FIG. 4 is a diagram illustrating an example of an evaluation input database. FIG. 13 is a diagram illustrating an example of an evaluation summary database. 2 is a diagram for explaining functions of a sharing server, a recruiter device, and an applicant device. FIG. 2 is a diagram for explaining functions of a sharing server, a recruiter device, and an applicant device. FIG. 2 is a diagram for explaining functions of a sharing server, a recruiter device, and an applicant device. FIG. FIG. 2 is a diagram for further explaining the function of the applicant device. FIG. 13 is a diagram for explaining a procedure for registering a recruitment request in a recruitment request database. FIG. 13 is a diagram for explaining a procedure for searching for recruitment requests from a database. 13 is a diagram for explaining the procedure for registering side job plans and results in a database. FIG. FIG. 13 is a diagram for explaining the procedure for registering an evaluation of an applicant in a database. FIG. 13 is a diagram for explaining the procedure for registering an evaluation of a recruiter in a database. 13 is a diagram for explaining a procedure for displaying evaluations of applicants and search results of members on a display. FIG. A diagram for explaining the procedure for displaying evaluations of recruiters and search results of members on a display. FIG. 13 is a diagram for explaining the viewable range of the evaluation summary database. FIG. 13 is a diagram showing an example in which a disclosure range is set according to a disclosure level. 13 is a diagram showing a screen displayed on the applicant device of a manager (applicant's boss) when the manager checks the side job status of his/her subordinates. FIG. FIG. 2 is a diagram showing details of job content contained in a recruitment job database. FIG. 1 is a diagram showing an overview of a recommendation function provided in the matching system. FIG. 13 is a diagram showing an example of a market value map. FIG. 13 is a diagram showing another example of a market value map. FIG. 13 is a diagram showing another example of a market value map. FIG. 4 is a diagram illustrating an example of a profile database. FIG. 13 is a diagram illustrating an example of a capability database. FIG. 13 is a diagram showing a specific example of a capability ID. FIG. 13 is a diagram showing a specific example of a skill ID. FIG. 13 is a diagram showing a specific example of an experience ID. A figure showing an example of forming a skill ID by combining multiple skills. 13 is a flowchart showing a processing procedure related to a recommendation function of the matching system. 13 is a flowchart showing a processing procedure of a case information acquisition unit. 13 is a flowchart showing a processing procedure of a labeling unit. 13 is a flowchart showing a processing procedure of a calculation unit. 13 is a flowchart showing a processing procedure of a capability information acquisition unit; 13 is a flowchart showing a processing procedure of a recommendation unit. 13 is a flowchart showing a processing procedure of a display unit. 13 is a flowchart showing a processing procedure of a recalculation unit. 13 is a diagram for explaining the functions of a sharing server, a recruiter device, and an applicant device according to the first modified example. FIG. FIG. 13 is a diagram showing an example of a member database according to the first modified example. 13 is a flowchart showing the processing steps of a counter offer member search process according to the first modified example. FIG. 11 is a block diagram showing the configurations of a sharing server, a recruiter device, and an applicant device according to the second modified example. FIG. 13 is a diagram showing an example of a member group database according to the second modified example. FIG. 13 is a diagram showing an example of a recruitment request database according to the second modified example. A diagram for explaining the functions of a sharing server, a recruiter device, and an applicant device related to Modification 2. FIG. 13 is a diagram for explaining the procedure for registering a recruitment request related to the modified example 2 in the recruitment request database.

The following describes in detail the embodiments of the present disclosure with reference to the drawings. Note that the same or corresponding parts in the drawings are given the same reference numerals and their description will not be repeated.

[Background to proposing Matching System 1]
1 is a block diagram showing an overview of a matching system 1, which is an example of a business information providing system. First, the background for proposing the matching system 1 in this embodiment will be described.

The matching system 1 is used, for example, in crowdsourcing between companies. Crowdsourcing is generally a process of soliciting contributions from an unspecified number of people to obtain needed services, ideas, or content.

Many companies are encouraging side jobs to make effective use of their human resources. By using crowdsourcing between companies, the capabilities of employees can be utilized.

However, if typical crowdsourcing methods are applied directly between companies, the following problems may arise:

[Possibility of confidential information being leaked]
In general crowdsourcing methods, the relationship between the client company and the recipient company is not taken into consideration, so adopting crowdsourcing entails corporate and personal risks. For example, there is a risk that confidential information may be leaked to rival companies through an employee's side job. With conventional crowdsourcing methods, managers cannot confirm that employees are not accepting projects from competitors as side jobs.

[Possibility of overwork]
If a company allows its employees to have a side job, there is a risk that the employees' working hours will become excessively long. To eliminate the risk of overwork, the company could set an upper limit on the number of overtime hours, including the main job and the side job. However, as long as employees are free to take on side jobs, it will be difficult for companies to control the amount of time that employees spend on side jobs. As a result, there is a risk that employees will end up overworked.

[The results of your side job may not be properly evaluated]
Conventionally, there are crowdsourcing systems that request clients to evaluate contractors. When appropriate evaluations made by clients are shared on the crowdsourcing system, those who are looking for contractors for the work can refer to the evaluations and select highly capable individuals from among the many people who wish to receive the work.

However, a client of a certain company may be so concerned about the contractors of other companies that they are being evaluated that they enter a higher evaluation into the system than the actual evaluation. A client of a certain company may also avoid giving a low evaluation to contractors of other companies, fearing that this could worsen relations between the companies. Furthermore, a client may not see any benefit in making an evaluation and enter an evaluation into the system that is far removed from the actual evaluation. Taking these possibilities into consideration, there is a risk that the reliability of the evaluations provided by the system will decrease. In this case, even if evaluations of contractors are shared, the client of the work will not be able to use the evaluations as reference data when selecting a contractor.

[Possibility of not obtaining accurate information about recruiters]
In the above-mentioned crowdsourcing system, applicants who wish to apply for jobs will select jobs that satisfy them while taking into consideration the content of the jobs and the remuneration. However, among the recruiters, there may be those who frequently make additional requests outside the scope of the contracted work or instruct changes to the content of the work. Applicants will want to avoid such recruiters and apply for the jobs. Conversely, there are also recruiters who do not cause any problems until the work is completed. Applicants will want to apply for jobs recruited by such recruiters, if possible. Therefore, it is desirable to widely share not only the evaluation of applicants (contractors) but also the evaluation of recruiters (clients) in the crowdsourcing system.

If appropriate evaluations of job seekers are shared on a crowdsourcing system, people looking to apply for jobs can use those evaluations as a reference to select a job that satisfies them from among the many available jobs, taking into account the job seeker's past transaction history, etc.

However, when constructing an evaluation system that allows evaluation of recruiters, problems similar to those when constructing an evaluation system that allows evaluation of contractors can arise. That is, a contractor (applicant) of a certain company may input a higher evaluation into the system than the actual evaluation, out of consideration for the client (recruiter) of the other company being evaluated. Also, a contractor (applicant) of a certain company may avoid giving a low evaluation to the client (recruiter) of the other company, out of concern that this may worsen the relationship between the companies. Furthermore, contractors (applicants) may not see any benefit in providing an evaluation and may input an evaluation into the system that is far removed from the actual evaluation. Considering these possibilities, there is a risk that the reliability of the evaluation provided by the system will decrease. In this case, even if evaluations of recruiters are shared, applicants will not be able to use the evaluations as reference data when selecting recruiters.

[Special characteristics of having companies act as the matching body]
In general, in order to match talent and jobs across companies, a close relationship such as trust between the companies matching talent and jobs is required. Therefore, for example, it is very difficult to match talent and jobs across companies that do not have capital ties. In addition, large companies such as listed companies are prone to compete with other companies from the perspective of diversification, etc., and cannibalization occurs between other companies, so there are special circumstances in which talent and jobs cannot be matched between many companies.

[Difficulties in developing skills to meet labor market needs]
Many applicants are attracted to jobs with good conditions, such as jobs with high remuneration. In order to be selected as a contractor from among many applicants, applicants need to make an effort to constantly improve their abilities so that they can appeal to the employer with their high capabilities.

However, it is not realistic for applicants to make an effort to improve their skills in all of the many specialized fields that exist in the world.

In Japan, the retirement age has been extended due to amendments to the Act on Stabilization of Employment of Elderly Persons, and an obligation to make an effort to secure employment opportunities until the age of 70 has been established. For this reason, the utilization of senior human resources is being promoted in Japan. If senior human resources remain in a company longer than usual, it will become difficult to hand over existing work to younger people. This can be a factor that hinders the metabolism of a company. Therefore, in order to enable senior human resources who have handed over existing work to younger people to play an active role, senior human resources are being required to receive reskilling and recurrent education.

As AI (Artificial Intelligence) technology rapidly penetrates the industrial sector of every country, the needs of human resources in the labor market are likely to change rapidly. For this reason, the need for reskilling and recurrent education is not limited to senior Japanese workers.

However, it is difficult for individuals to analyze and understand the needs of the human resources required in the labor market. If the skills that have been acquired through hard work do not match the needs of the labor market, the effort to acquire new skills may be in vain.

In addition, since it is not easy to acquire new skills that are unrelated to those already acquired, it is desirable for those who wish to succeed in the labor market to acquire skills that are highly compatible with the skills they already possess. This is especially true for senior workers.

In this embodiment, we propose a matching system 1, which is described in detail below, with the aim of solving at least one of the various problems mentioned above that conventional crowdsourcing faces.

[overall structure]
The general configuration of the matching system 1 will be described with reference to Fig. 1. The matching system 1 includes a sharing server 100, recruiter devices 200A, 200B, 200C..., and applicant devices 300A, 300B, 300C....

The sharing server 100 provides a matching service to many companies that matches business orders and receipts between companies. Figure 1 shows company A, company B, company C, etc. as examples of companies that use the matching service. Company A, company B, company C, etc. are registered as corporate members of the matching system 1. Employees of company A, company B, company C, etc. who use the matching system 1 are also individually registered as members of the matching system 1.

The work arranged in matching system 1 is, for example, temporary work that is expected to be completed in a predetermined period of time. Therefore, a person who accepts a work arranged in matching system 1 will work in the specific department to which they belong within the company as their main job, and will be engaged in each of the jobs arranged in matching system 1 as a side job. Note that in matching system 1, for example, an applicant from company A can also accept work from company A. Therefore, in matching system 1, an applicant who belongs to a different department Y of company A is also permitted to accept work from department X of company A.

Hereinafter, a job for which contractors are being recruited in the matching system 1 may be referred to as a "recruited job" or a "recruited case", a person providing a recruited case may be referred to as a "recruiter", and a person applying to receive an order for a recruited case may be referred to as an "applicant". Applying for a recruited job may be referred to as an "application for the recruited job" or an "application for the recruited case".

An applicant who accepts a job offer is referred to as the "contract recipient," and a recruiter who places an order with the contractor is referred to as the "orderer." In the following, however, the term "applicant" may include the "contract recipient," and the term "recruiter" may include the "orderer."

A database 120 necessary for the matching service is constructed in the sharing server 100. The database 120 includes various databases in which information necessary for providing the matching service is registered. For example, information on members and recruitment operations is registered in the database 120. The sharing server 100 is managed and operated by a company separate from the companies that use the matching service. Any of the companies that use the matching service may manage and operate the sharing server 100.

Recruiter device 200A is operated by an administrator of company A. Recruiter device 200B is operated by an administrator of company B. Recruiter device 200C is operated by an administrator of company C. Hereinafter, recruiter devices 200A, 200B, 200C... may be collectively referred to as "recruiter device 200."

Applicant device 300A is operated by an applicant from company A. Applicant device 300B is operated by an applicant from company B. Applicant device 300C is operated by an applicant from company C. Hereinafter, applicant devices 300A, 300B, 300C... may be collectively referred to as "applicant device 300". Although two applicants are depicted for each company in FIG. 1, the number of applicants is not limited to this. There may be more applicants for each company, or a company may have only one applicant. Sharing server 100 may also accept applicants who do not belong to a company, such as freelancers.

In this embodiment, the managers of companies A, B, C, etc. will act as recruiters. Therefore, hereinafter, the managers of each company may be referred to as "recruiters." Recruiters can also act as applicants for jobs being recruited by other recruiters. In that case, the recruiter device 200 functions as the applicant device 300. In this embodiment, when a company manager acts as a recruiter, the device that the manager uses to use the matching service will be referred to as the recruiter device 200.

Company A may have one or more managers. When company A has managers, each manager may be given a recruiter device 200, or one recruiter device 200 may be shared by multiple managers. The same applies to companies B, C, etc.

The sharing server 100 and the recruiter device 200 are configured to be able to communicate with each other via the Internet 50, which is an example of a communication line network. The sharing server 100 and the applicant device 300 are configured to be able to communicate with each other via the Internet 50.

When accepting access from the recruiter device 200, the sharing server 100 requests sign-in with the input of a member ID and password. Similarly, when accepting access from the applicant device 300, the sharing server 100 requests sign-in with the input of a member ID and password. The sharing server 100 identifies each recruiter and applicant by the member ID notified at the time of sign-in.

The recruiter device 200 accepts various operations by the recruiter. For example, the recruiter device 200 accepts operations such as inputting a recruitment case (requested work), inputting an evaluation of a contractor who has completed a job, and searching for members of the matching service.

The recruiter device 200 communicates with the sharing server 100 in response to each operation on the recruiter device 200. The sharing server 100 registers a recruitment request in the database 120 in response to an operation of inputting a recruitment request (requested work), registers an evaluation of the target applicant (contractor) in the database 120 in response to an operation of inputting an evaluation, and provides member information to the recruiter device 200 in response to an operation of searching for members.

The applicant device 300 accepts various operations by the applicant. For example, the applicant device 300 accepts operations such as searching for job openings, applying for job openings, inputting work results, and inputting an evaluation of the recruiter (client).

The applicant device 300 communicates with the sharing server 100 in response to each operation on the applicant device 300. The sharing server 100 provides the applicant device 300 with appropriate recruitment requests in response to an operation to search for recruitment requests, issues a notice of acceptance or rejection to the applicant device 300 in response to an operation to apply for a recruitment request, registers the work results in the database 120 in response to an operation to input the work results, and registers an evaluation of the target recruiter (client) in the database 120 in response to an operation to input an evaluation.

As described above, the matching system 1 includes an evaluation system that evaluates job applicants (contractors) and recruiters (orderers), and a recruitment system that recruits job applicants.

A recruiter belonging to one department of company A can use matching system 1 to hire an applicant belonging to another department of company A as a contractor for a job.A recruiter belonging to company A can use matching system 1 to hire an applicant belonging to company B as a contractor for a job.

Members who use the matching system 1 access the sharing server 100 as recruiters or applicants. In the following, members of the matching system 1 may be referred to as "users." In addition, in the following, the recruiter device 200 and applicant device 300 operated by members may be collectively referred to as "user device 500."

As shown in FIG. 1, a labor market map is displayed on the screen 550 of the user device 500. The labor market map displays the magnitude of value in the labor market by ability. The labor market map also displays the size of the labor market by ability. By looking at the labor market map, the user can understand what abilities are considered important in the labor market from the perspective of value and size.

The capabilities possessed by a user are identified, for example, from skills and years of experience. Skills include national qualifications. By looking at the labor market map, a user can understand the value that the labor market places on "ability X," for example, "possessing national qualification A and having N years of work experience related to national qualification A."

In addition, by looking at the labor market map, users can understand the size of the labor market in which such "ability X" is needed. Hereinafter, the value of ability in the labor market may be referred to as "market value," and the size of ability in the labor market may be referred to as "market size."

The labor market map further displays the relationship between the user's own abilities and the market value, as well as the relationship between the user's own abilities and the market size. Screen 550 illustrated in FIG. 1 displays that the user's own abilities have a low market value and a medium market size.

By looking at the labor market map, users can understand the relationship between their own abilities and market value, as well as the relationship between their own abilities and the size of the market. Based on this, users can analyze what skills they should develop in the future.

Figure 2 is a block diagram showing the configuration of the sharing server 100, the recruiter device 200, and the applicant device 300.

[Configuration of sharing server 100]
The sharing server 100 includes a processor 101 , a memory 102 , a storage 103 , and a communication interface 104 .

The memory 102 may include a random access memory (RAM), a read only memory (ROM), a flash memory, or any other suitable memory system. The memory 102 stores programs necessary for the arithmetic processing of the processor 101, temporary data calculated in the arithmetic processing, and the like.

The storage 103 is composed of a hard disk drive, a solid state drive, and the like. The storage 103 stores a database 120. The database 120 includes multiple types of databases. The multiple types of databases include a company database (company DB) 121, a member database (member DB) 122, a community database (community DB) 123, a job posting database (job posting DB) 124, a side job database (side job DB) 125, an evaluation input database (evaluation input) 126, an evaluation summary database (evaluation summary DB) 127, and numerous other databases.

Some of these multiple types of databases may be stored in storage provided separately from the sharing server 100. For example, the sharing server 100 may be connected to a cloud service separate from the sharing server 100, and some of the multiple types of databases shown in FIG. 2 may be stored on that cloud. In this case, the sharing server 100 can access the necessary databases by communicating with the cloud via the Internet 50.

The processor 101 connects to the Internet 50 via the communication interface 104 in accordance with the program stored in the memory 102. The processor 101 connects to the Internet 50 and communicates with the recruiter device 200 and the applicant device 300. The processor 101 accesses the database 120 and executes processes such as extracting necessary data, registering new data in the database 120, and updating data registered in the database 120.

[Configuration of recruiter device 200]
The recruiter device 200 includes a processor 201, a memory 202, a communication interface 203, an input/output interface 204, a display 205, and an operation unit 206. The operation unit 206 is composed of a mouse, a keyboard, and the like.

The memory 202 includes a random access memory (RAM), a read only memory (ROM), a flash memory, or any other suitable memory system. The memory 202 stores programs necessary for the arithmetic processing of the processor 201, temporary data calculated in the arithmetic processing, and the like.

The processor 201 connects to the Internet 50 via the communication interface 203 in accordance with the program stored in the memory 202. The processor 201 connects to the Internet 50 and communicates with the sharing server 100. The processor 201 communicates with the sharing server 100 and executes processes such as sending recruitment requests, displaying information on applicant members on the display 205, ordering work from a contractor selected from among the applicants, and sending the contents of the evaluation of the contractor entered by the recruiter to the sharing server 100.

The information input by operating the operation unit 206 is notified to the processor 201 via the input/output interface 204.

[Configuration of applicant device 300]
The applicant device 300 comprises a processor 301, a memory 302, a communication interface 303, an input/output interface 304, a display 305, and an operation unit 306. The operation unit 306 is made up of a mouse, a keyboard, and the like.

Memory 302 includes a random access memory (RAM), a read only memory (ROM), a flash memory, or any other suitable memory system. Memory 302 stores programs necessary for the arithmetic processing of processor 301, temporary data calculated in the arithmetic processing, etc.

The processor 301 connects to the Internet 50 via the communication interface 303 in accordance with the program stored in the memory 302. The processor 301 connects to the Internet 50 and communicates with the sharing server 100. The processor 301 communicates with the sharing server 100 and executes processes such as applying for a job, displaying a notice of acceptance or rejection of the job on the display 305, transmitting the performance of the work received to the sharing server 100, and transmitting the contents of the evaluation of the recruiter entered by the applicant to the sharing server 100.

Information entered by operating the operation unit 306 is notified to the processor 301 via the input/output interface 304.

[Overview of database 120]
An overview of the database 120 will be described below. The company database 121 stores information on companies affiliated with the matching system 1. The member database 122 stores information on members who use the matching system 1. Many of the members are employees of companies affiliated with the matching system 1.

Members registered in the member database 122 can act as recruiters (orderers) or applicants (recipients) by using the matching system 1. Members may include employees of companies registered in the company database 121 as well as individuals (freelancers) who are not affiliated with a company.

In the community database 123, information for identifying companies belonging to a community is stored. A community is formed by agreement between companies. Therefore, multiple communities can be formed depending on how the agreement is reached between the companies. The number of companies belonging to one community can also be set in various ways. Between companies having a community relationship, a relationship of trust is formed to the extent determined by the manner of agreement when forming the community. In the community database 123, information for identifying companies belonging to the community is registered for each community.

The job posting database 124 stores jobs (job postings) for which contractors are being recruited. Employees of each company can work in their own department as a main business within the company, and as members of the matching system 1, they can accept jobs from other departments of their own company or jobs from other companies that are registered in the job posting database 124. In this case, members accept jobs from other departments of their own company or jobs from other companies as a side job.

In the side job database 125, data indicating the side job status is registered for each member. The data indicating the side job status includes information such as side job results and side job plans.

The evaluation input database 126 stores evaluation information for applicants (contractors) and evaluation information for recruiters (clients). By using the matching system 1, recruiters (clients) can evaluate the work of applicants (contractors) who have completed a job as an evaluator. By using the matching system 1, applicants (contractors) can evaluate the recruiters (clients) as an evaluator. The evaluations made by each evaluator are registered in the evaluation input database 126.

Evaluation summaries are registered in the evaluation summary database 127. Evaluation summaries are registered for each member in the evaluation summary database 127. The evaluation summaries include a recruiter evaluation summary and an applicant evaluation summary. The recruiter evaluation summary indicates the level of evaluation when the member behaved as a recruiter (orderer). The applicant evaluation summary indicates the level of evaluation when the member behaved as an applicant (recipient of an order). The recruiter evaluation summary is created based on the applicant's evaluation of the recruiter. The applicant evaluation summary is created based on the recruiter's evaluation of the applicant.

Members can view the evaluation summaries. Recruiters can view each member's applicant evaluation summaries and select the member they deem appropriate as the contractor. Applicants can view each member's recruiter evaluation summaries and apply for work from the recruiter they deem appropriate.

[Company Database 121]
FIG. 3 is a diagram showing an example of the company database 121. In the company database 121, a company ID for identifying the company, a company name, a company address, and a side job upper limit time are registered for each company. The side job upper limit time is the upper limit time that an employee is permitted to work as a side job in addition to his/her main job. The side job upper limit time is set for each company. For example, the side job upper limit time can be calculated by "prescribed overtime hours - overtime hours of the main job other than the side job". The "prescribed overtime hours" differ depending on the company. Note that while FIG. 3 shows the side job upper limit time in months, it may also be set in weeks. The unit of the side job upper limit time may also be set for each company.

In this embodiment, members are permitted to apply for and accept work from various companies and departments, as long as it does not exceed the side job time limit set by the company to which the member belongs.

[Member database 122]
4 is a diagram showing an example of the member database 122. Various information about the member is registered in the member database 122. The various information about the member includes a member ID for identifying the member, the ID of the company to which the member belongs, the member's name, the member's authority, the department to which the member belongs, and the amount of time allowed for side work.

Types of member authority include administrator and applicant. A member with administrator authority is given the authority to use the matching system 1 as a recruiter and an applicant. A member with applicant authority is given the authority to use the matching system 1 as an applicant, but is not given the authority to use the matching system 1 as a recruiter. Department heads within a company are given administrator authority to manage the side jobs of their subordinates within their departments. Managers with administrator authority are given the authority to approve applications from their subordinate applicants. Thus, managers function as approvers.

The available side job time is the remaining time available for engaging in a side job. The available side job time is calculated by "maximum side job time - total side job time". If the subject is engaged in multiple side jobs, the total side job time includes the time already spent on those multiple side jobs. The total side job time includes the time already spent on the side job as well as the expected time for the side job. The expected side job time is calculated based on the expected man-hours registered in the job posting database 124. Figure 4 shows the available side job time on a monthly basis. Applicants who use the matching system 1 to search for available jobs are provided with only jobs that can be completed with man-hours within the available side job time as jobs to which they can apply.

[Community Database 123]
5 is a diagram showing an example of the community database 123. Information on communities formed between companies is registered in the community database 123. The community information includes a community ID for identifying the community, a community name, and a list of IDs of companies belonging to the community. Each company can form various communities by reaching an agreement with other companies. A company belonging to a community can change the companies that belong to the community by reaching an agreement with other companies.

[Recruitment job database 124]
6 is a diagram showing an example of the solicited request database 124. Information on solicited requests is registered in the solicited request database 124. The solicited request information includes a request ID for identifying the solicited request, the ID of the company to which the recruiter who registered the solicited request belongs, a list of non-disclosure company IDs, a disclosure level, a request title, an estimated number of man-hours, an estimated period, and a request content.

The non-disclosure company ID list registers the IDs of companies that are prohibited from disclosing recruitment information. The disclosure level is set to one of three levels: "Company", "Within the community", or "All". If the disclosure level is set to "All", applicants outside the community will also be disclosed.

The IDs of the companies that can view the recruitment requests are shown on the right side of the recruitment request database 124 in Figure 6. For example, the recruitment request corresponding to request ID = 001 has the disclosure level set to "our company." In this case, only members belonging to the company that registered the recruitment request (company ID = 00A) can view the recruitment request corresponding to request ID = 001.

Hereinafter, the recruitment cases corresponding to each case ID may be referred to as case 001, case 002, case 003, etc., using the case ID. Similarly, the communities corresponding to each community ID may be referred to as community 01, community 02, community 03, etc., using the community ID, and the members corresponding to each member ID may be referred to as member P1, member P2, member P3, etc., using the member ID. In addition, hereinafter, the companies corresponding to each company ID may be referred to as company A, company B, company C, etc., using part of the company ID.

In case 002, the disclosure level is set to "within the community." According to the community database 123 shown in FIG. 5, the companies that have a community relationship with company A, which registered case 002, are company B and company C. Therefore, as shown in FIG. 6, only members belonging to company A, company B, or company C can view case 002.

Case 003 has the same registered companies and disclosure level as case 002. However, for case 003, "00B" is registered in the non-disclosure company ID list. Therefore, as shown in FIG. 6, only members belonging to either company A or company C can view case 003, and members belonging to company B are not authorized to view case 003.

In the case of a recruitment case where the disclosure level is set to "all," all members can view the target recruitment case. Case 005 shown in Figure 6 is an example of this. If one or more company IDs are registered in the non-disclosure company ID list for case 005, the members belonging to the companies with those company IDs will not be given the authority to view case 005.

The estimated man-hours and estimated period are used by applicants and matching system 1 to estimate the time it will take to process a recruitment request.

[Side Job Database 125]
7 is a diagram showing an example of the side job database 125. Information showing the status of a member's side job is registered for each side job case in the side job database 125. The information showing the status of the side job includes the ID of the member engaged in the side job, the case ID, the month (period of engagement in the side job), planned time for the side job, actual time for the side job, expected time for the side job, and the progress rate.

Planned side job time is the time that a member is expected to need to process an order that has already been placed. Members who have accepted a side job input their planned side job time each month from their applicant device 300. The input planned side job time is reflected in the side job database 125. For example, the expected man-hours for case 001 are set to 5 hours/person/month in the recruited case database 124. This means that the workload is 5 hours per person per month. Usually, members input their planned side job time using the expected man-hours for the recruited case as a guide.

The actual side job time is the time that the member has actually worked on the case that has been accepted. In other words, the actual side job time is the time that the member has already worked as actual work. Each time the member works on the accepted case, until the work is completed, the member inputs the time that the member worked on the case at any timing on the applicant device 300. The cumulative value of the time input on the applicant device 300 is registered in the side job database 125 as the actual side job time for each month.

The expected side job time is the time expected to be required for the work of the target case. In other words, the expected side job time is the time expected as the member's future working hours. The sharing server 100 automatically sets the expected side job time taking into consideration the planned side job time and the actual side job time. The member may be allowed to input the expected side job time on his/her own applicant device 300 at any time until the work of the target case is completed. In addition, the member may be allowed to modify the expected side job time that has been automatically set. It is desirable that the expected side job time be equal to or less than the planned side job time. However, depending on the situation of the case, the expected side job time may be longer than the planned side job time. The member engaged in the case may be allowed to update the expected side job time at any time until the work of the case is completed.

The progress rate indicates the degree of progress of the side job. The progress rate is input at the discretion of the person engaged in the side job. The progress rate is input, for example, between 0(%) and 100(%).

For example, when a member first accepts a project, the progress rate is 0%, the actual side job time is 0 hours, and the planned side job time and expected side job time match. As the member progresses with the project and inputs the actual side job time and progress rate, the expected side job time changes in tandem.

The side job database 125 shown in FIG. 7 shows side job data for member P2 from October 2021 to December 2021. Referring to the side job database 125 shown in FIG. 7, it can be seen that member P2 was engaged in case 001 and case 002 between October 2021 and December 2021.

As data for case 001 for October, the side job database 125 registers planned side job hours = 5, actual side job hours = 10, and expected side job hours = 10. From this, it can be seen that member P2 worked on case 001 beyond the planned side job hours in October.

The November data for case 002 is registered in side job database 125 as planned side job hours = 10, actual side job hours = 4, and expected side job hours = 8. From this, it can be seen that member P2 worked on case 002 in November without exceeding the set expected side job hours. As the progress rate is 50, it can be seen that member P2 completed half of the total work for case 002 in November.

In the side job database 125, the December data for case 001 is registered as planned side job hours = 5 and expected side job hours = 5, but no actual side job hours are registered. Similarly, the December data for case 002 is registered as no actual side job hours. This means that the system is waiting for member P2 to input actual side job hours.

The sharing server 100 calculates the member's additional side-job capacity using the side-job expected time and side-job actual time in the side-job database 125. If the member is engaged in multiple side jobs, the sharing server 100 calculates the "total side-job expected time", which is the sum of the side-job expected time corresponding to those multiple side jobs, and the "total side-job actual time", which is the sum of the side-job actual time corresponding to those multiple side jobs. The sharing server 100 calculates the side-job capacity by calculating "side-job upper limit time - (total side-job expected time + total side-job actual time)". Here, if "total side-job expected time + total side-job actual time" is defined as "total side-job time", the side-job capacity, that is, "available side-job time" is calculated as "side-job upper limit time - total side-job time". For example, in the side-job database 125 shown in FIG. 7, the total side-job expected time, which is the sum of the side-job expected time for member P2 in December, is 15 hours (5 hours + 10 hours). Additionally, the total side job hours for member P2 in December was zero. If the "side job limit" set by the company to which member P2 belongs is 30 hours, then member P2's spare capacity for a side job (available side job hours) is calculated to be 15 hours (30 hours - 15 hours).

Here, we will explain an example of a more specific calculation procedure for expected side job time. For example, the "expected side job time" may be calculated based on the calculation formula "(man-hour progress rate/progress rate) x planned side job time - actual side job time." Here, the "man-hour progress rate" is calculated by "actual side job time/planned side job time." As already explained, the "progress rate" is a rate that is entered into the side job database 125 at the discretion of the person engaged in the side job.

For example, if the planned side job time = 10 hours and the actual side job time = 2 hours, the man-hour progress rate is calculated to be 20%. Let's assume that the progress rate is 40%. In this case, the expected side job time is calculated as "(20% / 40%) x 10 hours - 2 hours" = 3 hours. In other words, according to this calculation result, the expected side job time for the target side job is 3 hours.

[Evaluation Input Database 126]
8 is a diagram showing an example of the evaluation input database 126. Information on evaluations of ratees for ratees is registered in the evaluation input database 126. The evaluation information includes the evaluation target, the member ID of the ratee, the member ID of the evaluator, and the evaluation result.

The evaluation input database 126 includes a recruiter evaluation section 126A and an applicant evaluation section 126B. The recruiter evaluation section 126A stores evaluation information for the recruiter (orderer). The applicant evaluation section 126B stores evaluation information for the applicant (contract recipient).

In the recruiter evaluation section 126A, the target of evaluation (evaluated person) corresponds to the recruiter (client), and the evaluator corresponds to an applicant who applied for the recruitment work of the evaluated person and received the order for the work. In the recruiter evaluation section 126A, evaluations of the evaluated person are registered for each evaluator. Figure 8 shows an example in which members P1 and P2, who correspond to the evaluated person, are evaluated by evaluator members. In particular, Figure 8 shows an example in which member P1 is evaluated by each of evaluator members P5, P7, P11, and P12. The evaluation result (evaluation value) is expressed as a numerical value with 10 as the maximum value and 0 as the minimum value.

In the applicant evaluation section 126B, the evaluation target (evaluatee) corresponds to the applicant (contractor) for the recruitment project, and the evaluator corresponds to the recruiter (orderer) of the project. In the applicant evaluation section 126B, evaluations of the evaluatee are registered for each evaluator. Figure 8 shows an example in which member P7, who corresponds to the evaluatee, has been evaluated by members P1, P2, and P3, who correspond to the evaluators. Note that in Figure 8, examples of evaluation results in the applicant evaluation section 126B are omitted, but various evaluation results are registered there, just like in the recruiter evaluation section 126A.

When an applicant (contractee) completes an order received from a recruiter (orderer), he/she uses the applicant device 300 to evaluate the recruiter (evaluator), who is also the assessee. The evaluator's evaluation results are registered in the evaluation input database 126. When an applicant receives an order for another job from a recruiter who has previously received an order for another job, the applicant evaluates the recruiter again. In this case, the average value of the previous evaluation result and the subsequent evaluation result is registered in the evaluation input database 126.

When an applicant (contractor) completes the work requested of the applicant (contractor), the recruiter (orderer) uses the recruiter device 200 to evaluate the applicant (contractee) as an evaluator. The evaluator's evaluation results are registered in the evaluation input database 126. If a recruiter orders a different work from an applicant who has previously requested work, the recruiter evaluates the applicant again. In this case, the average value of the previous evaluation result and the later evaluation result is registered in the evaluation input database 126.

Therefore, the evaluation results registered in the evaluation input database 126 reflect the average value of each evaluator's evaluation of the person being evaluated. Note that instead of the average value, a weighted average value calculated according to the number of evaluations and a standard deviation value, etc., may be used. Evaluation results by case ID may also be registered in the evaluation input database 126.

[Evaluation Summary Database 127]
9 is a diagram showing an example of the evaluation summary database 127. Information on the evaluation of the appraisee by department is registered in the evaluation summary database 127. The information on the evaluation by organization includes the evaluation target, the member ID of the appraisee, the ID of the company to which the appraisee belongs, the ID of the company to which the evaluator belongs, the department to which the evaluator belongs, and the evaluation summary.

The evaluation summary database 127 includes a recruiter evaluation summary section 127A and an applicant evaluation summary section 127B. In the recruiter evaluation summary section 127A, the evaluation target (evaluated person) corresponds to the recruiter (orderer). In the applicant evaluation summary section 127B, the evaluation target (evaluated person) corresponds to the applicant (contract recipient). In the evaluation summary database 127, evaluation summaries for the evaluation targets are registered by department.

The evaluation summary is calculated based on the results of the evaluation input database 126. The department category includes each department within a company, such as the "Systems Department" and the "Planning Department," as well as "Overall," which refers to the entire company. The evaluation summary is calculated for each of these "departments."

Figure 9 shows an example in which member P1 corresponds to the person being evaluated as the recruiter evaluation summary section 127A. The company ID of the person being evaluated is "00A". Therefore, member P1 belongs to company A. In Figure 9, data group 1271 represents company B's evaluation of member P1 acting as a recruiter, and data group 1272 represents company C's evaluation of member P1 acting as a recruiter.

Referring to data group 1271, it can be seen that the evaluation of company B is classified into an evaluation of the entire company, an evaluation of the systems department within company B, and an evaluation of the planning department within company B. The average evaluation value corresponding to each classified category is registered in the evaluation summary.

For example, the evaluation summary corresponding to company B as a whole is registered with the average evaluation results of the members of company B who evaluated member P1 acting as a recruiter. In FIG. 9, this value is "4.75". The evaluation summary corresponding to the system department is registered with the average evaluation results of the members of company B who are members of the system department and who evaluated member P1 acting as a recruiter. In FIG. 9, this value is "4.0". The evaluation summary corresponding to the planning department is registered with the average evaluation results of the members of company B who are members of the planning department and who evaluated member P1 acting as a recruiter. In FIG. 9, this value is "5.0".

As with data group 1271, the evaluation of company C in data group 1272 is classified into an evaluation of the entire company and an evaluation of each department within company C. Data groups 1271 and 1272 are data that evaluate recruiters. Therefore, the evaluation summaries registered in data groups 1271 and 1272 are recruiter evaluation summaries.

Above, the recruiter evaluation summary section 127A has been explained in detail. Next, the applicant evaluation summary section 127B will be explained. Figure 9 shows an example of the applicant evaluation summary section 127B in which member P7 is the person being evaluated. The company ID of the person being evaluated is "00C". Therefore, member P7 belongs to company C. In the applicant evaluation summary section 127B, evaluations of member P7, who acts as an applicant, are registered by department.

The applicant evaluation summary section 127B has a similar structure to the recruiter evaluation summary section 127A, except that the evaluation target is an "applicant" rather than a "recruiter." Therefore, the explanation of the applicant evaluation summary section 127B will be replaced here with the explanation of the recruiter evaluation summary section 127A already given.

The sharing server 100 uses the evaluation input database 126 to identify the evaluation results of each member, and uses the member database 122 to identify the affiliation of each member. The sharing server 100 updates the data in the evaluation summary database 127 based on these identification results.

Note that while FIG. 9 only shows members P1 and P7 as those being evaluated, other members P2 to P6, member P8, and member P9, etc. are also registered in the evaluation summary database 127 as those being evaluated. The evaluation summary database 127 may also include data in which the same member is the subject of evaluation as both a recruiter and an applicant. For example, in addition to a recruiter evaluation summary for member P1, an applicant evaluation summary for member P1 may also be registered in the evaluation summary database 127 shown in FIG. 9.

[Functions of the Sharing Server, Recruiter Device, and Applicant Device]
10 to 12 are diagrams for explaining the functions of the sharing server, the recruiter device, and the applicant device.

As shown in FIG. 10, the sharing server 100 functionally includes a community registration unit 140, a company registration unit 141, a member registration unit 142, a member search unit 143, and a case registration unit 144. These various functions are realized by a processor 101, a memory 102, a storage 103, and a communication interface 104 provided in the sharing server 100.

The community registration unit 140 has a function of registering a community in the community database 123. A system administrator who manages the matching system 1 inputs information about the community into the sharing server 100 using an operation unit such as a keyboard (not shown).

The information about the community includes the community name and information about the companies that belong to the community. The community registration unit 140 registers the community in the community database 123 according to the input from the system administrator (step S1). The community registration unit 140 further has a function of updating the information about the community registered in the community database 123.

The company registration unit 141 has a function for registering new companies that will join the matching system 1. The system administrator uses an operation unit such as a keyboard to input information about the company into the sharing server 100.

The information about the company includes information such as the company name, address, and maximum hours for side jobs. The company registration unit 141 registers the company in the company database 121 according to the input from the system administrator (step S2). The company registration unit 141 further has a function for updating information about companies that have already been registered.

The member registration unit 142 has a function for registering (signing up) new members who will join the matching system 1. The member registration unit 142 issues a member ID and password in response to a request from an individual belonging to a company that is a member of the matching system 1. An individual who wishes to become a member performs the sign-up process using a personal computer or the like (step S3).

Specifically, a person who wishes to become a member inputs information such as their name, company, and department into a personal computer, etc., and transmits the input information to the sharing server 100. The member registration unit 142 registers the input information in the member database 122. New members can sign in to the sharing server 100 using the personal computer used for member registration. In this case, the personal computer functions as the recruiter device 200 or the applicant device 300.

Two applicant devices 300 are shown in FIG. 10. One is a device that is assumed to be operated by a manager of the applying company. The other is a device that is assumed to be operated by someone in the applying company other than the manager. The manager of the applying company is a managerial employee such as a department head, and corresponds to the superior of the subordinate applicants. In this embodiment, the manager of the applying company plays the role of an approver who approves applications for recruitment jobs by subordinates.

The member search unit 143 has a function of searching for members of the matching system 1. In response to requests from the recruiter device 200 and the applicant device 300, the member search unit 143 provides information on members registered in the member database 122 to the recruiter device 200 and the applicant device 300.

When the recruiter's search operation is received, the recruiter's device 200 executes a member search process (step S4A). This allows the recruiter to view, for example, the applicant's information. The recruiter can select an applicant from among multiple applicants to whom the job will be awarded, taking into consideration the applicant's information. Similarly, when the applicant's device 300 receives a search operation for a manager who is the superior of an applicant, it executes a member search process (step S4A).

Furthermore, when the applicant device 300 receives a search operation from an applicant, it executes a member search process (step S4B). This allows the applicant to view, for example, the information of the recruiter. The applicant can select an order for a job from among multiple recruiting jobs, taking into account the information of the recruiter.

The member search process (step S4A) executed by the recruiter device 200 and the processing of the member search unit 143 will be described in detail later with reference to FIG. 19. The member search process (step S4B) executed by the applicant device 300 and the processing of the member search unit 143 will be described in detail later with reference to FIG. 20.

The case registration unit 144 has a function of registering the recruitment case in the recruitment case database 124. When the recruiter device 200 receives an operation to input a recruitment case, it executes a process to register the recruitment case (step S5). In the process of registering the recruitment case, the recruiter device 200 transmits information about the recruitment case to the sharing server 100. The case registration unit 144 registers the received information about the recruitment case in the recruitment case database 124.

The recruitment request registration process (step S5) executed by the recruiter device 200 and the processing of the request registration unit 144 will be described in detail later with reference to FIG. 14.

As shown in FIG. 11, the sharing server 100 functionally includes a case extraction unit 145, an application unit 146, an approval unit 147, and a notification unit 148. These various functions are realized by the processor 101, memory 102, storage 103, and communication interface 104 provided in the sharing server 100.

The job extraction unit 145 has a function of extracting job postings that can be viewed by applicants. The application unit 146 has a function of submitting an application by an applicant to a manager (the applicant's superior). The approval unit 147 has a function of sending the contents of the application for the job posting to the recruiter on the condition that approval of the application has been received from the manager (approver). The notification unit 148 has a function of receiving the result of whether or not to hire the applicant from the recruiter, and notifying the applicant and the manager of the result.

The application unit 146, approval unit 147, and notification unit 148 use the workflow system to notify the administrator for approval, notify the recruiter of the applicant, and notify the applicant of the application result.

When the applicant device 300 receives an operation from the applicant requesting a search for recruitment cases, the applicant device 300 executes a search process for recruitment cases (step S6). In the search process for recruitment cases, the applicant device 300 transmits a search request to the case extraction unit 145 of the sharing server 100.

When the case extraction unit 145 receives a search request, it extracts cases that the applicant is permitted to view from among the recruitment cases registered in the recruitment case database 124, and transmits the extracted cases to the applicant device 300. The case extraction unit 145 determines whether the applicant is permitted to view the case based on a first criterion and a second criterion. The first criterion is the disclosure range set for the recruitment case. The second criterion is the applicant's spare capacity for a side job. The disclosure range is determined by the disclosure information shown in FIG. 14. The spare capacity for a side job is calculated as the available time for a side job shown in FIG. 15.

The case extraction unit 145 determines cases that satisfy both the first and second criteria as cases that the applicant is permitted to view. Therefore, the case extraction unit 145 extracts cases that are permitted to be disclosed to the applicant who received the search request from among the recruitment cases registered in the recruitment case database 124. Furthermore, the case extraction unit 145 extracts cases that can be handled within the side job hours available to the applicant who received the search request from among the recruitment cases registered in the recruitment case database 124. The case extraction unit 145 transmits the cases that the applicant is permitted to view to the applicant device 300.

The case extraction unit 145 may be configured to accept an operation to set criteria for extracting cases. For example, a function may be added to the sharing server 100 that allows the system administrator to select from a first setting that enables only the first criterion, a second setting that enables only the second criterion, and a third setting that enables both the first and second criteria.

The applicant device 300 receives the recruitment request from the request extraction unit 145. The applicant device 300 displays the received recruitment request on the display 305 (step S7).

The job search process (step S6), the job display process (step S7), and the process of the job extraction unit 145 will be described in detail later with reference to FIG. 15.

The applicant operates the applicant device 300 to select the job to apply for from among the jobs displayed on the display 305. The applicant device 300 executes application processing in response to the applicant's operation (step S8). In the application processing, the applicant device 300 transmits application information indicating the job to be applied for to the application unit 146 of the sharing server 100. As a result, a request to receive the job is transmitted from the applicant device 300 to the application unit 146.

The application unit 146 transmits the application information received from the applicant device 30 to the applicant device 300 of the manager (the applicant's superior). The application unit 146 identifies the member ID of the superior, who is the manager of the applicant, based on the relationship between the applicant's member ID and the superior's member ID registered in the member database 122, for example. The application unit 146 transmits the subordinate's application information to the applicant device 300 corresponding to the identified superior's member ID. The manager checks the job for which the subordinate has applied on his/her own applicant device 300. The manager performs an operation to approve the application on the applicant device 300. The applicant device 300 accepts the approval operation and executes the application approval process (step S9). In the application approval process, the applicant device 300 transmits the approval information to the approval unit 147 of the sharing server 100. As a result, the approval information, which is an example of an approval notice, is transmitted from the applicant device 300 of the manager (approver) to the approval unit 147.

The approval unit 147 accepts the applicant's application on the condition that approval information has been received from the applicant device 300. Thus, in this embodiment, the applicant's application is accepted on the condition that the manager to whom the applicant belongs approves it. Therefore, the manager can check in advance the content of the job for which the subordinate is applying. As a result, it is possible to prevent confidential information from leaking outside the company through the side job activities of employees.

Note that FIG. 11 shows the flow when the administrator approves an application. If an operation to reject the application is accepted in step S9, rejection information is sent from the applicant device 300 of the administrator to the approval unit 147. When rejection information is received, the approval unit 147 may notify the applicant device 300 of the applicant that the application has been rejected.

The approval unit 147, which has accepted the applicant's application, transmits application information to the recruiter device 200. The application information includes information about the applicant and the details of the job for which the applicant is being applied. The recruiter device 200 displays the application details on the display 205 (step S10). The recruiter checks the applicant and the job for which the applicant is being applied based on the display 205, and determines whether or not to hire the applicant.

The recruiter inputs the result of the hiring or rejection decision to the recruiter device 200. The recruiter device 200 accepts the input result (step S11). The recruiter device 200 transmits the accepted hiring or rejection result to the notification unit 148 of the sharing server 100.

When the notification unit 148 receives a result of employment or rejection from the recruiter device 200, it transmits the application result (the result of employment or rejection) to the applicant's applicant device 300 and the manager's applicant device 300.

The applicant's device 300 and the manager's device 300 display the application results on the display 305 (steps S12 and S13). The applicant and manager check the application results by looking at the display 305.

As shown in FIG. 12, the sharing server 100 functionally includes a performance reception unit 149, a performance output unit 150, an evaluation reception unit 151, and an evaluation output unit 152. These various functions are realized by a processor 101, a memory 102, a storage 103, and a communication interface 104 provided in the sharing server 100.

The performance receiving unit 149 has a function of receiving the planned side job hours and actual side job hours input by the applicant on the applicant device 300. The performance output unit 150 has a function of outputting information including the applicant's planned side job hours and actual side job hours to the recruiter device 200 or the manager's applicant device 300.

The evaluation receiving unit 151 has a function of receiving an evaluation of an applicant (contract recipient) that is input by the recruiter on the recruiter device 200. The evaluation output unit 152 has a function of outputting information indicating the evaluation of the applicant to the recruiter device 200.

When an applicant engages in a side job, he/she inputs the planned side job hours and the actual side job hours into the applicant device 300. An applicant typically inputs the planned side job hours into the applicant device 300 when he/she receives an order for a new side job, and inputs the actual side job hours into the applicant device 300 at any time while he/she is engaged in the side job. For example, if an applicant receives an order for a side job that has an expected period spanning multiple months, the applicant inputs the actual side job hours into the applicant device 300 for each month.

The applicant device 300 accepts the input of the planned side job time and the actual side job time (step S14). The applicant device 300 transmits the accepted planned side job time and actual side job time to the performance acceptance unit 149 of the sharing server 100.

The achievement receiving unit 149 registers the received planned side job time and actual side job time in the side job database 125. The processing of step S14 executed by the applicant device 300 and the processing of the achievement receiving unit 149 will be described in detail later with reference to FIG. 16.

The performance output unit 150 transmits the planned side job time and actual side job time registered in the side job database 125 to the recruiter device 200 and the manager's applicant device 300. The recruiter device 200 displays the received information including the planned side job time and actual side job time on the display 205, and the manager's applicant device 300 displays the received information including the planned side job time and actual side job time on the display 305 (step S15). However, when comparing the information transmitted to the recruiter device 200 and the information transmitted to the manager's applicant device 300, the cases to be transmitted are different.

Data corresponding to cases that the subordinate is in charge of, among the many cases registered in the side job database 125, is sent from the achievement reception unit 149 to the manager's applicant device 300. The manager can check the side job status of the subordinate by looking at the display 305. The screen displayed on the manager's applicant device 300 when the manager checks the side job status of the subordinate will be explained later using Figure 23.

From the achievement reception unit 149 to the recruiter device 200, data corresponding to cases recruited by the recruiters among the many cases registered in the side job database 125 is transmitted. For example, in the side job database 125 shown in FIG. 7, consider a case in which, among multiple recruiters, a first recruiter is recruiting for case 001 and a second recruiter is recruiting for case 002.

In this case, various data corresponding to case 001 from the side job database 125 is transmitted from the achievement receiving unit 149 to the recruiter device 200 operated by the first recruiter. Various data corresponding to case 002 from the side job database 125 is transmitted from the achievement receiving unit 149 to the recruiter device 200 operated by the second recruiter.

The first and second recruiters can check the progress of their own projects by viewing the planned side job hours and actual side job hours, etc., displayed on the display 305 of the recruiter device 200.

When the recruiter completes the side job, the recruiter inputs an evaluation of the applicant into the recruiter device 200. The recruiter device 200 accepts the input of the evaluation of the applicant (step S16A). Therefore, when accepting the input evaluation, the recruiter device 200 functions as an evaluator device operated by the evaluator (recruiter).

The recruiter device 200 transmits the received evaluation to the evaluation receiving unit 151 of the sharing server 100. The evaluation receiving unit 151 updates the evaluation input database 126 and the evaluation summary database 127 based on the received evaluation. As a result, the information in the applicant evaluation unit 126B is updated in the evaluation input database 126, and the information in the applicant evaluation summary unit 127B is updated in the evaluation summary database 127.

The processing of step S16A executed by the recruiter device 200 and the processing of the evaluation receiving unit 151 will be described in detail later with reference to FIG. 17.

When the recruiter accepts an operation to view the applicant's evaluation, the recruiter device 200 executes a viewing request process (step S17A). In the viewing request process, the recruiter device 200 transmits a viewing request to the evaluation output unit 152 of the sharing server 100. In response to the viewing request, the evaluation output unit 152 transmits the applicant's evaluation (applicant evaluation summary) registered in the evaluation summary database 127 to the recruiter device 200. The recruiter device 200 displays the received applicant evaluation on the display 205 (step S18A).

The processing of steps S17A and S18A executed by the recruiter device 200 and the processing of the evaluation output unit 152 will be described in detail later with reference to FIG. 19.

Figure 13 is a diagram for further explaining the functions of the applicant device 300. Here, the input and output of evaluations of the recruiter will be explained using Figure 13. The evaluation receiving unit 151 further has a function of receiving an evaluation of the recruiter input by the applicant on the applicant device 300. The evaluation output unit 152 further has a function of outputting information indicating the evaluation of the recruiter to the applicant device 300. When the applicant completes the ordered work, he or she inputs an evaluation of the recruiter to the applicant device 300. There are various points on which the applicant evaluates the recruiter.

For example, applicants are likely to rate a recruiter highly if they can communicate smoothly with the recruiter and complete the work within an appropriate time frame. Conversely, applicants are likely to rate a recruiter low if there are many requests to add, change, or modify the work content, if too much time is spent outside the scope of the work, if instructions are communicated too late, or if instructions are given unilaterally without consulting the applicant beforehand regarding modifications to the work content.

The applicant device 300 accepts the input of an evaluation of the applicant (step S16B). Therefore, when accepting the input evaluation, the applicant device 300 functions as an evaluator device operated by the evaluator (applicant).

The applicant device 300 transmits the received evaluation to the evaluation receiving unit 151 of the sharing server 100. The evaluation receiving unit 151 updates the evaluation input database 126 and the evaluation summary database 127 based on the received evaluation. As a result, the information in the recruiter evaluation unit 126A is updated in the evaluation input database 126, and the information in the recruiter evaluation summary unit 127A is updated in the evaluation summary database 127.

The processing of step S16B executed by the applicant device 300 and the processing of the evaluation receiving unit 151 will be described in detail later with reference to FIG. 18.

When the applicant device 300 receives an operation to view the applicant's evaluation of the recruiter, it executes a viewing request process (step S17B). In the viewing request process, the recruiter device 200 transmits a viewing request to the evaluation output unit 152 of the sharing server 100. In response to the viewing request, the evaluation output unit 152 transmits the evaluation of the recruiter (recruiter evaluation summary) registered in the evaluation summary database 127 to the applicant device 300. The applicant device 300 displays the received evaluation of the recruiter on the display 305 (step S18B).

The processing of steps S17B and S18B executed by the applicant device 300 and the processing of the evaluation output unit 152 will be described in detail later with reference to FIG. 20.

[Details of the processing by the case registration unit 144 and the recruiter device 200]
Fig. 14 is a diagram for explaining the procedure for registering a recruitment request in the recruitment request database 124. Step S5 in Fig. 10 and the function of the request registration unit 144 will be described in more detail with reference to Fig. 14.

A recruiter who registers a recruitment request first signs in to the sharing server 100 using the recruiter device 200. This establishes a logical communication path identified by the recruiter's member ID between the recruiter device 200 and the sharing server 100. Next, the recruiter uses the operation unit 206, such as a mouse and keyboard, to input business information and disclosure information for the recruitment request into the recruiter device 200.

The information inputted by the operation unit 206 is notified to the processor 201 via the input/output interface 204 of the recruiter device 200. The operation unit 206 and the input/output interface 204 constitute an interface that accepts operations for inputting the contents of the business and for inputting disclosure information that specifies the target to which the business is to be disclosed.

The business information for the job posting includes the job title, job content, estimated man-hours (person-months), and estimated period. The disclosed information includes the disclosure level. The disclosed information may include the IDs of companies that are not subject to disclosure, depending on the employer's choice.

The recruiter device 200 accepts input of the business information and disclosure information of the recruitment request, and executes a process to register the recruitment request (step S5). In the process of registering the recruitment request, the recruiter device 200 transmits the business information and disclosure information of the recruitment request to the sharing server 100.

The case registration unit 144 of the sharing server 100 acquires information about the recruiter (step S1441). Specifically, the case registration unit 144 identifies the company to which the recruiter belongs.

The sharing server 100 stores the member ID used when a member signs in to the sharing server 100 using the recruiter device 200 or the applicant device 300. When the sharing server 100 receives any information from the recruiter device 200 or the applicant device 300 in communication established by this member ID, it identifies the member who sent the information by the member ID used to sign in.

Therefore, when business information and disclosure information of a recruitment business are received from the recruiter device 200, the case registration unit 144 uses the member ID used to sign in to identify the recruiter operating the recruiter device 200. The case registration unit 144 uses the identified member ID, the member database 122, and the company database 121 to identify the member who is the recruiter and the company to which the recruiter belongs.

Next, the case registration unit 144 executes a process of registering the solicited case in the solicited case database 124 (step S1442). Specifically, after generating a case ID, the case registration unit 144 registers the company information (company ID), the ID of the company to be withheld, the disclosure level, the case title, the estimated man-hours, the estimated period, and the case content, etc., in the solicited case database 124 in association with the generated case ID.

According to this embodiment, the recruiter can freely control the disclosure scope of the recruitment request at the level of "within the company," "within the community," or "unrestricted." As a result, it is possible to prevent the recruitment request from being disclosed to a specific company without the recruiter's intention.

According to this embodiment, it is possible to set companies that are not to be disclosed separately from the disclosure level. Therefore, the recruiter can set the disclosure range by excluding some of the multiple companies that have a community relationship with the recruiter's company. As a result, it is possible to prevent business related to a specific company in the community from being disclosed to that specific company.

Instead of or in addition to the non-disclosure company ID list, a non-disclosure member ID list for registering member IDs for which disclosure of recruitment requests is prohibited may be provided in the recruitment request database 124. The recruiter device 200 may accept an operation to designate a member for whom disclosure of recruitment requests is prohibited, and transmit the member ID to the sharing server 100. The sharing server 100 may not provide recruitment requests corresponding to a member ID listed in the non-disclosure member ID list to the member. In this way, the recruiter device 200 may accept either companies or members as persons for whom disclosure of business is prohibited.

Figure 15 is a diagram for explaining the procedure for searching for recruitment cases from within the database 120. Using Figure 15, the processing of steps S6 and S7 in Figure 11 and the function of the case extraction unit 145 will be explained in more detail.

When the applicant device 300 receives an operation from the applicant requesting a search for recruitment cases, the applicant device 300 executes a search process for recruitment cases (step S6). In the search process for recruitment cases, the applicant device 300 transmits a search request to the case extraction unit 145 of the sharing server 100.

When the case extraction unit 145 receives a search request, it extracts cases that the applicant is permitted to view from among the recruitment cases registered in the recruitment case database 124. To this end, the case extraction unit 145 executes the processes of steps S1451 to S1454.

Steps S1451 and S1452 are processes for extracting cases that the applicant is permitted to view based on the disclosure scope set for the recruitment case. In step S1451, the applicant's company and the company's community are determined. In step S1452, cases that can be disclosed are extracted.

Step S1453 is a process for extracting jobs that the applicant is allowed to view based on the applicant's spare time for a side job. Step S1454 is a process for finally extracting jobs that match the applicant.

[Process to extract cases based on disclosure scope]
Step S1451 includes step S1451A and step S1451B.

In step S1451A, the applicant's company is identified based on the member ID, company database 121, and member database 122 used when signing in.

In step S1451B, the community of the applicant's company is identified based on the ID of the applicant's company and the community database 123.

Step S1452 includes step S1452A and step S1452B.

In step S1452A, discloseable job openings are extracted from the job opening database 124 based on the community to which the applicant's company belongs and the disclosure level.

In step S1452B, from among the recruitment jobs extracted in step S1452A, those for which the applicant's company is included in the non-disclosure company list are excluded. Here, the job extracted by the processing of step S1452B is referred to as job X.

[Process to extract cases based on spare capacity for side jobs]
Step S1453 includes step S1453A, step S1453B, and step S1453C.

In step S1453A, the applicant's possible side job time T1 is calculated. The possible side job time is derived by calculating "maximum side job time - total side job time". The maximum side job time is a time set by the company to which the applicant belongs, and is registered in the company database 121. The calculated possible side job time is registered in the member database 122. The case extraction unit 145 may calculate the possible side job time of all members at regular intervals, and register the calculated possible side job time in the member database 122.

The total side job time is calculated based on the expected side job time and actual side job time registered in the side job database 125, using the formula "total expected side job time + total actual side job time." In other words, the total side job time includes the time already spent on the side job, as well as the expected time not yet spent on the side job.

In step S1453B, the time T2 required to complete the work is calculated for each job posting. Time T2 is calculated based on the estimated man-hours (man-months) and estimated period registered in the job posting database 124. For example, the estimated man-hours (months) may be used as time T2. For example, 5 hours per month may be set as time T2 for the job posting corresponding to job ID 001.

In step S1453C, jobs that meet the condition "time T2≦time available for side job T1" are extracted from the job database 124. Here, the job extracted by the processing of step S1453C is referred to as job Y.

[Process for extracting cases based on disclosure scope and side job capacity]
The case extraction unit 145 extracts case X based on the disclosure scope, extracts case Y based on the side job capacity, and then extracts cases that overlap between case X and case Y as matching cases for the applicant (step S1454).

[Process to provide extracted cases]
Next, the case extraction unit 145 transmits information about the matching cases to the applicant device 300 (step S1455). The applicant device 300 receives the matching cases. The applicant device 300 displays a list of the received matching cases as recruiting cases on the display 305 (step S7).

This provides applicants with job postings that are appropriate from two perspectives. First, applicants are provided with job postings that they can handle without exceeding the applicant's side job limit. This prevents applicants from becoming overworked. Second, a recruiter's job postings are provided only to applicants who fall within the scope of disclosure intended by the recruiter. This prevents confidential information about the recruiter's company from being leaked to competitors.

[Process for registering planned side job hours and actual side job hours]
Fig. 16 is a diagram for explaining the procedure for registering plans and results of a side job in the database 120. Step S14 in Fig. 12 and the function of the result receiving unit 149 will be described in more detail with reference to Fig. 16.

For example, when an applicant receives an order for a new side job, the applicant inputs the planned side job time into the applicant device 300, and inputs the actual side job time into the applicant device 300 at any time while the applicant is engaged in the side job. The applicant device 300 accepts the input of the planned side job time (step S14). The applicant device 300 transmits the accepted planned side job time and actual side job time to the performance acceptance unit 149 of the sharing server 100.

The results receiving unit 149 receives the applicant's planned side job hours and actual side job hours, and registers the accepted applicant's planned side job hours and actual side job hours in the side job database 125 (step S1511). As a result, the applicant's planned side job hours and actual side job hours for each month are registered in the side job database 125 by case ID.

Usually, after an applicant inputs the planned side job hours, the applicant also inputs the actual side job hours at the end of the month. For this reason, the side job database 125 may contain cases where the planned side job hours are registered but the actual side job hours are not registered. For example, when an applicant who has been accepted for a side job inputs the planned side job hours, the planned side job hours are registered as data corresponding to that side job, but the actual side job hours are not registered.

Next, the result receiving unit 149 automatically calculates the side job expected time for the current month (step S1512). The result receiving unit 149 calculates the side job expected time based on the planned side job time and the actual side job time. Specifically, as already explained, the "side job expected time" is calculated based on the calculation formula "(man-hour progress rate/progress rate) x planned side job time - actual side job time". Note that the result receiving unit 149 may also calculate the "side job expected time" using the calculation formula "planned side job time - actual side job time". The result receiving unit 149 registers the calculated side job expected time in the side job database 125. As shown in the side job database 125 in FIG. 7, the side job expected time is registered for each case ID.

[Process to register evaluation results (evaluation of applicants)]
Fig. 17 is a diagram for explaining the procedure for registering evaluations of an applicant in database 120. Step S16A in Fig. 12 and the function of evaluation receiving unit 151 will be described in more detail with reference to Fig. 17.

When the applicant completes the side job, he/she reports the delivery and completion to the recruiter and has the recruiter inspect the job. The recruiter then operates the recruiter device 200 to input an evaluation of the applicant to the recruiter device 200. The recruiter device 200 accepts the input evaluation (step S16A). The recruiter device 200 transmits the accepted evaluation to the evaluation receiving unit 151 of the sharing server 100. The information transmitted from the recruiter device 200 to the sharing server 100 includes the member ID of the applicant who is to be evaluated and the evaluation value (0 to 10).

When the evaluation receiving unit 151 receives information on the evaluation of the person being evaluated (applicant) from the recruiter device 200, it reflects the evaluation of the person being evaluated in the evaluation input database 126 (step S1513A).

If evaluation results for the person being evaluated (applicant) have already been registered in the evaluation input database 126, the evaluation receiving unit 151 calculates the average value of the evaluation results for the person being evaluated, including the currently received evaluation value. The evaluation receiving unit 151 updates the evaluation results registered in the evaluation input database 126 with the calculated average value. As a result, the average evaluation values (evaluation results) for the person being evaluated (applicant) are registered for each evaluator (recruiter) in the evaluation input database 126. This updates the information in the applicant evaluation unit 126B in the evaluation input database 126.

Next, the evaluation receiving unit 151 executes evaluation summary processing (step S1514A). In the evaluation summary processing, the evaluation receiving unit 151 calculates the average evaluation results for the evaluatees (applicants) by company and department, and registers the calculation results in the evaluation summary database 127. This updates the information in the applicant evaluation summary section 127B in the evaluation summary database 127.

For example, the evaluation receiving unit 151 identifies the evaluator (recruiter) using the member ID used by the recruiter device 200 to sign in to execute step S16A. Based on the evaluation information received in step S1513A, the company database 121, and the member database 122, the evaluation receiving unit 151 identifies the ID of the company to which the evaluator belongs, the department to which the evaluator belongs, the member ID of the person being evaluated, and the ID of the company to which the person being evaluated belongs. The "member ID" is an example of "identification information that enables the sharing server 100 including the evaluation receiving unit 151 to identify the affiliation (company and department) of a person accessing the sharing server 100."

The evaluation receiving unit 151 accesses the evaluation summary database 127 and detects a data row containing the identified IDs (the member ID of the person being evaluated, the ID of the company to which the person being evaluated belongs, and the ID of the company to which the evaluator belongs). The evaluation receiving unit 151 updates the value of the applicant evaluation summary that corresponds to the detected data row.

[Process to register evaluation results (evaluation of recruiters)]
18 is a diagram for explaining the procedure for registering an evaluation of a recruiter in a database. Step S16B in FIG. 13 and the function of the evaluation receiving unit 151 will be described in more detail with reference to FIG.

As described above, when the applicant completes the side job, he/she delivers and reports completion to the recruiter and has the recruiter inspect the job. The applicant then operates the applicant device 300 to input an evaluation of the recruiter into the applicant device 300. The applicant device 300 accepts the input evaluation (step S16B). The applicant device 300 transmits the accepted evaluation to the evaluation receiving unit 151 of the sharing server 100. The information transmitted from the applicant device 300 to the sharing server 100 includes the member ID of the recruiter who is being evaluated and the evaluation value (0 to 10).

When the evaluation receiving unit 151 receives evaluation information for the person being evaluated (recruiter) from the applicant device 300, it reflects the evaluation of the person being evaluated in the evaluation input database 126 (step S1513B).

If evaluation results for the person being evaluated (recruiter) have already been registered in the evaluation input database 126, the evaluation receiving unit 151 calculates the average value of the evaluation results for the person being evaluated, including the currently received evaluation value. The evaluation receiving unit 151 updates the evaluation results registered in the evaluation input database 126 with the calculated average value. As a result, the average evaluation values (evaluation results) for the person being evaluated (recruiter) are registered for each evaluator (applicant) in the evaluation input database 126. This updates the information in the recruiter evaluation unit 126A in the evaluation input database 126.

Next, the evaluation receiving unit 151 executes evaluation summary processing (step S1514B). In the evaluation summary processing, the evaluation receiving unit 151 calculates the average value of the evaluation results for the evaluatees (recruiters) by company and department, and registers the calculation results in the evaluation summary database 127. This updates the information in the recruiter evaluation summary unit 127A in the evaluation summary database 127.

For example, the evaluation receiving unit 151 identifies the evaluator (applicant) using the member ID used by the applicant device 300 to sign in to execute step S16B. Based on the evaluation information received in step S1513B, the company database 121, and the member database 122, the evaluation receiving unit 151 identifies the ID of the company to which the evaluator belongs, the department to which the evaluator belongs, the member ID of the person being evaluated, and the ID of the company to which the person being evaluated belongs. The "member ID" is an example of "identification information that enables the sharing server 100 including the evaluation receiving unit 151 to identify the affiliation (company and department) of a person accessing the sharing server 100."

The evaluation receiving unit 151 accesses the evaluation summary database 127 and detects a data row containing the identified IDs (the member ID of the person being evaluated, the ID of the company to which the person being evaluated belongs, and the ID of the company to which the evaluator belongs). The evaluation receiving unit 151 updates the value of the recruiter evaluation summary that corresponds to the detected data row.

For example, data group 1271 in FIG. 9 lists the member ID of the person being evaluated (P1), the ID of the company to which the person being evaluated belongs (00A), and the ID of the company to which the evaluator belongs (00B). When a member belonging to the systems department of company B evaluates member P1, the evaluation is accepted in step S1513B.

In this case, in step S1514B, the evaluation received in step S1513B is reflected in the recruiter evaluation summary corresponding to the "Overall" and the recruiter evaluation summary corresponding to the "System Section" of data group 1271.

More specifically, the evaluation receiving unit 151 sets the average value of the evaluations of the entire company B, including the evaluations received in step S1513B, as the recruiter evaluation summary corresponding to "Overall" in the data group 1271. Similarly, the evaluation receiving unit 151 sets the average value of the evaluations of the system part, including the evaluations received in step S1513B, as the recruiter evaluation summary corresponding to "System part" in the data group 1271.

Figure 19 is a diagram for explaining the procedure for displaying the evaluation of the applicant and the search results of the members on the display 205. Using Figure 19, step S4A (processing of the recruiter device 200) and the function of the member search unit 143 in Figure 10, as well as steps S17A and S18A in Figure 12, and the function of the evaluation output unit 152 will be explained in more detail.

[Process to output applicant evaluation summary]
First, the processes of steps S17A, S18A, S1521A, and S1522A shown in FIG. 19 will be described.

When the recruiter accepts an operation to view the evaluation of the applicant, the recruiter device 200 executes a viewing request process (step S17A). In the viewing request process, the recruiter device 200 transmits a viewing request to the evaluation output unit 152 of the sharing server 100. In response to the viewing request, the evaluation output unit 152 selects from the evaluation summary database 127 an applicant evaluation summary that the recruiter (view requester) has permission to view (step S1521A).

The recruiter who made the viewing request is authorized to view the applicant evaluation summary for the entire company to which the recruiter belongs and the applicant evaluation summary for the department to which the recruiter belongs. The recruiter who made the viewing request is not authorized to view any evaluation summaries other than these. The evaluation output unit 152 determines the viewing authority based on the member ID of the recruiter who sent the viewing request, the company database 121, and the member database 122. The "member ID" is an example of "identification information that enables the sharing server 100 including the evaluation receiving unit 151 to identify the affiliation (company and department) and viewing authority of a person who has accessed the sharing server 100."

The evaluation output unit 152 selects an applicant evaluation summary corresponding to the viewing authority from the evaluation summary database 127. The evaluation output unit 152 transmits data including the selected applicant evaluation summary to the recruiter device 200 (step S1522A). In addition to the applicant evaluation summary, the transmitted data includes the applicant's (evaluated) membership ID, information about the company to which the applicant belongs, information about the department to which the applicant belongs, etc. The transmitted data may include applicant evaluation summaries corresponding to each of multiple applicants (evaluated) depending on the viewing request.

The recruiter device 200, which has received the applicant evaluation summary, displays the applicant evaluation summary on the display 205 together with information about the company to which the applicant belongs and information about the department to which the applicant belongs (step S18A). When applicant evaluation summaries corresponding to multiple applicants (evaluated persons) are received, the recruiter device 200 displays the applicant evaluation summaries in a list of multiple applicants (evaluated persons).

In this way, when the sharing server 100 receives a viewing request in communication established by a member ID that can identify the company and department to which the recruiter belongs, it transmits an applicant evaluation summary, which is an example of evaluation information, to the recruiter device 200 of the recruiter that sent the viewing request.

[Process to search for members (applicants)]
Next, the processes in steps S4A, S19A, and S1431A to S1433A will be described with reference to FIG.

When the recruiter device 200 receives a search operation from the recruiter, it executes a member search process to search for information about the applicant (step S4A). In the member search process, the recruiter device 200 transmits a search request to the member search unit 143 of the sharing server 100. The search request includes a reference value for performing a search while excluding members who have a low evaluation as an applicant. This reference value is determined, for example, based on the value of the applicant evaluation summary.

The member search unit 143, which receives the search request, identifies the company to which the recruiter who sent the search request belongs (step S1431A). Here, the company identified by step S1431A is referred to as "company Xa."

The member search unit 143 identifies the recruiter operating the recruiter device 200 by using the member ID used by the recruiter device 200 when signing in to the sharing server 100. The member search unit 143 identifies the company Xa to which the recruiter belongs by using the company database 121 and the member database 122.

Next, the member search unit 143 extracts from the evaluation summary database 127 members whose applicant evaluation summary values for the identified company Xa as a whole exceed a reference value (step S1432A). In other words, the member search unit 143 extracts search results by excluding members who have a low evaluation for company Xa as a whole.

It should be noted here that the member search unit 143 determines whether or not the evaluation is low based on the applicant evaluation summary. That is, member α, who has the authority of both an applicant and a recruiter, may behave as an applicant or as a recruiter. Therefore, as evaluation summaries for such member α, an applicant evaluation summary and a recruiter evaluation summary are registered in the evaluation summary database 127. Member α may have a high evaluation as a recruiter, but a low evaluation as an applicant. In this case, member α may be excluded from the extraction targets in step S1432A.

The sharing server 100 may be provided with a function for accepting setting information for the standard value from each company's recruiter device 200. This allows each company to exclude members with low evaluations based on their own standard value from the search results.

Next, the member search unit 143 outputs the extracted member information as a search result to the recruiter device 200 that made the search request (step S1433A). The recruiter device 200 displays the received search results in a list on the display 205 (step S19A).

As a result, the recruiter can view the search results on the display 205, from which members whose companies the recruiter belongs to have a low overall rating have been excluded. Therefore, when selecting contractors from among applicants, the recruiter can save the trouble of visually excluding members whose companies have a low overall rating.

In this embodiment, even if a member has a low evaluation in a department of the company to which the recruiter belongs, the member will not be excluded from the search results if the evaluation of the company as a whole is not low. However, the member search unit 143 may further exclude such members from the search results.

Figure 20 is a diagram for explaining the procedure for displaying the evaluation of the recruiter and the search results of the members on the display 305. Using Figure 20, step S4B (processing of the applicant device 300) and the function of the member search unit 143 in Figure 10, as well as step S17B, step S18B and the function of the evaluation output unit 152 in Figure 13 will be explained in more detail.

[Process for outputting a summary of the recruiter's evaluation]
First, the processes of steps S17B, S18B, S1521B, and S1522B shown in FIG. 20 will be described.

When the applicant device 300 receives an operation to view the applicant's evaluation of the recruiter, it executes a viewing request process (step S17B). In the viewing request process, the applicant device 300 transmits a viewing request to the evaluation output unit 152 of the sharing server 100. In response to the viewing request, the evaluation output unit 152 selects from the evaluation summary database 127 a recruiter evaluation summary for which the applicant (view requester) has been granted viewing rights (step S1521B).

The applicant who made the viewing request is authorized to view the recruiter evaluation summary for the entire company to which the applicant belongs and the recruiter evaluation summary for the department to which the applicant belongs. The applicant who made the viewing request is not authorized to view any evaluation summaries other than these. The evaluation output unit 152 determines the viewing authority based on the member ID of the applicant who sent the viewing request, the company database 121, and the member database 122. The "member ID" is an example of "identification information that enables the sharing server 100 including the evaluation receiving unit 151 to identify the affiliation (company and department) and viewing authority of a person who has accessed the sharing server 100."

The evaluation output unit 152 selects a recruiter evaluation summary corresponding to the viewing authority from the evaluation summary database 127. The evaluation output unit 152 transmits data including the selected recruiter evaluation summary to the applicant device 300 (step S1522B). In addition to the recruiter evaluation summary, the transmitted data includes the member ID of the recruiter (evaluated person), information about the company to which the recruiter belongs, information about the department to which the recruiter belongs, etc. The transmitted data may include recruiter evaluation summaries corresponding to each of multiple recruiters (evaluated people) depending on the viewing request.

The applicant device 300, which has received the recruiter evaluation summary, displays the recruiter evaluation summary on the display 305 together with information about the company to which the recruiter belongs and information about the department to which the recruiter belongs (step S18B). When receiving recruiter evaluation summaries corresponding to multiple recruiters (evaluated persons), the applicant device 300 displays the recruiter evaluation summaries in a list of the multiple recruiters (evaluated persons).

In this way, when the sharing server 100 receives a viewing request in communication established by a member ID that can identify the company and department to which the applicant belongs, it transmits an applicant evaluation summary, which is an example of evaluation information, to the applicant device 300 of the applicant who sent the viewing request.

[Process to search for members (recruiters)]
Next, the processes in steps S4B, S19B, and S1431B to S1433B will be described with reference to FIG.

When the applicant device 300 receives a search operation from the applicant, it executes a member search process to search for information about the recruiter (step S4B). In the member search process, the applicant device 300 transmits a search request to the member search unit 143 of the sharing server 100. The search request includes a reference value for excluding members with low evaluations as recruiters. This reference value is determined, for example, based on the value of the recruiter evaluation summary.

The member search unit 143, which has received the search request, identifies the company to which the applicant who sent the search request belongs (step S1431B). Here, the company identified by step S1431B is referred to as "company Xb."

The member search unit 143 identifies the applicant who is operating the applicant device 300 by using the member ID used when the applicant device 300 signed in to the sharing server 100. The member search unit 143 identifies the company Xb to which the applicant belongs by using the company database 121 and the member database 122.

Next, the member search unit 143 extracts from the evaluation summary database 127 members whose recruiter evaluation summary values for the entire identified company Xb exceed a reference value (step S1432B). In other words, the member search unit 143 extracts search results by excluding members whose evaluations of the entire company Xb are low.

The sharing server 100 may be provided with a function for accepting setting information for the standard value from each company's recruiter device 200. This allows each company to exclude members with low evaluations based on their own standard value from the search results.

Next, the member search unit 143 outputs the extracted member information as a search result to the applicant device 300 that made the search request (step S1433B). The applicant device 300 displays the received search results in a list on the display 305 (step S19B).

As a result, the applicant can view the search results on the display 305, which exclude members whose companies have low overall ratings. Therefore, when selecting contractors from among the recruiters, the applicant can save the trouble of visually excluding members whose companies have low overall ratings.

In this embodiment, even if a member has a low evaluation for a department of the company to which the applicant belongs, the member will not be excluded from the search results if the evaluation for the entire company is not low. However, the member search unit 143 may further exclude such members from the search results.

[Viewable range of evaluation summary database 127]
Fig. 21 is a diagram for explaining the viewable range of the evaluation summary database 127. Here, the viewable range will be explained by taking as an example the recruiter evaluation summary section 127A, which is also shown in Fig. 9, of the evaluation summary database 127.

The recruiter evaluation summary section 127A shown in FIG. 21 includes evaluation summaries from companies B and C for member P1, who acts as a "recruiter." Member P1 belongs to company A. The evaluation summary for company B is categorized into "overall," "system department," and "planning department." The evaluation summary for company C is categorized into "overall," "planning department," etc. Members belonging to companies B and C view the evaluation summaries for member P1 as "applicants."

The right to view the evaluation summary calculated from the overall evaluation of Company B is granted to all members belonging to Company B, as shown in the "Viewable range" column in Figure 21.

The right to view the evaluation summary calculated from the evaluation of Company B's Systems Department is granted to members of Company B's Systems Department, but not to members other than Company B's Systems Department. The right to view the evaluation summary calculated from the evaluation of Company B's Planning Department is granted to members of Company B's Planning Department, but not to members other than Company B's Planning Department.

All members belonging to Company C are granted permission to view the evaluation summary calculated from the overall evaluation of Company C. Members of Company C's Planning Department are granted permission to view the evaluation summary calculated from the evaluation of Company C's Planning Department, but not members outside of Company C's Planning Department.

The above describes the viewable range using the recruiter evaluation summary section 127A as an example. In the matching system 1, the viewable range of the applicant evaluation summary section 127B (see FIG. 9) is also determined based on the same design concept as the recruiter evaluation summary section 127A.

If the viewers are members of Company X's first division and Company X's second division, the viewers' authority to view the evaluation summary for the entire Company X, the evaluation summary for Company X's first division, and the evaluation summary for Company X's second division will be as shown in table 401 in FIG. 21. Here, when the applicant corresponds to a "viewer," the evaluation summary that is viewed is the evaluation summary for the "recruiter." Conversely, when the recruiter corresponds to a "viewer," the evaluation summary that is viewed is the evaluation summary for the "applicant."

Members belonging to the first division of company X can view the evaluation summary for company X as a whole and for company X's first division, but cannot view the evaluation summary for company X's second division. Members belonging to the second division of company X can view the evaluation summary for company X as a whole and for company X's second division, but cannot view the evaluation summary for company X's second division. Members belonging to company Y other than company X cannot view the evaluation summary for company X as a whole, for company X's first division, or for company X's second division.

The evaluation summary of company X as a whole, the evaluation summary of company X's first division, and the evaluation summary of company X's second division will not be disclosed to members of companies other than company X. Therefore, when evaluating recruits belonging to company X, a member belonging to company Y and acting as an applicant can objectively evaluate recruits belonging to company X without considering the relationship between the companies, etc. Similarly, when evaluating applicants belonging to company X, a member belonging to company Y and acting as a recruiter can objectively evaluate applicants belonging to company X without considering the relationship between the companies, etc.

In addition, the evaluations made by members of Company X (evaluations of recruiters and applicants) are shared within Company X as recruiter evaluation summaries and applicant evaluation summaries. This makes it possible for evaluators to be aware that the accumulation of each individual evaluation produces useful information. This motivates evaluators to make accurate evaluations.

As a result, the accuracy of the recruiter evaluation summary and the applicant evaluation summary is improved. This allows the recruiter evaluation summary to be usefully used as reference data when selecting a job for which recruitment is required. Similarly, the applicant evaluation summary can be usefully used as reference data when selecting a contractor.

Furthermore, according to this embodiment, when the member search process (step S4A) is executed on the recruiter device 200, search results excluding low-rated members are provided to the recruiter (step S1432A). Similarly, when the member search process (step S4B) is executed on the applicant device 300, search results excluding low-rated members are provided to the recruiter (step S1432B). In other words, the matching system 1 has a filtering function that provides search results excluding low-rated members.

Therefore, when deciding on a contractor for a job, the recruiter can prevent, on a company-by-company basis, mistakenly hiring a member with a low evaluation. Similarly, when deciding on a job to apply for from among many jobs available, the applicant can prevent, on a company-by-company basis, mistakenly selecting a job that is being recruited by a member with a low evaluation. The sharing server 100 may also perform filtering using the evaluation summary on a department-by-department basis.

A command signal may be sent from the recruiter device 200 to the sharing server 100 to instruct whether filtering using an evaluation summary for the entire company or filtering using an evaluation summary for each department should be used. In this case, the sharing server 100 is provided with a function for changing the evaluation summary used for filtering in response to the command signal.

[Example of setting the scope of disclosure according to the disclosure level]
Fig. 22 is a diagram showing an example in which the disclosure range is set according to the disclosure level. Here, as shown in Fig. 22, consider a case in which companies A to E form a community relationship, and company F does not form a community relationship with any company. In this case, the disclosure range of the recruitment item will be as shown in table 402, depending on the company to which the recruiter belongs and the disclosure level set by the recruiter.

The disclosure levels "Level 1" to "Level 3" shown in FIG. 22 correspond to the three levels of "Company", "Within the Community", and "All" already explained. Thus, at level 1, the recruiter's recruitment request is disclosed only to applicants who belong to the same company as the recruiter's company. At level 2, in addition to the level 1 scope, the recruiter's recruitment request is disclosed to applicants who belong to companies that have a community relationship with the recruiter's company. At level 3, the recruiter's recruitment request is disclosed to applicants who belong to all companies, including the recruiter's company. However, if the recruiter specifies a company ID that is not to be disclosed, the company corresponding to that company ID is excluded from the companies to be disclosed, regardless of the disclosure level set. Among the disclosure levels in this embodiment, "Level 1" corresponds to "permitting disclosure of business information to the first applicant and prohibiting disclosure of business information to applicants who do not belong to the first group". "Level 2" corresponds to "allowing the disclosure of business information to applicants who belong to either the first group or a community group that has formed a community relationship with the first group, and prohibiting the disclosure of business information to applicants who do not belong to either the first group or a community group." "Level 3" corresponds to "allowing the disclosure of business information to applicants regardless of the group to which the applicant belongs."

Here, levels 1 to 3 as described above have been described as an example of multiple disclosure levels. However, the multiple disclosure levels are not limited to these. For example, a community may be divided into multiple small communities, and whether or not to disclose recruiting activities may be set for each small community. More specifically, community 02 shown in FIG. 5 is divided into a first small community and a second small community. Company C belongs to the first small community, and companies D and E belong to the second small community. In this case, a recruiter from company D may be able to choose whether to disclose the scope of his or her recruiting activities within the scope of the first small community or the scope of the second small community.

The sharing server 100 may accept an operation to set the disclosure range differently for each recruitment case. For example, out of the many recruitment cases, case 001 to case 003 are given as examples to explain a specific example of setting the disclosure range differently for each recruitment case.

For example, the disclosure scope of recruitment case 001 may be limited to only companies A and C that belong to the community identified by community ID=03. Or, the disclosure scope of recruitment case 002 may be limited to only companies C, D, and C that belong to the community identified by community ID=02. Or, the disclosure scope of case 003 may be limited to companies C, D, and C that belong to the community identified by community ID=02, and companies A and C that belong to the community identified by community ID=03.

Company A may form a community separate from the community identified by community ID=01 or 02. For example, as shown by the dashed line in FIG. 19, company A may form a community identified by community ID=Z with company Z. For example, if a recruiter belongs to company A, the recruiter's recruitment opportunities may be disclosed to applicants belonging to company A and applicants belonging to company Z. This level of disclosure may be adopted as a modified version of "Level 3" as shown in FIG. 19.

In this case, "Level 3" corresponds to "allowing disclosure of business information to applicants who belong to a specific community group (a community identified by community ID = Z) that is different from the first group (Company A) and the second-level community groups (Companies A to C) that have formed a community relationship with the first group, and prohibiting disclosure of business information to applicants who do not belong to either the first group or the specific community group."

[Example of the screen displayed when checking side job status]
Fig. 23 is a diagram showing a screen displayed on the applicant device 300 of a manager (the applicant's boss) when the manager checks the side job status of his/her subordinates. Fig. 23 shows an example in which the side job status of the manager's subordinates is displayed on the applicant device 300. The applicant device 300 is provided with a keyboard 306A and a mouse 306B as operation units.

Here, the manager is, for example, the head of the sales department of company C. The side job status of employees in the sales department is shown on display 305. The manager can check the side job status of employees in the sales department by selecting tab 307A, tab 307B, tab 307C, etc. with keyboard 306A or mouse 306B. Therefore, the manager can manage the working hours of his/her subordinates so that they do not fall into a state of overwork. The progress rate may also be displayed on the screen.

[Details of the case]
Fig. 24 is a diagram showing details of the job content included in the recruitment job database 124. The job content includes the recruitment requirements. As shown in Fig. 24, the job content is registered in the recruitment job database 124 by job ID.

The job description includes the items of required skills, required experience, and required qualifications. These items state the conditions required of applicants. Required skills refer to the skills required for the job. Required experience refers to the number of years of work using the required skills. Required qualifications refer to national qualifications, private qualifications, etc.

The required skills, experience, and qualifications are examples of the "abilities" required of applicants. The sharing server 100 classifies multiple recruitment requests by "abilities," using each of the required skills, experience, and qualifications as a "label."

The project contents further include fields for the client and the client's affiliated company. The client refers to the person who proposed the project, i.e., the solicitor. The client's affiliated company refers to the name of the company to which the solicitor belongs.

The project details further include the following items: timing, unit price (unit cost per labor), planned total time, and actual total time. Timing refers to when the work will begin. Unit price (unit cost per labor) refers to the wage per unit time. Planned total time refers to the planned time from the start to the end of the work. Planned total time changes depending on the progress of the project related to the work. Actual total time refers to the time calculated by reviewing the time until the project is completed depending on the progress of the project related to the work.

The job description is an example of job information for the job being recruited. The required skills, required experience, and required qualifications are examples of ability information that can identify the abilities possessed by the applicant. The unit price, planned total hours, and actual total hours are examples of compensation information regarding compensation.

Applicants decide which job they would like to apply for from among a number of jobs, taking into consideration their own capabilities (skills, experience, qualifications). Applicants may interview with the job recruiter if necessary before finally applying for the job. In addition, after selecting a specific person from the applicants as a provisional contractor, the recruiter may interview the provisional contractor before entering into a business contract. After entering into a business contract with the applicant, the recruiter may interview the applicant (contractor) regarding the work content depending on the progress of the work.

[Recommendation function overview]
25 is a diagram showing an overview of the recommendation function of the matching system 1. The matching system 1 has a function of presenting the user with skills that are recommended for acquisition based on the relationship between the skills possessed by the user and the skills required in the labor market. This function is called the recommendation function. As described above, information on a large number of recruitment jobs is registered in the database 120 of the matching system 1. The information on each recruitment job includes the required skills, timing, unit price, and time (planned total time and actual total time) as the job content.

Based on information about recruitment requests, the matching system 1 estimates market value (the value of skills in the labor market) and market size (the size of demand for skills in the labor market) by type of skill.

The matching system 1 estimates market value based on the abilities (experience, skills, qualifications) required for the job posting and the remuneration unit price for the job posting. More specifically, the matching system 1 estimates abilities with a high unit price as abilities with a high market value.

Matching system 1 estimates the market size based on the abilities (experience, skills, qualifications) required for the job posting, the remuneration set for the job posting, and the number of job postings. The remuneration set for the job posting is calculated by multiplying the unit price by the planned total hours or the actual total hours.

More specifically, matching system 1 extracts all recruitment cases related to ability X from among the recruitment cases registered in database 120, and calculates the total amount X of the remuneration set for each of the extracted recruitment cases. This is set as the total amount X of ability X. Matching system 1 calculates the total amount S of the remuneration set for each of all recruitment cases registered in database 120. For example, matching system 1 estimates the market size of ability X based on the ratio of the total amount X to the total amount S.

Matching system 1 creates a labor market map using the estimated market value and market size. Matching system 1 creates two labor market maps: a "market value map" that focuses on market value, and a "market size map" that focuses on labor size.

The matching system 1 acquires from the user (member) information on the abilities possessed by the user himself/herself. As shown in FIG. 25, the ability information includes experience, skills, and qualifications. The matching system 1 evaluates the user's abilities in the labor market based on the acquired information. The matching system 1 represents the relationship between the user's abilities and market value, as well as the relationship between the user's abilities and the market size, on a market map.

Furthermore, the matching system 1 presents recommended skills (skills that the user is recommended to acquire) to the user based on the relationship between the skills possessed by the user and the skills required in the labor market. As shown in FIG. 25, the matching system 1 presents multiple recommended skills to the user in order of recommendation.

By looking at the labor market map, users can understand what skills are considered important in the labor market. Furthermore, by looking at the labor market map, users can understand what skills they should acquire in the future from two perspectives: the skills they already possess and the skills that are considered important in the labor market.

Next, we will explain a market value map, which is an example of a labor market map, with reference to Figures 26 to 28.

Figure 26 is a diagram showing an example of a market value map. The matching system 1 displays the market value map shown in Figure 26 on the screen 550 of the user device 500. The vertical axis of the market value map represents skills. In this example, the skills are programming skills related to IT (Information Technology). The horizontal axis of the market value map represents the years of experience corresponding to the skills. The market value map shows the value of abilities in the labor market in terms of skills and years of experience.

The star 551 indicates the position of the user's ability in the market value map. The star 551 is an example of evaluation information that can identify the degree to which the labor market evaluates the applicant's abilities.

Arrow 552 indicates the direction of new skills that the user should acquire. Arrow 552 indicates the direction of new skills that the user should acquire. The tip of arrow 552 indicates the recommended skills that the matching system recommends to the user. Arrow 552 is an example of information indicating new abilities that the applicant should acquire. Arrow 553 indicates the direction of skills that are not recommended to the user.

The right side of the market value map shows the relationship between the user's skills and the labor market, as well as advice to the user.

By looking at the market value map shown in FIG. 26, the user can understand that although the market size for the skills the user possesses (C/C++) is medium, the market value is low, and even if the user continues to gain more years of experience, the market value of the skills will not increase. Furthermore, by looking at the arrow 552, the user can understand that if the user learns Python skills in the future, he or she will acquire skills with high market value.

Figure 27 is a diagram showing another example of a market value map. The matching system 1 displays the market value map shown in Figure 27 on the screen 550 of the user device 500. The vertical axis of the market value map represents the years of experience related to "C/C++" skills. The horizontal axis of the market value map represents various IT-related qualifications. The market value map shows the value of abilities in the labor market in terms of the years of experience related to "C/C++" skills and various qualifications.

According to the market value map shown in FIG. 27, it can be seen that the user has about three years of work experience using "C/C++" and has IP qualifications. By looking at the market value map shown in FIG. 27, the user can understand that the market value of their skills will not increase even if they continue to gain more years of experience in "C/C++". Furthermore, by looking at arrow 552, the user can understand that if they obtain AP qualifications in the future, the market value of their skills will increase.

A user can increase the market value of their abilities more by aiming to obtain an ST qualification than by aiming to obtain an AP qualification. However, considering the abilities that the user currently possesses, it is unreasonable to recommend that the user obtain an AP qualification, which is highly difficult. Therefore, the matching system 1 indicates with arrow 552 a reasonable direction for developing abilities, taking into account the abilities that the user currently possesses. The market value map further includes the advice that "rather than obtaining a qualification lightly, you need to gain experience as well." Note that the market value map shown in FIG. 27 may also display the "relationship between current abilities and the market" as shown in FIG. 26.

Figure 28 is a diagram showing another example of a market value map. The matching system 1 displays the market value map shown in Figure 28 on the screen 550 of the user device 500. The market value map shown in Figure 28 is obtained by changing the content of the horizontal axis of the market value map shown in Figure 27 from IT qualifications to intellectual property-related skills.

According to the market value map shown in Figure 28, it can be seen that the user has about three years of work experience using "C/C++", but has no experience working with intellectual property. By looking at the market value map shown in Figure 28, the user can understand that even if he continues to gain more years of experience with "C/C++", the market value of his skills will not increase.

Furthermore, by looking at arrow 552, the user can understand that if he or she obtains the qualification of an intellectual property management technician in the future, the market value of his or her abilities will increase. The user will also understand that if he or she obtains the qualification of an intellectual property management technician, he or she will be able to aim to obtain the qualification of a patent attorney, which is more difficult to obtain than an intellectual property management technician and has higher market value.

The market value map further shows training information. The training information is information such as courses that the user should take in order to acquire the recommended skills. By referring to the training information, the user can learn about online courses that are useful for obtaining the qualification of an intellectual property management technician, for example. The training information is an example of information that is useful for acquiring new skills. Note that the market value map shown in FIG. 28 may also display the "relationship between current skills and the market" as shown in FIG. 26.

Above, a market value map, which is an example of a labor market map, has been described using Figures 26 to 28. Here, a market value map has been exemplified as a labor market map, but the matching system 1 can also create a market size map in which the "market value" of the map target is replaced with "market size" and display it on the user device 500 (recruiter device 200, applicant device 300).

In this case, the matching system 1 calculates the market size and reflects the calculation result in the market size map. The format of the market size map is the same as the format of the market value map. However, in the market size map, all the places marked "value" in Figures 26 to 28 are changed to "size."

Various methods can be used to display the market value map and the market size map on screen 550. Matching system 1 may display the market value map and the market size map side by side or vertically on screen 550. Matching system 1 may display the market value map on screen 550 in response to a first operation by the user, and may display the market size map on screen 550 in response to a second operation by the user.

[Other databases]
In the following, in addition to the various databases 121 to 127 shown in FIG. 2, other databases employed in this embodiment will be described.

Figure 29 is a diagram showing an example of the profile database 129. As shown in Figure 29, in the profile database 129, profile information of members (users) is registered by member ID. Some of the profile information may overlap with information registered in the member database 122. The profile information includes the member's name, age, and gender. Furthermore, the profile information includes affiliation information that can identify the member's affiliation (company and department). The affiliation information is an example of group information for identifying either the company or a department within the company.

Furthermore, the profile information includes the member's ability information and recommended ability information for the member. The member's ability information is categorized by skills, experience, and qualifications. These categories correspond to the job recruitment requirements (see Figure 24). For example, the attribute information for each member is made up of age, gender, affiliation, and ability information. When this member attribute information for each company is integrated, attribute information for each company is generated.

The recommended ability information indicates abilities (recommended skills) that are desirable for a member to acquire. The sharing server 100 determines the direction of the arrow 552 shown in Figures 26 to 28 based on the recommended ability information. The sharing server 100 determines new abilities that a member should acquire based on the abilities that the member possesses, the market value of those abilities, and the market size that can be covered by those abilities. The sharing server 100 registers the recommended ability information in the profile database 129 as information that can identify the determined abilities.

In addition, the profile information further includes market value and market size for the member's capabilities.

Figure 30 is a diagram showing an example of the capability database 134. As shown in Figure 30, capability information is registered in the capability database 134 by capability ID. The capability information includes a capability information name and a capability information category. The capability information category includes skills, experience, and qualifications. The capability information includes market value and market size. The sharing server 100 can identify the market value and market size by capability ID (by capability information) by referring to the capability database 134.

Figure 31 shows a specific example of a capability ID. Figure 32 shows a specific example of a skill ID. Figure 33 shows a specific example of an experience ID.

As shown in Figures 31 to 33, the ability ID is generated by combining a skill ID and an experience ID. The skill ID is an identifier for identifying the type of skill and the type of qualification. The experience ID is an identifier for identifying the years of experience. Therefore, the ability information identified by the ability ID is information that combines skills (or qualifications) and experience.

FIG. 32 shows skill IDs related to information-related skills (programming skills). For example, "skill ID=0001-1" corresponds to "Ruby" skills. "Skill ID=0001-2" corresponds to "Python" skills. "Skill ID=0001-3" corresponds to "C/C++" skills. "Skill ID=0001-4" corresponds to "Kotlin" skills. "Skill ID=0001-5" corresponds to "Java (registered trademark)" skills. These are merely examples of skill IDs. For example, it is envisioned in this embodiment that various qualifications will be associated with skill IDs.

As shown in FIG. 33, "Experience ID=0001" corresponds to less than one year of experience. "Experience ID=0002" corresponds to one or more years but less than three years of experience. "Experience ID=0003" corresponds to three or more years but less than five years of experience. "Experience ID=0004" corresponds to five or more years but less than ten years of experience. "Experience ID=0005" corresponds to ten or more years of experience. These are merely examples of experience IDs. The range of years of experience (experience period) may be divided into ranges different from those shown in FIG. 33.

As shown in Figure 31, "Ability ID = 0001-1, 0001" is composed of a combination of "Skill ID = 0001-1" and "Experience ID = 0001." As shown in Figure 31, "Ability ID = 0001-1, 0001" corresponds to "Ruby x less than 1 year." This means "ability equivalent to less than 1 year of Ruby programming experience."

Also, as shown in FIG. 31, "ability ID = 0002-1, 0002" is composed of a combination of "skill ID = 0002-1" and "experience ID = 0002." As shown in FIG. 31, "ability ID = 0002-1, 0002" corresponds to "Python x 1 year or more but less than 3 years." This means "ability equivalent to 1 year or more but less than 3 years of Python programming experience."

The other ability IDs shown in FIG. 31 are similarly composed of a combination of a skill ID and an experience ID, and represent the skill corresponding to the skill ID and the experience period corresponding to the experience ID.

Figure 34 is a diagram showing an example of a skill ID that is formed by combining multiple skills. The number of skills possessed by a user is not limited to one. As shown in Figure 27, it is assumed that a user has, for example, programming skills and IT-related qualifications. Alternatively, as shown in Figure 28, it is assumed that a user has, for example, IT-related skills and intellectual property-related skills. Here, we introduce an example of a skill ID that can be used when it is assumed that a user has multiple skills.

Figure 34 shows two examples of skill IDs corresponding to multiple skills. One is a skill ID generated by combining programming-related skills and IT-related qualifications. The other is a skill ID generated by combining programming-related skills and intellectual property-related qualifications.

As shown in FIG. 34, "Skill ID=0001-3-1" corresponds to possessing "C/C++" skills and "IP" skills (qualifications). In "Skill ID=0001-3-1", "0001-3" represents "C/C++", and the following "-1" represents "IP".

The other skill IDs shown in FIG. 34 are defined in a similar manner. "Skill ID=0001-3-2" corresponds to possessing "C/C++" skills and "FE" skills (qualifications). "Skill ID=0001-3-3" corresponds to possessing "C/C++" skills and "AP" skills (qualifications). "Skill ID=0001-3-4" corresponds to possessing "C/C++" skills and "SA" skills (qualifications). "Skill ID=0001-3-5" corresponds to possessing "C/C++" skills and "ST" skills (qualifications).

"Skill ID = 0001-3-11" corresponds to possessing the skills of "C/C++" and the skills (qualification) of "Intellectual Property Management Technician." "Skill ID = 0001-3-12" corresponds to possessing the skills of "C/C++" and the skills (qualification) of "Patent Attorney."

[Explanation of processing procedures related to the recommendation function]
Next, various processing procedures related to the recommendation function will be described with reference to Fig. 35 to Fig. 42. Fig. 35 is a flowchart showing processing procedures related to the recommendation function of the matching system 1.

In the flowchart shown in FIG. 35, first, the sharing server 100 collects a plurality of pieces of recruitment job information (step Sr1). In step Sr1, the sharing server 100 functions as a job information acquisition unit.

Next, the sharing server 100 determines whether or not each of the multiple recruitment job information requires labeling (step Sr2). When checking the recruitment requirements, the sharing server 100 determines that recruitment job information that can be classified into the ability information category of the ability ID does not require labeling. When checking the recruitment requirements, the sharing server 100 determines that recruitment job information that cannot be classified into the ability information category of the ability ID requires labeling.

The sharing server 100 labels recruitment job information that requires labeling. That is, the sharing server 100 classifies the contents of the recruitment requirements included in the recruitment job information into ability information (skills, experience, and qualifications) based on the criteria of the experts (step Sr3). In step Sr3, the sharing server 100 functions as a labeling unit.

Next, the sharing server 100 uses the labeled data to calculate the market value and market size for each piece of capability information (step Sr4). Similarly, the sharing server 100 uses the case information data for which it has been determined that labeling is not required to calculate the market value and market size for each piece of capability information (step Sr5).

In steps Sr4 and Sr5, the sharing server 100 functions as a calculation unit. The calculation results by the calculation unit (steps Sr4 and Sr5) correspond to the estimated market value and market size. The calculation unit estimates the labor market's evaluation of work-related abilities by type of work-related ability based on the work information included in each of the multiple recruitment cases.

Next, the sharing server 100 calculates the market value and market size of the user's capabilities based on the user's capability information (step Sr6). In step Sr6, the sharing server 100 functions as a capability information acquisition unit. The sharing server 100 acquires the user's capability information from the profile database 129.

In order to register the capability information in the profile database 129, the user must upload the capability information to the sharing server 100. The types of capability information uploaded by the user are various.

For this reason, the sharing server 100 may not be able to immediately classify the ability information uploaded by the user into a category assumed in the profile database 129. Taking such a situation into consideration, the sharing server 100 may perform a labeling process on the ability information uploaded by the user in the same way as for the recruitment job information.

Next, the sharing server 100 calculates the ability to recommend to the user (step Sr7). In step Sr7, the sharing server 100 functions as a recommendation unit.

Next, the sharing server 100 displays the labor market map (market value, market size) on the user device 500 (step Sr8). As a result, the market value and market size related to the abilities possessed by the user, as well as the recommended skills, are displayed on the screen 550 of the user device 500. In step Sr8, the sharing server 100 functions as a display unit. The display unit displays the above-mentioned estimation results on the user device 500.

Figure 36 is a flowchart showing the processing steps of the case information acquisition unit (Sr1). The sharing server 100 acquires information on each recruitment case from the recruitment case database 124 (step Sr11). This ends the processing of the case information acquisition unit.

Figure 37 is a flowchart showing the processing steps of the labeling unit (Sr3). First, the sharing server 100 acquires information on each recruitment request from the recruitment request database 124 (step Sr31). Next, the sharing server 100 checks the information on the recruitment requirements of the recruitment request (step Sr32). The information on the recruitment requirements includes skills, experience, and qualifications.

Next, the sharing server 100 labels the recruitment request based on the criteria of the experts and the contents of the recruitment requirements included in the recruitment request information (step Sr33). Next, the sharing server 100 registers the labeling results in the recruitment request database 124 (step Sr34). More specifically, a label of the required capabilities (skills, experience, qualifications) is attached to the recruitment request. This ends the processing of the labeling unit.

Figure 38 is a flowchart showing the processing steps of the calculation unit (Sr4, Sr5). First, the sharing server 100 acquires the ability information (required skills, required experience, required qualifications), unit price information, and time information for the recruitment request from the recruitment request database 124 (step Sr41).

The sharing server 100 may use either the planned total time or the actual total time included in the case contents as the time information. For example, the sharing server 100 may use the actual total time for cases where the work has been completed, and the planned total time for cases where the work has not been completed.

Next, the sharing server 100 categorizes the recruitment requests by the ability information of the recruitment requests (step Sr42). This classifies the recruitment requests by ability ID. Next, the sharing server 100 calculates the market value and market size for each category (step Sr43).

The sharing server 100 executes the processes of steps Sr42 and Sr43 for all recruitment requests. As a result, the market value and market size for each ability information item (required skills, required experience, required qualifications) are calculated (estimated) based on the ability information for the recruitment request.

Here, we will explain the method by which sharing server 100 calculates the market value and market size based on recruitment applications. First, sharing server 100 groups recruitment applications based on the recruitment requirements (skills, experience, qualifications). Next, sharing server 100 calculates the average unit price of the recruitment applications and the total amount of remuneration for each recruitment application for each group. Next, sharing server 100 evaluates the market value based on the average unit price, and evaluates the market size based on the total amount.

When calculating the market value and market size, the sharing server 100 may take into account the time of solicitation of the solicited items. In other words, the sharing server 100 may adjust the coefficients in the calculation formula so that older items have a smaller contribution rate to the calculation result than newer items.

After step Sr43, the sharing server 100 registers the market value and market size for each category of capability information in the capability database 134 (step Sr44). This ends the processing of the calculation unit.

Figure 39 is a flowchart showing the processing steps of the capability information acquisition unit (Sr6). First, the sharing server 100 acquires the user's capability information from the profile database 129 (step Sr61). Next, the sharing server 100 acquires the market value and market size for each capability information category from the capability database 134 (step Sr62).

Next, the sharing server 100 calculates the market value and market size for the capabilities possessed by the user (step Sr63). Next, the sharing server 100 registers the market value and market size for the capabilities possessed by the user in the profile database 129 (step Sr64). This ends the processing of the capability information acquisition unit.

Figure 40 is a flowchart showing the processing steps of the recommendation unit (Sr7). First, the sharing server 100 acquires the user's capability information from the profile database 129 (step Sr71). Next, the sharing server 100 acquires the market value and market size for each capability information category from the capability database 134 (step Sr72).

Next, the sharing server 100 calculates the ability information (recommended skills) that will increase the market value if the user further acquires them (step Sr73). Next, the sharing server 100 ranks the recommended skills according to the degree of improvement in market value (step Sr74). Next, the sharing server 100 registers the ranking information as recommended abilities in the profile database 129 (step Sr75). This ends the processing of the recommendation section.

In addition, the sharing server 100 may calculate the market value and market size of the user's abilities when the user acquires multiple recommended skills. In addition, the sharing server 100 may register only the highest ranked recommended skill among the multiple calculated recommended skills in the profile database 129.

Figure 41 is a flowchart showing the processing procedure of the display unit (Sr8). First, the sharing server 100 acquires the user's profile information from the profile database 129 (step Sr81). The profile information includes the user's capability information.

Next, the sharing server 100 obtains the market value and market size for each category of ability information from the ability database 134 (step Sr82). Next, the sharing server 100 obtains market information for each ability possessed by the user (step Sr83).

Next, the sharing server 100 obtains information on recommended skills for the user from the ability database 134 (step Sr84). Next, the sharing server 100 displays on the user device 500 the market value and market size of the abilities possessed by the user, the recommended skills, and information on the market value and market size if the recommended skills are acquired (step Sr85). This ends the processing of the display unit.

Figure 42 is a flowchart showing the processing steps of the recalculation unit (Sr9). First, the sharing server 100 receives an instruction to recalculate the market value and market size from an administrator of the sharing server 100 or the like (step Sr91). Next, the sharing server 100 executes Sr1 to Sr7 again to recalculate the market value and market size (step Sr92). This ends the processing of the recalculation unit.

The sharing server 100 may execute steps Sr91 and Sr92 of the recalculation unit by batch processing or the like. For example, the sharing server 100 may execute the processing of the recalculation unit periodically at a specified timing. When batch processing is employed, it is desirable that the processing of the labeling unit be performed in advance.

As described above, matching system 1 is an example of a job information providing system that provides job information of a job to applicants who apply for the job. Matching system 1 effectively utilizes a platform that matches recruiters and applicants to estimate the labor market's evaluation of job-related abilities by type of job-related ability, and displays the estimation results on the applicant device. Matching system 1 can provide applicants with information that enables them to understand the abilities that are considered important in the labor market.

Furthermore, matching system 1 identifies the abilities possessed by the applicant based on ability information that can identify the abilities possessed by the applicant, and displays evaluation information indicating the labor market's evaluation of the abilities possessed by the applicant on the applicant device. More specifically, matching system 1 has a function of presenting the applicant with the market value and market size of the abilities possessed by the applicant, as well as recommended skills.

According to the matching system 1, based on the abilities that the applicant possesses, it is possible to teach the applicant the abilities that will increase their market value more effectively if they are acquired in the future. This allows the applicant to understand the abilities that will increase their market value and to efficiently proceed with skill development. More specifically, the applicant can understand the skill information that he or she should acquire, and can receive optimal reskilling, recurrent education, or training. As a result, the applicant can aim to become a human resource with higher market value.

As explained above, the sharing server 100 communicates with the applicant device 300 operated by the applicant via the communication interface 104. The sharing server 100 accesses a database 120 (particularly the recruitment job database 124) in which job information (job content) is registered for each recruitment job. The sharing server 100 estimates the labor market's evaluation of job-related abilities by type of job-related ability based on the job information contained in each of the multiple recruitment jobs (steps Sr42, Sr43), and displays the estimation results on the applicant device (step Sr85).

The database 120 (profile database 129) contains registered ability information that can identify the abilities possessed by the applicant. The sharing server 100 identifies the abilities possessed by the applicant based on the ability information (step Sr61), and displays evaluation information (star mark 551) indicating the labor market's evaluation of the abilities possessed by the applicant on the applicant device 300 (step Sr85).

Based on the estimation result and the abilities possessed by the applicant, the sharing server 100 displays information (arrow 552) indicating new abilities (recommended skills) that the applicant should acquire on the applicant device (step Sr85). Furthermore, the sharing server 100 displays information (training information) that is useful for acquiring new abilities on the applicant device 300 (see FIG. 28).

As shown in FIG. 24, the job information includes ability information regarding the abilities required of the applicant (required skills, required experience, required qualifications) and compensation information regarding compensation (unit price, planned total hours, actual total hours). The sharing server 100 estimates the labor market's evaluation of the abilities related to the job based on the ability information and compensation information (steps Sr42, Sr43). As shown in FIG. 30, the ability information includes the applicant's skills and the period of experience of the job using the skills.

As shown in Figures 1, 26 to 28, and step Sr85, the labor market's assessment of work-related abilities includes either the value that the labor market places on the work-related abilities (market value) or the size of the labor market in which the work-related abilities are needed (market size).

In order to use crowdsourcing to find more suitable personnel, it is desirable to broaden the scope of crowdsourcing beyond a specific company or a small number of companies. In this case, it becomes necessary to consider the interests between the recruiter who is recruiting contractors for the work and the applicant who applies for the recruitment. In this embodiment, the recruiter device 200 transmits to the sharing server 100 the business information for which the contractors are being recruited and disclosure information indicating the disclosure range of the business information. The sharing server 100 registers the business information together with the disclosure information in the database 120. The sharing server 100 determines, based on the disclosure information, the business information that is permitted to be disclosed to the applicant among the business information registered in the database 120, and provides the applicant device 300 with the business information that is permitted to be disclosed to the applicant. Therefore, according to this embodiment, it is possible to select an appropriate applicant taking into consideration the interests between the recruiter and the applicant.

In the present embodiment described above, a "company group" and a "departmental group within the same company" are examples of a "group." Applicants who do not belong to a company, such as freelancers, may form a "group." A "company group" may be formed by multiple companies.

In this embodiment, a "company that forms a community relationship" is an example of a "community group."

In this embodiment, the "non-disclosure target" information included in the disclosure information is an example of "information that can identify a target person to whom disclosure of business information is prohibited."

The communication (S9 in FIG. 11) in which approval information is transmitted from the applicant device 300 of the manager functioning as an approver to the approval unit 147 is performed on a logical communication path identified by the member ID of the approver. "The approval unit 147 receiving approval information on such a communication path" is an example of "receiving an approval notification in a communication involving the identification information of the approver of the first applicant."

In this embodiment, the "applicant evaluation summary" registered in the evaluation summary database 127 is an example of "evaluation information based on evaluation received from the recruiter device 200 functioning as an evaluator device." In this embodiment, the "recruiter evaluation summary" registered in the evaluation summary database 127 is an example of "evaluation information based on evaluation received from the applicant device 300 functioning as an evaluator device."

Figure 9 merely shows an example of data registered in the evaluation summary database 127. In this embodiment, it is also assumed that a member belonging to company A, in the position of an applicant, evaluates members belonging to companies A, B, C, etc. and acting as recruiters. In this embodiment, it is also assumed that a member belonging to company B, in the position of an applicant, evaluates members belonging to companies A, B, C, etc. and acting as recruiters. In this embodiment, it is also assumed that a member belonging to company A, in the position of a recruiter, evaluates members belonging to companies A, B, C, etc. and acting as applicants. In this embodiment, it is also assumed that a member belonging to company B, in the position of a recruiter, evaluates members belonging to companies A, B, C, etc. and acting as applicants.

In this embodiment, the "recruiter device 200A" operated by a recruiter belonging to company A functions as an evaluator device and is an example of a "first evaluator device (recruitment side first evaluation device) operated by one or more evaluators belonging to a first group." In this embodiment, the "applicant device 300A" operated by an applicant belonging to company A functions as an evaluator device and is an example of a "first evaluator device (applicant side first evaluation device) operated by one or more evaluators belonging to a first group."

In this embodiment, the "recruiter device 200B" operated by a recruiter belonging to company B functions as an evaluator device and is an example of a "second evaluator device (recruitment side second evaluation device) operated by one or more evaluators belonging to a second group different from the first group." In this embodiment, the "applicant device 300B" operated by an applicant belonging to company B functions as an evaluator device and is an example of a "second evaluator device (applicant side second evaluation device) operated by one or more evaluators belonging to a second group different from the first group."

In FIG. 21, a systems department and a planning department are shown as examples of departments of company B. In this embodiment, "one of the systems department and the planning department" is an example of a "first divided group" included in the first group, and the other is an example of a "second divided group" included in the first group.

Based on the estimated man-hours registered in the recruitment job database 124, the side job upper limit hours registered in the company database 121, the side job actual hours registered in the side job database 125, and the expected side job hours registered in the side job database 125, the sharing server 100 extracts from the list in the recruitment job database 124 task information for which the applicant's working hours do not exceed the upper limit hours. Specifically, for example, if an applicant is engaged in multiple side jobs, the sharing server 100 calculates the sum of the side job actual hours corresponding to each side job to obtain the total actual side job hours, calculates the sum of the expected side job hours corresponding to each side job, and obtains the total expected side job hours.

The sharing server 100 adds the calculated total actual side job time to the calculated total expected side job time to calculate the total side job time. The sharing server 100 calculates the applicant's available side job time by subtracting the total side job time from the applicant's maximum side job time. The sharing server 100 searches the list of available side job database 124 for jobs that can be completed with the calculated available side job time.

At this time, the sharing server 100 calculates the time required to handle each recruitment job based on the estimated man-hours in the recruitment job database 124, and searches for recruitment jobs that fall within the range of possible side job hours. Here, the "side job upper limit time" is an example of "upper limit time that is the upper limit of the applicant's working hours", the "side job actual time" is an example of "actual time that is the time the applicant has already worked as an actual result", and the "side job expected time" is an example of "expected time expected as the applicant's working hours". The upper limit time may not only be for the side job, but also for the time that sets an upper limit on the total time of the main job and the side job.

The first upper limit time may not be the upper limit time for the side job, but may be the upper limit time for all work including the main job and the side job. The first actual time and the first expected time may be not only the time for the side job, but also the total time for all work including the side job and the main job.

The recruiter device 200 and the applicant device 300 may not only be equipped with all of the processor, memory, communication interface, and input/output interface shown in FIG. 2, but may also be a thin client system that uses a VDI (Virtual Desktop Infrastructure). A thin client system that uses a VDI is a system in which a desktop environment on a server is transferred to a terminal in a remote location for use. The recruiter device 200, the applicant device 300, and the sharing server 100 do not necessarily need to be independent devices. When using a thin client system such as the one described above, the functions of the recruiter device 200, the applicant device 300, and the sharing server 100 can be provided on the same aggregation server.

The database 120 is not limited to a relational database, but may be an object-type or NoSQL-type database.

The sharing server 100 is an example of a computing device. A computing device may be configured by a server (on-premise server, cloud server, etc.) or a serverless system. Here, an on-premise server is a server installed and managed in facilities managed within a company. A cloud server is a server (rented server) provided by another business operator via a network. A serverless system is a system in which computing and memory functions can be used only when necessary, without being aware of the existence of a server. Computing devices include servers and serverless systems. Servers include on-premise servers and cloud servers.

<Modification 1>
Next, a first modification will be described with reference to Figures 43 to 45. In the first modification, a counter offer function will be described, which allows a recruiter to encourage a person selected from a large number of members to join the recruiting business.

[Background to proposing the counter offer feature]
In crowdsourcing, recruiters generally disclose information about the job they are looking for and wait for applications from those who are interested in the job. However, with this method of recruitment, it may take a long time for applicants to respond. Also, it is unclear whether applications will come from people with the skills the recruiter expects.

One possible solution is for the recruiter to search for members and select a suitable member (counter offer). However, if the recruiter is only informed of the member ID and the member's name, it is difficult for the recruiter to select the applicant they truly desire. Furthermore, member information of rival companies must be excluded from the search results to prevent confidential information from being leaked to rival companies, etc.

In light of this background, in Variation 1, search results including detailed member profile information are provided to recruiters who perform a member search. Furthermore, in Variation 1, member information of companies that are rivals to the recruiter's company is excluded from the search results. Variation 1 will be described in detail below with reference to the drawings.

Figure 43 is a diagram for explaining the functions of the sharing server 100, recruiter device 200, and applicant device 300 related to variant example 1.

As shown in FIG. 43, in addition to the member search unit 143, the sharing server 100 functionally includes a counter offer request unit 161, a counter offer approval request unit 162, and a counter offer request acceptance notification unit 163. These various functions are realized by the processor 101, memory 102, storage 103, and communication interface 104 provided in the sharing server 100.

As already explained, the member search unit 143 has a function of searching for members of the matching system 1. In particular, in the first modification, the member search unit 143 has a function of providing detailed profile information of members to the searcher. When the recruiter's search operation is accepted, the recruiter device 200 executes a member search process (step S21). In particular, in step S21, the recruiter device 200 accepts a search operation for the recruiter to make a counter offer. The member search unit 143 provides the recruiter device 200 with information on members registered in the member database 122. The provided member information includes detailed profile information of members. However, the member search unit 143 excludes member information of companies, etc. that are in a rival relationship with the recruiter's affiliated company, etc., from the search results.

The recruiter device 200 receives the member information (search result) from the member search unit 143, and displays the member information as the search result on the display 205 (step S22). The recruiter device 200 then accepts an operation by the recruiter to select an applicant from the search results. That is, the recruiter selects a member to which to make a counter offer based on the search results, and makes the counter offer by operating the recruiter device 200 (step S23). The recruiter device 200 transmits the member ID of the member to whom the counter offer is to be made to the sharing server 100.

The counter offer request unit 161 receives the member ID of the member who is the target of the counter offer from the recruiter device 200. The counter offer request unit 161 identifies the member corresponding to the received member ID. The counter offer request unit 161 notifies the applicant device 300 of the member who is the target of the counter offer that a request for a counter offer has been received. This notification may include information on the recruitment case that is the target of the counter offer. The member who is the target of the counter offer receives the request for a counter offer via the applicant device 300. The "request" received here is an example of "information that encourages the applicant to apply." The member who is the target of the counter offer decides whether to accept the request for a counter offer. The member who is the target of the counter offer can use the applicant device 300 to perform an operation to accept the request for a counter offer or an operation to reject the request for a counter offer. The applicant device 300, for example, accepts the request for a counter offer (step S24). The applicant device 300 that has accepted the request for a counter offer transmits the application information to the counter offer approval request unit 162.

The counter offer approval request unit 162 sends the subordinate's application information to the applicant's superior. The counter offer approval request unit 162 identifies the member ID of the superior, who is the applicant's manager, based on the relationship between the applicant's member ID and the superior's member ID registered in the member database 122. The applicant's superior checks the application information on his or her own applicant device 300 and approves the application (step S25).

The counter offer request acceptance notifying unit 163 receives approval information from the applicant's superior. The counter offer request acceptance notifying unit 163 accepts the applicant's application on the condition that the approval information has been received. The counter offer request acceptance notifying unit 163 notifies the recruiter device 200 that the application from the member who made the counter offer has been accepted. Based on the notification, the recruiter device 200 notifies the recruiter that the counter offer has been accepted (step S26). More specifically, the recruiter device 200 displays information on the display 205 to notify the recruiter that the counter offer has been accepted.

Figure 44 is a diagram showing an example of a member database 122A relating to variant example 1. Compared to the member database 122 shown in Figure 4, the member database 122A shown in Figure 44 has profile information and profile disclosure information indicating whether or not the profile is to be made public added to it.

The matching system 1 gives members the authority to register and modify their own profile information in the member database 122A using the applicant device 300. Members register various pieces of their own profile information in the member database 122A using the applicant device 300. The profile information includes, for example, the member's Synthetic Personality Inventory (SPI) information, the member's work history, the member's track record, the member's qualifications, etc.

Members set public profile information using the applicant device 300. Profile information of members whose profile public information is set to allowed is provided to searchers. Profile information of members whose profile public information is set to not allowed is not provided to searchers. The sharing server 100 registers the public profile information in the member database 122A based on the settings selected by each member. In this way, the sharing server 100 accepts input of information from each of multiple members indicating whether or not they permit their profile information to be included in search results.

Here, an example has been described in which it is determined whether or not disclosure of a member's profile information is permitted based on the settings of the profile public information. However, the sharing server 100 may also be configured to accept a setting operation for whether or not to permit disclosure for each type of profile information. This allows, for example, a member to make achievements and qualifications public, while keeping SPI information private. Alternatively, if age is included in the profile information, the member can keep age private and make other profile information public. In this case, the sharing server 100 registers multiple pieces of profile information for each of multiple registrants (members) in the member database 122A. The sharing server 100 accepts input from each of the multiple registrants to set the range of the multiple pieces of profile information to be made public as search results.

Figure 45 is a flowchart showing the processing steps of the reverse offer member search process related to variant example 1. The processing based on this flowchart is executed by the sharing server 100.

First, the sharing server 100 accepts a search request by a searcher to search for members suitable for a recruitment request (step S211). Here, the searcher is a recruiter who has a recruitment request. The recruiter uses his/her own recruiter device 200 to search for members who have skills suitable for the recruitment request in order to make a counter offer to members. The recruiter's search request is accepted by the sharing server 100 in step S211. The search request may include the member ID of the searcher and the case ID of the recruitment request.

Next, the sharing server 100 identifies the company to which the searcher belongs from the member database 122A and the company database 121 (step S212). Next, the sharing server 100 identifies the community to which the searcher belongs from the community database 123 (step S213).

Next, the sharing server 100 identifies the disclosure level and non-disclosure company ID list of the recruitment requests registered in the recruitment request database 124 (step S214). Next, the sharing server 100 extracts members who can disclose to the searcher (step S215).

More specifically, the sharing server 100 identifies companies that should not disclose recruitment opportunities held by the searcher (recruiter) based on the non-disclosure company list and disclosure level in the recruitment opportunity database 124. The sharing server 100 determines members belonging to such companies as members who cannot be disclosed to the searcher. The sharing server 100 extracts members other than those belonging to such companies as members who can be disclosed to the searcher.

Next, the sharing server 100 refers to the member database 122A and excludes the profile information of members who have set their profile information to non-disclosure from the extracted member information (step S216).

Next, the sharing server 100 transmits the extracted member information to the search request source (step S217), and ends the processing based on this flowchart. The recruiter device 200 that transmitted the search request receives the member information transmitted from the sharing server 100, and displays the information on the display 205. The information displayed on the display 205 displays the ID, name, and profile information of each extracted member. However, for members who have not disclosed their profile information, only the member's ID and name are displayed, and no profile information is displayed.

As explained above, according to variant 1, a recruiter can refer to detailed profile information of members, search for members who are considered to be the best candidates to apply for the job, and make a counteroffer to those members. Furthermore, members from companies that are in a rival relationship with the recruiter's company and community are excluded from the members displayed as search results. This prevents the recruiter from placing an order for work with members from such rival companies. Furthermore, since members themselves can decide whether or not to make their profile information public, a system can be provided that respects the free will of each member.

Note that members may be able to set whether or not to make their name public, in addition to their profile information. Additionally, several categories may be set for profile information, and members may be able to set whether or not to make their profile information public for each category.

By adding the offer function described above to matching system 1, recruiters can check the profile information of members who are permitted to view recruitment cases. Furthermore, recruiters can encourage applications from members with whom they themselves want to place orders. Furthermore, members who are encouraged to apply by the recruiter can view the case information and accept or reject the application. Furthermore, when registering or editing member information, each member can decide whether or not to make their profile information public. This allows recruiters to actively select who to offer to and get the most suitable applicants to work early.

<Modification 2>
Next, a second modified example will be described with reference to Figures 46 to 50. In the second modified example, a member group application function will be described, which allows a plurality of members to apply for a recruitment operation as a group.

[Background to proposing the member group application feature]
In crowdsourcing, generally, recruiters disclose information about the job they are looking for, and individuals who are interested in the job apply for the job. However, there are many jobs that should be handled by a team of several people, or where it is preferable to handle them as a team, such as comprehensive tasks from business planning to acquiring intellectual property rights related to the plan. For this reason, if the number of people recruited is limited to one person, it is difficult for those who wish to accept the order to take on more work than they can handle individually.

In light of this background, Variation 2 provides a member group application function that allows multiple members to apply for recruitment activities as a group. Variation 2 is described in detail below.

Figure 46 is a block diagram showing the configuration of the sharing server 100, recruiter device 200, and applicant device 300 relating to variant example 2. Compared to the block diagram shown in Figure 2, the block diagram shown in Figure 46 adds a member group database 128. The recruitment request database 124A shown in Figure 46 adds a function to the recruitment request database 124 shown in Figure 6 that allows registration of recruitment requests that allow application by member groups.

Member groups consisting of multiple members are registered in the member group database 128. Using the recruiter device 200, the recruiter can register recruitment jobs that allow application by member groups in the recruitment job database 124A. Using the applicant device 300, the applicant can apply for recruitment jobs that allow application by member groups using a member group registered in the member group database 128.

Figure 47 is a diagram showing an example of a member group database 128 relating to variant example 2. Member group information is registered in the member group database 128. The member group information includes a group ID for identifying the member group, the company ID of the company to which each member of the member group belongs, and the member ID of each member of the member group.

Hereinafter, the member groups corresponding to each group ID may be referred to as member group G1, member group G2, member group G3, etc. using the group ID.

Member group G1 is made up of three members identified by member IDs P1, P2, and P5. The company ID registered for member group G1 is 00A, so it can be seen that all three members belong to company A.

Member group G2 is composed of two members identified by member IDs P1 and P3. The company IDs registered corresponding to member group G2 are 00A and 00B, so it can be seen that one of the two members belongs to company A and the other belongs to company B. As can be seen by comparing member group G1 and member group G2, member ID P1 is registered in both member groups G1 and G2. Therefore, member P1 belongs to two member groups.

Member group G3 is made up of four members identified by member IDs P4, P7, P8, and P14. The company ID registered for member group G3 is 00C, so it can be seen that all four members belong to company C.

The member group database 128 is stored in the storage 103 of the sharing server 100, as shown in FIG. 46. A member forms a member group with the consent of other members who he or she has met through the same company or community, etc., and registers the member group in the member group database 128. A "member group" is an example of an "application group."

Figure 48 is a diagram showing an example of the recruitment request database 124A relating to variant example 2. Compared to the recruitment request database 124 shown in Figure 6, the recruitment request database 124A shown in Figure 48 has additional information on the recruitment type. The recruiter operates the recruiter device 200 to set the recruitment type. The sharing server 100 registers the recruitment type based on the setting in the recruitment request database 124A in association with the business information.

Recruiters can select the recruitment type from group and individual. If the recruiter does not select a recruitment type, the recruitment type of the recruitment project is considered to be not limited to group or individual. Projects with the recruitment type set to group can only be accepted by member groups. Projects with the recruitment type set to individual can only be accepted by individual members. Projects with no recruitment type restrictions can be accepted by both member groups and individuals. "Recruitment type information" is an example of "information that can identify that the job for which contractors are being recruited is a job to which multiple recruiters should jointly apply."

Figure 49 is a diagram for explaining the functions of the sharing server 100, recruiter device 200, and applicant device 300 relating to variant example 2. In Figure 49, compared to Figure 11, a determination unit 145A is added to the sharing server 100. Also, compared to Figure 11, in Figure 49, step S7A is added after step S7, and step S8A of group application is adopted instead of step S8 of application.

Here, it is assumed that the applicant belongs to multiple member groups. The applicant operates the applicant device 300 to search for recruitment cases (step S6). The applicant device 300 transmits a search request to the case extraction unit 145 of the sharing server 100.

When the case extraction unit 145 receives a search request, it extracts cases that the applicant is allowed to view from among the recruitment cases registered in the recruitment case database 124, as explained using FIG. 11. The cases extracted by the case extraction unit 145 include cases where the recruitment type is either "group," "individual," or "unlimited." The case extraction unit 145 transmits the extracted recruitment cases to the applicant device 300. The applicant device 300 receives the recruitment cases from the case extraction unit 145. The applicant device 300 displays the received recruitment cases on the display 305 (step S7).

For each recruitment case, the display 305 displays the disclosure level, case title, estimated man-hours, estimated period, case content, recruitment type, etc. If the applicant wishes to apply as a member group, the applicant uses the operation unit 306 such as a mouse and keyboard to specify the member group and select a case for which the recruitment type is set to "group" or "unlimited." The applicant device 300 accepts the member group and the case for which the applicant wishes to apply based on the applicant's operation (step S7A). The applicant device 300 transmits the group ID of the accepted member group and the case ID of the accepted case to the sharing server 100. The determination unit 145A of the sharing server 100 acquires the group ID and case ID.

The determination unit 145A accesses the member group database 128 and identifies the member ID registered corresponding to the acquired group ID. The determination unit 145A accesses the member database 122 and identifies the company ID corresponding to the identified member ID.

The determination unit 145A accesses the community database 123 and identifies the community ID of the community to which the company with the identified company ID belongs. The determination unit 145A accesses the recruitment case database 124A and identifies the company ID (the company ID of the recruiter), non-disclosure company ID, disclosure level, and recruitment type registered in correspondence with the acquired case ID.

Based on the information identified as described above, the determination unit 145A determines whether the recruitment request accepted by the applicant device 300 is a request for which application by the member group designated by the applicant is permitted. In other words, the determination unit 145A determines whether or not to permit application by the member group.

For example, if one of the members in the member group belongs to a company that is listed in the non-disclosure company ID list corresponding to the recruitment request, the determination unit 145A will not allow the member group to apply. Alternatively, if one of the members in the member group belongs to a company outside the community, even if the disclosure level of the recruitment request is "within the community," the determination unit 145A will not allow the member group to apply.

The determination unit 145A returns the determination result to the applicant device 300. Figure 49 shows the flow when the application by the member group is permitted by the determination unit 145A. When the application by the member group is permitted by the determination unit 145A, the applicant device 300 accepts the application by the member group (step S8A). For example, the applicant device 300 displays on the display 305 a screen indicating that the application accepted in step S7A is permitted and a screen for confirming whether or not to apply. The applicant selects to apply using the operation unit 306, such as a mouse and keyboard.

When the applicant device 300 accepts an application from a member group (step S8A), it transmits application information to the sharing server 100. The application unit 146 of the sharing server 100 acquires the application information. The subsequent processing is the same as that described using FIG. 11. However, the application unit 146 transmits the application information to the superiors of each member belonging to the member group. Therefore, the application approval processing of step S9 is executed for each superior of each member belonging to the member group. Therefore, the approval unit 147 receives approval information indicating that the subordinate's application is approved, or rejection information indicating whether the subordinate's application is rejected, from multiple superiors.

The approval unit 147 accepts an applicant's application only if approval information has been obtained from all superiors of each member belonging to the member group. After accepting an applicant's application, the approval unit 147 transmits the application information to the recruiter device 200. As already explained using FIG. 11, the recruiter device 200 displays the application details on the display 205 (step S10). The recruiter inputs the result of the hiring or rejection decision to the recruiter device 200. The recruiter device 200 accepts the input result (step S11) and transmits the accepted hiring or rejection result to the notification unit 148 of the sharing server 100.

The notification unit 148 transmits the application result (result of whether the applicant was hired or not) to the applicant's applicant device 300 and the applicant's superior (manager) applicant device 300. However, the notification unit 148 transmits the application result to the superior of each member belonging to the member group.

The applicant's device 300 and the applicant's device 300 of the superior of each member belonging to the member group display the application results on the display 305 (steps S12 and S13). The applicant and the superior of each member belonging to the member group check the application results by looking at the display 305.

Figure 50 is a diagram for explaining the procedure for registering a recruitment request related to variant example 2 in the recruitment request database 124A. In Figure 50, compared to Figure 14, the recruitment type has been added to the business information input to the recruiter device 200.

In the second variant, when a recruiter who registers a recruitment request inputs the business information and disclosure information of the recruitment request into the recruiter device 200, the recruiter can include the recruitment type of the recruitment request in the business information. The recruitment type is either group or individual. The request registration unit 144 of the sharing server 100 registers the recruitment request, including the recruitment type selected by the recruiter, in the recruitment request database 124A (step S1442). If the recruiter does not select a recruitment type, the request registration unit 144 registers information indicating that the recruitment type is not limited in the recruitment request database 124A. The other contents shown in FIG. 50 are the same as those in FIG. 14 already described, and therefore will not be described again here.

As explained above, according to variant 2, multiple members can apply for a job posting as a group. Moreover, according to variant 2, whether or not to accept an application from a member group is determined based on the relationship between the company and community to which the recruiter belongs and the companies and communities to which each member of the member group belongs. This makes it possible to prevent a member group that includes a member who belongs to an organization in competition with the applicant from accepting a job posting from that applicant.

By adding the member group application function described above to the matching system 1, it is possible to provide a system in which the recipient can view job postings and apply for them as a member group. This makes it possible for the matching system 1 to handle orders for large-scale work that is best done in teams.

The present embodiment described above has the following configuration for a matching system, which is an example of a business information provision system.

(a) In the matching system, the recruiter device transmits business information for recruiting contractors and disclosure information indicating the scope of disclosure of the business information to the computing device, the computing device registers the business information together with the disclosure information in a database, the computing device determines, based on the disclosure information, which business information registered in the database is permitted to be disclosed to the first applicant, and provides the business information permitted to be disclosed to the first applicant to the first applicant device.

(b) The matching system further includes a second applicant device operated by a second applicant different from the first applicant, and the computing device determines, based on the disclosure information, business information that is permitted to be disclosed to the second applicant from among the business information registered in the database, and provides the business information that is permitted to be disclosed to the second applicant to the second applicant device.

(c) In the matching system, the matching system further includes a third applicant device operated by a third applicant different from the first applicant and the second applicant, and multiple disclosure levels are set for the disclosure information, and the computing device determines whether or not to permit disclosure for each of the first to third applicants depending on the disclosure level.

(d) In a matching system, a first applicant belongs to a first group and a second applicant belongs to a second group different from the first group, and the multiple disclosure levels include a first level and a second level, the first level corresponds to permitting disclosure of business information to the first applicant and prohibiting disclosure of business information to applicants not belonging to the first group, and the second level corresponds to permitting disclosure of business information to applicants belonging to either the first group or a community group that has formed a community relationship with the first group, and prohibiting disclosure of business information to applicants not belonging to either the first group or the community group.

(e) In a matching system, a first applicant belongs to a first group, and a second applicant belongs to a second group different from the first group, and the multiple disclosure levels include a first level, a second level, and a third level, the first level corresponds to permitting disclosure of business information to the first applicant and prohibiting disclosure of business information to applicants not belonging to the first group, the second level corresponds to permitting disclosure of business information to applicants belonging to either the first group or a community group that has formed a community relationship with the first group, and the third level corresponds to permitting disclosure of business information to applicants belonging to a specific community group different from the first group and a second-level community group that has formed a community relationship with the first group, and prohibiting disclosure of business information to applicants not belonging to either the first group or the specific community group.

(f) In the matching system, the multiple disclosure levels include a disclosure level that corresponds to allowing disclosure of job information to an applicant regardless of the group to which the applicant belongs.

(g) In the matching system, attribute data capable of identifying a community group is registered in the database, and the computing device identifies applicants who are permitted to disclose their business information based on the disclosure information and the attribute data.

(h) In the matching system, the recruiter device accepts an operation to input a target group for which disclosure of business information is prohibited, and transmits information capable of identifying the accepted target group to a computing device, and the computing device prohibits disclosure of business information to applicants belonging to the target group even if the disclosure level is a level that permits disclosure of business information to the target group.

(i) In the matching system, a first applicant belongs to a first company, and a second applicant belongs to a second company different from the first company.

(j) In the matching system, the computing device receives a request from a recruiter device to search for information on multiple registrants registered in a database, and provides the recruiter device with search results based on the received request. The recruiter device receives an operation by the recruiter to select from the search results an applicant recommended by the recruiter to be recommended to apply as an applicant, and transmits identification information of the selected applicant recommended to the computing device. The computing device transmits information encouraging the applicant device of the selected applicant recommended to apply.

(k) In the matching system, a computing device registers multiple pieces of profile information for each of multiple registrants in a database, and the computing device accepts input from each of the multiple registrants to set the extent to which the multiple pieces of profile information are to be made public as search results.

(l) In the matching system, the recruiter device transmits recruitment type information to the computing device that can identify whether the job for which contractors are being recruited is a group job that can be accepted when multiple applicants apply jointly, or a job that can be accepted for an application by a single applicant, and the computing device registers the recruitment type information in the database in association with the job information.

(m) In the matching system, the computing device registers an application group consisting of multiple applicants in a database, and the computing device is capable of accepting applications from the application group regarding business information that is permitted to be disclosed to all applicants belonging to the application group.

[Aspects]
Aspects of the present disclosure are listed below.

(Section 1) The job information providing system described in Section 1 is a job information providing system that provides job information of a job to an applicant who applies for the job, and includes an applicant device operated by the applicant, and a computing device that communicates with the applicant device and can access a database in which job information is registered for each recruitment case, and the computing device estimates the labor market's evaluation of job-related abilities by type of job-related ability based on the job information included in each of a plurality of recruitment cases, and displays the estimation results on the applicant device.

(Section 2) The business information provision system described in Section 2 is the business information provision system described in Section 1, in which the database stores ability information that can identify the abilities possessed by the applicant, and the computing device identifies the abilities possessed by the applicant based on the ability information, and displays evaluation information on the applicant device that indicates the labor market's evaluation of the abilities possessed by the applicant.

(Paragraph 3) The business information provision system described in paragraph 3 is the business information provision system described in paragraphs 1 or 2, in which the computing device displays on the applicant device information indicating new skills that the applicant should acquire based on the estimation results and the skills that the applicant possesses.

(4) The business information provision system described in paragraph 4 is the business information provision system described in paragraph 3, in which the computing device displays information useful for acquiring new skills on the applicant device.

(Section 5) The job information provision system described in Section 5 is a job information provision system described in any one of Sections 1 to 4, in which the job information includes ability information regarding the abilities required of applicants and compensation information regarding compensation, and the computing device estimates the labor market's evaluation of the abilities related to the job based on the ability information and compensation information.

(Section 6) The business information provision system described in Section 6 is the business information provision system described in Section 2, in which the ability information includes the applicant's skills and the period of experience in work that uses those skills.

(Section 7) The business information provision system described in Section 7 is the business information provision system described in any one of Sections 1 to 6, in which the labor market's evaluation of business-related abilities includes either the value that the labor market places on business-related abilities or the size of the labor market in which business-related abilities are required.

(Section 8) The business information providing system described in Section 8 is the business information providing system described in any one of Sections 1 to 7, in which the business information providing system has a function of matching applicants with recruiters who are seeking contractors for a business, and the computing device registers business information and disclosure information indicating the scope of disclosure of the business information in a database, and the computing device determines, from the business information registered in the database, based on the disclosure information, which business information is permitted to be disclosed to applicants, and displays the business information permitted to be disclosed to applicants on the applicant device.

(Clause 9) The computing device described in clause 9 is a computing device that provides job information of a job to an applicant who applies for the job, and includes a communication interface that communicates with an applicant device operated by the applicant, and a processor that accesses a database in which the job information is registered, and the processor estimates the labor market's evaluation of job-related abilities by type of job-related ability based on the job information included in each of a plurality of recruitment cases, and displays the estimation results on the applicant device.

(Clause 10) The method described in clause 10 is a method for providing job information of a job to an applicant who applies for the job, and includes the steps of communicating with an applicant device operated by the applicant, accessing a database in which the job information is registered, and estimating the labor market's evaluation of job-related abilities by type of job-related ability based on the job information included in each of a plurality of recruitment cases, and displaying the estimation results on the applicant device.

The embodiments disclosed herein should be considered to be illustrative and not restrictive in all respects. The scope of the present invention is indicated by the claims, not by the description of the embodiments above, and is intended to include all modifications within the meaning and scope of the claims.

1 Matching system, 50 Internet, 100 Sharing server, 101 Processor, 102 Memory, 103 Storage, 104 Communication interface, 120 Database (DB), 121 Company database (Company DB), 122, 122A Member database (Member DB), 123 Community database (Community DB), 124, 124A Recruitment job database (Recruitment job DB), 125 Side job database (Side job DB), 126 Evaluation input database (Evaluation input DB), 126A Recruiter evaluation section, 126B Applicant evaluation section, 127 Evaluation summary database (Evaluation summary DB), 127A Recruiter evaluation summary section, 127B Applicant evaluation summary section, 128 Member group database (Member group DB), 129 Profile database (Profile DB), 134 Ability database (Ability DB), 1271, 1272 Data group, 140 Community registration unit, 141 Company registration unit, 142 Member registration unit, 143 Member search unit, 144 Case registration unit, 145 Case extraction unit, 146 Application unit, 147 Approval unit, 148 Notification unit, 149 Performance reception unit, 150 Performance output unit, 151 Evaluation reception unit, 152 Evaluation output unit, 161 Counter offer request unit, 162 Counter offer approval request unit, 163 Counter offer request acceptance notification unit, 200, 200A, 200B, 200C Recruiter device, 201 Processor, 202 Memory, 203 Communication interface, 204 Input/output interface, 205 Display, 206 Operation unit, 206A Keyboard, 206B Mouse, 207 Screen, 300, 300A, 300B, 300C Applicant device, 301 Processor, 302 Memory, 303 communication interface, 304 input/output interface, 305 display, 306 operation unit, 306A keyboard, 306B mouse, 307A to 307C tabs, 401, 402 table, 500 user device, 551 star, 552, 553 arrows.

Claims (10)

A business information providing system that provides business information of a recruitment business to an applicant who applies for the recruitment business,
an applicant device operated by the applicant;
a computing device that communicates with the applicant device and can access a database in which the business information is registered for each recruitment job;
The computing device estimates the labor market's evaluation of work-related abilities by type of work-related ability based on the work information contained in each of a plurality of recruitment requests, and displays the estimation results on the applicant device. The database has registered therein ability information that can identify the abilities possessed by the applicant,
The business information providing system of claim 1 , wherein the computing device identifies the skills possessed by the applicant based on the skill information and displays evaluation information indicating the labor market's evaluation of the skills possessed by the applicant on the applicant device. The business information providing system according to claim 1 or 2, wherein the computing device displays on the applicant device information indicating new skills that the applicant should acquire based on the estimation result and the skills that the applicant possesses. The business information providing system of claim 3, wherein the computing device displays information useful for acquiring the new skills on the applicant device. The job information includes ability information regarding abilities required of the applicant and remuneration information regarding remuneration;
The job information providing system according to claim 1 or 2, wherein the computing device estimates a labor market evaluation of the skills related to the job based on the skill information and the remuneration information. The business information providing system according to claim 2, wherein the ability information includes the applicant's skills and the period of experience in work using the skills. The business information providing system according to claim 1 or claim 2, wherein the labor market evaluation of the business-related ability includes either the value that the labor market places on the business-related ability or the size of the labor market in which the business-related ability is required. The business information providing system has a function of matching a recruiter who is recruiting contractors for a business with an applicant,
The computing device registers the business information and disclosure information indicating a disclosure range of the business information in the database;
The business information providing system of claim 1 or claim 2, wherein the computing device determines, based on the disclosure information, which business information from among the business information registered in the database is permitted to be disclosed to the applicant, and displays the business information that is permitted to be disclosed to the applicant on the applicant device. A computing device that provides job information of a job to an applicant who applies for the job,
a communications interface for communicating with an applicant device operated by the applicant;
a processor that accesses a database in which the business information is registered;
The processor is a computing device that estimates a labor market evaluation of job-related skills for each type of job-related skill based on the job information included in each of a plurality of recruitment requests, and displays the estimation results on the applicant device. A method for providing job information of a job to an applicant who applies for the job, comprising the steps of:
communicating with an applicant device operated by the applicant;
accessing a database in which the business information is registered;
and estimating a labor market evaluation of job-related abilities for each type of job-related ability based on the job information included in each of a plurality of recruitment applications, and displaying the estimation results on the applicant device.

Images