ベストプラクティス

本ページでは、NuAppのポテンシャルを最大限に引き出し、拡張性が高く堅牢なシステムを構築するための「設計の定石（ベストプラクティス）」をまとめています。従来のスクラッチ開発やRDB（リレーショナルデータベース）の常識とは異なる部分もある、NuAppの設計思想に慣れていきましょう。

開発フローでの考え方

NuAppは、モデルとアプリで完結するシンプル設定を謳っていますが、それでもいざ開発を行おうとすると、何から手を付けていいか迷うかもしれません。ここでは開発の進め方（開発フロー）の視点から、いくつかの論点についての考え方を提示します。

アジャイル型（プロトタイプ駆動）で進行 : リリース前であれば設定を変更しても手戻りは少ないです。「作っては壊す」が瞬時にできるのがノーコードの強みなので、仕様書を完璧にする前に、まずは気軽に作って、実際の画面を動かしながら仕様の完成度を高めていきましょう。
「モデル」と「アプリ」どちらから作るか？ : 「モデル」がないと「アプリ」は作れないので、まずは「モデル」の定義からスタートします。しかし、一発で完璧なモデルを作る必要はありません。その後、メニューや機能を司る「アプリ」を構築する中で、「カンバンで見せたいからステータス属性が必要だな」「カレンダーに表示するために日付型が必要だな」といったユースケースからの逆算でモデルの仕様が洗練されていくのが自然な流れです。
「データ」と「プロセス」どちらから始める？ : データとプロセスは「やりやすい方」から着手してOKです。例えば、以下のようなアプローチが考えられます。ターゲットの業務に合わせて選択してください。
- データ先行型： 既存のExcelや紙の帳票から必要なデータを整理してモデル化し、その後、担当別の権限や自動化の必要性に応じて「プロセス」を設計する。
- プロセス先行型： 現実の業務フローをもとに「プロセス（ワークフロー）」を描画し、各タスク（担当者毎の業務）でどんな情報が必要になるかを洗い出しながら「データ項目」を肉付けする。

基本設計の定石（モデリング）

モデルの設計をシンプルに保ち、拡張性や保守性を高めていくための判断基準です。

モデルの単位：何を基準に分割？
- 基本は「業務的な概念毎（顧客、商談、請求など）」でモデルを分けます。また、NuAppの実装上の理由で作成するのも大いに正解です。例えば、バッチ処理用のモデル、テンプレートとして使うためのモデルといったイメージです。
データ設計：正規化等についてはどう考えるべき？
- 一定程度は必要です。しかし、従来のRDBのように厳密に正規化（テーブル分割）を行うと、かえって運用や実装が複雑になって不便になる可能性もあります。
- 例えば、前述のモデル分割の観点ですが、タスクの1画面で編集したい情報は、原則１モデルにまとめた方が便利です。まとめない場合、複数のデータを開いて編集という流れをユーザーに強いることになります。
- 項目の重複についても時に許容してもいいです。「データを参照して引っ張るよりも、項目をコピーして同じモデルに持たせた方が実装がシンプルになる」という場合は、データの重複を恐れずにコピーして持たせる設計を取ってもいいです。ただし、正となる情報がどのモデルに属するのかを明確にし、編集は原則その元となるモデルのみ許容し、適切なタイミングで反映されるという設計に留意する必要はあります。
データの関係性（リレーション）の使い分け
- 多対1： 例えばマスターデータを参照するようなケースの場合は、参照型 を使用して他のモデルを結びつけます。
- 1対多： 逆に自モデルに、他モデルが複数紐づくような場合です。かつ画面遷移なしてその場で編集したい、というケースでは、明細 を使用します。
  - 明細でよく使うテクニック：明細側から親モデルを参照したいケースは多々あります（検索や集計で使いたい、プロセス処理中に参照したい等）。その場合は、「親モデルの登録後に、親への参照を明細側（子）へ引き渡す」というバックエンドのデータ操作処理を挟むのが定石です。
「次のアクション」と「関連リスト」で動線を作る
- モデル同士を連携させたら、アプリ設定を使って、「次のアクション（関連するデータの作成）」や「関連リスト」を配置します。ユーザーが「次にどの画面を開けばいいか」迷わないシームレスなUI/UXを提供してください。
現実の業務フローは必ずプロセス化すべきか？
- モデルでプロセスを設定できる以上、現実の業務におけるプロセスはちゃんと設定しなければいけない、と考える方もいるかもしれません。しかし、プロセスはあくまでも、システム上のユースケースを実現するための手段です。
- 例えば要件が「タスクによる権限管理は不要」「ステータス等の変更はユーザーの手動更新で事足りる」という場合は、無理に複雑なプロセス（ワークフローの矢印）を描く必要はありません。「データを入れて一覧（リスト）で見るだけ」というシンプルな設計が、用途を完璧に満たすシステムになるケースも多いです。

一歩進んだアプリを作るために（プロセスの実践）

裏側の自動処理（バックエンド）や、予期せぬ挙動を防ぐための技術的なチェックポイントです。

「データ操作」と「モデル連携」の使い分け
- データ操作： 主に「既に存在しているデータ」に対して、値の更新や計算、集計をかける場合に使用します。
- モデル連携： 業務の進捗（例：受注確定）に伴い、「新たに別モデルのデータを生成・追加する」というユースケースが中心の場合に使用します。
タスクの状態遷移との整合性を保つ
1. アプリ設定におけるタスク： NuAppの多くのアプリ機能では、設定時に「初期タスク」と「更新タスク」を指定する必要があります。新規登録を行う際に「初期タスク」が実行され、既存データを編集する際に「更新タスク」が実行さるという意味です。ユースケースと照らし合わせて、その機能を使うタイミングで更新タスクがアクティブになっているか等を想定しておく必要があります。
2. 明細の親子連動： 明細を使っている場合、親のプロセスが進んでも明細側が編集可能な状態を継続できるよう、親子のライフサイクルが同期するプロセスを親モデル側・明細モデル側両方を見比べて組んでください（※詳細はテーマ記事「明細」を参照）。
自動処理の時系列（実行順）と「同時実行」の罠 自動化ロジックを組む際、処理が実行される順番の仕様を正しく理解しておく必要があります。
- プロセスの矢印： ワークフロー（プロセス）上に配置された処理は、矢印で繋いだ順に時系列で実行されます。
- データ操作内の処理： 1つのデータ操作ノードの中に複数の処理を並べた場合、原則として上から順に実行され、順次保存（コミット）されます。
- ⚠️ 注意：同時実行によるデータ競合の回避 「全分岐」を使用した場合や、「明細」のあるモデルのタスクを実行した場合、裏側では複数の処理が同時に並行実行（並行処理）されます。そのため、データの上書き順序が制御できなくなったり、競合が発生したりするケースがあります。どうしても「1つ目の処理が終わってから2つ目を処理したい」といった厳密な実行順の制御を行いたい場合は、『メッセージ送受信』や『スケジューラー』を使って時間差制御を行うのが極めて有効な回避策です。