JP7168966B2 - Program, information processing device and method - Google Patents

Description

Article 30, paragraph 2 of the Patent Act applied January 22, 2020, April 15, July 14, August 3, August 18, September 24, 2020 Findy Co., Ltd. website, etc. publication

The present disclosure relates to programs, information processing apparatuses, and methods.

Product development in corporate activities is often carried out by a team of multiple engineers. In product development by a team, it is necessary to appropriately allocate personnel within the team, appropriately review the deliverables, and maximize the performance of the team.

Patent Literature 1 discloses an activity analysis technique for analyzing the organization and individuality of activities in corporate activities. This technology is a method for analyzing an organization by obtaining information on participants who were simultaneously involved in an activity where multiple people can intervene at the same time, such as a meeting, from the position information of the participants. .

JP 2008-027017 A

By the way, when evaluating the performance of an engineer team composed of engineers who develop products, etc., it is necessary to appropriately grasp the deliverables of the team. For that purpose, it is necessary to grasp not only the number of deliverables by each engineer who is a member of the engineering team, but also what kind of process is going through within the team. There has been a need for a method to properly grasp the performance of such an engineering team.

Therefore, in the present disclosure, a technique for appropriately evaluating performance as an engineering team will be described.

According to one embodiment of the present disclosure, there is provided a program to be executed by a computer having a processor and a storage unit. The program stores information uploaded online by members belonging to the engineering team in order to create deliverables as engineers, and review information conducted by members of the engineering team on the uploaded deliverables to the processor. and the step of identifying a parameter representing the activity status of the engineering team, and the step of presenting the parameter to the user.

According to this disclosure, based on the history of the information uploaded to create deliverables as an engineer and the review information of the uploaded deliverables performed by members of the engineer team, the activities of the engineer team Identify the parameters that describe the situation. Therefore, it becomes possible to appropriately grasp the performance as an engineering team.

It is a figure which shows the structure of the whole team activity evaluation system 1. FIG. 2 is a block diagram showing a functional configuration of terminal device 10 configuring team activity evaluation system 1 of Embodiment 1. FIG. 2 is a diagram showing a functional configuration of server 20 that constitutes team activity evaluation system 1 of Embodiment 1. FIG. 3 is a diagram showing the data structure of a repository database 2021 stored by the server 20. FIG. 4 is a diagram showing data structures of an individual performance database 2022 and a team score database 2023 stored by the server 20. FIG. 4 is a flow chart showing an example of the flow of scoring processing by the team activity evaluation system 1 of Embodiment 1. FIG. 7 is a flow chart showing an example of the flow of team activity status presentation processing by the team activity evaluation system 1 of the first embodiment. 4 is a diagram showing an example of a sign-in screen displayed on the terminal device 10. FIG. 6 is a diagram showing an example of a display screen of team activity status displayed on the terminal device 10. FIG. 4 is a diagram showing an example of a pull request status display screen displayed on the terminal device 10. FIG. FIG. 11 is a diagram showing another display screen example of team status displayed on the terminal device 10. FIG. FIG. 10 is a diagram showing an example of a display screen of the lead time and pull request status displayed on the terminal device 10. FIG. FIG. 10 is a diagram showing an example of a pull request type status display screen displayed on the terminal device 10. FIG. FIG. 10 is a diagram showing an example of a display screen of a pull request state displayed on the terminal device 10. FIG. FIG. 10 is a diagram showing an example of a display screen of a review implementation status displayed on the terminal device 10. FIG. 4 is a diagram showing an example of a display screen of alert information displayed on the terminal device 10. FIG. FIG. 10 is a diagram showing an example of a member's performance display screen displayed on the terminal device 10. FIG. FIG. 10 is a diagram showing an example of a display screen of a member's pull request status displayed on the terminal device 10. FIG. FIG. 10 is a diagram showing an example of a display screen for team comparison of team activity statuses displayed on the terminal device 10; FIG. 10 is a diagram showing a functional configuration of a server 20 that constitutes the team activity evaluation system 1 of Embodiment 2; 3 is a diagram showing the data structure of an engineer database 2024 stored by the server 20. FIG. FIG. 10 is a diagram showing an example of an engineer's recommendation display screen displayed on the terminal device 10. FIG.

Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the following description, the same parts are given the same reference numerals. Their names and functions are also the same. Therefore, a detailed description thereof will not be repeated.

<Overview>
A team activity evaluation system according to the present disclosure will be described below. This team activity evaluation system is a system for identifying and evaluating a team score (parameter) indicating the activity status (performance) of an engineer team, which is composed of engineers who develop products and the like. Here, the engineering team is a team composed of a plurality of engineers and for promoting the development of specific products, such as web services and websites provided by so-called SaaS (Software as a Service), Within the team, each engineer divides roles for each function of the service, each output, etc., and proceeds with development. In addition, the engineers in the team are not limited to employees employed by a specific company, but may be individual employees in a development project jointly developed by multiple companies. A so-called freelance engineer may also be included.

The team activity evaluation system according to the present disclosure accesses GitHub (registered trademark), which is a software development platform, as an example, in order to identify the team score indicating the activity status of the engineer team, and the engineer who is a member of the engineer team Acquire various parameters that indicate the results of GitHub is a source code hosting service, has a repository (management means) for version management of source codes that are products, and manages a list of source codes at a certain point in time. In addition, GitHub is used for issues (creation) for managing projects and source code issues, push for uploading source code created or modified in the engineer's local environment (local repository) to the remote environment (remote repository), It has functions such as a pull request that notifies that a push has been made and requests a review, a commit that adopts comments and corrections during the review, and a merge that confirms the review results and integrates the history. Here, the source code is a concept including a programming language such as Python and a script language which is a kind of programming language such as JavaScript (registered trademark). That is, the team activity evaluation system according to the present disclosure acquires parameters related to deliverables managed by an external server (cloud server), and does not require monitoring of the usage status of individual PCs. It is a system that shows the situation.

A programming language is a language used for software development, specifically HTML, CSS, JavaScript (registered trademark), Java (registered trademark), Scala, PHP, Ruby, Python, Go, C#, Node .js etc. A software framework is a software platform used for software development. Specifically, jQuery, React, Vue.js, Angular, Nuxt.js, Next.js, ReactNative, Spring Framework, Play Framework, Laravel, CakePHP, RubyonRails, Django, Flask, TensorFlow, gin, Unity, Express, etc.

As various parameters that indicate the activity status of the engineering team, the number of pushes to GitHub (number of uploads), the number of source code created on GitHub, the number of modified codes, the number of pull requests (number of review requests) managed by GitHub, By acquiring values such as the number of merges (the number of integrations), the deliverables of the engineering team are digitized as information uploaded online, and a score is calculated. From this, it is considered possible to estimate the activity status of the engineering team from the quantitative aspect of the deliverables. For example, if the number of source codes created, the number of modified codes, and the number of pushes are large, it can be said that the engineering team has created many deliverables, so it can be said that the activity of creating deliverables by the engineering team is active. Presumed. Therefore, it is considered that the activity status of the engineer team for the deliverable can be estimated in terms of quantity of the deliverable, depending on the amount of this score.

In addition, as various parameters that indicate the activity status of the engineering team, by acquiring values such as the number of issues created, the number of reviews, the number of comments, the number of comment responses, and the number of commits managed by GitHub, these values is included, quantified as review information performed by members of the engineering team, and a score is calculated. From this, it is considered possible to estimate the activity status of the engineering team from the qualitative aspect of the deliverables. For example, if the number of reviews and comments is large, it can be said that there are many checks and discussions on the deliverables within the engineering team. It is estimated that there is a high tendency Therefore, it is considered that the activity status of the engineer team for the deliverable can be estimated from the qualitative aspect of the deliverable, depending on the amount of this score.

Furthermore, by presenting these team scores in association with time-series information, it is possible to grasp the activity status of the engineering team in time-series. For example, if the team score in a particular period (e.g., one week) is low compared to other periods, it is presumed that either the creation of the deliverables, the review of the deliverables, or both were stagnant during that period. Therefore, the situation of the team can be grasped at an early stage, which contributes to the identification of the cause.

Therefore, in the team activity evaluation system according to the present disclosure, the values of various parameters in GitHub are acquired, and the team score indicating the activity status of the engineer team is specified from these values. This team score is presented to members of the engineering team and administrators who manage the engineering team (team managers, personnel department personnel, executives, etc.). With such a configuration, it is possible to more objectively present the activity status of the engineering team and have them grasp it. Note that the product of the engineering team is a concept that includes setting information, databases, various specifications, etc. on the system in addition to the source code in GitHub, but in this embodiment, the source code in GitHub will be described as an example.

<First Embodiment>
The team activity evaluation system 1 will be described below. In the following description, for example, when the terminal device 10 accesses the server 20 , the server 20 responds with information for generating a screen on the terminal device 10 . The terminal device 10 generates and displays a screen based on information received from the server 20 .

<Overall configuration of 1 team activity evaluation system 1>
FIG. 1 is a diagram showing the overall configuration of a team activity evaluation system 1. As shown in FIG. As shown in FIG. 1, the team activity evaluation system 1 includes a plurality of terminal devices (terminal device 10A and terminal device 10B are shown in FIG. 1; hereinafter collectively referred to as "terminal device 10"). , a server 20 and a repository server 30 . The terminal device 10, the server 20, and the repository server 30 are connected via a network 80 so as to be able to communicate with each other. Network 80 is configured by a wired or wireless network.

