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

プロジェクト名
函館補完計画：破Project Name
Hakodate Complementary Plan: 2.0

グループ名
消火栓みてみま SHOW か！？

Group NameGroup C
プロジェクト番号/Project No.

8-C

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

グループリーダ/Group Leader
酒井佑馬

Yuma Sakai

グループメンバ/Group Member
酒井佑馬

Yuma Sakai

朝日夏々

Nana Asahi

川田隼大

Hayata Kawata

堀岡璃久

Riku Horioka

八幡瑠樹

Ruki Yahata

指導教員
松原克弥

鈴木昭二

奥野拓

Advisor
Katsuya Matsubara Sho’ji Suzuki Taku Okuno

提出日2024 年 1 月 17 日

Date of Submission
January 17, 2024

概要
本プロジェクトは，AR 技術を用いて函館のまちにあるモノ・コト・トキをカスタマイズする
ことで，新たな体験や価値を創造することを目的とする．現実の函館のまちに対し，新たな価値を見出すことを主眼に置く．サービスの考案を行うに当たり，フィールドワークを行い，函館に存在する課題を洗い出した．本グループでは，「函館の観光地が集中している」，「地上式消火栓が函館などの積雪地帯に多く存在すること」に着目し，「消火栓見てみま SHOW か！？」というサービスを制作した．
キーワード

AR, XR（※文責: 朝日夏々）-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. To focus on discover
new value for the real city of Hakodate. In order to propose the service, ﬁeldwork was
conducted in city of Hakodate to indentify the city s issues. Our group pay attention
to Concentration of tourist spots in Hakodate , There are many Surface type ﬁrehydrants in such city of Hakodate as”, and create ”Let’s Show a Shokasen”.
KeywordAR, XR（※文責: 朝日夏々）- ii -

目次
第1章

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

1

1.1

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

1

1.2

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

1

1.3

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

1

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

2

2.1

ロゴ制作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.2

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

2

2.2.1

アジャイルワークショップ . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.2.2

Git・GitHub ハンズオン . . . . . . . . . . . . . . . . . . . . . . . . . .

3

第2章

2.3

第3章

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

3

2.3.1

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

3

2.3.2

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

3

2.3.3

フィールドワークの実施 . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3.4

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

4

2.3.5

知識の獲得 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.3.6

各自アイデア出し，フィードバック . . . . . . . . . . . . . . . . . . . . .

5

2.3.7

アイデアの評価基準の設定 . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.3.8

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

5提供するサービスについて

7

3.1

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

7

3.2

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

7

3.3

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

7

3.4

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

8

3.5

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

8

3.6

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

8

3.7

消火栓について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.7.1
第4章

世間からの反応. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

開発プロセス15

4.1

開発ツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

4.2

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

18

4.3

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

18

4.3.1

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

18

4.3.2

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

20

4.3.3

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

20

第5章

サービスの開発

22- iii -

5.1

5.2

第6章

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

22

5.1.1

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

22

5.1.2

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

22

各種 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

5.2.1

23

Vuforia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

各メンバーの振り返り

24

6.1

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

24

6.2

酒井佑馬の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

6.3

朝日夏々の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

6.4

川田隼大の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

6.5

堀岡璃久の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

6.6

八幡瑠樹の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

成果報告会

31

7.1

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

31

7.2

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

31

7.2.1

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

31

7.2.2

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

31

第7章

第8章

まとめ

33

8.1

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

33

8.2

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

34

8.3

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

35

付録 A

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

36

付録 B

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

37

参考文献

38

- iv -

Hakodate Complementary Plan: 2.0

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

背景

AR (Augmented Reality) 技術は，「ポケモン GO」への採用で爆発的に知名度が上昇した．最近は，VR (Virtual Reality) やメタバースなどの現実世界とは異なる仮想空間を 3DCG で実現する技術が注目されているが，実際に暮らしているリアルな世界をデジタル空間とつなぐことができる AR 技術には，VR とは異なる独特のオモシロさがある．
（※文責: 武藤恵理也）

1.2

目的

本プロジェクトの目的は，函館のまちにあるモノ・コト・トキを AR 技術でカスタマイズすることで，新たな体験・価値を創造するサービスの考案と開発を行うことである．さらに，企業や函館市の協力により，開発したサービスを函館のまちで実際に評価することを目指す．
（※文責: 武藤恵理也）

1.3

AR について

拡張現実感（Augmented Reality：以下，AR）とは，現実の世界に CG (Computer Graphics)
によって描かれる物体を重畳表示する技術である [?]．また，AR は複合現実感（Mixed Reality：
以下，MR）の分類の 1 つである [?]．MR の図を図 1.1 に示す．左へ行くほど現実の様相へ近づ
き，右へ行くほど仮想の様相へ近づく．AR は現実よりの中間という位置に定義づけられている．

図 1.1 Realit-virtuality continuum（※文責: 武藤恵理也）

Group Report of 2023 SISP

-1-Group Number 8-C

Hakodate Complementary Plan: 2.0

第2章
2.1

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

ロゴ制作

本プロジェクトでは，プロジェクトの特徴やイメージを表現するとともに，メンバー全員の一体感を生むために，今年度のプロジェクトのロゴを制作した．
はじめに，プロジェクトメンバー全員がロゴ案を 1 つ以上考案してロゴの発表会を行い，それぞれの案についてレビューを行った．1 回目のレビュー方法は，それぞれの案の良いところだけを伝える形式をとった．2 回目に，レビューや他のプロジェクトメンバーのロゴデザインを参考に，各
自新たなロゴ案を考案し，発表会を行った．この発表会のレビューでは，まず 1 回目と同じ形式でのレビューを行い，その後 3 つのグループに分かれて，これまでのロゴ案を参考にロゴの方針を話し合った．その後，3 名の希望者によるロゴチームを結成し，良いロゴ案の絞り込みと，各自新しいロゴデザインの考案を行った．1 ヶ月後，プロジェクトメンバーによる投票を行い，ロゴ案の決定に至った．その後，さらに 1 週間かけて考案者とロゴチームメンバーがデザイン原案の改善をプ
ロジェクトメンバーの意見をもとに行い，ロゴデザインの最終版を制作した．
今年度のロゴ (図 2.1) は，本プロジェクトで使用する「AR」技術，函館をイメージした浮いている箱の形に「AR」の文字を組み込み，赤色と黄色を用いることで，希望やエネルギッシュさを持ち合わせたデザインである．箱の中に「AR」の文字があることで，箱を補完するということを表している．

図 2.1

プロジェクトロゴ（※文責: 朝日夏々）

2.2

勉強会

2.2.1

アジャイルワークショップ

アジャイル開発とは，ソフトウェア開発プロセスの一種である．アジャイル開発では，要求や解決策が変化しうる環境で，短い期間で反復的に開発を進める．これからアジャイル開発をプロジェ

Group Report of 2023 SISP

-2-Group Number 8-C

Hakodate Complementary Plan: 2.0
クト学習に取り入れるため，株式会社アトラクタの永瀬美穂氏によるアジャイルワークショップに参加した．事前にビデオ教材にて「アジャイル開発概論」を学習し，ワークショップにてアジャイ
ル開発について具体的なシチュエーションをもとに学習した．最後にいくつかのチームに分かれて，アジャイル開発についてのクイズに回答し，ワークショップの内容の理解を深めた．
（※文責: 小黒皓太）

2.2.2

Git・GitHub ハンズオン

次に GitHub 講習会を行なった．Git とはソースコードやファイルの変更履歴を管理するためのツールであり，GitHub とは Git をベースとしたウェブ上でソースコードを管理するためのプラッ
トフォームである．この講習会では Git を自身の PC にインストールし，環境構築を行なった．そして Git の一般的なコマンドを理解し，GitHub の簡単な操作を学んだ．
（※文責: 小黒皓太）

2.3

フィールドワーク

2.3.1

事前調査

函館の街やその周辺に存在する問題や課題を調査することを目的としてフィールドワークを行った．「西部地区」「五稜郭」「湯の川」の 3 つの地域に分かれてフィールドワークを行うことをメン
バー間の話し合いのもと決定した．そして，各地域に行くための 3〜4 人 1 組のグループ編成を行った．なお，西部地区のみ，調査範囲が広いため 2 グループが行くこととした．フィールドワー
クを行うにあたり，対象の地域にまつわる歴史・名所などを調べ，理解を深めた．また，各グルー
プごとにタイムスケジュールを組み，それに従いフィールドワークを行った．
（※文責: 櫛引萌々子）

2.3.2

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

フィールドワークの実施にあたって，南部美砂子先生，元木環先生によるフィールドワークについてのレクチャーを受けた．
南部先生からは，まず，フィールドワークとは何かということを学んだ．これにより，フィール
ドワークとはその土地の社会や文化を知る一つの方法であり，得た情報をこまめにまとめ，他人やフィールドワークを行った地域に共有することが大事だと確認することができた．
次に調査者としての態度を学んだ．フィールドワークを行う際には，効率的に答えを知りたいという考えを手放すことと，デザインや提案や成果物をゴールにせず，発見のプロセスに集中するということがわかった．
元木先生からは，様々なフィールドワークの事例から気をつけておくべき点について学んだ．例
えば，街に出るときには「未来大」というブランドを背負っていることや自分との接点を探すということが挙げられた．
（※文責: 櫛引萌々子）

Group Report of 2023 SISP

-3-Group Number 8-C

Hakodate Complementary Plan: 2.0

2.3.3

フィールドワークの実施

レクチャー後，絞った 3 つの地域，3〜4 人のグループに分かれた．6 月 7 日にすべてのグループが実施，6 月 8 日は，湯の川を担当するグループ，6 月 11 日は西部地区を担当する 1 グループ
がそれぞれ追加で実施した．

• 西部地区周辺
函館公園，函館八幡宮周辺などを中心としたエリアと函館朝市，金森倉庫，旧イギリス領事官，元町公園，街づくりセンター，海洋研究センター，大門横丁で調査を行った．

• 五稜郭周辺
五稜郭公園，五稜郭タワー，丸井今井を中心に調査を行った．

• 湯の川周辺
函館空港，湯倉神社，足湯，熱帯植物園，五稜乃蔵，トラピスチヌ修道院で調査を行った．
また，調査中は Discord にフィールドワーク用のチャンネルを作成し，気がついた点を写真や文章で共有した．フィールドワーク中の写真やメモは，どのグループも 100 件以上となった．
（※文責: 櫛引萌々子）

2.3.4

振り返り

