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

AIIT における実践的 Scrum 技術者教育の取り組み
中鉢 欣秀

ソフトウェア開発手法を学ぶ PBL において，その学習の成果は開発手法を実践できる能力を学習者が獲得できたかどうかである．しかしながら，PBL における学習者の評価の場で，学習者の能力の向上を根拠に基づき判断することは難しかった．そのため，評価しやすい開発したプロダクトの評価をもって代替することが行われる．そこで，こ
こでは学習者が獲得した実践的能力を評価する方法について提案する．学習者は自ら評価基準を設定して評価者に提示し，頻繁な振り返りを通した改善の成果をその評価の根拠とする．本論文では AIIT における実践的 Scrum 技術者教育の取り組みの一環である実際の事例に基づきこの教授法の有用性について論じる．

魅力は乏しくとも，学習者が今後に活かすことのでき

1 はじめにる多くの知恵や知識を身につけたならば，教育の場とソフトウェア開発手法の習得を目的とする学習におしての PBL は学習者にとって価値あるものであった

いて，その教育の成果とは，学習者が自ら学んだ手法と言える．

を実践できる能力の獲得である．すなわち，何らかの換言すれば，例え機能や見た目の出来具合が素晴らソフトウェア開発の方法を学んだことで，ソフトウェしいプロダクトが開発できたとしても，それが何ら体ア開発の現場で遭遇する実際の課題を学習者がより系的なプロセスに従うことなく，締め切り間際に徹夜上手に解決できるようになったのかどうか，というこを続け，体力任せで完成させたものであるならばプロとこそが教育の効果だ．

ジェクトとしては失敗であると評価されてもよい．

近年，実践的なソフトウェア開発手法の習得方法と本研究では，PBL は学習者の学びの場であり，そして PBL（Project Based Learning）が普及してきの評価の対象は学生の成長そのものであるという立た．ところが，一般に PBL の成果として評価される場に立つ．その上で，PBL においてプロダクトではものは，学習者自身の学びよりも，プロジェクトで開なくプロジェクトとしての評価をある程度の客観性を発されたプロダクトの質に注目することが多いので持って実施する方法について提案する．

はないか．

リサーチクエスチョンとして，学習者が自ら評価基確かに，学習者が上手にソフトウェアが開発できる準を作成して評価者に提示し，頻繁な振り返りから得ようになったのならば，当然ながら開発されたソフトた気づきとそれによる改善の成果を根拠として自己ウェアの質も良好であるはずだ，という考えもでき評価を行うことでプロジェクトに対する妥当な評価をる．しかしながら，仮に開発したソフトウェア自体の行うことが可能かどうかを探る．

Practical Scrum Technology Education Initiatives inAIIT.
∗ This is an unrefereed paper. Copyrights belong tothe Author(s).
Yoshihide Chubachi, 産業技術大学院大学, Advanced
Institute of Industrial Technolagy.

この事例として 2016 年度に産業技術大学院大学（以下，AIIT）の修士課程 2 年生を対象として筆者が指導した PBL を取り上げる．本文中の図表の一部は2016 年 8 月に実施した PBL 前期発表会において学生が作成した資料を再構成したものである．フレームワーク開発特論

コラボレイティブ
開発特論

アジャイル開発特論

ビジネスアプリケーション
特別演習（PBL）

図1

AIIT で開講する enPiT 科目

学習者による学習目標と評価基準

頻繁な「振り返り」による学びの深化

図2

PBL での学習法の 2 本の柱

3 事例の PBL における学習の方法
3. 1 本 PBL での学習法における 2 本の柱
今回事例として取り上げる PBL は，AIIT の修士

2 AIIT における実践的スクラム技術者教育

課程 6 名からなるチームで実施したものである．ス

本節では，本研究の背景として AIIT で実施してクラムによるソフトウェア開発を実際に行い，実践的いる enPiT プログラムについて述べる．AIIT ではなソフトウェア開発手法を学ぶ．

enPiT プログラムの一環としてアジャイル開発の手

ここではプロダクトよりもプロジェクトの進め方を法として現在主流となっているスクラムを学ぶコース
を実施している [4] [2] [3] [5] †1 ．

大事にし，何を作るのかではなく，どう作るかに焦点

スクラムコースの特徴として，アジャイル開発手法をあてる．また，教師が教えるのではなく，学習者が自ら学ぶことに重点を置く．の習得を最大の目的としている．それに注力するた

この PBL における学習は図 2 に示す 2 本の柱で構めにプロダクトの開発に用いる技術的知識は限定し成する．第 1 の柱である学習者による学習目標と評ている．最終的なプロダクトとして全チーム Web ア

