JP2019016280A - Information processing device and program - Google Patents

Abstract

To provide an information processing device and the like capable of appropriately classifying and managing user-related tasks.SOLUTION: An information processing device 1 comprises: an acquisition unit which acquires message information of a user; an extraction unit which extracts task information related to the user from the acquired message information; an identification unit which identifies a person in charge of the task and a person involved in the task from the extracted task information; a classification unit which classifies the task information into first task information in which the user is the person in charge of the task and second task information in which the user is the person involved in the task; a registration unit which registers the classified first or second task information in a database; and an output unit which refers to the database and outputs the first or second task information.SELECTED DRAWING: Figure 1

Description

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

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

JP 2016-48513 A

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

  For example, depending on the contents of a task, in order to perform a certain task, the user may have to wait for the task requested by another person to be completed. Therefore, it is important not only to manage the tasks handled by the user, but also to manage the tasks handled by other people.

  An object of one aspect is to provide an information processing apparatus and the like that can appropriately classify and manage tasks related to a user.

  In one proposal, the information processing apparatus includes: an acquisition unit that acquires message information of a user; an extraction unit that extracts task information related to the user from the acquired message information; and a task from the extracted task information. A classifying 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 in charge. A registration unit that registers the classified first or second task information in a database, and an output unit that outputs the first or second task information with reference to the database.

  In one plan, the program acquires user message information, extracts task information related to the user from the acquired message information, and identifies a person in charge of the task and related parties from the extracted task information. Then, 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, and the classified first or second task information is stored in a database. Registering and referring to the database, causing the computer to execute a process of outputting the first or second task information.

  In one aspect, tasks related to 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 which shows the structural example 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 explanatory drawing regarding the outline | summary of a task registration process. It is explanatory drawing which shows an example of a task management screen. It is explanatory drawing which shows an example of a task management screen. It is explanatory drawing regarding a schedule adjustment process. 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. 10 is a flowchart illustrating an example of a processing procedure of task output processing according to the third embodiment.

Hereinafter, the present invention will be described in detail with reference to the drawings illustrating embodiments thereof.
(Embodiment 1)
FIG. 1 is a schematic diagram illustrating a configuration example of a task management system. In the present embodiment, a task management system that performs task management of a project with which a user is engaged in 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. Each device is connected for communication via a network N such as the Internet.

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

  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 displaying and inputting task information.

  The mail server 3 is a server device that manages mail transmission / reception by the user. In the present embodiment, the server 1 acquires e-mail (message information) sent and received by the user from the mail server 3 and extracts task information such as task name, task content, and execution 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 a user's schedule. As will be described later, the schedule server 4 transmits / receives information to / from the server 1 that performs task management, specifies a schedule candidate that the user can respond to a schedule adjustment request from another person, and temporarily registers the schedule I do.

FIG. 2 is a block diagram illustrating 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 mass storage device 14.
The control unit 11 includes an arithmetic processing unit such as a CPU (Central Processing Unit) and an MPU (Micro-Processing Unit), and reads and executes the program P stored in the storage unit 12 to thereby execute various information related to the server 1. Processing, control processing, etc. are performed. In FIG. 2, the control unit 11 is illustrated as a single processor, but the control unit 11 may be a multiprocessor. The storage unit 12 includes memory elements such as RAM (Random Access Memory) and ROM (Read Only Memory), and stores a program P and data necessary for the control unit 11 to execute processing. 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 for performing processing related to communication, and transmits and receives information to and from the terminal 2 and the like via 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 that the user is engaged in. The task DB 142 stores information on tasks performed by the user in each project. The user DB 143 stores information on each user.

In the present embodiment, the storage unit 12 and the mass storage device 14 may be configured as an integrated storage device. Further, the mass storage device 14 may be constituted by a plurality of storage devices. The mass storage device 14 may be an external storage device connected to the server 1.
In the present embodiment, the server 1 is not limited to the above configuration. 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, and the like May be included.

