東海大学紀要情報通信学部
Vol.13,No.2,2020,pp.1-8

東海大学紀要 情報通信学部
Vol.xx, No.xx , 20xx, pp.xxx -xxx

論文
論文

PBL の実践による組込みソフトウェア開発に関する学生の意識変化の検証
撫中 達司 *1 ，佐藤

未来子 *2 ，大江信宏 *1

Verification of Changes in Students' Perception ofEmbedded Software Development through PBL PracticebyTatsuji MUNAKA *1 , Mikiko SATO *2 and Nobuhiro OHE *1( Received on Sep. 24, 2020 & Accepted on Nov. 16, 2020 )あらまし
文科省は成長分野を支える情報技術人材の育成に向け，課題解決型学習（PBL)等の実践的な教育を広く普及させる拠点の形成(enPiT)を進めている．東海大学情報通信学部組込みソフトウェア工学科では，組織の中で働く上での基礎技術力の育成を実践するカリキュラムの中で，基礎力のまとめとして 位置づ けている組込みソフトウェア工学実験1を4セメスタ（2年生秋学期）に開講している．本授業では，ソフトウェア開発を行うための方法の一つであるウォーターフォールモデルを学ぶ中で，特にソフト ウェア 開発における工程管理や，上流工程である要求分析やプログラム設計の重要性をグループでの実習，PBLを通じて身に着けることを目的としている．本稿では，この目的に対する結果検証について，学生に対して実施したアンケート結果をもとに評価，考察する．結果として，ソフトウェア開発における工程管理や上流工程作業の重要性について学生の意識変化が確認できた．またPBLを実践することにより，マネージメントの重要さ，難しさを認識したことも確認することができた．
Abstract
The Ministry of Education, Culture, Sports, Science, and Technology is promoting PBL in the formation of an information
technology human resource development base that supports growth fields (enPiT). Embedded Software Engineering Department
implements a curriculum that fosters the necessary technical skills for working in an organization in society. The class ofEmbedded Software Engineering Experiment 1 is positioned as a summary of the necessary skills and operated in 4 semesters(2nd year Fall Semester). In this class, while learning the waterfall model which is one of the methods for software development,
the importance of process management in software development, requirements analysis, and program design, which are upstream
processes, it is intended to be worn through practical training and PBL. In this paper, we report on the evaluation andconsideration based on the results of questionnaires conducted on students to verify the results for this purpose. As a result, it
was confirmed that students recognized the importance of process management and upstream process work in softwaredevelopment. We also know that students recognized the difficulty and importance of management through the practice of PBL.
キ ー ワ ー ド ： ソフトウェア開発， 工程管理， ウォーターフォールモデル， PBL（Project Based Learning）
Keywords: Software Development ， Schedule Management ， Water-Fall Model ， PBL(Project Based Learning)

1. は じ め にあらゆるモノがインターネットに接続され(IoT)，収集された大量のデータを活用した新たなサービスの創出が期待されており，そのサービスを担う多くの機器のスマート化が進められている．このような背景の中，これら機器に組込まれるソフトウェアの重要性がこれまで以上に高まって*1 情報通信学部組込みソフトウェア工学科 教授
School of Information and Telecommunication
Engineering，Department of Embedded Technology，Professor*2 情報通信学部組込みソフトウェア工学科 准教授
School of Information and Telecommunication
Engineering，Department of Embedded Technology，Assistant Professor

いる．スマート機器は，状況の観察，観察の結果得られた情報の記録，情報を用いた自発的な動作などが要件とされるが，機器単体に留まらずユーザに提供するサービス全体の中でどのような役割を果たすのかを考慮したものであることが必須となっている．
ドイツの Industrie4.0 では，モノづくりを RAMI4.01)と呼ばれるアーキテクチャで設計することがそのガイドとして示されており，その具体的な開発手法として，UML を用いたシステム分析，システム設計が基本となっている．このようにソフトウェア開発は，ソフトウェア工学の分野において，様々な開発手法やモデル化が研究されており，現在も進化し続けている．
このような背景において，特に組込みソフトウェアの技術者育成は火急かつ非常に重要な課題であり，文科省は成長分野を支える情報技術人材の育成に向け，課題解決型学――− 11 −

PBL の実践による組込みソフトウェア開発に関する学生の意識変化の検証

撫中達司・佐藤未来子・大江信宏

