DEIM Forum 2018 G2-5

開発プロジェクトにおけるソフトウェア性能分析に基づいた 開発者の貢献度分析

笠井 貴之† 鷹野 孝典‡

†神奈川工科大学大学院工学研究科情報工学専攻 〒243-0292 神奈川県厚木市下荻野 1030

‡神奈川工科大学情報学部情報工学科 〒243-0292 神奈川県厚木市下荻野 1030

E-mail: †s1785009@cco.kanagawa-it.ac.jp, ‡takano@ic.kanagawa-it.ac.jp

あらまし ソフトウェア開発プロジェクトにおいて，共同作業を通じて効率を向上させるために人的資源を管理

し開発者を動機づけることが重要である．このために個々の開発者のプロジェクトに対する貢献度を適切に評価す

ることが必要である．例えば，ソースコードの総編集行数は，開発者の貢献度を評価する指標として利用可能であ

るが，プログラム開発の促進やプロジェクトの保守などに対する実質的な貢献度を評価するには不足している．本

研究では，ソースコードの実行結果をプロファイリングし，その分析結果に基づいて開発者のソフトウェア実行性

能改善への貢献度を算出する手法を提案する．提案方式では開発中のソフトウェアを実際に実行し，実行時間・CPU

使用率・メモリ使用量等の性能値をコミットごとに収集・分析することで開発者のプロジェクトへの実質的な貢献

度を算出する．GitHub 上の開発プロジェクトを対象とした実験により提案方式の実現可能性を検証する．

キーワード GitHub，継続的プロファイリング，ソフトウェア開発，貢献度分析，特徴抽出

1. はじめに

ソフトウェア開発における分散バージョン管理シ

ステムの普及に伴い，様々な開発プロジェクトが

GitHub[1]や Bitbucket[2]等のプロジェクト管理サービ

スを用いて Web 上で共有・管理されるようになってい

る．これによって，世界各地に分散しているソフトウ

ェア開発者はいつどこにいようと同じプロジェクトに

対して協力して作業を行うことができる．また，異な

る開発者によって作成されたソースコードを頻繁にマ

ージし，アプリケーション実行環境に迅速に配置する

開 発 プ ロ セ ス を 継 続 的 イ ン テ グ レ ー シ ョ ン

(Continuous Integration : CI)と呼び，広く普及し始めて

いる．CI を使用することで，開発者はソフトウェアの

バグを早期に発見し，ソフトウェアの品質を向上させ

ることが可能になる．さらに開発ブランチでのビルド

とテストの過程を自動化することで開発時の作業量を

削減できる．

開発プロジェクトにおいて，共同作業を通じて効率

を向上させるために人的資源を管理し開発者を動機づ

けることが重要である．開発者は通常人手によるソー

スコードレビューを行うか，コードカバレッジやテス

トケースを用いたアルゴリズム解析などのソフトウェ

ア測定法により，ソフトウェアの品質と実行性能を測

定することができる．しかし，アプリケーション設計，

開発計画，開発品質，テスト，ビルドと本番環境への

配置，セキュリティといったいくつかの要素の評価が

必要となるため，開発者のプロジェクトへの貢献度を

客観的に見積もることはより困難であり，評価が偏っ

てしまう場合がある．例えばシニア開発者がより困難

な仕事を割り当てられ，解決できない場合過小評価さ

れるというような可能性がある．

本研究では，開発者のプロジェクト内における評価

をソフトウェアの実行性能の向上に対する貢献度であ

るとみなし，ソースコードの実行結果を分析すること

で，開発者のソフトウェア実行性能改善への貢献度を

算出する手法を提案する． GitHub 上の開発プロジェ

クトを対象とした実験により提案方式の実現可能性を

検証する．

2. 関連研究

開発者の能力評価やプロジェクト評価に関する研

究 が 行 わ れ て い る ． 文 献 [3] で は GitHub 上 で の

MVC(Model View Controller)設計のフレームワークを

