事務用封筒一括契約の申込受付業務における Google スプレッドシートとGoogle Apps Script による業務改善下司 和彦 1）, 小野 英理 1）1） 京都大学 Web 戦略室
geshi.kazuhiko.8e@kyoto-u.ac.jp

Improvement of the application work using Google Spreadsheets andGoogle Apps Script in package contract for the business envelopes
Kazuhiko Geshi 1）, Eiri Ono 1）
1） Website Planning Office, Kyoto University.
概要
京都大学（以下、「本学」と記す）では学内全部局及び部署で利用する事務用封筒を一括契約している。一括契約には、業者が一括印刷することによる封筒一部当たりの費用を削減する目的がある。2019 年度より封筒に本学ビジュアル・アイデンティティ（エンブレム、ロゴタイプ、スクールカラー等の策定、及び使用上のルール。以下、「VI」と記す）に係るデザインを採用した。封筒の一括契約は毎年度決まった時期に申込みを受け付けており、VI 導入以降の申込みでは、印刷する組織名及び住所の内容を Microsoft Excel で作成した申込書に記入することになった。申込受付業務では、印刷する組織名及び住所の回答において、文字の半角/全角の不統一や入力規則の違反が多発したため、申込受付担当者が回答者の意図を推測して回答を確認及び修正する作業が必要となり大きな業務負担となっていた。
そこで、Google スプレッドシートを活用し、Google Apps Script による回答制御と、ファイル共有機能により申込みが記入された申込書を 1 つに集約させることで業務効率化を行った。結果、申込受付業務の改善を達成した。
策定、及び使用上のルール。以下、「VI」と1 はじめに記す）の策定とガイドブックの作成。

著者が所属している京都大学 Web 戦略室（以⚫

本学 VI の事務用封筒及び名刺への展開。

下、それぞれ「本学」「当室」と記す）は、本学 Web⚫

学内職員に向けた、Web サイトアクセス解

サイトの構築・維持管理等に係る課題解決及びWeb での情報発信の強化に向けて、下記の業務を用封筒における VI の導入以前から存在していた主に行っている組織である。
⚫
⚫
⚫

Web サイトの構築・維持管理等に係る具体業務である。一括契約では、学内全部局及び部署的計画の策定及び実施。

（以下、部局及び部署を「組織」と記す）に向けて

Web サイトを中心とした ICT による情報申込受付の通知を行い、その結果集まった申込み発信体制の全学的な連携・支援体制の構築。

を業者に一括契約することで封筒一部当たりの費Web サイトを活用した「京大らしさ」の創用の削減を図っていた。
当時は封筒印刷内容に制限が無かったため、印出への取り組み。
⚫

析講習会の企画。
本稿で取り上げる事務用封筒一括契約は、事務Web サイト構築・運用に関するナレッジマ

刷内容は紙または PDF ファイルで受け付け、印刷ネジメントの強化。

申込数は Microsoft Excel で作成した申込書により受け付けしていた。その後当室が事務用封筒におまた、関連する実績として下記のものがある。
⚫

本学公式ホームページの刷新。

ける VI を策定したことで、2019 年度に封筒に印⚫

本学ビジュアル・アイデンティティ（エン刷する項目（エンブレム、ロゴタイプ、組織名、住ブレム、ロゴタイプ、スクールカラー等の所等）と各項目の配置（以下、「レイアウト」と記181す）に規則が定められた。これにより印刷内容に制限が加えられたため、レイアウトについては予め用意したレイアウトパターンから選択することになり、印刷内容の指定はテキストデータとして受け取ることになった。これに伴い、従来印刷申込数の回答のみに使用していた申込書は、レイアウト、印刷内容、印刷申込数を記入するものになった。
申込書の変更伴い、本学財務部から全組織に対しては申込書への回答方法の説明、印刷業者に対しては申込書に書かれた回答を封筒に配置する際の規則の説明が必要となったが、その規則が複雑なことに加え、組織に対しての説明が不十分だったため入力規則に反する回答が多発し、本学財務

ロゴタイプ部は回答の確認作業と回答が規則に反している場合には回答者の意図を推測して修正する作業が発生した。

エンブレム