The terminal device 10 is a device operated by each user. Here, the user is a person who uses the terminal device 10 to receive the presentation of the activity status of the engineer team by the team activity evaluation system 1, but is not limited to the members of the engineer team, and the (team (not affiliated with a company), including managers, human resources representatives, executives, etc. The terminal device 10 is implemented by a stationary PC (Personal Computer), a laptop PC, or the like. In addition, the terminal device 10 may be, for example, a mobile terminal such as a tablet compatible with a mobile communication system or a smart phone.

Terminal device 10 is communicatively connected to server 20 and repository server 30 via network 80 . The terminal device 10 is a wireless base station 81 compatible with communication standards such as 4G, 5G, and LTE (Long Term Evolution), and a wireless LAN (Local Area Network) standard such as IEEE (Institute of Electrical and Electronics Engineers) 802.11. It is connected to the network 80 by communicating with a compatible communication device such as a wireless LAN router 82 . As shown as terminal device 10B in FIG.

The communication IF 12 is an interface for inputting and outputting signals so that the terminal device 10 communicates with an external device. The input device 13 is an input device (for example, a keyboard, a touch panel, a touch pad, a pointing device such as a mouse, etc.) for receiving an input operation from a user. The output device 14 is an output device (display, speaker, etc.) for presenting information to the user. The memory 15 temporarily stores programs and data processed by the programs, and is a volatile memory such as a DRAM (Dynamic Random Access Memory). The storage unit 16 is a storage device for storing data, and is, for example, a flash memory or a HDD (Hard Disc Drive). The processor 19 is hardware for executing an instruction set described in a program, and is composed of arithmetic units, registers, peripheral circuits, and the like.

The server 20 is a device that manages various parameters in GitHub, performance of members belonging to the engineer team, and team score information indicating the activity status of the engineer team. The server 20 receives information identifying the engineer team from the user, specifies a team score indicating the activity status of the target engineer team, and presents it to the user.

Server 20 is a computer connected to network 80 . The server 20 includes a communication IF 22 , an input/output IF 23 , a memory 25 , a storage 26 and a processor 29 .

The communication IF 22 is an interface for inputting and outputting signals for the server 20 to communicate with an external device. The input/output IF 23 functions as an interface with an input device for receiving input operations from the user and an output device for presenting information to the user. The memory 25 temporarily stores programs and data processed by the programs, and is a volatile memory such as a DRAM (Dynamic Random Access Memory). The storage 26 is a storage device for storing data, such as a flash memory or HDD (Hard Disc Drive). The processor 29 is hardware for executing an instruction set described in a program, and is composed of arithmetic units, registers, peripheral circuits, and the like.

The repository server 30 is a device that manages a remote repository (management means) in GitHub. The repository server 30 accepts the source code pushed by the user, stores and manages it, and accepts pull requests, comments, commits, merges, and the like.

<1.1 Configuration of terminal device 10>
FIG. 2 is a block diagram showing a functional configuration of the terminal device 10 that constitutes the team activity evaluation system 1 of the first embodiment. As shown in FIG. 2, the terminal device 10 includes a plurality of antennas (antenna 111, antenna 112), wireless communication units (first wireless communication unit 121, second wireless communication unit 122) corresponding to each antenna, and an operation unit. It includes reception unit 130 (including keyboard 131 and display 132 ), audio processing unit 140 , microphone 141 , speaker 142 , camera 150 , storage unit 160 , and control unit 170 . The terminal device 10 also has functions and configurations not particularly shown in FIG. 2 (for example, a battery for retaining power, a power supply circuit for controlling power supply from the battery to each circuit, etc.). As shown in FIG. 2, each block included in the terminal device 10 is electrically connected by a bus or the like.

The antenna 111 radiates a signal emitted by the terminal device 10 as radio waves. Antenna 111 also receives radio waves from space and provides a received signal to first wireless communication section 121 .

The antenna 112 radiates a signal emitted by the terminal device 10 as radio waves. Antenna 112 also receives radio waves from space and provides a received signal to second wireless communication section 122 .

The first wireless communication unit 121 performs modulation/demodulation processing and the like for transmitting and receiving signals via the antenna 111 in order for the terminal device 10 to communicate with other wireless devices. The second wireless communication unit 122 performs modulation/demodulation processing and the like for transmitting and receiving signals via the antenna 112 so that the terminal device 10 communicates with other wireless devices. The first radio communication unit 121 and the second radio communication unit 122 are communication modules including a tuner, an RSSI (Received Signal Strength Indicator) calculation circuit, a CRC (Cyclic Redundancy Check) calculation circuit, a high frequency circuit, and the like. The first radio communication unit 121 and the second radio communication unit 122 perform modulation/demodulation and frequency conversion of radio signals transmitted/received by the terminal device 10 and give received signals to the control unit 170 .

The operation accepting unit 130 has a mechanism for accepting user input operations. Specifically, operation accepting unit 130 includes a keyboard 131 and a display 132 . Note that the operation reception unit 130 may be configured as a touch screen that detects the user's touch position on the touch panel, for example, by using a capacitive touch panel.

The keyboard 131 accepts input operations by the user of the terminal device 10 . The keyboard 131 is a device for inputting characters, and outputs input character information to the control unit 170 as an input signal.

The display 132 displays data such as images, moving images, and text under the control of the control unit 170 . The display 132 is implemented by, for example, an LCD (Liquid Crystal Display) or an organic EL (Electro-Luminescence) display.

The audio processing unit 140 modulates and demodulates an audio signal. Audio processing section 140 modulates the signal supplied from microphone 141 and supplies the modulated signal to control section 170 . Also, the audio processing unit 140 provides an audio signal to the speaker 142 . The audio processing unit 140 is implemented by, for example, a processor for audio processing. Microphone 141 receives a voice input and provides voice signal corresponding to the voice input to voice processing section 140 . The speaker 142 converts the audio signal provided from the audio processing unit 140 into audio and outputs the audio to the outside of the terminal device 10 .

The camera 150 is a device for receiving light with a light receiving element and outputting it as a photographed image. The camera 150 is, for example, a depth camera that can detect the distance from the camera 150 to the subject.

The storage unit 160 is configured by, for example, a flash memory or the like, and stores data and programs used by the terminal device 10 . In one aspect, storage unit 160 stores user information 161 and local repository 162 .

The user information 161 is information of a user who uses the terminal device 10 to receive presentation of a team score indicating the activity status of the engineer team, which is a function of the team activity evaluation system 1 . The user information includes information for identifying the user (user ID), the name of the user, organizational information such as the company to which the user belongs, ID information and password for signing in to GitHub, and the like.

The local repository 162 stores information such as source code for users to work in their own local environments when developing software using GitHub. The user stores the created source code in the local repository 162 and modifies the source code stored in the local repository 162 . After completion of creation and modification, the user pushes the source code to repository server 30 .

The control unit 170 reads a program stored in the storage unit 160 and executes instructions included in the program to control the operation of the terminal device 10 . The control unit 170 is, for example, an application installed in the terminal device 10 in advance. The control unit 170 functions as an input operation reception unit 171, a transmission/reception unit 172, a data processing unit 173, and a notification control unit 174 by operating according to a program.

The input operation reception unit 171 performs processing for receiving a user's input operation to the input device such as the keyboard 131 .

The transmission/reception unit 172 performs processing for the terminal device 10 to transmit/receive data to/from an external device such as the server 20 according to a communication protocol.

The data processing unit 173 performs processing according to a program to perform computation on data input by the terminal device 10, and outputs the computation result to a memory or the like.

The notification control unit 174 performs processing for presenting information to the user. The notification control unit 174 performs processing for displaying a display image on the display 132, processing for outputting sound to the speaker 142, processing for causing the camera 150 to vibrate, and the like.

<1.2 Functional Configuration of Server 20>
FIG. 3 is a diagram showing a functional configuration of the server 20 that constitutes the team activity evaluation system 1 of Embodiment 1. As shown in FIG. As shown in FIG. 3 , the server 20 functions as a communication section 201 , a storage section 202 and a control section 203 .

The communication unit 201 performs processing for the server 20 to communicate with an external device.

Storage unit 202 stores data and programs used by server 20 . The storage unit 202 stores a repository database 2021, an individual performance database 2022, a team score database 2023, and the like.

The repository database 2021 is a database for holding various information related to various parameters such as the number of source codes created in the remote repository and the number of pushes acquired from the repository server 30 in the team activity evaluation system 1 . Details will be described later.

The individual performance database 2022 is a database for holding information indicating the performance of members of the engineer team in the team activity evaluation system 1. FIG. Details will be described later.

The team score database 2023 is a database for holding the team score indicating the activity status of the engineer team, which is presented in the team activity evaluation system 1, and various parameter information on which the score is based. Details will be described later.

The control unit 203 has various modules such as a reception control module 2031, a transmission control module 2032, a repository management module 2033, a performance calculation module 2034, a scoring module 2035, and an alert decision module 2036 by the processor of the server 20 performing processing according to a program. , and presentation module 2037 .

The reception control module 2031 controls processing for the server 20 to receive a signal from an external device according to a communication protocol.

The transmission control module 2032 controls the processing by which the server 20 transmits signals to external devices according to a communication protocol.

The repository management module 2033 controls processing for acquiring information recorded on the network for each user. Since the user of the team activity evaluation system 1 develops the source code on GitHub, the number of source codes created on GitHub (source code hosting), the number of modified codes Various parameters such as the number of requests, the number of source code pushes, and the number of pull requests are recorded in the repository server 30 . Various parameters such as the number of created issues, the number of reviews, the number of comments, the number of comment responses, and the number of commits are recorded in the repository server 30 as various parameters. Therefore, the repository management module 2033 accesses the repository server 30 and acquires various parameters of the user.

In the repository server 30, in order to manage the version of the source code, when a certain user pushes the source code from the local repository, the user's information and the date and time at that time are recorded as log information. Similarly, when an issue is created regarding the source code, etc., when there is a pull request regarding the source code, when a comment is created, when a reply to a comment is created, when there is a merge, etc. For each action , information on the user who performed the action, and the date and time of the action are recorded as log information. This information is recorded for each engineer team to which each user belongs, each project, and each source code file created within the project. The repository management module 2033 acquires these log information from the repository server 30 .

The performance calculation module 2034 controls processing for calculating a value (individual score) indicating the performance (result) of members belonging to the engineer team. For example, by counting the number of source codes created, the number of modified codes, the number of source code pushes, and the number of pull requests created in the GitHub of the member in a certain period of time, the user as an engineer in a certain period of time source code Since the amount (number of codes, number of lines, etc.) to be created is known, it is possible to estimate the performance of the member as an engineer (programmer) for a certain period of time. In addition, by counting the number of issues created, reviews, comments, comment responses, and commits created by the member on GitHub during a certain period of time, the amount of reviews that the user makes as an engineer in a certain period of time can be understood. Therefore, it is possible to estimate the results of the member concerned as a reviewer, manager, or the like for a certain period of time. Therefore, the performance calculation module 2034 calculates the number of source codes created on GitHub, the number of modified codes, the number of source code pushes, the number of pull requests, the number of issues created, the number of reviews, the number of comments, the number of comment responses, the number of commits, etc. Various calculations are performed based on various parameters of . For example, as examples of various calculations, the number of source codes created by each member, the number of modified codes, the number of source code pushes, the number of pull requests, the number of issues created, the number of reviews, the number of comments, the number of comment responses, the number of commits, etc. is added for each member belonging to the engineering team.

The performance calculation module 2034 may simply accumulate and add various parameters as calculations based on various parameters, and calculations that weight each parameter (for example, multiply each parameter by a predetermined coefficient and add). You may Further, each parameter may be weighted based on the degree of difficulty or importance of the product (source code), and the above calculation may be performed.

The scoring module 2035 controls the process of identifying parameters indicating the activity status of the engineering team based on various parameters acquired by the repository management module 2033 . Here, the parameter (also called team score) is a value indicating the activity status of the engineering team (for example, the results of the engineering team). It is a value specified by performing various calculations based on the history of the information uploaded online and the review information of the uploaded product by members of the engineering team. As will be described later, team scores are presented in association with chronological information, so the scoring module 2035 identifies team scores at regular intervals (eg, one week).

Specifically, as the information uploaded online by members to create deliverables as engineers, the number of source codes created on GitHub for the entire team, the number of modified codes, the number of source code pushes, Count the number of pull requests for a certain period of time. As a result, the amount of source code created by the engineering team in a certain period (number of codes, number of code, etc.) can be known, so the activity status of the team to create deliverables, that is, the activity status of the engineer team It is possible to estimate from various aspects. In addition, the number of issues created, the number of reviews, the number of comments, the number of comment responses, and the number of commits created on GitHub by the entire team are counted for a certain period of time as information on reviews performed by members of the engineering team on the uploaded deliverables. That is, the activity status of the team is acquired by acquiring and accumulating information on the deliverables of each member. As a result, the number of reviews (the number of comments) by the engineering team in a certain period of time can be known, so it is possible to estimate the review status of the deliverables of the team, that is, the activity status of the engineering team from the qualitative aspect of the deliverables. It is possible.

The scoring module 2035 weights the number of source codes created on GitHub, the number of modified codes, the number of source code pushes, and the number of pull requests based on the degree of difficulty or importance of the deliverable (source code). to determine team scores. The degree of difficulty and importance of the source code may be calculated from, for example, the amount of modification of the source code, the number of files affected by the modification of the source code, etc. It may be estimated from the number of man-hours set in . In such cases, the greater the amount of source code modification, the higher the difficulty and importance of the source code, and the greater the number of files affected by the modification of the source code, the higher the difficulty and importance of the source code. It is desirable to set the difficulty and importance of the source code higher as the number of man-hours set for the issue related to the pull request related to the modification of the source code increases. This is because the time required for creation, that is, the performance required to produce results, may vary depending on the difficulty and importance of the source code. Scoring module 2035 may also determine the team score based on the history of the number of chords remaining after a predetermined period of time after creation. This is because the source code remaining after a certain period of time is considered to be highly useful.

The alert determination module 2036 controls the process of determining alerts about the engineering team's activity status to be notified to the user based on the team score changes identified by the scoring module 2035 . The alert to be notified to the user presents matters to be noted regarding the activity status of the engineering team based on the fluctuation of the team score. and an outlier that is outside a certain range, the alert determination module 2036 determines an alert based on the outlier. As a specific example, the alert determination module 2036 compares the team score for the week with other weeks in a range that is determined to be an outlier (eg, a decrease of 20% or more). Since it is presumed that the activity status of the engineering team is stagnant, it is decided to detect outliers and notify them as alerts based on the detected outliers.

In addition, the alert determination module 2036 detects changes in various parameters indicating the performance of members belonging to the engineering team, specifically the number of created codes, the number of modified codes, the number of pushes, and the number of pull requests on GitHub, Based on the variability, a decision may be made to alert the user. This is because fluctuations in the performance of members often affect the activity status of the engineering team. In addition, the alert determination module 2036 detects changes in the number of reviews, review time, and number of comments between a member and another member belonging to the engineering team in GitHub, and notifies the user of an alert based on the change. may decide to do so. This is because the status of reviews between specific members may affect the activity status of the engineering team. Additionally, the alert determination module 2036 may determine to notify the user with an alert based on the individual score variation computed by the performance computation module 2034 . This is because fluctuations in overall evaluation based on individual scores may affect the activity status of the engineering team.

The presentation module 2037 controls the process of presenting to the user the team score identified by the scoring module 2035 and indicating the activity status of the engineer team. For example, the presentation module 2037 transmits to the user's terminal device 10 via the communication unit 201, in order to present to the user, as time-series information, changes in team scores on a weekly basis. The presentation module 2037 may present the team score fluctuation status for each breakdown such as the number of created codes on GitHub and the number of pushes.

The presentation module 2037 may acquire, as the activity status of the engineer team, the lead time indicating the period from the request of the review in the engineer team to the completion of the review, and present it to the user. This is to grasp the time until subsequent processing (review, etc.) is performed on the deliverable, and the time thereafter. Here, when a review is requested for a product, a person other than the engineer who created the product reviews the product and writes comments and the like. In the normal process, the comments are used to modify the deliverables (sometimes no corrections are required and sometimes not reviewed) and a decision is made to incorporate the deliverables. Once done, the merge is done and the work on that deliverable is closed. However, there may be cases where a decision is made not to reflect the product for some reason, such as specification changes, and in that case the product is closed without being merged. In addition, on GitHub, etc., when a pull request is decided regardless of whether or not it is merged, it is called "closed", but in this specification, no merge is performed, that is, no response to the pull request is called. In addition, a decision to terminate the development work such as modification of the deliverable is called “rejection”. The above-mentioned lead time is a concept that includes the period from the request for review to closing after merging and the period from requesting review to closing without merging. In other words, "closed" refers to a state in which some kind of decision has been made and development work such as modification of a product has been completed, and includes merge and rejection. Note that deliverables for which decisions have not been made as described above are left unattended. If not, it is a concept that includes a state in which work has been completed but no decision has been made to merge or close, and a state in which a certain period of time has passed in these states.

In addition, the presentation module 2037 may acquire, as the activity status of the engineer team, a breakdown showing the transition of the deliverables for which review has been requested in the engineer team, and present it to the user. As described above, when a review request is made, the pull request state, the review state, the response to the review (comments in response to comments or corrections to artifacts), and the merge is performed, and the transition of the deliverable is the transition of the status of the deliverable after such a review request (each of the states described above). In addition, the breakdown showing the transition of deliverables is the breakdown of pull requests that have transitioned to each status in the entire target pull request. 7 items are in the state of being unreviewed, 4 of the 7 items are in the state of responding to reviews, and 2 of the 4 items are in the state of being merged. It becomes the information of the breakdown showing the transition of This is to grasp whether subsequent processing (review, etc.) is appropriately performed on the deliverables. In addition, the presentation module 2037 may acquire, as the activity status of the engineer team, the relationship between the number of comments on the deliverable for which review has been requested in the engineer team and the time until the deliverable is closed, and present it to the user. . This is to understand how the relationship between the number of comments and the time to close the deliverable is distributed, and which case is an outlier. Furthermore, the presentation module 2037 may acquire, as the activity status of the engineer team, the relationship between reviewees who request reviews in the engineer team and reviewers who receive the review requests, and present them to the user. This is to understand the relationship between reviewers and reviewers and the load status of reviews.

The presentation module 2037 also controls the process of presenting to the user the alert regarding the activity status of the engineer team determined by the alert determination module 2036 . The presentation module 2037 , for example, transmits an alert based on the weekly team score fluctuations to the terminal device 10 of the user via the communication unit 201 together with the team score fluctuations.

Furthermore, the presentation module 2037 may present the individual score, which is calculated by the performance calculation module 2034 and indicates the performance of the members belonging to the engineer team, to the user in association with time-series information. At this time, it may be presented in association with a team score indicating the activity status of the engineering team. This is for understanding the activity status of the engineering team in association with the performance of the members. In addition, the presentation module 2037 associates the team score indicating the activity status of the engineer team with the time-series information, associates the team score indicating the activity status of the other engineer team with the time-series information, and enables comparison (for example, , displayed side by side) and presented to the user. This is to grasp the activity status of the engineering team by comparing it with other teams. At this time, both pieces of time-series information do not necessarily have to be at the same time. This is because the activity periods of the two may be different, and it is easier to grasp the situation of the team by comparing the period from the start of the project related to the team. Furthermore, the presentation module 2037 indicates the period from the review request to the merging and closing in the engineering team (here, the period from the review request to the dismissal without merging and closing). may be presented to the user so that the lead times of other engineering teams can be compared (for example, displayed in parallel). This is to understand the delivery status of deliverables in the engineering team by comparing it with other teams. At this time, both lead times do not need to be at the same timing, and may be compared at different times and periods. This is because the timing and duration of each project are usually different.

<2 Data structure>
FIG. 4 is a diagram showing the data structure of the repository database 2021 stored by the server 20. As shown in FIG. 5 is a diagram showing the data structures of the individual performance database 2022 stored by the server 20 and the team score database 2023 stored by the server 20. As shown in FIG.

As shown in FIG. 4, each record of the repository database 2021 includes an item "organization ID", an item "repository ID", an item "address", an item "update history information", and the like.

The item “organization ID” is information for identifying each organization such as a company to which an engineer team such as a development project belongs, which is the object of various parameters acquired from the repository server 30 in the team activity evaluation system 1 .

The item “repository ID” is information for identifying each repository set for each engineer team such as a development project, which is the object of various parameters acquired from the repository server 30 in the team activity evaluation system 1 .

The item "address" is information indicating the address (URL) of the repository server 30 from which various parameters are obtained in the team activity evaluation system 1, and stores the address of the remote repository created for each project. With this address, it is possible to identify a common file name (README.txt, etc.) for each project.

The item "update history information" is information about the update history of the source code stored in the repository server 30 from which various parameters are acquired by the team activity evaluation system 1. Specifically, the item "action" and It includes the item "worker", the item "title", the item "source code", the item "creation date information", the item "update date information", and the like. This item "update history information" is action management information such as source code version management and comments in GitHub.

The item “action” is information on the type of action for the source code stored in the repository server 30 .

The item “worker” is information identifying each user who has performed an action on the source code stored in the repository server 30 .

The item "title" is information indicating the name of the project, repair, correction, etc. that is the basis of the action.

The item "source code" is information indicating the file name of the source code that performed the action.

The item “creation date/time information” is information on the date/time when an action was performed on the source code stored in the repository server 30 .

The item “update date/time information” is information on the date/time when further action was performed on the source code stored in the repository server 30 .

The repository management module 2033 of the server 20 updates the repository database 2021 as log information is acquired from the repository server 30 .

As shown in FIG. 5, each record in the individual performance database 2022 includes an item "member ID", an item "performance details", and the like.

The item "member ID" is information identifying each member belonging to the engineer team who receives the activity status of the engineer team in the team activity evaluation system 1, and the item "worker" of the repository database 2021. corresponds to

The item "performance details" is information related to actions obtained from various parameters of log information in GitHub of members belonging to the engineering team who receive presentation of the activity status of the engineering team in the team activity evaluation system 1. Specifically, it includes an item "repository ID", an item "action", an item "opponent member ID", an item "value", and the like.

The item “repository ID” is information for identifying each repository set for each engineer team, and corresponds to the item “repository ID” of the repository database 2021 .

The item "action" is information on the type of action performed by a member belonging to the engineer team on the source code stored in the repository server 30, and corresponds to the item "action" of the repository database 2021. .

The item "partner member ID" indicates the partner member when the member belonging to the engineer team has an action, such as review or comment, on the source code stored in the repository server 30. This is identifying information and corresponds to the item “worker” in the repository database 2021 .

The item “date information” is information on the date when the action was performed on the source code stored in the repository server 30 .

The performance calculation module 2034 of the server 20 updates the individual performance database 2022 in accordance with calculation of individual scores indicating the performance of members belonging to the engineer team.

Each of the records in the team score database 2023 includes the item “organization ID”, the item “repository ID”, the item “team member”, the item “team detailed information”, and the like.

The item "organization ID" is information identifying each organization such as a company to which the engineer team, which is a higher item of the engineer team, belongs to and receives the activity status of the engineer team in the team activity evaluation system 1, and is a repository. It corresponds to the item “Organization ID” of the database 2021 .

The item "repository ID" is information for identifying each engineer team such as a development project, which is the object of various parameters acquired from the repository server 30 in the team activity evaluation system 1, and the item "repository ID" of the repository database 2021. corresponds to

The item "team member" is information identifying each member belonging to the engineer team who receives the activity status of the engineer team in the team activity evaluation system 1, and the item "member It corresponds to ID.

The item "team detailed information" is information about the engineer team whose activity status is presented in the team activity evaluation system 1. Specifically, the item "date" and the item "number of pull requests". , the item “number of merges”, the item “number of commits”, the item “number of reviews”, and the like. The item "number of pull requests", the item "number of merges", the item "number of commits", and the item "number of reviews" are examples of various parameters in GitHub, and other parameters may be stored.

The item "date" is information indicating the date on which the activity status of the engineer team was acquired and totaled for each day.

The item "number of pull requests" is information on the number of pull requests in the engineering team, obtained from GitHub on the date.

The item "number of merges" is information on the number of merges in the engineering team, obtained from GitHub on the date.

The item "number of commits" is information on the number of commits in the engineering team, acquired from GitHub on the date.

The item "number of reviews" is information on the number of reviews in the engineering team, which is obtained from GitHub on the date.

Note that the values obtained from GitHub may be stored for the "number of pull requests", the "number of merges", the "number of commits", and the "number of reviews", or the values that have undergone predetermined weighting may be stored. good too.

Although not shown, the team score database 2023 may store alert information determined by the alert determination module 2036 .

In addition, when the performance calculation module 2034 and the scoring module 2035 aggregate the activity status of the engineer team acquired from the repository database 2021 and present it as it is in the presentation module 2037, the individual performance database 2022 and the team score database 2023 You don't have to. The individual performance database 2022 and the team score database 2023 store pre-aggregated values so that even if the dates and periods for presenting the activity status of the engineering team are changed, they can be presented immediately, as will be described later.

The scoring module 2035 of the server 20 updates the scoring module 2035 as the team score indicating the activity status of the engineer team is specified.

<3 Operation>
Scoring processing and team activity status presentation processing by the team activity evaluation system 1 according to the first embodiment will be described below with reference to FIGS. 6 and 7. FIG.

FIG. 6 is a flow chart showing an example of the flow of scoring processing by the team activity evaluation system 1 of the first embodiment.

In step S111, the user operates the terminal device 10 to perform an action such as push or comment from the local repository of GitHub to the remote repository of the repository server 30. Therefore, the input operation reception unit 171 of the terminal device 10 Accepts an action instruction from the user. The transmitting/receiving unit 172 transmits the received action information to the server 20 . The server 20 receives action information via the communication unit 201 .

In step S112, the repository management module 2033 of the server 20 acquires various parameters such as the number of source code pushes and the number of pull requests recorded in the repository server 30 for each member of the team. Access and send a request signal. The repository management module 2033 acquires various parameters from the repository server 30 via the communication unit 201 .

In step S113, the performance calculation module 2034 of the server 20 calculates a value (individual score) indicating the performance of the members belonging to the engineering team based on various parameters of GitHub acquired in step S112.

In step S114, the scoring module 2035 of the server 20 identifies a team score indicating the activity status of the engineer team based on various parameters of GitHub acquired in step S112.

In step S115, the alert determination module 2036 of the server 20 determines an alert regarding the activity status of the engineer team to be notified to the user based on the change in the team score identified in step S114.

In step S116, the repository management module 2033 of the server 20 stores various parameters acquired in step S112 in the repository database 2021. FIG. The performance calculation module 2034 stores the personal score calculated in step S113 in the personal performance database 2022. The scoring module 2035 stores the team scores identified in step S114 in the team score database 2023. The alert determination module 2036 stores the alert information determined in step S115 in the team score database 2023. FIG.

As described above, the team activity evaluation system 1 calculates the individual score of each member and identifies the team score based on various parameters that are the log information of deliverables in GitHub. This makes it possible to grasp the activity status of the team.

FIG. 7 is a flow chart showing an example of the process of presenting the team activity status by the team activity evaluation system 1 according to the first embodiment.

As a premise for performing the process of step S211, user registration is performed to sign in to the team activity evaluation system 1 (not shown in FIG. 7). The input operation reception unit 171 of the terminal device 10 receives information input from the user such as an ID (which may be a temporary one), an e-mail address, and a password for signing in to the team activity evaluation system 1 . The transmitting/receiving unit 172 transmits the accepted user ID and password and the information of the engineering team of the user to the server 20 . The server 20 accepts the transmitted ID, e-mail address and password via the communication unit 201 and registers the user information. The input operation reception unit 171 of the terminal device 10 receives a selection of GitHub or other services as a service to be linked, selects an organization (company etc.) registered with the service, and selects an engineer team and members associated with the organization. (Member), accepts the selection of the repository and transmits it to the server 20 . The server 20 receives the transmitted various selection information via the communication unit 201 and registers the selection information.

In step S<b>211 , the input operation receiving unit 171 of the terminal device 10 receives input of information such as an organization ID, an email address, and a password for signing in to the team activity evaluation system 1 from the user. The transmitting/receiving unit 172 transmits the received organization ID, email address, and password information to the server 20 .

In step S221, the server 20 accepts the organization ID, email address and password via the communication unit 201, performs predetermined authentication, and accepts the user's sign-in.

In step S222, the presentation module 2037 of the server 20 reads and acquires the team score specified in step S114 from the team score database 2023 for the engineer team selected by the user. Note that when acquiring the team score, the latest team score of the engineer team may be specified and acquired.

In step S223, the presentation module 2037 of the server 20 reads and acquires from the team score database 2023 the alert regarding the activity status of the engineer team determined in step S115. Note that when acquiring an alert, the alert may be determined and acquired from the latest team score of the engineer team.

In step S224, the presentation module 2037 of the server 20 transmits the team score specified in step S222 and the alert determined in step S223 to the terminal device 10 via the communication unit 201 in order to present them to the user.

In step S<b>214 , the transmission/reception unit 172 of the terminal device 10 receives the team score of the engineer team to which the user belongs and the alert transmitted from the server 20 . Notification control unit 174 causes display 132 to display the received team score and alert.

As described above, the team activity evaluation system 1 identifies the chronological team score of the engineer team based on various parameters that are the log information of the deliverables on GitHub. This makes it possible to grasp the activity status of the team.

<4 Screen example>
Screen examples of the team activity status presentation process by the team activity evaluation system 1 will be described below with reference to FIGS. 8 to 19 .

FIG. 8 is a diagram showing an example of a sign-in screen displayed on the terminal device 10. As shown in FIG. The example screen of FIG. 8 shows an example of the screen when the user who receives the presentation of the activity status of the engineer team signs in to the team activity evaluation system 1 . This corresponds to step S211 in FIG.

As shown in FIG. 8, the display 132 of the terminal device 10 has an organization ID entry field 1031a of a company or the like to which the engineer team belongs and a registered A user's email address input field 1031b, a password input field 1031c for the user, and a login transition button 1031d for logging in are arranged.

The user enters the organization ID, email address, and password in the organization ID entry field 1031a, the email address entry field 1031b, and the user's password entry field 1031c, respectively, and presses the screen transition button 1031d. to log in. After that, the screen transitions to a screen displaying the activity status of the engineering team.

FIG. 9 is a diagram showing a display screen example of the team activity status displayed on the terminal device 10. As shown in FIG. The screen example of FIG. 9 shows a screen example of a state in which team scores for a certain period of time and chronological changes in team scores are displayed. This corresponds to step S214 in FIG.

As shown in FIG. 9, the display 132 of the terminal device 10 has a period display field 1032a for displaying a period during which the activity status of the engineer team is specified in response to an instruction operation for displaying the activity status of the engineer team, A score display field 1032b for displaying the details of the team score indicating the activity status (performance) of the engineer team, and a time-series change display field for displaying the time-series change of the overall team score, which is the activity status of the engineer team, and the breakdown thereof. 1032c, and a period change input field 1032d for receiving a change in the period specifying the activity status of the engineer team.

The period displayed in the period display field 1032a is the period indicated by the start date and end date of the period in which each score displayed in the score display field 1032b is acquired, and for example, the start date and end date of one week are displayed. It is The scores displayed in the score display field 1032b are various parameters acquired from GitHub. For example, the number of issues created, the number of pull requests, the number of merges, the number of commits, and the number of reviews during the period displayed in the period display field 1032a. is displayed. As an example, in FIG. 9, various parameters in the period described in the period display column 1032a are compared with various parameters in the previous period, and the number of changes is displayed. In addition, the total number of various parameters in a specific period may be displayed, or how much the cumulative value has increased from the previous point in time from a certain point in time may be displayed. The time-series change displayed in the time-series change display field 1032c is a stacked bar graph of weekly changes in various parameters. ), and the vertical axis indicates the score value. In the stacked bar graph of the chronological change display column 1032c, the number of issues created 1032c1, the number of pull requests 1032c2, the number of merges 1032c3, the number of commits 1032c4, and the number of reviews 1032c5 are displayed as elements similar to the parameters displayed in the score display column 1032b. Weekly changes are stacked and displayed, along with changes in the total value. In the example of FIG. 9, changes for 6 months are displayed.

