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

アジャイルソフトウェア開発 PBL における形成的アセスメントの効果測定
日戸 直紘伊藤 恵

大場 みち子多くの情報系大学において，Project-Based Learning(PBL) が広く取り入れられ，その有効性や実践例が多数報告されている．ソフトウェア開発を行う PBL では，Scrum に代表されるアジャイル開発方法論を採り入れる大学が増加している．Scrum では，透明性・検査・適応の実践が求められるが，開発・マネジメント経験の少ない学生が透明性の確立，プロジェクトを検査・適応する難易度は高い．また，講義設計や学びの状況，質を改善するには，学習途中でそこまでの成果や達成度を把握し，学習を促す形成的な評価・アセスメントを行うのが望ましい．しかし，教育者が PBL 専任でない場合や，学生が時間外にも活動するなど，形成的な評価を行うには多くの課題がある．これらの課題解決を目指し，プロセスを評価し改善するモデルである能力成熟度モデル統合 (CMMI) に着目した．本稿
では，筆者らが提案する CMMI に基づいた，プロジェクト状況を検査可能な評価手法に対し，PBL における形成的アセスメント効果の検証について報告する．

Project-Based Learning (PBL) has been widely adopted in many information-oriented universities and its
eﬀectiveness and practical examples have been reported. In PBL that develops software, there are an
increasing number of universities that adopt the Agile development methodology represented by Scrum.
Although Scrum requires the practice of transparency, inspection, and adaptation, it is highly diﬃcult for
students with a little development and management experience to establish transparency and inspect andadapt projects. In addition in order to improve the situation and quality of lecture design and learning it
is desirable to grasp the results and achievement so far during learning and to carry out formative evaluation and assessment that encourage learning. However, there are many problems in performing formativeevaluation such as when each educator is not full-time PBL or overtime activities. In order to solve theseproblems, we focused on the Cability Maturity Model Integration (CMMI), which is a model to evaluate
and improve the software process. In this paper we report the eﬀectiveness of formative assessment in PBL
using the evaluation method that can inspect our proposed the project situation based on CMMI.

解決に向け主体的 (あるいは能動的) に取り組む実践

1 はじめに的な授業法である．座学等で学んだ体系的知識の定着

文部科学省は，IT 人材の不足が今後一層深刻化すと利活用への効果も期待されており，より良い教授法る可能性が高いなどから，高度 IT 人材の育成を日本を目指し試行錯誤が繰り返されている．の極めて重要な課題としている [1]．高等教育機関にソフトウェア開発を目的とするソフトウェア開発

おいて高度 IT 人材の育成が求められる背景のなかPBL では，社会のニーズや課題，IoT などの要素技で，Project-Based Learning(PBL) が注目されてい術を掛け合わせ，学生がアイディア・実装・検証を繰る．PBL とは課題解決型学習を指し，学習者が課題り返し，成果物を生み出し，成果報告会を行うといった流れが一般的である．そのソフトウェア開発 PBL

Eﬀects of Formative Assessment in Agile Software Development PBL
Naohiro Hinoto, 公立はこだて未来大学 システム情報科
学研究科, Graduate School of Systems Information
Science, Future University Hakodate.
Kei Ito and Michiko Oba, 公立はこだて未来大学, Future
University Hakodate.に，アジャイル開発方法論を採り入れる大学が増加している (以下，アジャイルソフトウェア開発 PBL)．
筆者らの調査によると，アジャイルソフトウェア開発

PBL を実施している大学のうち，9 割が Scrum [2] を導入していることがわかった．

Scrum はプロダクトを開発・提供・保守するためとした定量的な評価手法を提案する．のフレームワークであり，可能な限り価値の高いプロ

PBL 実施中の学生が行うプロセスの継続的な評

