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

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

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

グループ名
グループ A (交通支援)

Group NameGroupA (Traﬃc support)
プロジェクト番号/Project No.

1-A

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

Takumi Kodama

グループリーダ/Group Leader
高野希澄

Manato Takano

グループメンバ/Group Member涌井春那

Haruna Wakui

高野希澄

Manato Takano

池端麦

Mugi Ikebata

似鳥亜美

Ami Nitadori

児玉拓海

Takumi Kodama

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

奥野拓

元木環

AdvisorKei Itou Taku Okuno Misako Nambu Tamaki Motoki

提出日
2023 年 1 月 20 日

Date of Submission
January 20, 2023

概要
本プロジェクトは，フィールド調査をもとに問題を発見し，IT を用いて解決する．それによりユーザの仕事や生活をデザインし，地域や社会に貢献することを目的に活動している．また，本プロジェクトは，アジャイル開発手法を用いる．それにより，迅速で柔軟な開発を行い，短期間の開発でより効率的に成果を出すことを目標にしている．今年度は，プロジェクト内を交通支援グループ，観光グループ，地域メディアグループの 3 グループに分け，各チームがそれぞれのフィールドで活動している．本報告では交通支援グループについての報告を行う．
本チームでは，ブレインストーミングやフィールドワークを行った中で気が付いた函館地域のバスの使いにくさを解消することを目的として活動した．私たちは，この目的を達成する手段として，既存のバスアプリの情報表示・表現の分かりにくさに焦点を当てたアプリの開発を行うこととした．これまで，フィールドワークの実施やユーザモデリングの作成を通して，函館地域のバスの使いにくさの原因の議論や機能の考案を行い，バス検索アプリ「ばすうぃふと」を開発した．
キーワード

フィールド調査，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 development groups: atransportation support group, a local media group, and a local media group, with eachgroup working in its own ﬁeld. In this report, we report on the traﬃc support group.
In this team, we worked to solve the diﬃculty of using the bus in the Hakodate area,
which we noticed while doing brainstorming and ﬁeldwork. As a means to achieve
this purpose, we decided to develop an application that focuses on the diﬃculty ofunderstanding the information display and expression of existing bus applications. So
far, through ﬁeldwork and user modeling, we have discussed the causes of the diﬃcultyof using buses in the Hakodate area and devised functions, and developed a bus search
application “Buswift”.
KeywordExpression

Field Survey, IT, Scrum, Bus, Incomprehensible Information Display and（※文責: 高野希澄）- ii -

目次
第1章

背景と目的

1

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

1

1.1.1

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

1

1.1.2

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

1

1.1.3

グループの背景. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

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

2

中間発表までの主な活動

3

2.1

グループ分け . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

ブレインストーミング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.3

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

4

2.3.1

調査方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3.2

結果

4

1.1

1.2
第2章

2.4

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

タイムライン作成. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.4.1

タイムラインの説明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.4.2

タイムライン作成より得た結果 . . . . . . . . . . . . . . . . . . . . . . .

6

ユーザモデリング作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.5.1

ユーザモデリングの説明 . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.5.2

ユーザモデリング作成より得た結果 . . . . . . . . . . . . . . . . . . . . .

8

2.6

テーマの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.7

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

8

2.7.1

中間発表資料作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.7.2

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

8

2.7.3

フィードバック. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

知識・技術習得 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.8.1

enPiT e-learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.8.2

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

10

2.8.3

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

11

2.8.4

中村拓也氏のレクチャー . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.8.5

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

12

2.8.6

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

13

2.5

2.8

第3章

夏季休暇中の活動

14

3.1

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

14

3.2

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

14

3.2.1

類似アプリの調査 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.2.2

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

14

3.2.3

機能仕様書 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15- iii -

3.2.43.3

3.4

函館バス訪問準備

16

3.3.1

訪問する経緯 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.3.2

資料作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

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

17

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

17

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

18

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

18

3.5.1
第4章

4.1

4.2

4.3

4.4

16

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

3.4.1
3.5

プラットフォーム決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

後期活動内容19

函館バス訪問 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

4.1.1

結果

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

19

4.1.2

機能の見直し . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

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

19

4.2.1

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

20

4.2.2

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

21

4.2.3

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

21

4.2.4

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

22

4.2.5

リファインメント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

各スクラムでの活動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.3.1

スプリント 0(10 月 7 日〜10 月 12 日). . . . . . . . . . . . . . . . . . .

23

4.3.2

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

24

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

31

4.4.1

概要

4.4.2

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

31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

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

32

4.5.1

成果発表資料作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

4.5.2

概要

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

32

4.5.3

フィードバックと改善 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

4.6

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

33

4.7

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

34

4.8

ユーザレビュー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

いただいたフィードバック . . . . . . . . . . . . . . . . . . . . . . . . . .

34

4.5

4.8.1
第5章

プロダクト

35

5.1

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

35

5.2

コンセプト決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

5.2.1

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

35

5.2.2

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

36

5.2.3

ターゲットユーザの決定 . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

5.2.4

バリュープロポジションキャンバスの作成 . . . . . . . . . . . . . . . . .

36

機能決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

バス時刻一覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.3

5.3.1

- iv -

5.3.2地図. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.3.3

リアルタイムバス位置 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.3.4

お気に入り・履歴バス停 . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

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

38

Figma でプロトタイプの作成 . . . . . . . . . . . . . . . . . . . . . . . .

38

5.5

アプリの流れや使い方について . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.6

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

43

5.6.1

ホーム画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.6.2

入力画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

5.6.3

地図画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

5.6.4

一覧画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.6.5

詳細画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

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

49

5.7.1

Swift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

5.7.2

Firebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

5.7.3

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

50

使用したデータ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

5.8.1

GTFS-JP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

5.8.2

GTFS-RT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

使用したツール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.9.1

Xcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.9.2

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

51

5.9.3

ZenHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

5.9.4

Figma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

5.9.5

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

52

5.9.6

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

52

5.9.7

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

53

5.9.8

Google Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

5.4

5.4.1

5.7

5.8

5.9

第6章

今後の展望

54

6.1

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

54

6.2

フィードバックを基に改善しようとしていること . . . . . . . . . . . . . . . . . .

54

6.3

函館バスでいただいたフィードバックを基に改善しようとしていること . . . . . .

54

学び

55

7.1

高野希澄 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

7.2

涌井春那 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

7.3

池端麦 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

7.4

似鳥亜美 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

7.5

児玉拓海 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

まとめ

59

第7章

第8章

-v-

第9章

9.1

今後の予定

60

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

60

9.1.1

秋葉原成果発表会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

9.1.2

enPiT BizSysD 分野ワークショップ . . . . . . . . . . . . . . . . . . . .

60

9.1.3

Agile PBL 祭り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

付録 A

アカデミックリンクスライド

61

付録 B

グループポスター

64

参考文献

66

- vi -

Field Oriented System Design Learning by Users’ Feedback 2022

第 1 章 背景と目的
1.1

背景

1.1.1

プロジェクトの立ち上げ

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

1.1.2

プロジェクトの方針

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

1.1.3

グループの背景

交通支援グループは，IT を利活用することで函館地域のバスの使いにくさを解消することを目指す．2022 年 4 月に函館に導入されたゾーンバスシステム [2] や赤字運営による減便によって，函館地域のバスが使いにくくなったという声を学内でも聞くようになった．また，私たちは，グループ活動が始まった際に，函館地域の交通についての議論を行い，そのなかで函館地域のバスが使いにくいのではないかという考えに至った．そして，実際に既存のバスアプリやマップアプリを使って行ったフィールドワークで，既存のアプリの使いにくさや函館地域のバスの使いにくさを実感することができた．これらの使いにくさの原因を取り除くことで，函館地域の生活をより良いものにすることができると私たちは確信した．
（※文責: 高野希澄）

Group Report of 2022 SISP

-1-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

1.2

目的

議論やフィールドワークを経て，バスの使いにくさの原因を考えた結果，既存のバスアプリや
マップアプリは情報の表示や表現に問題があるという結論に至った．そこで私たちは，既存のバス
アプリの情報表示・表現のわかりにくさに焦点を当て，函館地域のバスを使いやすくするためのアプリ開発を行うことにした．
（※文責: 高野希澄）

Group Report of 2022 SISP

-2-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

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

グループ分け「交通支援」，「観光」，「地域メディア」の 3 つの観点から，プロジェクトメンバーそれぞれが興味のあるグループに分かれた．私たちは「交通支援」グループとして活動することになった．
（※文責: 似鳥亜美）

2.2

ブレインストーミング

最初に，ブレインストーミングを行い，函館市に来て約 2 年ほどになるメンバーそれぞれが思う
函館市の交通の問題を挙げていった．挙がった問題の例は以下である．

• バスの系統が分からない• バスの待ち時間が長い• バスが遅れているか分からない• 電車と比べてバスの分かりにくさを感じる• 亀田支所のバス乗り場が多くて分からない• バスに学生がいっぱい乗っている時の他の市民の乗降車が大変そう
この際，パソコンで利用できるオンラインホワイトボードツール Miro*1 を用いた．その様子が図2.1 である．挙がった問題を付箋に記入し，バスについての問題を橙色の付箋，それ以外の交通問
題を青色の付箋とした．結果，ブレインストーミングで多く挙がったのが，函館地域のバスの使いにくさに関する問題であった．

図 2.1 Miro によるブレインストーミングの様子*1 https://miro.com/

Group Report of 2022 SISP

-3-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022（※文責: 似鳥亜美）

2.3

フィールドワーク

ブレインストーミングで挙がった函館地域のバスの問題を確かめるため，6 月 8 日金曜日に授業時間を使ってフィールドワークに行くことにした．詳細は以下で述べる．
（※文責: 似鳥亜美）

2.3.1

調査方法

はこだて未来大学前を出発地，函館駅前を目的地とし，バスのみを使って乗り換えを行う A チー
ムと，バスと市電を使って乗り換えを行う B チーム，計 2 チームに分かれた．それぞれの函館駅までの経路を図 2.2 に示す。具体的に，A チームは，はこだて未来大学前を出発する 55 系統に乗り，亀田支所 2 番乗り場で降りた．そのあと亀田支所 7 番乗り場で乗り換え，67A 系統に乗って函館駅前で降りた．帰りは，函館駅前 5 番乗り場から 61 系統に乗り，五稜郭シダックス前で降りた．
そのあと五稜郭シダックス前から 55F 系統に乗り，はこだて未来大学前で降りた．B チームは，Aチームと同じくはこだてみらい大学前を出発する 55 系統に乗ったが，亀田支所で降りることなく，五稜郭大村美容形成クリニック前で降りた．その後，五稜郭公園前で市電に乗り換え，谷地頭行きの 2 系統に乗り，函館駅で降りた．帰りは、函館駅 2 番乗り場から 33 系統に乗り，亀田支所で降りた．バスが予定よりも遅れてしまったため，はこだて未来大学前まで行くバスに乗ることができず，亀田支所の 1 番乗り場から 66 系統に乗り，赤川中学校前で降りた．そこからは，歩いてはこだて未来大学前を目指した．フィールドワーク中は，コミュニケーションツール「Slack*2 」を用いて，各自気付いたことを投稿し，違うチームの気付きもリアルタイムで共有した．

図 2.2

フィールドワークの経路（※文責: 似鳥亜美）

2.3.2

結果

フィールドワーク中は，ブレインストーミングで挙げられた問題を確認できたことに加え，「路線図が見にくい」や「同じ名前のバス停が複数あって分かりにくい」(図 2.3) など新たな問題にも*2 https://slack.com/

Group Report of 2022 SISP

-4-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
気付いた．また，バスと市電を使って乗り換えを行った B チームでは，市電の時刻表が見やすいのに対し，バスの時刻表は見にくいなど，より函館地域のバスの使いにくさを感じることができた．
さらに B チームでは，帰りのバスの大幅な遅れにより，バスの乗り換えに失敗し，学校まで約30 分歩くことになるなど，フィールドワークでは，函館地域のバスの使いにくさ，不便さを実際に体感することとなった．

図 2.3

複数ある同じ名前のバス停（※文責: 似鳥亜美）

2.4

タイムライン作成

フィールドワーク後は，フィールドワークで発見した問題をただ列挙していったが，先生方から問題が起こった状況を分かるようにしたほうがよいというアドバイスをいただいたため，タイムラ
インを作成することで，フィールドワークで発見した問題の状況を分析した．
（※文責: 似鳥亜美）

2.4.1

タイムラインの説明

タイムラインでは，バスを乗る前の調べる段階から降りる段階までの時間軸を直線で表した．発見した問題を付箋に書き，その問題がどの段階で起きているか模造紙に貼って問題が起きた状況を整理して一目で見えるようにした．そのタイムラインが図 2.4 である．
このタイムラインでは，ピンクの付箋には「バスを待つ」や「バスに乗る」といった，バスを利用する際の段階を書いた．一方で，青い付箋には「時刻表が見にくい」や「料金が分かりにくい」などの具体的な問題を書いて貼り付けた．

Group Report of 2022 SISP

-5-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 2.4

タイムライン（※文責: 似鳥亜美）

2.4.2

タイムライン作成より得た結果

