DevOpsとSREのために知るべき3つの原則〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜

DevOpsとSREのために知るべき
3つの原則
〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜
08 July 2023
渡辺聖剛＠クラスメソッド株式会社

View Slide

#devio2023
Q : みなさんの職種(ロール)について
1. エンジニア・プログラマー
2. 技術責任者
3. 情報システム部門
2

View Slide

#devio2023
早速ですが、
⽇々の開発業務、
忙しくないですか？

View Slide

#devio2023
開発環境 = Software Development Life Cycle
機能実装
コード記述
（IaC含む）
コミット
・PR
コードのレ
ビュー
テストビル
ド
デプロイ用
ブランチへ
のマージ
本番ビルド
本番ビルド
（アプリケー
ション）に対
するテスト
本番環境へ
のデプロイ
本番環境に
てアプリ
ケーション
が動作して
いる状態
実行状態の
観測・計測
本番環境へ
の操作・運
用
インシデン
ト対応
ポストモー
テム
計測結果や
フィード
バックを受
けての次の
開発計画
Code Review Build Test Deploy Run Measure
Improve
Plan
Repeat
Operate
4

View Slide

#devio2023
開発者は忙しい
● 開発のCI/CDループ。
毎⽇コードは書かれている
● 問題があるコードは、即座に
顧客体験の悪化を引き起こす
● だから、⽇々のコードレビューは
本当に重要
● しかし、組織の事情によっては
そこを⼗分に⼿厚くできない
● 規模に依らずそんな組織が多い
● なぜなら、開発者たちは
やることが多く忙しいからだ
5
https://youtu.be/uC2jIRm0eAM（意訳）

View Slide

#devio2023
でも要求はどんどん増える : 2013 → 2023
https://httparchive.org/reports/state-of-the-web#bytesTotal
デスクトップ
➡ 2.7倍
モバイル
➡ 4.9倍
サーバー側の
処理内容
➡ ????倍
6

View Slide

#devio2023
「速いは正義」という時代 | ⾚の⼥王仮説
● 開発速度
≒ 変化する / 変化に対応する速度
● 処理性能(レスポンスタイム)の速さ
⽇々⾛り続けないと
ついていけない！
7
https://agora-web.jp/archives/516141.html
https://www.genpaku.org/alice02/alice02j.html
“ここではだね、
同じ場所にとどまるだけで、
もう必死で走らなきゃいけないんだよ”
———— ルイス・キャロル「鏡の国のアリス」

View Slide

#devio2023
ここで聞こえてくる
「忙しすぎて、
環境のメンテとかできないよ」
との声

View Slide

#devio2023
RPGにおける武器と狩り場のジレンマ
● はやく経験値や素材を稼ぎたい
● レベルアップなどの理由で、
装備や狩り場が適正では
なくなった
そのまま狩り続けるのか？
それとも、
拠点に戻って装備を整え
適切な狩り場に移動する？
https://commons.wikimedia.org/wiki/File:LARP.jpg
9
※画像はイメージです

View Slide

#devio2023
わかりにくいと⾔われたのでで例えてもらった
4⼈1チーム同⼠での対戦
● 敵を2体倒し、
⾃分ひとりで最前線をキープ
● 敵も同様に⾃拠点に攻め込んでいて、
味⽅ 3 vs 敵 2 で状況が膠着
（通常はこのままでも勝てる）
● ⾃分が戻ることで 4 vs 2、
早期解決を⽬指せるが、
せっかく上げた戦線を下げることになる
⾃分ひとりで前線を維持し続けるか？
拠点に戻り、戦況とチーム体制を整えてから
再び前線を上げるか？
https://commons.wikimedia.org/wiki/Main_Page
10
※画像はイメージです

View Slide

#devio2023
そんな装備で大丈夫か？
短期的には良い判断だが、
その後⽣産性はじわじわ低下
短期的には⽣産性が落ちるが、
中⻑期的には
こちらが上に
いわゆる「⽊こりのジレンマ」
ぼろぼろの斧で
⽊を切り続けるのか？
それとも
まず斧を研いで、
その後の⽊を切るペースを
あげるか？
https://webtan.impress.co.jp/e/2017/06/27/26149
http://elshaddai.jp/elshaddai_crim/freedeta.html
11
➡ 課題を感じているなら
「斧を研ぐ」時間をとる検討を

