情報処理学会 インタラクション 2014
IPSJ Interaction 2014

B3-1
2014/2/28

分散開発のための手書き注釈ログの俯瞰によるプログラム理解支援
秀毛 嶺維馬1,a)

奥野 拓2

概要：ソフトウェア開発では，他者が書いたプログラムを読解する場面がある．特にドキュメントやコメント，テストケースが整っていないソースコードを編集する場合，無用な試行錯誤を避けるため，実装の意図を理解する必要がある．そこで分散ペアプログラミング中に交わされるコミュニケーションに注目し，そのログを用いて実装意図の理解を支援する．先行研究では，意図理解に無関係なログの存在が課題となっている．本稿では，このログのノイズが手書き注釈を付記する最中は少ないことに着目し，課題解決を図る．提案手法の検証のため，分散ペアプログラミングの試行を観察し，検証範囲内での有効性を確認した．その結果や考察について述べていく．

Understanding Support of Programs by Overview of Handwritten Logs
for Distributed Development
Reima SHUKE1,a)Taku OKUNO2

Abstract: During developing software, a programmer often read and understand program written by otherprogrammers.When a programmer edit a source program without documents, comments or test cases, he/sheneeds to understand intention of a source program. This is because, if the programmer doesn’t understandit, he/she will do wasteful trial and error.We support understanding the intension of the source program byusing communication logs in distributed pair programming. Previous studies indicate that useless logs prevent understanding the intention.This paper focuses on the experimental result that few useless logs foundnear handwritten annotations.We observe the works of distributed programming to inspect the proposed
technique and conﬁrm eﬃciency in this examination.

1. はじめにを読解しなければならない状況が発生する．特に，コードレビューやシステムの機能拡張の際には，プログラムの細離れた二者が共にコーディングする分散ペアプログラミかな理解が必要である．一般的には，ソースコード中のコングという手法がある [1]．この手法では，作業者の間で交メントやドキュメント，実装の担当者の説明をプログラムわされるコミュニケーションの記録が容易である．通常の理解に活用する．しかしこれらの手がかりが無い場合，プ

分散ペアプログラミングでは作業者らのコミュニケーショログラムの理解には非常に時間が掛かる．

ンは意図伝達以上に活用されることはない．しかし，コー

本稿ではこの問題に対して，分散ペアプログラミングのディング時のコミュニケーションには作業者らの意思決定コミュニケーションログを用いてプログラムの理解支援をが含まれているため，何らかの活用が考えられる．

行う．特に手書きの注釈によるコミュニケーションに焦点

ソフトウェア開発において，他者が書いたソースコード
12a)

公立はこだて未来大学大学院
Graduate School of Future University Hakodate
公立はこだて未来大学
Future University Hakodate
g2112020@fun.ac.jp© 2014 Information Processing Society of Japanをあて，本稿ではその有効性について述べていく．

2. 分散開発におけるプログラム理解支援
2.1 プログラム理解支援の必要性
ソフトウェアの開発において，開発メンバが分散する

429

表 1
対話手法

対話手法毎の利用状況
利用状況

頻度

テキストチャット

Web サイトの文章の引用

低

音声通話

ソースコードの説明

高ケースがある．有志によるオープンソースソフトウェアの開発や，海外や国内に開発の一部を委ねるオフショア開発・ニアショア開発はその一つの例である．この分散開発
では，一つの場所に集合して開発する場合に比べ，密なコミュニケーションが取りにくい．コミュニケーションはグ

疑問点への問いかけや対応
手書き注釈

図表による音声通話の補助

ループウェアを介して行う必要があり，直接対話するよ

記号による注目点の指示りも手間が掛かる．そのため，分散開発ではコミュニケー気づいたことのメモ中ションロスが発生しやすい状況にあると言える．
特にプログラムの実装においては，密に連携できないこプ数の多いソースコードや頻繁に編集されたソースコードとが作業効率に影響する．例えば他人が実装したソースは編集操作履歴の量が膨大となるため，ソースコードの特コードをリファクタリングする際，実装されたコードに疑定箇所を参照するのに時間がかかる．

問が生じても，開発担当者への照会に時間が掛かる．また，開発ドキュメントのメンテナンス不足や内容が十分ではな

3.2 編集理由の類推い場合，ソースコードの保守は困難になる．したがって，編集操作履歴には，コミットメッセージのように何を意

作業者個人で利用可能なソースコード理解手法が必要だと図して変更されたかは記述されていない．版管理システム考えられる．

