事例 4

事例4では，プロジェクト「パズルD」において，ソースファイル

PuyoStateM-anager.javaを約6分間編集した開発期間を取り上げる．このソースファイルには，

パズルピースの操作や状態の管理を行うクラス（PuyoStateManager）が定義され ており，この開発期間ではパズルピースの移動処理を表すtranslatePuyo(int, int)メソッドに対して，パズルピースの補正処理の修正やメソッドのリファクタ

表 6.6: 事例4における検出結果

CID 開始 終了 検出結果 1M 3S 変更タスク

1138 13:02:54 13:02:54 CMB CMB CMB 1. パズルピースの補正処理の修正

1139 13:03:01 13:03:01 CMB

1140 13:03:17 13:03:17 CMB CMB

1141 13:03:22 13:03:22 CMB

1142 13:05:12 13:05:12 CMB CMB 1143 13:05:16 13:05:16 CMB

1144 13:05:34 13:05:52 CMB 2. メソッドのリファクタリング

1145 13:06:26 13:06:26 CMB 1146 13:06:28 13:06:28 CMB 1147 13:06:37 13:06:53 CMB 1148 13:06:54 13:06:54 CMB 1149 13:06:58 13:06:58 CMB 1150 13:07:09 13:07:09 CMB

1151 13:07:14 13:07:14 CMB CMB

1152 13:07:17 13:07:17 CMB

1153 13:07:24 13:07:24 CMB CMB

1154 13:07:33 13:07:33 CMB 1155 13:07:37 13:07:37 CMB 1156 13:07:44 13:07:44 CMB 1157 13:07:50 13:07:50 CMB 1158 13:07:53 13:07:53 CMB 1159 13:07:57 13:07:57 CMB 1160 13:08:09 13:08:09 CMB 1161 13:08:15 13:08:15 CMB 1162 13:08:24 13:08:24 CMB

1163 13:08:31 13:08:31 CMB CMB

1164 13:08:35 13:08:35 CMB 1165 13:08:38 13:08:38 CMB 1166 13:08:43 13:08:43 CMB 1167 13:08:46 13:08:46 CMB 1168 13:08:49 13:08:49 CMB

6.3. 定性的評価 77 リングが行われていた．事例4における検出結果を表 6.6に示す．

各タスクについて，変更タスク「1. パズルピースの補正処理の修正」では，操 作中のパズルピースをゲームフィールドの外に補正する際に，パズルピース自身 の幅や高さを考慮していなかったため，それを考慮した補正を行うように修正し ていた．

変更タスク「2. メソッドのリファクタリング」では，メソッドの可読性を向上 のために，2つの説明用変数の導入（複雑な式を適切な名前のついた変数へ置き換 えること）が並列に行われていた．この開発期間では，メソッド内ですでに導入 されていた説明用変数の名前変更や，別の説明用変数の導入も行おうとしていた ようだが，それらは最終的には開発者によって手動で取り消された．

本事例は開発期間が約6分程度で，定義された変更タスクも2つだけであり，非 常に小さい規模の開発期間だといえる．それにもかかわらず，この開発期間では 31個のCMBが検出されてしまっている．特に，変更タスク2については，メソッ ドの可読性の向上を目的としたメソッドの振る舞いを変化させない編集が行われ ており，ソフトウェアを開発・拡張・修正するような直接的な変更内容でないにも かかわらずその変更タスクによるプログラム変更が25個も検出されており，開発 者や保守者がこれらのプログラム変更をすべて閲覧していくことは時間の掛かる 作業となる．

1Mによる集約において，変更タスク2を１つのプログラム変更（CID=1142∼CID

=1168）として集約していることから，開発者や保守者のプログラム変更の閲覧

の手間を軽減できているといえる．しかし，このプログラム変更の中に変更タス ク2によるプログラム変更だけでなく変更タスク1によるプログラム変更が混ざ り合っている点や変更タスク1による変更の全てを1つのプログラム変更に集約 できていない点では，開発者や保守者にとって適切な集約ができているとは言い がたく，開発者や保守者を混乱させ，これらの変更を解きほぐす余計な手間を増 やす原因を作りだしてしまっているといえる．

