特開 2022-178776 適用可否判定方法およびプログラム

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

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

(11)【公開番号】P2022178776

(43)【公開日】2022-12-02

(54)【発明の名称】適用可否判定方法およびプログラム

(51)【国際特許分類】

   G06F 8/70 20180101AFI20221125BHJP

【ＦＩ】

G06F8/70

【審査請求】未請求

【請求項の数】3

【出願形態】ＯＬ

(21)【出願番号】P 2021085810

(22)【出願日】2021-05-21

(71)【出願人】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】110002918

【氏名又は名称】弁理士法人扶桑国際特許事務所

(72)【発明者】

【氏名】前田 翔

(72)【発明者】

【氏名】原田 将治

(72)【発明者】

【氏名】倉木 健介

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

5B376

【Ｆターム（参考）】

5B376BA05

5B376BA18

5B376CA32

5B376DA06

5B376DA11

(57)【要約】

【課題】開発プログラムに信頼度の高い修正ファイルを適用する。
【解決手段】会話データの解析により検出した開発担当者と有識者／レビュア間のコミュニケーションの有無およびマージ判定結果（適用判定結果）が開発責任者に提示される。画面ｇ１１は、参加者をノードで表し、開発担当者と、開発担当者が会話した参加者とのノード間を枝で結んでグラフ化したものである。画面ｇ１２は、会話有無テーブルＴ０とマージ判定結果Ｍ０を示している。会話有無テーブルＴ０は、username、役割および会話有無の項目を有する。マージ判定結果Ｍ０は、マージOK／NGを示す。会話有無テーブルＴ０からファイル修正を行ったsato.hanako（開発担当者）は、yamada.taro（有識者）、yoshida.jiro（有識者）およびsaito.goro（レビュア）と会話していることが示されるので、修正ファイルの開発プログラムへのマージ判定結果は、マージOKと表示される。
【選択図】図１７

【特許請求の範囲】

【請求項1】

コンピュータが、
プログラムの修正が行われた場合、前記プログラムの修正履歴情報にもとづいて、前記プログラムの修正経験がある有識者を特定し、
コミュニケーションサービスシステムに記録されている会話情報にもとづいて、前記プログラムの修正を行った開発担当者と、前記有識者との間でのコミュニケーションの有無を判定し、
前記判定の結果にもとづいて、修正された前記プログラムの適用可否を判定する、
適用可否判定方法。

【請求項2】

前記コンピュータは、
前記有識者として、修正された前記プログラムを最初に作成した人物、または前記プログラムの修正に多く関わった人物を前記コミュニケーションサービスシステムに対するコミット回数にもとづいて特定し、
前記開発担当者と、前記有識者との前記コミュニケーションが取れていると検出した場合に、修正プログラムのソフトウェア開発中のプログラムへの適用を可とする、
請求項１記載の適用可否判定方法。

【請求項3】

コンピュータに、
プログラムの修正が行われた場合、前記プログラムの修正履歴情報にもとづいて、前記プログラムの修正経験がある有識者を特定し、
コミュニケーションサービスシステムに記録されている会話情報にもとづいて、前記プログラムの修正を行った開発担当者と、前記有識者との間でのコミュニケーションの有無を判定し、
前記判定の結果にもとづいて、修正された前記プログラムの適用可否を判定する、
処理を実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、適用可否判定方法およびプログラムに関する。

【背景技術】

【0002】

ソフトウェアの開発においては、開発プログラムに対して、機能の修正が行われたソースコード等のファイルを繰り返し適用させながら開発が進められる。
関連技術として、例えば、レビューでコメントされた指摘者を示す記録ファイルにもとづいて、有効な指摘をコメントしたか判定する技術が提案されている。また、レビューに参加したレビュアのスキルレベルと人数を評価し、評価結果を電子メールで送信する技術が提案されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１９－１３３５５８号公報

【特許文献2】特開２０１３－０３３３９１号公報

【発明の概要】

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

【0004】

しかし、上述の背景技術は、コメントをした人が修正されたプログラムに精通しているとは限らない。もし修正されたプログラムに精通していない人が、有効と思われる指摘を行った場合、またはスキルレベルは高いが、修正されたプログラムに精通していない人が指摘を行った場合には、適正なコメントができていないことが考えられる。

【0005】

１つの側面では、本発明は、修正した人が修正されたプログラムに精通している人とコミュニケーションを取ったか否かを判定することで、当該プログラムに対する信頼度の高い修正ファイルの適用を可能にした適用可否判定方法およびプログラムを提供することを目的とする。

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

【0006】

上記課題を解決するために、適用可否判定方法が提供される。適用可否判定方法は、コンピュータが、プログラムの修正が行われた場合、プログラムの修正履歴情報にもとづいて、プログラムの修正経験がある有識者を特定し、コミュニケーションサービスシステムに記録されている会話情報にもとづいて、プログラムの修正を行った開発担当者と、有識者との間でのコミュニケーションの有無を判定し、判定の結果にもとづいて、修正されたプログラムの適用可否を判定する。

【0007】

また、上記課題を解決するために、コンピュータに上記適用可否判定方法と同様の処理を実行させるプログラムが提供される。

【発明の効果】

【0008】

１側面によれば、開発プログラムへの信頼度の高い修正ファイルの適用が可能になる。

【図面の簡単な説明】

【0009】

