開発組織の貢献は売上として直接語るのはやはり無理があるのではないかという考察

posted at 2023/05/06

先日サーバントワークスさんが公開した計測によるスクラムチームのパフォーマンス向上を読んで、以前自分が書いた開発の改善はKPIに翻訳しなければいけないのかをもうちょっと言語化することができそうだったのでメモ。

TL;DR

結論としては、開発の改善はKPIに翻訳しなければいけないのかでも書いた通り開発組織はビジネスの実現を担っている職能であり、理想的には「永久に持続性がある状態」で「0秒でしかも並列数を無限」でモノが実現されて、「不具合やパフォーマンスの劣化は 0」であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもないから考え方は変わってないが、改めて整理して

開発組織は、Ability to Innovate と Time to Market 2つのケイパビリティが高い状態を維持することで結果として Current Value -> Unrealized Value を近づける原動力となりプロダクト全体の成功の確率を高めることに貢献することができるため、これらのケイパビリティを向上させる改善については売上などのKPIに翻訳する必要性は必ずしもない

という主張となった。

背景にある考え

計測によるスクラムチームのパフォーマンス向上自体は短くまとまっていて非常に読みやすいのだが、その前提となるエビデンスベースドマネジメントガイド（EBMガイド）も読んでおくことを勧める。

また考察をまとめる際には、 CTOの頭の中：技術を財務で表現するにも大きく影響を受けた。

まず自分の中でのエビデンスベースドマネジメントガイド（EBMガイド）や計測によるスクラムチームのパフォーマンス向上の要約は上記のような図の認識をしている。

※ 用語の補足

Ability to Innovate (A2I) : Unrealized Value を Current Value に移管する (= Current Value の状態から Unrealized Value へと近づく) ような価値の提供にどれくらいのフォーカスを使えているのか
Time to Market (T2M) : 市場にリリースしてユーザーの声を聞いて学習のフィードバックサイクルを回す時間はどれくらい短いのか

つまりざっくりと言ってしまえばエビデンスベースドマネジメントガイド（EBMガイド）は、 Ability to Innovate と Time to Market という2つのケイパビリティが Current Value -> Unrealized Value の状態に近づけるための原動力となる という主張をしていると自分は捉えている。

またアジャイルな方法 (主にスクラム) で問題解決を試みているということは、「CIの改善をスクラムでユーザーストーリーとして扱うか？」を考察するでも紹介している Cynefin Framework における Complex な問題 (= 実験を通してユーザーからのフィードバックがなければ正しさの判断ができない問題) を相手にしているということになる。
これも持論になってしまうが、そういった構造の中のアウトカムというのは 成功確率 x 試行回数 の掛け算によって確率的に定まる (つまり良くも悪くも想像とは違った結果になり得る) と考えている。
この掛け算のそれぞれの要素こそが Ability to Innovate と Time to Market であり、特に Time to Market はその名前からも連想できる通りエリート DevOps チームであることを Four Keys プロジェクトで確認するなどで語られている 4 Key Metrics の Delivery の指標として登場する Lead Time と Deploy Frequency が Time to Market のケイパビリティを測定するための1つのメトリクスとなり得るのではと考えることができるようになる。

つまり開発の改善はKPIに翻訳しなければいけないのかで書いた

開発組織はビジネスの実現を担っている職能であり、理想的には「永久に持続性がある状態」で「0秒でしかも並列数を無限」でモノが実現されて、「不具合やパフォーマンスの劣化は 0」であってほしい。もちろん現実世界ではどれも実現できないのでそこにいかに近づけるかということを目的に改善を実施すればよく、売上などのKPIに翻訳する必要性は必ずしもない

という結論は、今回学んだことを取り入れて整理すると以下のようになりそうである。