View Slide

#devio2023
忙しいなかですが
なんとかアップデートしてほしい...
というわけで、
開発環境を
「リファクタリング」しませんか？

View Slide

#devio2023
本⽇お話しすること
https://dev.classmethod.jp/news/devops-webinar/
13

View Slide

#devio2023
今年の 2 ⽉から毎⽉開催
● 2023/02/03
● 2023/03/03
● 2023/04/07
● 2023/05/10
● 2023/06/07
● 2023/07/06
ご参加‧ご協⼒いただいた皆様⽅、
本当にありがとうございました！
14

View Slide

#devio2023
ウェビナーアンケートより 15

View Slide

#devio2023
ウェビナーアンケートより 16

View Slide

#devio2023
今⽇お話しすること
開発環境の「リファクタリング」
どうやって進めましょう？
● どこを
● どのように
● どうやって‧何を使って
17

View Slide

#devio2023
紹介する「 3 つの原則」
Refactoring / SDLC / ⽊こりのジレンマ / ⾚の⼥王仮説
DevOps / SRE / Platform Engineering
CALMS / Culture / Automation / Lean / Measurement / Share
Think big, act small, fail fast, learn rapidly
DORAメトリック / 可観測性(Observability) / 監視(Monitoring)
IaC / SaaS / マネージドサービス / ⼼理的安全性 / Phoenix Project
18

View Slide

#devio2023
本⽇のゴール
⽇々の開発の状況を思い返して
「オレたちみんな、毎⽇たいへんなことやってんな...」
「実はもっと楽に効率あげられるんじゃないかな？」
と、思えるようになること
19

View Slide

#devio2023
今⽇お話ししないこと
● SDLCステップごとの具体的な解決策の提⽰
（語り尽くせません！）
● 具体的なツールの紹介
（銀の弾丸はありません！！）
● 開発環境 ≠ コーディング環境
（好きなIDEを使ってください！）
（でもコーディングを助ける話はします）
20

View Slide

#devio2023
こちらも是⾮視聴を！
AWS事業本部コンサルティング部 mokoさんのセッション
勝⼿に姉妹編的なセッションだと思いました
（ついさっきそう思いました

View Slide

#devio2023
⾃⼰紹介
▸ クラスメソッド株式会社
アライアンス事業部エンジニアG
○ DevOpsソリューション
○ Google Cloud
▸ 指向 :
運⽤‧モニタリング‧SRE
▸ 好きなAWSサービス :
ACM‧Route 53‧
CloudWatch Metric Stream
▸ 好きなGoogle Cloudサービス :
Compute Engine Live Migration
22
渡辺聖剛 (Seigo Watanabe)
https://dev.classmethod.jp/author/watanabe-seigo/
https://www.credly.com/users/seigo-watanabe.29d196c2
https://www.credential.net/profile/seigowatanabe992008/wallet

View Slide

#devio2023
[PR]【7/24（⽉）福岡】DevelopersIO 2023 福岡
https://dev.classmethod.jp/news/devio-2023-fukuoka/
23

View Slide

#devio2023
開発環境の
Refactoring（リファクタリング）
1
1

View Slide

#devio2023
リファクタリング
外部からみた動作を変更せずに
既存のコード本体を再構築し
その内部構造を置き換える
コーディング技術
https://refactoring.com/
“Refactoring is a disciplined
technique for restructuring
an existing body of code,
altering its internal structure
without changing its
external behavior.”
———— refactoring.com
25
この考え方を
開発環境そのものにも適応する

View Slide

#devio2023
「開発環境」を「リファクタリング」する
SDLCの全体の流れを変えずに
パーツ単位で改善していく
● ⼿段を変える
○ ⼿作業 ➡ ⾃動化
● 道具(ツール)を変える
○ 使いにくい道具 ➡ 使いやすい道具
基本原則：影響範囲を「最⼩に」抑える
（ゼロにする、ではない！）
26

View Slide

#devio2023
最⼩単位で⼩さく始める：リーン
Lean “Think big, act small, fail fast;
learn rapidly”
———— Lean Software Development: An Agile Toolkit
27