価基準は学生自らが設定する．ただし，その内容は評プリケーションを開発する．そのために用いる言語は価者が納得するものでなくてはならない．また，第 2Ruby であり，Ruby on Rails をフレームワークとしの柱である頻繁の「振り返り」による学びの深化はて用い，動作環境は Heroku と決められている．

チーム全員で行う．そこでは解決すべき課題を明らか

enPiT 関連科目を図 1 に示す．フレームワーク開にし，プロジェクトそのものの改善を継続する．その発特論では大規模アプリケーション開発に必要なコン改善の結果を根拠として，自ら設定した評価基準に対ポーネント技術を学ぶ．コラボレイティブ開発特論でしてどの程度の学習成果を得たのか判断する．

は，チームでの協同開発に用いる GitHub を中心としたクラウド技術を取り上げる．アジャイル開発特論

3. 2 学習者による学習目標と評価基準

では，アジャイル開発手法スクラムを学び，ビジネス本 PBL を実施する目的はアジャイル開発手法としアプリケーション演習で PBL を実施する．てのスクラムを実践し，そのエッセンスを掴みとるこ2016 年度で enPiT も最終年度を迎え，1 年次にとである [6]．このことは，学生が PBL を選択する際enPiT 科目を受講した学生が 2 年次の修士課程 PBLに参照するシラバス（2016PBL 説明書）にて全学生に参加するようになった．今回事例として取り上げるに予め提示してある．このため，この PBL に参加しPBL も，6 名のメンバーのうち 1 名は enPiT プログた学生の間で学習目的についての合意はできている．

ラムの修了生である．

しかし，より具体的な学習目標となると学習者個人が期待している内容がチーム内で異なっている可†1 これとは別に，グローバルなソフトウェア技術者を育成するコースもあるが本論文では取り上げない．

能性が高い．特に，本学の修士課程に在学している学生は社会人の割合が多い．また，出身大学（学部）での専攻も様々である．そのため一言で「ソフトウェ
ア開発手法を学ぶ」と言っても各自の具体的な興味関心は多様だ．

について詳細な言及はない．
これを補完するために，スクラム開発チームではKPT [7] と呼ばれる振り返り手法を実施する．KPT

とりわけ，チーム学習である PBL では，参加するとは Keep/Problem/Try の 3 つの単語の頭文字を繋学習者が学ぶ内容の方向性をできるだけ揃えておくげたものであり，やって良かったこと（Keep），問題ことが望ましい．このため，本 PBL ではプロジェクとなったこと（Problem），やってみたいこと（Try）

トを通して獲得する学習目的を明確にし，それらの到を整理することで，改善のための手がかりを得る．

達度を評価するための基準を学習者自身が設定する

この手法は簡便であり，実施することもさほど難しこととした．

くない．ただし，KPT を実施することは，その事自この基準はチームで合意を得たものでなくてはな体が目的なのではない．あくまでもその結果からチーらない．チームではそのための議論を行い，学習目標ムをより良くする改善が実施されなくてはならない．

に対する合意を形成する．このことを通して，チーム

このことを踏まえ，本 PBL では KPT による振りとしての学習目標をより明確にする．

返りを毎回のミーティングで行うことに加え，前述のこのように学習目標が定まることで，学習の成果の評価基準に照らしてどの程度の改善が行われ，評価が度合いを測るための評価基準が設定できる．この評どのように上がったのかを常に意識するようにする．

価基準は，学習者が自らの達成度を測るために利用する．
加えて，PBL での学びを評価する評価者（主に教4 学生の気づきに基づく学習の成果
4. 1 2 本の柱に基づく学習成果の評価員や外部評価者など）ともこの評価基準について合意

ここでは，本事例のチームがどのような学習目的をしておかなくてはならない．学習目的との整合性を含設定して，どのような評価をしたのかについて記す．

め学習者は自分たちで設定した評価基準の妥当性を

これは，前期発表会においてメンバー発表した内容を示し，評価者が納得できる基準となるようにする．

もとに，筆者が加筆したものである．
以下，2 本の柱のそれぞれについて，学習者による

3. 3 頻繁な「振り返り」による学びの深化

学習目標と評価基準の結果では学習者が設定した評

ソフトウェア開発手法であるスクラムはスクラムガ

価基準と評価の結果について，4. 3 では振り返りに基イド [1] で定義されている．そこにはチームにおけるづく評価結果への根拠づけについて述べる．

役割分担や，スプリントと呼ばれる開発サイクルを核としたプロセスが記述されている．これらのルール

4. 2 学習者による学習目標と評価基準の結果を理解するだけであれば，わずか 17 ページのガイド

学習成果の評価基準として学習者は，スクラムガイブックを頭に入れればことが足りよう．
しかしながら，筆者の見立てではスクラムを行う開ドを精読したうえで，表 1 に示す 6 つの評価基準を設定した．

