レッスン3：共通の設計言語②——データの持ち方を決める

このレッスンで学ぶこと

テーブル・レコード・フィールドという、データの持ち方の基本単位を理解する
表と表をつなぐリレーションという発想を身につける
一覧と詳細という、2種類のビューの考え方を理解する
1つの表にすべてを詰め込まない設計の考え方を身につける
あとから直しにくい設計を、事前に見分けられるようになる

前のレッスンでは、トリガー・アクション・条件分岐という、業務の流れを表す共通言語を学びました。このレッスンでは、もう1つの共通言語である「データの持ち方」を扱います。本コースの中核メッセージの3つ目に「データの持ち方を先に決めないと、あとで必ず作り直しになります」とありました。その理由を、このレッスンで具体的に理解していきます。

テーブル・レコード・フィールドという発想

ノーコードツールの多くは、データを「表」として扱います。この表には、3つの基本単位があります。

テーブルは、表そのものです。「申請一覧」「顧客一覧」「在庫一覧」というように、1つのまとまったデータの集まりを指します。

レコードは、テーブルの中の1行分のデータです。「申請一覧」というテーブルであれば、1件の申請が1つのレコードにあたります。表計算ソフトで言えば、1行分のデータと同じ考え方です。

フィールドは、テーブルの中の1列分の項目です。「申請日」「申請者」「金額」「承認状況」といった、レコードが持つ個々の情報がフィールドにあたります。

用語	表計算ソフトでの近い概念	具体例（申請一覧テーブルの場合）
テーブル	シート	申請一覧
レコード	行	2026年9月1日の交通費申請
フィールド	列	申請日、申請者、金額、承認状況

💡 ポイント テーブル・レコード・フィールドという呼び方は、ノーコードツールに限らず、データベースと呼ばれる仕組み全般で共通して使われる基本用語です。表計算ソフトの「シート」「行」「列」とほぼ同じ感覚で理解できますが、ノーコードツールでは、この単位ごとに細かい設定（入力の形式、必須かどうかなど）を加えられる点が異なります。

表と表をつなぐ——リレーション

業務のデータは、1つの表だけで完結することはほとんどありません。「申請一覧」というテーブルと、「申請者一覧」というテーブルがあり、両者を結びつけたい、という場面が必ず出てきます。この結びつきを「リレーション」と呼びます。

例えば、申請一覧テーブルの中に、申請者の氏名・部署・連絡先をすべて書き込んでしまう方法も考えられます。ですが、この方法には弱点があります。同じ申請者が10件申請すれば、氏名・部署・連絡先が10回、重複して入力されます。ある申請者が異動して部署名が変わったとき、過去の申請すべてを1件ずつ書き換える必要が出てきます。

これを避けるため、「申請者一覧」という別のテーブルを用意し、申請一覧テーブルからは「どの申請者か」だけを指し示すようにします。これがリレーションの基本発想です。