View Slide

#devio2023
さらに
Automation
⾃動化
Measurement
計測‧測定
● 「機械的に実⾏される所」を
増やす
● 現状把握と効果測定
28

View Slide

#devio2023
ちょっと並べ替えて
❏ Culture （⽂化）
❏ Automation （⾃動化）
❏ Lean （リーン）
❏ Measurement （測定）
❏ Share （共有）
29

View Slide

#devio2023
実は
30

View Slide

#devio2023
実は : CALMSフレームワーク
https://www.atlassian.com/ja/devops/frameworks/calms-framework
DevOpsフレームワークのひとつ
31

View Slide

#devio2023
つまり
DevOpsの原則‧フレームワークにそって
開発環境をリファクタリングしましょう
...という提案です
32

View Slide

#devio2023
CALMSの提唱者 : Jez Humble
著作（共著）➡
https://itrevolution.com/articles/devops-culture-part-1/
https://amzn.asia/d/iGFJIVa
https://www.oreilly.co.jp/books/9784873117744/
https://book.impress.co.jp/books/1118101029
33
“After the first US based Devopsdays
in Mountainview 2010 Damon
Edwards (@damonedwards) and I
coined the acronym CAMS, which
stands for Culture, Automation,
Measurement and Sharing. Jez
Humble (@jezhumble) later added an
L, standing for Lean, to form CALMS.”
———— John Willis “DevOps Culture (Part 1)”

View Slide

#devio2023
Q : DevOpsとは...
1. Dev と Ops
2. Dev も Ops も
3. Dev の Ops
4. Dev が Ops
ある意味
全部
正解
34

View Slide

#devio2023
Automation/Lean/Measurement
2

View Slide

#devio2023
Automation （⼀般的な定義）
“⾼度に⾃動化された⼿段によって、ひとの介⼊を最⼩限に抑えつつ
⼿続き(プロセス)を操作または制御する技術‧⽅法‧システム”
❌ （スクリプトなどで）⾃動化すること
⭕ ⼿動で⾏う作業を最⼩化すること
Automation Deﬁnition & Meaning | Dictionary.com
➢ the technique, method, or system of operating or controlling
a process by highly automatic means, as by electronic devices,
reducing human intervention to a minimum.
———— dictionary.com
37

View Slide

#devio2023
端的に⾔えば
Automation ≠ オートメーション 
とかく「如何にコードで置き換えるか」のような議論になりがちですが...
「その⼿続きは本当に必要なのか？」
「もっと簡素化‧簡略化できるのでは？」
「コードを書かなくても⽅法はあるのでは？」
もっとも効果的な⽅法で「⼿作業を回避」することが重要です
38

View Slide

#devio2023
「⼿動で⾏う作業を最⼩化すること」によって...
● ⼈的要因による事故やミスを抑制 ➡ 正確性‧再現性が向上
● 作業時間‧実⾏時間の短縮
● 作業の持続可能性が向上（属⼈スキルからの脱却）
https://www.atlassian.com/ja/devops/what-is-devops
39
“DevOpsの基本的なプラクティスは、ソフトウェア開発ライフサイクルを
可能な限り自動化することです。これにより、開発者がコードを書いたり、
新しい機能を開発したりする時間が増えます。
自動化は CI/CD パイプラインの重要な要素であり、人的ミスの削減と
チームの生産性向上に役立ちます。”
———— 自動化 - 5 つの重要な DevOps の原則 | Atlassian

View Slide

#devio2023
端的に⾔えば
Automation ≠ 機能実装 
サービスとして提供するためではなく、
そのための⼿段を改善するのが⽬的
➡「⼤きく完全なもの」は
⽬指さない
https://commons.wikimedia.org/wiki/File:160216-N-XT273-025_(25055215346).jpg
40

View Slide

#devio2023
2

View Slide

