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

成長するチームと製品(enPiT筑波大の紹介)

 成長するチームと製品(enPiT筑波大の紹介)

2019年7月12日(金)に筑波大学「情報メディア入門C」にて講義した内容をちょっと手直ししてアップしました。

C93ddcd56e947995124a73c45651f780?s=128

Chiemi Watanabe

July 13, 2019
Tweet

More Decks by Chiemi Watanabe

Other Decks in Education

Transcript

  1. 情報メディア⼊⾨C 第2回 3限 7/12 渡辺知恵美

  2. 講義内容 情報学群における「プロジェクトベース学 習」の実践をとおした について チームとプロダクトの成⻑

  3. 渡辺知恵美(Chiemi Watanabe) • 専⾨:データ⼯学 • セキュアデータ管理(データ匿名加⼯、暗号化データベース) • 2013年〜 2017年 システム情報系

    助教 • 2018年〜 図書館情報メディア系 准教授 • 2019年〜 筑波技術⼤学 産業技術学部 准教授 成⻑分野を⽀える 情報技術⼈材の育成拠点の 形成(enPiT)専任教員
  4. 情報学群:ビジネスシステムデザインA/B • 通称 enPiT (Education Network for Practical Information Technologies)

    • 「成⻑分野を⽀える情報技術⼈材の育成拠点の形成」⽂部科学省⽀援事業
  5. Project Based Learning (PBL) • プロジェクト学習。複雑な課題や挑戦しがいのある課題に対し て、少⼈数のグループでの⾃律的な問題解決・意思決定・情報 探索などを通じて解決を⽬指す学習⽅法。 チームによるシステム開発、という実践を通して 開発に必要となる情報技術について⾃律的に学ぶ

  6. enPiT1 実績 • 2014年度:「コロコロプラグ」 • GUGEN2014優秀賞 &起業賞(コクヨ賞) • 2015年度:「PoiPet」 •

    Mashup Awards 11 学⽣部⾨優勝 & アドビシステムズ賞 • GUGEN2015Vstone賞 • 2016年度: 「ChaTravel」 「れいんちゃん」 • Mashup Awards 2016 Repl-AIイケてるチャット ボット賞,Shopping Bot Award • Mashup Awards 2016エーアイ賞 • 「(集GO! 改め) meePa 」 • Mashup Award 2017 LINE賞 • https://www.youtube.com/watch?v=IzrIWe msuNY&list=PLJgl_g8FlTiNGlPYQA2F7taMa 4HN9Kgxw
  7. 2018年度のプロダクト例 •Cogito • https://cogito-hakohugu.herokuapp.com/ • 研究,⾃⼰分析,制作物のアイデア出し,⽬標実現のため の計画のときに,頭の中をうまく⾔語化して整理すること の難しさを解決する、⼤学⽣を対象としたWEBアプリ •Hello Idea

    • https://helloidea.site/topics • アイデアを出したいけどアイデアが出ない⼈向けの アイデア創出プラットフォーム
  8. 着任当時、想定したイメージ 楽しい 顧客が喜んでくれて嬉しい システムを完成させた 充実感 講義で勉強した基礎が活かせた! ⾃分から⾊々勉強できた チームとの助け合い ソフトウエア⼯学 プログラミング

    データ構造とアルゴリズム システムプログラミング データベース 多変量解析 1,2年で学んだ基礎知識
  9. 実際のところ… ⼤変でした… なんとか作るには 作りました… 実プロジェクトの 厳しさを学びました… 補⾜)素晴らしいプロダクトを作ってくれたり、 楽しかったと⾔ってくれる チームももちろんありました!

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

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

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

    偉い⼈「そんなの僕だったら使わない」 • 発表会にて。あの⼈は対象じゃないのに。評価下げられたらいやだ! 参考)メテオフォール型開発, http://eiki.hatenablog.jp/entry/meteo_fall (愚痴じゃないんです。受講⽣はとっても真⾯⽬で⼀⽣懸命でした。)
  13. プレイヤー⾃⾝の問題ではない • 期間中、それぞれ必死にやっている 設計でてく るまで遅れ てるよ! 要件理解す るの⼤変な んだよ! モノができたから良かれと思って

    改善要求しているのに こっちだって要求通りに 作ってるんですよ (2013年度当時) 適⽤していたソフトウエア 開発プロセス V字モデル(ウォーターフォール型開発)
  14. 社会の写し鏡だったようだ • γεςϜ։ൃϓϩδΣΫτͷ੒ޭ཰ 466 253 921 1280 561 824 2003

    2008 2018 成功 失敗 ⽇経コンピュータ 2018年3⽉号 https://business.nikkei.com/atcl /opinion/15/100753/03070000 • ໺ଜᨽ݊が೔ຊ*#.に依頼した⾦融システム開発プロジェクト が頓挫。損害賠償ԯԁ。 • Ѵ઒ҩେが/55౦೔ຊに依頼した電⼦カルテシステム開発プロ ジェクトが頓挫し訴訟。札幌⾼等裁判所は旭川医⼤にԯԁの ⽀払いを命じる。 など… 訴訟多数
  15. 顧客が本当に欲しかったもの 出典:Christopher Alexander, “Tree Swing”, The Oregon Experiment, 1975

  16. キーワード 暗黙知 ⾔葉や⽂章で表現することが難しい、⾝体的な経験に根ざす主観的な知

  17. 問題解決と暗黙知 問題が ある 解決 ツール • 顧客が問題を全部⾔葉にできて いるとは限らない • 気づいていない問題が隠れている

    解決法の アイデア 実現の ⼿段 暗黙知 暗黙知 • 解決法のアイデアは知の塊 • 実現の⼿段も⼀通りではない • ⾔葉で正しく伝えられるのか
  18. チーム開発と暗黙知 システム構成 利⽤するツール と使い道 実装⽅法 (アルゴリズム) データ分析 今どんな問題を 抱えているか 今何をやっているか

    今何を考えて いるのか 状況や開発者個⼈の考え⽅、知っている知識によって 開発の仕⽅は多岐にわたる。マニュアル化するのは⾮常に難しい。 暗黙知
  19. SECIモデル 野中郁次郎, ⽵中広⾼, 梅本勝博, 知識創造企業, 東洋経済新報社, 1996

  20. 野中郁次郎⽒ 経営学者。⼀橋⼤学名誉教授。カリフォルニア⼤学バークレー校 特別名誉教授。知識経営の⽣みの親として知られる。 ダイヤモンド社 1984年 ⼤東亜戦争における ⽇本軍の失敗の原因 を組織論と歴史研究を 組み合わせて論じる 東洋経済新報社

    1996年 新しい知識を作り出 し、組織全体に広め、 製品やサービスに具 体化する組織全体の 能⼒を「組織的知識 創造」として提唱 (wikipediaより引⽤)
  21. 5IF/FX/FX1SPEVDU%FWFMPQNFOU(BNFT (H. Takenaka and I. Nonaka, Harverd Business Review, 1986)

    • ⽇本の製造業者(富⼠ゼロックス, キャノン, ホンダ)の 新製品開発プロセスをNASA等と⽐較
  22. “スクラム” • 段階ごとに分断せず重なりあい、 スピードも柔軟性も優れていた • チームは機能横断的で主体性が あった • ⾃分たちの枠を超えた⼤きなも のを⽬指していた

    • マネジメントは指図しない • 管理職はサーバント(奉仕型) リーダーでまとめ役 • 中⾝や進め⽅を細かく指⽰した りしなかった チーム内でボールをパスしながら、チームは⼀団となってフィールドを進む Jeff Sutherland著, ⽯垣賀⼦訳, スクラムより当該論⽂に関する部分を要約・引⽤ Conor Lawless, Scrum, https://flic.kr/p/67KuTJ
  23. アジャイルマニフェスト(2001年) 私たちは、ソフトウエア開発の実践 あるいは実践を⼿助けする活動を通じて、 より良い開発⽅法を⾒つけ出そうとしている。 この活動を通じて、私たちは以下の価値に⾄った。 プロセスやツールよりもݸਓͱର࿩を、 包括的なドキュメントよりもಈ͘ιϑτ΢ΣΞを、 契約交渉よりもސ٬ͱͷڠௐを、 計画に従うことよりもมԽ΁ͷରԠを、 価値とする。すなわち、左記のことがらに価値があることを

    認めながらも、私たちは右記のことがらにより価値を置く
  24. 参考)Yasunobu Kawaguchi, アジャイルをやってないとはどういうことなんだろうか, http://bit.ly/2Sck9n7

  25. アジャイルマニフェストは「指針」 Agile [adjective] 1. quick and well-coordinated in movement 2.

    active; lively 3. marked by an ability to think quickly Donʻt do agile, be agile.
  26. アジャイルに開発するための⽅法論 出典 : VERSIONONE 13th annual STATE OF AGILE TM

    Report
  27. 4DSVNEFWFMPQNFOUQSPDFTT (Ken Schwaber, OOPSLA Business Object Design and Implement workshop,

    1997) • Ken SchwaberとJeff Sutherlandにより提唱 • 複雑で変化の激しい問題に対応するためのフ レームワーク Jeff Sutherland著, ⽯垣賀⼦訳, 早川書房より引⽤ 私たちがイーゼルでこれを読んだときは発表から7年が経ってい た。(略) トヨタがこのアプローチで市場シェアを拡⼤しているに も関わらず、平均的なアメリカの経営者は、この⼿法を⾃分のも のにして取り⼊れることができずにいたのだ。(略)このアプ ローチを試してみることにした。両⽒の考え⽅は、分野を問わず、 ⼈間がチームになって仕事をする際のプロセスの根本を捉えてい ると感じたからだ。
  28. スクラムガイド • スクラムの公式な 知識体系(Body of Knowledge) • 特徴 1.軽量 2.理解が容易

    3.習得は困難
  29. スクラムガイド • 経験主義を基本 • 実際の経験と既知に基づく判断によって 知識が獲得できる • 反復かつ漸進的な⼿法で、予測可能性の最適 化とリスクの管理を⾏う •

    スクラムを⽀える三本柱 • ಁ໌ੑ • 結果責任を持つものに対して⾒える化 されている • ݕࠪ • 頻繁に検査し好ましい変化を検知する • దԠ • プロセスに不備があれば調整を⾏い 逸脱を防ぐ https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
  30. スクラムチーム スクラム マスター プロダクト オーナー(PO) 開発チーム ⾃⼰組織的:作業を成し遂げる最善の策を、⾃分たちで選択し、動く 機能横断的:チームメンバーがそれぞれの役⽬を超えて連携する ϓϩμΫτͷՁ஋࠷େԽに 責任を持つ

    ü 必要な機能リストの管 理・更新 各スプリント(後述)の終了時に リリース判断可能なʮ׬੒ͨ͠ʯ プロダクトを届けることのできる 専⾨家 スクラムの促進と⽀援の責任者。 ü メンバーが最⼤のパフォーマ ンスを発揮するよう奉仕する ü あらゆる障害を取り除く 顧客/外部関係者 (ステークホルダー)
  31. スクラムマスター https://www.youtube.com/watch?v=NcWDx-XXISY

  32. スクラムイベント https://www.scrum.org/resources/blog/difference-between-scrumorg-professional-scrum-master-classes

  33. スプリント:利⽤可能でリリース判断可能な プロダクトを作る期間(1ヶ⽉以内) https://www.scrum.org/resources/blog/difference-between-scrumorg-professional-scrum-master-classes

  34. 前提:プロダクトオーナー(PO)は作るべき機能のリスト (プロダクトバックログ)を⽤意しておく https://www.scrum.org/resources/blog/difference-between-scrumorg-professional-scrum-master-classes

  35. プロダクトバックログ ü 顧客が本当に欲しいものを検証できる੡඼を継続的に ఏڙするための(優先順位づけられた)機能リスト “The Myth of Incremental Development” by

    Herding Cats Where4Lunch とにかく何かオススメしてくれる ランチで迷って結局コンビニな⼈のために ランダムにオススメしてくれる お店の基本情報を掲載 他の選択肢も推薦 現在地の周辺の店を推薦 ⼈気ランキングを考慮して推薦 過去の履歴を考慮して推薦
  36. スプリント計画:スプリントで完成させる 機能とその詳細をPOと開発チームで決める https://www.scrum.org/resources/blog/difference-between-scrumorg-professional-scrum-master-classes

  37. デイリースクラム(スタンドアップミーティング) 毎⽇15分、メンバーの進捗と障害を確認する https://www.scrum.org/resources/blog/difference-between-scrumorg-professional-scrum-master-classes

  38. レビュー:最終⽇、成果物の “Show and Tell ” https://www.scrum.org/resources/blog/difference-between-scrumorg-professional-scrum-master-classes

  39. 振り返り:スプリントを振り返り次の改善計画を⽴てる https://www.scrum.org/resources/blog/difference-between-scrumorg-professional-scrum-master-classes

  40. enPiT筑波⼤での実践 実施⽅法とその効果、そしてenPiT筑波⼤では暗黙知をどのように 形式化し新しい知を⽣み出すように⼯夫しているのか

  41. 年間スケジュール • جૅ஌ֶࣝशɿ講義&⾃習で必要な技術を習得 • 1#-جૅɿ集中授業でΞδϟΠϧ։ൃを習得 • ൃలֶशɿプロダクトのチーム開発を実践

  42. 前提:餅は餅屋 • 「理解は容易、実践は困難」 • スクラムの実践にも「暗黙知」がある • プロの「アジャイルコーチ」が導⼊⽀援 永瀬美穂⽒ 株式会社アトラクタ CBO,

    産業技術⼤学院⼤学特任准教授。 多くの企業でアジャイル導⼊⽀援 実績あり。 筑波⼤のほか、東⼯⼤、琉球⼤、 公⽴はこだて未来⼤等でも アジャイルに関する講義を実践。 kyon_mm⽒ うさぎ組代表。 株式会社オンザロードでシステ ムアーキテクトとして活躍する 傍ら、フリーでアジャイルコー チを務める。2016年度より筑 波⼤enPiTのアジャイル講師を 担当。
  43. ⾃分たちが顧客 • 顧客やプロダクトオーナーはチームと⼀緒に動く必要がある • チーム内に常にプロダクトオーナーがいる状態にする ビジネス側の⼈と開発者は、プロジェクトを通して⽇々⼀緒に働かねばなりません。

  44. 夏合宿:1⽇1スプリント • スプリントのリズムを体に覚えさせる PBL基礎での1⽇ 8:40 リリース計画 開発(途中2回情報共有) 17:00 実機デモ 17:30

    振り返り リリースノート • ⼣⽅にリリースをする 機能を宣⾔する 情報共有(Standup meeting) • タスクの状況や現在起きている問題 を共有する 振り返り • 1⽇を振り返り、明⽇改善する ための取り組みを考える デモンストレーション • 実機でのデモでのみ成果を⽰す
  45. 秋学期:2⽇スプリント x 9 weeks (⽔曜3,4限+⾦曜5,6限) 計画 ։ൃ ໿࣌ؒ෼ レビュー 振り返り

    ⽔曜⽇ (3,4限、150分) ⾦曜⽇ (5,6限 、150分) 30分 30分 30分
  46. スプリントごとにプロダクトが੒௕͢Δ ϓϩμΫτόοΫϩά ࡞੒ɾߋ৽ͷͨΊͷ ϛʔςΟϯά 顧客・POと(開発チーム) が共同で作る ɾϓϩμΫτόοΫϩά ࡞੒ɾߋ৽ ɾܭըϛʔςΟϯά 必要な機能や

    開発タスクに落とし込む ࣮૷ プログラムによって 製品を作り出す ϨϏϡʔ デモやリリースで 使⽤することによって 新たな知を⽣成
  47. 再掲:パターン1:成果物(製品)がない リリース可能なものは夏合宿の時点から存在する •「設計はしたものの実装が完了しませんでした」 • 部分的に⾒せられるところもありません •「直前に直したら動かなくなっちゃって…」 • 前のバージョンとか公開できるもの?… ないです •「こんな期間で完成するはずがないです」

    • 何連続かで徹夜までしたのに… • 他の授業のレポートや試験だってあるんです
  48. enPiTでは原則的に残業禁⽌ •「こんな期間で完成するはずがないです」 • 何連続かで徹夜までしたのに… • 他の授業のレポートや試験だってあるんです スプリント計画でチームが獲得するべきスキル 限られた時間の中で完成できる 機能を予測し選択する 残業して埋め合わせたらスキルが⾝につかないでしょ

    他の授業のレポートや試験に時間を使ってください
  49. 再掲:パターン3: メテオフォール •「2週間前に⾊々⾔われても…」 • 発表前にシステムを動かしてもらったら仕様にない注⽂を ⾊々つけられた。そんなん⾔われても、もう無理です。 •「先⽣が⼿を出す⼝を出す」 • 僕らの学びを奪わないで… •

    偉い⼈「そんなの僕だったら使わない」 • 発表会にて。あの⼈は対象じゃないのに。評価下げられたらいやだ! スプリントレビューごとに表出している(はず)
  50. スプリントごとにνʔϜも੒௕͢Δ ৼΓฦΓ チームメンバーで 学びを共有 ৼΓฦΓπΞʔ 他のチームの振り返り も⾒る λεΫ͔Μ͹ΜͳͲͷ ਐḿՄࢹԽ σΠϦʔεΫϥϜ

    νʔϜͰࣗݾ૊৫తʹ ໰୊ղܾΛ͢Δ ϊ΢ϋ΢ͷ065165 Ұॹͷ෦԰Ͱ΍Δ 全チーム同じ部屋で 開発する ϖΞϓϩɾϞϒϓϩ ⼀緒にプログラムを書いて ノウハウを伝承する ࣮૷ɾ࣮ݧɾௐࠪ
  51. プラクティス:タスクかんばん • PBI: 開発する機能 • TODO: これからやる タスク • DOING:

    作業中 • DONE: 完了 チームの進捗状況が⼀⽬でわかる 状況を表出。 刺さってる タスクもわかる
  52. プラクティス:ペアプロ・モブプロ υϥΠόʔ プログラムを書く 実況する φϏήʔλ 先回りして調べる 書き⽅を考える φϏήʔλ φϏήʔλ φϏήʔλ

    φϏήʔλ プログラム時の 考え⽅や書き⽅ などの暗黙知を共有 υϥΠόʔ
  53. プラクティス:ふりかえり • スプリント後に、チームでの働き⽅を振り返り、次に 改善や挑戦することを決める チームで振り返り 個⼈で振り返り KPT (Keep, Problem, Try)

    YWT (やったこと、わかったこと、つぎ やること) 感謝 Fun Done Learn
  54. パターン2:トラックナンバー1 •「あの機能は彼しかさわれなくて…」 • 彼は発表1週間前にインフルエンザ •「僕だけ⾟い。みんな何もしてくれない。」 • 教えるのもしんどい。わかってくれないしやる気ないし •「あの機能が完成するの待ちなんです」 • 他にやることないので帰ります

    機能横断的なチームに成⻑すれば問題はきえる(はず)
  55. 教員は何しているの? • スクラムマスター:受講⽣チームが開発活動に 専念できるようにサーバントリーダとして奉仕し ています 差し⼊れ 状況に応じた専⾨家の召喚(ゲスト講義) メンターチーム(教員, 修了⽣, 企業エンジニア)

  56. メンターミーティング • アジャイルコーチ・教員と学⽣メンター(前年 度の修了⽣)でスクラムマスターチームを結成

  57. 再掲:パターン3: メテオフォール •「2週間前に⾊々⾔われても…」 • 発表前にシステムを動かしてもらったら仕様にない注⽂を ⾊々つけられた。そんなん⾔われても、もう無理です。 •「先⽣が⼿を出す⼝を出す」 • 僕らの学びを奪わないで… •

    偉い⼈「そんなの僕だったら使わない」 • 発表会にて。あの⼈は対象じゃないのに。評価下げられたらいやだ! 実際、アジャイルコーチに注意された。 やらないように⼼がけています。
  58. 再掲:パターン3: メテオフォール •「2週間前に⾊々⾔われても…」 • 発表前にシステムを動かしてもらったら仕様にない注⽂を ⾊々つけられた。そんなん⾔われても、もう無理です。 •「先⽣が⼿を出す⼝を出す」 • 僕らの学びを奪わないで… •

    偉い⼈「そんなの僕だったら使わない」 • 発表会にて。あの⼈は対象じゃないのに。評価下げられたらいやだ! ⾊々頑張っています
  59. 全てがうまくいくわけではない 製品やチームがどうなるかは スプリントを経てチームが どんな形式知や共同化した暗黙知を 獲得したかによる しかし どのチームも約10スプリントの経験 を経て成⻑することに間違いはない (講義後補⾜)

  60. で、楽しいの?楽しくないの? • エンジニアの⽴場で⾔うと楽しいと思う 最⼤限の パフォーマンスを 発揮

  61. みんなで夢中になるのは楽しい • 問題 vs. 私たち (not ⼈ vs. ⼈ )

  62. Fun Done Learn を⾒てみると楽しそう • https://enpit.coins.tsukuba.ac.jp/products/#2018

  63. 7/31-8/7 合宿やります • 総合研究棟B SB0112 教室 • https://enpit.coins.tsukuba.ac.jp/summercamp2019/ • 是⾮⾒に来てください