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

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

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

グループ名
MET.

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

7-A

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

None

プロダクトオーナー/Product Owner
久末瑠紅

Ryuku Hisasue

グループメンバー/Group Member
鈴木利武

Tom Suzuki

野間直生

Naoki Noma

指導教員
松原克弥 藤野雄一 鈴木昭二 奥野拓 鈴木恵二

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

提出日
2021 年 1 月 14 日

Date of Submission
January 14, 2021

概要
函館市には多様な観光資源があり，その魅力を活かす函館市総合計画という取り組みが行われている．本プロジェクトでは，ビーコンの特徴を活かすことで函館市による取り組みの一端を担うようなサービスを考案・開発することを目的としている．函館のまちをよく知らない状
態でサービスを提案してしまうと，実際に潜んでいる課題を見逃してしまう可能性がある．そのため，サービスを提案するにあたり，函館のまちの課題を発見するためにフィールドワークを行った．発見した課題をもとに，函館の魅力を引き出せるようなアイデアを創出した．創出
したアイデアをよりよくするために様々な観点に着目してブラッシュアップや絞り込みを行った．その結果，3 つのサービスを提案することに決定した．
（※文責: 荻ノ沢実佑）
函館は，
「食」
，
「歴史」
，
「景色」など様々な魅力を持っている．それらの魅力を活用すること
で，観光産業が函館市の基盤産業になっている．観光産業が衰退しないためには，何度も訪れてもらえるよう，様々な角度から魅力を発信し続ける必要がある．観光客が観光する際，情報を集めるタイミングは 2 つある．1 つは，事前に情報を集める方法，もう 1 つは，現地で情報を集める方法である．事前に情報を集めるためのサービスは，4travel.jp や Triple などのブログ形式のものが多く存在する．しかしながら，現地でインタラクティブに情報を集めながら，また自身の思い出帳を作成することができるサービスは存在しない．よって，観光しながら様々な情報を集めるユーザーに向けて，観光するルートの選択肢を増やしてもらうためのサービス「MET.」を考案した．前期の活動にてサービスの概要を決定し，後期の活動にてアプリ
ケーションの開発を行った．開発メンバーが 3 人と少人数であったため，メンバーの得意分野を活かし，効率的に活動することが求められた．そのため，タスクを週ごとに細分化し，メン
バー各々が効率的に行える作業を割り振った．そして，週ごとにメンバーと議論し，改善を繰
り返した．
キーワード

ビーコン IoT, 函館, 観光資源, 基盤産業, 旅行, 情報収集（※文責: 久末瑠紅）-i-Abstract
Hakodate City has a variety of tourism resources, and made ”Hakodate City Comprehensive Plan” for use the resources eﬀectively. We aim to devise and develop a service
that plays a part in the plan by utilizing the feature of beacons. If we propose a service
without knowing the city of Hakodate well, we may miss the issues that are actuallylurking. Therefore, for proposing the service, we conducted ﬁeldwork to discover theissues in the town of Hakodate. We created ideas based on the issues we discovered,that could bring out the charm of Hakodate. In order to improve the ideas we created,
we focused on various perspectives and reﬁned and narrowed down. As a result, we
decided to propose three services.
（※文責: 荻ノ沢実佑）

Hakodate City has various attractions such as ”food,” ”history,” and ”scenery.” Byutilizing these attractions, the tourism industry is a basic industry for Hakodate City.
In order to prevent the tourism industry from declining, Hakodate City has to continue
to disseminate the appeal from various angles so that sightseeners come to the City manytimes. There are two timings to gather information when tourists go sightseeing. One
is to collect information before the trips, and another is to collect information during
trips. There are many blog-style services such as 4travel.jp and Triple for collecting
information during sightseeing. However, there is no service that can create your own
memory book while sightseeing, and collect information interactively. Thus, we made a
service ”MET.” to increase the choices of sightseeing routes for users who collect various
information during sightseeners. We decide the outline of the service in 1st semester,and develop the application in 2nd semester. Since the number of members was three;
the number of members were too small, it was required to utilize the strengths of themembers to work eﬃciently. Therefore, we devide the tasks weekly, and each member
assigned tasks to make it done. Then, we discussed with the members every week andrepeated improvements.
Keywordinformation

Beacon IoT, Hakodate, tourism resources, basic industry, trips, getting（※文責: 久末瑠紅）- ii -

目次
第1章

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

1

1.1

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

1

1.2

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

1

1.3

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

1

1.4

本プロジェクトの活動の進め方 . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.4.1

本プロジェクトにおける開発着手前の手法 . . . . . . . . . . . . . . . . .

2

1.4.2

本プロジェクトにおける開発手法 . . . . . . . . . . . . . . . . . . . . . .

3

本プロジェクトのロゴについて . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

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

5

1.5

1.5.1
第2章

提供サービスの考案プロセス

72.1

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

7

2.2

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

7

2.2.1

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

7

2.2.2

フィールドワークに関するレクチャー . . . . . . . . . . . . . . . . . . . .

7

2.2.3

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

8

2.2.4

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

8

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

9

2.3.1

アイデア考案に用いた手法 . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.3.2

中間発表時の外部レビュー . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.3.3

プロジェクトでの内部レビュー . . . . . . . . . . . . . . . . . . . . . . .

11

2.3.4

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

11

2.3.5

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

12

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

12

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

12

2.3

2.4

2.4.1
第3章

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

14

3.1

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

14

3.2

課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.3

サービスについて. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.3.1

概要

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

14

3.3.2

サービス名の由来 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

3.4

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

15

3.5

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

15

3.5.1

みんなの思い出帳 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.5.2

今回の思い出帳. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.5.3

自分の本棚 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

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

17

3.6

- iii -

第4章

4.1

4.2

4.3

第5章

開発プロセス

18

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

18

4.1.1

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

18

4.1.2

夏季休暇期間中の勉強会 . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

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

21

4.2.1

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

21

4.2.2

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

21

4.2.3

ユーザーストーリーの作成とタスクの洗い出し . . . . . . . . . . . . . . .

23

4.2.4

スプリント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

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

23

4.3.1

効果

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

23

4.3.2

課題

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

24

4.3.3

解決策 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

サービスの実装

25

5.1

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

25

5.2

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

25

5.3

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

28

5.3.1

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

28

5.3.2

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

29

5.3.3

API

31

5.3.4

導入ライブラリ

5.4

第6章

6.1

6.2

第7章

7.1

7.2

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

33

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

34

5.4.1

サービスロゴ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.4.2

アプリケーションロゴ . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.4.3

アプリケーションデザイン . . . . . . . . . . . . . . . . . . . . . . . . . .

35

5.4.4

アプリケーション内アイコンデザイン . . . . . . . . . . . . . . . . . . . .

35

成果報告会

37

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

37

6.1.1

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

37

6.1.2

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

38

6.1.3

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

39

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

40

6.2.1

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

40

6.2.2

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

43

各メンバーの振り返り

45

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

45

7.1.1

久末瑠紅 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

7.1.2

鈴木利武 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

7.1.3

野間直生 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

久末瑠紅の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47- iv -

7.3

鈴木利武の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

7.4

野間直生の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

まとめと展望51

8.1

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

51

8.2

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

52

8.3

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

52

8.3.1

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

52

8.3.2

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

53

第8章

参考文献

55

付録 A

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

56

付録 B

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

57

-v-

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

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

背景

近年，通信技術の向上や通信機器の小型化・低コスト化のため IoT が普及している．[1]IoT デバイスの 1 つとして BLE ビーコンがある．BLE ビーコンとは，低消費電力の近距離無線技術「Bluetooth Low Energy」（BLE）を利用したデバイスのことである．スマートフォンなど BLE 対応デバイスを所持していれば，誰でも利用可能である．BLE ビーコンを利用したサービスとして，
人やモノの位置情報を可視化する屋内位置情報サービス「Beacapp」や，自動販売機にスマートフォンを接続してドリンクを購入することでお得にドリンクを入手することができる「Coke On」などが存在する [2][3]．この他にも様々なサービスやアプリケーションが創出されている．そして，
今後もその数は増加していくと考えられる．それに伴い，需要も高まっていくと期待できる．そこで，函館のまちの様々な場所にビーコンを配置することで，函館の魅力を伝える新しいサービスの提供が可能になる．
函館市には，自然，歴史，文化，食など幅広い観光資源が存在する．自然については，函館山からの夜景や，活火山の恵山などの雄大な自然の景色を楽しめる．歴史，文化については，五稜郭跡
や軍事要塞跡をはじめ旧函館区公会堂など多くの歴史的建造物が存在するため，幕末から明治，大正と様々な時代の歴史を知ることができる．食については，函館市は海に囲まれているため，豊かな漁場から獲れる海産物を使った海鮮を食べることができる．また，函館朝市や地元の食材を使用したレストランなども存在する [4]．このように函館市は観光資源にあふれた観光都市であるといえる．この多様な観光資源をより多くの人に伝えるためにも，多角的に魅力を発信し，磨きをかけていく必要がある [5]．その方法の 1 つとしてビーコンを活用する．函館の様々な観光資源とビーコンを組み合わせることによって，函館の魅力をさらに引き出すサービス展開ができる．
（※文責: 荻ノ沢実佑）

1.2

目的

本プロジェクトの目的は，ビーコンを用いて函館のまちの様々な魅力や新たな価値を生み出すことである．ビーコンの特徴を活かしつつ，函館の魅力をさらに引き出せるようなサービスを考案する．
（※文責: 荻ノ沢実佑）

1.3

ビーコンについて

BLE ビーコンとは，BLE に準拠した Bluetooth の電波を発信する機器であり，端末ごとに固有の情報を保持している [6]．以後、本報告書で述べるビーコンは，BLE ビーコンを指す．スマートフォンなどの電子端末でビーコンの電波を受信・検知することにより，固有 ID や受信電波強度などの情報を取得することが可能になる．BLE ビーコンには Apple 社が提供する iBeacon，LINE

Group Report of 2020 SISP

-1-Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4社が提供する LINE Beacon など様々な規格がある．iBeacon は，固有 ID や信号強度などの情報を持っている [7]．その情報を利用することで，距離測定や領域内の入出の監視などをを行うことができる．LINE Beacon は，コミュニケーションアプリ LINE がインストールされているスマー
トフォンに対して，広告やプッシュ通知を送信することができる [8]．
（※文責: 荻ノ沢実佑）

1.4

本プロジェクトの活動の進め方

1.4.1

本プロジェクトにおける開発着手前の手法

本プロジェクトでは，プロジェクトを円滑に進めるべく，開発着手前から独自の試みを多く行っていた．以降では，行った試みについて，それぞれ説明する．
（※文責: 大石晃平）

週ごとのファシリテーター制度
本プロジェクトではプロジェクトリーダーを決めなかった．今年度は前期の活動が全面オンラインであったため，当初はプロジェクトメンバーのことをお互いによく知らなかった．そのような状態で，本プロジェクトの責任を負うリーダーを決めるのは難しいと考えた．したがって，本プロ
ジェクトでは，前期の活動を通じて互いのことを理解してから，プロジェクトリーダーを定めるかどうかを判断することに決定した．ただし，各週のプロジェクト活動の進行を担う人は決める必要があった．そのため，毎週最後のプロジェクト活動時に，次週の進行を担うファシリテーターを 2人決定した．ファシリテーターは，公平性を保つためあみだくじなどを用いてランダムで決定していた．この決定方法には，全員に等しくプロジェクトをファシリテートする経験をさせることなどの狙いがあった．
しかし，ファシリテーターの役割が明確ではなかったため，仕事量が多くなり，メンバーがファ
シリテーターになることに抵抗感を覚えた．加えて，週ごとにファシリテーターが変わってしまう
ため，自分の担当した週以外ではあまりファシリテーターの活動に責任を持って活動ができていな
かった．そのため，前週に行った活動内容の引き継ぎがされず，活動が右往左往してしまった．
これらの問題点から，開発着手後は，様々なことに担当大臣を任命し，その担当大臣が中心となって，任命された職務を進めていく「担当大臣制度」という独自の手法を取り入れた．ファシリテーターの役割は，「進行担当大臣」が担い，毎週のプロジェクト活動のアジェンダ作りや進行を行った．上記の反省点を活かして，全体的にプロジェクト全体に対しての関心が深まり，全員がより責任を持って活動することができた．
（※文責: 大石晃平）

疑似的バックログの作成と全員での意思決定「週ごとのファシリテーター制度」で述べたように，本プロジェクトでは週ごとのファシリテー
ター制度を取り入れていたため，全体の活動を統括するような役割を担う人が不在の状態であった．そのため，プロジェクトでの活動の見通しを全体で共有して持つことができるように，全員で疑似的バックログを作成した．週ごとにファシリテーターが変わるため，スケジュールを細かく決Group Report of 2020 SISP

-2-Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
めても，その通りに物事が進む可能性が低い．したがって，週ごとで柔軟に対応可能にさせるた
め，バックログを採択した．また，なにかを決定する際には，極力全員での意思決定をして，活動を行った．全員での意思決定を大切にした理由には，プロジェクトリーダーの決めていないチーム
において，全員の意思での決定を行えば不平不満が出さずに活動できるのではないかという狙いがあった．
疑似的バックログは，作成する際に全員で行い，活動の見通しを持つという意味では活かすことはできたが，それ以上は活用することはできなかった．そのため，すべての工程を計画し，その工程に沿ってプロジェクトを進めていってしまうこともあった．結果的に，疑似的バックログを作った理由である，柔軟に活動することができていない部分もあった．また，疑似的バックログでは，それぞれタスクにどのくらいの期間を有するかやそれに向けての心理的な問題点がどれくらいあるのかを数字などで表す，重みづけを行った．しかし，その重みづけもしただけになってしまい，それぞれのタスクに対して振り返りをしなかった．そのため，その重みづけが正しいのかを判断することもできずに進んでしまった．全員での意思決定は，意識的に行っており，全体的にできていたため，全員が活動に対しての納得感や満足感はあった．しかし，一回一回の意思決定で時間がかかってしまい，円滑に活動を進めることはできなかった．
これらの反省点を活かして，開発着手してからはそれぞれのサービスごとにバックログ作りに工夫を凝らし，より円滑に開発を進めることができた．また，意思決定の方法も「d」という言葉をチャットや体で表現をすれば，その意見に対して合意であるなどの独自の決定方法を作成することによって，円滑に進めることができた．
（※文責: 大石晃平）

1.4.2

本プロジェクトにおける開発手法

アジャイル開発
本プロジェクトでは，ソフトウェア開発の手法の 1 つである，アジャイル開発を導入した．ア
ジャイル開発とは，プロセスやツールよりも個人と対話を，包括的なドキュメントよりも動くソフ
トウェアを，契約交渉よりも顧客との協調を，計画に従うことよりも変化への対応を価値とした開発手法である [9]．小さな単位での計画・設計・実装・テストを繰り返すことにより，継続的に動く
ソフトウェアを提供し続けることができる．また，できるだけ短い期間で上記のプロセスを繰り返し，関係者からのフィードバックを継続的に得ることで，トラブルや仕様変更に柔軟に対応することができる．これらのことから，開発初期から継続して価値のあるソフトウェアを作り続けることができると考え，この手法を採用した．
（※文責: 袴田結女）

スクラム
本プロジェクトでは，アジャイル開発を導入するにあたり，アジャイル開発の手法の 1 つである
スクラムを採用した．Ken Schwaber らによると，スクラムとは「複雑な問題に対応する適応型のソリューションを通じて，人々，チーム，組織が価値を生み出すための軽量級フレームワークである」と定義されている [10]．スクラムでは，スクラムチームと呼ばれる，小さなチームを構成することが定められている．スクラムチームは，プロダクトオーナー 1 人，スクラムマスター 1 人，複Group Report of 2020 SISP

