■スクラムを使ったソフトウェア技術者の育成

近年、欧米を中心に普及している軽量なソフトウェア開発手法「スクラム」は、日本においてもソフトウェア開発の現場で利用されるケースが増えています。スクラムは、他の開発方式に比べてシンプルであり、学習すべき知識項目はさほど多くありません。
しかし、実際にスクラムをプロジェクトで実施できるようになるには相当の訓練が必要です。このようなスキルの獲得のためには実際の業務に近い形で、プロジェクトを行うことが望まれます。

私たちはスクラムを採用し、大学と企業の産学連携プロジェクトを通じて、ソフトウェア技術者の育成を図っています。その活動についてご紹介します。

 

■顧客が「真」に求める製品を作るために

私たちは、実社会で即戦力として活躍できる人材を育成することを目的に、プロジェクト・ベースド・ラーニング(以下、PBL)を実施しています。

PBLとは、チームでプロジェクトを遂行し、学生らが学習を進める上でできた問題を自主的に解決することで能力(コミュニケーション能力や問題解決能力など)の向上を図る教育手法です。PBLではプロジェクトを通して、社会で役立つスキルやノウハウを習得します。企業研修や教育機関において、PBL形式で授業が実施される例も増えています。

慶應義塾大学SFCでは、学部生を対象にPBL型科目「協創型ソフトウェア開発」を実施しています。
コラマネ:コラボレイティブ・マネジメント・ラボラトリー

この授業は、2005年度秋学期に開講され、2012年度で7回目になります。毎年、複数の開発チームが結成され、プロジェクトのメンバは3〜5名で構成されています。また、プロジェクトマネージャは社会人技術者が担当し、実際にシステムを必要とする企業や個人の顧客が設定され、ユーザに利用されるソフトウェアの開発を目標としています。

2010年度までは、ウォーターフォール型などの非アジャイル型開発プロセスを利用していました。しかし、2010年度までのプロジェクトでは、顧客の求めていたソフトウェアと異なるものが完成する、ソフトウェアの品質が低くリリースすることができないなどといった問題が発生していました。また、納品できる製品を作ったプロジェクトも顧客が必要としない機能まで作る、仕様書などのドキュメントに多くの時間を割くなど、余計な時間が発生していました。

顧客が「真」に求める製品を作る、ソフトウェア品質を上げる、余計なものを作らない(生産性を上げる)といった理想に合致する手法として、2011年度以降は、アジャイル型開発プロセス「スクラム」を採用しました。

本授業のプロジェクトモデルでは、プロジェクトには顧客(プロダクトオーナー)を設定しています。また、IT企業からスクラムマスターが参加して各チーム(3〜5人)に加わります。そして、教員の他にアジャイルの専門家(アジャイルコーチ)が参加して、手法に不慣れなチームのサポートを行っています。
このモデルを適用することで、学生は実際のソフトウェア開発に限りなく近い環境で学ぶことができます。

筆者は、2010年度からプロジェクトマネージャ(2012年度以降はスクラムマスター)として参加しています。

 

■活動の様子

2013年1月現在、5チームがそれぞれ異なるプロジェクトを実施しています。
毎週金曜日の午後(2コマ)が授業時間となり、それぞれのチームでプロジェクト活動を行っています。最初の3回はガイダンスとスクラムでの開発方法を講義形式で実施しました。
PBLによるスクラムの様子_3

以降は各チームでプロジェクトを進めていきます。
最初はスクラムに慣れることを目標にスプリント計画を立てます。スプリント計画会議では、プロダクトバックログの作成と完了の定義を決めます。1つのスプリントを2週間。2週間単位でスプリントレビューを行いプロダクトオーナーの評価をもらいます。
PBLによるスクラムの様子_1

授業時間の最初にデイリースクラムを行います。次に、決められたタイムボックスの中で作業を行います。授業時間の最後は振り返り(レトロスペクティブ)を行い、今後の改善点を話し合います。次の授業までに、プロダクトバックログの優先順位をもとにして作業を進めていきます。
PBLによるスクラムの様子_2

活動の窓口

※メール送信時は[at]を@に変えてください。

 

■今後の活動の予定

本年度の授業は、2013年1月までになります。最終発表会までに、個々のチームが製品をリリースします。

協創型ソフトウェア開発は、秋学期の科目のため、半年ペースで実施されています。毎年、多くの企業や社会人の方に参加いただいております。
スクラムマスターやプロダクトオーナー役として興味がある方はぜひご連絡ください。

最終発表会のご案内


木崎さん書き手:木崎 悟

