公立はこだて未来大学 2019 年度 システム情報科学実習
グループ報告書
Future University Hakodate 2019 System Information Science PracticeGroup Report

プロジェクト名
ビーコン IoT で函館のまちをハックする -BEACON FUN Revolutions

Project Name
Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

グループ名
ゆまち

Group Name
Yumachi
プロジェクト番号/Project No.

10-C

プロジェクトリーダ/Project Leader
渡邊慎太郎

Shintaro Watanabe

グループリーダ/Group Leader
瀧本恒平

Kohei Takimoto

グループメンバ/Group Member
瀧本恒平

Kohei Takimoto

川谷知寛

Tomohiro Kawatani

石川空人

Takato Ishikawa

指導教員
松原克弥 藤野雄一

鈴木恵二

鈴木昭二

奥野拓

Advisor
Katsuya Matsubara Yuichi Fujino Keiji Suzuki Sho’ji Suzuki Taku Okuno

提出日2020 年 1 月 22 日

Date of Submission
January 22, 2020

概要
本プロジェクトは，ビーコンを函館の街の様々な場所に設置して，新たな体験や魅力を提供す
ることを目的とする．ビーコンを用いることより，函館という地域に付加価値をもたらすことに重点をおいたサービスを提供する．どのようなサービスを提案するかのアイデア出しを行うにあたり，フィールドワークによって函館の街の課題を洗い出した．洗い出した課題をもとに，函館らしさ・ビーコンである理由・新規性・継続したくなる魅力・必要性の 5 つの観点に重点をおいて 7 つのアイデアを創出した．さらに，それらをブラッシュアップすることによって 4
つのサービスを提案するに至った．
（※文責: 渡邊慎太郎）
函館市には，温泉を利用した施設または銭湯が多く存在する．特に，湯の川は全国的に知名度のある温泉地である．温泉という文化が根付いている地域では，観光客だけではなく地域住民
も温泉を利用する．これらの背景を踏まえて，本グループでは，温泉施設の抱える課題をビー
コン IoT を用いて解決することを目指す．従来，夫婦などの異なる性別のメンバを含むグループが温泉施設を訪れた際は，事前に待ち合わせ時間を設定したり，浴場から出る際に大声で呼びかける等の不確実な方法によって施設を出るタイミングを調整する必要があった．そこで本グループでは，自分が浴場にいるときに自分のペアが温泉施設内のどこにいるかを知らせることで待ち合わせを容易にするサービスである「ゆまち」の提案，開発を行った．前期では，「ゆまち」のサービスの概要や機能の詳細を決定した．後期では，ゆまちの開発を行うにあたり，サービスの詳細設計として，要件定義とモックアップの作成を行い，それをもとに UI・UX の作成や実装を行った．プロジェクト成果発表会や HAKODATE アカデミックリンク 2019 では，開発している「ゆまち」のデモに実際に触ってもらうなどして多くのフィードバックを得ることができた．その後，これらのフィードバックをもとに UI・UX の改善を行った．
キーワード

函館，温泉，銭湯，湯の川，IoT，ビーコン，待ち合わせ（※文責: 瀧本恒平）-i-Abstract
In this project, we aim to set up beacons in various places in the city of Hakodate toprovide new experiences and attractions. By using beacons, we will provide services
focused on bringing added value to the area of Hakodate. Before we came up withideas for what kind of service to propose, we identiﬁed issues in the city of Hakodate byﬁeldwork. Based on the issues identiﬁed, 7 ideas were created with emphasis on the ﬁveviewpoints of the likeness of Hakodate, reasons for being beacons, novelty, attractivenessto be continued, and necessity. Furthermore, by brushing seven ideas up, we came topropose four services.
（※文責: 大野和也）

Hakodate has a lot of facilities and public baths using hot spring. Especially, Yunokawa
is one of the most famous town for its hot-spring village in Japan. A place other thanthere, signs of hot springs and public baths are seen in various places in Hakodate. Not
only tourist but also local residents use them in the land where culture of hot spring istaken root in area. Therefore, we aim to solve it using beacon IoT. Conventionally, whena group that includes member of diﬀerent genders, such as couples, they need to meet in
the lobby by specifying a rough time before bathing or call out loud before getting out
from bath. Then, we are going to propose and develop the service named Yumachi thatmakes meeting up easy by notifying the pair location in hot spring facility. In the ﬁrst
semester, we decided the service outline and its function. In the second semester, we
carried out requirement deﬁnition and created mock-up. Next, we implemented device
based on detailed design. We were able to receive a lot of feedback in the HAKODATE
Academic Link by letting people use Yumachi Demo under development. We improved
UI・UX based on that feedback.
Keyword

Hakodate, hot spring, public baths, Yunokawa, IoT，beacon，meeting up（※文責: 川谷知寛）- ii -

目次
第1章

本プロジェクトの活動と目的

1

1.1

背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.3

ビーコンについて1

第2章. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

グループ課題設定までのプロセス

2

2.1

プロセス概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.2

フィールドワーク. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.2.1

事前調査 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.2.2

フィールドワークレクチャー . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.2.3

実地調査 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2.4

振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

サービスの考案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.3.1

BS (ブレーンストーミング) と KJ 法によるアイデア出し . . . . . . . . . .

3

2.3.2

OST

(オープンスペーステクノロジー) によるアイデアの深掘り . . . . .

4

2.3.3

アイデアのブラッシュアップ . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3.4

新技術開発サロンとの情報交換会 . . . . . . . . . . . . . . . . . . . . . . .

4

2.3.5

テーマ決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

その他 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.4.1

ロゴ作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.4.2

ビーコンについての事前調査 . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.4.3

Git/GitHub ワークショップ . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.4.4

昨年度のサービスの説明

9

2.3

2.4

第3章

. . . . . . . . . . . . . . . . . . . . . . . . . . .

提案するサービスについて

10

3.1

背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.2

目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.3

本サービスの概要. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.4

要件定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.5

機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.5.1

チュートリアル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.5.2

性別選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.5.3

ペア登録機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.5.4

鍵登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.5.5

混雑状況確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

第4章

4.1

開発

16

技術習得 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16- iii -

4.2

第5章

4.1.1

環境準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

4.1.2

各メンバーに課した課題. . . . . . . . . . . . . . . . . . . . . . . . . . .

17

開発手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

4.2.1

導入した手法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

4.2.2

開発の流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

4.2.3

効果, 課題, 解決策 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19システム仕様21

5.1

システム構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

5.2

モバイルアプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

5.2.1

導入ライブラリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

5.2.2

ペア登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

5.2.3

ビーコン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

サーバサイドアプリケーション . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

5.3.1

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

5.3.2

エンドポイントの詳細 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

5.3.3

データベース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

5.4.1

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

5.4.2

ビーコン受信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

5.4.3

サーバサイドとの連携 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

5.4.4

マーク出力 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

デザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

5.5.1

アプリアイコン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

5.5.2

アプリデザイン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

5.5.3

ペアのマーク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26インフラ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

外部評価

27

中間発表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

6.1.1

発表形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

6.1.2

レビュー内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

6.2

公立はこだて未来大学オープンキャンパス . . . . . . . . . . . . . . . . . . . . .

28

6.3

HAKODATE アカデミックリンク 2019 . . . . . . . . . . . . . . . . . . . . . . .

28

6.3.1

評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

6.3.2

評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

成果発表会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

6.4.1

発表形式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

6.4.2

発表技術の評価と反省 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

6.4.3

発表内容の評価と反省 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

enPiT ByzSysD 北海道・東北グループ合同発表会 . . . . . . . . . . . . . . . . .

30

各メンバーの振り返り

32

5.3

5.4

5.5

5.6
第6章

6.1

6.4

6.5
第7章

- iv -

7.1

役割分担 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

7.2

瀧本恒平の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

7.3

川谷知寛の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

7.4

石川空人の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

まとめと展望35

8.1

前期の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

8.2

後期の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

8.3

今後の展望 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

付録 A

中間報告会で使用したプロジェクト概要のポスター

37

付録 B

中間報告会で使用した本グループのポスター

38

付録 C

成果発表会で使用したプロジェクト概要のポスター 1

39

付録 D

成果発表会で使用したプロジェクト概要のポスター 2

40

付録 E

成果発表会で使用した本グループのポスター

41

第8章

参考文献

42

-v-

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

第 1 章 本プロジェクトの活動と目的
1.1

背景

近年，IoT (Internet of Things) の拡大に合わせて，省電力無線通信である BLE (Bluetooth

Low Energy) の利用が拡大している [1]．この BLE を利用したデバイスの 1 つに BLE ビーコンが存在する．BLE ビーコンは，BLE 対応デバイスを所持していれば誰でも利用可能であるため，今後，ビーコンを活用したサービスの増加が期待できる．
（※文責: 瀧本恒平）

1.2

目的

本プロジェクトの目的は，ビーコンを使用して函館の街に新しい価値を創造することである．
ビーコン IoT を用いたサービスの考案・開発・評価実験を行う．
（※文責: 瀧本恒平）

1.3

ビーコンについてビーコンとは，電波を発して，それを受け取ることのできる機器で受信することにより，位置をはじめとした情報を伝達するための機器である．このビーコンの 1 つに，BLE を用いて位置や情報を発信する機器がある．これを BLE ビーコンと呼ぶ．ビーコンは，省電力・低コストで動作し，ビーコンの電波を受信する機器は，ビーコンそれぞれが所持する固有 ID や電波強度を取得することが可能である．また，BLE ビーコンにはいくつかの規格があり，規格によって付加される情報が異なる．例えば，現在普及しているビーコンの規格として，「iBeacon」・「Eddystone」
・「LINE

Beacon」等がある．iBeacon は，固有 ID の送信や，距離測定，領域入出監視を行うことができる．Eddystone は，iBeacon でできることに加えて，URL の送信や，ビーコンのバッテリ電圧や温度等のデバイス自体が所持している情報を送信することができる．LINE Beacon は，BLE と

