OutSystems 開発初期にやっておきたい設計と準備

1. Architecture Canvas に沿ったモジュールの作成

OutSystems には、アプリケーションの構造を整理するためのフレームワークとしてArchitecture Canvas が提供されています。これは、Entity・Action・画面といった要素をレイヤーごとに整理し、再利用性と保守性を高めるための設計指針です。

Architecture Canvas は Reactive Developer BootCamp の学習範囲には含まれませんが、チーム開発では必須といえるスキルです。

→公式サイト : Reactive Developer Boot Camp の案内ページ

開発初期に Architecture Canvas に基づいてモジュールの構成を決めておくと、アプリケーション全体の役割が明確になり、実装時に迷いにくくなります。

なぜ開発初期に作るべきか

Architecture Canvas を初期に適用しておくと、次のようなメリットがあります。

• 初期にモジュール構成を固めておけば、後からモジュールを移動せずに済み、依存関係が壊れるリスクを抑えられます

• 処理をどのモジュールに置くべきか、判断基準がチームで統一されます

• レイヤー間の不適切な依存を防ぎ、保守性が向上します

設計手順

詳細な実践手順は以下の公式サイトでも紹介されています。

→公式サイト:アーキテクチャから開発へ

ここでは概要を整理して説明します。

1. 機能要件と非機能要件を整理する

利用する画面、業務処理、Entity、外部システム連携などをリスト化し、アプリ全体の構成要素を把握します。

2. Architecture Canvas に配置する

整理した要素を Architecture Canvas のレイヤーに沿って配置します。

Architecture Canvas では、アプリを構成する要素を次の 3つのレイヤーに分類します。

3. モジュール構成を検討する

レイヤー分けした要素をもとに、役割が近いもの同士をまとめてモジュール化します。

モジュール名は誰が見ても役割が分かる名称にします。

• 例：業務ロジックなら [アプリ名]_BL

4. モジュールをアプリケーション単位にまとめる

設計したモジュールをアプリケーション単位で整理します。

5. アプリケーションとモジュールを作成する

Service Studio を使い、アプリケーションとモジュールを作成します。

開発者が Service Studio 上で役割を一目で把握できるようにするため、各アプリケーションやモジュールの Description にはその役割を記載します。

過去に携わったプロジェクトでの一例を紹介すると、モジュールの Description には配置する要素の種類（画面、ブロック、業務ロジック、Entity など）を記載する運用を採用していました。この運用により、どの種類の要素をそのモジュールに置くべきかが明確になり、要素の配置ミスを防ぐことができました。

• 例：[アプリ名]_BL モジュール なら、「アプリケーションで使用する業務固有のロジック（Action）」

また、作成した Architecture Canvas は、実際の構成と乖離しないよう継続的に更新し、チームの誰もがいつでも最新の状態を参照できるようにすることが重要です。

2. Theme

Theme はアプリ全体の見た目（色・レイアウト・スタイル）を統一する基盤です。Theme を初期に整えておくことで、UI の統一性と保守性が向上します。

Service Studio の「Interface」タブ内にある「Themes」フォルダから、そのモジュールで利用可能な Theme を確認できます。

複数モジュールで共通 UI を使用する場合は、Theme 専用モジュール（例：[アプリ名]_TH）を作成し、画面モジュールから参照する構成が推奨されます。

Theme を開発初期に整備することのメリット

Theme を開発初期に整備すると、以下のメリットがあります。

• 画面構造とスタイルの基準を初期に決めておくことで、アプリ全体の UI を統一できる

• 画面を同じルールで作成できるため、実装のばらつきを防ぐことができる

• 開発後半でレイアウト変更が必要になっても、影響範囲を最小限に抑えられる

開発初期に作成を推奨する内容

1. レイアウトブロック

レイアウトブロックは、Theme の Layout プロパティ に設定される、画面レイアウト（ヘッダー・メニュー・フッターなど）の構造を定義するブロックです。このレイアウトブロックを設定することで、新しく作成する画面の構成を統一できます。

