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

デバッグ時の診断作業の質的な分析に向けた事例研究
久米 出

中村 匡秀

田中 康之

新田 直也

柴山 悦哉

デバッグに於ける診断は障害の原因と発生過程の説明を可能にするまで精緻化された仮説である。診断の形成はいき
あたりばったりでないデバッグの遂行に不可欠である一方、作業者の知識や技量に大きく依存する作業である。こうした作業の属人性は診断支援ツールを評価する上で大きな障害となる。
我々の最終的な目標は評価実験の被験者の作業時の内面を質的に分析する事によって、実験結果から属人的な要素を分離する手法を開発する事にある。この目標に向けて我々は被験者の診断時の判断を質的に分析する手法を開発中である。本論文では質的分析手法の基本概念、トレース解析技術を利用した実装の概要、及び実際のソフトウェア
開発事例を利用した予備実験の結果を紹介する。

A diagnosis in program debugging is a refined hypothesis that points out the cause and the process of a
failure. Making a hypothesis depends on maintainers’ knowledge and skills, although it is indispensables
to systematic debugging. The dependency on individual knowledge and skills makes it diﬃcult to evaluate
tools that aim to support diagnosis making tasks.
The goal of our study is to develop a method of experimental evaluation which enables us to separate
those factors that depend on individual participants by a qualitative analysis of their internal thoughts. To
this goal, we are developing a qualitative analysis of participants’ decisions during their diagnosis making.
In this paper, we explain the basic concepts of our qualitative analysis, design of experimental environment
using our trace analysis technology. We also explain the result of an exploratory analysis of a diagnosis
making task in a real software development project.

プログラムの更なる実行と共に感染はさらなる感染

1 はじめにを生む。これを感染の連鎖 (chain of infection) と呼誤りを含むプログラムコードが実行されると不正なぶ。感染の連鎖によって引き起こされ、プログラムの状態が発生する。ここでコード中の誤りは不具合 (defect) 、不正な状態は感染 (infection) と呼ばれる †1 。

利用者から観測可能な実行時の誤りは障害 (failure)と呼ばれる。
デバッグは障害からその原因となった不具合を特定

A Case Study for Qualitative Analysis of Diagnosingin Program Debugging
Izuru Kume, 奈良先端科学技術大学院大学情報科学研
究科, Graduate School of Information Science, Nara
Institute of Science and Technology.
Masahide Nakamura, 神戸大学大学院工学研究科, Graduate School of Engineering, Kobe University.
Yasuyuki Tanaka, （株）京都ソフトウェアリサーチ,
Kyoto Software Research, Inc..
Naoya Nitta, 甲南大学大学院自然科学研究科, Graduate
School of Natural Science, Konan University.
Etsuya Shibayama, 東京大学情報基盤センター, Information Technology Center, The University of Tokyo.
†1 本論文ではデバッグに関する用語として Andreas
Zeller による定義 [18] に準拠したものを使用する。

し、修正する作業である。行き当たりばったりでない
科学的手法 (the scientific method) をデバッグに適用するためには障害の発生過程を説明する検証可能な仮説を立てる事が求められる。このような仮説は診断 (diagnosis) と呼ばれる [18]。実用的なプログラムを解消するためには診断の形成が不可欠である。
様々なプログラム開発手法が開発された現在に於いても診断は多くの人手や時間を必要と作業であり続けている。こうした手作業はデバッグのボトルネッ
クであるために診断作業を支援するツールの開発は極めて重要である。一般にツールを評価する最も直接

的な方法は、被験者を募りツールを使う場合と使わない場合の作業の結果を比較する評価実験を実施する事である。
しかしながらデバッグのみならずソフトウェエア工学のツールを被験者が参加する実験で評価する事は一考察する。
本論文では評価される手法はデバッガやプログラム
理解支援のための手法として実装されている事を仮定する。またデバッグ対象プログラムは Java 言語によって記述されているものとする。

般にリスクが高く、実験の実施そのものが困難である以降の節の構成は以下の通りである。まず第 2 節と考えられてる [7] 。研究者達がそのように考えるのでデバッグに於ける診断の重要性を述べ、診断支援手は被験者による作業は個々の被験者による属人的な要法の評価方法に関して問題提起を行う。次に第 3 節

素の法がツールそのものよりも実験に与える影響が大で我々が提案する評価手法を説明し、第 4 節で予備きいと信じられているからである。デバッガを用いて調査の実施と、その評価について述べる。第 5 節で診断形成作業を実施する場合と用いずに実施する場

