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

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

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

グループ名
いさりび Graﬃti

Group Name
Isaribi Graﬃti
プロジェクト番号/Project No.

14-C

プロジェクトリーダ/Project Leader
1016089

Yuki Nakata

中田裕貴

グループリーダ/Group Leader
1016195

佐藤登威

Toi Sato

グループメンバ/Group Member
1016089

中田裕貴

Yuki Nakata

1016152

伊勢田蓮

Ren Iseda

1016187

山口賢登

Kento Yamaguchi

1016195

佐藤登威

Toi Sato

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

鈴木恵二

鈴木昭二

奥野拓

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

提出日2019 年 1 月 16 日

Date of Submission
January 16, 2019

概要
本プロジェクトでは，ビーコンを使って街の中の未だ明らかになっていない情報を明確にし新たな体験・価値を函館の街に与えることを目的とする．街の様々な場所にビーコンを設置し，函館圏に住む市民や観光客に，ビーコンの特色を生かした既存の位置情報システムを使用したサービスとは別の価値を持つサービスを提供する．サービス提案をするにあたり，実際にフィールドワークを行って，街に潜む課題・需要を見極め 256 のアイデアを創出した．さらに，創出されたアイデアを複数の視点でブラッシュアップし，函館に新たな価値を与える四つのサービスを提案することにした．
（※文責: 大山義人）
列車を利用する人々のコミュニケーション手段として「駅ノート」がある．駅ノートとは，駅にノートが置かれ，地元の人々や観光客が想い出や落書きを残すことができるサービスである．
しかし，盗難・紛失が起こりうる問題，情報を共有する手段が少ないという問題，市民しか知らない魅力が伝わりにくいという三つの問題がある．そこで本グループではそれらの問題を解決するために，AR と SNS を用いて列車そのものを想い出ノートとして地元の人々と観光客をつなげる新しいサービス「いさりび Graﬃti」を提案・開発する．本サービスを利用することにより，いさりび鉄道利用者のコミュニケーションが活性化し，一体感が生まれる．そして，観光や日々の想い出をより感じることが可能となる．前期では，「いさりび Graﬃti」の実装に向けてプロトタイプを作成した．また，開発にあたって必要なアプリケーション開発の技術習
得を夏季休業中に実施した．後期では前期で作成したプロトタイプを元に開発を進め，2 度の道南いさりび鉄道での実証実験，青森公立大学との合同ワークショップを行った．合同ワーク
ショップでは，ユーザビリティテストを実施することにより，UI・UX 改善点を発見すること
ができた．
キーワード

ビーコン, 駅ノート, AR, SNS, 道南いさりび鉄道（※文責: 中田裕貴）-i-Abstract
In this project, we aim to clarify information which has not been clarified yet in town
by using a beacon and to give new experience and value to the city of Hakodate. We
set up beacons at various places in the city and provide services that have a value thatis diﬀerent from services using existing location information systems that make use of
the characteristics of beacons to citizens and tourists living in the Hakodate area. In
making service suggestions, we actually did fieldwork. Then, we generated 256 ideas
by checking the issues/demands of the city. In addition, we decided to brush up thecreated ideas from multiple perspectives and propose four services that give Hakodate
new value.
（※文責: 大山義人）

There is a communication tool for train passengers called “station notebooks”. Local
users and tourists can leave their memories and graﬃti through notebooks placed instations. However, there are three problems, station notebooks have limited pages,
can be lost or stolen, and it is diﬃcult to tell them charms which citizens only know.
Therefore, to resolve the issues, we propose and implement a new service to connect
between local people and tourists as trains are like notebooks using AR and SNS. Using
this service, the communication among railway users will be better and they feel a senseof unity. Then they will be able to feel tourism and daily memories better. In the firstterm, we made a prototype of Isaribi Graﬃti for the implementation in the second
term. In the summer vacation, we learned technologies for application development.
In the second term, we proceeded the work using the prototype, had a workshop withstudents of Aomori Public University and demonstration experiments in South Hokkaido
Railways two times. We could find improvements of UI and UX doing usability tests inthe workshop.
Keyword

Beacon, Station Notebook, AR, SNS, South Hokkaido Railway（※文責: 伊勢田蓮）- ii -

目次
第1章

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

1

1.1

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

1

1.2

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

1

1.3

ビーコンについて. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

第2章

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

2

2.1

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

2

2.2

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

3

2.3

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

3

2.4

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

3

2.4.1

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

3

2.4.2

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

3

2.4.3

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

4

2.4.4

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

5

2.5

協力企業によるレクチャー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.6

昨年度のサービスの説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.7

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

7

2.7.1

BSKJ 法 (ブレーンストーミング KJ 法) . . . . . . . . . . . . . . . . . . .

7

2.7.2

OST(オープンスペーステクノロジー) . . . . . . . . . . . . . . . . . . . .

7

2.7.3

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

8

2.7.4

函館市異業種交流会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.7.5

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

9第3章

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

11

3.1

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

11

3.2

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

11

3.3

サービス概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.4

ビーコン使用の理由 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.5

利用方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.6

機能一覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.6.1

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

13

3.6.2

アカウント作成機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.6.3

ログイン機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.6.4

列車識別機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.6.5

Bluetooth 有効化機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.6.6

閲覧機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

3.6.7

投稿機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.6.8

プロフィールの確認・編集機能 . . . . . . . . . . . . . . . . . . . . . . . .

16- iii -

第4章

4.1

4.2

第5章

開発

17

技術取得 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

4.1.1

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

17

4.1.2

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

18

4.1.3

プロトタイプ作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

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

20

4.2.1

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

20

4.2.2

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

21

4.2.3

効果と課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22システム仕様23

5.1

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

23

5.2

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

23

5.2.1

アーキテクチャ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

5.2.2

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

24

5.2.3

AR 表現 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

5.2.4

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

24

5.3

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

25

5.4

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

27

外部評価

29

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

29

6.1.1

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

29

6.1.2

発表形式の評価と反省 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

6.1.3

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

29

6.2

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

30

6.3

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

30

6.4

青森公立大学との連携ワークショップ . . . . . . . . . . . . . . . . . . . . . . . .

31

6.5

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

32

6.5.1

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

32

6.5.2

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

33

6.5.3

発表形式の評価と反省 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

第6章

6.1

第7章

各メンバーの振り返り

34

7.1

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

34

7.2

中田裕貴の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

7.3

山口賢登の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

7.4

佐藤登威の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

7.5

伊勢田蓮の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

まとめと展望39

8.1

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

39

8.2

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

39

8.3

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

40

第8章

- iv -

参考文献

41

付録 A

中間発表会で使用したプロジェクト全体のポスター

42

付録 B

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

43

付録 C

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

44

付録 D

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

47

-v-

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

第1章
1.1

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

背景

近年，IoT の普及が進んでいる．これらの普及が進んだ要因として，センサの低コスト化があげられる [1]．IoT 用デバイスのひとつとしてビーコンがある．ビーコンとは Bluetooth Low

Energy(以降，BLE) 規格の電波の発信機で，その電波を受信することで人や物の位置情報を把握することができる．ビーコンを用いたサービスでは，旅行案内アプリケーションや見守り支援シス
テムなどが存在する [2][3]．これらの他にも様々なサービスが試作されている．スマートフォンな
どの BLE に対応したデバイスを所持していれば，誰でも利用可能であるため，サービスやアプリ
ケーションの需要が高まっている．
（※文責: 森雄斗）

1.2

目的

本プロジェクトの目的は，ビーコンを使用して函館に新たな魅力を付与することである．ビーコンの特色を生かした新しい価値・体験を与えるサービスを提案する．
（※文責: 大山義人）

1.3

ビーコンについてビーコンとは，BLE を用いて信号を発信することで位置や情報を伝達する機器のことである．

BLE では，省電力・低コストで動作するため近接通知としてよく利用される．受信する端末はビーコンの固有 ID や受信電波強度を取得することができ，規格によっては URL やビーコンの温度などの情報が付加されていることがある．現在普及しているビーコンにはいくつかの規格があり，代表的な規格としては Apple 社の iBeacon，Google 社の Eddystone，LINE 社の LINE Beacon がある．iBeacon は，固有 ID や距離測定するための送信出力などのビーコンの情報を送信することができる．Eddystone は，固有 ID や距離の送信に加えて，URL の情報やビーコン自体の状態の情報を送信することができる．LINE Beacon は，コミュニケーションアプリケーションの「LINE」
に対してプッシュ通知を送信したり，広告を展開することができる．
（※文責: 篠田大地）

Group Report of 2018 SISP

-1-Group Number 14-C

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

第2章

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

本章では，前期の活動についてに述べる．本プロジェクトでは，前期は主にプロジェクトを印象付けるロゴの制作と課題設定のためのフィールドワーク，開発するサービスの考案を行った．

2.1

ロゴ作成

本プロジェクトでは，プロジェクトの目的を理解し，ビーコンについての認識を確認すること，また昨年のプロジェクトと差別化を図るために今年度プロジェクトを印象付けるロゴの制作を行った．ロゴ制作については，3 週間の時間を要した．初めに，各自でロゴのデザイン候補を作成しメンバー全員でレビューを行った．このときのレビューは改善点の指摘ではなく，そのロゴ候補について良いと思った点を述べていく方式をとり，レビューと他メンバーのデザイン候補を参考にしてロゴの改善を各自で行った．改善されたロゴに対して改善点の指摘を含めた 2 回目のレビューを行った．2 回の改善を経たデザイン候補を多数決により四つに絞り，絞られた四つのデザイン候補にレビューを行いデザインの改善を行った．最終的に改善された四つのデザイン候補の中から函館らしさ，ビーコンらしさを考慮にいれ多数決により本プロジェクトの原案を決定した．その後，ロゴに関するワーキンググループを結成し，デザイン原案を改善しつつ，ロゴデザインの最終版とロゴ使用に関するガイドライン (図 2.1)，それを用いたポスターのテンプレート (図 2.2) を作成した．

Project No.14 ビーコン IoT で函館のまちをハックする

ここにタイトルを書いてねコンセプトをここに書いてねMember

中田裕貴 大橋一真
Yuki Nakata

Kazuma Ohashi

大山義人 佐藤登威

Yoshito Oyama

佐藤綾省

篠田大地 高松耕太
Daichi Shinoda

Kota Takamatsu

前野匠星

山口賢登

伊勢田蓮

Ryosei Sato

Naruse Maeno

Kento Yamaguchi

Toi Sato

中村陽太

Yota Nakamura

北條奨 林友佳
Tasuku Hojo

Tomoka Hayashi

Teacher

森雄斗 松浦巧
Yuto Mori

Takumi Matsuura

松原克弥

鈴木昭二

鈴木恵二

藤野雄一

Katsuya Matsubara

Keiji Suzuki

Syoji Suzuki

奥野拓Taku Okuno

AdviserYuichi Fujino

佐藤生馬
Ikuma Sato

南部美砂子
Misako Nambu

美馬義亮
Yoshiaki Mima

Ren Iseda

プロジェクト概要

テーマ設定

詳細

詳細

ここにテキストここにテキストここにテキストここにテキスト
ここにテキストここにテキストここにテキストここにテキスト
ここにテキストここにテキスト

ここにテキストここにテキストここにテキストここにテキストここにテキストここにテキストここにテキストここに
テキストここにテキストここにテキストここにテキストこ
こにテキストここにテキストここにテキストここにテキス
トここにテキスト

学習プロセス

各グループの概要

詳細

詳細

ここにテキストここにテキストここにテキストここにテキスト
ここにテキストここにテキストここにテキストここにテキスト
ここにテキストここにテキストここにテキストここにテキスト
ここにテキストここにテキストここにテキストここにテキスト
ここにテキストここにテキストここにテキストここにテキスト
ここにテキストここにテキストここにテキストここにテキスト

ここにテキストここにテキストここにテキストここにテキストここにテキストここにテキストここにテキストここに
テキストここにテキストここにテキストここにテキストこ
こにテキストここにテキストここにテキストここにテキス
トここにテキストここにテキストここにテキストここにテ
キストここにテキスト

詳細

図 2.1 ロゴガイドライン

ここにテキストここにテキストここにテキストここにテキス
トここにテキストここにテキストここにテキストここにテキストここにテキストここにテキストここにテキストここにテ
キストここにテキストここにテキストここにテキストここに
テキストここにテキストここにテキストここにテキストここ
にテキスト

学び

詳細

