Submit Search
Upload
Velocity - Lean, Velocity and Anti-Fragile 「ボトルネックを飼い慣らせ!」
•
4 likes
•
2,141 views
Shuji Yamada
Follow
2015年10月27日開催 さくらガレージ オペレーション勉強会用資料です。 Velocity とは、「方向性のある集中的な勢い」のことです。 @uzyexe
Read less
Read more
Engineering
Report
Share
Report
Share
1 of 40
Download now
Download to read offline
Recommended
ボトルネックを解消せよ
ボトルネックを解消せよ
Masanori Hayashi
TOCから俯瞰するリーンスタートアップ
TOCから俯瞰するリーンスタートアップ
Taro Kawai
Ad tech 勉強会 20140115
Ad tech 勉強会 20140115
ajiyoshi
パフォーマンス ボトルネック 国内あるある事例
パフォーマンス ボトルネック 国内あるある事例
日本Javaユーザーグループ
ローカル環境のテスト自動化【勉強会資料】
ローカル環境のテスト自動化【勉強会資料】
株式会社キャッチアップ
話すハードルを下げてみる
話すハードルを下げてみる
irof N
TOC-ICO2014マフィアオファーから始めるセールスバッファマネジメント
TOC-ICO2014マフィアオファーから始めるセールスバッファマネジメント
ゴールシステムコンサルティング株式会社
LT(自由)
LT(自由)
Recruit Technologies
Recommended
ボトルネックを解消せよ
ボトルネックを解消せよ
Masanori Hayashi
TOCから俯瞰するリーンスタートアップ
TOCから俯瞰するリーンスタートアップ
Taro Kawai
Ad tech 勉強会 20140115
Ad tech 勉強会 20140115
ajiyoshi
パフォーマンス ボトルネック 国内あるある事例
パフォーマンス ボトルネック 国内あるある事例
日本Javaユーザーグループ
ローカル環境のテスト自動化【勉強会資料】
ローカル環境のテスト自動化【勉強会資料】
株式会社キャッチアップ
話すハードルを下げてみる
話すハードルを下げてみる
irof N
TOC-ICO2014マフィアオファーから始めるセールスバッファマネジメント
TOC-ICO2014マフィアオファーから始めるセールスバッファマネジメント
ゴールシステムコンサルティング株式会社
LT(自由)
LT(自由)
Recruit Technologies
GitHub Enterpriseの導入事例と実践GitHub Actions
GitHub Enterpriseの導入事例と実践GitHub Actions
Shuji Yamada
ここにハマった!Dockerコンテナホスティング「Arukas」の裏側
ここにハマった!Dockerコンテナホスティング「Arukas」の裏側
Shuji Yamada
現場!実物!実践!マルチクラスタを運用するときの課題とコツ
現場!実物!実践!マルチクラスタを運用するときの課題とコツ
Shuji Yamada
Arukas meet Mesos/Marathon
Arukas meet Mesos/Marathon
Shuji Yamada
20分でわかるgVisor入門
20分でわかるgVisor入門
Shuji Yamada
10分でわかる Cilium と XDP / BPF
10分でわかる Cilium と XDP / BPF
Shuji Yamada
会社にGitHub Enterpriseを導入してみた話
会社にGitHub Enterpriseを導入してみた話
Shuji Yamada
10分でわかる marathon-lb
10分でわかる marathon-lb
Shuji Yamada
コンテナのユースケース考察
コンテナのユースケース考察
Shuji Yamada
Kanban 301「プロセスマネジメント(成長エンジン)」
Kanban 301「プロセスマネジメント(成長エンジン)」
Shuji Yamada
Kanban 101「明日から使えるかもしれないカンバン」
Kanban 101「明日から使えるかもしれないカンバン」
Shuji Yamada
自動テストによって生み出される価値
自動テストによって生み出される価値
Shuji Yamada
2015-07-27 Docker Introduction 〜Dockerの基礎とユースケースに関する考察〜
2015-07-27 Docker Introduction 〜Dockerの基礎とユースケースに関する考察〜
Shuji Yamada
お手軽OpenFlow試験環境 Mininet
お手軽OpenFlow試験環境 Mininet
Shuji Yamada
Sensu -The Next Generateion Monitoring Framework-
Sensu -The Next Generateion Monitoring Framework-
Shuji Yamada
【Interop Tokyo 2013】 どうする?どうなる?SDN/クラウド時代の運用管理 ~データセンター、クラウド提供事業者の立場から~
【Interop Tokyo 2013】 どうする?どうなる?SDN/クラウド時代の運用管理 ~データセンター、クラウド提供事業者の立場から~
Shuji Yamada
2015-01-27 Introduction to Docker
2015-01-27 Introduction to Docker
Shuji Yamada
More Related Content
More from Shuji Yamada
GitHub Enterpriseの導入事例と実践GitHub Actions
GitHub Enterpriseの導入事例と実践GitHub Actions
Shuji Yamada
ここにハマった!Dockerコンテナホスティング「Arukas」の裏側
ここにハマった!Dockerコンテナホスティング「Arukas」の裏側
Shuji Yamada
現場!実物!実践!マルチクラスタを運用するときの課題とコツ
現場!実物!実践!マルチクラスタを運用するときの課題とコツ
Shuji Yamada
Arukas meet Mesos/Marathon
Arukas meet Mesos/Marathon
Shuji Yamada
20分でわかるgVisor入門
20分でわかるgVisor入門
Shuji Yamada
10分でわかる Cilium と XDP / BPF
10分でわかる Cilium と XDP / BPF
Shuji Yamada
会社にGitHub Enterpriseを導入してみた話
会社にGitHub Enterpriseを導入してみた話
Shuji Yamada
10分でわかる marathon-lb
10分でわかる marathon-lb
Shuji Yamada
コンテナのユースケース考察
コンテナのユースケース考察
Shuji Yamada
Kanban 301「プロセスマネジメント(成長エンジン)」
Kanban 301「プロセスマネジメント(成長エンジン)」
Shuji Yamada
Kanban 101「明日から使えるかもしれないカンバン」
Kanban 101「明日から使えるかもしれないカンバン」
Shuji Yamada
自動テストによって生み出される価値
自動テストによって生み出される価値
Shuji Yamada
2015-07-27 Docker Introduction 〜Dockerの基礎とユースケースに関する考察〜
2015-07-27 Docker Introduction 〜Dockerの基礎とユースケースに関する考察〜
Shuji Yamada
お手軽OpenFlow試験環境 Mininet
お手軽OpenFlow試験環境 Mininet
Shuji Yamada
Sensu -The Next Generateion Monitoring Framework-
Sensu -The Next Generateion Monitoring Framework-
Shuji Yamada
【Interop Tokyo 2013】 どうする?どうなる?SDN/クラウド時代の運用管理 ~データセンター、クラウド提供事業者の立場から~
【Interop Tokyo 2013】 どうする?どうなる?SDN/クラウド時代の運用管理 ~データセンター、クラウド提供事業者の立場から~
Shuji Yamada
2015-01-27 Introduction to Docker
2015-01-27 Introduction to Docker
Shuji Yamada
More from Shuji Yamada
(17)
GitHub Enterpriseの導入事例と実践GitHub Actions
GitHub Enterpriseの導入事例と実践GitHub Actions
ここにハマった!Dockerコンテナホスティング「Arukas」の裏側
ここにハマった!Dockerコンテナホスティング「Arukas」の裏側
現場!実物!実践!マルチクラスタを運用するときの課題とコツ
現場!実物!実践!マルチクラスタを運用するときの課題とコツ
Arukas meet Mesos/Marathon
Arukas meet Mesos/Marathon
20分でわかるgVisor入門
20分でわかるgVisor入門
10分でわかる Cilium と XDP / BPF
10分でわかる Cilium と XDP / BPF
会社にGitHub Enterpriseを導入してみた話
会社にGitHub Enterpriseを導入してみた話
10分でわかる marathon-lb
10分でわかる marathon-lb
コンテナのユースケース考察
コンテナのユースケース考察
Kanban 301「プロセスマネジメント(成長エンジン)」
Kanban 301「プロセスマネジメント(成長エンジン)」
Kanban 101「明日から使えるかもしれないカンバン」
Kanban 101「明日から使えるかもしれないカンバン」
自動テストによって生み出される価値
自動テストによって生み出される価値
2015-07-27 Docker Introduction 〜Dockerの基礎とユースケースに関する考察〜
2015-07-27 Docker Introduction 〜Dockerの基礎とユースケースに関する考察〜
お手軽OpenFlow試験環境 Mininet
お手軽OpenFlow試験環境 Mininet
Sensu -The Next Generateion Monitoring Framework-
Sensu -The Next Generateion Monitoring Framework-
【Interop Tokyo 2013】 どうする?どうなる?SDN/クラウド時代の運用管理 ~データセンター、クラウド提供事業者の立場から~
【Interop Tokyo 2013】 どうする?どうなる?SDN/クラウド時代の運用管理 ~データセンター、クラウド提供事業者の立場から~
2015-01-27 Introduction to Docker
2015-01-27 Introduction to Docker
Velocity - Lean, Velocity and Anti-Fragile 「ボトルネックを飼い慣らせ!」
1.
1 Velocity Shuji Yamada @uzyexe lean,velocityandanti-fragile. Oct 27,
2015 「ボトルネックを飼い慣らせ!」
2.
https://www.flickr.com/photos/shawnclover/6287072270/ 生産方式のパラダイムシフト 2
3.
https://www.flickr.com/photos/ifhp97/9303599413/ フォード生産方式 • 一定の期間において特定の商品を大量に生産する。(一品種大量生産) • 部品の標準化、流れ作業、計画生産(押し出し式)、専門工の細分化。 •
スケールアップの追及。 • 過度な分業体制の推進による製品品質の悪化を招いた。 3
4.
https://www.flickr.com/photos/mishpo/3659654143/ GM生産方式 • 一定の期間において大量の商品を大量に生産する。(多品種大量生産) • 製品ラインアップ、事業部制、市場管理、財務管理。 •
体系的な管理の追求。 • 分業体制による製品品質の低下は抑制できなかった。 • 1品種1工場体制のため、市場の急激な変化には対応できなかった。 4
5.
https://www.flickr.com/photos/toyotamheurope/8472007819/ トヨタ生産方式 • 必要なものを必要なときに必要なだけ生産する。(多品種少量生産) • 分業の廃止、カンバンの導入、リードタイム短縮、引き出し式、現場主義。 •
クオリティの追求。 • 高品質な製品をムダなく完全受注生産することが可能になった。 5
6.
https://www.flickr.com/photos/theenmoy/14238871026/ オペレーションを取り巻く環境 6
7.
https://www.flickr.com/photos/kenmainr/8878270120/ インフラサービスは顧客の需要に即して、 24/365 で高品質なサービスを提供する必要がある。 7
8.
https://www.flickr.com/photos/shawnclover/6287072270/ 顧客のニーズに対して高品質なサービスを提供することで、 さらなる富が生まれる。 8
9.
https://www.flickr.com/photos/pilotsofswiss/5198554028/ オペレーションの課題 • 一つのラインで複数のサービスに対応する必要がある。 • オペレーションに負担がかかりやすい。 •
オペレーションが不安定になりやすい。 9
10.
https://www.flickr.com/photos/shawnclover/6287072270/ ムリ・ムダ・ムラ • ムリ:負荷が高い状態。 • ムダ:無意味な処理や成果物。 •
ムラ:能力や性質が一定ではない状態。 10
11.
カオス • カオス =
混沌、無秩序、機能不全。 • 不安定な環境は、より不安定な状況に追い込まれやすい。 • カオス状態に陥ったオペレーションの引き上げは多大な苦労を要する。 http://www.itskeptic.org/kamu 11
12.
https://www.flickr.com/photos/edo-finelight/287074613/ 不安定な環境が引き起こす負の連鎖 • 些細なトラブルで混乱が生じる。 • トラブルの連鎖。 •
衝突の発生。 • ストレスの増加。 12
13.
https://www.flickr.com/photos/edo-finelight/287074613/ 様々な制約が様々なタイミングで生じることで、 システム全体のスループットが不安定になる。 13
14.
https://www.flickr.com/photos/jamesyu/13042995/ システム全体のスループットとは? • システムの上流から下流までにおける全体の生産性。 • システム全体のスループットはボトルネックに制約される。 •
システム全体のスループットが低下すると負債が蓄積される。 14
15.
ボトルネック http://agileattorney.net/2014/07/30/legal-ops-doing-the-thing-wrong-or-doing-the-wrong-thing/ 15
16.
http://agileattorney.net/2014/07/30/legal-ops-doing-the-thing-wrong-or-doing-the-wrong-thing/ ボトルネックは悪? • ボトルネックは悪ではなく、単なる現実。 • ボトルネックは飼い慣らすもの! •
システム全体の安定化には、ボトルネックの特性や性能を最大限に活用する方 策を考える必要がある。 16
17.
https://www.flickr.com/photos/arlophoto/3277486134/ 制約とボトルネックの違い • 制約 =
スループットを一時的に、もしくは断続的に制約するもの。 • ボトルネック = 全体のスループットを制御する役割を担っているもの。 17
18.
https://en.wikipedia.org/wiki/Population_bottleneck 現場で制約になりがちなものは何か? 18 • 承認作業/確認作業 • 計画外タスク •
予算、設備・機材、人員 • ルールやポリシー • トラブル
19.
http://agileattorney.net/2014/07/30/legal-ops-doing-the-thing-wrong-or-doing-the-wrong-thing/ ボトルネックはどこにあるのか • オペレーションが安定化しているサービス業であれば・・・ • 需要こそが最大のボトルネックになる。 •
オペレーションが不安定なサービス業であれば・・・ • オペレーションがボトルネックになりがち。 19
20.
https://www.flickr.com/photos/edenpictures/13048651414/ 不安定な現場で生まれる負債とその影響 • タスクや在庫が増え続ける。 • 有効活用されないリソースが増え続ける。 •
納期を守れなくなる。 • 顧客が逃げ出す。 • 利益が無くなる。 • 会社が潰れる。 20
21.
https://www.flickr.com/photos/r-z/384866837/ システム全体のスループットが向上するとどうなる? • タスクや在庫が最小限になる。 • リソースが有効活用される。 •
納期を守れる。 • 顧客が増える。 • 利益が増える。 • みんなが成長する。 21
22.
https://www.pakutaso.com/20130926245post-3235.html タスクが減ると・・・ 従業員がリストラされるのでは? 22
23.
... 23
24.
24
25.
https://www.flickr.com/photos/shawnclover/6287072270/ タスクが減ると従業員がリストラされる? • 富が拡大し続けることが中長期的な大前提にある近代経済において、単なるコ ストカットを目的とした人員削減は一般的に得策ではない。 • 余剰したリソース(ヒト、モノ、カネ)を営業・開発・運用に活用し、さらな るサービス拡充や市場の拡大を目指す選択をしたほうが合理的。 25
26.
https://www.pakutaso.com/20141237343post-4921.html ここで問題です。 • 各ワークセンターの稼働率を100%に近い状態にバランスさせるべきか? • ボトルネック本体のスループットを改善するべきか? •
非ボトルネックのスループットも改善するべきか? • ボトルネックの生産性に合わせてシステム全体のフローを再編するべきか? 26
27.
各ワークセンターの稼働率を100%に近づけるとどうなる? 27
28.
https://www.flickr.com/photos/shawnclover/6287072270/ 稼働率が 100% に近づくほど・・・ •
トラブルに対して脆弱になる。 • 余剰リソースが枯渇しやすくなる。 • タスク実行までの待ち時間(キュー)が長くなる。 • トラブルが連鎖する。 • システム全体のスループット低下に繋がる。 28
29.
ボトルネックのスループットを改善すべきか? 29
30.
https://www.flickr.com/photos/ctaweb/7516076366/ ボトルネックのスループット改善 • システム全体が安定しており、需要が供給を上回る見込みがある状況であれば、 ボトルネックのスループット改善に挑戦する価値がある。 • どうやっても需要が現在の供給量を上回る見込みがしばらくない状況では、ボ トルネックのスループットをただちに改善する必要はない。 •
システム全体が不安定な場合、ボトルネックのスループットが改善されると新た なボトルネックが別の場所に発生(移動)するため、新たな混乱が生じる。 30
31.
非ボトルネックのスループットも改善すべきか? 31
32.
https://www.flickr.com/photos/shawnclover/6287072270/ 非ボトルネックのスループット改善 • 非ボトルネックが改善されてもシステム全体のスループットは向上しない。 • しかし、中長期的には現場のストレスを削減する効果をもたらす。 •
ほとんどの場合、効果以上のコストをかける必要はない。 32
33.
システム全体のフローをボトルネックのスルー プットに合わせて再編するべきか? 33
34.
• システム全体をボトルネックの能力や特性に協調させながら改善を繰り返すこ とでシステムは安定する。 • 安定と成長は共存関係にある。 •
安定なくして成長はなく、成長なくして安定はない。 • 安定しているのであれば成長を目指し、不安定なら安定化を優先する。
35.
改善 = コスト削減や使用効率の最適化ではない •
コスト削減や効率の最適化を目的とした取り組みは実行しやすい。 • しかし、それはすぐに収穫逓減の限界に達してしまう。 • コスト削減や使用効率の最適化を進めるほど、現場は最適な状態から遠ざかる。 • 『最適化』と『改善』は、本質的に意味合いが異なる。 • 平時の際にはムダのように見えるけれども、有事の際には即時投入できる余剰リ ソースの存在が安定と成長のためには欠かせない。 35
36.
改善 = 最高のサービスを顧客に届けるための活動 •
生産性や利益は、理論的には無限の経済成長を遂げることができる。 • 生産性と利益の拡大によって得られた余剰リソースを活用して、営業/開発/運用 を強化拡大して新サービスの開発や新しい市場を切り開くのが最も合理的。 36
37.
0.1%の要因が、結果の99.9%を左右することがある • 複数の要素が絡み合うことで結果が生まれる。 • その場合、0.1%
の要素が結果の 99.9% を左右することがある。 • 多くの場合、誤った前提が修正されるだけで結果は良い方向に転がる。 • 『全体を改善すること』と『すべてを改善すること』は同義ではない。 37
38.
https://www.flickr.com/photos/lucaheron/1559081070/ 全体の生産性を高めるにはどうすればいいか • ボトルネックの性能や特徴に合わせて、ボトルネックの周辺に存在する制約の 再編(ポリシー変更/役割分担/アウトソーシングなど)や強化(並列化/高速化/ 自働化など)のような改善を繰り返す。 • ボトルネックをボトルネックのままにしておくのが賢明であるときもある。 •
全体をバランスさせるほど各ワークセンターの稼働率は100%に近づく。全体を バランスさせずに意図してアンバランスにする手法が安定化のためには必要。 38
39.
https://www.flickr.com/photos/53558245@N02/4978362207/ 本当に重要なものは数字にはできない • 本当に重要な指標は、売上や利益のように数字やグラフで表せるものではない。 • コミュニケーションやコラボレーションのような和
(WA) 、モチベーションや時 間、お客様からの信頼といった目には見えない要素まで改善されることが重要。 • 衝突が生まれるときの多くの要因は、誰かが作った前提が間違っている。 • 最高の環境で最高の仕事をして最高のサービスをお客様に提供できる環境こそが、 成長と幸せを分かち合うことができる Win-Win な環境であることには違いない。 39
40.
Any Questions? https://www.flickr.com/photos/skrubu/3345244660/ 40
Download now