ダクトを生産的かつ創造的に届けるためのものであ価方法が求められることから，筆者らは，Cabilityる [2]．Scrum において，透明性・検査・適応の 3 本Maturity Model Integration (CMMI) [8] [9] に着目し，柱は非常に重要な軸となっており，経験的プロセス制CMMI のいくつかの領域と独自に開発した領域を用御の実現を支えている．経験的プロセス制御とは，経いた評価手法を開発した．

験主義とも言い，実際の経験と既知に基づく判断に

本稿では以降，2 章で公立はこだて未来大学におけよって知識が獲得できるというものである [2]．そのる複数の PBL に関する特徴について述べ，3 章ではため，経験や知識が乏しい学生自身が主体となって学CMMI について概説する．4 章では筆者らが提案すぶ PBL において，Scrum の導入，3 本柱の実現は難る評価手法について述べ，5 章で PBL での実験につ易度が高い側面を持ち合わせている．加えて，アジャいて述べる．6 章では Communication Tool の可視

イル開発経験の無い教員が多いことや，アジャイル開化について述べ，7 章では実践結果について分析・考発を教える講義が無いなどからコーチングが難しい察していく．8 章では本研究の結論と今後の課題につといった教育者側の課題も考えられる．

いて述べ，まとめる．

実践的な教育を実施する情報技術人材育成のための実践教育ネットワーク形成事業 (通称：enPiT) [3]2 公立はこだて未来大 PBL の特徴

では，これらの課題をフォローアップする取り組みを

2 章では，公立はこだて未来大学 (以下，未来大) に行っている大学も存在する．enPiT の一部大学では，おける複数の PBL に関する特徴について述べる．

アジャイル開発導入のコーチングを行っているアジャ未来大では，開学初期から講義カリキュラムに PBL

イルコーチ [4] などの企業人らと協力し，独自のカリを採り入れ，コース・分野を超え，様々な内容の PBLキュラムや合宿を設計している．しかし，PBL チーを実践してきた．学部 3 年次に開講される全学科必ム数の多さや予算などのコスト面における課題などか

修の PBL であるシステム情報科学実習の他に，全学ら，一部の高等教育機関のみの実施に留まっており，年参加可能な高度 ICT 演習と呼ばれる単位認定の無実施している enPiT 参画大学も enPiT の予算次第でい自由参加型の PBL を行っている．

は実施が難しくなる可能性が高いのが現状である．

PBL の学習評価，特にプロセス (活動そのもの) の以降，システム情報科学実習と高度 ICT 演習の概要について解説する．

評価を適切に実施することは困難であると多数報告されており [5] [6] [7]，PBL の学習評価は PBL 運営の

2. 1 システム情報科学実習の概要一つの課題となっている．PBL の担当教員は，専任システム情報科学実習 (通称：プロジェクト学習)

ではなく通常の教員業務との兼任の場合が多く，学生は，未来大の学部 3 年次の全コースに開講されていは講義時間外に活動することも多いため，常に学習者る必修通年型の PBL である．本 PBL では，情報シを観測することは難しい．先のアジャイルソフトウェ

ステムコース・高度 ICT コース・情報デザインコー

ア開発 PBL の課題から，講義改善のための評価 (形ス・知能システムコース・複雑系コースの垣根を超え成的評価) を定量的に行うのは非常に重要であるが，たコース混合の学生によって，プロジェクトを構成PBL 評価の課題なども踏まえて考えると実施自体のされている．毎年 20〜30 プロジェクトが開講され，困難性や教育者の負担が大きいなどの課題も重なり

1 プロジェクトあたり 10〜15 名程度の学生が参加す実現が難しい．

る．毎週水・金曜日の 4・5 限 (14:50〜18:00) が講義

本研究では，アジャイルソフトウェア開発 PBL を時間に設定されており，ソフトウェアだけでなくハー実践する学生の学び，Scrum 導入の支援および講義ドウェアやワークショップ等のイベント企画など様々指導，カリキュラム改善などの複数の課題解決を目的なテーマに 1 年間取り組む．ゴールとして，成果報告書の作成や学内向け成果発表会のほか，企業や自治動や企業への導入が進んでいないことから，事実上の体向けに成果を報告・発表するプロジェクトも多く，デファクトスタンダードとなっているのは V1.3 であ未来大の特徴的な演習科目となっている．

