納期間際になって不具合が見つかった状況を考えてみます。選択肢は2つあります。一つは設計から見直し、コードを変更してテストも行うことですが、納期に間に合わないかもしれません。
もう一つはとりあえず不具合を解消するよう深く考えずにソースコードを変更することです。納期に間に合ってプログラムも正常に動いている模様ですが、その後の変更時に影響範囲が大きかったりソースコードの意味が分からなかったりして、不具合の修正や機能追加が大変になる、あるいはコードをいじれない、という事態が待ち受けています。
あなたのプロジェクトは2つ目のような事態に陥ってはいませんか?
2つ目の選択肢のような「とりあえず動くが、後から変更が大変なコード」は「技術的負債」と呼ばれています。技術的負債は単にソースコードが汚くて読みにくいコードだけでなく、次のようなコードも当てはまります。
- テストケースが作られていないコード
- 設計を推敲せずに書かれたコード
- 別のところからコード断片をコピー&ペーストしたコード
- 変更に時間がかかる
- テスト工数が膨らむ
- リリースが遅れる
- リリース後も障害が起きる
では技術的負債の量はどのように求めたら良いでしょうか? 技術的負債の構成要素としては、コーディング規約違反の件数、メトリクスの超過/過少の量、単体テストの失敗件数、テストで未到達なコードの量、等が考えられます。一例として、SQALEメソッドにおいて技術的負債の計算方法が例示されていますので、参考になると思います。
技術的負債を定義したら、次は技術的負債の構成要素を計測します。計測方法は要素によって異なりますが、コードレビュー時に確認したり、単体テストを実行したり、静的解析や構造解析のツールを利用することが一般的です。弊社取扱製品であるParasoft JtestやParasoft dotTEST, Parasoft C++testといったテストツールももちろん利用できます。
最後に、各要素から技術的負債を計算してプロジェクトメンバーに提示します。先程例として挙げたSQALEメソッドに従うと、技術的負債は単純な四則演算で計算できますので、表計算ソフトでも計算できます。あるいは弊社取扱製品であるParasoft Development Testing Platform (Parasoft DTP) を使用すると、技術的負債を計算する手段が予め提供されている他、技術的負債がモジュールや品質特性ごとに計算され、かつWebブラウザで確認できます。WebブラウザでParasoft DTPにアクセスすれば、下図のようにどこにどれくらいの技術的負債が溜まっているかをいつでも誰でも確認できるため、技術的負債を減らすためにリファクタリングを開始する動機付けが可能になります。
また、継続的インテグレーションの中に技術的負債の計測を組込むことで、現在のプロジェクトの技術的負債の状況をリアルタイムに近い形で確認することが可能になります。技術的負債が増加していることをリアルタイムに把握できれば、リーダーの方がリファクタリングを開始するよう指示して早期にプロジェクトを軌道修正することも容易に可能になります。
いかがでしたでしょうか。技術的負債とは何か、技術的負債が溜まるとどうなるか、技術的負債を算出して可視化する方法をご説明いたしました。読者の方が技術的負債を返済し、将来の変更の労力を少しでも減らすことができればと思います。
最後に、上記で紹介しました弊社取扱製品はすべて2週間無償でご評価いただけますので、購入を検討されたい方は下記からぜひお試しください。またParasoft DTPのユーザー様向けに、技術的負債を計算するためのプラグインも提供しておりますので、ぜひご利用ください。
Parasoft DTPプラグイン提供ページ