【図1】第１の実施の形態の情報処理装置の一例を説明するための図である。

【図2】第２の実施の形態の情報処理装置の機能ブロックの一例を示す図である。

【図3】情報処理装置のハードウェア構成の一例を示す図である。

【図4】GitHubの動作の一例を説明するための図である。

【図5】会話情報の収集動作の一例を示す図である。

【図6】会話データの抽出動作の一例を示す図である。

【図7】チャットアプリテーブルの一例を示す図である。

【図8】プルリクエスト会話テーブルの一例を示す図である。

【図9】masterブランチのコミット情報からのデータ抽出の一例を示す図である。

【図10】開発ブランチのコミット情報からのデータ抽出の一例を示す図である。

【図11】masterブランチ更新テーブルの一例を示す図である。

【図12】開発ブランチ更新テーブルの一例を示す図である。

【図13】プルリクエスト情報からのデータ抽出の一例を示す図である。

【図14】プルリクエスト関係者テーブルの一例を示す図である。

【図15】チャットアプリテーブルの一例を示す図である。

【図16】プルリクエスト会話テーブルの一例を示す図である。

【図17】会話有無の提示画面の一例を示す図である。

【図18】情報処理装置の動作の一例を示すフローチャートである。

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

【0010】

以下、本実施の形態について図面を参照して説明する。
［第１の実施の形態］
図１は第１の実施の形態の情報処理装置の一例を説明するための図である。情報処理装置１は、制御部１ａおよび記憶部１ｂを備える。制御部１ａは、例えば、情報処理装置１が備える図示しないプロセッサが、所定のプログラムを実行することによって実現する。記憶部１ｂは、情報処理装置１の主記憶装置として使用され、例えば、ソフトウェア開発の履歴情報や会話情報等を記憶する。

【0011】

制御部１ａは、プログラムの修正が行われた場合、プログラムの修正履歴情報にもとづいて、プログラムの修正経験がある有識者を特定する。また、制御部１ａは、コミュニケーションサービスシステムに記録されている会話情報にもとづいて、プログラムの修正を行った開発担当者と、有識者との間でのコミュニケーションの有無を判定し、判定の結果にもとづいて、修正されたプログラムの適用可否を判定する。

【0012】

図１の例を用いて動作の流れについて説明する。以下、プログラムの修正をファイルの修正を行うものとして説明する。
〔ステップＳ１〕ソフトウェア開発において、開発担当者によるプログラムの修正としてファイルの修正（新たな機能追加やバグ修正等）が行われる。なお、開発担当者は、例えば、ファイルに対して機能追加等の修正を行った人物である。

【0013】

〔ステップＳ２〕制御部１ａは、ソフトウェア開発の修正履歴情報２ａにもとづいて、ファイルの修正に関しての有識者を特定する。修正履歴情報２ａは、例えば、ソフトウェア開発プラットフォームからリリースされるバージョンごとに開発履歴が管理されている情報である。なお、有識者は、修正が行われたファイルに対して過去に開発や修正を行った前任者が相当する。

【0014】

〔ステップＳ３〕制御部１ａは、コミュニケーションサービスシステム２ｂからファイルの修正が行われた期間における会話情報を抽出する。コミュニケーションサービスシステム２ｂは、例えば、GitHub（登録商標）やMattermost（登録商標）を使用することができる。

【0015】

〔ステップＳ４〕制御部１ａは、会話情報にもとづいて、ファイルの修正を行った開発担当者と、有識者との間でコミュニケーションの有無を検出する。開発担当者と有識者間でコミュニケーション有りと検出した場合、ステップＳ５に処理が進み、コミュニケーション無しと検出した場合、ステップＳ６に処理が進む。

【0016】

〔ステップＳ５〕制御部１ａは、修正箇所が含まれる修正ファイルのソフトウェア開発中のプログラムへの適用を可と判定する。
〔ステップＳ６〕制御部１ａは、修正箇所が含まれる修正ファイルのソフトウェア開発中のプログラムへの適用を不可と判定する。

【0017】

このように情報処理装置１では、ファイルの修正が行われた期間における会話情報にもとづいて、ファイルの修正を行った開発担当者と、有識者との間でコミュニケーションが取れているか否かを検出する。そして、検出結果にもとづいて、修正箇所が含まれる修正ファイルのソフトウェア開発中のプログラムへの適用の可否を判定する。

【0018】

これにより、開発担当者と有識者間でコミュニケーションが取れている場合に修正ファイルを開発プログラムに適用できるので、開発プログラムへの信頼度の高い修正ファイルの適用が可能になる。

【0019】

［第２の実施の形態］
次に第２の実施の形態の情報処理装置について以降詳しく説明する。図２は第２の実施の形態の情報処理装置の機能ブロックの一例を示す図である。情報処理装置１０は、制御部１１および記憶部１２を備える。制御部１１は、会話情報収集部１１ａ、会話データ抽出部１１ｂ、会話データ解析部１１ｃおよび会話有無提示部１１ｄを含む。また、制御部１１には、コミュニケーションサービスシステム２０が接続され、コミュニケーションサービスシステム２０は、コミュニケーションツール２１およびソフトウェア開発プラットフォーム２２を含む。

【0020】

コミュニケーションツール２１は、意思疎通や情報共有等を行う際に利用される会話ツールであり、例えば、Mattermost等のチャットアプリケーションまたはメール等のその他ツールである。ソフトウェア開発プラットフォーム２２は、例えば、GitHub等のコードホスティングサービスである。

