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

模擬案件と実案件を組み合わせたシステム構築 PBL カリキュラムの開発
伊藤 恵

木塚 あゆみ奥野 拓

大場 みち子システム構築を主とした PBL(Project Based Learning) には，よく作りこまれた教材を用いるが実システムや実在の依頼者に依らない模擬開発を行うものと，教育としての制御は難しいが実際の依頼者のために実際に使われるシステムを構築する実開発を行うものがある．著者らの所属大学において過去に行ってきた両方の PBL の成果を踏まえ，実践的 IT 教育のための両方を組み合わせた PBL カリキュラムを開発したので，ここに報告する．

There are two types of project based learning(PBL) for system development. One has no real customers
but uses well-defined education material to develop simulated systems. The other develops systems to beused by real customers, although it is diﬃcult to control diﬃculty or quality of the education. Based on ourexperiences on past PBLs in our university, we develop a PBL curriculum combining both types of PBL for
practical IT education. This paper reports its curriculum and trial operation.

は保ちやすいが，教育としての難易度調整などが難し

1 はじめにく，PBL 期間中に全く完成の目途が立たずに学習と

実 践 的 な IT 技 術 者 育 成 の た め に 様々な 高 等 教して消化不良になる場合もある．

育 機 関 で シ ス テ ム 構 築 を 主 と し た Project Based

そこで我々は所属大学での過去の PBL 事例に基づLearning(以下 PBL) を用いた教育が行われている

き，両種類を混合することにより，学習意欲を保ちな[6] [5] [4] [2]．

がら，一定の難易度制御が可能な PBL カリキュラム

システム構築を主とした PBL を構築題材の種類でを開発したので，ここに報告する．

分類すると，実際には使われない模擬システムの開発を行うものと，実在の依頼者や利用者に向けて実際に2 関連研究使われることを想定した実システム開発を行うもの

2. 1 模擬システム開発演習教材 ABS および NSPがある [3]．前者は，よく作り込まれた教材を利用す

よく作り込まれた模擬システム開発演習教材としれば，PBL 自体の難易度などの制御がし易く，PBLて，2002 年度に経済産業省「高度 IT 人材育成シスの実施期間や参加人数などに応じた柔軟な対応が可

テム開発事業」に採択された「実践型グループ学生能である一方，構築するシステムが実際に使われるこ教育コースの開発及び実施評価」において構築されとのないシステムであることから学習意欲の低下をた ABS [9] や，総務省「最先端ネットワーク技術を活招きやすい．後者は，うまく構築できれば実際に使わ用した遠隔教育システムの開発・実証事業」においれる可能性のあるシステムであることから学習意欲て PBL 教材として採用された NSP がある [7]．これDeveloping PBL Curriculum for System Construction
by Combining Simulated And Real Development
Kei Ito, Ayumi Kizuka, Taku Okuno, Michiko Oba,
公 立 は こ だ て 未 来 大 学 シ ス テ ム 情 報 科 学 部, Dept.
of Systems Information Science, Future University
Hakodate.

らの教材は開発及び運用環境として Java，Tomcat,PostgreSQL 等を想定したもので，既存システムおよびその仕様書一式と開発依頼書を与えられ，これらに基づいてチーム開発を進めていくものである．これらの教材には，途中で依頼者役が仕様変更を要求する場面なども用意されており，模擬的な開発ではあるもの

度の PBL において模擬システム開発を行った．このの現実的な開発の局面をできるだけ再現できるようにプロジェクトへの配属を希望した学部 3 年生 24 名を作り込まれている．また，NSP では教師が模擬シス4 チームに分け，連名でプロジェクトのテーマ提案をテム開発を運用するためのガイド用ドキュメント等も行った 4 名の教員を仮想顧客役として模擬開発を行っ充実しており，よく作り込まれた教材となっている．

た．年度の前半は主に参加学生個人個人の基礎技術習得を行い，グループ単位の模擬開発は主に年度後半に