用いた Web アプリケーションの開発履歴に基いて，開

発者に対して役割・サポート性・リーダー性の特徴付

けを行っている．文献 [4]では開発者を風林火山と称す

る 4 つの特性に分類し，開発前の段階で自己評価アン

ケートを行い，実際の開発履歴から導出した分類結果

と比較することで開発前に開発者特性の分類が可能か

検証している．文献 [5]では Java のソースコードを静

的解析することによって学生や求職者を対象としたプ

ログラミング能力や知識の評価を行っている．文献 [6]

ではオープンソースソフトウェア開発における各開発

者の開発・保守に対する貢献度に着目し，ソースコー

ド品質との関係について定量的な分析を行っている．

各ソースコードに対して各開発者が追加，変更，削除

した総ソースコード行数の比率を貢献度エントロピー

として定量化することで，一人で開発されてきたもの

に対して他の開発者が部分的に関与し始めた状態が最

もバグ修正が起こりやすいという傾向を確認している．

3. 提案方式

提案システムはソフトウェアの性能評価に基づい

て，開発者スキルの分析を行う．本システムは，CI プ

ロセス中において開発者がソースコードをリモートリ

ポジトリへコミットするごとにソースコードに対して

性能分析を行う．分析結果からソフトウェア性能の変

化をスコアとして開発者に関連付けることで，開発者

の貢献度を客観的に分析することが可能になる．

提案システムによるソフトウェア性能評価，および

開発者スキル抽出は下記の手順で行う（図 1）．

図 1 提案システムの概要

Step-1．開発者はソースコードを書き，リモートリポ

ジトリのメイン開発ブランチにコミットする．

Step-2．コミット後最新のソースコードがアプリケ

ーションサーバにデプロイされる．

Step-3．ソフトウェア性能がプロファイリングされ，

性能の改善に関する情報がソースコード性能分析結果

に基づいて算出される．

Step-4．ソースコードをコミットした開発者と実行

性能の向上を関連付けることによって，開発者のプロ

グラム実行性能への貢献に関する情報が抽出される．

図 2 の時系列グラフは開発プロジェクトにおける

性能改善グラフの例を示している．図 2 のグラフにお

いて，横軸は「時間」，縦軸は「実行時間」を表してい

る．グラフの各プロットは開発者によるコミットポイ

ントを表している．この例では，開発者 kasai がソース

コード内の関数 X を変更してコミットポイント (2)で

コミットした結果，関数 X の処理速度が以前のバージ

ョンよりも 10%速くなったことを示している．したが

って，ソフトウェア性能改善への開発者の貢献度を示

すことができる．

図 2 性能改善グラフの例

3.1. ソフトウェア性能分析

表 1 にソフトウェア性能分析の評価属性を示す．こ

れらの属性は特定の状況に依存しない普遍的な実行性

能の基準であるため，評価対象とした．例えば P1 は「実

行時間」を評価するための属性を表し，P2 は「メモリ

使用量」を示す．

表 1 ソフトウェア性能分析の評価属性

評価属性

P1 実行時間

P2 メモリ使用量

P3 CPU 使用率

P4 実行数

n 回目のコミットのソフトウェア性能スコア PSn を

次のように定義する．

𝑃𝑆𝑛 = [

𝑣1𝑣2⋮𝑣𝑗

]

ここで各要素 v j は表 1 に示す評価属性の改善の程

度を表す．評価属性 P jのソフトウェア性能が以前のコ

ミットよりも改善されている場合，v jを Sup(>0)だけ増

加させる．性能が変更されていない場合は v jを変更せ

ず，悪化している場合は Sdown(<0)だけ減少させる．例

えば Supは 1，Sdownは -1 と設定する．

3.2. 開発者のプログラミング貢献度の分析

開発者のプログラミング貢献度を分析するために

表 2 に示すようなソフトウェア性能分析属性 P1~P jに

Source code Repository

Developer

