アーキテクチャ設計はしたいけど、今のソースコードがある、という方も多いと思います。動いているソースコードを捨てて、新たにアーキテクチャ設計する、という機会はなかなかありません。そして、新しくアーキテクチャ設計しても、それできちんと動くかどうかは、動かしてみないと分からないというリスクも抱えてしまいます。今のソースコードは、動いている限りはソフトウェア資産といえます。

しかし、ソースコードがスパゲティ化していて全体が見えない、ソースコードを追いかけないと動きが分からない、などの課題があるソースコードも見受けられます。その様なソースコードは、少し修正するために、多大な設計工数及びテスト工数を必要とします。私たちは、そのようなソフトウェアを「資産」ではなく、「在庫」と呼んでいます。在庫を抱えていると、無駄な費用が発生していると言えます、まさしくロスコストです。 資産価値の簡易判定はこちらで実施できます。
http://www.bslash.co.jp/support/check.html 

そして、在庫のまま、局所的な追加修正を重ねていくと、在庫化に拍車がかかってしまいます。日々、一生懸命にコードを修正しているのに、なぜか仕事が楽にならず、逆に、複雑に入り組んだコードを作ってしまっていることになります。悪循環サイクルです。

私たちは、ソースコードをリバース設計して、構造的に表現することをお勧めします。構造的に見ることで、設計の意図が浮き出てくることがあります。それをアーキテクチャ設計と徐々にすり合わせていくことで、「在庫」を「資産」に変えていくことができます。その際に、アーキテクチャ設計の通りにソースコードを作り込む、というトップダウンアプローチが先行するのではなく、既存コードの設計意図をアーキテクチャ設計として定義する、というボトムアップアプローチを先行させた方が、より実践的で、成功する方法です。

ステップ１：ソースコードをリバース設計して構造的に表現する
ステップ２：ソースコードの設計意図を発掘する
ステップ３：設計意図をアーキテクチャ設計として定義する
ステップ４：アーキテクチャ設計の全体を統合する

一からアーキテクチャ設計をして、それに合わせてソースコードを作る、というやり直しのアプローチは、初期投資費用がかさむだけでなく、それが本当に動くのかというリスクも抱えることになります。

それよりも、今動いているソースコードから設計意図を発掘し、それをアーキテクチャとして定義していけば、現行のプロジェクトを推進しながら、アーキテクチャ設計の整備もできます。次のプロジェクトへ向けて資産価値が向上していく、という好サイクルが回ります。