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

過去の PBL の情報を用いた工数見積り支援ツールの開発
齋藤 尊

新美 礼彦

伊藤 恵

企業におけるソフトウェア開発では，FP 法や COCOMO などの工数見積り手法が使われている．これらの手法では，機能の複雑さやエンジニアの技術などの補正係数を利用する．しかし，ソフトウェア開発 PBL(Project-BasedLearning) では，開発経験の浅い PBL 参加者がそれらを算出するのは難しいため，これらの手法を PBL で活用するのは困難である．そのため，PBL を対象とした工数の見積り方法が求められている．一方 PBL では，そのプロジェクト活動中に様々なデータを蓄積することができる．しかし，既に終了したプロジェクトも含め，それらのデータが十分に活用されていない．そこで本研究では，過去および進行中の PBL で蓄積されたデータを利用して，各成果物作成の工数見積りを行うツールを提案する．本ツールを進行中の PBL に適用することで，PBL に参加している学生たちが正確に作業見積りができるようになることが期待される．

Man-hour estimate technique such as Function Point method or COCOMO(constructive cost model) is
generally used in software development companies. It need some correction coeﬃcients. But, in softwaredevelopment PBL(Project-Based Learning), it is diﬃcult that PBL participants who do not have so muchsoftware development experience use these estimate technique because they may not have enough skills forcalculating these coeﬃcients. On the other hand, we can accumulate various data in PBL. However, thesedata have not been inflected fully. So, in this paper, we propose a man-hour estimation tool for making
deliverables which uses some data accumulated from already ended and on-going PBL. It is expected that
if on-going PBL participants use this tool, they will become to be able to estimate a workload correctly.

ジェクトとは異なり，プロジェクトメンバはソフト

1 はじめにウェア開発を学習しながら，ソフトウェア開発に参

近年，ソフトウェア開発教育において，Project-加する．そのため，十分なソフトウェア開発技術をBased Learning(PBL) と呼ばれる実践型教育手法が持たないままソフトウェア開発を行っている可能性注目を集めている．PBL は通常の講義形式の教育でが高い．それに伴い，ソフトウェア開発で発生し得はなく，学習者同士が数人から十数人のグループを作るリスクが顕在化しやすいと考えられる．この顕在り，プロジェクトを通して問題発見・解決を経験させ化しやすいと考えられるリスクのうちの一つに見積る教育法である．特にソフトウェア開発 PBL の場合，りの甘さによる納期遅れが挙げられる．ソフトウェ

コーディングやテストなどの下流工程だけでなく，要ア開発における見積りの手法としてファンクション

件定義や内部設計などのソフトウェア開発の上流工程

ポイント法 (FP 法) を代表とする規模見積もり，やを経験することで，学習者はより実践的なソフトウェ

COCOMO(constructive cost model) などの工数見ア開発技術を学習することが期待できる．

積り手法があるが，工数を見積るためにはまず規模

しかし，PBL は企業が行うソフトウェア開発プロ見積もりを行わなければならない．しかし，規模見積もり手法である FP 法では，ファンクションポイント

Development of a Man-hour Estimation Tool which
Uses the Past PBL Data.
Takeru Saito
Ayahiko NiimiKei Ito, 公立はこだて未来大学, Future University Hakodate.

を算出するためには，開発するソフトウェアのデータ
ファンクションとトランザクショナルファンクションの計測が必要である．この二つのファンクションポイ

ントは計算者によってその分類の仕方が変わるため，模を見積る手法として，FP 法が一般的に利用されて学習者が安定して計測するまで慣れと経験が必要でいる．FP 法は，対象となるソフトウェアプロジェクある．

トの入力，出力，照会，内部論理ファイル、外部イン

また，ソフトウェア開発 PBL を行っている大学等

