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

過去の PBL の開発履歴を活用した PBL 運用支援伊藤 恵

木塚 あゆみ奥野 拓

大場 みち子

近年，情報教育の分野において PBL(Project Based Learning) を用いた実践的な教育が着目されてきている．PBLの有効性については一定の評価があるものの，PBL をどのように運用するのが効果的・効率的であるか，そのノウハウの蓄積は不十分である．一方，システム開発を中心とした PBL 実施の際にはプロジェクト管理やバージョン管理のための様々なツールが用いられることが多く，それらのツールには多くの情報が蓄積される．本研究では，過去のPBL によって蓄積されたプロジェクト管理ツール Redmine のチケット情報と，バージョン管理ツール Subversionのコミット情報を分析し，そこから PBL 運用に有用な情報の抽出・提示を行うことを目指す．

In recent years, practical education using PBL(Project Based Learning) is focused on information education
area. Eﬀectiveness of PBLs achieve a measure of legitimacy. But, it is insuﬃcient to accumulate know-how
on eﬃcient and eﬀective operation of PBLs. For system development PBLs, several tools are used such as
project management tool, version control tools and so on. In such tools, a lot of information about thedevelopment are accumulated. This study aims to provide useful information for PBL operation by collecting and analyzing both tickets of Redmine which is a project management tool and commits of Subversion
which is a version control tool.

役立てる取り組みは様々ある [3] [6]．しかし，こういっ1 背景と目的た可視化情報でさえも，システム開発やプロジェクト近年，情報教育の分野において PBL を用いた実践マネジメントの実務経験のない大学教員にとっては，的な教育が着目されてきている [1] [4]．PBL の有効性

そのプロジェクトの進捗状況がどの程度のもので，どについては一定の評価があるものの，PBL をどのよのくらい深刻か否か判断するのは困難であることがうに運用するのが効果的・効率的であるか，そのノ多い．一定数以上のグループが同時並行に同じシスウハウの蓄積は不十分である．産学連携により企業テムを開発するグループ並行型 PBL において，複数から実務経験のあるプロジェクトマネージャが大学のグループのプロジェクト情報を同時並行に可視化し，PBL に参加することによって，その経験や勘を踏まその比較を行うことで，実践経験の少ない教員でもえてプロジェクト運用をする事例も多いが，永続的にプロジェクトへの指導が可能な程度に情報を得られ企業からの協力が得られるわけではないことのほか，る試みは行われている [2] [5] [7]．また，これらの試み開発プロジェクトとしての成否と教育としての PBL

ではよく作りこまれた PBL 教材を使うなど，教員がの成否は一致しないことから，大学教員によるプロPBL 全体を制御し易い状態で PBL を実施している．

ジェクト運用が本来であることは間違いない．

しかし，PBL の実践的教育としての効果を十分生か

一方，ソフトウェア開発プロジェクトの残す様々なすためには多くのチームが同じ題材を扱うことが良

情報を可視化して，それによってプロジェクト管理にいとは限らないし，必ずしも制御し易くないような実践的な題材や環境で行うことで，より効果的な実践的

A Support for PBL Operation Using Development
History of Past PBLs
Kei Ito, Ayumi Kizuka, Taku Okuno, Michiko Oba,
公立はこだて未来大学, Future University Hakodate.

教育が行えると考えられる．また，そもそも十分なグループ数を構成するほど学生数が多くはない実施状況も多くあり得る．

そこで本研究では，同時並行に同じシステムを開発ことにより，進行の遅い (あるいは早い) グループやするグループを比較するのではなく，過去に実施され特異な活動をしているグループを見つけるのを容易た類似の PBL の情報と，現在進行中の PBL の情報にしていることや，教材としてよく作りこまれた開発を比較可能な支援をすることで，実務経験の少ない大題材を複数年に渡って使用することで，教員側も開発学教員が，グループ数や開発題材に依らず，有効なプ題材についてよく把握しているという状況での実践ロジェクト運用を行えるようになることを目指す．

