公立はこだて未来大学 2013 年度システム情報科学実習グ …sisp/old_report/2013/03/document03_B_C.pdfProject Name Regional Design with ICT - Construction of Useful

公立はこだて未来大学 2013 年度システム情報科学実習グループ報告書

Future University Hakodate 2013 System Information Science Practice

Group Report

プロジェクト名ICTで地域をデザインする

- お客様のための使えるシステム構築 -

Project Name

Regional Design with ICT

- Construction of Useful Systems for Customers -

グループ名イベント班

Group Name

Event Group

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

3-B/C

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

1011057 兵藤允彦 Masahiko Hyodo

グループリーダー/Group Leader

1011057 兵藤允彦 Masahiko Hyodo

グループメンバー/Group Member

1011019　西本光司 Kohji Nishimoto 1011029 工藤卓也　 Takuya Kudo

1011094　斉藤篤史 Atsushi Saito 1011108 小田大介　 Daisuke Oda

1011114　坂部翔一 Shouichi Sakabe 1011115 柴田健介　 Kensuke Shibata

1011129　京谷和明 Kazuaki Kyoya 1011177 齋藤創　　 Hajime Saito

1011219 菅野久樹 Hisaki Kanno

指導教員伊藤恵奥野拓大場みち子

Advisor

Kei Ito Taku Okuno Michiko Oba

提出日2014年１月 15日

Date of Submission

January 15, 2014

概要

　本プロジェクトでは，ICT(Information and Communication Technology)を用いて，シ

ステム開発の工程を体験し，実践的なスキルを学びながら，地域をデザインしていく．その手

段として，函館野外劇のチケット予約システムの開発と函館市近郊のイベント検索サービスの

構築を行う．本プロジェクトの目的は，これら 2つのシステムを提供することで市民活動の活

性化を図ることである．また，お客様に使って頂けるようなシステムを構築するスキルを学ぶ

ことである．

　本プロジェクトでは前期に模擬開発演習を行い，システム開発における要求分析や設計等の

一連の開発工程を経験する演習を行った．この演習は，主にシステムを構築するスキルを学ぶ

ために行われた．

　本グループでは，函館市近郊のイベント検索サービスの構築を行い，目的を達成する．現

在，函館市近郊では多くのイベントが開催されているが，これらの情報は充分に伝わっていな

いという問題がある．この仮説を踏まえ本グループでは，函館市近郊において多くのイベント

情報を発信している 3 施設へヒアリングに伺った．その結果から，3 施設の中で函館市近郊

のイベントを唯一Web上で網羅的に発信している函館市地域交流まちづくりセンター様にご

協力を頂き，函館市近郊のイベント検索サービス「HakoEve」を提供しようと考えた．この

「HakoEve」は，函館市地域交流まちづくりセンター様のWebサイトの一部として運用して頂

くことが決まり，今年度中に納品を行う．

キーワード ICT，イベント，イベント検索サービス，函館市地域交流まちづくりセンター，

HakoEve，模擬開発

（※文責: 兵藤允彦）

- i -

Abstract

　 In this project, we will design Hakodate using ICT(Information and CommunicationTechnology) while we experience the process of system development and acquire practi-cal skills. As a way to achieve this theme, we will develop a Ticket Reservation Systemof Hakodate Open-Air Theater and develop the service that provides the informationof events held in Hakodate. The purpose of this project is to support the region andtourists and moreover to restore vitality to the region by working on these two themes.Also, we will acquire the skill of developing useful systems for users.　 In the preceding term, we performed simulated development and practice to experi-ence a series of development processes such as requirement analysis or the design in thesystem development.　 Our group is developing the service. Various people can search information of eventsheld in Hakodate with this service. A lot of events are held in Hakodate. However, theseinformation can not conveyed well. So, to interview, we visited three organization thatconvey a lot of events information. As a result, we asked for cooperation of HakodateCommunity Design Center, and we suggested the service to this center. We namedthis service ”HakoEve”. This service will be operated by Hakodate Community DesignCenter. We pursue the goal of accomplish this service within this fiscal year.

Keyword ICT，Event，The service searching information of events held in Hakodate，Hakodate Community Design Center，Simulated Development

（※文責: 京谷和明）

- ii -

目次

第 1章はじめに 1

1.1 本プロジェクトについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 本プロジェクトの背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 本プロジェクトの目的と手段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

第 2章模擬開発演習 3

2.1 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 開発プロセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3.1 グループ B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3.2 グループ C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4 企業講師によるレビュー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4.1 テレビ会議 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4.2 第 1回企業講師レビュー会 . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.5 成果物 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5.1 グループ B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5.2 グループ C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.6 学び . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.6.1 グループ B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.6.2 グループ C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

第 3章函館市近郊のイベント検索サービスの構築 15

3.1 背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 プロセス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.1 現状調査 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.2 現状のまちセンの業務 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.3 問題の発見 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3.4 サービスの考案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.5 第 2回企業講師レビュー会 . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.6 提案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.7 設計 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.8 第 3回企業講師レビュー会 . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.9 実装 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.10 サービスの命名 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.11 第 4回企業講師レビュー会 . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.12 評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4 成果物 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

- iii -

3.4.1 プロジェクト憲章 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4.2 用語集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4.3 画面設計書 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.4 ユースケース図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4.5 業務フロー図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4.6 画面遷移図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4.7 テーブル定義書 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.8 ER図 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.9 HakoEve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.10 Facebookによる宣伝 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4.11 HakoEveロゴ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.5 本開発における学び . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.6 今後 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.6.1 仕様変更書 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.6.2 画面 UIの変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.6.3 推薦機能の変更 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.6.4 検索機能の有用性の確認 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

第 4章スケジュール 43

4.1 全体 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2 模擬開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.3 本開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

第 5章個人の活動 47

5.1 西本光司 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2 工藤卓也 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.3 兵藤允彦 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.4 斉藤篤史 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.5 小田大介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.6 坂部翔一 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.7 柴田健介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.8 京谷和明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.9 齋藤創 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.10 菅野久樹 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

第 6章プロジェクト全体の活動と学び 93

6.1 前期キックオフ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.2 CakePHP勉強会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.3 Redmineによるプロジェクト管理 . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.4 Subversionによるバージョン管理 . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.5 中間発表会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.6 オープンキャンパス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6.7 札幌オープンキャンパス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

- iv -

6.8 後期キックオフ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

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

6.10 最終成果発表会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

6.11 振り返り会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

第 7章おわりに 99

謝辞 101

付録A 新規習得技術 103

付録 B 活用した講義 105

参考文献 107

- v -

Regional Design with ICT - Construction of Useful Systems for Customers -

第 1 章はじめに

1.1 本プロジェクトについて

本プロジェクトは，函館野外劇のチケット予約システムの構築と，函館市近郊のイベント検索

サービスを提供することで，ICT を用いて地域をデザインすることを目的として活動を行ってい

る．また本プロジェクトでは，これらのサービスの開発を本開発と定義した．なお，本開発におい

て函館野外劇のチケット予約システムの構築を行うグループを野外劇班と定義し，函館市近郊のイ

ベント検索サービスの構築を行うグループをイベント班と定義した．

　本プロジェクトでは，プロジェクトメンバーを 5名ずつ，グループ A，グループ B，グループ C

の 3 グループに分けた．そして前期では，本開発を円滑に進めるため，あらかじめシステム開発

の一連の工程を経験することを目的として，面談予約管理システムの開発を行った．なお，本プロ

ジェクトではこれらのシステム開発を模擬開発演習と定義した．

　また，模擬開発演習で分かれたグループを基に，後期から本格的に本プロジェクトの目的を達成

するための本開発を行っている．

（※文責: 齋藤創）

1.2 本プロジェクトの背景

現在，多くの地域で ICTを用いた地域の活性化が注目されている．例えば長崎県の観光ポータ

ルサイトがある．インターネットの存在が以前にも増して重要な位置を占めるようになったため，

サイトの大幅リニューアルを実施した．その内容としては，市町の観光担当者がスポットやイベン

ト情報等を随時更新できるようにし，タイムリーな情報を発信，また県内の観光地をリアルに伝え

るため，歴史や自然などのテーマごとに制作した２分間の動画コンテンツ全 86作品を配信などで

ある．この効果として，サイトへのアクセスが増加した．年間総ページビューは前年から 36.2%伸

び，平均滞在時間は 1分 9秒伸びている．[6]

　現在，函館市ではインターネットを用いた情報発信が不十分である．例えば，函館市近郊のイベ

ント情報などである．そこで，本プロジェクトでは長崎県の例のように ICTを用いて地域を活性

化できるのではないかと考えた．

（※文責: 工藤卓也）

1.3 本プロジェクトの目的と手段

第 1章 2項より，本プロジェクトでは，お客様に使って頂けるようなシステムを構築するスキル

を学びながら，ICTを用いて，市民活動の活性化を目指すことを目的とした．また，この目的を達

成するための手段として函館野外劇のチケット予約システムの構築と函館市近郊のイベント検索

サービスの構築を行う．本グループでは，2つ目の手段である函館市近郊のイベント検索サービス

の構築に取り組んだ．さらに，目的達成のための技術習得として前期に模擬開発演習も行った．

Group Report of 2013 SISP - 1 - Group Number 3-B/C





第 2 章模擬開発演習

本開発をより効率よく行うために模擬開発演習を行った．


2.1 背景

本プロジェクトでは実際にお客様に使っていただけるシステムの構築を目指している．システム

の構築を行うには様々な知識，技術，経験が必要となる．例えば，システムの設計を行うためには，

ユースケース図や業務フロー図といった UML図の作成方法を知る必要がある．そして，実装を行

うためには，使用する言語やバージョン管理についての知識や技術が必要となる．また，開発を効

率よく行うためには，どの工程でどのようなドキュメントを作成する必要があるかや，チームで開

発する際のマネジメント方法など実際の経験も必要とされる．

　しかし，プロジェクト始動時のプロジェクトメンバーではお客様に使っていただけるシステムの

構築を行うための知識，技術，経験が不十分だと考えた．


2.2 目的

模擬開発演習の目的はシステム開発の基本的な流れを経験し，本開発で活かせる知識，技術を身

につけることである．これらの経験を活かし本開発をより効率的に行う．


2.3 開発プロセス

模擬開発演習を行うにあたり，プロジェクトメンバー 15人を 3つのグループに分けた．それぞ

れのプロジェクト担当教員にグループ毎の開発依頼者となって頂いた (図 2.1)．教員のみに編集機

能がある面談情報管理システムの機能拡張の依頼を受けた．そこで，3つのグループが別々に作業

を行い，学生が面談の予約を行なうことのできる面談予約管理システムを開発した．開発において

は，ウォーターフォールモデルを採用し，使用したフレームワークは PHPのフレームワークであ

る CakePHPである．また，タスク等の管理は Redmine，その他環境として Eclipse，Subversion，

LAMP(Linux，Apache，MySQL，PHP)を用いた．テストでは Seleniumを用いた．また開発に

あたって企業講師の方にアドバイスやレビューを頂いた．




図 2.1 模擬開発演習グループ分け

2.3.1 グループ B

開発依頼者から既存システムの機能拡張の依頼を受け，まず依頼者に既存システムの機能の確認

と追加機能の提案のためヒアリングを実施した．ヒアリングを基に要求定義書とユースケース記

述，ユースケース図を作成した．これを基に再度ヒアリングを行い，要求定義の了承を得た段階で

システム設計にとりかかった．テーブル定義書を作成した後，astah* professional を用いて，画

面遷移図，ER 図を作成した．設計が完了した後，動作を確認しながら CakePHPを用いて実装を

行った．この工程ではグループで用意したサーバにデプロイし，設計との整合性を取りながら面談

予約管理システムを完成させた．

（※文責: 柴田健介）

2.3.2 グループ C

面談予約管理システムの開発では，要求分析，設計，実装を行った．まず，要求分析のため依頼

者からのシステム開発依頼書の分析を行った．分析により得た情報を基に提案するシステムを考案

し，ヒアリングを行った．数回の提案とヒアリングの後，最終的に依頼者から提案システムの開発

の承認を得た．続いて，ユースケース図，業務フロー図，画面遷移図，要件定義書，テーブル定義



書の作成をした．これらのドキュメントを再び依頼者に提示し，承認を得ることで実装段階に移っ

た．実装では作成したドキュメントを基にデータベースを作成し，PHPのフレームワークである

CakePHPを用いてシステムの構築を行った．また，実装した機能の動作確認のため Seleniumを

用いたテストを行った．

（※文責: 小田大介）

2.4 企業講師によるレビュー

2.4.1 テレビ会議

6月 12日に企業講師の高森満様と木下実様のお二方に，模擬開発演習のグループ A，B，Cそれ

ぞれのグループが進捗報告を行った．その準備として各グループで作成した成果物を企業講師の方

に見せられる完成度にした．テレビ会議では，それぞれのグループごとに作成した成果物を見せな

がら模擬開発演習の進捗レビューを頂いた．

　その結果として，プレゼンテーションの仕方について，いきなり成果物を見せるのではなく，ど

のような経緯でどんなものを作ったのかの全体像を説明してから成果物の説明に入った方が聞きや

すいとご指摘を頂いた．

　次に，成果物については「要求定義書のビジネスプロセスを幾つかに分けたほうが良い」など，

ユースケース図や要求定義書，画面遷移図などのドキュメントをより良くする指摘を頂いた．

　また，ユースケース記述や業務フロー図作成の際に各メンバー全員の書式や用語の統一ができて

いないので，合わせる作業にまた時間が掛かってしまうというご指摘を頂いた．そのことについて

改善案を伺ったところ，「いきなり全員で作業を分担し作成するのではなく，まず誰かが叩き台を

作ってから，作業分担を行うほうが良い」などのアイデアを頂いた．

（※文責: 西本光司）

2.4.2 第 1回企業講師レビュー会

6月 28日に，企業講師の方々に実際に公立はこだて未来大学にお越し頂いて，作成したドキュ

メントや設計プロセスの問題点を指摘していただいた．「設計においては情報共有が重要で，その

ために Redmineを使用してしっかりとタスク管理を行うことが必要」といった，本開発で活かせ

るノウハウを学んだ．さらに，模擬開発演習で得た知識をどう本開発に活かしていくのかを一緒に

協議して頂いたことで，イベント班の活動方針を見直すことができた．加えて，中間発表会のスラ

イドについてもレビューして頂いた．その結果，スライドの全体の流れ，スライド 1枚の情報量な

どについて指摘を頂き，よりよいスライド作成につなげることができた．

（※文責: 坂部翔一）



2.5 成果物


以下はグループ B で作成した成果物である．そのうち，ユースケース図を図 2.2 に ER図を図

2.3 に画面遷移図を図 2.4 示す．

• 用語集• ヒアリング質問項目• 要求定義書• ユースケース図• 画面遷移図• ER図

• テーブル定義書• 面談予約管理システム



図 2.2 グループ Bのユースケース図

図 2.3 グループ Bの ER図



図 2.4 グループ Bの画面遷移図



以下はグループ Cで作成した成果物である．そのうち，ユースケース図を図 2.5，業務フロー図

を図 2.6，画面遷移図を図 2.7，面談予約管理システムを図 2.8に示す．

• 用語集• ヒアリング質問項目• ユースケース図• ユースケース記述• テーブル定義書• 業務フロー図• 画面遷移図• 要件定義書• 面談予約管理システム



図 2.5 グループ Cのユースケース図



図 2.6 グループ Cの業務フロー図



図 2.7 グループ Cの画面遷移図

図 2.8 グループ Cの面談予約管理システム




2.6 学び


本開発を行う前にチームでの開発の流れや開発の要求定義から運用までの開発の流れを実際に体

感した．グループ Bでは公立はこだて未来大学の大場みち子教授を実際の依頼者と見立てて開発

を行った．模擬開発では依頼者である大場みち子教授の面談予約管理システムの開発を行った．完

成した面談管理システムのトップ画面が図 2.9である．

　最初にスケジュールを立てて，細かい仕様の要求を伺うためにヒアリングを行うことにした．ヒ

アリングを行う前に依頼者にアポイントメントをとるところから始まり，ヒアリングの時に必要な

資料作りを行った．実際のヒアリングもグループ内でファシリテーターやファシリテーターの補

助係，記録係など役割分担をすることで効率よくヒアリングを進めることができた．その結果，グ

ループでの役割分担やヒアリングの一連の流れを学ぶ事が出来た．

　ヒアリングの結果を基にしてグループ全体でユースケースを考え，ユースケース図を作成した．

全体で作成したユースケース図をメンバーでユースケースごとに役割分担をし同時に要求定義書の

作成を進めた．TAの方のレビューを頂きながら完成し，もう一度依頼者の元に私たちの考えと依

頼者との考えとの差異が無いかどうかヒアリングを行った．差異があった部分と差異がない部分

がはっきりしたところでグループ Bは設計のフェーズに入り，全体で大まかな画面遷移やユース

ケースを決定し，役割分担し文書作成にとりかかった．適宜，グループ内で各自作成した文書をレ

ビューを行ったり，企業講師の方や TAの方からのレビューをしていただき成果物が完成した．そ

の結果，文書作成において，依頼者との差異が無いように確認すること，お互い作成してきた文書

をレビューし合うことを学んだ．

　次に実装のフェーズに入り，まずグループ全体でデータベースのテーブル名，コントローラー

ファイルや，ビューファイルの命名を行い作業分担を行った．実装体制としてリーダーが実装のサ

ポートにまわり他のメンバーが各機能ごとに一人ついて実装を行った．こまめに進捗状況を確認

し，実装が上手くいかないメンバーが発生した場合はリーダーがサポートし，一緒に実装を行っ

ていた．中間発表会の発表準備の作業や本開発の問題提起の作業の日程と重なり，ハードなスケ

ジュールでの実装となったが，ヒアリングでわかった最低限実装してほしい機能の面談タイトル

追加機能，面談候補日追加，ログイン・ログアウト機能と面談予約機能は実装完了することができ

た．その結果，お互いの進捗が予定通りに進まないこと，実装完了できた喜びを学ぶ事ができた．

　最後に納品会が行われ，依頼者の大場みち子教授にユースケース図と照らし合わせながら実装を

行った部分を確認してもらい，講評をいただきグループ全体で振り返りを行い，同時進行で行われ

ていた本開発の方に活かす事ができた．



図 2.9 グループ Bの面談管理システムトップ画面



グループ Cは，公立はこだて未来大学の伊藤恵准教授をお客様に見立てて模擬開発演習を行っ

た．1回目のヒアリングの際には，準備不足のせいで，何を聞くべきなのかが明確になっておらず

進行をスムーズに行うことができなかった．しかし，1回目の失敗から，私達は，あらかじめ話し

合いで使用するドキュメントをお客様に渡しておくことで進行をスムーズに進めることができるの

ではないかと考えた．例えば，私達の考えているシステムを分かりやすく示すために，ユースケー

ス図や業務フロー図を作成し，お客様とのヒアリングの際に使用した．このようにドキュメントを

用いて，考えを提示することで話し合いをスムーズに進めることができた．このことから，お客様

との話し合いにおけるドキュメントの重要性を実感することができた．

　ドキュメント作成においては，用語集を作成することで，使用する用語を統一しようとした．し

かし，作成した UML図において定義した用語以外の日本語の使い方が個人でバラバラになってし

まっていて修正に多くの時間を費やした．後期の本開発では，このようなことがなくなるような工

夫をすべきだと考えた．さらに，テレビ会議後の UML図の訂正において，図の一部を訂正した際

に，それに対応する別の図の一部を並行して訂正するといった作業を体験でき，UML図の１つの

作成方法を学ぶことができた．このような流れでユースケース図，ユースケース記述，テーブル定

義書，業務フロー図，画面遷移図といった UML図を完成させた．これらの UML図は，お客様と

の話し合いの際に役立っただけでなく，UML図を作成することでグループメンバーの意志が共有

され，実装をスムーズに進めることもできた．

　模擬開発演習では，本開発の大まかな流れだけでなく，上記のように本開発に活かすことのでき



る細かい経験を多く積むことができた．




第 3 章函館市近郊のイベント検索サービスの構築

本グループは模擬開発演習の体制を引き継ぎグループ B，Cの合計 10人で本開発を行った．本

開発では，函館市地域交流まちづくりセンター様 (以下，まちセン)が所有するイベント情報を利

用した函館市近郊のイベント情報検索サービス HakoEveの提案，開発を行った．

（※文責: 斉藤篤史）

3.1 背景

函館市近郊では市民団体などによって祭り，講座，体験会などの多くのイベントが毎月開催され

ている．例えば，「函館港イルミナシオン映画祭」というイベントは毎年 10月に金森ホールなどで

開催され，来年 20年目の節目を迎える大きなイベントである．

　現在，函館市近郊のイベント情報は函館市文化・スポーツ振興財団様 (以下，文化・スポーツ振

興財団)が発行している「ステップアップ」，函館市青年センター様 (以下，青年センター)が発行

している「ゆぅすかわらばん」といった広報誌で主に発信されている．それらの広報誌は図書館な

どの公共施設や小学校，大学などの教育機関，あるいはコンビニエンスストアといった商店など，

多くの施設に配布されている．

　また，文化・スポーツ振興財団のWebサイト内では，上記で述べた広報誌「ステップアップ」の

PDF版が閲覧・ダウンロードできるようになっている．

　しかし，函館にはこうしたインターネット上での情報発信媒体もあるものの，インターネットを

利用してイベント情報を探したい人に，うまく情報を伝えられていない現状がある．例えば，特定

のイベントを探すには向いていない形式である PDFで情報が配布されている，イベント情報ペー

ジは用意されているものの検索機能が搭載されていない，などである．


3.2 目的

本グループの目的は，インターネット上でのイベント情報検索のサービスを開発し，多くの人々

にイベント情報を知ってもらうことである．本グループの活動の背景にあった，インターネットを

利用してイベント情報を探したい人にうまく情報を伝えられていない現状がある．それを解決する

ために，いかにしてインターネットを利用して情報を探したい人に情報をうまく伝え，イベント情

報を知ってもらうことができるかについて焦点を当て，サービスのあり方やその機能について考察

し，提案，開発を行う．




3.3 プロセス

本開発において，本グループでは次のようなプロセスで活動を行った．


3.3.1 現状調査

本グループでは，函館市近郊のイベント情報に関する問題点を探るために，前期にインターネッ

トを用いて，イベント情報を発信している各Webサイトの調査を行った．そのWebサイトの調

査から，イベント情報を多く発信している 3つの団体，青年センター，文化・スポーツ振興財団，

まちセンへヒアリングに伺った．ヒアリング内容は，現在イベント情報をどのように収集・発信し

ているか，その収集・発信のプロセスで困っていることはないかを聞いた．また，イベント情報発

信サイトを自分たちで作るときのことも考えて，3つの団体がそれぞれ有しているイベント情報の

2次利用が可能かを聞いた．

　そのヒアリングの結果は，この 3つの団体は紙媒体でのイベント情報の発信に満足しており，イ

ンターネットを用いての発信は特に困っておらず，主にこの 3つの団体が主催しているイベントの

みを中心に発信していることが判明した．2次利用に関しては，文化・スポーツ振興財団はイベン

ト主催者との信頼関係があるため，各主催者に問い合わせて欲しいという回答を得られた．青年セ

ンターとまちセンは，全てのイベント情報の 2次利用は可能という回答を得られた．


3.3.2 現状のまちセンの業務

まちセンが，お客さんである市民の方からイベント情報に関する問い合わせがあった場合の現

状業務について説明する．このようなお客さんは，「今度開催される料理のセミナーなんでしたっ

け．」と言った曖昧な情報を基に質問をしてくる．これに対しまちセンの担当者は，現状手作業で

作成したチラシなどをまとめたファイルから，該当のイベント探すという作業を行っている．この

方法では，まちセンの担当者は近日開催される数多くのイベント情報をある程度把握している必要

があり，まちセンにとってかなりの負担になると考える．

（※文責: 菅野久樹）

3.3.3 問題の発見

上記のヒアリング結果を受けて，本グループでは，3つの団体の中で函館市近郊のイベント情報

を最も多く掲載しており，インターネット上でもイベントを多く発信しているまちセンに焦点を

絞って現状の問題点を挙げていくことにした．そのまちセンは現在，Webサイトを運用しており，

その中に市民活動情報というページがある．この市民活動情報では，函館市近郊のイベント情報を

月に約 120件掲載しており，その内容も充実している．

　しかし，本グループはまちセンのWebサイトでイベント情報を探す人にとっては複数の問題が

あるのではないかと考えた．例えばイベントのタイトルと開催日が一覧で表示されているだけであ



り，イベントの検索機能が無いため目的のイベントを探すことが難しい．また，数多くのイベント

情報が掲載されているのに，タイトルをクリックしないとイベントの中身を知ることができないの

で，興味のあるイベントに出会いにくいといったものが挙げられる．このことより，これらの問題

を ICTを用いて解決するために活動を行っていくことにした．


3.3.4 サービスの考案

上記で定義した問題点を解決するために，本グループでは現在まちセンが運営しているイベント

情報発信サイトに様々な検索機能と推薦機能を搭載したサービスの構築を決定した．このサービス

はイベントを探している人たちが自分にあった検索機能を使うことができ，また自分の趣味にあっ

たイベントに出会えるようなものである．そして，このサービスをまちセンに提案し，運用をお願

いしようと決定した．具体的なサービスの機能に関しては，私たちはまちセンにイベント情報を登

録してもらうサービスと，システムが自動でイベント情報を登録するサービスの 2 つの案を考え

た．

　 1つ目の案はイベント情報をキーワード検索，日付検索，タグ検索，地図・場所検索の 4つの検

索方法で検索できるサービスである．キーワード検索はイベント情報を文字列で探すことができ

る，日付検索はカレンダーの日付をクリックしてその日に開催されるイベントを知ることができ

る．タグ検索は分類分けされたカテゴリからイベントを探すことができる．地図・場所検索は地図

や場所を表示することでそこで開催されるイベントを知ることができる．そして，イベントの詳細

ページにはおすすめイベントとして，現在表示しているイベントと類似したイベントをページの下

部に表示する推薦機能がある．この案はまちセンのイベント情報ページ管理の業務内容が変更され

るものである．

　 2つ目の案は，新たな函館市近郊のイベント情報検索サイトを開設し，まちセンが運用している

イベント情報をスクレイピングでシステムが自動で取得し，そのWebサイトに掲載するものであ

る．このサービスもイベント情報を検索するのに検索機能を利用できる．しかし，1つ目の案にあ

るタグ関連の機能に関しては，タグはまちセンが主観で登録するものなので，この案では利用でき

ない．また，イベントの推薦はタグを用いて行われるものなので，推薦機能も利用できないもので

ある．この案はまちセンのイベント情報ページ管理の業務内容は変更されない．



9月 27日の後期キックオフ時に企業講師の方に公立はこだて未来大学へお越し頂き，本開発の

進捗報告を行った．進捗報告は，事前に用意するようにと言われたスライド資料を基に行った．そ

の進捗報告でスコープや提案したいサービスの説明が，曖昧になってしまった．それを受けて企業

講師の方から「グループメンバー全員が合意したスライドに見えない」というご指摘を頂き，そ

こで初めてグループ全体の情報共有が不足していることがわかった．またそれに関して，「人数が

多いのでテーマ毎にチームを分けるとよい」や，「会議の前に叩き台を作ってそれをグループメン

バー全員で見ながら進めていくとよい」といったご指摘を頂き，今後の本開発の活動方針について

見直すことができた．




3.3.6 提案

10月上旬にまちセンへヒアリングに伺い，考案した 2つのサービス案を提案した．提案を行う

前に，2 つの案の具体的な中身に関してや運用に関するお願いなどを記述したスライドを作成し

た．そのスライドを用いてまちセンの方にサービス案に関して説明したところ，1つ目の案だとイ

ベント情報の検索はまちセンの方々も利用できることから高い評価を受けた．

　具体的には 3.3.2で述べたことを，このサービスの多くの検索機能を利用することで，迅速に市

民に情報を提供でき，解決できることだった．さらに，イベントの登録に若干の手間が増えるが，

大量にあるイベント情報を多くの検索機能で探すことができることから 1つ目の案を採用して頂け

ることになった．このときに，実際に現在のイベント情報発信サイトとの差し替えと運用を検討し

て頂くことができ，12月までにサービスを完成させることを約束した．


3.3.7 設計

HakoEveを設計するにあたって，本グループはさらに 2つの班に分かれて活動を行うことにし

た．片方を機能班，もう片方をデータ班として，チームメンバーの得意分野を考慮した班構成を

行った．この班構成は模擬開発演習時の経験を活かしたものであった．機能班では，HakoEveの

機能の定義や設計を行う班であり，各種検索機能や管理者側の機能を定義し，ユースケース図や業

