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

プロジェクト名
函館補完計画：序 〜 AR 技術でリアルなまちをハックする

Project Name
Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

グループ名
ARuku

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

17-A

プロジェクトリーダ/Project Leader
佐藤有飛

Yuhi Sato

グループリーダ/Group Leader
佐藤有飛

Yuhi Sato

グループメンバ/Group Member
齊藤優月
坂田悠

Yuzuki Saito
Yu Sakata

藤本陽人

Haruto Fujimoto

藤井大悟

Daigo Fujii

指導教員
松原克弥 鈴木昭二

奥野拓 藤野雄一

Advisor
Katsuya Matsubara Sho’ji Suzuki Taku Okuno Yuichi Fujino

提出日
2023 年 1 月 18 日

Date of Submission
January 18, 2023

概要
本プロジェクトは、AR 技術で函館のまちにあるモノ・コト・トキをカスタマイズし、新たな体験や価値を創造することを目的とする。

AR を用いることにより、函館という地域に付加価値をもたらすことに重点をおいたサービスの考案、開発、評価実験を行う。サービスの提案を行うにあたり、実際に函館の街でフィールドワークを行って街の課題を洗い出した。
洗い出した課題をもとに、函館らしさ・AR である理由・課題解決を行う理由・新規性・実現可能性・体験の楽しさの６つに重点を置き 45 個のアイデアを創出した。
アイデアを 3 つに絞り込んでからは、メンバー同士で議論して、それぞれのアイデアを開発す
る 3 つのグループに分かれた。
私達のグループは ARuku という AR グラスを用いて散歩に付加価値を与えるサービスの開発に取り組んだ。
キーワード

函館 , XR , AR（※文責: 坂田悠）

-i-

Abstract
The purpose of this project is to create new experiences and values by customizing
things, matters, and times in Hakodate using AR technology.
In order to propose the service, ﬁeldwork was conducted in Hakodate to identify thecity’s issues.
Based on the issues identiﬁed, 45 ideas were generated, focusing on the following six
areas: Hakodate-ness, reasons for AR, reasons for solving issues, novelty, feasibility, andenjoyment of the experience. By further brushing up on these ideas, the team narrowed
them down to eight ideas.
Once the ideas were narrowed down to three, we discussed them with each other anddevide into 3 groups.
Our group worked on the development of ARuku, a service that adds value to a walkusing AR glasses.
Keyword

Hakodate , XR , AR（※文責: 坂田悠）

- ii -

目次
第1章

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

1

1.1

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

1

1.2

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

1

1.3

AR について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

サービス考案までの活動内容

2

2.1

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

2

2.2

勉強会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.3

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

3

2.3.1

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

3

2.3.2

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

3

2.3.3

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

3

2.3.4

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

4

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

4

2.4.1

各自アイデアの共有 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.4.2

ブラッシュアップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.4.3

アイデアの評価基準を決定 . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.4.4

アイデアの絞り込み . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.4.5

最終的なアイデアの絞り込み . . . . . . . . . . . . . . . . . . . . . . . .

9

第2章

2.4

第3章

サービスについて10

3.1

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

10

3.2

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

10

3.3

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

10

3.4

AR 技術を用いた理由 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.5

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

11

3.6

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

12

3.6.1

スタート機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.6.2

オブジェクト表示機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.6.3

スコア表示機能. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.6.4

ミニマップ表示機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

第4章

4.1

4.2

開発プロセス

15

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

15

4.1.1

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

15

4.1.2

学習施策 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

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

16

4.2.1

導入した手法. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
- iii -

16

第5章

4.2.2

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

17

4.2.3

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

18システム仕様19

5.1

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

19

5.2

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

19

5.3

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

20

5.4

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

21

各メンバーの役割と活動の振り返り

23

6.1

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

23

6.2

佐藤有飛の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

6.3

齊藤優月の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

6.4

坂田悠の振り返り. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

6.5

藤本陽人の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

6.6

藤井大悟の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

成果発表

29

7.1

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

29

7.2

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

29

7.2.1

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

29

7.2.2

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

30

第6章

第7章

第8章

まとめ

31

8.1

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

31

8.2

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

32

8.3

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

32

付録 A

成果発表会で使用したメインポスター

34

付録 B

サービス説明用ポスター

35

参考文献

36

- iv -

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

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

背景

近年、XR（Extended Reality）の普及が進んでいる。XR は、様々な仮想空間技術を指すが、現実世界と仮想世界を融合することで、実際には体験できないようなシミュレーションを実現できる。

AR（Argument Reality）も XR の一つで、現実世界と CG オブジェクトを一体化させることができる。AR を活用したサービスには、ゲーム、顔加工アプリ、家具配置シミュレーションなどがある。さらに、様々なサービスが開発・試験導入されている。スマートフォンなどのデバイスを持っていれば、誰でも利用できるためサービスやアプリケーションの需要が高まっている。
（※文責: 藤井大悟）

1.2

目的

本プロジェクトの目的は、AR 技術で函館のまちにあるモノ・コト・トキをカスタマイズし、新
たな体験・価値を創造することである。AR を用いたサービスの考案・開発・評価実験を行う。
（※文責: 藤井大悟）

1.3

AR についてAR とは、私たちの目の前にある現実の世界に写真や動画、CG などのデジタル情報を重ね合わせて表示する技術である。[1]
似たような技術として、VR(Virtual Reality) やメタバースなどの現実世界とは異なる仮想空間
を 3DCG で実現する技術が注目されているが、AR 技術には実際に暮らしているリアルな世界をデジタル空間とつなぐことができるという特徴がある。
（※文責: 藤井大悟）

Group Report of 2022 SISP

-1-Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

第 2 章 サービス考案までの活動内容
2.1

ロゴ作成

本プロジェクトでは、プロジェクトの特徴やイメージを表現するとともに、メンバー全員の一体感を生むために、今年度のプロジェクトのロゴを制作した。(図 2.1)
はじめに、メンバー全員がロゴ案を 1 つ以上考案してロゴの発表会を行い、それぞれの案についてレビューを行った。1 回目のレビュー方法は、それぞれの案の良いところだけを伝える形式をとった。2 回目に、レビューや他のメンバーのロゴデザインを参考に、各自新たなロゴ案を考案し、発表会を行った。2 回目の発表会のレビューでは前回と形式を変更し、良いところだけでなく改善点も指摘するレビューを行った。その後、再度新たなロゴ案をメンバー全員が考案し、3 回目の発表会を行った。この発表会後、メンバーによる投票を行い、ロゴ案の決定に至った。そのとき、決定したロゴ案の考案者を中心に、補佐のメンバーを 3 名決定した。その後、考案者と補佐がデザイ
ン原案の改善をメンバーの意見をもとに行い、ロゴデザインの最終版を制作した。
今年度のロゴは、本プロジェクトで使用する「AR」技術を前面に押し出し、全色を紫系統の色でまとめることでクールさとスタイリッシュさを持ち合わせたデザインである。円の中から「A」の文字の一部をはみ出させることで、新規プロジェクトとしての第一歩を踏み出すことを表している。
（※文責: 藤井大悟）

図 2.1

Group Report of 2022 SISP

プロジェクトロゴ-2-

Group Number 17-A

Hakodate Complementary Plan: 1.0

2.2

Hacking a real city AR technology

勉強会

アジャイル開発とは、小さなソフトウェアチームのためのシステム開発手法の一つである。 後期でのアジャイル開発の実施にあたって、株式会社アトラクタの永瀬美穂氏によるアジャイルワー
クショップに参加した。 ワークショップでは、初めに、アジャイル開発とは何かについて説明を受けた。次に、実際のビジネス状況やプロジェクト成功率などの情報をもとに、アジャイル開発の概要・手法について学んだ。最後に、参加したプロジェクトの中で、それぞれチームを作成し、チーム対抗でアジャイル開発についてのクイズが行われ、ワークショップの内容の理解をより深めた。
（※文責: 藤井大悟）

2.3

フィールドワーク

2.3.1

事前調査

函館の街やその周辺に存在する問題や課題を調査することを目的としてフィールドワークを行った。フィールドワークを実施する地域は、調査を元にメンバー間で話し合った結果、「美原・赤川」「五稜郭」「湯の川」「西部地区」「十字街・谷地頭」に決定した。そして、3 人 1 組のグループに別れ、各地域へのフィールドワークを行った。その後、調査を行うにあたり注意するべきことを確認した上で各グループごとタイムスケジュールを組み、それに従い実地調査を行った。
（※文責: 藤井大悟）

2.3.2

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

フィールドワークの実施にあたって、南部美砂子先生によるフィールドワークについての講義を受けた。
はじめに、フィールドワークでトラブルが起こらないように、トラブルの事例をもとに説明を受けた。またフィールドワークとは何かということを学んだ、これにより，フィールドワークは目に見えない何か（時間軸・関わる人・社会）を学ぶための一つの方法であり、得た情報を整理した上で出た結論を言語化し、他人に伝達・共有することが大事だと確認することができた。
次にフィールドワークは目的ではなく手段の一つであり、他者の合理性を理解することが重要であると学んだ。
最後に、調査者としての態度を学んだ。調査をするときは相手に迷惑をかけることを理解し、守秘義務や匿名性・調査先で生まれる人間関係に注意して調査に臨むべきだと知ることができた。
（※文責: 藤井大悟）

2.3.3

実地調査

レクチャー後、決定した 5 つの地域に 3 人のグループに分かれて調査した。
調査した日程は、まず 6 月 1 日に五稜郭、湯の川、美原・赤川を 6 月 5 日に西部地区、十字街・谷地頭のグループで訪問した。なお、本調査では COVID-19 の対策としてなるべく密な状況になGroup Report of 2022 SISP

-3-Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

