Program, method, information processing device, and system

Abstract

There are issues where projects and the tasks within them have not been evaluated. [Solution] A program to be executed by a computer having a processor and a memory unit, wherein the processor executes a project acquisition step of acquiring project information related to a project, a task acquisition step of acquiring one or more pieces of task information related to one or more tasks associated with the project based on the project information, and an evaluation step of evaluating one or more tasks based on the one or more pieces of task information.

Description

[Technical Field]

[0001] The present disclosure relates to a program, a method, an information processing device, and a system. [Background technology]

[0002] Techniques for supporting project management are known. Patent Document 1 discloses a technique for visually and easily understanding summary information on the progress of multiple projects that use different management tools, as a list. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2016-118832 A Summary of the Invention [Problem to be solved by the invention]

[0004] There are issues where projects and the tasks within them have not been evaluated. Therefore, the present disclosure has been made to solve the above problem, and its purpose is to provide a technique for evaluating a project or a task included in a project. [Means for solving the problem]

[0005] A program to be executed by a computer having a processor and a memory unit, the program executing a project acquisition step in which the processor acquires project information related to a project, a task acquisition step in which it acquires one or more pieces of task information related to one or more tasks associated with the project based on the project information, and an evaluation step in which it evaluates one or more tasks based on the one or more pieces of task information. [Effects of the Invention]

[0006] According to the present disclosure, projects and tasks included in projects can be evaluated. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 2 is a block diagram showing the functional configuration of the system 1. [Figure 2] FIG. 2 is a block diagram showing the functional configuration of the server 10. [Figure 3] FIG. 2 is a block diagram showing the functional configuration of a user terminal 20. [Figure 4] FIG. 10 is a diagram showing the data structure of a user table 1012. [Figure 5] FIG. 10 is a diagram showing the data structure of a project table 1013. [Figure 6] FIG. 10 is a diagram showing the data structure of a task table 1014. [Figure 7] FIG. 10 is a diagram showing the data structure of a rule master 1021. [Figure 8] 10 is a flowchart showing the operation of an evaluation process. [Figure 9] 10 is a flowchart showing the operation of an evaluation presentation process. [Figure 10] 10 is a screen example showing the operation of the evaluation presentation process. [Figure 11] FIG. 2 is a block diagram showing the basic hardware configuration of a computer 90. DETAILED DESCRIPTION OF THE INVENTION

[0008] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In all drawings describing the embodiments, common components are designated by the same reference numerals, and repeated description will be omitted. Note that the following embodiments do not unduly limit the content of the present disclosure described in the claims. Furthermore, not all components shown in the embodiments are necessarily essential components of the present disclosure. Furthermore, each drawing is a schematic diagram and is not necessarily a precise illustration.

[0009] <System 1 Configuration> The system 1 in the present disclosure is an information processing system that supports the management of development projects for software, products, and the like. The system 1 includes an information processing device, a server 10, and a user terminal 20, which are connected via a network N. FIG. 1 is a block diagram showing the functional configuration of the system 1. As shown in FIG. FIG. 2 is a block diagram showing the functional configuration of the server 10. As shown in FIG. FIG. 3 is a block diagram showing the functional configuration of the user terminal 20. As shown in FIG.

[0010] Each information processing device is configured by a computer equipped with an arithmetic unit and a storage device. The basic hardware configuration of the computer and the basic functional configuration of the computer realized by the hardware configuration will be described later. For each of the server 10 and the user terminal 20, descriptions that overlap with the basic hardware configuration and basic functional configuration of the computer will be omitted.

[0011] <Server 10 configuration> The server 10 is an information processing device that provides services to support the management of development projects for software, products, and the like. The server 10 includes a storage unit 101 and a control unit 104 .

[0012] <Configuration of the storage unit 101 of the server 10> The storage unit 101 of the server 10 includes an application program 1011 , a user table 1012 , a project table 1013 , a task table 1014 , and a rule master 1021 .

[0013] The application program 1011 is a program for causing the control unit 104 of the server 10 to function as each functional unit. Application programs 1011 include applications such as a web browser application.

[0014] User table 1012 is a table that stores and manages information about member users (hereinafter, "users") who use the service. When a user registers to use the service, the user's information is stored in a new record in user table 1012. This allows the user to use the service according to the present disclosure. The user table 1012 may store user information about individual users, or may store information about organizations to which users belong (organization information). Organizations include any organization or group, such as a company, corporation, corporate group, club, or various associations. Organizations may also be defined by more detailed subgroups, such as company departments (sales department, general affairs department, customer support department). In the present disclosure, an example is disclosed in which personal information related to users and information related to groups such as companies and corporations are collectively managed in the user table 1012, but this is not limiting. For example, information on groups such as companies and corporations may be managed in a group table or the like that is different from the user table. The user table 1012 is a table having columns of user ID, user name, and user data, with the user ID as the primary key. FIG. 4 is a diagram showing the data structure of the user table 1012.

[0015] The user ID is an item that stores user identification information for identifying a user. The user identification information is an item that is set with a unique value for each user. The user name is an item for storing the name of the user. The user name may be set to any character string such as a nickname instead of a name. The user data includes information specific to the individual user and attribute information relating to the user's characteristics and background. The user's unique information includes information unique to the user, such as the user's date of birth (age), sex, and the like. The user's attribute information includes information such as the user's educational history (highest level of education, major, graduation year), occupation, work history, interests, place of residence, and language. In the case of a company, corporation, organization, group, etc., user data includes information such as business type / industry, location, number of employees, annual sales, transaction start date, contract details / contract period, past transaction history, key contact information, organizational structure / decision maker information, etc.

[0016] The project table 1013 is a table for storing and managing information related to a project (project information). The information processing system 1 of the present disclosure does not necessarily need to include the project table 1013, and project information stored in an external project management system such as Jira may be used. Furthermore, project information stored in an external project management system or the like may be linked (imported) to the project table 1013 and stored. Information stored in an external project management system or the like may be linked (imported) to the project table 1013 for each item and stored. Information stored in an external project management system or the like may be converted using the generation AI 50 and stored. The project table 1013 is a table having a project ID as a primary key and columns of project ID, person in charge ID, project content, project data, and evaluation data. FIG. 5 is a diagram showing the data structure of the project table 1013.

