GASで進捗管理アプリを作る方法：現場入力・写真添付・遅延通知までの構成例

進捗管理は、現場や担当者ごとの状況を早く正確に把握するために重要な業務です。

ただ、実際には電話、メール、チャット、紙のチェック表、Excel、スプレッドシートなどが混ざり、最新状況がどこにあるのか分かりにくくなることがあります。

「完了したと思っていた作業が止まっていた」「写真は送られているが一覧に反映されていない」「遅れている案件に気付くのが遅れた」といった問題は、進捗情報の集め方と見方が整理されていないと起きやすくなります。

GAS（Google Apps Script）を使うと、スマホやPCから進捗を入力し、スプレッドシートに保存し、写真をGoogleドライブへ保管し、一覧画面で確認し、必要に応じて遅延通知を送る仕組みを作れます。

この記事では、GASで進捗管理アプリを作る場合の構成例を、実務目線で整理します。コードの細かい話ではなく、中小企業や現場業務でどのように役立つのかを中心に解説します。

1. この記事で伝えたいこと

GASで進捗管理アプリを作る目的は、最初から大きな専用システムを作ることではありません。

まずは、今あるスプレッドシート管理を活かしながら、現場からの入力、写真の保存、一覧確認、遅延の把握を一つの流れにすることです。

たとえば、作業者がスマホで案件を選び、工程を更新し、必要なら写真を添付する。入力された内容はスプレッドシートに保存され、管理者は一覧画面で状況を確認する。予定日を過ぎている案件があれば、担当者や管理者へ通知する。この流れができるだけでも、確認の手間はかなり減ります。

GASを使うと、進捗データを起点に次のような処理をまとめて行えます。

• スマホやPCから進捗を入力する
• 入力内容をスプレッドシートに保存する
• 工程ごとのステータスを管理する
• 写真や添付ファイルをGoogleドライブに保存する
• 管理者向けの一覧画面を作る
• 遅延案件を自動で検出する
• 担当者や管理者へメール通知する

もちろん、進捗管理は業務ルールそのものと深く関わります。ステータス名、工程の区切り、誰が入力するか、誰が確認するかを曖昧にしたまま画面だけ作っても、現場では使いにくくなります。

そのため、GASで作る場合は「入力画面を作る」だけでなく、「現場が迷わず入力でき、管理者が早く判断できる状態を作る」と考えることが大切です。

進捗管理アプリで大切なのは、入力を増やすことではなく、確認の手間を減らすことです。現場にとっては、入力項目が多すぎると負担になります。管理者にとっては、情報が多すぎても、何を見ればよいのか分かりにくくなります。

そのため、最初から高機能な画面を作るより、まず「誰が」「どの案件を」「どの状態に更新したか」が確実に残る形を作る方が現実的です。そのうえで、写真添付、遅延通知、一覧の絞り込み、担当者別の集計などを段階的に追加すると、現場に定着しやすくなります。

GASは、GoogleスプレッドシートやGoogleドライブと相性がよいため、現場業務の小さな改善から始めやすいのが強みです。一方で、進捗管理は毎日使う業務になりやすいため、入力しやすさ、表示速度、権限、保守まで含めて考える必要があります。

2. 進捗管理でよく起きる困りごと

進捗管理でよく起きる問題は、情報が集まらないことと、集まった情報が見にくいことです。

たとえば、担当者が現場から電話で状況を伝え、管理者があとで表に入力している場合、聞き間違いや入力漏れが起きます。忙しい時間帯は連絡が後回しになり、一覧表の更新が実際の状況より遅れることもあります。

チャットで写真や報告を送っている場合も、最初は便利です。

しかし、案件数が増えると、どの写真がどの案件のものか分かりにくくなります。過去の投稿を探したり、別の一覧表へ転記したりする時間が増えると、進捗確認のための作業がまた増えてしまいます。

スプレッドシートだけで管理している場合は、入力しやすさが課題になります。

PCで入力する前提の表を、現場でスマホから直接編集するのは使いにくいことがあります。列が多い、入力する場所が分かりにくい、誤って別のセルを消してしまう、といった問題が出やすくなります。

遅延に気付きにくいことも大きな問題です。

予定日や期限を表に入れていても、毎日人が確認しなければ遅れを見逃します。件数が少ないうちは目視で確認できますが、案件が増えると、どれを優先して見るべきか分かりにくくなります。

さらに、進捗の定義が人によって違うと、一覧の意味が揃いません。

