コードを書く奴がコードを支配しよう

負の面だけを書いても解決しない。今回はプログラマとしてSIerのフレームワークに少しでも対抗する策を書いておこうと思う。

例えば、Strutsベースのフレームワークの場合であれば、URLに対するトランスミッションとアクション、それに付随するバリデーションとビジネスロジックの基本的な書き方が規定されていることが多いが、そのアクションのまとめ方や分散のさせかた、ビジネスロジック以外の非機能要件に関しては規定されていないことが多ので手を入れることができるはずだ。また、そのようなフレームワークはJ2EE全盛期の古い設計が多く、永続化にはEJB2.x以前が使われていることが多いので、ここをJPAやDAO等、他の永続化フレームワークに置き換えるよう勧めていくのも良いだろう。(もちろん、定性的、定量的にこちら側に有利な評価を明示する必要があるが)

問題はビューだ。典型的な例だと〜Builder、〜WeaverなどのHTMLオーサリングツールとJavaの連携機能を使ってHTMLからビューを自動生成するようなタイプや特定の開発環境のプラグインを使ってXMLやコードを自動生成しているケースだと入り込む隙は無いかもしれない。(後で修正することを考えると最悪の事例だろう)しかし、ビューにクラシックなJSPを使っているのであれば、スクリプトレット排除、EL式前提の最新のJSP2.xに変えたり、NetBeans等のIDEでJSFを使ってその生産性をアピールするのも良いだろう。

また、今回のケースのような豪華客船型フレームワークの場合は何が何でもWebアプリケーションで機能要件を実現できるかのごとく謳い文句やドキュメントには書かれているが、クライアントが必要とするエクスペリメントやユーザインタフェース、使用するO/SによってはWebアプリケーションではないものを提案するのも良いだろうと思う。(私はマスタメンテナンス等を切り出した上でこの部分リッチクライアントに置き換えることを狙いにいくことが多い)

エンドユーザと直接やり取りできる環境にあるのであれば、ユーザが少しでも不満を持っていることが解ればチャンスである。顧客に対してより良いものが同額で出来ることをアピールすることで味方につけることができるかもしれない。そうなればいくらSIerでも顧客の要求は呑まざるを得ないのである。

それでも駄目なら、万策尽きたのなら甘んじて状況を受け入れた上で、次回こそはセルフビルドされたコードを使ってもらえるように日々精進するしかない。

豪華客船型フレームワークは作るのに時間がかかるので設計が大袈裟で古い。(大抵は3〜4年前の設計だ)また、特定のオーサリングツールや開発環境にロックインしているフレームワークはその部分が陳腐化するのが早い傾向にある。(対象にしているツールのバージョンも古いことが多い)
長い目で見るといくらでも弱点はあるので、我々はめげずにその弱点を最新の技術で攻めるのだ。