分析と考察

8.4.1 設問解答の採点結果の分析

解答の採点結果に対して、使用したツールを因子とした分散分析を行った。設問全体では ツールによる効果は有意だった（p<0.01）。Ryan法による多重比較を行ったところ、画面サ ムネイル表示ありのORCAはEclipseよりも良い結果が得られた（p<0.01）。さらに画面サ ムネイル表示なしのORCAもEclipseよりも良い結果が得られた（p<0.01）。一方、ORCA

の画面サムネイル表示があるものと無いものの間には有意差は見られなかった（p = 0.498）。

次に解答時間について言及する。Eclipseを用いたとき、大部分の被験者が30分以内にすべ ての設問についての解答を完了することができなかった。一方、ORCAを用いた場合には大 部分の被験者が制限時間内ですべての設問を解き終えることができた。平均の実験完了時間 は画面サムネイル表示ありの場合には26分30秒、無しの場合には26分59秒であった。

次に各設問について考察する。設問1と設問2についてはツールによる効果は有意であり

（p<0.01）、Ryan法による多重分析を用いた結果、ORCAとEclipseの間に有意差がみられ た(p<0.01)。Eclipseの場合には操作に対応するソースコードを発見するのに時間がかかる 傾向にあり、列挙すべき情報の抜け漏れが目立った。ビデオを分析して確認したところ、情 報の抜け漏れは多くの場合、静的な情報だけに頼ったことやデバッガ使用時にトレースのス テップを飛ばすことが原因で発生していた。これらの結果からORCAが操作と実行部分の結 びつけを行い、実行されたソースコード部分を抽出する上で十分有効であることが実証でき た（仮説2、3を実証）。

設問3では、表示の異なる2つのシーンを解析しなければならないこと、操作間に視覚的な フィードバックが変化するような機能を設問としたことから、ORCAの画面サムネイル表示 がある場合と無い場合では大きな差が出ると予想していた。実際の結果を見ると、画面サム ネイル表示ありのORCAを用いた場合の平均スコア（0.931）は、画面サムネイル表示無しの ORCAを用いた場合の平均スコア（0.750）と比べて高かった。しかし今回は被験者のサンプ ル数が少なかったこともあり、統計的な有意差には至らなかった（p = 0.261）。ビデオ分析を したところ、1人の被験者は、画面サムネイル表示のないORCAを利用している際に、誤っ たシーンの解析を行い続けていた。これは連続操作間に発行された各イベントにより実行さ れたソースコードと、画面の変化とが正しくマッピングできていなかったために生じたもの と思われる。仮に画面サムネイル表示があったとしたら、サムネイル情報から正しいマッピ ングを行うことができたと予想される。また数人の被験者は設問3において、ORCAの可視 化結果とその時点の実行状況の間でのマッピングができずに何度もGUIへの操作を繰り返し た。さらに、ある被験者は状況と可視化結果のマッピング作業が不十分なまま解答を進めた ために解答を誤っていた。このように、画面サムネイル表示の有無は少なからずGUIプログ ラムの理解作業に影響を与えていた。

Eclipseにおいて何人かの被験者は、マウスのドラッグ操作のように一連の複数イベントを

把握する必要があった場合にも、一部のイベントのみしか収集することができなかった。ま た同一のイベントが連続して発行している中で変化が起こる条件を見つけ出すような問題で は、デバッガを利用した把握が難しく、被験者はソースコードを静的に読み進める中から該 当部分を見つけ出す必要があった。これらの事実及び、前述したEclipseとORCAの間での 分散分析の結果から、ORCAは複数イベントを伴う機能の把握にも十分有効であることが実 証できた（仮説1を実証）。

また対象プログラムを因子として分散分析を行ったところ、プログラム間でのスコアに有 意差は見られなかった（p = 0.699）。そのためプログラム規模の大小にかかわらず、上記の結 果が得られると予想される。

事前アンケートでは被験者全員がEclipseを利用した経験があり、うち6人が時々利用する と答え、3人が普段から利用すると答えた。そのため、今回の被験者はEclipseの操作には慣 れていたと言える。また5人が普段からデバッガを利用し、4人が普段あまりデバッガを利用 しないと答えた。デバッガの使用経験は、Eclipseを利用してプログラムを理解する上で差が みられると予想した。しかしながら、デバッガの使用経験の有無を因子とした分散分析の結 果からも統計的な差は見られなかった（p = 0.677）。またGUIプログラミングに関して、4人 が1年以内の経験があり、5人が3年以上の経験があった。経験が多いグループと少ないグ ループの間でスコアに差があるかを確かめるために、2つのグループに対する分散分析を行っ たところ、統計的な有意差は見られなかった(p = 0.906)。

図8.4を見ると、Eclipseの結果には大きなばらつきがあることが確認できる。これはEclipse では被験者の習熟度や被験者と設問との相性等によって解答の出来不出来が大きく変わって くることを示している。一方、ORCAでは結果にEclipseほど大きなばらつきはない。これよ り、ORCAを用いれば被験者の経験や解答する設問に関わらず、高い水準で理解作業を行う ことができると期待される。

8.4.2 アンケート結果の分析

GUI操作に合わせてソースコード中の実行部分が強調される表示に関しては肯定的な評価 を得た。多くの被験者が理解作業を開始するポイントを絞るためや処理の大まかな流れをつ かむために役立つと答えた。

