大学のバス時刻表のWeb-APIを作ってAWS Serveless Java Containerに上げるまで（1/n日目）
この記事はCIST (公立千歳科学技術大学) Advent Calendar 2022の4日目の記事です。（本来投稿したかった日が埋まってたので、書かれていなかった日を後日ハックしました）
CIST (公立千歳科学技術大学)のカレンダー | Advent Calendar 2022 - Qiitaqiita.com
はじめに
AWS Serverless Java Container（参考1, 参考2）というのがあり、一度技術検証しておきたいなあと思いました。
実は、サンプルのping/pongがさくっと苦労なく数コマンドで動いてしまい、面白みがないので何か役立ちそうなものがあれば検証がてらAPIを立ててみたいなと。
せっかく本学のアドカレがあったので、情報系の学生に何か役立つような形にまとめていければと思いました。
想定する読者と書くこと
プログラミングを勉強した（している）が、授業レベルの課題以外にはあまり使ったことがない/実際にシステム開発等に挑戦中ぐらいのレベルの学生さんに向けて。
学生が読む価値が少しでもあればと思い、個人で作業をする時の範囲ではありますが、「私が（Javaで）何かソフトウェアを作るときはこういう手順を踏むなあ」というのを丁寧に書いていこう と思います。
メインのはずのAWS Serverless Java Containerの話は、最終回1回分ぐらいの予定です。何回連載になるのかは不明です。
以下本編です。
大学バスの時刻表について
課題感
某大学は、バス事業者に運行を委託する形で、市内や最寄駅から大学へのシャトルバス（以後、大学バス）を運行しています。
この大学バスの時刻表は、大学側が学生からの声を頑張って汲み取って「毎週変えていく」という体制になってからしばらく経ちます。
私は大学バスユーザーではないのでわからない部分もありますが、最寄駅の列車の発着時刻や毎週の開講状況にあわせてバス発着時刻をコーディネートしてくれるのはサービスフルに思える一方で、学生にはWebサイトで配布されるバスの時刻表PDFを都度確認する手間がある、というネガティブな部分も出てきているようです*1*2。
こうした課題に、学生がこれまでにも色々なアイディアを出して改善（主にアプリ化）に挑戦してみる姿を見かけましたが、なかなかうまく行ってません*3*4。
こういう状況を少しだけでも支援するには？
そんな中「時刻表PDF内のテキストを読み取り、オープンデータっぽくすれば、もう少し課題解決に迫りやすいのでは」と気づき、試した学生がいました。これは結構うまく動いていた（しばらくの間、時刻表の更新に同期していた）のですが、その後、あっさり時刻表PDFのフォーマットが変わってしまい、学生も卒業してしまったので現在は動いていません。
ただし、この例ように 大学の公開データを誰もが使いやすい形にしておくことは、学生が陥りがちな状況の一部が解決されている前提でさらなる挑戦に取り組める支援 となるかもしれませんね。
ちょうど、AWS Serverless Java Containerにも興味があったので、今回は「大学のバス時刻表のWeb-APIを作ってAWS Serveless Java Container に上げるまで」 として行ったことを一つ一つまとめていきたいと思います。
少なくともこの記事を執筆時点で完了している話でないので、ちょっとずつ暇を見つけて取り組む形です。完成するといいなぐらいで進めていきます*5。
「作ってみよう！」のその前に、サービスの現状と目指すことを位置付ける
ここまで話をしてくると「じゃあ早速開発しよう！」という気持ちでコーディング等に走りがちですが、まずは落ち着いて、土台となるサービスの現状とやることを位置付けるところから始めましょう。
今回は、現状のサービスと、目指すサービスの全体像がどうなるのか、図などを使って整理 してみます。
現状のサービス全体像の整理
現状のサービス全体像（ステークホルダーとプロセス）を図示してみましょう。
[図]
①大学職員は（内部的な情報に基づいて）時刻表の元データ（おそらくExcelと予想）を作成します。これが、次週のバス時刻表（案）の元データです。
②大学職員は、バス事業者にバス運行委託を行っています。ここで、大学職員からバス事業者へ、次週のバス時刻表（案）の承諾を得ていると考えられます。ここは時刻表元データ（もしくはPDF）をバス事業者に毎週提出しているのではないかと仮定しています*6。
③承諾を得た大学職員は、バス時刻表（案）データからバス時刻表PDFを作成します。④また、大学Webサイトにアップロードを行います。
こうして準備されたバス時刻表PDFを、大学バスの利用者は随時大学Webサイトにアクセスして確認を行う形になります。
目指すサービス全体像の整理
今回目指すことは、④で大学サイトにアップロードされたバス時刻表PDFに基づいて、バス発着時刻のデータ利用希望者に（もう少し扱いやすい形式で）データ提供を行うWeb-APIの作成 です。①から④の業務プロセスは触らないので、良く言えば従前通りのまま*7、ちょっとしたバス利用者アプリを卒論/学生プロジェクトなどで作りたいという場合には役立ちそうなものを目指します。
これを反映した、目指すサービス全体像を図示してみましょう。
[図]
今回、開発を行うのは画面下の青い部分です。
大学Webサイトから、バス時刻表PDFを取得します。更新される頻度を見ると、Web-APIのアクセスの度に取得することは避け、日ごとや時間ごとで取得し直すような工夫もしておきたいところです。
取得したバス時刻表PDFからテキストデータでバスの時刻を抜き出し、JSONにして、他のシステムやサービスから利用できる様にします。
ただし赤い部分は、Web-APIが無事完成したら誰か学生に使ってもらえればいいなという形で、今回の開発の範囲に含めません。
ここまでのまとめと次回
本稿では、ざっくりとしたモチベーションを述べた上で、さて開発！...となる前に、サービスの現状と目指すことを整理しました。
開発に取り掛かる上で、まずは全体像と目指すところを整理 してみましょう。
大学のサービスやその基となる業務プロセス上の課題は、学生にとっても身近なテーマで挑戦しやすい内容です。
その一方で現状のサービス全体像や目指すゴールの整理を怠ってしまうと、自分や他者が感じる面白さは別として、結局何のための成果物なの？になってしまうこともよくあります。今回の方法も業務サービス自体に触れるものではないので、そもそものサービス改善や課題解決を目指したゴールではありません。なので本当はこのサービス自体に意義があるのか？などもここで検討が出来そうですね。
目指す物事に優劣はないと思いますし、私は 車輪の再開発はすべき派で、別にサービス改善に繋がろうが繋がらなかろうが、面白そうならどんどんやってったらいい という考えなのですが、その一方で、自分達の挑戦する意義や価値、目的や目標がどこにあるのか、それによって現実の何がどう変わるのかという視点を持ったり、時にそれを再確認や振り返りながら物事を進めていくことは、ソフトウェアの開発はもとより、学生の間のさまざまな挑戦の中でも、社会に出てからも常に自問自答しながら進めていくことだと思っています。まずは全体像と目指すところを整理するのは、こうした点にも役立ちます。
次回は、「さて、PDFを取得する部分をどうしようか」というパートを例に、私ならこう進めるなという内容で続けていきたいと思います。
*1:"潜んでいたパワーを引き出せば隠れていたネガも当然出てくる━━" 湾岸ミッドナイト SERIES 63 より
*2:職員の業務的にも結構な負担が大きい気はする。
*3:例えば「サービスの要求（や、ステークホルダー・業務ドメインの）分析をせずに取り組んでしまい、各ステークホルダーが求めるサービスに届いていない」「スキル or 時間不足」「長期的に運用やメンテナンスする前提ではないので、継続されない」などに陥りがちになることが多い。とはいえ学生なんだから、形になったのなら胸をはって良いと思う。
*4:個人的には、GTFS-JPを吐き出せるExcelフォーマットに時刻表を喰わせてGoogleMapあたりで公開すればもうそれで円満解決ではと思っている。ただし各ステークホルダーとの調整もあるので趣味レベルで終わる話ではなさそう。そこまでやるならGTFS-RTぐらいまでやったら面白いんだけど。
*5:未完にならないようにしたいが、すでに記事を載せたかった日から10日ぐらい経過してて、もう男坂登り始めてる。
*6:例えば、バス時刻表の管理業務を支援・改善するサービスを作りたい場合は、ここまで、時刻表の元データの作成過程も含めて大学職員・バス事業者と要求分析（ジャーニーマップを作ったり）すべきだが、今回はゴールが異なるので仮定のままとしている。興味がある学生はぜひ取り組んでみたらいいのでは。
*7:悪く言えば、サービスや業務プロセスは何ひとつ改善されてないのでやる意味ないなと思うけど、私個人はServerless Java Containerが使ってみたいだけなので良しとする