関連研究を紹介し、第 6 節で将来課題や手法の問題

合の結果に差異が見出されたとしても、作業の過程が点を議論し、第 7 節で結論を述べる。

ブラックボックスである限りその差異がデバッガに依るものか否かは明らなではない。実際にデバッガが秀2 導入れているとしても被験者の人選によってはデバッガの

2. 1 デバッグに於ける診断

優位性が打ち消されてしまうかもしれないのである。

本論文では Andreas Zeller [18] の用語に従って観測

我々の研究はこうした現状を改善すべく、診断作業

可能なプログラムの実行の誤りを失敗 (failure) 、プロに対するツールの寄与を評価するためのデータを実グラムコード上に組込まれた誤りを不具合 (defect) と際の診断作業から収集し、分析するための一般的な枠呼ぶ。不具合を有するコードが実行される事によって組みを確立する事を最終目標としている。我々の手法

実行時の状態に誤りが発生する。これを感染 (defect)の最大の特徴はプログラムトレース (実行履歴) を利と呼ぶ。感染は更なる感染を引き起こす。これを感染用する事によって、被験者のよる作業の適切性を評価の連鎖 (Chain of infection) と呼ぶ。

する点にある。被験者が作業時に作適切な判断を下しプログラムのある箇所で障害が発生した時に、障害ているか否かを明らにする事によって、それが作業のの原因となった不具合はそこから離れた箇所に潜んで実行効率に与える影響を評価出来るようになると我々いる事は珍しい事では無い。不具合を含むコードがは考えている。

実行され多数のステップ数の実行を経て障害の発生

被験者による判定の適切性を評価するためには被に至る。複雑な感染の連鎖に対処するためには行き験者の内面を表現するデータを収集し、かつ判定の評価に不可欠な「正解」を予め準備しておく必要があ

当たりばったりの方法ではなく、科学的な手法を [18]を用いて診断 (diagnosis) †2 をまず形成すべきであるる。本提案手法は感染の連鎖をデータ化する事によっとされている。診断は障害発生の仕組みを説明し、実て、状態の正誤判定に関する「正解」を与える。我々

行結果の予測によって検証可能な仮説である。

は過去の研究で開発したトレース解析手法 [9] を利用してデータ化を実現する。

実際のデバッグではプログラムの外的内的な挙動が観察の対象となる。通常、内的な挙動の観察にはデ

本論文では我々開発する診断支援ツールの評価の枠

バッガ等の支援ツールが必要である。標準的なデバッ組みの概要を説明し、その実現に向けた取り組みにつガを用いるとコード中のブレークポイントを指定しいて述べる。我々が提案する枠組みに於ける診断作業た箇所でプログラムの実行を停止させ、その時点でののモデルとモデル形成の過程を説明する。形成されたモデルを利用すると、既存の評価手法では困難であった評価結果を得る事が可能になる。実際に我々が体験した診断作業の記録を分析して提案手法の妥当性を†2 診断という用語は Fault Localization のように自動化を指向するデバッグ支援分野でも用いらているが[12]、本論文では一環してデバッガのような対話的なツールを用いた手作業による診断を想定している。

プログラムの状態を参照する事が可能となる。しかしが避けられる傾向にある [7]。

ながらこの時点で既に呼び出しスタックから除去されたメソッドの実行内容は参照出来ず [10]、ブレークポ

2. 3 診断形成作業の評価

イントの利用による作業の非効率性 [14] がデバッグ支
援の古くて新しい問題として指摘され続けている。

Mental Model

How to evaluate?

2. 2 診断のためのプログラム理解
実用的なプログラムでは不具合箇所の実行が直ち(Representation)に障害として現れる代わりに多数の実行ステップを

Think Aloud.............

経て漸く障害が発生する事は珍しく無い。このよう

Operationな場合には障害発生の原因と結果が自明でないため、Debugger

保守作業者は両者の間を埋める感染の連鎖をしばしば逆に辿りながら特定しなければならない。この作業にはプログラムの状態の誤りの特定が不可欠である。

図1

メンタルモデルと操作履歴の分析

プログラムの構造や感染の連鎖が複雑である場合、作業者はこうした問題を直接解決するための十分なプログラム理解の分野では様々な認知科学的な手知識を予め有していない事は珍しくない。そのため問法を利用してその内面の分析が進められてきている

