特開 2024-117057 情報処理装置、方法、プログラム、およびシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024117057

(43)【公開日】2024-08-28

(54)【発明の名称】情報処理装置、方法、プログラム、およびシステム

(51)【国際特許分類】

   G06Q 10/0637 20230101AFI20240821BHJP

   G06N 20/00 20190101ALI20240821BHJP

   G06F 16/783 20190101ALI20240821BHJP

【ＦＩ】

G06Q10/0637

G06N20/00

G06F16/783

【審査請求】未請求

【請求項の数】19

【出願形態】ＯＬ

(21)【出願番号】P 2023191635

(22)【出願日】2023-11-09

(62)【分割の表示】P 2023022107の分割

【原出願日】2023-02-16

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＰＹＴＨＯＮ

２．ＴＥＮＳＯＲＦＬＯＷ

(71)【出願人】

【識別番号】516291402

【氏名又は名称】ファインディ株式会社

(74)【代理人】

【識別番号】110002815

【氏名又は名称】ＩＰＴｅｃｈ弁理士法人

(72)【発明者】

【氏名】志賀 優毅

(72)【発明者】

【氏名】稲葉 将一

(72)【発明者】

【氏名】柳沢 正二郎

(72)【発明者】

【氏名】内田 博咲也

(72)【発明者】

【氏名】笹野 翔太

(72)【発明者】

【氏名】山家 史照

【テーマコード（参考）】

5B175

5L010

5L049

【Ｆターム（参考）】

5B175FA01

5B175FB04

5L010AA09

5L049AA09

(57)【要約】

【課題】エンジニアによる開発業務の質を効率的かつ客観的に評価する技術を提供する。
【解決手段】本開示の一態様のプログラムは、コンピュータを、エンジニアがイシュー管理サービスを利用することで当該イシュー管理サービスに保存された情報から、第１エンジニアがイシュー管理サービスのローカルリポジトリに追加または変更したファイルのレビューを依頼するレビュー依頼の内容および当該レビュー依頼に関連する付加情報を取得する手段、レビュー依頼の内容および当該レビュー依頼に関連する付加情報に基づくモデル入力情報に、レビュー依頼の評価のための推論を行う学習済みモデルを適用することで、レビュー依頼を評価する手段、レビュー依頼の評価結果を出力する手段、として機能させる。
【選択図】図４

【特許請求の範囲】

【請求項1】

コンピュータを、
エンジニアがイシュー管理サービスを利用することで当該イシュー管理サービスに保存された情報から、第１エンジニアが前記イシュー管理サービスのローカルリポジトリに追加または変更したファイルのレビューを依頼するレビュー依頼の内容および当該レビュー依頼に関連する付加情報を取得する手段、
前記レビュー依頼の内容および当該レビュー依頼に関連する付加情報に基づくモデル入力情報に、前記レビュー依頼の評価のための推論を行う学習済みモデルを適用することで、前記レビュー依頼を評価する手段、
前記レビュー依頼の評価結果を出力する手段、
として機能させるプログラム。

【請求項2】

前記モデル入力情報は、前記レビュー依頼に関するボリューム情報を含む、
請求項１に記載のプログラム。

【請求項3】

前記ボリューム情報は、前記レビュー依頼の変更行数、または変更ファイル数の少なくとも１つに関する、
請求項２に記載のプログラム。

【請求項4】

前記モデル入力情報は、前記レビュー依頼に関する文字情報を含む、
請求項１に記載のプログラム。

【請求項5】

前記文字情報は、前記レビュー依頼の変更ファイルの拡張子に関する情報、変更ファイル名に出現する文字列に関する情報、前記変更ファイルに出現する文字列に関する情報、または前記変更ファイルから抽出された特徴ベクトルの少なくとも１つに関する、
請求項４に記載のプログラム。

【請求項6】

前記モデル入力情報は、前記レビュー依頼に関する時間情報を含む、
請求項１に記載のプログラム。

【請求項7】

前記時間情報は、前記レビュー依頼の作成からレビューがなされるまでの所要時間の実測値もしくは予測値、前記レビュー依頼に対応するファイルを前記ローカルリポジトリに記録した時刻、前記レビュー依頼の作成時刻、前記レビュー依頼がドラフト状態からオープン状態に遷移するまでの所要時間の実測値もしくは予測値、または前記レビュー依頼がオープン状態に遷移してからレビュアーがアサインされるまでの所要時間の実測値もしくは予測値の少なくとも１つに関する、
請求項６に記載のプログラム。

【請求項8】

前記モデル入力情報は、前記レビュー依頼に関する作業者情報を含む、
請求項１に記載のプログラム。

【請求項9】

前記作業者情報は、前記第１エンジニア、または前記レビュー依頼にアサインされたレビュアーの少なくとも１つに関する、
請求項８に記載のプログラム。

【請求項10】

前記レビュー依頼を評価する手段は、前記モデル入力情報に、前記レビュー依頼による障害の発生リスクについて推論を行う学習済みモデルを適用することで、前記レビュー依頼を評価する、
請求項１に記載のプログラム。

【請求項11】

前記レビュー依頼を評価する手段は、前記モデル入力情報に、前記レビュー依頼に関するリードタイムについて推論を行う学習済みモデルを適用することで、前記レビュー依頼を評価する、
請求項１に記載のプログラム。

【請求項12】

前記リードタイムは、レビュアーアサインから最初のレビューまでの所要時間、レビューから前記レビュー依頼に対応するファイルのプロジェクト本体への統合が承認されるまでの所要時間、または前記レビュー依頼がオープン状態に遷移してから当該レビュー依頼に対応するファイルのプロジェクト本体への統合が承認されるまでの所要時間の少なくとも１つを含む、
請求項１１に記載のプログラム。

【請求項13】

前記学習済みモデルは、エンジニア単位、複数のエンジニアを含むチーム単位、複数のチームを含む組織単位、または複数の組織を含む業界単位毎に構築されている、
請求項１に記載のプログラム。

【請求項14】

前記学習済みモデルは、プログラミング言語またはマークアップ言語毎に構築されている、
請求項１に記載のプログラム。

【請求項15】

前記コンピュータを、
前記モデル入力情報に含まれる要素が前記レビュー依頼の評価結果に及ぼした影響を分析する手段、
前記影響の分析結果を出力する手段、
として機能させる、請求項１に記載のプログラム。

【請求項16】

前記評価する手段は、前記レビュー依頼を複数の時点において評価し、
前記出力する手段は、前記レビュー依頼の前記複数の時点それぞれにおける評価結果を出力する、
請求項１に記載のプログラム。

【請求項17】

コンピュータが、
エンジニアがイシュー管理サービスを利用することで当該イシュー管理サービスに保存された情報から、第１エンジニアが前記イシュー管理サービスのローカルリポジトリに追加または変更したファイルのレビューを依頼するレビュー依頼の内容および当該レビュー依頼に関連する付加情報を取得するステップと、
前記レビュー依頼の内容および当該レビュー依頼に関連する付加情報に基づくモデル入力情報に、前記レビュー依頼の評価のための推論を行う学習済みモデルを適用することで、前記レビュー依頼を評価するステップと、
前記レビュー依頼の評価結果を出力するステップと
を実行する方法。

【請求項18】

エンジニアがイシュー管理サービスを利用することで当該イシュー管理サービスに保存された情報から、第１エンジニアが前記イシュー管理サービスのローカルリポジトリに追加または変更したファイルのレビューを依頼するレビュー依頼の内容および当該レビュー依頼に関連する付加情報を取得する手段と、
前記レビュー依頼の内容および当該レビュー依頼に関連する付加情報に基づくモデル入力情報に、前記レビュー依頼の評価のための推論を行う学習済みモデルを適用することで、前記レビュー依頼を評価する手段と、
前記レビュー依頼の評価結果を出力する手段と
を具備する情報処理装置。

【請求項19】