[0017] The project ID is an item that stores project identification information for identifying a project. The project identification information is an item that has a unique value set for each piece of project information. The person in charge ID is an item for storing person in charge identification information (user ID) for identifying the person in charge. The person in charge ID may be configured to store user identification information (user ID) indicating the company, organization, etc. to which the person in charge belongs. The project content is an item that stores a description that defines the project. Specifically, it stores character string information such as the project name, summary description, purpose, goals, start date and time, and scheduled end date and time. The project content may be stored as part of the project data. The project content is used as a basic description that allows the user to understand the outline of the project. Project data is an item that stores structured attribute information (project attributes) about a project. Project data includes information such as the purpose, goals, start date and time, planned end date and time, actual end date and time, progress (planned, ongoing, completed, suspended, etc.), priority, major milestones, deliverable definition, and success criteria. Project data includes, among other things, the following information: Project type: Information indicating the type of development project (new development, feature addition, maintenance, modification, research and development, etc.), development target (web application, mobile app, embedded software, AI / machine learning model, IoT system, etc.), and development method (waterfall, agile, scrum, etc.). It is not limited to development projects. You can also store the project type of any project, such as a sales project, marketing project, advertising project, or planning project. Data source: Information indicating the source of data used or generated in the project (internal system, external API, customer-provided data, public dataset, sensor data, etc.), data format (structured / unstructured), data volume, acquisition frequency, data quality information, etc. For example, string information indicating the task management system of the linked (imported) destination, such as Jira or GitHub, is stored. The data source includes not only string information indicating the partner service (Jira, GitHub, etc.), but also information for identifying tasks related to the target project within the service (such as task ID, URL, or other string information of any identifier). For example, the data source includes identifier information for identifying project-related tasks within the data source system, such as a specific project identifier or project key within a workspace in the case of Jira, or a repository name or specific branch information in the case of GitHub. Calculation rule: This field stores specific calculation rules for calculating evaluation information, such as lead time, for a specific project. Information similar to the calculation rules in the rule master 1021 (described later) is stored here. For example, if the project information (project content) is an "EC site renewal project," a calculation rule is stored that defines the lead time as the time from the date and time the status changes to design approval (first status) to the date and time the status changes to production release (second status) (excluding the client confirmation period). Different calculation rules may be stored depending on the project information (project content, project data). For example, if the project information (project content) is an "internal system development project," the rule master 1021 condition data item is searched for, and a calculation rule is stored that defines the lead time as the time from the date and time the status changes to requirements definition start (first status) to the date and time the status changes to user testing completion (second status) (none, including all time). The calculation rule may be stored in the rule master 1021 (described later) without being included in the project data. It is sufficient that a calculation rule can be defined for each specific project information. Calculation rules include not only lead time calculation patterns based on status changes within a single data source, but also composite calculation patterns that take into account the correlation between multiple data sources. For example, we will explain a calculation rule that aggregates and calculates the lead time for multiple GitHub tasks (pull requests, commits, etc.) linked to a Jira ticket. In this case, based on the linking information between the Jira ticket and the GitHub task (e.g., including the Jira ticket number in the GitHub commit message or branch name), the work time for all related GitHub tasks is aggregated and calculated as the overall lead time. Such composite calculation rules enable accurate lead time measurement throughout the entire development process. The project data may also store the value per unit time for the project (information such as man-hours, man-days, man-months, hourly rate, salary, wages, etc.). This makes it possible to calculate the monetary value of a task, project, etc. by multiplying the lead time calculated using the calculation rules by the value per unit time. The value per unit time may be defined individually for each task or for each task type. For example, the value per unit time for a requirements definition task may be defined as A yen per man-day, and the value per unit time for a testing task may be defined as B yen per man-day. Since labor costs for engineers and other personnel typically vary significantly depending on the task type, this allows for more accurate task evaluation. Furthermore, since the volume of task types is small compared to defining value for each task, defining value for each small-volume task type allows for more accurate calculation of the monetary value for each task. The evaluation data is an item that stores evaluation information (evaluation data) for a project. The evaluation data includes information on the project's lead time (information such as the number of man-hours and period required for development). The evaluation data also includes cost information (including any monetary information related to the task, such as investment amount) calculated by multiplying the lead time by cost information such as man-months (cost information may also be calculated directly). The evaluation data may also include any evaluation information (value information) such as the project's value, priority, score, etc.

[0018] The task table 1014 is a table for storing and managing information relating to tasks (task information). The task table 1014 does not necessarily have to be provided in the information processing system 1 of the present disclosure, and development item information stored in an external task management system such as GitHub may be used. Furthermore, development item information stored in an external task management system or the like may be linked (imported) to the task table 1014 and stored. Information stored in an external task management system or the like may be linked (imported) for each item to the task table 1014 and stored. Information stored in an external task management system or the like may be converted using the generation AI 50 and stored. The task table 1014 is a table having the task ID as a primary key and columns of task ID, project ID, person in charge ID, task content, task data, status, and evaluation data. FIG. 6 is a diagram showing the data structure of the task table 1014.

[0019] The task ID is an item that stores item identification information for identifying an item. The item identification information is an item in which a unique value is set for each item of item information. The project ID is an item for storing project identification information for identifying a project. The person in charge ID is an item for storing person in charge identification information (user ID) for identifying the person in charge. The person in charge ID may be configured to store user identification information (user ID) indicating the company, organization, etc. to which the person in charge belongs. The task content is an item that stores a description that defines a task. Specifically, it stores character string information such as the task name, summary description, purpose, goal, start date and time, and scheduled end date and time. The task content may be stored as part of the task data. The task content is used as a basic explanatory text that the user can use to understand the outline of the task. Task data is an item that stores structured detailed information about a task, including the target completion date, priority, estimated man-hours, actual man-hours, related project ID, tag information, and so on. Task type: Includes task classification information (requirements definition, design, development, feature implementation, bug fixes, documentation, testing, deployment, review, research, design, etc.). Also includes information equivalent to labels and milestones on GitHub. Data source: This stores information about the source of the task and related data (customer requests, internal proposals, bug reports, performance test results, user feedback, etc.), reference information for related external systems (commit ID, pull request number, etc.), and information about connections with external tools. For example, it stores string information indicating the task management system of the connected (imported) target, such as GitHub. The status includes time-series data such as the task status change history (not started → in progress → under review → completed, etc.), the start and end dates and times of each status, the change history of the person in charge, and the comment history. Note that the statuses stored in the task table 1014 of the present disclosure may be stored in the task table 1014 of the present disclosure as a status history by chronologically acquiring (collecting) the statuses stored in a task management service or the like related to the data acquisition source. For example, the control unit 104 of the server 10 of the present disclosure may constantly monitor (periodically monitor and poll) status changes in the data acquisition source (GitHub, Jira, etc.) such as a task management service, and may construct the status by acquiring a string indicating the status (not started, in progress, under review, completed, etc.) along with the timestamp of the change. Specifically, using methods such as web hooks or API polling, status change events (e.g., Not Started → In Progress, In Progress → Under Review, Under Review → Completed) in the target system are detected, and the change details and date and time are stored. This allows a chronological history of task progress to be accumulated, which can be used as basic data for lead time calculations and project evaluations based on the calculation rules described below. Events such as changes in the person in charge and the addition of comments can also be similarly obtained and stored as a status history that allows a comprehensive understanding of changes in task status. An example of the status is shown below. { "Status History":[ { "Status":"Not Started", "Start date and time":"April 1, 2025 09:00:00", "End date and time":"2025 / 04 / 02 10:30:00", "Contact Person": "Taro Tanaka", "Comment": "Registered as a new task. Medium priority, will be addressed in the next sprint." }, { "Status":"In Progress", "Start date and time":"April 2, 2025 10:30:00", "End date and time":"2025 / 04 / 04 17:45:00", "Contact Person": "Taro Tanaka", "Comment": "Implementation has begun. Due to the need to change the database schema, the estimated time has been revised from 8 hours to 12 hours." }, { "Status":"Under Review", "Start date and time":"April 4, 2025 17:45:00", "End date and time":"2025 / 04 / 05 14:20:00", "Contact Person": "Hanako Sato", "comment":"Assigned to code reviewer. Performance needs review." }, { "Status":"Repairing", "Start date and time":"April 5, 2025 14:20:00", "End date and time":"2025 / 04 / 05 18:00:00", "Contact Person": "Taro Tanaka", "comment":"Query optimization is currently being performed based on review comments." }, { "Status":"Under Review", "Start date and time":"April 5, 2025 18:00:00", "End date and time":"2025 / 04 / 06 10:15:00", "Contact Person": "Hanako Sato", "Comment": "Check the fix. No problems." }, { "status":"testing", "Start date and time":"April 6, 2025 10:15:00", "End date and time":"2025 / 04 / 07 11:30:00", "Contact Person": "Ichiro Suzuki", "Comment": "Confirm operation in the integration test environment. Includes edge case testing." }, { "Status":"Complete", "Start date and time":"April 7, 2025 11:30:00", "End date and time":null, "Contact Person": "Ichiro Suzuki", "Comment": "All tests passed. Ready to deploy to production. Actual effort: 14 hours." } ] } The evaluation data is an item that stores evaluation information (evaluation data) for a task. The evaluation data includes information on the lead time of the task (information such as the number of man-hours and period required for development). The evaluation data also includes cost information (including any monetary information related to the task, such as investment amount) calculated by multiplying the lead time by cost information such as man-months (cost information may also be calculated directly). In addition, the evaluation data may include calculation rules that output any evaluation information (value information) such as the value, priority, score, etc. of the task.

[0020] The rule master 1021 is a table for storing and managing information about rules (rule information). The rule master 1021 is a table having columns for rule ID, condition data, and calculation rule. FIG. 7 is a diagram showing the data structure of the rule master 1021. As shown in FIG.

