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

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

Project Name
Field Oriented System Design Learning by Users’ Feedback

グループ名

町内会グループGroup Name
Neighborhood Association Group
プロジェクト番号/Project No.

03-A

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

伊藤泰斗

Taito Ito

グループリーダ/Group Leader
1014120

永井陽太

Youta Nagai

グループメンバ/Group Member
1014059

船木綾香

Ayaka Funaki

1014120

永井陽太

Youta Nagai

1014231

森島帆南

Honami Morishima

1014237

伊藤泰斗

Taito Ito1014253

横山新

Arata Yokoyama

指導教員

伊藤恵 南部美砂子 奥野拓

木塚あゆみ

原田泰

AdvisorKei Ito Misako Nambu Taku Okuno Ayumi Kizuka Yasushi Harada

提出日2017 年 1 月 18 日

Date of Submission
January 18, 2017

概要
本プロジェクトでは, フィールドを実際に調査してそこから問題点を見つける. そこで見つかった問題点を ICT を活用して解決する. それにより地域・社会に貢献することを目標として活動を行っている. 開発手法はアジャイル開発手法を用いる. 素早くアプリケーションを開発し, それに対するレビューを受けて問題解決の質をより高いものにしていく. 我々町内会グ
ループは, 陣川あさひ町会をフィールドに設定した. 函館市陣川町にある陣川あさひ町会 (以下, 町会とする) は 1,200 世帯中 1,000 世帯が加盟しており 1,000 人規模のイベントを開催しているなど, 積極的に活動をしている 2016 年 5 月中旬に実際に陣川あさひ町会へ調査を行い,どのような問題点があるのか, どのような要望があるのかをヒアリングした. ヒアリングした
結果, 陣川あさひ町会役員 (以降, 役員とする) が複数の SNS に投稿するのが大変であることや参加者の管理がうまくいっていないこと, イベントの緊急連絡ができていないという問題点があった. そこから我々が話し合って固めたアプリケーション案をティーチングアシスタントや担当教員, 役員の方々からレビューを受けながら, アプリケーションの開発を行った. 5 月 30
日の第 1 回提案では, 役員のイベント開催に関する問題を解決するため, カレンダー表示を中心としたイベント管理アプリケーションの提案をした. 次に 6 月 23 日の第 2 回提案では第 1
回提案を経て更に内容を精査して「イベント作成機能」, 「イベント参加申し込み機能」, 「イベント通知機能」を提案した. しかし 7 月 8 日に行われた中間報告会で, 町民の方々に使ってもらうための伝達手段について考慮していないといった課題が見つかった. そのため 8 月 6 日に催される納涼まつりにて町民にから, どのようにアプリケーションを導入してもらうかを見当して, レビューをいただく予定である. そして使ってもらって学ぶサイクルを繰り返すこと
で役員の要望にあったシステムデザインを行っていく.
キーワード

陣川あさひ町会, アジャイル開発, アプリケーション開発, レビュー, システムデザイン（※文責: 伊藤泰斗）-i-Abstract
In this project, at first, we investigate on the field and find problems from field survey.
We solve the problems found from field survey by ICT. Then we have action withthe goal of contributing to an area. We use Agile development process which is a
software development technique. We do swift app development, and develop higher
quality app by being reviewed for it. We are neighborhood association group. We set“Jinkawa asahi” neighborhood association as the field. The neighborhood associationhas 1,000 households per 1,200 households and acts positively. For example, it held a
1,000 people scale of events. We went to “Jinkawa asahi” neighborhood association tofind the ploblems and the requests which they have in May of 2016. As the results of
the interview, they have a lot of problems. For example, executives of “Jinkawa asahi”
neighborhood association post messages on many kinds of SNS but it is a hard workfor them. Then we developed an application with the review from executives,teachingassistants and teachers. At the first suggestion, we suggest the application to solve
the problems that executives held a event. At the second suggestion in May 30th, wesuggested the application which can make events, apply for events and give notice of
events. However, in the middle term session in July 8th, we found a problem. We
didn’t consider how to introduce our application for townsfolk. This is way, we’re going
to consider it and receive reviews by townsfolk at “Nouryo” Festival which will held at“Jinkawa asahi” neighborhood association in August 6th. Then we design systems by
the cycle of developping, receiving reviews and improving to develop the best thing to“Jinkawa asahi” neighborhood association.
KeywordJinkawa asahi neighborhood association, Agile development, Application
development, review, system design（※文責: 伊藤泰斗）- ii -

目次
第1章

背景・目的

1

1.1

陣川町について . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

町会が抱える問題. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.3

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

2

到達目標

3

第2章

2.1

第3章

3.1

3.2

3.3

3.4

本プロジェクトのおける目標. . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.1

目標 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.2

目標 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

開発プロセス
前期第１プロセス. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

3.1.1

ヒアリング及び第１回町会打ち合わせ . . . . . . . . . . . . . . . . . . . .

4

3.1.2

アプリケーションアイデアの考案 . . . . . . . . . . . . . . . . . . . . . . .

4

3.1.3

第 2 回町会打ち合わせ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

前期第２スプリント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

3.2.1

第１回月例レビュー会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

3.2.2

アプリケーションアイデアの改善 . . . . . . . . . . . . . . . . . . . . . . .

6

3.2.3

第 3 回町会打ち合わせ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

前期第３スプリント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

3.3.1

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

7

3.3.2

第１回集中実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

後期第 1 スプリント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

後期活動開始 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

後期第 2 スプリント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.5.1

第 4 回町会打ち合わせ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.5.2

じぷりデザインの改善 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.5.3

第２回月例レビュー会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

後期第 3 スプリント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.6.1

第２回集中開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.6.2

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

12

3.6.3

第 5 回町会打ち合わせ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

後期第 4 スプリント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.7.1

第 6 回町会打ち合わせ . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.7.2

最終成果発表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

町会のイベントへの参加 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

開発準備

16

3.4.1
3.5

3.6

3.7

3.8
第4章

4

- iii -

開発に利用したツールとその経緯 . . . . . . . . . . . . . . . . . . . . . . . . . .

16

4.1.1

Monaca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

4.1.2

ニフティクラウド mobile backend . . . . . . . . . . . . . . . . . . . . . .

16

4.1.3

Git/GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

4.1.4

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

17

4.1.5

Redmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

4.1.6

Trello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

4.1.7

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

18

環境構築 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

第5章

「じぷり」について20

5.1「じぷり」の概要. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

5.2

イベント管理機能. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

4.1

4.2

5.2.1

イベント管理機能の概要. . . . . . . . . . . . . . . . . . . . . . . . . . .

20

5.2.2

イベント情報の発信機能. . . . . . . . . . . . . . . . . . . . . . . . . . .

20

5.2.3

イベント情報の編集機能. . . . . . . . . . . . . . . . . . . . . . . . . . .

21

イベント参加申し込み機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

5.3.1

イベント参加申し込み機能の概要 . . . . . . . . . . . . . . . . . . . . . . .

22

5.3.2

イベント参加申し込み画面 . . . . . . . . . . . . . . . . . . . . . . . . . .

22

5.4

参加者管理機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

5.5

おしらせ管理機能

24

5.3

第6章

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

5.5.1

おしらせ管理機能の概要. . . . . . . . . . . . . . . . . . . . . . . . . . .

24

5.5.2

お知らせ作成画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

5.5.3

お知らせ削除 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

到達目標に対する評価

27

6.1

目標 1 についての評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

6.2

目標 2 についての評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

今後の展望

28

7.1

不具合の解消 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

7.2

無償サーバサービスの利用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

7.3

機能の追加と改善

28

第7章

第8章

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

振り返り

29

8.1

前期の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

8.2

後期の振り返り . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

学び

30

9.1

先方との打ち合わせ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

9.2

メンバ間の情報共有 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

9.3

システムコースとデザインコースの考え方の違い . . . . . . . . . . . . . . . . . .

31

9.4

スケジュール管理31

第9章. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

- iv -

付録 A

5 月 30 日提案資料

32

付録 B

6 月 23 日提案資料

37

付録 C

11 月 18 日提案資料

46

参考文献

57

-v-

Field Oriented System Design Learning by Users’ Feedback

第 1 章 背景・目的
1.1

陣川町について

陣川町は北海道函館市にあり (図 1.1), 人口はおよそ 3,300 人の町である. 陣川町には「陣川あさひ町会」がある. 町会は陣川町の 1,200 世帯中約 1,000 世帯が加入している. 夏には参加者が約1,000 人にもなる納涼まつりや冬にはウィンターフェスティバルを行うなど積極的に活動している.
また, これらのイベント情報を多くの人に知らせる為に町会役員が Facebook と LINE@を使い発信している. しかし, 積極的にイベントを開催する上で様々な問題を抱えている.