第１情報処理装置と第２情報処理装置とを具備するシステムであって、
前記第１情報処理装置は、
エンジニアがイシュー管理サービスを利用することで当該イシュー管理サービスに保存された情報から、第１エンジニアが前記イシュー管理サービスのローカルリポジトリに追加または変更したファイルのレビューを依頼するレビュー依頼の内容および当該レビュー依頼に関連する付加情報を取得する手段と、
前記レビュー依頼の内容および当該レビュー依頼に関連する付加情報に基づくモデル入力情報に、前記レビュー依頼の評価のための推論を行う学習済みモデルを適用することで、前記レビュー依頼を評価する手段と、
前記レビュー依頼の評価結果を前記第２情報処理装置へ出力する手段と
を備える、
システム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、情報処理装置、方法、プログラム、およびシステムに関する。

【背景技術】

【0002】

組織において、その構成員が行った業務の生産性や業務の質の良し悪しを評価することは重要である。

【0003】

特許文献１には、質的な観点から業務を評価し、当該業務に関連する業務を的確に評価することを企図した技術思想が記載されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開2011-164715号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

特許文献１の技術思想では、ユーザ（活動主体）が活動に対して主観的評価を行う必要がある。故に、この技術思想は、実施にあたってユーザに煩雑な作業を強いるという問題に加えて、同一の活動（業務）であっても主体によって異なる評価を受け得る（つまり評価が客観的でない）という問題がある。

【0006】

本開示の目的は、エンジニアによる開発業務の質を効率的かつ客観的に評価する技術を提供することである。

【課題を解決するための手段】

【0007】

本開示の一態様のプログラムは、コンピュータを、エンジニアがイシュー管理サービスを利用することで当該イシュー管理サービスに保存された情報から、第１エンジニアがイシュー管理サービスのローカルリポジトリに追加または変更したファイルのレビューを依頼するレビュー依頼の内容および当該レビュー依頼に関連する付加情報を取得する手段、レビュー依頼の内容および当該レビュー依頼に関連する付加情報に基づくモデル入力情報に、レビュー依頼の評価のための推論を行う学習済みモデルを適用することで、レビュー依頼を評価する手段、レビュー依頼の評価結果を出力する手段、として機能させる。

【図面の簡単な説明】

【0008】

【図1】本実施形態の情報処理システムの構成を示すブロック図である。

【図2】本実施形態のクライアント装置の構成を示すブロック図である。

【図3】本実施形態のサーバの構成を示すブロック図である。

【図4】本実施形態の一態様の説明図である。

【図5】本実施形態のリポジトリデータベースのデータ構造を示す図である。

【図6】本実施形態の開発活動データベースのデータ構造を示す図である。

【図7】本実施形態の情報処理のフローチャートである。

【図8】本実施形態の情報処理において表示される画面例を示す図である。

【発明を実施するための形態】

【0009】

以下、本発明の一実施形態について、図面に基づいて詳細に説明する。なお、実施形態を説明するための図面において、同一の構成要素には原則として同一の符号を付し、その繰り返しの説明は省略する。

【0010】

本明細書において、チームとは、複数人のメンバーにより構成される集団を意味する。本明細書では、チームとは、複数のエンジニアにより構成される集団であるエンジニアチームを指す場合もある。チームは、特定のプロダクトの開発を担当する。プロダクトは、典型的にはソフトウェアであり、例えば、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）などのＷｅｂサービスを提供するためのＷｅｂサイトであってもよいし、コンピュータにインストールされるアプリケーションであってもよい。チーム内では、それぞれのエンジニアが機能ごと、アウトプットごと等に役割分担して開発を進める。１つまたは複数のチームは、例えば企業などの組織に属する場合がある。また、チーム内のエンジニアは、特定の１つの企業（組織）に雇用されている会社員のみに限られず、複数の企業が共同で開発を進める開発プロジェクトにおける任意の企業の会社員でもよい。さらに、チーム内のエンジニアには、派遣社員、個人事業主（いわゆるフリーランス）のエンジニアが含まれてもよい。

【0011】

（１）情報処理システムの構成
情報処理システムの構成について説明する。図１は、本実施形態の情報処理システムの構成を示すブロック図である。

【0012】

図１に示すように、情報処理システム１は、クライアント装置１０と、サーバ３０とを備える。
クライアント装置１０及びサーバ３０は、ネットワーク（例えば、インターネット又はイントラネット）ＮＷを介して接続される。また、サーバ３０は、ネットワークＮＷを介して外部システム５０と接続される。

【0013】

クライアント装置１０は、サーバ３０にリクエストを送信する情報処理装置の一例である。クライアント装置１０は、例えば、スマートフォン、タブレット端末、又は、パーソナルコンピュータである。クライアント装置１０は、情報処理システム１によって提供される、レビュー依頼に対する評価結果を確認するために用いることができる。ここで、レビュー依頼とは、エンジニアがローカルリポジトリに追加または変更したファイルのレビューを他者に依頼する活動を指し、例えばＧｉｔＨｕｂにおけるプルリクエストに相当する。

【0014】

クライアント装置１０のユーザは、例えば、以下の少なくとも１つを含むことができる。
・評価対象となるレビュー依頼を行ったエンジニア
・評価対象となるレビュー依頼をアサインされたレビュアー
・上記エンジニアまたはレビュアーが所属するチームの他メンバーまたはリーダー
・上記エンジニアまたはレビュアーが担当するプロダクトの開発責任者
・上記エンジニアまたはレビュアーの上長
・上記エンジニアまたはレビュアーが所属する組織における人事担当者
・上記エンジニアまたはレビュアーが所属する組織における経営幹部
・上記エンジニアまたはレビュアーが所属する組織の求人情報を閲覧する者
・上記エンジニアまたはレビュアーへの業務の依頼、または雇用を検討している者

【0015】

サーバ３０は、クライアント装置１０から送信されたリクエストに応じたレスポンスをクライアント装置１０に提供する情報処理装置の一例である。サーバ３０は、例えば、サーバコンピュータである。サーバ３０は、クライアント装置１０からのリクエストに応じて、レビュー依頼の評価結果を提供する。

【0016】

外部システム５０は、サーバ３０からのリクエストに応じて、エンジニアによる開発活動に関する情報を提供する。外部システム５０は、典型的には、ＧｉｔＨｕｂ（登録商標）などの、ソフトウェア開発プラットフォームである。ＧｉｔＨｕｂは、エンジニアによる開発の成果物であるソースコードの管理、およびソースコードに対するレビューの管理等を行う。

【0017】

なお、外部システム５０は、ＧｉｔＨｕｂに限られず、ＧｉｔＬａｂ（登録商標）またはＢｉｔｂｕｃｋｅｔ（登録商標）等の他のソフトウェア開発プラットフォームであってもよい。或いは、外部システム５０は、ソフトウェア開発における課題管理ツール（例えばＪｉｒａ（登録商標））、またはタスク管理ツール（例えば、Ｔｒｅｌｌｏ（登録商標）またはｂａｃｋｌｏｇ（登録商標）等）であってもよい。これらソフトウェア開発プラットフォーム、課題管理ツールまたはタスク管理ツールは、イシュー管理サービスとして総称することもできる。以下の説明では、外部システム５０として、ＧｉｔＨｕｂを利用することを前提として述べる。

【0018】

ＧｉｔＨｕｂは、ソースコードホスティングサービスである。ＧｉｔＨｕｂは、開発の成果物であるソースコードのバージョン管理を行うためのリポジトリ（管理手段）を有する。ＧｉｔＨｕｂは、ある時点におけるソースコードの一覧を管理している。ＧｉｔＨｕｂは、イシュー（作成）、プッシュ、コミット、プルリクエスト、マージ等の各種機能を備えている。

【0019】