コーディング コミット

Measurements

デプロイ

開発者の貢献度分析

Step-1

Step-2

Step-3

プログラムの性能評価

Step-4

Profiling

提案システム

(2) commit_id: x5iszdyi

関数 Xの処理速度が 10% 高速化しました

(1)

User: kasai19

20

22

g+=i;

while(i++<3000){ g+=i; }

printf(“Result = %d”, g);

(2)(3) (4) (5)

(7)

(6)

対するプログラミング貢献度を表す行列 Dを定義する．

表 2 において，d iは開発者 i を表し，各セルの u i jは開

発者 d i のソフトウェア性能分析属性 P j に対する貢献

度スコアを表している．

表 2 開発者の貢献度マトリクス

d1 d2 d3 … d i

P1 u11 u21 u31 … u i1

P2 u12 u22 u32 … u i2

P3 u13 u23 u33 … u i3

…

Pj u1 j u2 j u3 j … u i j

行列 Dn は開発者がソースコードをコミットするた

びに更新される．例えば，ソフトウェア性能分析属性

P jのソフトウェア性能が以前のコミットバージョンよ

りも改善された場合，u i jを Sup(>0)だけ増加させる．性

能が変更されていない場合は v jを変更せず，悪化して

いる場合は Sdown(<0)だけ減少させる．

例えば，Sup =1，Sdown =-1 とすると，この場合，開発

者 d i によるソースコードコミットにより実行時間 (P j)

が以前のバージョンよりも短くなると，実行時間の実

行性能が向上したということになり，u ij (n)= u i j (n-1)+1

となる．

開発者の貢献度行列 Dnを使用して，各コミットポイ

ントでの行列間の差分を計算することによって，各開

発者のソフトウェア性能改善への貢献度を分析するこ

とができる．

4. 実験

プロトタイプを用いた実験により，提案システムの

実現可能性を確認する．

4.1. 提案方式実現の確認

4.1.1. 実験目的

GitHub 上の開発プロジェクトにおいて手動でソフ

トウェア性能分析を行い，提案方式により開発者の実

行性能への貢献度スコアとして算出できることを確認

する．

4.1.2. 実験環境

3 人の開発者 d1，d2，d3 がコミットする共同ソフト

ウェア開発のための GitHub リポジトリをセットアッ

プし，アプリケーションサーバにプロトタイプを実装

した．対象開発プロジェクトとして，はてな [7]が提供

する Microsoft IME 形式の単語辞書 [8]を MeCab[9]形式

の辞書へ変換する機能を提供する自作ソフトウェアを

用意した（表 3）．実行時間は「 time」コマンド，アプ

リケーションサーバのメモリと CPU 使用量は「ps」コ

マンドを使用して計測した．表 4 は各開発者のコミッ

ト履歴を示している． 図 3 は d1 が作成したコミット

2ac0382(初期コミット )と d2 が作成したコミット

bac96ae のソースコード例を示している．

表 3 実験 1 対象開発プロジェクト

プロジェクト名 概要 URL

oc20160820 辞書変換 https://github.com/unblee/ oc20160820

表 4 コミット履歴

Commit ID Description Developer

2ac0382 Initial commit d1

45d69e3 Changed a string-concatenation

process d1

bac96ae Changed a file-open process d2

45a5384 Deleted a function

convert_utf16to8() d3

acf2457 Changed a process for skipping

the first line of a dictionary file d2

[Commit ID: 2ac0382]

53

…

56

57

58

59

…

63

64

def convert2csv(utf8_file_name)

…

open(dic_file_name, "ab") do |outfile|

open(utf8_file_name, "rb:UTF-8") do

|utf8_file|

buf = utf8_file.read

buf.each_line do |line|

…

outfile.puts(content)

end

[Commit ID: bac96ae]

53

…

56

57

58

...

62

63

def convert2csv(utf8_file_name)

…

outfile = open(dic_file_name, "ab")

