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

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

Project Name
Field Oriented System Design Learning by User’s Feedback 2020

グループ名グループ B

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

1-B

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

遠藤侍玄

グループリーダ/Group Leader
宮岡萌映

Moe Miyaoka

グループメンバ/Group Member
宮岡萌映

Moe Miyaoka

田中陽都

Haruto Tanaka

山本紋豊

Akito Yamamoto

吉兼刃矢

Jinya Yoshikane

荒戸大輝

Daiki Arato

指導教員
伊藤恵

南部美砂子

奥野拓

原田泰

AdvisorKei Ito Misako Nambu Taku Okuno Yasushi Harada

提出日
2021 年 1 月 14 日

Date of Submission
January 14, 2021

概要
本プロジェクトは， フィールド調査をもとに問題を発見し，IT(Information Technology) を用いてユーザーの仕事や生活をデザインすることを目的としている．また、本プロジェクト
は，スクラムと呼ばれるアジャイル開発手法の一種を用いる．それにより、高速で柔軟な開発を行い，短期間で最大限に成果を出すことを目標としている．今年度はプロジェクト内を高齢者支援のデザイン，地域交通のデザイン，地域情報のデザインの 3 グループに分け，各グルー
プが別のフィールドで活動している．本書では地域交通のデザインについて報告を行う．本グ
ループでは，函館バスをフィールドとしており，函館市の地域交通を IT で支援し，利用者のユーザー体験を向上させることを目的に活動を行った．前期は函館市のウェブサイトなどを利用したインターネット上の調査と私たちが実際にバスに乗り，バス車内やバス停，バス利用者の様子を観察するフィールドワークを実施した．そして，見つけた課題から利用者の乗車前・乗車中の少しの不安を解消するためのスマートフォンアプリケーションを開発することに決めた．夏季休業中は各自がアプリ開発のために必要な知識を習得し，後期が始まるとスクラムと共に開発がスタートした．
開発期間は 1 スプリントを 2 週間とした全部で 4 スプリント行い，スプリントごとに計画，開発，レビューを繰り返すことで効率的に進めた．開発の結果，バス停で行きたいバス停の表示がないという問題，バス停で運賃の情報が不足しているという問題を解決することができた．
今後は私たちのアプリケーションの強みである “優しい”，“新しい”，“早い”をより感じてもらえるデザインにする為，ユーザーテストを実施しながら開発を進めていく予定である．
キーワード

フィールド調査，アジャイル開発，IT，シビックテック，交通（※文責: 宮岡萌映）-i-Abstract
The purpose of this project is to discover problems based on ﬁeld surveys and to designusers’ work and life using IT (Information Technology). The purpose of this project is
to identify problems based on ﬁeld research and to design users’ work and life using IT(Information Technology). In addition, this project uses a kind of agile development
method called Scrum. The goal of this project is to achieve maximum results in a shortperiod of time through fast and ﬂexible development. This year, the project is divided
into three groups: elderly support design, local transportation design, and regional
information design, with each group working in a diﬀerent ﬁeld. In this paper, we reporton the design of regional transportation.The purpose of this group is to support the local
transportation system of Hakodate City with IT and to improve the user experience.
In the ﬁrst semester, we conducted internet-based research using the city’s website andﬁeldwork in which we actually rode the bus and observed the bus interior, bus stops,
and bus users. Based on the issues we found, we decided to develop a smartphone
application to alleviate some of the anxiety of bus users before and during the ride.
During the summer vacation, each of us acquired the necessary knowledge to develop
the application, and when the second semester started, we started the development with
Scrum.
The development period was four sprints, each of which lasted two weeks, and we
proceeded eﬃciently by repeating planning, development, and review for each sprint.As
a result of the development, we were able to solve the problem of the bus stop not
displaying the bus stop you want to go to and the problem of the bus stop lacking fare
information. We are planning to develop the application while conducting user tests inorder to make the design more “kind”, “new” and “fast”, which are the strengths of ourapplication.
KeywordField Surveys, Agile Development, IT, Civic Tech, Transportation（※文責: 宮岡萌映）- ii -

目次
第1章

背景と目的

1

1.1

地域交通グループの目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

シビックテックについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.3

函館市の公共交通機関について . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.4

函館バスについて. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

第2章

フィールド決定までの活動

2

2.1

函館市の抱える問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.2

Code for Hakodate のレクチャー . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.3

取り組むべき問題の決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2フィールド決定後の活動

3

第3章

3.1

函館の交通に関する問題調査. . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

3.2

対象の仮決定と問題解決案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

3.3

CfH 中村氏と交通問題解決案 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

3.4

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

4

3.4.1

函館バスの利用と調査 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

3.4.2

サービスの仮案. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

3.5.1

システムコンセプトの決定 . . . . . . . . . . . . . . . . . . . . . . . . . .

6

3.5.2

具体的な機能の提案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

3.5

3.6
第4章

サービス案の決定

夏季休業中の活動
開発サービス

9

4.1

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

94.2

開発済みの機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

4.2.1

バス停一覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

4.2.2

料金一覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

UI/UX の設計 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

4.3.1

3 つの価値の決定. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

4.3.2

“優しい

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

13

4.3.3

“新しい

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

15

4.3.4

“早い

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

15

4.4

データベースについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

4.5

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

16

4.5.1

ユーザビリティテストの実施 . . . . . . . . . . . . . . . . . . . . . . . .

16

4.5.2

実装途中の機能実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

4.5.3

機能面の改善・追加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

4.3

- iii -

第5章

5.1

5.2

5.3

5.4

5.5

第6章

開発が始まってからの活動

18

アジャイル開発について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

5.1.1

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

18

5.1.2

プロダクトバックログの作成 . . . . . . . . . . . . . . . . . . . . . . . .

18

5.1.3

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

19

5.1.4

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

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

19

5.2.1

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

19

5.2.2

スプリントでの成果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

5.2.3

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

20

5.2.4

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

20

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

21

5.3.1

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

21

5.3.2

スプリントでの成果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

5.3.3

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

21

5.3.4

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

22

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

22

5.4.1

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

22

5.4.2

スプリントでの成果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

5.4.3

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

23

5.4.4

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

23

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

24

5.5.1

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

24

5.5.2

スプリントでの成果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

5.5.3

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

25

5.5.4

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

26

中間発表

27

6.1

発表準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

6.2

発表についての評価と反省 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

アカデミックリンク28

7.1

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

7.2

スライドの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

7.3

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

28

7.3.1

フィードバックの内容 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

7.3.2

フィードバックに対する評価と反省 . . . . . . . . . . . . . . . . . . . . .

29

第7章

第8章

成果発表

30

8.1

発表準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

8.2

ポスターと動画の作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

8.3

レビュー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

8.3.1

30

レビューの内容. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
- iv -

8.3.2
第9章

レビューの評価と反省 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

知識・技術習得

32

9.1

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

32

9.2

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

32

9.3

アジャイル開発勉強会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

9.4

Git/GitHub 講習会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

9.5

開発言語の勉強 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

第 10 章 学び

35

10.1

宮岡萌映 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

10.2

田中陽都 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

10.3

山本紋豊 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

10.4

吉兼刃矢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

10.5

荒戸大輝 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

第 11 章 今後の活動

38

第 12 章 まとめ

39

付録 A

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

40

付録 B

成果発表のポスター

45
46

参考文献

-v-

Field Oriented System Design Learning by User’s Feedback 2020

第 1 章 背景と目的
1.1

地域交通グループの目的

本グループでは，我々が居住している函館という街の中で日々運行されている公共交通機関を対象として，シビックテックの考え方に基づき，規模を問わず地域交通が抱えている問題を，IT 技術によって解決することを目的として活動を行った．
（※文責: 田中陽都）

1.2

シビックテックについて

シビックテック (Civic Tech) とは，シビック (Civic， 市民) とテック (Tech， テクノロジー)
をかけ合わせた造語であり，地域の様々な問題を，当事者である市民自らがテクノロジーを用いて解決しようとする取り組みのことをいう [1]．シビックテックの細かい定義は決まっておらず，技術者のみならずそれに携わる人々も活動の参加者とする文献 [2] もある．函館市でも，Code for

Hakodate という市民団体が，「ICT を中心とした函館をちょっとよくするきっかけづくり」をコンセプトとして活動を行っている．
（※文責: 田中陽都）

1.3

函館市の公共交通機関について

函館市内・市外近郊には複数の公共交通機関がある．例えば，鉄道 (JR，道南いさりび鉄道)・新
幹線・路線バス (函館バス)・函館市電・飛行機・フェリーなどがある．このうち，鉄道路線，新幹線，飛行機，フェリーについては，函館市外からの旅行客やビジネス客の輸送，すなわち「都市間輸送」を主としている．一方，路線バスや函館市電は，市内の観光地へのアクセスに使われるのみ
ならず，地域内の住民の移動手段として，「地域輸送」の役割を担っている．
（※文責: 田中陽都）