Also, the period displayed in the period display field 1032a can be changed by inputting in the period change input field 1032d. For example, the period change input field 1032d is configured to enable pull-down selection for each predetermined period. By selecting a period, the period is displayed in the period display field 1032a, and various parameters of the period are displayed in the score display field 1032b. to be displayed. In addition, the chronological change display field 1032c may display chronological changes going back from the period changed by the input in the period change input field 1032d. The values indicated by the number of commits 1032c4 and the number of reviews 1032c5 may be changed and displayed. Furthermore, the period displayed in the period display field 1032a and the period selectable by the period change input field 1032d may be configured to be changeable. It may be changeable every day, every 10 days, every month. The display of the chronological change display column 1032c enables the user to grasp the change in the activity status of the engineer team.

FIG. 10 is a diagram showing an example of a pull request status display screen displayed on the terminal device 10. As shown in FIG. The example screen of FIG. 10 shows an example of a screen displaying the pull request status of the source code in the engineering team. For example, the screen example of FIG.

As shown in FIG. 10, on the display 132 of the terminal device 10, active pull requests (in which some sort of response is being made) in the engineering team are extracted, and as an example of the situation, a pull request with a large number of comments is displayed. A list is displayed. Specifically, a title display column 1033a indicating the title of the pull request, a status display column 1033b indicating the correspondence state of the pull request, and a link display column 1033c displaying the link to the source code corresponding to the pull request. , a member display field 1033d showing the member who made the pull request, a comment number display field 1033e showing the number of comments on the pull request, and an update date display field 1033f showing the last update date on the pull request. is displayed.