#devio2023
lean (リーン)
そもそもの⾔葉の意味：
● 贅⾁‧脂肪が少ない、無駄がない
● (含有量が)希薄である
リーンソフトウェア開発：
● 「価値を⽣み出さないもの」を省く
● サイクルタイムの短縮
● 継続的にプロセスを改善
DevOps的⽂脈：
● 継続的な改善に努める
● (その際の)失敗を受け⼊れる ➡ 「不具合の早期発⾒‧早期対処」
https://www.dictionary.com/browse/lean
https://en.wikipedia.org/wiki/Lean_software_development
42
“Think big, act small, fail fast;
learn rapidly”

View Slide

#devio2023
Lean (リーン)
● 継続的な改善の実⾏が前提
● ⼤局的にみて「⽬的地」を設定
● ⼩規模のところから段階的に
○ 対象プロセス‧ステップ
○ 対象システム
○ 関わる組織‧メンバー⼈数
● 効果を⾒極め、「うまく⾏かないところ」は次で修正
https://www.dictionary.com/browse/lean
“Think big, act small, fail fast;
learn rapidly”
43

View Slide

#devio2023
Lean ➡ 「継続的な改善に努める」
「⾃動化して終わり」ではない
(ここも錯覚しやすいポイント)
「やっている時間が無い」
からこそ
持続可能な範囲で
試⾏‧遂⾏することが重要
https://pxhere.com/en/photo/930678
44

View Slide

#devio2023
「作ったものは壊したくない」➡ わかります！
もちろん「全てを作り直せ」と
⾔っているわけではないです
残すべきものは残しましょう
（その判断をしましょう）
最初からライフサイクルを
意識しておくといいですね！
45

View Slide

#devio2023
Think big, act small
● いま⾏っている「マニュアル作業」をそのまま⾃動化すると、
その作業の本質が覆い隠される危険性がある
○ ⾃動化しようとしているその作業、
最初は（本来は）ワークアラウンドのはずではなかったですか？
● 全体(big)をみた上で、
なるべく局所(small)的な変更‧導⼊を⼼がけましょう
“問題の重大性を覆い隠すようなスクリプトを書くことは、
本当の問題を修正しないため中長期的には無駄であり、さらに
潜在的には後にもっと問題を引き起こす要因となりえます。”
————John Looney, 「サイトリライアビリティワークブック」（一部要約）
46

View Slide

#devio2023
2

View Slide

#devio2023
計測(Measure) = 記録(Record)
いま(現状)がどうであるかを
正しく理解‧把握するための⾏動
計測しないと...
● 今がどうなっているのか分からない
● → 過去と差もわからない、将来も予測できない
https://www.linkedin.com/pulse/you-cant-improve-what-measure-raymond-bednar
48
“Measurement is the first step that leads to control
and eventually to improvement.”
———— Dr. H. James Harrington

View Slide

#devio2023
49
古典 : いわゆる「推測するな、計測せよ」
https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6
http://www.lysator.liu.se/c/pikestyle.html
“ルール1: （略）どこがボトルネックな
のかをはっきりさせるまでは、推測を
行ったり、スピードハックをしてはなら
ない”
“ルール2: 計測すべし。計測するまでは
速度のための調整をしてはならない。
（後略）”
————Robert "Rob" C. Pike “Notes on Programming in C” 1989

View Slide

#devio2023
Measurement (計測) 50
アプリケーションの挙動
➡ APM
(Application Performance Management)
インフラ/システムの挙動
➡ システム監視
(CPU/メモリ/システムログ etc...)
実⾏環境の挙動の監視
(異常の発⽣➡即時アラート)
Infrastructure
Application
APM
System
Monitoring
Dashboard

View Slide

#devio2023
Measurement (計測) 51
Code Review Build Test Deploy Run Measure
Improve
Plan
Operate
こちらは
誰が⾒ていますか？
Infrastructure
Application
APM
System
Monitoring
Dashboard
SDLC

View Slide

#devio2023
DORAメトリック
DevOps 組織の有効性を測定する 4 つの指標
(DORA = DevOps Research and Assessment)
速度
1. 変更のリードタイム（commit → deploy）
2. デプロイの頻度
安定性
3. 変更障害率（障害に繋がったデプロイの割合）
4. サービス復元時間（MTTR）
https://cloud.google.com/blog/ja/products/gcp/another-way-to-gauge-your-devops-performance-according-to-dora
52

View Slide

