都知事杯オープンデータ・ハッカソン参加レポ：車椅子×混雑回避ルートを作る挑戦

はじめに

株式会社メンバーズ デブオプスリードカンパニーの橋本です。

私が所属しているデブオプスリードカンパニーには、ラボ活動という業務とは別で自由にテーマを決めて研究活動を行う制度があり、私は「コンペティション・ハッカソンラボ」というハッカソンなどの開発イベントに参加することを目的としたラボを立ち上げています。

その活動の一環として今回、東京都が主催する都知事杯オープンデータ・ハッカソンに参加したので、その際のレポート記事をまとめます。

都知事杯オープンデータ・ハッカソンとは

都知事杯オープンデータ・ハッカソンは、東京都などが公開するオープンデータを活用し、都民の課題解決やQOL向上等につながるサービスを考え、形にするハッカソンです。

審査では、データを有効に活用できているかという観点に加え、アイデア、技術、社会的なインパクト、都民にとっての使いやすさなども重視されます。

参加のきっかけとしては、普段の業務とは異なる領域であり、身近な東京都の課題を解決するインパクトが、意義深い活動になると感じたからです。同じ部内で時間の都合がつく人を誘い、4人チームで参加しました。参加したメンバーは、三上さん・谷森さん・蔡（サイ）さんです。

開発のテーマ・課題

私たちが開発作業を始めたタイミングでは、まだハッカソン運営からテーマが発表されていなかったため、チーム内で独自にアイデア出しをしました。（テーマは運営から提示されるものでも自分たちで考えるのも自由です。）

その中でチームメンバーから一つ、あるニュース番組で、車椅子を利用する方が事前に多目的トイレの有無を調べてから外出を決めていることを聞いた話が出ました。

外出先を決めるとき、多くの地図サービスは「最短で到着できるルート」を案内してくれます。しかし、その最短ルートが、すべての人にとって移動しやすいとは限りません。

例えば、次のような情報が外出のしやすさを大きく左右します。

• 経路上に階段や急な坂がないか

• 車椅子やベビーカーで通りやすいか

• 周辺に多目的トイレなどの設備があるか

• 人混みを避けて移動できるか

特に注目したのが、混雑も移動上のバリアになり得る点です。混雑していると、エレベーターに乗りにくかったり、多目的トイレが利用中だったり、車椅子やベビーカーで通れる空間が狭いことがあります。

そこで私たちは、単にどこに何があるかを示すだけではなく、使用するあらゆるユーザーがどのルートなら無理なく行けるかを考えられる「外出支援サービス」を構想して実現に向けて調査に入りました。

実際に制作したプロトタイプ

今回のハッカソンでは、まず対象地域を（弊社の所在地である）東京都中央区に絞り、観光施設やバリアフリーに関する情報を地図上で確認できるプロトタイプを制作しました。

↑制作したプロトタイプの画面

主な機能は次のとおりです。

• 地図上に観光施設やスポットを表示する

• 目的地を選択する

• バリアフリーに配慮したルートの候補を表示する

• 多目的トイレなど、外出を支援する施設情報を確認する

• 混雑する場所を避けるルートの考え方を検証する

プロトタイプでは、東京都や中央区が公開する観光施設・バリアフリー設備などのデータに加え、OpenStreetMapなどの地理情報も組み合わせる方針としました。地図の表示やルート検索についても、車椅子向けの経路探索や混雑エリアの回避を考慮できる技術を調査しました。

インフラにはAWSのサーバーレスサービスを採用し、短期間でも構築・運用しやすいシンプルな構成にしました。

AIの活用

今回はメンバーが全員、業務の合間で作業したため、どうしてもまとまった開発期間を確保することが難しかったです。そのためAIをフルに活用して、仕様の策定から設計、実装、さらには発表資料の準備まで壁打ちしながら進めました。メンバーそれぞれ担当するフェーズが異なるため、前フェーズのAI対話ログや生成物を次のメンバーのAIへ引き継ぐ「リレー方式」で開発を進めましたが、認識の欠落等もなく無事に形にすることができたと感じています。今後はこういったフローも最初に整備してより円滑にフェーズを回せるようにしたいと思います。

取り組みを通じて得た学び

今回のハッカソンで得られた学びとしては以下3つあります。

1. 公開されているデータが、そのまま使えるとは限らない

2. 課題の定義が技術選定を左右する

3. 短い期間だからこそ、MVPを絞る

公開されているデータが、そのまま使えるとは限らない

オープンデータを調査する中で大変だったことは、公開データの形式が異なる点です。

データごとに項目や形式が異なっていたり、位置情報が不足していたり、複数のファイルに情報が分かれていたりすることがあります。そのため、実際のサービスで利用するには、データの確認、変換、補完、統合といった作業が必要でした。

また、民間のオープンデータサービスでは有償提供のものが多く、その辺りも今回のようなハッカソンの開発では見落としがちなポイントでした。なるべく無償で提供されているものを選定していき、有償のみで提供されているデータは将来的な実装計画として盛り込むことで対応しました。

課題の定義が技術選定を左右する

当初は一般的な地図サービスの利用も検討しました。しかし、「地図を表示する」だけでなく、「車椅子などの利用条件に合った経路を探す」「混雑する場所を避ける」要件を明確にすると、必要な地理情報やルーティング機能も変わります。

先に使いたい技術を決めるのではなく、解決したい課題から必要な機能を整理することの重要性を改めて実感しました。

短い期間だからこそ、MVPを絞る

理想を追求すると、対象地域、対応する利用者、データの種類、機能はいくらでも広げられます。一方、ハッカソンでは限られた期間で、アイデアの価値が伝わる状態まで形にする必要があります。

今回は対象地域を中央区に絞り、地図表示、目的地の選択、ルート表示といった中核となる体験から実装しました。この絞り込みによって、サービスのコンセプトを実際に触れられる形で確認できました。

まとめと今後の展望

今回のハッカソンを通して、オープンデータを使ったサービス開発では、データを見つけることだけでなく、利用者の体験につながる形へ整えることが重要だと学びました。

また、バリアフリーを設備の有無だけで捉えるのではなく、時間帯や混雑状況によって変化するものとして考えることで、外出支援サービスの新しい可能性も見えてきました。

今後は、対応地域と利用できるデータを増やすことに加え、時間帯別の混雑情報との連携や、利用者ごとの条件に応じたルート提案なども検討したいと考えています。

今回得た、課題を定義し、データを調べ、限られた期間でプロトタイプに落とし込む経験を、今後のハッカソンや日々の業務にも活かしていきたいです。