日本ソフトウェア科学会第 38 回大会 (2021 年度) 講演論文集

ソフトウェア開発 PBL におけるマージコンフリクト調
査支援システムの開発
井出 岳人

浅野 耀介

古川 貴一

山田 侑樹

櫨山 淳雄

協調型のソフトウェア開発において，バージョン管理は重要である．これにより複数人で並行してソースコードを変更することが可能となる．並行開発における問題点として，同一ファイルを並行して編集したときなどに発生してしまう編集の競合 (以下，マージコンフリクトと記す) がある．複数人によるソフトウェア開発を行う実践的な教育にプロジェクト型ソフトウェア開発教育がある (以下，ソフトウェア開発 PBL と記す)．ソフトウェア開発 PBL で行われる活動として振り返りがある．ソフトウェア開発 PBL においてマージコンフリクトに関する振り返りを行うことが望ましい．しかし，マージコンフリクトには，マージコンフリクトを解消した時点で，マージコンフリクトがどこでどのように起こっていたかという履歴は残らないという特徴がある．マージコンフリクトに関する履歴が残らないことは，ソフトウェア開発 PBL における振り返り活動が十分に行えなくなる可能性がある．そこで本研究では，ソフトウェア開発 PBL におけるマージコンフリクトの振り返りを実現するために，ソフトウェア開発 PBL においてマージコンフリクトの実態調査を可能にするシステムを提案する．

Version management is important in collaborative software development. A version management systemenables a number of developers to change source codes concurrently. However, conflicts in the merge process
may occur in concurrent development. In recent years, project-based learning of software development isconducted as a practical education style. Reflection is an important activity in project-based learning ofsoftware development. It is desirable to do reflection regarding conflicts in the merge process. History of theconflicts will disappear when the conflicts are resolved. Reflection regarding conflicts in the merge process
becomes diﬃcult without the history of the conflicts. This study proposes a system to record histories ofconflicts in the merge process in concurrent software development.

ジェクトの進行に遅れを引き起こす要因となってしま

1 はじめにう可能性がある．Brun ら [1] ならびに Kasi と Sarma

協調型のソフトウェア開発において，バージョン管[2] はいくつかのオープンソースプロジェクトで，マー理は重要である．これにより複数人で並行してソースジコンフリクトがすべてのマージの約 19%で発生すコードを変更することが可能となる．並行開発におけることを発見した．また，Phillips ら [4] の研究による問題点として，同一ファイルを並行して編集したとると，ブランチとマージに関して，回答者の 54%が，きなどに発生してしまう編集の競合 (以下，マージコ

マージコンフリクトが最も重大な問題であると回答ンフリクトと記す) がある．マージコンフリクトが発している．ソフトウェア開発の技術向上を目的に情報生してしまうと，それを人手で解消しなければなら系の大学などで行われているソフトウェア開発 PBLないため，非常に多くの時間とコストがかかり，プロにおいて，振り返り活動が行われている [3]．しかし，マージコンフリクトには，マージコンフリクトを解消

A Support System for Investigating Merge Conflicts in
Project-Based Learning of Software Development.
This is an unrefereed paper. Copyrights belong tothe authors.
Taketo Ide, Yosuke Asano, Kiichi Furukawa, Yuki
Yamada, Atsuo Hazeyama, 東 京 学 芸 大 学, TokyoGakugei University.

した時点で，マージコンフリクトがどこでどのように起こっていたかという履歴は残らないという特徴がある．マージコンフリクトに関する履歴が残らないことは，ソフトウェア開発 PBL におけるマージコンフリクトに関する振り返り活動が十分に行えなくなることにつながる可能性がある．また，過去のソフ

表1

マージコンフリクトにおいて収集するデータ

トウェア開発 PBL におけるマージコンフリクト発生

リモートローカル

ファイル名

○

○

ユーザ

X

X

日時X

○環境

X

