公立はこだて未来大学 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
Hakolive
プロジェクト番号/Project No.

10-D

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

Shintaro Watanabe

グループリーダ/Group Leader
渡邊慎太郎

Shintaro Watanabe

グループメンバ/Group Member
渡邊慎太郎

Shintaro Watanabe

吉川綾乃

Ayano Yoshikawa

斉藤由樹

Yoshiki Saito

熊谷峻

Kumagai Shun

指導教員
松原克弥

藤野雄一 鈴木恵二

鈴木昭二

奥野拓

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

提出日2020 年 1 月 22 日

Date of Submission
Jan 22, 2020

概要
本プロジェクトは，ビーコンを函館の街の様々な場所に設置して，新たな体験や魅力を提供す
ることを目的とする．ビーコンを用いることより，函館という地域に付加価値をもたらすことに重点をおいたサービスを提供する．どのようなサービスを提案するかのアイデア出しを行うにあたり，フィールドワークによって函館の街の課題を洗い出した．洗い出した課題をもとに，函館らしさ・ビーコンである理由・新規性・継続したくなる魅力・必要性の 5 つの観点に重点をおいて 7 つのアイデアを創出した．さらに，それらをブラッシュアップすることによって 4
つのサービスを提案するに至った．
（※文責: 渡邊慎太郎）
路上ライブは演奏者と聴き手の距離が近く，不特定多数の人に気軽に音楽を聴いてもらえるという特徴がある．また，函館は音楽と親和性があり，GLAY，北島三郎等，有名アーティス
トを輩出している街である．だが，函館の街では路上ライブが，あまり盛んに行われていない印象がある．その原因として，路上ライブは大きな音を発するため，ライブ音を聴きたくない
人には煩わしく感じるという問題がある．そこで，本グループはこの問題を解決するために，
路上ライブを聴きたいと思っている人だけに音を伝えるサービス「函ライブ」を提案する．本サービスを利用することにより，路上ライブを煩わしいと思っている人には音を聴かせずに演奏に興味を持った人だけに音を伝えることができる．また，大きな音を立てないため屋内で演奏することも可能である．前期では，「函ライブ」のサービス概要と機能を決定した．後期では「函ライブ」の要件定義を行った．次にアプリケーションを開発するために技術検証を行った．
その後アプリケーションを開発を行い，実際に電子楽器を接続をして実際に演奏を行い有用性の検証を行った．
（※文責: 渡邊慎太郎）キーワード

路上ライブ, ビーコン, アーティスト, 無音, スマートフォン-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.
（※文責: 大野和也）

Street performance has features. In street performance, distance of performer and audience is close and performer can play the music for unspeciﬁed people. In addition,
Hakodate is highly familiar with music because Hakodate produces many famous musician. For example, GLAY, Kitajima Saburo and YUKI. However, there are few street
performances in Hakodate. The reasons of this, street performance makes a loud noise.
People who are not interested in street performance feel annoying it. Therefore, we
proposal the service named ”hakolive” because we solve this issue. This service conveys
the sound to audience who wants to listen street performance. Performer who use thisservice can convey the sound only people are interested in street performance. Moreover, this service doesn’t make a loud noise. Performer who use this service are able to
do street perfomance indoors. We decided to overview of this service and function in
the ﬁrst semester. In the second semester, we decided to requirement deﬁnition. Next,
technical veriﬁcation was performed to develop the application. Finally, we developed
an application and connected it to an electronic musical instrument and performed it
to verify its usefulness.
Keywordstreet performance, beacon, artist, silent, smartphone（※文責: 渡邊慎太郎）- 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

開発

12

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

12

4.1.1

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

12

4.1.2

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

13

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

13

4.2.1

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

13

4.2.2

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

14

4.2.3

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

15

第4章

4.1

4.2

- iii -

第5章

システム仕様17

5.1

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

17

5.2

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

17

5.2.1

演奏者の演奏を配信する機能 . . . . . . . . . . . . . . . . . . . . . . . . .

18

5.2.2

近くの演奏者の演奏を視聴する機能. . . . . . . . . . . . . . . . . . . . .

18

5.2.3

演奏者のプロフィール機能 . . . . . . . . . . . . . . . . . . . . . . . . . .

18

5.2.4

演奏者にいいねを送る機能 . . . . . . . . . . . . . . . . . . . . . . . . . .

18

5.2.5

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

18

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

19

5.3.1

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

19

5.3.2

Players モデルに関する API . . . . . . . . . . . . . . . . . . . . . . . . .

19

5.3.3

ストリーミングサーバ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

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

20

5.4.1

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

20

5.4.2

サービスロゴ，アプリアイコン . . . . . . . . . . . . . . . . . . . . . . . .

21

インフラストラクチャー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

外部評価

22

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

22

6.1.1

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

22

6.1.2

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

22

6.1.3

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

22

6.2

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

23

6.3

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

23

6.3.1

手段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

6.3.2

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

24

5.3

5.4

5.5
第6章

6.1

6.4

青森市学生ビジネスアイデアコンテスト （Aomori Business Challenge GATE）〜青函ツインシティ 30th Anniversary〜 . . . . . . . . . . . . . . . . . . . . . .

24

6.4.1

ビジネスアイデアコンテスト . . . . . . . . . . . . . . . . . . . . . . . . .

24

6.4.2

準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

6.4.3

発表当日 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

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

25

6.5.1

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

25

6.5.2

発表準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

6.5.3

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

26

6.5.4

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

26

6.5.5

コンセプトの評価と反省. . . . . . . . . . . . . . . . . . . . . . . . . . .

27

6.5.6

アプリケーションの評価と反省 . . . . . . . . . . . . . . . . . . . . . . . .

27

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

28

各メンバーの振り返り

29

7.1

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

29

7.2

渡邊慎太郎の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

6.5

6.6
第7章

- iv -

7.2.1

プロジェクトリーダーとしての振り返り . . . . . . . . . . . . . . . . . . .

30

7.2.2

アイデア出し . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

7.2.3

開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

吉川綾乃の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

7.3.1

アイデア出し . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

7.3.2

開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

7.3.3

副リーダーとして . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

7.4

斉藤由樹の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

7.5

熊谷峻の振り返り

33

7.3

第8章

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

まとめと展望35

8.1

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

35

8.2

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

35

8.3

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

36

付録 A

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

37

付録 B

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

38

付録 C

HAKODATE アカデミックリンク 2019 で使用した本グループのポスター

39

付録 D

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

40

付録 E

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

42

参考文献

43

-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-D

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-D

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-D

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-D

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-D

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.1 ロゴ案 1

Group Report of 2019 SISP

図 2.2

-6-

ロゴ案 2

Group Number 10-D

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-D

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-D

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-D

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

第3章
3.1

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

路上ライブは全国各地の路上で行われるゲリラ的ライブ活動である．自分の歌を直接広めることができることから，根強く続いている文化である．この路上ライブは観客と直接ふれあいながらライブをできるため，観客は気軽に奏でられる音楽を聞くことができ，演奏者は道行く人へ自身の音楽を直接伝えることができる．また，路上ライブがミュージシャンとして名を挙げるという手段に使われることもあり，函館出身のアーティストである GLAY は函館にてライブをしていた．さらに，函館出身のアーティストとして北島三郎や YUKI 等の著名な歌手も存在していることから，函館は音楽と親和性の高い土地だと言える．しかし函館では路上ライブは盛んに行われている様子はなく，街を歩いていても路上ライブに出会うことはほとんどないため函館は路上ライブと親和性の低い土地であると考えた．
（※文責: 斉藤由樹）

3.2

課題

函館は，修道院のような静かな時間を大事にする土地も多く，決められた地点に限りライブを許可するヘブンアーティスト [2] のような制度も存在しないことから，路上ライブが盛んではないことがないことがわかる．また，大音量で流れる音楽は時に騒音に聞こえることがあり，静かな観光地や住宅街などでの路上ライブは近隣への迷惑になることがある．加えて，屋外での路上ライブは
天候にも左右されやすく，許可をとった場合でもライブができなくなる場合がある．
（※文責: 斉藤由樹）

3.3

本サービスの概要

本サービスのメインターゲットは，路上ライブの演奏者と聴衆である．背景であげた課題を解決するために，音のでないサイレントなライブができるようなサービスにする．そのために，ライブ
音を限られた人のみが聴くことができるようなサービスにする必要がある．具体的には，演奏者が本サービスのアプリケーション（以下，アプリ）を起動したスマートフォンに電子楽器を繋いで演奏することで，音の出ないライブを行うことができる．ここで，iBeacon を利用し，このスマートフォンをビーコンとしても使用する．一方，聴衆はビーコンの範囲に入ると，本サービスのアプリが入ったスマートフォンに通知が送られ，興味のある人は自分のスマートフォンでアプリを起動して路上ライブを聴くことができ，興味のない人はそのまま通り過ぎることができる．また，路上ラ
イブを聴いている時にはアプリを通して演奏者へのリアクションが送ることができるようにすることで，演奏者がフィードバックをもらうこともできる．
（※文責: 熊谷峻）