1Mによる集約が失敗した変更タスク1による変更とその直後の変更（CID=1138∼ CID=1144）の変更内容を詳しく見てみると，CID=1138∼CID=1141のプログラ ム変更で，1箇所を除いたすべてのパズルピースの補正処理の修正が完了してお

り，CID=1142∼CID=1143のプログラム変更でパズルピースの補正処理で残され

た部分を修正していた．そして，CID=1144の変更では変更タスク2における説 明用変数の導入のための変数が定義され，それ以降は変更タスク2のための変更 が続いていた．CID=1141とCID=1142の間では約2分間ほど編集操作が行われ たかった期間があり，それに対してCID=1143とCID=1144の間では十数秒の休 止しかなかった．

CID=1138∼CID=1141で1箇所だけ不自然に補正処理の修正が残されており，

図 6.1: 事例4の開発期間における初期状態のソースコード

CID=1142∼CID=1143でその修正箇所が修正されているため，その間の開発者に

よって編集操作の行われていなかった約2分の間にコードのレビューやプログラ ムの実行によって修正が正しく行われたのかの確認が行われ，その際に修正箇所 の漏れに気づいて修正したように見えた．そして修正漏れを直した後，コードの レビューや動作の検証などに時間をかけずに変更タスク2に移ったのではないか と思われる．

事例1でも述べたように，開発中にいつ，どのような理由で開発者の編集操作 が止まるかを完全に予想することはできない．そして時間的距離による集約はそ のような不確実な要素を持つ情報を基準に集約を行うため，このような誤検出を 発生する可能性は常に存在する．

3Sによる集約では，変更タスク1による変更のそれぞれは2つのプログラム変 更へ集約され，変更タスク2による変更のそれぞれは4つのプログラム変更へ集 約されてしまっている．また，CID=1142∼CID=1143における3Sによる集約の 結果を見ても変更タスク1と2が混ざり合った状態となっており，個々の変更タス クとはかけ離れた集約結果となってしまっている．

本事例で3Sによる集約で誤検出が増えた原因の1つとして，本事例のコードの 中で互いに空間的距離が離れた位置にある複数の文が，同じ変更タスクによって 同時に書き換えられた点があげられる．

本事例の開発期間における初期状態のソースコードを図6.1に示す．図ではコー

6.3. 定性的評価 79 ドの見やすさのために，空白文字によって一部の文のスタイルを調整し行頭に行 番号を付加している．このコードでは，変数の宣言のあとに4つのif文が存在し，

それぞれのif文の中に単一の文が存在しており，これらの文によってx座標の下 端の補正と上端の補正，y座標の下端の補正と上端の補正がそれぞれ行われてい る．その後，補正された値を使ってパズルピースを移動させている．

図 6.1のようなコードでは，4行目∼5行目，6行目∼7行目，8行目∼9行目，10 行目∼11行目に存在するif文の間のそれぞれの空間的距離はすべて3となる．そ のため，これらの文から別のこれらの文のどれかに編集箇所が移動するたびに，3S による集約では別のプログラム変更として集約されてしまう．具体的に見ていく と，CID=1139が7行目，CID=1140が11行目でこの2つは別のプログラム変更 として集約され，同様にCID=1150とCID=1151が4行目と6行目で，CID=1152 とCID=1153が6行目と5行目で，CID=1162とCID=1163が9行目と10行目で それぞれ別のプログラム変更として集約されていた．

また，3Sによる集約のもう一つの誤検出として，それぞれ別の変更タスクによ る変更であるCID=1143とCID=1144について，同じプログラム変更として集約 してしまったというものがある．2つの変更の編集箇所を見ると，CID=1143が10

行目，CID=1144が3行目と4行目の間に説明用変数の宣言文を挿入しており，こ

れらの空間的距離は2となりこの2つの変更は1つのプログラム変更として集約 されてしまっていた．

空間的距離は，「ある変更タスクによって行われた変更の変更範囲はすべて狭い 範囲の中で行われ，ある変更タスクと別の変更タスクによって行われた変更のそ れらの変更範囲はお互いに離れる傾向にある」という仮説を前提としているため，

事例2でも述べたように空間的距離の結果は変更タスクとソースコードの構造と の関係に依存しやすい．しかし本事例の変更タスク1と2から，お互いのタスクに よる変更の変更範囲が離れない場合は同じ変更タスクによる変更とみなして誤っ た集約をしてしまう傾向にあることが考察できる．