ある担当者は「作業中」を着手済みの意味で使い、別の担当者は確認待ちの意味で使っている場合、同じステータスでも実態が違ってしまいます。進捗管理アプリを作る前に、こうした言葉の定義を揃えることが重要です。

未入力の問題もよく起きます。現場では作業が終わっていても、入力が後回しになることがあります。管理者から見ると、作業が遅れているのか、単に入力されていないのかが分かりません。この区別ができないと、確認の電話やチャットが増え、結局アプリを入れる前と同じ状態に戻ってしまいます。

写真の扱いも混乱しやすい部分です。チャットに写真だけ送られている、ファイル名が分からない、どの案件の写真か分からない、同じ写真が複数の場所に保存されている、といった状態になると、後から証跡を探すのに時間がかかります。写真を使うなら、案件番号や工程と紐づけて保存する仕組みが必要です。

遅延見落としは、案件数が増えたときに表面化します。10件程度なら管理者が目視で確認できますが、50件、100件と増えると、どの案件を優先して見るべきか分かりにくくなります。予定日、最終更新日時、ステータスを使って、確認すべき案件を自動で浮かび上がらせることが重要です。

進捗管理の問題は、単に入力フォームを作れば解決するものではありません。情報の入口、保存場所、見方、通知、責任分担を一つの流れとして整理することで、初めて実務で使える仕組みになります。

3. GASで進捗管理アプリを作るとできること

GASで進捗管理アプリを作ると、入力、保存、確認、通知を一つの流れにできます。

基本的な流れは、次のような形です。

• 作業者がスマホやPCから進捗入力画面を開く
• 案件や工程を選択する
• ステータス、コメント、作業日時などを入力する
• 必要に応じて写真を添付する
• GASが内容をスプレッドシートに保存する
• 添付写真をGoogleドライブに保存する
• 管理者が一覧画面で最新状況を確認する
• 遅延や未入力があれば通知する

入力画面は、GASのWebアプリとして作れます。

Googleフォームでも簡単な入力はできますが、案件一覧から選ばせたい、ステータスを業務に合わせたい、写真添付や確認画面を細かく制御したい場合は、HTML画面を使う方法が向いています。

データの保存先には、まずスプレッドシートを使えます。

案件番号、案件名、担当者、工程、予定日、ステータス、最終更新日時、コメント、写真URLなどを列として持たせれば、一覧管理や集計がしやすくなります。最初から複雑なデータベースを用意しなくても、小規模な進捗管理であればスプレッドシートで始められます。

管理者向けの一覧画面も作れます。

ステータス別、担当者別、工程別、遅延有無などで表示を切り替えられるようにすれば、見るべき案件を探しやすくなります。現場入力用の画面と管理者確認用の画面を分けると、利用者ごとの使いやすさも上がります。

入力時に確認画面を入れることもできます。たとえば、案件名、工程、ステータス、コメント、添付写真を送信前に確認させれば、誤入力を減らせます。特にメール通知や顧客向け報告につながる処理では、送信前の確認が重要です。

履歴管理も進捗管理では役立ちます。現在の状態だけを上書きする設計にすると、いつ誰が変更したのかが分からなくなります。更新履歴を追記する形にしておけば、問い合わせがあったときに「いつ完了になったか」「誰が確認待ちにしたか」を後から確認できます。

遅延通知は、毎朝の定期チェックとして動かすこともできます。GASの時間主導トリガーで、予定日を過ぎている未完了案件や、一定日数更新されていない案件を抽出し、担当者や管理者へ通知します。通知文には、案件名、担当者、期限、現在ステータス、管理画面へのリンクを入れると、受け取った人がすぐ確認できます。

また、進捗データは簡単な集計にも使えます。担当者別の未完了件数、工程別の滞留件数、今週完了した件数、遅延中の件数などを見えるようにすれば、管理者は現場の詰まりを把握しやすくなります。最初は一覧だけでも十分ですが、運用が定着してきたら集計ビューを追加すると効果が出やすくなります。

4. 入力画面とスプレッドシート構成の考え方

進捗管理アプリでは、入力画面をシンプルにすることが大切です。

現場で使う画面に項目を詰め込みすぎると、入力が面倒になり、結局あとでまとめて入力する運用に戻ってしまいます。まずは、案件、工程、ステータス、コメント、写真など、現場で本当に必要な項目に絞ります。

案件の選び方も重要です。

案件番号を手入力させる方法もありますが、入力ミスを避けたい場合は、案件一覧から選択できるようにします。担当者ごとに表示する案件を絞る、未完了の案件だけ表示する、といった工夫もできます。

ステータスは、業務に合わせて少数に絞ります。

