WO2019012781A1

WO2019012781A1 - Information processing device and program

Info

Publication number: WO2019012781A1
Application number: PCT/JP2018/016711
Authority: WO
Inventors: 雅裕板場
Original assignee: 板場ビジネスコンサルタンツ株式会社
Priority date: 2017-07-10
Filing date: 2018-04-25
Publication date: 2019-01-17
Also published as: JP2019016280A; JP6535863B2

Abstract

Provided is an information processing device, etc., capable of appropriately classifying and managing user-related tasks. An information processing device (1) is characterized by comprising: an acquisition unit that acquires user message information; an extraction unit that extracts task information relating to the user from the acquired message information; an identification unit that identifies a person responsible for the task and a person involved with the task from the extracted task information; a classification unit that classifies the task information as first task information in which the user is the person responsible for the task or as second task information in which the user is the person involved with the task; a registration unit that registers the classified first or second task information to a database; and an output unit that references the database and outputs the first or second task information.

Description

Information processing apparatus and program

The present invention relates to an information processing apparatus and program.

Conventionally, various management systems have been proposed as task management tools for managing user tasks. For example, in Patent Document 1, it is a workflow system in an organization such as a company, and the task for the employee is based on list data in which each task in the business is linked with an employee in charge of each task. A management system is disclosed that performs transmission of an e-mail requesting a request, task prompting, deadline management, and the like.

JP, 2016-48513, A

However, the invention according to Patent Document 1 only manages the tasks assigned to the individual users, and does not manage the tasks requested by other users.

For example, depending on the contents of a task, in order for a user to perform a task, it may be necessary to wait for the completion of a task requested by another person. Therefore, it is important not only to manage the task that the user takes charge of, but also to manage the task that another person takes charge of.

In one aspect, it is an object of the present invention to provide an information processing apparatus and the like capable of appropriately classifying and managing tasks associated with a user.

In one scheme, the information processing apparatus includes an acquisition unit that acquires user message information, an extraction unit that extracts task information related to the user from the acquired message information, and a task from the extracted task information An identification unit for identifying the person in charge and the person concerned, and a classification portion for classifying the task information into first task information in which the user is the person in charge or second task information in which the user is the person concerned And a registration unit for registering the classified first or second task information in a database, and an output unit for referring to the database and outputting the first or second task information.

In one scheme, the program obtains the user's message information, extracts task information related to the user from the obtained message information, and identifies the person in charge and the person in charge of the task from the extracted task information , The task information is classified into first task information in which the user is the person in charge or second task information in which the user is the related person, and the first or second task information classified is stored in a database The computer is caused to execute processing for registering and outputting the first or second task information with reference to the database.

In one aspect, tasks associated with the user can be appropriately classified and managed.

It is a schematic diagram which shows the structural example of a task management system. It is a block diagram showing an example of composition of a server. It is explanatory drawing which shows an example of the record layout of project DB. It is explanatory drawing which shows an example of the record layout of task DB. It is explanatory drawing which shows an example of the record layout of user DB. It is an explanatory view about an outline of task registration processing. It is an explanatory view showing an example of a task management screen. It is an explanatory view showing an example of a task management screen. It is an explanatory view about schedule adjustment processing. It is explanatory drawing which shows an example of a task performance screen. It is a flowchart which shows an example of the process sequence of a task registration process. It is a flowchart which shows an example of the process sequence of a task output process. It is explanatory drawing regarding a document production | generation process. It is a flowchart which shows an example of the process sequence of a document production | generation process. It is explanatory drawing regarding the difficulty determination process of a task. FIG. 18 is a flowchart illustrating an example of a processing procedure of task output processing according to Embodiment 3. FIG.

Hereinafter, the present invention will be described in detail based on the drawings showing the embodiments.
Embodiment 1
FIG. 1 is a schematic view showing a configuration example of a task management system. In the present embodiment, a task management system that performs task management of a project that a user works in a business will be described. The task management system includes an information processing device 1,

terminals

2, 2, 2..., A mail server 3 and a schedule server 4. The respective devices are communicably connected via a network N such as the Internet.

The information processing apparatus 1 is an information processing apparatus that performs various information processing and transmission / reception of information, and is, for example, a server apparatus, a personal computer, or the like. In the present embodiment, the information processing apparatus 1 is assumed to be a server apparatus, and hereinafter the server 1 will be read for the sake of simplicity. The server 1 stores task information related to the user, and manages the execution deadline of tasks and the like. In the present embodiment, the server 1 manages not only tasks assigned to the user, but also tasks assigned to others, such as tasks requested by the user to others, as tasks associated with the user.

The terminal 2 is a terminal device used by each user, and is, for example, a personal computer, a smartphone, a tablet terminal, or the like. The terminal 2 communicates with the server 1 and performs processing such as display and input of task information.

The mail server 3 is a server device that manages transmission and reception of mail by the user. In the present embodiment, the server 1 acquires an electronic mail (message information) transmitted and received by the user from the mail server 3, and extracts task information such as task name, task content, and operation deadline from the mail text. The server 1 registers the extracted task information in the database and performs task management.

The schedule server 4 is a server device that manages information related to the schedule of the user. As described later, the schedule server 4 transmits and receives information to and from the server 1 that performs task management, identifies schedule candidates that the user can respond to schedule adjustment requests from others, and temporarily registers the schedule. I do.

