6.3. ソフトウェア資産の蓄積と売上の時間軸（微積）
ここで開発における、P/LとB/Sのつながりを考えていきます。端的に言えば、ソフトウェアを開発するという蓄積と部分と、それが売上につながる部分の時間差に難しさがあります。
私たちはソフトウェアを作っている中で、開発作業のすべてがすぐに売上に直結しないことを知っています。当然、ソフトウェアを作っている最中は、価値を生まず人件費だけがコストとしてマイナスされていきます。
また、技術負債への対応としてリファクタリングといった内部品質にかける開発は直接売上につながるものではなく、時間をかけてソフトウェアの価値をあげていきます（資産の耐久年数を伸ばすという意味で、B/Sの負債部分を減らしているとも言えます）。
つまり、「開発→資産」のB/Sへの蓄積的な積分と、「資産→売上」といったP/Lへの貢献部分です。よく、事業とエンジニアリングの接続・融合を考えたときに、このcash inから逆算（微分）しようとすると、例えば負債を減らしている「リファクタリング」という作業が、直接P/Lに与える影響を算出しようとすると（具体的な金額で）、そもそも時間軸が違うので難しかったり、細分化（微分）ができなかったりします。
6.4 開発生産性を上げると、P/Lはどうなるのか
この前提に立ったときに、開発生産性が上がるとP/Lにどのような影響があるかを考えていきます。
まず、開発生産性の改善には2つの意味があると思っています。スループットの改善とリードタイムの改善です。スループットは一定期間あたりの生産量を示しており、リードタイムは一定期間あたりのプロセスにかかる時間で横と縦の関係です。主に投入資源に対してのリターンなので、スループット的な考え方が開発生産性の改善とも取れますが、実際にはリードタイムの話を指定することもあります。
よく開発組織とビジネス側の会話として、「いつリリースされるのか？」という会話はリードタイムの会話です。つまり、事業責任者側からすると「この機能がほしい」という要望を出した後は詳しく進捗を確認しているわけではないことが多く、なんとなくリリースされるのが遅くないか？ という認識を持っています。中身としては効果による優先度付けがされたり、社内のリソース不足によって待ちになっていたりします。
一方、開発組織にかけるコストに対しての価値（生産量）についてはスループット的な会話です。予算に対しての生産が妥当かという話です。例えば、年間人件費が1億円だったとして、開発組織が出した生産価値が妥当なのか、来年はどのぐらい予算を積むべきなのかといった会話です。1億円の中身を見たらずっと保守運用ばかりで、新しく資産価値を作る開発ができていないことがある場合は、対策を考えなければなりません。
その上で、開発生産性を上げることで儲かるのかについては、スループット（P/L）の話です。
まず、コストについて見ていくと、開発生産性を上げたとしても固定人件費は変わりません。そこに人がいる限り給与は発生しますし、昇給などもあります。一方、無駄な開発費用が減ることは大いにあります。
開発生産性が高い組織＝開発速度や開発効率が高いチームは、通常開発速度が遅いチームに比べてイニシャルコスト（初期費用）が少なくなったり（短くなったり）、炎上プロジェクトへの人員投下がなかったり、調整コストが少なく済む可能性が高いです。
また、PdMや事業責任者が考えた仮説が"一定の確率"で価値を上げるとすると、"継続的な速さ"は価値になります。具体的には、以下2つのメリットが考えられるでしょう。
- Q単位の仮説検証プロセスの回転数
- 1施策あたりのリードタイム短縮
特に1つ目は、技術がコモディティー化する中で競争優位性として、開発生産性の高さは大きな差別化になるとメリットは大きいでしょう。
もう1つ、同じ売上という観点でも損失の最小化があります。開発生産性という枠からは少し飛躍しますが、開発生産性が高い組織が技術負債も少ないとすると、インシデント（障害）の数が少なく、ロールバックの素早さから売上の被害を最小化できます。逆に技術負債が多い環境だと、予想外の障害が起こったときに影響範囲調査に時間がかかる傾向があります。
論文の「Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases」というコードの品質がビジネスに与える影響がある資料を見ていても、以下の結果が述べられています。
- 欠陥数の増加：低品質のコードは高品質のコードに比べて「15倍」も多くの欠陥を含んでいます
- 問題解決時間の延長：低品質のコードで問題を解決するには平均で「124％」も多くの時間がかかります
- 予測不可能性の増加：低品質のコードでの問題解決には、最大で「9倍」も長いサイクルタイムがかかることがあります
開発生産性が上がると、以下の効果が生まれてきます。
- 人件費自体は変化しない
- ただ、無駄な開発費用は減る
- Q単位の仮説検証プロセスの回転数やリードタイム短縮による競争優位性の向上
- 障害の影響最小化による売上損失
6.5 「儲かるか」ではなく「資産価値が上がっているか」を考える
ここまで見てきた中で、開発生産性を上げる改善は儲かるかについては「改善が売上やコストへの影響度を一番初めに考えるのではなく、まずは資産価値が上がっているかどうかを考えよう」というのが現時点での答えです。
前述したとおり、私たちは直接売上を作っているのではなくソフトウェア資産を作っています。そのソフトウェア資産が、セールスやマーケ部門を通して売上を上げているかどうかなので、間接的に紐づきます。
そのため、まずは自分たちが行っている改善がソフトウェア資産の価値をあげているか、つまり資産を使うユーザーの体験が良くなるなど、資産として耐久年数が伸びるようになっているか（適切にリファクタリングされているか）を考えていくのがよいでしょう。
業務の中で保守運用が多いなど、資産価値をあげるような改善（新規開発や内部品質改善）ができていないと資産価値が落ちていくため、すぐに作り直さないといけないシステムができあがるほか、利用者が使いづらいソフトウェア資産ができあがってしまいます。
まとめると、エンジニア組織はできるだけ開発生産性を上げることで、ソフトウェアが使いやすく長持ちするような改善にリソースを当てることができ、結果として良いソフトウェアが生み出され、売上を作りコストを下げ利益幅を大きくしながら「儲かる」という最終目標につながっていくでしょう。