2. 2 分野・地域を超えた実践的情報教育協働ネッ
トワーク enPiT行った．模擬システム開発教材には要求分析，設計，実装，テストなどの工程が含まれており，仕様書の完

文部科学省の情報技術人材育成のための実践教育

成度を高めてから初めて実装に取り組むという進め方

ネットワーク形成事業による補助金助成を受けて，に対して，そういった経験のない参加学生には戸惑い

2012 年度から「分野・地域を超えた実践的情報教育も多く見られた．また，作っているものがあくまで模協働ネットワーク (通称 enPiT)」が実施されている擬的なものであることから，同年度の PBL において[1]．enPiT ではクラウドコンピューティング，セキュ他プロジェクトで作られていた模擬的でないシステムリティ，組込みシステム，ビジネスアプリケーションの方が魅力的に見えるなどといった場面もあったが，の 4 分野において，全国さまざまな大学で行われて参加学生たちも最終的にはシステム開発プロセスをいる実践的情報教育を連携させ，短期集中合宿と分一通り体験することと，それを通じてスキルアップを散 PBL を組み合わせた教育プログラムの開発と運用することの重要性を感じることができたと報告してを行っている．本稿で報告する教育カリキュラムは，いる．

この事業のうちのビジネスアプリケーション分野向けのものである．

2007 年度から当大学に開設された実践的 IT 人材育成講座においても，講座立ち上げ時の約半年間，同じ教材を使用した模擬システム開発を行った．この講

3 PBL 事例紹介

座には学部 3 年生から大学院修士 2 年生までの希望

著者らの所属大学では 2002 年度以降，学部 3 年次者が参加し，授業単位の取得を伴わない課外活動での通年の必修科目「システム情報科学実習」においあった．この事例では参加学生たちのスキルアップ意て，毎年度約 250 名の 3 年生が 20 程度のプロジェク

欲を十分に持続させることができず，最終的には発表

トに分かれて PBL を行っている．プロジェクトは毎会に間に合わせるために動くものを作るということ

年度教員チームによるテーマ提案，学生の参加希望にを目的とした活動となってしまった．

基づく配属，プロジェクト実施をしており，システム構築を伴うプロジェクトもそうでないプロジェクトも

3. 2 実開発事例ある．過去に実施されたプロジェクトの中には模擬シ

3 年次必修科目「システム情報科学実習」においてステム開発を行ったもの，実システム開発を行ったもも，前節で述べた実践的 IT 人材育成講座においても，の，その両方を行ったものがあり，次節以降でそれら実際に使われることを想定した実システム開発は多の事例紹介を行う．

く行われている．中でも 2008 年度の実践的 IT 人材育成講座内のプロジェクトで行った観光情報サイト構3. 1 模擬開発事例

築は，地元公共団体からの依頼に基づくものであり，2002 年度に経済産業省「高度 IT 人材育成システ構築後の同サイトを受託運営する民間企業と協議をム開発事業」に採択された「実践型グループ学生教育重ねながら構築した．参加した学生は学部 3 年生かコースの開発及び実施評価」において，実装技術のスら大学院修士 2 年生までの計 21 名であった．地元公

キルアップのための e-learning 教材と模擬システム

共団体から大学への受託研究としてサイト構築依頼

開発教材が開発された [9] ことを受けて，翌 2003 年があり，同年 12 月のサイトオープンまでに必ず構築を完了することが求められたため，教師側からの難易(5) システム開発 (1.5 時間 ×12 回想定)度調整等は事実上不可能であった．地元公共団体の公ガイダンスから模擬開発までは練習フェーズ，それ式のサイトとして実際に使われることが明らかであっより後は本開発フェーズの扱いである．模擬開発ではたことや，受託研究予算の一部が学生への謝礼として依頼者役が必要となり，PBL の担当教師でない者が支払われたこともあり，参加学生の構築意欲は当初非依頼者役となるのが望ましいが，担当教師がなっても常に高かったが，地元公共団体や運営業者からの要求よい．ただし，依頼者役としての発言と PBL 担当教難易度が極めて高く，逆に意欲喪失して参加を辞めた師としての発言を明確に区別する必要がある．もし学生も居た．しかし，最終的にはサイトオープンまでも複数チーム体制で PBL を行う場合にはチームごとに構築を終え，この活動に関して参加学生チームが大に別々の依頼者役がいる方が望ましい．要求開発以降学内で表彰されるに至った．