FIG. 2 is a block diagram showing a configuration example of the server 1. The server 1 includes a control unit 11, a storage unit 12, a communication unit 13, and a large-capacity storage device 14.
The control unit 11 includes an arithmetic processing unit such as a central processing unit (CPU) and a micro-processing unit (MPU), and reads and executes the program P stored in the storage unit 12 to execute various information related to the server 1. Perform processing, control processing, etc. Although FIG. 2 shows the control unit 11 as a single processor, the control unit 11 may be a multiprocessor. The storage unit 12 includes memory elements such as a random access memory (RAM) and a read only memory (ROM), and stores programs P and data necessary for the control unit 11 to execute processing. In addition, the storage unit 12 temporarily stores data necessary for the control unit 11 to execute arithmetic processing. The communication unit 13 includes a processing circuit and the like for performing processing related to communication, and transmits and receives information with the terminal 2 and the like through the network N.

The large capacity storage device 14 is a large capacity storage device including, for example, a hard disk. The large capacity storage device 14 stores a project DB 141, a task DB 142, a user DB 143, and the like. The project DB 141 stores data of each project in which the user is engaged. The task DB 142 stores information on tasks performed by the user in each project. The user DB 143 stores information of each user.

In the present embodiment, the storage unit 12 and the large capacity storage device 14 may be configured as an integrated storage device. Also, the mass storage device 14 may be configured by a plurality of storage devices. Further, the mass storage device 14 may be an external storage device connected to the server 1.
Further, in the present embodiment, the server 1 is not limited to the above configuration, and for example, an input unit that receives an operation input, a display unit that displays information related to the server 1, a reading unit that reads information stored in a portable storage medium, May be included.

FIG. 3 is an explanatory view showing an example of the record layout of the project DB 141. As shown in FIG. The project DB 141 includes a project ID column, a project name column, a customer column, and a project attribute column. The project ID column stores identification information for identifying each project. The project name column stores the name of a project. The customer column stores information (for example, a company name) of a customer who is a business partner of each project. The project attribute column stores information representing an attribute of a project, such as a product name which is a commercial material of each project, and a name of an item handled in each project.
As described above, the project DB 141 stores information of each project in the work. For example, the server 1 accepts the pre-registration of a project by the manager, and stores it in the project DB 141.

FIG. 4 is an explanatory view showing an example of the record layout of the task DB 142. As shown in FIG. The task DB 142 includes a task ID column, a task name column, a project column, a task content column, a progress column, an attached file column, a person in charge column, a related party column, a scheduled date column, a scheduled date column, a scheduled date column, a completion date Contains columns, follow-on task columns. The task ID column stores identification information for identifying individual tasks to be performed in each project. The task name column stores the names of tasks in association with task IDs. The project column stores the ID of the project related to the task in association with the task ID. The task content column stores the content of each task in association with the task ID. The progress column stores the progress of each task in association with the task ID.

The person-in-charge column stores identification information for identifying the person in charge of the task in association with the task ID. The related party column stores identification information for identifying a related party related to the task in association with the task ID. Related parties are the requester who has requested the task from the person in charge, and other related parties. Not only persons in charge of each task but also persons concerned with each task are registered in the task DB 142 together.

The scheduled start date row, the start date row, the scheduled completion date row, and the completion date row are associated with the task ID, and the scheduled task start date, launch date, completion scheduled date, and completion date are stored. The subsequent task column stores the ID of the subsequent task that follows the task in the project in association with the task ID.

FIG. 5 is an explanatory view showing an example of the record layout of the user DB 143. As shown in FIG. The user DB 143 includes a user ID column, a user name column, an affiliation column, an address column, and a scheduler account column. The user ID column stores identification information for identifying each user. The user name column stores the name of each user in association with the user ID. The affiliation column stores an affiliation destination (for example, a department name of a work place) of each user in association with the user ID. The address column stores the e-mail address used by the user in association with the user ID. The scheduler account column stores account information of the scheduler used by each user in association with the user ID.

FIG. 6 is an explanatory diagram of an overview of task registration processing. Below, the outline | summary of the process which a task management system performs is demonstrated.
The server 1 performs a process of extracting task information from message information transmitted or received by the user and registering the task information in a database. The message information is, for example, an e-mail. The server 1 synchronizes with the mail server 3 and acquires an email sent to the email address of the user and an email sent from the email address of the user.

The server 1 only needs to be able to obtain the mail sent and received by the user of the present system, and the other party of the mail does not have to be the user of the present system. For example, when the system is implemented as a task management tool in a company, the sender or destination of the mail may be an external person.

The server 1 determines whether the acquired e-mail is an e-mail related to a task request. For example, the server 1 determines whether or not a predetermined keyword such as "request" or "please" is described in the title and text of the mail.

If it is determined that the email is related to a task request, the server 1 extracts task information from the email. Specifically, the server 1 extracts information such as the task name, the contents of the task, and the execution deadline of the task. For example, the server 1 uses the title of the mail as a task name, and extracts the text of the mail as task content. Further, the server 1 extracts attribute information related to the task, such as a project name related to the task, a customer name and the like, in addition to the task execution deadline, from the mail text. The attribute information is information representing the classification of the task, and is related information associated with the task ID. The server 1 performs character recognition on the e-mail, and extracts the attribute information of the task in addition to the deadline. The server 1 further extracts the attached file of the mail. Thus, the server 1 extracts information related to the task as much as possible from the electronic mail.