発チームにとって真に困難なのはチーム全体の効率

本節では，表の評価基準 1〜2 について学習者が振と最適化に関することであろう．ガイドによると開発り返った結果について述べる．3 については次節で述

チームは自己組織化され，機能横断的であることが特べる内容と関連するため，そこで取り上げる．4〜6

徴であるとされる．ただし，この状況を実際に達成すについては機会を改めて述べることにしたい．

ることは容易ではない．
スクラムマスターは開発チームを自己組織化・機能

4. 2. 1 評価基準 1:顧客の要望を満たすソフトウェアの提供横断的になるようコーチする．また，スプリントレト

評価基準 1 の顧客の要求を満たすソフトウェアをロスペクティブを実施し，改善計画を作成するとされ提供できるようになることは，アジャイル開発における．ところが，スクラムガイドにはその具体的な方法る一般的な目標である．このことが達成できたかどう表1

スクラム理解度の評価基準

項番

1.

評価基準
顧客の要望を満たすソフトウェアを提供できること

2.

要望を満たすための作業を詳細化できる

図3

ユーザ視点ではないプロダクトバックログ

こと

3.

チームを継続的に改善できること

4.

作業を成し遂げるための最善の策を自分たちで選択できること

5.

開発ツール，プロセスを使いこなせる
こと

6.

未経験の技術に挑戦し知識を身につけること
図4

ユーザの視点を意識したプロダクトバックログ

かの判断材料として，スクラムではプロダクトバックログの内容に着目することができる．
スクラムガイドによると，プロダクトバックログとは「プロダクトに必要なものがすべて並べられた一どうしても技術者の目線になってしまい，ユーザにとって価値のない機能ができてしまったこともあったと振り返った．

覧」である．これらはユーザに対して価値を提供する

また，ユーザからの価値を意識する際，単に機能とものであり，ユーザの立場で作成するべきである．

して実装するだけではなく，使いやすいユーザ・イン

しかしながら，チームが初期に作成したプロダクタフェースを提供することの必要性についても気づきトバックログにはこの視点が不足していた．図 3 に，プロジェクトの初期に学習者が作成したプロダクトバックログの一部を示す．
例えば，図に「トップページが表示できるようにする」という項目がある．これは技術的なタスクでを得た．

4. 2. 2 評価基準 2:要望を満たすための作業の詳細化
次に評価基準 2 の，要望を満たすための作業の詳細化について述べる．

あり，トップページが表示ができるようになることでスクラムでは毎スプリントごとに，プロダクトバッ

ユーザに対してどのような価値が提供できるのかがクログのアイテムのうち優先順位の高いものから実述べられておらず，顧客の観点で作成したプロダクト装をすすめる．プロダクトバックログのアイテムを完バックログとは言えない．

成させるために必要となるタスクはスプリントバック

PBL ではレビューの場でこのような誤りを指摘すログとして整理する．

ることで，学習者は次第にユーザの視点を意識するこ

図 5 に，スプリントバックログの例を示す．スプリとができるようになっていった．図 4 はこの点を改善

ントバックログの作成方法は，基本的には，優先順位したプロダクトバックログである．顧客の言葉で分かの高いアイテムから順にスプリントで実施可能なもりやすく書いたプロダクトバックログアイテムに加のを取りだし，それぞれをタスクに分解する．

え，顧客から見た価値が高い順につけられた優先順位

スプリントの完了時点で，理想的には全てのスプリとストーリーポイント法による見積もりも記されてントバックログの中身が完了する．これにより，選んいる．

だプロダクトバックログアイテムが実現され，プロダ

ただし，特に技術的に難易度の高そうなプロダクト
バックログのアイテムについて議論しているときは，クトがユーザに提供する価値が高まる．
この一連の作業が，要望を満たすための作業の詳細

教師が KPT のやり方をレクチャーし，その後はメンバーのみで行った．ツールとしてホワイトボードとマーカーを利用した．プロジェクトを通した振り返りの記録のごく一部を図 6 に示す．
学習者は KPT を通して自発的に様々な気付きを得た．発見した課題を自ら改善した例として「役割が固定」していたことがあげられる．これはメンバーで
図5

スプリントバックログ

ディスカッションをする際，ファシリテーターや議事録係などの役割が固定してしまうと議論に参加して発言するメンバーが偏るという問題が生じる．このため，役割はローテーションさせ，そのような偏りが起きないように工夫した．

5 事例から得られた知見に関する考察
ここまで，本 PBL 事例において実施した学習法と，その結果について述べた．本節では，この事例におけ
図6

KPT による振り返りの記録

る PBL 型の学習での学びについて考察する．
はじめに，学生自らが学習目標を設定したことに化である．このことについて，チームメンバーは基本