FIG. 3 is an explanatory diagram showing an example of the record layout of the project DB 141. 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 the project. The customer column stores information (for example, corporate name) of customers who are business partners of each project. The project attribute column stores information representing project attributes, such as product names that are the materials of each project, and project names handled by each project.
As described above, the project DB 141 stores information on each project in the business. For example, the server 1 accepts a project pre-registration by an administrator and stores it in the project DB 141.

  FIG. 4 is an explanatory diagram showing an example of the record layout of the task DB 142. The task DB 142 includes a task ID column, a task name column, a project column, a task content column, a progress column, an attachment file column, a person-in-charge column, a related party column, a scheduled start date column, a scheduled start date column, a scheduled completion date column, and a completed date. Column, followed by task column. The task ID column stores identification information for identifying individual tasks executed in each project. The task name column stores the name of the task in association with the task ID. 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 person column stores identification information for identifying a related person related to the task in association with the task ID. The related person is a requester who requested a task from the person in charge, or other related persons. In the task DB 142, not only the person in charge of each task but also the persons related to each task are registered.

  The scheduled start date string, the scheduled start date string, the scheduled completion date string, and the completed date string each store a scheduled task start date, a scheduled start date, a scheduled completion date, and a completed date in association with the task ID. The subsequent task column stores the ID of the subsequent task following the task in the project in association with the task ID.

  FIG. 5 is an explanatory diagram 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 the affiliation of each user (for example, the department name of the work) in association with the user ID. The address column stores the mail address used by the user in association with the user ID. The scheduler account column stores scheduler account information used by each user in association with the user ID.

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

  The server 1 only needs to be able to acquire emails sent and received by users of this system, and the other party of the emails does not need to be a user of this system. For example, when the present system is implemented as an in-house task management tool, the mail source or destination may be a person outside the company.

  The server 1 determines whether the acquired mail is a mail related to the task request. For example, the server 1 determines whether or not a predetermined keyword used when requesting a task, such as “request” or “please”, is described in the title and body 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 a task name, task contents, and task execution deadline. For example, the server 1 extracts the mail title as the task name and the mail text as the task content. Further, the server 1 extracts attribute information related to the task such as a project name and a customer name related to the task, in addition to the task execution deadline, from the mail body. 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 task attribute information in addition to the execution deadline. The server 1 further extracts the attached file of the mail. In this way, the server 1 extracts information related to the task from the electronic mail as much as possible.

  The server 1 identifies the person in charge of the task and the related person from the extracted task information. The person in charge is a user in charge of the task. On the other hand, the related person is a user related to the task, such as a requester who requested the task or a member of a project sharing the result of the task. For example, the server 1 identifies the person in charge of the task and related parties from the header information of the electronic 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 related person 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 electronic mail.

  Based on the identification result, the server 1 converts the task information extracted from the mail into the first task information in which the user who is the transmission / reception source 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 that the user himself / herself should perform or a task that other users should perform.

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

  Through the above processing, the server 1 separately manages the first task information handled by the user and the second task information handled by another user. 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 users. As described above, the task of the user himself / herself and the task of another person are automatically sorted, and the convenience of task management can be improved.

  7 and 8 are explanatory diagrams illustrating an example of a task management screen. The task management screen is a management screen showing a list of task information registered in the task DB 142. For example, when the server 1 accepts the login process from the terminal 2, the server 1 generates a task management screen shown in FIG. As shown in FIG. 7, the task management screen displays a menu including a first task folder 51, a second task folder 52, and a performance tab 53 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 for the first task information handled by the user. On this screen, task information including a task name 54, a project name 55, and an execution deadline 56 is displayed as a list.

  When the terminal 2 accepts an operation input to the task name 54, the terminal 2 further displays the details of the task. Specifically, as illustrated in FIG. 7, the terminal 2 displays a customer name, a related party name, task contents (details), an attached file, and the like under the task name 54. Thereby, the user can confirm the details of the task.

  Depending on the text of the email from which the task information is extracted, for example, necessary items such as the task execution deadline and project name may not be described. Therefore, the server 1 displays the task management screen shown in FIG. The setting input of the attribute information of each task is accepted. For example, the terminal 2 accepts setting inputs such as a task name 54, a project name 55, an implementation deadline 56, and the like. The server 1 stores the attribute information received via the terminal 2 in the task DB 142.

  In addition, the server 1 receives a setting input for subsequent tasks via the terminal 2. Subsequent tasks are tasks that should be performed following the task in a series of projects. For example, the server 1 pulls down tasks registered in the task DB 142 for the same project in the subsequent task column 57 of the management screen, and accepts selection by the user. The server 1 registers the task selected in the subsequent task column 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 each subsequent task manually by the user but also be able to register a plurality of subsequent tasks all at once. Specifically, the server 1 stores project template information associated with a plurality of task information, and accepts the designation of the template information to register the plurality of task information in the task DB 142 simultaneously.

  For example, when the server 1 receives an operation input to the reference object 572 displayed as “reference template”, the server 1 refers to the project DB 141, reads information on a project that has been executed in the past, and outputs the information to the terminal 2. . For example, the server 1 searches for a project whose project attributes such as a product name and a project name are the same as the project indicated by the project name 55, and outputs the searched project to the terminal 2. The server 1 receives a designation input as to whether or not to use a task executed in the project as a template via the terminal 2. When receiving a designation input for use as a template, the server 1 simultaneously registers tasks of past projects as subsequent tasks.

  In the above description, task information of a project executed in the past is used. However, it is a matter of course that a template may be prepared in advance by the administrator and a preset template may be used.

  As described above, the server 1 receives the setting input of the subsequent task, thereby linking the tasks in time series, and manages a plurality of tasks as a series of projects. Thereby, the user can grasp task information efficiently.

  The user confirms the first task information displayed on the task management screen and executes the task. The user reports a progress report to related parties according to the progress of the task. For example, the terminal 2 displays a 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 enters a progress report indicating that the task is in progress and the task is completed in a new mail. Needless to say, the result of the task may be attached to the mail as an attached file. The terminal 2 transmits a progress report mail to the parties concerned.

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

  As described above, the server 1 extracts the contents of the progress report from the electronic mail and records the progress history. Therefore, the server 1 can extract and record a progress report even for an email transmitted from an external user who is not a user of this system. For example, when this system is implemented as an in-house task management tool, the server 1 may acquire an email from a person in charge outside the company such as a business consignee, and extract and record a progress report from the email. That is, the server 1 only needs to be able to acquire a progress report from an e-mail transmitted to the user's e-mail address of this system, and the source of the progress report may be inside or outside the system. Thereby, the versatility of task management can be improved.

  FIG. 8 is a management screen for second task information related to the user. When receiving an operation input to the second task folder 52, the terminal 2 displays a task management screen shown in FIG. On this screen, the second task information is displayed in a list in the same manner as the first task information management screen 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, a status 59 such as “completed”, “not yet started”, “in progress” 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 user (related person) can check the progress status of each task based on the status 59.

  The terminal 2 not only displays a list of the second task information on the management screen, but also accepts a selection input as to whether or not to approve completion of the task. For example, as illustrated in FIG. 8, the terminal 2 displays an icon 60 for a task that has been reported to be completed by the person in charge, and notifies the user (related party) that the task has been completed. Further, the terminal 2 communicates with the server 1 and pops up a report screen 61 showing the contents of the progress report.

  The report screen 61 is a pop-up screen showing the mail content of the progress report transmitted from the person in charge. The terminal 2 displays an approval button 62, a question button 63, and a return button 64 on the report screen 61 in addition to the mail text and attached file. 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 the completion of the task 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, when the completion of the task is not approved, the server 1 sends a reply to the person in charge 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. A user (related person) inputs a question about a report content in an e-mail and replies to a person in charge to ask a question. When the return button 64 is operated, the server 1 automatically generates a standard mail indicating that the completion of the task has not been approved and returns it to the person in charge. In this way, the terminal 2 accepts the selection of whether or not to approve the completion of the task on the task management screen, and notifies the person in charge when it is not approved. Note that the server 1 records a progress history such as questions and return by related parties in the task DB 142.
