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

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

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. パターン１：成果物（製品）がない •「設計はしたものの実装が完了しませんでした」 • 部分的に⾒せられるところもありません •「直前に直したら動かなくなっちゃって…」 • 前のバージョンとか公開できるもの？… ないです •「こんな期間で完成するはずがないです」 • 何連続かで徹夜までしたのに… • 他の授業のレポートや試験だってあるんです （愚痴じゃないんです。受講⽣はとっても真⾯⽬で⼀⽣懸命でした。）
11. パターン２：トラックナンバー1 •「あの機能は彼しかさわれなくて…」 • 彼は発表１週間前にインフルエンザ •「僕だけ⾟い。みんな何もしてくれない。」 • 教えるのもしんどい。わかってくれないしやる気ないし •「あの機能が完成するの待ちなんです」 • 他にやることないので帰ります （愚痴じゃないんです。受講⽣はとっても真⾯⽬で⼀⽣懸命でした。）
12. パターン3: メテオフォール •「２週間前に⾊々⾔われても…」 • 発表前にシステムを動かしてもらったら仕様にない注⽂を ⾊々つけられた。そんなん⾔われても、もう無理です。 •「先⽣が⼿を出す⼝を出す」 • 僕らの学びを奪わないで… • 偉い⼈「そんなの僕だったら使わない」 • 発表会にて。あの⼈は対象じゃないのに。評価下げられたらいやだ！ 参考）メテオフォール型開発, 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
    /FX
    1SPEVDU
    %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. 4DSVN
    EFWFMPQNFOU
    QSPDFTT (Ken Schwaber, OOPSLA Business Object Design and Implement workshop, 1997) • Ken SchwaberとJeff Sutherlandにより提唱 • 複雑で変化の激しい問題に対応するためのフ レームワーク Jeff Sutherland著, ⽯垣賀⼦訳, 早川書房より引⽤ 私たちがイーゼルでこれを読んだときは発表から７年が経ってい た。(略) トヨタがこのアプローチで市場シェアを拡⼤しているに も関わらず、平均的なアメリカの経営者は、この⼿法を⾃分のも のにして取り⼊れることができずにいたのだ。（略）このアプ ローチを試してみることにした。両⽒の考え⽅は、分野を問わず、 ⼈間がチームになって仕事をする際のプロセスの根本を捉えてい ると感じたからだ。
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. スプリント：利⽤可能でリリース判断可能な プロダクトを作る期間（１ヶ⽉以内） 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 リリース計画 開発（途中２回情報共有） 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. 再掲：パターン１：成果物（製品）がない リリース可能なものは夏合宿の時点から存在する •「設計はしたものの実装が完了しませんでした」 • 部分的に⾒せられるところもありません •「直前に直したら動かなくなっちゃって…」 • 前のバージョンとか公開できるもの？… ないです •「こんな期間で完成するはずがないです」 • 何連続かで徹夜までしたのに… • 他の授業のレポートや試験だってあるんです
48. enPiTでは原則的に残業禁⽌ •「こんな期間で完成するはずがないです」 • 何連続かで徹夜までしたのに… • 他の授業のレポートや試験だってあるんです スプリント計画でチームが獲得するべきスキル 限られた時間の中で完成できる 機能を予測し選択する 残業して埋め合わせたらスキルが⾝につかないでしょ 他の授業のレポートや試験に時間を使ってください
49. 再掲：パターン3: メテオフォール •「２週間前に⾊々⾔われても…」 • 発表前にシステムを動かしてもらったら仕様にない注⽂を ⾊々つけられた。そんなん⾔われても、もう無理です。 •「先⽣が⼿を出す⼝を出す」 • 僕らの学びを奪わないで… • 偉い⼈「そんなの僕だったら使わない」 • 発表会にて。あの⼈は対象じゃないのに。評価下げられたらいやだ！ スプリントレビューごとに表出している（はず）
50. スプリントごとにνʔϜも੒௕͢Δ ৼΓฦΓ チームメンバーで 学びを共有 ৼΓฦΓπΞʔ 他のチームの振り返り も⾒る λεΫ͔Μ͹ΜͳͲͷ ਐḿՄࢹԽ σΠϦʔεΫϥϜ νʔϜͰࣗݾ૊৫తʹ ໰୊ղܾΛ͢Δ ϊ΢ϋ΢ͷ065165 Ұॹͷ෦԰Ͱ΍Δ 全チーム同じ部屋で 開発する ϖΞϓϩɾϞϒϓϩ ⼀緒にプログラムを書いて ノウハウを伝承する ࣮૷ɾ࣮ݧɾௐࠪ
51. プラクティス：タスクかんばん • PBI: 開発する機能 • TODO: これからやる タスク • DOING: 作業中 • DONE: 完了 チームの進捗状況が⼀⽬でわかる 状況を表出。 刺さってる タスクもわかる
52. プラクティス：ペアプロ・モブプロ υϥΠόʔ プログラムを書く 実況する φϏήʔλ 先回りして調べる 書き⽅を考える φϏήʔλ φϏήʔλ φϏήʔλ φϏήʔλ プログラム時の 考え⽅や書き⽅ などの暗黙知を共有 υϥΠόʔ
53. プラクティス：ふりかえり • スプリント後に、チームでの働き⽅を振り返り、次に 改善や挑戦することを決める チームで振り返り 個⼈で振り返り KPT (Keep, Problem, Try) YWT (やったこと、わかったこと、つぎ やること） 感謝 Fun Done Learn
54. パターン２：トラックナンバー1 •「あの機能は彼しかさわれなくて…」 • 彼は発表１週間前にインフルエンザ •「僕だけ⾟い。みんな何もしてくれない。」 • 教えるのもしんどい。わかってくれないしやる気ないし •「あの機能が完成するの待ちなんです」 • 他にやることないので帰ります 機能横断的なチームに成⻑すれば問題はきえる（はず）
55. 教員は何しているの？ • スクラムマスター：受講⽣チームが開発活動に 専念できるようにサーバントリーダとして奉仕し ています 差し⼊れ 状況に応じた専⾨家の召喚（ゲスト講義） メンターチーム（教員, 修了⽣, 企業エンジニア）
56. メンターミーティング • アジャイルコーチ・教員と学⽣メンター（前年 度の修了⽣）でスクラムマスターチームを結成
57. 再掲：パターン3: メテオフォール •「２週間前に⾊々⾔われても…」 • 発表前にシステムを動かしてもらったら仕様にない注⽂を ⾊々つけられた。そんなん⾔われても、もう無理です。 •「先⽣が⼿を出す⼝を出す」 • 僕らの学びを奪わないで… • 偉い⼈「そんなの僕だったら使わない」 • 発表会にて。あの⼈は対象じゃないのに。評価下げられたらいやだ！ 実際、アジャイルコーチに注意された。 やらないように⼼がけています。
58. 再掲：パターン3: メテオフォール •「２週間前に⾊々⾔われても…」 • 発表前にシステムを動かしてもらったら仕様にない注⽂を ⾊々つけられた。そんなん⾔われても、もう無理です。 •「先⽣が⼿を出す⼝を出す」 • 僕らの学びを奪わないで… • 偉い⼈「そんなの僕だったら使わない」 • 発表会にて。あの⼈は対象じゃないのに。評価下げられたらいやだ！ ⾊々頑張っています
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/ • 是⾮⾒に来てください