ではコミットメッセージを残すことができるが，ソースコード一行単位でどのような意図をもって変更されたかは2.2 既存のプログラム理解の手法
一般に，クラスやメソッドの仕様を理解するには，開発ドキュメントの読解を行う．また，デバッガを利用して変数の状態を監視する，テストケースから仕様を推測するなどといった方法もある．ソフトウェアの保守作業においては，そのソースコードがどのように変更されてきたかを知る必要がある．

類推するしかない．ソースコードの細かい部分の変更意図を知りたい場合，編集操作履歴やコミットメッセージでは不十分である．

4. プログラム理解支援の関連研究
編集操作履歴の調査時間を短縮する手法として，大森らが提案した編集操作再生器がある [3]．これは，編集操作履

そこで版管理システムを利用したソフトウェア開発で歴から任意の時点のソースコードエディタを再現することは，ソースコードの変遷を知るためにコミットログを参照ができる．さらに，編集操作履歴の内容を時系列に並べ、する．コミットログにはソースコードの差分の他，ソース利用者に図示する．大森らの行った評価実験では，提案手コードの変更理由などをコミットメッセージとして残し法を用いない場合 8 分掛かっていた調査時間が，1 分に短ておける．しかし，このコミットメッセージの有無は作業縮されたという結果が得られている．このタイムラインに者に依存するため，必ずしも付けられるものではない．まよる編集操作履歴の視覚化は，編集操作履歴の調査時間のた，その内容が適切に更新内容を説明しているとも限らな短縮に貢献するものだと考えられる．

い．さらに，詳細なソースコードの変化を追うためには，コミット単位の調査では不十分である．

次に，編集理由の類推を支援する手法として，西川らの提案したコミュニケーションログの利用がある [4]．西川

版間で同じソースコードを何度も編集されていても，そらは分散ペアプログラミング中に交わされるコミュニケーの試行錯誤は記録には残らない．その試行錯誤の経過を辿ションが編集理由の類推に有用と考え，テキストチャットることで開発者の意図を探ることが可能と考えられるが，と編集操作履歴を紐付けて提示するという手法を提案しコミット単位の記録ではそのような調査は行えない．そこた．この手法の評価実験では，編集操作履歴の 68.8 ％がテで，統合開発環境への入力を記録した編集操作履歴を利用キストチャットのログとほぼ対応すると評価された．しかすることが試みられている [2]．編集操作履歴を利用するこ

し，テキストチャットのログには，相槌やコーディングととで，ソースコードの変化をより詳細に追うことができる．

は無関係な対話など不必要な情報が含まれる．これらは，しかし，この編集操作履歴にも幾つかの課題が存在する．

目的の情報を見付けるためのノイズとなる．そのため、こ3. 編集操作履歴によるソースコード変遷追跡における課題
3.1 編集操作履歴の量れらのノイズを取り除くような工夫が必要である。

5. 手書き注釈ログを利用したプログラム理解
支援プログラムの統合開発環境では，ファイル内容の変更差

本稿では 3 節で述べた編集操作履歴の読解に関する問題分が編集操作履歴として残される．この編集操作履歴から，解決に取り組む．以下に既存の支援手法と問題解決のためソースコードの変遷を追うことができる．しかし，ステッの提案を述べる．

© 2014 Information Processing Society of Japan430

グラミングに利用したツールから各種ログを収集する．具
体的には，統合開発環境からは編集操作履歴，手書き注釈
アプリケーションからは手書き注釈ログ，チャットクライ
アントからは通話ログを収集する．そしてソフトウェア保守フェーズで，保守担当者がログをビューワから視聴する．
このビューワは大森らの編集操作再生機と同様，編集操作履歴をもとに，任意の時点のソースコードエディタを再現する．エディタの下部の作業タイムラインからは，コードの編集と手書き注釈が付記された時刻を把握できる．また，動画のように任意の時点から音声通話記録を再生でき
図 1

コードに付記された手書き注釈

る．保守担当者はエディタ下部のグラフを頼りに目的の編集箇所を探索する．そして，手書き注釈が付記されている付近の音声通話記録を視聴し，これをプログラム理解の手がかりとする．

6. 手書き注釈アプリケーションの実装
本節では提案の検証のため試作した手書き注釈アプリ
ケーションについて述べる．

6.1 注釈の付与と作業者間の同期
本アプリケーションを用いて，ユーザはソースコードエディタの任意のタブに半透明なレイヤを貼り付ける．このレイヤは手書き注釈を付記するために用いられる．レイヤ
図 2

