【69】今の近道、後で大損

　アーキテクチャーを設計するときには、最初の開発段階よりもメンテナンスに入ってからの方が多くのリソースを消費するということを忘れてはなりません。プロジェクトの初期開発段階で近道を選んでしまうと、後でメンテナンスにばかばかしいコストがかかることがあります。

　たとえば、単体テストでは直接的な価値が得られないからと、デベロッパーたちに単体テストの適用を省略してよいと言ったとします。このようにして作られたシステムは、後で変更するのがとても難しくなりますし、変更を加えたときにそれでよかったのかどうか確信が持てません。わずかな変更のために手作業によるテストが必要になるため、システムがもろくなって、メンテナンスにコストがかかります。設計自体としても、完全にテストできる設計（テストファースト設計はもちろん）と比べてよいものにはなりません。

　既存のシステムの活用はコスト軽減につながるからといって、適合しない目的のために既存システムをむりやり使うのは、アーキテクチャー上の誤りとしても特に深刻です。たとえば、アーキテクチャーのコンポーネントとして BPEL とデータベーストリガーを使って非同期メッセージングシステムを実現しようとしていたとします。便利だからとか、あなたやクライアントが知っているアーキテクチャーだからというので、そういう案になったのかもしれませんが、要件によってメッセージングがコンポーネントとして必要だということがはっきりしたら、ただちにメッセージングアーキテクチャーを選択すべきだったのです。プロジェクトの最初の段階で、誤った判断をすると、新しい要件に合わせてシステムのアーキテクチャーを作り直すときのコストが大幅に増えてしまいます。

　初期開発段階で近道を避けるだけでなく、設計のまずい部分を見つけたときにはできる限り早く修正するのも大切なことです。設計のまずい部分が将来の機能の基礎になる場合もあります。そのような場合、後で正しい動作をするように修正しようとすると、余分なコストがかかります。

　たとえば、基礎的な機能のために不適切なライブラリが選択されていることに気付いた場合、そのライブラリはできる限り早く置き換えなければなりません。そうしないと、要件の発展とともに、以前のレイヤーのまずい部分を隠すために、後で余分な抽象化レイヤーを追加しなければならなくなる場合があります。これではもつれあった糸と粘着テープでボールを作っているようなもので、レイヤーを追加するたびに、もつれあったものをほどくのが難しくなっていきます。これでは、システムが変更しにくくなってしまいます。

　あなたはアーキテクトとして、アーキテクチャー上の問題点やデザインの欠点を見つけたときには、コストのかからない今の段階で修正することを主張すべきです。放置したままの状態が長引けば長引くほど、そのために支払わなければならない利子は増えます。