詳細
ここにテキストここにテキストここにテキストここにテキスト
ここにテキストここにテキストここにテキストここにテキスト
ここにテキストここにテキストここにテキストここにテキスト
ここにテキストここにテキストここにテキストここにテキスト

図 2.2

ここにテキストここにテキストここにテキストここにテキストここにテキストここにテキストここにテキストここに
テキストここにテキストここにテキストここにテキストこ
こにテキストここにテキストここにテキストここにテキス
トここにテキストここにテキストここにテキストここにテ

ポスターテンプレート（※文責: 佐藤登威）

Group Report of 2018 SISP

-2-Group Number 14-C

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

2.2

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

ビーコンを用いた開発を行うためにビーコンの仕様や事例について文献調査を行い，プレゼンテーション形式でメンバー間の情報共有を行った．対象とした規格は iBeacon，LINE Beacon，

Eddystone の 3 種類であり，各 5 人のグループに分かれて調査した．文献調査には 2 日間の調査期間を設け，各自で書籍やインターネットから情報を収集し，発表を行うためのスライドを作成した．その結果，ビーコンの規格やユースケースの例，そして詳細な仕様といった知識を得た．
（※文責: 中村陽太）

2.3

Git/GitHub ワークショップ

ソースコードのバージョン管理ツールである Git とソフトウェア開発プラットフォームである

GitHub のワークショップを開催した．このワークショップにより円滑なドキュメント管理とチー
ム開発を行う手法を学ぶことが目的であった．ワークショップについては 5 時間を要した．まず初めに，Git と GitHub の概要を教員から説明を受けることによってバージョン管理の概念と必要性を学んだ．次に，個人で Git を用いたバージョン管理に関する演習を行った．その後，GitHub 上
で複数人による課題管理機能とレビュー機能を用いたチーム開発の演習を行った．ワークショップを開催したことにより，GitHub 上へのドキュメントの集約やアジェンダ・議事録を課題管理機能で集約して管理することが可能になり，円滑なプロジェクト進行が可能となった．また，後期の開発に向けてチーム開発の手法を学ぶことができた．
（※文責: 中田裕貴）

2.4

フィールドワーク

2.4.1

事前調査

函館およびその周辺地域に存在する課題や問題を調査し把握するためにフィールドワークを計画した．はじめに，調べたい場所と項目についてそれぞれブレーンストーミングを行い，場所を地区ごとに分類した．その後分類した場所をもとに調べたい項目を場所ごとに分けた．分類した地区の中から多数決で函館市西部地区，函館市五稜郭公園周辺，七飯町大沼公園，七飯町の四つの地区を調査対象として決定した．次に，各地区についてグループに分け，建物などの詳細な場所やインタ
ビュー内容などの調査項目をまとめた．インタビュー内容としては，なぜ普段は Bluetooth を無効にしているのか，困っていることはないかなどであった．これらの調査項目をもとにフィールド
ワークを行った．インタビューした結果については，2.4.3 項で記述する．
（※文責: 中村陽太）

2.4.2

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

フィールドワークの実施にあたり，2018 年 5 月 25 日の 4 限の時間にて南部美砂子先生より
フィールドワークについてのレクチャーを受けた．レクチャーでは主にフィールドワークの方向性

Group Report of 2018 SISP

-3-Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeと内容についてのアドバイスを受けた．まずフィールドワークの方向性として，課題解決型と問題発見型の二つが示された．課題解決型は問題，目標が明確であるのに対し，問題発見型は問題そのものを探求するとの説明を受けた．それぞれの特徴を踏まえ，本プロジェクトにおけるフィールド
ワークの方向性は問題発見型であることを確認した．次に，フィールドワークの内容については，実施中の記録の取り方について四つの手続きが重要であるとの説明を受けた．具体的には，情報の探索，相対化，展開，共有であった．単にフィールドワークを実施するのみでなく，得られた情報をアウトプットすることが重要であると確認した．
（※文責: 大橋一真）

2.4.3

実地調査

絞った四つの地区を 3 日に分けて実地調査を行った (図 2.3)．大沼・七飯には 2018 年 5 月 27
日，西部地区には 2018 年 6 月 3 日，五稜郭には 2018 年 6 月 8 日に訪問した．大沼では大沼国定公園，大沼公園駅，山川牧場，大沼国際セミナーハウス，東大沼キャンプ場の五カ所を，七飯では道の駅なないろ・ななえ，七飯駅，城岱牧場，北海道昆布館，富原観光果樹園，あかまつ公園の六カ所を 6 グループで訪問した．大沼，七飯の二ヶ所においても現地の様子を観察したが，フィールドワーク終了後の意見出しではその場所に対する意見を述べた．西部地区では函館駅，朝市，大門横丁，函館公園，函館護國神社，函館山ロープウェイ，はこだて明治館，金森赤レンガ倉庫，市立
函館博物館郷土資料館，緑の島，元町公園，旧イギリス領事館，旧函館区公会堂，函館ハリストス
正協会，函館聖ヨハネ教会，カトリック元町教会，旧相馬邸，八幡坂の十八ヶ所を 5 グループで訪問した．大沼・七飯ではあまり行えなかったインタビューを交えることで，西部地区の実態を知ることができた．五稜郭では五稜郭タワー，五稜郭公園，シエスタ ハコダテ，五稜郭交差点地下横
断歩道，市電，丸井今井 函館店，函館本町市場，北海道立函館美術館，函館市中央図書館，六花亭
五稜郭店，ラッキーピエロ 五稜郭公園前店，函館市青年センター，千代台公園，テーオーデパー
ト，JR 五稜郭駅，函館ショッピングセンター ポールスターの十六ヶ所を 5 グループで訪問した．
西部地区を調査した時よりも多くのインタビューをすることで街にいる人の意見をより聞くことができた．シエスタ ハコダテを調査したグループが 2.4.1 項で述べたインタビューを行った．その結果として，BLE 機能を無効にしている理由として• バッテリーの減りが早い• そもそも使い方が分からないなどの意見を聞くことができた．困っていることについては，• 喋る人がいることでうるさく感じる• コンセントや席が足りていないなどの意見を聞くことができた．意見出しでは上記以外にも，フィールドワーク中に多くのインタ
ビューを行うことができたため，アイデア出しに繋げることができた．
（※文責: 松浦巧）

Group Report of 2018 SISP

-4-Group Number 14-C

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

図 2.3

2.4.4

西部地区フィールドワーク

振り返り

調査で得た情報を他の班と共有するため，各々が調査した場所の良い点と悪い点を付箋に書き出
し，場所ごとにグループ化して模造紙に貼り付けた (図 2.4) グループ化された付箋の情報を文字でまとめ直し，アイデア出しの材料とした (図 2.5)．2018 年 5 月 27 日には，2.4.3 項で述べた大沼・七飯の調査を行った．調査の結果，駅に訪れた人が書き込める「ななえノート」や，付近の飲食店のメニューが記された看板，Instagram を模した記念撮影用のパネルの存在を確認した．調査の反省として，時間配分の見積もりが甘かったこと，現地での目的設定が不明瞭だった事があげられた．

2018 年 6 月 3 日には，2.4.3 節で述べた 18 ヶ所の調査を行った．5 月 27 日の反省から，滞在時
間と移動時間の見直し，現地で行うインタビュー内容の決定，時間に余裕があった場合に訪ねる目的地を設定しておいた．調査の結果，大門で開かれているフリーマーケットや，知名度の低い銅像の存在を確認した．調査の反省として，調査対象の下調べが足りないことがあげられた．2018 年

6 月 8 日には，2.4.3 節で述べた 16 ヶ所の調査を行った．調査の結果，本町市場に活気が無いこと
や，美術館の利用者が少ないことを確認した．下調べを綿密に行ったことで，滞りなく調査を進めることができた．5 月 27 日と 6 月 3 日の反省が生かされ，実りのある調査を行うことができた．

図 2.4

図 2.5

良い点と悪い点の書き出し

フィールドワーク後のまとめ（※文責: 北條奨）

Group Report of 2018 SISP

-5-Group Number 14-C

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

2.5

協力企業によるレクチャー

2018 年 6 月 6 日の 4 時限目にビーコンに関する開発やサービスの提供を実際に行っている
Tangerine 株式会社とトランスコスモス株式会社の方から Skype を用いた遠隔通話にてビーコンのレクチャーを受けた．ここでは基本的なビーコンの特徴や事例について説明があった．初めに企業の概要やプロフィールについての紹介を受けた．その後，ビジネスを行う上で比較する要素として Beacon，GPS，NFC，QR コード，Wi-Fi それぞれの違いや特徴について教示いただいた．また，iPhone 7 以降からイヤホンジャックがなくなったことや，Bluetooth 対応機器が増えたことなどによって Bluetooth を利用する機会が増加してきていることが明らかとなった．ビーコンの利用時のトレンドとして来店時利用からリターゲティング利用に変わってきているとの説明を受けた．その後，iBeacon の仕様や Tangerine 株式会社とトランスコスモス株式会社の方からビーコンを設置し活用した事例の紹介を受けた．事例としては街頭や店舗にビーコンを設置してプロモーションとして利用したサービスやライブイベントでトイレの混みぐらいの把握をするサービス等があった．また，事例の函館市内での活用案を提示していただいた．活用案としては函館のバスや市電内でビーコンを利用することで広告情報をスマートフォンに送る案，ビーコンを活用して外国の方にも利用してもらえるような観光客向けアプリケーションを作成する案があった．その後学生から企業の方への質問を行った．質問と回答については以下に示す．

• 動いているものにビーコンを乗せることは可能か– 高速で動くものには適さない– 人が歩くような速度であれば検知することができる• ビーコンでの三点測位は可能か– 人や物に遮られることがあるため難しい• なぜビーコンの設置案は出入り口が多いのか– 大門や朝市では今の所は出入り口のみ設置予定である– 将来的には店ごとに置くことも検討している• ビーコンの複数台設置は可能か– 干渉してしまう– 理想は複数重ならないように設置する• ビーコンのメンテナンスはどの程度必要か– 遠隔でビーコンの電池残量を確認することができる– 設置時点で消費電力を計算できる– 函館に設置予定のビーコンは単三電池 2 本で約一年半交換の必要はない（※文責: 高松耕太）

2.6

昨年度のサービスの説明

アイデア出しのきっかけを作るために昨年度の「ビーコン IoT で函館のまちをハックする」から
三つ，「ロケーションベースサービスの展開 人々の生活を便利にする位置情報サービスの提供 」
から一つの計四つのグループに，それぞれ 15 分間でポスター発表をお願いし，サービスについての質疑応答を行った．この説明を受けて，アイデアを決定する際の重要な点としてビーコンの優位

Group Report of 2018 SISP

-6-Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
性や地域とのつながりを学ぶことができた．
（※文責: 前野匠星）

2.7

サービスの考案

2.7.1

BSKJ 法 (ブレーンストーミング KJ 法)

フィールドワーク後のブレーンストーミングを踏まえて BSKJ 法を用いて行った．BSKJ 法とは，思いつく限り多くの量のアイデアを付箋等にアウトプットし，その後アイデアを整理し，グルーピングを行う方法である [4]．様々な意見を出すために，毎回，各グループが異なるメンバー構成となるように調整した．アウトプットの方法としては，初めの三つのグループに模造紙を一枚ずつ配布し，アイデアを付箋で貼り付けて行った．グループが変わった後も以前の意見を参考にできるように共通の模造紙を使用した．BSKJ 法によるアイデア出しの結果，256 のアイデアを生み出すことができた．
（※文責: 高松耕太）

2.7.2

OST(オープンスペーステクノロジー)

BSKJ 法でのグルーピングを行った後に，OST を行った．OST とは，各々が関心を持ったテーマについて考え，より深い意見にするための方法である [5]．特に時間を区切らず，各々が関心を持ったアイデアについて考え，考え終わったら他のアイデアに移り，各アイデアについて考えを深めていった (図 2.6)．OST の結果，BSKJ 法で考察した 256 のアイデアを七つのアイデアに絞り込むことができた．

図 2.6

アイデア考案中の模造紙（※文責: 高松耕太）

Group Report of 2018 SISP

-7-Group Number 14-C

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

2.7.3

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

OST で七つのアイデアに絞り，それぞれのアイデアに興味のあるプロジェクトメンバーを偏りの少なくなるよう振り分け，各グループの詳細なサービス案についてブラッシュアップを行った．
教員や学生間でのレビューを行いつつスライドに内容をまとめ，プロジェクトメンバー内でプレゼンテーションを行った．評価の方法として図 2.7 のように，各アイデアに対して「新体験」，「オリジナリティ」，「函館らしさ」，「ビーコンの特徴」，「継続性」の観点について，意見出しを行い，0〜