iBeacon に対応し，LINE Beacon パケットをアドバタイズできるビーコン端末であり，コミュニケーションツールとして広く認知・活用されている「LINE」を通じて，広告やプッシュ通知を送信することができる．
（※文責: 瀧本恒平）

Group Report of 2019 SISP

-1-Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

第2章
2.1

グループ課題設定までのプロセス

プロセス概要本プロジェクトのグループ課題設定までのプロセスは，大きく 2 つに分かれる．1 つ目は，フィールドワークに関わるプロセスである．実際に函館市内を見て回り，本プロジェクトで開発するサービスを考えるきっかけを探した．2 つ目は，サービスの考案に関わるプロセスである．フィールド
ワークや自身の体験を元に，アイデアを考えた．考えたアイデアについて，函館の地元企業の方，Tangerine 社，トランスコスモス社，担当教員，プロジェクトメンバーや OB・OG などに向けて，プレゼンを行った．そこで得られたのコメントを自身のアイデアの改善の参考にした．その他にも，プロジェクトのロゴ制作や，開発に必要となる Git/GitHub のワークショップや，OB・OGからの昨年度のサービスの説明などが挙げられる．ここからは，フィールドワーク，サービスの考案，その他の 3 つに分けて，詳細を説明する．
（※文責: 吉川綾乃）

2.2

フィールドワーク

2.2.1

事前調査

函館における課題を調査するためにフィールドワークを計画した．まず，調査内容と調査地区をKJ 法によるアイデア出しによるによって挙げた．次に，挙げられたものから五稜郭地区・赤川地
区・湯の川地区・西部地区についてフィールドワークを実施すると決定した．決定した調査地区を対して，五稜郭地区・赤川地区を担当するグループ，湯の川地区を担当するグループ，西部地区を担当するグループを決定し，それぞれのグループでおおまかな調査内容を決定した．
（※文責: 斉藤由樹）

2.2.2

フィールドワークレクチャー

フィールドワークの実施にあたり，5 月 10 日 (金)4 限の時間にて南部美砂子先生よりフィール
ドワークについてレクチャーを受けた．レクチャーでは，フィールドワークをする上での心得として単に見たものや聞いたものをメモするだけではなく，情報の検索，処理，相対化，生産，展開の 5
つの手続きを意識することが大切だと学んだ．また，本プロジェクトにおけるフィールドワークのアプローチとしては，問題そのものを探索する問題発見型であることを認識した．フィールドワー
カーは訪問先にとってあくまで邪魔者であるので，謙虚さ，誠実さ，感謝を忘れないことが重要であるということを学んだ．
（※文責: 川谷知寛）

Group Report of 2019 SISP

-2-Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

2.2.3

実地調査

実地調査は，2.2.1 節で述べた地区を 3 日の日程で実施した．五稜郭地区は，五稜郭公園，五稜
郭タワー，シエスタ・ハコダテ，五稜郭交差点地下横断歩道，市電，千代台公園へ調査を行った．
赤川地区は，四季の杜公園，笹流ダムへ調査を行った．湯の川地区は，湯倉神社，足湯，熱帯植物園，コーヒールームきくち，市民の森トラピスチヌ修道院，函館牛乳あいす 118，函館空港へ調査を行った．西部地区は，緑の島，北方民族資料館，八幡坂，元町公園，旧函館区公会堂，中華会館，
旧イギリス領事館，赤レンガ倉庫，西埠頭，函館どつく，函館山，立待岬，函館公園へ調査を行った．実地調査中は，普段からある当たり前なことに疑問を持ち，細かなことにも注目して課題を発見することを心がけた．調査の記録や情報の共有には Slack を用いた．訪れた地区ごとのチャンネ
ルを作成し，気づいたことや写真などを共有した．Slack での発言はどんな些細なことでもすることとし，より多くの情報を得られるようにした．
（※文責: 石川空人）

2.2.4

振り返り

調査の結果の共有を行うため，各々がフィールドワーク中に気付いた点を付箋に書き出し，模造
紙に貼り付けた．その後，出た意見について KJ 法を使用してグループ分けを行い，そのグループ間の関連性を，矢印と理由で具体的に書き出した．書き出した気付きとその関連性のグラフ図を，
その後のアイデア出しの材料とした． 5 月 22 日 (水) には，2.2.3 節で記載した 8 箇所を訪れた．
調査の結果，平日の昼間の市電は高齢者の乗車が多かったこと，本町という括りの中でも，場所によって人の多さがかなり異なっていたことに気付いた．各班滞りなくフィールドワークを進め，気付きをアウトプットする時間もしっかりと確保することが出来た．5 月 25 日 (土) には，2.2.3 節で記載した 7 箇所を訪れた．調査の結果，温泉や足湯が多くあること，教会や神社等の趣のある建造物の存在を確認できた．5 月 26 日 (日) には，2.2.3 節で記載した 13 箇所を訪れた．調査の結果，函館に縁のある作家の存在や，函館山登山道を通る人達のコミュニケーションがあることを確認した．全体を通して多くの気付きがあり，函館というまちについて改めて知ることができた．
（※文責: 松山穂乃夏）

2.3

サービスの考案

2.3.1

BS (ブレーンストーミング) と KJ 法によるアイデア出しフィールドワーク後のブレーンストーミングを踏まえて，BS と KJ 法によるアイデア出しを行った．BS とは思いつく限りの多くの量のアイデアを出すことで，KJ 法とはそれらを付箋等にア
ウトプットして得られたアイデアを整序し，グルーピングを行う方法である．今回は，3 人を 1 組とするグループを 7 つ作り，各グループ内で 15 分間アイデア出しのブレーンストーミングと KJ法によるアイデアのグルーピングを行い，その後の 10 分間で他のグループのアイデアをレビューした．アウトプットの方法としては，7 つのグループに模造紙を 1 枚ずつ配布し，アイデアを付箋に書いて貼り付けるかたちで行った．

Group Report of 2019 SISP

-3-Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life（※文責: 熊谷峻）

2.3.2

OST

(オープンスペーステクノロジー) によるアイデアの深掘り

BS と KJ 法によるアイデア出しを行った後に，各プロジェクトメンバが興味のあるアイデアについて深めるために OST を行った．OST とは各々が関心を持ったテーマについて考え，より深い意見にするための方法である．時間を区切ることはせず，各々が関心を持ったアイデアについて
考え，考え終わったら他のアイデアに移り各アイデアについて考えを深めていった．OST の結果，一人一人が好きなアイデアを自由に話し合うことができた．しかし，OST の短所として，話し合うことができるほどの人数が集まらなかったアイデアが自然消滅してしまうことがあったため，ほかの方法でのアイデア出しも必要であると感じた．最終的に，OST によって深められたアイデアを話し合いや投票によって 7 つに絞り込むことができた．
（※文責: 熊谷峻）

2.3.3

アイデアのブラッシュアップ

アイデア出しの後いくつかのプレゼンテーションや評価を行い，5 つのアイデアに絞った．またそれぞれのアイデアに興味のあるプロジェクトメンバーを偏りの少なくなるよう振り分け，各グ
ループの詳細なサービス案についてブラッシュアップを行った．教員や学生間でのレビューを行いつつスライドに内容をまとめ，プロジェクトメンバー内でプレゼンテーションを行った．評価の方法として各アイデアに対して「函館らしさ」「ビーコンらしさ」「新規性」「継続性」「必要性」の観点について意見出しを行い，アイデアをさらに絞った，最終的なアイデアは 2 つでそれらの改善を行った．
（※文責: 海老原天紀）

2.3.4

新技術開発サロンとの情報交換会

6 月 19 日（水）に函館周辺地域の企業の方々が開催する，新技術開発サロンとの情報交換会に他
プロジェクトとともに参加した．まず参加企業の会社概要と事業内容の説明を受けた．ソフトウェ
ア開発を行う会社から造船業まで幅広い会社の話を聞くことができる貴重な機会であり有意義であった．次に，プロジェクト内で考えたアイデアの発表・質疑応答を行った．発表ではビーコンプ
ロジェクトの概要やビーコンの説明，実現するもの，利用例を紹介した．その後今年度の活動予定と，発表時点で構想段階であった 2 つのアイデアである，ぷれいるーむと函ライブについて発表を行った．すべての発表が終わった後，アイデアに関する質疑応答の時間を設けた．この中で，参加企業の方々から様々な質問や意見を頂くことが出来た．発表会自体は成功に収まったが，アイデアの決定にかなりの時間を要するなど．準備に大変手間取った．このため，発表会で十分な情報を提示することが出来ず，適切な意見をもらうことが出来なかった可能性があると考えている．これを踏まえ，これ以降の活動では意思決定をすばやく行うことを心がけるようにした．
（※文責: 工藤大山）Group Report of 2019 SISP

-4-Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

2.3.5

テーマ決定

新技術開発サロンとの情報交換会を終えて，新たにアイデア出しを行った．その後，担当教員，

TA，函館市職員，Tangerine 社，トランスコスモス社の方々に参加してもらい，アイデアコンテストを行った．アイデアコンテストでは「みみうち」「ゆまち」「山で仏に会ったよう」「Mystery

Films」「函ライブ」「ぷれいるーむ」「去りし想ひを乗せゆきて」の 7 個のアイデアをプレゼン，採点を行った．裏メニューの情報を提供するサービスである「みみうち」．温泉での待ち合わせを円滑に行うサービスである「ゆまち」．函館山の地蔵から情報を受け取るサービスである「山で仏に会ったよう」．函館市電の歴史を舞台とした脱出ゲーム「Mystery Films」．病院での複数人でのコ
ミュニケーションを可能とする「ぷれいるーむ」．市電で共同で短歌を詠む「去りし想ひを乗せゆきて」．各アイデアの採点には，「函館らしさ」「ビーコンらしさ」「新規性」「継続性」「必要性」の

5 つの観点で 0∼5 点の 6 段階評価を行った．採点の結果は表 2.1 に示す．アイデアコンテストでの意見としては，以下が挙げられる．

• みみうち：裏メニューのためにアプリを入れたくなるのか疑問に思いました．ユーザが使いたくなるモチベーションがもう少し欲しいです．

