Project implementation system, task execution information recording device, and task execution information recording method

Abstract

[Problem] To collect and record the execution conditions of tasks in a project, in a manner that guarantees veracity. [Solution] When a new task is designated, the task content of the task is acquired as task execution information, during execution of the task, an intermediate deliverable that was produced by executing the task is acquired as task execution information, and when the task is completed, a final deliverable that was produced by completing the task is acquired as task execution information. These items of task execution information are recorded in a manner that maintains the order in which the items of task execution information were created or acquired. Thus, because information regarding the ongoing progress of implementing the task is included and recorded, if an attempt is made to record task execution information that differs from the truth, a discrepancy is produced between the same and other task execution information. Consequently, by doing so, the execution condition of the task can be collected and recorded in a manner that guarantees veracity.

Description

Project execution system, task execution information recording device, task execution information recording method

[0001] This invention relates to a technology for carrying out a project by having multiple computer-equipped nodes communicate with each other and by having the nodes share and execute multiple tasks that make up the project.

[0002] In the business world, a "project" refers to a task with clearly defined objectives. When starting a project, it's common to plan several more specific tasks (called "tasks") by considering what needs to be done and by when to achieve the set objectives. The project is then completed by executing these tasks. It's also common for multiple smaller tasks to be necessary to complete a single task. The relationship between the original task and its smaller tasks is the same as the relationship between a project and its tasks. Therefore, in this specification, we will consider a project to be a type of task, and refer to the largest, original task as the project itself.

[0003] The success or failure of a project largely depends on whether all tasks are executed according to plan. Therefore, if a task fails to be executed as planned, it is necessary to detect this as quickly as possible and take some kind of action. To this end, various techniques have been proposed for monitoring the progress of multiple tasks executed in parallel within a project (for example, Patent Document 1). Furthermore, a technique has been proposed for creating execution plans for multiple tasks in a way that the execution of one task does not interfere with the execution of other tasks (for example, Patent Document 2). The method of managing a project to ensure its efficient execution by utilizing these techniques is called "project management."

[0004] However, these project management methods focus on how to efficiently execute the tasks that are already determined to be carried out within the project. However, depending on how the project is carried out, there is a possibility that multiple tasks can be made unnecessary, and as a result, the efficiency of the project can be significantly improved. Therefore, in order to efficiently execute a project, it is considered necessary to examine not only how to efficiently execute the multiple tasks that are already determined, but also the quality of the "way of proceeding with the project" that has given rise to those tasks.

[0005] Japanese Patent Application Laid-Open No. 2010-257327, Japanese Patent Application Laid-Open No. 2005-284386

[0006] However, it has been extremely difficult to examine the quality of the way of proceeding with a project with the conventional project management methods proposed so far. The reason is considered as follows. First, in order to examine the quality of the way of proceeding with a project, it is necessary to collect information on the execution status of the tasks executed within the project. However, the information on the execution status of the tasks is directly related to the evaluation of the task-related persons (task executors, task instructors, etc.). For this reason, even if an attempt is made to collect information on the execution status, various changes due to the various motives of the task-related persons often mix in during the process. As a result, even if information on the execution status of the tasks is collected, it is impossible to determine whether or not the information has the authenticity worthy of consideration. As a result, it is considered that it has been extremely difficult (virtually impossible) to examine the quality of the way of proceeding with the project.

[0007] The present invention has been made to solve the above-described problems of the conventional technology, and an object thereof is to provide a technology capable of collecting and recording information on the execution status of tasks executed within a project in a state where sufficient authenticity is ensured.

[0008] To solve the above-mentioned problems, the project execution system of the present invention employs the following configuration: a project execution system in which a plurality of nodes equipped with computers are connected to each other in a manner that enables communication, and in which a plurality of tasks for executing a project are divided and executed by the plurality of nodes, wherein when a new task is instructed by setting the objective of the task and the executor of the task at any of the plurality of nodes, a task content acquisition unit acquires the objective of the task and the executor of the task as task content representing the content of the task; from the time the task is started by the executor of the task until the task is completed, an intermediate deliverable, which is the deliverable of the task generated during the execution of the task, is acquired from the node operated by the executor of the task, and after the completion of the task, an end product, which is the deliverable of the task generated by the completion of the task, is acquired from the node operated by the executor of the task; and a task execution information recording unit records the task execution information, which is information of the task content, the intermediate deliverable, or the final deliverable, in a manner that preserves the order in which the task execution information was created or acquired.

[0009] In the project execution system of the present invention, when a new task is specified, the task details for that task are acquired as task execution information. During the execution of the task, intermediate deliverables generated by the task are acquired as task execution information, and when the task is completed, the final deliverable generated by the completion of the task is acquired as task execution information. This task execution information is recorded while preserving the order in which the task execution information was created or acquired.

[0010] This ensures that task execution information, including not only the start and results of tasks but also the progress of tasks in progress, is recorded while maintaining the order in which it was created or acquired. Therefore, even if those involved in a task attempt to record task execution information that is not factual, inconsistencies will arise between that information and the earlier and later task execution information. Consequently, if there are no inconsistencies among all the recorded task execution information, it can be assumed that that information represents the true circumstances under which the task was executed. As a result, it becomes possible to collect and record information about the execution status of tasks performed within a project with sufficient assurance of truthfulness.

[0011] Furthermore, in the project execution system of the present invention described above, when acquiring the task content of a task, information on the date and time the task was assigned may also be acquired. In addition, when acquiring the deliverables of a task (intermediate deliverables or final deliverables), information on the date and time the deliverables were generated or acquired may also be acquired. When recording task execution information, the task execution information for the task content may be recorded together with the date and time the task was assigned, and the task execution information for the deliverables may be recorded together with the date and time the deliverables were generated or acquired, thereby maintaining the order in which the task execution information was created or acquired.

