コードジンのヘッダーが入ります
自分1人で考えたものを自らコーディングしたとしても、当初の構想とはズレが生じてしまうことは珍しくない。当然、大勢の開発者がコーディングを行う複雑なシステム開発では、最初に設計したアーキテクチャどおりに完成させることがさらに難しくなる。また、仮に思い通りのシステムが完成したとしても、テストや運用フェーズでユーザからさまざまな変更依頼が入り、アーキテクチャが崩れてしまうことも多い。そこで必要となるのが、ソフトウェアアーキテクチャ管理である。
ビズモ 代表取締役兼CEOの鈴木高弘氏は、ソフトウェアアーキテクチャ管理の基本として、「アーキテクチャ管理の対象はソースコードそのものであり、アーキテクチャの管理とはソースコードの品質を評価し、実装や設計上におけるアーキテクチャの改善を施すことです」と説明。そのために必要とされるテクニックとして、「リファクタリング」などのプラクティスの実践と「メトリクス」などの客観的な評価手段を挙げた。
リファクタリングによって大きなクラスを2つに分割して影響度を抑えたり、レイヤやパッケージの相互参照を解消することで、保守性や再利用性を高めることができる。そして、リファクタリングを必要とするコードの「不吉な匂い」は、クラスの凝集度を表すLCOM(Lack of Cohesion of Methods)などのメトリクスを計測することによって捕捉可能だ。
メトリクスを利用してソフトウェアアーキテクチャを可視化し、システムの現状を開発チームで共有することで、アーキテクチャの改善もスムーズに行えるようになる。では、具体的にはどのような方法でソフトウェアアーキテクチャを可視化すればよいのだろうか? モジュール間の依存関係をUMLの静的なクラス図で表現する手法もあるが、大規模なシステムの場合にはいくつもの矢印が行き交う煩雑な図になってしまうため、とても全体を把握することができないだろう。
そこで鈴木氏が推奨するのが、「DSM(Dependency Structure Matrix)」を用いたアーキテクチャの可視化である。DSMとは、製造業で長く利用されてきた工程管理技法だ。そのDSMの手法をソフトウェアに応用したツール「Lattix」では、モジュール間の依存関係をマトリックス(表形式)に置き換えて表現する。モジュールが適切な階層構造なら、依存関係があることを示す数字が「下位の三角形」で並び、不適切な構造であれば対角線の右上にも数字が表示されることになる(通常、DSMでは依存関係をマトリックス中に「×」で表すが、Lattixでは依存関係の強さの要素も加えて「数字」で表示する)。
人間が絵画的に判定を行わなければならないクラス図とは異なり、Lattixを利用すれば複雑で大規模なシステムでも、DSMのマトリックスで容易に依存関係を理解できる。これにより、変更の影響範囲を把握したり、依存関係の偏りや矛盾が明らかになり、より品質の高い構造に改善することが可能となる。また、Lattixではアーキテクチャの設計ルールを設定することも可能だ。設計ルールに違反する依存関係には自動的にフラグが立つので、改善すべき箇所が明確に分かるようになる。
こうしたLattixの代表的な機能をデモで紹介した後、鈴木氏は「ソフトウェアの品質が上がれば、結果的には生産性も向上するし、お客様にも喜んでいただける。そのためにも、ソフトウェアアーキテクチャを管理し、継続的に改善していくことが重要なのです」と、最後に改めてソフトウェアアーキテクチャ管理の重要性を強調した。