google フォーム スプレッドシート 集計｜現場の報告を1枚に集める

「月末の集計に、毎回半日くらいかかっているんです」

業務を整理するご相談で、いちばんよく聞く言い方のひとつです。それで実際の流れを画面と手元の書類まで見せてもらうと、集計そのものはほとんど時間を使っていないことが多い。合計や件数はスプレッドシートの関数で出ていて、そこは数分で終わっています。時間を食っていたのは、LINEに送られてきた写真、メールの本文に書かれた報告、事務所に戻ってきた手書きの紙を見ながら、シートの行に打ち直している工程でした。

この記事では、現場やスタッフから上がってくる報告・申請・点検・棚卸しの記録を、Googleフォームで受けてスプレッドシートに集めるときに、業務側で何を決めておくかを整理します。フォームの作り方の手順ではなく、入力の受け皿としてどう設計するかの話です。

集計に時間がかかるのは、集計しているからではなく、集めていないから

報告や記録が集まってくる経路は、たいてい一本ではありません。ベテランの人はLINEで写真を送ってくる、事務所にいる人は口頭で伝えてくる、外部の協力会社はメールで文章を送ってくる、現場は紙に書いて持ち帰る。悪気があるわけではなく、それぞれがいちばん早い方法を選んだ結果です。

ただ、経路が分かれると、必ずどこかに合流させる人が必要になります。その人が読んで、判断して、表の形に直す。これが転記です。集計が重いと感じている会社のほとんどで、重いのは計算ではなくこの合流の作業でした。だから関数を工夫しても、マクロを足しても、体感はあまり変わりません。速くしたい工程の手前に、人が読んで打ち直す工程が残っているからです。

考え方を逆にします。集計を速くするのではなく、入る時点で表の形にしておく。Googleフォームは、この「入る時点の形」を決めるための道具として位置づけると分かりやすいです。入力する項目と選べる答えを先に決めて、送信された答えを1枚のシートに落とす。その1枚が、そのまま集計の材料になります。

言い換えると、フォームの価値は「入力が楽になること」より「答えの形が揃うこと」にあります。楽さだけで比べるなら、現場にとってはLINEに写真を1枚送るほうが速いのです。それでもフォームにする理由は、集める側が毎月やっていた読み替えの作業をなくすためです。ここを説明せずに「これからはフォームで出してください」とだけ伝えると、なぜ手間の増える方法に変えるのかが伝わらず、運用は続きません。

フォームで受ける前に決める4つ

フォームを作る作業自体は、項目を並べるだけなので短時間で終わります。うまくいくかどうかを分けるのは、その前に業務側で決めておく次の4つです。ここが決まっていないフォームは、回答は集まるのに集計できない、という状態になります。

このうち最初の「1件とは何か」が、いちばん後戻りしにくいところです。たとえば点検の報告を受けるとき、1回の送信で複数の箇所をまとめて書ける形にすると、あとで箇所ごとに数えたくなったときに分解できません。逆に箇所ごとに1件として受ける形にすると、現場は同じフォームを何度も送ることになるので、そのぶん入力が短く済むように項目を削る必要があります。どちらが正しいということではなく、後で数えたい単位に1行を合わせるという順番で決めます。

集計できない表を前にすると、集計のやり方を工夫する方向に手が伸びます。ですが、ほとんどの場合そうではありません。集計できない表は、集計のやり方が悪いのではなく、1行の意味が揃っていないのです。関数で直せるのは揃っている表のズレだけで、意味の不一致は直せません。

自由記述をなくす、の意味（選択肢の設計）

「自由記述をなくしましょう」という言い方をすることがありますが、全部を選択式にするという意味ではありません。線を引く場所は決まっています。

• 集計する項目は選択式にする：担当者、種別、場所、判定（問題なし／要対応など）。数えたい・分けたい項目は、必ず選ぶ形にします
• 集計しない項目だけ自由記述にする：備考、気づいたこと、次に見てほしいこと。読むための情報は、文章のまま受けたほうが役に立ちます

この線引きをすると、フォームは「数える部分」と「読む部分」がはっきり分かれます。読む部分を集計しようとすると無理が出るし、数える部分を文章で受けると揺れが出る、というだけの話です。

選択肢を作るときにつまずきやすいのは、次のあたりです。