【0021】

会話情報収集部１１ａは、コミュニケーションツール２１およびソフトウェア開発プラットフォーム２２の少なくとも一方から会話情報を収集する。会話データ抽出部１１ｂは、収集された会話情報から解析対象となる会話データを抽出する。

【0022】

会話データ解析部１１ｃは、抽出した会話データと、ソフトウェア開発プラットフォーム２２のプルリクエストから取得した履歴情報（開発情報）とにもとづいて、有識者の識別を行い、さらに、開発担当者と有識者間でのコミュニケーションの有無を検出する。

【0023】

会話有無提示部１１ｄは、ソフトウェア開発の開発責任者に対して、例えば、開発担当者と有識者とのコミュニケーションの有無を付与したコミュニケーション有無リストおよび適用可否に関して可視化した情報を提示する。記憶部１２は、収集・取得された会話情報や履歴情報等がテーブル化されたデータ構造を記憶する。

【0024】

＜ハードウェア＞
図３は情報処理装置のハードウェア構成の一例を示す図である。情報処理装置１０は、プロセッサ（コンピュータ）１００によって全体制御されている。プロセッサ１００は、制御部１１の機能を有する。

【0025】

プロセッサ１００には、バス１０３を介して、メモリ１０１、入出力インタフェース１０２およびネットワークインタフェース１０４が接続されている。
プロセッサ１００は、マルチプロセッサであってもよい。プロセッサ１００は、例えば、ＣＰＵ（Central Processing Unit）、ＦＰＧＡ（Field Programmable Gate Array）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、またはＰＬＤ（Programmable Logic Device）である。またプロセッサ１００は、ＣＰＵ、ＦＰＧＡ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。

【0026】

メモリ１０１は、記憶部１２の機能を有し、情報処理装置１０の主記憶装置として使用される。メモリ１０１には、プロセッサ１００に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０１には、プロセッサ１００による処理に要する各種データが格納される。

【0027】

メモリ１０１は、情報処理装置１０の補助記憶装置としても使用され、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。メモリ１０１は、補助記憶装置として、フラッシュメモリやＳＳＤ（Solid State Drive）等の半導体記憶装置やＨＤＤ（Hard Disk Drive）等の磁気記録媒体を含んでもよい。

【0028】

バス１０３に接続されている周辺機器としては、入出力インタフェース１０２およびネットワークインタフェース１０４がある。入出力インタフェース１０２は、キーボードやマウス等の情報入力装置を接続可能であって、情報入力装置から送られてくる信号をプロセッサ１００に送信する。また、入出力インタフェース１０２には、ディスプレイが接続されて、会話有無／適用可否判定結果に関する情報等を表示する。

【0029】

さらに、入出力インタフェース１０２は、周辺機器を接続するための通信インタフェースとしても機能する。例えば、入出力インタフェース１０２は、レーザ光等を利用して、光ディスクに記録されたデータの読み取りを行う光学ドライブ装置を接続することができる。光ディスクには、Ｂｌｕ－ｒａｙ Ｄｉｓｃ（登録商標）、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ－Ｒ（Recordable）／ＲＷ（Rewritable）等がある。

【0030】

また、入出力インタフェース１０２は、メモリ装置やメモリリーダライタを接続することができる。メモリ装置は、入出力インタフェース１０２との通信機能を搭載した記録媒体である。メモリリーダライタは、メモリカードへのデータの書き込み、またはメモリカードからのデータの読み出しを行う装置である。メモリカードは、カード型の記録媒体である。

【0031】

ネットワークインタフェース１０４は、ネットワークに接続してネットワークインタフェース制御を行う。ネットワークインタフェース１０４は、ネットワークを通じてコミュニケーションサービスシステム２０にアクセスして、会話情報や履歴情報等を収集・取得する。また、ネットワークインタフェース１０４は、例えば、ＮＩＣ（Network Interface Card）、無線ＬＡＮ（Local Area Network）カード等を使用することもできる。ネットワークインタフェース１０４で受信されたデータは、メモリ１０１やプロセッサ１００に出力される。

【0032】

以上のようなハードウェア構成によって、情報処理装置１０の処理機能を実現することができる。例えば、情報処理装置１０は、プロセッサ１００がそれぞれ所定のプログラムを実行することで本発明の処理を行うことができる。

【0033】

情報処理装置１０は、例えば、コンピュータで読み取り可能な記録媒体に記録されたプログラムを実行することにより、本発明の処理機能を実現する。情報処理装置１０に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。

【0034】

例えば、情報処理装置１０に実行させるプログラムを補助記憶装置に格納しておくことができる。プロセッサ１００は、補助記憶装置内のプログラムの少なくとも一部を主記憶装置にロードし、プログラムを実行する。

【0035】

また、光ディスク、メモリ装置、メモリカード等の可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えば、プロセッサ１００からの制御により、補助記憶装置にインストールされた後、実行可能となる。またプロセッサ１００が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

【0036】

＜GitHub＞
次にソフトウェア開発プラットフォーム２２の一例であるGitHubについて説明する。Gitとはオープンソースの分散バージョン管理システムであり、ソフトウェア開発ではソースコードのバージョン管理に用いられる。

【0037】

