4keys導入におけるリアル～DevOpsDaysTokyo2023

@ 2023 Novasell, Inc. All Rights Reserved.
4keys 導⼊におけるリアル
2023/04/18 @ DevOpsDay Tokyo
1

View Slide

@ 2023 Novasell, Inc. All Rights Reserved. 2
Yuki Yamanaka
ノバセル株式会社
データプロフェッショナルG
データエンジニア
本⽇のスピーカー
Yusuke Tamura
ノバセルアナリティクスG
サーバサイドエンジニア
Yuya Murata
ノバセルトレンドG
サーバサイドエンジニア

View Slide

ノバセルの事業内容
3
「TVCMを、Web広告のように分析し運⽤する」
運⽤型TVCM市場を開拓

View Slide

ノバセルの事業内容
4
⾃社のTVCMの効果分析ツール
ノバセルアナリティクス
競合他社TVCMの効果分析ツール
ノバセルトレンド
超⾼速アンケートツール
ノビシロ

View Slide

本⽇のアジェンダ
5
4keys を⽤いて⽣産性改善していくのは
実はそこまで難しいことではない
だが、各ステップを丁寧に進めていく必要がある
導⼊構築運⽤拡張

View Slide

4keys とは？
6
Google DevOps Research and Assessment（DORA）チームによって提唱された
開発チームのパフォーマンスを⽰す4つの指標
デプロイの頻度
変更のリードタイム
変更障害率
サービス復元時間
参考
：https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance

View Slide

1. 4keys 導⼊フェーズにおける課題と取り組み（⼭中）
2. 4keys 構築フェーズにおける課題と取り組み（村⽥）
3. 4keys 運⽤フェーズにおける課題と取り組み（⽥村）
4. さらなる前進に向けて（⼭中）
7
Index -⽬次-

View Slide

Section 1
4keys 導⼊フェーズにおける課題

View Slide

ノバセルにおけるエンジニア開発組織の課題
9
技術的負債⼿動テスト‧デプロイ
運⽤負荷属⼈的なシステム開発
改善施策を実施するが継続的に続かない
機能開発を優先し中⻑期での最適化が難しい

View Slide

ノバセルにおけるエンジニア開発組織の課題
10
サービス横断の
基盤開発チームの⽴ち上げ
4keys による可視化
● 全体最適‧中⻑期での費⽤対効果
最⼤化
● DevOps のベストプラクティスの
実践
● 可視化による改善の実感
● 改善の継続意欲向上
● 改善施策の意思決定
改善の継続中⻑期での最適化
→ 我々はこのチームに所属

View Slide

4keys の効果とは？
11
4keys が計測できるようになり
DevOps の改善が進められた場合に、
どれくらいの効果を⽣み出すのか？
Google Cloud 「変⾰の成果を数値化: DevOps 変⾰で収益を獲得する⽅法」
に則って試算
（弊社の場合）だいたい半年くらいで元が取れる計算に

View Slide

効果の計算⽅法についての詳しい⽅法は
弊社テックブログにて公開しています
RAKSUL TechBlog
「エンジニアがROIに向き合ってみたら起こったこと」
https://techblog.raksul.com/entry/2022/12/08/100000

View Slide

Section 2
4keys 構築フェーズにおける課題

View Slide

DORA 4keys は⼈が回答するアンケート調査の設問
として作られている
システムの状態をもとにその指標を算出するには指
標の定義を具体化しなければならない
エンジニア組織の開発プロセスやカルチャーに合わ
せて定義を明確にする必要がある
4keys の定義の難しさ
14
どのように DORA 4keys を
既存社内システムから計測するか？

View Slide

