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

プロジェクト名使ってもらって学ぶフィールド指向システムデザイン 2021

Project Name
Field Oriented System Design Learning by Users’ Feedback 2021

グループ名
グループ A (地域 × 災害チーム)

Group NameGroup A (Community × Disaster Team)
プロジェクト番号/Project No.

1-A

プロジェクトリーダ/Project Leader
石井滉一

Koichi Ishii

グループリーダ/Group Leader
海野芽美

Megumi Unno

グループメンバ/Group Member
海野芽美

Megumi Unno

木川裕太郎
畑大地

Yutaro Kikawa

Daichi Hata

藤田華奈

Kana Fujita

吉田拓夢

Hiromu Yoshida

指導教員伊藤恵 南部美砂子

奥野拓

原田泰

AdvisorKei Ito Misako Nambu Taku Okuno Yasushi Harada

提出日
2021 年 7 月 21 日

Date of Submission
July 21, 2021

概要
本プロジェクトは，フィールド調査をもとに問題を発見し，IT(Information Technology) を用いてユーザの仕事や生活をデザインすることを目的としている．また，本プロジェクトは，
スクラムと呼ばれるアジャイル開発手法の一種を用いる．それにより，高速で柔軟な開発を行い，短期間でより効率的に成果を出すことを目標としている．今年度はプロジェクト内を地域

× 災害チーム，高齢者支援チーム，シビックテックチームの 3 チームに分かれ，各チームがそれぞれのフィールドで活動している．本報告では地域 × 災害チームについて報告を行う．本
チームでは函館市民の防災意識の向上を目指すため，情報収集として担当教員である南部美砂子准教授による現段階で行われている函館の防災活動に関してのレクチャー，函館女性会議へのヒアリング，Code for Hakodate へのヒアリングを行い，集めた情報から問題点や課題を洗い出した．この結果，子どもへの防災教育という点に着目し，「函館市民の防災意識の向上を目
指し，子どもたちが関心を持つ防災学習を立案する」というテーマを決定した．テーマからプロダクトを決定する際にはブレインストーミングという手法を利用して出した 3 案のうち「やりたい」「やるべき」「やれる」の観点からゲーミフィケーションを取り入れた防災学習システ
ム「DID IT」を作成することに決定した．従来の防災学習について，子どもたちにとっての代表的なものとして避難訓練がある．しかし，多くの避難訓練ではありふれた避難状況の中子どもたちが受動的に参加しているため防災意識の向上効果が薄いと考えた．そこで，このプロ
ダクト「DID IT」を提案することにより子どもたちが防災訓練に能動的に参加することを実現し，結果として防災意識の向上効果を高めることを狙う．
キーワード

フィールド調査，IT，アジャイル開発，災害，防災教育（※文責: 畑大地）

-i-

Abstract
The goal of this project is to discover problems based on ﬁeld research and design a way
of working and living for users using information technologies (IT). In addition, thisproject adopts a kind of agile development method called Scrum. By doing so, we aim
to achieve fast and ﬂexible development, and to produce results eﬃciently in a shortdevelopment period. This year, we are divided into three teams: the “Community ×
Disaster” team, the “Elderly Support” team, and the “Civic Tech” team. This report isabout the “Community × Disaster” Team. In order to improve the disaster prevention
awareness of Hakodate citizens, this team collected information through a lecture by
Prof. Nambu, a teacher as instructor, interviewed the Hakodate Women’s Conference,and interviewed Code for Hakodate. The problems and issues were identiﬁed from theinformation gathered. As a result, we decided to focus on disaster prevention education
for children, and decided on the theme of “planning disaster prevention education forchildren in order to improve disaster prevention awareness of Hakodate citizens”. In deciding on a product based on the theme, we used the brainstorming method and decided
to create a gamiﬁed disaster prevention learning system called “DID IT” from the perspective of “We want to,” “We should,” and “We can.” Evacuation drills are a typicalexample of conventional disaster prevention learning for children. However, we believethat most evacuation drills are not eﬀective in raising awareness of disaster prevention
because children are passively participating in common evacuation situations. Therefore, by proposing this product, “DID IT”, we aim to make children actively participate
in disaster drills, and as a result, increase their awareness of disaster prevention.
KeyworducationField Research, IT, Agile Development, Disaster, Disaster Prevention Ed（※文責: 畑大地）

- ii -

目次
第1章

背景と目的

1

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

1

1.1.1

プロジェクトの立ち上げ . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.2

プロジェクトの方針 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.3

チームの背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

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

2

中間発表までの主な活動

3

2.1

リスク分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

チーム分け . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3

プロダクト決定までの活動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3.1

函館における防災活動の調査 . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3.2

函館女性会議へのヒアリング . . . . . . . . . . . . . . . . . . . . . . . .

5

2.3.3

Code for Hakodate へのヒアリング. . . . . . . . . . . . . . . . . . . .

6

2.3.4

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

6

1.1

1.2
第2章

2.4

プロダクトの決定. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.5

プロダクト具現化. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.5.1

エレベーターピッチの制作 . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.5.2

ペルソナの決定. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

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

8

夏季休暇中の活動

9

3.1

夏季休暇での活動方針 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.2

プロダクトの詳細決め . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.2.1

類似サービスを調査 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.2.2

函館市立えさん小学校訪問 . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.2.3

プロダクトの機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.2.4

デバイス決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.2.5

ユーザーストーリーマップ作成 . . . . . . . . . . . . . . . . . . . . . . .

10

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

10

3.3.1

GitHub・スクラム講習会 . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.3.2

UCD ワークショップ . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.3.3

FizzBuzz アプリケーション作成 . . . . . . . . . . . . . . . . . . . . . .

12

開発方針決め . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.4.1

開発形態 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.4.2

縮小スクラム導入決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.6
第3章

3.3

3.4

第4章

後期活動内容14- iii -

4.1

4.2

4.3

スクラム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

4.1.1

ツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

4.1.2

デイリースクラム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

4.1.3

スプリントプランニング . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

4.1.4

スプリントレトロスペクティブ . . . . . . . . . . . . . . . . . . . . . . .

16

4.1.5

スプリントレビュー . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

各スプリントでの活動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

4.2.1

縮小スクラム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

4.2.2

本スクラム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

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

22

4.3.1

概要

4.3.2

発表内容と結果. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

実地試験 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.4.1

1 回目実地試験 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.4.2

2 回目実地試験 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.5

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

27

4.6

enPiT BizSysD 北海道・東北合同発表会 . . . . . . . . . . . . . . . . . . . . . .

27

4.7

最終報告書 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

プロダクト

28

5.1

プロダクト概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

5.2

エレベーターピッチ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

5.3

ペルソナシートの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

5.4

USM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

5.4.1

ユーザの行動を明確化する . . . . . . . . . . . . . . . . . . . . . . . . . .

29

5.4.2

ユーザの価値を明確化する . . . . . . . . . . . . . . . . . . . . . . . . . .

30

5.4.3

必要な機能を明確化する . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

5.5

画面デザインの決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5.6

クイズのコンテンツ決め . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

5.7

ゲームの流れやルールについて . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5.8

開発済みの画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5.8.1

ゴール場所確認画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.8.2

メイン画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.8.3

クイズ画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.8.4

ゴール画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

アプリケーションの機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

5.9.1

共通の機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

5.9.2

1 回目の実地試験で開発した機能 . . . . . . . . . . . . . . . . . . . . . .

39

5.9.3

2 回目の実地試験で開発した機能 . . . . . . . . . . . . . . . . . . . . . .

41

使用した技術 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.10.1 Android Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.10.2 Kotlin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

4.4

第5章

5.9

5.10

- iv -

第6章

6.1

第7章

5.10.3 PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.10.4 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.10.5 Go 言語 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.10.6 Vue.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

今後の展望

44

フィードバックを基にしたプロダクト改善 . . . . . . . . . . . . . . . . . . . . .

44

6.1.1

成果発表会で得たフィードバック . . . . . . . . . . . . . . . . . . . . . .

44

6.1.2

実地試験で得たフィードバック . . . . . . . . . . . . . . . . . . . . . . .

44

6.1.3

フィードバックを基にした改善 . . . . . . . . . . . . . . . . . . . . . . .

44

学び

46

7.1

畑大地 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

7.2

藤田華奈 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

7.3

海野芽美 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

7.4

吉田拓夢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

7.5

木川裕太郎 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

第8章

まとめ

50

第9章

今後の予定

51

9.1

フィードバックを利用した改善 . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

9.2

課外成果発表会への参加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

付録 A

制作物: アカデミックリンクでのスライド

52

付録 B

成果発表会にて使用したポスター

57

参考文献

58

-v-

Field Oriented System Design Learning by Users’ Feedback 2021

第 1 章 背景と目的
1.1

背景

1.1.1

プロジェクトの立ち上げ

現在，世の中にはユーザのニーズに沿っていないシステムが存在する．この問題が発生する原因として，開発側が作るものとユーザ側が求めるものの認識のズレが挙げられる．この問題を解決するためには，フィールドを理解してシステムを開発する必要がある．そのため，開発側が実際の現場に赴きフィールド調査を行い，開発をすることを学ぶべきだと考えた．そこで，「使ってもらって学ぶフィールド指向システムデザイン」を理念とするプロジェクトを始めた．
（※文責: 木川裕太郎）

1.1.2

プロジェクトの方針

本プロジェクトは，例年実際に現場に赴くフィールド調査と，アジャイル開発手法の 1 つである
スクラム手法を採用している．フィールド調査ではユーザの思考や行動といった，現場に行かないと分からないことを知ることができる．また，スクラム手法では，プロダクトの制作と，制作物をステークホルダーに披露することなどをワンサイクルとして，そのサイクルを繰り返しながらユーザが求めるプロダクトに近づける手法である．ユーザのフィードバックを繰り返し受けて，改善する機会を何度も得ることができるため，本プロジェクトの「使ってもらって学ぶ」という理念と合致する．以上のことから，今年度もフィールド調査とスクラム手法を採用することにした．
（※文責: 木川裕太郎）

1.1.3

チームの背景地域 × 災害チームでは，IT を利活用することで函館市民の防災意識の向上を目指す．年々，大規模な災害によって被災する土地は増えている．2018 年には，北海道の胆振地方中東部を震源とする「平成 30 年北海道胆振東部地震」が発生し，道内の広い範囲に被害を及ぼした [1]．実際に函館市でもライフラインが止まり，市立学校などは臨時休校することになった [2]．それから約 3 年の月日が経過した現在，函館市は災害前と変わらない日常を取り戻している．しかし，現在の日常の中で大規模な自然災害から身を守るために，日頃から防災を意識している人々の割合は不確かである．例として，花王株式会社による防災意識に関する調査を挙げる．この調査では，被災経験ありの人と被災経験なしの人にそれぞれ「東日本大震災以降，防災の意識が高まったか」という質問をしている．この質問の結果，被災経験ありの人は 77 ％，被災経験なしの人は 66 ％の割合で「そう思う」，「ややそう思う」と回答した [3]．このように被災経験がない人は，自然災害を他人事のように扱う傾向がある．こういった問題は，実際に災害が発生してからでは遅い．災害が発生する
前に，防災意識を持ち，対策をする必要がある．

Group Report of 2021 SISP

-1-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021（※文責: 木川裕太郎）

1.2

目的

近年の函館市では，「平成 30 年北海道胆振東部地震」のように震度 6 や震度 7 といった大規模な自然災害を経験していない [4]．そのため，過去の記憶が薄まると共に，自然災害に対する意識も低くなっているのではないかと考える．そこで，本チームは学校で定期的に行われている避難訓練に着目した．近年，防災訓練の必要性は増しているが，実際に防災訓練に参加した割合は低い [5]．
防災訓練に対する意識が変われば，防災意識にも変化があると考える．また，子どもから大人へ防災に対する意識を共有することで，世帯ごとの防災意識の向上を期待する．加えて，恒常化しつつある防災訓練を一新することで，子どもが防災訓練を通して防災に興味を抱くのではないかと考える．これらのことから、函館市の子どもたちが関心を抱く防災学習を立案し，函館市民の防災意識が向上することを目的として活動する．
（※文責: 木川裕太郎）