イシューは、プロジェクトやソースコードの課題を管理するための機能である。プッシュは、エンジニアのローカル環境（ローカルリポジトリ）で作成又は修正を行ったソースコードをリモート環境（リモートリポジトリ）へアップロードする機能である。コミットは、ソースコードへの変更内容を登録するための機能である。プルリクエストは、プッシュがなされたことを通知してレビューを依頼する機能である。マージは、レビュー結果を確定させて履歴を統合する機能である。ここで、ソースコードとは、Ｐｙｔｈｏｎのようなプログラミング言語、またはＨＴＭＬ、ＣＳＳのようなマークアップ言語により記述されるコード（文字列）に加え、ＪａｖａＳｃｒｉｐｔ（登録商標）のようなプログラミング言語の一種であるスクリプト言語により記述されるスクリプト（文字列）を含む概念である。

【0020】

プログラミング言語とは、ソフトウェア開発に用いられる言語であり、具体的にはＪａｖａＳｃｒｉｐｔ（登録商標）、Ｊａｖａ（登録商標）、Ｓｃａｌａ、ＰＨＰ、Ｒｕｂｙ、Ｐｙｔｈｏｎ、Ｇｏ、Ｃ＃、などがある。また、ソフトウェアフレームワークとはソフトウェア開発に利用するソフトウェアプラットフォームであり、具体的には、ｊＱｕｅｒｙ、Ｒｅａｃｔ、Ｖｕｅ.ｊｓ、Ａｎｇｕｌａｒ、Ｎｕｘｔ.ｊｓ、Ｎｅｘｔ.ｊｓ、ＲｅａｃｔＮａｔｉｖｅ、Ｓｐｒｉｎｇ Ｆｒａｍｅｗｏｒｋ、Ｐｌａｙ Ｆｒａｍｅｗｏｒｋ、Ｌａｒａｖｅｌ、ＣａｋｅＰＨＰ、ＲｕｂｙｏｎＲａｉｌｓ、Ｄｊａｎｇｏ、Ｆｌａｓｋ、ＴｅｎｓｏｒＦｌｏｗ、ｇｉｎ、Ｕｎｉｔｙ、Ｅｘｐｒｅｓｓなどがある。

【0021】

（１－１）クライアント装置の構成
クライアント装置の構成について説明する。図２は、本実施形態のクライアント装置の構成を示すブロック図である。

【0022】

図２に示すように、クライアント装置１０は、記憶装置１１と、プロセッサ１２と、入出力インタフェース１３と、通信インタフェース１４とを備える。クライアント装置１０は、ディスプレイ２１に接続される。

【0023】

記憶装置１１は、プログラム及びデータを記憶するように構成される。記憶装置１１は、例えば、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、及び、ストレージ（例えば、フラッシュメモリ又はハードディスク）の組合せである。

【0024】

プログラムは、例えば、以下のプログラムを含む。
・ＯＳ（Operating System）のプログラム
・情報処理を実行するアプリケーション（例えば、ウェブブラウザ）のプログラム

【0025】

データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理を実行することによって得られるデータ（つまり、情報処理の実行結果）

【0026】

プロセッサ１２は、記憶装置１１に記憶されたプログラムを起動することによって、クライアント装置１０の機能を実現するコンピュータである。プロセッサ１２は、例えば、以下の少なくとも１つである。
・ＣＰＵ（Central Processing Unit）
・ＧＰＵ（Graphic Processing Unit）
・ＡＳＩＣ（Application Specific Integrated Circuit）
・ＦＰＧＡ（Field Programmable Array）

【0027】

入出力インタフェース１３は、クライアント装置１０に接続される入力デバイスから情報（例えばユーザの指示）を取得し、かつ、クライアント装置１０に接続される出力デバイスに情報（例えば画像信号）を出力するように構成される。
入力デバイスは、例えば、キーボード、ポインティングデバイス、タッチパネル、又は、それらの組合せである。
出力デバイスは、例えば、ディスプレイ２１、スピーカ、又は、それらの組合せである。

【0028】

通信インタフェース１４は、クライアント装置１０と外部装置（例えばサーバ３０）との間の通信を制御するように構成される。

【0029】

ディスプレイ２１は、画像（静止画、または動画）を表示するように構成される。ディスプレイ２１は、例えば、液晶ディスプレイ、または有機ＥＬディスプレイである。

【0030】

（１－２）サーバの構成
サーバの構成について説明する。図３は、本実施形態のサーバの構成を示すブロック図である。

【0031】

図３に示すように、サーバ３０は、記憶装置３１と、プロセッサ３２と、入出力インタフェース３３と、通信インタフェース３４とを備える。

【0032】

記憶装置３１は、プログラム及びデータを記憶するように構成される。記憶装置３１は、例えば、ＲＯＭ、ＲＡＭ、及び、ストレージ（例えば、フラッシュメモリ又はハードディスク）の組合せである。

【0033】

プログラムは、例えば、以下のプログラムを含む。
・ＯＳのプログラム
・情報処理を実行するアプリケーションのプログラム

【0034】

データは、例えば、以下のデータを含む。
・情報処理において参照されるデータベース
・情報処理の実行結果

【0035】

プロセッサ３２は、記憶装置３１に記憶されたプログラムを起動することによって、サーバ３０の機能を実現するコンピュータである。プロセッサ３２は、例えば、以下の少なくとも１つである。
・ＣＰＵ
・ＧＰＵ
・ＡＳＩＣ
・ＦＰＧＡ

【0036】

入出力インタフェース３３は、サーバ３０に接続される入力デバイスからユーザの指示を取得し、かつ、サーバ３０に接続される出力デバイスに情報を出力するように構成される。
入力デバイスは、例えば、キーボード、ポインティングデバイス、タッチパネル、又は、それらの組合せである。
出力デバイスは、例えば、ディスプレイである。

【0037】

通信インタフェース３４は、サーバ３０と外部装置（例えばクライアント装置１０または外部システム５０）との間の通信を制御するように構成される。

【0038】

（２）実施形態の一態様
本実施形態の一態様について説明する。図４は、本実施形態の一態様の説明図である。

【0039】

図４に示すように、様々なエンジニアが、外部システム５０を利用して種々の開発活動を行う。外部システム５０は、このような開発活動のログに関する情報（以下、「開発活動情報」という）を保存する。サーバ３０は、外部システム５０から開発活動情報のうち、特にレビュー依頼に関する情報を取得する。サーバ３０は、レビュー依頼の内容、またはレビュー依頼に関連する付加情報（後述）の少なくとも１つを取得する。サーバ３０は、レビュー依頼に関する開発活動情報を定期的に収集してもよいし、何らかのトリガ（例えば、クライアント装置１０からの評価要求の受信）に応じてかかる開発活動情報を収集してもよい。

【0040】

サーバ３０は、外部システム５０に蓄積されているレビュー依頼の中から、評価対象となるレビュー依頼を決定する。サーバ３０は、決定した評価対象（レビュー依頼）の内容、または当該評価対象に関連する付加情報の少なくとも１つに基づいてモデル入力情報を生成する。

【0041】

サーバ３０は、生成したモデル入力情報に、レビュー依頼評価モデルを適用することで、当該モデル入力情報に対応するレビュー依頼を評価する。レビュー依頼評価モデルは、レビュー依頼の評価のための推論を行う学習済みモデルであり、後述する機械学習（教師あり学習）の結果に基づいて構築され得る。

【0042】

サーバ３０は、レビュー依頼の評価結果をクライアント装置１０へ送信する。クライアント装置１０は、レビュー依頼の評価結果に基づく情報をユーザＵＳ１に提示する。

【0043】

ユーザＵＳ１は、評価対象であるレビュー依頼を行ったエンジニアと異なる人物であってもよい。例えば、ユーザＵＳ１が、レビュー依頼に対してアサインされたレビュアーである場合に、ユーザＵＳ１は、レビューを開始する前に当該レビュー依頼に対する評価結果を確認することで、レビューに要する工数を事前に見積もりやすくなる。或いは、ユーザＵＳ１が、レビュー依頼を行ったエンジニアを管理または人事評価する立場にある人物の場合に、各エンジニアが行ったレビュー依頼の評価結果を、チーム内の業務の割り当てやエンジニアの人事評価の判断材料として用いることができる。

【0044】