では実システム開発を行うため，原則として依頼者が居る必要がある．題材によっては明示的な依頼に基

3. 3 模擬開発と実開発の組み合わせ事例

づかずに，想定されるユーザの役に立つシステムを

1 回の PBL の中で模擬システム開発と実システ開発するということもあり得る．その場合であってもム開発を組み合わせた事例もあった．2006 年度から

PBL に参加する開発メンバとは異なる視点でユーザ2008 年度までの「システム情報科学実習」において，の意見を代表できる依頼者役が必要である．

年度前半には主に技術習得を目的として 3. 1 節の事
例紹介で述べた教材を一部簡略化したものを用いたカリキュラムの各項目で行う具体的な内容について以下で説明する．

模擬システム開発を行い，年度後半には地域の団体等

4. 1. 1 ガイダンスを依頼者として実システム開発を行った．この方式でPBL 全体の目的や運用方針の説明のほか，大まか開発したシステムのいくつかは，開発の翌年度に実なプロジェクト計画の説明，プロジェクト管理ツール際に利用された．中でも 2008 年度に開発した地元のの説明，ドキュメントやソースコードのバージョン

屋外イベント向けチケット予約システムは，開発後 5管理および共有方法の説明などを行う．2013 年度の年間にも渡って使い続けられている．

PBL 遂行に当たってはプロジェクト管理に Redmineを使用し，バージョン管理に Subversion を用いるこ

4 実践的 IT 教育のための PBL カリキュラ
ム開発ととした．

4. 1. 2 基礎技術習得

前節で述べた過去の PBL 事例に基づき，2013 年

基礎技術習得として，プロジェクト管理ツールの使度に模擬開発と実開発を組み合わせた PBL カリキュい方演習，バージョン管理ツールの使い方演習，開発ラムを開発した．主として 3. 3 節で述べた事例を基環境構築，開発に用いるフレームワークのチュートリにして，より新しい開発技術やプロジェクト運用方針アルなどを行う．プロジェクトに関する活動はすべてを取りいれたものとした．

プロジェクト管理ツールにチケット登録すること，登録したチケットには期限，担当者，予定工数を設定す

4. 1 カリキュラム構成

ること，チケット更新時にはそのタスクに費やした時

具体的なカリキュラムの構成は以下の通りであり，間数を実績として記録すること等の指示を行う．2013

全体として 1.5 時間× 30 回の授業時間枠を想定した年度の PBL 遂行に当たっては模擬開発でも本開発でものとなっている．

も，開発に使用するフレームワークとして CakePHP(1) ガイダンス (1.5 時間 ×1 回想定)を採用することとし，基礎技術習得の中で参加する学(2) 基礎技術習得 (1.5 時間 ×4 回想定)

習者個人単位で CakePHP のチュートリアルを行う(3) 模擬開発 (1.5 時間 ×10 回想定)こととした．

(4) 要求開発 (1.5 時間 ×3 回想定)

4. 1. 3 模擬開発
開発体制，共通開発依頼の説明，既存システムとそのドキュメントの紹介．依頼者役との打ち合わせや個別開発依頼の説明，それらに基づく要求分析や技術検証，設計，実装，テスト，依頼者役への納品までの行う．模擬開発で得た技術やスキルが本開発フェーズで応用できることが重要であり，参加する学習者にも最初からそのように伝えておく．

4. 1. 4 要求開発

図1

プロジェクト開始時の様子

システム開発の上流工程としての要求獲得ではな
く，要求開発アライアンスで提唱された Openthology

