見出し画像

フェリー全国カバー率100%への歩み

この記事は、NAVITIME JAPAN Advent Calendar 2022の15日目の記事です。

こんにちは!ぱてぃおです。ナビタイムジャパンでバス・フェリーデータの開発を担当しています。

2022年12月15日(木)に、ナビタイムジャパンは全国のフェリーカバー率100%を達成しました。

2018年1月の路線バスカバー率100%、2021年3月のコミュニティバスカバー率100%に続いての全国制覇達成となります。

フェリーで海を渡る経路でしか行けなかったような場所にも、最適な案内が可能となりました。

フェリーデータ100%達成導入前後での経路比較例

そこで今回は、フェリーの100%導入までに、我々がどのようなことを行ってきたのかをご紹介します。


「フェリー100%達成」に取り組んだ背景

当社では、2018年1月の路線バスカバー率100%達成、2021年3月のコミュニティバスカバー率100%達成と、全国のバス経路については現実に即した経路案内を提供できるようになりました。

その一方で、「フェリーを利用してどこかの島に行く」といった経路を調べたいときに、経路が案内されないといった課題がありました。それもそのはずで、これはフェリーの経路を表示するためのデータが揃っていないから、というシンプルな理由によるものでした。

バスのデータが入っていないときには、徒歩で最寄り駅から1時間歩くような過酷な経路だとしても目的地へ向かう経路が出たのですが、フェリーではそうもいかず、そもそも経路検索結果が表示されなくなります。海を泳いで渡る経路を出されても誰も嬉しくないので仕方がない部分です。

島国であり、海洋国家である日本において、フェリーは重要な公共交通です。古くは船を中心とした輸送で街を活気づけ、今なお本土と島の間など地域同士をつなぐ足として活躍しています。

そこで移動手段がありながら経路検索結果として表示されていない経路をなくし、よりよいサービスを提供したいと考え、フェリーカバー率100%に取り組むこととしました。

フェリー100%導入に向けた動き

1. 調査

フェリーデータのカバー率100%導入を目指すにあたり、母数を知る必要があります。国土交通省が提供する『フェリー事業者数データ』(令和4年4月1日版)の一覧データを母数としました。

そのリストに記載のある全国のフェリー事業者のHPをひとつずつ確認し、当社で扱っているデータが存在しない事業者のリストアップを行いました。

なおこの際、遊覧船など移動を目的としていないフェリー航路は掲載を行わないという判断をしました。

2. データを集める

フェリーの存在は調査で明らかとなりましたが、投入するデータがなければ始まりません。各事業者(船会社や地方自治体)と契約を結び、主に下記の3つの方法でデータを集めました。契約は当社渉外担当から各事業者へお声がけする形で行いました。

1.  HPに掲載されている時刻・運賃データを利用
2. 各自治体が管理しているエクセル等の時刻表データを利用
3. オープンデータを利用

路線バスやコミュニティバスのカバー時とデータ収集方法のラインナップは変わらないのですが、その割合が変わりました。
バスを導入した際にはデータを受領する(2番か3番)場合が多かったのですが、フェリーでは「HPに掲載されている時刻・運賃データを利用」するケースが大多数を占めています。これはフェリーとバスの公共交通としての特色の差が顕著に出ている部分かと思います。

例えば、フェリーは港を数カ所結びますが、バスは大量の停留所を経由して目的地に向かうといった違いがあります。バスのように大量の停留所の緯度経度情報は必要なく、事業者HPに掲載されている港位置情報だけで十分なケースも多かったため、受領データにこだわらずに開発することができました。

データ作成紆余曲折

フェリーのデータは前項であったように、その多くがHP掲載情報を利用することでデータを作成しています。HP掲載情報を利用しない場合には、様々なフォーマットでデータを受領して作成することになります。
当社では多種多様なフォーマットからナビタイムジャパン独自のフォーマットに変換する対応を行っており、公共交通データのオープンフォーマットであるGTFSから作成する会社もいくつかありました。

路線バスとコミュニティバスのカバー率100%達成時に蓄積されたノウハウを基に、誰でもナビタイムジャパン独自のフォーマットのデータを作成できる仕組みになっています。そんな中、フェリー対応だからこそ生じた、データ作成時の考慮点をいくつか紹介します。

1. 港名の定義