ターフェースファイルの 5 つの外部属性に注目し，計の教育機関では，開発したソフトウェア以外にも，要測したファンクションポイントをそれぞれの複雑度ご件定義書や仕様書等のドキュメントや会議毎に書かとに重み付けを行う [3]．このファンクションポインれた議事録等，様々なデータが過去に行われた PBL

トの集計を利用することで，ソースコードの規模だけで蓄積されている．開発の際に Redmine などのプロでなく，文書やバグの規模見積もりも可能となる．

ジェクト管理ツールや Subversion などのバージョン

しかし，ソフトウェア開発プロジェクトには，開発管理システムを利用していた場合，参加者ごとの詳細環境やプロジェクトメンバーの習熟度などが生産性をな活動履歴を得ることができる．だが，現在これらの変動させる要因となるため，開発工数の見積りの際にデータは蓄積されているばかりで十分に利用されてはファンクションポイントだけでは見積りが難しい．

いない．

そのため開発工数を導出するためには，ソフトウェア

そこで本研究では，これらの十分に活用されていなの規模だけでなく，それらの生産性要因を説明変数とい過去の PBL から得られるデータを利用した，工数しなければならない．この説明変数に利用する生産性見積りツールの開発を行う．

要因を決定する方法は，相関係数を利用する方法などがあるが，天嵜 [4] は 5 つの変数選択手法の比較を2 関連研究行っている．その結果として，対象となるデータサイ

2. 1 PBL の支援環境開発

ズが極端に小さくない限り，ステップワイズ法が最もソフトウェア開発 PBL を支援する試みとして，福妥当であることが示された．また，生産性要因が定性

安ら [1] は作業リポジトリのガントチャート出力を利的または定量的に記録されていない場合，その生産性用したグループ並行型 PBL を提案している．この研要因を見積りに利用できない．角田ら [5] はこの問題

究では，PBL 活動日での活動には Web アプリケー

に対し，プロジェクトマネージャが生産性要因の生産ションによるガントチャート表示，非活動日には活発性レベルを荒い粒度で推測し，それを説明変数とするに活動が行われている時間帯を中心にガントチャートことを提案している．

表示を行った．また，明石ら [2] はレビューと改善作業に重点をおいた PBL のコース管理システム Collasys

そして，これらの説明変数を利用する工数の見積り手法は大きく分けて以下の 6 つがある [6]．

を開発した．Collasys は成果物のレビュー項目ごと• 類推法に掲示板を作成し，この掲示板上で作成担当者とレ• 専門家による判断ビュアーが修正方針に関して議論しながら，修正を行• トップダウン見積りうことができる．これらの PBL 支援システムでは，• ボトムアップ見積り

プロセスモニタリングや相互評価によって PBL の支• パラメトリック法

援を行っているが，プロジェクトの見積りという観点• プライスツーウィンからの支援システムは確認されていない．

類推法とは見積り対象プロジェクトと類似した過去のプロジェクトの実績を基に見積りを行う手法で

2. 2 工数見積り手法ある．まず全体の工数を見積ってから，各作業に分配

ソフトウェア開発の工数見積りを行う際，まず対象するのがトップダウン見積り，逆に成果物の構成要素となるプロジェクトの規模の見積りを行う．これは，ごとに工数を見積り，その結果を積み上げるのがボト開発規模と開発工数が比例していると言う仮定を元ムアップ見積りである．パラメトリック法は工数をにしているためである．このソフトウェア開発の規目的変数とし，プロジェクトの工数の変動要因とな3. 2. 1 Subversion
Subversion とは，ソフトウェアのソースコードなどをのファイルの管理を行う集中型バージョン管理システムである．このシステムはサーバ上にバージョン管理を行うファイルを格納するリポジトリを用意することで，複数人が最新バージョンをサーバからコピーすることができ，前バージョンへの復元も容易にできる．本研究では，この Subversion のコミットログを利用データの一つとする．
図1

システムの入出力

