世間一般に認められている優秀なフレームワークというのは結構ある。 中には開発生産性を大きく高めるものもあり、そういうものは大変ありがたく使わせてもらっている。

しかし、社内アーキテクトによくある勘違いが、 「じゃあ、それをラップして、より便利なフレームワークを作ろうぜ (￣ー￣)ニヤリ」 というものだ。

このやり方は、アーキテクトの自己満足になるだけで、実際の開発者には メリットがない場合が多い。具体的なデメリットとして以下のようなものがある。

• 開発者は、基本的には両方のフレームワークを知らなければならない
• ソースが追いづらい
• ラップされる側（いわゆる有名なフレームワーク）の理解が中途半端になる
• アーキテクトの技量が低いと、ラップされる側のフレームワーク機能が使えなくなったりする
• ドキュメントに、ラップされる側へリンクを貼った形式が多くなり理解しづらい

また、実はアーキテクト側にも面倒なことは多い

• ラップされた方のフレームワークに緊急バグフィックスがあった場合に、影響を受けてしまう
• 常にラップされる側のフレームワークの動向をチェックしないといけない
• ラップされる側の有名フレームワークを知っている新規開発者が入ってきても、教育が必要になってしまう

なので、百害あって一利なしだと思う。 基本的には有名なフレームワークを、そのまま使うのがいいのではないか。 フレームワークをラップして洗練するというのは アーキテクトとしては楽しい作業であり、つい盲目的にやってしまいがちだが、 アーキテクトの使命は開発者に楽をさせることだというのを忘れてはならない。

なんてことを、NHibernateをラップしたActiveRecoredを使っていて思いました。 ようするに愚痴です orz

このブログで、何度か書いているように、私はフレームワーク反対派です。今日は、フレームワークに対するライブラリの優位性を、開発者のシステム理解度の観点から説明します。

フレームワークとは、システムの大枠です。フレームワークが、システムの共通処理部分を実行してくれるので、一般開発者は、業務ロジックに特化した部分を、フレームワークの処理の流れの中に、組み込むことになります。

図にすると、こんな感じです。

一般開発者は、フレームワークが実行している処理について、ドキュメントを読んで、大まかに理解していることが多いですが、ソースコードを追うことは、あまりありません。

フレームワークを使わずに、ライブラリを使った場合は、以下のようになります。

フレームワークがないので、処理の流れ全体を、一般開発者が作成します。一般開発者は、ライブラリのドキュメントを読みますが、ソースコードを追うことは、まずありません。

一見すると、フレームワークのほうが、ソースコードを読まれる可能性が高い分、システムに対する理解度が増すのではないかと思いますが、それは間違いです。先ほどの図で、一般開発者が、実装している独自処理部分に、注目してください。

フレームワークを使用した場合は、処理の流れの中で、フレームワークのロジックと、業務ロジックが交互に実行されます。これでは、一般開発者は、処理全体の流れを把握するのは大変です。大体こんな処理をしているだろうという想像は出来ますが、完全に全体を理解するには、他人が書いたソースを追うしかありません。フレームワークの中で、理解不能の例外が発生した場合などは最悪です。フレームワークは、取り外し不可能なので、必死で原因を調査して、ツギハギ的な対応をすることになります。しかも、そのような例は、比較的大きなフレームワークでも起こったりします。

 ライブラリの場合は、一般開発者は処理の流れを全て把握できます。ライブラリは、処理の流れの中に、特定の機能を組み込むため、一般開発者によって、能動的に呼び出されます。ライブラリの中で、理解不能の例外が発生したら、その箇所では、ライブラリを使わないという選択もできるので、ハマることがありません。

一般開発者が作った画面は、通常、一般開発者によってメンテナンスされます。その際に、処理全体の流れが見えていないと、とんでもないポカをやらかす可能性がでてきます。フレームワーク作成者しか、全体の流れが見えないシステムを作るのでなく、一般開発者全員が、処理の流れを細部まで、理解しているシステムを作る。そのためには、フレームワークという枠組みは邪魔でさえあるのです。

今、担当している Java Swing 案件のフレームワークは、ある意味すごい。○○Frame や、○○Button （○○は会社名略称）のように、Swing の全てのコンポーネントを、ラップしている。また、Swing にとどまらず、○○List や ○○Map 等の、コレクションフレームワークラッパーまである。ありとあらゆる標準 API をラップしているのだ。

ただ、自分は、以下の理由で、このフレームワークはダメだと感じる。

1. 学習のコスト
2. 費用対効果

ラッパーの作成は、継承または委譲で実装されているが、委譲に関しては面倒だったのか、全てのメソッド、フィールドが委譲されてないケースがあった。これでは、Java 標準 API に精通した熟練者であろうと、このフレームワークを使用する場合には、新たな学習をする必要がある。さらに、学習をしても、企業や部署が変わると、使用できないので、モチベーションが上がりにくい。

