« 「動的参照関係」を手なづける | トップページ | 仕様書でシステムが動く時代へ »

2009.11.19

「個別案件」ではプログラミングの可能性を生かせない

 ソフト開発企業に所属するプログラマが十年一日のように「個別案件」を相手にしているというのは、マイケル・ジャクソンが盛り場あたりで毎晩「流し」で日銭を稼いでいるようなものだ。もったいない。そんなやり方ではマイケルやプログラミングの可能性がもたらすさまざまな効果を享受できない。

 仮にあるソフト会社が「ロボットの振る舞いのカスタマイズサービス」を提供しているとしよう。顧客の要望がそれぞれ微妙に違うとすれば、彼らはまず個々の要望を様式化して、その内容をあるソフトウエアに読ませるだろう。そうすればそのソフトウエアが個々の要望にしたがってロボットを動かしてくれるからだ。そんなソフトウエア、すなわち「ハードウエアドライバ」をあらかじめプログラミングしておくのが、その事業で効率的に稼いでゆくための賢いやり方というものだ。

 ところが、現在の「基幹業務支援システム開発事業」の分野では、あらかじめドライバをプログラミングすることなく、個別案件毎に人海戦術でアプリ開発がなされている。上記の喩えでロボットの制御プログラムをいちいちゼロから作っているようなものだ。批判されがちな多重下請構造もそのことの結果のひとつでしかないし、顧客にとっても業務システムは高額でリスクの高い投資対象となってしまっている。

 つまり、ドメイン向けアプリケーションを汎用的に制御できるドライバ(DSLの発展形として「アプリケーションドライバ」と呼びたい)が、この分野では欠如しているのである。以前の記事で、この業界で「モデルシステム」が流通していないのは異常だと指摘したが、アプリケーションドライバの欠如はその原因のひとつでもある。なにしろいちいちアプリケーションをプログラミングするのだから、モデルシステムを作るにも手間がかかりすぎる。

 アプリケーションドライバがあれば、アプリの製造過程は「個別案件向けアプリのプログラミング」から「個別案件向け設定データの編集」に変化する。この工程をはたから見れば「ドメイン特有の知識体系にもとづく設計作業」にしか見えない。ところがその成果物をドライバに読ませると、要件どおりのアプリケーションがいきなり立ち上がる。続くテスト工程は「コードの品質」ではなく「設計情報の品質」を検証するためになされる。

 では、現在あるさまざまなフレームワークはアプリケーションドライバではないのだろうか。それらを用いて作業する様子を眺めればすぐにわかる。その作業が「詳細設計作業」ではなく「プログラミング」に見えるようであればアプリケーションドライバではない。言い換えれば、そのフレームワークを用いながらも詳細設計作業の後でわざわざプログラミングしなければいけないとしたら、筆者の言うアプリケーションドライバではない。このソフトウエアは、詳細設計工程とプログラミング工程とが分離されているという「発展途上ゆえの矛盾」を解決するものなのだから(*1)。

 つまりアプリケーションドライバは、「開発・保守の生産性を格段に向上するツール」であるだけでなく、システム開発のスタイルや事業体制までも変えてしまうほどのインパクトを持っている。今後、この分野でもアプリケーションドライバが生み出され、活用されるようになるだろう。以前の記事でも説明したように、組み込み型スクリプトエンジンをはじめとして必要な実装技術が揃ってきたからだ。

 いずれにせよ、「何をプログラミングするか」が決定的に大事という話だ。「個別案件」を相手にするばかりではプログラミングは「役不足」に過ぎる。対象をメタへずらそう。それによってプログラミングという営為が本来持っている破壊的パワーが引き出せる。


*1.アプリケーションドライバによって個別案件におけるプログラミング工程が大幅に削減されるとはいえ、ゼロになるとも思えない。筆者が開発しているドライバを使った場合でも、詳細設計情報の中にスクリプト言語で記述される部分が含まれるし、処理パターンにはずれた特殊な機能については従来どおりのプログラミングが必要になる。しかし、従来のような人海戦術的プログラミングはもう要らない。

|

« 「動的参照関係」を手なづける | トップページ | 仕様書でシステムが動く時代へ »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「個別案件」ではプログラミングの可能性を生かせない:

« 「動的参照関係」を手なづける | トップページ | 仕様書でシステムが動く時代へ »