ることを避けるなど、十分注意をして実施した。
五稜郭周辺では五稜郭公園、五稜郭タワー、美術館、資料館を中心に調査を行った。湯の川周辺
では函館空港、競馬場、函館アリーナ、足湯を中心に調査を行った。美原・赤川周辺では笹流ダム、四稜郭、亀田支所・亀田交流プラザ、五稜郭駅、青函フェリー乗り場、津軽海峡フェリー乗り場、蔦屋書店を中心に調査を行った。十字街・谷地頭のグループでは函館駅、谷地頭、中心に調査を行った。西部地区周辺では、函館駅、十字街、函館公園、谷地頭などを中心としたエリアと金森倉庫、元町公園、旧イギリス領事官、旧函館区公会堂などを中心としたエリアの調査を行った。また、調査中には Slack にフィールドワーク用のチャンネルを作成し、写真や文章で気づいた点を共有した。
（※文責: 藤井大悟）

2.3.4

振り返り

フィールドワークで得た知見を他グループと共有を行うため、グループごとにフィールドワーク
で得られた情報をまとめ、気づいた点などをオンラインホワイトボードサービスである Miro を用
いて書き出した。そして、気づいた点からサービス案を考え書き加えた。その後、より効果的に知見の共有を行うため、フィールドワークを行った各グループから 1 人ずつ選出して 1 グループ 5 人のグループを 3 つ作り、結果の報告を行った。最後に全体で情報を共通点ごとにグルーピングし、情報の整理をした。
（※文責: 藤井大悟）

2.4

サービスの考案

2.4.1

各自アイデアの共有

フィールドワークで発見した函館の問題点や課題を解決できるようなサービスアイデアを、各自で 5 個ほど考案した。これらのアイデアをほかのメンバーと共有するために、3 5 グループに分かれてグループワークを行った。共有する際は「解決したい課題」、「解決方法」、「アイデアの推しポ
イント」が明確になるように議論を行った。その後、グループ内でそれぞれのアイデアに対するフィードバックを行った。
（※文責: 藤本陽人）

2.4.2

ブラッシュアップ

自分のアイデアに対するフィードバックを受け、それぞれでアイデアの改善を行った。このときはまだサービスとして実装するには内容が不十分だったため、全体でアイデアを考案する際にどのような方針をもとにするのかをを考えた。話し合いの結果、「新しい体験ができる」、「函館らしさがある」、「AR らしさがある」、「危険でない」の４つに留意してアイデアを考案することが決まった。これらの基準をもとに、各自で自分の考えたアイデアについてさらなる改善をおこなった。加
えて、各自で考案したアイデアをジャンルごとに分類し、アイデアの傾向把握や絞り込みをする上Group Report of 2022 SISP

-4-Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

での参考にした。
（※文責: 藤本陽人）

2.4.3

アイデアの評価基準を決定

ブラッシュアップしたアイデアをさらに絞り込むことにした。このとき、アイデアを絞り込む際の評価基準が必要なのではという意見が出たので、それについて話し合うことが決定した。私たちはプロジェクトメンバーで３人ずつの５つのグループに分かれ、評価基準について話し合った。その後、各グループで考案した評価基準を全体で共有した。共有後、評価基準ごとに評価の重みをつけることが決定した。重みの配分をどのようにするべきかを再びグループで話し合い、それを共有した結果、「AR ならではの体験かどうか (25%)」「函館・その土地でしかできないか (25%)」、「実
現可能かどうか (15%)」、「体験が楽しいかどうか (15%)」、「新しい体験かどうか (10%)」、「課題を解決する意義があるか (10%)」の６つの項目と重みを評価基準として定めた。
（※文責: 藤本陽人）

2.4.4

アイデアの絞り込み

中間発表で発表するアイデアの絞り込みを行った。当初は、評価基準をもとに１人ずつ各自がブラッシュアップした５つのアイデアを壇上で発表し、それを他のメンバーが評価するという形式で絞り込みを行う予定だった。しかし、一人ずつ壇上で発表することで雰囲気が暗くなり、意見が出しづらい空気感になってしまったので、プロジェクトメンバーで話し合った結果絞り込みの方法を変更することにした。話し合いの結果、グループワークで絞り込みを行うことにした。１グループ
あたり３〜４人の４グループに分かれ、各自の持ち寄ったアイデアを共有した。このとき、共有するアイデアは持ち寄ったものをすべて発表するのではなく、自分が自信を持っているものだけに限定した。その後、評価基準をもとに各グループで３〜５個のアイデアに絞り込み、その中でアイ
デアのさらなるブラッシュアップを行った。次に、４つのグループを再編成し２つのグループにした。そこで、グループごとに絞り込んだアイデアを互いに発表した後に、持ち寄ったアイデアの中から４〜５つに絞り込んだ。最後に、２つのグループで絞り込んだアイデアを全体で共有し、似ているアイデア同士の合成などを行い、最終的に８つのアイデアに絞り込んだ。ここで絞り込んだ８
つのアイデアは中間発表で公開することとなった。

Group Report of 2022 SISP

-5-Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

以下が一時的に決まった８つのアイデアである。

• この衣装いいでしょう– 深い歴史がたくさんある函館には多くの歴史的展示物や、街並みがある。
– これをさらに楽しむために、函館公会堂ではレトロ衣装のレンタルを行っており、これを着用して街を歩いたり写真を撮ったりすることができる。

– しかし金銭的な問題や衣装を着用する手間などの点で、ややハードルが高いサービスとなっている。

– レトロ衣装をより楽しんでもらいために、屋外や屋内において、AR を活用してレトロ衣装を疑似体験できるスポットを設ける。衣装は画像や 3DCG によって複数のレパー
トリーを用意し、キネクトなどの人間の動きを認識する技術を利用して被写体に AR で衣装をフィッティングさせる。利用者は、好きな衣装とアクセサリーを選択し自分好みのスタイルにカスタマイズする。また、撮影時に背景やフィルターによって画質などを変更し、当時の雰囲気や環境により近い形で撮影することも可能とする。

• たわー。
– 多くの観光タワーには床面がガラス張りになっているスペースがあるが、そのスペースは限定的であり、函館の五稜郭タワーも例外ではない。

– 高所が得意な人にとっては全面がガラス張りの観覧車ほどのインパクトや東京スカイツ
リーほどの高さが五稜郭タワーにはないため、物足りないと感じてしまう。

– 高所が苦手な人にとっては、床面のガラス張りになっているスペースが展望デッキ 2 階から階段を降りてすぐの所に設置しているため、彼らの不安を更に煽ってしまう恐れがある。

– このサービスは五稜郭タワーの展望台の床面に拡張された映像を AR グラスを通して体験するものである。映像の入手方法については、五稜郭タワーの外側にカメラを設置し、リアルタイムの映像を入手する。または、五稜郭タワー付近にカメラを搭載させたドローンを飛ばし、撮影を行うことを想定している。そして、入手した映像にフィル
ターや演出を加える。こうして加工した映像を AR グラスを着用したユーザが自由に選択し、体験してもらう。フィルターの詳細は、街全体にフィルターを掛けることによって、四季ごとの街並みや一世代前のレトロな街並みといった訪れた時期や季節に関係なく、多くの五稜郭の街並みを体験するものや、床面を水族館のように魚を泳がせるといったものなどを考えた。

• HAKODATE ATLAS– 函館にはさまざまな個人経営のお店があり、これらの中には元町周辺などの路地裏に存在し隠れていて見つけづらいお店や、地図アプリやインターネット上にあるお店の情報が公開・更新されていないお店もある。

– 個人経営のお店には各店舗のウェブサイトや SNS アカウントが存在することは少なく、実際にお店を訪ねても、臨時休業や閉店になっていたり営業時間が変わっていたりすることもある。

– 函館のお土産の詳細が知られていないという事実もあり、函館には有名なお土産が少な
く、函館に来た多くの観光客は白い恋人やじゃがポックルなどのような北海道ならどこでも買うことができるようなお土産を買って帰ることが多い。

Group Report of 2022 SISP

-6-Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology– このサービスは、どこにどんなお店があるかがわかるサービスである。使用場所は主に五稜郭タワーや函館山などの高い建物、大門横丁などの店が密集しているエリア、実際に訪ねるお店の前と、お土産屋の店内を想定する。はじめに、ユーザがお店のある方向に向かってスマートフォンをかざすと AR 上でお店のジャンルごとに色の異なるピンが立つ。次に、ユーザがピンをタッチするとお店の営業時間や口コミなどお店の情報が表示される。次に、高い建物やお店が密集しているエリアで使用する場合には、ジャンルや地域での絞り込みの機能も使うことができる。例えば、ユーザが和食を食べたいときには、「飲食店・和食」と絞り込みをすることで探したい方角からお店を見つけることができる。さらに、地域で絞り込むことによって、ユーザが行くべき方角が分かる上に、そこまでの通り道の中で行きたいお店を見つけることができる。お土産屋の店内では、ユーザがお土産にスマートフォンをかざすことでお土産の詳細が表示されるため、お土産を選ぶ参考にできる。この機能を追加することで、このサービスを屋内外の両方で役立つものとすることができる。

• ツアー with ごとキャラ– 函館には様々な歴史的観光地があり、多くの観光客が訪れる一方で、観光客はその観光地に関する歴史をよく知らないことがある。

– 観光地の風景ばかり見て、そこにある歴史的展示や説明に目を向ける人は多くない。これは文章で書かれているのが問題なのではとも考えた。

– 函館に初めて訪れた観光客が五稜郭などの観光地に行く場合、降りるバス停の名前と、観光地の名前が一致していないことがあるためどこのバス停で降りればいいのかわからないことが多く、誤って観光地から観光地から離れたバス停で降りてしまって混乱する
観光客もいる。