①デプロイ頻度の定義
15
DORA の定義ノバセルの定義
組織による
正常な本番環境へのリリースの頻度
チームのスプリント内で
PR が main ブランチに
マージされた⽇数
「正常な本番環境へのリリース」とは何か？
● リリースの定義は何か？
● バグが起こったときのリバートのリリースを
含むか？
● 社内使⽤の Redash クエリ作成なども含む
か？
頻度の集計粒度をどうするか
● 間隔は？（⽇、週、⽉ etc）
● ⼀⼈当たりの頻度か、組織やチームとしての
頻度か
リリースの定義：
● プロダクトによって利⽤するデプロイシステムが異な
り開発⼯数が増える、マージからデプロイ完了までの
時間が短く改善幅が少ない、という理由から PR マー
ジを採⽤
● ビッグバンリリースを改善するためにリリースブラン
チへのマージは含めず、main のみ対象とする
● Redash などでもデプロイとして捉える。GitHubリポ
ジトリで管理され PR マージが発⽣すればデプロイと
みなすことでコードとしての管理を促進
集計粒度の定義：
● ビッグバンリリースを改善するためにスプリント内で
リリースが発⽣した⽇数を頻度として測定

View Slide

②変更のリードタイム
16
コミットから
本番環境稼働までの所要時間
チームのスプリント内に
完了した開発チケットの
着⼿から完了までの所要時間の平均
「コミット」とは何か？
● 開発の着⼿時？
● Git の作業ブランチの初回コミットからデプ
ロイ完了までの時間？
● リリース準備の完了時？
● デプロイ開始時？
● サイクルタイムを採⽤
● 開発チケット以外（PRが紐づかないチケッ
ト。設計など）は除外
● 改善可能な部分を多くするために測定幅が広
い定義を採⽤
● 開発チケットの粒度を⼩さくする圧⼒が働く
ことで、⼩さく開発をしてフィードバックサ
イクルを早く回していくリーン開発を促進

View Slide

③変更障害率
17
デプロイが原因で
本番環境で障害が発⽣する割合
直近 3 ヶ⽉の間に
main にマージされた PR のうち、
障害を直接引き起こした PR の割合
何をもってデプロイが原因とするか
● UXを悪く作ってしまった社内システムの操作
ミスによる障害などを含むか？
● マージされた PR のうち、障害を引き起こし
たPRの割合を算出
● 障害の振り返りをチームごとに⾏っているた
めチームごとの集計
● 現状の障害発⽣率が低くスプリントごとの計
測では0%が続くため、直近 3 ヶ⽉で発⽣率
を計測
● 機能の使い勝⼿が引き起こした運⽤ミスなど
は機能の使い勝⼿が原因だと正確に⽴証しに
くいため、バグの直接原因となったデプロイ
を計測の対象とした

View Slide

④サービス復元時間
18
組織が本番環境での
障害から回復するのにかかる時間
直近 3 ヶ⽉の間に発⽣した障害の
「障害発⽣⽇時」から
「障害復旧⽇時」までの平均時間
所要時間の開始を何にするか
● 障害発⽣⽇時
● 障害検知⽇時
回復の定義
● リバートや応急処置などの暫定対応でよいか
● 根本対応完了までの時間か
● 障害検知までの時間も改善したいため、発⽣
⽇時を起点にした
● 計測終了の時点は暫定対応完了までとした
○ 4keys のアンケートの設問内容が根本
か暫定かに関わらず復旧した⽇時であ
ると読み取れるため
○ 根本対応完了までにした場合、計測完
了まで⻑期化し、計測完了したサービ
ス復元時間の数が少なくなり、数値が
出しにくくなるため

View Slide

リファレンスアーキテクチャ
19
チケット情報
デプロイ情報
障害情報
Notion
GitHub
Snowﬂake
AWS Athena
AWS S3
Google
Sheet
BIと連携し
可視化

View Slide

Section 3
4keys 運⽤フェーズにおける課題

View Slide

4keys を使いこなすには
21
4key 数値から改善ポイントを模索することが⽬的ではなく、
組織に DevOps を取り⼊れ⽣産性の継続的改善を⾏うことが⽬的
4keys は⾒えるようになったが
改善⾏動にどう活⽤すれば良いのか？

View Slide