本学財務部は、申込受付業務での回答確認と修正作業が業務負担になったため学内の他組織に業務改善の相談を行うこととなり、その相談先とし住所て、VI を策定し当一括契約の申込マニュアル作成と封筒デザイン策定に携わっていた当室が選ばれた。本学財務部と当室との相談の結果、今年度は当室による業務改善と併せて申込受付業務も行う

図 1a レイアウト A（組織名 0 件：住所１件）ことに決定した。
当室の申込受付業務の改善の方針として、業務組織名負担の原因である回答確認作業を削減することを目標とした。本稿では、事務用封筒一括契約の申住所込受付業務の概要と 2020 年度までの問題点、業務改善に向けた検討、業務改善の成果について報告する。

図 1b レイアウト B（組織名１件：住所１件）

2 封筒のレイアウトと印刷内容
組織名

封筒の申込みには、レイアウト、印刷する組織名及び住所、印刷希望数の情報が必要である。
本章では、レイアウトと、組織名及び住所の印刷について記載する。

住所

封筒のレイアウトは A～E の 5 種類を用意している。レイアウト A の封筒全体を図 1a に示す。
ロゴタイプとエンブレムは必ず印刷するものであり、組織名または住所に対して一定間隔を取るよう位置が上下する。

住所

レイアウトの選択に応じて組織名と住所の表記数が変わる。レイアウトに応じて変化する部分を抜き出した図を 1b～1e に示す。
図 1c レイアウト C（組織名 1 件：住所 2 件）

182

た。従来の Microsoft Excel ファイルの申込書によ組織名る受付の問題について本章に記載する。
3.1 表記の不統一

組織名

封筒に印刷する組織名及び住所の回答において、文字の半角/全角の不統一が多発した。半角/全角は本学封筒に統一性を持たせるために出来る限住所り統一することが望ましい。
また、回答項目によって入力内容に規則を設けているが、規則を守らない回答も発生した。例えば、電話番号の表記の括弧とハイフンの使い方、

図 1d レイアウト D（組織名 2 件：住所 1 件）

郵便番号の表記に「〒」記号が必須であることである。
3.2 レイアウトの選択に伴う使用可能・使用不要の項目の認識不足

組織名

第 2 章に記載のとおり、選択したレイアウトにより、組織名の表記が 0～2 件、住所の表記が 1～2 件に変わる。選択したレイアウトに応じて組織住所名と住所の表記数が変わることに伴い、回答項目において使用可能・使用不要の項目も変わる。
参考として、図 1a～1e の印刷依頼内容を申込書で表すと図 2 となる。図 2 では、例えばレイアウ
ト B（組織名１件：住所１件のレイアウト）を指定

組織名している行では「組織名 2」「部門 2」「郵便番号 2」
「住所 2」の項目は印刷に使用しないので使用不要である（「部門 1」「FAX1」は使用可能であるが住所空白を指定している。使用可能であっても回答必須ではない）。
レイアウトの選択に伴い使用可能・使用不要の項目が変動することは申込マニュアルにより説明しているが、マニュアルでは説明不足だったよう

図 1e レイアウト E（組織名 2 件：住所 2 件）であり、使用不要の項目に回答が記入されることが多発した。

3 従来の Microsoft Excel による申込受付
方法の問題
2020 年度までの申込受付は、Microsoft Excel で作成された申込書を全組織にメール送信し、各組織はそのファイルに申込内容を記入し返送してい図2

3.3 回答者による項目名の書き換え
申込書に予め記載していた項目名について、組織により項目名が書き換えられて回答を行われてしまい、結果、申込受付担当者（2020 年度までは本学財務部、2021 年度は当室）が求めている回答が記入されていない問題が発生した。

印刷申込内容を記入した申込書（図では項目は一部しか表示していない。実際には全 18 項目存在する）

183

それぞれの具体的な検討内容を下記に示す。

4 業務改善の方針

5.1 申込書として使用するツールの検討

第 3 章に記載した問題により発生した回答は、申込書として使用するツールには Google スプそのまま利用できないため、申込受付担当者が回レッドシートを採用した。理由は、共有ファイル答者の意図を推測し修正を行うこととなり、大きとして設定することで全組織からの回答を 1 つのな業務負担となっていた。業務負担の解消のため、ファイルに集約できること、加えて Google Apps