Xの履歴が確認できないことから，過去のソフトウェア開発 PBL におけるマージコンフリクトの実態を調査することは難しい．そのため，今後実施されるソフト
ウェア開発 PBL において実態を調査することが求められる．
本研究では，ソフトウェア開発 PBL におけるマーコマンド

X○

ジコンフリクトの振り返りを実現するための事前準発生の有無○○

備として，ソフトウェア開発 PBL においてマージコンフリクトの実態を調査できるシステムを開発する．

持つ役割に特徴はあるか

そして，本学で行われているソフトウェア開発 PBLにおいて運用することで，マージコンフリクトの実態

2. 3 マージコンフリクト発生のログ取得を調査できていることを確認する．

本研究では，2. 2 項で述べた調査を実現するために，ソフトウェア開発 PBL においてマージコンフリクト

2 研究のアプローチが発生した際，自動でログ取得を行う．調査に必要な

本節では，ソフトウェア開発 PBL におけるマージログのうち，本システムで取得するログは表１で○とコンフリクトがどのような場面で発生するのかを考したものである．

察し，それに合わせたシステムのあり方を述べる．

2. 4 開発環境との連携
2. 1 想定されるマージコンフリクト
マージコンフリクトは，それを引き起こす動作とリ

本研究では，ソフトウェア開発 PBL におけるマージコンフリクトの実態調査にあたって，ソフトウェアポジトリに注目すると，以下の 4 つに分類できる．

開発 PBL 参加者に過度な負担を求めないようにする

1. リモートリポジトリで Pull request を作成した

ため，ソフトウェア開発 PBL 参加者が使用する開発

場合

2. リモートリポジトリで Pull request をマージした場合環境の中にシステムを導入する．本研究では，開発環境として，リモートリポジトリとして GitHub†1 が使用されることを想定している．

3. ローカルリポジトリで git pull した場合

2. 4. 1 リモートリポジトリとの連携

4. ローカルリポジトリで git merge した場合

2. 1 項の 1, 2 で述べたようなマージコンフリクトが想定されることから，図 1 のように連携を行う．

2. 2 調査内容

システムは GitHub 上でマージコンフリクトを起

本研究における調査内容を以下に示す．

こしたことを検知し，当該の Pull request にラベル

RQ1： マージは何回実行されているかを貼り付ける．これによりマージコンフリクトが解消

RQ2： マージのうち，リモートリポジトリと，された後もラベルの有無を見れば，マージコンフリク

ローカルリポジトリで実行された割合はどうなっているか

トの履歴を確認できる．

2. 4. 2 ローカルリポジトリとの連携

RQ3： マージコンフリクトはリモートリポジトリ

2. 1 項の 3, 4 で述べたようなマージコンフリクトとローカルリポジトリにおいてそれぞれ何回発が想定されることから，図 2 のように連携を行う．

生したか

RQ4： マージコンフリクトが発生したファイルの†1 https://github.co.jp/

表2

グループ

リモート

ローカル

合計

A108

183291

B141

199

340

表3

図1

リモートリポジトリとの連携

マージ回数

マージコンフリクトの発生回数

グループ

リモート

ローカル

合計

A

11

415

B

10

3

13

3. 3 結果
システムの運用によって以下の結果 (表 2，表 3)が得られた．ただし，A グループ 1 名と B グループ

2 名が使用していた開発ツールにシステムが対応して
図2

ローカルリポジトリとの連携おらず，ローカルリポジトリにおいて十分に開発履歴を記録することができなかった．

マージコンフリクトが発生する可能性のあるコマンド (git pull または git merge) を入力する際に，そ3. 4 考察の出力結果を自動でローカルリポジトリ内のログファ

本システム運用期間中に確認できたマージは 631

イルに記録する．そのログファイルを収集し，分析す回であった (RQ1)．631 回のマージの内，リモートリることでマージコンフリクトが起こっていたかどうかポジトリで実行されたものが 249 回 (39.5%)，ローカを確認できる．