4keys をどのように捉えるべきか
22
プロセス
改善施策を実⾏した結果が4keysである
改善施策を考える上でDevOpsの推進についての理解が重要
技術⽂化
組織の⽣産性に関わる主な要素
単に4keysの数値を
⾒るだけでは、⽣産
性改善に向けた施策
が出しにくい。

View Slide

ケイパビリティにフォーカスする
23
DevOpsの推進によって4keysが改善＝ケイパビリティの獲得
ケイパビリティ＝ DevOpsのベストプラクティスを実⾏する能⼒
クラウド
インフラストラクチャ
コードの保守性
継続的
インテグレーション
デプロイの⾃動化
継続的なテスト
継続的デリバリー
疎結合
アーキテクチャ
バージョン管理
データベースの
チェンジマネジメント
トランクベース開発
テストデータ管理
チームのツール選択
のサポート
モニタリングと
オブザービリティ
お客様の
フィードバック
バリューストリーム
での作業の可能性
⼩さいバッチ
単位の作業
変更承認の効率化
チームのテスト
仕掛り制限
ビジュアル
管理機能
障害の予兆通知
仕事の満⾜度
創造的な組織⽂化
変⾰型リーダーシップ
学習⽂化
技術プロセス⽂化
セキュリティの
シフトレフト
システムをモニタリ
ングして的確な判断
引⽤: Google Cloud 「DevOps の能⼒」

View Slide

4keys の振り返り
24
ケイパビリティと4keysを振り返る仕組みの作成
ドキュメントの作成レトロスペクティブへの導⼊

View Slide

基盤開発チームでは Auth0 や Snowﬂake などを Terraform でコード管理
実際の改善成果例 ①
25
コード管理化を推し進めデプロイ頻度が向上
コードの保守性、バージョン管理、継続的なデリバリー
といったケイパビリティが強化
デプロイ頻度が増加傾向デプロイ数は増加

View Slide

実際の改善成果例 ②
26
ペアプロやWIP制限の導⼊でサイクルタイムが改善
ノバセルアナリティクスチームでは
属⼈化による
⻑期的な価値提供のスピード感が課題に
コードの保守性や、レビュースピードが改善
サイクルタイムが改善＋デプロイ頻度は維持
ペアプログラミングの導⼊
チーム内で同時に作業可能なタスク数の制限
（WIP制限）
デプロイ頻度は維持
サイクルタイムが向上

View Slide

Section 4
さらなる前進に向けて

View Slide

4keys のさらなる運⽤改善
28
① 指標の改善
チームメンバー数に依存しないようにする
休⽇の影響を除外する
正確に計測するための運⽤徹底
③ 指標の良し悪しの基準作り
ノバセルにおけるパフォーマンスレベル
の定義が作れていない
※ DORA定義のパフォーマンスレベルをその
まま流⽤できない
② チーム変更の影響に強くする
チームの統廃合が起こっても、過去の数値
を参考に新チームの改善をしていきたい
④ 指標のより詳細な分析を出来るように
変更のリードタイム（開発着⼿〜完了）
までのどこにより時間が掛かっているか等
の分析

View Slide

バリューストリームのデリバリのパフォーマンスが⾼い組織は、
組織パフォーマンス（収益性）も同様に⾼い。
（『LeanとDevOpsの科学』）
DevOps の⽬的
29
Plan＆Design Code Review Merge Release
Development Value Stream Operational Value Stream
バリューストリームとはサービスが顧客の⼿の届くまでの全体的な活動のこと

View Slide

DevOps の⽬的
30
DevOps のビジネス価値は以下のように説明
4keys
開発⽣産性が改善する
施策の試⾏回数が増加する
成功する施策の数が増える
プロダクト価値の向上
？
この領域の
可視化‧改善をしたい

View Slide

ご静聴ありがとうございました！
ラクスル‧ノバセルでは
エンジニア‧PdM‧データサイエンティスト
募集中です！

View Slide

4keys導入におけるリアル～DevOpsDaysTokyo2023

4keys導入におけるリアル～DevOpsDaysTokyo2023

RAKSUL

More Decks by RAKSUL

Other Decks in Technology

Featured

Transcript