1.4

函館バスについて

本グループでは，活動の対象とする交通機関を路線バス (函館バス) に決定した．その理由については第 3 章にて述べる．函館バス [3] は，北海道函館市を中心として渡島・檜山地方全域で路線バスを運行しているバス会社である．函館市を含む渡島・檜山地方の 2 市 15 町で運行している．
全線で交通系 IC カードが使用できるほか，バスロケーションシステム [4] が導入されており，ス
マートフォンやパソコンのブラウザからバスの位置情報や遅延時分を確認することができる．
（※文責: 田中陽都）

Group Report of 2020 SISP

-1-Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

第2章
2.1

フィールド決定までの活動

函館市の抱える問題点

本プロジェクトメンバーのうち，函館市の抱える問題をシビックテックによって解決したいと考える 10 人のメンバーがシビックテックグループとして活動を開始した．本グループは，函館市公式サイトの「市民の声」や私たちが暮らしていて感じる問題点などを KJ 法を用いて話し合い，分析した [5](詳細は 3.1 で述べる)． その結果，交通，情報，子育て，娯楽の問題に分類できた．次に，その他の地域で行われているシビックテックの事例について調査し，それらをもとに函館市の抱える問題を解決するためのアイデアを出し合った．そこで，私たちが分析した問題について意見を頂くため，Code for Hakodate の中村氏にシビックテック についてレクチャーして頂いた (詳細は 2.2 及び 3.3 で述べる)．
（※文責: 宮岡萌映）

2.2

Code for Hakodate のレクチャー

Code for Hakodate[6] とは，ICT(Information and Communication Technology) を使って函館・道南地域の様々な問題の解決に取り組む団体である．レクチャーでは，シビックテックや Codefor Hakodate の活動やその目的について詳しく教えていただいた．また，今まで私たちが話し合ってきた函館市の問題点やそれについての解決案を発表し，意見を頂いた．私たちは今までアプ
リや Web サイトを作成するといった解決するための手段にばかり注目してしまっていたと感じた．
もう一度しっかり問題を考え直して最善の方法を考えていくべきだと感じた．また，シビックテッ
クには様々な方法があることが分かり，このレクチャーを通して，シビックテックについて理解を深めることができ，私たちのこれからの活動にとても参考になった．
（※文責: 宮岡萌映）

2.3

取り組むべき問題の決定

レクチャーで得られた意見などをもとに，解決案についてもう一度意見を出し合い，話し合いを行った．その中で解決案や開発サービスを考える前に，各自どの問題について取り組んでいきたいのかをもとにグループ分けを行うことにした．その結果，取り組みたい問題が交通と情報で意見が分かれたため，地域交通のデザイン，地域情報のデザインの 2 グループに分かれ，活動を行うことに決定した．
（※文責: 宮岡萌映）

Group Report of 2020 SISP

-2-Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

第 3 章 フィールド決定後の活動
3.1

函館の交通に関する問題調査

フィールドを交通に決定したことで函館市の交通に関する内容でどのような問題があるのかをSNS に投稿された内容や実体験，インターネットなどで調査した．インターネット上の調査では函館市のウェブサイトで交通機関についての情報を用いた [7]．調査では，公共交通機関の利用が年々低下していることがわかった [8]．SNS では，観光地周辺や裏道に違法駐車が多いこと，市内の道路が狭く見通しが悪いことなど，様々な意見が挙げられた．調査の結果を道路の状況，公共交
通機関の情報，観光客に向けた交通関連の情報の 3 つに分類した．道路の状況では狭い道や複雑な道が多いなど見通しの悪い道路が多いことや工事中，新設中の道路，混雑することが多い道路などが挙げられた．公共交通機関は函館バスや函館市電を利用する方が感じていることや到着，出発時間の正確性などが挙げられた．観光客向けの交通情報では，公共交通機関の利用方法や観光地に最寄りの交通手段の情報が少ないことがわかった．調査で得られた課題を改善する方法を検討する
ため，3 つに分類した情報をもとに考えることにした．公共交通機関をもっと利用してもらえるよ
うに世界中で講じられた内容を調査し，改善につなげる．道路状況をコミュニティ内で共有できる

SNS のようなものを作成する．観光客向けには掲示板などに観光地の情報を QR コードで提供できるのではないかと考えた．大きく 3 つに分類した中で本グループはユーザーを絞りやすく，メン
バー全員が利用したことがあり身近である公共交通機関の利用者向上を問題の解決に設定した．
（※文責: 荒戸大輝）

3.2

対象の仮決定と問題解決案

問題解決を行うため，解決の目的と対象を絞ることで問題の具体化を検討した．話し合いの結果，目的を「公共交通機関の利用増による活性化」とし，対象を函館バスに決定した．その理由は，函館市で利用されている函館市電や，JR などの公共交通機関の中でバスの利用率が 1 番低下していることであった [8]．そして，バスを利用してもらうためには，どのような方法があるのか列挙
した．バスロケーションシステムのアプリ化，バス停周辺の活性化，観光客にバスを利用してもらうようにするなどの解決案が挙げられたが，解決方法の具体化は出来ず，実現可能性も考えられていなかった．そのため本グループは，バス以外にも交通に関する問題と解決案を列挙し，函館市の情報に詳しい方から助言をいただくことにした．
（※文責: 荒戸大輝）

3.3

CfH 中村氏と交通問題解決案

対象のフィールドが交通に決定したことを前提に，Code for Hakodate(以降 CfH と略す) の方から意見をいただくために話し合いを行った．話し合いの中で，実現可能なサービスの開発は，技術面と開発時間を考慮することが重要だと助言をいただき，話し合いの中でサービス案を 3 つ提案

Group Report of 2020 SISP

-3-Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020した．バスロケーションシステムのアプリ化，外国人向けの公共交通機関の情報を提示するサービ
ス，バス内の料金表示と IC カードの残高確認の改善の 3 つであった．バスロケーションシステムのアプリ化はロケーション情報の提供をしていただけない可能性がある．外国人向けの情報提供はすでにある提供資料との差別化が必要である．バス車内の表示機能は函館バスの許可を得れば未来大学を経由するバスで実践できるかもしれないことなどの助言をいただいた．
（※文責: 荒戸大輝）

3.4

フィールドワーク

中村氏との話し合いを行った中で，自分自身が交通機関を使用してみることも大切だと助言をいただき，フィールドワークを行うことに決定した．フィールドワークとは研究者自身が現地に赴き，インタビューや資料収集等の調査することであり，フィールドワークを行うことで現地のデー
タを体感しながら獲得することが可能で現地でしか感じることが出来ない雰囲気を経験することが出来る．今年はフィールドワーク中の密を避けるためにメンバーが各々で函館バスを利用し，バス
停の情報や車内の様子，運転手とバス利用者の会話内容や運賃の支払い方法などのバス利用者の特徴に焦点を置き調査を行った．
（※文責: 荒戸大輝）

3.4.1

函館バスの利用と調査

函館バスのバス停や，バス車内を調査した結果から感じたこと，改善可能なものを Google

Jamboard で共有した (図 3.1)．調査した際に気になったことなど，メンバーで共有した内容を大きくまとめると，バスの乗り降り，観光客向け，バス停・バスロケの 3 種類に分類することが出来た．バスの乗り降りでは大きく分け 2 つ発見できた．1 つ目は，乗車時に確認することが出来るバスの側面の表示には，主要な経由地が 3 つほどしか書かれておらず，他の停車地がわかりづらいことだ．2 つ目は，降車時に運賃を払う際，現金で支払う人がお金の用意が出来ていないことや，IC
カードの残高が足りずにチャージを行うことで，時間がかかる人がいたことである．以上の 2 つであれば，何かしらの改善可能なサービスを提供することが出来るのではないかと考えた．過去の実体験やバス利用者の特徴調査から，函館バスは函館市電に比べると，観光客よりも市民が使う公共交通機関であるのではないかと考えた．そのため，観光客向けに分類された内容を改善しても需要が少ないと判断した．しかし，観光客だけでなく仕事や学業の関係で来日した外国人向けに，函館バスの利用方法をわかりやすく提示するサービスなら可能なのではないかと考え候補とした．バス
停・バスロケではバスロケシステムの情報が正確なものではないこと，各バス停で QR コードを読み込んでも，すべてトップ画面で最初から検索する必要がある．そもそも QR コードが小さく読み取りづらいなど，改善の余地があることも少し見られた．しかし，バスロケーションシステムに直接手を加えられないこと，バスロケは企業が行っているものであるため，本グループで解決することは現実的ではないと判断した．
（※文責: 荒戸大輝）

Group Report of 2020 SISP

-4-Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

図 3.1

3.4.2

フィールドワークの内容共有

