【開発生産性】開発チームのパフォーマンスを向上させるDORAとSPACEによる改善戦略
はじめに
connpassにあったイベントに参加しました。
DevOpsの有効性を評価するために、「DORAメトリクス」「SPACEの開発生産性フレームワーク」の活用方法などを学びました。
下記のイベント資料と研究内容をもとにDORAとSPACEについてまとめています。
イベントで使用していた資料
DORAの公式研究内容
ソフトウェア開発における開発生産性のような、一般的に概念で語られるものを一定の指標として活用できるのは個人的に良いニュースでした。
DORA
DORAとは、チームがソフトウェア開発において、運用、保守の有効性を測定するために利用できるパフォーマンス指標のフレームワークになります。
4つのメトリクス
このフレームワークは4つのメトリクスで構成されており、画像のように紹介されました。
- 変更による平均リードタイム。コードがコミットされてから、本番環境で実行されるまでにかかる時間を指します。
- リードタイムが短いということは、俊敏な開発プロセスが確立できていることを示唆しています。
- デプロイの回数やデプロイの頻度。
- デプロイ頻度が高いということは、devopsの効率的なフローが確立されている状態を示します。
3.平均復旧時間。何らかのインシデントが発生した場合、障害から復旧までに要する時間です。 - この復旧時間が短いほど、サービスの回復力と応答性の高いDevOps環境を確立できていることを示します。
- デプロイ頻度が高いということは、devopsの効率的なフローが確立されている状態を示します。
- 変更障害率。実環境へのデプロイ失敗やインシデントが発生する割合を評価します。この失敗率が低いほど、テストと検証のプロセスが堅牢であることを示唆しています。
この4つのメトリクスを指標としている理由は、研究によりそれらが相関していることを発見したからです。
その為、これらのメトリクスの素晴らしい側面として、速度が上がれば安定性も上がり、安定性が上がれば速度も上がるというように、相互のメトリクスは連動して評価が上がります。
4つのメトリクスの参考基準
4つのメトリクスの参考として、昨年度の研究から抜粋したものがこちらです。
ボトルネック改善の側面
DevOpsの能力は「技術、文化、アーキテクチャ、コミュニケーション、コラボレーション」などの要素で構成されます。もちろん「リーンの原則やアジャイル」などの要素も含まれます。
DORAはこれらの要素のパフォーマンスを測定し、改善を支援する能力を特定する為の評価基準を提供するフレームワークになります。
例えば、「継続的なインテグレーションを改善したい」というチーム課題に対して、メンバー全員同じ改善策を持つことは少ないと思います。ほとんどの場合、話が噛み合わないことが多いです。そういった際にどういったアクションや要素がパフォーマンスの改善に効果をもたらすかをDORAの研究に差し示されています
アクションとシグナル
DORAによるパフォーマンス改善において、「シグナル」と「アクション」だという考え方が重要になります。シグナルとは現状の評価、アクションはシグナルに基づいてどのように改善していくかという行動を示します。
シグナル
DORAのメトリクスを指しており、スピードと安定性のメトリクスとして測定します。チームがこのメトリクスに沿って、ソフトウェア開発能力を「リードタイム、デプロイ頻度、平均復旧時間(MTTR)、変更障害率」でパフォーマンスを評価します。シグナルで現状の評価をするだけでなく、評価をもとに開発能力を改善するためのアクションを考えます。
アクション
「ソフトウェアの運用能力を改善するためにどのような能力に焦点を当てるべきか」という考え方です。ここではアンケート、アルゴリズム的なアプローチやバリューストリームマップを作るなど多角的なアプローチを取ることができます。
DORA.devのサイトでは、ソフトウェアの運用能力が報告されています。
「Help Me Prioritize」ボタンを押下すると、評価結果や焦点を当てるべき重要な要素が表示されます。
業界ごとに必要な評価が表示され、これらは約10年にも及ぶ研究により分析されています。
SPACE
開発者の生産性を計測するためのフレームワークです。状況や測定したい内容に合わせて、正しいメトリクスのセットを特定するためのフレームワークとして定義されています。
SPACEは、実施したい作業や働く文脈に適したメトリクスを選ぶためのフレームワークともいえます。その為、開発だけでなく、営業やコピーライティングなど様々な作業に使用することができます。
SPACEが推奨している測定指標は5つある。
- Satisfaction and well-being
- Activity
- Performance
- Communication and collaboration
- Efficiency and flow
1. Satisfaction and well-being(満足度と健康状態)
どのくらい充足感・幸福感・健康的表しています。
自身の仕事にどれだけ満足し、健康的であるかを考える。またツールの使用状況や使いやすさなども含まれることがあります。
研究では「生産性、満足度、燃え尽き症候群」は相関関係にあると考えられています。
2. Performance(パフォーマンス)
最終的に想定したことを実行したかを計測するプロセスの結果になります。
信頼性指標・品質指標・顧客満足度・システム全体の速度/パフォーマンスなどを指します。
3. Activity(アクティビティ)
ソフトウェア開発においては、これが最もよく計測される。理由は、自動化が容易であり、定量的な計測が難しくないからです。コミットの数やコードの行数などが当てはまります。
4. Communication and collaboration(コミュニケーションとコラボレーション)
どのようにチームメンバーと協業するかという観点になります。システム連携をどのようにするかということも含まれます。システムやナレッジベースの検索が簡単かどうか、チームメンバーがどれだけ頻繁に会話するか、1on1の回数なども含みます。
5. Efficiency and flow(効率性とフロー)
最小限の遅延と中断で作業を行う観点です。
システムやプロセスを通じた効率とフローに関連します。システム内のハンドオフの回数などが含まれます。
推奨の使い方
SPACEフレームワークを使用して何かを測定する際に、「バランスとトレードオフを考えること」が重要視されています。その為には、3つの異なる側面を使用することを推奨しています。
それにより、異なるバランスとトレードオフが考慮され、一つの側面に過度に依存しないようになります。
コードレビュー例
コードレビュープロセスのプルリクエストのプロセスを迅速化したいと考えます。
通知の設定、アラート機能を実装することで、他の開発者がプルリクエストに気付き、レビュープロセスの効率化が可能になります。この場合、アラートの数やタイミングは「アクティビティ」の要素に該当します。
この数やタイミングよって効率性とフローが妨げられる可能性があります。その為、「二つのメトリクス(効率性・フローとアクティビティ)」を利用するだけでも、スピードと通知量やタイミングをコントロールする必要があります。
さらに、満足度と健康状態のメトリクスを追加します。先述の二つのメトリクスは、自動化されたシステムから取得できるデータです。満足度と健康状態は、開発者がコードレビュープロセスにどれだけ満足しているかを月次や四半期ごとに尋ねることで取得できます。
注意点として、過度な頻度で調査を実施すると、調査疲労が起きる可能性があります。
インシデント管理例
-
Satisfaction and well-being
- インシデント管理プロセスにどれだけ満足しているかを調査。
- エスカレーションシステムやオンコールのローテーションに満足しているかどか。
- 燃え尽き症候群に陥っていないかを調査
-
Performance(システムの信頼性に焦点を当てる)
- モニタリングシステムが問題を検出し、フラグを立てる機能があるか。
- システムのMTTR(平均復旧時間)の調査
-
Activity(定量的に計測できるメトリクス)
- モニタリングシステムで検出されたデータの数
- インシデントの数
- 解消済みのインシデント
それぞれの側面をスコアリングし、スパイダーチャートなどで表すことで、どのような要素がトレードオフになっているかをみることができます。
どの側面を解決しなければいけないのか、どのようなメトリクスが適切かをグラフ化することで見極める手助けをすることができます。
またこのグラフやデータをチームに共有することで、欠損している観点やトレードオフになっているものが適切かを判断することができ、全体的な考えを踏まえた状況が把握できます。
登壇者からGithubでSPACEを活用した研究を紹介して頂きました。
githubでの研究例
発者個人が良い毎日を過ごす方法を見つけることを目的とした研究です。SPACEフレームワークを利用して、開発者の負担にならないよう、迅速かつ簡単な測定方法を作成し、実施しました。は次のような質問を行った。
- 「あなたの仕事はどうでしたか？」
- 「他の人と一緒に仕事をしましたか」
- 「仕事は中断されましたか」
- 「何回ミーティングがありましたか」
この調査で分かったことは、「仕事の中断がほとんどない、全く無い人は良い一日を過ごす可能性が82％だった」ということです。
これは、たった2分間の小さな調査だったが、人々に1日を締めくくる素晴らしい方法を提供したという研究になっています
DORAとSPACEの関係性
この二つのフレームワークは補完的な関係をもち、また共通点もいくつかあります。
補完的な関係
SPACEは、どのような状況においても活用することがき、適切なメトリクスを特定するのを後押ししてくれます。
その為、DORAを使用して改善したい項目を特定した後、SPACEを使用してどのように測定し、どのメトリクスを使用するのかを決定するような使い方を推奨しています。
共通点
DORAはSPACEのメトリクスの一部と考える。
DORAは既にSPACEの要素をカバーしています。ソフトウェアのデリバリープロセスで考えてみると下記のように見ることができる。
- リードタイムは効率性とフロー
- デプロイの頻度はアクティビティ
- MTTRは効率性とフロー
- 変更障害率や可用性はパフォーマンスの指標
| DORA METRIC | SPACE DIMENSION |
|---|---|
| Lead time | Efficiency and flow |
| Deploy Frequency | aActivity |
| MTTR | Efficiency and flow |
| Change fail rate | Performance |
| Availability | Performance |
DORAはSPACEの5つの側面の3つをカバーしている為、DORAはSPACEの一部と言えます。
組織文化
イベントでは、SPACEとDORAの活用しても、「変化を生み出すには十分ではない」とありました。その理由として、チームや組織の文化が関係します。
組織が人員にどのような体験をしているのかを示す指標に注目し
ており、パフォーマンスを予測するうえでチームや組織の文化に寄与すると思われる要素が研究で画像のように示されています。
画像の要素を取り入れた所謂創造的文化の組織は、そうでないチームよりおよそ30%組織パフォーマンスが高いという研究結果がでております。
まとめ
DORAとSPACEのフレームワークはソフトウェア開発と運用のプロセス改善に非常に役立つツールであることが明確になりました。これらの指標は、開発速度の向上、安定性の保持、さらにはチームの満足度と協力を促進するための効果的な手段を提供します。特に、これらのメトリクスが互いに補完し合い、相乗効果を生み出すことは、開発プロセスの最適化において非常に価値のあることか思います。
私たち開発者にとって、これらのフレームワークを活用することで、より効率的かつ効果的な開発環境を整えることが可能になると考えます。組織文化がパフォーマンスに与える影響を理解することも重要で、創造的で開かれた文化を育むことが、技術的な成功だけでなく、チームとしての充実感にも繋がると思いました。
感想
今後は、DORAとSPACEを日々の業務に積極的に取り入れることで、持続可能な開発プロセスを築き、絶えず改善を追求する姿勢を持ち続けたいと思います。これにより、開発者としてのスキルを磨くだけでなく、より良いチームとしてさらに研鑽できるかと思いました。
参考
Discussion