業務改善の方針を下記の通りとした。

Script（以下、「GAS」と記す）により入力制御を行⚫

文字の半角/全角、電話番号、郵便番号等

他のツールを不採用にした理由を下記に示す。の規則を設けている項目は、規則に従っ⚫

た回答が記入されること。
⚫

⚫

える利点があるためである。

組織からは送信した回答の確認と修正がレイアウト選択に伴う項目の使用可能・行えない。確認や修正をしたい場合には申使用不要を回答者に明示すること。

込受付担当者が連絡を受けて対応する必回答者から項目名書き換えが出来ないこ要がある。申込受付担当者の作業は極力削と。
上記の業務改善の方針から下記の通りシステム設

⚫

計した。
⚫

⚫

減したいため不採用とした。
Microsoft Excel
ツール単体で見ると、VBA により入力制御が行えるため GAS と同様に入力の制御を回答入力に対して柔軟に規則を設定でき、行える利点がある。しかし、第 5.2 節に記規則に反する回答がある場合は受け付け載するが申込書の受信には Google ドライないこと

ブ を 使用 す る。 Google ド ラ イブ 上 では

レイアウトの選択に伴い、自動的に使用可

Microsoft Excel ファイルの VBA が実行されず、VBA が実行されない環境上で編集が能・使用不要の項目が回答者に明示される行えてしまうため、スクリプトによる入力こと⚫

Google フォーム制御が徹底できないことから不採用とし回答者が編集する必要のない項目は編集⚫

不可に出来ること。

5 検討したツール

た。
Microsoft Access
活用方法として、まず当一括契約業務用にサーバを構築し、一括契約用の申込用業務改善に向けて使用するツールは、普段からMicrosoft Access ファイルを開発し、各組織業務で利用されている Microsoft Office 製品と、本に配布する。そのファイルから申込みを行学教職員グループウェアとして採用されているうとサーバに回答が送信される仕組みを

Google Workspace の 2 つを中心に検討を行った。

検討した。この場合、今後継続的にファイ申込書については下記のツールを候補にした。

ルとサーバの 2 つのメンテナンスが必要で⚫

Google スプレッドシートあり管理コストが増えるため不採用とし⚫
⚫
⚫
⚫

Google フォーム
Microsoft Excel
Microsoft Access
専用システムの開発た。
⚫

専用システムの開発
当一括契約業務専用のサーバを構築し、専用の Web アプリケーションを開発するこ

加えて、申込書に対して申込を記入したファイルとを検討したが、他の案に比べて開発コス（以下、「申込記入済ファイル」と記す）の受信がトと管理コストが大きいため不採用とし必要になる場合、受信手段については下記を候補た。にした。

5.2 申込記入済ファイルの受信手段の検討⚫

Google ドライブ⚫

メールでのファイル添付

ライブを採用した。理由として、組織が一度提出⚫

本学ファイル共有サービスした申込記入済ファイルを修正する場合を想定す

申込記入済ファイルの受信手段には Google ド184

ると、組織に編集権限を付与していればファイル編集を自由に行えるため、組織自ら修正が可能だからである。申込受付担当者は、回答に修正があったかは一切気にする必要は無く、申込締切時点の申込記入済ファイルを利用するだけでよいことから、最終的な回答を正確に受け取れる利点があるため採用とした。
他のツールを不採用にした理由を下記に示す。
⚫

メールでのファイル添付
この方法で組織が一度提出した申込記入済ファイルを修正したい場合を想定すると、申込受付担当者は組織から修正後の申込記入済ファイルを受け取り、修正前の申込記入済ファイルは利用しないよう注意する必要が発生する。Google ドライブを活用する方法と比べ、修正の連絡を見落としてしまうと修正前の申込記入済ファイルを使ってしまう懸念があることから不採用とした。

⚫