buf = open(utf8_file_name, "rb:UTF-8")

buf.each_line do |line|

…

outfile.puts(content)

end

図 3 コミットしたソースコード例

4.1.3. 実験方法

対象開発プロジェクトが管理するソフトウェアの

実行時間，メモリ使用量，CPU 使用率のソフトウェア

性能分析評価属性について表 4 に示したコミットポ

イントごとに計測を行う．提案方式を用いて各プロフ

ァイリング属性についての計測結果を貢献度スコア化

し，各コミットで開発者がプログラムの実行性能にど

のような影響を与えたのかを確認する．これによって

開発者の実行性能への貢献度スコアを算出可能である

かを確認する．

4.1.4. 実験結果

図 4，図 5，図 6 は各コミット時の実行時間，メモ

リ使用量，CPU 使用率のプロファイリング結果を示し

ている．これらの結果から，すべての開発者がソフト

ウェアの実行性能を改善していることが確認できる．

表 5 は開発者 d1，d2，d3 の貢献度を計算した結果を示

す．2 回開発者 d2 によってコミットされ，これによっ

て実行時間と CPU 使用率が 2 倍に向上したことから

d2 のスコアを 2 ポイント増加した．コミット bac96ae

でメモリ使用率が向上したが，コミット acf2457 で悪

化した．その結果 d2 のメモリ使用率スコアは 0(= +1-

1)点となった．

これらの結果から，ソースコードのプロファイリン

グ結果に基づいてソフトウェアの改善点を分析し，開

発者のソフトウェア性能への貢献度スコアを算出でき

ることが確認できた．

図 4 性能分析結果（実行時間）

図 5 性能分析結果（メモリ使用量）

図 6 性能分析結果（CPU 使用率）

表 5 開発者の貢献度の計算結果

評価属性 d1 d2 d3

P1

(実行時間 ) 1 2 -1

P2

(メモリ使用量 ) 1 0 1

P3

(CPU 使用率 ) 1 2 -1

4.2. GitHub 開発プロジェクトへの適用

4.2.1. 実験目的

実験 1 において提案方式によって開発者の貢献度を

算出することが可能であることを確認した．この実験

2 ではそれを踏まえて，GitHub 上で複数人の開発者に

よって開発されているプロジェクトを対象に本システ

ムを用いて貢献度を算出し順位付けを行う．これと各

開発者のソースコードの総編集行数を基準とした順位

付けとの比較を行い，ソースコードの編集量による貢

献度と実行性能への貢献度との差異を考察する．

4.2.2. 実験環境

GitHub 上で開発されている参加開発者数，コミット

数，お気に入り数が多い Ruby プロジェクトの 2017 年

1 月時点での最新コミット時点からマージコミットと

ソフトウェアの性能に関係のないドキュメント更新の

ためのコミットを除いた過去 200 コミット分に対して

表 6 に示したプロファイラを用いて計測した．対象開

発プロジェクトを表 7 に示す．

表 6 実験 2 使用プロファイラ

評価属性 使用プロファイラ

実行時間 ruby-prof

メモリ使用量 get_process_mem

CPU 使用率 ps（Linux コマンド）

10.5739.246 8.913

12.352

8.801

0

2

4

6

8

10

12

14

2ac0382 45d69e3 bac96ae 45a5384 acf2457

Exec

uti

on

tim

e(s

ec)

Commit ID

92.2 88.2 82.3

73.5

121.3

0

20

40

60

80

100

120

140

2ac0382 45d69e3 bac96ae 45a5384 acf2457

Mem

ory

usa

ge (

MB

)

Commit ID

47.0

40.7 39.2

42.0

38.0

30

35

40

45

50

2ac0382 45d69e3 bac96ae 45a5384 acf2457

CP

U u

sage

(%

)

Commit ID

表 7 実験 2 対象開発プロジェクト

名称 概要 URL コミット範囲

bundle パッケージ

管理

https://

github.com/ bundler/bundler