#devio2023
計測(Measure) ≠ 監視(Monitor)
監視 (Monitor) : ⽬的をもって閾値を設定、超過/下回ったら警報
計測 (Measure) : 「いまがどうであるか」の測定
● 現状把握のための計測(Measure)を！
○ 警報ありきの監視(Monitor)ではありません
● 持続性のある計測⽅法の採⽤を！
○ Excelに⼿⼊⼒強制：
労⼒と⽐較して、正確な情報が採れる保証がありません
53

View Slide

#devio2023
可観測性(Observability)
異常検知‧警報のためでなく、
「いまシステムがどうであるか」を把握するための
計測 (Measurement)
Metric / (Event)Log / Trace etc...
➡ そのためのもの！
54
“システムがどのような状態になったとしても、それがどんなに
斬新で奇妙なものであっても、どれだけ理解し説明できるかを
示す尺度です”
————Charity Majors、Liz Fong-Jones、George Miranda「オブザーバビリティ・エンジニアリング」

View Slide

#devio2023
念のため : 監視(Monitoring)は、それはそれで必要 55
https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/
既知の異常については
積極的に監視してアラートを
仕掛けましょう！
“Monitoring means that you already
know what is important.
(何が重要でどうなったら異常なのか、
既に分かっている場合にのみ
監視は有効だ)”
—— Dr. Werner Vogels

View Slide

#devio2023
ここまでのまとめ
Automation‧Lean‧Measurement

View Slide

#devio2023
ここまでのまとめ
反復的な手作業の排除
再現性・正確性の向上
継続的な改善を前提
最小限の範囲から段階的に
現状の状況把握・可視化
(詳細よりも大局を意識)
どのように始めるか・進めるか
何から始めると効果的か・行った効果は
57

View Slide

#devio2023
ちょっと休憩：こちらの解答
1. Dev と Ops
2. Dev も Ops も
3. Dev の Ops
4. Dev が Ops
58

View Slide

#devio2023
1. Dev と Ops ➡ 本来の定義
https://www.techtarget.com/whatis/reference/The-history-of-DevOps-A-visual-timeline
“DevOps is a shared philosophy in
which development and operations
teams work together. The practice
promotes better communication and
collaboration between those two
teams, as well as other teams in an
organization, such as security.”
———— The history of DevOps: A visual timeline
59

View Slide

#devio2023
2. Dev も Ops も ➡ 現在のありがちな状況‧‧？
ひとり（or ⼩数）の担当者が
なんでもやる
● 開発
● 運⽤
● etc
https://en.wikipedia.org/wiki/Tree_swing_cartoon
https://medium.com/@thx2001r/the-project-cartoon-root-cause-5e82e404ec8a
60

View Slide

#devio2023
3. Dev の Ops ➡ 現在の理想像
Operations
for Development Lifecycle
「開発サイクルを
うまく回す(運⽤する)」
MLOpsやDataOpsなど
最近の造語にもニュアンス合致
61

View Slide

#devio2023
では、具体的にはどうすれば？

View Slide

#devio2023
実践のためのヒント
3

View Slide

#devio2023
まず : Measurement
可観測性(Observability)を向上させよう
● システムに対して
● SDLC全体に対して
● 継続的な計測と可視化‧記録
● ⼈の⼿による現状把握も「可観測性の第⼀歩」
どこに対して⾏うべきか / ⾏った結果どうだったか
すべて分かる状態にしてから進めるのが理想です
とはいえ、そこで詰まらないように！
64

View Slide

#devio2023
やり⽅は：Lean
⼤きく変えず、少しずつ変える
変えるべき箇所が⼤きかったら ➡ まずタスクを分解しよう
変更は永続的とはなりえない。
継続的な改善を
65

View Slide

#devio2023
⼿段：Automation
Adobe Fireﬂyによる⽣成 - “Illustration of a car driven by a humanoid robot”
66
なるべく⼈の⼿を介さないような⽅向性
まず⼿順を整理してから⾏おう（テスト駆動）
⾃動化そのものが⽬的にならないように！
問 : ⾃動運転⾞両にほんとうに必要なものはなんでしたか？

View Slide