• ゆまち：まずは待ち合わせに特化して具体的に必要な技術を調べてみて．
• 山で仏に会ったよう：案としては面白いが，あまり地蔵をピックアップしている意味がない
ように感じました．地蔵はあくまで，道筋の指標にしかならないのかなと感じました．

• Mystery Films：ゲームのコンテンツ内容がサービスの鍵になると思います．
• 函ライブ：個人的には面白そうだっと思うのですが，一般的にはイメージしにくいので，やってみなければわからないタイプのアイデアだと思います．路上ライブの土壌をサイレン
トライブで作るってのは面白いと思います．このサービスを使ってくれる人とやりたい人の両方が揃ったら行ってみてほしいですね．

• ぷれいるーむ：ビーコンが必要ないというかビーコンではできないアイデアだと思います．
内容や対象自体は非常に悪くないと思います．

• 去りし想ひを乗せゆきて：アイデアはとても面白いので，ビーコンである意味をもう少し推せると良いと思った．
その後，アイデアコンテストでの意見を踏まえて，各アイデアでブラッシュアップを行った．その後，自分たちがどのアイデアの開発に携わりたいかという観点で投票を行い，「みみうち」「ゆまち」「函ライブ」「去りし想ひを乗せゆきて」の 4 個のアイデアを今年度のプロジェクト学習で開発することを決定した．
（※文責: 吉川綾乃）

Group Report of 2019 SISP

-5-Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
表 2.1 各アイデアの評価の平均

アイデア名

函館らしさ

ビーコンらしさ

新規性

継続性

必要性

みみうち

2.6

3.0

3.3

3.3

2.7

ゆまち

3.3

3.6

4.0

3.2

3.3

山で仏に会ったよう

2.9

2.8

3.1

2.0

2.1

Mystery Films

3.4

3.2

2.9

2.8

2.3

函ライブ

2.2

3.5

3.0

2.3

2.3

ぷれいるーむ

1.9

1.9

3.3

3.0

3.1

去りし想ひを乗せゆきて

3.6

3.3

3.0

3.6

3.0

2.4

その他

2.4.1

ロゴ作成

本プロジェクトでは，プロジェクトの特徴，目標，活動，呼び名などプロジェクトのアイデンティティについてチームで考え，今年度のプロジェクトを印象付けるロゴの製作を行った．ロゴ製作については，2 ヶ月の時間を要した．初めに，各自で 1 案以上のロゴ案を持ち寄り，ロゴ検討会を行った．ここでは，それぞれのロゴ案に対し，良いと思った点だけを述べていくレビューを行った．レビューと他のメンバーのデザインも参考にして，各自でロゴの改善を行い，今度は改善点の指摘を含めた 2 回目のレビューを行った．その後，改善した 17 デザインを，投票により 7 つのデザインに絞り込んだ．(図 2.1，図 2.2，図 2.3，図 2.4，図 2.5，図 2.6，図 2.7)．7 つのデザインそれぞれのコンセプトを把握し指導教員からのコメントも頂いた上で，2 度目の投票を行い，2 つのデザインに絞り込んだ．さらに改善を行い，函館らしさ，ビーコンらしさも考慮した上でメンバーと OB，OG，指導教員も加えた 3 度目の投票を行い，ロゴ原案を決定した．その後，ロゴのワー
キンググループを結成し，デザイン原案の改善を行った．最後に，ロゴデザインの最終版とロゴ使用に関するガイドライン (図 2.8)，それを用いたポスターのテンプレート (図 2.9) を作成した．

図 2.2

図 2.1 ロゴ案 1

Group Report of 2019 SISP

-6-

ロゴ案 2

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

図 2.3

ロゴ案 3

図 2.5

ロゴ案 5

図 2.4 ロゴ案 4

図 2.6 ロゴ案 6

図 2.7

ロゴ案 7

Group Report of 2019 SISP

-7-Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

図 2.8 ロゴガイドライン

図 2.9 ポスターテンプレート（※文責: 新田野乃華）

2.4.2

ビーコンについての事前調査

本プロジェクトでビーコンを使用するにあたり，ビーコンに関する知識を深く知るために，各自
ビーコンについて調べた．さらに，5 人 1 グループを 3 グループ作り，それぞれのグループでビーコンに関するスライドを作成し，全員の前で発表した．各グループのスライド発表を聞くことで，ビーコンの基本情報やビーコンの特徴，ビーコンを使用している既存サービス，ビーコンの利用場
所，ビーコンの課題等を知ることができた．ビーコンの課題として，専用のアプリをインストール
しないと機能しないことやユーザー側は電波を受信するために Bluetooth 機能をオンにしなければいけないこと，受信する端末の機種依存してしまうこと，仕切り・パソコンのディスプレイ等の遮蔽物や反射物で電波が遮られること，通知が煩わしいこと，盗難リスクがあることが挙げられた．ビーコンについて事前調査することにより，その後のアイデア出しではユーザー目線のアイデ
アやビーコンの特徴を活かしたアイデアを出すことができた．
（※文責: 石倉愛朗）

2.4.3

Git/GitHub ワークショップバージョン管理システムである Git と，Git ホスティングサービスである GitHub を用いたシス
テム開発・管理手法を本プロジェクトの TA から学んだ．まず，Git/GitHub とはどのようなサービスなのか説明があり，各 PC に Git のインストールを行った．続いて，GitHub のアカウント登録，Git で管理するディレクトリ・ファイルの作成，Git の初期設定，ブランチの作成，ブランチのチェックアウト，コメント付きでのコミット，プッシュ，プルリクエストの一連の流れを実行しGroup Report of 2019 SISP

-8-Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
た．また，敢えてコンフリクトを起こすことでコンフリクトの修正方法や，新しいブランチを作成する際の良いブランチ名を学んだ．さらに，プロジェクトのアジェンダや議事録を GitHub のリポ
ジトリを作成し，issue を立てることで，Markdown 形式の記法を学び，GitHub の機能をより深く知ることができた．
（※文責: 石倉愛朗）

2.4.4

昨年度のサービスの説明

今年度のプロジェクトでは，どのようなサービスを開発していくか，アイデア出しで出た案を選ぶ際の判断材料に利用するために昨年度のサービスの説明を受けた．昨年度のサービスの代表者に「＠ハナセル」，「becoma」，「いさりび Graﬃti」，「Telepath」の 4 つのサービスについて説明してもらった．「＠ハナセル」は銅像を介して歴史的な偉人と会話できる新体験を提供できるサービスである．「becoma」はビーコンを活用し近くの人とマッチングを行い物を手放したい人と欲
しい人をつなげるサービスである．「いさりび Graﬃti」はビーコンを利用し列車自体をノートとしてメッセージや写真を投稿でき，列車毎の思い出ノートをみんなで作り上げるサービスである．
「Telepath」は講義中や会議中で立場や周りが静かな時に気軽に質問できるサービスである．サービスの説明に加えて昨年度のアイデア決めをどのように行ったかなども説明を受けた．説明を受けたことで「いさりび Graﬃti」のような，函館市内にビーコンを設置しサービスを運用した地域密
着型のアイデアが出やすくなった．したがってプロジェクトのテーマに沿った評価の高いアイデアを選出することにつながった．
（※文責: 根元隆成）

Group Report of 2019 SISP

-9-Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

第3章
3.1

提案するサービスについて背景

函館には中央部温泉群，横津山系温泉群，銭亀沢火山温泉群の計 3 つの温泉群が存在する [1]. また，それらの温泉を利用した，計 69 箇所の公衆温泉施設がある [1]．公衆温泉施設は，湯の川などの温泉街だけではなく住宅街にも作られている．したがって，函館は観光客・地元住民の両方にとって温泉を楽しみやすい街であると言える．一般的に公衆温泉施設は男湯・女湯に分かれている．そのため，男女のぺアや家族連れで利用する際は，あらかじめ待ち合わせる時間を決めておか
なくてはならない．しかし，それぞれの公衆温泉施設によって，施設や広さなどが異なるため，入浴後に待ち合わせる時間をあらかじめ決めることは困難である．また，待ち合わせの時間をあらかじめ決めることによって，時間に注意しながら入浴しなければいけなくなる．その行為は，入浴から得られるリラックス効果を妨げる要因になりかねない．これらを踏まえ入浴前ではなく入浴後に，ペアと待ち合わせるタイミングを決められるサービスを考案する必要があると考えた．そこで，スマートフォンを持ち込めない公衆浴場内で相手の居場所を知ることで待ち合わせを容易にする，といったサービスを開発するに至った. 当初は位置情報を得るための手段として GPS を用いることを検討した．しかし，GPS は屋内では電波が遮られてしまい，また公衆浴所にはスマートフォンを持ち込むことができないため本サービスに適用するには至らなかった. そこで，公衆浴場
内に持ち込むことが可能であり，屋内での位置情報特定に優れるビーコンを採用した.
（※文責: 石川空人）

3.2

目的

本グループの目的は，公衆温泉施設において，入浴後待ち合わせ時間をあらかじめ決めなくてもペアと待ち合わせることを可能にするサービス「ゆまち」の提案・開発をすることである. それを達成することにより，時間に注意することなくリラックスして入浴を楽しめることが期待される.
（※文責: 石川空人）

3.3

本サービスの概要

本サービスのメインターゲットは，温泉を訪れた男女を含むグループである. 背景で挙げた課題を解決するために，ターゲットが温泉で待ち合わせを円滑に行うことができるようなサービスにする. そのため，待ち合わせの前に行う手間をなるべく省くことにする. まず，脱衣所の鍵にビーコンを設置し，大浴場内にはビーコンを受信するデバイスを設置していることを前提とする. 具体的なサービス内容としては，大浴場内からペアの居場所を大まかに把握することで，脱衣所に向かう
時間を自発的に揃えることを前提としているサービスである. そのため，ユーザ側が行う手間といえば，事前にアプリをインストールし，ペアとのペアリングを済ませるのみである. よって，ユー
ザはペアをロビーで長々と待つこともなく，湯冷めの心配もない. また，ビーコンの電波の受信状

Group Report of 2019 SISP

- 10 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
況を外部に送信することで，大浴場内の混雑状況についても把握できる.
（※文責: 瀧本恒平）

