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

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

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

グループ名
グループ C (地域メディア)Group NameGroup C (Local media)
プロジェクト番号/Project No.

1-C

プロジェクトリーダ/Project Leader
児玉拓海

Takumi Kodama

グループリーダ/Group Leader
如澤駿介

Shunnsuke Jyozawa

グループメンバ/Group Member
如澤駿介

Shunnsuke Jyozawa

外崎健介

Kensuke Sotozaki

近藤篤

Atsushi Kondou

中野瑛斗

Eito Nakano

鈴木瑞帆

Mizuho Suzuki

指導教員
伊藤恵

南部美砂子 奥野拓

元木環

AdvisorKei Itou Taku Okuno Misako Nambu Tamaki Motoki

提出日
2023 年 1 月 18 日

Date of Submission
January 18, 2023

概要
本プロジェクトは，フィールド調査をもとに問題を発見し，IT を用いて解決する．それによりユーザの仕事や生活をデザインし，地域や社会に貢献することを目的に活動している．また，本プロジェクトは，アジャイル開発手法を用いる．それにより，迅速で柔軟な開発を行い，短期間の開発でより効率的に成果を出すことを目標にしている．今年度は，プロジェクト内を交通支援グループ，観光グループ，地域メディアグループの 3 グループに分け，各グループがそれぞれのフィールドで活動している．本報告では地域メディアグループについての報告を行う．
本グループでは，函館近郊の情報の発見を手軽にすることを目的とした Web アプリケーショ
ン「はこレクト」の開発を行った．「はこレクト」では，ソーシャルメディア上にある函館近郊に関する投稿をリアルタイムで取得し，施設の情報などのみを選別して一つの Web アプリ
ケーションとして表示している．投稿の選別方法は，函館近郊の情報発信をしている SNS のアカウントや，除くべきと判断したキーワードを含んだ投稿など様々である．今後は，現在作り上げた「はこレクト」を対象ユーザに利用してもらいフィードバックを受け，プロダクトを改善する予定である．さらに，投稿の選別精度を向上させるために、機械学習や画像処理などを導入し，よりよいプロダクトを開発することを検討している．
キーワード

フィールド調査，IT，スクラム，はこレクト（※文責: 外崎健介）-i-Abstract
This project identiﬁes problems based on ﬁeld research and solves them using IT. The
project design the work and life of users and contribute to the community and society
through these activities. The project will use agile development methods. The goal
is to develop quickly and ﬂexibly, thereby achieving more eﬃcient results in a shortdevelopment period. This year, the project is divided into three main developmentgroups: a transportation support group, a tourism group, and a local media group,with each group working in its own ﬁeld. This report is about the Local Media Group.
This group has developed a web application “HaCollect” for the purpose of easily ﬁnding
information on the Hakodate suburbs. HaCollect acquires posts about the Hakodate
suburbs on social media in real time, selects only facility information, etc., and displaysthem as a single Web application. There are various methods for selecting posts, suchas SNS accounts that disseminate information about the Hakodate suburbs, posts that
contain keywords that should be removed, and so on. In the future, we plan to have thetarget users use the HaCollect that we have created and receive feedback to improve
the product. Furthermore, in order to improve the accuracy of sorting posts, we areconsidering developing a better product by introducing machine learning and image
processing.
KeywordField survey, IT, Scrum, “HaCollect”（※文責: 外崎健介）- ii -

目次
第1章

背景

1

1.1

前年度の成果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

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

1

1.3

地域メディアグループ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

前期の主な活動2

2.1

グループの結成とプロダクトの考案 . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.2

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

3

2.3

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

5

2.4

Swarm，TwittPane，ツイータン，タグライブなどの類似サービスの調査 . . . .

6

2.5

既存サービスの調査 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.6

技術検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.7

グループ名の変更. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.8

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

8

2.9

対象者の明確化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.10

地域の問題の明確化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.11

目的の明確化 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.12

アンケートによるアイデア評価 . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.12.1 アンケートの実施 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

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

17

2.13.1 準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

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

19

2.14

機能の考案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.15

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

20

2.16

役割決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

夏休みの活動23

3.1

夏休みのスケジュール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.2

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

23

3.3

ワイヤーフレームの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.4

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

25

3.5

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

25

3.6

縮小スクラム（スクラム練習）の実施 . . . . . . . . . . . . . . . . . . . . . . . .

26

第4章

後期の主な活動27

4.1

スクラムの説明会. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.2

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

27

スクラムについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

第2章

2.13

第3章

4.2.1

- iii -

4.2.2

スプリントについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.2.3

スプリントプランニングについて . . . . . . . . . . . . . . . . . . . . . .

29

4.2.4

プロダクトバックログについて . . . . . . . . . . . . . . . . . . . . . . .

29

4.2.5

スプリントバックログについて . . . . . . . . . . . . . . . . . . . . . . .

29

4.2.6

デイリースクラムについて. . . . . . . . . . . . . . . . . . . . . . . . .

29

4.2.7

リファインメントについて . . . . . . . . . . . . . . . . . . . . . . . . . .

30

4.2.8

スプリントレビューについて . . . . . . . . . . . . . . . . . . . . . . . .

30

4.2.9

スプリントレトロスペクティブについて. . . . . . . . . . . . . . . . . .

31

4.3

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

32

4.4

スプリント 1 (中止) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.4.1

期間

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

33

4.4.2

スプリントの目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.4.3

中止した理由 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.5

コンセプトの見直し . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.6

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

34

4.7

4.8

4.9

4.6.1

期間

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

34

4.6.2

スプリントの目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.6.3

何を達成できたか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.6.4

何が問題だったか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

4.6.5

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

35

4.6.6

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

36

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

36

4.7.1

期間

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

36

4.7.2

スプリントの目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.7.3

何を達成できたか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.7.4

何が問題だったか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.7.5

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

37

4.7.6

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

38

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

38

4.8.1

期間

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

38

4.8.2

スプリントの目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

4.8.3

何を達成できたか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

4.8.4

何が問題だったか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

4.8.5

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

39

4.8.6

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

39

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

39

4.9.1

期間

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

39

4.9.2

スプリントの目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4.9.3

何を達成できたか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4.9.4

何が問題だったか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4.9.5

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

40

4.9.6

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

40- iv -

4.10

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

41

4.11

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

41

4.12

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

43

4.13

ユーザからのフィードバック. . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

4.14

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

45

開発したプロダクト「はこレクト」

46

5.1

「はこレクト」の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.2

対象ユーザ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.3

「はこレクト」の機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.3.1

投稿閲覧機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.3.2

カテゴリ別表示機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.3.3

キーワード検索機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

第5章

5.4

投稿選別方法. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

選別ルールの決め方 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

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

53

5.5.1

HTML/CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

5.5.2

JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

5.5.3

Vue.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

5.5.4

Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

5.5.5

Twitter API・Instagram Graph API . . . . . . . . . . . . . . . . . . .

54

5.5.6

Google Cloud Platform . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

5.5.7

Firebase Realtime Database . . . . . . . . . . . . . . . . . . . . . . . .

54

5.5.8

Git・GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

5.5.9

Sourcetree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

5.5.10 ZenHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

知識・技術習得56

6.1

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

56

6.2

アジャイル開発概論 (enPiT e-Learning) . . . . . . . . . . . . . . . . . . . . . .

57

6.3

フィールドワーク入門講座 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

6.4

スクラムワークショップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

6.5

GitHub 講習会. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

6.6

SCRUM BOOT CAMP THE BOOK スクラムチームではじめるアジャイル開発

60

6.7

オンラインプログラミング学習サービス「Progate」

60

5.4.1
5.5

第6章

第7章

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

学び

61

7.1

共通認識の重要さ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

7.2

議事録の重要さ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

7.3

コミュニケーションツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

7.3.1

Discord. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

7.3.2

Slack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

7.3.3

ホワイトボード

63. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
-v-

7.3.4
第8章

Miro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

個人の学び

65

8.1

如澤駿介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

8.2

中野瑛斗 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

8.3

外崎健介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

8.4

近藤篤 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

8.5

鈴木瑞帆 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

まとめ

71

第9章

第 10 章 今後の予定

73

10.1

課外発表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

10.2

「はこレクト」の今後 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

付録 A

制作物：作成したペルソナ

74

付録 B

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

75

付録 C

成果発表会で使用したスライド

76

付録 D

制作物：リスク分析

82

付録 E

活用した講義

91

参考文献

92

- vi -

Field Oriented System Design Learning by Users’ Feedback 2022

第 1 章 背景1.1

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

1.2

プロジェクトの方針

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

1.3

地域メディアグループ

私たちは前期の活動の初めにブレインストーミングを行い，函館の娯楽にはどのようなものがあるかについて意見を出し合った．その際に，函館出身のメンバと大学入学に伴い函館に移住してきたメンバとの間で函館の娯楽に関する知識の差が大きく現れた．そして，函館外出身のメンバは函館出身のメンバよりも函館に関する知識があまり少なく函館を十分に楽しめていないという問題を発見した．私たちはこの問題に注目し，函館外出身者の函館に関する知識を，函館出身者と同じ程度まで引き上げることによって，函館外出身者が現状よりも函館を楽しむことができるのではないかと考え，これを課題とした．私たちはこの課題を解決するために，函館の良さにより多く気づくことができるような信頼性の高い地域情報を共有する場を作りたいと考え，「はこレクト」というプロダクトを考案した．
（※文責: 近藤篤）

Group Report of 2022 SISP

-1-Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

第2章
2.1

前期の主な活動

グループの結成とプロダクトの考案

私たち地域メディアグループは，初めてグループワークを行った 5 月 27 日に，グループ間で函館の娯楽に関してブレインストーミングを行った．まず, 函館で娯楽の対象となる施設やものについて話し合った．主に出た函館の娯楽施設としてはアミューズメントプラザテキサス函館やラウン
ドワンスタジアム函館，Starbucks Coﬀee やコメダ珈琲店などカフェが出た．しかし，これ以降函館の娯楽施設に関する話題が進展しなかったため，3 年前の先輩方が行った北斗市石別地区の魅力をより多くの人に共有するために，ICT を用いて観光を支援し観光客を増やすアプリケーション[2] を参考に観光面について話し合うことになり，「函館や函館付近の各地で有名なものは何か」という議題で再度ブレインストーミングを実施した．
まず大沼では，大沼だんごやワカサギ釣り，キャンプ，グリーンピア大沼などその他合計六つほ
どの有名な食べ物やイベント，施設が出た．次に七飯町のリンゴ狩りや，ワインを作るためのブド
ウ園，山川牧場などが話題に出た．最後に函館の有名なものとして函館公園の現存する中で最古の観覧車 [3] や動物施設の二つが出た．約 1 時間ほどのブレインストーミングを行った後，ホワイト
ボードに羅列した単語同士を組み合わせ新規性があるプロダクトを作ることができないか様々な視点からそれぞれ考察した．一週間のスケジュールを入力したらそれを管理するプロダクトやインス
タ映えスポットを探すプロダクトなどその他合計 17 個ほどプロダクトのテーマが出た．
その後私たちはアイデアとして出た案の中から以下の三つに絞った．

•「石別の魅力を ICT を用いて伝えるアプリケーション」の函館版• 対象を函館とした函館の観光情報のメジャーではないコアな情報を提供するプロダクト• 函館の有名な観光地を提供する観光アプリ
まず，「石別の魅力を ICT を用いて伝えるアプリケーション」の函館版の主な機能や役割として
は，以前のプロダクトを参考にアプリケーションとして函館の詳細な地図をアプリ画面の中心に図示し，タップした場所でその辺り一帯の情報を表示することなどが機能として発案された．次に，函館にこれから住む人に取って深い情報を提供する案としては，Web や広告，ニュースで取り上げられるようなメジャーな情報ではなく，実際の口コミや人づてで得られるようなインターネット
や SNS で漠然と調べても出ないコアな情報を扱ってそれをユーザに提供するプロダクトを考案した．最後に函館の観光アプリとして，Twitter や Instagram にある「タグ機能」を用いてタグ検索
で自分が知りたいカテゴリや場所を一覧表示するものであった．
この三つの案において私たちはそもそも私たち自身が函館に住んでいてどのような問題を感じる
か議論し，ブレインストーミングを行った (図 2.1) ．その際，外崎と中野は函館出身者であるため
観光サイトなどにはあまり記載されていないコアな情報を多く発話したりアイデアとして発案したが，鈴木と近藤，如澤の 3 人は函館外出身であるため観光サイトに載っているような有名な情報しか話し合いで提供できなかった．ゆえに私たちのグループはこの有識者の情報を知識のない人へ伝達できる何かがほしいという結論に至った．函館外出身者である 3 人は 2 年から 6 年の間しか函館にいないため函館出身者のような深い情報に短期間でたどり着くのは難しいと言っていた．まGroup Report of 2022 SISP

-2-Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
た，観光に来た人が訪れるような有名な観光地はすでに行っているため，他の目新しいものを楽しんでみたいと述べていた．よって，私たちは先ほど言った三つのテーマ候補より函館の観光アプリ
を最終案とし，函館に関する知識を求めているメンバの要望を汲み取り，函館の観光アプリをテーマとして決定した．また，このテーマの目標として「知識を所持している人があまり知識のない人へ知識を共有する」とした．
（※文責: 外崎健介）

図 2.1

2.2

ブレインストーミングを行いテーマを考案していた際の写真

Code for Hakodate へのヒアリング

6 月 1 日に私たちのプロジェクト全体で，Code for Hakodate の中村氏からヒアリングを行い，全体で函館にどのような問題があるのか，Code for Hakodate は函館のためにどのようなことをしているのか話を伺った．講義後はグループごとでグループワークを進めつつ，中村氏が各グループを巡回し質疑応答を行った．私たちは，前回出したテーマが客観的に見てどうか，また現時点でどのような問題が想定されるか質問させていただいた．
私たちのテーマを聞いた中村氏から 2 点指摘をしていただいた．

• Web でプロダクトを作成する場合には，私たちのプロダクトを使ってもらうため，Web を分析し人気がある Web サイトとそうでないものの差は何かを解明し，人気を引くためにどうすればいいか一度考える必要がある• プロダクトをアプリとしてを作成した場合，「インストールをする」という行為はハードルが高く，ユーザにとって面倒である
この二つのそれぞれの弱点を解決するためには，Web アプリケーションが良いと仰っておりグ
ループの仮決定として Web アプリケーションでプロダクトを作成することが決まった．
その後，中村氏は私たちが観光系のアプリを作ることを踏まえ，函館市公式観光情報サイトである「はこぶら」[4] にはユーザの好みに情報を表示するマッチング機能が存在しないため，「はこぶGroup Report of 2022 SISP

-3-Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
ら」に投げかけ分析し，ユーザのおすすめを表示するプロダクトはどうだろうかと案を出して頂いた．またそれとは別に Twitter や Instagram のアカウント情報からユーザを分析し，ユーザがどのような場所に行っているのかを分析し，年代ごとにトレンドを発信する「トレンドメーカー」という案も出して頂いた．中村氏は「何か問題を見つけたいのなら初めて函館に来て何も知識がない設定で函館を観光をした場合様々な問題が見つけられる」とアドバイスを頂いた．
これらの案やアドバイスを参考に一度私たちで新たなプロダクト案を出すために再度ブレインス
トーミングを行った (図 2.2)．ブレインストーミングにより私たちは，既存サービスとの差別化を図るために「はこぶら」のように全体の情報を扱うのではなくコアな情報を主体とすれば競合が減るため，私たちのプロダクトに新規性が生まれるのではないかと推察した．また，中村氏に仰っていた「自分で観光してみる」というフレーズを元に，私たちはアプリをダウンロードしたユーザに位置情報を利用して「はこぶら」の情報やトレンド，マイナーな情報を送り，自分から全ての情報を探すのではなく，自動的に情報が入ってくるポップアップ通知のプロダクトがいいのではないかと話し合い中村氏に話を伺った．中村氏は，「アイデアとしてはいいが位置情報をリアルタイムで手に入れる方法はビーコンが必要だ．函館全域にビーコンを置くことは非現実的でありコストも非常に高くなってしまう」と仰っていた．ゆえにテーマとして成立はしなかったが，プロダクトの機能にある自動的に情報を取得することが私たちの中で今後のテーマに必ず取り入れたい機能となった．
この日の結果として，私たちは Web サイトを作る場合には既存サービスである「はこぶら」があり，今年度で「はこぶら」を上回るサービスを開発することは不可能だとグループ全体で判断し，函館の観光アプリはテーマとして断念したのである．また，函館の魅力を伝える方法は PWAのような Web アプリケーションを作成することに決定した．また，ＰＷＡとは Progressive Web

Apps の略称で，モバイルブラウザとネイティブアプリ (アプリストアからダウンロードして使用するアプリ) の利点を融合した Web アプリ (アプリのように振る舞う高速な Web サイト) のことである．[5]（※文責: 外崎健介）

図 2.2

中村さんに話を伺いブレインストーミングを行った際の写真

Group Report of 2022 SISP

-4-Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

2.3

プロダクトの決定

