6.評価実験の結果

6.1 GitHub Flow演習におけるルール遵守状況の評価

6.1.1 ルールの違反率

表6.1.1-1にルールごとの違反率の平均を示す．

表 6.1.1-1 ルールごとの違反率の平均

違反率が最も高いルールはR5’であった．チーム開発における相互レビューが軽視される傾向にある．最も違反率が低いルールはR4’であった．今回の演習では，masterブランチへのマージの方法としてプルリクエストを使用するものしか説明していなかったためと考えられる．

表6.1.1-2に24リポジトリ全てのルールごとの違反率を示す．R1'，R2'，R5'の違反率が高い順にソートを行い，赤・黄色・緑の順に違反率が低くなるように色を付けた．

表 6.1.1-2 24リポジトリ全てのルールごとの違反率

1つのルールを違反しているとその他のルールも違反している傾向にある．

6.1.2 違反率の低いリポジトリと違反率の高いリポジトリ

図6.1.2-1は違反率が低い傾向にあるチームのリポジトリである．また，このリポジトリの各ルールの違反率を表6.1.2-1に示す．

表 6.1.2-1 違反率の低いリポジトリの各ルールの違反率

図 6.1.2-1 違反率の低いリポジトリのグラフ

ブランチの作成，コミット，プルリクエストの作成，レビュー，マージ，という一連の流れがスムースに行われており，開発者間のコミュニケーションが適切に取られていたことが見て取れる．

図6.1.2-2に違反率が高い傾向にあるチームのリポジトリを示す．また，このリポジトリの各ルールの違反率を表6.1.2-2に示す．

表 6.1.2-2 違反率の高いリポジトリの各ルールの違反率

図 6.1.2-2 違反率の低いリポジトリのグラフ

コミット履歴から分かるように，masterブランチへの直接コミットやmasterブランチ以外からのブランチの作成，といった違反行動が複数実施されている．また，プルリクエスト時にレビューを行わないマージが多数行われている．結果としてコミット履歴が非常に複雑になり，開発効率自体も低下する傾向が確認できた．実際に，2つのチームが同様の機能を実装するまでに作成したコミットの数は，図6.1.2-2の違反率の低いリポジトリでは32個，図6.1.2-2の違反率の高いリポジトリでは46個となった．この違いは，コミットを訂正するためのコミット及び他のブランチのコミットをあるブランチに取り込むためのマージコミットの数であった．リポジトリが複雑で把握しにくくなるほど，このような修正及びつじつま合わせのための行為が増えてしまう．そしてその行為がさらにリポジトリを複雑にするという悪循環に陥ってしまうのである．

6.2 チーム開発における遵守状況可視化の評価

6.2.1 ルールの違反率

本節では，チームAとチームBの違反率について述べる．

6.2.1.1 チームAの結果

本システム不使用時の1回目，システム使用時の2回目の評価実験における違反率を，それぞれ表6.2.1.1-1，表6.2.1.1-2に示す．

表 6.2.1.1-1 評価実験1回目の違反数

表 6.2.1.1-2 評価実験2回目の違反数

結果として，使用時，不使用時ともに違反率は低かった．開発は，GitHub Flowの講義を行った後にすぐに行ったため，GitHub Flowを遵守し易い状況となったのだと考えられる．

次に，1回目と2回目の評価実験のそれぞれのリポジトリを，それぞれ図6.2.1.1-1，図6.2.1.1-2に示す．

図 6.2.1.1-1 評価実験1回目のリポジトリ

図 6.2.1.1-2 評価実験2回目のリポジトリ

どちらも，6.1.2項で示した違反率の低いリポジトリに近いものとなった．

6.2.1.2 チームBの結果

本システム使用時の3回目，システム不使用時の4回目の評価実験における違反率を，それぞれ表6.2.1.2-1，表6.2.1.2-2に示す．

表 6.2.1.2-1 評価実験3回目の違反数

表 6.2.1.2-2 評価実験4回目の違反数

結果として，使用時，不使用時ともに違反率は低かった．チームAの評価実験の際と同様の理由だと考えられる．

次に，3回目と4回目の評価実験のそれぞれのリポジトリを，それぞれ図6.2.1.2-1，図6.2.1.2-2に示す．

図 6.2.1.2-1 評価実験3回目のリポジトリ

図 6.2.1.2-2 評価実験4回目のリポジトリ

チームAと同様に，どちらも6.1.2項で示した違反率の低いリポジトリに近いものとなった．

6.2.2 アンケートの結果

本節では，被験者から回収したアンケートについての結果を述べる．まず，5段階評価アンケートの結果を示し，次に文章で回答してもらった2つの設問についての結果を示す．

6.2.2.1 5段階評価アンケートの結果

5.2.4項で示したアンケートについての結果が，以下の表6.2.2.1-1である．1（まったくそう思わない）から５（まったくそう思う）の5段階で評価された結果の数を項目ごとに示した．数が多いほど濃い緑となるよう色を付けた．

表 6.2.2.1-1

本システムは複雑ではなく容易に利用できるという回答が多い．また，GitHub Flowの違反を確認でき，GitHubの理解度や遵守に対する意識の向上に貢献していることもわかる．しかし一方で，本システムの使用前に多くのことを学ぶ必要があり，さらに使用時には専門家のサポートを必要としたいという回答も多々ある．

6.2.2.2 このシステムの改善すべき点についての結果

まず，GitHub Flow遵守状況検出システムについて述べる．遵守状況の更新周期が長い．という回答があった．この周期は，GitHub上に存在する分析対象となるリポジトリとプルリクエストの情報を収集・加工しMySQLに格納するのにかかる時間より長く設定する必要がある．そのため，より高速なアルゴリズムの開発，または更新周期が開発履歴の収集・加工の時間に依存しないアーキテクチャ設計が必要である．

次に，可視化用Webアプリについて述べる．4.2.2項で述べたリポジトリやユーザを選択する際にすべてがリスト表示されてしまう．リポジトリの遵守状況を更新の際に再びリポジトリを選択しなければならない．遵守状況確認部分でそれぞれのルールがルール番号しか書かれておらず，具体的にどのようなルールなのかがわからない．という回答があった．システムを利用する人に寄り添ったデザインを設計する必要がある．

6.2.2.3 システムを利用したことによる利点

GitHub Flowを意識しながら開発できる．違反した場合，違反箇所をすぐに特定できる．違反をチーム内で指摘し改善を促すことが出来る．と回答した．本システムは，GitHub Flowの遵守率の向上に貢献することができたといえる．