– このサービスは、函館のご当地キャラクターが観光のガイドをしてくれるサービスである。ご当地キャラクターが AR 上で案内しながら、五稜郭の歴史や建物などについて文字と音声で説明してくれるため、文章で書かれている説明を読まない観光客も五稜郭について楽しみながら知ることができる。また、歩きながらの使用となることが考えられるので使用デバイスはスマートフォンではなく AR グラスの使用を想定している。また、観光客が行きたい観光地を設定すると、AR 上でバスの中から観光地付近の最寄り
駅やバス停でご当地キャラクターが手を振るのが見え、降りる駅やバス停がわかりやす
いように案内する機能もある。

• レーンフィッシング
– 荷物を預けた客にとって、空港内のターンテーブルで荷物を待つ時間が長く退屈である。
– 特に、函館空港は荷物が流れてくるまでとても長い時間ターンテーブルの前で待たなけ
ればならないので、函館空港を利用する客は空港側に荷物を預けたくないという意見を持つ人が一定数存在する。

– ビジネス目的で函館を訪れた函館空港の利用客は、函館に興味を持って訪れた観光客とは違い、函館の食に興味がない人が多いので空港内のお店を訪れにくい傾向がある。

– 本サービスは、空港側に荷物を預けた客が、ターンテーブル上に自分の荷物が来るまで
AR を用いたイカ釣りゲームをしながら遊ぶことができるサービスである。スマホをかざすと、A ターンテーブル上に泳いでいるイカが現れる。そして、泳いでいるイカはゲーム上の釣り竿で釣ることができると想定している。また、イカを釣りあげた際に、Group Report of 2022 SISP

-7-Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

同時に函館に関する観光情報や函館空港内のお店で使えるクーポンが付いてくることもある。さらに、イカ釣りゲームをしている最中に自分の荷物の到着に気づかないことがないように、画像認識で自分の荷物の到着を教えてくれる機能の追加も想定している。

• ゆるキャラみっけ！！
– 函館に訪れる子供連れの観光客の中で、子供の世話に時間をとられてゆっくり観光をできない親が存在する。

– 例えば、函館には現地の歴史について知ることができる史跡や博物館、函館に関する常設展示やを楽しめたり期間限定で有名作家の展覧会が楽しめたりする美術館など、多くの大人たちが楽しめる観光名所がたくさん存在するが、そのような場所で観光を楽しめ
る子供はあまり多くなく、退屈で親にかまってもらおうとする子供や、観光地で大声を出して騒ぐ子供も少なくない。

– 函館には体験型の観光スポットが少なく子供にとって函館観光が飽きやすいという背景
や、函館に存在する多くのゆるキャラの知名度があまり高くないという背景も考慮。

– このサービスは、五稜郭公園や函館美術館、公会堂などといった観光地で、子供が AR
技術を用いてゆるキャラとかくれんぼをするという内容だ。端末はスマートフォンを用
い、観光地に潜んでいる函館に由来した様々なゆるキャラを AR 技術で登場させ、隠れたゆるキャラをタップして見つける。捕まえたゆるキャラが逃げることがあるので、それを追いかけて引き続きゲームを楽しむことができる。また、歩きスマホによる事故を防止するために位置情報で歩きスマホを検知する。検知した場合は、ゆるキャラの表示を止めたり、画面に警告文を表示したりなどといった措置をとる。

• ARuku– 函館は観光地として有名な都市で、五稜郭公園や金森倉庫など様々な観光スポットがあり、主要施設や店舗、交通の多い道路も人が多く集まるそれらのスポット周辺に集中している傾向があると言える。

– 一方で、函館市内でも観光地と少し距離がある地域や、大きな道路から逸れた道などは人通りが少なくなってしまっている傾向があるとも言える。

– しかし、そのような小さな道にも喫茶店などの小さな店舗や公園など魅力的なスポットは多く存在する– このサービスは人通りの少ない道や、サービス利用者が普段歩かない道の付近を通った時に、その道に対して興味を持ってもらえるような視覚情報を、AR 技術を用いて普段見ている景色に重ねて表示し、利用者に通行を促すサービスである。利用者がこのサービスで満足度の高いと感じたスポットを発見した場合、スポットにピンを立てられるよ
うな機能も実装し、ほかの利用者の方で付近でのそのスポットを提案する視覚情報の表
示頻度をあげるなどして見つかりやすくする。また、サービスは歩きながらの利用を想定しているため、危険を避けるためにスマートフォンではなく AR グラスを用いる。

• 謎解きはジョウブツのために– 函館に住んでいる人でも自身が函館の歴史をあまり知らないことが挙げられる。
– 函館には函館の歴史を知る方法がたくさんあるが、それらの方法では函館を知りたいという強い意欲のある人でないと歴史を知るきっかけにはならないと結論付けた。

– 資料館や歴史的な事件が起こった場所には、歴史を伝えるための手段として大抵の場合

Group Report of 2022 SISP

-8-Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

文章を載せたパネルを読んでもらう形式になっているが、これでは前述した様に、興味のある人に限らずたくさんの人に函館の歴史を知ってもらうのは難しく、楽しんで歴史を学んでもらうことは難しい。

– このサービスは、謎解きで歴史を知ることができるサービスである。ユーザが函館の歴史のある場所でスマホをかざすと、その場所にゆかりのある偉人が登場する。この偉人が登場するときは、AR を使用して、その場所の背景に偉人を重ねるように登場させ、同時に景色も楽しめるようにすると想定する。そして、偉人がユーザに対して話をしてくるので、話を聞き進めていくと、歴史に準ずる事件が発生する。その事件をユーザ自身が解いていく中で、さまざまな歴史に触れて、函館の歴史のある場所を巡ってもらう
ことで、登場した偉人を成仏させることができる。
（※文責: 藤本陽人）

2.4.5

最終的なアイデアの絞り込み

中間発表後、プロジェクトで開発を行うサービスの決定を行った。最初に５人の３グループに分かれて、最終的な採用アイデアの個数と、アイデアの絞り方を考えた。グループワークの結果、採用するアイデアの個数は３個、絞り方はいいと思うアイデアに理由を添えた付箋を貼る形式で決定した。
そして投票を行い結果は以下の表 2.1 のようになった
表 2.1

それぞれのアイデアの投票数

アイデア

票数

この衣装いいでしょう。

0

たわー。

3

HAKODATE ATLAS

0

ツアー with ごとキャラ

0

レーンフィッシング

5

ゆるキャラみっけ！！

0

ARuku

4

謎解きはジョウブツのために5よって、本プロジェクトで開発を進めるサービスは「レーンフィッシング（ちょいグル）」、「ARuku」、「謎解きは成仏のために」で決定した。
（※文責: 藤本陽人）

Group Report of 2022 SISP

-9-Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

第 3 章 サービスについて
3.1

背景

函館は古くからの歴史がある建物や土地、豊かな海産物、美しい景観など観光資源が多くあり、観光地として非常に有名な都市で、五稜郭や函館駅の周辺などは全国から連日多くの観光客が訪れている。そのため観光地の周辺には飲食店など商業施設や交通量の多い道路などが集中しており、人通りが多く賑わっている傾向があると言える。
一方で大きな道から少しそれた道や住宅街の付近の道、観光地とは少し距離の離れた地域などは細い道が多く入り組んでおり、人通りが少なくなってしまっている傾向があると言える。そのような小さな道にも、魅力のある商店や公園、景観の良いスポットなどが点在しているが、人通りが少ないために認知、利用される機会も少なくなってしまっている現状が課題としてあるのではないかと感じた。
そのため、小さな道を通行する機会の少なさという課題を解決するため、利用者に普段通行しない道を提案できるサービスを提案し、目的がないと歩くことがなかった道に興味を持ってもらうことで通行するきっかけを用意し、上記のようなスポットを発見する助けとなるようなサービスを開発できないかという考えのもと、サービスを考案した。
（※文責: 齊藤優月）

3.2

目的

人通りの少なくなってしまっている道というのは、多くの通行人がその道に興味を惹かれるものがない、通る目的がないと思っているために通行する機会が少なくなってしまっているのではない
か、加えて、函館という土地に関しては行き止まりや同じ道に戻ってしまうような複雑な道が多い
ため知っている道以外を通る機会がより少なくなっているのではないかという考えのもと、普段通行しない道に興味を持って、歩いてみようと思えるような情報を提供することで、実際に歩いてもらい、今まで認知していなかったスポットを発見してもらう助けとなるサービスを開発し、発見したスポットを利用してもらうことで都市全体を活性化することを目的とした。
（※文責: 齊藤優月）

3.3

サービス概要本サービス「ARuku」は現実世界に AR 技術を用いてユーザーに情報を視覚的に表示するという形で提供し、ユーザーに歩く機会のなかった道に興味を持ってもらい、歩いてもらうことを目的としたサービスである。
本サービスは、散歩をしたい人を中心に、普段の道に飽きた人など新たな発見を求めている人をターゲットに定めた。函館には小さい道や複雑な道が多く、目的がないとそういった道を歩く機会が少なくなってしまっているため、ポイントを集めるというゲーム的要素を織り交ぜてユーザーのGroup Report of 2022 SISP

- 10 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

興味を引き、散歩中に小さい道に誘導することで、知らなかった道を歩くきっかけを作り、そこにある新たな発見に出会ってもらう機会を提供することを目的とした。
利用の際、ユーザーはアプリケーションを起動し、AR グラスに表示される周辺の地形とポイントを獲得できるオブジェクト、触れるとゲームオーバーとなるオブジェクトを参考に歩く経路を自由に決定し、ポイントを集めながら歩く。この際、オブジェクトが表示される道はユーザーの道の通行回数から決定され、この仕組みによって通行回数の少ない道を提案することが可能となっている。
本サービスは、街の路上での歩きながらの使用を想定しているため、歩きスマホによる危険を防
ぐため、スマートフォンの画面を見るのではなく、アプリケーションをビルドしたスマートフォンに接続した眼鏡型のデバイスである AR グラスを着用して使用する。
（※文責: 齊藤優月）

