INTER-Mediatorの開発モデル

2011/8/1

INTER-Mediatorの仕組みは、現在のソフトウエア工学の中心的なアーキテクチャである「レイヤー」とは異なります。適切な名前がないのでここでは、「2階層的システム」と称することにします。データベースと、Webページがダイレクトに結合するという意味合いを取りました。

現在のソフトウエア工学が、3階層システムやMVC、あるいはビジネスレイヤーといった考え方を元に作られて大きく成功していることは言うまでもありません。これらの手法は、巨大化するソフトウエア開発というところに焦点が当てられています。アーキテクチャ的な面に限らず、1年を超える開発期間や、10年を超えるメンテナンス、さらには何十人ものスタッフによる開発、こうした開発をいかに効率良くこなすのかといった点に重点が置かれています。

一方、現代のソフトウエア工学では、「小さな開発」についてはあまり取り上げられる事がないように思います。個人あるいは部門、小規模な組織といった単位での開発は、前出の大きな開発にくらべて、ともかく予算が限られているため、ビジネスとしては小さいもとなります。言い換えれば、メジャーな企業は取り組むことはあまりない領域と言えるでしょう。

かくして、企業全体で使うような大きなシステムは構築されても、小さな単位での業務のコンピュータ化は進展しないこともあります。結果的に、Excelで作ったワークシートをメールでやり取りするという状況に陥り、仕事よりそのものよりもファイル管理に時間が割かれるという状況が生まれます。

こうした小さな開発をまかなうソフトウエア製品としては、FileMakerやAccessといったものがあります。これらを専業としている開発会社も小規模ながら存在しますが、一方、ユーザ自身が自分のために作る事もあります。つまり、ソフトウエアのプロフェッショナルではない人が開発者となる側面が目立つのです。

大規模な開発のノウハウを小規模なものに持ち込むということももちろん可能です。しかしながら、たとえばドキュメンテーションを取っても、たくさんの開発者が概念や設計情報を共有するためのドキュメンテーションと、1人の現場で働いている人が片手まで作るデータベース向けのドキュメントは自ずと異なります。多数いる場合は、労力をかけてドキュメンテーションを充実させないといけませんが、1人の場合はいかに最低限に必要なものを抽出してドキュメント化するのかが非常に大きな問題です。また、ドキュメントそのものの作成がかえって「余計な仕事」と評価される場合もあります。

つまり、小規模な開発には小規模な開発の方法論があり、それは必ずしも大規模な開発とは一致しないと言えるでしょう。

小規模な開発では、むしろ、2階層的システムの方が、適合する場合があります。FileMakerやAccessが使われている理由は、2階層的なシステムの手軽さがあるからです。こうした開発は、しっかり設計するよりも、短いスパンで結果が得られ、実際に試してみるということが望まれることです。工数をかけずに一定の結果を出すためには、設計をしっかりやるよりも、まずは作って考えるということが望まれるわけです。そして、だめであっても、工数がかかっていないのなら容易に捨てる事ができます。

INTER-Mediatorはこうした2階層的システムをWebアプリケーションで構築する事を目指したものなのです。FileMakerもAccessも一定の評価はできますが、一方で自社製品に囲い込むための仕組みがシステム構築の足かせになる場合もあります。特に、いずれも、Webアプリケーションへの展開に手を焼くユーザが多いのも事実です。INTER-Mediatorなら、まったく同様な作業をするわけではありませんが、FileMakerやAccess並みの手軽さでWebアプリケーションが作成できます。

大規模な基幹システムが稼働する中で、身の回りの業務はExcelというのは、実は10年以上前と何も進歩がないと言えます。汎用ソフトを使い込むのは悪い事ではありませんが、その中のルーチンワーク的なことはシステム化することでより効率的に業務をこなせるようになります。そこを阻害するのは、手軽な開発手法が広まっていないからです。大きな予算で大きなシステムを作ることばかりではなく、小さな予算で小さなシステムを同じように効率的に展開するということで、中小企業だけでなく、大企業の部門などでもITのメリットを享受できるようになるのではないでしょう。INTER-Mediatorはそうした「システム開発像」を実現するものです。

INTER-Mediatorに至った理由

2011/7/12

90年代中頃より、Web開発が本格化したと記憶します。当時、用意された基本的な関数などでスクラッチから作るスタイルもありましたが、その一方でColdFusionにも人気がありました。ColdFusionが受けたの理由の1つは、HTMLに拡張タグ要素を追加することで、データベースとの連携やさまざまなアプリケーションを作成する機能が利用できたことです。また、FileMakerでもCDMLとして、同様な仕組みを提供していましたし、サードパーティからLassoという同じおうな仕組みの製品も登場しました。いずれも、独自な言語をHTMLに追加していて、サーバサイドで独自仕様のタグを処理してページ生成していました。HTMLの延長で作れる手軽さが受けたわけです。

