社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,INFORMATION AND COMMUNICATION ENGINEERS

信学技報
TECHNICAL REPORT OF IEICE.

細粒度プロジェクトモニタリングのためのDaaS を利用したソフトウェア開発 PBL 支援環境の提案
眞鍋 雄貴†

井垣宏†

福安直樹††

佐伯 幸郎††† 楠本真二†

井上克郎†† 大阪大学大学院情報科学研究科 〒 565-0871 大阪府吹田市山田丘 1 番 5 号†† 和歌山大学システム工学部††† 高知工科大学情報学群
E-mail: †y-manabe@ist.osaka-u.ac.jp
あらまし 受講生が主体となって PBL 形式で行われるソフトウェア開発演習では，プロジェクトの進捗に応じた振り返りが重要である．振り返りを行うためにはプロジェクトで行われた受講生ごとのタスクを正確に記録し，問題の抽出や今後の方針の提案を行う必要がある．しかしながら，受講生一人ひとりのタスク記録がどこまで正確かを講師が評価することは困難である．本稿では，DaaS 環境を用いた開発活動の正確なログデータを取得可能な開発環境の構築を行い，どの様なデータを取得できるのか検証を行う．
キーワード

ソフトウェア開発 PBL，振返り，タスク管理，DaaS

Toward software development PBL supporting environment
for ﬁne-grained project monitoring on DaaS
Yuki MANABE† , Hiroshi IGAKI† , Naoki FUKUYASU†† ,Sachio SAIKI††† , Shinji KUSUMOTO† , and Katsuro INOUE†† Department of Computer Science Graduate School of Information Science and Technology, Osaka
University 1–5 Yamadaoka, Suita, Osaka 565–0871 Japan†† Faculty of Systems Engineering, Wakayama University††† School of Information, Kochi University of Technology
E-mail: †y-manabe@ist.osaka-u.ac.jp
Abstract Retrospectives play an important role in a software development exercise of the project-based learning(PBL) style. To conduct retrospectives, students have to collect what they did in a project, extract problems basedon their task records and make a new suggestion for project improvement. However, it is diﬃcult for teachers toevaluate accuracy of their task records collected by students. In this paper, we propose a software development
environment to obtain accurate records in development activities on DaaS (Desktop as a Service). In a case study,
we show the examples of task records collected by our environment.
Key words Software Development PBL, Retrospective, Project Monotoring, DaaS

1. ま え が き
社会インフラとしての IT の必要性や重要性が高まるにつれて，円滑な業務進捗のためのプロジェクトマネジメント力ととして，プロジェクト形式でのソフトウェア開発演習 (ソフトウェア開発 PBL，以降 SDPBL と呼ぶ) が多くの情報系教育機関で行われている [1]．

SDPBL では，複数の受講生がグループを組み，ソフトウェいった高度な技能を備えたソフトウェア技術者の育成が求めら

ア開発における要求分析から運用に至るまでの工程 (の一部分)れている．そのような高度なソフトウェア技術者の育成を目的を実際に体験するという形式で行われることが多い [2]．ただ—1—

し，SDPBL の内容については標準化されたものが存在しないある．PBL 形式による教育は，通常の座学による講義・演習だ

ため，教育機関ごとにその内容が大きく異なっている．

けでは習得の難しいプロジェクトの運用に必要なスキルを，主一方でどのような SDPBL においても必ず行われる活動として，振り返りがある．振り返りとは，プロジェクトにおける受講生らのタスクとその進め方を評価し，改善するためのプロジェクトグループ全体によって行われる活動である [3]．

体的なプロジェクト運営を通じて受講生に獲得させることを目指して実施される [7]．
大学における SDPBL の代表的な例として，松澤らは，顧客を地域の商店や大学教授とし，PM を目指す企業の技術者

振り返りでは，行われたプロジェクトからの問題の抽出や改と学生が協同することで顧客が望むソフトウェアを作成する善のための方策の提案，実施された方策に対する評価を具体SDPBL を報告している [2]．沢田らは，組み込みソフトウェア的な指標や根拠に基づいて行うことが重要であるとされてい開発プロジェクトをテーマとし，分析から受け入れテストまでる [4]．そのため，SDPBL ではプロジェクト中に行われた受講を行って飛行船制御ソフトウェアを作成する SDPBL を報告し生一人ひとりのタスクを正確に記録する方法とその記録に基づている [8]．これらの SDPBL の多くでは，納期の順守や成果物