3.4

AR 技術を用いた理由

本プロジェクトは目的を実現するための手段を検討した結果として AR 技術を用いたのではな
く、「AR 技術でリアルなまちをハックする」というプロジェクトの名前も表しているように、AR技術を用いるという部分が目的となっている面も存在するプロジェクトである。この点も踏まえた
うえで今回 AR 技術を用いて本サービスを開発しようと考えたのは以下の理由からである。
類似した技術に、専用のゴーグル等を装着して映像を自らの動きと同期して仮想空間にあたかも自分が居るような体験を提供する VR 技術等があるが、AR 技術はすでにある実際の風景に、本来存在しないもの、ことを投影してあたかもそこにあるような体験ができる技術であるという違いがある。そこで、AR 技術でサービスを実現するにあたって価値のある体験を提供するということを考えたとき、普段の生活でよく目にする、自分の街の近所の光景と、普段の生活で毎日行う歩くという行為をカスタマイズする実在するもの、こと、としてそこに実在しないオブジェクトが表示される、という対比が価値のある体験につながるのではないか、と考えたためである。
（※文責: 齊藤優月）

3.5

利用方法

本サービスは、散歩をしたい人、普段の道を歩くのに飽きてきた人をサービスのターゲットとしている。
はじめにユーザーは、歩き始めたいと思ったタイミングで AR グラスを装着し、アプリケーショ
ンを起動する。
アプリケーションを起動すると、AR グラスの画面上には、付近のマップと、ユーザーの道の通
行回数に応じて触れるとポイントが獲得できるオブジェクトと、触れるとゲームオーバーとなる
オブジェクトが表示される。ユーザーはこれらの情報を参考に、ポイントを集めるために散歩を行う。
前述したとおり、各オブジェクトは利用するユーザーの道の通行回数に応じて表示されるため、ポイントを多く獲得するためには通行回数の少ない道、通行したことのない道に積極的に足を運ぶ必要があるため、認知していなかったスポットや、利用したことのなかった施設などを発見できるGroup Report of 2022 SISP

- 11 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

可能性が高まることが予想される。
（※文責: 齊藤優月）

3.6

機能一覧

3.6.1

スタート機能アプリケーションを開くと、AR グラスが接続されているスマートフォンにスタートボタンが表示される (図 3.1)。これを選択すると、自分の位置情報を参照して AR グラス上にオブジェクトが配置され、加えてミニマップとポイントも表示される。また、ゲームオーバー後にこのボタンを押すと、位置情報の更新とポイントのリセットが行われ、再びスタートすることができる。

図 3.1

操作画面

（※文責: 藤本陽人）

Group Report of 2022 SISP

- 12 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

3.6.2

Hacking a real city AR technology

オブジェクト表示機能

AR グラスを通して、道路の曲がり角に様々なオブジェクトを配置する。黄色いオブジェクト(図 3.2) は静的オブジェクトとして配置され、これに接触するとそのオブジェクトは消えるようになっている。敵オブジェクト (図 3.3) は黄色いオブジェクトを一定数取得すると出現し、曲がり角上を移動するように表示される。

図 3.2

ポイントオブジェクト

図 3.3

敵オブジェクト（※文責: 藤本陽人）

3.6.3

スコア表示機能取得した黄色のオブジェクトの数に応じで、得点が加算される (図 3.3)。加算数は、オブジェク
ト 1 つにつき 10 点である。その得点が、AR グラスの画面右上に表示される。敵と接触してゲー
ムオーバーとなった場合、得点は 0 にリセットされる。
（※文責: 藤本陽人）

Group Report of 2022 SISP

- 13 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

3.6.4

Hacking a real city AR technology

ミニマップ表示機能

画面の右下にミニマップが表示される。マップの画像は Google Maps Platform の Maps Static

API を用いて取得している。この API を用いることで、スマートフォンの位置情報をもとに自分の位置が中心となるような画像（sprite）が作成され、それを一定の周期で受け取ることができる。
中央にある矢印は静的オブジェクトであり、マップが回転することによって自分の向いている方向を確認することができる。また、ミニマップには矢印を除いて 2 種類のポインタが存在する。赤い十字のポインタは黄色のオブジェクトの位置を示しており、青いバツ印は敵のいる位置を表示している。
（※文責: 藤本陽人）

Group Report of 2022 SISP

- 14 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

第 4 章 開発プロセス
4.1

技術習得

4.1.1

環境準備

Slack
各メンバーとの連絡はコミュニケーションツールである Slack を用いて行った。Slack には、

Web アプリケーションとの連携や、ファイルの共有がしやすいといったメリットがある。また、毎日進捗報告を行う際にリマインダを設定し参加を促すなど、効果的に利用することができた。

Notion開発で使用するドキュメント、議事録の管理には Notion を使用した。Notion とは、メモやタス
ク管理、ドキュメント管理、データベースなど、仕事で使うさまざまなツールを 1 つにまとめたア
プリケーションである。ドキュメントの中にドキュメントを作る入れ子のような構造で管理を行う
ため、多量なドキュメントを一括で管理することができる。

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

branch の影響を受けずにファイルを編集することができる。この branch によって複数のファイル編集を 同時に行うことができる。

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

- 15 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

学習施策

4.1.2

夏季休業中に各メンバーには開発が滞りなく進行できるように、アプリケーションを開発するために必要なツールのチュートリアルを行った。また、開発に不慣れなメンバーをフォローするために、週に一回オンラインでミーティングを行う機会を設けたほか、後述するスクラムの練習としてSlack のチャンネルへ一日一回進捗報告を行うようにした。
（※文責: 佐藤有飛）

4.2

開発手法

4.2.1

導入した手法アジャイル開発
本グループでは、ソフトウェア開発の手法である、アジャイル開発を導入した。アジャイル開発
では、短い期間で計画・実装・テストを反復的に繰り返すことにより、継続的に価値のあるソフト
ウェアを提供することができる。
スクラム
アジャイル開発を導入するにあたり、アジャイル開発の手法の一つであるスクラムを採用した。

Ken Schwaber らによると、スクラムとは「複雑な問題に対応する適応型のソリューションを通じて、人々・チーム・組織が価値を生み出すための軽量級フレームワークである」と定義されている [2] スクラムでは、スクラムチームと呼ばれる、小さなチームを構成することが定められている。
スクラムチームは、プロダクトオーナー 1 人、スクラムマスター 1 人、複数人の開発チームから構成される。プロダクトオーナーとは、プロダクトの責任者であり、プロダクトの価値を最大化する責任がある。後述するプロダクトバックログの管理の責任者でもある。スクラムマスターは、スクラムというフレームワークを円滑にまわすことに責任を持つ。スクラムのルールをスクラムチームに理解させることや、スクラムチームを妨害から守ること、スクラムチームが円滑に作業を進められるよう支援するというような役割をもつ。開発チームは、プロダクトの開発を行う役割であり、
通常 3 人から 9 人までで構成される。開発チームは、機能横断的であり、プロダクトを作るために必要な作業をすべて行うことができなければならない。「コードを書く」や「UI/UX の設計を得意とする」というように、開発チームの各メンバーが所有する能力やスキルで、開発に必要なすべての作業を行うために協力し合う。また、開発チームにおける作業は、外部からの指示を受けることはなく、チーム全体が責任を持ち、主体的に行う。スクラムでは、実現したい機能を、価値やリスク、必要性などを基準に並べ替えたプロダクトバックログと呼ばれるリストを作成する。プロ
ダクトバックログ項目の作成や更新, 並び順はプロダクトオーナーが最終決定権を持つ。プロダク
トバックログの各項目は、ユーザーストーリー形式で書かれることが多い。ユーザーストーリーとは、実際に使う人たちの視点に立って、実現したいことを簡潔に記述したものである。プロダクト
バックログを作成することによって、実現すべき機能の順番が明確化する。この順番が上位の機能から開発に取り掛かることで、成果を最大化することができる。
また、スクラムでは最長 1 ヶ月までの固定の期間に区切って、開発を繰り返す。この固定の期間をスプリントと呼ぶ。この期間内に、小単位での計画・設計・実装・テストを行い、プロダクト

Group Report of 2022 SISP

- 16 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

バックログの機能を完成させる。これを繰り返すことで、段階的に、そして継続的に動くソフト
ウェアを提供し続けることができる。スプリント内で機能の実装を目指すために、スプリントプラ
ンニング・デイリースクラム・スプリントレビュー・スプリントレトロスペクティブの 4 つのスク
ラムイベントを行う。 スプリントプランニングとは、スプリントを開始するにあたって行われる、スプリントで実行する作業を計画するミーティングである。スプリントで行う作業を計画するミー
ティングである。このミーティングでは、プロダクトバックログから今スプリントの開発できそうな機能を考案し、スプリントバックログを作成する。
スプリントバックログとは、選択した実装したい機能と、そのための具体的な作業と計画のことである。
次に、デイリースクラムとは、スプリント期間中、毎日同じ場所・同じ時間で行う 15 分のミー
ティングのことである。開発メンバー全員で「昨日何をしたか」、「今日何をするか」、「困っていること」を共有し、スプリントゴールが達成できるかを確認するためのものである。また、スプリン
トレビューとは、スプリント終了時にスプリントの成果をステークホルダーに披露したり、プロダ
クトの状況や進捗を報告したりするイベントである。ステークホルダーからのフィードバックに基づき、プロダクトバックログを見直し、今後やるべきことに取り組むことができるようになる。最後に、スプリントレトロスペクティブとは、今回のスプリントにおける活動を振り返り、次回のスプリント以降のアクションプランを考えるミーティングである。うまくいったことや問題点を話し合い、もっと成果が出せるよう改善を続けることで、スクラムチームの成長が期待される。
（※文責: 佐藤有飛）