たとえば「未着手」「作業中」「確認待ち」「完了」「保留」のように、誰が見ても意味が分かる名前にします。細かく分けすぎると入力者が迷うため、最初は運用できる粒度にする方が安全です。

スプレッドシート側では、現在の状態を持つシートと、更新履歴を残すシートを分ける方法があります。

現在の状態だけを見るなら案件一覧シートが便利です。一方で、いつ誰がどのステータスに変えたのかを後から確認したい場合は、更新履歴シートに追記していく形にします。履歴を残しておくと、問い合わせやトラブル時の確認がしやすくなります。

写真を扱う場合は、スプレッドシートに画像そのものを入れるのではなく、Googleドライブに保存してURLを記録する形が扱いやすいです。

ファイル名には案件番号、工程名、日時などを含めると、あとから探しやすくなります。保存先フォルダも案件別や月別に分けると、管理しやすくなります。

シート構成は、最初に整理しておくと後から楽になります。たとえば、案件マスタ、現在ステータス、更新履歴、担当者マスタ、設定、ログを分ける構成です。すべてを1枚のシートに入れると最初は簡単ですが、項目が増えたときに管理しにくくなります。

案件マスタには、案件番号、案件名、顧客名、担当者、開始日、予定日、現在工程、現在ステータスなどを持たせます。更新履歴には、更新日時、更新者、案件番号、変更前ステータス、変更後ステータス、コメント、写真URLを追記します。このように分けると、現在の一覧表示と過去履歴の確認を両立できます。

設定シートには、ステータス候補、通知先、通知条件、写真保存先フォルダIDなどをまとめます。コードの中に固定値を書き込むより、設定シートで変えられるようにしておくと、現場の運用変更に対応しやすくなります。

ログシートも用意しておくと安心です。通知を送った日時、エラー内容、処理件数、失敗した案件番号などを残しておけば、障害時に原因を追いやすくなります。GASは小さく作れる反面、問題が起きたときに何が起きたか分からないと調査に時間がかかります。

入力画面では、現場が迷わないように項目順も大切です。案件を選ぶ、工程を選ぶ、ステータスを選ぶ、コメントを書く、写真を添付する、確認して送信する、という流れにすると自然です。管理者向けの項目や内部管理用の項目は、現場入力画面には出しすぎない方が使いやすくなります。

5. 写真添付・一覧画面・遅延通知の考え方

現場業務では、写真が進捗の証跡になることがあります。

作業前、作業中、作業後の写真を残しておけば、管理者が現地に行かなくても状況を確認できます。GASのWebアプリでは、入力画面から写真を受け取り、Googleドライブへ保存し、そのURLをスプレッドシートに記録する構成にできます。

ただし、写真添付は運用ルールも必要です。

どの工程で写真が必要なのか、何枚まで添付するのか、ファイル名や保存先をどうするのかを決めておかないと、ドライブ内が探しにくくなります。写真を残す目的を先に決めることが大切です。

管理者向けの一覧画面では、最新状況を見やすくします。

すべての項目を一画面に並べるよりも、案件名、担当者、工程、ステータス、予定日、最終更新日時、写真リンクなど、判断に必要な項目を優先して表示します。ステータスや遅延有無で絞り込めると、確認作業が早くなります。

遅延通知は、進捗管理アプリの効果が出やすい部分です。

予定日を過ぎても完了していない案件、一定時間更新がない案件、確認待ちのまま止まっている案件などをGASの時間主導トリガーでチェックし、担当者や管理者へメールで通知できます。

通知は多すぎると読まれなくなります。

そのため、すべての変化を通知するのではなく、確認すべきものだけを通知する設計にします。たとえば、遅延案件だけ、当日期限の案件だけ、管理者確認が必要な案件だけに絞ると、通知の価値が下がりにくくなります。

写真添付では、ファイルサイズにも注意します。現場のスマホ写真は容量が大きくなりがちです。枚数が増えるとGoogleドライブの容量を圧迫し、一覧表示も重くなります。必要であれば、添付枚数を制限する、撮影する場面を決める、古い写真の保管ルールを決める、といった運用が必要です。

写真の共有範囲も確認します。現場名、顧客名、作業内容、人物、車両番号などが写る場合があります。写真フォルダを広く共有しすぎると、見せる必要のない情報まで見えてしまいます。進捗管理アプリで写真を扱うなら、保存先フォルダの権限を本文データと同じくらい慎重に扱うべきです。