c783394b

…bdef06e5

rake ビルド

ツール

https://

github.com/ ruby/rake

3948349

…34f5e2e

4.2.3. 実験方法

表 7 に示した開発プロジェクトに対して本システ

ムを適用し，各開発者の実行性能への貢献度を算出す

る．この貢献度を基に開発者の実行性能への貢献順位

を作成する．また比較対象として，各開発者のソース

コード編集行数を基にしたソースコードへの貢献順位

を作成する．この二つを比較し，その差異から開発プ

ロジェクトへの開発者の貢献がソースコードの編集行

数だけでは測れないことを確認する．

4.2.4. 実験結果

表 8，表 9 に開発プロジェクト「bundler」，表 10，

表 11 に開発プロジェクト「 rake」それぞれにおけるソ

ースコード編集行数順位と提案方式によって算出した

各開発者の実行性能への貢献度スコア順位を示す．ま

た図 7 に「bundler」，図 8 に「 rake」における開発者

のランキング間における位置関係を示す．

表 8 「bundler」のソースコード編集行数順位

順位 編集行数 開発者名

1 4855 Samuel Giddins

2 3127 chrismo

3 2602 Andre Arko

4 1910 Homu

5 349 Guillermo Guerrero

6 300 The Bundler Bot

7 189 Akira Matsuda

8 185 Colby Swandale

9 136 hiren mistry

9 136 Jason King

10 71 Bodo Tasche

11 50 Lucas Mazza

12 47 bronzdoc

13 14 Sean Arnold

14 8 Pavel

15 5 mrb

16 4 smlx

16 4 Igor Zubkov

16 4 Andrey Korobkov

17 2 Gearnode

17 2 Andrew White

17 2 Alyssa Ross

表 9 「bundler」の貢献度スコアによる順位

（提案方式）

順位 貢献度 開発者名

1 4 Homu

2 2 Pavel

2 2 Colby Swandale

3 1 Lucas Mazza

3 1 Jason King

3 1 Gearnode

3 1 Bodo Tasche

4 0 smlx

4 0 mrb

4 0 Sean Arnold

4 0 Igor Zubkov

4 0 Andrey Korobkov

4 0 Alyssa Ross

5 -1 hiren mistry

5 -1 chrismo

5 -1 bronzdoc

5 -1 The Bundler Bot

5 -1 Guillermo Guerrero

5 -1 Andrew White

6 -2 Andre Arko

6 -2 Akira Matsuda

7 -7 Samuel Giddins

表 10 「 rake」のソースコード編集行数順位

順位 編集行数 開発者名

1 9648 jimweirich

2 6923 Tatsuya Sato

3 6238 SHIBATA Hiroshi

4 4173 Eric Hodel

5 80 rudyyazdi

6 63 Brian Henderson

7 57 ptarjan

8 43 Josh Cheek

9 26 Mark D. Blackwell

10 24 Jesse Bowes

11 22 Nobuyoshi Nakada

12 20 ogawatti

12 20 leethomas

12 20 Tim Maslyuchenko

13 18 Code Ass

14 14 Brett Sykes

15 13 Chris Johnson

16 8 Izuta Hiroyuki

17 7 Olle Jonsson

18 4 Hendy Tanata

19 3 Chocolateboy

19 3 Paul Annesley

20 2 Yuta Kurotaki

20 2 Jérémie Astori

表 11 「 rake」の貢献度スコアによる順位

（提案方式）

順位 貢献度 開発者名

1 3 Josh Cheek

2 2 SHIBATA Hiroshi

3 1 jimweirich

3 1 Tatsuya Sato

3 1 Chris Johnson

4 0 rudyyazdi

4 0 ptarjan

4 0 leethomas

4 0 Yuta Kurotaki

4 0 Olle Jonsson

4 0 Jérémie Astori

4 0 Izuta Hiroyuki

4 0 Hendy Tanata

4 0 Eric Hodel

5 -1 ogawatti

