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 and Agile organization,...
Search
Daisuke Sato
April 02, 2018
Technology
82
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ソフトウェアとアジャイル組織/Software and Agile organization, and then
ソフトウェアとアジャイル組織の関係、なぜアジャイルなのか。
Daisuke Sato
April 02, 2018
More Decks by Daisuke Sato
See All by Daisuke Sato
人と組織に偏重したEMへのアンチテーゼ──なぜ、EMに設計力が必要なのか/An antithesis to the overemphasis of people and organizations in EM
dskst
8
1.3k
エンジニアのための事業貢献入門/A business introduction for engineers
dskst
93
34k
Management Workflow
dskst
2
990
スタートアップのマネージャーに役立つ視座/A useful perspective for startup managers
dskst
6
2.4k
「時」と「場」を捉える、プロダクトづくりのためのリーダーシップ/Leadership for product creation that captures time and place
dskst
3
740
事業紹介/Joystruct
dskst
0
5k
キャリア理論をもとに考えるエンジニアのキャリア/Engineer's careers based on career theory
dskst
10
5.7k
ソフトウェア開発とマネジメント/Software Development and Management
dskst
6
7.6k
エンジニアのためのマネジメント入門/Introduction to Management for Software Engineers
dskst
11
10k
Other Decks in Technology
See All in Technology
オントロジーって 結局なにもの? AI エージェントに「意味」を渡す知識設計の話
greenmidori
0
200
実践! SRE × AI - ABEMA における AIOps -
tetsuya28
8
3.1k
Railsで挑む大量データ永続化 〜600億件を永続化するための設計とボトルネックとの戦い〜
occhi
1
580
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
Browser Spec: Testing Hotwire with Ruby
takahashim
1
120
20261017福岡devIO 「AIは"良いダッシュボード"を作れるか?
jtakeda
0
160
アウトプット初心者、半年間のふりかえり
4o1sobblue
0
430
OptunaHub: ブラックボックス最適化のためのプラットフォーム
pfn
PRO
0
140
パスキーの自動テストはどこまでいけるのか
teamlab
PRO
0
250
hackers_champloo_2026_tidb
makocchi
0
160
PHPカンファレンス関西の招待状 / Invitation to PHP Conference Kansai
ykanoh
0
130
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
464
34k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
1
630
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
890
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
730
Side Projects
sachag
456
43k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
2
2.2k
Leveraging Curiosity to Care for An Aging Population
cassininazir
1
540
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.9k
Darren the Foodie - Storyboard
khoart
PRO
4
4k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
The Illustrated Guide to Node.js - THAT Conference 2024
reverentgeek
1
570
Bootstrapping a Software Product
garrettdimon
PRO
306
120k
Transcript
Software and Agile organization, and then daisuke sato
佐藤 大典/daisuke sato @dskst9 クラウドとアーキテクチャ、組織論が好 き。Certified ScrumMaster 犬と娘とアウトドアで心を浄化する。
ソフトウェアと 組織についてのお話。
ソフトウェアと 組織って関係あるのか?
Software ≠ Organization ? Software ≒ Organization ? Software =
Organization ?
Software ≠ Organization ? Software ≒ Organization ? Software =
Organization ?
コンウェイの法則 システムを設計する組織は、その構造 をそっくりまねた構造の設計を生み出 してしまう。
様々な組織の形 組織の形がそのプロダクトを表してい る気がする?
逆コンウェイの法則 自分たちの望ましいアーキテクチャを促進するた めに、チームと組織側を機動的に進化させる。理 想的には「技術的アーキテクチャ」が「ビジネスアー キテクチャ」の同形写像になるように。
マイクロサービスの本質は システムの話ではない。
価値のあるプロダクトを、 より早く提供するための 組織論のこと。
コンウェイの法則から考える マイクロサービス。
サービスを分割すると 起こること サービスを管理するチームが、サービ ス数に比例して必要になる。 では、細かいサービスがたくさんできる と何が起きるのか?
忙しくなってしまう!
忙しくなってしまう! 今までのやり方だと。
マイクロマネジメントから 脱却 マイクロマネジメントではリーダーがチームの限界に なる。サービスが増えることでさらに。
サーバントリーダーシップ コマンドアンドコントロールではなく。リーダーはまず 相手に奉仕し、導いていく。
自己組織化したチームを つくる 自らを管理し、自主性を持ったチームのこ と。 最良のアーキテクチャ・要求・設計は、自 己組織化したチームから生み出される。
例えば、
例えば、 スポーツの試合中、 次のアクションについて 監督の指示を待っていたら?
None
信じて裁量を渡す 裁量の境界を明確にして、裁量を渡すこ とでチームは自分たちで判断をできる。 裁量の範囲で最大のパフォーマンスが 発揮される。それは、あなたが想像し得 ないことかも。
価値提供が加速化す る チーム自身で判断できるので最速でプ ロダクトアウトしていく。
スポーツとマーケットは似てい る。
スポーツの戦況のように、 とてつもないスピードで 変化している。
自己組織化したチームで 変化とスピードに対応して 価値あるプロダクトを提供する ことが必要。
そこで、
そこで、 アジャイル開発 という考え方。
アジャイル開発とは? 迅速かつ適応的にソフトウェア開発を行 う軽量な開発手法群の総称。アジャイル とはその概念のことをいう。
アジャイル開発手法
Scrumとは? プロジェクトの現状を把握するためのフ レームワーク。 組織論、集団心理の要素から提唱され ており、 Scrum Team 全員が現状を把 握できる。課題を発見できる。 そして、自ら課題を解決していく。
Scrumの起源 1986年に野中郁次郎、竹内弘高の両氏により書か れた論文「The New New Product Development Game」が元になる。 最初のScrum Teamは1993年にJeff
Sutherlandと Ken Schwaberにより作られ、1995年にOOPSLAカ ンファレンスで世の中に紹介された。
None
とはいえ、 アジャイルやScrumって ただの流行りではないの?
31% 日本企業のアジャイル開発導入率。
90% Over 先進国企業のアジャイル開発導入率。
自部門で2年くらい試してみた。
Good, Bad を総評して、 私は以前の思想、手法より 優れていると感じる。
Bad • ヒエラルキー組織体に少しフィットしない • チームが醸成するまで 3ヶ月ほどかかる • Scrumを理解しないでやると壊れた Scrum になり害悪となる
• 従来の評価制度がマッチしない Good • マネージャーが不要になる • チームが自発的に動く • 早い、さらに小さく失敗できる • 変化に柔軟に対応できる • 誰が何をやっているのか全て把握可 • 課題を発見できる • チームがチームを改善していく Scrumの所感
Scrumのやり方
Scrumのやり方 実は19個のルールしかない。
Scrumのやり方 実は19個のルールしかない。 スクラムガイドという ルールブックで17ページしかない。 http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-ja.pdf
シンプル
None
アジャイルの考え方と Scrumという手法は、
アジャイルの考え方と Scrumという手法は、 ソフトウェア開発以外にも適用 できる。
有効な選択肢の1つである チーム運営、プロジェクト管理の方法はた くさんあるが、その1つとしてScrumはい かが? 部門を跨ぎ自己組織化した多様なスキル セットを持つチームがいるのを想像すると おもしろい。
チームがサービスを変えて、
チームがサービスを変えて、 チームがプロダクトを変えてい く。
そんなチームを 目指しています。
ご静聴ありがとうございました。