この Subverison のコミットログの中から，以下の6 種類のデータが獲得できる．
る要素を説明変数と設定し，数学的な手法で工数を• リビジョン番号見積る手法である．パラメトリック法に属する代表• コミットしたユーザ名的な見積り手法に，COCOMO や CoBRA 法がある

• コミット日時[6]．COCOMO は回帰分析を利用したプログラム言• 該当リビジョンで追加や変更があったパス語の難度に左右されない手法で，COBRA 法は熟練

• 変更の種類者の経験とソフトウェア開発データを利用し工数を見• コミットメッセージ積る手法である．また，プライスツーウィンは顧客予

リビジョン番号とはコミット毎に増加する，ソース算を基に見積りを行う手法だが，見積もり手法としてコードやドキュメントの細かい変更を表す改訂番号はふさわしくないとされている．のことである．また，該当リビジョンで追加や変更があったパスが，そのリビジョンにおける追加および編

3 アプローチ集を行った成果物と等しい．一度のコミットで複数の3. 1 見積りの流れファイルやディレクトリが変更されることがあるた

本研究では，過去に実施されたソフトウェア開発

め，この変更があったパスはコミット一件につき複数

PBL で蓄積されたデータより，開発環境やプロジェ個取得できる．変更の種類というデータは，それぞれクトメンバの習熟度などの目的変数を抽出し，見積ものパスが追加，変更或いは削除のいずれかの操作を受りのためのデータセットとして利用する．ここで，本けたかを AMDR のアルファベット一文字で表現した研究で制作する見積り支援システムの入出力構成をものである．コミットメッセージとは，コミット者が図 1 に示す．図 1 の通り本システムでは，進行中のソコミットを行う際に付加する，作業内容の説明文章でフトウェア開発 PBL のデータと見積りしたい成果物ある．このコミットメッセージだけは，コミット者が名を入力する．そしてそれらのデータと，システム内任意で記述を行うため，他のデータと異なり欠損が存に蓄積した過去に実施されたソフトウェア開発 PBL在する．のデータから予測規模と予測工数を割り出し，出力3. 2. 2 Redmine

する．

Redmine とは，タスク管理や進捗管理が行えるプロジェクト管理システムの一つである．Redmine は

3. 2 利用データ

チケットと呼ばれる各タスクのデータを登録，編集す本研究では，過去の PBL で蓄積したデータを，バーることで，タスクの進捗管理を行う．また，文章の保ジョン管理システムである Subversion とプロジェク

存や掲示板の作成ができるため，PBL ではこの機能

ト管理システムの Redmine から取得する．

を利用して会議の議事録を保存，共有している．そこで本研究では，Redmine に蓄積された過去のプロジェクト情報を，登録チケットおよび議事録から抽出• 作成担当者をする．

Redmine のチケットから獲得できるデータは以下

3. 3 見積り手法の 16 種類である．

PBL では一般的にメンバの増員を想定していない• チケット番号

ため，納期までに作業を間に合わせるためには，開発• プロジェクト名するシステムのスコープかドキュメント等の成果物• トラッカー (チケットの種類)の作成予定を調整するのが一般的である．そのため，• チケット名各成果物ごとの開発工数を見積ることができれば，成• 親チケット名

果物作成予定の調整に役立つと考えられる．よって本• ステータス研究では，ボトムアップ見積りによって各成果物ごと• 優先度の開発工数を見積るのシステムを開発する．

• 作成者
• 担当者

4 収集データ• 作成日

本研究では，以下のようなデータを情報系大学のソ• 更新日

フトウェア開発講義で過去に行われた PBL から入手

• 開始日する事ができた．

• 期日• 対象バージョン

4. 1 収集できたプロジェクト• 進捗％

本研究において A，B，C，D，E，F，G，H，I，J，• 作業時間の記録

K の 11 プロジェクトからデータを収集することがでこのデータの中で，トラッカーとはチケットの作業きた．

