初めてのソフトウェアメトリクス（後編）
ソフトウェアメトリクスを現場に組み込む

テクノロジックアート
長瀬嘉秀｜矢野大介
2006/1/14

　前編（ソフトウェアの品質を数値化して確かめる）、中編（凝集度と結合度：このコードのどこが悪いのか？）を通じて、ソフトウェア・メトリクスの概要を解説しながら、ツールを利用したメトリクス測定による問題点の抽出方法を提示しました。今回は、実際の開発現場で設計改善するときの問題点や、メトリクス測定を利用した改善方法を説明します。

1. 開発現場の現状

　一般的に、開発が進み、機能が増えていくに従って、図1のような複数のクライアントコードからロジックコードが呼び出されるような構造になっていきます。図1で明らかなように、依存性がとても複雑になるため、徐々に拡張性や可読性、保守性が悪化していきます。また、単純に重複したコードを共通化・共有していくと、さらに複雑さが増していきます。

図1 開発が進むにつれ、構造が複雑化する

　クラス設計やクラス間の依存性をUMLなどで視覚化している場合は、これらの複雑性にすぐ気が付くでしょう。しかし、コードと設計図が同期していない場合は、このような状況をすぐには察知できないものです。こうなると、結合度と凝集度といったメトリクスの数値も悪化します。状況を素早く把握するためには、メトリクスを継続的に測定する必要があります。

　なお、このような状態を改善するため、デザインパターンとして有名なファサード（Facade）を導入するとクラス間の依存性が整理されます。そうすることで、クライアントは、煩雑になってしまっているロジック側を意識する必要がなくなります。この方法で大幅に設計を改善できます。もちろん、メトリクスの結果も改善されます。

図2 ファサードを導入する

　ファサードを導入することで一時的には設計が改善されますが、実際の開発現場ではもっと複雑です。機能がさらに増えてゆくに従って、導入したファサードそのものが膨れ上がっていき、ついにはすべての機能がファサードに集まってしまうといった状態になりがちです。この場合の拡張性や保守性がとても悪くなります。このような膨れ上がったファサードを改善するには、丁寧に分割していく必要があります。

2. リファクタリング時に利用するメトリクス

　膨れ上がったファサードクラスを分割するのは面倒なので、ついつい修正を行わなくなってしまいます。しかし、今後の拡張性や保守性を考慮すれば、分割すべきことは明らかです。リファクタリングとは、悪いコードの“匂（にお）い”を嗅ぎ分けて改善することです。しかし、メトリクスを使って測定し、定量化すると、“におい”ではなく数値化によって明確にコードの改善が示されます。逆にメトリクスの数値が改善されない場合は、分割がうまくいっていないことが判断できます。

　凝集度の数値の改善を意識するとスムーズにコードが修正できます。測定の結果は意図的に改善され、分割方法に迷いがなくなります。ユースケースや、設計段階に出てきた機能一覧で分割すると、分割する粒度の調整が難しく、あまりうまくいきません。

　開発現場で起こり得るリファクタリングの一場面を例に挙げましたが、リファクタリングが必要な不吉な“匂い”は、経験上の直感に左右されてしまう部分が大きいものです。しかし、メトリクスで計測すると、素早く正確に“におい”のもとを発見できます。

3. 開発プロセスへの組み込み

　今日のシステム開発は、従来からのメインフレームや単純なクライアント／サーバ型のシステム開発と違い、システム構成や利用技術が複雑になってきています。また、顧客のビジネス変化に対応するため、短納期でシステムをリリースすることも増えています。

　従来のウォーターフォール型開発では、すでに上記の問題は解決されません。さらに、メトリクスを組み込むとなると、単体／結合テストのフェーズになります。このフェーズに組み込んで問題が発生すると、すべてのコードを修正することになってしまい、開発のスケジュールが大幅に遅延してしまいます。テスト期間でさえも納期に間に合わすために縮めている現実を見ると、ウォーターフォール型開発に組み込んでも意味があるかどうか分かりません。

　これに対して、オブジェクト指向開発で採用されている繰り返し型開発はどうでしょうか。繰り返し型には、保守的なUnified Process（統一プロセス）からアジャイル、XPなどの先進的な手法があります。

　繰り返し型では、開発のスコープを分割していくので、実際に動くシステムを顧客に早く見せることができます。これにより、顧客の意見を早めに聞くことができます。ただ、全体を見通した設計が難しくなる側面もあります。アジャイル方法論では、リファクタリングを工程に組み込んでいますが、前に説明したように“におい”の嗅ぎ分けなど直感的な経験に頼ることが多くなります。直感的な方法だけではなく、さらに工学的なメトリクスをリファクタリングフェーズに導入するとより品質の良いシステムが開発できます。実際、コードの量が増えてくると人手だけによるリファクタリングには限界があります。ツールによるコードの改善を導入することで、より確実に高品質なシステムを開発することができます。繰り返し型開発では、結合テストやリファクタリングにメトリクス測定を組み込むと効果を発揮します。

◆

　以上、3回にわたってソフトウェア・メトリクスの解説をしてきました。従来の非オブジェクト指向言語については、確立されたメトリクスの使用方法があります。しかし、オブジェクト指向の環境では、あまり注目されてきませんでした。しかし、オフショア開発などの分散開発になってくると品質の確保は重要です。

　品質の測定結果がグラフなどのビジュアルに提供されると、コードの良しあしが一目瞭然で分かります。そして、この品質確保の技術を開発プロセスに正しく組み込むことで、的確なシステム開発が可能になります。組み込み方法を間違えると、品質確保どころではなくなり開発の失敗につながってしまいます。

　今回の連載は、ソフトウェア・メトリクスの「さわり」の部分に触れただけでしたが、この連載を契機にして、より実践的なメトリクスの活用方法を探していただければと思っています。実践的なメトリクス利用について、また近いうちに、ご紹介できれば幸いです。より良い品質のシステムリリースをするヒントになればと願っています。

IT Architect 連載記事一覧