図 1.1

陣川町周辺地図（※文責: 船木綾香）

1.2

町会が抱える問題

町会のイベントを開催する上での問題点は主に以下の 6 つである.

• 情報内容に関する問題– Facebook や LINE@ではイベントに関するお知らせはできるが, 開催予定のイベントを一覧で見れない.

• 情報伝達手段に関する問題– イベントの情報を Facebook と LINE@に同一の内容を発信する手間がかかる.
– 町民のイベント申し込み方法が電話, FAX, メールの 3 つあり, イベント参加者の管理Group Report of 2016 SISP

-1-Group Number 03-A

Field Oriented System Design Learning by Users’ Feedbackに手間がかかる.

– Facebook では個人情報が漏れてしまうため参加申し込みができない.
– 役員だけで共有したい情報を町民に知られずに共有することが Facebook や LINE@ではできない.

– イベント当日が悪天候の場合, 参加者全員に対してイベントの中止, 延期などの連絡を迅速に行うことができない.
このように, 町会はイベントを開催する上で様々な問題を抱えている.
（※文責: 船木綾香）

1.3

目的

本グループでは「陣川あさひ町会のイベント開催に関する問題を解決するサービスの提供をする」ことを目的とした. 1.2 の通り, 町会ではイベントを開催する上で様々な問題がある. そこで本グループではそれらの問題を解決するアプリケーションを開発する.
（※文責: 船木綾香）

Group Report of 2016 SISP

-2-Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

第 2 章 到達目標
2.1

本プロジェクトのおける目標

陣川あさひ町会は 1.2 の通り, 様々な問題を抱えている. このことから, 本プロジェクトでは 2 つに分けて目標を設定した.

2.1.1

目標 1

１つ目の目標として, 本プロジェクトは, 陣川あさひ町会で開催されるイベントをシステム内で一覧で表示し, そのイベントに対して参加申し込みを可能にすることで, 町会側がシステム内で参加者の情報も管理できるようにすることと設定した. 前述の通り陣川あさひ町会は開催予定のイ
ベントを一覧で見ることができないという問題や, Facebook や LINE@ といった現在利用してる

SNS から参加申し込みすることができないという問題を抱えてる. そのためイベントの一覧表示と表示されたイベントへの参加申込みが可能になることで町民の SNS 間の移動という手間が省け,
町会側は参加者の情報が紙面ではなく, システムにまとめられた状態になる. そのため従来より参加者の管理が楽になり, 前述の問題を解決することが可能になると考えた.

2.1.2

目標 2

2 つ目の目標は, 老若男女問わず, 全ての年齢の方にとって使いやすいアプリにすることである.
前述の通り, 陣川あさひ町会は 1200 世帯中 1000 世帯が加盟しており、年齢の幅も大きいため, ある一定の年齢層だけが利用しやすいアプリを作成してしまうと, 他の年齢層が使いにくくなってしまう. このことから, 町内会のアプリがあるのに使われなくなる問題がある. そこでこの問題を未然に防ぐため, 町内会と定期的に会議を行いレビューと改善のサイクルを繰り返すことで, 前述の問題を解決することが可能になると考えた.

（※文責: 伊藤泰斗）Group Report of 2016 SISP

-3-Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

第3章

開発プロセス

3.1

前期第１プロセス

3.1.1

ヒアリング及び第１回町会打ち合わせ

目的
町会の現状を知り, 町会が抱えている問題を知ること.
手法
事前に, チーム内で町会に聞きたいことを洗い出し, 「質問したいことリスト」を作成した. その後, 5 月 12 日に町会の会長, 副会長, 総務部長, 会計部長, 青少年育成部副部長に対して, TA5 名と教員 4 名と共にヒアリングを行った.
結果
ヒアリングの結果, 町会役員から以下の要望が明らかになった.

• 開催予定のイベント一覧をカレンダーで表示してほしいという要望.
• iOS のアプリケーションを作ってほしいという要望.

• 幅広い年代の人が使いやすい UI にしてほしいという要望.
• 町会の役員の数を増やすため, 町内会を知ってもらいたい.

• イベント発信をした際に通知できる機能がほしいという要望.

• イベントスケジュールでイベントの削除, 作成, 更新ができるようにしてほしいという要望.
• イベントをタップしたらそのまま参加申し込みフォームに遷移してほしいという要望.
• 保護者の方の確認を得るためのポップアップ機能がほしいという要望.
• イベントで不参加になった人がわかるようにしてほしいという要望.

我々は, これらの要望を取り入れつつ 1.2 で述べたイベント開催に関する問題を解決するアプリ
ケーションを開発することとした.
（※文責: 永井陽太）

3.1.2

アプリケーションアイデアの考案1.2 で述べた問題と町会の要望を分析した結果, イベントに関する内容のものが多かった. そこでイベントに関係する 3 つの問題を解決することとした. 問題は「Facebook や LINE@ではイベントに関するお知らせはできるが, 開催予定のイベントを一覧で見れない」「Facebook では個人情報が漏れてしまうため参加申し込みができない」「役員だけで共有したい情報を町民に知られずに共有することが Facebook や LINE@ではできない」の 3 つである. これらの問題を解決するために,開催予定イベントのカレンダー表示機能, イベントへの参加申し込み機能, 参加申し込み者の情報を役員のみが見ることのできる機能, 役員のみが役員会議などのイベント情報を見ることのできる

Group Report of 2016 SISP

-4-Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback機能を考案した. アプリケーションアイデアの一部であるイベントカレンダー画面 (図 3.1), 参加
フォーム画面 (図 3.2), イベント作成画面 (図 3.3) の画面イメージを以下に示す.

図 3.1

イベントカレンダー画面

図 3.2

参加フォーム画面

図 3.3

イベント作成画面（※文責: 森島帆南）

3.1.3

第 2 回町会打ち合わせ

目的
我々の考案したアプリケーションの画面イメージ図をより良くするために, 画面イメージ図に対して町会の方々にレビューをいただくこと.
手法
アプリケーションの画面イメージを町会の方々にわかりやすく伝えるために, 資料を作成し, 5 月

30 日に町会の役員の方々に提出した.
結果
その結果, 以下の 4 つの要望をいただいた.

• イベント参加者の名簿を市役所に提出する際に参加者の情報として「名前」「性別」「年齢」「住所」「電話番号」が必要なので, 図 3.2 の入力フォームに 5 つの情報を追加してほしいという要望.

• アプリケーションをインストールした人が, すぐイベントを確認できるように起動時の画面
はログイン画面にしないでほしいという要望.

• 図 3.3 に「定員」の項目を追加してほしいという要望.

• より多くの人達にアプリケーションを利用していただくために, 様々なプラットフォームに対応したアプリケーションを作成してほしいという要望.

そこで, 我々は様々なプラットフォームに対応したアプリケーションを作成していくことを決定した.
（※文責: 船木綾香）

Group Report of 2016 SISP

-5-Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

3.2

前期第２スプリント

3.2.1

第１回月例レビュー会

月例レビュー会とは, プロジェクト内で, ３つのチームが現在の進捗報告と今後の展望を発表し,その発表内容に対して担当教員, TA, 他チームのメンバからレビューを受ける会である. ここで我々は, 現在のアプリケーションアイデア, つまり, 役員と町民でイベントカレンダーを共有する機能で本当に問題を解決できているのかと教員より指摘を受け, 3.1.3 にうけたレビュー内容も考慮し, アプリケーションについて再考し改善を図った.
（※文責: 船木綾香）

3.2.2

アプリケーションアイデアの改善

改善の結果, カレンダーを用いて開催予定のイベントを表示するのではなく, 開催予定のイベン
トを直近のものから順にリスト表示することにした. なぜなら, カレンダー表示では来月の予定な
どがひと目で確認することができないからである. アプリケーションアイデアの一部であるイベン
トリスト画面 (図 3.4), イベント作成画面 (図 3.5), 参加者リスト画面 (図 3.6) の画面イメージを以
下に示す.

図 3.4

イベントリスト画面

図 3.5

イベント作成画面

図 3.6

参加者リスト画面（※文責: 船木綾香）

3.2.3

第 3 回町会打ち合わせ

目的
我々の改善したアプリケーションの画面イメージ図をさらに良くするために, 画面イメージ図に対して再度, 町会の方々にレビューをいただくこと.

Group Report of 2016 SISP

-6-Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback
手法

3.1.3 と同様に, 改善したアプリケーションの画面イメージ図をまとめた資料を作成し, 6 月 23
日に町会の役員の方々に提出した.
結果
その結果, 以下の要望をいただいた.

• 図 3.4 でイベントをタップすると画面いっぱいにイベントの詳細情報が表示されるようにしてほしいという要望.