内容の分類を示し，バグ，機能，サポート，タスクのこれらプロジェクトの開発期間とメンバ数，およびいずれかが格納される．また，チケットには既に作成参加学年とそのプロジェクトの開発種別を表 1 に示されたチケットを細分化して，詳細なタスクとしてす．この 11 プロジェクトのうち，A から E までの 5新たにチケット登録をすることがある．そのとき細プロジェクトが学部 3 年生，F から K までの 6 プロ分化したチケットに，元となったチケットを親チケッジェクトが大学院 1，2 年生が参加した．表 1 の開発

トとして登録をする．チケットの進捗状況を表す要素

種別とは，開発するソフトウェアが新規に開発されたとして，ステータスがある．ステータスには着手，進ものなのか，既存のものを拡張あるいは再開発した行中，完了などが入力される．対象バージョンとは，ものなのかを示しており，プロジェクト D，J 以外はそのチケットによる修正がどのバージョンに取り込ま全て新規開発である．また，F から I までのプロジェれるかが入力されたデータである．しかし，管理者がクトの開発期間が 0.16ヶ月となっているが，これは 5該当するバージョンを Redmine に設定していない場日間のみの活動であったことを示している．

合，このデータは欠損する．
また議事録からは，以下のデータが収集し，利用する．

4. 2 Subversion のコミットログ
Subversion のログデータは，全てのプロジェクト• 会議の日時データから取得できた． 各プロジェクトの取得リビ• 会議場所

ジョン情報を表 2 に示す．A，B，C，D，E の 5 プ• 参加メンバ

ロジェクトの Subversion リポジトリは，主にソース• 会議内容コード以外の UML 図や要件定義書などのドキュメ• 次回の活動予定ントを管理している．ただし，D，E に関しては，ド表1

データ収集したプロジェクト一覧

プロジェクトAB

CD

EF

GHIJK

開発期間 (月)

2

2

2

8

8

0.16

0.16

0.16

0.16

44

メンバ数 (人)

55

5

5

10

5

55

578

参加学年

333

3

M1,2

M1,2

M1,2

M1,2

M1,2

M1,2

M1,2

開発種別

新規新規

新規再開発

新規

新規

新規

新規

新規

機能拡張

新規

表2

プロジェクトごとの取得リビジョン情報

プロジェクト

A

B

C

DE

FG

H

I

JK

取得リビジョン数

64 件

27 件

69 件

479 件

467 件

23 件

45 件

327 件

109 件

47 件

196 件

一月あたりのリビジョン数

32 件

13.5 件34.5 件59.9 件58.4 件143.8 件262.5 件

2043.8 件

681.3 件11.8 件

49 件

ソースコード
有無

なし

なし

なし

あり

ありありありありありありあり

ドキュメント
有無ありありありあり

あり

なし

なし

なし

なし

あり

あり

コミットメッセージ欠損率

65.6%

48.2%

10.1%

54.7%

9%

56.5%

64.4%

82.6%

91.7%

70.2%

35.7%

キュメントだけでなく開発したシステムのソースコー

4. 3 Redmine のチケットドを管理している Subversion フォルダから，ソース11 プロジェクトそれぞれから得られた Redmine のコードのリビジョン情報を取得できた．また，F，G，チケット総数と開発期間あたりのチケット数を表 4 に

H，I，J，K の６プロジェクトはほぼソースコードの示す．表 4 より，チケット総数は開発期間とやや比例みを管理していたため，ソースコードのリビジョン情しているが，プロジェクトによって発行数の差が大き

報を Subversion からデータを取得した．

い．また，開発期間の短い F から I までのプロジェク

表 3 はプロジェクト D の報告書作成開始時と作成

トは短期間で集中してチケット発行を行ったため，開終了時のログデータである．この表を見ると，作成開発期間あたりのチケット数が増加したと考えられる．

始時点では報告書作成のためのディレクトリや編集す