る．そのため本研究では，CMMI-V1.3 を利用する．

2. 2 高度 ICT 演習の概要

3. 2 プロセス領域

高度 ICT 演習は，実社会の課題やニーズを理解し，CMMI には，各活動内容に応じて分類されたプロ問題解決につなげるシステムの提案から実装までをセス領域と呼ばれる分類が存在し，CMMI-V1.3 では行う単位認定のない自由参加型の演習である．本演習

22 のプロセス領域が定義されている．22 のプロセス

は，学部生・大学院生を交えた学年・コースの壁がな

領域は 4 つの「区分」に分けられており，重複はない学年混成型 PBL であり，学部 1 年生から修士 2 年い．
「区分」は，組織および組織内のプロジェクトが生まで様々な学年・コースの学生がプロジェクトを組実施する活動内容を「プロセス管理」・「プロジェクトみ活動している．演習のテーマは，学生が主体となり管理」
・「エンジニアリング」
・「支援」の 4 つに分類し学生自らがテーマ提案を行っており，年度を超えた継たものを示している．

続テーマに取り組むプロジェクト・学生も多い．

22 のプロセス領域の中には，リスク分析やプロジェクトのコスト (金銭等) 管理など，PBL には不要もし3 CMMI の概要

くは適さない領域も存在する．そのため，CMMI を3 章では，筆者らが着目した CMMI(Capability

評価手法に活用する場合には，プロジェクトに応じてMaturity Model Integration) について概説し，本適切な領域を選択する必要がある．

研究で扱うプロセス領域について述べる．その後，CMMI における評価について述べていく．

3. 3 CMMI における評価

企業におけるソフトウェア開発では，品質・生産性

CMMI を用いて企業やプロジェクトを評価する際の向上，工期短縮を目的とした，プロセス評価・改善は，CMMI アプレイザーと呼ばれる評価を行う専門活動が盛んに行われている．プロセス評価・改善活動

家 (もしくはチーム) が評価を行う．アプレイザーは，とは，組織やプロジェクトの有効性を評価し，様々な外部かつ認定を受けた者が行うことで，評価への信頼情報を総合的に分析することでプロセス改善に有効な性や妥当性，客観性を担保している．

策を展開していく活動のことである．プロセス評価を行うための業界標準とされる CMMI は，米国・中国・インドを中心に世界の多くの企業が採用している．
以下，CMMI について述べていく．

4 効果測定手法の概要
4 章では，3 章で概説した CMMI に基づいた PBLのアセスメント効果を測定するための手法について述べていく．

3. 1 Cability Maturity Model Integration
CMMI の前身である CMM(Capability Maturity

4. 1 対象領域と独自開発領域

Model) は，1989 年にソフトウェア開発の企業を客観

3 章で解説したように，CMMI はプロジェクトの的に評価できる指標として，米国国防総省とカーネギ

管理活動から実装，テスト，トレーニング (教育) な

メロン大学 (CMU) により設立されたソフトウェア工ど幅広い活動をカバーしている．そのため，学生が主学研究所 (SEI) によって誕生した．現在は，複数の改体的に学ぶ PBL に適さない領域が複数あると考えら

善モデルや知見を加えながら，能力成熟度モデル統合れる．

(CMMI) となった．CMMI は，現在も CMU/SEI で本提案手法では CMMI の 5 領域と独自に開発した開発・管理されており，2019 年 8 月現在の最新バー

1 領域の計 6 領域を選定・開発し，評価を行っていく．

ジョンは，CMMI-V2.0 である [10]．しかし，翻訳活選定した 5 領域は，プロジェクトに必要なデータ収

集・分析，定期的なスケジュール等の計画・確認，プ評価可能であり，できる限り客観性/妥当性を持たせロセス実施の評価などの領域を中心に選定した．