The server 1 identifies the person in charge and the person in charge of the task from the extracted task information. The person in charge is a user in charge of the task. On the other hand, a related person is a user related to a task, such as a requester who has requested a task, or a member of a project that shares the result of the task. For example, the server 1 identifies the person in charge of the task and the person concerned from the header information of the e-mail such as the transmission source (From), the transmission destination (To), and the simultaneous transmission destination (Cc, Bcc). Further, for example, the server 1 may perform character recognition of the mail text, and identify the person in charge and the person concerned from the personal name included in the mail text. Thus, the server 1 identifies the person in charge and the person concerned from the header information or the text of the e-mail.

The server 1 uses the task information extracted from the mail as the first task information in which the user who is the sender / receiver of the mail is the person in charge, or the second task information in which the user is the person concerned Classify. That is, the server 1 determines whether the task described in the mail is a task to be performed by the user or a task to be performed by another user.

The server 1 registers, in the task DB 142, task information classified as first task information or second task information. For example, the server 1 issues a new task ID for the task, and stores information such as task name, task content, task execution deadline, etc. in the task DB 142 in association with the task ID. In addition, the server 1 stores the user ID of the person in charge, the user ID of the person concerned, and other attribute information in the task DB 142 in association with the task ID.

According to the above process, the server 1 separately manages the first task information that the user is in charge of and the second task information that the other users are in charge of. That is, as shown in the lower part of FIG. 6, the server 1 separately manages tasks to be output from the user to others and tasks input from others to the user. As described above, the user's own task and another's task are automatically sorted, and the convenience of task management can be enhanced.

7 and 8 are explanatory diagrams showing an example of the task management screen. The task management screen is a management screen that displays task information registered in the task DB 142 in a list. For example, when the server 1 receives a login process from the terminal 2, the server 1 generates a task management screen shown in FIG. As shown in FIG. 7, on the task management screen, a menu including a first task folder 51, a second task folder 52, and a performance tab 53 is displayed on the left side of the screen.

For example, when the terminal 2 receives an operation input to the first task folder 51, the terminal 2 displays the screen shown in FIG. FIG. 7 is a management screen of first task information assigned to the user. In the screen, task information including a task name 54, a project name 55, and an execution deadline 56 is displayed in a list.

When the terminal 2 receives an operation input to the task name 54, the terminal 2 further displays the details of the task. Specifically, as shown in FIG. 7, the terminal 2 displays the customer name, the names of persons concerned, the contents of the task (details), the attached file and the like under the task name 54. This allows the user to confirm the details of the task.

Depending on the text of the e-mail that is the source of extraction of task information, there is a possibility that required items such as task execution deadline and project name may not be described, so the server 1 uses the task management screen shown in FIG. , And accepts setting input of attribute information of each task. For example, the terminal 2 receives setting inputs such as the task name 54, the project name 55, the execution deadline 56, and the like. The server 1 stores the attribute information received via the terminal 2 in the task DB 142.

Also, the server 1 receives the setting input of the subsequent task via the terminal 2. The follow-on task is a task to be performed following the task in a series of projects. For example, the server 1 pulls down the task registered in the task DB 142 for the same project in the subsequent task column 57 of the management screen, and receives the selection by the user. The server 1 registers the task selected in the subsequent task field 57 in the task DB 142 in association with the task indicated by the task name 54.

Further, the server 1 may not only set one subsequent task manually by the user, but may simultaneously register a plurality of subsequent tasks. Specifically, the server 1 stores template information of a project in which a plurality of pieces of task information are associated, and collectively registers a plurality of pieces of task information in the task DB 142 by receiving designation of the template information.

For example, when the server 1 receives an operation input to the reference object 572 displayed as “refer to template”, the server 1 refers to the project DB 141, reads out information of a project that has been implemented in the past, and outputs it to the terminal 2. . For example, the server 1 searches the same project as the project indicated by the project name 55, such as a product name and a project name, and outputs the searched project to the terminal 2. The server 1 receives, via the terminal 2, a designation input as to whether or not the task performed in the project is to be used as a template. When the designation input to use as a template is received, the server 1 simultaneously registers the tasks of the past projects as the subsequent tasks.

Although in the above description, task information of a project implemented in the past is used, it is a matter of course that a manager may prepare a template in advance and use a template set in advance.

As described above, by receiving the setting input of the subsequent task, the server 1 links the tasks in time series, and manages a plurality of tasks as a series of projects. This allows the user to efficiently grasp task information.

The user confirms the first task information displayed on the task management screen and carries out the task. The user reports progress to the parties concerned according to the progress of the task. For example, the terminal 2 displays the report button 58 on the task management screen. When the operation input to the report button 58 is received, the terminal 2 creates a new mail (not shown). The user text-enters, in a new email, a progress report that the task is in progress, that the task has been completed, and so on. Of course, the result of the task may be attached as an attached file to the mail. The terminal 2 sends a mail of progress report to the parties concerned.

When an email related to the progress report is transmitted from the terminal 2, the server 1 acquires the email from the email server 3. The server 1 performs character recognition on the text of the mail and extracts the content of the progress report. The server 1 also extracts the attached file. The server 1 records the information related to the extracted progress report in the task DB 142 as the progress history.

As described above, the server 1 extracts the content of the progress report from the electronic mail and records the progress history. Therefore, the server 1 can extract and record progress reports even for mails sent from external users who are not users of the present system. For example, when the system is implemented as a task management tool in a company, the server 1 may acquire an email from an external person in charge such as a business consignee, and extract and record a progress report from the email. That is, the server 1 is only required to obtain the progress report from the e-mail sent to the e-mail address of the user of the system, and the transmission source of the progress report may be inside or outside the system. This can enhance the versatility of task management.