Group Report of 2021 SISP

-2-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

第 2 章 中間発表までの主な活動
2.1

リスク分析

プロジェクトが発足して直ぐに，チームビルディングの一環としてリスク分析を行った．リスク
分析は発生確率・影響度マトリックスを用いて各個人でリスクの洗い出しをした後に，個々のリスク分析を持ち寄って Google スプレッドシートにまとめ，コメント機能を用いて全体でレビューした (図 2.1)．また，個人作業の段階にて，履修カリキュラムの違いによりリスク分析および発生
確率・影響度マトリックスに関する知識を持たないメンバーが居たため，有志のメンバーによる「リスク分析勉強会」を行い，最初にリスク分析に知見のあるメンバーがリスク分析に関するレク
チャーを行った後，実際にリスク分析を行った．
実際のプロジェクト内で活かされたリスク分析の例として 「ドキュメントが分散してどこを参照して良いか分からなくなる」が挙げられる．これは Slack*1 や Discord*2 を始めとする様々なコ
ミュニケーションやタスク管理ツールを導入するうちに，必要な資料の所在が様々なツールに分散し使いたい時に資料の探索が困難になる可能性について言及したリスクである． このリスクの対策として「テキストでコンタクトを取るツールを自分たちで決定・限定して、いろんなツールに無暗に貼らないようにする」が “回避” の対策として提案され，該当のリスク分析に基づき，現時点においても Slack 及び Google Drive のみにドキュメントを集約し，作業用に作成した Discord
サーバーにもテキストチャンネルを原則作らないことで，ドキュメントを分散させる余地を作らない方針を継続している．

*1 https://slack.com*2 https://discord.com

Group Report of 2021 SISP

-3-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 2.1

メンバー全員のリスク分析をまとめた Google スプレッドシート (一部抜粋)（※文責: 吉田拓夢）

2.2

チーム分け

次の活動としてチーム分けを行い，函館市民の防災意識の向上を目指す「地域 × 災害チーム」，
高齢者の認知症問題，社会的交流不足による孤立問題などの改善を目指す「高齢者支援チーム」，
入手可能な情報と IT を用いて市民生活の改善を目指す「シビックテックチーム」の 3 チームに分
かれ活動を行った．すうぃふとプロジェクトでは，各チームが各チームの判断でフィールドを調査し、決定を行うことでプロダクトを制作する．私たちは，地域 × 災害チームとして活動を行うことにした．
（※文責: 吉田拓夢）

2.3

プロダクト決定までの活動

2.3.1

函館における防災活動の調査取り組むプロダクトを決定するために地域 × 災害チームでは始めに，函館における防災活動の調査を行った．各自で調査を行い結果をオンラインホワイトボードサービス「Miro*3 」を利用しま
とめた (図 2.2)．各自の調査の中では，函館の昔の災害として挙げられる「函館大火」や「函館市の公式の情報が整理されておらず見にくい」，「避難所情報の整理」などが問題点として挙げられ*3 https://miro.com

Group Report of 2021 SISP

-4-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
た．さらに調査だけでは防災に関する知識は少なく，実際に函館で防災活動をしている方にお話を伺いたいと思い，南部美砂子准教授から現段階で行われている函館の防災活動に関してレクチャーをいただいた．レクチャーでは，函館で防災活動を行っている「函館女性会議」という団体について教えてもらい，ヒアリングを行うことを決定した．

図 2.2

函館の防災活動や災害情報に関する調査の Miro（※文責: 吉田拓夢）

2.3.2

函館女性会議へのヒアリング

函館女性会議 [6] とは 1986 年に函館市教育委員会から発足した，女性の地位向上，男女雇用均等など，男女参画社会を作るために活動している団体である．ヒアリングでは会長の佐々木香氏から「なぜ防災活動を行っているのか」，「今まで行ってきた防災活動と函館の防災意識の現状」について教えていただいた．函館の防災意識について自由に意見交換することで，「未災地の防災」，「子
どもに向けた防災デバイス」などのキーワードが出た．ヒアリング後，佐々木香氏へのヒアリングの内容と自分たちが調査した内容を照らし合わせながら，函館で防災に関してどんなことができるのか，必要なのかを Miro を利用し，再度議論を行った (図 2.3)．Miro を使った議論では，佐々木香氏へのヒアリングの中で出てきた，まだ災害が起こっていない地域での防災活動の少なさや未災
地の防災，子どもへの防災教育に取り組むことで，親世代へも防災について考えてもらえるのではないかなど，様々な議論が行われた．議論した内容について，実際に函館のコミュニティや活動に詳しく，函館に長く住んでいる人の意見をもらうために，Code for Hakodate の中村拓也氏にヒアリングを行うことを決定した．

Group Report of 2021 SISP

-5-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 2.3

函館女性会議へのヒアリングの内容に関する Miro（※文責: 吉田拓夢）

2.3.3

Code for Hakodate へのヒアリング

Code for Hakodate[7] とは「ICT を中心とした函館をちょっとよくするきっかけづくり」をコンセプトに函館のさまざまな問題の解決に取り組む団体である．ヒアリングでは，自分たちが調査してきた函館の防災に関する問題，函館女性会議へのヒアリングでの内容について説明を行い，「教育に携わっている立場」，「函館で地域課題解決に携わっている立場」，「函館に長く住む有識者としての立場」の 3 つの立場から意見をいただいた．中村拓也氏からは「集めた情報をアーカイブ化する利点」，「ついついやってしまうことをうまく引っ張り出して体験に落とし込む」，「一つの事
象を色んな方向性から名前をつける」など、アイデアに対する意見をいただいた．
（※文責: 吉田拓夢）

2.3.4

テーマの決定中村拓也氏へのヒアリング内容を精査し，各自が現在まで挙げられてきた取り組みたい内容や問題に関して，今までの Miro を振り返りリアクションを付け合った．各自がリアクションを付け合うことで，メンバーが気になっているテーマや問題について相互理解を深めた．さらに，リアクションから各自が取り組みたい問題や掲げたいテーマを挙げ，議論を行うことでテーマの決定を行った．佐々木香氏、中村拓也氏へのヒアリングでもテーマとして上がっていた「子供への防災教育」というテーマに着目した．注目した理由として函館市民の防災意識の向上を目指すために，幼少期から防災に関する知識や意識を持つことが重要と考え，子供たちの防災意識が親世代にまで普及するのではないかと考え、このテーマに着目した．その後テーマに関してさらに議論を行い，「函館市民の防災意識の向上を目指し，子どもたちが関心を持つ防災学習を立案する」というテーマを定めた．

Group Report of 2021 SISP

-6-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021（※文責: 吉田拓夢）

2.4

プロダクトの決定

テーマからプロダクトを決定するため，実際にどんなものを作れるのかについてブレインストー
ミングを行い，「インタラクティブビデオ」，「矢印デバイス」，「避難 RTA(Real Time Attack)」の3 つにアイデアをまとめた．まとめたアイデアに対して，「やりたい（おもしろい）」，「やるべき（需要）」，「やれる（データ入手、実装技術）」の観点から考え，お互いのアイデアに対する認識の共有を図った．3 つのアイデアの中でも避難 RTA では「 IoT を絡ませた新しい避難訓練」，「ライフログを取ることができる」，「現行の避難訓練よりも実践的」など 3 つの観点全てにおいて多くの意見が出たことで，子どもが関心を持つ内容の防災教育であり，遊びとともに知識をつけることができる IoT を絡ませた新しい避難訓練「避難 RTA」にプロダクトを決定した．
（※文責: 吉田拓夢）

2.5

プロダクト具現化

2.5.1

エレベーターピッチの制作決定したプロダクトを具現化していくため，始めにエレベーターピッチを活用しチーム内のテーマを決定した．エレベーターピッチとは短時間で自分の意見を的確に伝えるプレゼンのことであり，今回エレベータピッチのテンプレートを使用し，自分たちのプロダクトに関して短い文章で具現化を行った．エレベーターピッチを作成することでチームとしてプロダクトに関して共通の認識を持つことができた．制作したエレベーターピッチの詳細は 5.2 節で述べる (図 2.4)

図 2.4

エレベータピッチ（※文責: 吉田拓夢）

Group Report of 2021 SISP

-7-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

2.5.2

ペルソナの決定エレベーターピッチの制作過程で，今回のプロダクトのユーザーに関する議論になり，プロダク
トのターゲットユーザーに関する決定を行うため，ペルソナの設定を行った．ペルソナとはサービス・商品の典型的なユーザー像のことであり，実際にその人物が実在しているかのように，年齢，
性別，居住地，職業，役割，趣味などを細くリアリティのある詳細の情報を設定する．ペルソナを設定することでチームの中のユーザー像を明確化し，ユーザーに必要なプロダクトや機能の選定を行うことができるようになった．決定したペルソナの詳細は 5.3 節で述べる (図 2.5)．

図 2.5

ペルソナシート（※文責: 吉田拓夢）

2.6

中間発表

中間発表は 7 月 9 日金曜日の 15:00∼18:00 に Zoom を用いて行われた．発表では事前に提出物として提出したポスターおよび Web サイトを使用し，現段階でのプロダクトに関して発表が行われた. 地域 × 災害チームに関するフィードバックとして，「避難訓練を楽しくというのが、おもしろいと思った」，「目的が立案がゴールのように感じる」，「最終的な制作物まで明確に想定されていて非常に分かりやすかった」等のフィードバックがあった．フィードバックを基にさらにプロダク
トに関して細部まで具現化し，機能やどのように行うかなどを明確化する必要があり，そのために議論を行っていくことが夏季休業中の目標となった．
（※文責: 吉田拓夢）

Group Report of 2021 SISP

-8-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

第 3 章 夏季休暇中の活動
3.1

夏季休暇での活動方針

中間発表では，作りたいプロダクトの内容についておおまかに決まっていただけだったので，プロダクトの詳細について夏季休暇で決めることにした．避難訓練を楽しくしたようなゲームを考えるにあたって重視することや，ゲームに使うデバイスを決めて，夏季休暇終了後には開発に入れるよう活動を行った．
（※文責: 海野芽美）

3.2

プロダクトの詳細決め

3.2.1

類似サービスを調査

プロダクトの詳細を決めるにあたって，類似サービスや防災学習での ICT 活用事例の調査を行った．メンバー各自が調べたあとに，Miro を利用して調べたことの発表を行った．調査の結果，サービスに共通して小学生が実際に体を動かすような特徴がみられた．また，ICT 活用事例では，

ICT によって災害をリアルに表現してユーザに災害を疑似体験させるような事例が多かった．(図
3.1)

図 3.1

類似サービスを調査したときの Miro（※文責: 海野芽美）

Group Report of 2021 SISP

-9-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

3.2.2

函館市立えさん小学校訪問

小学生が実際にどのような防災学習を行っているか知るために，函館市立えさん小学校に訪問した．訪問では，「小学校での防災活動はどのように行っているのか」，「小学生が興味をもてるようなものは，どのようなものか」などについて意見を教えていただいた．そこで，小学生の防災学習
は，学習指導要領の総則に従って行っていることが分かった．また，訪問時点でのプロダクトについて紹介して，防災学習での IT 活動についての意見をいただいた．その結果，防災学習に IT を利活用することは良いことだが，訓練と IT は切り離して考えたほうが良いということが分かった．

3.2.3

プロダクトの機能