4.2.2

開発の流れ

本グループでは、スプリント期間を 1 週間として開発を行った。毎週水曜日をスプリント開始日
としてスプリントプランニングを行い、翌週水曜日にスプリント最終日としてスプリントレビューとスプリントレトロスペクティブを行った。プロダクトバックログとスプリントバックログはNotion で管理した。
スプリント期間中は、平日午後 0 時 50 分からデイリースクラムを 15 分間で実施した。デイリースクラムでは、「昨日行ったこと」、「本日行うこと」、「困っていること」を議論した。スプリント期間中の開発は、GitHub Project を用いて Issue と Pull Request を主体として管理した。メンバーはスプリントバックログの内容を Issue に登録し、GitHub Project から随時進捗を確認する。それぞれ割り当てられた部分の開発が完了したら、Pull Request を作成し 1 名以上のコード
レビューをもって取り込まれる。この流れをスプリント最終日まで継続して行った。
スプリント最終日には、スプリントレビューとスプリントレトロスペクティブを行った。
スプリントレビューでは、各メンバーが開発した機能の確認を行い、スプリントレトロスペク
ティブでは、自分達の活動内容に対して「今後も続けた方が良い施策」「続けるべきではない施策」
を軸に振り返りを行い、うまくいかなかった部分に対しては、なぜうまくいかなかったのか議論をして改善計画を立てた。
（※文責: 佐藤有飛）Group Report of 2022 SISP

- 17 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

4.2.3

Hacking a real city AR technology

効果と課題

アジャイル開発の手法であるスクラムを導入することで、メンバー間の意思疎通を図ることができ、仕様の変化に柔軟に耐えうる開発ができた。特にサーバーサイドアプリケーションでは、開発が円滑に進んだことにより、継続的インテグレーションを導入する余裕ができ、コードの品質向上を図ることができたほか、デプロイに係るコストを削減することができたため、結果として開発したサービスの品質を向上させることができたと考えている。
しかし、メンバーそれぞれのアジャイル開発に対する知識は充分とは言えない状態からのスタートだったため、プロダクトバックログの内容の不備や、スプリントレビューが実施されないなどの問題が発生した。また、タスクの負荷を見誤ることで、1 スプリントで実施する予定の量が増えてしまい特定メンバーへの負荷が集中するなどの問題が発生した。
これらの問題を回避するため、サービスの開発開始以前から勉強会などを実施し知識を蓄えるとともに、部分的にスクラムを導入してイベントの流れに慣れておくと良いと考える。
（※文責: 佐藤有飛）Group Report of 2022 SISP

- 18 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

第 5 章 システム仕様
5.1

システム構成図 5.1

システム構成イメージ図

アプリケーションは API サーバに位置情報を送信し、API サーバはデータベースを参照して提案する道の情報を送信する。
このとき、送られてきた情報をもとに提案する道を決定して AR グラス上にオブジェクトを表示する。(図 5.1)（※文責: 藤井大悟）

5.2

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

本サービスは Android スマートフォンに接続して使うことができる AR グラス、NrealLight を使うため、モバイルアプリケーションの開発をした。

NrealLight の開発用 SDK として Nreal が Unity のアセットを配布していたため開発は Unity
で行うこととした。また、AR グラス内に GPS 機能が取り付けられておらず、開発序盤に AR グ
ラスを装置中スマートフォン端末本体の GPS が取得できなくなってしまうという不具合が見られたため、別途 AndroidStudio を用いて GPS をバックグラウンドで起動、取得し保存、サーバへと送信するという Android アプリケーションの製作を行った。そしてその保存した GPS データ
を Unity 上のアプリで読み込むことにより AR グラスを使いながら GPS を使用することを可能にした。
開発言語はそれぞれ Unity で C#を、AndroidStudio で Java を使用して開発を行った。

AndroidStudio で作成したアプリの機能を以下に示す。AndroidStudio で作成したアプリではバックグラウンドで GPS を取得する機能がもともと用意してあるが、こちらは Android Developerによると「１時間当たり数回だけ」という記載があり [3]、使用用途から考えると１時間に数回は厳しいことが考えられるため、断念となった。その後、Android の機能 Foreground services を使用することによってバックグラウンド処理をしているということをユーザーが認識することがGroup Report of 2022 SISP

- 19 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

できるようにすることにより、取得上限がなくなるということがわかったためこちらを使うこととなった。Foreground services を使用して位置情報を常時監視し、位置情報が変化を検知するとonLocationChanged がコールバックされ、専用のフォーマットへと取得した GPS データを整形する。その後整形した GPS データを HTTP クライアントライブラリの Retroﬁt を使うことによって FastAPI で作成したサーバへと GPS データを json 形式で送信をした。

Unity アプリの機能を以下に示す。Unity では NRSDK for Unity という Nreal アプリを制作するために必要な Unity ライブラリを使用して AR グラス上に情報を表示していった。Unity はグ
ローバル座標での表現となり 1 の値が現実世界の 1m として表されるため、直接、緯度経度を入力することでオブジェクトを指定の位置に配置することはできない。そのため FastAPI で作成したサーバから取得した GPS を現在位置とし、さらに現在位置から一番近い曲がり角の座標を取得し、現在位置と取得した座標の差分を取ることで現在地から何 m 先に表示するかを定め、ポイント取
得オブジェクトをサーバに保存されている曲がり角の座標に配置するというプログラムを作成した。配置した曲がり角にあるポイント取得オブジェクトに直接ユーザーがぶつかることでポイントを取得することができ、ユーザーはポイントを集めながら散歩を楽しむことができる。ポイント取
得オブジェクトは新たに生成されることがないため、行ったことのない道をユーザーは通ることができその行ったことのない道にある新たなお店や風景をユーザーは見つけることができるというアプリを作成した。また、ポイント取得オブジェクトは黄色の丸の形のオブジェクトとしていたが、ここに Andtech Star Pack というオブジェクトを光らせるためのパーティクルライブラリを使用することによってポイント取得オブジェクトの高級感、どれがポイント取得オブジェクトなのかというわかりやすさを向上させた。さらに、ゲーム要素としてポイントを集める以外にも敵としてオバケのオブジェクトを用意し、行ったことのある道にオバケを配置することによって行ったことのある道へと行かないようにと誘導することも可能にした。ユーザーはオバケにぶつかってしまうとゲームオーバーとなり、それまでに集めたポイントが集計されるようにした。画面右下には現在位
置の周りの地図を配置し、ポイントオブジェクトの位置、お化けの位置を表示することによりユーザーが行ってみたら行き止まりだった、行ってみたらポイントがないところだったということがな
いようにした。
このように二つのアプリを AndroidStudio で作成したアプリをバックグラウンドで実行しながら Unity で作成したアプリを起動するということによりそれぞれのアプリがサーバを返して連携することができるというアプリの制作を行った。
（※文責: 坂田悠）

5.3

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

本サービスにおいてクライアントに API を提供するため、Python 及び Web フレームワークである FastAPI[4] を用いてサーバを開発した

FastAPI の特徴として次のような点が挙げられている。
• 少ないバグ: 開発者起因のヒューマンエラーを約 40% 削減します。
• 直感的: 素晴らしいエディタのサポートやオートコンプリート。デバッグ時間を削減します。

• 簡単: 簡単に利用、習得できるようにデザインされています。ドキュメントを読む時間を削減します。

Group Report of 2022 SISP

- 20 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology• 短い: コードの重複を最小限にしています。各パラメータからの復数の機能。少ないバグ。
また、FastAPI の GitHub リポジトリを見ると Issue 数や Star 数が多く、FastAPI の利用者数は十分におり、FastAPI に関する情報が多いと考えた。これらに加え、FastAPI は SwaggerUI と呼ばれる、作成した API をインタラクティブなドキュメントとしてレンダリングする機能がついており、作成した API について GUI ベースで直感的に動作確認ができる。
これらの点から FastAPI は開発に慣れていない人でも、簡単に開発できると考えたため、導入した。
次に本サーバの提供した API を以下に示す• GET /v1/corner– データベースに登録されている曲がり角の座標と現在地の座標を比較し、10m 以内な
ど十分に近い場合に登録された曲がり角の座標を取得する API• POST /v1/corner/passed count– データベースに登録された曲がり角の座標を引数に与え、その曲がり角の通った回数
を +1 にする API• GET /v1/corner/next– 引数に登録された曲がり角を与え、その曲がり角に隣接する曲がり角のうち、最も通った回数が少ない曲がり角を取得する API• GET /v2/corner/nearby– GET /v1/corner と同じ機能を持つ API• GET /v2/corner/Id– 曲がり角の id を与えることで、その id が示す曲がり角の情報を取得する API• GET /v2/players/id– プレイヤーの id を与えることで、その id が示すプレイヤーの情報を取得する API• POST /v2/players/id– プレイヤーの id とプレイヤーの状態（生きているか or 死んでいる, 獲得したスコア）を取得する API• POST /v2/enemies– 敵の位置を更新して取得する API• POST /v2/corner/id/got-feed– id が指す曲がり角にあるスコアをすでに取得したことを更新する API（※文責: 藤井大悟）

5.4

インフラ

本サービスの API サーバの運用のために Google Cloud Platform(GCP) を採用した。GCP[5]とは Google 社が提供するクラウドサービスの総称のことである。本サービスでは GCP のサーGroup Report of 2022 SISP

- 21 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

ビスである Google Compute Engine(GCE) と Google Kubernetes Engine(GKE) を使用した。

GKE は、自動化とスケーラビリティに優れたマネージとな

