AppSheet設計のポイント(1) 最小限のデータではじめよう
―――「ノーコードツールを使えば “誰でも簡単にアプリが作れるらしい” から、とりあえず社内のアレやコレやソレで使うアプリを作ってみて。よろしく！」
と、エライ人から指示されたので少しググってみると、あちらこちらに “小さく始めることが大事” と書いてある。なるほどなるほど。じゃあ早速やってみよう！と始めると、順調だったのはチュートリアル（初心者用の教材）だけ。指示されたアプリを目指して作っては壊し作っては壊しで、いつまでたっても進捗はゼロ。ツールの操作は覚えたけど、作りたいアプリが完成しない。（あるIT担当者の話）
―――ノーコードツールを使えば “誰でも簡単にアプリが作れる” のか！それならITに詳しい社員にやらせてみよう。既製品のアプリではカバーできないうちの業務専用のアプリがあれば、どんどん効率化が進むだろう。
と目論み、社員に指示してから半年。最初のチュートリアルでは、“こんなに簡単にアプリが作れるのか！” と2人で感動したが、いまだ使えるアプリは1つも完成しない。たまに最初から作り直したアプリを見せにくるが、完成にはほど遠い。（ある中小企業経営者の話）
こんなことないですか？
新しいことを始める時に『小さく始めることが大事』なのは間違いないし、新しいITツールで遊んでみたり試行錯誤してみたりも大事。その過程で作ってみたアウトプットは何度でも捨てて、何度でも作り直せばいい。全部間違いない。ただし、“余裕があれば” ね。
中小企業のIT活用には、『開発予算や社内リソースの不足』という現実が重くのしかかります。なんとか予算を確保して外注しても、打ち合わせや要件定義に手間と時間がかかり、思うように進まないことも多い。それならば内製しようとノーコードツールを使って小さく始めてみるけど、それも前述の通り簡単には上手くいかない（ことも多い）。
そこで今回から何度かに分けて、アプリ開発をはじめる際に重要な設計のポイントを整理します。初回のテーマは『データ構造』です。
特に、アプリ開発の初期段階でなるべくシンプルに整える方法を具体例とともに解説し、実際に運用を開始するまでのハードルを下げることを目指します。さらにシンプルさを保つだけでなく、データ構造において最低限考慮しておかなければいけないKeyやデータ型、データの命名にも触れようと思います。
前述のIT担当者や中小企業経営者と同じような悩みがあるなら、参考になると思います。この記事を参考に、スムーズにアプリの内製を進めてください！
AppSheetとは？
この記事では、ノーコードツールとして『Google AppSheet』を使います。
AppSheetは組織内で使うアプリの開発に適しており、専門知識（プログラミング等）を必要とせず、シンプルなアプリを作れます。社内にITエンジニアがいなくても、小さく試しながら少しずつ拡張していけるのが大きな強みです。
しかし冒頭のエピソードのように、実際に作りはじめてみると、データやアプリの設計に戸惑い、途中で心折れてしまう方も少なくないようです。（著者の周辺調べ）
なぜ「最小限のデータではじめる」べきなのか
ノーコードによるアプリ内製を考えたとき、中小企業がまず取り組みたいのがアナログ管理（紙やExcelなど）からの脱却です。
冒頭のエピソードにもある通り、ノーコードによるアプリ開発は簡単に始められます。ただし、いざアプリを作り始めると「顧客管理」「在庫管理」「案件管理」などをまとめて開発しようとして、結果的に運用開始が遅れたり、挫折してしまったりするケースが “あるある” です。
ここでは、運用開始をスムーズにするためになぜ最小限のデータ構造が必要なのか、順を追って整理します。
アナログ管理から脱却には “まずは” 運用開始が必要
紙やExcelのまま管理を続けていると、データの更新漏れや重複入力などが生じやすく、業務の属人化も進みがちです。特に小規模な企業では、個人の記憶や手作業に頼ったままになり、ミスや作業負担が積み重なる傾向があります。
早めにアプリを動かすことが重要
まずはシンプルなアプリを作り、実際に社内で運用を始めることがメチャクチャ大事です。実際に使ってみると開発前には気づかなかった「もっとこうしたい！」が必ず発生します。その「もっとこうしたい！」を開発前に想像することは、ITエンジニアやITコンサルタントでも不可能です。
最小限の設計が、運用開始を後押しする
機能やデータ項目を詰め込みすぎると、作業や設定が複雑になり、結局リリースできないまま終わってしまう可能性があります。小さく始めるからこそ、社内で早期にテストを行い、アナログ管理から一歩抜け出すことが可能になります。
いきなり複雑にしすぎる失敗パターン
運用を始める前から多機能化を図り、「顧客管理」「在庫管理」「案件管理」などを一つのアプリに盛り込もうとすると、以下のような問題が起こりやすいです。
- テーブルや項目が膨大になり要件定義が複雑化
- エラーやデータ不整合が頻発
- 周知が追いつかず社内ユーザーが混乱
このように、いきなり大きく作ろうとすると、開発だけでなく運用面でも混乱を招きがちです。結果として「完成しない」「使われなくなる」といった失敗パターンに陥る可能性が高まります。
最小設計のメリット
運用開始を最優先するために、まずは「1テーブル・少数の列」から始めるのがオススメです。メリットは、以下の通り。
トラブルシューティングが簡単
項目が少ないので、トラブルシューティング（問題発生時の原因特定）しやすくなります。どの列や設定がエラーを起こしているかをすぐに突き止められれば、復旧も早いです。
運用しながら柔軟に拡張できる
AppSheetを使う場合、後から列を追加したり、別テーブルを紐づけたりするのは比較的容易です。最初に小さい設計で運用を始めれば、必要になったタイミングで機能を拡張できます。
逆に最初から複雑にすると、手に負えなくなります。
非エンジニアでも着手しやすい
列数や画面数が増えるほど、AppSheetの設定や管理は複雑化します。シンプルに設計しておくことで、ITリテラシーの低いメンバーでも扱いやすく、早期に成功体験を得るチャンスが高まります。
アナログからの移行ハードルを下げる
手作業で散らばっていた情報を1テーブルにまとめ、すぐに使い始められる形にするだけでも、大きな前進です。最小限の構造であれば、紙やExcel管理からの移行を心理的にも技術的にも進めやすくなります。
最小限のデータ構造でアプリを作り始めれば、運用を重ねるうちに「この項目も欲しい」「このステータスが必要だ」という具体的なニーズが明確になります。
失敗パターンの多くが、運用する前に大きく作りすぎて迷走してしまうことなので、まずは小さく運用してから必要な機能を追加するほうが、結果的にスムーズにシステム化できます。
サンプルテーブル：顧客リスト
この後の説明に使うサンプルテーブルです。
どの業種でもイメージしやすい『顧客（取引先）』を管理するシンプルな例で進めます。このテーブルを起点に、AppSheetで顧客管理アプリを立ち上げる際のイメージをつかんでいただければと思います。
データ構造
実際のAppSheetでは、下表のように列（項目）を定義します。
| 列名 | データ型 | 必須 | Key | 説明 |
|---|---|---|---|---|
| 顧客ID | テキスト | はい | はい | レコードを一意に特定するためのID AppSheetでは UNIQUEID() で重複を回避します |
| 顧客名 | テキスト | はい | いいえ | 法人名や個人名 |
| 電話番号 | テキスト(Phone) | いいえ | いいえ | スマホから発信できる |
| 担当者 | テキスト | いいえ | いいえ | 先方のメイン担当者名 |
| 登録日 | 日付 | はい | いいえ | データの登録日TODAY() などで自動入力させる |
| ステータス | Enum | いいえ | いいえ | 取引状況["新規","見込み","成約"] を設定 |
ポイント
- 主キー
「顧客ID」をKeyに設定し、_RowNumberは使わないのがおすすめ。行の削除や並べ替えによるズレを防ぎ、レコードの一意性を確保しやすくなります。 - データ型
「日付」や「Enum」を設定すると、AppSheetが入力フォームやプルダウンを自動で提供してくれます。誤入力を減らす効果も期待できます。 - 必須設定
「顧客名」「登録日」など、空欄だと困る列は「Required（はい）」にしておくと、保存時に入力漏れを防げます。
サンプルデータ
10件分のサンプルデータを用意しました。
| 顧客ID | 顧客名 | 電話番号 | 担当者 | 登録日 | ステータス |
|---|---|---|---|---|---|
| 9B2QX | ABC商事 | 011-123-4567 | 田中 太郎 | 2023/11/01 | 新規 |
| 5FP7Z | 山田製作所 | 011-987-6543 | 山田 花子 | 2023/11/02 | 見込み |
| 3NQAF | サクラ不動産 | 011-222-3344 | 佐藤 健 | 2023/11/05 | 新規 |
| 7DQLX | オレンジ企画 | 011-000-1111 | 小林 久美 | 2023/11/07 | 成約 |
| G1H2Z | 北海水産 | 011-333-6677 | 鈴木 太一 | 2023/11/08 | 新規 |
| 29KU8 | ひまわり物流 | 011-444-9911 | 田辺 優 | 2023/11/10 | 見込み |
| MW492 | ケイエム商店 | 011-555-1122 | 松本 隆 | 2023/11/11 | 新規 |
| P8XZ3 | Green Tech | 011-567-8888 | 伊藤 さやか | 2023/11/12 | 見込み |
| 64AJE | 旭川リフォーム | 0166-123-4567 | 後藤 晴彦 | 2023/11/13 | 新規 |
| YL59B | 札幌ケータリング | 011-777-2020 | 森田 佳代 | 2023/11/15 | 成約 |
顧客ID には UNIQUEID() が自動生成する文字列を想定しています。運用時にはユーザーが手動で変更できないように設定しておくと、誤ってIDが変わってしまうリスクを回避しやすいです。また、電話番号やステータスなどは業種によって増減する場合があるため、実際の運用状況を見ながら列の構成を追加・修正するとよいでしょう。
こうした最小限のテーブルを用意しておけば、AppSheet上で一覧表示、詳細表示、新規登録のフォームなどの画面を簡単に生成できます。
1テーブル（スプレッドシート1枚）からスタート
複数のテーブルをいきなり用意してしまうと、項目の関連づけや要件定義が複雑になり、初心者ほど途中で手が止まりがちです。
そこで最初は1つのテーブル（スプレッドシート1枚）だけを作り、簡単なサンプルデータを用意して小さく始めます。
シンプルさが最大の武器
最初は最低限の機能でテストできる
画面の一覧表示・詳細表示・新規登録フォームなど、基本的な操作だけでも、十分に運用テストが可能です。
操作に慣れやすい
列が多すぎないため、アプリの管理画面や設定項目がシンプルになります。非エンジニアがAppSheetの仕組みを学ぶ際のハードルが下がります。
“最小限”にする理由
初期設定やバリデーションが簡単
列を増やしすぎると、入力チェックや参照関係の設定が煩雑になりがちです。小さく始めれば、トラブルシューティングもすぐに行えます。
あとから追加しやすい
運用しながら「やっぱりこの項目も必要だ」と気づいたとき、あとから列を増やしても問題ありません。修正範囲が小さいため、シート全体を作り直す手間も最小限に抑えられます。
住所やメールアドレスがない理由
考慮すべきことが多くなる
住所なら入力フォーマットをどうするか、メールアドレスなら重複登録や送信設定など、検討点が増えます。
実際の運用を見てから判断できる
まずは運用してみて、「やはり住所があったほうがいい」「メルマガ配信用の列が欲しい」と感じた段階で追加すると、無駄が少なくなります。
このように、最小限のテーブルから始めることで、アプリ開発の成功体験を得やすくなるのが最大のメリットです。余計な項目を削ぎ落として、まずは動かしてみる。そこから少しずつ拡張していけば、管理や学習コストを抑えつつアプリを成長させられます。
主キー（Key）を設定し、_RowNumberは使わない
AppSheetでアプリを作る際には、主キー（Key） をどう設定するかが重要です。主キーはテーブル内のレコードを一意に識別するための列で、これを正しく決めておかないと、後からデータが混ざってしまったり、参照先との関連付けが崩れたりする恐れがあります。
ここでは、ランダム文字列をKeyにするメリットや、_RowNumberを使わない理由、そして運用時の注意点をまとめます。
ランダム文字列をKeyにするメリット
レコードの混同を防ぎやすい
UNIQUEID()などの機能を使い、自動生成されたランダム文字列を主キーに設定しておくと、重複や行の並び替えによるズレを防ぎやすくなります。
AppSheet公式の推奨方法
公式ドキュメントでも、「Keyには乱数文字列など、固定的に変わらない値」を使うことが紹介されています。将来的にテーブル間の参照設定（Ref）を行う際にも、安定して動作します。
_RowNumberをKeyにすると起きる問題
前述の公式ドキュメントにも『行番号キー（非推奨）』とある通り、_RowNumberをKeyとして使うのはオススメしません。
行番号が変動するリスク
スプレッドシートで行の削除やフィルターをかけたりすると、_RowNumberは簡単に変わってしまいます。
データ不整合が発生しやすい
主キーが書き換わったことで、参照関係や外部連携がうまく動作しなくなるケースがあります。社内で複数の人が編集を行う場合、そのリスクはさらに高まります。
実運用上の注意点
最初にしっかり決めておく
一度運用を始めてしまうと、Keyを後から変更するのは手間がかかります。最初の段階で乱数文字列を使う設計にしておけば、後のトラブルを大幅に減らせます。
Keyをユーザーが書き換えないようにする
ランダム文字列にしていても、ユーザーが手動で編集できる状態だと、思わぬところで誤更新が起こる可能性があります。AppSheetの列設定で「読み取り専用」にするなどの工夫が必要です。
こうした対策を行うことで、データの整合性を保ちつつ、スムーズにアプリを運用できるようになります。まずはKeyを適切に設定することが、ノーコード開発の成功を左右する大きなポイントです。
列の属性（データ型）を正しく設定する
AppSheetでは、各列のデータ型（Type）を指定することで、入力フォームやバリデーション（項目に対する入力値の妥当性確認）機能を自動で整備できます。
「日付」「数値」「テキスト」「Enum」など、あらかじめデータ型を決めておくと、手入力の際のブレや誤入力を最小限に抑えられるメリットがあります。
データ型設定の利点
日付型
たとえば「登録日」を日付型にすると、カレンダー形式の入力画面が自動で生成されます。日付のフォーマットや月日だけの入力ミスが減り、後々の集計も簡単になります。
Enum（プルダウン）
「ステータス」や「カテゴリー」のように選択肢が限られている列は、Enumに設定するとプルダウン式で入力できます。入力ブレを防げるだけでなく、集計や絞り込みもしやすくなります。
必須（Required）
「顧客名」や「登録日」など、どうしても欠かせない項目は必須にしておきます。空欄での保存を防ぎ、データ品質を保つうえで効果的です。
やりすぎは禁物
複雑すぎる設定は負担
最初からすべての列に厳密なバリデーション（電話番号はハイフン必須、メール形式チェックなど）をかけると、入力時に混乱が起きやすくなります。
徐々にルールを追加していく
まずは「日付」「テキスト」「数値」など大まかな型だけ設定し、実際に運用しながら必要に応じて詳細を詰めるのがオススメです。
このように、列のデータ型を適切に設定することで、アプリの使いやすさとデータの正確性を両立できます。
特に最初の段階ではシンプルな型とバリデーションにとどめ、運用を通じて必要性が高まったところで詳細ルールを追加していく流れが理想的です。
列名・シート名はわかりやすく統一する
地味ですが、列名やシート名の命名ルールをしっかり決めておくと、チーム全体でデータを扱う際の混乱を防ぎやすくなります。
AppSheetの設定画面やアプリ画面で、そのまま列名が表示される場面もあるため、ユーザーが理解できる名前をつけることが大切です。
命名の重要性
誰が見ても意味が分かる名称
「顧客名」「電話番号」「担当者」など、直感的に用途が伝わる名前を心がけます。
英語と日本語の混在は避ける
「CustomerName」「電話番号」「担当者」など、言語が混在すると混乱の原因になります。社内ルールとして「列名はすべて日本語で統一」など、方向性を決めておくとよいです。
シンプル・意味が通る名前を採用
長い列名は避ける
たとえば「お客様のご住所（都道府県・市区町村・丁目以下）を入力する欄」のように長いと、アプリ画面で見切れてしまうことがあります。必要に応じて列を分けたり補足説明を入れたりして、列名はなるべく短く保ちます。
シート名も分かりやすく
スプレッドシートが複数枚になる場合も、「顧客リスト」「在庫リスト」「請求リスト」のように名前だけで用途が分かるようにします。
一貫性が大事
後から列が増えてもルールを守る
列が追加されるときに命名ルールが崩れると、一気に見づらくなります。あらかじめ「列名は日本語」「頭文字は大文字で統一」など、簡単なガイドラインを作っておくと管理が楽になります。
初期段階で統一しておけば改名の手間が減る
運用後に大きく名前を変えると、AppSheetの設定や参照先などを修正しなければなりません。その手戻りを防ぐためにも、最初から分かりやすい名前で始めるのが無難です。
列名・シート名は、実際の操作画面だけでなくメンテナンスや拡張時の効率にも影響します。「どの列がどんな役割を持つか」をすぐに理解できる状態を作っておくことで、内製アプリ開発のメリットを最大限に生かしやすくなるでしょう。
まとめ
今回ご紹介したように、データ構造を最小限にすることは、ノーコード開発をスムーズに進めるための大きなポイントです。
要点を振り返ると、次の4つに集約できます。
最小限のデータ構造で始める
列を少なくしておくことで、運用ハードルを下げられます。
主キー（Key）を乱数文字列で設定し、_RowNumberは使わない
レコードの一意性を確保し、データ不整合リスクを回避します。
型や必須を最低限バリデーションする
「日付」「Enum」などを正しく設定することで、入力ミス削減や品質向上が図れます。
列名・シート名をわかりやすくし、チームでルールを揃える
意味が通るシンプルな名前を採用し、後々の運用や管理をスムーズにします。
最小設計だからといって、紙やExcel管理の課題を一瞬で解消できるわけではありません。ただし、小さく始めることでアプリ運用の第一歩を確実に踏み出せるのが大きなメリットです。ここで挫折しなければ、機能拡張やセキュリティ設定など、次のステップへ進みやすくなります。
次は『MVP（最小限の機能）でアプリを作る』をテーマにする予定です。