FIG. 8 is a management screen of second task information related to the user. When the operation input to the second task folder 52 is received, the terminal 2 displays a task management screen shown in FIG. In the screen, the second task information is displayed in a list, as in the management screen of the first task information shown in FIG.

On the other hand, unlike the management screen of FIG. 7, the terminal 2 also displays a status 59 indicating the progress of each task. Specifically, as shown at the right end of the screen, the status 59 such as "Done", "Not started", "In progress", etc. is displayed. The server 1 refers to the progress history recorded in the task DB 142, and outputs the status 59 on the management screen. The status (59) allows the user (person concerned) to check the progress of each task.

The terminal 2 not only displays the second task information in a list on the management screen, but also receives a selection input as to whether or not to approve the completion of the task. For example, as shown in FIG. 8, the terminal 2 displays an icon 60 for a task for which the person in charge has reported completion, and notifies the user (person concerned) that the task is completed. Furthermore, the terminal 2 communicates with the server 1 and pops up a report screen 61 indicating the content of the progress report.

The report screen 61 is a pop-up screen showing the contents of the progress report mail sent from the person in charge. The terminal 2 displays an approval button 62, a question button 63, and a sendback button 64 on the report screen 61 in addition to the mail text, the attached file, and the like. When the operation on the approval button 62 is performed, the completion of the task is approved. In this case, the terminal 2 notifies the server 1 that the task completion has been approved. The server 1 records that the task is completed in the task DB 142 as a progress history. In this case, for example, the server 1 notifies the person in charge of the subsequent task that the subsequent task should be started.

On the other hand, if the completion of the task is not approved, the server 1 sends a response to the person in charge indicating that the approval has not been obtained. For example, when the question button 63 on the report screen 61 is operated, the terminal 2 creates a new mail. The user (person concerned) inputs questions about the contents of the report in an email, and sends the questions to the person in charge. When the send back button 64 is operated, the server 1 automatically generates a fixed form mail indicating that the completion of the task has not been approved, and sends it to the person in charge. As described above, the terminal 2 receives the selection as to whether or not to approve the completion of the task on the task management screen, and notifies the person in charge if it is not approved. The server 1 records in the task DB 142 the progress history of questions by related parties, repatriation, and the like.
As described above, the server 1 can not only extract task information from e-mail, but can collectively perform processing required for task management such as transmission of an e-mail related to a progress report in a management screen. Thereby, the convenience of the user can be enhanced.

FIG. 9 is an explanatory diagram of the schedule adjustment process. In addition to task management, this system also supports coordination of the user's schedule.
Specifically, the server 1 extracts the information related to the adjustment request of the user's schedule from the e-mail transmitted and received by the user. The schedule adjustment request is, for example, a participation request for requesting the user to participate in an event such as a meeting. As shown in the upper right of FIG. 9, the server 1 determines the presence or absence of keywords such as “meeting” and “convenience” from the mail text, and determines whether or not the mail relates to the schedule adjustment request. If it is determined that the email is related to the adjustment request, the server 1 extracts information such as the location described in the email, the date and time (candidate date), and the contents of the event from the email text.

The server 1 accesses the schedule server 4 that manages the schedule of the user, and identifies schedule candidates that the user can handle. That is, the server 1 specifies schedule candidates from the scheduler. The scheduler may be managed externally (schedule server 4) or may be managed by server 1. That is, it is sufficient that the server 1 can refer to the schedule of the user. The server 1 further narrows down schedule candidates based on the date and time presented by the other party, the staying places of the user before and after, the moving means, and the like. The server 1 creates a fixed form mail that notifies the other party of the finally identified schedule candidate, and requests the mail server 3 to reply. The mail server 3 returns the mail to the other party.

In addition, the server 1 temporarily registers the schedule for the schedule candidate identified above in the scheduler. That is, the server 1 temporarily holds the schedule. The server 1 stores the location of the event, the content of the event, the name of the other party, and the like in the schedule server 4 in association with the date and time of the schedule candidate.

For example, the server 1 determines, corrects, reminds, etc., a schedule that has been temporarily registered, based on the contents of an e-mail to be sent back from the other party. For example, when an e-mail having a fixed date is obtained from the mail server 3, the server 1 extracts the date and time fixed from the e-mail, and transfers the extracted date to the schedule server 4. The schedule server 4 performs fixed registration of the schedule at the relevant date and time, deletion of the schedule temporarily registered on the other candidate dates, and the like. As described above, the server 1 not only extracts task information from the e-mail, but also extracts schedule information of the user, thereby providing support for schedule management.

FIG. 10 is an explanatory view showing an example of the task result screen. The server 1 generates, from the progress history of tasks recorded in the task DB 142, result information representing the implementation efficiency of each task and outputs the result information to the terminal 2.
The track record information is information that can be an evaluation index of the track record of tasks, such as task man-hours and required time (so-called lead time). For example, the server 1 refers to the task DB 142, and reads information such as the required time for each task in each project and the number of persons in charge. The server 1 calculates the man-hours for the entire project, the lead time, the man-hours for each task, and the like based on the above information.