提案システムの全体図には手書き注釈を付記できる描画モードと，レイヤに注釈を残したままソースコードエディタの操作ができる編集

5.1 手書き注釈ログの利用モードがある．モードの変更はキーボードの特定のキーを本研究では編集理由の類推の簡易化という課題に対して，押下することで行われる．描画モード時，ユーザがレイヤ手書き注釈によるコミュニケーションログに注目した．こ上でマウスクリック，ドラッグするとその軌跡がレイヤにこでの手書き注釈とは，図 1 のようにソースコード上に付残る．また，同様に特定のキーを押下することで注釈の一記された文字や下線，記号を指す．表 1 は分散ペアプログ

括削除や描画のアンドゥができる．

ラミングにおいて，テキストチャット，音声通話，手書き線描の入力が終わると，マウスのリリースをトリガーに注釈がそれぞれどのような状況で使われるかを示したもの

して共同作業者の PC に座標データが送信される．この描である [1]．利用の容易さや頻度から，相槌やコーディン

画データはソケット通信によってやりとりされる．常に相グと無関係な会話など，ノイズとなりうる情報が一番多く手の通信を待ち受けることで，レイヤの同期を行う．

含まれているのは音声通話だと予測できる．一方で，手書き注釈は注目点の指示や気付きの伝達に利用されている．

6.2 手書き注釈ログのアウトプット

多くはソースコードの一部分に関する説明を補助すること

5.2 節で述べた作業タイムラインの実現のため，手書きに使われている．そのため，手書き注釈により補助された注釈アプリケーションにログのアウトプット機能を実装

音声通話は，プログラムの編集理由の類推に有用と考えらした．アウトプットするログには，注釈の座標や付記したれる．

ユーザの IP，色，タイムスタンプが含まれる．これらのログはアプリケーションの終了後，または任意のタイミング

5.2 編集操作履歴と手書き注釈ログの可視化
5.1 節から，手書き注釈が付けられた付近の音声通話を抽出することで，プログラム理解に有用な対話をユーザにで CSV 形式で書き出される．

7. 手書き注釈の有効性検証提示できると考えられる．そこで，編集操作履歴とコミュ

5 節で述べた，手書き注釈を利用したプログラム理解支ニケーションログを収集し，ユーザにそのログを提示する

援手法の有効性を測るために，2 つの検証を行った．以下

システムを提案する．システムの全体図を図 2 に示す．にその方法と結果について述べる．

まずソフトウェア開発フェーズにおいて，分散ペアプロ© 2014 Information Processing Society of Japan431

表 2

検証 1 の試行結果

図 3 のペア 1 における記録から，手書き注釈が付記された前後でコード変更理由となる対話がされていたと読み取

所要時間

手書き注釈

注釈数

ペア 107m05s

あり

15

ペア 209m05s

なし-れる．今回の試行では，付記された注釈はソースコードの特定箇所を指すために利用されていた．被験者の発言内容を観察すると，コード変更前はバグの出所について話されていた．またソースコード変更後は，その時の変更がどのような物だったかソースコードに注釈を付記しながら話されていた．手書き注釈の無いペア 2 の試行からは，コード変更数が手書き注釈を利用した場合に比べ多いことが読み取れる．こちらもコード変更の前後でソースコード変更の手がかりとなる内容の対話がされていた．

7.1.3 考察図 3

検証 1 における被験者の作業タイムライン

この検証で行われた試行では，仮説の通り，手書き注釈の付記された前後でコード変更理由となる対話がされて7.1 検証 1：注釈の前後の対話に関する検証

いた．手書き注釈が無い場合は，コード変更理由となる対

5.1 節から，手書き注釈が付けられた付近に，ソースコー話は実際にコード変更された前後でされていた．しかし，ド変更理由の類推に有用な対話があると仮説を立てた．こ

コード変更の回数が手書き注釈有りの場合に比べ増加しの仮説を検証するため，実験を行った．また，注釈の有無た．これは，言葉で伝えるより先に一時的にソースコードによるログの変化も考察した．

を変更して，結果を協調作業者に見せていたためである．

7.1.1 実験方法

手書き注釈が無い場合でもコードが変更された前後の対話

被験者には講義で Java プログラミングの基礎を履修しを参照すれば，コード変更理由の類推は可能であると考えた，情報系大学の学部生 4 名を選んだ．この 4 名で二組のられる．しかし，一時的な変更によってコード変更箇所がペアを作り，分散ペアプログラミングで Java で書かれた増加し，変更履歴が冗長になった．後にプログラム理解をプログラムのデバッグを行わせた．

