# [最終報告用の記述はここのリンクから](#5-サービス内容-最終報告用)

# [俺はソロだ] Tokyo OSS Party!! 2021 記録シート
## チームメンバー

* 坂本 諒太さん

### チームで策定したコミュニケーションルール

* 一人でも寂しくならないようにする
* 一人でもモチベーションを維持する工夫をする
* 一人でも独り言で盛り上げる

## 5. サービス内容 (最終報告用)

### サービスの名前：「Helper Call Platform ~マッスルヘルパー＆ヘルプボタン~」

### ターゲット（主人公）
ペルソナはデバイスごとに用意

#### マッスルヘルパー
年齢：64才
性別：男性
家族構成：一人暮らし
ハンデキャップ：視覚に障害
移動方法：白杖を使った徒歩
生活：
ヘルパーの方が週２~3程度来て家の細かいことはサポートしてもらえる。
物体の認識はできるが視界が霞むため細かいところまで見えない。また死角も多いらしい。
スマートフォンは持っておらずガラケーを所持。
ガラケーの操作は簡易ボタンで家族に電話をかけられるようにしているため複雑なことはできない。
視覚障害の影響もあり、新しいアプリなど慣れないもの細かいものを操作するのはとても難しい。
白杖を使っていると何かと手が塞がることが多い。
買い物：
商品の種類、大きさが判別しにくい。
お店に入っても何かわからなかった際に誰に聞けばいいかわからない。
四方八方からいらっしゃいませの声が聞こえるがどの人が店員であるか確証が持てない。

#### ヘルプボタン
年齢：68才
性別：女性
家族構成：
ハンデキャップ：手足の一部、聴覚に障害
移動方法：電動車椅子
生活：
週2回64才の妹が家の手伝いに来て買い物などもしてくれる。
手足に障害があるが、右手での電動車椅子の操作は可能。
聴覚にも障害があり聞き取りやコミュニケーションに自信があまりない。
理解のない人にサポートお願いするのは少し勇気が必要。
買い物：
高い位置にある商品や低い位置にある商品を取るのが難しい。
声をかけた店員さんの理解がどこまであるか不安なため知っている店員がいる時間しか行けない。

### 課題の背景



### サービスの内容・特徴

サービス名 **Helper Call Platform**

端的に言うと、外出先でも使えるナースコールのようなもの

1. コールをするとその施設の職員へ通知が行き即座に対応
その場にいる職員のため対応のスピード感や安心感がある

2. コール用の入力デバイスを追加可能、世代やハンデキャップの種類に対応可能
現在はボタン、筋電センサーが対応 (後ほど解説！)


### 課題と解決に関わるステークホルダーとその役割
* 介助者や家族： ハンデキャップのある方を日々見守っている方
* ハンデキャップのある方の当日の外出先の内容をHelper Call Platformに入力
* 施設の方： 店員や職員など
* ハンデキャップのある方からの通知でサポートを行いにいく、介助者や家族からの事前入力情報を元に施設内のコールした人を探す

### 使う技術・技術的特徴

#### プラットフォーム側

* Next.js TypeScript(フロントエンド提供)
* Nest.js TypeScript(バックエンド)
* PostgreSQL (データベース)

言語やフレームワーク選定はOSSとしてコントリビュータがコントリビュートしやすい人気の技術を選定しました。
また、今回はOSSとしての公開なので特定のクラウドに依存しないよう(特定のクラウドにロックインしないよう)にマネージドサービスなどはなるべく使わない形にしました。

GraphQLを共通的なインターフェイスとして用意を行いバックエンドはNest.jsでまとめることでBFF(Backends For Frontends)のアーキテクチャを想定しています。
BFFなので今後機能拡張をしていく際にマイクロサービスを接続していく拡張性があります。

技術的な今後の課題として、本来デバイス側からの通信は別口にすべきで軽量なmqttなどのプロトコルを使いたい。
あと別口にした場合、入り口はメッセージングキューなどを配置。

