陸上部の電話連絡500人分をGASでDXしてみた
こんにちは、GDSC大阪大学支部DX-TeamのAkifumi-Nishioです!GDSC大阪大学支部は、「身近な課題をテクノロジーで解決する」ことを活動目標とする学生テックコミュニティです。身近な課題としてある部活が抱える問題に着目しDXに取り組んでいます。
今回はそのDX案件第一号として、陸上部OB電話連絡のメール化の実装が一通り完了したため、その背景から結果まで一気に紹介したいと思います❗️
そもそもDXとは
最近新聞やニュースでよく聞くようになった謎の言葉「DX」。私もGDSCに携わるまで正直意味はよく分かりませんでした(笑)
DXは一言で表すと「デジタル技術による変革」です。単なるIT化や自動化ではありません。つまり、小手先の問題解決ではなく、デジタル技術を活用した問題の根本からの解決を目指すことを意味します。
GDSC大阪大学支部では、学内でDXを行いたい個人や団体を対象に、課題分析から実装方法、技術的な問題解決までのサポートを目指しています。
依頼概要
依頼主(依頼団体):合田理樹さん(大阪大学陸上競技部OB主務)
依頼時期:2021年10月
課題:1000人にも及ぶOBさんに電話連絡を行っているが、連絡件数は年々増加傾向にあり部員にとっての負担が増加している。
最終目標:OB電話連絡のメール化・自動で管理
OB電話連絡とは、阪大陸上部の現役部員(1~3回生)が毎年3月頃に行っている、部誌の送付やメルマガ送信のためのOB・OGさん(以下OBさん)への住所・連絡先確認のことです。陸上部には現役生だけで現在約100人の部員が在籍しており、またOBさんの人数は約1000人にも上ります。(2022年4月時点)
単純計算すると、現役部員1人あたりなんと10人のOBに電話を掛ける必要がありました...さらに1度の電話では繋がらないことも多く、繋がるまで何度も何度も掛け直すことになり、10人全員に繋がるまで延べ30回以上連絡をしたという部員もいたそうです。週5日の練習がある中でそれだけ多く電話を掛けることは、時間的にも通話料金的にも非常に負担が大きいものでした。
ところで電話連絡自体必要なの?という意見もありました。そもそも陸上部の活動における支出の多くはOB会費で賄われており、現役生が活動を部誌やメルマガで報告することによってOB会費を支払ってもらうという相互関係にあります。したがってOBさんの連絡先を把握することはOBさんと現役生の関係を持続させる上で重要な役割を持っています。
それでも今後もOBさんの人数は増え続け、現役部員の負担は年々増加する一方でした。そこで連絡方法を直接の電話連絡からメールに切り替え、自動的にメールを送信・回答を管理するシステムを構築し、その負担軽減を図ろう!というのが今回の目的です。
補足:DXのプロセス
DXは以下のスケジュールで進めました。
課題分析(10月~11月)
今回のDXにおける適切な課題と最終目標を設定
システム設計(11月)
設定した最終目標を達成できるよう、DX Team (Tech Adviser)のNishiharaを中心にメール自動化システムを設計
システム実装(11月~2月)
設計に従い依頼者本人がシステムを実装
メール送信本番(3月)
システムを実行しメールを一斉送信
送信完了(3月)
結果を整理し来年度以降の改善点を発見
システム構成
システムは合田さんの技術力や3月の運用を踏まえて、Google App Script (GAS) を中心とした設計にしました。
また今回の目標を満たすために必要だと判断した機能 (システム要件)は以下の通りです。
住所・連絡先情報に関するアンケートをメールで送信
アンケートの回答をもとに新しいOB名簿を自動作成する
未回答のOBさんへリマインドメールを自動送信
変更履歴を残す
①システムのイメージ図
以上を踏まえて、設計したシステムは以下の図のようになりました。
OB主務側の流れをざっと説明すると、(「」〇 は図中の囲いに対応 )
昨年時点での住所・連絡先情報を「昨年のOB名簿」シートにまとめる
①(doGet()関数):昨年時点の情報が事前入力された「アンケートフォーム」およびそのURLを自動生成する
②(sendEmai()関数):生成したURLが記載されたメールを自動的に作成し送信する
③(doPost()関数):OBからの回答を「アンケートの回答」シートに集める⇒変更履歴
④(existReplyed()関数):回答があったOBに関して、「昨年のOB名簿」シートに回答済の情報を追加する
⑤(setNewList()関数):「アンケートの回答」をもとに「新しいOB名簿」シートを自動作成する
【リマインドメール】②(sendReEmail()関数):「昨年のOB名簿」で回答済の情報がないOBに対してメールを送信する
少々説明が難しくなってしまったかもしれません。要するに、メール送信~アンケート~新しいOB名簿作成を一体化させたシステムを構築したということを理解してもらえればOKです!
よってシステムを実行するだけで①~⑤が自動的に終わります!
また実際に回答するOBさん側からの操作は、
自分宛てにOB主務からのメールが届く
URLをクリックしアンケートフォームが開く(図中青矢印)
昨年時点の住所・連絡先情報が既に入力されているので、変更がある場合は新たに入力する(図中右下の画像)
フォーム一番下の送信をクリックすると、回答完了
と非常に簡単なものになり、最短30秒で確認が終わるようになりました!
②工夫した点
その1:アンケートフォーム
アンケートフォームには html + Bootstrap を使用しました。Bootstrapは効率的に開発を進めるためのWebデザインフレームワークです。
これを使うことで、文字の大きさやレイアウトを整えることができ、見た目上の安心感があり、入力しやすくなるよう工夫しました。またPCとスマホどちらで閲覧しても体裁が崩れないようになりました。
また「ajaxzip3」というインターネット上で公開されている住所の自動入力のライブラリを用いることで、郵便番号を入力すれば自動的に住所が入力されるようになり、入力の手間と入力ミスの削減を目指しました。
その2:OB名簿
これまでOB名簿は、卒業年順に全OBさんの情報をただ縦に並べただけの形で管理してきました。しかし結婚して苗字が変わった場合や、同姓同名であった場合に個人を特定できなくなるといった問題がありました。
そこでプログラム上管理がしやすいようにOBさん一人一人にIDを付与しました。それに応じてアンケートフォームのURLでOBさん個人を識別できるようにし、住所・連絡先情報が適切に事前入力されるようにしました。
またOBさんからのアンケートの回答に間違いがあった場合を想定して、名簿は上書きせず新しい名簿を生成する仕組みにしました。
その3:迷惑メール対策
本番の送信前には、デモプログラムを使用して部内でテストを実施しました。テストでは、部員約40人に対して本番と同様に、アンケートフォームのURLが記載されたメールを送信し回答してもらいました。しかし回答率は40%と低く、主に “xxx@gmail.com” のアドレス宛に送ったメールが迷惑メールに判定される事例が多発していました。よって早急な対策が必要でした。
まずはメール本文をhtml⇒テキストに変更し、メール本文の内容も変更してみました。しかし状況は変わりませんでした。
最終的に着目したのは送信元のメールアドレスでした。それまでは “xxx@gmail.com” のアドレスから送信していましたが、大学ドメインのアドレス (xxx@xx.ac.jp) に変更してみました。すると送信の成功率が格段に上昇し、迷惑メールに振り分けられる事例が急激に減りました!
結果
システムの実装は当初の計画から1か月延長し3か月かかりましたが、無事3月の送信本番を迎えました。送信から2週間を期限とし、適宜リマインドメールも自動送信しながらOBさんからの回答を待ちました。
さて結果は、
490/837(メールアドレス既知のOBからの回答率=約58%、期限日時点)
初めての試みながらも半数以上のOBさんから回答を得ることができました!従来の電話では1回につき5分以上かかっていた連絡先の確認が、システムを1度実行するだけで終わってしまいました!!!
メールで回答を得られた500人近いOBさんへの連絡先確認の時間が省かれたため、単純計算で現役部員1人あたり5分×500人(OB)÷100人(現役生)=約25分の時間が節約されたと言えます。
従来は時間帯を変えて何度も電話を掛けなおしていたことも考えると、数字以上に節約した時間は大きいかもしれません。来年度以降メールでの連絡が陸上部OB内で浸透すれば、さらなる回答率の上昇⇒負担軽減が見込めます!
ちなみに今年度は、期限後もメールでの回答を受け付け、また追加で電話番号を把握しているOBさんへの電話連絡も実施しました。最終的に、524名(メール)+294名(電話)=818名のOBさんから回答を得ることができました。
昨年繋がったOBさんの人数は579名だったようで、昨年よりも200名以上のOBさんから情報を得ることができました!
DXを終えて
今回のDXを終えて、OB主務の合田さんから感想をいただきました。
ー 実装を終えてみた率直な感想はどうですか?
構想から実装まで、思ったより時間がかかってしまいました。しかし、メールの自動送信のみならず、名簿の自動更新まで行えたので結果には満足しています。次期OB主務に引き継ぎを行うため、プログラムの内容を説明するための資料の作成にも取り組みたいと思います。
ー 苦労した点はありますか?
技術的な話になりますが、htmlを使ったアンケートフォームの実装に苦労しました。特に「変更なし」と「変更あり」の選択肢に関する処理の実装が難しく、選択肢を変えるごとに下の入力ボックスの入力の可否を変更する関数や、選択肢によって入力されている回答をスプレッドシートに反映させるかどうかを決める関数の作成に手こずりました。
また得られた回答を基に配列を組み直す関数(postResponese())の実装にも苦労しました。同一の人物から複数の回答があった際に、最新の回答のみを配列に反映させるための処理を作成することが難しかったです。(関数の代入とfor文についての理解が足りていませんでした)
ー GDSCのサポートはどうでしたか?
モジュールやhtmlでのフォーム作成では的確なアドバイスをいただき、サポート体制はとてもよかったです。ただ、実装の時期が当初の予定よりも一ヵ月程遅れてしまったので、僕の技術不足という面もありますが、もう少し余裕をもって計画を進めたかったです。
ー スケジュール管理に関して深く反省しております。ご感想いただきありがとうございました。
なお合田さんは、今回のアンケートフォームの自動生成技術を、別の個人情報を扱うアンケートにも適用してくれました!この半年で個人でGASを応用できるまで成長するとは畏れ多いです...
以上でDX案件第一号の紹介を終わります。詳細な実装技術を知りたい、もしDXに興味が出て自分たちもやってみたいという方がいらっしゃれば、GDSC大阪大学支部のslackにご参加ください!!!
(GDSC大阪大学支部のHP:https://gdsc-osaka.jp/ のslack参加申請フォームから是非!!)
最後までお読みいただきありがとうございました。
この記事が気に入ったらサポートをしてみませんか?