Group Report of 2019 SISP

- 10 -

Group Number 10-D

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

3.4

機能

実際に利用するミュージシャンのユーザストーリーに沿ってアプリの機能を述べる．はじめに，
ユーザはライブを行う地点にて電子楽器を規定のデバイスを経由してスマートフォンにつなぐ．そこから配信用アプリを起動して配信の内容設定，範囲などの指定を行い，Bluetooth 機能によるスマートフォンのビーコン化を行う（図 3.1.A）．このときに演奏をおこなうことで視聴用アプリを起動したユーザが聞くことができる．視聴するためのアプリは演奏者のビーコンの受信範囲内にはいることで通知を行う．その通知を開くことによって演奏者の配信する演奏を聞くことができる（図 3.1.B）．これにより，路上ライブの音量ある状態を避けつつライブを楽しむことが可能になる．ライブという形であるため，聞き手はリアクションをアプリから通して行い，配信者にも届く形になる．演奏を聞くためにヘッドホンをしていても届くため演奏中でも一体感を出すことができる．この時興味のない人は人混みがあるということ以外は静かであり，素通りしやすい形になる（図 3.1.C）．これによって音を出しにくい場所でもライブを行うことができ，加えてライブ感の多くを損なわずに臨場感を残すことができる．聴いているユーザは演奏者に対して，アプリを通して
拍手や手拍子などを伝えることができる（図 3.1.D）．これが函ライブが提供できる機能であり，想定したユーザストーリーである．
（※文責: 斉藤由樹）

図 3.1 ユーザストーリー

Group Report of 2019 SISP

- 11 -

Group Number 10-D

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

第4章

開発

4.1

技術習得

4.1.1

環境準備

• Slack
オンラインのコミュニケーションツールとして Slack の導入を行った．Slack はビジネス向
けチャットツールでありチーム別，プロジェクト別，顧客別など，組織ごとに適したスタイ
ルのチャンネルを作成できる．教員やメンバーのやりとり，ファイルの共有に利用した．

• Google ドライブ
Google ドライブは Google が提供するオンラインストレージサービスである．本プロジェ
クトではファイルの共有やプレゼンを行う際に利用した．

• Whereby
Whereby はオンライン通話サービスの 1 つである．音声や映像を利用して複数人でのビデ
オ通話を行うことのできるサービスである．4.2.1.2 章のデイリースクラムにて現地集合が行えない際に利用するため導入した．

• Git
Git は分散型のバージョン管理システムのことであり，ソースコードの変更履歴を記録・追跡するツールである．これによって，編集したファイルをもとに戻すことや，編集した履歴を残して確認することが容易になる．また，branch という機能によって平行した作業を行うことが可能になる．

• GitHub
GitHub はソースコードのホスティングサービスである．リモートリポジトリを共有することが可能で，メンバー間でソースコードやファイルを共有しながらの開発を行うことができる．また，ソースコードの相互レビューを行いやすく，プロジェクト活動を円滑に行うことができる．

• Docker
Docker は OS レベルのコンテナ型の仮想環境を提供するソフトウェアである．完全仮想化を行うハイパーバイザ型に比べディスク利用量が少ない．また，起動や作成が早いため実行
環境を構築しやすい．本プロジェクトでは初期にサーバのテストをする際に PC 上でサーバを利用するために導入した．

• Swift
Swift は iOS を利用する際に使われる言語の一種である．ネイティブアプリを開発することが可能で，Objective-C に比べ学習をしやすい言語である．本プロジェクトではモバイルア
プリケーション側の開発に導入した．Swift をコンパイルするために Xcode を Mac に導入している．利用したバージョンは 10.1 である．

• Go
Go は簡潔に描きやすく，軽い並行処理によってマルチコア環境において構築が行いやすい
コンパイル言語である．サーバ側の管理にて導入した．

Group Report of 2019 SISP

- 12 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
• Nginx
Nginx はオープンソースの Web サーバである．主に静的コンテンツを高速で配信するために利用される．Web アプリケーションサーバを配置して動的なコンテンツを配信することも可能である．今回のプロジェクトではストリーミング配信を行う最に利用する外部モ
ジュールの導入のために導入した．
（※文責: 斉藤由樹）

4.1.2

各メンバーに課した課題

夏休み期間に上記の環境を利用して各々開発のための技術習得を行った．ここでは各メンバーが課されていた課題を記載する．

• 渡邊慎太郎
Go のチュートリアル，サーバ準備• 吉川綾乃AppleDeveloper 公式の Swift チュートリアル，かんたんなクイズアプリ• 斉藤由樹別 Swift アプリの開発• 熊谷峻
Swift 参考書（Swift によるじゃんけんアプリ制作，mp3 再生可能なアプリ開発），Go 言語習得
渡邊慎太郎はサーバサイドを担当するため，実際に運用するサーバ側の準備を行った．サーバを運用するために利用する言語の Go のチュートリアルを実際に学んでいる．吉川綾乃はユーザーサ
イドを担当するため，iOS の開発に必要な Swift の扱いを学び，インターフェースの扱い方などを学ぶことのできるクイズアプリを実際に作り学んでいる．斉藤由樹には別で開発している Swift 利用のアプリ開発を継続させている．今回のアプリ開発で利用する言語の内容をその中で得られるため継続した．熊谷峻は，Swift の参考書と Go の両側を学習した．音楽再生に必要な機能や Swiftの機能の確認，サーバ側の Go 言語についても学習している．
（※文責: 斉藤由樹）

4.2

開発手法

4.2.1

導入した手法

4.2.1.1

アジャイル開発

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

Group Report of 2019 SISP

- 13 -

Group Number 10-D

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

スクラム

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

4.2.2

開発の流れ

開発するにあたり，本サービスでは 1 週間で 1 スプリントを回した．デイリースクラムの頻度
は，平日の 12 時 40 分から行い，Whereby というツールを用いてリモート参加にも対応させた．
デイリースクラムを行う際，「やったこと」「困ったこと」「次やること」の 3 つの項目について各々報告を行った．毎週水曜日に実施したレトロスペクティブに関しては，最初の数スプリントはKPT を使用し，次の数スプリントでは FDL を使用し，最終的に KPT と FDL を組み合わせた方法を使用して活動の振り返りを行った．KPT とは，仕事や活動内容を「Keep (成果を出ているので継続して行うこと)」，「Problem (問題があるため改善が必要なこと)」，「Try (新しく取り組むべ
きこと)」の項目で検討を行い，次のスプリントの方針を決定する方法である．FDL とは，「Fun(楽しんだこと)」，「Done (やったこと)」，「Learn (学んだこと)」を検討して次のスプリント方針を決定する方法である．最初に KPT から FDL へ変更を行った理由は，レトロスペクティブというよりも，デイリースクラムのようになっているという理由と P (問題) と T (改善すべきこと) が多
く，続けることが困難だと感じたからである．FDL から，KPT と FDL を組み合わせた手法へ変更した理由は，FDL のみであると，新たに取り組むべき課題や継続して何を行うべきかという項
目が無いため，次のスプリントの方針やプロダクトバックログの変更や新たにタスクを追加することが難しいと感じたからである．その後，他サービスの面々を含めてデモを行ってレビューをもらい，次のスプリントでの開発に活かした．
（※文責: 渡邊慎太郎）Group Report of 2019 SISP

- 14 -

Group Number 10-D

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

4.2.3

効果, 課題, 解決策

4.2.3.1

効果

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

4.2.3.2

課題

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

4.2.3.3

解決策

上記の 4.2.3.2 節で挙げられた課題を解決するために次のような対策を行った．まず，1 つ目の課題であるデイリースクラムへの遅刻に対する対策として，原因は，主にメンバーの寝坊やど忘れによるものが多かったため，デイリースクラムを行う日の前日や朝にリマインドを送ることで忘れGroup Report of 2019 SISP

- 15 -

Group Number 10-D

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

Group Report of 2019 SISP

- 16 -

Group Number 10-D

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

第 5 章 システム仕様
5.1