6 月 3 日に私たちは中村氏からアドバイスを受けた情報のポップアップ通知のプロダクト案の問
題点と新たなプロダクト案に関するブレインストーミングを行った (図 2.3)．話し合いの過程で以前にマイナーな情報をユーザに提供したいと話し合ったが，マイナーな情報の定義が最も困難な議題となった．そもそもマイナーなモノとは何か，また，マイナーな場所はどこでその場所は多くの人が来ることを求めているのかなど一概には言い切ることができない問題が多く挙げられた．私たちの作業を見て，TA の方が「プロダクト考案において重要なことは私たちが最も欲しい物を考え，
今私たちがどのような問題を解決したいか考えること」と仰っていた．ゆえに，それを参考にもう一度何を実現したいか話しあった結果，私たちの現在のプロダクトの「はこレクト」の命名前のプロダクト「函館の Twitter」を実現したいということに決まったのである．
その後，実際に「函館の Twitter」で何をしたいかホワイトボードに各々書き出し大雑把にどのような機能があって誰が対象なのか，何を解決できるかなどを話しあった．その作業を踏まえ，私たちのアイデアが実現可能なのか奥野教授に小規模のプレゼンテーションを行い，フィードバッ
クを頂いた．フィードバックでは，私たちのアイデアは既存の類似サービスにより実現されていな
いか，扱う SNS などの規約は違反していないか，情報をどのように扱いどのように表示するのかなど詳細な意見を頂き，これらのタスクを私たちは再度一つ一つ確認し問題がないか確かめた．また，奥野教授は「どれだけ必要な情報を絞り込めるかが鍵になる」と仰っていたため，私たちはこの意見を今後の活動で話し合っていった．
（※文責: 外崎健介）

図 2.3

Group Report of 2022 SISP

中村さんからのアドバイス-5-

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

2.4

Swarm，TwittPane，ツイータン，タグライブなどの類似サービスの調査

6 月 10 日に私たちはまず既存の類似サービスと私たち自身のアイデアの比較を行った．まず，奥野教授から教えていただいた類似サービスの Swarm を分析したところ，アプリの機能としては
アプリを電子端末に入れている人が訪れた場所を簡単に記録するアプリで Twitter のようなフォ
ロー/フォロワー，タイムラインなどの機能があった．Swarm の類似点は Twitter API を用いて投稿されたツイートを収集する点であり，利点は位置情報を ON にしていると，アプリを起動後に周囲の施設が一覧で表示される点であった．また，欠点は特に挙げられなかった．次に，フォ
ロー/フォロワーを管理できるアプリ TwittPane[6] などの Twitter API を利用しているサービス
をいくつか比較したが，私たちのアイデアとは異なっていたため特に比較することはなかった．次に，ツイータン [7] を分析した．このアプリの利点は，Twitter のキーワードやハッシュタグを独自に集計し，ランキングやトレンドワードを表示するサービスである．このサービスは Twitter

API を継続的に収集していたため，私たちのアイデアの機能面として継続的に情報を収集できることが実際に確認できた．最後に，タグライブ [8] という Twitter や Instagram のハッシュタグを取得するサービスを発見した．このサービスにより私たちは情報を取得や識別することができるということが分かった．
（※文責: 外崎健介）

2.5

既存サービスの調査

6 月 15 日に私たちは既存のサービスの問題点を探すための調査を行った．具体的には，Instagram，Twitter，食べログ，函館の飲み食い日記 [9] というブログの計四つのサービスで函館の本町にある居酒屋をメンバで分担して調べた．Instagram で検索するのを如澤，外崎が，Twitter で検索するのを鈴木が，食べログで検索するのを近藤が，函館の飲み食い日記で検索するのを中野が担当した．この調査から，Twitter では写真がなく文章のみで紹介されているものがあり，調べる
側から見ると情報が伝わりにくいという問題や最新順で検索すると，余計な情報があり検索が少し困難であるという問題があった．また，Instagram では，具体的な範囲を指定して検索することが難しいという問題や位置情報のタグが投稿に一つしか付けられないため，位置情報タグがお店で統一されておらず，検索結果に表示されないお店があるという問題があった．さらに，Twitter とInstagram の共通の問題として，実際のお店の名前を知らないと情報が出てこないという問題があった．次に食べログは店の情報がいつ更新されたかわからないため現在営業しているかがわからないことや標準検索ではプロモーション店舗が優先表示されるため情報の信頼性に欠けるという問題があった．最後にすべてのサービスの共通の問題として，本町のカフェや五稜郭の居酒屋の情報など本町の居酒屋ではない情報が表示されることが挙げられた．これらの問題をオンラインのホワ
イトボードサービス「Miro」を利用しフィールドワークの結果をまとめた (図 2.4)．図 2.4 の青色の付箋はそれぞれが調べたお店について，オレンジ色の付箋はそのサービスの問題点，水色の付箋はそのサービスの良い点，緑色の付箋はどのように調べたかについてまとめた．このまとめから，
既存のサービスでは抽象的な検索をすると，目的とする情報以外の情報が多数表示されてしまい本
来手に入れたい情報が手に入らないということがわかった．

Group Report of 2022 SISP

-6-Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022（※文責: 近藤篤）

図 2.4

2.6

既存のサービスの問題点を探すためのフィールドワークまとめ

技術検証

6 月 15 日に私たちは奥野教授からサービスとして成立させるために必要なデータが継続的に取得できそうか，データから必要な情報が自動抽出できそうかの 2 点についての技術検証を行うべきという指摘を頂いたため，6 月 17 日にメンバ全員で Twitter API を取得し Python の Tweepyというライブラリを用いて，函館というキーワードが含まれた最新の投稿を取得した．この際，取得した投稿にはリツイート投稿や返信投稿など私たちが必要としていない投稿が多く含まれていたため，必要な情報に絞り込むために工夫が必要なことがわかった．そして，企業向けに Twitterと Instagram のハッシュタグやキーワードを取得して表示するサービスを提供しているタグライ
ブ ，6 月 10 日に発見したツイータンを発見したことから，必要な情報を継続的に取得できると判断した．また，Python で抽出した投稿からトレンドを word cloud で表示することができると考えたため，その実装も行った．この検証後，奥野教授から必要な情報を取得するにはハッシュタグ
やキーワード，ユーザ情報などの情報を用いて絞り込む必要があり，この点が一番難しいという
フィードバックを頂いた．このフィードバックをもとに必要な情報をどう取得するかを今後再検討することとした．
（※文責: 近藤篤）

2.7

グループ名の変更

私たちは大学生×娯楽というグループ名で活動を始めたが，作ろうとしているプロダクトの大まかな内容が決まっていく過程で，対象者が大学生だけでないこと，娯楽に関する情報だけを表示するものでないことからグループ名を変更したいという考えがあった．そこで，南部准教授からのGroup Report of 2022 SISP

-7-Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
フィードバックを基に地域×キュレーションというグループ名を考案した．しかし，このグループ名だと私たちのプロダクトをイメージさせるのは難しいという意見を奥野教授から頂いた．この意
見を基に，私たちは地域×メディアというグループ名を考案した．このグループ名に対して，伊藤教授から「×」があることで可能性が広がってしまうため良くないとの意見を頂いたため，最終的に「地域メディア」というグループ名にすることとなった．
（※文責: 近藤篤）

2.8

プロダクト名の決定

奥野教授から中間発表までにプロダクト名を決めておけば，聴衆の記憶に残りやすく，評価や意見をもらいやすくなるとのご指摘を受け，メンバ全体で，プロダクト名を考えた．初めは，「ハコッ
ター」というプロダクト名を考案した．このプロダクト名の由来としては，私たちのプロダクトはTwitter のようにリアルタイムの声を届けるようなものを想定していたため，「函館」と「Twitter」を掛け合わせた．しかし，私たちのプロダクトは複数のソーシャルメディアから函館に関する情報を集め，信頼性のある情報を自動的に識別，表示する Web アプリケーションであるため，ハコッ
ターという名前だと，Twitter をメインとするプロダクトであると勘違いしてしまうことが予測されたため，また新たに考え直した．次に思いついたのが「はこレクト」というプロダクト名である．
このプロダクト名の由来としては，「函館」と「collect (集める，収集) 」を掛け合わせたものである．私たちのプロダクトはあらゆる情報を信頼性のある情報として収集し，それをユーザに届ける
プロダクトであるため，このプロダクトには妥当な名前であると思われる．
（※文責: 中野瑛斗）

2.9

対象者の明確化「はこレクト」の対象者を考え始めたのは 6 月 3 日の「はこレクト」で実現したいことを話し合った後のことである．実現したいこととしては，函館の人気の飲食店を知りたいことや函館のトレン
ド情報を知りたいこと，「はこレクト」を見るだけで何か情報が手に入ること，調べづらさを改善したいことなど様々な意見が出た．これらのことをもとに「はこレクト」の対象者を話し合った．
その結果，以下の条件すべてを満たす人を対象者とした．

• 函館に住む人であること• 大学生であること• 自分から積極的に情報探索をしない人• 最低限スマホの基本的な操作できる人
函館の大学生を対象者とする理由として，私たちのグループで休憩中に雑談をしている時，函館について話す機会があった．そこで函館出身の人しか知らない函館近郊のスポットなどが多くあり，函館出身の人と函館外出身の人では明らかに函館近郊の情報に関する知識の差があった．私たちのグループはこの知識の差を縮めようと考えたため，私たち自身を含めた函館の大学生を対象とした．また，自分から積極的に情報探索をしない人を対象者とした理由は，函館の情報を知りた
くても，検索が面倒だと思う人，どの情報に信頼性があるのかを判断することが面倒な人の悩みをGroup Report of 2022 SISP

-8-Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
解決したいと考えたためである．したがって，自分から積極的に情報探索をしない人を対象者とした．また，最低限スマホの基本的な操作ができる人を対象者とした理由は，最低限のスマホの基本的な操作ができない人を対象とするならば，IT を用いない方向で解決手段を考えることになるためである．可能ならば，スマホの基本的な操作ができない人でも利用してもらえるようなプロダク
トを作りたいが，現段階の私たちの能力を鑑みるに，実現不可能であるため，断念せざるを得ないと考えた．以上のような理由で，「はこレクト」の対象者を定めた．また，この後に TA から，対象者を考える時はペルソナを用いて考える事によって，メンバが対象者を想像しやすくなるというご指摘を受けたため，メンバでペルソナを考えることにした．ペルソナとはサービス・商品の典型的なユーザ像のことで，マーケティングにおいて活用される概念のことである [10]．ペルソナを考えた結果，図 2.5 や図 2.6 のようなものを作成した．残りの作成したペルソナは付録 A に添付する．
このようなペルソナを複数作成することによって，各メンバは，「はこレクト」をどのようなユー
ザに提供するのかを具体的に想像することができるようになり，今後の開発が捗ると感じた．
（※文責: 中野瑛斗）

図 2.5

Group Report of 2022 SISP

ペルソナ 1 人目-9-Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 2.6

2.10

ペルソナ 2 人目

地域の問題の明確化

私たちが当初提起した問題は「函館に関する知識格差があることによって，函館を満喫できる人とできない人が存在すること」であった．これは私たちがどのような活動を行うか考える際，函館にある娯楽施設についてブレインストーミングを行った時に，函館出身メンバが函館外出身メンバの知らない娯楽施設を次々に挙げた，つまり両者の間で知識の差が現れたことから考えた問題であった．
しかしメンバ全体で改めてこの問題に疑問点があるか話し合ったところ，「そもそも知識格差があることで，なぜ函館を満喫できる人とできない人が存在するのか」という話が挙げられた．この
疑問の回答として「滞在期間が短く，函館に関する知識が無い場合，函館のマイナーな場所 (＝五稜郭などよくメディアに挙げられるメインの観光名所ではない場所) の良さが伝わらない」というものが挙げられたが，同時に「知識格差を補完するための情報は多く発信されているが，その情報自体調べづらく気付かれていない」という新たな問題も発見した．この新たな発見も踏まえて，「滞在期間によって函館に関する知識格差があり，情報を探そうにも調べづらいので，結果として滞在期間が短い人は函館を最大限満喫出来ない」という問題に変更した．
この内容で一度中間発表用の発表スライドに記述したところ，伊藤教授から「誰と誰の間で知識格差があるのかわかりにくい」，奥野教授から「滞在という言葉は一時的なニュアンスのため，この場合では違和感がある」，南部准教授から「格差という言葉を安易に使わないほうが良い」「満喫できないと言い切るのは押し付けがましく感じる」というフィードバックをいただいた．また「函館の良さにより多く気づくことができるような，信頼性の高い地域情報を共有する場を作る」という目的の変更に伴い，問題→目的までの関連性が薄くなったように感じたため，内容の訂正を行った．最終的に，まずブレインストーミングを行い，メンバで知識に差が現れたことから，「函館外出身者の知識を函館出身者と同じくらいのレベルにまで引き上げることで，函館外出身者も函館をより楽しめるようになるのではないか」という問題発見の流れを記述し，函館外出身と函館出身者，両者の知識を同じレベルに引き上げるために目的へ，という内容となり，曖昧な問題例から，
主に問題の実例として私たち自身を使うという方式に変更した．

Group Report of 2022 SISP

- 10 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022（※文責: 鈴木瑞帆）

2.11

目的の明確化私たちの当初の目的は「函館の大学生や転勤者のような中期滞在者を中心として，短い滞在期間で函館を満喫できるように支援する」というものであった．これは前述したように「函館に関する知識格差があることによって，函館を満喫できる人とできない人が存在する」という問題を私たちが考え，この問題をもとに決めた目的である．
しかしメンバ全体で改めてこの目的が正しいか話し合ったところ，理想の目的としては，調べづ
らさ，函館の良さを気づかせてあげたいということ，知識の共有の三つを含む内容にしたいという考えとなり，この話し合いでは最終的に「情報の調べづらさを払拭し，函館に住む人が知識を共有
しあえることで，短い滞在期間であっても函館の良さをより多く気付ける場を作りたい」という目的に変更した．
一度この内容で中間発表用のポスターに記述したところ，南部准教授から，「一文に情報を盛り込みすぎていて，頭に入ってこない」「情報の調べづらさの払拭は目的ではなく目的達成による結果ではないか」というフィードバックをいただいた．このフィードバックをもとに「函館の良さに気付ける」「信頼性の高い情報の共有」の二つに重点を置いた「函館の良さにより多く気づくことができるような，信頼性の高い地域情報を共有する場を作る」という目的に変更した．
（※文責: 鈴木瑞帆）

2.12

アンケートによるアイデア評価

私たちのプロダクトの「はこレクト」は，対象者が元々私たち自身であり，FW によって見つけた問題ではないため，「はこレクト」が函館市民全体に必要とされているのかアンケートを作成し確認しようという目的を立てた．アンケートの作成後，南部准教授に添削していただいた．図 2.7が 1 回目の草案である．私たちは，アンケートの一つ一つにその質問に何の目的があるのか南部准教授と伊藤教授にプレゼンテーションを行った．まず，アンケート作成の必須事項であることの説明を受けた．まず男性と女性，年齢などこれらを問う質問が基本中の基本であり必須であること
や，私たちが書いた草案には回答者に何のために行うアンケートでどのようなことに利用されるのかなど，事前に説明が書いていなければ私たちが欲しているデータや回答を得ることはできないな
どと仰っていた．その後一つひとつの質問を添削していただいた．
まず，草案にある Q2「普段調べごとを行う際，どのようなものを使って調べますか．
」では，「調
べごとを行う際」と記載していたが，「レストランを調べる際」など具体的な条件を付け加え，調べる対象を統一すべきだと指摘を受けた．また Q3 も Q2 と同様の指摘を受けた．
次に Q7「私たちは現在インターネットメディア (Web，SNS，Web ブログ) などから函館に関して発信している情報を集め，信頼できる情報のみを表示し利用者に情報を届ける製品を開発しております．この製品により情報を調べる際様々なサイトで比較したり，得たいと思う情報が信頼できるか調べる必要などはなくなると考えています．実際に私たちが開発している製品 (無料) が提供された場合使いたいと思いますか．」に記載した「はこレクト」の概要をアンケート冒頭に移動させ，回答を「はい」「いいえ」に設定した場合は得られるデータが少ないため「かなりほしい」「少しほしい」「あまりいらない」などのように段階で回答してもらった方がいいと仰っていた．

Group Report of 2022 SISP

- 11 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
また，最初に私たちはアンケートを行い「はこレクト」が必要とされているか問う目的で実施する予定であったが，南部准教授は「私たちがこのプロダクトが欲しているから他の人に必要かどうか確認するのではなく，アイデアを評価してもらうアンケートに方向性を変えたらあなたたちにより利点がある」とご指摘を受けたので，アンケートの目的をアイデアに変更することが決まった．
その後，南部准教授は「言葉としてアンケートの利用目的を書いてもいいが，動画などをアン
ケートに添付しそれを視聴してから回答してもらった方が回答しやすくなる」と仰ったため，私たちは「はこレクト」の機能を紹介したスライドを作成し声を埋め込み回答者のための簡単な動画を作成した．さらに，「『はこレクト』の機能に関するたたき台をいくつか作ることで，どの機能が必要とされているのかなど選別することができる」と南部准教授は仰っていたので，質問事項の中にいくつかたたき台を作ることにした．
また，伊藤教授は「信頼性がある情報を人がどのように判断しているのかデータとして得るために，Twitter の投稿でいいね数やリツイート数が多い投稿とそうでない投稿の二つを載せ，どちらが信頼できるか選んでもらった後，なぜそちらを選んだか記述してもらうことで今後「はこレクト」でどのように情報を選別するかの指標になる」とご意見を頂いたのでこの質問事項を今後のアンケートに書き加えることにした．以上のようなフィードバックを受け，私たちは 2 回目の草案と動画を作成したがまだ南部准教授や伊藤教授に添削をお願いできていないため，完成したアンケー
トに関する記述はできなった．ゆえに，後期の期末報告書を書く際に完成したアンケートについて述べる予定である．
（※文責: 外崎健介）

Group Report of 2022 SISP

- 12 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 2.7Group Report of 2022 SISP

アンケートの第 1 回目の草案- 13 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

2.12.1

アンケートの実施

