Scaffold としてのWebAPI

電子情報通信学会SWIM研究会の皆様、

　本日はお招きいただき、本当にありがとうございました。
地下３階で電波がまったく入らないのを知って、デモ中心から、急遽ウケ狙いの漫談と
プレゼン資料に切り替えさせていただきました。
　
　正直言って、当方、ノリノリで楽しんでしまいました。
今回は、ソフトウェア工学関係のご聴衆も多く、平均年齢も予想したより高めでした。
お話はできませんでしたが、数年前まで、要求工学国際会議に出たり、要求を抽出、洗練するためのWBS(Work Breakdown Structure)のグループウェアの研究開発をドイツでしていたりしたので、もし懇親会に参加できれば、さらに皆様とお近づきになれたように思います。

　Requirements led Project Managementを著したRobertson夫妻とも直接議論したことありますし、ドイツのFraunhoferソフトウェア工学研究所長Prof. Dr. Dieter Rombachと国際長電話で丁々発止の議論をしていた時代もありました。

　本日お伝えしたかった最重要のメッセージは、標記のとおり、
「Scaffold としてのWebAPI」です。

プログラミングのプロを自認する人ほど、Ruby on RailsのScaffoldによる自動プログラミング、メタプログラミングを「大したことない」と軽視する傾向にありますが、私は決してそんなことはない、メタプログラミングで、各種のソースを一貫性もって自動生成する能力は凄まじい、と評価し
ています。

Scaffold : Ruby on Railsで自動生成されるコード
　・RJS (Ruby-generated Javascript)
　・DSL (Domain Specific Language) なら多くを自動生成しやすい

Webアプリケーションという大くくり、大分類のものも、Domain Specificということができるので、RoRが受け入れられるのは当然だった、ということができるでしょう。

講演の主題「ScaffoldとしてのWebAPI」：
　
「独自サービスのコア機能以外はWebAPIで済ませてしまい、早くサービスインするのが吉。
　
もうこれにつきます。

昨日も一昨日も、RoRのコミュニティや会社を訪問したのですが、弊社の「マッシュアップ」文化にどっぷり浸った状況を再認識する結果となりました。それくらい、蓄積したノウハウ、スキル、志向性が違う、ということであります。同じ言語を使っていても。

「Userからのフィードバックが早くなり健全にサービスが育つ」
そうです。利用者からみて、なんのこだわりもない、どうでもいCommodity機能をわざわざ自前で作る必要はない。それこそWebAPIで間に合わせておき、必要が生じた時点で自前のモジュールで置き換えれば良い。
　
　その前に、ともかく、アプリ全体としてしっかり動くように、１刻（＝２時間）も早く開発するにはマッシュアップ以外の選択肢はない。
本日の基調講演で、私はこう断言しました。
　
　その際に頭をよぎったのは、過去、何年も研究本体の成果が出ないのを、中間発表の機会を与えるように国際学会が開催されていた事実です：　
Tools for AI
　
　当時何年もかけて、例えば自然言語処理なら、検索や意味処理をする前提として形態素解析、構文解析を開発していました。しかし、今の若者は、形態素解析APIを２，３時間で理解して組み込むことで、その晩のうちに、本業の研究を進めることができるのです。　
　凄まじいスピードの差です。
　　
　これを肝に銘じて、若い人々に対して謙虚に接し、対等にスタートラインにたっている認識をすると共に、昔の（AIなどの）失敗を知る者らしい知恵を発揮して世のため、人のため、貢献しなければならない、と認識を新たにしました。