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

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

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

グループ名
グループ AGroup NameGroup A
プロジェクト番号/Project No.

3-A

プロジェクトリーダ/Project Leader
佐々木虎太郎Kotaro Sasaki

グループリーダ/Group Leader
及川寛太

Kanta Oikawa

グループメンバ/Group Member
及川寛太
下村蒔里萌

Kanta Oikawa
Marimo Shimomura

大津武琉

Takeru Otsu

稲田敬介

Keisuke Inada

指導教員
伊藤恵 南部美砂子 奥野拓 元木環 石尾隆

AdvisorKei Ito Misako Nambu Taku Okuno Tamaki Motoki Takashi Ishio

提出日2024 年 1 月 17 日

Date of Submission
January 17, 2024

概要
本プロジェクトは，フィールド調査をもとにした活動で発見した問題を，IT を用いて解決する．これは，ユーザの仕事や生活をデザインし，地域や社会に貢献することが目的である．本
プロジェクトでは，アジャイル開発のスクラム手法を用いた．これは，迅速で柔軟な開発を行い，短期間の開発で効果的な成果を出すためである．14 名のメンバーが「交通」「小学校支援」「未来大生支援」のフィールドで活動した．本報告では交通グループについての報告を行う．
本グループでは，ブレインストーミングを行った中で発見したバスが使いにくいという問題を解決することを目的として活動してきた．具体的には，いつバス停に行けばいいのかがわからない，乗りたいバスに間に合うかどうかがわからないという問題が存在する．既存のバスロ
ケーションアプリは情報量が多く，この問題を解決できていなかった．また，バスの現在の正確な位置や，バス停への発着情報がわかりにくいという問題があった．そこで，情報量が絞られており，一目でバスと自分の位置関係がわかるアプリの開発を検討した．これまで，見やすい UI，洗練された機能についての考察，開発を行ってきた．今後は，引き続き開発を進め，学内でのリリースを目指しながら取り組んでいく．
キーワード

バス，遅延，情報量過多，交通，モバイルアプリ，ひとめぼれ，デザイン，体験，

アジャイル，スクラム，フィールド調査，函館（※文責: 稲田敬介）-i-Abstract
This project aims to solve the problems found in ﬁeld research using IT. This is todesign the user’s work and life, and contribute to the community and society. This
project used the Scrum method of agile development method. The purpose is to quickly
and ﬂexibly develop and achieve eﬀective results in a short period of development. 15
members worked in the ﬁelds of “transportation”, “elementary school support”, and“FUN students support”. This report is about eth transportation group.
The group aims to solve the problem of ineﬃcient use of buses found through brainstorming. Speciﬁcally, bus users have the problem of not knowing when to go to the bus
stop and whether you will be able to catch the bus you want. Existing bus location apps
have a lot of information and have not been able to solve this problem. In addition,
the current location of the bus and the departure and arrival information to the bus
stop are diﬃcult to understand . Therefore, we considered developing an app that has
a limited amount of information and can see the bus and your position relationship at a
glance. So far, we have been developing a user interface that is easy to see and reﬁnedfunctions. We will continue to work on the development with the aim of releasing within
the university.
KeywordBus, Delay, Information Overload, Transportation, Mobile App, Fall inLove at First Glance/Use, Design, Experience, Agile, Scrum, Field Research, Hakodate（※文責: 稲田敬介）- ii -

目次
第1章

はじめに

1

1.1

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

1

1.2

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

1

1.3

交通グループ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

プロダクト

2

2.1

アプリケーションのコンセプト . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.2

機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.2.1

住所を登録 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2.2.2

Time-Distance List と Route View . . . . . . . . . . . . . . . . . . . . .

3

2.2.3

Time-Distance View の詳細 . . . . . . . . . . . . . . . . . . . . . . . .

3

第2章

2.3

2.4

第3章

デザインシステム. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3.1

Colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3.2

Typographies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.3.3

Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3.4

Shapes and Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7システムの構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.4.1

クライアントアプリケーション . . . . . . . . . . . . . . . . . . . . . . .

9

2.4.2

Transit API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.4.3

Place API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

活動

10

3.1

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

10

3.2

アイデアの深掘り. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.3

アプリ名の決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.4

開発プラットフォームの決定. . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.5

メンバの役割決定. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.5.1

プロダクトオーナー . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.5.2

スクラムマスター . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.5.3

デザイナー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.5.4

iOS アプリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.5.5

Android アプリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.5.6

サーバサイドエンジニア . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.6

Git・GitHub の習得 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.7

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

14

3.7.1

プロトタイプ ver.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.7.2

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

14

3.7.3

プロトタイプ ver.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14- iii -

3.7.4

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

15

3.7.5

プロトタイプ ver.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

3.8

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

16

3.9

函館バス株式会社への訪問 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.10

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

17

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

17

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

19

開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.11.1 アジャイル開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

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

22

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

23

3.12

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

24

3.13

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

24

3.14

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

24

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

24

3.14.2 概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

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

26

第4章

今後の予定

28

第5章

まとめ

29

付録 A

使用した技術・ツール・知識

30

A.1

Adobe Illustrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

A.2

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

30

A.3

Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

A.4

FigJam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

A.5

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

30

A.6

Flutter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

A.7

GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

A.8

GitHub Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

A.9

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

31

A.10

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

31

A.11

GraphQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

A.12

gRPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

A.13

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

32

A.14

Notion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

A.15

PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

A.16

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

32

A.17

Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

A.18

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

32

資料

33

3.11

3.15

付録 B

- iv -

B.1

成果発表スライド. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

B.2

成果発表ポスター. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

参考文献

39

-v-

Field Oriented System Design Learning by Users’ Feedback 2023

第 1 章 はじめに
1.1

プロジェクトの立ち上げ

世の中にはニーズを十分に満たしていないシステムが存在する．これは，開発者が作るものとユーザが求めるものとの乖離が原因の 1 つであると考えられる．この問題を解決するためには，ユーザを理解してシステムを開発する必要があることから，開発者が現場に赴き，調査をして，ユーザから直接学ぶべきであると考えた．そこで「使ってもらって学ぶフィールド指向システムデザイン」を理念とするプロジェクトが始まった．
（※文責: 及川寛太）