インタビューにより評価する．貢献度評価は，PBL[8] に基づき，システム開発以前に開発者と依頼者が実施中や終了時に参加学生間の相互評価を行うこと共同して要求を開発する活動を行う．本カリキュラム

や，PBL に関与する参加学生以外の者 (模擬開発のでは実システム開発を扱うため，実際の依頼者に協力依頼者役など) に評価をしてもらうことで評価する．

してもらうのが望ましいが，十分に協力が得られない
場合などは依頼側の状況に詳しい代理者に協力して5 カリキュラム適用事例もらうなどの体制を取る必要がある．

開発した PBL カリキュラムに基づく PBL は，著

4. 1. 5 システム開発者ら所属大学において 2013 年 8 月下旬から翌年 1 月

要求開発した結果に基づき，実在する依頼者やユーに掛けて大学院生を対象として実施予定であるが，こザに対して，実際につかわれることを想定したシステ

れに先行して，4. 1 節で述べたカリキュラムのうちムを開発していく．要件定義，設計，実装，テスト，(1)∼(3) の練習フェーズを，2013 年 5 月から 7 月に納品を進めていくが，採用する開発モデル等は状況掛けて学部 3 年生 5 名× 3 チームを対象に実施した．に適したものを選択する．システム開発では模擬開発時に習得した技術やスキルが応用できるような題

5. 1 配属とプロジェクト開始

材や開発スコープであることが望ましい．模擬開発

同大学の学部 3 年全員を対象とした通年の PBL 必とシステム開発の難易度の差や応用の幅は参加する

修科目「システム情報科学実習」の中で，20 数プロ学習者のスキルに応じて調整できることが望ましく，ジェクト中の 1 プロジェクトで行った．4 月に学部 3

必要であれば PBL 担当教師と実際の依頼者の間で協年全員を対象として教員チームが提案するプロジェク議して調整する．

トテーマを説明し，学生の希望に基づいてプロジェク
ト配属を行った．著者らの提案したテーマには 15 名

4. 2 評価方法の学生が第一希望で配属され，これを学生 5 名ずつ

単なるシステム作りでなく教育として PBL を行うのサブプロジェクトに分けて，5 月に PBL を開始し以上，成績評価が必要となる．スキル評価，目標達成

た (図 1)．

度評価，貢献度評価などを行った上で，PBL の実施体制や実施状況等に応じて総合的に評価を行う．スキ5. 2 PBL スケジュール

ル評価はスキル調査アンケートあるいはスキル調査テ

当該 PBL 科目は 1 週間に 3 時間× 2 回，通年の授ストを用いて，PBL 開始時と終了時の差，もしくは，業科目であるが，プロジェクト開始前の配属プロセス終了時のスキル習得度合いで評価する．目標達成度評や前期末/後期末の発表会等も授業時間枠内で行われ価は，PBL 開始時に参加学生それぞれに個人目標をるため，実質的にプロジェクト活動に使えるのは前期立てさせ，PBL 終了時にその達成度をアンケートや20 回程度，後期 20 回程度である．開発したカリキュ

表1

適用スケジュール

内容

日程回

ガイダンス

5/2

0.5(Redmine/Subversion)

5/2∼5/10

2.5(CakePHP)

5/15∼5/24

4

5/29∼6/28

10౫㢗⪅ᙺ
䠄ᢸᙜᩍဨ䠅

基礎技術習得
㛤Ⓨ

㛤Ⓨ

模擬開発

ラムの適用スケジュール計画は表 1 の通りであった．
この「システム情報科学実習」という科目全体のスケ㛤Ⓨ㛤Ⓨ䝯䞁䝞䠄Ꮫ⏕䠅䝏䞊䝮䝏䞊䝮䝏䞊䝮䝃䝫䞊䝖䝃䝫䞊䝖䝃䝫䞊䝖䜰䝗䝞䜲䝄䠄ୖ⣭⏕䠅