ついては，チーム内で何を学習するべきかをより明的な管理作業はできるようになったと評価した．この確にすることができた．もともとソフトウェア開発手評価が妥当かどうかについては，チームが作成した法を学ぶことが本 PBL の目的であったが，Ruby on

バックログと実際に動作するプロダクトをもって確認

Rails などの Web アプリケーション開発技術の取得することができる．に関心が向きがちな面もあった．その状況を，あくま

また，単に，プロダクトバックログを詳細化すればスプリントにおけるチームのタスクが全て抽出できでも開発手法を学ぶのだという方向性で意識合わせすることができたのもこの成果といえよう．

るわけではない，ということの気づきも得ている．例

また，成果発表会では，学生が設定した学習目標をえば，技術習得や調査の作業が該当し，スクラムでは評価者に対して明確に示すことができた．このことはスプリントバックログでこれらのタスクを管理できる評価者に対して，プロダクトではなくプロジェクトをことを学んだ．

評価してもらいたいというメッセージとなった．評価者にとってもチームが何を学ぼうとし，どこを評価し4. 3 頻繁な「振り返り」による学びの深化の結果
4. 3. 1 頻繁な振り返りとチームの改善て欲しいかが分かりやすかった．
頻繁な振り返りを KPT で実施したことについて

ここでは，本 PBL の学習法のもう一つの柱であるも良い効果があった．もともと，本学の修士課程で頻繁な振り返りについて，前節の表 2 で述べた評価の PBL においては，毎期ごとに個人レポートとして基準 3 のチームを継続的に改善できることの結果と「セルフアセスメント」を実施している．しかしながあわせて述べる．

ら，時間に追われがちな社会人にとっては個人作業で

4. 3. 2 評価基準 3:チームを継続的に改善できること

深い振り返りを行うことは難しい．KPT であればそれほど時間も手間もかからずに実施でき，チーム全体PBL では，開始当初より毎回のミーティングの終で行うため基本的に全員が参加することになる．このわりに KPT による振り返りを実施した．初回のみことも学生の学びを深めることに大いに貢献した．

以上見てきたとおり，学生自らが学習目標を設定しうになる．将来的には，開発手法を学ぶ PBL のためて明示することと，頻繁な振り返りを行うことで学習のルーブリックとして構成することも検討したい．

した内容をよりじっくりと振り返るこの学習法の効果事例として紹介した PBL は，2016 年度後半も同は明確に現れた．
しかしながら，実際には学習目標の合意形成に時間じテーマで活動を継続する．今後，研究そのものも改善を繰り返し，より良い教授法となるようにしたい．

がかかり，全ての項目が定義できたのは前期の活動の後半になったなど，実施にあたって改善すべき点も残参 考 文 献されている．

[1] Schwaber, K. and Sutherland, J.: ス ク ラ ム ガ
イ ド, 2011. http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf (accessed on
2016-08-21).
[2] 中鉢欣秀: enPiT プログラムにおける遠隔 PBL とアジャイル教材開発, 産業技術大学院大学紀要, No. 8(2014),
pp. 109–113.
[3] 中鉢欣秀: モダンなソフトウエア開発者育成のための技術教育, 日本ソフトウェア科学会大会論文集, Vol. 31,
9 2014, pp. 121–125.
[4] 中鉢欣秀: アジャイル開発の本質理解とグローバル人材育成のための PBL 教育, 第 40 回教育システム情報学会全国大会, 徳島, 教育システム情報学会, 9 2016.
[5] 酒森潔, 中鉢欣秀, 川田誠一: ビジネスアプリケーショ
ン分野における実践型 PBL プログラム, 日本ソフトウェ
ア科学会大会論文集, Vol. 30, 9 2013, pp. 295–300.
[6] 須澤秀人, 川木富美子, 酒瀬川泰孝, 木崎悟, 土屋陽介,酒森潔, 中鉢欣秀: 学生を対象とした Scrum 型ソフト
ウェア開発教育の実践に関する考察, プロジェクトマネ
ジメント学会研究発表大会予稿集, Vol. 2013, 3 2013,
pp. 292–297.
[7] 天野勝: これだけ! KPT, すばる舎, 2013.

6 おわりに
本論文では，ソフトウェア開発手法を学ぶ PBL の評価手法について，頻繁な振り返りとそれに基づく改善の蓄積を根拠として，学習者がみずから設定した評価基準により学習成果を評価する方法について提案した．
事例として取り上げた PBL でこの方法を適用した
ところ，学習者に対する評価手法として機能することが確認できた．それに加えて，学習者の学びを更に深める効果もあるとの感触も得た．
今回は最初の試行でもあり，改善の余地は大いにある．評価基準についてはより詳細化し，細かく点数化できるようにすればより精度の高い評価が行えるよ