体系的廃棄

過去に書いたブログからの再掲です。原著は2007/2/18です。
（注記）　文中の「フレームワーク」とは、掲載当時、筆者が社内で配布していたJavaEEのフレームワークのことを示しています。

====================================

以前から重要だと感じていることの一つに「体系的廃棄」という考え方があります。

意味は、文字通り、システムや（その一部である）ソフトウェアを「ある計画に基づいて廃棄する」ということで、「当初から廃棄を意識した開発を行う」と言ってもいいかもしれません。

カスタムプログラムを載せたシステムでも、パッケージをカスタマイズしたシステム（「システム」という言葉には、HW、MWを含みます）でも、長い期間をかけた過度のRefineによってモンスター化してしまうものが大変多いのではないかと思います。

こういったシステムというのは、システムのライフサイクルのある時期から大変お金（人手）のかかるものになっていくと同時に、（時代遅れの代物となって）魅力の乏しいものとなっていきます。
しかしながら、こうなってしまったシステムを再構築するとなると、当然既存の人手では間に合わないものになってしまい、再構築によるメリットがそれなりのものであっても、それに見合わないほどの投資が必要になってしまいます。

以前のログで、『フレームワークは完成しない』と述べたことがありますが、実際には『完成しない』どころか、毎年のようにアーキテクチャから見直しをかけています。

これは、Webアプリケーションの時代変化が（あいもかわらず）激しいためで、アプリケーションの根幹に触れるような、イノベーションが毎年現れるからです。

ですので、開発された業務アプリケーションは、ある一定の期間（３年とか５年とか）の寿命を持ちますが、フレームワークについては、毎年、根本から見直さざるをえません。

取引先の開発者から『フレームワークといっても何一つ、同じバージョンで作ったものがない』というようなことを言われたことがあります。

この言葉の裏側には、当然のことながら、「開発を容易にするはずのフレームワークを変更されてしまうと、フレームワークそのものとしてのメリットがでなくなる」という反論が含まれています。

これは、ある程度本当の話で、毎年メジャーバージョンアップをするフレームワークの寿命が１年ですから、１年毎に業務アプリケーションのベースが異なったものとなっています。

それに合わせる開発者にも、大変な労苦が必要となります。

これは、ある意味で（無理やり）『体系的廃棄』をしている。否、『時代にさせられている』ということが言うことができます。

フレームワークも、その時々のイノベーションの中から「よさそうなもの」を選んでいますので、それをベースとする業務アプリケーションも（新しいフレームワークを使うものほど）、『シンプル』なものになっていきます。

フレームワークの見直しという作業は、テクニカルな実証検証を含みますし、デザインパターンの多用といった（ある程度）高度なコーディング作業を必要としますので、多大な労力な必要なわけですが、非常に重要なことであると思っています。

なぜなら、思い切ったアーキテクチャの見直しをかけないでフレームワークのバージョンを上げたとしたら、フレームワークは複雑で巨大なものになる一方です。
（人間、１回作ったものをRefineするのは楽しいですからね）

そして、最終的にはブラックボックス化、属人化して、廃棄したくてもできなくなります。

当然、ベースラインとなるフレームワークがモンスター化してしまうと、フレームワークと業務アプリケーションの結合が密になっていきますので、フレームワークに引きづられて業務アプリケーションも（開発当初から）モンスター化してしまいます。

これでは、システムが魅力に乏しいものとなった際に、手直しを入れるための投資が巨大なものとなってしまいます。

このような害が出ているシステム、ソフトウェアは私の周りにもたくさんありますし、一般的にも多いのではないかと思います。

毎年のように、表層部のアプリケーションを機能追加するのだけど、基本アーキテクチャは見直さない。

なので、ソフトウェアも（ちょっとした仕様違いでも）ブランチが増えるばかりで、開発者はいくらいても足りない。

そういう状況です。

フレームワークの見直し、アーキテクチャの廃棄を繰り返すことは大変な苦労を伴ないますが、必要なことであると思います。