バス会社様サイト向けデータの運用基盤を開発した話
こんにちは、miiです。
ナビタイムジャパンでバス会社様サイト向け時刻表データの運用・開発を主に担当しています。
現在所属しているチームは以前も所属して、久しぶりに古巣に戻ってきました。このチームでは「バス会社様サイト向け時刻表データの運用」を日々行っています。
このチームでは、私が約9年前に担当して導入した「バス時刻表データを自動生成する」仕組みが、現在も現役でシステムを支えてくれていました。
今回は、長く利用される仕組みを今後も生み出すため、当時を振り返っていこうと思います。
時刻表情報反映は迅速性・正確性が求められる
公共交通機関を利用していて、時刻を知りたいときは紙媒体で調べたり、
Web・アプリで調べたりしますが、その情報が誤っているとユーザーの大事な時間を奪ってしまうことになります。
当社で作成しているバス会社様サイト向け時刻表データも同様に、誤りが許されません。そのため、バス会社様から改正データを頂戴した際は、誤りのない情報を迅速に届けられるよう日々改善を続けています。
なぜ仕組みを作ったのか
当時を振り返る
仕組みを検討し始めた2014年当時は、数社のバス会社様とお取引があり、
当社向けサービスでもバスデータ導入100%を目指して鋭意活動中の頃でした。
きっかけは、新しいバス会社様サイト導入の開発が、本格始動し始めた頃です。
「今後、更に全国のバス会社様とお取引が増えてくるとなると
より迅速かつ安定している時刻表データの運用基盤が必要になる」
そのような声がチームメンバーから挙がることが増えていました。
バス会社様サイト向けデータの導入をするときは、バス会社様から頂戴した改正データに対して主に下記を行っています。
バス会社様のご要望を実現できるデータ内容になるようデータを変換する
当社の検索システムで参照できる形式にデータを変換する
現在の仕組みができるまでは、バス会社ごとに別システムを開発していました。
当時は、1年に4社以上のサイト導入開発を進めることが多かったので、やり方を変えずに進めていたとしたら、5年後には20社分ものシステムを作ることになっていたと思います。
実際に、数社導入していた頃でも、開発コスト・担当者の異動時の引継ぎコスト等が会社ごとに発生していたり、自動ではなく手作業でデータを作成している工程も多数あったため、改善の必要性を感じていました。
開発を始めた頃
先行して、検証用環境にデータをリリースする仕組みは自動化済みでしたので、データの作成作業の改善に注力して進めることにしました。
まず、システムの概要ですが、全自動を最終的に目指し、
データ作成の共通の工程は事前に用意しておき、
各バス会社様の改正データから当社の「共通フォーマット」のデータに加工するコンバーターのみを新規開発する流れにしました。
受領するバス会社様のデータフォーマットは各社バラバラだったり、サイト導入作業を優先し、システムを実際に構築する工数も確保出来ていない状況だったため、共通システム化は難しいと考えていました。
しかし、数社導入したことによりノウハウが溜まったことと、システム化できる引き出しを持ったチームメンバーが合流したことにより、上記のシステム化が実現しました。
共通フォーマットはバスのデータに詳しいチームメンバーに設計してもらいました。
今後もバス会社様からの要望を受け、拡張しやすいような設計になっています。また、当時は今ほど日本に普及が進んでいなかったGTFSデータのデータ形式も参考に設計を行っています。
はじめは苦労した
まずは、導入を進めていたバス会社様をターゲットに開始しました。
バスのデータは例外が多いため、共通システムとして定義することが難しく、設計と開発に何度も変更が入りました。
「連続して同じ停留所に停車する運行路線」、「複数回同じ停留所に停車する運行路線」等、想定されるデータパターンが多くあります。
わかりやすい例を挙げると「停留所の名称」に関するお話です。
はじめは、以下で一意になるようデータ作成することを想定していました。
停留所を一意に識別する番号「ID」
停留所の「名称」
「利用サービス（バス会社様）」
しかし、以下を考慮する必要がありました。
同じ停留所の名称でも同じ停留所とは限らない
一社だけでなく、複数の会社様からデータをご提供いただいて、サービス提供する場合がある
上記を考慮したものに再設計し、開発を進めました。
進めていくと考慮点が多数挙がりましたが、導入スケジュールに影響がないよう進める必要があるため、闇雲に進めないよう後述を心掛けて進めることにしました
仕組みを作るときに心掛けたこと
基本的なことですが、下記を遵守して少人数で開発を進めました。
リグレッションテストを常におこなえるようテストデータを予め準備した
各工程を自動処理で行えるようにした
または、将来的に自動化しやすい環境に整えた
まず、1についてですが、開発の度に、Jenkinsでテストできるよう下記のような仕組みを整えました。
バスの運行パターン（循環路線等）を洗い出し、その全パターンを「共通フォーマット」のデータとして用意する
テスト用の架空のバス会社として、データを作成する
予め準備しておいた期待値データと比較し、一致していれば問題なし
一致していなければ問題ありとして、不具合を修正する
「期待値 時刻表等検索データ」と「テスト用 共通フォーマットデータ」を予め準備しておけば、何度でも手軽にテストできるようになっています。
また、テストの追加も可能にし、機能改修もしやすくしました。
上記仕組みのおかげか、当時のQA担当から「データ起因の不具合は、ほぼありませんでした」というコメントをもらえたことを今でも覚えています。
次に2についてですが、基本的にデータ作成はJenkinsで自動作成できるように環境を構築しました。
実際には、初回リリース時に全てJenkins化することはできませんでしたが、
データ作成の選択肢としてまずは手作業ではなく、自動処理に近いものを用意するようにしました。
はじめから手作業で検討を進めてしまうと、自動化に関して気後れすることもあるからです。100%のものでなくても、ある程度自動化を進めておくことで、他のメンバーが改善を進めやすくなると考えました。
リリース後も上記を念頭に処理速度を改善したり、追加機能を実装したりと、開発は継続的に行っていきました。
最後に
幸いにもシステムやバスのデータに強いメンバーが日々改善してくれていたおかげもあり、約9年経った現在もより改善が進み、2023年6月現在は数十社以上のバス会社様のデータを安定運用できています。
そして、日々のバス会社様のご協力がなくてはここまで続かなかったと思っています。
まとめです。下記が今に繋がっていると思っています。
初回リリース時に100%完璧なシステムを求める必要はない
しかし、継続的な改善ができるように基盤は整えておく
自動化しやすいようにしておく
自動化を見据えて検討する
リグレッションテストは容易にできるようにする
今回の振り返りが何かの役に立つと幸いです。