図 2.4 のタイムラインより，左の「バスを調べる」というバスを利用する際の段階を表すピンクの付箋に，問題を表す青い付箋がたくさん貼られていることが分かった．その結果から，バスの時
刻や路線などを「調べる」段階に問題が多いと気付いた．
（※文責: 似鳥亜美）

2.5

ユーザモデリング作成

タイムラインで得た「調べる」段階で問題が多いことをさらに具体化するため，ユーザモデリン
グを作成した．
（※文責: 似鳥亜美）

2.5.1

ユーザモデリングの説明「調べる」段階下に絞り，ユーザモデリングの項目を「いつ、誰が、どういう状況で困っているか，その理想の状況，理想の状況にするための機能」の 5 点とし，計 11 個作成した．表 2.1，表

2.2，表 2.3 は実際に作成したユーザモデリングの例である．表 2.1 はユーザをショッピングに行く
学生，表 2.2 はホテル宿泊者，表 2.3 はバスの利用頻度が少ない函館市民に設定している．
（※文責: 似鳥亜美）

Group Report of 2022 SISP

-6-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

表 2.1

ユーザモデリングの例 1

表 2.2

表 2.3

ユーザモデリングの例 2

ユーザモデリングの例 3Group Report of 2022 SISP

ショッピングに行く学生

ホテル宿泊者

バス利用頻度の少ない函館市民-7-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

ユーザモデリング作成より得た結果

2.5.2

ユーザモデリング作成より，調べる段階において困っている人，その状況を想像した．そこで予測したのが，ユーザモデリングの「状況」時に，アプリの画面の中に情報量が多いため欲しい情報が探せない，複数のバス検索に関するアプリを使用しないと欲しい情報を得ることができないユー
ザの状況であった．その結果，当初は調べる段階の問題だと考えていたことを，ユーザモデリング
によって，情報の表示・表現・選択の問題としてとらえ直すことができた．
（※文責: 似鳥亜美）

2.6

テーマの設定2.2〜2.5 の過程から「交通支援」グループでは，「函館地域のバスを利用しやすくすることを目的とし，バスを利用する際の負荷を軽減させるアプリを開発する」ことをテーマに設定することになった．
（※文責: 似鳥亜美）

2.7

中間発表

2.7.1

中間発表資料作成

中間発表に向けて，メインポスター，スライド，発表原稿を作成した．ポスターやスライドは，
先生方や TA である先輩方に何度も繰り返しレビューをもらい，何度も内容を改訂した．また，スライドに関しては，授業時間外を多く使い，発表会が始まる直前まで何度も改訂し，非常に多くの労力を要した．図 2.5 は最終的に決まったメインポスターの，交通支援グループの部分である．
（※文責: 似鳥亜美）

2.7.2

中間発表会

中間発表会は 7 月 8 日金曜日に対面で行われ，15 分間の発表を計 6 回行った．図 2.6 のようなスライドを使いながら，本グループが取り組むテーマ，テーマ決定までの経緯，アプリの機能案の紹介を発表し，いくつか質問をもらった．「考えている機能が，今世間にありそうな機能だが，このグループの独自性とは？」という独自性が分からないという質問が最も多く，他には「調べるのに問題があるから情報の表現に問題があるに代わっていたが、その経緯を具体的に教えてほしい」
といった内容の説明に関する質問をもらった．
（※文責: 似鳥亜美）

Group Report of 2022 SISP

-8-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 2.5Group Report of 2022 SISP

メインポスター交通支援グループの部分-9-Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 2.6

2.7.3

発表で実際に使用したスライドの一部抜粋

フィードバック

発表を聞いていただいた先生方や学生から，主にアプリの機能案についてのフィードバックを得た．発表会での質問と同様に，「既存のアプリとの違いが分からない」という指摘を多くいただいた．フィードバックを参考にし，アプリの要件定義に活かしていきたい．
（※文責: 似鳥亜美）

2.8

知識・技術習得

2.8.1

enPiT e-learning

プロジェクトが始まってすぐに，各自，enPiT e-learning[3] の「プロジェクト学習のためのプロ
ジェクトマネジメントの基礎」を視聴し，プロジェクト学習を行う上でのプロジェクトマネジメン
トなどの学習をした．プロジェクトの立ち上げから，計画，実行，監視，終了までについて学んだ．
その中で, プロジェクトにおける，重要な役割を果たす，リスク分析や，その管理，タスクの管理なども学んだ．
（※文責: 池端麦）

2.8.2

リスク分析

プロジェクトを行ううえで，リスクは常に存在する．そのリスクが発生する前に，対策することを目的に，リスク分析を行った (図 4.11)．リスクと、それによる被害，またその発生確率を，次で説明しているように各班ごとに求めた．リスクの大きさの定義は，「事態の発生確率とその結果の組合せ」であり，その各種リスクを，「影響の大きさ」と「発生確率」の両面から分析・算定した[4]．このリスク分析で，重要なことは，具体的な決め事が必要で，誰がやっても同じようになるよ
うな手順で記述することである．また，プロジェクトを進めていく中で，このリスク分析を見返して，更新していく必要がある．

Group Report of 2022 SISP

- 10 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 2.7

リスク分析（一部抜粋）（※文責: 池端麦）

2.8.3

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

南部美砂子准教授に，「函館補完計画：序 〜 AR 技術でリアルなまちをハックする」プロジェクトと一緒に「フィールドワーク入門講座 for PBL」の講義を行っていただいた．そこで，フィール
ドワークについて，ご教授いただいた．ここでは，フィールドワークで，どのような視点を持って行うか，また，その中に，行うべきではないこと，注意すべきことなどを学んだ．現場では，適切に見て，発見し，それを記録することを心がける．さらに，上から目線の態度を取らないようにする．このように学んだことをいかして，フィールドワークを行った．

図 2.8

Group Report of 2022 SISP

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

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022（※文責: 池端麦）2.8.4

中村拓也氏のレクチャー

Code for Hakodate[5] に所属している，中村拓也氏から，シビックテック，函館市が抱えている問題についてのレクチャーを受けた．Code for Hakodate とは，「ICT を中心とした函館をちょっとよくするきっかけづくり」をコンセプトとするシビックテック団体である．全体へのレクチャー
では，Code for Hakodate として，何をしたのかの説明や，中村氏自身が考える，いいプロダクトについてご教授いただいた。また、グループでは、現在、自分たちのなかで考えている問題について共有し，アドバイスを頂いた．そこで，実際に，問題を探しにいくことも重要であるとわかり，
フィールドワークの計画を練った．
（※文責: 池端麦）

2.8.5

スクラムワークショップ

本プロジェクトでは，チーム開発の手法として，アジャイル開発の一つである，スクラムを導入
し，プロジェクトを進めていく．スクラムの知識がまだ不十分であるため，株式会社アトラクタ永瀬美穂氏主催のアジャイルワークショップに参加し，スクラム開発について学んだ．これに参加す
る前に，各自で，事前ビデオを視聴し，開発についての初歩的な知識を身につけた．ここでは，ス
クラムにおける，「チームワーク」を高めるために，グループに分かれ，クイズ大会をしたことで，スクラムに関する共通認識をもち，開発の意欲を高めた．

図 2.9

スクラムワークショップ 2022 資料（一部抜粋）（※文責: 池端麦）Group Report of 2022 SISP

- 12 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

2.8.6

GitHub 講習会

Git*3 /GitHub*4 についての知識を得るため，先輩に講師を依頼して，7 月 27 日に Git/GitHub
講習会を行った．講習会を行うにあたり，プロジェクトメンバーは事前に Git のインストールや

GitHub のアカウント作成，SSH 接続などの環境構築を行った．講習会では，昨年度のプロジェク
トにおける利用方法，Git/GitHub の使い方，使用するメリットを学んだ．その後，自分たちで実際にコマンドを使用しながらブランチを作成したりプルリクエストを作成し，開発の中で必要となる基本的な Git/GitHub の使い方を学んだ．Git/GitHub を使用したことがないメンバーが多かったが，知識を有する先輩からの教えによって，開発に向けて Git/GitHub に対する理解を深めることができた．
（※文責: 児玉拓海）*3 https://git-scm.com/*4 https://github.com/

Group Report of 2022 SISP

- 13 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

第3章
3.1

夏季休暇中の活動

夏季休暇での活動方針

中間発表では，作成予定であるプロダクトのおおまかな機能が決まっていただけだったので，プロダクトの詳細について夏季休暇中に決定することにした．プロダクトに必要な機能，使いやすくなる工夫について検討を行い，夏季休暇終了後には開発に入れるよう活動を行った．また，メンバ
各自で Swift*1 の技術習得も行った．
（※文責: 児玉拓海）

3.2

プロダクトの詳細決め

3.2.1

類似アプリの調査

バス検索アプリを作ることになったため，既存のバス検索アプリについての調査を行った．この時にそれぞれのアプリの情報の表示や表現がどのように課題を感じるかについて注目した．調べた
アプリを，情報の表示や表現の観点，機能の観点で，良いところ，課題に感じるところで分けた．
その中で，バス検索アプリとバスロケーションシステムの違いがはっきりとした．バス検索アプリ
はただ乗りたい区間のバスの詳細情報を調べること特化していて，バスロケーションシステムは，
現在バスがどこを走っているのかという情報に特化していることがわかった．(表 3.1)
表 3.1

バス検索アプリとバスロケーションの比較（※文責: 池端麦）

3.2.2

プロダクトの機能

夏休みの段階で決まった，バスの検索アプリの機能を優先順位で紹介する．優先する順番から，• バスの経路検索（入力サポート機能，履歴），2 ）• 地図からの入力機能（ランドマーク機能○，• バス経路の一覧表示，• バスがあと何分でバス停に着くかの表示機能，• お気に入り登録機能，*1 https://developer.apple.com/jp/swift/

Group Report of 2022 SISP

- 14 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
• ヘルプ機能（操作方法），• バス停の時刻表が見れる機能，
1 ，• ランドマーク機能○• 音声読み上げ機能
1 は，出発地と到着地にランドマークを入力するが挙げられた．ここで言う，ランドマーク機能○
2 は，ランドマークを地図上で検索すると，地図ことができるという機能で，ランドマーク機能○

がランドマーク中心の地図になって，バス停が表示され，ユーザーは表示されているバス停を選択できる機能だ．
（※文責: 涌井春那）

3.2.3

機能仕様書

インターンシップに参加したメンバが，インターンシップ先で使用した機能仕様書をもとにして，本グループでも，機能仕様書を制作した．(図 3.1) 変更履歴と開発優先度 (プロダクトバック
ログ)，表示の優先度を決定した．開発優先度 (プロダクトバックログ) はストーリーと優先度，必要に応じて説明を書いた．表示の優先度については，どこの画面で使用する機能なのかとその説
明，その画面内での優先度を記入した．機能仕様については，機能名とアクター，概要，事前条件，
基本フロー，代替フロー，例外フロー，事後条件，必要に応じて補足を記入した．開発の最後にな
ると，ZenHub*2 を多く利用したため，この機能仕様書はほとんど参照しなくなったが，これを決めたことで，開発優先度 (プロダクトバックログ) と表示 (操作順) の優先度は，スムーズに機能を絞ったり，開発に入ることができた．

*2 https://www.zenhub.com/

Group Report of 2022 SISP

- 15 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 3.1

機能仕様書

（※文責: 涌井春那）

3.2.4

プラットフォーム決定

本グループが開発するアプリのプラットフォームに，iOS を採用することにした．理由はグループ内に iOS のアプリ開発経験者がいること，また開発未経験者が 3 人いるため，画面の直感的な操作方法がしやすいといった iOS の開発のしやすさがあるためである．開発言語は Swift を使用，
そしてツールは Xcode*3 を使用した．Swift についての詳細は 5.7.1 節，Xcode についての詳細は

5.9.1 節で述べる．
（※文責: 似鳥亜美）

3.3

函館バス訪問準備

3.3.1

訪問する経緯本グループは夏季休暇明けに函館バス株式会社へ訪問することにした．訪問目的は，本グループの活動紹介と，開発するバスの検索アプリで必要になる函館バスに関するデータをいただくことである．
*3 https://developer.apple.com/jp/xcode/

Group Report of 2022 SISP

- 16 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022（※文責: 似鳥亜美）

3.3.2

資料作成

函館バス株式会社に本グループの活動紹介，開発するアプリを紹介するためのスライド資料を作成した．開発アプリの紹介については，大まかなアプリの概要を説明するだけではなく，開発アプ
リのイメージを掴んでいただけるようにするため，プロトタイプを作成した．コラボレーションイ
ンターフェースデザインツール Figma を用いてプロトタイプを作成し，スライドにプロトタイプの QR コードを載せた (図 3.2)．これにより，Figma*4 アプリをダウンロードしなくとも，スマー
トフォンなどの端末で読み込んですぐにプロトタイプを試していただけるようにした．プロトタイ
プでは開発予定の画面のデザインを見たり，画面のボタンをタップすると画面遷移ができるようになっている．この時に作成したプロトタイプの画面は，5.4.1 節の 図 5.3，図 5.4 に表示している．

図 3.2

函館バス会社訪問資料（一部抜粋）（※文責: 似鳥亜美）

3.4

技術習得

3.4.1

UCD ワークショップ