#devio2023
これもAutomation
⼿作業
(⾮コード化処理 / ⼿動実⾏)
コード
(スクリプト / IaC / ⾃動実⾏)
⼿製ツール
スクリプト
既製品
(OSS / SaaS / マネージドサービス )
67

View Slide

#devio2023
SaaS‧マネージドサービス推奨
● OOTB (Out-of-the-box) で
すぐ使える
○ ドキュメントも揃っている
● インフラも運⽤も込み
○ メンテナンスや障害対応に
⼯数を割かなくて良い
● ツール側で勝⼿に進化
○ 意図しない進化のリスクも
● 「継続的な⾒直し」がしやすい
○ 利⽤契約 (OpEx) がほとんど
買い切り (CapEx) ではない
68

View Slide

#devio2023
SaaS‧マネージドサービスの強み
https://forge-vtt.com/features
“SaaS を使えば数分で動く仕組みが
手に入り、しかも始めたタイミングから
ドキュメントなども手に入ります。”
—— Mike Julian 「入門　監視」
69

View Slide

#devio2023
こんなことをやってくれるSaaSがあります
● アプリケーションのエラー発⽣ → トレースログの可視化
● IaCコードのセキュリティスキャン、評価
● フロントエンドテストの定期実⾏
● システムやアプリケーションメトリックの異常なふるまいの検知
● 様々な出⼒‧計測結果を⼀元で可視化
● IaCステータス管理
● Git commitから⾃動でbuild → test → deploy実⾏
● フィーチャーフラグの管理
● 認証認可基盤
70

View Slide

#devio2023
誰がやる？
4

View Slide

#devio2023
だから「開発者は忙しい」って⾔ってるだろ！ 72
https://youtu.be/uC2jIRm0eAM

View Slide

#devio2023
とはいえ
現場の状況や問題について、
⼀番詳しいのは現場の開発者
➡ 最適解の⼀番近くに
「机上の空論の押しつけ」は
回避したい
なんとかならないものか...
73

View Slide

#devio2023
案 1 : Platform Engineering
乱暴にまとめれば、
SDLCで利⽤するツール群を
管理運⽤する
...という概念に
名前をつけたもの
https://platformengineering.connpass.com/event/275718/
https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai?slide=8
“（さまざまな意見のまとめとして）
開発者体験と生産性を向上させるために
セルフサービスで利用できるツール
チェーンとワークフローを設計構築する
分野”
———— Platform Engineeringとは - Platform Engineering Meetup #1
74

View Slide

#devio2023
というか、
開発環境‧開発⼯程も
「サービスの⼀部である」
と位置づけるのであれば、
その品質や「信頼性」を
担保するための役割が
既にあったりしませんか...？
75

View Slide

#devio2023
案 2 : Site Reliabilit Engineering
S R E
Site
サイト
Reliability
信頼性
Engineering
技術
(or Engineer)
76

View Slide

#devio2023
(唐突ですが) 4. Dev が Ops ➡ SRE！
SREの出発点は
ソフトウェアエンジニア(開発者)
開発者が、⾃⾝のサービス
(サイト)の信頼性を
向上させるためのもの
Operations
by Software Developer
“SREとは、ソフトウェアエンジニアに
運用チームの設計を依頼したときに
できあがるものです”
———— Benjamin Treynor Sloss, VP, Google
/ 「SREサイトリライアビリティエンジニアリング」
77

View Slide

#devio2023
class SRE implements interface DevOps
SDLCに「信頼性」のボトルネックがあるのなら
その解決はSREの守備範囲
“SREがパイプラインの後半部分に
集中できるのは、Google社内では
前半のフェーズで問題が解決されて
いるか、それらのフェーズは
他のチームに委任されるからです。
（略）SREは、目的を達成するための
手段となるのであれば、
パイプラインの前半部分にも
首を突っ込みます。”
———— Thomas A. Limoncelli / 「SREの探求」
78

View Slide

#devio2023
というか
結局のところ (残念ながら)
「現状打開しないと」
という意識の元で
「誰かが」やるしかないです
『Lean』の考え⽅のもと
ちょっとずつ、無理なく、
少しずつ『Automation』を
導⼊していってみませんか？
斧とぎ専任チームも選択肢に！
➡ その結果が『Refactoring』に繋がっていきます！

