アルバイト雇用申請フォームをGAS Webアプリで作った話【システム選定の視点も含めて】
大学や研究機関では、アルバイトの雇用申請を紙の書類で行っているケースがまだ多い。
今回作ったのは、教員がWebブラウザから申請情報を入力するだけで申請書PDF・事務担当へのメール通知が自動で完了するシステムだ。ツールはGoogle Apps Script(GAS)。実装の中身よりも、なぜGASを選んだのか・選ぶべきだったのかという視点を中心に書く。
改善前:何が起きていたか
アルバイト雇用申請の典型的な業務フローはこうだ。
① 教員がWordまたはExcelの書式をダウンロード
↓
② 必要事項を手入力・印刷
↓
③ 教員が署名・押印して事務窓口へ持参
↓
④ 事務担当が内容を確認・スプレッドシートへ手動転記
↓
⑤ 管理台帳に記録・保管
問題は複数ある。
| 課題 | 具体的な問題 |
|---|---|
| 転記の二重化 | 教員が書いたものを事務担当が再入力する |
| 書式の陳腐化 | WordファイルのバージョンがPC間でばらつく |
| 進捗の不透明さ | 受理されたかどうかが教員側からわからない |
| 管理コスト | 紙の保管・検索に時間がかかる |
加えて今回は「エフォート管理」という特有の複雑さもあった。複数の研究予算に人件費を按分する設定で、件数が増えると教員・事務双方に管理負担が生じる。この問題については後述する。
システム選定:なぜGASを選んだか
最初の検討で候補に挙がったのは以下の3つだ。
| 候補 | 概要 |
|---|---|
| Microsoft Forms + Power Automate | Microsoftエコシステム |
| 専用の申請系SaaS | 外部サービス導入 |
| Google Forms + GAS | Googleエコシステム |
組織がGoogleアカウントで動いている
今回の対象組織では、教員・事務担当のアカウント管理がGoogle Workspace上で行われている。メール・カレンダー・ドライブがすべてGoogleだ。
この前提があると、GASの選択肢は自然に浮上する。
- スプレッドシートはすでに使われている
- Driveへのファイル保存は既存の権限モデルに乗れる
- GmailでのメールはGmailAppで送れる
- 追加の認証・ライセンス・IT承認が不要
「組織のIDプロバイダーがどこか」は、業務ツールの選定に直結する。Googleアカウントで管理されているなら、GASが最も摩擦なく動く。
MicrosoftアカウントのExchange制限という現実
組織によっては、Microsoft 365のアカウントを持っていてもExchange(メール)がフル機能で使えないケースがある。
たとえば:
- ライセンスが「Exchange Online Plan 1」止まりで、特定のメール自動送信機能が使えない
- メールフローのルールやコネクタが管理者権限で制限されている
- Power Automateのメール送信がセキュリティポリシーで外部送信不可になっている
Power Automateは強力なツールだが、こうした制約が組織のIT方針によって随所に存在する。承認されるまでの時間コストも馬鹿にならない。
GASの場合、GoogleアカウントがあればGmailAppで即座にメールを送れる。サービスアカウントの設定も不要で、権限周りのハードルが低い。
長期的な影響を考える
ここが重要だ。
業務ツールを選ぶとき、「今動くか」だけでなく「誰が5年後に維持するか」を考える必要がある。
GASはJavaScriptベースで、ブラウザ上のエディタで完結する。特定のローカル環境に依存しない。担当者が変わっても、Googleアカウントさえあれば中身を見て修正できる。
外部SaaSは機能が豊富な分、依存度が高い。料金改定・サービス終了・仕様変更のリスクを組織が負い続ける。
今回のような組織内部の人事手続きであれば、Google Workspaceの中で完結するGASが長期的なコスト・リスクの観点でも優位だ。
実装したもの
システムの全体構成はシンプルだ。
[教員] Webフォーム入力・送信
↓
[GAS] スプレッドシートに記録
↓
[GAS] 申請書出力シートに行番号をセット → 数式が自動で値を引いてくる
↓
[GAS] スプレッドシートをPDFエクスポート → Driveに保存
↓
[GAS] 管理者(複数可)にメール通知
↓
[教員] PDFダウンロードリンクが表示される → 印刷・提出
Webフォーム(HTML + GAS)
HtmlService.createHtmlOutputFromFile() でHTMLを返すGAS WebアプリとしてデプロイするとURLが発行され、ブラウザからアクセスできる。インストール不要。
フォームで収集する主な項目は以下。
- 申請者情報:申請日・氏名・職員番号・学部
- アルバイト本人:氏名・区分(一般/学生)・生年月日・住所・電話
- 労働条件:雇用期間・業務内容・勤務場所・曜日・時間帯
- 経費:経費区分・予算コード・時給
- 備考:エフォート管理の記載欄
フォームを閉じる前にcheckValidity()でHTML5バリデーションを走らせ、未入力の必須項目をブラウザがハイライトする。送信後はローディング表示→完了画面(PDFダウンロードリンク付き)へ遷移する。
PDF自動生成
Googleスプレッドシートのエクスポート機能をGASから叩く。
const url = 'https://docs.google.com/spreadsheets/d/' + ss.getId() + '/export'
+ '?format=pdf'
+ '&gid=' + outputSheet.getSheetId()
+ '&size=A4'
+ '&portrait=true'
+ '&fitw=true'
+ '&top_margin=0.5&bottom_margin=0.5&left_margin=0.5&right_margin=0.5'
+ '&sheetnames=false&pagenumbers=false&gridlines=false';
スプレッドシート側の「申請書出力」シートには、セル参照で一覧シートのデータを引く数式が入っている。GASが行番号をセットしてflush()→sleep(2000)で再計算を待ってからPDFを生成する設計だ。
生成されたPDFはDriveに保存し、ANYONE_WITH_LINKで閲覧権限を付けてダウンロードURLを返す。
複数管理者へのメール通知
設定シートの「通知先メールアドレス」にカンマ区切りで複数アドレスを入力できる。GASはそれを分割して、各宛先に個別でメールを送る。
config.notifyEmail
.split(',')
.map(addr => addr.trim())
.filter(addr => addr)
.forEach(addr => sendNotificationEmail(addr, data, fileUrl));
メール本文には申請者情報・雇用期間・業務内容・PDFダウンロードURLが含まれる。
設定シートで運用パラメータを分離
setupConfigSheet()を一度実行するとスプレッドシートに設定シートが作られる。
| キー | 値 |
|---|---|
| 保存先フォルダID | Google DriveのフォルダID |
| 通知先メールアドレス | admin1@example.com, admin2@example.com |
コードを触らず、スプレッドシート上で運用パラメータを変更できる。担当者が変わっても維持しやすい。
設計上の工夫:エフォート管理の啓発
今回のフォームでひとつ気を遣ったのが、備考欄まわりの案内文だ。
エフォート管理(複数予算への人件費按分)は、科研費や受託研究など厳格な支出報告が必要な場合に正当な手続きだ。しかし、必要性が低いケースでも慣習的に設定されることがあり、件数が増えると教員・事務の双方に管理負担が発生する。
そこでフォームの備考欄の直下に、以下の要旨の案内を常時表示する設計にした。
- エフォートの設定は厳格な支出報告が義務付けられている場合のみにしてほしい
- 支出報告要件が緩い予算間での按分は予算振替でまとめる方向を検討してほしい
- 一度設定したエフォートの変更も同様のコストが発生するため、当初設定から変えないよう十分に検討のうえ申請してほしい
申請を止めるのではなく、「知った上で申請する」状態を作ることが目的だ。
フォームは申請のインターフェースだが、同時に組織の運用方針を伝える場所にもなる。
まとめ:「組織のID基盤」に合わせて選ぶ
今回の実装で整理できた考え方をまとめる。
業務ツールの選定は、組織のIDプロバイダーを起点に考える。
Googleアカウントで管理されている組織では、GASはコスト・摩擦・維持コストのすべてで有利だ。MicrosoftのExchange機能が制限されている環境では、Microsoft Formsや Power Automateが想定通りに動かないケースが出てくる。
「どのツールが機能として優れているか」より、「どのツールが自分たちの環境で今日から動き、5年後も維持できるか」を優先する。
GASはその問いへの答えとして、Googleアカウントを持つ組織には今でも有力な選択肢だと思っている。
関連記事: