Old Articles

ローコードヤバイ

まともな技術者を確保することを諦めた SIer が「RPA」を経て「ローコード」「ノーコード」に走り出し、 あまりの香ばしさに笑いものにされていた「超高速開発コミュニティ」がいつの間にか「ローコード開発コミュニティ」に看板を架け替えてて久しい。 私も某国営 SIer 絡みで「ローコード開発」(笑) の共犯になることになってしまったので、 関わったローコード (笑) の特徴について後で語れるようここに感想を残しておこうと思った。

ローコード開発、またはノーコード開発はプログラム言語に関する専門知識が無くても既成の部品を組み合わせて 業務システムを実現することを目指したアプリケーション開発環境であり実行環境でもある。 小学生の授業で使おうという Scratch なんかもある意味ローコード開発と言える。

この手のローコード開発パッケージの数少ない利点としてはアプリケーションの開発から実行まで必要な環境がオールインワンで用意されるので 開発者は面倒くさい環境構築から開放され、アプリケーションの製造にのみ集中できることである。 ユーザ管理と権限、DB の構築、Web サーバとアプリケーションサーバの連携といった本題以前の糞面倒くさい部分をパッケージに丸投げすればいいというのは 地味ではあるが大きなメリットである。 特に SIer の案件で構築する環境はたいてい基盤となるサーバ、ネットワーク周りが意味不明なゴミカスで こっちが面倒見るべきではない箇所で無駄手間取らされるので、環境構築工程とも言うべき無駄手間を省いて即アプリケーションの開発を始められるのは 開発させられる身としては大変ありがたかった。

そもそも IT 業界でのローコード開発は SIer が素人の寄せ集めで作ったゴミにローコードライセンス (笑) でボッタクリ価格を上乗せするための言い訳用アイテムという扱いだが、 どちらかといえば過去に RPA による業務改善がそれなりにうまく行く程度にリテラシーのあるエンドユーザが自ら業務システムを構築する場合に効果を発揮できるように見える。 そしてそのようなユーザは概ね現実と妥協点の摺り合わせを心得ているので理想的とは行かなくともまあまあ悪くない程度にはうまく行くのだが、 そのようなユーザならローコードなんかに頼るまでもなく自社の社内 SE で分相応のシステムを開発しているのではないかという気がしないでもない。

ローコード開発はある程度型にはまった典型的な要件を満たすには大幅な開発コストの削減が期待できるが、 逆に凝ったカスタマイズが必要になるとあっという間に破綻するというところが短所になる。

私が関わった「ローコード(笑)」もご多分にもれずそのような特徴を持っている。 しかしそんな事はむしろ些細なことで、最大の問題点は肝心のローコード開発のパッケージそのものが素人によって開発されたゴミであること。 ブラウザ上でフローチャートを書いて詳細設計書がそのまま動くからプログラム不要ですよーという SIer の「いつものやつ」である。 特に致命的な問題は部品を配置してフローチャートを構築するロジック (他言語の感覚では関数、メソッド程度のスコープに相当) の面積が狭すぎること。 条件分岐や変数の代入、他の処理の呼び出しといった部品をフローチャートの要素として GUI 上に並べてプログラムを表現するのだが、 肝心のフローチャートを欠ける広さの制限が激しく、部品を限界の密度まで詰め込んでもせいぜい 200 個程度までしか配置できない。 しかもそこまで詰めてしまうと部品同士を繋ぐフローチャートの線が無茶苦茶な方向に自動配置されてしまって 処理の内容が全くわからなくなるため、実際には 100 個置ければ上等である。 100 個という数字はそれなりに多そうに見えるが、java や C、C# で 100 行でどれほどの機能が実装できるというのか。