[0021] The rule ID is an item for storing rule identification information for identifying a rule. The condition data is an item that stores the conditions under which the rule is applied. Specifically, the condition data includes information (such as character string information) indicating the project type, task type, and data source (the data source of the project information, the data source of the task information). In addition, the condition data can be assigned any information such as project content indicating the content of the project, task content indicating the content of the task, project data, and task data. The condition data includes label information assigned to a task. For example, a task may be assigned label information indicating its development purpose, such as "churn reduction," "new feature development," "performance improvement," "security response," "technical debt repayment," or "UX improvement." Such label information may be considered a type of task type. The condition data may also include label information indicating whether the task utilizes AI. This enables analysis tailored to business purposes, such as "average lead time for tasks labeled as churn suppression" or "correlation between the priority of tasks labeled as security-related and the actual response speed," through evaluation presentation processing, etc. It also makes it possible to compare the difference in productivity between tasks that utilize AI and those that do not. When multiple labels are assigned to a single task, the condition data may include conditions based on the combination and priority of the labels. Specifically, it is possible to set compound conditions using the logical product (AND condition) of multiple labels, such as "reducing churn and responding to security," or the logical sum (OR condition), such as "developing new features or improving UX." It is also possible to assign priorities and weights to labels and define conditions such as "tasks with high priority for security response." Furthermore, by combining label information with other condition data (project type, data source, etc.), more granular conditions can be defined. For example, complex condition settings such as "technical debt repayment tasks in a mobile app development project" or "AI-based churn prevention tasks managed on GitHub" can be included. For example, condition data includes conditions such as project type (new development, feature addition, maintenance, modification, etc.), task type (requirements definition, design, development, feature implementation, bug fixes, documentation creation, testing, deployment, review, research, design, etc.), data source (Jira, GitHub, Trello, internal tools, etc.), project content (keywords included in the project name or summary), etc. These conditions can be defined by specifying a single value, combining multiple values, or pattern matching using regular expressions. For example, you can set complex conditions such as "if the project type is new development and the task type is requirements definition" or "if the project content includes EC or payment." The calculation rule is an item that stores specific calculation rules for calculating evaluation information such as lead time. In this disclosure, calculation of lead time for task information is disclosed as an example, but is not limited to this. For example, the calculation rule may store a calculation rule for cost information (including any monetary information related to a task such as investment amount) by multiplying lead time by cost information such as man-months. In addition, the calculation rule may store a calculation rule for outputting any evaluation information (value information) such as the value, priority, score, etc. of a task. Specifically, the calculation rules store information such as the definition of the starting state (when the status changes from "Not started" to "In progress", when the status becomes "Requirements confirmed", when the PR is opened, etc.), the definition of the ending state (when the status becomes "Complete", when the status becomes "Release completed", when the pull request is merged, etc.), the calculation method (actual working hours only, total number of calendar days), and times to be excluded (nights, holidays, "Waiting" status periods, client confirmation periods, etc.). Furthermore, definitions for detailed analysis based on status transitions (such as aggregating the time spent in "in progress" and "being fixed" as development time, and aggregating the time spent in "awaiting review" and "under review" as review time) may also be stored. These rules are applied to the status history of tasks that match the condition data, allowing for the calculation of meaningful lead time indicators. By combining multiple rules, it is possible to calculate highly accurate lead times that are optimized for project and task characteristics. Calculation rules are not limited to rule-based calculation rules. They may be defined by any artificial intelligence model, such as machine learning, deep learning, or generative AI, or by prompts. In this case, past task completion data and performance data from similar projects can be learned to perform more precise lead time predictions and optimal calculations. For example, a machine learning model that takes into account factors such as task characteristics, developer skill levels, and project complexity can calculate lead times more accurately.

[0022] <Configuration of the control unit 104 of the server 10> The control unit 104 of the server 10 includes a user registration control unit 1041. The control unit 104 executes an application program 1011 stored in the storage unit 101, thereby realizing each functional unit.

[0023] The user registration control unit 1041 performs processing to store information about users who wish to use the service according to the present disclosure in the user table 1012. The information stored in the user table 1012 is generated when a user opens a web page operated by a service provider from any information processing terminal, enters information into a predetermined input form, and transmits the information to the server 10. The user registration control unit 1041 stores the received information in a new record in the user table 1012, completing the user registration. This allows the user stored in the user table 1012 to use the service. Before the user registration control unit 1041 registers the user information in the user table 1012, the service provider may conduct a predetermined examination to restrict whether or not the user is permitted to use the service. The user ID may be any character string or number that can identify the user, any character string or number desired by the user, or may be automatically set by the user registration control unit 1041.

[0024] <Configuration of User Terminal 20> The user terminal 20 is an information processing device operated by a user who uses a service. The user terminal 20 may be, for example, a mobile terminal such as a smartphone or tablet, a stationary personal computer (PC) or a laptop PC, or a wearable terminal such as a head mounted display (HMD) or a wristwatch terminal. The user terminal 20 includes a storage unit 201 , a control unit 204 , an input device 206 , and an output device 208 .

[0025] <Configuration of the storage unit 201 of the user terminal 20> The storage unit 201 of the user terminal 20 includes a user ID 2011 and an application program 2012 .

[0026] The user ID 2011 is the user's account ID. The user transmits the user ID 2011 from the user terminal 20 to the server 10. The server 10 identifies the user based on the user ID 2011 and provides the user with the service according to the present disclosure. The user ID 2011 includes information such as a session ID temporarily assigned by the server 10 to identify the user using the user terminal 20.

[0027] The application program 2012 may be stored in advance in the storage unit 201, or may be configured to be downloaded from a web server or the like operated by a service provider via a communication IF. The application programs 2012 include applications such as a web browser application. The application program 2012 includes an interpreted programming language such as JavaScript (registered trademark) that runs on a web browser application stored on the user terminal 20.

[0028] <Configuration of the control unit 204 of the user terminal 20> The control unit 204 of the user terminal 20 includes an input control unit 2041 and an output control unit 2042. The control unit 204 executes an application program 2012 stored in the storage unit 201, thereby realizing each functional unit.

[0029] <Configuration of the input device 206 of the user terminal 20> The input device 206 of the user terminal 20 includes a camera 2061 , a microphone 2062 , a position information sensor 2063 , a motion sensor 2064 , and a touch device 2065 .

[0030] <Configuration of the output device 208 of the user terminal 20> The output device 208 of the user terminal 20 includes a display 2081 and a speaker 2082 .

[0031] <System 1 Operation> Each process of the system 1 will be explained below. FIG. 8 is a flowchart showing the operation of the evaluation process. FIG. 9 is a flowchart showing the operation of the evaluation presentation process. FIG. 10 is a screen example showing the operation of the evaluation presentation process.

[0032] <Evaluation process> The evaluation process is a process for evaluating tasks associated with a project, specifically, the lead time, cost, investment amount, and other monetary values ​​of the tasks associated with the project.

[0033] <Evaluation process overview> The evaluation process is a series of steps consisting of a project acquisition step that acquires project information for the project that is the subject of the evaluation process, a task acquisition step that acquires task information for one or more tasks associated with the project, a status acquisition step that acquires the status of the task, an evaluation step that evaluates the task based on the acquired status, and an evaluation step that evaluates the project.

[0034] <Evaluation process details> The evaluation process will be described in detail below.

[0035] <Project acquisition steps> In step S101, the control unit 104 of the server 10 executes a project acquisition step of acquiring project information related to a project. Specifically, the user operates the input device 206 of the user terminal 20 to execute a browser application or the like and open the evaluation page D1 by inputting the URL of a web page (evaluation page) for executing the evaluation process. The evaluation page D1 includes an input field for the project ID, etc., as well as a search condition input field and a send button. The user operates the input device 206 of the user terminal 20 to input project identification information in the project ID input field. The user may also input any search conditions for searching for project information stored in the project table 1013 in the search condition input field or the like. The user operates the input device 206 of the user terminal 20 to select the send button on the evaluation page D1. The control unit 204 of the user terminal 20 transmits a request including the user ID 2011 to open the evaluation page to the server 10.

