ソフトウェア開発自動化が目指すべき姿

自動化ツールを使ったプログラミングレスなシステム開発、という流行病（はやりやまい）は数年おきに出現します。10年ほど前で言えばCASEツールがありました。もっと大昔では、シグマ計画（プププ）ではSPACEなるプログラミング自動化システムが最上位ツールの一つとされていたようです。

何らかのツールに一定の形式で要件定義情報を入力すると、アプリケーションのソースコードが完全に自動生成される、というのが、最近（昔から？）よく見かけるソフトウェア開発自動化ツールの見果てぬ夢幻です。本当にそれをやろうとすると、一定形式の要件定義情報を書くこととソースコードを書くこととの複雑さの差があっという間に埋まってしまって自動化ツールの存在が無意味化するだろうということは、きちんとしたプログラミング経験のある人間であれば誰でも本能的に察知できます。

gccやjavacのようなコンパイラがソースコードをマシン語に変換する自動化ツールであるならば、その進化形として、一定の人間語で書かれた文章と図面をソースコードに変換する自動化ツールもあってしかるべきだ、というレトリックもときどき見かけます。残念ながらそれも、中国の古い故事で言うと論理の飛躍です。ソフトウェア開発はそれほど単純なものではありません。

しかし意外にも、そうした銀の弾丸と青い鳥を探し求める傾向を、ITを使う側でではなく、IT業界の内側でちらほら見るので世の中不思議です。ITの使い方を知らないIT業界人も思いのほか存在するのです。

逆に、ITの使い方を心得たうえで自動化ツールをうまく使う企業や個人もいます。と書いてから自分のことを書くのはものすごくおこがましい（ので深くはつっこまないでほしい）ですが、私の開発したmixer2では、JDK6に標準添付されているxjcコンパイラというツールを使って自動生成したJavaソースコードを大量に使っています。XML(XHTML)という分野では非常に有効な自動生成ツールの一つだからです。

著名なプログラマの一人である小野さん率いるアプレッソ社の主力製品は、DataSpiderというデータ連携のための自動化ツールです。特定の分野において、自動化ツールを使う側ではなく自動化ツールを作る側に立ち、しかもその価値を認められて10年以上にわたり生き残っていることこそ、ITにおける自動化のなんたるかを正しく心得ている証左でしょう。ちなみに彼のブログで個人的に好きなのはバグは夜更け過ぎに仕様に変わるだろう(2007年)です。

10年ほど前、インターネットバブルに踊り莫大な赤字を垂れ流す怪しげな本屋がありました。彼らは、物理的な電子回路と仮想的な電子回路とをリアルタイムに相互変換するという不可思議なツールの価値を正しく見抜き、使い方を磨き、その結果、世界有数の先進的なITサービス企業へと変貌を遂げました。Amazon Web Serviceです。大した根拠もないピーク予想値と少ない予算という不条理のなかで、HDD容量を自動見積もりするexcelシートと向き合い納品リードタイムを気にする必要はなくなりました。ハードウェアを、いや、ミドルウェアをも、ボタン一つで増減できる自動化ツールがそこにあるからです。

10年ほど前、一人の日本の若者が渡米し、XMLというデータ形式を取り扱うコードを書きまくりました。それが現在のJava6のJAXB-APIであり、先述のxjcコンパイラもその副産物です。その道程で、彼は自らの仕事に集中するために、逆に本質的ではない煩雑で退屈な仕事を自動化するためのツールを作り上げ、親しみをこめてhudsonと名づけました。現在のJenkinsです。バックエンドデータストアとしてRDBMS等に頼らず、XMLそのものの柔軟性を最大限に生かすことによって、導入と運用のハードルの低さを実現した自動化ツールの登場です。優秀な執事たるJenkinsにビルドとテストを任せることはこの業界のデファクトとなりました。来週に迫ったJenkinsユーザ・カンファレンス2012東京（at市ヶ谷 法政大学）の参加者は1000人を超えつつあります。

ソフトウェア開発自動化が目指すべき姿とはなんでしょうか？

ここまでのように私がクドクドと書くまでもなく、先人がすばらしい示唆を残してくれています。それを紹介して、このエントリを終わりましょう。

ソフトウェアアーキテクトが知るべき97のこと オライリージャパン (2009) より クリエイティブコモンズ 表示3.0に基づく全文の転載。（太字は転載者によるものです）

煩雑なことを非属人化し、創造性を高める
萩原正義

ソフトウェア開発の完全な自動化は目指すべきではありません。

DSL（ドメイン特化言語）のスコープを十分に小さくし、生成コードの実行をWebアプリケーションの特定フレームワークに限定すれば、完全な自動化は可能となるでしょう。しかし、この自動化はDSLのスコープが限定された小さな問題領域と特定の実装技術に対してのみに有効であって、一般のソフトウェア開発が対象とする広範な問題領域、実装技術の選択肢に大して有効な解とはなりません。

それでは、問題領域を小さな部分問題に分割して、それぞれの部分問題を解くためのDSLを複数組み合わせる方法や、逆に1つのDSLのスコープを広げて汎用性を高める方法でのソフトウェア開発の完全な自動化は 可能でしょうか？

前者は分割したDSL間での依存関係や相互作用がまったく存在しない「直交化」した問題に関しては可能となるかもしれませんが、一般にはこのような単純な問題は少ないでしょう。後者は、DSLはもはや汎用開発言語の範疇になり、一般のプログラミングによる開発となんら変わりがなくなり自動化は難しくなるでしょう。

DSLやその他の開発ツール、モデル駆動型開発は、繰り返し起こる煩雑な開発を自動化することで省力化を行うためであって、ソフトウェア全体を自動化する目的で使うべきではありません。それほどソフトウェア開発は単純なものではありません。 また、問題領域あるいは解決領域のスコープ自体も、ビジネスの進化、ソフトウェア技術の進化、要求の変化によって、固定的な定義で収まるものではありませんから、ソフトウェア開発の自動化の対象領域自体の前提も成立しなくなります。進化しないソフトウェアはいずれ価値を失い、自動化の有効性はなくなるでしょう。

このように間違った目的を目指して技術を適用しようとしても失敗することは歴史が証明しています。進化するビジネスや技術、変化する要求の中で、不変の規則、原理を発見し、この規則と原理に基づき自動化するならば有効な解となるでしょう。不変の規則と原理は繰り返し現れるので、煩雑さを非属人的な 方法で省くことが可能となります。

その上で、創造性や進化が求められる部分に人間の知的作業を集中させることで、ソフトウェア開発の工業化が可能となると考えます。ソフトウェア開発の工業化を大規模な製造の自動化と考えるのはよく見られる誤りです。ソフトウェア開発での工業化は、人による創造性や知的作業と自動化の分担で実現し、その意味では、ソフトウェアは完全な工業製品というより、むしろ人の創造力を含んだ工芸品を目指しているといえなくもないでしょう。

技術と創造力を融合したソフトウェア開発の在り方は、筆者の考える「ソフトウェア工芸」の捉え方の基になっています。