##### プラットフォームで管理されるもの
* スケジュール管理(事前入力行き先管理)
* デバイス管理
* 通知管理

#### デバイス側

* ラズパイ Zero HW
* 筋電センサー
* LEDボタン
* その他電子部品

/devices ディレクトリにあるREADME.mdに記述されている機材を調達し、記述されている回路を組むことで誰でも再現することが可能。
デバイスを追加する際もcall_client.py経由でコールを投げる実装に対応し/devicesに手順を追加すれば可能。

今後の課題としてはCONTRIBUTING.mdを追加したい。
また、LEDボタンは押すと光るため視覚的なフィードバックがあるが、筋電センサーもLEDかバイブレータなどでフィードバックを行う機能を追加したい。

デバイスを実験として使った結果を FEEDBACK.mdに記述して知見を貯めて、みんなでデバイス自体も改善していく仕組み。

#### 通知について
現時点の対応

* LINE Messaging API

構想

* メール送信
* Web hook
* Slack通知
* 電話 Twilio?

### 使うデータ
今回は特に使いませんでした。

### サービスによって課題が解決された世界のイメージ
ハンデキャップがある人々が店員などに訪ねる際に遠慮をしなくなる世界
まずはコミュニケーションの入り口のハードルが下がることでハンデキャップのある方の困りごと時のコミュニケーション回数が増加する。
いきなり全ての課題を解決するのではなく、今回のハードルを下げられたら次にステップに広がられたらいい。

#### OSSの価値 発展サイクル

### そのサービスが実際にターゲット（主人公）に届き活用されるまでのストーリー
考えるポイント/全てを埋めなくても問題ありません）
サービスのターゲットとする主人公が、
(年齢：68才 性別：女性のヘルプボタン利用のペルソナで記述)
* どんな課題を持ち
手足に障害があるが、右手での電動車椅子の操作は可能。
聴覚にも障害があり聞き取りやコミュニケーションに自信があまりない。
理解のない人にサポートお願いするのは少し勇気が必要。
声をかけた店員さんの理解がどこまであるか不安なため知っている店員がいる時間しか行けない。

* どのようにサービスを認知し
市役所から実証実験の案内を知る

* どのような点に魅力を感じ
こちらから声をかけなくても、理解のある相手が初めからサポートをする想定で向かってきてくれる

* どのように使い
外出時はヘルプボタンを持つ。

* どのように課題が解決されるのか
買い物などで店員に声をかける時のコミュニケーションの入り口が楽になる

### サービスへのリンクURL（あれば）
* GitHub: https://github.com/ryo-ma/helper-call-platform
* サービスURL

* マッスルヘルパー 動画： https://drive.google.com/file/d/1i2ajf5pk3Eb6xprwIt5NmbzKxxg44VQ3/view?usp=sharing
**※ 動画ですがちゃんと デバイス -> 認証 -> バックエンド(データベースへ保存) -> LINE APIと動作しています**

* ヘルプボタン 動画： https://drive.google.com/file/d/1Rvc6SA6y_1CigU6NrKNaQSdpqSh1C2N-/view?usp=sharing
**※ 動画ですがちゃんと デバイス -> 認証 -> バックエンド(データベースへ保存) -> LINE APIと動作しています**

* フロント画面

### 実導入の課題感
* 実験フィールドが欲しい
* デバイスを配布する方法は？
* デバイスの軽量化、簡素化
* どこまで協力してくれる施設やお店を広げられるか
* バッテリーなどの運用は？
* ネットワーク通信は？ Wi-Fiかソラコムsimなど？
* 誤操作が発生する可能性 現状だとキャンセルで対応
* 部位や人ごとにチューニングが必要、誤操作のコントロールが難しい(マッスルヘルパー)
* あまり目立たないデザインが必要

###### tags: `TokyoOSSParty2021`