• 図 3.5 にアプリケーションの所有者全員に通知するか, しないかの項目を設けてほしいという要望.

• 町民が利用したくなるようなコンテンツを追加してほしいという要望.
町民が利用したくなるようなコンテンツとしては, 過去のイベントの写真が確認できる Web ペー
ジとじぷりとリンクさせることが例として挙げられる. また, アプリケーションの名前として「じんかわのあぷり」を省略して, 「じぷり」を提案し, 許可を得た. (以後, アプリケーションのことをじぷりと呼称する. )（※文責: 船木綾香）

3.3

前期第３スプリント

3.3.1

中間発表

7 月 8 日に行われた中間発表では, 各グループが行ってきた活動を詳細に伝え, 後期の活動に活かせるレビューをもらうことを目的とした. そのため全体ポスター 2 分, 各グループのポスターとデモを含めた発表を 12 分間並行して発表を行った.
発表方法についての評価と振り返り
以下に, 中間発表会で行ったアンケートの「発表技術について」の項目から, メンバ間で精査した結果, 最終成果発表にも取り入れたいコメントを抜粋した.

• デモがプロトタイプであることを伝えないと, 実装したものだと勘違いしてしまう.
• もう少しスラスラ話せていたらわかりやすかったと感じた.

上記より, 伝える情報とポスターセッションの練習の不足が伺える. しかし, 「とても喋りに安定感があるなと感じた」との評価も受けた. 最終成果発表の際にはすべての機能を実装したじぷりでデモを行い, ポスターセッションをする人全員がスラスラと話せるくらいに練習を行っていく.
発表内容についての評価と反省「発表内容について」の項目から後期の開発や発表において考慮すべきコメントを抜粋した.

• 陣川町民に使ってもらうためのプロモーションの方法を考えたほうが良い• クーポンなど, ユーザを得る工夫がほしい
Group Report of 2016 SISP

-7-Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback• ユーザにより沿って開発していく中で生起した出来事を大切に記述してほしい
上記より, 2 つの見落としが伺えた. 1 つ目はユーザに使ってもらうための考慮をしていなかったことである. メンバ全員が使ってもらえることを前提として考えていることである. しかし実際には使ってもらえることは前提ではないため, どのようにして使ってもらうのかを考える必要がある. 2
つ目は, じぷりにユーザにとって魅力的な優位性が必要であることである. 認知されていてもユー
ザにとって使いたいものでなければ使ってもらうことができない. そのため, 最終成果発表までにプロモーションの方法を考え, 使ってもらうための工夫をじぷりに追加することでユーザを獲得していきたい.
（※文責: 伊藤泰斗）

3.3.2

第１回集中実装

夏季休業期間中に, じぷりの主要な機能の内の「イベントの編集・削除機能」, 「お知らせの削除機能」, 「イベントへの参加申し込み機能」を実装した.
（※文責: 永井陽太）

3.4

後期第 1 スプリント

3.4.1

後期活動開始プロダクトバックログ・スプリントバックログの導入
前期のプロジェクト活動では, アジャイル開発手法の１つである, スクラム開発を行っていたものの, スプリントバックログや, プロダクトバックログの作成を行っていなかったので, 後期の活動からスプリントの始まりに, タスクを洗い出し, 担当を割り振り, 期日を設けてスプリントバックロ
グとプロダクトバックログを作成することを決定した.
チーム内のルール制定
後期の活動からはチーム運用ルールを制定して活動していくことになったので, メンバで話し合いを行い, ルールを制定した. 実際に制定されたルールは, 下記の様になっている.

1. 必ず定時の 18:00 に５人での作業を中断する
2. 専門用語を使う時は説明できようにする. また, 使いすぎないようにする
3. 最終報告書を作成のコストを削減するために, 議事録の最後に活動のまとめを書く
4. 2 週間に 1 回, 活動の KPTG 分析を行う
5. 議事録担当を横山, 永井, 森島, 船木, 伊藤の順で回す
6. 活動冒頭 10 分は個人タスクの進捗報告を行う
7. プロジェクト活動終了時間 40 分前に活動をやめて, 10 分間チーム内でまとめを行う
8. 町会との連絡には「jinnovation 会議」という LINE グループを利用する
このようなルールが制定された理由を以下に記述する.

1. 前期の活動で, 時間外活動がプロジェクト内の３チームで一番多かったので時間外活動を減Group Report of 2016 SISP

-8-Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback
らすため.

2. 前期の活動で, メンバ間で学習してきた内容に差異があるので, 専門用語を利用して, メンバ
を困惑させる場面が多々あったので, そのような場面を回避するため.

3. 前期の活動報告書作成にコストがかかってしまい, 開発に時間をかけることができなったので, 後期ではそのような事態を回避するため.

4. メンバの１人が夏季休業中のインターンシップで振り返りの際に kptg 分析を行っていたので, 実際に企業が行っていることをプロジェクト活動にも取り入れることで活動を振り返り,
次に繋げられると考えたため.

5. 前期の活動で議事録の担当をリーダーが覚えている限り均等になるように割り振っていたので, 個人の記憶に頼るのではなく, ルールに則ることで, より均等になるように割り振る
ため.

6. 前期の活動で, 誰がどのタスクをどこまで終わらせていて, どこに困っているのかを共有する時間が, プロジェクト活動時間外に行われていたので, メンバ同士のリアクションも遅れてしまい, 進捗を遅らせてしまっていたので, プロジェクト活動時間内に進捗報告を行うことで, メンバが困っていることを共有し迅速に解決することができるようにするため.

7. プロジェクト活動最後の 20 分間にプロジェクト内で各チームの進捗と次回の活動内容とそれまでの個人のタスクの報告を行っていたのだが, 前期の活動ではまとめの時間を明確に設けていなかったので, 最後の 20 分間の報告の際に, 次回やることや次回までのタスクを明確にして報告することができなかったので, そのような事態を回避するため.

8. 前期の活動で, 先方との連絡はリーダーを通して行われていたのだが, リーダーから先方との連絡の内容がメンバに十分に共有されておらず, 明確にしなければならない疑問点などが町会との打ち合わせの直前にメンバから挙げられて慌てて先方に確認するという場面が多々あったので, そのような事態を回避するため.

じぷり進捗状況の共有
その後, 夏季休業中にメンバ 1 人が実装してきた内容をメンバ及び TA で共有し, 改善点を洗い出した. その際に, UI が地味であり, 誰もが使いたくなるような UI で無いことが課題として挙げられた. したがって, UI のデザインの再設計を行うことが決定した.
（※文責: 森島帆南）

3.5

後期第 2 スプリント

3.5.1

第 4 回町会打ち合わせ

目的
第 4 回の打ち合わせでは, 実装済みの機能を確認してもらうことを目的とした.
手法

10 月 14 日に我々が実装してきた
1. 参加申し込み機能
2. 参加者リスト確認機能
Group Report of 2016 SISP

-9-Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback
3. イベント新規作成・編集・削除機能
4. お知らせ作成・削除機能
5. お知らせ表示機能
上記５つの機能のデモを行いながら実際に町会役員の方々に利用していただき, 5 つの機能の評価
シートに回答してもらうという形式をとった. 評価シートの内容としては, じぷりの各機能が第 3回町会打ち合わせで共有されたイメージ図通りであったかを”はい”か”いいえ”で回答してもらい,いいえと答えた人のみに, 具体的にどういった点がイメージ図と異なっていたかを記述してもらう内容とした.
結果
評価の結果として, イベントの作成・編集・削除機能について, イベント作成時にイベントの様子がわかるような画像を挿入できるようにしたいという意見が挙がった. また, 参加者リスト確認機
能について, 参加者の情報が名前と年齢だけでなく, 住所と電話番号を表示してほしいという意見が挙がった. また, お知らせ表示機能について, お知らせの見出しと本文と担当部署を分けて表示することはできないかという意見が挙がった. その他の機能に関しては概ねイメージ通りであるという意見をいただいた.
その他要望
今回の機能の確認とは別に, スマホの操作に慣れていない人の為に, 操作マニュアルを作成してほしいという要望も挙げられた.
（※文責: 永井陽太）

3.5.2

じぷりデザインの改善

第４回町会打ち合わせ時の UI は以下の図 3.7 である. この UI に対して, スマホの操作に慣れていない人にも使いやすく, 興味を引くような UI にしてほしいという要望を受けた. 具体的には, イ
ベント毎の違いを明確にすることに加え文字やレイアウト, 誤操作が起きないようにボタンの色を改善して視覚的な配慮を施してほしいなどが挙げられた. この意見を基に UI を改善したじぷりのイメージ図は以下の図 3.8, 図 3.9 である.

図 3.7

旧イベントリスト画面

