実用的な明細フォームのための親子データモデル

なぜ1つのレコードでは不十分か

見積、注文、経費精算、チェックリストはめったに1つの事項だけを表しません。これらのフォームの多くは、上にメインのレコードがあり、その下に複数の小さな項目が並びます。すべてを1つのレコードに無理やり押し込むと、フォームは読みづらく、編集しにくく、壊れやすくなります。

長いテキストフィールドは最初は簡単に見えますが、すぐに問題を引き起こします。人は1つの項目だけをきれいに追加できず、ある行だけを修正することが難しく、古い情報を安心して削除できなくなります。検証も弱くなります。システムは明確な個別項目ではなく、1つの塊のテキストとして扱ってしまうからです。

例えば営業見積を考えてみてください。1件の顧客の依頼に5つの商品が含まれることがあり、それぞれに数量、単価、割引、メモが必要です。経費精算でも同様です。1件の申請は1名の従業員に属しますが、それぞれの経費は日付、カテゴリ、金額、領収書の有無といった個別の情報を持ちます。

ここで親子モデルが役立ちます。親レコードは依頼者、日付、部署、承認ステータスなど、フォーム全体に共通する詳細を保持します。子レコードは明細行を保持します。各行は、メインのレコードを壊すことなく個別に追加・編集・削除できます。

この分離により、フォームは使いやすく、チームが信頼しやすくなります。ある行だけ金額が間違っていたり、項目が欠けていたりしても、その行だけを修正すれば十分です。他はそのまま保たれます。

同じパターンは編集可能なチェックリストにも当てはまります。チェックリストは1人の所有者と1つの期限を持ち、それぞれのタスクはラベル、担当者、メモ、完了状態を持ちます。共有の詳細はひとつの場所に、項目の詳細はそれぞれの行に残します。

親と子のレコードはどう機能するか

明細フォームは、1つのメインレコードと複数の関連する項目レコードに分けると管理しやすくなります。

親レコードは一度だけ表示すべき情報を保持します。見積なら顧客、見積日、営業担当、現在のステータスなどです。経費申請なら従業員名、部署、提出日、承認段階などが該当します。

各子レコードは、その親に紐づく編集可能な1つの項目を格納します。見積では1つの子が商品やサービスの明細を表すかもしれません。チェックリストでは1つの子がタスクになります。経費フォームでは通常、各子が日付、カテゴリ、金額、領収書メモなどを持つ1つの経費です。

単純にまとめると次の通りです：

• 親：フォーム全体に共通する詳細
• 子：1行、1項目、1アクション
• リンク：子が親を参照するフィールド

この構造が重要なのは、合計や要約が親に手入力されるのではなく子の行から算出されるべきだからです。誰かが項目を追加・削除・編集したときに合計が実際のデータから更新されれば、エラーが減り承認の信頼性が高まります。

また検証がより正確になります。数量を必須にしたり、負の金額を拒否したり、日付が抜けている行だけをフラグしたりでき、フォーム全体を凍結する必要がありません。

日常業務でのよくある用途

ヘッダーが1つあり、その下に多くの編集可能な行が必要な場所なら、どこでもこのパターンが使われます。

見積はわかりやすい例です。営業担当が1つの見積を作り、商品やサービスごとに1行を追加します。各行は品目名、数量、単価、割引、税、メモなどを必要とし、親が顧客、日付、承認ステータスを保持します。

注文も同じ考え方ですが、行には運用上の詳細がより多く含まれることがあります。1つの注文に複数商品が含まれ、各行に在庫状況、倉庫メモ、配送情報、出荷予定日などが必要になる場合があります。明細行が注文後の作業を駆動します。

経費精算も一般的なケースです。1つの申請は1名の従業員と1つの報告期間に属しますが、多数の経費が含まれることがあります。各経費行は通常、日付、金額、カテゴリ、ベンダー、領収書参照などを必要とし、管理者は行ごとにレビューすることが多いです。

チェックリストも同じモデルに当てはまります。親レコードはオンボーディング計画、現場点検、週次レビューなどになり、各子行は完了状態、メモ、担当者、期限を持つタスクになります。

シンプルなテストはこうです：フォームにヘッダーが1つあり、人が追加・編集・削除する行があるか？あれば、親子構造が一般的に適切です。

作る前に構造を計画する

良いフォームは通常、最初に「何が全体に属し、何が各行で繰り返されるのか？」という問いから始まります。

これを先に決めると後の多くの問題が消えます。重複フィールド、乱れた合計、管理しにくい行を避けられます。

親レコードにはドキュメント全体を表すフィールドだけを置きます。見積なら顧客名、見積日、通貨、営業担当、全体の承認ステータスなどです。経費申請なら従業員名、部署、提出日、最終判断などが該当します。