他グループと共有を行うため，グループごとに実地調査で 3 つの地域から得た情報を KJ 法によりまとめた．その後，お互いにまとめた情報を報告し合い，他グループの 4〜5 人でまとまり，函館の現状や問題点について話し合った．
挙げられた問題点としては，まず函館空港の問題として手荷物検査で準備しておくべきものの案
内がわかりにくい，保安検査所通過後の暇つぶしがないため，利用客が搭乗時間寸前まで通過しようとせず，混雑してしまうことが挙げられた．
観光の問題としては，交通手段がなく移動が大変であること，歴史があるのに知られていない建物や場所があること，案内の表記方法が統一されていないことなどがわかった．
生活の面では，車を持っていないと行くことができる範囲が狭い，道がわかりにくく迷いやすいということが挙げられた．

図 2.2 KJ 法のようす（※文責: 櫛引萌々子）

Group Report of 2023 SISP

-4-Group Number 8-C

Hakodate Complementary Plan: 2.0

2.3.5

知識の獲得

まず初めに，サービスの考案に必要な基盤となる背景知識を収集した．3 つのグループに分かれて，それぞれ AR の歴史，要素技術，先行事例について調査し，わかったことを全体に共有した．
余裕がある者は，函館の郷土史などの個々に興味を持ったテーマについても独自に調査した．その後，函館の街でのフィールドワークでさらに詳細な情報を収集し，アイデア創出に役立つよう整理
した．
（※文責: 杉山新）

2.3.6

各自アイデア出し，フィードバック

1 回目
個人学習とフィールドワークから得た知識をもとに，各員がアイデアを考案して発表した．A4の紙にタイトル，課題，解決策を記述するというルールのもとでそれぞれ 3 案ずつを考案した．その後，全員の前でアイデアを発表し，付箋に感想を書いて渡す形式で相互にフィードバックを授受
した．

2 回目
フィードバックを受けてアイデアを練り直し，再度発表した．2 回目のフィードバックでは，1回目と同様の形式に加えて，新たにオープンスペーステクノロジー（OST）を導入した．OST は
詳細な議題を事前に固めず，参加者が自由に話題を移動することで，自律的に議論を進める手法である．OST のセッションを通じてより柔軟な発言が見られるようになったことに加え，メンバー
がもつ興味の傾向を洗い出せた．

3 回目
2 回目に集まったアイデアを基に，各々が気に入ったものを「街歩き」「空港」「歴史」の 3 つのテーマに分類した．そして，OST を用いて各テーマについて細部の検討を行った．
（※文責: 杉山新）

2.3.7

アイデアの評価基準の設定検討を経たアイデアを絞り込むために評価基準が必要となった．全員からどのような基準をもって評価すべきか意見を募ったところ，「新規性があるか」，「函館らしさを活かせるか」，「AR を使う
必然性はあるか」，「我々が作ってみたいと思うか」，「需要は見込めるか」の 5 つの項目に設定した．
（※文責: 杉山新）

2.3.8

アイデアの絞り込み

班ごとに分かれて評価項目に基づいた絞り込みを行った．その結果を表 2.1 に示す．
その結果を元に全体で話し合い，先のアイデア出しで用いた分類に基づいて，最終的に「街歩き」

Group Report of 2023 SISP

-5-Group Number 8-C

Hakodate Complementary Plan: 2.0
表 2.1

各グループで絞り込んだ案の一覧

グループ 1

グループ 2

グループ 3

裏道 AR

坂ゴルファー

はこだてクエスト

古今箱館物語

酒造 AR

酒造 AR

ハコゲスター

函館×市電

飛行機関連

AR 植物館

夜景 AR

五稜郭戦争

夜景 AR

古今箱館物語

2 案，「空港」1 案，「歴史」2 案にまでアイデアを絞り込んだ．結果を以下の表 2.2 に示す
表 2.2

最終候補案

街歩き

空港

歴史

Fly FAR飛び函五稜郭戦争 AR
古今函館物語はこだてクエスト（※文責: 杉山新）Group Report of 2023 SISP

-6-Group Number 8-C

Hakodate Complementary Plan: 2.0

第 3 章 提供するサービスについて
3.1

背景

函館をはじめとした降雪地域では，他の雪の降らない地域と比べて地上式消火栓の設置数が多い．特に函館の消火栓は見た目が他の消火栓と比べて特徴的であり，近年ではメディアに取り上げられるほど注目を集めている．函館は歴史ある建物や土地，豊かな海産物，夜景のような美しい景
観など観光資源が多くあり，観光地として非常に有名な都市である．しかし，こういった観光地は五稜郭や湯の川，函館駅周辺などに集中しており，他の地域が注目を集めることは少ない．有名な観光地以外にも魅力のあるスポットが多くあるが，有名な観光地ばかり注目されていて認知されていないという課題があると考えた．この課題を解決するために，函館の特徴的な消火栓を辿るという体験を通じて，消火栓を楽しんでもらいながら，途中にある道での新たな発見や，函館のまだ知られていない魅力に気付いてもらえるようなサービスを考案した．
（※文責: 朝日夏々）

3.2

目的

函館の観光地だけではなく，まだ知られていない函館の町全体の魅力に気付いてもらいたいと考えた．そこで，普段生活する中では見過ごされてしまっているが，面白い特徴がある函館の消火栓に焦点を当てた．AR 技術を活用して，消火栓にエフェクトを付与することで，函館の消火栓を巡る動機付けをし，函館の町を楽しく巡って，まだ知られていない函館の魅力を知り，新たな思い出を作る機会を提供することを目的としたサービス開発を行った．
（※文責: 朝日夏々）

3.3

サービス概要本サービス「消火栓見てみま SHOW か！？」は，AR 技術を用いてエフェクトを付与した函館の特徴的な消火栓を巡ることで，函館の町を歩いてもらい，函館の新たな魅力を発見することを目的としたサービスである．
本サービスは，観光客を中心に，散歩をして新たな発見を求めている観光客以外の人や，消火栓に興味のある人をターゲットに定めた．函館は有名な観光名所であり，様々な観光資源があるが，その多くが集中した場所にある．そのため，本サービスは，函館の各所にある消火栓を巡り歩くことで，有名な観光地にはない魅力に出会ってもらう機会を提供した．利用の際，ユーザはアプリ
ケーションを起動し，消火栓を探して歩く．消火栓から 100 ｍの範囲に入ると，アプリケーション
から通知が来る．消火栓を発見した後，消火栓をスマートフォンで映すと，各消火栓にランダムで付与されたエフェクトが表示される．消火栓により違うエフェクトが表示されることで，ユーザに新しい体験を提供する．

Group Report of 2023 SISP

-7-Group Number 8-C

Hakodate Complementary Plan: 2.0（※文責: 朝日夏々）3.4

AR 技術を用いた理由

本プロジェクトは，目的を実現するための手段を検討した結果として AR 技術を用いたのではな
く，本プロジェクト自体が「AR 技術を用いて函館を補完する」という目的があるため，AR 技術
を用いてサービスを開発した．

AR 技術に類似した技術として，専用のゴーグル等を装着して仮想空間にあたかも自分がいるよ
うな体験を提供する VR 技術等があるが，AR 技術は現実にある実際の風景に本来は存在しない
もの，ことを投影してあたかもそこにあるような体験ができる技術であるという違いがある．そこで，AR 技術でサービスを実現するにあたって価値のある体験を提供するということを考えたとき，普段気にも留めないような消火栓に変化を与えることによって，普段の生活では得られない発見を生み出すという価値のある体験に繋がるのではないか，と考えたためである．
（※文責: 朝日夏々）

3.5

利用方法

はじめに，消火栓が 100m の範囲にあるとユーザのスマートフォンに通知が届く．ユーザは近くにある消火栓を探して歩く．
消火栓を発見したら，アプリケーションを起動する．アプリケーションを起動すると，消火栓をかざす画面が表示されるので，表示に合わせて消火栓をスマートフォンで映す．アプリケーションに消火栓が認識されると，消火栓により様々なエフェクトが表示される．ユーザはエフェクトを写真として残すことができたり，撮影した写真を確認したり，訪れた消火栓の位置をマップで確認したりすることができる．
多種多様な消火栓を探したり，消火栓のマップを埋めたりとコレクション要素が含まれているため，ユーザは函館の町を散策したくなることが予想される．これにより，散策している途中での新
たな発見が期待される．
（※文責: 朝日夏々）

3.6

機能一覧

消火栓通知機能
消火栓が半径 50 ｍの範囲内にあると，スマートフォンにアプリケーションから「消火栓が近くにある」という通知が届く．ユーザはこの通知を頼りに消火栓を探すことを予想される．

消火栓認識機能
アプリケーションを起動すると，スマートフォンに消火栓を認識する画面が表示される．ガイド
ラインに合わせて消火栓を画面に映すと，ガイドラインが消え，消火栓にエフェクトが付与される．画面から消火栓を映すのをやめると，再びガイドラインが表示される．

Group Report of 2023 SISP

-8-Group Number 8-C

Hakodate Complementary Plan: 2.0

図 3.1

通知画面

エフェクト表示機能
消火栓を認識すると，消火栓により違うエフェクトが表示される．エフェクトにより，使える機能も異なっている．
踊りエフェクト
実際の消火栓とは別のものである，消火栓のモデルが踊っているものが表示される．画面をタップすると踊りを止めることができる．再び画面をタップすると，再び踊りが始まる．

図 3.2

踊りエフェクト

噴水エフェクト
実際の消火栓の上の部分から，噴水のエフェクトが表示される．画面をタップすると噴水を止めることができる．再び画面をタップすると，再び噴水が出現する．

図 3.3

Group Report of 2023 SISP

噴水エフェクト-9-Group Number 8-C

Hakodate Complementary Plan: 2.0

ローポリゴン与謝野晶子エフェクト
実際の消火栓の上の部分から，ローポリゴンの与謝野晶子のモデルが出現する．画面をタップすると与謝野晶子が消える．再び画面をタップすると，再び与謝野晶子が出現する．

図 3.4

ローポリゴン与謝野晶子エフェクト

増殖エフェクト
実際の消火栓とは別のものである，消火栓のモデルが画面内に出現する．画面をタップすると消火栓のモデルが増え，消去ボタンを押すと消火栓のモデルが消える．
以下のエフェクトは，実装予定のものである．
消火栓が生えてくるエフェクト
このエフェクトは，増殖エフェクトに似て非なるものである．消火栓のモデルが出現すること，
操作方法は増殖エフェクトと同じものであるが，増殖エフェクトは単純に発生するが，このエフェ
クトは消火栓のモデルが地面から出現する．
消火栓デコレーションエフェクト
実際の消火栓にデコレーションパーツを付けたいところをタップすると，デコレーションパーツ
を選ぶ画面が下から出現する．デコレーションパーツを選ぶと，消火栓に選んだデコレーション
パーツが付けられる．また，付けたデコレーションパーツをタップすると，消去ボタンが出現し，操作を取り消すことができる．また，デコレーションパーツは 1 つだけでなく多数付けることができる．
コメントエフェクト
実際の消火栓に，チェキのような見た目でコメントを付けることができる．消火栓を認識すると，これまでに付けられたコメントがあれば表示される．コメントをタップすると，コメントの内容を確認することができる．編集ボタンをタップすると，コメントの編集，挿入する写真の選択ができる．編集が完了したら，完成ボタンで投稿できる．投稿したコメントをタップすると，再編集することができる．