習（PBL)等の実践的な教育を広く普及させる拠点の形成(enPiT)を進めている 2)3)．東海大学情報通信学部では，組込みシステム技術者の育成を目指して，組込みソフトウェア工学科がその重責を担っている．組込みソフトウェア工学科では，組込みシステムにおいて求められるハードウェ
アとソフトウェアを基礎から応用まで学ぶことを基本方針としており，学生の理解度の向上を目指し実践的カリキュラムとして PBL(Project Based Learning)の実施を重点的に進めている．この中で，社会において組織の中で働く上での基本的な基礎技術力育成を実践するカリキュラムと位置づけている組込みソフトウェア工学実験 1（以降，工学実験 1）を 4 セメスタ（2 年生秋）に開講している．工学実験 1 では，5 人程度でチームを組み，与えられた課題をウォーターフォールモデルに沿って 7 週（計 14 回）の授業でPBL を実践する．授業では，グループ内で各メンバがそれぞれの役割を担い，工程管理を行いプロジェクトを実践することを第一の目的とし，また，ウォーターフォールモデ
ルに基づき要求分析，システム設計，ソフトウェア設計，プログラミング，試験の各工程における仕様書作成を実践し，要求分析やソフトウェア設計などの上流工程の重要性を認識させることを第二の目的としている．学生に提示する課題は，水の入ったペットボトルを乗せた掃除ロボット（Roomba4) ）がペットボトルを倒す事なく所定の時間内で設定されたコースのゴールである充電器にドックインするというものである．ただし，重要視するのは，異常処理を含めて各グループが設定した仕様どおりに動作することであり，高度な要求仕様であることやゴールまでの速さを競争するものではない．
本稿では，PBL の実践として，2018 年 4 月に竣工した実験室（通称 IoT ラボ）を活用した授業内容と，シラバスに記載した意図（身に着ける力）を授業において学生がどのように理解し実践したかについて，授業前後の学生アンケートを用いてその内容を評価し，今後の実践プロジェクトの取組みについての課題について考察する．
以下，第 2 章で，PBL を実践する背景，既存の PBL でのソフトウェア開発に関する関連研究について述べる．第 3章では，工学実験 1 で実施した授業内容を述べ，第 4 章で学生に対して実施したアンケート内容と集計方法につき述べる. 第 5 章では，目的が達成されたかどうか，すなわち学生が授業の意図を理解し，重要性を認識できたかどうかにつき学生の意識の変化をアンケート結果に基づき考察する．最後に第 6 章でまとめを述べる．

2. 関 連 研 究
PBL における学生の評価について，グループではなく個々の学生の達成度やプロセスにおける貢献度についての評価方法につき多くの提案が行われている 5)6)7)8)9)10)．一方，
坪井は PBL において学生の能力を伸長させるためには，苦手なことや過去に経験のないことを実践させることによる効果を示している 11)．また福安らは，PBL の進捗状況を把握し学生にフィードバックを行うことで目標への達成度が向上することを示している 12)．有賀らは PBL の成功・失敗を左右する要因を洗い出し，学生を対象に PBL の成功要因と学習成果を測定するアンケートを作成し，成功要因と学習成果の関連性を定量的に評価している 13)．また菅谷らは，ロボット PBL を学部導入教材として活用し，PBL を通じて実践した実習の感想を学生のアンケート結果としてまとめ，早期の段階から共同して開発を行うことでコミュニケーシ
ョン力の養成に繋がることを示している 14)．
このように，PBL における学習の成果の評価，あるいは学生の成績評価については多くの研究が行われているが，学生が授業を通じて身に着けるべき力，あるいは教員がその授業にて学生に身に着けてほしい力を PBL という方法によって達成できたかどうかという観点で，学生のアンケートに基づく学生の意識の変化について評価した事例はあまりない．
本稿では，ソフトウェア開発を行うための方法の一つであるウォーターフォールモデルを学ぶ中で，特にソフトウ
ェア開発における工程管理，ならびに上流工程である要求分析やプログラム設計の重要性をグループでの実習，PBLを通じて身に着けさせることを目的としており，学生に対して実施したアンケートに基づいて，学習目標の達成度を評価・考察することに加え，PBL を通じた開発の実践によるソフトウェア開発に対する学生の意識の変化につき評価，考察を行う．

