ローコード開発は、近年多くの企業が注目するシステム開発の選択肢となっています。従来のフルスクラッチ開発と比べてスピード感があり、業務部門とエンジニアが密に連携しながら開発を進められる点は大きな魅力です。
しかし、そのローコード開発の最大の魅力である『手軽さ』と『速さ』により「品質は二の次になりやすいのでは？」という声を耳にすることもあります。

実際にプロジェクトで開発・運用を担当しているフォリウムのエンジニアにヒアリングした結果、「ローコード開発だから品質は妥協する」ということは全くなく、むしろローコード開発だからこそプロダクトの品質向上に集中できるという声が多く挙がりました。
またクライアントからも、曖昧な要件に対して、スピーディかつ柔軟に画面モックやPoCを提供できることで、具体的な要件を詰めていくステップに貢献できているという声をいただいています。
本記事では、ローコード開発の取り組みとそれを支える設計フェーズでの工夫、そしてエンジニアの実感を交えながらお伝えしていきます。

「既存踏襲」という選択

商材受発注システムのリニューアルプロジェクトを担当したエンジニアは、こんな工夫を語ってくれました。

既存ロジックはすでに運用・保守も踏まえた上で実装されているはずなので、なるべく踏襲しながら開発を進めています。
『新規で作る』場合、既存の運用・保守の仕方とは別の新たな運用・保守の仕方を追加で考慮する工数が発生してしまいます。効率よくマイグレーションできるように、このような余分な工数は極力発生させないように注意しています。

この「既存踏襲」というアプローチは、一見保守的に思えるかもしれません。しかし、実はこれこそがローコード開発における品質保証の核心なのです。
従来のスクラッチ開発では、既存システムを理解し、それを新しい技術で再現することに膨大な時間を費やしていました。

例えば、レガシーシステムの複雑なSQL文を解読し、それを新しい言語やフレームワークで書き直すだけで数週間を要することも珍しくありませんでした。
ところが、ローコード開発では状況が劇的に変わります。OutSystemsのような環境では、既存のデータベース構造を視覚的に確認でき、テーブル間のリレーションも直感的に把握できます。

また、既存の業務ロジックを一旦簡易的な形で再現し、実際に動作を確認しながら理解を深めることが可能です。商材受発注システムの担当エンジニアが語った例がまさにこれを表しています。
これは決して「既存システムを真似する方が楽」という意味ではありません。
既存システムの理解を深めながら開発を進めることで長年培われた既存システムのルールを正確に再現し、業務ロジックの適合性を正確に担保しながら迅速に移行できることを意味しています。

UI実装における品質への配慮

ローコード開発ではコストや機能性の制約から、一般的にはユーザー体験（UX）が犠牲になりやすいという課題があります。鋼材管理システムの開発を担当したメンバーは、ライセンス料削減という制約の中で品質を保つ工夫を教えてくれました。

AO（ApplicationObject）数の削減が課題でした。Entity（エンティティ※1）や画面を増やすとAOが増え、OutSystemsのライセンス料が上がってしまうため、それらをできるだけ軽減したかったようです。しかし、システムの機能性も下げたくないという思惑もありました。
これに対応するため、Visible（ビジブル）プロパティやタブウィジェット等を使用し表示条件を切り替えることで、２～３画面分の機能を１画面内にまとめました。

この事例は、ローコード開発におけるUI品質の確保が、単純な機能実装を超えた判断力を要することを示しています。コスト制約という限られた条件下で、いかにユーザビリティを維持・向上させるかという課題に対して、効果的・効率的な画面設計により解決策を見出しています。

また、海運の船舶管理システムの保守を担当したエンジニアは、プロジェクトの担当者へユーザビリティ向上の改善案を提案しました。

引き継がれた段階で画面に使われている配色に統一性がありませんでした。
そこで、表示内容ごとの配色ルールを設定しプロジェクトの担当者に提案したのち、CSSで細かくカスタイマイズして適用したところ、使いやすくなったとプロジェクトの担当者や実際に使用する船員の方から好評を得られました。