OutSystems には、標準のレイアウトブロック（例：LayoutTopMenu）が用意されています。これには、一般的な業務アプリでよく使われるヘッダー、メニュー、コンテンツ領域が組み込まれているため、独自にレイアウトブロックを作らなくても画面を作成できます。一方で、標準のレイアウトブロックでは要件を満たせず、プロジェクト独自のレイアウトを適用したい場合は、新たにレイアウトブロックを作成し、Theme の Layout プロパティ に設定します。

2. スタイルシート

Theme の Style Sheet プロパティ では、Theme に紐づく CSS を定義できます。

以下のような共通スタイルを Theme で管理することで、画面間のデザインのばらつきを防げます。

• 余白（margin / padding）ルール

• ラベルテキストのサイズ、色

3. アプリケーションのベースカラー

アプリ全体の基調色（プライマリカラー）は、Theme の Style Sheet（CSS）から定義できます。

例

:root {
    --color-primary: #4c6cb3;
}

設定したプライマリカラーは、ボタンの背景色など、各種 UI 要素に適用されます。

3. 画面テンプレート（Screen Template）

OutSystems の画面テンプレートは、単なる UI の雛形ではなく、検索処理・入力検証・エラー処理といった繰り返し必要となる共通ロジックをまとめて再利用できる仕組みです。複数の画面で同じ処理を使用する場合、あらかじめテンプレート化しておくことで、開発効率と画面品質を大きく向上できます。

業務アプリケーションでは、一覧で検索して絞り込む・フォームで入力して保存するといった基本フローは、扱う Entity が異なっても画面構造がほぼ共通になるケースが多くあります。こうした繰り返し登場する画面構造を最初にテンプレート化しておけば、実装がスムーズになるだけでなく、チーム全体の作り方も標準化できます。

作成手順の詳細は公式ドキュメントにまとめられています。

→公式サイト：画面テンプレート

なぜ開発初期に作るべきか

画面テンプレートを初期に作成しておくと、以下のメリットがあります。

• UI と共通ロジックをテンプレートにまとめておくことで、以降の画面作成を高速化できる

• 開発者ごとの作り方の違いが減り、画面品質のばらつきを抑えられる

• 一定数の画面を作成した後ではテンプレート側の改善が既存画面に自動反映されないため、初期に作成しておくほど手戻りを最小化できる

開発初期に作成を推奨するテンプレート

OutSystems で業務アプリを構築する際、次の 2 種類の画面は複数回登場するため、早い段階でテンプレート化しておくことを推奨します。

• 一覧画面（検索 + テーブル表示）

• 登録・更新フォーム（入力・検証・エラーハンドリングなど）

これらの画面は、扱う Entity が異なっても構成がほぼ共通しているという特徴があります。

一覧画面に共通する構成例

• 検索条件

• 検索ボタン

• テーブル表示

• ページング

登録・更新フォームに共通する構成例

• 入力項目のデザイン（Label + Input の繰り返し）

• バリデーション

• 保存ボタンなどの操作ボタンの位置

• 完了メッセージ／エラー表示

扱うデータが異なっても画面構造はほとんど変わらないため、これらの共通要素をテンプレートとしてまとめておけば、各画面の作成が項目の差し替えだけとなり、開発効率が向上します。

特にこの一覧画面と登録・更新フォームは、マスタメンテナンス画面として登場する頻度が非常に高いという特徴があります。

テンプレート化の効果がもっとも大きい領域のため、開発初期の段階で準備しておくことを推奨します。

実践時の注意点

• テンプレートを作り込みすぎると汎用性が低下し、他の画面に適用しにくくなる

• 小規模アプリでは画面数が少ないため、テンプレート化より直接実装した方が早い場合もある

4. Entity と ラッパーアクション

OutSystems では Entity を作成すると、その Entity の CRUD 処理を行う Entity Action が自動生成されます。

Entity を Public に設定すると、他のモジュールからも Entity Action を利用できますが、これをそのまま利用すると以下のような問題が発生します。

• 権限チェックを各画面・各処理で個別に実装する必要があり、漏れが発生しやすい

• 例：一部の画面だけ更新権限のないユーザーでも Entity を更新できてしまう場合がある