1.2

プロジェクトの方針

本プロジェクトは，例年実際に現場に赴くフィールド調査とアジャイル開発手法の 1 つである，
スクラム手法 [5] を採用している．フィールド調査ではユーザの思考や行動などの，現場に行かな
いと分からないことを知ることができる．また，スクラムは，アジャイル開発の中でも少人数のチームで開発を行い，スプリントと呼ばれる固定の短い時間に区切って作業を進めるものである[5]．これはユーザのフィードバックを繰り返し受けて，改善する機会を何度も得ることができるため，本プロジェクトの「使ってもらって学ぶフィールド指向システムデザイン」という理念と合致する．以上のことから，今年度もフィールド調査とスクラム手法を採用することにした．
（※文責: 及川寛太）

1.3

交通グループ

発車予定時刻ギリギリにバス停についたときに，バスが今どこにいるのかがわからないことで，バスがもう行ってしまったのか， まだ来ていないのかがわからないという現状がある．また，現在存在する地図アプリや，乗換案内のアプリ，バス会社が提供しているバスロケーションシステム[3] によって，バスの運行に関する情報を手に入れることができる．しかし，それらの情報は大量で整理されておらず， 欲しい情報に辿り着くのが難しい．先述の問題を既存のアプリやシステムで解決することが困難であることから，本グループでは，バス利用者がストレスを抱えずにバスを利用できるようなアプリ開発を行うことにした．
（※文責: 及川寛太）

Group Report of 2023 SISP

-1-Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

第2章
2.1

プロダクト

アプリケーションのコンセプト

BuLo は，バスに乗り遅れたくないがバスを効率的に使いたいひとのためのバスロケーションア
プリである．従来のバスロケーションアプリや Google Maps などの地図アプリとは異なり，バスの位置や遅延情報をリアルタイムにわかりやすく把握することができる．また，本サービスは “
ひとめぼれ” するバスロケーションアプリをめざしている．我々は “ひとめぼれ” を以下の 2 つと考える．まず 1 つ目にアプリのデザインに対する “ひとめぼれ” である．これは本サービスを使うきっかけとなるものである．2 つ目にアプリ全体を通しての体験への “ひとめぼれ” である．これは本サービスを使い続けるきっかけになると考える．
（※文責: 下村蒔里萌）

2.2

機能

2.2.1

住所を登録

本サービスは自宅と職場の住所を登録する機能を搭載している．対象ユーザは通勤・通学にバスを利用する人であり，使用するルートは変わらないことが予測できるため，最初に住所を登録をすることで 2 回目以降は再度住所の検索をする手間を省いている．図 2.1 の左から 3 枚目の画面では，現在地の住所をサジェストしている．住所の入力では，キーワードに対しての予測をサジェストしている．

図 2.1

Group Report of 2023 SISP

住所を登録

-2-

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

2.2.2

Time-Distance List と Route View

ユーザが住所を登録したあと，ユーザがアプリを開いた際は図 2.2 の画面を表示する．図 2.2 の左側の画面は，後述する Time-Distance View の一覧である．一覧は，バスがユーザの乗車するバ
ス停に到着する順に表示される．図 2.2 の右側の画面は，各 Time-Distance View をタップした際に表示される Route View である．ここではタップした Time-Distance View と，ユーザとそのバスの現在地がマップ上に表示される．

図 2.2 Time-Distance View と Route View

2.2.3

Time-Distance View の詳細

Time-Distance View とは，ユーザの現在地・バスの現在地・バス停の 3 点を時間的グラフに表したものである．これにより，ユーザは「バスに間に合うかどうか」，「バス停でどのくらい待つか」がひとめでわかる．実装方法は図 2.3 に示す．また，図 2.3 では以下の状況を考えている．

• ユーザの目的地は自宅 (田家入口の近く)• 現在地からの最寄りのバス停ははこだて未来大学駅• ユーザが乗るバスは 55G• ユーザが自宅に行くまでにかかる料金は 220 円• バスは 5 分後にはこだて未来大学駅に到着する• 現在地からはこだて未来大学駅まで徒歩で 3 分かかる
• 自宅には 16:25 に到着するGroup Report of 2023 SISP

-3-Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

図 2.3 Time-Distance View

図 2.4 では，想定される Time-Distance View の例を示している．図 2.4 の左から，「ユーザがバスに安心して乗れる状態」「ユーザがバス停でかなり待つことが予想できるため，バス停以外の場
所で時間をつぶすことができる」「ユーザよりバスの方が先にバス停に到着するが，走ることでバスに乗ることができる」状態である．

図 2.4 Time-Distance View の例（※文責: 下村蒔里萌）

2.3

デザインシステム

本サービスでは，デザインシステムを導入している．Colors，Typographies，Icons，Shapes

and Others の 4 つのカテゴリに分けて，デザインシステムを構築した．

2.3.1