アンケートは「はこレクト」のメインの対象ユーザである函館の大学生・専門学生に対して実施した．この際，図 2.8，図 2.9 のようなアンケートを作成した．アンケート内容としては，中間発表で利用する発表スライドを元に動画を添付し，動画閲覧後に質問に答えていただいた．動画の内
容を踏まえ，興味を持ったか，必要性があったかなど選択式の解答とともに，必須記述蘭と自由記
述蘭を設け，具体的なフィードバックを受けられるような質問項目を作成した．対象学校は公立はこだて未来大学，北海道教育大学

函館校，函館大学，函館工業専門高等学校，函館厚生院看護専

門学校，函館病院高等看護学校の 6 校に協力をお願いした．結果としては，計 75 名が回答してくださり，グラフより「はこレクト」に対して前向きな回答を多く頂いた (図 2.10)．私たちはこの結果を元に，今後のプロダクトに実装する機能の選定とデザインの改善を行った．
（※文責: 外崎健介）

Group Report of 2022 SISP

- 14 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 2.8Group Report of 2022 SISP

アンケート画面 1- 15 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 2.9Group Report of 2022 SISP

アンケート画面 2- 16 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 2.102.13

中間発表

2.13.1

準備

アンケートの実施

中間発表はプロジェクト間での交流を目的に行われ，それに向けプロジェクトの内容を紹介する
ポスターと，対面での発表で用いるスライドの作成を行った．中間発表の準備は 6 月 24 日から開始した．まず初めに，発表を誰が行うか話し合い，主に本グループ内での司会と進行をしていた外崎と如澤が担当することとなった．
本グループのスライドの作成では，グループ内で考えたスライドの構成や発表内容について，ス
ライド担当である鈴木がまとめた．その後，担当教員と TA の方々にレビューを依頼し，その内容を基に修正を行った．レビューと修正は合計 4 回行われ，修正は主にプロジェクトの授業時間外で行った．また，発表に向けてスライドの内容にそって原稿の作成も行った．中間発表は前半と後半に分かれており，発表者が異なるため，発表内容に違いが現れないように注意した．
ポスター作成では，まず本プロジェクトのポスター担当に，グループ部分の書く内容とレイアウ
トをまとめたポスター草案 1 (図 2.11) を提出した．完成したポスターはプロジェクトメンバや担
当教員，TA がレビューを行い，その内容を基に，ポスターの修正を行った．
中間発表の直前の授業時間では模擬発表を行い，時間配分や機材の確認，声量の確認を行った．
また本グループでは，中間発表の際に想定される質疑応答をまとめ (図 2.12)，発表が円滑に進む
ように準備した．
（※文責: 如澤駿介）

Group Report of 2022 SISP

- 17 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 2.11

Group Report of 2022 SISP

ポスター草案 1- 18 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 2.122.13.2想定される質疑応答

中間発表

中間発表は 7 月 8 日の 15 時 20 分から対面で行われた．前半と後半に分かれており，どちらも

15 分 3 セットであった．最初の 10 分で事前に作成したスライドを用いて本プロジェクトと三つのグループの紹介をし，5 分で質疑応答を行った．来場者には質疑応答と並行して，発表方法や内容を評価するアンケートに協力してもらい，発表以外の時間にはポスターを見るよう促した．本プロ
ジェクトの発表形式は，全体の説明をする発表者 1 名，各グループの発表者 1 名の合計 4 名であった．本グループの質疑応答内容は図 2.13 に記載された通りである．
（※文責: 如澤駿介）

図 2.13

2.14

本グループの質疑応答内容

機能の考案「はこレクト」の機能を 7 月 15 日にブレインストーミングを用いて考えた．ブレインストーミン
グでホワイトボードに案をできるだけ書いた後，その案を Miro を用いて図 2.14 のように振り分け
た．振り分けの内容としては，以下のように振り分けた．

• 赤色の付箋は，特に重要な機能で，その機能さえあれば最低限リリースできるようなもの．
• オレンジ色の付箋は，重要な機能で，「はこレクト」の機能として全メンバが絶対に実装したいもの．

• 水色の付箋は，絶対に実装したいわけではないが，あればいいと思うもの，かつ，実現できそうなもの．

Group Report of 2022 SISP

- 19 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
• 青色の付箋は，絶対に実装したいわけではないが，あればいいと思うもの，かつ，実現が難しそうなもの．
赤色の付箋に関しては，ホーム画面 (最新の情報を取得・表示する) やアカウントは作らないことなどが挙げられた．オレンジ色の付箋に関してはワード検索機能やカテゴリ検索機能などが挙げられた．水色の付箋に関しては，急上昇の表示，動画の自動再生機能などが挙げられた．水色の付
箋に関しては，BAD 機能や検索履歴が挙げらた．今後，赤色の付箋とオレンジ色の付箋に関しては，ユーザーストーリーを作成し，詳細まで決める予定である．
（※文責: 中野瑛斗）

図 2.142.15

機能の話し合いエレベーターピッチの作成

私たちが提供したいプロダクトについての情報を具現化し，メンバ間で共通のプロダクトのイメージを持つため，エレベーターピッチを活用することにした．エレベーターピッチとはビジネスプランを PR するプレゼン手法の一つである．文字にして 250 文字程度，時間にして 30 秒ほどで，自分の意見を要約し的確に伝えることができ，必要最低限の情報でプロダクトのイメージを統一するために適した手法といえる [11]．現時点でのプロダクトについての情報をまとめると以下のようになった (図 2.15)．

• 函館の良さにより多く気づくことができるような信頼性の高い地域情報を共有する場を作りGroup Report of 2022 SISP

- 20 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
たい，

• 函館の中期滞在者向けの，•「はこレクト」というプロダクトは，• 情報発見 web アプリケーションです．
• これは複数のソーシャルメディアにある函館の情報をまとめて閲覧することができ，• Twitter や Instagram などの SNS とは違って，• 複数の信頼性のあるソーシャルメディアから函館の情報をまとめて検索，閲覧できる機能が備わっています．
エレベーターピッチの作成は，今後プロダクトの詳細な内容を構想するにあたって，メンバそれぞれが共通の認識を持つために重要であったといえる．
（※文責: 鈴木瑞帆）

図 2.15

2.16

作成したエレベーターピッチ

役割決定

夏休みに入る直前に，スクラムを用いて開発をしていく上で，プロダクトオーナー，スクラムマ
スターを決めなければならなかった．プロダクトオーナーは，スクラムチームから生み出されるプ
ロダクトの価値を最大化することの結果に責任を持つ役割を持つ [12]．スクラムマスターは，スク
ラムガイドで定義されたスクラムを確立させることの結果に責任を持ち，スクラムチームと組織において，スクラムの理論とプラクティスを全員に理解してもらえるよう支援する役割を持つ [12]．
各メンバに誰がプロダクトオーナーやスクラムマスターにふさわしいかを話してもらい，その後，全メンバが納得したうえで，役割が決定した．プロダクトオーナーは如澤駿介，スクラムマスターは中野瑛斗，そして，残りのメンバは開発者という結果になった (図 2.16)．
（※文責: 中野瑛斗）Group Report of 2022 SISP

- 21 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 2.16

プロダクトオーナーとスクラムマスターが決まったときの様子

Group Report of 2022 SISP

- 22 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

第 3 章 夏休みの活動
3.1

夏休みのスケジュール

前期までで，ターゲットの明確化 (ペルソナの制作) ，おおまかな実装したい機能の考案，使用
ソーシャルメディアの規約調査，類似アプリとの比較など，作りたいプロダクトに関する調査と内容の構想について決まったので，以下のことをを夏休み中に行うことにした．

• ユーザーストーリーマップの作成による詳細な実装機能の考案• 実装機能の優先順位の設定• ワイヤーフレームの作成• 技術検証またプロダクトの開発に必要な言語などの技術習得も夏休み中に概ね完了することを目標とし，
夏休み終了後すぐに開発に着手できるよう活動した．なお，対面で集まることが難しいと判断し，各自の進捗を報告するため，15 分程度のデイリースクラムを平日の 22 時から行った (詳細は 4.2.6
節で述べる)．
（※文責: 鈴木瑞帆）

3.2

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

前期の時点で想定するユーザのペルソナを作成していたため，ペルソナを基に図 3.1 のようなユーザーストーリーマップの作成を行った．作成には Miro を用いたが，枠組みはテンプレートではなくインターネットで紹介されているものを複数参考に，簡単なものを自作した．ユーザがアプリで利用すると考えられるページを利用する順番に記述し，その各ページでどのような機能が必要かを，グループで話し合いながら考案した．その後 MVP（Minimum Viable Product）の設定を行った．MVP とは，実用に足る最小限の機能のみを備えたプロダクトのことであり，全ての機能の実装を一気に行う場合と比べると，より短時間で仮説や結果の検証を行うことができるという利点がある [13]．具体的に行ったこととしては，まず考案した全ての機能に開発の優先順位を付けて，その後優先順位の上位部分から見ていき，この部分までの機能があればアプリ内で必要最低限のやりたいことはできる，と私たちが考えるラインを，全員で話し合って設定した．開発するプロダクトの最低限実装したい機能がどこまでなのか，その線引きを行うことでメンバ全員が開発の区切りとなる部分を把握することができた．
（※文責: 鈴木瑞帆）

Group Report of 2022 SISP

- 23 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 3.1

3.3

ユーザーストーリーマップ (画像は 90 度回転)

ワイヤーフレームの作成

開発においてアプリケーション班，デザイン班など明確な役割の区切りをつけてはいなかったが，実装機能について全員で話し合い，ユーザーストーリーマップの作成により MVP を既に設定しているため，メンバの鈴木を中心に，MVP に対応した図 3.2 のような大まかなワイヤーフレー
ムを作成した．作成には Figma[14] を用いた．作成したワイヤーフレームはメンバ間で共有し，全員でおかしいと思ったことや，この機能は MVP として実装すべきなのかを話し合い，出た意見を基に再度ワイヤーフレームの修正を行った．これによりプロダクトの具体的なイメージをメンバ全員が把握できたため，今後の開発に大いに役立ったといえる．
（※文責: 鈴木瑞帆）

Group Report of 2022 SISP

- 24 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 3.2

3.4

スマートフォン版，PC 版のワイヤーフレーム (一部を抜粋)

技術習得

私たちのグループには Web アプリケーションの開発経験がある人がいなかったため，開発予定のプロダクトに使用する言語やシステムの利用方法などについての理解が無い状態であった．そのため「Progate」[15] というオンラインプログラミング学習サービスを使って，プロダクトの開発に必要な言語などの技術習得を行った (詳細は 6.7 節で述べる) ．また Vue.js や Firebase Realtime

Database など，Progate に無い言語や技術などに関しては，各自が参考書を購入またはレンタル
して勉強を進めた．各自の勉強の進捗は平日にあるデイリースクラムで報告を行った．
（※文責: 鈴木瑞帆）

3.5

UCD ワークショップ

9 月 18 日 (日) ，9 月 19 日 (月) の 2 日間にわたり，enPiT(成長分野を支える情報技術人材の育成拠点の形成)[16] という教育プロジェクトによる取り組みの一つである UCD ワークショップに，グループ全員で参加した．ワークショップは大阪芸術大学の木塚あゆみ講師を迎え，未来大学
内にて対面で受講した．人間中心のデザインの考え方とその設計方法について，短期集中の講義および演習 (システムの考案，ジオラマ制作，ジオラマとスライドを用いた発表) を通して学んだ (図3.3)．システムを使用する側の人間，つまりユーザを中心としたシステムを開発することの必要性を学ぶことができ，ユーザの立場から見て利用する価値がある，使って満足ができるシステムとはどのようなものなのかを学ぶことができた．
（※文責: 鈴木瑞帆）

Group Report of 2022 SISP

- 25 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 3.3 UCD ワークショップ内での発表資料 (一部を抜粋)

3.6

縮小スクラム（スクラム練習）の実施

縮小スクラムは後期から行う本スクラムの練習として，夏休みの最終週 (9 月 21 日 (水) から 9
月 27 日 (火) まで) に開催した．各スクラム活動に関しては後述するが，スプリントプランニン
グ，デイリースクラム，スプリントレトロスペクティブを実際に行い，スプリントレビューは本ス
クラムから行うため今回は無しとした (代わりに初回の本スクラムのスプリントレビュー内で縮小
スクラムの説明も行った) ．
今回のスプリントでは主に，先述したワイヤーフレームを基としたプロトタイプの作成に取り組んだ．達成度としては，HTML・CSS を用いて，1 週間でほぼ Figma のワイヤーフレーム通りの見た目に仕上げることはできた．ただし夏休みの段階で Vue.js を用いて Twitter と Instagram の投稿を取得し，ブラウザで情報が見える形にするまでが目標だったが，Vue.js で直接投稿を取得するのが難しいことがわかったため，この時点では投稿をイメージ画像で代用することとした．
今回のスプリントを通して， 私たちは 1 週間でスプリントを回すことが困難であることを理解し，本スクラムは 2 週間で回すこととした．また使用ツールの採用に関しては，今回のスクラム中に使用してみた結果，Git のコマンド操作による開発難易度を下げるために SourceTree の使用を，
プロダクトバックログの管理や進捗情報の共有のため，GitHub との連携が強い Zenhub の使用を決定した．
（※文責: 鈴木瑞帆）

Group Report of 2022 SISP

- 26 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

第 4 章 後期の主な活動
4.1

スクラムの説明会

プロジェクト後期の活動が始まってすぐに，スクラムマスターの中野が地域メディアグループのメンバ全員と交通支援グループの一部のメンバに対し，スクラムについての説明会を行った (図4.1)． この説明会をするきっかけとなったのは，スクラムマスター以外のメンバはスクラムに関してまだ分からないことが多く，このまま開発に進んでしまってもスクラムを用いた開発は十分にできないだろうと考えたためである．この説明会のために，スクラムに関するスライドを作成した．
このスライドは，「SCRUM BOOT CAMP THE BOOK」というスクラムについての本や，Ken

Schwaber 氏と Jeﬀ Sutherland 氏によって作成されたスクラムガイド 2020，スクラムについて書かれた Web サイトを調べたうえで作成した．主に，スクラムとはそもそも何なのかやスクラムにおけるイベント，よく使われる用語についての解説などを説明した．ただメンバが聞くだけの会にはならず，分からないことがあればすぐに質問が飛んできたり，解説者の中野が参加者に対し理解しているかの確認をとっていたりして，相互的なコミュニケーションをとることができ，有意義な時間にすることができた．
（※文責: 中野瑛斗）

図 4.1

4.2

スクラム

4.2.1

スクラムについて説明会の様子スクラムとは，世界で最も採用されているアジャイル開発プラクティスである．スクラムの基本
単位はスクラムチームという小さなチームである．スクラムチームは，スクラムを確立させることの結果に責任を持つ役割であるスクラムマスターが 1 人，スクラムで生み出されるプロダクトの価Group Report of 2022 SISP

- 27 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
値を最大化することの結果に責任を持つ役割であるプロダクトオーナー 1 人，各スプリントにおいて，利用可能なインクリメントの作成を行う役割である開発者が複数人のメンバで構成される [12]．スクラムの学習について，プロジェクト内で行ったスクラム講習会のアジャイルワークショップ
や，「SCRUM BOOT CAMP THE BOOK」というスクラムに関する本を読んだりして，スクラ
ムの概要や進行の仕方について学びを深めた．
（※文責: 中野瑛斗）

4.2.2

スプリントについて

スプリントとは，開発チームが一定の作業を完了させる際の，短く区切られた期間を指す．このスプリントは主に，スプリントの目標を決めてそのスプリントで開発するプロダクトバックログア
イテムを選択し，選択したアイテムを実現するのに必要な作業に分解するスプリントプランニン
グ，毎日同じ時間，同じ場所で 15 分程度，今後の作業計画やスプリントゴールに対する進捗の確認・調整をするデイリースクラム，スプリントで完成した動作するソフトウェアをデモしフィードバックを得るスプリントレビュー，スプリントの中で改善事項を話し合い次につなげるスプリント
レトロスペクティブの 4 つのイベントで構成され，プロダクトゴールを達成する為に必要なすべての作業は，スプリント内で行われる．
私たちのグループは，縮小スクラムでは 1 週間を 1 スプリントとして，9 月 21 日から 9 月 27 日
まで活動したが，本スクラムでは 2 週間を 1 スプリントとして，10 月 3 日から 12 月 10 日までの
計 4 スプリント (スプリント 0 と中止したスプリントは含まない) で活動を行った (表 4.1)．ここで，私たちのグループでは，開発に対するモチベーションを低下させないため，基本的に本スクラ
ムの土日をスプリントの期間に含めない方法を実践した．
また，私たちは本スクラムを始めるための準備期間として，1 週間のスプリント 0 を導入した．
このスプリント 0 では，主に，スケジュールの設定やプロダクトバックログアイテムの完成の定義の決定などをした．
（※文責: 中野瑛斗）

スプリント期間全体

2022/9/21 ∼2022/12/9

縮小スクラム期間

2022/9/21 ∼2022/9/27
2022/9/21 ∼2022/9/27

スプリント 1
本スクラム期間

2022/10/3 ∼2022/12/10
スプリント 02022/10/3 ∼2022/10/7

スプリント 1(中止)

2022/10/10 ∼2022/10/13

スプリント 12022/10/17 ∼2022/10/29

スプリント 22022/10/31 ∼2022/11/11

スプリント 32022/11/14 ∼2022/11/25

スプリント 42022/11/28 ∼2022/12/10

表 4.1

Group Report of 2022 SISP

スプリント期間一覧- 28 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

4.2.3