一覧画面では、色の使い方も重要です。遅延は赤、確認待ちは黄、完了は緑のように視覚的に分かるようにすると、管理者がすぐ判断できます。ただし、色だけに頼ると見落としもあるため、ステータス名や件数表示も併用します。

通知条件は、最初から細かくしすぎない方が運用しやすいです。たとえば最初は「期限超過」「3日以上未更新」「確認待ちが残っている」のような条件に絞ります。運用してみて、通知が多すぎる、少なすぎる、担当者が違うといった問題が見えたら調整します。

通知先も分けて考えます。現場担当者には自分の案件だけ、管理者には全体の遅延一覧、責任者には週次のサマリーだけ送る、といった形です。同じ通知を全員に送ると、誰が対応すべきか分かりにくくなります。

6. 導入前に決めておきたいこと

進捗管理アプリを作る前に、業務ルールを整理しておくことが大切です。

まず、何を進捗として管理するのかを決めます。

案件単位なのか、工程単位なのか、作業者単位なのかによって、画面やシートの作り方が変わります。進捗管理という言葉だけでは範囲が広いため、どの業務のどの状態を見たいのかを具体化します。

次に、ステータスの種類を決めます。

「未着手」「作業中」「確認待ち」「完了」など、現場と管理者が同じ意味で使える状態名にします。曖昧な言葉を使うと、入力された進捗を見ても判断しにくくなります。

入力者と確認者も決めておきます。

作業者本人が入力するのか、現場責任者がまとめて入力するのか、管理者が確認してステータスを変えるのか。権限や責任の分担を決めておくと、運用開始後に迷いにくくなります。

写真添付のルールも必要です。

どのタイミングで写真を撮るのか、必須にするのか、保存期間をどうするのかを整理します。写真には現場情報や顧客情報が写る場合もあるため、共有範囲にも注意します。

通知ルールも最初に決めます。

誰に、いつ、どの条件で通知するのかを決めておかないと、通知が多すぎたり、必要な通知が届かなかったりします。最初は遅延や未入力など、重要なものに絞る方が運用しやすくなります。

権限管理も導入前に決めておきます。作業者は自分の案件だけ入力できればよいのか、全案件を見られるのか、管理者だけがステータスを戻せるのか、といったルールです。スプレッドシートを直接編集できる人を増やしすぎると、誤って行や列を変更するリスクがあります。

Webアプリとして提供する場合は、誰の権限で実行するかも確認します。GASのWebアプリは、実行ユーザーやアクセス権限の設定によって、見えるデータや操作できる範囲が変わります。社内だけで使うのか、外部協力会社も使うのかによって、設定方針が変わります。

運用責任者も決めます。進捗管理アプリは、作って終わりではありません。案件マスタを更新する人、担当者を追加する人、通知先を変更する人、エラーが出たときに確認する人が必要です。これを決めないまま始めると、運用開始後に小さな変更で止まりやすくなります。

導入前には、現場で試す期間も決めておくとよいです。いきなり全案件に広げるのではなく、1つの部署、1つの現場、1つの工程だけで試し、入力しにくい項目や通知の過不足を確認します。小さく試して改善してから広げる方が、現場の反発も少なくなります。

7. GASだけで作る場合の注意点

GASの進捗管理アプリは便利ですが、向いていない使い方もあります。

まず、大量アクセスやリアルタイム性が強く求められる場合です。

GASのWebアプリやスプレッドシートは、小規模から中規模の業務改善には使いやすい一方で、多数の利用者が同時に頻繁に更新するような用途では、専用のWebアプリやデータベースを検討した方がよいことがあります。

スプレッドシートをデータベースのように使いすぎる場合も注意が必要です。

データ量が増え、検索や集計が重くなったり、履歴が多くなりすぎたりすると、表示や処理に時間がかかります。将来的に件数が大きく増える見込みがある場合は、外部DBとの連携も選択肢になります。

権限管理も考える必要があります。

進捗情報には、顧客名、現場名、写真、担当者名などが含まれることがあります。スプレッドシート、Googleドライブ、GASプロジェクト、WebアプリURLの共有範囲を曖昧にしないことが大切です。

オフライン環境にも注意します。

現場によってはスマホの通信が不安定な場合があります。常にオンライン入力できる前提で作ると、現場で使いにくくなることがあります。必要に応じて、入力タイミングや代替運用を決めておきます。

また、進捗管理は現場の習慣に影響します。

画面を作っただけでは定着しません。入力項目を絞り、運用ルールを説明し、最初は小さな範囲で試してから広げる方が失敗しにくくなります。

