目次
FAXと電話で受けた注文を、いったん紙に書く。それを事務所で誰かがまとめてスプレッドシートに転記する——受発注まわりのご相談で、いちばんよく聞く景色です。
この工程は、時間がかかるだけでなく、転記のタイミングまで受注状況が誰にも見えないという問題を抱えています。夕方にまとめて入力するなら、日中の受注は担当者の手元の紙にしか存在しません。
実案件（匿名）では、この最初の1工程だけをAppSheetでアプリ化しました。在庫も請求も、最初は入れていません。この記事では、その最小構成の中身と、後で困らないための設計判断を整理します。
この記事の結論
- 受発注は「受注を1件登録する」だけから作る。在庫・請求は後回し
- 最小構成でも受注ヘッダ・明細・マスタの3テーブルに分ける
- マスタのキーを決めずに作り始めると、必ず作り直しになる
AppSheetで受発注管理を作るときの最小構成とは
AppSheetは、スプレッドシートなどのデータをもとに、スマホアプリとPC画面を同時に作れるツールです。ノーコードで作れるぶん、「せっかくだから在庫も請求も」と欲張りやすいのが落とし穴になります。
最小構成とは、紙をなくすのに必要な最低限の範囲です。今回でいえば「受注を1件、その場で登録できる」だけ。集計も帳票も、この段階では作りません。
理由は3つあります。
- 効果が早く出る。紙の転記は、受注登録がアプリになった時点で消える
- 現場が覚えることが少ない。入力項目が数個なら、説明は数分で終わる
- 間違えても戻せる。範囲が小さいほど、作り直しの痛みが小さい
「全部入りの受発注システム」を目指した瞬間、要件定義が数か月単位になり、現場の紙はその間ずっと残り続けます。小さく作って、先に紙を消すほうが早いのです。
最小構成に必要な3つのテーブルの分け方
受注登録だけと言っても、テーブル（データの表）は1枚では足りません。最小でも次の3種類に分けます。
| テーブル | 持つ情報 | 1件あたり |
|---|---|---|
| 受注ヘッダ | 受注日・取引先・担当者・受注番号 | 1受注に1行 |
| 受注明細 | 商品・数量・単位・単価 | 1受注に複数行 |
| マスタ | 取引先、商品などの一覧 | 固定の基礎データ |
なぜ最初から明細行を持たせるのか
ここが今回いちばん大事な判断です。
受注登録だけなら、「取引先」「商品」「数量」を1行に詰め込んだ1テーブルでも動きます。実際、そのほうが作るのは速い。しかし、あとから集計や帳票を足す段階で必ず行き詰まります。
- 1受注で3品目を受けたとき、1行に収まらない
- 商品別の数量を集計しようとすると、1行の中身を分解する処理が必要になる
- 納品書や請求書に明細を並べられない
最初から明細を別テーブルにしておけば、集計も帳票も「明細を足し上げる」だけで済みます。作り直しコストを先に潰しておくのが、最小構成でも譲らないポイントです。
マスタは「選ばせる」ためにある
取引先名や商品名を毎回手入力させると、表記ゆれが溜まります。「株式会社」と「(株)」、全角と半角。これが混ざった時点で、集計は使い物になりません。
マスタを用意して、現場には選択させるだけにします。入力が速くなり、データもそろう。一石二鳥です。
現場はスマホ、事務所はPC——入力端末の違いをビューで吸収する
受発注アプリで意外と効くのが、使う人によって画面を変える設計です。AppSheetは、データを1つに保ったまま、ビュー（画面）だけを切り替えられます。
| 現場・外出先（スマホ） | 事務所（PC） | |
|---|---|---|
| 主な操作 | 受注を1件登録する | 一覧確認・修正・進捗管理 |
| 画面 | 入力項目を絞ったフォーム | 表形式の一覧＋詳細 |
| 求めるもの | 速さ・押しやすさ | 一覧性・修正のしやすさ |
現場に事務所と同じ画面を出すと、項目が多すぎて入力が止まります。逆に事務所にスマホ用のフォームだけ出すと、全体が見えず確認作業ができません。
実案件（匿名）でも、現場のスマホは「取引先を選ぶ → 商品を選ぶ → 数量を入れる」の最短動線に絞り、備考や社内メモは事務所側の画面でだけ触れるようにしました。同じデータを見ているのに、見え方だけが違う。これがAppSheetを使う一番の理由と言ってもいいくらいです。
なお、AppSheetの機能やプランの条件は変わるため、最新は公式サイトで確認してください。
内製する前に決めておくべきこと：マスタのキーを何にするか
ノーコードで作れると、つい手を動かしたくなります。ただ、着手前に1つだけ決めておいてほしいことがあります。マスタのキー（各行を一意に識別する項目）を何にするかです。
よくあるのは、取引先マスタのキーを「取引先名」にしてしまうパターン。これは危険です。
- 社名変更が起きると、過去の受注データとのつながりが切れる
- 同名の別会社、支店違いが出てきたときに区別できない
- 表記を1文字直しただけで、紐付きが外れる
キーには、業務上は意味を持たない番号やIDを使います。取引先コード、商品コードのような形です。すでに社内で使っているコード体系があるなら、それをそのまま使うのが最も摩擦が少ない。
この順番を守れば、後工程を足すときに土台を壊さずに済みます。逆に、キーをあいまいなまま作り始めたアプリは、データが数か月ぶん溜まった頃に手当てが必要になり、そのときには移行作業まで発生します。
小さく始めて、あとから足す
まとめると、受発注のAppSheet内製はこう進めます。
- マスタのキーを決める（取引先・商品のコード体系）
- 受注ヘッダ／明細／マスタの3テーブルを用意する
- 受注登録だけ動かす（現場スマホ用のフォーム＋事務所PC用の一覧）
- 運用が回ってから、集計・帳票・在庫・請求を足していく
3までなら、範囲は小さく、現場が覚えることも少ない。それでいて「紙に書いて事務所で転記する」という一番重い工程は、この時点で消えます。
よくある質問
Q. AppSheetで受発注管理は作れますか？ 作れます。ただし在庫・請求まで一度に含めると破綻しやすいため、まず「受注を1件登録する」最小構成から始めるのが現実的です。受注ヘッダ・明細・マスタの3種類のテーブルがあれば動きます。
Q. 受発注アプリは最初からどこまで作るべきですか？ 最初は受注登録の1工程だけで十分です。ただしテーブル設計では最初から明細行を持たせておきます。ヘッダだけで作ると、後から集計や帳票を足す段階で作り直しになります。
Q. 現場のスマホと事務所のPCで入力画面は分けられますか？ 分けられます。AppSheetはデータを1つに保ったまま、端末や利用者ごとにビュー（画面）を変えられます。現場は入力項目を絞ったフォーム、事務所は一覧と修正しやすい画面という作り分けが基本です。
まとめ
- 受発注アプリは受注登録の1工程だけから作る。在庫・請求は後回しでいい
- 最小構成でも受注ヘッダ／明細／マスタに分け、明細行は最初から持たせる
- 現場スマホと事務所PCの違いは、データではなくビューで吸収する
- 着手前にマスタのキーを決める。名前をキーにすると後で必ず困る
RENOYでは、AppSheetを使った業務アプリの設計・開発から、社内で運用が回るまでの伴走を行っています。「うちの受発注は、どこから手をつければいいのか分からない」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。