[0036] When the server 10 receives the request, it searches the person in charge ID field in the project table 1013 based on the user ID 2011 and acquires one or more pieces of project information. The server 10 may also search the person in charge ID field in the project table 1013 and acquire one or more pieces of project information based on affiliation information such as the organization or group to which the user belongs. Alternatively, the server 10 may accept search conditions from the user using an input field for the project ID, etc., or other search condition input field included in the evaluation page D1, and acquire one or more pieces of project information by searching one or more items in the project table 1013 based on the search conditions. The control unit 104 of the server 10 transmits an evaluation page D1 including the acquired one or more pieces of project information to the user terminal 20. The control unit 204 of the user terminal 20 presents one or more pieces of project information to the user on the evaluation page D1 in a selectable manner. The user selects one or more pieces of project information to be subjected to the evaluation process from the one or more pieces of project information listed on the evaluation page D1. The control unit 104 of the user terminal 20 transmits a request including one or more project IDs of the selected one or more pieces of project information to the server 10. The control unit 104 of the server 10 acquires one or more project IDs included in the request. Based on the acquired one or more project IDs, the control unit 104 of the server 10 searches the project ID item in the project table 1013 and acquires one or more projects. The control unit 104 of the server 10 executes evaluation processing on the acquired one or more pieces of project information. The control unit 104 of the server 10 does not necessarily need to receive one or more pieces of project information to be subject to evaluation processing from a user, but may periodically acquire all project information stored in the project table 1013 and perform evaluation processing on the project information. Alternatively, the control unit 104 of the server 10 may periodically acquire project information of a predetermined user or a predetermined group and perform evaluation processing on the project information.

[0037] As part of the evaluation process or outside of the evaluation process, the control unit 104 of the server 10 acquires project information from an endpoint provided by an external project management service such as Jira (registered trademark), GitHub (registered trademark), Trello (registered trademark), Asana (registered trademark), Monday.com (registered trademark), or Wrike (registered trademark), and stores the information in the project table 1013. Note that the server 10 does not necessarily need to store the project table 1013, and the server 10 may directly acquire project information stored in the external project management service and execute the evaluation process.

[0038] <Task acquisition step> In step S102, the control unit 104 of the server 10 executes a task acquisition step of acquiring one or more pieces of task information related to one or more tasks associated with the project. Specifically, the control unit 104 of the server 10 searches the project ID item of the task table 1014 based on the project ID of one or more pieces of project information acquired in step S101, and acquires one or more pieces of task information. The control unit 104 of the server 10 acquires one or more pieces of task information from an endpoint provided by an external task management service, such as GitHub (registered trademark), Jira (registered trademark), GitLab (registered trademark), Azure DevOps Boards, Linear, or ClickUp (registered trademark), as part of the evaluation process or outside of the evaluation process, and stores the information in the task table 1014. Note that the control unit 104 of the server 10 does not necessarily need to store the task table 1014, and may directly acquire the task information stored in the external task management service and execute the evaluation process.

[0039] <Status acquisition steps> In step S103, the control unit 104 of the server 10 acquires one or more statuses included in each of the acquired one or more pieces of task information.

[0040] <Evaluation steps> In step S104, the control unit 104 of the server 10 executes an evaluation step of evaluating one or more tasks based on the project information or one or more pieces of task information. The evaluation step is a step of calculating the lead time of one or more tasks based on project information or information on one or more tasks.

[0041] Specifically, the control unit 104 of the server 10 acquires task data of one or more pieces of task information acquired in step S102 and one or more statuses acquired in step S102. For simplicity, the following evaluation steps will be described based on one predetermined piece of task information, the task data of that task information, and the status. The evaluation steps are similarly performed for each of the one or more pieces of task information acquired in step S102.

[0042] The evaluation step executes a step of evaluating one or more tasks based on a status indicating the progress of the one or more tasks. The control unit 104 of the server 10 searches for condition data in the rule master 1021 based on the task data included in the task information. Specifically, the control unit 104 of the server 10 determines whether the task data satisfies one or more condition data stored in the rule master 1021. If the condition data is satisfied, the control unit 104 of the server 10 acquires and identifies one or more calculation rules corresponding to the condition data. Note that the number of calculation rules identified does not need to be one; multiple calculation rules may be identified. In this case, the evaluation result (evaluation value) calculated using the calculation rule may be a statistical value (average, median, maximum, minimum, standard deviation, variance, etc.) of the evaluation results calculated using the multiple calculation rules. Alternatively, a calculation rule for calculating one evaluation result using multiple evaluation results may be separately defined, and the evaluation result may be calculated by applying the calculation rule. Furthermore, although the present disclosure has disclosed as an example whether task data satisfies condition data, this is not limiting. For example, it may be determined whether a person in charge ID, project content, project data, etc. of project information identified based on a person in charge ID, task content, and project ID associated with task information satisfies the condition data. Alternatively, one or more calculation rules may be identified based on whether any information associated with task information satisfies the condition data. The control unit 104 of the server 10 calculates an evaluation result for the task information by evaluating the status associated with the task information based on the specified calculation rule. As an example, calculation of the evaluation result for the lead time will be described. Assume that the control unit 104 of the server 10 acquires a calculation rule that defines the lead time as the time from the date and time when the status changes to "in progress" to the date and time when the status changes to "completed." In this case, the control unit 104 of the server 10 calculates the lead time as "5 days and 1 hour (121 hours)," which is the difference between the date and time when the status changes to "completed" (e.g., April 7, 2025, 11:30:00) and the date and time when the status changes to "in progress" (e.g., April 2, 2025, 10:30:00). The calculation rule may also include a rule that excludes a specified period from the lead time, such as "excluding the period under review." This allows for more accurate evaluation of the lead time, cost, investment amount, and other monetary value of tasks included in projects such as development projects based on the task status. Furthermore, by simply using the status of the user who performed the project task, tasks can be more appropriately evaluated without having to perform any work to evaluate the task.

[0043] In the past, when a project included multiple types of tasks, it was difficult to evaluate (compare) the productivity of the project from a specific perspective because the tools used for each task and the task content themselves could differ. For example, even within the same project, different management tools were used for front-end and back-end development, or different status definitions were used for design work and implementation work, making it difficult to obtain a unified evaluation index. The information processing system disclosed herein solves the above-mentioned problems by defining the tools used to manage tasks and the rules for evaluating tasks for each project and performing evaluations according to these rules. For example, even if different tools are used for tasks included in a single project, evaluation across tools is possible because the tools used are specified. Furthermore, even if rules such as lead time differ for each task, evaluation (comparison) can be performed from a specific perspective. This allows overall productivity to be grasped using consistent evaluation criteria, even for complex projects with diverse task characteristics and management methods.

[0044] <Evaluation Step (First Embodiment)> The evaluation step executes a step of calculating a lead time based on a first status and a second status identified based on the task type of one or more tasks, based on the period from when the task becomes the first status to when the task becomes the second status. Specifically, the control unit 104 of the server 10 searches for the condition data items in the rule master 1021 based on the task type of the task information, and acquires the calculation rule. For example, if the task type is "requirements definition," the control unit 104 searches for the condition data items in the rule master 1021 and acquires the calculation rule that "the lead time is from the date and time when the status changes to requirements collection start (first status) to the date and time when the status changes to requirements finalization (second status) (only working hours, excluding nights and holidays)." The calculation rule differs depending on the task type. For example, if the task type is "testing," the control unit 104 searches for the condition data items in the rule master 1021 and acquires the calculation rule that "the lead time is from the date and time when the status changes to test preparation complete (first status) to the date and time when the status changes to test completion (second status) (total number of days on the calendar)." In the present disclosure, lead time can be calculated more accurately based on the status labels for the "first status" and "second status" included in the calculation rules defined for each task type, as well as the status labels included in the task status history and date and time information. For example, if the task type is "requirements definition," the status label for the first status is "requirements gathering started," and the status label for the second status is "requirements finalized." For example, if the task type is "testing," the status label for the first status is "test preparation complete," and the status label for the second status is "testing completed." In this case, the calculation rules may be configured to store the first status label and the second status label indicating the first status and the second status. This case is also included in the calculation rules. For example, if the task type is a "design task," the status label for the first status is "design commenced," and the status label for the second status is "design approved." For example, if the task type is a "development task," the status label for the first status is "implementation commenced," and the status label for the second status is "implementation completed." For example, if the task type is a "deployment task," the status label for the first status is "deployment commenced," and the status label for the second status is "production operation confirmation." Based on these status labels, it is possible to calculate the optimal lead time for each task type. This allows for a more accurate evaluation of the lead time of tasks included in a project such as a development project based on the task type and status of the task. Also, by simply using the status of the user who performed the project task, the lead time can be calculated more appropriately without the need for additional work to measure the lead time of the task.