もちろん処理がひとつのロジックに収まりきれなければ複数の部品に分割して相互に呼び出すことが出来、 この「ローコード(汗)」も個々のロジックを小さな「そけつごう」で作成しておいて相互に呼び出すという建前で設計されている。 しかし IDE で当たり前に出来るようなコード中を選択してメソッドの定義位置に飛ぶような機能はもちろん無く、 フローチャート編集画面から一旦一覧画面に戻り、呼び出し先のフローチャートを選択して編集画面へ… とモッサリした手順を踏まなければならない。 先に「関数、メソッド程度」と述べたが、他言語で言えば 1 つのソースファイルに1個の関数しかかけないようなものである。 感覚的には関数 1 個毎に Eclipse が個別に起動するくらいのモッサリ感である。

なおかつブラウザベースで実装しているくせにたかが画面遷移のリンクにも無駄にスクリプトを仕込んでいるせいで、 「新しいタブで開く」で両機能の編集画面を開くことも出来ない、複数の編集画面を開くには空の新しいタブを開いて URL をコピペしなければならないという馬鹿馬鹿しい有様である。

フローチャート編集機能自体の品質も当然のようにゴミだった。 フローチャート内の各部品に渡すパラメータ設定がいつの間にか壊れているのは茶飯事で、 プログラミング言語で IDE を使っていれば関数の引数が足りなかったり型が誤っていれば警告されるものだがこのローコードではそのような支援は一切なく、 しかもパラメータ設定はいちいち画面切り替えしなければ確認することができないため動作試験中におかしい動きを発見して 初めて消えているパラメータに気付くというのが多々あって困った。

かろうじてループの開始、終了の整合性が取れていない、java でいえば中括弧の開きと閉じの数があっていないような場合はエラーになるが、 フローチャート内の部品をコピペする際、ループ処理の部品を含んでいると内部的な関連付けが壊れるのか必ずエラーになって保存できなくなるという 割と致命的なバグが放置されている。

プログラムを構成する部品はフローチャートの他に SQL や JavaScript、あるいは PDF 形式の帳票の生成などの種類があって それらはいずれも入出力パラメータとして JSON と相互変換可能な階層構造のオブジェクトを使用する。 統一したインターフェイスで個別の部品を抽象化し、しかも JSON でパラメータを渡せるようにすることで単体テストの自動実行を想定しているのだろう。やるじゃん。 ……と思いきやフローチャート以外の部品はフローチャートからしか呼び出すことが出来ないので それ以外の種類の部品の単体テストをしようと思ったらわざわざテスト用のダミーのフローチャートを作らなければならない。 当然自動実行など対応しておらず、ブラウザで毎度ポチポチしなければならない。ガッカリだ。 まあフローチャートはバッチ処理として実行することも可能なので、自動テストも実現可能といえば可能なのだが……

パラメータといえば、この開発環境で扱う変数には一応データ型の概念がある。 実行環境が java で実装されているせいか変数の型も java 相当なのだが、内部的には全ての変数は Object 型で格納しており、 変数の型チェックはなぜか代入時ではなく参照時にキャストで行われるというイミフな実装である。

このような仕様になっているのは javascript 部品とのパラメータ入出力の都合で、javascript から返されたパラメータは型情報を持っていない (文字列と数値、オブジェクトくらいの型情報は返せたような気がするんだが……) ためらしいのだが、だからといって文字列で返されたパラメータをそのまま integer 型で定義した変数に代入できるのは頭おかしい。 しかも互換性の無い型で代入されていることは認識されていて 「文字列型 integer」 のような意味不明な状態になって toString 以外は受け付けなくなる。 そんなんするんだったら最初から代入時点でキャスト可能かチェックしろやと思う。

さらに、null の概念はあるのだが、フローチャート上で変数に null を設定する方法がない。 無理やり実現するには

のいずれかの方法を取る必要がある。いずれにせよ馬鹿馬鹿しいこと極まりない。 また、変数を操作する際にリテラル値は一切使えないので、演算処理なんかで DB や画面入力から取得した値以外を使用する場合は 全て定数として定義しなければならない。 0、1 といったごく基本的な値も例外ではなく、変数のインクリメントが必要なら