である．十分な数のグループ数が構成できないような

2 節では関連する先行研究や先行事例を紹介する．

学生数の場合には対応が難しいほか，システム開発が3 節では PBL 運用支援のための具体的なアプローチ

より実践的であるために開発題材をより新しいものを述べ，このアプローチに基づく運用支援を実施するに変えていく場合やグループごとに異なる題材を扱ためにデータ収集した過去の PBL について 4 節で述う場合への対応も困難である．

べ，進行中の PBL との対比可視化方法について 5 節で，運用支援の試みについて 6 節で述べる．

福安ら [7] は同じようなグループ並行型 PBL を同様なグループ数に対し，より少ない教員数で実践しており，教員による成果物検査等を一部省略しながら2 関連研究も，教員数以外の条件は同様である．

2. 1 開発履歴の利用
ソフトウェア開発プロジェクトの残す様々な情報を3 アプローチ可視化して，プロジェクトのモニタリングを行い，そ本研究では，過去に実施した類似 PBL の開発履歴

れによってプロジェクト管理に役立てる取り組みはを活用し，それらと現在進行中の PBL のプロジェク行われてきた．EPM [3] [6] ではソフトウェア開発プロトデータと対比させて可視化することで，そのプロジェクトにおいて構成管理，メーリングリスト管理，ジェクトの進捗の程度などを実務経験のない大学教員障害管理などの各システムからリアルタイムに情報でも容易に確認できるようにすることを目指す．

を収集して，プロジェクトの状態を可視化し，それに過去の PBL の開発履歴として，昨今の PBL にてよってプロジェクトのリアルタイム管理を目指した．

よく利用されていると考えられるチケット管理システ

現在では Trac や Redmine などの有用なプロジェク

ムおよびバージョン管理システムからのデータ収集をト管理ツールにより，EPM と類似のプロジェクト状行い，蓄積する．そのデータと現在進行中の PBL の態可視化が可能となっている．しかし，システム開発チケット管理システムおよびバージョン管理システムやプロジェクトマネジメントの実務経験のない大学のデータとを対応付けて，運用支援となる情報の可視

教員にとっては，これらから得られる情報だけでは，化提示を行う (図 1)．

その進捗状況がどの程度のものか，どのくらい深刻か判断するのは困難であることが多い．

3. 1 チケット管理システムからのデータ収集
チケット管理 (または Issue 管理) システムからの2. 2 PBL 支援システム

データ収集は，trac のチケット情報，Redmin のチ

井垣, 柿元ら [2] [5] は，システム開発やプロジェクケット情報，および，GitHub の Issue 情報からのデー

トマネジメントの実務経験のない教員でもシステム開タ収集を想定しているが，4 節で述べるように今回発 PBL における指導を容易にすることを目指して，実際に開発履歴データの収集をした PBL はいずれもPBL 環境を構築している．しかし，彼らの PBL 実

Redmine を使用していたため，今回は Redmine のチ

践では，複数の学生グループが同じ仕様書から同じシケット情報収集のみについて述べる．

ステムを開発するグループ並行型 PBL の特徴を活かRedmine はその設定によってチケットに保存できしたものであり，一定数以上の学生グループが同時並る情報も異なってくるが，今回収集対象とするのは以行に同じシステムを開発するのをモニタリングする下の情報である．

図1

PBL 運用支援システム• チケットの作成者

3. 2 バージョン管理システムからのデータ収集• チケットの担当者

データ収集対象のバージョン管理システムとして• チケットの作成日時

CVS，Subversion，Git を想定しているが，4 節で述• チケットの作業が着手された日時

べるように今回実際に開発履歴データの収集をした• チケットが close された日時

PBL はいずれも Subversion を使用していたため，今• チケットの種別

回は Subversion のリポジトリ情報収集のみについて

