Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

C93ddcd56e947995124a73c45651f780?s=128

Chiemi Watanabe

November 13, 2021
Tweet

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. パターン1:成果物(製品)がない •「設計はしたものの実装が完了しませんでした」 • 部分的に見せられるところもありません •「直前に直したら動かなくなっちゃって…」 • 前のバージョンとか公開できるもの?… ないです •「こんな期間で完成するはずがないです」 •

    何連続かで徹夜までしたのに… • 他の授業のレポートや試験だってあるんです (愚痴じゃないんです。受講生はとっても真面目で一生懸命でした。)
  11. パターン2:トラックナンバー1 •「あの機能は彼しかさわれなくて…」 • 彼は発表1週間前にインフルエンザ •「僕だけ辛い。みんな何もしてくれない。」 • 教えるのもしんどい。わかってくれないしやる気ないし •「あの機能が完成するの待ちなんです」 • 他にやることないので帰ります

    (愚痴じゃないんです。受講生はとっても真面目で一生懸命でした。)
  12. パターン3: メテオフォール •「2週間前に色々言われても…」 • 発表前にシステムを動かしてもらったら仕様にない注文を 色々つけられた。そんなん言われても、もう無理です。 •「先生が手を出す口を出す」 • 僕らの学びを奪わないで… •

    偉い人「そんなの僕だったら使わない」 • 発表会にて。あの人は対象じゃないのに。評価下げられたらいやだ! 参考)メテオフォール型開発, 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回 • 1学期にアジャイル開発合宿(6日間)を実施済

  22. None
  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. まとめに代えて • 皆さんとこんな話ができたら嬉しいです 本当に、当たり前のことでしょうか? こういう「学び方の学び」は社会で生かされますか?