Kubernetes プラットフォームである。。GCE は Google のインフラストラクチャで仮想マシンを作成して実行できる、安全性の高い
カスタマイズ可能なコンピューティングサービスである。
これらのサービスの使い分けとしては、GKE はサービスの需要に合わせてオートスケーリングや障害時にサービスを完全に停止させずに運用できるため本番環境として、GCE は GKE に比べて費用を抑えられるため開発環境として運用した。
また、開発時のデプロイのコストを下げるために継続的インテグレーション (CI) や継続的デプ
ロイ (CD) を行った。継続的インテグレーションには GitHub Actions というツールを使用し、継続的デプロイには Argo CD や Argo CD Image Updater というツールを使用した。
（※文責: 藤井大悟）

Group Report of 2022 SISP

- 22 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

第 6 章 各メンバーの役割と活動の振り返り
6.1

役割分担

本グループでは、メンバーの得意分野に合わせてモバイルアプリケーションの開発担当とサー
バーサイドアプリケーションの開発担当、インフラ開発担当に分かれて役割分担を行った。また、本サービス開発において最終的な意思決定を行うプロダクトオーナーとチームのファシリテーショ
ンを行うスクラムマスターを一人ずつ選出した。各メンバーの担当は以下に示す。

佐藤有飛• スクラムマスター• ポスター作成
齊藤優月• サーバーサイドアプリケーション開発• プロダクトオーナー
坂田悠• モバイルアプリケーション開発
藤本陽人• モバイルアプリケーション開発
藤井大悟• サーバーサイドアプリケーション開発• インフラ開発（※文責: 佐藤有飛）

6.2

佐藤有飛の振り返り

プロジェクト学習を通じて、多くのことを学んだ。前期では、サービスを開発するまでの過程で多くの学びがあった。サービス発案では、フィールドワークから得られた課題から各自 5 個のアイデアを考えてきてプレゼンを行った。しかしながら、多くのものは AR という技術を使用する必要性が乏しく、アイデアのフィードバックを行う中でアイデア出しの難しさを感じた。プロジェクト
メンバーの中に開発経験者は多くなかったため、アイデア出しでは、自身がプロジェクトリーダーとしてある程度誘導をしながら進行していた部分があり、それによって柔軟な発想が出にくくなっていた場面があった。その状況を変えるため、場面に応じてメンバーと相談しながら進行方法を変Group Report of 2022 SISP

- 23 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

えていく方法を取ったところ、自由なアイデアがかなり出てきたため、メンバーとの情報共有や相談の大切さを学んだ。
後期では、グループリーダーとして進捗管理を主に担当した。私たちのグループでは、開発手法
としてアジャイル開発の手法の 1 つであるスクラムを導入したが、メンバーそれぞれがスクラムについて慣れているとは言い難い状況だったため、一度に導入するのではなく、段階的にレクチャーを行いながら導入することで、スクラムを運用することができた。しかし、成果発表会の直前では開発の遅れから一部スクラムの手法から逸脱してしまうような場面があり、メンバーに混乱が生じてしまうことがあった。この他にも開発の過程では、様々な問題が生じたが、そのたびにメンバー間で話し合いを行うことで解決していくことができたのは非常に貴重な経験であったと考えている。
成果発表では、デモを交えることで私達のサービスに対する理解度を上げることが出来たと思う。しかし、ブースの運営方法であったり人の誘導に関して不満が残る結果となった。これらの問
題点については、事前にオペレーションを組むことで解決できる部分だと思うので今後に活かして生きた。また、デモによってサービスそのものを体験してもらうことはできたが、サービスが開発された背景・課題についてはあまり共有できなかったと感じた。これらについても、発表の形態を工夫することで改善できる部分であると考えている。
私は、今回のプロジェクト学習を通じて、メンバーとの対話・開発手法についての知見・事前の計画の重要さを学ぶことが出来た。上記で述べた反省点を元に今後の活動に取り組んでいきたい。
（※文責: 佐藤有飛）

6.3

齊藤優月の振り返り

私は今回プロジェクト学習で、「函館補完計画：序 〜 AR 技術でリアルなまちをハックする」に携わってサービス開発を行なったことを振り返って、慣れない難しいことも多かったが、とても多くのことを学べて、今後に活きる良い経験になったと感じた。
前期の活動では、函館の抱えている課題を発見し、AR を用いてどのように解決するか、ということを議論してサービス案を絞っていく活動が主であった。私たちのプロジェクトは、「AR 技術
を課題解決の手段として選択した」のではなく、「AR 技術で課題を解決する」ということを目的としていたプロジェクトであったため、議論の進め方や考え方に難しい点が多かったように思う。
だがこの活動によって様々な観点から課題を検討する力を身につけることが出来た。また、多くの意見から案を絞っていく議論の過程で、特定のテーマからアイデアを発散させ広げていく方法、広がったアイデアを分類し、有用な情報を抽出する方法、それらのアイデアをまとまったものに収束させる方法など、様々な手法に触れ、知ることが出来たことも、例えば今後の研究などで参考にできる良い経験だったと感じた。
後期からは開発が本格的に始まり、サーバーサイドのアプリケーション開発という役割でグループに携わった。今まで触れた事のない技術に触れ、知識を広めたいという思いからサーバーサイドの開発を希望した。サーバーサイドは全くの未経験で知識も皆無の状態からスタートし、ツールやCUI の使い方など手探りで調べ、学びながら使う、書くという経験は自ら学ぶ力を得るとても良い経験に感じた。しかし、しばしば行き詰った場合の対処が上手くいかなかったり、見通しが甘く思うような進捗を上げられない場面も目立ってしまう点が振り返ると多くあったため、大きな反省点であり、改善すべき点であると感じた。

Group Report of 2022 SISP

- 24 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

開発手法に関しては、本グループはアジャイル開発を取り入れており、一週間程度のスプリント
期間を設け、繰り返すことで開発を進めていったが、結果としては思うように上手くいかなかった
点が多かったように感じた。予定通りに開発が進まなかったスプリントも多く、各スプリントごとにテストを行い、終了時には動くものがある、という状態に関してはほぼ出来ていなかった。私自身も本格的なサービス開発は初めての経験であり、完成までの見通しやタスクを設定するときの粒度、工数の見積もりなどが上手くいかなかったと感じている。だがこの経験から自らのこなせるタ
スクの量や見通しなどを知ることが出来たので、今後の開発や研究などの活動では活かしていきたい。
中間、期末の成果発表会では、私たちのサービスに関して伝えたいことを伝えるということは概ねできたと思う。しかし期末の成果発表会では実機でのデモを用意して体験してもらうブースも用意しており、そちらの方に時間を多く使ってしまったため、サービスそのものを体験してもらうことは出来たものの、なぜ考案されたのか、どういう課題を解決することが目的なのかについては説明が疎かになってしまっていたため、タイムスケジュールやオペレーションの見直しが必要だと感じた。また、細かな発表技術に関してもポスターの方ばかり見てしまった、担当した部分以外だと曖昧な点も多かったなど改善点も多く残っていたため、今後の外部発表の際は改善できるよう努めたい。
私は今回のプロジェクト学習で、アイデアの広げ方・まとめ方、自ら学ぶ力、見通し・計画の立て方、チームによる開発の手法など様々な力を得ることが出来た。これらの力や上記で述べたような反省点、改善点を活かして今後の活動に取り組んでいきたい。
（※文責: 齊藤優月）

6.4

坂田悠の振り返り

私がプロジェクト学習で「函館補完計画：序 〜 AR 技術でリアルなまちをハックする」に、その中の「ARuku」というサービスの開発に携わった理由は二つある。
一つ目は私は以前高校の頃に AR を用いたマーカー型のアプリ製作に携わったことがあった。その知識を生かして、また、さらにその時に作ったアプリケーションより、良いものを作れるのではないかと考えたからである。実際に開発を進めていく中で以前に使った AR で表示したオブジェ
クトの当たり判定を使った動作や、AR で表示したオブジェクトにボタンを追加し、そのボタンを押せるようにするというプログラムを作成する場面があり、この以前 AR を作成する際に使っていた知識は役に立ったといえる。
二つ目は以前はマーカー型を使用したが Aruku というサービスは AR グラスを用いたものであるため、新たな技術取得ができると考えたからである。AR という点で活用できる知識もあるが、その中に AR グラスという新たな内容が入ることで新しい技術取得をすることができると考えた。以上二つが私が本プロジェクトを選び、またこの 1 年間の活動でもっとも意識してきた内容である。
前期の活動は主に函館に隠れている問題を発見し、問題について AR を用いたサービスの考案をすることであった。問題発見のために本プロジェクトで最初に行なった活動はフィールドワークであったがフィールドワーク自体で隠れた問題を発見することは大変困難であり、その後の意見交換や付箋を使って大まかな分類に分けていくなどの分析によって初めて問題が明確になるということがわかった。サービス考案に関しては多種多様なアイデアを提案することができた。しかし函館にGroup Report of 2022 SISP

- 25 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