作成者および担当者については，個人名を特定する述べる．

必要はなく，チーム内の誰であったかを収集すること

Subversion のリポジトリに保存されている情報ので，作成者および担当者のチーム内での偏りを抽出す

うち，今回収集対象とするのは以下の情報である．

るために使用する．チケットの種別はチケット管理シ• コミットした人

ステムやその設定によって様々だが，収集できる範囲• コミットした日時

でその偏りや使い分けの程度を判別するために使用• コミットによって追加/変更/削除されたファイ

する．

PBL ではチケット管理システムを使うよう指示し

ルとその行数• コミットメッセージの有無ても，必ずしも十分に使いこなせるわけではない．チ• コミットメッセージ等からチケット管理システケットを作成し忘れたまま作業をしてしまい，作業がムのチケットとの関連が分かれば関連するチケッ終わった時点で気が付いて作成する場合や，実際は担トの番号当者が決まっていてもチケット上の担当者を設定しなコミットによる具体的なファイルの変更内容まではいまま進んでしまう場合などもある．もちろん，チ考慮せず，行数の変化までを対象とする．リポジトリ

ケットが適切に作成され，適切に更新されるのが望まには開発対象のソースコード以外にドキュメント類しいが，PBL のチケット情報にはそういうデータのも格納する可能性があるが，ドキュメント類は PBL欠落もあり得るという前提で収集する．

で使用する開発プロセスによって大きく異なるため，また，多くのチケット管理システムではそのチケッ

今回は主にソースコードに着目する．

トの作業の工数見積もりや作業実績なども入力可能でまた，バージョン管理システムではリポジトリで管あり，これらの項目が十分に活用されていれば，PBL理されているファイルを更新するためのコミット等の運用支援のための極めて有効な情報となるが，実際の操作だけでなく，開発作業のためにリポジトリからに PBL からのデータ収集を行ったところ，入力し忘ファイルを取り出すアップデート等の操作の記録も，れが非常に多い項目でもあったため，今回は敢えて収そのプロジェクトの活動の様子を把握するために有用集対象から除外した．

である可能性があるが，今回はそこまでは考慮していない．

4. 1 チケット数の推移

4 過去の PBL 開発履歴

チケット管理システムから得られるデータをプロ著者ら所属大学で 2013 年度に実施された 4 種類 11

ジェクトの状況を示すために可視化する方法の一つ

チームの PBL について蓄積された情報を収集した．に，チケット数の推移をグラフ化する方法がある．

情報収集した 4 種類の PBL は表 1 の通りである．プ

図 2 は enPiT 分散 PBL/B チームにおいて，そのロジェクト学習は学部 3 年生を対象とした必修科目

プロジェクト期間中にチケット数、着手済みチケッの PBL であり，2013 年度に学生 15 名が配属されてト数、作業終了/完了済みチケット数がどのように推行われたプロジェクトの中の計 5 つのサブプロジェ移したかを示すグラフである．プロジェクト期間をクトに関してデータ収集を行った．また，enPiT は通じた平均チケット着手率は 78.7%で最終着手率は文部科学省の情報技術人材育成のための実践教育ネッ93.7%，平均チケット完了率は 49.7%で最終完了率はトワーク形成事業を受けて全国 15 大学が中心となっ89.8%であった．チケットの記録上は未着手あるいはて開始した「分野・地域を超えた実践的情報教育協未完了の作業が残っていることになるが，多くのチ働ネットワーク」 [1] により，著者ら所属大学で他大ケットを作成したチームの中では着手率/完了率とも学の学生を含む大学院修士 1,2 年の学生を対象としてかなり高い方である．

実施したものであり，2013 年度の夏季の集中講義形

図 3 は enPiT ミニ PBL/A チームにおいて，その式で行われたミニ PBL4 プロジェクトと後期に行わプロジェクト期間中にチケット数、着手済みチケットれた分散 PBL2 プロジェクトのデータ収集を行った．