-3-Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
数人の開発チームから構成される．プロダクトオーナーとは，プロダクトの責任者であり，プロダ
クトの価値を最大化する責任がある．後述するプロダクトバックログの管理の責任者でもある．ス
クラムマスターは，スクラムというフレームワークを円滑にまわすことに責任を持つ．スクラムのルールをスクラムチームに理解させることや，スクラムチームを妨害から守ること，スクラムチー
ムが円滑に作業を進められるよう支援するというような役割をもつ．開発チームは，プロダクトの開発を行う役割であり，通常 3 人から 9 人までで構成される．開発チームは，機能横断的であり，プロダクトを作るために必要な作業をすべて行うことができなければならない．「コードを書く」
や「UI/UX の設計を得意とする」というように，開発チームの各メンバーが所有する能力やスキルで，開発に必要なすべての作業を行うために協力し合う．また，開発チームにおける作業は，外部からの指示を受けることはなく，チーム全体が責任を持ち，主体的に行う．
スクラムでは，実現したい機能を，価値やリスク，必要性などを基準に並べ替えたプロダクト
バックログと呼ばれるリストを作成する．プロダクトバックログ項目の作成や更新，並び順はプロ
ダクトオーナーが最終決定権を持つ．プロダクトバックログの各項目は，ユーザーストーリー形式
で書かれることが多い．ユーザーストーリーとは，実際に使う人たちの視点に立って，実現したい
ことを簡潔に記述したものである．プロダクトバックログを作成することによって，実現すべき機能の順番が明確化する．この順番が上位の機能から開発に取り掛かることで，成果を最大化することができる．
また，スクラムでは最長 1 ヶ月までの固定の期間に区切って，開発を繰り返す．この固定の期間をスプリントと呼ぶ．この期間内に，小単位での計画・設計・実装・テストを行い，プロダクト
バックログの機能を完成させる．これを繰り返すことで，段階的に，そして継続的に動くソフト
ウェアを提供し続けることができる．スプリント内で機能の実装を目指すために，スプリントプラ
ンニング，デイリースクラム，スプリントレビュー，スプリントレトロスペクティブの 4 つのスク
ラムイベントを行う．
スプリントプランニングとは，スプリントを開始するにあたって行われる，スプリントで実行する作業を計画するミーティングである．このミーティングでは，「そのスプリントになぜ価値があるのか（why）」，「そのスプリントで何をするのか（what）」，「決めた作業をどのように成し遂げるか（how）」の 3 つのトピックについて話し合い，決定する．1 つ目のトピックでは，スプリント
ゴールと呼ばれる今回のスプリントの目標を決定する．2 つ目と 3 つ目のトピックでは，プロダク
トバックログから今回のスプリントで開発できそうな機能を検討し，スプリントバックログを作成する．スプリントバックログとは，選択した実装したい機能と，そのための具体的な作業と計画のことである．次に，デイリースクラムとは，スプリント期間中，毎日同じ場所・同じ時間で行う

15 分のミーティングのことである．開発メンバー全員で「昨日何をしたか」，「今日何をするか」，「困っていること」を共有し，スプリントゴールが達成できるかを確認するためのものである．また，スプリントレビューとは，スプリント終了時にスプリントの成果をステークホルダーに披露したり，プロダクトの状況や進捗を報告したりするイベントである．ステークホルダーからのフィードバックに基づき，プロダクトバックログを見直し，今後やるべきことに取り組むことができるよ
うになる．最後に，スプリントレトロスペクティブとは，今回のスプリントにおける活動を振り返り，次回のスプリント以降のアクションプランを考えるミーティングである．うまくいったことや問題点を話し合い，もっと成果が出せるよう改善を続けることで，スクラムチームの成長が期待される．
このように，ユーザーからのフィードバックをもとに，柔軟に計画を変更しながらより良い機能を実装し続けることができると考え，本プロジェクトではスクラムを採用した．

Group Report of 2020 SISP

-4-Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4（※文責: 袴田結女）

1.5

本プロジェクトのロゴについて

1.5.1

ロゴ作成

本プロジェクトでは，プロジェクトの特徴やイメージを表現するため，加えて議論の練習と，メンバー全員の一体感を生むために，今年度のプロジェクトのロゴを制作した．ロゴの制作期間は 3週間であった．まずはじめに，メンバー全員がロゴ案を 1 案以上考案してロゴ案の発表会を行い，それぞれの案についてレビューを行った．この段階ではそれぞれの案の良い点だけを伝える形式をとった．良い点のみを伝える目的として，作成者本人のモチベーションの維持，さらには他のロゴ案の良い点を各自のロゴ案に取り入れやすくするといった 2 つの目的があった．ここで受けたレビューと，他のメンバーのロゴ案を参考に，各自のロゴ案の改善をし，2 回目の発表会を行った．
この発表会のレビューでは，良い点に加えて改善点の指摘を含めたレビューを行い，その後投票によって 4 つのロゴ案に絞り込んだ．投票は「サービスの函館らしさ」，「ビーコンらしさ」の 2 つの観点を持って行われた．これらの観点は，函館のまちをコンセプトにしたサービスの開発をする宣言として，他のプロジェクトとの差別化を行うものとして設けた．発表会で得られたレビューをもとに，再度ロゴ案の改善を行い 3 回目の発表会を行った．この発表会後，前回と同じ観点を持ち，メンバー，TA，先生を交えて最終投票を行って今年度のロゴを決定した．その後，ロゴに関するワーキンググループを結成し，デザインの微調整や，色の確定を行うために，デザイン原案の改善を行った．最後に，ロゴデザインの完成版と，ロゴのカラーコードやフォント，フォントサイズ，
使用上の注意点などを記載した，ロゴ使用に関するガイドラインを作成した．
（※文責: 伊藤直樹）

Group Report of 2020 SISP

-5-Group Number 7-A

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

図 1.1

Group Report of 2020 SISP

ロゴガイドライン-6-

Group Number 7-A

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

第 2 章 提供サービスの考案プロセス
2.1

プロセス概要本プロジェクトの提供サービスの決定までのプロセスは，大きく 2 つに分かれる．1 つ目は，
フィールドワークに関わるプロセスである．函館やその周辺地域で実際にフィールドワークを行い，課題や気づきを発見・共有した．2 つ目は，サービスの考案に関わるプロセスである．フィー
ルドワークでの結果をもとに，アイデアを考案した．考案したアイデアを 8 つに絞り込み，中間発表でレビューを実施した．そこで受けたレビューをもとに，再度アイデア出しを行った．考案したアイデアについて，プロジェクトメンバー，担当教員，OG・OB に向けてプレゼンを行った．そこで得られた評価をもとに，提供する 3 サービスを決定した．上記のプロセスのほかに，ビーコンの事前学習や，グループ C では，はこだて自由市場でのインタビューを行った．ここからは，フィールドワーク，サービスの考案，その他の 3 つに分けて，詳細を説明する．
（※文責: 袴田結女）

2.2

フィールドワーク

2.2.1

事前調査

函館やその周辺の地域に存在する問題や課題を把握することが目的であるフィールドワークを行うために，それらについての事前調査を行った．はじめに，フィールドワークを行う函館の地域を「五稜郭」，「赤川・美原・昭和・富岡」，「函館駅・西部地区」，「七飯・北斗」，「空港・湯の川」の5 つに分けた．地域ごとにグループを分け，調査を通して得られた地域のイメージを，ブレインス
トーミングを行って書き出した．そして，書き出した各イメージについて様々な視点からグルーピングを行い，実地調査を行う際に注目する点を確認した．その後，各地域の実地調査を行うグループを編成し，実地調査を行った．COVID-19 の感染拡大を抑制するために，3 人 1 グループとして，人数を抑えてグループを編成した．
（※文責: 石澤大輔）

2.2.2

フィールドワークに関するレクチャー

フィールドワークの実施にあたり，40 分ほどの動画にて南部美砂子先生よりフィールドワークについてのレクチャーを受けた．レクチャーでは，まずフィールドワークとはどのようなものなのかという説明があった．ただ街を歩いて見たり聞いたりするだけではなく，情報を得て整理し，考えて結論を出し，他者に伝達して行動することが大事であると学んだ．次に，COVID-19 の影響の下でのフィールドワークについての説明があった．COVID-19 の影響でフィールドに行けないということではなく，この COVID-19 が蔓延しているという環境そのものがフィールドであると学んだ．また，フィールドワークは目的ではなく手段の一つであり，フィールドワークの目的の一つ

Group Report of 2020 SISP

-7-Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
は他者の合理性の理解であるということを学んだ．最後に，フィールドワーカーとしてのあり方についての説明があった．調査者は基本的に特権的存在であり，迷惑な侵入者という意識を持って調査を行うべきであるということや，守秘義務や匿名性，調査の説明や同意などに注意するべきであるということを学んだ．
（※文責: 石澤大輔）

2.2.3

実地調査

実地調査は，プレ調査と本調査の 2 回実施した．プレ調査は，本調査に向けて調査情報の記録，共有の方法について確認することを目的として，6 月 19 日に函館山で実施した．本調査は，「2.2.1
事前調査」で述べた 5 つの地区で 5 つのグループに分かれて 6 月 21 日に実施した．プレ調査の振り返りを行い，本調査での情報の記録は，メモだけでなく，リアルタイムで共有を行うことで，ほかの地域ではどのような発見があったのかを確認することができることから，Slack に各グループのチャンネルを作成し，写真や文章を貼ることとした．また，調査実施にあたり，COVID-19 感染への対策として体調の管理やマスク着用必須，人混みや他人との接触・会話を避けるなど注意することとした．調査場所に関しては，我々のプロジェクトが函館の観光や街の課題を探索し，見つけた課題に対して，ビーコンを用いて解決していくということを目的としているため，これを満たすために，観光地として取り上げられる一部地域だけでなく，函館の街全体を調査の対象とした．五稜郭地区では，五稜郭公園，五稜郭タワー，五稜郭交差点地下横断歩道，千代台公園，JR 五稜郭
駅，函館市中央図書館，六花亭で主に調査を行った．赤川・美原・昭和・富岡地区では，四季の杜
公園，笹流ダム，四稜郭，住宅街で主に調査を行った．函館駅・西部地区では，函館駅周辺，金森
赤レンガ倉庫，朝市，西部地区で主に調査を行った．七飯・北斗地区では，男爵ラウンジ，なないろ・ななえ，新函館北斗駅，大沼公園，山川牧場で主に調査を行った．空港・湯の川地区では，あいす 118，函館空港，トラピスチヌ修道院，香雪園，植物園，函館公園，十字街で主に調査を行った．
（※文責: 山本雄平）

2.2.4

振り返り

調査で得た情報をまとめてほかの班と共有するため，各グループで調査中に気づいた点について，Google Jamboard に写真や付箋を用いて書き出しを行った．その後，書き出した写真や付箋をグループ分けをした．グループ分けは，班員それぞれが気づいた点を調査グループ内で共有すること，発表を行うときに，何処に行って，どのような気づきが得られたかを共有しやすくすることを目的とした．グループ分けは，班員がそれぞれで気づいた点の書き出しを行った後，それぞれの気づいた点を五稜郭や朝市など場所ごとで行った．グループ分けが完了したあと，Zoom の画面共有機能を用いて，1 グループずつ，調査結果をまとめた Google Jamboard を見せながら発表した．
プレ調査では，函館山を訪れた．調査の結果，展望台やロープウェイにはビーコンが設置されていること，山でも GPS が利用できること，登山道の一部ではソーシャルディスタンスが保ちにくい
こと，登山道が多く，迷いやすいことなどがわかった．本調査では，「2.2.1 事前調査」で述べた 5つの地区を訪れた．調査の結果，五稜郭や函館駅，湯の川周辺などの主に観光地で，時短営業や観光客の減少などの COVID-19 の影響が見られること，夏にマスクを着用しながら歩き回るのはつらいこと，函館駅・西部地区では多くの撮影スポットがあること，公園では年配の方が多いことなGroup Report of 2020 SISP

-8-Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4どがわかった．これらの気づきについて組み合わせを考えたり，グルーピングを行い，さらに議論を通じてアイデアの考案を行った．
（※文責: 山本雄平）

2.3

サービスの考案

2.3.1

アイデア考案に用いた手法

BSKJ 法（ブレインストーミング KJ 法）
調査と振り返り後，ブレインストーミングを踏まえて BSKJ 法を行った．BSKJ 法とは，思いつく限り多くの量のアイデアを出すというブレインストーミングと，それらを付箋等にアウトプッ
トして得られたアイデアを整序しグルーピングを行う KJ 法と組み合わせた方法である [11]．今回
は 4 人 1 グループを 3 グループ作成した．また，1 グループを 4 人に設定したのは，グループごとに異なるアイデアを出すことができ，後述する「OST（オープンスペーステクノロジー）」を実施
することから，ほかの班のアイデアを見ることで新たな発見ができると考えたためである．グルー
プごとにフィールドワークの共有結果を見ながら，Google Jamboard で付箋にアイデアを書いて，貼り付けを行った．その後，乗り物，観光地，聖地巡礼，植物や動物などの様々な観点でグルーピングを行った．
（※文責: 山本雄平）

ハッカソン方式
ハッカソンはハックとマラソンを掛け合わせた造語である．本来のハッカソンの内容はチームで短期間でサービスやシステム，アプリケーションを開発し，成果を競うものとなっている．この方
式は時間制限を設けることで，プレッシャーを与え，その結果，良いアイデアが出るのではという期待を込めて取り入れた．私たちは時間制限設けること，文字よりも絵の表現のほうがアイデアのイメージより相手に伝わると考え，アイデアの絵を描くことをルールとして設けて，これをハッカソン方式とした．この方式を中間発表前と夏季休業期間のアイデア出しの 2 回用いた．1 回目
は BSKJ 法のグループと同時並行で 90 分という時間制限を設けて 4 人 1 グループでアイデア出しを行った．2 回目は参加者が順番に出題し，5 分の時間制限を設けてお題に沿ったアイデア出しを行った．実際に絵に起こすことで，アイデアを視覚的に理解できるので，イメージをつかみやす
く，アイデア共有がしやすくなった．
（※文責: 山本雄平）

OST（オープンスペーステクノロジー）
BSKJ 法とハッカソン方式を行った後に，関心のあるテーマについてに考え，より深い意見にするために OST を実施した．OST とは，参加者が自ら議題を設定，または，参加する議題について自発的に選択することで議論を進めていく方法である [12]．OST の特徴は，参加人数，時間やスペースの制限がないということである．参加者自身で議題を選択することから，議題によって，人数にばらつきがある．また，ほかの議題への移動も参加者に委ねられているため，時間を自由に使って議論をした後，ほかに議題に移動することができる．今回は BSKJ 法 3 グループ，ハッカソGroup Report of 2020 SISP

-9-Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
ン方式 1 グループでそれぞれ部屋を作成し，プロジェクトメンバーは興味のあるアイデアを探し，議論を行った．興味のあるアイデアについて議論する時間に制限は設けず，考えがまとまったらほかのアイデアを探す．これを繰り返し，それぞれのアイデアを深めていった．また，他グループのアイデアの発想を持ち帰り，グループのメンバーに共有し，さらに議論を繰り返すことで，一つ一つのアイデアを具体的にすることができた．OST を実施した結果，斬新なアイデアや何か要素を加えることで発展しそうなアイデアに関しては，議論が進んだものと，既に実装されているものに近いアイデアなど人が集まらず，議論がされなかったものとで明確に分かれたので，その後に行われたアイデアの絞り込みを容易に行うことができた．
（※文責: 山本雄平）

2.3.2

中間発表時の外部レビュー

中間発表時に提案する仮アイデアとして，OST を用いて「俺を食ってくれぇ!!」，「カラオケ×
ビーコン」，「観光客×地元民」，「函館のここ，おすすめかも」，「目の前のイベントは何？」，「クー
ポン長者」，「五稜郭地下歩道の活性化」，「未来大のライブラリをよくしよう！」の 8 つに絞り込んだ．

1. 海産物自身が最適な調理法をアピールしてくる「俺を食ってくれぇ!!」
2. カラオケ店で注文や清算をスマホを通じてできる「カラオケ×ビーコン」
3. 地元をよく知る人をビーコンで探して質問できる「観光客×地元民」
4. 行動履歴をもとに，おすすめのお店を紹介する「函館のここ，おすすめかも」
5. 大道芸などの突発的なイベントの情報を得ることができる「目の前のイベントは何？」
6. お店を訪れた人に他店のクーポンを配る「クーポン長者」
7. 地下歩道のマップや周辺店舗の情報を表示する「五稜郭地下歩道の活性化」
8. 見つけたい図書の位置を教えてくれる「未来大のライブラリをよくしよう！」
サービスの選定のため，これらの仮アイデアについて，中間発表で評価を依頼した．8 つの仮アイ
デアについて，「使ってみたいと思えるものはどれか」，「使ってみたいと思った理由や気になった点」について，Google Forms での発表評価シートで回答を依頼した．中間発表で得られた評価は以下が挙げられる．

• 俺を食ってくれぇ!! : 普段やったことない調理方法を見て買おうと思う主婦には響くアイデ
アだと思ったけど，そもそも目が肥えてる主婦はアプリ見なくても鮮度とか調理方法とかわかるかも．どんな人に使ってほしいのかをもう少し詳しく知りたい．

• カラオケ×ビーコン : 時代に合ったアイデアで良いですね．函館のカラオケでは入店する
前に駐車場に車を停める人も居るので，駐車場に居る段階でカラオケの混雑状況を知ることができれば感染リスクを避けるという意味では安全につながるかも．