根ざしたサービスや将来性を考え長期的にユーザが使ってくれるというような条件にあてはめてい
くと、ほとんどのアイデアは価値を説明しきれなかった。その後 8 つのアイデアに絞り、中間発表を見に来てくれた人にいいと思ったアイデアを投票してもらった。
後期の活動は 8 つのアイデアの中から中間発表で投票してもらった投票数や、プロジェクトメン
バー内で相談を進め、サービスを 3 つに絞り、それぞれプロジェクトの中で 5 人ずつにわかれ、主にサービスの開発を進めていった。開発ではプロジェクトリーダーの佐藤の提案で Aruku ではス
クラムな開発を採用し、1 週間を 1 スプリントとして開発を進めた。開発の初期では AR グラスという初めて使うものに苦戦しつつ、案通りに作ることができず Android アプリを AndroiddStudioと Unity の 2 つを作成することにし、それらをバックグラウンドで処理することにより、改善をしたりするなど柔軟な対応ができたといえる。また、チームでの開発の経験がなかったため最初のうちは github などの使い方がおぼつかない部分があった。
後半の開発では github を積極的に活用し、コミュケーションをグループメンバーと積極的にとることで円滑に作業を進めていき、役割をそれぞれ分担しながら作業を効率的に行うことができた。後半の開発の中でも様々な進路変更はあったといえるが円滑なコミュケーションのおかげで流れよく作業を進めることができた。
スクラムに関しては前半ではスクラム開発がメンバー全員が初めてということもあり、スプリン
トゴールの内容が重すぎたものや内容が抽象的すぎて複数の内容がふくまれていたものなどがあったため 1 スプリント内でスプリントゴールを達成することができないことが多々あったが、後半に行くにつれ、慣れもあってかこの内容ならどのくらいの期間がかかる、さらに細かいゴールを立てるなど 1 スプリントで達成することができるスプリントゴールを作成することができるようになっていった。
成果発表会をはじめとした様々な発表会ではポスターと実機での説明を主とした内容だった。実機での実演をしたためアプリケーションの使用方法や使用した際のイメージは発表に来た人にとって容易であったが、ポスター側の説明がおろそかになってしまい、なぜ函館でこのサービスを活用できると思ったかなどのなぜこのアプリになったのかという点を説明があまり詳しくできなかったのが課題として残った。今回のプロジェクト学習で問題発見、サービス考案の力、開発力向上、
チーム開発における様々なノウハウを学習することができた。また反省点を生かし今後の活動に取り組んでいきたい。
（※文責: 坂田悠）

6.5

藤本陽人の振り返り

私がこのプロジェクトへの参加を希望した理由は、このプロジェクトの目的である AR 技術を用いてプロダクトを製作し、それをもって函館市の問題解決につなげるという点に魅力を感じたからである。また、私自身函館に 10 年近く住んでいるので、すでに持っている函館に関する知識や感じている問題点があり、これを共有することでプロジェクトに貢献できると考えたのも理由の一つである。
前期の活動内容は、フィールドワークで函館の問題点を探し、それらを踏まえてプロダクトやサービスのアイデアを考案することが主だった。フィールドワークでは、事前に行われた講習会で学んだ着眼点や、注意点に気を付けながら調査を行った。結果、今まで気づかなかった発見や問題点を探し出すことができた。しかし、発見した問題点を解決するためのサービスを考案するのにはGroup Report of 2022 SISP

- 26 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

時間がかかった。その理由は 2 つある。1 つは、問題解決につながっているアイデアを考えることが難しかったからである。2 つめは、新しい体験ができる、函館らしさがある、AR らしさがある、危険でない、これらすべての要件を満たしたアイデアが少なかったからである。これらの要件を満たし、且つプロジェクトメンバーが納得するようなアイデアを考案するためにたくさんのグループ
ワークを行い、最終的に 8 つのアイデアまで絞ることができた。そこからは、中間発表での評価と、プロジェクトメンバーそれぞれが開発に取り組みたいと思うサービスを基準として、現在の 3
つのサービスに決定した。ここで、私は「ARuku」の開発メンバーとして製作に取り組むことが決定した。私がこのサービスの開発に携わりたいと考えた理由は、今まで使用したことのないデバイスを使って開発に挑戦したいと考えたからである。ARuku は、函館市内での散歩をより楽しくするという目的をもって考案されたので、安全性を考慮して当初から AR グラスを用いて開発をすると決まっていた。私はそこに魅力を感じたため、このサービスの開発に携わろうと決めた。前期の活動はここまでである。
夏季休業期間中は、技術検証を主な活動としていた。私はフロントエンドとして活動していたので AR グラスの検証がほとんどだった。私たちが使用した Nreal Light という AR グラスは日本
での開発事例が非常に少なく、開発方法を理解するのに時間がかかった。しかし、夏休み中には任意のオブジェクトを AR グラスに移すという段階までは達成していた。
後期からは本格的にプロダクトの製作に取り掛かっていった。私たちのグループでは、スクラム開発を導入して製作に取り組んだ。その理由は、スクラム開発は、常に他人と作業の進捗を共有できるという点がこのプロダクトを製作するうえで非常に有用だと判断されたからである。デイリー
スクラムへの参加頻度低下や、スプリントの管理などでうまくいかなかったことも多かったが、私の中ではこの経験は非常に良いものとなった。後期になってからも、AR グラスを使った開発ではトラブルが頻発した。一番大変だったのは、スマートフォンからとった位置情報が AR グラスに反映されないと分かった時だ。このサービス開発において位置情報を使えないことはあまりにも致命的なので、この事実が判明してからバックエンドも交えて大幅なフローの見直しが行われた。また、フロントエンドで作ったプロダクトとバックエンドが作ったサーバーとの通信を実装するのにも多くの時間を要した。その結果、成果発表までには目標とするプロダクトを完成させることはできなかった。成果発表後の反省で、開発においての反省点が多く出されたのでそこに気を付けながらこれから続きの開発を行っていくつもりである。成果発表では、前述したとおり目標としたプロダクトができなかったため、デモを製作し展示した。内容の評価は、なぜこれが函館でしかできないのかという点がいまいち伝わらなかったという指摘がいくつかあったが、それ以外の評価はよかった。発表形式ではポスター紹介からデモの体験へうまく人を流せなかったので、デモの評価はよかったものの多くの人に体験してもらうことができなかったという点が反省点として挙げられた。
最後に、私はこの 10 カ月近く行われたプロジェクト学習で多くのことを学び、多くのいい経験をした。特に、自分は今までハッカソンなどへの出場経験がなくチーム開発を行ったことがなかったので、スクラム型開発でプロダクトを製作できたことが非常に良い経験となった。このプロジェ
クトで学んだことや反省点は、これからの大学生生活やその先の活動でも生かせるようにしたい。
（※文責: 藤本陽人）

Group Report of 2022 SISP

- 27 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

6.6

Hacking a real city AR technology

藤井大悟の振り返り

私はプロジェクト学習で多くのことを学んだ。
まず、プロジェクトの立ち上げから開発までを学んだ。前期では、函館のまちを AR 技術を使ってより良くするをテーマにアイデア出しをした。アイデアを出す過程でフィールドワークを行い、函館のまちを観察したり、函館の企業や住民にヒアリングをしたりした。また、アイデアをそれぞれ 5 つほど出し、それを話し合いなどで 3 つまで絞る過程でもメンバー同士で時間をかけて議論し、それぞれが納得するアイデアを絞り込んだ。
後期は開発に取り掛かった。開発では私はバックエンドアプリケーション開発を行うチームに所属した。バックエンドアプリケーション開発チームでは、主に私が技術面でのリードを行い、基本設計や詳細設計を担当したり、タスクを適切な粒度に分けてメンバーに割り振ったりした。
また、私はプロジェクト学習で多くの学びが得られるように取り組んだ。技術面での取り組みとしては、アーキテクチャやディレクトリ構成などはできるだけ公式の情報や信頼できる情報元を参考にし、ベストプラクティスがあればそれに従うよう努めた。
また、変数名などは他の人が見て何をしているかわかりやすいように名付けた。
他にも開発の進め方としてアジャイル開発やその手法のひとつであるスクラムにも取り組んだ。
スクラムはチームと共同で迅速な開発を行うソフトウェア開発フレームワークで、1〜２週間程度の短い時間単位でサイクルを回し開発を行う。これによって、開発についてのフィードバックを定期的に行うことで柔軟に開発を進めることができた。一方でスクラムについてはうまく行かなかった面も多くある。スクラムを初めたころは、問題なく進んでいたが、後半になるにつれてタスクをうまく回すことができなくなった。これについては、タスクの分割がうまく行かなかった、またそれについてのフィードバックをきちんとできていなかったことが原因としてあげられる。今後スクラムをする機会があれば、今回の失敗点を踏まえてよりよいスクラムを行いたい。
また、開発体験の向上を目指して Argo CD という Kubernetes 用の宣言型 GitOps 継続的デリバリーツールを導入した。Argo CD によって、デプロイの自動化が可能となり、私達は開発に集中することができた。Argo CD の導入は技術的に難しかったが、その分学びがあった。例えば

Kubernetes についての知識を得たり、ドキュメントの読み方についての知見を得たりした。
この用に私はプロジェクト学習から多くの学びが得られて、大変よい経験を得られた。
（※文責: 藤井大悟）

Group Report of 2022 SISP

- 28 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

第 7 章 成果発表
7.1

発表形式

中間発表同様 3 階の教室前で発表を行った。また、中間発表とは違い３階の教室内も発表場所とすることで、より広いスペースを確保することができた。
始めに本プロジェクトの概要や各アイデアのおおまかな説明を行うためメインポスター、スライドを使用して 5 分間で説明した。その後、ARuku、ちょいぐる、なぞときはジョウブツのあとでの 3 サービスから興味を持っていただいたものを選んでいただき質疑応答を含めそれぞれのグルー
プのブースで合計 10 分間で発表を行なった。中間発表ではサービス案の紹介、気になったサービスへの投票としていたため、6 分間ですべてのポスターを回る形としていたが、成果発表会ではサービス紹介から製作物の紹介までを行なったのち気になったサービスを選んでいただき、発表時
間を 10 分とすることでデモをする時間の確保や細かい説明までを来てくれた人に聞いてもらうことができるようになった。
プロジェクト全体の展示として全体ポスター 1 枚、本プロジェクトで考案したサービスの展示として、本グループでは開発したアプリケーションに関する内容をまとめた簡易ポスターを教室外に展示した。また、教室内にはデモプレイができる展示として、デモプレイ専用のアプリを入れた

Android 端末と NrealLight をそれぞれ２台ずつ、配置をした。
（※文責: 坂田悠）

7.2

レビュー内容7.2.1