フェリーを導入する上で真っ先に問題となったのが港名の定義です。
導入当初、港名はそのままの名称(例:亀徳港)として扱っていました。
ところがこれにはいくつか問題がありました。

その一つに「ユーザーから見てその港がどこの島にある港なのかわからない」という問題があります。

簡単な例ですが、亀徳港 と聞いてもどこの島の港かわからない方が多いかもしれません。その一方で 亀徳港<徳之島>とすることで、「奄美諸島の徳之島にある港だ」とわかる人が増える、といった具合です。
徳之島に行きたい人が経路を調べる際、港名を知りたいかというと、本質的にはそうでもないと思います。そういった意味で、島名を検索すればヒットするような港名とすることはフェリーを導入する上で大事な要素でした。

そこで新たに導入したフェリー航路については、以下の港名の定義を設けました。
※別の理由などで必ずしもこの限りではありません。バス停留所と区別するために〔航路〕を付与する場合などがあります。

・本土(本州島・北海道島・四国島・九州島・沖縄本島)およびこれらの島から船/飛行機を使用せずに行ける島の港名は特別な対応はしなくてもよい
 例)東京港竹芝客船ターミナル、佐渡両津港、宮崎港〔航路〕など

・上記を満たさない離島に存在する港には島名を付与する
 例)亀徳港<徳之島>、平土野港<徳之島>

2. 港ノードと航路を孤立から守る

フェリーデータを導入しても、ある設定を軽視していると
「経路検索結果に反映されなかった」そんな悲劇が起こり得ます。

それがノード間の徒歩時間の設定が漏れている場合です。
※ノードとはネットワークの結節点を指しますが、特にここでは停留所や港といったものの総称だと思っていただければと思います。

例えば、バス停留所「宮崎港」と港「宮崎港〔航路〕」がある場合、徒歩時間を設定できていないと、この2つのノードをつなぐことができません。

せっかくある島へ行ける航路が出せるようになったのに、地上を走るバスや鉄道といった交通機関と経路が繋がらないとなると、フェリーデータを導入する意味がなくなってしまいます。
1社ごとに「どこに設定するか」「その設定箇所に間違いないか」「事業者HPで案内されている経路が出るか」などの観点で慎重に確認をした上で設定をすることで、経路検索結果へ反映をしています。

3. データ対応しきれない場合

フェリーは海を相手にした公共交通です。
当日の海上状況や冬季の日照時間などにより、ダイヤが通年同じとは限りません。そのため日々HPをチェックして運行状況を検知できるようにしています。

当日の海上状況で運休や臨時ダイヤなどがある際に、データの更新が間に合わない場合があります。このような際にデータの更新はできずともその情報を伝える手段としてお知らせ文言の掲載があります。これによりユーザーの経路検索結果画面上に重要な情報を掲載し、利用前の段階でその情報に気が付ける仕組みとなっています。

これはあくまで体感ベースの話になりますが、バス導入時と比較して、事業者様から文言掲載や文言対応した様子のキャプチャを要望いただくことが多かった印象です。
文言を掲載できるかどうかで事業者側が掲載許諾を出す心理的なハードルが低くなったことも、今回の達成に一役買っていたのではないかと思います。

掲載許諾をいただくまで

ここまでデータ作成について深堀りしましたが、それ以外の面として掲載許諾の話を簡単に紹介します。

事業者様から掲載許諾をいただきたいときには当社渉外担当から連絡をします。載せてほしいと言ってくださる事業者様から慎重に判断をされる事業者様など様々です。例えばある事業者様の場合は営業所まで伺ったり、定期的に連絡を取ることで熱意をご理解いただけたり、それぞれの事業者の方に合わせて最終的な許諾というゴールまで対応しました。

今後の展望

フェリーカバー率100%を達成したことで、「フェリーがあるのにルートがでない」といったケースがなくなりました。ただこれで終わりではないと考えています。

高速バスやロープウェイ、シャトルバスなどなど現実にはまだ多くの交通機関が存在します。これらの交通機関の網羅率も上げ、より便利で、より迅速に最新の情報提供ができるサービスを目指します。

私たちはこれからも事業者様と相互協力・連携し、ナビタイムジャパンにしかできない、現実に即したユーザー体験を実現出来るよう対応していきますので応援のほどよろしくお願いいたします。