題解決のためにプログラム理解のための問題を設定[13] [17] [16] [4] [2] 。これらの手法では被験者に定期的する。こうした問題解決のための知識も不足しているに発話を促す思考発話 (Think Aloud) と呼ばれる方場合にはさらに入れ子状に問題が設定され、その解決式で被験者の内面を発話履歴としてデータ化していに向けた作業が実施される。このような入れ子構造的る。これらの手法はそれぞれ被験者の内面を形式化しな問題設定の存在は過去の研究 [2] でも確認されていた内面モデル (mental model) を定義している。それる。我々自身もデバッグ作業でこのような入れ子的なぞれの発話内容をラベル付けし、ラベルの内容に基づプログラム理解作業をしばしば体験済みである。

いて内面モデルを生成する。ツールの操作履歴はこの

このように実際のデバッグに於ける診断ではしばし

内面モデルによって意味付けされる。

ばプログラム理解が不可欠である。よってプログラム

内面モデルとツールに対する操作と組み合わせる

理解の支援は診断を効率化する上で非常に重要であ事によって、被験者のプログラム理解の戦略や思考のる。プログラム理解の支援を目的とした様々な手法がモードの切り替えを分析する事が可能になる。こうし提案され、それらを実装したツールを用いた問題解決

た質的な分析はプログラムを理解するための人間のの事例が紹介されている [1] [11] [6] 。

心の働きや傾向をモデル化する手法としては極めて

これらの手法やツールの評価はその適用結果によっ有効である。

てその有効性が示されている。しかしながらこれらの

しかしながら診断支援ツールの評価に於いて被験手法やツールが実証実験によって評価されたとして者固有の要素を特定するためには既存の研究とは異も、その実験とは異なる作業環境下でそれらが有効でなるモデルが必要とされる。診断形成の効率は被験者あるか否かは分からない。一般にプログラム理解はによるプログラム理解の、特にコードや状態の誤りを属人性が強い作業であり [5] 、作業の成績が被験者に正しく判定する能力に大きく左右される。例えばツー

依存している可能性を否定する事が困難であるから

ルが誤った状態を被験者に表示しても被験者がそれをである。実際、デバッグのみならずソウトウェア工学

誤りを判定出来なければツールの本来の能力は発揮

ツールの研究者にとって被験者を用いた評価実験はリされる事は無い。

スクが高く実施が困難であると考えられており実施

診断形成作業時に被験者状態の正誤に対して下した判定が実際に正しいか否かを実験の実施者は評価

このようなモデル化を可能にするためには、思考発する手段を持たなけらばならない。被験者による判定

話法と合わせて被験者の操作・観察の履歴や感染情報を実施者が評価がする事によって初めて、その判定にを含むトレースが必要である。これらのデータを収集

ツールがどのように貢献したのかを評価出来るようし、それらを用いたモデル化、モデルを用いた適切性になるからである。判定を評価するためには実験実施の評価を実施するための実験環境の実装と運用が必者が判定に関する「正解」を知っている必要がある。

要となる。実験の実施から適切制の評価に至る一連の内面モデルとツールの操作のみを分析の対象とする過程を図 3 に示す。

従来の手法ではこうした「正解」を与える情報を得る
事は極めて困難である (Figure 1)。

Tool underevaluated

Participant

3 評価手法3. 1 診断形成モデル
本節では診断作業時の被験者の判定を評価するた(execute)(diagnose)

Evaluation
Environment

めの新しいモデルとして診断形成モデル (Diagnosing

Diagnosing
Process(analysis)

Process Model) を提案する。診断形成モデルは以下

Relevanceの三つの要素から構成される:Buggy Java
Program.............

.............

Evaluation

Chain of
Infection.............

• 被験者の内面
図3• ツールとのやりとり

評価実験の枠組み• 感染の連鎖を含むトレース (実行履歴)
これらの構成要素とその関係を図 2 に示す。
内面モデルは診断形成作業に従事する被験者の思考を分類する。この分類は基本的にデバッグ作業時

多くの認知科学的な手法と同様、我々の診断形成モ
デルも被験者の思考内容を分類する。診断形成モデル
による分類を以下に述べる。

の内面を、問題の設定と解決 (或いは問題解決のため

問題 (Problem) ツールが表示するプログラムのの問題の設定) によってモデル化する既存の枠組みを実行やコードに対する疑問や仮説の形成。被験者[2] [4] 継承するものである。

はこれらの疑問や仮説を解消或いは検証すべき

我々はデバッグされるプログラムに対して、その実と考えている。

行時に於ける感染の連鎖に関する情報を含むトレース

