システム導入が爆速に？ 「超高速開発」の出番ってどこですか？：本当はうさんくさくない、超高速開発のリアル（4/4 ページ）

[高橋一成，ITmedia]

超高速開発についてのよくある質問

　最後に、超高速開発についてのよくある質問と回答を紹介します。

Q1：簡単なものしか作れないんでしょ？

　「簡単な画面しか作れないんでしょ？」という意味ならば「YES」です。「React」（※9）で作るようなスーパーリッチなアプリケーションと超高速開発を比較するのはお門違いです。

　ただ、既に述べた通り、超高速開発は「簡単な画面を組み合わせて複雑な処理を実現する」ことがモットーであり、「簡単な業務しか実現できないんでしょ？」という意味であれば、答えは「NO」です（もちろん限界はあります）。

Q2：アプリケーションの性能は？

　フルスクラッチで同様の機能を作るよりも、体感できる程度には悪いことがあります。

　アプリケーションの性能が悪い理由の多くは「遅いSQLが実行されているから」ですが、JOINを多数行うとか、どのインデックスを使うか制御しなければならないようなケースでは自動化にも限界があります。

　また、超高速開発ではビューを多用します。例えばデータ表示画面では、テーブルのデータそのままではなく、同時に計算結果も表示することがよくあります。そのとき、画面仕様に一致したテーブル定義があると簡単に画面を自動生成できるため、「都合のよい」ビューを作っておくというテクニックが用いられます。しかし、ビューは性能悪化の要因として嫌われるものでもあります。この点でも性能悪化を招きやすい性質があるといえましょう。

　また、ほとんどの製品では、自動生成された遅い処理を、手書きのSQLないしコードによってオーバーライドすることも可能ですが、最小限に抑えるべきです。

手書きのコードは、設計情報とはリンクされておらず、テーブル定義が変わるたびに、手で修正が必要になるからです。そのような箇所が増えれば増えるほど、超高速開発の「うまみ」の1つである保守性の高さが損なわれていくことになります。

Q3：現行システムと完全に同じものを作りたいんだけど

　モダナイゼーション案件でよくある質問です。答えはズバリ「無理です。諦めましょう」。“割り切ること”を受け入れないと、超高速開発を採用するメリットはありません。

　ベンダーの立場からすると「現行システムの仕様と、候補となる超高速開発製品による」という中途半端な回答になるのでしょうが、そういう往生際が悪い回答をすることが、この連載の趣旨ではありません。

Q4：誰でも簡単に使えるの？

　いいえ。超高速開発は、アプリケーション開発の一通りの知識を持ち、要件定義や基本設計を行うエンジニアの生産性を最大化するための技術です。

　自動化の範囲を超えた複雑な業務ロジックを実現するには、JavaやJavaScriptを用いたプログラミングが必要ですし、データモデリングのスキルを持たない人が、ユーザーの目で見える範囲の画面ベースで話を進めてしまうと、最終的にはトンデモナイものが出来上がってしまいます。

　“DIY的使い勝手”をうたう製品は、非エンジニアでも利用可能です。ですが、やりすぎると最終的には「熱海の建て増し旅館」状態（※10）になります。これに近い例を皆さんも見たことがあるはずです。そう、Excelの“VBA地獄”です。

まとめ

　第1回目となる今回は、超高速開発について次のように整理しました。

• フルスクラッチ開発でもパッケージ導入でもない、第3の選択肢である。
• 30年以上の歴史がある。
• ある種の万能ツールを目指したが無理だったので、現実路線に落ち着いた。
• ご利用は計画的に。それなりの妥協を受け入れることで真価を発揮する技術です。

　少しは超高速開発への印象が変わったでしょうか？

　次回はケーススタディーを中心とした議論を展開していきます。どんな内容でもけっこうです。是非とも連載へのフィードバックをお寄せください。

---

※9：　Facebookが公開しているJavaScriptのフレームワーク。高度にインタラクティブな画面を比較的簡単に作ることができる。

※10：　前掲の白川氏の書籍の表現を借りています。無計画に増築していった結果、複雑怪奇な構造になってしまったことを指しています。

著者プロフィール：高橋 一成

ルート42 代表取締役。

大学卒業後、某NTTデータ子会社、ウルシステムズ、フリーランスエンジニアを経て、2009年にルート42株式会社を設立。趣味は合気道とお酒とキーボード（楽器ではない方の）集めで、もはや骨董品の5576-003を愛用中。