On the screen shown in FIG. 10, for example, the title of the pull request shown in the title display field 1033a, the response status of the pull request shown in the status display field 1033b, and the like are displayed in descending order of the number of comments displayed in the comment number display field 1033e. is displayed. This display is done, for example, in order to grasp pull requests that are actively being reviewed. A pull request with a large number of comments may indicate a positive trend due to active discussion, but if the number of comments has increased significantly in a specific period of time (one day, for example) , there is a discrepancy in recognition between the reviewer and the reviewee, and so on. Therefore, such display is performed to grasp that the reviews were actively conducted. For example, when the amount of increase in the number of comments is at an abnormal pace, the display mode of the comment number display field 1033e may be changed (for example, the color may be changed to red). Note that, as shown in FIG. 10, the status display column 1033b may be displayed so as to change the display mode (for example, change the color) according to the response status of the pull request.

FIG. 11 is a diagram showing another display screen example of the team status displayed on the terminal device 10. As shown in FIG. The example screen in FIG. 11 shows an example screen in which the team scores of the engineer team and other engineer teams for a certain period of time are displayed. For example, the screen example in FIG. displayed by

As shown in FIG. 11, on the display 132 of the terminal device 10, a team name display column 1034a indicating the engineer team and other engineer teams in a predetermined period, and a total team score indicating the activity status of each engineer team. A graph display field 1034b that expresses the value and its breakdown as a horizontal bar graph, a score display field 1034c that displays the breakdown of the team score indicating the activity status of each engineer team, and a period change input field 1034d that accepts changes to the period. is displayed.