ジュールとして 7 月に前期末の発表会と報告書作成・提出があるため，プロジェクト配属決定後，発表会準備に取りかかる前までに模擬開発まで終わらせると

図2

模擬開発の開発体制いう計画であった．
要件定義書，ユースケース図，業務フロー図，画面遷

5. 3 適用結果移図等を作成し，実装に取り掛かった．各チームと依5. 3. 1 ガイダンスから基礎技術習得まで頼者役との打合せ回数はそれぞれ数回ずつあり，要求ガイダンスから基礎技術習得までは大よそ計画通

ヒアリングの他，進捗報告や実際に開発を進めた上りに進んだが，CakePHP フレームワークの技術習得での開発スコープの変更依頼・承諾などが行われてに関しては授業時間内だけでは理解が不十分となり，いた．各チームとも積極的に PBL に取り組み，時間学生たちが時間外の自習により遅れを取り戻す場面が外の活動も多かったが，3 チーム共，模擬開発完了目あった．ここまでの Redmine チケット数は Redmine

標の 6/28 までに間に合わせることはできなかった．の使い方演習のために登録したものを除いて 38 チ

6/28 より後に発表会準備，発表会，報告書作成があケットであった．チケットには予定工数未記入のもの

るが，授業自体は 7/24 まで行われるため，それらのが 24 と多かった上，この時点では作業時間実績を全活動と並行して 6/28 以降も開発を続けることとなっく記録していなかったため，実際の作業時間は不明た．発表会が行われた 7/12 時点では各チームとも多確である．この間の授業時間数は 1.5 時間 ×7 回の計少のデモができる程度にはシステムが動いていたが10.5 時間であるのに対し，予定工数が記入されてい実装は途中段階であり，実装前に作成していた仕様書たチケットだけでもその合計は 25.5 時間で，かなり類も依頼者側や TA に指摘された不備を完全には直時間超過の傾向が見られる．

し切れていない状態であった．模擬開発開始以降の

5. 3. 2 模擬開発

Redmine チケットは 99 チケットあり，やはり予定工

模擬開発では 3 つの学生チーム A,B,C に対して，数や作業時間の実績が未記入のものが多かった．そのプロジェクト担当教員 3 名がそれぞれ依頼者役とな

内訳は表 2 の通りであった．これを見る限り A チーり，また開発技術やプロジェクト運用のサポートをす

ムと C チームは Redmine を活用したチケット駆動にるために PBL 経験のある上級生が TA として対応しよるプロジェクト運用が相応にできていたようだが，た (図 2)．

B チームはチケット数も他の 2 チームより明らかに開発依頼の概要は 3 チームに対して共通のもので少なく、予定工数も全く入力されていなかった．表中あるが，依頼内容の詳細は各依頼者役の教員が個別の「共通」は 3 チームに共通する内容のチケットで，の判断で決めることとした．各学生チームは依頼者「模擬開発外」は発表会準備など模擬開発には直接関役の教員に要求ヒアリングを行い，得た情報を基に係ないが，模擬開発期間中に必要となったチケットで

表2

表3

模擬開発中の Redmine チケット数内訳

分類

A チーム

チケット数

33

学生別リポジトリ別のコミット回数

共通A

学生 1

236248.9学生 2143637

11予定工数

作業実績

(時間)

(時間)

41.85

B

B チーム

190

4

学生 3C チーム

3839

16

学生 4

910共通

54.5

1

学生 543

2

模擬開発外

330

学生 6

1536

C

学生 71817ある． また，Subversion の利用に当たっては 3 チー

学生 8

38

13

ム共通で利用するリポジトリと各チームごとのリポ

学生 9

911ジトリとを用意し，模擬開発に関してはチームごとの学生 10114リポジトリを使用するよう指示した．各リポジトリに学生 111827

対する学生別のコミット回数は表 3 の通りであった．

学生 1226

3

表中の学生 1 から学生 5 が A チームのメンバ，学生