しかしながら、2000年が近づくくらいの頃から、より高度なアプリケーションを作成するというニーズが発生しました。Java EEを中心としたJavaを利用した開発手法がまずは発展し、同時にスクリプト言語の利用が進みました。その段階では複雑なアプリケーションを作る手法として、レイヤーアーキテクチャが注目され、MVCや3階層あるいは４階層システムが目標となり、次第にそれが常識となりました。Javaはある程度のところで飽和した感じがありますが、2005年前後からは、Ruby on RailsやPHPの各種フレームワークで、Javaの流れを受けてMVCを基調としたフレームワークに注目が集まる傾向があります。こうした流れの中で、ユーザインタフェースコンポーネントと、データベースの特定のテーブルの特定のフィールドとの間で、自動的にデータをやりとりする「バインド」という考え方はどちらかと言えば忘れ去れて来ています。バインドという言葉はいろいろ意味がありますが、ここでは前文のような意味でとらえることをします。つまり、バインドされたテキストフィールドには、フィールドの値が自動的に設定され、その値を変更すると、値は自動的に書き戻されるという状況です。もちろん、FileMakerやMicrosoft Accessはそうした仕組みをデスクトップアプリケーションでサポートし、今でも使われています。

３階層アーキテクチャでは、確かに柔軟性が高いことは否定できません。ストレージを抽象化できるので、「間違えたスキーマ」でもアプリケーションをなんとか動かすことが不可能ではありません。その点は善し悪しがありますが、仕事をこなすという点では「できる」ことは重要です。しかしながら、一方で、バインドということはプログラマが自分で管理するのもになってしまいました。つまり、「<php echo $record['field']; ?>」みたいな記述を手作業でやるということが基本になっています。一方、POST等でフォームをコミットした結果を受けるというような仕組みは、大昔のCGIと原則は同じ仕組みです。

しかしながら、３階層でないと作れないシステムはあるかもしれませんが、２階層でも十分に実用になるようなアプリケーションもあります。あるいは、見方を変えれば、３階層が必要なシステムも、適切なスキーマにすることで２階層で処理ができる可能性があります。しかしながら、Webでは２階層的なシステムを作るための素材はもはやほとんど使えません。ColdFusionは存在しますが、ほとんど過去に作ったアプリケーション資産の保持のために残っているようなものです。FileMakerは2004年のVer.7でCDMLをサポートしなくなりました。いずれも、それなりに支持はあったものの、大きな欠点は複雑なことをしようとしたときにかえって大変になるという２階層システム独特の袋小路にぶちあったのです。そういうこともあって、３階層システムの柔軟性に注目されたのです。

INTER-Mediatorを構想したのは2009年暮れで、CodeIgniterを使っていくつかのシステムを作った上での発想です。Webページ上のユーザインタフェースコンポーネント、あるいはあらゆる要素を、データベースの特定のレコードの特定のフィールドとバインドする設定を最低限の作業で行えれば、２階層Webアプリケーションは簡単に作成できます。加えて、複雑なニーズに対応する仕組みを入れるということを考えました。その結果、INTER-Mediatorの最初のバージョンができました。最初のバージョンは仕組みの上での限界があり、2010年中頃から再構築して、2011年の中頃におおむね一定のレベルまで到達できました。

バインドについては、要素のclass属性、あるいはtitle属性に、テーブル名、フィールド、そして要素の何に作用をするのかという記述を行います。つまり、HTMLの範囲を逸脱しないで、ページ内の要素にバインドの設定を記述できます。ただし、テーブルに関する情報を別のファイルにある程度記述しなければなりません。テーブルの主キーや外部キー、そして外部キーとつながる別テーブルのフィールドなどに加えて、検索条件やソート条件なども指定することになります。INPUTやTEXTAREAタグの要素のテキスト自体であれば、そのデータをユーザが書き換えれば、データベース側に更新がかけられます。また、データベースに存在するデータは、複数のレコードである場合もあります。そこで、「エンクロージャー」「リピーター」という概念をDOM要素に持ち込ます。これは、たとえば、レコードの数だけテーブルの行（つまりTR要素）を繰り返すというような仕組みになっています。こうして、複数レコードの対応を組み込みました。リピーターの中にエンクロージャーがあれば、そこでリレーショナル処理を行うという仕組みも動くので、マスターからの取り出しや、あるいは選択肢をポップアップで表示するだけでなく、他の選択しに応じてポップアップの選択肢が異なるようなものも、「設定だけ」でできます。

こうした２階層な仕組みだけでは、柔軟性が足りません。そこで、サーバ側では、データベースからの取り出しや更新の前後に、処理を組み込むという仕組みを提供しています。自由な動きをするオブジェクトではなく、フィルタ的な仕組みではありますが、データの処理という点ではビューと組み合わせることも考えれば、かなり多彩な処理ができるはずです。一方、クライアント側は、JavaScriptを使ってさまざまな仕組みを組み込みます。ページを生成している間やあるいはユーザのインタラクションに合わせて、ページに展開した後の要素を参照する仕組みなどを用意するので、たとえば、各行の単価と個数をかけて金額の要素に表示するということが記述できます。

２階層の部分を、Webページとデータベース層で考えれば、それぞれ前者にはJavaScriptによる処理の追加、後者ではフィルタリングによる処理の追加が可能なので、いわば４階層的なものであるとも言えます。こうして、「簡単」と「拡張性」の両立を目指したのです。