9 月 18，19 日に，希望するメンバで UCD ワークショップに参加した．UCD ワークショップとは，高度 IT 人材を育成する産学協働の実践教育ネットワークの enPiT[8] の講義の一つである．このワークショップでは，大阪芸術大学の木塚あゆみ講師を招き，人間中心のデザインの考え方とその設計方法を，短期集中の講義及び演習により学んだ．演習では，グループごとに，約 20 年後の未来で使いたい製品・サービはスを考え，ジオラマ上でシナリオを発表した．(図 3.3) UCD ワー
クショップを通じて、PBL 活動に役立つスキルを身につけた．

*4 https://www.ﬁgma.com/

Group Report of 2022 SISP

- 17 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 3.3 UCD ワークショップ発表資料（一部抜粋）（※文責: 池端麦）3.5

開発方針決め

3.5.1

開発形態

開発は，フロントエンド 2 名，バックエンド 2 名，デザイン 1 名に別れて行うことにした．iOS
アプリの開発を行うため，学校から MacBook と iOS 端末を借りた．開発環境は各自で必要に応じて Xcode や Figma をインストールして整えた．また，スクラム手法を取り入れた開発を行うにあたって，「ZenHub」という GitHub の拡張機能を使うことにした．ZenHub についての詳細は，

5.9.3 節で述べる．
（※文責: 高野希澄）

Group Report of 2022 SISP

- 18 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

第 4 章 後期活動内容
4.1

函館バス訪問9 月 28 日に本グループの活動紹介，開発するアプリで必要な函館バスに関するデータをいただ
くことを目的に，函館バス株式会社へ訪問した．
（※文責: 似鳥亜美）

4.1.1

結果

函館バス株式会社の方から，函館バスの GTFS-JP、GTFS-RT データをいただいた．データの詳細については 5.8.1 節，5.8.2 節で述べる．また，開発予定のアプリについて意見をいただいた．
開発予定だった乗り換えなしで行くことができる経路，乗り換えありで行くことができる経路を地
図に色をつけて表示させる機能については，乗り換えがありだとたくさんの経路の組み合わせがあるため，地図で見ることができる経路が膨大になってしまうのではないか，乗り換えありの経路を絞るとしたらどのような基準を設けて絞るのかと意見をいただいた．また，検索ではバス停のみしか入力できないが，現在地から適切なバス停やバスを案内してくれる機能があれば良いのではないかと提案していただいた．バスの検索結果を一覧で見ることができたり，詳細に見ることができる
機能に関しては，多様なユーザの好みやニーズに対応できていて良いと評価していただいた．
（※文責: 似鳥亜美）

4.1.2

機能の見直し函館バス株式会社の方からいただいた意見を踏まえ，開発するアプリの機能を見直した．乗り換
えなしで行くことができる経路，乗り換えありで行くことができる経路を地図に色をつけて表示させる機能は，乗り換えありの組み合わせが多数ある中で経路を絞るのが難しいと判断し取り消し
た．代わりとして，一覧画面で表示させる情報を時刻だけではなく，乗り換え回数を一覧で見ることができる機能に変更した．
（※文責: 似鳥亜美）

4.2

スクラム

効率的でユーザのニーズに合った開発を行うためにスクラムを導入した．スクラム運用期間は，2022 年 10 月 7 日から 2022 年 12 月 6 日までだった．この期間のうち 2022 年 10 月 7 日から 2022
年 10 月 12 日まではスプリント 0 として，スクラム開発に慣れることを目的として FizzBuzz アプ
リを作成する期間を設けた．スプリント 0 では，スプリントプランニング，デイリースクラム，レトロスペクティブのみを行った．各スプリントでの詳しい活動内容や作成物については 4.3 節で述Group Report of 2022 SISP

- 19 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
べる．各スプリントの期間は，レトロスペクティブででた意見を元にグループにあった期間を話し合いによって設けた (表 4.1)．

表 4.1

スプリント期間一覧（※文責: 高野希澄）

4.2.1

デイリースクラム

デイリースクラムは Discord を用いた同期型のものと Google Document を用いた非同期型のものを組み合わせた形で行った．平日は，Google Document に「昨日したこと」「今日すること」「問題」を各自で 12:45 までに記入した（図 4.1）．そして，12:45 に Discord に集まった際に記入
内容の確認を行った．記入内容に関して疑問に感じたことや問題に関しての話し合いも必要に応じて行った．気になった部分だけを取り上げて話し合いを行うことでデイリースクラムの時間を 10分から 15 分ほどに抑え，長時間の集まりにならないことを心がけた．休日は，Google Documentへの記入のみとし，気になった部分は Slack を使用して確認することにした．

図 4.1

デイリースクラムでのメンバの記入（※文責: 高野希澄）

Group Report of 2022 SISP

- 20 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

4.2.2

スプリントプランニング

スプリントプランニングでは，スプリントバックログを作成してそのスプリントにやらなければ
ならないことの計画を立てた．まず，プロダクトオーナーがそのスプリントでのスプリントゴール
をメンバに共有，説明を行った．そして，ZenHub で作成したプロダクトバックログの粒度を細かくした項目の中から，そのスプリントで行う項目を選び，スプリントバックログを作成した．その後，ZenHub の機能を利用してプランニングポーカーを行い，各項目の工数の見積もりを立てた．
（※文責: 高野希澄）

4.2.3

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

スプリントレトロスペクティブとは，開発チーム内でそのスプリントの反省を行うスクラムのイベントである．私たちは，スプリントレトロスペクティブを Miro 上で行った．Miro 上では，Keep(続けたいこと)，Problem(問題点)，Try(次回やること) を各メンバが付箋で書いていく KPT法という手法をとった（図 4.2，図 4.3，図 4.4）．Keep と Problem から今回のスプリントのよい点や課題点を分析し，次回以降どのように対策をとるかなどを Try で話し合った．Miro 上では，付箋の色分けをすることによって誰の意見なのかがわかるようにした．スプリントレトロスペク
ティブを行う際は，個人の問題としてではなく，グループの問題として捉えることを心がけること
で，グループとして改善を図ることができるようにした．

図 4.2 Miro 上で行ったスプリントレトロスペクティブの様子 1Group Report of 2022 SISP

- 21 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 4.3 Miro 上で行ったスプリントレトロスペクティブの様子 2

図 4.4 Miro 上で行ったスプリントレトロスペクティブの様子 3（※文責: 高野希澄）

4.2.4

スプリントレビュー

スプリントレビューは，そのスプリントでの成果を先生や TA に発表してレビューを受けた．ス
プリントレビューでは，プロダクトオーナーがそのスプリントでのゴールや達成できたタスク，達成できなかったタスクとその原因などを資料にまとめ，スプリントでの成果を発表した．また，プGroup Report of 2022 SISP

- 22 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
ロトタイプや作成途中のアプリのデモを触ってもらうことで，プロダクトに関する感想をもらい，プロダクトの機能やデザインを見直した（※文責: 高野希澄）

4.2.5

リファインメント

リファインメントでは，スプリント中に 1 時間ほど時間をとってプロダクトバックログの見直しを行った．スプリントレビューでの意見やメンバが作業中に感じた疑問点などを参考にプロダクト
バックログの項目の順番に問題が無いかや項目自体に本当に価値があるのかの確認を行った．また，プロダクトバックログの項目を細かい粒度に分解することもここで行った．
（※文責: 高野希澄）

4.3

各スクラムでの活動

4.3.1

スプリント 0(10 月 7 日〜10 月 12 日)

スプリント 0 では，スクラム開発になれることを目的とし，FizzBuzz アプリを作成した．

FizzBuzz アプリのルールは以下のとおりとした．
• カウントボタンを押すと 1 から順に 100 まで表示される• 3 の倍数なら，Fizz を表示される• 5 の倍数なら，Buzz を表示される• 15 の倍数なら，FizzBuzz を表示される
このスプリントでは，スプリントゴールを，Swift に慣れる，FizzBuzz アプリ完成とし，1 週間でスプリントを回した．初めてスクラム開発を行う手順を踏んだため，スプリントバックログを考える段階で，どれくらいの粒度にするか，また，重みをつけるか考えるのに時間がかかった．また，今回のスプリントで，Git を使う練習も行ったため，全員が，リポジトリからクローンした環境でブランチを切り，プッシュし，プルリクエストを出すということをした．このスプリントでは，メンバ同士でスプリントレビューを行い，FizzBuzz アプリを作れていることを確認した．スプリン
トレトロスペクティブでは，主に Git の使い方や，スクラムについての課題が挙げられた．Git の使い方については，ブランチ名の命名規則が曖昧だったため，「機能名-作成者名」とした．また，
プルリクエストを出した後のレビューが遅かったため，レビューが来ない場合は，Slack でアナウ
ンスするということにした．スクラムについて，知識が乏しかったため，スクラムに出てくる言葉の意味をきっちりと理解することを目的に，スクラムに関する本を読むことにした．

Group Report of 2022 SISP

- 23 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 4.5

レトロスペクティブ（try）：スプリント０（※文責: 池端麦）

4.3.2

スプリント

スプリント 1(10 月 13 日〜10 月 25 日)
スプリント 1 では，アプリの開発とデザインの修正を 2 週間のスプリントで行った．スプリント
ゴールを，以下のように設定した．

Group Report of 2022 SISP

- 24 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
• 出発地と目的地をテキストで入力してバスの一覧を見ることができる• 現時点で上がっているデザインの問題点を解決し，改善する
このスプリントでは，函館市民が思う函館のイメージカラー [9] を参考に, このアプリのイメージ
カラーを青に決定した．また，テキストを全体的に統一したり，文字数が多い場合のテキストの配置などを決めた．また，このアプリで使用する GTFS-JP と GTFS-RT の技術検証を行った．

GTFS-JP は JSON 形式に変換し，その JSON ファイルを Swift で扱い，GTFS-RT は Python*1
で整形し，そのデータを Firebase*2 に収納するようにした．今回からのスプリントレビューは，教員方にお願いした．スプリントレビューでは，主にデザインに関するレビューをいただいた．また，地図から入力する機能についての必要性を問われた．地図から入力する機能を必要とする裏付けとして，函館市で開催されているイベントのチラシを調べ，その中に，住所や開催される建物名は書かれてあるが，バス停名が書かれてあることが少ないということがあった．このため，地図から入力する機能は，このアプリには必要と考えた．今回のスプリントでは，スプリントバックログ
をほとんど消費することができなかったことが問題にあがった．その理由として，技術検証に多くの時間が割かれたことが原因だと考えた．スプリントレトロスペクティブでは，レビューが遅いということから，プルリクエストがされると Slack に通知が来るように設定したり，コーディング規
約を見直した．タスク管理について，タスクを分割したり，追加した場合は，次の日のデイリース
クラムで共有することにした．また，タスクを２人で共有してたこともあり，進捗に遅れが出た
り，共有することが難しかったため，タスクの共有をすることをやめ，作業分担を，デザイン，フロントエンド，バックエンドとわけた．

図 4.6

レトロスペクティブ（try）：スプリント 1（※文責: 池端麦）
*1 https://www.python.org/*2 https://ﬁrebase.google.com/

Group Report of 2022 SISP

