※この記事は 開発生産性 Advent Calendar 2022 のカレンダー2の13日目の記事になります。
前回は1日目は hiroshinishio さんの 『より筋肉質なチームにするために、開発者が見るべき21のDevOpsアウトプット指標』 で、個人的には指標それぞれの分析や改善の方法が書かれていて勉強になりました。
こんにちは。
モノタロウで主に DevOps エンジニアとして活動している伊藤です。
休日はジムに節制した食事、サウナと健康を意識するおじさんとしても活動しています。
（最近だと渋谷の改良湯さんのサウナと外気浴スペースの具合が最高でととのいました）
今回は DevOps Four Keys*1 （以降 4keys と呼称） というソフトウェア開発チームのパフォーマンスを示す4つの指標を導入し、部門の目標として掲げたここ1年の取り組みを紹介できればと思います。
背景 （なぜ 4keys なのか）
モノタロウのビジネスやエンジニアを取り巻く環境として下記があります。
- 売上が毎年20%のペースで増加しており、2021年には約1,900億円に達成した。
- 複数の事業ではなく、一つの事業（間接資材の調達・購買ソリューションの提供）で上記を達成している。
- エンジニアは5年前は数十人だったものの、現在は正社員で150人を超え、さらに増えていくことが見込まれている。
参考: ５分でわかる！モノタロウ ～採用ピッチ公開のお知らせ～
上記の通り成長真っ只中のモノタロウですが、その中であっても「アジリティー（俊敏性）をもってビジネスの成長に貢献し続けるエンジニア組織でありたい」と最近策定された Tech Vision でも掲げられるようになりました。
それを確認する手段はいくつもあるかと思いますが、モノタロウではデータを大事にするデータドリブンの文化が浸透しており、本件も何らかの指標により確認できないかと検討している中で出てきたのが 4keys でした。
問題意識
私は EC システムエンジニアリング部門という ECサイト monotaro.com 等の開発・運用を担当する部署に所属しているのですが、そこでの問題意識として下記がありました。
- リリースに関する負荷が高く、週1回となっている。
- 1リリースあたり30～50件のプルリクエストをリリース
- 1リリースあたり1～2時間がかかり、ロールバックが必要な場合はさらに時間がかかる。
- 上記に際して申請等の準備を含めるとさらに時間がかかるため、各チームではなくチーム横断でリリース担当者を募り、その担当者にその負荷が集中している。
私としても2021年にモノタロウに入社し DevOps チームへ配属となり「DevOps とはなんぞや？」というのを探索する中で、『LeanとDevOpsの科学』といった書籍や「推測するな、計測せよ」といった DevOps の考えに出会い、その中で「4keys の収集と可視化は DevOps の良い活動の一つでは？」と考え始めていました。
4keys 基盤の構築と PoC
システム構成図
4keys の収集と可視化の実装の手段は最終的に3.としました。
最初は2.で考えていたのですが、より詳細に分析したい、生データにアクセスして一つひとつ深掘りしたいといったモチベーションから3.を選択しました。
- Google が提供するソース （ GoogleCloudPlatform/fourkeys ）
- JIRA が提供する各機能
- Google Apps Script で Jira Server platform REST API をコール＆加工した上でスプレッドシートへ 4keys データを保存
PoC （Proof of Concept、概念実証）
その後、一部の開発チームに提供し 4keys が利活用できるかどうかの効果検証を行いました。
具体的にはいくつかのチームで 4keys の収集と可視化 → フィードバック → 改善…を繰り返し、各開発チームが実際に利用できる状態としていきました（詳細は後ほど紹介します）。
モノタロウでの 4keys の再考・深掘り
デプロイ頻度、変更障害率の本来からの定義の変更
当時 EC システムのリリースは週1回だったことから、本来の定義で言えば「デプロイ頻度は常に週1回」「変更障害率は1リリースあたりおおよそ数十件のプルリクエストにより必然的に高くなること」となっていました。
そのため、収集と可視化の対象外とすることも考えましたが、『LeanとDevOpsの科学』によれば「バッチサイズ（1チケットあたりの作業量）」に着目する例も紹介されていました。
そこで、モノタロウではプルリクエストに着目し、デプロイ頻度ではなくリリースしたプルリクエスト数を「デプロイ量」として収集するようにしました。
左上は日別、左下はレポジトリ別、右2つはチーム別でそれぞれフィルタリングしながらデプロイ量をグラフ化
デプロイ量の深掘り （d/d/d）
モノタロウではエンジニア組織の拡大に伴いチーム内の人員増加、異動、組織再編が比較的多く発生しているため、それを考慮しないと「私のチームのデプロイ量は30%増えました！」といっても、実際には人員増加の影響もあり得ます。
そこで d/d/d という @hiroki_daichi さんもご紹介された指標の考えも取り入れました。
deploys / a day / a developer の略で 1日あたりのデプロイ回数を開発者数で割ったもの。
https://twitter.com/hiroki_daichi/status/1100381137929625600
デプロイ数はデプロイ量として d/d/d をグラフ化
変更のリードタイムの深掘り （箱ひげ図 / ヒストグラム / 移動平均）
変更のリードタイムは最初は月ごとの平均値を可視化していたのですが、各開発チームから「これを見てどのように分析すれば良いかわからない」とフィードバックをもらいました。
そのため、箱ひげ図やヒストグラムで外れ値を排除し、見るべきポイントを明らかにしました。
各開発チームはどのあたりのボリュームゾーンが多いかを把握したり、そのボリュームゾーンを左にずらすための施策を考えたりします。
もちろん生データへのアクセスも容易にできるようにすることで、より分析しやすい状態となるように改善しました。
変更のリードタイムのヒストグラム
縦軸はプルリクエスト数、横軸は変更のリードタイム（例えば「～3」は変更のリードタイムが2～3日という意味となります）
OKR と 4keys
部門の半期 OKR に 4keys の改善を掲げる
モノタロウでは OKR （Objectives and Key Results） をもとに目標管理を行っており、2022年5月〜10月の半期で特に下記2つが目標として掲げられました。
- 各開発チームの変更のリードタイムが2〜4月のものと平均し20%削減されていること
- サービス復旧時間が維持できていること
1.は別途構築されるカナリアリリースを各開発チームが利用することで、従来の週1回リリースから週N回リリースへデプロイ頻度が増加し、翻って変更のリードタイムが削減されるだろうと見込んで設定しました。
取り組み1（カナリアリリースの導入）
詳細は下記の記事をご覧いただけますと幸いです。
（また近日中にその半年後についての記事が公開される予定となります。
デブサミ2022夏に登壇してきました！ ――信頼性とアジリティを同時に上げろ！モノタロウのカナリアリリース導入
取り組み2（各開発チームへの SRE の移譲）
モノタロウの EC システムは SRE を導入し 4keys でいうサービス復旧時間は安定するようになってきた一方、オンコールチームの負荷や属人性の増大といった課題も生まれてきました。
そのため、現在 SRE チームが各開発チームへ SRE のノウハウを伝えながら徐々にオンコール等を移譲する取り組みを進めているのですが、その際にサービス復旧時間が悪化していないか、またヒアリングを通して改善の余地がないかの確認も合わせて行っています。
モノタロウでの SRE の取り組み: SRE導入: システムを安定させる4000万円の魔法の壺
成果と新たな課題
結果から言いますと「変更のリードタイムの20%削減」はあまり達成できませんでした。
どちらかと言うと数値目標の設定の仕方が良くなかったという結論に達しました。
今回の目標は「従来は週1回リリースだったものの、カナリアリリースの導入と利用により週1回を待たずにリリースでき、変更のリードタイムは削減されるだろう」という仮説をもとに立てられたため、まずはカナリアリリースの利用状況を見る必要がありました。
「変更のリードタイムの20%削減」の達成状況
カナリアリリースが導入された2022年7月以降、変更のリードタイムの削減が達成された割合が増えているが、月によって案件の規模が異なる等の他の要因により達成できないことも確認された。
そこでカナリアリリースの利用状況を追加で収集したのですが、たしかに「使い倒している」利用状況にはなっていないことがわかり、翻って変更のリードタイムの削減もまだ道半ばだろうと結論付けました。
2022年9月のカナリアリリースの利用状況
最大1日3回まで可能だが、まだ1日1回または2回のケースもある
その際に私の上司が「先行指標と遅行指標*2 の違いに気をつけて数値目標を設定すると良いのではないか？」と教えてくれました。
たしかに本件で言えばまず第一に計測すべきなのは「カナリアリリースの利用状況」で、それがどれくらい「変更のリードタイムの削減」に効果を与えたのかを見ると良かったと振り返って学びました。
このあたり数値目標の設定の難しさを感じた部分でした。
ちなみに「サービス復旧時間が維持できていること」は現状達成できていますが、引き続き SRE チームとともに注視しています。
100人規模のエンジニア組織での難しいところ
EC サイトの開発チームだけでなく、販促システムや企業向けシステム等の開発チームへの 4keys の普及も並行して行っているのですが、課題と言いますか現状下記により丁寧に議論を重ねています。
- システムにより方向性や 4keys の指標に関する課題感・モチベーションが異なる。
- システムにより開発フローや「変更失敗とは？」といった定義が異なり、 4keys 収集の方法も異なる。
システムによってそれを取り巻く環境が異なるため、例えば「一律に変更のリードタイムは〇〇日であるべき」といったことは望ましくないと考えており、 4keys を普及する際には課題感やモチベーションを伺うことも大事にしています。
100人規模のエンジニア組織となると開発チーム数も多くなり、各開発チームの目的や特性も異なることも多いと思われるため、このあたり気を付けていかないとという学びを得ました。
また「システム構成図」の通り、現在は内製開発で 4keys の収集と可視化を行っているのですが、それにかかる管理・運用工数やカスタマイズの開発・分析工数が 4keys の普及とともに増加してきています。
そのため「Findy Team+」といったサービスの利用の検討や上記の工数を削減する取り組みを行っていき、なるべく利用者が利用したいときにすぐに利用できるようにと考えています。
こういった新しい取り組み・普及はいかに認知されるか・利用されるかが大事だと思い、また利用者にとってモチベーションが一番高いのは利用したいとき（依頼や要望を出したとき）だと考えているため、依頼や要望を待たせるのはなるべく避けていけるようになりたいと思っています。
今後
約1年ほど 4keys の活動を続けてきましたが、既に 4keys を利用するチームにはさらに継続や利活用を、また他の開発チームへさらに導入を拡大できるようにしていきたいと考えています。
また変更のリードタイムのさらなる深堀りや開発・運用コストの削減など、「利用者がより簡易にセルフマネージドで利活用できる」の世界観で 4keys 基盤、 "MonotaRO 4keys Platform" の開発を進めていきたいと思います。
加えて最近「2022 State of DevOps Report*3 」が公表されましたが、その内容については広く議論が行われているとのことで、動向をチェックしながら適宜取り入れていきたいと考えています。
最後に、もし本記事でモノタロウでの DevOps や SRE について興味が湧きましたら、下記の別記事やカジュアル面談でお話しできたらと思います。
「お客様に良いものを作って届けたい」ECサイトにおける開発生産性とサービス信頼性の向上に取り組むテックリードの挑戦
*1:「エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ」 https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance
*2:「先行指標と遅行指標 | サーバントワークス株式会社」 https://www.servantworks.co.jp/posts/leading-indicator-vs-lagging-indicator/
*3:「2022 State of DevOps Report | Google Cloud」 https://cloud.google.com/devops/state-of-devops/