表 5 はプロジェクト D のグループ報告書作成を示るファイルの作成を行っており，終了時には報告書をすチケットデータである．この表を見ると，報告書作PDF ファイルとして生成していることが分かる．

成が急いで行わなければならなく，また開始日と期日

これらの Subversion のコミットログからは，各成果物の作成を行った人物と，初回コミットから最終コから 10 日間を必要な作成期間であると見積ったことがわかる．

ミットまでの期間を抽出することができる．それによ

この Redmine のチケットからは，実際に行われた

り，過去の PBL から各成果物の作成に必要となった具体的なアクティビティとその担当者のデータが獲人日を推定することができると考えられる．特に，プ得できる．また，そしてプロジェクト中での対象アクロジェクト A，B，C，D，E からはソースコード以ティビティの重要度も収集できるため，この PBL が外のドキュメントの作成工数が抽出できる．

どのような点に気を配っていたかを知ることができる．それによって，対象プロジェクトの特性が判断できると考えられる．Redmine ではチケットに記したタスクの開始日と期日から，その PBL での見積り工表3

グループ報告書の Subversion ログデータの例

リビジョン番号r1175

r1891

コミットしたユーザ名abコミット日時

2013-12-17 13:18:32 +0900(2013 年 12 月 17 日 (火))2014-01-15 16:32:54 +0900(2014 年 01 月 15 日 (水))A/final report/D GroupA /final report/D Group/midterm group ver0.2.tex
他

M /final report/D Group/midterm/8.tex
M /final report/D Group/midterm group ver0.2.pdf
他

該当リビジョンで追加や変更があったパス変更の種類

最終報告書のテンプレート (中間報告書のコピー)

コミットメッセージをコミットしました。

表4

プロジェクトごとの取得チケット情報

プロジェクトA

B

C

DE

FG

H

I

JK

取得チケット数

25 件

17 件

25 件

160 件

240 件

48 件

22 件

10 件

45 件

4件

44 件

一月あたりのチケット数

5件

3.4 件

5件

20 件

30 件

300 件

137.5 件62.5 件

281.3 件

1件

11 件

表5

グループ報告書のチケットデータの例と更新日の差だけから，実際に掛かった工数を抽出するのは難しいと考えられる．実際の工数を抽出する

チケット番号

1067

プロジェクト名

D

トラッカー

サポート

チケット名

グループ報告書の作成を行う

親チケット名最終報告書の作成を行う

ステータス

完了

優先度

急いで作成者

c

いる議事録数が多くなっていることが分かる．プロ

担当者

cジェクト F と H からは議事録を収集できなかったが，作成日

2013/12/18 18:49

その他のプロジェクトでは定期的に議事録が作成され更新日

2014/01/20 13:35ていると考えられる．

開始日

2013/12/18

議事録から得られたデータのうち，日時と場所，そ期日

2013/12/28

して参加メンバの情報はどの議事録でも，まず間違い対象バージョン

D班なく獲得できた．しかし，次回の活動予定と作成担当

進捗％

100

者に関するデータは欠損が見られた．議事録のフォー

作業時間の記録

0マットは各プロジェクトごとに定義されており，学内場合には，チケットの開始日と前述の SVN の最終コミットの日付から割り出す必要がある．

4. 4 議事録
議事録は，Redmine の文書機能やフォーラム機能を用いて記録されたものが取得できた．表 6 より，議事録は開発期間が長いほど，Redmine に登録されてで統一されたフォーマットがないため，作成担当者や数も抽出できる．しかし，更新日が同一のチケットが活動予定を記入しないプロジェクトもあることが分複数あることから，すでに完了した複数のタスクを一かった．また，会議内容はプロジェクトの進捗状況に括して更新していることが窺える．そのため，開始日より記述される内容が異なり，特に要件定義や設計の表6

プロジェクトごとの取得議事録数

プロジェクトAB

CDE

FG

HI

JK