3. 工 学 実 験 1 の 授 業 内 容
工学実験 1 は，4 セメスタ（2 年生秋）に開講され，講義と実習を 2 コマ連続で行う授業である．以下，シラバスに記載した本授業の主旨, 内容につき説明する．
3.1 目的
組込みソフトウェアの開発プロセス，特にプロジェクト管理（工程管理，仕様書作成による品質管理）の重要性につき実習を通じて実践的に学ぶ．授業では，数名でチームを組んで，Roomba を使用して与えられた課題につき，以下の手順で各種仕様書を作成しながら開発プロセスを学ぶ．
(1) プロジェクト計画①工程管理表，②メンバ役割分担表(2) ソフトウェア設計③要求仕様書，④プログラム設計書(3) プログラム⑤プログラム（ソースコード）(4) 試験
⑥試験仕様書，⑦試験成績書(5) プロジェクト完了報告⑧プロジェクト完了報告書
3.2 授業で育成する力・スキル(1) プロジェクト管理（工程管理）を実践する力(2) 仕様（要求仕様，プログラム設計，試験設計）を作成
する力(3) ソフトウェア開発を実践する力(4) コミュニケーション能力(5) 自発的に取り組む姿勢・意欲(6) 問題発見・解決能力

― 2 ―
−2−

撫中達司・佐藤未来子・大江信宏

撫中達司・佐藤未来子・大江信宏

Table1 Plan of this class

3.3 学習の到達目標(1) プロジェクト管理（工程管理）方法を理解する(2) ソフトウェア開発プロセスの基本として，仕様書を作成し，その内容に基づきソフトウェアを開発することを理解する(3) 各種仕様（要求仕様，プログラム設計，試験設計）を作成するための手段を理解する
3.4 授業計画，内容
7 週合計 14 回の授業では，1 コマ目の授業で開発プロセスの各ステップでの成果物について説明を実施した後，2 コマ目は各グループで実習を行う形式としている（Table1）．
(1) プロジェクト管理・役割分担：プロジェクトメンバが作業を分担し開発を進める・工程管理：毎回授業の最後に進捗を確認し，遅れている場合にはその対策を作成し次回の授業にて実践する(2) ソフトウェア開発
・ドキュメント作成およびプログラムの開発(Fig.1)
次の各工程(プロセス)を経てソフトウェアを完成させる
A. 要求分析
B. プログラム設計
C. 実装(プログラミング，デバッグ)
D. 試験（動作確認）

RS: Review Sheet

3.5 評価方法
各チームは，提示された課題に対してどこまで実現するかを要求仕様として定義する．評価では，各チームが設定した仕様の難易度ではなく，開発プロセスをしっかりと実践できているかどうか，設定した仕様どおりに開発が進められたかどうかを，レポートとして報告させ，その内容を評価する．具体的には以下の項目を評価対象とする．なお，(1)，(2)はグループで共通，(3)は学生個々の報告となる．
(1) プロジェクト計画に即した開発となっているか
計画した開発工程が守られているかどうか．仮に，遅れが生じた場合にどのような対策を取ったか．
(2) 作成が指示された仕様書について，レビュ内容とその結果を反映した仕様書となっているか．対象となるのは，指定した①～⑧のドキュメント．
(3) プロジェクトで決めた個人の役割が遂行できているか
各自が計画時点で分担とした役割の具体的な実施内容と役割が達成できたかどうかについての考察が記載されているかどうか．
3.6 実習課題
予めペットボトルを載せた Roomba がスタートラインを出発し，設置された杭を回り，スタートラインの延長線上に設定されたゴールを通過する(Fig.2)．なお，水を満タンに入れた 500ml（形状問わず）のペットボトルを Roombaの中央後部に乗せることを条件とし，仕様項目①～⑥の中から選択し，それぞれのチームの仕様を決定する．
① 杭を倒さないこと② ペットボトルを倒さないこと③ Roomba が障害物と接触した場合には，エラー音を発するとともに速やかに停止すること

Fig.1
Table2Target of this class in water-fall model
Details of each step in water-fall model④ CLEAN ボタンを押されたら，LED を光らせ速やかに停止すること⑤ ゴールで BASE（充電器）へドックインすること⑥ ゴールまでの目標タイムは，15 秒以内とすること― 3 ―−3−

PBL の実践による組込みソフトウェア開発に関する学生の意識変化の検証

撫中達司・佐藤未来子・大江信宏

Fig.3

Fig.2

Driving task imposed in this class