他方、ユーザＵＳ１は、評価対象であるレビュー依頼を行ったエンジニアと同一人物であってもよい。この場合に、ユーザＵＳ１が行ったレビュー依頼について、レビュー依頼の評価結果に基づく情報をユーザＵＳ１に提示することで、本人の内省を促したり、本人を鼓舞したりすることができる。

【0045】

このように、本実施形態によれば、エンジニアによる開発業務（具体的には、レビュー依頼）の質を効率的かつ客観的に評価することが可能となる。この結果、レビュー依頼の質の改善が促されたり、質の低いレビュー依頼が後工程の着手前に検知されたりするので、チーム全体での開発の効率の向上（例えばリードタイム短縮または障害減少による開発スピードの向上）および質の向上（例えばバグの少ないソフトウェア）が期待できる。

【0046】

（３）データベース
本実施形態のデータベースについて説明する。以下のデータベースは、記憶装置３１に記憶される。

【0047】

（３－１）リポジトリデータベース
本実施形態のリポジトリデータベースについて説明する。図５は、本実施形態のリポジトリデータベースのデータ構造を示す図である。

【0048】

リポジトリデータベースには、リポジトリ情報が格納される。リポジトリ情報は、外部システム５０において作成されているリポジトリに関する情報である。

【0049】

図５に示すように、リポジトリデータベースは、「リポジトリＩＤ」フィールドと、「チームＩＤ」フィールドと、「アドレス」フィールドとを含む。各フィールドは、互いに関連付けられている。

【0050】

「リポジトリＩＤ」フィールドには、リポジトリＩＤが格納される。リポジトリＩＤは、リポジトリを識別する情報である。サーバ３０は、外部システム５０からリポジトリＩＤを取得可能である。

【0051】

「チームＩＤ」フィールドには、チームＩＤが格納される。チームＩＤは、対応するリポジトリＩＤによって特定されるリポジトリを作成したチームを識別する情報である。サーバ３０は、外部システム５０からチームＩＤを取得可能である。なお、チームＩＤは、例えば後述するレビュー依頼評価モデルをチーム単位で構築するなどの目的で同一チームに属するエンジニアによる開発活動情報を収集する時に有用であるが、かかる情報の収集が必要でない構成の場合、リポジトリデータベースにチームＩＤを格納しなくてもよい。

【0052】

チームＩＤは、図示しないデータベースにおいて、組織ＩＤと関連付けられてもよい。チームＩＤに関連付けられる組織ＩＤは、当該チームＩＤに対応するチームが属する組織を識別する。また、チームＩＤは、図示しないデータベースにおいて、エンジニアＩＤと関連付けられてもよい。チームＩＤに関連付けられるエンジニアＩＤは、当該チームＩＤに対応するチームに属するメンバーを識別する。

【0053】

「アドレス」フィールドには、アドレス情報が格納される。アドレス情報は、対応するリポジトリＩＤによって特定されるリポジトリにアクセスするための情報（例えばＵＲＬ（Uniform Resource Locator））である。

【0054】

（３－２）開発活動データベース
本実施形態の開発活動データベースについて説明する。図６は、本実施形態の開発活動データベースのデータ構造を示す図である。

【0055】

開発活動データベースには、開発活動情報が格納される。開発活動情報は、外部システム５０において作成されたリポジトリに保存されているソースコードに関して、エンジニアにより行われた活動に関する情報である。

【0056】

外部システム５０は、例えば、ユーザ（つまり、エンジニア）がソースコードをローカルリポジトリからプッシュした場合に、プッシュを行ったユーザを特定可能な情報、およびプッシュが行われた日時をログ情報として記録する。同様に、以下の少なくとも１つの活動について、外部システムはログ情報を記録する。
・追加または変更したファイルをイシュー管理サービスのローカルリポジトリに記録する活動（例えばＧｉｔＨｕｂにおけるコミットに相当し、以下、同様の活動を「コミット」という）
・ソースコードに関してイシューを作成する活動
・イシューをクローズする活動
・ローカルリポジトリに追加または変更したファイルのレビューを依頼する活動（例えばＧｉｔＨｕｂにおけるプルリクエストに相当し、以下、同様の活動を「プルリクエスト」という）
・上記依頼に応じてファイルをレビューする活動
・レビューを依頼されたファイルのプロジェクト本体への統合を承認（例えばＧｉｔＨｕｂにおけるマージに相当し、以下、同様の活動を「マージ」という）する活動
・コメントを作成する活動
・コメントに対する回答を作成する活動

【0057】

サーバ３０は、外部システム５０から取得した開発活動情報に基づいて、開発活動データベースを更新する。サーバ３０は、定期的に開発活動情報を取得してもよいし、何らかのトリガ（例えば、クライアント装置１０からの評価要求の受信）に応じて開発活動情報を取得してもよい。

【0058】

図６に示すように、開発活動データベースは、「活動ＩＤ」フィールドと、「リポジトリＩＤ」フィールドと、「アクションＩＤ」フィールドと、「エンジニアＩＤ」フィールドと、「日時」フィールドと、「ソースコード」フィールドとを含む。

【0059】

「活動ＩＤ」フィールドには、活動ＩＤが格納される。活動ＩＤは、外部システム５０において作成されたリポジトリに保存されているソースコードに関して、エンジニアにより行われた活動を識別する情報である。

【0060】

「リポジトリＩＤ」フィールドには、リポジトリＩＤが格納される。リポジトリＩＤは、対応する活動ＩＤによって特定される活動が行われたソースコードが保存されているリポジトリを識別する情報である。

【0061】

「アクション」フィールドには、アクション情報が格納される。アクション情報は、対応する活動ＩＤによって特定される活動の種別に関する情報である。

【0062】

「エンジニアＩＤ」フィールドには、エンジニアＩＤが格納される。エンジニアＩＤは、対応する活動ＩＤによって特定される活動を行ったエンジニア（つまり、外部システム５０のユーザ）を識別する情報である。

【0063】

「日時」フィールドには、日時情報が格納される。日時情報は、対応する活動ＩＤによって特定される活動が行われた日時に関する情報である。

【0064】

「ソースコード」フィールドには、ソースコード情報が格納される。ソースコード情報は、対応する活動ＩＤによって特定される活動が行われたソースコードに関する情報（例えば、ファイル名情報、変更ファイルの情報）である。

【0065】

（４）情報処理
本実施形態の情報処理について説明する。図７は、本実施形態の情報処理のフローチャートである。図８は、本実施形態の情報処理において表示される画面例を示す図である。

【0066】

図７の情報処理は、定期的に実行されてもよいし、クライアント装置１０からの要求に応じて実行されてもよい。

【0067】

図７に示すように、サーバ３０は、評価対象の決定（Ｓ１３０）を実行する。
具体的には、サーバ３０は、外部システム５０に蓄積されているレビュー依頼の中から、評価対象となるレビュー依頼を決定する。

【0068】

評価対象の決定（Ｓ１３０）の第１例として、サーバ３０は、特定のユーザによって指定されたレビュー依頼を評価対象として決定する。ユーザは、評価対象とするレビュー依頼を個々に指定してもよいし、リポジトリ単位で指定してもよい。ユーザがリポジトリを指定した場合に、サーバ３０は当該リポジトリのレビュー依頼を無条件で全て評価対象として決定し得る。

【0069】

評価対象の決定（Ｓ１３０）の第２例として、サーバ３０は、特定のユーザがレビュアーとしてアサインされたレビュー依頼を評価対象として決定する。

【0070】

評価対象の決定（Ｓ１３０）の第３例として、サーバ３０は、特定のユーザが指定したエンジニアによって行われたレビュー依頼、または当該エンジニアがレビュアーとしてアサインされたレビュー依頼を評価対象として決定する。

【0071】

評価対象の決定（Ｓ１３０）の第４例として、サーバ３０は、特定のユーザが指定したチームにおいて発生したレビュー依頼を評価対象として決定する。

【0072】