避難場所を目指しながらクイズを解くゲームを作成することにした．ユーザはクイズを解くのにスマートフォンを利用することにした．そして，避難中の行動経路や，歩行速度をスマートフォン
で記録してユーザが取りやすい行動のデータを収集することを考えた．

3.2.4

デバイス決定使用するデバイスは，iOS スマートフォンと，Android スマートフォンを利用することにした．
スマートフォンを選んだ理由は，開発のしやすさと，小学生にとって身近にあるものだからである．

3.2.5

ユーザーストーリーマップ作成

Miro を使って，ユーザーストーリーマップを作成した (図 3.2)．ユーザーストーリマップは，
Miro のテンプレートにあるプロダクトバックログとユーザーストーリーマップが一緒に表示されているものを採用した．この段階では，障害物がある避難訓練のようなプロダクトを想定していた．具体的に，児童が避難場所を目指しながら，割れたガラスや，火災が起きている教室がある状況下で適切な対処をしながら避難をするフローになっていた．その間に，児童の歩行速度や，どのように避難したか，どのような行動をとったかのデータを収集して振り返りとしてフィードバックを返すような想定をしたユーザーストーリーマップだった．
（※文責: 海野芽美）

3.3

技術習得

3.3.1

GitHub・スクラム講習会

8 月下旬にプロジェクト全体で GitHub・スクラム講習会を行った．GitHub 講習会は，メンバーの中で Git を使い慣れている人が講師役になって行った．そこでは，Git とは何かや，ブランチの切り方，GitHub 上のリポジトリに各自の手元で作ったファイルを反映してプルリクエストを出す方法などといったような基本的なことを学んだ．GitHub 講習会のあとにスクラムマスターが講師役になってスクラム講習会を行った (図 3.3)．この講習会では，実践的なスクラムを開始する前にスクラムの振り返りや，より具体的なプロダクトゴールや，スクラムでの責任についてのレクチャーを受けた．

Group Report of 2021 SISP

- 10 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 3.2 Miro 上で作成したユーザーストーリーマップ

図 3.3 GitHub・スクラム講習会の様子

Group Report of 2021 SISP

- 11 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021（※文責: 海野芽美）

3.3.2

UCD ワークショップ

9 月下旬に希望するメンバーで UCD ワークショップに参加した．UCD ワークショップとは、
enPiT という高度 IT 人材の育成を目指している取り組みの一つである。このワークショップでは、大阪芸術大学の木塚あゆみ先生を招いて人間中心のデザインの考え方とその設計方法を短期集中の講義および演習を通して学んだ。
（※文責: 海野芽美）

3.3.3

FizzBuzz アプリケーション作成

各自の技術力の確認とネイティブアプリでプロダクトを作る練習として，iOS 担当と Android
担当に分かれて FizzBuzz アプリケーションを作成した．FizzBuzz アプリケーションとは，画面をタップすると，数字が 1 ずつ増えて，3 の倍数で「Fizz」，5 の倍数で「Buzz」，15 の倍数で「FizzBuzz」と表示するアプリケーションである．それぞれ作成した後は，相互にレビューを行った．また，FizzBuzz アプリケーションを通してプルリクエストへのレビュー方法も学ぶことができた．
（※文責: 海野芽美）

3.4

開発方針決め

3.4.1

開発形態

開発は，デザイン班 2 名，コーディング班 3 名に分かれて行うことにした．iOS と Android のクロスプラットフォームで開発を行うため，学校から MacBook と iOS 端末を借りた．開発環境
は，各自で必要に応じて Xcode や Android Studio をインストールして整えた．
（※文責: 海野芽美）

3.4.2

縮小スクラム導入決定

本格開発でスクラムを導入するための練習の一環として，縮小スクラムを行うことにした．縮小
スクラムでは，スプリントプランニング，スプリントレトロスペクティブ，デイリースクラムのみを行った．また，1 スプリントは 1 週間とした．デイリースクラムは，土日を除いて毎日 20 分間
同期型で行うことにした．これらのスクラムの用語については，4.1 節で述べる．スクラム導入にあたって「Jira Software*1 」という Web アプリケーションを使うことにした．導入の主な理由は，メンバーが行っていたインターンで使われていて利便性が良いからである．Jira Software についての詳細は，4.1.1 節で述べる．

*1 https://onl.la/9HyU1a2

Group Report of 2021 SISP

- 12 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021（※文責: 海野芽美）

Group Report of 2021 SISP

- 13 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

第 4 章 後期活動内容
4.1

スクラム

効率的でユーザのニーズに合った開発を行うためにスクラムを導入した．スクラム運用期間は，2021 年 9 月 23 日から 2021 年 11 月 26 日までだった．また，この期間のうち 2021 年 9 月 23 日
から 2021 年 10 月 6 日までは，縮小スクラムとして，スクラムを簡略化したものを導入していた．
このスクラム運用期間には，プロダクトの大幅な改変や，成果発表会のためにスプリントを停止した期間も含まれている (表 4.1)．
スプリント全体期間

2021/9/23 ∼ 2021/11/26

縮小スクラム期間

2021/9/23 ∼ 2021/10/6
スプリント 12021/9/23 ∼ 2021/9/29

スプリント 22021/9/29 ∼ 2021/10/6

2021/10/6 ∼ 2021/11/26

本スクラム期間

スプリント 12021/10/6 ∼ 2021/10/13

スプリント 22021/10/13 ∼ 2021/10/20

スプリント 02021/10/22 ∼ 2021/11/5

スプリント 32021/11/5 ∼ 2021/11/12

スプリント 42021/11/12 ∼ 2021/11/19

スプリント 52021/11/19 ∼ 2021/11/26

表 4.1

スプリント期間一覧（※文責: 海野芽美）

4.1.1

ツール

Jira SoftWare
Jira Software はアジャイル開発のためのプロジェクト管理ツールである．ロードマップを表示する機能や，バックログを管理する機能などがある．Jira Software は，9/23 ∼ 9/29 までの縮小
スクラム期間から導入した．
（※文責: 海野芽美）

Planning Poker Online
スプリントプランニングでタスクの工数の見積もりをするのに，Planning Poker Online*1 という Web アプリケーションを利用した．これらはプランニングポーカーを行うためのサイトでメン*1 https://planningpokeronline.com/

Group Report of 2021 SISP

- 14 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
バーが出した工数見積もりの平均を自動的に出す機能がある．基本的に全スプリントでこのツールを使ってプランニングをした．
（※文責: 海野芽美）

4.1.2

デイリースクラム

デイリースクラムは，1 回 20 分間の同期型で Discord を用いて行っていた．最初は，口頭で各自の状況を言っていくような形式をとっていたが，もっと効率的に行うために非同期型のデイリー
スクラムと組み合わせた形になった．非同期型のデイリースクラムを一部取り入れたものでは，デイリースクラムの時間に集合したら各自 Slack にその日までにやったこと，次にやること，問題点を書く．そして，互いに内容を確認して気になった部分だけを取り上げて話し合うようにした (図4.1)．そして，デイリースクラムの終わりに，その日のデイリースクラムで決まったことをまとめたメモを Slack へ投稿していた．

図 4.1

デイリースクラムでのメンバーの投稿（※文責: 海野芽美）

4.1.3

スプリントプランニング

スプリントプランニングでは，スプリントバックログを作成してそのスプリントにやらなければ
ならないことの計画を立てた．Miro に作成したプロダクトバックログを，もっと細かい粒度にして Jira Software のバックログに落とし込んで，工数見積もりをつけた．そこで，工数見積もりはPlanning Poker Online というツールを使ってプランニングポーカーを行うことで決定した．
（※文責: 海野芽美）

Group Report of 2021 SISP

- 15 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

4.1.4

スプリントレトロスペクティブ

スプリントレトロスペクティブとは，開発チーム内でそのスプリントの反省を行うスクラムのイ
ベントである．私たちはスプリントレトロスペクティブを Miro 上で行った (図 4.2)．Miro 上で

Tweet（つぶやき），Keep(よかったこと)，Problem(問題点)，Next(次にやること) を付箋で書いていく方式をとった．Tweet で私的な近況や，予定なども書くので互いの状況がわかりやすくなったり，会話が生まれてチームビルディングにも役立った．例えば，就職活動やアルバイトが忙し
い，遊ぶ予定があるなどのプロジェクト外の状況を共有したり，最近買ったものや食べたものを共有したりした．実地試験前のような開発が大変になる時期になると雰囲気が殺伐としてしまいそうになっていたが，このような会話で雰囲気がよくなった．

図 4.2 Miro 上で行ったスプリントレトロスペクティブの様子（※文責: 海野芽美）

4.1.5

スプリントレビュー

スプリントレビューは，そのプロジェクトでの成果を先生，TA，函館市立えさん小学校の先生に発表してレビューを受けた．スプリントレビューは，毎回 Zoom でおこなった．外部の方がいるのでスクラムの用語や，開発の用語などわかりにくい単語を使わないように意識して活動を行った．
（※文責: 海野芽美）

4.2

各スプリントでの活動

4.2.1

縮小スクラム縮小スクラムは，スクラムの練習として 2021 年 9 月 23 日から 2021 年 10 月 6 日までで開催した．

Group Report of 2021 SISP

- 16 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

スプリント 1(9 月 23 日 ∼9 月 29 日)
スプリントゴールは特に設定せず，スクラムを試してみることを重視してできそうなタスクから
スプリントバックログに入れて開発を行った．このスプリントで自分たちが開発しているプロダ
クトの名前「DID IT」が決定した．このプロダクト名は，英語で避難訓練という言う意味の熟語「Disaster Drill」とやったねという意味の熟語「Did it」を組み合わせて作られた．スプリント 1
では，プランニングでタスクをスプリントバックログに入れすぎて土日稼働前提のタスク量になってしまったり，レビュー体制が整っていなくてレビューが進まなかったりした．また，見積もりよ
りも工数がかかってしまうことがあった．ここで問題になったレビュー体制については，受け入れ要件を明確にすることで解決した．例えば，プログラムのレビューだったら，コーディング班 3 名のうち熟達者 2 名どちらかを必ず含む 2 名の承認を受け入れ要件とした．
（※文責: 海野芽美）

スプリント 2(9 月 29 日 ∼10 月 6 日)
スプリント１と同様にスプリントゴールを設定しなかった．このスプリントでは消費できた工数は増えたが，割り込みタスクが増えてバックログを消費しきれなかった．この反省を踏まえて，プランニングポーカーをしないでスプリントバックログにタスクを追加することを制限することにした．このスプリントでは，本格的なスクラムの導入でスプリントレビューを開催することに備えてステークホルダーとして函館市立えさん小学校にコンタクトをとる計画を立てた．
（※文責: 海野芽美）

4.2.2

本スクラム

縮小スクラム期間を経た後，本格的なスクラムへ移行した．
スプリント 1縮小スクラムでの学びを基にしながら，本格的な開発タスクを入れ込んだスプリントを計画した．また，チーム外でスプリントレビューを行う初のスプリントである予定だったが，スプリント
レビューのための準備体制やフォーマットが整っていなかったこと，新型コロナウイルスワクチ
ンの接種による副作用でプロダクトオーナーとスクラムマスターがスプリントレビュー時に欠席となってしまったことから次スプリントに見送りとなった．ここでの反省を機に，スプリントレ
ビューで紹介する該当スプリントの成果物をまとめた「リリースノート」の作成 (図 4.3，4.4) や，スプリントレビューの段取り文書化の取り組みが行なわれた．

Group Report of 2021 SISP

- 17 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 4.3Group Report of 2021 SISP

リリースノートのテンプレート (1 ページ目)- 18 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 4.4

リリースノートのテンプレート (2 ページ目)（※文責: 木川裕太郎）

Group Report of 2021 SISP

- 19 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