開発担当者は、新しい機能を作成する際に、本番環境（masterブランチ）からコピーした開発環境（featureブランチ）を作成する。そして、開発担当者はコミット（commit）を重ねながら、開発が終了したブランチをmasterブランチにマージ（統合）することで、開発本流のmasterブランチを壊さずにソフトウェア開発を進めることができる。

【0038】

なお、コミットとは、ファイルの変更や追加を日時・実施者・差分・コメント等と共に記録するコマンドであり、ファイルの追加や変更の履歴をリポジトリに保存する。新機能の開発等でソースコードの変更量が大きくなる場合は、一般に処理の分割が行われ、コミット単位で分けることでレビューが容易となる。

【0039】

GitHubは、このようなGitを利用したソフトウェア開発をサポートするサービスであり、ソースコードの管理に加え、プルリクエスト（Pull Request）によるサービスを提供する。プルリクエストは、バグの修正や機能追加をmasterブランチに取り込んでもらうための要求（依頼）を出す機能である。プルリクエストを行うことで、GitHubで管理されているソースコードの差分等を確認しながらソフトウェア開発を進めていくことが可能となっている。

【0040】

なお、オープンソースのソースコードホスティングシステムであるGitLabにもGitHubのプルリクエスト相当のマージリクエスト（Merge Request）という機能がある。本実施の形態では、プルリクエストを例に挙げたが、マージリクエストとしても同様の制御が可能である。

【0041】

図４はGitHubの動作の一例を説明するための図である。
〔ステップＳ１１〕masterブランチとなるソフトウェア開発のリポジトリに対して、ソースコードの機能追加・修正等を行う際にcreateブランチによって新しいブランチ（featureブランチ）が生成される。

【0042】

〔ステップＳ１２〕ソースコードの機能追加・修正等が行われて（commit changes）、featureブランチが更新される。
〔ステップＳ１３〕featureブランチをmasterブランチにマージするためのプルリクエストが行われる。

【0043】

〔ステップＳ１４〕featureブランチをmasterブランチにマージする前に、機能追加・修正等のフィードバック検証が行われる。
〔ステップＳ１５〕featureブランチの最終確認が行われる（test changes）。

【0044】

〔ステップＳ１６〕featureブランチがmasterブランチにマージされる（mergeブランチ）。
＜情報処理装置の動作＞
以降、情報処理装置１０の動作について詳しく説明する。ここで、開発担当者、レビュアおよび有識者の用語について説明する。

【0045】

開発担当者は、開発機能のソースコードの作成を行った人物である。例えば、GitHub等のソースコードホスティングシステム上でassigneeに割り当てられた人物を開発担当者として扱うことができる。

【0046】

レビュアは、開発担当者が作成し、masterブランチに統合されようとするソースコードをチェックする人物である。ソースコードに詳しいと思われる人物や開発責任者（ソースコードにマージできる権限を持っているもののソースコードを熟知していない）が割り当てられる。例えば、GitHub等のソースコードホスティングシステム上でreviewerに割り当てられた人物をレビュアとして扱うことができる。

【0047】

有識者は、例えば、開発機能に関連するソースコードの修正を過去に行ったことのある人物を有識者として扱うことができる。よって、レビュアが有識者に包含されてもよいし、有識者とレビュアは重複してもよい。

【0048】

（会話情報の収集）
図５は会話情報の収集動作の一例を示す図である。コミュニケーションツール２１として、チャットアプリケーションのMattermostで会話ｃ１が行われたとする。会話ｃ１では、yamada.taroのメッセージである「ありがとうございます！こちらでも確認してみます」に対して、sato.hanakoがスマイルのスタンプで応答している。

【0049】

制御部１１は、REST API（Representational State Transfer Application Programming Interface）やファイルダンプ等により、Mattermostから半構造化された会話情報ｃｄ１を収集する。なお、REST APIは、Webシステムを外部から利用するためのプログラムの呼び出し規約である。

【0050】

（会話データの抽出）
図６は会話データの抽出動作の一例を示す図である。制御部１１は、収集した会話情報から解析に要する会話データを抽出する。抽出した会話データは、チャットアプリテーブルｔ１に登録される。

【0051】

チャットアプリテーブルｔ１は、Mattermostによって収集した会話情報ｃｄ１から会話データを抽出してテーブル化したものであり、id、original_id、root_id、posted_at、username、channelおよびreaction_typeの項目を有する。

【0052】

idは、チャットアプリテーブルｔ１内で識別される番号である。original_idは、１つのメッセージに付される番号であり、会話情報ｃｄ１内のidに対応する。会話情報ｃｄ１からoriginal_idとして“3ot1aijcebf5t8e75kr9text4h”が抽出されている。

【0053】

root_idは、メッセージに付されるid（メッセージ識別子）であり、会話情報ｃｄ１内のroot_idに対応する。会話情報ｃｄ１からroot_idとして“3ot1aijcebf5t8e75kr9text4h”が抽出されている。

【0054】

posted_atは、メッセージが投稿された時間であり、会話情報ｃｄ１内のcreate_atに示される数値を時間に変換したものに対応する。会話情報ｃｄ１からposted_atとして“2020-1221-19:31”が抽出されている。

【0055】

usernameは、会話情報ｃｄ１のuser idを人の氏名に変換したものであり、“yamada.taro”が抽出されている。channelは、会話情報ｃｄ１のchannel_idからチャネル名に変換したものであり、“team_dev”が抽出されている。reaction_typeは、メッセージに対する応答がメッセージの場合はmessageと登録され、スタンプの場合はスタンプ名が登録される。図６の例では、「ありがとうございます！こちらでも確認してみます」のメッセージに対しての応答として“smile”のスタンプ名が登録されている。