• 選択肢が増え続ける：当てはまらない答えは「その他」に逃げるので、放っておくと「その他」に中身が溜まります。対処は、月に一度「その他」の内容を見て、繰り返し出ているものを選択肢に昇格させ、使われていない選択肢を減らす日を決めておくこと。増やす担当と減らす担当を決めていないフォームは、必ず選択肢が肥大します
• 選択肢の名前が現場の呼び方と違う：管理側の正式名称で並べると、現場は自分が扱っているものがどれか分からず、近いものを選ぶか「その他」に書きます。略称や現場の言い方で作り、正式名称との対応は集計側で持ちます
• 人の名前を自由記述にする：姓だけ、フルネーム、ひらがな、社内の呼び名が混ざり、担当者別に数えられなくなります。人はほぼ必ず選択式にする項目です
• 日付を自由記述にする：書き方が揃わず、期間で絞れなくなります。日付は日付として受け取れる形にして、フォームを送った時刻とは別に「いつの記録か」を持たせます

回答シートを直接いじると壊れる（受け皿の2段構え）

フォームの回答は、連携させたスプレッドシートの回答シートに1行ずつ追記されていきます。ここまで来ると、あと少し手を加えれば使える表に見えるので、その場で列を足したくなります。ここが分かれ目です。回答シートに手を入れると、回答が増えるたびに崩れます。

• 回答シートに手で書き足した列が、あとから入った回答の行とずれて、別の回答の横に付いてしまう
• 見やすくするために並べ替えたり行を挿入したことで、回答と手入力の対応が崩れる
• フォームの項目を追加・削除したときに列の位置が変わり、参照していた式や色分けが合わなくなる
• 誤入力を直したいが、回答シートを書き換えるとフォーム側の記録と食い違い、どちらが正しいのか分からなくなる

対処はシンプルで、受け皿を2段にします。

1. 1段目＝回答シート：フォームが書く場所。人は読むだけで、加工しない。列を足さない、並べ替えない、色を塗らない
2. 2段目＝集計シート：1段目を参照して、必要な形に組む場所。区分の付け替え、判定、期間での絞り込み、合計はすべてこちらでやる

この分け方をしておくと、フォームの項目を増やしたときも、壊れるのは2段目の参照だけになります。1段目に人の手が入っていると、直すべき場所が「式」と「人が書いた内容」の両方になり、どこまでが正しい記録なのか分からなくなります。

そのうえで、訂正が避けられない業務では、訂正用のフォームを別に立てる形をおすすめしています。対象（どの記録か）と、訂正内容を入れるだけの短いフォームです。集計シートでは、元の記録に訂正を当てた後の値を組み立てます。ポイントは、直すのではなく、訂正の記録を足すことです。会計や在庫の記録で、間違いを消さずに打ち消す行を立てるのと同じ考え方で、誰がいつ何を訂正したかが残ります。現場から「あれ、間違えたので直しておきました」と言われたときに、何がどう変わったのか分からなくなる状態を防げます。

写真・PDFを受けるときの注意

点検や工事の報告では、写真を受け取りたいという要望がほぼ必ず出てきます。フォームでファイルを受けることはできますが、受け取った瞬間に「これはどの案件のどの工程の写真か」が分からなくなるケースをよく見ます。ファイルは集まっているのに、使えない状態です。

• ファイルの項目と一緒に、対象を選択式で必ず取る：案件、場所、工程。写真だけ受けて、対象を写真の中身から判断させる形にしないことです
• ファイル名に頼らない：現場のスマホが自動で付ける名前は端末ごとに違い、順番も内容も分かりません。名前で管理する前提の運用は続きません
• 集めるだけで終わらせない：誰がいつ見て、どうなったら完了なのかを決めます。ここが決まっていないと、写真は溜まる一方で、見ていないことに誰も気づきません

なお、ファイルの受け取りについては、設定によって回答する人にログインを求める形になります。社内だけで使うなら問題になりにくいのですが、協力会社や社外の方に出すフォームでファイルを受けたい場合は、相手側の環境で送信できるかを事前に確認してください。ここは設定や仕様が変わることがあるので、断定せずに、実際に受け取る相手の端末で一度試すのがいちばん確実です。

GASで足すのはどこか（集計の前ではなく後ろ）