For example, when the terminal 2 receives an operation input to the results tab 53, the terminal 2 displays a task results screen shown in FIG. The said screen is a screen which displays the performance information of a project. For example, the terminal 2 receives a specification input of a project on the project tab 65. The terminal 2 requests the server 1 to output performance information for the project selected on the project tab 65. The server 1 outputs the requested project performance information to the terminal 2.

The terminal 2 displays the task implementation efficiency calculated by the server 1 on the task result screen. For example, the terminal 2 displays the man-hours and lead time of the entire project at the top of the screen. Further, the terminal 2 displays the task-based man-hours in a Gantt chart format. As a result, the user can check the performance of the task, and work can be made more efficient.

In addition, although the task man-hour and lead time are mentioned as an example in the above, the server 1 is not limited to this, for example, the number of send back tasks, response time from completion of task to start of subsequent task, etc. The evaluation index may be calculated as performance information.

In addition, the server 1 may perform, for example, prediction of man-hours of tasks not yet started, prediction of lead time, and the like, based on the track record information of tasks performed in the past. This makes it possible to support the user's work more positively.

FIG. 11 is a flowchart illustrating an example of a processing procedure of task registration processing. The processing content of the task registration processing executed by the server 1 will be described based on FIG.
For example, the control unit 11 of the server 1 performs the following processing by the badge processing. The control unit 11 acquires message information of the user (step S11). Specifically, the server 1 accesses the mail server 3 to obtain an e-mail sent from the user or sent to the user. The control unit 11 determines whether the acquired message information is message information related to a new task request (step S12). For example, the control unit 11 performs character recognition of the mail title and text, and determines whether a predetermined keyword used at the time of a task request is included.

If it is determined that the message information relates to the task request (S12: YES), the control unit 11 extracts task information from the message information (step S13). For example, the control unit 11 extracts task information with the title of the email as the task name and the email text as the task content. Further, the control unit 11 performs character recognition on the mail text, and extracts attribute information such as a project name, a customer name, etc. besides the task execution deadline.

The control unit 11 identifies the person in charge and the person in charge of the task from the extracted task information (step S14). The person in charge is a user in charge of performing the task. Related parties are the requester who has requested the task to the person in charge, and other users. For example, the control unit 11 identifies the person in charge of the task and the person concerned from the header information such as the transmission source and the transmission destination of the mail or the personal name included in the mail text.

The control unit 11 classifies the task information extracted in step S13 into first task information in which the user is a person in charge or second task information in which the user is a person in charge based on the identification result in step S14 (step S15). ). That is, the server 1 classifies the task extracted from the user's mail into a task for which the user is in charge and a task for which another user is in charge. The control unit 11 registers the classified first or second task information in the task DB 142 (step S16). For example, in association with the task ID, the control unit 11 stores the user ID of the person in charge, the user ID of the person concerned, and other attribute information in addition to the task name, the task content, and the execution deadline in the task DB 142. The control unit 11 ends the series of processes.

When it is determined that the message information is not the message information related to the new task request (S12: NO), the control unit 11 determines whether the message information is the progress report of the existing task (Step S17). When it is determined that it is a progress report (S17: YES), the control unit 11 extracts the content of the progress report from the message information (step S18). The control unit 11 records the content of the extracted progress report as the progress history in the task DB 142 (step S19), and ends the series of processes.

If it is determined that the message is not a progress report (S17: NO), the control unit 11 determines whether the message information is a message related to the adjustment request of the schedule of the user (Step S20). If it is determined that the request is not a schedule adjustment request (S20: NO), the control unit 11 ends the series of processes. If it is determined that the request is a schedule adjustment request (S20: YES), the control unit 11 extracts information related to the schedule adjustment request from the message information (step S21). For example, the control unit 11 extracts information such as the location of an event described in the mail, the date and time, and the content of the event.

The control unit 11 refers to the scheduler managed by the schedule server 4 and specifies schedule candidates that can be handled by the user (step S22). The control unit 11 generates a reply message notifying the other party of the identified schedule candidate, and sends a reply message via the mail server 3 (step S23). Furthermore, the control unit 11 temporarily registers the schedule in the schedule candidate specified in step S22 with the scheduler managed by the schedule server 4 (step S24). The control unit 11 ends the series of processes.

FIG. 12 is a flowchart illustrating an example of a processing procedure of task output processing. The processing content of the task output processing executed by the server 1 will be described based on FIG.
For example, when the login process from the terminal 2 is accepted, the control unit 11 of the server 1 executes the following process. Based on the output request from the terminal 2, the control unit 11 determines whether or not to output first task information of which the logged-in user is a person in charge (step S41). When it is determined that the first task information is to be output (S41: YES), the control unit 11 refers to the task DB 142 and outputs to the terminal 2 a task management screen showing a list of first task information for which the user is the person in charge (Step S42). The control unit 11 receives an input of setting of attribute information of an existing task, an input of setting of a subsequent task, an input of progress report, and the like on the task management screen (step S43). The control unit 11 stores the input content in the task DB 142.

The control unit 11 determines whether a progress report has been received in step S43 (step S44). When it is determined that the progress report has not been received (S44: NO), the control unit 11 shifts the processing to step S56. When it is determined that the progress report has been received (S44: YES), the control unit 11 generates message information related to the progress report, and outputs the message information to the person concerned (step S45). The control unit 11 shifts the processing to step S56.

When it is determined that the first task information is not output (S41: NO), the control unit 11 determines whether or not the user outputs the second task information that is a related person (step S46). When it is determined to output the second task information (S46: YES), the control unit 11 outputs, to the terminal 2, a task management screen showing a list of second task information in which the user is a related person (step S47).