学生 13

28

26 から学生 10 が B チームのメンバ，学生 11 から学

学生 14

19

2

生 15 が C チームのメンバである．学生 1 は共通リ

学生 15

100

ポジトリに 23 回コミット，A チームのリポジトリにTA1

162 回コミットとコミット回数が非常に多い．学生 5

教員 1

3

は A チームのリポジトリには 2 回しかコミットして

合計

322

121

81

34

いないが，共通リポジトリには 43 回コミットしていて，共通活動への貢献度が高いと推測できる．実際こる場面自体も少なかったと考えられる．の学生は模擬開発外のプロジェクト活動として中間

5. 3. 3 その後の予定発表会用のポスター作成での貢献度が高かった．学生

PBL は教育であって，システムを納品することで15 は共通リポジトリに 10 回コミットしているが，所対価を得るという意味での実開発ではないため，プロ属する C チームのリポジトリには 1 回もコミットしジェクト自体は失敗しても教育としては成功であるておらず，模擬開発への貢献度が疑問視される．確認

可能性もある．しかし，単に開発が予定通り終わらなしたところ，この学生はプロジェクト活動時に使用すかったというだけでは教育としても失敗となってしまる個人 PC に問題が発生し，模擬開発中のドキュメンう．本稿執筆時点でも模擬開発が完了していない状況

トやプログラムにはほぼ手を付けられなかったことがであるが，同授業の後期の活動に向けて，円滑なプロ分かった．チーム単位で見てみると各チームとも相応

ジェクト運用や，そもそもシステム開発プロジェクトに Subversion を使えていたと考えられるが，A チーで期限に間に合わない場合の対応方法などを学習対

ムと B チームを比べると Redmine チケット数と同じ象として PBL を継続している．また，テスト工程やように B チームよりは A チームの方が有効に活用で納品などを全く未経験の状態であるため，当初想定通きていると推測する．C チームは Redmine チケットりにシステムが完成していなくても，部分的にこれら数の割には Subversion コミット回数は少ない．このの活動を行うことのほか，プロジェクトとしての達成チームは，他メンバよりも技術力の高い特定の学生が感を感じさせるために，どこまでを開発にスコープとチームのコミット回数のほとんどを占めており，実作するかを各チームに再検討させ，再検討後のスコー業としてはほぼ一人でチームを引っ張っていて，他メプの完成を持って前期活動を終わらせる予定である．

ンバとドキュメントやプログラムコードを共同編集すまた，この PBL 科目の後期の活動では実際に使われることを想定した実システム開発に取り組む予定で属大学の大学院生のほか，他大学の大学院生数名も参ある．

加予定である．

5. 3. 4 目標達成度評価
参加学生を対象としたアンケートで，このプロジェ

6. 1 短期集中 PBL

クトの開始前には PBL を通じて身に付けたいスキル

8 月最終週に 5 日間の集中講義でガイダンスから模項目を，模擬開発終盤の中間発表会後に身に付いたと擬開発までの練習フェーズを行う (図 4)．ガイダンス

思うスキル項目を調査した．開始前アンケートには参と基礎技術習得を 1.5 日，テスト工程までの模擬開発

加学生 15 名中 14 名から，中間発表後アンケートにを 2.5 日，模擬開発納品を兼ねた発表会を 0.5 日，残は 15 名全員の回答が得られた．アンケートでは「プり 0.5 日は本 PBL と別の枠組みで行っている PBL

ログラミング (Web アプリ)」「プログラミング (スマの発表会に参加する．集中講義形式で行うのは PBLホ)」などのスキル項目を提示し，身に付けたいもの，としては一般的ではないが，集中して行うことの利点あるいは，身に付いたと思うものをいくつでも選択すと，遅れを取り戻すための時間がほとんど確保できなるという方式で調査を行ったところ，図 3 の結果がいことの欠点がどのように結果に表れるかが興味深得られた．

い点である．

