初めに

2024年9月でOutsystemsでの開発に参画して1年が経過しました。開発してきたのは主にReactiveWebによるWebアプリケーションです。
Outsystemsに触れる前まではPython、PHP、node.jsによるWebシステムのバックエンド側の設計・開発、Reactによるフロントエンド側の開発に携わってきました。フレームワーク等は用いてきましたがローコードツールによる開発はこれからが初めてです。
私は基本的にWebシステムのバックエンド側の設計・開発の経験が多く、フロントエンド側の知見は不足しております。

Outsystems(O11)を使って感じたこと

画面の作成

UIの作成は容易
基本的な部品（Widget）が十分そろっています。作りたいと思ったUIは容易に作成できました。基本的にパーツを画面にドラッグアンドドロップすれば必要な画面項目を配置できます。それに内部の変数をバインドすることで値の表、入力が簡単にできます。
これまでUIを1から作る経験が不足していた自分でも、それなりのUIが作成できているのではないかと思います。変数や関数などの基本的なことを押さえておけば、プログラム初心者でも簡単に画面を作成できそうだと感じました。
サーバとのデータのやり取りについて
サーバからのデータの取得するにはいくつかの決まりとベストプラクティスがあり、それに沿わない形で実装してしまうとServiceStudioのWarningや後述のAIMenterStudioの指摘が発生します。この辺りは勉強と慣れが必要なところだと感じました。ただ、それぞれのベストプラクティスは納得のいくものが多いので、指摘に沿って実装することでおのずとユーザとサーバにやさしい画面ができると思います。
高度なデザインの適用は控えたほうがいいかもしれない
UIパーツのアップデートが年に何度か実施されるため、そのメンテナンスコストがある程度必要になってきます。廃止されるパーツがたまにあるので注意が必要です。
また、jsでDomの変更やcssでデザインのカスタマイズができますが、上記のメンテナンスコストを考えると標準のデザインで済むのであれば大幅なカスタマイズは加えないほうがいいのかと思います。
また、画面上のバリデーションも基本的なものはそろっており、画面の項目間のバリデーションを追加したり、カスタマイズすることができるため基本的に困ることはなさそうです。
権限のコントロールは容易
画面単位で「誰でも」・「ログイン済みユーザ」・「特定のロール持つユーザ」などのアクセスを制限できるため、権限のコントロールは容易です。ただし、データへのアクセスなど厳密な制限をかけるには、ServerActionでの権限の確認が必要になります。

データの取得・更新

Aggregateは強力で便利
AggregateはDatabaseから情報を取得するための仕組みです。SQLで詳細を指定することもできますが、とても簡単に取得条件や件数などを設定できます。パフォーマンスチューニングやキャッシュなども自動で制御してくれます。
ServerActionでないとできないことがある
基本的にClientActionやScreenActionからはAggregate以外のデータの取得はできない。複雑な処理はServerActionとして実装する必要がある。その切り分けが分からず最初のうちは苦労した。
複数レコードの同時更新が複雑
SQLでは当たり前に実装できる特定条件のレコードの一括更新などは基本的な部品でサポートしていません。SQLを作成するかループで1件ずつレコードを更新する必要があります。

ServerAction

ループ、分岐など基本的な組み合わせが扱えればコーディングができる
例外・トランザクション・ログも扱える
実際にアプリケーションを運用するには、エラー処理やドラブルシューティングも必要になります。それに必要な例外処理、トランザクション処理、ロギングも簡単に扱えます。とはいえこれらも公式ドキュメントのベストプラクティスに合わせて要件にそって実装を落とし込む必要があります。この辺りはプログラミングが初めての人にも簡単に実装ができる部分ではないかもしれません。システム開発のイロハとして学習が必要なところかと思います。
REST APIの実装が簡単にできる
Timerによるバッチ処理が作れる
Timerによりバージョンアップのためのマイグレーション処理が作れる

デバッグ

ClientActionは容易にデバッグできました。ServerActionのデバッグが機能せず困っています。

テスト

ServerActionやClientActionに関してはBDDFrameworkにて自動テストを作成することができます。ReactiveWebアプリケーションに関しては、ScreenやBlockに関してはCodeceptjsなどブラウザの自動化を使ったE2Eテストを導入することができそうです。

インフラ

ある程度、一般的大きなシステムを組織的に開発運用していくにあたり開発環境、ステージング環境、本番環境と複数の環境を整備運用していく必要があります。LifeTimeというツールで管理が可能です。各環境へのデプロイやそのための権限の管理などができます。

チーム開発

マージの機能はお世辞にも十分とは言えないかもしれません。ブランチ戦略を用いた複数人での開発と同じようにはいかないなと感じました。４、５名の少数でコンフリクトを意識しながらの開発が必要になりそうです。

品質分析と技術的負債について

AIMenterStudioというアプリケーションの品質分析を行い、ベストプラクティスを提示してくれるコード解析ツールがあります。

不満に感じたこと

最後に簡単に不満に感じた点を挙げてみます。

Nullがない
コンフリクトの解消が大変
日本語の資料が少ない
資格認定試験の料金が高い
導入金額の敷居が高そう

最後に

当たり前ですが、これさえ導入すれば簡単に大規模なシステムが開発できるというものではありません。コーディングの負荷自体は下がるかもしれませんが、システムのライフサイクルや運用を考えた設計を実装に落とし込んだりと通常のシステム開発におけるノウハウも確実に必要になってきます。
何を目的にローコード開発導入するかはしっかりと考える必要があるかと思います。
１エンジニアとしては苦手なUIが簡単に作成できるのはとても助かっています。