サービスの仮案

フィールドワークの結果と CfH の中村氏との話し合いから，本グループが改善可能で製作してみたい提供サービスを大きく 3 つに絞り込んだ．

1. 外国人向けサービスの提供
2. 系統番号で検索することで目的地に行くかどうかわかるアプリ
3. バス車内に観光地や目的地を示す掲示板 (映像) の設置
外国人向けサービスの提供では，外国語で降車時の支払い方法などの説明を促すなどの，バス利用方法を映像や紙媒体を用いて，バス車内の見えるところへ設置し，見てもらうようなもの，観光地付近の情報を同じような媒体で提供することなどを，サービス内容として考えた．系統番号での検索はバスが乗車地に到着したが，そのバスが目的地に停車するのかわからなかった際に，系統番号を入力するだけで，目的地で停車するか検索することが可能になるアプリとして考えた．バス車
内の液晶ディスプレイは函館バスにはないが，他の地域では液晶広告として利用されているようなもので考え，バス車内に液晶ディスプレイを設置し，観光地の場所や経由地，ルートを映像で視覚的にとらえることが可能になるサービス内容として考えた．
それぞれの背景や目的，対象を考えると 1 番と 3 番はただ見てもらうだけになってしまい，反応がわかりづらく使ってもらえないのではないかと考え，2 番はユーザーテストをバス利用者に行
い，そのまま意見をいただくことが出来ると考えた．また，開発期間を考慮した結果，3 番は函館バスとの連絡を多数繰り返す必要があり，時間を要すると感じ，2 番の「系統番号を入力し，目的地に行くかを検索可能なアプリ」に決定した．
（※文責: 荒戸大輝）

Group Report of 2020 SISP

-5-Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

3.5

サービス案の決定

3.5.1

システムコンセプトの決定

初めて訪れた地や初めて利用する系統のバスがバス停に到着したとき，目的地から最寄りのバス
停に停車するのか不安になることがあるのではないかと考えた．そのような時にはバスの運転手に直接聞きに運転席の方に移動したり，Web 上で検索をすることが想定される．その方法を用いると一度バスに乗ったり，時間がかかったりしてしまう．そこで系統番号の数字を選択するだけで今来たバスが目的地で停車するのかがわかればバスが到着してからでもすぐに検索できるのではないかと考えた．このアプリケーションは他にはない系統番号から検索可能にすることで価値のあるサービスになると考えた．また，出発地と目的地を入力することで目的地のバス停に停車する複数のバスの系統とルートを表示する機能も追加し，2 つの検索方法があるアプリケーションにすることで開発を行うことに決定した．対象は函館バスを利用するユーザーに定め，具体案を考えていった．
（※文責: 荒戸大輝）

3.5.2

具体的な機能の提案

具体的にあるとよい機能を KJ 法を用いて提案し，Google Jamboard を使用しまとめた．まと
めた機能から，系統番号での検索と乗車地，降車地での検索の 2 種類の検索方法可能なものにした．アプリケーションの大まかな動きや，デザインを Adobe XD を用いて製作した (図 3.2)．デ
ザインを製作後，開発にどのくらい時間を要するのか，その機能は必要かの 2 つを中心に機能を優
先度順に並べ，機能ごとに開発に予想される必要な時間を加え，プロダクトバックログを製作した(図 3.3)．必要な時間は小さい機能ほど予想開発時間が短く，フィボナッチ数列を利用して大きい数字になっていく．また，優先度を高，中，低に大きく 3 つに分類し，機能をそれぞれに分割した．
予想開発時間は，開発の有無があっても完璧な見積もりは不可能である。タスクは前のタスクよりも倍くらい大変そうなど，大雑把な見積もりを立てることが可能なため，フィボナッチ数列を使用する．開発予定のアプリ，系統番号を用いた検索機能を柱としたものであるため，優先度が 1 番高い機能を系統番号を検索出来る機能に設定した．検索はダイアログで選択する方法か，数字を打ち込む方法の 2 通りで考えた．検索する機能で，検索結果を表示するまでではないため，あまり時間はかからないと考え，予想開発時間の数字は 8 に設定した．検索した系統のバスが目的地のバス停に停車するかを確認する必要があるため，バス停一覧を見ることが出来る機能を次に優先度の高い位置づけにした．各系統番号にバス停を入れるためデータベースに入力するデータが多いと判断し検索よりも数字が 1 段階大きい 13 とした．

（※文責: 荒戸大輝）

Group Report of 2020 SISP

-6-Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

図 3.2

Adobe XD によるプロトタイプ

図 3.3Group Report of 2020 SISP

仮のプロダクトバックログ-7-

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

3.6

夏季休業中の活動

本グループは後期開始時からアプリ開発を行うために，夏季休業中に言語学習を行った．アプリ
は Android 用アプリを製作であり、Kotlin の使用することに決定した．さらに，アプリ開発に必要な基礎知識を修得するために Progate[9] を利用して Java の学習を行った．Kotlin は言語構文自体に Java との互換性がない独自方式であるが，コンパイルされたコードは Java VM 上で動作
し，Java の知識を多く流用することが可能なためである．Progate を用いた Java の学習が終了してから，参考書などで Kotlin の学習を行った．
（※文責: 荒戸大輝）

Group Report of 2020 SISP

-8-Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

第 4 章 開発サービス
4.1

概要

私たちが開発しているアプリケーションは， 函館市内におけるバス利用者のバス乗車前や乗車中に関する不安を解消することを目的としている．またアプリケーションの名称は対象フィールドである函館とバスを組み合わせて「ハコバス」とした (図 4.1)．本アプリケーションでは，簡単に操作できる優しさ，系統番号から検索できるという新しさ，素早く調べることができる早さの 3 つをコンセプトとしている．本アプリケーションを利用する主な対象ユーザーは，函館市内のバスを利用する際，乗車前や乗車中になんらかの不安要素を持っている人である．例えば，バス停に到着するバスが自分の行きたいバス停を経由するのかわからないという人や，乗車するバス停から各バス停までの運賃を比較したい人である．このサービスの利用シーンは主にバス停に到着してからか，あるいは乗車中を想定している．この利用シーンに伴い，サービスはブラウザではなくアプリ
ケーションを用いることにした．このサービスの魅力は，自分が乗るべきバスを系統番号で調べることができ，且つどこを経由するのかを一覧で確認できる点である．またバスの系統と乗車するバ
ス停を選択することで，乗車地から他のバス停までの運賃を一覧で比較できる点である．
（※文責: 山本紋豊）

図 4.1

4.2

開発済みの機能

4.2.1

バス停一覧

「ハコバス」のアプリアイコン

本機能は，指定した系統番号のバス停一覧を表示するものである．アプリケーションの起動後最初に検索画面が表示されることから，すぐにこの機能を利用することができる (図 4.2)．検索には系統番号を用いる．系統番号を一覧表示し，その中から選択する方式を採用した．また検索ボッ

Group Report of 2020 SISP

-9-Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020
クスに入力して絞り込む機能も取り入れた．系統番号は複数選択することが可能で，選択するとチェックボックスに印がつくようになっている (図 4.3)．表示したい系統番号を選択した後，画面下部の「この系統番号で検索」ボタンを押すことで検索が実行される．検索結果には各系統番号が経由するバス停が一覧で表示され，ユーザーは目的のバス停までバスが到着するかどうかを確認することができる．また複数の系統番号を選択した場合，画面上方の系統番号をタップすることでそれぞれの系統番号のバス停一覧に切り替えることができる (図 4.4)．
（※文責: 山本紋豊）

図 4.2

図 4.3

起動後の初期画面

Group Report of 2020 SISP

- 10 -

検索画面

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

図 4.4

4.2.2

バス停一覧

料金一覧

本機能は，系統番号で検索した後に乗車するバス停を選択することでその他のバス停に行くまでにかかる運賃を一覧で表示するものであり，4.2.1 のバス停一覧機能に付随する形となっている．
この機能の特徴は運賃を一覧で確認することができる点であり，ユーザーは目的地までの運賃だけでなくそれ以外の運賃と比較することが可能である．例えば，バスの運賃は段階的に繰り上がることから，目的地までの距離と運賃を考慮して降りるバス停を決定したいというユーザーは，料金一
覧をみることで効率よく比較することが可能である．
（※文責: 山本紋豊）

4.3

UI/UX の設計

4.3.1

3 つの価値の決定

まず最初に，ターゲットユーザーを明確にし，どのような価値を提供するのかを言語化することが必要だと考えた．そのため，ユーザーが抱えている問題ごとにターゲットユーザー像 (図 4.5) をそれぞれ設定し，それらのペルソナとして，プロフィール，行動様式，抱えている悩み，アプリ

Group Report of 2020 SISP