6 Google スプレッドシート活用の利点
6.1 申込記入済ファイル受信操作の削減
申込書として Microsoft Excel を使用していた時は、申込受付担当者は各組織からそれぞれ申込記入済ファイルをメールで受け取っていたため、1 通ずつのメールから添付ファイルをダウンロードする手間が発生していた。
申込書を Google スプレッドシートに変更するに伴い、Google ドライブ上に申込書を 1 つ設置し、それに対して各組織から記入を行うことした。これにより必然的に回答が 1 つのファイルに集約されるため、申込受付担当者による申込記入済ファイルのダウンロードは 1 回で完結できるようになった。
6.2 申込み集計作業の削減
各組織より受け取った申込記入済ファイルは、データを集計して印刷業者に提供する必要がある。
申込書として Microsoft Excel を使用していた時は各組織から送られた申込記入済ファイルを手作

本学ファイル共有サービス
当一括契約の申込みを受け付ける際、学内の誰が回答を行うかを事前に把握できない。そのためファイル共有を活用するのであれば共有先は学内全職員とすることが望ましい。本学にはオンプレミスでWebDAV による WEB 上でのファイル共有を提供するサービスがあるが、このサービスには学内全職員に共有する機能は無く、可能な手段としてはファイル共有先設定にて学内全職員のメールアドレスを手作業で入力する方法となる。これは現実的で業で 1 つのファイルに結合し集計していた。
申込書を Google スプレッドシートに変更するに伴い、申込みは Google ドライブ上に設置された1 ファイルに対して記入することにしたため、申込記入済ファイルを手作業で結合する必要はない。
これに加え第 7.3 節に記載する集計処理を実装することにより 1 ボタンで全組織からの回答の集計が行えるようになった。

7 GAS による独自機能の実装
Google スプレッドシートで作成した申込書にない方法であるため不採用とした。

は GAS による独自機能を実装した。実装ではセル以上より、Google スプレッドシートと Googleの値が変わるたびに呼ばれる onEdit（e）トリガードライブを活用し申込受付を行うことを決定した。

を主に活用し、回答者がセルに入力を行うたびになお、以上の検討結果から、当一括契約業務で入力値検証等を行う仕組みとした。本章では実装

は Google ドライブ上に学内全職員に編集権限をした独自機能の内容を記載する。

付与した Google スプレッドシートの申込書を用

7.1 入力内容の検証

意し、それに対して各組織からアクセスし回答を入力規則に反する入力があった場合、入力時点でメッセージを表示しセル背景色を赤にする。

記入したものが申込記入済ファイルになる。
この場合の懸念として、Google スプレッドシー

その後、入力が正常化すると背景色を白に戻す機

トは変更が自動保存されることから、回答者が意能を実装した。入力規則に反する入力があった場

図せず自身及び他人の回答を書き換えてしまい、合のメッセージの一例を図 3 に示す。

それに気付かないまま申込みが確定してしまう懸念が発生する。この問題は申込内容の正確性に直結する問題のため、最終的な回答の正確性の保証が必要とされた。

185

図5
図3

保護機能が表示するダイアログ

入力規則に反した場合のメッセージ
本来は「確認済」にチェックを入れた行は編集禁

7.2 回答済み行の保護止が望ましいが、GAS により編集禁止を設定する

申込書には、その行の回答入力が完了したこと

場合、GAS を実行したユーザー（「確認済」にチェを表す「確認済」チェックボックス項目を用意しックを入れた回答者）と Google スプレッドシート

た。
「確認済」チェックボックスを入れた申込書をのオーナーからは編集可能となる。この場合、他

図 4 に示す。

人からの回答の書き換えは防げるが、回答した本人からの編集は可能であるため、例えば意図せずキーボードに触れてしまったことで回答を上書きしてしまい、そのことに気付かないまま申込期限を迎えてしまう懸念が発生する。保護であれば、ダイアログへの選択次第で編集可能ではあるものの、誰が編集してもダイアログは表示されるため、意図しない回答の書き換えをより防げると考え保

図4「確認済」チェックボックスを入れた申込護を使用することとした。
7.3 集計処理

書

第 6.1 節に記載のとおり、今年度の申込受付は「確認済」をチェックするとその行の入力値検

Google スプレッドシートで作成した申込書 1 ファ証を行い、入力規則に従っていればその行を保護、イルで行うため、回答の受領時点で回答は 1 つの従っていなければ修正を促すメッセージを表示しファイルに集約されている状態である。しかしこ同時に「確認済」のチェックを外すようにした。のとき回答シートは組織ごとに分かれている状態

