職業プログラマの休日出勤

職業プログラマによる日曜自宅プログラミングや思考実験の成果たち。リアル休日出勤が発生すると更新が滞りがちになる。記事の内容は個人の意見であり、所属している(いた)組織の意見ではない。

超高速開発 体験談

数日前に日本で話題になっていた「超高速開発」について記事を残したいと思います。ニュース記事
超高速開発はスクラッチ開発の3倍から10倍の開発効率が条件、競合するベンダ13社が利害を超えて「超高速開発コミュニティ」を設立 - Publickey
はてなブックマーク に寄せられたコメントを見る限り「食わず嫌い」な方が非常に多いように見受けられたので、これは体験談の需要は高そうだなと思い、書き始めた次第です。
ネタ記事を書いた直後に真面目な記事を書くのは、少し気が引けるものではありますが…。

私は2006年初頭から2012年初頭まで、インフォテリア社製の開発ツール「Asteria」を使用していました。この製品には冒頭で紹介した記事からもリンクが張られていますが、超高速開発を実現するためのツールの一つです。もちろん、私がAsteriaを使用していた頃は「超高速開発」などという言葉は見たことも聞いたこともありませんでした。
Asteriaは、いわゆるプロプライエタリな開発ツール&実行環境であって、ライセンス価格などの都合上、個人開発者が自宅で使えるような代物ではありません。そのため、残念ながらネット上に出回る情報も少なめです。

このAsteriaを使って、私は企業内で使う情報システムを、裏方(バッチ処理など)からUIを伴う部分(Webアプリなど)まで、数多く手がけてきました。

注意事項

この記事において「超高速開発ツール」について言及している内容は、このAsteriaについての事柄が中心です。他の同様のツールでは、もう少し状況は異なるかもしれません。また、当然のことではありますが、ここで述べている内容は私個人の意見や感想であって、過去/現在の所属先などの見解ではありません。
更に、ここで述べている内容の多くはしっかりとした検証を経てのものではなく、経験則から導かれたものです。効果には個人差(チーム差?企業差?)があることが十分考えられます。
Asteriaの短所について触れている部分は、(私が知らない間に)バージョンアップ等によって改善している場合もあります。そういった点がもしもあれば、ご指摘頂ければ幸いです。

商売文句 - 実際のところ

超高速開発ツールが宣伝/営業されるとき、大抵、以下のような内容が謳われます。

  • 素早い開発
  • ノン・コーディング

これらの商売文句について、少し触れたいと思います。

素早い開発:どれくらい速いのか

多くの場合、速いのは本当です。じゃあ、どれくらい速いのでしょうか?
簡単な2つの事例について、Javaで開発した場合と比べてみましょう。なお、サーバのセットアップ時間などは考慮しません(既存のサーバに機能追加することを想定します)。

◆バッチ処理
貴方の目の前に、2つのRDBがあるとします。一方のRDBに格納されたデータを、簡単な加工をしながら他方のRDBにinsertする、という処理を考えます。元のテーブルと先のテーブルはカラム構成は「似たようなもの」であるとします。

Javaであれば、大まかには、以下のような処理が必要でしょう。

  • RDB2つに接続
  • SELECT文の実行
  • 1行ずつ取り出しながら、値を加工しながら、他方のRDBにinsert
  • commit/接続の切断など
  • エラー処理(rollbackなど)
  • ログ出力/完了時のメール配信

最後の1つを除けば、1時間程度もあれば開発完了するような内容です。
ログ出力やメール配信は非常に面倒臭いですが、恐らく2時間あればできるでしょうか。理屈の上では非常に簡単なこれらの処理ですが、例えば log4j を使うとなれば、その初期化の処理を思い出しながらor調べながら書いたりすることになります。メールについても似たようなことが言えます。
合計3時間程度ですね。

これがAsteriaになると、必要な処理は以下のようになります。

  • トランザクション開始の定義
  • SELECT文の実行
  • 値の加工(Mapperというものを使います。これがイイ!)
  • insertの実行
  • commit
  • エラー処理(rollbackなど)
  • ログ出力/完了時のメール配信

恐らく、全部で30分もあれば作れると思います。
ログ出力に至っては、「何もしなくても」仕組みが備わっています。我々がやることは、ログ出力すべき文字列を所定の場所に渡してあげるだけ、です。

