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
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
Scalling up Excellence and Friction
kawaguti
PRO
3
83
OKRの本質 / Scrum Fest Osaka 2026
kawaguti
PRO
7
4.8k
Project Based Learning at TUT
kawaguti
PRO
1
83
Zoom2Youtube.Claude
kawaguti
PRO
4
760
アジャイルな経理と Claude Code と経営の未来
kawaguti
PRO
3
290
AIエージェントが教えてくれたプロダクトオーナーシップの本質
kawaguti
PRO
1
370
Claude Code x Accounting
kawaguti
PRO
2
450
Every Conversation Counts
kawaguti
PRO
0
480
Why we keep our community?
kawaguti
PRO
1
990
Other Decks in Technology
See All in Technology
Tab5をRubyで動くパソコンにする
kishima
2
280
現場に行くだけでは足りない——プロダクトエンジニアが業務の流れを捉える観点と、その鍛え方
takumiengineering
0
360
V8コントリビュート超入門
riyaamemiya
0
160
AI時代のAPI品質を支えるガードレール / API Guardrails for API quality in the AI era
yokawasa
1
200
あるけみー式LTスライド作成術
alchemy1115
1
120
AIで開発は速くなったのに、なぜ現場は楽にならないのか 〜あなたの組織のボトルネックを突き止めるワークショップ〜
jacopen
1
300
#jawssonic2026 あの時代が悪かった ~動かなかったSageMakerと共に迎えたイベント当日~
ktkn1129
0
140
日経電子版を支えていく Kasane Design System/fec_fukuoka
nikkei_engineer_recruiting
0
320
Snowflakeで実現する全社横断の顧客の声(VOC)分析・活用基盤@Snowflake World Tour Tokyo 2026
yuto16
0
120
Webとヘルスデータ
yukukotani
1
200
20260906 「AWS運用入門」著者が教える、運用業務への生成AI活用入門
masaruogura
0
260
推論の観測、できていますか? 〜 Google Cloud Gemini Enterprise Agent Platformで 3つの Gemini モデルを実測して踏んだ、評価の罠 〜
shukob
PRO
0
180
Featured
See All Featured
Design in an AI World
tapps
1
310
Unsuck your backbone
ammeep
672
58k
How Software Deployment tools have changed in the past 20 years
geshan
1
34k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Bootstrapping a Software Product
garrettdimon
PRO
306
120k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
202
76k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
10k
Building Applications with DynamoDB
mza
96
7.2k
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
6
1.2k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.9k
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
660
VelocityConf: Rendering Performance Case Studies
addyosmani
331
25k
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 基調講演より
二枚のピザのチーム