Group Report of 2023 SISP

- 10 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

地域消火栓エフェクト
実際の消火栓の隣に，函館市以外の消火栓のモデルが出現する．出現するだけではなく，その地
域の消火栓の特徴や歴史をテキストで表示する．一つの地域の消火栓だけではなく，他の地域の消火栓も選択し出現させることができる．

写真撮影・録画機能
アプリケーションに表示した映像を，写真撮影・録画することができる．エフェクトが表示される前にも写真撮影・録画することができるが，エフェクトが表示された後に写真撮影・録画すると，エフェクトも一緒に写真・映像に残すことができる．

図 3.5

撮影画面

アルバム機能写真撮影・録画した写真・映像は，アルバム機能で確認することができる．この機能ではこのアプリケーション内で写真撮影・録画した写真・映像のみを確認することができる．

図 3.6

アルバム画面

消火栓マップ機能
アプリケーションで認識したことのある消火栓がマップに表示される．マップに表示されている
ピンをタップすると，住所が表示される．この機能は実装済みであるが，実機での動作が未確認である．

Group Report of 2023 SISP

- 11 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

図 3.7

マップ画面

（※文責: 朝日夏々）

3.7

消火栓について本グループが消火栓に焦点を当てたサービスを制作した理由の一つは，FW や事前調査を通して函館の消火栓に隠された魅力が沢山あることがわかったからである．本セクションでは消火栓の歴史などの情報を書いていく．
（※文責: 堀岡璃久）

函館の消火栓について
函館の消火栓，正式名称: 函館型三方式地上式消火栓について函館では，過去度重なる大火があった．その反省から函館市は昭和 10 年ころから防火施設の整備を進めた．その中でアメリカの消火栓を参考にし，作成されたものが現在の黄色の消火栓である．消火栓のバルブの部分は当時のアメリカの消防隊の帽子のデザインを模して作られたものであるという説がある．函館型消火栓の他の地域と異なる大きな特徴は，黄色いこと，放水口が 3 つあることである．他の地域と異なる特徴にはきちんとした理由がある．色に関しては，夜間ライトで照らしながら消火栓を探す場合，白色で塗られたものが一番視認性が良く次点で黄色いものが視認性が良い．函館市は雪国であるので，冬の積雪時でも視認性を確保できるように黄色という色が採用されている．放水口は，大きいものが 1 個，小さいものが 2 個ついており，他の地域の消火栓と比較しても取水能力が大きい．これらのことから，過去の函館の人々が”大火を二度と起こさない”為に知恵を絞り，心血を注ぎ対策を行ってきた歴史が垣間見える．[1]（※文責: 堀岡璃久）

図 3.8

Group Report of 2023 SISP

函館の消火栓 出典 [1]- 12 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

地上式・地下式とは？
消火栓には大きく分けて”地上式”と呼ばれるものと”地下式”と呼ばれるものの 2 種類が存在する．ここでは，これらの違いについて書いていく．まず，これらの名前は文字通り消火栓の設置される場所の違いである．地上式は地上に飛び出るような形で露出しており，地下式とはマンホールのような形で地下に埋め込まれているものを指す．地上式の最大のメリットはその視認性である．
遠方からでも見失う可能性が低く，積雪時などでも問題なく使用できるので，北海道をはじめとした降雪地域では関東以南の地域と比較して地上式消火栓の数が多い．そのため，消火栓の数で比較すると北海道ほどの面積がありながら 2021 年時点で全国 11 位の設置数であるにも関わらず，東京などから北海道に引っ越してきて消火栓の見かけ上の多さに驚く人がいるそうだ．地下式には地上式のものと比較して視認性が低かったり，積雪時や災害時など物理的にアクセスできなくなる可能性があるが，街の中心地域などで，地上に消火栓を設置できない場合でも問題なく設置でき，景観を損ねにくいというメリットがある．
（※文責: 堀岡璃久）

その他の地域の消火栓について
北海道には函館以外にも面白い消火栓がいくつかある．ここでは特に特徴的な小樽の消火栓を紹介する．小樽は坂のまちと呼ばれるほど市街地全体に坂が多く，住宅地の高低差が激しい街になっている．このような地形の特徴から配水の系統が非常に複雑に構成されており，消火栓もその複雑な水系の中に設置されていた．そういった状況下で昭和 49 年に大規模な火災が発生した．その際に同じ排水系統の消火栓から水を使い過ぎてしまい，消火栓からの水量が足りなくなり，消火作業が難航してしまう事件が発生した．[2] このような背景から一目見たら排水系統を見分けられるように消火栓の色分けを行っており，(赤赤 青青 黄黄 黄赤 青赤) の 5 種類の組に分かれて
いる．

図 3.9

小樽の消火栓 出典 [2]（※文責: 堀岡璃久）

3.7.1

世間からの反応”東京などから北海道に引っ越してきて消火栓の多さに驚く人がいる”と地上式・地下式のセクションで書いた．実際の所消火栓についての世間からの興味はどれくらいなのか気になることだろうと思う．北海道のテレビ局 HBC の視聴者の疑問を番組で調査しに行く形式のコーナーである
もんすけ調査隊 でここ 3 年間のうち 2 回も消火栓の話題について取り上げられており，意外と北Group Report of 2023 SISP

- 13 -

Group Number 8-C

Hakodate Complementary Plan: 2.0
海道の消火栓について興味のある人が多い．

2021 年の放送回では北海道の中でも札幌・小樽・函館の消火栓の色がなぜ違うのか？という疑問を取り上げており，実際に夜間照灯時の可視性についての実験を行ったり，各自治体の水道局や消防本部にインタビューを行っている．[4] 2023 年の放送回では，北海道の消火栓の数はなぜ多い？と東京から越してきた人からの疑問を取り上げており，地下式・地上式の長所短所の説明や見かけ上多く見えている話を解説していた．[3]以上のことから消火栓について世間から需要があると考える．
（※文責: 堀岡璃久）

Group Report of 2023 SISP

- 14 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

第 4 章 開発プロセス
4.1

開発ツール

Discord
Discord は，音声・ビデオ通話，テキストチャットをメイン機能としたチャットツールであり，テキストチャンネルでのチャットはもちろん，作成したボイスチャンネルごとに通話やファイルの共有を行うことが可能である．開発では主に，プロジェクトメンバーとの連絡や出席確認，遠隔にいるプロジェクトメンバーと通話をする際に用いた．また，作業画面を共有することも可能なため，オンラインでの活動時に，リアルタイムでグループメンバーの進捗状況を把握しつつ，議論や相談を交えながら作業を進めた．さらに，ボットを導入し，イベントまでのカウントダウンや Githubと連携して開発進捗を自動的に報告してもらいながら開発を行った．[5]（※文責: 八幡瑠樹）

NotionNotion はノート作成やプロジェクト管理などの機能を統合したサービスである．様々なタスクに対応した豊富なテンプレート機能が利用可能であり，独自のワークスペースを構築できる．主な機能として，テキストや画像，表を含むノートの作成，ドキュメントの作成・共有，カレンダーの作成などが可能である．また，他にも多くの外部アプリケーションとの連携も可能である．開発では，前期からプロジェクト活動の議事録をとるために利用しており，フィールドワークのメモや報告書のまとめにも利用した．後期からは，アジャイル開発を導入し，毎週の活動ごとにグループメ
ンバーの進捗や次回までの課題の記録し，インセプションデッキの作成にも利用した．本サービスを使うことで，過去の議事録から活動内容や共有した資料を容易に振り返ることができ，現在の進捗や必要な作業の明確化に貢献した．[6]（※文責: 八幡瑠樹）

Figma
Figma とは，ブラウザベースのコラボレーションインターフェースデザインツールである．デザイン，プロトタイピング，開発，フィードバック収集を 1 つのプラットフォームで行える．
開発では，UI のワイヤフレーム，プロトタイプの作成に使用した．UI デザインを作成するのに使用しただけではなく，アプリケーションの画面遷移，アニメーションの作成にも使用した．

Figma を使用したことで，メンバとデザインの共有，編集を同時に行うことができ，開発途中のデザインの変更にも柔軟に対応することができた．
（※文責: 朝日夏々）Group Report of 2023 SISP

- 15 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

Blender
Blender は，オープンソースの 3DCG ソフトウェアである．主な機能として，3D モデリング，
3DCG アニメーションやレンダリング，ビデオ編集，VFX などが可能である．開発では，主にエフェクト機能に使用する 3D モデルのモデリング，外見や質感を表現するためにマテリアルの作成，アニメーションの編集に使用した．また，3D モデルを Unity で利用できるようにするため，

obj や fbx のファイルフォーマットで出力する機能を使用した．本ソフトウェアを使うことで，多岐にわたる機能を単一のソフトウェアで扱うことが可能となり，作業の効率化に貢献した．[7]（※文責: 八幡瑠樹）

Illustrator
Illustrator とは，ベクターイメージ編集ソフトウェアである．よく使用される例としては，ポス
ターの作成，ロゴの作成，提案資料の作成などである．このソフトウェアでは，主にアプリケー
ションアイコンの作成を行った．その他には，アプリケーション内で使用するアイコンの作成を行った．Illustrator を使用したことで，下描きの線を綺麗に作成でき，バランスをきれいに整えることができた．
（※文責: 朝日夏々）

SCANIVERSE
Scaniverse とは，ポケモン GO などで有名な Niantic 社が提供している iOS 向けの 3D スキャ
ンアプリである．LiDAR に対応している機種の場合は LiDAR を用いたスキャン，非対応機種はManyDepth 技術を用いた NoLiDAR スキャンという機能を用いて LiDAR 搭載機種と遜色ないク
オリティのスキャンが行える．ManyDepth 技術は，開発元の Niantic 社が開発しており，2D カメラの画像から 3D の奥行きを推測し，スキャン中にカメラを動かすと，ニューラルネットワーク
を用いてスキャン対象の 3D 形状をより正確に取得できるようになっている．[?] スキャンを行った後に FBX，OBJ，USDZ，STL 形式でエクスポートできる．
今回は北海道地区の様々な消火栓をスキャンするために，実際に赴き Detail モードでスャキン
し，fbx 形式でエクスポートしたものを，サービス開発に使えるように Blender でモデルの整形を行った．このモデルを使用し消火栓モデルの認識機能などを作成したので，今回の開発において大いに役立ったといえる．
（※文責: 堀岡璃久）

Git
Git とは，テキストファイル等の変更履歴を記録し，いつでも記録した地点に巻き戻すことが出来るバージョン管理システムである．我々はチーム開発におけるバージョン管理を行うため，