この経験は、ローコード開発においてもUI設計の仕様が限定されることなく他の技術との組み合わせで実装でき、利用者にとってのサービス品質の向上につながることを教えてくれます。

これらの事例から、ローコード開発においてもエンジニアの工夫により単なる機能実装ではなく、ユーザー視点に立った判断力や工夫によって、制約を乗り越えつつ、高品質なUIを実現できることがわかります。

※1　エンティティ：
　OutSystemsにおいて、データベース内に情報を保持し、データベースモデルを実装することを可能にする要素。
　これは、データベースのテーブルまたはビューとみなすことができる。

複雑な処理をどう乗り越えるか

標準機能だけでは解決できない複雑な要件への対応は、ローコード開発の品質を考える上で最後の壁です。
ここまで書いたとおり、複雑な要件を実現するためにフォリウムのエンジニアたちは積極的に工夫を重ねています。

例えば、ある大規模案件ではAggregate（アグリゲート ※2）の限界を超えるデータ処理が必要になり、SQLで直接クエリを書き直しました。多数の参照テーブルとの結合処理やサブクエリによる集計結果も必要となり、標準機能のAggregateによるデータ取得ではユーザビリティに影響を与えることが示唆されたためです。これにより、標準機能だけでは実装が困難だったデータ取得のパフォーマンスを改善することができました。
「ローコードの標準機能で十分」という固定観念に捉われず、クライアントからの要件を満たすために適切な技術を選択し、難題を乗り越えた一例と言えます。

別の開発事例では、標準コンポーネントでは表現できない動きを実現するためにJavaScriptを組み込み、ユーザー体験を損なわずに要件を満たしました。

クライアントから要望のある高度な機能は、既存のウィジェットやForgeだけでは実装が難しい。
だからあえて自分でJavaScriptなどのコードを書いて実装することで、クライアントが望む挙動を実現することができました。

ローコード開発はあくまで「効率的に品質良く開発するための土台」であり、そこに+αで技術を組み合わせることによって複雑な業務要件にも対応できます。重要なのは、OutSystemsが標準で提供する「当たり前品質※3」（動作する、バグがない、要件を満たす）を超えて、期待以上の価値や感動を生み出す「魅力的品質※4」を追求することです。
ローコード開発+αの「α」において、どの技術・知識を使ってクライアントの要望を叶えるかが、エンジニアとしての腕の見せ所とも言えるでしょう。

※2　アグリゲート：
　OutSystemsにおいて、データモデルの変更を自動的に取り入れる標準的なデータ取得機能。
　サーバーからローカルデータベースのデータを読み込むことができる。

※3　当たり前品質：
　使えて当然と思われる基本的な機能や正確さのこと。欠けると大きな不満につながる。
　（動作する、バグがない、要件を満たす、など。）

※4　魅力的品質：
　なくても困らないが、あるとユーザーが喜んだり感動したりする工夫のこと。
　（入力補助、使いやすいデザイン、など。）

まとめ

今回、フォリウムエンジニアのヒアリングから見えてきたのは、ローコード開発において以下の価値を提供しているということです。

1. 機能の再現性、つまり既存の機能要件に対して高い品質を確保する仕組み
2. ローコードでの実装をベースに、＋αのカスタマイズによるUIの品質改善
3. 「当たり前品質」で満足せず、「魅力的品質」を目指す開発技術

ローコード開発は、エンジニアが「当たり前品質」を効率的にクリアし、より付加価値の高い「魅力的品質」を追求するための強力な土台であると言えます。

会社や組織を支えてきた基幹業務のシステムを見直す必要が出てきたときや、小規模でも新しい業務システムを構築してビジネスを立ち上げるとき、ローコード開発を取り入れることも考えてみてはいかがでしょうか？