The control unit 11 refers to the task DB 142, and determines whether there is second task information for which a person in charge has made a progress report (step S48). When it is determined that there is no second task information for which the progress report has been made (S48: NO), the control unit 11 shifts the processing to step S56. When it is determined that there is the second task information for which the progress report has been made (S48: YES), the control unit 11 outputs the message information related to the progress report transmitted from the person in charge to the terminal 2 (step S49). For example, the control unit 11 generates a report screen 61 indicating the content of the progress report, and outputs the report screen 61 to the terminal 2. The report screen 61 is a pop-up screen showing the mail contents of the progress report sent from the person in charge, and an approval button 62 for selecting whether the user (person concerned) approves the completion of the task or a sendback button 64 Etc.

The control unit 11 determines whether or not the selection input for approving the completion of the task has been received in response to the progress report output in step S49 (step S50). If it is determined that the task has been approved (S50: YES), the control unit 11 records, in the task DB 142, a progress history indicating that the task has been completed (Step S51). The control unit 11 shifts the processing to step S56.

When it is determined that the completion of the task has not been approved (S50: NO), the control unit 11 notifies the person in charge of the task (Step S52). The content of the notification is, for example, repatriation of a task, a question regarding the content of the report, or the like. The server 1 notifies the person in charge in accordance with the input content input by the person concerned. Further, in this case, the server 1 records the notification contents such as the task return and the question in the task DB 142 as the progress history. The control unit 11 shifts the processing to step S56.

If it is determined that the second task information is not to be output (S46: NO), the control unit 11 determines whether to output task performance information (step S53). The record information is information representing task execution efficiency, and is information such as task man-hours and lead times. When it is determined that the performance information is not output (S53: NO), the control unit 11 shifts the processing to step S56. When it is determined that the performance information is to be output (S53: YES), the control unit 11 refers to the progress history of each task stored in the task DB 142, and implements efficiency such as task man-hours and required time (lead time). Calculate (step S54). The control unit 11 generates a task performance screen that displays the calculated efficiency, such as man-hours and lead times, and outputs the task performance screen to the terminal 2 (step S55). The control unit 11 shifts the processing to step S56.

The control unit 11 determines whether a logout request has been received from the terminal 2 (step S56). If it is determined that the user does not log out (S56: NO), the control unit 11 returns the process to step S41. When it is determined that the user is to log out (S56: YES), the control unit 11 ends the series of processes.

Although the server 1 extracts the task information from the e-mail transmitted and received at the user's e-mail address, the present embodiment is not limited to this. For example, the server 1 may read a message in a chat group to which the user belongs and extract task information. As described above, the server 1 only needs to be able to extract task information from message information transmitted and received by the user, and the extraction source of the task information is not limited to electronic mail.

In addition, when task information is not described in the e-mail sent to the user's e-mail address and information on the schedule is not described either, the e-mail has a formal content such as simple confirmation, thank you etc. Probability is high. Therefore, for example, when the description regarding the task and the schedule is not recognized from the electronic mail (step S20: NO), the server 1 may automatically reply the fixed message. Thereby, the convenience of the user can be enhanced.

Also, for example, the server 1 may of course perform reminding, prompting, and the like to the person in charge.

As described above, according to the first embodiment, it is possible to appropriately classify and manage tasks related to the user.

Moreover, according to the first embodiment, efficient task management can be supported by mediating transmission and reception of progress reports.

Further, according to the first embodiment, it is possible to manage task performance such as task man-hours and lead times.

Further, according to the first embodiment, it is possible to perform task management without omission by using template information of a project in which a plurality of tasks are associated.

Further, according to the first embodiment, not only the task management but also the schedule management can be provided.

Second Embodiment
In the present embodiment, an embodiment will be described in which a user creates a document to be used in a conference based on task information managed by the server 1. The same reference numerals as in the first embodiment denote the same parts as in the first embodiment, and a description thereof will be omitted.
FIG. 13 is an explanatory diagram of document generation processing. In the present embodiment, the server 1 creates an agenda which the user uses in a conference, and minutes in which the content of the conference is recorded.

Specifically, the server 1 receives, from the terminal 2, the selection of the task related to the agenda of the conference among the plurality of tasks registered in the task DB 142. For example, as shown in the upper right of FIG. 13, the server 1 displays a list of tasks of a project on the terminal 2, and accepts selection of one or more tasks in the form of a check box.

For example, the server 1 searches the task DB 142 for tasks having attributes specified by the user, and displays a list on the terminal 2. As mentioned above, the attribute of the task is information indicating the classification of the task, such as the name of the person in charge, the name of the person concerned, the name of the project, the name of the customer, the attribute of the project It is related information linked to an ID. As described in the first embodiment, the server 1 recognizes the contents of the e-mail, or receives the setting input through the task management screen, thereby using the above various information as the task attribute information as the task DB 142. Remember.

For example, the server 1 receives specification of attribute information via the terminal 2, searches for tasks of the specified attribute, and displays a list on the terminal 2. For example, when the specification of the project name “project A” is received, the server 1 searches the task DB 142 for a task group having the attribute “project A”. Then, as illustrated in FIG. 13, the server 1 displays a list of the searched task groups on the terminal 2.