要件定義

3.4

本サービスは，公衆温泉施設内での待ち合わせに特化したサービスであり，これによってリラッ
クスした入浴を促すためのものである．これを踏まえて定義された要件を以下に示す．

• ペア登録の手順とサービスの流れについて表示
本サービスを利用するためにはいくつかの手順を踏む必要があるため，どのような流れで利用するかを図とそれを補助する文でわかりやすく示すこと．

• ユーザの性別を把握
本サービスは，基本的に男女間での待ち合わせを想定しているため，ペア登録を行う前にユーザの性別を事前に把握し，管理することが必要となる．ユーザへの負荷を軽減するために，簡単な操作かつ適切なタイミングでユーザの性別を把握できるようにすること．

• ペアの認識と保存
本サービスは，自分とこれから待ち合わせを行うペアが誰なのかをアプリケーションを通して把握し，管理する必要がある．これは，浴場内に設置されたモニターを用いてリアルタイ
ムでペアの居場所を可視化するためである．ユーザへの負荷を軽減するために，操作回数は少なめに，なおかつ理解しやすい登録の手順にすること．

• ユーザが浴場内に持ち込む BLE ビーコンの把握
一般に，公衆浴場内にスマートフォンを持ち込むことは不可能である．そのため，本サービ
スでは，脱衣所のロッカーの鍵とそれに付属するビーコンを持ち込むことでペアの居場所を可視化している．これは，どのビーコンを所持しているユーザが誰とペアなのかを認識することが必要となる．この操作はペア登録を行ったのちに脱衣所で各ユーザが行う操作である．脱衣所内で長時間スマートフォンを操作する行為は望ましくないため，短時間かつ少ない操作で実現すること．

• 温泉浴場内の混雑状況の把握
本サービスは，公衆浴場施設での待ち合わせを補助するだけでなく，リラックスした入浴を促すことも目的としている．そのため，施設外部から温泉浴場内の混雑状況を可視化することで，さらに快適な入浴を行うことができることが期待される．これを実現するために，男
女別に浴場内のビーコンの数を受け取り，リアルタイムの混雑状況を表示すること．
（※文責: 瀧本恒平）

3.5

機能

3.5.1

チュートリアルアプリケーションの初回起動時に，チュートリアル画面 (図 3.1) を表示する．チュートリアル画
面では，ペア登録の手順や，浴場に入ってからの流れを知ることができる．
（※文責: 川谷知寛）

Group Report of 2019 SISP

- 11 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

図 3.1

3.5.2

チュートリアル画面

性別選択

アプリケーションの初回起動時に，性別選択画面を表示する．男女どちらかの性別を選んだ際にサーバーに情報が送られ，性別情報とアプリ ID がデータベースに格納される．その後，アプリはメニュー画面に遷移する．
（※文責: 川谷知寛）

3.5.3

ペア登録機能ユーザがペアを登録するために利用する．認証番号の取得と入力という 2 つの機能 (図 3.2, 図3.3) がある．認証番号の取得は，ボタンを押すとランダムに生成される 4 桁の認証番号を取得し表示する．次にペアが取得した認証番号を入力する．入力した認証番号がペアの取得した認証番号と正しいときは，「ペア登録が完了しました」というダイアログが出る．反対に，認証番号が正しくない時は「無効な認証番号です」というダイアログが出る．

Group Report of 2019 SISP

- 12 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

図 3.3 認証番号入力画面

図 3.2 認証番号表示画面（※文責: 川谷知寛）

3.5.4

鍵登録

ペア登録が済んでから，男女お互いに脱衣所に向かったあと使用する (図 3.4)．鍵を登録することによって，鍵を身につけて浴場に行くだけで相手に自分の居場所を伝えることができる．脱衣所のロッカーの鍵についている MAMORIO というビーコンにスマホを近づけて，鍵を登録する．
またこの時，使用するデバイスで位置情報の使用許可がされていない場合にのみ，許可をしてもら
うためのダイアログが出る．ビーコンを検知するまでは，検索中の文字と同時にローディングアニ
メーションをモーダルで表示している．検知完了後は，画面遷移し，ペアのマークが表示されるよ
うになっている．また，この画面 (図 3.5) では, マークの色の変化による相手の状況の確認方法のチュートリアルも同時に表示される．

Group Report of 2019 SISP

- 13 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

図 3.4 鍵登録画面

図 3.5 マーク表示画面（※文責: 川谷知寛）

3.5.5

混雑状況確認

浴場内にあるビーコンの数から，混雑状況を取得してその混み具合を表示する (図 3.6)．混み具
合を表す度合いとして，「空いています」・「やや空いています」・「やや混んでいます」・「混んでいます」の 4 段階を用意した．アプリ画面では，男湯と女湯の両方の混み具合を表示しているが，現在は設計上，男湯の混み具合しか変化しないようになっている．

Group Report of 2019 SISP

- 14 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

図 3.6 混雑状況表示画面（※文責: 川谷知寛）

Group Report of 2019 SISP

- 15 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

第4章

開発

4.1

技術習得

4.1.1

環境準備

4.1.1.1

Slack

プロジェクトに関する連絡ツールとして Slack を利用した．開発チームごとのチャンネルや，使用するプログラミング言語ごとのチャンネルなどを作成し，チーム内外で，連絡や情報共有を行った．また，ファイルの共有や GitHub などの Web アプリケーションとの連携も行った．
（※文責: 石川空人）

4.1.1.2

Git

ソースコードのバージョン管理ツールとして Git を用いた．Git とは，分散型のバージョン管理
ツールである．Git を使用することによって，編集したファイルを元の状態に戻すことや，編集した履歴を残し，確認することが容易にできる．また，branch という機能を使うことにより，編集履歴を分岐させ，元の分岐した branch の影響を受けずにファイルを編集することが可能になる．
これにより，複数のファイルの編集を同時に行うことができる．
（※文責: 石川空人）

4.1.1.3

GitHub

GitHub とは，リモートリポジトリを共有するクラウドサービスである．これを使うことによって，メンバー間でソースコードやファイルを共有しながらの開発，またソースコードの相互レ
ビューを行うことが容易になる．本サービスでは、フロントエンド用，バックエンド用，Raspberry

Pi 用の 3 つのレポジトリを作成し，開発をした．
（※文責: 石川空人）

4.1.1.4

Adobe XD

モバイルアプリケーションのプロトタイプを作成するために，Adobe XD を用いた．Adobe XD
では，UI パーツなどが無償で提供されているなどと学習コストが低いことや，作成したプロトタ
イプを容易に実機で動作させられるなどといった利点がある．プロトタイプ作成ツールは様々ある
が，上記のような利点を踏まえて Adobe XD を採用した．
（※文責: 石川空人）

Group Report of 2019 SISP

- 16 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life4.1.1.5

Xcode

本サービスのうち，iOS アプリーケーションの開発プラットフォームに Xcode を使用した．

Xcode とは Apple 社が提供する統合開発環境である．本サービスの開発では，開発言語に React
Native を使用して，iOS と Android の両方のアプリケーションを，同一の言語で開発した．Xcodeは，React Native を使用した開発を行うにあたって，iOS 側の標準プラットフォームであった．
このことから，iOS アプリケーション開発に Xcode を使用した．使用したバージョンは 11.1 であった．
（※文責: 石川空人）

4.1.1.6

Android Studio

本サービスのうち，Android アプリケーション開発のプラットフォームに Android Studio を使用した．Android Studio とは，Google 社が提供する統合開発環境である．4.1.1.5 で述べたように，本サービスは iOS と Android の両方のアプリケーションを React Native を使用して開発した．Android Studio は，React Native を使用するにあたって，Android 側の標準プラットフォー
ムであった．このことから，Android アプリケーション開発に Android Studio を使用した．使用したバージョンは 3.5 であった．
（※文責: 石川空人）

4.1.2

各メンバーに課した課題

後期に開発を開始するにあたって，夏期休暇中に各メンバーに課題を課し，開発に必要な技術の習得や，開発を始めるための準備を行った. 各メンバーに課した課題は以下に示す.
瀧本恒平• Golang の公式ドキュメントの翻訳ページに存在するチュートリアルを通して Golang の基
本的な文法について学ぶ.

• オンラインプログラミング学習サービスである「Progate」で Golang で実装できる一部の機能について学ぶ• SQL の文法を確認する
石川空人•『やさしくはじめるラズベリーパイ』を用いて基本的な Raspberry Pi の操作に慣れる.
• Adobe XD の使用方法を学ぶ• サービスのモックアップを作成する
川谷知寛• React Native で BLE 通信が可能かどうかについて調べる• iOS，Android の両方の環境構築を完了させる• Xcode の使用方法を学ぶ
Group Report of 2019 SISP

- 17 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life（※文責: 瀧本恒平）

4.2

開発手法

4.2.1

導入した手法

4.2.1.1

アジャイル開発

本プロジェクトでは，システムやソフトウェア開発の手法の一つである，アジャイル開発を導入した. アジャイル開発とは，大きな単位でシステムを区切ることなく，小単位で実装とテストを繰り返すことにより，臨機応変に対応することができるため，継続して動くソフトウェアを作り続けることができる. そのため本プロジェクトでは，この開発手法を採用した.
（※文責: 瀧本恒平）

4.2.1.2

スクラム