As described above, the server 1 can not only extract task information from an e-mail but also perform processes necessary for task management such as transmission of an e-mail related to a progress report in a batch on the management screen. Thereby, a user's convenience can be improved.

FIG. 9 is an explanatory diagram regarding schedule adjustment processing. This system not only performs task management, but also supports user schedule adjustment.
Specifically, the server 1 extracts information related to the user's schedule adjustment request from the emails sent and received by the user. The schedule adjustment request is 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 / absence of keywords such as “meeting” and “convenient” from the mail text, and determines whether the mail is related to a schedule adjustment request. If it is determined that the mail is related to the adjustment request, the server 1 extracts information such as the location, date / time (candidate date), and event content described in the mail from the mail text.

  The server 1 accesses the schedule server 4 that manages the user's schedule, 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 the server 1. That is, it is only necessary that the server 1 can refer to the user's schedule. The server 1 further narrows down schedule candidates from the date and time presented by the other party, the staying places of the users before and after, the moving means, and the like. The server 1 creates a standard mail for notifying the opponent of the finally specified schedule candidate and requests the mail server 3 to reply. The mail server 3 returns the mail to the other party.

  The server 1 provisionally registers the schedule for the schedule candidate specified above in the scheduler. That is, the server 1 temporarily holds the schedule. The server 1 stores the event location, the event content, the name of the opponent, and the like in the schedule server 4 in association with the date and time of the schedule candidate.

  For example, the server 1 confirms, modifies, and reminds the schedule for the temporarily registered schedule based on the contents of the mail that will be returned later from the other party. For example, when a fixed date mail is acquired from the mail server 3, the server 1 extracts the fixed date and time from the mail and transfers it to the schedule server 4. The schedule server 4 performs final registration of the schedule at the date and time, deletion of the schedule temporarily registered on other date candidates, and the like. In this way, the server 1 not only extracts task information from the e-mail, but also supports schedule management by extracting information related to the user's schedule.

