WO2019012781A1 - 情報処理装置及びプログラム - Google Patents
情報処理装置及びプログラム Download PDFInfo
- Publication number
- WO2019012781A1 WO2019012781A1 PCT/JP2018/016711 JP2018016711W WO2019012781A1 WO 2019012781 A1 WO2019012781 A1 WO 2019012781A1 JP 2018016711 W JP2018016711 W JP 2018016711W WO 2019012781 A1 WO2019012781 A1 WO 2019012781A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- task
- information
- user
- person
- server
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
Definitions
- the present invention relates to an information processing apparatus and program.
- 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.
- Patent Document 1 only manages the tasks assigned to the individual users, and does not manage the tasks requested by other users.
- 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.
- 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.
- tasks associated with the user can be appropriately classified and managed.
- FIG. 18 is a flowchart illustrating an example of a processing procedure of task output processing according to Embodiment 3.
- FIG. 18 is a flowchart illustrating an example of a processing procedure of task output processing according to Embodiment 3.
- FIG. 1 is a schematic view showing a configuration example of a task management system.
- 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.
- 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.
- 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.
- 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.
- 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
- 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.
- the storage unit 12 and the large capacity storage device 14 may be configured as an integrated storage device.
- the mass storage device 14 may be configured by a plurality of storage devices.
- the mass storage device 14 may be an external storage device connected to the server 1.
- 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.
- 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.
- the project DB 141 stores information of each project in the work.
- 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.
- 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.
- 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
- 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.
- 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.
- 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 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.
- 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.
- 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).
- 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.
- 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.
- 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.
- the task management screen is a management screen that displays task information registered in the task DB 142 in a list.
- the server 1 receives a login process from the terminal 2, the server 1 generates a task management screen shown in FIG.
- 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.
- the terminal 2 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.
- task information including a task name 54, a project name 55, and an execution deadline 56 is displayed in a list.
- the terminal 2 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.
- the server 1 uses the task management screen shown in FIG. , And accepts setting input of attribute information of each task.
- 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.
- 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.
- 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.
- 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.
- the server 1 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. .
- 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.
- the server 1 simultaneously registers the tasks of the past projects as the subsequent tasks.
- 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.
- the terminal 2 displays the report button 58 on the task management screen.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- the approval button 62 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.
- the server 1 sends a response to the person in charge indicating that the approval has not been obtained.
- the terminal 2 creates a new mail.
- the user person concerned
- 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.
- 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.
- this system also supports coordination of the user's schedule.
- 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.
- 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.
- 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.
- 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).
- 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.
- the terminal 2 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- the control unit 11 of the server 1 executes the following process.
- 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).
- 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.
- 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.
- the control unit 11 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.
- step S53 determines whether to output task performance information.
- the record information is information representing task execution efficiency, and is information such as task man-hours and lead times.
- the control unit 11 shifts the processing to step S56.
- 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).
- 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.
- 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.
- the server 1 may read a message in a chat group to which the user belongs and extract task information.
- 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.
- the server 1 may automatically reply the fixed message. Thereby, the convenience of the user can be enhanced.
- the server 1 may of course perform reminding, prompting, and the like to the person in charge.
- efficient task management can be supported by mediating transmission and reception of progress reports.
- FIG. 13 is an explanatory diagram of document generation processing.
- the server 1 creates an agenda which the user uses in a conference, and minutes in which the content of the conference is recorded.
- 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.
- the server 1 searches the task DB 142 for tasks having attributes specified by the user, and displays a list on the terminal 2.
- 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.
- 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.
- 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.
- 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.
- 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.
- the server 1 updates the task DB 142 in accordance with the input content to the document file.
- 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.
- the server 1 registers, in the task DB 142, a new task input to the document file as new task information.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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).
- 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.
- the control unit 11 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.
- the control unit 11 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.
- 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.
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Entrepreneurship & Innovation (AREA)
- Economics (AREA)
- Human Resources & Organizations (AREA)
- Strategic Management (AREA)
- Tourism & Hospitality (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Educational Administration (AREA)
- Marketing (AREA)
- General Business, Economics & Management (AREA)
- Game Theory and Decision Science (AREA)
- Development Economics (AREA)
- General Engineering & Computer Science (AREA)
- Information Transfer Between Computers (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
ユーザに関連するタスクを適切に分類して管理することができる情報処理装置等を提供する。 情報処理装置(1)は、ユーザのメッセージ情報を取得する取得部と、取得した前記メッセージ情報から、前記ユーザに関連するタスク情報を抽出する抽出部と、抽出した前記タスク情報から、タスクの担当者及び関係者を識別する識別部と、前記タスク情報を、前記ユーザが前記担当者である第1タスク情報、又は前記ユーザが前記関係者である第2タスク情報に分類する分類部と、分類した前記第1又は第2タスク情報をデータベースに登録する登録部と、該データベースを参照して、前記第1又は第2タスク情報を出力する出力部とを備えることを特徴とする。
Description
本発明は、情報処理装置及びプログラムに関する。
従来、ユーザのタスクを管理するタスク管理ツールとして、種々の管理システムが提案されている。例えば特許文献1では、企業等の組織内のワークフローシステムであって、業務内の各タスクと、各タスクを担当する従業員とを紐付けた一覧表データを基に、従業員に対してタスクを依頼する電子メールの送信、タスクの催促、期限管理等を行う管理システムが開示されている。
しかしながら、特許文献1に係る発明は、個々のユーザに割り当てたタスクの管理を行うのみで、ユーザが他人に依頼したタスクの管理を行っていない。
例えばタスクの内容によっては、ユーザがあるタスクを行うためには、他人に依頼したタスクの完了を待たなくてはならない場合がある。従って、ユーザが担当するタスクを管理するだけでなく、他人が担当するタスクの管理も重要となる。
一つの側面では、ユーザに関連するタスクを適切に分類して管理することができる情報処理装置等を提供することを目的とする。
一つの案では、情報処理装置は、ユーザのメッセージ情報を取得する取得部と、取得した前記メッセージ情報から、前記ユーザに関連するタスク情報を抽出する抽出部と、抽出した前記タスク情報から、タスクの担当者及び関係者を識別する識別部と、前記タスク情報を、前記ユーザが前記担当者である第1タスク情報、又は前記ユーザが前記関係者である第2タスク情報に分類する分類部と、分類した前記第1又は第2タスク情報をデータベースに登録する登録部と、該データベースを参照して、前記第1又は第2タスク情報を出力する出力部とを備えることを特徴とする。
一つの案では、プログラムは、ユーザのメッセージ情報を取得し、取得した前記メッセージ情報から、前記ユーザに関連するタスク情報を抽出し、抽出した前記タスク情報から、タスクの担当者及び関係者を識別し、前記タスク情報を、前記ユーザが前記担当者である第1タスク情報、又は前記ユーザが前記関係者である第2タスク情報に分類し、分類した前記第1又は第2タスク情報をデータベースに登録し、該データベースを参照して、前記第1又は第2タスク情報を出力する処理をコンピュータに実行させることを特徴とする。
一つの側面では、ユーザに関連するタスクを適切に分類して管理することができる。
以下、本発明をその実施の形態を示す図面に基づいて詳述する。
(実施の形態1)
図1は、タスク管理システムの構成例を示す模式図である。本実施の形態では、業務内でユーザが携わるプロジェクトのタスク管理を行うタスク管理システムについて説明する。タスク管理システムは、情報処理装置1、端末2、2、2…、メールサーバ3、スケジュールサーバ4を含む。各装置は、インターネット等のネットワークNを介して通信接続されている。
(実施の形態1)
図1は、タスク管理システムの構成例を示す模式図である。本実施の形態では、業務内でユーザが携わるプロジェクトのタスク管理を行うタスク管理システムについて説明する。タスク管理システムは、情報処理装置1、端末2、2、2…、メールサーバ3、スケジュールサーバ4を含む。各装置は、インターネット等のネットワークNを介して通信接続されている。
情報処理装置1は、種々の情報処理、情報の送受信を行う情報処理装置であり、例えばサーバ装置、パーソナルコンピュータ等である。本実施の形態において情報処理装置1はサーバ装置であるものとし、以下では簡潔のため、サーバ1と読み替える。サーバ1は、ユーザに関連するタスク情報を記憶し、タスクの実行期限等を管理する。本実施の形態では、サーバ1は、ユーザに割り当てられたタスクだけでなく、例えばユーザが他人に依頼したタスクのように、他人に割り当てられたタスクもユーザに関連するタスクとして管理する。
端末2は、各ユーザが使用する端末装置であり、例えばパーソナルコンピュータ、スマートフォン、タブレット端末等である。端末2はサーバ1と通信を行い、タスク情報の表示、入力等の処理を行う。
メールサーバ3は、ユーザによるメールの送受信を管理するサーバ装置である。本実施の形態においてサーバ1は、ユーザが送受信した電子メール(メッセージ情報)をメールサーバ3から取得し、メール文面からタスク名、タスクの内容、実施期限等のタスク情報を抽出する。サーバ1は、抽出したタスク情報をデータベースに登録し、タスク管理を行う。
スケジュールサーバ4は、ユーザのスケジュールに関する情報を管理するサーバ装置である。後述するように、スケジュールサーバ4は、タスク管理を行うサーバ1と情報の送受信を行い、他人からのスケジュールの調整依頼に対してユーザが対応可能な日程候補を特定し、スケジュールを仮登録する処理を行う。
図2は、サーバ1の構成例を示すブロック図である。サーバ1は、制御部11、記憶部12、通信部13、大容量記憶装置14を含む。
制御部11はCPU(Central Processing Unit)、MPU(Micro-Processing Unit)等の演算処理装置を含み、記憶部12に記憶されたプログラムPを読み出して実行することにより、サーバ1に係る種々の情報処理、制御処理等を行う。なお、図2では制御部11を単一のプロセッサとして図示してあるが、制御部11はマルチプロセッサであってもよい。記憶部12はRAM(Random Access Memory)、ROM(Read Only Memory)等のメモリ素子を含み、制御部11が処理を実行するために必要なプログラムP及びデータを記憶している。また、記憶部12は、制御部11が演算処理を実行するために必要なデータを一時的に記憶する。通信部13は通信に関する処理を行うための処理回路等を含み、ネットワークNを介して端末2等と情報の送受信を行う。
制御部11はCPU(Central Processing Unit)、MPU(Micro-Processing Unit)等の演算処理装置を含み、記憶部12に記憶されたプログラムPを読み出して実行することにより、サーバ1に係る種々の情報処理、制御処理等を行う。なお、図2では制御部11を単一のプロセッサとして図示してあるが、制御部11はマルチプロセッサであってもよい。記憶部12はRAM(Random Access Memory)、ROM(Read Only Memory)等のメモリ素子を含み、制御部11が処理を実行するために必要なプログラムP及びデータを記憶している。また、記憶部12は、制御部11が演算処理を実行するために必要なデータを一時的に記憶する。通信部13は通信に関する処理を行うための処理回路等を含み、ネットワークNを介して端末2等と情報の送受信を行う。
大容量記憶装置14は、例えばハードディスク等を含む大容量の記憶装置である。大容量記憶装置14は、プロジェクトDB141、タスクDB142、ユーザDB143等を記憶している。プロジェクトDB141は、ユーザが携わっている各プロジェクトのデータを記憶している。タスクDB142は、各プロジェクトにおいてユーザが実施するタスクに関する情報を記憶している。ユーザDB143は、各ユーザの情報を記憶している。
なお、本実施の形態において記憶部12及び大容量記憶装置14は一体の記憶装置として構成されていてもよい。また、大容量記憶装置14は複数の記憶装置により構成されていてもよい。また、大容量記憶装置14はサーバ1に接続された外部記憶装置であってもよい。
また、本実施の形態においてサーバ1は上記の構成に限られず、例えば操作入力を受け付ける入力部、サーバ1に係る情報を表示する表示部、可搬型記憶媒体に記憶された情報を読み取る読取部等を含んでもよい。
また、本実施の形態においてサーバ1は上記の構成に限られず、例えば操作入力を受け付ける入力部、サーバ1に係る情報を表示する表示部、可搬型記憶媒体に記憶された情報を読み取る読取部等を含んでもよい。
図3は、プロジェクトDB141のレコードレイアウトの一例を示す説明図である。プロジェクトDB141は、プロジェクトID列、プロジェクト名列、顧客列、プロジェクト属性列を含む。プロジェクトID列は、各プロジェクトを識別するための識別情報を記憶している。プロジェクト名列は、プロジェクトの名称を記憶している。顧客列は、各プロジェクトの取引先である顧客の情報(例えば法人名)を記憶している。プロジェクト属性列は、各プロジェクトの商材である商品名、各プロジェクトで取り扱う案件名など、プロジェクトの属性を表す情報を記憶している。
上記のように、プロジェクトDB141には、業務内の各プロジェクトの情報が記憶されている。例えばサーバ1は、管理者によるプロジェクトの事前登録を受け付け、プロジェクトDB141に記憶しておく。
上記のように、プロジェクトDB141には、業務内の各プロジェクトの情報が記憶されている。例えばサーバ1は、管理者によるプロジェクトの事前登録を受け付け、プロジェクトDB141に記憶しておく。
図4は、タスクDB142のレコードレイアウトの一例を示す説明図である。タスクDB142は、タスクID列、タスク名列、プロジェクト列、タスク内容列、進捗列、添付ファイル列、担当者列、関係者列、着手予定日列、着手日列、完了予定日列、完了日列、後続タスク列を含む。タスクID列は、各プロジェクトにおいて実施される個々のタスクを識別するための識別情報を記憶している。タスク名列は、タスクIDと対応付けて、タスクの名称を記憶している。プロジェクト列は、タスクIDと対応付けて、当該タスクに係るプロジェクトのIDを記憶している。タスク内容列は、タスクIDと対応付けて、各タスクの内容を記憶している。進捗列は、タスクIDと対応付けて、各タスクの進捗状況を記憶している。
担当者列は、タスクIDと対応付けて、タスクの担当者を識別するための識別情報を記憶している。関係者列は、タスクIDと対応付けて、当該タスクに関係する関係者を識別するための識別情報を記憶している。関係者は、担当者にタスクを依頼した依頼者、その他の関係者である。タスクDB142には、各タスクの担当者だけでなく、各タスクの関係者も併せて登録されている。
着手予定日列、着手日列、完了予定日列、完了日列はそれぞれ、タスクIDと対応付けて、タスクの着手予定日、着手日、完了予定日、完了日を記憶している。後続タスク列は、タスクIDと対応付けて、プロジェクトにおいて当該タスクに続く後続タスクのIDを記憶している。
図5は、ユーザDB143のレコードレイアウトの一例を示す説明図である。ユーザDB143は、ユーザID列、ユーザ名列、所属列、アドレス列、スケジューラアカウント列を含む。ユーザID列は、各ユーザを識別するための識別情報を記憶している。ユーザ名列は、ユーザIDと対応付けて、各ユーザの名前を記憶している。所属列は、ユーザIDと対応付けて、各ユーザの所属先(例えば勤務先の部署名)を記憶している。アドレス列は、ユーザIDと対応付けて、ユーザが使用しているメールアドレスを記憶している。スケジューラアカウント列は、ユーザIDと対応付けて、各ユーザが使用しているスケジューラのアカウント情報を記憶している。
図6は、タスク登録処理の概要に関する説明図である。以下では、タスク管理システムが実行する処理の概要について説明する。
サーバ1は、ユーザが送信又は受信したメッセージ情報からタスク情報を抽出し、データベースに登録する処理を行う。メッセージ情報は、例えば電子メールである。サーバ1は、メールサーバ3と同期し、ユーザのメールアドレス宛に送信されたメール、及びユーザのメールアドレスから送信されたメールを取得する。
サーバ1は、ユーザが送信又は受信したメッセージ情報からタスク情報を抽出し、データベースに登録する処理を行う。メッセージ情報は、例えば電子メールである。サーバ1は、メールサーバ3と同期し、ユーザのメールアドレス宛に送信されたメール、及びユーザのメールアドレスから送信されたメールを取得する。
なお、サーバ1は、本システムの利用者が送受信したメールを取得可能であればよく、メールの相手方は本システムの利用者である必要はない。例えば本システムを社内のタスク管理ツールとして実装する場合、メールの送信元又は送信先は社外の人間であってよい。
サーバ1は、取得したメールが、タスク依頼に係るメールであるか否かを判定する。例えばサーバ1は、メールのタイトル及び本文において、「依頼」、「お願いします」など、タスクの依頼時に用いられる所定のキーワードが記述されているか否かを判定する。
タスク依頼に係るメールであると判定した場合、サーバ1は、当該メールからタスク情報を抽出する。具体的には、サーバ1はタスク名、タスクの内容、タスクの実施期限等の情報を抽出する。例えばサーバ1は、メールのタイトルをタスク名とし、メールの本文をタスク内容として抽出する。また、サーバ1は、メール本文から、タスクの実施期限のほか、タスクに係るプロジェクト名、顧客名等のように、タスクに関連する属性情報を抽出する。属性情報は、タスクの分類を表す情報であり、タスクIDと紐付けられる関連情報である。サーバ1は、電子メールに対する文字認識を行い、実施期限のほかに、タスクの属性情報を抽出する。サーバ1はさらに、当該メールの添付ファイルを抽出する。このように、サーバ1は電子メールから、タスクに関連する情報を可能な限り抽出していく。
サーバ1は、抽出したタスク情報から、タスクの担当者及び関係者を識別する。担当者は、タスクを担当するユーザである。一方で、関係者は、例えばタスクを依頼した依頼者、タスクの結果物を共有するプロジェクトのメンバーなど、タスクに関係するユーザである。例えばサーバ1は、送信元(From)、送信先(To)、同時送信先(Cc、Bcc)等の電子メールのヘッダ情報から、タスクの担当者及び関係者を識別する。また、例えばサーバ1は、メール本文の文字認識を行い、メール本文に含まれる個人名から、担当者及び関係者を識別するようにしてもよい。このように、サーバ1は、電子メールのヘッダ情報又は本文から担当者及び関係者を識別する。
サーバ1は、上記の識別結果に基づき、メールから抽出したタスク情報を、当該メールの送受信元であるユーザが担当者である第1タスク情報、又は当該ユーザが関係者である第2タスク情報に分類する。すなわちサーバ1は、メールに記載されているタスクが、ユーザ本人が実施すべきタスクであるか、又は他のユーザが実施すべきタスクであるかを判断する。
サーバ1は、第1タスク情報、又は第2タスク情報として分類したタスク情報を、タスクDB142に登録する。例えばサーバ1は、当該タスクについて新規のタスクIDを発行し、タスクIDと対応付けて、タスク名、タスク内容、タスクの実施期限等の情報をタスクDB142に記憶する。また、サーバ1は、タスクIDと対応付けて、担当者のユーザID、及び関係者のユーザID、その他の属性情報をタスクDB142に記憶する。
上記の処理により、サーバ1は、ユーザが担当する第1タスク情報と、他のユーザが担当する第2タスク情報とを別々に管理する。すなわち、図6下に示すように、サーバ1は、ユーザから他人にアウトプットすべきタスクと、他人からユーザにインプットされるタスクとを別々に管理する。以上より、ユーザ本人のタスクと他人のタスクとが自動的に仕分けられ、タスク管理の利便性を高めることができる。
図7及び図8は、タスク管理画面の一例を示す説明図である。タスク管理画面は、タスクDB142に登録されているタスク情報を一覧で示す管理画面である。例えばサーバ1は、端末2からログイン処理を受け付けた場合、図7等に示すタスク管理画面を生成して端末2に出力する。図7に示すように、タスク管理画面には、画面左側に第1タスクフォルダ51、第2タスクフォルダ52、及び実績タブ53を含むメニューが表示される。
例えば端末2は、第1タスクフォルダ51への操作入力を受け付けた場合、図7に示す画面を表示する。図7は、ユーザが担当する第1タスク情報の管理画面である。当該画面では、タスク名54、プロジェクト名55、及び実施期限56を含むタスク情報が一覧表示される。
端末2は、タスク名54への操作入力を受け付けた場合、さらにタスクの詳細表示を行う。具体的には図7に示すように、端末2は、タスク名54の下に、客先名、関係者名、タスクの内容(詳細)、添付ファイル等の表示を行う。これにより、ユーザはタスクの詳細を確認することができる。
なお、タスク情報の抽出元であるメールの文面によっては、例えばタスクの実施期限、プロジェクト名等の必要事項が記述されていない可能性もあるため、サーバ1は、図7に示すタスク管理画面で、各タスクの属性情報の設定入力を受け付ける。例えば端末2は、タスク名54、プロジェクト名55、実施期限56等の設定入力を受け付ける。サーバ1は、端末2を介して受け付けた属性情報をタスクDB142に記憶する。
また、サーバ1は、端末2を介して、後続タスクの設定入力を受け付ける。後続タスクは、一連のプロジェクトにおいて、当該タスクに続いて実施すべきタスクである。例えばサーバ1は、同一プロジェクトについてタスクDB142に登録済みのタスクを管理画面の後続タスク欄57にプルダウン表示させ、ユーザによる選択を受け付ける。サーバ1は、後続タスク欄57で選択されたタスクを、タスク名54で示すタスクと対応付けてタスクDB142に登録する。
また、サーバ1は、ユーザによる手動で一つひとつ後続タスクを設定するだけでなく、複数の後続タスクを一斉に登録可能としてもよい。具体的には、サーバ1は、複数のタスク情報を関連付けたプロジェクトのテンプレート情報を記憶しておき、テンプレート情報の指定を受け付けることで複数のタスク情報をタスクDB142に一斉登録する。
例えばサーバ1は、「テンプレートを参照する」と表示されている参照オブジェクト572への操作入力を受け付けた場合、プロジェクトDB141を参照し、過去に実施済みのプロジェクトの情報を読み出して端末2に出力する。例えばサーバ1は、商品名、案件名などのプロジェクト属性が、プロジェクト名55で示されるプロジェクトと同じプロジェクトを検索し、検索されたプロジェクトを端末2に出力する。サーバ1は、端末2を介して、当該プロジェクトで実施されたタスクをテンプレートとして使用するか否かの指定入力を受け付ける。テンプレートとして使用する旨の指定入力を受け付けた場合、サーバ1は、後続タスクとして過去のプロジェクトのタスクを一斉登録する。
なお、上記では過去に実施されたプロジェクトのタスク情報を流用することとしたが、管理者が事前にテンプレートを用意しておき、事前設定されたテンプレートを用いてもよいことは勿論である。
上述の如く、サーバ1は、後続タスクの設定入力を受け付けることで、タスク同士の時系列的な紐付けを行い、複数のタスクを一連のプロジェクトとして管理する。これにより、ユーザは効率的にタスク情報を把握することができる。
ユーザは、タスク管理画面に表示されている第1タスク情報を確認し、タスクを実施する。ユーザは、タスクの進捗状況に応じて、関係者に対する進捗報告を行う。例えば端末2は、タスク管理画面に報告ボタン58を表示しておく。報告ボタン58への操作入力を受け付けた場合、端末2は新規のメール(不図示)を作成する。ユーザは、新規のメールに、タスクが進行中であること、タスクが完了したことなどの進捗報告をテキスト入力する。なお、当該メールにタスクの結果物を添付ファイルとして添付してもよいことは勿論である。端末2は、関係者宛に進捗報告のメールを送信する。
端末2から進捗報告に係るメールが送信された場合、サーバ1は、当該メールをメールサーバ3から取得する。サーバ1は、当該メールの文面に対して文字認識を行い、進捗報告の内容を抽出する。また、サーバ1は、添付ファイルを併せて抽出する。サーバ1は、抽出した進捗報告に係る情報を進捗履歴としてタスクDB142に記録する。
上述の如く、サーバ1は、電子メールから進捗報告の内容を抽出し、進捗履歴を記録する。従って、サーバ1は、本システムの利用者ではない外部ユーザから送信されたメールについても、進捗報告の抽出、記録が可能である。例えば本システムを社内のタスク管理ツールとして実装する場合、サーバ1は、業務委託先など、社外の担当者からのメールを取得し、当該メールから進捗報告を抽出して記録してもよい。すなわちサーバ1は、本システムの利用者のメールアドレス宛に送信された電子メールから進捗報告を取得可能であればよく、進捗報告の発信元はシステムの内外を問わない。これにより、タスク管理の汎用性を高めることができる。
図8は、ユーザに関係する第2タスク情報の管理画面である。第2タスクフォルダ52への操作入力を受け付けた場合、端末2は、図8に示すタスク管理画面を表示する。当該画面では、図7に示した第1タスク情報の管理画面と同じく、第2タスク情報が一覧で表示される。
一方で、図7の管理画面とは異なり、端末2は、各タスクの進捗状況を示すステータス59を併せて表示する。具体的には、画面右端に示すように、「完了」、「未着手」、「進行中」などのステータス59が表示される。サーバ1は、タスクDB142に記録された進捗履歴を参照して、ステータス59を管理画面上に出力する。ユーザ(関係者)はステータス59により、各タスクの進捗状況を確認することができる。
端末2は、当該管理画面で第2タスク情報を一覧表示するだけでなく、タスクの完了を承認するか否かの選択入力を受け付ける。例えば図8に示すように、端末2は、担当者から完了の報告があったタスクについてアイコン60を表示し、タスクが完了した旨をユーザ(関係者)に報知する。さらに端末2は、サーバ1と通信を行い、進捗報告の内容を示す報告画面61をポップアップ表示する。
報告画面61は、担当者から送信された進捗報告のメール内容を示すポップアップ画面である。端末2は、報告画面61に、メール文面、添付ファイル等のほかに、承認ボタン62、質問ボタン63、及び差戻しボタン64を表示する。承認ボタン62への操作が行われた場合、当該タスクの完了が承認される。この場合、端末2はタスク完了が承認された旨をサーバ1に通知する。サーバ1は、タスクが完了した旨を進捗履歴としてタスクDB142に記録する。この場合、例えばサーバ1は後続タスクの担当者に対し、後続タスクに着手すべき旨を通知する。
一方で、タスクの完了が承認されなかった場合、サーバ1は、承認が得られなかった旨を担当者に返信する。例えば報告画面61の質問ボタン63が操作された場合、端末2は、新規のメールを作成する。ユーザ(関係者)は、報告内容について疑問点をメールに入力し、担当者に返信して質問を行う。また、差戻しボタン64が操作された場合、サーバ1が、タスクの完了が承認されなかった旨の定型メールを自動生成して担当者に返信する。このように、端末2はタスク管理画面上でタスクの完了を承認するか否かの選択を受け付け、非承認である場合に担当者へ通知を行う。なお、サーバ1は、関係者による質問、差戻し等の進捗履歴をタスクDB142に記録しておく。
以上より、サーバ1は電子メールからタスク情報を抽出するだけでなく、進捗報告に係る電子メールの送信など、タスク管理に必要な処理を管理画面内で一括して行うことができる。これにより、ユーザの利便性を高めることができる。
以上より、サーバ1は電子メールからタスク情報を抽出するだけでなく、進捗報告に係る電子メールの送信など、タスク管理に必要な処理を管理画面内で一括して行うことができる。これにより、ユーザの利便性を高めることができる。
図9は、スケジュール調整処理に関する説明図である。本システムでは、タスク管理を行うだけでなく、ユーザのスケジュールの調整支援も行う。
具体的には、サーバ1は、ユーザが送受信した電子メールから、ユーザのスケジュールの調整依頼に係る情報を抽出する。スケジュールの調整依頼は、例えば打ち合わせなどのイベントへの参加をユーザに要求する参加依頼である。サーバ1は、図9右上に示すように、メール文面から「打合せ」、「ご都合」等のキーワードの有無を判断し、スケジュール調整依頼に係るメールか否かを判定する。調整依頼に係るメールであると判定した場合、サーバ1は、メールに記載されている場所、日時(候補日)、イベント内容等の情報をメール文面から抽出する。
具体的には、サーバ1は、ユーザが送受信した電子メールから、ユーザのスケジュールの調整依頼に係る情報を抽出する。スケジュールの調整依頼は、例えば打ち合わせなどのイベントへの参加をユーザに要求する参加依頼である。サーバ1は、図9右上に示すように、メール文面から「打合せ」、「ご都合」等のキーワードの有無を判断し、スケジュール調整依頼に係るメールか否かを判定する。調整依頼に係るメールであると判定した場合、サーバ1は、メールに記載されている場所、日時(候補日)、イベント内容等の情報をメール文面から抽出する。
サーバ1は、ユーザのスケジュールを管理するスケジュールサーバ4にアクセスし、ユーザが対応可能な日程候補を特定する。すなわちサーバ1は、スケジューラから日程候補を特定する。なお、当該スケジューラは外部(スケジュールサーバ4)で管理してもよいし、サーバ1で管理してもよい。すなわち、サーバ1がユーザのスケジュールを参照可能であればよい。サーバ1はさらに、相手方から提示されている日時、前後のユーザの滞在場所、移動手段等から、日程候補を絞り込む。サーバ1は、最終的に特定した日程候補を相手方に通知する定型メールを作成し、メールサーバ3に返信を依頼する。メールサーバ3は、当該メールを相手方に返信する。
また、サーバ1は、上記で特定した日程候補におけるスケジュールを、スケジューラに仮登録をしておく。すなわちサーバ1は、スケジュールの仮押さえを行う。サーバ1は、イベントの場所、イベント内容、相手方の名称などを、日程候補の日時と対応付けてスケジュールサーバ4に記憶させる。
例えばサーバ1は、仮登録したスケジュールについて、後に相手方から返信されるメール内容を基に、スケジュールの確定、修正、リマインド等を行う。例えば日程確定のメールをメールサーバ3から取得した場合、サーバ1は当該メールから確定した日時を抽出し、スケジュールサーバ4に転送する。スケジュールサーバ4は、当該日時におけるスケジュールの確定登録、他の日程候補日に仮登録しておいたスケジュールの削除等を行う。このように、サーバ1は電子メールからタスク情報を抽出するだけでなく、ユーザのスケジュールに係る情報を抽出することで、スケジュール管理の支援を併せて行う。
図10は、タスク実績画面の一例を示す説明図である。サーバ1は、タスクDB142に記録されたタスクの進捗履歴から、各タスクの実施効率を表す実績情報を生成して端末2に出力する。
実績情報は、例えばタスクの工数、所要時間(いわゆるリードタイム)など、タスクの実績の評価指標となり得る情報である。例えばサーバ1は、タスクDB142を参照し、各プロジェクトにおけるタスク別の所要時間、担当者数などの情報を読み出す。サーバ1は、上記の情報を基に、プロジェクト全体の工数、リードタイムのほか、タスク別の工数などを計算する。
実績情報は、例えばタスクの工数、所要時間(いわゆるリードタイム)など、タスクの実績の評価指標となり得る情報である。例えばサーバ1は、タスクDB142を参照し、各プロジェクトにおけるタスク別の所要時間、担当者数などの情報を読み出す。サーバ1は、上記の情報を基に、プロジェクト全体の工数、リードタイムのほか、タスク別の工数などを計算する。
例えば端末2は、実績タブ53への操作入力を受け付けた場合、図10に示すタスク実績画面を表示する。当該画面は、プロジェクトの実績情報を表示する画面である。例えば端末2は、プロジェクトタブ65によりプロジェクトの指定入力を受け付ける。端末2は、プロジェクトタブ65で選択されたプロジェクトについて、実績情報の出力をサーバ1に要求する。サーバ1は、要求されたプロジェクトの実績情報を端末2に出力する。
端末2は、サーバ1で計算されたタスクの実施効率をタスク実績画面に表示する。例えば端末2は、プロジェクト全体の工数、リードタイムを画面上部に表示する。また、端末2はタスク別の工数をガントチャート形式で表示する。これにより、ユーザはタスクの実績を確認することができ、業務の効率化を図ることができる。
なお、上記ではタスクの工数及びリードタイムを一例に挙げたが、サーバ1はこれだけでなく、例えばタスクの差戻し回数、タスクが完了してから後続タスクが着手されるまでのレスポンス時間など、その他の評価指標を実績情報として計算してもよい。
また、サーバ1は、過去に実施されたタスクの実績情報に基づき、未着手のタスクの工数予測、リードタイムの予測等を行ってもよい。これにより、ユーザの業務をより積極的に支援することができる。
図11は、タスク登録処理の処理手順の一例を示すフローチャートである。図11に基づき、サーバ1が実行するタスク登録処理の処理内容について説明する。
例えばサーバ1の制御部11は、バッジ処理により以下の処理を行う。制御部11は、ユーザのメッセージ情報を取得する(ステップS11)。具体的には、サーバ1はメールサーバ3にアクセスし、ユーザから送信された、又はユーザ宛に送信された電子メールを取得する。制御部11は、取得したメッセージ情報が、新規のタスク依頼に係るメッセージ情報であるか否かを判定する(ステップS12)。例えば制御部11は、メールのタイトル及び本文の文字認識を行い、タスクの依頼時に用いられる所定のキーワードが含まれるか否かを判定する。
例えばサーバ1の制御部11は、バッジ処理により以下の処理を行う。制御部11は、ユーザのメッセージ情報を取得する(ステップS11)。具体的には、サーバ1はメールサーバ3にアクセスし、ユーザから送信された、又はユーザ宛に送信された電子メールを取得する。制御部11は、取得したメッセージ情報が、新規のタスク依頼に係るメッセージ情報であるか否かを判定する(ステップS12)。例えば制御部11は、メールのタイトル及び本文の文字認識を行い、タスクの依頼時に用いられる所定のキーワードが含まれるか否かを判定する。
タスク依頼に係るメッセージ情報であると判定した場合(S12:YES)、制御部11は、メッセージ情報からタスク情報を抽出する(ステップS13)。例えば制御部11は、メールのタイトルをタスク名、メール本文をタスク内容として、タスク情報を抽出する。また、制御部11は、メール本文に対する文字認識を行い、タスクの実施期限のほか、例えばプロジェクト名、顧客名等の属性情報を抽出する。
制御部11は、抽出したタスク情報から、タスクの担当者及び関係者を識別する(ステップS14)。担当者は、タスクの実施を担当するユーザである。関係者は、タスクを担当者に依頼した依頼者、その他のユーザである。例えば制御部11は、メールの送信元、送信先等のヘッダ情報から、又はメール本文に含まれる個人名から、タスクの担当者及び関係者を識別する。
制御部11は、ステップS14の識別結果に基づき、ステップS13で抽出したタスク情報を、ユーザが担当者である第1タスク情報、又はユーザが関係者である第2タスク情報に分類する(ステップS15)。すなわちサーバ1は、ユーザのメールから抽出したタスクを、ユーザが担当するタスクと、他のユーザが担当するタスクとに分類する。制御部11は、分類した第1又は第2タスク情報をタスクDB142に登録する(ステップS16)。例えば制御部11は、タスクIDと対応付けて、タスク名、タスク内容、実施期限のほか、担当者のユーザID、関係者のユーザID、その他の属性情報をタスクDB142に記憶する。制御部11は、一連の処理を終了する。
新規のタスク依頼に係るメッセージ情報でないと判定した場合(S12:NO)、制御部11は、メッセージ情報が既存タスクの進捗報告であるか否かを判定する(ステップS17)。進捗報告であると判定した場合(S17:YES)、制御部11は、メッセージ情報から進捗報告の内容を抽出する(ステップS18)。制御部11は、抽出した進捗報告の内容を、進捗履歴としてタスクDB142に記録し(ステップS19)、一連の処理を終了する。
進捗報告でないと判定した場合(S17:NO)、制御部11は、メッセージ情報が、ユーザのスケジュールの調整依頼に係るメッセージであるか否かを判定する(ステップS20)。スケジュールの調整依頼でないと判定した場合(S20:NO)、制御部11は一連の処理を終了する。スケジュールの調整依頼であると判定した場合(S20:YES)、制御部11は、メッセージ情報から、スケジュールの調整依頼に係る情報を抽出する(ステップS21)。例えば制御部11は、メールに記述されているイベントの場所、日時、イベント内容等の情報を抽出する。
制御部11は、スケジュールサーバ4で管理されているスケジューラを参照し、ユーザが対応可能な日程候補を特定する(ステップS22)。制御部11は、特定した日程候補を相手方に通知する返信メッセージを生成し、メールサーバ3を介して返信する(ステップS23)。さらに制御部11は、スケジュールサーバ4で管理されているスケジューラに対し、ステップS22で特定された日程候補におけるスケジュールを仮登録する(ステップS24)。制御部11は、一連の処理を終了する。
図12は、タスク出力処理の処理手順の一例を示すフローチャートである。図12に基づき、サーバ1が実行するタスク出力処理の処理内容について説明する。
例えばサーバ1の制御部11は、端末2からのログイン処理を受け付けた場合、以下の処理を実行する。制御部11は、端末2からの出力要求に基づき、ログインしたユーザが担当者である第1タスク情報を出力するか否かを判定する(ステップS41)。第1タスク情報を出力すると判定した場合(S41:YES)、制御部11はタスクDB142を参照して、当該ユーザが担当者である第1タスク情報を一覧で示すタスク管理画面を端末2に出力する(ステップS42)。制御部11は、当該タスク管理画面において、既存タスクの属性情報の設定入力、後続タスクの設定入力、及び進捗報告の入力等を受け付ける(ステップS43)。制御部11は、入力内容をタスクDB142に記憶する。
例えばサーバ1の制御部11は、端末2からのログイン処理を受け付けた場合、以下の処理を実行する。制御部11は、端末2からの出力要求に基づき、ログインしたユーザが担当者である第1タスク情報を出力するか否かを判定する(ステップS41)。第1タスク情報を出力すると判定した場合(S41:YES)、制御部11はタスクDB142を参照して、当該ユーザが担当者である第1タスク情報を一覧で示すタスク管理画面を端末2に出力する(ステップS42)。制御部11は、当該タスク管理画面において、既存タスクの属性情報の設定入力、後続タスクの設定入力、及び進捗報告の入力等を受け付ける(ステップS43)。制御部11は、入力内容をタスクDB142に記憶する。
制御部11は、ステップS43で進捗報告を受け付けたか否かを判定する(ステップS44)。進捗報告を受け付けていないと判定した場合(S44:NO)、制御部11は処理をステップS56に移行する。進捗報告を受け付けたと判定した場合(S44:YES)、制御部11は、進捗報告に係るメッセージ情報を生成し、関係者宛に出力する(ステップS45)。制御部11は、処理をステップS56に移行する。
第1タスク情報を出力しないと判定した場合(S41:NO)、制御部11は、ユーザが関係者である第2タスク情報を出力するか否かを判定する(ステップS46)。第2タスク情報を出力すると判定した場合(S46:YES)、制御部11は、当該ユーザが関係者である第2タスク情報を一覧で示すタスク管理画面を端末2に出力する(ステップS47)。
制御部11は、タスクDB142を参照し、担当者から進捗報告がなされた第2タスク情報があるか否かを判定する(ステップS48)。進捗報告がなされた第2タスク情報がないと判定した場合(S48:NO)、制御部11は処理をステップS56に移行する。進捗報告がなされた第2タスク情報があると判定した場合(S48:YES)、制御部11は、担当者から送信された進捗報告に係るメッセージ情報を端末2に出力する(ステップS49)。例えば制御部11は、進捗報告の内容を示す報告画面61を生成し、端末2に出力する。報告画面61は、担当者から送信された進捗報告のメール内容を示すポップアップ画面であり、ユーザ(関係者)がタスクの完了を承認するか否かを選択するための承認ボタン62、差戻しボタン64等を含む。
制御部11は、ステップS49で出力した進捗報告に対して、タスクの完了を承認する選択入力を受け付けたか否かを判定する(ステップS50)。承認されたと判定した場合(S50:YES)、制御部11は、当該タスクが完了した旨の進捗履歴をタスクDB142に記録する(ステップS51)。制御部11は、処理をステップS56に移行する。
タスクの完了が承認されなかったと判定した場合(S50:NO)、制御部11は、タスクの担当者に対する通知を行う(ステップS52)。当該通知の内容は、例えばタスクの差戻し、報告内容に関する質問などである。サーバ1は、関係者により入力された入力内容に応じて、担当者に対する通知を行う。また、この場合にサーバ1は、タスクの差戻し、質問などの通知内容を進捗履歴としてタスクDB142に記録しておく。制御部11は、処理をステップS56に移行する。
第2タスク情報を出力しないと判定した場合(S46:NO)、制御部11は、タスクの実績情報を出力するか否かを判定する(ステップS53)。実績情報は、タスクの実施効率を表す情報であり、例えばタスクの工数、リードタイム等の情報である。実績情報を出力しないと判定した場合(S53:NO)、制御部11は処理をステップS56に移行する。実績情報を出力すると判定した場合(S53:YES)、制御部11は、タスクDB142に記憶されている各タスクの進捗履歴を参照し、タスクの工数、所要時間(リードタイム)等の実施効率を計算する(ステップS54)。制御部11は、計算した工数、リードタイム等の実施効率を表示するタスク実績画面を生成し、端末2に出力する(ステップS55)。制御部11は、処理をステップS56に移行する。
制御部11は、端末2からログアウトの要求を受け付けたか否かを判定する(ステップS56)。ログアウトしないと判定した場合(S56:NO)、制御部11は処理をステップS41に戻す。ログアウトすると判定した場合(S56:YES)、制御部11は一連の処理を終了する。
なお、上記でサーバ1は、ユーザのメールアドレスにおいて送受信された電子メールからタスク情報を抽出したが、本実施の形態はこれに限定されるものではない。例えばサーバ1は、ユーザが属するチャットグループ内のメッセージを読み取り、タスク情報を抽出するようにしてもよい。このように、サーバ1はユーザが送受信するメッセージ情報からタスク情報を抽出可能であればよく、タスク情報の抽出元は電子メールに限定されない。
また、ユーザのメールアドレス宛に送信された電子メールにタスク情報が記述されておらず、スケジュールに関する情報も記述されていない場合、当該メールは、例えば単なる確認、御礼など、形式的な内容である可能性が高い。そこで、例えばサーバ1は、電子メールからタスク及びスケジュールに関する記述が認識されない場合(ステップS20:NO)、定型メッセージを自動返信するようにしてもよい。これにより、ユーザの利便性を高めることができる。
また、例えばサーバ1は、担当者に対するリマインド、催促等を行ってもよいことは勿論である。
以上より、本実施の形態1によれば、ユーザに関連するタスクを適切に分類して管理することができる。
また、本実施の形態1によれば、進捗報告の送受信を仲介することで、効率的なタスク管理を支援することができる。
また、本実施の形態1によれば、タスクの工数、リードタイム等、タスク実績の管理を行うことができる。
また、本実施の形態1によれば、複数のタスクを関連付けたプロジェクトのテンプレート情報を用いることで、漏れのないタスク管理を行うことができる。
また、本実施の形態1によれば、タスク管理の支援だけでなく、スケジュール管理の支援も行うことができる。
(実施の形態2)
本実施の形態では、サーバ1が管理しているタスク情報を基に、ユーザが会議で使用する文書を作成する形態について述べる。なお、実施の形態1と重複する内容については同一の符号を付して説明を省略する。
図13は、文書生成処理に関する説明図である。本実施の形態においてサーバ1は、ユーザが会議で使用するアジェンダ、及び会議内容を記録した議事録を作成する。
本実施の形態では、サーバ1が管理しているタスク情報を基に、ユーザが会議で使用する文書を作成する形態について述べる。なお、実施の形態1と重複する内容については同一の符号を付して説明を省略する。
図13は、文書生成処理に関する説明図である。本実施の形態においてサーバ1は、ユーザが会議で使用するアジェンダ、及び会議内容を記録した議事録を作成する。
具体的には、サーバ1は端末2より、タスクDB142に登録されている複数のタスクのうち、会議の議題に関連するタスクの選択を受け付ける。例えば図13右上に示すように、サーバ1は、プロジェクトのタスクを端末2に一覧表示し、一又は複数のタスクの選択をチェックボックス形式で受け付ける。
例えばサーバ1は、ユーザにより指定された属性を有するタスクをタスクDB142から検索し、端末2に一覧表示する。上述の如く、タスクの属性は、例えば担当者名、関係者名、プロジェクト名、顧客名、プロジェクトの属性(例えばプロジェクトで取り扱う商品等)などのように、タスクの分類を表す情報であり、タスクIDに紐付く関連情報である。実施の形態1で述べたように、サーバ1は、電子メールの内容を認識することで、又はタスク管理画面を介して設定入力を受け付けることで、上記の各種情報をタスクの属性情報としてタスクDB142に記憶しておく。
例えばサーバ1は、端末2を介して属性情報の指定を受け付け、指定された属性のタスクを検索して端末2に一覧表示する。例えば「プロジェクトA」というプロジェクト名の指定を受け付けた場合、サーバ1は、「プロジェクトA」の属性を有するタスク群をタスクDB142から検索する。そしてサーバ1は、図13に示すように、検索したタスク群を端末2に一覧表示する。
サーバ1は、端末2に一覧表示した複数のタスクから、会議の議題に用いるタスクの選択を受け付ける。サーバ1は、選択されたタスクに係るタスク情報を基に、会議の議題項目と、各項目に対応する入力欄とを含む文書ファイルを生成する。例えばサーバ1は、各タスクのタスク名を項目名とし、各項目に対応するテキスト入力欄を挿入した文書ファイルを生成する。これによりサーバ1は、会議のアジェンダに相当する文書を作成する。
サーバ1は、生成した文書ファイルを端末2に出力する。会議時にユーザは、端末2を操作して、各入力欄へのテキスト入力を行う。具体的には、ユーザは会議内の発言、決定事項、新たに挙がった課題など、議事内容を入力していく。
会議後、サーバ1は端末2からの操作に応じて、議事内容が入力された文書ファイルを議事録として保存する。例えばサーバ1は、当該文書ファイルをタスクに関連する添付ファイルとしてタスクDB142に記憶する。
また、サーバ1は、当該文書ファイルへの入力内容に応じて、タスクDB142を更新する。例えばサーバ1は、各議題項目の入力欄に入力されたテキストデータを参照し、対応するタスクの完了が承認されたか否かを判別する。サーバ1は、判別結果に応じてタスクの進捗履歴を更新し、タスクの完了を記録する。また、例えばサーバ1は、文書ファイルに入力された新たな課題を、新規のタスク情報としてタスクDB142に登録する。
上述の如く、サーバ1はタスク情報を基にアジェンダ及び議事録を作成し、議事内容を基にタスクDB142を更新していく。これにより、サーバ1は単にタスク情報を管理するだけでなく、タスク情報に基づく業務支援を行うことができる。
上述の如く、サーバ1はタスク情報を基にアジェンダ及び議事録を作成し、議事内容を基にタスクDB142を更新していく。これにより、サーバ1は単にタスク情報を管理するだけでなく、タスク情報に基づく業務支援を行うことができる。
図14は、文書生成処理の処理手順の一例を示すフローチャートである。図14に基づき、サーバ1が実行する文書生成処理の処理内容について説明する。
サーバ1の制御部11は、端末2を介して、タスクの属性情報の指定を受け付ける(ステップS201)。属性情報は、メッセージ情報から抽出された、又はユーザにより設定入力された情報であり、タスクの分類を表す情報である。タスクDB142には、タスクIDと対応付けて、タスクの属性情報が記憶されている。制御部11は、指定された属性情報に基づき、複数のタスク情報をタスクDB142から検索する(ステップS202)。
サーバ1の制御部11は、端末2を介して、タスクの属性情報の指定を受け付ける(ステップS201)。属性情報は、メッセージ情報から抽出された、又はユーザにより設定入力された情報であり、タスクの分類を表す情報である。タスクDB142には、タスクIDと対応付けて、タスクの属性情報が記憶されている。制御部11は、指定された属性情報に基づき、複数のタスク情報をタスクDB142から検索する(ステップS202)。
制御部11は、検索した複数のタスク情報を端末2に出力する(ステップS203)。そして制御部11は、出力した複数のタスク情報のうち、一又は複数のタスク情報を選択する選択入力を受け付ける(ステップS204)。制御部11は、選択されたタスク情報に基づき、議題項目と、議題項目に対応する入力欄とを含む文書ファイルを生成し、端末2に出力する(ステップS205)。上述の如く、当該文書ファイルはアジェンダに相当する文書である。例えば制御部11は、タスク名を議題項目とし、各項目に対応するテキスト入力欄を文書ファイルに挿入してアジェンダを生成する。
制御部11は、生成した文書ファイルへの情報入力を受け付ける(ステップS206)。例えば制御部11は、端末2を介して、文書ファイルへのテキスト入力を受け付ける。制御部11は、ユーザによりテキスト等が入力された文書ファイルを、議事録として保存する(ステップS207)。
制御部11は、文書ファイルへの入力内容に応じて、タスクDB142を更新する(ステップS208)。例えば制御部11は、文書ファイルに入力されたテキストデータから、既存タスクの進捗履歴の更新、新規タスクの登録等を行う。制御部11は、一連の処理を終了する。
なお、上記では属性情報に基づくタスクの検索機能をアジェンダ作成時に利用する場合について説明したが、検索機能の利用はアジェンダ作成時に限定されるものではなく、例えばプロジェクトの現状確認時など、その他の利用場面で検索可能としてもよいことは勿論である。すなわちサーバ1は、タスク属性を検索キーとして複数のタスク情報を一斉出力することができればよい。
以上より、本実施の形態2によれば、タスク情報を基にした文書作成を行うことで、さらなる業務の効率化を支援することができる。
(実施の形態3)
本実施の形態では、担当者が認識するタスクの難易度と、関係者が認識するタスクの難易度との差異を解消し、タスクの難易度の代表値を決定する形態について述べる。
図15は、タスクの難易度決定処理に関する説明図である。図15では、本実施の形態においてサーバ1が実行する処理内容について、概念的な説明図を図示している。
本実施の形態では、担当者が認識するタスクの難易度と、関係者が認識するタスクの難易度との差異を解消し、タスクの難易度の代表値を決定する形態について述べる。
図15は、タスクの難易度決定処理に関する説明図である。図15では、本実施の形態においてサーバ1が実行する処理内容について、概念的な説明図を図示している。
関係者から担当者へタスクが依頼された場合、当該タスクの難易度について、関係者と担当者との間で認識の差異が生じる場合がある。例えば図15に示すように、タスクを依頼する関係者から見れば難易度が低いが、実際にタスクを行う担当者から見れば難易度が高い場合がある。そこで本実施の形態では、関係者及び担当者の双方から難易度の設定入力を受け付け、設定された難易度の設定値を統計的に処理し、一般的な難易度に変換してユーザに提示する。
例えばサーバ1は、図7、図8等で図示したタスク管理画面において、1~5の五段階の数値でタスクの難易度の設定入力を受け付ける。サーバ1は、入力されたタスクの難易度をタスクDB142に記憶する。サーバ1は、各タスクについて担当者及び関係者の双方から難易度の設定入力を受け付け、タスクDB142に記憶していく。
サーバ1は、内容が同じタスク(例えばタスク名が類似するタスク)について、担当者及び関係者夫々の難易度の設定値をタスクDB142から読み出す。サーバ1は、読み出した担当者及び関係者夫々の難易度の設定値について、統計処理を行う。例えばサーバ1は、担当者たちが設定した難易度の分布、及び関係者たちが設定した難易度の分布がそれぞれ正規分布に従うと仮定し、全体として2つの正規分布が重ね合わされた二峰分布に従うと仮定して統計処理を行う。サーバ1は、担当者側の難易度の設定値、及び関係者側の難易度の設定値夫々について平均値、分散等を計算し、正規分布に係る近似曲線を導出する。
サーバ1は、統計処理による分析結果から、当該タスクの難易度の代表値を決定する。例えばサーバ1は、各正規分布の交点に位置する難易度を、当該タスクの難易度の代表値に決定する。すなわちサーバ1は、図15に示す分布図において、二峰分布の谷に相当する位置を代表値に決定する。例えばサーバ1は、図10で例示したタスク実績画面において、決定した難易度の代表値をタスクの一般的難易度としてユーザに提示する。ユーザは、提示された難易度を参考に、タスクの工数予測などを行うことができる。
なお、上記の難易度の代表値の決定方法は一例であって、本実施の形態はこれに限定されるものではない。例えばサーバ1は、担当者及び関係者が設定した難易度の中央値、平均値などを代表値としてもよい。
図16は、実施の形態3に係るタスク出力処理の処理手順の一例を示すフローチャートである。図16に基づき、本実施の形態に係るサーバ1の処理内容について説明する。
第1タスク情報を端末2に出力した後(ステップS42)、サーバ1の制御部11は、タスクの担当者による、第1タスク情報の難易度の設定入力を受け付け、タスクDB142に記憶する(ステップS301)。例えば制御部11は、五段階評価で各タスクの難易度の設定入力を受け付ける。制御部11は、担当者が設定した難易度の設定値をタスクDB142に記憶しておく。制御部11は、処理をステップS43に移行する。
第1タスク情報を端末2に出力した後(ステップS42)、サーバ1の制御部11は、タスクの担当者による、第1タスク情報の難易度の設定入力を受け付け、タスクDB142に記憶する(ステップS301)。例えば制御部11は、五段階評価で各タスクの難易度の設定入力を受け付ける。制御部11は、担当者が設定した難易度の設定値をタスクDB142に記憶しておく。制御部11は、処理をステップS43に移行する。
第2タスク情報を端末2に出力した後(ステップS47)、制御部11は、タスクの関係者による、第2タスク情報の難易度の設定入力を受け付け、タスクDB142に記憶する(ステップS302)。例えば制御部11は、ステップS301と同じく、五段階評価で各タスクの難易度の設定入力を受け付ける。制御部11は、関係者が設定した難易度の設定値をタスクDB142に記憶しておく。制御部11は、処理をステップS48に移行する。
ステップS54の処理を実行後、制御部11は、タスクDB142を参照し、担当者及び関係者の双方が設定した難易度の設定値から、タスクの難易度の代表値を決定する(ステップS303)。例えば制御部11は、担当者の設定値、及び関係者の設定値の双方が正規分布に従うと仮定し、全体として二峰分布に従うと仮定して統計処理を行い、難易度の代表値を決定する。制御部11は、決定した難易度の代表値を含むタスク実績画面を生成し、端末2に出力する(ステップS304)。制御部11は、処理をステップS56に移行する。
以上より、本実施の形態3によれば、タスクの難易度の代表値を定めることで、担当者と関係者との間の認識の差異の解消、タスクの工数予測等に役立てることができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、請求の範囲によって示され、請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
1 サーバ(情報処理装置)
11 制御部
12 記憶部
P プログラム
13 通信部
14 大容量記憶装置
141 プロジェクトDB
142 タスクDB
143 ユーザDB
2 端末
3 メールサーバ
4 スケジュールサーバ
11 制御部
12 記憶部
P プログラム
13 通信部
14 大容量記憶装置
141 プロジェクトDB
142 タスクDB
143 ユーザDB
2 端末
3 メールサーバ
4 スケジュールサーバ
Claims (10)
- ユーザのメッセージ情報を取得する取得部と、
取得した前記メッセージ情報から、前記ユーザに関連するタスク情報を抽出する抽出部と、
抽出した前記タスク情報から、タスクの担当者及び関係者を識別する識別部と、
前記タスク情報を、前記ユーザが前記担当者である第1タスク情報、又は前記ユーザが前記関係者である第2タスク情報に分類する分類部と、
分類した前記第1又は第2タスク情報をデータベースに登録する登録部と、
該データベースを参照して、前記第1又は第2タスク情報を出力する出力部と
を備えることを特徴とする情報処理装置。 - 前記タスクの進捗報告を取得する第2取得部を備え、
前記進捗報告を取得した場合、前記出力部は、該進捗報告を前記関係者に対して出力し、
出力した前記進捗報告に対して、前記タスクの完了を承認するか否かの選択を受け付ける承認受付部と、
前記タスクの完了が承認されなかった場合、前記担当者に対する通知を行う通知部と
を備えることを特徴とする請求項1に記載の情報処理装置。 - 前記進捗報告を基に、前記タスクの進捗履歴を記録する記録部と、
該進捗履歴を参照して、前記タスクの実施効率を計算する計算部と
を備えることを特徴とする請求項2に記載の情報処理装置。 - 複数の前記タスク情報を関連付けたテンプレート情報を記憶する記憶部を備え、
前記登録部は、前記テンプレート情報の指定を受け付けることで、前記複数のタスク情報を登録する
ことを特徴とする請求項1~3のいずれか1項に記載の情報処理装置。 - 前記抽出部はさらに、前記メッセージ情報から、前記ユーザのスケジュールの調整依頼に係る情報を抽出し、
前記ユーザのスケジュールを管理するスケジューラを参照して、前記ユーザが対応可能な日程候補を特定する特定部と、
特定した前記日程候補におけるスケジュールを前記スケジューラに仮登録する第2登録部と
を備えることを特徴とする請求項1~4のいずれか1項に記載の情報処理装置。 - 前記タスクの属性情報に基づき、複数の前記タスク情報を前記データベースから検索する検索部を備え、
前記出力部は、検索された前記複数のタスク情報を出力する
ことを特徴とする請求項1~5のいずれか1項に記載の情報処理装置。 - 前記データベースに登録されている前記タスク情報の選択を受け付けるタスク選択部と、
選択された前記タスク情報を基に、議題項目と、該議題項目に対応する入力欄とを含む文書ファイルを生成する文書生成部とを備え、
前記出力部は、前記文書ファイルを出力し、
出力した前記文書ファイルへの入力内容に応じて、前記データベースを更新する更新部を備える
ことを特徴とする請求項1~6のいずれか1項に記載の情報処理装置。 - 前記担当者及び関係者の双方から、前記タスクの難易度の設定入力を受け付ける難易度受付部と、
受け付けた前記難易度の設定値を記憶する難易度記憶部と、
該難易度記憶部を参照し、前記タスクの難易度の代表値を決定する決定部と
を備えることを特徴とする請求項1~7のいずれか1項に記載の情報処理装置。 - 前記メッセージ情報は、前記ユーザから送信された、又は前記ユーザ宛に送信された電子メールであり、
前記識別部は、前記電子メールのヘッダ情報又は本文から前記担当者及び関係者を識別する
ことを特徴とする請求項1~8のいずれか1項に記載の情報処理装置。 - ユーザのメッセージ情報を取得し、
取得した前記メッセージ情報から、前記ユーザに関連するタスク情報を抽出し、
抽出した前記タスク情報から、タスクの担当者及び関係者を識別し、
前記タスク情報を、前記ユーザが前記担当者である第1タスク情報、又は前記ユーザが前記関係者である第2タスク情報に分類し、
分類した前記第1又は第2タスク情報をデータベースに登録し、
該データベースを参照して、前記第1又は第2タスク情報を出力する
処理をコンピュータに実行させることを特徴とするプログラム。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017-134806 | 2017-07-10 | ||
JP2017134806A JP6535863B2 (ja) | 2017-07-10 | 2017-07-10 | 情報処理装置及びプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2019012781A1 true WO2019012781A1 (ja) | 2019-01-17 |
Family
ID=65002381
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2018/016711 WO2019012781A1 (ja) | 2017-07-10 | 2018-04-25 | 情報処理装置及びプログラム |
Country Status (2)
Country | Link |
---|---|
JP (1) | JP6535863B2 (ja) |
WO (1) | WO2019012781A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114240356A (zh) * | 2021-12-13 | 2022-03-25 | 中交第一航务工程局有限公司 | 一种项目管理平台 |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7017597B2 (ja) * | 2020-03-31 | 2022-02-08 | フリー株式会社 | 情報処理装置、方法及びプログラム |
JP7354392B1 (ja) | 2022-10-20 | 2023-10-02 | ヤフー株式会社 | 情報処理装置、情報処理方法、及び情報処理プログラム |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2003020120A (ja) * | 2001-07-10 | 2003-01-21 | Nippon Telegr & Teleph Corp <Ntt> | 宅配サービス支援システム及びその方法 |
JP2006163509A (ja) * | 2004-12-02 | 2006-06-22 | Olympus Corp | 障害通知システム |
JP2008217719A (ja) * | 2007-03-07 | 2008-09-18 | Ricoh Co Ltd | ワークフロー管理システム、管理サーバ、担当者端末、ワークフロー管理システムの進捗管理方法、管理サーバの進捗管理方法、及び管理サーバの進捗管理プログラム |
JP2009048580A (ja) * | 2007-08-23 | 2009-03-05 | Hitachi-Ge Nuclear Energy Ltd | プロジェクト計画方法、プロジェクト計画プログラム、および、プロジェクト計画システム |
WO2014208139A1 (ja) * | 2013-06-28 | 2014-12-31 | 日本電気株式会社 | 異常検出装置、制御方法、及びプログラム |
JP2016219881A (ja) * | 2015-05-14 | 2016-12-22 | コニカミノルタ株式会社 | ジョブ処理装置管理サーバプログラム |
JP2017041049A (ja) * | 2015-08-19 | 2017-02-23 | カシオ計算機株式会社 | 作業管理装置及びプログラム |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3956601B2 (ja) * | 2000-10-06 | 2007-08-08 | 富士ゼロックス株式会社 | 買い物支援サーバ及び買い物支援方法 |
JP2006190177A (ja) * | 2005-01-07 | 2006-07-20 | Chugoku Electric Power Co Inc:The | 電子メールシステムを用いた回答期限管理方法 |
-
2017
- 2017-07-10 JP JP2017134806A patent/JP6535863B2/ja not_active Expired - Fee Related
-
2018
- 2018-04-25 WO PCT/JP2018/016711 patent/WO2019012781A1/ja active Application Filing
Patent Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2003020120A (ja) * | 2001-07-10 | 2003-01-21 | Nippon Telegr & Teleph Corp <Ntt> | 宅配サービス支援システム及びその方法 |
JP2006163509A (ja) * | 2004-12-02 | 2006-06-22 | Olympus Corp | 障害通知システム |
JP2008217719A (ja) * | 2007-03-07 | 2008-09-18 | Ricoh Co Ltd | ワークフロー管理システム、管理サーバ、担当者端末、ワークフロー管理システムの進捗管理方法、管理サーバの進捗管理方法、及び管理サーバの進捗管理プログラム |
JP2009048580A (ja) * | 2007-08-23 | 2009-03-05 | Hitachi-Ge Nuclear Energy Ltd | プロジェクト計画方法、プロジェクト計画プログラム、および、プロジェクト計画システム |
WO2014208139A1 (ja) * | 2013-06-28 | 2014-12-31 | 日本電気株式会社 | 異常検出装置、制御方法、及びプログラム |
JP2016219881A (ja) * | 2015-05-14 | 2016-12-22 | コニカミノルタ株式会社 | ジョブ処理装置管理サーバプログラム |
JP2017041049A (ja) * | 2015-08-19 | 2017-02-23 | カシオ計算機株式会社 | 作業管理装置及びプログラム |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114240356A (zh) * | 2021-12-13 | 2022-03-25 | 中交第一航务工程局有限公司 | 一种项目管理平台 |
Also Published As
Publication number | Publication date |
---|---|
JP6535863B2 (ja) | 2019-07-03 |
JP2019016280A (ja) | 2019-01-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11720834B2 (en) | Talent platform exchange and recruiter matching system | |
US8060532B2 (en) | Determining suitability of entity to provide products or services based on factors of acquisition context | |
US20140278406A1 (en) | Obtaining data from unstructured data for a structured data collection | |
US8676792B1 (en) | Method and system for an invitation triggered automated search | |
CN109584094B (zh) | 一种人际路径快速定位***、方法及介质 | |
US20190042950A1 (en) | Learning computing activities and relationships using graphs | |
US20130232204A1 (en) | Identifying and processing previously sent and received messages | |
WO2021062920A1 (zh) | 信息处理方法、装置及计算机可读存储介质 | |
US10621535B1 (en) | Method and apparatus to onboard resources | |
JP6535863B2 (ja) | 情報処理装置及びプログラム | |
US20200104800A1 (en) | Talent platform exchange and rating system | |
JP2011191964A (ja) | ワークフロー管理方法、プログラムおよびワークフロー管理装置 | |
JP3872689B2 (ja) | セキュリティポリシーの作成支援システムおよびセキュリティ対策決定支援システム | |
CN111027838A (zh) | 一种众包任务推送方法、装置、设备及其存储介质 | |
US20190042951A1 (en) | Analysis of computing activities using graph data structures | |
US8504412B1 (en) | Audit automation with survey and test plan | |
JP4233472B2 (ja) | 営業支援装置 | |
Van der Aalst et al. | Emailanalyzer: an e-mail mining plug-in for the prom framework | |
JP2020004161A (ja) | 審査支援装置、審査支援方法、およびサービス提供方法 | |
JP2010191808A (ja) | スケジューリングプログラム、スケジューリング方法、及びスケジューリング装置 | |
CN113761127A (zh) | 一种任务处理方法、装置、电子设备和存储介质 | |
KR101264289B1 (ko) | 기업의 발명 신고 및 관리 시스템 | |
JP5656254B2 (ja) | コミュニケーションイベントログ作成システム、コミュニケーションイベントログ作成方法およびプログラム | |
JP2008234013A (ja) | 問い合わせ管理システム及び問い合わせ管理プログラム | |
US20190304040A1 (en) | System and Method for Vetting Potential Jurors |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 18831120 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 18831120 Country of ref document: EP Kind code of ref document: A1 |