[0045] <Evaluation Step (Second Embodiment)> The evaluation step executes a step of calculating a lead time based on the period from when the task becomes the first status to when the task becomes the second status, based on the first status and the second status identified based on the data source of one or more tasks. Specifically, the control unit 104 of the server 10 searches for the condition data items in the rule master 1021 based on the data acquisition source of the task information, and acquires the calculation rule. For example, if the data acquisition source is "Jira," the control unit 104 searches for the condition data items in the rule master 1021 and acquires the calculation rule that "the lead time is from the date and time when the status changed to In Progress (first status) to the date and time when the status changed to Done (second status) (excluding the waiting period)." The calculation rule differs depending on the data acquisition source. For example, if the data acquisition source is "GitHub," the control unit 104 searches for the condition data items in the rule master 1021 and acquires the calculation rule that "the lead time is from the date and time when the status changed to Open (first status) to the date and time when the pull request changed to Merge (second status) (including the review waiting time)." In the present disclosure, the lead time can be calculated more accurately based on the status labels for the "first status" and "second status" included in the calculation rules defined for each data source, the status labels included in the task status history, and date and time information. For example, if the data source is "Jira," the status label for the first status is "In Progress" and the status label for the second status is "Done." This allows for a more accurate evaluation of the lead time of tasks included in projects such as development projects, based on the data source and status of the task. Also, by simply using the status of the user who performed the project task, the lead time can be calculated more appropriately without the need for separate work to measure the lead time of the task. In particular, this disclosure allows for the application of appropriate evaluation rules even when the data source service and usage pattern (in-house team development or outsourcing) differ depending on the task type. For example, consider a complex project where design tasks are managed with a dedicated design tool, development tasks are managed with GitHub, and testing tasks are managed with Jira. Even in such a case, the project lead time can be appropriately evaluated by defining a "first status" and a "second status" according to the combination of each task type and data source. Furthermore, even for the same type of task, different tools and workflows may be used when an in-house team handles it versus when an outsourced team handles it. Even in such cases, by setting calculation rules appropriate for each situation, it is possible to appropriately evaluate each project. This allows for consistent evaluation of the lead time for the entire project.

[0046] <Evaluation Step (Third Embodiment)> The evaluation step executes a step of calculating a lead time based on the period from when the task becomes the first status to when the task becomes the second status, based on the first status and the second status identified based on the project information. Specifically, the control unit 104 of the server 10 searches for the condition data items in the rule master 1021 based on the project information associated with the task information, and acquires the calculation rule. For example, if the project information (project content) is an "EC site renewal project," the control unit 104 searches for the condition data items in the rule master 1021 and acquires a calculation rule that defines the lead time as the time from the date and time when the status changes to design approval (first status) to the date and time when the status changes to production release (second status) (excluding the client confirmation period). The calculation rule differs depending on the project information (project content, project data). For example, if the project information (project content) is an "in-house system development project," the control unit 104 searches for the condition data items in the rule master 1021 and acquires a calculation rule that defines the lead time as the time from the date and time when the status changes to requirements definition start (first status) to the date and time when user testing is completed (second status) (none, including all time). In the evaluation step (third embodiment), an example in which calculation rules are acquired by referring to the rule master 1021 has been disclosed as an example, but this is not limiting. For example, calculation rules for each piece of project information may be stored in a column (not shown) or the like, such as project data of project information associated with task information. Alternatively, calculation rules may be stored in a column (not shown) or the like, such as task data of task information. In other words, calculation rules may be defined differently for each project and task. In this case, tasks can be evaluated based on calculation rules individually defined for each project and task. This allows for a more accurate evaluation of the lead time of tasks included in projects such as development projects based on project information, such as definition information, and statuses defined for each project. Also, by simply using the statuses entered by the users who performed the project tasks, the lead time can be calculated more appropriately without the need for separate work to measure the lead time of the tasks.

[0047] In the evaluation steps (first embodiment) to (third embodiment), a rule-based method for calculating the lead time has been described as an example, but the present invention is not limited to this. For example, the lead time may be calculated by inputting the status into a machine learning model, deep learning model, artificial intelligence model, or the like that has been trained in advance to be able to output the lead time based on the change history of the status.

[0048] <Evaluation Step (Fourth Embodiment)> The evaluation step is a step of calculating a monetary value for one or more tasks based on project information or one or more task information. The evaluation step is a step of calculating the monetary value of one or more tasks based on the calculated lead time and the value per unit time of one or more tasks. The evaluation step is a step of calculating the monetary value of one or more tasks based on the calculated lead time and the value per unit time defined for each of the one or more tasks. Specifically, the control unit 104 of the server 10 calculates the monetary value of one or more tasks by multiplying the lead time calculated in the evaluation steps (first embodiment) to (third embodiment) by the value per unit time of one or more tasks. For example, if the lead time of a specific task is calculated to be 10 days and the value per unit time (man-days) is 50,000 yen, the monetary value of one or more tasks is calculated to be 500,000 yen. Such monetary values ​​are also included in the evaluation results of the tasks. Note that the monetary value of a task may include not only the monetary cost required for the task but also the investment amount required to realize the task. The value per unit time can be defined individually for each task or for each task type. For example, the value per unit time for a requirements definition task can be defined as A yen per man-day, and the value per unit time for a new test task can be defined as B yen per man-day. Since labor costs for engineers and other personnel typically vary significantly depending on the task type, this allows for more accurate task evaluation. Also, since the quantity of task types is small compared to defining value for each task, defining value for each small task type allows for more accurate calculation of the monetary value for each task. Furthermore, based on the person in charge ID in the task information and project information, the value per unit time of the person in charge (information such as person-hours, person-days, person-months, hourly rate, salary, wages, etc.) can be stored in the user data obtained by searching the user ID item in the user table 1012, and the monetary value of one or more tasks can be calculated by multiplying the lead time by this value. Alternatively, the monetary value of a task may be calculated by inputting the lead time into a machine learning model, deep learning model, artificial intelligence model, etc. that has been trained in advance by an organization, group, company, etc. This makes it possible to calculate the cost of tasks included in projects such as development projects, monetary values ​​such as investment amounts, etc.

[0049] In the present disclosure, a method for calculating the monetary value of a task based on the calculated lead time has been disclosed as an example, but the present disclosure is not limited to this. For example, a method for calculating the monetary value of a task directly from the status of the task may be used. For example, the monetary value of a task may be calculated by inputting the status of the task into a machine learning model, deep learning model, artificial intelligence model, or the like that has been trained in advance to be able to output the monetary value of the task based on the change history of the status. <Evaluation Steps (Variations)> In the present disclosure, an example of evaluating the lead time and monetary value of a task based on the task status has been given as an example, but this is not limiting. For example, task information may be evaluated using at least one or more pieces of information, such as a person in charge ID, task content, and project information identified based on a project ID, associated with the task information, such as a person in charge ID, project content, and project data. The task information may be evaluated based on the calculation rules in the rule master 1021, or may be calculated using any machine learning model, deep learning model, artificial intelligence model, etc.

