OfferBox用

1. コードレビューにおけるレビュワー間
の協調行動の分析
ソフトウェア工学研究室
北川 愼人
1

2. コードレビュー
• 複数のレビュワーが，ソフトウェアへの機能追加や不具合修
正を目的として作成されたソースコードを査読することにより，
ソースコードの中にバグや不具合が含まれているかどうかを
確認するプロセス．
2
1. 開発者がソース
コードを作成する
2. レビュワーがソース
コードを査読する
4. ソースコードが採用され
た場合，そのソースコー
ドはソフトウェアのプロ
グラムに統合される
3. ソースコードに不具合が見つかった
場合，レビュワーは開発者にソース
コードの修正を依頼する

3. 近年のコードレビュー
• 近年では，Gerritというコードレビューシステムを用いたコード
レビューも行われている．
3
• レビュワーは，レビュー票の
投稿者にレビューを依頼さ
れる．
• レビューは強制ではないた
め，レビューを行わないレ
ビュワーも存在する．

4. コードレビューの利益とコスト(1)
• レビュワーはソフトウェアの品質の向上を目的にコードレ
ビューを行っている[1]．
• コードレビューは仕事であるので，レビュワーはコードレビュー
を行うことにより自身の体力や時間を消費する.
4
レビュワーにとっての利益＝ソフトウェアの品質向上
レビュワーにとってのコスト
＝レビュワー自身の体力や時間の消費
[1] A. Bacchelli and C. Bird, “Expectations, outcomes, and challenges of modern code review,” in Proc. of 35th Int. Conf.
on Softw. Eng., ser. ICSE ’13. Piscataway, NJ, USA: IEEE Press, 2013, pp. 712–721.

5. コードレビューの利益とコスト(2)
• コードレビューが行われたソースコードの内，約15%のソース
コードで不具合が十分に修正されず，不具合の再修正が必要
とされている[2]．
• 2人以上のレビュワーにレビューされたソースコードは，1人の
レビュワーによってレビューされたソースコードに比べ，再修
正が必要となる不具合の数が少ないことが明らかにされてい
る[3]．
5
2人以上のレビュワーでコードレビューを行うことによって，将来
の仕事(コスト)を減らすことができる．
[2] E. Shihab, A. Ihara, Y. Kamei, W. M. Ibrahim, M. Ohira, B. Adams, A. E. Hassan, and K.-i. Matsumoto, “Studying re-
opened bugs in open source software,” Empirical Software Engineering, vol. 18, no. 5, pp. 1005–1042, 2012.
[3] S. McIntosh, Y. Kamei, B. Adams, and A. E. Hassan, “The impact of code review
coverage and code review participation on software quality: A case study of the qt, vtk, and itk projects,” in Proc. of 11th
Work. Conf. on Mining Softw. Repositories, ser. MSR 2014. New York, NY, USA: ACM, 2014, pp. 192–201.

6. コードレビューにおけるフリーライド
• 誰か一人でもレビューを行えば，ソフトウェアの品質向上とい
う利益をレビュワー全員が得ることができる．
• Qt，OpenStackともに，1人のレビュワーのみにでもレビューが行
われれば，ソースコードは採用・不採用が決定可能な状態となる．
• フリーライドとは，コストを支払わずに利益を得ること．
6
コードレビューには，レビュワーがフリーライドを
する状況が存在するのではないか？

7. フリーライドの実態調査
• 近年のコードレビューにおいて，レビュワーがフリーライドを
行っているか調査を行った．
• 調査対象
• Qtで行われたコードレビュー : 68,113件
• OpenStackで行われたコードレビュー : 86,549件
• コードレビューを大きく以下の3つに分類
• 2人以上のレビュワーがレビューを依頼され，最終的に２人以上のレ
ビュワーがレビューを行った．
• 2人以上のレビュワーがレビューを依頼され，最終的に1人のレビュワー
がレビューを行った．
• 2人以上のレビュワーがレビューを依頼され，最初から最後まで1人のレ
ビュワーがレビューを行った．
7

8. フリーライドの実態調査
• 近年のコードレビューにおいて，レビュワーがフリーライドを
行っているか調査を行った．
• 調査対象
• Qtで行われたコードレビュー : 68,113件
• OpenStackで行われたコードレビュー : 86,549件
• コードレビューを大きく以下の3つに分類
• 2人以上のレビュワーがレビューを依頼され，最終的に２人以上のレ
ビュワーがレビューを行った．
• 2人以上のレビュワーがレビューを依頼され，最終的に1人のレビュワー
がレビューを行った．
• 2人以上のレビュワーがレビューを依頼され，最初から最後まで1人のレ
ビュワーがレビューを行った．
8
フリーライドとみなす

