はじめに

とあるローコードツールを10ヶ月ほど使ってみて思ったメリット・デメリットを書いてみようと思います。
営業妨害？になるかもしれないので何のローコードツールかは記載しません。
Eclipseで開発でき、Javaを自動生成できるものです。

私は当時4年目（Java2年、C#1年）。
特にローコードツールへのネガティブなイメージはありませんでした。
過去にHTML/CSS/JSを1から書いて画面を作成した経験があり、バックエンド以上に時間がかかって苦労したので、それが効率化できるのならいいじゃないか！と思っていました。

結論

デメリットの方が上回ります。
情報の得にくさや実装時の手間を考えると、Javaを使う方が効率的と考えます。

メリット①：モックを作成するのは速い

HTML/CSSを書かずとも、プルダウンをポチポチ選択してUIを作成できます。
慣れれば半日くらいで、お客様から提示されたラフ画をモックにできると思います。

部品がいろいろあって、驚いたのは一覧テーブルです。
ドラックで列幅を調整できたり、ドラック&ドロップで列を入れ替えられたり、列固定／解除、表示／非表示、ヘッダークリックでソートといった機能が標準で付いています。

メリット②：処理によっては楽に実装できる

登録・更新処理、CSV出力処理はローコードツールの方が楽に実装できます。
登録・更新処理はSQLを書かなくていいし、CSV出力処理は表示したい項目を列挙するだけです。

デメリット①：ネット上に情報がない

ネットで調べられないのはつらいです（もちろんChatGPTも使えません）。
PDFの公式マニュアルがありますが1000ページ超え。他にも何百ページのマニュアルが何ファイルもあります。
Googleで検索する時のような柔軟な検索はできず、ワードで検索すると何百もヒットして、知りたい情報を見つけるまでに苦労します。

また、一般的な言葉が使われていなくて苦労する場面がありました。
「前方一致」ではなく「先頭一致」だったり、「活性」ではなく「編集可」だったり、検索してもヒットせずかなりの時間を溶かしました。

デメリット②：ソースの見通しが悪い

すでにいろんな画面が作成済みだったので参考ソースを検索していましたが、結局見つけられないということが多々ありました。
1ファイルの中にタブがあって実質3ファイルくらいな見た目になっています。
行をクリックしないと表示されない設定値や処理があったりします。
Javaのように1ファイルが1ファイルだけで見通しがよかったら理解しやすかったのになぁと思いました。

検索一覧画面はよく作るので、どこかの画面をサンプルとして画面キャプチャを貼り付けて手順書を作成してあれば理解しやすかったと思います。
（自分で作成して、自分たちのチーム内に展開しました）

デメリット③：プログラミング経験がある人ほど直感的に理解しにくい

プログラミング未経験者なら直感的に理解しやすいのかは謎ですが…
ある言語やフレームワークを学んでいたら、他も似ているということがよくありますが、その想像力はむしろ邪魔をします。

UIの細かい調整をするのに、HTMLやCSSを知っていたら「似たようなプロパティがあるだろう」と思いますが、実際は全然違うものでした。
ビジネスロジックを書くファイルで変数に自由に値が入れられないというのもすごく困りました。

あとは具体例を忘れてしまいましたが、思い出したら追記しておきます。

デメリット④：使い勝手が悪い

ぽちぽちプルダウン操作するところはファイルをスクロールすると設定値も変わっちゃったり、ctrl+zで戻そうとしても戻せず、またたくさんの選択肢から選ぶ必要があります。

デメリット⑤：Javaならすぐに実装できる機能にものすごく時間がかかる

例えば検索処理を実装するのに、Javaだったら1日くらいで完成できると思うのですが、このローコードツールだと2〜3週間かかりました（勉強しながらやっていたこと、周りに質問できる人がいなかったこと、時間的余裕があったこともあります）。

入力値で分岐させて検索する（前方一致/後方一致/部分一致）とか、取得結果を格納して画面に表示するとか、画面遷移するといった処理にとてつもなく時間がかかりました。

分岐が複雑なものだと拡張機能のJavaで実装することが推奨されていました。
他にも、ListやMapを使って突合したりするような処理はJavaでないと無理だと思います。
拡張機能のJavaで実装していた時はノンストレスでした。

デメリット⑥：処理を1行ずつ進めて確認するようなデバッグができない

Eclipseを使って開発しているのですが、デバッグができません。
ログで値を表示するのみです。

デメリット⑦：Javaだけの場合より複雑

拡張機能のJavaで実装しており、とある処理が後で追加になったのですが、汎用部品がローコード標準機能でしか使えないものでした。
そのため、一部処理をローコード標準機能上に移動し、それに伴ってトランザクション方式も全て変更、明示的にロールバックする方法を得るのにとても苦労したというのが最近ありました。

標準機能でできること・できないことをしっかり把握する必要がありますし、拡張機能を使うにしてもどこからどこまで使うのか見定める必要があります。この判断や調査は難易度が高いです。
（プロジェクトとして資料にまとめてあればいいのですが）
追加内容によってはこのように広範囲な修正になります。

デメリット⑧：業務外で勉強ができない

個人学習として無償で使えるものではないので、他の技術のように業務外の時間を使ってキャッチアップができません。

デメリット⑨：開発経験として認められないのではないか

私は実際このローコードツールで開発してみて「二度と使いたくない」と思いました。
次の現場では絶対にローコードはやりません。
こんなに苦労しているのに、世間では「ローコードは簡単に、楽に開発できるツール」と思われていそうだし、このローコードツールを使っている現場でないと開発経験として認められないのではないかと思います。
（実際に転職エージェントとかで相談してみたわけではないですが…実際に聞いてみたら追記します）

ローコードツールは「プログラミング経験がなくても使える」とありますが、それなりに学習コストがかかります。私の体感ではJavaの方が理解しやすいのではないかと思います（学習教材やサンプルが豊富にあるので）。
これからエンジニアとしてやっていきたいというような未経験者、若手はもっと汎用性の高い技術を学んだり、経験した方がいいと思います。

これだけの労力を費やすならReactなどを勉強したかったです。ネットに情報があったり、自宅で学習できる分、キャッチアップは大変でないと思います。

さいごに

私はこのローコードツールしか触ったことないので、それだけで一概にローコード開発はダメですとは言えません。単に知識不足だったり、私に合わなかったのかもしれません。
誰でも簡単に開発できるものではなく、このローコードツール特有の知識が必要です。それを1000ページ超えの検索しにくいマニュアルの中から拾い読んでいかないといけません。
標準機能でできること・できないことをまとめたり、よく作成する画面は具体例を手順書化する、メンバーが増員したタイミングで勉強会をする、などというのが必要だと思います。