The scores displayed in the score display field 1034c are various parameters acquired from GitHub, and examples thereof include the number of created issues, the number of pull requests, the number of merges, the number of commits, and the number of reviews. The graph display field 1034b displays a horizontal bar graph in which the scores displayed in the score display field 1034c are piled up to the right. In addition, similarly to the period change input field 1032d shown in FIG. 9, the period change input field 1034d is configured such that it is possible to change the aggregation period of the displayed graph display field 1034b and score display field 1034c by input. ing. The activity status of each team can be grasped at a glance by the display of the graph display column 1034b, and it is possible to grasp that the activity status of the team is active from the length of the bar of the horizontal bar graph.

FIG. 12A shows a display screen example of the lead time and pull request status displayed on the terminal device 10, and FIG. 12B shows another display example of the diagram display field 1035d shown in FIG. 12A. ). The screen example in FIG. 12 shows the lead time indicating the period from the pull request (request for review) to the closing of the source code, which is the deliverable of the engineering team, the transition of the source code for which the pull request was made, and the lead time. It shows an example of a screen in which a time transition is displayed, and is displayed by, for example, scrolling from the example of the screen in FIG. 9 or by making another screen transition.

As shown in FIG. 12A, the display 132 of the terminal device 10 includes a lead time display column 1035a indicating the average lead time of the engineer team as the activity status (team score) of the engineer team, and a pull request A comment time display column 1035b indicating the average time until the first comment is made on the source code that has been reviewed, a close time display column 1035c that indicates the average time from review to closing, and the transition of the source code with the pull request , a moving average display field 1035e for displaying the moving average times of the lead time, the time to the first comment, and the time from review to closing, and a period change input field for accepting changes in the period. 1035f is displayed. The average time displayed in the lead time display column 1035a, the comment time display column 1035b, and the closing time display column 1035c is the average value of each value in the engineer team for a predetermined period (for example, three weeks).

The transition information displayed in the diagram display field 1035d indicates how the pull-requested source code has transitioned from being pulled-requested to being closed or left unattended. More specifically, from a pull request (status), then reviewed, reviewed, responded to, merged and closed, rejected and closed, and not closed A method called Sankey diagram is used to express which status has changed among the states left as they are. For example, the rectangle 1035d1 on the left indicates the number of pull-requested source codes in the vertical direction. The number of source codes is indicated by the length in the vertical direction. That is, the difference between the number of cases indicated by the rectangle 1035d1 and the number of cases indicated by the rectangle 1035d2 indicates the number of source codes that have not been reviewed. Contains source code that has been closed without Also, the curves connecting the rectangles indicate the status transitions as described above. The same applies to subsequent statuses. Furthermore, by placing the mouse pointer over each rectangle or curve, the attributes and the number of cases indicated by each rectangle or curve may be displayed (rollover). Based on the information on the transition of the pull request (review request) source code (deliverable product) displayed in the diagram display field 1035d, the subsequent processing (review, etc.) of the deliverable is performed appropriately as the activity status of the engineering team. It is possible to grasp at a glance whether the

The moving average time displayed in the moving average display field 1035e is a bar graph and an approximated curve showing the moving average time for each time in a predetermined period (for example, 3 weeks) in the engineer team, and the vertical axis is The number of cases and the horizontal axis indicate the passage of time (time series). Various settings can be made for the interval for calculating the moving average, but for example, it is desirable to calculate the moving average every seven days in order to exclude fluctuations in engineering work for each day of the week. However, when confirming the transition from a longer-term perspective, it is desirable to set a moving average every three weeks. The average time displayed in the lead time display field 1035a, the comment time display field 1035b, and the closing time display field 1035c, the transition information displayed in the diagram display field 1035d, and the moving average displayed in the moving average display field 1035e The predetermined time period with corrected time may be configured so that the time and period can be changed. Similarly to the period change input field 1032d shown in FIG. 9, the period change input field 1035f includes a lead time display field 1035a, a comment time display field 1035b, a closing time display field 1035c, a diagram display field 1035d, and a shift display field. It is configured such that the aggregation period of the average display column 1035e can be changed by input. Based on the average time displayed in the lead time display column 1035a, the comment time display column 1035b, and the closing time display column 1035c, the activity status of the engineer team indicates the time until subsequent processing (review, etc.) is performed on the deliverable, It is possible to grasp the time at a glance, and it is possible to grasp the time-series transition from the moving average time displayed in the moving average display field 1035e.