5 -1 chocolateboy

5 -1 Tim Maslyuchenko

5 -1 Paul Annesley

5 -1 Mark D. Blackwell

5 -1 Jesse Bowes

5 -1 Brian Henderson

5 -1 Brett Sykes

6 -2 Nobuyoshi Nakada

6 -2 Code Ass

図 7 「bundler」におけるランキング間での開発者の位置関係

図 8 「 rake」におけるランキング間での開発者の位置関係

順位 編集行数 開発者名

1 4855 Samuel Giddins

2 3127 chrismo

3 2602 Andre Arko

4 1910 Homu

5 349 Guillermo Guerrero

6 300 The Bundler Bot

7 189 Akira Matsuda

8 185 Colby Swandale

9 136 hiren mistry

9 136 Jason King

10 71 Bodo Tasche

11 50 Lucas Mazza

12 47 bronzdoc

13 14 Sean Arnold

14 8 Pavel

15 5 mrb

16 4 smlx

16 4 Igor Zubkov

16 4 Andrey Korobkov

17 2 Gearnode

17 2 Andrew White

17 2 Alyssa Ross

順位 貢献度 開発者名

1 4 Homu

Pavel

Colby Swandale

Jason King

Bodo Tasche

Lucas Mazza

Gearnode

Sean Arnold

mrb

smlx

Igor Zubkov

Andrey Korobkov

Alyssa Ross

chrismo

Guillermo Guerrero

The Bundler Bot

hiren mistry

bronzdoc

Andrew White

Andre Arko

Akira Matsuda

7 -7 Samuel Giddins

3

4

5

6

2 2

1

0

-1

-2

順位向上

順位低下

順位変化なし

順位 編集行数 開発者名

1 9648 jimweirich

2 6923 Tatsuya Sato

3 6238 SHIBATA Hiroshi

4 4173 Eric Hodel

5 80 rudyyazdi

6 63 Brian Henderson

7 57 ptarjan

8 43 Josh Cheek

9 26 Mark D. Blackwell

10 24 Jesse Bowes

11 22 Nobuyoshi Nakada

20 ogawatti

20 leethomas

20 Tim Maslyuchenko

13 18 Code Ass

14 14 Brett Sykes

15 13 Chris Johnson

16 8 Izuta Hiroyuki

17 7 Olle Jonsson

18 4 Hendy Tanata

3 chocolateboy

3 Paul Annesley

2 Yuta Kurotaki

2 Jérémie Astori

12

20

19

順位 貢献度 開発者名

1 3 Josh Cheek

2 2 SHIBATA Hiroshi

jimweirich

Tatsuya Sato

Chris Johnson

rudyyazdi

ptarjan

leethomas

Eric Hodel

Izuta Hiroyuki

Olle Jonsson

Hendy Tanata

Yuta Kurotaki

Jérémie Astori

Mark D. Blackwell

Jesse Bowes

ogawatti

Tim Maslyuchenko

chocolateboy

Paul Annesley

Brian Henderson

Brett Sykes

Nobuyoshi Nakada

Code Ass

3

4

5

6

1

0

-1

-2

順位向上

順位低下

順位変化なし

4.3. 実験考察

実験 2 にて各開発プロジェクトにおける各開発者の

実行性能への貢献度とその順位を示した．これをとも

に示した編集行数を基にした順位と比較すると，その

順位が大きく異なっていることがわかる．例えば表 8，

表 9 の開発者「Samuel Giddins」に注目すると，編集

行数を基にした順位では最上位となっているが，実行

性能への貢献を基にした順位では最下位に位置してい

る．このような極端な結果となった理由として，本実

験での貢献度スコアが，全ての評価属性の合計点を累

計したものであるからと考えられる．図 9 は Samuel

Giddins の各コミットポイントにおける，全ての評価属

性の合計点の推移を表したものである．性能向上に貢

献している部分も存在するが，最終的な累積点では大

