Slide 1

Slide 1 text

どうしてこんな研修を やっているのかを 伝えたいスライド

Slide 2

Slide 2 text

二枚のピザのチーム

Slide 3

Slide 3 text

3 アマゾンの初期の頃、ジェフ・ベゾスは「すべての社内チームは、ピザ2 枚で食べられるくらいに小さくすべきだ」というルールを制定しました。 目標はケータリング代を削減することではありませんでした。それは、 Amazonが行うほとんどすべてのことと同じように、効率性とスケーラビ リティという2つの目的に焦点を当てたものでした。前者は明らかです。 小規模なチームであれば、スケジュール管理や最新情報の提供に費やす 時間が減り、やるべきことに多くの時間を割くことができます。しかし、 Amazonにとって本当に重要なのは後者です。 多くの小さなチームを持つということは、大きな目標を達成するために は、チーム全員が協力して仕事ができ、会社の共通のリソースにアクセ スできる必要があるということです。 https://www.theguardian.com/technology/2018/apr/24/th e-two-pizza-rule-and-the-secret-of-amazons-success

Slide 4

Slide 4 text

4

Slide 5

Slide 5 text

5 未来は予測するものではなく、発明するものだ。 "We don't predict the future. we invent it." (Allan Kay) 出すぎた杭は誰も打てない。 (作者不詳) 人生は短い "Life is too short" (慣用句?ニコラス・ネグロポンテ→石井さん) 学際っていう場合、多くの場合、例えば技術系の人がアート系の人と協力し合って、コラボレートすること だと思っている方がいます。 それはどういう仮定を含んでいるかというと、アーティストは、ハンダ付けしない、電気工学わからなくて いい、C++のLanguageが書けなくていい。一方、技術者は、アートの本質的なConceptとかTheoryに貢献す ることを期待されていない。 これはわれわれにとって本当のコラボレーションだと思っていません。 すなわち各人が、各研究者も教授も、アーティストでありデザイナーでありサイエンティストでありエンジ ニアであり、なおかつ教授の場合ビジネスマンでもなきゃいけない。 一人の人間がすべてでなきゃいけない。 すなわち、ひとつのラベルを貼って、レッテルを貼って、あなたは技術者、あなたはCognitive Science(認知 科学)、あなたはSociology、といった時代ではもうなくなっている。 逆に解かなきゃいけない問題がこれだけ複雑になって、人間、その信義、そのsociety、commitと、 これだけ複雑に絡んでいるときに、それをデザインするときに、ひとつの学問だけでやっていく時代はもう 終わっている。 もちろんすべての学問でNo.1にはなれませんけども、 それぞれの言語をfluentに話し、深く尊敬し、そういうチームをまとめられるリーダーでないと、これから やっていけない、というふうに思います。 それがわれわれの学際の違いです。 (石井裕さん)

Slide 6

Slide 6 text

6 未来は予測するものではなく、発明するものだ。 "We don't predict the future. we invent it." (Allan Kay) 出すぎた杭は誰も打てない。 (作者不詳) 人生は短い "Life is too short" (慣用句?ニコラス・ネグロポンテ→石井さん) 学際っていう場合、多くの場合、例えば技術系の人がアート系の人と協力し合って、コラボレートすること だと思っている方がいます。 それはどういう仮定を含んでいるかというと、アーティストは、ハンダ付けしない、電気工学わからなくて いい、C++のLanguageが書けなくていい。一方、技術者は、アートの本質的なConceptとかTheoryに貢献す ることを期待されていない。 これはわれわれにとって本当のコラボレーションだと思っていません。 すなわち各人が、各研究者も教授も、アーティストでありデザイナーでありサイエンティストでありエンジ ニアであり、なおかつ教授の場合ビジネスマンでもなきゃいけない。 一人の人間がすべてでなきゃいけない。 すなわち、ひとつのラベルを貼って、レッテルを貼って、あなたは技術者、あなたはCognitive Science(認知 科学)、あなたはSociology、といった時代ではもうなくなっている。 逆に解かなきゃいけない問題がこれだけ複雑になって、人間、その信義、そのsociety、commitと、 これだけ複雑に絡んでいるときに、それをデザインするときに、ひとつの学問だけでやっていく時代はもう 終わっている。 もちろんすべての学問でNo.1にはなれませんけども、 それぞれの言語をfluentに話し、深く尊敬し、そういうチームをまとめられるリーダーでないと、これから やっていけない、というふうに思います。 それがわれわれの学際の違いです。 (石井裕さん) 未来は予測するものではなく、発明するものだ。 "We don't predict the future. we invent it." (Allan Kay) 出すぎた杭は誰も打てない。 (作者不詳) 人生は短い "Life is too short" (ニコラス・ネ グロポンテ)

