見出し画像

【動画レポ】能登半島地震の支援でBTPアプリを3日で開発したワケ ~震災支援ではじめにデジタルができること〜【SAP Inside Track Tokyo 2024】Week1 | 前夜祭 #sitTokyo​​ #chillSAP ​​#SAPCommunity​​

今回はSAPのユーザーコミュニティであるChillSAPさんの年次イベント「SAP Inside Track Tokyo 2024」のアーカイブ動画「【SAP Inside Track Tokyo 2024】Week1 | 前夜祭」からリアル会場を中心に開催された前夜祭のセッション「能登半島地震の支援でBTPアプリを3日で開発したワケ」を紹介します。

登壇者紹介

Kazuma Asaiさん
SAPジャパン株式会社 Industry Advisory インダストリーアドバイザー

Ryo Asaiさん
Center of Expertise Japan  Engineer

震災におけるSAPの支援

2024.1.1 能登半島地震発生

非常に大きな地震〜インフラに大きな損害 
・42路線84箇所道路が遮断 
・避難者26,036人   孤立集落、勝手避難場所587箇所
・保険・医療・福祉施設786箇所

能登半島地震

避難所情報の問題
自治体が把握できない避難所・施設が1300
必要とする避難者や場所に物資や支援が届かないリスク

避難者の所在に確認
・kintoneにアプリを作成し、自衛隊が回って入力
・DMATの方々が芝浦工業大学と共同で作成した「D24」アプリに情報収集

石川県の総合防災情報システムには指定避難所の情報しかなく突合できない
・物資支援システムに接続されていない

システムからみた課題

石川県が掲げる被災者支援の3ステップ

Step1:場所と人数を特定〜漏れのない「避難所データ」
Step2:支援対象を特定〜避難所に紐づいた「避難者データ」収集
Step3:どこにいてもニーズに応じた支援〜迅速で効果的な支援、罹災証明

SAP対応の経緯
1/7 SAPへの応援要請
Step1:避難所情報
・件のシステム1箇所にデータを集約する方法・・・うまくいかず
・今ある情報を可視化・・・自治体に精査してもらうアプリ(1/13リリース)

SAP対応の経緯

データ上の問題と運用の懸念点

データ上の問題点
・共通IDが存在しない
・システム間の重複データ
・表記漏れ、記載方法の相違
・町名までの表記や座標の差異
・同一住所で建物名称の相違

運用上の問題点
・避難場所長福寺の有効データ選定
・各システムからのID入力
・最終判断者と入力者のプロセス
・市町職員の負荷

対応
・クレンジング処理/データインテリジェンスによるマスタデータ作成
・1つのシステムを正として決定し他システムへの連携基盤
・最終的な判断者は市町職員として当r区する避難所を特定する
・すべての関係者が同じデータ/ツールを利用
・客観的な使いやすさ

SAPが提供する避難所データ可視化プラットフォームの流れ

避難所データ集約可視化アプリの画面
・市町村の一覧から指定
 市町村ごとの避難所の一覧が表示
・直感的でわかりやすく実装(地図の表示など)
・避難所ごとの状況をコントロールできる
・必要な支援物資の情報を入力できる

避難所データ集約可視化アプリの画面

・基本的には市町村のテーブルと避難所のテーブルで構成
・どの地域のどれくらいの品暗所の数、必要情報の不足を明確化
・地図で各システムの登録データの差をわかるように

今回の対応とあるべき対応

あるべき姿
・IDがあらかじめ避難所に割当され、新しく採番される仕組み
・同じアプリケーションを使って関係者が登録をする
⇒災害時にはいろんな緊急対応が走る
 連携してデータを正規化するのが現実的な対応だった

政府への提言
・データの標準化、一元化
・データの連携が直ぐにできるよう

今回の対応とあるべき対応

技術情報

要件の適切な把握
・短時間で必要な機能のみにFixする⇒最小限の労力で最大の効果

技術選定

主な技術要件
・避難所のデータ保管
・データ表示(一覧、避難所地図、支援物資ステータスごとの累計)
・データ操作(支援物資ステータスごとの切り替え)
⇒典型的なビジネスアプリ二要求される要件⇒BTPの採用

基本的なアーキテクチャ
・HANAクラウドをデータソース
・誰もが操作、間違いが許されない⇒UIにUI5、バックエンドにCAPを使用
・HANA Database Explorer   開発をしないで用意した

基本的なアーキテクチャ

技術的な勘所

・ODataのプロトコルをうまく使う
 簡単に実装するための仕組みをそのまま使う
・Fiori Design Guideline出できる範囲のことを要件とする
 できないことをしようとしない
・Multi Target Applicationの仕組みを最大限利用する
 宛先管理などを一箇所にまとめて制御し本番環境にすぐリリース

上記3点を満たすことでビジネスアプリ構築に共通する煩雑な実装を回避して実装に取り組むことが可能

まとめ

・大規模災害発生時にはデジタルは無力だができることはある
・緊急性があるときにこそアジャイルに短期納期を実現できる技術者が必要
・データの一元化、標準化は理想だが緊急な特別対応はいつでも起きる
・適切に要件を固め、技術を選定することでアプリ構築が短い時間で達成
・BTPは今回の要件に非常によく適合した

まとめとメッセージ


この記事が気に入ったらサポートをしてみませんか?