Group Report of 2016 SISP

図 3.8

新イベント作成画面- 10 -

図 3.9

イベント詳細画面

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback
じぷりを利用する人の興味を引くためにイベントのチラシやイベントの詳細を見れるようにした. イベントの詳細画面ではチラシをタップすると拡大表示できるようにした. 視覚的な配慮を施すために, イベントのチラシやイベントの担当部署を色別に表示したり, イベント名の文字の大きさを変更しイベント毎の違いを明確にした. また, 誤操作が起きないようにイベント詳細を押してからイベントへの参加申し込みをするようにした. その結果, 役員の方からはわかりやすくなり操
作しやすくなったとの意見をいただいた.
（※文責: 船木綾香）

3.5.3

第２回月例レビュー会

第２回月例レビュー会で, 我々のチームは, 後期活動開始から第２回月例レビュー会までの活動の報告と, 開発途中のじぷりのデモと, 今後のスケジュールの報告を行った. 開発途中のじぷりの運用に対して, 利用しているニフティクラウド mobile backend で本番運用は可能であるのか, ニフ
ティクラウド mobile backend の性能の詳しい説明を先方に行うと良い, いつから運用を開始した
いのかを決めておいたほうが良いという意見をいただいた. また, じぷりの仕様について, 参加申し込みをする際に個人の情報を毎回入力するのはとても面倒であるのでそのような手間を省くような機能を用意した方が良いという意見や, 終了したイベントは確認できないようにしたほうが良いのではという意見をいただいた. そこで, 我々は運用に関してニフティクラウド mobile backend とその他のサーバサービスの性能を比較しメリット・デメリットを説明するための資料を作成することした. さらに, 運用も含めた今後のプロジェクトのスケジュールを立てて, 先方に説明するための資料を作成することとした.
（※文責: 伊藤泰斗）

3.6

後期第 3 スプリント

3.6.1

第２回集中開発

メンバのうち 2 名が, 11 月 9 日と 10 日に集中して開発を行った. 理由は 3 点ある. 1 点目は,翌週の 11 月 18 日に第 5 回町会打ち合わせが控えていたこと. 2 点目は, 12 日に HAKODATE
アカデミックリンク 2016 が控えていたこと. 3 点目は, 日々のプロジェクト学習時間の中では打ち合わせの調整や, 町会の要求の整理などグループとしての活動が多く, アプリの開発といった個
人作業を行う時間がほとんどなかったことである. また開発が進むに連れ, アプリの機能を担当するメンバとアプリの UI を担当するメンバが, 同じファイルを編集せざるを得なくなってしまい, 開発し辛い状況下にあった. この集中開発はメンバの 2 名が勝手にやったことである. 結果的にグループのためにはなったが, グループの予定にないこと, 仕様が定まっていない機能, 実装を前倒しした機能があり, 不要なバクの発生を招いてもおかしくはなかった. グループとして 2 名には, 感謝と同時に注意をした. この 2 日間で実装または, 改善したした 3 つの機能について述べる. 1 つ目は, 作成するお知らせに, 入力する情報の属性を 2 つ増やしたことである. 増やした２つの属性は, お知らせのタイトルと, お知らせを作成した担当部署である. 2 つ目は, お知らせリス
ト内の作成時刻の表記の変更である. 以前から作成した各お知らせの作成時刻は表示していたが,

2016-12-23T21:47:30.587+09:00 のように, ユーザには見づらい表記であったため, 2016/11/27
Group Report of 2016 SISP

- 11 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback
3:18 のように見やすく改善した. 3 つ目は, イベントリストとお知らせリストで, 各イベントとお知らせを作成した担当部署がはっきりわかるように, 部署ごとに色分けして着色した.
（※文責: 横山新）

3.6.2

HAKODATE アカデミックリンク 2016

HAKODATE アカデミックリンク 2016 とは
11 月 12 日に開催された, 函館市内 8 つの高等教育機関の学生や教員などの関係者による合同研
究成果発表会である. この HAKODATE アカデミックリンク 2016 には北海道教育大学函館校の教育学部の方や, 北海道大学水産学部の方など様々な分野の方が参加しており, 学生たちはそれぞれの研究テーマの連携や協力の可能性を探るために互いの研究について発表を行い, 交流する.
発表形式
中間発表とは異なり, プロトタイプを利用したデモを行うのではなく, 実際に開発途中のアプリ
でデモを行いながら, ポスターセッション形式で我々の活動やアプリについて発表を行った.
発表内容
アプリを開発するにいたった背景や, 開発過程, アプリの概要, 今後のスケジュールの説明を

HAKODATE アカデミックリンク 2016 の参加者に対して行った.
意見・評価
未来大の学生及び, 他大学の学生, 教員, 及び一般の参加者から様々な意見・評価をいただくことができた. 幾つかの意見・評価を以下に示す.

• 函館の地域に貢献することができるアプリを制作しているのはとても良い• 課題解決の提案をするだけでなく 実際にプロダクトを制作するのが良い• 利用しているサーバに関して, 負荷耐久テストを必ず行ったほうが良い（※文責: 伊藤泰斗）

3.6.3

第 5 回町会打ち合わせ目的

1. じぷりの進捗報告と完成イメージの共有
2. ニフティクラウド mobile backend を運用に利用することの了承を得る
3. 今後のスケジュールの了承を得る

手法

1. 11 月 18 日に完成イメージ図をまとめた資料を作成し, 先方へ共有した. また, 以下の（a）ログイン方法（b）イベントの編集・参加者リストの確認・参加申し込みをするための方法（c）参加者リスト表示方法

Group Report of 2016 SISP

- 12 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback（d）お知らせリスト表示方法（e）お知らせ作成画面
５つの変更点をデモを行いながら説明した.
さらに新規で追加された以下の（a）イベント詳細閲覧機能（b）参加者作成・削除機能（c）参加者リストの csv 形式出力機能
３つの機能についてもデモを行いながら説明した.

2. 先方に運用の説明をするために作成した資料を用いながら, まず, サーバについて概念的な説明を行った. その後, ニフティクラウド mobile backend の無償版, 有償版, その他のレンタルサーバの性能を比較しながら説明を行い, それぞれのメリットとデメリットを提示した.
その上でどのサービスを今後利用していくのかを町会役員の方々に決定していただいた.

3. 事前に作成したスケジュール説明資料を用いて, 我々が計画したスケジュールについて説明を行った. ちなみにそのスケジュールの内容は以下である.
（a）11/28 2 名の役員のスマートホンににじぷりをインストールする（b）12/2 １部の役員のスマートホンににじぷりをインストールする（c）1/11 20 じぷりの完成報告とストア公開に向けた打ち合わせ（d）1/31 ストア公開結果

1. じぷりへの新たな要望を以下に示す.
• 参加申し込みをする際に, 「キャンセルは町会に直接連絡してください」という１文を追加してほしいという要望• トップページに町会の住所, 連絡先をヒョ持してほしいという要望• 管理者を１０人してパスワードを１０個用意して, どの管理者が度のイベントを作成・編集したのかが確認できるようにしてほしいという要望• イベントの説明の文章が長くなったら「・・・」と省略するようにしてほしいという要望

2. じぷりの UI について, 以前よりもわかりやすく, 操作しやすくなったと評価をいただいた.
3. 運用に関して, ニフティクラウド mobile backend 無償版の性能に納得していただき, これからもニフティクラウド mobile backend で開発を行っても良いと許可をいただいた. しかし, 実際に運用が始まり利用者が 3000 人を超えそうな場合は, 町会にサーバを立ち上げるな
ど方法を考えてほしいという要望をいただいた.

4. スケジュールに関して, 我々が提案したスケジュールに納得していただき, 具体的な日付を決定することができた.
（※文責: 永井陽太）

Group Report of 2016 SISP

- 13 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

3.7

後期第 4 スプリント

3.7.1

第 6 回町会打ち合わせ

目的
２名の町会役員のスマートホンに, 実際にじぷりをインストールすることで, 役員限定公開に向けたテストを行うことを目的とした.
手法

Monaca クラウド上でじぷりをビルドし, Android 用の .apk ファイルを入手した後, 我々のノート PC を通して２名の役員うちの１人の Android スマートホンにじぷりをインストールした.

iOS 向けにも, じぷりのビルドを行い . ipa ファイルを入手しようと試みたが, Monaca クラウドの仕様上, ビルドを行うには,.ipa ファイルをインストールする iPhone の GUID を登録した証明書を発行する必要があるので不可能であった.
結果
じぷりへの新たな要望として• イベントリストを表示する際に, 更新日も表示されるようにしてほしいという要望• イベント作成時に, 「申し込み締め切り日」を入力できるようにしてほしいという要望• 作成日が自動で入力されて, イベント詳細確認画面で, 作成日を確認できるようにしてほしいという要望上記の内容が挙げられた. また, ビルドしたじぷりの動作ついては, 町会役員の Android スマート
ホンにおいて, じぷりの起動は可能であるものの, ニフティクラウド mobile backend との通信ができていないようで, イベントリストと, お知らせリストの表示ができない状態であった. 原因は特定できておらず, 今後調査していく予定である.
（※文責: 永井陽太）