5 点の 6 段階で点数をつけるというものであった．各点数については，表 2.1 に示す．さらに，各アイデアの担当メンバーについても多少変更し，引き続き各アイデアについてブラッシュアップとレビューを繰り返し行った．

図 2.7

表 2.1

アイデアに対しての評価出し各アイデアと評価の平均

新体験

オリジナリティ函館らしさ

ビーコンの特徴

継続性

平均

いさりび Graﬃti

3.1

3.0

4.6

4.4

3.0

3.6

＠ハナセル

4.6

4.0

1.9

3.9

2.8

3.4

Becoma

3.4

3.6

2.2

4.0

4.2

3.5

B-Haunted

3.7

3.4

0.5

4.2

3.0

3.0

Beacon-Live

4.2

3.2

1.2

3.1

2.2

2.8

B-FUN

2.8

3.2

2.5

2.9

3.2

2.9

Telepath

3.2

3.4

1.5

3.5

3.3

3.0

（※文責: 高松耕太）

2.7.4

函館市異業種交流会

函館市には，新技術開発サロンとよばれる各社の得意分野を生かした共同開発や大学との連携を行っている組織がある．2018 年 6 月 27 日に，この組織に所属しているものづくり企業を招いてGroup Report of 2018 SISP

-8-Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life開催される函館市異業種交流会に参加した．参加した目的は，IT 産業ではない異業種からの視点での客観的なレビューを受けることによって，考案中のアイデアの改善をするためである．交流会には，サービスを絞り込む段階でプロジェクト内の評価が高かった「＠ハナセル」，「いさりびGraﬃti」，「Becoma」の 3 グループが参加した．発表形式は 1 グループに付き 7 分の発表をスラ
イドを用いておこなった．その後質疑応答を受けた．まず，「＠ハナセル」では，LINE を使用する意義を適切に伝えることができなかったため，質疑応答ではサービス内容を改めて確認する内容の質問が多く見られた．「Becoma」では，「出品者の負担が多いので，場所の固定をしない方がいい」などの意見を頂いた．この意見について，グループ内でもう一度議論を行い，出品者の負担を減らす機能について考えることができた．「いさりび Graﬃti」は Facebook や Instagram などの既存の SNS との差別化の説明が足りず，このサービスの内容や，場所を道南いさりび鉄道として固定するメリットが伝わっていなかったと感じた．意見としては，「景色の解説が欲しい」などの意見を頂いた．全体として，第三者視点でのサービスに対する肯定的な意見はもちろん，厳しい意
見を頂いたことで提案の課題や提案する上で考慮できていない部分などを認識することができた．
この時頂いたレビューはテーマ決定前のブラッシュアップの際に反映させることができた．
（※文責: 中田裕貴）

2.7.5

テーマ決定

七つのアイデアについてブラッシュアップを行い，再度スライドにまとめ，各アイデアについてのプレゼンテーションと評価を行った．また，担当教員，TA，Tangerine 株式会社，トランスコ
スモス株式会社の方にも参加・評価をしていただいた．評価の方法としては，各アイデアに対して「新体験」，「オリジナリティ」，「函館らしさ」，「ビーコンの特徴」，「継続性」の観点について，0〜5
点の 6 段階で点数付けを行った．各点数については，表 2.2 に示す．プレゼンテーションを行った
アイデアは「＠ハナセル」，「Becoma」，「いさりび Graﬃti」，「B-Haunted」，「Telepath」の五つであった．「＠ハナセル」は LINE を使用し銅像と会話することを可能にし，新たな体験として提供することで銅像に対して関心や興味を持たせるサービスである．「Becoma」は簡単に取引したい人同士をマッチングさせ，気軽に取引を行うことができるサービスである．「いさりび Graﬃti」
は道南いさりび鉄道の車内に AR を用いて旅の想いを貼り付けることで他の人と想いを共有することができるサービスである．「B-Haunted」はお化け屋敷の中でビーコンを用いることで従来とは違う新たな恐怖感を与えることができるサービスである．「Telepath」はビーコンの検知範囲内においてチャットルームを作成し，匿名チャットにより気軽に質問等を行うことができるサービス
である．これらのサービスについて得られた評価と各サービスに必要な人数や開発期間を考えた結果，評価の点数の平均値が高い上位四つのアイデアである，「＠ハナセル」，「Becoma」，「いさりび

Graﬃti」，「Telepath」を今年度のプロジェクトで開発することを決定した．

Group Report of 2018 SISP

-9-Group Number 14-C

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

各アイデアと評価の平均

新体験

オリジナリティ函館らしさ

ビーコンの特徴

継続性

平均

＠ハナセル

4.1

3.8

3.1

3.6

2.9

3.5

Becoma

3.5

3.4

2.2

4.2

3.9

3.5

いさりび Graﬃti

4.1

3.8

4.7

4.4

3.8

4.2

B-Haunted

4.2

3.7

1.2

3.6

2.9

3.1

Telepath

3.4

3.6

2.2

3.7

3.7

3.3

（※文責: 高松耕太）

Group Report of 2018 SISP

- 10 -

Group Number 14-C

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

第3章
3.1

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

函館・木古内間を結ぶ道南いさりび鉄道 (以下いさ鉄) は，雄大な津軽海峡の景色や泉沢駅に広がる花畑などが見られる観光列車の面と，地元の人々がよく利用する通勤・通学列車という面の 2面性がある．その観光列車として，「ながまれ号」がある．ながまれとは，北海道の方言で「のんびりとして」という意味である．ながまれ号は，普段は日常の通勤・通学・買い物として地元の人々が利用する列車として運行しているが，観光団体用に列車内で食事が楽しめるようなテーブルやヘッドレストを設置した観光仕様としても利用できる．
鉄道の駅における情報共有手段として，「駅ノート」と呼ばれる，駅に訪れた人が思い思いの寄せ書きや落書きをするものがある．本プロジェクトでは，鉄道利用者が想い出や発見を残したいというニーズがあると考えた．しかし，駅ノートはページが有限である，紛失や盗難が起こりうるという二つの問題がある．実際，いさ鉄では，2017 年 12 月 8 日に駅ノートが何者かに持ち去られたという事件が起きた [6]．
また，地元の人々と観光客がいさ鉄での想い出を共有できていないという課題もある．両者を繋げることによって，地元の人しか知らない観光スポットを教えてもらうことや，その場所の雰囲気を感じられることなど，観光の活性化をできると考えた．これらのことをふまえて，盗難や紛失を防ぎ，地元の人々と観光客を繋げる新たなサービスを考案する必要があると考えた．
（※文責: 佐藤登威）

3.2

目的

Twitter や Facebook などの既存の SNS サービスでは，タイムラインに投稿が拡散してしまい，
情報の共有が難しい．一方，駅ノートは盗難や紛失の問題もある．本サービスの目的は，これらの問題を解決するために，いさ鉄の観光客と地元の人々を繋げ，新たなコミュニケーションの場を提供するサービス「いさりび Graﬃti」の提案と開発を行うことである．利用者の想い出はデジタルで保存されるため，従来の問題であった駅ノートの紛失・盗難を防ぐことができる．また，列車や駅のどこにいても情報を閲覧できるようにすることで，想い出や情報の共有が容易になる．
本サービスでは，位置情報取得のためにビーコンを使用する．位置情報の取得には GPS を用いることが一般的であるが，GPS よりもビーコンが優れている点が二つある．まず，列車は動き続けているため，列車内にいる人のみにサービスを提供するためには，GPS によるトラッキングではなく，ビーコンによる短距離信号で検知する方法が最適である．次に，ビーコンは電波の送受信に省電力無線技術である BLE を使用する．利用者のスマートフォンの GPS を使用して場所を特定すると電池を大量に消費するが，ビーコンを用いることで電池の消費を抑えることができる．
（※文責: 佐藤登威）

Group Report of 2018 SISP

- 11 -

Group Number 14-C

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

3.3

サービス概要いさりび Graﬃti は，列車そのものに想いを残す新しい形のサービスである．本サービスは，いさ鉄に乗車している人が列車内での想いを残す際に使用する．従来の駅ノートや観光地のノートでは，ノートに書き残すだけでその想いを皆で共有するという一体感に欠けていた．そこで本サービ
スでは，拡張現実 Augmented Reality(以下 AR) の技術を用いて列車内の机や壁といった部分に想いを残すことを提案する．この提案によりいさ鉄に乗車した人全員の想いを，寄せ書きのように
列車内に書き残すという一体感を提供できる．ユーザはスマートフォンを列車内の壁などに向ける
ことで，その場に残された想いを閲覧することができる．また，従来の駅ノートや観光地のノート
は，あくまでも自分の想いを残すものであり，ノートを介したコミュニケーションは重要視されていなかった．そこで本サービスでは他のユーザが投稿した想いに対して自分の想いをコラボレー
ションさせる機能を提案する．この提案により，日常的にいさ鉄に乗車している人しか知らない観光資源や沿線の魅力を伝えることが可能になる．
（※文責: 中田裕貴）

3.4

ビーコン使用の理由

本サービスではビーコンを使う理由が二つある．以下にそれぞれの理由について述べる．

1. 利用制限のため
本サービスは，列車そのものを想い出ノートとして地元の人々と観光客をつなげるサービスであるため，ユーザが列車に乗車している時のみ利用可能としている．そのため，ユーザが列車に乗車しているかを判別する必要がある. そこで本サービスは列車内にビーコンを置き，ビーコンの発するデータを受信したかを判別し，それを可能にする．

2. 列車特定のため
各ユーザの想いが列車内に表示される際に，列車によって表示する想いが異なるため，ユー
ザがどの列車に乗っているかを特定する必要がある．そこでビーコンを列車内に置き，どの列車に設置されているかの情報をビーコンに与えた．これによって，ユーザが列車に乗車した際にその情報を受信し，表示する想いを判別できる．
（※文責: 山口賢登）

3.5

利用方法

本サービスは，観光客と普段から通勤通学で利用される地元の市民の利用を想定しているが，本報告書では観光客の利用を想定してユーザストーリーを述べていく．まずはじめにユーザは，いさ鉄が運行している列車に乗車する．ユーザが所持しているスマートフォンの Bluetooth が無効になっている場合，アプリケーションはユーザに Bluetooth を有効にするように促す通知をする．

Bluetooth が有効になっている場合，乗車するとユーザのスマートフォンがビーコンの発する電波を受信する (図 3.1.A)．ユーザは雄大な海の景色や列車内で提供される海鮮料理などを楽しむことができる (図 3.1.B)．ユーザがいさ鉄での想いを残したい，他の乗客の想いを見てみたいと思った

Group Report of 2018 SISP

- 12 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeとき，いさりび Graﬃti を利用する．ユーザは投稿機能を使っていさ鉄での想いや写真を投稿する(図 3.1.C)．ユーザが所持しているスマートフォンの Bluetooth が有効で，なおかつスマートフォ
ンがビーコンを受信しているときホーム画面では AR を用いてこれまで投稿されてきた「寄せ書き」が列車内に表示される．この AR を用いた寄せ書きは，ユーザのスマートフォンを列車内に貼られている AR マーカーにかざすことで見ることができる (図 3.1.D)．また，自分のプロフィー
ルの確認や変更をしたいときは，プロフィールの表示・編集機能を使うことでこれらの操作が可能となる．以上がいさりび Graﬃti で体験できる機能とサービスであり，想定しているユーザストー
リーである．

図 3.1 サービス概要図（※文責: 山口賢登）

3.6

機能一覧

3.6.1

チュートリアル機能

アプリケーションをインストールして初めて起動するときに，チュートリアル画面が表示される(図 3.2)．チュートリアル画面では，アプリケーションの概要や，想いの投稿の方法を知ることができる．

図 3.2 チュートリアル画面（※文責: 山口賢登）

Group Report of 2018 SISP

- 13 -

Group Number 14-C

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

3.6.2

アカウント作成機能

アカウントを作成する (図 3.3)．ユーザはユーザ名とアイコンを登録できる．アイコンは標準のアイコンが設定されており，変更してもしなくても良い．アイコンを変更する際は，カメラ機能を用いてその場で撮影した写真か，フォトライブラリから写真を選択し，丸く切り取りをしてからアイコンにできる．

図 3.3 アカウント作成画面（※文責: 山口賢登）