[0050] The control unit 104 of the server 10 stores the calculated evaluation result in the evaluation data item of the corresponding record in the task table 1014. As a result, the evaluation data is stored in association with the task.

[0051] <Project evaluation steps> In step S105, the control unit 104 of the server 10 executes a project evaluation step of evaluating the project based on the evaluation results of one or more tasks evaluated in the evaluation step. Specifically, the control unit 104 of the server 10 calculates the evaluation result of the project by aggregating the evaluation results of one or more tasks calculated in step S104. For example, the control unit 104 of the server 10 calculates the sum, weighted sum, etc. of the evaluation results of one or more tasks associated with the project as the evaluation result of the project acquired in step S101. In this way, the evaluation result of the project can be calculated. For example, when the evaluation result is a lead time, the control unit 104 of the server 10 calculates the lead time of the project as the sum, weighted sum, or the like, of the lead times of one or more tasks associated with the project. This allows the project associated with one or more tasks to be evaluated based on the evaluation results of the tasks. For example, the lead time, cost, investment amount, and other monetary values ​​of the development project can be evaluated.

[0052] The control unit 104 of the server 10 stores the calculated evaluation result in the evaluation data item of the corresponding record in the project table 1013. As a result, the evaluation data is stored in association with the project.

[0053] <Evaluation presentation process> The evaluation presentation process is a process of presenting the evaluation results of the evaluation process to the user.

[0054] <Outline of evaluation presentation process> The evaluation presentation process is a series of processes including an evaluation acquisition step of acquiring the evaluation results of the evaluation process, an analysis step of analyzing the acquired evaluation results, and an evaluation presentation step of presenting the analyzed evaluation results.

[0055] <Details of evaluation presentation process> The evaluation presentation process will be described in detail below.

[0056] <Steps to obtain an evaluation> In step S301, the control unit 104 of the server 10 executes an evaluation acquisition step of acquiring an evaluation result. The user operates the input device 206 of the user terminal 20 to execute a browser application or the like, and opens the evaluation presentation page D3 by inputting the URL of a web page (evaluation presentation page) for executing the evaluation presentation process. The evaluation presentation page D3 includes input fields for the project ID, etc., as well as a search condition input field and a send button. The user operates the input device 206 of the user terminal 20 to input project identification information in the project ID input field. The user may also enter any search conditions for searching for project information stored in the project table 1013 in the search condition input field or the like. The user operates the input device 206 of the user terminal 20 to select the send button on the evaluation presentation page D3. The control unit 204 of the user terminal 20 sends a request to the server 10, including the user ID 2011, to open the evaluation presentation page. In the present disclosure, an example will be described in which a user inputs multiple pieces of project identification information (two pieces of project identification information) into the project ID input field. Note that the user may input one piece of project identification information into the project ID input field, or may input three or more pieces of project identification information.

[0057] When the control unit 104 of the server 10 receives the request, it searches the project ID item of the project table 1013 based on the one or more project IDs included in the request, and acquires one or more pieces of project information. Based on the project ID of the acquired project information, the control unit 104 of the server 10 searches the project ID item of the task table 1014, and acquires one or more pieces of task information.

[0058] <Analysis steps> In step S302, the control unit 104 of the server 10 executes an analysis step for the acquired project information. Specifically, the control unit 104 of the server 10 performs the following analysis process on one or more pieces of acquired project information. For simplicity, the following analysis steps will explain the analysis process on one specific piece of project information and one or more pieces of task information identified by searching the project ID item in the task table 1014 based on the project ID of the project information. The same analysis process is performed on each of the multiple pieces of project information.

[0059] The control unit 104 of the server 10 acquires the evaluation data included in one or more pieces of task information associated with the acquired project information.

[0060] The control unit 104 of the server 10 aggregates evaluation data for each task type of one or more pieces of task information. For example, the control unit 104 organizes multiple pieces of task information into task types such as "requirements definition," "design," "coding," "test," and "deployment," and calculates an evaluation result for each task type. For example, given task information such as Task A (requirements definition, lead time 5 days), Task B (requirements definition, lead time 3 days), Task C (design, lead time 4 days), Task D (design, lead time 6 days), Task E (coding, lead time 7 days), Task F (coding, lead time 8 days), Task G (coding, lead time 4 days), Task H (testing, lead time 3 days), Task I (testing, lead time 5 days), and Task J (deployment, lead time 2 days), the control unit 104 calculates the total lead time of Task A and Task B, which belong to the task type "requirements definition," as 8 days (= 5 + 3), and sets this as the evaluation result for the task type "requirements definition." Similarly, the evaluation result for the task type "design" is 10 days (= 4 + 6), the evaluation result for the task type "coding" is 19 days (= 7 + 8 + 4), the evaluation result for the task type "testing" is 8 days (= 3 + 5), and the evaluation result for the task type "deployment" is 2 days. This allows the control unit 104 of the server 10 to easily compile evaluation results for each task type for the task information included in the project information. For example, it is possible to easily check which task type requires the most lead time for each task type, such as "requirements definition," "design," "coding," "testing," and "deployment." Similarly, you can aggregate the data based on the source of the task or project (GitHub, Jira, etc.). For example, the GitHub evaluation result is 5 days old, and the Jira evaluation result is 8 days old. Additionally, it is not necessarily necessary to tally the results by task type, data source, etc., and a configuration may be adopted in which the breakdown of the evaluation results for each of the multiple tasks that make up the project is presented in a manner that allows each to be confirmed. For example, the breakdown of the evaluation results for each task that makes up the project may be presented directly, such as Task A (5 days), Task B (3 days), Task C (4 days), Task D (6 days), Task E (7 days), Task F (8 days), Task G (4 days), Task H (3 days), Task I (5 days), Task J (2 days), etc.

[0061] <Evaluation submission steps> In step S303, the control unit 104 of the server 10 executes an evaluation presentation step of presenting the evaluation results of one or more tasks evaluated in the evaluation step. Specifically, the control unit 104 of the server 10 generates an evaluation presentation page D3 based on the analysis results obtained in the analysis step of step S303, and transmits the generated evaluation presentation page D3 to the user terminal 20. The control unit 204 of the user terminal 20 displays and presents the evaluation presentation page on the display 2081 of the user terminal 20.

[0062] The control unit 104 of the server 10 executes a presentation step of presenting the evaluation results of one or more tasks associated with a plurality of different projects in a manner that allows comparison for each project. The presentation step is a step of presenting the evaluation results of one or more tasks associated with the project in a manner that allows comparison for each breakdown of task type. 10 shows an example of an evaluation presentation screen in the evaluation presentation process. Evaluation presentation page D3 includes evaluation results D31 of the first project and evaluation results D32 of the second project. The evaluation result D31 of the first project includes a requirements definition object D311 indicating requirements definition, design, coding, testing, and deployment, a design object D312, a coding object D313, a test object D314, and a deployment object D315. It also includes a total object D316 indicating the total of these. The evaluation result D32 of the second project includes a requirements definition object D321, a design object D322, a coding object D323, a test object D324, and a deployment object D325, which indicate requirements definition, design, coding, testing, and deployment, as well as a total object D326 indicating the total of these. The evaluation result D32 for the second project is presented in association with the first task D3211, the second task D3212, and the third task D3213, allowing the user to check the breakdown of the evaluation results for each task included in the project. This allows the user to easily check what task types and what tasks require the most lead time for the project. The user can check the evaluation results of the first and second projects by checking the evaluation presentation page D3. The user can also compare and check the evaluation results for each task type that makes up the breakdown of multiple projects. This allows service users to compare and confirm the evaluation results of multiple different projects by task. Service users can also compare and confirm the evaluation results of multiple different projects by task type. For example, they can compare and confirm the breakdown and percentage of evaluation results (including lead time, cost, investment amount, and other monetary values) for each task type, such as requirements definition tasks and test tasks, included in a project.

[0063] <Basic computer hardware configuration> 11 is a block diagram showing the basic hardware configuration of a computer 90. The computer 90 includes at least a processor 901, a main memory device 902, an auxiliary memory device 903, and a communication IF 991 (interface), which are electrically connected to one another by a communication bus 921.

