コード品質はビジネス上の成果にどれほど影響を及ぼすか
こんにちは、kubopです。
以前コードの品質が、ビジネス上の成果にどれほどの影響を及ぼすか定量的に調査した論文を読んだことがあり、自身の経験と照らし合わせてnoteを書いてみようと思います。
参考論文はこちら
コード・レッドコード品質がもたらすビジネスへの影響
結論から言うと、以下のような結果になります。
高品質なコードは低品質なコードより、
- 欠陥が15倍少なく
- 開発速度が2倍になり
- 問題解決の時間の予測精度が大幅に上がる
高品質なコードのビジネス上の優位性は紛れもなく明らかである。
コード品質が
- 報告された不具合の数
- 問題解決に要する時間
- 時間通りに問題を解決する予測可能性
にどのような影響を与えるかどうかを
- ソースコード解析
- バージョン管理マイニング
- Jira
からの課題情報の組み合わせに基づき、CodeSceneを用いて分析しました。
技術的負債が開発者の時間を42%浪費する
コード品質は、抽象的な概念であるため、ビジネスレベルでは支持されない。
その結果、ソフトウェア事業社はコード品質を市場投入までの時間や新機能と引き換えにし続けています。
その結果、技術的負債が開発者の時間の42%を浪費していると推定されます。
最近の研究では、開発者は平均して時間の約60%をプログラム理解活動に費やしていることが示されている。
Politowskiらの研究によると、アンチパターンのスパゲッティコードを含むコードは、それ以外に比べて理解に39.5%の時間を要することが示されている。
実際にこれは正しいと私は感じていて、開発者として仕事をする際は、実際にコードを書き始めるより先に理解する作業があり、かなりの時間を費やしています。
コードを理解しながら、書き進めることもあり、複雑で理解が難しいコードでは巻き戻しや設計を変更せざるを得ないことも良くありました。
また、理解が困難である場合や影響度がわからない場合は不具合を起こしてしまったりもしていました。
低品質なコードには高品質なコードの15倍、欠陥がある
コード品質がファイルの不具合数に大きな影響を及ぼしていることがわかりました。
平均値を比較すると、品質の低いコードはそうでないコードに比べて15倍もJiraの不具合が報告されることがわかります。
これはビジネスの観点から重要なことで、米国だけでも品質の低いソフトウェアのコストは年間約2兆8400億円もかかっています。
また、ソフトウェアの欠陥は、予定外の作業につながりコスト超過になります。
最後に、ソフトウェアの欠陥に伴う機会損失があり、開発時間の大部分を欠陥の修正に費やすと製品の競争力を維持するための新機能を実装する時間が少なくなります。
noteではコードの品質を数値化したことがないので実際の数字との相関関係は不明ですが
よく不具合を起こす場所は確実にあり、その部分の理解が難しい状態であるということがわかっています。
Google本でいう、いわゆる幽霊の出る場所、のようなコードは存在しているしその部分での不具合は多発していたという事実が不具合issueをいくつか分析した結果わかっています。
低品質なコードの問題を解決するには、平均して124%以上の開発時間がかかる
Jira課題と、Jira課題のうち欠陥と呼ばれるサブセットの解決に関連する時間を測定することにより研究が進められた。
Jiraでは、課題解決にかかる時間を2種類に分類しています。
- サイクルタイム
- あるアクションの開始から終了までの時間
- 課題が"進行中"である期間
- リードタイム
- アクションのリクエストを受け取ってから、アクションが完了するまでの全時間
低品質なコードでは、欠陥の解決や新機能の開発といった変更の実施に不確実性が高く、開発期間の分散はコード品質が低いほど大きくなることがわかりました。
同程度の複雑さの変更の場合、低品質なコードでは、変更の実施時間が平均して2倍以上長くなる。さらに、低品質なコードでは開発期間が1桁長くなる例もいくつか観察された。
つまり、市場投入までの時間が必要な時間の2倍以上になることを意味するため、組織がコード品質をどのように評価するかに劇的な影響を与えるはずです。
低品質のコードで貴重な時間を浪費することは、ビジネスを不利にすることになります。
Four Keys Metricは業界では一般的になっており、多くの注目を集めているものの、Four Keys Metricは実際のソースコード開発ではなく、ソフトウェア開発のデリバリーサイドに焦点を当てている。
そこで本研究は、図に示すようにコードが書かれた時点で導入される無駄に着目する。
技術的負債コミュニティからの研究ではこの無駄が重要であることを示している。開発者は、技術的負債により23%の時間を無駄にしていることがわかり、42%に達する可能性もある。
実際にサイクルタイムを測ったことがないのでどうなんだろう…と言う気がしました。（測ったことがある人は教えて欲しいです。
Four Keysがデリバリに目が向いているのは事実で、その部分と品質が相関しているかというと必ずしもそうではないのかなと思いました。
今回の研究では、コード品質とサイクルタイムに着目されていたので、Four keysとはちょっと異なる性質だと思いました。
コードを書く前〜コードを書き始める〜
↑ここの無駄部分が技術的負債と関係あるのではというお話かなと思います。
低品質なコードの問題解決は、最大サイクルタイムが9倍長くなる
低品質なコードにおけるTime-in-Developmentは、Jira課題の最大開発時間がコード品質が低いほど長くなると言う意味で、著しく予測性が低いことがわかります。
健全なコードの最大開発期間より9倍かかることがわかります。
予測性が低いと、管理者のストレスレベルが高まり、経済的な影響にとどまらずストレスによる無神経さが発現することがあります。
課題解決が長くなってくるのは、上記の低品質なコードでは理解に39.5%の時間を浪費している、との記載があるように
そもそも課題を理解し、コードを理解することにボトルネックがあるのかと思いました。
また、予測性が低い（課題解決が長引けば長引くほど）とストレスがたまっていきチームの生産性も下がってくるのかなぁと思ったりします。
多分スクラム開発をしてプランニングポーカーをしても予測不可能であって、課題に取り組めば取り組むほどスクラムゾンビになっていくのでは・・・と思いました。
※ 論拠・計算式については論文をご覧ください。
この記事が気に入ったらサポートをしてみませんか？