務フロー図や画面遷移図といった UMLを用いた設計を行った．データ班は HakoEveの内部処理

的な面の設計を行う班で，テーブルの定義を行い，ER図や SQL文の作成を行った．機能が変更

されるとテーブルも変更しなければならないことから，定期的に 2 つの班が集まって情報共有を

行った．



10月 18日にも企業講師の方にお越し頂いた．この日は本開発の活動中に何か困っていること，

相談事に対してアドバイスして頂くという流れで活動を行った．このときの本開発の活動は設計段

階に入っており，機能班とデータ班に分かれてそれぞれ活動していた．ここではデータ班の作成し

たドキュメントに関してレビューを頂き，データベース設計に関して「データ入力の際，主催者や

開催場所の情報が複数ある場合も考えられるが，それを実現しようとするとデータベースが複雑に

なり，納期までに完成できない可能性がある．だから，そういったものは予め入力に制限をかける

ような注釈を付け加えるなどして，データベースを複雑にしてしまわないようにしてはどうか」と

いうアドバイスを頂いた．それによってデータベースの構造を複雑にすることなく，結果として，

データベースの複雑化による作業量の増加や混乱を招かずに実装作業を行うことができた．また，

「図に関してほかの誰かに見せるのであれば，その図の見方がわかる注釈をつけたほうがよい」と

いうご指摘も頂き，注釈の重要性を理解した．




3.3.9 実装

プロジェクトリーダーはまず，模擬開発で知ったメンバーの得意分野を生かす班構成を考え，他

のメンバー 9 人をクライアント班とサーバ班という 2 つの班に分けた．プロジェクトリーダーは

どちらの班にも属さずに全体のまとめ，各班の進捗管理をしながらそれに応じたスケジュールの管

理を行った．どちらの班もペアプログラミングで実装中に起こる問題を効率よく解決できるような

体制を作った．また各メンバーのスケジュール管理のためのドキュメントを作成し，時間が合うと

きはいつでも活動できるような体制を作った．続いてタスクの洗い出しと締め切りの設定を行い，

今後の予定を明確にした．

　クライアント班は 4名である．コーディングの前にまちセンに提案を行った際に利用したスライ

ドを基に画面イメージ図を作成した．この図を基にまちセンがイベント情報を管理するための画

面，ユーザがイベントを探すための画面をそれぞれ 2名ずつで作成した．ペアプログラミングにお

いて進捗報告は頻繁に行うようにした．また実装に行き詰った際は，一人はリファレンスガイドか

ら解決方法を探し，もう一人はブログ記事から解決方法を探すように互いに違うサイトから解決策

を探した．また締め切りがまだ先のタスクにも目を向けることで，実装に必要な知識について学習

しながら作業を進めることができた．

　サーバ班は計 5名である．コーディングの前にあらかじめ実装にあたっての注意事項を定めた．

例えば，何をするメソッドなのかなどのコメントをソースコードに残す，またどんな変数名を使っ

たか，どんなメソッドを作ったのかコミット時にメッセージを残すというものである．


3.3.10 サービスの命名

11月 1日にまちセンに提案したサービス名が HakoEveに決定した．この決定に至るまでにサー

ビス名の検討をグループメンバー全員で行ってきた．まず，私たちはメンバーそれぞれでサービス

名の案を 3 つ以上考え，それをドキュメント上にまとめてメンバーの案を共有した．ドキュメン

ト上では計 42個の案が集まり，その後，それらの案の中から投票で候補を絞っていった．投票形

式は自分が良い案だと思うものを 1人 3つまで選ぶというものであり，その結果は，「Eさーち」，

「イベントであえ～る」，「はこイブ」の 3つの案に絞られた．これら 3つの案から，さらに良い案

だと思われるものを 1人 1つ選んで投票をし，最終的に「はこイブ」という案に決定した．「はこ

イブ」の案の由来として，函館をひらがなで表したはこだての「はこ」の部分と，Eventの頭 3文

字を取った Eveをカタカナにした「イブ」を合わせたものである．

　サービス名の案が「はこイブ」決定した後，次に私たちはその名称の表記の仕方について議論し

た．議論では，表記に関して様々な組み合わせを考え，ひらがなやカタカナだけで表記する案やひ

らがなとカタカナの組み合わせ，漢字とひらがな，漢字とカタカナを組み合わせる案，英文字で表

記する案など，考えられる案を網羅的に列挙した．列挙した後，サービス名の案を決定した際と同

様に投票によって表記の決定をした．投票ではまず表記としてふさわしいと思われるものを 1人 3

つまで選び候補を絞った．候補は「HakoEve」と「函 Eve」の 2つに絞られた．その後 2つの表記



から 1つを選び，その結果，私たちが開発するサービスの名称は「HakoEve」に決定した．この決

定に関しては，イベント班だけではなく TAの方，野外劇班にも協力して頂き，投票を行った．



11月 8日にも企業講師の方にお越し頂いた．この日は私たちが発表者として参加する「HAKO-

DATEアカデミックリンク 2013」の前日ということもあり，それに向けた発表練習に対してアド

バイスを頂いた．アドバイスでは，「発表中は体がふらふら動かないようにする」，「発表を聞くお

客さんの様子を見ながら，発表の仕方を変える」，「実際に iPadでまちセンのWebサイトを見せ

ながら発表することで，発表者自身が現状の問題点やその解決策について説明しやすくなり，発表

を聞くお客さんの理解も促しやすくなる．だから，そういうものも活用しながら発表すると良い」

というような，発表の際に役に立つことをアドバイスして頂いた．


3.3.12 評価

　 12月 1日にまちセンへ実装した HakoEveの進捗報告を行い，評価を頂いた．最初にスタッ

フの方に HakoEveが提供する機能の説明を行い，実際にイベント追加作業や主催者追加作業等を

して頂いた．

　 HakoEveを使って頂いた後に，各画面毎にご意見，ご要望を頂いた．例えば，トップ画面では

「新着情報が分かるような仕組みを作って欲しい」検索結果画面においては「イベント名をクリッ

クしても詳細を見れらるようにして欲しい」というものがあった．これらをドキュメントにまとめ

て今後行うべきタスクを明確化した．

　また訪問の際に，現在のまちセンのホームページを運用している団体があるということが分かっ

たので，HakoEveの運用の際はその団体とまちセンとイベント班の 3者で相談することになった．

またユーザテストについても協力して頂けることになったので，次回訪問時に，これらの件につい

て相談する予定である．


3.4 成果物

3.4.1 プロジェクト憲章

本グループでは，プロジェクトの背景と目的，内容など，この 1年間で実施したプロジェクトの

定義をメンバー全員で明確化するためにプロジェクト憲章を作成した．このドキュメントの作成方

法として，まず，メンバーの 2人が叩き台を作成し，そのたたき台をメンバー全員でレビューを行

いその内容で相違はないかどうかを確認し合った．レビューを踏まえ，修正を行い，メンバー全員

の承認がとれた段階で本グループのプロジェクト憲章として完成した．

　次に，プロジェクト憲章の具体的な内容について説明する．まず，本グループで行う函館市近郊

のイベント検索サービスの構築を行うまでに至った背景と活動の目的を明記した．また，本グルー



プの大まかなスケジュールや活動内容に関しても明記した．さらに，本グループが考案するサービ

スの提供先兼運用者であるまちセンやサービスを利用する人 (以下，エンドユーザ)に関して，こ

のサービスを提供することで考えられるメリット，提供する機能に関する明記もした．

　このプロジェクト憲章を作成したことで，本グループでのプロジェクトの定義が明確化し．その

後の作業をスムーズに行うことができた．会議等でメンバー間のプロジェクトに対する考え方の相

違が発生したとき，このプロジェクト憲章を見直すことで相違が解消されたという経緯がある．こ

のようにプロジェクトに関する方針を可視化したことで，プロジェクトが円滑に進んだ．


3.4.2 用語集

メンバー間の用語の使い方が統一できておらず，意味の取り違いが発生してしまった．例えば，

「ユーザ」と言ったとき，「サービスを用いてイベントを探す人」のことを想像しているメンバー

と，「運用者」もユーザに含めて考えているメンバーがおり，認識の違いが生じた．それらを防止

するために用語集を作成した．この例の場合，「イベントを探す人」と「運用者」という言葉を定

義し，「ユーザ」という言葉を使用しないようにすることで意味の取り違いがなくなった．用語集

をもとに，発表スライド，ポスターなどを作成することで，統一感のある成果物を生み出すことが

できた．さらに，用語の意味をしっかり定義したことで意思統一することができた．図 3.1が作成

した用語集である．



図 3.1 用語集


3.4.3 画面設計書

まちセンに HakoEveの提案を行う際の資料として，提案に伺うメンバーによって画面プロトタ

イプを作成した．その後，クライアント班で画面プロトタイプの検証を更に重ね，詳細化した最終

的な画面設計書を完成させた．画面設計書では前述されている機能全ての画面構想が起こされてい

る．以下の図 3.2はタグ検索機能による画面設計書である．



図 3.2 タグ検索機能画面設計


3.4.4 ユースケース図

アクターとシステムの関係を明確にするためにユースケース図 3.3を作成した．エンドユーザと

運用者をアクターとし，それぞれがどのような機能を使用することができるのかを示した．「タグ

を追加する」，「タグを編集する」というユースケースを「タグ編集」という 1つのまとまりにする

などして，見やすくするなどの工夫を施した．このユースケース図は，設計の初期段階で作成し，

業務フロー図などのほかの UML図作成の際にも使われた．



図 3.3 ユースケース図


3.4.5 業務フロー図

業務フロー図とは仕事のプロセスを、どのような人（組織）が，何をどのような流れ（順序）で

行っているのかがわかるように，フロー図で明示したものである．本グループでは，各ユースケー

スを実行するために，サービスのプロセスを，誰がどのような流れで行うのかを表すため，メン

バー全員のイメージを統一するために業務フロー図を作成した．この図を参照しながら実装を行う



などし，業務フロー図の重要性を実感することが出来た，図 3.4は，地図・場所検索の業務フロー

図を示している．この他にも 16種類の業務フロー図を作成した．業務フローの作成は個人で行わ

れ，その後全体で整合性をとっていった．「ボタンを押す」と書く人と，「クリックする」と書く人

がいるなど，文言が違っており，修正に苦労した．お客様が目を通す可能性もあるので，アクティ

ビティには誰が呼んでも分かるような文を書くという工夫をした．

図 3.4 業務フロー図


3.4.6 画面遷移図

HakoEveの構築に伴い，画面の遷移についてメンバー間で共有するために，ドキュメントとし

て管理者側の画面遷移図とエンドユーザの画面遷移図を作成した.作成においてメンバー間でどの



ようにすれば使いやすい遷移になるのか考えた．その結果，トップページに共通して遷移した．画

面遷移図を作成した事によってメンバー間での画面の遷移を確認する資料となった．図 3.5がそ

の画面遷移図である．

図 3.5 画面遷移図


3.4.7 テーブル定義書

格納に必要なデータの詳細をデータ班でドキュメントにまとめた．HakoEveのデータベースは，

イベント情報を格納する eventsテーブル，イベント主催者情報を格納する hostsテーブル，場所

情報を格納する venuesテーブル，タグ情報を格納する tagsテーブル，イベント情報と開催日を結

びつけるための中間テーブルである event datetimesテーブル，イベント情報とタグを結びつける

ための中間テーブルである events tagsテーブル，5つのテーブルで構成されている．


3.4.8 ER図

データベースをモデル化するためのドキュメントとして ER図 3.6の作成を行った．データベー

ス構築に当たり，注意した点が，イベント開催日テーブルとタグイベントテーブルの存在である．

検索する際にイベントの情報に対して，開催日時とタグ情報は 1対多の関係にある．これらの情報

をそれぞれ関連付けようとするとそれぞれの情報が含まれたテーブル同士では関連付けることが難

しく，必ず情報同士を結びづけている情報を持つテーブルが必要なのである．以下の図 3.6が ER

図である.




図 3.6 ER図



3.4.9 HakoEve

イベント管理機能

本機能は，管理者がイベント主催者などから得たイベント情報を HakoEveのデータベースに登

録，変更，削除を行うことができる機能である．イベント情報登録の際には，事前に登録されてい

る開催場所，主催者，タグのリストから選ぶことができる．この機能によって登録されたイベント

情報は後に説明する検索機能の検索結果として表示されるようになり，変更を行うとデータベー

スのイベント情報の詳細，日時，開催場所が更新される．また，削除を行うことによって，データ

ベースのイベント情報が削除される．



図 3.7 イベント情報入力画面


開催場所管理機能

本機能は，管理者ががイベントの開催場所情報を HakoEveのデータベースに登録，編集，削除

を行うことのできる機能である．登録を行うと，未登録の開催場所情報を入力することができ，入

力するとデータベース上で登録され開催場所の一覧に追加される．入力項目は開催場所名，住所の

2つである．開催場所は編集や削除も行うことができる．なお，既にイベント登録がされている開

催場所に関しては，変更や削除を行うことができないようにした．また，管理者によって開催場所

ごとに優先度を付けることができ，優先度の高い順で一覧の上から表示されるようになっている．

この優先度は地図場所検索においても適用する．この機能で事前に開催場所を登録することによっ

て，管理者がイベント情報登録，編集をする際に入力の負担を減らすことができる．

場所タグに優先度をつけた優先度


主催者管理機能

本機能は主催者名，住所，連絡先，優先度といった主催者情報を管理するための機能である．優

先度とは主催者一覧画面で優先度が高いもの程上に表示するための項目であり，管理者がオススメ

したい主催者を一覧画面上に表示することも可能である．主催者情報は主催者一覧画面から追加ま

たは編集，削除することができる．主催者追加機能を使うためには，まず主催者一覧画面の右上の

主催者追加ボタンをクリックし主催者追加画面に遷移する．主催者名，住所，連絡先，優先度をそ

れぞれ入力して追加ボタンをクリックすることで主催者追加を行う．主催者編集機能を使うために



は，主催者一覧画面から編集したい主催者を探し，編集ボタンをクリックし主催者編集画面に遷移

する．編集したい項目を編集し，送信ボタンをクリックすることで主催者情報を編集することがで

きる．主催者削除機能を使うためには，その主催者がすでに登録されているイベント情報に含まれ

ていないことが条件である．主催者一覧画面から削除したい主催者を探し，削除ボタンをクリック

すると確認ダイアログが表示されるので，そこで OKを選択することで主催者情報を削除すること

ができる．


タグ管理機能

本機能はタグ名，優先度といったタグ情報を管理するための機能である．優先度とはタグ一覧画

面で優先度が高いもの程上に表示するための項目であり，管理者がオススメしたいタグを一覧画面

上に表示することも可能である．タグ情報はタグ一覧画面から追加または編集，削除することがで

きる．タグ追加機能を使うためには，まずタグ一覧画面の右上のタグ追加ボタンをクリックしタグ

追加画面に遷移する．タグ名，重要度をそれぞれ入力して追加ボタンをクリックすることでタグ追

加を行う．タグ編集機能を使うためには，タグ一覧画面から編集したいタグを探し，編集ボタンを

クリックしタグ編集画面に遷移する．編集したい項目を編集し，送信ボタンをクリックすることで

タグ情報を編集することができる．タグ削除機能を使うためには，そのタグがすでに登録されてい

るイベント情報に含まれていないことが条件である．タグ一覧画面から削除したいタグを探し，削

除ボタンをクリックすると確認ダイアログが表示されるので，そこで OKを選択することでタグ情

報を削除することができる．


キーワード検索

本機能は管理者により登録されたイベントを，入力フォームに入力された任意の文字列 (キー

ワード)から検索する機能である．このキーワード検索では，入力されたキーワードを閲覧日以降

のイベントのタイトルおよび説明文の中から検索を行い，該当するイベントのタイトル，日時，開

催場所，画像などを表示する．

　また，入力された文字がカタカナであった場合でも，一致するひらがなも検出できるような機能

を搭載している．例えば，キーワード検索の入力フォーム内に「ハコダテ」と入力した際，本機能

では「ハコダテ」だけではなく「はこだて」という文字列も一緒に検索することができる．


日付検索

本機能は管理者が登録したイベント情報の中から，指定した日付に開催されるイベントを検索す

る機能である．本機能は図 3.8のように，HakoEveの右側にあるカレンダーの中から指定の日時

を選択することで利用することができる．また，まちセンが提供しているイベント情報掲載ページ

において，連続した複数日で開催されるイベントは，2月 10日～2月 14日というように表記され

ており，2月 12日や 13日に開催されるイベントを探したい場合，ひと目ではわからないという現



状がある．

　そこで本機能では，連続した複数日で開催されるイベントも，指定した日付がその日程に含まれ

ているならば閲覧することができるように対応した．例えば，2013年 12月 21日から 24日まで

まちセンで開催された「花結び展皮から生まれた日本の花、鳥」というイベントならば，22日や

23日を指定した場合でも，同様にそのイベントを参照することができる．

図 3.8 カレンダー表示例


地図・場所検索

本機能は，函館市地域交流まちづくりセンター様が登録したイベント開催場所の中から，任意の

開催場所を選択することにより，その開催場所で開催されるイベントを検索する機能である．本機

能では，地図・場所検索というページが設けられ，図 3.9のように，開催される施設名の一覧とそ

の施設の場所が Google Maps上にマーカとして表示される．このように，Google Mapsで表示す

ることで，エンドユーザはイベント開催場所へのアクセスの方法や，自宅の周辺で執り行われるイ

ベントなどを簡単に調べることができる．実際に本機能を用いる場合は，該当する施設を施設名一

覧から選択，あるいは Google Mapsから該当する施設のマーカを選択すると，閲覧日以降にその

施設で開催されるイベントが一覧で Google Maps上のウィンドウとして表示される．



図 3.9 地図・場所検索画面


タグ検索

本機能は，イベントに付けられたタグを用いて検索を行うことができる機能である．タグとは，

イベントを分類する単語のことである．例えば，「講演」「学ぶ（セミナー）」「遊ぶ」「食べる」「無

料」「スポーツ」「歴史」などのタグがある．

　タグ検索画面では，イベントに付けられている全てのタグがチェックボックス形式で複数選択で

きるようになっている（図 3.10）．検索したいタグにチェックを付けた上で検索ボタンをクリック

すると，選択されたタグ全てがタグ付けされているイベントが検索結果として表示される．

　タグ付けは，イベント情報の新規追加時，もしくはイベント情報の変更時に行うことができる．

1つのイベントに対して複数のタグを付けることが可能である．例えば，2014年 1月 15日開催の

イベント『季節の料理教室「冬」』には，「食べる」と「学ぶ（セミナー）」というタグが付けられる．

新しいタグの追加，削除は管理者が自由に行うことができるが，納品時に予め用意しておく 25種

類のタグを，まちづくりセンター様とのご相談の上，決定した．（図 3.10）で表示されているタグ

はその 25種類のタグである．



図 3.10 タグ検索画面


推薦機能

本機能は，イベント情報の詳細を閲覧中のユーザに，他のイベント情報を表示する機能である．

普段から多くのイベント情報を目にする機会の無い人にとっては，趣味に合うにも関わらず，目に

触れないイベントが多く存在すると考えた．この機能により，今まで知ることがなかった趣味に合

うイベントを知り，興味を持ってもらうという，新たなイベントとの出会いを提供する．

　推薦されるイベントは，イベント詳細情報の下部に表示される（図 3.11）．推薦表示されるイベ

ントは 5件である．

　推薦されるイベントは，詳細表示しているイベントに付けられているタグを用いて選ばれる．付

けられているタグが 1つ以上共通しているイベントが推薦候補として選ばれ，その候補が 5件以上

であった場合はランダムに 5件が選択され，表示される．タグを用いることで，イベントの内容が

似ているものを推薦することができる．



図 3.11 イベント詳細情報の下に表示される推薦イベント


3.4.10 Facebookによる宣伝

プロジェクトリーダーは 11 月 8 日に HakoEve を宣伝するため，Facebook のページを作成し

た．（図 3.12）このページではイベント班の活動情報や HakoEve開発の進捗状況などを報告して

いる．1月 8日現在このページは 39人に「いいね！」されていて，実際に函館市民からのコメン

トも来ている．このような応援コメントがイベント班の活動の励みとなっているので，Facebook

ページを立ち上げたことは HakoEveの開発にとっても効果的だったと考えている．



図 3.12 HakoEveの Facebook宣伝


3.4.11 HakoEveロゴ

HakoEveを多くの人に知ってもらうためにサービスを象徴するものが必要と考え，ロゴとアイ

コンを作成した（図 3.13）（図 3.14）．このロゴは HakoEve のヘッダーに使われているものであ

る．HakoEveの Oの字の中には函館市地域交流まちづくりセンター様の位置を示し，そこを中心

に情報を発信しているイメージをコンセプトとしている．作成日数は 10 日である．初日はまず，

「発信」というテーマを基にロゴの案を幾つか考えた．次に Illustratorの使い方を学びながらそれ

ぞれのアイディアを具現化した．そこで作成したものをそれぞれメンバーにレビューしてもらっ

た．3 日目にメディアデザイン専門の木塚あゆみ特任助教からアドバイスを頂いた．そこで，ロ

ゴについての勉強を木塚特任助教から教えていただいた．また様々なロゴの種類や Color scheme

designerという任意の色に合う色を提案するWebアプリケーション，Illustratorの便利な機能を

教えていただいた．4日目から 6日目にかけて，最も好印象だった案に的を絞り，アドバイスを頂

いた際に得た知識をもとに改良した． 7 日目には木塚特任助教から再度アドバイスとレビューを

頂き，その際に様々なロゴデザインについての書籍，フォントに関するアドバイスを頂いた．その

アドバイスをもとに比較的インパクトのある Fold Bold というフォントを使った．8 目から 9 日

目にかけて，レビューして頂いた時のデザインを基に約 10通りのデザインを考え，10日目にメン

バー，野外劇班，TA，教員の方々からの投票で現在のロゴに確定した．



図 3.13 HakoEveのロゴ

図 3.14 HakoEveのアイコン


3.5 本開発における学び

本開発を行う前に，まず函館のイベント情報の問題定義を行うところから始まった．プロジェク

トメンバー内でも函館のイベントについての認知度も低いことから函館のイベント情報は上手く伝

わっていないのではないのかと考えた．私達は，函館のイベント情報がどのように発信されている

かを調べた．その結果，函館のイベント情報は紙媒体とインターネットで発信されていることがわ

かった．

　次に主にイベント情報を扱っている函館市地域交流まりづくりセンター様，函館市青年センター



様，函館市文化・スポーツ振興財団の 3 団体にイベント情報の発信についてヒアリングを行った．

その結果，イベント参加者は年齢層が高めであること，どの団体も紙媒体のイベント情報の発信に

満足していることがわかった．ヒアリングの結果から，紙媒体の発信で満足していたことがわかっ

た．そのことから，現場の人から実際に話を聞くことの大事さを学んだ．次に私達は，現状ではイ

ンターネットでのイベント情報の発信が充分に伝わっていないのではないかと考えた．

　私達は，インターネットで函館市のイベント情報サイトを調べ，1番多くイベント情報を所有し

ているまちセンのイベント情報を使わせていただいてインターネットサービスの構築を目指した．

そこで，私達はどんな機能があればインターネットでイベント情報を探している人にわかりやす

く，イベントに来たくなる情報を与えられるかを考えた．メンバー全体で意見を出し合い検索機能

や事後レポートなどの意見が出たが，なかなか話し合いが進まないでいた．

　夏休みに入り遠隔の会議が多くなり，話し合いの効率が落ちてしまい当初予定していたスケ

ジュールとの遅れが発生してしまった．私達は事後レポート機能の案にしぼりすぎていたことに気

付き，一からブレインストーミングしメンバーの認識の違いを無くし，イベントを探す人は何を求

めているのかを再考した．その結果，キーワード検索，地図・場所検索，日付検索，タグ検索など

の機能が決まった．複数での会議ではメンバー間で認識の違いがあると話し合いが中々進まないの

で，会議を行う上でメンバー間で認識の共有の重要さを学んだ．

　システムの運用の問題もまちセンのイベントページの市民活動情報のページを私達のページと

差し替えていただければ解決するのではないかと考え，まちセンに提案をすることになった．提案

資料を作るために管理者側とインターネットでイベントを探す人にとっての各メリットを明確化

した．そのためにシナリオを作り，サイトの機能の細かい部分を確定した．まちセンに提案した結

果，ぜひ使ってみたいなどの意見を頂いた．提案資料を作る上で意識共有をするためにサイトのイ

メージを見せること，エンドユーザーやまちセンの目線で資料を作りメリットがわかりやすくする

ことの重要性を学んだ．

　そして，私達はすぐに設計フェーズに入り，前期の模擬開発でわかったお互いの得意分野などを

考慮して機能班とデータベース班に分かれ作業を行った．機能班はユースケース図や画面遷移図

などを作成し，データベース班はデータベースを設計し作成した．設計が終了し，実装フェーズに

入り，設計の班を引き継ぐのでなく，設計の情報の共有がしやすいようにどちらかの班に機能班と

データベース班の人がいるような班分けをし，クライアント班とサーバー班に分かれた．クライア

ント班はサイトのデザインや UIを実装し，サーバー班はデータベース側の処理を実装した．実装

と並行してサービス名とロゴを作成し，サービス名が「HakoEve」と決定し，ロゴも完成した．設

計と実装を通して，他のメンバーの進捗をこまめに確認すること，班ごとのソースコードの情報の

共有の重要性を学んだ．

　模擬開発でチームでの開発を一度経験してきたので，実装はスムーズに進み，はこだて高等教育

機関合同研究発表会「HAKODATE アカデミックリンク 2013」に出展することが決まった．それ

までにキーワード検索機能，イベント情報検索結果画面，イベント詳細画面並びにイベント推薦

機能の実装を完了することができた．アカデミックリンクでは発表時の情報系に詳しくない人に対

しての言葉選びや表現の仕方について学んだ．

　しかし，作成させるだけではなく運用のことを考えなければならないので，12月にまちセンの

元に訪問し実装完了した HakoEveをお見せし，運用の件についてお願いした．その結果，運用に

ついての前向きなご検討や機能についてのアドバイスをいただくことができた．

　今後 UIなどの調整を終えた後，テストを行い実際にエンドユーザーに使ってもらって有用性を

確かめて，3月中旬にまちセンに納品する予定である．本開発を通して，問題定義から納品までの



実装のみならず運用や納品などのプロセスを経験として学ぶことができた．


3.6 今後

12月 1日にまちセンから頂いた HakoEveの仕様に関するコメントを検討した結果，現在の仕様

に変更を加えた方が，よりシステムが使いやすくなると判断したため，仕様を変更し，変更分の実

装にとりかかることとなった．ユーザテストが 2月 15日に行われるため，仕様変更分の実装，テ

ストは 2月 14日までに行う予定である．

　また，HakoEveを運用していただくために，まちづくりセンター様のWebサイトを管理してい

る業者様との運用に向けた相談も行い，4月までの運用を目指して調整を行う予定である．


3.6.1 仕様変更書

本グループでは HakoEveの仕様変更でメンバー全員の変更点の認識を共有し、作業を円滑に進

めるために仕様変更書を作成した．まずメンバー 2名が仕様変更書のテンプレートを作成した．こ

のテンプレートを作成することによってクライアント班に関する仕様変更書とサーバ班に関する仕

様変更書の共通の体裁を整えることができた．

　テンプレートの仕様としては変更するべき仕様に高低の優先度をつけるようにした．また仕様変

更前の状態と仕様変更後の状態が比較され分かりやすく，UIの仕様変更書においては HakoEveの

画面のスクリーンショットを貼り付けることによって，ひと目で変更点がわかるような仕様となっ

ている．作成されたテンプレートを用いて，クライアントサイドに関する仕様変更書とサーバサイ

ドに関する仕様変更書の叩き台を作成し，メンバー全員でレビュー，修正を行い，メンバー全員の

承認が取れた段階で仕様変更書を完成させた．図 3.15は，サーバ側の仕様変更書の一部である．



図 3.15 仕様変更書




3.6.2 画面UIの変更

画面の UIに関しては，早急に変更するべき優先度が高い 3つの仕様変更箇所が挙げられた．

　 1つ目は検索結果画面にてイベント名をクリックすると，イベント詳細情報画面に遷移できるよ

うに変更することである．現状の HakoEveではイベントの詳細情報の画面に遷移する方法が「詳

細はこちら」のリンクをクリックするのみであった．この遷移を，表示されているイベント名をク

リックすることでも行えるようにすれば，HakoEveの UIが向上すると考えている．

　更に 2 つ目として，検索結果画面においてイメージ画像をクリックすることでの遷移もできる