理解 (Comprehension) 設定された問題に対すが生成されている事を想定する。この情報が第 2. 3 節

る結論、或いは作業による知見の追加。被験者

で述べた被験者の判定を評価するための「正解」としが下した結論や知見は必ずしも正しいとは限らての役割を果たす。

ない。

ツールとのやりとりには被験者による操作に加えその他 問題や理解に含まれない思考内容。ツールてツールの反応も含まれる。ツールは被験者に対しての操作に対する疑問等が含まれる。

プログラムコードや実行時の状態の一部を表示する。

問題はさらに以下のように分類される。

この時被験者に対して表示されている内容に感染の連鎖が含まれているか否かが特定される †3 。これに疑惑 (Suspicion) ツールが表示する状態や表示

よって被験者が下した判定が適切なものであるか否か

問題の答えは必然的に Yes/No によって与えらを評価する事が可能になる。

れる。

†3 この情報は実験実施者による評価に用いられるものであり、当然の事ながら感染の連鎖が含まれていたとしてもそれが被験者に示される事は無い。

が感染や不具合を示すか否かを問う問題。この仮説 (Hypothesis) ツールが表示する状態やコー
ド関してそれが感染か不具合かを問うもの以外るの問題で、その答が、答が Yet/No で与えらProblemanswerToolmanipulation
Trace / Code Basesupport

Relevance

Participant

図2

診断形成モデルれるもの。

用いられるプログラムは既にコード中の不具合箇所

問い (Inquiry) ツールに表示される状態やコーが明らかにされ、感染情報がトレースの一部としてドに関してその答が Yes/No で与えられない

データ化されている。こうした情報は当然被験者にはもの。

示されないが、被験者に対する暗黙的な不具合や感染理解はさらに以下のように分類される。

の表示は操作履歴として記録される。この記録によっ

判定 (Determination) ツールが表示する状態て被験者による判定の適切性の評価が可能となる。こやコードに対してそれが感染や不具合を表しての記録から導かれる被験者の判定に対する評価は図 2いるとする理解。

中の関連クラス Relevance で表現されている。

知見 (Knowledge) 診断形成作業で得られた或いは既知の知識から導かれた理解。

3. 2 評価環境

被験者による作業の時間は発話や操作に基づいて

我々は図 3 が示す評価実験の過程を実施するため

区間 (interval) に分割される。各区間内内での発話はの評価環境 (Evaluation Environment) の開発を進め

上記の枠組みに従って分類される。診断形成モデルはている。本評価環境は不具合を含むプログラムが実行

これらの区間から構成される。

されるとそのトレース (実行履歴) が生成、取得され

図 2 には上記の分類のうち問題、理解、判定とそる。プログラムコード中の不具合箇所は予め指定されの他のモデルの要素との関係が示されている。本モデており、トレース内の不具合箇所の実行に依存する部

ルでは被験者は問題を設定し、その解決に向けてツー

分がこの指定に基づいて導かれる。結果として感染のルを操作する。図中ではこの問題と操作の関係が関連

連鎖の情報を含むトレースが生成される。この処理はmotivation によって表現されている。被験者のツー

我々が過去に開発したトレース生成技術 [9] を用いてルの表示に対する理解はツールの表示と理解を結ぶ関実装される。

連 support によって示されている。ツールに対する

我々のトレースには実行時に呼び出されたメソッド

操作とその反応は両者を結ぶ関連 manipulation ととその実行内容が詳細に記録されている。メソッド呼feedback によって表現されている。

び出し、インスタンス変数とクラス変数の参照代入、

ツールはデバッグされているプログラムのソース

局所変数の参照と代入、条件分岐や繰り返し、例外のコードと実行時の状態を表示する。被験者はツールの投射と捕獲の実行とそれに共なう依存関係もトレー表示に基づいて不具合や感染を判定する。評価実験でス上に表現されている。指定された不具合による感染

の連鎖はこの依存関係に基づいて計算される。

聞き取り調査に基づいて作成分類された区間内で被験者は診断形成作業を行うと同時にその内面の被験者が観察した表示箇所を指定する。ここで特定し発話 (Think Aloud) が求められる。発話と画面上のた内容を評価環境が生成した操作や表示の履歴と合操作は動画として記録される。被験者がコードや実行わせる事によって区間内で被験者がコードやトレース

データに対してツールを介して参照した履歴は動画のどの部分を参照していたのかが明らかになる。被験とは別に時系列データとして記録されるが、診断形成者が該当区間で判定を下している場合、その判定の適モデルの構築時に動画と同期させて用いられる。