スプリントプランニングについてスプリントプランニングでは，スプリントバックログを作成してそのスプリントでやらなければ
ならないことの計画を立てた．このイベントでは，スプリントプランニングを通して，スプリント
ゴールや開発スコープ，プロダクトバックログアイテムの作業内容の認識を合わせることが目的である．
各スプリントの始めにスプリントプランニングを行い，グループ内で取り掛かるタスクの決定や時間の見積もり，タスクの細分化，担当メンバ決めなどを行った．これにより，スプリント期間内で迷わずにタスクに取り掛かることができた．また，タスクの細分化によって難易度を下げること
や見積もりの精度を上げることができ，より効率的な制作・開発に役立った．
（※文責: 中野瑛斗）

4.2.4

プロダクトバックログについて

プロダクトバックログとは，創発的かつ順番に並べられた，プロダクトの改善に必要なものの一覧である [12]．つまり，プロダクトバックログとはプロダクトゴールを達成する為に作成される必要なもののリストである．したがって，プロダクトバックログをすべて完了すると，プロダクトが完成するというイメージである．ただ，スクラムにおいて，プロダクトバックログがなくなるという事は決してない．なぜなら，開発が続くか終わるかは別として，少しでも良くしようとするのが，スクラムの原動力だからである [1]．
（※文責: 中野瑛斗）

4.2.5

スプリントバックログについてスプリントバックログは，プロダクトバックログの一部であり，特定のスプリント期間中に完了させる作業アイテムをリストアップしたものである．つまり，プロダクトバックログの中から，ス
プリントで行うプロダクトバックログアイテムを選び出したそれらのまとまりがスプリントバック
ログなのである．
（※文責: 中野瑛斗）

4.2.6

デイリースクラムについて

デイリースクラムとは，スプリントゴールを達成する為に，昨日やったこと，今日やること，障害や問題点を話すイベントである．もし，問題を見つけたら，デイリースクラムの後に，必要な人だけが残って，話し合い，対策するイベントでもある．私たちのグループでは，1 回 15 分間で，Discord を用いた同期型オンラインで行った．記録方法としては，口頭で各自の状況を話しつつ，記録者 (主にスクラムマスターの中野) が Google Docs にも記録を取った (図 4.2)．最初は夏休み
中の平日 22 時から，各自の作業 (主に技術習得やその日の日常の活動内容) の報告のみを行っていた．後期授業開始後はスクラムと組み合わせて，平日かつプロジェクト学習が授業で無い月曜・火
曜・木曜の 22 時から，スクラムに対するその日の進捗，翌日行うこと，活動中の問題点の報告をGroup Report of 2022 SISP

- 29 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
行っていた．
（※文責: 鈴木瑞帆）

図 4.2

4.2.7

デイリースクラムの記録 (一部を抜粋)

リファインメントについてリファインメントとは，プロダクトバックログの見直しを行う活動である．私たちのグループでは，リファインメントは，グループの誰かがプロダクトバックログアイテムやタスクを追加した日のデイリースクラムの時に行った．また，2 週間のうち，毎週水曜日に何か必要なタスクなどないかを呼びかけるリファインメントも行った．これによって，次回のスプリントで必要なタスクを洗い出すことが出来たり，「はこレクト」に必要なアイデアを発散することができた．
（※文責: 中野瑛斗）

4.2.8

スプリントレビューについて

スプリントレビューとは，ステークホルダに向けてスプリントでの作業の結果を報告すること
で，様々なフィードバックを得るイベントである．私たちのグループでは，まず，スプリントが始まったら，ステークホルダの人たちにいつスプリントレビューを行うかを Slack で呼びかける (図4.3)．そして，スプリントレビューが始まるまでに，ステークホルダのための簡単な資料を作成す
Group Report of 2022 SISP

- 30 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
る．そして，スプリントレビュー当日，作成したレビューを元に，スプリントゴールの説明，完了したタスク，完了できなかったタスクをステークホルダに説明し，その後に，実際にそのスプリントでできた「はこレクト」を触ってもらい，フィードバックを得た．このイベントにより，グルー
プ内のディスカッションでは気がつかなかった問題点を確認することができた．また，「はこレクト」のデザイン面でのアドバイスやコンセプトの部分でのアドバイスを頂き，短期間でより効果的なアプリケーションに改善することができた．
（※文責: 中野瑛斗）

図 4.3

4.2.9

スプリントレビューの呼びかけの様子

スプリントレトロスペクティブについて

スプリントレトロスペクティブはスプリントの最後に行うイベントである．スプリントレトロス
ペクティブの目的は，次のスプリントの品質や効果を高めるために，グループを対象として改善・育成するための議論を行うことである． スプリント単位で振り返りを実施することで，解決すべき課題や人間関係の問題，実施すべき内容の最適化等を実施する．私たちのグループでは，Miroというオンラインホワイトボードツールを利用して，各メンバがスプリントごとの活動を Keep(続けたいこと)，Problem(問題があったこと)，Try(今後の行動) に分け，それぞれ 5 分測って書き込
み，その書きこんだ内容を各メンバが発表していった (図 4.4)．その後，Action(Try の中で本当に実施すること) を 10 分議論したのち，決定した．このイベントでは，ポジティブな意見や感想を言い合うことをメンバで意識しあった結果，グループ内の雰囲気が良くなり，絆が深まった．
（※文責: 中野瑛斗）Group Report of 2022 SISP

- 31 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 4.4

4.3

スプリントレトロスペクティブを実施している様子

スプリント 0スプリント 0 は 10 月 3 日 (月) から 10 月 7 日 (金) にかけて行われた．このスプリントでは主に本スクラムを始めるにあたっての準備を整える目的で行った．まず，開発を進める上でスクラムに対する理解が必要であったため，メンバの中野が資料を作成し，スクラムの説明会を行った．また，当初はこのスプリントから本格的な開発を行う予定であったが，事前準備をしっかり行うべきと全体で判断したため 1 週間後の 10 月 10 日 (月) から本格的なスプリントを開始することにした．また，スプリントの期間を 2 週間とし，今後のスケジュールを立て，リファインメントのやり方やルールなどの詳細を決定した．さらに，PBI (プロジェクトバックログアイテム) のそれぞれのタスクの難易度を「簡単に終わる」，「少し大変」，「難しそう」の三つに分け見積もりを行った．
さらに，スプリントをレビューしてもらうステークホルダを決め，開発における最小限のコーディ
ング規約も決定した (図 4.5)．
（※文責: 外崎健介）

Group Report of 2022 SISP

- 32 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 4.5

4.4

スプリント 1 (中止)

4.4.1

期間

コーディング規約

スプリント 1 の期間は 10 月 10 日 (月) から 10 月 13 日 (木) である．
（※文責: 近藤篤）

4.4.2

スプリントの目的

スプリント 1 の目的は「ユーザが函館に関する Twitter や Instagram の投稿を閲覧することができる (信頼性があるかどうかは後回し) 」である．
（※文責: 近藤篤）

4.4.3

中止した理由10 月 12 日 (水) に夏休みに何を行ったか，スプリント 0 で行ったこと，現在抱えている問題や悩みを伊藤教授，奥野教授，元木准教授に共有した．そうしたところ，出力される投稿情報の信頼性を先に行った方が良いのではないかという指摘を頂いた．その指摘を基に，メンバで話し合った
結果，私たちが推していたポイントである情報の信頼性を後回しにしているスプリント 1 の目的が適切ではないと判断したためスプリント 1 を一度中止し，プロダクトのコンセプト部分から見直すこととなった．

Group Report of 2022 SISP

- 33 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022（※文責: 近藤篤）

4.5

コンセプトの見直し「はこレクト」のコンセプトはユーザに函館の信頼性の高い情報を届けることであり，Twitter

API や Instagram API を利用して函館の投稿を Web アプリケーションに表示することであった．
ゆえに，私たちは先に投稿を表示することを実践し，その後，情報の選別基準や選別の精度の向上について考える計画を立てていた．しかし，「はこレクト」の本質は「ユーザに函館の信頼性の高い情報を届けること」であったため，投稿を Web アプリケーションに表示する前に投稿の情報の選別基準や選別の精度の向上について先に取り掛かることにした．しかし，情報とは受け取る人や状況など条件下によって信頼性というのは人それぞれで異なり，ユーザ全員に確実に信頼できる情報を提供することは難しいという問題が生じた．ゆえに，信頼性の高い情報を提供するのではな
く，ユーザが知りたい情報を提供する方針になった．また，この方針の変更に伴い，エレベーター
ピッチの内容も変更し，「はこレクト」のコンセプトの見直しと最終決定をした (図 4.6)．
（※文責: 外崎健介）

図 4.6

4.6

スプリント 1

4.6.1

期間

新しく作成したエレベーターピッチ

スプリント 1 の期間は 10 月 17 日 (月) から 10 月 29 日 (土) である．本来のスプリント 1 の期
間は 10 月 28 日までであったが，スプリントレトロスペクティブを 10 月 29 日に行うこととなったため，スプリント期間を 1 日延長することとなった．
（※文責: 近藤篤）

Group Report of 2022 SISP

- 34 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

4.6.2

スプリントの目的

スプリント 1 の目的は「投稿選別における価値基準の決定と成果発表会のためのデモを完成させる」である．
（※文責: 近藤篤）

4.6.3

何を達成できたかスプリント 1 では投稿選別用のデータ取得を Google Sheets の拡張機能である Tweet Archiverを用いて「#函館」が付けられた Twitter の投稿を取得し，取得した投稿を各々が閲覧し，分析し評価するという投稿選別の流れを決め，実際に行うことができた．また，成果発表会用のデモで表示する投稿の個数とカテゴリの種類・個数を決定することができた．
（※文責: 近藤篤）

4.6.4

何が問題だったか

スプリント 1 の「投稿選別の基準を決定する」について選別をどのように行うかについては定まったが，扱いの難しい投稿が発見され，その投稿をどう扱うかが問題となった．それらの投稿は以下の通りである．

•「函館」というキーワードが入っていない函館に関する投稿• Twittbot などの Bot による投稿• Bot ではないが毎日同じような投稿をしているアカウントの投稿•「#函館」が入っているが函館に関する地域の情報が入っていない内容の投稿
また，「デモの完成」については表示するデザインが決定していないこと，Instagram の埋め込
みコードが Vue.js で上手く読み込めず表示できないこと，Facebook の埋め込み表示が大きくその調整が難しいことが問題として挙げられた．
（※文責: 近藤篤）

4.6.5

スプリントレビュー

10 月 28 日にスプリントレビューが行われ担当教員，TA からレビューをいただいた．スプリン
ト 1 のスプリントレビューでは，まずプロダクトの概要を説明してから，前回のスプリントを中止した経緯を説明し，縮小スクラム，スプリント 0，スプリント 1 で行ったことを説明した．発表に関して，スプリントバックログの説明を細かくする必要がないこと，ステークホルダからどのようなレビューが欲しいのかをあらかじめ示すべきだという意見をいただいた．プロダクトの説明か
ら，ユーザにとってどのような情報がでてくるのが嬉しいかを考えて機能や投稿選別を行うべきであり，そのために対象ユーザを明確化するべきだという意見があったため，対象ユーザを函館市内の大学生や専門学生であると明確化した．また，開発を PC デザインをベースに行っているが，利用するユーザはスマートフォンで使用することを想定しているため，スマートフォンベースで開発

Group Report of 2022 SISP

- 35 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
する方が良いのではないかという意見をいただいたため，スプリント 2 からはスマートフォンをベースに開発をすることに決定した．次に，作成した「はこレクト」のロゴデザインがスタイリッシュであり，プロダクトのコンセプトであるポップさと一致していないという意見があったため，スプリント 2 でロゴの修正をすることにした．その他にも，プロダクトのデザイン面に関して多くの意見があったため，スプリント 2 で修正を行う．
（※文責: 近藤篤）

4.6.6

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

10 月 29 日にメンバ間でスプリント 1 について振り返りを行った．良かった点としては，前回のスプリントよりも皆が作業をできていること，スクラムを回せたことによってスクラムの理解が前回のスプリントよりも深めることができたことが挙げられた．また，問題点としてメンバ間でプロダクトに関する認識の違いが生じており方向性が合っていなかったこと，タスクの振り分けや分割が曖昧なため自分がどのタスクを行えば良いかわからなかったことが挙げられた．これらの問題を解決するために，メンバの認識を合わせるためのコンセプト確認をスプリント 2 の冒頭でもう一度行うこと，一部メンバで作業を行ったときに取り決めたことや各々が考えて思いついたアイデアはデイリースクラムなどの話し合いの場で必ず共有すること，スプリントプランニングの際にタスクの分割・分業を怠らないことを取り決めた．
（※文責: 近藤篤）

4.7

スプリント 2

4.7.1

期間

スプリント 2 の期間は 10 月 31 日 (月) から 11 月 11 日 (金) である．
（※文責: 近藤篤）

4.7.2

スプリントの目的

スプリント 2 の目的はスプリント 1 で達成できなかった「投稿選別における価値基準の決定」を引き続き行うことと「ユーザがデモで Twitter と Instagram の選別された投稿を見ることができるように表示する投稿の枠組みを完成させる」ことである．
（※文責: 近藤篤）

4.7.3

何を達成できたかスプリント 2 ではスプリント 1 で決定した投稿選別の方法を基に Twitter の投稿に「函館」が入っている投稿を取得し，取得した投稿 1000 件に各々が，「はこレクト」で表示したい場合 1 点，
表示したくない場合 0 点を付け，合計値を算出した．その結果から，投稿に画像やリンクがないものは表示したくないと感じるということがわかった．また，投稿を分析する際に気づいたことをメGroup Report of 2022 SISP

- 36 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
モし，その内容についても話し合った．これらのことから，「はこレクト」で表示しない投稿の選
別ルールをいくつか決定することができた．その内容は以下の通りである．

• Bot が発信する投稿 (同じような投稿を連続でするため，ユーザが飽きてしまうと考えられるため)• 引用リツイート (引用元の投稿は良いものであることが多いが，引用リツイート投稿自体は表示したい情報でなかったため)• 函館近郊以外の地域の投稿 (函館近郊のみの情報を表示するというコンセプトとに違反してしまうため)• 投稿文だけの投稿 (分析結果から投稿文だけの投稿は表示したくない投稿であることが多かったため)
また，デモの作成に関しては，スプリント 1 で既存の埋め込みコードが上手く反映されないことやシステムの動作が重いためページを更新しないと表示されないことが問題として挙げられていた．そのため，当初は Twitter，Instagram，Facebook，TikTok，YouTube を用いてデモを作成する予定であったが，Twitter と Instagram に限定し，既存の埋め込みコードを使わずに各種 APIを用いて Firebase の Realtime Database に投稿データを一度保存し，そこから Vue.js で表示するシステムに変更することで問題を解決した．そのため，スプリント 2 では Python から Twitter

API と Instagram Graph API を用い投稿データを取得し，その投稿データを Realtime Databaseに保存し，Vue.js から Realtime Database に保存された投稿データを統一したデザインで出力することを達成できた．
（※文責: 近藤篤）

4.7.4

何が問題だったか

スプリント 1 のスプリントレビューでカテゴリのデザイン・順番に関して，様々な意見があり，カテゴリのデザインについては修正を行ったが，表示の順番についてはどの順番にするのが適切か定まらず実装することができなかった．また，投稿選別時に投稿に 0 点 1 点を付け合計値を算出し，合計点が 0 点・1 点の表示したくない投稿，合計点が 5 点・4 点の表示したい投稿に関してはメンバ全員で投稿を見て，その共通点を分析したが，合計点が 2 点・3 点の投稿に関してはどちらの分類にするべきか定まらず分析ができなかった．
（※文責: 近藤篤）

4.7.5

スプリントレビュー

11 月 11 日にスプリントレビューが行われ担当教員，TA からレビューをいただいた．投稿選別に関して，誹謗中傷や不正確な投稿は除外されているのかという質問をいただき，この時点ではそのような投稿についての対処を考えていなかったため，スプリント 3 の投稿選別では誹謗中傷やデマなどの不正確な投稿を出力しないように調整することとした．そして，「はこレクト」で使われているフォントが iOS と Android で異なっているという指摘を受け，スプリント 3 で使用するフォントを統一することとした．また，「はこレクト」のデザインに関して余白が足りないという意見や投稿をもっと大きく表示した方が良いという意見をいただいたため，スプリント 3 でも引きGroup Report of 2022 SISP

- 37 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
続きデザインの改良を行っていくこととした．
（※文責: 近藤篤）

4.7.6

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

11 月 11 日にメンバ間でスプリント 2 について振り返りを行った．良かった点としては，メンバの一人がスプリント期間の対面活動においてオンライン参加となってしまったが，コミュニケー
ションをしっかり取ることができたため開発を進めることができたこと，スプリント 1 で問題として挙げられていたタスク分割を前回よりも具体的に行えたこと，スプリントレビューの際にステークホルダから何についてのレビューが欲しいのかを明確化したことによって前回よりも具体的なレビューを貰えたことが挙げられた．また，問題点としては他の人が行っているタスクの進捗状況がわかりにくいこと，取り掛からないタスクを多く作ってしまったこと，タスクの分配が甘くスプリ
ント後半に行うタスクがなくなってしまったということが挙げられた．これらのことから，スプリント 3 では行っているタスクに関してメンバ間でレビューし合うこと，タスクをすべて消化したメ
ンバはスプリントレビューで使用するリリースノートなどの各種資料を作成することとした．
（※文責: 近藤篤）

4.8

スプリント 34.8.1

期間

スプリント 3 の期間は 11 月 14 日 (月) から 11 月 25 日 (金) である．
（※文責: 近藤篤）

4.8.2

スプリントの目的

スプリント 3 では「投稿選別の精度向上」，「ユーザがより函館の情報に絞られた投稿を検索機能とカテゴリ分け機能を用いて見ることができる」を達成するために検索機能とカテゴリ画面の実装を行う，「ユーザがシステムのデザインや UI が使いやすくなった「はこレクト」を使うことができる」を達成するために，デザインの改善を行うことである．
（※文責: 近藤篤）