【0056】

図７はチャットアプリテーブルの一例を示す図である。チャットアプリテーブルＴ１は、図６で上述したように、コミュニケーションツール２１として例えば、チャットアプリケーションのMattermostの会話情報から抽出した会話データをテーブル化したものである。

【0057】

チャットアプリテーブルＴ１では、id＝1の会話データのレコードと、id＝2の会話データのレコードの各root_idは同じ“3ot1aijcebf5t8e75kr9text4h”となっている。このようにroot_idが同一の会話データは、１つの同じ会話スレッドとして扱われる。

【0058】

図８はプルリクエスト会話テーブルの一例を示す図である。制御部１１は、チャットアプリテーブルＴ１の作成と同様にして、ソフトウェア開発プラットフォーム２２のGitHubからプルリクエスト会話テーブルＴ２を作成する。

【0059】

プルリクエスト会話テーブルＴ２は、GitHub上でのissueやプルリクエストによる会話から解析に要する会話データを抽出して作成したテーブルであり、id、original_id、root_id、posted_at、username、channelおよびreaction_typeの項目を有する。

【0060】

また、プルリクエスト会話テーブルＴ２では、id＝1の会話データのレコードと、id＝2の会話データのレコードの各root_idは同じ“dfakjekfjekf5t8e75falejkljsd”となっている。このようにroot_idが同一の会話データは、GitHub上でのissueやプルリクエストにおいて、１つの同じ会話スレッドとして扱われる。

【0061】

なお、上記では、MattermostやGitHubの会話情報から会話データを抽出して作成した会話テーブルの一例を示したが、会議等の音声データを話者識別してテキスト化したものから同様にして解析に要する会話テーブル（会議発言テーブル）を作成することも可能である。

【0062】

（履歴情報の取得）
GitHubでは、上述した会話情報の管理の他に、ソースコードの管理機構も有している。制御部１１は、GitHubのソースコードの管理機構から履歴情報を取得する。履歴情報には、masterブランチのコミット情報および開発ブランチ（featureブランチ）のコミット情報が含まれる。

【0063】

図９はmasterブランチのコミット情報からのデータ抽出の一例を示す図である。制御部１１は、masterブランチのコミット情報から解析に要するデータを抽出して、masterブランチ更新テーブル（本番環境更新テーブル）ｔ３を作成する。

【0064】

masterブランチのコミット情報は、masterブランチ更新情報ｍｄ１とコミットの差分（diff）情報ｍｄ２を含む。masterブランチ更新テーブルｔ３は、masterブランチ更新情報ｍｄ１とコミットの差分情報ｍｄ２から抽出したデータが登録され、id、commitid、username、dateおよびchangefileの項目を有する。

【0065】

idは、masterブランチ更新テーブルｔ３内で識別される番号である。commitidは、１つのコミット情報に付される番号であり、masterブランチ更新情報ｍｄ１内のcommitに対応する。masterブランチ更新情報ｍｄ１からcommitidとして“4c50ff93”が抽出されている。

【0066】

usernameは、masterブランチに対してコミットを行った人の氏名であり、masterブランチ更新情報ｍｄ１内のAuthorに対応する。masterブランチ更新情報ｍｄ１からusernameとして“yoshida.jiro”が抽出されている。

【0067】

dateは、コミットが行われた時間であり、masterブランチ更新情報ｍｄ１内のDateに対応する。masterブランチ更新情報ｍｄ１からdateとして“2020-1209-17:16”が抽出されている。

【0068】

changefileは、開発されたファイル名であり、コミットの差分情報ｍｄ２内のchangefileに対応する。コミットの差分情報ｍｄ２からchangefileとして“fileA”が抽出されている。

【0069】

図１０は開発ブランチのコミット情報からのデータ抽出の一例を示す図である。制御部１１は、開発ブランチのコミット情報から解析に要するデータを抽出して、開発ブランチ更新テーブル（開発環境更新テーブル）ｔ４を作成する。

【0070】

開発ブランチのコミット情報は、開発ブランチ更新情報ｆｄ１とコミットの差分（diff）情報ｆｄ２を含む。開発ブランチ更新テーブルｔ４は、開発ブランチ更新情報ｆｄ１とコミットの差分情報ｆｄ２から抽出したデータが登録され、id、commitid、username、dateおよびchangefileの項目を有する。

【0071】

idは、開発ブランチ更新テーブルｔ４内で識別される番号である。commitidは、１つのコミット情報に付される番号であり、開発ブランチ更新情報ｆｄ１内のcommitに対応する。開発ブランチ更新情報ｆｄ１からcommitidとして“bnlrvkrd”が抽出されている。

【0072】

usernameは、開発ブランチに対してコミットを行った人の氏名であり、開発ブランチ更新情報ｆｄ１内のAuthorに対応する。開発ブランチ更新情報ｆｄ１からusernameとして“sato.hanako”が抽出されている。

【0073】

dateは、コミットが行われた時間であり、開発ブランチ更新情報ｆｄ１内のDateに対応する。開発ブランチ更新情報ｆｄ１からdateとして“2020-1214-14:33”が抽出されている。