評価対象の決定（Ｓ１３０）の第５例として、サーバ３０は、特定のユーザが行ったレビュー依頼を評価対象として決定する。

【0073】

評価対象の決定（Ｓ１３０）の第６例として、サーバ３０は、直近の所定期間（例えば本情報処理の前回実行以降の期間）に発生したレビュー依頼（要するに新規のレビュー依頼）、または当該所定期間内に状態が変化した（例えばオープン状態となった）レビュー依頼を評価対象として決定する。

【0074】

サーバ３０は、上記第１例～第６例のうち２以上を組み合わせることもできる。
また、ステップＳ１３０に先んじて、クライアント装置１０のユーザは、クライアント装置１０を介して、評価対象、エンジニア、またはチームの指定に関するユーザ指示を行うことができる。そして、クライアント装置１０は、ユーザ指示に基づく評価要求を生成し、サーバ３０へ送信してもよい。

【0075】

なお、評価要求と同時に、または評価要求と前後して、サーバ３０は、ユーザ認証を行ってもよい。
具体的には、クライアント装置１０は、ユーザ認証に用いられる情報を取得し、サーバ３０へ送信する。サーバ３０は、かかる情報に基づいてクライアント装置１０の操作者が登録済みのユーザであるか否かを確認する。サーバ３０は、ユーザ認証が成功した場合に、以後の処理を実行する。ただし、評価要求と同時もしくは評価要求よりも後にユーザ認証が行われ、かつ評価対象の評価結果を閲覧する権限がユーザに割り当てられていない場合に、サーバ３０は評価要求を拒否する。

【0076】

ユーザ認証に用いられる情報は、ユーザを特定可能な情報（例えばユーザＩＤ）と、クライアント装置１０の操作者が当該ユーザ本人であることを証明するために当該操作者によって提供された情報（例7えば、パスワード、または生体情報、など）とを含み得る。

【0077】

ステップＳ１３０の後に、サーバ３０は、情報の取得（Ｓ１３１）を実行する。
具体的には、サーバ３０は、ステップＳ１３０において決定した評価対象（レビュー依頼）に応じて、例えば開発活動データベース（図６）を参照し、評価対象に関する情報を抽出する。抽出する情報は、評価対象であるレビュー依頼そのものであってもよいし、当該レビュー依頼に関連する付加情報であってもよいし、両者の組み合わせであってもよい。なお、サーバ３０は、開発活動データベースから直接的に情報を取得するに留まらず、当該情報を必要に応じて加工または分析してもよい。

【0078】

情報の取得（Ｓ１３１）の第１例として、サーバ３０は、ボリューム情報を取得する。ボリューム情報は、レビュー依頼（評価対象）のボリュームに関する情報である。ボリューム情報は、例えば以下の少なくとも１つに関する情報を含むことができる。
・レビュー依頼の変更行数
・レビュー依頼の変更ファイル数

【0079】

レビュー依頼の変更行数が多いほど、当該レビュー依頼による障害の発生リスク（後述）または当該レビュー依頼に関する工程間のリードタイム（後述）は大きくなる傾向にあると考えられる。レビュー依頼の変更ファイル数が多いほど、当該レビュー依頼による障害の発生リスクまたは当該レビュー依頼に関する工程間のリードタイムは大きくなる傾向にあると考えられる。

【0080】

情報の取得（Ｓ１３１）の第２例として、サーバ３０は、文字情報を取得する。文字情報は、レビュー依頼（評価対象）または当該レビュー依頼の付加情報を構成する文字に関する情報である。文字情報は、例えば以下の少なくとも１つに関する情報を含むことができる。
・レビュー依頼の変更ファイルの拡張子
・変更ファイル名に出現する文字列
・変更ファイルに出現する文字列
・変更ファイルから抽出された特徴ベクトル

【0081】

レビュー依頼の変更ファイル名の拡張子の情報は、当該変更ファイルの記述に使用されているプログラミング言語またはスクリプト言語を特定したり、当該変更ファイルがプログラムの変更に該当するかを判別したりする材料となり得る。つまり、レビュー依頼の変更ファイル名の拡張子の情報から、当該レビュー依頼の種類を判定することが可能である。レビュー依頼の種類と、障害の発生リスクまたはリードタイムとの間には相関があると考えられる。第１例として、サーバ３０は、拡張子が、「cpp」、「rb」、または「py」である場合に、レビュー依頼はプログラムの変更と判定可能である。第２例として、サーバ３０は、拡張子が、「yml」、「json」、または「xml」である場合に、レビュー依頼はおそらく設定ファイルの変更であると判定可能である。第３例として、サーバ３０は、拡張子が「lock」である場合に、レビュー依頼は依存ライブラリの変更と判定可能である。

【0082】

レビュー依頼の変更フアイル名に出現する文字列の情報も、当該レビュー依頼の種類を判定する材料となり得る。第１例として、サーバ３０は、変更ファイル名に「Pipfile」、「pyproject」、または「pom」の文字列が出現する場合に、レビュー依頼は依存ライブラリの変更と判定可能である。例えば、ユーザがPipfileを変更する場合、ユーザが手動で更新したPipfileに加えて、依存管理ツールによってPipfile.lockが自動更新されることになる。PiPefile.lockは、数百～数千行の規模の更新になるものの、自動生成された結果でありレビューで確認する必要がないため、手動で更新した同程度の規模のコードと比べて、障害の発生リスクは低い、と判定可能である。第２例として、サーバ３０は、変更ファイル名に「Client」、または「network」の文字列が出現する場合に、レビュー依頼は外部と通信する要素に関する変更である、つまりテストが難しくバグが生じやすい可能性がある、と判定可能である。第３例として、サーバ３０は、変更ファイル名に「util」の文字列が出現する場合に、レビュー依頼は様々な場所から参照される要素に関する変更である、つまり変更の影響範囲が大きくバグが生じやすい可能性がある、と判定可能である。

【0083】

レビュー依頼の変更ファイルに出現する文字列の情報は、当該変更ファイルによるバグの兆候を判定する材料となり得る。第１例として、サーバ３０は、変更ファイル内の「def」、または「func」の出現回数が少ない（例えば、ファイルの行数に応じた閾値を下回る）場合に、肥大化した関数がバグの温床となる可能性があると判定可能である。第２例として、サーバ３０は、変更ファイル内の変数名が「tmp」、「t」、「a」、または「b」である場合に、わかりにくい変数名がバグの温床となる可能性があると判定可能である。

【0084】

レビュー依頼の変更ファイルから特徴ベクトルを抽出する場合、サーバ３０は、例えばＢＥＲＴ（Bidirectional Encoder Representations from Transformers）などのニューラルネットワークを利用できる。

【0085】

情報の取得（Ｓ１３１）の第３例として、サーバ３０は、時間情報を取得する。時間情報は、レビュー依頼（評価対象）に関する工程が行われた時刻、または当該レビュー依頼に関する工程間のリードタイムに関する情報である。時間情報は、例えば以下の少なくとも１つに関する情報を含むことができる。
・レビュー依頼の作成からレビューがなされるまでの所要時間の実測値もしくは予測値
・レビュー依頼に対応するファイルをローカルリポジトリに記録（コミット）した時刻
・レビュー依頼の作成時刻
・レビュー依頼がドラフト状態からオープン状態に遷移するまでの所要時間の実測値もしくは予測値
・レビュー依頼がオープン状態に遷移してからレビュアーがアサインされるまでの所要時間の実測値もしくは予測値
ここで、上記予測値は、過去に計測された複数の実測値の代表値（例えば、平均値、中央値、最頻値、最大値、最小値、第一四分位数、または第三四分位数など）であってもよい。

【0086】

レビュー依頼に対応するファイルのコミット時刻またはレビュー依頼の作成時刻は、その時点でのエンジニアのコンディションを判定する材料となり得る。例えば、サーバ３０は、深夜帯にコミットまたは作成されたレビュー依頼は、他の時間帯にコミットまたは作成されたレビュー依頼に比べて、ケアレスミスによる不備が含まれている可能性が高く、障害の発生リスクが高い、またはリードタイムが長いと判定し得る。