FIG. 10 is an explanatory diagram illustrating an example of a task performance screen. The server 1 generates performance information representing the execution efficiency of each task from the task progress history recorded in the task DB 142 and outputs it to the terminal 2.
The track record information is information that can be an evaluation index of the track record of the task, such as the man-hour of the task and the required time (so-called lead time). For example, the server 1 refers to the task DB 142 and reads information such as the time required for each task and the number of persons in charge in each project. Based on the above information, the server 1 calculates the man-hour for each task in addition to the man-hour and lead time of the entire project.

  For example, when the terminal 2 receives an operation input to the result tab 53, the terminal 2 displays a task result screen shown in FIG. This screen is a screen that displays project performance information. For example, the terminal 2 receives a project designation input through 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 execution efficiency calculated by the server 1 on the task performance screen. For example, the terminal 2 displays the man-hour and lead time of the entire project at the top of the screen. Further, the terminal 2 displays the man-hours for each task in a Gantt chart format. Thereby, the user can confirm the performance of the task and can improve the efficiency of the work.

  In the above, task man-hours and lead times are given as examples. However, the server 1 is not limited to this. For example, the number of task return times, the response time from the completion of the task to the start of the subsequent task, and the like. An evaluation index may be calculated as performance information.

  Moreover, the server 1 may perform the man-hour prediction of the task that has not been started, the prediction of the lead time, and the like based on the past result information of the task that has been performed. Thereby, a user's business can be supported more actively.