• 観光客×地元民 : 地元の人と観光客を結びつけるという考えは興味深かったです．でも，突然観光客に話しかけられるのは少し怖い面もあるかなと思いました．

• 函館のここ，おすすめかも : 函館に来て数年経っても行ったことがない場所がたくさんあるため，新しい場所を開拓するのに使ってみたいと思いました．

• 目の前のイベントは何？ : よくわからないイベントも多く開催されているので情報は調べ
たい．

Group Report of 2020 SISP

- 10 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4• クーポン長者 : クーポンの力を利用して連鎖的にお店の売り上げを上げるという考えがナイスだと思いました．しかし，あそこのクーポンが欲しいからここで何か買わないといけな
いという展開になってしまう気がするので，多くの人がどうしたら利用するか深く考える必要があると思いました．

• 五稜郭地下歩道の活性化 : 五稜郭の交差点の地下歩道は，確かに，空間的には広いので，いろいろ活用が見えると面白いかも，と思いました．

• 未来大のライブラリをよくしよう！ : 未来大のライブラリーが，COVID-19 の影響で，当初の使い方が出来なくなっているので，何か突破口になるようなアイデアがあると面白いかもしれません．
また，8 つの仮アイデア全体を通じて，詳細な情報まで決定していなかったことから，「個々についてアイデアについて説明が少なくて，正直，選択するのが難しいです．
」や，「ユーザーがなぜそのアプリを使うのかというユーザーのインセンティブが強く訴えられているとよいと思いました．
」という意見も得られた．
（※文責: 袴田結女）

2.3.3

プロジェクトでの内部レビュー

中間発表終了後，新たにアイデア出しを行った．アイデアを評価する際に，本プロジェクトの目的を達成するようなサービスの基準を話し合い，「サービスの函館らしさ」，「ビーコンである理由」，「サービスの必要性」，「サービスの新規性」，「サービスの不変的な魅力（継続性）」の 5 つに定めた．
「サービスの函館らしさ」は，函館市による取り組みの一端を担うためである．「ビーコンである理由」は，ビーコンを用いたサービスを考案・開発することが本プロジェクトの目的であり，ビーコンの特徴を活かしたサービスを提供すべきであると考えたためである．「サービスの必要性」は，需要のあるサービスを提供したいと考えたためである．「サービスの新規性」は，ユー
ザーに今までにしたことのない体験をしてもらいたいと考えたためである．「サービスの不変的な魅力（継続性）」は，考案したサービスを継続して使ってもらいたいためである．以上の理由より，
これらの 5 つをアイデアを評価する際の観点として定めた．考案した 29 個のアイデアに対し，プロジェクトメンバーが，5 つの基準を満たすかどうかを議論し，満たさないものはそれを補う案を検討した．また， 29 個のアイデアのうち，新たに考案した 21 アイデアに対し，担当教員と TA から，上記の 5 つの観点でフィードバックを得た．担当教員と TA からのフィードバックと，5 つの観点を満たせるかどうかを踏まえ，29 個のアイデアから 21 個のアイデアに絞り込んだ．
（※文責: 袴田結女）

2.3.4

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

プロジェクトの内部レビューの後，それぞれのアイデアが 5 つの観点をどのように満たしているのかを記述したドキュメントを作成し，それをもとに，KJ 法などを用いて 8 つのアイデアに絞った．また，それぞれのアイデアに興味のあるプロジェクトメンバーを偏りの少ないように振り分
け，各グループの詳細なサービス案についてのブラッシュアップを行った．各グループごとに詳細なサービス案や 5 つの観点に対するサービスの強みをまとめたスライドを作成し，プロジェクト内Group Report of 2020 SISP

- 11 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
でプレゼンテーションを行った．評価の方法として各アイデアに対して「サービスの函館らしさ」，「ビーコンである理由」，「サービスの必要性」，「サービスの新規性」，「サービスの不変的な魅力」の観点から意見を出し合い，アイデアをさらに絞った．最終的なアイデアは，「ビーコンバトラー」，「俺を食ってくれぇ!!」，「造語シェア」，「函館のここ，おすすめかも」，「未来大のライブラリをよくしよう」，「函館を舞台とした ADV」の 6 つでそれらの改善を行った．
（※文責: 大石晃平）

2.3.5

テーマの決定アイデアのブラッシュアップを終え，最終的に出揃ったアイデアをスライドにまとめ，各アイ
デアについてのプレゼンテーションと評価を行った．また，担当教員，TA の方からも評価を受けた．評価の方法としては，各アイデアに対して，「サービスの函館らしさ」，「ビーコンである理由」，「サービスの必要性」，「サービスの新規性」，「サービスの不変的な魅力」の 5 つの観点について，1〜10 点の 10 段階で点数づけを行った．採点結果は，表 2.1 に示す．プレゼンテーションを行った
アイデアは，「ビーコンバトラー」，「俺を食ってくれぇ!!」，「造語シェア」，「函館のここ，おすすめ
かも」，「未来大のライブラリをよくしよう」，「函館を舞台とした ADV」の 6 つであった．

1. 函館のまちを自由に散策し，観光をしながらパズルのピースを集め，観光地に思い出を残す
ことができるサービス「ビーコンバトラー」

2. 函館の海産物自身が鮮度に応じて，適切な調理法をアピールしてくるサービス「俺を食ってくれぇ!!」

3. 観光地や景色の良いところで，感じたことなどをまだない言葉で表現し投稿・シェアすることができるサービス「造語シェア」

4. 観光客が，函館の街を歩くことで，行動履歴をもとに，訪れた店との関連性や好みに合わせてお店を提案するというサービス「函館のここ，おすすめかも」

5. 未来大のライブラリの本を，楽しくかつ簡単に探すことができるサービス「未来大のライブ
ラリをよくしよう」

6. 函館を舞台としたゲームを作成し，その場所に実際に訪れることで獲得できる追加のコンテ
ンツによって，函館のまちの活性化を促すサービス「函館を舞台とした ADV」
これらのサービスについての得られた評価の結果を踏まえ，自分たちがどのアイデアの開発に携わりたいかという観点で投票を行い，「俺を食ってくれぇ!!」，「ビーコンバトラー（のちに「でももに！」）」，「函館のここ，おすすめかも（のちに「MET.」）」の 3 個のアイデアを今年度のプロジェ
クト学習で開発することに決定した．
（※文責: 大石晃平）

2.4

その他

2.4.1

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

本プロジェクトではビーコンを使用した開発をおこなうために，ビーコンに関する知識を深める必要があると判断し，事前調査をおこなった．事前調査は「近接・位置測位」，「GPS との機能・特Group Report of 2020 SISP

- 12 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
表 2.1

各アイデアの評価の平均

アイデア名

函館らしさ

ビーコンである理由

必要性

新規性

不変的な魅力ビーコンバトラー

6.63

8.74

7.16

7.47

7.21

俺を食ってくれぇ!!

7.30

8.05

7.70

8.75

7.30

造語シェア

5.19

5.95

5.81

8.67

6.52

函館のここ，おすすめかも

6.80

6.10

7.45

7.55

7.35

6.10

7.50

7.30

7.15

7.80

6.24

5.38

5.43

7.33

5.38

未来大のライブラリをよくしよう
函館を舞台とした ADV，「各種センサーとの連携」，「LINE Beacon」，「適用事例」の 5 つの項目についておこなっ性比較」
た．ビーコンを扱う上で一番必要な知識であろう「近接・位置測位」や，似た機能をもつ GPS との違いを把握するために「GPS との機能・特性比較」を検討した．また，ビーコンの中でも，特徴の一つであるほかのセンサーとの連携についてより深く知り，サービスの特色を出すため「各種センサーとの連携」，iBeacon をはじめとしたほかのビーコンとは利用方法が異なる「LINE Beacon」
についての検討も行った．さらに，実際の利用方法をもとにアイデアを膨らませるために「適用事例」も調べることにした．その際，本プロジェクトは 15 名で構成されるグループであったため，各項目にメンバーを 3 名ずつ割り振って調査を行い，調査した内容を各グループごとにスライドにまとめ，共有した．この事前調査を行うことによって，ビーコンの特徴やビーコン特有の機能など，様々な知識を会得することができた．サービスを考案する中で，GPS や RFID タグでも実装できるアイデアが多くなり，”ビーコンらしさ”という点が薄れてしまったため問題となった．しかしながら，事前調査を行うことによって，圧力センサー付きビーコンを利用したアイデアの検討な
ど，GPS や RFID タグでは実現できないサービスの検討に一役買ったと考えている．
（※文責: 増田翔）

Group Report of 2020 SISP

- 13 -

Group Number 7-A

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

第3章
3.1

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

観光産業は，函館市にとって重要な基盤産業である．令和元年度における観光客入込客数は，合計約 536 万 9 千人であり，札幌に続き第 2 位 [4] であった．この数字は，
「食」
，
「歴史」
，
「景色」な
どの函館の魅力によって実現している．食という点では，函館市は海に面していることで，新鮮でおいしい海産物を食べることができる．また，歴史に残る出来事が数多くあったため，歴史的建造物も多数存在している．さらに，「函館の夜景」は日本 3 大夜景の 1 つである．このような魅力的な観光資源が多く存在していることによって，観光客が毎年多く訪れる．
観光産業が衰退しないためには，何度も訪れてもらえるよう，様々な角度から魅力を発信し続ける必要がある．観光客が観光する際，情報を集めるタイミングは 2 つある．1 つは，事前に情報を集める方法，もう 1 つは，現地で情報を集める方法である．事前に情報を集めるためのサービス
は，4travel.jp[13] や Triple[14] などのブログ形式のものが多く存在する．しかしながら，現地でインタラクティブに情報を集めながら，また自身の思い出帳を作成することができるサービスは存在しない．本サービスは，観光しながら様々な情報を集めるユーザーに向けて，観光するルートの選択肢を増やしてもらうために制作したサービスである．
（※文責: 久末瑠紅）

3.2

課題

現在，函館のまちを歩きながら，情報を収集するためのサービスが提供されていないため，旅行しながら函館について調べることが難しい．その課題を解決するために，現地で実際にユーザーが体験した思い出を共有できるようにし，さまざまな魅力を持つ函館をより楽しんでもらう．
（※文責: 久末瑠紅）

3.3

サービスについて

3.3.1

概要

本サービスは，函館を観光する際に，現地で情報を集めながら行先の選択肢を増やしたいと考える人に向けた，思い出帳交換アプリケーションである．思い出帳を同じ時間・場所を歩いている観光客と交換することで，旅行をする際に参考にできる情報が増え，函館のまちの歩き方 (新たな旅
行の楽しみ方) の種類を増やすことが可能となる．また，手書きの日記など思い出を記録するものと異なり，思い出を手軽に記録・交換することができる．
（※文責: 久末瑠紅）

Group Report of 2020 SISP

- 14 -

Group Number 7-A

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

3.3.2

サービス名の由来

本サービスは，旅行の中でたくさんの函館の魅力に出会ってほしいという願いから，「MeetExperiences on Trips」と，「出会った」という単語をかけて「MET.」という名称に決定した．
（※文責: 久末瑠紅）

利用方法

3.4

MET. は，五稜郭公園や函館山など，有名な観光地にビーコンを設置している．設置されているビーコンを認識すると，アプリケーションが観光客に通知を送信する．観光客は通知からアプリ
ケーションをひらき，そのときの思い出を入力するだけで，自分の思い出を記録することが可能となる．
観光客が書いた思い出帳は，匿名性を守られながら，訪れた観光地に保存される．その後，観光地に登録されている「他の人の思い出帳」を閲覧することが可能となる．それによって，ほかの観光客が，どの観光地に行き，どんな体験をしたか，ということを知ることが可能となる．その情報によって，新たな「函館のまちの歩き方」に気づくことができ，行き先の選択肢を増やすことを実現される．
（※文責: 久末瑠紅）

3.5

機能

図 3.1

みんなの思い出帳

一覧表示

Group Report of 2020 SISP

図 3.2

みんなの思い出帳

ページ表示- 15 -

図 3.3

今回の思い出帳Group Number 7-A

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

3.5.1

みんなの思い出帳

この機能が本サービスの最も核になる機能であり，従来の思い出帳作成アプリケーションにはな
い「他の人の思い出帳を閲覧する」という体験を与えるものである．他の観光客がどの観光地に行き，どのような思い出を得たのかを知ることができる．これによって，函館の歩き方の新たな選択肢を得ることが可能となる．
図 3.1 のように，思い出帳は一覧で表示される．
旅行の開始日時が新しいものが上部に表示される．表示される内容は「投稿日付」，「タイトル」，「投稿した人のユーザー名」，「住んでいる国」である．表示されている思い出帳をタップすると，
図 3.2 のように思い出帳の内容を閲覧することができる．
（※文責: 久末瑠紅）

3.5.2

今回の思い出帳

観光客が函館に訪れ，旅行中できた思い出をページとして追加する画面である．思い出を登録する方法は 2 つある．1 つ目は，ビーコンから電波を受信し，アプリケーションからプッシュ通知を受ける方法である．この機能により，観光客は，観光地に訪れた際にワンタップでページの追加画面に移動し，思い出をページとして追加することが可能となる．2 つ目の方法は，アプリケーショ
ンの画面を開き，追加ボタンをタップする方法である．ビーコンの電波を受信するためには，ユーザーに位置情報の共有を常に許可してもらう必要がある．位置情報の共有を許可したくないユー
ザーに向け，本機能を実装した．登録したページは，一覧で表示される．
図 3.3 は，「今回の思い出帳」の表示画面である．
観光地に訪れた日時が新しいものが上部に表示される．表示される内容は「思い出帳のタイトル」，「投稿日時」，「スポットの画像」，「訪れた観光地の名前」，「コメント」である．
（※文責: 久末瑠紅）

Group Report of 2020 SISP

- 16 -

Group Number 7-A

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

3.5.3

自分の本棚

図 3.4

自分の思い出帳

一

図 3.5

覧表示

自分の思い出帳

ページ表示

自分が過去に記述した思い出帳を閲覧し，旅行を振り返ることができる．
図 3.4 のように，思い出帳は一覧で表示される．
旅行の開始日時が新しいものが上部に表示される．表示される内容は「思い出帳のタイトル」，「投稿日時」，「スポットの画像」，「訪れた観光地の名前」，「コメント」である．表示されている思い出帳をタップすると，図 3.5 のように思い出帳の内容を閲覧することができる．
（※文責: 久末瑠紅）

3.6

ビーコン使用の理由

ビーコンを使用した理由は 3 つある．1 つ目は，思い出の登録を手軽にするためである．従来の思い出帳作成アプリケーションでは，思い出の登録をする際には，アプリケーションを開き，登録
画面に移動するという作業が必要であった．ビーコンを使用することによって，ユーザーは通知か
ら思い出の登録画面に移動することができ，思い出の登録を手軽に行うことができる．2 つ目は，

GPS を常に起動する場合に比べ，電力消費量が少ない点である．観光客が旅行をする際には，1 日中移動する場合が多い．そのため，スマートフォンの電力消費量は少ないほうがよい．3 つ目は，利用者のプライバシー保護である．GPS の場合，詳細な位置情報が常にトラッキングされる．すなわち，一日の行動パターンがすべてアプリケーションに送信されるということになる．それに対してビーコンは，あらかじめビーコンが設置された場所でのみ位置情報を取得する．これにより，ユーザーが「1 日中位置情報を提供する」という心理的負荷を解消することができる．
（※文責: 久末瑠紅）

Group Report of 2020 SISP

- 17 -

Group Number 7-A

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

第4章
4.1

開発プロセス

技術習得

本サービスは，API サーバーの開発経験者と iOS アプリケーションの開発経験者がグループに在籍していたため，API サーバーと連携した iOS アプリケーションを用いて私たちの目指すサービスを作成した．以下にチーム開発を進めるために用いた，ツールについて記述する．
（※文責: 野間直生）

4.1.1

環境準備

チーム開発に取り組むにあたって，メンバー同士の緻密なコミュニケーションは必要不可欠である．また，今年度は COVID-19 の影響でオンラインでの活動が多かった．そのため，私たちはオンラインの環境下でコミュニケーションを取るためのツールを複数用いた．
（※文責: 野間直生）

Slack
プロジェクト全体での連絡や，グループ間での連絡，教員や TA との連絡に用いた．Slack はLINE 等他のコミュニケーションツールと違い，意識を集中させたいチャット欄に意識を集中することができるため，たくさんの情報が飛び交うプロジェクト活動において最も有効なコミュニケー
ションツールであると判断したため使用した．
（※文責: 野間直生）