【0087】

レビュー依頼がドラフト状態からオープン状態に遷移するまでの所要時間は、仕様の設計が整理されているか、または小さいパッチサイズで開発できているかを判定する材料となり得る。サーバ３０は、かかる所要時間の実測値または予測値が短いほど、障害の発生リスクが低い、またはリードタイムが短いと評価し得る。

【0088】

レビュー依頼がオープン状態に遷移してからレビュアーがアサインされるまでの所要時間は、レビュアーアサインが適切に仕組み化されているかを判定する材料となり得る。サーバ３０は、かかる所要時間の実測値または予測値が短いほど、障害の発生リスクが低い、またはリードタイムが短いと評価し得る。

【0089】

上記所要時間の予測値は、例えば各工程を担当する作業者の情報に基づいて予測されてもよいし、他の情報に基づいて学習済みモデル（例えば後述するレビュー依頼評価モデルの第２例）により予測されてもよい。

【0090】

情報の取得（Ｓ１３１）の第４例として、サーバ３０は、作業者情報を取得する。作業者情報は、レビュー依頼（評価対象）に関する各工程の作業者に関する情報である。作業者情報は、例えば以下の少なくとも１つに関する情報を含むことができる。
・レビュー依頼を行ったエンジニア
・レビュー依頼にアサインされたレビュアー

【0091】

なお、サーバ３０は、開発活動データベースから情報を抽出する前に、外部システム５０から開発活動情報を取得し、当該データベースを外部システム５０が保有する最新の情報を反映するように更新してもよい。

【0092】

ステップＳ１３１の後に、サーバ３０は、モデル入力情報の生成（Ｓ１３２）を実行する。
具体的には、サーバ３０は、ステップＳ１３１において取得した評価対象に関する情報に基づいて、モデル入力情報を生成する。一例として、サーバ３０は、ステップＳ１３１において取得した情報を特徴量化し、各特徴量を配列したベクトルをモデル入力情報として生成してもよい。

【0093】

ステップＳ１３２の後に、サーバ３０は、レビュー依頼の評価（Ｓ１３３）を実行する。
具体的には、サーバ３０は、ステップＳ１３２において生成したモデル入力情報に、レビュー依頼評価モデルを適用する。これにより、サーバ３０は、ステップＳ１３０において評価対象として決定したレビュー依頼を評価する。

【0094】

レビュー依頼評価モデルの第１例は、レビュー依頼（評価対象）による障害の発生リスクについて推論を行う。ここで、障害の発生リスクは、例えば変更障害率であってよい。変更障害率とは、変更に伴って発生した障害の割合を意味する。一例として、ＧｉｔＨｕｂにおける変更障害率は、メインブランチへマージしたプルリクエスト数に対する、障害を意味するタグ付けがなされたブランチからメインブランチへマージしたプルリクエスト数の割合として表現できる。障害を意味するタグ付けがなされたブランチは、例えば、修正を意味する文字列（hotfix）または変更を元に戻すことを意味する文字列（revert）を含む（大文字小文字問わず）ブランチである。

【0095】

レビュー依頼評価モデルの第１例は、教師あり学習により構築可能である。教師あり学習に用いられる学習データは、学習用のモデル入力情報と、対応する正解情報とを含む。学習用のモデル入力情報は、過去に行われたレビュー依頼に基づいて、ステップＳ１３２における（運用時の）モデル入力情報と同様の形式となるように生成される。正解情報は、該当レビュー依頼によって障害が実際に発生したか否かを示す。かかる学習データを大量に学習することで、与えられたモデル入力情報に対応するレビュー依頼に内在する障害の発生リスクを統計的に予測する機能を備えた学習済みモデルを作成することができる。

【0096】

レビュー依頼評価モデルの第２例は、レビュー依頼（評価対象）に関する工程間のリードタイムについて推論を行う。推論の対象となるリードタイムは、例えば以下の少なくとも１つを含むことができる。
・レビュアーアサインから最初のレビューまでの所要時間
・レビューからレビュー依頼に対応するファイルのプロジェクト本体への統合が承認（つまり、ＧｉｔＨｕｂにおけるマージ）されるまでの所要時間
・レビュー依頼（評価対象）がオープン状態に遷移してから当該レビュー依頼に対応するファイルのプロジェクト本体への統合が承認（マージ）されるまでの所要時間

【0097】

レビュー依頼評価モデルの第２例は、教師あり学習により構築可能である。教師あり学習に用いられる学習データは、学習用のモデル入力情報と、対応する正解情報とを含む。学習用のモデル入力情報は、過去に行われたレビュー依頼に基づいて、ステップＳ１３２における（運用時の）モデル入力情報と同様の形式となるように生成される。正解情報は、該当レビュー依頼に関する工程間のリードタイムの実測値を示す。かかる学習データを大量に学習することで、与えられたモデル入力情報に対応するレビュー依頼に関する工程間のリードタイムを統計的に予測する機能を備えた学習済みモデルを作成することができる。

【0098】

レビュー依頼評価モデルは、様々な単位毎に構築可能である。具体的には、レビュー依頼評価モデルは、個々のエンジニア単位、複数のエンジニアを含むチーム単位、複数のチームを含む組織単位、または複数の組織を含む業界単位毎に構築され得る。少人数単位でレビュー依頼評価モデルを構築することは、学習データの収集には不利である一方で、フィット度合いを高めやすいという利点がある。また、レビュー依頼評価モデルは、プログラミング言語またはマークアップ言語毎に構築され得る。

【0099】

ステップＳ１３３の後、サーバ３０は、評価結果の出力（Ｓ１３４）を実行する。
具体的には、サーバ３０は、ステップＳ１３３におけるレビュー依頼の評価結果をクライアント装置１０のユーザに提示するための情報を生成する。サーバ３０は、生成した情報をクライアント装置１０へ送信する。ここで、生成される情報は、例えば、クライアント装置１０がディスプレイ２１に表示させる画面を生成するための情報であってよい。

【0100】

ステップＳ１３４の後に、クライアント装置１０は、情報提示（Ｓ１１０）を実行する。
具体的には、クライアント装置１０は、ステップＳ１３４において送信された情報を受信し、当該情報に基づく画面をディスプレイ２１に表示させる。これにより、ユーザは、レビュー依頼（評価対象）に対する評価結果（例えば、レビュー依頼による障害の発生リスク、またはレビュー依頼に関する工程間のリードタイム）を確認することができる。

【0101】

一例として、クライアント装置１０は、図８に示す画面をディスプレイ２１に表示させる。図８の画面は、オブジェクトＪ２０を含む。

【0102】

オブジェクトＪ２０は、レビュー依頼の情報を表示する。レビュー依頼の情報は、レビュー依頼の評価結果に関する情報を含む。図８の例では、レビュー依頼の評価結果は、レビュー依頼による障害の発生リスクの評価結果と、レビュー依頼に関する工程間のリードタイムの評価結果とを含む。図８の例では、評価結果は、アイコンの表示数で示される３段階評価であるが、これに限られずスコアまたは文章により表現されてよい。ユーザは、これらの評価結果を確認することで、障害が発生しないように入念なレビューを行ったり、リードタイムが長くならないように早めにレビューを開始したり、レビュー依頼を行ったエンジニアにフィードバックを行ったりするなどの対処がしやすくなる。なお、図８には示されていないが、例えば、発生リスクまたはリードタイムの評価結果が閾値を下回る場合に、サーバ３０は、評価対象に関する情報のうち、発生リスクまたはリードタイムの評価に与えた悪影響が大きいと推定される要素を特定し、当該要素を示す情報を、クライアント装置１０を介してユーザに提示してもよい。

【0103】

オブジェクトＪ２０に表示されるレビュー依頼の情報は、さらに、以下の少なくとも１つを含むことができる。
・レビュー依頼のタイトル
・レビュー依頼の作成者
・レビュー依頼の状態
・レギュ－依頼の作成日時