【0074】

changefileは、修正されたファイル名であり、コミットの差分情報ｆｄ２内のchangefileに対応する。コミットの差分情報ｆｄ２からchangefileとして“fileA”が抽出されている。

【0075】

（修正ファイル、開発担当者および有識者の特定）
図１１はmasterブランチ更新テーブルの一例を示す図である。masterブランチ更新テーブル（本番環境更新テーブル）Ｔ３は、図９で上述したように、ソフトウェア開発プラットフォーム２２として例えば、GitHubのmasterブランチのコミット情報から抽出したmasterブランチにおける開発データをテーブル化したものである。

【0076】

図１２は開発ブランチ更新テーブルの一例を示す図である。開発ブランチ更新テーブル（開発環境更新テーブル）Ｔ４は、図１０で上述したように、GitHubの開発ブランチのコミット情報から抽出した開発ブランチにおける開発データをテーブル化したものである。

【0077】

ここで、図１１、図１２の例において、開発ブランチ更新テーブルＴ４のchangefile列にもとづいて、修正されたファイルはfileAと検出され、fileAの開発ブランチ更新テーブルＴ４のusername列にもとづいて、修正に携わった開発担当者はsato.hanakoと特定される。

【0078】

そして、masterブランチ更新テーブルＴ３のchangefile列を値がfileAのレコードに絞ることで、masterブランチへコミットしている人物でfileAを作成した有識者は、yoshida.jiroおよびyamada.taroであることが特定される。

【0079】

さらに、コミット回数が多い人物はfileAに最も関わっている有識者とし、コミット回数が少ない人物はfileAの初版作成の人物と特定できる。この例では、masterブランチ更新テーブルＴ３のusername列で最頻出となる（コミット回数が多い）人物（fileAに最も関わっている有識者）はyamada.taroと特定される。また、コミット回数が少ないyoshida.jiroは初版作成の人物と特定される。

【0080】

このように、制御部１１は、有識者として、修正されたファイルを最初に作成した人物または修正されたファイルの修正・改変に過去最も関わった人物をGitHubに対するコミット回数にもとづいて特定する。これにより、有識者ということだけでなく、修正されたファイルの過去の最多修正者および初版作成者といった属性も特定することが可能になる。

【0081】

また、上記のように、制御部１１は、GitHubから履歴情報を取得し、履歴情報からmasterブランチにおけるファイルの更新情報として、ファイルの作成者の氏名（username）、作成期間（date）およびファイル名（changefile）を含むmasterブランチ更新テーブルＴ３を作成する。

【0082】

さらに、制御部１１は、履歴情報から開発環境におけるファイルの更新情報として、ファイルの修正者の氏名（username）、修正期間（date）およびファイル名（changefile）を含む開発ブランチ更新テーブルＴ４を作成する。

【0083】

そして、制御部１１は、開発ブランチ更新テーブルＴ４のファイル名（changefile）から修正ファイル（fileA）を検出し、ファイルの修正者の氏名（username）から開発担当者（sato.hanako）を検出する。さらに、検出した修正ファイル（fileA）がmasterブランチ更新テーブルＴ３のファイル名（changefile）に登録されるレコードにおけるファイルの作成者の氏名（username）から有識者（yamada.taro、yoshida.jiro）を検出する。このような制御によって、GitHubの履歴情報から、修正ファイル、開発担当者および有識者を精度よく特定することができる。

【0084】

（プルリクエスト情報の取得）
図１３はプルリクエスト情報からのデータ抽出の一例を示す図である。制御部１１は、REST APIにより、GitHub等のコードホスティングサービスからプルリクエスト情報を取得する。プルリクエスト情報には、開発関係者情報（レビュア、開発担当者等）、プルリクエストがオープンされた開発開始日時、最終更新日時等が含まれる。

【0085】

プルリクエスト情報テーブルｔ５ａは、プルリクエスト情報ｐｒから抽出したデータが登録されており、id、reviewer、assignee、created_at、updated_atおよびpr_idの項目を有する。

【0086】

idは、プルリクエスト情報テーブルｔ５ａ内で識別される番号である。reviewerは、レビュアの氏名であり、プルリクエスト情報ｐｒ内のrequested reviewersの下のlogin名に対応する。プルリクエスト情報ｐｒからreviewerとして“saito.goro”が抽出されている。

【0087】

assigneeは、開発担当者の氏名であり、プルリクエスト情報ｐｒ内のassigneeの下のlogin名に対応する。プルリクエスト情報ｐｒからassigneeとして“sato.hanako”が抽出されている。

【0088】

created_atは、プルリクエストがオープンされた開発開始日時であり、プルリクエスト情報ｐｒ内のcreated_atに対応する。プルリクエスト情報ｐｒからcreated_atとして“2020-1210-19:20”が抽出されている。

【0089】

updated_atは、プルリクエストの最終更新日時であり、プルリクエスト情報ｐｒ内のupdated_atに対応する。プルリクエスト情報ｐｒからupdated_atとして“2020-1223-13:21”が抽出されている。なお、created_atとupdated_atは、システムから取得する時間は協定世界時間（ＵＴＣ：Universal Time Coordinated）のものなので、日本標準時間と合わせるため＋９時間としている。

【0090】

