前回までの7回で、全体を俯瞰して、かつ、際どいところを押さえるアーキテクチャの構築と、それを使ってリーダーシップを発揮するアーキテクトの役割について書いてきました。しかし、実際のソースコードが、ぐちゃぐちゃになっていては、いくらアーキテクトが頑張っても、開発の現場は楽になりません。動いているソースコードは、資産のはずなのですが、時間が経過すると、徐々につぎはぎだらけになってしまいます。この現象を、金属疲労になぞらえて、ソフトウェア疲労、と呼んでいます。「資産」だったはずのソースコードが、少し直すだけでも、保守コストがかさみ、品質も低下していく、という「在庫」となってしまいます。

ソフトウェア疲労の原因を分類すると、

（1） そもそも設計していない
（2） 設計技法の適用ミス
（3） 静的構造の曖昧さ
（4） アドホックな制御構造
（5） 設計思想の欠如

が挙げられます。

アーキテクトの活動と現場の開発チームとの連携があれば、開発が好循環になります。アーキテクト活動がうまくいけば、ソフトウェア疲労を起こさずに、ソフトウェアを「資産」のまま使い続けることができます。これからの7回で、ソフトウェア疲労の症状と対処法を掲載していきます。