DevOps への投資に対するリターンを計算する方法
DevOps や Platform Engineering, Developer Productivity など、開発活動の生産性を高める活動や分野を指す言葉が広く謳われるようになってきましたが、その活動を始めようと思っても効果について説明するのは難しいなと感じていました。
そんななか、Google Cloud による The ROI of DevOps Transformation という、DevOps 施策の ROI を計算する方法がいくつか紹介されている記事を見つけました。
この記事の内容がそのまま使えるかと言うと判断に困るのですが、面白かったので 1 つの計算方法として紹介していきたいと思います。
前提
Four Keys について
DORA の研究によって、Four Keys 指標は組織のパフォーマンス（収益性、品質、顧客数、満足度など）に相関関係があることが分かっています。
Four Keys 指標とは以下の 4 つです。
- デプロイ頻度
- 変更のリードタイム
- 変更障害率
- 変更による障害からの復旧時間
DevOps への投資に対するリターンの種類
1. 不必要な修正や手戻りの削減から得られる価値を考える
英語は "Value Gained from Unnecessary Rework Avoided per Year"
DevOps に投資をすることで不要な手戻り作業を削減できたとすると、その削減した分は「コスト削減」ではなく「価値の創出」と捉えることができます。
これは、削減した分は価値を生み出す活動にあてることができるはずなので、「価値ある活動に従事する新しい人材を確保したのだ」と考えられるためです。
※ もし削減した分の不要人材を解雇すれば価値の創出はなく本当にコスト削減になりますが、これでは社員にとって DevOps を実現するモチベがなくなり組織文化に悪影響を及ぼすので避けるべきだと書かれています。
新しい人材を確保 & 定着させるのは難しい世の中なので、既存の人材を育成し価値を生み出していく方が費用対効果が良いです。
計算式は以下です。
ざっくりいうと以下のような計算式です。
回避されるコスト（=創出できる価値）(¥/年)
= 技術職全員にかかるお金の総額(¥/年) × 削減できる時間(%/年)
なぜ技術職全員の給与の総額なのかというと、不必要な修正や手戻りというものは複数のチームをまたいだ無駄な活動になるからです。厳密に計算したいなら、DevOps の投資によって本当に影響を受ける関係者のみの給与でも良いかもしれないですね。
細かく見ると Benefits Multiplier という名前の要素があります。これは、実際には社員には給与だけじゃなくて福利厚生などでもっとお金を払っているよねということで、給与に対してさらに × 1.5 の計算を行っています。
そこに対して削減できる時間の割合をかけて、創出できた価値を計算しています。削減できる時間の割合については見積もる必要があります。
DORA は Four Keys のパフォーマンスレベルごとで Unplanned work and reworkという数字が出ており、仮に 18% までこの値を下げられるとしてそれぞれ 0.5~2% で計算しているようです。しっかり見積もって計算しても良いと思っています。
計算例ですが、例えば技術者が 100 人いて、平均給与が 500 万だとし、無駄な手戻りや作業が全仕事時間の 2% ほどを占めていてそれを削減できるとすると、
100 * 500万 * 1.5 * 0.02 = 1500万/年
が価値として計算できます。
2. 新機能への再投資によって得られる可能性のある価値を考える
英語は "Potential Value Added from Reinvestment in New Features"
先程は「削減」=「価値」という考え方であり、例えば削減分をテスト自動化やドキュメント整備、人材育成などに時間を使うことを前提としていました。
今回では、その削減分をすべて新機能開発に費やすことを想定し、それによって得られるかもしれない収益を算出して、DevOps への投資の有意性を説明しようとしています。
計算式は以下です。
Where がややこしいですが要は式が分解されただけです。ざっくりいうと以下のような計算式です。
得られるかもしれない収益（=創出できる価値）(¥/年)
= 新規事業に期待できる収益(¥/年) × 削減できる時間(%/年)
新規事業に期待できる収益を計算し、削減できる時間をかける（削減分を新規事業にあてるため）ことで、DevOps が影響を与えた分の収益額を出しています。
細かく見ていきます。
Frequency of experiments per line of business
×
Lines of business in the organization
ここでは事業ラインごとの平均デプロイ頻度と事業ライン数をかけて「組織の実験可能回数」を算出しています。実験とは顧客に対して自分たちの施策が成果を上げられるかどうかを検証することで、例えば A/B テストや、ベータ機能のリリースなどが当てはまります。
× Idea success rate
実験可能回数に対してアイディアの成功率をかけています。この式により、実験回数が多く、顧客からフィードバックを得やすい環境であることが新機能の成功に大きく貢献することがわかります。
DORA は、アイディアの約 1/3 がヒットすると調査しています。
× Idea impact
× Product business size
DORAは、新機能のアイディアが成功するときは既存の収益に対して 1 % ほどの貢献が見込めると報告しています。
例えば年に 100 回の実験を行い、それらが 33% の確率で成功し、その成功したアイディアが既存の収益 1 億に対して 1 % の影響を与え、そのような新規事業に対して新たに 2% の時間をあてられそうなら、
100 * 0.33 * 0.01 * 100,000,000 * 0.02
= 660,000 円/年
が DevOps への投資がもたらす効果になります。
新規事業に期待できる収益をこれ以外の方法で上手く見積もれる場合は、特にこの計算にこだわらなくともよいと思います。
3. 年間のダウンタイムコストの回避から得られる価値を考える
英語は "Cost of Downtime Per Year"
ダウンタイムはその時間分の稼働時間が失われるので、売上や社員の給与に対する対価がゼロになるのはもちろん、対応に対する追加コストや顧客満足度の低下、ブランディングへのダメージといったコストもあります。
計算式は以下です。
ざっくりいうと以下のような計算式です。
年間ダウンタイムコスト（=創出できる価値）(¥/年)
= 1h あたりのダウンタイムコスト(¥) × 障害時間(時/年)
障害にかかる時間を計算するために、デプロイ頻度と変更障害率、そして障害からの復旧時間を利用しています。
例えば年 10 回デプロイするチームが 30 % の確率で障害を起こし、その復旧に 10 h かかる場合、
10 * 0.3 * 10(h) = 30h
が障害時間になります。
ちなみに年に 700 回デプロイするチームが 5% の確率で障害を起こし、その復旧に 15 分かかる場合は以下です。
700 * 0.05 * 0.25(h) = 8.75h
1h あたりのダウンタイムコストを出すのは、業界の特徴や事業のサイズ、また障害の度合いによって異なってくるので難しいですが、DORA は調査として $500K/h という数字を持っているようでした。
例えば、
1h あたりの売上額 + 1h あたりの技術職社員の給与 + 障害にかかるその他コスト
などでもう少し精度の高い数字が出せるかもしれません。
ROI の計算
ROI は「リターン / 投資」です。
リターンの計算のために、まずは先ほど計算した 3 つの価値を足し合わせます。
3 つの価値を足し合わせると「年間で得られる利益」が分かります。DORA はこのような計算以外にも、例えば従業員の式が上がるなどの付加価値を考えても良いと言っています。というのも、従業員の満足度は企業の業績に相関があると分かっているためです。
あとはこれを「投資額」で割ると ROI が分かります。投資額については DORA は以下のような例を出していました。
- コンサル料金
- DevOps に関する投資をどのようなところに導入できそうかの戦略決め
- ロードマップの作成
- 導入するソフトウェアの料金
- 新たな SRE や DevOps エンジニアにかかる料金
- DevOps やアジャイルなどに関するトレーニング料金
- 新しい施策を実現するためにかかるリソース
- 既存の人員にかかる負担・時間
- 例えばキャッチアップコストやリファクタ作業など
- その他リソースなど
- 既存の人員にかかる負担・時間
回収期間の計算
回収期間も判断軸になります。「投資 / リターン」で回収期間を算出できます。
例えば 1000 万の投資をして、毎年 500 万回収できるなら、回収期間は 2 年となります。
気になった点・追記
最終的には合意が取れるかが大事
当然ですが、この計算方法が正解というわけではないので、参考にしつつ自分たちの組織にあった計算を行ったり資料を作ったりすると良さそうです。
効果測定について
効果測定をしておくと、もし次回さらに DevOps へ投資しようと思ったときにその効果が予想とどれくらい乖離していたかの情報を示せると説得力が増すと思いました。
例えば、
- 実際に対象のタスクはどれくらい削減できたのか
- その削減時間を何に使えているのか
- 可能なら、その新たな活動がどのような価値を生み出しているのか
- 従業員の満足度が向上したのか
などでしょうか？
3つの価値を足し合わせて良いのか？
- 不必要な修正や手戻りの削減から得られる価値
- 新機能への再投資によって得られる可能性のある価値
- 年間のダウンタイムコストの回避から得られる価値
の 3 つを足し合わせてリターンとしていましたが、3 つ合算していいかどうかは浮いた時間を新機能開発に使うかどうかによるなと感じました。使わない場合は厳密には 1 + 3 になりそうです。
ただし、効果を説明する都合を考えて全部合算しても良さそうです。
先人の存在
この記事よりも先に、同じ Google の記事を引用しながら DevOps への投資を説明する先人の記事がありました。
ここまで書いて公開しないのも悲しみなので Zenn で公開供養させていただきます…
実際にこの計算方法を Google は使っているのか？
Google は分かりませんでしたが、先の節で参照した Cyboer Agent Group の Developer Productivity 室がこの計算方法を使っているようでした。
終わりに
このような流れで、今回参照した DevOps への投資とリターンの記事が生まれてきました。
- クラウドの登場によってアプリケーションは素早い価値提供が求められるようになった
- Four Keys のようなデプロイパフォーマンスが重視されるようになった
- 実際に Four Keys 指標の良さは業績の良さと相関関係があることが分かっている
- Four Keys 指標を押し上げるのはケイパビリティ
- ケイパビリティを高めるために DevOps への投資が必要
- DevOps への投資の納得材料としての計算方法の提供 ← イマココ
組織のパフォーマンスを高めるために DevOps の投資が重要という話でしたが、もっと単純に DevOps が充実することで開発者が開発を行うのが楽しくなったら良いなと思いますね。
この計算を実際に利用してみてどうだったのか、その感想記事が生まれるのを楽しみにしています！！
Discussion