切性が導かれ、診断形成モデルの構築に至る。
区間の分割と分類、さらに観察箇所の指定はその3. 3 事後の聞き取り調査

性格上手作業が避けられない。我々はこの作業を効

被験者が診断作業を終えた直後に自身の発話と操率化するための実験支援ツールを現在開発中である。

作画面が再現される。被験者は再現された動画を視聴支援ツールの画面を図 4 に示す。

しながら自身の発話や操作、観察していた画面上の箇支援ツールによる支援の対象は区間の編集と観察箇所、さらにツールの反応によって得られた知見を解説

所の指定作業である。図 4 が示す支援ツールの GUIする。実験の実施者はこの時必要に応じて被験者に質は以下の三つに分割される。

問する。これらの聞き取り調査の結果は実験実施者による内面モデル構築に利用される。
実験実施者による質問は被験者の説明を補完する事を目的とする。被験者がある発話や操作の説明をしない場合、実験実施者は質問を通じてそれらの意図を明確にすべきである。被験者の説明に指示代名詞が含

再生画面 被験者の作業時の発話と操作を記録した動画の再生画面 (図中の [1])。この再生画面上に方形を配置する事によって被験者の観察範囲を特定する (図中の [3])。
区間分割 動画の再生時間を用いて新たな区間の開始時点を定めるバー (図中の [2])。

まれている場合、質問によってそれが指している内容

区間編集 分割された各区間に対してその分類をを明らかにすべきである。被験者による判定や理解に指定し、かつ他の分割との相互参照を指定するた

対してはそれに至った根拠等を質問によて明らかにすべきである。

めの画面 (図中の [4])。
実験実施者は再生画面で動画を視聴しながら新た実験実施者による質問は実施者にとって望ましい回

な区間の開始時点を決定する。決定された開始時間で答を誘導するものであってはならない。例えば被験者

動画の再生を一時停止し、区間分割バーを操作して新に対して「ここであなたは局所変数が参照している

しい分割を開始する。新たな区間の開始時点の設定に値が誤ったものであると判定していて、どこで間違っよってその前の区間の終了時点が決定される。

た値が代入されているのかを調査しようとしている

新規に作成された区間に対して、区間編集画面を用んですね？」とうような質問は避けるべきである。

いた編集が可能になる。区間編集画面を用いて区間の分類を特定し、他の区間との相互参照を設定出来る。

3. 4 診断形成モデルの構築

評価環境で生成された時系列データは区間が作成さ実験実施者は聞き取り調査の結果に基づいて記録れた時点で対応付けられる。

された動画を区間分割する。分割の恣意性を避けるた
めに区間の開始と終了時点は被験者による観察箇所

4 予備調査や参照している情報の変更、ツールの GUI 操作の連

評価環境の構築と実験手法の開発に向けた予備調

続性、さらに被験者の内面の分類に基づいて決定さ査として、我々は現実のソフトウェア開発プロジェクれる。各区間を第 3. 1 節の議論に基づいて分類する。

トで実施されたデバッグ作業を記録し、その診断作業

さらに疑惑と判定のように互いに関連する区間同士の内面モデルを構築した。本論文の著者が実際にこのを関連付ける。

開発プロジェクトに参加しており、思考発話を実施しA13[4] Model Elements

http://localhost/ProcessEditor/

Suspicion [5]Related Intervals
Inquiry [11][3] Observed Area

Determination [12]Add new item

Observations
Operations[1] Captured VideoUndo

0: 15: 41: 05

Redo

Save and Quit

[2] Intervals

図4

診断形成モデル構築支援ツールながら自らの診断診断作業を記録した。作業者の発話ドを読み、プログラムの設計を理解し直しながら診断及び操作とその反応は市販の画面取り込みソフトウェ作業が進められた。開発者は診断作業が開始される

アを用いて記録した (図 5)。

前に障害を再現させるテストケースを作成している。

この診断作業は現実のソフトウェア開発の一環として実施されたため、不具合箇所は当然不明であり、診断はこのテストケースの実行に対して Eclipse のデバッガを用いて実施されている。

かつ感染情報を含むトレースも生成されなかった。そ今回の実験のために診断作業畤の操作と発話が動画のため本予備調査では第 3 節で述べた診断形成モデ

データとして記録されている。診断に要した作業時間

ルは構築されなかった。しかしながら本提案手法の有は約一時間二十分程度である。診断作業中は Think