4. 学 生 の 意 識 調 査 の た め の ア ン ケ ー ト 内 容 とアンケートの集計方法
4.1 アンケートの内容
学生の意識変化を以下の 3 つの視点から評価する．
1． 育てる力（身に着ける力）
目標として設定した，授業で育成する力・スキルに対する学生の理解度
2． ソフトウェア開発に求められる力
ウォーターフォールモデルに基づくソフトウェア開発プ
ロセスに対する学生の理解度
3． 実施方法の有効性
1，2 を実践する方法として実施した PBL に対する学生の理解度
以下，1 から 3 に対応するアンケート内容につき述べる．
なお，アンケートは授業の開始前（ガイダンス時）と終了後（成果発表後）に実施した．
1. 育てる力（身に着ける力）：(1)アンケート 1：組込みソフトウェア開発を成功させる上で重要と思う力を選択し，その優先順位を付けよ・選択肢：①プロジェクト管理を実践する力，②ソフトウェアを設計・開発する力，③プログラミング能力，④試験設
計能力，⑤自発的に取り組む姿勢・意欲，⑥コミュニケーション力，⑦問題発見・解決する力
2. ソフトウェア開発に求められる力：(2)アンケート 2：組込みソフトウェア開発を成功させる上で重要と思うプロセスを選択し，その優先順位をつけよ
・選択肢：①要求仕様策定，②システム設計，③プログラム設計，④プログラミング，⑤試験設計，⑥試験(3)アンケート 3：組込みソフトウェア開発における技術者に重要と思うものを選択し，その優先順位をつけよ
・選択肢：①プログラミング能力，②人柄，③組込み H/W の専門知識，④コミュニケーション能力，⑤仕様書作成力，⑥語学力（英語），⑦アプリケーションの知識，⑧マネー
ジメント能力，⑨業務知識
3. 実施方法の有効性：(4)アンケート 4：ソフトウェア開発を学ぶ上で，有効と思われる手段を選択し，その優先順位を付けよ・選択肢：①講義，②講義＋個人実習，③講義＋グループ実習，④講義＋PBL の実習，⑤コンテスト

Roles of students in this class

4.2 アンケート結果のまとめ方
授業では，予め提示するサンプルプログラム（C 言語）を参考にして，各チームが策定した仕様に基づき修正して動作させる．このため，3 セメスタまでにプログラミングを含む以下の科目を受講することを推奨している．なお，
プログラミング入門と組込みソフトウェア基礎実験のみが必須科目である．
・プログラミング入門（1 セメスタ）
・プログラミング応用（2 セメスタ）
・データ構造とアルゴリズム（3 セメスタ）
・組込みソフトウェア基礎実験（3 セメスタ）
今回のアンケート結果から学生の意識の変化を読み取り，評価・考察を行うにあたり，上記 4 科目の成績をもとに，3 つのグループに分け，その内上位 A グループ，中位 B グ
ループのアンケート結果により考察を行うこととする．理由として，上記科目の成績にある程度相関して学生の目的意識が異なると考えられ，このためアンケートの結果を同一のレベルとして扱うことは学生の意識の変化が捉えにくい可能性があること，また C グループについては回収したアンケートの記載内容に不備が多く，評価に含めることが適切ではないと判断したことによる．なお，3 つのグルー
プは，4 科目の平均 GPA をもとに分類した．各年度のそれ
ぞれのグループの割合はおおよそ A グループが 30％，B グ
ループが 25％，C グループが 45％となっており，4 年間を通じて大きな差異がないことを確認している．
また，PBL を実践する中で，各学生の役割分担を予め決め，その役割を担うために何を行うべきか考えることも重要な点と考え，以下の役割分担を設定した．
・プロジェクト管理担当（プロジェクトリーダ）
・要求仕様担当
・プログラム設計担当
・プログラム担当
・試験設計・試験実施担当
Fig.3 は A，B それぞれのグループメンバの役割分担についてまとめたものである．結果として，A，B それぞれのグループで役割分担に偏りはなく，評価における差異の要因とはならないことを確認した．

― 4 ―
−4−

撫中達司・佐藤未来子・大江信宏

撫中達司・佐藤未来子・大江信宏