数、作業終了/完了済みチケット数がどのように推移

プロジェクト学習は対象者が学部 3 年生であるため，したかを示すグラフである．enPiT ミニ PBL は 5 日

参加メンバのほとんどは PBL 経験が少ないか初経験間の短期集中で行う PBL であり，週 1∼2 回集まってであるのに対し，enPiT の各 PBL は参加メンバの半数か月掛けて行う PBL とは日程的に大きく異なるが，分以上は 2 回目以降の PBL 参加であり，一部の学生チケット数の推移は通常の PBL と大きな違いは見受

は大学内での PBL に多数参加しており，PBL 経験けられない．プロジェクト期間を通じた平均チケットが豊富であった．

着手率は 85.7%で最終着手率は 92.4%，平均チケッ

これら 11 チームのプロジェクトは，いずれも Web

ト完了率は 58.7%で最終完了率は 74.7%であった．

アプリケーション開発を行っており，開発に際してこれら 2 チームを含めいくつかのチームは PBL 期

Web アプリケーション開発フレームワーク CakePHP

間が実質的に終わった後に，未着手だったチケットをを使用していた．また，プロジェクト管理ツール

着手に，未完了だったチケットを完了に変更していた．

として Redmine を，バージョン管理ツールとして

図 4 はプロジェクト学習本開発/Yagaigeki チーム

Subversion を用いた．従って，どの PBL についてもの種類別のチケット数推移を示すグラフである．使Redmine および Subversion に蓄積された情報を収集用していた Redmine サイトの設定により，チケットした．の種類 (トラッカー) は「タスク」「サポート」「機能」

なお，どのチームも共通して CakePHP フレーム「バグ」の 4 種類が利用可能であり，行うべき作業のワークを用いた Web アプリケーション開発を行って内容や目的によってチケットを分類して登録することおり，CakePHP フレームワークに元々含まれるソーが期待されていたが，このチームはプロジェクト期間スファイルが 1400 超あるため，どのチームもソースの初期および末期に作成したいくつかのチケット以外ファイルとしてバージョン管理していたファイル数がはすべて「サポート」になっており，チケットの種類

1400∼1800 程度となっている．

を適切に設定しなかったようである．これらの種類間のチケット数のバランスは開発対象や主に開発すべき内容，あるいは，プロジェクトのその時点の状況によって異なると考えられるが，このような極端な偏り

表1

情報収集した 4 種類の PBL

PBL 種類期間

学年

チーム数/学生数

プロジェクト学習 模擬開発

約 2 か月学部 3 年

3 チーム 5 名

プロジェクト学習 本開発

約半年

学部 3 年

2 チーム 5〜10 名

enPiT ミニ PBL

5 日間

修士 1,2 年

4 チーム 4〜5 名

enPiT 分散 PBL

約 4 か月修士 1,2 年

2 チーム 6〜8 名

表2

11 チームから収集したデータの概要

PBL 種類/チーム名

チケット

コミット

ファイル

期間

学年/学生数

数

数

数

プロジェクト学習模擬開発/A チーム

約 2 か月学部 3 年/5 名

25

208

1,645

プロジェクト学習模擬開発/B チーム

約 2 か月学部 3 年/5 名

17108

1,596

プロジェクト学習模擬開発/C チーム

約 2 か月学部 3 年/5 名

25

106

1,642

プロジェクト学習本開発/Event チーム

約半年

学部 3 年/10 名

240

526

1,578

プロジェクト学習本開発/Yagaigeki チーム

約半年

学部 3 年/5 名

152

121

1,813

enPiT ミニ PBL/A チーム

5 日間

修士 1,2 年/5 名

79231,473

enPiT ミニ PBL/B チーム

5 日間

修士 1,2 年/5 名

4745

1,479

enPiT ミニ PBL/C チーム

5 日間