クラス階層表示は平均的に低い評価を得た。この評価は、今回の実験では対象GUIプログ ラムのクラス階層が少なくクラス階層に大きな関わりのある設問はなかったことに原因があ るものと思われる。この原因をインタビューにおいて確かめたところ、問題解答中にクラス 階層表示について意識する必要がなかったため、低めの評価をせざるを得なかったというの が被験者全員の意見だった。また、評価こそ低いものの否定的な意見は特になく、“実際の利 用時には役に立ちそう”という意見もあった。

GUI画面のサムネイル表示に関しては8人の被験者が理解に役立ったと答え、一方で1人 は役に立たなかったと答えた。肯定的な意見では、“サムネイルが無い場合にどの可視化結果 がどの操作に対応しているものか全くわからなかった”、“注意深く画面変化を見ていなくて も、自動的に画面変化を記録してくれるので便利である”、“イベントが多く発行されるとき に便利だった”という声があった。このことから画面サムネイルの表示が操作とソースコード を結びつける上で有益に働いていると考えられる。また“サムネイルが並べてあることで遷移 の様子が視覚的にわかりやすい”という意見があった。このことから、画面表示の切り替わり が早く肉眼では精密に遷移を辿りきれない場合等にも、サムネイル表示は有効に働いている と考えられる。一方、否定的な評価をした被験者は“イベント番号を確認しながら理解作業を 進めていけば、サムネイルがなくても支障はない”とコメントした。また肯定的な評価をした 被験者から挙がった不満として“サムネイルがイベントが発行されるたびに更新されるのが少 し直観的でない気がした。画面変化がない時にもサムネイルが増えていくと混乱する”とい う意見があった。まず前者の意見に関して言及する。今回の実験ではマウスの連続操作中に

画面変化が伴う機能の理解作業を行う設問を含んでいたものの、マウスを滞留するとイベン ト番号を確認することが可能であった。しかし、例えば、スナッピング機能の理解作業では 上記の方法は困難である。スナッピングは連続的なドラッグ入力の処理中に実行される。ス ナッピングの処理が行われた時点でのドラッグイベントでイベント発行を止めようとしても、

ドラッグ中の場合には即座に次のイベントが発行されてしまうため、イベント番号の確認を 行うことは困難である。次に後者の意見に関して言及する。画面変化毎に区切って表示する ことはユーザにとって直感的である一方、イベント毎に区切ることも行単位で処理を理解す る時に役立つ。そのため今後は、現実装のサムネイルを同一の画面状態を持つイベント群を グルーピングしたものとし、ユーザがそのグルーピングを解除するとイベント毎のサムネイ ルが現れるような機能を実装することでこの問題の対処を行いたいと考えている。

ポップアップ走査とズーミング走査は、それぞれ肯定的な評価を得た。実験中に各被験者 は好みだったどちらかの表示を重点的に使用する傾向にあった。ポップアップ走査では、全体 を俯瞰しながら関数呼び出しを走査できるという点で良い評価を得た。ある被験者は“Eclipse のデバッガを使ったステップ実行に比べて見やすかった”と述べた。一方で、表示の大きさや 表示内容についての不満がいくつか挙がっており、表示方法に改善の余地があることがわかっ た。現在のポップアップは単色で表示され、実行された行と実行されなかった行を区別しな い。実験中に1人の被験者がポップアップされたソースコードを見て、実際には実行されて いない行が実行されているものと勘違いをしてしまい、問題解答を誤るということがあった。

また、“ポップアップされたソースコードの断片だけを見ても詳細な解析を行うには不十分で ある”という意見も挙がった。これはポップアップ走査の表示上で実行された行と実行されな かった行を区別していないことが原因であると考えられる。以上を踏まえると、ポップアッ プの表示上でも実行された行を確認することができれば、情報の質を落とさずに関数走査を 行うことが可能になると思われる。

ズーミング走査では、前後の呼び出しもわかる点やソースコードの詳細を見ながら各行が 実行されたかどうかを確認できる点で肯定的な評価を得た。一方、“ステップを切り替えるた びに起こる表示の変化が大きいので混乱してしまい、関数呼び出しを辿りづらかった”という 意見があった。そのため、“切替時におけるアニメーションをよりリッチにしてほしい”とい う要望が挙がった。

Eclipseエディタ上へのマーカ表示に対しては否定的な意見が多かった。“ソースコードの閲

覧はORCAが提供するズーミング走査とポップアップ走査だけで十分だった”、“関数呼び出 しのエッジが表示されていないため、処理の流れが追いづらかった”というのが主な意見であ る。ある意味ではこれはORCAが提供する表示がソースコードを理解する上で十分に機能す るということを表す結果であると捉えることができるため、それほど悲観的に考える必要は ない。また、今回の実験ではORCAを使用する場合にEclipseが有している各機能（関数呼 び出し階層表示等）を併用することを禁止した。実際にはORCAとEclipseそれぞれの機能 を併用しながら理解作業を行うことも想定できる。その際にはマーカ表示がより効果を発揮 するものと考えている。そのためむしろ、色付けによるソースコード行の強調表示や関数呼 び出しのエッジ付けといったORCAの表示が提供する実行情報すべてをEclipseエディタ上