- 11 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020
ケーションを利用することで達成したいと考えている最終的な目標を定めた (図 4.6)(図 4.7)．例
えば，運賃を知りたいと思っている人は，運賃表示器が見づらいという悩み，そして運賃を安く抑えるために運賃の変わり目を知りたいという悩みを持っているとした．そしてターゲットユーザー
像をもとに，どのようにデザインしていくべきかを考えた．その結果，“優しい”，“新しい”，“早い”という 3 つの価値をユーザーに届けられるような UI/UX デザインを追求することに決定した．
（※文責: 吉兼刃矢）

図 4.5

図 4.6

Group Report of 2020 SISP

設定したターゲットユーザー像

経由地を知りたいと思っている人のペルソナ- 12 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

図 4.7

4.3.2

運賃を知りたいと思っている人のペルソナ“優しい“優しい”という価値は，バス利用者の小さな不安を解消するという本アプリケーション全体のコ
ンセプト実現から成り立つ．これは，乗車しようとしているバスが目的のバス停に停車するか分からないという不安や，運賃の情報が分かりづらいという不満に対して，“新しい”方法で，必要な情報を “早く”提示することで問題を解決することが，ユーザーにとって “優しい”と言える，ということである．そのため，他の 2 つの価値を追求することが，“優しい”という価値を提供するために重要だった．また，UI の面でもユーザーに優しいアプリケーションとするために，画面のデザイ
ン面についても検討を行った．まず，アプリケーションのテーマカラーを決めるにあたって色の意
味と色が与えるイメージを調査し，気分を落ち着かせる，安心感を与えるなどの効果がある緑色に決定した．次に，グループメンバーの持つ本アプリケーションへのイメージとのズレがないよう，
様々な種類の緑色をアプリケーションのアイコン形式に当てはめ，意見交換を行った (図 4.8)．この意見交換の後，テーマカラーとしてふさわしいトーンとなるように調整を行うと共に，類似サー
ビスのテーマカラーと似すぎることのないよう配慮した上で，もう一度メンバー間で意見交換を行った (図 4.9)．また，アプリケーションの機能誘導としてモジュール型のチュートリアルを配置
した (図 4.10)．これによってスライド型やダイアログ型のチュートリアルと異なり，ユーザーの自主的な行動を中断させることなく説明内容を理解してもらえるようにした．
（※文責: 吉兼刃矢）Group Report of 2020 SISP

- 13 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

図 4.8

テーマカラー検討 1 回目

図 4.10Group Report of 2020 SISP

図 4.9

テーマカラー検討 2 回目

モジュール型チュートリアルの画面- 14 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

4.3.3

“新しい

本アプリケーションは，ユーザーがバス停やバス乗り場にいる場面で使われることを想定している．そこで，後述する “早い”バスの検索方法として，既存のナビアプリに見られる出発地と目的地を設定して検索する方法ではなく，時刻表やバスの表示に書いてある系統番号からバスを特定して検索するという方法を採用した．そして，機能を系統番号から検索という一機能に絞った．これにより，類似サービスとは異なり，系統番号が分かる状況で経由地や運賃をより簡単で早く調べることに特化したシンプルなアプリケーションとなっている．また，バスの経由地一覧から出発地を設定し，そこからの運賃の一覧を見ることができる．これにより，ユーザーは出発地から目的地付近のバス停までの運賃を確認できるようになる．そして，運賃の変わり目を把握して降りるタイミン
グを選択することができる．これは，類似サービスにはない情報の提示方法であるため，ユーザーにとって新しい価値を提供できるのではないかと考えた．
（※文責: 吉兼刃矢）

4.3.4

“早い

ターゲットユーザー像の一つである，乗ろうとしているバスの経由地について知りたいというユーザーに向けて，素早い情報探索が可能でなければいけないと考えた．そこで，ユーザーが活用できるバスを特定するための情報として，系統番号に着目した．出発地と目的地を指定してバスを特定するより，短く分かりやすい系統番号を用いた検索方法にすることで，ユーザーはより素早く検索できる．また UI の面では，機能を 1 つに絞ったシンプルなアプリケーションであることによって，メニューバーやナビゲーションバーなどで複数の選択肢を提供する必要がない．そのため，何の機能を使えばよいかユーザーにとって迷いにくい UI にすることができたと考える．
（※文責: 吉兼刃矢）

4.4

データベースについて

本サービスでは，バス停のデータと料金のデータを，Google 社が提供する Firebase[10] というサービスを利用して運用している．Firebase は，mBaaS(エムバース，mobile backend as aservice) の一種であり，スマートフォンアプリ開発でよく利用される処理 (バックエンド処理)
を mBaaS サービスが代行するクラウドサービスである．開発者にとっては，データを保存する
サーバーの開発や運用が不要になるというメリットがある．mBaaS の代表的サービスとして，

Firebase の他にニフクラ mobile backend や AWS Mobile Hub がある．本グループでは，開発環
境が Google 社の提供する Android Studio であったことや，他サービスに比べてデータベースの操作が比較的簡単であったことから，Firebase を利用して開発を行うこととした．データベースへのデータの追加は，JSON ファイルをインポートすることにより実現した．これは，複雑かつ大量のデータを管理する際は JSON ファイルで管理する方が理にかなっているためである．現時点ではスクレイピング (PDF などから直接データを抽出・加工すること) を行わず，全て手入力により実装しているが，もしデータの変更や運賃の改定があった場合にデータを更新するために莫大な手
間と時間が必要となるため，スクレイピングを用いてデータを入力することが理想であると考えてGroup Report of 2020 SISP

- 15 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020
いる．
（※文責: 田中陽都）

4.5

今後の展望

4.5.1

ユーザビリティテストの実施

画面上の情報の見やすさや，系統番号を選択する方法は適切かどうか，初めて使った人が検索の流れを理解できるかなどの項目についてユーザビリティテストを行いたいと考えている．具体的には，被験者がある系統のバスに乗ろうとしていると仮定し，目的地となるバス停を提示された被験者が，その系統に乗っても良いか判断できるまでの秒数のテストなどが考えられる．ユーザビリ
ティテストを行った後，2 月までにアプリリリースを目標として，再び機能面とデザイン面での改善を行う．
（※文責: 吉兼刃矢）

4.5.2

実装途中の機能実装

現状では運賃データのデータベースが未完成であり，特定の系統番号でしか正しく情報を見ることができない状態となっているため，データベースの作成が今後の課題となる．また，度重なるコンセプトの見直しによって開発開始が遅れてしまったことから，デザイン面についてはまだ実装が途中の段階である．そのため，今後は Adobe XD で作成した画面イメージを目標に実装を進める．

(図 4.11)（※文責: 吉兼刃矢）図 4.11

4.5.3

目標となる画面イメージ

機能面の改善・追加

系統番号を選択するための方法についてはまだ改善の余地がある．現状ではリストからの選択のみとなっているが，テンキーのような形で系統番号を入力するという方法もあわせて検討中であGroup Report of 2020 SISP

- 16 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020
る．これは，リストから目的の系統番号を選択するのに時間がかかることが考えられるためである．また，GPS を用いて，ユーザーのいる場所から近いバス停を通る系統番号のみをリストで表示するという機能も改善案として挙がっている．この機能によって，ユーザーにとって無関係な系
統番号はリストに表示されなくなり，より素早く目的の系統番号を選択できるようになる．しかし，これらの機能については前述の実装途中の機能を実装した後に，アプリリリースまで余裕がある場合に取り掛かる予定である．
（※文責: 吉兼刃矢）Group Report of 2020 SISP

- 17 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

第5章
5.1

開発が始まってからの活動

アジャイル開発について

本プロジェクトは，アジャイル開発手法の一種であるスクラム手法 [11] を用いて活動した．ア
ジャイル開発とはシステムやソフトウェア開発におけるプロジェクト開発手法の一つである．計
画，開発，テストといった開発工程を機能ごとなど，小さいサイクルで繰り返す．それにより個々の機能の開発が独立して完結するため，開発期間中の急な変更もでき，リスクを最小化させることが可能である．
（※文責: 宮岡萌映）

5.1.1

スクラム手法について

スクラム手法とは，前述の通りアジャイル開発手法の一種である．スクラム手法はスプリントという一定の期間毎にプロダクトバックログ項目の優先順位が高いものから動くソフトウェアを作る．本スクラムチームでは 1 スプリント 2 週間で活動した．スプリント毎で作成されたソフトウェ
アを評価する形で開発を進めていく． その結果，すばやく開発することを可能になる．
（※文責: 宮岡萌映）

5.1.2

プロダクトバックログの作成

プロダクトバックログとは機能やユーザーの要望などを優先度順番に並べ替えたリストである．
本グループのプロダクトバックログは図 5.1 のようになった．アプリケーションの目的である利用者の乗車前の不安を取り除くという点で，検索には “早さ”が重要であると考えた．それらを解決できる方法として，類似サービスにはない “系統番号から検索”という検索機能の優先度を高く設定した．
（※文責: 宮岡萌映）