用性と実現可能性を論じる際に重要な知見を得る事

Aloud を意識して絶え間無く発話を心掛けた。感染が出来た。

に関する判定に迷う等の理由で二、三分間無言が続く
区間が幾つか存在する。動画データを記録する以外で

4. 1 診断の対象は通常の Eclipse のデバッガを用いている。このプロ

デバッグ対象となった Java プログラムはソフトウェ

グラムはファイルから入力を読み込むので作業時にテ

ア工学ツールが Java のクラスをロードするためのキストエディタを用いてファイルの内容を確認してい機能を提供するものである。本プログラムは Eclipse

る。感染の連鎖をデータとして含むトレースは生成さプロジェクトの設定ファイル (.classpath) を構文解析れていない。

し、プロジェクトから参照されるクラスやリソースをロードする上で必要な機能を実装している。

4. 2 モデル構築

本プログラムは著者の一人が研究用途で開発・保守

第 3. 2 節で説明した手順に従って取得した作業のしている。クラス数は 24 個、コードの行数は空行と記録動画の分析を進めた。ただし作業直後ではなくコメントを除いて 3452 行である。ソースコード中に後日に分析に着手した。これは本プログラムの障害はコンパイラコンパイラ [3] によって生成され読解がが発見された時点で分析の手順が確定されていなかっ

困難なものも含まれる。

たからである。しかしながら分析が後日実施された事

今回のデバッグ作業も開発者自身が担当している。

は特に分析の障害とはならなかった。

プログラムの開発は半年前に一旦終了しており特に文分析の過程で我々は作業時間を 173 の区間に分割書も残されていない。よってプログラムのソースコー

した。38(22%) の区間の発話に複数の分類の発話が図5

音声と操作画面の取り込み

含まれている。全作業を通じた発話の個数は 184 で、各分類の発話数と全体に於ける割合 †4 は内訳は以下

4 つの判定に関して被験者自身が判定の根拠を答えられなかった。被験者は 23 の知見に関してそれがどの通りである:のように得られたのかを説明出来なかった。被験者は疑惑 発話数 7(4%)

デバッガを用いてプログラムコードの実行を追いなが仮説 発話数 25(14%)

らその意味を理解しようとする中でこれらの判定を問い 発話数 10(5%)

下し、知見を得ている。こうした複雑な作業を遂行す

判定 発話数 16(9%)

る中で記憶が失われたものと推測される。

知見 発話数 79(43%)
その他 発話数 47 (26%)

4. 3 診断形成過程の分析「その他」に分類された発話の割り合いが高いがそ第 4. 2 節で述べたように今回の作業では大半の発の 47 のうち 38(80%) は操作に関する言及である事

話は診断形成モデルの構成要素と関連付けられる。結が判明した。結果として発話の大多数が図 2 の構成

果として我々の作業は記録されたデータの大半を診断

要素と関連付けられる事になる。

形成モデルの構築に活用出来たと考えられる。モデル

我々はさらに事後の聞き取り調査に基づいて無言 †5の内容に関しても理解と判定を合わせた 103 のうち、で実施された操作に対して発話の分類を適用した。こ

76 個 (73%) に対してその根拠の特定に成功した。被のような無言の操作の総数は 44 にのぼり、そのうち験者の思考の変遷を時系列的に辿る分析を行うための 2 つ (全体の 5%) が疑惑に分類された。さらに 3 つにはこうした発話間の関連性が重要であると考えら(7%) が仮説、7 つ (16%) が問い、8 つ (全体の 18%)れる。

が知見に分類された。判定に分類されたものは存在し問題と理解の対応関係を時系列的に分析する事になかった。残りの 24 個はその他に分類されたが、そよって、我々は作業者に固有な情報を得る事が出来のうち 23(96%) の実施時に於いては被験者は操作のた。作業者の設定した問題の多くはデバッガを用いた確認操作の計画等、操作そのものを考えていた事が明

簡単な操作を経て解決されている。これらの操作をらかになった。

より詳しく観察すると明らかに同じ問題の設定と解決を繰り返している事が分かる。特にプログラムの†4 小数点以下を四捨五入しているため合計が 100 にならない。
†5 厳密には全てが完全な無言というわけではなく、「う〜む」等の分類困難な発話も含まれる。

状態が正しいかどうかを確認するために入力データ(Eclipse プロジェクトの.classpath ファイル) を何

度も見直している事が判明した。
この事からこの作業者に関して二つの仮説が立てら境下でこれらのツールを容易に評価するための仕組みが今後求められる事が予想される。