発表形式の評価と反省

発表技術に関して、高評価な意見として• デモが体験しやすい形で発表が行われていた• デモを体験をすることでただ説明されるよりも作品のことが分かったなどが得られ、デモの環境を用意したことが効果的に働き、発表を聞きに来た人により良い理解を与えることができたと言える。低評価な意見としては• デモを動かす人と話者をわけたほうが良い。
という意見が得られた。デモを用意するということはよかったといえるものの、今回の発表ではポスター担当として 1 人、デモ担当として 1 人を常駐させており、想像以上にデモを体験したいと言ってくれる人が多かったため、デモ担当が 1 人で、1 人にデモを触ってもらいながら待ちの人 1
人に説明をするというようなタイミングなどがあった。ポスター側に人がおらず、ポスターの説明がない間はデモを手伝ってもらい、待ちの人たちへ説明をするなどの工夫をすることができればこのようなことは起こらなかったのではないかと考えられる。

Group Report of 2022 SISP

- 29 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology（※文責: 坂田悠）

7.2.2

発表内容の評価と反省

発表内容に関して、高評価な意見として• 散歩で使ってみたい• どうしてこのサービスになったかがわかりやすい• 実際に触れて見ることができて面白かった• プロセスがわかりやすかったなどが得られた。従って、発表を見に来た人達にとって本アプリケーションの評価は高いと言え、実際に使ってみたいというユーザーも多くみられたといえる。低評価な意見としては• もっと函館でしかできない理由をアピールしたほうが良い• 実装がまだまだなどが得られた。平均評価は 10 点中、8。38 点で、函館でしかできないという点が上手く伝わっていなかったので、ポスターだけではなくデモでも説明する必要があったなど様々な工夫の方法が考えられるとともに、明確に分かりやすく伝えるべきであったといえる。「実装がまだまだ」という意見については、今後も開発を重ねていき、改善に努めていきたいと考える。
（※文責: 坂田悠）

Group Report of 2022 SISP

- 30 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

第 8 章 まとめ8.1

前期の振り返り

前期では、AR 技術についての学習、プロジェクトロゴの作成、アジャイルワークショップへの参加、AR 技術でカスタマイズする函館という都市が抱えている課題の発見、それらの課題を解決するためのサービス考案という 5 つの活動を行っていた。

AR 技術についての学習では、AR 技術とはどういうものかについて、類似する VR 技術等との違いを中心に学んでから、既存する AR 技術が用いられているアプリケーションの事例を多数挙げ、一部実際に使用してみながら、AR 技術が用いられている理由、目的、利点で分類分けし、これから AR 技術を用いて課題解決するにあたって、その解決手法や方法についてのイメージをプロ
ジェクト全体で共有した。
プロジェクトロゴ作成は、今年度から新たに始まる本プロジェクト、「函館補完計画：序 〜 AR
技術でリアルなまちをハックする」を象徴し、過去のプロジェクトとの差別化を明確にするために行った。作成手順はプロジェクトメンバー全員で原案を持ち寄り、配色や形状の意図などを全員で共有し、レビューとブラッシュアップを複数回繰り返した上でメンバー全員の投票から原案を決定した。その後、決定した原案を有志メンバーで調整し、現在のプロジェクトロゴが完成した。
本プロジェクトでは、サービスの開発手法として、アジャイル開発を行うことをアジャイルワー
クショップへは、本プロジェクトは zoom を用いたオンラインの形式で参加した。本講座では、株式会社アトラクタ様の永瀬美穂氏より、アジャイル開発について、その性質、他の開発手法との違いや具体的な手法、メリット、デメリットなどを学んだ。アジャイル開発については、本報告書第4 章の開発手法の項で述べられているのでここでは省略する。
函館という都市が抱えている課題の発見については、主に複数回にわたるフィールドワークの活動を通して行った。まず、アドバイザーの南部先生によるフィールドワーク講座を受講し、街に出てのフィールドワーク、インタビューを行う際の心構え、注意点、見るべきポイントなどをお話しいただき、学習した。その後、プロジェクトメンバーを 5 グループに分け、五稜郭地区、湯の川地
区、赤川・美原地区、十字街・谷地頭地区、函館駅西部地区をそれぞれ訪れ、訪問中は Slack に専用のチャンネルを設けて写真や感じたことを細かに共有した。フィールドワーク終了後はまず各グループごとにオンラインホワイトボードサービスの Miro を用いて気づいた点や、AR 技術で実装が期待できる案などを書き出した。その後、全体で結果の共有を行い、集めた情報を観光などのジャンルに分け整理する活動を行った。
サービスの考案は、全体で共有したフィールドワークの結果を踏まえて、発見した課題を AR 技術を用いて解決出来るようなアイデアを各自 5 つ程度持ち寄り、レビューとブラッシュアップを繰
り返し、評価観点として「AR ならではの体験であるか」「函館という土地でしかできないか」「実現可能かどうか」「新しい体験か」「課題を解決する意義があるか」という 5 つの項目に重みをつけて評価、検討して 8 つのアイデアに絞り込み、中間発表会でサービス案として発表した。
中間発表会ではプロジェクト全体のポスター、絞り込んだ 8 つのアイデアそれぞれについてのポスターを展示して発表した。発表を聞きに来てくれた方にもサービスの評価を頂き、今後のアイデアの最終選考時に参考にして検討していくこととした。また、サービス内容に関する質問、意見はGroup Report of 2022 SISP

- 31 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

開発時に取り入れることとした。
（※文責: 齊藤優月）

8.2

後期の振り返り後期では、まず初めに中間発表会時点で絞り込んでいた 8 つのアイデアから、開発するサービスを選定するところから始めた。中間発表会で頂いた評価やご意見なども参考に、前期の振り返りでも述べたような評価観点に当てはまるかどうかを再度検討し、サービス案を 3 つまで絞り込み、開発することが決定した。その後、メンバーを各サービス 5 人ずつのグループに分割した。本グルー
プはそのうちのひとつである AR 技術を用いて散歩を支援するサービス、「ARuku」を開発するグ
ループとなった。
本グループでは、アジャイル開発を行うため、グループからスクラムマスター、プロダクトオー
ナーを一名ずつ選出し、サーバーサイドアプリケーション担当、モバイルアプリケーション担当、
インフラ担当と役割分担をし、スプリント期間とデイリースクラムの行い方を設定し、開発を開始した。
開発中には、権限の関係によって、AR グラスから接続したスマートフォンの位置情報を取得することが、機種によっては出来ないという問題に直面した。今回開発するサービスは、ユーザーの位置情報をベースに道の提案を行うものであるため、位置情報の取得は必須で、スマートフォンの位置情報を取得することを想定していた。これを解決するために、モバイルアプリケーション担当
は、AR グラスで動作するアプリケーションとは別に、バックグラウンドで動作し続け、位置情報をサーバーに送信するアプリケーションを開発し、サーバーサイドでは、受け取った位置情報
を AR グラスで動作するアプリケーションに返す機能を追加することで位置情報の取得を可能にした。
また、開発手法の面では、毎スプリントの終わりにスプリントレトロスペクティブという振り替りの時間を設けることで、スプリント期間やタスク量の検討、調整を行い、開発体制を改善するように務めた。
成果発表会では、展示の教室を、想定される利用シーンである街の道路、曲がり角に見立てたデモを作成し、ポスターによる説明の後に実際に AR グラスを装着してサービスを体験してもらうという形で発表することができた。
（※文責: 齊藤優月）

8.3

今後の展望

まず、本グループは 2 月 14 日に行われる秋葉原での成果発表会および 3 月 20 日に名古屋で行
われる Agile PBL 祭りに出展を予定しているため、そこに向けた発表手法の見直しやサービスのブラッシュアップを行っていきたいと考えている。
現在、開発したサービスが抱えている課題も何点か残っている。まず、モバイルアプリケーショ
ンとサーバーの通信に不具合が残っている点である。これによってサーバーとモバイルアプリケー
ション間の通信の遅延や実地でのオブジェクトとの接触判定の検証などが十分に進められていないという現状もあるので、安定した通信の確立は、課題の中でも重要度の高いものであると考えていGroup Report of 2022 SISP

- 32 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

Hacking a real city AR technology

る。機能の面では、画面構成、UI のブラッシュアップ、単独ユーザーのみではなく複数のユーザーでの利用を想定した機能の設計、マップのピン機能、表示するオブジェクトの多様化など、実装することで、ユーザーの体験を向上できる可能性のある案がいくつか考案されていたため、それらの検討も今後の展望として挙げられる。
（※文責: 齊藤優月）Group Report of 2022 SISP

- 33 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

付録 A

Hacking a real city AR technology

成果発表会で使用したメインポスター

図 A.1

Group Report of 2022 SISP

メインポスター (成果発表会)- 34 -

Group Number 17-A

Hakodate Complementary Plan: 1.0

付録 B

Hacking a real city AR technology

サービス説明用ポスター

図 B.1

Group Report of 2022 SISP

サービス説明用ポスター (成果発表会)- 35 -

Group Number 17-A

参考文献
[1] abridge. AR とは何？ . URL:https://www.abridge-lab.com/portforio sub1.html,(2023 年 1 月 18 日 閲覧)[2] Ken Schwaber, Jeﬀ Sutherland. スクラムガイド.URL:https://scrumguides.org/docs/
scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf,(2023 年 1 月 18 日 閲覧)[3] バックグラウンドでの位置情報へのアクセス. URL:https://developer.android.com/training/location/background?hl=ja,(2023 年 1 月 18 日 閲覧)[4] FastAPI Documentation. URL:https://fastapi.tiangolo.com,(2023 年 1 月 18 日 閲覧)[5] Google Cloud のドキュメント. URL:https://cloud.google.com/docs,(2023 年 1 月 18 日 閲覧)- 36 -