入力値検証は第 7.1 節に記載の機能でも行うが、となっている。

第 7.1 節の機能だけでは誤りの修正をしなくても印刷業者にデータ提供する際には 1 つの表とし回答提出が出来てしまう。そこで回答が完了したて集約させる必要があるため、シートに分かれて行は「確認済」にチェックすることを決めたこといる回答全てを 1 つのシートに集約させる機能をで、回答として確定された行は入力規則に従ってGAS で実装した。これは Google スプレッドシーいることが保証できるようになった。

トの各シートのデータを 1 シートにコピーする単補足として、本節で取り上げている「保護」機純なものである。集約機能は Google スプレッドシ

能とは Google スプレッドシートに用意されていートに設置したボタンをクリックすると実行される機能である。保護が設定されているセルは変更る実装とした。

される時に警告を出し「キャンセル」「OK」の選択が表示され、「OK」を選択するとセルは編集される。このダイアログを図 5 に示す。

これにより、2020 年度までは手作業で集約していた作業が 1 ボタンで完了するようになった。

8 業務改善の課題への対応と成果
8.1 入力規則に従った回答が入力されることの対応と成果「確認済」チェックボックスにチェックした際に行われる入力値検証により、「確認済」にチェッ

186

クされている行は入力規則に従っていることが保使用を徹底しない懸念があったが、実際に運用す証される。申込受付担当者は受け取った回答に対るとレイアウトテンプレートの利用は徹底されてして「確認済」にチェックが入っていることを確おり、使用不要の項目が使用される問題は解消し認するだけでよく、各回答が入力規則に従っていた。

るかを確認する作業が不要になった。

8.3 回答者による項目名の書き換えが行えないこ

8.2 レイアウトの選択に伴う使用可能・使用不要との対応と成果の項目が回答者に明示されることの対応と成果回答者による項目名の書き換えを防止するた

使用可能・使用不要の項目の明示は自動化が困

め、Google スプレッドシートの標準機能を使い、難だったため、申込書に新たな回答ルールを設け組織が入力するセル以外は編集禁止を設定した。

ることで対応した。困難だった原因については第具体的な編集禁止の対象は、説明文、項目名及び11 章に記載する。本節では新たな回答ルールにつ申込受付担当者が使用するセルである。編集禁止

いて記載する。

箇所を図 7 に示す。なお編集禁止にした箇所は説第 3.2 節に記載したように、レイアウトの選択明のため赤色背景にしている。に応じて使用可能・使用不要の項目が決まるが、2020 年度までの申込書では使用不要の項目が見た目で判別できなかった。2020 年度までの申込書の例として、簡略化した申込書を図 6a に示す。

図7

図 6a

申込書の編集禁止箇所

8.4 回答が書き換えられていないことの保証の対2020 年度までの申込書

応と成果

図 6a では、レイアウト A～E 全パターンの封筒を申し込もうとしているが、それぞれのレイアウトに応じた使用不要の項目が見た目で判別つかない。
改善策として、申込書に「レイアウトテンプレート」と呼ぶものを用意した。これは、予めレイアウト A～E に応じた使用不要の項目が黒く塗りつぶされているものである。簡略化したレイアウト
テンプレートを図 6b に示す。

回答者が意図せず自身及び他人の回答を書き換えてしまう問題について、第 7.2 節のとおり回答済みの行を保護する機能を実装したが、保護機能を使ってもダイアログで「OK」を選択すると編集できてしまうため、誤操作が続くことにより意図せず回答が書き換えられてしまう懸念が残る。
この問題に対処するため、申込期間後に申込書から組織の編集権限を外し、閲覧権限のみ付与した状態で申込内容の確認期間を設けた。確認期間は、組織からのセルの書き換えは完全に不可能である。もし回答の誤りが見つかった場合には、組織から当室に向けて修正依頼を行う運用とした。
申込内容の確認期間を設ける運用の結果、自組織が回答した内容を修正したいとの依頼が 1 件発

図 6b レイアウトテンプレート生したのみであり、業務改善の当初から懸念して回答記入時には、レイアウトテンプレートからレイアウト A～E の使用したい行をコピーし、自分の組織の回答スペースに貼り付けてから回答を記入することで、使用不要の項目が一目で判別できいた、意図しない回答の書き換えによるトラブルは発見されなかった。