れる。まず、作業者は入力がプログラム中のどのデー
タ構造に反映されるべきかを試行錯誤を経ずに特定し6 議論ている。これは本プログラムに関してある程度の知識

第 4. 2 節で述べたように、我々の予備調査の作業を暗示している。実際に作業者自身がこのプログラム

者は自身が取得した知見の幾つかについて、その取得を開発しているためにこのような特定が可能である。

の経緯を説明出来なかった。作業者がデバッガを用いさらに同じデータの入力との対応関係を一旦は確認てソースコードの複雑な実行を追う作業ではこのよした筈なのに繰り返し確認しているが、これは作業者の用心深く神経質な性格 †6 を示唆するものである。

うな由来の不明な知見が得られる傾向が見出された。

このような本来必要のない確認の繰り返しは正し

実装の詳細に密接に関わるものであると考えられる。

く作業が自身の性格に由来するものである。このようこうした知見の由来を特定するためには作業時にな繰り返しが作業の効率を低下させるとするならば、於けるソースコードや実行時状態の追跡を再現する

その原因はツールにあるのではなく被験者の性格にような仕組みが必要であると我々は考えている。これあると結論する事が可能になる。結果として今回の分は該当作業を実施している際の操作や表示を再現す

析は診断形成作業に於ける属人的な要素の特定に成る事によって実現される可能が有る。

功したという結論を下せると我々は考えている。

よってこのような知見はプログラムのアルゴリズムや今回の作業を通じて我々の評価実験を効率的に遂行する上で重要な二つの教訓を得る事が出来た。一つ目

5 関連研究は診断形成モデルの構築に於けるトレースと感染の

認知科学的な知見をデバッガやプログラム理解支援

連鎖情報の重要性である。上述した実装の詳細に関わツールの開発に反映すべきであるという主張はそれる知見の獲得を再現する際にもトレースを再利用すほど新しいものではない。例えば Storey 等は理解戦

れば被験者が過去の操作をフィードバックも含めて再略の分析に基づいたコード探索 (exploration) ツール

現する事が可能になる。

の要件定義を議論している [15]。

二つ目の教訓は診断形成モデル構築の支援の重要

Andrew Ko 等は認知科学的な知見に基づいてデ性である。作業者が診断に要した時間は一時間半にバッガのユーザンタフェイスを設計した [8]。彼等は満たなかったが、収集されたデータからモデルを構築

自身の設計したユーザインタフェイスを備えたデバッ

する作業には丸一日に相当する時間が必要であった。

ガを実際に実装し、依存関係を辿る作業を効率的に支

テキストエディタを用いてデータを生成していたため援する事を示した。

に、音声映像から区間を分割する工程が作業のボトル

しかしながら彼等の実証実験では「デバッグ初心者

ネックを形成したのである。この反省を踏まえて我々でも容易にデバッグが可能である」事によってその有は第 3. 4 節で説明した支援ツールの導入を決定した。

効性を主張している。Ko 等の内面モデルに関する研さらに記録された音声データの音質が低いためにしば究 [16] [4] はユーザインタフェイスの設計の根拠を与しば発話を何度も聞き直した事も作業効率を低下さえたが、その有効性の評価には利用されなかった。

せる要因となった。よってデータの質を向上させるた

我々の評価手法を効率的に用いるためには感染の連

めのハードウェア環境の重要性を認識するに至った。

鎖を表現するトレースを生成する必要がある。近年ト

診断形成モデルに於ける内面モデルが認知科学的レース解析を用いたデバッガや支援ツールの開発が進な手法で用いられる既存のモデル (例えば [4] [2]) と整められている (e.g. [1] [10]) 。我々が提案する評価環合的であるべきである。さらなる予備実験を通じて既存のモデルとの整合性の確認が必要であると我々は考†6 この作業者は実際にそういう性格を有している。

えている。

7 まとめ
本論文ではデバッグの診断形成を支援するツールを対象とした新しい評価実験の手法を提案した。本提案
手法は被験者による作業内容に対して実験実施者による評価を可能とする点に大きな特色を有している。
被験者の作業内容を評価する事によって、被験者の属
人的な要素に左右され難いツールの評価実験への道が開かれる事が期待される。この評価に用いるデー
タは我々が過去に開発したトレース生成手法によって取得される。我々は現実のソフトウェア開発プロジェ
クトに於けるデバッグ作業を利用した予備的な調査を実施し、本提案手法の有効性を示す結果と共に手法を実現するための課題を得るに至った。
謝 辞 こ の 研 究 は 栢 森 情 報 科 学 振 興 財 団 、人 工
知能研究振興財団、科研費基盤研究 B(16H02908、26280115)、科研費挑戦的萌芽 (15K12009) の助成を受けて遂行された。