スプリント 2
地域 × 災害チームにとって重要なステークホルダーである，函館市立えさん小学校の教頭先生
へのプロダクトの説明とスプリントレビューへの参加の依頼を目的としたミーティングを中間目標としてスプリントを行なった．ステークホルダーの獲得や，プロダクトについての外的な資料の原形の完成などが成果として挙げられる．その一方で，函館市立えさん小学校の方から，座学でやる防災学習と，地域 × 災害チームのプロダクトとの明確な違いが欲しいという指摘を頂いたこと，自分たちで開発を進めていく内にプロダクトの意義や特徴が弱くなってしまっていたこと，函館市
立えさん小学校の先生とのスケジュールの調整の必要性といった理由から，通常のスプリントを一旦停止した上で，プロダクトコンセプトの練り直しや，基礎開発及び先行デザインタスクのために費やす「0 スプリント」を設けることにした．また，残りの開発期間やプロダクトの進捗状況か
ら，チーム間での認識の齟齬による無駄をなくすために「スクラムマスター・プロダクトオーナー
会議」を週１回設けることに決定した．これにより，スクラムマスターとプロダクトオーナーでのビジョンを固め，チームの方針をより強固なものにすることを図った．
（※文責: 木川裕太郎）

スプリント 0前スプリントの反省を生かし，プロダクトのアイデンティティを再構成するためにユーザース
トーリーの練り直しからやり直しを行なった．ここで，教室内に設置された日常生活にありふれた道具と防災学習の関連性を特徴とした「アイテムクイズ」の構想が生まれ，DID IT の新たな特徴を生み出すことができた．また，スクラムマスターが日替わりでイラストを見せながらデイリー
スクラムを行う「デイリーお絵かき」の取り組みを行うなど (図 4.5)，スクラムの各イベントのブ
ラッシュアップが行なわれた．

図 4.5

Group Report of 2021 SISP

デイリーお絵描きの一例- 20 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021（※文責: 木川裕太郎）

スプリント 30 スプリントでの基礎開発を踏まえて，再び本格的な開発に突入した．縮小スプリントやプロダクト再設計前のスプリントの経験が積み重なったことにより，スプリントのシステムが安定してきており，チーム開発環境が整ったスプリントであった．このスプリントでのスプリントバックログ
項目の達成状況は図 4.6 の通りである．

図 4.6

スプリント 3 スプリントバックログの達成状況（※文責: 木川裕太郎）

スプリント 4
開発ペースがどんどん上がっていき，スクラムにおける作業消化の尺度を示すベロシティが最も高くなったスプリントであった．プロダクトが形になってきた部分が多くなったので，開発中アプ
リ配布サービスである DeployGate*2 を用いて，ステークホルダーの手元でもアプリを実際に触れるようにした．このスプリントでのスプリントバックログ項目の達成状況は図 4.7 の通りである．

*2 https://deploygate.com/

Group Report of 2021 SISP

- 21 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 4.7

スプリント 4 スプリントバックログの達成状況（※文責: 木川裕太郎）

スプリント 512 月 3 日に予定された函館市立えさん小学校での実地試験を控えた大詰めのスプリントとなった．実地試験を想定したチーム内での試験運用や，それを基にした細かいバグの修正，及び実地試
験のための運用マニュアルの作成に取り組み，実地試験運用に向けてプロダクトの完成度を高めた．このスプリントでのスプリントバックログ項目の達成状況は図 4.8 の通りである．

図 4.8

スプリント 5 スプリントバックログの達成状況（※文責: 木川裕太郎）

4.3

HAKODATE アカデミックリンク 2021

4.3.1

概要

11 月 26 日より開催された HAKODATE アカデミックリンク 2021 にすうぃふとプロジェクトの全 3 チームそれぞれが出展した．発表形式は 2 つあり，ライブ形式で発表するステージセッショ

Group Report of 2021 SISP

- 22 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
ンか，ポスターもしくはスライドを展示するブースセッションが選べた．私たちのチームは，スライドを展示するブースセッションを選択した．この時，アプリケーションの開発は進んでいなかったので，説明ではゲームのフローの説明や，ゲームの狙いについてスライドに記載した．

4.3.2

発表内容と結果

発表では，児童向け防災学習レクリエーションシステムとして DID IT を紹介した．スライドには，DID IT 開発に至ったきっかけ，DID IT の説明，今後の展望を載せた．その結果，審査員特別賞を受賞した．12 月 14 日にこの賞の表彰式が行われた（図 4.9）
．そこで，副賞を受け取った．

図 4.9

表彰式の様子（※文責: 海野芽美）

4.4

実地試験

4.4.1

1 回目実地試験

12 月 3 日に函館市立えさん小学校で DID IT の実地試験を行った．4 年生 7 人，5 年生 8 人で小学校の 4，5 時間目通しで 95 分間を使って行った．対象学年として 4，5 年生を選んだ理由は，
これまで学習した知識や経験を生かすような学習ならば高学年のほうが良いという函館市立えさん
小学校の先生のアドバイスがあったからである．6 年生にしなかった理由は，6 年生の 1 クラスあたりの人数が少なく，4，5 年生は 2 学年 1 クラスで人数の都合が良かったためである．
実地試験前事前準備

1 回目実地試験では，実地試験の準備はおよそ 1 か月前から行った．事前準備では，アプリケー
ションの開発を進めながら，実際に児童に解いてもらうクイズを作成したり，クイズを解く場所を決めたりした．まず，出題するクイズの内容を相談したり，校舎の下見をしたりするために 10 月

28 日に児童が帰宅した後の函館市立えさん小学校を訪問した．そのあとは，スプリントレビューの時に実地試験について利用可能な教室や，アイテムクイズに使うアイテムについてどのように準備するかを決めていった．実地試験前日には，ビーコンの動作確認や，実地試験当日に協力してくGroup Report of 2021 SISP

- 23 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
ださる先生と当日の動きについて打合せを行った．実地試験当日は，学校へ到着して昼食を食べた
後にアイテムクイズの設置や利用予定のスマートフォンを函館市立えさん小学校の Wi-Fi へ接続する作業をした．
実地試験の内容
最初に児童にスライドを使って自己紹介をして DID IT のルールやアプリケーションの操作方法を説明した（図 4.10）．実地試験では，アイテムクイズ 4 つ知識クイズ 4 つの計 8 問の問題を出題
した．小学校には児童が入ってはいけない教室もあるので，扉が開いている教室，もしくは DID

IT のロゴマークが書いてある教室にならば入ってよいことにした．アイテムクイズは，教室の前にビーコンを設置して近くを通ったらスマートフォンが反応してアイテムクイズがとけるようにした．

図 4.10

実地試験で児童にゲームについて説明している様子

結果
児童に楽しんでもらうことはできた．アンケートでは 80 ％以上の児童が楽しかったと回答していた．しかし，いくつか問題が発生した．まず，45 分でクイズを解き終わると想定していたが，15分ほど時間が過ぎてしまった．次に，スマートフォンの中にビーコンが読み取れない故障したス
マートフォンが一台あった．また，反応をしないわけではないが，ビーコンの反応速度，もしくは強度が弱く近くに行って数分待たないとスマートフォンが反応しないことがある端末があった．同Group Report of 2021 SISP

- 24 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
じように機械トラブルだと，ゲーム中にサーバーとの回線が切れてしまってゲームが 5 分ほど中断してしまうことがあった．ゲームの内容のトラブルだと，知識クイズとアイテムクイズのルールを混同してしまってゲームがうまく始められないチームがあった．児童がクイズを考えないで解いてしまう場面があり，解説もあまり読んでもらえなかった．そのせいか，実地試験前と実地試験後の防災意識尺度の総合点の平均は，実施前 66 点 (小数点以下切り捨て)，実施後 68 点 (小数点以下切り捨て) であまり変化が見られなかった．
反省と改善案
想定よりも時間がかかってしまったのは，知識クイズのうちの１つを児童がゲーム開始した後に初めに説明をしていた部屋の後ろに後から設置したためそのクイズだけ見つけられなかったようである．防災学習と違うところで難易度を上げてしまったので，今後この配置の仕方は避けることにした．機械トラブルのうち，端末の故障については該当端末を次回実地試験に使わないようにする．サーバーとの回線が切れてしまったのは，メンバー側で外部のアプリケーションを使ってデー
タベースにアクセスして進捗を確認しようとしたところポートがふさがってしまったのではないかと思われる．自分たちで児童の進捗を監視する Web アプリケーションを作成することでこれを解決する．児童にとってルールがわかりにくい部分があったことへは，知識クイズを廃止してアイテ
ムクイズのみにすることでルールをわかりやすくすることで対処する．クイズの解説を読んでもらえない問題は，解説にアニメーションを追加して児童が次の画面に急いで移動してしまうことを防ぐことによって改善を試みる．また，運営として児童に接するときに，メタ的な発言をしてしまうと児童のゲームへの没入の妨げになってしまうので，メタ的な言動は避けようという意見が出た．
（※文責: 海野芽美）

4.4.2

2 回目実地試験

1 月 18 日に函館市立えさん小学校で DID IT の 2 回目である実地試験を行った．前回と同じく
4 年生 7 人，5 年生 6 人の計 13 名に参加して頂き，4 時間目の時間 45 を使用し行った．前回の実地試験のフィードバックからアプリやシステムを改良し，実地試験を行った．
前回からの変更点
クイズの変更前回実験では，知識クイズ 4 問，アイテムクイズ 4 問の計８問を児童たちには解いてもらうシス
テムであったが，前回よりも時間が短く，フィードバックや振り返りの中で，子供たちがアイテム
クイズと知識クイズの違いがわからず，ゲームをうまく始められない児童がいたこともあり，本実験では能動的に動くアイテムクイズのみでシステムを作る形となった．
ビーコン使用方法の変更

1 回目の実証実験では，アイテムクイズの開始方法として，ビーコンは教室周辺に行くとボタンが有効化され，ボタンを押してクイズ開始する方法を取っていたが，ビーコンが反応しづらく中々ボタンが有効化されない場合があった．さらにビーコンは教室前においてあり，児童が教室に入ってしまい，アイテムクイズを始めるために戻らなければいけないという事案もあった．2 回目実証
実験では，この問題を解決するため，ビーコンの検知範囲を狭くし，ビーコンに対して，スマートGroup Report of 2021 SISP

- 25 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
フォンをかざすことで，自動でアイテムクイズが開始される方式へ変更を行った．これにより児童
はクイズが開始されたことをはっきり認識することができ，問題を解き始めることができると考えた．
不正答数のカウントおよび解説用アニメーションの制作
前回の反省点として，問題文および解説文を読んでもらえていないという問題が挙げられた．要因として何度間違っても良い仕様，正答後に出る回答画面におけるフォントの小ささ，アニメー
ションの不足が挙げられた．本実験ではこの問題の解決策として，不正答数のカウント機能を追加した．実証実験では子供たちに対して，この機能の説明と間違わないようしっかり考えることを事前に知らせることで，間違っても進行する仕様ではあるが，なるべく正解するように子供たちが動くように促した．さらに問題正解時に出てくる解説文は，正解した答えの強調し，解説が画面が出てから数秒後に次に進むボタンを出すアニメーションを追加することで解説を読んでもらうようにした．
実地試験の内容

ICT 紹介
今回の実地試験では，DID IT を使ってもらう前に，未来大生が制作した Processing の作品を触ってもらう時間を取った．これはえさん小学校の教頭先生とのミーティングの中で，子供たちに