5. 検 証 結 果 と 考 察
以下，アンケートの結果と，その結果に対する検証，考察を行う．なお，各グラフは左側が授業前のアンケート結果，右側が授業後のアンケート結果を示している．また，Fig.4，6，8，10 に各アンケートに対する学生全体のアンケート結果を示し，Fig.5，7，9，11 に A，B グループ毎のアンケート結果を示す.
5.1 育てる力（身に着ける力）：
目標として設定した授業で育成する力・スキルに対する学生の理解度
アンケート 1：育てる力として掲げた 7 項目の授業前後の差異は以下である(Fig.4)．なお，矢印→の左が授業前の回答数，右が授業後の回答数であり，その差異を％で示している．
① プロジェクト管理を実践
68→65
-4%
② ソフトウェアの設計・開発
48→51
+6%
③ プログラミング能力
23→33
+43%
④ 試験設計能力
9→14+55%⑤ 自発的に取り組む姿勢
64→55-15%⑥ コミュニケーション力
68→59-15%⑦ 問題発見・解決する力
32→32
±0%
本授業で意図した力に対応する①プロジェクト管理の実
践，②ソフトウェアの設計・開発については授業前後で大きな変化はないものの，他の項目に比べて大きな割合を占めており，身に着けて欲しい力という意図は学生に十分認識されたものと判断する．
なお，③プログラミング能力と④試験設計能力は全体に占める割合は低いものの，授業前後で約 50％増となっており，学生自身が足りないと感じた能力という結果となった．
プログラミング能力については与えられた演習を解く形式
であるプログラミング入門や応用は基本的な知識に留まり，今回の課題のような仕様を満たすプログラミング能力との差異を実感したものだと考えられる．また試験設計については作成した仕様どおりに動作するという確認試験をする
こと自体が初めてであり，その必要性を感じた結果であると考えられる．
次に A，B グループ毎の結果につき考察する．Fig.5 の上段が A グループの結果であるが，A グループは授業開始前から本授業で意図する①プロジェクト管理，②ソフトウェアの設計・開発の重要性を認識しており，特に①プロジェクト管理を 1 位とした学生が増加していることからもそのことが読み取れる．また，基本的に意識の高い学生が A グループに多く属しているためか，⑤自発的に取り組む姿勢，⑥コミュニケーション力については，授業前後で大きな変化はない．一方，B グループでは，②ソフトウェアの設計・開発が 23％増となっており，この点での意識変化が著しい．
また①プロジェクト管理の実践を 1 位とした学生も A グループと同様に増加しており，意図は十分理解されたと判断できる．なお，B グループの特徴として，⑥コミュニケーション力の重要性を持って望んだが，実際のプロジェクトを遂行する上で，これだけではプロジェクトは進捗せず，③プログラミング能力に加えて②ソフトウェアの設計・開発力の必要性を実感したというのが，A グループと異なる傾向といえる．

Fig.4

Fig.5

Skills that students need to learn

Details of skills that students need to learn

5.2 ソフトウェア開発に求められる力：
ウォーターフォールモデルに基づくソフトウェア開発プロ
セスに対する学生の理解度
アンケート 2：
① 要求仕様策定
93→89-4%② システム設計
91→88-3%③ プログラム設計
83→83±0%④ プログラミング
21→32+52%⑤ 試験設計13→14+8%⑥ 試験
10→6-40%
Fig.6 は，開発プロセスにおいて重要と考える項目についての結果である．授業前後で大きな差となったのは 52%増加した④プログラミングであり，一方で⑥試験は 40%減少している．今回の授業では予め決定した仕様どおりに動作することが確認できたチームは全体の 1/2 程度であり，多くのチームはプログラミングに苦労していたことが要因の一つであると考えられる．また，工程上最も下位に位置する試験までは十分な時間が取れなかったという点から試験に対する認識が十分できていないという結果と判断する．
次にグループ毎の結果として A グループは，開発プロセスにおける上流①，②，③での品質の作り込みの重要性を認識しており，授業によりその優先度①，②，③についてしっかりと認識を持ったものと判断できる．B グループは，― 5 ―−5−PBL の実践による組込みソフトウェア開発に関する学生の意識変化の検証

撫中達司・佐藤未来子・大江信宏

Fig.6

Students' understanding of softwaredevelopment

Fig.7

Details of students' understanding ofsoftware development

Fig.8

Technologies required for embedded softwaredevelopment

Fig.9