GASの実行時間にも注意が必要です。大量の行を毎回読み込んだり、写真ファイルをまとめて処理したり、外部APIと連携したりすると、処理が重くなることがあります。スプレッドシートの読み書きはまとめて行い、必要な範囲だけを扱うように設計します。

同時更新の問題もあります。複数人が同じタイミングで進捗を更新する場合、処理が重なって履歴がずれたり、同じ案件に対する更新が競合したりすることがあります。必要に応じてLockServiceを使う、更新時刻を記録する、最後に更新した人を表示するなどの工夫が必要です。

写真が増え続ける場合は、Driveの整理も課題になります。案件完了後に写真をどのくらい残すのか、月別フォルダへ移すのか、一定期間後にアーカイブするのかを決めておかないと、保存先が膨らみ続けます。

スプレッドシートの限界が見えてきた場合は、外部DBを検討するタイミングです。たとえば、履歴が数万行を超える、検索や集計が遅い、利用者が多い、複数画面から頻繁に更新する、といった状態になったら、GASとSupabaseなどを組み合わせる構成も選択肢になります。

ただし、最初から外部DBを使う必要はありません。小規模な現場管理なら、スプレッドシートで始めた方が運用を理解しやすく、顧客にも説明しやすいです。重要なのは、将来増えたときに移行できるよう、データ項目や履歴の持ち方を整理しておくことです。

8. 小さく始める導入ステップ

進捗管理アプリは、最初から全部入りで作るより、小さく始めた方が定着しやすくなります。

最初のステップは、現在の進捗管理方法を整理することです。どの情報をどこで管理しているのか、誰が入力しているのか、どのタイミングで遅延に気付いているのかを確認します。ここを飛ばして画面だけ作ると、現場の実態に合わないものになりやすいです。

次に、入力項目を絞ります。案件、工程、ステータス、コメント、更新者、更新日時くらいから始めると、現場の負担を抑えられます。写真添付や細かい分類は、必要性が確認できてから追加しても遅くありません。

3つ目は、少人数で試すことです。1つの現場や1つのチームだけで使い、入力に時間がかかりすぎないか、一覧が見やすいか、通知が多すぎないかを確認します。実際に使うと、机上では分からなかった項目名や操作順の問題が見えてきます。

4つ目は、管理者向けの確認方法を整えることです。現場が入力しても、管理者が見にくければ使われません。未完了、遅延、確認待ち、写真あり、担当者別など、日々の確認で使う切り口を優先します。

5つ目は、通知を追加することです。最初は遅延や未入力など、本当に見逃したくないものに絞ります。通知が多すぎると無視されるため、運用しながら条件を調整します。

最後に、権限と保守を整理します。誰が案件マスタを更新するのか、誰が通知先を変更するのか、写真フォルダを誰が管理するのか、エラーが出たら誰が見るのかを決めます。進捗管理アプリは毎日使う仕組みなので、保守担当が曖昧だと長続きしません。

このように段階を分けると、GASで作る進捗管理アプリは現場に合わせて育てやすくなります。最初は簡単な入力と一覧確認から始め、必要に応じて写真、通知、集計、外部DB連携へ広げるのが現実的です。

9. まとめ

GASで進捗管理アプリを作ると、現場入力、スプレッドシート保存、写真添付、一覧確認、遅延通知を一つの流れにできます。

電話やチャット、手入力の表だけで進捗を管理していると、情報が散らばり、最新状況の確認に時間がかかります。案件数や担当者が増えるほど、確認漏れや遅延の見落としも起きやすくなります。

GASを使えば、スマホやPCから入力された進捗をスプレッドシートに保存し、写真をGoogleドライブに残し、管理者が一覧で確認できる仕組みを作れます。

ただし、進捗管理アプリは画面だけで成り立つものではありません。ステータスの定義、入力者、確認者、写真添付、通知条件、権限管理を先に整理する必要があります。

まずは、現場入力と一覧確認から始め、必要に応じて写真添付や遅延通知を追加していくと、無理なく導入しやすくなります。

現場で使われる仕組みにするには、入力しやすい画面、見やすい一覧、必要な通知、分かりやすい権限設定が必要です。GASなら、これらをスプレッドシートやGoogleドライブと組み合わせて小さく始められます。

一方で、データ量、写真容量、同時更新、権限、保守担当を考えずに作ると、運用開始後に困ることがあります。まずは小さな範囲で試し、現場の反応を見ながら改善していくことが大切です。

進捗管理は、単に状況を記録するためのものではありません。遅れに早く気付き、必要な人が判断し、次の対応を取りやすくするための仕組みです。GASを使うことで、その流れを低コストで作り始められます。