Further, as shown in FIG. 12(b), the transition information displayed in the diagram display field 1035d may be displayed with only specific elements separated from each other so that the state can be easily grasped. In the example of FIG. 12(b), a right rectangle 1035d3 indicating the number of merged source codes in the period and a right rectangle 1035d4 indicating the number of rejected and closed source codes in the period. , and a rectangle 1035d5 on the right side indicating the number of source codes left unattended during the period. A plurality of elements may be separated, and may be configured to be selectable by clicking each rectangle with a mouse. With such a configuration, it is possible to grasp at a glance a deliverable in a specific state (abandoned, withdrawn, etc.) as the activity status of the engineering team.

FIG. 13 is a diagram showing an example of a pull request type status display screen displayed on the terminal device 10 . The example screen in FIG. 13 shows an example screen in which the relationship between the number of comments on a pull request (review request) and the time until merge/close is displayed as a scatter diagram in the engineering team. It is displayed by scrolling from the screen example of FIG. 9 or by making another screen transition.

As shown in FIG. 13, the display 132 of the terminal device 10 displays a scatter diagram 1036a as the activity status of the engineer team during a predetermined period. In the scatter diagram 1036a, the vertical axis indicates the number of comments for each pull request, and the horizontal axis indicates the lead time of each pull request (described as merge close time in the figure). is plotted. For example, the pull request indicated by point 1036b in FIG. 13 had 16 comments and a lead time of 1.6 hours. Also, a period change input field 1036e for accepting a change in the predetermined period is displayed. The scatter diagram 1036a may be configured to display (roll over) the number of comments and the merge/close time indicated by each point by placing the mouse pointer over the point 1036b. , as shown in FIG. 14, which will be described later, may be configured to transition to a screen showing the state of the pull request. Furthermore, the scatter plot 1036a may be configured so that a predetermined frame 1036c surrounded by scale lines can be selected to select points that are elements (to grasp outliers). Further, when selecting a predetermined frame 1036c, one frame 1036c may be selectable, and a plurality of frames 1036c may be selected (for example, by performing an operation of selecting by dragging or selecting while pressing a shift key). (by operation) may be configured to be selectable. Furthermore, a representative value (e.g., average value, median value, etc.) of the number of comments of a certain engineering team and the time to merge/close is set by a statistical method. may be configured to display by changing the display mode (for example, by changing the color, etc.) as shown in FIG. From the scatter diagram 1036a, it is possible to understand at a glance how the relationship between the number of comments and the time to merge/close is distributed, and which outliers are among them.

FIG. 14 is a diagram showing an example of a pull request status display screen displayed on the terminal device 10. As shown in FIG. The screen example of FIG. 14 shows a screen example of a state in which pull request statuses in the engineering team are displayed in a list format.

As shown in FIG. 14, the display 132 of the terminal device 10 includes a title display field 1037a of the source code that is the target of the pull request, a source code file name display field 1037b, and an action display field 1037c for the source code. , a date display column 1037d when the action was performed, and a member display column 1037e who performed the action are displayed. The action display column 1037c, the date display column 1037d, and the member display column 1037e are history information acquired from the personal performance database 2022, for example. With such a configuration, it is possible to grasp the status of each pull request (source code) at a glance.

FIG. 15 is a diagram showing an example of a display screen of the review implementation status displayed on the terminal device 10. As shown in FIG. The screen example of FIG. 15 shows a screen example in which a diagram showing the review execution rate in the engineering team, the response rate to the review, and the relationship between reviewers and reviewers is displayed. It is displayed by scrolling or making another screen transition.

As shown in FIG. 15, the display 132 of the terminal device 10 displays a review rate display column 1038a indicating the review rate of the engineer team and a response rate indicating the response rate to the review as the activity status of the engineer team in a predetermined period. A display field 1038b and a relationship diagram display field 1038c showing the relationship between the reviewer requesting the review and the reviewer receiving the review request are displayed. The relationship diagram display field 1038c is a diagram showing the relationship of who the reviewer requesting the review is to review and to whom the review is being performed. 1038d, a reviewer display column 1038e for displaying the reviewer who has received the review request, and a relationship display line 1038f for indicating the relationship between the reviewer display column 1038d and the reviewer display column 1038e. Also displayed is a period change input field 1038g for receiving a change in the predetermined period. The horizontal length of the frame of the reviewer display column 1038d and the reviewer display column 1038e indicates the number of reviews. Furthermore, by selecting a specific reviewer display field 1038d or reviewer display field 1038e, the relationship diagram display field 1038c is configured so that only the relationship display line 1038f related to the selected reviewer display field 1038d or reviewer display field 1038e is displayed. can be configured to

From the review rate display column 1038a and the response rate display column 1038b, it is possible to grasp the review implementation status of the engineer team at a glance. In addition, it is possible to grasp the relationship between reviewers and reviewers and the review load status at a glance from the relationship diagram display field 1038c.

FIG. 16 is a diagram showing an example of a display screen of alert information displayed on the terminal device 10. As shown in FIG. The example screen in FIG. 16 shows an example screen in which an alert determined based on the fluctuation of the team score for a certain period of time is displayed. For example, by scrolling from the example screen in FIG. Is displayed.

As shown in FIG. 16, the display 132 of the terminal device 10 includes an importance display column 1039a indicating the importance of alert information, an alert display column 1039b displaying an alert determined from the activity status of the engineer team, and an alert display column 1039b. A basis link display field 1039c for displaying a link to information that is the basis of the alert and a date display field 1039d for displaying the date on which the alert was determined are displayed.

In the importance display column 1039a, a picture or pattern indicating the importance of the content of the alert displayed in the alert display column 1039b is displayed in red, for example, when the importance is high. The alert display field 1039b displays an alert based on changes in the team score. impending) may be displayed. By displaying the alert display column 1039b as described above, the user can grasp matters to be noted regarding the activity status of the engineer team.

FIG. 17 is a diagram showing an example of a member's performance display screen displayed on the terminal device 10. As shown in FIG. The example screen in FIG. 17 shows an example screen in which a value indicating the performance of a specific member belonging to the engineering team corresponding to the fluctuation of the team score for a certain period of time is displayed. It is displayed by scrolling from the screen example or by making another screen transition.

As shown in FIG. 17, the display 132 of the terminal device 10 displays a period display column 1040a for displaying the period during which the member's performance was calculated, and a breakdown of the individual score indicating the activity status (performance) of the member. A score display field 1040b to be displayed and a time-series change display field 1040c showing changes in the total value of the member's personal score and its breakdown over time are displayed. Also displayed is a period change entry field 1040d for accepting a change in the period in which the member's performance is calculated.

The period displayed in the period display field 1040a is the period indicated by the start date and end date of the period in which the individual score displayed in the time series change display field 1040c was acquired, and for example, the start date and end date of 6 months. is displayed. The time-series change displayed in the time-series change display field 1040c is a stacked bar graph showing weekly changes in various parameters. ), and the vertical axis indicates the score value. The stacked bar graph in the chronological change display field 1040c displays weekly changes in the number of issues created, the number of pull requests, the number of merges, the number of commits, and the number of reviews, similar to the parameters displayed in the score display field 1040b. , the change in the total value is also displayed. It should be noted that it is also possible to display how much the cumulative value has changed since a certain point instead of the total value. Such display of the chronological change display field 1040c enables the user to grasp the change in the activity status of the relevant member, and to grasp the change in the activity status of the engineer team in association with the change. .

FIG. 18 is a diagram showing an example of a display screen of the member's pull request status displayed on the terminal device 10. As shown in FIG. The example screen of FIG. 18 shows an example of a screen displaying the pull request status of the source code by the member.

As shown in FIG. 18, the display 132 of the terminal device 10 shows the status of the pull request for the source code by the relevant member, for example, a state in which the pull request has been made for a certain period of time or longer, that is, a review has been made while the review request has been made. A list of source code that has not been done (is left unattended) is displayed. Specifically, a source code display column 1041a indicating the source code, a basis link display column 1041b displaying a link to information that is the basis of the state of the source code, and a pull request for the source code. A date display field 1041c for displaying the date is displayed. Also displayed is a period change entry field 1041d for receiving a change in the period in which the member's performance is calculated.

The source code display column 1041a displays the source code for which pull requests have been made for a certain period of time or more, and the reason link display column 1041b is displayed as means for confirming the state. For example, if a certain period of time has passed since a pull request was made for the source code, it will affect the lead time, which indicates the period from the start of the source code to the delivery of the source code in the engineering team. The screen display is used to check the status of Such a source code display field 1041a makes it possible to grasp the blank period for each product.

FIG. 19 is a diagram showing an example of a display screen for team comparison of the team activity status displayed on the terminal device 10. As shown in FIG. The screen example of FIG. 19 shows a screen example of a state in which a change in the team score of another engineer team corresponding to the change in the team score for a certain period of time is displayed so as to be comparable. It is displayed by scrolling from or by making a separate screen transition.

As shown in FIG. 19, the display 132 of the terminal device 10 has a period display column 1042a for displaying a period in which the activity status of the engineer team is specified, a total team score representing the activity status of the engineer team, and its score. A time-series change display field 1042b showing a time-series change in the breakdown, and a time-series change display field 1042c showing a time-series change in the total team score, which is the activity status of the other engineer teams to be compared, and its breakdown. is displayed. Also displayed is a period change input field 1042d for accepting a change in the period in which the activity status of the engineer team is specified.