【0104】

また、図８の画面に表示される情報は、ユーザ指示に応じてソート、またはフィルタリングされてよい。例えば、ユーザは、障害の発生リスクが高い順にレビュー依頼をソートしたり、特定の作成者によるレビュー依頼のみを表示したりするよう、クライアント装置１０を介して指示できる。

【0105】

（５）小括
以上説明したように、サーバ３０は、エンジニアがイシュー管理サービス（つまり、外部システム５０）を利用することで当該イシュー管理サービスに保存された情報から、エンジニアがイシュー管理サービスのローカルリポジトリに追加または変更したファイルのレビューを依頼するレビュー依頼の内容および当該レビュー依頼に関連する付加情報を取得する。サーバ３０は、取得したレビュー依頼の内容および当該レビュー依頼に関連する付加情報に基づくモデル入力情報に、レビュー依頼の評価のための推論を行う学習済みモデル（つまり、レビュー依頼評価モデル）を適用することで、レビュー依頼を評価し、当該レビュー依頼の評価結果を出力する。これにより、レビュー依頼の質を効率的かつ客観的に評価することが可能となり、ユーザは評価結果を自身の業務に活用することができる。この結果、レビュー依頼の質の改善が促されたり、質の低いレビュー依頼が後工程の着手前に検知されたりするので、チーム全体での開発の効率の向上（例えばリードタイム短縮または障害減少による開発スピードの向上）および質の向上（例えばバグの少ないソフトウェア）が期待できる。

【0106】

モデル入力情報は、レビュー依頼に関するボリューム情報を含んでもよい。これにより、レビュー依頼のボリュームとレビュー依頼の質との関係に基づいて、評価対象であるレビュー依頼の質を効率的かつ客観的に評価することができる。

【0107】

ボリューム情報は、レビュー依頼の変更行数、または変更ファイル数の少なくとも１つに関するものであってよい。これにより、レビュー依頼の変更行数、または変更ファイル数の少なくとも１つとレビュー依頼の質との関係に基づいて、評価対象であるレビュー依頼の質を効率的かつ客観的に評価することができる。

【0108】

モデル入力情報は、レビュー依頼に関する文字情報を含んでもよい。これにより、レビュー依頼に関する文字（列）とレビュー依頼の質との関係に基づいて、評価対象であるレビュー依頼の質を効率的かつ客観的に評価することができる。

【0109】

文字情報は、レビュー依頼の変更ファイルの拡張子に関する情報、変更ファイル名に出現する文字列に関する情報、変更ファイルに出現する文字列に関する情報、または変更ファイルから抽出された特徴ベクトルの少なくとも１つに関するものであってよい。これにより、ここで例示した各文字情報とレビュー依頼の質との関係に基づいて、評価対象であるレビュー依頼の質を効率的かつ客観的に評価することができる。

【0110】

モデル入力情報は、レビュー依頼に関する時間情報を含んでもよい。これにより、レビュー依頼に関する時間とレビュー依頼の質との関係に基づいて、評価対象であるレビュー依頼の質を効率的かつ客観的に評価することができる。

【0111】

時間情報は、レビュー依頼の作成からレビューがなされるまでの所要時間の実測値もしくは予測値、レビュー依頼に対応するファイルをローカルリポジトリに記録した時刻、レビュー依頼の作成時刻、レビュー依頼がドラフト状態からオープン状態に遷移するまでの所要時間の実測値もしくは予測値、またはレビュー依頼がオープン状態に遷移してからレビュアーがアサインされるまでの所要時間の実測値もしくは予測値の少なくとも１つに関するものであってよい。これにより、ここで例示した各時間情報とレビュー依頼の質との関係に基づいて、評価対象であるレビュー依頼の質を効率的かつ客観的に評価することができる。

【0112】

モデル入力情報は、レビュー依頼に関する作業者情報を含んでもよい。これにより、レビュー依頼に関する作業者とレビュー依頼の質との関係に基づいて、評価対象であるレビュー依頼の質を効率的かつ客観的に評価することができる。

【0113】

作業者情報は、評価対象であるレビュー依頼を行ったエンジニア、または当該レビュー依頼にアサインされたレビュアーの少なくとも１つに関するものであってよい。これにより、ここで例示した各作業者情報とレビュー依頼の質との関係に基づいて、評価対象であるレビュー依頼の質を効率的かつ客観的に評価することができる。

【0114】

サーバ３０は、モデル入力情報に、レビュー依頼による障害の発生リスクについて推論を行う学習済みモデルを適用することで、レビュー依頼を評価してもよい。これにより、評価対象であるレビュー依頼による障害の発生リスクを効率的かつ客観的に評価することができる。

【0115】

サーバ３０は、モデル入力情報に、レビュー依頼に関するリードタイムについて推論を行う学習済みモデルを適用することで、レビュー依頼を評価してもよい。これにより、評価対象であるレビュー依頼に関するリードタイムを効率的かつ客観的に評価することができる。

【0116】

リードタイムは、レビュアーアサインから最初のレビューまでの所要時間、レビューからレビュー依頼に対応するファイルのプロジェクト本体への統合が承認されるまでの所要時間、またはレビュー依頼がオープン状態に遷移してから当該レビュー依頼に対応するファイルのプロジェクト本体への統合が承認されるまでの所要時間の少なくとも１つを含んでもよい。これにより、ここで例示した各リードタイムを効率的かつ客観的に評価することができる。

【0117】

学習済みモデルは、エンジニア単位、複数のエンジニアを含むチーム単位、複数のチームを含む組織単位、または複数の組織を含む業界単位毎に構築されてもよい。これにより、学習済みモデルの構築の自由度を高めることができる。

【0118】

学習済みモデルは、プログラミング言語またはマークアップ言語毎に構築されてもよい。これにより、特定のプログラミング言語またはマークアップ言語に関するレビュー依頼について得られた学習データを用いて学習済みモデルが構築されるので、評価の精度を高めることができる。

【0119】

（６）その他の変形例
記憶装置１１は、ネットワークＮＷを介して、クライアント装置１０と接続されてもよい。ディスプレイ２１は、クライアント装置１０と一体化されてもよい。記憶装置３１は、ネットワークＮＷを介して、サーバ３０と接続されてもよい。

【0120】

上記の情報処理の各ステップは、クライアント装置１０及びサーバ３０の何れでも実行可能である。例えば、サーバ３０が実行するとして説明された処理を、クライアント装置１０が実行してもよい。

【0121】

上記説明では、サーバ３０は、評価結果の良し悪しに関わらず、評価結果の出力（Ｓ１３４）を行う例を示した。しかしながら、サーバ３０は、評価結果について所定の条件が成立する場合に、例えばユーザ宛に通知を行ってもよい。所定の条件は、例えば下限を下回る評価結果、または上限を上回る評価が得られたこと、であってよい。下限または上限は、ユーザによって設定されてもよいし、例えば評価対象であるレビュー依頼を行ったエンジニアまたは当該エンジニアと同一チームのエンジニアが過去に行ったレビュー依頼に対する評価結果に基づいて設定されてもよい。通知は、アプリ画面、またはウェブサイト画面上で行われてもよいし、メールまたはその他のメッセージ（例えば、ＳＮＳ（Social Networking Service）メッセージ、ＳＭＳ（Short Message Service）メッセージ、チャットツールのメッセージ、など）を用いて行われてもよい。通知は、所定条件が成立したことを伝える情報を含んでいてもよいし、評価結果の情報を含んでいてもよい。これにより、ユーザは、評価結果を能動的に頻繁に確認せずとも、上記所定の条件の成立時に評価結果を速やかに把握することができる。

【0122】

サーバ３０は、モデル入力情報に含まれる要素がレビュー依頼の評価結果に及ぼした影響を分析し、分析結果を出力（例えば分析結果に基づく情報をクライアント装置１０へ送信）してもよい。これにより、肯定的な評価に寄与した要因、または否定的な評価に寄与した要因をユーザ（例えば評価対象であるレビュー依頼を行ったエンジニア）に認識させ、質の良いレビュー依頼の再現性の向上、または質の悪いレビュー依頼の改善による成長を促すことができる。