[0064] The processor 901 is hardware for executing an instruction set written in a program, and is composed of an arithmetic unit, registers, peripheral circuits, and the like.

[0065] The main memory device 902 is used to temporarily store programs, data to be processed by the programs, etc. For example, it is a volatile memory such as a DRAM (Dynamic Random Access Memory).

[0066] The auxiliary storage device 903 is a storage device for saving data and programs, such as a flash memory, a hard disk drive (HDD), a magneto-optical disk, a CD-ROM, a DVD-ROM, or a semiconductor memory.

[0067] The communication IF 991 is an interface for inputting and outputting signals for communicating with other computers via a network using wired or wireless communication standards. The network is composed of the Internet, a LAN, various mobile communication systems constructed by wireless base stations, etc. For example, the network includes 3G, 4G, and 5G mobile communication systems, LTE (Long Term Evolution), and wireless networks (e.g., Wi-Fi (registered trademark)) that can connect to the Internet via a predetermined access point. In the case of a wireless connection, communication protocols include, for example, Z-Wave (registered trademark), ZigBee (registered trademark), and Bluetooth (registered trademark). In the case of a wired connection, the network also includes a direct connection using a USB (Universal Serial Bus) cable, etc.

[0068] It should be noted that the computer 90 can be virtually realized by distributing all or part of each hardware configuration across multiple computers 90 and interconnecting them via a network. In this way, the computer 90 is a concept that includes not only a computer 90 housed in a single housing or case, but also a virtualized computer system.

[0069] <Basic functional configuration of computer 90> The following describes the functional configuration of a computer realized by the basic hardware configuration (FIG. 11) of the computer 90. The computer includes at least the functional units of a control unit, a storage unit, and a communication unit.

[0070] The functional units of the computer 90 can also be realized by distributing all or part of the functional units among multiple computers 90 interconnected via a network. The computer 90 is a concept that includes not only a single computer 90 but also a virtualized computer system.

[0071] The control unit is realized by the processor 901 reading out various programs stored in the auxiliary storage device 903, expanding them in the main storage device 902, and executing processing in accordance with the programs. The control unit can realize functional units that perform various types of information processing depending on the type of program. In this way, the computer is realized as an information processing device that performs information processing.

[0072] The functions performed by the components described herein may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), a CPU (a Central Processing Unit), conventional circuits, and / or combinations thereof, programmed to perform the described functions. A processor includes transistors and other circuits and is considered to be circuitry or processing circuitry. A processor may also be a programmed processor that executes programs stored in memory. In this specification, a circuitry, unit, or means is hardware that is programmed to realize or performs the described functions, which may be any hardware disclosed herein or any hardware known to be programmed to realize or perform the described functions. If the hardware is a processor considered to be a type of circuitry, the circuitry, means, or unit is a combination of the hardware and software used to configure the hardware and / or processor.

[0073] The storage unit is realized by a main storage device 902 and an auxiliary storage device 903. The storage unit stores data, various programs, and various databases. Furthermore, the processor 901 can allocate a storage area corresponding to the storage unit in the main storage device 902 or the auxiliary storage device 903 in accordance with the programs. Furthermore, the control unit can cause the processor 901 to execute processes for adding, updating, and deleting data stored in the storage unit in accordance with the various programs.

[0074] A database refers to a relational database, which manages data sets called masters and tables in a tabular format structurally defined by rows and columns, by relating them to each other. In a database, a table is called a table, a master, a column in a table is called a column, and a row in a table is called a record. In a relational database, relationships between tables and masters can be set and associated. Typically, each table and each master has a column set as a primary key to uniquely identify a record, but setting a primary key to a column is not essential. The control unit can cause the processor 901 to add, delete, or update records in specific tables and masters stored in the storage unit according to various programs. Furthermore, by storing data, various programs, and various databases in the storage unit, it can be considered that the information processing device and information processing system according to the present disclosure have been manufactured.

[0075] Note that the databases and masters in this disclosure may include any data structure in which information is structurally defined (such as a list, dictionary, associative array, or object). The data structure also includes data that can be considered as a data structure by combining data with functions, classes, methods, etc. written in any programming language.

[0076] Furthermore, the information, data, etc. disclosed in this disclosure are intended to exemplify one concept of the information, data, etc., and are not intended to limit the concept. For example, information, data, etc. also include information, data, etc. that has been converted or summarized. For example, in the case where user data is data related to a user, such as the user's name, date of birth, occupation, etc., the user data may also include text describing an overview of the user that has been converted (summarized) using predetermined rules or other artificial intelligence systems such as generation AI.

[0077] The communication unit is realized by the communication IF 991. The communication unit realizes a function of communicating with other computers 90 via a network. The communication unit can receive information transmitted from other computers 90 and input the information to the control unit. The control unit can cause the processor 901 to execute information processing on the received information in accordance with various programs. In addition, the communication unit can transmit information output from the control unit to other computers 90.

[0078] <About the prompt> A prompt is a query (including text, character strings, images, videos, audio, etc.) that is input to artificial intelligence systems, such as generative AI and large-scale language models. By inputting a prompt to an artificial intelligence system, a user can instruct the system on how to process information. A user can input a prompt to the AI ​​system so that the AI ​​system will output a desired result. Note that the prompt does not have to be a character string, but can be an image, video, audio, or other prompt. For example, a user's gesture, voice instruction, or other prompt can also be a prompt.

[0079] <About creating prompts> A prompt can be input by a user's input operation on a user terminal. Also, a document file, an image, a video, an audio, etc. can be uploaded and input as a prompt. A user can create a prompt by combining an instruction input by inputting on a user terminal with other instructions, data, etc. In this case, the prompt may include one or more instruction sentences, data, etc. Also, the prompt may include only one or more instruction sentences or one or more data. A prompt can be created by including part of an instruction, data, etc. with another instruction, data, etc. A prompt can be created by inserting a portion of an instruction, data, etc. into another instruction, data, etc. Prompts can be created by combining instructions, data, etc. with other instructions, data, etc. A prompt can be created by combining instructions, data, etc. with other instructions, data, etc. A prompt can be created by adding instructions, data, etc. to other instructions, data, etc. In this disclosure, expressions such as "include," "insert," "combine," "combine," and "append" used when creating prompts from directives, data, and the like are used as terms that refer to the same information processing process. In other words, these can be treated as the same information processing process in that the same prompt is created based on one or more directives, data, and the like. For example, the term "include" encompasses information processing such as "insert," "combine," "combine," and "append." Similarly, "insert," "combine," "combine," and "append" also encompass information processing such as "include," "insert," "combine," "combine," and "append," respectively.

[0080] <Additional Notes> The matters described in the above embodiments will be supplemented below.

[0081] (Appendix 1) A program to be executed by a computer having a processor and a memory unit, the program executing a project acquisition step (S101) in which the processor acquires project information related to a project, a task acquisition step (S102) in which one or more pieces of task information related to one or more tasks associated with the project based on the project information, and an evaluation step (S104) in which the one or more tasks are evaluated based on the one or more pieces of task information. This makes it possible to evaluate the lead time of tasks included in projects such as development projects, as well as monetary values ​​such as costs and investment amounts.

[0082] (Appendix 2) 2. The program according to claim 1, wherein the evaluation step (S104) is a step of evaluating one or more tasks based on project information. This makes it possible to evaluate the lead time, cost, investment amount, and other monetary values ​​of tasks included in projects such as development projects based on the project information.

[0083] (Appendix 3) The program according to appendix 1, wherein the evaluation step (S104) is a step of calculating a lead time of one or more tasks based on a status of the task information included in the project information or the one or more pieces of task information. This makes it possible to evaluate the lead time, cost, investment amount, and other monetary value of tasks included in projects such as development projects based on the status included in the task information.

[0084] (Appendix 4) 2. The program according to claim 1, wherein the evaluation step (S104) is a step of calculating a monetary value of one or more tasks based on project information or one or more task information. This makes it possible to calculate the cost of tasks included in projects such as development projects, monetary values ​​such as investment amounts, etc.