開発プロセスにおける上流①，②，③での品質の作り込みの重要性を認識していたが，本授業により，上流での設計ではなく，プログラミングの必要性を認識したこと（67％増）が見てとれる．これは，先に述べたように目標とした仕様が多くのチームで達成できなかった結果において，Aグループに比べてプログラミング能力が十分ではない学生が B グループに多いことがその理由の一つとして考えらえる（Fig.7）．
アンケート 3：
① プログラミング能力
62→56-10%
② 人柄
34→26
-7%
③ 組込み HW の専門知識
55→47
-15%
④ コミュニケーション力
46→46±0%⑤ 仕様書作成力
41→46+12%⑥ 語学力（英語）16→16±0%⑦ アプリケーション知識
26→25
-4%
⑧ マネージメント能力
23→30+30%⑨ 業務知識8→17+110%
全体では伸び率が高いのは⑧マネージメント能力であり，次いで⑤仕様書作成力となっており，本授業の目的としていた工程管理，仕様書作成の重要性が認識された結果となった（Fig.8）．なお，①プログラミング能力，③組込み HW

Details of technologies required forembedded software developmentの基礎知識，⑦アプリケーション知識など，個人の能力に関してはすべて減少しており，一方で⑧マネージメント能力は大きく増加している．これは，個々の能力だけではプロジェクトは上手く進まず，グループのメンバがそれぞれの役割を担って開発することの難しさを体験したことでマネージメントの重要性を認識したものであり，PBL の実践による成果だと考える．なお，業務知識が増加している点については，本来の業務知識という意味とは多少異なるが，Roomba についての仕様を把握することの重要性を感じたということを意味していることを別途学生にヒアリングして確認した．
A グループは，授業開始前では①プログラミング能力が最も多かったが，授業後では③組込み H/W の専門知識，⑤仕様書作成能力と①プログラミング能力がほぼ同数となっており，特に本授業の目的の一つとしていた仕様書作成の重要性を認識した結果となった．B グループでは，授業開始前後で①プログラミング能力が最も多く，次いで④コミュニケーション能力，⑤仕様書作成能力という結果となった．B グループメンバは A グループメンバとの技術的な議論において，また仕様書の作成においてコミュニケーションが重要であることを認識したことが結果として現れたのではないかと考えられる（Fig.9）．

― 6 ―
−6−

撫中達司・佐藤未来子・大江信宏

撫中達司・佐藤未来子・大江信宏

Fig.10

PBL の形態を取ることで共同でプロジェクトを進めることの難しさを示す結果となった．なお，グループ実習と PBLの差がないことは，学生が両者の違いを明確に理解しておらず，区別がつかなかった結果であると考えられる．アン
ケートにおける問いにおいて両者の違いをしっかりと提示すべきであり，学生に対する説明不足であったと反省すべき点である．一方，②講義＋個人実習は 10％増という結果となり，プログラミングを含めて一人で課題をこなすことができる学生にとっては，グループあるいは PBL での実習によって得ることよりも負荷の増大などのデメリットな面が表れた結果と考えられる．
また，グループ B においても③，④の傾向は同様である
が，②講義＋個人実習が③，④より若干少なく，自分よりもプログラム開発等の能力の高い学生との共同での取組みにより，単独での実習よりもグループでの実習により得るものが大きいと感じたのではないかと考えられる（Fig.11）．

How to learn software development

6. ま と め

Fig.11

Details of how to learn software development

5.3 実施方法の有効性：
1，2 を実践する方法として実施した PBL に対する学生の理解度
アンケート 4：
① 講義
33→37+12%② 講義＋個人実習
72→78+8%③ 講義＋グループ実習
101→93 -8%④ 講義＋PBL
78→78±0%⑤ コンテスト
28→23-18%
全体では③講義＋グループ実習が 4%減，④講義＋PBL が増減なしという結果となった(Fig.10)．本授業ではグループ実習あるいは PBL を通じてソフトウェア開発の実際を体験し，その有効性を認識して欲しいと願っていたが，グループでの開発の難しさ，工程管理や各種仕様書作成を行いながらのソフトウェア開発の難しさを感じたことは，個人の開発では得られない認識であり，解決が難しい課題ほどプロジェクトでの進め方の難しさ，重要性を感じたと判断することもでき，学生のアンケート結果に直接的な効果は表れていないが，PBL による学習の成果であると考える．
グループ A は，③講義＋グループ実習，④講義＋PBL が有効と考えた割合は，それぞれ授業前後で 11％減，7％減という結果となり，ひとりであれば目標とした結果まで到達することができる能力を有する学生も，グループ実習，