ICT に触れる機会を作ってほしいという要望に応え行ったものになる．児童には未来大生が一年次に制作した作品などを各 PC で動く状態にし，昼休みの時間を使用して遊んでもらった．
実地試験
前回同様最初にスライドを使用し，子供たちに改めてルールの説明を行い，前回からの変更点や新しくなったアプリの使い方，クイズの解き方を説明した．実地試験では，アイテムクイズを 6 つ配置し，アイテムがある教室には DID IT のロゴが書いた教室札を配置した．アイテムクイズを解く場合は，教室に入り，DID IT のロゴが貼ってある箱にスマートフォンをかざすことで，その教室のクイズが自動的に開始される．クイズを全て解き，バッジを 6 つ集めることでゴールに行くことができ，ゴールのビーコンにスマートフォンをかざすことでゴールである．児童にはゴールを解いた後，実験に関するアンケートに回答してもらった．
結果
児童のアンケートは時間内に書き終わらない児童もいたため，現在集計中で数値的な結果は得られていないが，前回に比べ円滑にクイズを解くことができ，問題をしっかり思考し，ゲームを進めていたように感じた．しかし，実験の進行において，児童が問題を解いた際，家庭科室，理科室のクイズに正解したのにも関わらず，バッジが取得できないという問題が発生した．問題発生時には原因が特定できず，このままではゴールができない状態であったため，未来大生が急遽該当教室の緊急用 QR コードを使用し，目の前で問題に正解してもらい，アプリ上のバッチの代わりに物理ア
イテムを渡すことでこの問題を解決した．
振り返りと反省
前回の反省点にあった，知識クイズとアイテムクイズを区別をアイテムクイズのみに絞ったことで，問題を解く過程で迷うことはなくなり，前回の問題を解消することができたと考える．さらにGroup Report of 2021 SISP

- 26 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
アイテムクイズ開始のトリガーとビーコンにスマートフォンをかざす動作にしたことで，児童がア
イテムクイズ開始をしっかり理解することができ，安心してクイズを解くことができた部分は評価できる．バッジが取得できない問題だが，前回の実験ではアイテムクイズが 4 つであり，コード側
で今回の個数である 6 つにバッチの取得個数を変更できていなかったことが原因であり，現在は既に対処済みである．バッジが獲得できないことで，児童が不安を感じたり，ゴールビーコンにス
マートフォンをかざす形式でゴールをしてもらうことができなかったのはとても残念だが，物理的なアイテムを用意し，ゲームの進行できなく終了する状態を避けることができたので良かったと感じる．前回でのトラブルの経験もあり，その場で状況を理解し，対応する力がついたと思う．
（※文責: 吉田拓夢）

4.5

成果発表

12 月 10 日に行われたプロジェクト学習成果発表会において，私たちはポスターと Web サイト
を使って発表を行った．Web サイトやポスターには，開発体制や作成しているゲームの推している機能を図を用いてわかりやすく簡潔に紹介した．その結果，フィードバックで Web サイトやポスターがわかりやすいというフィードバックを得ることができた．また，フィードバックもあり，AR で災害を表現するのを取り入れるのはどうかという提案もあった．
（※文責: 海野芽美）

4.6

enPiT BizSysD 北海道・東北合同発表会

12 月 18 日に enPiT BizSysD 北海道・東北合同発表会が Gather(*3 ) 上で行われた．この発表
会には，UCD ワークショップに参加したメンバーだけで参加した．発表は前半後半に分かれていて，ブースで前半もしくは後半に発表を行う形式だった，そこでの発表資料は最終成果発表会で使った Web サイトとポスターを再利用した．この発表会は他大学と合同で行ったが，あまりほかの大学から聴衆が来なかった．ただ，自分たちも他の大学の研究や発表技術を見ることができて勉強になった発表会だった．
（※文責: 海野芽美）

4.7

最終報告書

最終報告書は，担当教員からグループで一気にレビューを出すとレビューを返すのが遅れるかもしれないので早めにレビューに出すようにというアドバイスをいただいた．しかし，計画を立てるのが遅れてしまい，レビューを出すのが遅くなってしまった．また，2 回目実地試験の開発と並行して行わなければならないのでスケジュール管理が余計に難しくなってしまった．
（※文責: 海野芽美）*3 https://www.gather.town/

Group Report of 2021 SISP

- 27 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

第 5 章 プロダクト
5.1

プロダクト概要

本チームでは，函館市の子どもたちが関心を抱く防災学習を立案し，函館市民の防災意識を向上させることを目的として活動している．子どもに着目した理由として，子どもから大人へ防災に対する意識を共有することで，世帯ごとの防災意識が向上すると考えたからである．また，子どもたちが防災に関心を抱きやすいように，恒常化しつつある防災学習を一新しようと考えた．そこで本チームは，防災学習にゲーム要素を取り入れた「DID IT」を考案した．ゲーム要素を取り入れる
ことで，子どもたちが防災学習を能動的に行うと考えた．そこで，防災学習をクイズ形式にして子どもが取り組みやすい構造にした．さらに，クイズを学校中に設置して子どもたちに自由に探索してもらうことで，防災学習に対する関心が高まると考えた．このプロダクトではクイズが QR コー
ド*1 やビーコンとして設置してある．そのため，子どもたちはスマートフォンを使って QR コードを読み取ったり，ビーコンが検知される場所を探したりしなければならない．このようにスマートフォンをゲームアイテムのように位置づけ，現実 (学校探索) と仮想的な空間 (スマートフォン内の操作) に関連性を持たせることで防災学習に没入感を与えた．この「DID IT」を用いた実地試験は2 回行っており，それぞれの実地試験で取り入れた機能は異なる．
（※文責: 藤田華奈）

5.2

エレベーターピッチ

プロダクトについて掘り下げを行い，チームとしてプロダクトに関する共有認識を持ち，細かい方針を定めるためエレベーターピッチを作成した．これは，以下の 7 つの項目を明確にして決めるものである．

1. 潜在的なニーズを満たしたり、解決したい課題
2. 対象顧客は誰か
3. プロダクト名は何か
4. プロダクトのカテゴリーは何か
5. プロダクトが持つ重要な利点、最大の長所は何か
6. 代替手段、競合相手との違いは何か
7. 差別化の決定的な特徴は何か本チームでは，以下のように決定した．

1. 防災学習に楽しさを取り入れ，防災意識の向上を目指す
2. 函館の子供
3. DID IT*1 QR コードは株式会社デンソーウェーブの登録商標です.

Group Report of 2021 SISP

- 28 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
4. 校内探索型防災学習ゲーム
5. ユーザが防災学習に関心を持ち，防災意識を高めることができる
6. 従来の防災学習
7. 子どもに楽しんでもらえる要素や、参加者同士で自発的に防災についての話し合いが起こる
ような工夫が備わっている（※文責: 藤田華奈）

5.3

ペルソナシートの作成

エレベーターピッチが決定したあとはペルソナシートを作成した (図 2.5)．ペルソナシートとは，ユーザの具体的な人物像の情報をまとめたものである．ペルソナシートを利用することで，プロダクトを提供するユーザ像をイメージしやすくなる．本チームでは，ペルソナシートを作成することで，ユーザ像を明確化してユーザに必要なプロダクトや機能の選定が可能になった (図 2.5)．
（※文責: 藤田華奈）

5.4

USM

アプリケーションを開発する前に，ユーザーストーリーマッピング (以下 USM) を行い，ユー
ザーストーリーマップを作成した (図 5.1)．ユーザーストーリーとは，システムの開発を行う際に必要なユーザの要望や役割，ゴールなどの要求事項のことである．これらを把握することで，ユー
ザの要求事項に沿って開発を進めることが出来る．そして，USM とはユーザーストーリーを時系
列と優先度に沿ってマッピングしたものである．USM を活用することで，適切な開発順序を決めることができ，チーム内での共通認識も図りやすくなる．本チームでは，3 つの段階を踏んで USMを作成した．

図 5.1

5.4.1

作成したユーザーストーリーマップ

ユーザの行動を明確化する

イベントの時系列順にユーザの行動を書き出し，明確にした (図 5.2)．例として，イベント開始
前には教室でイベントの説明を受ける。このようにユーザの行動について分析することで，より正Group Report of 2021 SISP

- 29 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
確な要求事項を把握することができた．

図 5.2

5.4.2

明確化したユーザの行動を一部抜粋

ユーザの価値を明確化する明確にしたユーザの行動は，ユーザにどのような価値を与えるのかについて書き出した (図 5.3)．
例として，児童はイベントの説明を受けると，イベントを理解して没入することができる．このようにユーザが得られる価値を書き出すことで，必須の機能と応用的な機能を分けて考えることがで
きた．

図 5.3

5.4.3

明確化したユーザの価値を一部抜粋

必要な機能を明確化する書き出したユーザの行動と価値を基に，実装すべき機能を書き出した (図 5.4)．例として，イベ
ント開始時に必要な機能として，ゴール画面表示 UI の実装などが挙がった．このように必要な機能を書き出すことで，今後の見通しが立ち，スケジュールを考えながら開発を進めることができた．

図 5.4

明確化した機能を一部抜粋（※文責: 藤田華奈）

Group Report of 2021 SISP

- 30 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

5.5

画面デザインの決定

画面デザインを決定するために，画面遷移図を作成して一連の流れを可視化した (図 5.5)．画面
遷移図とは，アプリケーションの画面間の相互関係を 1 つの図にまとめたものである．画面遷移
図を作成することで，アプリケーションの全体像を掴み，必要な画面の洗い出しを行うことができる．本チームでは，まずデザイン担当のメンバーが大まかな画面遷移図を作成し，その画面遷移図
を基にアプリケーション全体の動作について話し合いを行った．その後，ユーザが使いやすいデザ
インについて検討した．その結果，ユーザの負荷を減らすために，シンプルかつ操作性の少ないデザインにすることに決定した．例として，画像と文字を配置することにより，ユーザが直感的に操作ができるようにした．各画面の詳細については 5.8 節で述べる．

図 5.5

作成した画面遷移図の一部抜粋（※文責: 藤田華奈）

5.6

クイズのコンテンツ決め

アプリケーションでクイズを出題するために，クイズのコンテンツを決めた．このとき，誤った情報を教えないように信頼性の高いコンテンツを集めた．本チームでは，全国労働者共済生活協
同組合連合会がサイト運営している「親子で学べる防災クイズ [10]」，自衛隊と防衛省の著書「自衛隊防災 BOOK[11]」，羽田道信氏の著書「防災・救急に役立つ日用品活用法＆ロープワーク 新版 [12]」，国崎信江氏が監修している「防災・防犯シミュレーション

大地震 そのときどうする？

[13]」，「ぼくらの災害サバイバル BOOK[14]」，今泉マユ子氏の著書「防災教室 身の守りかたが3 災害がおきたわかる本 [15]」，藤吉洋一郎氏が監修している「いのちを守る！ 災害対策大百科 ○らこうしよう！ -対処と行動編-[16]」の 7 つを参考にした．集めたコンテンツは Google スプレッ
ドシートにまとめてからチーム内で共有し (図 5.6，図 5.7)，クイズの状況に合うイラストの選定を行いながらコンテンツを決めた (図 5.8)．

Group Report of 2021 SISP

- 31 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 5.6

知識クイズをまとめたスプレッドシート

図 5.7

アイテムクイズをまとめたスプレッドシート

図 5.8

クイズ選定を記録したドキュメントの一部抜粋

Group Report of 2021 SISP

- 32 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021（※文責: 藤田華奈）

5.7

ゲームの流れやルールについて