ざっくりではありますが、この事例においては「6倍」程度の速度があると考えられます。
この事例はとても小規模なので大きな差が開きますが、もっと大規模になるとどうでしょうか。Javaで書いた場合のコストの多くは、log4jやメール配信のために必要な「初期コスト」です。規模が大きくなる(作るものの種類が増えることではなくて、量が増えること:ここでは、データ移行させるテーブルの数が増えること)と、これら2つの手段の間のコストの差は、相対的には小さくなっていきます。

◆Webアプリ
バッチ処理では大きな差がつきましたが、今度はUIを伴うシステム、Webアプリだとどうでしょう?
※AsteriaではWindowsやLinuxやMacなどのデスクトップでネイティブ実行させるアプリを開発することはできません。あくまでサーバ側です。個々のクライアントに操作をさせる場合はWebアプリの形式を取ることになります。

まず初めに言えることは、HTML作成部分(MVCのViewに相当する部分)は、Javaで作るのと大して変わりません。Asteriaでは velocityテンプレートエンジン が採用されています。JSPを書くのよりは随分と楽ではありますが、velocityはJavaのものですので、これはAsteria独自の優位性ではありません。

次に、MVCのModelとControllerに相当する部分なのですが、Asteriaではこれらを分けて作っていくのは非常に難しいものがあります(私が良策を思い付いていないだけかもしれませんが)。しかしながら、これらの開発効率の差はバッチ処理と同等です。

以上をまとめると

  • 速いのは本当。
  • 「速さ」の大部分は、初動の速さ。
  • HTML作成に関しては、既存の言語と大して変わらない。

といったところでしょうか。

もちろん、Asteriaを使った方が遅くなることもあります。そういうプロジェクトは大抵、そもそもの要件定義/基本設計に大きな問題を抱えているものです。詳しくは後述の「弱点」の項へ。

ノン・コーディング

Asteriaをはじめ、いくつかの開発ツールでは「ノン・コーディング」を謳っていますが、これは「ほぼ」本当です。グラフィカルな操作と、処理の部品に対するプロパティの設定だけで処理の定義ができます。
もちろん、例外はあります。代表的なものは以下の通りです。

  • 複雑なSQL文を実行したいとき、そのSQL文は書く必要があります。
  • 特殊な数値計算をしたいとき、その処理はプログラミング言語で書く必要があります。例えば対数を取る、など。
  • 前の項で既に似た内容に触れていますが、Webアプリを作るとき、HTML / CSS / JavaScript は自分で書く必要があります(これらを書くことをコーディングと呼ばない文化も存在しますが…)。

まあ、これらの例外を考慮したとしても、「ノン・コーディング」を謳っているだけのことはあります。初めてツールを使う人でも、それまでにまともなプログラミング経験があれば、すぐに覚えて使うことは可能です。

ところで、この「ノン・コーディング」という言葉、当然ながらこれは「プログラミング経験が皆無でも使える」という表現とは同義ではありません。残念ながらこれらを同義であると捉えている人が多い気がします。

どんな人なら使えるの? - 必要となる技術力や知識

商売文句に対するお話はここまでにしておきましょう。

それでは、どのような知識があればAsteriaのようなツールを使いこなすことができるのでしょうか?
私は、以下のような知識が必要だと思っています。

  1. プログラミング言語不問だけど)制御構造を自然に使いこなせること。ifとかforとか。三項演算子とか。
  2. 一般的なIT用語とそれらの概要(例えば「ログ」とか「SSL証明書」とか…)
  3. ある程度のRDBMSの知識(バックアップ/リストア等の運用のあれこれや、ACIDが云々とか)
  4. 使用するプロトコルについての基礎的な知識(例えばHTTP使うなら「HTTPはステートレスなプロトコルだよー」、といった感じ)
  5. 作ろうとしているものについての知識(業務要件)

そう、Asteriaのような超高速開発ツールは、「誰でも開発できるようにする為のツール」なんかではなく「知識のある人が楽をするためのツール」なのです。
また、これだけで良いということは、ユーザ系企業に務めているシステム管理者でも真面目に基礎的な事項を勉強していれば十分に開発に手が届く範囲になるのです。私としては、ぜひそういう方々にも利用して欲しいと願っています。「内製の為のツール」でもあるのです。