3.7.2

最終成果発表発表形式

12/9 に行われた成果発表では今後の活動に活かすことを目的とした. 成果発表会では中間発表と同様にポスターセッション形式で, ポスターを２枚作成してデモを含めて 5 分程度の発表を行った.
発表内容

HAKODATE アカデミックリンク 2016 の内容に加え, 開発プロセスについて重点をおいた説明を行った.
発表方法に対する評価
発表方法について成果発表会で得られたアンケートの「発表方法」の項目から, 発表の理解のしやすさについてのコメントを抜粋した.

Group Report of 2016 SISP

- 14 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback• 一方的に話すのではなく, 聞いている人とコミュニケーションを取りながら話せていて, 内容が頭に入ってきた.

• デモを含めた一連の流れが簡潔にまとめられていた.
上記のコメントより, 中間発表に比べて全員がスラスラと説明できていたことが伺える. それに加え, 「簡潔にまとめられていた」や「内容が頭に入ってきた」と評価を受けることができた. そのため中間発表の反省点を改善することができた.
発表内容に対する評価
発表内容について, 成果発表会で得られたアンケートの「発表内容」の項目から, 今後の活動内
容について述べた内容についてのコメントを抜粋した.

• 中間よりも使いやすくなっていたが, まだまだ見た目のが改善できそう.
• 家族間で扱いやすいようにすると, より良くなるいいと思った.

上記のコメントより, 中間発表に比べて使ってもらうための改善をすることが少なからずできたことが伺える. しかし全てのユーザにとって使いやすいアプリケーションの開発を目標としている中,
見た目や使い勝手に関して好評化を受けることができなかったため, 今後はよりいっそう力をいれて取り組みたい. また機能面についての意見をたくさん受けることもできた. 依然として開発予定であるプッシュ機能やアカウント管理機能の開発ができていないため, これらの機能の開発が終わり次第, アンケートで受けた内容の反映をしていきたい. そうしてより多くのユーザに使われるア
プリケーションにしていく.
（※文責: 伊藤泰斗）

3.8

町会のイベントへの参加

我々は, より町会にとって有益なアプリを作成するために, 町会のことをより深く知る必要があると考えた. そこで我々は, 町会で行われたイベントに参加し, 町会の方々と交流をはかった. 参加
したイベントを以下に示す.

• 東照宮例大祭 6 月 18,19 日• 納涼まつり 8 月 6,7 日• 新年会 1 月 8 日

この様に, 町会と交流を深めていくことで, 町会の雰囲気や参加している人達の雰囲気, 生の声をお聞きすることができた.
（※文責: 永井陽太）

Group Report of 2016 SISP

- 15 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

第4章

開発準備

4.1

開発に利用したツールとその経緯

4.1.1

MonacaiOS と Android の両方のプラットフォームでアプリケーションを使いたいという町会の要
望を叶えるために, HTML5 ハイブリッドアプリを開発することとした. iOS と Android には,「WebView」と呼ばれるブラウザの機能を持つコンポーネントが組み込まれている [1]. HTML5
ハイブリッドアプリとは, 「WebView」に HTML と CSS, JavaScript を用いて開発するアプリ
ケーションである [1]. また, HTML5 ハイブリッドアプリの開発ツールのなかから Monaca を選択した. Monaca は Cordova というオープンソースのフレームワークを利用している [1]. また,Monaca には Monaca クラウド IDE, Monaca Localkit, Monaca CLI の 3 種類の開発環境が存在する [1]. Monaca クラウド IDE は, インターネットクラウド上で開発するため個人の開発環境に依存しない [1]. Monaca Localkit は, Monaca クラウド IDE とは異なり, 各メンバごとにローカルでの開発を可能とする [1]. Monaca CLI は, Monaca クラウド IDE が提供するサービスを, コマン
ドライン形式で利用することを可能にする [1]. いずれの開発環境においても, Monaca デバッカー
を用いて, デバックを行う (図 4.1).

図 4.1

4.1.2

Monaca での開発イメージ [2]ニフティクラウド mobile backend

じぷりの各情報を保存する場所として, mBaaS の１つであるニフティクラウド mobile back-end(以下, NCMB とする) を使用した. 使用した理由として, 以前このサービスを利用したことがあること, 他の mBaaS と比べて無料で利用可能な機能多いことが挙げられる. mBasS とは, サーGroup Report of 2016 SISP

- 16 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback
バの開発, 運用を必要とせずユーザから直接見えない部分の機能をアプリケーションに実装することを可能にするサービスである [3]. NCMB は, プッシュ通知, 会員管理と認証, SNS 連携などの機
能 [4] を提供しているサービスである (図 4.2).

図 4.2

4.1.3

ニフティクラウド mobile backend のサービス内容 [5]Git/GitHub

ソースコードのバージョン管理ツールとして, Git/GitHub を使用した. Git はファイルの変更
履歴をリポジトリと呼ばれる場所に保存する. そのため, 一度編集したファイルを過去の状態に復元することや, 編集箇所を表示することが可能となる [6]. リポジトリの種類は, メンバのローカル

PC 内に存在するローカルリポジトリと, インターネット上に存在するリモートリポジトリの 2 種類である [7]. リモートリポジトリでは, 各メンバのファイルの変更履歴を保存し, 共有する事が可能である. GitHub は, リモートリポジトリを提供するサービスの 1 つである. これにより, 複数のメンバで同時に開発を進めることが可能となった.

4.1.4

Slack

チーム内のコミュニケーションツールとして, Slack というチャットツールを使用した. Slack には数多くの特徴や機能が備わっているが, 本プロジェクトでは以下の 2 個の機能を主に使用した. 1
つ目は, 1 つの team に対して複数のチャンネルを作成することができる機能である. Slack はまず
最初に team というものを作成する. これは, team の名前は”2016 プロジェクト 03”など, 団体名

Group Report of 2016 SISP

- 17 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback
やプロジェクト名で名付ける. その後, 議題ごとに”#report”や”#design”などとチャンネルを作成することができる. これらの機能のお陰で, 1 つの話題について見逃すこと無く, 集中して話し合うことができた. また, ファイルやリンクの共有についても同様に, チャンネルごとに分けて行うことができた. 2 つ目は, GitHub などの他のサービスと連携することができる機能である. 連携先のGitHub に何らかの変更が生じた時に, 指定したチャンネルに通知が来るように設定した. この機
能のお陰でアプリケーションや報告書に変更があった場合に, グループメンバ全員が進捗の把握をしやすい環境を整えられた.

4.1.5

Redmineタスク管理ツールとして前期は, Redmine というオープンソースソフトウェアを使用した.

Redmine では, 発生したタスクごとにチケットと呼ばれるものを発行する. その後, タスクの進捗に合わせて各チケットを新規, フィードバック, 進行中（着手）, 進行中, 進行中（終了間際）, 作
業終了, レビュー中, 完了, 却下の 9 段階に分ける. また, チケットには担当者を指定し, チケットが更新される度に通知が来るようにウォッチャーと呼ばれるものに各メンバを設定する. これにより, 各メンバのタスクの進捗状況を把握することが可能となった. しかし, 機能の多さからなる操作の複雑さや, チケットの変更を受動的に知ることができないといった理由から, 後期は使用を見
送った。

4.1.6

Trello

タスク管理ツールとして, 後期から Trello を使用した. Trello では, タスクを「カード」として登録し, 「ボード」と呼ばれる場所で管理する [10]. その後, todo や done など好きな名前で「リスト」を作成し, 進捗状況に合わせて「カード」を移動することで, 進捗を管理する [10](図 4.3). また, ボードは個人で使うこともチームで共有することもできる [10]. 完了した「カード」はアーカイブする. 私たちは, 「カード」が移動されると, チームで使用している連絡ツールに通知が来るよ
うに設定をした. これにより, Redmine よりも迅速に進捗を把握することができた. さらに, 通知が来た後そのまま連絡ツールで, 話し合いをすることもできた.

4.1.7

Adobe Illustrator

ポスター作成と開発するアプリケーションのイメージ図の作成に Adobe Illustrator を使用した.

Adobe Illustrator はイラストやポスターなどデザインを描画するソフトウェアの 1 つである.
（※文責: 船木綾香）

4.2

環境構築