- 25 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
スプリント 2(10 月 29 日〜11 月 8 日）
スプリント 2 では，前回のスプリントレビューで受けたデザインの修正と，テキストから入力した場合の検索機能の実装を，2 週間のスプリントで行った．スプリントゴールを，以下のように設定した．

• 全ての画面（データなどは入っていない）を作り，遷移できる• 一覧表示ができる画面までには，データが表示されている
このスプリントでは，大幅に画面デザインを変更した．ボタンなどの，アクセントカラーが目立つように，背景を白っぽい色にしたり，できる限り長い文字数のバス停名を表示させるために，テキストフィールドを画面の端まで使ったデザインにした．バックエンド側では，Firebase のセキュリティを強化したり，バスのリアルタイムの位置を取得するため，定期実行が行えるようにした．
また，直通でいける範囲の出発バス停と到着バス停が選択された場合の時刻を取得できるようにした．フロントエンド側では，このアプリで必要とされる画面を作成し，それぞれの画面で遷移できるようにした．今回のスプリントレビューでは，主に，大幅に変更した画面のデザインについてレビューをいただいた．特に，選択されたバスの詳細情報を表示する画面で，どのような表示順にすれば，よりユーザが理解しやすくなるのかについて，ご教授いただいた．スプリントレトロスペ
クティブでは，プルリクエストを出した後のレビューと，ZenHub のタスクの動かし忘れなどについて話し合った．プルリクエストを出したのち，レビューが遅く，次のタスクに移れないということがあった．それを改善するために，前回は，Slack にプルリクエストされると通知がいくように設定したが，少し改善されたが，まだ問題点として残った．その理由として，レビューの仕方が曖昧，また，どのタスクのプルリクエストかわからないということがあった．それを解決するため，
プルリクエストのテンプレートを作成した．プルリクエストを出す時の名前は，行ったタスクの名前を書いた．issue 番号を明記したため，それが具体的にどのタスクなのか，リンクからとび確認をすることができる．また，そのタスクで，どのようなことを行なったかを，受け入れ要件にかき，チェックリストで確認し，漏れがないようにした．その受け入れ要件を達成した際に，どのような動きになるのかを，レビュワーと共有するため，画面のスクリーンショットや，動画を貼り，共有できるようにした．また，ZenHub のタスクを「実施中」から「レビュー中」への動かし忘れがあるため，それを防ぐために，チェックリストを作成した．

Group Report of 2022 SISP

- 26 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 4.7Group Report of 2022 SISP

プルリクエストテンプレート例- 27 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 4.8

レトロスペクティブ（try）：スプリント 2（※文責: 池端麦）
スプリント 3(11 月 10 日〜11 月 16 日)
スプリント 3 では，一覧画面と詳細画面にデータを表示させた．スプリントゴールを以下のように設定した．

• 乗り換えありも含めた情報を一覧画面に表示することができる• 詳細画面で料金、乗り換えが関わるもの，いくつ前を通過したかの情報以外を表示することができる
スプリント 3 からは，開発に慣れてきたということもあり，さらに開発スピードを上げるために，
スプリント期間を 1 週間にした．このスプリントでは，出発，到着バス停を入力し，検索ボタンを押すと，一覧画面に，その区間の直通のみの時間が全て表示されるようになった．また，一覧画面の時刻と，詳細画面の情報を紐づけるようにし，詳細画面に時刻，バス停名が表示できるようにした．スプリントレビューでは，現在，検索ボタンを押した後，一覧画面に遷移するまでに時間がかかって，再度検索ボタンをタップしてしまうということもあり，それを防ぐために，ローディング
画面があるとよいとアドバイスを受けた．また，一覧画面で，時刻のみの情報だけでなく，それに乗換時間や，乗換回数などの情報を付け加える良いかもしれないとアドバイスを受け，Figma で実際に作成し，確認した．スプリントレトロスペクティブでは，プルリクエストを出した後のレビューの遅さ，またデザインのタスクの進捗が把握しにくいなどの問題について話し合った．プ
ルリクエストを出した後の，レビュー，その後のマージまで時間がかかるという問題は以前から，

Group Report of 2022 SISP

- 28 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
ずっとあり，Slack に通知をいくようにしたり，プルリクエストのテンプレを作ることによって，どのようなタスクをしたのかの共有をしてきたが，まだ，改善されなかった．特に，マージされな
ければ，次のタスクに進めなかったり，それが原因で，コンフリクトが起こることもあった．これを改善するために，レビュワーを 2 人に減らし，レビューが遅い時には，Slack の GitHub の通知
がいくところに，メンションをつけ，レビューしてもらうようにした．また，レビューをする際に，様々なバス停名を用いて検索し，その結果をスクリーンショットを撮って，共有した．2 人に減らしたことにより，より慎重にレビューを行った．また，コンフリクトを発見した際には，発見した人が，GitHub 上にコメントしたり，Slack にメンションをつけて，作成者に報告し，コンフリク
トが発生していることを知らせるようにした．デザインのタスクの進捗については，テキストファ
イルにどこを直したかを記載，プルリクエストを出し，どのように変更したかなどを共有できるよ
うにした．

図 4.9

レトロスペクティブ（try）：スプリント 3（※文責: 池端麦）
スプリント 4(11 月 17 日〜11 月 22 日)
スプリント 4 では，詳細画面にさらに情報を表示させた．さらに，地図からバス停を入力できるようにした．スプリントゴールを以下のように設定した．

• 詳細画面で，時刻，バス停，乗り場，所要時間，行き先を表示できる• 地図画面でバス停のピンを選択し，検索できる• ホーム画面，入力画面，一覧画面のオートレイアウト化する
このスプリントでは，選択した時刻での，詳細情報を表示できるようにした．また，地図からバス

Group Report of 2022 SISP

- 29 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
停を入力できるようにするため，地図上のバス停がある場所に，ピンをたて，そこをタップすると確認画面が表示され，入力できるようにした．今回のスプリントレビューは，非同期形式で行ったため，現在仕上がっている部分のデモ動画を用意した．検索ボタンを押した後，一覧画面に遷移するまでの時間が 2 分以上かかってしまうということが問題に挙げられた．これは，次のスプリント
で，解決した．スプリントレトロスペクティブでは，ZenHub のタスクの動かし忘れ，また，プル
リクエストのアプルーブし忘れが問題となった．ZenHub のタスクの動かし忘れについては，デイリースクラムで確認し，動かし忘れがあれば，その際に報告するようにした．プルリクエストのレビューで，コメントをしているが，アプルーブをするのを忘れているということがあり，マージができなくなってしまっていたため，それを防ぐために，デイリースクラムで，現在どのプルリクエ
ストがあるのか，またレビューがどれくらいされているのかを確認するようにした．

図 4.10レトロスペクティブ（try）：スプリント 4（※文責: 池端麦）
スプリント 5(11 月 24 日〜11 月 29 日)
スプリント 5 では，現在仕上がっている部分の細かな修正と，バックエンド側で行なっていたものを，画面に反映させた．スプリントゴールを以下のように設定した．

• 地図画面で，ランドマーク機能が使うことができる• 日付を指定して，バスを検索することができる• バックエンド側で，乗り換えを含んだ時刻，いくつ前のバス停を出発したか，また，料金がわかる
このスプリントでは，乗り換え場所を亀田支所と五稜郭に絞り，乗り換えを含んだ時刻を表示できるようにした．また，検索する時の日付や時刻に関して，ユーザが使いやすいように，修正をした．
スプリントレビューでは，地図上からバス停を入力する際に，現在地周辺が表示され，現在地がわかる画面の方が良いのではないかと，指摘いただいた．これは，次のスプリントで改善した．スプ
リントレトロスペクティブでは，回数をこなし，スクラム開発に慣れてきたため，あまり問題はな
かったが，デイリースクラムのかき忘れや，コンフリクトについての問題について話し合った．デイリースクラムを書き忘れている場合は，Slack でメンションをつけるということにした．

Group Report of 2022 SISP

- 30 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 4.11

レトロスペクティブ（try）：スプリント 5（※文責: 池端麦）
スプリント 6(11 月 30 日〜12 月 6 日)
スプリント 6 では，スプリント 5 同様に，現在仕上がっている部分の細かな修正と，バックエン
ド側で行なっていたものを，画面に反映させた．前回のレビューで指摘あったように，地図画面に現在地を表示したり，出発地と到着地のバス停を入力する際の地図画面の拡大倍率を変えたりした．また，バックエンド側で行なっていた，いくつ前のバス停を出発したかという情報を表示させた．スプリント 6 では，成果発表前ということもあり，スプリントレビューやスプリントレトロス
ペクティブは行わなかった（※文責: 池端麦）

4.4

HAKODATE アカデミックリンク 2022

4.4.1

概要

2022 年 11 月 10 日〜12 月 4 日に開催された HAKODATE アカデミックリンクに，すうぃふとプロジェクトから，私たちのグループを含む，全 3 チームが参加した．HAKODATE アカデミッ
クリンクとは，函館市内にある 8 つの高等学校教育機関の学生が一堂に会し，普段研究している
内容や成果などをプレゼンテーションやパネル展示で発表する合同研究発表会である [10]．私たちは，「函館地域のバスを利用しやすくするアプリ

ばすうぃふと」として参加した．今回はオンラ

インでの動画としての発表と，スライドのみの発表形式があり，スライド形式で参加した．もうすでに開発に取り掛かっており，開発を主にしていたメンバは忙しかったため，主にデザインを担当していた，池端と似鳥が主にスライドを作成した．スライドの内容自体は，次節にて記述する．

4.4.2

発表内容と結果

発表方式は，スライドのみを提出し，発表を見に来てくださった方に，読んでもらう形だった．
函館市の交通について議論した結果やバス利用のフィールドワークを行い，調べる時に多くの問題があったことを記した．また，アプリを制作するにあたって，既存のアプリとの比較も行ったた
め，それについても記した．その後，アプリの概要や想定ユーザ・ペルソナなどを紹介し，基本的Group Report of 2022 SISP

- 31 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
な使い方と主要な機能を紹介した．スライドについては，付録に添付する。

4.5

成果発表

4.5.1

成果発表資料作成

12 月 9 日に行われたプロジェクト学習成果発表会に向けて，メインポスター，グループポス
ター，発表原稿を作成した．メインポスターには，開発体制や，作成したアプリの推しポイントを簡潔に表記した．また，グループポスターには，アプリ開発前の過程や，コンセプトをどのように考えたかを記載した．さらに，なぜこの機能を必要としたかを記載した．ポスター作成には，

Adobe Illustrator*3 を用いた．
（※文責: 池端麦）

4.5.2

概要

12 月 9 日に 2022 年度「プロジェクト学習」の成果発表会が行われた．私たちのプロジェクトでは，プロジェクト全体の概要発表をスライドを用いて行ったのち，それぞれのグループのブースに分かれてポスター発表とデモ実演を行った．（図 4.12）私たちは，ポスターの説明はさほどせず，デモに重きを置いた発表をした．発表に用いたポスターは，付録に添付する．

図 4.12

成果発表の様子（※文責: 涌井春那）*3 https://www.adobe.com/jp/products/illustrator.html

Group Report of 2022 SISP

- 32 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

4.5.3

フィードバックと改善発表をする中で，直接頂いた感想・提案・質問を紹介する．質問として，「時刻を一覧で見ることができるのが良い」という感想があった．これに関しては，私たちのアプリの一番個性的な部分でもあるため，とても嬉しく感じた．提案は，「いくつ前のバス停出発をテキストで表すのではな
く，バス停のマークやスゴロクで表示させるなど，視覚的に分かりやすくさせてはどうだろうか」，「通過しましたを色で強調（赤とか）すれば良いのではないか」というものがあった．この 2 つは，「いくつ前の表示」をどのようにするかによって決定のため，検討するということになった．また，「一覧でスクロール上の固定部分に影をつけているように，詳細部分でも影をつけた方がよいのではないか」という意見については，実装する予定である．さらに，「バスアプリでよく見るフォントだから，差別化や独自性のために，全体的なフォントを変えてみてはどうだろうか」と，「バスのピンの色を見直したらどうか」については，実装しない方向で決定した．「現在のバスの位置が地図で見れたら良いのでは？」については，進捗次第ではあるが，検討することになった．その他の質問として，「ペルソナは何通りか考えたのか，どうしてメインターゲットをこの人にしたのか」「現段階でどのくらいの完成度なのか．どのような機能を他に考えたのか」「マップの数字はどういう意味のもの？」「スプリントをどうやって回した？」「開発していく中でどれが難しかった？」「動
的データはどうやって取ってきている？動かしている？」「正しいバス停が取れてきているの？」「リリースはしないの？」などの質問があった．主に，デモの上での質問や，開発手法についてな
どの質問があった．
次に，プロジェクト全体のアンケート結果について紹介する．発表技術についての評価は，平均
約 8.64 で，発表内容についての評価は，平均約 8.5 と高評価だった．全体的な発表技術について
は，スライドのわかりやすさや，デモ機を用いて発表している点，しっかりと受け答えできた点が高評価の理由であった．しかし，3 グループに分かれて発表していたため，それに混乱してしまった人も少なからずいたため，それによった低評価もあった．発表内容については，私たちのグルー
プだと判断できる感想からだと，実際触ってみて，よく出来ているアプリだと感じたという声や，開発手法について良いと思ったという評価の一方で，複数のアプリの組み合わせ感を感じたり，動作が重いとの指摘があった．
実際に受け取った指摘や質問・Google フォームからのアンケート結果から，アプリを改善していきたいと思う．また，今後秋葉原での課外発表などに参加する際は，今回の成果発表会での発表
技術・発表内容のアンケート結果を活かしていきたい．
（※文責: 涌井春那）

4.6

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

成果発表会の翌日 12 月 10 日に enPiT BizSysD 北海道・東北合同発表会が oVice[] 上で行われた．発表は前半後半に分かれていて，それぞれのブースで前半または後半に質疑応答を含めた 10
分間の発表を 6 ターム行う形式だった．発表資料として，最終成果発表会で使ったグループポス
ターを再利用した．この発表会は他大学と合同で行われ，他大学の方々に自分たちのプロダクトについて興味をもってもらうことができた．本発表会で開発したプロダクトについて高い評価をいた
だき，最優秀賞を受賞することができた．発表会を通して，他大学の活動，発表技術を見ることができて勉強になった．また開発プロダクトに関する意見，評価をいただくことができた．

Group Report of 2022 SISP

- 33 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022（※文責: 児玉拓海）

4.7

最終報告書

最終報告書は，成果発表会後に作成を始めた．前期の中間報告書を書いた際，今までの活動内容を思い出し，該当部分の過去資料を探すという手間があったため，当初は普段の活動と並行して，最終報告書に書く内容を簡単にメモをしていく方針だった．しかし TA から同時進行よりも成果発
表会後に取り組み始めた方が良いとアドバイスをいただき，成果発表会後に本格的に作成を始めた．また，中間報告書では章ごとに担当箇所を決めた結果，文章量に差が生じてしまったため，最終報告書ではメンバ全員で章立てを詳細に行ってから，担当を箇所を決めた．
（※文責: 似鳥亜美）

4.8

ユーザレビュー

完成したアプリの紹介とユーザレビューを目的に，2023 年 1 月 11 日に函館バス株式会社へ二度目の訪問をした．実際にアプリを使用していただき，そこでいただくフィードバックをもとに更なるプロダクト改善を目指す．
（※文責: 似鳥亜美）

4.8.1

いただいたフィードバック

アプリで提供するリアルタイムの情報を予想ではなく事実の情報にしたことを良く評価していた
だいた．改善点として検索スピードを早くすることや乗り換えの便を正確にすることをあげていた
だいた．乗り場は「〇〇前」などの名前より「〇番」の番号の方が分かりやすいとおっしゃってい
たが，本アプリで表示している乗り場は名前だけのものと番号があるものが混在しているため改善の必要がある．提案として，出発時間で並び替えている便の検索結果一覧を到着時間や乗り換え回
数で並び替えたり絞ったりする機能をおっしゃっていただいた．さらにバスによく乗る人，あまり乗らない人でアプリのモードを分けることができれば，備える機能も分けることができるため，よりユーザに寄り添ったアプリになるのではないかと提案していただいた．他に函館バスのバスロ
ケーションシステムや函館バス株式会社についてのお話していただいた．またプロジェクト学習が終わってからも引き続きデータを使用をさせていただくことの許可をいただいた．
（※文責: 似鳥亜美）

Group Report of 2022 SISP

- 34 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

第 5 章 プロダクト
5.1

プロダクト概要

本チームでは，函館地域のバスを使いやすくすることを目的として活動している．函館地域のバスに着目した理由として，メンバで函館地域の交通課題を列挙していくとバスに関する課題が多く挙げられたためである．実際に函館地域のバスを利用すると乗車するバスを調べる時に多くの課題を発見できた．そこで本チームは，函館地域のバス検索をサポートするモバイルアプリケーション「ばすうぃふと」を考案した．既存アプリケーションで使いにくいと感じる部分を補う機能の実装
により，バス検索をサポートできるのではないかと考えた．本アプリケーションでは，検索経路のバス時刻を始発から終発まで一覧で表示することに加え，地図からの停留所入力により，停留所名
がわからないときでも目的地付近の停留所を探すことができる．検索したバスが現在運行中の場
合，バスの走行位置をリアルタイムで取得し，位置情報を提供します．またアプリケーションの使
いやすさを実現するために UI と一画面に表示する情報量にも検討を重ねている．
（※文責: 児玉拓海）

5.2

コンセプト決定5.2.1

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

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

1. 解決した課題，潜在ニーズ
2. 対象ユーザは誰か
3. プロダクト名
4. プロダクトのカテゴリー
5. プロダクトの持つ重要な利点，最大の長所
6. 代替手段，競合相手，比較対象
7. 決定的な特徴
本チームでは，以下のように決定した．

1. 函館地域のバス利用をサポートする
2. 函館市民
3. ばすうぃふと
4. バス経路検索アプリ
5. バスの経路を一覧表示
6. 既存のバス経路検索アプリ
7. マップからの停留所入力とリアルタイムでバスの走行位置がわかる

Group Report of 2022 SISP

- 35 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022（※文責: 児玉拓海）

5.2.2

ペルソナシートの作成

今回のプロダクトのユーザを決定するためにペルソナ設定を行った．ペルソナとはサービス・商品の典型的なユーザー像のことであり，実際にその人物が実在しているかのように，年齢，性別，
居住地，職業，役割，趣味などを細かくリアリティのある情報を詳細に設定する．本チームでは，
ぺルソナシートを作成した (図 5.1)．ペルソナシートの作成により，プロダクトを提供するユーザ
像をイメージしやすくなり，必要な機能の選定が可能となった．

図 5.1

作成したペルソナシート（※文責: 児玉拓海）

5.2.3

ターゲットユーザの決定

本チームでは，設定したペルソナから，ターゲットユーザを決定した．「ばすうぃふと」のター
ゲットユーザは，函館地域のバスを使い慣れていない利用者である．ターゲットユーザの利用時の混乱を避けるため，簡単な機能操作，少ない画面遷移，見やすい UI，誤タップ防止を考慮し，プロ
ダクトのデザインを行った．
（※文責: 児玉拓海）

5.2.4

バリュープロポジションキャンバスの作成

本チームでは，考案した機能とユーザのニーズの間にずれがないかを確認するために，バリュー
プロポジションキャンバスを作成した (図 5.)．バリュープロポジションキャンバスとは，製品やサービスと顧客のニーズのずれを解消するためのフレームワークである．バリュープロポジション
キャンバスの作成により，自分たちの考案した機能から必要となる機能を選定することができた．
（※文責: 児玉拓海）Group Report of 2022 SISP

- 36 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 5.2Group Report of 2022 SISP

作成したバリュープロポジションキャンバス- 37 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

5.3

機能決定

5.3.1

バス時刻一覧

この機能では，検索した区間のバス運行時刻を一覧で表示する．現在時刻に一番近いものが画面上部に表示されるように自動でスクロール開始位置が変更される．スクロールによって他の時刻を自由に見ることができる．この機能によって，ユーザが時刻を指定したり，調べ直す手間を省くことが可能となる．
（※文責: 児玉拓海）

5.3.2

地図

この機能では，地図上に表示されたピンを選択することで停留場を入力することができる．地図
画面上部にある検索ボックスから通常の地図検索を行うことができる．この機能によって，停留所
名がわからなくても目的地付近の停留所を入力できる．
（※文責: 児玉拓海）

5.3.3

リアルタイムバス位置

この機能では，検索したバスが運行中の場合，バスの走行位置情報を「〇〇前のバス停を出発しました」という形式で提供する．この機能によって，従来の運行時刻から予測するバス到着予測よりも，高い精度のバス到着予測を提供することができる．
（※文責: 児玉拓海）

5.3.4

お気に入り・履歴バス停

この機能では，お気に入りのバス停と過去に検索に使ったことのあるバス停を，バス停入力画面
であらかじめ表示する．この機能によって，ユーザのよく使うバス停を入力するときの手間を省くことが可能となる．
（※文責: 児玉拓海）

5.4

画面デザインの決定

5.4.1

Figma でプロトタイプの作成

このアプリのプロトタイプを Figma を用いて作成し，「実際に生産しても問題ないか，試作品を一つ作って色々な検証を行う」という目的で行なった．[9] プロトタイプを用いることにはメリットがある．まず，実際にユーザにテスト体験をしてもらうことができる．これにより，制作開始前に，レビュワーの意見を参考に実際にデザインを大幅に変更し，より良いデザインにすることができた．また，メンバ同士でのアプリの概要について，認識のズレを回避することができる．常に，Group Report of 2022 SISP

- 38 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
変化していくアプリデザインを，Figma に反映していたため，メンバが最新のデザインをすぐに確認することができた．
初期案 対象とするユーザを，老眼でスマホの画面などの文字を認識することができない人を想定したため，文字の大きさをかなり大きく作成していた．また，枠で囲み，それぞれの項目での区別をつけていた．

図 5.3

初期案１

図 5.4

初期案２

最終案 対象とするユーザでも認識することのできる文字サイズを調べ，実際に使ってもらい，認Group Report of 2022 SISP

- 39 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
識することを確認し，文字サイズを決定した．また，画面を全体的にシンプルな色にし，画面全体を大きく使えるような工夫をした．

Group Report of 2022 SISP

図 5.5

最終案１

図 5.6

最終案２

- 40 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022（※文責: 池端麦）

5.5

アプリの流れや使い方について

本アプリケーションの流れを実際のアプリケーションの画面を用いて説明する．まず，アプリの画面は，大きく分けて，ホーム画面，入力画面，地図画面，一覧画面，詳細画面がある．
ホーム画面の出発バス停を押すと，入力画面に移る．入力画面にて，テキストフィールドを選択することで，キーボードでバス停名を打ち込むと，予測欄にバス停名が出てくる．出てきたバス停
名をタップすることにより，ホーム画面に戻り，出発バス停の箇所に入力画面で選択したバス停名が入っている状態になる．これは，ホーム画面で到着バス停を選択した場合も同じ遷移である．
ホーム画面では，日にちも指定できる．デフォルトだと当日の日にちになっているが，ドラムピッ
カーを回すことにより，日にちを変更できる．また，過去の日にちは選択できないようになっている．ホーム画面の出発バス停と書いてあるところの横にあるマップアイコンを押すと，地図画面へ遷移する．地図画面のテキストフィールドでは，ランドマーク検索を行うことができるため，例えば，「シエスタ」と入力すると，シエスタの近くの地図が表示され，その近くのバス停アイコンをタップし，ポップアップで決定を押すと，ホーム画面に戻り，出発バス停のところに選択したバス
停が表示される．これは，到着バス停の横にあるマップアイコンを選択した場合も同様な動作だ．
ホーム画面の検索を押すと，検索ができ，一覧画面へ遷移する．一覧画面では，出発バス停と到着
バス停，日にち，時間ごとの出発時間と到着時間，乗り換え回数が確認できる．それぞれの出発時
間と到着時間のボタンを押すと，詳細画面に遷移ができる．詳細画面では，乗換回数，料金，所要時間，出発時間と到着時間，系統，行き先，いくつ前のバス停を出発したかが確認できる．乗換がある場合は，乗換がある場合の乗り換え時間や乗換場所が確認できる．

Group Report of 2022 SISP

- 41 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
図解

図 5.7

Group Report of 2022 SISP

アプリの流れの図解- 42 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022（※文責: 涌井春那）

5.6

開発済みの画面

5.6.1

ホーム画面

機能と概要
私たちが開発したアプリ「ばすうぃふと」を開くと，一番最初に表示される画面がホーム画
面だ．ホーム画面には大きく，4 つの機能（入力画面への遷移，マップ画面への遷移，一覧
画面への遷移，バス停入れ替え，日にち設定機能）がある．まず，入力画面の遷移についてだ．出発地バス停を選択もしくは到着バス停を選択のボタンをタップすると，入力画面に遷移する．入力画面で設定したあと戻ってくると，出発地バス停欄もしくは到着バス停欄に選択したバス停が表示されるようになっている．また，マップアイコンをタップすると，地図画面へ行き，そこで選択しても同様に，出発地バス停欄もしくは到着バス停欄に選択したバ
ス停が表示されるようになっている．ホーム画面の両矢印アイコンをタップすると，出発地と到着地のバス停を入れ替えることができる．日にちの部分をタップすると，ドラムロール
で日にちを設定できる．設定日にちは，過去を選択することはできないようになっており，
今日以後のみ選択することができる．
何が嬉しいか
この画面は，出発地と到着地，日にちのみ主に 3 つのみを選択すれば良いため，ユーザの認
知負荷・操作負荷を下げることができ，とても使いやすい UI になっている．
実装できていること・できなかったこと
実装できていることは，上記で説明したとおりのことができている．デザインも修正済みであるので，計画していたすべてのことは実装出来ている．計画段階で決めていた機能で実装できなかったことは無い．
どのように実装したかや意識したこと

Storyboard と，Swift コードで実装した．日にちのドラムピッカーは，過去を選択すると，自動で今日の日にちに戻るように実装した．実装するにあたって，UIKit と CoreLocation
を import した．

Group Report of 2022 SISP

- 43 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 5.8

機能仕様書

（※文責: 涌井春那）

5.6.2

入力画面

機能と概要
ホーム画面の出発バス停ボタンもしくは到着バス停ボタンをタップすることによって遷移するのが入力画面だ．バス停入力画面の機能は，キーボード入力機能，予測機能，履歴機能，お気に入り機能だ．キーボードで入力すると，予測したバス停名が表示され，それを選択す
ると，ホーム画面へ遷移し，選択したバス停が出発バス停もしくは到着バス停のところに表示される．
何が嬉しいか予測機能や履歴機能，お気に入り機能があることによって，毎回自分でバス停を入力する必要がなく，手間が減り，楽にバス停を選択することができる．
実装できていること・できなかったこと
実装できていることは，キーボードで正しくバス停名を打ち込むと，予測欄にバス停名が表示され，それをタップすると，ホーム画面へ遷移し，選択したバス停が出発バス停もしくは到着バス停のところに表示されることだ．入力途中でも予測される機能や履歴機能，お気に入り機能はまだ実装できていない．
どのように実装したかや意識したことGroup Report of 2022 SISP

- 44 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
きち んとバス 停が 入力 され たと き だけ ボ タン が有 効化・表 示されるように工夫した．
ま た ，SearchGTFS の 関 数 を 実 装 し ，ViewController の Swift フ ァ イ ル で は な く ，SearchGTFS.swift に記述し，わかりやすくした．import は UIKit のみした．

図 5.9

機能仕様書

（※文責: 涌井春那）

5.6.3

地図画面

機能と概要
ホーム画面で地図のアイコンを押すと遷移する画面が地図画面である．この画面では，地図上にバス停の位置がピンで表示されている．表示されているピンから出発バス停，到着バス
停の入力をすることができる．ピンはバス停の名前でクラスタリングされている．
何が嬉しいか
この機能により，バス停名がわからない場合でも，地図から目的地を探し，近くのバス停を選択できる．また，バス停の位置がわからない場合，バス停を探すことができる．
実装できていること・できなかったこと
地図上に表示されているバス停のピンから出発バス停，到着バス停を入力できる．また，函館地域の場所なら画面上部に配置された検索ボックスからランドマーク検索を行うことができる．実装できなかったこととして，バス停の検索機能があげられる．検索ボックスにバス

Group Report of 2022 SISP

- 45 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
停名を入力した場合に，入力されたバス停のピンを強調表示できるようにすることが今後の課題である．
どのように実装したかや意識したこと

GTFS のデータからバス停の座標を取得し，地図上にバス停を表示している．表示されるバ
ス停は，実際に設置されているバス停のみに絞った．バス停は地図の縮小倍率を変更することでクラスタリングされる．クラスタリングには，バス停名が同じバス停を指定している．
クラスタリングされたピンの個数を表示するようにもしている．ユーザの使いやすさを意識することで，地図の表示範囲や，ピンの色，クラスタリングの実装に繋がった．

図 5.10

地図画面（※文責: 児玉拓海）

5.6.4

一覧画面

機能と概要
ホーム画面で検索ボタンを押すと遷移する画面が一覧画面だ．この画面では，出発バス停
名と到着バス停名，出発時間と到着時間，乗換回数を確認することができる．出発時間は 7時，8 時など，時間でまとまって見ることができる．
何が嬉しいか
今までよくあった類似バス検索アプリは，早い順・安い順など条件ごとに 3 つほどしかバス

Group Report of 2022 SISP

- 46 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022の候補見ることができなかったが，このアプリは一気に始発から終発まで一覧で時間を確認することができ，一覧画面に乗換回数も表示されていることにより，乗換回数によってユーザがバスを選びやすくなっている．
実装できていること・できなかったこと
ホーム画面から検索されれば，一覧画面に飛ぶことが出来ている．また，出発バス停名，到着バス停名，出発時間と到着時間が正しく表示されている．出来なかったことは，今現在 07
時や 08 時，07:48 などとなってしまっているので，それを直したほうが良いということと，
検索画面から一覧画面に遷移すると，動作がとても重く，操作しづらいため，それを改善する必要がある．
どのように実装したかや意識したこと

GTFS から値を取ってきて，その値をもとに動的にボタンを生成し，必要な数だけボタンやラベルが表示されるようにしている．また，スクロール可能であることがわかるように，遷移してすぐにスクロールバーを一瞬表示させる仕様にし，ユーザがスクロールできるとわかるように工夫した．import は UIKit のみである．

図 5.11

機能仕様書（※文責: 涌井春那）

Group Report of 2022 SISP

- 47 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

5.6.5

詳細画面

機能と概要
一覧画面の希望する出発時間と到着時間を押した後に遷移する画面だ．ここでは，乗換回
数，運賃，所要時間，出発時間と到着時間，出発バス停名，到着バス停名，系統，行き先，
その区間ごとの料金，いくつ前のバス停を出発したかが共通で見ることができる．乗換がある場合のみ，乗換時間と，乗り換えるときの降り場と乗り場が載っている．
何が嬉しいか
今まで，いくつ前のバス停を出発したか？の情報は，函館バスロケーションシステム（以下，
バスロケ）から，もしくは亀田支所などでしか見ることができなかった．しかし，このアプリでも見ることができ，しかもこのアプリはバスロケにはなかった未来のバスの時間なども調べることができる．UI も改善したため，とても使いやすいものになっているだろう．
実装できていること・できなかったこと
料金以外の情報はきちんと表示されている．料金については，バックエンドの GTFS-JP の内容になってくるが，フロントエンドの部分はほぼ完成といっていいだろう．いくつ前のバス停を出発したか？の情報については，Firebase の関係で，まだ不具合などが起こる場合が多いため，それが改善されれば，使用できるものになるだろう．
どのように実装したかや意識したこと
前の画面で検索した情報のものに対応した情報を GTFS-JP のファイルから関数を作って，そこから取ってきてユーザが確認する画面に表示させている．いくつ前のバス停を出発したか？の情報については，GTFS-RT のデータを Firebase に格納し，Swift で取ってきて表示するようにしている．また，Storyboard や ViewController を，乗換ありなしで変更することなく，条件で分けることにより，1 つの Storyboard と ViewController で実現している．
実装するにあたって，UIKit はもちろん，Firebase を Xcode・Swift で使えるようにライブ
ラリのインポートをした．

Group Report of 2022 SISP

- 48 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

図 5.12

機能仕様書（※文責: 涌井春那）

5.7

使用した技術本チームでは，3 つの技術を使用してプロダクトを作成した．以下で技術の詳細について述べる．
（※文責: 高野希澄）

5.7.1

Swift

Swift は，Mac，iPhone，iPad のアプリケーション開発に特化したオープンソースのプログラ
ミング言語である．2014 年に発表され，翌年 2015 年には GitHub 上でオープンソースとして公開されている．基本的には 5.9.1 節で詳細を述べる「Xcode」を用いてアプリケーション開発を行う．ばすうぃふとでは，GTFS-JP から取得したバス停情報，経路情報，時刻情報などの静的デー
タと Firebase から取得した運行情報である動的データを Swiht によって処理を行い，機能の実装を行った．
（※文責: 高野希澄）

Group Report of 2022 SISP

- 49 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

5.7.2

Firebase

Firebase とは，2011 年に Firebase 社がサービスを開始したスマートフォンアプリや Web アプ
リケーションにおけるバックエンド開発で活用できるプラットフォームであり，mBaaS の一つである．2014 年には，Google 社によって買収された．もともと，バックエンド環境をクラウド上で行えるサービスのことを BaaS とよぶ．ここに携帯端末向けを表す「Mobile」の「m」を足し合わせたものが mBaaS であり，mBaaS と BaaS は基本的には同じ意味である．Firebase の最大の特徴は，リアルタイム同期型のデータベースを使用できる点にあり，アナリティクスやデータベース，
クラウドメッセージング，クラッシュレポートなどの複数の機能が提供されている．ばすうぃふとでは，クラウドホスト型 NoSQL データベースである Firebase Realtime Database を使用した．

Python によって処理されたバスの運行情報に関するデータをこのデータベースに格納し，Swift側から問い合わせがあったときは，運行情報をアプリ側に渡す処理を行った．
（※文責: 高野希澄）

5.7.3

PythonPython とは，1991 年にオランダ人のグイド・ヴァンロッサムというプログラマーによって開発され，オープンソースで運用されているプログラミング言語である．Python は，豊富なライ
ブラリが存在するという特徴を持っており，サーバーサイド開発，システム管理，IoT など，幅広い分野で使用されている．ばすうぃふとでは，バイナリファイルである GTFS-RT をデシリア
ライズして，バスの運行情報に関するデータを JSON 形式で Firebase に格納する処理を行った．

GTFS-RT はリアルタイムに更新される動的データであるため，Python を定期実行することでFirebase 上のデータが定期更新されるようにした．
（※文責: 高野希澄）

5.8

使用したデータ

5.8.1

GTFS-JP

GTFS-JP は「標準的なバス情報フォーマット」における静的データフォーマットであり，国際的に広く利用されている公共交通用データフォーマット「GTFS」を基本に，日本の状況を踏まえた内容としている [13]．データ形式はテキストであり，経路検索に必要な時刻表や運行経路等のデータを含んでいる．本開発では，テキスト形式から JSON 形式に変換し，Swift で扱った．
（※文責: 似鳥亜美）

5.8.2

GTFS-RT

GTFS-RT は，公共交通機関がアプリケーション開発者に車両情報をリアルタイム提供できるよ
うにするためのフィード仕様であり，GTFS の拡張仕様で，公共交通機関の時刻表や関連する地理情報のオープンデータ形式である．GTFS-RT のデータ変換フォーマットは，プロトコルバッファGroup Report of 2022 SISP

- 50 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022をベースにしており，本開発では Python でデシリアライズを行ったのちに Swift で扱った．
（※文責: 高野希澄）
図解

図 5.13

5.9

使用したツール

5.9.1

Xcode

アプリで使用したデータの図解

Xcode とは，Apple 社が開発，リリースを行っている Mac や iPhone，iPad 向けのアプリケー
ションの開発に特化した開発ツールである．また，ファイルの管理からコンパイル，ビルド，実証
実験，デバックまでのアプリケーション開発の一連の流れをサポートしているため，統合開発環境(IDE) とも呼ばれている．ばすうぃふとにおけるアプリケーション開発で Swift と併用した．
（※文責: 高野希澄）

5.9.2

Git・GitHub

Git は，プログラムのソースコードなどの変更履歴を記録・追跡できる，分散型バージョン管理システムである．Git を使用することで，複数人で作業するとき，他の人に上書きされることやデータがバッティングすることなく編集が可能である．また，過去の履歴のデータにアクセスする
ことや復元を行うことが可能である点や最新のデータがどれなのかがすぐにわかるなどの利点がある．しかし，Git はローカルで動かすツールであり，Git のみではオンラインでの複数人による作業ができない．ここで必要になるのが GitHub である．GitHub は，オンラインでメンバ全員がデータを共有できる場 (リモートリポジトリ) を提供している Git を利用した Web サービスである．本開発では，作成したソースコードの管理を Git・GitHub を利用して行い，拡張機能である

ZenHub も用いてタスク管理を行った．ZenHub については 5.9.3 節で述べる．
（※文責: 高野希澄）

Group Report of 2022 SISP

- 51 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

5.9.3

ZenHub

ZenHub は，タスク管理ツールである GitHub にカンバン機能を追加する拡張サービスである．
カンバン機能とは，タスクの進捗を可視化する手法の一つである．本開発では，作業中のタスク，
レビュー待ちのタスク，完了したタスクといったタスクの進捗管理の他にもプロダクトバックロ
グ，スプリントバックログなどの管理も ZenHub を活用して行った．また，タスクの担当者の割り当てや工数の見積もりを行うためのプランニングポーカーの際にも使用した．
（※文責: 高野希澄）

5.9.4

Figma

Figma とは，ブラウザ上で簡単にデザインができるツールである．複数人での編集や閲覧が可能であるため，本開発でも使うことにした．本開発では，画面デザインを行う際やプロトタイプを作成する際に使用した．
（※文責: 高野希澄）

5.9.5

Miro

Miro は、複数人で閲覧や編集ができるオンラインホワイトボードツールである．プロダクト考
案時は，意見をまとめる場として活用し，開発に入ってからは，このツールを使用してレトロスペ
クティブを行った．付箋の色ごとにメンバを割り当て，どの付箋が誰の意見なのかがわかるようにしながら使用した．
（※文責: 高野希澄）

5.9.6

Slack

グループ内での連絡手段として，コミュニケーションツール，Slack を利用した．ワークスペー
ス自体はすうぃふと 2022 のものを利用していたが，グループごとにチャンネルを構築し，他のグループの活動も見られるようになっていたため，他のグループの進捗状況などを確認することもできた．そのためグループ内だけでなく，プロジェクト全体でのコミュニケーションを行うことができた．グループでのチャンネルでは，グループ内の進捗状況やアジェンダ，リアルタイムでなくても済む活動内容の確認などを中心に行った．また，文章に対して絵文字をつけることのできる「リアクション」という機能を利用し，発言に対する反応を見ることで，チャットでの意思疎通を図ることができた．さらに，文章を投稿する際に，カスタムメンションという機能を利用し，交通メン
バーだけに確実に通知がいくように工夫した．カスタムメンションを利用することで，交通メン
バーとチャットでの意思疎通がしやすくなった．
（※文責: 高野希澄）

Group Report of 2022 SISP

- 52 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

5.9.7

Discord

グループで活動する際，Discord をボイスチャットツールとして利用した．グループでの簡易的な確認は，Slack を主に使用していたが，誰が確認しているかはすぐにわからないため，急ぎの確認や話し合いには不向きであった．そのため，リアルタイムで話し合いのできるツールとしてDiscord を利用した．
（※文責: 高野希澄）

5.9.8

Google Drive

Google ドキュメント，Google スプレッドシートや Google スライドのファイルを保存して共有したり，写真を保存したりする場として活用した．Google ドキュメントは，主に議事録を作成する際に利用した．また，それぞれが考えてきた案をまとめる際には，メンバーが一つの資料に共同で書き込むことができ，議論をスムーズに行うことができた． Google ドキュメント，Google ス
プレッドシートや Google スライドは，複数人での編集が容易にでき，誰が見ているかも確認ができたため，スムーズな編集を行うことができた．
（※文責: 高野希澄）

Group Report of 2022 SISP

- 53 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

第6章
6.1

今後の展望

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

本グループでは，成果発表会の質疑応答と評価フォームを基に，プロダクト改善を検討している．また成果発表会までに終わらなかった機能の開発も進めていく．
（※文責: 似鳥亜美）

6.2

フィードバックを基に改善しようとしていること

4.5.3 節のフィードバックより，詳細画面のスクロール上の固定部分に影をつけるデザインにすることを改善する．また検索に時間がかかる点を改善していく．またバス停がいくつ前を出発した
かの表示を現在の黒いテキストでの表示から変更すること，バスの現在位置が地図上で見ることができるようにすることは検討することにした．
（※文責: 似鳥亜美）

6.3

函館バスでいただいたフィードバックを基に改善しようとしていること

4.8.1 節のフィードバックより，検索スピードや乗り換えの正確さを改善していく．また乗り場
を名前ではなく番号に統一することも検討する．その他提案していただいた機能についても，より良いアプリを目指すためグループで話し合い検討していく（※文責: 似鳥亜美）

Group Report of 2022 SISP

- 54 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

第 7 章 学び
7.1

高野希澄

今回の行ったプロジェクト学習では，前半はグループリーダー，後半はスクラムマスターとして活動してきた．活動の中で最も困難に感じた点は，コミュニケーションの難しさだった．そして，
コミュニケーションの重要さを学んだ．まず，モチベーションやゴールはそれぞれ異なり，その違いをはっきりさせておかないことがグループの歪みにつながってしまったことが前半であった．足並みをそろえて開発を行うために，メンバ全員とのコミュニケーションが足りなかったことに気が付き，メンバとの話し合いの場を設け，UX デザインの手法も調べて話し合いに取り入れた．それが功を奏したのかは正直分からないが，メンバとの話し合いは重要だったように思う．本音がわかったことがお互いの理解につながり，以前ほどのストレスをメンバが感じないようになったためだ．実際に開発に入ってもコミュニケーションというのは切っても切り離すことはできなかった．
それぞれが異なる作業を行っているため，どのくらいの進度で進んでいるのか，問題は発生していないかが，本人に聞かないとはっきりしなかったためだ．そして，そこをはっきりとさせないと自分の作業に入れないこともあった．また，他人の作業を引き継ぐような形で作業が始まることもあった．そのため，まめに連絡を取って確認を行うことが重要であった．活動をしていくなかで，コーディングももちろん重要であったが，それ以上にコミュニケーションが活動の大多数を占めていたように感じる．私は，いままで個人で課題をこなすことや短期間の中で他の人と作業を行うことは多くあったが，長期間を使ったチーム開発は人生で初めて出会った．今回は，コミュニケー
ションの重要さを多く感じる機会であったし，自分のコミュニケーションの失敗を実感することも多かった．チーム開発を行う際には，今回の経験を糧にして，よりよいエンジニアとして活動できるように精進したいと感じた．
（※文責: 高野希澄）

7.2

涌井春那

1 年を通して，課題発見から，アプリ開発・発表，まで行うことの中で，様々なことを学ぶことができた．私たちは，函館市の交通に興味のあるメンバで集まった．そのため，まず交通の問題をあげていくところから始めた．そこで，たくさん問題をあげていたが，どのような問題をどのように解決していくか，の議論についてとても行き詰まってしまった．その際，先生にフィールドワークに行って実際に見てみたほうがよい，とアドバイスを頂き，Google マップや函館バスロケーショ
ンシステムなどのバス検索アプリを利用して，函館バスと市電を利用して函館駅まで行くというフィールドワークに行った．ここで学んだことは，自分たちで議論する中で上がってくる問題には限度がある，百聞は一見に如かずということだ．実際にフィールドワークに行ってみて，様々なバスアプリを利用してみると，議論をする中では出てこなかったような問題がたくさん上がった．もちろん，議論をすることもとても大切だと思うが，実際に行ってみないとわからないこともたくさんあり，フィールドワークの重要性を学ぶことができた．フィールドワーク講習ではピンと来ていなかったことも，実際に行ってみることで学ぶことができたため，とても良い学び・経験になっGroup Report of 2022 SISP

- 55 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
た．次に，機能などのブラッシュアップについてだ．バスの検索アプリを作るにあたって，私たちが詰まったのは，他のバスの検索アプリとの差別化だ．バスの検索は，NAVITIME や Yahoo!乗換案内，函館バスロケーションシステムや Google Map など，様々なアプリ・サイトによって行うことができる．中間発表時点では，なかなかこれらとの差別化が出来ず，苦労した．そのため，中間発表の際の Google フォームでのアンケート・実際の質疑応答では，他のアプリと比べた優位性がわからない，差別化ができていないなどといった声をたくさん頂いた．最終的に一覧で検索結果を見ることができること・函館バスロケーションシステムのように，今のバスの位置情報をみることができることによって，差別化を図ることができた．ただ，この話し合いの中で，差別化したいのになかなか案が決まらず，メンバの中での認識の差異などもあった．そのため，認識の一致なども，重要なポイントだと学んだ．私は，議事録担当だったため，議事録だけでなく，「なんでもシート」というドキュメントを提案し，誰でも書き込めるホワイトボードのようなものを利用することによって，言語化ができ，メンバ間での認識の一致ができたと思う．次に，実際に開発が始まった
時のスプリントを回す際の GitHub でのレビューについてだ．最初の頃はなかなかレビューがすぐに来ず，スプリントをスムーズに回すことがあまりできなかった．しかし，スプリントの中で行うレトロスペクティブによって，Miro を用いてしっかり反省などをしたため，どんどん改善していったので，とても良かったと思う．これで学んだことは，スプリントは最初はなかなかうまく回すことができないということだ．このときしっかりとコミュニケーションをとって，メンバと協力していき，改善していくが重要であると学んだ．次に，Xcode や Swift を始めとした技術の習得である．1 年生〜今まで，プログラミングをはじめとした技術を学んできたが，課題のためにやっている感じが自分の中でしていて，受け身だった．今回は主体的に取り組むことが出来たと思っていて，そのため，技術もしっかり習得できたのではないかなと思っている．今後の卒業研究も，主体的に取り組み，新しい技術を習得したり，今まで習得してきた技術を応用していきたいなと思う．
最後に，私は，1,2 年から今まで，大学でプログラミングや数学系科目，認知心理学，コンピュータ
サイエンスの基礎をたくさん学んできた．しかしどれも，グループで行うものは少なかったし，1年という長い期間行うものはプロジェクト学習が初めてだった．このプロジェクト学習を通して，

1,2 年ではあまり学べなかった様々なことを学び，身につけることができたと思う．
（※文責: 涌井春那）

7.3

池端麦

プロジェクト学習を通して，学んだことをは大きく二つある．一つ目は，課題解決についてである．このプロジェクトは，実際にフィールドに行き，そこから課題を見つけ，その課題について，
どのようにアプローチすれば課題が解決されるのかということに取り組んだ．その中で，様々な方法で，課題解決のためにアプローチしてきた．例えば，ターゲットユーザを定めたり，さらに詳しいペルソナを立てた．それに伴い，バリュープロポジションキャンバスを作成し，ペルソナにとって，提供するサービスがどのような問題を解決できるか考えた．これらを考えるに至るまでにも，どのような方法でアプローチするか考えたり，調べたりするのが大変だった．課題解決のための，機能を考えても，それが実際にペルソナにとって必要なものであるか，また，本当に課題は解決されるのか，など大変であった．さらに，私は，グループのデザインを担当することになったため，デザインの勉強も行った．このユーザにとって，使いやすいデザインとは何か，機能を使ってもらうために，わかりやすいデザインは何か，変更を繰り返しながら，デザインを考えた．これまで

Group Report of 2022 SISP

- 56 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
も，授業で何かを作成するということはあったが，プロジェクト学習のように，誰か人のためにということに重きを置いて考えることはなかったため，今回のような経験はとても貴重だった．
二つ目は，グループで活動することの大変さである．このプロジェクト学習で初めて話す人ばかりだったため，最初は自分自身の意見を発信することが難しく，意見を抑えることが多かったが，少し経つと，次は，自分の意見と，周りの意見が合わないということに悩まされた．1 人でやっている活動でないため，自分の意見が必ず通るというわけではないということは，十分理解しているはずではあるが，話し合いをしていても，「どうしてわかってくれないんだろ？」と思うことが多くあった．私自身の言語化能力が乏しかったこともあり，ホワイトボードなどに図解をして説明する
ことによって，言葉以外の手段を使うことによって，人に伝わりやすくなるということを学んだ．
また，相手の意見を聞いて，それを自分自身の中で理解する時，最初から 100 ％理解することはできないということを学んだ．何かしらの認識のずれが発生するため，再度確認することが重要である．この「認識のずれ」というものは，最初の頃は頻繁に起こっていたが，だんだんと活動していくうちに，自然と確認しあっていたため，少なくなっていったが，アプリの機能がある程度固まっていた頃に，大変な「認識のずれ」が起こった．それは，その機能について話し合った場にいなかった人に，変更点が伝わっていなかった，また，変更を繰り返し行なっていたため，何が最新の変更なのか，グループで認識がずれていた．この認識のずれは，最新の変更がされたものが，きちんとまとめられていなかったことが原因だと考えられた．グループ全員の認識を合わせるために，重要なのは，逐一意見の確認をすることと，最新の話し合った結果を記載しているところを全員がわかっていることが重要だと思った．
（※文責: 池端麦）

7.4

似鳥亜美

本グループで行ってきたフィールドワークや話し合い，アプリ開発を通して様々なことを学んだ．まずは，自分が思う相手の求めるものと実際に相手が求めているものは同じではないということだ．実際の活動でも，バスに関する課題を検索していく中でバスの利用者が感じる課題をなんとなく予想していたが，実際フィールドワークでバスを利用すると，予想していたものと違う課題を発見した．そこから相手の目線になったつもりでも，相手が実際に求めているものかどうか分からないということを実感した．またアプリを誰かに使ってもらった時に，相手から予想していなかったことを指摘され改善したことから，相手の立場に考えて終わりではなく，相手に実際に使ってもらうことが大切だと実感した．次にグループ開発を学んだ．話し合いで意見を言う際，自分の言ったことが相手に伝わっていると思っても伝わっていないということがあった．相手に理解してもらえるように伝えることの難しさを感じた．しかしグループで話し合いをする分，意見が多様になる
ことで，自分の凝り固まった考えに気づくことができたり，自分が知らないことをメンバから教えてくれたおかげでアプリを作成することができたりと，個人開発にはないグループ開発の利点を実感することができた．最後に計画通りに作業を進めることの難しさを学んだ．本プロジェクトはメ
ンバ全員が初めて取り組む内容なので常に計画の見通しが立てづらい状況だった．またアプリ開発
では初めて使用する言語だったため計画を立てても計画通りに進めることができる可能性が低い状況でもあった．そのためプロジェクト学習は授業として扱われているのにも関わらず，授業以外の時間をたくさん使って開発することになった．授業時間外にもプロジェクト学習の活動を行うことが当たり前になってくると時間内に仕上げるという意識が薄れて，結果授業時間をおろそかにしてGroup Report of 2022 SISP

- 57 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022
しまうことがあった．また夏季休暇中はメンバそれぞれが言語習得をする期間の予定だったがアプリの要件定義にとても時間がかかってしまったため，言語取得期間をとることができなく，開発すると同時に言語を習得していくことになった．そこから限られた時間の中で計画通りに作業を進めることの難しさを実感した．
（※文責: 似鳥亜美）

7.5

児玉拓海

私はプロジェクト学習を通して，チーム開発，開発プロセス，プログラミング技術の 3 点で大きく成長できたと感じる．私は将来，システムエンジニアを目指しており，プロジェクト学習では将来必ず役に立つ経験を積むことができたと思う．アジャイル開発の一種であるスクラム手法の導入により，スクラムについても勉強することができた．プロジェクト学習を通して，最も難しかったのはチームメンバとのコミュニケーションだった．認識の違いや，情報共有が上手くいかなくて，活動が円滑に進まない場面が何度もあった．この経験から，チームで協力しながら活動できるような状況を作っていくために日常的なコミュニケーションを行うことが重要であると感じた．前期の活動を振り返って，反省点，改善点を発見することで夏季休暇中の活動では，効果的な成果を得られるような活動ができたと思う．定期的なミーティングを実施し，意見や要求を共有，開発プロダ
クトの機能仕様，実装機能の検討は，将来の会社でも役立てることができる経験だった．スクラム開発では，開始時に難しいと感じていたことも少しずつ習慣化され，効率的に開発を進められたと思う．しかし，週末のデイリースクラムを忘れることが何度もあったことが反省点である．アプリ
ケーション開発の作業が始まってからは，デザイナーとエンジニアの両方の仕事を行う場面があった．今までは UI や配色，機能操作についてあまり考えてこなかったが，これらを考えることでデザイナーの視点を持つことができ，エンジニアの視点と合わせることで，よりよい機能の提案ができるようになったと思う．実装作業は，Swift のプログラミングスキルの成長に大きく繋がりました．学外の活動で勉強してきた言語ではあったが，メンバとの技術的な情報共有は興味深く，良い経験になった．これからも自分で Swift やアプリケーション開発の学習を継続していこうと思う．
また，私は本プロジェクトのプロジェクトリーダーとしても活動してきて，プロジェクトを円滑に進めていくことの難しさを実感した．コミュニケーションミスや，効率的に活動時間を使えない場
面があり，プロジェクトメンバにも迷惑をかけることが多くなってしまった．しかし，プロジェク
トメンバ，先輩方，指導教員のサポートのおかげで，最後までプロジェクトリーダとして活動することができた．プロジェクト学習の貢献してくれた人たちに感謝している．
（※文責: 児玉拓海）Group Report of 2022 SISP

- 58 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

第 8 章 まとめ本グループは，函館地域のバスを使いやすくすることを目的としてバス経路検索アプリ「ばすうぃふと」の開発に取り組んだ．交通支援グループとしての活動を始めた当初は，函館地域の交通の問題を挙げていくブレインストーミングから始めた．結果，函館地域のバスの使いにくさに関する問題が多く挙がったため，実際にフィールドワークに行って問題を確かめることにした．フィー
ルドワークを行った後は，タイムラインやユーザモデリングの作成を通して，フィールドワークで見つけた問題の整理・分析を行った．その結果，既存のバスアプリやマップアプリは情報の表示や表現に問題があるという結論に至った．そこで私たちは，既存のバスアプリの情報表示・表現のわ
かりにくさに焦点を当て，函館地域のバスを使いやすくするためのアプリ開発を行うことにした．
夏季休暇中は，プロダクトの詳細についての話し合いをグループの活動として行い，Swift の技術習得を個人の活動として行った．プロダクトの詳細を決めるために，類似アプリの調査や機能の選定，機能仕様書の作成などを行った．また，データの提供をしていただいた函館バス株式会社への訪問準備も夏季休暇中に行った．訪問準備として，活動内容を紹介するためのスライド作成や開発アプリのイメージをつかんでもらいやすくするためのプロトタイプの作成を行った．
後期は，函館バス株式会社への訪問から始まった．結果，GTFS-JP と GTFS-RT のデータを提供していただくことに成功した．また，開発アプリについての意見をいただくこともできた．考案
していた機能に対して良い評価をいただいたり，機能に対しての改善案・提案をいただくことができた．函館バス株式会社の訪問の振り返りが終わった後は，本格的な開発を始めた．スクラム開発に慣れることを目的としたスプリント 0 の実施もここで行った．成果発表会までに第 6 スプリン
トまで回して開発に取り組み，第 6 スプリントを除いたすべてのスプリントで担当教員によるレビューを行った．レビューでいただいた意見をグループで話し合い，検討を重ねたうえでプロダクトの開発に取り組んだ．
本グループは，大学での成果発表会のほかにも 11 月 10 日から 12 月 4 日の期間で開催された

HAKODATE アカデミックリンク 2022 や 12 月 10 日に開催された enPiT2BizSysD 北海道・東北合同発表会に参加して発表を行った．enPiT2BizSysD 北海道・東北合同発表会では，プロダク
トに対して高い評価をいただき，最優秀賞に選ばれる結果となった．
（※文責: 高野希澄）

Group Report of 2022 SISP

- 59 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

第9章

今後の予定

9.1

課外成果発表会への参加

9.1.1

秋葉原成果発表会

本グループは，2023 年 2 月 14 日に秋葉原で行われる公立はこだて未来大学主催のプロジェクト
学習成果発表会・企業交流会に参加する予定である．各グループ個別の参加ではなくプロジェクト
全体での参加となり，一年間プロジェクト学習で行ってきた活動についてポスターセッション形式
で発表を行う．この発表会には企業の方が多数来場するため，事業者視点からのフィードバックを多くいただくことを期待している．
（※文責: 似鳥亜美）

9.1.2

enPiT BizSysD 分野ワークショップ

本グループは，2023 年 2 月 21 日に岩手県立大学で行われる enPitBizSysD 分野ワークショップに参加を検討している．対面とオンライン (Zoom) の併用によるハイフレックス開催で，ポスター
セッションかプレゼンまたは聴講で一年間プロジェクト学習で行ってきた活動について各グループ発表を行う．他大学の生徒や教員方が参加するため，他大学の発表から知識を得たり，他大学の学
生視点の意見をいただくことができると考える．
（※文責: 似鳥亜美）

9.1.3

Agile PBL 祭り

2023 年 3 月 20 日に名古屋市で行われる Agile PBL 祭りについても参加を検討している．会場にはたくさんの企業が来場するため，企業の方を含めた多くの方から本グループの取り組みに対してのフィードバックを得られる機会になると考えている．
（※文責: 似鳥亜美）

Group Report of 2022 SISP

- 60 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

付録 A

アカデミックリンクスライド

函館市
函館地域

交通について議論

バスを利用しやすくするアプリ

すうぃふと
すうぃふと
公立

挙げられた問題
多くがバス関連

こだて未来大学 すうぃふと2022※オレンジがバス関連

交通支援グループ

バス利用

フィールドワーク

調べる時に多く 問題

調べる時

調べる時＝バス

・複数 アプリやブラウザを使う必要がある
・行きたい場所 分かっている に、停留所 名前がわからない・アプリでバスを調べても、時刻 情報 2本先しか表示されないが、そ 系統や料金など 詳細情報 たくさん表示される

検索

検索

問題 ・アプリで最初何を押せ 良いかわからないも がある
・検索結果 情報量が多すぎる

乗車時・停留所サイネージが「あと5分で到着」から「もうすぐ到着」
変わっても、すぐにバスが到着しない

既存

検索アプリ

表示

情報

比較

アプリ

Googleマップ*1

××

リアルタイム情報
日時指定

・提供する情報*2 ナビタイム https://www.navitime.co.jp

maps

×

*3 バスロケーションシステム
https://hakobus.bus-navigation.jp › wgsys › wgs ›route

優れた点を取り入れたバスアプリへ

Group Report of 2022 SISP

函館地域

バス

み

→情報量を削減

停留所お気に入り登録*1 Googleマップ https://www.google.com ›概要

バスロケーションシステム*3

ナビタイム*2

地図から 入力

量、表示や表現に問題が多い

・使いやすさを意識した画面
→情報

・既存
→複数

- 61 -

表示や表現

デザイン

問題を解決

検索アプリ

優れた機能を取り入れているアプリを使用せずに情報入手を可能にするGroup Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

想定ユーザ

ペルソナ

・普段あまりバスに乗らない
バス

検索に慣れていない人にとっても使いやすいも を目指すため

・タップ、スクロールなど スマートフォン操作が可能
高齢者も含めスマートフォン

基本操作ができる人が増えているため基本的な使い方

主要な機能①始発〜終発まで

時刻一覧②マップから停留所を選択③バス
必要な項目を入力し検索をタップ

バス 一覧を閲覧し詳細を見たい便をタップ

機能：①始発〜終発まで

時刻一覧

問題：時刻 情報 2本先しか表示されないが、系統や料金など 詳細情報 たくさん表示される

時刻と乗り換え回数

リアルタイム情報

タップしたバス
詳細を閲覧

機能：②マップから停留所を選択
問題：行きたい場所がわからないみ表示

分かっている

マップ上で停留所

に、停留所

名前

位置を表示

始発〜終発まで表示

時刻 情報を確認しやすくする
時刻を指定して調べなおす手間を省く

Group Report of 2022 SISP

停留所名 検索しなくても停留所 選択ができるようにする- 62 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

機能：③いくつ前

停留所を出発した情報

今後

予定

現在 ・機能問題：「あと5分で到着」から「もうすぐ到着」 表示に変わっても、すぐにバスが到着しなかった

実装

12月 ・最終成果発表会（学内）「約何分に到着」 予想で なく「いくつ前 バス停を出発した」という
事実 リアルタイム情報を表示

ユーザテスト可能なプロトタイプ完成

・ユーザテスト
普段あまりバスに乗らない函館市民に使用してもらう

バス

停留所で待つ時
位置を把握しやすくする

1月 ・改良ユーザテストまとめ
・函館

結果を踏まえて改良する

謝辞
バスに関する問題に注目

・バス利用

フィールドワークを実施

本開発を行うにあたりGTFS-JP、GTFS-RT
データを提供していただいきました
函館バス様に深く感謝致します。

・特にバス 路線や時刻を調べる段階
情報 量、表示や表現 問題を発見
・これら 問題を解決しバスをもっと利用しやすくする
アプリ「 すうぃふと」を考案、現在開発中

図 A.1

Group Report of 2022 SISP

アカデミックリンクスライド- 63 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

Group Report of 2022 SISP

- 64 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

付録 B

グループポスター[ 使ってもらって学ぶフィールド指向システムデザイン 2022]

函館バスの利用をサポートする
交通支援グループ

スクラムマスター

高野希澄

プロダクトオーナー

池端麦

涌井春那

似鳥亜美

児玉拓海

背景
函館市の交通問題についての話しあい

実地調査

函館市のバスについての課題が多くあがった

アプリ、ブラウザで検索

その課題の原因を探るために実地調査へ

函館市内のバスに乗る
タイムライン上に感じたことをアウトプット

オレンジ：バスについて
水色：その他

実地調査の考察
アプリやブラウザでバスを調べる時

・停留所サイネージが「もうすぐ到着」に変わっても、・アプリでバスを調べるが、時刻の情報は 2、3 本先しか表示されないがすぐにバスが到着しない
・履歴が残らないアプリだと、再度入力して検索し直す手間がある

その系統や料金などの詳細情報はたくさん表示される・複数のアプリやブラウザを使う必要がある

・行きたい場所は分かるが、停留所の名前がわからないことがある

スマホをよく使う人以外でも使いこなせるアプリへ ...

コンセプトの考案
既存アプリの調査

ターゲットユーザーのペルソナ作成

佐藤日葵
生活

性別

女性

住まい

函館在住 6 年（札幌から引越してきた）

年齢

53

職業

家族構成

夫 (54)、息子 (17)、一人暮らしの娘 (20)

趣味

手芸（ワークショップで出店をする）

パート（スーパーマーケット）

Google マップ

ナビタイム

バスロケーションシステム

地図からの入力
リアルタイム情報一覧表示

週 3 でパート、趣味のワークショップに月 1 回参加。手芸の買い出しに、月 1 回程度行く。

どういう時に頻繁には利用しないが、趣味の手芸のワークショップ（さまざまな場所で行っている）やバスを利用するか 買い出し（基本的に同じ場所）などで、五稜郭や函館駅方面へ行く時に利用する。

停留所お気に入り登録

結果

結果• 地図からバス停を選択できると、バス停名がわからなくても検索できるとよい• 老眼でも認識しやすいように、文字間隔や大きさに注目• 指定区間の時刻を一覧で表示されるアプリはない• 複雑なスマホの操作ではなく、簡単な操作にする• リアルタイムでどこをバスが走行しているかわかると便利• 誤タップを防ぐための工夫• お気に入り機能があると調べ直す手間を省ける

始発〜終発の時刻を一覧表示

地図から停留所を選択指定した区間を走行する
バスの時刻が始発〜終発を全て表示

行きたい場所の近くのバス停名がわからない

いくつ前の停留所を通過したかの表示
何分後に到着という情報
現在走行している場所から算出

建物名からバス停を検索できる

時刻を指定したり調べ直す手間を省いた

遅れが生じていることによりだんだんその時間が伸びてしまう

２箇所の停留所を選択されれば
乗り換え回数を表示

いくつ前のバス停を出発
乗換：1~2 回

乗換 1~2 回遅れが生じてもいくつ前という情報は変わらない

本開発を行うにあたり、GTFS-JP、GTFS-RT データを提供していただいた
函館バス株式会社に深く感謝いたします。

図 B.1

Group Report of 2022 SISP

発表会で使用したグループポスター- 65 -

Group Number 1-A

Field Oriented System Design Learning by Users’ Feedback 2022

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

[2] 函館市，交通網再編の検討に係る中間報告．https://www.city.hakodate.hokkaido.jp/
docs/2020071700010/files/2020_2_siryou3.pdf (2022/7/18)[3] enPiT e-Learning 学習用 Web サイト，プロジェクト学習のためのプロジェクトマネジメン
トの基礎．https://enpit2.widebook.net/ (2022/7/16)[4] 株式会社インターリスク総研，リスクマネジメント入門．https://www.ms-ins.com/pdf/
business/rm/rmguide.pdf (2022/07/15)[5] Codefor

Hakodate，Codefor

Hakodate．https://www.codeforhakodate.org/(2022/07/20)[6] 南部美砂子，フィールドワーク入門講座

for PBL．https://drive.google.com/file/d/1H6-Iepfufk80NmRY0DlYInMgRa-5zOrA/view (2022/7/17)[7] 永瀬美穂，スクラムワークショップ 2022．https://hope.fun.ac.jp/pluginfile.php/
108520/mod_resource/content/1/%E3%82%A2%E3%82%B7%E3%82%99%E3%83%A3%E3%82%
A4%E3%83%AB%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%EF%BC%88%E3%82%B9%E3%82%
AF%E3%83%A9%E3%83%A0%E9%96%8B%E7%99%BA%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%
B7%E3%83%A7%E3%83%83%E3%83%95%E3%82%9A%EF%BC%892022.pdf (2022/7/19)[8] 文部科学省，enPiT． https://www.enpit.jp/ (2022/12/26)[9] 第一弾「函館カラーを見つけよう！！」結果報告，PRTIMES．https://www.enpit.jp/(2022/12/26)[10] はこだて高等教育機関合同研究発表会 HAKODATE アカデミックリンク 2022，キャンパ
ス・コンソーシアム函館．https://www.cc-hakodate.jp/academiclink-web/

(2023

/1/8)
[11] プロトタイプはなぜ必要？システム開発における目的とは，発注ラウンジ．https://hnavi.
co.jp/knowledge/blog/prototype/ （2022/12/29）[12] スマートフォン・PC で読みやすいフォントサイズ &行間とは？国内のメディアサイト
を調べてみた，株式会社アーティス．https://www.asobou.co.jp/blog/web/fontsize(2023/1/1)[13] 国土交通省, 静的バス情報フォーマット (GTFS-JP) 仕様書 [第 3 版]．https://www.mlit.
go.jp/sogoseisaku/transport/content/001419163.pdf (2023.1.8)

Group Report of 2022 SISP

- 66 -

Group Number 1-A