本プロジェクトでは，アジャイル開発手法の 1 つである，スクラムを採用した. スクラムとは，反復を繰り返す開発プロセスのことを指し，この反復の単位をスプリントと呼ぶ. スプリントで行う内容としては，スプリントプランニング，デイリースクラム，スプリントレビュー，スプリント
レトロスペクティブ，開発作業などがある. スプリントプランニングとは，スプリントの開始に先立って行われる計画ミーティングを指す. このミーティングでは，プロダクトバックログと呼ばれるプロダクトへ追加する要求のリストからスプリントバックログを作成する. スプリントバックロ
グとは，プロダクトバックログの項目を完了させるために必要なすべての作業をリスト化したものである. また，デイリースクラムとは，開発チームの全員が活動状況を共有し，前回のデイリース
クラム以降に行った作業と，次回のデイリースクラムまでに行う作業を確認することをいう. これは，毎日決まった時間に決まった場所で 15 分程度行われる. また，スプリントレビューとは，スプリント終了時，チームの関係者に完成したプロダクトのデモンストレーションを行うことをいう.
開発した機能が正しく動作しているか，方向性が間違っていないか等の確認をここで行う. また，スプリントレトロスペクティブとは，スプリントレビューの後に行われる，振り返りの機会のことをいう. ここでは，今回のスプリントでうまくいったこと，うまくいかなかったこと，どうすれば次のスプリントで改善できるかといったことを話し合う. 本プロジェクトでは，1 週間をスプリン
トのタイムボックスとして，スクラムを行った.
（※文責: 瀧本恒平）

4.2.2

開発の流れ

本サービスの開発では，1 スプリントを 1 週間として行った．スプリント開始日は毎週水曜日としてスプリントプランニングを行った．プロダクトバックログとスプリントバックログは模造紙と付箋を用いて管理した．スプリント期間中の月曜・火曜・木曜は午前 8 時 30 分からデイリースク
ラムを実施した．1 回あたりの実施時間は，15 分を目安とした．このデイリースクラムでは，「昨日作業したこと」，「本日作業すること」，「困っていること」，「スプリントゴールまでにタスクを完了させられるか」について話し合った．そして，スプリント最終日には，スプリントレビューとス
プリントレトロスペクティブを行った．スプリントレビューでは，各メンバーがそのスプリントまGroup Report of 2019 SISP

- 18 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
でに開発したサービスのデモを行った．スプリントレトロスペクティブでは，KPT を用いてスプリントの振り返りを行った．KPT とは，Keep, Problem, Try の略である．Keep は「良かったこと・今後も続けたいこと」である．Problem は「うまくいかなかったこと・課題」についてである．Try は「今後行うこと」である．KPT では，それらの 3 項目についてそれぞれ付箋に書き出
し，スプリントの振り返りを行うとともに，チームの課題を見つけて改善案を立てた．
（※文責: 石川空人）

4.2.3

効果, 課題, 解決策

4.2.3.1

効果

デイリースクラムを行い，定期的にチームメンバーの進捗状況を確認し，開発で詰まっているところや，困っているところを共有することができることで，チーム内の問題を早期に発見することができた．例えば，アプリの UI デザインの作成に悩んでいるチームメンバーを発見して他のメンバーが支援したり，全体的に作業が遅れていることに早期に気づくことができたりなどの成果があった．また，1 スプリントごとに実際に動かせるものを作ることで，チームメンバーのモチベー
ションを保つことができ，本当に必要な機能のみを実装することができた．開発の後半には，チームメンバーだけでなく，他のチームのメンバーにも 1 スプリント毎に作ったものをデモで紹介することでレビューをもらった．それによって，特にアプリの UI デザインを使いやすいデザインに改善し，より完成度の高いものを開発することができた．他にも，1 スプリントの最後に振り返り（スプリントレトロスペクティブ）を行うことで，良かったところと悪かったところをチーム内で共有，認識することができた．チームの課題や継続すべき点を浮き彫りにすることで次のスプリン
トをより効率的に行うことができるようになった．実際の例として，全員が進捗を上げることができたことが良かった点として，特に作業を楽しみながら行うことができず，モチベーションが低下していたことが悪かった点としてあげられ，良い点はそのままに，悪い点は新しく学んだ技術を自分で好きに応用して使ってみることで楽しみをつくって改善できたチームもあった．
全体として，チームの早期問題発見や短い期間での振り返りによる作業の効率化といった効果があげられた．
（※文責: 熊谷峻）

4.2.3.2

課題

アジャイル開発手法の一つであるスクラム開発を取り入れることで，数々の効果が出たが，同時に課題も見つかった．まず，デイリースクラムに関してだが，これは決められた日に決められた時間で必ず行わなければならないものだったが，メンバー全員が揃わなかったり，時間通りに始める
ことができなかったりした．次に，本来は 1 週間で動くものを作り，デモを行うのが最善だったが，デモを行うことができたのが最後の 3 スプリントだけだったため，レビューをもらえる機会が少なくなってしまった．3 つめに，スプリントレトロスペクティブでは，何度も同じ問題が挙げられた時に，効果的な対策方法を探すことがなかなかできず，問題が長続きしてしまうことがあった．最後に，開発の前半はスクラム開発にまだ慣れていなかったため，進捗がうまくあがらず，最終的に，開発の後半にタスクが集中してしまった．
全体として，デイリースクラムへの遅刻，デモ披露の遅延，反省点の長続き，後半へのタスク集
中が課題として挙げられた．

Group Report of 2019 SISP

- 19 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life（※文責: 熊谷峻）

4.2.3.3

解決策

上記の 4.2.3.2 節で挙げられた課題を解決するために次のような対策を行った．まず，1 つ目の課題であるデイリースクラムへの遅刻に対する対策として，原因は，主にメンバーの寝坊やど忘れによるものが多かったため，デイリースクラムを行う日の前日や朝にリマインドを送ることで忘れないようにしたり，時間を全員が集まりやすい時間に変更することで寝坊を防いだり．ビデオ通話を利用することで遠隔で参加できるようにした．結果として，デイリースクラムへの遅刻を完全に防ぐことはできなかったが，最小限に抑えることができた．次に，2 つ目の課題であるデモ披露の遅延に対する対策として，1 週間に一度の決められた時間だけでなく，空いている時間に，他のグループのメンバーに積極的に意見をもらいに行くことでレビューをもらう機会を増やした．結果
として，グループ間での交流が盛んになり，意見交換が行いやすい環境を作り出すことができた．
そして，3 つ目の課題である反省点の長続きに対する対策として，特にデイリースクラム時にメン
バーのコンディションやモチベーションに問題がないかなどを注視し，デイリースクラム以外でも頻繁にメンバー間のコミュニケーションを行うことで，原因の発見を促した．結果として，根本的な原因を特定することができ，スプリントレトロスペクティブをより効率的に行うことができた．
最後に，4 つ目の課題である開発後半へのタスク集中に対する対策として，スプリントバックログ
をグループのベロシティに合わせて，消費しきれる範囲で無理なくタスクを割り振るようにし，主にスクラムマスターがデイリースクラムなどでチームの状況を確認し，開発がしやすい環境に整えることで，なるべく後半に負担がかからないようにした．結果として，ある程度負担軽減をすることができたが，最後にタスクが集中してしまうのは避けられなかった．
全体として，デモ披露の遅延と反省点の長続きの 2 点は解決することができたが，デイリースクラ
ムへの遅刻と後半へのタスク集中の 2 点はある程度改善できたが，完全な解決をすることはできな
かった．よって，この 2 点に関しては他の解決策を模索することが必要だと考える．
（※文責: 熊谷峻）

Group Report of 2019 SISP

- 20 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

第 5 章 システム仕様
5.1

システム構成本サービスのシステムは，ビーコン，モバイルアプリケーション，サーバ，Raspberry Pi から構成されている．ビーコンは MAMORIO 株式会社が販売している MAMORIO というタグ型のビーコンを使用している．モバイルアプリケーションは React Native という JavaScript のフレームワークを使用して開発した．このアプリケーションは，iOS, Android 両方の端末に対応しており，ペア登録，鍵登録，混雑状況確認などの機能を提供する．本サービスの大まかな流れとしては，
このアプリケーションでビーコンを登録し，そのビーコンを浴場内に持ち込む．そうすることによって，浴場内にある Raspberry Pi がビーコンを受信し，その情報をサーバに送信する．送信された情報を，異性側の Raspberry Pi で受け取りモニターにマークを表示するといった流れになっている. サーバサイドは，Golang を使用しており，データベースについては MySQL を使用している．モバイルアプリケーションや Raspberry Pi から FormData 形式で送られてくるファイル
を処理，データベースに格納するなどして通信を行っている．

図 5.1 システム構成図（※文責: 川谷知寛）

5.2

モバイルアプリケーション

本アプリはペアで使うアプリなので幅広く対応したいということで，iOS, Android の両方の開発を行った．開発言語としては，アプリ開発の担当が 1 人だったため，１つのコードで両プラットフォームに対応できる React Native を使用した．
（※文責: 川谷知寛）

Group Report of 2019 SISP

- 21 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

5.2.1

導入ライブラリ本アプリケーションでは，10 個のライブラリを導入した．以下に導入したライブラリと概要，本
アプリでの使用用途を示す．

• @react-native-community/async-storage(1.6.2)
データベース等を使用せずアプリ内にデータを保存できる．本アプリでは，アプリ ID や性
別情報, 認証番号を保存するのに使用した．

• axios(0.19.0)
サーバとの http 通信をするのに使用した．

• native-base(2.13.8)
iOS，Android 両方に対応した UI を気軽に使用できる．同じコードで両プラットフォームの差異を吸収した UI コンポーネントを提供してくれる．

• react-native-app-intro-slider(3.0.0)
チュートリアル画面作成の補助をしてくれるライブラリである.

• react-native-beacons-manager(1.0.7)
React Native で iBeacon などのビーコンを扱うためのライブラリである．React Native から直接 Bluetooth を扱うことはできないので，Native と連携して使用できるようになっている．本アプリではビーコンの検知，距離の測定に使用した．

• react-native-device-info(4.0.1)
使用するデバイスの情報を取得するライブラリである．アプリ ID を取得して，サーバに送信するために使用した．

• react-native-modal(11.4.0)
React Native でモーダルを表示するためのライブラリである．本アプリでは，ビーコン検索中の画面を表示するのに使用した．

• react-native-responsive-screen(1.3.0)
レスポンシブデザインを作成できるライブラリである．

• react-navigation(4.0.10)
React Native で画面遷移をできるようにするライブラリである．
• react-native-vector-icons
マテリアルデザインなどのアイコンを使用できるライブラリである．
（※文責: 川谷知寛）

5.2.2

ペア登録