FIG. 11 is a flowchart illustrating an example of a processing procedure for task registration processing. Based on FIG. 11, processing contents of task registration processing executed by the server 1 will be described.
For example, the control unit 11 of the server 1 performs the following processing by badge processing. The control unit 11 acquires the message information of the user (Step S11). Specifically, the server 1 accesses the mail server 3 and acquires an electronic mail transmitted from the user or transmitted to the user. The control unit 11 determines whether or not 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 title and body of the mail, and determines whether or not a predetermined keyword used at the time of requesting a task is included.

  When it determines with it being the message information which concerns on a task request (S12: YES), the control part 11 extracts task information from message information (step S13). For example, the control unit 11 extracts task information with the title of the mail as the task name and the mail text as the task content. In addition, the control unit 11 performs character recognition on the mail text, and extracts attribute information such as a project name and a customer name in addition to the task execution deadline.

  The control unit 11 identifies the person in charge of the task and the related person from the extracted task information (step S14). The person in charge is a user in charge of performing the task. The related person is the requester who requested the person in charge for the task or other users. For example, the control unit 11 identifies the person in charge of the task and the related person from header information such as the sender and destination of the mail, or from the personal name included in the mail text.

  Based on the identification result of step S14, 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 concerned (step S15). ). That is, the server 1 classifies the tasks extracted from the user's mail into a task for which the user is responsible and a task for which another user is responsible. The control unit 11 registers the classified first or second task information in the task DB 142 (step S16). For example, the control unit 11 stores the task name, the task content, the execution deadline, the user ID of the person in charge, the user ID of the related person, and other attribute information in association with the task ID in the task DB 142. The control unit 11 ends the series of processes.

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

  When it determines with it not being a progress report (S17: NO), the control part 11 determines whether message information is the message which concerns on a user's schedule adjustment request (step S20). When it determines with it not being a schedule adjustment request (S20: NO), the control part 11 complete | finishes a series of processes. When it determines with it being a schedule adjustment request (S20: YES), the control part 11 extracts the information which concerns on a schedule adjustment request from message information (step S21). For example, the control unit 11 extracts information such as the event location, date and time, and event content described in the mail.

  The control unit 11 refers to the scheduler managed by the schedule server 4 and identifies schedule candidates that can be handled by the user (step S22). The control part 11 produces | generates the reply message which notifies the other party of the identified schedule candidate, and replies via the mail server 3 (step S23). Further, the control unit 11 provisionally registers the schedule in the schedule candidate specified in step S22 with respect to 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. Based on FIG. 12, the processing content of the task output process which the server 1 performs is demonstrated.