まず，子どもたちにゲームの説明やルールの確認を行う．本チームではスライドをモニターに映しながら，プレゼンテーション方式で行った．このとき，子どもたちの安全性や起こり得るリス
ク，学校側の要望を考慮してルールを作成した (図 5.9)．説明が終わったあと，ゴール場所を示し
たスマートフォンが子どもたちに配られる．このゴール場所は，子どもたちがすべてのクイズに正解したあとに向かう最終目的地である．子どもたちがゴール場所を把握したあとは学校内を自由に探索し，クイズを解いてもらう．クイズの中には特定の場所でしか見つけることができないものがある．そのため，そこにクイズがあると分かりやすいようにオブジェクトを配置した．クイズの場所が分かりにくいと，クイズを解くことより学校を探索することに関心が傾く可能性があるからだ．また，このクイズではクイズの問題を見つけるだけでなく，答えとなるアイテムを探す必要がある．アイテムの近くには QR コードが設置されており，この QR コードを読み取ることでク
イズの選択肢が増えるシステムになっている．このようなシステムにすることで，疑似的にアイテムを獲得する楽しさを演出した．クイズに正解するとバッジを取得することができる．このバッジをすべて取得することがゴールの条件となる．クイズに正解し，すべてのバッジを取得した状態でゴール場所の QR コードを読み取るとゴールすることができる．

図 5.9

スライドのルール部分を抜粋（※文責: 藤田華奈）

5.8

開発済みの画面

本チームでは，大きく分けて「ゴール場所確認画面」，「メイン画面」，「クイズ画面」，「ゴール画
面」の 4 つの画面を作成した．画面の解説とそれぞれに加えた機能は以下である．

Group Report of 2021 SISP

- 33 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

5.8.1

ゴール場所確認画面

アプリケーションを起動させると，ゴール場所確認画面が表示される (図 5.10)．この画面では，子どもたちが最終目的地を確認することができる．班全員がゴール場所を確認したあと，「移動を開始する」と書かれたボタンを押すとメイン画面へ遷移する．このとき，メイン画面からゴール場
所確認画面に戻ることはできないため，子どもたちはゴール場所をしっかり覚えてから移動する必要がある．このような設計にすることで，むやみにボタンを押すことを防ぐことができると考
えた．

5.8.2

メイン画面

メイン画面は，1 回目の実地試験と 2 回目の実地試験で機能が異なる．1 回目の実地試験では，「獲得したバッチの表示」，「QR コードを読み取る」，「アイテムクイズに挑戦する」の 3 つの機能を実装した (図 5.11)．2 回目の実地試験では，「獲得したバッチの表示」と「アイテムクイズに挑戦する」の 2 つの機能を実装した．

図 5.105.8.3

ゴール場所確認画面

図 5.11

メイン画面

クイズ画面

クイズ画面は，「防災に関するクイズを出題する機能」がある．また，防災に関するクイズには「知識クイズ (図 5.12)」と「アイテムクイズ (図 5.13)」の 2 種類がある．各クイズの詳細は 5.9.2
節で述べる．

Group Report of 2021 SISP

- 34 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 5.12

図 5.13

5.8.4

知識クイズ画面

アイテムクイズ画面

ゴール画面

すべてのクイズに正解し，バッジを取得するとゴール画面が表示される．このゴール画面は，1回目の実地試験と 2 回目の実地試験で表示するゴール画面が異なる．1 回目の実地試験では，不正解の回数に関係なく子どもたち全員に同じゴール画面を用意した (図 5.14)．2 回目の実地試験では，「クイズの不正答数をカウントする機能」を実装し，不正解の回数に応じて異なるゴール画面を用意した (図 5.15，図 5.16，図 5.17)．各機能の詳細については，5.9 節で述べる．

Group Report of 2021 SISP

- 35 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 5.14 1 回目実地試験のゴール画面

図 5.15 2 回目実地試験のゴール画面 1

図 5.16 2 回目実地試験のゴール画面 2

図 5.17 2 回目実地試験のゴール画面 3（※文責: 藤田華奈）

5.9

アプリケーションの機能

本チームでは，実地試験を 2 回行っており，それぞれの実地試験で実装した機能が異なる．そのため機能の詳細については，「共通の機能」，「1 回目の実地試験で開発した機能」，「2 回目の実地試

Group Report of 2021 SISP

- 36 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
験で開発した機能」の 3 つに分けて述べる．

5.9.1

共通の機能

QR コードを読み取る機能
QR コードを読み取る画面を起動させ，学校内に設置した QR コードを読み取ることによって，指定した画面へ遷移したり特定の動作を呼び出したりする．DID IT では，指定のクイズを表示させたり，クイズの解答となるアイテムを取得するために QR コードを用いた．QR コードを活用
した理由としては，紙媒体からアプリケーションへの導線作り，現実と仮想的な空間に結びつきを持たせるためである．QR コードを読み取る画面は，journeyapps が提供しているオープンソース
ライブラリである ZXing Android Embedded*2 を使用して実装した．このライブラリを使用することで，QR コードを画像から簡単に読み取ることができる．また，QR コードを読み取るカメラを起動し，使用するための許可部分では EasyPermissions*3 を使用した．EasyPermissions とは，Android 6.0 以上から必要となったシステム権限に関する認証処理を簡略化するためのラッパーラ
イブラリである．
ビーコンを検知する機能

DID IT には，特定の場所でしか見つけることができないアイテムクイズがある．このとき使用したのがビーコンと呼ばれるデバイスである．ビーコンとは，低消費電力の近距離無線技術である「Bluetooth Low Energy」を利用した新しい位置情報特定技術およびその技術を使ったデバイスのことである [17]．また，発信する電波の強度を調節することで，特定の場所にコンテンツを送信することも可能である．例として，店舗の中にビーコンを設置すれば来店したユーザだけにクーポン
情報を通知することができる．さらに，ビーコンはスマートフォンでも検知することができ，安価である．これらの理由から，DID IT ではビーコンを利用することにした．子どもたちが特定の範囲へ入り，スマートフォンがビーコンを検知すると，「アイテムクイズに挑戦する」と書かれたボタンが有効になる (図 5.13)．2 回目の実地試験ではアイテムクイズを見つけたときとゴールすると
きに，NFC のようにスマートフォンをビーコンにかざす動作を加えた．この変更に伴い，ビーコ
ンの検知範囲を狭くした．また，検知回数を増やすことでスマートフォンがビーコンを検知する時間が早まると考えた．
バッジを取得する機能
クイズに正解すると，メイン画面にバッジが表示される (図 5.18)．クイズごとに異なるバッジを取得することができるため，クイズに解答する楽しさを増幅させる目的がある．また，クイズに正解して，バッジをすべて取得することがゴールできる条件であるため，条件が達成できているかを視覚的に確認することができる．2 回目の実地試験では改良を加え，バッジをタップするとどこで取得したバッジなのかが分かるようにした．この改良により，子どもたちが同じ場所を何度も探索する可能性を減らすことができると考えた．また，クイズの問題を新しいものに差し替えると同時に，バッジのデザインも一新した (図 5.19，図 5.20)．

*2 https://github.com/journeyapps/zxing-android-embedded*3 https://github.com/googlesamples/easypermissions

Group Report of 2021 SISP

- 37 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 5.18

バッジが表示されたメイン画面

図 5.19 1 回目実地試験で使用したバッジ

Group Report of 2021 SISP

- 38 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 5.20 2 回目実地試験で使用したバッジ（※文責: 藤田華奈）

5.9.2

1 回目の実地試験で開発した機能

知識クイズを出題する機能
知識クイズは防災に関する知識を問う問題であり，災害が起きたときの正しい行動について考えてもらうことを目的としている．知識クイズには，初めから問題文と解答の選択肢が表示されている．問題文にはいぢちひろゆき氏が提供しているイラストを取り入れ [18]，問題文が示す状況を想像しやすくした．正解の選択肢を選んだ場合は，選んだ回答と解説，「ほかのクイズを探す」と書かれたボタンが表示され，メイン画面に戻ることができる．不正解の選択肢を選んだ場合は，選んだ解答と「もう一度挑戦しよう」と書かれたボタンが表示され，クイズ画面に戻ることができる．
このとき，誤って同じ解答を選ばないように，1 度選択した解答は色が灰色になるようにした (図5.21)．

Group Report of 2021 SISP

- 39 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 5.21

選択した解答が灰色になっているクイズ画面

アイテムクイズを出題する機能
アイテムクイズは学校で災害が起きたとき，何を使って対処するのが最善かについて考えてもらうことを目的としている．そのため，実際の現場には学校の設備として置いてありそうな物をアイテムとして設置している (図 5.22)．アイテムクイズ画面には，初めに問題文とアイテム探索を促す文章，「QR コード読み取り」と書かれたボタンが表示されている．そのため，子どもたちは現実でアイテムを見つけ，QR コードを読み取り，解答の選択肢を増やす必要がある．このとき，解答の選択肢は取得したアイテム順に追加される．また，すべてのアイテムを取得すると，「QR コー
ド読み取り」と書かれたボタンが灰色になり，QR コード読み取りができなくなる．こうすることによって，アイテムをすべて取得したことが直感的に理解しやすくなると考えた．正解または不正解の選択肢を選んだ場合は，知識クイズ画面と同様の処理が行われる．

Group Report of 2021 SISP

- 40 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

図 5.22

実際に設置したアイテムの一例（※文責: 藤田華奈）

5.9.3

2 回目の実地試験で開発した機能

防災に関するクイズを出題する機能

1 回目の実地試験では「知識クイズ」と「アイテムクイズ」の 2 種類のクイズを用意したが，2 回目の実地試験では「アイテムクイズ」のみを用意した．その理由として，「知識クイズ」を表示す
る QR コードと，「アイテムクイズ」のアイテムを取得するための QR コードが混同してしまい，
非常に複雑なルールになってしまったためである．「アイテムクイズ」の主な機能は 1 回目の実地試験と変わらない．
クイズの不正答数をカウントする機能

1 回目の実地試験では不正解の回数をカウントせず，必ず正解するように誘導していた．その結果，子どもたちがあまり考えずに選択肢を選ぶ問題が浮上した．この問題を解決するために，2 回目の実地試験では不正解の回数をカウントし，その回数に応じてゴール画面の表示が変化するようにした（☆）．この改良により，子どもたちがクイズについて考え，チームで話し合いながら解答することに重きを置き直した．
（※文責: 藤田華奈）

5.10

使用した技術本チームでは，5 つの技術を使用してプロダクトを制作した (図 5.23)．以下で技術の詳細について述べる．

Group Report of 2021 SISP

- 41 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

5.10.1Android Studio

Android Studio*4 は，IntelliJ IDEA をベースとした Android アプリ開発用の公式の統合開発
環境 (IDE) である．IntelliJ の強力なコードエディタと開発ツールに加えて，Android アプリ作成の生産性を高めるさまざまな機能を利用できる．DID IT におけるアプリケーション開発で Kotlinと併用した．

5.10.2

KotlinKotlin*5 は，ジェットブレインズ社が Java 言語をより簡潔で安全になるように改良し，産業利用向けとして開発された静的型付けのオブジェクト指向プログラミング言語である．複数のプラッ
トフォーム間でコードを再利用することができ，生産性の高いプログラミングを実現する．DID

IT におけるアプリケーション開発で Android Studio と併用した．

5.10.3

PostgreSQL

PostgreSQL は，オープンソースのリレーショナルデータベース管理システム (RDBMS) である [19]．リレーショナルデータベース (RDB) は，データベースに入ったデータを別のデータベー
スのデータと関連付けることで，複雑なデータや大規模なデータを柔軟に取り扱うことができる．

RDBMS は，この RDB をコンピュータ上で操作できるようにした管理システムである [19]．DID
IT では，ゲームの監視と運用を行うデータベースを管理するために利用した．

5.10.4

DockerDocker*6 は Docker 社 (旧 dotCloud) が開発し，コンテナのアプリケーション実行環境を管理するオープンソースソフトウェアである。コンテナとは，実行環境を他のプロセスから隔離して，その中でアプリケーションを動作させる技術である．コンテナを用いることで，異なるサーバでも同じ構成の環境を簡単に構築することができる．このようなことから，Docker を利用するとアプリ
ケーションをコンテナにパッケージ化することができる [20]．DID IT では，データベースと API
をコンテナ技術により管理し，開発効率を向上させるために利用した．