するにあたって，変更履歴は少ないほど調査する時間が減

課題にはサイコロのように 1 から 6 をランダムに出力する，20 ステップ程のソースコードを用意した．このソース少する．そのため両者を比較した場合，手書き注釈がある方が優位と考えられる．

コードにはシンタックスエラーは無いが，仕様とは異なる3 つのバグが存在している．デバッグを行うクラスファイ
ルの他にテストケースを用意し，このテストを通過するまでを試行とした．
被験者らは二組ともコーディングには統合開発環境を利

7.2 検証 2：長時間の試行での検証
7.1 節で行った検証は，試行時間が 10 分以内と短いものだった．そのため交わされた対話が少なく，提案手法が有効な条件を確認するには至らなかった．そこで課題の難易用したが，コミュニケーションの手段に差を設けた．一方

度を上げ，再度実験・考察を行った．

はテキストチャットと音声通話を利用した．もう一方はそ

7.2.1 実験方法

れらに加え，手書き注釈によるコミュニケーションを行っ被験者には情報系の大学院生 2 名を選んだ．被験者 1 はた．手書き注釈の付記には，ペンタブレットを利用した．

講義以外でも Java アプリケーションの実装経験があるが，分散ペアプログラミングでは，作業者はソースコードを被験者 2 は講義以外では Java はほぼ扱っていなかった．

編集する実装役とアドバイスを行う補助役に役割が分かれ

この二人でペアを組み，分散ペアプログラミングを行った．

る．通常，15 分から 30 分でこの役割は交代するが，今回の課題は Java の連想配列，コレクションの操作に関するもの

試行は所要時間が短かったため，役割の交代はしなかった．

を用意した．この課題はプログラミングの講義で利用され7.1.2 実験結果たものであり，3 時間程度の時間で解くことを想定して作実験の様子は撮影し，動画を元にコード変更箇所と注釈成されている．被験者にはプログラムの仕様と参考資料，付与の箇所，コード変更理由を類推するのに有用な対話と一部のメソッドが未実装のクラスファイル，テストケース判断した箇所を図示した．手書き注釈がある場合とない場を提供した．

合で作業タイムラインの比較を行った．

6.1 節の実験と同じく，実装には統合開発環境を利用し試行の結果を表 2 に示す．ここでの注釈数は，ペンタブた．また，コミュニケーションの手段としては音声通話，レットのペンが接地してから離れるまでを 1 回と数えてテキストチャット，手書き注釈を利用した．先の実験とはいる．また，これらの試行の動画から作成した図を図 3 に違い，実装役・補助役の交代は 20 分毎に行った．

示す．

© 2014 Information Processing Society of Japan432表 3

検証 2 の試行結果

所要時間

被験者１注釈数

被験者２注釈数

03h21m25s

28415

図 4 検証２における被験者の作業タイムライン

7.2.2 実験結果

図 5

注目点の指示に用いられた手書き注釈：矢印・下線・丸囲い

図 6

変数の内部状態を示すのに用いられた手書き注釈：図・表

実験の様子を撮影し，動画を元にソースコードの編集・手書き注釈が付記された箇所を図示した．
試行の結果を表 3 に示す．また，試行中のソースコードの編集・手書き注釈の付記を可視化したものを図 4 に示す．
図 4 の特徴的な箇所における作業の状況について，以下に述べる．
（1）では，被験者らはプログラムの仕様や実装するメソッドの確認を行っていた．
（2）では，作業方針が固まり，順調にメソッドを実装していた．途中，記述の間違いを指摘し，指示するのに注釈が用いられた．
（3）では，それまでの実装に区切りがつき，次に実装する内容について処理

まず表 3 より，被験者 1 に比べ，被験者 2 による注釈付の流れを確認しあっていた．変数に格納されるデータの状記数が少ないことが分かる．また，その内容が図 5 のよう態について，表を描いて説明していた．
（4）では，実装しな指摘に用いる注釈だったことから，被験者 1 による一方たメソッドのテストが通らず，配布資料の再読や API の的なコミュニケーションが記録の多くを占めていたと言調査をしながら試行錯誤していた．ここでは，注釈によるえる．

補助は行われなかった．
（5）では，最後のテストを通すた