ように変更することである．現状の HakoEveではイメージ画像をクリックしても，別ウィンドウ

で拡大されたイメージ画像が表示されるだけであった．検討の結果，現状の機能の必要性が少な

かったため，仕様変更箇所として挙げられることとなった．この仕様変更が行われることで更に

HakoEveの UIは向上する．

　 3つ目の変更箇所としては，イベント名を目立たせるように変更することである．変更前は，文

字が小さく，目立ちにくい仕様であったが，イベント名の文字サイズを日付の文字サイズよりも大

きくし，イベント情報を記載したテーブル外に表記させることで，よりイベントが目立ち，閲覧者

に対して更なるアピールが可能になる．


3.6.3 推薦機能の変更

推薦機能で変更予定の仕様は 2点ある．推薦候補の決定方法，推薦候補のイベントの中から 5件

を選ぶアルゴリズムの 2点である．

　推薦候補の選定方法は，タグのみでなく，主催者が共通しているイベントも推薦候補として選ば

れるように変更する．推薦機能は，イベントの内容が似ているものを推薦する機能であるが，主催

者が同じならば，内容も似ているというイベントが多いということが，変更理由である．

　推薦候補のイベントの中から 5件を選ぶアルゴリズムは，推薦候補の中からランダムに 5件を選

ぶのではなく，推薦するのにふさわしいかどうかを表す点数を定義し，その点数が高いものを優先

的に推薦するように変更する．推薦するのにふさわしいかどうかを表す点数は，イベントの日時，

検索した日付，主催者の共通，タグの共通個数，を用いて計算する．この変更によって，より似た

イベントを推薦することができる．また，閲覧日から推薦されたイベントの開催日までの日数が長

すぎると，開催日近くになるとイベントのことを忘れてしまい，効果的な推薦ができないという欠

点があるとまちセンの職員の方から指摘を受けた．閲覧日からイベントの開催日が近いものを優先

的に推薦できるように，イベントの開催日を点数決定の条件として含めることで，この欠点を改善

することができる．点数の詳細な計算方法については現在のところ未定であるため，今後詳細を検

討する．




3.6.4 検索機能の有用性の確認

イベント班は HakoEveがイベントを探す人にとって本当に使いやすいサービスなのかについて

ユーザテストを行う．12月 1日の進捗報告会でまちセンにユーザテストの会場提供などの協力を

依頼した．まちセンには協力のお願いを快諾していただいた．ユーザテストまでに仕様変更分の実

装とシステムテストを行う予定である．またユーザテストを行う日は 2月 15 日を予定しており．

SD法により分析を行う．SD法とは，早い遅い，明るい暗い，重い軽いなどの対立する形容詞の

対を用いて，感情的なイメージを 5段階あるいは 7段階の尺度を用い，判定する方法である．ユー

ザテストでは SD法を行うためのアンケート用紙を用意し，被験者に回答させるテストを行う予定

である．




第 4 章スケジュール

4.1 全体

模擬開発，本開発のグループに分かれずに行ったプロジェクト全体での活動のスケジュールを以

下に列挙する．1月以降分は予定を列挙する．

• 5月

・プロジェクト発足

・プロジェクトリーダー決定

・グループ分け決定

・グループリーダー決定

・Subversion勉強会

・方針決定

・合同キックオフ

・懇親会

・CakePHP勉強会

・Redmineの使い方確認

・日本語運用ミニ講座

• 6月

・中間発表準備開始

・発表スライド作成

・発表ポスター作成

・発表練習

• 7月

・プロジェクト担当教員・TAからの発表レビュー

・企業講師からの発表スライドレビュー

・中間報告書着手

・中間発表会

・中間発表反省

・中間報告書提出

• 8月

・オープンキャンパス出展

・自主学習

• 9月

・自主学習



・後期プロジェクト開始

• 10月

・アカデミックリンク出展ポスター作成

・アカデミックリンク発表練習

• 11月

・アカデミックリンク出展

・成果発表会スライド作成

・成果発表会ポスター作成

・成果発表会発表練習

• 12月

・成果発表会

・最終報告書作成

・振り返り会実施

• 1月

・最終報告書作成

・最終報告書提出

• 2月

・課外成果発表会

4.2 模擬開発

模擬開発の活動のスケジュールを以下に列挙する．

• 5月

・模擬開発開始

・開始時説明

・依頼書・元システムのソース配布

・サーバの説明・設定

・システム開発依頼書・既存システムの要件定義書の確認

・システム開発依頼者へのヒアリング

• 6月

・要件定義

・要件定義書作成

・設計

・ユースケース図作成



・業務フロー図作成

・ユースケース記述作成

・ER図作成

・テレビ会議での企業講師レビュー

・実装開始

・企業講師レビュー

• 7月

・中間発表会

・テストに関するミニ講義

・テスト


• 8月


・システム納品

・模擬開発終了

4.3 本開発

本開発におけるスケジュールを以下に列挙する．12月までは実績，1月以降は予定を列挙する．

• 5月

・Web上の情報調査

・広報誌の情報調査

・ヒアリング先決定

• 6月

・3団体へヒアリング

・調査結果とヒアリング結果まとめ，考察

・今後の方針検討

• 7月

・中間発表会

・今後の方針検討


• 8月


・問題定義会議

・自主学習



• 9月

・問題提議会議

・HakoEve企画開始

・自主学習

• 10月

・まちづくりセンター様への HakoEve提案

・HakoEve設計

・HakoEve実装開始

・アカデミックリンクポスター作成


• 11月


・アカデミックリンク出展

・HakoEve実装

・HakoEveテスト

• 12月

・まちづくりセンター様へ進捗報告

・イベント情報集約・発信システム開発

・成果発表会

・仕様変更検討

• 1月

・最終報告書提出

・仕様変更実装

• 2月

・仕様変更実装

・仕様変更テスト

・ユーザテスト実施

• 3月

・HakoEve納品

• 4月

・HakoEve運用開始




第 5 章個人の活動

5.1 西本光司

• 前期キックオフ　プロジェクトがキックオフし，私たちのプロジェクトはメンバー 15人をイベント班 10名

を 2グループに，野外劇班を 5名 1グループに分けた．野外劇班をグループ A，イベント班

をグループ Bとグループ Cにした．その中で私はグループ Bに所属することになった．企

業講師の高森満様と木下実様のお二方に来ていただいて，前期キックオフを行った．グルー

プ各メンバーで自分が学んできたこと，このプロジェクト学習を通して学びたいことを述べ

た．私はこのプロジェクト学習を通して，データベースの知識やコーディングなどの技術的

な面とユーザーにとって使いやすいものにしていく人間中心設計を学びたいと私自身で掲げ

たので，今後の活動を行っていく上での活力となった．アイスブレイクで普段喋ったことの

ないメンバーと話すことができ，当初イメージしていた人物像とのギャップに気付けたこと

がキックオフでの大きな学びであった．

• 勉強会　 CakePHP勉強会では当時は全く知らなかった言語であったので，MVCの説明を聞くこ

と，練習問題を解くことで精一杯であった．練習問題などの演習を通して，データベースと

連携してWebページを始めて作ることができた．

• 模擬開発演習　模擬開発演習ではチームでの開発の流れや開発の要求定義から運用までの開発の流れを実

際に体感した．グループ Bでは担当教員の大場みち子教授を実際の依頼者と見立てて開発

を行った．模擬開発では依頼主である大場みち子教授の面談予約管理システムの開発を行っ

た．初めにグループでスケジュールを立てて，細かい仕様の要求を伺うためにヒアリングを

行うことにした．ヒアリングの際には私は記録係として，ヒアリングで行った質疑応答の結

果や，依頼者からの意見や要望をなるべく具体的に記録として残した．2回目のヒアリング

の際にはファシリテーターの補助として話し合いの内容がそれたり，ファシリテーターが具

体的な説明が不十分な場合に代わりに説明するような役目を果たした．ヒアリングの結果を

まとめ，グループ Bはドキュメント作成に取りかかり，要求定義書やユースケース図を作る

ことになり，私は要求定義書の作成に携わることになった．

　ドキュメント作成が終了し，実装が始まり機能ごとに役割分担をすることになり，面談タ

イトル追加機能，面談候補日追加機能，ログインログアウト機能と面談予約機能の中から私

は，面談候補日追加機能を実装することになった．CakePHP勉強会で勉強が不十分だった

ためデータベースの連携のところで，他のテーブルと連携する場合の実装が上手くいかず，

リーダーの工藤のサポートを受けながらの作業となった．8月上旬に技術習得として行って

きた模擬開発演習の依頼者への納品会をおこなった．活動時間外での活動であったので私は

欠席したが本グループのリーダーが中心となって依頼者である大場みち子教授に対して，最

低限実装してほしいと依頼された，面談タイトル追加機能，面談候補日追加機能，ログイン

ログアウト機能と面談予約機能が実装された面談予約管理システムを納品することができ

た．模擬開発演習が終了し，演習を通して学んだことを本開発に活かすことができた．



• 中間発表会　中間発表会の準備ではポスター班に所属し，ポスター班はプロジェクト全体の概要がわ

かるメインポスターと模擬開発演習の詳しいことがわかる模擬開発演習のポスターの 2 枚

を Illustrator で作ることに決まった．そして私はポスター班のリーダーとして，メインポ

スターを作成しつつポスター班全体の活動をとりまとめた．ポスター全体のデザインは私と

Kim Sun Wooと共に考え，文章や英訳は他のポスター班のメンバーで考えた．適宜必要と

なってきた文章を説明するために図は私と Kim Sun Woo が中心となって作成した．スラ

イド資料に使われたスケジュールも私が作成した．メインポスター全体として，文字数をし

ぼりながらの作業をしていたので，しぼった文字の分英訳の方もしぼられるので効率が悪

かった．中間発表全体のスライド発表で私はイベント班の説明をする発表者になり，発表練

習を重ねながら中間発表を迎えた．はこだて未来大学プロジェクト学習中間発表会の私たち

プロジェクトの前半の部の計 3回のスライド発表を私は行った．

• オープンキャンパス　はこだて未来大学でオープンキャンパスが行われ私たちのプロジェクトも出展させていた

だくことになった．中間発表会で使用した資料やデモを使って，高校生にはこだて未来大学

のプロジェクト学習では，どんなことをやっているのかを ITに詳しくない人に対してわか

りやすく説明することが出来た．

• 後期キックオフ　プロジェクト後期のキックオフが行われた．そこではマシュマロタワーを作成しチームで

マシュマロタワーの高さを競い合った．プロジェクト内では 2 回目のアイスブレイクだっ

たので，グループ内での話し合いが進みどうすれば高いマシュマロタワーが作れるのか計画

し，行動を起こすことができた．私は役割分担をしたほうがいい，もし上手くいかなった場

合はどのような対処方法をとるか積極的に発言した．

• 本開発

現状調査函館市のイベント情報の現状を知るために本グループで現状調査を行った．私は

ヒアリングに参加できなかったが，函館市のイベント情報を取り扱う webサイトを見て発

信方法や収集方法を調査した．

サービスの考案サービスの考案は夏休みに入り，インターンシップや帰省などで遠隔での

会議が多くなり，本開発で構築するサイトはどのようなサイトにするか決める会議を行って

いたが，会議の質が悪くなってしまった．私自身も会議に集中してないこともあったので，

遠隔での会議では意見が伝わりにくく，会議が進まないことが学ぶことができた．どのよう

なサイトにするか決める会議を行っていたが意見が食い違っていた．サイトを構築する目的

が全員で統一されていなかったことが原因であった．これを受けて，今まで考えてきた機能

を一から考え直すことにした．まず本グループ全体で目的を統一し，それからブレインス

トーミングでどんな機能があればいいかを出し合った．私は実際にイベント情報サイトを使

いながら，自分がイベントを探す立場だとどんな機能があれば嬉しいのかを考え意見を出し

た．目的が統一されて話し合いが進みやすくなった．話し合いだけで個々のイメージを共有

するのではなく，図や絵でイメージの共有ができたのが有効となりいろんな機能の提案につ

ながった．

設計設計の段階では前期の模擬開発でわかったお互いの得意分野などを考慮して機能班と

データベース班に分かれ作業を行った．機能班はユースケース図や画面遷移図などを作成



し，データベース班はデータベース設計し，作成した．私は機能班に所属し，ユースケース

図の作成や業務フロー図の作成を行った．設計が終了し，実装フェーズに入り，設計の班を

引き継ぐのでなく，設計の情報の共有がしやすいようにどちらかの班に機能班とデータベー

ス班の人がいるような班分けをし，クライアント班とサーバー班に分かれた．クライアント

班はサイトのデザインや UIを実装し，サーバー班はデータベース側の処理を実装した．私

はクライアント班に所属した．

実装クライアント班として実装を行った．グループメンバー 4名を二つに分けペアプログ

ラミングの方式をとった．私は小田大介とペアとなった．また，他のメンバーの工藤卓也と

柴田健介でペアになってコーディングを行うことにした．実装する際にサイトの大まかなデ

ザインをクライアント班で考えた．まちセンに提案に伺った際に作成したスライドにサイト

のイメージを考えていたので，それを基にデザインを作成することになった．また私たちが

作成したサイトと差し替えになるまちセンのサイトの市民活動情報のページのイメージを大

きく変えないために配色やボタンの配置は既存のサイトと同じ位置や配色にした．ペアごと

に作業を分担することになり，最初に私たちのペアはサイトに使うボタンなどの素材作りを

行い，工藤・柴田ペアでサイトのヘッダーとフッターの作成をおこなった．次に各ページの

実装を行った．私たちのペアは検索結果画面，詳細画面，地図・場所検索画面を実装した．

• アカデミックリンク　本プロジェクトで，はこだて高等教育機関合同研究発表会「HAKODATE アカデミック

リンク 2013」に出展することが決まった．それまでにキーワード検索機能，イベント情報

検索結果画面，イベント詳細画面並びにイベント推薦機能の実装を完了することができた．

アカデミックリンクの当日には参加できなかったが，実装や発表資料作りには参加した．

• 最終成果発表会　発表資料作りや発表準備をおこなった．私は前期に引き続きポスター作成班に所属した．

私は今回はポスター作成の補助にまわり，ステークホルダーの関係の図やスケジュールの図

作成を行った．スライド発表の発表練習にも参加し，発表会当日に望んだ．発表担当部分が

少なかったため，スムーズに発表することができた．

• 振り返り会　成果発表も終わりプロジェクト学習の振り返りを企業講師のお二方を迎えて行った．私は

プロジェクトキックオフの時に掲げていた目標が達成できたかどうか振り返ったところ目標

は達成できていた．

• 個人の学び　個人の学びとして最初に個人としてのシステムの作成ではなくチームとしての作成であっ

たので，情報を共有する際に，お互いにとってわかりやすい情報でなければならないので，

きちんと用語の統一やフォーマットの統一をしなければ伝わりにくくなる事を学ぶことがで

きた．また，今回の開発を通してユーザーの立場で考えて機能やデザインを考えることが多

かった中で，ただ考えるだけではなく実際にその状況やデータで使ってみることで気付くこ

とがあるということを学ぶ事ができた．




5.2 工藤卓也

• 前期キックオフ　私たちのプロジェクト学習は先生方からのプロジェクトの説明，Redmineの説明やプロ

ジェクトメンバー個人個人の自己紹介から始まった．2 回目のプロジェクト学習ではメン

バー 15人をイベント班 10名を 2グループに，野外劇班を 5名 1グループに分けた．野外

劇班をグループ A，イベント班をグループ Bとグループ Cにした．そこで私はグループ B

に所属することとなりリーダーを務めることとなった．

　また，企業講師の高森満様と木下実様を迎え，北海道の魅力創造プロジェクトとの合同

キックオフを行った．アイスブレイクとして行なったことは，10分以内に A4の紙 40枚を

使って，できるだけ高いタワーを作るというものだった．ここでチームメンバーの個性など

を理解し，チーム一丸となって取り組む力がついた．その後にポストイットにメンバー個人

個人のこのプロジェクトで学びたいものを書いてグループディスカッションを行った．

• 勉強会　模擬開発演習で必要となる技術習得のために CakePHP勉強会を行った．CakePHP勉強

会は 4回にわたって行われ，一人一冊 CakePHPのテキストを貸し出された．CakePHP勉

強会ではMySQLの勉強も同時に行い，Webアプリケーションの基礎となる部分の勉強を

行った．

• 模擬開発演習　 CakePHP 勉強会が終わると模擬開発演習が始まり私たちのグループは大場みち子教授

をお客様として面談予約管理システムの開発を行うこととなった．

　模擬開発演習が始まるとまずスケジュールをたて，大場みち子教授の要求を聞くためにヒ

アリングを行った．そこで私はグループでの話し合いではまとめ役となった．また．ヒアリ

ングの旨を伝えるメールなどを送った．メールを送る際には，今回のヒアリングで聞きたい

内容などをあらかじめ伝えることとした．ヒアリングは 2 回行い，1 回目はファシリテー

ターとして行動したが，2回目は経験を積むために話を進める人を私ではなく他のメンバー

にお願いし，私はメモに徹した．

　ヒアリングの結果を基にまずはメンバー全員でユースケースを考え，ユースケース図を作

成した．その後に，ユースケース毎に役割分担をして要求定義書の作成を行い TAの方から

レビューを頂いた．その結果，多くの指摘を受けたためドキュメントの修正に取りかかっ

た．そこでもメンバーで役割分担し，私は要求定義書の修正を行った．

　お客様である大場みち子教授と私たちの意見にズレがないことを確認し，データベース

設計に取りかかった．ER 図とテーブル定義書を作成した．データベースの知識が少なく，

データベースの勉強を改めて行い，実装に取りかかった．また，画面遷移図の作成を行った．

　 6月の中旬に高森満様と木下実様からレビューを頂くためにテレビ会議を行った．テレビ

会議では私はグループ Bの作成したドキュメントの説明を行った．そこで，たくさんの指

摘を頂いた．例えば，ヒアリング結果をまとめたドキュメントがまとめになっていないなど

や要求定義書の言葉の曖昧な部分などの指摘を頂いた．

　ご指摘頂いた部分の修正を行い，実装に取りかかった．実装を始めるためにまずは作業分

担を行った．作業分担はMVCモデル毎に分けるのではなく機能毎に分けた．そして，リー

ダーである私は，メンバーが困った時に助けるという立場に立った．そのため，私はメン



バーの実装箇所をあらかじめ理解しておく必要があり，他のメンバーの実装するべき部分を

私も実装し，全体を理解することを心がけた．その甲斐あってメンバーが実装で詰まったと

きなどは，実際にできている画面を見せつつアドバイスできたのでよかったと思う．しか

し，他のメンバーが実装する箇所を私も別で実装してしまっているため 2 重に実装してし

まい大きな無駄があった．しかし，私としては今回は経験を積むということが模擬開発演習

の目的であったため無駄が生じることは承知の上で行っていたので成功だと考えている．ま

た，サーバの管理も私が担当した．

　また高森満様と木下実様にレビューを頂く機会があり，そこでは実際にできた画面を見せ

つつドキュメントと照らし合わせ説明した．しかし，実装を始めて 1週間ほどしか経ってお

らず実装できていない箇所が多かった．そのため，ドキュメントについての指摘をたくさん

頂いた．

　模擬開発演習中は 3 つのグループの進捗状況や困っている点などを共有するため私とグ

ループ Aのリーダーとグループ Cのリーダーとプロジェクトリーダーの 4人でリーダー会

議を行った．

　 8月に面談予約管理システムの納品会を行った．そのために実装しきれていなかった部分

の実装に取りかかった．そこでは期日が少なかったこともあり，リーダーとして優先的に実

装するとこはどこかなど考え，メンバーにタスクを割り当てた．納品直前は夜遅くまで大学

に残り実装したが，全てのタスクを終わらせることはできなかった．

　納品会では各グループがお客様と見立てた先生方の前で自分たちの作った面談予約管理

システムの説明をする形で行われた．私たちのグループ Bは一番最後に納品を行った．グ

ループ Bの納品では主に私が話を進める形で行い，グループメンバーに実際に面談予約管

理システムを操作してもらい，ユースケースと照らし合わせながら説明を行い，最後に質疑

応答をして納品が完了した．

• 中間発表会　また，7 月の中間成果発表会に向けて準備も行い，まずリーダー会議でスライドとポス

ターをどのような体制で作るかを話し合った．その後，プロジェクト学習の時間でプロジェ

クトリーダーとグループリーダー以外のメンバーをスライド班かポスター班に振り分けた．

私はグループリーダーなのでどちらの集まりにも参加するようにした．私は直接操作するこ

とはほとんどなかったがスライドは Googleドライブで全員で作成し，ポスターは特定のメ

ンバーが Adobe Illustratorで作成した．

　中間発表の準備ではスライドは一通り完成したら先生や TA の方々からレビューを頂い

た．その結果，たくさんの修正点があげられた．修正点を直すにもうまい表現が見つからな

かったりどう直せばいいかわからないとこが多く，夜遅くまで残って作業する日が多かっ

た．私はスライド作成に比べ，ポスターの作成にはあまり携われなかった．

　中間成果発表会はミュージアムで行い，発表スライドと活動風景を映したスライドショー

とポスターとそれぞれのグループで開発した面談予約管理システムのデモを設置した．私

はそこでデモの説明を担当した．発表は前半と後半に別れるため人数が足りなく，他のグ

ループが開発した面談予約管理システムのデモの説明も行うことになった．そこで，全ての

グループの面談予約管理システムのデモの説明を同じように行おうとしたが，実際に発表

が始まると時間の都合上もあり，自分のグループの面談予約システムの説明に集中してし

まった．

• 個人報告書



　中間成果発表会が終わると中間報告書に取りかかった．中間報告書では，グループ報告書

と個人報告書と学習フィードバックシートを書いた．グループ報告書では私はプロジェクト

の背景について書いた．学習フィードバックシートは先輩からも頂いた昨年度のものをもと

に文字化けなどを直してテンプレートを作成した．一通りグループ報告書を完成させると先

生からレビューを頂き修正していった．また，個人報告書も人によって書き方が違うことが

あったので統一した後印刷を行った．

• 本開発

現状調査函館市のイベント情報の発信について現状を知るため，函館市近郊のイベント情

報の集約・発信状況や，現状でイベント情報の集約・発信に力を入れている団体はどこなの

かを調べた．その結果，まちセンと函館市青年センター様と函館市文化・スポーツ振興財団

様へヒアリングを実施することにした．

そして，私はまちセンと財団法人函館市文化・スポーツ振興財団様へヒアリングを行いたい

という旨のメールを送り，ヒアリングを行うことを交渉した．メール作成時には先生からレ

ビューを頂いた．3団体ともヒアリングの許可を頂き，6月にヒアリングを実施した．私は

まちセンと財団法人函館市文化・スポーツ振興財団様へ実際にヒアリングへ伺った．まちセ

ンでは主にファシリテーターを行い，財団法人函館市文化・スポーツ振興財団ではメモを

とった．

サービスの考案模擬開発演習が終わると本開発を行なったが 8 月の段階では 6 月に行っ

たヒアリングの結果をまとめただけでどのようなシステムを作るかが全然決まっていなかっ

た．しかし，夏休みはインターンシップや帰省などでメンバーが集まれない日が多かった．

そこで，メンバーがまだ函館に残っている 8月の初旬にどのようなシステムを作るか決めて

しまい，残りの夏休みは技術習得の時間にしようと計画した．前期から決めていた検索シス

テムと事後レポートを推したシステムを作ろうと考え，内容を詰めていき先生にレビューを

頂いた．しかし，解決案になっているのかなど様々な指摘を頂き，ペルソナをたてて考えた

り，他の地方のイベント発信サイトを見て自分たちの理想のWebサイトを考え，その後に

技術的な問題を考えていった．しかし，それでも一覧性がないという指摘を頂いた．なかな

か 8月の初旬では決まらず段々と予定がずれてしまい，集まれない時には Skype会議を実

施した．Skype会議だとドキュメントの共有や意志疎通が難しく，思うようにいかずまった

くと言っていいほど進捗がなかった．

　 9 月にも Skype 会議を行ったが，8 月に行った Skype 会議と同様にほとんど進捗がな

かったが，現状では検索と事後レポートに絞りすぎていることがわかり，今後の方針として

一から欲しい機能をブレーンストーミングしようという結果になった．そこで夏休みの後半

にメンバーみんなで集まってブレーンストーミングを行った．また，メンバーの意識にズレ

が生じないようにプロジェクト憲章を作り，画面イメージも共有するため図にした．

　そしてまた企業講師の高森満様と木下実様に進捗の報告を行ったのだが，まだまだ曖昧

だった部分を指摘されてしまった．また，今まで私を含めリーダー二人という体制で行って

いたためしっかりとしたまとめ役がいないという状況が続いていた点も指摘をうけた．

　体制について改めて考え直し，プロジェクトリーダーである兵藤をリーダーとして私とも

う一人のリーダーであった齋藤創をサブリーダーのような立場に置くこととした．

　システムを開発するということでずっと悩んでいた今後の運用についてまちセンにお願い

することで話が固まった．また，問題であった探しているイベントに出会えないという問題



に対しては検索機能を充実させ，さらに新たなイベントの出会いとして推薦機能を加えたシ

ステムを作ることに決定した．

提案そこで，函館市文化交流まちづくりセンター様に提案するために提案スライドを作成

した．ここでは，情報系に詳しくない人でもしっかり伝わるように心がけ難しい言葉を使わ

ないなど配慮してスライドを作成した．一通り作成すると先生や TAの方々からレビューを

頂いた．その結果，画面イメージがわかりづらいなどと言う指摘をうけ，大きくやり直す必

要があった．レビュー後Microsoft Power Pointを使いいくつかの画像を合成し，自分達の

画面のイメージに近いものを図として完成させた．その後も，初めて見る相手に伝わるよう

にとレビューを頂きながら修正していった．

　そして私達の考えたシステムを提案するためにまちセンへ私も含め 5 人で訪れた．話は

リーダーである兵藤が進め私はメモをした．結果としてまちセンに私たちの提案したシステ

ムを使いたいと言って頂けた．そこで，12月に一旦完成版を見せ，そこで納得して頂くこと

ができたら 3月頃に運用して頂くことを約束した．

設計　私が提案スライドを作成している間に他のメンバーには画面遷移図やユースケース

を担当する機能班とデータベース設計などを担当するデータ班に分かれて設計をしてもらっ

ていた．そして提案が終わると私は機能班に合流して画面遷移図などの作成を行った．

実装設計が終わると実装に移り，この工程でも班を 2つにわけ，デザインや UIを担当す

るクライアント班とデータベース側の処理を担当するサーバ班で実装を行った．班の構成に

ついてもリーダー会議で話し合い，設計時の 2つの班をそのまま継続するのではなく機能班

とデータ班のメンバーがクライアント班とサーバ班どちらにも属するような構成にした．そ

こで私はクライアント班となった．またその中でリーダーを務めることとなった．実装では

ペアプログラミングを行うこととなり，私は柴田と組むこととなった．

　自分が今までほとんど使ったことのなかった htmlや CSSや JavaScriptを使うことにな

り，一から勉強を始め，本を読んだり実際に前期作った面談予約管理システムのデザインを

変えたりと個人的に勉強を始めた．また，リーダーなのでタスクを洗い出し，スケジュール

をたてた，タスクは画面毎分割した．仕事分担はクライアント班全員で話し合い，得意分野

や学びたい内容などを考慮し割り振った．また実装を始めてから 1週間後にアカデミックリ

ンクが迫っており，そこではデモを見せる予定だったのでアカデミックリンクまでに実装を

終わらせるものを優先度を高めにしたりと優先度付けも行った．

　まず，私たちのペアは全ての画面に共通するヘッダーとフッターを実装することとなっ

た．ヘッダーとフッターはもともとあったまちセンのWebサイトと同様のものにしなけれ

ばならず，微調整に苦労した．その後も画面の右側にあるメニューを実装し，そこではカレ

ンダーを作らなければならず，JavaScriptを使用した．JavaScript のファイルは既存のも

のを変更し，CSSを変更してカレンダーを完成させた．また，トップ画面を担当し，見やす

いレイアウトを考え実装した．

　実装中にアカデミックリンクがあり，アカデミックリンクが終わると，改めてスケジュー

ルを見直し，タスクを割り振った．この割り振りから私は管理者用画面全般の実装を行っ

た．その後は画面遷移が正しいかなど確認した．また，途中でレビューを頂き，多くの修正

点が見つかったため，修正も行った．まちセンに評価を頂くまでの実装は 11月までに終わ

らせると決めいてたのだが，地図場所検索が終わるか微妙だった．そこで，私も手伝い期日

内に終わらせることができた．



評価 10月に約束した通り HakoEveの実装を終わらせ，まちセンへ評価を頂きに行った．

