5.評価実験
本章では,実施した2つの評価実験について詳述する.
5.1 GitHub Flow演習におけるルール遵守状況の評価
大阪工業大学で実施したGitHub Flow演習を対象として各ルールの遵守状況を評価した.演習はProcessing16を用いた簡単なゲームを4~5名で構成されるチームでGitHub Flowにもとづいて開発するものである.開発期間は授業時間6時間(1週あたり3時間)+授業外期間(締め切りまで10日程度)で,6時間のうち3時間程度をGit及びGitHub Flowの説明やツールの使い方についての簡単な演習にあてた.開発にはGitHub公式のGitクライアントであるGitHub Desktop17を使用した.GitHub Desktopではマージは原則としてno fast forwardに行われる(プル時のマージはfast forward).なお,演習開始時点でGitを利用していた経験がある学生はいなかった.また,GitHub Flowのルール説明時はオリジナルのものと改定後のものと両方について言及している.
本実験では,24チームのリポジトリを対象として分析を行った.これらのリポジトリは合計コミット数が1165,プルリクエスト数433,レビューコメント数が346存在した.分析に要した時間は14分47秒である.ただし,この時間にはリポジトリをクローンまたはプルする時間は含まれていない.また,この分析は開発期間終了後に行ったため,R3’は評価の対象外とする.
5.2 チーム開発における遵守状況可視化の評価
チーム開発における本システムの使用時と不使用時での違反率の違いを確認した.また,Webアプリについてのウェブユーザビリティの評価をSUS(System Usability Scale)[Usability.gov][Yukihito]を利用したアンケートと,本システムについての独自のアンケートを収集した.開発内容は簡単な2種類のWebアプリであり,詳細は以降で述べる.開発人数は6人で,3人ずつAチームとBチームに分類する.想定開発時間は1時間半であり,開発環境としてGitHub Desktopを使用した.評価実験は4回行う.1回目2回目ではシステム不使用時システム使用時の順にAチームが開発し,3回目4回目ではシステム使用時システム不使用時の順にBチームが開発した.また,奇数回と偶数回の開発内容はそれぞれ同様のものである.
1回目の評価実験では3時間30分,2回目では2時間30分で開発が終了した.3回目の実験では1時間30分,4回目では2時間で開発が終了した.これらの時間には,マニュアルの不備等についての対応も含んでいる.
5.2.1 準備
開発するのは,DWRを用いたToDo管理Webアプリケーション,VB(Visual Basic)18を用いた在庫管理アプリケーションである.被験者は,開発マニュアルに従い,こちらが用意したテンプレートに指定したソースコード及びファイルを追記して開発を行う.ソースコードはGitHubのリポジトリで管理し,そのリポジトリを対象に本システムを用いてGitHub Flow遵守状況の分析,可視化を行った.
開発手順は,開発者である3人それぞれがコンフリクトを起こさないように大きく3つに分割されており,これを大タスクとする.この大タスクをそれぞれの開発者が担当する.大タスクは,更に3つに分割されており,これを中タスクとする.中タスクごとにブランチを作成させる.中タスクも更にいくつかに分割され,これを小タスクとする.小タスクごとにコミットを行わせる.したがって,各開発者が3つのブランチを作成し,リポジトリ全体ではmasterブランチ以外に9つのブランチ存在することになる.
小タスクの一例を以下に示す.リスト5.2-1が用意されたテンプレートであり,リスト5.2.1-2が指定したソースコードを記述した後ものである.
リスト5.2.1-1 用意されたテンプレート
public static void main(String[] args) {
}
リスト5.2.1-2 ソースコード記述後
public static void main(String[] args) {
memberListener pl = new memberListener();
for(memberManager pm:pl.memberListen()) {
System.out.println("ID:"+pm.getId());
System.out.println("Name:"+pm.getName());
System.out.println("Org:"+pm.getOrg());
System.out.println("Position:"+pm.getPosition());
System.out.println("Age:"+pm.getAge());
}
}
開発を行う前に,GitHub Flowについての講義を行った.改定後のルールについても言及している.これら説明は4.2.2項で示したようにWebページ化されており開発中でも参照できる.同様に,GitHub Flow遵守状況可視化用Webアプリの使用方法の説明を行った.これも開発中に参照できる.
以降では,開発するアプリケーションであるDWRを用いたToDo管理Webアプリ,VBを用いた在庫管理アプリの詳細について述べる.
5.2.2 DWRを用いたToDo管理Webアプリケーション
本アプリケーションはDWRを用いたToDo管理Webアプリケーションであり,todoリストを管理するtodo.html,メンバーを管理するmember.html,プロジェクトを管理するproject.htmlで構成されている.図5.2.2-1に,想定する完成後のプロジェクト管理ページを示す.
図5.2.2-1 想定した完成ページ
被験者は開発マニュアルに従い,サーバサイドや各ページなどを開発をする.合計40コミット程になるように設計した.
5.2.3 VBを用いた在庫管理アプリケーション
本アプリケーションはVBを用いたデータベースプログラミング技術書[tanijiri2003]を参考に作成した在庫管理アプリケーションであり,伝票管理,顧客管理,社員管理,商品管理,検索機能の5つの機能で構成される.図5.2.3-1に,想定する完成後のページを示す.
図5.2.3-1 想定した完成ページ
被験者は開発マニュアルに従い,データベース操作機能や商品グループのフィルタや値段のソート機能などを開発する.合計39コミット程になるように設計した.
5.2.4 アンケート
実験終了後に被験者に,以下の表5.2.4-1の15の評価項目について,1(まったくそう思わない)から5(まったくそう思う)の5段階で評価してもらう.なお,質問No1からNo10は,SUSを参考に作成されたものである.
表 5.2.4-1 アンケート
質問No | 評価項目 |
---|---|
1 | このシステムをしばしば使いたいと思う |
2 | このシステムは不必要なほど複雑であると感じた |
3 | このシステムは容易に使えると思った |
4 | このシステムを使うのに技術専門家のサポートが必要とするかもしれない |
5 | このシステムにあるさまざまな機能がよくまとまっていると感じた |
6 | このシステムでは,一貫性のないところが多くあったとおもった |
7 | たいていのユーザは,このシステムの仕様方法について,素早く学べるだろう |
8 | このシステムはとても扱いにくいと思った |
9 | このシステムを使うのに自信があると感じた |
10 | このシステムを使い始める前に多くのことを学ぶ必要があった |
11 | ツールを使ったことによって違反の検出がしやすくなったと感じた |
12 | 実際に違反箇所を確認することができた |
13 | GitHub Flowを守ろうとすることにこのツールの利用が役立った |
14 | 違反を指摘されたことによってGitHub Flowの理解が深まった |
15 | 今後GitHub Flowを遵守しようと思いましたか |
また,システムの改善点,システムを利用したことによる利点や感想を文章で記述してもらう.
16. Processing.org, https://processing.org/ ↩
17. GitHub Desktop, https://desktop.github.com/ ↩
18. Visual Basic - MSDN, https://msdn.microsoft.com/ja-jp/library/2x7h1hfk(v=vs.120).aspx ↩