3.6.3

ログイン機能アプリケーションを起動した際に，アカウントが既に作成済みの場合に自動的にログインし，ユーザのプロフィールや投稿した想いを取得する．
（※文責: 山口賢登）

3.6.4

列車識別機能Bluetooth が有効化された状態で起動すると，アプリケーションはビーコンの電波を検知する画面を表示する．その際に列車内に設置されているビーコンを探す．ビーコンの電波を受信した際にビーコンの電波からどの車両かを特定する．
（※文責: 山口賢登）

3.6.5

Bluetooth 有効化機能

アプリケーション起動時に，端末の Bluetooth が有効化されてない場合は，有効にするようにア
プリケーションから促す (図 3.4)．本サービスではビーコンを利用するため，Bluetooth を有効にする必要がある．Bluetooth が有効化されている際にビーコンを検知することでアプリケーション

Group Report of 2018 SISP

- 14 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeの他の機能を利用できる．

図 3.4 Bluetooth の有効化画面（※文責: 山口賢登）

3.6.6

閲覧機能

ビーコンの検知中，識別された列車に投稿されている想いを閲覧できる (図 3.5)．投稿されている想いは AR を用いて，列車内にある AR マーカー上に貼り付けられているように表示される．

AR で表示されている想いをタップすることで拡大表示できる．また，その想いに写真が添付されている場合，その写真をタップすることで画面一杯に表示できる．

図 3.5

閲覧画面

（※文責: 山口賢登）

Group Report of 2018 SISP

- 15 -

Group Number 14-C

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

3.6.7

投稿機能

ビーコンの検知中，識別された列車に想いを投稿できる (図 3.6)．投稿する際に画像を添付することもできる．想いを入力し，その想いを貼りたい AR マーカーをタップすることでその AR マー
カー上に貼ることができる．投稿した想いには投稿日時も表示される．

図 3.6

投稿画面

（※文責: 山口賢登）

3.6.8

プロフィールの確認・編集機能

ユーザのプロフィールを表示することができ，ユーザ名とアイコン，過去に投稿した想いを確認できる (図 3.7)．また，ユーザのアイコンを変更することもできる．

図 3.7

プロフィール画面（※文責: 山口賢登）

Group Report of 2018 SISP

- 16 -

Group Number 14-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 を用いて行った．Slack には，他の Web アプリケーションとの連携や，ファイルの共有やアップロードがしやすいといったメリットがある．また，毎週金曜日にメンバー全員に週報を提出するように促すなど，効果的に利用することができた．
（※文責: 山口賢登）

4.1.1.2

Xcode

本サービスのアプリケーション開発では，開発期間が短いため Android，iOS の両方の開発をすることが難しい．そこで，iOS アプリケーションの開発経験があるメンバーがいたため，iOS ア
プリケーションの開発のみを行うこととした．そのため，アプリケーション開発には，Apple 社が提供している Xcode という統合開発環境を使用して開発することにした．Xcode には Interface

Builder という機能があり，実際にコードを書かなくても視覚的に UI を作成することが可能である．また，Xcode 上でシュミレータを起動し，実際に iPhone を持っていなくても動作の確認ができる．これらのことから Xcode を使用した．使用したバージョンは Xcode10.0 であり，言語はSwift4.2 を用いた．
（※文責: 山口賢登）

4.1.1.3

Adobe XD

プロトタイプ作成のためにアドビシステムズ株式会社が提供する Adobe XD というプロトタイ
プ作成ツールを用いた．プロトタイプ作成ツールは様々あるが，Adobe XD の場合，UI パーツやサンプルのレイアウトが無償で提供されているので学習コストが低く，共有したプロトタイプに直接レビューを書き込むことができるなどの利点があるため，Adebe XD を用いた．
（※文責: 山口賢登）

4.1.1.4

Git

ソースコードのバージョン管理ツールとして Git を使用した．Git は分散型のバージョン管理シ
ステムの一つであり，全てのファイルの変更履歴を含む完全なリポジトリの複製を保存できるというものである．そのため，一度編集したファイルをもとに戻すことやどのような編集が行われてきたのか表示することが可能である．リポジトリにはネットワーク上に保存されているリモートリポ
ジトリと，メンバーそれぞれの PC 内に保存されているローカルリポジトリの 2 種類がある．リGroup Report of 2018 SISP

- 17 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
モートリポジトリではメンバーそれぞれのファイルの変更履歴を保存し，確認や共有ができる．また，Git には branch という概念が存在する．branch は変更履歴を分岐し，元の分岐した branchの影響を受けずにファイルを編集することができる．この branch によって複数のファイル編集を同時に行うことができる．
（※文責: 山口賢登）

4.1.1.5

GitHub

GitHub とはリモートリポジトリを提供するクラウドサービスである．GitHub を使用することにより，複数のメンバー間でスムーズにファイルを共有し，開発することが可能となった．GitHubの一つの機能として Pull Request がある．これは分岐した branch でファイルを編集し，それを元の branch に取り込む際に使用する．Pull Request を使用することで，ファイルの変更箇所を把握でき，他の開発者がその変更箇所に対してレビューを簡単にすることができる．これによって本サービスでは，より品質の良いコードを作ることができた．また，GitHub には Issues という機能がある．これはプロジェクトやコードの課題などを管理することができる．Issue を用いることによって現状の課題やタスクを共有することができた．
（※文責: 山口賢登）

4.1.1.6

ZenHub

ZenHub とは，GitHub をアジャイル開発向けに拡張できるサービスである．ZenHub を用いる
ことでモバイルアプリケーションやサーバサイドアプリケーションの Issue や Pull Request を統合できる．また，ベロシティと呼ばれる先週までの実績を可視化することができ，開発終了時期の予測を立てることができる．
（※文責: 山口賢登）

4.1.2

各メンバーへ課した課題

夏季休業中に各メンバーには後期の開発が滞りなくできるようにするために，アプリケーションを開発するために必要な技術の習得や教育を行った．また，技術習得の際に経験者が開発に不慣れな者をフォローするために週に一回オンラインでミーティングを行う機会を設けた．各メンバーに課した課題を以下に示す．
中田裕貴• Kubernetes を用いたサーバサイドアプリケーションの運用方法の習得• Docker を用いた開発方法の習得• 継続的インテグレーションの環境整備• アジャイル開発導入に向けたプロジェクトメンバーの教育
山口賢登• Swift の基礎知識の習得• Xcode を用いた開発知識の習得
Group Report of 2018 SISP

- 18 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life• オリジナルの iOS アプリケーションの作成
佐藤登威• Swift の基礎知識の習得• Xcode を用いた開発知識の習得• オリジナルの iOS アプリケーションの作成
伊勢田蓮• ドットインストール Ruby 入門の完了 [7]• Ruby on Rails チュートリアルの完了 [8]• データベース設計方法の習得• Docker を用いた開発方法の習得（※文責: 中田裕貴）

4.1.3

プロトタイプ作成

アプリケーションの開発前にプロトタイプを作成することでメンバー間でのアプリケーションの想定する動き，デザイン，ユーザ体験を可視化して共有できた (図 4.1)．プロトタイプ作成時は，ホーム画面，投稿画面，プロフィール画面，検索画面の 4 画面を作成し，このプロトタイプを元に実際に開発を進めた．ホーム画面では AR 表現をする必要があるが，プロトタイプ内ではそれができないため，背景に列車内の写真を配置し，想いの投稿を置くことで AR 表現をした．プロトタイ
プ内では検索機能を追加することを想定していたが，実際のアプリケーション開発時には検索機能を追加しなかった．また，開発時に各画面の改善案が出たため，実際に完成したアプリケーションとプロトタイプでは多少 UI が異なった．

図 4.1

プロトタイプ（※文責: 山口賢登）

Group Report of 2018 SISP

- 19 -

Group Number 14-C

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

4.2

開発手法

4.2.1

導入した手法

4.2.1.1

アジャイル開発

本プロジェクトでは，ソフトウェア開発の手法である，アジャイル開発を導入した．アジャイル
開発とは，包括的なドキュメントよりも動くソフトウェアを重視した開発手法である．短い期間で反復的に計画・設計・実装・テストを繰り返すことにより，価値のあるソフトウェアを継続的に提供することができる．本プロジェクトでは，この手法を採用することで開発初期から継続して動く
ソフトウェアを作り続けることを目指した．アジャイル開発では経験則をプラクティスとして定めている．本プロジェクトでは，プラクティスとしてインセプションデッキとユーザストーリーを採用した．インセプションデッキとは，サービス開発前にメンバー全員で認識合わせを行うプロセス
で，「エレベーターピッチ」 や「夜も眠れない問題」，「やらないことリスト」など 10 の質問から構成されている．これらの 10 の質問をメンバーで議論することにより，開発するサービスの方向性や認識を全員で共有できる．ユーザストーリーとは，サービスを利用するユーザが実現したいと考えている機能を記述したものである．ユーザストーリーを記述することで，開発するサービスに必要な機能を洗い出すことができた．
（※文責: 中田裕貴）

4.2.1.2

スクラム

本プロジェクトでは，アジャイル開発を導入するにあたり，アジャイル開発の手法の一つである
スクラムを採用した．Ken Schwaber らは，スクラムは「複雑で変化の激しい問題に対応するためのフレームワークであり，可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである」と定義している [9]．スクラムは経験主義を実現するために全員が情報を共有する「透明性」，頻繁に行うソフトウェアやゴールの「検査」，頻繁にプロセスの調整を行う「適応」の三つを実践することを定義している．スクラムでは，スプリントと呼ばれる 1 ヶ月以下の短いタイム
ボックスを設けている．この期間で開発が完了した動くソフトウェアを出すことが求められる．ス
プリントの長さは常に一定であり，スプリントが終了後すぐに次のスプリントに入る．そして検査と適応を行うためにスプリントプランニング，デイリースクラム，スプリントレビュー，スプリン
トレトロスペクティブの四つのイベントを用意している．
スプリントプランニングとは，スプリントで行う作業を計画するミーティングである．このミー
ティングでは，過去の開発実績からプロダクトバックログと呼ばれる重要度順に並べられた機能の一覧から今スプリントの開発できそうな機能を考案し，スプリントバックログを作成する．スプ
リントバックログとは，スプリントで達成したいゴールを達成するために必要な実装する機能とリリースするための作業の一覧のことである．次にデイリースクラムとは，スプリント期間中毎日

15 分程度で行うミーティングのことである．デイリースクラムでは各メンバーが「昨日行ったこと」，「今日行うこと」，「困っていること」を議論することでスプリント終了日までゴールを達成できるかを確認できる．スプリントレビューとは，スプリント終了時に開発した機能の確認とプロダ
クトバックログの修正を行うイベントのことである．開発した機能の確認は実際にデモとして動かして他のメンバーからの質問に答えることで確認を行う．スプリントレトロスペクティブとは，チーム全体を振り返り，次のスプリントの改善計画を考えるミーティングである．スプリントレト

Group Report of 2018 SISP

- 20 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
ロスペクティブでは，チームの課題やうまくいった項目を議論することで，次のスプリントの生産性を上げることができる．
（※文責: 中田裕貴）

4.2.1.3

エクストリーム・プログラミング

本プロジェクトでは，アジャイル開発を導入するに当たり，スクラムとは別の手法でエクスト
リーム・プログラミングも採用した．エクストリーム・プログラミングでは，素早いフィードバッ
クやインクリメンタルな変更を始め五つの基本原則が定められている．そして 19 個のプラクティ
スが共同，開発，管理者，顧客の 4 カテゴリーに分類されて定められている．本プロジェクトではエクストリーム・プログラミングのプラクティスとして開発カテゴリのペアプログラミングとリ
ファクタリング，継続的インテグレーションを採用した．ペアプログラミングとは，二人一組で行うプログラミングのことで，コードを書く人をドライバー，隣でチェックする人をナビゲーターと呼ぶ．二人一組でプログラミングすることで常にコードレビューを行うことができる．リファクタ
リングとは，随時完成済みのコードでも改善していくことである．外部への振る舞いは変えず内部の処理を改善することで構造を見通しの良いものにできる．継続的インテグレーションとは，自分のコード変更がリポジトリに反映される度に自動でビルド・テストを行うことである．継続的イン
テグレーションを行うことにより，バグを早期に発見して対処することが可能となる．
（※文責: 中田裕貴）

4.2.2

開発の流れ