erDiagram
  申請者一覧 ||--o{ 申請一覧 : "1人が複数件申請する"
  申請者一覧 {
    string 氏名
    string 部署
    string 連絡先
  }
  申請一覧 {
    date 申請日
    string 申請者
    number 金額
    string 承認状況
  }

この図は、「申請者一覧」の1件のレコードが、「申請一覧」の複数のレコードと結びつく関係を表しています。申請者の部署が変わったときは、申請者一覧の1件を書き換えるだけで、すべての申請の表示に反映されます。重複した入力の手間も、書き換えの手間も、大きく減らせます。

📝 補足 リレーションを組むと、テーブルの数は増えますが、それぞれのテーブルが扱う情報の種類は単純になります。「テーブルが増えること」を怖がる必要はありません。1つの表に何もかも詰め込むより、役割ごとに分けたほうが、結果として扱いやすくなります。

関係の種類——1対多と多対多

リレーションには、大きく分けて2つの種類があります。

1対多は、先ほどの申請者一覧と申請一覧の関係のように、一方の1件が、もう一方の複数件と結びつく関係です。1人の申請者が、複数件の申請を持つという関係が、これにあたります。業務データの多くは、この1対多の組み合わせで表現できます。

多対多は、両方が互いに複数件と結びつく関係です。例えば「1件の申請には複数のタグを付けられ、1つのタグは複数の申請に使われる」という関係は、多対多にあたります。多対多の関係は、間に「どの申請に、どのタグが付いているか」だけを記録する小さなテーブルを1つはさむことで、1対多が2つ組み合わさった形として表現します。

erDiagram
  申請一覧 ||--o{ 申請タグ紐付け : "1件の申請に複数のタグが付く"
  タグ一覧 ||--o{ 申請タグ紐付け : "1つのタグが複数の申請に使われる"
  申請一覧 {
    date 申請日
    string 申請者
  }
  タグ一覧 {
    string タグ名
  }
  申請タグ紐付け {
    string 申請ID
    string タグID
  }

最初のうちは、1対多の関係だけを意識できれば十分です。多対多が出てきたときに「間に小さなテーブルをはさむ」という発想があることを知っておくと、行き詰まらずに設計を進められます。

一覧と詳細というビューの考え方

同じテーブルのデータでも、見せ方は1つとは限りません。ノーコードツールでは、同じデータを異なる形で表示する「ビュー」という考え方がよく使われます。

一覧ビューは、複数のレコードを、行として並べて見せる表示方法です。全体を俯瞰したいとき、件数を数えたいとき、条件で絞り込みたいときに向いています。

詳細ビューは、1件のレコードが持つすべての情報を、じっくり読める形で見せる表示方法です。申請の中身を確認したいとき、入力や編集をしたいときに向いています。

同じ申請一覧テーブルでも、「未承認のものだけを並べた一覧ビュー」「今月分だけをまとめた一覧ビュー」「1件を選んで全項目を確認する詳細ビュー」というように、目的に応じて複数のビューを使い分けます。データそのものは1つでも、見せ方を切り替えられるのが、ノーコードツールの利点です。

🔰 初学者の方へ 表計算ソフトでは、見せ方を変えたいとき、別のシートにコピーして作り直すことがよくあります。ノーコードツールのビューは、元のデータをコピーせずに、条件や並び順だけを変えて表示を切り替える仕組みです。元データは1つのまま保たれます。

1つの表に詰め込まない

初めてノーコードツールに触れると、管理したい情報をすべて1つの表に入れてしまいたくなります。ですが、これは、あとから直しにくい設計につながる、最も典型的な失敗です。

次のような表を考えてみましょう。

申請日	申請者	部署	連絡先	品目1	数量1	品目2	数量2	品目3	数量3
9/1	山田	総務	×××	ノート	5	ペン	10
9/2	佐藤	営業	×××	ノート	2

この表には、2つの問題があります。1つ目は、申請者の部署や連絡先が、申請のたびに重複して入力される点です。2つ目は、「品目1」「品目2」「品目3」という列が、4品目以上の申請に対応できない点です。あとから「品目4」の列を追加しても、根本的な解決にはなりません。

このような表は、次のように分けると扱いやすくなります。

申請者一覧テーブル：申請者ごとの氏名・部署・連絡先を1件ずつ持つ
申請一覧テーブル：申請日・申請者（申請者一覧への結びつき）・承認状況を持つ
申請明細テーブル：どの申請に、どの品目が、何個含まれるかを1行ずつ持つ

3つに分けることで、品目がいくつあっても明細テーブルに行を追加するだけで対応でき、申請者の情報も1か所にまとまります。

1件を特定できる項目を決めておく

テーブルを分けるときは、それぞれのテーブルで「どの項目を見れば、1件のレコードを間違いなく特定できるか」をあらかじめ決めておきます。この項目は、多くのノーコードツールで自動的にID（識別のための番号や記号）として割り振られますが、氏名のように重複しうる情報だけに頼らないことが重要です。同姓同名の申請者が2人いた場合、氏名だけでは、どちらの申請者を指しているかが曖昧になってしまいます。

⚠️ 注意 「テーブルを分けるのは面倒」と感じるかもしれませんが、1つの表に詰め込んだ場合の面倒さは、あとになるほど大きくなります。データを入れ始める前に、テーブルを分ける設計をしておくことが、結果として最も手間を減らします。

あとから直しにくい設計の見分け方

すべての設計の失敗を、最初から完全に避けることはできません。ですが、次のような兆候が見えたら、あとから直しにくい設計になっている可能性が高いというサインです。

同じ情報（氏名、部署名など）を、複数のテーブルや複数の行に、手作業でコピーして入力している
「品目1」「品目2」のように、同じ種類の項目が横方向に並んでいる
1つのフィールドに、複数の意味の情報が詰め込まれている（「東京都渋谷区、2026年9月1日、5個」のような文字列を1つのフィールドに入れる、など）
集計したい数値が、文章の中に埋め込まれていて、そのままでは合計や平均が計算できない
「このフィールドは何のためにあるのか」を、作った本人しか説明できない
集計や絞り込みをするたびに、まず文字列を分解する下準備が必要になる

これらの兆候に気づいたら、テーブルを分け直す、フィールドを分けるといった見直しを検討します。運用を始めてから直すのは手間がかかりますが、気づいた時点で直すほうが、さらに先送りするより必ず楽になります。

分けすぎにも注意する

テーブルを分ける発想を覚えると、今度は逆に、細かく分けすぎてしまうことがあります。関連性の薄い情報まで無理にテーブルを分けると、確認したい内容を見るために、何度もテーブルを行き来する必要が生まれ、かえって扱いにくくなります。

目安は、「一緒に見たい情報かどうか」です。申請日と申請者は、申請の内容を確認するときにいつも一緒に見る情報なので、同じテーブルに置きます。一方、申請者の入社年や資格情報のように、申請の確認では必要としない情報は、別のテーブルに分けたほうが見通しがよくなります。分ける・分けないの判断に唯一の正解はなく、実際に使いながら調整していく前提で、まずは大きな塊を1つ作ってみることをおすすめします。

💡 ポイント データの持ち方の見直しは、後回しにするほど対象のレコード数が増え、直す作業が重くなります。「あれ、これは詰め込みすぎているかもしれない」と感じた最初の瞬間が、直す最適なタイミングです。

まとめ

このレッスンでは、以下のことを学びました。

データの基本単位は、テーブル（表）・レコード（1行分）・フィールド（1列分の項目）である
表と表をつなぐ「リレーション」を使うと、情報の重複と書き換えの手間を減らせる
「一覧ビュー」と「詳細ビュー」を使い分けると、同じデータを目的に応じて見せられる
1つの表にすべてを詰め込まず、役割ごとにテーブルを分けると、あとからの変更に強くなる
情報の重複入力や、横方向に並ぶ同じ種類の項目は、直しにくい設計のサインである

次のレッスンでは、ここまで学んだトリガー・アクション・条件分岐、そしてテーブル・レコード・リレーションという2つの共通言語を使って、実際に申請・台帳・集計といった業務アプリを組み立てる発想を扱います。

確認クイズ

このレッスンの理解度をチェックしましょう。