フォームとスプレッドシートだけで足りる業務は、思っているより多いです。そのうえで、Google Apps Script（GAS）を足す価値がはっきりしているのは、主に次の2つです。

• 条件に当たった回答を、関係者に知らせる：判定が「要対応」だったときだけ担当に伝える、期限が近い申請を知らせる、といった用途です。何を条件にするかを先に決める必要があるので、メールを送る前に決める判定条件で整理しています
• 回答を別の台帳に振り分ける、締めた分を移す：種別ごとに担当のシートへ振る、月次で確定した分を別のシートへ移す、といった処理です。どこまで任せられるかはGASでできることにまとめています

逆に、集計の計算そのものはGASを書かずに関数で足りることが多いです。合計や件数、期間での絞り込み、区分ごとの並べ替えは、シートの機能の範囲で組めます。ここをスクリプトにすると、動いている間は問題なくても、止まったときに直せる人が減ります。作った人が離れた後に触れなくなる作り方の危うさは、作った人しか直せないツールのリスクで書きました。

私たちが順番として大事にしているのは、まず関数とシートの分け方で組んでみて、それでも人が毎回やらなければいけない作業が残ったときに、その1つだけをスクリプトに任せることです。書かずに済む範囲は書かない。これは技術的な保守性の話というより、誰が面倒を見続けるのかという運用の話です。

フォームで足りる範囲と、足りなくなる境目

フォームで足りるのは、次のような業務です。出したら終わりの一方通行の入力であること。1件の情報が、入力する時点で確定していること。入れた人以外が、あとから中身を更新しないこと。点検の記録、日々の棚卸し、簡単な申請の受付、アンケート的な報告はここに入ります。

足りなくなる境目は、経験上4つに整理できます。

1. 入れたあとに状態が変わる：申請 → 承認 → 完了のように進む業務です。フォームは送信した時点の記録を残すもので、状態を持つ仕組みではありません。承認欄をシート側で手で塗る運用にすると、そこが新しい属人化になります
2. 前の回答を見ながら入れる必要がある：前回の値、在庫の残り、途中まで進んだ進捗。フォームは基本的に前の記録を見せないので、現場は別の画面と行き来することになります
3. 人によって見えてよい範囲が違う：他の人の回答や、金額・個人情報を見せたくないケースです。シートの共有だけで線を引こうとすると、どこまで見えているかを説明できなくなります
4. 回答が増え続け、集計や連携が重くなる：溜まった行に対する処理は、いつか実行の上限に当たります。当たったときの分け方は6分で止まる処理を分けて回す設計で扱っています

境目に当たったときに、全部をシステムに作り替える判断を急ぐ必要はありません。多くの場合、困っているのは状態を持つ必要がある1つの業務だけです。そこだけを外に出して、残りはフォームとスプレッドシートのままにする。どこで線を引くかの考え方はExcel業務をシステム化する判断で整理しています。

そもそも何をフォームで受けるかを決める段階では、業務の棚卸しから入るほうが早いこともあります。報告や申請の種類を並べてみると、似た内容を別の経路で二重に受けているものが見つかることが多いからです。手順は業務棚卸しのやり方にまとめました。フォームを増やす前に、受ける対象を減らせるかを見ておくと、あとの運用が軽くなります。

まとめ

集計が重いと感じたときに見るのは、計算の工程ではなく、その手前です。LINEやメールや紙で受けたものを人が読んで打ち直しているなら、集計を速くするより、入る時点で表の形にするほうが効きます。Googleフォームは、その「入る時点の形」を決めるための道具です。

決めるのは4つ。1件とは何か、誰が入れるか、選ぶのか書くのか、いつ入れるか。集計する項目は選択式にして、集計しない項目だけ自由記述に残します。選択肢は増やす運用と減らす運用の両方を決めます。回答シートは加工せず、参照する集計シートを別に持つ2段構えにして、訂正は直すのではなく記録を足す形にします。

そして、入れたあとに状態が変わる業務はフォームでは持てない、というのが境目です。私たちがツールの選定より前に業務プロセスの構造化に時間をかけるのは、この線を引かないまま道具を足すと、集める場所が増えるだけで、合流させる人の仕事が減らないからだと考えています。まずは今いちばん重い集計を1つ選んで、その1行が何を表しているかを言葉にしてみるところからで十分だと思います。