古物商の現場入力をスマホ化したGAS Webアプリ開発対応事例

この記事は、公開アプリや配布ツールの紹介ではなく、開発請負で対応した開発対応事例です。顧客名、実データ、個人情報、案件固有の運用情報は出さず、同じような業務改善に転用できる考え方だけを整理しています。

古物商の買取・払出業務では、商品情報、本人確認方法、事業主区分、在庫、経費、日報に近い報告など、現場で扱う項目が多くなりがちです。そこで、現場スタッフはスマートフォンの専用フォームから入力し、管理側はGoogleスプレッドシートで確認できる形に整えました。

対応した業務

今回の中心は、既存の表計算運用を完全に捨てるのではなく、Google Apps ScriptのWebアプリで入力画面だけを現場向けに作り直すことです。

主な入力対象は次のような業務です。

管理側は、入力されたデータをスプレッドシート上で確認し、日別・担当者別・業務別に集計できます。現場入力をスマートフォンに寄せつつ、管理者が慣れているスプレッドシートの一覧性は残す構成です。

スマートフォンでスプレッドシートを直接編集する方法でも、簡単な入力なら対応できます。ただ、項目が増えると列が多くなり、横スクロールや入力セルの選択だけで負担が大きくなります。

特に、買取・払出のように入力ミスが後工程へ影響しやすい業務では、単に表へ直接入力できるだけでは十分ではありません。

構成は、スマートフォン向けの入力画面、HTML Serviceで作るGAS Webアプリ、Googleスプレッドシートの管理表というシンプルな形です。

この構成の利点は、専用サーバーや大きな基幹システムを最初から用意しなくても、業務に合わせた入力画面を比較的低コストで作れることです。すでにスプレッドシートで管理している業務なら、既存の表や集計の考え方も活かしやすくなります。

入力画面は、業務ごとにタブを分けました。受入、払出、経費、ビラ配り、キャッチ報告を同じ入口から扱えるようにし、現場スタッフがどこへ入力すればよいか迷いにくい構成にしています。

選択肢は、コード内に固定せず、設定シートや名前付き範囲から取得します。担当者、来店要件、本人確認方法、事業主区分、古物かどうかなど、後から変わりやすい項目をマスタ管理しやすくするためです。

また、選択肢にない値が出てきた場合は、手入力してから確認後に設定へ追加できる形にしました。現場業務では、最初からすべての選択肢を完全に洗い出せないことがあるため、後から運用を育てられる余地を残しています。

払出では、IDや商品名から商品を検索し、残り在庫を確認できるようにしました。入力数が在庫数を超える場合は登録を止めることで、在庫管理上のずれを減らします。

そのほか、郵便番号7桁から住所を補完する処理、全角数字を半角数字へ変換する処理、必須項目や形式エラーを淡い赤で強調する処理も入れています。

GAS Webアプリでは、画面側からサーバー側の関数を呼ぶときにgoogle.script.runを使います。通信中の表示、成功時の反映、失敗時のメッセージ表示を共通化しておくと、入力タブが増えても実装が崩れにくくなります。

スプレッドシートへの書き込みでは、列番号を直接コードへ散らばせないようにしました。ヘッダー名や名前付き範囲を基準にしておくと、列追加や並び替えに比較的強くなります。

郵便番号検索のように外部APIを使う処理では、空レスポンスやJSON形式の崩れも想定します。便利な補完機能であっても、外部サービスの応答に依存しすぎると現場入力が止まるため、失敗時は手入力へ戻れるようにしておくのが重要です。

入力値の正規化も地味に効きます。日本語の業務フォームでは、全角数字と半角数字が混ざりやすいため、金額、数量、郵便番号などは登録前に整えるだけでも後続の集計が安定します。

この方式は、次のような業務に向いています。

逆に、厳密な権限管理、大量アクセス、高度な監査ログ、法的判断そのものをシステムに任せるような用途では、別の構成を検討した方がよい場合があります。この記事は古物営業法などの法的助言ではなく、入力・管理業務を効率化した対応事例として整理しています。

スプレッドシート業務をWeb化するときは、いきなり大きなシステムへ置き換えるより、まず「現場が入力しやすい画面」と「管理側が見慣れた表」を分けるだけでも効果があります。

GASとGoogleスプレッドシートを組み合わせると、スマートフォン入力、入力チェック、マスタ管理、在庫確認、日別・担当者別の管理を小さく始められます。既存のスプレッドシート運用を活かしながら、現場入力を楽にする開発対応の一例として参考にできます。