また、このフレームワークは、かなり多くのクラスをラップしているので、フレームワーク自体の開発コストは、そうとうなものだったと思われる。しかし、それだけの苦労に相当する効果が出ているかというと、とても、そうは感じられない。膨大なクラスのフレームワークは、学習するだけで膨大なコストがかかり、初めて使用した際は、工数が膨れ上がる。では、2回目以降の開発では、楽が出来るのかというと、JDKのバージョンも、そろそろ上げないといけないし、これからの案件では、このフレームワークは使われないという。

Effective Java 等の書籍を読めば分かるように、標準 APIというのは、非常に洗練されている。Jakarta Commons のように、大規模な開発を行い、さらにオープンにして、あらゆる企業で使用可能とするならともかく、一介の技術者が、その全てを改良してやろうと考えるのは、傲慢ではないだろうか。

一般開発者にとって優しいフレームワークとは、独自の作りこみを減らし、標準 API を積極的に利用して作成されたものなのだろう。フレームワーク開発者は、フレームワークを作って、一般開発者をそれに従わせるより、標準 API を利用してもらうための、Java レクチャードキュメントを用意するべきだ。

フレームワークという言葉には、ある種、華があるが、フレームワーク開発者という立場から一歩視点を広げ、ソフトウェア基盤技術者として、一般開発者の作業を楽にする方法を真摯に考えていくことが重要なのではないだろうか。

タイトルにある、4製品は、どれも最近台頭してきた、ソフトウェア開発環境であるが、これらには、共通点がある。

これらは、すべて、デザインに重きがおかれているのだ。

Silverlight、WPF は、マイクロソフトの製品、Flex、Apollo は、Adobe の製品であるが、これら2社は、これからのソフトウェア開発では、デザインが重視されていくと予測しているのであろう。

では、なぜ、これら2社は、デザインの波が来ると考えているのか。

それは、ある程度、ソフトウェア業界というものが成熟したからではないだろうか。これは、持論だが、「成熟した業界は、デザインでの差別化が重要となるの法則」というのがあるように思う。

例えば、自動車の開発なども、最初は、とりあえず走る車の製造から始まり、クーラーやCDプレーヤ等、機能の追加で差別化が計られてきた。しかし、自動車という製品が、ある程度成熟し、機能差が付けにくくなった時、デザインやブランドによる差別化に重きが置かれるようになった。

Web 業界は、Yahoo による、Web1.0 から始まり、最近になって、ユーザ参加、集合知などを駆使した、Web2.0 による機能的革新が起こった。しかし、Web2.0 企業の躍進のスピードは、一時期に比べて停滞しているように思える。今が、デザイン重視への転換期にあるのではないか。Web2.0 的デザインが流行ったのも、この大きな転換の合図だったに違いない。

Web2.0 的デザインといっても、これまでは、画像等を綺麗に作って、CSSでレイアウトしてというレベルのものだった。だが、これからは、Silverlight でムービーを流したり、Flex で、エフェクトをかけたりといったサイトが当たり前のように出て来るだろう。もちろん、デスクトップアプリケーションも、WPF や Apollo によって、同じように生まれ変わるはずだ。

今、プログラマやアーキテクトをしている人は、デザインの技術を高めておくと、大きな武器になるだろう。これから、デザインが流行るというのは、2つの大企業の、お墨付きであるのだから。

フレームワークを使った開発をしていて、なぜか気分が重い。開発は楽になっているはずなのに、心が晴れない。その理由を、今から明確に説明します。

説明を円滑に進めるために、まず、ここでいうフレームワークを以下のように定義しておきます。

よく、ライブラリとフレームワークは混同されますが、ここでは、明確に区別します。必ず使う必要があるものがフレームワークで、使うかどうかの選択権が開発者にあるものが、ライブラリとします。

Strutsは、ほぼ純粋なフレームワークと見ていいでしょう。Jakarta Commonsのプロジェクト郡は、ライブラリです。

ここから、本題です。

まず、勘違いしないで頂きたいのが、特定の人にとっては、フレームワークを使った開発はとても楽しいということです。内部設計ができず、独力ではアプリケーション全体を開発できない人が、それに当たります。

フレームワークを使った開発を、つまらなく感じる人は、その逆です。内部設計ができて、標準APIだけで、アプリケーション全体が作成できる人が、それに当たります。

それでは、なぜ、後者の方たちの多くは、フレームワークを使った開発が、楽しくないのでしょうか？開発工数は、減っているにも関わらず・・・。

理由は、2つあります。

1つ目は、自己価値の喪失です。プログラム開発というのは、本来、一定レベル以上のスキルが要求され、誰にでも出来るものではありません。今まで、開発者は、プログラムを、自分の力で開発することで、自分の価値を見出すことが出来ました。しかし、フレームワークを使用した開発では、一定のルールさえ覚えてしまえば、スキルの低いプログラマでも開発できてしまいます。せっかくスキルを高めても、フレームワークを使う以上、それは特に必要とされません。「私が死んでも、代わりはいるもの」では、自分の生きている意味を見出せなくなってしまいます。

