ビジネスプラットフォーム革新協議会(第26回勉強会)でお話してきました。

昨日(9月3日)、同会の定例勉強会で講演させていただく機会がありました。テーマは"21世紀型アプローチ"ということでしたので、新しいシステム内製化の持論をお話してきました。
http://b-p-i-a.com/?p=1695

f:id:ynie:20130904084743j:plain
(写真は、参加いただいた片貝さんが Facebook にアップしたものを拝借しています。)

その前の勉強会はサイボウズ青野社長が kintone を、さらにその前は Sapiens と、私が存じ上げているツールがとりあげられています。それも踏まえ、当日は Wagby の機能紹介ではなく、Wagby の根底にある技術的な思想についてお話することにしました。この方が、各社の特徴がより明確になるだろうと考えました。

1990 年代に脚光を浴びた CASE はなぜ失速したのか

CASE (Computer Aided Software Engineering) は当時、脚光を浴びたものの、20年を経た現在まで残っているものは少ないといえます。ゼロではないですが、期待に反して市場は成長しませんでした。いったい何が問題だったのでしょうか。私の持論は次のとおりです。

  • 利用者もベンダーも「完全性」を求めすぎた。
  • CASE が生成するソースコードのカスタマイズ性が低かった。
  • 汎用機からオープン系(クライアントサーバ)そしてWebアプリケーション、HTML5、スマートフォンと、この20年の間に主流アーキテクチャは変遷しているが、これに追随することはベンダーにとって大変な負荷であった。

完全性とは、どのような要求にも耐えうるということですが、それは汎用性のあるプログラミング言語でコーディングすることと大差がなくなります。それでは利用の難易度も上がります。汎用性を犠牲にすると、要求を満たすために(ツールが生成したソースコードを)カスタマイズする必要が生じますが、当時は「(生成コードが)読みにくい。」「一度(生成コードに)手をいれると、ツールが使えなくなる。」という問題がありました。

ただ、これをもって「だからCASEはダメなんだ」という結論は尚早と思います。そもそもCASEが登場した背景は何だったのか。それはソフトウェアの品質改善や、生産性向上でした。そして現代でも、これは未解決の問題だという認識を持っています。

もう一つ、4GL はどうなったのか

CASE と時を同じくして脚光をあびた技術に 4GL がありました。第一世代(機械語)、第二世代(アセンブラ)、第三世代(手続き型)とした上での第四世代の位置づけは何か。Wikipedia にはこのように記載されています。

3GLはプログラマに大きな力を与えたが、同様に4GLは一般の人々に開発環境を開放した。

http://ja.wikipedia.org/wiki/4GL

つまり 4GL とは非プログラマでもエンタープライズアプリケーションを構築できるようにするための言語、という位置づけです。

ただし Wikipedia の同じページをみると、4GL の例として IBM の RPG から始まり、クライアントサーバ全盛期に流行した PowerBuilder や、データベース問合せの SQL, PL/SQL、アプリケーション開発言語としての Genexus、そしてウェブ開発として Ruby on Rails まで含まれています。これらが本当に非プログラマでも使えるものか、という視点では疑問を感じます。4GL はマーケティング用語になってしまい、実際には 3GL と大差ないのではないかというのが個人的な印象です。

4GL の思想は DSL に引き継がれた

非プログラマによるアプリケーション開発ということでは、「仕様記述言語」が望ましいでしょう。これは DSL (Domain Specific Language) として知られています。これは汎用言語と対比され、ドメイン固有 - つまり専門特化したものです。例えば HTML は、Web ページを表現するための DSL と考えられます。

ところが、エンタープライズアプリケーション全体を包括的に表現する DSL というものは、まだ確立されていません。部分的にはあります。BRMS と呼ばれるビジネスルールエンジンへの入力となる業務ルールのようなものです。

このDSLは、欠点ではないですが、本質的に次のような問題を抱えています。

  • DSLが表現できるものは限定的であり、(アプリケーションの要求をすべて満たすためには)汎用プログラミング言語との組み合わせが不可欠であるが、そのバランスが難しい。

つまりDSLはまだ試行錯誤している技術です。うまいバランスを提案できるかどうかが鍵になります。

そしてジェネレーティブ・プログラミングへ

私は CASE が目指した「(自己完結型の)完全性」ではなく、もはや境界があいまいな 4GL でもなく、非プログラマが理解できる DSL からコードが生成できる開発環境に可能性を見出しています。それはジェネレーティブ (Generative)、つまり生成的なプログラミング手法として知られているものです。

ジェネレーティブプログラミングを支えるにはオブジェクト指向言語をベースに、DSL、パターン、フレームワーク、メタプログラミングなど多くの要素技術が必要です。実現へのハードルは高いですが、目指すゴールは次のようなものです。

  • 実際にシステムを使う人(ユーザ)自身が DSL によってシステム全体を構築。
  • 生成されたソースコードを、専門家であるプログラマが補完する形でシステムが完成。
  • DSL はドキュメントの役割も兼ねるので、目の前で稼働しているシステムのドキュメントは常に最新。

このような開発・運用環境は、昨今注目されている「アジャイル開発」「DevOps」といったキーワードとも相性がよいものです。また、ソースコード生成型であればブラックボックスではないので、運用環境も多種多様になります。オンプレミスでもクラウドでも動作させる環境を手に入れることもできます。

私たちが提供している Wagby とは、この「ジェネレーティブ・プログラミング」環境を提供する具体的な製品の一つ、です。他にも類似の製品はあります。先月に立ち上がった超高速開発コミュニティでは、当社を含め、このような思想をもった製品がいくつか含まれています。

ちなみに私は通常の営業活動でこのような話をすることはありません。昨日は研究会という位置づけだったので、長々とこういう話をさせていただいた次第です。(滅多にない機会でした。)

ジェネレーティブな開発環境がもたらすもの

このような環境では、利用者自身がアプリケーション設計に関与できます。これが私が考える、新しい社内アプリケーションの内製化を支える基盤です。

ここではソースコードではなく、DSLそのものが資産になります。これを「リポジトリ」と呼びます。リポジトリのバージョン管理だけでなく、なぜこういうリポジトリになったのかという開発過程までも記録できる環境を提供できれば、前任の設計者からの引き継ぎも、よりスムーズになると期待できます。

そして最大の資産は(このブログの冒頭に掲載した写真が、プレゼンテーション最後のスライドなのですが)DSL を書ける人材です。このような方を社内の情報システム部門で育成することで、内製化が可能になります。カスタマイズ開発者は必ずしも抱える必要はなく、外注しても構わないでしょう。

私が不定期に参加しているシステムイニシアティブ研究会の発表で毎回、うなづいていますが、社内システムの内製化は経営陣と現場の満足度が高く、PDCAサイクルがうまく回りやすいです。内製化を実現する手法もさまざまですが、ジェネレーティブな開発基盤は有力な候補になると考えています。

発表終了後は、多くの有益なアドバイス、コメントをいただくことができ、嬉しかったです。ご参加いただいた方、また事務局(協議会)の皆様へ、このブログを借りて改めて御礼申し上げます。