9 申込受付業務中に発生したトラブル
9.1 申込書がコピーされるるようになった。
レイアウトテンプレートを活用する運用を決申込書が Google ドライブ上でコピーされるト

定した当初は、組織がレイアウトテンプレートのラブルが発生した。コピーされた申込書は元ファ187

イルの共有設定を引き継いで学内全職員から閲覧と編集が可能になっており、結果、複数の申込書が全組織から見える状態になっていた。

このことから申込受付業務の改善を達成した。

11 今後の改善点

このトラブルについて、申込書を置いているフ第 8.2 節に記載した「レイアウトの選択に伴うォルダに対して組織からの編集権限を外すことで使用可能・使用不要の項目が回答者に明示される対応した。
こうすることで Google ドライブの仕様ことの対応と成果」について、回答者が「レイアウにより、ファイルはコピーできてしまうがコピートテンプレート」をコピー＆ペーストする運用は、先はコピーを行った個人の領域であり、同時に共本来は GAS を活用し A～E の入力に応じて自動的有設定が全て外れるため、他人からそのファイルにテンプレートを貼り付ける機能の実装を行いたは表示されない。しかし他人からファイルが表示かったが、技術的に困難であり断念した。具体的されなくなっても、コピーした本人がコピーしたには、セルに変更が発生した時に呼ばれる onEdit

申込書に回答を書いてしまう懸念があるため、対（e）トリガーの処理後にアンドゥをすると、アン策として、申込受付担当者が用意した申込書のアドゥされた結果に再度 onEdit（e）トリガーが走りクセス URL を明記したメールを通知し、ここに書元に戻せない。またアンドゥを短時間に連続してかれていない申込みは無効だと通知することで、行うと、アンドゥの結果と onEdit（e）トリガーで勘違いしたままコピーしたファイルに回答を記入処理された結果の整合性が取れなくなるといったされるトラブルを抑制した。

ものである。更に、onEdit（e）トリガーの 1 回の9.2 ダウンロードした申込書を使い組織内で独自実行でセルに複数の変更が行われる場合、アンドに申込受付を実施される

ゥをするとセルの変更が 1 つずつアンドゥされて当室から申込受付の通知を受けた組織が、申込書をダウンロードし、組織内の下部組織に向けてしまい、ますます整合性が取れなくなるといった問題である。

ダウンロードした申込書を使い組織独自の申込受今年度は解決が困難だったため妥協案を取り付を実施した。申込書をダウンロードしたもので入れたが、解決策があれば自動化することで回答は GAS の独自機能が実行されないため、入力規則者の手間を更に削減したいと考える。に反する回答が行われることが懸念された。
この事案では、組織内で集まった回答は組織の代表者により Google ドライブ上に設置した正し

12 おわりに申込書に GAS による独自機能を実装することい申込書に入力されたため、その時点で入力規則で不正な回答を抑制でき、申込受付担当者によるに従う回答であることが保証された。予期してい回答確認の手間の削減を実現した。

ないトラブルではあったが、当室の負担が増えるクラウドサービス上のファイルを共同で編集ものではなかった。

することは、学内全職員のクラウドサービスへの10 運用成果理解度が推測できないため予想外の操作をされる懸念が大きかったが、最終的なデータの正確性を今年度は、42 組織から申込みがあり、封筒種類数は 85 種類であった。

第 8.4 節に記載した方法により保証し、結果大きなトラブル無く正確な回答を受け取ることができ申込受付では第 9 章のとおりトラブルはあったた。

ものの、当初から懸念していた意図せず回答が書以上より、GAS により申込受付業務の効率化がき換えられてしまうような大きな問題は発生しな図れること、クラウドサービス上の 1 つのファイかった。

ルに対して複数人が入力しても大きな混乱は生じ業務効率化により、回答を確認及び修正する作業と各組織の回答を 1 つの表に集計する作業が削減され、また、2020 年度と比べてレイアウトテンプレートの使用と「確認済」チェックボックスの使用の規則を追加したにも関わらず、申込受付期間から申込内容確認期間に至るまで質問は 2 件程度しか発生せず問合せ対応業務も殆ど無かった。

188ないことを確認することができた。