Sheets + GAS が向いているケース

向いているのは、件数がまだ多すぎず、業務ルールを固めながら運用したいケースです。学校の活動費、委員会の謝金、イベント運営、研究プロジェクトの支出整理など、まずは台帳と通知を整えるだけで効果が出やすい領域に適しています。

一方で、同時編集が非常に多い、複雑な権限が必要、外部ユーザーが多い、個人情報や機密情報が重い場合は、早めに専用 DB や認証基盤を検討すべきです。KirokuFlow では、Sheets で MVP を作り、必要に応じて Next.js とデータベースへ移行する段階設計を想定します。

最初に作るべきシート構成

最小構成は、topics、requests、payees、expenses、notifications、audit_logs のように、業務単位と履歴を分ける形です。一枚の巨大なシートに全項目を入れると、入力は簡単でも、履歴、権限、集計が難しくなります。

GAS は、フォーム送信時のステータス更新、承認メールの送信、支払い通知の作成、定期的な未処理リマインドに使えます。重要なのは、GAS が何を変更したかを audit_logs に残すことです。自動化の結果だけ残り、理由が消えると、後から説明できなくなります。

通知とエラー処理

GAS の通知は便利ですが、送信失敗、権限不足、宛先不備、重複送信が起きることがあります。通知済みフラグだけでなく、送信日時、宛先、テンプレート、エラー内容を残すと、担当者が追跡しやすくなります。

また、手動修正を完全に禁止するより、修正理由を残す設計にした方が現場には馴染みます。修正者、修正日時、修正前後の値、理由が残れば、シート運用でも一定の統制を保てます。

移行しやすい設計にする

Sheets で作る MVP は、将来捨てる試作品ではなく、業務ルールを学習するための土台です。列名、ID、ステータス、日付形式、担当者表記を安定させておくと、後から Next.js、Postgres、Supabase などへ移行しやすくなります。

KirokuFlow では、Sheets + GAS を「軽量な入口」として扱います。最初に導入障壁を下げ、業務が見えた段階で、権限管理、監査ログ、API、管理画面を段階的に強化します。