4.8.3

何を達成できたかスプリント 3 では Twitter の投稿に関して新しく函館に関する投稿をしている特定ユーザの投稿も表示することを行った．それによって「函館」というキーワードが付いていない函館の投稿を表示させることを達成した．そして，スプリント 2 のスプリントレビューで指摘されたフォントの統一を行い達成することができた．また，スプリント 3 の目的である検索機能とカテゴリ分け機能の実装も達成することができた．他にも，Google Cloud Platform を用いて Twitter と Instagramの投稿取得を定期的に行う仕組みを実装することを達成した．

Group Report of 2022 SISP

- 38 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022（※文責: 近藤篤）

4.8.4

何が問題だったか

スプリント 3 の投稿選別の精度向上を行っている際に Instagram Graph API で「函館」をキーワードに投稿を取得していたが，投稿のリプライに「函館」とある投稿も取得してしまうことが問題として挙げられた．
（※文責: 近藤篤）

4.8.5

スプリントレビュー

11 月 25 日にスプリントレビューが行われ担当教員，TA からレビューをいただいた．新しく追加した特定ユーザの投稿を取得することに関して，ごはんカテゴリで表示しているユーザがごはん
以外の投稿をした時にも表示されてしまうという意見や特定ユーザの投稿を取得した際に，その投稿に関してもフィルタリングすれば良いのではないかという意見をいただいた．また，カテゴリの名称に関して，全て動詞で揃えるなど名称の粒度を合わせた方が良いという意見をいただいた．また，ホーム画面に戻るたびに謎の動画ファイルがダウンロードされてしまうという問題点を指摘していただいた．他にもデザインに関して，プロダクトで使用する配色を統一した方が良いという意見をいただいた．
（※文責: 近藤篤）

4.8.6

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

11 月 25 日にメンバ間でスプリント 3 について振り返りを行った．良かった点としては，スプリント 2 よりもタスクの分割や割り振りが適切であったこと，リファインメントをしっかり行ったためスプリントバックログの整理やタスクの見直しを行うことができたことが挙げられた．また，問題点としては特定メンバにタスクが偏ってしまっていること，スプリントレビューの際にメンバ内で認識の違いがでてしまったことが挙げられた．これらのことより，スプリント 4 ではスプリント
レビュー前日に情報共有する時間を確保すること，タスクを一人だけに任せるのではなくペアプロ
グラミングを導入し誰かと行うことを取り決めた．
（※文責: 近藤篤）

4.9

スプリント 44.9.1

期間

スプリント 4 の期間は 11 月 28 日 (月) から 12 月 10 日 (土) である．12 月 9 日に成果発表会があり，12 月 10 日にスプリントレトロスペクティブを行うこととなったため，スプリント期間を 1日延長することとなった．
（※文責: 近藤篤）

Group Report of 2022 SISP

- 39 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

4.9.2

スプリントの目的

スプリント 4 では「ユーザが投稿選別の精度が向上されて，デザインが改善された「はこレクト」を Web 上で見ることができる」を達成するために，スプリント 3 から引き続き投稿選別の精度を向上すること，投稿デザインの改善を行うこと，誰でも「はこレクト」を見られるようにするために Web 上に一般公開することである．
（※文責: 近藤篤）

4.9.3

何を達成できたかスプリント 4 では投稿選別の精度を向上するために，「はこレクト」を実際に使用し気になった
投稿を Google Docs にまとめ，その内容をメンバで議論し，新たな選別ルールを決めることができた．他にも，複数の画像がある投稿の場合，ボタンをタップすることで次の画像が見れるようにした．また，成果発表に向けて「はこレクト」を外部の人に触ってもらえるようにするために

GitHub Pages を使用し，インターネット上に「はこレクト」を公開することを達成した．
（※文責: 近藤篤）

4.9.4

何が問題だったか

スプリント 4 では，Twitter と Instagram の動画投稿のサムネイルが Android では表示されるが，iOS では表示されないという問題が見つかった．
（※文責: 近藤篤）

4.9.5

スプリントレビュー

12 月 7 日の成果発表リハーサルの際に担当教員からレビューをいただいた．公開方法に関して
その時点ではローカルホスティングしたものをデモで使用する予定であったため，同一ネットワー
クを使うことで重くならないかという意見をいただいた．また，検索機能に関して「グルメ」や「カフェ」と入力した際に，ネイルサロンの情報など入力したキーワードと関係のない投稿が出力されるという問題を指摘していただいた．他にも，複数の画像がある投稿の際にボタンを押すこと
で次や前の画像が見れるボタンの名称に関して，「前へ」「次へ」という名称ではなく，「前の写真」「次の写真」の方がわかりやすくて良いのではないかという意見をいただいた．
（※文責: 近藤篤）

4.9.6

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

12 月 9 日にメンバ間でスプリント 4 について振り返りを行った．良かった点としては，ペアプ
ログラミングを導入したことでタスクの分業が行えたことが挙げられた．また，問題点としてはス
プリントレビューを行う日が成果発表と被ってしまったため，レビューをあまり貰えなかったこGroup Report of 2022 SISP

- 40 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022と，成果発表の準備に時間を取られ，開発があまり進まなかったことが挙げられた．これらのこと
から対応策として，スプリントレビューをオフラインで行えるように資料やデモ動画を準備することが挙げられた．
（※文責: 近藤篤）

4.10

HAKODATE アカデミックリンク 2022

HAKODATE アカデミックリンク 2022 とは，11 月 10 日から 12 月 4 日の期間で開催された，函館市内にある八つの高等学校教育機関の学生が普段研究している内容や成果をプレゼンテーショ
ンやパネル展示で発表する合同発表会である．2022 年度は前年に引き続きオンライン開催となり，本プロジェクトの 3 グループ全てが出展することとなった．本グループでは，開発途中のプロダク
トを紹介するスライドを作成し，オンデマンド形式の展示を行った．スライド作成に関して，何度か担当教員にレビューを依頼し，より簡潔に伝わるようスライドを作成した．スライドの構成は最初にグループの活動とプロダクトの背景を説明し，その後に開発予定の機能の詳細と今後の予定を説明した．使用したスライドは，プロジェクト成果発表会で修正し使用したため，ここでは省略する。
賞を獲得することはできなかったが，スライドを作成する過程でプロダクトの背景部分や詳細な機能を言葉と図で伝わるようにまとめる必要があったため，再確認することができ，その後の開発に良い影響が出た．
（※文責: 如澤駿介）

4.11

成果発表会

12 月 9 日に開催されたプロジェクト成果発表会において，本プロジェクトの発表は，最初に全体の概要をスライドを用いて説明した後，3 グループがブースに分かれ，それぞれ発表を行う形式であった．本グループでは，ポスターとスライドを用いて発表を行った．ポスターは，これまでにやってきた活動やプロダクトの詳細を簡潔にまとめ，見に来た人がイメージをつかみやすいように心掛けて作成した．スライドは，アカデミックリンクで作成したスライドをベースに，開発が進んだ部分や変更した部分を加え，修正したものを使用した．使用したポスターとスライドはそれぞれ
付録 B と付録 C に添付する．ブースに訪れた方には，「はこレクト」を触ってもらいながら，スラ
イドを用いてプロダクトの背景と機能について詳細な説明を行った．発表では，来場者が質問しやすいように発表者が来場者に話しかけるなどを意識した．また，事前に質問される内容を考え，発表が順調に進むよう工夫した (図 4.7)．発表を担当したメンバ以外は，質疑応答の内容をメモに残す作業や，発表者が詳しく説明できない質疑について応答した．質疑応答のメモは，今後の開発に役立てるために残した (図 4.8)．「はこレクト」の評価として，本グループの課題であったデザイ
ンや UI で好評価を受けたため，今後もより使いやすいプロダクトにしていきたい．
（※文責: 如澤駿介）

Group Report of 2022 SISP

- 41 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 4.7Group Report of 2022 SISP

想定した質問- 42 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 4.8

4.12

成果発表会での質疑応答のメモ

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

enPiT BizSysD 北海道・東北合同発表会とは，会津大学，岩手県立大学，公立はこだて未来大学，室蘭工業大学が PBL を通して取り組んでいる内容を発表する合同発表会である．2022 年度の enPiT BizSysD 北海道・東北合同発表会には本プロジェクトから参加した 2 グループを含む 12
グループが参加し，12 月 10 日に oVice を用いたオンライン開催となった．参加にあたり，12 月

8 日にメンバと oVice の会場でリハーサルを行い，発表の練習と oVice の接続確認を行った．当日の発表には前日成果発表会と同じポスターとスライドを使用して説明を行った．発表は前後半に分かれており，参加グループは前半もしくは後半にそれぞれ 6 回の発表と質疑応答を行う形式であった．発表以外の時間は他のブースを訪れ，他のグループの発表を聴講した．質疑応答で出た意見や質問の内容をメモに残し今後の開発の参考になるようにした (図 4.9)．enPiT BizSysD 北海道・
東北合同発表会では，アイデア，技術，チーム開発，プレゼンテーションの項目で評価され，本グ
ループは技術の点において高い評価を受け，技術賞を受賞した (図 4.10)．発表以外の時間でも質疑応答などを通して他大学の方と話すことができ，また前日の成果発表会とは違った反応が得られたため貴重な機会であった．
（※文責: 如澤駿介）

Group Report of 2022 SISP

- 43 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 4.9

北海道・東北合同発表会での質疑応答のメモ

図 4.10Group Report of 2022 SISP

技術賞受賞後の写真- 44 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

4.13

ユーザからのフィードバック

現在私達は，最新の「はこレクト」を長期間利用してもらうユーザ数人と短期間利用してもらう
ユーザ多数にそれぞれアンケートを実施する予定である．このアンケートを元に得られる結果から
また「はこレクト」を改善していくことを検討している．
（※文責: 外崎健介）

4.14

最終報告書

最終報告書の作成は，成果発表会後の 12 月 21 日のプロジェクト活動から開始した．冬休みの期
間中に執筆できるように，21 日と 23 日の活動日に章立てと役割分担を決め，余裕を持って執筆した．執筆は Google Docs を使用し，メンバ同士で確認しやすいようにした．また，メンバごとに使う単語が異なることを防ぐため，「グループ」と「チーム」など頻出する単語は初めに統一した．
その後，Google Docs に書いた内容を Overleaf を用いて LaTeX でまとめた。
（※文責: 如澤駿介）

Group Report of 2022 SISP

- 45 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

第5章
5.1

開発したプロダクト「はこレクト」「はこレクト」の概要

本グループでは，函館近郊の情報発見を手軽にすることを目的とした Web アプリケーション「はこレクト」の開発を行った．
「はこレクト」は，ソーシャルメディア上にある函館近郊に関する投稿をリアルタイムで取得し，施設の情報などのみに選別して表示する Web アプリケーションである．
ユーザは「はこレクト」を通して，飲食店の情報やイベント情報など，函館近郊に関する情報を得ることができる．「はこレクト」という名前は，函館の情報を集めて表示することから，Hakodateと Collect を組み合わせて命名した．ロゴは，「はこレクト」を英語表記したときの Hacollect から，H，C，L を組み合わせて考えた (図 5.1)．
現在の「はこレクト」では，Twitter と Instagram の二つのソーシャルメディアから投稿を取得している．投稿の選別は，グループ内で定めたルールに基づいて行っている．詳細なルールは 5.4
節で述べる．主な機能として，投稿閲覧機能，カテゴリ別表示機能，キーワード検索機能がある．
「はこレクト」は基本的にスマートフォンで使用することを想定してデザインしている．投稿情報を表示する仕組みは，ソーシャルメディアから取得した投稿に関する時間や写真などの情報を一度
データベースに保存し，そこからデータを取得して表示するというものである．
（※文責: 如澤駿介）

図 5.1

5.2

「はこレクト」のロゴ

対象ユーザ「はこレクト」の対象ユーザは，主に函館市内の高等教育機関に通っていて，函館市での生活期
間が短い学生である．そのような学生に「はこレクト」を使ってもらい，函館近郊に関する情報を新たに発見して在学中の生活を豊かにしてもらうことを目標としている．
函館での生活期間が短い学生を対象としているが，生活期間が長い方でも新たな発見が多く，有用な情報が表示されているため，学生にとどまらず幅広い方に使ってもらえるプロダクトとなっている．
（※文責: 如澤駿介）

Group Report of 2022 SISP

- 46 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

5.3

「はこレクト」の機能「はこレクト」には，投稿閲覧機能，カテゴリ別表示機能，キーワード検索機能の三つの機能が存在する．以下で詳細について述べる．
（※文責: 如澤駿介）

5.3.1

投稿閲覧機能「はこレクト」には，複数のソーシャルメディアにある函館近郊にある投稿を閲覧できる機能を備えている．多くの投稿を一覧で見れるように，投稿に含まれている文章は一部のみ表示し，ユー
ザが気になった投稿を選択して全文を読めるようにしている．また，投稿元にアクセスできるようにし，アカウントや詳細の確認ができる．投稿閲覧画面は，ユーザが視覚的かつ直感的に使えるよ
うに意識してデザインした．投稿閲覧画面のスクリーンショットを図 5.2 に掲載する．
（※文責: 如澤駿介）

図 5.2

Group Report of 2022 SISP

投稿閲覧画面- 47 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

5.3.2

カテゴリ別表示機能

カテゴリには，「食べる」「見る」「知る」の三つがある．画面上部に，三つのカテゴリを配置している．
「食べる」カテゴリには，函館近郊の飲食店の情報など食に関する投稿を表示している．
「見る」カテゴリには，観光情報や景色の写真が含まれる投稿などを表示している．「知る」カテゴリにはそれ以外の情報がまとめて表示されている．現在は，それぞれのカテゴリに合ったキーワード
を決め，それらを含んだ投稿や，カテゴリに合った投稿をしているアカウントの投稿などを表示しているが，今後は画像認識の技術などを利用することで，カテゴリ分けの精度を上げることを検討している．
（※文責: 如澤駿介）

5.3.3

キーワード検索機能

キーワード検索機能では，画面上部の「キーワード検索」に何かキーワードを入力することで，それに関連した投稿が表示される（図 5.3)．現在のキーワード検索では，データベースにある投稿の本文データから，入力されたキーワードと完全一致した投稿のみが表示されており，類似性の高い投稿や関連のある投稿が表示されていない状態である．今後はそれらを改善して検索の精度を上げていく．
（※文責: 如澤駿介）

Group Report of 2022 SISP

- 48 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 5.3

5.4

検索後の画面

投稿選別方法「はこレクト」では，函館近郊に関する投稿かつユーザにとって有用な情報が含まれている投稿が表示されるよう，一定のルールに基づいて投稿の選別を行っている．選別するときのルールとして以下のようなものがある．

• 本文に「函館」を含み画像が載っている投稿を表示– 函館近郊の地域名が入った投稿を除外– 本文に特定のワードを含んだ投稿を除外– 投稿元が Twitter bot である投稿を除外• 函館近郊の情報発信しているアカウントの投稿は表示（※文責: 如澤駿介）

5.4.1

選別ルールの決め方

このルールを作るにあたって，Tweet Archiver[17] を使用して，Google Sheets に Twitter から「函館」というワードが入っている投稿を約 1000 件まとめた (図 5.4)．まとめた投稿をメンバ 5 人がそれぞれが確認していき，「はこレクト」に表示したい投稿を 1，表示したくない投稿を 0 として評価していき，投稿ごとに合計点数をまとめた．投稿を評価していく段階でメンバがそれぞれメモ

Group Report of 2022 SISP

- 49 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022を残し，どういった投稿を省くべきかまとめやすいようにした．その後，メンバのメモを参考に，合計点数が低い投稿から省くべき投稿にどういった共通点があるか話し合った．また，合計点数と画像付きなどの条件からグラフを作成して，どういった条件を含んだ投稿の合計点数が低くなっているのかを分析した (図 5.5)．
また，これだけでは本文に「函館」というワードが入っている投稿のみしか取得できないため，函館近郊の情報発信しているアカウントを探し，それらのアカウントの投稿は表示するようにした．
以上の過程を経て，土台となる選別ルールを作成した．その後，作成したルールをプログラムに起こして，実際に納得のいく投稿が表示されてるか検証した．ルールを適用した後，省きたい投稿が「はこレクト」に表示されていれば，その都度メモに残しプログラムを修正し，投稿選別の精度を向上していった (図 5.6)．
（※文責: 如澤駿介）

図 5.4

Group Report of 2022 SISP

ルール作成に使用した表- 50 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 5.5Group Report of 2022 SISP

分析結果の図- 51 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 5.6Group Report of 2022 SISP

気になった投稿のメモ- 52 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

5.5

使用した技術本グループでは，以下で述べる技術を用いて開発を行った．
（※文責: 如澤駿介）

5.5.1

HTML/CSSHTML と CSS は Web ページを構成するときに使用する言語である． HTML は，HyperText
Markup Language の略称で，Web サイトのコンテンツの構造を作るために使う，マークアップ言語である．コンテンツは段落，箇条書きのリスト，画像や動画の使用，データテーブルなどで構成されており，一定の表示や動作をされることができる．CSS は，Cascading Style Sheets の略称
で，Web ページのスタイルを設定することができるスタイルシート言語である．HTML で書いたコードに対して，文字の色を変更することや，特定の場所で表示することができる．
（※文責: 如澤駿介）

5.5.2

JavaScript

JavaScript は，Web ページにてアニメーションなどの複雑な動きを追加することができるプロ
グラミング言語である．動きを付けるだけでなく，アプリケーション開発などに広く使用され，サーバサイドで動く Node.js という言語も存在する．React や jQuery などのフレームワークが多く存在し，「はこレクト」の開発では Vue.js を用いた．
（※文責: 如澤駿介）

