(57)【要約】【課題】ユーザの利便性を向上させることが可能な管理データ改善装置、方法及びプログラムを提供することにある。【解決手段】実施形態に係る管理データ改善装置は、取得手段と、評価手段とを具備する。取得手段は、ユーザによって作成された第１ソースコードがコミットされた場合に蓄積された、当該第１ソースコードよりも前にコミットされた第２ソースコードからの変更箇所を示す第１コミットデータを取得する。評価手段は、取得された第１コミットデータによって示される変更箇所の依存関係の解析結果に基づいて、当該変更箇所に関するコミットの粒度が適切であるかを評価する。【選択図】図４
2020071704.tif 000002
【特許請求の範囲】
【請求項１】
ユーザによって作成された第１ソースコードがコミットされた場合に蓄積された、当該第１ソースコードよりも前にコミットされた第２ソースコードからの変更箇所を示す第１コミットデータを取得する取得手段と、
前記取得された第１コミットデータによって示される変更箇所の依存関係の解析結果に基づいて、当該変更箇所に関するコミットの粒度が適切であるかを評価する評価手段と
を具備する管理データ改善装置。
【請求項２】
前記第１コミットデータは、第１及び第２変更箇所を示し、
前記評価手段は、前記第１及び第２変更箇所の間に依存関係があるか否かを判定し、前記第１及び第２変更箇所の間に依存関係がないと判定された場合、前記コミットの粒度が大きいと評価する
請求項１記載の管理データ改善装置。
【請求項３】
前記評価手段は、前記第１及び第２変更箇所の間に依存関係があると判定され、前記第１ソースコードに文法エラーがない場合、前記コミットの粒度が小さいと評価する請求項２記載の管理データ改善装置。
【請求項４】
前記評価手段は、前記第１及び第２変更箇所の間に依存関係があると判定され、前記第１ソースコードに文法エラーがない場合、前記コミットの粒度が適切であると評価する請求項３記載の管理データ改善装置。
【請求項５】
前記評価手段は、前記第１ソースコード中に出現する変数の値を変更すると、前記第１及び第２変更箇所に対応する処理または値に変化が起こる可能性がある場合に前記第１及び第２変更箇所の間に依存関係があると判定する請求項２〜４のいずれか一項に記載の管理データ改善装置。
【請求項６】
前記評価手段は、
前記第１変更箇所に対応する処理または値に変化が起こる可能性がある前記第１ソースコード中に出現する変数の第１集合を特定し、
前記第２変更箇所に対応する処理または値に変化が起こる可能性がある前記第１ソースコード中に出現する変数の第２集合を特定し、
前記第１及び第２集合のうちの少なくとも一部が重複する場合に、前記第１及び第２変更箇所の間に依存関係があると判定する
請求項２〜４のいずれか一項に記載の管理データ改善装置。
【請求項７】
前記コミットの粒度が大きいと評価された場合、前記第１コミットデータの分割候補として、前記第１変更箇所を示す第２コミットデータ及び前記第２変更箇所を示す第３コミットデータの各々を提示する提示手段を更に具備する請求項２記載の管理データ改善装置。
【請求項８】
前記第２コミットデータによって示される第１変更箇所の変更内容を含む第３ソースコードにおける文法エラーの有無を判定する第１判定手段と、
前記第３コミットデータによって示される第２変更箇所の変更内容を含む第４ソースコードにおける文法エラーの有無を判定する第２判定手段と
を具備し、
前記提示手段は、前記第３ソースコードに文法エラーがないと判定され、かつ、前記第４ソースコードに文法エラーがないと判定された場合、前記第２及び第３コミットデータの各々を提示する
請求項７記載の管理データ改善装置。
【請求項９】
前記第１コミットデータの分割候補としての前記第２及び第３コミットデータの評価値を、当該第２コミットデータによって示される第２変更箇所に基づいて算出する算出手段を更に具備し、
前記提示手段は、前記算出された評価値に基づいて、前記第２及び第３コミットデータの各々を提示する
請求項８記載の管理データ改善装置。
【請求項１０】
前記コミットの粒度が小さいと評価された場合、前記第１コミットデータの結合候補として、当該第１コミットデータと、前記第１ソースコードよりも後に作成された第３ソースコードがコミットされた場合に蓄積された第２コミットデータとを結合した第３コミットデータを提示する提示手段を更に具備する請求項３記載の管理データ改善装置。
【請求項１１】
判定手段を更に具備し、
前記第２コミットデータは、第３変更箇所を示し、
前記判定手段は、前記第１コミットデータによって示される第１及び第２変更箇所と、前記第２コミットデータによって示される第３変更箇所とを含む第４ソースコードにおける文法エラーの有無を判定し、
前記提示手段は、前記第４ソースコードに文法エラーがないと判定された場合、前記第３コミットデータを提示する
請求項１０記載の管理データ改善装置。
【請求項１２】
前記第１コミットデータの結合候補としての前記第３コミットデータの評価値を、当該第３コミットデータによって示される第１乃至第３変更箇所に基づいて算出する算出手段を更に具備し、
前記提示手段は、前記算出された評価値に基づいて、前記第３コミットデータを提示する
請求項１１記載の管理データ改善装置。
【請求項１３】
管理データ改善装置が実行する方法であって、
ユーザによって作成された第１ソースコードがコミットされた場合に蓄積された、当該第１ソースコードよりも前にコミットされた第２ソースコードからの変更箇所を示すコミットデータを取得するステップと、
前記取得されたコミットデータによって示される変更箇所の依存関係の解析結果に基づいて、当該変更箇所に関するコミットの粒度が適切であるかを評価するステップと
を具備する方法。
【請求項１４】
管理データ改善装置のコンピュータによって実行されるプログラムであって、
前記コンピュータに、
ユーザによって作成された第１ソースコードがコミットされた場合に蓄積された、当該第１ソースコードよりも前にコミットされた第２ソースコードからの変更箇所を示すコミットデータを取得するステップと、
前記取得されたコミットデータによって示される変更箇所の依存関係の解析結果に基づいて、当該変更箇所に関するコミットの粒度が適切であるかを評価するステップと
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、管理データ改善装置、方法及びプログラムに関する。
【背景技術】
【０００２】
一般に、ソフトウェア製品の開発においては、当該ソフトウェアの機能追加、修正、改善、派生開発等のために、プログラム言語で記述されたソースコードのバージョンを管理するツール（以下、構成管理ツールと表記）が利用されている。
【０００３】
このような構成管理ツールにおいてソースコードはコミットと称される単位で管理され、新しいバージョンのソースコードがコミットされた場合には直前のソースコードからの変更箇所（ソースコード中の変更された位置及び内容等）が記録される。このような構成管理ツールによれば、ユーザは、例えばソースコードが変更（改変）された経緯または任意のバージョンのソースコード等を確認する（レビューする）ことが可能となる。
【０００４】
ところで、ソースコードはユーザが能動的にコミットするため、当該コミットの粒度が適切でない場合がある。なお、コミットの粒度とは、コミットの大きさのような概念であり、例えばコミットされたソースコードに含まれる変更箇所の数等に相当する。具体的には、あるソースコードがコミットされた後、次のソースコードがコミットされるまでの期間が短く、当該あるソースコードから次のソースコードへの変更箇所の数が比較的少ない場合には、当該コミットの粒度は小さくなる。一方、あるソースコードがコミットされた後、次のソースコードがコミットされるまでの期間が長く、当該あるソースコードから次のソースコードへの変更箇所の数が比較的多い場合には、当該コミットの粒度は大きくなる。
【０００５】
上記したようにコミットの粒度が適切でない場合には、コミットされた各バージョンのソースコードに対するレビューが困難となる場合があり、構成管理ツールを利用するユーザの利便性に欠ける。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−２６８７７７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
そこで、本発明が解決しようとする課題は、ユーザの利便性を向上させることが可能な管理データ改善装置、方法及びプログラムを提供することにある。
【課題を解決するための手段】
【０００８】
実施形態に係る管理データ改善装置は、取得手段と、評価手段とを具備する。前記取得手段は、ユーザによって作成された第１ソースコードがコミットされた場合に蓄積された、当該第１ソースコードよりも前にコミットされた第２ソースコードからの変更箇所を示す第１コミットデータを取得する。前記評価手段は、前記取得された第１コミットデータによって示される変更箇所の依存関係の解析結果に基づいて、当該変更箇所に関するコミットの粒度が適切であるかを評価する。
【図面の簡単な説明】
【０００９】
【図１】コミットの粒度について説明するための図。
【図２】コミットの粒度について説明するための図。
【図３】第１実施形態に係る管理データ改善装置のシステム構成の一例を示す図。
【図４】管理データ改善装置の機能構成の一例を示すブロック図。
【図５】格納部に格納されているコミットデータのデータ構造の一例について説明するための図。
【図６】管理データ改善装置の処理手順の一例を示すフローチャート。
【図７】粒度評価処理の処理手順の一例を示すフローチャート。
【図８】第２実施形態における分割候補作成部の処理手順の一例を示すフローチャート。
【図９】変数名に重なりがあるソースコードの一例を示す図。
【図１０】依存変数集合について説明するためのソースコードの一例を示す図。
【図１１】依存変数集合について説明するためのソースコードの別の例を示す図。
【図１２】引数依存マップについて説明するためのソースコードの一例を示す図。
【図１３】依存変数集合を引数依存マップ及びグローバル依存マップを含んだ形で計算する処理について説明するためのソースコードの一例を示す図。
【図１４】依存変数集合を引数依存マップ及びグローバル依存マップを含んだ形で計算する処理について説明するためのソースコードの別の例を示す図。
【図１５】引数依存マップの具体例について説明するための図。
【図１６】グローバル依存マップの具体例について説明するための図。
【図１７】引数依存マップ及びグローバル依存マップの計算の具体例について説明するための図。
【図１８】ソースコードに対して分割候補を生成する処理が実行された結果の一例を示す図。
【図１９】第１及び第２分割候補の一例を示す図。
【発明を実施するための形態】
【００１０】
以下、図面を参照して、各実施形態について説明する。
（第１実施形態）  
まず、第１実施形態について説明する。本実施形態に係る管理データ改善装置は、例えばソフトウェア製品の開発等においてユーザによって作成されるソースコードのバージョンを管理するために用いられる。
【００１１】
このような管理データ改善装置において、ユーザによって作成されるソースコードはコミットと称される単位で管理され、例えば新しいバージョンのソースコードが登録された場合には、当該ソースコードより前に登録されたソースコード（直前のソースコード）からの変更箇所が記録される。
【００１２】
これによれば、ユーザは、ソースコードが変更された経緯または任意のバージョンのソースコード等を確認する（レビューする）ことが可能となる。
【００１３】
なお、以下の説明において、直前のソースコードからの変更箇所を記録するために、新しいバージョンのソースコードを登録することを「コミットする」と称する。
【００１４】
ここで、上記したソースコードはユーザが能動的にコミットするが、当該ユーザによってコミットされるソースコードに含まれる変更箇所（直前のソースコードからの変更箇所）によって当該コミットの粒度が異なる。
【００１５】
なお、コミットの粒度は、上記した管理データ改善装置において管理される単位であるコミットの大きさ（コミットされたソースコードと直前のソースコードとの差分等）に関する基準値を用いて表される。この場合、基準値が例えばｎ及びｍ（ｎ＞ｍ）であるコミットをそれぞれコミットＮ、Ｍとすると、コミットＮの方が粒度が大きいまたはコミットＭの方が粒度が小さいと表現するとする。
【００１６】
具体的には、複数のソースファイル内の複数のソースコードの各々が変更され、当該複数のソースコードがコミットされた場合には、基準値は、当該ソースファイル（変更ファイル）の数であってもよい。また、基準値は、コミットされたソースコードにおいて直前のソースコードから変更された行（変更行）の数であってもよい。また、基準値は、上記した変更ファイルの数または変更行の数から算出される数値等であってもよい。
【００１７】
なお、本実施形態において、「ソースコードが変更される」とは、例えば当該ソースコードの少なくとも一部が追加、修正または削除されること等をいう。
【００１８】
以下、図１及び図２を参照して、上記したコミットの粒度について具体的に説明する。まず、図１を参照して、コミットの粒度が大きい場合について説明する。
【００１９】
図１の上段に示すＣｎ＋１）は、新しいバージョンのソースコードの一部を示し、Ｃｎ）は、Ｃｎ＋１）に示す新しいバージョンのソースコードの直前のソースコードの一部を示している。
【００２０】
なお、Ｃｎ＋１）及びＣｎ）に示すソースコードはそれぞれコミットされており、Ｃｎ＋１）に示すソースコード中の下線太字の部分は、Ｃｎ）に示すソースコードからの変更箇所を表しているものとする。
【００２１】
ここで、Ｃｎ＋１）に示すソースコード（新しいバージョンのソースコード）は、Ｃｎ）に示すソースコード（直前のソースコード）に対して機能追加に関する変更と修正に関する変更とが行われたものとする。
【００２２】
この場合、例えばＣｎ）に示すソースコード及びＣｎ＋１）に示すソースコードの差分（つまり、新たなバージョンのソースコードの直前のソースコードからの変更箇所）においては上記した機能追加に関する変更箇所と修正に関する変更箇所（変更内容）とが混在しているため、当該差分を確認したとしても、ユーザが機能追加に関する変更及び修正に関する変更が行われていることを即座に理解することは困難である。
【００２３】
また、例えばある特定のコミットによる変更を変更前の状況に戻す機能を管理データ改善装置が有している場合において、Ｃｎ＋１）に示すソースコードがコミットされた後に機能追加に関する変更のみをキャンセルする（修正に関する変更のみが行われた状態に戻す）場合を想定する。
【００２４】
この場合、Ｃｎ＋１）に示すソースコードから戻すことができるのはＣｎ）に示すソースコードであるが、Ｃｎ）に示すソースコードは修正に関する変更もキャンセルされた状態であるため、当該Ｃｎ）に示すソースコードに対して再度修正に関する変更を行う必要がある。
【００２５】
すなわち、図１の上段に示すＣｎ）に示すソースコードをＣｎ＋１）に示すソースコードに変更してコミットした場合には、変更箇所に関するコミット粒度が大きい（例えば、一度のコミットで関係性のない複数の変更が行われている）ため、例えば図１の下段に示すように、Ｃ´ｎ）に示すソースコードに対して例えば修正に関する変更を行うことによって作成されたＣ´ｎ＋１）に示すソースコードの時点で一旦コミットし、機能追加に関する変更を行うことによって作成されたＣ´ｎ＋２）に示すソースコードを更にコミットすることが好ましい。
【００２６】
これによれば、Ｃ´ｎ）に示すソースコード及びＣ´ｎ＋１）に示すソースコードの差分が機能追加に関する変更を示していることを容易に把握することができ、Ｃ´ｎ＋１）に示すソースコード及びＣ´ｎ＋２）に示すソースコードの差分が修正に関する変更を示していることを容易に把握することができる。
【００２７】
更に、例えばＣ´ｎ）に示すソースコードとＣ´ｎ＋２）に示すソースコードとを利用すれば、上記のようにＣ´ｎ＋２）に示すソースコードがコミットされた後に機能追加に関する変更のみをキャンセルすることも容易に行うことができる。
【００２８】
したがって、例えば図１の上段に示すようにＣｎ）に示すソースコードをＣｎ＋１）に示すソースコードに変更してコミットした場合（つまり、コミットの粒度が大きい場合）には、図１の下段に示すようにＣ´ｎ）、Ｃ´ｎ＋１）、Ｃ´ｎ＋２）に示すソースコードの各々がコミットされたようにコミットを分割する必要がある。
【００２９】
次に、図２を参照して、コミットの粒度が小さい場合について説明する。図２の上段に示すＣｎ＋２）は、新しいバージョンのソースコードの一部を示し、Ｃｎ＋１）は、Ｃｎ＋２）に示すソースコードの直前のソースコードの一部を示し、Ｃｎ）は、Ｃｎ＋１）に示すソースコードの直前のソースコードの一部を示している。
【００３０】
なお、Ｃｎ＋２）、Ｃｎ＋１）及びＣｎ）に示すソースコードはそれぞれコミットされており、Ｃｎ＋２）に示すソースコード中の太字の部分はＣｎ＋１）に示すソースコードからの変更箇所を表しており、Ｃｎ＋１）に示すソースコード中の太字の部分はＣｎ）に示すソースコードからの変更箇所を表しているものとする。
【００３１】
ここで、Ｃｎ＋１）に示すソースコードは、Ｃｎ）に示すソースコードに対して機能追加に関する変更が行われたものとする。また、Ｃｎ＋２）に示すソースコードは、Ｃｎ＋１）に示すソースコードに対して更に同一の機能追加に関する変更が行われたものとする。換言すれば、Ｃｎ＋１）に示すソースコードの時点では機能追加に関する変更は完了しておらず、Ｃｎ＋２）に示すソースコードの時点で当該機能追加に関する変更が完了したものとする。
【００３２】
この場合、例えばＣｎ）に示すソースコード及びＣｎ＋１）に示すソースコードの差分には機能追加に関する変更箇所が含まれているが、Ｃｎ）に示すソースコードは当該機能追加に関する変更が完了していない状態（つまり、途中の状態）であるため、当該差分を確認したとしても、ユーザが追加された機能を理解することは困難である。
【００３３】
また、例えばＣｎ＋２）に示すソースコードがコミットされた後に機能追加に関する変更をキャンセルする場合、ユーザは、Ｃｎ）に示すソースコードに戻すべきか、Ｃｎ＋１）に示すソースコードに戻すべきかを即座に判断することが難しい。また、例えばＣｎ＋１）に示すソースコードに戻した場合には、当該ソースコードは機能追加に関する変更が完了していない状態であるため、文法エラーによって動作しない場合がある。
【００３４】
すなわち、図２の上段に示すＣｎ）に示すソースコードをＣｎ＋１）に示すソースコードに変更してコミットし、更に、Ｃｎ＋１）に示すソースコードをＣｎ＋２）に示すソースコードに変更してコミットした場合には、変更箇所に関するコミット粒度が小さい（一度のコミットで関係性のある複数の変更が行われていない）ため、例えば図２の下段に示すように、Ｃ´ｎ）に示すソースコードから機能追加に関する変更が完了したＣ´ｎ＋１）に示すソースコードが作成された時点でコミットすることが好ましい。
【００３５】
これによれば、Ｃ´ｎ）に示すソースコード及びＣ´ｎ＋１）に示すソースコードの差分に基づいて追加された機能を容易に把握することが可能となる。
【００３６】
更に、Ｃ´ｎ＋１）に示すソースコードがコミットされた後に機能追加に関する変更をキャンセルする場合には、Ｃ´ｎ）に示すソースコードに戻すことができるため、上記した図２の上段に示すＣｎ＋１）に示すソースコードのような文法エラーとなるような状態に戻してしまう事態を回避することができる。
【００３７】
したがって、例えば図２の上段に示すようにＣｎ）、Ｃｎ＋１）及びＣｎ＋２）に示すソースコードが順次コミットされた場合（つまり、コミットの粒度が小さい場合）には、図２の下段に示すように、Ｃ´ｎ）に示すソースコードがコミットされた後に、Ｃｎ＋１）に示すソースコードに含まれる変更箇所の変更内容及びＣｎ＋２）に示すソースコードに含まれる変更箇所の変更内容を含むソースコード（つまり、Ｃ´ｎ＋２）に示すソースコード）がコミットされたようにコミットを結合する必要がある。
【００３８】
そこで、本実施形態に係る管理データ改善装置は、ユーザによってコミットされたソースファイルに含まれる変更箇所に基づいて当該コミットの粒度を自動的に評価（すなわち、コミットの粒度が大きいか小さいかを自動的に判定）し、当該コミットを再構成する機能を有する。
【００３９】
以下、本実施形態に係る管理データ改善装置について説明する。図３は、本実施形態に係る管理データ改善装置のシステム構成の一例を示す。なお、本実施形態に係る管理データ改善装置は、ユーザによって使用される例えばパーソナルコンピュータ（ＰＣ）等であるが、他の電子機器であってもよい。ここでは、管理データ改善装置がパーソナルコンピュータである場合について説明する。
【００４０】
図３に示すように、管理データ改善装置１０は、ＣＰＵ１１、システムコントローラ１２、主メモリ１３、ＢＩＯＳ−ＲＯＭ１４、不揮発性メモリ１５、入力デバイス１６、表示デバイス１７及びエンベデッドコントローラ（ＥＣ）１８等を備える。
【００４１】
ＣＰＵ１１は、管理データ改善装置１０内の各コンポーネントの動作を制御するプロセッサである。ＣＰＵ１１は、ストレージデバイスである不揮発性メモリ１５から主メモリ１３にロードされる様々なプログラムを実行する。これらプログラムには、オペレーティングシステム（ＯＳ）及び上記したようにソースコードのバージョン（構成）を管理するためのプログラム（以下、構成管理プログラムと表記）等が含まれている。
【００４２】
また、ＣＰＵ１１は、ＢＩＯＳ−ＲＯＭ１４に格納された基本入出力システム（ＢＩＯＳ）も実行する。ＢＩＯＳは、ハードウェア制御のためのプログラムである。
【００４３】
システムコントローラ１２は、ＣＰＵ１１のローカルバスと各種コンポーネントとの間を接続するデバイスである。
【００４４】
入力デバイス１６は、例えばキーボード及びマウス等を含む。表示デバイス１７は、例えば液晶表示装置のようなディスプレイ等を含む。ＥＣ１８は、電力管理のためのエンベデッドコントローラを含むワンチップマイクロコンピュータである。
【００４５】
なお、図３においてはＣＰＵ１１、システムコントローラ１２、主メモリ１３、ＢＩＯＳ−ＲＯＭ１４、不揮発性メモリ１５、入力デバイス１６、表示デバイス１７及びＥＣ１８のみが示されているが、管理データ改善装置１０は、例えばＨＤＤ（Hard Disk Drive）及びＳＳＤ（Solid State Drive）のような他の記憶装置を備えていてもよいし、外部装置との通信を実行するように構成された通信デバイス等を備えていてもよい。
【００４６】
図４は、管理データ改善装置１０の機能構成の一例を示すブロック図である。図４に示すように、管理データ改善装置１０は、格納部１０１、コミット粒度評価部１０２、分割候補作成部１０３、結合候補作成部１０４、妥当性判定部１０５、候補評価部１０６及び候補提示部１０７を含む。
【００４７】
本実施形態において、格納部１０１は、例えば図３に示す不揮発性メモリ１５または他の記憶装置を用いて実現される。
【００４８】
また、本実施形態において、各部１０２〜１０７の一部または全ては、例えば図３に示すＣＰＵ１１（つまり、管理データ改善装置１０のコンピュータ）に上記した構成管理プログラムを実行させること、すなわちソフトウェアによって実現されるものとする。なお、構成管理プログラムは、コンピュータ読み取り可能な記憶媒体に予め格納して頒布可能である。また、構成管理プログラムは、例えばネットワークを介して管理データ改善装置１０にダウンロードされても構わない。
【００４９】
ここでは、各部１０２〜１０７の一部または全てがソフトウェアによって実現されるものとして説明したが、当該各部１０２〜１０７の一部または全ては、例えばＩＣ等のハードウェアによって実現されてもよいし、ソフトウェア及びハードウェアの組み合わせ構成として実現されてもよい。
【００５０】
格納部１０１は、ユーザによって作成されたソースコード（新たなバージョンのソースコード）がコミットされた場合に、当該ソースコード（ファイル）と、当該ソースコードよりも前にコミットされたソースコード（直前のソースコード）からの変更箇所を示すデータ（以下、コミットデータと表記）とを対応づけて格納（記録）する。
【００５１】
コミット粒度評価部１０２は、格納部１０１に格納されているコミットデータを取得する。コミット粒度評価部１０２は、取得されたコミットデータによって示される変更箇所の依存関係を解析し、当該変更箇所に関するコミットの粒度が適切であるか否かを評価する。なお、コミット粒度評価部１０２は、コミットの粒度が適切でない場合には、コミットの粒度が大きいまたはコミットの粒度が小さいと評価（判定）する。
【００５２】
分割候補作成部１０３は、コミット粒度評価部１０２によってコミットの粒度が大きいと評価された場合、当該コミットの分割候補を作成する。分割候補作成部１０３は、例えばコミット粒度評価部１０２によって取得されたコミットデータが第１及び第２変更箇所を示す場合、当該第１変更箇所を示すコミットデータ及び当該第２変更箇所を示すコミットデータを分割候補として作成する。
【００５３】
結合候補作成部１０４は、コミット粒度評価部１０２によってコミットの粒度が小さいと評価された場合、当該コミットの結合候補を作成する。結合候補作成部１０４は、例えばコミット粒度評価部１０２によって取得されたコミットデータ（によって示される変更箇所）と当該コミットデータよりも後に格納部１０１に格納されたコミットデータ（によって示される変更箇所）とを結合したコミットデータを結合候補として作成する。なお、コミット粒度評価部１０２によって取得されたコミットデータよりも後に格納部１０１に格納されたコミットデータとは、コミット粒度評価部１０２によって取得されたコミットデータに対応づけて格納部１０１に格納されているソースコード（以下、当該コミットデータに対応するソースコード）よりも後に作成されたソースコードがコミットされた場合に格納部１０１に格納されたコミットデータである。
【００５４】
妥当性判定部１０５は、分割候補作成部１０３によって作成されたコミットデータ（以下、単に分割候補と表記）によって示される変更箇所の変更内容を含むソースコードにおける文法エラーの有無に基づいて当該コミットデータの妥当性（つまり、当該コミットデータが妥当であるか否か）を判定する。
【００５５】
同様に、妥当性判定部１０５は、結合候補作成部１０４によって作成されたコミットデータ（以下、単に結合候補と表記）によって示される変更箇所の変更内容を含むソースコードにおける文法エラーの有無に基づいて当該コミットデータの妥当性を判定する。
【００５６】
なお、分割候補または結合候補によって示される変更箇所の変更内容を含むソースコードとは、上記したコミット粒度評価部１０２によって取得されたコミットデータに対応するソースコードの直前のソースコードに対して、分割候補または結合候補によって示される変更箇所の変更内容が反映されたソースコードをいうものとする。また、分割候補または結合候補によって示される変更箇所の変更内容は、例えばコミット粒度評価部１０２によって取得されたコミットデータに対応するソースコードから特定することができる。
【００５７】
候補評価部１０６は、分割候補または結合候補が妥当であると妥当性判定部１０５によって判定された場合、当該分割候補または結合候補の評価値を、当該分割候補または結合候補によって示される変更箇所に基づいて算出する。
【００５８】
候補提示部１０７は、候補評価部１０６によって算出された評価値に基づいて、分割候補または結合候補を例えばユーザに対して提示する。この場合、分割候補または結合候補は、上記した図３に示す表示デバイス１７等に表示される。
【００５９】
図５を参照して、図４に示す格納部１０１に格納されているコミットデータのデータ構造の一例について説明する。
【００６０】
図５に示すように、コミットデータは、例えばコミットＩＤ、変更ファイル名及び変更行の対応付けを含む。コミットＩＤは、ソースコードがコミットされた場合に当該コミットに割り当てられ、当該コミットを識別するための識別子として用いられる。
【００６１】
変更ファイル名は、コミットでソースコードの変更があったファイルのファイル名を示す。
【００６２】
変更行は、コミットで変更されたソースコードにおいて直前のソースコードから変更されている行の位置（例えば、行番号等）を示す。
【００６３】
ここで、図５に示す例では、格納部１０１には、コミットデータ１０１ａ〜１０１ｃが格納されている。
【００６４】
コミットデータ１０１ａは、コミットＩＤ「コミット１」、変更ファイル名「ｆ１」及び変更行「変更行１」の対応付けを含む。また、コミットデータ１０１ａは、コミットＩＤ「コミット１」、変更ファイル名「ｆ２」及び変更行「変更行２」の対応付けを含む。更に、コミットデータ１０１ａは、コミットＩＤ「コミット１」、変更ファイル名「ｆ２」及び変更行「変更行３」の対応付けを含む。
【００６５】
このコミットデータ１０１ａによれば、「変更行１」によって示される行が変更されたファイル名が「ｆ１」であるソースファイル内のソースコードと、「変更行２」及び「変更行３」によって示される行が変更されたファイル名が「ｆ２」であるソースファイル内のソースコードとがコミットされ、当該コミットにはコミットＩＤ「コミット１」が割り当てられていることが示されている。
【００６６】
換言すれば、コミットデータ１０１ａは、ファイル名が「ｆ１」であるソースファイル内のソースコードの「変更行１」によって示される行と、ファイル名が「ｆ２」であるソースファイル内のソースコードの「変更行２」及び「変更行３」によって示される行とが直前のソースコードから変更されていることを示している。
【００６７】
コミットデータ１０１ｂは、コミットＩＤ「コミット２」、変更ファイル名「ｆ１」及び変更行「変更行４」の対応付けを含む。また、コミットデータ１０１ｂは、コミットＩＤ「コミット２」、変更ファイル名「ｆ３」及び変更行「変更行５」の対応付けを含む。更に、コミットデータ１０１ｂは、コミットＩＤ「コミット２」、変更ファイル名「ｆ３」及び変更行「変更行６」の対応付けを含む。
【００６８】
このコミットデータ１０１ｂによれば、「変更行４」によって示される行が変更されたファイル名が「ｆ１」であるソースファイル内のソースコードと、「変更行５」及び「変更行６」によって示される行が変更されたファイル名が「ｆ３」であるソースファイル内のソースコードとがコミットされ、当該コミットにはコミットＩＤ「コミット２」が割り当てられていることが示されている。
【００６９】
換言すれば、コミットデータ１０１ｂは、ファイル名が「ｆ１」であるソースファイル内のソースコードの「変更行４」によって示される行と、ファイル名が「ｆ３」であるソースファイル内のソースコードの「変更行５」及び「変更行６」によって示される行とが直前のソースコードから変更されていることを示している。
【００７０】
コミットデータ１０１ｃは、コミットＩＤ「コミット３」、変更ファイル名「ｆ４」及び変更行「変更行７」の対応付けを含む。
【００７１】
このコミットデータ１０１ｃによれば、「変更行７」によって示される行が変更されたファイル名が「ｆ４」であるソースファイル内のソースコードがコミットされ、当該コミットにはコミットＩＤ「コミット３」が割り当てられていることが示されている。
【００７２】
換言すれば、コミットデータ１０１ｃは、ファイル名が「ｆ４」であるソースファイル内のソースコードの「変更行７」によって示される行が直前のソースコードから変更されていることを示している。
【００７３】
本実施形態においては、上記したコミットデータ１０１ａ〜１０１ｃに含まれる変更ファイル名及び変更行によって、コミットされたソースコードの直前のソースコードからの変更箇所を示している。
【００７４】
また、本実施形態においては、コミットデータ１０１ａ及び１０１ｂに示すように複数のソースファイル内の複数のソースコードがまとめてコミットされてもよいし、コミットデータ１０１ｃに示すように１つのソースファイル内の１つのソースコードのみがコミットされてもよい。
【００７５】
なお、図５においては便宜的にコミットデータ１０１ａ〜１０１ｃのみが示されているが、格納部１０１には、ソースコードがコミットされる度にコミットデータが格納（記録）される。
【００７６】
また、図５においては省略されているが、格納部１０１には、例えばコミットデータに対応づけて、当該コミットデータが格納部１０１に格納された日時（つまり、ソースコードがコミットされた日時）を示す情報等が更に格納されていてもよい。
【００７７】
次に、図６のフローチャートを参照して、本実施形態に係る管理データ改善装置１０の処理手順の一例について説明する。ここでは、格納部１０１には、複数のコミットデータが格納されているものとする。
【００７８】
まず、コミット粒度評価部１０２は、格納部１０１に格納されている複数のコミットデータの中から、コミットの粒度を判定する対象となるコミットデータ（以下、対象コミットデータと表記）を取り出す（ステップＳ１）。
【００７９】
なお、ステップＳ１において取り出される対象コミットデータは、例えばユーザによって指定されたコミット番号を含むコミットデータであってもよいし、上記したようにコミットデータが格納部１０１に格納された日時を示す情報が当該格納部１０１に格納されている場合にはユーザによって指定された日時等によって特定されるコミットデータであってもよい。
【００８０】
次に、コミット粒度評価部１０２は、ステップＳ１において取り出された対象コミットデータによって示される変更箇所に基づいて粒度評価処理を実行する（ステップＳ２）。このステップＳ２における粒度評価処理の結果には、「コミットの粒度が適切」、「コミットの粒度が大きい」、または「コミットの粒度が小さい」が含まれる。なお、粒度評価処理の詳細については後述する。
【００８１】
ステップＳ２の処理が実行されると、当該ステップＳ２における粒度評価処理の結果が「コミットの粒度が小さい」であるか否かが判定される（ステップＳ３）。
【００８２】
粒度評価処理の結果が「コミットの粒度が小さい」でないと判定された場合（ステップＳ３のＮＯ）、当該粒度評価処理の結果が「コミットの粒度が大きい」であるか否かが判定される（ステップＳ４）。
【００８３】
粒度評価処理の結果が「コミットの粒度が大きい」であると判定された場合（ステップＳ４のＹＥＳ）、分割候補作成部１０３は、対象コミットデータによって示される変更箇所を分割し、当該分割された変更箇所の各々を示すコミットデータを分割候補として作成する（ステップＳ５）。
【００８４】
以下、ステップＳ５の処理について具体的に説明する。ここでは、分割候補作成部１０３は、対象コミットデータ（によって示される変更箇所）をファイル単位で分割することによって分割候補を作成するものとし、例えばファイル名が「ｆ１」〜「ｆ４」の４つのソースファイル内のソースコードの各々が直前のソースコードから変更されてコミットされたものとして説明する。
【００８５】
なお、この場合における対象コミットデータには、変更ファイル名「ｆ１」〜「Ｆ４」の各々に対応づけて、ファイル名が「ｆ１」〜「ｆ４」のソースファイル内のソースコードにおいて直前のソースコードから変更されている行を示す変更行が含まれている。
【００８６】
以下の説明において、ソースコードが変更されたファイル名が「ｆ１」〜「ｆ４」のソースファイルをそれぞれ変更ファイルｆ１〜ｆ４と称する。
【００８７】
まず、分割候補作成部１０３は、上記した変更ファイル名「ｆ１」〜「ｆ４」の各々に対応づけて対象コミットデータに含まれている変更行に基づいて変更ファイルｆ１〜ｆ４を変更行の数が少ない順に並べ、当該変更ファイルｆ１〜ｆ４の各々の組み合わせを分割候補の一方とし、当該組み合わせの残りの変更ファイル（の組み合わせ）を分割候補の他方とする。
【００８８】
具体的には、例えば変更ファイルｆ１〜ｆ４のうちの変更ファイルｆ１及びｆ２の組み合わせを分割候補の一方とした場合、残りの変更ファイルｆ３及びｆ４の組み合わせを分割候補の他方とする。
【００８９】
この場合、分割候補作成部１０３は、変更ファイルｆ１及びｆ２内の各ソースコードの変更箇所を示すコミットデータを分割候補の一方のコミットデータとして作成する。なお、変更ファイルｆ１及びｆ２内の各ソースコードの変更箇所を示すコミットデータとは、変更ファイル名「ｆ１」及び変更ファイルｆ１内のソースコードにおいて直前のソースコードから変更されている行を示す変更行を含み、かつ、変更ファイル名「ｆ２」及び変更ファイルｆ２内のソースコードにおいて直前のソースコードから変更されている行を示す変更行を含むコミットデータである。
【００９０】
一方、分割候補作成部１０３は、変更ファイルｆ３及びｆ４内の各ソースコードの変更箇所を示すコミットデータを分割候補の他方のコミットデータとして作成する。なお、変更ファイルｆ３及びｆ４内の各ソースコードの変更箇所を示すコミットデータとは、変更ファイル名「ｆ３」及び変更ファイルｆ３内のソースコードにおいて直前のソースコードから変更されている行を示す変更行を含み、かつ、変更ファイル名「ｆ４」及び変更ファイル名ｆ４内のソースコードにおいて直前のソースコードから変更されている行を示す変更行を含むコミットデータである。
【００９１】
これによれば、変更ファイルｆ１及びｆ２内の各ソースコードの変更箇所を示すコミットデータ及び変更ファイルｆ３及びｆ４内の各ソースコードの変更箇所を示すコミットデータの組み合わせが分割候補として作成される。
【００９２】
ここでは、変更ファイルｆ１及びｆ２を分割候補の一方とし、残りの変更ファイルｆ３及びｆ４を分割候補の他方とした１つ（１組）の分割候補について説明したが、ステップＳ５においては、変更ファイルｆ１〜ｆ４の全てからなる組み合わせ（つまり、｛ｆ１，ｆ２，ｆ３，ｆ４｝）を除く変更ファイルｆ１〜ｆ４の全ての組み合わせ（例えば、｛ｆ１｝、｛ｆ１，ｆ２｝、｛ｆ１，ｆ３｝、｛ｆ１，ｆ２，ｆ３｝、｛ｆ２，ｆ３｝、…等）を分割候補の一方とし、残りの変更ファイルの組み合わせを分割候補の他方とする複数の分割候補が作成される。
【００９３】
以下、ステップＳ５において作成された複数の分割候補の各々における、分割候補の一方のコミットデータを第１分割候補コミットデータ、分割候補の他方のコミットデータを第２分割候補コミットデータと称する。また、第１分割候補コミットデータ及び第２分割候補コミットデータの組み合わせを分割候補と称する。
【００９４】
次に、妥当性判定部１０５は、ステップＳ５において作成された複数の分割候補の各々の妥当性を判定する（ステップＳ６）。
【００９５】
ステップＳ６においては、分割候補毎に、第１分割候補コミットデータによって示される変更箇所の変更内容を含むソースコード（以下、第１分割候補コミットデータに対応するソースコードと表記）における文法エラーの有無が判定（チェック）され、第２分割候補コミットデータによって示される変更箇所の変更内容を含むソースコード（以下、第２分割候補コミットデータに対応するソースコードと表記）における文法エラーの有無が判定（チェック）される。
【００９６】
この場合、各ソースコードに対してコンパイラを起動し、当該コンパイラからエラー（文法エラー）が返されない場合には当該ソースコードに文法エラーがないと判定され、当該コンパイラからエラーが返された（つまり、ソースコードが文法エラーによって動作しない）場合には当該ソースコードに文法エラーがあると判定される。なお、ソースコードにおける文法エラーの有無を判定する手法はこれに限られない。
【００９７】
これによれば、第１分割候補コミットデータに対応するソースコード及び第２分割候補コミットデータに対応するソースコードの両方に文法エラーがないと判定された場合、当該第１分割候補コミットデータ及び当該第２分割候補コミットデータの組み合わせの分割候補は妥当である（つまり、妥当性を有する）と判定される。
【００９８】
一方、第１分割候補コミットデータに対応するソースコード及び第２分割候補コミットデータに対応するソースコードのうちの少なくとも一方に文法エラーがある（つまり、少なくとも一方が文法エラーによって動作しない）と判定された場合、当該第１分割候補コミットデータ及び当該第２分割候補コミットデータの組み合わせの分割候補は妥当でない（つまり、妥当性を有しない）と判定される。
【００９９】
ここで、例えば第１分割候補コミットデータが変更ファイルｆ１及びｆ２内のソースコードの変更箇所を示すコミットデータであり、第２分割候補コミットデータが変更ファイルｆ３及びｆ４内のソースコードの変更箇所を示すコミットデータであるものとする。この場合、第１分割候補コミットデータに対応するソースコード（つまり、変更ファイルｆ１内のソースコード及び変更ファイルｆ２内のソースコード）に文法エラーがなく、かつ、第２分割候補コミットデータに対応するソースコード（つまり、変更ファイルｆ３内のソースコード及び変更ファイルｆ４内のソースコード）にも文法エラーがない場合に、分割候補が妥当であると判定される。一方、第１分割候補コミットデータに対応するソースコード（変更ファイルｆ１内のソースコード及び変更ファイルｆ２内のソースコードの少なくとも一方）に文法エラーがある、または、第２分割候補コミットデータに対応するソースコード（変更ファイルｆ３内のソースコード及び変更ファイルｆ４内のソースコードの少なくとも一方）に文法エラーがある場合、分割候補は妥当でないと判定される。
【０１００】
次に、候補評価部１０６は、上記したステップＳ６において妥当であると判定された分割候補の各々に対して評価値を算出する（ステップＳ７）。
【０１０１】
この場合、候補評価部１０６は、分割候補の第１分割候補コミットデータに含まれる変更行によって示される行の数（第１分割候補コミットデータにおける変更行数）を当該分割候補の評価値として算出するものとする。
【０１０２】
なお、ステップＳ６において妥当でないと判定された分割候補はステップＳ７の処理の対象とはならない（つまり、評価値は算出されない）。
【０１０３】
次に、候補提示部１０７は、ステップＳ６において妥当であると判定された分割候補（第１及び第２分割候補コミットデータ）を、ステップＳ７において算出された評価値に基づいてユーザに対して提示（表示）する（ステップＳ８）。
【０１０４】
ここで、本実施形態においては、ステップＳ７において算出された評価値が小さいほど評価が高いことを表すものとする。すなわち、ステップＳ８においては、例えば上記した第１分割候補コミットデータにおける変更行数が少ない分割候補が優先的に（つまり、上位に）提示されるものとする。
【０１０５】
なお、ステップＳ８においては、ステップＳ６において妥当であると判定された分割候補の全てを提示してもよいし、当該分割候補のうちの予め定められた数のみを提示してもよい。また、評価値（変更行数）が予め定められた値以下の分割候補のみを提示するようにしてもよい。
【０１０６】
例えばステップＳ８において複数の分割候補がユーザに対して提示された場合、当該ユーザは、管理データ改善装置１０（入力デバイス１６）を操作することによって、当該複数の分割候補のうちの１つを選択（指定）することができる。ユーザによって分割候補が選択された場合、格納部１０１に格納されている対象コミットデータは、分割候補に基づいて第１分割候補コミットデータ及び第２分割候補コミットデータに分割される。
【０１０７】
ここでは、ユーザによって分割候補が選択された場合に対象コミットデータが分割されるものとして説明したが、対象コミットデータは、例えば評価値が最も小さい（第１分割候補コミットデータにおける変更行数が最も少ない）分割候補に基づいて自動的に分割されてもよい。
【０１０８】
一方、上記したステップＳ３において「コミットの粒度が小さい」であると判定された場合（ステップＳ３のＹＥＳ）、結合候補作成部１０４は、対象コミットデータによって示される変更箇所及び当該対象コミットデータに対応するソースコードよりも後に作成されたソースコードがコミットされた際に格納部１０１に格納されたコミットデータ（以下、対象コミットデータの後のコミットデータと表記）によって示される変更箇所を示すコミットデータを結合候補として作成する（ステップＳ９）。
【０１０９】
以下、ステップＳ９の処理について具体的に説明する。ここでは、対象コミットデータを対象コミットデータＣｎ、当該対象コミットデータＣｎの後のコミットデータをコミットデータＣｎ＋１とする。また、コミットデータＣｎ＋１の更に後のコミットデータをコミットデータＣｎ＋２とする。
【０１１０】
この場合、結合候補作成部１０４は、対象コミットデータＣｎによって示される変更箇所（変更ファイル名及び変更行）とコミットデータＣｎ＋１によって示される変更箇所（変更ファイル名及び変更行）とを示すコミットデータを結合候補として作成する。
【０１１１】
更に、結合候補作成部１０４は、対象コミットデータＣｎによって示される変更箇所と、コミットデータＣｎ＋１によって示される変更箇所と、コミットデータＣｎ＋２によって示される変更箇所を含むコミットデータを結合候補として作成する。
【０１１２】
ここでは、対象コミットデータＣｎ、コミットデータＣｎ＋１及びコミットデータＣｎ＋２から結合候補を作成するものとして説明したが、例えばコミットデータＣｎ＋２の後のコミットデータが格納部１０１に格納されている場合には、同様に結合候補が作成される。すなわち、上記したように対象コミットデータをＣｎ、当該対象コミットデータＣｎより後のコミットデータをＣｎ＋１、Ｃｎ＋２、…とすると、ステップＳ９においては、｛Ｃｎ，Ｃｎ＋１｝、｛Ｃｎ，Ｃｎ＋１，Ｃｎ＋２｝、｛Ｃｎ，Ｃｎ＋１，Ｃｎ＋２，…｝のような複数のコミットデータの組み合わせから複数の結合候補が作成される。
【０１１３】
次に、妥当性判定部１０５は、ステップＳ９において作成された複数の結合候補の各々の妥当性を判定する（ステップＳ１０）。
【０１１４】
なお、このステップＳ１０の処理は、上記したステップＳ６の処理に相当する処理である。すなわち、ステップＳ１０においては、結合候補の各々によって示される変更箇所の変更内容を含むソースコード（以下、結合候補に対応するソースコードと表記）における文法エラーの有無が判定される。
【０１１５】
これによれば、結合候補に対応するソースコードに文法エラーがないと判定された場合、当該結合候補は妥当である（つまり、妥当性を有する）と判定される。一方、結合候補に対応するソースコードに文法エラーがある（つまり、ソースコードが文法エラーによって動作しない）と判定された場合、当該結合候補は妥当でない（つまり、妥当性を有しない）と判定される。
【０１１６】
次に、候補評価部１０６は、ステップＳ１０において妥当であると判定された結合候補の各々に対して評価値を算出する（ステップＳ１１）。
【０１１７】
ステップＳ１１の処理は、上記したステップＳ７の処理に相当する処理である。すなわち、ステップＳ１１において、候補評価部１０６は、結合候補に含まれる変更行によって示される行の数（結合候補における変更行数）を評価値として算出するものとする。
【０１１８】
なお、ステップＳ１０において妥当でないと判定された結合候補はステップＳ１１の処理の対象とはならない（つまり、評価値は算出されない）。
【０１１９】
ステップＳ１１の処理が実行されると、上記したステップＳ８の処理が実行される。この場合、候補提示部１０７は、ステップＳ１０において妥当であると判定された結合候補を、ステップＳ１１において算出された評価値に基づいてユーザに対して提示（表示）する。
【０１２０】
例えばステップＳ８において複数の結合候補がユーザに対して提示された場合、当該ユーザは、管理データ改善装置１０（入力デバイス１６）を操作することによって、当該複数の結合候補のうちの１つを選択（指定）することができる。ユーザによって結合候補が選択された場合、格納部１０１に格納されている対象コミットデータは、結合候補に基づいて例えば当該対象コミットデータの後のコミットデータと結合される。
【０１２１】
ここでは、ユーザによって結合候補が選択された場合に対象コミットデータが結合されるものとして説明したが、対象コミットデータは、例えば評価値が最も小さい（結合候補における変更行数が最も少ない）結合候補に基づいて自動的に結合されてもよい。
【０１２２】
一方、ステップＳ４において「コミットの粒度が大きい」でない（つまり、「コミットの粒度が適切」である）と判定された場合（ステップＳ４のＮＯ）、図６に示す処理は終了される。なお、この場合には、例えば対象コミットデータによって示される変更箇所に関するコミットの粒度が適切である旨がユーザに対して提示されてもよい。
【０１２３】
上記した図６に示す処理によれば、格納部１０１に格納されているコミットデータ（によって示される変更箇所）に基づいて当該変更箇所に関するコミットの粒度が適切であるか否かを評価し、当該コミットの粒度が大きい場合には分割候補をユーザに提示し、当該コミットの粒度が小さい場合には結合候補に提示することができる。
【０１２４】
なお、図６に示すステップＳ６及びＳ１０においてはコミットデータ（分割候補及び結合候補）によって示される変更箇所の変更内容を含むソースコードに文法エラーがない場合に当該コミットデータが妥当であると判定されるものとして説明したが、当該ステップＳ６及びＳ１０の処理においては、ユニットテストが用いられてもよい。
【０１２５】
ユニットテストは、ソースコードに含まれる関数や関数群の正しさをチェックするために用意されるテストするものであり、例えば当該ソースコードに文法エラーがない場合に自動もしくは手動で実行され、対象の関数や関数群をテストするものである。
【０１２６】
これによれば、上記したステップＳ６及びＳ１０においては、ソースコードに文法エラーがなく、かつ、ユニットテストに合格した場合にコミットデータ（分割候補及び結合候補）が妥当であると判定されるようにしてもよい。すなわち、例えばソースコードに文法エラーがないであっても、ユニットテストに合格しない場合には、コミットデータは妥当でないと判定されるようにしてもよい。
【０１２７】
また、図６に示すステップＳ９においては、対象コミットデータ及び当該対象コミットデータの後のコミットデータを用いて結合候補を作成するものとして説明したが、対象コミットデータ及び当該対象コミットデータに対応するソースコードよりも前に作成されたソースコードがコミットされた際に格納部１０１に格納されたコミットデータ（以下、対象コミットデータの前のコミットデータと表記）を用いて結合候補を作成してもよい。
【０１２８】
また、例えばステップＳ９において対象コミットデータ及び当該対象コミットデータの後のコミットデータを用いて結合候補を作成し、ステップＳ１０において例えば当該結合候補の全てが妥当でないと判定された場合に、ステップＳ９に戻って対象コミットデータ及び当該対象コミットデータの前のコミットデータを用いて結合候補を再度作成するような構成とすることも可能である。
【０１２９】
同様に、例えばステップＳ９において対象コミットデータ及び当該対象コミットデータの前のコミットデータを用いて結合候補を作成し、ステップＳ１０において例えば当該結合候補の全てが妥当でないと判定された場合に、ステップＳ９に戻って対象コミットデータ及び当該対象コミットデータの後のコミットデータを用いて結合候補を再度作成するような構成であってもよい。
【０１３０】
また、図６に示す例では、ステップＳ１において１つのコミットデータが取り出されるものとして説明したが、当該ステップＳ１において複数のコミットデータが取り出され、当該複数のコミットデータの各々についてステップＳ２以降の処理が実行されても構わない。
【０１３１】
また、図６に示す例ではステップＳ１〜Ｓ１１の処理が実行された場合には処理が終了されるものとして説明したが、例えば対象コミットデータが他のコミットデータ（当該対象コミットデータの前または後のコミットデータ）と結合された場合、当該結合された後のコミットデータに対して再度ステップＳ２以降の処理が実行されてもよい。これによれば、コミットデータの結合によってコミットの粒度が大きくなった場合に、当該コミットの粒度が適切となるように当該コミットデータを更に分割するようなことが可能となる。
【０１３２】
次に、図７のフローチャートを参照して、上記した粒度評価処理（図６に示すステップＳ２の処理）の処理手順の一例について説明する。なお、粒度評価処理は、上記したようにコミット粒度評価部１０２によって実行される。
【０１３３】
まず、コミット粒度評価部１０２は、対象コミットデータ（図６に示すステップＳ１において取り出されたコミットデータ）に対応づけて格納部１０１に格納されているソースコードを取得する（ステップＳ２１）。なお、ステップＳ２１において取得されるソースコード（以下、対象ソースコードと表記）は、対象コミットデータが格納部１０１に格納される際にコミットされたソースコードである。
【０１３４】
次に、コミット粒度評価部１０２は、対象ソースコードにおける文法エラーの有無を判定する（ステップＳ２２）。ステップＳ２２においては、例えば対象ソースコードに対してコンパイラを起動し、当該コンパイラからエラーが返されない場合には対象ソースコードに文法エラーがないと判定され、当該コンパイラからエラーが返される場合には対象ソースコードに文法エラーがあると判定される。
【０１３５】
対象ソースコードに文法エラーがないと判定された場合（ステップＳ２２のＹＥＳ）、コミット粒度評価部１０２は、対象コミットデータによって示される変更箇所の依存関係（依存性）を解析する（ステップＳ２３）。
【０１３６】
なお、本実施形態においては、上記したように対象コミットデータをファイル単位で分割する。このため、本実施形態における依存関係とは、ファイル単位の依存関係であり、各変更箇所において同一のファイルるの変更は依存しており、異なるファイルの変更は依存していないとする。
ここで、上記したように対象コミットデータは複数の変更箇所を示す場合があるが、ステップＳ２３において対象コミットデータによって示される変更箇所の依存関係が解析された場合、例えば当該複数の変更箇所の間に依存関係がある（当該複数の変更箇所が依存する）、または、当該複数の変更箇所の間に依存関係がない（つまり、複数の変更箇所は独立である）等の解析結果を得ることができる。
【０１３７】
ステップＳ２３の処理が実行されると、コミット粒度評価部１０２は、当該ステップＳ２３の処理の結果（つまり、依存関係の解析結果）に基づいて、対象コミットデータによって示される複数の変更箇所の間に依存関係があるか否かを判定する（ステップＳ２４）。
【０１３８】
ここで、対象コミットデータによって示される複数の変更箇所の間に依存関係がある（すなわち、当該複数の変更箇所の全てが依存している）と判定された場合を想定する（ステップＳ２４のＹＥＳ）。この場合、上記したように対象ソースコードに文法エラーがないため、当該対象ソースコードに他のコミットデータによって示される変更箇所の変更内容を追加する（つまり、対象コミットデータを他のコミットデータと結合する）必要はない。また、対象コミットデータによって示される全ての変更箇所の間に依存関係があるため、対象コミットデータによって示される複数の変更箇所の中に分割することができるものもない。よって、コミット粒度評価部１０２は、粒度評価処理の結果として「コミットの粒度が適切」を返す（ステップＳ２５）。
【０１３９】
一方、対象コミットデータによって示される複数の変更箇所の間に依存関係がない（すなわち、当該複数の変更箇所の中に他の変更箇所から独立しているものがある）と判定された場合を想定する（ステップＳ２４のＮＯ）。この場合、上記したように対象ソースコードに文法エラーがないため、対象ソースコードに他のコミットデータによって示される変更箇所の変更内容を追加する（つまり、対象コミットデータを他のコミットデータと結合する）必要はない。一方、対象コミットデータによって示される複数の変更箇所の中には他の変更箇所から独立しているものがあるため、少なくとも当該独立している変更箇所（を示すコミットデータ）については対象コミットデータから分割することができる。よって、コミット粒度評価部１０２は、粒度評価処理の結果として「コミットの粒度が大きい」を返す（ステップＳ２６）。
【０１４０】
また、ステップＳ２２において対象ソースコードに文法エラーがあると判定された場合を想定する（ステップＳ２２のＮＯ）。この場合、対象ソースコードを文法エラーがない状態にする（つまり、例えば機能追加等に関する変更が完了した状態にする）ためには、少なくとも他のコミットデータによって示される変更箇所の変更内容を追加する（つまり、対象コミットデータを他のコミットデータと結合する）必要がある。よって、コミット粒度評価部１０２は、粒度評価処理の結果として「コミットの粒度が小さい」を返す（ステップＳ２７）。
【０１４１】
上記した図７に示す処理によれば、対象ソースコードにおける文法エラーの有無及び対象コミットデータによって示される変更箇所の依存関係の解析結果に基づいて当該変更箇所に関するコミットの粒度を評価（判定）することができる。
【０１４２】
なお、ステップＳ２２においては対象ソースコードにおける文法エラーの有無を判定するものとして説明したが、上記したユニットテストに合格しているか否かを更に判定する構成としてもよい。このような構成においては、対象ソースコードに文法エラーがなく、かつ、ユニットテストに合格している場合に、ステップＳ２３の処理が実行されればよい。一方、対象ソースコードに文法エラーがある場合、または、ユニットテストに合格していない場合には、ステップＳ２７の処理が実行されればよい。
【０１４３】
上記したように本実施形態においては、ユーザによって作成されたソースコード（第１ソースコード）がコミットされた場合に、当該ソースコードよりも前にコミットされたソースコード（第２ソースコード）からの変更箇所を示すコミットデータ（第１コミットデータ）が格納部１０１に格納され、格納部１０１から取り出された対象コミットデータによって示される変更箇所の依存関係の解析結果に基づいて、当該変更箇所に関するコミットの粒度が適切であるか否かを評価する。
【０１４４】
ここで、上記した図６においては粒度評価処理が実行されることによって評価されたコミットの粒度に応じて分割候補または結合候補がユーザに対して提示されるものとして説明したが、本実施形態に係る管理データ改善装置１０は、当該粒度評価処理の結果（つまり、コミットの粒度が適切であるか否か）をユーザに提示する構成であってもよい。このような構成によれば、例えばコミットの粒度が大きいまたはコミットの粒度が小さいことをユーザが把握することができるため、当該ユーザは、対象コミットデータが適切なコミットデータ（つまり、適切な粒度）となるように修正（分割及び結合）することが可能である。このように適切な粒度となるようにコミットデータが修正された場合には、ユーザは、例えば機能単位でソースコードが変更された経緯または任意のバージョンのソースコードを確認する（レビューする）ことが可能となるため、ユーザの利便性を向上させることができる。
【０１４５】
なお、本実施形態においては、対象コミットデータによって示される第１及び第２変更箇所の間に依存関係があるか否かを判定し、当該第１及び第２変更箇所の間に依存関係がないと判定された場合にコミットの粒度が大きいと評価する。
【０１４６】
また、本実施形態においては、対象コミットデータによって示される第１及び第２変更箇所の間に依存関係があると判定され、当該対象コミットデータに対応するソースコード（当該コミットデータが格納部１０１に格納された際にコミットされたソースコード）に文法エラーがある場合には、コミットの粒度が小さいと評価する。
【０１４７】
更に、本実施形態においては、対象コミットデータによって示される第１及び第２変更箇所の間に依存関係があると判定され、当該対象コミットデータに対応するソースコードに文法エラーがない場合には、コミットの粒度が適切であると評価する。
【０１４８】
本実施形態においては、このような構成により、対象コミットデータによって示される第１及び第２変更箇所の間の依存関係の解析結果及び当該対象コミットデータに対応するソースコードにおける文法エラーの有無に応じてコミットの粒度を適切に評価することが可能となる。
【０１４９】
なお、本実施形態においては、例えばソースコード中に出現する変数の値を変更すると、第１及び第２変更箇所に対応する処理または値に変化が起こる可能性がある場合に当該第１及び第２変更箇所の間に依存関係があると判定する。
【０１５０】
また、本実施形態においては、例えば第１変更箇所に対応する処理または値に変化が起こる可能性があるソースコード中に出現する変数の第１集合を特定し、第２変更箇所に対応する処理または値に変化が起こる可能性があるソースコード中に出現する変数の第２集合を特定し、当該第１及び第２集合のうちの少なくとも一部が重複する場合に第１及び第２変更箇所の間に依存関係があると判定する。
【０１５１】
本実施形態においては、このような構成により、対象コミットデータによって示される第１及び第２変更箇所の依存関係を適切に判定することができ、上記したコミットの粒度の評価精度を向上させることが可能となる。
【０１５２】
また、本実施形態においては、コミットの粒度が大きいと評価された場合、上記したように対象コミットデータによって示される複数の変更箇所のうちの第１変更箇所を示す第１分割候補コミットデータ（第２コミットデータ）及び当該複数の変更箇所のうちの第２変更箇所を示す第２分割候補コミットデータ（第３コミットデータ）を分割候補としてユーザに提示する構成であってもよい。このような構成によれば、コミットの粒度が大きい場合に対象コミットデータの分割候補を自動的に作成し、当該コミットの粒度が適切になるように当該対象コミットデータを分割することをユーザに促すことができる。
【０１５３】
更に、本実施形態においては、コミットの粒度が小さいと評価された場合、上記したように対象コミットデータと当該コミットデータの後のコミットデータ（第２コミットデータ）とを結合したコミットデータ（第３コミットデータ）を結合候補としてユーザに提示する構成であってもよい。このような構成によれば、コミットの粒度が小さい場合に対象コミットデータの結合候補を自動的に作成し、当該コミットの粒度が適切になるように当該対象コミットデータを結合することをユーザに促すことができる。
【０１５４】
また、本実施形態においては、文法エラーがないと判定されたコミットデータ（分割候補または結合候補となるコミットデータ）をユーザに対して提示する構成により、分割候補または結合候補として適切でないコミットデータをユーザに提示することを回避することができる。
【０１５５】
また、本実施形態においては、分割候補または結合候補となるコミットデータの評価値を算出し、当該評価値に基づいて当該コミットデータをユーザに提示する構成より、ユーザは、適切な分割候補または結合候補を容易に把握すること可能となる。
【０１５６】
ここで、本実施形態に係る管理データ改善装置１０は、当該管理データ改善装置１０を利用するユーザに対して以下に説明するユーザインタフェース（ＵＩ：User Interface）を提供するものとする。なお、以下に説明するユーザインタフェースは一例であり、他のユーザインタフェースが提供されてもよい。
【０１５７】
このユーザインタフェースによれば、ユーザは、例えば上記した図６に示す処理が実行される際に管理データ改善装置１０を操作することによって、対象期間（開始時及び終了時）を入力することができるものとする。なお、対象期間は、日時または対応するコミット（例えば、コミットＩＤ等）で指定することができるものとする。また、必要であればブランチを指定することができるようにしてもよい。
【０１５８】
上記したようにコミットデータに対応づけて日時を示す情報が格納部１０１に格納されている場合には、対応づけられている日時がユーザによって入力された対象期間内に該当する複数のコミットデータ（コミット列）を管理データ改善装置１０の画面（表示デバイス１７）に表示することができる。
【０１５９】
この場合、ユーザは、表示された複数のコミットデータの全てまたは一部（１つでも可）を、ユーザインタフェースを介して選択することができるものとする。なお、ここでユーザによって選択されたコミットデータが図６に示すステップＳ１において格納部１０１から取り出されるコミットデータ（つまり、対象データ）となる。
【０１６０】
ここで、上記したユーザインタフェースとして、例えば「再構成」、「分割」及び「結合」に対応するボタンが管理データ改善装置１０の画面上に表示されるものとする。ユーザは、この「再構成」、「分割」及び「結合」に対応するボタンのうちの１つの選択（指定）することができる。
【０１６１】
ユーザによって、例えば「再構成」に対応するボタンが選択された場合には、例えば図６に示すステップＳ１〜Ｓ１１の処理が実行されるものとする。一方、ユーザによって例えば「分割」に対応するボタンが選択された場合には、例えば図６に示すステップＳ１〜Ｓ１１の処理のうち、分割候補の作成及び提示に関する処理のみが実行されるようにしてもよい。同様に、ユーザによって例えば「結合」に対応するボタンが選択された場合には、例えば図６に示すステップＳ１〜Ｓ１１の処理のうち、結合候補の作成及び提示に関する処理のみが実行されるようにしてもよい。
【０１６２】
また、上記したようにユーザによって選択されたボタンに応じた処理が実行された場合には、当該処理結果（分割候補または結合候補である新たなコミット列）が管理データ改善装置１０の画面に表示される。この場合、ユーザは、上記したように所望の分割候補または結合候補を選択することが可能であるが、当該分割候補または結合候補が例えばブランチとして生成されるように指示することも可能である。
【０１６３】
本実施形態においては、上記したようなユーザインタフェースを提供することによって、管理データ改善装置１０を利用するユーザの利便性を向上させることが可能となる。
【０１６４】
以下、本実施形態に係る管理データ改善装置１０（ソースコードの構成管理ツール）の利用態様（ユースケース）について説明する。
【０１６５】
まず、本実施形態に係る管理データ改善装置１０（ソースコードの構成管理ツール）は、例えばソフトウェア開発におけるプロジェクト管理者が開発状況を確認するために利用されることができる。
【０１６６】
具体的には、ソースコードがコミットされる回数または修正（変更）されたソースファイルの数等が多く、当該ソースコードの変更内容を理解することが困難である場合、または、コミットの粒度に統一性がないような場合には、プロジェクト管理者は、管理データ改善装置１０において上記したように対象となる期間を指定して、当該期間に該当するコミットデータ（コミット）について古いものから順に再構成（分割及び結合）を行うことができる。
【０１６７】
これによれば、プロジェクト管理者は、再構成されたコミットデータを確認することによって、プロジェクトの状況を把握することができる。
【０１６８】
また、管理データ改善装置１０は、例えばユーザがソフトウェア開発において追加された仕様（機能）の一部をキャンセルするために利用されることも可能である。
【０１６９】
具体的には、キャンセルすべき仕様が実装されていると想定される期間のコミットデータ（によって示される変更箇所）をユーザが確認した際に、他の仕様の追加または不具合の修正等が混在していて当該仕様を追加した部分を特定することが困難である場合、ユーザは、管理データ改善装置１０において上記したように対象となる期間を指定して、当該期間に該当するコミットデータ（コミット）について古いものから順に再構成（分割及び結合）を行うことができる。
【０１７０】
これによれば、ユーザは、再構成されたコミットデータの中から、キャンセル対象となる仕様を追加したコミットデータを発見し、当該コミットデータによって示される変更箇所の変更内容（つまり、仕様の追加）をキャンセルすることができる。
【０１７１】
更に、管理データ改善装置１０は、例えばユーザが共同開発者の作業を確認するために利用されることも可能である。
【０１７２】
具体的には、共同開発者の作業を確認するためにユーザがコミットデータを確認したが、当該コミットデータによって示される変更箇所に関するコミットの粒度が大きすぎて当該共同開発者の作業を確認することができないような場合、ユーザは、管理データ改善装置１０において当該コミットデータを指定して再構成（分割）することができる。
【０１７３】
これによれば、ユーザは、再構成されたコミットデータ（によって示される変更箇所）に基づいて共同開発者の作業を確認するようなことが可能となる。
【０１７４】
上記したように本実施形態によれば、例えばソフトウェア開発におけるプロジェクトのある時点でのソースコードが複数の修正や機能追加を含んでいるような場合には、当該ソースコードがコミットされた際に記録されたコミットデータを分割することが可能となる。同様に、本実施形態においては、ソフトウェア開発におけるプロジェクトのある時点でのソースコードが文法エラーで動作しない（当該ソースコードに文法エラーがある）場合や正しい結果が求められるユニットテストで正しい結果を得られない（ユニットテストに合格しない）場合には、当該ソースコードがコミットされた際に記録されたコミットデータを結合することができる。
【０１７５】
すなわち、本実施形態においては、上記したようにコミットデータを再構成（分割または結合）することによって、ソフトウェア開発においてソースコードが適切な粒度でコミットされたようにコミットデータを修正することが可能となる。
【０１７６】
なお、コミットデータの再構成は、独立した修正、機能追加を含まないこと、文法エラーがないこと、及び正しい結果が求められるユニットテストで正しい結果を出す（ユニットテストに合格する）こと等を満たすように行われるため、管理データ改善装置１０を利用してコミットデータをレビューするユーザの利便性を向上させることが可能となる。
【０１７７】
（第２実施形態）
次に、第２実施形態について説明する。なお、本実施形態に係る管理データ改善装置のシステム構成については、前述した第１実施形態と同様であるため、ここではその詳しい説明を省略する。
【０１７８】
ここで、本実施形態に係る管理データ改善装置の機能構成は前述した図４において説明した機能構成と同様であるが、本実施形態は、当該図４に示す分割候補作成部によって実行される処理が前述した第１実施形態とは異なる。
【０１７９】
具体的には、前述した第１実施形態においてはコミットの粒度が大きい場合にコミットデータをファイル単位で分割するものとして説明したが、本実施形態は、当該コミットデータをソースコードに記述されている行（行構成要素）単位で分割する点で、当該第１実施形態とは異なる。
【０１８０】
以下、本実施形態の前述した第１実施形態と異なる点について主に説明するが、本実施形態に係る管理データ改善装置の機能構成に関しては前述した図４と同様の参照符号を用いて説明するものとする。
ここで、上記したように本実施形態においては、コミットデータを行単位で分割する。このため、本実施形態における依存関係は、前述した第１実施形態における依存関係（ファイル単位の依存関係）とは異なる。
具体的には、本実施形態における依存関係とは、例えばソースファイル、当該ソースファイル内のソースコードに記述されている行、式及び変数等の集合をＡとしたときの集合Ａの二項関係である。また、二項関係とは、集合Ａの元からなる順序対の集まりをいう。
なお、例えばあるａ，ｂ∈Ａに対し、作成されたプログラムの実行しているどこかの時点で、ある変数ｃの値を変更すると、ａ，ｂに対応するそれぞれの処理や値に変化が起こる可能性がある場合に、当該ａ，ｂの間には依存関係があるという。すなわち、「複数の変更箇所の間に依存関係がある」とは、例えば上記した集合Ａに属する複数の変更箇所（対象コミットデータによって示される複数の変更箇所）に対し、ソースコードに基づいてプログラムが実行されているどこかの時点で、当該ソースコード中に出現するある変数の値を変更すると当該複数の変更箇所に対応する処理または値に変化が起こる可能性があることをいう。
具体的には、「複数の変更箇所の間に依存関係がある」とは、対象コミットデータによって示される複数の変更箇所の各々の依存変数集合を特定し、当該複数の変更箇所の各々の依存変数集合の少なくとも一部が重複することをいう。なお、変更箇所の依存変数集合とは、例えば上記した集合Ａに属する複数の変更箇所の各々に対し、ソースコードに基づいてプログラムが実行されているどこかの時点で、当該ソースコード中に出現するある変数の値を変更すると当該変更箇所に対応する処理または値に変化が起こる可能性がある場合における当該変数の集合をいう。換言すれば、ａ∈Ａに対して、作成されたプログラムの実行しているどこかの時点で、変数ｃの値を変更すると、ａに対応する処理や値に変化が起こる可能性があるようなｃの集合をａの依存変数集合と称する。
【０１８１】
以下、図８に示すフローチャートを参照して、本実施形態における分割候補作成部１０３の処理手順（分割候補を作成する処理手順）の一例について説明する。
【０１８２】
なお、図８に示す処理は前述した図６に示すステップＳ５において実行される処理であるが、本実施形態に係る管理データ改善装置１０の当該ステップＳ５の処理以外の処理については当該図６において説明した処理と同様である。ただし、図６に示すステップＳ２の処理においては、ソースコードの解析により、上記した本実施形態における依存間関係の判定が可能となっているとものとする。
【０１８３】
以下の説明において、図６に示すステップＳ１において格納部１０１から取り出されたコミットデータは、前述した第１実施形態と同様に対象コミットデータと称する。コミットデータのデータ構造については、前述した図５において説明した通りであるため、ここではその詳しい説明を省略する。また、コミットデータに対応づけて格納部１０１に格納されているソースコード（つまり、当該コミットデータが格納部１０１に格納される際にコミットされたソースコード）についても前述した第１実施形態と同様に対象ソースコードと称する。
なお、以下のステップＳ３１〜Ｓ３７においては本実施形態における依存関係▽について定義及び説明し、ステップＳ３８及びＳ３９においては当該依存関係▽に基づく分割候補の作成について説明する。
【０１８４】
まず、分割候補作成部１０３は、分割候補を作成するための前処理を実行する（ステップＳ３１）。
【０１８５】
このステップＳ３１において、分割候補作成部１０３は、例えばソフトウェア開発のプロジェクト（対象ソースコード）で使われている全てのグローバルな変数、関数の引数変数、関数内で定義された変数について、変数名（名前）に重なっているものがあるならば重なりがないように変数名を変更する。例えば図９に示すようなソースコード（プログラム）では（１）のｘと（２）のｘとは変数名は同一であるが、別の変数として扱われる。具体的には、（３）に現れるｘは（２）のｘであるから当該（２）のｙは６になるが、（４）のｘは（１）のｘであるから当該（４）のｚは５となる。このような図９に示すようなソースコードの場合には、（１）及び（４）のｘと、（２）及び（３）のｘとの少なくとも一方の変数名を変更する。
【０１８６】
ここで、以下の説明においては、対象ソースコードに記述されている行を構成するソースコードの構成要素（単位）を行構成要素と称する。なお、行構成要素と対象ソースコードにおいて記述されている行は一致する場合が多いが、複数の行構成要素が１つの行の中に存在する場合もある。
【０１８７】
この場合、ステップＳ３１においては、例えば行構成要素ｓ、変数ｖに対して、当該行構成要素ｓにおいて当該変数ｖが依存する変数の集合（ｓにおけるｖの依存変数集合）をｖｄ（ｓ，ｖ）で表すものとして定義する。
【０１８８】
具体的には、例えば図１０に示すソースコードの場合、ｖｄ（２，ｓ）は３行目のｓの値に影響を与える変数の集合を示している。この場合、ｓの値はｘの値に影響を受けることがわかるが、更にこのｓの値はｙの値の影響を受けることから、ｖｄ（２，ｓ）＝｛ｘ，ｙ｝ということになる。
【０１８９】
なお、上記したｖｄ（ｓ，ｖ）は行構成要素ｓがどのような順番で実行される可能性があるかによって変わるため、簡単に決めることはできない。例えば図１１に示すソースコードの場合、ｖｄ（４，ｙ）＝｛ｙ，ｚ｝であるように考えられるが、６行目（ｚ＝ｚ＋ｘ；）によれば２週目（２回目のループ処理）ではｘの値に影響を受けるため、ｖｄ（４，ｙ）＝｛ｙ，ｘ，ｚ｝となる。
【０１９０】
また、行構成要素ｓに対して、当該行構成要素ｓが依存する変数の集合（ｓの依存変数集合）をｓｄ（ｓ）で表すものとして定義する。この場合、各行構成要素ｓでの各変数の依存が判明している場合、当該各行構成要素ｓが依存する変数の集合ｓｄ（ｓ）を、当該行構成要素ｓに現れる変数と、当該変数が依存する変数とを併せたものとして定める。上記した図１１に示す例を用いて具体的に説明すると、ｓｄ（４）は、４行目に現れる変数ｙ及びｚと、当該ｙが依存する変数ｖｄ（４，ｙ）＝｛ｙ，ｚ，ｘ｝と、ｚが依存する変数ｖｄ（４，ｚ）＝｛ｚ，ｘ｝とを併せた｛ｙ，ｚ，ｘ｝となる。
【０１９１】
更に、関数内の最初の行構成要素ｓに対し、当該行構成要素ｓの１つ前の行構成要素を便宜的にｓ０とする。
【０１９２】
この場合、関数の引数変数ａに対して、依存変数集合ｖｄ（ｓ０，ａ）＝Ｍ（ａ）とする。本実施形態において、Ｍは、関数引数変数ａの初期状態を依存変数集合へ対応させるマップであり、引数依存マップと称する。
【０１９３】
具体的には、図１２に示すようなソースコードの場合、２行目ではｖｄ（２，ｚ）はｖｄ（ｓ０，ｘ）とｖｄ（ｓ０，ｙ）とを併せたものとなるが、当該ｖｄ（ｓ０，ｘ）及びｖｄ（ｓ０，ｙ）は簡単には計算することができない。このため、まずはそれぞれをＭ（ｘ）及びＭ（ｙ）としておき、後でＭを求める。この場合、ｖｄ（２，ｚ）＝｛ｚ｝∪Ｍ（ｘ）∪Ｍ（ｙ）となる。
【０１９４】
また、グローバルな変数ｇについては、任意の行構成要素ｓに対し、依存変数集合ｖｄ（ｓ，ｇ）＝Ｌ（ｇ）とする。本実施形態において、Ｌは、各グローバル変数ｇをｇの依存変数集合へ対応させるマップであり、グローバル依存マップと称する。グローバル依存マップＬは上記した引数依存マップＭと同様であり、ｖｄ（ｓ，ｇ）をまずはＬ（ｇ）としておき、後でＬを求める。
【０１９５】
なお、本実施形態において、例えばＡ１，Ａ２，…，Ａｎ，Ｂを集合とした場合に、任意のａ１∈Ａ１，ａ２∈Ａ２，…，ａｎ∈Ａｎに対し、一意にあるｂ∈Ｂが定まるような関係を、Ａ１，Ａ２，…，ＡｎからＢへのマップ、もしくは単にマップと称するものとする。例えばマップをＭとしたときには、ｂ＝Ｍ（ａ１，ａ２，…，ａｎ）と表される。
【０１９６】
また、関数内で定義された変数ｖに対しては、ローカル変数の依存変数集合ｖｄ（ｓ０，ｖ）＝｛ｖ｝として定義する。なお、例えば図１３に示すようなソースコードの場合、２行目は「ｉｎｔ  ｉ，ｅｎｄ，ｔｍｐ；」である。この場合、ｖｄ（２，ｉ）＝｛ｉ｝、ｖｄ（２，ｅｎｄ）＝｛３ｎｄ｝、ｖｅ（２，ｔｍｐ）＝｛ｔｍｐ｝となる。
【０１９７】
以下の説明においては、図１３に示すソースコードを対象ソースコードとして用いて説明する場合があるが、当該図１３に示すソースコードは、当該ソースコードに記述されている各行が行構成要素と一致しており、上記した変数名の重なりがない例である。また、図１３に示すソースコードにおいては、変数名に重なりがないため、便宜的に、変数番号の代わりに変数名が記述されている。なお、図１３に示すソースコードにおいては、値をソートするためのｓｏｒｔ関数が記述されている。
【０１９８】
また、以下の説明において、「＋」は、依存変数集合の和集合演算記号を表しており、「∪」と同義である。また、「＊」は、例えば依存変数集合が決められないこと意味し、依存変数集合が不定（つまり、全ての変数の集合）であることを表すものとする。この場合、全ての依存変数集合Ａに対して、「Ａ＋＊＝＊」かつ「Ａ∩＊≠φ」となる。なお、「φ」は空集合を表す。
【０１９９】
次に、分割候補作成部１０３は、上記した引数依存マップＭ及びグローバル依存マップＬを導入したことにより、各行構成要素ｓにおいて、グローバル変数以外の変数ｖに対する依存変数集合ｖｄ（ｓ，ｖ）を、当該引数依存マップＭ及びグローバル依存マップＬを含んだ形で計算する（ステップＳ３２）。なお、ｖｄは、各行構成要素にて各変数が依存する変数を示すマップに相当する。
【０２００】
ステップＳ３２においては、ソースコードに記述されている関数の行構成要素ｓで値が変更される変数ｖがあるとき、当該変数ｖの値を定める式にポインタが含まれている場合には、ｖｄ（ｖ）＝＊とする。一方、変数ｖの値を定める式にポインタが含まれていない場合、当該式に含まれる変数をｖ１，ｖ２，…，ｖｎとし、行構成要素ｓの１つ前の行構成要素をｓ´とすると、当該行構成要素ｓでの変数ｖの依存変数集合ｖｄ（ｓ，ｖ）＝｛ｖ｝＋ｖｄ（ｓ´，ｖ１）＋ｖｄ（ｓ´，ｖ２）＋…＋ｖｄ（ｓ´，ｖｎ）となる。なお、値が変更されない変数ｖ（現れないものも含む）については、ｖｄ（ｓ，ｖ）＝ｖｄ（ｓ´，ｖ）とする。
【０２０１】
具体的には、図１３に示すソースコードの７行目は「ｔｍｐ＝ｄ［ｉ−１］；」であるが、この行構成要素ｓに対して上記した処理が実行された場合には、ｖｄ（７、ｔｍｐ）＝｛ｔｍｐ｝＋ｖｄ（６，ｄ）＋ｖｄ（６，ｉ）＝｛ｔｍｐ｝＋｛ｄ｝＋｛ｉ｝＝｛ｄ，ｉ，ｔｍｐ｝となる。
【０２０２】
なお、上記の処理は、対象ソースコードに記述されている関数の最初の行構成要素ｓから順に実行される。
【０２０３】
また、関数の最初の行構成要素ｓから順に上記した処理が実行される場合において、ブロックが開始される場合には、以下の（ｉ）〜（ｉｉｉ）のいずれかの処理が実行される。なお、「ブロック」とは、プログラムを構成する単位であり、例えばＣ言語では「｛」で始まり「｝」で終わる。この「ブロック」の用語は、関数の処理部分、分岐の各選択肢、ループのループ単位を表すために用いる。
【０２０４】
まず、（ｉ）の処理においては、開始されるブロックがループブロックである場合に、ブロック内の行構成要素ｓについて順次上記の処理を実行する。なお、ブロック内の行構成要素ｓについて処理が終了した場合には、各ｖｄ、ｓｄに変化がなくなるまでブロックの最初の行に戻り繰り返す。変化がなくなったら次の行構成要素ｓに進む。
【０２０５】
なお、図１３に示すソースコードの８行目は「ｄ［ｉ−１］＝ｄ［ｉ］；」であるが、１回目の（ｉ）の処理では、ｖｄ（８，ｄ）＝｛ｄ｝＋ｖｄ（７，ｄ）＝｛ｄ｝＋｛ｄ｝＝｛ｄ｝となる。また、２回目の（ｉ）の処理では、ｖｄ（８，ｄ）＝｛ｄ｝＋ｖｄ（７，ｄ）＝｛ｄ｝＋｛ｄ，ｔｍｐ｝＝｛ｄ，ｔｍｐ｝となる。次に、３回目の（ｉ）の処理では、ｖｄ（８，ｄ）＝｛ｄ｝＋ｖｄ（７，ｄ）＝｛ｄ｝＋｛ｄ，ｔｍｐ｝＝｛ｄ，ｔｍｐ｝となる。２回目の（ｉ）の処理と３回目の（ｉ）の処理とでは変化がないため、８行目についての処理の結果は、ｖｄ（８，ｄ）＝｛ｄ，ｔｍｐ｝となる。
【０２０６】
次に、（ｉｉ）の処理においては、開始されるブロックがｉｆブロックである場合に、ブロック内の行構成要素ｓについて順次上記した処理が実行され、当該ブロック内の行構成要素ｓの全てについて処理が終了した場合には、次の行構成要素ｓに進む。
【０２０７】
また、（ｉｉｉ）の処理においては、開始されるブロックがｉｆ  （Ａ）  ｅｌｓｅ  （Ｂ）の形式のブロックである場合に、（Ａ）に入る前にｖｄを全て記録する。また、（Ａ）を出る際に再びｖｄを全て記録し、（Ａ）に入る前の状態に戻して（Ｂ）へ入る。（Ｂ）を出る際には（Ａ）を出る際に記録したｖｄと（Ｂ）を出る際のｖｄのそれぞれの和集合を取り、次の行構成要素ｓに進む。
【０２０８】
なお、図１４は、上記した（ｉｉｉ）の処理の具体例を示している。図１４においては、上記した図１３に示すソースコードとは異なるソースコードが対象ソースコードである場合を想定している。
【０２０９】
図１４に示すように、（ｉｉｉ）の処理においては、まずｉｆブロック（Ａ）を計算し、次にｉｆブロックの計算前に戻ってｅｌｓｅブロック（Ｂ）を計算する。このような計算処理の後、最後にそれぞれの結果の和集合を取ることでｖｄを得ることができる。
【０２１０】
ステップＳ３２においては、上記した処理が繰り返されることにより、対象ソースコードに記述されている各行構成要素ｓに対するｖｄ（ｓ，ｖ）を、引数依存マップＭとグローバル依存マップＬを含んだ集合として表現することができる。
【０２１１】
次に、分割候補作成部１０３は、ｖｄを使った式として上記した引数依存マップＭ及びグローバル依存マップＬを記述する（ステップＳ３３）。換言すれば、このステップＳ３３においては、引数依存マップＭ及びグローバル依存マップＬがｖｄを含む式で表現される。なお、ｖｄはステップＳ３２において引数依存マップＭ及びグローバル依存マップＬを使った式として表されているため、当該引数依存マップＭ及びグローバル依存マップＬは、ｖｄを含む式に変換する（書き直す）ことができる。
【０２１２】
ここで、引数依存マップＭについて説明する。ここでは、任意の関数ｆとその引数ａ１，ａ２，…，ａｎに対して、関数ｆを呼び出す全ての行構成要素ｓの集合を｛ｓ１，ｓ２，…，ｓｍ｝とし、各ｓｉ（ｉ＝１，２，…，ｍ）での引数ａ１，ａ２，…，ａｎにくる式をｋｉ１，ｋｉ２，…，ｋｉｎとする。
【０２１３】
この場合において、ｋｉｊにポインタが含まれるときは、依存を追うことができないため、引数依存マップＭｉ（ａｊ）＝＊とする。また、ｋｉｊにポインタが含まれていない場合において、当該ｋｉｊに含まれる変数ｖｄをｖ１，ｖ２，…，ｖｌとすると、Ｍｉ（ａｊ）＝ｖｄ（ｓｉ，ｖ１）＋ｖｄ（ｓｉ，ｖ２）＋…＋ｖｄ（ｓｉ，ｖｌ）となる。
【０２１４】
これによれば、
【数１】
2020071704.tif 000003
となる。
【０２１５】
ここで、図１５を参照して、引数依存マップＭの具体例について説明する。なお、図１５においては上記した図１３に示すソースコードとは異なるソースコードが対象ソースコードである場合を想定しており、例えば絶対値を取得し、結果をｉｎｔ型で返すａｂｓ関数が当該ソースコードに記述されている場合を想定している。
【０２１６】
図１５に示す例では、ｓ１＝３１、ｋ１１＝ｘ＋ｙ、ｓ２＝５２、ｋ２１＝ｇ＋ｋ／ｘ、ｋ２２＝ｋ、ｓ３＝８３、ｋ３１＝ｐ、ｋ３２＝ｘ／ｚである。
【０２１７】
この場合には、図１５に示すように、Ｍ１（ａ１）＝｛ａ１｝＋ｖｄ（３１，ｘ）＋ｖｄ（３１，ｙ）、Ｍ１（ａ２）＝｛ａ２｝＋ｖｄ（３１，ｚ）、Ｍ２（ａ１）＝｛ａ１｝＋ｖｄ（５２，ｇ）＋ｖｄ（５２，ｋ）＋ｖｄ（５２，ｘ）、Ｍ２（ａ２）＝｛ａ２｝＋ｖｄ（５２，ｋ）、Ｍ３（ａ１）＝｛ａ１｝＋ｖｄ（８３，ｐ）、Ｍ３（ａ１）＝｛ａ１｝＋ｖｄ（８３，ｐ）であり、  
【数２】
2020071704.tif 000004
となる。
【０２１８】
これによれば、行構成要素ｓ０に対して、ｖｄ（ｓ０，ａ１）＝Ｍ（ａ１）＝｛ａ１｝＋ｖｄ（３１，ｘ）＋ｖｄ（３１，ｙ）＋ｖｄ（５２，ｇ）＋ｖｄ（５２，ｋ）＋ｖｄ（５２，ｘ）＋ｖｄ（８３，ｐ）及びｖｄ（ｓ０，ａ２）＝Ｍ（ａ２）＝｛ａ２｝＋ｖｄ（３１，ｚ）＋ｖｄ（５２，ｋ）＋ｖｄ（８３，ｘ）＋ｖｄ（８３，ｚ）を得ることができる。
【０２１９】
次に、グローバル依存マップＬについて説明する。ここでは、任意のグローバル変数ｇに対して、ｇの値を変更する全ての行構成要素ｓの集合を｛ｓ１，ｓ２，…，ｓｍ｝とし、各ｓｉでのｇに代入される式をｋｉとする。
【０２２０】
この場合において、ｋｉにポイントが含まれるときは、グローバル依存マップＬｉ（ｇ）＝＊とする。また、ｋｉにポインタが含まれていない場合において、当該ｋｉに含まれる変数をｖ１，ｖ２，…，ｖｌとすると、Ｌｉ（ｇ）＝ｖｄ（ｓｉ，ｖ１）＋ｖｄ（ｓｉ，ｖ２）＋…＋ｖｄ（ｓｉ，ｖｌ）となる。
【０２２１】
これによれば、  
【数３】
2020071704.tif 000005
となる。
【０２２２】
ここで、図１６を参照して、グローバル依存マップＬの具体例について説明する。なお、図１６においては上記した図１３に示すソースコードとは異なるソースコードが対象ソースコードである場合を想定しており、ここでは、ｉｎｔ型のｚがグローバル変数である場合を想定している。  図１６に示す例では、Ｓ１＝３１、ｋ１＝ｘ＋ｙ、ｓ２＝５２、ｋ２＝ｋ／ｘ、ｓ３＝８３、ｋ３＝ｚ＋ｕ＋２である。
【０２２３】
この場合には、図１６に示すように、Ｌ１（ｚ）＝｛ｚ｝＋ｖｄ（３１，ｘ）＋ｖｄ（３１，ｙ）、Ｌ２（ｚ）＝｛ｚ｝＋ｖｄ（５２，ｋ）＋ｖｄ（５２，ｘ）、Ｌ３（ｚ）＝｛ｚ｝＋ｖｄ（８３，ｚ）＋ｖｄ（８３，ｕ）であり、  
【数４】
2020071704.tif 000006
となる。
【０２２４】
これによれば、任意の行構成要素ｓに対して、ｖｄ（ｓ，ｚ）＝Ｌ（ｚ）＝｛ｚ｝＋ｖｄ（３１，ｘ）＋ｖｄ（３１，ｙ）＋ｖｄ（５２，ｋ）＋ｖｄ（５２，ｘ）＋ｖｄ（８３，ｚ）＋ｖｄ（８３，ｕ）を得ることができる。
【０２２５】
次に、分割候補作成部１０３は、上記した引数依存マップＭ及びグローバル依存マップＬの最小不動点となるようにＭ及びＬを定める（ステップＳ３４）。換言すれば、ステップＳ３４においては、引数依存マップＭ及びグローバル依存マップＬの各々の最小不動点が計算される。なお、上記したステップＳ３３において引数依存マップＭ及びグローバル依存マップＬはｖｄの式として表されているため、最小不動点を求めることでＭ及びＬを確定することができる。
【０２２６】
このステップＳ３４においては、まず、任意の関数の引数ａに対する初期値Ｍ（ａ）及び任意のグローバル変数ｇに対する初期値Ｌ（ｇ）を｛｝（空集合）とする。
【０２２７】
次に、上記した初期値Ｍ（ａ）及びＬ（ｇ）を現在の引数依存マップＭ（ａ）及びグローバル依存マップＬ（ｇ）として引数依存マップＭ（ａ）及びグローバル依存マップＬ（ｇ）の式の右辺に代入することで、次の引数依存マップＭ（ａ）及びグローバル依存マップＬ（ｇ）の値を計算する。
【０２２８】
このように計算された引数依存マップＭ（ａ）及びグローバル依存マップＬ（ｇ）の値が、現在の引数依存マップＭ（ａ）及びグローバル依存マップＬ（ｇ）の値と異なる場合、当該計算された引数依存マップＭ（ａ）及びグローバル依存マップＬ（ｇ）の値を現在の引数依存マップＭ（ａ）及びグローバル依存マップＬ（ｇ）として処理が繰り返される。
【０２２９】
一方、計算された引数依存マップ（ア）及びグローバル依存マップＬ（ｇ）の値が、現在の引数依存マップＭ（ａ）及びグローバル依存マップＬ（ｇ）の値と等しい場合には、当該現在の引数依存マップＭ（ａ）及びグローバル依存マップＬ（ｇ）の値を最小不動点とする。
【０２３０】
ここで、図１７を参照して、上記した引数依存マップＭ及びグローバル依存マップＬの計算の具体例について説明する。
【０２３１】
ここでは、図１７に示すように、例えばＭ（ａ１）＝｛ａ１，ｋ，ｐ｝＋Ｍ（ａ２）＋Ｌ（ｇ）、Ｍ（ａ２）＝｛ａ２，ｘ，ｙ｝＋Ｍ（ａ２）、Ｌ（ｇ）＝｛ｋ、ｐ｝＋Ｍ（ａ１）の式が得られているものとし、この式に対して上記した処理が実行された場合には、Ｍ（ａ１）＝｛ａ１，ｋ，ｐ｝、Ｍ（ａ２）＝｛ａ２，ｘ，ｙ｝、Ｌ（ｇ）＝｛ａ１，ｋ，ｐ｝が最小不動点として得られる。
【０２３２】
次に、分割候補作成部１０３は、引数依存マップＭ及びグローバル依存マップＬからｖｄ（ｓ，ｖ）を計算する（ステップＳ３５）。このステップＳ３５において、ｖｄ（ｓ，ｖ）は、ステップＳ３２において表現された各行構成要素ｓ及び各変数ｖに対するｖｄ（ｓ，ｖ）に対して、ステップＳ３４において定められた引数依存マップＭ及びグローバル依存マップＬを代入することによって計算される。
【０２３３】
なお、例えば図１３に示すソースコードが対象ソースコードである場合、当該ソースコードには関数呼び出し及びグローバル変数はない（記述されていない）。この場合、上記したステップＳ３３〜Ｓ３５の処理は不要である。
【０２３４】
次に、分割候補作成部１０３は、ステップＳ３５において計算されたｖｄ（ｓ，ｖ）から各行構成要素ｓに対するｓｄを計算する（ステップＳ３６）。
【０２３５】
ここで、ｓｄは上記したように行構成要素ｓが依存する変数の集合（ｓの依存変数集合）であるが、各行構成要素ｓに対し、当該行構成要素ｓで参照されている変数（代入されるのみの変数は除く）をｖ１，ｖ２，…，ｖｎとした場合、ｓの依存変数集合ｓｄ（ｓ）＝｛｝＋ｖｄ（ｓ，ｖ１）＋ｖｄ（ｓ，ｖ２）＋…＋ｖｄ（ｓ，ｖｎ）とする。
【０２３６】
具体的には、図１３に示すソースコードの７行目は「ｔｍｐ＝ｄ［ｉ−１］；」であるが、この場合、ｓｄ（７）＝｛｝＋ｖｄ（７，ｄ）＋ｖｄ（７，ｉ）となる。このｓｄ（７）＝｛｝＋ｖｄ（７，ｄ）＋ｖｄ（７，ｉ）に対してステップＳ３５において計算されたｖｄを代入することによってｓｄを計算する。この場合、例えばｓｄ（７）＝｛｝＋｛ｄ，ｔｍｐ｝＋｛ｉ｝＝｛ｄ，ｉ，ｔｍｐ｝となる。
【０２３７】
次に、分割候補作成部１０３は、上記した各行構成要素ｓのｓｄから、対象ソースコードに記述されている各行のうちの直前のソースコードから変更された各行（つまり、変更行）ｌに対するｌｄを計算する（ステップＳ３７）。なお、対象ソースコードに記述されている各行のうちの直前のソースコードからの変更行は、当該対象ソースコードに対応づけて格納部１０１に格納されているコミットデータ（つまり、対象ソースコードがコミットされた際に格納部１０１に格納されたコミットデータ）に含まれる変更行から特定することができる。
【０２３８】
ここで、変更行ｌが行構成要素ｓ１，ｓ２，…，ｓｎで構成されているとき、ｌｄ（ｌ）＝ｓｄ（ｓ１）＋ｓｄ（ｓ２）＋…＋ｓｄ（ｓｎ）とする。なお、変更行が行構成要素を１つも含まない（例えば、変更行が「｛」のみの行やコメントのみの行等である）場合には、ｌｄ（ｌ）＝｛｝とする。
【０２３９】
ステップＳ３７においては、このようなｌｄ（ｌ）を上記したステップＳ３６において計算されたｓｄを用いて計算する。具体的には、例えば図１３に示すソースコードの７行目は上記したように「ｔｍｐ＝ｄ［ｉ−１］；」であるが、この７行目の行は１つの行構成要素で成り立っている。この場合、ｌｄ（７）＝ｓｄ（７）であるため、ｌｄ（７）＝｛ｄ，ｉ，ｔｍｐ｝となる。
【０２４０】
なお、図１３に示すソースコードでは全ての行が１つ以下の行構成要素で成り立っているが、１つの行に複数の行構成要素が記述されている場合には、上記したようにそれぞれの和集合を計算すればよい。
【０２４１】
次に、分割候補作成部１０３は、各変更行ｌに対するｌｄに基づいて、当該変更行ｌの各々を同値類に分解する（ステップＳ３８）。
【０２４２】
ここで、例えば対象ソースコードに記述されている関数内でリターンを含む行構成要素ｓをｓ１，ｓ２，…，ｓｎとし、関数の型、引数を含む行をｌとすると、ｌｄ（ｌ）＝ｓｄ（ｓ１）＋ｓｄ（ｓ２）＋…＋ｓｄ（ｓｎ）である。
【０２４３】
また、行ｌｉ，ｌｊに対し、ｌｄ（ｌｉ）∩ｌｄ（ｌｊ）≠φもしくはｌｄ（ｌｉ）＝ｌｄ（ｌｊ）＝φであるならば、ｌｉとｌｊとは直接依存するといい、ｌｉ〜ｌｊと表記するものとする。
【０２４４】
なお、本実施形態における依存関係▽については、ｌｉ〜ｌｊならばｌｉ▽ｌｊであり、ｌｉ〜ｌｊかつｌｊ〜ｌｋならばｌｉ▽ｌｋであるものとして定義する。なお、「▽」は、反射的、対称的、推移的な（つまり、反射律、対称律、推移律を満たす）二項関係に相当する同値関係である。
【０２４５】
ここで、１つの同値関係はその集合を同値類に分解することができるため、ステップＳ３８においては、変更行ｌを依存関係▽で同値類分解する。なお、分解したものをＥ＝｛ｅ１，ｅ２，…，ｅｎ｝とする。ｅｊ（ｊ＝１，２，…，ｎ）は行の集合を表す。
【０２４６】
ステップＳ３８の処理が実行されると、分割候補作成部１０３は、上記したＥを二つに分割し（一方がＥになる場合を除く）、分割されたそれぞれの和集合を計算したものを分割候補として生成する（ステップＳ３９）。
【０２４７】
すなわち、本実施形態においては、各行（行構成要素）が依存する変数の集合において共通部分がある行は依存するとみなし、このような観点に基づいて依存しない塊を生成する。このとき、上記したように例えばＡとＢとが依存し、ＢとＣとが依存している場合にはＡとＣとが依存するものとし、本実施形態においては、この点を定義するために同値関係を用いている。
【０２４８】
ここで、図１８は、上記した図１３に示すソースコードに対して上記した図８に示す処理（分割候補を生成する処理）が実行された結果の一例を示している。なお、上記したように図１３に示すソースコードには値をソートするためのｓｏｒｔ関数が記述されているが、このｓｏｒｔ関数には呼出がないため、引数依存マップＭ（ｄ）＝｛｝としている。更に、図１３に示すソースコードにはグローバル変数はないため、グローバル依存マップＬの計算は必要ない。
【０２４９】
図１８に示す例において、ソースコードの変更行が３行目、５行目〜１０行目及び１４行目であるものとする。また、これらの各変更行に対して計算されたｓｄがそれぞれ、ｓｄ（３）＝｛ｒｅｔ｝、ｓｄ（５）＝｛ｅｎｄ，ｉ，ｌｅｎｇｔｈ｝、ｓｄ（６）＝｛ｄ，ｉ，ｔｍｐ｝、ｓｄ（７）＝｛ｄ，ｉ，ｔｅｍｐ｝、ｓｄ（８）＝｛ｄ，ｉ，ｔｍｐ｝、ｓｄ（９）＝｛ｄ，ｉ，ｔｍｐ｝、ｓｄ（１０）＝｛ｒｅｔ｝、ｓｄ（１４）＝｛ｒｅｔ｝であるものとする。
【０２５０】
これらのｓｄから各変更行ｌに対するｌｄを計算し同値類分解をした場合、Ｅ＝｛Ａ，Ｂ｝となり、Ａ＝｛３，１０，１４｝、Ｂ＝｛５，６，７，８，９｝となる。なお、Ａ及びＢの各数字はそれぞれ変更行の行番号を表している。
【０２５１】
これによれば、分割候補作成部１０３は、変更箇所としてＡに属する変更行（３行目、１０行目及び１４行目）を示す第１分割候補コミットデータ及び変更箇所としてＢに属する変更行（５行目〜９行目）を示す第２分割候補コミットデータの組み合わせからなる分割候補（以下、第１分割候補と表記）と、変更箇所としてＢに属する変更行を示す第１分割候補コミットデータ及び変更箇所としてＡに属する変更行を示す第２分割候補コミットデータの組み合わせからなる分割候補（以下、第２分割候補と表記）を作成することができる。すなわち、本実施形態においては、上記したＥ（Ａ及びＢ）の並びの違いも考慮して分割候補を作成するものとする。なお、図１８に示す例では、上記した第１及び第２分割候補のみが作成される。
【０２５２】
上記した図８に示す処理が実行された場合には、前述した図６に示すステップＳ６以降の処理が実行される。この図６に示すステップＳ６以降の処理については前述した第１実施形態で説明した通りである。
【０２５３】
以下、図１９を参照して、上記した図１８において説明した第１及び第２分割候補が作成された場合の当該ステップＳ６以降の処理について具体的に説明する。
【０２５４】
まず、図１９の上段は、第１分割候補を表している。図１９の上段に示すソースコード２０１は、対象ソースコードの直前のソースコードを示す。また、ソースコード２０２は、ソースコード２０１に対して第１分割候補の第１分割候補コミットデータによって示される変更箇所（上記した対象ソースコードの３行目、１０行目及び１４行目）の変更内容が反映されたソースコードを示す。更に、ソースコード２０３は、ソースコード２０２に対して第１分割候補の第２分割候補コミットデータによって示される変更箇所（上記した対象ソースコードの５行目〜９行目）の変更内容が反映されたソースコードを示す。
【０２５５】
次に、図１９の下段は、第２分割候補を表している。図１９の下段に示すソースコード３０１は、上記したソースコード２０１と同様に、対象ソースコードの直前のソースコードを示す。また、ソースコード３０２は、ソースコード３０１に対して第２分割候補の第１分割候補コミットデータによって示される変更箇所（上記した対象ソースコードの５行目〜９行目）の変更内容が反映されたソースコードを示す。更に、ソースコード３０３は、ソースコード３０２に対して第２分割候補の第２分割候補コミットデータによって示される変更箇所（対象ソースコードの３行目、１０行目及び１４行目）の変更内容が反映されたソースコードを示す。
【０２５６】
ここで、上記した第１及び第２分割候補の各々に対して、前述した図６に示すステップＳ６の処理が実行された場合を想定する。
【０２５７】
この場合、第１分割候補（ソースコード２０２及び２０３）は文法エラーがないため、当該第１分割候補は妥当であると判定される。
【０２５８】
同様に、第２分割候補（ソースコード３０２及び３０３）は文法エラーがないため、当該第２分割候補は妥当であると判定される。
【０２５９】
次に、前述した図６に示すステップＳ７の処理が実行された場合を想定する。ここで、第１分割候補の第１分割候補コミットデータによって示される変更箇所は、対象ソースコードの３行目、１０行目及び１４行目である。このため、第１分割候補の評価値（第１分割候補の第１分割候補コミットデータにおける変更行数）は３となる。
【０２６０】
一方、第２分割候補の第１分割候補コミットデータによって示される変更箇所は、対象ソースコードの５行目〜９行目である。このため、第２分割候補の評価値（第２分割候補の第２分割候補コミットデータにおける変更行数）は５となる。
【０２６１】
この場合、前述した図６に示すステップＳ８においては、評価値が小さい第１分割候補が最終的な分割候補として優先的にユーザに対して提示される。
【０２６２】
なお、対象ソースコードには値をソートするための関数（ｓｏｒｔ関数）が記述されているが、ソースコード２０２（つまり、対象ソースコードの直前のソースコードに第１分割候補の第１分割候補コミットデータによって示される変更箇所の変更内容が反映されたソースコード）では正しい結果が得られない。このため、例えば具体的なソートの結果を検証するユニットテストが用意されている場合には、図６に示すステップＳ６において第１分割候補は妥当でないと判定され、当該図６に示すステップＳ８においては第２分割候補が最終的な分割候補としてユーザに提示される。
【０２６３】
なお、ソースコード３０２及び３０３は正しい結果が得られるため、当該ユニットテストが用意されている場合であっても、第２分割候補は妥当であると判定される。
【０２６４】
上記したように本実施形態においては、コミットの粒度が大きい場合にソースコードに記述されている行単位で対象コミットデータの分割候補を作成することが可能であるため、前述した第１実施形態において説明したようにファイル単位で分割する（分割候補を作成する）場合と比較して、より適切な分割候補をユーザに対して提示することが可能となる。
【０２６５】
以上述べた少なくとも１つの実施形態によれば、ユーザの利便性を向上させることが可能な管理データ改善装置、方法及びプログラムを提供することができる。
【０２６６】
なお、上述した各実施形態において実行される処理は管理データ改善装置１０のコンピュータがコンピュータプログラムを実行することによって実現可能であるが、当該コンピュータによって実行可能なコンピュータプログラムは、当該コンピュータに上述した各実施形態において説明した機能を実行させることが可能なインストラクションを備え、コンピュータ読み取り可能な非一時的記憶媒体に格納されていてもよい。
【０２６７】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれると同様に、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【０２６８】
１０…管理データ改善装置、１１…ＣＰＵ、１２…システムコントローラ、１３…主メモリ、１４…ＢＩＯＳ−ＲＯＭ、１５…不揮発性メモリ、１６…入力デバイス、１７…表示デバイス、１８…ＥＣ、１０１…格納部、１０２…コミット粒度評価部、１０３…分割候補作成部、１０４…結合候補作成部、１０５…妥当性判定部、１０６…候補評価部、１０７…候補提示部。
【図１】
2020071704.tif 000007
【図２】
2020071704.tif 000008
【図３】
2020071704.tif 000009
【図４】
2020071704.tif 000010
【図５】
2020071704.tif 000011
【図６】
2020071704.tif 000012
【図７】
2020071704.tif 000013
【図８】
2020071704.tif 000014
【図９】
2020071704.tif 000015
【図１０】
2020071704.tif 000016
【図１１】
2020071704.tif 000017
【図１２】
2020071704.tif 000018
【図１３】
2020071704.tif 000019
【図１４】
2020071704.tif 000020
【図１５】
2020071704.tif 000021
【図１６】
2020071704.tif 000022
【図１７】
2020071704.tif 000023
【図１８】
2020071704.tif 000024
【図１９】
2020071704.tif 000025