[0085] (Appendix 5) 2. The program according to claim 1, wherein the evaluation step (S104) is a step of evaluating one or more tasks based on a status indicating progress of the one or more tasks. This allows for more accurate evaluation of the lead time, cost, investment amount, and other monetary value of tasks included in projects such as development projects based on the status of the tasks. Furthermore, by simply using the status of the user who performed the task of the project, the task can be more appropriately evaluated without performing any work for evaluating the task.

[0086] (Appendix 6) The program described in Appendix 1, wherein the evaluation step (S104) is a step of calculating a lead time based on the period from when the task becomes the first status to when the task becomes the second status, based on the first status and the second status identified based on the task type of one or more tasks. This allows for a more accurate evaluation of the lead time of tasks included in a project such as a development project based on the task type and status of the task. Furthermore, by simply using the status of the user who performed the task in the project, the lead time can be calculated more appropriately without the need for additional work to measure the lead time of the task.

[0087] (Appendix 7) The program described in Appendix 1, wherein the evaluation step (S104) is a step of calculating a lead time based on the period from when the task becomes the first status to when the task becomes the second status, based on the first status and the second status identified based on the data source of one or more tasks. This allows for a more accurate evaluation of the lead time of tasks included in a project such as a development project based on the data source and status of the task. Furthermore, by simply using the status of the user who performed the task in the project, the lead time can be calculated more appropriately without the need for additional work to measure the lead time of the task.

[0088] (Appendix 8) The program described in Appendix 1, wherein the evaluation step (S104) is a step of calculating a lead time based on the period from when the task becomes the first status to when the task becomes the second status, based on the first status and the second status identified based on the project information. This makes it possible to more accurately evaluate the lead time of tasks included in a project such as a development project based on project information such as definition information defined for each project and the status. Furthermore, by simply using the status of the user who performed the task in the project, the lead time can be calculated more appropriately without the need for additional work to measure the lead time of the task.

[0089] (Appendix 9) A program described in any of Appendices 6 to 8, wherein the evaluation step (S104) is a step of calculating the monetary value of one or more tasks based on the calculated lead time and the value per unit time of one or more tasks. This makes it possible to calculate monetary values ​​such as the cost of the task, the investment amount, etc. based on the calculated lead time. For example, by multiplying the lead time by information (unit cost information, unit expense information) that indicates the monetary value per unit time such as man-hours, man-days, man-months, etc., it is possible to calculate the monetary values ​​such as the investment amount, expenses, etc. required to accomplish the task.

[0090] (Appendix 10) The program according to any one of Appendices 6 to 8, wherein the evaluation step (S104) is a step of calculating the monetary value of one or more tasks based on the calculated lead time and the value per unit time defined for each task type of the one or more tasks. This allows projects associated with one or more tasks to be evaluated based on the evaluation results of the tasks. For example, it is possible to evaluate the lead time of a development project, as well as monetary values ​​such as costs and investment amounts.

[0091] (Appendix 11) A program according to any one of appendices 1 to 8, wherein the processor executes a project evaluation step (S105) of evaluating the project based on the evaluation results of one or more tasks evaluated in the evaluation step. This allows projects associated with one or more tasks to be evaluated based on the evaluation results of the tasks. Since labor costs for engineers and others vary greatly depending on the type of task, tasks can be evaluated more accurately.

[0092] (Appendix 12) 9. The program according to any one of appendices 1 to 8, wherein the processor executes an evaluation presentation step (S303) of presenting the evaluation results of one or more tasks evaluated in the evaluation step. This allows users of the service to check the evaluation results for tasks, for example, the breakdown of evaluations for each task included in a project such as a development project. Specifically, you can check the evaluation results for Task A, Task B, and Task C that make up the project. You can also check the breakdown of the evaluation results.

[0093] (Appendix 13) A program according to any one of appendices 1 to 8, wherein a processor executes a presentation step (S303) of presenting the evaluation results of one or more tasks associated with a plurality of different projects in a manner that allows comparison for each project. This allows users of the service to compare and check the evaluation results of multiple different projects for each task.

[0094] (Appendix 14) The program according to claim 13, wherein the presentation step (S303) is a step of presenting the evaluation results of one or more tasks associated with the project in a manner that allows comparison for each task type. This allows users of the service to compare and check the evaluation results of multiple different projects by task type. For example, it is possible to compare and confirm the breakdown and percentage of the evaluation results (lead time, cost, investment amount, etc.) for each task type, such as requirement definition tasks and test tasks, included in the project.

[0095] (Appendix 15) A method executed by an information processing device having a processor and a memory unit, wherein the processor executes all of the steps executed in the invention according to any one of Supplementary Notes 1 to 8. This makes it possible to evaluate the lead time of tasks included in projects such as development projects, as well as monetary values ​​such as costs and investment amounts.

[0096] (Appendix 16) An information processing device comprising a processor and a memory unit, wherein the processor executes all of the steps executed in the invention according to any one of appendices 1 to 8. This makes it possible to evaluate the lead time of tasks included in projects such as development projects, as well as monetary values ​​such as costs and investment amounts.

[0097] (Appendix 17) A system comprising means for performing all steps performed in any of the inventions according to appendices 1 to 8. This makes it possible to evaluate the lead time of tasks included in projects such as development projects, as well as monetary values ​​such as costs and investment amounts. [Explanation of symbols]

[0098] 1 system, 10 server, 101 memory unit, 104 control unit, 106 input device, 108 output device, 20 user terminal, 201 memory unit, 204 control unit, 206 input device, 208 output device

Claims

1. A program to be executed by a computer having a processor and a storage unit, the processor: a project acquisition step of acquiring project information relating to a project, the project information being associated with a calculation rule for calculating a lead time; a task acquisition step of acquiring one or more pieces of task information related to one or more tasks associated with the project based on the project information, the task information being associated with statuses of the one or more tasks; an evaluation step of evaluating the one or more tasks based on the one or more pieces of task information; Run The evaluation step is a step of calculating a lead time of the one or more tasks based on the status of the one or more tasks and the calculation rule. program.

2. The evaluating step includes: calculating a lead time based on a period from when the task becomes the first status to when the task becomes the second status, based on a first status and a second status identified based on the task type of the one or more tasks; The program according to claim 1.

3. The evaluating step includes: a step of calculating a lead time based on a period from when the task becomes the first status to when the task becomes the second status, based on the first status and the second status identified based on the data acquisition source of the one or more tasks; The program according to claim 1.

4. The evaluating step includes: a step of calculating a lead time based on the period from when the task becomes the first status to when the task becomes the second status, based on the first status and the second status identified based on the project information; The program according to claim 1.

5. the evaluation step is a step of calculating a monetary value of the one or more tasks based on the calculated lead time and a value per unit time of the one or more tasks; 5. The program according to claim 2.

6. the evaluation step is a step of calculating a monetary value of the one or more tasks based on the calculated lead time and a value per unit time defined for each task type of the one or more tasks; 5. The program according to claim 2.

7. the processor: a project evaluation step of evaluating the project based on the evaluation results of the one or more tasks evaluated in the evaluation step; To execute 5. The program according to claim 1.

8. the processor: an evaluation presentation step of presenting an evaluation result of the one or more tasks evaluated in the evaluation step; To execute 5. The program according to claim 1.

9. the processor: a presentation step of presenting evaluation results of one or more tasks associated with a plurality of different projects in a manner that allows comparison for each project; To execute 5. The program according to claim 1.

10. The presenting step is a step of presenting evaluation results of one or more tasks associated with the project in a manner that allows comparison for each task type. The program according to claim 9.

11. A method executed by an information processing device including a processor and a storage unit, wherein the processor executes all of the steps executed in the invention according to any one of claims 1 to 4.

12. 5. An information processing device comprising a processor and a storage unit, wherein the processor executes all of the steps executed in the invention according to any one of claims 1 to 4.

13. A system comprising means for executing all steps performed in an invention according to any one of claims 1 to 4.

Images