pr_idは、プルリクエストを識別する番号である。プルリクエスト情報ｐｒ内のnumberに対応する。プルリクエスト情報ｐｒからpr_idとして“48”が抽出されている。
なお、プルリクエスト情報テーブルｔ５ａのcreated_atからupdated_at（2020-1210-19:20から2020-1223-13:21）期間中の会話データを解析に利用するものとする。すなわち、この期間は、ファイル修正が行われた期間とみなされ、当該期間における会話データからコミュニケーション有無の検出が行われる。

【0091】

このように、制御部１１では、Mattermostから収集した会話情報から、会話メッセージのメッセージ識別子（root_id）、会話が行われた会話時間（posted_at）、会話者の氏名（username）を抽出してチャットアプリテーブルＴ１を作成する。

【0092】

また、制御部１１は、GitHubにプルリクエストがオープンされたときのプルリクエスト情報ｐｒからファイルの修正期間（created_atからupdated_at）を抽出する。そして、このファイルの修正期間に会話時間が含まれるチャットアプリテーブルＴ１の会話スレッドを、ファイルの修正が行われた期間における会話データとして抽出する。これにより、ファイル修正が行われた期間の会話データをMattermostから精度よく抽出することが可能になる。

【0093】

一方、制御部１１では、GitHubから収集した会話情報から、会話メッセージのメッセージ識別子（root_id）、会話が行われた会話時間（posted_at）、会話者の氏名（username）を抽出してプルリクエスト会話テーブルＴ２を作成する。

【0094】

また、制御部１１は、GitHubにプルリクエストがオープンされたときのプルリクエスト情報ｐｒからファイルの修正期間（created_atからupdated_at）を抽出する。そして、このファイルの修正期間に会話時間が含まれるプルリクエスト会話テーブルＴ２の会話スレッドを、ファイルの修正が行われた期間における会話データとして抽出する。これにより、ファイル修正が行われた期間の会話データをGitHubから精度よく抽出することが可能になる。

【0095】

図１４はプルリクエスト関係者テーブルの一例を示す図である。プルリクエスト関係者テーブルＴ５は、プルリクエスト情報テーブルｔ５ａに対して、masterブランチ更新テーブルＴ３および開発ブランチ更新テーブルＴ４から検出された有識者のexpert列を追加したものである。なお、reviewer、assignee、expertは複数人となることもありうる。

【0096】

（会話データ解析の具体例）
会話データ解析の具体例として、pr_id＝48の開発項目における開発担当者と有識者間での会話有無の解析を行うものとする。図１４に示したプルリクエスト関係者テーブルＴ５から、pr_id＝48の開発項目においては、assignee列から開発担当者はsato.hanakoであることが検出される。さらに、reviewer列からレビュアはsaito.goroであり、expert1／expert2列から有識者はyoshida.jiro、yamada.taroであることが検出される。また、上述したように、プルリクエスト関係者テーブルＴ５のcreated_atからupdated_at（2020-1210-19:20から2020-1223-13:21）期間中の会話データを解析に利用するものとする。

【0097】

図１５はチャットアプリテーブルの一例を示す図である。チャットアプリテーブルＴ１１において、root_idが同一となるレコードは同じ会話スレッドである。したがって、root_id＝3ot1aijcebf5t8e75kr9text4hであるid＝１、２のレコードは同一の会話スレッドであり、root_id＝mniqwhyhxbn4zfofrxmmjzo1boであるid＝４、５のレコードは同一の会話スレッドである。

【0098】

ここで、チャットアプリテーブルＴ１１において、以下の条件（１Ａ）、（２Ａ）、（３Ａ）をすべて満たす会話スレッドがある場合、開発担当者と有識者／レビュア間での会話が存在したと判定する。

【0099】

（１Ａ）root_idが同一となる会話スレッドのうちにusername＝開発担当者となるレコードが存在する。
（２Ａ）root_idが同一となる会話スレッドのうちにusername＝レビュアまたは有識者となるレコードが存在する。

【0100】

（３Ａ）root_idが同一となる会話スレッドのうちに、posted_at列の値が最もcreate_atに近い行（posted_atが最も古い行）のusername（最初の発言者・有識者）が開発担当者、レビュアまたは有識者であるレコードが存在する。

【0101】

チャットアプリテーブルＴ１１におけるid＝１、２の会話スレッドについては、username＝sato.hanako（開発担当者）となるレコードが存在するので（１Ａ）を満たす。また、username＝yamada.taro（有識者）となるレコードが存在するので（２Ａ）を満たす。さらに、会話スレッド中でposted_atが最も古いレコードのusername（最初の発言者・有識者）がyamada.taro（有識者）となるレコードが存在するので（３Ａ）を満たす。

【0102】

したがって、id＝１、２の会話スレッドでは、sato.hanako（開発担当者）とyamada.taro（有識者）との会話があったことが検出される。
一方、チャットアプリテーブルＴ１１におけるid＝４、５の会話スレッドについては、username＝sato.hanako（開発担当者）となるレコードが存在するので（１Ａ）を満たす。また、username＝yoshida.jiro（有識者）となるレコードが存在するので（２Ａ）を満たす。さらに、会話スレッド中でposted_atが最も古い行のusername（最初の発言者・有識者）がyoshida.jiro（有識者）となるレコードが存在するので（３Ａ）を満たす。

【0103】

したがって、id＝４、５の会話スレッドでは、sato.hanako（開発担当者）とyoshida.jiro（有識者）との会話があったことが検出される。このような制御によって、Mattermostにもとづくチャットアプリテーブルから、開発担当者と有識者とのコミュニケーションの有無を精度よく検出することができる。