参 考 文 献[ 1 ] André L. Santos: GUI code tracing through direct program interaction, Journal of Software: Evolution and Process, Vol. 26, No. 6(2014), pp. 552–
568.
[ 2 ] Halle, J. E., Sharpe, S., and Hale, D. P.: An
Evaluation of the Cognitive Processes of Programmers Engaged in Software Debugging, Journal of
Software Maintenance, Vol. 11, No. 2(1999), pp. 73–
91.
[ 3 ] Java Compiler Compiler: https://javacc.java.net/.
[ 4 ] Ko, A., Myers, B., Coblenz, M., and Aung,
H.: An Exploratory Study of How Developers Seek,
Relate, and Collect Relevant Information during
Software Maintenance Tasks, Software Engineering, IEEE Transactions on, Vol. 32, No. 12(2006),
pp. 971–987.
[ 5 ] Ko, A. and Uttl, B.: Individual diﬀerencesin program comprehension strategies in unfamiliar programming systems, Program Comprehension, 2003. 11th IEEE International Workshop on,
May 2003, pp. 175–184.
[ 6 ] Ko, A. and Myer, B.: Debugging reinvented:
asking and answering why and why not questions
about program behavior, International Conference
on Software Engineering, IEEE, 2008, pp. 301–310.

[ 7 ] Ko, A. J., LaToza, T. D., and Burnett, M. M.: A
practical guide to controlled experiments of software
engineering tools with human participants, Empirical Software Engineering, Vol. 20, No. 1(2015),
pp. 110–141.
[ 8 ] Ko, A. J. and Myers, B. A.: Designing thewhyline: a debugging interface for asking questions
about program behavior, SIGCHI Conference on
Human Factors in Computing Systems, ACM, 2004,
pp. 151–158.
[ 9 ] Kume, I., Nakamura, M., Nitta, N., andShibayama, E.: A Case Study of Dynamic Analysis
to Locate Unexpected Side Eﬀects Inside of Frameworks, International Journal of Software Innovation (IJSI), Vol. 3, No. 3(2015), pp. 26–40.
[10] Lienhard, A., Gı̂rba, T., and Nierstrasz, O.:
Practical Object-Oriented Back-in-Time Debugger,
ECOOP, 2008, pp. 592–615.
[11] Palepu, V. and Jones, J.: Visualizing constituent
behaviors within executions, Software Visualization(VISSOFT), 2013 First IEEE Working Conference
on, Sept 2013, pp. 1–4.
[12] Perez, A. and Abreu, R.: A Diagnosis-based
Approach to Software Comprehension, Proceedingsof the 22Nd International Conference on Program
Comprehension, ICPC 2014, New York, NY, USA,ACM, 2014, pp. 37–47.
[13] Piorkowski, D. J., Fleming, S. D., Kwan, I.,
Burnett, M. M., Scaﬃdi, C., Bellamy, R. K., andJordahl, J.: The Whats and Hows of Programmers’ Foraging Diets, Proceedings of the SIGCHI
Conference on Human Factors in Computing Systems, CHI ’13, New York, NY, USA, ACM, 2013,
pp. 3063–3072.
[14] Ressia, J., Bergel, A., and Nierstrasz, O.:
Object-Centric Debugging, International Conference on Software Engineering, IEEE, 2012,
pp. 485–495.
[15] Storey, M.-A. D., Fracchia, F. D., and Müller,
H. A.: Cognitive Design Elements to Support theConstruction of a Mental Model During Software
Exploration, J. Syst. Softw., Vol. 44, No. 3(1999),
pp. 171–185.
[16] Storey, M.-A., Wong, K., and Mller, H.: How doprogram understanding tools aﬀect how programmers understand programs?, Science of Computer
Programming, Vol. 36, No. 23(2000), pp. 183 – 207.
[17] von Mayrhauser, A. and Vans, A. M.:
Hypothesis-Driven Understanding Processes During
Corrective Maintenance of Large Scale Software, International Conference on Software Maintenance,
IEEE, 1997, pp. 12–20.
[18] Zeller, A.: Why Programs Fail, Second Edition:
A Guide to Systematic Debugging, Morgan Kaufmann, 2009.