そこでは自分はメモを担当したが，思ったようにメモがとれなかった．まちセンからは良い

評価を頂き，今後直してほしい箇所も聞くことができ，今後の運用についても，現在委託し

ている業者についての話もできたりなど前向きに話を進めることができた．

• アカデミックリンク　また，アカデミックリンクに向けて発表準備を行った．アカデミックリンクはポスター

セッションとデモでの発表となっており，企業講師の高森満様にご指導いただき，ポスター

セッションの練習を行った．

　アカデミックリンク当日の発表も 2人ペアで 30分× 2で発表を行った．アカデミックリ

ンクは，情報系に詳しくない方々へ向けた発表だったので専門用語を使うように心がけた．

このような場で発表することにより，一般の方々からアドバイスや指摘などたくさんの貴重

な意見を頂くことができた．

• 最終成果発表会　最終成果発表会はスライド班 3 人とポスター班 3 人で行い．私はどちらにも属さなかっ

たので担当する仕事のメインはレビューになっていた．また今回はメンバー全員がスライド

発表を行うこととなり，スライド発表の練習も行った．

　スライド発表は早口になってしまうため苦手意識があった．スライドは模擬開発演習とイ

ベント班の活動と野外劇班の活動の 3つにわけ，私はイベント班の活動の発表を担当した．

発表全体として，時間がかかりすぎるという課題があり，そこで同じイベント班の活動の発

表をするメンバーと話し合い，どこを話し，どこを話さないかを決めた．そこで決めたこと

をもとに発表練習を行った．しかし，ポスター練習はほとんど行うことができなかった．ま

た，私はスライド班でもポスター班でもなかったので，指摘を行った．ポスターに対しては

PDFに対して指摘事項を書き，スライドに関しては直接指摘した．

　最終成果発表会本番では私はスライド発表とデモの発表とポスター発表を順に行った．ス

ライド発表ではメンバーで決めたことをしっかり行い，落ち着いてできたと思う．しかし，

質疑応答に対しては悔いが残った．質問をされた後にすぐにそのスライドへ移動せず，自分

が答える時に移動してしまったので今後改善していきたい．デモの発表では私はリーダーと

して全体を見ていたこともありスムーズに行えた．しかし，練習不足だったポスター練習は

どこから話せばいいかわからず焦りながら発表してしまった．また，ポスター発表は質問が

多くたくさんの貴重な意見を頂くことができた．

• 振り返り会　最終成果発表会が終わると，高森満様と木下実様による振り返り会が行われた．そこで，

成功したことや失敗したことを思い出し，プロジェクト学習で１年間私が何を学んだのかを

明確化できた．また，他のメンバーの考えを共有することにより，自分も当てはまる点が多

く大変勉強になった．また，5月に行われた合同キックオフで私がこのプロジェクトで何を

学びたいか書いたものを改めて見て，過去の自分と今の自分を比べ，見つめ直すことがで

きた．

• 個人の学び　私はこのプロジェクト学習での 1年間を通して，多くのことを学ぶことができた．まず，

ミーティングにおいて話を進めることの難しさだ．私は元々イベント班リーダー二人のうち

の一人だったので，話を進める立場にあった．しかし，ファシリテートした経験がほとんど

なかったため，その日のミーティングの終着点が見えなくなってしまった．そのことで話し



合いに参加するメンバーも意見を出しづらい状況をつくってしまった．それは，明らかな

ミーティングへの準備不足によるものだった．そこで，ミーティングを行うときは今日は何

をいつまでに決めるかなどをあらかじめしっかり決め，前のミーティングで決まった大事な

ことは可視化しておかなければならないということを学んだ．

　また，設計や実装などを行うときにスケジュールをたてることの重要性を学んだ．そのた

めには見積もりをしっかりすることが重要となる．スケジュールをしっかり立てないと本当

に終わるのか心配な状況で活動を行うことになってしまい，モチベーションの低下にもつな

がってしまう．グループ開発においてメンバーのモチベーションを維持させることはとても

重要であり，進捗に大きく影響してしまう．そのため，メンバーのモチベーションを維持す

ることはとても重要であった．

　技術面では設計の難しさを学ぶことができた．今まで UML 図をかくことがほとんどな

く，設計で作った UML図を誰が見てもわかるような見やすい図にすることがいかに難しく

重要か身を以て実感した．また，実装でも外部処理，内部処理ともに経験することができ，

Webサイトの構築に必要な技術の基礎が培われたと考えている．


5.3 兵藤允彦

• 前期キックオフ　これから 1年間本プロジェクトを進めていくために必要なプロジェクトリーダー決定やグ

ループ分けを行った．そこで私は，プロジェクトリーダーに立候補し，メンバーの承認を得

て，プロジェクトリーダーとなった．また，グループ分けではイベント班の B グループに

所属することが決定した．また，本プロジェクトには通常の担当教員とは他に，企業講師と

して企業の目線から本プロジェクトに関してアドバイスをしてくださる高森満様，木下実様

に年に数回来校して頂いた．その企業講師を迎えキックオフ会を行った．このキックオフ会

ではアイスブレイクとして各チームでペーバータワーの作成を行った．Bチームとしてこの

ペーパータワーを行ったことでチームの交流を図ることができ，チームメンバーの個性など

を知ることができた．

• 勉強会　今後の模擬開発演習や本開発に必要な知識を身につけるために様々な勉強会も行った．

ソースコードなどのバージョン管理をするための Subversionの勉強会，今回の開発に用い

るプログラミング言語である PHPのフレームワーク CakePHPの勉強会，プロジェクト管

理ツールである Redmineの，報告書など様々なドキュメントを作成する上で必要な日本語

運用ミニ講座を行った．

• 模擬開発演習　 5月から本開発に向けた技術習得として模擬開発演習を行った．この模擬開発演習は，本

プロジェクトの担当教員である大場みち子教授をお客様として，面談予約管理システムの開

発を行った．その模擬開発演習で使用する既存システムのソースコードの理解や既存システ

ムの開発依頼書，要件定義書の確認を私も含めメンバー全員で行った．

　まず，既存システムのソースコード，開発依頼書，要件定義書を踏まえお客様 (大場みち

子教授) がどのような機能が欲しいかといった要求を聞き出すためにヒアリングを行った．



このヒアリングを行う前にどのような要求が想定されるかどうかなどヒアリングを円滑に進

めるためにチームメンバー間で何度もミーティングを行った．その結果を踏まえ，要求を

チームメンバー間で分析を行い新システムの要件定義書とユースケース記述を作成した．要

件定義書作成やユースケース記述を作成しながら同時に，ユースケース図やデータベース定

義書，ER図，画面遷移図を作成した．要件定義書や UML図は TAである先輩方になんど

もレビューやアドバイスを頂きながら何度も修正をし，より完成度の高いものを目指した．

要件定義書や UML図など一通りのドキュメントの作成完了後に私たちがまとめた要件とお

客様に相違がないとを確認するため 2回目のヒアリングを行った．その後，データベースの

構築をし，インデックス命名規則に関するドキュメントを作成した．そして，実装では主に

ユーザアカウントに関する，ログイン，ログアウト，パスワード変更，その他バリデーショ

ン処理の実装を担当した．さらに，この模擬開発演習ではリーダとしてメンバーそれぞれの

得意分野を見つける努力もした．これが後の本開発にとても役に立った．

　また，企業講師によるテレビ会議やレビュー会では，模擬開発演習の進捗状況を報告し，

多くの貴重なアドバイス等を頂いた．

　模擬開発演習は，6月に引き続き実装を行いつつ，システムテストに関するミニ講義を受

講した．この講義を元に実装完了後，システムテストを行った．

　 8月初旬，約 1ヶ月程度の模擬開発演習で開発した面談予約管理システムの納品会を行っ

た．私たち Bチームでは，お客様である大場みち子教授に無事要件通りのシステムを納品

することができた．

• 中間発表会　私は，プロジェクトリーダーとして全体のまとめ役に徹した．まず，発表資料としてスラ

イドとポスターを作成しなければならなかったため，プロジェクトリーダーとグループリー

ダを除く 11名をスライド班，ポスター班に配属させるための人選を行った．さらに，中間

発表会までのスケジュールを作成し，いつまでにスライドやポスターを完成させなければな

らないのかをメンバーに報告し共有した．また，私はプロジェクトリーダーであったため，

スライド班とポスター班のすべての会議に参加し，各班のサポートを行ったり，一通りでき

たスライドやポスターを客観的に評価をして頂くためにプロジェクト担当教員や TAの皆さ

んにレビューの要請についても行った．また，中間発表会に向けた発表練習も行うために発

表当日の役割分担の人選も行った．

　中間発表会が間近にせまり，発表会ギリギリまで発表資料の修正や発表練習を行ってい

た．その中でプロジェクト担当教員や TAの方々に発表技術に関するアドバイスや発表資料

に関するレビュー等を頂き，最後の最後まで良い発表良い資料を目指し活動を行っていっ

た．また，企業講師である高森満様にスライドの遠隔レビューを頂き，企業目線でのアドバ

イスを頂いた．私たちの中間発表会の会場はミュージアムに決まったため，少し他のプロ

ジェクトと差別化を図るため工夫した発表会にしようとリーダー会議で決まった．具体的に

は，もうひとつの高度 ICT 枠のプロジェクトである「No.8 北海道の魅力創造プロジェク

ト」と合同で発表を行うことを提案したり，スライド発表，ポスター発表，デモ展示の他に

メンバーの活動風景を映したスライドショーの上映や，iPadを用いて要件定義書などのド

キュメントも展示しようと提案した．また，リーダーとしてどうすれば発表会が成功するの

かを常に考え，会場の配置を決め，設営時のまとめ役を行った．

　中間発表会当日は，会場の最終設営や最後の発表練習を行い本番に臨んだ．本番では，ス

ライドを投影していたプロジェクタが破損してしまうトラブルもあったが，メンバー全員が



練習の成果を発揮できた．また，発表には多くのお客さんに訪れて頂き，用意していた準備

していたアンケート用紙が足りなくなってしまうという嬉しいトラブルもあった．

• 中間報告書　中間発表会終了後，すぐに中間報告書の執筆に着手した．ここでは，プロジェクトのメン

バーが作業しやすいようにリーダーでグループ報告書および個人報告書のテンプレートを

作成したり，中間報告書提出締め切り日までのスケジュールの作成を行った．また，メン

バー間でのレビュー会の企画やプロジェクト担当教員や TAの方々へのレビューの要請等を

行った．

• オープンキャンパス　 8 月には高校生向けに公立はこだて未来大学で開催されたオープンキャンパスにも出展

をした．発表資料としては，中間発表会の時に利用したポスターと模擬開発演習で開発した

デモを展示した．中間発表会とは異なり，高校生向けに説明を行わなければならなかったた

め，分かりやすい説明をしようということに徹底した．

• 後期キックオフ　夏期休業期間が終わりプロジェクト学習の 2週目の時間に企業講師である高森満様と木下

実様が来校してくださった．その際，イベント班，野外劇班の進捗状況の共有会と「マシュ

マロタワー」と呼ばれるアイスブレイクを行った．進捗状況の共有会では，私たちが考えた

サービスをうまく企業講師の方々に説明することができず，自分のプレゼン力の低さが露呈

してしまった．そして，アイスブレイクでは前期の始めに行ったアイスブレイクと同じチー

ムで行った．前回のアイスブレイクでの反省を生かそうと努力したが，中々記録が残せず，

段取りの悪さについても露呈してしまった．このキックオフ会では，自分を見つめ直す良い

機会となった．

• 本開発

現状調査まず，函館市近郊のイベント情報を発信しているWeb サイトの調査を行った．

その結果を踏まえ函館市近郊のイベント情報を発信している 3つの施設にヒアリングを行っ

た．私は，実際に函館市青年センターに訪問し．ヒアリング内容のメモを記録した．

サービスの考察 6月，7月，9月にかけて，本グループが提供するサービスについての考

察を行った，しかし．夏期休業期間中インターンシップの参加などで中々メンバーが集まる

日を設けることができず，Skype会議中心となってしまった．この Skype会議では，どの

ようなサービスを提供するべきかを何度も考えたが中々全員が納得するような案が決まらず

にいた．この原因として，私たちは現在のイベント発信に関する問題点を洗い出し，それが

解決できるようなサービスを提供しようと考えていた．しかし，それでは本当に利用するエ

ンドユーザにとって嬉しいのだろうかといった議論が収束せずメンバーの意見を一致させる

ことができなかったことにある．また，毎回の会議の進め方に関してもメンバーから不満が

でるなどして全く議論が進まないといったこともあった．

　また，9月においても，Skype会議を数回行ったのだが，夏期休業期間が続いたため中々

全員が会議に参加できず会議があまりうまく進まないという状況が続いていた．そこで私は

ある Skype会議時にこの中々会議が進まない状況をなんとか打破しようと現在の問題解決

プロセス方法であった「イベント発信に関する問題点を洗い出し，それが解決できるような

サービスを提供しよう」とう方法から「まず．私たちがエンドユーザに立ったときあったら

嬉しい機能は何なのか」というプロセスから考察しその機能でどんな問題点が解決できるか



という逆のプロセスで考えてみてはどうかと提案をした．その結果，他のメンバーから承認

を得て，次回全員が集まれる日を設定し会議を設けようという話になった．

　そこで私は，その会議を成功させるために 8月に参加したインターンシップでWebサー

ビスを考える際に活用した方法を行ってみようと思った．その具体的な方法とは，まず付箋

も模造紙を用意し，メンバーそれぞれに付箋を配布しそこに自分がエンドユーザに立ったと

きにあったら嬉しい機能のアイディアをできるだけたくさん書き出してもらった．その後，

アイディアを書き出した付箋をそれぞれメンバーが自分の書いたアイディアを発表しながら

模造紙に張り出した．そして，模造紙に張り出された多くのアイディアのグルーピングを

行った．その結果，もっとイベントを簡単に探したい，検索機能が充実していると使いたく

なる，といった結果が得られた．次に，これを洗い出された問題点と照らし合わせてみると

問題点についても解決できそうだという話にまとまった．つまり，ここでようやく私たちが

提供するサービスが決まった．このように思考プロセスを変えることで意外にもうまく解決

策が見つかってしまったことに驚き，とても良い経験となった．

　また，私たちが提供するサービスの名称についても決めた．決定に至るまで，私はイン

ターネットでWebサービスの名称を決め方などの調査を行った．そして，参考サイトをメ

ンバー全員で共有しタスクとしてサービス名をメンバーそれぞれに考えてきてもらった．メ

ンバーそれぞれのアイディアを踏まえ最終的に投票を行い「HakoEve」という名称に決定

した．

提案私たちが考えたサービスを実現させるために，函館市近郊のイベント情報を網羅的に

発信しているまちセンにご協力頂ければ，このサービスが実現できるのではないかと考え

た．そこで，私たちリーダーは，まちセンに私たちの考えたサービスを提案させて頂きたい

という趣旨のアポイントを取り，提案のための資料作りに取りかかった．提案資料としてス

ライドを採用し，リーダー 3 人で資料を作成した．スライド作成時にはプロジェクト担当

教員や TAの方々に多くのレビューを頂き，とても参考になった．例えば，スライドは聞き

手の人がどういう人なのかを考えて作らないと全く伝わらない資料になってしまうというア

ドバイスを頂いた．また，当初作成していたスライドでは，想定する画面イメージをイラス

トで描いてそれを資料に貼付けていたのだが，それでは聞き手側にとっては全く伝わらない

という指摘も受けた．そこでよりWebサイトのイメージを持たせるためにブラウザのフッ

ターを加えて，より本物らしい画面イメージを作成した．

班構成の検討サービスの考案にも目処が立ち，次に私は設計，実装に向けたグループ分け

を行った．グループ分けは私が行い，設計では機能班とデータ班，実装ではクライアント班

とサーバ班という班構成にした．班員の人選を行う際，私は模擬開発演習でメンバーの得意

分野を発見できたということからこれを生かして班分けを行おうと考えた．

設計・実装メンバーのグループ分けが完了し，設計・実装に取り組んだ．リーダーである

私はどちらのグループにも属さずに全体のまとめ役に徹した．各グループのサポートや進捗

管理，そして各グループの進捗状況を考慮したスケジュールの作成を行った．さらに，各グ

ループの進捗を共有できるような仕組みを考えたり，メンバーが作業しやすいような環境づ

くりを整えるように努力した．

サーバの構築私は 10月の提案時にお約束した HakoEveの実装完了の目処がたったので，

12月の初旬の進捗報告会に向けてテスト用サーバの構築を行った．サーバの構築について



は具体的にニフティクラウドを利用し，Apache，PHP，MySQL，PHPMyAdminのイン

ストールを行った．サーバの基本的な構築は，システム管理方法論の講義を受講していたの

でスムーズに行うことができた．さらに，進捗報告会のアポイントのメールを送る際，デー

タベースの保存しておくタグと開催場所の候補をまとめたドキュメントも作成しそれについ

てもまちセンに報告をした．

評価 12月 1日日曜日，まちセンに HakoEveの進捗報告を行った．私は，まちセンのセン

ター長様などに HakoEveの機能の紹介をした．10月に一度訪問させて頂き，発表をさせて

頂いたので割と落ち着いて報告をすることができたと思っている．その結果，HakoEveに

関してとても喜んで頂き，今後の調整に関するお話も行うことができた．

• アカデミックリンク　 11月に開催された「HAKODATEアカデミックリンク 2013」の出展に必要な概要文を

考えたり，プロジェクト担当教員にデモ展示用の物品要請また，デモ用の iMacの環境構築

を行った．また，この発表会に必要なポスター作成のサポートも行った．

　この出展に見学に来るお客さんは，他大学の学生や教員また，函館の一般市民であった．

つまり，情報技術にあまり詳しくない人たちに私たちの活動について理解して頂く必要が

あった．そこで，私はなるべく技術的な話は避け，HakoEveの嬉しさや便利さを中心に説

明を行った．また，HakoEveはこの発表会が初のお披露目でもあったため見学に来て頂い

たお客さんに HakoEveを使ってみたいと思って頂けるようけるよう，なるべくエンドユー

ザ目線にたった説明を心がけた．

• 最終成果発表会　最終成果発表の準備を行う際，他のメンバーは実装のタスクがあったため中間発表会とは

やり方を替え私が中心にスライド作りに取り組んだ．スライドは，野外劇班も合わせて 15

分程度の発表時間しかないことを踏まえて作成する必要があり，スライドに盛り込みたい内

容が多すぎて，逆にどの部分が省けそうかということにとても悩み，苦労した．

　最終成果発表会当日は，私も含め全員がスライド発表を行った．私は，発表会ギリギリま

でスライドの作成に追われていて中々発表練習を行うことができなかった．案の定，発表当

日も思うように発表ができずもっと練習しておけばと今では後悔している．また，他のメン

バーにもギリギリまでスライドの最終版が完成せず迷惑をかけてしまった．最終成果発表会

では，中間発表会の反省を生かしプロジェクタの予備を用意した．

• 最終報告書　最終報告書の執筆については，私は報告書完成までの見通しを立て，スケジュールを作成

した．冬休みは，数回の Skype会議を設定しすべての回においてファシリテートを行った．

また，プロジェクトリーダーとしてグループ報告書，個人報告書の他にプロジェクト報告書

の執筆も行った．

• 個人の学び　私は，この 1 年間プロジェクト学習を通して様々なことを学ぶことができた．特にプロ

ジェクトリーダーとしてマネジメントに関することを多く学ぶことができた．今回は，その

中でも 2つ紹介する．

　 1 つ目はメンバーで会議の進め方に関することである．会議は事前の準備が必要不可欠

で，その会議での懸案事項は何か，またどのような時間配分で誰がまとめ役をするかなどを

事前にしっかり決めておく必要があるということを学べた．プロジェクトが始動して間もな

いときは，会議を何となく開き何となく終わっていたのが事実だ．しかし，それではその会



議自体の意味が不明瞭で意味のある会議とは全く言えなかった．その部分に気付く事がで

き，改善できたことが大きな学びだと思う．また，会議の話し合いをまとめる，いわゆる

ファシリテーターとして，さらに，決断力や段取り力に関してはまだまだ反省するところが

たくさんあり，悔しい思いを何度もした．今後，またこのような機会があるならば，この部

分に力をいれてもっと自分のマネジメント力を向上させたいと思う．

　 2つ目はスケジュールに関することである．結論から言うと，今回のプロジェクトで 1年

間も見通したスケジュールを作成することはできなかった．マイルストーンごとの短期的な

スケジュールは何度も作成したもののそれでは，中々年間を通したプロジェクトのイメージ

が共有できず，メンバーには迷惑をかけてしまった．今考えると最初の段階で明確なスケ

ジュールを作成しておけば，もっとスムーズにプロジェクトが進んだのではないかと思う．

したがって，私はスケジュールの重要性についても学ぶことができた．


5.4 斉藤篤史

• 前期キックオフ　 5月に企業講師の方を招きプロジェクトの立ち上げを行った．そのときは，プロジェクト

のリーダーを決め，プロジェクトチームをグループ A，B，Cの 3つに分けた．これは模擬

開発演習のためのグループ分けである．この後に，グループの親睦を兼ねてアイスブレイク

を行い，そこでは，グループ内でのグループディスカッションやタスク割り，目標に対して

どれくらい成果を挙げられるかといったプロジェクト活動の概要を学んだ．実際の内容は，

A4 サイズの紙を使ってペーパータワーの高さをグループ毎で競い合うというものだった．

私はこの競技中あまりディスカッションに参加できなかった．元々意見の出し合いに関して

アイディアが思いつかず周りの意見に同調するばかりだったからだ．アイスブレイク後，個

人の目標をグループ毎でまとめて発表することを行った．そこで私はシステム開発で使用す

る CakePHP 言語の習得とプレゼンテーションのスキルを身につけたいという目標を立て

た．

　プロジェクトの立ち上げ後，プロジェクト進行のための環境構築を行った．環境構築は

タスクの進捗管理などが行える Redmineの導入や，成果物の管理をするための Subversion

の導入をした．

• 勉強会　模擬開発演習に先駆けて実装の際に使う PHP言語のフレームワークである CakePHPの

勉強会を行った．勉強会ではまず，CakePHPで実装が行えるよう XAMPPや phpMyAd-

min，eclipseの導入を行った．その後，CakePHPの基本モデルであるMVCモデルを勉強

し，簡単な演習問題を何題か解いて CakePHPでの実装に慣れようとした．

　 5月下旬には模擬開発演習以降でも使う Astahの導入を行った．

• 模擬開発演習　 6月に模擬開発演習が本格的に始まり，グループ毎での作業が主になっていった．私はグ

ループ Cの一員として活動をし，模擬開発演習では伊藤恵准教授がお客様役としてシステ

ムの開発を行った．

　グループ Cはまず伊藤恵准教授にヒアリングを行い，インターフェースの構成など開発



依頼書に記載されていない要件を聞きだすことができた．開発依頼書に加えてヒアリング調

査で得た要件を基に要件定義を行い，要件定義書の作成をした．それと同時にユースケース

図の作成も行った．私はユースケース図作成の担当であり，要件定義から図の作成とユース

ケース記述を行った．その後，業務フロー図の作成をした．

　また 6 月に企業講師の方とテレビ会議を行い，模擬開発演習の進捗報告をしレビューを

頂いた．レビューでは「ユースケース図と業務フロー図の番号の対応がとれていない」や，

「それぞれのドキュメントで用語の整合性が取れていない」，「そもそも用語の定義自体がで

きていない」といった多くの指摘を頂いた，それによりドキュメント作成や作業の進め方の

難しさを実感することができた．テレビ会議の後，今までの作業の進め方や作成したドキュ

メントを見直し，班全員が作業しやすい体制で行えるよう班全員で意見を出し合い実際に行

動に起こしていった．また模擬開発演習中での実装では，ペアプログラミングで協力しなが

ら，粘り強く取り組んだことで実装に大きく貢献できた．

　 8月に模擬開発演習で開発したシステムの納品会を行った．納品会では，実際に完成した

システムを動かしながら発表を行った．その中で，「システムのデモンストレーションの際

に，実際の業務で使われると想定されるデータでデモンストレーションしないといけない」

と教員から指摘を頂いた．

• 中間発表会　 7月は模擬開発演習と同時に，中間発表会に向けての準備が行われた．準備ではポスター

製作の活動に携わった．ポスター製作では本開発で考えるサービスのステークホルダ図のた

たき台を作成し，ポスター製作に貢献した．中間発表会では，発表中で出た質問をまとめる

議事録を担当した．

• 後期キックオフ　 9月下旬にプロジェクト後期の活動が始まり，本開発の活動が本格的になった．後期の始

めの活動でも企業講師の方を招き，前期と同様にキックオフを行った．キックオフでは段取

り力をテーマにアイスブレイクとして，マシュマロタワーを建設しその高さを競い合った．

前期に行ったアイスブレイクよりも難易度が高く，より作業に対する時間のかけ方に注意し

なければならないので，競い合った班それぞれの段取りする能力が試されるものであった．

• 本開発

現状調査本開発では函館市近郊のイベントがどのように発信されているのかその現状を調

べるところからはじめた．まず，私たちは函館市近郊のイベント情報を発信している 3つの

施設にヒアリング調査を行った．私は 3つの施設の内のひとつである文化スポーツ振興財団

のヒアリング調査に同行した．私はそこで記録係りをしていたが，メモを取ることに精一杯

でヒアリング中に質問をすることができず，話を膨らませることができなかった．ヒアリン

グではメモを取ることもさることながら，用意した質問だけじゃなく会話中にふと思ったこ

とでも質問し，話を膨らませることの重要さを知った．

サービスの考案夏季休暇中は本開発で考えるサービスの内容について何度かミーティング

を行った．またメンバーが集まれない日は Skypeでもミーティングを行った．ミーティン

グでは前期中の活動で上げられた問題点をどう機能を持たせれば解決できるかについて話し

合いを行ったが，ミーティングはなかなか進展せずに 8月を終えてしまった．その原因とし

て，メンバーそれぞれが本プロジェクトで扱う問題点に対する考え方や意識の持ち方が曖昧

でしっかりと意識を共有する場を設けられなかったことが考えられる．



　夏季休暇最終日にもう一度集まりミーティングを行った．ミーティングでは夏季休暇中で

行ったミーティングの進め方で行わず，メンバーひとりひとりがユーザの立場に立ってどう

いう機能があればうれしいかを考え意見を出し合った．そうすることによって今までのミー

ティングよりもスムーズに進みプロジェクトを進展することができた．

　後期の活動が始まり，企業講師の方にプロジェクトの今後の活動の進め方を発表する機会

があり，そこでは，メンバー間での問題点に対する意識の共有が曖昧だったことから，プロ

ジェクト憲章を作成することで意識の共有を促すというアドバイスを頂いた．またドキュメ

ントの作成の際には，いきなりタスクを割り振るのではなくメンバー 1人がたたき台を作成

して，それをメンバー全員でレビューしドキュメントの雛形が出来上がってからタスクを割

り振った方がいいといったアドバイスも頂いた．それ以外にも，同じグループ内に複数リー

ダーが存在するのはメンバーが混乱するので，リーダーを 1人に絞るべきだという議論があ

り，議論の末リーダー 1人を決定することができた．

　企業講師の方のアドバイスを基に，私はプロジェクト憲章のたたき台の作成を行った．た

たき台の作成には私を含め 2名で作成を行ったが，それぞれ別々で作成した．これによって

ドキュメント作成がスムーズに進み，またこのプロジェクト憲章を作成することによってメ

ンバーの意識を統一することができたので，意識統一をしっかりとアウトプットし，それを

共有しなければならない重要さを知ることができた．

　キックオフ後の活動で本プロジェクトの目標のフォーカスを絞り，まちセンのWebサイ

トにあるイベント情報発信ページの問題点をメンバーで意見を出し合いながら洗い出し，そ

の問題点を解決するサービスを構築する方針で固めた．

提案 10月にスケジュールを見直し，修正を行った．

　 10月のまちセンのサービス提案に向けてサービスの機能の詳細決定や提案時に必要なド

キュメントの作成を行った．サービス提案には 2 つ案を用意した．1 つはそのサービスを

まちセンに運用して頂き，まちセンのWebサイトにあるイベント情報発信ページからこの

サービスに差し替えて頂く案である．もう 1つはまちセンが所有するイベント情報を利用し

て独立したサービスを構築するケースである．これらを提案するドキュメントにまとめた．

　 10月上旬に作成したドキュメントと共にまちセンに訪問し，本プロジェクトで考案した

サービスの提案を行った．その結果，まちセンがそのサービスを運用するケースで合意を得

ることができた．

　その後，サービス名が HakoEveに決まり，開発も設計段階に入った．