子レコードには行ごとに属するフィールドを置きます。品目名、数量、単価、経費日、カテゴリ、領収書種別、行メモなどです。値が行ごとに異なり得るなら、通常は子に属します。

便利なテストはこうです：ある行を削除したらその値も消えるべきか？答えが「はい」なら、そのフィールドは子レコードにあるべきです。

各行には固有のIDを付けてください。行の位置（1番目、2番目...）だけに頼らないでください。行IDがあると特定の経費を編集したり、削除された項目を復元したり、変更内容を追跡したりするのがずっと簡単になります。

公開前に、人が行をどう扱うかを決めておきます。行を追加、複製、削除、並べ替え、フィルタできるか？合計やステータスはいつ更新するか？あるチームは行が変わるたびに合計を即時更新したいですし、別のチームは保存や提出時だけ更新したいかもしれません。どちらの方式でも機能しますが、一貫したルールにしておくべきです。

ステータスのルールも重要です。ある経費が却下されたら申請全体は下書きに戻るのか、保留のままか、一部承認の状態になるのか？こうした質問には、ユーザーが使い始める前に答えを用意しておく方が後々楽です。

フォーム利用者が編集しやすくする

明細フォームは、親の詳細と行が一緒に見えると最も使いやすくなります。メインレコードを上に置き、編集可能な表をその下に直接表示してください。見積を作る人は、商品を追加する前に顧客、日付、ステータスを確認できるべきです。

このシンプルなレイアウトにより、編集するために画面を行ったり来たりする必要がなくなり、ミスが減ります。

1つの画面に収める

行の追加は素早く感じられるべきです。テーブルの上か下に明確な「項目を追加」ボタンがあると十分なことが多いです。クリックしたら別ページに遷移させるのではなく、空の行か小さなインラインフォームを開くようにしてください。

これは特に長いフォームで重要です。10件の経費を入力する人にとって、余分なクリックは時間を奪い、ミスの確率を上げます。

最も有用な行操作は通常、追加、複製、削除、場合によっては移動です。複製は、連続した宿泊や似たチェックリスト項目など、ほとんど同じ行が複数あるときに特に役立ちます。

エラーは発生箇所に表示する

長いフォームでは、作業の一部を自動保存するか、少なくとも下書きを保存できるようにしてください。タブが閉じて20分の入力が消えるのは、フォームを信頼できないと感じさせる最短ルートです。

検証も同様に明確にするべきです。1つの行に金額が欠けているか数量が不正なら、その行の該当フィールドにエラーを表示してください。曖昧な警告を探してフォーム全体を見直させるのは避けます。

7件の経費が正しく、1件だけが領収書番号 missing の場合は、その行だけにマーキングを付け、残りはそのままにしておきます。利用者はその場で問題を直せます。

例：多数の経費がある経費精算申請

経費申請はこのモデルがよく機能する理由を明確に示します。1つの申請が親レコードになり、各経費が子行になります。

親は申請全体に適用される詳細を持ちます：従業員名、申請期間、マネージャー、全体のステータスなど。ステータスは Draft（下書き）→ Submitted（提出済み）→ Partially Approved（部分承認）や Approved（承認済み）に移ることがあります。

各経費行はその項目にのみ属する詳細を持ちます。1行はタクシー代の店舗名、購入日、金額、カテゴリ、領収書の有無を保持し、別の行はホテル代の同じフィールドを持ちます。

単純な申請の例：

• City Taxi、5月3日、$28、交通、領収書あり
• Grand Hotel、5月4日、$180、宿泊、領収書あり
• Corner Cafe、5月4日、$14、食費、領収書なし

この構造が重要なのは、管理者が経費行を1つずつレビューすることが多いためです。タクシーとホテルは承認、食事は「領収書がない」や「日当を超過」などの短い理由で却下されるかもしれません。

1行の却下で申請全体が台無しになっては困ります。従業員は承認された項目分だけ払い戻しを受け、却下された行は理由とともに見える状態で残るべきです。これによりプロセスは理解しやすく、後で監査もしやすくなります。

合計は親ではなく子の行から算出するべきです。多くのチームは2つの合計を持ちます：提出時の合計（全行に基づく）と承認後の合計（承認された行のみ）。これで支払額が元の申請額より少ない理由が明確になります。

合計、承認、ステータスの変更

明細フォームは、数値とステータスが適切なタイミングで更新されると信頼できるようになります。

ユーザーが数量、単価、経費金額を変更したら、その変更に基づいて合計を再計算するべきです。提出時まで待つと、割引、税、承認限度などが関係する場合に混乱が生じやすくなります。多くの場合、親の合計は計算されるもので、編集可能にしてはいけません。

