超高速開発技法 : ユニケージ開発


先日、ユニバーサル・シェル・プログラミング研究所http://www.usp-lab.com/ でユニケージ開発技法という開発手法・ツール(以下、勝手にUSPと略称)を見学してきました。面白いのです。技術的には、誰でもすぐに使えます。コストがさしてかかる訳でもありません。強力な開発方法なのですが、金融機関は新たな開発態勢や手法を追加することを嫌がって使わないだろうな?でも勿体ないな!と思いながら話を聞いてきました。

USPの特徴は、端的に言えばシェルスクリプトで直接Linuxを使う方法です。RDBは使わずテキスト・ファイルを利用します。複数のコマンドをまとめて実行するスクリプトは、機械語への変換を省略した簡易言語で、シェルは与えられた指示をOSの中核部分に伝えるソフトウェアです。ですから、余計なことを一切しません。その結果、ハードの性能の大半をアプリケーションが使えます。ですから速い。そして、使わない機能満載のライセンス・ソフトも要らない。コストと開発スピードは4分の一、処理速度は10倍というのが、一般的なベンチマーク結果だそうです。

Hadoopとベンチマークしても、はるかに速いそうです。何故?と聞きますと。「余計なことを一切しないから。作業ファイルも作らない。全て、直にOSを働かせる。」との答えです。インメモリーでテキスト・ファイルを必要に応じて並び変えても、DBMSのオーバーヘッドがない分、はるかに速いのです。特に計算とSortが圧倒的に速いとのこと。8年前にこのコラムで筆者が勝手に「Excelのお化け」と名付けて紹介したDayDaLabooというツールがあります。これはスプレッドシートのファイルをあっという間に、SortMergeしたり、演算処理するツールですが、唯一の難点はDatという特殊なファイルに変換する必要があり、それに結構な時間がかかることでした。(その後、機能も価格も大きく改善されていると聞きますが、直接確認しておりません。)USPの場合は、汎用的なテキスト・ファイルですから、ファイル変換は大きな処理遅延になりません。そのメリットを活かそうとRDBからテキスト・ファイルを作り、それをUSPで処理し、また、RDBに戻す仕組みを作った企業もあるそうです。

Linuxとシェルスクリプトだけあれば良いのですから、アプリケーションは論理フローだけで作れます。物理環境を考える必要がありません。ExcelのMacroで業務開発するイメージです。ですから、一人で設計−開発−運用ができます。コマンドをコピペしてテキストに落とせば、そのまま設計書となり、レビューできます。こうなるとプログラミングの外注も要りません。基幹業務アプリへのEUC適用を促進できます。大手を含めて小売業での利用が拡大しているそうです。何故、小売業かと言えば、コストに厳しいだけでなく、スピードが要求される、システムライフが短いなどの背景があります。コストを気にしない、スピードよりも正確性を担保する手続き重視、長いシステムライフの金融機関とは確かにビジネス環境が大きく異なります。

当初はバッチに使うことが多かったのですが、最近ではWebサイトのアプリ開発にも使いだしたそうです。そのためのシェルも開発され、エンドユーザーがwebアプリを作るそうです。ビッグデータに注目が集まりだしましたが、新しい技術を習得しながらビッグデータ解析するよりは、手軽に即座にビッグデータ処理するために、uspBOAという製品が開発されました。100億件のトランザクションから、1万件をマッチングセレクトするのに4.5秒、更新・削除・演算に5.5秒、6種の属性を指定した検索に1.2秒というデモを見た時には、余りの速さに、むしろ実感が湧かず、「もう少し遅く処理した方が、見る人が感激するのでは?」などと妙なコメントをしたくなりました。

USPは、2008年のIPA[ソフトウェア・プロダクト・オブ・ザ・イヤー基盤ソフトウェア部門]を受賞していますが、筆者は全く知りませんでした。金融の世界では、大手IT企業が提供する枯れた技術に関心が集まりますので、どうしても時代から遅れます。もう少し、素直に謙虚に新しい技術・手法に目を向けないと、あっという間にガラパゴスの両生類になってしまうと反省しながら、同社を辞しました。

このツールを以前から推奨しているベテラン・コンサルタントとUSPについて話をしました。彼は「種も仕掛けもない技術だから、ベンダーは儲からない。だから、大手はやらない。」と言っていました。しかし、フリーウェアやOSSが普及する時代です。ベンダーは、技術指導や研修で事業を維持するモデルを作るでしょう。売上、資本金、社員数を誇る時代ではありません。業容拡大の為に、できる限りの機能を追加して、高いフィーを取り、ユーザーとは関係ない処理にリソースを使いまくるのが今のTビジネス・モデルです。逆に、機能をそぎ落とし、必要最小限の機能だけで充分な業務もたくさんあります。この視点でアーキテクチャやITガバナンスを設計する必要があるようです。

                                                 (島田 直貴)