修士 1,2 年/5 名

38327

1,487

enPiT ミニ PBL/D チーム

5 日間

修士 1,2 年/4 名

59

109

1,498

enPiT 分散 PBL/A チーム

約 4 か月修士 1,2 年/6 名

1347

1,552

enPiT 分散 PBL/B チーム

約 5 か月修士 1,2 年/8 名

127

196

1,827

はチケットの使用方法が不適切であるか，もしくはプ見ると，担当者未割当のチケットが 59 チケット中 16ロジェクトが特殊な事態になっている可能性が高い．

も残っているのは多いが，それ以外のチケットは 5 名のメンバ学生にほどよくばらついている．このチーム

4. 2 チケット作成者/担当者の偏りの 5 名のメンバ学生の担当チケット数の標準偏差は

図 5 は enPiT ミニ PBL/D チームの Redmine チ2.5 であり，担当チケットに関するばらつきはかなりケットの作成者別および担当者別のチケット数をグラ少ないと言える．

フ化したものである．凡例の 126 や 130 などの数値
はこのチームにメンバとして所属していた学生個々を4. 3 コミット回数推移区別するための ID であり，凡例の最後にある NULLそれぞれのプロジェクトの PBL 期間中の述べコミッはどの学生にも割り当てられていないことを示す．5

ト回数の推移を調べたところ，enPiT 分散 PBL/B日間の短期集中 PBL 中にこのチームが作成したチチームの推移は図 6 の通りであった．要求工程やヒケット数は 59 であり，作成者別で見ると上位 2 名のアリングを主に行っていた 10,11 月はコミットは少な

学生がそれぞれ 30 個，21 個のチケットを作成してく，開発が本格化した 12 月に急増，1/24 に行われた

いる．PBL においてチケット作成者が偏るのはよく発表会に向けて 1 月に段階的に増加している．2 月末ありがちであり，極端な場合，ほぼすべてのチケットにも学外での発表会に出展したため，2 月後半にも更を 1 人の学生が作成する場合もあるが，それ自体がにコミットしている．

PBL の進行上問題であるとは限らない．担当者別に一般的な PBL では週に 1∼2 回メンバが集まって

図4

図2

分散 PBL B チームのチケット数推移

図3

ミニ PBL A チームのチケット数推移

プロジェクト学習本開発 Yagaigeki チームの種類別チケット数推移

図5

enPiT ミニ PBL D チームの作成者/担当者別チケット数

図6

enPiT 分散 PBL B チームのコミット回数推移

ミーティングや作業を行うという形態が多いが，短期

4. 4 ファイル数/ソースコード行数の推移

集中形式で行われ，期間中ほとんどメンバが顔を合わ

各プロジェクトでバージョン管理していたソース

せていた PBL ではコミット回数の推移傾向は変わる

ファイル数およびソースコード行数の推移を調べたとだろうか．5 日間の短期集中で行われた enPiT ミニ

ころ，enPiT ミニ PBL/A,B,C,D チームのチーム別

PBL/C チームの述べコミット回数推移は図 7 の通りのコード行数推移は図 8 の通りであった．4 チームとである．5 か月近く掛けて行われた enPiT 分散 PBL

も CakePHP フレームワークを用いているため，元々のグラフ (図 6) と比べて，特段傾向が異なっているフレームワークに含まれるソースコード行数が相応わけではない．つまり，PBL 期間が長くても短くてにあること，また PBL 開始前に PBL 担当教員が各も述べコミット回数推移の大まかな傾向はあまり変わチーム用の Subversion リポジトリを用意し，そこにらないと考えられる．もちろん，総コミット数が極端

CakePHP を丸ごと入れておいたことなどからこのよに少ないなどのバージョン管理の利用が特殊なプロ

うなグラフになっている．なお，1 チームだけ不自然ジェクトの場合はこの限りではない．に行数が少ないのは担当教員の準備ミスと思われる．