本プロジェクトでは，スプリント期間を 1 週間として開発を行った．毎週水曜日をスプリント
開始日としてスプリントプランニングを行った．そして翌週の火曜日にスプリント最終日としてスプリントレビューとスプリントレトロスペクティブを行った．プロダクトバックログとスプリ
ントバックログは ZenHub で管理した．スプリント期間中は毎日午後 0 時半からデイリースクラムを 15 分間で実施した．デイリースクラムでは「昨日行ったこと」，「本日行うこと」，「困っていること」，「スプリントゴールに間に合わせることができるのか」を議論した．スプリント中の開発は GitHub の Issue と Pull Request を主体とした開発とした．メンバーはスプリントバックロ
グの内容の開発を行い，それを GitHub に Push して Pull Request を作成する．Pull Request を作成すると Travis CI により自動テストと Sider による静的コード解析が実行される．Travis CIとは，GitHub 上のソースコードを自動でテストを行う継続的インテグレーションツールである．

Sider とは，Sider 株式会社の GitHub 上のソースコードに自動でコードレビューを行う静的コー
ド解析ツールである．Pull Request を取り込むにはこの二つのツールによるチェックが通ったあと他のメンバーによるコードレビューが必要となる．コードレビューの基準は「仕様と実装はあっている」，「無意味なロジックがない」，「DRY を守っている」，「テストが適切に書かれている」，「メ
ソッド名，変数名などが適切」，「コーディングルールを守れている」「メソッドからは予想できない副作用が含まれていない」の七つであった．この流れをスプリント最終日まで継続して行った．
スプリント最終日はスプリントレビューとスプリントレトロスペクティブを行った．スプリント
レビューでは，各メンバーから開発した機能のデモを行ったほか，不定期に他チームと合同でスプ
リントレビューを行うことで機能の品質を確認した．スプリントレトロスペクティブでは，KPTという振り返りの手法を用いて行った．KPT とは Keep，Problem，Try の略である．Keep では

Group Report of 2018 SISP

- 21 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
「今後も続けたいことや良かったこと」，Problem では「うまく行かなかったこと，課題」，Try では「今後行うこと」であり，この三つを付箋に書き出してチームの課題を発見して改善計画を立てることでスプリントの振り返りを行った．
（※文責: 中田裕貴）

4.2.3

効果と課題

本プロジェクトでは，アジャイル開発の手法であるスクラムとエクストリーム・プログラミングを導入することで，継続的に毎週動く成果物を作り続けることができた．そのため後述する当初の予定に無かった青森公立大学との合同ワークショップでも滞りなくユーザビリティテストを実施することができた．1 週間というタイムボックスでスプリント期間を設定したため，仕様の変化にも柔軟に対応できたほか，機能の改善やチームの問題改善までの流れも迅速であった．また，継続的インテグレーションを導入したことでメンバー全員がコードの品質やバグにも気を使うことができたため，開発したサービスの品質を向上させることができたと考えている．しかしながら，プロ
ジェクトメンバーへのアジャイル開発に対する教育が足りなかったため，開発初期ではプロダクト
バックログの内容の不備やスクラムで用意されているイベントが実施されないなどの問題が発生した．また，ベロシティを見誤ることで 1 スプリントで実施する予定の量が増えすぎてしまいメン
バーへの負担が集中するなどの問題も発生した．そのため，アジャイル開発に慣れるためにサービスの開発が始まる前に勉強会などを実施する必要があると考える．
（※文責: 中田裕貴）

Group Report of 2018 SISP

- 22 -

Group Number 14-C

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

第5章
5.1

システム仕様システム構成本サービスは図 5.1 のようにビーコン，モバイルアプリケーション，サーバサイドアプリケー
ションの三つから構成される．ビーコンは，スマートフォンが特定の電波を検知する際の発信機としての役割を担う．これは iBeacon の規格を用いたものを用いる．列車内にビーコンを設置することで，乗車確認に用いる．モバイルアプリケーションはビーコンの電波の検出，ユーザの作成，想いの投稿と表示を行う．サーバサイドアプリケーションは初回通信時にモバイルアプリから送られてきたユーザ名と識別 ID で新規ユーザをデータベースに登録する．その後はモバイルアプリから送られてきた投稿の保存，特定の列車に貼られた投稿の一覧を送信することを行う．

図 5.1 システム構成図（※文責: 中田裕貴）

5.2

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

本サービスは列車内でも手軽に使えるようにするため，モバイルアプリケーションを開発した．
前述した通り，開発期間が短いため Android，iOS の両方の開発をすることが難しく，iOS アプリ
ケーションの開発経験があるメンバーがいたため，iOS アプリケーションの開発のみを行った．開発言語は Swift を使用した．
（※文責: 山口賢登）

5.2.1

アーキテクチャ開発においてアーキテクチャを考えずに実装すると，UI の操作や管理を行う ViewControllerというクラスが肥大化しやすく，同じ処理が使い回せない，チーム開発で役割分担が難しくな

Group Report of 2018 SISP

- 23 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeるなどの課題が生じると懸念した．そのため，本サービスのアプリケーション開発のアーキテク
チャとして Model View Presenter(以下 MVP) を採用した．UI のレイアウトや更新をする処理をViewController のみにし，Presenter には UI の状態に関する処理や Model の操作，Model には
データの処理などを書いた．数あるアーキテクチャの中から MVP を採用した理由として，処理を書くファイルが明確化され，コードが見やすくなり，前述したアーキテクチャを考えずに実装した
場合の課題がなくなることなどがあげられる．また，学習コストが高くなく，開発経験の浅いメン
バーでも理解しやすいということもあげられる．
（※文責: 山口賢登）

5.2.2

チュートリアル本サービスの概要や使い方をユーザに簡単に認知してもらうためにチュートリアルを導入した．
後述する青森公立大学との連携ワークショップにおいて，アプリケーションの使い方がわかりにくいなどの意見があったため，既存のチュートリアルを改善し，実際に投稿するまでの流れをユーザにしてもらうチュートリアルも追加することで解決できた．
（※文責: 山口賢登）

5.2.3

AR 表現

想いを列車に貼るためにアプリケーション内で AR 表現を行う必要があった．そのため，Apple社が提供している ARKit というフレームワークを用いてアプリケーション内で AR 表現を可能にした．完成したアプリケーションの場合，AR マーカーに iPhone のカメラを向けると過去に他ユーザの投稿した想いが表示される．また，ユーザが投稿画面から文章や写真を載せた想いを投稿する際に，AR マーカーをタップすることでその想いを貼り，投稿できる．しかしアプリケーションの開発当初は AR マーカーを用いることを想定していなかった．開発当初は列車内の壁や床などを検出し，自由に想いの投稿を貼ることを想定していた．しかし，ARKit は iPhone の加速度とカメラによる物体との深度を利用し AR 世界の物体を描画している．そのため，列車にユーザが乗ると列車の加速度を取得してしまい，ユーザが動いていなくとも AR 世界の物体が動いてしまう．
この課題があったため，AR マーカーを用いて想いの投稿を貼れるようにした．
（※文責: 山口賢登）

5.2.4

導入ライブラリ

導入したライブラリを以下に示す．

• ARKitApple 社が提供する開発者向けの AR フレームワークである．このライブラリを導入することでいさりび Graﬃti は AR 表現をできるようになった．

• Alamofire/AlamofireImage
Alamofire また AlamofireImage は GitHub で公開されている Swift で書かれた HTTP
ネットワーク通信ライブラリである．このライブラリを導入することで HTTP ネットワー

Group Report of 2018 SISP

- 24 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
ク通信のコードを簡略化することができた．

• TGRFramework
今回本プロジェクトと連携している Tangerine 株式会社が提供しているライブラリでビーコンに関する開発に用いた．このライブラリを導入することによってビーコン受信，ビーコンの電波強度などを計測することが容易となった．

• SVProgressHUD
今回ビーコン受信によって様々な機能が重くなり軽量化が困難となった．そこでこのライブラリを導入することでユーザにタスクが進行中であることを簡易的に表示できるようになった．

• paper onboarding
チュートリアルを作成するに当たって導入したライブラリである．簡単な操作でチュートリ
アルを進めることができ画面の遷移もシームレスに行える．

• RSKImageCropper
ユーザが自身のプロフィールのアイコン画像を変更する際に用いるライブラリである．このライブラリを導入することでユーザは自身がもつ写真を簡単に円形にトリミングすることができる．

• Quick
UnitTest で用いたライブラリである．本アプリケーションは Alamofire/AlamofireImageによる http 通信を行うため非同期処理という通信が終わるまでその他の処理を一時的に止めるという仕様にした．そこで非同期処理の Swift アプリケーションについて簡単に

UnitTest を行える Quick を導入した．
• Nimble
UnitTest で用いたライブラリである．Quick を導入するに当たって前提としてこのライブ
ラリを導入なければならなかったので導入した．
（※文責: 山口賢登）

5.3

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

本サービスにおいてクライアントに API を提供するため，Ruby 及び Web アプリケーション
フレームワークである Ruby on Rails を用いてサーバを開発した．これらを使用した理由として，開発に必要な機能が揃っていること，プロジェクトリーダの中田が Ruby・Ruby on Rails を用いた開発の経験があることがあげられる．本サーバはユーザの登録，ユーザのプロフィール画像の更新，列車ごとの投稿の取得，ユーザごとの投稿の取得，投稿をデータベースに保存，画像の取得の機能を提供する．開発の初期段階ではビーコンの識別に関する API も実装していたが，Tangerine
株式会社の TangerinSDK を用いたほうがモバイル側の管理が容易であったため，削除した．デー
タベースの設計及び実装した API を以下に示す．

• GET /post/:actionid
ビーコンを識別するための ID である actionid が含まれる最新 20 件の投稿を返す．存在しない actionid を参照した場合，HTTP 404 を返す．

• POST /post
投稿をデータベースに保存する．存在しないユーザで保存しようとした場合や異なる形

Group Report of 2018 SISP

- 25 -

Group Number 14-C

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

users テーブル

型

カラム名

概要

Stringuseridユーザを識別する UUID

Stringuser name

ユーザ名

Stringimage name

画像のファイル名

表 5.2

posts テーブル

型

カラム名

概要

Integer

id

投稿を識別する ID

Stringuseridユーザを識別する UUID

Stringtext

投稿の文

Stringimage name

画像のファイル名Stringpasted imageid

AR マーカーの画像

Integeractionid

ビーコン識別 ID

Datetime

created at

レコードの作成日時

Datetime

updated at

レコードの更新日時

式の画像を送信した場合，HTTP 500 を返す．リクエストの成功時，失敗時に応じて{“status”:“success”} または {“status”:“failure”} を JSON として返す．
• GET /post/user/:userid
ユーザを一意に識別する UUID である userid をもとに，ユーザの過去の投稿を返す．存在しない userid を参照した場合，HTTP 404 を返す．

• GET /image/:image name与えられたファイル名に基づき，サーバに保存されている画像を返す．存在しないファイルを参照した場合，HTTP 404 を返す．

• GET /user/:userid
userid を基にユーザを探し，ユーザ名，プロフィール画像のファイル名を返す．存在しない
userid を参照した場合，HTTP 404 を返す．
• GET /users
登録された全てのユーザの情報を返す．主にデバッグ用として使用した．

• POST /user
新 た に ユ ー ザ を 登 録 す る ．主 キ ー と し て 使 用 す る userid は 端 末 の UUID か ら 生 成
し ，一 意 で あ る ．リ ク エ ス ト の 成 功 時 ，失 敗 時 に 応 じ て {“status”:“success”} ま た は{“status”:“failure”} を JSON として返す．
• PUT /user/:userid
ユ ー ザ の プ ロ フ ィ ー ル 画 像 を 変 更 す る ．リ ク エ ス ト の 成 功 時 ，失 敗 時 に 応 じ て{“status”:“success”} または {“status”:“failure”} を JSON として返す．
• v2
8.3 節で詳細に述べるが，Base64 を使用しないようにするため，既存の API に変わる新バージョンのものを作成した．Base64 にエンコードされた文字列を返すのではなく，サーバに格納されているファイル名を返すようにした．

Group Report of 2018 SISP

- 26 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life– /post/v2/:actionid– /post/user/v2/:userid
画像をスマートフォン側で取得する際，元のデータサイズのまま送ると取得に時間がかかるため，サーバ側で縮小して送信するようにした．これにより，約 100MB あったデータを数 MB に圧縮することができた．バグを最小限に抑えるため，すべての機能についてテストを書き，品質を向上させるようにした．可読性のあるソースコードを書くため，Ruby の静的解析ツールである Rubocopを導入した．
（※文責: 伊勢田蓮）

