framework

＠IT：独自のフレームワークをオープンソース化、テンアートニ

フレームワーク開発において、初期の1つの「上がり」かなと思います。このテンアートニの試みが上手くいけば、同社は業界内で一定の地位を確保することが出来るでしょう。
自分も数年前、勤めている会社で「ベースフレームワーク開発→スキル蓄積・アダプタ追加による機能拡張→フレームワークを核とした他社との協業」といった提案を行ったことがありました。悲しいかな、それは実らず、ただStrutsを使っている人になりましたが・・・。

やりやすいところから再利用を

システム開発において、「再利用」は使い古されたキーワードです。
例えば過去の構造化プログラムにおけるモジュール分割や機能による関数分割であったり、最近ではオブジェクト指向プログラムにおけるクラス分割は、手法は違うとしても目的は再利用可能部分を最大化することを目的としていると思います。

ただ、どうしても再利用が上手くいっているというケースは多いとはいえないのではないでしょうか？特にビジネスロジックの部分（これを機能用件といいます＝クライアントがシステム化を希望する理由であり、かつシステム化を希望する部分です）の再利用は困難がつきまといます。いわんや、機能用件はクライアントによって千差万別であり、クライアント企業のビジネスプロセスは同じモノはないと考えられます。

システムを受託で開発するようなケースで、ビジネスロジックの開発をヒアリングから始めて実施するようなことは多いと思いますが、そこで再利用を前提とした開発を行うとなると、そのクライアントにとって不要な機能や、オーバースペックな機能を「再利用を前提とする」という旗印の下に実装しなければならないことになります。そして、それは無理が付きまといます。そのコストは？それによる納期の遅れをクライアントは待ってくれるのか・・・？

そうであっても、今後、システム開発における再利用は進化すると考えます。おそらく、それは「コンポーネントビジネス」として成り立つことになると思います。あくまで「それをビジネスとする」というところがポイントでしょう。システム開発会社が自社用に「おまけ」的に取り組む再利用ではなく、コンポーネント会社のようなものが多くの企業のシステム開発において幅広く使われるコンポーネントを、そのために作り、ビジネスとする・・・。システム開発会社はそのコンポーネントをいかにクライアントの希望に沿うシステムと見比べてチョイスし、組み込んでいくという姿になるのではないでしょうか。それが実現可能な機能用件の再利用になるでしょう。

一方、機能用件の対義語として「非機能用件」というものがあります。システムをシステムとして成り立たせるためには機能用件だけでは十分ではなく、必ず非機能用件が必要となります。それは例えば、使用するデバイスであったり、ミドルウェアであったり、さらにはWebシステムなどのシステムの構成形態を指します。クライアントはWebシステムを作りたいのではありませんし、特定のミドルウェアを使って欲しいのでもありません。あくまで「自分の要求を満たす機能をコンピュータ・システムとして実現して欲しい」のです。（最近では、クライアント側が非機能要件を指定することもあります。例えば「Webシステムとして作って欲しい」であったり、「モバイルに対応して欲しい」など）

例えばWebシステムというシステム構成の非機能用件は、大抵の場合、構成が似通っています。モバイルに対応するために必要となる実装手段も、どんなシステムであっても似ています・・・。これこそが、再利用の対象になるに違いありません。（つづく）

フレームワークによる開発の手法を考えてみようと思います。
まず、フレームワークについての概略ですが、「システムを開発する際にその開発する手法や方法論を実装よりから定義していったもの」ということが出来ると思います。（「フレームワーク」という単語には実は広い意味があって、例えばMicrosoftのMFCはフレームワークですし、COMやActiveXもフレームワークの一種といえます。ここではMFCに近いものを狭義のフレームワークとして単語を使用しています）