図9

図7enPiT ミニ PBL C チームのコミット回数推移

図8enPiT ミニ PBL 4 チームのコード行数推移

enPiT ミニ PBL 4 チームのコード行数推移 (開始時からの相対)

図 10

enPiT 分散 PBL B チームの成果物ファイル数とコード行数推移

フレームワークを使うか使わないか，使うとしてどミングであった．のフレームワークを使うかなどは，個々の PBL ごとに異なり，ファイル数や行数の絶対値比較はあまり意

4. 5 コミット者の偏り味をなさないと考えられる．図 8 のグラフを PBL 開

バージョン管理システムへのコミット者が同じチー始時点からの相対的な行数でグラフ化したものが図ム内でどの程度偏っているかを調査した．図 11 は9 である．開始時点からの相対行数変化でみると，4enPiT 分散 PBL/B チームのコミット者別のコミット

チーム中 3 チームはほぼ同様の傾向であり，1 チーム回数グラフである．このチームはメンバが 8 名とやだけが途中で急激に増えていることが分かる．何が起や多く，役割分担や作業負荷が偏る可能性が高いと推こったのか実際にデータを確認したところ，行数が急測された．この結果を見ると，主要 4 メンバの間では激に増えたのはフレームワークに対して追加のアドかなりバランスが良く，その 4 メンバと残りの 4 メオンを導入したからであった．PBL の運用としてアンバの間ではかなり偏っていたということが分かる．

ドオンの導入に特に注意する必要があるというわけ

教員からのコントロールが少なく，学生側のスキル向ではないが，ファイル数や行数の急激な変化が見られ上意識が不十分な場合，システム開発 PBL においてれば，そのチームで何が起こっているか気を払う必要

実装を担当する学生が極端に偏ることがしばしばあはあると考えられる．

る．実装担当者が偏るとその学生だけがコミット回数図 10 は enPiT 分散 PBL/B チームがバージョン管が極端に多く，それ以外の学生がコミット回数が極め理していたファイル数と行数の推移グラフである．グて少なくなるのが通例である．実装を担当する学生がラフを見ると 11 月下旬にファイル数と行数が急激に偏ることを教師側が容認する場合には，即座に注意す増え，また 1 月にファイル数は若干，行数が急激にべき事態とはならないが，その場合でも全体的な作業増えている．11 月下旬は開発を本格化させるために負荷が偏り過ぎて，実装担当学生の PBL 以外の活動

CakePHP フレームワークそのものをバージョン管理にまで影響を及ぼす場合もあるため，相応の注意は必下においたタイミングであり，1 月はソースコード以要となる．

外のドキュメント類をバージョン管理下に含めたタイ図 11enPiT 分散 PBL B チームのコミット者別コミット回数

それらは PBL の題材や実施形態にはほとんど依存し5 過去と進行中の PBL のデータ可視化方法ないため，過去の PBL と現在進行中の PBL との偏

本節では収集した過去の PBL データと現在進行中りの程度を比較できるように可視化することで，どのの PBL データを，現在進行中の PBL 運用支援のた程度の偏りまで許容できるかを検討可能になると考めにどのように可視化するのかを述べる．

えられる．

本研究では本稿冒頭で述べたように題材や環境がデータ収集した過去の PBL の中でチームが崩壊状

異なる PBL に対しても運用支援することを目指して態になり，PBL 期間の後半はほぼ 1 人で活動していいる．4 節で述べてきたように今回データ収集した過たというチームがあった．チームが崩壊したかどうか

去の PBL は共通点もあるが実施形態など異なる面もはデータに直接現れないが，PBL 期間の長さの割に多い．実施形態が異なっても同じ傾向のデータが得らチケット数もコミット回数も少ないというデータ傾向れることも分かってきた．

