リスクと品質的負債:知らないでいると痛い目にあうことも

(この記事は、開発元Parasoft社 Blog 「Risk and Quality Debt: What You Don’t Know Can Hurt You」2017年12月8日の翻訳記事です。)

コードのリスクは、たった 1 つの魔法の数字や信号機の様な単純な「進め/止まれ」で評価することはできません。リスクは多次元であり、多変量であり、組織が異なればその評価も異なります。

コードのどの部分の「リスクが高い」あるいは「ダメ」かは、あなたはすでに理解しているはずです。――それは、常に変更されている部分です。小さな問題を修正するために、あちらこちらといじられているようなコードです。修正の原因となった個々の問題は、特に重大では無いのですが、貧弱な設計の上に機能を積み重ねていることになります。これが、既存のコードに変更を加えることにより欠陥が混入する大きな理由です。

しかし、変更は常に必要であるのも確かです。最初からすべてを完全に、あるいは正しく実装するのは不可能です。既存のコードに変更を重ねるごとに、ユースケースやシナリオの知識が失われ、複雑さが増し、コードはますます危険にさらされます。リスク対処の手がかりの鍵は、これらの変更にあります。

リスクの可視化と同じくらい重要なのは、リスクへの対処方法を理解することです。つまり、チームの作業速度への影響を最小限に抑えながら「許容可能なリスク レベル」を達成するために、どのような改善措置を行うべきか、その優先順位を決定する方法を理解することが重要です。この記事では、まさにその、コード変更のリスクを評価する方法と、リスクを効率的に優先順位付けし、軽減する方法について説明します。

多変量リスクの評価方法

リスクは単一の数値でもプロジェクトレベルの「交通信号」でも表せません(Parasoft DTP のUIでは、分かりやすいよう交通標識の色を使用してはいますが)。リスクはコードの分類であり、現に存在する問題や潜在的な問題のありかを示すガイドです。次の図を見てください:

Risk and Quality Debt What You Dont Know Can Hurt You Blog_Figure 1.png

これは ParasoftのProcess Intelligence Engineの円グラフの例であり、高リスク、中リスク、低リスクのコードの割合を示しています。

リスクの分類は多次元であり、多変量です―リスクを完全に理解するためには、静的解析、メトリクス、コードカバレッジ、テストなどの解析技術から得られた品質メトリクスを総合して分析する必要があります。これらの解析技術では、意味のある値を提示するというよりは、公式にあてはめた値を提供します。たとえば、コードカバレッジは、単体ではあまり使い道のない数字です。なぜなら、100%のカバレッジを達成しているが、意味のあるテストを実行しているのはごく少数のテストケースでしかないということがありうるからです。何を得るためにコードカバレッジを使用するのかを考える必要があります( たとえば、「コードがどの程度テストされているか」を知るためなど)。また、より意味のある分析結果を得るためには、より多くのデータを追加する必要があります。

Risk and Quality Debt What You Dont Know Can Hurt You Blog_Figure 2.png

上の図はリスクの高いコード変更のバブルチャートの例であり、最も高いリスクが存在する場所を示しています。(バブルを拡大して、分類の元になっているメトリクスを確認することもできます)。

上のバブルチャートは、2つの次元に基づくリスクの分類を示しています(下の図にも示されています)。

  • Maintenance Burden  Halstead Volume、Strict Cyclomatic Complexity、コード行数、およびコメントとコードの比率の組み合わせを利用して、コードの保守性と理解しやすさを定量化します。
  • Test Deficit  テストの数、メソッドの数、コードカバレッジを利用して、コードがどの程度テストされているかを定量化します。

十分にテストされていない(つまり Test Deficit が高い)コードは高リスク(赤)に分類され、十分にテストされ、適切に構築されて(Maintenance Burden が低い)いれば、コードは低リスク(緑)に分類されます。

流動的なコードではあらゆる変更がリスクとなる

開発期間中のコードベースは常に流動的な状態にあり、あらゆるコードの変更が未知のリスクを含んでいます。基本的な機能を壊していないか?セキュリティ上の欠陥を混入させていないか?情報が少ないほどリスクが大きくなります。以前の記事では、変更がテストに及ぼす影響と、テストリソースを集中させるべき箇所を予測するために、コードカバレッジをうまく利用する必要があるということを説明しました。しかし、カバレッジとテストを増やしたとしても、依然として時間の経過とともに蓄積するリスクは存在します。

コードの変更は、3つ目の、最も重要なリスクの次元をもたらします―それは時間です。従来の意味での時間ではなく、ビルド間の変更に関連する時間です。ビルドとビルドの間に変更されたコードに範囲を絞ると、チームが現在作業している部分に焦点があたり、最もリスクが高く、最も関連性の高いコードの処理に集中することができます。

品質的負債に足を引っ張られていませんか?

再利用されたコードやレガシーコードは、特にセキュリティの観点において、それ自体がすでに負債になっています。品質基準を維持または改善するために十分なチェックが行われていない場合、コードが 1 行追加または変更されるたびに負債は増えます。この債務から抜け出すためには、他のあらゆる種類の債務と同様に、削減に対して集中と深い関与が必要です。また、これもあらゆる負債に言えることですが、お金がどのように費やされているか分からない限り、節約の方法も分かるはずはありません。

最もリスクが高く、最優先で対処する必要があるコードを特定したら、リスクを軽減するために必要な作業量も考慮しなければなりません。これが最後の 4 つ目の次元、つまり品質的負債です。上のバブルチャートでは、品質的負債はバブルの大きさで表されています。バブルが大きいほど、解決するべき既知の問題がより多く存在します。この例では、品質的負債は、重大度の高い静的解析違反(コードメトリクスのしきい値違反を含む)とテストの失敗の組み合わせをコードの論理行数で正規化したものです(図3参照)。

Risk and Quality Debt What You Dont Know Can Hurt You Blog_Figure 3.png

このように未対応の品質タスクを集約することで、コードのリスクを軽減するために必要な作業量の相対的な目安が得られます。

リスク評価の方法が異なる場合

すべての組織が同じ品質プラクティスを実践しているとは限らず、リスクの次元を計算する際にどの因子を考慮に入れるかは組織毎に異なります。それぞれ独自のリスク定義を設定する必要があります。

このブログのサンプルは、Parasoft マーケットプレースから入手し、特定のニーズに合わせて拡張することができます。このサンプルを土台として、組織に合わせて静的分析、メトリックのしきい値、およびリスクの分類をカスタマイズできます。

結論

予算、スケジュール、品質目標と十分なセキュリティ対策のバランスを取りながら顧客の要求を満たすことは、リスクを伴う困難な仕事です。しかし、品質プラクティスとプロセスインテリジェンスの自動化で、リソースを集中的に投入するべき場所を知ることができます。リスクがどこにあるのか、そしてコードの変更がベースラインの品質とセキュリティにどのように影響するのかを理解することで、開発の方程式から多くの未知数が取り除かれます。適切な場所にリソースを集中させることで、品質およびセキュリティ上の債務を克服できます。

Top