Adobe Illustrator
本サービスのロゴを作成するために使用した．また，モバイルアプリケーションに用いられるボ
タンやアイコンなどのパーツ作成にも使用した．
（※文責: 野間直生）

esa
私たちは，プロジェクト全体で共有する資料の作成や，プロジェクト活動ごとの議事録の作成に

esa を使用した．esa には WIP 機能という機能があり，この機能を使うことで，作成した資料が未完成であることを明記することができる．私たちは 15 人という大人数での作業が必要だったた
め，資料を同時に編集できるだけでなく Markdown の記法で資料を作成できること，WIP 機能に
よって資料の状態を明確に記せることから esa は私たちのプロジェクトにとって有用なツールであった．

Group Report of 2020 SISP

- 18 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4（※文責: 野間直生）

Zoom
毎週 2 回行われるシステム情報科学実習の時間にプロジェクトメンバー全員で集まるために使用した，ビデオチャットツールである．Zoom にはビデオチャットを録画する機能や，ブレイクア
ウトルームと呼ばれるビデオチャットのチャンネルを複数作成する機能がある．Zoom とこれらの機能を用いて，COVID-19 の影響下でもプロジェクト活動を円滑に進めることができるように努めた．
（※文責: 野間直生）

YouTube
私たちは Zoom を用いて録画した活動の動画を，YouTube に限定公開でアップした．活動の録
画をプロジェクトのメンバー間で共有することで，もし議事録に記入の漏れがあったときや，決定事項の再確認をしたいときに活動を手軽に振り返ることができた．
（※文責: 野間直生）

Discordシステム情報科学実習外の時間での活動や，グループごとでの活動の際に Discord を利用した．

Discord は手軽に新しいチャンネルを作成することができるため，複数人に別れて作業するときに有効なツールである．また，チャンネルへの参加状況も確認しやすいため，プロジェクトのメンバーに質問があるときや，確認したいことがあるとき，メンバーがオンラインかどうかの確認が容易であった．以上のことから Discord はグループに分かれて行う作業や，複数人で集まって作業するときに便利なツールであった．
（※文責: 野間直生）

Google Jamboard
Google Jamboard はオンラインで使うことのできるホワイトボードである．アイデア出しや，
バックログの作成など，書き出した文字列を視覚的に分類してまとめたいときや，それらを並べ替
えしたいときに積極的に用いた．オンラインで使うことのできるホワイトボードは，オンラインという限定された環境でのプロジェクトの活動をオフラインかのように進めさせてくれるツールであった．
（※文責: 野間直生）

MiroGoogle Jamboard と同様にオンラインで使うことのできるホワイトボードである．Miro は文字
サイズが変更できることや，付箋の色のバリエーションが豊富であること，付箋に任意のタグがつけれることなど，オンラインならではのホワイトボードを作成することができるツールであった．

Group Report of 2020 SISP

- 19 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4（※文責: 野間直生）

Visual Studio CodeGolang で API サーバーを開発するにあたり，Visual Studio Code を使用した．画面を共有しての開発では，画面の解像度や遅延が問題となり難しいため，拡張機能の Live Share を用いて同時編集を行い，開発の効率化を行った．また，拡張機能の Go を用いることでファイル保存時に自動的にフォーマットを行うことができ，誰もが見やすいプログラムを書くことができた．同じ開発環境で行うことで，トラブルがあった場合の解決策を共有できるメリットもあることから，API
サーバーの開発には Visual Studio Code を使用した．使用したバージョンは 1.51.1 から 1.52.1
であった．
（※文責: 鈴木利武）

OpenAPI
API サーバー側で設計・実装した機能の詳細をモバイルアプリケーション作成班に伝えるため，
OpenAPI を使用した．OpenAPI とは，REST API の仕様を記述するための規格であり，他のドキュメントファイルと比べ Git での管理がしやすいという利点がある．これにより，API の仕様
変更があった際に OpenAPI の定義ファイルを一緒にコミットすることができ，より正確に最新の情報を共有することが可能である．このほかに，データの型を明記することができ，仕様を明確にすることができるため OpenAPI を使用した．
（※文責: 鈴木利武）

Xcode
モバイルアプリケーションの開発に Xcode を用いた．Xcode は Apple が提供しているアプリ
ケーション開発ツールであり，統合開発環境であることからモバイルアプリケーションの開発に使用した．
（※文責: 野間直生）

4.1.2

夏季休暇期間中の勉強会

本プロジェクト内で，チームでの開発が未経験であるメンバーがいた．また，夏季休暇期間前に大まかなプラットフォーム分けと使用するプログラミング言語の決定を行った．その中で，各メンバーが今まで開発を行う際に使用していたプログラミング言語とは異なる言語を扱ってみたいという要望があった．そのため，後期からの本格的な開発に向けて，開発で必要となる知識をつけることと，各メンバーが主に開発するプラットフォームを決めることを目的として，夏休み勉強会を実施した．この勉強会の形式については，開発について初学者から経験者まで幅広い経験の差があったため，全員で内容を統一すると，初学者が理解しにくい内容になってしまうといった不都合が生じることが予想された．そのため，各メンバーが発表しやすく，内容に合わせやすいように，発表者が自由に形式を決定することにした．自分の持っている知識や，夏季休暇期間中に行ったことをLT 形式で発表したり，実際に見てもらっているメンバーに手を動かしてもらいつつ発表者がライGroup Report of 2020 SISP

- 20 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
ブコーディングを行ったりした．自分の興味のあるプラットフォームの勉強会には積極的に参加してもらい，1 人約 1 時間ほどの勉強会を，メンバー全員がそれぞれ 2 回企画した．また，行った勉強会を録画し，その動画をプロジェクト内で共有することで，のちに復習しやすい環境を作った
り，参加できなかったメンバーが学習しやすい環境を作った．この勉強会を通じて，GitHub の基
本的な知識や，サーバー，モバイル，Web といった各プラットフォームごとの知識が得られた．また，プログラミング関連以外にも，Adobe Illustrator を用いたポスターや資料を作る方法や，イラストを描くためのノウハウを学んだ．各メンバーが開発に携わりたいプラットフォームについての知識が深められ，円滑に開発に進められることができた．
（※文責: 石澤大輔）

4.2

開発手法

4.2.1

導入した手法アジャイル開発手法
本プロジェクトでは，ソフトウェア開発手法の 1 つである，アジャイル開発手法を参考に開発を行った．アジャイル開発手法とは，作り上げるサービスを粒度の細かい単位で実装とテストを繰り返すことで，成果物を作り続ける開発手法である．また，アジャイル開発手法を用いることで，定期的にユーザーの要求やステークホルダーからの意見を受け取り，俊敏に対応することができる．
（※文責: 野間直生）

ウォーターフォールモデル
本プロジェクトでは，開発期間が 1 ヶ月と少ししかなかったため，アジャイル開発手法のみではなく，ウォーターフォールモデルも参考に開発を行った．ウォーターフォールモデルとは，要件定
義，基本設計，詳細設計，開発，テストの手順で成果物を作りあげる開発手法である．ウォーター
フォールモデルのメリットは，計画を立てやすいことや全体を把握した上でタスクを管理することから，進捗管理を簡単に行うことができることである．ただし，要件定義や基本設計に誤りがあった場合，修正箇所が大きくなってしまい修正に時間がかかってしまうことがウォーターフォールモ
デルのデメリットである．
（※文責: 野間直生）

4.2.2

開発の流れ

要件定義
本プロジェクトでは，10 月にサービスの内容が決定した．私たちに残された時間は 1 ヶ月と 2週間ほどであったため，早急なサービスの開発が求められた．そこで私たちは最初の 1 週間を用いて，ウォーターフォールモデル的な，サービスの要件定義を細かく行った．私はサービスの要件定義だけでなく，メンバーのグループにおける目的の共有や，チーム開発における意識共有もエレ
ベーターピッチや，やらないことリストを用いて行った．
（※文責: 野間直生）

Group Report of 2020 SISP

- 21 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
プロジェクト定義書
プロジェクト定義書を作成することで，私たちのグループの目的や背景，活動期間，スコー
プ，組織構成を明確にした．これらの項目を明確にすることで，私たちが MET. として何を成し遂げるべきかを明確にした．
（※文責: 野間直生）
ステークホルダーリスト
次に我々はステークホルダーリストを作成した．ステークホルダーとは利害関係者のことであり，プロジェクトマネジメントで求められる利害関係者とは，グループに関わる全ての人のことを指す．このステークホルダーをまとめておくことで，スクラムイベントであるスプ
リントレビューをステークホルダーにお願いする際，どのような観点からレビューをしてもらいたいかが明確になる．毎週ごとのスプリントレビューで観点が変わってしまうことを防ぐことができる．
（※文責: 野間直生）
用語集
サービスを開発するにあたって私たちはサービスに用いる機能の用語集を作成した．本サー
ビスでは，1 つ機能にいくつかの呼称がついてしまっていたため，用語集を作成した．作成
することで，機能の名前が統一され，チームで取り組む成果物の作成や資料の作成がオンライン環境であっても円滑に行うことができた．
（※文責: 野間直生）
エレベーターピッチ
私たちは，私たちのサービスを共通認識とするために，エレベーターピッチの作成を行った．エレベーターピッチとは，会社で，エレベーターの移動時間の中で説明できるくらい簡潔にまとめた本サービスの価値について書かれた文章である．この文章を作成したことで，私たちが本サービスの価値について常に意識しながら後の開発を行うことができた．
（※文責: 野間直生）
やらないことリスト
最後に私たちは，やらないことリストを作成した．やらないことリストとは，「各々のタス
クの明瞭化」や，「休むときには休む」など私たちのグループが「やる」ことと，「徹夜しない」などの「やらないこと」，「ここまでの実装はしない」などの「後で決めること」の 3 つの項目に分けてグループの方針を書き出したリストである．このリストを用いることで，オンライン環境での作業のしすぎや，説明責任の意識などグループにとって必要な条件を共有することができた．
（※文責: 野間直生）

Group Report of 2020 SISP

- 22 -

Group Number 7-A

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

4.2.3

ユーザーストーリーの作成とタスクの洗い出し

要件定義を終えた私たちは，本サービスの基本設計として，ユーザーストーリーの作成とタスクの洗い出しを行った．
（※文責: 野間直生）
ユーザーストーリー
サービスが決定した段階では，メンバーそれぞれが思い描く本サービスが異なるものであり，統一する必要があったことや，ユーザーが本サービスを実際に使う場面を想像して必要な機能を明確にする必要があったため時間をかけてユーザーストーリの作成を行った．実際に本サービスを使ってもらう現場を紙芝居で作成した．もちろん紙芝居の作成途中で文章を主体としたユーザーストーリーを作成したが，視覚的にもユーザーストーリーを作成したことでよりしっかりとした本サービスの使われ方をメンバーで共有することができた．
（※文責: 野間直生）
タスクの洗い出し
作成したユーザーストーリーをもとに本サービスの詳細設計を行った．ユーザーストーリーから，必要な機能を箇条書きで書き出し，機能の優先度付けを行った．優先度付けを行った機能をタスクとして，「iOS」，「サーバー」の 2 種類のラベルを用いてタスクを作成した．タ
スクを洗い出したことで，次に取り組む開発の段階で，最終日までの全てのタスクを把握することができ，短い開発期間でも成果物を作り上げることができた．
（※文責: 野間直生）

4.2.4

スプリント

私たちは，1 週間を 1 スプリントとし，開発に望んだ．スクラムイベントであるスプリントプラ
ンニングで，洗い出ししたタスクから今週のタスクを選別し，スプリント終わりである金曜日のシステム情報科学実習の時間までに実装した．毎週成果物を出し続けることで，優先度の高い機能からステークホルダーにレビューしてもらうことができた．
（※文責: 野間直生）

4.3

効果，課題，解決策

4.3.1

効果

私たちはアジャイル開発手法とウォーターフォールモデルの両方を参考にすることで，1 ヶ月という短い開発期間ながら成果物を見せることができた．これは要件定義に 1 週間という長い期間をかけてじっくり行ったからこその成果であると思う．
（※文責: 野間直生）

Group Report of 2020 SISP

- 23 -

Group Number 7-A

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

4.3.2

課題

課題として，私たちは最初の段階で全てのタスクを洗い出しした．これによって，全てのタスクを把握することができたが，毎週いただいたレビューをタスクに含む余裕がなく，事前に定めたス
ケジュールから徐々に遅れてしまう結果となった．
（※文責: 野間直生）

4.3.3

解決策

この課題に対し 2 種類の解決策があると考える．1 つ目は，タスクの洗い出しを全て行わず，
目先の 1 週間だけ行うことである．これは本来のアジャイル的な開発方法であり，いただいたレ
ビューや開発途中で優先度の修正をしたいと考えたときに対応できるようになっている．私たちもこの手法を用いることで，より柔軟なスケジュールを作成することができたかもしれない．2 つ目
は，さらにタスクに余裕を持って，全てのタスクを洗い出す方法である．この方法によって，私たちが用いた手法と同様の結果を得られるが，1 週間で取り組むタスク量がかなり少なくなってしまう可能性が挙げられる．
（※文責: 野間直生）

Group Report of 2020 SISP

- 24 -

Group Number 7-A

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

第 5 章 サービスの実装
5.1

システム構成本サービスは，図 5.1 のように，ビーコン，モバイルアプリケーション，サーバーサイドアプリ
ケーションの 3 つから構成される．ビーコンは，函館市内の観光地に設置している．観光客が観光地に訪れると，スマートフォンがビーコンの電波を検知し，観光客のスマートフォンへ通知を送信する．スマートフォンにきた通知をタップすると，ページの追加画面へ移動することが可能となる．モバイルアプリケーション上で思い出の登録を行うと，追加されたページの内容がサーバーへ送信される．送信されたデータがサーバーに蓄積され，他者の思い出帳閲覧や自分の思い出帳閲覧を可能とする．
（※文責: 久末瑠紅）

図 5.1

5.2

システム構成図

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

本サービスでは，観光客に手軽に思い出帳のページを追加してもらえるよう，モバイルアプリ
ケーションを開発した．モバイルアプリケーションを開発するにあたってのプラットフォーム選定では，iOS アプリケーションを選択した．選択理由として，チームメンバーに iOS アプリケー
ションの開発経験があったからである．また，本サービスでは MVP（Model View Presenter）
アーキテクチャに準拠して開発を行った．アーキテクチャを選定する段階で，MVC（Model View

Controller），MVVM（Model View ViewModel），MVP アーキテクチャが候補として上がったが，MVC アーキテクチャは Swift を用いた開発には責務の所を明確にすることができないと考えた．MVVM アーキテクチャは 3 人でサービスを作り上げるには大規模すぎるアーキテクチャであると判断したため MVP アーキテクチャを採用した．本アプリケーションの主な機能は，「他の観光客の思い出帳を閲覧する機能」，「自分の本棚から思い出帳を閲覧する機能」，「作成中の思い出帳にページを追加する機能」である．

Group Report of 2020 SISP

- 25 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4（※文責: 野間直生）

開発環境
アプリケーションの開発は以下の環境で行った．

• MacBook Pro• macOS Big Sur• Xcode 12.2
• Swift 5.3.1（※文責: 野間直生）

ライブラリ
ライブラリ管理ツールとして CocoaPods を用いた．使用したライブラリは APIKit(version) のみである．APIKit はレスポンスが success と failure の 2 値で表せるだけでなく，レスポンスの型を定義でき，タイプセーフなライブラリである．このことから，私たちはモバイルアプリケーションの開発に APIKit を選定した．
（※文責: 野間直生）

初回起動
本サービスでは，初回起動時に初回起動であることをサーバーに送信し，ユーザー ID を生成してもらう．以降このユーザー ID は端末内に保存される．また，現在観光地に設置されているビー
コンの UUID と Major 値，Minor 値のリストを取得する．この操作によって，観光客は自分の思い出帳を作成することができるようになる．
（※文責: 野間直生）

他の観光客の思い出帳を閲覧する機能
本サービスでは，「他の人の思い出帳を閲覧する機能」がホーム画面（ユーザーが最初に視認する画面）となっている．この機能が，従来の思い出帳作成アプリケーションや，日記アプリケーショ
ンにはない，本サービスの最も核となる機能である．「他の人の思い出帳を閲覧する機能」によって，ユーザーと同じ観光地に訪れた別のユーザーの思い出を辿ることができる．ユーザーは，思い出を辿ることで，別のユーザーがどの観光地に訪れ，どのような体験をしたかを知り，ユーザー自身では考えつくことができなかった函館の新たな歩き方を見つけることができる．別のユーザーの「観光地に訪れた時間」，「思い出帳のタイトル」，「ユーザー名」，「出身国」が最初の画面で確認することができる．観光地に訪れた時間が一目でわかることで今からの函館歩き方の選択肢を増やすことができると考えている．また，別のユーザーの出身国がわかることで，出身国によって違う函館のまちの歩き方を知ることができる．
表示される思い出帳の数は観光地に訪れたユーザーの数によって増えるので CollectionView を用いて上下にスクロールする画面を作成した．CollectionView を用いることで，現在はい出帳が全て同じ形状で表示されているが，今後ユーザーのニーズに合わせて思い出帳のサイズを変えたいGroup Report of 2020 SISP