View Slide

#devio2023
[PR] クラスメソッドの⽀援サービス（例）
https://classmethod.jp/aws/services/iac/
https://classmethod.jp/aws/services/cloud-assessment/
80

View Slide

#devio2023
まとめ...の前に
5

View Slide

#devio2023
CALMSの残りのふたつ
82

View Slide

#devio2023
Share（共有） = サイロの撤廃
● チーム内で情報を共有する
○ 開発〜運⽤〜ビジネス
● 共有のための時間も改善の対象
○ 「その準備は必要ですか？」
○ 「どんな価値を⽣みますか？」
➡ 全員が同じツールを使い、
専⽤のダッシュボードで現状把握
➡ 忌憚のないディスカッション → ⼼理的安全性
➡ チーム全員でDevOps⽂化を共有
https://www.pexels.com/photo/people-taking-slices-of-pizza-from-plate-5907904/
83

View Slide

#devio2023
＿⼈⼈⼈⼈⼈⼈⼈⼈⼈⼈＿
＞ DevOps⽂化を共有＜
￣Y^Y^Y^Y^Y^Y^Y^Y^Y^Y￣

View Slide

#devio2023
Culture（⽂化）
『DevOps』が効果を発揮するためには、
組織の⽂化的⼟壌、
特に『⼼理的安全性』が不可⽋です
※ 正直なところ、導⼊難易度はかなり⾼い
https://www.atlassian.com/ja/devops/what-is-devops/devops-culture
85
“組織が DevOps アプローチに移行するのに役立つ
ツールやテクノロジーは用意されています。
しかし、文化を変えないままツールやテクノロジーを
変えることは、基盤にある弱点に対処せずにうわべだ
けを変えることになります”

View Slide

#devio2023
[PR] クラスメソッド内製化⽀援サービス
● 体制づくり
● スキル開発‧定着
● ビジネス開発
3つの領域から
内製化を実現するための
⾃⾛に向けた⽀援
https://classmethod.jp/services/insource/
https://classmethod.jp/services/insource/step0/
86

View Slide

#devio2023
今度こそ
まとめ
6
Banksy, 2022

View Slide

#devio2023
このセッションで紹介したキーワード
88

View Slide

#devio2023
このセッションで紹介したキーワード
89

View Slide

#devio2023
TL;DR
● ⽇々の開発をRefactoringしよう
○ 進め⽅、⼿段
○ DevOpsの原則‧CALMSフレームワーク
○ 「⽊こりのジレンマ」を回避しよう
● 特に重要 ➡ リーン(Lean)の考え⽅
○ 技術的にも⽅法的にも
○ Automationを念頭にMeasurementしながら
○ SaaS‧マネージドサービスも積極的に検討を
● 根幹には⽂化(Culture)がある
○ ⽂化のためにはShareが必要
○ みなが同じ画⾯を⾒て同じ⾔葉を話そう
○ そのためのツール(⼿段)選定を
90

View Slide

#devio2023
成功させるには
“短距離⾛ではなく、マラソンである”
“Remember: it's a marathon, not a sprint”
91
https://cloud.google.com/blog/ja/products/gcp/sre-success-starts-with-getting-leadership-on-board

View Slide

#devio2023
参考 (1)
❏ HTTP Archive: State of the Web
https://httparchive.org/reports/state-of-the-web#bytesTotal
❏ 資本主義は「⾚の⼥王」である | アゴラ⾔論プラットフォーム
https://agora-web.jp/archives/516141.html
❏ 「⽊こりのジレンマ」という寓話｜斧を研ぐ時間がなぜ重要なのか？
https://webtan.impress.co.jp/e/2017/06/27/26149
❏ Refactoring
https://refactoring.com/
❏ CALMS フレームワーク | Atlassian
❏ DevOps Culture (Part 1) - IT Revolution
https://itrevolution.com/articles/devops-culture-part-1/
❏ DevOps の原則 | Atlassian
https://www.atlassian.com/ja/devops/what-is-devops
❏ Lean software development - Wikipedia

View Slide