取得議事録数

13 件

13 件

13 件

50 件

61 件

0件

2件

0件

2件

5件

24 件

一月あたりの議事録数

6.5 件

6.5 件

6.5 件6.3 件

7.6 件

0件

12.5 件0件

12.5 件

1.3 件

6件

段階ではパラメトリック法で利用できるメトリクスをであると思われる．

獲得できた．たが，議事録ごとに大幅に粒度が異なっ

4. 2 節と 4. 3 節，および 4. 4 節で得たデータより，ており，会議の際に上がった意見等を詳細に書き記し各成果物の推定作業工数を表 8 に表す．表 8 は各成たものから，当日に行った活動のみを記述するのみに果物の作成工数を人日で表している．表中に小数点とどまる場合もあった．

以下の人日を取る工数は，作業が 1 日の間に完了し

表 7 はプロジェクト D がグループ報告書を作成したものを示している．また該当成果物を作成していている期間中の議事録の一部である．この表からは，なかったり，作業期間のデータが欠損しているものは詳細な活動の内容と報告書の作成担当にどのメンバ

N/A と表記している．この表 8 と表 1 を照らし合わが割り当たっているのかが分かる．

せると，プロジェクト全体の開発期間とソースコード

この議事録から得られるデータには，PBL の開発の作成工数は必ずしも比例しないことが分かる．これ

体制や作成ソフトウェアが新規開発か否か，報告会なは，ソースコード以外の成果物をどれだけ作るかにど納期の目安となる日程など，PBL の対象となるソ

よって，開発期間をコーディング作業が占める割合がフトウェア開発プロジェクトの基本的な性質を示すも変わるためであると考えられる．のが多い．そのため，これらのデータは見積りを行う

また，表 8 の画面遷移図に関して，プロジェクト Bに当たって，全ての成果物に関わる基本的なメトリク

では 69 人日で開発されたが，同じ開発期間で実施さスとして利用できる可能性がある．

れたプロジェクト A および C ではそれぞれ 10 人日，5 人日と計測できた．ここで，表 2 と表 4 を見ると，5 見積り実験

プロジェクト B はプロジェクト A，C に比べて取得

4 章で得られたデータより，プロジェクトの規模とリビジョン数，取得チケット数が少ないことが分か

工数の見積りを行う．工数見積りを行う上で必要とさる．そのため，画面遷移図作成の際には Subversionれる，開発環境等の工数の変動要因の多くは議事録かのコミット頻度と Redmine のチケット登録数が工数ら得られることが分かった．また，Subversion のロに影響する可能性があることが示唆された．

グと Redmine のチケットを照らし合わせることで，予測工数と実際の工数を獲得できる．この過去に行っ6 提案システムの構成た成果物作成の工数と，工数の変動要因を元に各成果5 節より，本システムでは以下のような処理によっ物の作成工数を目的変数とする数学的な関数を導きて工数見積りを実現する．

だせると考えられる．類似法を用いて成果物作成の見1. システム利用者から進行中のプロジェクトのメ積りを行うことも可能であるが，これを行うためにはンバ数や開発種別などのプロジェクトの基本情報より多くの PBL データが必要となる．現状では類似と，見積り対象とする成果物名の入力を受ける．

法による成果物作成の工数見積りが十分に行えるほ

2. システム利用者から Subversion のコミットロ

どの PBL データが揃っていない．そのため，本研究グおよび Redmine のチケット情報を受け取る．

では一成果物の工数見積りは類似法ではなく，パラメ

3. 入力情報を元に開発規模の見積り値を算出する．

トリック法による工数見積り関数の作成と利用が妥当

4. 過去の PBL データを元に見積り対象成果物の表7

グループ報告書に関する議事録の例

会議の日時

2013/12/18 4,5 限

会議場所

484 室

参加メンバ