Github と組み合わせて利用した．Git のほとんどの操作はローカル上で行われるため，高速で行われ，作業をする場所を選ばず，誰が編集を行ったかを明確にし，競合を解決する機能を使用した

Group Report of 2023 SISP

- 16 -

Group Number 8-C

Hakodate Complementary Plan: 2.0
ため，チーム開発におけるソースコードのバージョン管理をする際や，報告書の作成をする際に発生するストレスも少なく済んだ．
（※文責: 堀岡璃久）

GitHubGithub とはリモートリポジトリを提供するクラウドサービスである．Github を使用することで，チームメンバー間でのスムーズなファイル共有，進捗管理を行った．開発では Issues，Pull

Request，Github Actions といった Github 上の機能を主に用いた．Issues はサービス開発において発生した問題や改善点，機能リクエストなどのトラッキングに使用される．この機能を用いて，開発では残っているタスクの管理とタスクの割り当てを行った．Pull Request は分岐した branch
上で編集されたファイルを元 branch に取り込む際に使用される．この機能を用いて，開発ではファイルの変更箇所の把握を行った．また Issues と Pull Request ではテンプレートを用いること
により，チームメンバーのだれが見てもタスクのスコープ，ファイルの変更箇所が理解できるようにした．
開発中，Github 上で文字フォントや Vuforia パッケージといった，Github リポジトリにおけるファイルサイズ制限の 100MiB を超えてしまうファイルを共有する必要があった．これに対処するため，Git Large File Storage（以下「Git LFS」と呼ぶ）を用いた．Git LFS とは，リポジト
リに実際のファイルではなく，ファイルへの参照を保存することで大きなファイルを扱う，Githubの拡張機能の 1 つである．Git のアーキテクチャを回避するため，Git LFS では実際のファイルへの参照として働くポインターファイルが作成され，GitHub はこのポインタファイルをリポジトリ
中で管理している．つまり，リポジトリをクローンすると，GitHub はこのポインタファイルを大きなファイルを見つけるための地図のように使っている．Git LFS の導入により，ファイルサイズの大きい Unity パッケージや文字フォントの導入が，容易にできるものとなった．
また，CI/CD 環境の構築には GitHub Actions を使用した．GitHub Actions は，ビルド，テスト，デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー（CI/CD）のプラットフォームである．このサービスでは，Unity プロジェクトのテストとデプロイを行うため，CI では GameCI/unity-test-runner，CD では，GameCI/unity-builder を使用した．CI では，Github 上のソースコードを使用して，Unity プロジェクトのテストを行い，エラーが無ければ，エラーがない旨をレポートにまとめ，Artifact に出力され，CD に移行する．また，エラーが起こっていた場合は，エラーが有ることをレポートにまとめ，Artifact に出力し，CD には移行されない．CD では，GitHub 上のソースコードを用いて実際に Android 用ビルドを行い，

Apk ファイルを出力する．CI/CD 環境の構築によって，円滑な開発環境の構築を行うことができた．
（※文責: 川田隼大・酒井佑馬）

MixamoAdobe Mixamo は Adobe 社が提供する 3D モデル用のアニメーション素材を大量に取り扱うサービスである．このサービスは，3D モデルに対して自動的にリギングを行い，その後アニメー
ションを 3D モデルに適用することができる．アニメーションは歩行，ジャンプ，ダンスなど多彩Group Report of 2023 SISP

- 17 -

Group Number 8-C

Hakodate Complementary Plan: 2.0
なモーションが利用可能である．また，アニメーションにはモーションキャプチャが使用されており，滑らかな動きが特徴的である．そして，Unity や Blender などのプラットフォームと互換性のあるファイルフォーマットで出力可能である．本サービスを使うことで，手軽に 3D モデルにアニメーションを適用することができ，作業の効率化に貢献した．[8]（※文責: 八幡瑠樹）

4.2

技術習得

夏季休業中に開発に使用するツールのチュートリアルを行った．
特に Unity については，サービスの核となるツールではあるが，メンバー全員が未経験であった
ため，重点的に学習を行った．
また，後述するスクラムのプラクティスである，スプリントを体験するのも兼ねて，チュートリ
アルをやるなどのタスクを決め，それを一週間で実施し，報告する機会を設けた．
後期においては開発を行いながら，適宜学習を行い，それを共有し合うことによってチームとしての知識を蓄積させていった．
（※文責: 酒井佑馬）

4.3

開発手法

4.3.1

導入した手法アジャイル開発
本グループでは，ソフトウェア開発の手法である，アジャイル開発を導入した．アジャイル開発
では，短い期間で設計・実装・テストを反復的に繰り返すことにより，継続的に価値のあるソフト
ウェアを提供することができる．アジャイル開発の比較対象として，広く取り上げられるウォー
ターフォール開発という手法がある．ウォーターフォール開発では，まず開発を始める前にユー
ザーの要求を実現するために実装する機能や性能などを定めて具体的にどのように進めるかを決定する．その後，設計・実装・テストを後戻りせずに行う．アジャイル開発とウォーターフォール開発を比較すると，アジャイル開発のメリットは，開発途中でユーザーとコミュニケーションを取りながらフィードバックを行うことができるため，ウォーターフォール開発に比べ，顧客ニーズを反映したソフトウェア開発ができることである．一方，アジャイル開発のデメリットは，プロジェク
トに必要なエンジニアの数や作業量がイテレーションごとに変化することである．これにより，予算の見積もりやスケジュール管理が，計画があらかじめ決まっているウォーターフォール型よりも難しくなってしまう．また，実装する機能がイテレーションごとに変化するため，プロジェクトメ
ンバーごとの作業スコープが定まりづらいというデメリットも存在する．
（※文責: 川田隼大）

スクラム
アジャイル開発を導入するにあたり，アジャイル開発の手法の一つであるスクラムを採用した．
スクラムでは，スクラムチームと呼ばれる，小さなチームを構成することが定められている．スGroup Report of 2023 SISP

- 18 -

Group Number 8-C

Hakodate Complementary Plan: 2.0
クラムチームは，プロダクトオーナー 1 人，スクラムマスター 1 人，複数人の開発チームから構成
される．プロダクトオーナーとは，サービスの価値を最大化する責任者であり，プロダクトバック
ログの管理の責任者でもある．スクラムマスターとは，スクラムというフレームワークを円滑にまわすための責任者であり，プロジェクト自体のマネージャーや管理者という立場を持たない．例として，スクラムのルールをスクラムチームに理解させることや，スクラムチームを妨害から守ること，スクラムチームが円滑に作業を進められるよう支援するといった行動をする．開発チームは，サービスを作るために必要な作業をすべて行うことができなければならない．そのため，開発チームの各メンバーは所有する能力やスキルで，開発に必要なすべての作業を行うために協力し合う必要がある．しかし，今回のチームでは，メンバーの数が 5 人と少なく，スクラムマスターとプロダ
クトオーナーを除いた 3 人のみで，サービスを完成させることは，現実的ではないと考え，スクラ
ムマスターとプロダクトオーナーを，開発メンバーのうちの 2 人が兼任する形で開発を行った．
スクラムでは，実現したい機能を，価値やリスク，必要性などを基準に並べ替えたプロダクト
バックログと呼ばれるリストを作成する．プロダクトバックログ項目の作成や更新, 並び順は前述
したとおり，プロダクトオーナーが最終決定権を持つ．プロダクトバックログの各項目は，ユー
ザーストーリー形式で書かれることが多い．ユーザーストーリーとは，実際にサービス使うユー
ザーの視点に立って，実現したいことを簡潔に記述したものである．プロダクトバックログを作成することによって，実現すべき機能の順番が明確になり，順番が上位の機能から開発に取り掛かることで，成果を最大化することができる．
また，スクラムではスプリントという最長 1 ヶ月までの固定の期間に区切って，開発を繰り返す．スプリント期間内に，小単位での計画・設計・実装・テストを行い，プロダクトバックログの機能を完成させる．これを繰り返すことで，段階的に，そして継続的に動くソフトウェアを提供し続けることができる．今回のチームでは，スプリントの長さを 1 週間とし，後述するスプリントプ
ランニング・スプリントレビュー・スプリントレトロスペクティブは意見をより正確に伝えるために対面で行うことにした．
スプリント内で機能の実装を目指すために，スクラムではスプリントプランニング・デイリース
クラム・スプリントレビュー・スプリントレトロスペクティブの 4 つのスクラムイベントを行う．
まず，スプリントプランニングとは，スプリントを開始するにあたって行われる，スプリントで実行する作業を計画するミーティングである．スプリントで行う作業を計画するミーティングである．このミーティングでは，プロダクトバックログから今スプリントの開発できそうな機能を考案
し，スプリントバックログを作成する．スプリントバックログとは，選択した実装したい機能と，そのための具体的な作業と計画のことである．次に，デイリースクラムとは，スプリント期間中，毎日同じ場所・同じ時間で行う 15 分のミーティングのことである．開発メンバー全員で「昨日何をしたか」，「今日何をするか」，「困っていること」を共有し，スプリントゴールが達成できるかを確認するためのものである．また，スプリントレビューとは，スプリント終了時にスプリントの成果をステークホルダーに披露したり，サービスの状況や進捗を報告したりするイベントである．ス
テークホルダーからのフィードバックに基づき，プロダクトバックログを見直し，今後やるべきことに取り組むことができるようになる．最後に，スプリントレトロスペクティブとは，今回のスプリントにおける活動を振り返り，次回のスプリント以降のアクションプランを考えるミーティング
である．うまくいったことや問題点を話し合い，もっと成果が出せるよう改善を続けることで，ス
クラムチームの成長が期待される．
（※文責: 川田隼大）Group Report of 2023 SISP

- 19 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

4.3.2

開発の流れ

開発は，チーム立ち上げ，開発立ち上げ，開発の順に行った．
チームの立ち上げでは，夏季休業期間中に「函館市地域交流まちづくりセンター」に集まり，キッ
クオフとインセプションデッキの作成を行なった．インセプションデッキを作成する過程で，それぞれの得意分野とやりたいこと，考え方などが共有できたため，この後の開発に入るにあたり，とても重要なフェーズだった．
開発立ち上げでは，まず消火栓フィールドワークを行った．
消火栓フィールドワークでは，消火栓についての理解を深めることを目的として行った．事前調
査では，メンバーそれぞれの最寄り消火栓の場所や，消火栓についての情報を調査し，お互いの知識を共有した．フィールドワークでは，実際に最寄り消火栓に足を運び，観察や写真撮影を行い，消火栓の情報を取得した．また，今後の開発のため，3D スキャンも実施した．振り返りでは，
フィールドワークで得た情報を共有，整理し，バックログ作成で活用した．
フィールドワーク後に，使用する開発環境や，ツール，ライブラリなどの準備や，サービスのデザインを作成した．開発に必要なバックログの作成も同時期に行った．バックログの作成に必要なサービスの機能を洗い出し，それらを実現するためのタスクを作成した．また，タスクの見積もりも行い，バックログの優先順位を決定した．
開発では，スプリント期間を 1 週間に設定し，毎週水曜日をスプリント開始日としてスプリント
プランニングを行い，翌週水曜日にスプリントレトロスペクティブ，スプリントレビューを行なった．スプリントバックログとプロダクトバックログは Notion に記録した．スプリント期間中は毎日デイリースクラムを行い，進捗共有や，作業を行うにあたり，他メンバーに確認することなどを確認した．また，スプリントバックログのうち，開発が伴うタスクは GitHub の issue 機能と連携を行い，Notion と GitHub の両サービスで確認できるようにした．スプリントレビューではメンバーの成果物の確認を行い，スプリントレトロスペクティブはチームの施策やメンバーの作業に対して振り返りを行った．
（※文責: 酒井佑馬）

