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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

渡辺知恵美（Chiemi Watanabe) • 専⾨：データ⼯学 • セキュアデータ管理（データ匿名加⼯、暗号化データベース） • 2013年〜 2017年システム情報系助教 • 2018年〜図書館情報メディア系准教授 • 2019年〜筑波技術⼤学産業技術学部准教授成⻑分野を⽀える情報技術⼈材の育成拠点の形成（enPiT）専任教員

Slide 4

Slide 4 text

情報学群：ビジネスシステムデザインA/B • 通称 enPiT (Education Network for Practical Information Technologies) • 「成⻑分野を⽀える情報技術⼈材の育成拠点の形成」⽂部科学省⽀援事業

Slide 5

Slide 5 text

Project Based Learning (PBL) • プロジェクト学習。複雑な課題や挑戦しがいのある課題に対して、少⼈数のグループでの⾃律的な問題解決・意思決定・情報探索などを通じて解決を⽬指す学習⽅法。チームによるシステム開発、という実践を通して開発に必要となる情報技術について⾃律的に学ぶ

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

2018年度のプロダクト例 •Cogito • https://cogito-hakohugu.herokuapp.com/ • 研究，⾃⼰分析，制作物のアイデア出し，⽬標実現のための計画のときに，頭の中をうまく⾔語化して整理することの難しさを解決する、⼤学⽣を対象としたWEBアプリ •Hello Idea • https://helloidea.site/topics • アイデアを出したいけどアイデアが出ない⼈向けのアイデア創出プラットフォーム

Slide 8

Slide 8 text

着任当時、想定したイメージ楽しい顧客が喜んでくれて嬉しいシステムを完成させた充実感講義で勉強した基礎が活かせた！⾃分から⾊々勉強できたチームとの助け合いソフトウエア⼯学プログラミングデータ構造とアルゴリズムシステムプログラミングデータベース多変量解析 1,2年で学んだ基礎知識

Slide 9

Slide 9 text

実際のところ… ⼤変でした… なんとか作るには作りました… 実プロジェクトの厳しさを学びました… 補⾜）素晴らしいプロダクトを作ってくれたり、楽しかったと⾔ってくれるチームももちろんありました！

Slide 10

Slide 10 text

パターン１：成果物（製品）がない •「設計はしたものの実装が完了しませんでした」 • 部分的に⾒せられるところもありません •「直前に直したら動かなくなっちゃって…」 • 前のバージョンとか公開できるもの？… ないです •「こんな期間で完成するはずがないです」 • 何連続かで徹夜までしたのに… • 他の授業のレポートや試験だってあるんです（愚痴じゃないんです。受講⽣はとっても真⾯⽬で⼀⽣懸命でした。）

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

パターン3: メテオフォール •「２週間前に⾊々⾔われても…」 • 発表前にシステムを動かしてもらったら仕様にない注⽂を⾊々つけられた。そんなん⾔われても、もう無理です。 •「先⽣が⼿を出す⼝を出す」 • 僕らの学びを奪わないで… • 偉い⼈「そんなの僕だったら使わない」 • 発表会にて。あの⼈は対象じゃないのに。評価下げられたらいやだ！参考）メテオフォール型開発, http://eiki.hatenablog.jp/entry/meteo_fall （愚痴じゃないんです。受講⽣はとっても真⾯⽬で⼀⽣懸命でした。）

Slide 13

Slide 13 text