Colors本 サ ー ビ ス の カ ラ ー パ レ ッ ト は 図 2.5 の よ う に 設 定 し た ．16 進 数 の カ ラ ー コ ー ド (例:#FF3B30) に具体的な値を与え使いやすくしたプリミティブトークン (例: red) と，特定の用途別に定義したセマンティックトークン (例: alert) を定義している．Figma 上でのプロトタイプや実装では，セマンティックトークンを使用した．

Group Report of 2023 SISP

-4-Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

図 2.5

2.3.2

デザインシステム Colors

Typographies

本サービスのフォントは図 2.6 のように設定した．

Group Report of 2023 SISP

-5-Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

図 2.6Group Report of 2023 SISP

デザインシステム Typographies-6-

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

2.3.3

Icons

本サービスのアイコンは図 2.7 のように設定した．主に Material Symbols and Icons*1 を使用
し，足りないものは Pictogrammers*2 を使用した．

図 2.7

2.3.4

デザインシステム Icons

Shapes and Others

本サービスの形状とその他のデザインは図 2.8 のように設定した．Elevation や Blur は 2 つのレイヤー間の z 軸上の深度を表す．インターフェイス上の最も上位の要素をより強調することで，アクションの重要度を伝える．Corners は角丸を表し，4, 8, 16 と 3 種類の数字を用意し，コン
ポーネントの短辺に合わせて角丸の数値を可変する．角丸を使用した図形の中に，角丸を使用した
図形位がある場合は，外側の図形の角丸=内側の図形の角丸 + 内側の余白とする．

*1 https://fonts.google.com/icons*2 https://pictogrammers.com/

Group Report of 2023 SISP

-7-Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

図 2.8

デザインシステム Shapes and Others（※文責: 下村蒔里萌）

2.4

システムの構成

本サービスでは，マイクロサービスアーキテクチャを採用している．クライアントは，BFF(Backend for Frontend) を介して，バックエンドのマイクロサービスと通信する．バックエンドのマイクロサービス間は，gRPC を用いて通信する．アーキテクチャ図を図 2.9 に示す．

Group Report of 2023 SISP

-8-Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

図 2.9アーキテクチャ図

以下に，いくつかのマイクロサービスを抜粋して説明する．

2.4.1

クライアントアプリケーション

クライアントアプリケーションは，Flutter*3 を用いて開発した．Firebase Authentication*4 を用いて，ユーザの匿名認証を行う．生成された ID トークンを用いて，App Gateway と通信をする．App Gateway は，バックエンドのマイクロサービスと通信をして，クライアントが扱いやす
い形で，データを返却する．高度なビジネスロジックをフロントエンド側で持たず，できる限り
バックエンド側に切り出すようにした．

2.4.2

Transit API

本サービスで最も重要なマイクロサービスの 1 つである．クライアントアプリケーション
内の Time-Distance View や Route View を提供するために必要な情報を，GTFS-JP*5 およびGTFS-RT*6 のデータから計算する．

2.4.3

Place API地点を検索する際に，入力されたキーワードから，マッチする地点を検索するマイクロサービス
である．検索には，OpenStreetMap*7 のデータからジオコーディングを行う，Nominatim*8 というオープンソースのジオコーディングツールを使用した．
（※文責: 及川寛太）*3 https://ﬂutter.dev/*4 https://ﬁrebase.google.com/products/auth*5 https://www.gtfs.jp/*6 https://developers.google.com/transit/gtfs-realtime?hl=ja*7 https://www.openstreetmap.org/*8 https://nominatim.org/

Group Report of 2023 SISP

-9-Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

第3章
3.1

活動

ブレインストーミング

各々が開発したいアイデアを，Miro*1 を使用して，書き出した．(図 3.1) アイデアの例は以下である．

• 独り言を自動的に録音してテキスト化• 健康促進アプリ（地図上でこれまで行った場所を塗りつぶす）• 悩みがある人同士で会話できるもの• 店など様々な場所の混雑度チェックアプリ• 公共交通機関を携帯からリアルタイムに把握する• 1 日を可視化
各々違う色の付箋を使用し，KJ 法を使用し意見をまとめた．この活動ではさまざまな意見が挙げられたが，一番チームの共感を得たバス利用に関する問題について，今後の活動を絞った．

図 3.1

ブレインストーミング（※文責: 大津武琉）*1 https://miro.com/

Group Report of 2023 SISP

- 10 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

3.2

アイデアの深掘り

上記のブレインストーミングで挙げられたアイディアは煩雑なものであったため，実際に我々がバスを利用してきた中で不便に感じたことを考え，解決策への仮説を列挙した．以下はその例である．

• 交通系 IC カードを取り込み残高を表示• バス停までの徒歩時間表示• バスの時刻表表示• 地図上に表示するバスの数を変えることができる

図 3.2

アイデアの深掘り（※文責: 下村蒔里萌）

3.3

アプリ名の決定

各々が本サービスのコンセプトから考えられるサービス名を考えた．以下はその例である．

• BuLo (ブーロ) : Bus と Location の頭をとったもので，美しく (Beautiful) ，有用なユーザーインターフェース Useful (UserInterface) を持つライブ (Live) で最良のオプション (Option) である．バスロケーションシステムという意味も持つ．

• Loco (ロコ) :「ロケーション」と「どこ」をかけたもの．
• nuts (ナッツ) : No trouble with bus の各単語から 1 文字とって組み合わせたもの．
• バスらく: バスをらくに使えるアプリを略したもの．横文字のアプリ名がたくさんあるGroup Report of 2023 SISP

- 11 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023
が，ぱっと思い出しにくいため，名前からすぐにどんな用途かわかるものを提案した．

• ばすけん: バス検索を省略したもの．
上記のものでメンバ内で多数決をとった結果，BuLo (ブーロ) という名前に決定した．BuLo は

Bus Location の頭をとったものであり，美しく (Beautiful) ，有用なユーザーインターフェース
Useful (UserInterface) を持つライブ (Live) で最良のオプション (Option) であるバスロケーショ
ンシステムという意味も持つ．
（※文責: 下村蒔里萌）

3.4

開発プラットフォームの決定

まず，iOS と Android の 2 プラットフォームのネイティブアプリを並行して開発するか，クロスプラットフォームのネイティブアプリを開発するか，ということについて考えた．本グループでは 2 つの理由からクロスプラットフォーム開発に決定した．1 つ目の理由は，グループの規模が小さいことである．プラットフォームを分けると，各プラットフォーム 2〜3 人となってしまい各人の負担が大きい．2 つ目の理由は，本グループ全体の技術力が少ないことである．本グループには，過去に開発者としてアプリケーション開発を行ったことのある者が 1 人しかいない．ほかのメンバは経験がなく，1 から学習を始めるため，学習コストが大きい．以上の理由より，クロスプ
ラットフォームのネイティブアプリの開発を進める形となった．使用するフレームワークはクロスプラットフォームの代表例である Flutter*2 となった．
（※文責: 及川寛太）

3.5

メンバの役割決定

本グループでは 4 人のメンバで行っている．各メンバの役割については以下の通りである．

3.5.1

プロダクトオーナー

プロダクトオーナーはプロダクトの責任者であり，開発チームを活用して，そのプロダクトが生み出す価値を最大化する責任がある [5]．

• 及川 寛太

3.5.2

スクラムマスター

スクラム開発を円滑に進める役割がある．具体的に，アジャイルとスクラムの価値を維持し，ほかの人がスクラムを理解し実践するのを助ける，スクラムのミーティングをファシリテートする[1]．
• 大津 武琉*2 https://ﬂutter.dev/

Group Report of 2023 SISP

- 12 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

3.5.3

デザイナー

問題やユーザ像の分析より，アプリの UX や UI を考え，Figma*3 でプロトタイプを作成する．
実際にプログラムを書く際に必要な，レスポンシブな数値などのデザインシステムを作成する．

• 下村 蒔里萌

3.5.4

iOS アプリクロスプラットフォーム開発を行うが，iOS 独自の開発が必要な場合や問題が発生した場合に，優先的に対応にあたる．

• 及川 寛太• 下村 蒔里萌

3.5.5

Android アプリ

クロスプラットフォーム開発を行うが，Android 独自の開発が必要な場合や問題が発生した場合に，優先的に対応にあたる．

• 大津 武琉• 稲田敬介

3.5.6

サーバサイドエンジニア

バスの運行に関わるデータの収集・記録・管理を行う．また，クライアント側が必要とする情報を素早く提供するシステムを開発する．

• 及川 寛太• 大津 武琉（※文責: 稲田敬介）

3.6

Git・GitHub の習得

チーム開発を進める中で必要不可欠であるバージョン管理アプリの GitHub*4 の勉強会を行なった．メンバの過半数が GitHub を触ったことがなかったため，使用経験がある人から基本的な使用方法を教えてもらい，実際に Git*5 の機能である Clone，Commit，Push，Fetch，Merge，Pull を行なって GitHub について学んだ．
（※文責: 稲田敬介）*3 https://www.ﬁgma.com/*4 https://github.com/*5 https://git-scm.com/

Group Report of 2023 SISP

- 13 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

3.7

プロトタイプの作成

3.7.1

プロトタイプ ver.1

アプリのプロトタイプを Figma*6 を用いて作成した (図 3.3) ．左から 1 枚目の画面は自分の現在地を表示させている．2〜4 枚目は目的地を入力する画面となっている．5〜6 枚目は現在地から

2〜3 枚目で入力した場所までのバスを表示させる．7 枚目では 5〜6 枚目で選択したバスと自分との位置関係をグラフと地図で表示させる．

図 3.3

プロトタイプ ver.1

フィードバック

3.7.2

実際にプロジェクトメンバに Figma*7 で作成した図 3.3 のプロトタイプを使用してもらった．その際たくさんの質問，指摘，意見をいただいた．一番右の画面に対して，「下のバスと人との位置関係のグラフはいるのか？」，「現在動いているバスの位置情報と自分の位置情報が分かれば大体どれくらいにバス停にいけばいいのかわかるのでは？」という意見をいただいた．それらの意見に対し，ターゲットユーザを絞ることとした．
実際に得たフィードバックから，ターゲットユーザが定まっておらず，このアプリは何のため，
誰のためのアプリなのかがわからないことに気がついた．そこでチームでもう一度ターゲットユー
ザについて話し合い以下のように確立させた．

• 通勤通学にバスを使っていて，バスの乗降地点が毎回同じ• バスに乗り遅れたくない• バス停で待ちたくない• 10 代後半から 20 代前半

3.7.3

プロトタイプ ver.2

確立させたターゲットユーザに合う機能のみを実装するとしたため，合わせてプロトタイプを改善した．
図 3.3 のプロトタイプではユーザが毎回移動先・移動元を検索していたが，最初に登録をするこ*6 https://www.ﬁgma.com/*7 https://www.ﬁgma.com/

Group Report of 2023 SISP

- 14 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023とで，検索を毎回行う工程を省いた．通勤通学など，使用するバスが決まっているというユーザ像には，地点の検索は無駄な工程であった．
アプリ全体のデザインとしては，色やアイコンを改善した．具体的には，Time-Distace View のアイコンとその色を変更した．以前は人のアイコンが走っている人間のアイコンであり，赤色を使用していたため，焦りを与えていた．そのため，色を改善し，さらに同レベルの情報の色のコン
トラストを揃えた．また，Flutter*8 で開発をするにおいて，アイコンを Material Design*9 に統一
した．

Time-Distance View について，どの駅を使用するのか，何円かかるか，何時に到着するかなどの，ユーザが必要最低限と感じる情報を追加した．さらに，ウィジェット全体のサイズやレイアウ
トを改善した．
最後に，アプリを開いた時にランディング画面を設けることで，アプリ全体の概要や印象をユー
ザがわかりやすくなるよう改善した．

図 3.4

3.7.4

プロトタイプ ver.2

フィードバック

後述する中間発表会にて，プロトタイプ ver.2 についてのフィードバックをいただいた．その際たくさんの質問，指摘，意見をいただいた．図 3.4 の左から 7，8 枚目の画面に対して，「グラフの右端がバス停であることがわかりづらい」，左から 1〜3 枚目の画面に対して，「登録ボタンの視認性が悪い」という意見をいただいた．

3.7.5

プロトタイプ ver.3

図 3.5 の左から 1〜3 枚目の画面は初期画面である．4〜6 枚目は目的地を入力する画面となっている．7 枚目は現在地から 4〜3 枚目で入力した場所までのバスを表示させる．8 枚目では 4〜6 枚目で選択したバスと自分との位置関係をグラフと地図で表示させる．図 3.4 へのフィードバックをもとに，バスと現在地の時間的なグラフを改善した．また，図 3.5 の左から 4〜6 枚目の画面，すなわち目的地入力画面では，登録ボタンの視認性を向上させた．

*8 https://ﬂutter.dev/*9 https://m3.material.io/

Group Report of 2023 SISP

- 15 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

図 3.5

プロトタイプ ver.3（※文責: 下村蒔里萌）

3.8

リスク分析

プロジェクトを行ううえでリスクは必ず存在する．そのため，リスクに関して対策を講じておくことが必要である．我々は，リスクマネジメント [2] と題して，リスクに対して起こりうる被害の大きさや，どのように対策するのか等を考えた．まず初めにプロジェクトメンバを 3 グループに分け，それぞれのチームでメンバが持ち寄った起こりそうなリスクをまとめた．その後それぞれのリ
スクに対して，そのリスクが被る被害，発生確率，影響度，脅威，対策を考えた．脅威については発生確率，影響度を掛け合わせたものであり，脅威の値が大きいほど対策するべき優先度が高いものとなる．脅威に対して行うことができる対策には回避，軽減，転嫁，受容の 4 つがある．まとめたリスクの中でも，特に脅威の値が高いリスクと，それによる被害，対策の一部を表 3.1 に示す．
リスク

被害

対策
回避: コミュニケーションを図り，様子を知っておく

技術・知識不足

作業の停滞

軽減: 役割分担に余裕を持つ
転嫁: タスクを再分配する
回避: クラウド等に定期的にバックアップを取る

コンピュータの破損

データ紛失

軽減: バックアップ，データのバックアップ，
転嫁: メーカー保証，保険をかける

開発環境の不具合

開発ができない

軽減: 開発環境構築をドキュメント化しておく
回避: 人の目があるようなところで作業する

やる気不足

作業の停滞

軽減: モチベアップしそうな目標を立てる
転嫁: 気分転換に遊ぶ

データ消失

データ紛失

回避: クラウドサービスを利用する
表 3.1

Group Report of 2023 SISP

リスク分析

- 16 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023
このようにしてリスクを分析し，それに関して対策を事前に決めておくことで，迅速かつ最適な行動を被害発生時にとることができる．
（※文責: 稲田敬介）

3.9

函館バス株式会社への訪問

函館バス株式会社は，バス運行に関するデータを公開していない．本サービスで，函館バスのデータを利用すること，本サービスの紹介を目的に，6 月 16 日 (金) に函館バス株式会社に訪問した．そこで，「新しい観点からの機能で良い」というフィードバックをいただいた．

図 3.6

函館バス株式会社訪問時の様子（※文責: 大津武琉）

3.10

中間発表

3.10.1

中間発表資料の作成

7 月 7 日 (金) に行われる中間発表会に向けてスライド，メインポスター (図 3.7) ，サブポスター(図 3.8) を作成した．これらの資料に関して教員に繰り返しレビューをしていただき，より伝わりやすいものへと改良を重ねた．

Group Report of 2023 SISP

- 17 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

図 3.7Group Report of 2023 SISP

中間発表会メインポスター- 18 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

図 3.8

3.10.2

中間発表会サブポスター

中間発表会

7 月 7 日 (金) に発表会は行われた．そこで様々な質問や意見をいただいた．「首都圏と函館で同じ状況を想定していいのか？」「独自性を掲げているが UI についての独自性のみで機能についての独自性がみられない」という指摘をいただいた．これらの意見は，ターゲットユーザを絞り，合わ
せて実装する機能を絞った結果であると考えているため，次期バージョンにて，いただいた指摘をもとに改善を行う．

Group Report of 2023 SISP

- 19 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

図 3.9

中間発表会の様子（※文責: 下村蒔里萌）

3.11

開発

3.11.1

アジャイル開発

西村，永瀬，吉羽 (2020) によると，ソフトウェア開発において，目的を達成し，成果を最大化するための，以下のような進め方をアジャイル開発と呼ぶ [5]．

• 関係者は目的の達成のためにお互いに協力し合いながら進める• 一度にまとめてではなく少しずつ作り，早い段階から実際に動作するものを届け続けて評価を繰り返す• 利用者の反応や関係者からのフィードバックを継続的に得ながら，作っているもの自体
や計画を調整する
本サービスは，必要最小限の機能を実装した後，ユーザに使ってもらい，フィードバックを得る，というプロセスを繰り返しながら開発を行いたいという考えがあった．この考え，アジャイル開発を実現するために，我々は，アジャイル開発の手法の 1 つであるスクラムを用いて開発を行った．
西村ら (2020) は，以下のようなスクラムの特徴を挙げている [5]．

• 要求を価値やリスクや必要性を基準にして並べ替えて，その順にプロダクトを作ること
で成果を最大化します• スクラムでは固定の短い時間に区切って作業を進めます．固定の時間のことをタイムボックスと呼びます• 現在の状況や問題点を明らかにします．これを透明性と呼びますGroup Report of 2023 SISP

- 20 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023
• 定期的に進捗状況やつくっているプロダクトで期待されている成果を得られるのか，仕事の進め方に問題がないかどうかを確認します．これを検査と呼びます• やり方に問題があったり，もっとうまくできるよう方があったりすれば，やり方そのものを変えます．これを適応と呼びます
このようなスクラムは，5 つのイベント，3 つのロール，3 つの作成物から構成されているとしている [5]．
まず，プロダクトバックログ (作成物 1) を作成する．プロダクトバックログとは，実現したい
機能や，要求をリストアップし，実現したい順に並び替えたものである．常にメンテナンスして最新の状態を保つことが期待されている．
このプロダクトバックログを管理する責任を持つのは，プロダクトオーナー (ロール 1; 以下，PO) である．PO は，プロダクトの責任者であり，以下のような役割がある．
• プロダクトのビジョンを明らかにし，周りと共有する• おおよそのリソース計画を定める• 予算を管理する• 顧客，プロダクトの利用者や組織の関連部署などの関係者と，プロダクトバックログの項目の内容を確認したり，作る順番や実現時期を相談したりする• 既存のプロダクトバックログの項目の内容を最新の状態に更新する• プロダクトバックログの項目の内容を関係者が理解できるように説明する• プロダクトバックログ項目が完成しているかどうかを確認する
実際に作業を進めるのが，開発チーム (ロール 2) である．開発チームは，短く区切られたスプ
リント (イベント 1) ごとに開発を進める．スプリントプランニング (イベント 2) で，プロダクト
オーナーとともに，要求や実現可能性について議論する．
その後，スプリントバックログ (作成物 2) を作成する．スプリントバックログとは，スプリントで実現する機能や，要求をリストアップし，実現したい順に並び替えたものである．スプリント
バックログは，スプリントプランニングの終わりに作成される．
開発チームは，そのスプリントで，インクリメント (作成物 3) を作成する．インクリメントとは，スプリントで実現した機能のことである．開発チームは，スプリントゴール達成に向けて進んでいるかどうかを，デイリースクラム (イベント 3) で検査する．スプリントゴール達成に向けて昨日行ったこと，今日行うこと，障害となるものについて共有する．
スプリントの終わりに，スプリントレビュー (イベント 4) とスプリントレトロスペクティブ (イベント 5) を行う．スプリントレビューでは，スプリントで実現した機能をスクラムチーム外の関係者であるステークホルダに紹介し，フィードバックを得る．スプリントレトロスペクティブでは，開発チームのメンバが，スプリントでの作業の進め方や，やり方に問題がないかどうかを確認する．
これらのプロセスを円滑にまわして，プロダクトをうまく作れるように，PO や開発チームを支えるのが，スクラムマスター (ロール 3) である．
これらの基本原則を守りながら，開発を進めることで，アジャイル開発を実現した．
より効果的なアジャイル開発を行うために，デザインシステムの構築，スキーマ駆動開発を行なった．

Group Report of 2023 SISP

- 21 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

デザインシステム
本サービスは，簡潔で見やすく情報量の絞られたデザインを目指している．そのために，サービス内で一貫したデザインを目指している．また，アジャイル開発を行う上で，手戻りの少ない一貫性のある UI 改善を行うため，さらにはエンジニアとデザイナーの共通認識を図るために，デザインシステムを導入した．
（※文責: 下村蒔里萌）

スキーマ駆動開発

API のスキーマを元に，クライアントサイド，サーバサイド，デザイナーの 3 者間で，共通の認識を持ち，開発を進めた．デザイン変更に伴う，機能変更の際も，スキーマを元に話を進めるた
め，スムーズに柔軟な開発を進めることができた．
（※文責: 及川寛太）

3.11.2

使用した技術

Flutter
当初は，iOS アプリを Swift で，Android アプリを Kotlin で開発する予定であったが，開発期間が短いことや人数が少ないことから，1 つのコードベースで 2 つのプラットフォームをサポートできる，Flutter を採用した．

GraphQL
本サービスでは，当初，GraphQL サーバを介して，バックエンドのマイクロサービスと通信していた．GraphQL のデメリットや，マイクロサービス間では，gRPC による通信が行われていた
ことから，gRPC を用いて通信するように変更した．

gRPC
本サービスでは，マイクロサービス間通信，および，バックエンドのマイクロサービスとクライ
アント間通信に gRPC を用いている．

PostgreSQL
本サービスでは，GTFS-JP の静的データを保存し，各サービスからアクセスするために使用した．

Google Cloud Platform
本サービスの，データベースサーバは CloudSQL*10 ，バックエンドのマイクロサービスは Cloud

Run*11 上で稼働している．サーバレスサービスにより，サーバの管理にリソースを割くことなく，開発に集中することができる．

*10 https://cloud.google.com/sql/*11 https://cloud.google.com/run/Group Report of 2023 SISP

- 22 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023（※文責: 及川寛太）

3.11.3

使用したツール

Discord
本グループでは，コミュニケーションツールとして Discord*12 を使用した．テキストチャットと音声チャットを使用し，グループ内での進捗共有や，デイリースクラムを行った．開発中のコードに対しての質問や相談は，後述する GitHub や Figma のコメント機能を使用した．簡単な質問や相談，雑談については Discord を使用した．
（※文責: 下村蒔里萌）

Figma
本サービスのプロトタイプは Figma*13 で作成した．これは，Figma のオートレイアウトやコン
ポーネント機能を使用することで，プロトタイプの作成とエンジニアとの連携を効率化するためである．また，Figma の共有機能を使用し，開発に入る前にステークホルダーにプロトタイプを使用してもらい，フィードバックをもらった．
また，本サービスのデザインシステムの作成にも Figma を使用した．Figma のローカルバリア
ブルやローカルスタイル機能を使用することで，デザインシステムの作成とエンジニアとの連携を効率化した．Figma 内でデザインシステムとプロトタイプを完結させることで，プロトタイプの保守運用を効率化した．
（※文責: 下村蒔里萌）

GitHub Projects
本サービスのプロダクトバックログ，スプリントバックログ，詳細なタスク管理については，

GitHub Projects*14 を使用した．開発リポジトリの Issue や Pull Request と連携することで，見通しを確保し，開発の進捗管理を効率化した．
（※文責: 及川寛太）

NotionNotion*15 を使用して，ドキュメントの管理を行った．ミーティングの際の議事録や，知識の集約，日報の記録などを行なった．見通しを良くするために，ページのナビゲーションやレイアウトを工夫した．
（※文責: 及川寛太）*12 https://discord.com/*13 https://www.ﬁgma.com/*14 https://docs.github.com/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects*15 https://www.notion.so/Group Report of 2023 SISP

- 23 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

3.12

UCD ワークショップ

9 月 17 日 (日) ，9 月 18 日 (月) に希望するメンバで UCD ワークショップに参加した．UCD
ワークショップとは，高度 IT 人材を育成する産学協働の実践教育ネットワーク “enPiT”*16 の取り組みの 1 つである．このワークショップでは，大阪芸術大学のアートサイエンス学科で教鞭をとる准教授である大塚あゆみ氏を講師としてお招きし，人間中心のデザイン，ユーザ・センタード・
デザイン (それぞれの頭文字を取って UCD) の考え方とその設計方法を，短期集中の講義と演習を通して学んだ．演習では，20 年後の未来で使いたい製品・サービスを考え，シナリオ形式で発表
した．ここではグループメンバとコミュニケーションを円滑に図るために，ビジュアルシンキング
を用いてアイディアを共有した．城川 (2018) によると，ビジュアルシンキングとは，あたりまえなことに疑問をもって観察し，それを視覚的に記録することである [4]．また，ヒューマン・セン
タード・デザイン (HCD) を意識して避けるなど，随時アイデアを評価しながら洗練されたものにしていくまでの手順を実践した．
（※文責: 稲田敬介）

3.13

アカデミックリンク

11 月 3 日 (金) にはこだて高等教育機関合同研究発表会，通称 HAKODATE アカデミックリンクに参加した．HAKODATE アカデミックリンクは，函館市内にある 8 つの大学，短大，高専で日々行われる研究を市民・地元企業の方々にわかりやすく披露する場として提供されたものである．今年度の HAKODATE アカデミックリンク 2023 は函館アリーナで 4 年ぶりに対面で開催され，キャンパス・コンソーシアム函館に加盟する 8 校の学生をはじめ，函館市内の高校生や他地域の大学生などが参加した．ここでは，情報系である方やそうでない方など，様々な分野に進んだ
方々が参加していたのに加え，バスを普段の生活で使っている方，そうでない方など，様々な属性を持った方々がいらっしゃったため，多様な評価をいただくことができた．
（※文責: 稲田敬介）

3.14

成果発表会

3.14.1

成果発表会資料作成

12 月 8 日 (金) の成果発表会に使用するプロジェクト全体用のメインポスター，グループ発表用のグループポスター，発表スライドを作成した．これらの資料は教員に随時レビューを求め，わかりやすい資料になるよう改良を重ねた．

*16 https://www.enpit.jp/

Group Report of 2023 SISP

- 24 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

図 3.10Group Report of 2023 SISP

成果発表会メインポスター- 25 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

図 3.11

成果発表会サブポスター（※文責: 稲田敬介）

3.14.2

概要

12 月 8 日 (金) に成果発表会が行われ，そこでは未来大内外問わず，様々な方々からな意見や質問をいただくことができた．説明資料としてブースに配置していたポスター，デモ機，また，発表とそれに用いたスライド等を通して，「TDView にリスト表示されている分数を表すゲージの長さは，相対的に決めるのでは分かりづらいのではないか？」といった UI に関する意見や，「データの管理方法や精度はどのようになっているのか」など，データの取扱に関する質問をいただくことができた．またその一方で，「このアプリがリリースされたら使いたい」といったニーズが存在する
ことを確認できた．
（※文責: 稲田敬介）

3.15

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

12 月 9 日 (土) に Web と Zoom 上にて行われた，enPiT BizSysD 北海道・東北合同発表会に参加した．この発表会はいくつかの他大学と合同で行われ，全 8 チームのエントリーとなった．発表資料としては，前日に行われた成果発表会にて使用した資料をそのまま用いた．発表を通して教員・学生等様々な方々から評価をしていただくことができ，アイデア部門の最優秀賞，全体を通しての最優秀賞を受賞した．また，他大学の利用する技術，アイデア等を拝見できる貴重な機会として，充実した発表会となった．

Group Report of 2023 SISP

- 26 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023（※文責: 稲田敬介）

Group Report of 2023 SISP

- 27 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

第4章

今後の予定

今後の予定は，1 つ目に，複数事業者に対応させることを目指す．現状のバージョンでは函館バスのみしか対応していない．これを拡張し，函館市電や JR，また函館市以外のバス事業者にも対応させる．2 つ目に乗り換えに対応させることを目指す．バスを利用する上で目的地まで行くのに乗り換えが起こることは多くある．また，すでに「乗り換えに対応して欲しい」という指摘が多く寄せられているので乗り換えに対応させることをを目指す．3 つ目にパフォーマンスの向上を目指す．現状のバージョンでは，住所を検索する際や，路線を検索する際，結果が出るまでに時間がかかってしまっている．本サービスは「ひとめぼれ」をコンセプトとしているため，このレスポン
スの遅さを改善することを目指す．4 つ目に，Route View でのルートの表示を目指す．ユーザのルートの表示の目処は立っている．しかし，函館バスが提供しているデータの中に，ルートの情報がないため，バスのルートの表示の目処が立っていない．そこでどのようにしてルートを表示するかを考え，実装を行う．最後に，調査に基づいて UI/UX の改善を行う．すでに中間発表会や成果発表会で UI/UX の改善点を指摘された．それらの指摘に加えて，一般リリースをしたあとの，ユーザのフィードバックをもとに改善を行い，より使いやすいアプリにしていく．
（※文責: 大津武琉）

Group Report of 2023 SISP

- 28 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

第 5 章 まとめ本グループでは，バス利用者がストレスを抱えずにバスをできるようなアプリ「BuLo（ブーロ）」の開発を行った．最初にブレインストーミングを行い，メンバそれぞれがやりたいことについて話し合った．その中で，公共交通機関が利用しづらい問題を解決したいという意見が出た．その意見に対してメンバの多くが共感し，本グループの開発するプロダクトを決定した．次に，プロトタイ
プの作成を行い，プロジェクトメンバによるユーザテストを行なった．その結果，ターゲットユー
ザが定まっておらず，本サービスは何のため，誰のためのアプリなのかがわからないことに気がついた．そこで，本サービスについてもう一度考え直すことでターゲットユーザを確立させ，それをもとにプロトタイプを改善した．本サービスで函館バス株式会社のデータを利用するために，本サービスの紹介とデータ使用を願い出に，函館バス株式会社を訪問した．そこで，「新しい観点からの機能で良い」という感想をいただいた．その後，プロトタイプをもとにクライアントサイド，
サーバサイドそれぞれ開発を進めていき，中間発表会では，その時点での開発状況を発表し，プロ
トタイプを用いてデモを行なった．そこで，機能や UI についての指摘をいただき，それをもとに本サービスの改善を行なった．再びクライアントサイド，サーバサイドそれぞれで開発を進めた
後，はこだて高等教育機関合同研究発表会で本サービスについての発表を行なった．そこでは，情報系を専門としていない，市民や高校生などの一般の方々からも意見や質問をいただくことできた．その後，本サービスの開発を進め，成果発表会にて，本サービスの最終発表を行なった．そこ
では，未来大学関係者や函館市民，企業の方々と多くの方に本サービスに興味を持っていただくことができた．また，様々な観点からの意見や質問をいただくことができ，本サービスの改善に繋げることができた．現状では，本サービスの一般リリースを行うことがきていないが，様々な発表を通じて本サービスのニーズがあることを確認できているため，今後も開発を進めて一般リリースを目指していきたい．
（※文責: 大津武琉）

Group Report of 2023 SISP

- 29 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

付録 A
A.1

使用した技術・ツール・知識

Adobe Illustrator

Adobe Illustrator*1 は，ベクターベースのグラフィックを作成するソフトウェアである．ベク
ターベースで作成するため細かい図形などを扱いやすいというメリットがある．

A.2

Discord

Discord*2 は，コミュニケーションツールである．本グループの主な連絡手段として使用した．
プロジェクトに関わる連絡はもちろんのこと，日常生活で起こったことなどを Discord で共有することによりチームワークの向上を実現することができた．

A.3

DockerDocker*3 は，開発環境をコンテナとして扱うことができるツールである．本グループではサーバサイドの開発に Docker を用いた．Docker を用いることにより，デプロイを容易に行うことがで
きた．

A.4

FigJamFigJam*4 はオンラインでホワイトボードを利用できるツールである．Miro*5 で同じような機能を使うことができるが，Figma*6 の利用を開始したため，FigJam へと移行した．

A.5

Figma

Figma は，ホームページやアプリケーションなどのワイヤーフレームを作成できるツールである．中間発表スライドの作成，プロトタイプの作成，函館バス訪問の際に使用したスライドの作成，成果発表スライドの作成に使用した．コンポーネントやレスポンシブを意識し，ワイヤーフ
レームを作成することで，開発がスムーズになるようにした．

A.6

Flutter

Flutter*7 は，単一のコードベースから，複数のプラットフォームに向けたアプリケーションを構築できるフレームワークである．UI (ユーザインタフェース) を複数のプラットフォームで統一で*1 https://www.adobe.com/jp/products/illustrator.html*2 https://discord.com/*3 https://www.docker.com/*4 https://www.ﬁgma.com/*5 https://miro.com/*6 https://www.ﬁgma.com/*7 https://ﬂutter.dev/

Group Report of 2023 SISP

- 30 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023
きることなどのメリットがある．

A.7

GitHub

GitHub*8 は，ソースコードのバージョン管理システムである．このツールを用いることでチームでのアプリ開発を効率的に行うことができる．本グループでは開発サービスでそれぞれリポジト
リを作成し，アプリの開発を進めた．

A.8

GitHub Projects

GitHub Projects は，GitHub が提供するタスク管理ツールである．GitHub Projects に GitHubの Issue を紐付けることにより，タスク管理を行うことができる．本グループではタスクの管理に

GitHub Projects を用いることにより，タスクの進捗状況を把握することができた．

A.9

Google Cloud Platform

Google Cloud Platform*9 は，Google が運営する PaaS (Platform as a Service) である．

A.10

Google Drive

Google Drive*10 は，Google が提供するオンラインストレージサービスである．Google Driveを用いることにより手軽にファイルの共有を行うことができる．また昨年度のファイル履歴を見返すこともでき，資料作り，プロジェクトの進め方の参考とした．

A.11

GraphQL

GraphQL*11 は，API 用のクエリ言語であり，そのクエリを実行するためのランタイムである．
メリットは，クライアントが API に対して必要なリソースだけを要求することができること，可
読性の高いスキーマにより開発におけるコミュニケーションコストを下げることができることである．デメリットは，REST API や gRPC と比較して，実行速度が遅いことである．

A.12

gRPC

gRPC*12 は，ProtocolBuﬀers*13 を用いて通信する，RPC (Remote Procedure Call) フレームワークである．

*8 https://github.com/*9 https://cloud.google.com/*10 https://drive.google.com/*11 https://graphql.org/*12 https://grpc.io/*13 https://protobuf.dev/

Group Report of 2023 SISP

- 31 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

A.13

Miro

Miro は，オンラインでホワイトボードを利用できるツールである．ブレインストーミングなど，メンバーで一斉に意見を書くときに使用した．メンバーそれぞれの意見，考えを効率よく共有することができた．

A.14

Notion

本グループでは情報を管理するツールとして Notion*14 を使用した．議事録，日報，週報，プロ
ダクトバックログをそれぞれページにまとめることにより，情報を見やすくすることができた．

A.15

PostgreSQL

PostgreSQL*15 は，開発において使用した DBMS (Database Management System) である．
SQL を用いてデータの操作を行う，RDB (Relational Database) である．メリットは，拡張性，信頼性が高いことである．デメリットは，MySQL と比較して，実行速度が遅いことである．

A.16

Slack

Slack*16 は，コミュニケーションツールである．本グループでは主な連絡手段として Discord を利用していたが，本プロジェクトの主な連絡手段として使用した．細かくチャンネルを分けること
で情報がどこにあるかをわかりやすくすることができた．また，メンションという機能を利用する
ことにより教員，プロジェクトメンバー，TA とそれぞれに通知が届くようにすることで効率的な意思疎通を図ることができた．

A.17

Visual Studio CodeVisual Studio Code*17 は，マイクロソフトが提供するソースコードエディタである．

A.18

Xcode

Xcode*18 は，Apple が提供する統合開発環境である．本グループではコードエディタとして
Visual Studio Code を使用したが，iOS 端末での動作確認を行う際には，エミュレータを使用するために使用した．
（※文責: 大津武琉）*14 https://www.notion.so/*15 https://www.postgresql.org/*16 https://slack.com/*17 https://code.visualstudio.com/*18 https://developer.apple.com/jp/xcode/

Group Report of 2023 SISP

- 32 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

付録 B
B.1

資料

成果発表スライドGroup Report of 2023 SISP

- 33 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

Group Report of 2023 SISP

- 34 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

Group Report of 2023 SISP

- 35 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

Group Report of 2023 SISP

- 36 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

Group Report of 2023 SISP

- 37 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

B.2

成果発表ポスター（※文責: 下村蒔里萌）

Group Report of 2023 SISP

- 38 -

Group Number 3-A

Field Oriented System Design Learning by Users’ Feedback 2023

参考文献
[1] Zuzana Sochova. SCRUM MASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ. 翔泳社, 2020.

[2] 株式会社インターリスク総研. リスクマネジメント入門. https://www.ms-ins.com/pdf/
business/rm/rmguide.pdf. (Accessed on 01/16/2024).
[3] 国土交通省. バスロケーションシステム. https://www.mlit.go.jp/jidosha/sesaku/
koukyo/bus_loca/bus_loca.htm. (Accessed on 01/17/2024).
[4] 城川俊一. デザイン思考によるイノベーション. 経済論集= The Economic Review of Toyo
University, Vol. 43, No. 2, pp. 1–16, 2018.
[5] 西村直人, 永瀬美穂, 吉羽龍太郎. SCRUM BOOT CAMP THE BOOK スクラムチームではじめるアジャイル開発. 翔泳社, 2020.

Group Report of 2023 SISP

- 39 -

Group Number 3-A