リファレンスモデルの重要性

渡辺さんの本を読んで、昨今の業務システムの開発におけるボトルネックは、プロジェクト管理でもなくプログラミング技術でもなくオブジェクト指向技術でもなく、実はデータモデリングではないか、と思った。
その時に、有用な設計モデルにリファレンスモデルが不足している理由について優れた指摘があったのが面白かったのでメモ。

【元ネタ】
渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - HOME

【1】ソフトウェア開発の歴史をさかのぼると、色んな設計手法が提唱されているにも関わらず、ソフトウェア開発がエンジニアリングと言えるレベルまで達していないように思える。

土木建築・工業に比べると、DOA・OOA・POAなどの方法論が乱立しているけれども、実際の現場ではどれも中途半端にしか適用していないのではないか？
だから、いつまで経っても同じような失敗を繰り返し、デスマーチを繰り返しているのではないか。

渡辺さんによると、システム設計で方法論が百家争鳴な理由はリファレンスモデルが欠如しているのではないか、と指摘する。

つまり、建築デザインや工業デザインでは、方法論と膨大な具体例がセットされて提示されている。
例えば、ピラミッドやローマの建築物から現代の高層マンションと併せて、その設計図が有償無償で手に入る。
音楽ならば、記法である楽譜とその手法がペアで提供されている。

しかしながら、業務システム開発では、例えば小売業界向けの業務システムのようなパッケージ製品(ERP)のリファレンスモデル(設計図)が提供されておらず、個人が入手するのは非常に難しい。
業務システムを設計するには何が必要か、その手法に関する書籍や情報があったとしても、そのサンプルが公開されていないのだ。

だから、いつまで経っても上流工程のスキルを身に付けるのが難しく、上流工程の作業に普通のPGがキャリアアップの中に組み込むのが難しい現状がある。

この状況に比べると、プログラミング技術は、そのライブラリと記法が書籍やネットなど、あるいはオープンソースで公開されており、やる気さえあれば個人がそのスキルを身に付ける事ができる。
普通は、サンプルソースや似たようなライブラリを真似ながら、プログラミング技術を身に付けて行く。
ゼロから書いていくスタイルは、もはや現代では少ないだろう。

実装技術としては、RailsやSeasarのような優れたフレームワークのおかげで、プログラミングのコストは非常に安価になった。

しかし、業務システム開発は、いつも最初からスクラッチ開発が多い。
肝心の業務モデリングという設計技術は今も昔も変わらない。
だから無駄が多く、同じ失敗を何度も繰り返しているように思える。

【2】渡辺さんの指摘で面白いのは、リファレンスモデルが欠如している理由の一つが、従来のパッケージ製品にある設計仕様をベンダーが公開しにくいから、という点。

理由は、実装コストがどんどん下がっている現状では、設計情報を下手に公開すると、最新のオープンソースのフレームワークで簡単に安く実装されてしまう危険があるからだ。

従来のパッケージ製品は、その時代の技術で実装しているため、オブジェクト指向やRailsなどのような最新の設計思想が取り込まれていない古い技術の塊。
中身のソースは非常に汚いだろう。

更には、特にベンダーのパッケージ製品は、多くの顧客でカスタマイズできるように膨大なパラメータで調整できるようになっている。
そのために複雑な設計でカスタマイズしにくく、公開したとしても割に合わないだろう。

だから、オープンソースで提供されるパッケージ製品は、ソースの中身が公開されているという特徴だけでなく、設計仕様そのものも公開されているという点で、重要な意味を持つ。

大抵のオープンソースのパッケージ製品は、シンプルな仕様で作られてるから可読性も高く、誰もがカスタマイズしやすい特徴を持つ。
たった一人のユーザ、あるいは会社が必要とする機能を実装した業務システムを、数多くのユーザが使って、バグを発見したり、UIや機能の改善要望を出す。
それらのバグ修正や機能改善を取り込んで、更にシステムがより良く育っていく。

業務システムは、たくさんの人に使ってもらえるほど知名度も上がるし、数多くのテストをユーザが自ら行ってくれる。
熱心なユーザの改善要望は、貴重な要件だ。
そのようなシステムのライフサイクルは、特にオープンソースの開発例でよく見られる。

【3】渡辺さんの指摘で面白いと思ったもう一つの点は、実装技術が安価になっていくのは必然であり、その結果、MDA(モデル駆動アーキテクチャ)も発展していくだろうということ。

実際、アセンブラやパンチカードの頃に比べると、今はTDDなどの開発技法、RailsやSeasarなどのフレームワークのおかげで、実装技術は非常に効率が高い。
これは、詳細設計とプログラミングが統合されていく傾向にあることを示している、と。

すると、設計モデルさえあれば、プログラムを自動生成する流れへ開発も向かうだろう。
実際、Railsの設計思想の中核をなすCoCなどは、まさにそれに当たるだろう。
これが、MDAの発想。

モデルもプログラミング言語で書いてしまえ、というMDAの発想は、Rubyのようにメタプログラミングの強い言語で威力を発揮すると思う。
いわゆるDSLはRubyの得意分野の一つだし。

渡辺さんの指摘で気付いたのは、MDAが実現できれば、開発者が昔から悩んできた「仕様書の保守問題」も解決されること。
設計モデルとプログラムが同期されているならば、動くプログラムを正として、リバースエンジニアリングすればいいだけ。

渡辺さんの言う通り、「仕様書の保守問題」は実装技術が発展途上だったが故に発生した現象だといえるだろう。

【4】MDAが今後の主流になっていくだろう、と言われても、肝心のモデルを作らなければ、実装できない。

渡辺さんは自身のHPで、「財務管理」「科目履修管理」「販売管理」「生産管理」「自治体」の5つの業務モデルを公開されている。
渡辺さん自身が作成された設計ツールXeadと併せて見ると良いだろう。

渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - レファレンスモデル

非常に参考になるので、渡辺さんの本と併せて読むのを勧めたい。
昨今なら、上記のリファレンスモデルでテーブルが定義されているから、RailsやSeasarを使えば一瞬で実装できるはずだ。