Monaca の 3 種類の開発環境の中から, オフラインで作業する可能性があることと普段使い慣れているエディターで開発することが望ましいため, Monaca CLI を選択した. Monaca の公式 Web
サイト [8] を見ながら, Monaca アカウントの作成, Monaca CLI のインストール, コマンドライ
ンから Monaca へのログイン, 新規プロジェクト作成の順で環境構築を行った. GitHub については, リモートリポジトリに機能やバグの修正ごとにブランチを作成し, そこにプッシュするようにした. また, リモートリポジトリに develop ブランチを作成した. この develop ブランチは, 各ブ

Group Report of 2016 SISP

- 18 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

図 4.3

実際に使用した Trello の「ボード」

ランチの内容をマージするためのブランチである. この develop ブランチを作成した理由は, 単体
テストを終えた各ブランチの内容を master ブランチにマージする前に, develop にマージすることで, 結合テストを行うためである. また, master の内容を常に安定した状態に保つという役割も担っている. Slack については, 教員が用意した team にメンバ全員が参加し, 町内会グループ専用の”#jinkawa”チャンネルを用意した. 前期に使用した Redmine は, 担当教員よりすでに構築済みのものを提供していただいた. 原則ウォッチャー [9] は, メンバ全員を登録することとした. 後期に使用した Trello は, 各自アカウントを作った後, ボードを共有することでタスク管理を行った. また, チームで利用しているチャンネルと連携させることで, チャンネル内でタスクの状況を把握できるようにした.
（※文責: 横山新）Group Report of 2016 SISP

- 19 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

第5章
5.1

「じぷり」について「じぷり」の概要

本プロジェクトで開発している HTML5 ハイブリッドアプリケーション「じぷり」は, 町会が企
画, 運営するイベント情報の発信, 発信されたイベントへの参加申し込み, 雨天延期などの町会役員による緊急連絡が可能となるアプリケーションである. このアプリケーションの名称は, 「陣川」という地域の名称と, 「アプリケーション」を組み合わせたものである. じぷりの目標は, 町会のイ
ベント開催に関する問題を解決することである. 主な使用場面は新規イベントの開催が決定してから, 当日のイベント終了までを想定している. 既存の他のアプリケーションと比較した際の優位性として, 1 年間を通して何度も町会と打ち合わせを重ねてきたため, 町会の求めていることだけを「じぷり」では組み込んでいる. 求めていることとは, 機能だけではなく, UI の面も含まれている.
詳細は次節以降で述べていく. 「じぷり」では対象とするユーザを, 町民, 役員, 管理者に属性分けをした. 管理者とは, 役員の中でもスマートフォンの操作に慣れている人のことである. このようにした理由は, 町会にヒアリングをした際に, 役員の中には上手くアプリケーションを操作できな
いと考えられるユーザがいるため, 誤った情報を発信するといったリスクを挙げられたからである.
そのため町会と相談した上で, 管理者を誰にするかを決めた. 「じぷり」では, アプリケーションの起動時に, ユーザが町民, 役員, 管理者のいずれかであるかを選択する. その結果からじぷりは, 町
民が利用する「一般モード」か, 役員が利用する「役員モード」か, 管理者が利用する「管理者モード」に画面の遷移を行う. 「一般モード」では, イベント情報とお知らせの閲覧と, イベントへの参加申し込みを行うことができる. 「役員モード」では, 「一般モード」に加えて役員会議など役員以外にとって必要のない情報も閲覧できる. 「管理者モード」では, イベントの管理機能, お知らせの管理機能, 参加者管理機能も行うことができる. 次節より「じぷり」の各機能について詳しく記述していく.

5.2

イベント管理機能

5.2.1

イベント管理機能の概要

イベント管理機能とは「管理者モード」の場合のみ利用可能な機能であり, イベント情報の発信と発信した情報の編集, 削除を可能としている. イベント管理機能を実装した理由は, イベントの情報を Facebook や LINE@など複数のサービスを使用して発信していた従来の方式から, じぷり 1
つですべてを賄うことを可能とするためである.

5.2.2

イベント情報の発信機能

イベント一覧リスト画面 (図 5.1(a)) からプラスの形をしたボタンを押すと, 発信するイベント情報の入力画面 (図 5.1(b)) に遷移する. この発信画面では, 入力する情報の属性としてイベント告知用の画像, 担当部名, イベント名, 日程, 場所, 開始時間, 終了時間, 定員, 詳細, 申込締切日, 役員のみに公開の 11 個に分けた. 役員のみに公開とは, 役員会議など町民にとっては知る必要のないイベ
ント情報を判別するために設けた. また, イベント一覧リスト画面 (図 5.1(a)) を見た時に, ひと目Group Report of 2016 SISP

- 20 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback
でどの部が担当しているのかをわかるようにしてほしいとの要望を受けたため, 担当部別に色を付けた. これは, 5.1 節（20 ページ）で記述した「じぷり」が持つ優位性の 1 つである. これら 11 個の属性は, ヒアリングを通して定まったものである. 情報を入力した後画面下の作成ボタンを押す
ことでイベント情報を発信することが可能となる.

(a) イベント一覧リスト画面

図 5.1

5.2.3

(b) イベント情報の入力画面

イベント情報の発信

イベント情報の編集機能

イベント一覧リスト画面 (図 5.2(a)) から任意のイベントを選択すると, イベント情報の詳細画面(図 5.2(b)) に遷移する. その後, 右上のメニューボタンからイベントの編集を選択することで, イ
ベント情報の編集画面 (図 5.2(c)) に選択する. イベント情報の編集画面では, イベント情報発信機
能と同様に, 11 種類の情報を編集した後画面下の更新するボタンを押すことで, イベント情報を再発信することが可能となる. また, イベント詳細画面の右上のメニューボタンから, イベント削除を選択することでイベント情報の削除が可能となる.

Group Report of 2016 SISP

- 21 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback(a) イベント一覧リスト画面(b) イベント情報の詳細画面

図 5.2(c) イベント情報の編集画面

イベント情報の編集（※文責: 横山新）

5.3

イベント参加申し込み機能

5.3.1

イベント参加申し込み機能の概要

イベント参加申し込み機能とは, 全てのモードで可能な機能であり, イベントへの参加申し込みを行うことを可能とした. 従来は, 町民がイベントへの参加申し込みをする際に, 電話, メール,

FAX 等多くの方法が存在していため, 町会は参加者の管理に時間を要していた. イベント参加申し込み機能を実装した理由は, この問題を解決し, 町会の負荷を軽減するためである.

5.3.2

イベント参加申し込み画面

イベント一覧リスト画面 (図 5.3(a)) から任意のイベントを選択すると, イベント情報の詳細画面(図 5.3(b)) に遷移する. その後, 画面下の参加を申し込むボタンを押すと, イベント参加申し込み
画面 (図 5.3(b)) に遷移する. イベント参加申し込み画面では, 入力する情報の属性として氏名, 性別, 年齢, 電話番号, 住所の 5 つに分けた. これら 5 つの属性は, ヒアリングを通して定まったものである. このように, 入力する情報の属性を限定していることも, 5.1 節（20 ページ）で記述した「じぷり」が持つ優位性の 1 つである. 情報を入力した後画面下の確定するボタンを押すことで参加申し込みが可能となる. また, 入力した情報を端末に保存することで, 次回以降の入力を省略することができるようにした。
（※文責: 横山新）Group Report of 2016 SISP

- 22 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback(a) イベント一覧リスト画面(b) イベント情報の詳細画面

図 5.3

5.4

(c) イベント参加申し込み画面

イベント参加申し込み

参加者管理機能

参加者リスト画面は「役員モード」でのみ閲覧可能な画面 (図 5.4(a)) であり, イベントごとの参加者一覧の表示や参加取り消しを可能としている. また, 右上のメニューボタンから追加参加ボタンを選択すると, 追加参加画面 (図 5.4(b)) に遷移する. 実装した理由は, 役員がじぷりを使用することができないユーザの代わりに参加申し込みすることや, イベントの申込み締め切り後に役員がユーザから連絡を受け, 代わりに参加参加申し込みを行えるようにするためである. また, 町会へのヒアリングの結果, 参加者リストを市役所に提出する必要があるイベントが存在することがわかった. これを楽に行えるように, 右上のメニューボタンからリスト出力を選択することで, 参加者リストを CSV ファイル形式で出力 (図 5.5) できるようにした. CSV ファイルは ncmb に保存され,ユーザは画面左上のその他から LINE や GoogleDrive, Dropbox などに保存 (図 5.4(c)) することができる. これもまた, 5.1 節（20 ページ）で記述した「じぷり」が持つ優位性の 1 つである.

Group Report of 2016 SISP

- 23 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback(a) 参加者リスト画面(b) 追加参加画面