4.3.3

効果と課題

アジャイル開発の手法を導入することによって，メンバー間の意思の疎通を取る機会が多く用意されていたり，仕様の変更や想定外の事象に対する対処ができた．特にお互いの作業がお互いに作用し合うようなものはコミュニケーションを行う回数が多くなったことでスムーズに乗り越えることができた．
しかし，アジャイル開発を行うことによる問題も発生した．スクラムは本来毎日開発を行うことが前提になっているが，本グループでは，各自が毎日作業できるわけではなく，進捗が毎日でないこともあり，デイリースクラム行う必要がなくなってしまったため開発途中でデイリースクラムを廃止した．また，バックログの不備や，チームのベロシティを計りきれずに想定していた機能を開発しきれないなどがあった．
これらの問題を解決するためには，事前にメンバーのスケジュールを確認しておくこと，スプリントを始める前にあらかじめスクラムのイベントを行うことが効果的であると考える．

Group Report of 2023 SISP

- 20 -

Group Number 8-C

Hakodate Complementary Plan: 2.0（※文責: 酒井佑馬）

Group Report of 2023 SISP

- 21 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

第5章

サービスの開発

5.1

システム構成5.1.1

システム構成図 5.1

システム構成図アプリケーションの基盤は Unity で構成した．Unity 内では，消火栓画像をもとにした AR マー
カーの作成，認識機能の作成のため Vuforia SDK を用いた API の参照を行った．また，Android
本体へのカメラアクセス，アプリケーション内で撮影したスクリーンショットのパス保存，パス取得のため Android SDK を用いた API の参照を行った．さらに，函館市内のマップ表示のため

Mapbox SDK for Unity を用いた API の参照を行った．図 5.1 は本アプリケーションのシステム構成図である．
（※文責: 川田隼大）

5.1.2

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

本サービスは，まちあるきにフォーカスしたサービスであるため，持ち運びがしやすく，かつ多くの人が所持しているスマートフォン向けアプリケーションの開発を行った．

Unity で開発する際，開発言語は C#，JavaScript，Boo の 3 種類から選択することができるが，
JavaScript，Boo の廃止が決定していることと，Unity が標準でサポートしている言語が C#であったため，C#での開発を行った．

Unity で作成したアプリの機能を以下に示す．Unity で作成したアプリでは，メイン機能である
消火栓へのエフェクト機能を使えるようにした．エフェクト機能では，Prefab 化したエフェクト
用の 3D モデルを，消火栓認識後にカメラレイヤーの上に表示することで実装した．表示するエフェクトは全部で 8 種類あり，それらの Prefab 名を位置情報をもとに取り出すことで，エフェク
トの振り分けを実現した．また，アプリ内でカメラ機能を使えるようにした．カメラ機能では，撮影した写真を後から閲覧するためのパス保存や写真撮影が行われたことを示すフラッシュの実装を行った．パス保存では，カメラボタンが押されると画面のキャプチャを行い，作成した写真ファ
イルを Android 本体のメディアディレクトリ内に保存するようにした．また，画面のキャプチャ

Group Report of 2023 SISP

- 22 -

Group Number 8-C

Hakodate Complementary Plan: 2.0とメディアディレクトリの参照は並列で処理し，撮影時の画面のフリーズ時間の短縮を行った．パス保存を実装後，カメラ機能の確認を行ったところ，写真撮影が行われたかどうかがユーザー側からすると非常にわかりづらくなっているという問題が発生した．このため，フラッシュを追加し，ユーザーがよりストレスフリーでサービスを楽しんでもらうことを実現した．また，アプリ内で撮影した写真を，アプリ内で閲覧できるおもひで機能を使えるようにした．おもひで機能の実装のため，撮影した写真のパスを Unity のデータ保存の機能の 1 つである，PlayerPrefs に Json 形式で保存した．これにより，アプリを閉じた後でもアプリ内で撮影した写真は PlayerPrefs で保持することができる．写真一覧表示時には，PlayerPrefs からパス一覧を読み取り，それらを Image に変換することで，写真一覧の表示を実現した．
（※文責: 川田隼大）

5.2

各種 API

5.2.1

Vuforia

Unity で AR ア プ リ ケ ー シ ョ ン を 作 成 す る 際 ，必 要 と な る SDK と し て ARKit や ARCore,ARFoundation など有名なものがいくつか挙げられる．今回はそれらを使用せず，Vuforia
for Unity というものを使用した．Vuforia を選定した理由として，消火栓をターゲットとしたAR アプリを作成するために消火栓自体を AR マーカのような役割にしたいと考えたからである．
Vuforia には 3D モデルから AR マーカを自作できる MTG(Model Target Generator) という機能があったため，要件を満たすことが出来ると考え Vuforia を選択した．実際に MTG を使用してFW の際にスキャンしてきた消火栓モデルを整形して AR マーカ作成を行ったが，非常に簡単な操作で消火栓を認識することが出来た．
（※文責: 堀岡璃久）

Mapbox
本サービスではマップ機能の実装に Mapbox 社の Mapbox Maps SDK for Unity を使用した．
選定の理由は２つある．第一に，アプリケーションや，Web などでよく使用されている Google 社の Google Map が挙げられるが，Google Map Platform Gaming Service がサービス終了となってしまい，Unity 用 SDK である，Maps SDK for Unity もサービスを終了してしまったため，選定から外れたこと．第二に，著名なサービスで Google Map Platform Gaming Service を使用していたものが Mapbox Maps SDK for Unity に移行していたためである．スクウェアエニック
スとコロプラが共同開発した「ドラゴンクエストウォーク」のマップデータは当初 Google Map

Platform Gaming Service のものを使用していたが，サービス終了に伴い，Mapbox のマップデー
タに移行していた．この二つからマップ機能の実装には Mapbox の選定が妥当だと判断し，使用することとした．
（※文責: 酒井佑馬）

Group Report of 2023 SISP

- 23 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

第6章
6.1

各メンバーの振り返り

役割分担

本グループでは，メンバーの得意分野に合わせて，開発タスクを分担した．また，アジャイル
開発の手法に則り，本サービス開発において，最終的な意思決定を行うサービスオーナとチームのファシリテーションを行うスクラムマスターを一人づつ選出した．各メンバーの担当は以下に
示す．
酒井佑馬

• スクラムマスター• モバイルアプリケーション開発
朝日夏々• サービスオーナ• サービスデザイン• ポスター作成
川田隼大• モバイルアプリケーション開発
堀岡璃久

• モバイルアプリケーション開発
八幡瑠樹• 3D モデリング（※文責: 酒井佑馬）

6.2

酒井佑馬の振り返り

プロジェクト学習を通じて多くのことを学ぶことができた．
前期では，サービスの開発に至るまでの過程を学ぶことができた．特にチームに分かれ，サービスの詳細を決める際の話し合いが重要だったと考える．サービスの詳細な仕様などを話し合う前に，各メンバーの得意分野や，好きなこと，やりたいこと，こういった性格であるなどと言ったことをお互いに教えあった．これによって，メンバーがお互いにお互いのことを理解し合えたので，その後のコミュニケーションが円滑に行えたと考えている．
後期では，実践的なサービス開発について学ぶことができた．開発では，グループリーダーとして，タスクの進捗管理や，話し合う際のファシリテーションなどを行った．また，グループリー

Group Report of 2023 SISP

- 24 -

Group Number 8-C

Hakodate Complementary Plan: 2.0
ダーとしてだけでなく，開発者としてもグループを支えた．私達のチームではアジャイル開発の手法の一つであるスクラムを導入し，実践した．私を含め，メンバー全員がスクラム初心者だったた
め，前身プロジェクトである「函館補完計画：序」の進め方を参考にし，段階的にメンバー全員で学びながら導入することによって，スクラムを運用することができた．スクラムのプラクティスの一つであるデイリースクラムについては開発序盤では導入していたが，チームの実態にそぐわないことをメンバーと確認し，開発中盤から実施を取りやめた．また，開発の過程において，お互いにコミュニケーションを取り合うことによって，開発しながらより良い形にアップデートできたのは非常に貴重な経験だったと思う．
開発においては，Github Actions を用いた CI/CD 環境の構築と，モバイルアプリケーション開発を行った．CI/CD 環境の構築では，GameCI の unity-test-runner と unity-builder を使用
して構築を行った．CI では，Unity プロジェクトにおいて，テストを行い，Unity プロジェクトにエラーが起こっていないことを確認した．CD では，Github 上にあるソースコードをもとにAndroid 用ビルドを行った．しかし，ライブラリのバグによって正しく動作しなかったため，ライブラリ依存になるとライブラリにバグが起こると何もできないという教訓を得ることができた．
モバイルアプリケーション開発においては，メンバーと協力しながらタスクを分割し，実装を行った．サービスの核となる機能はメンバーが実装してくれたため，私は，各機能を呼び出すためのプ
ログラムと，外部 API との通信部分を担当した．モバイルアプリケーション開発についても各メンバーの得意分野を活かして開発することができた．
私はこのプロジェクト学習を通じて，チームマネジメントとアジャイル開発などの手法，実践的な技術について学ぶことができた．今後の活動においても上記の学びを活かして取り組んでいきたい．
（※文責: 酒井佑馬）

6.3

朝日夏々の振り返り

プロジェクト学習を通して，私は様々なことを学ぶことができた．
今まで，プロジェクト学習のような 1 年を通して他の人と協力して開発することがなかったため，非常に良い経験となった．開発の中で新しい技術や手法を得た経験も多くあったが，特に他者との協調性を成長させることができた．私は普段生活しているときから，他者との関わりが苦手であったが，プロジェクト学習の中でどのようにしたら一緒に開発をしていきたい仲間と思ってもら
えるか，どのようにしたら情報の共有を気軽に行える人物になれるかなどを考え行動することで，他者との関わり方に自信を持てるようになった．
前期の活動では，プロジェクトのロゴの制作を行ったが，プロジェクトらしさ，意味合いの込め方などを考え，制作することができた．また，メンバと 2 人でロゴの制作を行ったが，ほとん
ど私の意見を通してしまったり，あまりメンバの意見を聞けなかったことが反省として残っている．フィールドワークでは，函館の町を探索する中で普段は見ないような部分から，それがなぜ存在しているのか，どのように機能するのかなどを考えたり，メンバとの仲を深めることができた．
フィールドワークの時から消火栓に着目していたため，「消火栓見てみま SHOW か！？」にこのときの観察点を活かせた．サービス案の考案では，案を考えていく中で，どんどん洗練されたアイデアを思い付けるようになったり，他のメンバのアイデアを見て面白いと思うところを学んだり，
更に良くするにはどうすればいいかなどを考えることができた．

