AgilePBL （アジャイルなプロジェクトベース学習） を通じて 生き生きとした価値創造の場を作る

M2M･IoT研究会の第18回専門部会セミナーにて発表しました。

Transcript

1. AgilePBL （アジャイルなプロジェクトベース学習） を通じて 生き生きとした価値創造の場を作る 筑波技術大学 渡辺知恵美
2. 自己紹介 渡辺知恵美（わたなべ ちえみ） 筑波技術大学 産業情報学科 准教授 筑波大学 非常勤講師 専門：データ工学、個人情報保護技術、暗号化DB 2013年より教育プロジェクトenPiT専任教員として 筑波大にてチームによるシステム開発教育に携わる AgilePBL祭り実行委員会
3. Project Based Learning (PBL) • プロジェクト学習。複雑な課題や挑戦しがいのある課題に対して、 少人数のグループでの自律的な問題解決・意思決定・情報探索な どを通じて解決を目指す学習方法。 チームによるシステム開発、という実践を通して 開発に必要となる情報技術について自律的に学ぶ
4. 筑波大 enPiT • 情報系学部のプロジェクトベース学習（PBL）に 担当教員として 8年ほど関わる • ICT技術を利用し、チームで問題解決 • 「自分の身の回りの困りごとを解決する」 • 2016年からアジャイル開発を導入 enPiT: 2012年度〜2020年度に実施された文部科学省補助金事業の名称。 もう終了しましたが、名前が定着したのでそのまま使ってます。 顧客の価値、良いものを提供する良いチームに本気で向き合う
5. Agile PBL 祭り (2020〜) 大学のPBL（Project Based Learning）などでアジャイル開発 を取り入れている学生チームや、企業でのプロジェクト実践者が参 加し、相互学習と交流をするイベント
6. 発表内容と、みなさんにお聞きしたいこと • 筑波大学で実践している Agile PBLで チームでソフトウエアを作る際に 何を重視して何をしているのかをお話しします • 受講生がこの授業を通して獲得する学びが その後のキャリアにおいてどう生かされるのか 教員としてその土台を築くにはどうするべきか 議論できたらと思っています
7. PBLを始めた当初の話
8. 着任当時、想定したイメージ 楽しい 顧客が喜んでくれて嬉しい システムを完成させた 充実感 講義で勉強した基礎が活かせた！ ⾃分から⾊々勉強できた チームとの助け合い ソフトウエア⼯学 プログラミング データ構造とアルゴリズム システムプログラミング データベース 多変量解析 1,2年で学んだ基礎知識
9. 実際のところ… 大変でした… なんとか作るには 作りました… 実プロジェクトの 厳しさを学びました… 補足）素晴らしいプロダクトを作ってくれたり、 楽しかったと言ってくれる チームももちろんありました！
10. パターン１：成果物（製品）がない •「設計はしたものの実装が完了しませんでした」 • 部分的に見せられるところもありません •「直前に直したら動かなくなっちゃって…」 • 前のバージョンとか公開できるもの？… ないです •「こんな期間で完成するはずがないです」 • 何連続かで徹夜までしたのに… • 他の授業のレポートや試験だってあるんです （愚痴じゃないんです。受講生はとっても真面目で一生懸命でした。）
11. パターン２：トラックナンバー1 •「あの機能は彼しかさわれなくて…」 • 彼は発表１週間前にインフルエンザ •「僕だけ辛い。みんな何もしてくれない。」 • 教えるのもしんどい。わかってくれないしやる気ないし •「あの機能が完成するの待ちなんです」 • 他にやることないので帰ります （愚痴じゃないんです。受講生はとっても真面目で一生懸命でした。）
12. パターン3: メテオフォール •「２週間前に色々言われても…」 • 発表前にシステムを動かしてもらったら仕様にない注文を 色々つけられた。そんなん言われても、もう無理です。 •「先生が手を出す口を出す」 • 僕らの学びを奪わないで… • 偉い人「そんなの僕だったら使わない」 • 発表会にて。あの人は対象じゃないのに。評価下げられたらいやだ！ 参考）メテオフォール型開発, http://eiki.hatenablog.jp/entry/meteo_fall （愚痴じゃないんです。受講生はとっても真面目で一生懸命でした。）
13. 経験すべき苦労... 学びになった...本当？ 仕組みで解決できる問題を学生に押し付けていないか
14. 改めてPBLに向き合う 1. 何のためにプロダクトを作るのか • 技術を応用することが目的か • 「使うものを作る」ことに本気で向き合わないか 2. チームで取り組むことの意義 • プロジェクトの過程で起こるさまざまな問題は メンバーが経験的に解決することか • 苦労・頑張り・努力の経験はどの程度必要か
15. 使うものを作る • そんなことは当たり前 • 誰もがそのつもりで作っている • 顧客の要望から始まったプロジェクトもある • 結果的にそうなっていない • 「どうつくるか」に夢中になってしまう癖 • 顧客自身も何が欲しいかわかってない
16. 「どうつくるか」に夢中になってしまう癖 例）「ギリギリまで課題に手をつけられない」という問題 タスク管理ツールを 作れば良いのでは タスク管理ツール の一般的な機能を つくらなきゃ... こんな機能や あんな機能もあった ら便利だな！ 本当にタスク管理ツールで課題に手をつけられない問題は解決するのか？
17. 顧客自身、何が欲しいかわかっていない 顧客が本当に 欲しかったもの 出典：Christopher Alexander, “Tree Swing”, The Oregon Experiment, 1975
18. 顧客自身、何が欲しいかわからない 例）「ギリギリまで課題に手をつけられない」という問題 顧客も想像で言っているので、 それで問題が解決するのか わかっているわけではない 明確に「〇〇が欲しい」と いう場合も、 ◯◯の背景にある問題が 解決するかはわかってない ずっと見えるところに あればいいのかも しれないなぁ… TODOリストには 入れてたんですけどね 入れてたこと 忘れるんですよね
19. 「本当に欲しかったものを作る」 に正面から取り組む
20. 顧客は自分たち • 身の回りの困りごとをプロダクトで解決する •「本当に欲しかったものは何か」を探究する
21. 開発スケジュール • 1スプリントの長さは160分、残業は非推奨 • スプリントが日を跨ぐと思い出す時間が必要になる • スプリントは15回 • １学期にアジャイル開発合宿（６日間）を実施済
23. Agile Manifesto 2000
24. 想像と体験、その本気度 包括的なドキュメントよりも動くソフトウエアを プロダクト/体験の提供 • レビューでは必ずプロダクトによる体験を（実機レビュー） • 「何のためにそのレビューをするのか」を常に意識する https://speakerdeck.com/kawaguti/jikkankudo2016-bpstudy より
25. 一緒になって本気で解決する • 自分たちが顧客になる • 困りごとを共有するメンバーで チームを結成する • 本気で作りながら、本気で考える • ドッグフーディング • 最初の熱狂的なユーザになる 契約交渉よりも顧客との協調を
26. 捨てる勇気と優先順位 • プロダクトバックログは 常に更新をする • 計画はきちんと立てる • サンクコストとの戦い • どこかで必要かも しれないものは消す • リスクが高い（＝ちゃぶ台 がひっくり返ると痛い）も のから取り組む 計画に従うことよりも変化への対応を
27. 考え方の転換とトレーニングが必要なこと •プロダクトを小さくちぎるスキル • スプリントが短い＝速く作らなければいけないではない • プロダクトによるユーザの体験をいかに小さくちぎるか •優先順位を決めるスキル • 土台から作るのではなく、速く検証すべきものからやる • 潔く計画を変えられるか Unlearnが求められるため、開発経験者ほど難しい
28. 改めてPBLに向き合う 1. 何のためにプロダクトを作るのか • 技術を応用することが目的か • 「使うものを作る」ことに本気で向き合わないか 2. チームで取り組むことの意義 • プロジェクトの過程で起こるさまざまな問題は メンバーが経験的に解決することか
29. 初期の頃、よく発生していた問題 • 属人化 • スキルの高いメンバーだけが全てを担当していて、その人がいなくなると何も 動かない • 役割分担 • フロントエンド、バックエンド、デザイン • 気がつくと仕様に違いが生じて結合できない • 属人化 • 残業 • 発表会の前の日に徹夜をして何とかする • 問題が最後になって顕在化する • 発表会にて「そんなことがあったのか！」 • 何とかしないとと思ってはいたんだけど
30. プロジェクトの過程で起こるさまざまな問題は メンバーが経験的に解決すること • ただし、プロジェクトで苦労した結果だけが残っていたら それは「経験的に解決」できていない • 状況を観察し、分析し、解決法を探し、実践する サイクルを回してもがかないと解決に至らない
31. スクラムフレームワークで チーム成長のサイクルも回していく https://www.ryuzee.com/contents/blog/7147 より
32. フレームワークの強み • 質問や相談はスキルが必要 • モヤモヤを整理する、相談する人を探す、時間や場所を調整す る、どう話したら伝わるのか考える、話す • 場所／時間／相手が決まっている • 定期的に質問したり相談するタイミングがあると楽 • モヤモヤのままひとまず表に出す
33. チームだけで解決できるのか？ • チーム間で互いに相談し合う仕組み • 振り返りツアー • Open Space Technology (OST） • 受験生やメンターが自主的に作ったもの • 修了生や企業でのスクラム経験者に聞ける仕組み • 学生／教員／メンターを含めたチーム体制 • 学びのコミュニティ
34. チームによる解決法の一端 •スキルの差／知識の差の解消 • 最初は役割分担をせず一緒にやる（モブプログラミング） • 分担するべき状況が生まれてきたら一時的に分担する •担当を毎回変える • 人を固定で割り当てない
35. 学生／教員／メンターを含めたチーム体制 • 学部3年生と修士1年生を対象にした授業 • 修了生が5,6名メンターとして協力 • メンターとしてチームを見ることで別の学びが得られる • PBLの運営チームとして改善にもかかわる
36. 学びの共同体を作る 主催・運営 講師 講師 OB/OG, メンター 受講生 勉強会 勉強会 RSGT Scrum Fest Agile Tech スクラム コミュニティ
37. がんばらないで 仕組みを変える • enPiTの好きなところ と学生に言われた一言 • 「苦労はして経験おくも のだ」への反論
38. AgilePBLは実践を通した「学び方の学び」 •「わからない」ことを前提にする • 誰も正解を知らない • 全ての計画は妄想 • 計画を細かくちぎり、並べ替えて、やってみて前進する •1人で抱えない • 頼る、パクる、カンニングする • 違和感を言語化する仕組みを組織で作る 当たり前だ（と思う）けど、実はトレーニングが必要なこと
39. 現在私が持っているもやもや • 大学を出た後の世界がわからない • 「学び方の学び」をトレーニングしても単独では成立しない • 次の世界にどうつなげていけば良いのか • 「アジャイル」「スクラム」というキーワードにとらわれず考えたい 主催・運営 講師 講師 OB/OG, メンター 受講生 勉強会 勉強会 RSGT Scrum Fest Agile Tech スクラム コミュニ ティ そのほかわからない世界
40. まとめに代えて • 皆さんとこんな話ができたら嬉しいです 本当に、当たり前のことでしょうか？ こういう「学び方の学び」は社会で生かされますか？