を示していた．同様のことが起こる場合，チケットやプロジェクト期間は PBL によってかなり異なるが，コミットが少ないか，もしくは，一部のメンバ以外はプロジェクト期間に依らずチケット数の推移やコミッ担当チケットやコミットが極めて少ないなどの傾向がト回数の推移は大きく変わらなかった．チケット数が表れると想定される．

最終的に何個，コミット回数が最終的に何回程度にな

今回データ収集した過去の PBL はいずれも同じるのが妥当かは判断が難しいが，プロジェクト期間のWeb アプリケーション開発フレームワークを使って時間的な進行割合に対してチケット数やコミット回数おり，各チームの開発規模は大きく変わらなかったの平均的な増加傾向は分かるため，それを現在進行中と考えられるため，このデータを開発規模の異なるの PBL の開始してから終了予定時期までの割合と照PBL と比較して十分な運用支援になるかどうかは未らし合わせることで，それぞれの増加が少なめである実証である．しかし，開発規模が大きく変わらなかっか多めであるかを提示することが可能である．

たはずの各チームであるにも関わらずチケット数やコPBL を受講する学生は年々入れ替わっていくため，ミット回数は大きく異なっていることのほか，PBL参加するメンバのスキルも変わるが，収集した過去のとして教員が運用する性質上，開発規模が極端に変PBL のデータからはチーム単位でのスキルの差は明わることは多くないと考えられるため，運用支援上らかではなかった．チーム内でのスキル差や意識の差は PBL の開発規模を厳に捉えなくても良いと考えらはチケットやコミット回数の偏りとして表れており，れる．

理システムに関して結果的に Redmine と Subversion

6 PBL 運用支援の試みという組み合わせだけに対応することになった．チ

本稿執筆時点ではまだ開始していないが，収集しケット管理システムやバージョン管理システムには流た 2013 年度実施の 11 チーム分の PBL データを基に行り廃りがあるため，それぞれ複数のシステムに対応して，2014 年度に実施するいくつかの PBL においすることを目指したい．現時点では GitHub の Issueて，運用支援を想定したデータ可視化を行い，実際に機能や Git への対応が有望であるほか，過去の PBLPBL 運用の助けとなるか試みる予定である．実施対データをより多く収集・活用するために trac や CVS象となる PBL は，チケット管理やバージョン管理にへの対応も検討したい．

関してはデータ収集した 2013 年度の PBL と同様にまた，チケット管理やバージョン管理以外の PBL

Redmine と Subversion を使用予定であるが，2013に関するデータも運用支援につながるものがあり得

年度の 11 チームすべてで使用していた開発フレーム

る．議事録や週報などは有用な情報が含まれている可ワーク CakePHP を使用しないチームがほとんどに能性があるが，その形式がプロジェクトごとに全く異なる予定である．使用する開発フレームワークや開発なるなど，過去の PBL のものと現在進行中の PBL内容が大きく異なった場合に，支援できる度合いがどのものを対比して可視化するのは難しいと考えられう変わるかが今回の試みの注目点となる．

る．PBL に関するメールのやり取りや Skype での会話ログなども考えられる．従来であればチケット管理

7 考察やバージョン管理以外のやり取りはプロジェクト用の今回，Redmine や Subversion から収集可能であっメーリングリストなどを用いることが多かったが，昨たが収集対象としなかったデータがある．例えば

今の PBL において教員側が特に何かを強要しない場

Redmine では各チケットに見積り工数や作業実績が合は学生間で自然と Skype 等でのやり取りが行われ入力できるため，このデータに着目することで PBLている．参加学生承諾の下で Skype の会話を記録し，各チームの見積りの精度やその向上度合いを見るこ

過去の PBL のメーリングリストでのやり取りと対比とができるが，現時点では考慮していない．また，

して可視化することがプロジェクト運用支援になるか

Redmine のチケット作成者とチケット担当者についどうかも検討していきたい．て，作成者についてはチーム内で偏ることを容認し，担当者の偏りには注意するという方針で考えている