るため，各プロセス領域/評価項目に対して，ルーブ

表 1 は，これら 6 領域の CMMI における区分，プリックを開発する．

ロセス領域名，選定理由についてまとめたものであ

ルーブリックを活用して，PBL 受講者 (学生) が一る．以降，各領域を表 1 に記載された領域 A〜F で定期間 (Scrum ではスプリント) ごとに評価を行うこ表記する．とで，図 1 のように，学びの形成過程や課題箇所，成長などを自己評価できると考えた．

表1

対象領域と独自領域の名称と選定理由

図1

学びの計測・評価

CMMI は Agile/Scrum との親和性は高い一方で，各領域にそれらを評価する要素が分散していること

ルーブリックの評価項目は，CMMI の各プロセスや，Scrum のロール (役割)・イベントなどの直接的領域に存在する項目に準拠し，評価基準において専門な項目は存在しない．そこで，“Scrum 遵守”の領域的な単語や表現をできる限り避けることで，CMMIとして Scrum Guide [2] に記載されたロール・イベンの知識がない学生でも評価可能なルーブリックを目指

ト等の遵守に関する独自領域を開発した．

した．
また，評価点は 4 段階評価 (Lv.0 〜 Lv.3) とし，評4. 2 ルーブリックの開発

価結果をわかりやすくするため，以下の通り，%へ置

本来の CMMI はアプレイザーが評価を行うのに対き換えることとした．

し，本手法では学生が主体的に学ぶという PBL の観

Lv.0 ： 0%点から，学生自身が評価を行うことを想定している．

Lv.1 ： 33%

学生が自分たちの力で評価/改善を行うことで，プロLv.2 ： 66%

セス改善・アセスメントの過程も学びに繋げていける

Lv.3 ： 100%と考えたためである．
学生が自己評価を行う課題として，主に以下が挙げられる．

各プロセス領域には，複数の評価項目が存在する．
全プロセス領域合計で 50 項目以上存在するため，分析や評価を行いやすいようにプロセス領域ごとの評

客観性 客観的に自分たちを分析/評価できない価を算出する必要がある．そこで，プロセス領域に含妥当性 評価結果に理由/根拠がない (過大もしくまれる評価項目の%の相加平均をそのプロセス領域のは過小評価)
知識 CMMI に関する知識がを持っていない
これらの課題から，CMMI の知識がない学生でも評価結果 (0〜100%) とすることで，評価結果・改善効果がわかりやすいように定義・算出した．
ルーブリックは可能な限り，客観性を保持する評価方法であるが，評価者が学生のため客観性や妥当クトを進めている．プロジェクト内に 3 サービスが性には少し疑問が残る．そこで，日々の活動を可視設置されており，さらに各サービスが 4 開発チーム化することにより，客観的な情報からも評価していにわかれているため，計 12 チーム (4 開発チーム× 3くこととした．なお本稿では，PBL で利用されていサービス) を実験対象とした．

る Communication Tool を対象に日々の活動 (プロセ

5. 1. 2 FinTech プロジェクト

ス) を捉えていく．

FinTech プロジェクトは，高度 ICT 演習にて 2017度発足された，学内向け仮想通貨を企画・開発するプ

5 PBL における実験ロジェクトである．プロジェクトは，R&D チームと本評価手法を用いることでプロジェクトを評価可応用開発チームの 2 チームで構成されている．R&D

能か検証するため，進行中の PBL を対象に実験をチームはブロックチェーンを含めた仮想通貨そのもの行った．

を開発，応用開発チームは仮想通貨を利用する際の取各スプリントのふりかえり (スプリントレトロスペ引所の様な役割を果たす仮想通貨アプリを開発してクティブ) に加えて，提案手法による評価を実施している．本実験では，Scrum を取り入れている応用開もらった．手順は以下の通りである．

発チームを実験対象としている．応用開発チームはさ1. ルーブリックが記載された評価シート