本サービスでは，男女のペアで利用するため，誰と誰がペアなのかを事前に登録しておく必要がある．登録の方法として，1 人が認証番号を取得して，もう 1 人がその番号を入力し，それが一致した時にペアとしてデータベースに格納するようにした．また，再度ペア登録する手間を省くために，一度登録したペアはユーザが削除または，新しい人と登録しない限り，解除されないようになっている．
（※文責: 川谷知寛）

Group Report of 2019 SISP

- 22 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

5.2.3

ビーコン

ビーコンの電波を検知するには react-native-beacons-manager という React Native のライブ
ラリを使用した．本サービスでは，脱衣所の鍵１つ１つにビーコンを設置するため，ユーザがビーコンを登録する際に誤って近くにある別のビーコンを登録してしまう可能性が考えられた．そこ
で，検知したビーコンの accuracy 値を適時取得し，距離の判定を行った．スマートフォンにビー
コンを触れさせる程度の距離を検知した時のみビーコンを登録するようにした．その時に検知したビーコンの major 値を取得し，アプリ ID とペア登録に使用した認証番号をサーバに送ることで，ビーコンの登録ができるようになっている．
（※文責: 川谷知寛）

5.3

サーバサイドアプリケーション

5.3.1

概要

本サービスでは，ユーザのペアリング情報をデータベースに保存するため，API サーバを開発した. 開発には Golang と MySQL を用いた. これらを用いた理由として，各グループで使用する言語を揃えることによって，スムーズな連携を行うことを期待したためである. 以降より，データ
ベースと実装した API で提供するエンドポイントの詳細について記述する.
（※文責: 瀧本恒平）

5.3.2

エンドポイントの詳細

以下に開発したサーバサイドアプリケーションのエンドポイント及びその概要について示す.

• POST /UserData
データベースにユーザの性別とアプリケーションの固有 ID を格納する.

• POST /SetPass
アクセス時にランダムな 4 桁の認証番号を生成し，この番号をデータベースに格納した後に，レスポンスとしてこれを返す.

• POST /RegisterPass
データベースに認証番号を登録し，レスポンスとしてペア登録が完了したかどうかを返す• POST /SetUUIDandGetMark
データベースに個人ごとのビーコンの major 値を格納し，ランダムなマークを示す文字列を生成，格納する. レスポンスとして，マークを示す文字列を返す.

• POST /Bathhouse
データベースに脱衣所の Raspberry pi が取得するビーコンの情報を格納する. 同時に，マークを赤色に変更する旨を記した文字列も格納する.

• POST /ChangeMark
データベースに浴場の Raspberry pi が取得するビーコンの情報を格納する. 同時に，マークを青色に変更する旨を記した文字列も格納する. レスポンスとして，モニターに表示するGroup Report of 2019 SISP

- 23 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeべきマークとその色に関する文字列を返す.

• GET /Congestion
浴場，脱衣所内にて確認されるペア登録済みのビーコンの数を返す.
（※文責: 瀧本恒平）

5.3.3

データベース本サービスのサーバサイドアプリケーションでは，1 つのテーブルを作成した．ユーザのペアリ
ング情報を共有する pairing user テーブルである．このテーブルの詳細を，表 5.1 に示す．
（※文責: 瀧本恒平）

表 5.1 pairing user テーブル

カラム名

型

概要

app idStringモバイルアプリの固有 ID

genderStringユーザの性別pairing id

String

ペア登録時の認証番号

beacon id

Stringビーコンの major 値

mark str

Stringマークを示す文字列

5.4

Raspberry Pi

5.4.1

概要

本サービスにおいて，ビーコンの受信や，モニタへのマーク出力などに Raspberry Pi を使用した．Raspberry Pi は男湯・女湯のそれぞれの脱衣所と浴場に，1 台ずつ設置することとした．ビーコンの受信や，その情報をもとにしたサーバサイドとの連携には Node.js，モニタへのマーク出力には Processing を使用した．
（※文責: 石川空人）

5.4.2

ビーコン受信Raspberry Pi 上での開発ではまず，ビーコンを受信する機能を実装した．これは，ビーコンを持った公衆浴場施設内のユーザの居場所を特定するためである．それぞれ設置した Raspberry Piのうち，どの Raspberry Pi でユーザの持っているビーコンを受信したかによって，そのユーザの居場所を特定することができる仕組みである．この実装にあたって，Node.js のモジュールである

bleacon を使用した．bleacon は，ビーコン電波を受信すると，そのビーコンの UUID や major
値・minor 値に加え，そのビーコンとの距離を取得することができる．
（※文責: 石川空人）

Group Report of 2019 SISP

- 24 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

5.4.3

サーバサイドとの連携

サーバサイドとの連携では，受信したビーコンの情報の送信と，ペアの居場所情報の取得を行うよう実装した．実際の流れとしては，ビーコンを受信した際、その情報をサーバサイドへ送信し，そのレスポンスとしてサーバサイドから，送信したビーコンを持つユーザのペアの居場所情報を取得するように実装した．ここで，ペアの居場所情報は，モニタに表示すべきマークとその色の情報として取得した．取得したマークの情報は，次項で述べるマークのモニタ出力を行う Processing
へ送信した．サーバサイドとの情報のやり取りには，request を使用した．request とは，Node.jsのモジュールで，HTTP 通信を可能にするものである．
（※文責: 石川空人）

5.4.4

マーク出力

ユーザにペアの居場所を知らせるために，ペア固有のマークをペアの居場所によって，色を分けて出力した．マークの色は，ペアが脱衣所にいるときは赤，浴場にいるときは青とした．これらの実装には Processing を使用した．5.4.3 節で述べたように，出力するマークやその色は，サーバサ
イドから取得した情報を基に変化させた．このとき，Node.js と Processing との情報のやり取りには，WebSocket を使用した．
（※文責: 石川空人）

5.5

デザイン

5.5.1

アプリアイコン「ゆまち」というサービスは，温泉を利用するため温泉のマークを使用した．湯船の温かいイメー
ジから，ベースカラーを赤色に決め，デザインを考えた．文字やマークの見易さも考慮して，カラーコード#E56A5B を用いた．また，温泉のマークだけでは，少し分かりづらいと感じたため，
サービス名である「ゆまち」の文字をマークの下に設置した．
（※文責: 川谷知寛）

5.5.2

アプリデザイン

作成には，Adobe XD というツールを使用した．アプリデザインとしては, ベースカラーである
カラーコード#E56A5B を用いてボタン等を作成した．本アプリはシンプルな機能が多いため，一目で使い方がわかるようなデザインを心がけた．
（※文責: 川谷知寛）

Group Report of 2019 SISP

- 25 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

5.5.3

ペアのマーク

温泉のモニターに表示するマークは，和に関連させたいと考えた．さらに，複数のペアで利用する想定なので，様々な種類を用意できるという理由で寿司をマークに使用することに決めた．しかし，成果発表会等で，寿司のマークに疑問や違和感を持つ方が多かったため，寿司のマークはあまりよくないという印象を持った．そのため，今後の展望として，マークのデザインの検討をしたいと考えている．また，現在モニターに表示するマークの色は，赤と青を使用しているが，今後，色覚障害のある方に向けて色や背景の色を考慮したい．
（※文責: 川谷知寛）

5.6

インフラ

本サービスの API サーバを運用するためのクラウドコンピューティングサービスとして Gogle

Cloud Platform(以後，GCP) を採用した．GCP とは，Google 社が提供するクラウドサービス群のことである．GCP を用いることで仮想マシンを従量課金制で使用できる．本サービスでは

GCP のサービスである Google Compute Engine(以降，GCE) と Google Kubernetes Engine(以降，GKE) を使用した．GCE とは，仮想マシンと呼ばれる仮想的なコンピュータを提供するサービスである．GCE を使用することで，要件に合わせた性能の仮想マシンを用意できる．GKE とは，コンテナ化されたアプリケーションを運用するためのサービスである．GKE を用いることでサービスの需要に合わせてオートスケーリングと呼ばれる CPU やメモリの量を自動で増やすシス
テムを完全に停止させずにアプリケーションを更新すること，障害発生時の自動修復を行うことなどが可能になる．本サービスでは，GCE に MySQL をインストールし，Go で作成した API サー
バを立てた．また，GKE の構築完了後，API サーバを GCE から GKE へ移行した．
（※文責: 宮越七菜）

Group Report of 2019 SISP

- 26 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

第 6 章 外部評価
6.1

中間発表

6.1.1

発表形式

7 月 19 日 (金) に行われた中間発表会では，ポスターとスライドを用いて発表を行った．初めに
5 分間でスライドの発表を行った．スライドでは，プロジェクトの概要とビーコンの簡単な説明，
これまでに行った勉強会やフィールドワークでの学び，アイデアコンテストで決定した 4 つのアイ
デアのタイトルとキャッチコピー，今後の予定についての説明を行った．その後，4 つのアイデアのポスターのうち，観衆が興味のあるアイデアのポスターの前に来てもらい発表を行った．私たちのグループでは，ポスターを用いて前半タームを 1 人，後半タームを 2 人で分かれ発表を行った．
グループ発表では，5 分でポスターを用いながらサービスの概要を説明し，残りの時間で質疑応答を行った．
（※文責: 川谷知寛）

6.1.2

レビュー内容6.1.2.1

発表形式の評価と反省

発表内容に関しての高評価な意見として• 順を追ってサービスについて説明していて良かった• 質疑応答がしっかり行えたので良かった• すごく聞き取りやすかったなどがあった．わかりやすいサービスの説明を行うことができ，サービスについてある程度理解してもらうことができたと言える．一方，低評価な意見として• 全体説明の時に各アイデアに関する説明を詳しくして欲しい• ポスターセッションで１つだけではなく全部のアイデアを見たかった• デモがないのが残念だなどがあった．私たちのグループの平均評価は 10 点中，7.81 であった．以上のことから，時間を割り振って全てのアイデアのポスターセッションに参加できるようにする工夫が必要だということが分かった．また，デモを用意した方が聴き手側もサービスに対するイメージがつきやすいことが分かった．
（※文責: 川谷知寛）

6.1.2.2

発表内容の評価と反省