5.4

インフラ

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

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

Engine を使用した．Google Kubernetes Engine(GKE) とは，コンテナ化されたアプリケーショ
ンを運用するためのサービスである．GKE を用いることでサービスの需要に合わせてオートス
ケーリングと呼ばれる CPU やメモリの量を自動で増やすことやシステムを完全に停止させずにア
プリケーションを更新すること，障害発生時の自動修復を行うことなどが可能になる．CloudSQLとは，データベース管理システムである MySQL や PostgreSQL のデータベースをクラウド上に簡単に構築できるサービスである．CloudSQL を用いることで最大 64 コアの CPU，400GB のメモリまでオートスケーリングすることが可能であり，99.95 ％の可用性を保証できる．Google

Compute Engine(GCE) とは，仮想マシンと呼ばれる仮想的なコンピュータを提供するサービス
である．GCE を使用することで，要件に合わせた性能の仮想マシンを用意できる．
本サービスでは，GKE に Ruby on Rails 製の API サーバと CloudSQL に接続するための二つのコンテナを用意した．また，このコンテナ群は負荷分散のために 2 個に複製されている．GKEの仮想マシンは冗長構成としており，CPU のコア数 3，メモリ 5.1GB 構成の 3 台によるクラス
タ構成とした．また GCE には投稿された画像を保存するためのマシンとして 10GB の SSD 永続
ディスクを用意した．図 5.2 のように，iOS アプリからのリクエストはロードバランサーと呼ばれる負荷分散装置によって 2 個のコンテナ群のうち一番負荷が少ないコンテナ群にリクエストが送られる．コンテナ群に送られたリクエストは WEB サーバの nginx によって Ruby on Rails アプリ
ケーションに送られて処理される．Ruby on Rails アプリケーションからデータベースに情報を取得しに行く際，CloudSQL に接続するためのプロキシコンテナに SQL のクエリを送信する．プ
ロキシコンテナは受け取ったクエリを CloudSQL に送り情報を取得する．そして取得した情報をRuby on Rails アプリケーションコンテナに送信する．
（※文責: 中田裕貴）

Group Report of 2018 SISP

- 27 -

Group Number 14-C

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

図 5.2 システム構成図

Group Report of 2018 SISP

- 28 -

Group Number 14-C

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

第6章

外部評価

6.1

中間発表

6.1.1

発表形式

始めに本プロジェクトの概要や各アイデアの大まかな説明を行うため，メインポスターを 5 分で発表した．その後，@ハナセルと Becoma のどちらかを聞き手に選んでもらい，5 分で発表して 2
分間の質疑応答の時間をとった．次にいさりび Graﬃti，telepath のどちらかを聞き手に選んでもらい，5 分で発表し，時間の許す限り質疑応答の時間をとった．2 グループずつに分けた理由は，4グループを同時に発表すると聞き手に声が届きにくい点と，4 グループ同時に発表するにはスペー
スが窮屈なためである．いさりび Graﬃti の発表では，概要，モバイルアプリケーションについて，システム構成，画面遷移の流れで説明した．画面遷移の説明の後に，メイン機能のみを実装したモバイルアプリケーションをモニターに映し，実際にスマートフォンアプリを使いながら利用方法を説明した．
（※文責: 伊勢田蓮）

6.1.2

発表形式の評価と反省

発表技術に関して，高評価な意見として• しっかりと準備されていた• 実機での発表がわかりやすかった• なぜビーコンの設置案は出入り口が多いのか• ポスターに文字が少なく，図が多いことで読みやすかったなどが得られ，聞き手にうまく伝えることができていた．低評価な意見としては，• ポスターを読みながら発表になっていた点が残念• システム構成を詳しく聴きたかったなどが得られた．平均評価は 10 点中，7.7 点であった．以上から，ポスターを読みながら発表しないようにすること，システム構成をより詳しく説明できるようにするという改善点があることがわかった．
（※文責: 伊勢田蓮）

6.1.3

発表内容の評価と反省

発表内容に関しては，高評価な意見として• 物体にコメントを貼り付けられるのはすごく面白いアイデアだと思った
Group Report of 2018 SISP

- 29 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
• 想い出をその場に残せるのは良いと思った• AR での実装が面白い• 実際に使ってみたら面白そうだと思ったなどが得られ，提案に対する聞き手の評価は高く感じられた．低評価な意見としては• AR を用いるのはいいが，携帯越しで見るので人混みが多い場所では難しいと思った• AR である理由がわからなかったなどが得られ，実際にこのスマートフォンアプリを使うことの難しさを指摘された．平均評価は10 点中，7.9 点であった．以上から，実際に実証実験をしてスマートフォンアプリの使いやすさを検証する必要があることが改善点として得られた．「AR である理由がわからなかった」という指摘に関しては，発表時に AR を利用する意味を説明したが，上手く説明できていなかったことが原因であると考えた．
（※文責: 伊勢田蓮）

6.2

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

2018 年 8 月 5 日に 公立はこだて未来大学でオープンキャンパスが開催された．本プロジェクト
は前期で考案したサービスについて，一般ユーザを想定してオープンキャンパスに参加していただ
いた高校生ならびに保護者の方々にアドバイスや意見を得て，後期の開発につなげることを目的とした．二つ目の目的として高校生にプロジェクト学習とはどのようなものなのかを本プロジェクトの活動を紹介することで，一つの例として提示し大学生活を想像して頂こうと考えた．
本プロジェクトは公立はこだて未来大学が主催するオープンキャンパスに「ここにいる人だけコ
ミュニケーション」というインタラクティブ展示として出展した．展示ではプロジェクト学習の中
間発表会で用いた全体ポスターと各グループのポスター 4 枚，そして昨年のプロジェクト学習で製作した「サプライズスナップ」のポスター，および製作物を展示した．プロジェクト活動の説明としてビーコン認知度が高くないと予想されたためビーコンについて説明し，本グループからは中間発表会で作成・使用したポスターとサービスの特徴である AR × SNS を体験してもらうために
モックアプリをモニターに表示し展示した．
参加したメンバーは佐藤登威，林友佳，大橋一真，北條奨，中村陽太の計 5 人と教員として松原克弥である．
（※文責: 佐藤登威）

6.3

HAKODATE アカデミックリンク

2018 年 11 月 10 日に函館アリーナで HAKODATE アカデミックリンク 2018 が開催された．本
プロジェクトが参加した目的は前期で考案し後期で開発してきたサービスを実際に一般の方に説明
し，サービスに対するアドバイスや意見を求めるためである．また企業の方と商業的に運用するのであればどのようなビジネスプランを考えているのか自分たちの考えを説明し評価を頂いた．参加者は中田裕貴，大橋一真，大山義人，北條奨，佐藤登威，林友佳，佐藤綾省，篠田大地，高松耕太，
森雄斗，松浦巧，前野匠星，山口賢登，伊勢田蓮の計 14 人である．また教員として松原克弥准教Group Report of 2018 SISP

- 30 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life授が参加した．
本プロジェクトはキャンパス・コンソーシアム函館が主催するはこだて高等教育機関合同研究
発表会 HAKODATE アカデミックリンク 2018 に参加した．HAKODATE アカデミックリンク

2018 とは函館市内 8 高等教育機関の学生が一堂に会し，普段研究している内容や成果をポスター
展示や実演などによって発表し合う合同研究発表会である．
展示では中間発表会で用いたポスターを今回の合同発表会向けに編集した全体ポスター 2 枚と各グループのポスター 4 枚，各グループがこれまでに作成したアプリケーションの実機映像を展示した．
アカデミックリンク 2018 では四つの観点で評価し，評価得点最も高いテーマは表彰された．評価に関する観点は次の 4 点である．

1. 発表内容• 論理性，創造性，発展性のいずれかにおいて，秀でたものがあるか• 発表内容を的確に理解し，質疑に対して適切に回答できているか
2. 発表技術• 内容を伝えるために，効果的な発表が行われているか (ポスターの構成，プレゼンテー
ションの構成，発声や説明の明瞭さ，専門分野外の人にもわかりやすく説明しているか，等)

3. コミュニケーション• 学生会の交流，企業や地域住民および中学高校生などとの連携という目的に即して熱意を持って発表・交流に取り組んでいるか

4. 地域性• 地域で発表することが意義深い，「地域に根ざした研究」「学校の特色が感じられる発表」となっているか• 企業や地域住民および中学高校生などとの連携に資する研究発表となっているか（※文責: 佐藤登威）

6.4

青森公立大学との連携ワークショップ

本ワークショップは本学と青森公立大学の学術交流協定に基づき，2015 年から 2 度開催された．
専門分野の異なる学生との共同作業を通じて，コミュニケーション能力，視野の向上を目的としたものである．今年度は 2018 年 11 月 24・25 日に開催された．本学の参加者は，プロジェクトメン
バー 15 人 (中田裕貴，大橋一真，大山義人，北條奨，佐藤登威，林友佳，佐藤綾省，篠田大地，高松耕太，中村陽太，森雄斗，松浦巧，前野匠星，山口賢登，伊勢田蓮)，教員が，片桐恭弘学長，藤野雄一教授，鈴木昭二教授，安井重哉准教授，松原克弥准教授であり，青森公立大学の参加者は学生が 11 人，教員が香取薫学長であった．

2 日間を通して実際にサービスが使われるであろう場所で実証実験し，UI・UX を評価していた
だいた．1 日目は昼に函館大学ベイエリア・サテライトに両学生及び教職員が集合し，本プロジェ
クトのサービスの一つである「Telepath」のユーザビリティテストを金森赤レンガ倉庫付近で行った．青森公立大学の学生に iPhone を渡し，「Telepath」を用いて本学生とのコミュニケーションをとった．その後，サービスの良かった点・悪かった点を議論し，KJ 法でまとめ，各グループごとに発表した．2 日目は「Becoma」，「@ハナセル」を担当するグループ，「いさりび Graﬃti」をGroup Report of 2018 SISP

- 31 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
担当するグループの二つに分かれて行った．前者のグループは西部地区・五稜郭・朝市で，後者のグループは五稜郭・木古内間の列車上で実証実験を行った．
「いさりび Graﬃti」の実証実験では，列車の壁面に AR マーカーを貼り，本サービスを体験してもらった．五稜郭・上磯間は人が多く，立ち上がってサービスを使用すると他の客の迷惑となるた
め，控えた．路線を往復した後，前日と同じく評価をし，情報を共有した．本サービスの高評価な意見として，• 上手に写真が撮れなかった日でも楽しめる• 観光列車なので AR が気軽に楽しめる• 綺麗な景色が楽しめるなどがあり，本サービスの意図を理解してもらうことができた．低評価な意見としては，• AR 機能なのかカメラ機能なのかがわからない• AR マーカーに過去の投稿が貼ってあると上書きにためらいが生じる• AR マーカーが小さくてトラッキングしてくれないなどがあった．ユーザの目線でのレビューをもらうことができ，開発者である我々が気づかないことが多く得られた．本ワークショップ終了後，残りの開発期間で改善点を修正した．また，ユーザの目線になって UI・UX を考えることをより重視するようにした．
（※文責: 伊勢田蓮）

6.5

成果発表会

6.5.1

発表形式

中間発表では 3 階のモールで発表を行なってきたが，スペースの広さ，人の集まりやすさ，声の通り具合を考慮し 1 階のプレゼンテーションベイに発表場所を変更した．
始めに本プロジェクトの概要や各アイデアのおおまかな説明を行うためメインポスターを 5 分で説明した．その後，@ハナセル，Becoma，Telepath，いさりび Graﬃti の 4 サービスから興味を持っていただいたものを選んでいただき 8 分間で発表を行なった．中間発表ではサービス案の紹介しかしないため 5 分間の発表を 2 タームに分けて二つのサービスを発表したが，成果発表会ではサービス紹介から製作物の紹介までを行なったので選んでいただくサービスは 1 つとし，発表時間
を 8 分とした．
プロジェクト全体の展示として全体ポスター 3 枚，青森公立大学との連携ワークショップで作成したポストイットでまとめた簡易ポスターおよび本プロジェクトで考案したサービス，開発したアプリケーションに関する意見をまとめた簡易ポスターを展示した．本グループはグループポス
ター，青森公立大学との連携ワークショップで撮影した動画，実機の画面を展示した．実機画面の展示に関してはアプリケーションをモニターに映し，実際に操作方法や AR 画面の見せながら説明した．
（※文責: 佐藤登威）