弱点

多くの方が想像している通り、超高速開発ツールにも当然ながら弱点があります。ツールが想定している使い方から外れた使い方をすると、途端に難しくなるのです。
例えば、動的に生成された数百MBものデータを HTTP Client に転送する(ダウンロードさせる)処理を考えます。通常、AsteriaからHTTP Clientに何かをダウンロードさせるときは、そのコンテンツを一旦メモリ上に展開させることになります。AsteriaはJavaVM上で動作する仕組みですから、そんなところで数百MBのデータをメモリ上に持たせるとどうなるでしょうか?容易に想像できますね。JavaでWebアプリを組んでいるとしたら、途中でバッファをフラッシュさせる操作をするところですが。
開発中のシステムがこの状況に陥ったならば、基本設計からやり直しです。通常のJavaなどでの開発よりも遅くなってしまいそうです。

言いたかったのは、「ツールが想定している使い方から外れた使い方をすると、途端に難しくなる」ということです。
もちろん、Asteriaをはじめ各社のツールも、バージョンを重ねるに従って、想定外の使い方への対応を広げているように見えます。こういった弱点は減少傾向にあると見て良いでしょう。

その他の小話

主に愚痴です(笑)

顧客企業

冒頭で紹介した記事の はてブ のコメントの中には、超高速開発ツールを使っていたら顧客企業から安く買い叩かれるのでは?と危惧する声もいくつか見られましたが、そんなことを危惧するような取引関係においては、こういったツールを使っていても使っていなくても買い叩かれます。心配無用です。いや、かなり心配ですね(笑)

SIer

私が所属していたSIerでは、それなりの数のプロジェクトで超高速開発ツールを導入していたことからノウハウもかなり蓄積されていて、ツールの特性も上手く捉えており、「SIerにしては」まともな使用方法をしていました。もちろん、中にはダメダメなチームも見受けられましたが。。

非常に困ったこと

超高速開発ツールを使う上で非常に困ったことは、(私自身の所属先でもあった)人材派遣会社が「超高速開発ツールを使える」人材を、派遣先であるSIerに投入しようとしてきたことです。多くの場合、彼らは超高速開発ツールを使ったことはあるけれども、他のプログラミング言語の経験はほとんど無いし、私が中学高校レベルの数学の話をしなければならない状況にも何度も陥ったし、挙げ句の果てには「HTTPとは何ぞや?」という問いにも言葉を詰まらせる人達です。前述の「必要となる技術力や知識」をほとんど有していない人達です。もちろん中には例外も居ますが、本当に失望したものです。
超高速開発ツールの特性を正確に深く捉えていなければならないはずの会社が「完全に」勘違いしていた訳です。

失敗事例

これは私自身の失敗ではありませんが。
超高速開発ツールで使うプログラムを自動で生s…
おっと、来客のようだ。こんな時間に誰だろう…??

…という冗談は置いといて、こういうノウハウを諸事情により共有できないのは、普段OSSに触れている人間からすると非常に鬱陶しいですね。これも大きな弱点です。なお、この弱点は超高速開発ツール特有のものではなくて、これらのツールが機密保持契約を伴い易い環境で主に使われていることに起因するものであります。
将来何かに変化が起きて、こういう失敗事例を詳細におおっぴらにできるようになってくると、超高速開発ツールについての実際の情報が出回るようになって導入し易くなり、普及が急速に進むんじゃないかなと思っています。

メトリクス計測

Asteriaには、普通のプログラミング言語でよく実施される、メトリクス計測に相当する機能はありません。
それを自作したときの苦労話がこちら → 未開の地でもメトリクス - 職業プログラマの休日出勤
この辺も整備されてくると嬉しいですよね。

まとめ : 最も言いたかったこと5つ

  • 速いのはほぼ本当。小規模プロジェクトで特に顕著。
  • 「ノン・コーディング」もほぼ本当。「コーディング能力が無くても使える」は大嘘。この2つの言葉を読み違えてはならない。
  • 超高速開発ツールは、「誰でも開発できるようにする為のツール」ではなくて「知識のある人が楽をするためのツール」または「内製の為のツール」である
  • 筆者のケースでは、超高速開発を進める上で一番邪魔だったのは顧客企業でもSIerでもなく、人材派遣会社だった。
  • 失敗事例が赤裸々にインターネット上や勉強会などで語られるようになったとき、爆発的に普及し始めると見込まれる。