The server 1 receives the selection of the task to be used for the agenda of the conference from the plurality of tasks listed and displayed on the terminal 2. The server 1 generates a document file including the agenda items of the conference and the input fields corresponding to the respective items based on the task information related to the selected task. For example, the server 1 sets a task name of each task as an item name, and generates a document file in which a text input field corresponding to each item is inserted. Thus, the server 1 creates a document corresponding to the meeting agenda.

The server 1 outputs the generated document file to the terminal 2. At the time of a meeting, the user operates the terminal 2 to input text in each input field. Specifically, the user inputs the contents of proceedings such as the remarks in the meeting, the decision matters, and the newly raised issues.

After the meeting, the server 1 stores the document file in which the content of the proceedings is input as the minutes in accordance with the operation from the terminal 2. For example, the server 1 stores the document file as an attached file associated with the task in the task DB 142.

Further, the server 1 updates the task DB 142 in accordance with the input content to the document file. For example, the server 1 refers to the text data input in the input field of each agenda item, and determines whether the completion of the corresponding task has been approved. The server 1 updates the progress history of the task according to the determination result, and records the completion of the task. Also, for example, the server 1 registers, in the task DB 142, a new task input to the document file as new task information.
As described above, the server 1 creates the agenda and the minutes based on the task information, and updates the task DB 142 based on the contents of the proceedings. As a result, the server 1 can not only manage task information but also perform business support based on the task information.

FIG. 14 is a flowchart of an example of the document generation process. The processing content of the document generation processing executed by the server 1 will be described based on FIG.
The control unit 11 of the server 1 receives specification of task attribute information via the terminal 2 (step S201). The attribute information is information extracted from the message information or input by the user, and is information representing the classification of the task. The task DB 142 stores task attribute information in association with the task ID. The control unit 11 searches the task DB 142 for a plurality of pieces of task information based on the designated attribute information (step S202).

The control unit 11 outputs the plurality of searched task information to the terminal 2 (step S203). Then, the control unit 11 receives a selection input for selecting one or more pieces of task information among the plurality of pieces of output task information (step S204). Based on the selected task information, the control unit 11 generates a document file including an agenda item and an input field corresponding to the agenda item, and outputs the document file to the terminal 2 (step S205). As described above, the document file is a document corresponding to the agenda. For example, the control unit 11 sets a task name as an agenda item, inserts a text input field corresponding to each item into a document file, and generates an agenda.

The control unit 11 receives information input to the generated document file (step S206). For example, the control unit 11 receives text input to a document file via the terminal 2. The control unit 11 stores the document file in which the text or the like is input by the user as the minutes (step S207).

The control unit 11 updates the task DB 142 according to the input content to the document file (step S208). For example, the control unit 11 updates the progress history of the existing task, registers the new task, and the like from the text data input to the document file. The control unit 11 ends the series of processes.

Although the case where the task search function based on attribute information is used at the time of creating an agenda has been described above, the use of the search function is not limited to when creating an agenda, for example, at other times Of course, it may be searchable in the scene. That is, the server 1 only needs to simultaneously output a plurality of pieces of task information using the task attribute as a search key.

As described above, according to the second embodiment, further efficient work can be supported by creating a document based on task information.

Third Embodiment
In this embodiment, the difference between the degree of difficulty of the task recognized by the person in charge and the degree of difficulty of the task recognized by the person concerned is eliminated, and a mode for determining a representative value of the degree of difficulty of the task will be described.
FIG. 15 is an explanatory diagram of task difficulty determination processing. FIG. 15 illustrates a conceptual explanatory view of the processing content executed by the server 1 in the present embodiment.

When a related party requests a task from a person in charge, there may be a difference in recognition between the person in charge and the person in charge regarding the degree of difficulty of the task. For example, as shown in FIG. 15, the degree of difficulty may be low when viewed from a person who requests a task, but may be high when viewed by a person who actually performs the task. Therefore, in the present embodiment, the setting input of the degree of difficulty is received from both the person in charge and the person in charge, the set value of the degree of difficulty is statistically processed, converted to a general degree of difficulty, and presented to the user Do.

For example, in the task management screen illustrated in FIG. 7 and FIG. 8 etc., the server 1 receives the setting input of the degree of difficulty of the task in numerical values of 1 to 5 levels. The server 1 stores the difficulty level of the input task in the task DB 142. The server 1 receives the setting input of the degree of difficulty from both the person in charge and the related person for each task, and stores the input in the task DB 142.

The server 1 reads, from the task DB 142, the setting values of the degree of difficulty of the person in charge and the person of interest for tasks having the same content (for example, tasks having similar task names). The server 1 performs statistical processing on the read setting values of the difficulty level of the person in charge and the related person. For example, the server 1 assumes that the distribution of the degree of difficulty set by the persons in charge and the distribution of the degree of difficulty set by the parties follow the normal distribution, and follows the bimodal distribution in which two normal distributions are superimposed as a whole. Perform statistical processing assuming that The server 1 calculates the average value, the variance, and the like for each of the set values of the degree of difficulty on the person in charge side and the set values of the degree of difficulty on the person concerned side, and derives an approximate curve related to the normal distribution.

The server 1 determines the representative value of the degree of difficulty of the task from the analysis result by the statistical processing. For example, the server 1 determines the degree of difficulty located at the intersection of each normal distribution as a representative value of the degree of difficulty of the task. That is, the server 1 determines the position corresponding to the valley of the bimodal distribution as the representative value in the distribution diagram shown in FIG. For example, the server 1 presents the representative value of the determined difficulty level to the user as the general difficulty level of the task on the task performance screen illustrated in FIG. The user can perform task task estimation and the like with reference to the presented difficulty level.