#devio2023
参考 (2)
❏ You can’t improve what you can’t measure
https://www.linkedin.com/pulse/you-cant-improve-what-measure-raymond-bednar
❏ UNIX哲学 - Wikipedia
https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6
❏ Notes on Programming in C
http://www.lysator.liu.se/c/pikestyle.html
❏ Google Cloud で実⾏されている DevOps 組織の有効性を評価する | Google Cloud 公式ブログ
https://cloud.google.com/blog/ja/products/gcp/another-way-to-gauge-your-devops-performance-accordin
g-to-dora
❏ The history of DevOps: A visual timeline
https://www.techtarget.com/whatis/reference/The-history-of-DevOps-A-visual-timeline
❏ OPEX(オペックス)とは? 意味やCAPEX(キャペックス)との違いを解説 | クラウドERP実践ポータル
https://www.clouderp.jp/blog/what-is-capex-opex
❏ Platform Engineeringへの招待 - Speaker Deck
https://speakerdeck.com/jacopen/platform-engineeringhenozhao-dai?slide=8
❏ DevOps ⽂化 | Atlassian
https://www.atlassian.com/ja/devops/what-is-devops/devops-culture

View Slide

#devio2023
参考 (3)
❏ AWS re:Invent 2019 - Andy Jassy による基調講演 | AWS (⽇本語字幕) - YouTube
https://www.youtube.com/watch?v=uC2jIRm0eAM
❏ オペレーション、監視(Monitoring)、可観測性(Observability)… AmazonのCTOはAWS re:Invent 2020のキーノー
トでどう語ったか？キーワードを拾ってみた #reinvent | DevelopersIO
https://dev.classmethod.jp/articles/202012-report-reinvent-keynote-observability/
❏ なぜそれをやってるの？「太陽と祈祷師」の寓話にみる因果関係の話 | DevelopersIO
https://dev.classmethod.jp/articles/202004-dilemma-of-the-sun-and-the-shaman/
❏ SRE を成功させるには、まず計画を⽴てることが⼤事 | Google Cloud 公式ブログ
https://cloud.google.com/blog/ja/products/gcp/sre-success-starts-with-getting-leadership-on-board

View Slide

#devio2023
参考 (書籍)
❏ Amazon | The Devops Handbook
https://www.amazon.co.jp/dp/1942788002
❏ O'Reilly Japan - リーンエンタープライズ
❏ LeanとDevOpsの科学［Accelerate］テクノロジーの戦略的活⽤が組織変⾰を加速する - インプレスブックス
https://book.impress.co.jp/books/1118101029
❏ O'Reilly Japan - オブザーバビリティ‧エンジニアリング
❏ O'Reilly Japan - SRE サイトリライアビリティエンジニアリング
❏ O'Reilly Japan - サイトリライアビリティワークブック
❏ O'Reilly Japan - SREの探求

View Slide

る全て独自の考察である全
る　　　　　　　　　　全
全て独自の考察である
Special Thanks
私のバカせまい史 - フジテレビ
https://www.fujitv.co.jp/bakasemaishi/

View Slide

#devio2023
セッションアンケート DAY2
満⾜度上位のセッションを後⽇ブログで公開予定！
回答へのご協⼒をよろしくお願いします。
https://forms.gle/Upi2i5PsMTEUyJ6F8

View Slide

#devio2023
スタンプラリーに挑戦しよう！
イベント会場（11階、26階）にはQRコー
ドが設置されており、QRコードごとにクイ
ズのヒントがもらえます。
クイズに答えて豪華景品をGETしよう！
● AWSトレーニング1⽇コース受講チケット
● クラスメソッドオリジナルグッズ

View Slide

View Slide

DevOpsとSREのために知るべき3つの原則〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜

DevOpsとSREのために知るべき3つの原則〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜

Seigo Watanabe

More Decks by Seigo Watanabe

Featured

Transcript

DevOpsとSREのために知るべき3つの原則 〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜

DevOpsとSREのために知るべき3つの原則 〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜

Seigo Watanabe

More Decks by Seigo Watanabe

Featured

Transcript

DevOpsとSREのために知るべき3つの原則〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜

DevOpsとSREのために知るべき3つの原則〜忙しすぎるエンジニアのための開発環境リファクタリングガイド〜