らに 6 チームに細分化されており，全 6 チーム計 12(Google Spreadsheet) を参照しながらの評価名を対象とした．学部 1 年生 2 名，学部 2 年生 5 名，

2. 各評価項目に対し，自分たちがどのレベルに当学部 3 年生 5 名が混成しており，多学年 PBL となってはまるのかルーブリックを基に議論ている．

3. 当てはまるレベルを Lv.0〜3 から選択
4. 手順 2〜3 を全評価項目分実施

5. 2 評価結果

5. 必要に応じて評価結果を振り返りに活用

システム情報科学実習のミライケータイプロジェク

これらの手順をスプリントごとに 1 度，チームごと

ト，高度 ICT 演習の FinTech プロジェクトにおいてに実施してもらうことで，プロセス/形成的アセスメ実施した提案手法による評価結果を各領域/スプリンントの評価を行っていく．

トごとに示す．

5. 2. 1 ミライケータイプロジェクト
5. 1 実験対象プロジェクト

チーム数が多い関係上，システム情報科学実習の実験対象は，2 プロジェクト 18 チーム，計 50 名

評価結果は，4 チームの平均値を各サービスの評価結とし，プロジェクト活動期間のうち開発期間である果として，Service1〜3 に示した．1 スプリント/2 週

2018 年 10 月〜12 月の 3ヶ月間実施した．

間であることや，開発期間/プロジェクト計画上の理5. 1. 1 ミライケータイプロジェクト

由から，3 スプリント分のみの計測となった (図 2〜ミライケータイプロジェクトは，システム情報科学図 7)．各図の縦軸は評価の点数 (%) スプリント，横実習の 1 プロジェクトであり，数年後当たり前となっ軸はスプリントを表している．ているサービスを想定したアプリケーション開発を

5. 2. 2 高度 ICT 演習通して，企画から開発，ビジネスモデルを企業へ提6 開発チームの評価結果を Team A 〜 Team F と案をする実践的な開発プロジェクトである [11]．毎年して示した．FinTech プロジェクトでは，1 スプリ新たなサービスを企画・開発しており，その規模は連ント/1 週間のため，システム情報科学実習と同様の携大学もあわせ 40 名前後にも及び，PBL としては，期間である 6 スプリント分の計測を行った (図 8〜図大規模なプロジェクトである．

13)．各図の縦軸は評価の点数 (%) スプリント，横軸

2018 年度は，学部 3 年生計 38 名がプロジェクトに参画しており，Scrum 手法を取り入れ，プロジェはスプリントを表している．

図2

図3

図4

“scrum 遵守”領域の評価結果

図5“プロジェクト計画策定”領域の評価結果“プロセスと成果物の品質保証”領域の評価結果

図6

図7“検証”領域の評価結果“測定と分析”領域の評価結果“プロジェクトの監視と制御”領域の評価結果

主にチーム活動で用いられる Communication Tool

6 Communication Tool の可視化

でビジネスに必要な機能が多数備わっており，多くのPBL で利用されている Communication Tool の企業や PBL で利用されている．

log を可視化することによって，評価データをより客観的かつ詳細に分析できると考えた．

6. 1 可視化システム

実験対象の 2 プロジェクトで最も活発に利用され可視化ツールには，Microsoft 社の Power BI [13] をていた Slack [12] を可視化の対象とした．Slack とは，使用し，CData 社の Rest Driver [14] を用いた．Slack

図8

図9

図 10

“Scrum 遵守”領域の評価結果

図 11“プロジェクト計画策定”領域の評価結果“プロセスと成果物の品質保証”領域の評価結果

図 12

図 13

“検証”領域の評価結果“測定と分析”領域の評価結果“プロジェクトの監視と制御”領域の評価結果

は Web API を公開しており，リアルタイムなデータ

6. 2 Slack-log の可視化を取得することが可能である．システム構成は図 14

FinTech プロジェクトでは，実験対象チーム以外のの通りである．

チームも同 Slack(ワークスペース) に参加しているこ