図 5.1

Group Report of 2020 SISP

プロダクトバックログ- 18 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

5.1.3

スプリントプランニングについてスプリントプランニングとは，そのスプリントで達成するゴールを決め，そのために計画するものである．達成するための項目をプロダクトバックログから選択し，さらに細かいタスクに分け見積もりを出し，作業量を調整する．具体的な内容は 5.2 以降にスプリント毎に述べる．
（※文責: 宮岡萌映）

5.1.4

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

デイリースクラムとは，自分が何の作業をやったか，これからやる作業は何か，作業をしていて問題点は何かを毎日同じ時間に共有し合うものである．本スクラムチームでは毎日 12:10〜13:10に Slack の各自の times で行なった．デイリースクラムの例を図 5.2 に示す．
（※文責: 宮岡萌映）

図 5.2

5.2

10 月 7 日の宮岡のデイリースクラム

スプリント 1

スプリント 1 の期間は 2020 年 9 月 30 日〜10 月 9 日である．9 月 30 日にスプリントプランニ
ングを行い，10 月 9 日にスプリントレビューとスプリントレトロスペクティブを行なった．
（※文責: 宮岡萌映）

5.2.1

スプリントプランニング

9 月 30 日にスプリントプランニングを行った．作成したスプリントバックログは図 5.3 の通りである．プロダクトバックログから優先度を考慮し作成した．
（※文責: 宮岡萌映）

図 5.3

Group Report of 2020 SISP

スプリント 1 でのスプリントプランニング- 19 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

5.2.2

スプリントでの成果

本スプリントでは，開発方法などの事前調査が足りておらず開発に取り掛かることができなかった．また，アプリの各機能についても曖昧な部分が多く，話し合いに時間をかけることになった．
（※文責: 宮岡萌映）

5.2.3

スプリントレビュー

今回のスプリントレビューはプロジェクトリーダー，各グループのリーダーの 4 名で行なった．
どのグループも事前の準備不足や見積もりがうまくいかず，開発に取り掛かることができなかった
為，各グループの開発するサービスについての発表を行った．サービスについて初見の人からの意
見を聞くことができ，機能ごとのユーザーにとっての有用性を考え直すことができた．また，サービスの良さをよりわかってもらえる発表の仕方なども考えるべきだと感じた．
（※文責: 宮岡萌映）

5.2.4

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

スプリントレビューをリーダーだけで行った為，メンバーにレビューの内容などを共有した．また，スプリントレトロスペクティブという今回のスプリントの良かった点，悪かった点などを話し合い，スプリント全体の振り返りを行った．
良かった点

1. 開発途中でプロダクトバックログを改善できた
2. 各メンバーが役割を理解して取り組むことができた
3. お互いにカバーしながら作業をこなせた
悪かった点

1. 環境構築などの準備が足りていなかった為，開発に取り掛かれなかった
2. 各メンバーの仕事の共有を十分に行えなかった
3. 各機能を明晰にする必要があった
以上のことが挙げられた．各メンバー同士の情報共有が十分にできていなかった点，事前調査や準備が足りていなかったことから開発に取り掛かることができなかったことが分かった．これらの反省を踏まえて次のスプリントでは積極的な情報共有，スプリントプランニングをより細かく行う
ことになった．
（※文責: 宮岡萌映）

Group Report of 2020 SISP

- 20 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

5.3

スプリント 2

スプリント 2 の期間は 2020 年 10 月 14 日〜10 月 23 日である．10 月 14 日にスプリントプラン
ニングを行い，10 月 23 日にスプリントレビューとスプリントレトロスペクティブを行なった．
（※文責: 宮岡萌映）

5.3.1

スプリントプランニング

10 月 14 日にスプリントプランニングを行った．作成したスプリントバックログは図 5.4 の通りである．プロダクトバックログから優先度を考慮し作成した．

図 5.4

スプリント 2 でのスプリントプランニング（※文責: 宮岡萌映）

5.3.2

スプリントでの成果

本スプリントでの成果は以下の通りである．

1. 市内主要系統図 A の 43 系統分のバス停データをデータベースに格納する
2. アプリ画面にデータベースにあるバス停一覧 (7A 系統) を表示させる
3. アプリ画面に選択した系統番号のバス停一覧を表示させる（※文責: 宮岡萌映）

5.3.3

スプリントレビュー

今回のスプリントレビューはプロジェクトメンバー 15 名全員で行なった．各グループのリー
ダーが, 自分たちのグループが開発するサービスについて説明し，今回のスプリントでの成果をデモで発表した．他のグループが開発するサービスや進捗について知ることができた．自分たちのサービスについて普段からバスを利用する人，あまり利用しない人どちらの意見も聞くことができ，プロダクトバックログについてもう一度話し合いを行い，機能の優先度，必要性について考え直さなければならないと感じた．

Group Report of 2020 SISP

- 21 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020（※文責: 宮岡萌映）

5.3.4

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

プロジェクトメンバーからのレビュー内容を確認し，スプリント全体の振り返りを行った．スプ
リントにおける良かった点，悪かった点は以下の通りである．
良かった点

1. データベースを使用して画面上に表示できた
2. 分担して作業できた
3. デイリースクラムの時に良い話し合いができた
悪かった点

1. スプリントが始まってから使用するデータベースが変更になった
2. プロジェクト活動日以外の日の情報共有がうまく行えていない
前回のスプリントの反省から十分に調査したつもりではあったが，スプリント内での大きな変更があった．その為全てのタスクを達成することができなかったと考えられる．また，プロジェクト
活動日以外の情報共有ができていない為，他のメンバーがどの作業をしているのかわからない時があった．Slack などを活用して，情報共有することの大切さを再認識することができた．
（※文責: 宮岡萌映）

5.4

スプリント 3

スプリント 3 の期間は，2020 年 10 月 28 日 (水) から 11 月 6 日 (金) までである．10 月 28 日にスプリントプランニングを行い，11 月 6 日にスプリントレビューとスプリントレトロスペクティブを行った．
（※文責: 田中陽都）

5.4.1

スプリントプランニング

10 月 28 日にスプリントプランニングを実施した．作成したスプリントバックログを図 5.5 に示
す．プロダクトバックログと前回スプリントまでの進捗度を考慮し，優先度の調整を行った．今回のスプリントではタスクが多岐に渡るため，進行状況を可視化するために，右端に「進行中」であるか「完了」であるかを記す欄を設置した．

Group Report of 2020 SISP

- 22 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

図 5.5

スプリント 3 でのスプリントプランニング（※文責: 田中陽都）

5.4.2

スプリントでの成果

本スプリントでの成果は以下の通りである．

1. 乗車バス停と降車バス停の入力をもとにした料金表示システムの実装
2. 前スプリントで作成したバス停の一覧表示と当システムの結合
3. UI の改善 (プロトタイプの改善・実際のアプリケーションへの反映)（※文責: 田中陽都）

5.4.3

スプリントレビュー

11 月 6 日にプロジェクトメンバー 15 人・TA・指導教員によるスプリントレビューを実施した．
今回のレビューでは，ユーザーストーリーについて，ペルソナを設定するなどしてより詳細に説明することにした．ペルソナとは，仮想のユーザーのことであり，このペルソナの視点からサービス
が本当に適しているものか判断する手法のことをペルソナ分析 [12] という．頂いたレビューの中には，既存のアプリやサービス (NAVITIME やバスロケーションシステムなど) との差が分かりに
くいとのご指摘を多く頂いたため，類似サービスとの比較表などを作成して説明する必要があると気づいた．類似サービスとの比較表については，次回のスプリント内で作成した．詳細については

5.5 で述べる．また，位置情報機能の実装や履歴機能など，改良できる点を多く見つけることができた．
（※文責: 田中陽都）

5.4.4

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

スプリントレビュー後にスプリントレトロスペクティブを行い，スプリント全体の振り返りを行った．スプリント内での良かった点，悪かった点は以下の通りである．
良かった点

1. 分担して作業に取り組めた
2. こまめに進捗報告ができた
3. 実機で動かせるようになったGroup Report of 2020 SISP

- 23 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020
悪かった点

1. 各個人で作業量に偏りがあった
2. モチベーションの低下
前回のスプリントの反省を活かし，Slack 上で細かく進捗の報告をすることができたと感じる．
また，今回のスプリントで実際に実機の端末で動かすことができるようになり (図 5.6)，成果を感じることができたと思う．しかし，スプリントを通してみると，各個人で作業量が偏っていることが浮彫りとなった．これは，個人の開発技量の差が広がったことが原因であると考えられる．また，開発期間も 6 週間を超えて，モチベーションの維持が難しくなってきていることもわかった．

図 5.6

実機で動いている様子（※文責: 田中陽都）