設計設計ではグループを機能の外部的な設計を行う機能班と内部的な設計を行うデータ班

に分けて活動を行い，私はデータ班で活動した．データ班ではデータベースの設計，ER図，

テーブル定義書の作成，phpMyAdminでのデータベースの作成を行った．

実装 10月下旬から実装が始まり，それに伴い新たに班を変えて画面のレイアウトやユー

ザインターフェースを実装するクライアント班と機能の実装をするサーバ班に分かれて実装

を行った．実装はペアプログラミングを採用し，私はサーバ班で活動した．

　 11月でも引き続き，HakoEveの実装を行った．サーバ班ではあまり貢献することができ

ず，簡単な削除機能を実装する程度しか貢献できなかった．タスクとして HakoEveの 4つ

の検索機能の 1 つである日付検索の実装を任されたが，実装がうまくいかず途中で班の他

のメンバーに任せてしまうことがあった．実装に関してもう少し勉強するべきだったと思っ

た．



　 11月下旬に差し掛かるとまちセンに HakoEveの進捗報告会や最終成果発表会の準備も

あり，班の内，何名かがポスター作成やスライド作成のために実装作業から抜け出さなけれ

ばならないことが何度かあった．ペアプログラミングで開発を行ってきたがこのようなこと

があったため，この頃は 1人で実装していた．

評価 12 月 1 日にまちセンへ HakoEve の進捗報告会を行いこのときに開発中のサービス

を使って頂いた．それに伴い様々なコメントを頂き，このコメントを基に仕様の変更をする

ことがが決まった．

• アカデミックリンク　 11月中旬にはアカデミックリンクに参加することもあり，アカデミックリンクに向けて

本開発の実装と並行してポスター作成を行った．私はポスター作成の活動に携わらなかった

ので，ポスター作成の間は引き続き実装を行った．アカデミックリンクを前にして，出来上

がったポスターを使ってポスターセッションの練習をした．始めの練習は TAを交えながら

行い，その後多くの指摘を頂いた．2回目は企業講師の方を前に練習を行い，その後発表仕

方に関して多くの指摘を頂いた．だがその中での練習は 1回だけで終えてしまいあまり多く

できなかった．当日は普段では耳に入らない他大学の研究活動の話を聞くことができとても

有意義な時間を過ごせた．私たちが出展するブースの 30秒紹介を任され，緊張したがとて

もいい経験になった．ポスターセッションではやはり練習量が足りないせいか，あまりうま

く説明できなかったところもあり練習はやはり重要だと実感した．

• 最終成果発表会　 12月 6日に最終成果発表会というマイルストーンがあり，それに向けて最終的な調整を

行った．最終成果発表会ではプロジェクトメンバー全員がスライドの発表を行うので，私は

初めてスライド発表をすることになった．アカデミックリンクでの反省もあり，当日の本番

直前までスライドの発表練習を行った．発表練習では実際に発表時間を計りながら行い，ど

この部分で説明に時間が掛かり，説明ができなかったかを明確にしていった．説明に時間が

掛かる部分はどこを削るべきか考え，説明できなかった部分は他のメンバーの発表を参考に

したり，メンバーで話し合って説明する内容を決めていった．また，発表会前日に想定質問

を列挙し，それに対する回答をグループメンバーで考えそれを共有しまとめる作業を行っ

た．

　当日はポスターセッションとスライド発表を担当し，ポスターセッションでは自分が担当

していないポスターの説明をしたり，質問に対してできるだけ丁寧に答えられるように努力

した．スライド発表では，声を大きく出すようにし，話を聞く人の方へ向いて発表するよう

心がけた．練習の成果があってか，思いのほかスムーズに発表を進めることができた．

• 振り返り会12月 20日に企業講師の方を招き，プロジェクトの振り返りを行った．振り返りでは，写真

を通してプロジェクト 1 年間を振り返ったり，ポストイットに 1 年間の学びや気づきを書

いてグループでそれをまとめて，発表した．発表では何を学べたか，どんな気づきがあった

か，後輩にどのようなアドバイスを送るかなどといったことを発表した．

• 個人の学び　私は 1年間，このプロジェクトを通して学んだことが 3つある．まず 1つ目にプロジェク

トの工程について学べた．プロジェクトでの開発において問題の発見，要求定義，設計，実

装，テスト，納品までの流れを模擬開発演習で学ぶことができ，模擬開発演習中でのヒアリ



ングで，作成したドキュメントを使ってシステムの説明したり，またメンバー間で情報を共

有するためにも使われ，上流工程で作成するドキュメントの大切さを知ることができた．ま

た本開発でサービスを考える際，イベント情報発信に関してどのような問題を抱えているか

を洗い出し，それをどう解決していけばいいのか，なかなか解決策を生み出せなかったりと

どういう方法で解決していくのか模索する難しさを実感することができた．

　 2つ目はチームで作業する難しさを知ることができた．一見，チームで作業することは 1

人で何かを成し遂げようとする分，比較的楽に見えてしまう．だが，情報の共有不足によっ

てミーティングが思うように進まなかったり，プロジェクトそのものの目標や目的が揺らい

でしまったり，お互いが今どんな活動を行ってどの程度まで進んでいるのかがわからなかっ

たりすることもあって，チームで作業する難しさを痛感することが多くあった．特にドキュ

メント作成において用語の定義が曖昧だったために人によって用語がバラバラで記述された

り，文言が統一されてなかったりとドキュメントの修正に多く時間を費やしてしまった．

　 3つ目は積極性を持つ大切さを学んだ．私は元々，あまり積極的な行動をとることが少な

くいつも周りの意見を聞く聞き手になってしまい，発言することができなかった．プロジェ

クトでのミーティングでも最初は意見も出せず，ただただ周りの意見を聞くだけだった．だ

が，責任のある仕事に課せられ，その仕事で周りのメンバーをどう促していけば意見が出し

やすくなるか考えさせられ，その難しさを知ったことで今のままの自分でいるのではなく

て，勇気を持って意見を言える自分に変わらなければならないと思うようになった．積極性

を持つことによりミーティングでの内容も記憶に残りやすく，またそのおかげで自分の意見

を言いやすくなり，積極性を持つ大切さを実感することができた．


5.5 小田大介

• 前期キックオフ　プロジェクトが開始され本開発に向けたチーム分けを行った．私は ABCの 3グループの

なかのグループ Cに所属することとなった．チーム分けののちに特任教授である高森満氏，

木下実氏と担当教員の方々を交えたキックオフ会を行った．キックオフ会では主に自己紹

介，大まかなプロジェクト活動計画，各々のプロジェクト学習に対する意気込みの発表など

をした．意気込みを発表する場において私は，プロジェクトを通して，自らの実装力及び，

積極性を身につけていきたいとプロジェクト関係者に公言した．また，チームごとにペー

パータワーを作るというアイスブレイクを体験することで，チームメンバーの特色をある程

度知ることができ，親睦を深めることができた．更に，チーム活動において協調性，積極性

が非常に重要であることをを企業講師の方々から学ぶことができた．

• 勉強会　プロジェクト計画の 1 つである模擬開発に向けて，技術を習得するために勉強会の時間

が設けられた．模擬開発では，CakePHP を用いる予定であったため，PHP の学習及び，

MySQL等の扱い方を重点的に学習した．勉強会の際には TAの方々に基本的な概念であっ

たり，演習を通した指導を頂くことができ，順調に模擬開発に向けた技術習得をすすめるこ

とができた．しかし，私自身の技術習得のスピードが他メンバーより少々遅かったため，時

間外での技術習得に時間を割くことは惜しまなかった．



• 模擬開発演習　模擬開発では面談予約管理システムを構築するため，依頼者と見立てられている担当教員

の伊藤恵先生に対してシステムに関するヒアリングを行い，システム要件や要望を引き出し

た．ここで得られた情報を要求定義書としてまとめた．設計段階に入り，UML作成を行っ

た．チーム内でタスク振りが行われ，私は画面遷移図の作成を重点的に行うこととなった．

他メンバーは情報システムコースの授業でドキュメント作成の心得があったが，私はそれら

の授業を受けていなかったため，UML作成の知識はなかった．しかし，この作業を通して，

UML作成のノウハウをある程度身につけることができた．これらで完成したドキュメント

を依頼者とのヒアリングを通して確認及び新たな要望を追加する，また企業講師の高森満

氏，木下実氏に TV会議でのレビューをいただくことによって，UMLの質を徐々に高める

ことができた．数回のヒアリングの末，最終的に依頼者から提案システム開発の了承を得る

ことができ，実装段階に移行した．私自身は主にログインのための認証に関する実装を行っ

た．

　 7月では 6月に引き続き実装を行い，8月の納品会に向けた機能の実装及び，テストを重

点的に行った．実装では，納品の機嫌が間近に迫っていたため，時間外の活動が余儀なくさ

れた．この中で我々プロジェクトメンバーは，体調管理，また精神的な管理をそれぞれで行

うことができ，多くの教訓を得ることができた．

　 8月では間近に迫った面談予約管理システムの納品期日に向けた未完了部分の実装を行っ

た．面談予約管理システムの開発にあたり，新しく生まれた要望等新たな機能として実装す

る余地はあったものの，本開発のスケジュールとの兼ね合いを考慮した結果，納品に必要な

最低限の機能を持った面談予約管理システムを納品するという結論に至った．従って実装す

るタスク量は本来予定しているものより増えることがなかった．こうして，完成した面談予

約管理システムは，依頼者である伊藤恵先生と納品会という場を設け，納品することがで

きた．

• 中間発表会　 6月の下旬には，7月の中間発表に向けての発表資料作りも行った．資料作成の際には，

ポスター作成班とスライド作成班に分かれた．その中で私はスライド作成班のリーダーとし

て任命された．実際にリーダーとしてスライド作成をすることで，スライド作成の心構えの

みならず，リーダーという立場の認識等を改めることができた．また，チームを管理する際

には，メンバーのモチベーションを高く保つことが作業効率化につながることを知ることが

できた．

　 7月上旬では中間発表会に向けての資料作成と発表練習を行った．担当教員，TAの方々

に発表資料及び発表技術に関するレビューを行って頂いた．それらのレビューを資料，発表

に反映させ，徐々に発表全体の練度を高めていった．発表の担当者の一人として，私も練習

を多くしていった．練習のこなしていないはじめの方では人前に立つことになれていなく，

自分の思ったようにうまく発表ができなかった．しかし，プロジェクトメンバーに対して多

くの発表練習をすることで，ある程度人前に立つことに慣れることができた．また，発表技

術に関しても多く学ぶことができ，当初に比べて自覚できるほどに成長することができた．

　中間発表会当日では，会場の設営及び発表の最終確認等を行い，本番に臨んだ．会場設営

においては，来往者の目線に立った設営を心がけることができた．本番では，練習の成果を

十分ではないが，ある程度発揮することができ，発表を見てくださった人達から多くの質疑

を受け，本開発をよりよくするためのアドバイスをいただくことができた．また，本番中に



プロジェクタが破損する予期せぬトラブルが発生し，リスク分析の重要性を身を持って知る

ことになった．

• 中間報告書　中間発表の前期の活動のまとめと報告書作成を行った．私は模擬開発の開発プロセスの執

筆担当になった．作成した報告書はプロジェクトメンバー同士のレビュー，担当教員，TA

の方々からもレビューを頂くことができ，多くの修正をし，より良い報告書を提出すること

ができた．

• 本開発

現状調査扱うテーマは函館市近郊のイベント情報の集約及び発信であり，現状の函館市

のイベント情報を扱っているWebサイト及び施設を調べ，函館市地域交流まちづくりセン

ター，函館市青年センター，函館市文化・スポーツ振興財団の 3団体に対してヒアリングを

行うことが決定し，事前に 3団体とヒアリング日時の確認を取り合うことができた．私自身

は函館市青年センター様のヒアリング担当として，函館市青年センターに行くことになり，

質問事項等をまとめたドキュメントを作成し，ヒアリングに臨んだ．実際のヒアリングを通

して，目上の方に対する態度等，社会人としての身の振る舞い方を学ぶことができた．これ

らのヒアリングで得ることのできた情報をのまとめを行い，今後のイベント班活動方針につ

いて話し合いをした．

サービスの考案中間発表，納品会を終え，夏休みを各々で過ごすことになったが，この夏

休みでは本開発に向けた技術習得として各自で勉強することとなった．本開発で構築した

サービスをモバイルで提供するための技術として JQueryの知識が必要であるとのことが会

議によって判明した．そこで私はこれに関する技術習得として本を情報ライブラリから借り

出し，夏休み中に勉強することになった．

　今後の方針を定める必要性が当時あったため，複数回 Skype会議が設けられた．複数回

にわたって会議が行われたため，会議の進行役を事前に決めるなどの工夫をしていた．しか

し，メンバーが想定していた以上に遠隔で会議を進めることは難しく，夏休み中にプロジェ

クトの今後の方針が定まることはなく，スケジュールに大きな遅れが生じてしまった．この

ことから，遠隔会議には綿密な準備が必要であることを学ぶことができた．

夏休み終了の直前にメンバー全員で今後の活動方針を定めるための会議を行った．これまで

多くの会議でシステム考案に関して議論していたが，なかなか結論に至らず今後の活動方針

を定めることができなかった．そこでこの会議では，今までのシステム考案に至るまでの考

え方を変更し，自分たちの欲しい機能について話し合うことで，構築するサービスの全体像

を大まかに定めることができた．この会議により，既存のイベントが掲載されているWeb

サイトにキーワード検索，日付検索，タグ検索，地図場所検索，推薦機能を追加することに

決定した．また，今後の活動においてメンバー間のイメージ共有のためのドキュメントづく

りが非常に重要な要素であることに気づくことができた．

提案提供するサービスの具体案が定まり，プロジェクトの方針も定まってきたため，プロ

ジェクト憲章を作成した．このプロジェクト憲章のレビューを担当教員，TAの方々に頂き

修正を完了した後に，我々のサービスを運用していただくために函館市地域交流まちづくり

センター様に提案を行った．この提案の際には，まちづくりセンター様の事情を考慮し，複

数の案を用意するとともに，説明するためのシステムのイメージ図を作成した．提案の結

果，函館市地域交流まちづくりセンター様にサービスを運用して頂く了承を得ることができ



た．開発の許しを頂いたため，設計段階へと移行した．

設計設計段階では，内部設計担当のデータ班と外部設計担当の機能班の 2班に分かれて設

計を行った．私はデータ班に所属し，提供するサービスのデータベース設計を行った．ER

図，テーブル定義書の作成を行った．データ班と機能班それぞれの設計が完了した後に，実

装段階へと移行した．

実装実装段階では，クライアント班とサーバー班に分かれて実装を行った．設計段階の

情報を共有しやすいようにどちらの班にも必ず機能班，データ班のメンバーが属するよう

な班分けが行われた．私はクライアント班に属し，サイトのデザインや UIの実装にとりか

かった．実装にあたり，これまで使わなかった cssの知識等が必要となったため，時間外の

技術習得時間を増やしていった．また，これらの実装と並行して，サービス名の考案も行っ

た．プロジェクトメンバーそれぞれから，案を提案し，投票を行った結果，サービス名は

HakoEveと命名された．さらに，HakoEveのロゴを作成する方針となり，クライアント班

の柴田健介が担当者となった．

実装はペアプログラミング方式で行い，クライアント班の西本光司と共に，ボタン作成，検

索結果画面，詳細画面，地図場所検索画面の実装を行った．私は主に，検索結果画面の画面

レイアウトの調節，地図検索におけるマーカーに関する処理等の実装を行った．検索結果画

面実装の際には cssを多く用いることになった．しかし，当初は cssに関する知識が全くな

かったため，実装時の問題解決をスムーズに行うことができるようにと，情報ライブラリか

ら，本を借り出し，時間外での技術習得に時間をかけることを心がけた．また，パートナー

と十分に協力しあい，互いにわからないことを気軽に相談しあえる信頼関係を築き上げるこ

とを意識した．地図検索画面の実装でも，上記の 2つのことを意識して実装を行った．この

ことで，プロジェクトメンバーと協力してタスクをやり遂げる重要性を学ぶことが出来た．

評価最終成果発表会の前に，当時の実装段階では HakoEveメイン機能の実装がある程度

済んでいたため，函館市地域交流まちづくりセンター様に HakoEve の評価をして頂いた．

函館市地域交流まちづくりセンターの方々からは高評価を頂くと同時に，さらに欲しい機能

など，新たな要望等を教えて頂くことができた．最終発表までには，これらの頂いた要望を

全て満たすことはできないが，来年の活動に正しく持ち越すために，HakoEveの仕様変更

に関する会議を行い，HakoEveの新たな実装内容をまとめるドキュメントを作成すること

になった．ここで私は，会議で仕様を変更することに決まった項目の仕様変更前と仕様変更

後の状態を記載する仕様変更ドキュメントの担当となった．

• アカデミックリンク　クライアント班は，アカデミックリンクで展示するデモの実装の完成度を高めるために，

引き続けて実装を行っていた．さらに，本番での発表者として割り振られていたため，ポス

ターセッションの練習，デモ紹介の練習も行った．練習の際には高森満氏に発表に関する指

導をして頂き，内容をより簡潔にわかりやすくするためにするべきこと等，限られた時間の

中で相手に伝えたいことを効率的に伝える技術を学ぶことができた．

　アカデミックリンク本番では，ポスターセッション，デモ紹介を見に来てくださった人達

にある程度リラックスして説明をすることができた．しかし，少々説明に熱が入ってしま

い，予定より長い時間説明をしてしまうこともあった．今後の発表の時には，これまで以上

に時間に気を配るように心がけようと感じた．

• 最終成果発表会



　最終成果発表会が間近に迫り，成果発表会の準備を行った．発表資料としてスライド班と

ポスター班に分かれることとなった．私を含めたチームメンバー 3名は発表スライドの作成

を行った．中間成果発表会ではスライド作成班のリーダーを努めたこともあり，自身のスラ

イド作成の経験を活かせるよう積極的にスライド作成に臨んだ．しかし，スライド作成にあ

たり，発表時間 15分と限られた時間の中，1年間全ての活動を細かく説明することができ

ないことから，スライド内容の多くを説明では省くことになってしまった．この省く説明を

決めることに非常に苦労した．スライド班は発表内容を多く省くということもあり，発表の

流れを考えることに非常に苦労したが，実際に発表練習を通して，流れを確認することで，

発表練習を行いつつ発表の流れを徐々に改良することができ，非常に効率の良い作業を行う

ことができた．何度も出来上がったスライドを担当教員，TAの方々にレビューして頂くこ

とでスライドの完成度を高めることができ，また，発表担当者の発表の練度を高めることが

できた．

　最終成果発表会の本番では，スライドの発表，ポスターセッションを行った．多くの練習

やアカデミックリンクでの経験も有り，今までで一番良い発表を行うことができた．さら

に，中間発表会ではプロジェクターが破損するという予期せぬ自体が起こってしまったが，

最終発表ではそれらのリスク対策も行うことができた．

• 個人の学び　このプロジェクトを通して私は，積極性，協調性，発表技術の 3 つを身につけることが

出来たと自負している．　私は，以前から主体性を発揮することがあまりなく，会議等の場

においても，他人の意見に流されることがとても多かった．しかし，プロジェクトメンバー

の一員としての責任を課せられる，またメンバーの皆が私をプロジェクトの一員として認識

してくれ，１人１人の意見を尊重してくれたおかげで自身の考えをハッキリ持つことができ

るようになり，会議の場でも日に連れて発言することが多くなっていった．このことによっ

て，積極性も大きく身につけることが出来た．さらに，話を聞いてくれるメンバーのために

役立ちたいと考えるようになり，協調性の重要性を知るとともに身につけることが出来た．

他にも，発表技術を大きく習得することが出来た．これが私の中で最も大きな成長である．

中間成果報告会の発表練習までは，人前に立つだけでも緊張して，発表がうまくいかず，目

線の配り方，話し方等，全く発表技術を身につけていることはなかった．しかし，プロジェ

クトメンバーと多くの練習をこなすことによって，人前にたつことに慣れ，様々な発表技術

を習得する余裕が生まれることになった．余談であるが，夏休みのインターンシップにおけ

るプレゼンテーションでは，社会人の方々に褒められるほどに成長することができた．この

ように，プロジェクトを通して多くのことを学ぶことができた．


5.6 坂部翔一

• 前期キックオフ　プロジェクト開始にあたり模擬開発演習におけるチームメンバを決定した．私はグループ

Cで活動を行うこととなった．次に，高森満様，木下実様といった企業講師と担当教員も含

めキックオフ会を行った．そこで本プロジェクトの全体像や大まかな活動内容を知ることが

できた．さらにペーパータワー作成を通してチームメンバとの交流を深めた．私は，ペー



パータワー作成中には意識していなかったが，本来こういったアイスブレイクを通してチー

ムメンバの特色を知ることができるということを企業講師の方々から学ぶことができた．

• 勉強会　今回のプロジェクトで開発に用いる CakePHPの勉強会を行った．TAの方に CakePHP

の基本的概念である Controller，Model，Viewについて学び，さらに演習を通してフォー

ムの使い方や，MySQLの使い方も学習をした．PHPを知らなかった私としては新たなプ

ログラミング言語に触れることができ，いままで学習してきたプログラミング言語との違い

や，プログラミング言語ごとの長所，短所といったことを実感することができた．加えて，

スケジュールを管理するためのツールである Redmineの使い方についても学んだ．これを

用いることで個々人のタスクが目で見て分かるようになり，作業を行う上で重要になってく

ると考えた．

• 模擬開発演習　模擬開発演習では，まず，担当教員である伊藤恵准教授の要求を引き出し，要件定義を

行った．それをもとに要件定義書，ユースケース図，業務フロー図などの UML図を作成し

た．ここで，UML図作成にあたって，各個人にタスクを振って UML図を作成したのだが，

用語の使い方，文言が統一されておらず，修正を行った．この問題は用語集を作成すること

で解決することができたのだが，多くの時間がかかってしまった．この経験から用語集の重

要性を実感することができた．さらに，1回目の伊藤恵准教授との話し合いの際，聞きたい

ことが曖昧でうまく話を進めることができなかったことを活かして，2回目の際には，話し

合いをスムーズに進めるための準備をしっかり行った．具体的には，前もってドキュメント

を相手に渡しておき，それをもとに話し合いを行ったり，質問事項をあらかじめ決めておく

などの準備を行った．こういった準備をしっかり行うことで，スムーズに話し合いを行うこ

とができ，要件定義のコツをつかむことができた．

　 6月には，企業講師とのテレビ会議も行った．ここでは，模擬開発演習や本開発の活動の

報告を行い，それに対するレビューを頂いた．個人的には前もった準備が十分ではなかった

せいか，このテレビ会議をうまく活かせなかったように思う．遠隔レビューの難しさを学ん

だことに加えて，今後こういった機会があるときには，この経験を活かして，前もって準備

をしっかり行おうと思った．

　 7月の模擬開発演習の実装では，開発ツールの eclipseが壊れてしまい，ほとんどグルー

プに貢献することができなかった．あらかじめバックアップをとっておくなど，対策はいく

らでもあったが，迅速に行動することができず，非常に悔しい経験をした．実装を終了し，

次にテストを行った．テストは Seleniumを用いて行い，さまざまな入力項目を考慮したテ

ストを行った．Seleniumをうまく使いこなせなかったせいで，自動でのテストはすべてを

網羅することができなかったが，実装の際に，バリデーションをしっかり行えていたことも

あり，おおむね予想どうりの挙動となった．模擬開発演習で構築したシステムは規模が小さ

く，Seleniumを用いなくても手動でテストを行うことができた．しかし，実際社会にでて

構築するシステムは非常に規模が大きく，テストの自動化が重要になると思うので，こう

いった経験は非常に貴重なものだったと思う．

　 8月には，模擬開発演習で構築したシステムの納品を行った．納品会では，依頼者に対し

て一部の機能の説明を行った．システム自体は自分の思ったような挙動だったのだが，その

挙動を明確に依頼者に伝えることが難しく，自分で思っていることを正確に相手に伝えるこ

との難しさを知った．この機能の説明は，要件定義との違いがないかといった確認の意味も



含まれていたので，事前に要件定義書をしっかり確認しておくといった対策が可能だったと

思う．

• 中間発表会　中間発表会の準備段階では，ポスター担当となり，3人で中間発表用ポスターを作成し，

1人がポスターの構成，イラストなどを担当し，残りのメンバーで文章を考えた．私は，文

章を 2 人で考えたのだが，文章の構成，使用する用語を統一しなければならず，互いに情

報共有をしあって作業を進めた．中間発表会では，ポスターセッションを担当した．私がポ

スターセッションを行うのは，中間発表会がはじめてであったので，チームメンバーをお客

様に見立てて練習を行った．しかし，中間発表会当日にポスターセッションをしてみて，お

客様とのコミュニケーションが最も重要であると感じた．あらかじめ用意しておいたセリフ

を言っても，分かってくれる人とよく分かっていないような表情をする人がいた．そういっ

た時は，柔軟に対応し，分かりやすい言葉に言い換えるなどした．こういった自分達のプロ

ジェクトの活動の報告だけでなく，中間発表会では他のプロジェクトを見て回る機会があ

り，自分達とまったく違ったプロジェクトに触れることができた．1年生の時にもプロジェ

クトの中間発表会に参加したのだが，その時とはまた違う目線で話を聞くことができた．

• 中間報告書　中間報告書の作成においては主に成果と学びの部分を担当した．約 4ヶ月の間に行ってき

たことを振り返り，そこから何を得たのかということを改めて考えることで，得たものの重

要さ，こうしておけばよかったといった反省点に気づくことができた．

• オープンキャンパス　夏休み中に札幌のオープンキャンパスに参加した．このイベントは任意参加のものだった

のだが，私は経験を積むためにも参加することにした．出張オープンキャンパスのイベント

を通して，本番に行ったポスターセッションだけでなく，イベントに向けての打ち合わせや，

当日の設営，撤収といったすべての作業に参加することができた．プロジェクトでは，リー

ダーの指示に従って行動することが主だったのだが，この出張オープンキャンパスのイベン

トに参加する人数はプロジェクト毎に 2人だったので，本来の 10人体制のプロジェクトよ

りも主体的に行動することができた．例えばポスターの印刷など他のメンバーに頼ってしま

いがちな仕事を自ら進んで行うことができた．加えて本番のポスターセッションからも多く

のことを学ぶことができた．2回目のポスターセッションだったので，自分なりに 1回目と

は違った工夫をした．例えばあまり説明口調にならず，自然な対話を意識することで相手に

とって聞きやすく，分からないことがあった時に気軽に質問できるような発表を心がけた．

他に，自分の影がポスターにかかって見えづらくなっていないか，とにかく相手の目をみて

話すことなどに注意を払った．結果，1回目よりも相手が頻繁に頷いてくれていてしっかり

伝わっていることが見て取れた．さらに，質問も多く頂いて，その質問に返答しているうち

にさらに話題が広がりよりよいアドバイスを頂くことができた．一般企業の方々との会話の

中で，システムに関する詳しい話もすることができ，良い経験になった．反省としては，一

般企業の方々とは多く交流できたのだが，高校生とあまり交流することができなかった．一

般企業の方々には理解してもらえても高校生にはうまく伝わらないことがあると思うので，

そういったときの対応を経験するためにももっと多く高校生と交流すべきだったと思う．

• 本開発

現状調査函館市近郊のイベント情報の現状を知るために，多くのイベント情報サイトを実

際に閲覧し，そのなかでも多くのイベント情報を取り扱っていた函館市地域交流まちづくり



センター様，函館市青年センター様，函館市文化・スポーツ振興財団様へヒアリングを行っ

た．その結果，函館市近郊のイベント情報の集約，発信は紙媒体が主であることが分かり，

本開発の活動方針を決定する要因となった．

サービスの考案サービスの方針を決定する会議は，8 月の夏休み中に数回行われ，私は，

ペルソナを使った具体的なシナリオ作成などに積極的に参加した．しかし，方針の決定には

いたらなかった．私は，この原因はグループメンバー全体のモチベーションにあるのではな

いかと考える．中間発表会，中間報告書の作成，模擬開発演習の実装，納品といったことが

立て続き，時間外活動が多くなっていて，グループメンバーは身体的にも精神的にも疲れて

いたように思う．そんな中，夏休みに入ってもなお，活動を続けてしまい，モチベーション

の低い中会議を進めていたので，非常に効率が悪い印象を受けた．この経験から，モチベー

ションの重要性と，限られた時間の中でよりよい成果を生み出すことの重要性を学ぶことが

できた．時間を決めて活動を行い，時間内に bestな成果が出なかった場合は，betterな成

果で勝負することも大切だと思った．

9月にも，継続してシステムの方針を検討した．その際に，ほとんどのグループメンバーが