b，c，d，e，f
グループ別作業
報告書班 (c，d，e):イベント版図の意見あわせ, 目次, 担当割り決定(担当割りはレポジトリの表で確認できる)

会議内容
次回の活動予定

報告書班:金曜日 2 限に集めて進捗具合確認と今後の予定確認

作成担当者

d表8

成果物

各プロジェクトにおける成果物ごとの推定実績工数 (人日)

要件定義書

ユースケース記述

画面遷移図

ER 図

ソースコード発表用スライド

報告書

A8955

100.09215

133

210

B

7063

69

28

140

133

210

C

6444

572140

133

210

D

155

112

72

90

410

63

125

E

N/A

N/A

1031660

126

370

F

N/A

N/A

N/A

0.04

100.17

N/A

G

N/A

N/A

0.01

N/A

101

N/A

H

N/A

N/A

N/A

N/A

101

N/A

I

N/A

N/A

0.16

N/A

81

N/A

J

49

N/A

N/A

N/A

392

N/A

N/A

K

14

N/A

N/A

N/A

704

N/A

N/A

調整係数を作成する．

5. 利用する工数見積り関数にシステム利用者から取得したデータと調整係数を代入し，対象成果物

7 まとめと今後の課題
本研究ではソフトウェア開発 PBL を支援するため，過去の PBL で蓄積されたデータを利用した成果物ごの見積り工数を算出する．

6. 算出した見積り規模と見積り規模を出力する．との工数見積りツールを提案する．このツール制作の仮に工数見積り手法として CoBRA 法を利用する

ため，現在取得できるデータの検証を行った．その結果，11 のソフトウェア開発 PBL から 7 種類の開発

場合，手順 5 では以下の式を利用する．

Eﬀort = αSize(1 +∑

成果物の開発工数を抽出することができた．

COi )

(1)

今後は取得できたデータを元に，各成果物に対する適切な規模および工数見積り法の検討が必要である．

この式 1 の Eﬀort が工数を表し，Size が見積り規模

特にソフトウェア開発 PBL ではプロジェクトメンバを表す．ここで，式 1 の α および COi が手順 4 で算ごとに開発スキルが大きく異なる可能性があるため，出する調整係数となる．

その差異にも対応できる必要がある．この個人の開発スキルに関するデータが取得可能か否か，入手できな

い場合にメンバの学年が利用できるかどうかの検討も必要となる．
参 考 文 献[ 1 ] 福安直樹, 佐伯幸郎, 水谷泰治：リポジトリのリア
ルタイムな可視化にもとづく PBL の支援環境： 継続的な実施を目的として, 電子情報通信学会技術研究報
告. SS, ソフトウェアサイエンス, Vol. 110, 458(2011),
pp. 1–6．
[ 2 ] 明石敬, 松澤芳昭, 大岩元：Project-Based Learning を支援するコース管理システム, 情報処理学会研究報告. コンピュータと教育研究会報告, Vol. 2007,
No, 12(2007), pp. 15–22．
[ 3 ] Copers Jones(1998)：Estimating Software Costs,
McGraw-Hill Osborne Media, (富野壽 (訳) (2001),
ソフトウェア見積りのすべて：規模・品質・工数・後期の予測法, 共立出版)．
[ 4 ] 天嵜聡介：工数見積もり手法における変数選択手法の比較, 情報処理学会研究報告. ソフトウェア工学研究会報告, Vol. 2006, No. 125(2006), pp. 1–8．
[ 5 ] 角田雅照, 門田暁人, ジャッキー キョン, 松本健一：
熟練者判断を取り入れたソフトウェア開発工数見積り
モデル, 情報処理学会論文誌, Vol. 55, No. 2(2014),
pp. 994–1004．
[ 6 ] IPA 独立行政法人 情報処理推進機構：エンタプライ
ズ系事業/見積もり手法, http://www.ipa.go.jp/sec/
softwareengineering/std/ent01-c.html, (2014/07/15
アクセス)．