システム構成函ライブは，モバイルアプリケーションとサーバサイドアプリケーションの 2 つから構成されている（図 5.1）．モバイルアプリケーションは iOS 端末向けのもので，電子楽器での演奏を配信する機能や，演奏者の近く（ビーコンの電波を受信できる範囲）にいる演奏者の演奏を聞くことができる機能などを提供する．サーバサイドアプリケーションでは，演奏者のプロフィールや，演奏者のスマートフォンから発信されるビーコンの UUID をデータベースを用いて管理する配信管理
サーバと，配信している演奏者の演奏データを管理するストリーミングサーバの 2 つから構成されている．
演奏者が，配信を開始する際，モバイルアプリケーションからプロフィールと，UUID を配信管理サーバに送信する．UUID はモバイルアプリケーションがビーコンの電波を発信する時に使用するもので，モバイルアプリケーション側で自動的に設定する．サーバがプロフィールと UUID を受信したら，配信に使用する配信キーをモバイルアプリケーションに送信する．演奏者が配信を開始すると，モバイルアプリケーションはストリーミングサーバに配信キーを使用して，演奏データを配信する．それと同時に，モバイルアプリケーションは，ビーコン電波を周囲に発信する．
聴き手が演奏を聴く場合，配信管理サーバから配信者一覧を取得する．この時，配信者の UUID，
プロフィール，配信キーがサーバから送信される．聴き手は，その中から聴きたい演奏者を選ぶ．
モバイルアプリケーションは，その演奏者の配信キーで，ストリーミングサーバに接続する．聴き手のスマートフォンが演奏者のスマートフォンを受信できた時のみ，聴き手は演奏を聞くことがで
きる．

図 5.1

システム構成（※文責: 吉川綾乃）

5.2

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

モバイルアプリケーションは，Swift と Xcode を用いて開発を行った．モバイルアプリケーションの機能としては，大きく 5 つの機能がある．演奏者の演奏を配信する機能，近くの演奏者の演奏を視聴する機能，演奏者のプロフィール機能，演奏者にいいねを送る機能の 4 つである．

Group Report of 2019 SISP

- 17 -

Group Number 10-D

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

5.2.1

演奏者の演奏を配信する機能

演奏者がスマートフォンに iXZ を介して電子楽器を接続する．iXZ とは，iPad/iPhone/iPodtouch/Android デバイス用マイク/ギターインターフェースである [3]．今回，電子楽器の演奏を
マイクの入力として受け取るために，iXZ を使用した．演奏者が，「配信する」ボタンを押すと，マイクから入力された演奏データをサーバに送信する．
この時，配信するだけでは，演奏者は自身の演奏を聴くことができなかったため，マイクで入力された音を，そのまま出力する機能を作成した．これによって，演奏者は iXZ に繋いだイヤホンやヘッドホンから，自身の演奏を聞くことができる．

5.2.2

近くの演奏者の演奏を視聴する機能

この機能は，路上ライブの良さである，限定性を損なわないために実装した．演奏者のスマートフォンから，ビーコンの電波を発信する．そのビーコンの電波を受信できるユーザのみが，アプリを通して演奏を聴くことができる．

5.2.3

演奏者のプロフィール機能

プロフィールの内容としては，演奏者の名前，自由に書き込めるプロフィール，曲のジャンルの 3 項目となっている．演奏者が配信を開始する前に，自身のプロフィールを編集をする．聴き手
は，配信している演奏者一覧を見る時，演奏を聞いている時にプロフィールを確認できる．特に，演奏を聴いている時に表示するプロフィールは，セミモーダルビューを使用して，常に全て表示するのではなく，必要な時のみ全体を見ることができるようにした．

5.2.4

演奏者にいいねを送る機能

函ライブでは，路上ライブとは異なり，演奏者は聴き手をはっきりと認識することはできない．
そのため，聴き手からのリアクションとして，いいねを送信する機能を作成した．これによって，聴き手は演奏者にプラスの感情を伝えることができ，演奏者はプラスの感情を持った聴き手がいる
ことを確認できる．

5.2.5

導入ライブラリ

ライブラリの導入には，CocoaPods を使用した．使用した CocoaPods のバージョンは，1.8.4である．使用したライブラリをいかに示す．

• MobileVLCKit
メディアプレイヤーの VLC エンジンの libVLC のラッパーである [4]．AVFoundation でサポートされていない形式のメディアを再生するために必要となった．演奏を受信するために使用した．使用したバージョンは 3.3.6 である．

• HaishinKit
RTMP，HLS の形式に対応しているカメラとマイクのストリーミングライブラリである[5]．演奏を配信するために使用した．使用したバージョンは 0.10.6 である．
• SwiftGifOrigin
Group Report of 2019 SISP

- 18 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
UIImage を拡張し，GIF 画像に対応させたライブラリである [6]．ボタンに使用していた，
GIF 画像を表示するために使用した．使用したバージョンは 1.6.1 である．
• FloatingPanel
UI コンポーネントであるセミモーダルビューを使うことができるライブラリである [7]．プ
ロフィールの表示に用いたセミモーダルビューを実現するために使用した．使用したバー
ジョンは 1.7.0 である．
（※文責: 吉川綾乃）

5.3

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

5.3.1

概要

函ライブでは演奏者と聴き手の通信を行うストリーミングサーバと，演奏者の情報と配信に必要なストリーミングキーを管理する API サーバを開発した．
（※文責: 渡邊慎太郎）

5.3.2

Players モデルに関する API

開発には Go および Go 用の ORM ライブラリである GORM を用いた．言語に Go を採用したのはプロジェクト全体でサーバサイドの言語を Go で統一したためである．GORM を採用したのはデータベースとの接続を楽に行えるからである．函ライブのデータベースは Players テーブルが存在する．テーブルの内容は以下の通りである．
表 5.1 Players テーブル

カラム名

型

概要

uuid

string(主キー)

演奏者の UUID

key

string

演奏者のストリーミングキー

namestring

演奏者の名前

proﬁlestring

演奏者のプロフィール

genre

integer

演奏者が演奏する曲の得意ジャンル

good

integer

演奏者がいいねされた回数• GET /live/list
演奏者の iBeacon の UUID，演奏者のストリーミングキー，演奏者の名前，演奏者のプロ
フィール，演奏者が演奏する曲の得意ジャンルがリストの JSON 形式で返ってくる．

• GET /live/list/:uuid
データベースに登録されている UUID と紐付いている演奏者のプロフィールといいねの数，演奏者が演奏する曲の得意ジャンルが JSON 形式で返ってくる．

• GET /live/good/get/:uuid
データベースに登録されている UUID と紐付いている演奏者のいいねの数が JSON 形式でGroup Report of 2019 SISP

- 19 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
返ってくる．

• GET /live/good/add/:uuid
データベースに登録されている UUID と紐付いている演奏者にいいねを追加した数がJSON 形式で返ってくる．データベース上では，その演奏者のいいねの数が 1 増えた値が保存される．

• POST /post
string 型の uuid，string 型の name，string 型の proﬁle，integer 型の genre を JSON 形式
でポストするとデータベースに保存される．この時，サーバ側でストリーミングキーは自動生成される．genre がなかった場合はデフォルト値で 0 が保存されるようになっている．

• DELETE /live/delete/:uuid
データベースに登録されている演奏者の UUID と指定した UUID が一致した演奏者の情報が削除される．
（※文責: 渡邊慎太郎）

5.3.3

ストリーミングサーバ

ストリーミングサーバとはファイルをダウンロードさせながら同時に再生を行う技術を用いることにより，ネットワークを通して映像や音声などのマルチメディアファイルの配信を行うサーバのことである．開発するにあたり Nginx の外部モジュールである nginx-rtmp-module を用いて，RTMP サーバを構築した．RTMP サーバを採用した理由は開発するにあたり，ドキュメントが多く存在したことと，サーバ側での構築が容易であったためである．
（※文責: 渡邊慎太郎）

5.4

デザイン

5.4.1

アプリデザイン