きく貢献度を落としている．他にも編集行数という点

では上位に属している開発者が実行性能への貢献度で

はスコアがマイナスや 0 になっている場合があり，順

位を落としている．逆に編集行数という点で下位に位

置している開発者は，実行性能への貢献という点では

順位自体は上がっているが，そのほとんどがスコアは

0 点となっている．実行性能への貢献度の上位に位置

するのは編集行数の順位が中位以上の開発者である．

この傾向は実験対象の開発プロジェクトに共通して表

れている．

図 9 「bundler」開発者「Samuel Giddins」の貢献度

スコアの推移

以上の比較結果から編集行数を基にした貢献度と

提案方式で算出した実行性能への貢献度との間には隔

たりがあることがわかった．このことから本研究にお

いてプロダクトへの実質的な貢献度の指標とみなして

いるソフトウェアの実行性能への貢献度算出が可能で

あることが確認できた．

5. まとめ

本研究では，開発者のプロジェクトへの実質的な貢

献度評価を得られることを目的とし，ソフトウェア実

行性能分析の結果を用いた開発者のプロジェクトへの

貢献度算出手法について提案しその実現可能性を検証

した．

提案方式は開発プロジェクトにおいて開発中のソ

フトウェアを実際に実行することで，実行時間・CPU

使用率・メモリ使用量等の性能値をコミットごとに性

能分析し収集・累積することで各開発者のプロジェク

トへの実質的な貢献度を算出する．

実験では GitHub 上で複数人の開発者によって開発

されているプロジェクトを対象に提案方式を用いて貢

献度を算出し開発者の順位付けを行い，これと各開発

者のソースコードの総編集行数を基準とした順位付け

と比較した．比較結果からソースコードの編集量によ

る貢献度と実行性能への貢献度には隔たりが存在し，

提案方式によりソフトウェア性能改善に基づいた実質

的な貢献度を算出可能であることが確認できた．

今後の課題として，性能改善を行うソースコードの

編集難易度や開発プロジェクトの成熟度を分析するこ

とで，それに応じて貢献度スコアに重み付けを行い，

より詳細な貢献度分析を行うことが考えられる．

参 考 文 献 [1] “GitHub”, https://github.com/, 参照 Dec. 2017.

[2] “Bitbucket”, https://bitbucket.org/ , 参照 Dec. 2017.

[3] 李書，鷹野孝典，“分散バージョン管理システムの共同開発履歴に基づいた開発者の特徴抽出手法の検討 ”, 研究報告データベースシステム（DBS）, Vol. 2015-DBS-162, No. 1, pp.1－8, 2015.

[4] 五田篤志，山崎尚，玉田春昭，畑秀明，角田雅照，井垣宏 , “開発履歴による開発者特性とアンケートによる特性の自己診断の関連分析 , 研究報告ソフトウェア工学（SE）, Vol. 2015-SE-187, No. 5, pp.1－8, 2015.

[5] Emília, P. and Sergej, C. “Profile-driven source code exploration”, Computer Science and Information Systems (FedCSIS), 2015 Federated Conference on. IEEE, 2015.

[6] 山内一輝，阿萬裕久，川原稔 , “コード行数に基づいた開発者の貢献度とそのエントロピーを用いた OSS プロジェクトの分析 ”, 研究報告ソフトウェア工学（SE）, Vol. 2016-SE-193, No. 21, pp.1－6, 2016．

[7] “はてな ”, http://www.hatena.ne.jp/ , 参照 Dec. 2017.

[8] “日本語入力システム用はてなキーワード辞書 ”, http://web-apps.nbookmark.com/hatena-dic/, 参 照 Dec. 2017.

[9] “MeCab: Yet Another Part-of-Speech and Morphological Analyzer”, http://taku910.github.io/mecab/, 参照 Dec. 2017.

c783394b

bdef06e5-8

-7

-6

-5

-4

-3

-2

-1

0

1

2

貢献

度点

数

Commit ID