pblへのアジャイル開発手法導入の試み

PBLへのアジャイル開発手法導入の試み

神谷年洋公立はこだて未来大学

於教育システム情報学会第38全国大会パネルPC1

実践的PBL高品質化・高効率化のための教育機関交流

2013/09/02 教育システム情報学会第38会全国大会パネルディスカッションPC1

2

「アジャイルって何それ？おいしいの？」「アジャイルって何それ？おいしいの？」

http://www.flickr.com/photos/suzanneandsimon/430069386/


3

アジャイル開発とは● 迅速（アジャイル）にソフトウェアを開発するための方法群● 1周間〜数週間で開発サイクルを1回● 人間中心、計画の見直しが前提

開発技術

開発プロセス、プラクティス組織、チーム

契約、ビジネス

教育

XP

スクラム

リーン

組織パターン

上記の守備範囲はかなり主観が入って

います


4

アジャイル開発の4つの価値

個人と相互作用

動作するソフトウェア顧客との協調

変化への対応

プロセスやツールよりも

契約交渉よりも包括的なドキュメントよりも

計画の尊守よりも


5

アジャイル開発のプラクティス(その他)

個人と相互作用

動作するソフトウェア顧客との協調

変化への対応

イテレーション

共通の用語振り返り

テスト駆動

ペアプログラミング

リファクタリング

計画ゲーム

受け入れテスト

チーム

スクラムマスター

プロダクトオーナー

バックログスプリント

ムリ・ムダ・ムラ

全体最適化

決定を遅らせる

エレベーター・ピッチ

スタンドアップ・ミーティング

品質を作りこむ


6

欧米での普及

● 欧米では8割以上の企業が導入

引用 http://www.versionone.com/state-of-agile-survey-results/


7

「でも、日本じゃまだまだ、なんでしょ？」「でも、日本じゃまだまだ、なんでしょ？」「大規模開発には向かないんでしょ？」「大規模開発には向かないんでしょ？」

http://www.flickr.com/photos/evanblaser/5652992350/


8

日本でも使われ始めました

● Web業界では広く利用されている

– 楽天、cookpad、モバゲー・・・

● ドラクエX(2012)– 100人を超える開発組織での利用

– http://www.atmarkit.co.jp/news/201208/29/cedec_araki.html

● 組み込みソフト開発でも利用が始まっています– www.jaspic.org/event/2012/SPIJapan/session2C/2C1

_ID004.pdf


9

「でも、学生のチームで「でも、学生のチームでアジャイル開発を回せるの？」アジャイル開発を回せるの？」

http://www.flickr.com/photos/vastateparksstaff/6354627939/


10

そんなに難しいことなの？● アジャイルは楽な開発ではありません！

● メンバーに共通の知識・スキルが必要となる– ドメイン知識、技術を含めて

● 自律的に動くチームになる必要がある● 評価は（ほぼ）成果物のみで行われる

– 「ドキュメントを作る仕事」は評価されない。進捗ですらない● 顧客を巻き込む必要がある● 開発プロセスをチームが定義する必要がある

– なぜそのタスクを行う／行わないのか？


11

じゃあなぜ大学でやるの？● 知価社会にふさわしい開発手法だから

● 楽しい！– 早期から「動く」成果物がある＝実感がある

● フィードバックがもらえる– 少人数のチーム

● 自分の貢献・メンバーの貢献がよくわかる● 学習プロセスである

– 開発プロセスを学習の過程として捉える– メンバーが学ぶ方法が組み込まれている– 複数の技術・ドメインに精通することが求められる


12

高度ICT演習● プロジェクトベースの学習

– B2〜Mまで参加するチーム

● 通年● 単位は出ない● 企業の皆様に対して成果発表（2回）

● 神谷が担当しているチームは、eポートフォリオ（後述）の開発

● お題はあるが仕様はない


13


14


15


16


17


18


19


20


21


22


23


24

高度ICT演習固有の事情● 知識レベルの相違

– メンバーの学年がバラバラ(B2〜M)● 開発技術、ドメインともに知識レベルが異なる

– アジャイル開発を前提とした事前の座学が（ほとんど）ない● 開発体制

– メンバー全員が集まれる時間を見つけるのは困難– 週1回〜2回の開発作業

● 開発に巻き込まれてくれる顧客を見つけるのが難しい– 今年度はコース長の大場先生に助けてもらっているところ大


25

工夫(1): 見える化● ペーパープロトタイプを導入

– メンバー間で成果物のイメージを共有できた(➔知識)

– 顧客への説明デモとして利用できた(➔顧客)

– 開発スキルがない状態でプロトタイプを作り始められた(➔知識)

● ドキュメントはなるべく構成管理システムで管理– 開発の状況をメンバー各人が把握できた（体制）➔

● コード（プロダクション、テスト）: ソースコード● データ構造などの設計ドキュメント : マークダウン ● 日誌: マークダウン● 成果発表会のプレゼンテーション: HTML


26

工夫(2): 前提となる知識● メンバー全員が共有すべき知識・技能・プラクティスを限定（➔

知識）– ドメイン知識（eポートフォリオ）

– 構成管理（Git, GitHub）

– 成果物の記法（HTML, マークダウン）

– スタンドアップミーティング● メンバー全員に共有されない部分にはリーダー（オーナー）を立

てる（体制）➔– 全体のリーダー（スケジュールや調整、構成管理）– 技術リーダー（技術検証・技術的な決定）– デザインリーダー（画面やワークフローに関する決定）– （ただし、このリーダー制度は計画的にやったのではなく、自然にそう

なったという側面も・・・）


27

工夫(3): 開発プロセスのカスタマイズ

● 「正しくアジャイル開発を行うこと」を目標にしない– 取り入れないプラクティス（知識）➔

● リファクタリング● テストファースト（テスト駆動）

– 後からテストを足していく● 計画ゲーム● バーンダウンチャートによる進捗管理

– 追加したプラクティス● ペーパープロトタイプ（前述）● 日誌（体制）➔● 成果発表


28

工夫(4): 学習プロセスとしての設計

● 学習曲線をなだらかにする（知識）➔– 演習の開始時点で学習の順序を立てる

● (1) 構成管理 (Git, GitHub)● (2) ドメイン知識● (3) ペーパープロトタイプ (POP)● (4) プログラミング言語、ライブラリ

– 独立性の高い（単体で理解できる）小さなライブラリを順に導入

● ウェブフレームワーク（Flask）● UI (HTML5, bootstrap)● ファイルサーバー(ownCloud)


29

現状

● あくまで年度の途中の状況ですが

● チームが俊敏に立ち上がった● 動く成果物が早期にできた● 顧客からフィードバックをもらっている● 士気は高い


30

まとめ● 学生チームの開発にアジャイルを導入できる

– いろいろ工夫すれば– 開発に巻き込まれてくれる顧客

● 学生の知識・技術は間違いなく向上– アジャイルは学習プロセスを内包している

● 参考: 開発チームのリポジトリ– github.com/ICTKyouikukei2013– 前述の資料およびソースコード

pblへのアジャイル開発手法導入の試み

Education