発表内容に関しての高評価な意見としてGroup Report of 2019 SISP

- 27 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
• 温泉の待ち合わせを解消するという提案は面白いと思った• 混雑状況がわかるのは便利だと思う• 内容がユニークで良かった• 不満からサービスを決定しているのでいいものができると思ったなどがあった．一方，低評価な意見として• 待ち合わせのサービスというより温泉施設自体向けのサービスに感じた• マークの表示の仕方に工夫が必要だと感じた• 実装上の問題点の検討が必要などの意見があった．私たちのグループの平均評価は 10 点中，7.71 であった．以上の意見から，サービスの概要や有用性を伝えることはできたが，実装する上での問題点の解決策や詳細な仕様の決定が必要であるということが分かった．この結果を踏まえて今後は，実際に温泉施設にフィール
ドワークに行きサービスの問題点の検討を行う．さらに，実証実験を行い，サービスの有用性を確かめる必要があると考えられる．
（※文責: 川谷知寛）

6.2

公立はこだて未来大学オープンキャンパス

2019 年 8 月 4 日に，公立はこだて未来大学のオープンキャンパスが開催された．本プロジェク
トは，そのイベントの 1 つのインタラクティブ展示に『「ここにいる人だけ」コミュニケーション』
として出展した．出展には，中間発表に使用した全体ポスタープロジェクト 1 枚，各サービスのポ
スター 4 枚の展示した．また，来場者の方にビーコンを用いたサービスの特徴を直感的に体験していただくために，昨年度のサービスのデモを行った．実際に来場者の方へは，来場者の方自身が興味を持ったサービスについて，ポスターを用いた簡単な説明をした後，昨年度のサービスのデモを体験していただくという形式をとった．来場者の方を，これから実装するサービスのユーザとして想定しながら説明や質疑応答をすることによって，サービスの構想をより深めることができた．
（※文責: 石川空人）

6.3

HAKODATE アカデミックリンク 20192019 年 11 月 9 日に，はこだて高等教育機関合同研究発表会 アカデミックリンク 2019 が北海道教育大学函館校にて開催された．このイベントは，函館市内の大学・高等専門学校・高等学校などが行った研究を，市民の方や企業の方へ発表するものであった．本プロジェクトは「函ライブ」と「みみうち」を 1 チーム，
「去りし想いを乗せゆきて」と「ゆまち」を 1 チームとした，計 2 チーム
でブースを作り参加した．
（※文責: 石川空人）

Group Report of 2019 SISP

- 28 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

6.3.1

評価

基本スタイルはポスターセッションで，各サービスのポスターを用いた説明の後に，その時点まで実装されていたサービスのデモを行う流れであった．ポスターを用いた説明では，本イベント用に作成したポスターを用いて，サービスの内容や今後の展望などを説明した．デモでは，スマートフォンを使ってペアの登録からビーコンを使用して鍵の登録をした後，登録したビーコンを持った人が場所を移動すると，表示されているマークの色が変化するところを体験できるようにした．ポスター説明・デモの後は，質疑応答や意見交換を行った．
（※文責: 石川空人）

6.3.2

評価

発表内容に対し，肯定的な評価として，• 家族連れで使いたい• 温泉以外でも使ってみたい• 初めていく温泉で使いたいなどがあり，本サービスを利用する意義を理解していただくことができた．否定的な評価として，• ペア登録の手順がわかりにくい• 初期コストに対する利益が見込めないなどがあった．この中の，「ペア登録の手順がわかりにくい」に対しては，チュートリアル機能を実装して解決することとした．
（※文責: 石川空人）

6.4

成果発表会

6.4.1

発表形式

2019 年 12 月 9 日，公立はこだて未来大学にて，プロジェクト学習最終成果発表会が行われた．
本プロジェクトは 3 階 364 教室前，及び教室内にて発表を行った．発表の流れは，まずプロジェク
トの全体の概要説明をした．その後，「函ライブ」
・「去りし想ひを乗せ行きて」
・
「ゆまち」
・
「みみう
ち」の各サービスがそれぞれにポスターセッションをし，聴講者の方は興味を持ったサービスのポ
スターセッションに参加していただいた．本サービスでは，ポスターセッションを行った後，サービスのデモを行った．デモは，教室前と教室内をそれぞれロビー・脱衣所と浴場に見立て，ペア登録からペアの状況をモニタで確認をするところまで行った．また，聴講者の方と脱衣所から浴場に実際に歩いて移動して，デモの臨場感や実際の使用感を感じられるように行った．
（※文責: 石川空人）

Group Report of 2019 SISP

- 29 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

6.4.2

発表技術の評価と反省

発表技術に関しての肯定的な意見として，• 脱衣所と浴場を移動する想定のデモは，臨場感があってよかった• サービスについての説明がわかりやすかった．
• ポスターからデモの流れが良かった．
などが挙げられ，特にデモについての好意的な意見が多かった．デモを通して，実際に使っているイメージをしてもらうことができたと考える．また，否定的な意見として• 少し声が聞こえにくかった．
• なぜ「ゆまち」なのかという説明が欲しかった．
といった意見が挙げられた．発表技術に関しての否定的な意見は少なく，ポスターやデモを通してサービスの内容を理解してもらえたと考える．
（※文責: 川谷知寛）

6.4.3

発表内容の評価と反省

発表内容に関しての高評価な意見として• 個性があり実用性が高い• 実際に夫婦で行くと待ち合わせにならないことがあるので使ってみたいなどが挙げられた. 実際に「ゆまち」というサービスを体験してもらったことで，有用性を理解してもらえたことがわかる. また，低評価な意見として，• マークを見ても急かされるだけでリラックスできない• マークが寿司である必要性はあるのかなどが挙げられた. これは，本サービスの仕様上，入浴中ペア同士での連絡を取り合えない中でペアの状況が見えてしまうが故に，不安感を煽ってしまうという問題点が指摘された. また，マークに関しては寿司である必要はないため，もう少し見やすく区別が付きやすいものに改善する必要があると感じた. これにより，本サービスが抱えるマークに関する課題は，中間発表の時からあまり改善できなかったということになるため，これを反省点とした.
（※文責: 瀧本恒平）

6.5

enPiT ByzSysD 北海道・東北グループ合同発表会

2019 年 12 月 14 日に室蘭工業大学にて行われた北海道・東北グループ合同発表会に，会津大学，
岩手県立大学，公立はこだて未来大学，室蘭工業大学，北海道情報大学が参加した. 北海道・東北
グループ合同発表会では参加大学の学生が各々の学習成果の報告を行うとともに，他大学の学生や教員の方々と交流することを目的として開催された. 当プロジェクトからは 8 名が参加し，「ゆまGroup Report of 2019 SISP

- 30 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeち」からは２名が参加した. 発表形式としては，チームごとに前半・後半に分かれて 1 時間ずつポ
スターセッションを行った. ポスターセッションでは，プロジェクトの概要を簡単に述べた後，「ゆまち」の背景や目的などを説明し，サービスのデモを行った. ポスターセッション後の質疑応答にていただいた高評価な意見として，• 移動して体験するデモが面白い• 斬新なアイデアであるなどが挙げられた. 実際にサービスに触れてもらうことでサービス内容について理解を深めてもらうことができた. また反対に，低評価な意見として，• どの点で利益になるのか• 温泉にしか使えないのはターゲットを絞り過ぎではないかなどが挙げられた. ビジネス面については深く考えていなかったため，これから 1 つの案として考えておく必要があると感じた.
（※文責: 瀧本恒平）

Group Report of 2019 SISP

- 31 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

第7章
7.1

各メンバーの振り返り

役割分担

本サービスを実装するにあたり，モバイルアプリケーション開発担当・API サーバ開発担当・

Raspberry Pi 担当に役割を分けて開発を行った．また，アジャイル開発を行うにあたって，プロ
ダクトオーナーとスクラムマスターもそれぞれ 1 人ずつ担当した．各メンバーの詳細な担当内容を以下に示す．
瀧本恒平• プロダクトオーナー• API サーバ開発• データベース構築
川谷知寛• モバイルアプリケーション開発• デザイン• ポスター作成
石川空人• スクラムマスター• Raspberry Pi• モックアップ作成（※文責: 石川空人）

7.2

瀧本恒平の振り返り

PBL の活動を通して，初めて明確にチーム開発というものを体験した. その過程で，最も苦労したのはアイデア出しである. 当プロジェクトでサービスに求められる要素として，「函館らしさ」・「ビーコンらしさ」・「新規性」などが挙げられる. これらの要素を全て満たすアイデアを得るため，
実際に街に赴き課題を探す (フィールドワーク) などをしたが，あまり良い着想を得ることはできなかった. また，フィールドワークで得た知見を基に，アイデア出しの手法もいくつか試してみたが，あくまでアイデアを出すのは自分たちであるため難しく感じることが多くあった. また，開発手法として，アジャイル開発手法の 1 つであるスクラムを取り入れたのも初めてだった. これは，実際に取り入れてみるとタスク管理と見積もりが容易であるということを身をもって実感した. 社
会に出る前にこのような開発手法を経験できたことはとても嬉しく思う. また，サーバサイドについて触れたのも今回が初だった. サーバサイドはどんな作業から始めたらいいのかを調べるところから始まったことを考えると，技術的な面で少しは成長できたのだと思う. しかし，自分が関わっGroup Report of 2019 SISP

- 32 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
た技術がいくつかある中で，積極的に理解しようとして取り組めたものばかりではなかったため，今後の活動の中で学習すべき部分はまだ多くあるようにも感じた. また，チーム内でのコミュニ
ケーション不足により，追加する機能や画面デザインがうまく決まらないこともあったため，そこは反省すべき点であると感じた. その上で，積極的なコミュニケーションを行い，何かしら決める
ことがある場合は密に相談することが大切であることも強く感じた. これらの PBL を通した学びを今後の活動で生かしていきたい.
（※文責: 瀧本恒平）

7.3

川谷知寛の振り返り