プレイヤー⾃⾝の問題ではない • 期間中、それぞれ必死にやっている設計でてくるまで遅れてるよ！要件理解するの⼤変なんだよ！モノができたから良かれと思って改善要求しているのにこっちだって要求通りに作ってるんですよ (2013年度当時）適⽤していたソフトウエア開発プロセス V字モデル（ウォーターフォール型開発）

Slide 14

Slide 14 text

社会の写し鏡だったようだ • γεςϜ։ൃϓϩδΣΫτͷ੒ޭ཰ 466 253 921 1280 561 824 2003 2008 2018 成功失敗⽇経コンピュータ 2018年3⽉号 https://business.nikkei.com/atcl /opinion/15/100753/03070000 ● ໺ଜᨽ݊が೔ຊ*#.に依頼した⾦融システム開発プロジェクトが頓挫。損害賠償ԯԁ。 ● Ѵ઒ҩେが/55౦೔ຊに依頼した電⼦カルテシステム開発プロジェクトが頓挫し訴訟。札幌⾼等裁判所は旭川医⼤にԯԁの⽀払いを命じる。など… 訴訟多数

Slide 15

Slide 15 text

顧客が本当に欲しかったもの出典：Christopher Alexander, “Tree Swing”, The Oregon Experiment, 1975

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

問題解決と暗黙知問題がある解決ツール • 顧客が問題を全部⾔葉にできているとは限らない • 気づいていない問題が隠れている解決法のアイデア実現の⼿段暗黙知暗黙知 • 解決法のアイデアは知の塊 • 実現の⼿段も⼀通りではない • ⾔葉で正しく伝えられるのか

Slide 18

Slide 18 text

チーム開発と暗黙知システム構成利⽤するツールと使い道実装⽅法（アルゴリズム）データ分析今どんな問題を抱えているか今何をやっているか今何を考えているのか状況や開発者個⼈の考え⽅、知っている知識によって開発の仕⽅は多岐にわたる。マニュアル化するのは⾮常に難しい。暗黙知

Slide 19

Slide 19 text

SECIモデル野中郁次郎, ⽵中広⾼, 梅本勝博, 知識創造企業, 東洋経済新報社, 1996

Slide 20

Slide 20 text

野中郁次郎⽒経営学者。⼀橋⼤学名誉教授。カリフォルニア⼤学バークレー校特別名誉教授。知識経営の⽣みの親として知られる。ダイヤモンド社 1984年⼤東亜戦争における⽇本軍の失敗の原因を組織論と歴史研究を組み合わせて論じる東洋経済新報社 1996年新しい知識を作り出し、組織全体に広め、製品やサービスに具体化する組織全体の能⼒を「組織的知識創造」として提唱 (wikipediaより引⽤)

Slide 21

Slide 21 text

5IF/FX/FX1SPEVDU%FWFMPQNFOU(BNFT (H. Takenaka and I. Nonaka, Harverd Business Review, 1986) • ⽇本の製造業者（富⼠ゼロックス, キャノン, ホンダ）の新製品開発プロセスをNASA等と⽐較

Slide 22

Slide 22 text

“スクラム” • 段階ごとに分断せず重なりあい、スピードも柔軟性も優れていた • チームは機能横断的で主体性があった • ⾃分たちの枠を超えた⼤きなものを⽬指していた • マネジメントは指図しない • 管理職はサーバント（奉仕型）リーダーでまとめ役 • 中⾝や進め⽅を細かく指⽰したりしなかったチーム内でボールをパスしながら、チームは⼀団となってフィールドを進む Jeff Sutherland著, ⽯垣賀⼦訳, スクラムより当該論⽂に関する部分を要約・引⽤ Conor Lawless, Scrum, https://flic.kr/p/67KuTJ

Slide 23

Slide 23 text

アジャイルマニフェスト(2001年) 私たちは、ソフトウエア開発の実践あるいは実践を⼿助けする活動を通じて、より良い開発⽅法を⾒つけ出そうとしている。この活動を通じて、私たちは以下の価値に⾄った。プロセスやツールよりもݸਓͱର࿩を、包括的なドキュメントよりもಈ͘ιϑτ΢ΣΞを、契約交渉よりもސ٬ͱͷڠௐを、計画に従うことよりもมԽ΁ͷରԠを、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値を置く

Slide 24

Slide 24 text

参考）Yasunobu Kawaguchi, アジャイルをやってないとはどういうことなんだろうか, http://bit.ly/2Sck9n7

Slide 25

Slide 25 text

アジャイルマニフェストは「指針」 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.

Slide 26

Slide 26 text

アジャイルに開発するための⽅法論出典 : VERSIONONE 13th annual STATE OF AGILE TM Report

Slide 27

Slide 27 text

4DSVNEFWFMPQNFOUQSPDFTT (Ken Schwaber, OOPSLA Business Object Design and Implement workshop, 1997) • Ken SchwaberとJeff Sutherlandにより提唱 • 複雑で変化の激しい問題に対応するためのフレームワーク Jeff Sutherland著, ⽯垣賀⼦訳, 早川書房より引⽤私たちがイーゼルでこれを読んだときは発表から７年が経っていた。(略) トヨタがこのアプローチで市場シェアを拡⼤しているにも関わらず、平均的なアメリカの経営者は、この⼿法を⾃分のものにして取り⼊れることができずにいたのだ。（略）このアプローチを試してみることにした。両⽒の考え⽅は、分野を問わず、⼈間がチームになって仕事をする際のプロセスの根本を捉えていると感じたからだ。

Slide 28

Slide 28 text

スクラムガイド • スクラムの公式な知識体系（Body of Knowledge) • 特徴 1.軽量 2.理解が容易 3.習得は困難

Slide 29

Slide 29 text

スクラムガイド • 経験主義を基本 • 実際の経験と既知に基づく判断によって知識が獲得できる • 反復かつ漸進的な⼿法で、予測可能性の最適化とリスクの管理を⾏う • スクラムを⽀える三本柱 • ಁ໌ੑ • 結果責任を持つものに対して⾒える化されている • ݕࠪ • 頻繁に検査し好ましい変化を検知する • దԠ • プロセスに不備があれば調整を⾏い逸脱を防ぐ https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

Slide 30

Slide 30 text

スクラムチームスクラムマスタープロダクトオーナー(PO) 開発チーム⾃⼰組織的：作業を成し遂げる最善の策を、⾃分たちで選択し、動く機能横断的：チームメンバーがそれぞれの役⽬を超えて連携する ϓϩμΫτͷՁ஋࠷େԽに責任を持つ ü 必要な機能リストの管理・更新各スプリント（後述）の終了時にリリース判断可能なʮ׬੒ͨ͠ʯ プロダクトを届けることのできる専⾨家スクラムの促進と⽀援の責任者。 ü メンバーが最⼤のパフォーマンスを発揮するよう奉仕する ü あらゆる障害を取り除く顧客/外部関係者 (ステークホルダー）

Slide 31

Slide 31 text

スクラムマスター https://www.youtube.com/watch?v=NcWDx-XXISY

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

プロダクトバックログ ü 顧客が本当に欲しいものを検証できる੡඼を継続的に ఏڙするための（優先順位づけられた）機能リスト “The Myth of Incremental Development” by Herding Cats Where4Lunch とにかく何かオススメしてくれるランチで迷って結局コンビニな⼈のためにランダムにオススメしてくれるお店の基本情報を掲載他の選択肢も推薦現在地の周辺の店を推薦⼈気ランキングを考慮して推薦過去の履歴を考慮して推薦

Slide 36

Slide 36 text

スプリント計画：スプリントで完成させる機能とその詳細をPOと開発チームで決める https://www.scrum.org/resources/blog/difference-between-scrumorg-professional-scrum-master-classes

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

前提：餅は餅屋 • 「理解は容易、実践は困難」 • スクラムの実践にも「暗黙知」がある • プロの「アジャイルコーチ」が導⼊⽀援永瀬美穂⽒株式会社アトラクタ CBO, 産業技術⼤学院⼤学特任准教授。多くの企業でアジャイル導⼊⽀援実績あり。筑波⼤のほか、東⼯⼤、琉球⼤、公⽴はこだて未来⼤等でもアジャイルに関する講義を実践。 kyon_mm⽒うさぎ組代表。株式会社オンザロードでシステムアーキテクトとして活躍する傍ら、フリーでアジャイルコーチを務める。2016年度より筑波⼤enPiTのアジャイル講師を担当。

Slide 43

Slide 43 text

⾃分たちが顧客 • 顧客やプロダクトオーナーはチームと⼀緒に動く必要がある • チーム内に常にプロダクトオーナーがいる状態にするビジネス側の⼈と開発者は、プロジェクトを通して⽇々⼀緒に働かねばなりません。

Slide 44

Slide 44 text

夏合宿：1⽇1スプリント • スプリントのリズムを体に覚えさせる PBL基礎での1⽇ 8:40 リリース計画開発（途中２回情報共有） 17:00 実機デモ 17:30 振り返りリリースノート • ⼣⽅にリリースをする機能を宣⾔する情報共有(Standup meeting） • タスクの状況や現在起きている問題を共有する振り返り • 1⽇を振り返り、明⽇改善するための取り組みを考えるデモンストレーション • 実機でのデモでのみ成果を⽰す

Slide 45

Slide 45 text

秋学期：2⽇スプリント x 9 weeks （⽔曜3,4限＋⾦曜5,6限）計画 ։ൃ ໿࣌ؒ෼ レビュー振り返り⽔曜⽇ (3,4限、150分) ⾦曜⽇ (5,6限、150分) 30分 30分 30分

Slide 46

Slide 46 text

スプリントごとにプロダクトが੒௕͢Δ ϓϩμΫτόοΫϩά ࡞੒ɾߋ৽ͷͨΊͷ ϛʔςΟϯά 顧客・POと(開発チーム) が共同で作る ɾϓϩμΫτόοΫϩά ࡞੒ɾߋ৽ ɾܭըϛʔςΟϯά 必要な機能や開発タスクに落とし込む ࣮૷ プログラムによって製品を作り出す ϨϏϡʔ デモやリリースで使⽤することによって新たな知を⽣成

Slide 47

Slide 47 text

再掲：パターン１：成果物（製品）がないリリース可能なものは夏合宿の時点から存在する •「設計はしたものの実装が完了しませんでした」 • 部分的に⾒せられるところもありません •「直前に直したら動かなくなっちゃって…」 • 前のバージョンとか公開できるもの？… ないです •「こんな期間で完成するはずがないです」 • 何連続かで徹夜までしたのに… • 他の授業のレポートや試験だってあるんです

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

再掲：パターン3: メテオフォール •「２週間前に⾊々⾔われても…」 • 発表前にシステムを動かしてもらったら仕様にない注⽂を⾊々つけられた。そんなん⾔われても、もう無理です。 •「先⽣が⼿を出す⼝を出す」 • 僕らの学びを奪わないで… • 偉い⼈「そんなの僕だったら使わない」 • 発表会にて。あの⼈は対象じゃないのに。評価下げられたらいやだ！スプリントレビューごとに表出している（はず）

Slide 50

Slide 50 text

スプリントごとにνʔϜも੒௕͢Δ ৼΓฦΓ チームメンバーで学びを共有 ৼΓฦΓπΞʔ 他のチームの振り返りも⾒る λεΫ͔Μ͹ΜͳͲͷ ਐḿՄࢹԽ σΠϦʔεΫϥϜ νʔϜͰࣗݾ૊৫తʹ ໰୊ղܾΛ͢Δ ϊ΢ϋ΢ͷ065165 Ұॹͷ෦԰Ͱ΍Δ 全チーム同じ部屋で開発する ϖΞϓϩɾϞϒϓϩ ⼀緒にプログラムを書いてノウハウを伝承する ࣮૷ɾ࣮ݧɾௐࠪ

Slide 51

Slide 51 text

プラクティス：タスクかんばん • PBI: 開発する機能 • TODO: これからやるタスク • DOING: 作業中 • DONE: 完了チームの進捗状況が⼀⽬でわかる状況を表出。刺さってるタスクもわかる

Slide 52

Slide 52 text

プラクティス：ペアプロ・モブプロ υϥΠόʔ プログラムを書く実況する φϏήʔλ 先回りして調べる書き⽅を考える φϏήʔλ φϏήʔλ φϏήʔλ φϏήʔλ プログラム時の考え⽅や書き⽅などの暗黙知を共有 υϥΠόʔ

Slide 53

Slide 53 text

プラクティス：ふりかえり • スプリント後に、チームでの働き⽅を振り返り、次に改善や挑戦することを決めるチームで振り返り個⼈で振り返り KPT (Keep, Problem, Try) YWT (やったこと、わかったこと、つぎやること）感謝 Fun Done Learn

Slide 54

Slide 54 text

パターン２：トラックナンバー1 •「あの機能は彼しかさわれなくて…」 • 彼は発表１週間前にインフルエンザ •「僕だけ⾟い。みんな何もしてくれない。」 • 教えるのもしんどい。わかってくれないしやる気ないし •「あの機能が完成するの待ちなんです」 • 他にやることないので帰ります機能横断的なチームに成⻑すれば問題はきえる（はず）

Slide 55

Slide 55 text

教員は何しているの？ • スクラムマスター：受講⽣チームが開発活動に専念できるようにサーバントリーダとして奉仕しています差し⼊れ状況に応じた専⾨家の召喚（ゲスト講義）メンターチーム（教員, 修了⽣, 企業エンジニア）

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

Slide 59

Slide 59 text

全てがうまくいくわけではない製品やチームがどうなるかはスプリントを経てチームがどんな形式知や共同化した暗黙知を獲得したかによるしかしどのチームも約10スプリントの経験を経て成⻑することに間違いはない（講義後補⾜）

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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