「勤怠管理、市販のシステムを入れるほどではないけれど、紙とExcelはもう限界」。中小企業や事業所からいただくご相談で、いちばん多いパターンです。
こういうとき、Googleスプレッドシート＋GAS（Google Apps Script／スプレッドシートに機能を追加できる、Google公式のプログラム機能）で作ると、数十万円規模で自社専用のものが作れます。ただ、ここで必ず1回悩むポイントがあります。
「スプレッドシートの画面のまま使わせるのか、それともReactでちゃんとしたアプリ画面を作るのか」
Reactというのは、スマホアプリのような操作感の画面を作るための道具だと思ってください。載せれば操作感は良くなりますが、作る手間も、あとで直す手間も確実に増えます。
直近1年で、勤怠まわりのツールを3件、別々の構成で作りました。「ここで分かれる」という基準が3つに固まったので、そのまま共有します。
実際に分かれた3件
① 北関東の社会保険労務士事務所様 ＝ Reactを載せなかった
スプレッドシートの画面そのものを業務画面として使い、GASは裏方に徹する構成です。入力された「1/5」「0105」といった雑な日付をその場で正しい日付に直したり、毎日深夜2時のバッチで完了案件を別シートへ移して並び替えたり。担当者は普通にセルへ打ち込むだけです。
② 北関東の福祉事業所様（2事業所） ＝ Reactを載せた
朝の点呼と打刻を、共有タブレットで職員・利用者の方が次々に行う使い方です。スプレッドシートの画面では戦えないと判断し、React製のアプリ画面を載せました。
③ 群馬県のIT関連企業様 ＝ そもそも画面を作らなかった
打刻をLINEのトーク上で完結させたので、フロント画面自体が不要でした。
分かれ目1：使う人に、シートを直接触らせるか
いちばん効く基準がこれです。
①の事務所様は、担当者が複数名で同時にシートへ入力します。しかも「解約したお客様の行は自分たちで消したい」「列を足したい」というご要望がありました。つまりExcel的に自由に触れること自体が価値だったわけです。ここにReactの画面をかぶせると、できることをわざわざ減らすことになります。
逆に②の事業所様は、「シートは月1回の集計で開くくらい。編集は全部アプリ経由」という運用を最初に決めました。触らせない前提が立つなら、Reactを載せる価値が出ます。
判断は「どちらが高機能か」ではありません。使う人がシートを触る運用なら、シートが画面のままでいい。それだけです。
分かれ目2：速さが「業務要件」になっているか
②が決定的だったのはここでした。朝の混雑時、タブレットの前に人が並びます。押してから2秒待たされる画面は、それだけで使われなくなります。
そこでReactを載せたうえで、性能のために3つを標準にしました。
- 打刻は楽観的更新にする（押した瞬間に画面を更新し、通信は裏で走らせる。失敗したときだけ巻き戻す）
- 独立した通信はまとめて並列で投げる
- 社員マスタなど変わらないデータはキャッシュに置き、書き込み時に自動で捨てる
逆に言えば、速さが要件になっていない業務にReactを載せても、体感は変わりません。①の事務所様の入力作業は、1件ずつじっくり進む仕事です。ここを高速化しても誰も得をしませんでした。
分かれ目3：画面が「状態」を持つか
ログイン状態、選択中の事業所、入力途中のフォーム。こうした「画面が覚えておくべきこと」が増えるほどReactの得意分野です。②は所属と区分の2軸で対象者を絞り込む画面があり、表計算の画面では表現しきれませんでした。一方で①は覚えておくべき状態がほぼなく、セルの値がすべてです。
Reactを載せると増えるコスト（正直に書きます）
良いことばかり書くとフェアではないので、実際に払ったコストも書いておきます。
GASでWebアプリを公開すると、画面はGoogleの3階層のフレームの中で動きます。ここに独特の癖があり、②では実際に事故を起こしました。
セッションが切れたときに画面を再読み込みさせる、という一般的な作りにしていたのですが、この環境で再読み込みを呼ぶと画面が真っ白のまま固まります。フレームの中身は親から流し込まれていて、読み直すべき実体が空っぽだからです。セッションの有効期限は24時間だったため、タブレットを開きっぱなしにした翌朝、必ず踏むという最悪の出方をしました。修正は「再読み込みをやめ、アプリ内部の状態だけをログイン前に戻す」で済みましたが、こうした問題はシートのまま使っていれば1つも起きません。
迷ったときの順番
ご相談を受けたときは、いつもこの順で確認しています。
1. 使う人がシートを直接触るか → 触るなら、シートのままでいく
2. 速さが業務要件か（人が並ぶ・現場が止まる） → そうでなければ、シートのままでいく
3. 画面が覚える状態が多いか → 少なければ、シートのままでいく
3つとも「いいえ」なら、Reactは要りません。むしろ載せないほうが、あとで直すのが速くて安全です。
いちばんもったいないのは、「せっかく作るならちゃんとした画面で」という気持ちだけで載せてしまうことです。見た目は良くなりますが、直すたびにビルドの手間がかかり、環境固有の罠を踏みます。
まとめ
- 分かれ目は「シートを触らせるか」「速さが要件か」「状態が多いか」の3つ
- 3つとも当てはまらないなら、スプレッドシート＋GASのままが正解
- Reactは、共有端末で人が並ぶような現場でこそ効く
- 載せた瞬間に、GAS特有のフレームの癖という追加コストが発生する
自社の勤怠や日報を仕組み化したいが、どこまで作るべきか判断がつかない、という段階でのご相談も歓迎です。作らないほうがいい、というご提案をすることもあります。
【群馬・北関東の中小企業・ひとり社長のAI導入をサポート】
UMEO CREATE（ウメオクリエイト）では、群馬県（高崎・前橋・太田・伊勢崎・吉岡町など）を中心に、中小企業や個人事業主・ひとり社長様向けの「AI導入・業務自動化・DX伴走コンサルティング」を行っています。
「自社の業務でもAIを使える？」「何から手をつければいいかわからない」「面倒な事務作業を自動化したい」といったご相談は、お気軽に公式LINEまたはWebサイトのお問い合わせフォームよりご連絡ください。