5.10.5Go 言語

Go 言語*7 とは，Google 社が開発し，公開しているオープンソースのプログラミング言語である．コードを記述するときの簡潔さや理解のしやすさと，プログラム実行の高速性やリソース利用の効率性の両立を目指している [21]．DID IT では，データベースとアプリケーションの仲介を行うことと，データを json 形式に変換することの 2 つに利用した．

*4 https://developer.android.com/studio/intro?hl=ja*5 https://kotlinlang.org/docs/getting-started.html*6 https://www.docker.com/*7 https://go.dev/

Group Report of 2021 SISP

- 42 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

5.10.6

Vue.jsVue.js*8 は，ユーザーインターフェイスを構築するためのプログレッシブフレームワークである．
他のモノリシックなフレームワークとは異なり，Vue は少しずつ適用していけるように設計されている．また，中核となるライブラリは view 層だけに焦点を当てている．そのため，使い始めるのも，他のライブラリや既存のプロジェクトに統合するのも，非常に簡単である．DID IT では，ゲームの進行状況の監視を行う Web アプリケーションの制作に利用した．

図 5.23

使用した技術（※文責: 藤田華奈）*8 https://jp.vuejs.org/v2/guide/index.html

Group Report of 2021 SISP

- 43 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

第 6 章 今後の展望
6.1

フィードバックを基にしたプロダクト改善

地域 × 災害チームでは，成果発表会の質疑応答と評価フォーム並びに 12 月 3 日に行なわれた実
地試験での気づきや評価アンケートを基に，更なるプロダクト改善を検討している．
（※文責: 木川裕太郎）

6.1.1

成果発表会で得たフィードバック

成果発表会の評価フォームは，「発表技術」に対する得点 (10 点満点) とその評価理由，「発表内容」に対する得点 (10 点満点) とその評価理由が記入されるフォーマットとなっている．当プロジェクトの発表技術の平均得点は 8.63 点，発表内容の平均得点は 8.54 点となった．また，地域 ×
災害チームに関するフィードバックについては，「現実世界との掛け合わせが面白い」という声があった．その一方で，災害を体験できるモードや AR を用いた災害映像を見られる機能を追加する
提案の声があった．
（※文責: 木川裕太郎）

6.1.2

実地試験で得たフィードバック

実地試験では，函館市立えさん小学校の先生と 4・５年生の児童の協力のもと，アプリを用いたイベントを行い，イベント後に評価アンケートに回答してもらった．実験最中に得た気づきとしては，まずアプリケーションの利用フロー上の都合でスマートフォンの物理的な戻るボタンを用いると意図的にアプリケーションが終了する画面フローが存在していたが，知識クイズの為の QR コー
ド読み取りボタンとアイテムクイズの為の QR コード読み取りボタンの役割を混同してしまった
ためにスマートフォンの戻るボタンを利用しようとしてアプリケーションを終了させてしまう児童が続出してしまった．また，この実地試験では，クイズの回答状況を保持しているデータベースを

SQL クライアントを用いることで監視しイベントの進行状況を把握しようと試みていたが，SQL
クライアントの接続の仕様上アプリの通信を阻害してしまい，イベント中にサーバーを再起動させる事態となってしまった．そのため，別の方法でのイベント監視を検討する必要が生まれた．評価
アンケートでは，イベントを楽しむことができたという声の一方で，QR コードの読み取りが難しいという指摘が多くあった．
（※文責: 木川裕太郎）

6.1.3

フィードバックを基にした改善

前述のフィードバックを基にして，地域 × 災害チームはプロダクトの改善を検討している．まず，従来はコンテンツの充実を図ってアイテムクイズと知識クイズの二種類を実装していたとこ

Group Report of 2021 SISP

- 44 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
ろを，アイテムクイズのみに絞ることで，クイズフローを単純化させて子供達にわかりやすい形になるように計画している．また，イベント状況の監視用として，優先度的に開発を先送りしていたWeb アプリの実装を完成させ，イベント状況を Web にアクセスするだけで手軽に把握できるようにする予定である．その他にも，ユーザーインターフェースのレイアウトや，注目を惹きつける為のアニメーションなどの細かいブラッシュアップによって，子供達がより防災学習としての側面の強いイベントを行えるように改善を図る予定である．
（※文責: 木川裕太郎）

Group Report of 2021 SISP

- 45 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

第 7 章 学び
7.1

畑大地

設計及びテストの重要性

2 回目実地試験において，クイズに正解したのにも関わらず，バッジが獲得できない不具合が発生した．原因はバッジ獲得のプログラムにおいて，前回の実地試験のアイテムクイズの個数が残っており，4 つから 6 つへ変更できていなかったことであった．これはプログラムの中で “4” を “6”に変更していなかったという 1byte のミスであり，今回の結果で 1byte の違いによるプログラムの影響度を再認識することができた．2 回目実地実験のプロダクトが完成したのは，当日の朝であり，それぞれの機能は完成し，単体テストを終えていたが，全ての機能を合わせた結合テストは実施できていなかった．事前に全体を通してのテストを行なっていれば，今回の不具合は未然に防ぐことが可能だった．また設計の面でも今回のような可変なデータに対しては，可変なデータでまとめる必要があった．開発中も設計変更の必要性は理解していたつもりだったが，他のタスクに集中するあまりその優先度を自分の中で下げてしまっていた．このような設計がずさんなたくさん機能が入ったアプリケーションの中で，今回のような変更する部分を見つけるのは困難であったといえる．結果，事前に変更の可能性がある部分に関してはまとめておく必要があり，設計段階で対応可能な状態にすることで防ぐということの重要性を実感した．
（※文責: 畑大地）

7.2

藤田華奈

本チームでは函館市の防災意識に焦点を当て，そこからヒアリングやメンバー同士での話し合いを重ねて今のプロダクトに落ち着くことができた．前期と後期で考えていたプロダクトの内容は異なる．しかし，後期でプロダクトの内容を考え直したことでステークホルダーには一層充実した価値を提供することができたと思う．ヒアリングやスクラム手法，実地試験など，初めての経験が多かったもののメンバー同士が各々の役割を果たしたことで良い結果を生んだと思う．特に，メンバー同士での認識のすり合わせは非常に大切だと感じた．プロダクトを制作していく中で，各々の「こうだと思っていた」という認識のズレにより，制作を一旦やめて話し合いをすることになる場
面がいくつかあったからである．この認識のズレも，デイリースクラムのやり方を工夫していくことで徐々に少なくなったと思う．また，私自身としてもチームのデザイン班として初めての経験が多くあった．特に，小学生が使いやすい UI を模索する時間が多かった．私自身にはない小学生の目線や思考について考えることに難しさと楽しさを感じた．実地試験では子どもたちの意見を聞いたり，動きを見ることができた．その様子からアプリケーションの使いにくさやプロダクトのルー
ルの分かりにくさを問題点として挙げ，解決するように動くことができた．一方で，子どもたちの楽しそうな反応を見ることができたこともチームのモチベーションに繋がったと考える．このような体験から，実際にユーザの反応を見ることの大切さを学んだ．アプリケーションの画面をデザインする際には，メンバーにレビューをもらいながら修正を行った．レビューの際にも，本チームでは「お疲れさまです！」などの声掛けが多く，精神的な負荷が少なかった．私はチームでの開発もGroup Report of 2021 SISP

- 46 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
初めてだったが，メンバー同士で支え合い，それぞれの役割をしっかり果たしたことで DID IT を制作することができたと思う．この経験を今後に活かしていきたい．
（※文責: 藤田華奈）

7.3

海野芽美

プロジェクト学習を通して主に二つの立場としての学びを得た．1 つ目の立場は，プロダクト
オーナーの立場としての学びである．プロダクトオーナーとして，プロダクトについて最終的な意
思決定をしていく中で，意思表示を明確にすることの重要性を学んだ．まだ，スクラムに慣れていないときにプロダクトの要件についての決定であいまいな意思表示をしてしまったことから共通認識にずれが出てしまうことがあった．その後，後期に入ってから意思決定についてなるべく明確な言葉選びをするように意識したところ，状況が改善したように感じた．2 つ目の立場は，開発者としての立場である．このプロジェクト学習では開発初心者として，Android アプリケーションの開発に携わった．そして，Git の使い方やわからないことの調べ方などを実践的に学んでいった．とくに，価値のある学びはコーディングが得意なメンバーから得られた．具体的には Android アプ
リケーションの開発で他の人のコードを読んだり，他の人が Slack に投稿していた技術に関連する技術を読んだりして，コーディングが得意な人のコードの書き方や，目をつけるポイントを知ることができた．また，Android の開発以外にも，全く知らなかった Web フレームワークや，オープ
ンプラットフォームを知ることができたことも大きな学びである．今後，自分でなにかプロダクトを作るというときに使う技術の選択肢を増やすことができたと思う．加えて，プログラム関連の技
術習得以外にも，ユーザーフレンドリーの考え方をプロジェクトを通して学ぶことができた．他の機会でユーザの体験を向上させるために意識することについて学んだことはあったが，実践の場で意識したことはなかった．プロジェクト学習では，実際にユーザフレンドリーなプロダクトにすることを意識する機会が与えられた．特に，デザインを担当していたメンバーから大きい影響を受けた．デザインを担当していたメンバーは，プロダクトが正しく動くことだけではなく，ユーザが正
しくプロダクトを使えることを常に意識していた．また，プロダクト以外の資料作りでも，情報の強弱や，伝え方など自分が今まで考えてこなかったところを意識してプロダクトを作っていた．その姿を近くで見て，動くものを作りたいという意識から，ユーザにとって価値のあるプロダクトを作りたいという意識をできるようになった．
（※文責: 海野芽美）

7.4

吉田拓夢

開発円滑化のためのデザインスタイルガイドについて本チームでは，プロダクト決定後にアプリデザインを行う前に，デザインスタイルガイド作成した．デザインスタイルガイドとは複数人でアプリや Web サイトをデザインする場合に，チームメ
ンバーが共通認識を持つために使用され，これにより異なるページの間に一貫した体験を作ることができ，その他のサードパーティ製品が生まれた際にもガイドラインにしたがって制作することで，そのプロダクトの一部として，知覚しやすくなる．本プロダクトでのデザインスタイルガイドの役割としては，主にデザインチームのデザインに対して一貫性を持たせるためとエンジニアチー

Group Report of 2021 SISP