【0104】

図１６はプルリクエスト会話テーブルの一例を示す図である。プルリクエスト会話テーブルＴ１２において、root_idが同一となるレコードを１つの会話スレッドとする。したがって、root_id＝dfakjekfjekf5t8e75falejkljsdであるid＝１、２、３のレコードは同一の会話スレッドである。

【0105】

ここで、プルリクエスト会話テーブルＴ１２において、以下の条件（１Ｂ）、（２Ｂ）をすべて満たす会話スレッドがある場合、開発担当者と有識者／レビュア間での会話が存在したと判定する。

【0106】

（１Ｂ）root_idが同一となる会話スレッドのうちにusername＝開発担当者となるレコードが存在する。
（２Ｂ）root_idが同一となる会話スレッドのうちにusername＝レビュアまたは有識者となるレコードが存在する。

【0107】

プルリクエスト会話テーブルＴ１２におけるid＝１、２、３の会話スレッドについては、username＝sato.hanako（開発担当者）となるレコードが存在するので（１Ｂ）を満たす。また、username＝saito.goro（レビュア）となるレコードが存在するので（２Ｂ）を満たす。

【0108】

したがって、id＝１、２、３の会話スレッドでは、sato.hanako（開発担当者）とsaito.goro（レビュア）との会話があったことが検出される。このような制御によって、GitHubにもとづくプルリクエスト会話テーブルから、開発担当者と有識者とのコミュニケーションの有無を精度よく検出することができる。

【0109】

（会話有無の提示）
図１７は会話有無の提示画面の一例を示す図である。制御部１１は、上記のような会話データの解析によって検出した開発担当者と有識者／レビュア間のコミュニケーションの有無およびマージ判定結果を可視化情報にして、例えば、開発責任者に提示する。

【0110】

この場合、例えば、過半数の有識者と、開発関係者とのコミュニケーションが取れているか否かで「マージOK」「マージNG」といったマージ判定の基準となる通知とともに、開発担当者と関係者のコミュニケーションの有無を提示してもよい。また、有識者とはみなされてないものの会話量の多い人物との会話を有識者候補との会話として併せて提示してもよい。

【0111】

制御部１１は画面ｇ１０を表示する。画面ｇ１０は、画面ｇ１１、ｇ１２を含む。画面ｇ１１は、プルリクエスト＃４８の開発項目のうち、すべての参加者をノードで表し、開発担当者と、開発担当者が会話した参加者とのノード間を枝で結んでグラフ化したものである。sato.hanako（開発担当者）は、yamada.taro（有識者）、yoshida.jiro（有識者）、suzuki.siro（第三者）およびsaito.goro（レビュア）と会話していることが示される。

【0112】

画面ｇ１２は、会話有無テーブルＴ０とマージ判定結果Ｍ０を示している。会話有無テーブルＴ０は、username、役割および会話有無の項目を有する。また、マージ判定結果Ｍ０は、マージOKまたはマージNGを示す。

【0113】

会話有無テーブルＴ０からsato.hanako（開発担当者）は、yamada.taro（有識者（最多修正））、yoshida.jiro（有識者（初版作成））およびsaito.goro（レビュア）と会話していることが検出されている。したがって、開発プログラムへの修正ファイル（修正ソースコード）のマージ（適用）か否かのマージ判定結果Ｍ０はマージOKとなっている。

【0114】

（フローチャート）
図１８は情報処理装置の動作の一例を示すフローチャートである。
〔ステップＳ２１〕制御部１１は、Mattermost、GitHub等のコミュニケーションサービスシステムから会話情報を収集する。

【0115】

〔ステップＳ２２〕制御部１１は、収集した会話情報から解析に要する会話データを抽出する。
〔ステップＳ２３〕制御部１１は、会話データから開発担当者、有識者／レビュアを識別する。

【0116】

〔ステップＳ２４〕制御部１１は、開発担当者と有識者／レビュアとの会話があるか否かを検出する。会話がある場合はステップＳ２５に進み、会話がない場合はステップＳ２６に処理が進む。

【0117】

〔ステップＳ２５〕制御部１１は、開発責任者に「マージOK」を提示する。
〔ステップＳ２６〕制御部１１は、開発責任者に「マージNG」を提示する。
上記で説明した本発明の情報処理装置１、１０の処理機能は、コンピュータによって実現することができる。この場合、情報処理装置１、１０が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。

【0118】

処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶部、光ディスク、光磁気記録媒体、半導体メモリ等がある。磁気記憶部には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープ等がある。光ディスクには、ＣＤ－ＲＯＭ／ＲＷ等がある。光磁気記録媒体には、ＭＯ（Magneto Optical disk）等がある。

【0119】

プログラムを流通させる場合、例えば、そのプログラムが記録されたＣＤ－ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶部に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

【0120】

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶部に格納する。そして、コンピュータは、自己の記憶部からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。

【0121】

また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。また、上記の処理機能の少なくとも一部を、ＤＳＰ、ＡＳＩＣ、ＰＬＤ等の電子回路で実現することもできる。

【0122】

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

【符号の説明】

【0123】

１ 情報処理装置
１ａ 制御部
１ｂ 記憶部
２ａ 修正履歴情報
２ｂ コミュニケーションサービスシステム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】