ここ数年、超高速開発という言葉をよく聞くようになってきた。いくつかの製品が発表されただけではなく、「超高速開発コミニュティ」の設立されたり、日経コンピュータでも「広がる超高速開発」という記事が取り上げられるなど、ひそかにブームが起こりつつある。
とはいえ、そこで紹介される素人でも開発、高い生産性、といった文句をうたった技術・製品というものは、RAD、ビジュアル言語、CASEツールといった名前で1960年代からずっと存在し、人工知能と同じように流行っては廃れてを繰り返してきたのも事実である。
私自身も以前から仕事でEXCEL設計書からのプログラム半自動生成フレームワークを作っていることもあり、とても関心の強い分野だ。
多くのプログラマは超高速開発を色眼鏡で見ているし、その認識の半分は全くその通りではあろうとは思う。開発の実務を知らない経営者や顧客にとっては、21世紀という時代にもかかわらずテキストエディタで意味のわからない呪文を書いてシステムを構築するという考えがとても非生産性的に見えるのもわからなくないのだが、GUIベースのWindowsが世界を制覇しそうに見えても、結局サーバサイドの勝者はテキストベースのWebとUNIX世界だったという事実からもビジュアルなものが常に優位なわけではないことがわかる。
数学者にとっての数式がそうであるように、ある一定レベルを超える複雑なロジックを構築し運用するにはテキスト・インターフェイスが最適なのだし、バージョンや差分の管理、共有性、安定性、いずれをとってもテキストファイルの有用性は否定しがたい。
では、やはり超高速開発はまた時代の徒花として消え去ってしまうのか、というとそうでもないのではないかと思っている。むしろ、長く潜伏していた時期を過ぎ、ようやく花開こうとしている感がある。
先日、ウォータフォール vs アジャイルという話題がまたさかんに議論されていたが、JUAS のソフトウェア・メトリックス調査の結果を見れば、議論すべきは、従来型開発 vs 超高速開発 の方であることははっきりしている。アジャイル導入で生産性が向上したという根拠は不明確な一方、まだサンプルは少ないものの超高速開発の生産性向上は2～3倍と圧倒的だ（ただ、この数値は圧倒的すぎて明らかに何らかのバイアスが発生していることはそのうち考察する）。
超高速開発が見直されている理由はいくつかある。
- 開発技術の複雑さが増している。HTMLだけ知っていればよかった時代と異なり、CSSやJavaScript、そしてその周辺の ES6, jQuery, React, Sass, Less, node.js といった各種Web技術に関する広範な知識が必要となった。超高速開発ツールの多くは、それらの知識に直接触れることなく開発できる。
- クライアント環境の自由度が増している。Windows XP、IE6しかなかった時代が終わり、HTML5の登場で規格の標準化が進んでいるとはいえ、IE, Edge, Chrome, Safari, Firefox といった各種ブラウザに対応する必要があるだけでなく、デスクトップ、タブレット、モバイル、はたまたテレビなど様々なプラットフォームにも対応を求められる時代になった。超高速開発ツールは、各種プラットフォームに自動で対応してくれる。
- 開発技術の自由度が増している。例えば、同じ Java 言語で開発といっても、違うフレームワーク上で開発されたプログラムには全く互換性がなく、知識やプログラムの流用が難しい。新しいフレームワークを導入するのも超高速開発ツールで開発するのも大差ない。
プログラマは超高速開発をビジュアル開発ツールの延長線上に捉えているのではないかと思っているが、おそらく超高速開発の本質はそこにはない（そういう意味では超高速開発という言葉自体が不適切なものである）。超高速開発をうたっているツールがもたらすパラダイムシフトはむしろモデル駆動開発が実現できるという点にある。
たとえば、超高速開発ツールでしばしば提供される機能として、画面ごとの滞留時間の自動計測がある。しかし、この「画面ごと」という単位は、それを考慮して開発を行わないと意外と難しい。MVCを使う場合、最終的に同じViewが表示されるかは、Controllerではわからない。次の画面に遷移しようとしたが、入力チェックにひっかかって前の画面に戻った場合は前の画面の滞留時間にカウントしたいなどの要件があると、簡単には求まらない。超高速開発ツールでは、まず「これは画面である」というモデルを定義し、そこから実際のプログラムを生成するため、どの範囲が画面のプログラムであるかというメタな情報を持つことができる。
こういった例もどうだろうか。モデル駆動開発系のツールであれば、データモデルを定義し、そこからDB上のテーブルの作成や、画面項目と更新先カラムの紐付けを行ったりできる。そのため、画面項目桁数や型がDB上のテーブルカラムの型と不整合がある場合エラーを検知することができる。通常のプログラム開発でこれを行うことは極めて難しい。
上述のクライアント環境やDBといったミドルウェアの違いに柔軟に対応できるのも、このアプリケーション・モデル駆動によりメタレベルの情報とプログラムの紐付けを行うことができる点に起因する。しかしながら、このモデル駆動であるという特徴は、別にビジュアル言語でしか実現できないわけではない。もしかすると、次の時代のプログラミング言語では、アプリケーションモデルの定義→ロジックの埋め込みが言語機能として組み込まれたものも生まれてくるのかもしれない。
