【エンジニア座談会】自治体向けアプリケーション「Geolonia Maps for Smart City」の開発の裏側を聞きました!
採用担当の山本です!でも先駆けとなった高松市さん向けの開発について、エンジニアと開発の裏側を振返りました。
是非ご一読ください。
今回は大橋さんと樋口さんが中心となって開発を進めておりましたが、お互いの仕事ぶりはいかがでしたか。
■大橋:
樋口さんはGeoloniaに入社して間もないのに、精力的に活動していました。
樋口さんの担当していた「水防アプリ」はもともと紙の地図や通報のメモなど紙ベースで業務をされており、その業務フローの理解をした上でデジタルに置き換える必要があります。
先方からの要望も複雑で、ワークフローの検討からエンジニアとして参加していました。
樋口さんはUIの設計はもちろん、ワークフロー図も自主的につくって対応されていたので高松市さんにとってもわかりやすかったのではないでしょうか。
絵を描いて先方へ提示していたことで議論も広がっていたと思います。
■樋口:
大橋さんは「水防アプリ」のバックエンドも手早くつくってくれて、私がフロントエンドでアップアップしていた中、助かりました。
一人で進めるよりも、誰かと一緒に案件を担当する方が仕事の進め方など他の人の良いところを学べるのでよいですね。
自分としては、もうちょっと実装力も上げていかないと、という課題が出てきました。
UIの絵がFigmaでパッと描けた分、実装に時間がかかりすぎなのでは、と自分では気になっていましたね。
その点、大橋さんはぱっとなんでもやっていたので、勉強になりました。
大橋さんが担当された「バタクス」のアプリもデータもらったらすぐに可視化し、すごく早く出来上がっていた印象です。
お客さんと話すのも上手で、フィードバックをもらって改善するのも早かったです。
■大橋:
「バタクス」では、ドメイン知識の情報をしっかり調べておいたことで、お客さんとスムーズに話せたのかなと思います。
「バタクス」(Vehicle of Advanced Tariff And Connection System)は
車両はタクシーで、バスのように決められたルート・ダイヤで運行する公共機関です。
そもそもなぜ「バタクス」が必要なのか?という背景知識がもともとはなかったのですが、自治体の担当者の方の講演や発表資料を集めて、どういうユースケースがあるのか、なぜ必要なのか、事前に調べました。
高松市のバスは費用の半分を市が負担して運行されていますが、それでも、赤字という状況です。
一方で、市民には免許を返納したお年寄りなどバスがなければ移動ができない人もいるので、バスをなくすことはできません。
■小林:
高松市さんのバタクスの取り組みは印象的でしたね。
僕は屋久島に住んでいるけど、最近近くの種子島空港バスを完全予約制にするという話がありました。定時運行バスに乗る人がいないみたいですね。
東京だったら運行しているバスに誰も乗らないことはまずないと思います。
誰も乗ってない、空気だけを運んでいるバスも問題になっていて、社会的に解決しないといけないな、と実感しました。
特に地方では車社会かつ高齢社会が進む中で免許を持たない人も何かしらの交通手段は必要なので、どうするかは問題になっていると思います。
事前のドメイン知識が重要なんですね。その後、バタクスの開発はどのように進みましたか?
■大橋:
開発当初はシンプルにバタクスのリアルタイムの位置情報をWeb上の地図に表示できるようにしたい、という話でした。もともと「バタクス」自体は運行ルートの地図が市民向けにPDFで公開され、運行されていたので、位置情報をアプリケーションとして提供したい、というご依頼です。
ところが進める中で、熱意にあふれる高松市の担当者の方が、「もう一工夫ほしい!大橋さん何か考えてよ!」とご期待いただき、GTFSを載せて表示させることにしました。
GTFSはバタクスに限らず、交通情報をワンストップで表示させたり、決済に関する情報も絡めることを可能にするデータフォーマットです。
■樋口:
「バタクス」の開発は、いい感じでしたね。
■大橋:
地方の公共交通機関は、需要の最適化が難しいというお話を自治体の担当者さんも話されていて、今後、需要予測なども組み合わせたサービスをつくると面白そうだなと思いました。
今回の案件でそういった問題に意識にある行政の方がいらっしゃるんだな、と知り、刺激になりましたし、お仕事させていただいて楽しかったです!
Geoloniaはエンジニアも積極的に自治体さんとの会議に参加しながら開発を進めていますよね。
■樋口:
今回、高松市では、大枠の何をつくるかは決まっている、くらいの段階でエンジニアが参加しました。私の担当した「水防アプリ」はいつの間にか、当初のお話よりも大きなプロジェクトになっていて、予想外でしたね。
逆になくなった企画もありました。
■大橋:
「水防アプリ」の方は実際に水防対策本部の現場に訪問もしました。
映画「シン・ゴジラ」の対策本部のようなイメージで大きなモニターやマイクが机から生えていたり、面白かったです。
実際に電話を受けてこの紙に記入して、トランシーバーのような衛星電話で現場に電話して、といった一連の業務イメージを掴めました。
関わる複数の課の人にもヒアリングをして、つくりこみましたね。
■樋口:
実際に訪問したり、オンラインミーティングでも予想以上に時間を使いましたね。
■小林:
力を入れて開発した分、横展開できるようにしないとね。
自治体さんとのやりとりで印象に残っていることはありますか?
■大橋:
担当者さんから「工夫してほしい」と言われて自分が提案したことに「もっとこうした方がいいんじゃない?」とフィードバックいただけたことは、先方から言われたものをつくるのでもなく、自分がつくったものがそのまま受け入れられるのでもなく、一緒に作っている感覚が持てて良い経験になりました。
■樋口:
やっぱり見た目があるとわかりやすいので、UI系を絵として見せることができて喜んでもらうことができました。つくったかいがあったと思いましたね。
ただ、UIを見せるだけだと、あとからの開発でデメリットになる部分までわかっていなくて、その段階でこれでいいと言われていても、後から改修になる、ということもあったので、学びを活かしてやり方の見直しは必要そうです。
今回の案件でベクトルタイルだからこそできた開発はありますか?
■大橋:
極端な話、ベクトルタイルの特徴である機械判読性がないとつくれないと言っても過言ではありません。
ベクトルタイルの地図は「データ」の地図なので、「画像」でできている地図とは、「データの読み込みの速さ」「情報のハイライト」などの観点で大きく違います。
画像データの地図では、もともと表現されている不要な情報を消すことができませんが、ベクトルタイルの地図では、「自分が乗車予定の路線の路線図だけハイライト」というように操作に合わせて表示させるデータを変更することが可能です。クリックしたバス停に紐づいた時刻表データを取得するなど、必要なデータだけを取り出すことも可能ですね。
これはラスタータイルの地図ではできないことだと思います。
バタクス活用のために作った「いつくるなび高松」では例えばバス停をクリックすると、「現在」の時間の時刻表を表示させることができます。読み込んで表示させる表示速度も速いのもベクトルタイルならではです。
バス停に紐づく路線のルートはIDを取得して照らし合わせて、路線を表示する仕組みになっていて、よく目にする「路線図」のようなすべての路線、すべてのバスが表示される地図ではなく、乗る必要のある路線だけハイライトされて表示されます。
ズームレベルでの情報の間引きなども含め、見たい情報をごちゃごちゃさせず早く表示させることが可能です。
■塩飽:
自分の住んでいる市の都市計画関連のWebマップは他社さんが作られているWebマップですがロード画面長くてなかなか表示されないですね。起動の時だけでなく違うエリアへ地図画面を動かした時もなかなか表示されないです。
ベクトルタイルはスムーズに表示されるので、そこが魅力ですよね。
■小林:
利用者にとっての魅力と開発したい提供者側にとって両方ともベクトルタイルにする利点はありますね。
地図サービスの提供者側はつくりやすいと思います。データを自由に重ね合わせることが簡単にできるのも魅力です。
利用者側にとってはベクトルタイルが機械判読性があるので、例えばそのバス停がなんという名前のバス停なのか、クリックすればわかります。
画像の地図では人間が目で見て「バス停だ」ということはわかりますが、画像データのみなので人間が目で判別できる情報以上の情報は取得できません。データで配信されている地図は、パソコンが「これはバス停」と判別でき、そこに紐づくバス停の名前などの情報もすべてデータで取得できます。
この機械判読性がまさにベクトルタイルの特徴ですね。
■樋口:
Geoloniaに入社してはじめて地図アプリをさわったので、逆に画像で地図をつくったことがなくわからなかったですが、そういわれると確かに、今回の「水防アプリ」もベクトルタイルじゃないとできなかっただろうなぁと思いました。
アプリケーション開発で地図を扱うからこそ気を付けることはありますか?
■大橋:
GIS周りの知識は必要なことでしょうか。
たとえば今回の開発で建築計画概要書のデータをもらったときは座標系もらって変換などの対応が必要でした。そのあたりの知識は普通のアプリケーションとは違うかなぁと思います。
■樋口:
私は今まで経験したアプリ開発と実装の仕組みが違うので、マップのデータがロードされるか、データが書き変わっているか、など考えながらフロントエンドの実装するのが大変でした。
仕組みを理解しないと使えないと思います。
■小林:
地図を使う、地図がメインになるアプリは、同じ画面がずっと開いている状態が多いですよね。
一般的なアプリはページ遷移、ページビュー、他のページへの誘導などが多いですが、地図メインだと、地図から離れることはないので、同じ画面の中で操作しますよね。
ページ遷移ではないフローで、地図の上に表示する、周りに表示する、という動きになるので一般的なアプリを設計する時と考え方が違うところはあります。
それが一番大きな違いですね。
今作っている管理画面は地図じゃないから、久しぶりにページ遷移の設計してますね。
今後のGeoloniaMapsforSmart Cityの開発で取り組んで行きたいことを教えてください!
■樋口:
まずは、管理画面と公開型GISを提供しながら、オプションで水防アプリも展開できればいいなと思います。
横展開しやすいものをつくりたいですね。
■小林:
導入を簡単にしたいよね。
今はそれぞれの自治体にカスタマイズで開発をしていますが、だんだんテンプレート化して、理想としては都市計画はこういう形で提供する、という形を決めてあとはデフォルトの設定で処理することができるようにしたいですね。
それぞれの自治体さんが違うデータを持っているけど、提供する自治体さんの数を増やしていけば、自然にできるのではないかと思います。
■大橋:
以前、けいたさんがデータをアップロードするだけでスマートマップがつくれるアプリ
をつくっていたのですが、そのくらい使い勝手の良いもの、簡単につくれる仕組みもつくりたいですね。
■塩飽:
今回の「バタクス」の資料を見て、アプリをつくるために自治体さんの導入背景を知ることは重要だなと思いました。高松市において「バタクス」は公共交通空白地域に導入されているようですね。
自治体さんの抱える課題を知ることも大切だと思います。
ありがとうございました。
株式会社Geoloniaでは、一緒に働く仲間を募集しています。
少しでもご興味を持たれましたら、是非ご応募いただき、カジュアルにお話ができればと思います。
この記事が気に入ったらサポートをしてみませんか?