- 26 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
ときや，一つの画面に表示させる思い出帳の数を制限したいときに，CollectionViewFlowLayout
から同じデータを参照して表示方法を変更することができる．同じデータを参照して表示方法を変更できるということは，開発するにおいてクラスごとの責務を複雑にする必要がなくなる．よって私は，CollectionView が多様性のある手法であると考えているため開発に用いた．
（※文責: 野間直生）

自分の本棚から思い出帳を閲覧する機能「自分の本棚から思い出帳を閲覧する機能」によって，ユーザーは今までの思い出を振り返ることができる．この機能では今までにユーザーが作った思い出帳の「旅行期間」，「思い出帳のタイトル」，「思い出帳の詳細」，「思い出帳のカバー画像」，「公開か非公開か」を確認することができる．
私たちが日頃使っているアルバム帳や手帳，日記が日付を目印に閲覧していることや，思い出帳に
タイトルがあることで振り返りやすくなることなどから，これらの情報を「自分の本棚から思い出帳を閲覧する機能」の最初の画面に表示している．
「公開か非公開か」については，先に述べた「他の人の思い出帳を閲覧する機能」によって別のユーザーが作成している思い出帳を，閲覧することができるようにするかどうかを設定するステータスである．ユーザーは思い出帳をタップすると自身が追加した思い出を振り返ることができる．この機能によって，今までに作成した思い出を詳細に振り返ることができる．
「他の人の思い出帳を閲覧する機能」と同様に CollectionView を用いて上下にスクロールする画面を実装した．
（※文責: 野間直生）

作成中の思い出帳にページを追加する機能
本サービスで思い出帳を交換するためには，思い出帳を作成し，作成した思い出帳にページを追加しなければならない．この，「作成中の思い出帳にページを追加する機能」は，作成した思い出帳にページを追加することができる機能である．「作成中の思い出帳にページを追加する機能」の最初の画面では，作成中の思い出帳のページを確認することができる．「観光地に訪れた時間」，「思い出（観光地）の画像」，「観光地の名前」，「思い出のコメント」を一枚のページに表示している．
表示している情報は「自分の本棚から思い出帳を閲覧する機能」と同様に，私たちが普段使っているアルバム帳や手帳が日付を目印にされていることや，ページをユーザー自身が振り返って思い出
すことや別のユーザーが閲覧して共感するために必要な情報が，「思い出（観光地）の画像」と「観光地の名前」，「思い出のコメント」であると考えたためこれらの情報をページとして表示できるよ
うになっている．
画面内にある「ページを追加するボタン」をタップすることで，ユーザーは思い出をページとして思い出帳に追加することができる．私たちは，このページを追加する機能の実装にあたり，いかに旅行中に，手軽に，ページを追加してもらえるかを考えた．従来の日記はその日の夜に記入する
ことがほとんどである．本サービスではそのページに記入する動作を旅行中にユーザーに行ってもらわなければならない．私たちはユーザーが旅行中でもページを追加しやすいように，ページに追加する情報を画像とコメントだけに限定した．思い出帳を追加するためには，最初にユーザーが観
光地のビーコン圏内で追加ボタンをタップする．タップするとカメラが起動して，ユーザーは「思い出（観光地）の画像」を撮影することができる．撮影すると，「思い出のコメント」を記入する

Group Report of 2020 SISP

- 27 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
画面に遷移する．ユーザーはコメントを記入して，追加ボタンをタップする．これらの動作によってユーザーは思い出をページとして思い出帳に追加することができる．
最初の画面である作成中の思い出帳のページを確認する画面では CollectionView を用いて左右にスクロールする画面を実装した．選定理由は上の二つの機能と同じく CollectionView を用いた実装が多様性のある実装方法であると判断したためである．ページを追加する機能では，Apple が開発した AVFoudation というフレームワークを用いてカメラ機能の実装を行った．
（※文責: 野間直生）

5.3

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

本サービスでは，ユーザーの思い出帳の共有を行うため，サーバーを開発する必要がある．そのため，MET. のサービスを実現するための API サーバーを開発した．開発には，習得が他言語より容易と判断した Golang を用いた．また，MVC（Model View Controller）アーキテクチャを採用し，仕様変更に対して柔軟に対応ができる設計を行った．
（※文責: 鈴木利武）

開発環境
サーバーサイド・アプリケーションの開発は以下の環境で行った．

• Windows 10, Linux pi 4.19.75-v7l+• Visual Studio Code• go version go1.15.2• mysql Ver 8.0.21
モバイルアプリケーションの開発時にサーバーへのアクセスが必要であり，複数の端末からのアクセスを検証するために Raspberry Pi 4 Model B を使用してその検証を行った．
（※文責: 鈴木利武）

5.3.1

MVC アーキテクチャ

本サービスでは，Model View Controller（MVC）アーキテクチャを採用した．MVC アーキテ
クチャには，「可読性が高い」，「機能の拡張が容易」，「仕様変更に対応しやすい」などの利点が存在する．アジャイル開発を行う上で，機能の拡張性は高い方が好ましいため，このアーキテクチャを採用した．

View
モバイルフロントアプリケーションとサーバー間で，情報を送受信する処理を記述する層である．ササーバーからモバイルフロントアプリケーションにデータを送信する処理と，モバ
イルフロントからサーバーがデータを受信した際に行う処理が記述されている．この層には，サーバー内部で行うべきである，データベースの操作などは記述していない．

ControllerGroup Report of 2020 SISP

- 28 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
Model が行った処理を，View へ受け渡すための処理を行う層である．View で送受信されたデータを，View がデータを送受信した際に，Model 内のどの関数を用いて処理を行わなければならないかが記述されている．

Model
View，Controller で行うべき処理以外の全てが Model に記述されている．主に，データベースに関連する処理と，ビジネスロジックが記述されている．Model には，Data Access

Object（DAO），Data Transfer Object（DTO），Service の 3 つが存在している．
DAO
データベースなどに格納されているリソースにアクセスするための処理が記述されている．
サーバーからデータを読み込むためのクエリに関しても，DAO 内に記述される．

DTO
DAO が扱うデータの構造体を定義を定義するためのものである．サーバー内部で行うデータの構造体と，モバイルアプリケーションに送信するデータの構造体が分けて定義されている．

Service
認証機能や暗号化など，ビジネスロジックに関連する処理を記述するための処理である．
（※文責: 久末瑠紅）

5.3.2

データベース本サービスのデータベースには，ユーザーの詳細を詳細を保存する USER LIST(表 5.1)，思い出帳の詳細を保存する BOOK LIST(表 5.2)，思い出帳のページの詳細を保存する PAGE LIST(表5.3)，そのページに追加されている画像の情報を保存する PAGE MEDIA LIST(表 5.4)，観光地の情報を保存する SPOT LIST(表 5.5)，ビーコンの情報を保存する BEACON LIST(表 5.6)，観光地に置かれた思い出帳を保存する SPOT BOOKS LIST(表 5.7)，交換した旅思い出帳を保存す
る EXCHANGED BOOKS LIST(表 5.8) の 8 つのテーブルが存在する．これらは MySQL を用
いてデータの管理を行い，Golang で開発したサーバーからデータの読み書きを行うことができるように設計した．
現段階では，テーブル SPOT LIST(表 5.5) の SPOT LAT や SPOT LNG のように使用されていないカラムがいくつか存在する．今後，これらの使用されていないカラムについての機能を実装
し，サービスで得られる体験を増やしていく計画である．
表 5.1 USER LIST

カラム名

型

概要

USER ID

INT

プログラムにより自動採番された ID

USER NAMEVARCHAR(20)ユーザーが登録した名前

USER RESIDENCE

VARCHAR(3)ユーザーが登録した居住地

PROFILE PUBLIC SETTINGBOOLEAN

ユーザーのプロフィールを公開するかの設定

CURRENT BOOK ID

INT

現在の思い出帳Group Report of 2020 SISP

- 29 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
表 5.2 BOOK LIST

カラム名

型

概要

BOOK ID

INT

プログラムにより自動採番された ID

USER ID

INT

この思い出帳の所有者のユーザー ID

BOOK PUBLIC SETTINGBOOLEAN

思い出帳を他のユーザーへ公開するかの設定

BOOK NAMEVARCHAR(32)

思い出帳の名前BOOK DATE START

DATE

旅行を開始した日付

BOOK DATE END

DATE

旅行を終了した日付

BOOK TEXT

VARCHAR(140)

思い出帳の説明

表 5.3 PAGE LIST

カラム名

型

概要

PAGE ID

BIGINT

プログラムにより自動採番された ID

BOOK ID

INT

ページが追加されている思い出帳の ID

PAGE TEXT

VARCHAR(140)ページ内のテキスト

PAGE ADD DATETIMEDATETIME

ページが追加された日時

SPOT ID

INT

ページが作られた場所

表 5.4 PAGE MEDIA LIST

カラム名

型

概要

MEDIA ID

INT

プログラムにより自動採番された ID

MEDIA URL

VARCHAR(128)

メディアファイルが格納されている場所のパス

PAGE ID

BIGINT

メディアが追加されているページの ID

表 5.5 SPOT LIST

カラム名

型

概要

SPOT ID

INT

プログラムにより自動採番された ID

SPOT NAMEVARCHAR(64)

観光地の名称SPOT COUNT VISITORS

INT

観光地に訪れた人数

SPOT LATDOUBLE(8, 6)

観光地の緯度SPOT LNGDOUBLE(8, 6)

観光地の経度

表 5.6 BEACON LIST

カラム名

型

概要

SPOT ID

INT

ビーコンの置かれているスポットの ID

UUID

VARCHAR(64)

ビーコンの UUID

MAJOR

INT

ビーコンの Major 値

MINOR

INT

ビーコンの Minor 値

Group Report of 2020 SISP

- 30 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
表 5.7 SPOT BOOKS LIST

カラム名

型

概要

BOOK ID

INT

スポットに置かれた思い出帳の ID

SPOT ID

INT

思い出帳が置かれたスポットの ID

VISIT DATETIMEDATETIME

スポットに置かれた日時

表 5.8 EXCHANGED BOOKS LIST

カラム名

型

概要

BOOK ID

INT

受け取った思い出帳の ID

USER ID

INT

思い出帳を受け取ったユーザーの ID

SPOT ID

INT

思い出帳を受け取った場所の ID

VISIT DATETIMEDATETIME

思い出帳がスポットに置かれた日時

EXCHANGED DATETIMEDATETIME

思い出帳を受け取った日時（※文責: 鈴木利武）

5.3.3

API

API の返却値には画像を取得するための/GET image を除き，すべて JSON 形式（HTTP
ヘッダーの Content-Type が application/json）を使用した．/GET image は画像を取得するた
め JPEG 形式（HTTP ヘッダーの Content-Type が image/jpeg）を使用した．データの返却にJSON 形式を用いた理由は，データの構築，読み取りが容易であること，XML や CSV など他の形式と比べ人間が読みやすくデバッグが容易であることなどの利点がある．
画像はサーバーへアップロードされた時点で JPEG 形式にエンコードし，データの形式を統一することで開発を容易に行えるようにした．画像形式について，JPEG 形式を採用した理由として，一般的な形式であり，PNG 形式や TIFF 形式などの他のよく使われる画像形式と比べるとファイルサイズが小さい点がある．さらに，本サービスでは，景色を撮影する機会が多く，JPEG
形式の圧縮率をあげても画像の劣化が目立ちにくい点がある．
以降では，実装した API について，モデルごとに分けて説明する．
ビーコンに関する API• GET /GET allBeaconList
すべてのビーコンの情報を表示する．ユーザーが訪れた観光地を判別するためにはビーコンの情報が必要不可欠である．そのため，この機能を使用してすべてのビーコンの情報を取得
し，モバイルアプリケーション内で判別を行っている．
（※文責: 鈴木利武）

Group Report of 2020 SISP

- 31 -

Group Number 7-A

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

観光地に関する API• GET /GET spotName
指定した観光地の情報をリスト形式で表示する．取得できる情報は，観光地の名称，観光地のイメージ画像の URL である．イメージ画像は，本サーバー内の/GET image を使用することで JPEG 形式の画像を取得することができる．

• POST /POST visitSpot
ユーザーが観光地に訪れたことをサーバーに通知する．サーバー側はこれを受け取り，ユーザーの思い出帳を観光地に置く処理を行う．
（※文責: 鈴木利武）

思い出帳に関する API• GET /GET myBookList
ユーザーの自分自身の思い出帳を JSON 形式の配列ですべて表示する．

• GET /GET exchangeBooksList
ユーザーが受け取った他のユーザーの思い出帳を JSON 形式の配列で表示する．

• POST /POST newBook
新たに思い出帳を作成する．作成した思い出帳は，現在の思い出帳として設定される．
（※文責: 鈴木利武）

ページに関する API• GET /GET pageList
思い出帳の ID を指定し，ユーザーのページを JSON 形式の配列で表示する．

• GET /GET exchangedPageList
思い出帳の ID を指定し，ユーザーが受け取った他のユーザーのページを JSON 形式の配列で表示する．

• POST /POST deletePage
ユーザーのページをページの ID を指定して削除する．削除を行うことができるページは自分自身のページのみである．

• POST /POST newPage
現在の思い出帳に新たなページを作成する．作成することができるのは自分自身の思い出帳のみである．

• POST /POST pageImage
指定したユーザーの自分自身のページに，新たな画像を追加する．画像は自動的に切り抜きが行われ，正方形の形でサーバー上に保存される．このとき，引き伸ばしなどは行わず，長い辺は切り落とされる．サーバーが受け取ることができる画像形式は PNG 形式，BMP 形
式，JPEG 形式，TIFF 形式であるが，全ての画像をサーバーへの保存時に JPEG 形式に変換する．
（※文責: 鈴木利武）

Group Report of 2020 SISP

- 32 -

Group Number 7-A

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

ユーザーに関する API• GET /GET newUserID
新たなユーザーの ID を取得する．

• POST /POST updateUserResidence
ユーザーの居住地を更新する．
（※文責: 鈴木利武）

メディアに関する API• GET /GET image
ページに追加された画像を JPEG 形式で返す．
（※文責: 鈴木利武）

5.3.4

導入ライブラリ

サーバーサイドアプリケーションの開発にあたり，開発を容易にするためにいつくかのライブラ
リやフレームワークを使用した．導入したライブラリやフレームワークは以下の通りである．カッコ内は使用したバージョンである．

gin-gonic/gin(v1.6.3)
Golang での Web Application Framework である．標準ライブラリのみでも Web アプリ
ケーションを作成することは可能であるが，このフレームワークを使用することで，より簡単に開発を行うことができる．また，参考となる資料が他のフレームワークと比べて多いことなどから，このフレームを使用することを選択した．

sirupsen/logrus(v1.7.0)
ログ出力にエラーレベルの定義や整形を行うためのパッケージである．必要なログを簡単に指定し出力ができるためこのパッケージを使用した．

stretchr/testify(v1.6.1)
テストコードを簡単に書くためのパッケージである．プログラムのテストはコードの品質を維持し，信頼性を向上させることに役立つ．作成・更新した機能にバグが含まれていないかを簡単にチェックするためのテストコードに使用した．

go-sql-driver/mysql(v1.5.0)
Golang で MySQL を使用するために必要となるパッケージである．本 API サーバーでは，データを MySQL を用いてデータベース上に保存するため，このライブラリを用いた．

disintegration/imaging(v1.6.2)
Golang で画像処理を行うためのパッケージである．ユーザーから受け取った画像を JPEG
形式へエンコードするために使用した．

nfnt/resize(v0.0.0-20180221191011-83c6a9932646)
Golang で画像データのサイズを変更するパッケージである．ユーザーから受け取った画像
を比率を保ち，引き伸ばすことなく正方形にリサイズする必要があるため，本 API サーバーで使用した．

Group Report of 2020 SISP

- 33 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4（※文責: 鈴木利武）

5.4

デザイン

5.4.1

サービスロゴ