- 47 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
ムの開発時にデザインスタイルガイドによって開発を円滑化させることが目的として挙げられる．
デザインスタイルガイドにはテーマカラーやサブカラー，主に使用するボタンやアイコン，加えて使用フォントやフォントサイズがあり，エンジニアが開発する場合，それらのスタイルガイドの内容を変数として持たせておけば，簡単に使用することができる．エンジニアは必須機能の実装に作業のリソースを割くことができ，結果としてアプリとして完成度を上げることができた．デザイン
面でも，メイン画面，アイテム画面，ゴール画面など使用するシーンの違う画面において統一した
アプリイメージをユーザーに対して与えることができたと考える．
ミーティングに精神的負担の軽減
プロダクトの詳細を決める場合，本チームでは Zoom や Discord などのオンラインミーティン
グツールを使用し話し合うことで詳細を決めてきた．しかし，多くのミーティングはプロジェクト
時間外に行われ，全員の参加が可能な時間に行うとなると 20 時以降の時間に行われることが多い
傾向にあった．さらに詳細を決める事項が多い場合そのミーティングの時間は 2 時間以上となり，チームメンバーの精神的負担を増す原因となった．このままではチームメンバーのモチベーショ
ン，パフォーマンス低下に繋がる可能性が高かったため，ミーティングの手法を切り替えた．一つ目は解決策としては，ミーティングの前に個人で行う作業である．ミーティングの議題が一つある
場合，事前にその議題に対しての意見や調べごとを行い，Slack への書き込みやドキュメントにまとめるなどの行為を行う．これによりミーティングでは，それらを確認しながら，議論を行うことができ，考える時間や意見を出し合う時間を削減することができるので，ミーティング時間を 1 時間ほど削減することができた．個人作業はそれぞれが空いている時間に行うことができ，隙間時間にも行えるため時間効率としてはとても高いと言える．二つ目の解決策は，時間帯の変更である．
皆で集まる場合には多くは夜の時間帯になるが，夜の時間は好きなことを行える，一日の中で最もリラックスできる時間であり，その時間を削りミーティングを行うことは精神的負担を増す原因となる．一つ目の解決策によりミーティング自体の時間を削減することができたため，ミーティング
時間の変更も行うこともできた．具体的には朝の時間や昼休みなど空き時間や最後の時間が決められている時間にミーティングを入れることで議論の効率化を図った．朝の時間帯に関してはチーム
メンバーの活動時間が夜が中心だったこともあり，朝に集合できないこともあり，変更となる場合もあったが，昼の時間や空き時間に関しては議論の効率化を図ることができたと考える．要因としては次の予定や授業がある限られた時間での議論は中だるみが少なく，簡潔に議論を行おうという意識がチームメンバーに広がり，議論の中で重要なポイントに絞って話し合うことができることが挙げられる．

Slack でのデザインレビューの手法
本チームでは，制作したデザインのレビューを UI デザインを行う際に使用する Adobe XD の共有機能と Slack で行った．コードレビューは github を使用し行えるのに対して，デザインのレビュー方法は明確な手法があまり提供されておらず，Adobe XD のコメント機能ではわかりにくい点があったため，Slack を使用することとした．デザインレビューを行う場合，制作した UI を

Adobe XD の共有機能で URL を発行し，レビュー者がみれる状態にする．その後 Slack 上で制作した UI の説明，デザインの意図，レビューをしてほしい箇所を書き込み，チームメンバーに対してメンションで通知を行う．レビュー者その投稿に対して，スレッドで返信しレビューを行うこと
でレビューを行った．これにより円滑なデザイン制作を行うことができた．

Group Report of 2021 SISP

- 48 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021（※文責: 吉田拓夢）

7.5

木川裕太郎

本プロジェクトを通して，スクラムマスターを務めたことによるアジャイル開発の知見に始まり，開発そのもののノウハウや技術スタック，デザインチームに関与したことによるデザイン的なスキルの向上など，多岐に渡る学びを得ることができた．初めに，自分は前述の通り地域 × 災害チームのを務め，加えて他チームのスクラムマスターに対してもアドバイスをするような立場にあったため，率先してスクラムについてのインプットをし，チームへ還元することが求められていた．その結果，スクラムの基礎的なフレームワークの理解や，「デイリーお絵描き」の考案などのドキュメントには書かれていない実践ならではのプラクティスの獲得をすることができた．開発
においては，主にデータベース設計と API の制作，イベント監視用 web アプリケーション「DID

IT Observer」の開発，そしてこれらのシステムの Docker によるコンテナアプリケーション化を担当した．個人的に初めての技術スタックのものばかりで，バックエンドレイヤーや Docker コン
テナについては初めての体験だったため，プロジェクトを通して自分の技術スタックを新たに獲得することができた．また，成果発表会に向けた準備において，後学のために開発班ではなくデザイン班に所属し，一部 web デザインやサイト内素材の制作などを経験した．デザインコース生のメンバーからデザインに関する知見を得ながら実践的に経験を積み重ねることで，デザイン対する興味関心とスキルを獲得することができた．
（※文責: 木川裕太郎）

Group Report of 2021 SISP

- 49 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

第 8 章 まとめ本チームでは函館市民の防災意識の向上を目的に課題や問題を見つけ出すために，担当教員である南部美砂子准教授による現段階で行われている函館の防災活動に関してのレクチャー，函館女性会議へのヒアリング，Code for Hakodate へのヒアリングを行った．そこで，函館大火という大きな火事が昔起こったということ，函館の避難所情報が見にくいという市民の声があったこと，函館
市民は未だ致命的な災害に遭っていないがゆえに防災意識が低い可能性があるということなど様々な防災にまつわる情報を収集した．収集した情報を元に本チームは地域の防災意識の向上という観点から子どもへの防災教育に着目し「函館市民の防災意識の向上を目指し，子どもたちが関心を持
つ防災学習を立案する」というテーマを定めた．テーマからプロダクトを決定する際にはブレイン
ストーミングという手法を用い，結果として従来の避難訓練とは違う，遊びとともに知識をつけることができる IoT を絡ませた新しい避難訓練「避難 RTA」を開発することに決定した．
夏季休暇期間では，プロダクトの詳細を決めるため類似サービスの調査，函館市えさん小学校への訪問，ユーザーストーリーマップの作成などを行った．加えて同時に，技術習得のために

GitHub 講習会，UCD ワークショップ，FizzBuzz アプリケーション作成などの活動を行った．また夏季休業期間の間，スクラム導入をスムーズに行うため縮小スクラムを実施した．
後期に入ってからはスクラムの本格運用を開始した．具体的には，夏季休業期間で行っていた
縮小スクラムにスプリントレビューを足したものを行った．自分たちで開発を進めていく内にプロダクトの実現可能性や意義や特徴が弱くなってしまったことを受けてプロダクトの練り直しを行った．練り直しの結果，避難訓練システムから大きく方針を転換し，「DID IT」という防災学習
支援システムを開発することに決定した．10 月には函館市えさん小学校にて 1 回目の実地試験を行った．11 月末には「児童向け防災学習レクリエーションシステム DID IT」開発チームとして

HAKODATE アカデミックリンク 2021 で発表を行い，審査員特別賞を受賞した．2022 年 1 月
18 日には函館市えさん小学校にて 2 回目の実地試験を行った．また，この際に実地試験への協力のお礼として児童たちに対して Processing ワークショップも行った．Processing ワークショップ
では，公立はこだて未来大学の学生が作成した Processing プログラムを 3 つ展示した．
（※文責: 畑大地）

Group Report of 2021 SISP

- 50 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

第 9 章 今後の予定
9.1

フィードバックを利用した改善

本チームでは函館市えさん小学校で 2 回行った実地試験や成果発表会などで多くのフィードバッ
クを得ることができた．今後はそこで得たフィードバックを元にプロダクトの改善を図る．具体的には DIDIT-Web(仮称) での分析レポート機能の拡充，複数イベントの管理，問題パッケージの拡充や細かいバグの修正などが挙げられる．また，2 回目の実地試験終了後アンケートはまだ集計できていないため，集計作業を行う必要がある．
（※文責: 畑大地）

9.2

課外成果発表会への参加

本チームは 2022 年 2 月 15 日に公立はこだて未来大学が主催するオンラインで開催されるプロ
ジェクト学習課外発表会に参加する．例年は秋葉原会場での現地開催を行なっていたが，昨今のコロナ禍による事情を考慮して，昨年に引き続き Zoom によるオンライン開催される予定である．各
チーム個別の参加ではなくプロジェクト全体での参加となり，2 セッションの発表が予定されているので，成果発表の際に決めた前半・後半チームによる構成を基本として発表する予定である．参加にあたって 2022 年 2 月 15 日の午前中にリハーサルに参加する．発表会では 2 回目の実地試験を終え，改善を行った「DID IT」を紹介する予定である．
（※文責: 畑大地）

Group Report of 2021 SISP

- 51 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

付録 A
イド

制作物: アカデミックリンクでのスラ

アカデミックリンクで使用したポスターを記載する．

（※文責: 吉田拓夢）

Group Report of 2021 SISP

- 52 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

Group Report of 2021 SISP

- 53 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

Group Report of 2021 SISP

- 54 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

Group Report of 2021 SISP

- 55 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

Group Report of 2021 SISP

- 56 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

付録 B

成果発表会にて使用したポスター

4.5 節で記載した成果発表で使用したポスターを以下に掲載する．

Group Report of 2021 SISP

- 57 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021

参考文献
[1] 内閣府，2019， 平成 30 年北海道胆振東部地震に係る被害状況等について，http://www.
bousai.go.jp/updates/h30jishin_hokkaido/pdf/310128_jishin_hokkaido.pdf[2] 小 野 浩 ，2018，平 成 30 年 北 海 道 胆 振 東 部 地 震 に よ る 被 害 状 況 等 ，https://www.city.
hakodate.hokkaido.jp/docs/2018090400011/files/0907-02.pdf[3] 花王株式会社，2020，【東日本大震災から 10 年】被災の有無で差がある防災対策，https://prtimes.jp/a/?c=9276&r=1203&f=d9276-1203-pdf-0.pdf[4] 函館市防災会議，2021，資料９ 過去の災害状況，https://www.city.hakodate.hokkaido.
jp/docs/2014022500262/files/21040109.pdf[5] 旭化成ホームプロダクツ株式会社，2020，全国 20 60 代 700 名に聞いた「防災意識と備えに関する調査」 ，https://www.asahi-kasei.com/jp/news/2020/ip4ep30000001mak-att/

li200827_1.pdf[6] 函 館 女 性 会 議 の Facebook，https://www.facebook.com/groups/444520429927364/(2021-07-21 閲覧).
[7] CodeforHakodate のホームページ，https://www.codeforhakodate.org/(2021-07-21 閲覧).
[8] 中鉢欣秀，Fisdom | アジャイル開発概論，https://www.fisdom.org/F00000033/(2021-07-19 閲覧)．
[9] 高森満，プロジェクト学習のためのプロジェクトマネジメントの基礎 - enPiT e-Learning 学習
用 Web サイト，https://enpit2.widebook.net/?page_id=33 (2021-07-19 閲覧)．

[10] みんなの防災，親子で学べる防災クイズ，https://www.zenrosai.coop/stories/bousai/
cafe/quiz.html (2022-01-12 閲覧)．
[11] 自衛隊／防衛省，自衛隊防災 BOOK，マガジンハウス，2018．
[12] 羽田道信，防災・救急に役立つ日用品活用法＆ロープワーク 新版，風媒社，2011．
[13] 国崎信江，防災・防犯シミュレーション 大地震 そのときどうする？，ほるぷ出版，2018．
[14] 国崎信江，ぼくらの災害サバイバル BOOK，主婦の友社，2018．
[15] 今泉マユ子，防災教室 身の守りかたがわかる本，理論社，2019．
3 災害がおきたらこうしよう！ -対処と行動[16] 藤吉洋一郎，いのちを守る！ 災害対策大百科 ○編-，株式会社 日本図書センター，2008．

[17] デジタルトランスフォーメーションチャンネル，https://www.digital-transformation-real.com/blog/what-is-beacon.html(2022-01-11 閲覧)．
[18] いぢちひろゆき.net，https://ijichihiroyuki.net/bousai/index.php?cat=saigaiji(2022-01-11 閲覧).
[19] CodeZine，https://codezine.jp/article/detail/11753 (2022-01-1 閲覧).
[20] IBM，https://www.ibm.com/jp-ja/cloud/learn/docker (2022-01-12 閲覧).
[21] IT 用語辞典 e-Words，Go 言語とは -，https://e-words.jp/w/Go%E8%A8%80%E8%AA%9E.
html (2022-01-11 閲覧).
Group Report of 2021 SISP

- 58 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2021
[22] コトバンク/小学館, アジェンダとは -，https://kotobank.jp/word/%E3%82%A2%E3%82%
B8%E3%82%A7%E3%83%B3%E3%83%80-424384 (2021-07-19 閲覧).

Group Report of 2021 SISP

- 59 -

Group Number 1-A