5.5

スプリント 4

スプリント 4 の期間は，2020 年 11 月 11 日 (水) から 11 月 20 日 (金) までである．11 月 11 日にスプリントプランニングを行い，11 月 20 日にスプリントレビューとスプリントレトロスペク
ティブを行った．
（※文責: 田中陽都）

5.5.1

スプリントプランニング

10 月 28 日にスプリントプランニングを実施した．作成したスプリントバックログを図 5.7 に示す．最終スプリントであることを考慮して大きく方針が変わり，マップ機能については期間内での実装は難しいと考え，実装しないことになった．
（※文責: 田中陽都）

Group Report of 2020 SISP

- 24 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

図 5.7

5.5.2

スプリント 4 でのスプリントプランニング

スプリントでの成果

本スプリントでの成果は以下の通りである．

1. TabLayout と ViewPager 機能を利用したタブによる複数系統の検索の実装
2. UI の改善 (実際のアプリケーションへのプロトタイプの反映)
3. 発表スライド内への，類似サービスとの比較表の追加 (図 5.8)
図 5.8 については，5.4.3 で述べたように，既存のサービスとの相違点を表としてまとめたものである．この図はアカデミックリンクでの発表時に用いたスライドで使用した．アカデミックリンクについての詳細は第 7 章にて述べる．また，スライドは付録 A に添付する．
（※文責: 田中陽都）

図 5.8

5.5.3

類似サービスとの比較表

スプリントレビュー

11 月 20 日にプロジェクトメンバー 15 人・TA・指導教員によるスプリントレビューを実施した．今回のスプリントレビューでは，後述するアカデミックリンクや成果発表を見据えて，5 分程
度の短時間で発表を行うことにした．前回のスプリントレビューで学んだことをもとに，スライド
中に既存サービスとの比較表を挿入してより優位性をアピールすることができた．アプリの完成度が高まってきたため，前回のスプリントレビューよりも，機能についてより細かい質問を頂くことができた．

Group Report of 2020 SISP

- 25 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020（※文責: 田中陽都）

5.5.4

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

スプリントレビュー後にスプリントレトロスペクティブを行い，スプリント全体の振り返りを行った．スプリント内での良かった点，悪かった点は以下の通りである．
良かった点

1. UI デザインについて全員で話し合いができた
2. メンバーの進捗共有ができた
悪かった点

1. 開発環境などの理由で作業の進みが遅かった
2. モチベーションが下がっていった
前スプリントまでは UI デザインをメンバー 1 人がすべて請け負っており，そのメンバーの進捗に他の行程が左右されるという状況だったが，本スプリントでは全員がデザインに携わり，意見を擦り合わせながらより良い UI を計画・実装することができた．また，前スプリントに引き続き，
メンバー間で細かく進捗を報告することができた．しかし，メンバーによってプログラムのデータが開けないなどの問題が起きた．具体的には，あるメンバーの PC でのみ，GitHub 上に保存している本サービスのプログラムファイルが，原因不明のエラーによって起動することができなかった．原因として，各個人の開発環境の違いが一因として考えられる．各個人が開発で使用した PC
は Windows PC が 3 人，Mac OS PC が 2 人とばらつきがあった．また，性能不足で Android

Studio が快適に動かない PC を使っているメンバーもおり，環境要因のエラーが発生しやすい状態であった．この問題は解決することができなかったため，正常にプログラムファイルが開けるメンバーのみが開発作業を行い，正常に動作しないメンバーには発表用のスライドの作成・手直しな
どのタスクを割り振ることにした．この問題が影響して，作業の進行が遅れることになってしまった．また，この問題がモチベーションの低下に拍車を掛けてしまったと感じている．
（※文責: 田中陽都）

Group Report of 2020 SISP

- 26 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

第 6 章 中間発表
6.1

発表準備

中間発表に向け，想定される質問への回答リスト，質疑応答用のスライドを作成した．スライドはフィールドワークでの発見や開発サービスの仮案，函館市の交通の問題点など，活動の経緯を中心にまとめた．そして，実際に質疑応答ではフィールドワークの結果についての質問があり，スライドで対応することができた．また，今年度の中間発表は Web 会議サービス「Zoom」経由での発表となった．そのため，アプリケーションの完成イメージを並べた Adobe XD のウィンドウを画面共有しながら説明するなど，発表の際には工夫をした．
（※文責: 吉兼刃矢）

6.2

発表についての評価と反省

中間発表の発表技術，発表内容について 39 人からレビューをいただいた．本グループに対しては以下のような主旨のコメントが寄せられた．

1. プロジェクト内の 3 グループの中でも特に聞きやすかった．
2. 課題の紹介にとどまっているのではないか．
3. 具体的なアイデアについての言及がなく，評価できない．
4. バスのシステムが分かりづらいと感じていたため，いいテーマ設定だと思った．
これらのコメントから，発表技術，函館バスのユーザーが抱える問題の解決というテーマは良いが，具体的なアイデアの提案が不十分であったことが分かった．この気づきをもとに，中間発表後には仮案について検討する時間を設け，最終的な開発サービスをどうするかについての話し合いを行った．
（※文責: 吉兼刃矢）Group Report of 2020 SISP

- 27 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

第7章
7.1

アカデミックリンク概要

本グループは，HAKODATE アカデミックリンク 2020 と呼ばれる，キャンパス・コンソーシア
ム函館が主催する函館市内８つの高等教育機関が研究内容を発表する合同発表会に出展した．今年のアカデミックリンクは 2020 年 11 月 28 日 (土) から 2020 年 12 月 20 日 (日) までオンラインで行われ，ポスターやスライドで紹介するブースセッションと動画で紹介するステージセッションに分かれて研究内容を発表した．本グループはブースセッションとしてハコバスのサービスを出展することにした．
（※文責: 山本紋豊）

7.2

スライドの作成

本グループでは， ブースセッションでの発表としてスライドを用いることに決め，スライドの内容を 2020 年 11 月 4 日 (水) から作成し始めた．成果発表で使用する動画内スライドにも用いることができるようにできるだけ見やすく，サービスを初めて見た人にも理解しやすいスライドを目指して作成し，2020 年 11 月 18 日 (水) に完成した．内容には，プロジェクトや本グループについての概要，サービス概要や類似アプリとの比較表，本サービスのコンセプト，実際の機能と今後の展望について記載した．文字を少なくし，代わりにイラストや図，開発した画面などを多く用いる
ことを意識した．また内容の順序についても考慮することで，読み手が内容を理解しやすいスライドが作成できたと感じる．作成したスライドは付録 A に添付する．
（※文責: 山本紋豊）

7.3

レビュー内容7.3.1

フィードバックの内容

アカデミックリンクの各出展ページからアクセスできるお問い合わせフォームから本グループの研究発表についてのフィードバックをいただいた．寄せられたフィードバックは 2 つで，学内と学外の方からのものであった．回答の中には，どのバスが自分の行きたいバス停を経由するかわからないという問題に対して，ユーザーに系統番号で検索してもらうことは難しいのではないかという
意見，系統番号で目的のバス停を調べるのではなく，目的のバス停からそのバス停を経由するバス
を知れる方が良いと感じたという意見，この高齢化社会において函館のバス路線は複雑なのでこのようなサービスは優しくとても便利だと感じたという意見，料金一覧の機能は他の類似サービスにはないのであると便利だという意見，市外の人に案内する際に函館のバスは複雑で苦労するという意見があった．
（※文責: 山本紋豊）

Group Report of 2020 SISP

- 28 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

7.3.2

フィードバックに対する評価と反省

フィードバックで得られた回答から，やはり系統番号で検索するという検索のしづらさやニーズの少なさが伺えた．バス路線の複雑さから系統番号で検索という機能は良いと感じる声もあり，自分たちのサービスの後押しになったと感じる．また料金一覧の機能については他の類似サービスにはないことから良い評価を得ることができたと感じる．一方で目的のバス停から系統番号を検索するというアプローチは開発するサービスを考案する際には出てこなかった考えであったことから新しい知見を得たと言える．さらに，函館市内で生活している人と市外から来る人とでサービスの使
いやすさが異なるかどうかについても疑問が浮かび，今後のサービスデザインの改善につながる
様々なフィードバックを得られたと感じる．
（※文責: 山本紋豊）

Group Report of 2020 SISP

- 29 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

第8章
8.1

成果発表

発表準備

成果発表の準備は，発表当日の 2 週間前から始めた．発表はオンラインでポスターと動画の提出があり，役割分担して作業を進めた．TA やプロジェクトメンバー，担当教員のレビューを複数回受け，それを元に改良を行った．
（※文責: 山本紋豊）

8.2

ポスターと動画の作成