ロゴ作成をするにあたり，最初にサービスや函館市の特徴や要素を考えた．旅行，人との繋がり，函館の観光地などの要素が挙がり，それらを総括してロゴのラフスケッチを行った．ラフス
ケッチでは簡単な図形でサービスをイメージできるものを考えた．いくつかのラフスケッチからからサービスのイメージに合うものを Adobe Illustrator で書き起こした (図 5.2)(図 5.3)．思い出帳
は元来手書きで作成するものであるので，サービスのイメージに合うようデジタルフォントを使用
せずメンバーが書いたものに決定した．また，観光地を自分の足で歩いて観光することから，ロゴに足跡を入れることに決定した．テーマとなるカラーは文字の見やすさと，サービスのイメージである人と人との繋がりに合う，カラーコードが#F2962C の暖かみのあるオレンジに決定した．これらの要素を組み合わせ，Adobe Illustrator で 3 つのプロトタイプを作成した (図 5.4)(図 5.5)(図5.6)．メンバーと話し合った結果，テーマカラーであるオレンジ色を使用すると見づらいと感じる
意見がでた．最終的に，様々な人の，それぞれの旅行が混ざり合い，重なっているイメージのロゴ(図 5.4) に決定した．

図 5.2

図 5.4

サービスロゴのプロトタイプ 1

サービスロゴ案 1

図 5.5

図 5.3

サービスロゴのプロトタイプ 2

サービスロゴ案 2

図 5.6

サービスロゴ案 3（※文責: 鈴木利武）

5.4.2

アプリケーションロゴ

アプリケーションロゴとは，スマートフォンのホーム画面に設置されるアプリケーションのアイコンである．サービスロゴをアプリケーションのロゴとして設定したところ，見やすさに問題がな
いこと，サービスロゴが正方形であることが理由となり，サービスロゴをそのままアプリケーショ

Group Report of 2020 SISP

- 34 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
ンロゴとして利用することに決定した．
（※文責: 鈴木利武）

5.4.3

アプリケーションデザイン

アプリケーションのデザインは，欲しい情報が一目でわかること，ページをめくる体験が楽しいと思ってもらえること，ページを追加することが簡単であることを意識して作成した．本サービスは別のユーザーの旅行を思い出帳から体験するものであるため，ユーザーの情報だけでなく思い出帳の情報もわかりやすいところに表示する必要がある．たくさんの情報を全て表示することは不可能なため，一度モックを作成してから，レビューをいただきそのレビューと私たちの考えから表示
する情報と順番を選定した．また，静的な UI ではなく，画面中央のページが少し大きめに表示されるなど，動的なページを実装したことで，ユーザーにページをスクロールする動作にスクロール
ならではのページを捲る感覚を感じてもらえるよう実装した．ページを追加することが簡単である
ための UI の工夫として，追加ボタンが一目でわかるように，また，片手で簡単に操作できるように右手の親指でタップできる位置に設置した．
（※文責: 野間直生）

5.4.4

アプリケーション内アイコンデザイン

アプリケーション内のメニューで使用するアイコンは，サービスのロゴやイメージから作成した．アイコンは，非アクティブ時にはカラーコードが#A5A5A5 のグレー (図 5.7)(図 5.8)(図 5.9)，
アクティブ時にはサービスのテーマカラーであるカラーコードが#F2962C の暖かみのあるオレンジ (図 5.10)(図 5.11)(図 5.12) を使用した．線とサービスロゴで使用されている足跡を組み合わせ
たシンプルなデザインとすることで，どのような思い出にもなじむデザインとなるようにシンプルなデザインを心掛けた．

図 5.7

交換した思い出帳（非選択時）Group Report of 2020 SISP

図 5.8

自分の本棚（非選択時）- 35 -

図 5.9

今回の思い出帳（非選択時）Group Number 7-A

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

図 5.10

交換した思い出帳（選択時）

図 5.11

自分の本棚（選択時）

図 5.12

今回の思い出帳（選択時）（※文責: 鈴木利武）

Group Report of 2020 SISP

- 36 -

Group Number 7-A

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

第 6 章 成果報告会
6.1

中間発表

6.1.1

発表形式

2020 年 7 月 17 日金曜日に，前期のプロジェクト活動の成果を発表するための中間発表が行われた．今年度は COVID-19 の流行により，オンラインでの開催になった．中間発表を行うにあたり，
本プロジェクトの概要を説明する資料として，「A1 サイズのメインポスター」と「プロジェクト紹介の動画」を作成した．
（※文責: 伊藤直樹）

ポスター
メインポスターは主に 4 人で作成し，Adobe Illustrator（Illustrator）を用いて作成した．

Illustrator では同時に共同編集を行うことが不可能であるため，共同で作業するためには Zoom やDiscord の画面共有を用いた．
メインポスターには，「プロジェクト概要」，「独自のタスク管理手法」，「開発サービスのアイデ
ア出し」，「今後の予定」という大項目を設けた．A1 サイズのポスター 1 枚に内容を収める必要があったため，本プロジェクトが行ってきたこと，これから行うことを上記の 4 つに絞って記述した．
「プロジェクト概要」では，本プロジェクトの目的とすること，ビーコンの特徴について記述した．「独自のタスク管理手法」では，アジャイル的なタスク管理手法を確立し，それに則ってタスクを管理していたことを説明した．「開発サービスのアイデア出し」では，まず函館のまちに潜む課題を発見するためにフィールドワークを行ったこと，それをもとにアイデア出しを行ったこと，
そこから仮アイデアとして 8 つの案を選定したことを記述した．「今後の予定」では，中間発表以降の予定を月別に分けて，今後どのような活動を行っていくのかを箇条書きで説明した．
ポスターのデザインに関しては，文字やカラーはロゴのカラーと合わせて作成し，統一感を生み出した．またグリッドを作成することで，より整ったデザインを作り上げることができた．さらに文字幅などを調節することで，違和感のあるような部分での改行がされないように調整を施した．
（※文責: 伊藤直樹）

動画
動画の構成としては，順に「本プロジェクトの概要」，「今年度のプロジェクト活動の特徴」，「5月から中間発表までの活動内容」，「仮アイデア 8 つ」，
「中間発表以降の活動」といった流れとした．
動画は，主に Adobe Premiere Pro（Premiere）のチームプロジェクトを用いて 4 人で作成した．Premiere のチームプロジェクトでは，複数人で同じプロジェクトに対する操作が可能であり，効率的であると判断したため，このツールを選択した．
動画を制作するにあたって，他プロジェクトの動画や Web サイトにはない，奇抜さやこだわりを取り入れることで，多くの人が興味を持って見ることができる動画を目標にして取り組んだ．

Group Report of 2020 SISP

- 37 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
目標達成のための要素の 1 つとして，キャラクターの使用がある．今年度の本プロジェクトには「ビーコンうさぎ」というオリジナルキャラクターがいるため，そのキャラクターがプロジェクト活動について説明するという方法を用いた．もう一つの要素は，VOICEROID を用いたことである．
人の声ではなく，機械音声を用いることで人々の注意を引き付けることができると考えた．キャラ
クターの使用と合わせて，YouTube で投稿されている動画の「ゆっくり実況」という形式を取り入れることで，より親しみやすい動画になると考えた．その他のこだわりとしては，全ての発言に対して字幕を付けたことがある．字幕のフォントも親しみやすいと思われるものを選択した．字幕をつけることで，機械音声が苦手な方や，聞き取りにくい部分があった場合でも，理解しやすい動画になると考えた．
動画制作における課題として，Premiere におけるチームプロジェクトの仕様を理解するまでに時間がかかってしまい，動画を作る以前の部分に時間を使ってしまったことがある．Premiere にはシーケンスというものがある．シーケンスに動画の素材を置いていくことで，シーケンス上に複数の素材が混ざった 1 本の動画が出来上がるというものである．チームプロジェクトでは 1 つのシーケンスに対して複数人で同時に作業することができず，同時に作業して全体に共有しようとす
るとどちらか一方の作業しか反映されない．同時にシーケンスを作業したい場合は動画を複数のシーケンスに分けると違うシーケンスで同時に作業することができるのだが，このことに動画制
作後半になってから気がついたため，気がつくまでは 4 人のうち 1 人または 2 人が作業に参加できず，見ているだけになってしまうという事態に陥ってしまった．ほかにも，取り込んだはずのメ
ディアがほかの端末で見た時にオフラインとなって見ることができなくなることや，正しくチーム
プロジェクトが読み込まれず，作業ができない人が出てきてしまったことがあった．
（※文責: 平山翔真）

中間発表当日
中間発表当日では，まず 15 時から 1 時間，各プロジェクトが作成した Web サイト，または動画の視聴と，メインポスターの閲覧時間が設けられていた．その後 10 分の休憩をはさみ，Zoom のミーティングルームを使用して，1 ターン 15 分の質疑応答を前半 3 回，後半 3 回の計 6 回行った．
また，質疑応答を担当する人数を均等にするために，前半 7 名，後半 8 名がミーティングルームに残るよう割り当てた．質疑応答では，ポスターの閲覧，動画の視聴が済んでいることを前提として，ターンが始まると同時に質疑応答を開始した．
さらに，本プロジェクト独自の取り組みとして，限られた時間外でもコメントや質問ができるよ
うに，Twitter のハッシュタグ（#BF4 中間発表）を作成して利用した．
（※文責: 伊藤直樹）

6.1.2

発表技術の評価と反省

評価アンケートは 46 件の回答が得られ，平均評価は 10 点中 7.79 点であった．そのうち，平均点以上の評価を得た回答を高評価，平均点未満の評価を得た回答を低評価と定義する．発表技術に関して，高く評価された点として，• 他にはない動画で面白かった• 動画の強み活かしていて，内容も理解しやすかった
Group Report of 2020 SISP

- 38 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4• 動画にインパクトがあり，非常に目を引いたなどの意見があった．低く評価された点としては，• すべての語尾に「うさ」がついていると聞きにくい• 音声が早口で聞き取りづらかった• ポスターとスライドの内容がほぼ一緒だったのが残念などの意見があった．イメージキャラクターの使用と，そのアニメーションに機械音声を合わせた動画を作成したことよって，視聴者には今までにないような発表形式となり，強い印象を与えることができた．その反面，語尾に関してや音声の速度から，内容を理解しにくいといった意見も挙がった．
これらの評価から，今回の発表は，とくに動画に関しては好みが分かれるような発表になったと推測できる．
以上のことより改善点として，キャラクターの語尾の修正や，音声の速度の調整，また，動画に用いるスライドではとくに強調したい部分を抜粋すると良いといった点がある．
（※文責: 伊藤直樹）

6.1.3

発表内容の評価と反省

発表内容に関する平均評価は，プロジェクトの計画については 6 点中 4.70 点，目標設定については 6 点中 4.74 点であった．そのうち，上記と同様に，平均点以上の評価を得た回答を高評価，平均点未満の評価を得た回答を低評価と定義する．発表内容に関して，高く評価された点として，• 今後に希望が持てる内容であった• 前期の活動が細かく説明されていて，理解しやすかった• 仮アイデアもよく考えられたもので，興味深かったなどの意見があった．低く評価された点として，• 専門用語の説明がもう少し欲しかった• 最初，質問してよい時間なのかがわからなかった• 質疑応答がもう少し円滑だとなおよいなどの意見があった．このアンケートの回答から，発表の内容は理解しやすいが，専門用語の説
明が不足していたといえる．また質疑応答の受け答えはできているが，いきなり質疑応答が始まり，聞き手を少し困惑させてしまった部分があった．
以上のことより改善点として，専門用語はなるべく噛み砕いて説明すること，よりスムーズに質疑応答に入るために，冒頭におおまかなプロジェクトの説明を行うと良いといった点がある．
（※文責: 伊藤直樹）

Group Report of 2020 SISP

- 39 -

Group Number 7-A

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

6.2

成果発表

6.2.1

発表形式

2020 年 12 月 4 日金曜日に，本プロジェクト活動の成果を発表するための成果発表が行われた．
中間発表と同様，COVID-19 の流行により，オンラインでの開催になった．成果発表を行うにあたり，本プロジェクトの概要を説明する資料として，「A1 サイズのメインポスター」と「プロジェク
ト紹介の動画」と「プロジェクト紹介の Web サイト」を作成した．
（※文責: 伊藤直樹）

ポスター
メインポスターは中間発表のときと同様に主に 4 人で作成し，Illustrator を用いて作成した．共同作業も行うときも中間発表と同じく，Zoom や Discord の画面共有を用いた．
メインポスターには，「プロジェクト概要」，「活動内容」，「開発について」，「提案サービス」，「学び」という大項目を設けた．中間発表と同様に，A1 サイズのポスター 1 枚に収める必要があった
ため，本プロジェクトの説明や行ってきたこと，サービスについて最低限の説明をするために，5つに絞って記述した．
「プロジェクト概要」では，中間発表に作成したポスターと同様，本プロジェクトの目的とする
こと，ビーコンの特徴について記述した．
「活動内容」では，今年度の本プロジェクトの流れを「調査」，「企画・技術習得」，「開発」，「発表」の 4 つに分け，月別に，箇条書きで説明した．「開発について」では，本プロジェクトでは 3 グループすべてが「アジャイル手法」に挑戦したこと，開発の流れについての説明，チーム構成はアジャイル手法のスクラムに基づいて構成し，各チームにスク
ラムマスター，プロダクトオーナーを置いたことを記述した．「提案サービス」では，本プロジェ
クトが実際にどのようなサービスを開発し，提案するのかの簡単な説明と，各サービスのロゴを記載した．このポスターでの説明を簡単に記載した理由としては，メインポスターは A1 サイズ 1 枚という制約があったこと，また，詳しい説明は動画で行われているためといった理由がある．「学び」では，約 1 年間のプロジェクト活動を通じて，メンバーが学んだことや，活動において大事であると感じたことを記述した．
ポスターのデザインに関しては，カラーや文章の配置，構成は中間発表のときと大きく変化させずに作成した．中間発表のときと変更した点としては，以前の反省を活かすために，文章のブロッ
クごとの余白を少し大きめに確保し，フォントも少し線の細いものを使用した．この変更を施したことによって，詰められたように見える文章の問題を解消できた．また，左右の余白のスペースを少し小さくした．それを行うことによって，文章や図を記載できるスペースを増やし，より情報量を多くすることができた．さらに，中間発表のときよりも，図解表現を用いた説明を多くすること
で，視覚的に認識しやすいようなデザインを作り上げることを心掛けた．そのほかに，文章の文字
色を黒から明度を少し上げることで，下地の白とのコントラストを少し抑え，見やすくなるように施した．
（※文責: 伊藤直樹）

Group Report of 2020 SISP

- 40 -

Group Number 7-A

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

動画
動画の構成としては，順に「本プロジェクトの概要」，「今年度のプロジェクト活動の特徴」，「5月から成果発表までの活動内容」，「考案・開発した 3 サービス（MET.・でももに！・俺を食ってくれぇ!!）の紹介」といった流れとした．
動画は，中間発表の動画と同様に，主に Premiere のチームプロジェクトを用いて 5 人で作成した．中間発表動画作成の際の課題を意識し，あらかじめ動画の区切りごとで切ったシーケンスを 5つ用意して動画制作を開始した．この試みにより，手が余ってしまう人は 1 人も出ず，効率的な動
画編集を行うことができた．メディアがオフラインになってしまう問題は，正しい手法でメディアを取り込んでも起きてしまうことがあったため，Premiere 側のバグであると思われる．この問題
はこまめに編集結果を共有し，動画作成者間で反映されていないことなどの報告を行うことで，早めに問題を取り除くことができた．
中間発表の際のアンケートでは動画に対し，合成音声について，聞き取りやすい，わかりやすいといったポジティブな意見もあったが，反対に聞き取りにくい，内容を理解しにくいといったネガ
ティブな意見もあった．この結果から，合成音声は好みが分かれてしまい，大衆に向けての発表としては相応しくないと考えた．ただし，中間発表の際の，奇抜さやこだわりを取り入れて多くの人が興味を持って見ることができる動画を作るという目標は変えなかったため，キャラクターの使用はやめず，音声にはメンバーの声をキャラクターボイスとして採用した．中間発表の動画では，語尾に「うさ」とついていたが，これによって聞き取りにくくなっているという意見があったため，
普段話す言葉に近い「だよ」に変更した．動画内での表現方法として，中間発表では文字が多かっ
たが，期末発表では中間発表よりも文字での表現を減らし，図や表を用いることを心がけた．
成果発表の動画は，中間発表の動画よりも 5 分程度長いため，キャラクターが最後まで話していると視聴者が飽きてしまうと考え，各サービスの発表では，それぞれのサービスのプロダクトオー
ナーが出演した．撮影はグリーンバックを設営し，各サービスの印象を伝えやすい背景を合成する
ことで，視聴者が内容を理解しやすく，飽きにくい動画になった．音声に関しては，ラベリアマイ
ク，ショットガンマイク，iPhone を使用して声を録音し，3 つの音声を組み合わせることで，聞きやすい音になるように工夫した．各サービスの雰囲気や機能が視聴者に伝わりやすいように，アプリを使用している様子を表した動画やスマートフォンの画面を表示するといった工夫もした．
中間発表の動画では字幕を動画内に作成しており，概ね好評だったが，手間がかかってしまうことや画面の占有率が大きかったことを踏まえて廃止し，代わりに YouTube の字幕生成機能を使用した．YouTube の字幕生成機能はあらかじめ文章を書いたテキストファイルを読み込ませると，ある程度自動で時間などを調整して，字幕を生成してくれるといったものである．これを使用することで，字幕を使うかどうかを視聴者に委ねることができ，画面を端から端まで使って動画を作成することができた．
課題としては，「でももに！」の部分の編集を担当したメンバーが，開発でも多くのタスクを抱えており，編集に十分な時間を割くことができなかったため，編集を終えるのが遅くなってしまったことがある．この課題は，編集に対する時間や仕事量のマネジメントが行き届いていなかったことが原因であった．
（※文責: 平山翔真）Group Report of 2020 SISP