追記 on 13-Aug-2013 12:10AM頃 AEST (UTC+10)

はてブを沢山頂いたようです。ありがとうございます。
さて、はてブを通して頂いたコメントのうちのいくつかに、この場で回答を差し上げたいと思います。
※話を逸らしますが、Australiaでは午前0時(真夜中)のことを 12AM と表記し、午後0時(正午)のことを 12PM と表記するのが一般的です。

比較対象が酷過ぎるんじゃないの??

Javaを比較対象にしたのは、そもそもアレじゃないの?という意見もありましたが、Asteria自体がJava上で動いていることと、Asteriaがシェアを奪い取るのは現在Javaで動作しているシステムからであるだろうと考えたことからの判断です。
生のJavaを比較してしまったことについては、そうですね、ORMとか入れた方が良かったですね。

log4jとの比較について

log4jは思い出しながら書くのにAsteriaを使う学習コストはまったく無視して」
良いご指摘です。
私の主観になりますが、log4jについて理屈を覚えて実装(初期化処理ですよ)の経験を積んでも、数ヶ月後や数年後に改めて実装する時にはマニュアルを見ないと書けません。その一方で、確かにAsteriaは初期学習コストはかかりますが、理屈さえ知っていれば特にマニュアルを見ずともそれが可能です。そう、これがGUIの力だと思います。

初期学習コストについて

はい、かかります。
チュートリアルひと通り(今では分量が変わってるかもしれませんが)こなすのに数日かかるとは思いますが、ほとんどのプログラマの方は、これだけこなせば十分に使うことができるようになると思います。

この手のツールは、そもそもクソである

とは、私自身も2006年に初めて触れたときに感じました。どんだけ汎用性を殺しているんだ!!と。誰だこんなの採用したのは!と。
恐らく、アセンブラやってた人がC言語を初めて見たとき、似たことを感じたんだろうなーとも思います。
しかしながら、長い時間触っていると、次のことに気付きました。
この手のツールをクソだと感じるとき、そもそも基本設計などに重大な誤りや無茶が潜んでいることが多いのです。
もちろん例外はありますが、まるでAsteriaが設計書レビュアであるかのような感覚に陥ります。

フレームワークと一緒だね

はい、その通りであると私も考えてます。激しく同意です。
初期学習にコストがかかること、慣れてくると開発効率が上がってくることなどなど、共通の性質は挙げ出すとキリがありません。

実行速度について

遅いんじゃないの?というご指摘がありました。確かに少し遅いですが、極端にスレッド/ソケット数が多い環境だとか、極端にデータ量が多い環境とかでない限りは、十分に実用的な範囲に収まります。
どんなスペックのサーバで、どんなプログラムの内容で、どんな数値がでるのか、とかを共有していくことは重要ですね。データ量はどれくらいまで大丈夫なのか、とか。
しかし!私がこのへんの数値に触れるのは色々な事情により、控えさせて頂きます。。

あと、こういうアーキテクチャに起因する遅さよりももちろん、ダメプログラマが作った酷いプログラム(Asteriaならフロー)の方が、圧倒的に悪い結果を導き出します。皆さんも経験ありますよね? O(n) で済むはずの処理が O(n^2) で実装されてた、とか。。
そう、Asteriaは、こういうダメプログラマを雇わなくて済むためのツールでもあるのです(と言っても、油断してるとそういう人材を突っ込まれるので注意!!)。

その他
  • Asteriaはソースコードの自動生成ツールではありません。開発環境 兼 実行環境です。
  • Data Spiderも紹介したかったところですが、記事を書けるほど私が詳しい訳ではないのです。ゴメンなさい。
  • 定量的な評価を提示できていないのは私の力不足によるものですが、弱点である「想定外のことをすると途端に難しくなる」という性質はバージョンアップを重ねるごとに減少傾向にあります。主にそれは「想定」を広げることによって…。。
  • やっぱり情報が出回ってないことと、体験するためのハードルが異常に高いのが最大の普及阻害要因だなー、と感じた次第です。