Note that the method of determining the representative value of the difficulty level described above is an example, and the present embodiment is not limited to this. For example, the server 1 may use, as a representative value, the median value, the average value, and the like of the difficulty levels set by the person in charge and the person concerned.

FIG. 16 is a flowchart of an example of the task output process according to the third embodiment. The processing contents of the server 1 according to the present embodiment will be described based on FIG.
After outputting the first task information to the terminal 2 (step S42), the control unit 11 of the server 1 receives the setting input of the degree of difficulty of the first task information by the person in charge of the task and stores it in the task DB 142 (step S42) S301). For example, the control unit 11 receives the setting input of the degree of difficulty of each task in the five-step evaluation. The control unit 11 stores the setting value of the difficulty level set by the person in charge in the task DB 142. The control unit 11 shifts the processing to step S43.

After outputting the second task information to the terminal 2 (step S47), the control unit 11 receives the setting input of the degree of difficulty of the second task information by the person concerned with the task, and stores it in the task DB 142 (step S302). For example, as in step S301, the control unit 11 receives the setting input of the degree of difficulty of each task in the five-step evaluation. The control unit 11 stores in the task DB 142 the setting value of the degree of difficulty set by the person concerned. The control unit 11 shifts the processing to step S48.

After executing the process of step S54, the control unit 11 refers to the task DB 142 and determines the representative value of the task difficulty level from the setting values of the difficulty levels set by both the person in charge and the person concerned (step S303) . For example, the control unit 11 performs statistical processing on the assumption that the set value of the person in charge and the set values of the related persons both follow a normal distribution, and that the whole follows a bimodal distribution, and determines the representative value of the difficulty level Do. The control unit 11 generates a task performance screen including the representative value of the determined difficulty level, and outputs it to the terminal 2 (step S304). The control unit 11 shifts the processing to step S56.

As described above, according to the third embodiment, by defining the representative value of the task difficulty level, it is possible to help to eliminate the difference in recognition between the person in charge and the person concerned, and to predict the number of tasks of the task.

It should be understood that the embodiments disclosed herein are illustrative in all respects and not restrictive. The scope of the present invention is indicated not by the meaning described above but by the scope of the claims, and it is intended to include all the modifications within the meaning and scope equivalent to the scope of the claims.

1 Server (Information Processing Device)
11 control unit 12 storage unit P program 13 communication unit 14 large capacity storage device 141 project DB
142 Task DB
143 User DB
2 terminal 3 mail server 4 schedule server

Claims

An acquisition unit for acquiring user's message information;
An extraction unit that extracts task information related to the user from the acquired message information;
An identification unit for identifying a person in charge and a person in charge of the task from the extracted task information;
A classification unit that classifies the task information into first task information in which the user is the person in charge or second task information in which the user is the person concerned;
A registration unit that registers the classified first or second task information in a database;
An output unit that outputs the first or second task information with reference to the database.
A second acquisition unit that acquires a progress report of the task;
When the progress report is acquired, the output unit outputs the progress report to the relevant party,
An approval receiving unit that receives a selection as to whether the completion of the task is to be approved for the output progress report;
The information processing apparatus according to claim 1, further comprising: a notification unit that notifies the person in charge if the completion of the task is not approved.
A recording unit that records the progress history of the task based on the progress report;
The information processing apparatus according to claim 2, further comprising: a calculation unit that calculates the implementation efficiency of the task with reference to the progress history.
A storage unit storing template information in which a plurality of pieces of task information are associated;
The information processing apparatus according to any one of claims 1 to 3, wherein the registration unit registers the plurality of pieces of task information by receiving designation of the template information.
The extraction unit further extracts, from the message information, information related to an adjustment request of the schedule of the user,
An identifying unit that identifies schedule candidates that can be handled by the user with reference to a scheduler that manages the schedule of the user;
5. The information processing apparatus according to any one of claims 1 to 4, further comprising: a second registration unit that temporarily registers the schedule in the identified schedule candidate in the scheduler.
A search unit configured to search a plurality of pieces of task information from the database based on the attribute information of the task;
The information processing apparatus according to any one of claims 1 to 5, wherein the output unit outputs the plurality of searched task information.
A task selection unit that receives a selection of the task information registered in the database;
A document generation unit configured to generate a document file including an agenda item and an input field corresponding to the agenda item based on the selected task information;
The output unit outputs the document file,
The information processing apparatus according to any one of claims 1 to 6, further comprising an update unit configured to update the database according to the input content to the document file that has been output.
A difficulty level accepting unit that accepts setting input of the degree of difficulty of the task from both the person in charge and the person concerned;
A difficulty level storage unit that stores the accepted setting value of the difficulty level;
The information processing apparatus according to any one of claims 1 to 7, further comprising: a determination unit which refers to the difficulty level storage unit and determines a representative value of the difficulty level of the task.
The message information is an e-mail sent from the user or sent to the user,
The information processing apparatus according to any one of claims 1 to 8, wherein the identification unit identifies the person in charge and the person concerned from header information or text of the electronic mail.
Get user's message information,
Task information related to the user is extracted from the acquired message information;
Identify the person in charge and the person in charge of the task from the extracted task information;
The task information is classified into first task information in which the user is the person in charge or second task information in which the user is the person concerned;
Registering the classified first or second task information in a database;
A program that causes a computer to execute a process of outputting the first or second task information with reference to the database.