OutSystemsでの開発
～画面遷移・データ取得・パフォーマンス改善の要点～
OutSystemsはローコードで生産性の高い開発ができる一方で、使い方によっては動作が重くなることもあります。
特に、画面遷移やデータ取得の工夫によって、ユーザー体験が大きく変わります。
今回は、OutSystemsでのアプリ開発におけるパフォーマンス最適化方法を3つ紹介します。
1. 画面遷移の最適化：ページ分割とOnInitializeの使いすぎ注意
よくある課題
- 画面遷移が遅くなる
- 初期表示で大量データを一度に読み込む
対策ポイント
- 大きな画面は分割する
→ 入力フォーム＋確認画面、一覧＋詳細を別ページに分けることで、初期レンダリングを軽量化。 - 必要な処理だけをOnInitializeに書く
→ 初期表示でAPIや重いクエリを実行しない。必要に応じてOnAfterFetchを活用。
Tips
- 複雑なデータ取得は別画面やポップアップに分離
- 画面遷移時にローディングスピナーを表示し、UXを保つ
2. AggregatesとSQLの使い分け：高速化の鍵は取得対象の明確化
基本の使い分け
| 手法 | 向いている場面 |
|---|---|
| Aggregate | シンプルな検索・一覧表示（UI連携に強い） |
| SQL | 複雑な条件、結合、パフォーマンス重視の処理 |
チューニングポイント
- Aggregateでも条件を明確に指定する（例：IsActive = True）
- 無駄な結合（Join）を避けることで取得時間を短縮
- SQLを使う場合は「Only Retrieve What You Need」（必要なカラムだけ）
Tips
- 画面側に渡すデータは最小限に
- SQLクエリで重い集計処理を行う場合はタイムアウト対策も検討（例：Timeout拡張や非同期化）
3. 不要なFetch Dataを減らす：見えない負荷を可視化せよ
よくあるミス
- 複数のWidgetがそれぞれ独自にデータ取得
- 一覧画面とフォーム画面の両方で同じデータを取得
対策アプローチ
- 共通のデータはローカル変数 or Session変数に保持
- 画面内で同じデータを何度もFetchしないよう設計
- Pagination（ページング）で一度に取得する件数を制限
Tips
- Data Fetchingは「必要なときに必要な分だけ」が原則
- Listのデフォルト取得件数は50件 → 本当に必要？
→ パフォーマンス重視なら20～30件で様子を見る
まとめ：高速化は「減らす」「分ける」「見える化」から
| 課題 | ベストプラクティス |
|---|---|
| 画面が重い | 画面を分割、OnInitializeの見直し |
| データ取得が遅い | AggregateとSQLの使い分け、条件最適化 |
| 無駄なFetchが多い | 取得の共通化、件数制限、遅延読み込み |
OutSystemsの魅力は「早く作れる」ことですが、それは「速く動く」こととは別です。
パフォーマンスを意識した設計ができてこそ、本当に価値あるアプリになります。