For example, when the control unit 11 of the server 1 receives a login process from the terminal 2, the control unit 11 performs the following process. Based on the output request from the terminal 2, the control unit 11 determines whether or not the logged-in user outputs the first task information that is a person in charge (step S41). If 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 that lists the first task information for which the user is in charge. (Step S42). In the task management screen, the control unit 11 receives a setting input of attribute information of an existing task, a setting input of a subsequent task, a progress report input, and the like (step S43). The control unit 11 stores the input content in the task DB 142.

  The control unit 11 determines whether or not a progress report has been received in step S43 (step S44). When it determines with not receiving a progress report (S44: NO), the control part 11 transfers a process to step S56. If 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 it to the parties concerned (step S45). The control unit 11 moves the process to step S56.

  When it determines with not outputting 1st task information (S41: NO), the control part 11 determines whether the user outputs the 2nd task information which is a participant (step S46). When it determines with outputting 2nd task information (S46: YES), the control part 11 outputs the task management screen which shows the 2nd task information in which the said user is a related person to the terminal 2 (step S47).

  The control unit 11 refers to the task DB 142 and determines whether there is second task information for which a progress report has been made by the person in charge (step S48). If it is determined that there is no second task information for which a progress report has been made (S48: NO), the control unit 11 proceeds to step S56. If 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 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 it to the terminal 2. The report screen 61 is a pop-up screen showing the mail contents of the progress report transmitted from the person in charge, and an approval button 62 and a return button 64 for selecting whether or not the user (related person) approves the completion of the task. Etc.

  The control unit 11 determines whether or not a selection input for approving completion of the task has been received for the progress report output in step S49 (step S50). When it determines with having been approved (S50: YES), the control part 11 records the progress history to the effect that the said task was completed in task DB142 (step S51). The control unit 11 moves the process to step S56.

  When it is determined that the task completion 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, a task return, a question regarding the report content, or the like. The server 1 notifies the person in charge according to the input contents input by the related parties. In this case, the server 1 records notification contents such as task return, questions, etc. in the task DB 142 as a progress history. The control unit 11 moves the process to step S56.

  When it determines with not outputting 2nd task information (S46: NO), the control part 11 determines whether the track record information of a task is output (step S53). The track record information is information indicating task execution efficiency, and is information such as task man-hours and lead times, for example. When it determines with not outputting performance information (S53: NO), the control part 11 transfers a process to step S56. When it determines with outputting performance information (S53: YES), the control part 11 refers to the progress history of each task memorize | stored in task DB142, and performs implementation efficiency, such as a man-hour of a task, and required time (lead time). Calculate (step S54). The control part 11 produces | generates the task performance screen which displays implementation efficiency, such as the calculated man-hour and lead time, and outputs it to the terminal 2 (step S55). The control unit 11 moves the process to step S56.

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

  In the above description, the server 1 extracts the task information from the e-mails transmitted and received at the user's e-mail address. However, 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 source of task information extraction is not limited to e-mail.

  In addition, when task information is not described in the e-mail transmitted to the user's e-mail address and information regarding the schedule is not described, the e-mail has a formal content such as mere confirmation or thanks. Probability is high. Therefore, for example, when the description about the task and the schedule is not recognized from the e-mail (step S20: NO), the server 1 may automatically reply with a fixed message. Thereby, a user's convenience can be improved.

  For example, the server 1 may of course perform reminding, prompting, etc. on 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.

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

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

  Further, according to the first embodiment, task management without omission can be performed by using template information of a project in which a plurality of tasks are associated.

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

(Embodiment 2)
In the present embodiment, a mode in which a user creates a document used in a conference based on task information managed by the server 1 will be described. In addition, about the content which overlaps with Embodiment 1, the same code | symbol is attached | subjected and description is abbreviate | omitted.
FIG. 13 is an explanatory diagram regarding document generation processing. In the present embodiment, the server 1 creates an agenda used by the user in the conference and a minutes recording the conference content.

  Specifically, the server 1 receives from the terminal 2 a selection of a task related to the agenda of the meeting among a 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 project tasks on the terminal 2 and accepts selection of one or more tasks in a check box format.

  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 described above, the task attribute is information indicating the classification of the task, such as the person in charge name, the name of the person concerned, the project name, the customer name, the project attribute (for example, a product handled in the project, etc.) This is related information associated with the ID. As described in the first embodiment, the server 1 recognizes the content of the e-mail or accepts a setting input via the task management screen, so that the various types of information described above are used as task attribute information in the task DB 142. Remember it.

  For example, the server 1 accepts designation of attribute information via the terminal 2, searches for a task with the designated attribute, and displays a list on the terminal 2. For example, when the designation 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, the server 1 displays a list of the searched task groups on the terminal 2 as shown in FIG.

  The server 1 accepts selection of a task to be used for a conference agenda from a plurality of tasks displayed as a list on the terminal 2. The server 1 generates a document file including the agenda items of the conference and input fields corresponding to the items based on the task information related to the selected task. For example, the server 1 uses the 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. As a result, the server 1 creates a document corresponding to the conference agenda.

  The server 1 outputs the generated document file to the terminal 2. During the meeting, the user operates the terminal 2 to input text into each input field. Specifically, the user inputs the contents of the agenda, such as remarks in the conference, matters to be determined, and newly raised issues.

  After the meeting, the server 1 stores the document file in which the contents of the proceedings are input as the minutes according to the operation from the terminal 2. For example, the server 1 stores the document file in the task DB 142 as an attached file related to the task.