Group Report of 2023 SISP

- 25 -

Group Number 8-C

Hakodate Complementary Plan: 2.0
開発を始める前に，グループの各メンバの得意分野，性格，好きなことややりたいことなどを相互に教えあったことで，円滑にコミュニケーションを行うことができたと感じている．この活動は，これからまたプロジェクトを進める際にも行っていきたい．
後期の活動では，エンジニアとユーザの両方のためのデザインを学ぶことができた．私は開発の中でデザインを担当したが，その中でアプリケーションの UI，アイコン，ポスター，その他の 3Dモデリング以外のデザインに関わっているものを制作した．UI の制作では，ユーザがひと目見ただけで使い方が分かるようなデザインを心がけ，また開発の際に再現できるような動きを考える
ことができた．アイコンの制作では，普段ポップなイメージのものばかり作ってしまうため，モダンなデザインに挑戦できた．新しいデザインを自分の中に取り入れていきたいと考えているため，非常に良い経験となった．また，Illustrator の効果的な使い方も学べた．ポスターの制作では，見る人にとって見やすく，情報が多すぎず伝わりやすいものにできたと感じている．グループのポス
ターだけではなく，プロジェクト全体のポスターも制作したので，普段の締切ギリギリで制作するというペースでは間に合わない．そのため，スケジュール管理を徹底することを学べた．
私はプロジェクト学習を通して，チーム開発をする上での他者とのコミュニケーションの取り方
や，効果的なデザイン手法について学べた．今後の活動でも，この経験を活かしてより良い活動を行っていきたい．
（※文責: 朝日夏々）
プロジェクト学習を通して，私は様々なことを学ぶことができた．
今まで，プロジェクト学習のような 1 年を通して他の人と協力して開発することがなかったため，非常に良い経験となった．開発の中で新しい技術や手法を得た経験も多くあったが，特に他者との協調性を成長させることができた．私は普段生活しているときから，他者との関わりが苦手であったが，プロジェクト学習の中でどのようにしたら一緒に開発をしていきたい仲間と思ってもら
えるか，どのようにしたら情報の共有を気軽に行える人物になれるかなどを考え行動することで，他者との関わり方に自信を持てるようになった．
前期の活動では，プロジェクトのロゴの制作を行ったが，プロジェクトらしさ，意味合いの込め方などを考え，制作することができた．また，メンバと 2 人でロゴの制作を行ったが，ほとん
ど私の意見を通してしまったり，あまりメンバの意見を聞けなかったことが反省として残っている．フィールドワークでは，函館の町を探索する中で普段は見ないような部分から，それがなぜ存在しているのか，どのように機能するのかなどを考えたり，メンバとの仲を深めることができた．
フィールドワークの時から消火栓に着目していたため，「消火栓見てみま SHOW か！？」にこのときの観察点を活かせた．サービス案の考案では，案を考えていく中で，どんどん洗練されたアイデアを思い付けるようになったり，他のメンバのアイデアを見て面白いと思うところを学んだり，
更に良くするにはどうすればいいかなどを考えることができた．
開発を始める前に，グループの各メンバの得意分野，性格，好きなことややりたいことなどを相互に教えあったことで，円滑にコミュニケーションを行うことができたと感じている．この活動は，これからまたプロジェクトを進める際にも行っていきたい．
後期の活動では，エンジニアとユーザの両方のためのデザインを学ぶことができた．私は開発の中でデザインを担当したが，その中でアプリケーションの UI，アイコン，ポスター，その他の 3Dモデリング以外のデザインに関わっているものを制作した．UI の制作では，ユーザがひと目見ただけで使い方が分かるようなデザインを心がけ，また開発の際に再現できるような動きを考える
ことができた．アイコンの制作では，普段ポップなイメージのものばかり作ってしまうため，モダGroup Report of 2023 SISP

- 26 -

Group Number 8-C

Hakodate Complementary Plan: 2.0
ンなデザインに挑戦できた．新しいデザインを自分の中に取り入れていきたいと考えているため，非常に良い経験となった．また，Illustrator の効果的な使い方も学べた．ポスターの制作では，見る人にとって見やすく，情報が多すぎず伝わりやすいものにできたと感じている．グループのポス
ターだけではなく，プロジェクト全体のポスターも制作したので，普段の締切ギリギリで制作するというペースでは間に合わない．そのため，スケジュール管理を徹底することを学べた．
私はプロジェクト学習を通して，チーム開発をする上での他者とのコミュニケーションの取り方
や，効果的なデザイン手法について学べた．今後の活動でも，この経験を活かしてより良い活動を行っていきたい．
（※文責: 朝日夏々）

6.4

川田隼大の振り返り

私がこのプロジェクトへの参加を希望した理由は 2 つある．1 つ目は，本プロジェクトの目的である AR 技術を用いて製作したサービスで，函館市の問題解決につなげるという点に興味をひかれたからである．2 つ目は，一から始めるサービス開発の経験を積んでみたかったからである．本プ
ロジェクトの開発では，生徒自身がタスクを見つけ，生徒自身で様々な決定をする必要がある．それらの決定を 1 年間という短い期間で行うにあたっての，効率的な手法や議論の進め方，チームの雰囲気等を知っておくことで，今後の大学での活動，将来の仕事に役立つのではないかと考えた．
前期の活動内容は，フィールドワークで函館の問題点を探し，それらを踏まえてサービスのアイデアを考案することが主だった．フィールドワークでは，開発に役立つかどうかにかかわらず，自身が気付いた点をできるだけ多く書き留めておくことを意識して行った．結果，函館に隠れていた
面白い発見や，函館の施設ごとが抱えている問題点を探し出すことができた．しかし，フィールド
ワークで得た知見を直接生かしたサービスを考案することは難しかった．このため，複数の案の良いところを組み合わせることや，実現可能性や本プロジェクトの目的から外れている内容ではないかどうかを時間をかけて吟味するといったことを行った．これにより，いくつかの洗練されたサービス案を作成することができた．今後，私の身の回りで似たような場面が発生した場合は，サービス案の作成を焦らずに，しっかりと吟味することを心がけようと思う．
夏季休業中の活動内容は，技術習得とインセプションデッキの作成，開発グループメンバーとの顔合わせである．私は，この中でインセプションデッキの作成が，開発においてとても良いものだったと考える．インセプションデッキでは「このサービスはどのようなものか？」と「このサービスをどのように開発していくか？」を大まかにまとめた．これにより，開発メンバー全員のサービスの理解度が高まるとともに，サービスに対する共通のイメージを持つことができた．また，私たちのチームでは独自の項目として，メンバーそれぞれのできること苦手なことリストを追加した．この項目では，メンバーの性格や得意不得意，開発への向き合い方を共有した．これにより，相手への理解度が増し，相互理解による衝突のない開発を行うことができたと考える．今後も，チームで何かしらの作業を行う際は，チームメンバー間の相互理解が高められるような活動をしようと思う．
後期の活動内容は，サービスの開発が主だった．私が担当した部分は，Android 本体との通信が必要であるカメラ機能とおもひで機能，各種 3D モデルの Prefab 化であった．特にカメラ機能とおもひで機能には多くの時間をかけ，納得のいく仕上がりにすることができた．また，各種 3D モ
デルの Prefab 化に関しては，複数人で作業していたが，こまめに連絡を取り合うことや GithubGroup Report of 2023 SISP

- 27 -

Group Number 8-C

Hakodate Complementary Plan: 2.0を使うことで，タスクの重複を防いだ．しかしながら，複数のタスクで同一のファイルを編集し，

Conﬂict が生じてしまうことがしばしばあった．Unity のファイル形式の 1 つである meta ファイ
ルは，バイナリ形式のファイルであったため，どちらか片方に合わせた Conﬂict 解消しかできな
い．これにより，相手側の環境で再度同様のファイル編集を行うことになってしまい，開発時間が無駄になってしまう場面が多く発生した．今後は，タスクにおいてどのファイルを編集するのかをあらかじめ確認し，Conﬂict が発生しないタスクの振り分けをしていく必要があると感じた．
上記のことに加え，発表資料の作成方法，魅力をより伝えるための発表方法，サービス開発における Github の活用方法，アジャイル開発手法など多くのことをプロジェクト学習を通して学ぶことができた．これらの学びを，今後の活動に生かして取り組んでいきたい．
（※文責: 川田隼大）

6.5

堀岡璃久の振り返り

プロジェクト学習を通して，チーム開発に必要な知識や経験など，将来に活かすことが出来る貴重な経験をすることが出来た．前期では git を使用したことのあるメンバーが経験のないメンバーに git の使い方を教える講習会を行った．私自身 git を使用したチーム開発の経験が浅かったため，今後の開発への不安を抱えていたが，一通りの使用方法，使用した際のメリットなどを丁寧に聞けたため，この講習のおかげで，実際に開発に臨むハードルが下がったように感じた．また，全員でFW 講座を受講し，4 つのグループに分かれて FW を行った．私は湯川方面へ FW に行き，湯川のホテルや旅館がある通りを歩いたり，函館空港の JAL の方々に協力してもらい，保安検査所での待ち時間の問題であったり，搭乗時の手荷物の大きさに関するものなどの問題点を直接聞かせてもらった．その後，函館らしさ・新規性・AR である必要性・自分たちがやりたいか・需要があるか，という評価軸に沿ってアイデア出し・絞り込みを行った．私自身は，空港で聞いた問題点の解決を図るサービスの提案を行い，OST(オープンスペーステクノロジー) や kj 法などを用いてグループメンバーみんなのアイデアを絞り込んだ．最終的に５つのサービスに絞り込み，私は空港の諸問題を解決するサービスの発表を行った．発表会後に，もう一度みんなで集まってアイデア案の再考案を行い，消火栓に関するサービス・夜景に関するサービス・五稜郭で戦うサービスの 3 つに絞り込んだ．ここまでが前期の活動で行ったことである．
私自身函館高専から未来大学に今年度編入学してきたので，プロジェクトに配属された当初は，技術面で足りない部分が多かったり，うまく馴染めるかの不安を感じていたが，チームメンバーに恵まれ，メンバー同士で技術の講習を行ったり，きちんとした自己紹介を行い，親睦を深めるイベントを企画してくれたので杞憂に終わって良かった．また，アイデア収集のために行った FW であったが，チームメンバー同士の相互理解を深める上で重要なイベントにもなったように感じた．
夏季休業期間中は，前期最後に絞り込んだ 3 つのサービスのうち消火栓サービスに配属され，メンバー同士のアイスブレイク・インセプションデッキの作成・Unity 開発に挑戦するためのチュー
トリアルを行った．インセプションデッキを作成することによって，メンバー各自のサービスのイ
メージのすり合わせができ，皆の向く方向を合わせることが出来た．ここで作成したインセプショ
ンデッキのおかげで開発に入ってからも軸がぶれずに開発を行うことが出来たように思う．Unityのチュートリアルでは，ブロック崩しゲームの作成を行った．簡単なゲーム作成を通して，Unity
開発の基礎であったり，スクリプトの記述方法が理解できたため，初めにやっておいてよかった．
後期に入ってからは，本格的にサービスの開発に取り組むために，実際に FW を行い消火栓めGroup Report of 2023 SISP