帰省しており，Skypeでの会議を行った．私もこの会議にイヤホンとマイクを用いて参加し

たのだが，相手の表情が見えなかったり，チャットでの参加メンバーも多くいて話し合いが

まとまらまかった．ここで企業講師とのテレビ会議の件も含めて改めて遠隔会議の難しさを

知った．スケジュールがどんなに厳しい状況でも，遠隔会議をできるだけ避けて，メンバー

全員がそろって会議を行うことが重要だと思った．

提案 10月には，システムの方針が決定し，まちセンへサービス (HakoEve)の提案を行っ

た．その結果，現状の市民活動情報というイベント情報発信ページと HakoEveとの差し替

えを検討して頂くことができた．

設計提案の結果をを受けて，システム設計の段階に入っていった．設計は，サービスの機

能に関するドキュメントを作成する機能班と，サービスのデータ構造を定義するデータ班に

分かれて行った．私は，機能班に所属し，ユースケース図と，業務フロー図を作成した．

実装サービスの実装は設計時の情報を共有しやすいよう，設計段階で分かれていた機能班

とサーバ班のメンバーを混ぜて新たにサービスの UIを実装するクライアント班と，サービ

スの内部機能を実装するサーバ班を編成して行った．私は，サーバ班に所属し，主にキー

ワード検索機能を実装した．この機能は 11月に行われるアカデミックリンクまでに絶対に

実装しなければいけない重要な機能だったので，責任のある仕事だった．しかし，期日まで

にしっかりと実装を完了することができた．実装したキーワード検索は，ひらがな，カタカ

ナ両方に対応しており，イベント名だけでなく，イベントの詳細からも検索することができ

るといったものだった．さらにイベント名をしっかり覚えていなくても，曖昧な検索でも

しっかりヒットするような検索機能を実装することができた．

• アカデミックリンク　アカデミックリンクの準備では，ポスター作成を担当した．中間発表のときとは違いプ

ロジェクトの活動すべてを説明する必要はなく，主に HakoEveについての説明を行うため

のポスターを作成した．HakoEveの概要をイラストを用いて説明するだけでかなり多くの

スペースをとってしまうせいで，他のメリットや提案に関する文章をできるだけ少なくし，

しっかりと内容が伝わるような文章を考えた．アカデミックリンクに向けた練習では，企業



講師の高森満様に指導を頂いた，発表時間 2～3分を目安にして，要点だけを絞った発表の

練習を行った．まずはじめに，自分達が一番言いたいことを決め，それを伝えるために必要

不可欠な情報を抜粋することで要点を抑えた発表ができることを学んだ．

　アカデミックリンク本番では，ポスターセッションを行った．このアカデミックリンク

は他の大学と合同で行われた．そのため，それまでは ITに関わりのある人ばかりを相手に

ポスターセッションを行っていたが，アカデミックリンクでは ITの知識が全くない人が聴

衆者になった．それを受け，未来大学内ではあたりまえのように使っている用語も別の言

い方ができるようにして本番に臨んだ．本番では，2～3分よりも多く時間を使ってしまっ

たが，聞いている人の表情から HakoEve について理解していることが見て取れた．さら

に，Facebookの宣伝も忘れずに行った．そのせいか，わずかながらつながりが増えた．ポ

スターセッション以外にも，他の大学の活動を知ることで全く新しい学びを得ることができ

た．例えば，蟻のコミュニケーションに関する研究や，アオコに関する研究，食品の品質管

理に関する研究など，ＩＴを専攻している本大学では，関わりあえないような分野の話を聞

くことができた．

　アカデミックリンクまでに HakoEveで特に見てもらいたい機能を実装し，それ以外の機

能は，アカデミックリンク後に実装した．私はイベントの日付の表示に関する実装を行った．

• 最終成果発表会　最終成果発表会の準備において，私はスライドの作成を担当した．プロジェクト活動を通

して，スライドを作成するのはこのときが初めてだったのだが，特に発表の流れを意識した

スライド作成を心がけた．作成している最中には，常に頭の中で発表のイメージをし，スラ

イドのつながりが悪く発表のイメージがしにくい場合は積極的に指摘を行った．本来，最終

成果発表会の１週間以上前にスライドを完成させて，練習に取り掛かる予定だったのだが，

TAや担当教員からのレビューを受けて修正を加えなければならず，修正と練習を平行して

行っていった．レビューを受けて修正した結果，どうしてもスライドのつながりが悪くなっ

てしまい，発表しづらくなってしまうケースがあった．そういったときは，スライド作成班

全員で，うまくつながるような文言を考えたり，ある程度の情報をスライドに付加して発表

しやすくしたりといった対策を講じつつスライドを作成していった．このように常に発表の

流れを意識してスライドを作成したせいか，発表練習ではあまり詰まらず，伝えたいことを

しっかり伝えることができた．

　最終成果発表会本番では，スライドの発表とポスターセッションを担当した．特に私が担

当したスライドのイベント班の活動の説明は長く，伝えたいことを絞ってしっかり伝えない

と情報量が多く拡散してしまうので注意が必要だった．本番では，練習どおり，HakoEve

の中でも特に知ってほしい推薦機能についてと，開発体制の工夫点についてを，重点的に説

明することができた．さらに，お客様の目を見て話すことをしっかり意識することができ

た．しかし，緊張のせいか，多少早口になってしまった．プレゼンのスキル向上は経験を積

むことが非常に重要だと思うので，今後プレゼンする際は，同じ失敗を繰り返さずに，１回

の経験でできるだけ多くのことを学んで，スキルを向上させていきたいと考えた．

• 個人の学び　私は，このプロジェクトを通して大きく 3つのことを学ぶことができたと考える．

　 1つ目に，要件定義，設計，実装，テスト，運用といった開発の流れを経験できたことに

ついてである．私は，本大学で座学で学んできたことが実際のプロジェクトにおいてどのよ

うに役立つのかを実感することができた．ユースケース図，業務フロー図といった UML図



を大学の講義の演習で作成したのだが，作成して終わってしまっていた．しかし，このプロ

ジェクトでは，その UML図を用いてヒアリングを行ったり，メンバー全員の意志共有のた

めにそれらを用いたりなど，プロジェクトにおける UML図の役割を学ぶことができた．

　 2 つ目は，情報共有の難しさについてである．今回，本開発を 10 人のメンバーで行い，

情報共有の難しさを実感した．まず，各自で文章を考えてきてそれらをマージしようとして

も用語がバラバラで修正に多くの時間をとってしまった．さらに，日本語の文言もバラバラ

だった．例えば，「クリックする」と「ボタンを押す」という表現が混在してしまっており，

修正に時間がかかったりした．さらに，業務フロー図作成の際に，自分の考えていたフロー

と全く違うということが多々あり，その度に全体で確認を取りながら作業を行っていったの

で，多くの時間がかかってしまった．こういった経験から情報共有の難しさを学ぶことがで

きた．

　 3つ目は個人の責任についてである．今回のプロジェクトは，主にまちセンの協力で活動

を行った．そのなかで，12月上旬までに HakoEveの実装を完了することを約束したため，

それまでの活動よりもいっそう責任のある活動が求められた．そんな中，コミットの際に

メッセージを忘れたり，プログラムにコメントを付け忘れてしまい何の意図で行ったものな

のかわからなくなってしまい，メンバーを混乱させてしまい責任を持った仕事をすることが

大切だと感じた．

　本プロジェクトを通して，これら以外にも非常に多くのことを経験し，学ぶことができ

た．私は将来，IT系の職に就こうと考えているので，これらの経験は非常にアドバンテー

ジになると考える．


5.7 柴田健介

• 前期キックオフ　プロジェクト学習初日では教員からのプロジェクト方針の説明や，自己紹介，このプロ

ジェクトを行う上でのリスク分析を行った．リスク分析を行う事で後々起こりうる様々な問

題に対応できる体制を整えられるはずだったが，まだシステム開発を行っていなかった段階

なので実際のイメージがわかず，どのようなリスクがあるか分からなかった．

• 勉強会　主にこれから模擬開発や本開発を行う上で最も基本となる部分を学んだ月であり，タス

ク管理をする為の Redmine，バージョン管理のための Subversion，他にも phpMyAdmin，

CakePHP，MCV モデルについて学んだ．どれも今まで扱った事がないものだったので，

慣れるまでには苦労した．phpMyAdminを実際に使うことで，今まで知らなかったデータ

ベースの実際の使い方を知ることができた．Subversionと CakePHPに関してはもっと学

習しておけば，後々困ることが少なく済んだのではないかという反省点がある．

• 模擬開発演習　自分はグループ Bに所属していたので，大場みち子教授をお客様として，面談予約管理シ

ステムを 5人で開発した．要件定義の際，ヒアリングを二回行った．一回目のヒアリングで

は，お客様と要件の確認を行った．ヒアリングの中で自分は内容のメモをとりドキュメント

にまとめた．事前に用意した質問事項をお客様に確認しながらお客様の要望を聞きだしてま



とめる進行役のメンバーのレベルの高さに驚愕した．次のヒアリングでは実際に進行役を担

当し，事前に用意したドキュメントの項目を確認しながら話を進めた．しかし経験不足だっ

た為，会話の中でシステムのイメージがわかず他のメンバーに助けられる事が多かった．お

客様とのヒアリングの際は紙にシステムの機能をイメージとして記しながら話を進めれば，

一つ一つの機能を詰めていくことができ，要求定義書の作成をよりスムーズに進めることが

できたのではないかと後で反省した．ヒアリングの際はお客様と共有しながら話を進めるた

めのドキュメントがあり，それを有効に活用する事が大切だと感じた．ヒアリング後は要件

定義書を作成した．納期までに全ての機能を実装出来る確信が無いため，機能毎に実装する

優先順位をつけた．設計時はユースケース図，ER 図を astah* professional を用いて京谷

と共同で作成した．ユースケース図はあらかじめ自分が作成したので，Skype のチャット

で改善点を挙げ，5個から 10個程上がった段階でどちらかがマージする方針で作業を進め

た．マージの際は特にバージョンの管理に留意した．ER図に関しては知識が不十分であっ

た為，情報ライブラリの図書やWebページを参考に，学習しながら作成した．実装時は面

談のタイトルを追加，削除，一覧する機能を作成した．分からない点はリーダに教えてもら

う事が多かったが，出来るだけ自分で実装する努力をした．エラーなどの不具合の解決方法

を調べる為，Google検索した際に出てきたのは海外の解説サイトが殆どだった．解読する

のに時間がかかり，プログラミングを行う際は英語力も必要だという事を実感した．8月 6

日に作成した面談予約管理システムを納品した．納品会の流れを知らなかったため事前の準

備を全くしていなかったことで指摘を受けた．納品前にシステムの説明をするので，その為

の資料を作成したり，誰がどこを発表するかを決める等の準備が必要だった．

• 中間発表会　中間発表会の準備ではポスター作成のタスクを受け，自分は面談予約管理システムに関す

る説明，組織体制に関する説明を考えた．スライド発表練習ではプレゼンテーションの基本

をメンバーに叩き込まれ，慣れるまでは苦労した．「ご説明させていただきます」ではなく

「ご説明します」と言うべきという事や例を挙げる時は一つ挙げてから全体を説明すればよ

いという事など，気をつけなくてはならない点が多かったのでノートにメモしておいたが，

まとめ方が悪く全文を暗記しているようになってしまった．この方法だと臨機応変に対応出

来ず，万が一忘れてしまった時に対応できないと指摘されたので，出来るだけノートを見ず

注意事項に気をつけながらひたすら練習した．ここで得た教訓は，プレゼンテーションの練

習の際は気をつける事項は箇条書きでメモしておいて，発表練習の際に意識して何度も練習

するのが最も効率がよく確実だという事だ．

• 中間報告書　報告書はグループ Bの活動内容を書いた．後からの反省としてあらかじめポスターやス

ライド，中間報告書を書く前に背景や目的や過程を意識しながら活動を行い，その定義を議

事録に記録しておけば，もっとスムーズにこれらを作成できたのではないかと考えた．

• 本開発

サービスの考案イベント班の活動では，前期に行った函館市の現状調査から問題点を分析

し，どんなサービスを提供すればそれらを解決できるのかをミーティングで話し合った．話

し合いに参加する上で最も難しかった事は，自分が提案したい機能が実際に実現可能なもの

であるかどうかを考える事だった．実装経験が未熟だと現実的な意見を言うことが困難だ

と感じ，もっと身の回りのWebページを見てどのように動いているのかと興味を持つ必要

があると思った．8 月後半は殆どのメンバーが函館を離れていたので Skype を用いてミー



ティングを行った．Skype上のミーティングは会話の記録が残っていてミーティングの流れ

を追ったり話の内容を再確認できるという点は良かったが，相手の表情が見えないという事

や，通信が途切れてしまうという事などの欠点があった．また後期の活動の始め，ミーティ

ングで 2 回程議長を務め，ミーティングの進行に挑戦した．チーム内でサービスのイメー

ジが漠然としている段階だったので前のミーティングからメンバー全員が共通の認識を持っ

ているのかどうかが問題であった．それを確認する為それぞれの認識を紙に書いてもらい，

前のミーティングのおさらいのような時間をとった．またミーティング中に話が脱線してい

かないようにあらかじめ議題を決めたり，ミーティングのスケジュールを組むなどの工夫も

した．

提案 HakoEve の提案の際はまちセンに訪問し，録音許可を得て会話の内容を記録した．

帰宅後に他のメンバーが，録音した音声を全て聞かなくても内容が理解できるということを

意識しながら，今回の訪問をダイジェストにまとめたドキュメンを作成し，このファイルと

録音したデータをリポジトリにコミットして共有した．

設計設計時は機能班に所属した．まちセンに提案するシステムに必要と思われる機能を

洗い出し，astah* communityを用いてユースケース図と業務フロー図を作成した．ユース

ケース図作成は機能の洗い出しに力を注ぎ，業務フロー図は初めて作ったので，他のメン

バーが作成したものを参考に作成した．

実装主にプロジェクトの活動に入ったのは後期が始まってからだったので活動に入る前

に，本開発に備え，模擬開発で学んだ CakePHP の使い方を復習した．実装時はクライア

ント班に所属し，最初に画面イメージ図を作成した．自分はイベント詳細画面のイメージ

を担当した．提案のスライドにあるイメージと同じ画面でなければ，システム利用するま

ちセンが困惑してしまうので細かい部分まで正確に作るよう努めた．11月 1日から実際に

コーディングが始まった．コーディングは工藤と共同で作業していたので，進捗報告は頻繁

に行っていた．最初はヘッダー，フッダー，詳細画面を実装した．初めて CSSのコードを

扱ったので，分からない部分はその都度調べながらコーディングした．次にイベント開始日

時フォームを増やす為のボタンの実装を試みた．HTMLで扱っている変数を PHP側のプ

ログラムに渡さなくてはならないので Ajax通信について学習した．しかし，かなりの時間

がかかると判断したため，その他の優先度が高いタスクに手を回すことにした．このタスク

は現在も完了していない為，今後の課題である．その後ブラウザ対策のタスクを担当した．

Internet Explorerでの HakoEveの表示のされ方が他のブラウザと異なり，白文字で表示さ

れるはずが黒文字で表示される，テーブルが表示されない，という問題があった．前者の問

題は Internet Explorerでは色を指定しないとデフォルトで黒文字で表示されるため，白文

字で指定する事で解決に至った．後者の問題はコメントアウト部分を消すと直ったのだが，

その部分はテーブル表示部分のソースコードにかかっていないはずのコメントアウトだった

事に加え，他のブラウザでは正常にテーブルが表示されていたので，原因は不明のままで

ある

ロゴの作成アカデミックリンク後，実装を中断し HakoEveのロゴ作成のタスクを担当し

た．最も大変だった事は Illustrater の知識不足のせいで思ったようなデザインを再現する

事が出来なかったことである．その穴埋めはアイディアで補い，ロゴの案を 10個程挙げた．

他のメンバーからのアドバイスから，アイディアを挙げるときは実際に紙に何かを書いてみ



た結果，思わぬアイディアが浮かぶ事もあった．ロゴのデザインを考える時だけでなく，ア

イディアを考えるときにこのようなプロセスは重要だと思った．

• アカデミックリンク　 11月 9日にはアカデミックリンクがあり，HakoEveを売り込むような気持ちでポスター

を発表した．発表の後で，お客様から「検索機能は今までにもあったものが多いけど，推薦

機能は斬新だ．これを強調して発表するといい」というアドバイスや「HakoEve運用後に，

運用前と比べてどのくらいイベントを探すのが早くなったというデータを取ると，研究とし

ておもしろいものになる」というアドバイスを頂いたので今後の活動の参考にしていくつも

りだ．

• 最終成果発表会　最終発表はスライド発表一筋で力を入れた．最初の発表練習は初見のスライドだった為，

殆ど練習にならなかった．その悔しさをバネに反省して発表のスタイルを自分で考え，何度

も練習した．最終発表当日はかなり緊張したが自身の発表をやり遂げることができた．

• 個人の学び　プロジェク学習が始まる前の目標はプログラミングのスキルを付ける事であったが，実際

に活動を行っていくうちに，その目標以上のものを得られたと私は考える．プログラミング

を行う工程は実装工程であったが，その前には要件定義，設計の工程があった．要件定義で

はヒアリングを行いお客様の要望を聞き出し，それを満たす為にシステムはどのような機能

を提供すればよいかを考えた．お客様の要望を叶えるシステムを作るには，この要件定義が

システム開発において最も重要な工程だと感じた．お客様の要望を正確に聞きだす為には，

お客様のイメージを紙やドキュメントにまとめ，お客様と開発者側で共有する事が重要だと

いう事を学んだ．またお客様自身が想定していなかった問題を解決出来る機能を実現できる

可能性があるため，事前に「このような機能があったらどうだろう」という提案をヒアリン

グ前に用意しておくとよい．

　設計では，要件定義で確定した機能をどのような形でシステムが提供するのかを明確化

し，図化したものをドキュメントにまとめた．この工程では，開発者側が，システムが提供

する機能の詳細を忘れてしまっても，見ただけで思い出せるようなドキュメントを作る事が

重要だという事を，ドキュメントのレビューの際に学んだ．またそのドキュメントをお客様

側が見ても理解して納得できる事が重要だという事もレビューの際に学んだ．

　実際にプログラミングを行った実装工程は，チーム開発だったのでバージョン管理が最も

重要であると感じた．バージョン管理では，コミットをする際メッセージを残さず他のメン

バーに迷惑をかけてしまう，作業ファイルのコピーファイルで作業して混乱する等の失敗を

してしまい，他のメンバーからチーム開発をするという事は責任を伴う事だと強く教えられ

た．今後システム開発を行う事があれば，どの点を変更，実装したのかがわかるようにコ

ミットメッセージを残すことに留意し，1つの作業ファイルでコーディングを行うよう心が

けたい．一方進捗報告を頻繁に行った事と不明な点をそのままにせず相談した事が実装をス

ムーズに進めることができたと考え，これらの点は引き続き維持して行うようにしていきた

い．

　また，それまで議事録を書く技術が未熟だったが，TAから議事録を書く際のアドバイス

をいただき，アドバイスを基に議事録を書く際のテンプレートを確定した．議事録は活動内

容，決定事項，教員からのアドバイス，今後の予定を分けて書くようにして，いつまでに，

誰が，何を，どのように行うのかが分かるようにタスクの内容を書くという方針に定めた．




5.8 京谷和明

• 前期キックオフ　 5月にグループ分けを行い，本グループの B班として活動を行っていくことになった．

　まず最初に先生や TA，企業講師の方から Subversionについてや Redmine，PBLについ

ての説明を受けて，キックオフを行った．キックオフではアイスブレイクやグループディス

カッションを行った．このキックオフを経て，プロジェクトメンバーとの親睦を深めること

ができたと思う．

• 勉強会　 5 月の中旬には CakePHP 勉強会を行い，MVC アーキテクチャの基礎的な内容を学ん

でいった．この CakePHP勉強会で XAMPPや phpMyAdmin，eclipseなどの環境を構築

し，実際にローカル上で動くシステムの構築を学んでいった．Webアプリケーションは今

まで触れたことがなかったので，今後の開発に活かせる貴重な勉強会であったと思う．

　 5 月の下旬には，模擬開発演習についての説明を受けて，astah* professional の導入を

行った．またサーバ構築の説明を受けて，実際にサーバの設定も行った．

• 模擬開発演習　 6月に入ると模擬開発演習が始まった．この模擬開発演習では教員をお客様と見立てて行

うものなので，まず B班のお客様である大場みち子教授のもとへヒアリングに行った．この

ヒアリングでは既存の面談管理システムをどのように変更をして欲しいのかといった要求を

聞き，それを基に要求定義書の作成を行った．自身のタスクとしては，ユースケース記述の

一部の作成を行い，要求定義書全体の清書を行った．その要求定義書を基に，続いては設計

を行っていった．私自身はユースケース図や ER図の作成を行い，教員や TAの方々からの

レビューを頂きながら作成していった．また，他のメンバーが作成した UML図のレビュー

も行った．

　この設計の段階において，6月の中旬に企業講師の方とのテレビ会議を行った．そのテレ

ビ会議では要求定義書や UML図などのレビューをして頂き，またプロジェクトの進行方法

についての改善点も多く頂いたので，今後の活動に活かせる多くのことを学ぶことができ

た．

　　そして設計が終わり次第，実装に移っていった．実装においては，CakePHP を用い

て主に教員用のシステム全般の機能の作成を行った，私自身は面談情報の登録システムや，

データの削除，一覧の表示方法などの実装を行ってきた．

　 7 月に入ると，模擬開発先週は上旬は中間発表会に向けて実装はあまり手をつけていな

かった．中間発表会が終わり次第，中間報告書の作成に移っていったため，実装はあまり進

まず優先度の高いものだけを行った．下旬に入ると中間報告書の作成が終わったので，残っ

たタスクを消化していった．

　 8 月に模擬開発演習では納品会を行った．納品会に向けて残ったタスクを深夜遅くまで

消化していったが，結局全てのタスクが終了しなかった．納品会では実際にどの程度タスク

が終わったのかを発表し，発表形式についてやどういった具合で実装を進めればよかったの

か，お客様との連携をもっとしっかりと取るべきだったなどの多くの反省点を出すことがで

きた．模擬開発を行ったことにより，プロジェクトの進行に関する多くの知識を得ることが



でき，これらを本開発のほうで活かしていきたいと決意した．

• 中間発表会　 6月の後半には，中間発表会に向けての資料作りが始まった．本グループをスライド班，

ポスター班の 2 つに分け，私はスライド班として割り当てられた．そのスライド班として

は，模擬開発についてと本グループについてのスライドの作成を行った．スライドは主に土

日に集まって作成し，そのスライドは TAや教員の方々からのレビューを頂きながら修正し

ていった．

　 7 月のスライド班の活動としては，中間発表会があったので，スライドの作成を終わら

せ，そのレビューを TAや先生方から何度も受けて，その都度修正を行っていった．またこ

のときスライドの作成は Googleドキュメントで行っており，それではレイアウトが崩れて

しまうため，それの修正に手間取ってしまった．このことから，最初から PowerPointで作

成すべきだったということを学んだ．スライドの作成は深夜までかかったこともあったが，

チームのメンバーと一緒に作成を行ったので，より団結力を高めることができたと思う．

　実際の中間発表会では私はスライドの発表を担当し，何度も発表練習を行った．またチー

ムメンバーの前や TAや先生方の前でも発表練習を行い，レビューを多く頂いた．スライド

も複数回変更されていったので，その都度発表練習も行った．実際の中間発表会ではスライ

ドの説明では，そこそこうまく発表することができたが，質疑応答のときに少し戸惑ってし

まったなどの反省点も多く見受けれ，最終成果発表会ではこれらを改善しようと決意を新た

にした．

• 中間報告書　中間発表会が終わった後に，中間報告書の作成を行った．最初に Texの環境を構築し，そ

の後に実際に文書の作成を行い，私は本開発の部分を担当した．中間報告書においてもまず

メンバー間でレビューを行い，TAや教員方からレビューを頂き，修正をしていった．

• 後期キックオフ　 9月の終わり頃に企業講師の方を招いて，進捗報告を行った．その報告会では現在どの程

度本開発が進んでいるのかを説明し，後期の活動に向けての様々なアドバイスを頂くことが

できた．

• 本開発

現状調査 6月から模擬開発演習とスライドの作成と並行して，本グループの本開発の活動

がスタートした．まず最初にイベント情報についての現状の問題点を考えるために，イン

ターネット上の様々なイベント情報発信サイトについて調べて，イベント情報を多く発信し

ている 3つの施設に今のイベント情報の現状についてのヒアリングを行った．私自身はヒア

リングには出向いていないが，メンバーがヒアリングで聞いたことのまとめを行い，今後本

グループはどういった方針で活動していくかを話し合った．

サービスの考案 7 月に入ると，6 月のヒアリングで聞いたことを基に，現状のインター

ネットでのイベント情報の発信には複数の問題点があると考え，後期にこれらの問題点を解

決できるサービスを開発していこうとなった．具体的には 3つの施設はインターネットでの

イベント情報の発信にあまり力を入れておらず，またイベントを開催したらそれがやりっぱ

なしで事後レポートが存在しないので，これらの問題点を解決できるサービスの開発を進め

ていくことが決定した．

　 8月に入ると，どういった形で何を後期に開発するのかを話し合った．ヒアリングに伺っ



た 3つの施設は複数の問題点が存在しているが，現状で満足しているため，このグループで

現状の函館市近郊のイベント情報の問題点を解決できる新しいサービスを作りあげることに

した．そのサービスはインターネット上にあるイベント情報をスクレイピングで取得してき

て，それを掲載するサイトであり，また事後レポートも掲載できるものである．夏休み中に

はこれらのサービスを構築するために，スクレイピングや CSS，JavaScriptについて勉強

することに決定した．しかし，教員の方からレビューを頂いた結果，コンセプトがはっきり

していないという指摘を受けたので，まずはコンセプトをはっきりさせることにした．しか

し，その後も何度も会議を行ったが，あまりはっきりと決めることができず，夏休みに方針

を決定することになった．

　夏休み中は皆インターンシップ等で忙しく，全員で集まれる日がないので Skypeで会議

を行うことになった．しかし Skypeでの会議は意識の共有が難しく，自分が何を伝えたい

のかをはっきりさせることができなかったため，会議は難航した．そのため，しっかりと

意識を共有するために，9月に全員集まれる日に会議を行うことになった．このことから，

Skype等を用いての複数人での会議は意識を伝えることが難しく，簡易的なものしか会議で

きないということ，会議を行う前に今日決める内容を予め決めておくことなどを学ぶことが

できた．

　 9月に夏休みが終わる直前に，本グループ全員が集まり視点を変えて，自分の作りたいも

の，あったらいいなと思う機能を挙げていく会議を行った．そこではブレインストーミング

を行い，そこで複数の機能を挙げて，この機能なら現状の問題点のどれを解決できるかで話

合いを行った．この会議によりキーワード検索，タグ検索，日付検索，地図・場所検索，リ

コメンド機能を搭載したサービスを構築するという方針がある程度定まった．その後に教員

の方からレビューを頂き，運用者やユーザは誰なのかを明確にするためにまちセンが提供し

ている既存のイベント情報発信サイトを改良しようということが決定した．

　 10月にはまず構築するサービスをどういった具合で進めていくのかのスケジュールを決

め，各検索機能のイメージ共有を行った．その後にプロジェクト憲章の作成を行い，教員の

方や企業講師の方からのレビューを頂き，まちセンへ構築したサービスを運営してもらおう

という方針が決まった．

提案 10月の下旬に実際にまちセンのところへサービスの提案にいったところ，快く承諾

していただくことができ，サービスの構築を行っていくことが決定した．私たちが提案した

サービスは，まちセンの職員の方々にかなり好評で，今すぐにでも取り掛かってほしいとの

ことだった．

設計 10月の上旬の頃にはイベント班を内部設計班と外部設計班のさらに 2つに分かれて

設計を行った．私は外部設計班として活動を行い，機能定義書のたたき台を作成し，メン

バーからレビューを受けた．それが完成した後に，UML設計に入り外部設計班のメンバー

で話合いを行いながら，ユースケース図，業務フロー図，画面遷移図の作成を行った．機能

に関することは，内部設計班の設計するところに影響する部分も多く存在したため，定期的

に内部設計班と会議を行いながら進めていった．作成したものに関しては TAや教員の方々

からレビューを頂き，複数回に渡って修正を行った．

実装 10 月の下旬に入ると，今度は実装に移っていった．実装ではイベント班をサーバ班

とクライアント班の 2つに分け，私はサーバ班として実装を行った．まず最初にサーバ班と

