# GHP2021 東日本技術者A　実践研修記録シート

## リンク集
* 参加者＆チームリスト
* 昨年の事例　[やさしいひなんちず](https://hackmd.io/@hackcamp89/HymKWq4bu)
* GHP2020　技術者　研修記録シート
【東日本】
https://hackmd.io/@hackcamp89/SkqpguoWu
https://hackmd.io/@hackcamp89/Syz3G_oW_
https://hackmd.io/@hackcamp89/ry-pGujZO
https://hackmd.io/@hackcamp89/SkH0MOob_
https://hackmd.io/@hackcamp89/r13Asto-_
【西日本】
https://hackmd.io/@hackcamp89/HkBVq2NzO
https://hackmd.io/@hackcamp89/Bkfpq2EGd
https://hackmd.io/@hackcamp89/SkMAc2VM_
https://hackmd.io/@hackcamp89/BJcSo3Vzd
https://hackmd.io/@hackcamp89/r1Udi2Nfu

* [開発中の記録用HackMD](https://hackmd.io/team/geo-a)
* [GitHub]
## チームメンバー

* 手塚寛さん
* 吉永慧一さん
* 大迫星磨さん
* 馬場英道さん
* 石田都士磨さん

## チームで策定したコミュニケーションルール
属性・地域・年代も異なる多様なメンバーが集まっているとき、どのようなコミュニケーションが心地よいのか・力を発揮できるのか、「ルール」を言葉にしておくと、その後のやりとりの指針になります。
* リアクションは大きく分かりやすく。身振り手振りで。
* チャットでは必ずメンションを付ける。リアクションも欠かさずに。
* 否定しない。
* 間違ってもいいから発言する。
* 深く考え込まずに。積極的に。
* メモを残す。可視化する。
* 結論が出てなくても過程を共有する。
* 最低でも1日1回はSlackを見る。
* できるだけ他者の意見を聞く。
* 打合せ前に議題・ゴールを確認する。
* いつまでに何をするかを明確に。
* アウトプットなどの共有の場をどうするか？
* HackMDに記載していく。

## 1. 取り組む課題
**「住民が被害想定を過小評価して、避難してくれない。」**

## 2. アイデアの公式

*当初作成案*
オープンデータ（統計情報・地形データなど）＿と、利用者ならではの情報（住んでる場所、年齢、今何してるかなど）をかけ合わせて、その人ならではの避難情報を提供するサービス

**決定事項**

**「被害の過小評価により住民が避難してくれない。」という課題を解決するために、
「地理空間情報を活用したデータ抽出技術、およびWebベースの情報提供技術」と
「洪水・統計データ、地形データと個人のデータ」を組み合わせて、
「自宅待機避難をしている住民」に対して、
「その人ならではの避難情報の提供」をして、
「住民が避難をする上で具体的なアクションを取れる」ようになる。**

* サービス提供のレベル
* （最低限実現したい）地理空間情報：位置情報のマッピングにより位置を起点とした避難情報の提供
* （できればさらに実現したい）個人属性を基にしたさらなる避難情報の提示

**検討事項**
誰が使うのか？
* ~~自治体の人など避難を支援する人~~
* 自宅で待機しているような人


### 中間報告までのスケジュール
2/6　20時～　開発する具体的な内容を決める。ファイル共有の確認
　　　リサーチ期間
2/10 20時～　リサーチ結果の共有、実装方針の相談
2/12 中間報告（早い時間希望）
2/15 20時～　開発状況の共有
2/19

## 3. 役割分担
`あなたのチームに必要な役割のみ項目を残して活用してください`

* タイムキーパー（進行管理）：吉永さん
* ドキュメント整備（このHackMDの利用を推奨）：吉永さん
* 発表スライド作成 @tsushimaishida
* 2日目　プレゼンテーション　石田さん
### 開発
FE:フロントエンド
BE:バックエンド
* データ準備 手塚さん
* PLATEAUデータ　【済】
* 避難情報【確認中】
* 気象データの警戒レベル相当情報（Atomフィード）【確認中】
* LINE通知実装 馬場さん
* FE:
* BE:LINEのNotifyAPIをコール
* 現在地取得機能 馬場さん
* FE: GeolocationAPIからユーザーの緯度経度を取得する
* BE: FEから緯度経度を受け取るAPIを作成
* 現在地から`洪水浸水想定区域内`かどうかを判定する機能
* FE:
* BE: 緯度経度を受け取り、空間結合を行うことで該当する地物の属性情報を取得する。 大迫さん
* 入力値：
* 緯度経度
* [リサーチデータ](https://hackmd.io/UOwzA3FYSv2-Oj6OCN-c0A)のデータ
* 出力値：Yes/No
* 現在地から`家屋倒壊等氾濫想定区域`かどうかを判定する機能
* FE:
* BE: 緯度経度を受け取り、空間結合を行うことで該当する地物の属性情報を取得する。 大迫さん
* 入力値：
* 緯度経度
* [リサーチデータ](https://hackmd.io/UOwzA3FYSv2-Oj6OCN-c0A)のデータ
* 出力値：Yes/No
* 現在地からユーザーの住居の建物情報を取得する機能
* FE:
* BE: 緯度経度を受け取り、空間結合を行うことでユーザーが住む建物の属性情報を取得する。 大迫さん
* 入力値：
* 緯度経度
* [リサーチデータ](https://hackmd.io/UOwzA3FYSv2-Oj6OCN-c0A)のデータ
* 出力値：地上階数、計測高さ
* 気象警報(リアルタイム情報) 手塚さん
* BE: 気象情報APIを呼び出し、レベル何相当かを返す
* ユーザーから属性情報の入力を受け取り、避難フローに応じて避難指示を表示する機能　馬場さん
* FE:ユーザーから入力を受け付けるフォームを作成
* BE:ユーザーからの入力データと避難フローから避難指示を返す
* 入力値：
* 家族に避難に時間を要する人がいるかどうか？
* 家屋は想定浸水深より低いか？
* 現在の階は想定浸水深より低いか？
* 備蓄は十分か？
* 気象情報のレベルが3相当なのか4相当なのか？
* 出力値：
* 避難推奨Yes/No
* 避難所の地図表示
* FE:避難所を地図上に表示
* 避難所までの経路表示
* FE:経路のPolylineを表示
* BE:経路探索を実装
* 外部API（Google?）に始点、終点の緯度経度を渡す
* 経路の緯度経度のリストを返却

### その他関連作業
* 画面デザイン 石田さん
* リポジトリ準備　馬場さん

---

## 4. 中間報告
### a. 選択した課題
住民が被害想定を過小評価して、避難してくれない。

### b. 開発進捗概要

「ユーザの位置情報に応じて、具体的な避難指示を提示する。」
2/6　20時～　開発する具体的な内容を決める。ファイル共有の確認
　　　＜リサーチ期間＞
2/10 20時～　リサーチ結果の共有、実装方針の相談
2/12 中間報告（早い時間希望）
　　　＜開発＞
2/15 20時～　開発状況の共有
　　　＜開発＞

### c. チーム運営・コミュニケーションについて
* 最低1日1回はSlackを確認し、情報共有を行う。
* ドキュメント、プログラムの管理は個人の裁量とし、共有方法は都度調整する。
* チーム外に共有する事項は本ページにまとめる。
* その他の情報は外部リンクを本ページに貼る。

### d. 技術について
* バックエンド開発
* 避難判断フローチャートを作成し現在位置の避難レベルを判定するAPI
* CityGMLから建物の階層情報を抽出し、現在位置の建物情報を取得
* 現在位置が洪水浸水想定区域内か判定

* フロントエンド開発
* GeoLocationAPIを利用して、利用者の現在位置を取得
* APIの結果に応じて避難指示を実施
* 避難所を地図表示
* （LINEでの通知）

### e. チームの成長・得られた観点
* 開発者視点のプロセスに関われたこと自体が個人としてよかった
* コミュニケーションに使えるWebサービスが知れてよかった
* 総務省の意図、求める人物像がイメージできた
* 他者の意見も取り入れながら、自分のアイデアが磨かれている感じを受けた
* アイデアを出していく手法（QFT）を体験できてよかった

### f. メンターへの質問（困っていること・ヘルプが欲しいこと）
* すすめていく中で追記

---

## 5. サービス内容

### サービスの名前：「ナラデハ」

### a. ターゲット（主人公）
普段からスマートフォンを利用する人。自宅待機中の利用を想定。
特に平時よりハザードマップを見たり、備蓄を行っていない等、避難行動についてイメージができていない人。

### b. 課題の背景　　
* 災害警報発令時、自宅が実際に対象となるか、どのような影響があるかイメージできていないため、避難アクションが取りにくい。
→警報が発令された際に自宅への影響、取るアクションをユーザに応じて詳細に提供したい。

* 類似事例
* PREP（https://www.service.rcsc.co.jp/prep)
災害情報を届けるだけでなく、災害時の行動を支援するための機能を提供している。ユーザが事前に登録した情報に応じて、避難時のガイダンスなど災害時の行動をサポートする。

### c. 使う技術
* データ整備（Python/GeoPandasなどの空間解析ライブラリ）
* CityGMLから建物情報を抽出し、建物ポリゴンとして保持する。
→位置情報と建物ポリゴンの空間結合を行い、どの建物に属しているかを判定する基礎情報とする
※テキスト解析（citygmlから建物情報や浸水情報の取得）が一番大変でした

* API（GCP/Docker/Github Actions/FastAPI/Python）
* 抽出した建物ポリゴンと洪水予報を元に、位置情報に応じた避難判定を行う。処理フローは以下の通り。

* Web（React/TypeScript/Leaflet/LINE）
* 利用者の情報入力
* 避難所への案内(Directions API)

* API/Webを提供するインフラ
* GCP(Cloud Run, Cloud Storage)
* Docker
* Github Actions

sequenceDiagram
participant user as ユーザ
participant web as ナラデハWeb
participant api as ナラデハAPI
participant server as 通知サーバ
participant service as 外部サービス
    rect rgba(120, 120, 120, 0.2)
        server -->> service: 警報情報取得
        Note right of server: 今回は対象外 
        service ->> server: 
    end
    server ->> user: LINE通知
    user -->> web : Webサイトへアクセス
    web ->> user: 入力画面表示
    user -->> web : 属性入力・位置情報取得
    web -->> api : 位置情報
    Note over api: 現在位置の建物の判定
    Note over api: 家屋流出リスク判定（今回対象外）
    Note over api: 洪水浸水想定区域内判定
    Note over api: 備蓄判定
    api -->> web : 判定結果
    web ->> user: 避難推奨通知
    opt 建物外への避難が必要
        web ->> user : 地図・ルート案内
    end

### d. 使うデータ

* **[川崎市3D都市モデル（Project PLATEAU）](https://www.geospatial.jp/ckan/dataset/plateau-14130-kawasaki-shi-2020)**
* 建物モデル
* 計測高さ
* 地上階数
* 洪水浸水想定区域
* 浸水深
* 浸水ランク
* **指定河川洪水予報（気象庁）**
* **[川崎市避難施設データ](https://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-P20.html)**

### e. サービスの内容・特徴
利用者「ならでは」の避難情報を提供する。

* Webサービス
* 警報発生時、LINEでユーザに通知
* 通知されたURLから現在位置・属性を入力
→今いる建物の高さ（地上階数）・浸水深を元に、パターンに応じた避難通知を行う。
* APIサービス
* 位置情報から建物情報（ポリゴン、高さ、階数）がわかる。将来的には建築年や構造種別なども
* 位置に応じた避難レベルを提供する。

### f. 課題と解決に関わるステークホルダーとその役割

* 外部サービス提供者（気象業務支援センター／気象会社など）
* 警報情報のリアルタイムAPI化と取得方法の確立
※気象庁は無償提供のため、有償でサポートの手厚い事業者にお願いしたい。
* より細かい領域の気象情報を取得・連携
* 自治体
* 警報と合わせてLINE通知を行う仕組みの整備、導入
→自治体のLINEアカウントとの連携や、アナウンス方法など
* 避難情報、避難所開設情報のリアルタイム取得に向けた整備

* サービス提供事業者
* LINEの友達追加キャンペーンなど、ユーザを呼び込むための活動
* サービスと合わせて、避難アクションや備蓄ガイドなど、より防災を意識するための情報提供を実施

### g. サービスによって課題が解決された世界のイメージ
* 住民の逃げ遅れが減少する

### h. そのサービスが実際にターゲット（主人公）に届き活用されるまでのストーリー

ハザードマップや気象情報など、防災は大事だとは聞くが、どういうときに自分が避難すればよいのかは難しいし、忙しい生活の中で考える時間もない。
LINEのキャンペーンにつられて「ナラデハ」を友達追加したが、普段はその存在を忘れていた。
そんなあるとき、大雨により近くの川が氾濫しそうになった。避難情報も出ている。
そうはいっても避難情報は市内のほぼ全域に出ているし、川から離れている私の家は大丈夫だろうとぼんやり思っていた。
だが「ナラデハ」の通知が届き、聞かれたことに答えていくと、危険なので避難したほうがよいという。「ナラデハ」は私の住んでいる建物の高さや現在地も考慮しておすすめしてくれているらしい。そこまで言うならと避難することを決め、「ナラデハ」の案内にしたがって近くの避難所にたどり着くことができた。
その後実際に川が氾濫し、自分の家も水に浸かってしまったが、「ナラデハ」のおかげでなんとか命は守ることができた。

<!-- ※Muralの「アイデアスケッチテンプレート」なども活用しながらイメージしてください
考えるポイント/全てを埋めなくても問題ありません）
サービスのターゲットとする主人公が、
* 災害時にどんな課題を持ち
* どのようにサービスを認知し
* どのような点に魅力を感じ
* どのように使い
* どのように課題が解決されるのか
* そしてそのストーリーに関連するステークホルダーとその役割は？ -->

### i. サービスへのリンクURL（あれば）

https://naradeha.netlify.app/

### j. サービス拡張に向けたアイデア
* 利用結果の活用
* 登録結果の収集→逃げ遅れ発見の参考情報として活用
* 避難所との連携→避難指示判定ユーザの収集→逃げ遅れ管理
* 実際の避難経路の解析→今後の避難経路策定への活用

---

## 6. 振り返り

### a. ユーザーフレンドリーなコミュニケーションデザインの設計について
* 良かったこと
* LINEの採用は良かった。入り口として入りやすい。
* 入力画面は直感的だった。
* 反省点
* 避難有無の判断材料を可視化できるとよりイメージしやすいサービスにできた。
* 収集情報の活用も含めて対象にできるとよかった。

### b. 技術・デザインについて
* 良かったこと
* ルートAPIの規約違反だったけど、半日でできたのは良かった。
* 難易度は高かった。アプリケーションとして実装できた。
* API実装まで想定できたのは良かった。
* LINE Botを自然と採用したけど、独自性があったのは意外。
* バックエンドの処理は言語が揃ってた。チームワークすごい。

* 反省点
* フロントエンド開発にリソースを割ければよかった。分業への落とし込みができなかった。
* 技術選定は検討の余地があった。

### c. 「社会課題に資するG空間人材のあるべき姿」について（作ったサービス・プロセス）
* 「プロトタイピング力が重要」はその通り。
* シビックテックという観点では、ターゲットを広く考えないといけないと感じた。高齢者へのリーチとか。
* 社会課題を解決という点だと、Bチームは実際の事例を題材にしているのは良かった。
* 緊急時に素早く収集、動くものを作るという一連の体験はできた。

### d. 役割分担は適切だったか・他にどんな役割が欲しかったか
* 開発リソースはいくらいても嬉しいので良し悪しはない。
* 分担は悪くなかった。
* マーケティング・サービスを提供するための役割が実際には必要。

### e. どのような知識・スキル・データが欲しかったか
* 国土数値情報に全種類の情報があれば・・・（家屋流出リスクとか）
* 全国的にデータは整備されていてほしい
* 開発したAPIの部分とか、目的に応じてデータを選んだり探したりできるとよかった

### f. 本日の学びや作ったものを今後どのように活かしたいか
* CityGMLは今後も触ろう
* 空間解析は学びたい
* Python→FastAPI（解析ロジックの作成→API化）の流れをやりたい
* 開発をやってみたい

### g. これから地理空間技術を学びたいと思った人に伝えたいことは？
* 地理空間技術＝地図を使う、ではないと気づく良い機会になりました。
* プロダクト開発する上で高度な解析や見せ方も重要だが、それ以上にユーザー側がちゃんと理解できて使えるものか（実用性）を意識すること

###### tags: `GHP2021　技術者　東日本`