Group Report of 2018 SISP

- 32 -

Group Number 14-C

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

6.5.2

発表内容の評価と反省

発表技術に関して，高評価な意見として• 開発したものまで十分に内容が分かる• 発表資料が分かりやすい• 話すスピードが良いなどが得られ，中間発表での反省を活かすことができたと言える．低評価な意見としては• 技術的な仕組みをもう少し説明したほうが良いが得られた．今回の発表では UI・UX に重点を置き，技術的な側面は AR しか取り上げていな
かった．限られた発表時間の中でも工夫して，技術的な仕組みをもっと説明するようにすれば良かった．
（※文責: 伊勢田蓮）

6.5.3

発表形式の評価と反省

発表内容に関して，高評価な意見として• ぜひ使ってみたい• 同じ空間を共有できるのは良いと感じた• UI が素晴らしい• ユーザのフィードバックをちゃんと適用しているなどが得られた．従って，本アプリケーションの評価が高いと言える．低評価な意見としては• サービスの目的がどこなのか気になった• ポスターに書かれている課題が解決されるサービスなのか，ビーコンを活用することで価値を発揮するサービスなのか (AR 機能のみのほうがどこでも見れて本人の思い出になるとか?) の 2 点はやや気になりました．

• 過去の投稿を見れるようにしてほしいなどが得られた．平均評価は 10 点中，8.44 点で，中間発表会よりも 0.54 点に上がった．サービスの目的が上手く伝わっていなかったようなので，明確に分かりやすく伝えるべきであった．「過去の投稿を見れるようにしてほしい」については，現状の実装では新しい投稿は過去の投稿の上に貼るようになっており，アプリケーションの実装で過去の投稿を見れるように改善していく必要があると感じた．
（※文責: 伊勢田蓮）

Group Report of 2018 SISP

- 33 -

Group Number 14-C

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

第7章
7.1

各メンバーの振り返り

役割分担

本グループでは中間発表終了後，メンバーの得意分野に合わせてモバイルアプリケーションの開発担当と API サーバ開発担当，インフラ開発担当に分かれ役割分担を行った．しかしながら，開発中は個人が他の担当の支援をすることもあり，あくまでも形式的なものであった．また，本サービス開発において最終的な意思決定を行うプロダクトオーナーとチームのファシリテーションを行うスクラムマスターを一人ずつ選出した．各メンバー担当は以下に示す．
中田裕貴• プロダクトオーナー• API サーバ開発• インフラ開発
山口賢登• スクラムマスター• モバイルアプリケーション開発• モックアップ作成
佐藤登威• モバイルアプリケーション開発• ポスター作成
伊勢田蓮• API サーバ開発• データベースの構築（※文責: 中田裕貴）

7.2

中田裕貴の振り返り

プロジェクト学習を通して様々な活動があり，多くのことを学んだ．前期では主にサービスを開発するまでのアイデア出しの過程で多くの学びがあった．まず私達のプロジェクトでは考案するにあたってフィールドワークを行いその中で得られたものから 256 個のアイデアを出した．しかしながら，多くのアイデアはビーコンである必要性や函館らしさが乏しく，アイデア出しの難しさを感じた．この過程でアイデアの出し方や考え方を学ぶことができた．また，私はプロジェクトリー
ダであったが，前期は自分が一人でタスクを抱えることが多くなってしまい全体の作業が滞ってしまうことがあった．滞ってしまうことで中間発表や中間報告書の準備が遅くなってしまい，メンGroup Report of 2018 SISP

- 34 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
バーで情報を共有する大切さを感じた．また，技術習得の中でアプリケーション運用方法や開発手法について大きな学びがあった．
後期では，プロジェクト全体のアジャイル開発や継続的インテグレーションの導入やインフラの自動化など技術基盤や開発手法の推進を行った．まずアジャイル開発やスクラムの導入は自分自身があまり経験豊富ではなかったため，模索しながらの開始であった．そのため，スクラムの手法から逸脱してしまったり，プロジェクトメンバーにスクラムの必要性を理解してもらないことがあった．しかしながら，繰り返し振り返ることや改善を重ねていく中でこれらの問題は解決していった．このような改善の過程をプロジェクト学習の中で体験することができたのは貴重な経験だった．また，これらの手法を導入していったことでサービスは開発初期から継続して動くものを作ることができた．雰囲気で開発するのではなく，アジャイル開発を始めとした開発手法を導入することで多くの学びを得ることができた．サービス開発ではインフラとサーバサイドアプリケーションの開発を行った．インフラで Kubernetes を使用することでオートスケーリングや自動修復できる
堅固なインフラを目指した．実際に運用することで安定に可動させる難しさやデプロイの自動化などを学んだ．サーバサイドアプリケーションの開発では，主に Rubocop の導入やテストの重要性などをプロジェクトメンバに伝えながらコードレビューを多く行ってきた．自分がコードを書くだ
けではなくコードレビューを行う側になることで良くないコードの書き方や良いテストの書き方な
どの多くのことを学ぶことができた．
（※文責: 中田裕貴）

7.3

山口賢登の振り返り

私はプロジェクト学習を始めるまでに iOS アプリケーションの開発経験やチーム開発をしたことがあった．過去のチーム開発ではメンバーがある程度の開発経験や知識があったため，開発初期の段階で躓くことがなかった．しかし，プロジェクト学習ではメンバー全員が開発経験があるわけでもなければチーム開発の経験があるわけでもない．そういった状況下でサービス開発を始めたため，多くの経験や知識を得ることができた．
本格的にサービス開発に入る前に，アプリケーションの基盤作りに力を入れた．アプリケーショ
ンの初期設定や，コードの構文チェックをする SwiftLint の導入・設定，CI の導入など，今までのチーム開発では私が担当しなかったが今回初めてしっかりと基盤作りを行ったため，とてもいい経験となった．
開発初期にメンバーに Swift や Xcode の基礎知識，アーキテクチャの話などする必要があった．そこでは，今まで私の中ではあまり気にしていなかった部分などについて質問されることもあり，再度私自身そのことについて調べ，新たに気づくこともあり，既存知識を再確認することができた．
前述した通り，本サービスは元々 AR で表示している想いを列車の壁や床などに自由に貼れることを想定していたが，列車が動くと想いが元の位置から動いてしまうため，AR マーカーを用いてこの課題を解決した．しかし，すぐに AR マーカーを用いて解決するという案には至らなかった．一番最初に試したことは列車の移動量分，想いの位置をずらすという案である．次に試したことは，クアルコム社が提供している vuforia という AR ライブラリを用いたことである．実際に車に乗って実験をしたが，車が動くと表示してる AR ブロックが動いてしまい，失敗におわった．最後に試したことは 6D.AI 社が提供している 6D.ai という AR ライブラリである．これも車に乗っGroup Report of 2018 SISP

- 35 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Lifeて実験をしたが，うまくいかなった．そして最後には AR マーカーを用いて，電車が動いても想いが元の位置からずれないようにできた．
今回の開発手法としてスクラムを採用していたが，平日は毎日デイリースクラムを行ったのはとても誇らしいものだと思った．メンバー全員が毎日大学に来ているわけでもなければ，プロジェク
ト学習以外にも授業が入っている．そのような状況で毎日デイリースクラムを行えたからである．
そこで開発におけるコミュニケーションの重要性というものに気づいた．仮に毎日デイリースクラムを行っていなかった場合，メンバー全員の今行っていることや困っていることなどが把握できなく，メンバー内でアプリケーションの仕様の認識がずれていたかもしれない．これらを考慮すると，コミュニケーションというのはとても重要であると気づけた．
（※文責: 山口賢登）

7.4

佐藤登威の振り返り

私がプロジェクト学習で「ビーコン IoT で函館のまちをハックする」を選んだ理由は二つある．
一つ目は PBL として問題を発見するところから活動が始まるという点である．世の中には様々な問題が山積しているが，目に見えている問題を解決するだけではなく調査や分析をして初めて発見できる問題を解決することも重要であると考える．よって初めから解決すべき問題が与えられているのではなく，本プロジェクトのような問題を発見する過程から始まり，現状の調査，分析から問題発見までの力が身につくようなプロジェクトに入りたいと考えていた．
二つ目は技術力を高められ，開発に携われる点である．問題解決には様々な方法があるが，未来大生として調査・分析した問題について適切に解決できるデジタルサービスを開発したいと考えていた．また近年急速に発展・普及している IoT に関する開発はこれからの開発人材として重要な立ち位置になると考えた．以上二つが本プロジェクトを選び，またこの１年間の活動でもっとも意識してきた内容である．
前期の活動は主に函館に隠れている問題を発見し，問題についてビーコンを用いたサービスの考案であった．問題発見のために本プロジェクトで最初に行なった活動はフィールドワークであったがフィールドワーク自体で隠れた問題を発見することは大変困難であり，その後の意見交換や

BSKJ 法による意見の分析によって初めて問題が明確になるということがわかった．ただフィール
ドワークに関して，事前に質問事項を考え函館市民にインタビューをしていく方式は決められた時間内でスムーズに聞くことができるが，市民が考える問題を引き出すことが難しいということがわ
かった．次の機会では簡単な質問事項に抑え，インタビューのなかから適切に引き出せるようなものにしていきたい．
サービス考案に関して多種多様なアイデアを提案することができた．しかし函館に根ざしたサー
ビスや将来性を考え長期的にユーザが使ってくれるというような条件にあてはめていくと，ほとん
どのアイデアは価値を説明しきれなかった．今回は様々なアイデアを複合したり連携企業からの指摘を取り入れた上で四つのサービスが考案された．今後私は社会人として活動していく上で「ユーザが長期的に使ってくれるサービス」「商業利用が明白になっている」という観点を重要視していきたいと思う．
夏季休暇期間では主にアプリケーション開発で使用する Swift の勉強と Xcode の使い方を学習した．Swift と Xcode の学習では本グループに所属し，先行して Swift と Xcode に知見がある山
口からアドバイスを得て学習を進めた．夏季インターンに参加や実家帰省で順調とはいかなかったGroup Report of 2018 SISP

- 36 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
ものの後期の開発で必要な基礎的な知識を学習することができた．
後期の活動は主にサービスの開発と様々な発表会に参加し本プロジェクトで考案・開発したアプ
リケーションの紹介であった．開発ではプロジェクトリーダーの中田の提案でスクラムな開発を採用し，１週間を１スプリントとして開発を進めた．開発の初期では自分の技術力の見誤りやコミュ
ニケーション不足からスプリント計画で決めた要件を開発しきれない問題が発生した．しかし開発を進めていくうちに技術力が向上し，またコミュニケーションを重要視しサーバサイドアプリケー
ションの開発陣とも積極的に相談を進めることで，後半の開発では順調にスプリントを進めることができた．コミュニケーションに関してはオンラインのチャットやビデオ通話による相談ではなく実際に対面で会う方が相手の表情がわかり，活発に意見が出るということがわかった．
成果発表会をはじめとした様々な発表会ではポスターと実機での説明を主とした内容だった．実機での実演をしたためアプリケーションの使用方法や使用した際のイメージは容易であったが，サービスの根幹である「駅ノートの存在」や「誰に当てたわけではない想いを残したい」というニーズを十分に伝えきれなかった．なのでサービスの有用性をしっかり伝えるには何に注目し重要視しているか説明するのが重要とわかった．
今回のプロジェクト学習で問題発見，サービス考案の力，開発力向上，チーム開発におけるノウ
ハウを学習できた．また先ほど述べた反省点を生かし今後の活動に取り組んでいきたい．
（※文責: 佐藤登威）

7.5

伊勢田蓮の振り返り