してのスケジュールを確認し，タスクの割り方を話し合った．その後に実装に入り，私はタ



グ登録やキーワード検索などの内部処理的な内容を構築していった．

　 11月も，引き続き実装を行っていった，プロジェクトの時間のときは各々が作成してき

たコードのレビューを行い，その後に実装を行った．この実装では私は各種削除機能の修正

などを行った．中旬にはアカデミックリンクがあり，私は参加できなかったがそれに向けて

クライアント班との整合性を取り，エラーチェックを行った．また，アカデミックリンクに

参加する人たちと一緒に夜遅くまで残り，発表練習のレビューを行った．そのアカデミック

リンクが終わった後にまた実装を行い，タグ検索や各種バリデーションの設定などを行っ

た．11月の下旬にはほぼ全ての実装が終わり，残ったタスクは何か，今後はどうするかなど

の話し合いを行った．

　 12月に入ると，上旬においてはまちセンにヒアリングに伺った際に出てきた仕様変更は

行わず，最終成果発表会に向けての最終調整を行った．

　 12月の下旬には，ヒアリングに伺った際に出てきた仕様変更や新たな要求に対してのタ

スクの洗い出しを行った．そこから仕様変更定義書を作成し，メンバー間でレビューを行っ

た．今後はそのタスクを終わらせて，ユーザ検証を行っていく予定である．

評価 12月に入ると，最初にまちセンのところへヒアリングに伺った．そこでは構築した

サービスの説明をし，デモとして実際に使ってもらうことができた．まちセンの評価は概ね

好評であったが，ユーザ側の機能はどうするかなどは，実際にユーザに使ってみてもらわな

いとわからないということなので，公立はこだて未来大学とまちセンでユーザ検証を行おう

という計画立てた．このヒアリングでは新たな要求や仕様変更なども複数出てきた．

• 最終成果発表会　 11月の終わり頃に，最終成果発表会に向けてイベント班からポスター班とスライド班の

メンバーを抽出した．私はポスター班として活動を行うことになった．

　 12月に入ると，最終成果発表会に向けて，私はポスター班として文章を考えたり，英訳を

行ったりした．またポスター班で集まり，ポスター構成をどうするかや各自作ってきたもの

のレビューを行った．また野外劇班との整合性を取るために，野外劇班とも話し合いを行っ

た．このポスターは TAや教員の方々からレビューを頂き，その都度修正を加えていった．

　実際の最終成果発表会においては，私はデモとポスターとスライドの発表を担当した．そ

の発表に向けて何度も発表練習を行い，また他のメンバーの発表練習を聞いて互いに意見を

出し合うことができた．実際の発表会では，デモやポスターは人があまりこなかったので何

とも言えないが，スライドの発表は中間発表会の反省点を活かし，うまく行うことができた．

• 振り返り会　 12月の最後のプロジェクトの時間の活動では，企業講師の方を呼んでの振り返りを行っ

た．そこでは PBLに関しての復習や，この 1年間を通して学んだこと，反省点，今後の自

分の活動に活かせること，後輩たちに活かして欲しいことを多くあげることができた．

• 個人の学び　この 1年間を通して，まずプロジェクトの進行方法について学んだ．前期と後期に模擬開

発，本開発と 2回の演習を行うことができたので，課題発見からの要求定義，設計，実装，

テスト，納品の一連の流れを体験することができた．またプロジェクトの進行にあたっての

タスクの共有やコードの共有，進捗状況の共有などの様々なチームでの共有方法を学ぶこと

ができ，チームの特色を知ることで，うまくタスクの割り振りができることも学んだ．

　他にもチームでの会議の進め方についても学ぶことができた．ただ漠然と会議を始めるの

ではなく，予めその会議では何に焦点を絞って話すのかを決め，そこから脱線しないように



進めていくべきだということ，今回の会議ではここまで決定するということを決めておくべ

きだということなどを実際の会議を通して学ぶことが出来た．さらに会議の場においては，

議事録をしっかりと書くことでチームメンバで意識の共有を行うことができ，前回の会議の

振り返りもスムーズに行うことができるということを学んだ．

　構築するサービスに関しても利用者が求めるサービスが一体どういったものなのか，運用

者とユーザ側の視点から考えなければならないということを学んだ．

　設計や実装においても，勉強会や実際の開発を通して UML設計の手法や CakePHPに関

することなど多くの技術習得を行うことができた．


5.9 齋藤創

• 前期キックオフ　本プロジェクトの最初に私たちは企業講師の高森満様，木下実様を迎えプロジェクトの

キックオフを行った．キックオフではプロジェクトメンバーを 3 グループに分け，私はグ

ループ C のリーダーとしてメンバーと共にペーパータワーの作成を行った．ペーパータ

ワーの作成では，各人が意見やアイディアを出し合い，どのような方法で作るのが良いかを

話し合い，私はペーパータワーを立てる人と紙を準備する人などの役割決めをすることを進

言する等のファシリテーションを行った．このキックオフで私は，グループ Cのメンバー

との交流を深めることができた．

• 勉強会　本プロジェクトではバーション管理ツールとして，Subversion の学習を行った．以前，

私自身が Subversion を別の課外活動で使用したことがあったため，私は復習をしつつ

Subversion を初めて使う人のサポートを行った．本プロジェクトにおいて Subversion を

ファイルの共有や，サービスの開発およびドキュメントのバージョン管理するために用いた

ため，Subversionの学習は大いに役立てることができた．

　今回のプロジェクトにおいて，模擬開発演習やサービスの開発を行うため，PHP のフ

レームワークである CakePHP 勉強会を行った．教材は CakePHP2.1 による Web アプ

リケーション開発[1] を用いた．この CakePHP勉強会では CakePHPの基本的概念である

Controller，Model，Viewについて学び，フォームの使い方や，MySQLの使い方等も学習を

した．私は，以前 CakePHPに関して課外授業で学習をしたことがあったため，Subversion

の学習を行った時と同様に学習のサポートを行い，同時に CakePHPについての復習も行っ

た．この演習問題を行うことにより，模擬開発演習における面談予約管理システムの実装を

スムーズに行うことができた．

• 模擬開発演習　グループ Cでは本プロジェクトの担当教員である伊藤恵准教授を開発依頼者として，面

談予約管理システムの実装を行った．主に，伊藤恵准教授とのヒアリングのアポイントメン

トは私が取り，グループ Cのリーダーとしてメンバーにタスクの割り振りやスケジュール

の作成などを行った．模擬開発演習のヒアリングの際には，ヒアリングを円滑に進めるた

め，まず先に用語集や質問事項をあらかじめまとめておく等の工夫をした．

　 6月の上旬に，伊藤恵准教授へ模擬開発演習の際に実装する面談予約管理システムの要件



に関するヒアリングを行った．このヒアリングを元に，グループ Cではユースケース図や

業務フロー図，WBSなどのドキュメントを作成した．私は主に各ドキュメントの進捗管理

や業務フロー図等の作成を行った．

　テレビ会議にて，企業講師の方々より「各成果物の整合性が取れていない」という指摘を

頂き，ユースケース図，業務フロー図などの作成に関して手戻りが発生してしまった．そこ

で私たちのグループでは，3名がユースケース図，業務フロー図，要件定義書をそれぞれ同

時に作成し，残り 2名が確認作業を行うように作業を行った．その際私は，要件定義書を作

成しつつ同時進行で作成している成果物の整合性が取れているのかどうかの確認作業を行っ

た．その結果，各成果物の整合性を取りつつ，効率良く上流工程を進める事ができるように

なった．

　企業講師レビュー会では，上記の方法を企業講師の方々に説明し，評価を得ることができ，

私たち自身がこの手法が私たちのグループに合っていたという事を認識することができた．

　面談予約管理システムの実装において，私は全面談データの削除機能と，面談データのエ

クスポート機能の実装を行った．全面談データの削除機能の要件として，登録されているす

べての面談データを削除する機能と教員アカウント以外の全てのデータを削除する機能，教

員アカウントを含む全てのデータを削除する機能の 3 つの全面談データ削除機能の実装を

行った．また面談データの削除の際，教員であるかどうかの確認のため教員アカウントのパ

スワードを再入力するように実装を行った．面談データのエクスポート機能については，同

じグループの斉藤篤史とともに実装を行い，面談データを CSV形式で出力できるように実

装を行った．

　 7月には，システムのテスト方法や Seleniumの使い方などを学習し，納品に向けて面談

予約管理システムの実装，テストを行った．私は主に，実装した面談予約管理システムが作

成したドキュメント通りの応答をするように修正を行った．

• 中間発表会　 6 月の中旬頃，前期の活動を報告する中間発表会の準備を始めた．私は，中間発表会の

発表スライおよびポスターの作成を担当した．スライド作りに関して，私たちのプロジェク

トでは ICTで地域をデザインするという目的を果たすための本開発と，本開発を円滑に進

めるために行った模擬開発演習の説明のため，限られた時間内に内容を説明できる資料を作

ることが難しかった．ポスター作りに関しては，同プロジェクト野外劇班所属の Kim Sun

Wooと共に lustratorを用いてポスターを作成した．ポスターでは Adobe Illustratorの使

い方を学び，ポスターをどのように構成すると良いのかを学ぶことができた．

　中間発表会での発表場所が公立はこだて未来大学のミュージアムに決定したため，活動

写真のスライドショーとメディアデザイン専門の木塚あゆみ特任助教が作成した ICTをイ

メージするロゴを放映することを決定した．また，それらのスライドショーの作成を私が

行った．スライドショー作成に関してはWindows Live ムービーメーカーを用いて作成し，

動画のエンコーディングはフリーソフトである XMedhia Recode を用いて作成を行った．

このスライドショー作成に関しては，非常に時間がかかる作業であり，動画のエンコードだ

けでも１回 30分ほどかかってしまったり，PCの負荷が大きいので作業中に他の作業に着

手できないという点が大変だった．

　中間発表会当日に，本プロジェクトはスライドショーによる発表とポスター 2枚の展示を

行った．さらに，各グループが模擬開発演習として実装した面談予約管理システムと，各グ

ループが作成したユースケース図などを展示した．当日私は，ミュージアムのライトの設置



やプロジェクタの操作等を行い，発表時には主にポスターセッションを行った．

　中間発表会終了後，私たちは私たちの発表風景を録画したビデオを見ながら中間発表会の

反省会を行った．私自身はスライドによる発表を行っていなかったので，観客目線でメン

バーの発表のレビューを行うことができた．

• 中間報告書　中間報告書を作成するに当たり，私はグループ報告書，個人報告書，学習フィードバック

シートを作成するためのテンプレートを作成した．グループ報告書に関しては，各自が同時

に作業できるように作業ファイルを分割し，私がグループ報告書をマネジメントした．中間

報告書は本プロジェクトメンバー全員で役割分担をし書き上げた．

• オープンキャンパス　公立はこだて未来大学のオープンキャンパスにて本プロジェクトの発表を行った．オープ

ンキャンパスでは，見学にやってきた学生にわかりやすく説明するために，中間発表会で用

いたポスターと，各グループが実装した面談予約管理システムをデモとして利用した．私自

身はオープンキャンパスの発表担当ではなかったが，当日私は実際に会場に行き，発表の手

伝いなどを行った．

• 後期キックオフ　夏季休業が終了した後，本グループでは企業講師の方々を招き後期キックオフを行った．

後期キックオフでは，本プロジェクトで最初に行ったキックオフと同様に，アイスブレイク

を行った．アイスブレイクとして私たちは，マシュマロタワーを各グループ 3チームに分け

て作成した．今回のアイスブレイクでも，私はグループ Cのリーダーとしてマシュマロタ

ワーをどのような時間配分で作成するのかをメンバーに指示した．

• 本開発

現状調査私たちはイベント班として函館市近郊のイベント情報が現状どのように扱われて

いるのかを調査するため，函館市近郊のイベント情報を集約しているまちセン，函館市青年

センター様，函館市文化・スポーツ振興財団様へヒアリングを行った．このヒアリングにお

いて，私はまちセンへのアポイントメントを取り，まちセンと函館市青年センター様へヒア

リングに伺った．これらのヒアリングにより，現在函館市近郊のイベント情報がWeb上で

はうまく発信されていないということがわかった．

サービスの考案　 8月頃に本グループは，各施設へのヒアリングを元に，どのようにすれ

ば ICTで地域をデザインすることができるのかを考察を行った．当時，私はリーダーの一

人としてメンバー全員が意見をしっかり出せるように気をつけながらマネジメントを行っ

た．

　夏期休業中には，メンバーが帰省及びインターンシップに行く等，集合することができな

かったため，Skypeによる遠隔会議を行った．私も，夏季休業中に 1ヶ月間東京へインター

ンシップに行っており，インターネット環境がなかったため，携帯端末のテザリング機能を

用いて Skype会議に参加した．しかし，遠隔での会議は集合して行う会議と勝手が違い，十

分な進捗を得ることができなかった．このことから遠隔で会議を行う場合，十分に会議を行

う準備をする必要があるということがわかった．

　本グループでは，夏季休業中にイベント班として今後どのように問題解決を図るのかにつ

いて話し合いを行った．函館市近郊のイベント情報がうまく発信されていないという問題に

関して，私たちは問題を解決するための機能を考えるというプロセスを用いてサービスの考



察を行ってきたが，イベントを検索するユーザ自体の要望を考慮していなかったため，エン

ドユーザが使いやすいサービスを考案することができていなかった．さらに，この時点では

イベント班のリーダーが私と工藤卓也の 2人いるという状態であったため，効率が悪いので

はないかという指摘が上がっていた．

　夏季休業の終了が近づいてきた 9月の中旬頃，私たちは問題解決のプロセスを変更し，私

たち自身がどのような機能があると嬉しいのか，またその機能によりどのような問題を解決

することができるのかを考察することにした．その結果，夏季休業中に今後どのようなサー

ビスを実装するのかを決定することができた．私は，どのようなサービスが喜ばれるのか，

そのサービスがどのような問題を解決するのかを考察した．

　第 2 回企業講師レビュー会では，活動の報告や共有を行うため，プロジェクト内のイベ

ント班と野外劇班がどのように活動を行っていくのかを発表した．この時，イベント班内で

も問題になっていた「リーダーが実質２人いるという状態はよろしくない」ということが議

題に上がったため，イベント班のリーダーを兵藤允彦に決定した．さらに，私たちイベント

班では，夏季休業中に考察したサービスをしっかりドキュメント化する必要があると指摘を

受けたので，数名でそのドキュメントのたたき台を作成し，全体で集まった時にそれをレ

ビュー及び修正しながらドキュメントの作成を行った．

　本グループが特に力を入れたのは，イベント班がプロジェクトとしてどのように活動を行

うのかを明確化したプロジェクト憲章の作成である．プロジェクト憲章の作成はイベント班

の京谷和明がたたき台を作成し，イベント班全員で議論をしながら完成させた．私は主に，

作成したプロジェクト憲章に矛盾がないかなどの検証を行った．

提案 9月に，本サービスをまちセンへ提案する準備を行った．提案先をまちセンにした理

由は，私たちが 6月にヒアリングに伺った際，まちセンは唯一自身が開催するイベント以外

のイベントをWebサイトを用いて発信していたためである．提案に関する資料作りは主に

イベント班のリーダーの兵藤允彦とサブリーダーとして私と工藤卓也が行った．

　提案資料の作成に関して，私は主に提案するサービスの UI の概形を作成した．しかし，

担当教員の奥野拓准教授より，提案する際にはユーザがきちんとイメージできるようにブラ

ウザならばブラウザで表示しているように明瞭に作る必要がある，という指摘を受けたた

め，私は提案資料に用いる画像の作成や，説明の明確化を行った．

　提案の際，6月のヒアリングの際に面識があるということで，私が函館市地域交流まちづ

くりセンターセンター長の丸藤競様と連絡を取り，提案の日取りを決定した．10月上旬に，

私たちはまちセンへ，私を含めた計 5名でサービスの提案に伺った．当日私は，タイムキー

パー兼機器等の準備を行った．提案の結果，私たちの提案したサービスを絶賛して頂くこと

ができた．さらに，既存のイベント情報掲載ページから提案したサービスへの移行を検討し

て頂くことができた．私たちは 12 月頃に完成したサービスを見せるということを約束し，

本サービスを実装する許可を頂くことができた．

設計サービスの設計の際，本グループは 10名を，サービス内の各種機能を明確にドキュ

メント化する機能班と，サービスのデータ構造を定義するデータ班に分かれて設計を行っ

た．なお，私はデータ班のリーダーとしてデータ班のメンバーにタスクを割り振る仕事をし

ていたが，提案資料の作成などの仕事が重なってしまうことがあったので，データ班の菅野

久樹を中心にデータ班の作業をメンバーに勧めてもらった．その間，私は提案資料作成およ

び機能班とサーバ班の間の齟齬が発生しないように注力した．この際，本グループが実装す



るサービス名を「HakoEve」と命名した．

実装要件定義を行った後，私たちは提案したサービス HakoEveの実装を行った．Hako-

Eveの実装は設計段階で分かれていた機能班とデータ班を考慮し，サービスの UIを実装す

るクライアント班と，サービスの内部機能を実装するサーバ班に分かれた．私はサーバ班の

リーダーとして，各メンバーのタスクの割り振りや，進捗状況を確認した．本グループで

は，予めはこだて高等教育機関合同研究発表会「HAKODATEアカデミックリンク 2013」

までに確実に完成させる機能を明確化した．私自身はイベントが開催される場所の登録機能

と HakoEveのトップページに表示されるイベント情報の一覧表示の機能部分を実装した．

　開催場所の登録機能に関して，私は Google Mapsを使うということであったため，開催

場所を登録する人が登録する施設の緯度と経度を調べる手間を省くことができるように，住

所を入れることで緯度と経度の値を取得するため，Google Geocoding APIを用いて本機能

を実装した．

　 HakoEveのトップページのイベント情報の一覧に関して，私は当初，閲覧日以降のイベ

ント情報 30件を表示し，それ以上はページネーションを行う仕様に実装したが，この点は

要検討が必要であるということになったため，他のメンバーにこの機能を引き継いだ．

　アカデミックリンク終了後，本グループは引き続き HakoEveを完成させるため活動およ

び最終成果発表に向けての準備を行った．

評価アカデミックリンク終了後，私は他のメンバーとは別行動をし，HakoEveをまちセ

ンに評価して頂けるように準備を行った．　本グループでは，最終成果発表会とまちセンか

らの評価を頂くため，ニフティクラウドにて HakoEveを実装した．その際私は，正式なイ

ベント情報が表示されるように，まちセンが提供している既存のイベント情報掲載ページか

ら，12月以降に函館市近郊で開催されるイベント情報を探し出し，そのイベント情報の入力

を行った．また，11月分のイベント情報はイベント班の菅野久樹の協力を得てアカデミッ

クリンクで用いたデモ機より SQL文を出力したものを利用し，2014年 1月の分は，イベン

ト班の工藤卓也の協力のもと入力を行った．

　 12月 1日，私はイベント班の兵藤允彦，工藤卓也，京谷和明，菅野久樹とともにまちセン

に伺い，まちセンから HakoEveの評価を頂いた．まちセンからは，UIを調整し，修正点を

修正することで，実際にまちセンが現在使っているイベント情報掲載ページから，Hakoeve

へ移行をして頂くことになった．

　 12月 20日に行われた振り返り会が終了した後，本グループはまちセンから頂いた要件に

ついて検討を行った．なお，私は変更要件の確認と作成したドキュメントとの整合性が図れ

ているのかを検証した．

• アカデミックリンク　 11月上旬に，本プロジェクトでは，はこだて高等教育機関合同研究発表会「HAKODATE

アカデミックリンク 2013」に向けて活動を行った．アカデミックリンク当日には，当初アカ

デミックリンクまでに実装を終了することを決めていた HakoEveのトップページ及びキー

ワード検索機能，イベント情報検索結果画面，イベント詳細画面，イベント推薦機能の実装

を完了することができた．私は，アカデミックリンク当日までに，現在まちセンが既存のイ

ベント情報掲載ページに掲載している 11月分のイベント情報をアカデミックリンクで用い

るデモ機へ入力を行った．このデータを入力する作業を行ったことにより，実際にイベント

データを入力しているまちセンの労力の大きさを体験することができた．



　アカデミックリンクでは，北海道教育大学函館校や，北海道大学水産学部などの函館市の

他大学の方々と活発な意見交流を行うことができた．さらに，他大学の方々に来場して頂い

た市民の方々に，HakoEveについて知って頂き，意見や質問などを伺うことができた．初

めての他大学との合同研究発表会であったので，どのように発表すれば正確に伝わるのか，

どのようにすればスムーズに理解して頂けるのかを学ぶことができた．私自身もアカデミッ

クリンクでは北海道大学水産学部の教員の方々や，様々な学校の方と交流をすることがで

き，様々な研究テーマや研究内容を見ることで，自分の知らなかった知識や着眼点を得るこ

とができた．

• 最終成果発表会　アカデミックリンク終了後，私は最終成果発表のポスターの作成を主に行った．最終成果

発表のポスターは，本プロジェクトの概要を説明するものを１枚，模擬開発演習の説明をす

るものを１枚，野外劇班の活動を説明するものを 2 枚，イベント班の活動を説明するもの

を 2枚の計 6枚を作成することになった．私は主に，本プロジェクトの概要と本グループの

活動の概要をまとめたポスターの作成を行い，全てのポスターの取りまとめ作業を行った．

私が担当しなかった部分のポスターは，主に野外劇班所属の Kim Sum Wooに作成しても

らった．その際，私と Kim Sum Wooが密な連絡を取れるように気を配りつつ，最終成果

発表に用いるポスターの作成を行った．本プロジェクトの概要を掲載するポスターに関して

は，和文とともに英文を記載する必要があり，TAの方々のレビューを基に英文を大幅に修

正するなどしたため，とても苦労した．また，野外劇班の活動についての部分の表記につい

ては，Kim Sum Wooと協力して作成を行った．イベント班の活動を記載したポスターにつ

いて，1枚目にはイベント班の活動の概要や，問題解決のプロセス，学び等を記載した．2

枚目には，HakoEveについての概要や機能，メリットについて記載した．イベント班のポ

スターに関しては，どちらも私がレイアウトを決め，内容はイベント班のメンバーの協力を

得て複数人で考えた．

　最終成果発表会に向けたポスター作成は，12月 1日に行われたまちセンの評価を反映さ

せる形で作成し，最終成果発表会の前日に完成させることができた．

　その他にも私は，最終成果発表会も中間発表会と同様に，私は本プロジェクトの活動写

真のスライドショーを作成した．作成に用いたソフトウェアは，中間発表会の時と同様に

Windows Live ムービーメーカーと XMedhia Recodeを用いて作成を行った．中間発表会

の時に作成したスライドショーの作業ファイルを基にスライドショーを作成したため，中間

発表会の時より早くスライドショーは作成できたが，動画自体が大きくなってしまい，動画

のエンコードに 1時間以上かかってしまうことがあった．

　最終成果発表会当日は，全員でミュージアムのセッティングを行った．私は主に中間発表

会と同様に，ポスターの設置，ライトの設置，スライドショーの準備を行った．最終成果発

表会では全員が順に発表を行い，大きなミスもなく発表を行うことができ，皆堂々と発表を

行うことができていた．

• 振り返り会　 12月 20日に私たちのプロジェクトでは，今回のプロジェクトの振り返り会を行った．こ

の振り返り会では，企業講師の方々とプロジェクトを支えてくださった TA の方々ととも

に，今回のプロジェクトの学びなどを共有した．またこの振り返り会で，企業講師の方々や

TAの方々が，本プロジェクトに対してどのようにメンバーを教育するのかをしっかり考え

てくださっていることがわかった．



• 最終報告書　本グループでは，役割の分担を行い本報告書を作成した．私は，本報告書の取りまとめを

行い，メンバーの作業ファイルや本報告書の作成に関する進捗報告を行った．また，本報告

書を作成するにあたって，野外劇伴所属の齋藤尊と協力し，各作業ファイルごとに Redmine

のチケットを発行し，各メンバーの進捗状況や章ごとの進捗状況がわかるように工夫を

行った．

• 個人の学び　私は今回のプロジェクトで，以下の 4つのことを学ぶことができた．

　 1 つ目は，情報共有の難しさとそれを解決するための方法をメンバー全員でしっかり話

し合う必要があるということである．これは主に夏季休業期間中に，遠隔会議においてメン

バー間での連絡や情報共有をスムーズに進めることができなかったためである．ここから私

は，情報を共有しながらの作業は実際に対面しながら行うものと，遠隔で行うものは，まる

で異なるということを体験し理解した．実際に対面しながらの作業の場合，メンバーの考え

や資料は全員の手元やホワイトボードに残っているが，遠隔会議の場合それらを常に意識し

ながら共有する必要があるということがわかった．

　 2 つ目は，私自身が作業をし続けるよりも，他のメンバーをサポートする方が得意であ

るということである．私自身は，今回のプロジェクトの模擬開発演習において自分自身が作

業をし続け，周りのメンバーの活動を見ることを疎かにしてしまうという事があった．しか

し，イベント班としての HakoEve実装及び発表会の準備において，主にサポートやファシ

リテート，タスクの割り振りなどを行い，メンバーに対してうまく作業を割り振ることがで

きたと自負している．また，今回のプロジェクト学習を通して，私は誰にどのような作業を

してもらうか，誰がどの作業を得意としているのか，誰に任せると一番効率がいいのかを

しっかり考え選択ができるようになった．

　 3 つ目は，このプロジェクトメンバーの各人がお互いの特色などを知ることで作業の効

率が格段に上がっていくということである．私は，このプロジェクトメンバー全員が各メン

バーの特色について段々と理解することができていた思う．理由として，前期の模擬開発演

習において私の所属するグループ Cのメンバーが，段々と活発にコミュニケーションを取

るようになり，作業の効率が上がった．また，後期から本格的に活動を行った本開発におい

て，夏季休業中などはイベント班の活動も思うように進まなかったが，お互いに作業を進め

るうちに段々と作業効率を上げ，最終的にはとても短い期間で，要件定義，設計，実装を行

うことができたためである．前期に行った模擬開発演習が本開発の手助けになったのは言う

までもないが，前期に培った経験を異なるメンバーで共有できたことは，とても大きな学び

である．

　最後に，本プロジェクトを進める上で TAの方々や指導教員の方々，企業講師の方々の支

えが，必要不可欠であったということである．今回のプロジェクトにおいて，TAや担当教

員の方に発表の際に発表資料のレビューをして頂き，発表資料を作る指標や見せ方，想定質

問の考察などをして頂き，とても役に立った．企業講師の方々には，プロジェクトの進め方

という大きな枠について，どのようにすれば円滑に進むのか，どの点を工夫する必要がある

のかなどを教えて頂いた．私は TAの方々や，担当教員の方々，企業講師の方々がいなけれ

ば，今回のプロジェクトはこのように順調に進まなかったと思う．来年度は私自身が TAと

して，後輩がより成長できるように立ち回り，また後輩にプロジェクトをどのようにすすめ

ると良いか，どのようにドキュメントを作成するべきかなどを教えられるようになりたいと



思えるようになった．


5.10 菅野久樹

• 前期キックオフ　プロジェクト開始時のグループ分けでイベント班を希望し，グループ Cとして活動する

こととなった．

　 5月 10日に前期キックオフを行った．キックオフではアイスブレイク，目標設定と発表

のためのグループディスカッションを行った．この時点ではまだグループ内でそれほど打ち

解けているような雰囲気が無く，アイスブレイクでも，目標発表会でも積極的な発言が見ら

れないグループだった．発言があまりにも少ないと話が進まないと考えたため，キックオフ

では自分から積極的に発言したり，発言を促したり，リーダーの補助を行ったりして，ス

ムーズに活動が進められるように務める役回りになるよう心がけた．

• 勉強会　勉強会は，Redmine勉強会，Subversion勉強会を 1回ずつ行い，その後 3週間を使って

CakePHP勉強会を行った．Subversion勉強会，CakePHP勉強会では，周りのメンバーよ

りも比較的早く課題を解けたので，わからなくて進められていないメンバーを手伝うように

努めた．

• 模擬開発演習　模擬開発演習開始のための説明，準備を行った．模擬開発演習の説明を受けた後には，ま

ずどのようなタスクがあり，それぞれをいつ頃までに終了させなければならないかというお

おまかなスケジュール立てを行った．その後，模擬開発演習で使用するデプロイ用のサーバ

の設定を行った．OSのインストール，Apacheの設定や起動は既に終了していた．しかし，

デプロイに使用する Subversionにまだ不慣れであったこと，CakePHPの命名規則やパー

ミッション設定の知識が少なかったことなどが原因で，なかなか設定を完了させることがで