[0012] This date and time information can be easily obtained, and furthermore, by recording task execution information along with this date and time information, it is possible to record task execution information while easily preserving the order in which the task execution information was created or obtained. In addition, when analyzing or interpreting the task execution information at a later date, the date and time information of when the task execution information was created or obtained can be used, making it possible to obtain more useful insights.

[0013] Alternatively, in the project execution system of the present invention described above, task content and deliverables (intermediate deliverables and final deliverables) may be acquired as task execution information each time predetermined acquisition conditions are met. When acquiring task content as task execution information, the task content and the date and time the task was assigned are acquired. When acquiring deliverables (intermediate deliverables or final deliverables) as task execution information, the deliverables and the date and time the deliverables were created are acquired. Furthermore, when recording task execution information, task execution information indicating task content may be recorded together with the date and time the task was assigned, and task execution information indicating deliverables may be recorded together with the date and time the deliverables were created.

[0014] This approach allows task execution information to be retrieved only when the specified acquisition conditions are met. For example, task execution information only needs to be retrieved at a specified time on a business day, or after a specified period of time has elapsed, eliminating the need to keep the task execution information constantly available. This reduces the processing burden required to retrieve task execution information.

[0015] Furthermore, the present invention can also be understood as a task execution information recording device or task execution information recording method that is applied to a project execution system in which tasks are executed on multiple nodes and which acquires and stores task execution information of tasks. That is, a task execution information recording device of the present invention in such an embodiment is applied to a project execution system in which multiple nodes equipped with computers are connected to each other in a manner that enables communication, and which divides and executes multiple tasks for carrying out a project among the multiple nodes and which acquires and stores task execution information that is information relating to the execution status of multiple tasks, and comprises: a task content acquisition unit that, when a new task is instructed by setting the objective of the task and the executor of the task on any of the multiple nodes, acquires the objective of the task and the executor of the task as task content representing the content of the task; an output acquisition unit that, from the time the task is started by the executor of the task until the task is completed, acquires intermediate output, which is the output of the task generated during the execution of the task, from the node operated by the executor of the task, and after the completion of the task, acquires final output, which is the output of the task generated by the completion of the task, from the node operated by the executor of the task; The system is characterized by comprising a task execution information recording unit that, when task execution information, which is information of the task content, the intermediate deliverable, or the final deliverable, is acquired, records the task execution information while preserving the order in which the task execution information was created or acquired.

[0016] Alternatively, the task execution information recording method of the present invention is applied to a project execution system in which a plurality of nodes equipped with computers are connected to each other in a communicative manner, and a plurality of tasks for carrying out a project are divided among the plurality of nodes to be carried out, and the task execution information recording method of the present invention is applied to a project execution system in which a plurality of nodes equipped with computers are connected to each other in a communicative manner, and the plurality of nodes carry out a task execution information recording method that realizes the process of acquiring and storing task execution information which is information relating to the execution status of a plurality of tasks, the method comprising: a task content acquisition step in which, when a new task is instructed by setting the objective of the task and the executor of the task on any of the plurality of nodes, the objective of the task and the executor of the task are acquired as task content representing the content of the task; an deliverable acquisition step in which, from the time the task is started by the executor of the task until the task is completed, intermediate deliverables which are deliverables of the task generated during the execution of the task are acquired from the node operated by the executor of the task, and after the completion of the task, final deliverables which are deliverables of the task generated by the completion of the task are acquired from the node operated by the executor of the task, The system is characterized by comprising a task execution information recording step, in which, when task execution information, which is information of the task content, the intermediate deliverable, or the final deliverable, is acquired, the task execution information is recorded while preserving the order in which the task execution information was created or acquired.

[0017] In the task execution information recording device or method of the present invention, task execution information regarding the start and results of tasks, as well as task execution information regarding the progress of tasks in progress, are recorded while maintaining the order in which the task execution information was created or acquired. Therefore, it becomes possible to collect and record information about the execution status of tasks performed within a project while ensuring sufficient truthfulness.

[0018] This is an explanatory diagram showing an overview of the project execution system 1 of this embodiment. This is an explanatory diagram illustrating the chain of command of an organization executing a project. This is an explanatory diagram illustrating how multiple tasks are executed in parallel within an organization executing a project. This is an explanatory diagram illustrating how various task deliverables are generated as the project is executed. This is an explanatory diagram of the task execution information recording device 10 applied to the project execution system 1 of this embodiment. This is a flowchart of the task execution information recording process performed by the task execution information recording device 10 of this embodiment. This is an explanatory diagram illustrating how predetermined items for creating header information are set on the screen of node 2 when transmitting task execution information. This is an explanatory diagram illustrating the data structure of the task execution information 20 transmitted by node 2. This is an explanatory diagram illustrating block data generated in the task execution information recording process. This is an explanatory diagram showing how block data 30 transmitted from the task execution information recording device 10 is recorded by computer nodes 51a to 51d. This is a flowchart of the task execution information recording process performed by a modified task execution information recording device 10.

[0019] A. Project Execution System 1: Figure 1 is an explanatory diagram showing an overview of the project execution system 1 of this embodiment. The project execution system 1 is formed by multiple nodes 2 equipped with computers being connected to each other via wired or wireless communication lines 3. These nodes 2 are capable of dividing and executing multiple tasks, and as a result, the project is executed by the project execution system 1. Various terminal devices such as desktop computers, laptop computers, and tablet computers can be used as nodes 2.

[0020] The communication line 3 is connected to multiple nodes 2, as well as a task execution information recording device 10. The task execution information recording device 10 is also equipped with a computer and can communicate with multiple nodes 2 via the communication line 3. The task execution information recording device 10 acquires information about various deliverables (including intermediate deliverables) generated when each node 2 executes a task, and the content of the task instructed to each node 2 (hereinafter referred to as "task content"). The information about various deliverables and task content acquired by the task execution information recording device 10 from the nodes 2 will be referred to as "task execution information" below. When predetermined conditions are met, the task execution information recording device 10 generates block data, which will be described later, by combining the acquired task execution information and transmits it to a computer node 51a outside the project execution system 1.