9. 調査結果
• 2人以上のレビュワーがレビューを依頼され，最終的に２人以
上のレビュワーがレビューを行った．
• 2人以上のレビュワーがレビューを依頼され，最終的に1人の
レビュワーがレビューを行った．
• 2人以上のレビュワーがレビューを依頼され，最初から最後ま
で1人のレビュワーがレビューを行った．
9
Qt : 55,252件 (約81%) OpenStack : 67,537件 (約78%)
Qt : 12,042件 (約18%) OpenStack : 13,545件 (約15%)
Qt : 818件 (約1%) OpenStack : 6,075件 (約7%)

10. 調査結果
• 2人以上のレビュワーがレビューを依頼され，最終的に２人以
上のレビュワーがレビューを行った．
• 2人以上のレビュワーがレビューを依頼され，最終的に1人の
レビュワーがレビューを行った．
• 2人以上のレビュワーがレビューを依頼され，最初から最後ま
で1人のレビュワーがレビューを行った．
10
Qt : 55,252件 (約81%) OpenStack : 67,537件 (約78%)
Qt : 12,042件 (約18%) OpenStack : 13,545件 (約15%)
Qt : 818件 (約1%) OpenStack : 6,075件 (約7%)

11. フリーライドの実態
• Qtで約19%，OpenStackで約22%のコードレビューにおいて，
レビュワーのフリーライドが確認できた．
• よって，レビュワーはフリーライドを行うと考えられるが，レビュ
ワー全員がレビューを放棄すると，ソフトウェアの品質は永遠
に向上しない．
• そこで，レビュワーはレビューを実施したり，時に放棄したりと，
状況に応じて自身の行動を選択しているのではないか？
11

12. 研究目的・アプローチ
研究目的
• コードレビューにおけるレビュワーの協調行動の実態を理論
的に明らかにする．
アプローチ
• ゲーム理論を用いてレビュワー間での利益・コスト・戦略のや
りとりを数学的にモデル化する．
• コードレビューのゲームモデルとして，フリーライドが可能な状
況を表現するゲームモデルであるスノードリフトゲームを適用
する．
12

13. 戦略型ゲーム
13
戦略 A 戦略 B
戦略 A (効用値 A, 効用値 B) (効用値 C, 効用値 D)
戦略 B (効用値 E, 効用値 F) (効用値 G, 効用値 H)
プレイヤー B
プレイヤー A
• プレイヤー，戦略，効用値の３つの要素からなるゲーム
．
• 各プレイヤーの選択する戦略の組み合わせによって，各プレ
イヤーは対応する効用値(利益とコストからなる値)を得ること
ができる．

14. 補足：コードレビューの利益とコスト(1)
• レビュワーはソフトウェアの品質の向上を目的にコードレ
ビューを行っている[1]．
• コードレビューは仕事であるので，レビュワーはコードレビュー
を行うことにより自身の体力や時間を消費する.
14
レビュワーにとっての利益＝ソフトウェアの品質向上
レビュワーにとってのコスト
＝レビュワー自身の体力や時間の消費
[1] A. Bacchelli and C. Bird, “Expectations, outcomes, and challenges of modern code review,” in Proc. of 35th Int. Conf.
on Softw. Eng., ser. ICSE ’13. Piscataway, NJ, USA: IEEE Press, 2013, pp. 712–721.

15. 補足：コードレビューの利益とコスト(2)
• コードレビューが行われたソースコードの内，約15%のソース
コードで不具合が十分に修正されず，不具合の再修正が必要
とされている[2]．
• 2人以上のレビュワーにレビューされたソースコードは，1人の
レビュワーによってレビューされたソースコードに比べ，再修
正が必要となる不具合の数が少ないことが明らかにされてい
る[3]．
15
2人以上のレビュワーでコードレビューを行うことによって，将来
の仕事(コスト)を減らすことができる．
[2] E. Shihab, A. Ihara, Y. Kamei, W. M. Ibrahim, M. Ohira, B. Adams, A. E. Hassan, and K.-i. Matsumoto, “Studying re-
opened bugs in open source software,” Empirical Software Engineering, vol. 18, no. 5, pp. 1005–1042, 2012.
[3] S. McIntosh, Y. Kamei, B. Adams, and A. E. Hassan, “The impact of code review
coverage and code review participation on software quality: A case study of the qt, vtk, and itk projects,” in Proc. of 11th
Work. Conf. on Mining Softw. Repositories, ser. MSR 2014. New York, NY, USA: ACM, 2014, pp. 192–201.

16. コードレビューのゲームモデル(1)
16
レビュワーA レビュワーB
• 2人のレビュワーA,Bがあるパッチをレビューする状況を考え
る．
• もし，レビューをすればソフトウェアの品質を向上させることが
できるので利得bを得ることができるが，体力や時間を消耗す
るのでコストcがかかる．
• どちらか一方だけがレビューをすれば，もう一方のプレイヤー
も利得bを得ることができる．
• 2人で一緒にレビューをすれば，お互いにコストを半分に抑え
ることができる．