• 実装した後に業務ルールが追加された場合、Entity Action を使っているすべての実装を修正する必要がある

• 例：削除前の共通チェックを追加する場合、Delete Entity Action を使っているすべての実装で修正が必要になる

そのため、Entity Action を直接使用するのではなく、Entity Action を呼び出す専用のアクション（ラッパーアクション）を作成し、そちらを Public にする構成が推奨されます。
また、Entity のプロパティには Expose Read Only という設定もあり、Yes に設定すると 外部モジュールから利用できる Entity Action が Get 系 のみに制限されます。こうすることで、Entity の更新処理を実装するモジュールを限定できるため、更新処理の変更に対する影響調査も容易になります。

ラッパーアクションの自動作成機能

OutSystems には、ラッパーアクションを自動生成できる Entity Actions Wrappers Accelerator が用意されています。

→公式サイト : Entity Actions Wrappers Accelerator

Entity を右クリックし 「Create Entity Action Wrappers」 を選択すると、必要なラッパーアクションが自動作成されます。

なぜ開発初期に作るべきか

• 共通処理（権限チェック・ログの出力等）を最初から組み込める

• Entity を利用し始めた開発者が、誤って Entity Action を直接使ってしまうリスクを防ぐ

実装頻度が高いラッパーアクション

ラッパーアクションは、Entity ごとに必要な Entity Action に絞って実装する必要があります。ここでは、過去携わったプロジェクトで、効果が大きいと感じたラッパーとその理由を紹介します。

CreateOrUpdate

• Create と Update を同じ画面で扱う場面が多いため

• 判定ロジックを各画面で実装するとばらつきが生じやすく、ラッパー側に集約することで処理を統一できる

なお、Create と Update を個別のラッパーとして提供していたプロジェクトでは、画面側でどちらのラッパーアクションを呼ぶべきかの判定をするロジックを毎回実装する必要があり、チーム内で実装方針にばらつきが出るという課題が発生しました。

Delete

• プロジェクトやデータによって論理削除・物理削除の方針が異なるため

• 削除処理を画面ごとに実装すると方針が統一されないため、ラッパー側で一元化することで削除ルールを統一できる

5. 共通処理・部品

アプリケーションの種類に関係なく利用頻度が高く、複数のモジュールで再利用される処理は、開発初期の段階で共通化しておくことを推奨します。共通化することで品質のばらつきを抑えられ、プロジェクト全体の生産性も高められます。

開発初期に作成を推奨する共通処理・部品

• ログレベルに応じたログ出力制御処理

• ローディング表示部品

• 日付のフォーマット変換処理

• 確認メッセージ・警告メッセージなど定型文を返す処理

• 単一項目に対する汎用バリデーション

• 必須チェック

• 日付チェック

• 数値チェック

これらは特定の業務ロジックに依存しない汎用的な処理であるため、複数の画面で繰り返し登場します。そのため、あらかじめ共通化することで実装の重複を防ぎ、品質を統一できます。

関連サービスのご紹介

本記事で紹介した初期設計は、短期間で体系的に理解・習得するのが難しい領域でもあります。CTC では、初期設計をスムーズに進めるためのサービスを提供しています。もし初期設計に不安がある場合は、次のようなサービスの活用もご検討ください。

Architecture Workshop

Architecture Canvas の適用方法、モジュール分割の基準、依存関係の整理など、チーム開発で必須となる設計スキルを集中的に学べるトレーニングです。

→CTCが提供するトレーニングのご紹介

OutSystems Utility Package

OutSystems Utility Package は、多くのプロジェクトで利用される共通処理や部品をまとめたモジュール群を提供しています。導入することで、OutSystems プロジェクトの初期セットアップを効率化できます。

まとめ

適切な初期設計を行うことで開発効率が向上し、長期的に保守しやすいアプリケーションを構築できます。さらに、後続の開発コストも抑えやすくなるため、プロジェクトの立ち上げ段階から意識して取り入れてみてください。

CTC では、OutSystems プロジェクトの立ち上げ支援をはじめ、さまざまな支援サービスを提供しています。詳しい内容や本記事で紹介したサービスについて、ぜひお気軽にお問い合わせください。