ソフトウェアエンジニアでない人にはピンとこないかもしれないが、ソフトウェアのアーキテクチャ（構造）を改善するということには意味がある。
家が完成してしまうと外面からはどのようなアーキテクチャ（構造）でその家ができているのかがよく分からなくなってしまうのは実際の建築物もソフトウェアシステムも同じだ。でも、そのアーキテクチャの善し悪しが災害に対する強度だったり、住みやすさに大いに影響する。テレビ朝日の『大改造!!劇的ビフォーアフター』で、古い家屋を骨組みだけにする過程で、基礎がいい加減だったり、支えとなる柱が途中で切られていたりするケースをたまに見かけるが、これらの手抜き工事は外からでは見られないから恐ろしい。
ソフトウェアの場合、アーキテクチャが悪いと、非常にわかりにくいバグを生んだり、ソフトウェアの再利用によく多くの時間と工数がかかる。こちらも、それらの問題がソフトウェアのことに詳しくない人には見えない、理解できないからやっかいだ。
ソフトウェアアーキテクチャの改善（＝ソフトウェアプロダクトラインの導入）は組織のトップからおろしていくのであれば、品質面のメリットよりも、コストメリットや開発期間の短縮のメリットが強調されると思う。ただし、改善の実現には一時的にソフトウェア資産の再構築が必要になるため、成果が現れるまでには2～3回製品を開発するサイクル（1年以上）を回す必要がある。その投資期間をじっと我慢することができれば、その後から劇的な効果が現れる。
日本の組織ではそのようないったん我慢をして後々の利益を取るという判断ができる企業は少ないので、なかなかソフトウェアアーキテクチャの改善に踏み出せない。
そこで考えるのは、プロジェクトやエンジニアにアーキテクチャ改善の重要性を諭して取り組んでもらうというアプローチだ。しかし、それもなかなかうまくいかないケースがあることに気がついてきた。
既存のソフトウェアシステムのアーキテクチャを可視化して問題点を共有しても、思ったより改善に対する気持ちがイマイチ盛り上がらない場合がある。それはそもそも既存のソフトウェアシステムのアーキテクチャ設計を外部の協力会社の技術者に任せているケースだ。建築業界においてハウスメーカーが自社の商品の構造設計を外注することはないと思うが、ソフトウェアの世界ではソフトウェアシステムのアーキテクチャ設計を外部の技術者にゆだねることはよくある。悪い言葉で言えば丸投げだ。
アーキテクトがプロジェクトのメインメンバーの外にいる場合、アーキテクチャの改善は非常にやりにくい。なぜなら、アーキテクチャに問題があることに対してアーキテクトはすぐに理解できるが、プロジェクトのステークホルダには十分に理解できないからだ。協力会社のアーキテクトはアーキテクチャの改善をプロジェクトに進言するということは、これまで納品してきた自分たちのソフトウェアに問題があったことを告げることににもなる。アーキテクチャの改善とはこれまでのソフトウェアシステムの中にある問題点を自ら認め、未来のために一時的な苦労を強いることである。そのためには協力会社のエンジニアを含めたプロジェクト全体で現在のアーキテクチャの問題点について認め合い、目標となるゴールについての認識を一つにしなければいけない。
エンジニア個人としては、アーキテクチャが改善したことでどれくらい自分自身が成長し、仕事が楽になるのか感覚的に分かっていないと改善への第一歩を踏み出せない。
鶏と卵のような関係で、アーキテクチャの改善に必要なトレーニングを与えるのが先か、それともアーキテクチャの改善によるメリットを実感させることが先かは微妙なところだ。前者はメリットが実感できないと学習効果が上がらないし、後者はスキルがないとメリットを実感できないからだ。
日本でソフトウェアアーキテクチャ改善の話題がいまいち盛り上がらないのは、ソフトウェアアーキテクトの存在が組織内で認識されておらず、その職務が不明確で地位が確立していないからではないかと思う。建築業界では建築士という資格によってその地位が認められているが、ソフトウェアの世界では、そのような資格は存在しない。（資格があればいいってもんじゃないが）
ソフトウェアアーキテクチャを改善し、ソフトウェアコンポーネント間の関係がすっきりすると、開発は非常に楽になる。簡単に言えばソフトウェア資産に一切手を入れずにコンポーネントを再利用できるようになるから、資産の再利用のコストは限りなくゼロに近くなる。
かつて作ったソフトウェアの“流用”すると言っておきながら、新規にソフトウェアを開発するのと同じくらいの費用や期間がかかっていることに疑問を持つプロジェクトやクライアントの会社が少ないことに驚きを隠しきれない。ソフトウェアの再利用に成功したことが一度もないから、ソフトウェアはよく分からないが金がかかるものだと思っているのだ。
また、ソフトハウスの経営者としても再利用資産が増えることで工数が削減されることは利益の減少につながるから積極的にアーキテクチャ改善には動かない。しかし、それは発想を変えるべきで、ソフトウェアのアーキテクチャを改善し、再利用性が高まったら、その資産を利用して新たな派生製品を作り、そのアプリケーション開発のための仕事を受注すればよいのだ。前者の考え方は長期的な視点に立てば、コストダウンで開発費を縮小され、少人数で仕事量が増えるから悪循環に陥り、後者は資産の再利用により開発効率が高まるので長い目で見れば好循環につながる。
新しい技術を学びながら、自分のスキルと市場価値が向上し、開発効率が上がって、よりクリエイティブな仕事ができるようになるのに、なぜアーキテクチャの改善に積極的に踏む出そうとするソフトウェアエンジニアが少ないのか自分には理解できない。
その答えの一つは、自分や自分のプロジェクトが作成したソフトウェア再利用資産が他のプロジェクトや他の商品に利用されても、再利用できたことのメリットが表面にでてこないという現実がある。
どんなに自分自身が成長しても、その成果を自分の中だけにとどめておいたのでは自己満足に終わってしまう。組織に認められてこそ、組織貢献を果たすことができ、顧客への貢献につながる。
そんなこんなの問題が山積していることから、ソフトウェアアーキテクチャの改善は難しいのだ。
最後にソフトウェアエンジニアに言いたいのは、これからも続く長いソフトウェアエンジニアのキャリアパスを考えたときに、10年後、20年後に振り返ったら日々忙しくしていた自分しか見えないというのはあまりにも悲しくないかということだ。自分が組織に残したソフトウェア資産やアーキテクチャは「これだ」と言えるようになりたくないのか。一回やってみるとそのありがたみが分かるはずなのに、日々の忙しさを言い訳にして最初の一歩を踏み出せない技術者が多すぎる。
