DevOpsを支える原則、3つの道
10.5K Views
February 16, 22
スライド概要
日本TOC推進協議会の第3回実践分科会で発表したスライドです。
Agile Practitioner / CSP-SM, CSP-PO(Certified Scrum Professional) / Modern Offshore Development / Vietnam / Paris Hilton / RareJob / BOOKOFF / Classmethod, Inc.
関連スライド
各ページのテキスト
〜第3回 TOC実践分科会〜 DevOpsを支える原則、 3つの道 2022/2/16 藤村 新
自己紹介 • 藤村 新(ふじむら あらた) • @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
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関連でも少しだけ… 主な登壇歴 •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 (と私)の歴史
Agile 2008 Agile Infrastructure and Operations: How Infra-gile are You? パトリック・デボア (The DevOps Handbook共著[2016/10]) 7月 2008年 9月 11月 8月 結婚♥ 3年働いたエキサイト退職 同僚が立ち上げたスタートアップ へ転職🔥 エキサイト アヴリル・ラヴィーン来日ツアー 3キャリア公式＆PCサイトを 1人Devで構築 スタートアップ
Continuous Deployment ティモシー・フィッツ http://timothy tz.com/2009/02/08/ continuous-deployment/ (DevOpsの文脈ではない) 2009年 2月 3月 Velocity 2009 10+ Deploys per Day: Dev and Ops Cooperation at Flickr ジョン・アレスポウ ＆ ポール・ハーモンド 6月 DevOpsDays Ghent 2009 パトリック・デボア 9月 10月 スタートアップ退職 フリーランスエンジニアになる🔥 自社サービスを模索しながらも受託開発メイン fi スタートアップ フリーランス
Continuous Delivery ジェズ・ハンブル他 DevOpsDays Sydney DevOpsDays Mountain View 2010年 DevOpsDays Hamburg (The DevOps Handbook共著) (DevOpsにも結構言及してる) DevOpsDays Brazil 11月 9月 2月 6月 7月 フリーランスエンジニア挫折 スタートアップに出戻り orz 自社サービスを模索しながらも受託開発メイン フリーランス 10月 12月 長男誕生♥ 西海岸ノリの スタートアップに常駐 スタートアップ(出戻り)
DevOpsDays Manila DevOpsDays Mountain View DevOpsDays Boston 2011年 DevOpsDays Melbourne 2月 DevOpsDays Goteborg DevOpsDays Bangalore 4月 7月 6月 3月 10月 8月 12月 9月 西海岸ノリで解雇🔥 GMOインターネットに出戻り 常駐先へ転職 西海岸ノリの スタートアップに常駐 事業をピボットしたタイミングでジョイン アジャイル開発、リーン・スタートアップ初体験 ソシャゲで アジャイル開発 スタートアップ(出戻り) 西海岸ノリのスタートアップ GMOインターネット
DevOpsDays Austin Texas DevOpsDays Mountain View DevOpsDays Tokyo@GMO インターネット 2012年 DevOpsDays Rome DevOpsDays Delhi 3月 7月 4月 5月 6月 ニアミス！ しかし不参加 12月 9月 リリース ソシャゲでアジャイル開発 GMOインターネット 10月 PMIアジャイルPM研究会 立ち上げプロジェクトに参画 グループ会社の新規プロジェクトで スクラム初実践
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 qpstudy 2013.01 「DevOpsをぶち壊せ 〜DevOps言うな〜」 The Phoenix Project ジーン・キム他 (The DevOps Handbook共著) ＠ヤフー 2013年 3月 1月 6月 8月 9月 “「状況によって手作業で環境構築することを認めると、 Chefの利用が浸透しない」。 GMOインターネットの藤村 新氏（次世代システム 研究室 シニアアーキテクト）は、自身のチームでの 経験から、こう警鐘を鳴らす。” GMOインターネット
初海外登壇！ DevOpsDays 開催数 初登壇！ 80 80 71 初参加！ 60 51 40 42 35 28 20 18 0 1 4 6 19 22 5 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021
DevOps に対する 私のもやもや
DevOpsって、 ズルくない？
fi https://puppet.com/sites/default/ les/inline-images/2016%20State%20of%20DevOps%20infographic.jpg
全部DevOpsの手柄？
“実際、devops運動の背後にあるアイデア の多くは、以前から別の名前で存在していた ものが多い。しかし、devopsの時代精神 は、それらの部品の総和以上のものであり、 今までのものとは異なるものである。” ‒Effective DevOps
これら全部DevOps傘下？
DevOpsって、 名前が悪くない？
当初はDevとOpsの対立構造解消にフォーカス していたけど、その後解釈が拡大中 fl https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at- 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とは、 組織のビジネス競争力を 向上させるために行なう 全ての活動の総称
単なる標語
2013/1 2016/10 2012/8 https://itrevolution.com/the-three-ways-principles-underpinning-devops/
2013/1 2016/10
DevOpsを支える原則 3つの道 2013/1 2016/10 https://itrevolution.com/the-three-ways-principles-underpinning-devops/
3つの道: DevOpsを支える原則 •第1の道: フローの原則 •開発→運用→顧客の左から右へのワークフローを高速にする
3つの道: DevOpsを支える原則 •第1の道: フローの原則 •開発→運用→顧客の左から右へのワークフローを高速にする •第2の道: フィードバックの原則 •右から左へのすばやくて持続的なフィードバックフローを実現する
3つの道: DevOpsを支える原則 •第1の道: フローの原則 •開発→運用→顧客の左から右へのワークフローを高速にする •第2の道: フィードバックの原則 •右から左へのすばやくて持続的なフィードバックフローを実現する •第3の道: 継続的な学習と実験の原則 •フィードバックループの継続的な短縮、強化により、かつてないほど安全 な作業システムを作ると、リスクテイクと実験がしやすくなり、競合他社 よりも早く学んで競争に勝ちやすくなる
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日
VSMやってみてわかったこと •改善ポイント1 •ステージングデプロイ、社内デプロイとも 曜日を固定して実施しているために待ち時 間が発生してしまっている •必要に応じて随時デプロイすれば、最大 で18日分のLTが短縮できる可能性がある
VSMやってみてわかったこと •改善ポイント2 •テスト実施者、承認者、デプロイ実施者、それぞれが担当が異なる ため、ハンドオーバーの無駄が発生している •AWS Code Pipelineなどを使ってデプロイメントパイプライン を構築すれば、承認者がAWS マネジメントコンソール上で承認を クリックするだけで、各環境にデプロイするところまでを自動化す ることもできそう •“改善ポイント1”だけではハンドオーバーが発生するため現実的に は18日分のLT短縮は難しいが、さらにハンドオーバーを止めて、 一連の流れを自動化することでそれに近い短縮が可能になる
VSMを使った 継続的な 改善フロー
スタート
スタート VSM実施 •現状数値把握 •リードタイム •プロセスタイム •待ち時間 •手戻り率
スタート VSM実施 ムダなプロセスと その改善案洗い出し •現状数値把握 •ボトルネックの解消に注力 •リードタイム •リードタイムをKPIに設定 •プロセスタイム •具体的な短縮目標を決め、 部門横断目標にする •待ち時間 •手戻り率
思いつき駆動の長い企画会議 技術的負債による開発速度低下 スタート VSM実施 ムダなプロセスと その改善案洗い出し 長期開発とビックバン結合 手間のかかる手動デプロイ •現状数値把握 •ボトルネックの解消に注力 •リードタイム •リードタイムをKPIに設定 •プロセスタイム •具体的な短縮目標を決め、 部門横断目標にする •待ち時間 •手戻り率 開発から運用への引き継ぎ 隔週の定例承認会議
スタート VSM実施 ムダなプロセスと その改善案洗い出し •現状数値把握 •ボトルネックの解消に注力 •リードタイム •リードタイムをKPIに設定 •プロセスタイム •具体的な短縮目標を決め、 部門横断目標にする •待ち時間 •手戻り率 思いつき駆動の長い企画会議 リーン・スタートアップ 技術的負債による開発速度低下 継続的インテグレーション 長期開発とビックバン結合 アジャイル開発 手間のかかる手動デプロイ CI/CDパイプライン 開発から運用への引き継ぎ 組織変更 隔週の定例承認会議 形骸化したルール変更
DevOps支援のスコープ スタート VSM実施 ムダなプロセスと その改善案洗い出し •現状数値把握 •ボトルネックの解消に注力 •リードタイム •リードタイムをKPIに設定 •プロセスタイム •具体的な短縮目標を決め、 部門横断目標にする •待ち時間 •手戻り率 思いつき駆動の長い企画会議 リーン・スタートアップ 技術的負債による開発速度低下 継続的インテグレーション 長期開発とビックバン結合 アジャイル開発 手間のかかる手動デプロイ CI/CDパイプライン 開発から運用への引き継ぎ 組織変更 隔週の定例承認会議 形骸化したルール変更
スタート VSM実施 ムダなプロセスと その改善案洗い出し •現状数値把握 •ボトルネックの解消に注力 •リードタイム •リードタイムをKPIに設定 •プロセスタイム •具体的な短縮目標を決め、 部門横断目標にする •待ち時間 •手戻り率 思いつき駆動の長い企画会議 リーン・スタートアップ 技術的負債による開発速度低下 継続的インテグレーション 長期開発とビックバン結合 アジャイル開発 手間のかかる手動デプロイ CI/CDパイプライン 実際のボトルネックはここだった！ 開発から運用への引き継ぎ 組織変更 隔週の定例承認会議 形骸化したルール変更
“「制約条件理論を生み出したエリヤ フ・ゴールドラットは、ボトルネック 以外のところでいかに改良を加えても 無駄だということを教えてくれた。衝 撃だったけど、真実なんだよ。」” ‒ 『The DevOps 逆転だ！』
ボトルネックが移動 スタート VSM実施 ムダなプロセスと その改善案洗い出し •現状数値把握 •ボトルネックの解消に注力 •リードタイム •リードタイムをKPIに設定 •プロセスタイム •具体的な短縮目標を決め、 部門横断目標にする •待ち時間 •手戻り率 思いつき駆動の長い企画会議 リーン・スタートアップ 技術的負債による開発速度低下 継続的インテグレーション 長期開発とビックバン結合 アジャイル開発 手間のかかる手動デプロイ CI/CDパイプライン 開発から運用への引き継ぎ 組織変更
ボトルネックが移動 スタート VSM実施 ムダなプロセスと その改善案洗い出し •現状数値把握 •ボトルネックの解消に注力 •リードタイム •リードタイムをKPIに設定 •プロセスタイム •具体的な短縮目標を決め、 部門横断目標にする •待ち時間 •手戻り率 思いつき駆動の長い企画会議 リーン・スタートアップ 技術的負債による開発速度低下 継続的インテグレーション 長期開発とビックバン結合 アジャイル開発 手間のかかる手動デプロイ CI/CDパイプライン 開発から運用への引き継ぎ 組織変更
ここまでが第1の道 •第1の道: フローの原則 •開発→運用→顧客の左から右へのワークフローを高速にする !"#
注意1 「やってる感」に注意！
Scrum＠Scale ペアプロ 自動テスト カナリアリリース カオスモンキー マイクロサービス AI Management 3.0 サーバレス DAD クラウド リーン開発 カンバン Git GitHub DevOps パターン・ランゲージ XP リーンキャンバス ティール組織 デプロイパイプライン スクラム コンテナ デザイン思考 Kubernetes アジャイル DX LeSS SAFe Docker モブプロ Nexus ドメイン駆動設計 継続的デリバリー モダンアジャイル ダークカナリア リーンスタートアップ 継続的インテグレーション ブルーグリーンデプロイメント テスト駆動開発 リファクタリング ユーザーストーリーマッピング プランニングポーカー PaaS インセプションデッキ SaaS カスタマージャーニーマップ Spotifyモデル システム思考 IaC チャットボット デザインスプリント IaaS
ボトルネック 以外の改良は
無無無無無無無無無無無無無無無無無無無無 駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄 無無無無無無無無無無無無無無無無無無無無 駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄 無無無無無無無無無無無無無無無無無無無無 駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄 無無無無無無無無無無無無無無無無無無無無 駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄 無無無無無無無無無無無無無無無無無無無無 駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄駄 無駄！
注意2 VSMを厳密な定量評価 には使わない
https://speakerdeck.com/moriyuya/bullshit-product-rsgt2022?slide=261
https://speakerdeck.com/moriyuya/bullshit-product-rsgt2022?slide=269
VSMは ボトルネックを探す 参考にする程度
まとめ
•DevOpsを実践するためのステップは3つの道！ •第1の道の最初の一歩は可視化！ •可視化をプロセスに組み込むならカンバン •まず現在の流れを可視化するならVSM •VSMはボトルネックを探す参考にする程度 •可視化したらメトリクスの収集 •代表的なメトリクスはリードタイム •ボトルネックを見つけ、その解消に注力しよう •その結果、ワークフローは高速になる •ボトルネック以外の改良は無駄！
以上