2013年8月の超高速開発コミュニティ発足から関わって足掛け6年、当初は予想していなかった名称変更というイベントにも立ち会うことになりました。
上のプレスリリースにもあるように、"世界市場との歩調を合わせ…” というのが主な理由です。実際のところ、国内で業務アプリケーション開発に携わっている関係者の方々には "超高速開発” という言葉は知られてきたと実感しています。しかしこの考え方は日本でしか通用しないというものではなく、海外製品は "ローコード開発プラットフォーム” として認知されているという事実がありました。一般の方に "超高速開発とローコード開発って、何が違うの？” と混乱させないために、ここは名前を変えてでも市場への普及・啓蒙活動を優先させるという判断になりました。
会員の方からは「せっかく知られてきた言葉を捨てるのは、もったいない」という惜別の声もありました。それを無視したわけではありませんが、幹事会での議論は最終的に現状維持よりも変化することを選んだ、ということです。私も悩みましたが、今は支持する立場です。Wagbyもこれからは超高速開発ツールではなく、ローコード開発ツールと言い換えます。（ついうっかり、超高速開発と言い間違えるかも知れませんが、時間が解決してくれることでしょう。）
超高速開発とローコード開発は本当に同じもの？
私がいろいろ調べた範囲内では、厳密には同じではないかな、という印象です。超高速開発はどちらかというと「設計情報重視」でしたが、海外勢力によるローコード開発の意図は「ビジュアルプログラミング」にあるようです。マウスでアイコンを並べることでプログラムを表現する、というのがわかりやすいイメージです。
そう書くと生粋のプログラマの方からは速攻で反発されそうです。表現がソースコードなのかアイコンなのかという違いは本質ではなく、書くべき処理（ロジック）は同じなので、アイコン化することで簡単になるわけでもなく（つまり非プログラマが使えるわけでもなく）生産性が何倍も向上するとは思えない…と。
その視点は間違っていないと思います。その上で、この手のツールが提供するビジュアルプログラミングは、あくまでも機能の一部である、というところがポイントだということに気づきました。原則は、やはり設計情報がキモになります。では設計情報 + ビジュアルプログラミングのメリットは何か。二つあります。
一つ目は「影響調査分析の精度が高い」です。よくあるスクラッチ開発の現場では、Excelに自由文章で仕様を記述し、プログラマがこれを解釈しています。ここで仕様記述の曖昧性はよく問題となるところですが、それはひとまず置き、もう一つの仕様変更問題にフォーカスしましょう。現状では、ある仕様を変更したとき、この影響がどこまで広がるのかという影響調査も自動化できていません。つまり人力で行なっています。これがエンドユーザには「項目を追加するだけの変更で、予想以上の金額を請求された」という不満につながっています。しかしツールを使うと、各パラメータが論理的につながっているので、即座に影響範囲を把握できます。理論的にはビジュアルプログラミングで書かれたコードも、この影響範囲の調査に含まれるはずです。これは大きなメリットです。
二つ目は、品質の均一化です。よく指摘されることは、Java で開発する案件では人材を集めることが容易だが、特定のツールを使う案件だと人材確保が困難な上、余分な学習コストもかかるではないかという点です。その通りなのですが、しかしここには Java 開発者のスキル差という問題があります。これは書かれたコードの品質に直結します。多くの開発現場では、テストが通れば品質クリアと解釈しているようですが、その後の保守工程で、ばらばらな品質のソースコードを管理するのは大変な労力です。しかしツールベースの業務コード作成は自由度が削減される代わりに、個人のスキル差を埋めます。ちょっとしたことですが、業務系は長期間の保守が求められるため、わかりやすいコードは貴重です。初期の学習コストを十分に回収できるメリットと思います。
つまりローコード開発は、これまで超高速開発できる理由としてアピールしてきた設計情報中心の世界観をさらに拡げると解釈できるもの、と考えています。