[0021] Computer node 51a, together with the other computer nodes 51b to 51d, forms a blockchain network 50. Upon receiving block data from the task execution information recording device 10, it transfers the data to computer nodes 51b to 51d. Each of the computer nodes 51a to 51d then records the block data in a manner that makes tampering difficult. In this embodiment, it is explained that the block data is recorded on the computer nodes 51a to 51d of the blockchain network 50. However, an external storage device may be connected to the task execution information recording device 10 or the communication line 3, and when the task execution information recording device 10 generates block data, it may be recorded on the external storage device.

[0022] In the following, the operation of the task execution information recording device 10 of this embodiment, after acquiring task execution information and generating block data, and then recording the block data, will be explained using a project carried out by a fictional organization as an example.

[0023] Figure 2 is an explanatory diagram illustrating the chain of command when a fictional organization carries out a project. The project is initiated when President Pr designates one of the executives as Executive Director MD and directs the project. Each department head, such as Development Manager D(d), Purchasing Manager D(p), Manufacturing Manager D(m), and Sales Manager D(s), will be under the command of Executive Director MD for this project. Development Manager D(d) has two section chiefs under him, Section Chief 1 M1 and Section Chief 2 M2. Section Chief 1 M1 has three staff members under him (Staff Mb1, Staff Mb2, Staff Mb3). Section Chief 2 M2 also has three staff members under him (Staff Mb4, Staff Mb5, Staff Mb6). Furthermore, although not shown in Figure 2, there are multiple section managers under Purchasing Manager D(p), Manufacturing Manager D(m), and Sales Manager D(s), and each of these section managers also has multiple staff members under their respective sections.

[0024] Figure 3 is an illustrative diagram illustrating how a project is carried out in the fictional organization described above. In Figure 3, the tasks are executed over time for the President (Pr), the Executive Director (MD), the Development Manager (D(d)), the Purchasing Manager (D(p)), the Manufacturing Manager (D(m)), the Sales Manager (D(s)), the First Section Chief (M1), the Second Section Chief (M2), and the Person in Charge (Mb1, Mb2, and Mb3). The project is started when the President (Pr) designates the Executive Director (MD) from among several executives and instructs them to start the project. The project start instruction specifies the project's goals and the deadline for achieving those goals. Upon receiving this instruction, the Executive Director (MD) begins their tasks to carry out the project. In Figure 3, the solid line extending downward from the position of the Executive Director (MD) becomes a thin, vertical rectangle from the point when the project start instruction is received, indicating that the Executive Director (MD)'s tasks have begun.

[0025] Upon receiving the project commencement order, the Executive Director (MD) in charge considers the tasks that each department, such as the development, purchasing, manufacturing, and sales departments, should perform in order to carry out the project. He then issues a meeting invitation to the Development Manager D(d), Purchasing Manager D(p), Manufacturing Manager D(m), and Sales Manager D(s). The arrows pointing from the Executive Director (MD) to the Development Manager D(d), Purchasing Manager D(p), Manufacturing Manager D(m), and Sales Manager D(s) indicate that the Executive Director (MD) has issued meeting invitations to each department head. After the meeting, based on the results, the Executive Director (MD) first issues an order to the Development Manager D(d) to commence development. This order includes the goals and deadlines to be achieved, and serves as a task instruction for the Development Manager D(d).

[0026] Development Manager D(d) considers what each of his subordinate departments should do to achieve the tasks assigned by Executive Director MD, and then issues a meeting invitation to Section Chief M1 and Section Chief M2. After the meeting, based on the results, Development Manager D(d) issues task instructions to Section Chief M1 and Section Chief M2, specifying the goals and deadlines they should each achieve. Section Chief M1, upon receiving the instructions, decides how to divide the tasks among his three subordinates to achieve the assigned tasks and issues task instructions to subordinates Mb1, Mb2, and Mb3. Furthermore, if the tasks assigned by Development Manager D(d) cannot be achieved with a single instruction, Section Chief M1 checks the progress of each subordinate's tasks and issues additional task instructions to each subordinate at an appropriate time. Although not shown in Figure 3, Section Chief M2 similarly determines the division of tasks among his three subordinates and issues task instructions to Mb4, Mb5, and Mb6. Additionally, Development Manager D(d) issues additional tasks to each section chief as needed. In this way, the development department starts multiple project-related tasks before other departments.

[0027] Furthermore, the Executive Director (MD) in charge checks the progress of tasks in the development department and, at an appropriate time, instructs the Purchasing Manager (D(p)) to begin selecting suppliers. This instruction also includes goals and deadlines to be achieved and constitutes a task instruction for Purchasing Manager (D(p)). Upon receiving the instruction, Purchasing Manager (D(p)) instructs each of his subordinate section managers to perform the task, similar to the Development Manager (D(d)) described above, thus initiating project-related tasks in the purchasing department as well. In addition, the Executive Director (MD) in charge checks the progress of tasks in both the development and purchasing departments and, at an appropriate time, instructs the Manufacturing Manager (D(m)) to begin preparations for manufacturing and the Sales Manager (D(s)) to begin preparations for sales. These instructions also include goals and deadlines to be achieved and constitute task instructions for Manufacturing Manager (D(m)) and Sales Manager (D(s)). As a result, project-related tasks are also initiated in the manufacturing and sales departments.

[0028] As explained above, when a project is carried out, various tasks are assigned to individuals at different levels of responsibility, such as executives, department heads, and section chiefs, and these assigned tasks are executed in parallel. As each task is completed, various deliverables are generated.

