DevOpsを支える原則、
3つの道
2022/2/16
藤村 新
∼第3回 TOC実践分科会∼
自己紹介
• 藤村 新(ふじむら あらた)
• @aratafuji
• 46歳
• 転職多め(現在13社目)
• クラスメソッド株式会社 グローバル事業部
主な登壇歴
•Regional Scrum Gathering Tokyo 2015
•Agile Japan 2015
•Regional Scrum Gathering Tokyo 2016
•Scrum Fest Osaka 2019
•DevOpsDays Tokyo 2019
•DevOpsDays Taipei 2019
•XP祭り 2019
•Regional Scrum Gathering Tokyo 2020
•Developers Summit 2020
•Regional Scrum Gathering Tokyo 2021
•Scrum Fest Sapporo 2021
主な登壇歴
•Regional Scrum Gathering Tokyo 2015
•Agile Japan 2015
•Regional Scrum Gathering Tokyo 2016
•Scrum Fest Osaka 2019
•DevOpsDays Tokyo 2019
•DevOpsDays Taipei 2019
•XP祭り 2019
•Regional Scrum Gathering Tokyo 2020
•Developers Summit 2020
•Regional Scrum Gathering Tokyo 2021
•Scrum Fest Sapporo 2021
Agile(Scrum, XP)関連がほとんど
主な登壇歴
•Regional Scrum Gathering Tokyo 2015
•Agile Japan 2015
•Regional Scrum Gathering Tokyo 2016
•Scrum Fest Osaka 2019
•DevOpsDays Tokyo 2019
•DevOpsDays Taipei 2019
•XP祭り 2019
•Regional Scrum Gathering Tokyo 2020
•Developers Summit 2020
•Regional Scrum Gathering Tokyo 2021
•Scrum Fest Sapporo 2021
DevOps関連でも少しだけ…
DevOps
(と私)の歴史
8月
2008年
7月
3年働いたエキサイト退職
同僚が立ち上げたスタートアップ
へ転職🔥
Agile 2008
Agile Infrastructure and Operations:
How Infra-gile are You?
パトリック・デボア
(The DevOps Handbook共著[2016/10])
アヴリル・ラヴィーン来日ツアー
3キャリア公式&PCサイトを
1人Devで構築
9月 11月
結婚♥
エキサイト スタートアップ
6月
2009年
Velocity 2009
10+ Deploys per Day:
Dev and Ops Cooperation at Flickr
ジョン・アレスポウ & ポール・ハーモンド
スタートアップ退職
フリーランスエンジニアになる🔥
10月
スタートアップ フリーランス
DevOpsDays Ghent 2009
パトリック・デボア
2月
Continuous Deployment
ティモシー・フィッツ
http://timothy
fi
tz.com/2009/02/08/
continuous-deployment/
(DevOpsの文脈ではない)
9月
3月
自社サービスを模索しながらも受託開発メイン
9月
DevOpsDays Sydney
フリーランスエンジニア挫折
スタートアップに出戻り orz
10月
フリーランス スタートアップ(出戻り)
2月 6月 12月
DevOpsDays
Mountain View
DevOpsDays Hamburg
DevOpsDays
Brazil
11月
長男誕生♥
西海岸ノリの
スタートアップに常駐
7月
Continuous Delivery
ジェズ・ハンブル他
(The DevOps Handbook共著)
(DevOpsにも結構言及してる)
2010年
自社サービスを模索しながらも受託開発メイン
4月 10月
スタートアップ(出戻り) 西海岸ノリのスタートアップ
2月
西海岸ノリの
スタートアップに常駐
事業をピボットしたタイミングでジョイン
アジャイル開発、リーン・スタートアップ初体験
12月
8月
DevOpsDays
Melbourne
7月
DevOpsDays
Bangalore
常駐先へ転職
DevOpsDays
Goteborg
DevOpsDays
Manila
西海岸ノリで解雇🔥
GMOインターネットに出戻り
GMOインターネット
3月
DevOpsDays
Boston
6月
DevOpsDays
Mountain View
ソシャゲで
アジャイル開発
9月
2011年
4月 10月
DevOpsDays
Tokyo@GMO
インターネット
7月
DevOpsDays
Delhi
DevOpsDays
Rome
GMOインターネット
DevOpsDays
Austin Texas
6月
DevOpsDays
Mountain View
ソシャゲでアジャイル開発
5月
3月
グループ会社の新規プロジェクトで
スクラム初実践
ニアミス!
しかし不参加
2012年
12月
PMIアジャイルPM研究会
立ち上げプロジェクトに参画
リリース
9月
9月
GMOインターネット
6月
3月
DevOpsDaysは年18回開催!
New York (Winter)、New Zealand、London (Spring)、Paris、Austin、Berlin、Amsterdam、Silicon Valley、Sydney、
Tokyo、Tel Aviv、Atlanta、Barcelona、New York (Fall)、Vancouver、Portland、London (Autumn)、Bangalore
1月
The Phoenix Project
ジーン・キム他
(The DevOps Handbook共著)
2013年
「状況によって手作業で環境構築することを認めると、
Chefの利用が浸透しない」。
GMOインターネットの藤村 新氏(次世代システム
研究室 シニアアーキテクト)は、自身のチームでの
経験から、こう警鐘を鳴らす。
@ヤフー
8月
qpstudy 2013.01
「DevOpsをぶち壊せ
∼DevOps言うな∼」
DevOpsDays 開催数
0
20
40
60
80
2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
28
35
80
71
51
42
22
19
18
5
6
4
1
初参加!
初登壇!
初海外登壇!
DevOps
に対する
私のもやもや
DevOpsって、
ズルくない?
https://puppet.com/sites/default/
fi
les/inline-images/2016%20State%20of%20DevOps%20infographic.jpg
全部DevOpsの手柄?
‒Effective DevOps
実際、devops運動の背後にあるアイデア
の多くは、以前から別の名前で存在していた
ものが多い。しかし、devopsの時代精神
は、それらの部品の総和以上のものであり、
今までのものとは異なるものである。
これら全部DevOps傘下?
DevOpsって、
名前が悪くない?
当初はDevとOpsの対立構造解消にフォーカス
していたけど、その後解釈が拡大中
https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-
fl
ickr
DevOpsって、
なぜ定義
しないのか?
• devopsに関係があるのは開発者と管理者だけではない
• devopsはチームではない
• devopsは肩書きではない
• devopsはウェブ系のスタートアップだけの問題ではない
• devopsには認定資格が必要ではない
• devopsとは、半分の人員ですべての仕事をすることではない
• devopsには「正しい方法」(または「間違った方法」)はない
• devopsを取り入れるためにはX週間/Xヶ月かかるわけではない
• devopsはツールの問題ではない
• devopsとは自動化のことではない
• devopsは一時的な流行ではない
• devopsは以前のアイデアに新しい名前をつけただけではない
• 非難文化があるのはdevopsではない
• サイロ化しているのはdevopsではない
• 根本原因分析しているのはdevopsではない
• ヒューマンエラーという考え方はdevopsではない
• 割り込み文化はdevopsではない
• devopsは単なるアジャイルではない
• 「1日10デプロイ」を実践しているからといって「devopsをうまくやっている」
とは言えない
http://agilemanifesto.org/iso/ja/manifesto.html
アジャイルの価値と原則
https://www.slideshare.net/fkino/brief-history-of-agile-movement/15
DevOpsの価値と原則を
定義すれば良いのに
もやもやしながらも
DevOps導入支援
サービス始めてみた
定義なくして
支援なし!
定義してみた
変化の激しい
ビジネス環境において、
組織のビジネス競争力を向上
させること
DevOpsの目的
組織のビジネス競争力を
向上させるために行なう
全ての活動の総称
つまりDevOpsとは、
単なる標語
https://itrevolution.com/the-three-ways-principles-underpinning-devops/
2012/8
2013/1 2016/10
2013/1 2016/10
https://itrevolution.com/the-three-ways-principles-underpinning-devops/
2013/1 2016/10
3つの道
DevOpsを支える原則
•第1の道: フローの原則
•開発→運用→顧客の左から右へのワークフローを高速にする
3つの道: DevOpsを支える原則
•第1の道: フローの原則
•開発→運用→顧客の左から右へのワークフローを高速にする
•第2の道: フィードバックの原則
•右から左へのすばやくて持続的なフィードバックフローを実現する
3つの道: DevOpsを支える原則
•第1の道: フローの原則
•開発→運用→顧客の左から右へのワークフローを高速にする
•第2の道: フィードバックの原則
•右から左へのすばやくて持続的なフィードバックフローを実現する
•第3の道: 継続的な学習と実験の原則
•フィードバックループの継続的な短縮、強化により、かつてないほど安全
な作業システムを作ると、リスクテイクと実験がしやすくなり、競合他社
よりも早く学んで競争に勝ちやすくなる
3つの道: DevOpsを支える原則
3つの道: DevOpsを支える原則
変化に強い、継続的に学習する組織
•第1の道: フローの原則
•開発→運用→顧客の左から右へのワークフローを高速にする
•第2の道: フィードバックの原則
•右から左へのすばやくて持続的なフィードバックフローを実現する
•第3の道: 継続的な学習と実験の原則
•フィードバックループの継続的な短縮、強化により、かつてないほど安全
な作業システムを作ると、リスクテイクと実験がしやすくなり、競合他社
よりも早く学んで競争に勝ちやすくなる
DevOpsの
最初の一歩
可視化
•カンバン
•VSM
•カンバン
•VSM
1.見える化
2.WIPの制限
3.流れの管理
カンバンの重要な要素
https://lean-trenches.com/one-day-in-kanban-land/
①
②
③
④
⑤
⑥
https://lean-trenches.com/one-day-in-kanban-land/
⑦
⑧
⑨
⑩
⑪
•サイクルタイム
•プロセスの一部を完了する時間
•リードタイム
•プロセス全体を完了する時間
•スループット
•ある一定期間に完了した項目数
流れを管理するメトリクス
•カンバン
•VSM
https://dev.classmethod.jp/articles/value-stream-mapping/
https://dev.classmethod.jp/articles/value-stream-mapping/
VSMやってみてわかったこと
•全体のリードタイム、プロセスタイム、待ち時間
•LT(リードタイム)
•48日
•PT(プロセスタイム)
•20日
•WT(待ち時間)
•28日
•改善ポイント1
•ステージングデプロイ、社内デプロイとも
曜日を固定して実施しているために待ち時
間が発生してしまっている
•必要に応じて随時デプロイすれば、最大
で18日分のLTが短縮できる可能性がある
VSMやってみてわかったこと
•改善ポイント2
•テスト実施者、承認者、デプロイ実施者、それぞれが担当が異なる
ため、ハンドオーバーの無駄が発生している
•AWS Code Pipelineなどを使ってデプロイメントパイプライン
を構築すれば、承認者がAWS マネジメントコンソール上で承認を
クリックするだけで、各環境にデプロイするところまでを自動化す
ることもできそう
• 改善ポイント1 だけではハンドオーバーが発生するため現実的に
は18日分のLT短縮は難しいが、さらにハンドオーバーを止めて、
一連の流れを自動化することでそれに近い短縮が可能になる
VSMやってみてわかったこと
VSMを使った
継続的な
改善フロー
スタート
スタート VSM実施
•現状数値把握
•リードタイム
•プロセスタイム
•待ち時間
•手戻り率
スタート VSM実施
ムダなプロセスと
その改善案洗い出し
•現状数値把握
•リードタイム
•プロセスタイム
•待ち時間
•手戻り率
•ボトルネックの解消に注力
•リードタイムをKPIに設定
•具体的な短縮目標を決め、
部門横断目標にする
スタート VSM実施
ムダなプロセスと
その改善案洗い出し
•現状数値把握
•リードタイム
•プロセスタイム
•待ち時間
•手戻り率
隔週の定例承認会議
手間のかかる手動デプロイ
長期開発とビックバン結合
技術的負債による開発速度低下
思いつき駆動の長い企画会議
開発から運用への引き継ぎ
•ボトルネックの解消に注力
•リードタイムをKPIに設定
•具体的な短縮目標を決め、
部門横断目標にする
スタート VSM実施
ムダなプロセスと
その改善案洗い出し
•現状数値把握
•リードタイム
•プロセスタイム
•待ち時間
•手戻り率
長期開発とビックバン結合
技術的負債による開発速度低下
思いつき駆動の長い企画会議 リーン・スタートアップ
継続的インテグレーション
アジャイル開発
組織変更
•ボトルネックの解消に注力
•リードタイムをKPIに設定
•具体的な短縮目標を決め、
部門横断目標にする
手間のかかる手動デプロイ CI/CDパイプライン
形骸化したルール変更
隔週の定例承認会議
開発から運用への引き継ぎ
スタート VSM実施
ムダなプロセスと
その改善案洗い出し
•現状数値把握
•リードタイム
•プロセスタイム
•待ち時間
•手戻り率
長期開発とビックバン結合
技術的負債による開発速度低下
思いつき駆動の長い企画会議 リーン・スタートアップ
継続的インテグレーション
アジャイル開発
•ボトルネックの解消に注力
•リードタイムをKPIに設定
•具体的な短縮目標を決め、
部門横断目標にする
CI/CDパイプライン
手間のかかる手動デプロイ
組織変更
形骸化したルール変更
隔週の定例承認会議
開発から運用への引き継ぎ
DevOps支援のスコープ
スタート VSM実施
ムダなプロセスと
その改善案洗い出し
•現状数値把握
•リードタイム
•プロセスタイム
•待ち時間
•手戻り率
長期開発とビックバン結合
技術的負債による開発速度低下
思いつき駆動の長い企画会議 リーン・スタートアップ
継続的インテグレーション
アジャイル開発
•ボトルネックの解消に注力
•リードタイムをKPIに設定
•具体的な短縮目標を決め、
部門横断目標にする
CI/CDパイプライン
手間のかかる手動デプロイ
組織変更
形骸化したルール変更
隔週の定例承認会議
開発から運用への引き継ぎ
実際のボトルネックはここだった!
‒ 『The DevOps 逆転だ!』
「制約条件理論を生み出したエリヤ
フ・ゴールドラットは、ボトルネック
以外のところでいかに改良を加えても
無駄だということを教えてくれた。衝
撃だったけど、真実なんだよ。」
スタート VSM実施
ムダなプロセスと
その改善案洗い出し
•現状数値把握
•リードタイム
•プロセスタイム
•待ち時間
•手戻り率
長期開発とビックバン結合
技術的負債による開発速度低下
思いつき駆動の長い企画会議 リーン・スタートアップ
継続的インテグレーション
アジャイル開発
•ボトルネックの解消に注力
•リードタイムをKPIに設定
•具体的な短縮目標を決め、
部門横断目標にする
ボトルネックが移動
手間のかかる手動デプロイ CI/CDパイプライン
組織変更
開発から運用への引き継ぎ
スタート VSM実施
ムダなプロセスと
その改善案洗い出し
•現状数値把握
•リードタイム
•プロセスタイム
•待ち時間
•手戻り率
長期開発とビックバン結合
技術的負債による開発速度低下
思いつき駆動の長い企画会議 リーン・スタートアップ
継続的インテグレーション
アジャイル開発
•ボトルネックの解消に注力
•リードタイムをKPIに設定
•具体的な短縮目標を決め、
部門横断目標にする
ボトルネックが移動
手間のかかる手動デプロイ CI/CDパイプライン
組織変更
開発から運用への引き継ぎ
•第1の道: フローの原則
•開発→運用→顧客の左から右へのワークフローを高速にする
ここまでが第1の道
!"#
「やってる感」に注意!
注意1
アジャイル
スクラム
クラウド
DX
リーン開発
カンバン
XP
DevOps
継続的インテグレーション
継続的デリバリー
デプロイパイプライン
IaC
LeSS
SAFe
DAD
Scrum@Scale ペアプロ
モブプロ
リーンスタートアップ
ドメイン駆動設計
テスト駆動開発
ユーザーストーリーマッピング
インセプションデッキ
カスタマージャーニーマップ
リーンキャンバス
パターン・ランゲージ
デザイン思考
システム思考
Spotifyモデル
IaaS
PaaS
SaaS
ブルーグリーンデプロイメント
カナリアリリース
ダークカナリア
カオスモンキー
マイクロサービス
Git
GitHub
Nexus
Management 3.0
モダンアジャイル
プランニングポーカー
デザインスプリント
ティール組織
サーバレス
コンテナ
Docker
Kubernetes
自動テスト
リファクタリング
AI
チャットボット
ボトルネック
以外の改良は
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無
駄
無駄!
VSMを厳密な定量評価
には使わない
注意2
https://speakerdeck.com/moriyuya/bullshit-product-rsgt2022?slide=261
https://speakerdeck.com/moriyuya/bullshit-product-rsgt2022?slide=269
VSMは
ボトルネックを探す
参考にする程度
まとめ
•DevOpsを実践するためのステップは3つの道!
•第1の道の最初の一歩は可視化!
•可視化をプロセスに組み込むならカンバン
•まず現在の流れを可視化するならVSM
•VSMはボトルネックを探す参考にする程度
•可視化したらメトリクスの収集
•代表的なメトリクスはリードタイム
•ボトルネックを見つけ、その解消に注力しよう
•その結果、ワークフローは高速になる
•ボトルネック以外の改良は無駄!
以上

DevOpsを支える原則、3つの道