IT☆ぱらだいす

これはどこの開発現場でもそうですが、フレームワークに過度な期待をしているようです。

フレームワークは工数を縮めない

フレームワークを開発に利用したからといって、納期を縮めることはできないのです。

これは、私が「アスペクト指向」プログラミングの講師をした経験からも言えます。

アスペクト指向のフレームワークである「Spring」、DBコンテナの「iBatis」。
どちらも、理論的にはソフトウェア開発の理想をいっています。
複数箇所に散らばった似たような処理を、一箇所にまとめたり、DBの接続設定やSQLのベースを一箇所にまとめたりして、開発の負担（ソースコードの記述）を減らそう。

そういうものなのですが、言うのは簡単。
しかし、それを実現するためには、別のところでしわ寄せがくるのです。

「Spring」や「iBatis」、「Struts」などは、ソースコードの行数を減らすことができますが、その分複雑なXMLファイルの記述に工数がかかります。
また、XMLはコンパイルやビルドを行うわけではないので、誤りがあったとしても、その箇所を突き止めるのに、多くの時間を費やしてしまいます。

大手ソフトウェアベンダーのフレームワーク

大手ソフトウェアベンダーのフレームワークのなんかもそうなのですが、たとえばF社の開発プラットフォーム。
GUIで項目とデータ型を設定すれば、設計書とソースコードのテンプレートが出力され、開発工数を削減できるという謳い文句ですが。

実際は、仕様変更で、項目名や桁数が変わるたびに、設計書と、テンプレートを出力し直さなければなりません。

そのテンプレートのソースコードは１画面で２０〜３０あり、様々なフォルダに格納され、さらに言えば、素の業務ロジックのないテンプレートですので、すでに作成済みのソースコードと、Diff（２つのソースコードの相違点を調べるツール）ソフトで、相違点を調べてテンプレートの内容を、開発途中のソースコードに反映させなければなりません。

項目名や、桁数が変わるたびに２〜３時間の作業が必要なのです。

フレームワークさえ使用しなければ、プロパティーの値を変更するだけでいいのに。

「フレームワークを使ったばかりに工数が増えてしまった！！」
そう思うことも度々あります。

まさに、ソースがぐちゃぐちゃになるか、XMLファイルがぐちゃぐちゃになるか。
どちらを選ばなければならないのです。
プラスマイナスゼロなのです。

理想論と実現方法の乖離

オブジェクト指向とアスペクト指向の話で言えば。
私的に、（コーディングをしなければ）オブジェクト指向の弱点を克服するアスペクト指向がなかなか思想的にはよいのですが、それはあくまで思想的な話。

ソースコードの負担を減らした分、いろんなディレクトリに設定ファイルやソースコードが散らばり、わけがわからなくなってしまう。
理想を語り、それを無理矢理実現するために、逆にソースが煩雑になってしまう。

どの画面も同じ構造のソースコードにしたいのなら、オブジェクト指向の継承、抽象クラス、抽象メソッドの使用くらいがちょうどいいと思います。

自由度がありそうで、じつはガッチガチに制限され、仕様を満たすためには裏技的なプログラムを書かなければならない。

私の参画した前のプロジェクトと今のプロジェクト。
共に、自社グループの独自のフレームワークを使用していますが、いままで使いやすいフレームワークには出会ったことがありません。

・・・・なんとかならないものか・・・・。