[0029] Figure 4 is an illustrative diagram illustrating how various task deliverables are generated within a project. In Figure 4, the long, thin white arrows extending from left to right represent the passage of time. The black arrows extending downwards from above the arrows representing the passage of time (and therefore towards the arrows) indicate that a task was assigned at that time. Furthermore, the white arrows extending downwards from below the arrows representing the passage of time (and therefore away from the arrows representing time) indicate that a deliverable was generated as a result of the task being executed. Among these arrows representing the generation of deliverables, solid arrows indicate that the final deliverable has been generated, while dashed arrows indicate that an intermediate deliverable has been generated.

[0030] At the start of the project, the President (PR) instructs the Executive Director (MD) to begin the project. The black arrow labeled "PR → MD Project Start" in Figure 4 indicates that the project has been instructed to begin. This instruction clearly outlines the project's objectives, deadlines, and the people responsible for carrying it out. The Executive Director (MD), upon receiving the instruction, begins considering how to achieve the instructed objectives, and various review documents are created during this process. Once a general plan for carrying out the project has been decided, preparations begin for a meeting with the Development Manager (D(d)) and other department heads, and various meeting documents are created during this process. These review documents and meeting documents are intermediate deliverables generated during the execution of the task (in this case, the project) instructed by the President (PR). In Figure 4, the dashed arrows labeled "Review Documents" or "Meeting Documents" indicate that these intermediate deliverables have been generated.

[0031] In Figure 4, only one dashed arrow labeled "Review Materials" is shown. This is to avoid making the figure difficult to read and does not mean that only one review material was generated. In reality, multiple review materials are usually generated at different times. The same applies to the dashed arrow labeled "Meeting Materials." Thus, in Figure 4, only one white downward-pointing arrow shown with a dashed line is shown. This is because, although multiple arrows should actually be shown, one arrow may be used to represent multiple arrows in order to avoid making the figure difficult to read. Similarly, the white downward-pointing arrows shown with solid lines may also represent multiple arrows. Furthermore, review materials and meeting materials do not necessarily need to be completed; materials still under development can also be considered intermediate deliverables.

[0032] Next, the Managing Director (MD) issues a meeting invitation to each department head. Since the meeting invitation clearly specifies the purpose, date, time, and participants of the meeting, it can be considered an instruction for the task of "holding a meeting." In Figure 4, the black arrow labeled "MD → Each Department Head (Meeting Invitation)" indicates that the instruction for the task of holding a meeting has been issued. Following the meeting invitation, the meeting is held, and then the meeting minutes are created. These minutes are the final deliverable produced as a result of the meeting task. In Figure 4, the solid arrow labeled "Meeting Minutes" indicates that the final deliverable, the meeting minutes, has been produced. Note that, as with this solid arrow, there are cases where a single arrow represents multiple arrows indicating the production of a final deliverable.

[0033] The executive in charge, MD, issues an instruction to Development Manager D(d) to begin development, based on the decisions made in the meeting. This instruction is also an instruction for the task "development," and information such as the development goals, deadlines, and executors is clearly stated. The black arrow labeled "MD → D(d) (development)" in Figure 4 indicates that an instruction for the task "development" has been issued. Note that task instructions may be issued in multiple parts, or supplementary materials may be provided later. Ideally, in such cases, multiple black arrows representing task instructions should be displayed, but in Figure 4, to avoid making the display difficult to read, a single black arrow may be used to represent multiple arrows.

[0034] Upon receiving the instructions, Development Manager D(d) considers how to proceed with development and then convenes a meeting with his subordinates, Section Chief M1 and Section Chief M2. During this process, various review materials and meeting materials are created. These review materials and meeting materials are also intermediate deliverables generated in the process of Development Manager D(d) carrying out the tasks instructed by Executive Director MD. Furthermore, the convening of the meeting is an instruction for the task "Meeting," and the black arrow in Figure 4 labeled "D(d) → M1, M2 (Meeting Convening)" indicates that the instruction for the task "Meeting Convening" has been issued. Following the convening of the meeting, the task of "Meeting" is executed, and as a result of the meeting, the final deliverable, the meeting minutes, is generated.

[0035] Next, Development Manager D(d) gives task instructions to Section Chief M1, and then to Section Chief M2, based on what was decided in the meeting. The black arrows labeled "D(d)→M1" and "D(d)→M2" in Figure 4 indicate that task instructions were given to Section Chief M1 and Section Chief M2, respectively.

[0036] Then, Section Chief M1, having received the task instructions, gives the instructions to his subordinates Mb1, Mb2, and Mb3, and Section Chief M2 also gives the instructions to his subordinates Mb4, Mb5, and Mb6. In Figure 4, the black arrows labeled "M1→Mb1", "M1→Mb2", and "M1→Mb3" indicate that Section Chief M1 gave the task instructions to the three subordinates Mb1 to Mb3. Similarly, the black arrows labeled "M2→Mb4", "M2→Mb5", and "M2→Mb6" indicate that Section Chief M2 gave the task instructions to the three subordinates Mb4 to Mb6.

[0037] The team members Mb1 to Mb3, who have been assigned tasks by Section Chief M1, execute their respective tasks, generating intermediate deliverables such as various review materials and interim reports in the process. The dashed arrows labeled "Mb1 (Interim)," "Mb2 (Interim)," and "Mb3 (Interim)" in Figure 4 indicate that the respective intermediate deliverables have been generated by team members Mb1 to Mb3. Once team members Mb1 to Mb3 have completed their respective tasks, the final deliverables for each task (various review materials and completion reports, etc.) are generated. The solid arrows labeled "Mb1 (Final)," "Mb2 (Final)," and "Mb3 (Final)" in Figure 4 indicate that the respective final deliverables have been generated by team members Mb1 to Mb3. Section Chief M1 also monitors the progress of the tasks of team members Mb1 to Mb3 and issues instructions for additional tasks before each task is completed.