In addition, the server 1 updates the task DB 142 according to the input contents 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 or not the completion of the corresponding task has been approved. The server 1 updates the task progress history according to the determination result, and records the completion of the task. Further, for example, the server 1 registers a new task input in the document file in the task DB 142 as new task information.
As described above, the server 1 creates an agenda and 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 illustrating an example of a processing procedure of document generation processing. Based on FIG. 14, processing contents of the document generation processing executed by the server 1 will be described.
The control unit 11 of the server 1 accepts designation of task attribute information via the terminal 2 (step S201). The attribute information is information extracted from the message information or set and 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 searched plurality of task information to the terminal 2 (step S203). And the control part 11 receives the selection input which selects one or several task information among the several task information output (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 uses the task name as the agenda item and inserts a text input field corresponding to each item into the document file to generate an agenda.

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

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

  In the above, the case where the task search function based on attribute information is used at the time of agenda creation is described. However, the use of the search function is not limited to the creation of the agenda. Of course, it may be possible to search in the scene. In other words, the server 1 only needs to be able to simultaneously output a plurality of task information using the task attribute as a search key.

  As described above, according to the second embodiment, the creation of a document based on task information can support further business efficiency.

(Embodiment 3)
In the present embodiment, a mode is described in which the difference between the task difficulty level recognized by the person in charge and the task difficulty level recognized by the person concerned is resolved, and the representative value of the task difficulty level is determined.
FIG. 15 is an explanatory diagram regarding task difficulty level determination processing. FIG. 15 illustrates a conceptual explanatory diagram of the processing content executed by the server 1 in the present embodiment.

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

  For example, the server 1 accepts a setting input of the task difficulty level with numerical values in five stages of 1 to 5 on the task management screen illustrated in FIGS. The server 1 stores the input task difficulty level in the task DB 142. The server 1 accepts the setting input of the difficulty level from both the person in charge and the related person for each task, and stores it in the task DB 142.

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

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

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

FIG. 16 is a flowchart illustrating an example of a processing procedure of task output processing according to the third embodiment. Based on FIG. 16, the processing content of the server 1 which concerns on this Embodiment is demonstrated.
After outputting the first task information to the terminal 2 (step S42), the control unit 11 of the server 1 accepts an input for setting 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 part 11 receives the setting input of the difficulty level of each task by five-step evaluation. The control unit 11 stores the difficulty level set by the person in charge in the task DB 142. The control part 11 transfers a process to step S43.

  After outputting the second task information to the terminal 2 (step S47), the control unit 11 accepts the setting input of the difficulty level of the second task information by the persons related to the task and stores it in the task DB 142 (step S302). For example, the control part 11 receives the setting input of the difficulty level of each task by five-step evaluation similarly to step S301. The control unit 11 stores the setting value of the difficulty level set by the parties in the task DB 142. The control unit 11 moves the process to step S48.

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

  As described above, according to the third embodiment, by determining the representative value of the task difficulty level, it is possible to eliminate the difference in recognition between the person in charge and the related person, and to estimate the man-hour of the task.

  The embodiment disclosed this time is to be considered as illustrative in all points and not restrictive. The scope of the present invention is defined by the terms of the claims, rather than the meanings described above, and is intended to include any modifications within the scope and meaning equivalent to the terms of the claims.

1 server (information processing equipment)
11 Control Unit 12 Storage Unit P Program 13 Communication Unit 14 Mass Storage Device 141 Project DB
142 Task DB
143 User DB
2 Terminal 3 Mail server 4 Schedule server

In one proposal, the information processing apparatus includes: an acquisition unit that acquires message information of a user; 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 a person who has requested the task and a client who has requested the task , and the task information, the first task information in which the user is the person in charge, or the first in which the user is the client A classification unit for classifying into two-task information, a registration unit for registering the classified first or second task information in a database, and an output unit for outputting the first or second task information with reference to the database It is characterized by providing.

In one proposal, the program acquires user message information, extracts task information related to the user from the acquired message information, and from the extracted task information, a person who is requested to perform the task , and The requester who requested the task is identified, and 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 requester, and the classified first The first or second task information is registered in a database, and the computer is caused to execute processing for outputting the first or second task information with reference to the database.

In one proposal, the information processing apparatus includes: an acquisition unit that acquires message information of a user; 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 a person who has requested the task and a client who has requested the task, and the task information, the first task information in which the user is the person in charge, or the first in which the user is the client A classification unit for classifying into two-task information, a registration unit for registering the classified first or second task information in a database, and referring to the database , the user being the person in charge for the user An output unit for separately outputting a list of first task information and a list of second task information for which the user is the requester is provided.

In one proposal, the program acquires user message information, extracts task information related to the user from the acquired message information, and from the extracted task information, a person who is requested to perform the task, and The requester who requested the task is identified, and 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 requester, and the classified first The first or second task information is registered in a database, and the database is referred to, for the user, the list of the first task information for which the user is the person in charge, and the user for the requester. It is characterized by causing a computer to execute a process of separately outputting a list of second task information .

Claims (10)

An acquisition unit for acquiring user message information;
An extraction unit for extracting task information related to the user from the acquired message information;
An identification unit for identifying a person in charge of the task and a person concerned from the extracted task information;
A classification unit 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;
A registration unit for registering the classified first or second task information in a database;
An information processing apparatus comprising: an output unit that outputs the first or second task information with reference to the database. A second acquisition unit for acquiring a progress report of the task;
When the progress report is acquired, the output unit outputs the progress report to the related parties,
An approval receiving unit that receives a selection as to whether or not to approve completion of the task for the output progress report;
The information processing apparatus according to claim 1, further comprising: a notification unit configured to notify the person in charge when the completion of the task is not approved. Based on the progress report, a recording unit for recording a progress history of the task;
The information processing apparatus according to claim 2, further comprising: a calculation unit that calculates an execution efficiency of the task with reference to the progress history. A storage unit for storing template information in which a plurality of the task information is associated;
The information processing apparatus according to claim 1, wherein the registration unit registers the plurality of task information by receiving specification of the template information. The extraction unit further extracts information related to the user's schedule adjustment request from the message information,
With reference to a scheduler that manages the user's schedule, a specifying unit that specifies a schedule candidate that the user can handle,
5. The information processing apparatus according to claim 1, further comprising: a second registration unit that temporarily registers the schedule for the identified schedule candidate in the scheduler. Based on the attribute information of the task, comprising a search unit for searching a plurality of the task information from the database,
The information processing apparatus according to claim 1, wherein the output unit outputs the plurality of searched task information. A task selection unit that accepts selection of the task information registered in the database;
A document generation unit that generates 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 claim 1, further comprising an update unit configured to update the database in accordance with input contents to the output document file. A difficulty level acceptance unit that accepts setting input of the difficulty level of the task from both the person in charge and the person concerned;
A difficulty level storage unit for storing the set value of the received difficulty level;
The information processing apparatus according to claim 1, further comprising: a determination unit that refers to the difficulty level storage unit and determines a representative value of the difficulty level of the task. The message information is an email sent from or sent to the user,
The information processing apparatus according to claim 1, wherein the identification unit identifies the person in charge and a person concerned from header information or text of the electronic mail. Get user message information,
Extracting task information related to the user from the acquired message information,
From the extracted task information, identify the person in charge of the task and the person concerned,
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 in charge;
Register the classified first or second task information in a database;
A program for causing a computer to execute a process of outputting the first or second task information with reference to the database.

Images