図 5.4

図 5.5

(c)CSV の保存

参加者リスト

出力した CSV ファイル（※文責: 横山新）

5.5

お知らせ管理機能

5.5.1

お知らせ管理機能の概要

お知らせ管理機能とは「役員モード」での利用可能な機能であり, 町会からのお知らせを発信, 発
信したお知らせの削除を可能とした. これらは, 管理者のみが使うことを可能とした. お知らせ機
能を実装した理由は, 1.2 節でも記述したが過去のイベントで雨天中止の連絡ができなかったために, 参加者に風邪を引かせてしまったという事例があったことから, 町会からのお知らせを迅速に参加者に伝える必要があると判断したからである. またこの機能を用いて, 「今日は燃えるゴミが出せる日」「午後から雨が振るので, 洗濯物は取り込んでおいて下さい」といった生活情報の発信も行うことが可能となる.

Group Report of 2016 SISP

- 24 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

5.5.2

お知らせ作成画面

お知らせ一覧リスト画面 (図 5.6(a)) からプラスの形をしたボタンを押すと, お知らせの新規作成
画面 (図 5.6(b)) に遷移する. お知らせの新規作成画面では, 担当部名, タイトル, お知らせ内容を入力し役員のみに公開するか否かを選択した後画面下の作成するボタンを押すことでお知らせを発信することが可能となる. 担当部名については, 第 5.2.2 項（20 ページ）で記述したイベント情報の発信機能と同様に担当部ごとに色を付けた.

(a) お知らせ一覧リスト画面

図 5.6

Group Report of 2016 SISP(b) お知らせの新規作成画面

お知らせ作成- 25 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

5.5.3

お知らせ削除

お知らせ一覧リスト画面 (図 5.7) から削除したいお知らせを選択した後, 削除ボタンを選択して,発信したお知らせの削除を行う.

図 5.7

お知らせの削除（※文責: 横山新）Group Report of 2016 SISP

- 26 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

第 6 章 到達目標に対する評価
6.1

目標 1 についての評価

目標 1 は, 町会で開催されるイベントをシステム内で一覧で表示し, そのイベントに対して参加申し込みを可能にすることで, 町会側がシステム内で参加者の情報も管理できるようにすることとしていた. このイベント一覧表示や参加申し込み機能、参加者管理機能について, 発表会で得られた評価より, イベントを見てから参加するまでの過程がスムーズで便利だと思ったとの評価を得た.
以下に, 最終発表会で得られたアンケートの「よりアプリを使いやすくするにはどのようにしたらいいか？」の項目から, 機能についてのコメントを抜粋した.

• ログイン機能があるともっと便利になると思った.

• より家族間で扱いやすいようにするといいと思った.
これらのコメントから, 目標 1 についてはおおむね到達目標に到達しているものと評価できる.
アンケートではこれらの機能をより良くしていくためのアドバイスが多かった. そのため今後は成果発表会で得た評価を参考にして町民や町会にとって使いやすい機能の開発を進めていく.
（※文責: 伊藤泰斗）

6.2

目標 2 についての評価

目標 2 は, 老若男女問わず, 全ての年齢の方にとって使いやすいアプリにすることとしていた. この目標 2 について, 発表会で得られた評価より, 先方とたくさん打ち合わせをしている様子がアプリから伝わり, 洗練されていると感じたとの評価を得た. 以下に最終発表会で得られたアンケートの「発表内容」の項目から, 機能についてのコメントを抜粋した.

• 見た目がシンプルで迷わず操作できると思う.
• ヒアリングの効果が出ていると思う

これらのコメントのみ考慮すると目標 2 については到達目標に達成できていると評価できる. しかし「町民が使う画面か管理者が使う画面かわからない」や「予定イベントが見づらい」など課題の指摘も受けた. そのため, 両方のコメントを考慮すると目標 2 については到達目標に達成したと言えない部分が多く残ったと言える. 今後はアンケートで評価をいただいた項目を参考に町会や町民にとって使いやすい機能やデザインを考慮してリリースに向けて開発を進めていく.
（※文責: 伊藤泰斗）Group Report of 2016 SISP

- 27 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

第7章
7.1

今後の展望

不具合の解消11 月 18 日の町会打ち合わせにて役員に開発途中のじぷりを利用してもらったところ, iOS,
Android 共に動作が不安定であることがわかった. iOS では, イベントの新規作成をすることができるが, イベントの更新をすることができなかった. Android では, イベントの新規作成時に写真の追加をすることができなかった. 今後, それぞれの原因を特定して解消していく. 解消後は 1 月

11 日から 20 日の間で予定されている町会打ち合わせにじぷりを実際に利用してもらい, そこで出た要望や問題を解決し最終調整を行い, 1 月 31 日までに App Store と Google Play ストアでリリースする予定である.
（※文責: 船木綾香）

7.2

無償サーバサービスの利用

今後とも, 町会の意向により無料版の NCMB を利用していく. しかし, じぷりの NCMB へのリ
クエスト回数が無料の範囲を超えてしまう場合は, 無料版の NCMB では運用することが難しいた
め町会で独自のサーバを立ち上げる可能性がある.
（※文責: 船木綾香）

7.3

機能の追加と改善

私たちは, 陣川町民の多くの人にじぷりを長く利用してもらいたいと考えている. そのため, 今後
は今期に実装できなかった機能を追加していく予定である. 具体的な機能を以下に示す.

• イベントへの参加申し込みが来た時にイベント管理者へ通知が行われる機能• 特定のイベントの参加者のみにメッセージを送る機能, イベントへの参加者自身で参加の申し込みを取り消す機能• イベント参加者がイベントへの参加を取り消した場合, イベント管理者へ通知が行われる
機能• イベント開催する担当部署ごとに通知のオンオフを切り替える機能• イベントが新しく追加された時にじぷりを持っている全ユーザへ通知がされる機能• 自分が参加する予定のイベントを確認できる機能

また, 現在のじぷりはスマートフォンの操作に慣れていない人でも利用しやすい UI を目指して作っているが, 今後は幅広い年齢層の方や町民外の方にでも利用してもらえるような UI に改善していく予定である.
（※文責: 船木綾香）

Group Report of 2016 SISP

- 28 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

第 8 章 振り返り
8.1

前期の振り返り7 月 13 日にプロジェクト学習前期活動の振り返りを行った. はじめに, 5 月から我々が行ってきたこと, その際に感じたこと, 心に残ったアドバイスについてそれぞれ黄色, 緑, 赤の付箋に書き出した. その後, それらを 2 枚の模造紙に期間ごとに貼り付けてグループメンバ全員で見返した. その次に, 我々は今までの活動の中で良い点, 悪い点, これからやっていきたいことを話し合った. 良い点として, メンバ間で積極的にコミュニケーションを取り合うことでメンバの関係性を良好に保てたことが挙げられた. 悪い点として, メンバの予定を考慮することなくスケジュールの決定を行った点, 各作業に要する時間の想定が困難だったため, メンバに負担がかなり掛かってしまった点が挙げられた. これからやっていきたいこととしては, TA や教員等相談できる人がいるという環境を有効に活用することで, 活動の行き詰まる時間を削減することが挙げられた.
（※文責: 森島帆南）

8.2

後期の振り返り12 月 21 日に前期と後期を含めたプロジェクト活動全体で起きたことを深く掘り下げるために振り返りを行った. はじめに, 前期の KPT を小さい模造紙にまとめた. 次に, 後期のマイルストーン
ごとに, チームや個人で取り組んだこと, その時に思っていたこと, その要因をそれぞれ緑, 黄色,
赤の付箋に書き出し, 別の模造紙に貼り付けた. その後, メンバで貼り付けた情報を共有し, これまでの活動の良かった点, 悪かった点について話し合った. 良い点として, 以下の 2 点が挙げられた.

1. Trello を用いて, スプリントバックログとプロダクトバックログの作成・管理を行ったこと
2. 町会打ち合わせで議事録ドリブンを導入したこと
Trello を使い始めてから, 残りのタスクの数が可視化されて全体の進捗が把握しやすくなり, タス
クの管理の効率が良くなった. 議事録ドリブンを導入した理由は, 町会打ち合わせで要望がたくさん出てしまい, まとめるのが大変であったためである. 議事録ドリブンを導入したことで, その場で要望を整理し, 役員の方たちと共有しながら確認することができ, 普段より要望の整理にかかる時間を短縮することができた. 以上の 2 点がメンバ全員が後期の活動の中で特に良かったと感じることであった. また, メンバの 1 人からは, 自身で開発しているため, 操作性についてまったく気にしていなかったが, 実際に先方に使ってもらった時に操作に手間がかかっていた部分があることが発覚し, 改めて UI の大切さを身をもって感じたという意見があった. 悪い点として, 計画的なスケ
ジュールを組み立てられなかったことが 1 番の反省点に挙げられた. スケジュールを立てる際に,自分たちの実力が不明だったのでタスクの期日を定めることができなかった. しかし, 最終的な目標を立ててしっかりとした期日を設けて, それまでにタスクを終わらせる方針をとっていれば, ス
ケジュールが詰まらずに余裕をもって活動を行えたと考えられる.
（※文責: 森島帆南）Group Report of 2016 SISP