[0038] Similarly, for the personnel Mb4 to Mb6, who were assigned tasks by Section Chief M2, intermediate products are generated during the process of executing each task, and the final product is generated upon completion of each task. Furthermore, Section Chief M2 also monitors the progress of the tasks of personnel Mb4 to Mb6 and issues instructions for additional tasks before each task is completed.

[0039] Furthermore, Development Manager D(d) also monitors the progress of the tasks he has instructed Section Chief M1 and Section Chief M2, and before each task is completed, he issues additional task instructions to Section Chief M1 or Section Chief M2. In this way, the development department is able to execute the tasks instructed by the executive in charge, MD, ahead of other departments.

[0040] The executive in charge, MD, monitors the progress of tasks in the development department and, at the appropriate time, instructs the purchasing manager, D(p), to begin selecting suppliers. This instruction is also an instruction for the "purchasing" task, and the black arrow labeled "MD → D(p) (purchasing)" in Figure 4 indicates that the instruction for the purchasing task has been issued.

[0041] Upon receiving instructions, Purchasing Manager D(p) begins the assigned task in the same manner as Development Manager D(d) mentioned above. That is, he considers how to proceed with the task, convenes a meeting with each of his subordinate section chiefs, and holds the meeting. In this process, various intermediate deliverables such as review materials and meeting materials are generated, and after the meeting concludes, the final deliverable, the meeting minutes, is produced. Then, Purchasing Manager D(p) instructs each of his subordinate section chiefs on the task, and each section chief further instructs the task to their subordinate personnel, thus enabling the task assigned by the Executive Director (MD) to be executed in the Purchasing Department as well. Similarly, in the Manufacturing and Sales Departments, the Executive Director (MD) in charge instructs the Manufacturing Manager D(m) and Sales Manager D(s) on the task, and the respective tasks begin.

[0042] As explained above, when a project is carried out, various tasks are assigned by various positions such as executives, department heads, and section chiefs, and multiple assigned tasks are executed in parallel by various positions such as department heads, section chiefs, and team members. Therefore, within a project in progress, various types of information (i.e., task execution information) are generated, such as information describing the content of the task to be started, intermediate deliverables obtained by executing the task, and final deliverables obtained by completing the task. Furthermore, it is rare for each task to be executed completely independently; many tasks cannot be started until other tasks are completed, or they need to be executed in coordination with other tasks. In addition, it is not uncommon for multiple tasks to be related across multiple departments. Therefore, within a project in progress, various types of task execution information are exchanged across departmental boundaries.

[0043] The task execution information recording device 10 in this embodiment acquires and records various task execution information exchanged within a project in progress in chronological order. By analyzing the recorded task execution information, it is possible to reconstruct the situation in which various tasks were executed within the project. Furthermore, even if a person involved in a task were to record false information in the task execution information recording device 10 for purposes such as making their performance look good or concealing their failures, the content recorded in the task execution information recording device 10 would become inconsistent with the content before and after that information. Therefore, if all the recorded contents in the task execution information recording device 10 are consistent, it can be determined that various changes have not been made by the people involved in the task, and that the true situation in which various tasks were executed within the project is recorded. It is also believed that by analyzing such task execution information, it is possible to obtain useful insights into how the project should be conducted.

[0044] In order to achieve this, the project execution system 1 of this embodiment includes a plurality of nodes 2 connected by a communication line 3, and task execution information generated during the execution of the project is exchanged using the nodes 2. By connecting the task execution information recording device 10 to the communication line 3, it becomes possible to collect the task execution information exchanged by the plurality of nodes 2 via the communication line 3.

[0045] B. Task Execution Information Recording Device 10: FIG. 5 is an explanatory diagram of the task execution information recording device 10 of this embodiment. As shown in FIG. 5, the task execution information recording device 10 of this embodiment includes a network connection unit 11, a task content acquisition unit 12, a deliverable acquisition unit 13, and a task execution information recording unit 14. Note that these "units" are abstract concepts representing the functions provided by the task execution information recording device 10 of this embodiment to acquire and record task execution information, and do not necessarily indicate the existence of components corresponding to these "units". These "units" can be realized as software programs executed by a microcomputer built into the task execution information recording device 10, as hardware such as LSIs and ICs, or as a combination of software programs and hardware.

[0046] The network connection unit 11 is connected to the communication line 3 and can transmit and receive data by communicating with a plurality of nodes 2 via the communication line 3. The data transmitted from the node 2 includes data related to task content such as the target of the task and the task executor, and data such as intermediate deliverables and final deliverables (hereinafter referred to as "deliverables") generated by the execution of the task. In addition, the network connection unit 11 of this embodiment is also connected to the computer node 51a of the blockchain network 50 and can transmit and receive data to and from the computer node 51a.

[0047] The task content acquisition unit 12 acquires the data of the task content from the data received by the network connection unit 11. Further, the deliverable acquisition unit 13 acquires the data of various deliverables generated by the execution of the task from the data received by the network connection unit 11.

[0048] The task execution information recording unit 14 receives the data of the task content from the task content acquisition unit 12 and receives the data of the deliverables from the deliverable acquisition unit 13, and records them as task execution information. In the task execution information, the data is recorded in time series so that the order in which the data of the task content and the data of the deliverables are received can be known. Alternatively, the data of the task content and the data of the deliverables are recorded together with the information on the date and time when those data are generated. Also, in this embodiment, it is assumed that the task execution information is recorded in a distributed ledger on the blockchain network 50. For this reason, the task execution information recording unit 14 generates block data obtained by aggregating the data of a plurality of task execution information, and transmits the block data to the computer node 51a of the blockchain network 50 via the network connection unit 11.