チームメンバーでサービスのイメージカラーとして決めた黄緑色 (#38b48b)（図 5.2）を主に用いてデザインをした．直感的な操作が可能になるように，シンプルかつ分かりやすいデザインにしている．例えば，文字だけの UI では操作性が悪くなってしまうため，画像や GIF を多用したデザインにすることで，視覚的にも直感的にもわかりやすい UI デザインにしている．特に，本アプリのメニュー画面では演奏するか，演奏を聴くかの選択をでき，演奏する方のモードのボタンは電子キーボードを指で押している GIF を，演奏を聴く方のモードのボタンはヘッドホンの間にオーディオスペクトラムが波打っている GIF を設置しているため，一目でモードがわかるようになっている．加えて，ボタンの判定も GIF 全体に合わせているため，ユーザが直感的に GIF を押しても画面遷移するようにしている．さらに、最近のアプリで見るようになったセミモーダルビューを用いることで，知りたい情報を簡単に知ることができ，かつ操作を楽しめるようなデザインとなっている．具体的には，演奏を聴いている時に画面下部に演奏者の名前を表示しており，その名前をタッチすると，演奏者の演奏予定の曲や一言を見ることができるようにしている．また，聴きたい演奏者を選択する画面では，近くの範囲にいる演奏者の名前をリスト表示することで，聴き手が聴きたい演奏者を簡単に選べるようになっている．最後に，聴き手がライブの配信を再生しているこGroup Report of 2019 SISP

- 20 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeとを認識できるように，再生中にはオーディオスペクトラムが波打ち，逆に停止中にはオーディオ
スペクトラムも停止するようにするにした．同様に，演奏者側も，ライブ配信をしていることが認識できるように，配信中には電波が飛んでいる GIF を配置し，逆に停止中には電波も止まっている画像が配置されるようにした．
（※文責: 熊谷峻）

5.4.2

サービスロゴ，アプリアイコン

ロゴおよびアイコンを作成するにあたり，本サービスの特徴を伝えるには何が必要かを考えた．
本サービスは「音楽を無音で届ける」ということを主としたサービスであり，その要素を表現する
ために，音楽の象徴である音符に音をミュートしているような斜め線を入れ，それを配信することを表す電波を添えることで, 本サービスの特徴を再現した（図 5.3）．色は本サービスのイメージカ
ラーである黄緑色 (#38b48b)（図 5.2）を主軸とした．

図 5.2

テーマカラー

図 5.3 アプリアイコン（※文責: 熊谷峻）

5.5

インフラストラクチャー

本サービスのストリーミングサーバおよび API サーバを運用するためのクラウドコンピュー
ティングサービスとして Google Cloud Platform (GCP) を採用した．GCP とは，Google がク
ラウド上で提供するサービス群の総称である．GCP を用いることで仮想マシンやデータベースなどを従量課金で使用することが可能となる．本サービスでは GCP のサービスである Google

Compute Engine (GCE) を使用した．GCE とは，仮想マシンと呼ばれる仮想的なコンピュータを提供するサービスである．用途に応じた仮想マシンを選択できる．本サービスでは，リージョン
を東京，マシンタイプは n1-standard で設定した．リージョンを東京にした理由は，ストリーミン
グをする際の遅延を少なくするためである．マシンタイプを n1-standard にした理由は，マシンのスペック面でストリーミングの実行時に本サービスを滞りなく運用できる性能であったからである．今回は Nginx の外部モジュールである nginx-rtmp-module を使用したストリーミングサーバと Go で作成した API サーバ，データベースサーバである MySQL サーバを用意した仮想マシン上に構築した．
（※文責: 渡邊慎太郎）Group Report of 2019 SISP

- 21 -

Group Number 10-D

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

第6章

外部評価

6.1

中間発表

6.1.1

発表形式

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

6.1.2

発表技術の評価と反省

発表技術に関しての高評価な意見として• 活動内容がわかりやすかった• スライドが明確でわかりやすいなどがあり，時間内に聞き取りやすい説明を行うことができ，サービスの内容について理解してもらうことができた．低評価な意見として• 声が小さくて聞き取りづらかった• スライド発表はスライドに書いてあることしか言ってなかった• デモがないのが残念だなどがあり，満点を 10 点とした評価の平均評価は 7.81 であった．以上のことから，発表する際にはデモを用意したり，スライドに書いてあることに付け加えた説明などを入れたりする必要がある
ことが分かった．
（※文責: 熊谷峻）

6.1.3

発表内容の評価と反省

発表内容に関しての高評価な意見として• 路上ライブが不利な場所でもできるところがよい• 実現したら利用してみたいGroup Report of 2019 SISP

- 22 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeなどがあげられた．低評価な意見として• ライブ感が薄れそう• 異様な光景になりそう• ユーザ側の手間が多そうなどがあげられ，満点を 10 点とした評価の平均評価は 8.10 であった．以上のことから演奏者側の魅力は伝わったが，聴衆側の魅力があまり伝わらなかったことが分かった．よって，演奏者側だけ
でなく，聴衆側のメリットも具体例を入れた説明をするべきだったと考えられる．また，ユーザの手間をなるべく減らせるようなシステム開発が必要だということが分かった．
（※文責: 熊谷峻）

6.2

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

公立はこだて未来大学では 2019 年 8 月 4 日にオープンキャンパスが開催された．本プロジェク
トでは，オープンキャンパスのイベントの 1 つであるインタラクティブ展示にて，「ここにいる人だけ」コミュニケーションとして出展した．出展にはプロジェクトのメンバー 8 人が参加し，中間発表時に使用したプロジェクト全体のポスター 1 枚と各サービスのポスター 4 枚，昨年度のプロ
ジェクトのサービスのポスター 2 枚，その昨年度のサービスが体験できるデモを用意した．今年度のサービスは，オープンキャンパス開催時にはまだ実装ができていなかったため，昨年度のサービスを用いることで来場者にビーコンを用いたサービスを体験していただくことができた．今年度のサービスについては，興味を持った方に向けてサービスの概要や機能について簡単にポスターセッ
ションを行った．
（※文責: 大野和也）

6.3

HAKODATE アカデミックリンク 201911 月 9 日に函館にて，はこだて高等教育機関合同研究発表会アカデミックリンク 2019 にみみう
ちと合同のブースで出展した．HAKODATE アカデミックリンクは函館市内の大学，短大，高専を集めて市民や地元企業へと披露し，研究のテーマ同士の協力や連携の可能性を図るためのイベン
トである．こちらのイベントに本プロジェクトの 4 チームを 2 ブースに分けて出展し，参加した．
（※文責: 斉藤由樹）

6.3.1

手段

基本スタイルはポスターセッションにて，各サービスのポスターを用いた説明の後に，その時点まで実装されていたサービスのデモを行う形であった．ポスターを用いた説明では，本イベント用に作成したポスターを用いて，サービスの内容や今後の展望などを説明した．デモでは，受信側とサーバについてを動かし，サーバ側は既存の音楽を流す環境を整え，iPhone を持った人がビーコン範囲内にいる場合のみ視聴を行えることを行った．ポスター説明・デモの後は質疑応答や意見交換を行った．最終的に発表や懇親会なども行っている．

Group Report of 2019 SISP

- 23 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life（※文責: 斉藤由樹）

6.3.2

評価

デモ後に頂いた意見や質疑について，• 今までにない体験のため人の集め方に苦労しそう• 若い人には流行るのではないかというものが上がった．集め方に苦労しそうであるという点は，路上ライブであるにも関わらず無音ということが大きいと考える．人だかりが生まれればそこに何かがあることがわかるが，人が集
まらなければ練習風景にしか見えない可能性もある．視聴する顧客を集めるために集客をするための手段が必要だと感じた．人は情報を得るために五感を使うことが多く直接五感の 1 つを感じ取れない状態で売り込みをすることは難しいが，視覚に対して圧をかけることができれば人は伸びると考えられる．若い人に流行るのではないかという点はまさしくビーコンといった技術を使い目新し
い方法で路上ライブをするからだろう．これまでにない活動を生み出すということは苦難があることは間違いがない存在であるため，今までにない視点からのアイデアも必要となってくるものだろう．そのために「現在は馴染んでいるが今までになかったもの」のアイデアを見ていくことも発想力を鍛えるというにはよいものかもしれない．
（※文責: 斉藤由樹）

6.4

青森市学生ビジネスアイデアコンテスト （Aomori

Business Challenge GATE）〜青函ツインシティ 30th
Anniversary〜
6.4.1

ビジネスアイデアコンテスト

ビジネスアイデアコンテストとは，参加者が様々なビジネスモデルを考え，プレゼンテーション
して競い合うコンテストのことで，一流企業や学生団体，多くの地方自治体なども主催しており，テーマも様々である．コンテストで優勝や入賞したビジネスモデルには実際に事業を行うための資金や設備などのサポートが提供されることもある．今回は青森公立大学との連携ワークショップの一環として青森市学生ビジネスアイデアコンテストに参加した．
（※文責: 渡邊慎太郎）

6.4.2

準備

ビジネスアイデアコンテストに出るにあたり，前期に決めたユーザーストーリーだけではビジネ
スアイデアコンテストに応募するために満たさない「提供場所」や「提供方法」，「提供価格設定」，「収支見込」等の項目が存在したためアイデアを改善した．例えば，「提供場所」の項目を満たすにあたり，地方で問題となっているシャッター街やショーウィンドウの空きスペースのような，使われていない場所を有効活用することを考えた．また，提供価格設定や収支見込等を考える際，前期Group Report of 2019 SISP

- 24 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeに考案したアイデアでは支出や収入などの費用面についてを考えていなかったため大変苦労した．
理由として，メンバー全員が起業や商売に関する知識が不足していたためである．そこで，メンバーで集まり知識の共有を行いつつ議論を進めた．議論では，まずは誰がステークホルダーである
かと初期費用がどれくらいかかるかを定めた．ステークホルダーを決めないと需要や供給がどこにあるかが分からなくなるからである．本サービスのステークホルダーは「演奏者」，「店舗の管理人」，「演奏を聴く人」の 3 者とした．また，初期費用に関しては開発や運用するにかかると思われる費用と設定した．次にどのように収入を得るのかということを考えた．そこで苦労した点は，議論している時点では本サービスに収入を得られる機能が存在しなかったこと，サービスを提供する
際の妥当な設定価格がわからなかったことの 2 点であった．機能に関しては，投げ銭機能や過去のライブ視聴，音楽販売などアイデアを追加，改良を行うことで解決した．妥当な価格設定に関して
は，サービスを運用するのにかかる費用や人件費，初期費用をどれくらいで回収できるのか等を考慮して妥当だと思われる価格を設定した．ここから損益分岐点を計算し，収益予測をたてた．これ
らの内容をスライドにまとめてプレゼン準備を進めた．
（※文責: 渡邊慎太郎）

6.4.3

発表当日

発表当日は，青森市内各大学・専門学校などの学生 9 チームと，青函ツインシティー 30 周年を記念して招かれた公立はこだて未来大学を含めた函館市内各大学の学生 3 チームがそれぞれのアイ
デアを出し競い合い，「事業性」「革新性」「プレゼン力」などの観点から審査が行われた．審査は，青森市長や副市長，函館副市長などが行った．他大学が提案したアイデアは，地方創生や産業廃棄物の再利用，地方という特性を活かしたアイデアが多かった．また，本サービスとは全く違ったア
プローチをしている様々なアイデアがあり，中には実際に起業しているサービスがあり多くの刺激を受けた．加えて，情報系とは違う分野の学生との交流を行うことで，アイデアに対する視野が広がった．本サービスは他のサービスと比べてアイデアの斬新さや寸劇を含めたプレゼンテーションが評価され，Grand Prix を受賞した．
（※文責: 渡邊慎太郎）

6.5

成果発表会

6.5.1

発表形式

12 月 6 日（金）に行われた成果発表会では，スライドとポスター，開発したデモを用いて説明を行った．まず 3 分間でスライドを用いて，プロジェクト全体の説明や一年間の流れ，提案するサービスの説明を行った．その後，聴衆には気になるサービスのポスターの前に移動してもらい，
各サービスに分かれてポスターセッションを行った．函ライブのポスターセッションでは，はじめに 4 分程度で，ポスターを用いてサービスを思いついた背景や解決したい課題，提案するサービスについて説明した後，実際に 2 分ほどでデモを使用してもらった．デモでは，364 教室内で電子ピ
アノをメンバーや OB が演奏し，それをモール側で函ライブのアプリを通して演奏を聴くという形
で．その後，質疑応答を 5 分ほどで行った．
（※文責: 吉川綾乃）

Group Report of 2019 SISP

- 25 -

Group Number 10-D

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

6.5.2

発表準備

デモをするにあたり，ライブ感を損なわないでどのように相手にこのサービスを伝えるか，という所に焦点を当てて準備を行った．しかし，準備を進めるにあたり多くの問題が発生したため，以下にそれらを記述する．まず，ライブの演奏に近づけるために，演奏で音が届く範囲とビーコンの電波が届く範囲を同じくらいにするように心掛けた．そのため，iBeacon のビーコンの電波強度を最小に設定したが，想定より遠くまでビーコンの電波が届いてしまったため，電波を遮るものを用意する必要があった．今回は炊飯器の釜で代用した．次に問題となったのが演奏時の問題である．
開発メンバー内にキーボードを演奏できる者が存在しなかったため，誰が演奏するかという問題が発生した．この問題に対しては，キーボードを演奏できる別サービスのメンバーと OB の人に協力してもらうことで解決した．また，演奏が映えるようライトアップにも気を使った．加えて，発表場所とそれに伴うポスターの配置に関する問題が発生した．今回はコンピュータ教室の前を割り当てられたため，本サービスと「ゆまち」がデモの際にコンピュータ教室内も利用した．そのため，スペースを必要とするサービスが多かったためデモを行う場所とポスターの場所に気を使った．今回は本サービスが想定している「ショーウィンドウの中で演奏している」を再現するために，演奏はガラスを挟んで演奏を行った．また，他のサービスのデモや発表が互いに邪魔をしないようにデモやポスターの場所に気を配った．
（※文責: 渡邊慎太郎）

6.5.3

発表技術の評価と反省

発表技術に対しての高評価な意見としては• スライドでの発表が簡潔で良かった• 函館のまちをより良くするようなプロジェクトがたくさんあり，とても面白いと思った• デモを使いながら発表ができているなどがあり，スライドやポスター，デモを用いて，自分たちの考案，開発したアイデアについて伝えることができた．低評価な意見として• 声はもう少し大きいほうが良い• 話す内容を頭に入れて，自信を持って前を向いて話してほしい• 質疑応答の際に，いきなり否定するのではなく，一度受け止めてから提案するなどがあり，発表技術に対する評価 (1-10) の平均は，7.76 となった．発表の時は，聴き手に届くような声の大きさにしたり，事前に練習をし，話す内容を頭に入れておくこと，質疑応答の時の対応に注意すべきことが分かった．
（※文責: 吉川綾乃）

6.5.4

発表内容の評価と反省

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

- 26 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life• ビーコンの特徴を利用できている点が良い• 具体的な利用方法が考えられていた• アプリケーションがどのようなことができるのかわかりやすかったなどがあり，サービスの利用方法やビーコンを使うメリットを伝えることができた．低評価な意見
として• 各チームの内容のポイントをもう少し突っ込んでほしい• コンテンツ量が多くパンクしているなどがあり，発表内容に対する評価 (1-10) の平均は，8.61 となった．発表内容を考える時はどの
ポスターを見に行くかの判断材料を提供するために，詳しく説明をしなければいけないことが分かった．加えて，説明する内容に関して見当したほうが良いことが分かった．
（※文責: 吉川綾乃）

6.5.5

コンセプトの評価と反省

コンセプトに対しての高評価な意見としては• 道外で盆踊りの音をこの形で行っている地域があった．このような取り組みは注目されると思う• これが使われることで路上ライブを見る機会が増えるのではないかと思ったなどがあり，サイレントで音を届けるというコンセプトの良さを実感してもらうことができた．低評価な意見として• 聴く人にとってはいいが路上ライブは興味のない人に聴いてもらうためにやる人が多いので実際に使う人が少ないのではないか• 路上ライブを見かけるから立ち止まるのであって，わざわざ最初からアプリをいれるかな？
と思ったなどがあり，コンセプトに対する評価 (1-10) の平均は，8.92 となった．コンセプトとしては，実際に路上ライブをしている人に使っていただき，ユーザに評価してもらったり，最初にアプリをインストールするという導入をどのようにするかについて，考える必要があることがわかった．
（※文責: 吉川綾乃）

6.5.6

アプリケーションの評価と反省

アプリケーションに対しての高評価な意見としては• とても便利で使いやすいなどがあり，使いやすいアプリケーションができた．低評価な意見として• 音が途切れるトラブルをなくしてほしい• 遅延があるなら路上ライブに向いていないのではないか
Group Report of 2019 SISP

- 27 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life• ピアノだけではなく，歌も聴こえれば良いと思った• 演奏者とのつながりを意識できるものがあれば面白いと思ったなどがあり，アプリケーションに対する評価 (1-10) の平均は，8.38 となった．アプリケーションの技術的課題として，音が途切れるトラブルや，演奏が聴こえるまでのラグが挙げられた．また，歌声や複数楽器への対応や，演奏者にコメントを送るなど，アプリケーションを良くするためにできることは多くあることが分かった．
（※文責: 吉川綾乃）

6.6

enPiT BizSysD の北海道・東北グループ合同発表会 201912 月 14 日に室蘭工業大学にて行われた enPiT BizSysD の北海道・東北グループ合同発表会
2019 に，会津大学，岩手県立大学，公立はこだて未来大学，室蘭工業大学，北海道情報大学が参加した．北海道・東北グループ合同発表会では参加大学の学生が各々の学習成果の報告を行うとともに，他大学の学生や教員の方々と交流することを目標として開催された．本プロジェクトからは 8名が参加し，「函ライブ」からは 3 名参加した．発表形式としては，チームごとに前半・後半分かれて 1 時間ずつポスターセッションを行った．ポスターセッションでは，プロジェクトの概要を簡単に述べた後，実演奏の視聴が行えるデモを体験していただき，現状や今後についてを説明した．
数多くのポスターセッションを見ることができ，他大学の活動などを見ることで見聞を広げることもできた．ポスターセッション中や終了後の質疑応答に頂いた意見として，• ライブ感をどこに見出すか• 遅延があるように思えるといったものがあった．
ライブを行ううえで得に重要なものがライブ感である．その場にいてその場で楽しむということがどれだけ再現することが難しいかを実感した．このライブ感を生み出すために振動するデバイスなどを用いて振動を感じ取れる形をいかに作り出すか，それとも別のライブ感を模索するべきかという問題が明らかとなった．遅延についてはサーバ側の問題となり，内部での処理を変えることになる．現場でサーバを建てることが一番遅延をなくすことができるが演奏者側にかける負担が大きくなるという点が存在する．そのため，どれだけサーバ側の処理を軽くできるか考えていく必要がある．全体としてはライブを行うために必要な要素が不足していると感じた．路上ライブの内容としては臨場感やライブ感といったものを手軽に得られるというものがあるが，今回の結果からは，
リアルライブを行うにはまだ技術が追いついていないようにも思えた．ライブを円滑にするためにも，行いやすい環境整備とサーバの関係を整えていく必要が存在するだろう．
（※文責: 斉藤由樹）

Group Report of 2019 SISP

- 28 -

Group Number 10-D

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

第 7 章 各メンバーの振り返り
7.1

役割分担

本グループでは，スクラム開発手法に則り，プロダクトオーナー 1 人，スクラムマスター 1 人を決定し，4 人全員がサービス開発に関わるように，4 人のうち，1 人がデザイン，2 人がフロントサ
イドの開発，1 人がサーバサイドの開発を行った．以下はそれぞれが担当した内容である．
渡邊慎太郎• プロダクトオーナー• サーバサイドの開発• インフラ整備熊谷峻• スクラムマスター• フロントサイドの開発• XD を用いたモックアップの作成• UI デザイン考案

吉川綾乃• iOS アプリ開発• フロントサイドの開発• UI の実装• ポスター制作• ロゴ，アイコンの製作

斉藤由樹• サービスのロゴとアイコンのデザイン考案（※文責: 熊谷峻）

7.2

渡邊慎太郎の振り返り

私は 1 年間にもわたるプロジェクト学習を通して，アイデア出しからサービスの提案，開発までの一連の工程に携わることにより，様々な経験と反省を得られたと感じている．
（※文責: 渡邊慎太郎）Group Report of 2019 SISP

- 29 -

Group Number 10-D

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

7.2.1

プロジェクトリーダーとしての振り返り

私はこれまでにリーダーの経験がなかったため，アイデアの決め方やアジェンダの決め方などの，決定に関するノウハウがないため，物事を決める際に適切な行動をできなかったことや決断力がなかった点が大きな反省点である．また，アジェンダを決める際に，主にプロジェクト副リー
ダーと話し合いをして決めていたが，全体のコンセンサスを得られていなかったためプロジェクトの活動が始まるたびにアジェンダを説明するところから始めないといけなかったため大きく時間をロスしてしまったり，メンバーが何をすべきか分からないまま進めてしまい，考える機会を奪ってしまったのではないかと考えることがあった．これの解決策としては，アジェンダを考えている時
点でメンバーを何が何でも巻き込む必要があった．しかし，各メンバーの講義の時間割の都合上プ
ロジェクト時間以外で集まる時間を確保できなかったため，Slack をうまく活用できれば良かったと考える．他にも，アジェンダを考える人を毎週変えるなどもっと試行錯誤するべきであったと考える．加えて，早い段階で各チームメンバーに役割を割り振っておけばよかったと考える．役割を割り振ることで各々のメンバーが責任感を持つことが出来るからである．他にも，提案するサービスが決まっていない時点ではグループに別れていなかったため，何かをするたびに人数を分けるところから始まってしまうという問題も存在した．この点に関しても早い段階で工夫するべきであり，プロジェクトの時間が始まるときには，グループ分けが終わっているところから活動できればよかったのではないかと考える．
（※文責: 渡邊慎太郎）

7.2.2

アイデア出しアイデア出しを行っている時，自分には無い視点でアイデアが出たり，評価されたりすることが多く，自分の視野が広がったように感じた．ただ，「函館らしさ」や「ビーコンらしさ」といった要
素をアイデアに結びつけることが難しく，出したアイデアに類似したサービスが既に存在し，既存のサービスとの差別化を図ることが難しく感じることが多かった．また，出したアイデアも何か反論がでると，それ以上アイデアを練り直すことをせずに死蔵することが多かった点も反省すべき点である．これらの点は，私たちがアイデア出しに不慣れであったことと，フィールドワークからア
イデアの着想を得ることが難しかったからである．スケジュールの関係でフィールドワークを短期間で集中的に行ったが，フィールドワークを行った後にアイデア出しを行い，その後に再度フィールドワークを行った方が，アイデア出しのためのフィールドワークを出来たのではないかと考察できる．加えて，アイデアが死蔵してしまう問題に関しては練り直しを行ったり，一旦期間をおいて本当に芽がないかを確認したうえで不採用にするべきであったと感じた．
（※文責: 渡邊慎太郎）

7.2.3

開発

今回開発するにあたり，アジャイル開発手法の 1 つであるスクラムを採用しての開発を経験することが出来た．デイリースクラムによってフロントエンドとの進捗具合を確認することで，情報共有を円滑に行うことが出来たと感じた．また，KPT や FDL を用いたレトロスペクティブを行う

Group Report of 2019 SISP

- 30 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
ことにより，自分が何をどれだけ楽しみながらやったのかを客観的に確認することで自分がどれだ
け技術習得ができているのかが分かった．しかし，自身にはリアルタイムストリーミングについての知識が足りなく，ストリーミングで使われているプロトコルを調べるところから始めたため，フロントエンドも含めての技術検証を行うことが多かった．そのため，ベロシティをなかなか上げることができなく，開発を進めることが難しいと感じることが多かった．また，今回の開発においてはストリーミングを用いて実装したが，サーバを介して通信を行っているため数秒のラグが発生してしまった．そのため Bluetooth 通信などのストリーミング以外の技術についての検証が必要であったと感じた．これらの経験と反省を今後の開発に活かしたい．
（※文責: 渡邊慎太郎）

7.3

吉川綾乃の振り返り

初めて，サービスのコンセプトから開発まで連続して関わることができた．1 年間を通して，これらの事柄について考え，行動することによって，たくさんの反省点や学びを得ることができた．
（※文責: 吉川綾乃）

7.3.1

アイデア出しどのようなサービスを作るのかというアイデア出しの段階では，アイデアを妥協しないで考える
ことにより，納得するアイデアを作ることができた．一方で，自分たちが考えたアイデアの良さを伝えるということの難しさを痛感した．絵や画像などを用いたり，実際のストーリーなどを提示して，話を聞いている人がイメージしやすいような工夫が必要だとわかった．
（※文責: 吉川綾乃）

7.3.2

開発

開発では Swift を用いて iOS の開発を行った．チームでの活動を進めるにあたっての反省点としては，今までチーム開発の経験があまりなく，どのように進めていいかわからなかったことが挙げられる．そのため，GitHub を有効活用できなかった．OB に聞くなどして，モバイル担当のメンバー全員でコードを書くことができれば，チーム全員の学びも多くなったのではないかと思った．今後は，調べて解決できなかったことを，臆せずに先輩などに聞くことを意識したいと感じた．また，もう 1 つの反省点として，タスクを抱え込みすぎたことが挙げられる．上の反省点で挙げた GitHub の活用だけではなく，開発以外の仕事も抱え込んでしまった面がある．うまくタスク
量を分散させ，メンバー全員でこのチームのタスクに取り掛かれるような工夫について考える必要があると思った．加えて，後半に行くに連れて，開発手法についての意識が弱くなってしまったこ
とも，反省点として挙げられる．振り返りのときに，もっと自分たちの活動について客観的な視点で反省できれば良いと思った．
チームでの開発を踏まえて，定期的に確認する場を持つことの大切さを学んだ．デイリースクラ
ムやスプリントレトロスペクティブの時間で，対面で話すことによって，お互いがどのような状況なのかについて知ることができ，1 週間でどこまで進めなくては行けないのかについて把握でき

Group Report of 2019 SISP

- 31 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeた．定期的なスパンで，お互いの進度を確認することによって，プロジェクトの進度を把握することができ，対策を考えることができた．また，コミュニケーションの場を定期的に設けることにより，その人の状態がどのような状態なのかを把握することができたため，コミュニケーションの大切さを実感した．これからのプロジェクトでは，定期的な確認やコミュニケーションを大切にしていきたいと思った．
（※文責: 吉川綾乃）

7.3.3

副リーダーとして

また，私は，プロジェクトの副リーダーとして，1 年間活動してきた．サークル活動でのリー
ダー経験はあったが，初めて体験する内容，メンバーでの副リーダーは異なる難しさがあった．
難しかったこととして，一人一人のメンバーとの関係を築き，それぞれの性格や様子を把握することがある．特に初対面から関係を築いていくのが難しく，自分自身のコミュニケーション能力の不足を実感した．今後，初対面の人と話す機会があれば，積極的に話しかけるなどの努力を重ねていきたいと思う．
さらに，プロジェクトを進行するためにアジェンダやスライドを作成した．特にプロジェクト序盤のアイデア出しのアジェンダでは，リーダーと，どのような方法で行えばアイデアを考えやすいのかを話し合った．なかなか納得のいくアジェンダが思いつかず，時間をかけて話し合った．この時，主にリーダーと 2 人でアジェンダを検討していたが，もっと多くのメンバーを巻き込んでいれば，方法に対しての感想や意見を聞くことができたと考える．それを踏まえて，後期のアジェンダ
は多くのメンバーに見えるところで検討していた．それによって，メンバーや OB から，こうしたほうがいいという意見をもらうことができ，アジェンダを検討するのが容易になったと感じた．
今後は，進行など全体に関わることは，メンバーを巻き込みながら決められると良いと感じた．また，スライドでは進め方を説明する時に活用した．アジェンダの文字や話だけでは伝わらない情報
を，図形やイラストを用いて説明することができるので重宝した．今後も，複雑な説明をする時はスライドを活用していきたいと思う．
加えて，開発の準備段階で，私がプロジェクト全体にアジャイル開発やスクラムについての説明を行ったことがあった．私もスクラムの経験はなく，本を読んだり調べたりしただけの知識だった
ので，メンバーにあまり理解してもらえなかった．このことから，自分が理解していないものに関して説明をする時は，メンバーにも事前に調べてきてもらったり，知識のあるメンバーや OB に頼ることが必要であると感じた．
最後に，スケジュール管理の面でも難しさを実感した．特に，最終報告書の執筆は，個々人の執筆しなければいけないページ数を誤って認識していたため，締切が近くなった段階で，大幅な書き足しが必要であることが判明した．あらかじめ確認を取っておけば，この問題は未然に防げたと思う．このことから，提出要項などに曖昧な表現があった場合は，自分にとって都合の良いように解釈するのではなく，確認を取ってはっきりとした定義に置き換える必要性があると感じた．また，どのような場合でも，スケジュールに余裕をもって終わらせていれば，精神的に余裕を持つことができると考える．であるから，余裕を持って先を見通したスケジュール管理というのを意識してい
きたいと思う．
（※文責: 吉川綾乃）

Group Report of 2019 SISP

- 32 -

Group Number 10-D

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

7.4

斉藤由樹の振り返り

PBL の活動を行った中で，チーム開発の手法を深く学び直すことができた．その過程でもっとも難航したものは自身のできるできないの再把握である．これが深くできないことによりプロジェ
クト全体に対して多大な負荷をかけてしまった．自身の取得技術として「はこだてマップ plus」による Swift 開発経験があるが，1 画面ごとの開発にとどまっていたため画面遷移についての内容を理解しきれていなかった問題があった．こちらの習得が行いきれず，別部分の担当に再割り振りとなるまで後期の活動にて成果を出せていなかった．技術のできるできないの部分については確実にわかる形にしておく必要があると感じた．わかるのであれば開発に参加ができるうえ，教えることができるのでわからない人に対しても技術習得を行えるものである．加えてわからない場合でも習得までの期間がわかるという利点がある．技術的な面での活動を行うには知識の運用が大事だと感じた．また，スクラムによる開発は今回が初であり，細かいスパンでの開発を行えていたと思う．
しかし見直しに関してはもう少し早くから全体で合わせられる点もあったと思い，自分からの進言も足りてないと感じた．積極的な活動は何を行ううえでも重要だと再認識した．最終的に外部活動での支援やアイコン案などの開発の外の部分を扱うことが増えており，はじめの時点で裏方部分の知識を深めていけば開発を円滑にすすめる助けになったと感じる．これらの PBL での学習経験を用いて開発に携わる際の参考にしていきたい．
加えて，自身の活動を行う中での時間のとり方というものに多大な問題を感じた．プロジェクト学習という枠組みの中だけでなく，通常の学習においてもペースや自分の出来不出来の判断に疑問を覚える事が多い．これまでの学習の中で改善はされているが未だに社会活動に適したレベルであると感じることは少ない．活動を行う中で複数の内容を進めるのではなく１つの連続したものとして捉えることが重要だと感じるが，他の時間の決まった活動との兼ね合いで次々と後送りとなり締
め切りや必要な時間の手前まで作業を引っ張る様子を改善したとしても，次の区間では再び元に戻っている．ここまで来る場合，個人的な人間性に問題があると考えられる．自身の生活は決まった時間に活動することや連続的な活動を行うことでその内容について深めるというものであるが，通常は別々の講義を受けることや別の活動を行うことになるため集中力などを別の方向へ利用している可能性がある．１つのことを突き詰める状況であれば実際に活躍できるあたりこの可能性は高い．この PBL 学習の中でもあったとおり，１つの内容に対して突き詰める場合に完全に詰まる可能性も存在する．このような場合の検索能力，解決能力を深めることも短時間で確実に集中を切らすことのない活動を行う条件となってくるだろう．
（※文責: 斉藤由樹）

7.5

熊谷峻の振り返り

今回のプロジェクトでは，前期はアイデア出し，後期は開発を主に行ったが，私個人としては開発よりもアイデア出しの方が苦労したと感じる．まず，アイデアを出すには何かしらの課題を見
つ けなければならなかったが，その課題を見つけるのすら大変だった．函館市内の様々なところをフィールドワークという形で巡り，そこで感じたことや，見つけたことなどをとにかく書き出してみたが，アイデアにつながるようなものが思ったよりも出なかったため，他のプロジェクトメン
バーも詰まってしまっていてとても大変だった．フィールドワークをする前にフィールドワーク

Group Report of 2019 SISP

- 33 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeについてのレクチャーを受けたが，それを活かすことができなかったのが反省点だったと思う．その後に，それを解決する手段を 考えることに苦労した．フィールドワークから見つけられた課題をアイデアに昇華するためにいろいろな方法を試したが，どれも中途半端な結果になってしまい，
期限ギリギリまでアイデアを決めることができなかった．最後に，企業の方々に絞り込んだアイデ
アをプレゼンして評価をもらった．アイデアがまだ固まりきってはいなかったが，一番アピールしたいところはアピールすることができた．このアイデア出しを通して，課題や解決策を発見する力
や，他の人に自分のアイデアを伝える力を身につけることができたと考える．
後期の開発では，私は主にスクラムマスターとして，チームメンバーのサポートを行ったが，こちらも自分の思った通りにはいかなかったことが多々あった．スクラムマスターの役割としては，チームが持続可能なペースでプロジェクトを進められるように支援したり，チームメンバー同士のコミュニケーションを促したり，スケジュール管理をしたりする．しかし，スケジュールの管理がうまく いかず，1 スプリント内でタスクを消費しきれなかったり，チームメンバーのモチベー
ションが保てず，チームのベロシティがなかなか上がら なかったりなど，スクラムマスターとしてチームをサポートすることの大変さを身に染みて感じた．特に，スケジュール管理に関しては，
所属コースの違いや，講義によって全員の予定を合わせることが難しく，うまく支援を行うことができなかった．しかし，開発が後半になるにつ れて，自分たちの能力を正確に把握できるようになり，チームメンバー同士のコミュニケーションを盛んに行うことができ，チームのベロシティを上げることができた．結果として，ユーザストーリーを損なわないアプリケーションを作ることができたと考えている．今回開発したアプリケーションは遅延が発生してしまったり，使い続けているとアプリケーションが落ちてしまったりといった課題が残っているが，プロジェクト学習を通して，チームを組んで開発することに対する自信をつけることができた．今回のプロジェクトではス
クラムに対する経験をしたことがある人がいなかったために，チームを引っ張っていける人がおらず苦労した場面が多々あったため，次にスクラムに携わることがあれば，またスクラムマスターとしてチームのスケ ジュール管理について特に力を入れ，より効率的な開発をできるように引っ張っていける人材になれるよう頑張りたいと思う．
（※文責: 熊谷峻）

Group Report of 2019 SISP

- 34 -

Group Number 10-D

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

第 8 章 まとめと展望
8.1

前期の振り返り本プロジェクトはビーコンを使って函館のまちをより良くするという目的で活動を開始した．前期の活動では主に「ビーコンについての学習」，「ロゴ制作」，「アイデア決め」を行った．
「ビーコンについての学習」では，まずビーコンについての特徴と活用事例を調べ，プロジェク
トメンバー全体での共有を行った．メンバー全体で共有することによってビーコンについての理解を深めることができた．
「ロゴ制作」ではまずメンバー全員がロゴ案を考え，そのロゴの意味などを全体で発表を行った．
発表後にメンバーや教員にレビューをもらい，そのレビューをもとに修正を行った．その後，投票を行うことにより案が絞られた．この工程を何度か繰り返し，ロゴ案が決定し現在のロゴが作成されるに至った．「フィールドワーク」ではまず，南部准教授によりフィールドワークに関する講義を受け，フィールドワーク中の注意点やインタビューする際に気をつける点などを学習した．次にフィールドワークをする場所を決めるために，KJ 法によるアイデア出しにより決定した．決定した場所は，五稜郭地区，赤川地区，湯の川地区，西部地区である．各々がフィールドワーク中に気づいた点や感じた点などを Slack 上に写真やメモで残し，フィールドワークによる調査の結果を共有するために，付箋に書き出して模造紙に貼り付けた．
「アイデア決め」では，フィールドワークでまとめた模造紙をもとに BSKJ 法によってアイデア出しを行い，OST で出したアイデアに対して話し合いを行うことによってアイデアを絞りこんだ．
絞りこんだアイデアごとにメンバーがアイデアのブラッシュアップを行いスライドにまとめて，函館市異業種交流会や，Tangerine 株式会社，トランスコスモス株式会社に向けて発表を行って，各
アイデアごとに「函館らしさ」「ビーコンらしさ」
「新規性」
「継続性」
「必要性」の 5 つ評価項目をもとにレビューをもらい，評価が高かった「去りし想ひを乗せゆきて」「ゆまち」「みみうち」「函ライブ」の 4 つアイデアを開発することが決まった．
中間発表では全体ポスターと「函ライブ」についてのポスターの展示と発表を行った．ここで得たサービスに関する意見をもとに，アイデアの修正を行った．そして後期の開発に活かした．
（※文責: 渡邊慎太郎）

8.2

後期の振り返り後期は中間発表会で貰った意見や中間報告書執筆時に決定した機能を踏まえたうえで，開発を始めた．今回はアジャイル開発手法の 1 つ，スクラム開発を行った．開発環境は，MacOS の

Xcode11.3.1 を使用し，Swift4 と Go 言語を用いた．スクラム開発をすることで，他の開発手法に比べて仕様の変更や各メンバーの状況に応じて柔軟に対応できた．そして，函館市内の教育機関が集まる合同研究発表会である HAKODATE アカデミックリンク 2019 や，ビジネスモデルを提案し，その優劣を競う青森ビジネスチャレンジゲートなどに参加し，サービスに対するレビューを貰った．その後，貰った意見をもとに修正を重ねつつ，ポスター作成と発表練習を行い，成果報告
会において本サービスの最終発表を行った．また，12 月 14 日の enPiT BizSysD 北海道・東北グGroup Report of 2019 SISP

- 35 -

Group Number 10-D

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
ループ合同発表会 2019 でプロジェクト内の enPiT 履修生が各サービスのプレゼンテーションを行った．ここで貰った意見を元にさらに修正し，秋葉原での発表準備を行った．
（※文責: 熊谷峻）

8.3

今後の展望

我々の現状の課題としてはいくつか存在する．まずライブ感という基礎に当たる部分をどのように伸ばしていくかだ．現在函ライブは目の前でのリアル演奏をヘッドホンなどで聴く形となっている．しかし，臨場感という面から見ると音が起こす振動が著しく欠損していることがわかる．音の膨らみも直接的な信号での入力であれば部屋の響きなどが一切含まれなくなるため，ライブ感という意味ではどうしても薄くなる．これを対策するためにライブ感をどのように詰めるのかが大事だと考える．具体的には疑似 3D 音声技術を導入して空間の雰囲気をだすのか，振動を感じるデバイスを用意してそれを利用するのかといった内容である．このような要素を含むため，ライブ感を生み出すためには多くの情報が必要だと感じた．続いて，オンラインサーバを通した際の遅延が大きいことだ．5 秒近く遅れることが多々存在し，その状態では臨場感を出すには難しいものがある．
人は 0.2 秒ほどのズレから感じ取ることが容易になっていくため，音が届くまでの遅延までを解決するかが重要だと感じる．小型の実サーバをネット上ではなく現場で建ててそのサーバから配信を行うといった案や音声のビットレート部分についての改変などがあるため改善していくことは可能であると考える．最後に，UI の改善があれば良いと考えている．現状のアプリは非常に簡素な状態であり，音楽シーンにあった存在とは言えない．UI 面を深く考えていくことで聞く際の雰囲気作りに貢献できると考える．
これらに加え，このアプリケーションをビジネスで実際に活用する際に必要なプランと機能を考える必要がある．今回の活動の中で青森市の主催するビジネスプランコンテストに出場したことを踏まえ，実際に活用するためにはアプリとしての完成度も足りていないがビジネスプランとしても詰めの甘い部分が多数存在する．現状の資金の回収を行う方法として，ライブを行う際のブランド
料やライブの行った人の曲の販売費から天引きするというものがあるが，業務として動かすには資金回収が追いつくことが難しい状況にある．経済的な面を考えることも社会では必要な内容となってくることから，この内容を深めていくことは開発を行う中での展望を考えながら行うことになるため，自社開発，自社活用のソフトを作る際には大きな助けになると考える．
（※文責: 斉藤由樹）

Group Report of 2019 SISP

- 36 -

Group Number 10-D

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

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

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

Group Report of 2019 SISP

- 37 -

Group Number 10-D

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

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

図 B.1

Group Report of 2019 SISP

函ライブ（中間報告会）- 38 -

Group Number 10-D

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

付録 C HAKODATE アカデミックリンク
2019 で使用した本グループのポスター

図 C.1 函ライブ（HAKODATE アカデミックリンク 2019）

Group Report of 2019 SISP

- 39 -

Group Number 10-D

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

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

図 D.1

Group Report of 2019 SISP

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

Group Number 10-D

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

図 D.2

Group Report of 2019 SISP

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

Group Number 10-D

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

付録 E
スター

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

図 E.1

Group Report of 2019 SISP

函ライブ（成果発表会）- 42 -

Group Number 10-D

参考文献
[1] 古館達也，堀川三好，工藤大希，岡本東：Bluetooth Low Energy ビーコンを用いた屋内測位手法に関する研究，情報科学技術フォーラム講演論文集，第 14 巻，4 号，pp. 311-312(2015)[2] 東 京 都 生 活 文 化 局 (2015)「 ヘ ブ ン ア ー テ ィ ス ト ト ッ プ ペ ー ジ ｜ 東 京 都 生 活 文 化 局 」,
<http://www.seikatubunka.metro.tokyo.jp/bunka/heavenartist/>, 2019 年 7 月 25 日アクセス．

[3] iXZ — 製品トップ — TASCAM (日本), <https://tascam.jp/jp/product/ixz/top>, 2020 年
1 月 21 日アクセス．
[4] VideoLAN/VLCKit・GitLab, <https://code.videolan.org/videolan/VLCKit>, 2020 年 1
月 20 日アクセス．

[5] GitHub - shogo4405/HaishinKit.swift: Camera and Microphone streaming library via
RTMP, HLS for iOS, macOS, tvOS., <https://github.com/shogo4405/HaishinKit.swift>,2020 年 1 月 20 日アクセス．
[6] GitHub - swiftgif/SwiftGif: A small UIImage extension with gif support,<https://github.com/swiftgif/SwiftGif>, 2020 年 1 月 20 日アクセス．
[7] GitHub - SCENEE/FloatingPanel: A clean and easy-to-use ﬂoating panel UI component
for iOS, <https://github.com/SCENEE/FloatingPanel>, 2020 年 1 月 20 日アクセス．

- 43 -