The period displayed in the period display field 1042a is a period indicated by the start date and the end date of the period in which the team scores displayed in the time-series change display field 1042b and the time-series change display field 1042c are obtained. The start date and end date of the month are displayed. The time-series changes displayed in the time-series change display field 1042b and the time-series change display field 1042c are stacked bar graphs showing weekly changes in various parameters during the same period, and the horizontal axis represents time-series changes. (one element indicates one week as an example), and the vertical axis indicates the score value. Stacked bar graphs in the chronological change display column 1042b and the chronological change display column 1042c show the number of issues created, the number of pull requests, the number of merges, the number of commits, and the number of reviews corresponding to the chronological change display column 1032c shown in FIG. is displayed, and changes in the total value are also displayed. In addition, if the various parameters of the engineer team or the other engineer team to be compared exist only for a part of the period, it may be configured so that only a part of the period is displayed, and the chronological information of both is , not necessarily at the same time. By displaying the chronological change display column 1042b and the chronological change display column 1042c, the user can grasp the change in the activity status of the engineering team by comparing it with other teams. Items and graphs for comparison with other teams are not limited to those shown in FIG. It is possible to create and compare.

<Summary>
As described above, according to the present embodiment, the team score is specified by calculating the individual score of each member based on various parameters that are log information of deliverables on GitHub, and the team score and various parameters are presented. be. Therefore, it becomes possible to appropriately grasp the activity status (performance) of the engineering team. As a result, it is possible to provide an opportunity to improve the management of the engineering team, and to supply the necessary human resources according to the situation of the team organization.

Also, based on the activity status of the engineer team and changes in the activity status of the engineer team, an alert about the activity status is determined and presented to the user. Therefore, it becomes possible to grasp matters to be noted about the activity status of the engineer team in association with the activity status of the engineer team. This makes it possible to identify the cause of fluctuations in the activity status of the engineering team, so that it becomes possible to consider specific plans for improving the management of the engineering team.

In addition to the activity status of the engineer team, the performance of the members belonging to the engineer team is also calculated and presented to the user. Therefore, it becomes possible to grasp the activity status of the engineering team in association with the performance of the members. This makes it possible to grasp that a specific member is the bottleneck and that the review between a specific member and another specific member is the bottleneck.

Furthermore, the activity status of the engineer team is presented to the user so that it can be compared with the activity status of other engineer teams. Therefore, it is possible to grasp the activity status of the engineering team by comparing it with other teams. This makes it possible to more objectively grasp the activity status of the engineering team.

<Second Embodiment>
Another embodiment of the team activity evaluation system 1 will be described below.

<Overall configuration of 1 team activity evaluation system 1>
FIG. 20 is a diagram showing a functional configuration of server 20 that constitutes team activity evaluation system 1 according to the second embodiment. The overall configuration of the team activity evaluation system 1 and the configuration of the terminal device 10 according to the second embodiment are the same as those of the first embodiment, so they will not be described repeatedly. The configuration of the server 20 is the same as that of the first embodiment, except that an engineer database 2024 is newly stored and a function of a recommendation module 2038 is provided as shown in FIG. The functions of the engineer database 2024 and recommendation module 2038 according to the second embodiment will be described below.

The engineer database 2024 is a database for holding various types of information about other teams acquired from the repository server 30 in the team activity evaluation system 1 as, for example, information on an engineer who wishes to be transferred, with the approval of the person himself/herself. The engineer database 2024 may also hold information on engineers who wish to change jobs registered on a so-called job change platform, with the approval of the person. Details will be described later. Note that the engineer database 2024 is not an essential configuration for realizing the function of the recommendation module 2038, and may be configured so that the recommendation module 2038 recommends information on engineers who have received cooperation from other systems or the like.

The recommendation module 2038 is a process of extracting and presenting (recommending) to the user either or both of the cause of the change in the activity status of the engineer team and/or the improvement plan for the engineer team user whose activity status has been presented by the presentation module 2037. to control. At this time, the recommendation module 2038 analyzes various parameters stored in the team score database 2023, outputs the analysis result, and presents the cause of the variation or an improvement plan based on this result. For example, information uploaded online to create deliverables as an engineer (number of codes created, number of pushes, etc.), information on the review of deliverables by members of the engineering team (number of reviews, number of comments, etc.) For either or both of them, the reduced parameter, the task, the action that causes it, and the members are presented, and the change of the member in charge, the assignment of a new member, etc. are presented to the user and recommended.

For example, if the individual score indicating the results of a specific member is stagnant (fluctuating) and affects the activity status of the engineering team, the deliverables (source code, etc.) that the specific member is in charge of The reason may be that it does not match the skill of the specific member concerned, or is not good at it. Therefore, the recommendation module 2038 may present to the user changes in the deliverable (source code, etc.) that the particular member is in charge of. In addition, if the individual score, which indicates review information between specific members, is stagnant and affects the activity status of the engineering team, the compatibility between the specific members is poor, communication is difficult, etc. The cause is considered. Therefore, the recommendation module 2038 may present changes in the review relationship (reviewer, reviewee) between the specific members to the user.

Furthermore, if the number of source code pushes and pull requests is not stagnant, but the number of reviews and comments is stagnant, it is possible that there are not enough reviewers. As such, the recommendation module 2038 may present to the user the participation of other members who are engineers outside the engineering team. At this time, the recommendation module 2038 performs matching with information (values) indicating the engineer's achievements stored in the engineer database 2024, determines whether or not it is applicable, and if it is determined that it is applicable to the engineer team, the engineer to the user. As an example of determining whether or not the engineer team is adaptable, predetermined criteria are selected from the team performance activity status, and engineers who satisfy the selected criteria are selected from other teams registered in the engineer database 2024. It is possible by extracting from engineers and engineers registered on the career change platform. Specifically, when it is detected from the lead time of a pull request that reviews are constantly stagnant as an engineer activity status, review criteria (for example, the number of reviews within a predetermined period threshold or above) is selected, and engineers who satisfy the criteria are extracted and recommended. As another example, if it detects that the overall number of pull requests in the team is decreasing, it will set criteria related to pull requests (for example, the number of pull requests within a predetermined period is greater than or equal to a predetermined threshold). Select, extract engineers who satisfy the criteria, and recommend them.

<2 Data structure>
FIG. 21 is a diagram showing the data structure of the engineer database 2024 stored by the server 20. As shown in FIG.

As shown in FIG. 21, each record in the engineer database 2024 includes an item “engineer ID”, an item “self-reported skill”, an item “score information”, an item “performance details”, and the like. Note that the items "self-reported skills" and the item "score information" are the same as the alliance items of the individual performance database 2022 shown in FIG.

The item “engineer ID” is information for identifying each engineer recommended by the team activity evaluation system 1 .

The item "performance details" is information related to actions obtained from various parameters of log information in GitHub of members belonging to the engineering team who receive presentation of the activity status of the engineering team in the team activity evaluation system 1. Specifically, it includes an item "team ID (affiliation)", an item "action", an item "opponent member ID", an item "value", and the like. Note that the item "action", the item "opponent member ID", and the item "value" are the same as the alliance items in the individual performance database 2022 shown in FIG.

The item “team ID (affiliation)” is information for identifying each engineer team.

When presenting the participation of other members to the user and making a recommendation, the recommendation module 2038 refers to the item “performance details” of the engineer database 2024 to perform matching, and recommends an appropriate engineer to the user.

<3 Operation>
Since the operation in the second embodiment is the same as that in the first embodiment, it will not be described repeatedly.

<4 Screen example>
A screen example of the engineer's recommendation processing by the team activity evaluation system 1 will be described below with reference to FIG. 22 .

FIG. 22 is a diagram showing a screen example of an engineer's recommendation display displayed on the terminal device 10. As shown in FIG. The screen example of FIG. 22 shows a screen example in which the personal score of the engineer making the recommendation and the performance information of the engineer are displayed.

As shown in FIG. 22, the display 132 of the terminal device 10 displays an individual score display column 1043a shown in FIG. and an offer button 1043c to be pressed when making an offer to the engineer. The user refers to the score displayed in the score display column 1043b for the engineer and determines whether to assign the engineer. When the assignment is determined, the user presses the offer button 1043c, so that the engineer is notified. Such a configuration enables assignment to an appropriate engineer.

<Summary>
As described above, according to the present embodiment, improvement proposals are recommended for various parameters of the activity status of the engineering team. For example, a recommendation for a specific member and a recommendation for assignment of a new member are made. As a result, it becomes possible to grasp an improvement proposal for the activity status of the engineering team.

Although the disclosed embodiments have been described above, they can be implemented in various other forms, and can be implemented with various omissions, substitutions, and modifications. These embodiments, modifications, omissions, substitutions and modifications are included within the technical scope of the claims and their equivalents.

<Appendix>
The items described in each of the above embodiments will be added below.

(Appendix 1) A program to be executed by a computer comprising a processor 29 and a storage unit 202. The program is stored in the processor so that a member belonging to an engineer team creates a product as an engineer. a step of specifying a parameter representing the activity status of the engineer team based on the history of information uploaded online and review information of the uploaded product by members of the engineer team (S114); , a step of presenting the parameters to the user (S224), and

(Appendix 2) In the step of specifying the parameters, the source that manages the source code, which is the deliverable of the engineering team, is the information uploaded online of the deliverable and the review information of the deliverable performed by members of the engineering team. The program of (Appendix 1) obtained from a code hosting service.

(Appendix 3) The program according to (Appendix 1) or (Appendix 2), wherein in the step of specifying the parameter, the parameter is specified based on the value indicating the result of each member of the engineering team.

(Appendix 4) The program according to (Appendix 3), wherein the parameter is specified by accumulating values indicating achievements made by each member of the engineering team in a predetermined period specified by the user.