[0049] Figure 6 is a flowchart of the process by which the task execution information recording device 10 in this embodiment records task execution information. When the task execution information recording device 10 starts the task execution information recording process, it determines whether or not it has received new task execution information (STEP 10). This process is as follows. First, in the project execution system 1 of this embodiment, all task instructions are given by the task instructioner to the task executor using node 2 to send information such as the task's goal and deadline (task content), and the task executor confirms this content using node 2. In addition, intermediate and final deliverables obtained by the task executor executing the task are sent from node 2 to the task instructioner. Furthermore, communication between the task instructioner and the executor regarding task execution is also communicated using node 2. All of this information exchanged between the task instructioner and the executor regarding the task constitutes task execution information. In the project execution system 1 of this embodiment, the task execution information that the task instructioner and executor send to each other using node 2 is also sent to the task execution information recording device 10.

[0050] Furthermore, as described above using Figure 4, various tasks are executed in parallel within the project. Therefore, the task execution information received by the task execution information recording device 10 consists of various types of information sent to various recipients. In this embodiment, when node 2 sends task execution information, header information is created based on predetermined items set by the sender, and the task execution information is sent with this header information attached.

[0051] Figure 7 is an illustrative diagram illustrating how to set predetermined items for creating header information from the Node 2 screen when sending task execution information. In the illustrated example, the following items are set: "Project Name," "Instructor," "Executor," "Deadline," "Priority," "Creation Date and Time," "Information Category," and "Attached Data." For example, when instructing a task, "Project Name," "Instructor," "Executor," and "Priority" are selected from pre-registered options. For "Deadline," a date is selected from a calendar, and for "Creation Date and Time," the date and time are automatically set. "Information Category" refers to the category of task execution information, and is selected from pre-registered options such as "Task Content," "Intermediate Deliverable," "Final Deliverable," and "Other." Furthermore, for "Attached Data," various types of saved data (e.g., document data, calculation data, image data, etc.) are selected.

[0052] Similarly, when the task executor submits various deliverables, the same predetermined items are set. However, since these deliverables are obtained by the task executor executing the specified task, the task executor has received task execution information that instructed them to perform that task. Therefore, when the task executor submits various deliverables, if the task executor displays the screen executor 2 shown in Figure 7, the contents of the header information when the task instruction was received are already set for each of the following items: "Project Name," "Instructor," "Executor," "Deadline," and "Priority." In Figure 7, these items are shown with diagonal lines to indicate that these items can only be set by the task instructor, and not by the task executor. The task executor then sets the "Creation Date and Time" and "Information Category" items and selects the attached data.

[0053] Furthermore, most tasks are generated by receiving instructions for other tasks. For example, a task that a section chief instructs an employee to perform is a task that the section chief instructed the employee to perform in order to carry out a task that the department head instructed the employee to perform. In addition, a task that the department head instructs the section chief to perform is a task that the department head instructed the employee to perform in order to carry out a task that the department head in charge of executives in charge of. Thus, most tasks have a parent task that directly caused the creation of that task. Therefore, an identification number may be assigned to all tasks, and when a parent task exists when instructing a task, the identification number of the parent task may be set on the screen illustrated in Figure 7, thereby including the identification number of the parent task in the header information. Similarly, when a task executor reports the deliverables, the identification number of the parent task set in the header information of the instructed task may be automatically inherited.

[0054] Figure 8 is an explanatory diagram illustrating the data structure of task execution information 20 transmitted by node 2. The task execution information 20 has a data structure in which header information 21 and attached data 22 are attached. Here, the header information 21 is created based on the content set by the sender of the task execution information 20 for predetermined items on the screen illustrated in Figure 7. The attached data 22 is the attached data set on the screen illustrated in Figure 7. Note that any number of attached data 22 can be attached to the task execution information 20.

[0055] As described above, in the project execution system 1 of this embodiment, all information for executing a task is exchanged between nodes 2 as task execution information 20 having the data structure illustrated in Figure 8. All of the task execution information 20 exchanged between nodes 2 is then transmitted to the task execution information recording device 10.

[0056] Therefore, when the task execution information recording device 10 starts the task execution information recording process shown in Figure 6, it checks whether or not there is task execution information transmitted from node 2 of the project execution system 1 (STEP 10). If no new task execution information is received (STEP 10: no), it continues monitoring as in STEP 10. On the other hand, if new task execution information is received (STEP 10: yes), the received task execution information is stored in a temporary memory (not shown) within the task execution information recording device 10 (STEP 11).

[0057] Next, the task execution information recording device 10 determines whether or not to create block data of the task execution information (STEP 12). It determines whether the total amount of data of the task execution information stored in the task execution information recording device 10 has reached a predetermined amount of data, and if it has reached the predetermined amount of data, it decides to create block data; otherwise, it decides not to create it. Alternatively, instead of the total amount of data, it may decide to create block data if the number of task execution information items reaches a predetermined number, and not to create it if it has not. Or, it may check whether or not there is task execution information stored in temporary memory at predetermined intervals, and decide to create block data if there is task execution information, and not to create it if there is no task execution information.

[0058] If the result of STEP 12 is to decide not to create block data (STEP 12: no), the process returns to the beginning and resumes determining whether or not new task execution information has been received (STEP 10). On the other hand, if it is decided to create block data (STEP 12: yes), the task execution information 20 stored in temporary memory (not shown) is read and block data is created (STEP 13). The read task execution information 20 is deleted from temporary memory. The block data is as follows.

[0059] Figure 9 is an explanatory diagram illustrating the data structure of block data 30. As shown in Figure 9, block data 30 has a structure in which multiple task execution information 20 are arranged in the order in which they were created (and therefore in the order in which they were received by the task execution information recording device 10). In STEP 13 of Figure 6, block data 30 as shown in Figure 9 is created by reading the task execution information 20 in the order in which they were stored in temporary memory.