きなかった．この作業中に，CakePHPのエラーを読んでそれを解決するということを繰り

返し行なったため，ある程度経験が蓄積し，その後の開発で発生した CakePHPのエラーに

比較的短時間で対処することができるようになった．

　準備を終え，6月から模擬開発演習がスタートした．模擬開発演習ではまず，配布された

システム開発依頼書をチーム内で整理することから始めた．その後，顧客へのヒアリングを

行い，その結果をもとに要件定義を行い，要件定義書を作成した．要件定義書に従って設計

を行い，ユースケース図，ユースケース記述，業務フロー図などを作成した．各ドキュメン

トは TAにレビューをもらいながら作成していった．

　 6月の中旬に企業講師の方とのテレビ会議を行い，各ドキュメントのレビューを頂いた．

このテレビ会議では，わかりやすい説明の組み立て方などを主に指摘され，反省する点も大

いにあったため，ここで得た教訓が中間発表でも活かされた．

　設計においては，前半では効率の悪いドキュメント作成方法でなかなか作業が進まないと

いうことがあったが，テレビ会議を終えた後の設計後半では，効率の良い作成方法をチーム

内で考えるようになり，効率の上がった作業を行うことが出来た．ここで効率の良い作業を

行ったことで，チーム全体の士気も上がり，実装までその士気を維持することができた．作



業方法が士気を上げたと考えているが，それと同時に士気が上がったことによってさらに効

率が良くなったのではないかと考えており，メンバーの意識の違いが作業効率に大きく影響

するということを学べた．

　設計終了後，実装にとりかかった．実装においては，フロントエンド，サーバサイドのど

ちらもを担当した．また，行き詰まってしまい困っているメンバーのフォローに回ることが

出来た．自分のタスクと，フォローをしているメンバーのタスクで手一杯になってしまって

いたため，プログラミングが苦手なメンバーの成長を促すようなフォローを行うことはでき

ず，タスクをほとんど引き受けるような強引な形でのフォローになってしまった．

　中間発表の準備中は模擬開発演習は中断していた．中間発表終了後は中間報告書の作成に

着手したため，模擬開発演習は中間報告書の作成と平行して行うこととなった．模擬開発演

習の実装は 7月の末に完了し，納品を行うことができた．

• 中間発表会　 6月の後半には，中間発表会に向けての資料作りも開始した．チームをスライド班，ポス

ター班の 2つに分け，私はスライド班として割り当てられた．

　 7月の上旬は中間発表会に向けてスライド作成と発表練習を行った．作業分担で私はスラ

イド作成に割り当てられた．スライド作成では当初は Googleドライブのプレゼンテーショ

ン作成機能を用いて，複数人での同時作業ができるように配慮した．しかし，作業自体はス

ムーズにできるようになったものの，発表練習をするためにファイルをダウンロードする

と，テキストのフォントが変更されていたり，レイアウトが崩れていたりして，使い物にな

らないファイルしかダウンロードできないことが判明した．結局，Googleドライブで作成

したものは使用しないということになってしまい，作業の手戻りが生じてしまった．複数人

での作業に配慮したつもりだったが，ファイルが使えるかどうかまで配慮が行き渡っておら

ず，段取りの悪さを痛感する結果となった．

　当日の発表では私はポスターセッションの担当になったため，ポスター発表練習に主に参

加していた．発表方法やスライドの改善のため，スライドの発表練習にも参加していた．

• 中間報告書　中間報告書の作成では，Subversion を用いて管理を行ったため，各担当分のマージがス

ムーズにできた．

• 本開発

現状調査 6月からはイベント班としての活動も開始した．まず最初にイベント情報につい

ての現状の問題点を発見するために，函館市のイベント情報を取り扱っているイベント情報

発信サイトを調べた．また，イベント情報を多く発信している 3団体にイベント情報の現状

についてのヒアリングを行った．私は 3団体のうち，まちセンにヒアリングに伺い，イベン

ト発信サイトの運営に関する業務フローなどを伺うことが出来た．

サービスの考案夏休み中に，後期からどのようなサービスを開発するのかについてのミー

ティングをイベント班全体で複数回行った．ミーティングは主に Skype を用いて遠隔で

行った．Skypeでのミーティングはあまりうまく進まず，会議の方法に問題があると考えた

ため，会議の方法の変更を提案した．

　夏休み終了直前に，イベント班全員が集まる会議を設けた．それまでの話し合いの方針を

変更し，自分があったらいいと思う機能を挙げ，それに基づいて開発するサービスを考えて

いくという方針にした．この会議によりキーワード検索，タグ検索，日付検索，地図・場所



検索，リコメンド機能を搭載したサービスを構築するという方針が定まった．その後，サー

ビスの運用者が誰なのかを明確にするためにまちセンが提供している既存のイベント情報発

信サイトを改良しようということが決定した．夏休み明けには，スケジュール修正を行い，

大幅にずれた計画の見直しを行った．

提案 9 月下旬から，まちセンへ提案を行うための準備を開始した．機能の詳細を決定し，

画面イメージと共に提案資料を作成した．サービスをまちセンに運用して頂く案と，まちセ

ンの協力の下，独立したサービスとする案があったため，そのどちらも提案資料に盛り込

み，まちセンの意向を伺うことにした．提案に伺った結果，提案内容に賛同していただくこ

とができ，まちセンがサービスを運用するということに決定した．

設計開発は設計段階に入り，作業は機能班とデータ班の 2つの班に分かれて行った．私は

データ班として，データベース設計，ER 図作成，テーブル定義書の作成，phpMyAdmin

を用いたデータベース作成作業にあたった．

実装 10月の下旬から実装を開始した，実装では班構成を変え，サーバ班とクライアント班

の 2つに分けた．私はサーバ班として実装を行った．実装ではペアプログラミングを採用し

たが，人数の都合上，私は 1人での実装となった．

　 11 月からは 10 月よりもクライアント班のメンバーと細かい打ち合わせをしながら実装

を行うことができ，効率が少しずつ良くなっていった．

　アカデミックリンク終了後の実装では，サーバ班のメンバーもかなり実装に慣れてきたよ

うで，スムーズに実装を進めることができた．模擬開発演習時と同様に，行き詰まってし

まっているメンバーのフォローに回るような役回りをすることも多かったが，模擬開発演習

時と違い，この頃にはかなりメンバーの性格，性質をよく見た上で，メンバーそれぞれに合

わせたフォローを行うことができた．プログラミングが苦手と言っても，プログラミングの

どの部分が苦手なのかには個性があったため，フォローに回る際の時間のかけ方や言葉選び

はその都度，メンバーが力を発揮しやすいように考えることで，スムーズにフォロー作業と

自分の作業を行うことができた．この気を付けていることをメンバーに話したところ，私の

人を見る力に感心されたため，私は人を見る力があるのではないかと新しい自分の長所に気

付くこともできた．

　 11月の下旬には，まちセンとの進捗報告会までのタスクはほぼ全て終了し，残ったタス

クは何か，今後タスクを進める上で注意することは何かといった確認を行った．

評価 12月 1日にまちセンへ進捗報告へ伺った．進捗報告では開発中のサービスの説明を

し，実際に使って頂いた．この報告で得たコメントを検討し，仕様変更を行うことが決定し

た．仕様変更の検討では，変更点をまとめたドキュメントの作成を担当した．ドキュメント

はまずはじめにたたき台として作成したものをメンバー全員に見せ，レビューをもらってか

ら修正を行った．

• アカデミックリンク　アカデミックリンクに向けてポスターの作成が開始されたが，私は実装に専念することに

なったため，発表練習が開始されてから，アカデミックリンク発表準備に参加した．

• 最終成果発表会　最終成果発表会では後半の発表を担当した．開発中の HakoEveのデモとスライド発表を

担当したが，中間発表時の反省を活かしタイムキーパーも兼任し，発表時間の管理もでき



た．これによって，中間発表で起こってしまったような混乱が起こることもなく，スムーズ

に発表を進めることができた．

• 個人の学び　私は今回のプロジェクトで，チーム開発の難しさを身を持って知ることができた．今まで

個人的に開発を行うことはあったが，本格的にチーム開発を行ったのは今回が初めてであっ

た．

　模擬開発での要件定義などの上流工程を行ったときに，初めてチーム開発の難しさを感じ

た．要件定義，設計などの上流工程を行っている最中には，その工程を面倒だと感じてしま

い，上流工程をできるだけ少なくして早めに実装を開始してしまえば，時間短縮になると考

えていた．その後，上流工程を完了し，実装を開始したが，メンバー内での認識の違いや，

設計時に作成したドキュメントの不備によって実装がスムーズに進まないという問題が発生

した．問題が発生してようやく上流工程の重要さを感じることができた．

　個人での開発では，設計などをしなくとも，実装途中に仕様変更を行ったり，まず実装し

てみてそれから変更が必要かどうか考えたり，などの自由な開発方法が可能だった．これ

は，個人での開発では自分自身だけが責任者なので考えが統一されており，さらに制作物の

ソースコードレベルでの詳細な部分も全て自分 1人で把握しているためにできる開発方法で

あるということがよくわかった．

　チーム開発の場合には，作業を分担している以上，自分が把握していることと，他のメン

バーが把握していることにどうしても差が生じてしまい，これをいかに少なくしていくかが

開発をいかにスムーズにしていくかということであるとわかった．チームビルディングや，

作業分担の仕方，上流工程で情報共有のための工夫をすることができれば，実装時に混乱が

発生することもないだろうということが模擬開発を通じて学ぶことができた．

　本開発では模擬開発時の教訓を活かして，実装時に混乱が発生するような事態が一切起こ

らないようにしたかったが，実際には多少発生してしまっていた．これはスケジュール上，

設計に割ける時間が限られていたというのが原因で，十分な対策をすることができなかった

からだと分析している．情報共有は重要だが，限られた時間内でいかに効率良く行えるかが

さらに難しい部分だと感じ，模擬開発時とは違った学びが得られた．




第 6 章プロジェクト全体の活動と学び

6.1 前期キックオフ

5月 10日にプロジェクト開発についてノウハウがある企業講師の高森満様と木下実様のお二方

からプロジェクトにおける開発工程や，役割分担が重要になるなど，今回一年間行ったプロジェク

トや今後企業に就職し行うであろうプロジェクトをどう進めていくと成功に近づけるのかを実際に

アイスブレイクを通して簡単に学んだ．

　アイスブレイクで，プロジェクトが始まったばかりでお互いの事をまだ知らない各グループで，

ペーパータワーを作成することによって，メンバーの先頭に立って物事を進めるタイプ，一歩引い

て進行のサポートに回るタイプなどの問題解決における前期キックオフを行う前では，知らなかっ

たグループメンバーごとの特性を知る事ができた．これを踏まえて今後のどう進めていくと成功に

近づけるのか学ぶ事ができた．

　また次に行われた自己紹介で，学部が異なり学んできたことが異なる各メンバーが，今まで何を

やってきたのか，何が得意なのか，本プロジェクトで何を学びとして期待しているのかを発表し

合った．コーディングが得意だが本プロジェクトを通してデータベース設計の知識を学びたい，ア

プリケーションを作りたいなど，各メンバーが本プロジェクトに対して求めるものを知る事がで

きた．


6.2 CakePHP勉強会

CakePHPによるプログラミングを学ぶことで模擬開発演習，本開発におけるシステム実装の知

識を得た．勉強会は 4回に分けて行われ，それぞれの回で，Formヘルパーの使い方，データベー

ス利用の基本，バリデーションの利用，テーブル連携を学んだ．さらに各回で学んだ知識を確認す

る演習を行い理解を深めた．演習ではチェックボックス，ラジオボタンといったフォームの作成，

データベース操作といった内容を取り扱った．最後には，各回で学んだ知識を総合したWebアプ

リケーションを実装する演習を行った．

　勉強会を通して，Webアプリケーションを開発する技術を習得することができた．さらに，メ

ンバー間での教え合いの様子も多く見られ，チームワークの向上にもつながった．なおこの勉強会

には，CakePHP2.1によるWebアプリケーション開発[1] を使用した．


6.3 Redmineによるプロジェクト管理

タスク管理や議事録管理，情報共有のためにオープンソースのプロジェクト管理ソフトウェアで

ある Redmineを用いた．しかし，チケット発行やWikiの使い方などの運用上のルールがなかっ

たために，具体的なタスク管理が出来ていなかった．そのため Redmine運用ルール作成班を設け，



運用ルールを作成した結果，担当している学生や現在の進行状況をプロジェクト全体で共有できる

ようになった．このことから，タスク管理ツールについても具体的な運用ルールを設けることが，

チームでの開発では大切なことであると学んだ．

　また，プロジェクトに関する連絡事項がある場合は，連絡掲示板を用いた．活動の議事録に関し

ては Redmineのフォーラム機能を利用して，管理を行った．議事録についても運用ルールを定め

ることで，全体の議事録やグループごとの議事録，発表準備時の議事録などを上手く整理して管理

できるようになり，情報共有が円滑に進んだ．


6.4 Subversionによるバージョン管理

オープンソースのバージョン管理システムである Subversionを利用することで複数人でソース

コードやドキュメントを管理することができた．うまく作業分担ができていなかったために，コ

ミット時にコンフリクトを起こしたり，うまく使いこなさないと最新版が分かりにくくなってし

まったりなど，バージョン管理の難しさが分かった．HakoEve構築の際は，設計と実装でグルー

プごとにディレクトリを分けるなどの工夫をした．誤って他の人の成果物を消してコミットしてし

まったり，コミットとアップデートを間違って行ってしまうなどの問題が発生しが，復元を行うな

どして，解決することができた．こういった問題を解決していく中でバージョン管理と Subversion

の理解を深めていくことができた．


6.5 中間発表会

中間発表会での発表資料を作る上で，何が発表をする上で重要な情報で，何がそれほど重要では

ないのか考えることで，情報の優先度を見極めることを学んだ．発表場所が公立はこだて未来大学

ミュージアムに決定し，広いスペースでの発表ができることで，模擬開発で作成した各グループの

成果物をどのように展示し，どこでスライド発表を行い，ポスターをどこに展示するかを教員の

方々のご協力をいただき決定することができた．

　さらに，発表練習を重ねることで発表資料を読むのではなく，相手に聞いてもらえるような発表

ができるように相手の方を見てわかりやすく発表する大切さを学んだ．中間発表会当日の発表中に

プロジェクタが破損し，代わりのプロジェクタを用意していなかったことから，リスク管理の重要

性を学んだ．

　そして，発表のフィードバックを集計した結果，発表技術点数の平均が 10点満点中 6．8点，発

表内容点数の平均が 10点満点中 6．5点という良い結果が出た．発表技術コメントとして，「話し

ている内容がとてもシンプルで分かりやすかった．」「提案についてのスライドの図があるおかげで

全体の提案や現状などがわかりました．」などのコメントをいただき，発表技術のコメントとして，

「問題点，それに対してのアプローチ，解決方法が明確でプロジェクトの方針が良くわかった．」「私

たちが作ったシステムの評価をもらう仕組みが明示されていないので問題点が見えなかった．」「問

題を挙げるところでも図などがあるとよりよかったです．」などのコメントを頂いた．これらの結

果よりこちらが伝えようとしていることは，なかなか相手に伝わらないことを学んだ．




6.6 オープンキャンパス

私たちのプロジェクトは 8 月 4 日，公立はこだて未来大学で開催された「OPEN CAMPUS

2013」に学科出展として参加した．そこでは，私たちが行ってきた模擬開発や本開発の内容をポス

ターとデモを通しての発表形式で出展した．デモでは，中間発表会でも出展した各グループで構築

した面談予約管理システムのデモを出展した．

　私たちは出展に訪れてくださった方に対して，ポスターを使って簡単にプロジェクトの概要を説

明し，実際に各グループの面談予約管理システムを使って面談の予約を行っていただいた．中間発

表会では，スライドでの発表が主な発表であったので，ポスターセッションやデモでの説明を経験

しなかったメンバーがいた．そのため準備の段階で説明する形式の役割分担を決めポスターセッ

ションとデモの説明の両方を行えるようにした．

　オープンキャンパスを通して，IT分野に詳しい人や詳しくない人に対してどのように説明した

ら，私たちがしてきたことをポスターセッションやデモの説明を通して知ってもらえるか各メン

バーが考え実践できた．その結果，発表に慣れていないメンバーも数多くの発表の経験を通して慣

れる事ができ，今後の発表会での発表に活かす事ができた．


6.7 札幌オープンキャンパス

本グループは，9月 20日に札幌駅の地下歩行空間で開催されたオープンキャンパスに参加した．

オープンキャンパスでは，主にポスターセッションを通して高校生だけでなく，一般企業の方々に

説明を行った．未来大学を札幌に持って行くというコンセプトとの元で行われたこのオープンキャ

ンパスでは，未来大学の学生の実際の学びを体験していただくために，プロジェクトの内容や成果

について発表した．ポスターセッションでは，聞いている人の表情やしぐさを読み取ることで本当

に理解しているのかを知ることができた．さらに，もし理解してくれていないならば説明の仕方を

変えて理解を促すといったコミュニケーションのテクニックも学ぶことができた．

　ポスターセッション以外にもプロジェクトの活動に関する会話を行った．一般企業の方々とは，

プロジェクトの成果物，活動内容に関する詳しい話もすることができ，多くのアドバイスもいただ



6.8 後期キックオフ

9月 27日後期の最初の活動日に前期と同様にキックオフを行った．最初に企業講師の高森満様

と木下実様に「段取り力」とは目標にむかって何をいつまでにどこまでしなければならないのか優

先順位をつけて計画すること，先を見越して行動する事などをチームディスカッションを挟みなが

らご説明いただいた．

　次に模擬開発演習の 3グループに分かれてアイスブレイクを行った．アイスブレイクではマシュ



マロ 1個とパスタ 20本とマスキングテープを使用してマシュマロタワーを制限時間内にグループ

ごとに作成した．制限時間内により高いマシュマロタワーを完成させるために，設計の時間と作成

の時間を各グループがご説明頂いた，「段取り力」を活用させながら作成した．マシュマロタワー

を作成し計測を終えてからは各グループで作成のプロセスにおいて，何が起こったのか，何が良

かった，何が悪かった，その原因は何があったのか分析を行い，振り返りを行い反省をした．

　最後に各グループの進捗報告を企業講師の方にし，リーダーが 2人いる本プロジェクトの体制に

ついてご指摘いただき，リーダーを 1人にすることにした．これにより，後期の活動をより良いも

のにすることができた．


6.9 アカデミックリンク

2013年 11月 9日土曜日に函館市青年センターで行われたキャンパス・コンソーシアム函館が主

催する「HAKODATEアカデミックリンク 2013」に本グループの概要について出展をした．この

イベントは，函館市内の高等教育機関合同研究発表会で全 43チームが展示を行った．

　この発表会に参加するにあたり，HakoEveのデモと活動内容が記されたポスターを用意する必

要があった．HakoEveのデモに関してはキーワード検索機能までの実装が完了していたので，そ

こまでの機能のデモを行った．また，ポスターについては，本グループの主な活動内容や HakoEve

の機能の詳細を記したものを作成した．

　発表会当日は，多くの他大学の学生や函館市民の方々に見て頂き，HakoEveに関する貴重なご

意見やご感想を頂いた．開発途中ではあったが，この日が初めて HakoEveの一般市民に向けたお

披露目となった．

　この発表会では，HakoEveに関する見学者の貴重な声の他に発表技術に関しても学ぶことがで

き，大きな成果となった．今回の見学者の多くは ICT に精通していない一般市民がほとんどで

あった．そのような人に対して，どのような方法で説明をすればうまく伝わるのかといったことを

メンバーそれぞれ学ぶことができた．図 6.1は，アカデミックリンクのときに撮影した集合写真で

ある．


6.10 最終成果発表会

最終成果発表会では HakoEveの実装もあり，スライド班 3名，ポスター班 3名とプロジェクト

メンバー全員をスライド班かポスター班のどちらかに割り当てた中間発表会に比べ，少人数での作

業を行った．

　中間発表会での資料づくりの際には，先生や TAの方々から何度もレビューを頂き資料を完成さ

せた．そのレビューで言われたことなどを参考に資料づくりを行った．しかし，今回のスライドで

は，13分という短い時間の中で模擬開発の話と HakoEveの話，別の班で行っているもう一つの本

開発である野外劇の話もする必要があったため，第一版の完成時に行った発表練習では大幅に時間

を超えてしまった．そこで，今回の発表で伝える相手は誰なのか，その相手には何を伝えることが

大事なのかを改めて検討した．その結果，スライド枚数を大幅に減らすことができた．それ以降も



図 6.1 アカデミックリンク集合写真

プロジェクト担当教員や TAの方々に多くのレビューを頂きながらスライドを完成させていった．

ポスターも中間発表に比べ，プロジェクト全体 1枚，模擬開発 1枚，野外劇班 2枚，イベント班 2

枚と枚数も多く，どのポスターに何を書くかなどを決めた．スライドと同様にプロジェクト担当教

員や TAの方々や木塚あゆみ特任助教に何度かレビューを頂き完成させた．

　最終成果発表会も中間発表会同様，ミュージアムで行うことになった．中間発表会のノウハウも

あり，会場設置についてはスムーズに行うことができた．中間では 6 人しかスライド発表を行わ

なかったが，最終成果発表会ではメンバー全員が発表するようにした．そのため，メンバーはしっ

かりと発表練習を行った．しかし，メンバーのほとんどがポスターでの発表練習は行えていなかっ

た．

　最終成果発表会当日ではスライド，ポスター，デモの 3つに分けて発表を行った．中間発表会の

ようなトラブルもなくスムーズに行うことができた．また，メンバーそれぞれの発表技術が向上し

ていた．

　フィードバックシートを集計した結果，発表技術点数の平均が 10点満点中 7.8点，発表内容点

数の平均が 10点満点中 8.0点だった．発表技術点数，発表内容点数ともに中間発表会に比べ 1点

以上増えていた．発表技術コメントとして，「スライドの流れが上手く，わかりやすかった．」など

という良い意見を数多く得ることができた．しかし，「写真や図がもっとほしい．」という中間発表

会で頂いた意見をうまく活用できてない部分も見られた．発表内容については，「模擬開発での成

果が本開発にどう繋がっているのか，あるいは本当に効果があったのかが明確でない．」というよ

うなスライドの指摘などを頂いた．しかし，全体的に中間発表会に比べ，良い意見を頂くことがで

きた．

　図 (6.2)は最終成果発表会の時のスライド発表風景である．



図 6.2 最終成果発表会の様子


6.11 振り返り会

12月 20日に企業講師の高森満様と木下実様を招いて，1年間を通してのプロジェクト全体の振

り返り会を行った．この振り返り会ではこの 1年間を通して行ってきたことを，文章や映像を用い

て振り返った．その後に PBLの開発工程に関する復習を行い，ウォーターフォールモデルについ

てや役割分担について，実際の企業の PBLはどうなっているのかを学んだ．

　その後，自分自身の学んだことや反省点，改善点などをポストイットにまとめた．各自まとめた

ものをイベント班，野外劇班とそれぞれのチームに分かれてチーム全体の気づいたこと，反省点，

次に活かすことなどをまとめていった．そのまとめたものをチームごとに発表し，企業講師の方々

や，TA，教員の方々とここはこうすればよかったのではなど，反省点の改善案を複数出した．こ

の振り返り会を通して，今後の私たちの活動や来年度の 3年生に向けての多くのメッセージを残す

ことができた．




第 7 章おわりに

本グループでは HakoEveという函館市近郊のイベント情報検索サービスの開発を行った．イン

ターネット上でイベント情報を探す人にとって情報が探しやすくなり，その結果，より多くの人々

に函館市近郊のイベントを知ってもらうことを目指し私たちは活動を行ってきた．現在は 12月 1

日の進捗報告で新たに HakoEveに関する要望を頂き，一部仕様の変更を現在実装中である．また，

2月 15日に HakoEveの有用性検証のテストを予定し，今年度中の納品を目指している．

　本グループは，実際にサービスの提案をし，そのサービスを使って頂けることが決まったこと

で，本グループの活動にとって大きな一歩を踏み出すことができた．それによって HakoEveの有

用性検証の準備段階まで進めることができた．またその中で，大きな学びとしてメンバー間の情報

共有の難しさを知り，またエンドユーザの目線に立ってサービスを考える難しさを知った．それに

よって，お客様の要求を分析することに力を注いだ結果，分析する力，それを実現していく力を磨


　今後の活動は，来年度 4 月から HakoEve のサービス運用が開始されるのでそのサービス保守

を主として活動する．同時に，Facebookによる HakoEveの宣伝も引き続き行っていく．また展

望として，HakoEveのスマートフォン対応のアプリケーションソフト開発も視野に活動していき

たい．




謝辞

　本グループの進行にあたり，多くの方々にお世話になりました．ここに深く感謝の意を表しま

す．

　企業講師の高森満特任教授，木下実様には，テレビ会議やレビュー会を通して本グループの活動

や成果物に対するアドバイスやレビューを熱心にご指導して頂きました．また，メンバーの意識共

有をとるためにプロジェクト憲章作成のご教示や発表会におけるプレゼンテーションスキルのご指

導を頂きました．心より感謝致します．

　本プロジェクト担当教員の大場みち子教授には，模擬開発演習を始めるにあたり，チケット管理

に関する講義やマネジメント論，発表資料やプレゼン技術のご指導を頂きました．奥野拓准教授に

は．本グループにおける問題定義から設計，実装のすべてのフェーズにおいて大変熱心なご指導

を頂きました．伊藤恵准教授には，Redmineや Sunbversionの環境構築など私たちが円滑にプロ

ジェクトを進めることができるための様々なサポートをしていただきました．

　ロゴの作成や発表用のポスター作成，発表会場のデザインに関するご指導をして頂いた，木塚あ

ゆみ特任助教に深く感謝致します．

　また，本グループの技術的アドバイスや発表資料のレビュー，時にはメンタル面のサポートをし

て頂いた TAの皆様にも深く感謝致します．

　最後になりますが，本グループの活動にあたり，ヒアリングの実施を快く引き受けて頂いた函館

市地域交流まちづくりセンターの丸藤競様，函館市青年センターの仙石智義様，財団法人函館市文

化・スポーツ振興財団の米田哲夫様には，感謝の念にたえません．また，函館市地域交流まちづく

りセンターの丸藤競様におきましては，本グループが提案したイベント検索サービス HakoEveへ

の快い賛同や数回に渡る訪問に対しても快く引き受けて頂きました，ありがとうございました．さ

らに，現状の市民活動情報から HakoEveへのご移行の快諾に関しても，本グループ一同心より感

謝致します．




付録 A 新規習得技術

• Redmine

• MySQL

• CakePHP

• TeX

• Adobe Illustrator CS6

• Subversion

• Apache HTTP Server

• astah* professional

• PHP

• JavaScript

• CSS

• HTML

• jQuery

• サーバ構築



付録 B 活用した講義

• ソフトウェア設計論 I

• ソフトウェア設計論 II

• システム管理方法論• 情報マネージメント論• プリンタ講習会• TeX講座

• 科学技術リテラシ• データベース工学• 情報機器概論• プロジェクトマネージメント• ヒューマンインターフェース



参考文献

[1]しょうだ

掌田つやの

津耶乃. CakePHP 2.1によるWebアプリケーション開発. 秀和システム, 2012.

[2]すずき

鈴木けんじ

憲治,あんどう

安藤けんいち

建一,やまだ

山田なおあき

直明,やぎ

八木てるお

照朗,やまもと

山本よしゆき

義之,かわい

河合かつひこ

勝彦. PHP 逆引きレシピ. 翔泳社,

2009.

[3]ほしの

星野かほこ

香保子. ゼロからわかる PHP超入門 Webプログラミングの第一歩. 技術評論社, 2000.

[4]かわい

河合あきお

昭男. ゼロからわかる UML超入門. 技術評論社, 2012.

[5]たきもと

滝本まさゆき

雅之,おおもり

大森くみこ

久美子,いとう

伊藤かずお

和夫,よしの

吉野じゅん

順 ,きたに

木谷つよし

強 . 実例で学ぶソフトウェア開発. オーム社,

2011.

[6]そうむしょう

総務省. 総務省｜ u-Japanベストプラクティス　地域情報化ポータル. http://www.soumu.

go.jp/menu_seisaku/ict/u-japan/tkportal/casestudy_117.html, (2014/1/14 アク

セス).


Documents

公立はこだて未来大学 2013 年度システム情報科学実習 グ …sisp/old_report/2013/03/document03_B_C.pdfProject Name Regional Design with ICT - Construction of Useful

公立はこだて未来大学 2013 年度システム情報科学実習グ …sisp/old_report/2013/03/document03_B_C.pdfProject Name Regional Design with ICT - Construction of Useful