(Appendix 5) As information on uploading deliverables online, the number of uploads, the number of created codes, the number of modified codes, the number of review requests, and the integration that determines the review results for the management means that manages the deliverables in the project within the engineering team The program according to any one of (Appendix 1) to (Appendix 4), which obtains one or more of the numbers.

(Appendix 6) In the step of presenting parameters, one or more of the number of uploads, the number of created codes, the number of modified codes, the number of review requests, and the number of integrations is presented to the user as chronological information, (Appendix 5) program as described.

(Appendix 7) The number of created codes and the number of modified codes are weighted based on the degree of difficulty or importance of the created codes and modified codes, and parameters are specified, or remaining after a predetermined period of time has passed after generation. The program according to (Appendix 5) or (Appendix 6), wherein the parameter is identified based on the history including the number of chords in the program.

(Appendix 8) Acquire one or more of the number of reviews, the number of comments, and the number of comment responses to the management means as review information performed by members of the engineer team on the deliverables, (Appendix 1) to (Appendix 7) Program as described in any.

(Appendix 9) The program according to (Appendix 8), wherein one or more of the number of reviews, the number of comments, and the number of comment responses is presented to the user as chronological information.

(Appendix 10) The program acquires and presents to the user, as a parameter, the lead time indicating the period from the request for review in the engineer team to the closing of the review, to the processor, and presents it to the user. the program described in

(Appendix 11) The program acquires and presents to the user, as the activity status of the engineer team, a breakdown showing the transition of the deliverables requested for review by the engineer team, to the processor, (Appendix 1) to ( A program according to any one of Appendix 10).

(Appendix 12) The program further provides to the processor, as the activity status of the engineer team, the number of comments on the deliverables requested for review by the engineer team, and the lead time indicating the period from the request for review to the closing of the engineer team. The program according to any one of (Appendix 1) to (Appendix 11), which acquires the relationship with and presents it to the user.

(Appendix 13) The program acquires and presents to the user, as the activity status of the engineer team, the relationship between the reviewer who requests the review in the engineer team and the reviewer who receives the review request (Appendix 1). (Appendix 12).

(Appendix 14) The program further causes the processor to execute a step of calculating a value indicating the achievement of the member belonging to the engineer team, and presents the value indicating the achievement of the member belonging to the specific engineer team. The program according to any one of (Appendix 1) to (Appendix 13).

(Appendix 15) As values indicating the results of the members belonging to the engineering team, the number of uploads, the number of created codes, the number of modified codes, the number of review requests, and the review results for the management means that manages the deliverables in the project in the engineer team. The program according to (Appendix 14), which calculates and obtains one or more of the integration numbers to be determined.

(Appendix 16) The program according to any one of (Appendix 1) to (Appendix 15), wherein the program further causes the processor to perform the step of notifying an alert based on a change in the parameter over a predetermined period of time.

(Appendix 17) Detecting that the value of the parameter in a predetermined period is an outlier based on the value of another period of the parameter, and based on the detected outlier, or the results of members belonging to a specific engineer team The program according to (Appendix 16), which notifies an alert based on a change in the value indicating .

(Appendix 18) As a value indicating the results of members belonging to a specific engineer team, the number of uploads, the number of comments, the period until the start of review, the member and other members in the project within the engineer team The program according to (Appendix 17), which detects a change in one or more of the number of reviews, review time, and number of comments, and notifies an alert based on the change.

(Appendix 19) Any one of (Appendix 16) to (Appendix 18), extracting and presenting either or both of the causes of the fluctuations in the activity status of the engineering team and/or improvement proposals based on the fluctuations in the parameters during a predetermined period program described in .

(Appendix 20) As a cause of parameter fluctuation, from the history of the engineering team, in the predetermined period, information that the reduced deliverables were uploaded online, review information performed by members of the engineering team Either or both The program according to (Appendix 19), which presents

(Appendix 21) Analyze the history of the engineer team, detect and present any or more of the tasks, actions, and members belonging to the engineer team that cause the parameter fluctuations in the predetermined period, (Appendix 19) or the program according to (Appendix 20).

(Appendix 22) The program further instructs the processor to obtain a value indicating the achievement of the engineer outside the engineer team, match the value indicating the achievement of the engineer outside the engineer team with the history of the engineer team, and A step of determining whether an engineer outside the team is adaptable to the engineering team, and if it is judged that the engineer outside the engineering team is adaptable to the engineering team, the participation of the engineer outside the engineering team in the engineering team as an improvement plan The program according to any one of (Appendix 19) to (Appendix 21), causing execution of the step of presenting

(Appendix 23) The program further causes the processor to perform a step of associating the parameter with the time-series information and presenting the parameter representing the activity status of the other engineer team with the time-series information in a comparable manner. The program according to any one of (Appendix 1) to (Appendix 22).

(Appendix 24) The program according to (Appendix 23), in which the lead time is used as a reference together with the parameters and presented so as to be comparable with other engineering teams.

(Appendix 25) An information processing device comprising a control unit and a storage unit, wherein the control unit stores information uploaded online by a member belonging to an engineer team in order to create a deliverable as an engineer. , a step of identifying a parameter representing the activity status of the engineering team based on the history of review information of the uploaded product by members of the engineering team, and a step of presenting the parameter to the user. An information processing device that executes.

(Appendix 26) A method for being executed by a computer comprising a processor and a storage unit, the method comprising: a processor which is used by a member belonging to an engineering team to create a product as an engineer; a step of identifying a parameter representing the activity status of the engineering team based on the history of the information uploaded above and the review information of the uploaded deliverable by the members of the engineering team; and providing the parameter to the user. The steps presented and the method of performing.

10 terminal device, 20 server, 80 network, 130 operation reception unit, 161 user information, 22 communication IF, 23 input/output IF, 25 memory, 26 storage, 29 processor, 201 communication unit, 202 storage unit, 2021 repository database, 2022 Individual performance database, 2023 Team score database, 2024 Engineer database, 203 Control unit

Claims (15)

A program to be executed by a computer comprising a processor and a storage unit,
The program causes the processor to:
Information uploaded online by a member belonging to the engineering team to create a deliverable as an engineer from a repository set for each engineering team, and the configuration of the engineering team with respect to the uploaded deliverable. obtaining review information made by the member;
a step of identifying a parameter representing the activity status of the engineering team based on the history of the uploaded information and the review information obtained from a repository set for each engineering team ;
and presenting said parameters to a user. In the acquiring step, the uploaded information and the review information are acquired from the repository using a repository ID that identifies the repository set for each engineer team;
A program according to claim 1. In the presenting step, at least one of an average time until the engineer team makes the first comment on the source code requested for review and an average time from review to closing is acquired as the parameter. to present to the user,
3. The program according to claim 1 or 2. In the step of acquiring , the information uploaded online of the deliverables and the review information of the deliverables conducted by members of the engineering team are stored in a source code for managing the source code, which is the deliverable of the engineering team. 4. A program according to any one of claims 1 to 3 , obtained from a hosting service. 5. The program according to any one of claims 1 to 4 , wherein, in the step of specifying the parameter, the parameter is specified based on a value indicating the results of each member of the engineering team. 6. The program according to claim 5 , wherein in said specifying step, said parameter is specified by accumulating a value indicating achievements made by each member of said engineer team in a predetermined period specified by a user. In the obtaining step, the number of uploads, the number of created codes, the number of modified codes, the number of review requests, and the number of reviews for management means for managing the deliverables in the project within the engineering team as the information uploaded online of the deliverables. 7. A program according to any one of claims 1 to 6 , for obtaining any or more of a number of consolidations that establish a result. 8. In the step of presenting the parameters, one or more of the number of uploads, the number of created codes, the number of corrected codes, the number of review requests , and the number of integrations is presented to the user as chronological information. program described in . In the step of identifying the parameters, weighting is performed based on the degree of difficulty or importance of the created code and the modified code associated with the number of created codes and the number of modified codes to specify the parameters, or after creation, a predetermined 9. The program according to claim 7 or 8 , wherein said parameter is specified based on said history including the number of remaining codes after a period of time has elapsed. In the acquiring step, the number of reviews, the number of comments, and the number of comment responses to a source code hosting service that manages the source code that is the deliverable of the engineering team, as review information on the deliverable by members of the engineering team. 10. The program according to any one of claims 1 to 9 , which acquires any one or more of 11. The program according to claim 10 , wherein in the step of presenting the parameter, one or more of the number of reviews, the number of comments, and the number of comment responses is presented to the user as chronological information. The program further causes the processor to:
Execute a step of calculating a value indicating the achievement of a member belonging to the engineering team,
12. The program according to any one of claims 1 to 11 , which presents a value indicating achievements of members belonging to the specific engineer team. In the calculating step, the number of uploads, the number of created codes, the number of modified codes, and a review request to the management means for managing the deliverables in the project in the engineer team as values indicating the results of the members belonging to the engineer team. 13. The program according to claim 12 , which calculates and obtains one or more of the number and the integrated number that determines the review result. An information processing device comprising a control unit and a storage unit,
The control unit
Information uploaded online by a member belonging to the engineering team to create a deliverable as an engineer from a repository set for each engineering team, and the configuration of the engineering team with respect to the uploaded deliverable. obtaining review information provided by the member;
a step of identifying a parameter representing the activity status of the engineering team based on the history of the uploaded information and the review information obtained from a repository set for each engineering team ;
and presenting the parameter to a user. A method for being executed by a computer comprising a processor and a storage unit, comprising:
The method comprises: the processor;
Information uploaded online by a member belonging to the engineering team to create a deliverable as an engineer from a repository set for each engineering team, and the configuration of the engineering team with respect to the uploaded deliverable. obtaining review information provided by the member;
a step of identifying a parameter representing the activity status of the engineering team based on the history of the uploaded information and the review information obtained from a repository set for each engineering team ;
presenting said parameters to a user.

Images