被験者 2 の注釈数が少ないのは，ペアの組み合わせに起め，処理の流れについて再検討していた．説明には図が用因すると考えられる．ペアプログラミングにおいて，実装いられた．の熟練度に差があるプログラマの組み合わせでは，発言数

試行中はお互いにソースコードを編集する直前や，そのが少なくなる状況がある．これは熟練度が高いプログラマ

最中に自分の考えを発話していた．しかし，Java の実装経が実装役，低いプログラマが補助役に就いた際に起こる験のある被験者 1 に比べ，講義で基礎を学んだのみの被験[5]．熟練度の低いプログラマは補助役として指摘できる箇者 2 は注釈付記数は少なかった．

所が見当たらず，コードの記述に疑問が生じても質問しな

今回の試行で記述された注釈を図 5，図 6 に示す．また，い．熟練度の高いプログラマは補助役からの質問がないこ

注釈の形状と対話内容について，以下に記述する．矢印・とを，相手が自分のやろうとしていることを理解している

丸囲い・下線は，主に補助役からの指摘，注目点を伝えると考え，そのまま作業を進めてしまう．対話数が減少する際に利用されていた．この指摘の際には文字を伴うことがことで，ペアプログラミングの利点である知識共有が行わあり，これは描画した文字を入力するよう指示することにれない．また，注釈の数も対話数に伴って減少する．

使われていた．図や表が描かれた際には，ある変数に格納

この組み合わせにおいて発言機会を減少させないためにされたデータの説明や，関数のワークフローについて説明

は，次の二点がポイントになる．一つは，熟練度の高いプがされていた．

ログラマは相手の理解度の確認する機会を設ける，質問で7.2.3 考察きる環境を作ることである．もう一つは，熟練度の低いプ

実験結果より，手書きの注釈が付記されにくい状況があログラマは積極的に質問することである．

ることが分かった．一つは被験者らのコミュニケーション

今回の試行では，実装役と補助役を定め，定期的に交代に問題がある場合，もう一つは被験者らが独立して作業しする以外は作業の進め方に制限を設けていなかった．今後ている場合である．以下に詳細を述べる．の実験では発言機会の減少を防ぐため，作業者らの属性に© 2014 Information Processing Society of Japan433

応じた，対話の仕方を事前に教示する必要があると考えられる．
また図 4 の（4）では，注釈による補助が行われなかった．ここでは，作業者らは実装に試行錯誤しており，それぞれ別の作業を行っていた．例えば，実装役がソースコードの記述を試行錯誤している間に，補助役が参考資料の調査をしていた．このように，各々の意見がまとまっていない場合には，対話が少なく，注釈による意図伝達も行われないと考えられる．

8. おわりに
本稿では，分散ペアプログラミング中に蓄積されるコミュニケーションのログを利用して，プログラム理解を支援する手法を提案した．従来手法ではコミュニケーションログのノイズが課題となっていた．そこで，ソースコードエディタ上に付記された手書きの注釈が，音声通話の補助に使われていたことから，注釈が描かれた付近の音声通話ログを抽出することで，ノイズを軽減できると仮説を立てた．
仮説を検証するため，二つの実験を行った．検証では，仮説が成り立つ状況があることを確認した．しかし，被験者らのコミュニケーションが少ない場合や，独立して作業している場合には，注釈が付記されないことがわかった．
今回は検証例が少ないため，更なる試行が必要である．
その際には，被験者等のコミュニケーションの内容の分析のため，作業中におけるコミュニケーションのガイドラインを提示することを検討する．それに併せて，ソフトウェアの保守作業時を想定した検証を行っていく．
参考文献
[1]

[2]

[3]

[4]

[5]

秀毛嶺維馬，奥野拓：分散ペアプログラミングにおける手書き注釈を用いたコラボレーション機能の提案，情報処理学会北海道シンポジウム講演論文集, pp.175-180, (2012)
大森隆行，丸山勝久：開発者による編集操作に基づくソースコード変更抽出，情報処理学会論文誌，Vol.49，No.7，pp.2349-2359，(2008)
大森隆行，丸山勝久：プログラム開発履歴調査のための編
集操作再生器，ソフトウェア工学の基礎 XVII, pp.45-54,(2010)
西川穂高，酒井三四郎：分散ペアプログラミングにおけるコミュニケーションログとコード変更箇所の対応付けによる理解支援, 情報科学技術フォーラム一般講演論文集,
pp.103-104, (2005）
Laurie Wiliams and Robert Kessler：Pair Programming
Illuminated, Addison-Wesley Professional (2002）© 2014 Information Processing Society of Japan434