技術的負債とソフトウェアの品質

TODO：ストーリーがまだ練り切れてない状態ですので、折を見て修正します

技術的負債は、システムの品質が劣化する原因だと考えることができます。

技術的負債というと、ソースコードの保守性についてフォーカスが当たりがちですが、パフォーマンス劣化など、影響はさまざまかと思うので広くとらえることとします。

この記事ではちょっと乱暴かもしれませんが、「ソフトウェアの品質が劣化している」＝「技術的負債が蓄積している」＝「欠陥がある」とみなします。

そもそも品質とは

一口に品質といっても多岐にわたるので、議論するときはどの品質を指しているのかを気を付ける必要があります。

例えばISO/IEC 9126 というソフトウェア品質特性のモデルがあります。（漢字多いんで読まなくていいです。）

とりあえず、このモデルではソフトウェアの品質は、機能性、信頼性、使用性、効率性、保守性、移植性に分けていて、さらにこれを細分化しています。

狩野モデルは、『顧客が製品やサービスに対して要求する品質について、「当たり前品質」「一元的品質」「魅力的品質」「無関心品質」「逆品質」の品質要素に分類する』ものです。

やみくもにサービスの品質にコストをかけても、顧客満足度が上がる（≒お金になる）かどうかは別問題ということです。

たとえば、軽微なバグは直さないという判断は、サービスの品質に影響を及ぼすかどうかによって判断するべきで、その結果として直さないという判断は大いにありえます。

もちろん、サービスの品質という観点でいえばすぐ直すべきという場合もあるかもしれません。（ボタンが押しにくい、など）

システムの品質を議論するうえで、以下の２つの工学手法があります。

それぞれ、織り込む品質の種類によって分けられます。

信頼性（システムが安定して稼働するための条件）の問題については、安価に発見するためには設計レビュー・コードレビューが適切です。

もちろん、ソフトウェアテストでも可能ですが、信頼性に関するテストは環境を準備したり、時間を要したりします。そのため、特にアジャイル開発の文脈ではレビューで欠陥の発見を目指すのがコスト的に適当かと思われます。

作業プロセスにおけるミスは、コードレビューでも発見しますが、チェックリスト化したり、静的解析ツールによる自動チェックする仕組みを考えるべきです。

なお、不吉なにおいについての指摘は、(たぶん）作業効率の向上やミスの予防のための指摘にあたりますが、自動チェックする仕組みだけでは簡単には検知できない場合があります。

例えば重複コードの検知を行うツールは存在しますが、それが１つのメソッドなどに集約可能であるかは人手で判断する必要があります。