私はこのプロジェクト学習を通して様々なことを学ぶことができた．前期では，フィールドワー
クやアイデア出しを行った．特にアイデア出しでは，フィールドワークを行って発見した函館の課
題や特徴を活かし，思いついたアイデアをとりあえず質より量で出し続けた．その過程でアイデア出しの手法とアイデアをより良いものにしていく方法を身につけることができた．また，成果発表
会や企業の方への発表などを通して，期日までに間に合わせる力やプレゼン力を磨くことができた．夏季休暇中では，後期からのアプリ開発に対応するために，使用する言語である React Nativeの技術習得や Git, GitHub の勉強を行った．自分は今までアプリ開発というものを経験したことがなかったため，後期からの開発がとても不安であった．そのため，後期から失敗しないように
ビーコンの扱い方や画面遷移の仕方などをあらかじめ学んでおいた．後期からの開発では，モバイ
ルアプリの開発を担当した．React Native では Bluetooth の扱いができなかったため，ネイティ
ブとの連携やライブラリの使用方法を調べるのが難しかった．また，メジャーな言語ではないため
日本語の記事が少なく，英語の記事を読むことが多かったためすごく苦労した．さらには，サーバサイドとの連携も初めて行ったため，連携が思った通りにうまくいかず大変だった部分もあったが，チームでの開発の大変さやサーバに関する知識を得るいい機会となった．スクラム開発については，朝のデイリースクラムや予定通りにいかないタスクに苦労はしたものの，問題が発生した
らすぐに対応できることや，目に見えて進捗が出ることにメリットを感じることができた．また，チームメンバーとのコミュニケーションを通して，やるべきことを認識し，すぐに取り組むことができた．改めてチーム内でのコミュニケーションをとることの大切さを学んだ．デザインについて
は，Adobe XD を使用して作成した．自分はデザインに関しては全くの無知だったため，この開発で一番苦労した部分だった．温泉に会うデザインは何か，を考えながら作成していたが，自分が良いと思っていても伝えたいものが伝わらなかったり，分かりづらいという意見をもらうことが多かった．そのため，自分 1 人で作るのは難しいと感じ，メンバーにレビューをもらいながら修正して，より良いものにしていくことができた．私は，この 1 年間を通して自分に自信がつき，新しい知識や経験をたくさん得ることが出来た．この学習で得た学びを，今後の大学生活や就職してからも活かしていきたい．
（※文責: 川谷知寛）

Group Report of 2019 SISP

- 33 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

7.4

石川空人の振り返り

プロジェクト学習の活動を通して一番大きな収穫となったのは，実際にシステム開発の一連の流れを経験できたことである．これまでに開発を行った経験はなかったため，ゼロからのスタートであったが，メンバーと協力したり教員からアドバイスを得たりしながら，少しずつ力を付けられた．
前期は主に，フィールドワークとアイデア出しを行った．フィールドワークでは，函館の街のあらゆる場所を訪れ，様々な情報を収集した．私は函館出身なために大概の場所は見慣れていたが，その中で，既存の当たり前なことに疑問を持ちながら周りを観察し，また考察することの重要性を学んだ．アイデア出しでは，フィールドワークから得られた情報を整理して課題を見出し，それを解決するサービスの案を出した．最終的に４つのサービスに決定したが，決定するまでに多くの時間がかかった．多種多様な情報の中から課題を見出し，また効果的にその課題を解決する手段を考案する難しさを学んだ．
後期は主にサービスの開発を行った．私は Raspberry Pi を担当した．Raspberry Pi に関しては，担当したメンバーは私のみであった．そのため，メンバー間での協力はあまりできなかったが，担当者が１人であるがゆえに一層の責任を持ち，根気強くものごとに取り組む重要性を再確認できた．本サービスではアジャイル開発の１つであるスクラムを用いて開発を行った．スクラムは，メンバー間の認識の違いが生じると，開発する対象にもずれが生じてしまう．そのため，デイリース
クラムなどを通したコミュニケーションや，それ以外でも逐次，報告・連絡・相談が重要だと学んだ．1 年間のプロジェクト学習を通して学んだことは，システム開発だけにとどまらず，社会の中でも重要になると考える．経験したあらゆることを活用・応用して，今後に活かしていきたい．
（※文責: 石川空人）

Group Report of 2019 SISP

- 34 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

第 8 章 まとめと展望
8.1

前期の振り返り本プロジェクトはビーコンを使って函館のまちをより良くするという目的で活動を開始した．前期の活動は「ビーコンについての学習」
・「フィールドワーク」
・「アイデア出し」等を行った．フィー
ルドワークでは，函館の西部地区や湯の川に訪れた．そこで発見した函館の課題や問題，特徴など
をエリアごとに付箋にまとめた．次に，それを元に「函館らしさ」
・「ビーコンである理由」
・
「新規
性」・
「継続性」・「必要性」の 5 つの観点を重要視しアイデア出しを行った．その後，類似しているアイデアをまとめ，見えている課題の解決策を付箋に書いていきながらアイデアを深めていき，
最終的にアイデアを 5 個ほどに絞った．絞ったアイデアをスライドにまとめ，プロジェクトメン
バーや教員，OB，OG などに発表を行い，その後レビューを得た．しかし，１回目のプレゼンではあまりいい評価を得られなかったので，さらにアイデアを深めたり，全く新しいアイデアを追加
して，２回目のプレゼンを行った．最終的には投票を行い，評価の高かった「去りし想いを乗せゆきて」
・「みみうち」
・「函ライブ」
・「ゆまち」の 4 つのサービスの開発を行うことが決定した．その後，各サービスにチーム分けし，チームごとに活動を行った．中間発表に向けて，サービスの背景
や目的，機能などについて話し合いを行った．また，夏季休暇中に，後期に向けて開発に必要な技術の習得をした．
（※文責: 川谷知寛）

8.2

後期の振り返り後期では初めにスクラム開発についての学習を行い，チーム内でプロダクトオーナー，スクラムマスターを決め，開発を開始した．毎週のスプリントレビューやスプリントレトロスペクティブ，
計画ミーティングを通して，反省や改善を行い，よりよいプロダクトになるよう精進した．また，
ゆまちでは毎週月曜日，火曜日，木曜日の朝 8 時半からデイリースクラムを行い，モチベーションの維持や目標を見失わないように心がけた．この朝から行うデイリースクラムのおかげで，十分な作業時間を確保でき，プロダクトの完成ができたと考えている．また，HAKODATE アカデミッ
クリンク 2019 というイベントに参加した．そこで企業の方や学生からフィードバックを得た．そのフィードバックを基に，モチベーションの向上や機能の改善などを行った．その後，成果発表会に向けてポスター作成やデモの練習，発表練習を行った．
（※文責: 川谷知寛）

8.3

今後の展望

今回我々が提案したサービスには２つ課題がある. １つ目は Raspberry Pi の受信したビーコンの major 値を送信する間隔が，回線速度に依存しているということである. 回線速度が良好である
場所では問題なくサービスが稼働するが，回線速度が良好でない場所では，モニターに表示していGroup Report of 2019 SISP

- 35 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeるマークの色が変わるまで大きなタイムラグが出てしまい，最悪の場合 Raspberry Pi で実行しているプログラム自体がダウンしてしまうこともある. これを回避するためには，回線速度が良好である場所でビーコンの受信を行うこと，またプログラムの非同期処理について見直す必要がある.
２つ目はマークの表示方法についてである. 温泉では基本的に眼鏡を外して入浴することが多いた
め，現状のようにマークの色が変化するだけでは遠くからでは見えにくい. そのため，色を反転させて見やすくするか，マークの表示方法自体を変更する必要がある. また，この課題については，マークが見えにくいだけではなく，温泉浴場の景観の一部を損なう可能性についても考えなければならない. 現状では温泉浴場内にモニターを設置し，映し出されるマークの色で自分のペアが現在どこにいるかを判別するというサービスになっている. しかし，温泉浴場の雰囲気とモニターが合うかどうかについては，開発期間中に何度も議論されていた. 実際，サウナ内ではあるが温泉浴場
内にモニターを設置している公衆浴場施設は少なくない. また，ごく少ない施設数ではあるが，露天風呂にモニターを設置している公衆浴場施設も存在する. これらの 2 つの事柄を踏まえると，温泉浴場内にモニターが設置されるというのは，大きな違和感を持つものではないようにも感じる.
しかし，これらの施設がモニターを設置している理由は，公衆浴場施設に訪れた温泉利用客の退屈凌ぎのためにテレビを流すためである. それに対して，本サービスが設置するモニターの使用目的
は，マークを表示するのみである. この使用目的の違いによって，景観を損なうかどうかも大きく違ってくる可能性もある. これらの事柄を踏まえて，モニターではなく浴場内のタイルにマークを投影する案も出ている.
（※文責: 瀧本恒平）

Group Report of 2019 SISP

- 36 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

付録 A 中間報告会で使用したプロジェクト概要のポスター

図 A.1 プロジェクト概要（中間報告会）

Group Report of 2019 SISP

- 37 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

付録 B 中間報告会で使用した本グループのポスター

図 B.1 ゆまち ♨（中間報告会）

Group Report of 2019 SISP

- 38 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

付録 C 成果発表会で使用したプロジェクト概要のポスター 1

図 C.1 プロジェクト概要（成果発表会）

Group Report of 2019 SISP

- 39 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

付録 D 成果発表会で使用したプロジェクト概要のポスター 2

図 D.1

Group Report of 2019 SISP

プロジェクト概要（成果発表会）- 40 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

付録 E
スター

成果発表会で使用した本グループのポ

図 E.1

Group Report of 2019 SISP

ゆまち ♨（成果発表会）- 41 -

Group Number 10-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life

参考文献
[1] 古館達也，堀川三好，工藤大希，岡本東：Bluetooth Low Energy ビーコンを用いた屋内測位手法に関する研究，情報科学技術フォーラム講演論文集，第 14 巻，4 号，pp. 311-312(2015).

[2] 函館市，（2010），函館市温泉資源保護指針,
https://www.city.hakodate.hokkaido.jp/docs/2014010700230/ﬁles/sisin.pdf，(last accessed
2018/7/20).

Group Report of 2019 SISP

- 42 -

Group Number 10-C