【0123】

サーバ３０は、同一のレビュー依頼を複数の時点（例えば、状態が変わる度）で評価し、レビュー依頼の複数の時点それぞれにおける評価結果を出力してもよい。これにより、例えばモデル入力情報を生成するために参照可能な情報が増えた段階で評価結果を更新できるので、ユーザにより精度の高い評価結果を提供することができる。

【0124】

また、上記説明では、情報処理において各ステップを特定の順序で実行する例を示したが、各ステップの実行順序は、依存関係がない限りは説明した例に制限されない。

【0125】

（７）付記
実施形態および変形例で説明した事項を、以下に付記する。

【0126】

（付記１）
コンピュータ（３０）を、
エンジニアがイシュー管理サービスを利用することで当該イシュー管理サービスに保存された情報から、第１エンジニアがイシュー管理サービスのローカルリポジトリに追加または変更したファイルのレビューを依頼するレビュー依頼の内容および当該レビュー依頼に関連する付加情報を取得する手段（Ｓ１３１）、
レビュー依頼の内容および当該レビュー依頼に関連する付加情報に基づくモデル入力情報に、レビュー依頼の評価のための推論を行う学習済みモデルを適用することで、レビュー依頼を評価する手段（Ｓ１３３）、
レビュー依頼の評価結果を出力する手段（Ｓ１３４）、
として機能させるプログラム。

【0127】

（付記２）
モデル入力情報は、レビュー依頼に関するボリューム情報を含む、
付記１に記載のプログラム。

【0128】

（付記３）
ボリューム情報は、レビュー依頼の変更行数、または変更ファイル数の少なくとも１つに関する、
付記２に記載のプログラム。

【0129】

（付記４）
モデル入力情報は、レビュー依頼に関する文字情報を含む、
付記１に記載のプログラム。

【0130】

（付記５）
文字情報は、レビュー依頼の変更ファイルの拡張子に関する情報、変更ファイル名に出現する文字列に関する情報、変更ファイルに出現する文字列に関する情報、または変更ファイルから抽出された特徴ベクトルの少なくとも１つに関する、
付記４に記載のプログラム。

【0131】

（付記６）
モデル入力情報は、レビュー依頼に関する時間情報を含む、
付記１に記載のプログラム。

【0132】

（付記７）
時間情報は、レビュー依頼の作成からレビューがなされるまでの所要時間の実測値もしくは予測値、レビュー依頼に対応するファイルをローカルリポジトリに記録した時刻、レビュー依頼の作成時刻、レビュー依頼がドラフト状態からオープン状態に遷移するまでの所要時間の実測値もしくは予測値、またはレビュー依頼がオープン状態に遷移してからレビュアーがアサインされるまでの所要時間の実測値もしくは予測値の少なくとも１つに関する、
付記６に記載のプログラム。

【0133】

（付記８）
モデル入力情報は、レビュー依頼に関する作業者情報を含む、
付記１に記載のプログラム。

【0134】

（付記９）
作業者情報は、第１エンジニア、またはレビュー依頼にアサインされたレビュアーの少なくとも１つに関する、
付記８に記載のプログラム。

【0135】

（付記１０）
レビュー依頼を評価する手段は、モデル入力情報に、レビュー依頼による障害の発生リスクについて推論を行う学習済みモデルを適用することで、レビュー依頼を評価する、
付記１に記載のプログラム。

【0136】

（付記１１）
レビュー依頼を評価する手段は、モデル入力情報に、レビュー依頼に関するリードタイムについて推論を行う学習済みモデルを適用することで、レビュー依頼を評価する、
付記１に記載のプログラム。

【0137】

（付記１２）
リードタイムは、レビュアーアサインから最初のレビューまでの所要時間、レビューからレビュー依頼に対応するファイルのプロジェクト本体への統合が承認されるまでの所要時間、またはレビュー依頼がオープン状態に遷移してから当該レビュー依頼に対応するファイルのプロジェクト本体への統合が承認されるまでの所要時間の少なくとも１つを含む、
付記１１に記載のプログラム。

【0138】

（付記１３）
学習済みモデルは、エンジニア単位、複数のエンジニアを含むチーム単位、複数のチームを含む組織単位、または複数の組織を含む業界単位毎に構築されている、
付記１に記載のプログラム。

【0139】

（付記１４）
学習済みモデルは、プログラミング言語またはマークアップ言語毎に構築されている、
付記１に記載のプログラム。

【0140】

（付記１５）
コンピュータを、
モデル入力情報に含まれる要素がレビュー依頼の評価結果に及ぼした影響を分析する手段、
影響の分析結果を出力する手段、
として機能させる、付記１に記載のプログラム。

【0141】

（付記１６）
評価する手段は、レビュー依頼を複数の時点において評価し、
出力する手段は、レビュー依頼の複数の時点それぞれにおける評価結果を出力する、
付記１に記載のプログラム。

【0142】

（付記１７）
コンピュータ（３０）が、
エンジニアがイシュー管理サービスを利用することで当該イシュー管理サービスに保存された情報から、第１エンジニアがイシュー管理サービスのローカルリポジトリに追加または変更したファイルのレビューを依頼するレビュー依頼の内容および当該レビュー依頼に関連する付加情報を取得するステップ（Ｓ１３１）と、
レビュー依頼の内容および当該レビュー依頼に関連する付加情報に基づくモデル入力情報に、レビュー依頼の評価のための推論を行う学習済みモデルを適用することで、レビュー依頼を評価するステップ（Ｓ１３３）と、
レビュー依頼の評価結果を出力するステップ（Ｓ１３４）と
を実行する方法。

【0143】

（付記１８）
エンジニアがイシュー管理サービスを利用することで当該イシュー管理サービスに保存された情報から、第１エンジニアがイシュー管理サービスのローカルリポジトリに追加または変更したファイルのレビューを依頼するレビュー依頼の内容および当該レビュー依頼に関連する付加情報を取得する手段（Ｓ１３１）と、
レビュー依頼の内容および当該レビュー依頼に関連する付加情報に基づくモデル入力情報に、レビュー依頼の評価のための推論を行う学習済みモデルを適用することで、レビュー依頼を評価する手段（Ｓ１３３）と、
レビュー依頼の評価結果を出力する手段（Ｓ１３４）と
を具備する情報処理装置（３０）。

【0144】

（付記１９）
第１情報処理装置（３０）と第２情報処理装置（１０）とを具備するシステム（１）であって、
第１情報処理装置は、
エンジニアがイシュー管理サービスを利用することで当該イシュー管理サービスに保存された情報から、第１エンジニアがイシュー管理サービスのローカルリポジトリに追加または変更したファイルのレビューを依頼するレビュー依頼の内容および当該レビュー依頼に関連する付加情報を取得する手段（Ｓ１３１）と、
レビュー依頼の内容および当該レビュー依頼に関連する付加情報に基づくモデル入力情報に、レビュー依頼の評価のための推論を行う学習済みモデルを適用することで、レビュー依頼を評価する手段（Ｓ１３３）と、
レビュー依頼の評価結果を第２情報処理装置へ出力する手段（Ｓ１３４）と
を備える、
システム。

【0145】

以上、本発明の実施形態について詳細に説明したが、本発明の範囲は上記の実施形態に限定されない。また、上記の実施形態は、本発明の主旨を逸脱しない範囲において、種々の改良や変更が可能である。また、上記の実施形態及び変形例は、組合せ可能である。

【符号の説明】

【0146】

１ ：情報処理システム
１０ ：クライアント装置
１１ ：記憶装置
１２ ：プロセッサ
１３ ：入出力インタフェース
１４ ：通信インタフェース
２１ ：ディスプレイ
３０ ：サーバ
３１ ：記憶装置
３２ ：プロセッサ
３３ ：入出力インタフェース
３４ ：通信インタフェース
５０ ：外部システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】