本稿では，プロジェクトを成功させる上で重要なプロジ
ェクト管理や，ソフトウェア開発での品質を確保するために実践されるウォーターフォールモデルを PBL を通じて学生が学ぶことを目的として実施した内容につき，学生のアンケート結果をもとにその目的が達成されたかどうかを評価した．結果として，ソフトウェア開発においてはプロジ
ェクト管理，ウォーターフォールモデルの上流工程の重要性について学生が一定の認識を持ってくれたことが確認され，授業の目的は達成されたものと判断した．また，グループのメンバが協力し，それぞれの役割を担って開発することの難しさを体験したことでマネージメントの重要性を認識したことは PBL の実践による成果だと考える．加えて，PBL を実践する中で，解決が難しい課題ほどプロジェクトでの進め方の難しさ，重要性を感じたことも PBL による学習の成果と考える．
今後は，教材のさらなる改良を行うことに加えて，PBL によるワークの進め方についてもしっかりと実践させる必要性を改めて認識した.
なお，本論文で用いたアンケート結果は，卒業生については Web ページを用いて，また在校生についてはキャンパスライフエンジンの掲示板を用いて，対象とした学生全員から利用につき許諾を得ている．また，学生によるアンケート結果を研究成果に利用し，本紀要にて開示することについては，東海大学「人を対象とする研究」に関する倫理委員会により承認を得ている．

参考文献
1)

Reference Architectural Model Industrie4.0(RAMI4.0)，
https://www.plattformi40.de/PI40/Redaktion/EN/Downloa
ds/Publikation/rami40-an-introduction.html(最終閲覧日2020年9月)

2)

文部科学省，平成28年度大学教育再生戦略推進費，“成長分
野を支 える 情 報技術 人材 の 育成拠 点の 形 成(enPiT)公募要領”，2017年

3)“ 高 度 ICT 人 材 育 成 の た め の 実 践 的 教 育 と し て の PBL” ，(社)日本経済団体連合会 情報通信委員会，2009年― 7 ―−7−

PBL の実践による組込みソフトウェア開発に関する学生の意識変化の検証

撫中達司・佐藤未来子・大江信宏

4)iRobot, https://www.irobot-jp.com（最終閲覧日

10)2020 年

9 月）
5)

大 学 産 業 技 術 研 究 科 情 報 ア ー キ テ ク チ ャ 専 攻 Web 版
InfoPress，2016年

原，八重樫，橋浦，小宮，“PBL参加者の成績の評価方法 11)

課題達成への貢献度を反映した，参加者ごとに異なる成績を済大学地域政策学会），第17巻第3号，pp.45-57，2015年と教育，vol.2010-CE-103 No.19，2010年

7)

12)

小方，“プロジェクト型学習における相互評価とその妥当性担を考慮したソフトウェア開発PBLの評価基準と状況把握支

2013年

援”， 電子情報通信学会論文誌， Vol.J98-D No.1， pp.117-

土井，東田，重井，小幡，“プロジェクト活動に基づく学習

129，2015年
13)

手法に対するいくつかの評価手法の提案とその実践”，日本

有賀，尾崎，広瀬，“PBLにおける成功要因と学習成果の定
量 的 分 析 ” ， 教 育 シ ス テ ム 情 報 学 会 ， 第 40回 全 国 大 会 ，
pp.347-348，2015年

上田，合田，根本，鈴木，“Project Based Learningにおけ14)る学習評価手法の動向と特徴”，日本教育工学会第27回全国
9)

福安，井垣，佐伯，水谷，柗本，楠本，“チーム内の役割分の検証”，日本ロボット学会誌 vol.21，No.2，p.140-146，

ロボット学会誌，vol.31，No.2，pp.181-186，2013年
8)

坪井，“ゼミ活動を通じたPBL実践の効果と課題 -学生の能力の伸長という点からの考察-”，地域政策研究会（高崎経

導く方法の提案-”，情報処理学会研究報告，コンピュータ
6)“PBL:Project Based Learning(評価編)”，産業技術大学院

菅谷，谷田川，杉本，“分野を超えたものづくりと教育 -組

大会，3a-107-01，pp.677-678，2011年

込みシステム開発教育のためのロボットチャレンジ-：8．ロ

日戸，伊藤，大場，“能力成熟度モデル統合に基づいたPBL

ボットPBLを学部導入教材として活用する -授業における事における定量的学習評価手法の提案”，日本ソフトウェア科

例報告-”，情報処理，56(01)，pp.74-76，2014年

学会第34回大会，2017年― 8 ―−8−