8 まとめと今後の課題

が，関連する別の情報としてチケットの変更者が誰

過去の PBL の開発履歴を活用し，それらと現在進だったかという情報もある．実際にデータ収集した

行中の PBL のプロジェクトデータと対比させて可視

PBL の中のあるチームでは，チケット担当者はチー化することで，そのプロジェクトの進捗の程度などをム内でそれなりにばらついているが，チケットを作成実務経験のない大学教員でも容易に確認できるようにするのも変更するのもほぼ一人が行っているというすることを目指し，2013 年度に著者ら所属大学で実状態であった．つまり，チケット担当者はチケットで施した PBL のチケット管理情報とバージョン管理情示される作業を実際にやっているがチケット管理シス報を 11 チーム分収集し，分析した．そして，それらテムには全く触らず，システム上のチケット操作はすを運用の支援となるように可視化する方法についてべて特定の学生に任せているという状態だった．プ

検討した．本年度の PBL において実際に過去のデーロジェクトとしてはそれでも進行するが，チケット駆タと進行中の PBL のデータを対比可視化して，PBL動開発としてはかなり特殊な状態であるため，チケッ運用支援を試みる予定である．また，データ収集範囲ト駆動であることを重視する場合には考慮した方がの再検討，他の PBL 関連システムへの対応，より多良い．

くの PBL 開発履歴の収集なども並行して行っていく

今回はチケット管理システムおよびバージョン管予定である．

参 考 文 献[1] enPiT 事務局: 分野・地域を越えた実践的情報教育協働ネットワーク (通称 enPiT), http://enpit.jp.
[2] 井垣宏, 柿元健, 佐伯幸郎, 福安直樹, 川口真司, 早瀬康裕, 崎山直洋, 井上克郎: 実践的ソフトウェア開発演習
支援のためのグループ間比較にもとづくプロセスモニタ
リング環境 (教育実践研究論文,< 特集 > 学習・教育支援のための技術開発), 日本教育工学会論文誌, Vol. 34,
No. 3(2010), pp. 289–298.
[3] 大平雅雄, 横森励士, 阪井誠, 岩村聡, 小野英治, 新海平, 横川智教: ソフトウェア開発プロジェクトのリアルタイム管理を目的とした支援システム (ソフトウェア開発環境・開発支援システム, < 特集 > システム開発論文), 電子情報通信学会論文誌. D-I, 情報・システム, I情報処理, Vol. 88, No. 2(2005), pp. 228–239.
[4] 福田晃, 鵜林尚靖, 荒木啓二郎, 峯恒憲, 日下部茂, 金子邦彦, 亀井靖高, 廣重法道: 情報工学系大学教員のための PBL 実践ガイド, 九州大学大学院システム情報科学府 情報知能工学専攻社会情報システム工学コース,2012.
[5] 柿元健, 井垣宏, 川口真司, 福安直樹, 佐伯幸郎, 早瀬康裕, 崎山直洋: 開発プロセスの観察とグループ間比較による実践的ソフトウェア開発演習の支援環境, 電子情報通信学会技術研究報告. SS, ソフトウェアサイエンス, Vol. 109, No. 456(2010), pp. 13–18.
[6] 横森励士, 市井誠, 新海平, 井上克郎: 開発履歴データのリアルタイム収集・分析システム EPM の拡張について: SRGM を用いた予測グラフの実現および既存解析システムとの連携, 電子情報通信学会技術研究報告.
SS, ソフトウェアサイエンス, Vol. 104, No. 722(2005),
pp. 1–6.
[7] 福安直樹, 佐伯幸郎, 水谷泰治: リポジトリのリアルタイムな可視化にもとづく PBL の支援環境: 継続的な実施を目的として, 電子情報通信学会技術研究報告.
SS, ソフトウェアサイエンス, Vol. 110, No. 458(2011),
pp. 121–126.