#define ONE 1

を定義して変数に ONE を加算しなければならない。 (C言語風に書いたが実際は「定数設定画面」でポチポチ設定する必要がある) もちろん true、false なんかも用意されていないので、

#define TRUE true
#define FALSE false

は欠かせない。ちなみに定数のスコープはフローチャート単位のみなので、ほぼすべてのフローチャート部品でこれらの定数定義をコピペするのが定形作業になっている。

現代的なアプリケーション開発では svn や git といったバージョン管理システムとの連携は欠かせないが、 ローコード開発はブラウザ上でポチポチ部品を並べているのでもちろんそんなものとは連携できない。 自分の開発環境で実装した部品を他のメンバーと連携するには zip 形式でエクスポートして共有フォルダで連携だ。 まるで 1980 年代に戻ったような懐かしい気分になれる。バージョン管理システムの元祖に近い rcs が 1982年、世界初である RCCS が 1972 年らしいので どうやら弊社の文明レベルは 1960 年代相当のようだ。

言うまでもなく diff や grep など使えるわけはないし、なんなら開発環境内でも変数や定数の参照箇所を検索するといった今時の IDE なら当たり前の機能だって無い。 ある部品に対してそれをどの部品が使用しているか、という検索はかろうじて可能なのだが、「どの部品か」までしかわからないので フローチャートが複雑化していればそこから頑張って探さなければならない。

一応ローコード開発内部でバージョンの概念はあるのだが、内部的にバージョンごとの「名前をつけて保存」しているに過ぎないので、 例えば A さんの環境で実装した ver.2 の部品を B さんが別の ver.2 を既に実装している環境にインポートすると コンフリクトが発生するのではなく、単に B さんの ver.2 が上書きで消されてしまう。 なお、エクスポートした zip ファイル内にどのような部品が含まれているのか、インポートするとどれが上書きされるのかと言った情報は 実際にやってみるまで一切知ることは出来ない。 zip ファイルを展開して中身を見てみたが、「エクスポート対象の全ての部品を1個の文字列にエンコードしたJSON」という頭おかしい構造だったので、 エクスポートした zip ファイルから含まれる部品を調べようと思ったら解析用のツール開発が必要になるだろう。 というかこういうのは zip ファイル内に 1 部品 1 ファイルで生成するのが普通だと思うんですがね。 何を考えてこんな構造にしたのか聞いてみたいものだ。

アプリケーションの開発には直接関係しないが、「開発画面をログアウト」→「ログイン画面に戻ったら再度ログイン」すると必ずセッションタイムアウトするという信じがたいバグが放置されている。 要はログアウトした時にサーバ側のセッション情報は破棄されるものの、ブラウザ側のセッション情報が明示的に削除されておらず しかもログイン画面でもセッションの有効性チェックが行われているのでクライアント 〜 サーバ間で不整合を起こしているのだが、 こんなバグが開発側にフィードバックされないはずがないので現場からのフィードバックなんか最初から黙殺するつもりか、 あるいは http の仕組みを理解していないため何がおかしいのかすら解っていないと思われる。 実業務に致命的な不具合ではないとはいえ、こんな基本的なところの対応も出来ていないものを商用パッケージとしてお出しするのはいかがなものかと思う。

さらにいえば、スクリプトエディタを開いているときもセッションタイムアウトは発生するので、 長めの javascript や SQL を書いていると保存するときには既にタイムアウトしており、頑張って書いた大作が消えてしまう事も当たり前なので フローチャート以外の部品を実装する場合はまずテキストエディタで書いて完成したらまとめてコピペするのが常識である。

語れば語るほど楽しくなってきたのでもしかするとこの「ローコード(爆)」を気に入ってしまったのではないかと思い始めてきたが 営業に騙されてこれに手を出す会社がたくさん現れると笑えることこの上ないので具体的な製品名は黙っておこうと思う。