関東地区

教育システム情報学会 2018年度学生研究発表会

ソフトウェア開発 PBL 授業における進捗管理手法の提案
A study of progress management method for Software Development
Project-based Learning
山本 美幸*1, 福岡 宏一*1, 清原 良三*2, 寺島 美昭*1
Miyuki YAMAMOTO*1, Koichi FUKUOKA*1, Ryozo KIYOHARA*1, Yoshiaki TERASHIMA*2*1
創価大学工学研究科*1
Graduate School of Engineering, Soka University*2
神奈川工科大学*2
Kanagawa Institute of Technology
Email: e18m5204@soka-u.jp
あらまし：本研究では，ソフトウェアの分散開発を想定した Project Based learning(以下，PBL）型の授業において，開発遅延を解決するための進捗管理手法を提案する．分散開発では，開発チームの学生が独立して開発を進めることで，進捗の情報共有が遅れ，遅延の影響が拡大する恐れがある．そこで，学生に助言をする Teaching Assistant(以下，TA)に着目し，TA の役割を自動化することで，遅延の早期解決を行う．
キーワード：ソフトウェア開発 PBL，TA，非同期情報共有，進捗管理

1.

点が不十分である．

はじめに分散開発を想定したソフトウェア開発の PBL 授業を対象として，開発遅延を早期解決し，開発を円滑にするための進捗管理手法を提案する．
授業の前提は次のとおりである．学生数名がプロジェクトを組み，一つのソフトウェアを開発する．
分散開発を体験する目的があるため，対面での開発は原則行わず，独立して開発する．また，プロジェクト開始時に，計画書を作成する．計画書には，作業ごとに余裕日を設け，一週間で行う作業を一作業と決める．開発進捗は，定期的に進捗報告書を提出することで把握する．プロジェクトの進行状況を監視し，助言を行う役割として，TA が存在する．
対象授業において次の二つの課題が発生する．
[課題 1]開発プロセスの遅延の拡大
各学生の遅延がプロジェクト全体に与える影響がわからないため対処が遅れる．
[課題 2]進捗管理と助言を行う TA の負担
TA は，複数のプロジェクトを監視し，個人の作業遅延に敏感に反応することが困難である．

2.

3.

進捗管理手法プロジェクトの遅延の拡大を防ぎ，TA の負担を軽減することを目的とし，一章で述べた課題に対して次のように対処する．
[解決 1]他学生の状況を考慮した”深刻度”を用いて，遅延がプロジェクトに与える影響を可視化[解決 2]個人の作業遅延に応じた助言を，BOT を用いて自動化し，TA の負担を軽減二点の解決を実現するための手法が進捗管理手法である．提案手法では，非同期情報共有と 3 段階支援モデルで構成される(図 1)．

既存研究

既存研究として，ソフトウェア開発 PBL 関連では，チームの状況に合わせた指導者の評価負担の軽減の，状況把握支援環境のツール開発が行われている(1)．
しかし，指導者の評価負担の軽減だけでは，学生のプロジェクト遅延を軽減することができないため，本研究の想定する授業に適用する場合，学生に助言を行う点が不足している．
TA の負担軽減に関する研究では，プログラミング講義に関して，TA が巡回する際に学生に声をかけやすくする研究(2)がある．しかし，プロジェクト開発では，各学生の遅延がプロジェクトに与える影響を考慮する必要があり，適切なタイミングで助言を行う

37

図 1 分散開発 PBL と進捗管理手法
分散開発に非同期情報共有を取り入れることで，学生の独立した開発を妨げることなく，進捗情報や学生間の議論情報が取得できる．3 段階支援モデル
は，非同期情報を活用し，進捗管理と学生への助言タイミングと内容の判断，を行い，TA の役割を自動化するモデルである．

関東地区

教育システム情報学会 2018年度学生研究発表会

3.1 3 段階支援モデル
3 段階支援モデルは，「監視」「分析」「支援」の 3点からプロジェクトの状況を把握する．第一の監視モデルでは，非同期情報から進捗を管理し，遅延の早期発見を行う．第二の分析モデルは，他の学生の状況を踏まえた個人の遅延を深刻度として計算し，進捗状況を分析する．支援モデルでは，TA-BOT を用いて TA の助言を自動化し，負担を軽減する．
監視モデル
監視モデルでは，非同期情報共有における発言を常時取得し，発言監視を行うことでプロジェクトの遅延を検知する．発言には，開発に関する発言と進捗状況に関する進捗報告の 2 種類がある．
遅延検知には，進捗報告の内容と，開発開始時に学生が決めた計画書を用いる．計画書には，各作業ごとに作業にかかる日数や，担当作業者等の情報が記載されている．進捗報告の報告日を Tn，計画書の作業期限日を Tp，余裕日数を Ts とし，Tn と Tp とを比較し，Ts を下回る場合，遅延と判定する[1] .
（Tp -Tn）> Ts
[1]
分析モデル
分析モデルでは，監視モデルにて出力された遅延作業情報を用いて，作業ごとに遅延による影響を計算し，プロジェクトの深刻状況を分析する．作業単独の遅れだけでなく，他の学生の影響を加味したプロジェクト全体の状況を表すことが目的である．
プロジェクトの深刻状況を表す指標として，”深刻度”を定義する．深刻度の判断は，遅延作業者以外の学生にも遅延の影響があるか，余裕日数がどの程度あるか，遅延原因は何かの 3 点を，余裕日数と結合点との関係を分析して行う．余裕日数とは，各作業に設けられた作業マージンである．結合点とは，作業関連図において作業を取りまとめる地点である．
作業関連図は，学生の作業の流れと関連を表した図である．結合点は，時間順に結合点 C1,結合点 C2,...
結合点 CN と定義する．
深刻な遅延状況に適した助言等の支援を，5 段階の"支援 LEVEL"として定義する．深刻な状況であるほど支援 LEVEL は上がる．余裕日数と結合点の関係から計算される深刻度を入力として，出力される遅延原因と支援 LEVEL を整理したものを表 1 に示す．閾値は開発初期時に TA が設定する．
表 1 深刻度と支援 LEVEL の関係を行うものと，(B)深刻度に応じて支援を行うものの2 種類がある．(A)の支援では，TA に対する質問応答，作業関連図表示，深刻状況グラフ表示(図 2)の 3点がある．

図 2 深刻状況グラフと作業関連図(B)深刻度に応じて行う支援では LEVEL ごとに内容を変え，プロジェクトに対する支援を行う．
LEVEL1，2 の状況では(a)遅延作業者・影響作業者に遅延情報を助言，LEVEL3 では，(b) 遅延作業者に遅延作業の解決策を提示，LEVEL4，5 では，(c)今後の遅延作業予測とプロセス再構築を助言する．
3.2 進捗管理支援システム
進捗管理手法を検証するために進捗管理システムを実装し，動作確認を行った．例として図 3 に，LEVEL3 の支援を示す．表 2 は実装諸元表である．

4.

図3

LEVEL3 の支援

表2

実装諸元表

まとめ

本稿では，ソフトウェア開発 PBL 授業における開発遅延の課題解決を目的とした進捗管理手法を提案した．今後は提案手法の効果を検証するため，進捗管理支援システムを活用し，試行実験を行う．
参考文献(1) 福安直樹, et al. "チーム内の役割分担を考慮したソフ
トウェア開発 PBL の評価基準と状況把握支援." 電子情報通信学会論文誌 D 98.1 (2015): 117-129.
(2) 市村哲, et al. "プログラミング演習授業における学習
状況把握支援の試み." 情報処理学会論文誌 54.12(2013): 2518-2527.

支援モデル
支援の種類は，(A)常時プロジェクトに対して支援38