例えば、Javaアプレットだと、init()メソッドが呼ばれて、次にpaint()メソッドが・・・といったようなメソッドの呼ばれる順番に定義があり、そのメソッドだけを開発するという手法を取ります。まさに、このような手法が私がここでいっているフレームワークです。
このJavaアプレットとかWindowsアプリケーション開発用のMFCは、普通の（例えばDOS上のC言語での）アプリケーション開発とは異なり、main()を実装することはしません。main()はご存知の通りプログラムの起点となる実に重要なメソッド、関数ですが、これを実装しなくて、どうしてプログラムが動くのか・・・？という疑問が生まれます。
ある種のフレームワークでは、main()は実装済みで隠蔽されています。間違いなくプログラムの起点として呼び出されるのですが、それをプログラマが実装する必要はないのです。

この「実装済みの部分」を「フローズンスポット」といいます。つまり凍結された部分なのです。ここで、システム全体のうちフローズンスポットを最大化すると、開発にかかる工数は（少なくとも実装作業としては）最小化します。一方、フローズンスポットの対義語として、プログラマが開発する部分を「ホットスポット」といいます。基本的に、ホットスポットが最小化すると、工数も最小化するわけです。（つづく）

やけに挑発的なタイトルをつけてしまいましたが、何を言いたいのかというと・・・。

砂で城を作ろうとする場合、まず水を混ぜるなりして固形のブロック状のものを作らないといけないでしょう。つまり、砂で積木のブロック相当のものを作ることから作業が始まります。だから、積木で城を作るよりも、砂では時間がかかってしまいます。

では、砂で城を作るのが悪いのかというと、そうではありません。なぜなら積木はブロックの形が予め決まっていますが、砂は自分の好きなブロックを好きなように作ることが出来ます。

システム開発の分野に置き換えると、砂の一粒は、ちょうどプログラム言語の一語に相当するでしょう。だから、何もないところからプログラム言語だけを使ってシステムを組むことは、砂遊びに相当します。この場合、完全なオーダーメイドですから、顧客の望むものが確実に出来ます。しかし、時間（費用）がかかります。また、砂で城を作るのは高度なテクニックが必要になると思いますが、システム構築でも同様に、技術者の技術レベルによっては、危なっかしいシステムになる可能性も大です。

積木遊びの世界はレディメードです。積木の一つのブロックは、砂の一粒に比べて圧倒的に大きく、自由な形には出来ません。おおよそ、出来上がった城は似たような形になりがちです。しかし、砂で作ることに比べて圧倒的に速く、幼児でも作れますからテクニックも不要です。

コンピュータが生まれてから、システム開発はずっと砂遊び式の方法が取られてきました。しかし、最近ではシステムは経営に直結するためにスピーディーな開発が求められています。さらに、技術者は不足がちです。こうした中で、遅くてテクニックが必要な砂遊び式ではない、速くてテクニックが不要な積木遊び式のシステム開発が待望されるようになっています。（究極的には城をそのまま買う・・・パッケージをそのまま適用することで、開発そのものを不要に出来ますが、顧客のビジネススタイルをパッケージに合わせて変える努力が必要になってしまいますので、そこまでは求められていないようです）

積木遊び式システム開発は、待望だけでなく既に形になっているものもあります。VBやDelphiにおけるコントロールや、JavaBeans、EJB、Webサービス・・・といったコンポーネント思想、分散コンポーネント思想がまさに当てはまります。

現在、積木遊びはさらに進化しようとしています。城を作るときに、あらかじめ積木をはめ込む枠を用意して、そこに好きな色の積木をはめ込むだけで城を作ってしまおうという発想です・・・枠・・・そう、フレームワーク（枠組み）です。VBやDelphiでもスケルトンやテンプレートといった枠が用意されていましたが、さらに進化してEJBを核とするJ2EEの世界ではMVCフレームワークがあり、Webサービスの世界ではMicrosoftの.NETや、各アプリケーションサーバ毎でフレームワークが用意されています。

積木を作ること、どの積木を使うか選ぶこと・・・これがシステム開発の中心的作業になる日は遠くありません。