Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a GTFS-JPデータを用いた乗合バス事業の電子申請に向けた基礎検討 ～帳票地獄からの脱却による働き方改革を目指して～
Semelhante a GTFS-JPデータを用いた乗合バス事業の電子申請に向けた基礎検討 ～帳票地獄からの脱却による働き方改革を目指して～ (20)
Mais de Kohei Ota
Mais de Kohei Ota (20)
GTFS-JPデータを用いた乗合バス事業の電子申請に向けた基礎検討 ～帳票地獄からの脱却による働き方改革を目指して～
- 1. GTFS-JPデータを用いた乗合バス事業の 電子申請に向けた基礎検討 ～帳票地獄からの脱却による働き方改革を目指して～ 第59回土木計画学研究発表会 トラフィックブレイン 太田 恒平 共著 水野羊平(永井運輸), 三浦公貴(青森市交通部), 伊藤昌毅(東京大学)
- 6. 6 帳票地獄
- 9. 9 研究概要
- 10. 研究の動機 10 ◼研究対象 • 路線バス申請の電子化 ◼目的 • バス事業者の書類作成、運輸行政の書類確認にかかる労力軽減・高速化 • 行政による交通マネジメント・計画の高度化 • 事業者による柔軟な運行改善 • 標準的なバス情報フォーマット（GTFS-JP）整備促進(キラーコンテンツになる) ◼今取りかかる理由 • バス業界の人手不足、官民双方の働き方改革 • デジタル・ガバメント、EBPM • 標準的なバス情報フォーマット（GTFS-JP）の普及 必要性・実現性・関心が高まってきた今こそ実現に向け歩み出したい
- 11. 研究の構成 11 ◼実態・先行例調査（追加） • 事業者ヒアリング@永井運輸 • 運輸局ヒアリング@関東運輸局 • 文献調査 ◼全体構想（追加） • 課題の整理 • ロードマップの作成 ◼GTFS-JPによる既存様式の作成 • 各種様式の検証 • 課題の整理 ◼実現に向けた検討（追加） • 技術的な試作 • 検討計画 ※提出から3か月以上経過のため、追加研究が多く恐縮です
- 13. 13 実態・先行例調査
- 14. 14 事業者ヒアリング@永井運輸
- 15. 事業者ヒアリング先 15 ◼訪問先 • 永井運輸(株) @群馬県前橋市 ◼事業規模 • 乗合バス25台 ◼回答者 • 水野羊平（バス事業部 営業課長） • バス事業者事務員 18年目 • 事業計画・運行計画等が主務 ◼調査日 • 2019/06/03 小規模事業者のワンオペ事務員
- 17. 作業量 17 ◼申請回数：31回/年(H30) • 臨時便 29 • 時刻変更 1 • 営業所・車両 1 ◼紙量：約200ページ ◼紙作業時間：業務時間の約3割 • 申請関係が業務全体の約7割 • その4割程度が書類作成、5%が紙提出 • 年間700時間程度が費やされている ◼印刷数：6部～ • 運輸局 旅客第一課、運輸支局 輸送課 • 県警、所轄警察署 • 道路管理者 営業課長というより申請課長
- 19. 運輸局ヒアリング先 19 ◼訪問先 • 関東運輸局 自動車交通部 旅客第一課 ◼体制 • 監理係 係長1名、係員3名 ◼対象地域 • 東京、神奈川、埼玉、千葉、埼玉、 茨城、群馬、栃木、山梨 ◼調査日 • 2019/06/07
- 20. 作業量 20 ◼申請数：4000前後/年 • 事業計画変更：20-30/週 • 運行計画変更：50-/週 ◼ピーク • 12月末（4月改正の3か月前） 2月末（4月改正の1か月前, 協議会事項） に通常の2倍弱 ◼消費税増税の申請数 • 120-130社 4人で膨大な監理作業を行っている
- 21. 確認方法 21 ◼様式の遵守、情報同士の整合 • 目視確認。自動化したい。 • 運行回数表に間違いが多いので、時刻表も提出してもらっている。 • ➡正確で整合が取れたデータがほしい ◼現状の把握 • 申請は変更分だけなので現状は過去の申請に散在。実際は事業者Webサイト等で確認。 • ➡現状をまとまって把握したい ◼クリームスキミング • 競合の抽出、状況確認は他社Webサイト等を参考 • ➡競合候補を自動で抽出してほしい ◼運賃の確認 • 計算賃率は確認する。 • 三角表は、例外的な補正を中心に確認するが、1マス1マスは確認しきれない • 消費税対応時は、会社全体の増収率算定表を中心に確認 目視確認に苦労しているのが実態
- 22. 22 文献調査
- 23. 海外事例 23 UKでは標準フォーマット(TransXChange)を用いた 電子申請(Electric Bus Service Registration)が2008年から稼働 https://www.pcb.its.dot.gov/StandardsTraining/modtransit7/ppt/mt7ppt.htm http://www.transportoffice.gov.uk/crt/repository/CONT074476.pd f 利用状況、最新状況、他国の状況などは 詳細未確認
- 25. 25 全体構想
- 26. 26 将来構想 様式に入力 OK ダイヤ表/ システム 紙 印刷 持参/郵送 目視確認 ダイヤ システム GTFS ＋α 申請 ツール ・基準数値 ・地図表示 ・他社路線 OK 一括出力 登録 自動判定 作成の 機械化 提出の 電子化 審査の 機械化・ セルフ化 補正 補正 現状 将来
- 27. ロードマップ 27 方法、ステップの刻み方、スケジュールを検討していきたい ステップ バス事業者 受け渡し 運輸行政 現状 ・Excel等で手作り ・ダイヤシステム出力 紙様式 ・目視 ・形式的確認中心 1.作成の 機械化 基礎データ(GTFS+α)から 既存様式データ出力 紙様式 (多少の変更を許容) 〃 2.提出の 電子化 〃 Excel様式 〃 3.確認の 機械化 基礎データから機械判読 データ(XML, JSON)出力 機械判読データ(XML, JSON) 確認の機械化 4.基準算出の 移管 基礎データ作成 基礎データ(GTFS+α?) 基準算出を事業者から行政に 移管 5.高度化 〃 〃 ・審査基準の高度化 ・交通計画や補助申請と連携 あえて細かく要素分解すると 作れる? 不足要素は? 現行指標の 構造化 法規の改定 が必要そう データ基盤上で 継続的発展 本研究
- 29. 29 表紙
- 30. 分析方法 30 ◼対象様式 • 事業計画：路線，停留所 • 運行計画：運行系統，運行回数/時刻，運賃 • 対象運輸局：中部運輸局 • 記載事例や手引きが充実しているため ◼観点 • 生成可否 • ○：生成可能 • ×：生成不能 • △：条件付き，または一部データ補完により生成可能 • 日本仕様(GTFS-JP)の拡張による有効性 • ○：拡張により可能となる • △：拡張により実現に近づくが不十分
- 31. 31 表紙 ～様式～
- 32. 32 表紙 ～分析結果～ 分類 個数 項目 可否 JP GTFS-JP対応項目 備考 申請先運輸局名 × 申請システムによる付与を想定 申請日 × 申請システムによる付与を想定 住所 ○ ○ agency_jp.agency_address 名称 ○ ○ agency_jp.agency_official_name 代表者(名) ○ ○ agency_jp.agency_president_po s, agency_president_name 代表者印 × 連絡先(電話番号) △ agency.agency_phone 利用者向け番号の流用 郵便番号 △ ○ agency_jp.agency_zip_number 申請者の流用 住所 △ ○ agency_jp.agency_address 申請者の流用 事業者名 △ ○ agency_jp.agency_official_name 申請者の流用 部署名 × 担当者名 × 電話番号 △ agency.agency_phone 利用者向け番号の流用 事業者 ○ [申請者]を流用 事業種別 ○ 固定値 事業計画 ○ 固定値 申請理由 × 運行開始予定日 △ calendar, calendar_dates 前回との差分から可能な可能性が あるが別項目が現実的 申請 申請者 申請内 容 申請担 当者 1 1 1 1 印鑑ボトルネック JP拡張も 担当者や申請理由 はサポートしない
- 33. 33 路線
- 36. 36 表紙 ～分析結果～ 地番問題 分類 個数 項目 可 否 JP GTFS-JP対応項目 備考 起点・終点 △ stops.stop_lat(lon), stop_times.shape_dist_travel shapes.shape_pt_lat(lon) *1新設区間を前回との差分で抽出、 もしくは申請者が指定。新規区間の両 端のstops座標からshapeの座標を検 索。 キロ程 △ stop_times.shape_dist_traveled 往復で異なる場合がある 起点・終点 △ stops.stop_lat(lon), stop_times.shape_dist_travel shapes.shape_pt_lat(lon) *1 *2 キロ程 △ shapes.shape_dist_traveled *2 幅員 △ *2 幅員の精度は道路データに依存 道路種別 △ *2 道路管理者 △ *2 国/自治体名まで。事務所名の把 握までは困難 廃止 路線 道路 区間 - △ - 各項目は路線内訳と同様。 廃止区間を前回との差分で抽出、もし くは申請者が指定。 路線形状 △ shapes *2 道路マッチング後の形状の方が他 データと整合 下絵 ○ - 地理院地図等を利用可能 新設 路線 路線 内訳 路線 道路 区間 路線路線 図 全体の制約事項：GTFS-JPに路線という概念はない。 形状(shape)は便(trip)に紐付くため、それらを集約して路線形状が抽出される。 *1 地番よりも高精度な緯度経度を取得可能。地番が必要な場合は逆ジオコーディングで変換。 *2 道路データへのマッチング、道路属性ごとの区間分割が必要。施設構内、私道等は独自入力が必要。 道路属性 問題 そもそも GTFSに 路線という 概念はない
- 37. 路線・系統・便 37 ◼路線・系統 • GTFSのrouteは曖昧 • trip(便)が主体のデータ構造 • GTFS-JPのrouteは方向別経路 • 申請の系統は双方向経路 • 申請の路線は通過可能道路 • ➡GTFS-JPのrouteをベースに方向を束ねる(jp_parent_id?)などの追加が必要? ◼形状の持ち方 • GTFS(-JP)はtrip(便)ごとに形状を割り当てている • 申請では系統に形状を割り当てている。往復で経路が異なる場合は方向別。 • ➡路線の形状作成はマージが必要
- 38. 地番 or 座標 38 ◼住所⇔座標の変換 • ジオコーディング：住所➡座標 • 逆ジオコーディング：座標➡住所 ◼位置参照情報ダウンロードサービス • 国交省 国土情報課がWeb APIを試験提供 • 逆ジオコーディング機能を直接提供してい ないが、システムを組めば可能 ◼そもそも地番が要るのか • 道路運送法施行規則 • 路線：起点及び終点の地名及び地番 • 停留所：名称及び位置並びに停留所間のキロ程 • 関東運輸局ヒアリング • 実務上は地図上で表示できれば座標でもよい
- 40. 全国で使える道路NWデータ 40 ◼有償道路NWデータ • 地図会社（ゼンリン等） • デジタル道路地図（DRM） • 数値地図2500 ◼無償道路NWデータ • Open Street Map(OSM) • 行政の基盤情報にしづらい • 国土数値情報 • 1995年のまま • 地理院ベクトルタイル地図 • 現在実験中 • 道路中心線を提供 • WebサイトだけでなくAPIで取得可能
- 41. 41 系統
- 43. 43 系統 ～分析結果～ routeと系統の 違いによる諸問題 全体として、1系統につきrouteが1つまたは往復別に2つある前提 *3 GTFS-JPでは、方向別にrouteを分けることを推奨しているので、 往復routeを同一系統に束ねる必要がある。 routes.jp_parent_route_idにより、親子関係を設定することで、系統名のマージは可能。 *4 往復の判定が必要 「一般乗合旅客自動車運送事業の運行計画の届出等の処理要領」によれば競合情報が必要 「運行系統図には(略)他事業者(略)の運行系統と重複している場合には、 当該他事業者名並びに当該重複部分の延長キロ及び運行区間を記載」 JPでの入れ方が微妙 識別できれば経由地 でなくても名称等で 良い by 関東運輸局 競合情報どうする？ 分類 個数 項目 可否 JP GTFS-JP対応項目 備考 申請者名 ○ [申請者]から流用 住所 ○ [申請者]から流用 届出日 × 申請システムによる自動付与を想定 系統番号 ○ ○ routes.jp_parent_route_id *3 系統名 ○ ○ route.route_long_name *3 起点・終点 ○ ○ routes_jp.origin_stop, destination_stop またはstops.stop_name routes_jpには停留所のIDではなく名称が 入っていることに留意 主な経由地 ○ ○ routes_jp.via_stop routes_jpには停留所のIDではなく名称が 入っていることに留意 届出内容 △ 前回との差分で変更内容を判定 停留所名 ○ stops 系統形状 △ △ shapes *3 *4 複数系統の形状が重なるため、 見やすく表示する工夫が必要。 届出内容 △ 前回との差分で変更内容を判定 申請 運行系統 申請系統図 1 系統 1 地図表示の工夫 届出内容を新旧比較 で判定できるか？
- 44. 44 停留所
- 46. 46 停留所 ～分析結果～ 停留所- 標柱問題 全体として、1系統につきrouteが1つまたは往復別に2つある前提 *1 地番よりも高精度な緯度経度を取得可能。地番が必要な場合は逆ジオコーディングで変換。 *3 GTFS-JPでは、方向別にrouteを分けることを推奨しているので、往復routeを同一系統に束ねる必要がある routes.jp_parent_route_idにより、親子関係を設定することで、系統名のマージは可能。 *4 往復の判定が必要 施設内は 系統形状や下絵 が解像度不足の 可能性あり 分類 個数 項目 可否 JP GTFS-JP対応項目 備考 系統 系統名 △ ○ route.route_long_name *3 系統×往復系統キロ程 △ △ stop_times.shape_dist_traveled *3 *4 停留所番号 ○ stops.stop_idまたはstop_code 往復共通の番号は、親停留所か、 stop_codeに設定する必要がある。 停留所名 ○ stops.stop_name 往復で停留所名が異なる場合はマージ が必要 変更内容 ○ stops 前回との差分で「既設/新設/廃止」を判定 位置（地番） △ △ stop_times.stop_lat(lon) *1 *3 *4 停留所キロ程 △ △ stop_times.shape_dist_traveled *3 *4 停留所番号 ○ [系統別停留所]を参照 停留所名 ○ [系統別停留所]を参照 標柱名 △ △ *3 *4 複数系統が乗り入れている場合 は、「往路/復路」だけでは表現しきれない 位置（地番） △ △ *1 *3 *4 設置場所 × 道路上/道路外の設定が必要 停留所× 系統 系統形状 △ △ shapes *3 *4 施設内は解像度不足の可能性あり 標柱名（地図上）△ [標柱名]参照 位置（地図上） △ △ stop_times.stop_lat(lon) *3 *4 停留所 下絵 △ 地理院地図等を利用可能だが施設内は 情報不足の可能性あり 系統 系統別 停留所 系統×停 留所 系統×停 留所×往 復 停留所 標柱 標柱 停留所 付近の 状況 停留所 付近の 概略図
- 48. 48 運賃
- 50. 運賃 ～永井運輸 記載例～ 50 ◼金額 • 普通運賃の三角表は、GTFS-JPデータから生成可能 • 小児運賃、定期券、回数券、ICカード運賃等についてはGTFS-JPデータに無い ◼算出方法 • 距離あたりの賃率、長距離逓減、初乗り最低運賃等の算出方法はGTFS-JPに無い
- 51. ◼位置・地図の表現 • 地番よりも緯度経度の方が出しやすい • 複数系統、新設・廃止系統を見やすく表示させるには工夫が必要 • ➡GISに停留所や系統図を重ね合わせ、Webブラウザで拡縮・選択できるのが理想 ◼路線・系統・形状 • GTFS・GTFS-JP・申請で、路線・系統の概念や、形状の持たせ方が異なる。 • ➡JP仕様で考慮はされていたが、改めて技術検討が必要。 ◼道路NW • ➡道路属性取得のためには、地理院地図等の道路NWベースで経路を定義するのが有効 ◼過去・競合との比較 • ➡行政が時系列データを管理・オープン化することが有効 GTFS-JPによる既存様式の作成のまとめ 52 プロトタイピングしながら解決策を模索していきたい
- 52. 53 実現に向けて
- 53. プロトタイピング 54 ◼帳票の作成 • 例）Excel VBAによる運行系統表（伊藤浩之, 諸星賢治@標準的なバス情報フォーマット/GTFS勉強会） ◼地図表現 ◼機械判読スキーマ { "$id": "https://example.com/geographical-location.schema.json", "$schema": "http://json-schema.org/draft-07/schema#", "title": "Longitude and Latitude Values", "description": "A geographical coordinate.", "required": [ "latitude", "longitude" ], "type": "object", "properties": { "latitude": { "type": "number", "minimum": -90, "maximum": 90 }, "longitude": { "type": "number", "minimum": -180, "maximum": 180 } } } 例： JSON Schema
- 54. ◼キックオフ • 勉強会を兼ねてプロジェクトを立ち上げる ◼実現すべき姿・進め方の検討 • 関係者の思いをすり合わせていく ◼プロトタイピング • プログラムを開発しながら、使えるところから使い、検討にフィードバック ◼法規の確認 • 変更が必要そうな箇所を洗い出し、早めに調整していく 合意形成 55
- 55. 56 質疑
- 57. 質疑記録 58 ◼Q1. 永井運輸ではデータ整備ができたようだが、ほかはできるのか？ • ➡去年の今頃は数社だったが、今は全国で120社のデータが出てきている。外注も含むが。 ◼Q2. GTFSは難しい印象だが、申請データがこれである必要はあるのか？ • ➡作成の難易はツール次第。情報提供用に広まっているので整備されつつあるのでGTFS ベースとしているが、 GTFSはむしろレガシーで緩いフォーマットなので、これをベース にして良いのかという不安はある。 ◼Q3. ボタン一つで簡単に使えるようなツールが公開されると嬉しい • ➡申請・ツールが電子化されて手続きが省力化されても、バス運行に必要な情報自体が多 いので、複雑なことに変わりない。 • ➡補足）これまでも申請書類を出力するツールはあったが、高価で導入できない事業者が 多かった。運輸行政側がツールを提供し、基礎データの提供を受け付けるのが本筋と考え ている。ただ、行政側で使いやすいツールを提供し継続的に改善できるかは疑問もあるの で、誰がツールを開発・保有するべきかは検討が必要。 ◼Q4. 受益者はバス会社なので、バス会社からお金を集めるのが筋では？ • ➡その通りなのだが、これを必要としている中小の事業者は困窮している。バス協会もIT に疎く業界を率いる状態にない。出資をしたがっている財団や、クラウドファンディング などの手もあるかもしれない。まだ答えは持っていない。
- 58. 質疑記録 59 ◼Q5. 審査業務を電子化するのはかなり困難では？ • ➡全ては困難。警察と協議などは、外部との交渉で、かつ基準が曖昧なので難しいだろう。一方で、 記載内容の整合などは機械化容易。今の運輸行政はこういった形式的なチェックが多い。 ◼Q6. 警察との協議にも本提案は有効か？ • ➡そう思う。今、申請の記載方法は事業者によりまちまち。例えば地図の下絵がきれいな拡大図に なり、さらに航空写真や道路台帳図と重ね合わせれば、協議もしやすくなるだろう。判定自体の機 械化だけでなく、統一的に見やすくしてコミュニケーションロスを無くすことも大事だと思う。 ◼Q7. 事業者が基礎データを出すようになれば、行政側で実態を正確に把握できる。 行政はどこまで公共交通をコントロールするべきなのか？ • ➡運輸行政による需給調整が無くなった一方で、自治体の交通計画が権限を持つようになった。電 子申請のデータを自治体とも共有し交通計画に役立てるスキームが、現行の仕組みに則った当面の 進め方だと思う。 ◼Q8. 現制度は需給調整時代の名残なので、引き継がない方が良い。 あるべき姿を考えることが大事。 • ➡将来像の検討が大事なのは同意。ただ、まだ議論も始まっておらず、業務や法規を変えるのには 時間がかかる。将来像検討と同時並行で現行制度をベースにしたプロトタイピングを行っていくの は、今疲弊している事業者を救って余裕を作りたいから。具体的に進めていくことで、検討に フィードバックもできると考えている。
- 59. 質疑記録 60 ◼Q9. 運輸局ではなく本省と話をしてはどうか？ • ➡ぜひそうしていきたい。今回運輸局をヒアリングしたのは、運輸行政の現場で も紙申請の処理に苦慮していて、電子申請が省力化に有効であることを確認し、 意見を収集するため。意見交換は和やかで、省力化による働き方改革の必要性に ついて合意できた。 ◼Q10. スポンサー募集には、費用の規模感を示した方がよいのでは？ • ➡Step.1～3を一気にやって2千万円、1年くらいか？ 実装上は、Step.3の機械 判読データをモデリングし作成した上で、Step.2の集計データ、Step.1の紙とし て出力することになるだろう。予算や期間の範囲内で、できることをしていく進 め方でも良い。 Step.4基準算出の移管は読めないので、検討を進めていきたい。 Step.5高度化の段になれば、基盤データがある上で効果を出していける。 ◼Q11. 次世代モビリティの検討とも関係するか？ • ➡大いに関係する。 MaaSの流れに乗って事業者が運行や運賃を柔軟にしていくの は良いが、全体として破綻しないようにモニタリングしコントロールするには行 政がデータを持つ必要がある。