プロジェクト学習での様々な経験を通して，多くの知識や技術を学ぶことができた．課題の発見・サービスの提案・開発・実証実験・成果発表会の一連の流れを通して大きく成長できたと思う．
高校生の頃から IoT に興味があり，実社会に役立つサービスを考えて開発してみたいと思っていた．本プロジェクトに所属し活動していくことで，目的が達成できたと思う．また，技術面では知らないことを知ることができたり，曖昧な知識を完全なものにできた．
前期では，フィールドワークによる課題の発見やサービスのアイデアの考案を主に行った．
フィールドワークでは，普段よりも注意深く観察することにより，様々な問題を発見することができた．アイデアを考えるところでは，ビーコンと GPS の差別化をするところが最も難しいと感じた．それに加え，函館らしさや新規性も考慮しなければならなかったため，苦労した．ブレーンス
トーミングや KJ 法を用いて情報を整理していくことで，効率的に物事を進めていくプロセスを学ぶことができた．これらの経験により，問題の調査や分析・比較といった技術者として必要なものを身につけることができ．中間発表では人前で発表することに慣れていなくて，ポスターを見ながらの発表になったり，声が小さいなどの問題があり，反省点とした．
夏季休暇期間は，後期の開発に必要な技術の取得を行った．私はサーバサイドアプリケーションを担当することになったので，Ruby on Rails の学習を進めた．Ruby や Ruby on Rails を用いた開発の経験が無かったため，学習に時間がかかった．また，言語やフレームワークの他に，ミドルウェアや HTTP，CUI で用いるコマンド等についても学習する必要があった．週に一度，遠隔で学習の進捗を報告する会が設けられ，モチベーションを向上させることができた．
後期では，前期で決定したサービスの開発を進めた．最初のほうでは夏季休暇期間で学んだ知識ではうまく開発できなかった．テストの書き方が悪いと指摘され，様々な資料を調べて正しい書き方を学んだ．また，開発スピードが遅く，自分の思い通りに開発することができなかった．開発のGroup Report of 2018 SISP

- 37 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
中盤に差し掛かると，開発スピードも早くなり，慣れてきたが，データベースのカラム名が不適切であることを指摘された．様々な機能を追加していくうえで，どちらがどれを指しているのかが分かりにくくなった．後のことを考えてわかりやすい名前を決めることが重要だと学んだ．開発手法にスクラムを取り入れ，1 週間を 1 スプリントとして開発を進めてきた．私は 1 スプリントの中でやるべきタスクを持ち越さず，期限までにすべて終えたので，計画的に開発を進めることができたと思う．平日の昼にミーティングを行うことにより，密接なコミュニケーションを取ることができた．開発を効率的に行うツールである Git/GitHub については，本プロジェクトで初めて使用したが，前期で講習会を行ったこともあり，問題なくできた．開発期間中，2 度の体外発表の場 (6.3節, 6.4 節) があり，発表技術を向上させることができた．成果発表会では，中間発表での反省を活かし，落ち着いて発表することができた．この約 2 か月間の開発期間はとても濃密であり，貴重な体験であった．今回の経験で得られたものを今後の活動に生かしていきたい．
（※文責: 伊勢田蓮）

Group Report of 2018 SISP

- 38 -

Group Number 14-C

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

第8章
8.1

まとめと展望前期の振り返り

前期では初めにビーコンについて，特に類似技術である GPS，QR コード，NFC との違いについて注目し学習を進めた．ここで類似技術との違いを明確にすることでその後のサービス考案でビーコンの特色をより行かせる内容にすることができた．また連携企業である Tangerine 株式会
社とトランスコスモス株式会社から既存のビーコン事業についてレクチャーを受け商業的なサービスについての知見を得た．
次に本年のビーコンプロジェクトと昨年のビーコンプロジェクトを差別化させるためにまずプロジェクトのロゴを作成した．作成手順はプロジェクトメンバー全員で案を持ち寄り，レビューと改善をそれぞれ行い教員を含めた 19 人で一つのロゴを投票によって選択した．作成したロゴについてはカラーガイドや使用上の注意が載ったガイドラインを作成しその後のポスター作成など各種資料作成で利用を簡易にした．
次に南部先生からフィールドワークについて講義を行っていただきフィールワークやインタ
ビューを行う際の注意点を学習した．訪れた場所は七飯地区と大沼地区，五稜郭地区，西部地区である．調査で得た情報を他メンバー共有するため，各々が調査した場所の良い点と悪い点を付箋に書き出し，場所ごとにグループ化して模造紙に貼り付けた．グループ化された付箋の情報を文字でまとめ直し，アイデア出しの材料とした．調査の反省として，時間配分の見積もりが甘かったこと，現地での目的設定が不明瞭だったことがあげられた．初回のフィールドワークの反省から下調べを綿密に行ったことで，滞りなく調査を進めることができた．
サービス考案では簡単なアイデアを 256 個提案し，BSKJ 法・OST・ブラッシュアップを経て

7 つのアイデアに絞った．ここから連携企業を交えて「新体験」「函館らしさ」「オリジナリティ」「ビーコンの特徴」「継続性」の 5 つの観点で評価し最終的に「@ハナセル」「Becoma」「Telepath」「いさりび Graﬃti」の 4 つのサービスを後期に開発していくこととなった．
中間発表では全体ポスターといさりび Graﬃti についてのポスター，実機での実演を展示した．
サービスに関するご意見は開発時に取り入れ改善に当たった．発表自体の反省はプロジェクト全体
でまとめ後期の成果発表会に活かすこととなった．
（※文責: 佐藤登威）

8.2

後期の振り返り後期では初めにスクラム開発についてグループで導入するかプロジェクトメンバーに確認をとり，全員の了承を得て導入することとなった．その後各グループでプロダクトリーダー，スクラムマスターを決め開発を開始した．開発手法は 4.2 節の通りであり，毎週のスプリントレビューにより反省と改善を行い，本グループが抱えていた開発課題を解消した．
開発の途中で移動体における AR の問題を発見した．今回のサービスにおいて AR 表現は Apple社が提供する ARKit というフレームワークを利用しアプリケーションを開発した．ARKit はユー
ザ端末の加速度とカメラによる物体との深度を利用し，AR 世界の物体を描画している．よってGroup Report of 2018 SISP

- 39 -

Group Number 14-C

Leverage the Beacon IoT in Hakodate Real Downtown for Our Smarter Life
ユーザが列車に乗ってしまうと，ユーザが動いていなくても加速度を計測してしまうので AR 世界の物体が移動してしまう．そこで本グループが考えた解決策は AR マーカーにユーザの投稿を設置するという形式に変更し AR 世界を表現するというものである．この手法により移動している
列車の中でも「投稿を貼る，閲覧する」という体験を提供することができた．

2018 年 11 月 25 日に行われた青森公立大学との連携ワークショップにて得られた意見を元にア
プリケーションを改善した．
成果発表会に関しては 6.5.1 項の通り行い中間発表の反省を活かしスライドを使用した形式に変
更し実機による実演を多用することでイメージのつきやすい展示にすることができた．
（※文責: 佐藤登威）

8.3

今後の展望

今回実装したアプリケーションには課題が何点かある．まず，投稿を 5 分に一度サーバから取得しているが，このときにスマートフォンの画面が固まってしまう．画面を表示する部分と投稿を取得する部分を別スレッドにして並列化することで改善が期待される．次に，クライアントから画像を送る際に Base64 を使用している．これはデータを文字列に変換する技術であるが，この際にデータの大きさが約 37% 増加してしまう．さらに，長い文字列をサーバに送信すると，サーバが処理できないという問題が起こりうる．Base64 を用いたほうがサーバとクライアントの連携が取れるため使用したが，効率的にデータを送信するために multipart/form-data 形式を使用していきたい．最後に，メッセージや画像の投稿に成功した後，過去の投稿が重なり，過去の投稿を見ることができなくなる課題がある．現状の実装では，一つの AR マーカーに一つの最新の投稿を表示するようになっている．最新の投稿の下部に投稿を数件重ねて表示することで改善が期待される．
最終的には，AR マーカーを使わず，標準の AR 機能を用いるアプリケーションと同等の体験を提供できるようにしていきたい．
（※文責: 伊勢田蓮）

Group Report of 2018 SISP

- 40 -

Group Number 14-C

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

参考文献
[1] 総務省, (2015), 平成 27 年版 情報通信白書 ユビキタスから IoT へ,
http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h27/html/nc254110.html, (lastaccessed 2018/7/18).
[2] 天目隆平, 神原誠之, 横矢直和, (2002), 赤外線ビーコンと歩数計測を利用したウェアラブル型拡張現実感のための幾何学的位置合わせ, 情報科学技術フォーラム (FIT) 2002 一般講演論文集,

32, 431-432.
[3] 杉野恭兵, 片山真也, 丹羽佑輔, 白松俊, 大圏忠親, 新谷虎松, (2014), Bluetooth ビーコンを用いた居場所情報に基づく見守り支援システムの試作 (人工知能と知識処理), 電子情報通信学会
技術研究報告 = IEICE technical report : 信学技報 114(339), 43-48.

[4] アイデア総研, (2016), これでもう失敗しない！ KJ 法の正しいやり方と注意点,
http://idea-soken.com/kj-method, (last accessed 2018/7/18).
[5] OUR FUTURE, (2015), オープンスペーステクノロジー (OST),
https://www.ourfutures.net/session methods/ost, (last accessed 2018/7/18).
[6] 道南いさりび鉄道株式会社 (2017), 【お願い】 駅ノート のご返却をお願いします．,
http://www.shr-isaribi.jp/info/2964, (last accessed 2018/07/16).
[7] 株式会社ドットインストール (2018).Ruby 入門 (全 26 回).
https://dotinstall.com/lessons/basic ruby v3,(last accessed 2018/12/25).
[8] Michael Hartl.(2017).Ruby on Rails チュートリアル. https://railstutorial.jp/ (lastaccessed 2018/12/25).
[9] Ken Schwaber, Jeﬀ Sutherland: スクラムガイド (2017).

Group Report of 2018 SISP

- 41 -

Group Number 14-C

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

付録 A 中間発表会で使用したプロジェクト全体のポスター

図 A.1 いさりび Graﬃti(中間発表会)

Group Report of 2018 SISP

- 42 -

Group Number 14-C

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

付録 B
スター

中間発表会で使用した本グループのポ2018.7.13

中間発表会

ビーコン IoT で函館のまちをハックする

いさりび Graﬃti

感じて、残して、つなげる。AR いさ鉄ノートGL佐藤登威 中田裕貴
Toi Sato

山口賢登 伊勢田蓮

Kento Yamaguchi

Yuki Nakata

Ren Iseda

概要 Overview
背景 Background

課題 Issue- 道南いさりび鉄道 ( いさ鉄 ) は豊富な観光資源があり、観光- 駅ノートはページが有限で紛失・盗難が起こりうる

列車と通学・通勤列車としての 2 面性がある。

-「駅ノート」などの鉄道での思い出を残したいニーズがある- South Hokkaido Railway (Isa-Tetsu) has lots of tourist attractions and there are 2
ways, tourist trains and commuting trains.
- Users want to leave the memories in trains, for example, “station notebooks”.

- 市民しか知らない観光資源や魅力が伝えにくい- Station notebooks have limited infomation and can be lost or stolen.
- It is diﬃcult to tell the users tourist attractions and charms citizens only know.

提案 Proposal- 列車や駅舎自体をノートとしてメッセージや写真、ビデオを投稿、閲覧できるサービス- 列車毎・駅毎の想い出ノートを「みんな」で作り上げる- 市民がもつ日々の想いと観光客をつなげる- AR×SNS による一体感の演出- The service that provides users to post message, pictures and videos as trains
and stations are like notebooks.
- “Everyone” creates their memory notes in the each train and stations.
- Connect between citizensʼdaily memories and tourists.
- Direction a sense of unity by AR×SNS.

アプリについて Application

駅・列車内のビーコンを受信

いさ鉄を満喫アプリで” 想い” を投稿

投稿された想い出を AR で閲覧

Receive beacon signals in stations and trains

Fully enjoy Isa-Tetsu

Post “memories” in the application

See the posted memories through AR

画面遷移 Screen transition

システム構成 Architecture

コンテンツの保存

コンテンツ配信 API

車両・駅の判別

Tangerine Hub

遠隔監視
ビーコン範囲内であることを通知

投稿・取得

投稿詳細

投稿

Posting

コンテンツのPosting detail

ビーコンの送出ホーム

Home
AR フレームワーク
検索

Searching

プロフィールProﬁle

図 B.1 いさりび Graﬃti(中間発表会)

Group Report of 2018 SISP

- 43 -

Group Number 14-C

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

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

図 C.1

Group Report of 2018 SISP

プロジェクト概要 (成果発表会)- 44 -

Group Number 14-C

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

図 C.2

Group Report of 2018 SISP

プロジェクト概要 (成果発表会)- 45 -

Group Number 14-C

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

図 C.3

Group Report of 2018 SISP

プロジェクト概要 (成果発表会)- 46 -

Group Number 14-C

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

付録 D
スター

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

図 D.1

Group Report of 2018 SISP

いさりび Graﬃti(成果発表会)- 47 -

Group Number 14-C