[0060] Once the block data 30 is created, it is sent to the computer node 51a of the blockchain network 50 (STEP 14). As described above using Figure 1, computer node 51a, together with the other computer nodes 51b to 51d, forms the blockchain network 50, and the block data 30 sent to computer node 51a is also forwarded to the other computer nodes 51b to 51d and recorded on each of them. Therefore, sending the block data 30 to computer node 51a in STEP 14 is equivalent to recording the block data 30 on the computer nodes 51a to 51d on the blockchain network 50. After sending the block data 30 to computer node 51a, the process returns to the beginning and resumes determining whether or not new task execution information has been received (STEP 10).

[0061] Figure 10 is an explanatory diagram showing how block data 30 transmitted from the task execution information recording device 10 to computer node 51a is also transferred to computer nodes 51b to 51d and recorded at each of the computer nodes 51a to 51d. For example, when the first block data 30a is transmitted from the task execution information recording device 10 to computer node 51a, that block data 30a is also transferred to computer nodes 51b to 51d and recorded at computer nodes 51a to 51d.

[0062] Next, when the task execution information recording device 10 transmits the next block data 30b to computer node 51a, that block data 30b is also transferred to computer nodes 51b to 51d. However, when block data 30b is recorded by computer nodes 51a to 51d, it is not recorded alone, but with the hash value of the block data 30 recorded immediately before it (in this case, the first block data 30a) added to it.

[0063] Here, a hash value is a value obtained by applying a special function called a hash function to arbitrary data. Furthermore, a hash function converts any data of any size into a hash value of the same data length, and if even a part of the original data is different, the converted hash value will be a completely different value. Therefore, a one-to-one relationship exists between the hash value and the original data, and it can be said that the hash value uniquely represents the original data.

[0064] Furthermore, when the third block data 30c is transmitted from the task execution information recording device 10 to the computer node 51a, the block data 30c is also recorded on the computer nodes 51a to 51d with a hash value attached. At this time, the hash value attached to the block data 30c is not the hash value of the block data 30b, but the hash value of the block data 30 with the hash value already attached.

[0065] In this way, the block data 30 transmitted from the task execution information recording device 10 to the computer node 51a is recorded on computer nodes 51a to 51d, containing information (in this case, a hash value) that allows for the identification of the previously transmitted block data 30. This format (i.e., a format in which previous data is recorded in an identifiable manner) is called the blockchain format because multiple data are linked in a chain-like sequence. While the use of hash values ​​is a known method for identifying previous data, other methods (most simply adding sequential numbers) can also be used. However, the method of identifying previous data using hash values ​​and recording it redundantly in multiple locations is known to be an extremely difficult method to tamper with.

[0066] As described above, the task execution information recording device 10 of this embodiment can acquire and record task execution information exchanged between multiple nodes 2 during project execution. The recorded task execution information includes details of how various tasks were executed during project execution, including their intermediate progress. If the intermediate progress of tasks is also recorded in this way, even if those involved in a task try to leave a record that suits their convenience, inconsistencies will arise with other task execution information. Therefore, if there are no inconsistencies among all the recorded task execution information, it can be determined that the task execution information records the true situation in which various tasks were executed within the project. Furthermore, since this task execution information records details of how various tasks were executed within the project, including their intermediate progress, useful insights can be obtained with a high probability by analyzing or interpreting this information.

[0067] In addition, in the embodiment described above, task execution information is recorded on computer nodes 51a to 51d on the blockchain network 50 in a manner that is extremely difficult to tamper with. From this perspective as well, it is possible to fully guarantee the truthfulness of the recorded content.

[0068] C. Modifications: Modifications exist for the project execution system 1 or task execution information recording device 10 of the above-described embodiment. Below, the differences between the modified task execution information recording device 10 and the above-described embodiment will be explained.

[0069] In the embodiment described above, it was explained that when node 2 of the project execution system 1 transmits task execution information 20 to another node 2, it is automatically transmitted to the task execution information recording device 10. However, the task execution information recording device 10 may request each node 2 to transmit new task execution information 20.

[0070] Figure 11 is a flowchart of the task execution information recording process performed in the modified task execution information recording device 10. When the modified task execution information recording device 10 starts the task execution information recording process, it determines whether the current time is a predetermined request time (STEP 20). In other words, in the modified version, each node 2 requests the transmission of new task execution information 20 at a fixed time each day, and STEP 20 determines whether that time has arrived. If the predetermined request time has not been reached (STEP 20: no), the device remains in a waiting state until the request time is reached by repeating the determination in STEP 20.

[0071] In response to this, if the requested time has been reached (STEP 20: yes), the system requests all nodes 2 within the project execution system 1 to send new task execution information 20 (STEP 21). As described above using Figures 7 and 8, the header information 21 attached to the task execution information 20 includes information on the creation date and time of the task execution information 20. If the creation date and time is newer than the request time when the previous transmission was requested, the task execution information 20 can be determined to be new task execution information 20. Therefore, the task execution information recording device 10 can request the transmission of new task execution information 20 by specifying the request time when the previous transmission was requested.

[0072] Next, the task execution information recording device 10 receives the new task execution information 20 transmitted from each node 2 and stores them in temporary memory (STEP 22). In the modified example, for the sake of simplicity, all nodes 2 are simultaneously requested to transmit the new task execution information 20 (STEP 21). However, this would result in a large number of task execution information 20 being transmitted at the same time, raising concerns that it may interfere with the reception of the task execution information 20. Therefore, all nodes 2 may be divided into multiple blocks in advance, a request time may be set for each block, and the transmission of new task execution information 20 may be requested for each block.

[0073] As described above, the processing after obtaining new task execution information 20 is the same as the processing in this embodiment described above using Figure 6. Briefly, the next step is to decide whether or not to create block data of the task execution information (STEP 23). This decision can be made based on whether the total amount of data of the task execution information has reached a predetermined amount, or whether the number of task execution information items has reached a predetermined number. Furthermore, the creation time of the block data may be set in advance, and the decision may be made based on whether or not the creation time has arrived. Of course, the creation time may be set to the same time as the request time described above, and it may be decided to create block data immediately upon receiving new task execution information 20.

