モデル駆動(MDA)から仕様書駆動(SDA)へ

■何がMDAを殺したのか

　期待されたわりにあっけなく消えてしまった技術用語は数多いが、そのひとつとして「モデル駆動アーキテクチャ(MDA,Model Driven Architecture)」を取り上げよう。ソフトウエアのあり方を「モデル」としてまとめ、これにもとづいて開発作業を合理化するための枠組みのことをいう。考え方としては昔からあったが、オブジェクト指向技術の標準化団体であるOMGによって2001年に体系化された。当時は注目されたものだが、今ではすっかり聞かれなくなった。

　なぜか。MDAを実現させるための自由な発展を「UML」が邪魔したため――そう私はにらんでいる。

　じっさいは、MDAにおいてUMLの利用が強制されているわけではない。しかし、なにしろOMGによって提唱された枠組みなので、UMLの利用が前提と理解されたのは自然の成り行きだった。ちょうどその頃は、この表記体系がソフトウエア開発の救世主のように見られていたこともあって、UMLモデルからコードを自動生成するための機構（MDAツール）がいくつか登場して期待が高まった。しかし、少なくとも「業務システム開発」向けに決定的な成果はいまだに生み出せていない。

　UMLの何が問題だったのか。クラスの構造やふるまいを記述することに関して、UMLになんら問題はない。じっさい、開発しようとしているソフトウエアが「クラス」であれば、UMLはすこぶる便利だ。UMLで事前にモデル化したクラス構造をプログラミングすることで、ソフトウエアは無難に出来上がる。

　ところがその逆は真ならず。「どんなソフトウエアであっても、クラスをプログラミングすることで出来上がる」とは言えない。

　どういうことか。これまでも何度か説明したように、「"イパネマの娘"の演奏プログラム」をJavaやRubyを使ってスクラッチ開発するとすれば、UMLでクラス構成をモデリングしてプログラミングするという手順に意義はある。しかし、現実にはミュージシャンはそんな面倒なことはしない。SONARや初音ミクといった手馴れたDAW（演奏を録音したりプログラミングして音源を作るためのツール。Desktop Audio Workbench）を使って、「演奏シーケンス」としてサクッと「演奏プログラム」を制作する。

　その際に「演奏シーケンス」は、UMLではなく、ピアノロールや五線譜を模した独特な形式でまとめられる。こうして出来上がった「音楽演奏モデル」にもとづいて、意図されたふるまいが実行（演奏）される――この風景はMDAに他ならない。じつはこのようなソフトウエア分野は珍しくない。プログラミング言語で綴られた「クラス」ばかりがプログラムの元ネタではないのである。

　ようするに、音源制作におけるDAWのような作業合理化のための基盤を、業務システム向けに用意すればいい。このシンプルな発想に至ることを、UMLが邪魔をしなかったといえるだろうか。たしかに業務システムも、UMLでモデル化してクラス群をプログラミングすることで手に入ろう。しかし、その手順にこだわる理由など何もなかったのだ。

■システム開発と「仕様書」

　では、UMLにこだわらないとすれば「業務システムのシーケンス」はいかなる形式でモデル化されるべきなのだろう。「演奏シーケンス」が五線譜等で表現されたように、ソフトウエア分野（ドメイン）の特性に応じた固有の形式（DSL, Domain Specific Language)で表現されたらいい。業務システム開発のドメイン向けには、どんなDSLを利用すればいいのか。

　答のひとつが身近にある。我々が昔から慣れ親しんできた「仕様書」だ。表形式を基本とする仕様書の様式は、業務システムのあり方を事前に「モデル化」するためのオーソドックスな形式に他ならない。

　拙作の開発基盤XEAD Driverはその実例だ。仕様書の形式でまとめられた「システムのあり方を示すモデル」を専用のドライバが読み込んで、自らを変形させて「仕様書どおりのアプリ」として立ち上がる。「コードの自動生成」ではなく、まさにDAWのように「動的制御」を実現できている事実が、DSLとしての仕様書の適合性をよく表している。

　五線譜だろうと仕様書だろうと、それなりの形式で表現されたモデルにもとづいてソフトウエアが意図どおりに動くとしたら、その枠組みをMDAと呼んで間違いではない。ところがMDAはその出自ゆえに、UMLの印象を強くひきずっている。UMLを使わない基盤はMDAツールとは多少呼びづらいところがある。

　そこで、UMLの印象を取り払った、業務システム向けのMDAを表す用語としてあえて「仕様書駆動アーキテクチャ(SDA,Specification Driven Architecture)」を提唱したい。この基盤を利用することで、仕様書を書くだけでシステムが動作する。仕様変更したいのであれば、文字通り仕様書の内容を変更するだけで、システムのふるまいがダイナミックに変化する。開発時だけでなく保守フェーズにおいても、その生産性は圧倒的だ。

　この効果はおもに「仕様書を眺めながらのプログラミング作業」の多くの部分が、コンピュータによる自動処理に置き換わったゆえにもたらされている。それはちょうど音源制作において「五線譜を眺めながらの人手による楽器演奏」の多くの部分がコンピュータによる自動演奏に置き換わったのと同じ効果だ。ある種の痛みをともなうとはいえ、これはコンピュータの利用にともなってさまざまな分野で起こり続けている「ふつうの変化」のひとつに過ぎない。

■鍵は「設計力」

　用語の意味として「仕様書にもとづいてシステム開発が駆動される」と説明されると、なにやらウォーターフォールの説明のようだが、SDAによってプロジェクトは必然的にアジャイル化する。設計～動作検証のサイクルが極端に短いからだ。ただし、イテレーションを繰り返しさえすれば良いシステムが出来上がると考えるのはアマい。SDAにおいても、プロジェクトの成否の鍵を握るのは「設計力」だ。生産性の高い基盤であるゆえにこそ、この本来のボトルネックがよりアカラサマになるといってもいい。

　この理屈を理解するには、プロミュージシャンではないあなたが映画音楽を制作することを想像してみればよい。DAWを使って延々とイテレーションを繰り返しても、プロデューサーが対価を払いたくなるような作品は完成しないだろう。なぜなら、作り手に作曲・編曲に関する技術やセンスが欠けているからだ。同様に、クライアントが対価を払いたくなるシステムシーケンス（仕様書）を完成させるためには、基盤がSDAだろうが何だろうがシステム設計に関する技術とセンスが要る。

　じっさい、イテレーションを繰り返すことで改善されるのはせいぜいUIまわりの使い勝手やデータ項目の欠落くらいで、これらはシステムのごく限られた一面に過ぎない。業務プロセスや帳簿組織、そしてその上で動作するデータ処理機能の切り分けと配置等、端正かつ適切に設計されるべき要素はあまりに多い。

　この仕事を担う人材は、私が「設計できるプログラマ」と呼ぶ技術者で、けっして潤沢にいるわけではない。しかし、人材の少なさは大きな障害にはならない。壮大なオーケストラ曲の音源さえ、DAWを使えばたったひとりのミュージシャンによって制作可能である。同様に、SDAの圧倒的生産性ゆえに、複雑な業務システムもたったひとりの「設計できるプログラマ」によって制作できてしまう。SDAはそんな「本来の技術力で稼ぐ時代」の到来を告げるものだ。

このブログでの参考記事：
「モデル」としての仕様書