スキル項目の候補としてアンケートで提示したもののうち，「プログラミング (Web アプリ)」「データ6. 2 分散 PBL

ベース」「チームワーク」「プレゼンテーション」につ

9 月下旬から翌年 1 月までに要求開発とシステム

いては，事前に身に付けたいと思っていた学生よりも開発の本開発フェーズを行う．原則として短期集中実際に身に付いたと思った学生の方が少し多かった．

PBL と同じ受講生を対象とするが，一部受講メンバ「書類作成」に関しては PBL 開始時にその重要さをが変わる可能性があるため，短期集中 PBL とはチー認識しておらず，実際に取り組んでみたら必要だったム編成を変える予定である．こちらは通常の授業科という判断であると考えられる．
「システム設計」に関目と同様に週 1 回程度の授業時間に集まって PBL をしては事前に身に付けたいと思っていた学生数と実際進めていく．具体的な内容はまだ十分に計画できていに身に付いたと思った学生数が同数であった．
「市民ないが，10 月いっぱいは主に要求開発に当て，11 月や観光客とのコミュニケーション」や「ニーズ調査」からはシステム開発に入る予定である．開発題材はは，このプロジェクトの後期に主に想定していた活動参加する大学院生の所属大学で実際に使えそうなシであり，調査対象の期間中には僅かしか行っていないステムとする予定である．著者ら所属大学の大学院ため，身に付いたと思う学生は少ない．また，「品質生のほか，他大学の大学院生も参加することから「分管理」についてはテスト工程にまだ入っていない段階

散 PBL」としているが，大学間の授業時間調整が難のアンケート調査であるため，身に付いたと思う学生しく，現時点では分散であることの特徴を出せるかどが居ないのは妥当な結果である．なお，「プログラミうか不明確である．

ング (スマホ)」についてはスマホアプリ開発を行う
可能性があることをプロジェクト配属前には担当教員

7 カリキュラム評価と考察が示唆していたものの，模擬開発までの活動では全く難易度の制御が容易な模擬開発と学習意欲を維持着手していないため，これも身に付いたと思う学生がし易い実開発を組み合わせた PBL カリキュラムを開居ないのは妥当な結果である．

発したが，5. 3 節で示したように模擬開発段階で既にかなり時間超過しており，実際には難易度調整がうま6 カリキュラム本実践の計画く為されていなかった．その原因としては，難易度調

本稿で説明したカリキュラムに基づく PBL は以下整の要となる依頼者役が十分に調整を行えていなかっのスケジュールで実施予定である．これには著者ら所たこと，具体的な開発技術やツールの使い方の習得に㌟䛻௜䛡䛯䛔ͬ㌟㌟䛻௜䛔䛯䝇䜻䝹㡯┠䝥䝻䜾䝷䝭䞁䜾;tĞď䜰䝥䝸Ϳ䝥䝻䜾䝷䝭䞁䜾;䝇䝬䝩Ϳ䝕䞊䝍䝧䞊䝇䝅䝇䝔䝮タィ᭩㢮సᡂᕷẸ䜔ほගᐈ䛸䛾䝁䝭䝳䝙䜿䞊䝅䝵䞁䝙䞊䝈➼ㄪᰝ䝏䞊䝮䝽䞊䜽䝸䞊䝎䝅䝑䝥䝥䝻䝆䜵䜽䝖䝬䝛䝆䝯䞁䝖ရ㉁⟶⌮䝥䝺䝊䞁䝔䞊䝅䝵䞁
図3ϬϮϰϲϴϭϬϭϮϭϰ

㌟䛻௜䛡䛯䛔㌟䛻௜䛔䛯

身に付けたい/身に付いたスキル項目

䜹䝸䜻䝳䝷䝮ヨ㦂ᐇ᪋䛸ᮏᐇ᪋䛾᪥ᩘϬϮϰϲϴϭϬϭϮϭϰϭϲϭϴ

