日本ソフトウェア科学会第 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 be used by real customers, although it is difficult to control difficulty or quality of the education. Based on our experiences 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 はじめに
実 践 的 なIT技 術 者 育 成 の た め に 様々な 高 等 教 育 機 関 で シ ス テ ム 構 築 を 主 と し たProject Based Learning(以下PBL)を用いた教育が行われている [6] [5] [4] [2]． システム構築を主としたPBLを構築題材の種類で 分類すると，実際には使われない模擬システムの開発 を行うものと，実在の依頼者や利用者に向けて実際に 使われることを想定した実システム開発を行うもの がある[3]．前者は，よく作り込まれた教材を利用す れば，PBL自体の難易度などの制御がし易く，PBL の実施期間や参加人数などに応じた柔軟な対応が可 能である一方，構築するシステムが実際に使われるこ とのないシステムであることから学習意欲の低下を 招きやすい．後者は，うまく構築できれば実際に使わ れる可能性のあるシステムであることから学習意欲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. は保ちやすいが，教育としての難易度調整などが難し く，PBL期間中に全く完成の目途が立たずに学習と して消化不良になる場合もある． そこで我々は所属大学での過去のPBL事例に基づ き，両種類を混合することにより，学習意欲を保ちな がら，一定の難易度制御が可能なPBLカリキュラム を開発したので，ここに報告する．
2 関連研究
2. 1 模擬システム開発演習教材ABSおよびNSP よく作り込まれた模擬システム開発演習教材とし て，2002年度に経済産業省「高度IT人材育成シス テム開発事業」に採択された「実践型グループ学生 教育コースの開発及び実施評価」において構築され たABS[9]や，総務省「最先端ネットワーク技術を活 用した遠隔教育システムの開発・実証事業」におい てPBL教材として採用されたNSPがある[7]．これ らの教材は開発及び運用環境としてJava，Tomcat, PostgreSQL等を想定したもので，既存システムおよ びその仕様書一式と開発依頼書を与えられ，これらに 基づいてチーム開発を進めていくものである．これら の教材には，途中で依頼者役が仕様変更を要求する場面なども用意されており，模擬的な開発ではあるもの の現実的な開発の局面をできるだけ再現できるように 作り込まれている．また，NSPでは教師が模擬シス テム開発を運用するためのガイド用ドキュメント等も 充実しており，よく作り込まれた教材となっている． 2. 2 分野・地域を超えた実践的情報教育協働ネッ トワークenPiT 文部科学省の情報技術人材育成のための実践教育 ネットワーク形成事業による補助金助成を受けて， 2012年度から「分野・地域を超えた実践的情報教育 協働ネットワーク(通称enPiT)」が実施されている [1]．enPiTではクラウドコンピューティング，セキュ リティ，組込みシステム，ビジネスアプリケーション の4分野において，全国さまざまな大学で行われて いる実践的情報教育を連携させ，短期集中合宿と分 散PBLを組み合わせた教育プログラムの開発と運用 を行っている．本稿で報告する教育カリキュラムは， この事業のうちのビジネスアプリケーション分野向け のものである．
3 PBL 事例紹介
著者らの所属大学では2002年度以降，学部3年次 の通年の必修科目「システム情報科学実習」におい て，毎年度約250名の3年生が20程度のプロジェク トに分かれてPBLを行っている．プロジェクトは毎 年度教員チームによるテーマ提案，学生の参加希望に 基づく配属，プロジェクト実施をしており，システム 構築を伴うプロジェクトもそうでないプロジェクトも ある．過去に実施されたプロジェクトの中には模擬シ ステム開発を行ったもの，実システム開発を行ったも の，その両方を行ったものがあり，次節以降でそれら の事例紹介を行う． 3. 1 模擬開発事例 2002年度に経済産業省「高度IT人材育成システ ム開発事業」に採択された「実践型グループ学生教育 コースの開発及び実施評価」において，実装技術のス キルアップのためのe-learning教材と模擬システム 開発教材が開発された[9]ことを受けて，翌2003年 度のPBLにおいて模擬システム開発を行った．この プロジェクトへの配属を希望した学部3年生24名を 4チームに分け，連名でプロジェクトのテーマ提案を 行った4名の教員を仮想顧客役として模擬開発を行っ た．年度の前半は主に参加学生個人個人の基礎技術習 得を行い，グループ単位の模擬開発は主に年度後半に 行った．模擬システム開発教材には要求分析，設計， 実装，テストなどの工程が含まれており，仕様書の完 成度を高めてから初めて実装に取り組むという進め方 に対して，そういった経験のない参加学生には戸惑い も多く見られた．また，作っているものがあくまで模 擬的なものであることから，同年度のPBLにおいて 他プロジェクトで作られていた模擬的でないシステム の方が魅力的に見えるなどといった場面もあったが， 参加学生たちも最終的にはシステム開発プロセスを 一通り体験することと，それを通じてスキルアップを することの重要性を感じることができたと報告して いる． 2007年度から当大学に開設された実践的IT人材 育成講座においても，講座立ち上げ時の約半年間，同 じ教材を使用した模擬システム開発を行った．この講 座には学部3年生から大学院修士2年生までの希望 者が参加し，授業単位の取得を伴わない課外活動で あった．この事例では参加学生たちのスキルアップ意 欲を十分に持続させることができず，最終的には発表 会に間に合わせるために動くものを作るということ を目的とした活動となってしまった． 3. 2 実開発事例 3年次必修科目「システム情報科学実習」において も，前節で述べた実践的IT人材育成講座においても， 実際に使われることを想定した実システム開発は多 く行われている．中でも2008年度の実践的IT人材 育成講座内のプロジェクトで行った観光情報サイト構 築は，地元公共団体からの依頼に基づくものであり， 構築後の同サイトを受託運営する民間企業と協議を 重ねながら構築した．参加した学生は学部3年生か ら大学院修士2年生までの計21名であった．地元公 共団体から大学への受託研究としてサイト構築依頼 があり，同年12月のサイトオープンまでに必ず構築を完了することが求められたため，教師側からの難易 度調整等は事実上不可能であった．地元公共団体の公 式のサイトとして実際に使われることが明らかであっ たことや，受託研究予算の一部が学生への謝礼として 支払われたこともあり，参加学生の構築意欲は当初非 常に高かったが，地元公共団体や運営業者からの要求 難易度が極めて高く，逆に意欲喪失して参加を辞めた 学生も居た．しかし，最終的にはサイトオープンまで に構築を終え，この活動に関して参加学生チームが大 学内で表彰されるに至った． 3. 3 模擬開発と実開発の組み合わせ事例 1回のPBLの中で模擬システム開発と実システ ム開発を組み合わせた事例もあった．2006年度から 2008年度までの「システム情報科学実習」において， 年度前半には主に技術習得を目的として3. 1節の事 例紹介で述べた教材を一部簡略化したものを用いた 模擬システム開発を行い，年度後半には地域の団体等 を依頼者として実システム開発を行った．この方式で 開発したシステムのいくつかは，開発の翌年度に実 際に利用された．中でも2008年度に開発した地元の 屋外イベント向けチケット予約システムは，開発後5 年間にも渡って使い続けられている．
4 実践的 IT 教育のための PBL カリキュラ
ム開発
前節で述べた過去のPBL事例に基づき，2013年 度に模擬開発と実開発を組み合わせたPBLカリキュ ラムを開発した．主として3. 3節で述べた事例を基 にして，より新しい開発技術やプロジェクト運用方針 を取りいれたものとした． 4. 1 カリキュラム構成 具体的なカリキュラムの構成は以下の通りであり， 全体として1.5時間× 30回の授業時間枠を想定した ものとなっている． (1) ガイダンス(1.5時間×1回想定) (2) 基礎技術習得(1.5時間×4回想定) (3) 模擬開発(1.5時間×10回想定) (4) 要求開発(1.5時間×3回想定) (5) システム開発(1.5時間×12回想定) ガイダンスから模擬開発までは練習フェーズ，それ より後は本開発フェーズの扱いである．模擬開発では 依頼者役が必要となり，PBLの担当教師でない者が 依頼者役となるのが望ましいが，担当教師がなっても よい．ただし，依頼者役としての発言とPBL担当教 師としての発言を明確に区別する必要がある．もし も複数チーム体制でPBLを行う場合にはチームごと に別々の依頼者役がいる方が望ましい．要求開発以降 では実システム開発を行うため，原則として依頼者 が居る必要がある．題材によっては明示的な依頼に基 づかずに，想定されるユーザの役に立つシステムを 開発するということもあり得る．その場合であっても PBLに参加する開発メンバとは異なる視点でユーザ の意見を代表できる依頼者役が必要である． カリキュラムの各項目で行う具体的な内容について 以下で説明する． 4. 1. 1 ガイダンス PBL全体の目的や運用方針の説明のほか，大まか なプロジェクト計画の説明，プロジェクト管理ツール の説明，ドキュメントやソースコードのバージョン 管理および共有方法の説明などを行う．2013年度の PBL遂行に当たってはプロジェクト管理にRedmine を使用し，バージョン管理にSubversionを用いるこ ととした． 4. 1. 2 基礎技術習得 基礎技術習得として，プロジェクト管理ツールの使 い方演習，バージョン管理ツールの使い方演習，開発 環境構築，開発に用いるフレームワークのチュートリ アルなどを行う．プロジェクトに関する活動はすべて プロジェクト管理ツールにチケット登録すること，登 録したチケットには期限，担当者，予定工数を設定す ること，チケット更新時にはそのタスクに費やした時 間数を実績として記録すること等の指示を行う．2013 年度のPBL遂行に当たっては模擬開発でも本開発で も，開発に使用するフレームワークとしてCakePHP を採用することとし，基礎技術習得の中で参加する学 習者個人単位でCakePHPのチュートリアルを行う こととした．4. 1. 3 模擬開発 開発体制，共通開発依頼の説明，既存システムとそ のドキュメントの紹介．依頼者役との打ち合わせや個 別開発依頼の説明，それらに基づく要求分析や技術検 証，設計，実装，テスト，依頼者役への納品までの行 う．模擬開発で得た技術やスキルが本開発フェーズで 応用できることが重要であり，参加する学習者にも最 初からそのように伝えておく． 4. 1. 4 要求開発 システム開発の上流工程としての要求獲得ではな く，要求開発アライアンスで提唱されたOpenthology [8]に基づき，システム開発以前に開発者と依頼者が 共同して要求を開発する活動を行う．本カリキュラム では実システム開発を扱うため，実際の依頼者に協力 してもらうのが望ましいが，十分に協力が得られない 場合などは依頼側の状況に詳しい代理者に協力して もらうなどの体制を取る必要がある． 4. 1. 5 システム開発 要求開発した結果に基づき，実在する依頼者やユー ザに対して，実際につかわれることを想定したシステ ムを開発していく．要件定義，設計，実装，テスト， 納品を進めていくが，採用する開発モデル等は状況 に適したものを選択する．システム開発では模擬開 発時に習得した技術やスキルが応用できるような題 材や開発スコープであることが望ましい．模擬開発 とシステム開発の難易度の差や応用の幅は参加する 学習者のスキルに応じて調整できることが望ましく， 必要であればPBL担当教師と実際の依頼者の間で協 議して調整する． 4. 2 評価方法 単なるシステム作りでなく教育としてPBLを行う 以上，成績評価が必要となる．スキル評価，目標達成 度評価，貢献度評価などを行った上で，PBLの実施 体制や実施状況等に応じて総合的に評価を行う．スキ ル評価はスキル調査アンケートあるいはスキル調査テ ストを用いて，PBL開始時と終了時の差，もしくは， 終了時のスキル習得度合いで評価する．目標達成度評 価は，PBL開始時に参加学生それぞれに個人目標を 立てさせ，PBL終了時にその達成度をアンケートや 図 1 プロジェクト開始時の様子 インタビューにより評価する．貢献度評価は，PBL 実施中や終了時に参加学生間の相互評価を行うこと や，PBLに関与する参加学生以外の者(模擬開発の 依頼者役など)に評価をしてもらうことで評価する．
5 カリキュラム適用事例
開発したPBLカリキュラムに基づくPBLは，著 者ら所属大学において2013年8月下旬から翌年1月 に掛けて大学院生を対象として実施予定であるが，こ れに先行して，4. 1節で述べたカリキュラムのうち (1)∼(3)の練習フェーズを，2013年5月から7月に 掛けて学部3年生5名× 3チームを対象に実施した． 5. 1 配属とプロジェクト開始 同大学の学部3年全員を対象とした通年のPBL必 修科目「システム情報科学実習」の中で，20数プロ ジェクト中の1プロジェクトで行った．4月に学部3 年全員を対象として教員チームが提案するプロジェク トテーマを説明し，学生の希望に基づいてプロジェク ト配属を行った．著者らの提案したテーマには15名 の学生が第一希望で配属され，これを学生5名ずつ のサブプロジェクトに分けて，5月にPBLを開始し た(図1)． 5. 2 PBLスケジュール 当該PBL科目は1週間に3時間× 2回，通年の授 業科目であるが，プロジェクト開始前の配属プロセス や前期末/後期末の発表会等も授業時間枠内で行われ るため，実質的にプロジェクト活動に使えるのは前期 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月に前期末の発表会と報告書作成・ 提出があるため，プロジェクト配属決定後，発表会準 備に取りかかる前までに模擬開発まで終わらせると いう計画であった． 5. 3 適用結果 5. 3. 1 ガイダンスから基礎技術習得まで ガイダンスから基礎技術習得までは大よそ計画通 りに進んだが，CakePHPフレームワークの技術習得 に関しては授業時間内だけでは理解が不十分となり， 学生たちが時間外の自習により遅れを取り戻す場面が あった．ここまでのRedmineチケット数はRedmine の使い方演習のために登録したものを除いて38チ ケットであった．チケットには予定工数未記入のもの が24と多かった上，この時点では作業時間実績を全 く記録していなかったため，実際の作業時間は不明 確である．この間の授業時間数は1.5時間×7回の計 10.5時間であるのに対し，予定工数が記入されてい たチケットだけでもその合計は25.5時間で，かなり 時間超過の傾向が見られる． 5. 3. 2 模擬開発 模擬開発では3つの学生チームA,B,Cに対して， プロジェクト担当教員3名がそれぞれ依頼者役とな り，また開発技術やプロジェクト運用のサポートをす るためにPBL経験のある上級生がTAとして対応し た(図2)． 開発依頼の概要は3チームに対して共通のもので あるが，依頼内容の詳細は各依頼者役の教員が個別 の判断で決めることとした．各学生チームは依頼者 役の教員に要求ヒアリングを行い，得た情報を基に 䝏䞊䝮 䝏䞊䝮 䝏䞊䝮 ౫㢗⪅ᙺ 䠄ᢸᙜᩍဨ䠅 㛤Ⓨ䝯䞁䝞 䠄Ꮫ⏕䠅 䜰䝗䝞䜲䝄 䠄ୖ⣭⏕䠅 䝃䝫䞊䝖 䝃䝫䞊䝖 䝃䝫䞊䝖 㛤Ⓨ 㛤Ⓨ 㛤Ⓨ 図 2 模擬開発の開発体制 要件定義書，ユースケース図，業務フロー図，画面遷 移図等を作成し，実装に取り掛かった．各チームと依 頼者役との打合せ回数はそれぞれ数回ずつあり，要求 ヒアリングの他，進捗報告や実際に開発を進めた上 での開発スコープの変更依頼・承諾などが行われて いた．各チームとも積極的にPBLに取り組み，時間 外の活動も多かったが，3チーム共，模擬開発完了目 標の6/28までに間に合わせることはできなかった． 6/28より後に発表会準備，発表会，報告書作成があ るが，授業自体は7/24まで行われるため，それらの 活動と並行して6/28以降も開発を続けることとなっ た．発表会が行われた7/12時点では各チームとも多 少のデモができる程度にはシステムが動いていたが 実装は途中段階であり，実装前に作成していた仕様書 類も依頼者側やTAに指摘された不備を完全には直 し切れていない状態であった．模擬開発開始以降の Redmineチケットは99チケットあり，やはり予定工 数や作業時間の実績が未記入のものが多かった．その 内訳は表2の通りであった．これを見る限りAチー ムとCチームはRedmineを活用したチケット駆動に よるプロジェクト運用が相応にできていたようだが， Bチームはチケット数も他の2チームより明らかに 少なく、予定工数も全く入力されていなかった．表中 の「共通」は3チームに共通する内容のチケットで， 「模擬開発外」は発表会準備など模擬開発には直接関 係ないが，模擬開発期間中に必要となったチケットで
表 2 模擬開発中の Redmine チケット数内訳 分類 チケット数 予定工数 作業実績 (時間) (時間) Aチーム 33 41.85 48.9 Bチーム 19 0 4 Cチーム 38 39 16 共通 5 4.5 1 模擬開発外 3 3 0 ある． また，Subversionの利用に当たっては3チー ム共通で利用するリポジトリと各チームごとのリポ ジトリとを用意し，模擬開発に関してはチームごとの リポジトリを使用するよう指示した．各リポジトリに 対する学生別のコミット回数は表3の通りであった． 表中の学生1から学生5がAチームのメンバ，学生 6から学生10がBチームのメンバ，学生11から学 生15がCチームのメンバである．学生1は共通リ ポジトリに23回コミット，Aチームのリポジトリに 62回コミットとコミット回数が非常に多い．学生5 はAチームのリポジトリには2回しかコミットして いないが，共通リポジトリには43回コミットしてい て，共通活動への貢献度が高いと推測できる．実際こ の学生は模擬開発外のプロジェクト活動として中間 発表会用のポスター作成での貢献度が高かった．学生 15は共通リポジトリに10回コミットしているが，所 属するCチームのリポジトリには1回もコミットし ておらず，模擬開発への貢献度が疑問視される．確認 したところ，この学生はプロジェクト活動時に使用す る個人PCに問題が発生し，模擬開発中のドキュメン トやプログラムにはほぼ手を付けられなかったことが 分かった．チーム単位で見てみると各チームとも相応 にSubversionを使えていたと考えられるが，Aチー ムとBチームを比べるとRedmineチケット数と同じ ようにBチームよりはAチームの方が有効に活用で きていると推測する．CチームはRedmineチケット 数の割にはSubversionコミット回数は少ない．この チームは，他メンバよりも技術力の高い特定の学生が チームのコミット回数のほとんどを占めており，実作 業としてはほぼ一人でチームを引っ張っていて，他メ ンバとドキュメントやプログラムコードを共同編集す 表 3 学生別リポジトリ別のコミット回数 共通 A B C 学生1 23 62 学生2 14 36 学生3 37 11 学生4 9 10 学生5 43 2 学生6 15 36 学生7 18 17 学生8 38 13 学生9 9 11 学生10 11 4 学生11 18 27 学生12 26 3 学生13 28 2 学生14 19 2 学生15 10 0 TA1 1 教員1 3 合計 322 121 81 34 る場面自体も少なかったと考えられる． 5. 3. 3 その後の予定 PBLは教育であって，システムを納品することで 対価を得るという意味での実開発ではないため，プロ ジェクト自体は失敗しても教育としては成功である 可能性もある．しかし，単に開発が予定通り終わらな かったというだけでは教育としても失敗となってしま う．本稿執筆時点でも模擬開発が完了していない状況 であるが，同授業の後期の活動に向けて，円滑なプロ ジェクト運用や，そもそもシステム開発プロジェクト で期限に間に合わない場合の対応方法などを学習対 象としてPBLを継続している．また，テスト工程や 納品などを全く未経験の状態であるため，当初想定通 りにシステムが完成していなくても，部分的にこれら の活動を行うことのほか，プロジェクトとしての達成 感を感じさせるために，どこまでを開発にスコープと するかを各チームに再検討させ，再検討後のスコー プの完成を持って前期活動を終わらせる予定である． また，このPBL科目の後期の活動では実際に使われ
ることを想定した実システム開発に取り組む予定で ある． 5. 3. 4 目標達成度評価 参加学生を対象としたアンケートで，このプロジェ クトの開始前にはPBLを通じて身に付けたいスキル 項目を，模擬開発終盤の中間発表会後に身に付いたと 思うスキル項目を調査した．開始前アンケートには参 加学生15名中14名から，中間発表後アンケートに は15名全員の回答が得られた．アンケートでは「プ ログラミング(Webアプリ)」「プログラミング(スマ ホ)」などのスキル項目を提示し，身に付けたいもの， あるいは，身に付いたと思うものをいくつでも選択す るという方式で調査を行ったところ，図3の結果が 得られた． スキル項目の候補としてアンケートで提示したも ののうち，「プログラミング(Webアプリ)」「データ ベース」「チームワーク」「プレゼンテーション」につ いては，事前に身に付けたいと思っていた学生よりも 実際に身に付いたと思った学生の方が少し多かった． 「書類作成」に関してはPBL開始時にその重要さを 認識しておらず，実際に取り組んでみたら必要だった という判断であると考えられる．「システム設計」に関 しては事前に身に付けたいと思っていた学生数と実際 に身に付いたと思った学生数が同数であった．「市民 や観光客とのコミュニケーション」や「ニーズ調査」 は，このプロジェクトの後期に主に想定していた活動 であり，調査対象の期間中には僅かしか行っていない ため，身に付いたと思う学生は少ない．また，「品質 管理」についてはテスト工程にまだ入っていない段階 のアンケート調査であるため，身に付いたと思う学生 が居ないのは妥当な結果である．なお，「プログラミ ング(スマホ)」についてはスマホアプリ開発を行う 可能性があることをプロジェクト配属前には担当教員 が示唆していたものの，模擬開発までの活動では全く 着手していないため，これも身に付いたと思う学生が 居ないのは妥当な結果である．
6 カリキュラム本実践の計画
本稿で説明したカリキュラムに基づくPBLは以下 のスケジュールで実施予定である．これには著者ら所 属大学の大学院生のほか，他大学の大学院生数名も参 加予定である． 6. 1 短期集中PBL 8月最終週に5日間の集中講義でガイダンスから模 擬開発までの練習フェーズを行う(図4)．ガイダンス と基礎技術習得を1.5日，テスト工程までの模擬開発 を2.5日，模擬開発納品を兼ねた発表会を0.5日，残 り0.5日は本PBLと別の枠組みで行っているPBL の発表会に参加する．集中講義形式で行うのはPBL としては一般的ではないが，集中して行うことの利点 と，遅れを取り戻すための時間がほとんど確保できな いことの欠点がどのように結果に表れるかが興味深 い点である． 6. 2 分散PBL 9月下旬から翌年1月までに要求開発とシステム 開発の本開発フェーズを行う．原則として短期集中 PBLと同じ受講生を対象とするが，一部受講メンバ が変わる可能性があるため，短期集中PBLとはチー ム編成を変える予定である．こちらは通常の授業科 目と同様に週1回程度の授業時間に集まってPBLを 進めていく．具体的な内容はまだ十分に計画できてい ないが，10月いっぱいは主に要求開発に当て，11月 からはシステム開発に入る予定である．開発題材は 参加する大学院生の所属大学で実際に使えそうなシ ステムとする予定である．著者ら所属大学の大学院 生のほか，他大学の大学院生も参加することから「分 散PBL」としているが，大学間の授業時間調整が難 しく，現時点では分散であることの特徴を出せるかど うか不明確である．7 カリキュラム評価と考察
難易度の制御が容易な模擬開発と学習意欲を維持 し易い実開発を組み合わせたPBLカリキュラムを開 発したが，5. 3節で示したように模擬開発段階で既に かなり時間超過しており，実際には難易度調整がうま く為されていなかった．その原因としては，難易度調 整の要となる依頼者役が十分に調整を行えていなかっ たこと，具体的な開発技術やツールの使い方の習得にϬ Ϯ ϰ ϲ ϴ ϭϬ ϭϮ ϭϰ 䝥䝻䜾䝷䝭䞁䜾;tĞď䜰䝥䝸Ϳ 䝥䝻䜾䝷䝭䞁䜾;䝇䝬䝩Ϳ 䝕䞊䝍䝧䞊䝇 䝅䝇䝔䝮タィ ᭩㢮సᡂ ᕷẸ䜔ほගᐈ䛸䛾䝁䝭䝳䝙䜿䞊䝅䝵䞁 䝙䞊䝈➼ㄪᰝ 䝏䞊䝮䝽䞊䜽 䝸䞊䝎䝅䝑䝥 䝥䝻䝆䜵䜽䝖䝬䝛䝆䝯䞁䝖 ရ㉁⟶⌮ 䝥䝺䝊䞁䝔䞊䝅䝵䞁
㌟
㌟
㌟
㌟䛻
䛻
䛻
䛻
䛡
䛡
䛡
䛡䛯
䛯䛔
䛯
䛯
䛔
䛔
䛔ͬ㌟
㌟
㌟
㌟䛻
䛻
䛻
䛻
䛔
䛔
䛔
䛔䛯
䛯
䛯
䛯䝇
䝇
䝇
䝇䜻
䜻䝹
䜻
䜻
䝹
䝹
䝹㡯
㡯
㡯
㡯┠
┠
┠
┠
㌟䛻䛡䛯䛔 ㌟䛻䛔䛯 図 3 身に付けたい/身に付いたスキル項目 Ϭ Ϯ ϰ ϲ ϴ ϭϬ ϭϮ ϭϰ ϭϲ ϭϴ ヨ㦂ᐇ ;Ꮫ㒊ϯᖺͿ ᮏᐇ ;Ꮫ㝔Ϳ䜹
䜹
䜹
䜹䝸
䝸
䝸
䝸䜻
䜻
䜻䝳
䜻
䝳
䝳
䝳䝷
䝷䝮
䝷
䝷
䝮
䝮
䝮ヨ
ヨ
ヨ
ヨ㦂
㦂
㦂
㦂ᐇ
ᐇ
ᐇ
ᐇ
䛸
䛸
䛸
䛸ᮏ
ᮏ
ᮏ
ᮏᐇ
ᐇ
ᐇ
ᐇ
䛾
䛾
䛾
䛾᪥
᪥
᪥
᪥ᩘ
ᩘ
ᩘ
ᩘ
䜺䜲䝎䞁䝇 ᇶ♏ᢏ⾡⩦ᚓ;ZĞĚŵŝŶĞ͕^ƵďǀĞƌƐŝŽŶͿ ᇶ♏ᢏ⾡⩦ᚓ;ĂŬĞW,WͿ ᶍᨃ㛤Ⓨ 図 4 試験実施と本実施の日程 重点を置いてしまい，実際にプロジェクトを進めてい くに当たっての運用技術の習得を結果的に軽視してし まったこと，実際には模擬開発と並行して発表会の準 備や後期の活動の準備を早くから始めてしまい模擬 開発に専念できていなかったことなどが考えられる． 受講学生の1/3程度は学内で課外活動として行われ ている他のPBLへの参加経験があったが，自分たち が主体となるPBLは初めてであり，他の2/3はそも そもPBL初経験であることから，プロジェクト運用 上起こり得る問題への対処方法をある程度は教えて おく必要があったと考える．具体的には各チームの依 頼者役との打合せ回数を多く設定させて，開発スコー プを柔軟に調整し易くすることや，各チームのリーダ からPBL担当教師に定期的に状況報告をさせて，担 当教師が模擬開発全体の調整を図るなどの対策が考 えられる．また，模擬開発自体の難易度調整はうまく 為されなかったものの，ここで行かなかったことがそ の後の活動に役立ち，PBLとしては成功する可能性 もあり得る．その点は1年間のPBL科目を終えてか らの評価となる． 学習意欲に関しては，7月までの活動は基礎技術習 得や模擬開発であったものの，それらがその後の活動 への準備段階であるという意識が参加メンバに十分浸 透しており，意欲的にPBL活動を継続できていた． なお，8月末と後期の本実践では，受講生のほとん どは学部3年次にPBLを経験済みであり，一部の受 講生は複数年に渡っていくつもPBLを経験している ことから，プロジェクト運用に関しては5月∼7月の 試験実践ほどには問題にならないと予想される．しか し，それぞれの状況に応じてプロジェクト運用技術の習得をどのようにカリキュラムに盛り込むかは今後の 検討課題である．