ポスターは中間発表の内容を元に改良を加える形で作成した．プロジェクトの概要や全体の活動の流れ，3 つのグループの内容がそれぞれわかりやすいように配置やデザインに気を使いつつ作成
した．レビューを受ける中で細かな修正を行い，誰が見ても活動内容が伝わる見やすいポスターが作成できた．また動画内で用いるスライドについては，アカデミックリンクで使用したスライドに改良を加える形で作成した．またスライドに合わせて音声で説明することで，スライドの内容を補足するとともにより理解しやすい動画が作成できた．作成したポスターは付録 B に添付する．
（※文責: 山本紋豊）

8.3

レビュー

8.3.1

レビューの内容

成果発表の際，Google フォームで寄せられたレビューを Google スプレッドシートにまとめた．
その中で本グループに向けられたレビューとしては，利用者のニーズをよく捉えている，バス利用
者として料金一覧は役に立ちそう，系統番号を軸にするのはいいアイデアだがもう一工夫あると良い，バス停を指定しそのバス停の時刻表の中から系統を選ぶようにしてはどうか，利用シーンがわかりづらい，バスの接近情報がわかると便利などがあった．またプロジェクト全体に向けられたレビューとしては，調査を元に開発を行なっていることが良いと思った，動画とポスターが見やす
い，動画とポスターだけでなく活動の中で苦労した点なども知りたかった，目的・背景や機能がはっきりしていてわかりやすかった，目的設定と結果が伴っていたなどがあった．
（※文責: 山本紋豊）

8.3.2

レビューの評価と反省

本グループに向けられた様々なレビューの中で，料金一覧の機能が好評だったと感じた．実際，類似する他のアプリには見られない機能なので，より改良を加えてユーザーにとって使いやすい機能にしたいと感じた．また系統番号から検索という点についてはやはり賛否両論という印象を受けGroup Report of 2020 SISP

- 30 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020た．現状，一部のニーズにしか答えられていないことは確かであると感じるので，検索方法の改善
や新しいアプローチの仕方についても検討していく必要があると考える．同様にバスの接近情報がわかる機能やその他の新しい機能を求める声もあったが，現状のコンセプトでは追加しづらいので，この点については慎重に検討する必要があると感じた．また動画やポスターについては全体的に良い評価をいただいたので，今回の成功を元に今後もどんな読み手であっても理解できるような
わかりやすいものを作っていこうと感じた．
（※文責: 山本紋豊）

Group Report of 2020 SISP

- 31 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

第9章
9.1

知識・技術習得

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

6 月 5 日に，南部准教授によるフィールドワーク入門講座を受けた．まず活動を始めるにあたり，どのような目的を持ちフィールドワークに臨むのか，現場とどう信頼関係を築くのか，などを意識することが大切だということが分かった．また，今年はコロナ禍における様々な制約があるが，これまでとは異なった挑戦をするチャンスでもあるという姿勢を教わった．資料の一部を図9.1 に示す．

図 9.1

フィールドワーク入門講座 資料 (一部抜粋)（※文責: 吉兼刃矢）

9.2

スクラム開発ワークショップ

6 月 17 日に，enPiT 特任教授である永瀬氏によるスクラム開発ワークショップに参加した．ア
ジャイル開発の概要について学んだのち，スクラムの復習を行った．このワークショップを通して，スプリントごとに計画を立てること，計画よりも計画づくりを重視することが大切だということが分かった．
（※文責: 吉兼刃矢）Group Report of 2020 SISP

- 32 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

9.3

アジャイル開発勉強会

6 月 19 日に，本プロジェクト TA の立花氏によるアジャイル開発勉強会に参加した．アジャイ
ル開発をしていく上で取り入れるスクラムというフレームワークについて，昨年のスクラムを例に解説を受けた．その後，ワークショップ形式でプロダクトバックログ作成などを行い，チームとして開発していく過程を学んだ．プロダクトバックログ作成では，例としてオンラインショッピング
サービスを想定し，フィボナッチ数を用いて作業工数を見積もった．グループメンバーと話し合いながら作業工数を見積もっていくことが，計画的な開発に繋がるということを学んだ．資料の一部を図 9.2 に示す．

図 9.2

アジャイル開発勉強会 資料 (一部抜粋)（※文責: 吉兼刃矢）

9.4

Git/GitHub 講習会

8 月 10 日 に ，当 大 学 学 部 4 年 の 白 幡 氏 に よ る Git/GitHub 講 習 会 に 参 加 し た ．そ こ で ，Git/GitHub についての説明を受けた．この講習会を通して，バージョン管理の重要性を学んだ．また，一人ひとり環境構築をして，手を動かしながら使い方を学んだため，共同開発をしていく体制を整えることができた．資料の一部を図 9.3 に示す．
（※文責: 吉兼刃矢）Group Report of 2020 SISP

- 33 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

図 9.3

9.5

Git/GitHub 講習会 資料 (一部抜粋)

開発言語の勉強オンラインプログラミング学習サービス「Progate」の法人プランに加入し，開発言語 Java，

Kotlin の基礎的な学習を進めた．
（※文責: 吉兼刃矢）Group Report of 2020 SISP

- 34 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

第 10 章
10.1

学び

宮岡萌映

プロジェクト学習を通しての学びは二つある．一つ目は，グループでの開発の難しさである．今
年はコロナの影響でオンラインでの活動がメインとなった．話し合いでは，意見が出しずらかったり，表情が見えない分，メンバーに思っていることが伝わりにくいことも多かった．対面でのみん
なで集まれる時の作業とオンラインでの作業を分けることで効率的に進めることができた．また，開発が始まってからはモチベーションの維持とスプリントごとの見積もりが難しかった．思うように実装できないことも多くモチベーションが下がってしまうこともあったが，XD でプロトタイプを作成することで完成のイメージを持ちながら開発を進めることができていったと感じる．

二つ目は，私自身グループのリーダーとして，自分自身が作業をしながらメンバーの状況を確認してタ
スクの割り振りをすることが難しかった． 開発経験がなく，わからないことも多かった．どの作
業をしているか，何で困っているかを知るためにも情報共有が 1 番大切だと感じた．調べてわからなかったことでもメンバーに聞くとすぐに解決できることもあった．コミュニケーションを取り，困っていることはすぐに共有し，協力し合うことで最後まで活動できたと感じる．リーダーをして学べたことが多くあったので今後に活かしていきたい．
（※文責: 宮岡萌映）

10.2

田中陽都

今年は，新型コロナウイルスの影響で 1 年を通してオンライン上での作業というのが多かった．
そのような特殊な状況下でのプロジェクト学習を通じて，大きく 2 つのことを学ぶことができたと感じる．1 つ目の学びは，チームで活動することの難しさである．タスクを各個人に割り振ったはいいが，実際には各個人で進捗の足並みが揃わず，作業が遅れるということが多かった．その原因としては，技量不足だけではなく，モチベーションが保てずに作業が停滞してしまったことなどが考えられる．改めて，チームで足並みを揃えて 1 つのモノを作り上げることの困難さを思い知った．2 つ目の学びは，目標 (ゴール) を設定することの大切さである．前述のモチベーション低下の原因としては，開発する機能が完全に定まっていなかったことでアプリケーションのの完成形が想像し難く，目指すべきところが不明瞭であったことが上げられる．最初の設計の段階で実装すべ
きものをある程度明確にすることが大切であると感じた．3 つ目の学びは，オンライン上で活動することの特殊さである．今まではメンバーが集まって対面しながら話し合うのが当たり前であったが，Zoom 上での話し合いはボディーランゲージが伝わりにくい上，回線による遅延などもあって自然に話すことが難しいと感じた．その確証として，後期に数週に 1 回登校して集まって話す機会が設けられたが，その時は Zoom 上での話し合いより話が弾んだと感じた．また，ずっとパソコンの前に座っているだけなので，話し合いに区切りがつかず延々と長引いてしまうこともあった．今後もしばらくはオンライン上での活動が続くと予想されるため，リフレッシュの時間を設けるな
ど，自分なりの対策をしていくことが大切だと感じた．

Group Report of 2020 SISP

- 35 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020（※文責: 田中陽都）

10.3

山本紋豊