[0074] As a result, if it is determined not to create block data (STEP 23: no), the process returns to the beginning and resumes determining whether or not new task execution information has been received (STEP 20). On the other hand, if it is determined to create block data (STEP 23: yes), the task execution information 20 stored in temporary memory is read and block data 30 is created (STEP 24). Then, the created block data 30 is sent to the computer node 51a of the blockchain network 50 (STEP 25), and the process returns to the beginning and resumes determining whether or not new task execution information has been received (STEP 20).

[0075] In the modified task execution information recording device 10 described above, new task execution information can be obtained by querying node 2 of the project execution system 1. Therefore, it is not necessary to constantly monitor the task execution information transmitted from node 2, which reduces the processing load.

[0076] Although the project execution system 1 and task execution information recording device 10 of this embodiment or modified version have been described above, the present invention is not limited to the above embodiment or modified version, and can be implemented in various forms without departing from the spirit of the invention.

[0077] For example, in the embodiment or modification described above, it was explained that when the task execution information recording device 10 acquires task execution information, it combines that task execution information into block data and records it on the computer nodes 51a to 51d of the blockchain network 50. However, the block data may also be recorded on the task execution information recording device 10, the communication line 3, or a connected external storage device. Alternatively, the task execution information recording device 10 may record the task execution information to the external storage device each time it receives task execution information from node 2.

[0078] 1...Project execution system, 2...Node, 3...Communication line, 10...Task execution information recording device, 11...Network connection unit, 12...Task content acquisition unit, 13...Deliverable acquisition unit, 14...Task execution information recording unit, 20...Task execution information, 21...Header information, 22...Attached data, 30...Block data, 30a-30c...Block data, 50...Blockchain network, 51a-51d...Computer node.

Claims

1. A project execution system in which multiple nodes equipped with computers are connected to each other in a manner that enables communication, and multiple tasks for carrying out a project are divided among the multiple nodes and executed, the project execution system comprising: a task content acquisition unit that, when a new task is instructed by setting the objective and the executor of the task on any of the multiple nodes, acquires the objective and the executor of the task as task content representing the content of the task; an deliverable acquisition unit that, from the time the task is started by the executor of the task until the task is completed, acquires intermediate deliverables, which are the deliverables of the task generated during the execution of the task, from the node operated by the executor of the task, and after the completion of the task, acquires the final deliverable, which is the deliverable of the task generated by the completion of the task, from the node operated by the executor of the task; and a task execution information recording unit that, when task execution information, which is information of either the task content, the intermediate deliverable, or the final deliverable, is acquired, records the task execution information while maintaining the order in which the task execution information was created or acquired.

2. A project execution system according to claim 1, wherein the task content acquisition unit acquires information on the date and time the task was instructed when acquiring the task content, the deliverable acquisition unit acquires information on the date and time the intermediate deliverable or the final deliverable was generated or acquired when acquiring the intermediate deliverable or the final deliverable, and the task execution information recording unit records the task content as task execution information together with the information on the date and time the task was instructed when recording the task content, and records the intermediate deliverable or the final deliverable as task execution information together with the information on the date and time the intermediate deliverable or the final deliverable was generated or acquired, thereby recording the task execution information in a manner that preserves the order in which the task execution information was created or acquired.

3. A project execution system according to claim 1, wherein the task content acquisition unit acquires the task content and information on the date and time the task was instructed each time a predetermined acquisition condition is satisfied; the deliverable acquisition unit acquires the intermediate deliverable or the final deliverable and information on the date and time the intermediate deliverable or the final deliverable was produced each time the acquisition condition is satisfied; and the task execution information recording unit records the task execution information indicating the task content together with the information on the date and time the task was instructed, and records the task execution information indicating the intermediate deliverable or the final deliverable together with the information on the date and time the intermediate deliverable or the final deliverable was created, thereby recording the task execution information in a manner that preserves the order in which the task execution information was created.

4. A task execution information recording device applied to a project execution system in which multiple computer-equipped nodes are connected to each other in a communicative manner, and multiple tasks for carrying out a project are divided and executed by the multiple nodes, the device acquires and stores task execution information which is information regarding the execution status of multiple tasks, the device comprising: a task content acquisition unit that acquires the task's objective and the task's executor as task content representing the content of the task when a new task is instructed by setting the task's objective and the task's executor on any of the multiple nodes; an output acquisition unit that acquires intermediate output, which is the output of the task generated during the execution of the task, from the node operated by the task's executor from the time the task is started by the task's executor until the task is completed, and after the completion of the task, acquires final output, which is the output of the task generated by the completion of the task, from the node operated by the task's executor; A task execution information recording device is characterized by comprising a task execution information recording unit that, when task execution information which is information of the task content, the intermediate deliverable, or the final deliverable is acquired, records the task execution information while maintaining the order in which the task execution information was created or acquired.

5. A task execution information recording method that uses a computer to implement a process for acquiring and storing task execution information, which is information regarding the execution status of multiple tasks, applicable to a project execution system in which multiple computer-equipped nodes are connected to each other in a manner that enables communication, and in which multiple tasks for carrying out a project are divided among the multiple nodes to be executed, wherein when a new task is instructed by setting the objective of the task and the executor of the task on any of the multiple nodes, the task content acquisition step acquires the objective of the task and the executor of the task as task content representing the content of the task; from the time the task is started by the executor of the task until the task is completed, intermediate deliverables, which are the deliverables of the task generated during the execution of the task, are acquired from the node operated by the executor of the task, and after the completion of the task, final deliverables, which are the deliverables of the task generated by the completion of the task, are acquired from the node operated by the executor of the task. A task execution information recording method characterized by comprising a task execution information recording step, which, when task execution information, which is information of the task content, the intermediate deliverable, or the final deliverable, is acquired, records the task execution information while preserving the order in which the task execution information was created or acquired.

Images