Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
Software is eating the world
Search
Yasunobu Kawaguchi
PRO
July 01, 2020
Technology
230
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Software is eating the world
Yasunobu Kawaguchi
PRO
July 01, 2020
More Decks by Yasunobu Kawaguchi
See All by Yasunobu Kawaguchi
What the customer really needed
kawaguti
PRO
3
260
AI de Idea
kawaguti
PRO
2
150
Scalling up Excellence and Friction
kawaguti
PRO
3
230
OKRの本質 / Scrum Fest Osaka 2026
kawaguti
PRO
7
5.4k
Project Based Learning at TUT
kawaguti
PRO
1
100
Zoom2Youtube.Claude
kawaguti
PRO
4
790
アジャイルな経理と Claude Code と経営の未来
kawaguti
PRO
3
340
AIエージェントが教えてくれたプロダクトオーナーシップの本質
kawaguti
PRO
1
490
Claude Code x Accounting
kawaguti
PRO
2
480
Other Decks in Technology
See All in Technology
コンテナ運用におけるネットワーク・コンテナコストの削減方法/How to Reduce Network and Container Costs in Container Operations
masakiokuda
1
190
Rustuna: Rustによる高速なOptuna実装
pfn
PRO
0
190
JAWSUG TOHOKU 青森支部 「LoGoチャット」のAWS移行で 乗り越えたこと
taketakekaho
0
330
AI コーディングと人間の認知スループット / CTO Night & Day 2026 Morning Session / AI Coding and Human Cognitive Throughput
prog893
4
1.1k
[JAWS-UG彩の国埼玉#12]そろそろ準備する?re:Invent2026をやさしく解説 / reinvent2026-sainokuni
sh_fk2
1
340
無理せず続ける、子育てエンジニアの学び
codmoninc
PRO
0
870
Claude の新機能を、 出た日に触って社内に届けるまで
rfdnxbro
1
180
ストレスなくAIと付き合いたい!こんなときどうしてる?
namiki64
3
520
WasmをRustにする
sansantech
PRO
0
250
Persisting Massive Data with Rails ~Designing for 60 billion rows, and fighting the bottlenecks~ Railsで挑む大量データ永続化 〜600億件を永続化するための設計とボトルネックとの戦い〜
occhi
0
730
Railsで挑む大量データ永続化 〜600億件を永続化するための設計とボトルネックとの戦い〜
occhi
1
580
Code for Security プロジェクト紹介 2026年10月
yu23ki14
0
110
Featured
See All Featured
Optimizing for Happiness
mojombo
378
71k
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
1
280
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
890
Intergalactic Javascript Robots from Outer Space
tanoku
273
28k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
480
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.5k
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
3
3.9k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
270
Measuring & Analyzing Core Web Vitals
bluesmoon
9
1k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
330
Unlocking the hidden potential of vector embeddings in international SEO
frankvandijk
0
990
Bash Introduction
62gerente
615
220k
Transcript
どうしてこんな研修を やっているのかを 伝えたいスライド
二枚のピザのチーム
3 アマゾンの初期の頃、ジェフ・ベゾスは「すべての社内チームは、ピザ2 枚で食べられるくらいに小さくすべきだ」というルールを制定しました。 目標はケータリング代を削減することではありませんでした。それは、 Amazonが行うほとんどすべてのことと同じように、効率性とスケーラビ リティという2つの目的に焦点を当てたものでした。前者は明らかです。 小規模なチームであれば、スケジュール管理や最新情報の提供に費やす 時間が減り、やるべきことに多くの時間を割くことができます。しかし、 Amazonにとって本当に重要なのは後者です。 多くの小さなチームを持つということは、大きな目標を達成するために
は、チーム全員が協力して仕事ができ、会社の共通のリソースにアクセ スできる必要があるということです。 https://www.theguardian.com/technology/2018/apr/24/th e-two-pizza-rule-and-the-secret-of-amazons-success
4
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に話し、深く尊敬し、そういうチームをまとめられるリーダーでないと、これから やっていけない、というふうに思います。 それがわれわれの学際の違いです。 (石井裕さん)
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" (ニコラス・ネ グロポンテ)
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に話し、深く尊敬し、そういうチームをまとめられるリーダーでないと、これから やっていけない、というふうに思います。 それがわれわれの学際の違いです。 (石井裕さん) すなわち各人が、各研究者も教授も、アー ティストでありデザイナーでありサイエン ティストでありエンジニアであり、なおか つ教授の場合ビジネスマンでもなきゃいけ ない。
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に話し、 深く尊敬し、そういうチームをまとめられ るリーダーでないと、これからやっていけ ない、というふうに思います。
9 > whoami Yasunobu kawaguchi Agile Coach Scrum Alliance Certified
Scrum Professional
10 Jan 2011 Dr. Jeff Sutherland Prof. Ikujiro Nonaka INNOVATION
SPRINT 2011 @ Rakuten Tower 1 Co-creator of Scrum
11 Software Is Eating The World by Marc Andreessen (2011)
Amazon Netflix Spotify Rovio (AngryBirds) Pixer Google Skype Connected Cars Wal-Mart / FedEx PayPal
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 …
13 http://agilemanifesto.org/
14
15
16 マ ジ
17
18
19
20
21
22
37 アジャイルちゃんは、 いろんなところで つかわれるように なりました
38
44
45 http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr Flickr
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.非難しない
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
48 Microsoft Yahoo! 歴史ある企業でもDevOpsへの移行が起きている…
49 北米トヨタの事例 “アジャイル開発は、数年前から幾つかの チームでスタートしていたが、1年半前に 全面的に導入した。ウエスト氏は、ある 大規模なプロジェクトが大きく改善した 事例を挙げた。そのプロジェクトはリ リース日を6回延期した停滞状態から、ス クラム(アジャイル開発の手法の1つ)を 実践。必要最低限のプロダクトに集中し
て開発を進めることにより、2017年8月 に最初のリリース日を迎え、その後は2週 間に1度のリリースを実践できるように なった。チームの規模も200人体制から 25人まで縮小することができた。” http://monoist.atmarkit.co.jp/mn/articles/1803/09/news057.html
50 トヨタ自動車にとって「アジャイル(身軽な、機敏 な)」とは(クリックして拡大) 出典:トヨタ自動車 http://monoist.atmarkit.co.jp/mn/ articles/1803/09/news057.html
51 Michimune Kono @Microsoft RSGT2018
52 「クラウドというのは、大きな、 いろんなサービスの集合体ですから、 たとえば自分のところが動いていても、 ほかのサービスがダウンしているということは 当たり前に起きます。 ネットワークが切れたり、OSがおかしくなったり、 毎日どこかが壊れているんです。」 Regional Scrum
Gathering Tokyo 2018 基調講演より
53 「ある時点で何かがちゃんと動いてても、 次の週にはその前提が変わっている。 完璧というのが世の中に存在しないんです。 その中でどうやってシステムを動かし続けるか。 答えないんですけど、 その答えない中で考えるのがそのすごく楽しい。 たぶんご理解いただけると思うんですけど。」 Regional Scrum
Gathering Tokyo 2018 基調講演より
54 「そういうなかで、安心して どんどん新しいことを試したり、 テレメトリ新しいのをデプロイしたりするには、 やっぱり、背骨がしっかりしないとだめでして、 そのおっきな一つが、CIがちゃんと回っている、 チェックインのモニタリングがちゃんとが回っている、 というのは絶対必要だなと思います。」 Regional Scrum
Gathering Tokyo 2018 基調講演より
二枚のピザのチーム