天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

Spotifyの開発生産性向上事例 - 効果的なDevOpsアプローチとそのリスクとはに参加してきた

developer-productivity-engineering.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

来る6月28日（金）-29日（土）に開催される開発生産性Conference2024に先駆け、 Keynoteとして登壇いただく元Spotify EMのLaurent Ploix氏に、「Spotifyでの経験から学ぶ、開発生産性の向上事例」をお話しいただきます。

同氏は2023年サンフランシスコで開催されたDPE SUMMITに登壇されており、今回のイベントでは前セッションの内容を踏まえ、Spotifyに閉じない以下事例について、より深い洞察を得られるセッションとなっております。
※前セッションの内容は後述しています

  • 開発生産性へ取り組む上でのメンタルフレームワーク
  • 開発生産性の計測観点や取り組み体制におけるベストプラクティス
  • Four Keysに閉じない、具体的なメトリクスとその背景
  • 開発チームレベルの指標と、ビジネス指標との接続
  • 開発生産性指標の観測において陥りがちなポイント
  • 組織として開発生産性へ取り組む上でのリスク観点

皆さんと一緒に、開発生産性に関する理解と知見を深められるイベントを目指します。

会の様子

DRE Favorable Context

以下の3点がDREが重要になっている背景だという話がありました。

  • 人事が今後200人採用する必要があるものの予定通りにはいっていないという状況を仮定すると、多くの場合は採用面接時間の確保や広告の改善などといった対策が打てますが、システム開発では、そもそも「今が予想通りに進んでいる」ということがわからないため、対策も打つことが難しい
  • 昨今の借り入れが高くつくようになっている状況(採用が重要になっている)は経営にプレッシャーをかけている
  • データサイエンスの正しい活用(A/BテストやDORAメトリクスやSPACEメトリクスを社内分析して、成功事例を共有しながら活用)をする必要性が高まっている

生産性を高めるために必要な3要素

生産性を高めるためには、

  • 良い製品を作ること
  • 優秀なチームが密すぎず疎すぎない依存関係で仕事をすること
  • 有能な開発者が自らの仕事に集中して仕事できるようにすること

の3つが重要だという話がありました。

データ、情報、知識の関係性

まずは生のデータを集め、そこで集められたデータを見てMTTRなどをダッシュボードに情報としてまとめ、その結果をもとに分析をするというステップが重要だという話がありました。

アクティビティ、アウトプット、アウトカム、インパクトの関係性

何かしらのアクティビティはプルリクエスト数などといったOutputにつながり、その後に何かしらのアウトカムにつながり、それが顧客の行動変容につながるという話がありました。

これはメトリクスでいうと、例えばBuild Time -> Developer Satisfaction -> Attrition rate -> Recruitment costsといった形で表現できるということです。

Build TimeやDeveloper Satisfactionといったメトリクスは、何らかの改善を行うとすぐに変化を起こせるためスプリントレベルの計画に使えるものの、改ざんがしやすく意味のないメトリクスになりがちだという弱点があるという話がありました。

失敗事例

Ploixさんは、ビルド関連のメトリクスをはじめとした複数メトリクスを取る環境を作り、JiraやDeployments, CI, Codeといったメトリクスを定期的にウォッチできるようにしたということです。

こうして集まったデータやメトリクスをもとに分析を行ったそうですが、データやメトリクスの正確性はばらばらである上、顧客にとってあまり関心のない分析結果が出てしまったということです。

また、開発者にアンケートを依頼しすぎて疲れてしまったり、適切なアンケートを作ったり整備したりするコストが高かったり、嘘の回答を書いてしまったりといった問題も起きてしまったそうで、対象者を全開発者の1/3ずつに絞ることでアンケートに回答する頻度を9ヶ月に1回としたり、自由形式とNPS的な質問をバランスよく混ぜたり、社内全体で結果が見られるように透明化を図ったということでした。

意味ある分析をするために

分析結果は、社内で起きている問題を解決するものでなくてはならないため、関心度が高い問題解決にインサイトを与える分析結果に絞ったり、得られたデータやメトリクスをすべてそのまま貼るのではなく重要なものに絞って提示したりするのが重要だという話がありました。

メトリクスの罠

例えばあるチームが他のチームを積極的に助けているようなチームだった場合、デプロイ頻度を上げるようにただ指示しても、チーム間の協力関係が損なわれるだけになってしまうという話がありました。

メトリクスは現実を表すものでない可能性もあるため、ユーザー調査などで現実を確認しておく必要性があるということです。

社内で議論のきっかけになるメトリクス

  • DORAメトリクス
  • ゴールデンテクノロジー
  • オンボーディング時間
  • 技術的負債

などは社内で問題を議論するきっかけになるメトリクスだという話がありました。

メトリクスを使う注意点

メトリクスの注意点として、

  • メトリクスは改ざんできるものである
  • 皆が信頼している状態ではないと意味がない
  • メトリクスは判断の根拠に直接的にはならない
  • 仮説を立てて意味がある

が挙げられました。

Q&A

講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

メトリクスの中で特に重視しているステップや項目はあるか？

DORAメトリクスは、会社レベルのメトリクスの基礎となる。
これに加えて、開発者のフォーカスに対する満足度、生産性、使用しているツールなどの調査から抽出したメトリクスを使用することができる。DORAメトリクスと同等のメトリクスとして、MTTRやリードタイム、デプロイ頻度、デプロイメントの問題発生率なども取得することができる。

DORAメトリクスを使った測定は、Spotifyやその他の国際的な企業では標準的な手法と考えられているのか？それとも一部企業が行っているものか？

DORAメトリクスは意外と取るのが難しいので、開発者自身の生産性に対する満足度を把握するための調査から始めることもある。また、DORAメトリクスは共通言語になりつつあるが企業同士の比較は難しく、現実的に計算できているかと言われるとそれは難しい。

オンボーディングタイムは具体的にどのように計算するのか？

毎週すべての新しく入社した社員に対して、オンボーディングされたか？を聞くようにしている。最初はNoと答えるはずだがどこかでYesになるはずなので、そこまでの時間を計測する。

全体を通した感想

メトリクスの有効性や使い方、注意点などがコンパクトにまとまった教科書的な講演で良かったです。

質問にもでていましたが、オンボーディング時間などはあんまり計測をしているところは話として聞いたことがなかったので特に面白かったです。