- 29 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

第9章
9.1

学び

先方との打ち合わせ先方と行ってきた打ち合わせに関しての 3 つの問題があった. 1 つ目は十分に打ち合わせの事前準備が行えていなかったことである. 事前に打ち合わせの目的を明確にして, 先方に必ず確認すべ
きことを定めておくことの重要性を学んだ. また, 先方に見せる資料のピアレビューを必ず全員で行うことも大切であると学んだ. 実際に, メンバの 1 人が作成した資料を確認しておらず, 打ち合
わせ直前に確認したところ, 説明不十分の部分があり, 資料訂正に時間を割かれてしまい, 打ち合わせの練習ができないことがあった. 事前に全員が資料に目を通していれば, 余裕を持ってより先方にとって理解しやすい資料を作成できる可能性があった.

2 つ目は, 打ち合わせの進め方の効率が悪いことである. 打ち合わせ中に先方から要望が数多く出てしまいまとめるのが大変であった. この問題から, 打ち合わせを進行しながら議事録を書いていく議事録ドリブンを導入した. 議事録ドリブンを導入したことで, 要望を整理することができる.
また, 打ち合わせの最後に先方の方を含め全員で打ち合わせの内容を振り返ることが簡単にできるようになり, 打ち合わせの時間も短縮することができた.

3 つ目は, 先方の要望の分析が不足していたことである. 前期では, 先方からの数多くの要望をメンバ全員ではなく, 各々で重要な部分をまとめようとしてしまった. 先方の要望の本質の分析不足
で先方にとって本当に使いやすいとは言えないものを提案してしまった. 教員からも先方にとって満足のできるものになっているのか見直した方が良いとのレビューを受けた. 我々はもう 1 度先方の要望を洗い出し, 先方の本当に求めているものを別のアプローチから解決できないか分析し直した. また, 全ての機能を書き出した後にそれぞれの優先順位をつけることで, 機能が可視化されて同時に進行した方が作業の効率が良くなる機能なども確認することができた.
（※文責: 森島帆南）

9.2

メンバ間の情報共有

チーム全体でのメンバ間の情報共有に関して, 2 つの問題が起きてしまった. 1 つ目は, チーム全
員での議論時に個人個人の認識に差異が生じてしまうことがあった. メンバ全員が個人のパソコンに向かって話している状態になっていることが多くあり, 同じ認識を持っているかを確認しないま
ま話を進めてしまったからである. 改善策としてスクリーンを用いての画面共有と席替えを行った.
スクリーンを用いて, 議論の進行に必要な画面を投影することで, 全員が同じ認識で議論を進めることができた. また, 席替えではリーダーが真ん中に座りメンバ全員に質問を振りながら議論を進めることで, メンバ間の認識に差異が生まれにくくすることができた.

2 つ目は, チーム全体のタスクの進捗が把握できていなかったことであった. 前期では, メンバ
個人個人の忙しさと期日を考慮せずにタスクを割り振ってしまい進捗に偏りが出てしまった. この反省点から, チーム全体のタスクの進捗が把握できていなかったことであったとわかった. 後期から, スプリントバッグログとプロダクトバッグログを Trello で管理し始め, プロジェクト全体のタ
スクが可視化されてお互いの役割を把握しやすくし進捗が遅れているメンバのサポートをしやすくGroup Report of 2016 SISP

- 30 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback
なった.
（※文責: 森島帆南）

9.3

システムコースとデザインコースの考え方の違い

本チームは情報システムコース 1 名と情報デザインコース 2 名と高度 ICT コース 2 名で構成されていたため, ２つの問題が起きてしまった. 1 つ目は, チーム全体のコミュニケーションが不足してしまったことであった. システム班とデザイン班に分かれて活動するようになり, チーム全体
でのコミュニケーションを取る時間が減ってしまった. 結果, わからないことを確認する機会がな
くわからないことや疑問におもっていることをそのままにしてしまっていた. そこで我々は, プロ
ジェクト活動の最初に前回までのタスクの進捗報告をすることを始め, 全体でのコミュニケーショ
ンをとりやすくすることでタスクでのわからないことを共有し解決することができた.

2 つ目は, システム班とデザイン班の意思疎通がうまく噛み合わないことであった. デザイン班
がじぷりの仕様が大きく変わる案を考え, システム班に変更内容を伝え承諾を得た. しかし, しばら
く経った後に仕様の変更内容がシステム班に正しく伝わっていないことがわかり, 説明し直さなけ
ればいけないことがあった. お互い得意とする分野が違い専門的な知識や考え方が大きく異なるためデザインの感覚の言葉選びではなく, システム班の人たちが理解しやすいように仕様変更内容の理由を伝えるべきであった. こうすることで, 専門的な知識が異なってもお互いの意思疎通ができることを学んだ.
（※文責: 森島帆南）

9.4

スケジュール管理

前期, 後期を通してスケジューリングの粗さが目立った. 自分たちの実力や, 忙しさを考慮せずにスケジュールを立てた結果リスケジューリングを余儀なくされる場面が多く見られた. さらに,リスケジューリングする際の各タスクの工期の見積もりが甘く, リスケジューリングを繰り返す場
面も多く見られた. また, リスケジューリングした後に町会との打ち合わせが企画されたり, 仕様の変更などが要求された結果スケジュールが大きく乱れた場面も見られた. これらの経験からスケ
ジュールを立てる時は, 各タスクに対して余裕を持って工期をを見積もることと, リスケジューリ
ングをする際は今あるタスクへの影響度などを考慮した上で, リスケジューリングすべきだということを学んだ. また, 作業に必要な時間, 担当者, 作業の洗い出し, 期限を設定しいつでも確認できるようにすることで, 忘れることなく作業に取り組むことができた.
（※文責: 森島帆南）Group Report of 2016 SISP

- 31 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

付録 A 5 月 30 日提案資料

Group Report of 2016 SISP

- 32 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 33 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 34 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 35 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 36 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

付録 B

6 月 23 日提案資料

Group Report of 2016 SISP

- 37 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 38 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 39 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 40 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 41 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 42 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 43 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 44 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 45 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

付録 C 11 月 18 日提案資料

Group Report of 2016 SISP

- 46 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 47 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 48 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 49 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 50 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 51 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 52 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 53 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 54 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 55 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

Group Report of 2016 SISP

- 56 -

Group Number 03-A

Field Oriented System Design Learning by Users’ Feedback

参考文献[1] 永井勝則. クラウドでできる HTML5 ハイブリッドアプリ開発 Cordova/Onsen UI で作る
iOS/Android 両対応アプリ (Monaca 公式ガイドブック) . 翔泳社, 2015.
[2] Monaca. Monaca Debugger HTML ハイブリッドアプリのテストを超効率化. 2016. https://ja.monaca.io/debugger.html (2016/7/20 アクセス)[3] NIFTY Cloud mobile backend. mBaaS とは. 不明. http://mb.cloud.nifty.com/about.
htm(2016/7/16 アクセス)[4] NIFTY Cloud mobile backend. 料 金. 不 明. http://mb.cloud.nifty.com/price.htm(2016/7/16 アクセス)[5] nifty. ニフティクラウド「mobile backend」のご紹介. 不明. http://lp.mb.cloud.nifty.
com/mbaaspaperdownload (2016/7/20 アクセス)[6] 大塚弘記. GitHub 実践入門 Pull Request による開発の変革. 技術評論社, 2014.
[7] サルでもわかる Git 入門 バージョン管理を使いこなそう . Git の基本 はじめに. 2014.
http://www.backlog.jp/git-guide/intro/intro1_1.html(2016/7/16 アクセス)[8] Monaca. Monaca CLI チ ュ ー ト リ ア ル. 2011. https://docs.monaca.io/ja/quick_start/cli/ (2016/7/16 アクセス)[9] Redline.JP. チ ケ ッ ト の ウ ォ ッ チ ャ ー. 不 明. http://redmine.jp/glossary/i/
issue-watcher/ (2016/7/16 アクセス)[10] SELECK. 無料＆日本語化！「Trello」でタスク管理がラクになる！使い方・始め方を解説します. 2016. https://seleck.cc/610 (2016/12/16 アクセス)

Group Report of 2016 SISP

- 57 -

Group Number 03-A