Slack では，User・Channel ごとの投稿数や共有とから，正確な分析が行えないと判断した．一方で，ファイル数，投稿時間などを Web API から取得できミライケータイプロジェクトの 3 サービスは，独立る．それらを Power BI をつかって，可視化することした個々の Slack(ワークスペース) を利用しており分で，より分析を容易にしていく，今回は JSON 形式

析に適していると考え，可視化対象とした．特に評価の Slack-log を SQL 形式に変換してくれることから，結果の中で，特徴のある部分の Slack-log を可視化す

CData Rest Driver を利用した．

ることにより，客観的かつ定量的なデータから評価結果を分析していく．

たチームであり，開発経験が少ないのにくわえ，これが初めてのチーム開発となる．開発未経験からチーム開発を経験し，自分たちを客観的に分析する能力が向上したことや，周りの上級生のチームから良いところを吸収する力が高かったことから，数値の変動が大きかったと推測できる．また，同プロジェクト内に学部
図 14

Slack の情報可視化システムの構成

4 年生以上のチームメンバーがいたこと，スプリントの回数がミライケータイプロジェクトよりも多かった
ことも数値が高い要因であると考えられる．

7 分析、考察ミライケータイ/Service3 は，主な開発が実験期間

7. 1 全プロセス領域の相加平均値の変動外で行われていたことや，スプリント数が少なく，改図 15 と図 16 は，全プロセス領域の相加平均値を善のタイミングが少なかったことが改善効果が低くプロジェクト/チーム別にスプリントごとに算出したなってしまった要因であると考えられる．

グラフである．

7. 2 各プロセス領域の数値変動
プロセス領域ごとの評価データである図 2〜図 13をみていくと，プロジェクトごとに改善効果・評価数値の高い領域が異なっていることがわかった．

7. 2. 1 ミライケータイプロジェクト
ミライケータイプロジェクトでは，3 サービスの平均が最も高い改善効果・評価数値を示したのはプロ
ジェクトの監視と制御，最も高い評価結果となったのは，Service3 のプロジェクト計画策定だった．これ
図 15

ミライケータイプロジェクトの相加平均値の推移

は，遠隔で開発を行うプロジェクトであることから、遠隔間の進捗や状況の把握をより求め，成熟度を向上させたことが要因であると考えられる．
マネジメントに関する領域が重点的に改善されており，マネジメントを意識したプロセスを形成していたことがわかった．

7. 2. 2 FinTech プロジェクト
FinTech プロジェクトでは，Scrum 遵守の領域が最も高い改善効果・評価数値を示したプロセス領域だった．FinTech プロジェクトでは，1 スプリント辺りの期間を短くすることで，ミライケータイプロジェク
図 16

FinTech プロジェクトの相加平均値の推移

トよりも Scrum イベントや改善活動を多く実施していた．そのため，プロジェクトとして，Scrum Guide

図 15・16 より，改善効果が最も高かったのは，Fin-に記載されたルールやイベントに対する意識が高まっ

Tech/TeamB で 65.3%，最も低かったのは，ミライていたことから，改善効果・評価数値高かったと考えケータイ/Service3 の 23.8%であった．

られる．

FinTech の TeamB は，主に学部 1 年生で構成され

7. 3 評価データと可視化情報

図 18 は，Service2 の Slack-log から，Channels ご

図 17 は，ミライケータイプロジェクト/Service2とのメッセージ数の推移について，日付ごとに可視化の各プロセス領域の評価結果をスプリントごとにグしたものである．縦軸は発言 (投稿) 数，横軸は日付ラフ化したものである．縦軸は評価結果 (%)，横軸はを表している．1st スプリントと 2nd スプリントを比スプリントを表している．領域の A〜F は，表 1 と較すると，チャンネル数が急激に増加していることが対応しており，領域 C/D が全て同値だったため，合わかる．また，2nd スプリントと 3rd スプリントを比わせて表記している．