- 41 -

Group Number 7-A

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

Web サイト
成果発表の際には，プロジェクトに関する情報を集約し，より効果的に活動内容を伝えるため，

Web サイトを作成した．Web サイトの公開には，GitHub の Web ページホスティングサービスである GitHub Pages を用いた．
主な選定の理由として，すでに利用している GitHub の機能であるため，追加の知識が不要であったこと，Markdown ファイルや画像データを配置するのみで，面倒な環境の構築なしに作成に取りかかることができること，また，Markdown で作成したページには自動でテーマが適用され，簡単にサイトのデザインを選択することが可能であった点がある．Web サイトの作成に当たっては，プロジェクトメンバーのうち，主に文面や画像などのコンテンツを用意するメンバー，スタイ
ルを修正するメンバー，全体を調整するメンバーの 3 人が担当した．
内容としては，発表動画やプロジェクトの目的，ビーコンの特徴，活動内容，サービスロゴの一覧を用意し，発表動画を視聴しながらも，活動の目的や内容，各サービスの特徴などをすぐに確認できるように工夫した．また，そのほかに工夫した点としては，GitHub Pages に用意されているテーマでは不要なボタンや不都合なスタイルが存在したため，スクリプトやスタイルを用いて見やすく改善したこと，favicon を設定して，ブラウザのタブ一覧からページを判別しやすくしたことがある．
その結果，成果発表の評価では，Web サイトがわかりやすく書かれていたというフィードバッ
クが得られた．Web サイトの作成を行なった上で反省すべき点としては，作成開始が提出締め切
りの直前になってしまったことから，作業時間が限られていたために完成イメージの共有が十分にできていなかったという点である．
（※文責: 久米田羽月）

成果発表当日
成果発表当日の段取りは中間発表と同じで，15 時から 1 時間，各プロジェクトが作成した Web
サイト，または動画の視聴と，メインポスターの閲覧時間が設けられていた．その後 10 分の休憩をはさみ，プロジェクト WG によって用意された Zoom のミーティングルームのブレイクアウト
ルームに移動し，1 ターン 15 分の質疑応答を前半 3 回，後半 3 回の計 6 回行った．
また，質疑応答を担当する人数を均等にするために，前半 7 名，後半 8 名がルームに残るよう割り当てた．また，どのサービスに対しての質問にも対応できるように，各サービス 1〜3 名が残る
ように割り当てた．
質疑応答では，中間発表の反省を活かし，まず冒頭に本プロジェクトの説明と，提案する 3 つのサービス説明を，Google Slides を画面共有で映しながら 2 分程度説明を行った．その後，質疑応答の時間とした．
また，中間発表と同様に，Twitter のハッシュタグ（#BF4 最終発表）を利用し，コメントや質問を募った．
（※文責: 伊藤直樹）

Group Report of 2020 SISP

- 42 -

Group Number 7-A

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

6.2.2

発表技術の評価と反省

本年度の成果発表は，COVID-19 の影響もありオンラインで開催されることとなったが，動画担当大臣をはじめとした，各大臣を筆頭に，オンラインならではの効果的な見せ方ができたと感じている．上述でもあるが，中間発表では，本プロジェクトのイメージキャラクターである

うさとVOICEROID による合成音声を全編に使用したことで，聞き取りにくいといった声が複数上がった．これを解決させるため，成果発表では，プロダクトオーナーが実際に出演し，合成音声を使わず，プロジェクトメンバーがうさの声を担当する形へと変更した．また，クロマキー合成を用いる
ことにより，プロダクトオーナーが説明しながら，実際に使用している場面を紹介するといった画面構成が可能となった．その際，少しでも発表者の声が聞き取りやすくなるように，ラベリアマイ
クとショットガンマイクを用いて，反響の多い教室内で撮影するための工夫を施した．
その結果，発表後のアンケートでは，• 動画の音声が聞き取りやすかった• 発表者の表情を見ながらサービスの内容を聞くことができてよかったとの声が上がり，サービスごとのアプリケーションの使用方法がわかりやすかったという肯定的な意見が多数を占める結果となった．
中間発表終了後より，動画の見せ方について検討を重ねていたため，このような評価が得られ嬉し
く思うと共に，聴取者に効果的に伝わっていることがわかり，大変良い結果となったと考えている．
しかしながら，15 分という短い時間内にサービスの内容を全て詰め込むことが難しく，さらに説明が欲しいといった要望が見られた．また，キャラクターである”うさ”の語尾を”だよ”に変更し，
親しみやすさを演出したつもりであったが，不快であったというネガティブな意見も得られた．
当日の発表時には，サービスの紹介とプロジェクトの紹介を 15 分の動画に全てまとめることが困難であっため，Web ページを作成した他，質問時間にできるだけサービスの詳細について理解してもらえるように努めた．その際，Twitter を用いて，#BF4 最終発表というハッシュタグを作成し，聴取者からの質問を募集した．また，プロジェクトメンバーは全員が Zoom のカメラをつけ，質問に対応した．
これについて，• フレンドリーさを感じた• 良い雰囲気の発表だった• しっかりと段取り等を取られており，質問もスムーズに答えられていてよかったなどの意見があった．Twitter を利用したことで質問しやすい環境を作ることもこの要因であると考えている．質問に対しての受け答えについても，的確に答えられていたとの感想が得られた一方で，• アンケートへの誘導や，Web サイトの提示がよりスムーズであるとよかった• 質問がこない場合の対策が前半発表時には取れていなかったなどの問題点も指摘された．事前に予想される質問内容を各グループ内で考え，回答案を用意し，プロジェクトメンバー全員が答えられるように準備をしていたが，質問がこない場合の予測をしていなかったため，この結果になってしまったと考える．しかしながら，発表中盤より質問がなくてGroup Report of 2020 SISP

- 43 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
も，動画やポスターに含めることができなかった各サービスの補足説明などを行うことができていた．
これらの事前準備等により，非常に良い成果発表に繋がったと考えている．
（※文責: 増田翔）

Group Report of 2020 SISP

- 44 -

Group Number 7-A

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

第 7 章 各メンバーの振り返り
役割分担

7.1

本グループでは，アジャイルソフトウェア開発手法を参考にし，プロダクトオーナー 1 人，スク
ラムマスター 1 人を決定したうえで，3 人全員がサービス開発に関わった．サービス開発における役割分担は 1 人がモバイルアプリケーションの開発，1 人がサーバーサイドアプリケーションの開発，もう 1 人がモバイルアプリケーションとサーバーサイドアプリケーションの両方を担当した．
成果発表会に向けて 2 人が動画作成を行った．
（※文責: 野間直生）

7.1.1

久末瑠紅

プロダクトオーナー
プロダクトオーナーとして，プロダクトバックログに責任を持ち，プロダクトの価値を最大化できるように努めた．具体的には，サービスのビジョンを示し，作りたいサービスの方向性を明確にした．また，チームメンバーとコミュニケーションをとり，各々の作業を明確にした．これにより，メンバー全員が，互いにどのような作業をしているのかを把握することができる環境を作り上げた．また，期限が短かったため，「時間・品質・機能」の 3 つの観点
で，どれを優先すべきかを明示し，定めた優先度に則って開発が進むよう，プロダクトバッ
クログを管理した．また，最終成果発表では，プロダクトオーナーとしてサービスの紹介を
担当した．
ロゴの作成
ロゴの原案作成に参加した．また，最終決定までの段階で，各メンバーのアイデアを結合する段階で議論した．最終ロゴでは，原案で提出した文字部分が採用された．

MVC アーキテクチャの基礎基盤作成
サーバーサイドの機能を拡張しやすいように，MVC アーキテクチャを採用した．MVC
アーキテクチャにのっとったコードを書いたことがあるメンバーがいなかったため，アーキ
テクチャについて調べながら，機能が拡張できるよう基礎基盤を作成した．
サーバーサイドの API 機能の開発
モ バ イ ル ア プ リ ケ ー シ ョ ン と 通 信 す る た め の API を 作 成 し た ．作 成 し た 機 能 は「POST deletePage」，「POST exchangeBooksList」，「POST updateUserResidence」の3 つである．
モバイルアプリケーションの UI 作成
モバイルアプリケーションの画面遷移の定義や，UI レイアウトの配置を担当した．これまでモバイルアプリケーションの実装をしたことがなかったため，サンプルコードや書籍を参考に実装を進めた．
最終成果発表の動画・Web ページの作成
最終成果発表では，Web ページと動画の両方を組み合わせることとなった．動画編集では，

Group Report of 2020 SISP

- 45 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
本サービスの紹介パートの動画を作成した．また，プロジェクトについて紹介している Web
ページの構成・本文部分を担当し，作成・記述した．
人事改革担当各チームのプロダクトオーナーとともに，メンバー間で問題が発生していないか，また，メンバーがどのようなことを得意・不得意としているのかを文書にまとめ，見える化した．それにより，メンバー間で問題が発生しないよう，コミュニケーションを積極的にとった．
行政改革担当プロジェクト全体の体制について，常に問題がないか議論した．議論の結果，改善の必要があると判断した場合はプロダクトオーナーやスクラムマスターにコミュニケーションをとり，改善に努めた．
（※文責: 久末瑠紅）

7.1.2

鈴木利武

データベースの設計，構築
サービスで使用するデータを保存するデータベースの設計を行った．
サーバーサイドアプリケーションの開発

Golang を用いて，API サーバーの機能の開発を行った．作成した機能は「GET allBeaconUUIDList」，「GET myBookList」 ，「GET newUserID」 ，「GET pageList」 ，「GET spotName」 ，，，「GET exchangedPageList」，「GET allBeaconList」「GET image」「POST newBook」，，「POST newPage」，「POST visitSpot」，「POST pageImage」「POST updatePageText」の 13 個である．
テストデータの作成
架空の旅行をイメージし，ページの文章やページに追加された画像をサーバー，およびモバ
イルアプリケーションのデバッグ用に作成した．
サービスロゴ，アイコンの作成サービスをイメージしたロゴを Adobe Illustrator を用いて作成した．
ボタンイメージの作成
モバイルアプリケーションで使用するボタンのイメージを Adobe Illustrator を用いて作成
した．

UI/UX デザイン担当大臣
デザイン関連の質問に Slack などで回答した．
（※文責: 鈴木利武）

7.1.3

野間直生

スクラムマスター
スクラムの手法を参考に，スプリントレトロスペクティブや，スプリントレビュー，レトロ
スペクティブツアーなどのスクラムイベントを提案した．また，プロジェクトのメンバーから要望をしてもらったとき他のチームのスクラムマスターと協力してできる限り要望を叶えることができるようにスクラムイベントを調整した．

Group Report of 2020 SISP

- 46 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
画面のレイアウト，UI の作成

Adobe XD を用いてモックのたたき台を作成した．
MVP アーキテクチャの導入
クラスの責務を明確にしてチーム開発に取り組みやすいように MVP アーキテクチャを導入した．
モバイルアプリケーションの作成
サーバーとの連携部分や受け取ったデータを表示する画面を作成した．
進行担当大臣
毎週の水曜日と金曜日に行われる全体でのプロジェクト活動を，より有意義なものにするために活動した．全員が集まらなければできない作業を事前に把握することや，1 週間のうち6 時間というあまり長くない全員が集まる時間でいかに議論を行うかを意識し続けた．
行政改革担当大臣
プロジェクトの活動において，不自由を感じていないか，活動計画に不具合がないかなどを常に確認していた．
（※文責: 野間直生）

7.2

久末瑠紅の振り返り

前期の活動において，わたしたちのチームは迷走している状況が多かったと感じている．理由は，ファシリテーターという存在があまりに抽象的であったことである．「毎週チーム内で交代していくファシリテーター」という存在をつくった中で，そのファシリテーターの役割が明確化されていなかった．私の認識では，本チームのファシリテーターが行っていた行為は「次の会議の内容を決め，それ進行する」であった．しかしながら，ファシリテーター本来の役割は，それに限らない．例えば，スクラムを円滑に回すように支援する，タスクのバックログを作成していく中で考えうる必要事項やリスクを洗い出す，などの役割もある．ファシリテーターを回す際には，本来であれば，全員がチームの現状を把握し，長期的にさまざまな可能性を考えることが大切である．会議の内容を決めるアジェンダ作成のフェーズでは，参加できるメンバーは可能な限り参加していた．
しかし，アジェンダ作成をする際には，まずファシリテーターが 9 割を決め，細かいところを全員が修正するという形になっていた．言い換えると，ファシリテーター以外で，議論の内容に責任を感じ，積極的に発言していた人はほとんどいなかったと感じていた．つまり，1 週間が終わり，
ファシリテーターがまわってきた際に，（強い言い方をすれば）いままで責任を持っていなかった人が毎回ファシリテーターになる，という状況が生まれていたのである．それにより，「チームの中でだれも責任を持っていない状態」が発生してしまい，リスクを予期し，マネジメントを行う行
為がだれもできていなかった．そのような状況を作り出さないために，通常のプロジェクトではプ
ロジェクトリーダーが存在する．しかし，本プロジェクトにはプロジェクトリーダーが存在していない．
私は，後期の活動ではそのような事態を防ぎたいと考えた．まず，責任者を決めずメンバー全員で責任を分割するという考えは誤っており，全員が責任をもって行動する必要があると考え，組織体制の改革を考案した．そこで考えたのは，「全員が今まで以上に責任をもって行動する場合」と，「責任者を決め，その人の能力を向上させる」のでは，どちらの方がよいか，ということである．前者に関しては，正直実現は難しい．メンバーのプロジェクト学習に対するモチベーションの違いもGroup Report of 2020 SISP

- 47 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
あるうえに，そもそも経験値が不足していた．前期の「全員に責任を分担する」という方針により，成長できていた人がほとんどであったので，挑戦した意味は大いにあったと感じている．しかし，残り 2 か月しかない現状で，必要十分なスキルが身につき，かつ円滑にプロジェクトを進めることができるとは考えられなかった．後者の場合について考えてみる．もちろん，その人に膨大なタスクが降りかかる可能性は高い．ただ，私たちのチームは非常に仲が良く，困っているときにはみん
な手を差し伸べてくれると信じていた．そのため，そこに関しては問題ないと感じているので，責任者がタスクに埋もれて機能しなくなる可能性はあまり考えていなかった．そもそも，責任者の役
割を明確にし，膨大なタスクを抱えなければならないように工夫すればいいだけの話であった．つまり，責任者はリスク管理やスケジュール管理の技能が上がりやすくなり，プロジェクトも円滑に進みやすくなると考えていた．よって，後期は「責任者を決め，その人の能力を向上させる」ということをすべきだと，私はメンバーに主張した．
ほとんどのメンバーは賛成しなかった．理由は，今までの組織形態を大きく変えたくないというものであった．メンバーに代替案を求め，議論した結果できたのが「大臣制度」である．この大臣制度によって，メンバーのタスクへ対する責任感が大きく変化し，様々なタスクの進捗が安定するようになった．それを通じて，私は「責任の分割をする際には，明確な役割を定義すべきである」ということに気づいた．前期の活動を振り返った際にも述べたが，前期の場合はファシリテーターの定義があまりにもあいまい過ぎた．しかし，役割を明確にすることによって，タスクに対する責
任をどのように持てばいいのか，ということを大臣自身が意識できるようになる．いままで，このような責任分担を考えたことはなく，またこれほどうまく働いたため，今後参加するであろうチー
ム活動でもこの経験を有効活用したい．
開発面においても，成長を感じることができた．いままで，プログラミングをすることはあったが，アーキテクチャを意識しながらコーディングすることはあまりなかった．また，はじめてモバ
イルフロントの開発にも携わることができた．開発中はわからないことも多くあったが，メンバーと助け合いながら，しっかりと動くものを作れたことを誇りに思う．
プロジェクト学習では，チームの組織形態，責任のあり方，開発手法，アーキテクチャなど，本当にたくさんのことを学ぶことができた．この経験を，今後の活動でも活かしていきたい．
（※文責: 久末瑠紅）