5.5.3

Vue.jsVue.js は ，Web ア プ リ ケ ー シ ョ ン に お け る ，ユ ー ザ イ ン タ ー フ ェ ー ス を 構 築 す る た め のJavaScript のフレームワークである．他のフレームワークに比べ学習コストが低く，導入が比較的簡単である．また，Evan You 氏が提唱したプログレッシブフレームワークであり，アプリ
ケーションの規模が変化した場合にも柔軟に対応できる．メンバは 5 人とも Web アプリケーショ
ン開発の経験が無かったため，Vue.js を用いて開発を行った．
（※文責: 如澤駿介）

5.5.4

PythonPython は，1991 年に公開されたオープンソースのプログラミング言語である．Python で書かれたプログラムは読みやすさやわかりやすさが重視されており，理解しやすいようにデザインされている．また，専門的なライブラリが豊富に存在し，科学技術計算のツールとしてデータサイエン
スの分野で広く使われている．「はこレクト」では，API を用いてソーシャルメディア上の投稿情報を取得することに利用した．

Group Report of 2022 SISP

- 53 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022（※文責: 如澤駿介）

5.5.5

Twitter API・Instagram Graph API

API とは Application Programming Interface の略称で，ソフトウェアから外部のアプリケー
ションの機能を利用するための仕様，またはインターフェースの総称をいう．公開されている API
を使用することで，対象のアプリケーションのデータへのアクセスが可能となる．「はこレクト」
では，Twitter と Instagram の情報を取得するために，それぞれ公開されている Twitter API とInstagram Graph API を用いて，投稿情報を取得している．
（※文責: 如澤駿介）

5.5.6

Google Cloud Platform

Google Cloud Platform とは Google が提供するクラウドコンピューティングサービスの総称である．Google Cloud Platform は Google と同じインフラストラクチャでアプリケーション，Web
サイト，サービスを構築，導入，拡大することができる．また，Google Cloud Platform は従量課
金制のサービスであるため，一定の使用量までは無料で使用できる．「はこレクト」ではクラウドサービスの構築と接続に使用するサーバーレスのランタイム環境である Google Cloud Functionsとバッチ処理，ビッグデータ ジョブ，クラウド インフラストラクチャオペレーションなどのジョ
ブをスケジューリングできる Google Cloud Scheduler を使用している．それによって，「はこレクト」は 15 分ごとに Twitter と Instagram の投稿を API を用いて取得することができている．
（※文責: 近藤篤）

5.5.7

Firebase Realtime Database

Firebase Realtime Database は，リアルタイムでデータベースを保存し，ユーザ間で同期ができる，NoSQL のデータベースである．データは JSON 形式で保存され，ユーザはオフラインでもデバイスに残ったキャッシュを利用してデータを利用することができる．「はこレクト」では，Python で取得した投稿情報のデータを一度データベースに保存し，データベースにあるデータを表示している．その際，Firebase Realtime Database を用いてデータの保存を行っている．
（※文責: 如澤駿介）

5.5.8

Git・GitHub

Git とは，ソースコードの変更を保存，追跡するための分散型バージョン管理システムである．
GitHub とは，Git を用いてクラウド上でバージョン管理をすることができる Web サービスである．Git と GitHub を使用することで複数人でコードをレビューし合いながら開発を行うことができる．メンバは 5 人とも Git と GitHub の使用経験が無かったため，6.5 節で後述する，

Git/Github 講習会を通して，使い方を学んだ．
（※文責: 如澤駿介）

Group Report of 2022 SISP

- 54 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

5.5.9

Sourcetree

Sourcetree とは，Atlassian 社が開発した，Git の操作が効率的にできる GUI 形式のデスクトッ
プアプリケーションである．Git の操作は主に CUI 形式で行うが，Sourcetree を用いることで，視覚的，直感的にバージョンの管理を行うことができる (図 5.7)．メンバは 5 人とも Git の経験が無かったため，操作が理解しやすいように Sourcetree を導入して開発を行った．
（※文責: 如澤駿介）

図 5.7 Sourcetree の画面

5.5.10

ZenHubZenhub とは，GitHub の拡張機能で，タスクボードを追加することができる．本プロジェクトでの開発はアジャイル開発であるスクラム手法を用いて行ったため，スプリント毎のタスクの管理やプロダクト完成までのタスクを管理するため，Zenhub を導入した．スクラムの詳細は 4.1 節で説明している．
（※文責: 如澤駿介）

Group Report of 2022 SISP

- 55 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

第6章
6.1

知識・技術習得

リスク分析

プロジェクト活動を本格的に開始する前の段階で，各個人が，プロジェクト活動で起こり得ると思う問題と，その発生確率，発生した場合の被害，問題の対策について考えた．考えたものはランダムに分かれたグループ内で共有し，グループ単位で Google Sheets にまとめ，グループ発表，そして発表をもとに内容の調整をしつつ全体で一つの Google Sheets にまとめた (図 6.1 および付録

D)．その後奥野教授からフィードバックを頂き，今後活動中に様々な状況下でどのように動けば良いのかを，全体で共通知識として得ることができた (図 6.2)．
（※文責: 鈴木瑞帆）

図 6.1

Group Report of 2022 SISP

メンバのリスク分析をまとめたシート (一部を抜粋)- 56 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 6.2

6.2

リスク分析レビューの様子

アジャイル開発概論 (enPiT e-Learning)

プロジェクトの開始時に，事前ビデオ教材「アジャイル開発概論 (enPiT e-Learning) 」[18] の「プロジェクト学習のためのプロジェクトマネジメントの基礎」を視聴した．プロジェクトマネジ
メントとはなにか，プロジェクト内での役割について，プロジェクトを進めるうえで取り組んでいく内容 (計画，リスク分析，スケジュール管理など) についてを一つひとつ詳細に学び，これからのプロジェクト学習活動で必須となっていく知識を身につけることができた．またこれらの内容をメンバ全員が共通の知識として得ることで，今後のグループ活動の進め方などを円滑に話し合うことが可能となった．
（※文責: 鈴木瑞帆）

6.3

フィールドワーク入門講座

フィールドワークがどのような活動なのか理解するため，5 月 25 日 (水) に，南部准教授による対面でのフィールドワーク入門講座を，プロジェクトメンバ全員で受講した (図 6.3)．講座はスライドを用いて，そもそもフィールドワークとはなにか，実際に過去のフィールドワークではどのようなことを行い，どのような問題が発生したか，何に気を付けるべきか (注意事項) を教えていた
だいた [19]．実際に現場にいって問題点や解決の糸口を見つけることの重要さや，ただ街をぶらぶらするのではなく社会や文化を知るために観察と記録を怠らないことが大事であるということを学んだ．
（※文責: 鈴木瑞帆）

Group Report of 2022 SISP

- 57 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 6.3

6.4

フィールドワーク入門講座資料 (一部を抜粋)

スクラムワークショップ

前述したアジャイル開発概論 (enPiT e-learning) で得た知識を深めるため，6 月 10 日 (金) に，
株式会社アトラクタの永瀬美穂氏を講師に迎え，対面・オンライン同時開催のスクラムワーク
ショップ [20] を，プロジェクトメンバ全員で受講した (図 6.4)．なお，会場の対面人数が多かった
ため，私たちのプロジェクトはメンバ全員 493 教室でオンラインで受講した．前半はアジャイル開発についてビデオ教材の内容をより深堀りしたもののレクチャーが行われた．後半は，前半で得た知識を用いて，オンラインの投票サービス「Mentimeter」を用いたクイズ大会が実施された．動
画の説明以上に深く，実例的な内容を学ぶことで，アジャイル開発がどのように行われるか，どのようなメンバで分け，どう進めていくかをより理解することができた．
（※文責: 鈴木瑞帆）

Group Report of 2022 SISP

- 58 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 6.4

6.5

スクラムワークショップ資料 (一部を抜粋)

GitHub 講習会

開発に使用する Git と GitHub についての知識を得るため，7 月 27 日 (水) に，TA である未来
大学学部 4 年の畑大地氏による Git/GitHub 講習会を，未来大学内にて対面で受講した (図 6.5)．
講習会では，前半は昨年度に実際に使用したツールをまとめて紹介していただいた後に，そもそも Git や GitHub とは何か，使用するメリットの紹介をしていただき，後半では実際に Git と

GitHub を操作して，ブランチの作成やコミット・プッシュ・プルの方法など，基本的な操作方法を教わった．私たちのグループには Git と GitHub の使用経験がある人がいなかったため，実際に昨年度 1 年間使用してきた先輩方から教えてもらうことで，理解を深め，開発の具体的な流れを学ぶことができた．
（※文責: 鈴木瑞帆）

Group Report of 2022 SISP

- 59 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 6.5 Git/GitHub 講習会の様子

6.6

SCRUM BOOT CAMP THE BOOK スクラムチーム
ではじめるアジャイル開発

伊藤教授からプロジェクトメンバに一人一冊「SCRUM BOOT CAMP THE BOOK」[1] というアジャイル開発について書かれている書籍を貸していただいた．各自でアジャイル開発の手法の一つ「スクラム」について時間があるときに読んで学んだ．プロダクトオーナーやスクラムマス
ターなど役割の理解や，スクラムの始め方・見積もり方や，制作物についてもどのように進めていけばよいかを学んだ．
（※文責: 鈴木瑞帆）

6.7

オンラインプログラミング学習サービス「Progate」

私たちのグループには Web アプリケーションの開発経験がある人がいなかったため，夏休み中に，プロダクトの開発に必要な言語などの技術習得を行うために，オンラインプログラミング学習
サービス「Progate」の法人プランに加入させていただき，HTML，CSS，JavaScript を中心に学習を行った．Progate は一つのセクションにつき，およそ 10 枚以下のスライドで学習を行い，次に直前に学んだ内容を踏まえて実際にプログラムを入力することで，Web サービスを制作していくという学習方法であった．基本的な内容が丁寧に説明されているため，初心者の私たちも容易に技術の習得ができた．またレベルシステムが導入されており，セクションの進捗によってレベルがアップしていくため，自身の学習量や，他メンバと比較した自身の進捗などが可視化され，各自の学習量の増加に大いに役立った．
（※文責: 鈴木瑞帆）

Group Report of 2022 SISP

- 60 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

第 7 章 学び7.1

共通認識の重要さ

この前期のプロジェクトを通して共通認識が重要である事が分かった．活動序盤，伊藤教授から貸して頂いた書籍「SCRUM BOOT CAMP THE BOOK」[1] では共通認識が重要であることが何度も書かれていたため．グループでは共通認識を最優先にして活動を行った．例としては，プロダクトを作る目的や，誰のためのプロダクトなのかといった今後共通認識として重要になってくる
ものは何度も話し合った．これにより，中間発表までには形のあるものとなった．中間発表のためのスライドやポスターを作る際，各メンバは何のためのプロダクトなのかという疑問を持った時期があった．しかし，議事録などにしっかり共通認識について記載されていたため，それを見て思い出すことができた．また，今後開発を行う際，なぜプロダクトを作るのかや誰を対象者とするのかを考えなければならないため，そこを共通認識として定めることは重要だと感じた．
（※文責: 中野瑛斗）

7.2

議事録の重要さ

本グループではどのような経緯で何が決定されたのかを後から確認することができるよう，図7.1 のような議事録を執りながら活動を進めた．議事録はグループ活動が終わった後にも時間外活動として書かなければならず，多くのコストが必要であるが，それを上回るほどの利点が多くあることを学んだ．例としては，一つ一つの行動を記録できるため，報告書や発表スライドの作成の時に，議事録を見直すことで作成しやすくなることや，メンバにとって重要なことが共通認識として定まっているかを議事録を確認することで判断できることなどがある．議事録を見直すことで，メンバがそれぞれ次に何をやらなければならないのかを考えやすくなった．議事録はグループの進むべき方向を導いてくれるため必須のものであると考える．また，議事録を執ること以外に図 7.2 のような図を作成した．これは，グループ活動をする上で，何から始め，次に何をするのかを Google

Jamboard を用いて，視覚的に表した図である．中間発表などのイベントは黄緑色，まだ未着手のタスクは水色，作業中のタスクは赤色，完了したタスクは黄色で表現した．逐一，今後何をする必要があるのか，何が完了したのかを話し合い，その結果をこの図に加えていった．この図があることにより，各メンバは今何を優先してやるべきなのか，何が最後まで完了していないのかを一度で確認できるため，作業効率が向上した．

Group Report of 2022 SISP

- 61 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 7.1

図 7.2

実際の議事録の様子

理想の流れを Google Jamboard を用いて作成したもの（※文責: 中野瑛斗）Group Report of 2022 SISP

- 62 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

7.3

コミュニケーションツール

グループでの活動を円滑に進めるために，Discord や Slack，というコミュニケーションツール
を導入し，ホワイトボードや Miro を利用し，議論を行った. これらのツールを利用し，効率よく作業を進めた.
（※文責: 中野瑛斗）

7.3.1

Discord

プロジェクト時間外活動の作業を補助するツールとして Discord[21] を利用した．Discord とは
アメリカ発のチャットサービスであり，一般的に Discord はゲーマー向けのチャットサービスとして広く使われている．プロジェクト時間外での活動において効率よく作業できるように，ボイスチャットや画面共有機能を使用した．ボイスチャットや画面共有を使うことで，オンライン上でも誰がどの作業をしているかがひと目でわかったり，現在行っている作業に対してすぐに意見を求めたり意見を言うことができた．
（※文責: 中野瑛斗）

7.3.2

Slack

プロジェクト活動の進捗報告や連絡事項などを補助するツールとして Slack[22] を利用した．

Slack とは，チャンネルベースで行われるビジネス用のメッセージングアプリである．一般的にSlack はグループコミュニケーションツールとして使われている．このツールを使うことで，メンバが一つの場所に集まり，グループが一体となって働くことができた．
（※文責: 中野瑛斗）

7.3.3

ホワイトボード

グループ活動で話し合うときは，主に教室のホワイトボードを用いて活動していた．ホワイト
ボードを使う場合のほとんどはブレインストーミングを行うときである．メンバの意見をホワイトボードにすべて書くことで思考を発散させた．これにより，プロダクト案やプロダクトの対象者などを明確にする一助になったため，何かに行き詰って困ったときは，ホワイトボードでブレインス
トーミングを行うことがいいことを学んだ．
（※文責: 中野瑛斗）

7.3.4

Miro

既存サービスの調査や類似サービスとの比較をする時などに Miro[23] を利用した．Miro とは豊富なテンプレートと使い勝手の良い UI で，多くの人気を集めるオンラインホワイトボードツールである．一般的に，Miro は Web 会議などでオンラインホワイトボードとして使われる．このGroup Report of 2022 SISP

- 63 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
ツールを用いることにより，意見やアイデアが書かれた付箋を色をつけてグループ化することでメ
ンバ各自の興味の方向性を可視化することができ，話し合いを円滑に進めることができた．また，スプリントレトロスペクティブの際，スプリントを通して良かったこと (Keep)，問題だったこと(Problem)，今後行うべきこと (Try)，実際に次のスプリントで実践してみること (Action) をこの
Miro を使って決定した．
（※文責: 中野瑛斗）Group Report of 2022 SISP

- 64 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

第 8 章 個人の学び
8.1

如澤駿介

この 1 年間苦労は多くあったが楽しいと感じることばかりで，とても実りのある期間であった．
私がこのプロジェクトを通して最も学んだと感じることは，開発の大変さである．私自身，2021
年に開催された学内のハッカソンへ出場したことはあったが，ほとんど貢献できていなかったため，このプロジェクト学習がほぼ初めてのチーム開発であった．作るプロダクトが決まったとき，何から始めるか，どういうデザインにするか，担当はどうするかなど決めるべきことが多く，その際に苦労したのがグループ内でプロダクトへの認識が異なることだった．一部のメンバ間で認識が異なることが多く，プロダクトの方向性がずれることがあった．原因は，プロダクトの背景や対象
ユーザ，プロダクトを作る上での目的など，話し合いはしたが，話し合いを目的として後から確認することを怠ったため，普段の会話や開発などでずれが生じ，私たちのやりたい内容に偏っていたことだと考える．今では，仕様書などを作成し，後から確認する機会を設けるべきであったと考える．また，開発が進むにつれ，タスクの作業の分担が上手くできていなかった．一部のメンバにタスクが偏り，やることがないメンバが出てくることがあった．本グループでの開発は，初期は投稿を選別するためのルールの作成など，皆で同じ作業をしていたため，開発においての分担が曖昧になっていた．そのため，初期の段階でもっとプロダクトの機能を固め，担当する役割を明確にするべきであったと考える．
ただ，今回の開発で良かった点として，コミュニケーションを頻繁に取ったことが挙げられる．
グループが決まった当初は，ほぼ初対面のメンバ同士で会話は多いわけではなかったが，すぐに打ち解けコミュニケーションの取りやすい雰囲気になった．夏休みなどはほぼ毎日，進捗の報告や相談などを行っていた．そのため，互いに高め合い，モチベーションの維持に繋がったと考える．開発が進む過程で，認識のずれやタスクの分割など問題はあったが，すぐに相談して修正できたこと
は，コミュニケーションを頻繁に取っていたためだと考えられる．
このグループで私は，グループリーダと，プロダクトの責任者であるプロダクトオーナーを担当
したが，これらの役割を担当して学んだことがいくつかある．まず，リーダとしてグループでの活動が円滑に進むようサポートすることを学んだ．プロジェクトの 1 グループとして，全体のミー
ティングに参加することや，提出分の把握などグループ単位でやらなければいけないことがあれば率先して自分が担当し，他のメンバが自分の作業に注力できるようサポートした．しかし，グルー
プの士気を維持することはできていなかった．モチベーションを保つこともリーダとしてやることだと考えていたが，自分のモチベーションを保てていなかったため反省している．
またプロダクトオーナーとしてプロダクトに対しての意思決定を行った．もともと意思表示をするのは得意ではなかったため，プロダクトの方向性を全体の流れに任してしまっていた．しかし，プロダクトに対しての認識がグループ内でずれたこともあったため，意見が別れたときなどメンバ
それぞれが納得のいくように意見をまとめ，プロダクトの軸をはっきりさせるよう努力した．
スプリントレビューやプロジェクト学習成果発表会など，グループとして発表するときは自分が担当した．そこで学んだこととして，聞いている人は何を知りたいかを意識して資料作りと発表を行うことである．初回のスプリントレビューでは，やったことを淡々と話してしまったが，TA のGroup Report of 2022 SISP