較すると，チャンネル数が落ち着き，いくつかのチャンネルで活発なメッセージのやりとりをしていることがわかる．

2nd スプリントでチャンネル作成のルールや区別などを決めずに急激に Channel 数が増加したことで，統制が取れず透明性が下がり，全体の状況把握が困難だった可能性が高い．これらの理由から，プロジェク
トの監視と制御の評価結果に変動がみられたことがわかった．

Slack などの Communication Tool を可視化することにより，評価データや報告書などからはわからな
図 17

Service2-各プロセス領域の評価結果

いプロセス形成，学生によるアセスメント効果についての分析が可能であることがわかった．

Service2 の領域 B は，ミライケータイプロジェク
トのうち，唯一評価結果が一度下降し，再度上昇し8 おわりにているプロセス領域である．領域 B は，プロジェク

本研究では，アジャイルソフトウェア開発 PBL をトの監視と制御の領域であり，2nd スプリントで下降実践する学生の学び・Scrum 導入の支援および講義し，3rd スプリントで再度数値が上昇していることが指導，カリキュラム改善などの複数の課題解決を目的わかる．とした定量的な評価手法を提案し，実際に行われている PBL に適用した．結果として，学生自身がプロジェクトの状況を検査することができ，それらを活用することでスプリントごとに，形成的なアセスメントを学生自身で行うことができた．また，評価データを Communication Tool の可視化情報と合わせて分析することで，PBL の形成過程であるプロセスを評価できることがわかった．
今後は，教育者からみた形成的アセスメントの効果について，アンケートやヒアリングなどから定性的に検証していく．

図 18

Service2-Channels ごとのメッセージ数の推移

参 考 文 献[ 1 ] 文部科学省:「成長分野を支える情報技術人材の育成拠点の形成（enPiT）」公募要領, pp. 2, 2017.
[ 2 ] Ken Schwaber, Jeﬀ Sutherland: Scrum Guide,
2017, https://www.scrumguides.org/docs/scrumguide/v2017/, <cited:2019.07.28 >.
[ 3 ] 文 部 科 学 省: enPiT 成 長 分 野 を 支 え る 情 報 技術 人 材 の 育 成 拠 点 の 形 成, http://www.enpit.jp/,<cited:2019.07.28 >.
[ 4 ] Rachel Davies(著), Liz Sedley(著), 永瀬美穂 (訳),角征典 (訳) : アジャイルコーチング, オーム社, 2017.
[ 5 ] 大隅智春, 鴻巣努, 関哲朗, 新井浩志, 西尾雅年: プロ
ジェクトベース教育の効果に関する考察, プロジェクト
マネジメント学科研究発表大会予稿集, pp. 179 − 180,1999.
[ 6 ] 本庄加代子: PBL の課題克服に向けたプロジェクト
マネジメント理論の有効性, 東洋学園大学紀要, 25 号,
145-164, 2017.

[ 7 ] 櫻井浩子, 山本雅基, 海上智昭, 小林隆志, 宮地充子,
奥野拓, 粂野文洋, 春名修介, 井上克郎: 情報系大学院生に対する実践教育の効果測定, 65 巻, 1 号, pp.52–57,2017.
[ 8 ] CMU/SEI: CMMI for Development-Version 1.3,Vol.1.3, 2010.
[ 9 ] CMU/SEI and 日本 SPI コンソーシアム CMMI
V1.3 翻訳研究会: 開発のための CMMI 1.3 版, Vol.
1.3, 2010.
[10] CMMI Institute：Introducing CMMI V2.0,2018.
[11] 美馬のゆり: 未来を創る「プロジェクト学習」のデザイン, 公立はこだて未来大学出版, 2018.
[12] Slack: Slack, https://slack.com/,<cited:2019.08.02 >.
[13] Microsoft: Power BI, https://powerbi.microsoft.
com/, <cited:2019.08.02 >.
[14] CData Software Japan: CData Rest, https://www.cdata.com/jp/drivers/rest/,<cited:2019.08.02 >.