いた具体的な振り返り実施手法を講師が指導する必要があるの高い品質，必要工数といった制約を受講生らのグループに課

我々の研究グループでは，アジャイルソフトウェア開発手法の一つであるチケット駆動開発 [5] を用いて，SDPBL を行ってすことで，プロジェクトマネジメントの重要性を受講生に認識させることに成功している．

きた [6]．この開発手法では，受講生一人ひとりのタスクがチ

我々の研究グループでは開発実践演習という SDPBL をこれケットという単位でチケット管理システムによって記録されるまで行ってきた．開発実践演習では，チケット駆動開発と呼ばため，振り返りの判断基準となるタスク記録を容易に収集するれる開発方法論に基づき，詳細設計から実装・テストに至る工ことができる．一方で，タスクの開始・終了時刻やタスクに要程がプロジェクト形式で行われる．チケット駆動開発は，一人した時間といった記録は受講生の負荷が大きいため，誤って記の開発者が一つの成果物を対象として行う一種類のタスクを録されることも多い．実際に我々が行った SDPBL を対象としチケットとして登録し，開発者の割り当てやタスク開始の宣言て，受講生に記録されたチケットに含まれる誤りの数を分析しといったチケットに対する操作によって開発を進めていく開発たところ，平均して 40%程度のチケットにおいて，タスク開始手法である．各受講生は，一人の受講生が一つの成果物を対象(着手) 時刻や終了時刻，タスク粒度といったタスクを構成するとして一度に行う活動という粒度で，タスクを行い，その内容要素のいずれかが誤って記録されていた．

や成果物，開始・終了時刻といったタスクに含まれる情報がチ

そこで我々は受講生らによって記録されたタスク情報がケットとして記録される．

正しいかどうかを講師が分析する際の支援を目的として，このように様々な種類の SDPBL が主に情報系の大学を中心

DaaS(Desktop as a Service) を用いた開発環境における細とした教育機関で行われている．なお，以降では我々が行って粒度プロジェクトモニタリング手法を提案する．DaaS とはデいる SDPBL を対象として提案を行う．

スクトップ環境を仮想化し，クラウドサービスとしてインター2. 2 ソフトウェア開発 PBL における振り返りネット上で提供する枠組みを指す．ソフトウェア開発環境を教育機関ごとに内容が異なる SDPBL において，どこの教育DaaS 上に構築することで，開発者はどこからでも常に同じ環機関でも必ず行う活動として振り返りがある．振り返りとはプ境でソフトウェア開発に携わることが可能となる．我々はこのロジェクト中あるいは終了後にプロジェクトメンバ自身によっような DaaS 上のソフトウェア開発環境を利用し，その開発環て行われるプロジェクト改善のための自主的な活動で，メンバ境で受講生が行っているアプリケーション操作を様々なログに全員によるミーティングの形式で行われる [3]．ミーティングによって記録することで，細粒度のプロジェクトモニタリングをよって，プロジェクトを進めていく上での問題点を洗い出し，実現する．DaaS 上でのソフトウェア開発環境では，ログイン・次のプロジェクトに向けた改善点の提案についての同意をメンログアウト時刻やアプリケーションの起動・終了時刻，ファイバ間で得る．提案された改善点は次の振り返りのときにその有ルに行われた修正内容といった受講生の振る舞いが記録される．

効性が評価される．このような活動を繰り返すことにより，プこれらのログを収集し，受講生によって記録されたタスク情報ロジェクトの質を高めることが可能となる．と比較することで，どのタスク記録にどのような誤りがあるかを講師が検知することが容易となると考えている．
以降では，タスク記録において発生する誤りに関する予備実代表的な振り返り手法として，KPT 法 [4] が提案されている．

