「在庫管理に使っている Excel が、もう重すぎて現場のスマホでは開けないんです」「先週、二人が同時に同じ行を直したら、片方の入力がまるごと消えていました」——脱 Excel の相談を受けると、最初に出てくるのはたいていこの種の生々しい症状です。表計算ソフトは、一人が手元で集計するぶんには優秀ですが、現場の複数人が同時に書き込み、外出先のスマホから入力し、入力ミスを防ぎたい、という業務の道具としては早々に限界を迎えます。にもかかわらず、専用システムを発注するほどの予算も時間もない。その板挟みのまま、壊れかけの Excel を騙し騙し使い続けている現場は、本当に多い。
ここで現実的な選択肢になるのが、Google の AppSheet です。AppSheet は、Google スプレッドシートやドライブに溜まったデータを土台にして、入力フォーム・一覧・検索・モバイル画面を備えた業務アプリを、プログラミングなしで作れるツールです。「スプレッドシートが使えるなら最初の一歩は踏み出せる」と言われるほど敷居が低く、エンジニアを雇わずに脱 Excel を始められる。ただし、触ってみると簡単に動くものができる一方で、「現場で毎日壊れずに回るアプリ」にするには、データの持ち方と権限の作り込みで差が出ます。本記事では、AppSheet で業務をアプリ化するときにどこでつまずき、受託でどう設計し内製化まで支えるかを整理します。
AppSheet が向く業務、向かない業務
まず押さえたいのは、AppSheet が「何でも作れる魔法の道具」ではないことです。向き不向きをはっきりさせておくと、期待値のズレで失敗しません。
AppSheet が得意なのは、台帳に対してデータを足したり直したりする業務です。在庫の入出庫記録、設備や車両の点検報告、現場からの日報、顧客への訪問記録、備品の貸出管理。こうした「一覧があり、そこに人が入力し、状態が更新されていく」タイプの業務は、AppSheet の土俵そのものです。スマホからの入力、写真の添付、入力必須や選択肢の制御、条件に応じた通知まで、ノーコードの範囲で十分組めます。
逆に、複雑な会計計算をリアルタイムで回す、大量データを高速に集計分析する、外部システムと密に連携した独自ロジックを持つ、といった用途は、ノーコードの枠を超えます。ここを無理に AppSheet で押し通すと、かえって保守しづらいものになる。「台帳系の業務はアプリ化、複雑なロジックは別の手段」と切り分けるのが、最初の勘所です。なお、同じく Google Workspace の自動化でも、メールやチャットを横断してタスクを自動で進めるエージェント型の自動化は Workspace Studio の記事 で扱った領域で、AppSheet の「データを扱うアプリ」とは役割が異なります。
「動くもの」と「現場で回るもの」を分ける三つの作り込み
AppSheet で最初のアプリを作ること自体は、半日もあればできます。問題は、その先です。研修を 2〜3 回受ければ簡単なアプリは作れるようになる、と言われるほど入口は易しい。だからこそ、入口で止まったアプリが「動くデモ止まり」になりやすい。現場で毎日回るアプリにするには、見た目に表れない三つの作り込みが要ります。
一つ目は、データ設計です。Excel をそのまま 1 枚のシートに横長で持っていると、入出庫の履歴と現在の在庫が混ざり、集計が壊れます。AppSheet を活かすには、「マスタ（商品や顧客の台帳）」と「トランザクション（入出庫や訪問の記録）」をシートで分け、互いを ID で結ぶ、という最低限のデータ構造が必要です。ここを整えるかどうかで、後の拡張性も同時更新の安全性もまるで変わります。スプレッドシート側の整え方は Google スプレッドシート自動化の記事 の考え方とも地続きです。
二つ目は、権限と共有範囲です。アプリの土台はスプレッドシートなので、元のシートの共有設定が緩いと、アプリ経由でなくシートを直接開いて誰でも全データを見られてしまいます。誰がどの行を見て・直してよいかを、アプリ側だけでなくシートの共有設定まで含めて設計する必要があります。これは Google ドライブ共有設定の記事 で扱った「利便性とセキュリティの両立」が、そのままアプリの土台に効いてくる場面です。
三つ目は、入力の制約と現場の使い勝手です。必須入力、選択肢の固定、数量がマイナスにならない制御、重複登録の防止——こうした「人が間違えても壊れない」工夫を入れて初めて、現場の入力品質が保てます。現場が片手間のスマホ操作でも迷わない画面にできているか。ここを詰めずに配ると、結局「入力されない」「間違って入る」で形骸化します。
弊社の事例: 点検 Excel をアプリにしたら、内製で育ち始めた
具体例を挙げます。ある設備保守の中堅企業（社名は伏せます）から、「現場の点検記録が Excel と紙でバラバラで、月末の集計に毎回まる二日かかっている。何とかしたいが、専用システムを入れる予算はない」という相談を受けました。現場はスマホを持って各拠点を回るのに、記録は事務所に戻ってから Excel に転記する運用で、転記漏れも誤記も日常茶飯事だったそうです。
私たちはいきなり完成形のアプリを納品する進め方を取りませんでした。まず、点検対象の設備マスタと点検記録のトランザクションにデータを分け直し、写真添付と異常時の必須コメントを備えた最小限のアプリを AppSheet で組んで、一つの拠点だけで二週間使ってもらいました。現場から「この項目は選択式にしてほしい」「異常があったら所長にすぐ通知してほしい」という声が出てくるたびに、その場で直して反映する。動くものを早く現場に当て、使いながら育てる進め方です。集計はスプレッドシート側に自動で溜まるので、月末まる二日かかっていた作業は、ほぼボタン一つに変わりました。
ただ、この案件でいちばん効いたのは集計の時短ではありませんでした。点検記録のデータ構造を整え、アプリの直し方を現場の担当者に引き渡したことです。データのマスタとトランザクションが分かれている意味と、AppSheet 上での項目の足し方を伝えたところ、その後の細かな改修——点検項目の追加や通知先の変更——は、担当者が自分でこなせるようになりました。受託として「作って終わり」にせず、現場が自分で育てられる土台にしたことが、結果としていちばん喜ばれた点です。
アプリ化を検討する前に確かめたいこと
AppSheet での脱 Excel を考えるなら、発注の前に二つだけ確かめておくと判断を誤りません。
一つは、その業務が「台帳にデータを足していく」型かどうか。一覧があり、人が入力し、状態が更新される業務なら AppSheet の土俵です。複雑な計算や分析が主役なら、別の手段を検討したほうが結果的に安く済みます。もう一つは、作った後を誰が育てるかを最初から決めておくこと。ノーコードの利点は内製で改修し続けられることなので、引き渡しと教育まで含めて設計しないと、結局また「触れない人が増えるだけの仕組み」に逆戻りします。
現場の Excel が限界で何から手をつけるか分からない、AppSheet を触ってみたが現場に配れる形にならない、作ったアプリを自社で育てられるよう引き継ぎまで含めて頼みたい——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。いまの Excel と業務の流れを拝見し、どこをアプリ化すると効くか、どこは無理にアプリ化しないほうがよいかを率直にお見立てしたうえで、現場で回り、自社で育てられる形へご一緒に組み上げます。