ルリポジトリで実行されたものが 382 回 (60.5%) であった (RQ2)．

3 運用と結果

システム運用中に取得できたマージコンフリクト

3. 1 システムの導入

は，リモートリポジトリで A グループが 11 回，B グ

本研究で開発したシステムを導入・運用を行ったのループが 10 回の計 21 回，ローカルリポジトリでは，は，2020 年度に本学で実施されたソフトウェア開発

A グループが 4 回，B グループが 3 回の計 7 回であっ

PBL に参加した学部 3 年生の 9 人で，4 人と 5 人の 2た (RQ3)．

グループ (それぞれを A, B グループとする) である．

マージ回数はローカルリポジトリの方が多かった
が，マージコンフリクトはリモートリポジトリで多3. 2 システムの導入
本研究では，ソフトウェア開発 PBL でコーディンく発生していた．また，マージコンフリクトが発生したファイルは文書ファイル †2 からプログラムファグに入る前の段階からシステムの導入を行い，コーイルまで様々であったが，画面を表示するファイルなディングが終了するまでシステムの運用を行った．まど１つのファイルで複数の機能に関係するファイルがた，運用したシステムについてソフトウェア開発 PBLあった．また，複数のファイルにおいて同時にマージ参加者にアンケートを行った．

コンフリクトが発生していることが多かった (RQ4)．
†2 当該 PBL では、多くの文書がマークダウン記法により，テキスト形式で作成されている．

よって，タスクの割当が適切であったかを振り返るこ運用を続けていき，マージコンフリクトの振り返りのとが大切である．しかし，調査数が十分とは言えない実現に向けて実態調査を進めていくことが求められので，今後もシステムを運用し，調査を継続していくる．

必要がある．
実施したアンケートでは，「提案システムが開発の謝辞 調査に協力いただいた受講生各位に感謝する．

妨げになると感じることはありましたか？」という問本研究の一部は科研費 20K12089 の助成の下で行わいに対して，妨げにならなかったという意見が多く，れた．記して謝意を表す．

ソフトウェア開発 PBL 参加者の過度な負担なくシステムが運用されたことを確認した．

4 まとめと今後の課題
本稿では，ソフトウェア開発 PBL においてマージコンフリクトの実態調査を行うために，リモートリポジトリとローカルリポジトリの 2 つの環境において，マージコンフリクトの履歴を自動で記録するシステムを開発し，本学で行われているソフトウェア開発 PBL において運用を行った．運用の結果，ソフト
ウェア開発 PBL 参加者の過度な負担なくマージコンフリクトの実態調査を行うことができていることを確認した．また，ソフトウェア開発 PBL において実際にマージコンフリクトが起こっていることを確認した．
今後は，システムの改良を進め，また，システムの参 考 文 献[1] Brun, Y., Holmes, R., Ernst, M. D., and Notkin,
D.: Proactive detection of collaboration conflicts,
Proceedings of the 19th ACM SIGSOFT symposium
and the 13th European conference on Foundationsof software engineering, 2011, pp. 168–178.
[2] Kasi, B. K. and Sarma, A.: Cassandra: Proactive conflict minimization through optimized taskscheduling, Proceedings of the 2013 35th International Conference on Software Engineering (ICSE),
IEEE, 2013, pp. 732–741.
[3] 眞鍋雄貴，井垣宏，福安直樹，佐伯幸郎，楠本真二,
井上克郎: ソフトウェア開発 PBL における正確な根拠に基づいた振り返りのためのプロジェクトロギングにおけるエラー検出支援, Proc. SES2012 ワークショップ,2012.
[4] Phillips, S., Sillito, J., and Walker, R.: Branching
and merging: an investigation into current version
control practices, Proceedings of the 4th International Workshop on Cooperative and Human Aspects of Software Engineering, 2011, pp. 9–15.