KPT 法では，効果があったため引き続き行うこと (Keep），問題があったので改善すべきこと (Problem)，次回から行いたい験と，提案するプロジェクトモニタリング環境のプロトタイプ

こと (Try) の 3 つの観点について，メンバ間で議論が行われる．

によるケーススタディについて詳述する．

プロジェクトにおける問題の発見や改善点の提案に対する効果

2. 準備の確認のためには，プロジェクトで各受講生が行ったタスクが記録されていることが重要である．例えば，納期遅れという問2. 1 ソフトウェア開発 PBL

題とその原因を調査するためには，特に時間のかかったタスク

SDPBL とはソフトウェア開発プロジェクトをテーマとし，が何であるかという情報が必要となる．また，タスクの割り当

実践的なソフトウェア開発プロセスやプロジェクトマネジメンてに無駄がなかったかどうかを調べるためには，ガントチャートを受講生に体験させることを目的とした PBL 形式の演習でトのような形式で，誰がいつ何をやっていたのかといった記録—2—

が重要である．実際に松澤ら [9] は，プロジェクト中の全ての情報と開発実践演習で受講生らが用いた版管理システムのログタスクについて分単位の作業時間を受講生に入力させること情報を受講生に提示した．ここで版管理システムのログ情報にで，プロジェクトの進捗と予定されたスケジュールとの乖離をは，check-out，commit，update といった版管理システムに対分析する手法を SDPBL で行っている．我々が実施している開する受講生の全ての操作内容が含まれている．調査では，受講発実践演習においても，チケット駆動開発によって得られた受生が講師によって与えられたタスク情報および版管理システム

講生一人ひとりのタスク記録を用いて，納期やタスク割り当てのログ情報と，必要であれば受講生自身が記録していた受講生といった複数の観点に基づいて，振り返りを支援する取り組み

間のコミュニケーションの記録 (Skype 等のチャットツールがを行ってきた [10]．

利用されていた）を利用し，全てのタスク情報の誤りを指摘し一方で，チケット駆動開発における一タスクのような粒度の細かい情報は誤って記録されることも多い．特にタスクの着手てもらった．受講生によるタスク情報の誤り指摘終了後に，指摘された誤りの集計を行った．

時刻や終了時刻，開発時間といった時間に関する情報は，タス

誤り分類では 1. タスク情報誤り，2. タスク粒度誤り，3. タス

クの粒度が細かくなればなるほど正確な記録が難しくなる．まク記録漏れの 3 種類のカテゴリを規定した．タスク情報誤りはた，受講生にタスク記録を正確に行うよう指導するためには，タスク情報に含まれる a∼h までの要素が誤ってチケットに入力

講師自身が正確な値を認識してなければならないが，そのためされていることを表す．タスク粒度誤りは，2(a) の “記録されには非常に大きなコストが講師にかかってしまう．そこで本研たタスクの粒度が大きすぎる” あるいは 2(b) の “小さすぎる場

究では受講生のプロジェクトの進捗状況と受講生によって行わ合” を示す．我々は開発実践演習において，記録されるべきタれたタスクの記録が正確であるかを講師が容易に評価するため「一人の受講生が一つの成果スクの粒度を 2. 1 節で述べた通り，のプロジェクトモニタリング環境を提案する．受講生によるタ物を対象として一度に行う活動という粒度」と規定し，受講生スク記録の正確性を評価するためには，実際に受講生がどのよらに通知した．この定義と異なる粒度で記録されているチケッ

うな点において記録を誤る傾向にあるのかを分析する必要があトがあった場合に，誤りと分類した．タスク記録漏れは，3(a)る．そこで我々は実際に行われた SDPBL において，どのようの “実施されたにも関わらず記録されていないタスク” や 3(b)な種類の誤りがどの程度含まれるかを明らかにするべく，予備の “実施されていないにも関わらず記録されているタスク” が実験を行った．

あった場合に分類される項目を示している．

3. 予備実験：タスク記録に含まれる誤り分析
3. 1 実 験 設 定

3. 2 実 験 結 果
予備実験の結果を表 1 に示す．受講生グループによって記録された合計 1419 件のタスク記録のうち，1 つでも誤りを含む

本研究において我々は，2011 年度に 3 週間にわたって行われタスク記録は 570 件であった．なお，誤りを含むタスク記録件

た SDPBL「開発実践演習」において受講生が行ったタスク記数の中に分類 3(a) の “記録されていないタスク” の件数は含ま録を対象として，どのような種類の誤りがどの程度の量含まれれていない．

るかの分析を行った．開発実践演習では 5∼6 名からなる 6 グ

結果より，どのグループでも多かった誤りは 1(a) 着手時刻，ループの受講生らが，与えられた詳細設計書に基づいて実装・1(b) 終了時刻，1(d) 見積時間，1(e) 総時間，の時間に関する誤レビュー・単体試験・結合試験といったタスクを成果物ごとにりの 4 種類と 2(a) の記録されているタスク粒度が大きすぎる遂行し，原則として全てのタスク情報をチケットとして記録しものであった．着手時刻は，受講生がチケットに対して着手とた．チケットの記録にはチケット管理システム「Trac」[11] をいう操作をしたときに記録される．この操作は本来実際にタス利用している．また，本演習で記録されたチケットは 1 グルークを開始する際に行われるべきものであるが，着手操作を行うプあたり平均 240 枚程度であった．開発実践演習で記録されたのを失念しているケースが多くあった．終了時刻についても同

タスク情報は下記に示す通りである．

様に，タスク終了時にチケットに対する終了操作をするのを忘a. 着手時刻: タスクに着手した日時

れているケースが存在した．見積時間および総時間の項目につb. 終了時刻: タスクを終了した日時

いては，タスク開始時あるいは終了時にそのタスクを遂行する

c. 担当者: タスクの担当者名のに受講生が要すると推測した時間，あるいは実際に要した時

d. 見積時間: タスク実施に必要と見積もられた時間

間を手入力する形式になっていたが，入力値が 0 のままになっ

e. 総時間: タスク完了にかかった時間ているものが非常に多く存在した．着手・終了と同様入力漏れ

f. 成果物: タスクで作成・編集される対象物があったものと考えられる．タスク粒度については，一度終了

g. 種類: タスクの種類

したタスクに対応するチケットを使いまわすことで，見かけ上

h. マイルストーン: このタスクを含むあるまとまりのタスクのタスク数が少なくなっている事例が散見された．例えば，あ群が実施されるべき期限

る成果物の実装タスクが終了し，対応するチケットに対して終本予備実験では，開発実践演習終了後に各グループより受講了という操作を行ったあとにも関わらず，レビューやテストで生を 1 人選び，自分が所属したグループの全てのタスク情報に検出されたバグ修正タスクの記録に，同じチケットを使いまわついて誤りが存在しないかを調査してもらった．調査の際には，している事例があった．

講師より Trac に記録された全てのチケットに含まれるタスク

これらの誤りのうち見積時間については，受講生の想定した—3—

表 1 予備実験の結果記録された誤りを含むチケット詳細

チケット数

1. タスク情報誤り

誤りを含む

2. タスク 3. タスク
粒度誤り(a) (b) (c)(d)(e) (f) (g) (h)

(a)

チケット数

記録漏れ

(b) (a)

(b)

G1208

181164250

102242067(32.2%)

G2302

16551047202

150

1188(29.1%)

G3

270

2

1012372

0

10

34

00

1 112(41.4%)

G4242

29

6349

74

01157

40

5 146(60.3%)

G5182

24

16026

38

620

19

00

183(45.6%)

G6215

348183608

1809174(34.4%)

合計1419 12356

16 120 292

19134 155

8129 570(40.1%)

値が記録される項目であるため，タスク記録より誤りを推定すL2(ファイル操作ログ): 受講生がファイルに対して行った追ることは非常に困難である．そのため，本研究では入力が行わ記・削除・編集の内容とその日時を記録したログ．

れていない場合のみを誤りの対象とした．また，タスク粒度以SDPBL では，受講生が実施するタスクの種類に応じて，利外の誤りについては，入力漏れのものや，チケット情報や版管用するアプリケーションが異なることがある．例えば，実装・

理システムのログ情報から明らかに間違っていると推定される

単体テストは統合開発環境を用い，レビューはテキストエディものしか今回の調査では検出されていない．そのため実際にはタや表計算ソフトを用いるといったケースが存在する．そのたもっと多くのチケットに誤りが含まれている可能性がある．

め，受講生が実施するタスクの種類が事前に分かっていれば，以上の分析から分かるように，手作業で行われるタスク記録には誤りが含まれる可能性が非常に多い．そのため，SDPBLアプリケーション操作ログによって作業開始・終了時刻や総時間の推定を支援できると考えられる．

における振り返りを指導する際にはこれらの誤りが含まれてい一方で，受講生がタスクを実行する際，複数のアプリケーることを講師が認識し，適切な記録方法や誤りそのものの指摘ションを利用したり，複数ファイルを参照したりすることがあを振り返り前に行う必要がある．そこで本研究では，予備実験る．例えば，レビューを行う際にはレビュー対象のファイルとで明らかになった 5 種類の誤りのうち，見積時間を除く 4 種

仕様書やチェックリストを参照しつつ，テキストエディタ等に類の誤りについて，誤っていることを講師が検知できるようにレビュー結果を記述する．そのため，アプリケーション操作ロ支援するシステムを構築する．

グのみでは，正確に受講生がどのタスクを実施しているかを推定することは困難である．そこで，L2 としてファイルに対す

4. DaaS を用いたソフトウェア開発環境における細粒度プロジェクトモニタリング

る編集作業の内容をログとして収集する．L2 のログによって，我々はタスク記録における誤りを講師が検証できるようにす定できるようになる．

受講生がどの成果物を対象としてタスクを実施しているかを推ることを目的とした細粒度プロジェクトモニタリング環境を

L1，L2 のログにより，DaaS 上のソフトウェア開発環境を利提案する．提案する細粒度プロジェクトモニタリング環境は用した開発ログ収集によって，受講生がどの成果物を対象としDaaS(Desktop as a Service) を利用して構築されるソフトウェてどのアプリケーションをいつからいつまで操作していたかをア開発環境とサーバ上に配備される版管理システム等の開発支確認することが可能となる．

援環境およびこれらの環境それぞれに組み込まれた開発ログ取得機能によって構成される．以降では，それぞれの環境とその環境における開発ログ取得機能について詳述する．

4. 2 サーバ側開発支援環境を用いた開発ログ取得
SDPBL では，統合開発環境やエディタといったソフトウェ
ア開発環境だけでなく，チームでの開発を支援する開発支援機

4. 1 ソフトウェア開発環境における開発ログ取得能が用いられることが多い．我々が想定する SDPBL では，チDaaS とはクラウド上に仮想化されたデスクトップ環境を配ケット管理システムと版管理システムが開発支援環境に相当す置し，インターネットを介してユーザに提供するための枠組み

る．開発支援環境における受講生の操作内容を下記に示すようである．インターネット越しにデスクトップ環境を利用できるなログとして収集することで，受講生に現在割り当てられていようにすることで，一定のセキュリティを確保した状態で共通るタスクの情報や成果物の開発状況を確認することができる．の開発環境をどこからでも利用することが可能となる．DaaS

L3(チケット情報ログ): チケット管理システムに対して行われを用いることで，受講生のタスク遂行時の開発作業をログとしたチケット情報およびチケットに対して行われた操作ログ．て収集する機能を組み込んだ共通のソフトウェア開発環境を容L4(版管理システム操作ログ): check-out， commit，update易に構築することが可能となった．我々のソフトウェア開発環といった版管理システムに対して行われる受講生の操作ログ．

境で収集される開発ログは下記の 2 種類である．

3. で述べた予備実験で，タスク情報における担当者や成果物

L1(アプリケーション操作ログ): 受講生が任意のアプリケーの誤りは比較的少ないことが分かった．そのため，チケットとションの操作を開始・終了した時刻を表すログ．

して登録されたタスクの担当者と成果物が正しいと仮定するこ—4—

とで，L3 によって特定の受講生が実施すべきタスクの内容を推サーバといったソフトウェア開発に用いられるソフトウェアで定することが可能となる．また，チケットに対する着手操作やある．また，ManicTime は L1 のログを，Dropbox は L2 のロ

終了操作のログ情報によって，受講生の意図するタスク開始・グを収集するために導入した．ManicTime では，アプリケー終了時刻を取得できる．

ションの稼働状況，ドキュメントへのアクセス状況についてロ

我々が想定する SDPBL では，原則として全てのタスクにおグを取ることができる．アプリケーションの稼働状況ログは，いて成果物の作成・編集が行われる．そのため，タスクの終了

アプリケーション名，プロセス名，稼働開始日時，稼働終了日

は版管理システムに対して成果物を登録・更新する日時とほぼ時，稼働時間からなる．ドキュメントへのアクセス状況ログは，等しくなる．L1，L2 のログと L4 のログを合わせることで，あアクセスされていたドキュメント名，アクセス開始時刻，稼働る受講生の特定の成果物に対するタスクが終了した日時の推定終了時刻，アクセス時間からなる．Dropbox はクラウドを用いが可能となると考えられる．

たファイル共有サービスである．Dropbox は，ファイルが編集以上のログを分析することで，L3 によって受講生に割り当てられているタスクの情報を認識し，L1，L2 によって対象成され，保存されるたびに，各ファイルが編集された時刻と編集されたファイルそのものを記録することができる．

果物に対する編集内容およびタスクの実施時間を推定し，L4

ソフトウェア開発支援環境によってタスク終了時間を検知することが可能となる．結果と•Trac 0.11.7.ja1

して，完全に自動でタスク情報を記録することは難しいとして•Subversion 1.6.11-2

も，受講生によって記録されたタスク情報との間の齟齬を検知することは可能となると考えている．
我々はここで提案したログ収集機能を備えたソフトウェア環

Trac をチケット管理システムとして，Subversion を版管理システムとして利用した．Trac におけるチケット情報を L3 のログとして記録し，Subversion に対して行われた受講生の操作境およびソフトウェア開発支援環境のプロトタイプを実際に構

ログを L4 として記録する．本ケーススタディでは，これらを築し，実験を行った．次節ではプロトタイプシステムの紹介とCentOS 6.0 の搭載されたサーバ上で用いた．

プロトタイプシステムを用いて行った実験内容をケーススタ
ディとして示す．

5. ケーススタディ

5. 2 グループ開発内容
本ケーススタディでは，事前に用意された Web アプリケーションのひな形に対して，詳細設計書に基づいてある機能を追加するという開発プロジェクトにグループで取り組んでもらっケーススタディとして，本稿で提案するプロジェクトモニタた．被験者は大学教員 4 名で，全員が Java 言語による Web

リング機能を備えたソフトウェア開発環境およびソフトウェア

アプリケーション開発経験とチケット管理システム利用経験を開発支援環境を edubase Cloud [12] を用いて実装し，実際に小持っている．各被験者が取り組んだタスクは実装・レビュー・規模なグループ開発を行った．本章ではプロトタイプとして構単体試験・結合試験の 4 種類で，対象成果物は実装対象の Java築した各環境とグループ開発の内容および提案環境によって収ソースコード，単体試験の Java ソースコード，コードレビュー集されたログ情報について詳述する．

報告書，試験報告書の 4 種類であった．開発中は行われたタス

5. 1 ソフトウェア開発環境および開発支援環境

クをより正確に把握するため，別途チャットシステムを用いて，ソフトウェア開発環境および支援環境のプロトタイプを以下

タスクの開始・終了時刻を被験者が宣言し，記録した．に示す．

5. 3 グループ開発結果

ソフトウェア開発環境

グループ開発は 4.5 時間かけて行われた．また，Trac に記録

仮想デスクトップ仕様

されたタスク数は 26 件で，これはチャットシステムで確認され•OS:Windows XP Professional 32bit

たタスク数と一致した．被験者全員がチケット管理システムを•

CPU:Intel Xeon 2.4GHz 2 コア

用いた経験があることとチャットシステムによって開発進捗を•

Memory:4GB，HDD:20GB

厳密に管理していたこともあり，今回の開発ではチケットに対本ケーススタディでは全ての被験者がこの仕様の仮想デスクトップにリモートデスクトップ接続機能を利用してアクセスし，ソフトウェア開発を行う．

する操作もほとんど誤りなく行われた．
一人の被験者について，チケットに対する着手を忘れていた事例があったため，着手忘れを提案システムによって検知でき導入ソフトウェアるか評価を行った．図 1∼4 は，対象の被験者が着手を忘れてい•Java SE Development Kit 7 Update 5た時刻前後の L1∼L4 のログを表している．チケット管理シス•Eclipse IDE Juno for Java EE Developers

テムにおいて記録されていた，被験者 X が着手を忘れていたタ•MySQL Community Server 5.5.24

スクの情報を図 3 に示す．タスク情報から，担当者が X であ•Apache Tomcat 7.0.28

り，対象タスクの種類はコードレビューで，作成する成果物が•ManicTime [13]classAreview.txt であることが分かる．図 2 から被験者 X が•Dropbox [14]classAreview.txt を作成した時刻が 2012/7/6 13:40 であると

JDK，Eclipse，MySQL，Apache Tomcat はそれぞれ言語分かる．さらに，図 1 から classAreview.txt ファイルを eclipse

環境や統合開発環境，データベースサーバにアプリケーションで 13:40 に作成し，開いていることが分かるため，この時刻が—5—着手時刻である可能性が高いといえる．このあと被験者 X は図れたツールにより行われる必要がある．特に，各自のデスク2 のログより，13:51 まで作業を続け，図 4 のログより 13:52 にトップ上にインストールされるソフトウェア開発環境は，個別コミットし，タスクを終了していることが分かる．図 1 のログに設定をしなければならない．各自が利用するデスクトップ環より，途中で休憩を挟んでいる様子も見られないので，タスク

境を DaaS を利用して提供することで，L1 および L2 のログをの総時間は約 12 分であったと判断できる．

収集する機能を含んだ共通のソフトウェア開発環境を受講生に以上の分析より，図 3 のタスク情報は着手時刻が約 20 分遅れており，終了時刻が 8 分遅れていることが分かる．また，総時間も実際は 0.2 時間であることから，0.1 時間少ない値が記録されていたことが分かる．
新規ファイル 2012/7/6 13:40 2012/7/6 13:40 0:00:08 eclipseclassAreview.txt 2012/7/6 13:40 2012/7/6 13:41 0:01:23 eclipse
classA.java 2012/7/6 13:41 2012/7/6 13:42 0:01:11 eclipse
classAreview.txt 2012/7/6 13:42 2012/7/6 13:45 0:02:37 eclipse：（省略）classA.java 2012/7/6 13:51 2012/7/6 13:51 0:00:06 eclipse
classAreview.txt 2012/7/6 13:51 2012/7/6 13:51 0:00:31 eclipse
コミット 2012/7/6 13:51 2012/7/6 13:52 0:00:14 eclipse
classAreview.txt 2012/7/6 13:52 2012/7/6 13:52 0:00:28 eclipse

容易に利用させることが可能となった．

6. まとめと今後の課題
本研究では，SDPBL において受講生により記録されたタス
ク情報の正しさを，講師が検証できるようにすることを目的とした細粒度プロジェクトモニタリング環境を提案した．提案に基づいて，開発ログを取得するための環境を DaaS 上に構築し，ケーススタディを実施した結果，予備実験において多かった，時間に関する誤り（着手・終了時間および総時間）を検出し，正しい値を推定することができた．一方で，タスク粒度の誤りについては今回の事例には含まれなかったため，検証すること

図1

L1:被験者 X のアプリケーション操作ログはできなかった．
今後の課題としては，タスク情報における誤り判定の自動化

バージョン 1 DeveloperX による Added 2012/7/6 13:40 0 bytes
バージョン 2 DeveloperX による Edited 2012/7/6 13:50 27 bytes
バージョン 3 DeveloperX による Edited 2012/7/6 13:51 79 bytes
図2

L2:classAreview.txt のファイル操作ログが挙げられる．また，実際の SDPBL に適用することにより，本手法のさらなる検証と有効性の確認が必要である．
謝辞 本研究は，日本学術振興会科学研究費補助金若手研究（B）（課題番号:24700030）の助成を得た．
文

着手時刻:2012-07-06T14:00:04+0900
終了時刻:2012-07-06T14:00:09+0900
担当者:DeveloperX
見積時間:0.3 時間
総時間:0.1 時間
成果物:classAreview.txt
種類:コードレビュー
マイルストーン:2012-07-06T17:00:00+0900
図3

L3:着手忘れタスク情報ログ[06/Jul/2012 : 13 : 38 : 20] DeveloperX update /project r13[06/Jul/2012 : 13 : 50 : 50] DeveloperX update /project r15[06/Jul/2012 : 13 : 52 : 05] DeveloperX commit r16
図4

5. 4 考L4:被験者 X の版管理システム操作ログ

察

タスクが対象とする成果物の履歴を L1 で取得し，L2 によってより詳細に分析することにより，タスクの時間に関する属性，すなわち着手・終了時刻および，総時間を推定することができた．この推定に基づき，チケットに記録された着手・終了時刻および総時間と比較した結果，一部のチケットにおいて入力された記録と異なることが分かった．チャットシステムの履歴からも，該当するチケットに入力された記録が誤りであることが確認されており，本手法による誤りの検知の可能性を確認することができた．一方，タスクの粒度誤りについては事例数が不十分であったためプロトタイプシステムで対応が可能であるか確認できなかった今後粒度誤りの事例においても，誤りを検知できるか分析していきたい．
誤り検知のためのログの収集は，同じ設定でインストールさ献[1] 独立行政法人情報処理推進機構，“IT 人材白書 2010,” 2010．
[2] 松澤芳昭，杉浦 学，大岩 元，“産学協同の PBL における顧客と開発者の協創環境の構築と人材育成効果,” 情報処理学会論文誌，vol.49，no.2，pp.944–957，2008．
[3] 天野 勝，“プロジェクトファシリテーション実践編振り返りガイド第 20 版”．
[4] A. Cockburn, Agile Software Development, AddisonWesley, 2003.
[5] まちゅ，“チケット駆動開発 … itpro challenge のライトニン
グトーク (4),” Sept. 2007． http://www.machu.jp/diary/20070907.html．
[6] 井垣 宏，柿元 健，佐伯幸郎，福安直樹，川口真司，早瀬康裕，崎山直洋，井上克郎，“実践的ソフトウェア開発演習支援のためのグループ間比較にもとづくプロセスモニタリング環境,”
日本教育工学会論文誌，vol.34，no.3，pp.289–298，2010．
[7] H. Batatia, A. Ayache, and H. Markkanen, “Netpro: aninnovative approach to network project based learning,”
Proc. International Conference on Computers in Education(ICCE’02), pp.382–386, 2002.
[8] 沢田篤史，小林隆志，金子伸幸，中道 上，大久保弘崇，山本晋一郎，“飛行船制御を題材としたプロジェクト型ソフトウェア開発実習,” 情報処理学会論文誌，vol.50，no.11，pp.2677–2689，2009．
[9] 松澤芳昭，塩見彰睦，秡川友宏，酒井三四郎，“ソフトウェア開発の教員主導型 PBL における反復プロセスと EVM 導入の効果,” 情報処理学会研究報告. コンピュータと教育研究会報告，第2009 巻，pp.1–8，May 2009．
[10] 福安直樹，佐伯幸郎，水谷泰治，“リポジトリのリアルタイムな可視化にもとづく PBL の支援環境〜継続的な実施を目的として〜,” 電子情報通信学会技術研究報告，vol.110，no.458，pp.121–126(SS2010–73)，2011．
[11] “Trac”. http://trac.edgewall.org/ 参照 Jul. 6,2012.
[12] “edubase Cloud”. http://edubase.jp/cloud/ja/ 参照 Jul.
6,2012.
[13] “Manictime”. http://www.manictime.com/ 参照 Jul. 6,2012.
[14] “Dropbox”. https://www.dropbox.com/ 参照 Jul. 6,2012.

—6—