Slide 7

Slide 7 text

7 未来は予測するものではなく、発明するものだ。 "We don't predict the future. we invent it." (Allan Kay) 出すぎた杭は誰も打てない。 (作者不詳) 人生は短い "Life is too short" (慣用句?ニコラス・ネグロポンテ→石井さん) 学際っていう場合、多くの場合、例えば技術系の人がアート系の人と協力し合って、コラボレートすること だと思っている方がいます。 それはどういう仮定を含んでいるかというと、アーティストは、ハンダ付けしない、電気工学わからなくて いい、C++のLanguageが書けなくていい。一方、技術者は、アートの本質的なConceptとかTheoryに貢献す ることを期待されていない。 これはわれわれにとって本当のコラボレーションだと思っていません。 すなわち各人が、各研究者も教授も、アーティストでありデザイナーでありサイエンティストでありエンジ ニアであり、なおかつ教授の場合ビジネスマンでもなきゃいけない。 一人の人間がすべてでなきゃいけない。 すなわち、ひとつのラベルを貼って、レッテルを貼って、あなたは技術者、あなたはCognitive Science(認知 科学)、あなたはSociology、といった時代ではもうなくなっている。 逆に解かなきゃいけない問題がこれだけ複雑になって、人間、その信義、そのsociety、commitと、 これだけ複雑に絡んでいるときに、それをデザインするときに、ひとつの学問だけでやっていく時代はもう 終わっている。 もちろんすべての学問でNo.1にはなれませんけども、 それぞれの言語をfluentに話し、深く尊敬し、そういうチームをまとめられるリーダーでないと、これから やっていけない、というふうに思います。 それがわれわれの学際の違いです。 (石井裕さん) すなわち各人が、各研究者も教授も、アー ティストでありデザイナーでありサイエン ティストでありエンジニアであり、なおか つ教授の場合ビジネスマンでもなきゃいけ ない。

Slide 8

Slide 8 text

8 未来は予測するものではなく、発明するものだ。 "We don't predict the future. we invent it." (Allan Kay) 出すぎた杭は誰も打てない。 (作者不詳) 人生は短い "Life is too short" (慣用句?ニコラス・ネグロポンテ→石井さん) 学際っていう場合、多くの場合、例えば技術系の人がアート系の人と協力し合って、コラボレートすること だと思っている方がいます。 それはどういう仮定を含んでいるかというと、アーティストは、ハンダ付けしない、電気工学わからなくて いい、C++のLanguageが書けなくていい。一方、技術者は、アートの本質的なConceptとかTheoryに貢献す ることを期待されていない。 これはわれわれにとって本当のコラボレーションだと思っていません。 すなわち各人が、各研究者も教授も、アーティストでありデザイナーでありサイエンティストでありエンジ ニアであり、なおかつ教授の場合ビジネスマンでもなきゃいけない。 一人の人間がすべてでなきゃいけない。 すなわち、ひとつのラベルを貼って、レッテルを貼って、あなたは技術者、あなたはCognitive Science(認知 科学)、あなたはSociology、といった時代ではもうなくなっている。 逆に解かなきゃいけない問題がこれだけ複雑になって、人間、その信義、そのsociety、commitと、 これだけ複雑に絡んでいるときに、それをデザインするときに、ひとつの学問だけでやっていく時代はもう 終わっている。 もちろんすべての学問でNo.1にはなれませんけども、 それぞれの言語をfluentに話し、深く尊敬し、そういうチームをまとめられるリーダーでないと、これから やっていけない、というふうに思います。 それがわれわれの学際の違いです。 (石井裕さん) もちろんすべての学問でNo.1にはなれませ んけども、それぞれの言語をfluentに話し、 深く尊敬し、そういうチームをまとめられ るリーダーでないと、これからやっていけ ない、というふうに思います。

Slide 9

Slide 9 text

9 > whoami Yasunobu kawaguchi Agile Coach Scrum Alliance Certified Scrum Professional

Slide 10

Slide 10 text

10 Jan 2011 Dr. Jeff Sutherland Prof. Ikujiro Nonaka INNOVATION SPRINT 2011 @ Rakuten Tower 1 Co-creator of Scrum