- 65 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
方からどういったことが聞きたくて，どういったレビューを受けたいのか明確にするよう意識することをアドバイスして頂いたことで，聞く人のこと考え資料作りと発表を行うようになった．発表に使った資料にはポスターやスライドがあるが，やってきた活動やプロダクトの背景を，論理的にかつ簡潔に見やすくまとめることが大変であった．まとめる段階で，議事録などを参考に作成したが，やってきた活動などを端的にまとめた資料を作成していれば作成がスムーズに進んだと考える．
このプロジェクトを通して学んだこととして，技術の習得も大きい．コミュニケーションのツールとして Slack や Discord を使い，オンラインでのコミュニケーションを行ったが，文面で内容を伝えることや情報を整理しておくことの重要性を学んだ．また，アイデアをまとめるためのツールである Figma や Miro など様々なツールを使用し，その度に使い方を調べて有効に使うための方法を探り，ツールを有効的に使うことを学んだ．使ったツール以外にも開発に用いた言語や開発の流れを学ぶことができた．また，アジャイル開発であるスクラムを経験できたことも経験として大きい．
この 1 年間本当に様々な貴重な経験ができた．プロジェクト学習を通して気づいた発見や課題な
どは，今後の活動に役立てていきたい．
（※文責: 如澤駿介）

8.2

中野瑛斗

このプロジェクト学習を経験し，多くの学びを得た．大きく分けて三つある．
一つ目は，長期的なグループでの活動を経験したことでチーム開発の難しさを学んだことである．長期間のチーム開発は初めてということもあり，多くの困難があった．まず，何より難しかったこととしては，グループ内で共通認識を合わせることである．例えば，活動初期，開発する Web
アプリケーションである「はこレクト」のコンセプトをメンバの総意により決定した．このコンセ
プトが，活動中盤，終盤になってくるとぶれてくるメンバが現れる．このようなメンバの認識の齟
齬が発生するのを防ぐことがこのプロジェクト学習において一番難しいと感じた．私はこの共通認識のズレを防ぐために率先して議事録を記録する担当を申し込んだ．議事録ではその日に話し合ったことをただ書くのではなく，なぜその議論をするに至ったのかの理由まで書くことを意識して書いた．また，Google Jamborad という Google 社が提供するオンラインホワイトボードを使ってこれまでやってきたことを色付きの付箋でまとめたりもした．だが，これだけ議事録や Google

Jamborad のような視覚的ツールを利用しても共通認識のズレが発生してしまう．このズレを完全に無くしていくには，別のツールを有効活用したり，グループ内でコンセプト部分を確認しあう時
間を増やすなど，もっと工夫や努力が必要なのだと感じた．次に難しいと感じた事としてはタスク管理が挙げられる．理由としては，まずタスクを作成する際，どれくらいの粒度で作成すればいいかわからないからである．これはどういうことなのかというと，タスクは基本的に 1 日で終わるぐ
らいのものを作らなければならないのだが，私たちは開発経験がないので，どの程度のタスクが 1
日以内で終わるのかが分からなかった．これは，経験を重ねていかないと分からないものだと感じた．また，タスクの分担がうまくできなかったことも理由として挙げられる．特に，プログラミン
グのコードを書くタスクの分担は難しいと感じた．「はこレクト」を実装するフェーズに入ったときはコードを書くタスクが多く，私たちのグループはコードを書ける人と書くのに不安がある人で二極化していたため，特定のメンバに多くのタスクが割り当てられ，逆に何もタスクが割り当てらGroup Report of 2022 SISP

- 66 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
れない人が発生することが多々あった．このような事態を回避する為には個人レベルでのスキルアップやコードを書かない人のためのタスクを作成することなどがあると感じた．
二つ目は，チーム開発の楽しさを学んだことである．まず，こんなにも長くグループで活動するという経験は今まで体験したことがなかった．なので活動初期は本当にこのグループでやっていけるのかが不安であった．だが，プロジェクト学習が終わった今では本当にこのグループで良かったと思っている．特筆すべき点としては，メンバの仲がいいことである．これがチーム開発の楽しさを感じられた大きな要因と言ってもよい．仲がいい事によって，グループで何かを達成した時の喜びを共有できたり，なにかタスクをこなしたときにメンバにたくさん感謝されたり，困ったことがあったら，すぐに助けてもらったりすることができたのでグループ内の絆は何よりも大切だと感じた．
三つ目は，新しいことに挑戦したことで，様々な知識や技術を学んだことである．このプロジェ
クト学習の期間で様々な知識や技術を身につけた．まずはスクラムについての知識である．スクラ
ムマスターはメンバにスクラムを理解してもらうことに責任を持たなければならないため，なお
さらスクラムに関する知識を身につけなければならなかった．なので，伊藤教授から貸してもらった「SCRUM BOOT CAMP THE BOOK」というスクラムに関する本を読んだり，スクラムガイ
ドを読んだりした．そして，それらの情報を踏まえて，スクラムに関する説明スライドを作成し，そのスライドを使用してメンバに説明する機会を設けたりした (4.1 節参照)．次に，プログラミン
グ言語やその他の技術の知識である．「はこレクト」を実装する為に様々なプログラミング言語やツールを利用した (詳しくは 5.5 節参照)．この中で特にプログラミング言語の習得には力を入れた．夏休みの期間を使って，ほぼ毎日言語の学習をした．最初に HTML/CSS，次に JavaScript，
最後に Vue.js を夏休み中に学習した．学習する際は，オンラインプログラミング学習サービスである「Progate」を利用したり，参考書を自分で買い，それで学習した．さらに，学習した内容をGoogle Docs に書いて他のメンバのためになるようにした (8.1)．
このように，プロジェクト学習を経験したことで自分自身大きく成長したと感じた 1 年となった．今後は，この学んだ知識や経験を忘れることなく新たなことに挑戦する際に有効活用できたらと思う．
（※文責: 中野瑛斗）Group Report of 2022 SISP

- 67 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

図 8.1

8.3

学習したことを Google Docs で共有している様子

外崎健介

この 1 年に及ぶプロジェクト学習で得られた学びと体験は私自身にとって非常に大きな成長を与える機会となった．まず，グループで開発していく楽しさと難しさを学ぶことができた．私は，グループで活動する際にはそれぞれの考えや思い，どのような技術があって，何をしたいのかなど理解すべき点が多くあった．これらの土台をしっかり形成しないと開発を進めていくうえで少しず
つずれが生まれることがわかった．ゆえに，どれだけ頻繁に顔を合わせて活動を共にしていても，
ミーティングやアイスブレイクなどの機会を設け，話し合いを積極的に行うことが大事だということを学べた．また，プロジェクトを進めていくうえでそれぞれがやるべきタスクがあっても，問題が生じたり疑問に思ったことがあればメンバと共に解決するたびに，チームワークの素晴らしさを学ぶことができた．次に，スクラム開発を経験できたことが最も貴重な体験となった．私は，今回のプロジェクト学習で初めてスクラム開発を行い，そもそもスクラム開発がどんなものでどのように行っていく開発手法なのか知らなかった．ゆえに，伊藤教授からお借りしたスクラム開発に関する本を熟読し，開発の概念や手法，進行方法について学ぶことができた．それと共に，グループで各々がスクラム開発について調べ，学んできたことを共有しグループ全員の理解度を上げていった．開発をするうえで企画トイテレーション，リリースの全ての工程に積極的に参加することができ，それぞれの工程を行う上で注意すべき点や改善すべき点など，ただ進めるのではなく失敗した
らすぐ原因を分析し改善することもできた．最後に，全ての行動に目標と実行すべき理由を考えて活動していくことの大事さを学んだ．プロジェクトで行うタスクには負荷が高いものが多々あり，
なぜこんなことをする必要があるのかと考える場面が多々あった．しかし，スケジュールを立てながらタスクを作成する際に，それぞれの意義を決めてから実施していたためどれだけ困難なタスク

Group Report of 2022 SISP

- 68 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
でもやりぬくことができた．このように，やること全てに意味を持たせることが大事だということを学べた．今後はこれまで学んできたことを他の場面でも活かしていき，将来の自分に役立てるよ
うな経験にしたい．
（※文責: 外崎健介）

8.4

近藤篤

1 年間のプロジェクト学習を通して，多くの学びや経験を得ることができた．その中でも三つのことに関して記述する．一つ目は，スクラム開発を行ったことで得たチーム開発についての知識に関してである．私自身初めてのチーム開発であったため，開発で使用する単語や用語を理解したり覚えたりすることがまず大変であった．そのため，スクラムに関してわからないことがあったら

SCRUM BOOT CAMP を読み直したり，スクラムマスターである中野に積極的に質問したりすることでスクラムの理解度を深めることができた．また，チーム開発を行うにあたって情報や進捗の共有をすることの重要性を理解できた．情報や進捗を細かく行わないと，メンバ間ですぐに認識の違いがでてしまい，情報の共有をもう一度行わなければならなくなり，作業の進捗に大きな遅れをもたらしてしまうことがわかった．二つ目は，プログラミングに関することである．私たちが作った「はこレクト」ではフロントエンド言語として Vue.js，バックエンド言語として Python を使用した．Python に関しては大学の講義などで使用した経験があり使いやすかったが，Vue.js に関しては初めて使用するフレームワークであったため習得に多くの時間を要した．Vue.js で使用
する JavaScript についても初めて使用する言語であったため，夏休み期間中に Progate を使って学習した．また，開発をするうえで追加したい機能などがあった場合に，インターネット上で見つけたその機能のコードを私たちの開発する環境に合わせて書き直す方法も学んだ．これらの経験か
ら，プログラミングに関する知識を身に付けることができた．三つ目は，コミュニケーションに関してである．このグループが決まった際は，話したことがない人しかいない状態で不安だったが，メンバの外崎が率先して話しやすい雰囲気を作ってくれたおかげで，メンバ同士すぐに打ち解けることができた．このような，雰囲気づくりの方法を他の場所でも実践できるように頑張っていきたい．また，自分自身の意見や考えを伝える際に，ただ話すだけではなく，話すときの熱量，なぜその考えに至ったか，その際に参照した資料やサイトを提示するなどの工夫を行うことで聞き手の理解度が格段に上がることも実感できた．プロジェクト学習を通して学んだこれらのことを，今後の大学生活，これからの日々で活かしていきたい．
（※文責: 近藤篤）

8.5

鈴木瑞帆

1 年間のプロジェクト学習を経験し，様々な苦労があったが，その分多くのことを学ぶことができた．
何よりもまず，個人ではなくグループになって開発することが，難しくもあり，とても面白いものであるということを学ぶことができた．難しい点としては，やはり情報共有のコストや分業のやり方が挙げられる．メンバ全員が共通で把握していなければいけない部分が把握できていなかった
り，認識のズレによって制作しようとしているプロダクトのイメージが各自で違っていることがプGroup Report of 2022 SISP

- 69 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
ロジェクト中に実際にあった．その度に全員で内容の確認や見直しをおこなっていたため，定期的に共通認識について確認を取っておくことの大切さを学んだ．また分業に関しては，特に開発前半
はメンバ内で作業量の偏りがあったり，全員が同じ作業を行うことで作業があまり進まないことがあった．後半はなるべく分業することで作業効率は上がったが，特定の作業を行っているメンバの完了待ちという状態が発生してしまい，分業の重要さと，より良い作業の分け方などを学ぶことができた．次に面白い点としては，何よりも孤独な開発ではないため純粋に楽しいという点と，自分1 人では気が付かないミスの指摘や思い付かないアイデア等が次々に出てくるため，自分とは違う見方を学ぶことができた．またそれぞれに得意な分野と苦手な分野があるため，お互いがそれぞれの苦手な部分を補うことができるというのも，グループで活動することのメリットであることを理解した．
次に，引き継ぎではなく 1 から開発をすることの難しさを学ぶことができた．私は高校時代に，授業の関係で Android アプリの開発を行ったことがある．ただしその時は開発するプロダクトのテーマや内容は既に決まっていて，プロダクト自体も先輩方の開発していたものを引き継ぐ形だったため，ほぼ完成しているものを改良するだけであった．そのため何かアプリを 1 から開発するということは初めての経験であり，正直携わる前から不安だった．そしてプロジェクトが開始すると，開発に取りかかる前の段階，つまり企画段階が特に難しいことを理解した．ユーザの選定，そのユーザがどのようなものを今欲しているか，その二ーズに合ったプロダクトを作るにはどのような形で開発するか，他にも様々なものを定める必要があり，想像以上に前提の部分が大切であることを学んだ．また開発においても，自分がこういうものを作りたいと考えている機能ひとつひとつはインターネットや参考書等に書かれているが，それらを組み合わせたときに問題が発生するな
ど，前例があまり無いからこそ考えなければいけないことが多く，とても苦労した．この時メンバは勿論だが，TA や教授からもアドバイスを頂くことで解決したことが多くあったため，先ほども記述したが，自分とは違う視点をお借りすることの重要性を学ぶことができた．
今回長期間のグループでの開発経験で学んだことは，今後企業に就職した時にも間違いなく活かすことができるものだと思われる．そのため今回の学びを忘れることなく，これからの活動にも取り組んでいきたいと考える．
（※文責: 鈴木瑞帆）

Group Report of 2022 SISP

- 70 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

第 9 章 まとめ本グループは，函館近郊の情報発見を手軽にすることを目的とした Web アプリケーション「はこレクト」の開発に取り組んだ．グループを結成した当初は，大学生の娯楽を豊かにするグループとして活動を開始した．最初の活動として，函館近郊の娯楽についてブレインストーミングを行
い，メンバがそれぞれ意見を出していった．そこで，函館市出身と函館市外出身のメンバの間で知識の差が大きく表れた．また，函館市出身のメンバは，函館市の娯楽施設について熱意を持って他のメンバに説明しており，説明されたメンバはその施設に大きな興味を持った．本グループでは，
その函館市出身者と市外出身者の間にある知識の差と，市内出身者が熱く語っている姿に注目し，熱意を持って語っている内容を共有する場を作ることで，知識の差が埋まり，大学生のうちに函館近郊をより楽しめるようになるのではないかと考えた．自分の思いが多く集まってる場として

SNS などのソーシャルメディアに注目した．以上の過程を経て，本グループでは，ソーシャルメ
ディアから函館近郊に関する投稿のみを取得し，一つにまとめて表示する Web アプリケーション「はこレクト」を開発することに決めた．
「はこレクト」では，Twitter と Instagram にある函館近郊に関する投稿をリアルタイムで取得
し，施設の情報などのみを選別して一つの Web アプリケーションとして表示している．投稿の選別方法は，函館近郊の情報発信をしている SNS のアカウントや，グループ内で除くべきと判断したキーワードを含んだ投稿など様々である (詳細は 5.4 節に記載) ．
このプロダクトを作るにあたって，Code for Hakodate の中村拓也氏へのヒアリング，既存のソーシャルメディアの調査，開発予定のアプリケーションに類似したサービスが無いかの調査，

API を用いた投稿取得が可能かの技術検証，アンケートによるアイデア評価などの活動を行った(詳細は第 2 章に記載) ．プロダクトを決定した段階で，グループ名は「大学生×娯楽」だったが，表示する情報が娯楽に関する情報だけでないことや，作ろうとしているプロダクトのイメージが湧かないなどの理由により，「地域メディア」へグループ名を変更した．夏季休暇前最後の活動で，本プロジェクトでの開発手法であるスクラムに必要となるプロダクトオーナーとスラムマスターを決定した (スクラムの詳細は 4.2 節を参照) ．それぞれ投票と話し合いにより，如澤と中野が担当することとなった．
夏季休暇期間中は主に技術の習得を行った．プロジェクトの予算から伊藤教授にオンライン
プログラミング学習サービスである Progate を 2 ヶ月分を購入していただき，HTML や CSS，

JavaScript などの学習を中心に行った．また，メンバがそれぞれ，Vue.js の教本を購入するなどして学習を行った．夏季休暇期間中は，毎日 22 時から 15 分程度集まり，進捗の報告や情報交換などを行い，頻繁にコミュニケーションを取った．9 月 18 日には，enPiT の取り組みである UCD
ワークショップに参加した．夏季休暇の最終週には，後期の開発へ向けて，スクラムのスプリントを縮小して行い，開発にスムーズに取り組めるようにした．その他の活動として，ユーザーストー
リーマップの作成や，フレームワークの作成を行った．
後期は主にプロダクトの開発を行った．開発に入る前に，まだスクラムでわからないことが多いという意見が挙がったため，スクラム開発の理解を深めるために本グループのスクラムマスターである中野からメンバを対象に，スクラム説明会を開催した．その後，本格的な開発を 10 月 10 日から開始した．10 日からスプリント 1 として開発を進めたが，スプリント期間中に担当教員の伊藤Group Report of 2022 SISP