複数人でチームを組み，グループで協力して一つのサービスを設計・開発することができてとても良い経験になったと感じる．プロジェクトが始まった当初は，それぞれでやりたい事が分かれて
いてまとまりがなく，またオンラインということもあり活動がやりづらいと感じていた．これまで自分の意見をしっかりと持つ意識がなく，他人の意見を受けてばかりだった．しかし，グループが決定し，グループでの活動が開始してからは自分の意見をしっかり持って発言するようになれたと感じる．また，グループ内でお互いに考えを言うことで意見の共有ができ，そのおかげでグループ
全体やメンバーそれぞれの活動の状況を常に整理できていたと思う．夏休みの期間を使って技術習得を行ったが，サービス案が完全に決定していないまま次の活動に移ってしまったことは反省すべき点だと感じる．結果として用いられなかった技術について習得していたこともあり，計画性の無さが効率の悪さとして出てしまった．同様に，開発段階に入ってからサービスやコンセプトの見直しが行われたこともあり，これらのことからプロジェクト活動は順序に沿って行うことが大切であり，前の部分が不完全なまま次に移ることはよくないと経験する中で理解することができた．
また，グループ活動全体を通して自分がグループの雰囲気をよくすることがよくあり，そのことか
らチームで協力して活動する中での自分の役割を感じられた．中間発表では，受けた質問を記録する役割として速記に努めたが，自分が答えなければいけない質問などもあり，完璧にこなすことはできなかった．中間発表で受けるフィードバックは大切なもので，その後の活動にとても役立つものだと考える．従って，このような状況を見据えて自分だけがやるのではなくあらかじめ複数人にお願いして役割分担をすべきだったと感じた．また，その時の反省を元に，成果発表では複数人で協力して質疑応答の記録を行い，結果として後に見返すことができるものができて良かったと考える．
（※文責: 山本紋豊）

10.4

吉兼刃矢

プロジェクト学習を通して学んだことは大きく分けて 3 つある．1 つ目はオンラインでの共同作
業の難しさである．今年度のプロジェクト学習は大部分がオンラインで行われたが，前期から他科目でオンライン講義を受講していたため，オンラインでの取り組みに慣れつつあると思っていた．
しかし，始まってみるとプロジェクト学習は困難が多く，主にコミュニケーション面で問題を感じることが多かった．二週間に一度，グループ全員が大学に集まって対面で作業できる日があった．
その際には，グループ内で役割の関係性が深い人同士が，カジュアルにコミュニケーションを取りながら作業を行っていた．気軽な相談から問題解決に発展したり，雰囲気の面で良い影響があったように感じた．しかし，オンラインでの活動の日は Zoom や Discord 上でグループごとに通話上の部屋に集まって作業を行う形式だったため，一つの場をグループ全員で共有しなければならな
かった．そのため，それぞれができる限り一人で自分の作業をし，必要な時だけ発言するというよ
うな，遠慮がちな姿勢になってしまったと考えられる．2 つ目は基礎を固めることの重要性である．本グループのアプリケーション開発では，途中にコンセプトを見直さなければならない場面が多数あった．これは，ターゲットユーザーに関する調査が不十分だということや，期限内での開発

Group Report of 2020 SISP

- 36 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020が難しいということが，開発を始めてから明らかになったためである．この問題によって手戻りが発生し，開発にかかる工数が何度も変動した．この経験から，コンセプトを考える段階には特に時間をかけ，後から手戻りのないように価値をしっかりと説明できるようになってから開発に取り掛からなければいけないことを学んだ．3 つ目は共同開発における個人の役割についてである．それぞれが役割を持って開発に取りかかったものの，進捗の共有があまり活発でなく，開発が停滞してしまうことが度々あった．それにより，自分も含め多くのメンバーにモチベーションの低下が見られた．また，自分が担当していた UI の部分で迷いが生じた際もグループに共有するのが遅く，多くの時間を使ってしまった．UI デザイナーはグループ内において，開発のゴールとなるサービスのイメージを提供することができる役割であると考えられる．そのため，もっと自らが素早く画面
イメージを仕上げて共有することで，ゴールが明確となりモチベーション向上を図ることができたのではないかと考えている．この経験から，共同開発においてはそれぞれのメンバーが開発担当部
分だけでなく，グループ内の士気の面でも影響を及ぼすということを学ぶことができた．
（※文責: 吉兼刃矢）

10.5

荒戸大輝

今年のプロジェクト学習はオンラインであったため理想の開発には至らなかった．なぜなら対面で行われていれば進捗状況を提示しながら進めることが出来るがその報告が言葉のみの状況が多く，あまりメンバー間での状況把握ができていなかったからである．しかし，何度かの対面授業の日には各々の役割をはっきりさせて進めることが出来ていた．もし，オンラインが大半でなければもっと良い開発になったのではないかと考える．私はこのプロジェクト学習でグループでの開発の難しさと有意義であることを学んだ．何度も情報共有が必要だがその分だけ何度もコミュニケー
ションをとることでメンバー間の信頼関係を強固にすることができ，自分に与えられた役割を全うしようと責任感を自覚することが出来た．また，本格的な開発が始まってからスプリントによって難易度が高く，あまり進捗がよくない時のモチベーションの維持が難しかったが，私は対面でコ
ミュニケーションをとることでなんとか維持できたのではないかと考える．私はグループで開発
でメンバーとのコミュニケーションが一番重要なのではないかと強く感じ，学ぶことが出来た．今後，グループ活動の際にプロジェクト学習を思い出しながら行いたいと感じた．
（※文責: 荒戸大輝）

Group Report of 2020 SISP

- 37 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

第 11 章

今後の活動

本グループは，2021 年 2 月 15 日に秋葉原で開催されるプロジェクト学習課外発表会に参加する予定である．例年は秋葉原 UDX の 2 階「アキバ・スクエア」にて実施していたが，今年度はコロ
ナ禍における対面でのイベント自粛の動きからオンラインでの実施が決定した．各プロジェクトから代表者 3 名以内での参加が想定されているため，各グループのリーダーが参加して発表を行う．

Web 会議サービス「Zoom」経由での発表となるため，アプリケーションのデモやスライドなど，発表に用いる資料の見せ方を工夫して行う必要があると考えられる．
（※文責: 吉兼刃矢）Group Report of 2020 SISP

- 38 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

第 12 章まとめ

函館市の交通に関する問題を調査した結果，バス利用者がバス停で様々な問題を抱えていることが明らかになった． バス停で利用者が必要としている運賃や，これから乗車する系統のバス停情報などの不足から乗車前に不安を抱えているのではないかと考えた．そこで，本グループではそれらの不足した情報をバス停で素早く知ることができるスマートフォンアプリケーションの開発を行った．運賃やバス停のデータは Firebase というクラウドサービスを利用して管理し，主に Kotlin を用いて開発した．これにより，利用者の乗車前・乗車中の不安を解消することでバス利用者のユーザー体験を向上を目指した．1 年間の活動を通して，系統番号から検索するとその系統のバス停一
覧を見ることができる機能，出発地のバス停を選択するとそのバス停からの運賃の一覧を見ることができる機能を実装し，バス停での不足していた情報を提供することができた．
（※文責: 宮岡萌映）

Group Report of 2020 SISP

- 39 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

付録 A

アカデミックリンクのスライドGroup Report of 2020 SISP

- 40 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

Group Report of 2020 SISP

- 41 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

Group Report of 2020 SISP

- 42 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

Group Report of 2020 SISP

- 43 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

Group Report of 2020 SISP

- 44 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

付録 B

成果発表のポスター

Group Report of 2020 SISP

- 45 -

Group Number 1-B

Field Oriented System Design Learning by User’s Feedback 2020

参考文献
[1] シビックテックとは【用語解説】, https://www.sbbit.jp/article/cont1/32211 (2020.12.16
閲覧)[2] 時代が求める シビックテック 、その定義と活動の概要, https://internet.watch.impress.co.jp/docs/imreboot/1123303.html(2020.12.16 閲覧)[3] 函館バス株式会社｜会社概要, http://www.hakobus.co.jp/company/ (2020.12.16 閲覧)[4] 函 館 バ ス バ ス ロ ケ ー シ ョ ン シ ス テ ム (函 館 バ ス バ ス ロ ケ), https://hakobus.busnavigation.jp/wgsys/wgp/search.htm (2020.12.16 閲覧)[5] 市民の声｜函館市, https://www.city.hakodate.hokkaido.jp/docs/2014031700349/ (2020.
12.16 閲覧)
[6] Code for Hakodate – IT ×市民×まちづくり, https://codeforhakodate.org/ (2020.12.16
閲覧)[7] 公共交通｜函館市, https://www.city.hakodate.hokkaido.jp/docs/2014032000332/ (2020.
12.16 閲覧)[8] 交 通 機 関 別 利 用 者 の 推 移,https://www.city.hakodate.hokkaido.jp/docs/2015091500023/ﬁles/bunkatsu3.pdf, 35p (2020.12.16 閲覧)[9] Progate, https://prog-8.com/(2020.12.27 閲覧)[10] Firebase, https://ﬁrebase.google.com/?hl=ja (2020.12.16 閲覧)[11] アジャイル開発とは？主流の開発手法「スクラム」もくわしく解説！, https://udemy.benesse.co.jp/development/system/agile.html(2020.12.27 閲覧)[12] ペルソナ手法 (Persona)：日経クロステック Active, https://active.nikkeibp.co.jp/ atclact/activekw/121800153/ (2020.12.16 閲覧)Group Report of 2020 SISP

- 46 -

Group Number 1-B