- 28 -

Group Number 8-C

Hakodate Complementary Plan: 2.0
ぐりをしたり，サービスに実装する機能の優先度付けや実装するための技術選定を行った．チー
ムメンバーで共有を行った後にタスクの振り分けを行い本格的な開発を進めていった．私自身はVuforia の MTG(Model Taget Generator) を用いて消火栓自体を AR のマーカーとして認識できるような機能の実装と，そのほか細かなタップ時の動作の実装，北海道函館市以外の消火栓がある場所に実際に訪れて（札幌・小樽・その他道内各所）LiDar センサ付きの iPad でスキャンしてもでスキャンし，blender を用いてアプリ内で使用できるような形の 3d モデルとして整形するなどの作業を行った．開発するにあたって，はじめ大変だったことが Git の使用である．元々チーム開発の経験も浅く，授業で少し触る程度しか Git の利用をしていなかったので，基本的な使用方法もままならない状態であったが，グループ内の出来る人に都度聞いたり，自分で調べながら開発を行うことによって今後使える知識が身についたと考える．また，Unity のスクリプトは C#を用いて書くのだが，C 言語に少し触れたことがある程度で，オブジェクト指向の言語を使用した経験がほ
とんどなかったのだが，今回の開発を通して触れることができたのでこれも自身にとって良い経験になったと思う．
以上のことから，このプロジェクトでの活動を通して，アイデアの出し方，まとめ方，進捗の管理方法，git の使用法などチーム開発を行う上で必要になる様々な知識，経験を得ることが出来た．
今後の活動においてもこれらの経験を活かして行きたい．
（※文責: 堀岡璃久）

6.6

八幡瑠樹の振り返り

プロジェクト学習は，慣れない難しいことも多かったが，そこから多くのことを学ぶことができ，将来に活かせる貴重な経験になったと感じる．
前期では，フィールドワークで函館の問題点を探し，それらを踏まえてサービスやサービスのア
イデアを考案することやサービス開発について学習することが主だった．最初に，函館のまちにあるモノ・コト・トキを AR 技術でカスタマイズすることを目指して，アイデア出しを行った．アイ
デアを出す過程でフィールドワークを行い，函館のまちの観察や函館の企業へのヒアリングを通して，函館の現状を把握した．しかしながら，AR という技術を使用する必要性が乏しいアイデアが多く浮かび上がり，議論を行う中でアイデア出しの難しさを実感した．この活動によって，様々な観点から課題を検討する力を身につけることが出来た．次に，アジャイルワークショップに参加した．このワークショップを通して，サービスの開発工程やタスクの管理において柔軟性と迅速な対応が重要であることを理解し，スクラムやカンバンといったアジャイル手法の有効性に気づくことができた．最後に，グループメンバー同士が協力し合いながらアイデアを発表・議論し，最終的には複数の選択肢から 3 つのアイデアに絞り込んだ．この過程で，メンバー同士が協力し合いながら時間をかけて議論し，最終的には全員が納得するアイデアを見つけることができた．この活動を通して，課題の検討やアイデアの絞り込みにおいて，複数の視点からアプローチするスキルやチームワークが向上したと感じる．
夏季休業期間中は，インセプションデッキの作成や Unity のチュートリアルを行った．インセプ
ションデッキの作成によって，開発の目標や方針を明確にすることができた．また，グループメン
バーのスキルや性格を共有することで，グループ全体の結束を一層強化できたと感じる．そして，Unity のチュートリアルを通して，プロジェクト開発に必要な技術の向上に努めた．
後期では，本格的なサービス開発に取り組んだ．私の所属するグループでは，前期に学習したアGroup Report of 2023 SISP

- 29 -

Group Number 8-C

Hakodate Complementary Plan: 2.0
ジャイル開発の一種であるスクラム開発を導入した．開発中盤にはデイリースクラムを行わなくなったが，実際にスクラム開発を導入し，開発を進めるのは初めてだったため良い経験になった．
開発では，主に，消火栓の 3D モデルとエフェクト機能用の 3D モデルやアニメーションを作成した．消火栓の 3D モデル作成では，Luma AI でスキャンした消火栓を使用した．AI を用いている
ため，3D モデルのメッシュにできる穴は少なかったものの，目立ってしまう可能性があるため，ス
キャンする際のカメラ角度に気を付けた．スキャンアプリを選定する際に，スキャン方法やスキャ
ン情報の処理方法について学ぶことができたため良い経験になった．エフェクト機能用の 3D モデルやアニメーション作成では，Blender を用いて 3D モデルやアニメーションを作成した．この際に苦労したのは，Blender のモディファイアとシェーダーノードで作成したエフェクトを Unity に移すことである．これは最初に，Blender のモディファイアとシェーダーノードで作成したアニ
メーションは 3D でのエクスポートに対応していないことが問題であった．Blender でのアニメーション作成方法から調べていたため，Blender から Unity に移す際のことを考えていないことが原因であった．アニメーションを Unity に移すために，Blender でアニメーション中の 3D モデルを

Unity に移し，3D モデルのテクスチャを Unity のシェーダーを利用した UV スクロールを使用して再現した．作業を通して，先に移行元と移行先がどこまで対応しているのか確認するべきという教訓を得ることができた．また，3D モデルを Unity に移す際にも試行錯誤した．特に，3D モデルの見た目を Unity 上で容易に変えられるように様々なファイルフォーマットで検証した．これ
らの作業を通して，3D モデルの仕組みやファイルフォーマットの特徴を学ぶことができたので良い経験になった．
以上のことから，このプロジェクトを通して，困難な状況でも柔軟に対応し，協力して目標を達成するチームワークや，新しい技術やツールの習得，プロジェクト全体の進捗管理など，様々なス
キルや知識を身につけることができた．これらを今後の活動において活かしてさらなる成長を目指していきたい．
（※文責: 八幡瑠樹）

Group Report of 2023 SISP

- 30 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

第 7 章 成果報告会
7.1

発表形式

グループでの発表の方法は，プロジェクト全体のメインポスター・スライドを用いた発表でそれぞれのサービスについて軽く説明した後に，興味のあったサービスのところに分かれてもらい，その後グループで作成したスライド・ポスターを用いて発表を行う形であった．我々のグループでは
特に，等身大消火栓パネルを設置し，demo 機を 3 台用意して実際に体験してもらい，その間に消火栓についての豆知識を話すようなスタイルで発表を行った．
（※文責: 堀岡璃久）

7.2

レビュー内容7.2.1

発表形式の評価と反省発表形式に関して，高評価な意見として• デモなどもあって分かりやすかった• どういう経緯でどういうサービスが作られたかという説明が簡潔で分かりやすかった• 画像が複数あり，分かりやすかったなどが得られた．したがって，発表を見に来た人にとって本アプリケーションの評価は高いと言え，実際に使ってみたいというユーザーも多くみられる．低評価な意見としては，• 使用した技術にもう少し説明があってもいいかなと思った• 多くの人が同時にデモの体験を出来ないのが勿体無いと思った．
• デモ動画を用意するといいと思った．
などが得られた．平均評価は 10 点中 8.8 点であった．以上から，デモンストレーション用の動画を制作し，別で流すなど，一度に多くの人に本サービスの内容を伝える物を準備するべきであったと言える．実演しながらの説明ではマンツーマンであったため丁寧な対応ができ，それが高評価につながったと考えられる．
（※文責: 八幡瑠樹）

7.2.2

発表内容の評価と反省

発表内容に関しては，高評価な意見として• 函館の観光を強化する上で，面白いアプリだと思った• 実際に体験できるデモンストレーションがあって分かりやすくて，楽しい発表だった• 消火栓× AR でこういうアプローチがあるのかと感心したGroup Report of 2023 SISP

- 31 -

Group Number 8-C

Hakodate Complementary Plan: 2.0などが得られた．したがって，発表を見に来た人にとって，本アプリケーションのサービス内容は興味深いものであったと言える．低評価な意見としては，• 目的がそれぞれ分かりにくい• 今後の展望が現実的なものかどうかという点が気になってしまったなどが得られた．平均評価は 10 点中 9.0 点であった．発表において，今後の展望の前にデモンス
トレーションを行っていたため，今後の展望の説明がなおざりになっていた．デモンストレーションを行う前に，発表内容を伝えきるべきであり，情報提供の形式に工夫が必要だった．聴衆に分かりやすく情報を伝えるように心掛けていればこのようなことは起こらなかったのではないかと考えられる．
（※文責: 八幡瑠樹）

Group Report of 2023 SISP

- 32 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

第 8 章 まとめ8.1