17. コードレビューのゲームモデル(2)
17
レビューする
(Cooperate, C)
レビューしない
(Defect, D)
レビューする
(Cooperate, C)
レビューしない
(Defect, D)
レビュワー B
レビュワー A
• このようなゲームモデルはスノードリフトゲームと呼ばれ，フ
リーライドが可能な状況を分析するゲームモデルとして知られ
ている[4][5]．
[4] R. Sugden, The Economics of Rights, Cooperation and Welfare, ser. The Economics of Rights, Co-operation and
Welfare. Palgrave Macmillan, 2005.
[5] C. Hauert and M. Doebeli, “Spatial structure often inhibits the evolution of cooperation in the snowdrift game,”
Nature, vol. 428, no. 6983, pp. 643– 646, 2004.

18. ナッシュ均衡
• 戦略型ゲームの解概念の1つであり，各プレイヤーの合理的
な戦略選択の結果である．
• 各プレイヤーが1つだけ戦略を選択する場合，その時のナッ
シュ均衡を純粋戦略ナッシュ均衡と呼ぶ．
18
レビューする
(Cooperate, C)
レビューしない
(Defect, D)
レビューする
(Cooperate, C)
レビューしない
(Defect, D)
レビュワー B
レビュワー A
純粋戦略ナッシュ均衡

19. 混合戦略ナッシュ均衡(1)
• 各プレイヤーがお互いの戦略選択確率に従って戦略を選択
する場合，その時のナッシュ均衡を混合戦略ナッシュ均衡と
呼ぶ．
19
レビューする
(Cooperate, C)
レビューしない
(Defect, D)
レビューする
(Cooperate, C)
レビューしない
(Defect, D)
レビュワー B
レビュワー A
p
1-p
q 1-q戦略選択確率

20. 混合戦略ナッシュ均衡(2)
• 混合戦略ナッシュ均衡は，戦略選択確率のグラフを用いて求
める．また，混合戦略ナッシュ均衡は，各プレイヤーの戦略選
択確率の組で表される．
20
※

21. コードレビューのゲーム理論による分析(1)
• 純粋戦略ナッシュ均衡から，レビュワーにとって，自身はレ
ビューせず，相手のレビュワーがレビューするのを待つのが
合理的な戦略である．
21
レビューする
(Cooperate, C)
レビューしない
(Defect, D)
レビューする
(Cooperate, C)
レビューしない
(Defect, D)
レビュワー B
レビュワー A
純粋戦略ナッシュ均衡

22. コードレビューのゲーム理論による分析(2)
• 実データから，実際のコードレビューは，
の均衡状態に陥っていると考えられる．
22
※

23. コードレビューのゲーム理論による分析(3)
• nの値が大きいほど(bの値がcより大きいほど)，各レビュワー
がレビューを行う確率は高くなる．
23
※

24. コードレビューのゲーム理論による分析(4)
• 混合戦略ナッシュ均衡の結果から，レビュワーは，利得がコス
トに比べて高いほど，相手のレビュワーと協調してレビューを
行うことが合理的である．
• 逆に，利得がコストに比べて低いほど，お互いのレビュワーは
レビューをしないことが合理的である．
24

25. 考察
• 未熟な開発者の作成したソースコードは，熟練した開発者の
作成したソースコードに比べて1.5から24倍ほど多くのバグが
含まれていることが報告されている[6]．
• 未熟な開発者の作成したソースコードは，熟練した開発者の
作成したソースコードに比べて2から19倍ほど長い期間，レ
ビューされずに放置される傾向が高いことが報告されている[7]．
25
[7] A. Bosu and J. C. Carver, “Impact of developer reputation on code review outcomes in oss projects: An empirical
investigation,” in Proc. of 8th ACM/IEEE Int. Symp. on Empirical Softw. Eng. and Measurement, ser. ESEM ’14. New
York, NY, USA: ACM, 2014, pp. 33:1–33:10.
[6] A. Bosu, “Characteristics of the vulnerable code changes identified through peer code review,” in Companion
Proceedings of the 36th International Conference on Software Engineering, ser. ICSE Companion 2014. New York, NY,
USA: ACM, 2014, pp. 736–738.
定量的な分析からも，利得が低い(コストが高い)ソースコードは，
レビューされずに放置される傾向にあることが報告されている．

26. まとめ
• 研究背景
• コードレビューにおいて，レビュワーがフリーライドを行っている状況が
存在する．
• 研究目的
• コードレビューにおけるレビュワーの協調行動の実態を理論的に明らか
にする．
• アプローチ
• コードレビューを行う状況をスノードリフトゲームでゲームモデル化して
分析する．
• 結果
• レビュワーにとって，1人のレビュワーがレビューを行うことが合理的で
ある．
• レビューをすることによって得られる利得がコストに比べて高ければ高
いほど2人のレビュワーがレビューを行うことが合理的である．
26