ヨ㦂ᐇ᪋
Ꮫ㒊ϯᖺͿ
ᮏᐇ᪋;኱Ꮫ㝔Ϳ䜺䜲䝎䞁䝇 ᇶ♏ᢏ⾡⩦ᚓ;ZĞĚŵŝŶĞ͕^ƵďǀĞƌƐŝŽŶͿ ᇶ♏ᢏ⾡⩦ᚓ;ĂŬĞW,WͿ ᶍᨃ㛤Ⓨ;

図4

試験実施と本実施の日程

重点を置いてしまい，実際にプロジェクトを進めていえられる．また，模擬開発自体の難易度調整はうまくくに当たっての運用技術の習得を結果的に軽視してし為されなかったものの，ここで行かなかったことがそまったこと，実際には模擬開発と並行して発表会の準の後の活動に役立ち，PBL としては成功する可能性

備や後期の活動の準備を早くから始めてしまい模擬もあり得る．その点は 1 年間の PBL 科目を終えてか開発に専念できていなかったことなどが考えられる．

らの評価となる．

受講学生の 1/3 程度は学内で課外活動として行われ学習意欲に関しては，7 月までの活動は基礎技術習ている他の PBL への参加経験があったが，自分たち得や模擬開発であったものの，それらがその後の活動が主体となる PBL は初めてであり，他の 2/3 はそもへの準備段階であるという意識が参加メンバに十分浸

そも PBL 初経験であることから，プロジェクト運用透しており，意欲的に PBL 活動を継続できていた．

上起こり得る問題への対処方法をある程度は教えて

なお，8 月末と後期の本実践では，受講生のほとんおく必要があったと考える．具体的には各チームの依どは学部 3 年次に PBL を経験済みであり，一部の受頼者役との打合せ回数を多く設定させて，開発スコー講生は複数年に渡っていくつも PBL を経験しているプを柔軟に調整し易くすることや，各チームのリーダことから，プロジェクト運用に関しては 5 月 ∼7 月のから PBL 担当教師に定期的に状況報告をさせて，担試験実践ほどには問題にならないと予想される．しか当教師が模擬開発全体の調整を図るなどの対策が考し，それぞれの状況に応じてプロジェクト運用技術の習得をどのようにカリキュラムに盛り込むかは今後の検討課題である．

8 まとめ
本稿では，著者ら所属大学で過去に実施した模擬開発を行う PBL と実開発を行う PBL について事例紹介をした上で，両者を組み合わせた PBL カリキュラムを報告した．また，同カリキュラムの試験運用として 2013 年度前期に行った PBL について紹介した．
参 考 文 献[1] enPiT 事務局: 分野・地域を超えた実践的情報教育協働ネットワーク, http://www.enpit.jp/, 2013.
[2] PBL Summit 2012 実行委員会: PBL Summit 2012,
http://pblsummit.jp, 2012.

[3] 伊藤恵, 奥野拓, 今野陽子: PBL による地域向けシステムの構築と運用, 電気学会研究会資料, Vol. IS,No. 12, 電気学会, 2012, pp. 7–10.
[4] 駒谷昇一: 実践的 PBL によるエンタープライズ系システム企画設計開発の授業実践, 情報システムと社会環境研究報告, Vol. 2009, No. 32(2009), pp. 177–184.
[5] 駒谷昇一, 田中二郎, 北川博之: 筑,, 工学教育, No. 4,pp. 92–98.
[6] 情報処理推進機構: IT 人材育成白書 2012, 情報処理推進機構, 2012.
[7] 総務省: enPeL(遠隔教育システム), http://www.
soumu.go.jp/main_sosiki/joho_tsusin/joho_jinzai/,
2013.
[8] 要求開発アライアンス: Openthology, http://www.
openthology.org/.
[9] 鈴木恵二, 伊藤恵, 斉藤朝輝, 奥野拓: 高度 IT 人材育成システム開発と e-ラーニングによる Java スキルアップ, 情報教育シンポジウム SSS2005 プレカンファレンス, 2005.