2つ目は、自己実現の阻害です。プログラミングは、とてもクリエイティブな仕事であると言えます。工夫次第で、生産性は何倍にもなるので、自然と成長を図りたいと思うようになります。その作業は、非常に創造的です。しかし、フレームワークを使用した開発では、「創造性＝悪」になります。そこでは、プログラマの創造性は発揮されず、アプリケーションは、フレームワーク開発者の知識の中に収まったものになります。

 フレームワークを使用する場合は、まずプロジェクト人員のスキルを、見極めることが重要です。スキルの低い人員が多い場合、個人的には、人員への教育で乗り越えるべきだと思いますが、一定の品質を確保するため、フレームワークを適用するという選択もアリでしょう。

ただ、スキルのある人員に対して使用してしまうと、それは、プログラマの成長を止め、創造性を奪う結果になることは、覚えておかなくてはなりません。

Easyが売り、の問題

以前フレームワークに関して書いたけど、まさたか氏の意見には大賛成です。

Javaのフレームワークには、開発者の傲慢が感じられるものがあると思ってます。利用者をバカにして、ベルトコンベア方式のような開発をさせていては、いつまでたっても利用者はバカのままです。

確かに、トラックバックされている方のお話のように、何も分からないようなプログラマが来たときは泣きたくなりますが、最初は多少苦労してでも基本をしっかり教えた方がいいです。次の開発からは楽になりますし、いつかトンでもないポカをやらかすかも知れませんから。

分からない人には、楽をさせるのでなく、苦労させる必要がある気がします。（コーチング理論）

せっかくだから、いろいろ書いちゃいますが、極論、個人的には、Java言語の標準に準拠したコード（ServletやJSPとか）を、ものすごく簡単に書けるツールとかがあれば、フレームワークはいらないくらいです。分からない部分を隠蔽するフレームワークより、分かってる部分を楽に作らせてくれるライブラリをください。

利用者の創造性を奪うようなフレームワークでは、開発が楽しくない、楽しくないことははかどらない。楽しくないことは勉強したくない。結局、悪循環な気がします。

SeasarがDoltengというEclipseプラグインを出している。私はこれを触ったわけではないので製品自体に関して詳しくは述べないのだけど、TeedaとUujiというフレームワークを使用して開発する際に、生産性を飛躍的に高める効果があるらしい。

ひがやすを氏のブログに書いてあったのだが、EJB3、JPA、JSFを単に導入しただけでは生産性がうまく上がらず、独自に開発スピードを上げるための仕組みを作る必要があり開発したそうだ。

一応、社内フレームワークを開発している立場として普段私が思っていることがある。

「フレームワークよりライブラリを。設定より規約、規約よりツールを。」

Seasarプロジェクトの考え方と似ており、私の考え方がひとりよがりのものでなかったようで少しほっとした。

フレームワークが必要な層というのは内部設計ができないレベルの人達である。そのレベルの人達に対してフレームワークはコーディングの筋道を示し、コード品質を一定に保つのに一役買う。

しかし、、プログラマがある一定レベルを超えていると、フレームワークはかえって足かせになってしまう場合がある。現場の仕様は複雑で様々な例外的処理を含んでおり、一定の筋道に沿ってコードを記述していくのが難しい場面がしばしば出てくる。

内部設計が出来るレベルのプログラマに必要なのは統制のとれたフレームワークでなく、開発生産性を上げるライブラリなのだ。私は普段フレームワークを作る際は、わざとプログラマの自由度を高く設定する。そして、再利用可能なちょっとした関数や、単純にコードの記述量を減らせるライブラリに重点を置いて開発している。

それに近い理由で開発の生産性を高めるツールの重要度は高い。Railsが世に出てから「設定より規約」の考え方が浸透してきたが、私はこれは少なくとも一定以上の規模を持つシステムでは当てはまらないと考えている。設定ファイルは記述するのが面倒だが、システムに柔軟性を与える。変更する必要の高い定数を切り出しておくことで、可搬性、可用性が大きくアップする。

面倒だから書かないではなく、面倒だからツールに書かせるなり工夫しようという考え方が重要なのだ。Seasarは、設定ファイルを書かないのではなく設定ファイルを使用しつつも考え抜かれたデフォルト値を使うことで設定なしでプログラムを動作させることが可能になっている。

時にフレームワーク作成は、開発者に対する自分の考え方の押し付けであったりする。反対に一見地味なライブラリやツールの作成に必要なのは地道な努力と謙虚な姿勢なのである。実際の現場が求めているのは、フレームワークという押し付けでなくライブラリ、ツールという援助（愛）なのではないだろうか。