読んでみた：低品質ソフトウェアの総コスト(CPSQ)

どうも、イケてるIT品質管理です。

ITソフトウェア品質コンソーシアム（CISQ : The Consortium for Information & Software Quality™）が、"The Cost of Poor Software Quality in the U.S.: A 2020 Report"というレポートを発表しました（住所・氏名・メルアドなどの登録が必要ですが、誰でも無料でDownloadできます）。

ソフトウェア品質の低下が米国経済に与える影響を定量化することを目的というレポート。ざっと読んでみたので、気になったポイントをPick upします。

総コストは2.08兆ドル

いきなり結論（笑）
2020年、アメリカにおける低品質ソフトウェアの総コストは2.08兆ドルと試算されたようです。何と比較すればよいか悩ましいですが、2020年のアメリカの国家予算が4.74兆ドルですから、低品質ソフトウェアのコストインパクトは相当大きいと言えます。

2.08兆ドルの内訳は以下の通りです（カッコ内は2018年調査時との対比）
① Operational software failures ：1.56兆ドル（+22%）*Cybersecurity含む
② Legacy systems：0.52兆ドル（-18%）　*①と一部重複あり
③ Unsuccessful IT projects：0.26兆ドル（+46%）

低品質をコストで表すことは、経営層にとってはインパクトがありますね。
算出方法や考察はレポートの3章「2020 FINDINGS FOR COST OF POOR SOFTWARE QUALITY」に書かれていますが、まぁ読まなくても良いかな。

唯一、3章で気になったのは"③Unsuccessful IT projects"に関する、
アジャイル+ DevOpsを非常に成熟した方法で使用したプロジェクトは約90%が成功したとの記載（調査対象全体で、予算・期間観点での成功率は35%）。アジャイルは予算・期間固定だと思うのですが・・・成功の定義が曖昧に見えました。

で、何ができるか？

4章「RECOMMENDATIONS」に、 “what can we do about it?”が前述①～③の切り口でまとめられています

① Operational software failures

・「シフトレフト」がより重要になっていく
・自動化ツール活用がこの領域の品質に良い影響を与えている。インスペクションなどの手法は不利になっていく
・ノンコード・ローコード開発が品質に与える影響には懐疑的

☞最後の1点はレポートまとめた人の主観が強そうだけど、残り2点は、まぁそうですよね。合意。Cybersecurity領域の内容も多いですが専門外なので読まず。

② Legacy systems

取りうる戦略は「カプセル化」「Rehost」「Replatform」「Repair」「リファクタリング」「Rearchitect」「再構築」「Saasへのリプレース」

☞多くの企業が直面している課題だけに、”何ができるか”に真新しさナシ。分かっちゃいるけど出来ないやつです。

③ Unsuccessful IT projects

・ニーズと要件の優先順位付け、スコープ変更の制御
・複雑さを最小限に抑える
・バグ修正とリファクタリングの計画
・厳格な品質のゲートを確立する
・早期かつ頻繁にテストする　等々

☞こちらも、まぁそうですよね、真新しさナシ。
唯一、” Probability of Project Cancellation by Size and Quality Level”という数字レポートは興味深かったです。

このレポートは有益か？

4章の内容に不安を覚えつつ、5章「CONCLUSIONS（結論）」へ。個人レベル、プロジェクト/チームレベル、組織レベルでまとめられています。

このうち、”プロジェクト/チームレベル”の内容が具体的でした。品質目標を定義しチームの責任とすることの重要性を強調し、品質目標の達成のためのシンプルなテクニックが紹介されています。

１．コーディングガイドラインに従う
２．要件、ユースケース、ユーザーシナリオ等がSMART(specific,
measurable, acceptable, realistic, and time-bound)であり、開発・テストの前に更新されること
３．問題と欠陥の指標を追跡する
４．レビューと修正を通じ、何が機能した/しなかったかを継続的に記憶
５．安価で修正できる問題には出来るだけ早く対峙する
６．開発ライフサイクルの早期に位置付けられたツールを使用（？）
７．恣意的、非現実的なスケジュールを回避する

☞No.2に登場する「SMART」は、要件定義の質を高める良い視点です。

ちょっと当たり前のことしか書いて無くないか？と思っていたら、5.4章に気になる言葉が登場しました。

DevQualOpsとは？

DevOpsやDevSecOpsは知っていましたが、DevQualOpsという言葉は初めて目にしました。この新しいモデルで、従来のDevOpsに追加されている機能が挙げられています。

・品質目標の設定、測定、傾向分析を行う
・伝統的なQA/Testingの役割はシフトレフトされ、より戦略的な位置づけに
・技術的負債を管理、軽減するための計画的なリファクタリング
・バグの発見、修正はすべて各イテレーション内に計画される
・重要なポイントに品質ゲートを設ける　等々

”「開始、定義、測定、管理」アプローチにより、組織は品質に対する「何でもあり」のアプローチから脱却し、DevQualOpsの成熟に向けスタートすることができる”
”品質を測定する機能は、品質への投資がビジネスとその顧客にどの程度の利益をもたらしているかを測定するための究極のテストだ”
と纏められています。

ざっと読んでみた感想としては・・・
・有益ではないとは言わないが、書いてあることの多くは当たり前のこと
・低品質をコストで示すアプローチと、「DevQualOps」という言葉は覚えておいて損はないかな
です。

CISQは「State of the Industry Report on Software Quality Analysis」というレポートも出しているので、また読んだらまとめてみようと思います。

ではまた！