- 71 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022
教授，奥野教授，元木准教授に当時の現状や問題を説明したところ，グループとして先に進めるべき内容を誤っていたことに気づいたため，スプリントを中止しプロダクトのコンセプトを見直すことになった．その 10 月 17 日から新たにスプリント 1 として開発を開始し，成果発表会までに第4 スプリントまで回して開発に取り組んだ．スプリント期間中の開発の詳細は第 4 章に記載している．また後期には，プロジェクト学習成果発表会とは別に，11 月 10 日から 12 月 4 日の期間で開催された HAKODATE アカデミックリンク 2022 や 12 月 10 日に開催された enPiT BizSysD 北
海道・東北合同発表会に参加して発表を行った (詳細は 4.10 節，4.11 節，4.12 節) ．これらの発表会では，質疑応答で得られた意見をメモにまとめ，その後の活動に役立てられるようにした．
本グループには，開発経験のあるメンバがほとんどいなかったが，それぞれのメンバが自発的に活動して，皆よりよいプロダクトにしたいという意識を持って活動していたため，成果発表会までに形のあるものを作り上げることができた．グループでの開発を進めるうえで，認識を合わせることや進捗の共有などがあまりできていなかったが，メンバ全員が初めての経験が多く，とても学びのあるプロジェクトであった．
（※文責: 如澤駿介）

Group Report of 2022 SISP

- 72 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

第 10 章
10.1

今後の予定

課外発表

今後の活動として，2023 年 2 月 14 日に秋葉原で開催される課外成果発表会への参加を予定している．本プロジェクトからはプロジェクトリーダの児玉と副プロジェクトリーダの如澤が参加予定である．今回は 3 年ぶりの現地開催の予定である．
また本グループでは，秋葉原での発表以外に，2 月に盛岡市で開催されるワークショップと 3 月に開催される Agile PBL 祭への参加を検討している．
（※文責: 如澤駿介）

10.2「はこレクト」の今後

今後は，プロダクト評価のアンケートで得た意見や発表会で得た意見をもとに，「はこレクト」の改善を行い，今後の発表会でよりよい「はこレクト」を紹介したい．現在は，それぞれの機能に改善点がいくつか見られる．また，グループ内で決めたルールに基づいて投稿の選別を行っており，
投稿の内容が重複していることや，函館近郊の情報とは関係ない投稿が表示されるなどの問題が見られるため，それらを修正してプロダクトの完成度を上げていく．また，アンケートで得たユーザからの意見を合わせることで表示する投稿の精度を上げていきたい．
（※文責: 如澤駿介）

Group Report of 2022 SISP

- 73 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

付録 A

制作物：作成したペルソナ

Group Report of 2022 SISP

- 74 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

付録 B

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

Group Report of 2022 SISP

- 75 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

付録 C

成果発表会で使用したスライド

Group Report of 2022 SISP

- 76 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

Group Report of 2022 SISP

- 77 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

Group Report of 2022 SISP

- 78 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

Group Report of 2022 SISP

- 79 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

Group Report of 2022 SISP

- 80 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

Group Report of 2022 SISP

- 81 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

付録 D番

制作物：リスク分析

リスク

被害

号

1

発生確

影響

率

度

0.3

メンバーが

失踪したメン(3

失踪する（メバーのタスク班)0.2

ンバーが欠けが完了しない脅威対策

具体的な対策0.06

回避

ストレスフリーな環
境？、メンタルサポー
ト、常にコミュニケー

る)

ションをとるよう心が
ける

(2

0.8

0.16

軽減

班)0.2

(1

どうにかして失踪した
メンバーを見つける？

?

0.8

転嫁

班)?
受容

失踪したメンバーのタ
スクを他のメンバーが請け負う

2

メンバーが出休んだメン(3

席できなくな

バーのタスク

班)0.8

0.1

0.08

回避

活動の時間に予定を被せないように心がけるる（体調不良） が 進 ま な い 、
情報にズレが
生じる

(2

0.3

0.15

軽減

班)0.5

(1

睡眠をしっかりとる、感染対策をしっかりする

?

0.05

転嫁

班）?
受容

他のメンバーに急ぎのタスク・役割を任せる、議事録を残して休んだ
メンバーはそれを確認する

Group Report of 2022 SISP

- 82 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

3

メンバーのパ

できないタス(3 班 ） 0.3

ソコンが使えク が 生 じ る 、 0.5

ルにデータバックアッ

なくな る (壊重要データのプ、PC の自己管理を徹れる、盗まれ

紛失

底する

0.15

回避

大切に扱う、共有ファイ

る、破損する）(2 班 ） 0.8

0.4

軽減

バックアップをこまめにとる (共有ファイルな

0.5

どに)、代わりの PC？を
使う

(1

?

0.16

転嫁

班)?
受容

PC なしでできることをする

4

コロナウイル

コミュニケー

スの流行によションの質のり対面での活低下、作業の動が難しくな

遅延

0.5

0.3

0.15

回避

る
軽減

重要な活動のみ少人数
で対面

転嫁
受容

オンラインでも活動できるような事前準備

5

データがなく

作業に遅延

なる

(3

0.3

0.24

回避

できるだけ共有する

0.8

0.4

軽減

バックアップから復元

班)0.8

(2
班)0.5

する、スクショする、外付け HDD などにバッ
クアップデータを取っておく
転嫁

git に保存、外付け HDDなどにバックアップ
データを取っておく

受容可能な限り、自分の記憶で復元するGroup Report of 2022 SISP

- 83 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 20226

要求技術が難機能ができな

しくて実装で

い

0.8

0.8

0.64

回避

実現可能な機能を考え
る

きない
軽減

勉強する

転嫁
受容

代わりとなる実現可能な機能を考える

7

ある技術に関機能ができな

して知見のあ

い

0.8

0.8

0.64

回避

事前に勉強する軽減

勉強するるメンバーがいない

転嫁
受容

TA さん、先生に聞いて
みる

8

使っていた

作 業 に 遅 延 、 0.2

ツールが使えデータが消え

なくなる

る？

0.8

0.16

回避

不具合報告が多いツー
ルは避ける

軽減

代替できるツールを探
す

転嫁

9

時間が足りな

成果物ができ(3い（期日に間

ない

班)0.8

0.8

0.64

受容

復旧するまで待つ

回避

前倒しで作業？時間外労働？ スケジュール管に合わない）

理
依頼者に迷惑

(2をかけてしま

班)0.5

0.8

0.4

軽減

計画をたて効率よく作業する。、こまめに進捗うを確認し合う

(1

?

0.4

転嫁

班)?
受容

その段階で最低限必要
なもの以外は諦める

Group Report of 2022 SISP

- 84 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 202210

メンバー間の見当違いなこ認識の差異がとをやってし生じる、コミ

まう？

0.8

0.1

0.08

回避

重要事項については確認する・記録をとるュニケーショ
ントラブル
軽減

不安があることに関しては質問する

転嫁
受容

修正可能なものに関してはやり直す11

導入予定のソ

予算オーバー

フトウェアや

(3

0.1

0.02

回避

班)0.2

予算内に収まるように購入計画を立てる、しっ

機器管理費のかりと計画を立てて費費用爆増（費用を使う、大切に保管、用不足）

予算を常に把握できる
ようにする
必要なサービ(2

スやツールを

班)0.2

0.8

0.16

軽減

?

0.15

転嫁

予算の増加を申請

使えない

(1
班)?

受容

自費、しっかりと計画を立てて費用を使う

12要求の実装難開発が完了し易度が高く開

ない

0.5

0.8

0.4

回避

発が完了しない軽減
転嫁
受容

難易度に合わせたスケ
ジュールに調整して、準備を整える

Group Report of 2022 SISP

- 85 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

13

災害が起こっ

プロジェクトてプロジェクが中止になる

0.2

0.8

0.16

回避

トが中止になる
軽減
転嫁

教員に今後の予定を聞く受容

再開可能になるまで待つ？

14github を 使

成果物の品質いこなせない

が低下する

0.2

0.3

0.06

回避

実践的な勉強会？

軽減

TA さんに聞く(勉強会後)
転嫁
受容

その後個人で github を習得するスケジュール
を立てる。

15

フィールド調成果物の品質査での調査不

が低下する

0.5

0.8

0.4

回避

足
軽減 （軽減）事前に調査する
内容を確認しておく。
転嫁

16

受容

再調査？

回避

事前に複数の運行状況

フィールド調フィールド調査中での利用

査内での予定や他の路線などを調べ、予定の交通機の遅延・延期利用する候補をいくつ

0.5

0.3

0.15

関の遅延またか定めておく。

は逃し
軽減

運行状況や他の路線などをその場で調べ、少しでも早くその後の予定が出来るようにする。

転嫁
受容Group Report of 2022 SISP

- 86 -

状況を受け入れ徒歩…

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

17

新型コロナな

メンバー間の(3

どによる対面

コミュニケー班)0.5

授業不 可 (コ

ション不足

ロナの再拡

化、作業の遅

大）

延

0.3

0.15

回避

オンラインでの作業を日常的に行う対面活動不軽減

オンラインと対面の両可、現場に行方を行う、オンラインでくことができの活動、オンラインで拝

ない

聴

(1

?

0.15

転嫁

班)?
受容

18

キ ャ パ オ ー （メンバーが
バー

0.2

0.3

0.06

回避

疲弊する？）
軽減

各々自分の限界を自覚する/仕事の押し付けを
しない

転嫁
受容

19

本来してほし （ 進 捗 が 遅 れいことと違う

0.2

0.8

0.16

回避

る？）

確認しあう（コミュニケーション円滑にする）

ことをしてしまう
軽減

過程途中で確認

転嫁
受容20

今 ま で 使 っ （戸惑ってしたことのない

0.5

0.8

0.4

回避

使わない

軽減

メンバー同士で教えあまう？）

ツールを使うう 教員・TA 方に教えて
もらう
転嫁
受容

Group Report of 2022 SISP

- 87 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

21

コードが書け （ 進 捗 が 止 ま
ない

0.8

0.3

0.24

回避

る？）
軽減

あらかじめ使う言語の
学習をする

転嫁
受容

22

バグ発生

（実行できな

0.8

0.3

0.24

回避

くなる？）
軽減

エラー文を読み、調べて
改善

転嫁
受容

23

データ入り

重要データのファイルの紛

紛失

?

?

0.24

回避

共有ファイルにデータのバックアップ

失、破損軽減

共有ファイルにデータのバックアップ

転嫁
受容24

コミュニケー

メンバのタスションツール

ク進捗がわかのエラー

らない、重要

?

?

0.5

回避

他ツールを使う（LINEなど)な連絡が伝わらない、焦る
軽減
転嫁
受容

25

作業担当の人

グループ全体と連絡とれなの進捗がとまかの人にメンションついる、ほかの人

けて質問する、相談できが作業できな

る体制をつくる

?

?

0.1

回避

よびかける、問題点をほ

い
軽減
転嫁
受容

Group Report of 2022 SISP

- 88 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

26

リリース前に制作物がない

?

?

0.64

回避

解決できない
問題発生
軽減バージョンを残す、動くバージョンは保存？し
ておく

転嫁
受容

バージョンを残す、動くバージョンは保存？しておく

27

インターネッ

Zoom 会議なト不調どに参加でき

?

?

0.64

回避

ない
軽減
転嫁
受容

問題が起きたことを連絡する、報告する

28

喧嘩

スムーズに意

?

?

0.4

回避

見交換ができ一緒に遊ぶ、コミュニ
ケーション

ない
軽減
転嫁
受容

29

スキル不足

よい制作物が(勉 強 で ど う

できない

?

?

0.64

回避

個人でもグループでも積極的に勉強こうなるか不明)
軽減

個人でもグループでも積極的に勉強転嫁
受容Group Report of 2022 SISP

- 89 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 202230

目標が定まらモチベション

ない

が続かない

?

?

0.16

回避

全体で目標を共有でき
る時間

軽減
転嫁
受容

31

グループ変更

急にやるこ

?

?

0.05

回避

とが変わるため、進捗状況
がわからなかったりして、
スケジュールがわからなく
なる。
軽減
転嫁
受容

グループが変わったら、その後グループのやることを整理して対応する

32

メンバーが進作業がかみ合捗状況を把握

わない

?

?

0.4

回避

日々の報告を怠らない

していない
軽減
転嫁
受容

Group Report of 2022 SISP

- 90 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

付録 E

活用した講義本グループがプロジェクト学習の活動を行っていく上で，活用した講義は以下である．
ソフトウェア設計論 I
ソフトウェア設計論 I ではリスク分析やリスク対策の種類などについて学んでいたため，この講義で使用されていた資料を再確認するなどして活用した．
ヒューマンインタフェース
ヒューマンインタフェースの講義でアンケートの作成方法について紹介されていたため，この講義をもとに，アンケートを作成した．
科学技術リテラシ
中間報告書を書く際，参考文献の書き方を学んだ．

Group Report of 2022 SISP

- 91 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022

参考文献
[1] 西村 直人， 永瀬 美穂， 吉羽 龍太郎. “SCRUM BOOT CAMP THE BOOK スクラムチー
ムではじめるアジャイル開発”. 株式会社 翔泳社. 2020.

[2] 武 信 雄 平 ， 財 部 圭 太 ， 板 谷 愛 美 ， 岡 田 将 太 朗 ， 高 橋 莉 奈 ， 沼 田 夏 竜. “公 立は こ だ て 未 来 大 学 2018 年 度 シ ス テ ム 情 報 科 学 実 習 グ ル ー プ 報 告 書”．2018．

https://drive.google.com/drive/u/0/folders/1bDQn34hbNuOJODBEmBByxal98jRGsbKg(7 月 14 日 アクセス)[3] kanko-ch.com. “日 本 最 古 の 観 覧 車 は 函 館 で 稼 働 し て い た ！ [北 海 道 観 光 ス ポ ッ ト]”．
2021/05/28．https://www.kanko-ch.com/(7 月 14 日 アクセス)[4] 函館市公式観光情報 “観光情報サイトはこぶら”．2022．https://www.hakobura.jp/ (7 月
14 日 アクセス)[5] 株 式 会 社 ア イ レ ッ プ ．“PWA と は — 用 語 —株 式 会 社 ア イ レ ッ プ”．

—https://www.irep.co.jp/knowledge/glossary/detail/id=10227/ (7 月 14 日 アクセス)[6] teitpane．“TwitPane について”．https://twitpane.com/ (7 月 14 日 アクセス)[7] ツイータン．“tweetan トレンドワード分析サイト”．https://tweetan.dtn.jp/ (7 月 14 日 ア
クセス)[8] Tag Live．“タグライブ”．https://taglive.jp/pr/ (7 月 14 日 アクセス)[9] オ ヤ ジ ．“函 館 の 飲 み 食 い 日 記

Poweredby

ラ イ ブ ド ア ブ ロ グ”．

https://hakodatedayo.blog.jp/ (7 月 14 日 アクセス)[10] forret．“今さら聞けない「ペルソナ」とは．意味やマーケティングでの活用方法，作り方も解説！”．2020．

https://ferret-plus.com/8116 (7 月 14 日 アクセス)[11] カオナビ人事用語集．“エレベーターピッチとは？【作り方・まとめ方 5 ステップ】 - カオナ
ビ人事用語集”． https://www.kaonavi.jp/dictionary/elevator-pitch (1 月 9 日 アクセス)[12] Ken

Schwaber,

Jeﬀ

Sutherland.

“ス

ク

ラ

ム

ガ

イ

ド

”.

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf(1 月 9 日 アクセス)[13] NIJIBOX BLOG．“【 基 本 編 】MVP（Minimum Viable Product）と は ？ 開 発 手 法
や プ ロ ト タ イ プ の 種 類 を 、事 例 を 交 え て 解 説 — 株 式 会 社 ニ ジ ボ ッ ク ス”．

https://blog.nijibox.jp/article/mvp-basic/ (1 月 16 日 アクセス)[14] Figma．“コ ラ ボ レ ー シ ョ ン イ ン タ ー フ ェ イ ス デ ザ イ ン ツ ー ル 。 - Figma”．
https://www.ﬁgma.com/ (7 月 15 日 アクセス)[15] progate．“Progate — プログラミングの入門なら基礎から学べる Progate[プロゲート]”．
https://prog-8.com/ (1 月 9 日 アクセス)[16] enPiT．“enPiT2

成 長 分 野 を 支 え る 情 報 技 術 人 材 の 育 成 拠 点 の 形 成”．

https://www.enpit.jp/index.html (1 月 16 日 アクセス)[17] Google. “Save Tweets in Google Sheets” https://digitalinspiration.com/product/twitterarchiver (1 月 9 日 アクセス)[18] enPiT．“enPiT e-Learning 学習用 Web サイト - 成長分野を支える情報技術人材の育成拠点
Group Report of 2022 SISP

- 92 -

Group Number 1-C

Field Oriented System Design Learning by Users’ Feedback 2022の形成”．https://enpit2.widebook.net/ (7 月 17 日 アクセス)[19] 南 部 美 砂 子 ．“フ ィ ー ル ド ワ ー ク 入 門 講 座

forPBL2022

年 度 版”．

https://drive.google.com/ﬁle/d/1H6-Iepfufk80NmRY0DlYInMgRa-5zOrA/view(7

月 17 日 アクセス)[20] enPiT，株式会社アトラクタ．“スクラムワークショップ 2022”．(7 月 19 日 アクセス)[21] Discord．“Discord”． https://discord.com/ (7 月 15 日 アクセス)[22] Slack．“Slack”． https://slack.com/intl/ja-jp/ (7 月 15 日 アクセス)[23] Miro．“Miro”． https://miro.com/ja/ (7 月 15 日 アクセス)

Group Report of 2022 SISP

- 93 -

Group Number 1-C