Slide 11

Slide 11 text

11 Software Is Eating The World by Marc Andreessen (2011) Amazon Netflix Spotify Rovio (AngryBirds) Pixer Google Skype Connected Cars Wal-Mart / FedEx PayPal

Slide 12

Slide 12 text

12 In 2001, 17 people gathered to discuss… Jeff Sutherland and Ken Schwaber Kent Beck Martin Fowler Robert Martin Alistair Cockburn Ron Jeffries Ward Cunningham Dave Thomas And more …

Slide 13

Slide 13 text

13 http://agilemanifesto.org/

Slide 14

Slide 14 text

14

Slide 15

Slide 15 text

15

Slide 16

Slide 16 text

16 マ ジ

Slide 17

Slide 17 text

17

Slide 18

Slide 18 text

18

Slide 19

Slide 19 text

19

Slide 20

Slide 20 text

20

Slide 21

Slide 21 text

21

Slide 22

Slide 22 text

22

Slide 23

Slide 23 text

37 アジャイルちゃんは、 いろんなところで つかわれるように なりました

Slide 24

Slide 24 text

38

Slide 25

Slide 25 text

44

Slide 26

Slide 26 text

45 http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr Flickr

Slide 27

Slide 27 text

46 http://www.slideshare.net/jallspaw/10- deploys-per-day-dev-and-ops- cooperation-at-flickr 1.インフラ自動化 2. バージョン管理の共有 3. ビルド&デプロイ一発 4. フィーチャーフラグ 5. メトリクスの共有 6. チャットとロボット 1.尊敬 2.信頼 3.失敗への健全な態度 4.非難しない

Slide 28

Slide 28 text

47 Amazon Web Services http://www.slideshare.net/shivamaan/devops-and-aws Facebook http://www.infoq.com/presentations/Facebook-Release-Process https://www.google.com/events/io/sc hedule/session/c9e32eaf-4acb- e311-b297-00155d5066d7 Google

Slide 29

Slide 29 text

48 Microsoft Yahoo! 歴史ある企業でもDevOpsへの移行が起きている…

Slide 30

Slide 30 text

49 北米トヨタの事例 “アジャイル開発は、数年前から幾つかの チームでスタートしていたが、1年半前に 全面的に導入した。ウエスト氏は、ある 大規模なプロジェクトが大きく改善した 事例を挙げた。そのプロジェクトはリ リース日を6回延期した停滞状態から、ス クラム(アジャイル開発の手法の1つ)を 実践。必要最低限のプロダクトに集中し て開発を進めることにより、2017年8月 に最初のリリース日を迎え、その後は2週 間に1度のリリースを実践できるように なった。チームの規模も200人体制から 25人まで縮小することができた。” http://monoist.atmarkit.co.jp/mn/articles/1803/09/news057.html

Slide 31

Slide 31 text

50 トヨタ自動車にとって「アジャイル(身軽な、機敏 な)」とは(クリックして拡大) 出典:トヨタ自動車 http://monoist.atmarkit.co.jp/mn/ articles/1803/09/news057.html

Slide 32

Slide 32 text

51 Michimune Kono @Microsoft RSGT2018

Slide 33

Slide 33 text

52 「クラウドというのは、大きな、 いろんなサービスの集合体ですから、 たとえば自分のところが動いていても、 ほかのサービスがダウンしているということは 当たり前に起きます。 ネットワークが切れたり、OSがおかしくなったり、 毎日どこかが壊れているんです。」 Regional Scrum Gathering Tokyo 2018 基調講演より

Slide 34

Slide 34 text

53 「ある時点で何かがちゃんと動いてても、 次の週にはその前提が変わっている。 完璧というのが世の中に存在しないんです。 その中でどうやってシステムを動かし続けるか。 答えないんですけど、 その答えない中で考えるのがそのすごく楽しい。 たぶんご理解いただけると思うんですけど。」 Regional Scrum Gathering Tokyo 2018 基調講演より

Slide 35

Slide 35 text

54 「そういうなかで、安心して どんどん新しいことを試したり、 テレメトリ新しいのをデプロイしたりするには、 やっぱり、背骨がしっかりしないとだめでして、 そのおっきな一つが、CIがちゃんと回っている、 チェックインのモニタリングがちゃんとが回っている、 というのは絶対必要だなと思います。」 Regional Scrum Gathering Tokyo 2018 基調講演より

Slide 36

Slide 36 text

二枚のピザのチーム