前期の振り返り前期は，ロゴ制作，勉強会，フィールドワーク，サービスの考案を行った．
ロゴ制作では，プロジェクトの特徴や，イメージを表現するとともに，メンバー全員の一体感を産むために，今年度のプロジェクトのロゴを制作した．メンバー全員がロゴ案を考案し，レビュー会を行った．その後，有志のメンバーによるロゴチームを結成し，ロゴの考案を行なった．その後，プロジェクトメンバーによる投票によってロゴを決定した．
勉強会では，アジャイルワークショップ，Git・GitHub ハンズオンを行いました．本プロジェ
クトでは開発手法の一つとしてアジャイル開発を取り入れるため，アジャイルワークショップに参加した．事前にビデオ教材にて「アジャイル開発概論」を学習し，ワークショップにて具体的なシ
チュエーションを基に学習を行なった．本プロジェクトではソースコードの管理に GitHub を使用する予定であったため，Git・GitHub ハンズオンを行なった．ハンズオンでは，Git を自身の PCにインストールし，環境構築を行なった．そして，Git のコマンドを複数実行し，GitHub に反映させるということも行なった．
フィールドワークは，函館の街や，その周辺に存在する問題や課題を調査することを目的として行なった．具体的には，事前調査，フィールドワークに関するレクチャー，フィールドワークの実
施，振り返りを行なった．事前調査では，「西部地区」「五稜郭」「湯の川」の 3 つの地域に分かれてフィールドワークを行うことを決定した．対象の地域にまつわる歴史・名所などを調べ，理解を深めた．フィールドワークに関するレクチャーを南部美砂子先生，元木環先生より受けた．フィー
ルドワークとは何か，調査者としての態度，様々なフィールドワークの事例から気をつけておく
べき点について理解することができた．フィールドワークではグループに分かれ，3 つの地域へ
フィールドワークを行なった．振り返りではグループごとにフィールドワークで得た情報を KJ 法
によってまとめ，お互いのグループでまとめた情報を報告し合い，函館の現状や問題点について話し合った．サービスの考案では，はじめに，サービスの考案に必要な基盤となる背景知識を収集した．AR のの歴史や，要素技術，先行事例などを調査した．次にアイデア出しとフィードバックを行なった．合計で 3 回実施し，1 回目はアイデアを A4 の紙に書いて貼り，発表した後に，付箋にてフィードバックを行った．2 回目は，1 回目と同様の形式に加えてオープンスペーステクノロ
ジー（OST）を導入し，議論を深めた．3 回目は「街歩き」，「空港」，「歴史」の 3 つのテーマに分類し，OST にて細部の検討を行なった．次にアイデアの評価基準を設定した．「新規性はあるか」，「函館らしさを活かせるか」，「AR を使う必要性はあるか」，「我々が作ってみたいと思うか」，「需要は見込めるか」の 5 つの項目に設定した．最後にアイデアの絞り込みを行い，「街歩き」チーム
が「FlyFAR」，「はこだてクエスト」，「空港」チームが「飛び函」，「歴史」チームが，「五稜郭戦争AR」，「古今箱館物語」に絞り込まれた．
中間発表会では，ポスターとスライドを用いて発表をした．スライドは本プロジェクトの概要を説明するために使用し，ポスターはそれぞれのチームのアイデアを発表するために使用した．発表
会後にレビューを頂き，成果発表会での発表に活かした．
（※文責: 酒井佑馬）

Group Report of 2023 SISP

- 33 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

8.2

後期の振り返り後期は，サービス割り当て，インセプションデッキ制作，フィールドワーク，プロダクトバック
ログ制作，サービス開発，レビュー会，成果発表会を行った．
サービス割り当てでは，夏季休業中に前期の中間発表会で得たレビューをもとに提案されたアイ
デアに基づいて，3 つのグループに分かれた．それぞれ，「五稜郭 AR 戦争」，「星空メモリアル」，「消火栓，見てみま SHOW か！？」の 3 つのグループに分かれた．各グループで，技術選定や技術習得，サービスの確認などを行い，後期のサービス開発に備えた．
インセプションデッキ制作では，サービスの全体像を把握し，メンバー全員がサービスの開発に共通の認識と目標を持って取り組むために，チーム名，われわれはなぜここにいるのか，エレベー
ターピッチ，利害関係者，メンバーのできることできないことなどをまとめた資料を作成した．メンバー全員がアイデアを出し合い，最終的な内容を協力して決定した．本グループではアジャイル開発を採用しており，その一環としてインセプションデッキを作成した．
フィールドワークでは，消火栓についての理解を深めることを目的として行った．具体的には，
事前調査，フィールドワークの実施，振り返りを行った．事前調査では，メンバー全員がそれぞれの最寄りの消火栓の場所や全国での消火栓の違いについて調査し，互いの知識を共有した．フィー
ルドワークでは，メンバー全員が事前調査で調べた場所に実際に足を運び，消火栓に関する実地調査を行った．各メンバーが観察や写真撮影を通じて情報を取得し，実際の状況も把握した．特に，消火栓の具体的な特徴や配置の違いに注目した．また，今後のプロジェクトにおいて必要な情報を取得するために，3D スキャンも実施した．振り返りでは，フィールドワークで得た情報を整理し，バックログ制作で活用しできるようにした．
プロダクトバックログ制作では，フィールドワークで得た情報をもとに，具体的なサービスの要
件や機能を整理した．消火栓に関する特徴や利点などを洗い出し，それに基づいてサービスに実装する機能を決定した．また，バックログに優先順位をつけ，サービスで優先する開発項目を明確にした．
サービス開発では，前述のプロダクトバックログに基づいて実際にサービス開発を行った．本グ
ループでは，アジャイル開発の一種であるスクラム開発を採用し，毎週スプリントを実施した．ス
プリントは，デイリースクラム，スプリントレトロスペクティブ，スプリントレビュー，スプリン
トプランニングの 4 つのイベントで構成されている．デイリースクラムは，開発中盤で本グループに合わないと判断し，取りやめた．スプリントレトロスペクティブでは，スプリント中の良かった
こと悪かったことを共有した．スプリントレビューでは，スプリント中に達成した成果や進捗を共有した．スプリントプランニングでは，次のスプリントで取り組むべき課題を決めた．これらのイベントを取り入れ，開発の進捗管理や課題の解決に努めた．
開発ツールは Unity を主に使用し，ソースコードの管理に GitHub を採用した．消火栓を認識するために Vuforia を使用し，マップ機能の実装には Mapbox を使用した．エフェクト制作にBlender と Adobe Mixamo を使用し，アプリデザインやポスター制作に Illustrator と Figma を活用した．
レビュー会では，各グループで開発しているサービスの概要と進捗を共有し，サービスについて質問やアドバイスをし合った．それを参考にし，グループごとに今後のサービス開発について話し合い，サービスのブラッシュアップを行った．
成果発表会では，スライドとポスターを用いて発表をした．スライドは本プロジェクトの概要をGroup Report of 2023 SISP

- 34 -

Group Number 8-C

Hakodate Complementary Plan: 2.0
説明するために使用した．サブスライドは本チームのサービスの概要を発表するために使用した．
ポスターはそれぞれのチームのサービスの概要を発表するために使用した．
（※文責: 八幡瑠樹）

8.3

今後の展望

本グループは，秋葉原で行われる成果発表会，東京で行われる AgilePBL 祭り，未来大で行われる enPiT BizSysD Workshop 2024 に出展予定である．そのため，これらに向けたサービスのブ
ラッシュアップと発表手法の改善を行いたいと考えている．
サービスのブラッシュアップについては，実装しきれなかった機能を実装するということが挙げられる．成果発表会の時点で，サービスの核となる機能である，「消火栓を AR 上で遊ぶ」，「エフェクトをつけた消火栓を撮る」というものは完成していたが，「アプリ内で消火栓の魅力を伝える」や，「函館だけでなく様々な地域の消火栓と比較する」，「消火栓がある場所をマッピングしてコレクションする」といった機能を実装しきれなかった．具体的には「デコレーション」機能，「コ
メント」機能，「地域消火栓」機能，である．デコレーション機能は，消火栓にデコレーションパー
ツを付ける機能である．この機能をつけることによって，消火栓に愛着を持ってもらう事ができると考える．コメント機能は，消火栓にコメントを残すことができる機能である．この機能を持った消火栓を，普段人があまり行かないようなところに設置することによって，消火栓を目的として訪れた人同士の交流が生まれ，思い出の一つとなると考える．地域消火栓は，函館だけでなく，様々な地域の消火栓と比較する機能である．消火栓は地域によって，その地域の特徴や，歴史を反映したデザインや，機能となっている．したがって，消火栓を通じて地域の特徴や，歴史を知ることができる．これらの機能を実装できていない段階では，消火栓の魅力を伝えることや，消火栓を起点として函館を巡ってもらうという目的を達成できないため，重要度の高い改善であると考える．
発表についても改善する必要があると考えている．成果発表会では，すべての機能を完成させることができなかったため，アプリのデモをやりながら消火栓の魅力を伝えるという手法を取らざるを得なかった．したがって，今後の発表会では，実装できていない機能を実装し，発表だけでな
く，アプリで魅力を伝えられるようにしたいと考えている．また，発表スライドについても改善の余地があると考えている．スライドはあくまでも補助資料として，サービスの背景などや，簡単な魅力などを話す程度のものを想定していたが，アプリで伝えられなかった魅力までスライドに盛り込んでしまったため，スライドが長くなってしまった．したがって，今後の発表会では，スライドの内容を見直し，アプリで伝えられないことのみをスライドに盛り込むようにしたい．
（※文責: 酒井佑馬）

Group Report of 2023 SISP

- 35 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

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

図 A.1

Group Report of 2023 SISP

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

Group Number 8-C

Hakodate Complementary Plan: 2.0

付録 B 成果発表会で使用したグループ概要の
ポスター

図 B.1

Group Report of 2023 SISP

成果発表会で使用したグループ概要ポスター- 37 -

Group Number 8-C

Hakodate Complementary Plan: 2.0

参考文献[1] 函 館 市 役 所.

”函 館 の 消 火 栓”.

函 館 市

City

of

HAKODATE(2018-3-14).

https://www.city.hakodate.hokkaido.jp/docs/2014011300057/, (accessed 2023-1-17).
[2] 小 樽 市 役 所. ”小 樽 市 の 消 火 栓 に つ い て”. 小 樽 市 OTARU CITY (2020-12-19).
https://www.city.otaru.lg.jp/docs/2020101200169/, (accessed 2023-1-17).
[3] HBC ニ ュ ー ス 北 海 道 放 送. ”「 東 京 に は 消 火 栓 が な い ！ ？ 」な ぜ ？ 札 幌 は 消 火 栓 が多 い ？・・・も ん す け 調 査 隊（ 今 日 ド キ ッ ！ 2023 年 11 月 10 日 放 送)”. (2023-11-10).

https://youtu.be/EQiKhiUDwtY?si=s3VdaowqfpQ37u94, (accessed 2023-1-17).
[4] HBC ニュース 北海道放送. ”なぜ消火栓の色は違うのか？札幌は黄色、旭川は赤、小樽
は５色！？そこには意外な理由があった！！・・・北海道（札幌・小樽・旭川・函館）『今日ドキッ！もんすけ調査隊』2021 年 11 月 11 日放送”. 2021 年 11 月 11 日 (投稿日時).

https://youtu.be/Jnv4fcwjuaQ?si=9FUEzNan3T8uHOyQ, (accessed 2023-1-17).
[5] Librarian. ”Discord 初心者ガイド”. https://support.discord.com/hc/ja/articles/360045138571,(accessed 2024-1-17).
[6] Notion Labs, Inc. ”notion.so”. https://www.notion.so/ja-jp/product, (accessed 2023-1-17).
[7] Blender. ”blender.org”. https://www.blender.org/, (accessed 2023-1-17).
[8] Adobe Systems Incorporated. ”mixamo.com”. https://www.mixamo.com/, (accessed 20231-17).

Group Report of 2023 SISP

- 38 -

Group Number 8-C