7.3

鈴木利武の振り返り

プロジェクト学習を通して，一年を通して様々な経験をすることができた．前期の活動では，プロジェクトの進め方やフィールドワークの行い方，サービスの提案について多くのことを学ぶことができた．とくに，プロジェクトの進め方については，毎週ファシリテーターを交代して進行を行う方針は初めての経験であったのでとても新鮮であった．私がファシリテーターを勤めた週では，
うまく話を進行でできなかったと感じることが反省点である．後期では，進行方法が問題となり，メンバーの提案で大臣制を用いての進行であったが，あまり話に参加することができず，後期の活動でも反省点が残る結果となった．
今年は COVID-19 の影響で，オンラインでの授業であったため，様々なツールを用いて意見の交換や話し合いを行った．これらのツールを用いたことは初めてで，オンラインでのコミュニケー
ションのとり方について，良い経験になった．
サービスの開発で私は，データベースと API サーバーの設計，開発を担当した．このほかに，

Group Report of 2020 SISP

- 48 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
サービスのロゴ，iOS アプリケーション内で使用されるアイコンの作成を行った．API サーバーの開発では，私が今までに使用したことのない Golang を使用し，MVC アーキテクチャに則ったプログラムを構築した．また，iOS アプリケーションの開発者と API の仕様を共有するために

GitHub Wiki と OpenAPI を使用した．これを用いることで，iOS アプリケーションの開発者が知りたい機能をすぐに知ることができ，開発をスムーズに行うことができた．プログラムの仕様を言語化してまとめることで，チームでの作業が円滑に行うことができると感じた．API のリクエ
ストやレスポンスの定義は初めてであったため，手探りでの開発であった．定義に間違いや正常に動作しない構造がいくつもあり，他のメンバーに迷惑をかけてしまう部分があったことは反省点である．1 か月程度の短い開発期間であったが，チームでの開発，Golang の修得，MVC アーキテク
チャ，API 設計，データベース設計など多くのことを学ぶことができた．
プロジェクト学習は今までの授業では得ることができなかった良い経験を得ることができた．今後，チームで開発を行う機会があれば，プロジェクト学習での経験を活かしたい．
（※文責: 鈴木利武）

7.4

野間直生の振り返り

プロジェクト活動での PBL の経験は私にとって初めての体験であった．最初にプロジェクト全体での活動の振り返りをする．前期の活動では，プロジェクトリーダーを決めなかった．プロジェ
クトリーダーを決めない活動は，皆がプロジェクトリーダーと同じ責任を持って週ごとの交代制でプロジェクトリーダーを担当することが目的であった．私はこの方針によってプロジェクトのメ
ンバー同士が気軽に相談することができた．また，プロジェクトの現状を把握し続けることができた．しかしこの方針ではプロジェクト活動において発生する責任をメンバー全員に均等に分配してしまったことにより，責任がどこにも持っていないことになってしまった．その結果，決定事項が先延ばしになり期限が直前になってしまったと私は思っている．私は前期からスクラムにおけるメンバー同士の信頼の大切さと，全員がプロジェクトリーダーと同様の責任を持つためにはメンバー
全員がスクラムについて理解している必要があることを学んだ．後期の活動では，前期の活動の経験からプロジェクトリーダーを設置するか，大臣制を導入するか議論を行った．大臣制とは，プロジェクト活動において発生する責任を細分化し，責任ごとに役割を分担する制度である．私たちはこれまでの活動からプロジェクトリーダーを設置することは私たちのプロジェクトには向いていな
いと判断して大臣制を導入することを決定した．この議論で私は責任についてとスクラムにおける役職とその仕事について学ぶことができた．大臣制を導入してから私はスクラムマスターを担当した．今までスクラム自体経験したことがなかったのでもちろんスクラムマスターも初めての経験である．私は同じチームのメンバーや私以外のスクラムマスターに相談しながらスクラムイベントを採用した．スクラムイベントを導入し，メンバーから要望や疑問があれば要望に沿ってスクラムイ
ベントを変更することで私たちに合ったスクラムイベントを作ることができた．この体験によって私はスクラムを時間が経つごとにさらに良いスクラムを行えるよう考え続けることが人同士の関係で合ったため，とても重要であり難しく感じた．サービス開発では，私は UI の設計と iOS アプリ
ケーションの開発を行った．UI の設計では，今までに人に使ってもらうことを考えた UI を作成したことがなかったため，とても困難であった．使いにくい UI はレビューしてもらうまで気がつくことができなかった．動くものを作って人に見てもらうことが UI を完成させるうえでとても重要であると感じた．iOS アプリケーションの開発では，アプリケーションを作り上げる経験をしたこGroup Report of 2020 SISP

- 49 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4とがなかったため，画面遷移の苦労を考えていないアプリケーション設計にしてしまった．私はこの開発経験から，アプリケーションを作成することが決まった段階でアプリケーション設計の細分化をする必要があると学んだ．
（※文責: 野間直生）

Group Report of 2020 SISP

- 50 -

Group Number 7-A

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

第 8 章 まとめと展望
8.1

前期の振り返り

前期では，プロジェクトリーダーを設けず，週替りのファシリテーター制度でプロジェクト活動を進めた．これによって，特定の人に負荷が集中することを避けた．プロジェクトの最終意思決定については全員が納得するように運営した．これは，メンバーの全員がしっかりと責任意識を持ってプロジェクト活動に能動的に参加することを促すことにもつながった．
タスクの管理については，GoogleJamboard を用いてバックログを作成し，タスクを優先度順に並べて管理することで，今回取り掛かるべきタスクや，今後のやるべきことなどをメンバー全員で共有できるようにした．しかし，ファシリテーター交代の際，前週のファシリテーターと次週のファシリテーターで情報共有がうまくいかなかった．また，タスクの管理自体は GoogleJamBoardを用いて全員で共有し管理していたが，タスクの完了までの具体的な見通しをたてることに時間がかかってしまい，本質的な作業に取り掛かるのに遅れてしまう事があった．この問題の前者に対しては，議事録を複数人で書き，取りこぼしを防ぐこと，Zoom での会議を録画するなど，情報を残すことを徹底することで解決していった．また後者に対しては，全員でバックログの粒度を上げる
作業や，タスクの重さづけを行う作業などを行うことで解決した．
前期における具体的な活動としては，ロゴ制作，フィールドワーク，サービス考案という活動を行ってきた．ロゴ制作では，メンバーのそれぞれがプロジェクトのイメージを考えロゴをデザイン
してロゴに込められた想いや意味などを発表し合った．その後メンバーのレビューをもらい，ブラッシュアップを行っていった．メンバーによる投票を何度か行い，都度ブラッシュアップしていき，数を絞り込んでいくことで現在のプロジェクトのロゴが確定された．
フィールドワークでは，函館の 5 ヶ所でフィールドワークを行った．フィールドワークを行った場所は，「五稜郭」，「赤川・美原・富岡・昭和」，「函館駅・西部地区」，「七飯・北斗」，「空港・湯の川」である．この 5 ヶ所を周り，各々気づいたことや思ったことについて GoogleJamboard
や Slack のフィールドワーク用に作成されたチャンネル，手書きのメモなどを使用して書き出していったり，参考になりそうなものの写真を撮っていったりした．フィールドワーク終了後，

GoogleJamboard を用いて意見を書き出し，KJ 法を用いてグルーピングを行い，関連性を明らかにした．サービスの考案では，フィールドワークのまとめや，自身の経験などからサービスを考えた．その際，BSKJ 法に加えて，ハッカソン方式を用いて，サービスのアイデアを洗練させた．また，Slack のワークスペースに誰でもいつでも自由にアイデアを投稿できるチャンネルを作成し，ユニークなアイデアを考案，発表できる機会を増やすことができた．また OST をしながら，自身の興味のあるアイデアに対し議論することでアイデアをより深めていくことができた．これらの活動によって，多くのアイデアの中から，メンバーのそれぞれの良いと思った部分を組み合わせ，ブラッシュアップを行った．
前期最後の中間発表では，ポスターと動画を作成し発表した．ポスターではメンバー全員で文章を添削し，より伝わりやすいポスターの作成に努めた．動画ではスライドを用いてプロジェクトを説明した．より多くの人に興味を持ってもらうために，本プロジェクトのオリジナルキャラクター
を解説役として起用した．さらに，動画内で合成音声を用いることでより印象に残る動画を目指しGroup Report of 2020 SISP

- 51 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
た．この中間発表において現時点で上がっているサービスを発表し，聴衆にアンケートを取った．
そして，このアンケートの結果を参考に後期でサービスの決定をしていくことになった．
（※文責: 宮田悠冶）

8.2

後期の振り返り後期の活動では，大臣制を導入した．この制度は，前期の全員がプロジェクトリーダーを担当
し，全員が平等に責任を持つ活動方針によって生じた，責任の所在がうやむやになってしまう問題を解決するために導入した，制度である．この大臣制の導入によって，プロジェクトリーダーの仕事が細分化され，担当者がそれぞれ決まった．担当者が決まったことによって，それぞれの仕事にメンバーが責任を持つことができるようになった．私たちは，3 人という少ない人数の中で，プロダクトオーナー，スクラムマスターを決めて開発を行った．また一週間を 1 スプリントとプロジェ
クトメンバー全員で定め，一週間ごとにレビューやスクラムイベントを実施する環境を整え開発に取り組んだ．
（※文責: 野間直生）

8.3

今後の展望

8.3.1

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

今回実装したサービスの利用者は，日本人観光客のみならず，外国人観光客も想定している．しかしながら，まだ多言語対応はしていないため，日本語がわからない外国人は利用することができない．また，表示する思い出帳をカテゴリーで分けたり，並べ替えることができないため，ユー
ザーが欲しい情報をすぐに見つけることが難しい．今後は，これらの機能を実装し，より多くの人が，より手軽に利用できるようにしたいと考えている．
（※文責: 久末瑠紅）

他言語対応
今後の機能として最も多言語対応が優先されている．これは，モバイルアプリケーションで対応するべき機能であると考えている．Swift では NSLocalizedString という型が存在していて，事前に作成しておいた strings ファイルと呼ばれるファイルを用いると，「hello」という言葉に対し，日
本語版では「こんにちは」英語版では「Hello」と表示させることが可能である．
（※文責: 野間直生）

マップ機能
また，本サービスでは，観光客に新しい函館の歩き方を提案することが目的である．歩き方を提案する上で，思い出帳の写真や文章だけでなく，マップを用いた歩き方の提案がユーザーにより強く歩き方を提案することができると考える．マップを用いることで，別のユーザーがどの観光地をどの順番で歩いたかを 1 枚の画面で確認することができる．観光地を巡った順番も確認することがGroup Report of 2020 SISP

- 52 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4できるため，より具体的に函館の歩き方を提案できる．
（※文責: 野間直生）

実装方法について実装について，本モバイルアプリケーションでは，画像をサーバーから受信している．実装には，CollectionView と呼ばれるクラスを用いたが，このクラスは性質上画面の中にコンテンツが表示されると決まった段階でサーバーにコンテンツに使われる画像のリクエストを送信している．
つまりページを捲るたびにリクエストを送信し，画像を受信している．テストや成果発表の段階だと現状のままでも問題はないが，実際にユーザーに使ってもらうとなった際，ページを捲るたびにリクエストを送信し画像を受信していることは，サーバーに対してとても負荷になってしまうと考えている．よって，事前にコンテンツの表示に必要な画像を全てサーバーから受信しておくなど何らかの対策が必要だと考えている．
（※文責: 野間直生）

8.3.2

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

動画の取り扱い
本サービスでは，思い出帳を通し，ユーザーの体験を共有することで観光客に新しい函館の歩き方を提案することが目的である．体験の共有には，動画を使用することで画像やテキストでは伝えることのできない体験の共有が可能である．この機能を実装することで，より一層，体験の魅力を共有でき，新たな函館の歩き方を提案できると考える．
（※文責: 鈴木利武）

編集機能
現段階では，ページや思い出帳のテキストを一度設定すると編集を行うことができない．あとから，その時は気づかなかった情報を加筆することで，さらに良い情報を他のユーザーに届けることが可能である．また，誤字やテキストそのものを編集したい場合も考えられる．そのような理由から，ページや思い出帳の編集機能は必要であると考える．
（※文責: 鈴木利武）

実装方法について
今回開発したサーバーの API には，似た機能が複数実装されていたり，使用すべきメソッドが間違っていたりするものが存在する．サーバーの API が複雑化すると，それだけモバイルアプリ
ケーションの処理も複雑化する．なるべく重複が少なく，かつ分かり易い形式でデータを返すことが重要ではないかと考える．具体的には，自分の思い出帳を取得する機能と交換した他人の思い出帳を取得する関数が分かれており，実際に開発中にも機能の使い間違えが発生した．使用するメ
ソッドについては，GET メソッドを使用しているのにもかかわらずデーターベース上の値を更新
しているものがあり，本来 POST メソッドを使用しなければならず，これは変更すべき機能であGroup Report of 2020 SISP

- 53 -

Group Number 7-A

Leverage the Beacon IoT for Our Smarter Life in Hakodate Real Downtown - Beacon FUN 4
る．また，現在はログイン機能や暗号化通信，アカウント認証などが行われていない．本サービスを実際にユーザーへ提供するためには，セキュリティについても考え，実装する必要がある．
これらの技術的課題を解決し，ユーザーが安心して利用できるサービスを提供したい．
（※文責: 鈴木利武）

Group Report of 2020 SISP

- 54 -

Group Number 7-A

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

参考文献[1] 総務省｜平成 30 年版 情報通信白書｜ IoT デバイスの急速な普及，
https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h30/html/nd111200.html（2021 年 1 月 8 日閲覧）

[2] Beacapp Here(屋内位置情報サービス) ，https://jp.beacapp-here.com/ （2021 年 1 月 7 日
閲覧）[3] Coke ON（コーク オン），https://c.cocacola.co.jp/app/ （2021 年 1 月 7 日閲覧）
[4] 函館市観光基本計画策定調査平成 25 年 3 月，
https://www.city.hakodate.hokkaido.jp/docs/2014032500399/ﬁles/siryou250515.pdf（2020 年 12 月 26 日閲覧）

[5] 函館市総合計画（2017〜2026）について，
https://www.city.hakodate.hokkaido.jp/docs/2016122100014/ （2021 年 1 月 8 日閲覧）
[6]【サルでもわかる BLE 入門】（１） BLE の基礎，
https://www.musen-connect.co.jp/blog/course/trial-production/ble-beginner-1/（2021 年 1 月 13 日閲覧）

[7] iBeacon とは ｜ 電源設計の技術情報サイトの TechWeb，
https://techweb.rohm.co.jp/iot/knowledge/iot02/s-iot02/04-s-iot02/3896（2021 年 1

月 13 日閲覧）[8]【サルでもわかる BLE 入門】（３） BLE ビーコンの基礎，
https://www.musen-connect.co.jp/blog/course/trial-production/ble-beginner-3/（2021 年 1 月 13 日閲覧）

[9] アジャイルソフトウェア開発宣言，https://agilemanifesto.org/iso/ja/manifesto.html（2021 年 1 月 6 日閲覧）

[10] Jeﬀ Sutherland & Ken Schwaber，スクラムガイド - Scrum Guides，
https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf（2021 年 1 月 6 日閲覧）

[11] 立命館大学，ブレーンストーミングと KJ 法，http://www.ritsumei.ac.jp/ yamai/kj.htm（2020 年 12 月 23 日閲覧）

[12] OST(オープン・スペース・テクノロジー)，HUMAN VALUE，
https://www.humanvalue.co.jp/keywords/ost/ （2020 年 1 月 20 日閲覧）
[13] 4travel

ホームページ ，https://4travel.jp/ （2021 年 1 月 6 日閲覧）

[14] Triple

ホームページ，https://triptriple.com/ja （2021 年 1 月 6 日閲覧）

Group Report of 2020 SISP

- 55 -

Group Number 7-A

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

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

図 A.1

Group Report of 2020 SISP

中間発表で使用したポスター- 56 -

Group Number 7-A

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

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

図 B.1

Group Report of 2020 SISP

成果発表で使用したポスター- 57 -

Group Number 7-A