承認ルールも同じくらい明確であるべきです。レコードが完全に承認されたら行をロックするかどうかを決めてください。承認済みの行が編集可能なままだと、管理者が実際に承認した内容とデータがずれてしまいます。

場合によっては、承認は行ごとに行われます。経費は良い例です。交通は承認、食事は一部却下、別の経費は説明が必要で差し戻される、という具合です。その場合、各子行は独自のステータスを持ち、親が全体のステータスを保持します。

全体状態は簡潔にしておくとよいでしょう：

• Draft（下書き）
• Pending review（レビュー中）
• Partially approved（部分承認）
• Approved（承認済み）
• Rejected（却下）

この分離によりフォームは正直になります。親が申請の全体状況を伝え、子行が各項目に何が起きたかを説明します。

また、金額、ステータス、承認者、合計など重要なフィールドの簡単な変更履歴を残すと便利です。初日から完全な監査システムが必要というわけではありませんが、主要な変更を説明できるだけの履歴は必要です。

削除された行にもルールが必要です。レビュー前なら完全削除で構いませんが、レビューが始まってからはアーカイブする方が過去の合計や承認判断が意味を持ち続けるため安全です。

信頼を損なう間違い

画面上はきれいでも、内部に乱れたデータが保存されていると信頼は急速に落ちます。

よくある間違いの1つは、親フィールドと項目フィールドをフラットな表で混ぜてしまうことです。見積や注文、経費申請には依頼者、日付、承認ステータスのような全体に属する情報と、品目名、金額、数量、領収日など各行に属する情報があります。これらが混ざると編集が混乱し、レポートが使いにくくなり、重複データが広がります。

もう1つの問題は、合計を手入力させることです。誰かが3件の経費行を入力してから別に総合計を手で入力すると、数値が一致しないことがあります。そうなるとレビュアーはフォームを信用しなくなります。

大きな自由形式テキストボックスも同様に問題を起こします。すべての項目を1つのフィールドに貼り付けさせるのは速そうに見えますが、非構造化テキストは検証、ソート、フィルタ、承認が難しくなります。構造化された行は初めは手間がかかりますが、後で管理しやすくなります。

行レベルのチェックが抜け落ちることもよくあります。空の行、不正な日付、重複エントリ、負の金額、中途半端な項目はフォームが進む前に検出されるべきです。実際のエラーはヘッダーではなく子行の中にあることがほとんどです。

削除も弱点です。ユーザーが確認なしにワンクリックで行を消せると重要なデータが誤って消える可能性があります。誰が変更したかの記録がなければさらに問題です。

安全なアプローチはシンプルです：行削除を確認し、計算フィールドをロックし、人々が行う重要な変更を記録します。

公開前に確認する

繰り返し行を含むフォームを公開する前に、実際のユーザーが使うようにテストしてください。

まず基本を確認します。ユーザーが行を追加、編集、複製、削除しても他のデータを失わないか。10行で動作が良いか、50行や100行でも問題ないか。エラーは該当する行に表示されるかなどを確認します。

次に変更後の挙動をテストします。数量を更新し、行を削除し、項目を複製し、ステータスを変更します。各操作後に親レコードが正しい合計、件数、要約状態を表示しているか確認してください。

また、よく弱点を露呈するエッジケースも試します：すべての行を削除した場合、1つだけ無効な行が混ざっている場合、重複エントリ、ゼロ金額、長いメモ、提出後の編集などです。

日常的な使い方でも混乱が起きず、混乱した条件下でも予測可能に振る舞うようになればフォームは公開準備完了です。

ノーコードアプリで作る

ノーコードアプリでこれを作る場合は、人が既に理解しているワークフロー（経費精算や見積など）から始めてください。最初にデータ構造を作り、次に親レコードと子行をつなぐルールを追加し、その後にレイアウトを整えます。

実際のサンプルデータを使うことは、完璧なテストデータを使うよりもはるかに有益です。重複、メモ不足、金額修正、中途半端な行を入力してみてください。そうしたケースが、フォームが混乱する場所や信頼が落ちる箇所を教えてくれます。

AppMasterは、この種の構築に適しています。親子構造は別々のデータモデル、関連するフォーム、ビジネスロジックに自然にマッピングできます。プロセスが成長したら、同じコアモデルをバックエンド、Web、ネイティブモバイルアプリに変換でき、ワークフローを一から作り直さずに済みます。

どのツールを使うにせよ、目標は同じです：親レコードをすっきり保ち、各行を個別に編集できるようにし、合計やステータスは実データから算出すること。ここがうまくいけば、明細行フォームははるかに使いやすく、信頼されるようになります。