Web系プログラマの仕事をしながら、社会人向け大学院で専門職学位(情報システム学修士)を取得。現在、電気通信大学大学院情報システム学研究科博士後期課程在籍。専門はソフトウェア工学教育。フリーランス講師。
趣味はアニメ鑑賞。コミックマーケットに参加することが生きがい。


6 Comments

@a0920sk · 2013年1月13日 at 23:28

大学でも使われるスクラム 〜PBLによるスクラム実践 http://t.co/fcUZsC3t オンライン記事を執筆しました!

@dokokano_panda · 2013年1月15日 at 02:01

RT @em_staff: 慶應義塾大学SFCで取り組まれている「協創型ソフトウェア開発」によるスクラム実践授業の紹介です ―大学でも使われるスクラム 〜PBLによるスクラム実践 http://t.co/vXAwCc8o #scrum

@ryuzee · 2013年1月21日 at 12:18

RT @em_staff: 慶應義塾大学SFCのPBL最終発表会の日時と場所が確定しました。2/23(土) 15:00より、三田キャンパス西校舎 1階512教室です。興味ある方は是非ご参加ください ―大学でも使われるスクラム 〜PBLによるスクラム実践 http://t.co/vXAwCc8o

@dokokano_panda · 2013年1月21日 at 13:08

RT @em_staff: 慶應義塾大学SFCのPBL最終発表会の日時と場所が確定しました。2/23(土) 15:00より、三田キャンパス西校舎 1階512教室です。興味ある方は是非ご参加ください ―大学でも使われるスクラム 〜PBLによるスクラム実践 http://t.co/vXAwCc8o

@haradakiro · 2013年1月21日 at 15:38

RT @em_staff: 慶應義塾大学SFCのPBL最終発表会の日時と場所が確定しました。2/23(土) 15:00より、三田キャンパス西校舎 1階512教室です。興味ある方は是非ご参加ください ―大学でも使われるスクラム 〜PBLによるスクラム実践 http://t.co/vXAwCc8o

matsuzawa · 2013年3月7日 at 10:56

おつかれさま.以下,よくするための批判的なコメント.
1.PBLの定義は即戦力を育成する事じゃない.すくなくとも,コラマネは.
2.コミュニでケーション能力や問題解決能力も育成できるけど,それが主眼じゃない.
3.僕がコラマネをやってきたのは,”理論の意味とか,理論が実際に役に立つこと”を理解できる環境を作るため.
4.2010年度までは、ウォーターフォール型などの非アジャイル型開発プロセスを利用していました。→うそでしょ?アジャイル型も含めて,むかしからなんでもありです.繰り返し型,アジャイル型の方が成功率が高い.論文を読んでね.
5.「2010年度までのプロジェクトでは、顧客の求めていたソフトウェアと異なるものが完成する、ソフトウェアの品質が低くリリースすることができないなどといった問題が発生していました。また、納品できる製品を作ったプロジェクトも顧客が必要としない機能まで作る、」→おいおい.顧客満足度評価で言えば,2010年度までのほうがはるかに厳しくやっていました.もちろん,問題は発生するけど,それはそれをきちんとやったからで,去年今年は...(ごにょごにょ,以下口頭で).
6.「仕様書などのドキュメントに多くの時間を割くなど、余計な時間が発生していました。」→これもおいおい.昔から無駄なドキュメントに時間を割くなといっていますよ,ドキュメントつくるるために作ったらおわりなんです..でもね.最近はドキュメント少なすぎ,時間も計測していないので生産性はかれねーし.scrumだってドキュメントは最低限というのであって,作るなって話ではないでしょう.もしscrumの人が,それがでいいのだと思っているのだとしたら,それはscrum手法に問題があるということになるでしょう.
7.顧客が「真」に求める製品を作る、ソフトウェア品質を上げる、余計なものを作らない(生産性を上げる) というのは,コラマネがまさに探究してきたものであって,それ以前のやり方がダメで,scrumにすると解決,という問題ではないでしょう.やるべき事は,たぶんコラマネがやってきたたことは,scrumと相性がいいと思うので,その手法の良いところを取り入れたり,scrumの言葉で説明したり,scrum とPBLが合わないところを見つけたり(デイリースクラムとか,面白い考察を学生さんがしていましたね.),というところから始めていくのだと思います.
8.scrumだって現在産業界で評価中,そのまま適用すればよいものではないでしょう.そもそも,「なにかのプロセスに乗ってやると,うまくソフトウェアが作れる」という発想自体が間違っているのです.ソフト開発では,プロセスなどの開発理論の適用に際して,現場の種類に応じたカスタマイズ,工夫が必要です.「教典にのってるから」と思考停止になるのは最悪でしょう?コラマネが教育現場として目指してきたものは,「そうした工夫が必要だ」という考え方(理論の実際の意味が分かる)をmake senseするものです.

Comments are closed.