公立はこだて未来大学 2013 年度 システム情報科学実習
グループ報告書
Future University Hakodate 2013 System Information Science Practice
Group Report
プロジェクト名
ICT で地域をデザインする
- お客様のための使えるシステム構築 -
Project Name
Regional Design with ICT - Construction of Useful Systems for Users -
グループ名
野外劇班
Group Name
Yagaigeki Group
プロジェクト番号/Project No.
3/A
プロジェクトリーダ/Project Leader
1011057
兵藤 允彦
Masahiko Hyodo
グループリーダ/Group Leader
1011205
花田 洋貴
Hirotaka Hanada
グループメンバ/Group Member
1011044
安藤 大岳
Daigaku Ando
1011241
齋藤 尊 Takeru Saito
1011259
吉田 匡孝
Masataka Yoshida
7009755
金善禹
Kim Sun Woo
指導教員
大場 みち子
伊藤 恵
奥野 拓
Advisor
Michiko Oba Kei Ito Taku Okuno
提出日
2014 年１月 15 日
Date of Submission
January 15, 2014
概要
本プロジェクトでは，ICT(Information and Communication Technology) を用いて，シ
ステム開発の工程を体験し，実践的なスキルを学びながら，地域をデザインしていく．その手
段として，函館野外劇のチケット予約システムの開発と函館市近郊のイベント検索サービスの
構築を行う．本プロジェクトの目的は，これら 2 つの手段に取り組むことで地域を活性化し，
市民や観光客の支援に繋げることである．また，お客様に使って頂けるようなシステムを構築
するスキルを学ぶことである．
本グループでは，函館野外劇におけるチケット予約システムの構築を行い，目的達成を目指
す．市民創作「函館野外劇」(以下，函館野外劇) は 1988 年の第 1 回公演以来，毎年 7 月から
8 月末まで五稜郭公園で行われている国内最大規模の野外公演である．公立はこだて未来大学
(以下，未来大学) では，2006 年から 2008 年にかけて野外劇チケット予約システム（以下，既
存システム）を開発した．野外劇では，既存システムが現在も運用されている．函館野外劇を
運営している NPO 法人市民創作「函館野外劇」の会（以下，野外劇の会）は既存システムに
一部使いづらい部分があると感じており，本プロジェクトに既存システムの改善を依頼した．
既存システムには大きく分けて 2 つの問題がある．1 つは，適切な機能と UI を有していな
いという点である．これは，野外劇の会が既存システムを使いづらいと感じる原因であり，既
存システムが野外劇の現在の業務に対応しきれていないということである．もう 1 つの問題
は，既存システムは現在未来大学のサーバ上で稼働しているという点である．これは，既存シ
ステムを未来大学が管理しなければならないということであるが，研究教育機関である未来大
学が商用にシステムの管理をし続けることは不可能である．これらの問題に対し本プロジェク
トでは，既存システムの良い部分を踏襲しつつシステムの再構成を行い，野外劇の現在の業務
に即したシステムを開発することで解決を目指す．また，開発システムを未来大学サーバから
外部サーバへ移行し，野外劇の会独自でのシステム運用方法を提案することでシステムの運用
保守の問題の解決を目指す．
システム開発は，前期に模擬開発を行い，システム開発における要求分析や設計等の一連の
開発工程を経験する演習を行った．この経験を活かし，ウォーターフォールモデル開発の手順
に従い，現在は要件定義を終え，システムの設計に取り掛かっている．今後は１月中には実装
を始めて２月末でシステムのテストに入り，3 月に納品することを予定している．また実装に
関しては，PHP の Web アプリケーションフレームワークである CakePHP を用いる．
キーワード
ICT, 市民創作函館野外劇, 「函館野外劇」の会, 野外劇チケット予約システム,
模擬開発
（※文責: KIM SUN WOO）
-i-
Abstract
In this project, we will design the region using ICT(Information CommunicationTech-
nology) while we experience the process of system development and learn practical
skills. As a way to achieve this theme, we will develop a Ticket Reservation System
of “Hakodate Open-Air Play Created by Citizens of Hakodate” (hereinafter “Hakodate
Yagaigeki”) and we will develop the service that provides the information of events held
in Hakodate. The purpose of this project is to support the region and tourists moreover
to restore vitality to the region by working on these two themes. Also, we will acquire
the skill of construction of useful systems for users.
Our group is developing the Ticket Reservation System of “Hakodate Yagaigeki”.
“Hakodate Yagaigeki” is the largest scale domestic open-air play which is parformed
from July to the end of August in Goryoukaku park every year since 1988. Students
of the Future University Hakodate(hereinafter Future University) developed a Ticket
Reservation System of “Hakodate Yagaigeki” from 2006 to 2008. Hakodate Yagaigeki’s
staff have been using that system. Member of the “Association of Hakodate Open-Air
Play Created by Citizens of Hakodate” (hereinafter “Association of Yagaigeki”) thought
that it has some inconvenient points and they commissioned our project to improve this
system.
There are two problems in the existing system. First, there are no suitable function
and user interface. This problem is the cause of that “Association of Yagaigeki” thought
that it is hard to use and it suggest that the existing system cannot deal with client’s
business. The other is that the existing system has been running on the Future University’s server. Which means Future University have to manage this system. But, Future
University cannot continue to manage it for business forever because Future University
is the education and research institution. So, we aim to follow the existing system’s
good points and rebuild that system and resolve these problems.
In addition, we will migrate The Ticket Reservation System from Future University’s
server to external server and suggest system operation method in the “Association of
Yagaigeki” alone for resolving the problem of the system operation and maintenance.
In the system development, first, we performed simulated development and performed
practice to experience a series of development processes such as requirement analysis or
the design in the system development. According to the water fall model, we finished
with requirement definition process in a base by the experience and are designing the
system now. Then, we are going to begin programming in January and test the new
system. And we are going to deliver in March. We use CakePHP for programming.
Keyword
ICT(Information and Communication Technology)，Hakodate Open-Air
Play Created by Citizens of Hakodate，Event，Ticket Reservation System，Aggregate
and Transmit System，Simulated Development
（※文責: KIM SUN WOO）
- ii -
目次
第1章
はじめに
1
1.1
本プロジェクトについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
本プロジェクトの背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3
本プロジェクトの目的と手段
2
第2章
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
模擬開発
3
2.1
概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.3
目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.4
問題解決プロセス
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.5
成果物 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
函館野外劇におけるチケット予約システムの構築
7
3.1
概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2
背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.3
目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.4
開発の進め方 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.5
開発体制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.6
問題解決プロセス
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.6.1
プロジェクト設立 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.6.2
現状調査工程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.6.3
提案工程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.6.4
要件定義工程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.6.5
設計工程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
第3章
3.7
野外劇の会の業務
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.8
新システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.8.1
概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.8.2
機能詳細 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.8.3
運用体制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.9
成果物一覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.10
今後の予定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
スケジュール
29
4.1
全体 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.2
模擬開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.3
本開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
個人の活動
35
花田 洋貴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
第4章
第5章
5.1
- iii -
5.2
安藤 大岳 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.3
齋藤 尊 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.4
吉田 匡孝 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.5
金善禹. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
成果と学び
73
6.1
キックオフ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
6.2
CakePHP 勉強会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
6.3
Redmine によるプロジェクト管理 . . . . . . . . . . . . . . . . . . . . . . . . . .
73
6.4
Subversion によるバージョン管理 . . . . . . . . . . . . . . . . . . . . . . . . . .
74
6.5
テレビ会議によるレビュー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
6.6
企業講師レビュー会でのレビュー . . . . . . . . . . . . . . . . . . . . . . . . . .
74
6.7
中間発表会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6.8
オープンキャンパス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6.9
札幌オープンキャンパス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
6.10
後期キックオフ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
6.11
アカデミックリンク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
6.12
最終成果発表会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
6.13
振り返り会 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
6.14
模擬開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
6.15
本開発 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
おわりに
81
第6章
第7章
謝辞
83
付録 A
新規習得技術
85
付録 B
活用した講義
87
参考文献
89
- iv -
Regional Design with ICT -Construction of Useful Systems for Customers-
第1章
はじめに
本章では，本プロジェクトの概要，背景，目的とその手段について説明を行う．
（※文責: 花田 洋貴）
1.1
本プロジェクトについて
本プロジェクトは，函館野外劇のチケット予約システムの構築と，函館市近郊のイベント検索
サービスを構築することで，ICT を用いて地域をデザインすることを目的として活動を行ってき
た．また本プロジェクトでは，これらのサービスの開発を本開発と定義して活動を行っている．
本プロジェクトでは，まずチームを 5 名ずつ，グループ A，グループ B，グループ C の 3 グルー
プに分けた．前期では，本開発を円滑に進めるため，あらかじめシステム開発の一連の工程を経験
する事を目的として，担当教員 3 名をそれぞれのグループの開発依頼者として先生と学生の面談予
約を支援するシステムの模擬開発演習を行った．また，模擬開発演習で分かれたグループを基に，
函館野外劇におけるチケット予約システムの構築を行うグループ A を野外劇班，函館市近郊で開
催されるイベント情報の検索サービスを構築するグループ B とグループ C をイベント班としてグ
ループ分けを行い，後期から本格的に本プロジェクトの目的を達成するためのサービスの構築を
行った．
（※文責: KIM SUN WOO）
1.2
本プロジェクトの背景
現在，多くの地域で ICT を用いた地域の活性化が注目されている．例えば長崎県の観光ポータ
ルサイト [1] である．インターネットの存在が以前にも増して重要な位置を占めるようになったた
め，サイトの大幅リニューアルを実施した．その内容としては，市町の観光担当者がスポットやイ
ベント情報等を随時更新できるようにし，タイムリーな情報を発信している．また県内の観光地を
リアルに伝えるため，歴史や自然などのテーマごとに制作した２分間の動画コンテンツ全８６作
品を配信などを行っている．この効果として，サイトへのアクセス状況が増加した．年間総ページ
ビューは前年から 36.2% 伸び，平均滞在時間は 1 分 9 秒伸びている．
現在，函館市ではインターネットを用いた情報発信が不十分である．例えば，東京の観光情報サ
イトトーキョーブックマーク [2] ではユーザが積極的にサイトを利用してイベントの情報を載せる
ことができるが，現在の函館市のイベント情報サイトは運営者がイベント関係者から連絡を受けて
サイトに直接イベント情報を載せている．それが原因で，函館近郊のいくつかのイベント情報の掲
載が漏れるということが発生した．そのため，函館市近郊で開催されるイベント活動を支援するこ
とで，地域が活性化する可能性がある．そこで，本プロジェクトでは長崎県の例のように ICT を
用いることで地域活動に貢献できるのではないかと考えた．
（※文責: KIM SUN WOO）
Group Report of 2013 SISP
-1-
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
1.3
本プロジェクトの目的と手段
これらのことから，本プロジェクトでは，お客様に使って頂けるようなシステムを構築するスキ
ルを学びながら，ICT を用いて，市民活動の活性化を目指すことを目的とした．また，この目的を
達成するための手段として函館野外劇のチケット予約システムの構築と函館市近郊のイベント検索
サービスの構築を行った．本グループでは，1 つ目の手段である函館野外劇のチケット予約システ
ムの構築に取り組んだ．さらに，目的達成のための技術習得として前期に模擬開発演習を行った．
（※文責: KIM SUN WOO）
Group Report of 2013 SISP
-2-
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
第2章
模擬開発
本開発をより効率よく行うために，模擬開発演習を行った．本章ではこの模擬開発について説明
する．
（※文責: 齋藤 尊）
2.1
概要
模擬開発を行うにあたり，プロジェクトメンバー 15 人を 3 つのグループに分けた．また，それぞ
れのプロジェクト担当教員にグループ毎の開発依頼者となってもらい，既存の面談予約管理システ
ムの機能拡張の依頼を受けた．開発においては，ウォーターフォールモデルを採用し，開発言語は
PHP を用い，また Web アプリケーションフレームワークとして CakePHP を利用した．加えて，
タスク等の管理に Redmine，その他環境として Eclipse，Subversion，LAMP(Linux，Apache，
MySQL，PHP) を用いた．また開発にあたって TA や担当教員，企業講師の方にアドバイスやレ
ビューをいただいた．
図 2.1
模擬開発グループ分け
（※文責: 齋藤 尊）
2.2
背景
本プロジェクトでは本開発において実際にお客様に使っていただけるシステムの構築を目指して
いる．システムの構築を行うには様々な知識，技術，経験が必要となる．例えば，システムの設計
Group Report of 2013 SISP
-3-
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersを行うためには，ユースケース図や業務フロー図といった UML の作成方法を知る必要がある．そ
して，実装を行うためには，使用する言語やバージョン管理についての知識や技術が必要となる．
また，開発を効率よく行うためには，どの工程でどのようなドキュメントを作成する必要があるか
や，チームで開発する際のマネジメント方法など実際の経験も必要とされる．
しかし，プロジェクト始動時のプロジェクトメンバーではお客様に使っていただけるシステムの
構築を行うための知識，技術，経験が不十分だと判断した．そのため，模擬開発によって，これら
を学習することとした．
（※文責: 花田 洋貴）
2.3
目的
模擬開発演習の目的はシステム開発の基本的な流れを経験し，本開発で活かせる知識や技術を身
につけることである．具体的には，ウォーターフォールモデルでの開発の流れを学習することであ
る．設計の段階ではユースケース図や業務フローといった UML の基本的な書き方を学ぶ．実装の
段階では PHP のフレームワークである CakePHP を用いた実装の技術を学ぶ．加えて，ドキュメ
ントやソースコードを管理するためバージョン管理の知識も身につける．これらの経験を活かし本
開発をより効率的に行えることを目指す．
（※文責: 花田 洋貴）
2.4
問題解決プロセス
面談情報管理システムという既存システムがある．面談予約管理システムは既存システムを基に
拡張を行った．開発は以下のようなプロセスで進めた．
1. 業務分析
既存システムの要求定義書，業務フロー図を基に既存システムの分析を行った．その結
果，既存のドキュメントを読み取ってそのシステムの全体像をつかむプロセスを学んだ．
2. 第 1 回ヒアリング
開発依頼者からのシステム開発依頼書を基に，システムの詳細を決定するためのヒアリン
グ要項を作成し，ヒアリングを行った．事前にヒアリング内容を策定してヒアリングがス
ムーズにできたことから，ヒアリング内容は必ず用意することを学んだ．
3. 要件定義，システム設計
ヒアリングの結果を基に，要件定義を行った．システムが有する機能とその挙動を規定す
るためにユースケース図とユースケース記述を作成した．その結果，システムを再構築する
ユースケース図を作成する場合は，新しく追加したユースケースと既存のユースケースとが
わかるような工夫が必要だと学んだ．これを基に，各画面間の遷移を決めるために画面遷移
図を作成し，同時に実際のユーザーの業務の流れを想定した業務フロー図を作成した．画面
遷移図の起点を左上にすればよいと学んだ．設計では，データベースを構築するためにデー
タベース・テーブル定義書と ER 図を作成した．その結果，システムで使用するデータを整
Group Report of 2013 SISP
-4-
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers理し，データベースを設計する能力が身についた．
4. 第 2 回ヒアリング
設計を基に開発依頼者へのヒアリングを再度行うため，要求定義書と画面モックアップを作
成し，ヒアリングを行った．ヒアリングで合意を取るためには画面モックアップを作成し，
開発する予定のシステムの姿を見せたほうがより効果的だと学んだ．
5. 実装
ヒアリングの結果を踏まえ，設計の一部見直しを行った．その後，必要となる関数やクラ
スファイルなど全ての命名規則を定めた命名記述を作成し，実装を行った．CakePHP の各
機能やヘルパーを使用する際の注意点について学ぶことができた．
（※文責: 安藤 大岳）
2.5
成果物
以下はグループ A で作成した成果物である．そのうち，ユースケース図を図 2.2 に示す．
• 用語集
• ヒアリング質問項目
• ユースケース図
• ユースケース記述
• 画面遷移図
• 業務フロー図
• データベース・テーブル定義書
• ER 図
• 要求定義書
• 画面モックアップ
• インデックス命名記述
• 面談予約管理システム
（※文責: 安藤 大岳）
Group Report of 2013 SISP
-5-
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
図 2.2
Group Report of 2013 SISP
グループ A ユースケース図
-6-
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
第 3 章 函館野外劇におけるチケット予約シス
テムの構築
この章では，本開発における背景や目的，問題解決プロセスなどを説明する．
（※文責: 齋藤 尊）
3.1
概要
野外劇の会からの依頼で，既存システムを基に新システムを構築することとなった．模擬開発に
続き A 班の 5 人が野外劇メンバーとして活動している．始めに既存システムの調査を行った．そ
の後，新システムの提案を経て要件定義を行った．この段階で野外劇の会の合意を得てから設計
を行い，実装へ進む．既存システムには Java Servlet が用いられていたが，本開発では，PHP の
Web アプリケーションフレームワークである CakePHP を用いることとする．本グループで開発
しているシステムは，システムを予約者が使いやすく, システム管理者にとって管理しやすいシス
テムを目指している．今後は実装が終了した後にテストを経て 3 月に納品する予定である．なお，
2014 年 1 月現在は要件定義が終了し，野外劇の会の合意を得た．
（※文責: 吉田 匡孝）
3.2
背景
函館野外劇は 1988 年の第 1 回上演以来，2013 年度で 26 回目を迎えた五稜郭公園で上演される
歴史劇である．出演者全員が自発的に参加するボランティアの函館市民で構成されており，延べ 1
万人の観客が集まる国内最大規模の野外劇である．
函館野外劇は毎年赤字が続き，2013 年度は 2,000 万円の赤字が生じていることがわかっている．
このことから，チケットの販売数を増やすことが最も重要な課題であると言える．
この課題を解決するため，2006 年からこの函館野外劇を運営する野外劇の会は未来大学と連携
し，予約システムを開発することなどで問題解決のための努力をしてきた．しかし，既存システム
について野外劇の会は公演日や販売するチケットの設定がシステム上でできない．や各公演日の予
約情報が分散していて探しにくい．といった使いづらさを感じていた．
そこで，既存システムをもっと使いやすいものにし，野外劇を広く認知させて多くの観客を集る
ため，2013 年度プロジェクト学習で野外劇の会から依頼を受けることになった．
（※文責: 吉田 匡孝）
Group Report of 2013 SISP
-7-
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
3.3
目的
本グループの目的は，既存システムを基にシステムを予約者が使いやすくし，またシステムを運
用している野外劇の会にも管理しやすい新システムを構築することである．加えて，新システムで
は函館野外劇を広く報せることができるような仕組みを実現する．
（※文責: 吉田 匡孝）
3.4
開発の進め方
本グループは，本開発を以下の手順にて行った．
• プロジェクトの設立
• 現状調査工程
• 提案工程
• 要件定義工程
プロジェクトの設立ではグループの基盤を築くために用語集やリスク管理表，プロジェクト計画
書を作成した．
現状調査工程では，既存システムを実際に利用した後，野外劇の会へヒアリングして問題点や要
望を伺った．問題点や要望を伺った後は，それらを基にして新システムに必要な機能の策定を行っ
た．
提案工程では，提案のためにシステム提案書やプロトタイプを作成した．
要件定義工程では，提案したシステムを基に実装すべき機能を明確にするため，ユースケース
図，画面遷移図，業務フロー図，ユースケース記述，非機能要件を作成した．更にこれらをまとめ
て要件定義書を作成した．この要件定義書を用いて再び野外劇の会へヒアリングを行い，新システ
ムの仕様について合意を得た．
また，今後は以下の手順でシステム開発を継続する．
• 設計工程
• 実装工程
• 試験工程
• 納品
設計工程では，ER 図，データ定義書，クラス図を作成し，シーケンス図，エラーメッセージ表
を作成する予定である．
実装工程では，システムのほかにコーディング規約の作成を予定している． 試験工程では，テ
スト計画書や納品物の一つである試験成績表の作成を予定している．
（※文責: 吉田 匡孝）
Group Report of 2013 SISP
-8-
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
3.5
開発体制
本グループの開発体制を図 3.1 で示す．依頼者である野外劇の会はグループメンバ全員と連携
して，要望や提案をやり取りする．グループの中ではメンバーはリーダーに進捗状況を報告する．
リーダーは各メンバー作業を指示し，メンバーの作業時に不確定な事項があれば，グループで話し
合って確定する．アドバイザは TA と未来大学の担当教員，企業講師で構成される．アドバイザは
グループからの報告を受けその報告に対してレビューなどのフィードバックをする．
図 3.1
開発体制
（※文責: 吉田 匡孝）
3.6
3.6.1
問題解決プロセス
プロジェクト設立
プロジェクトの開始時に，まずチームの基盤を築くことが必要だと感じ，メンバーの共通認識を
作るため，開発用語集を作成した．またどのようなリスクがあるかを洗い出しリスクを軽減，回避
するようリスク管理表を作成した．これらを基にプロジェクトの最終的な目標を定めたプロジェク
ト計画書を作成し，メンバー間での最終目標を固めた．
（※文責: 花田 洋貴）
3.6.2
現状調査工程
現状調査では，まず実際に既存システムを調査した．その後，野外劇の会に既存システムで困っ
ていることをヒアリングすることで問題点を洗い出した．次に，公演日やチケットの設定がシステ
Group Report of 2013 SISP
-9-
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersム上で行えないといった顕在化した問題に対してメンバー間で解決策を考え，新システムに必要な
機能の策定を行った．
（※文責: 花田 洋貴）
3.6.3
提案工程
提案工程では依頼元である野外劇の会へのシステム提案を行った．新システムの機能を決定した
後に，現段階で考えているシステムの概要について野外劇の会の方へ提案を行うため，システム提
案書を作成した．また，文書のみで説明すると野外劇の会の方にとってわかりづらい内容になって
しまうと判断したので，システムのプロトタイプを作成することで本グループが構築しようと考え
ているシステムを可視化し説明の際に役立てた．その結果，システム提案の際にいくつかの意見を
いただいたが，その意見を反映させることを条件にシステム提案の内容について合意を得ることが
出来た．以下にシステム提案の際に得られた意見を列挙する．
• 地図上の野外劇の会事務所の位置が現在の事務所の位置と異なるので修正してほしい．
• 路線バスと市電の最寄駅を掲載してほしい．
• サーバの設定時刻がずれているため予約を締め切るタイミングが早まっている状態を修正し
てほしい．
• 毎年，5 月 1 日から本格的にチケット予約を行っているためそれまでにシステムを完成して
ほしい．
（※文責: 花田 洋貴）
3.6.4
要件定義工程
要件定義工程では，システム提案の際にいただいた要求を基に実装するべき機能を明確にした．
またこの工程では最終的に本グループ側で策定した機能や性能について記載した要件定義書を用い
て，本グループが解釈した野外劇の会の方の要求が正しいか，また，本グループで提案した仕様が
野外劇の会の方の要求と合致しているかを確認するために実施した．
この工程ではまず，要求を基に，システム化する機能が具体的にいくつあるか分かりやすくする
ためにユースケース図を作成した．その後，ユースケース図の機能１つ１つが具体的にどのような
流れで行われているかを画面遷移図や業務フロー図，ユースケース記述を作成し詳細化した．これ
らの作業はメンバーの共通認識をつくり，同時に野外劇の会の方へ説明を行う際に利用するため
に行った．具体的な機能のほかにシステムが満たすべき性能や運用・保守の際に野外劇の会の方に
行っていただきたい内容については非機能要件として明文化した．
上記の図や文章等をまとめて要件定義書を作成し，野外劇の会の方に再びヒアリングを行った．
その結果，本グループが解釈していた野外劇の会の要求はほぼ正しいことがわかった．しかし，提
案する機能の中で修正してほしい点，更なる要求をいただいたので，そういった点を新システムに
反映させることを約束し，具体的なシステム設計に入ることとした．以下に野外劇の会からいただ
いた修正してほしい点を列挙する．
• チケット種別に変更を加えたとき，その変更を履歴として残せるようにしてほしい．
Group Report of 2013 SISP
- 10 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers• 管理トップページからの遷移方法をラジオボタンを用いたものに修正してほしい．
（※文責: 花田 洋貴）
設計工程
3.6.5
設計工程では，開発するシステムがどのようなものになるかを示すために，機能や操作手順など
についてまとめる．さらに，開発するシステムの構成や動作を明記する．データベース構造を固め
るために ER 図やデータ定義書，クラスの関連を表すためにクラス図を，オブジェクト間の関連
を動的に表すためにシーケンス図を作成する．現在，ER 図とデータ定義書が完成し，クラス図を
作成中である．クラス図が完成した後にシーケンス図を作成し，実装工程へと進んでいく予定で
ある．
（※文責: 花田 洋貴）
野外劇の会の業務
3.7
野外劇の会が函館野外劇の開催にあたって，既存システムを用いて行う業務の流れは以下の通り
である．
1. 公演日の設定
野外劇の会は，チケットの予約を始める前にその年度の公演日を既存システムに設定す
る．既存システムは公演日の設定機能を備えていないため，野外劇の会が未来大学に依頼し
て公演日を設定する．
2. チケット予約受付
チケット予約者がチケット予約を行い，既存システムはチケット予約者ごとに受付番号を
発行する．野外劇の会は，既存システムを用いてチケット予約情報を閲覧する．
3. チケット引き換え
野外劇の会は，公演日ごとに既存システムを用いてチケット予約情報を印刷する．印刷し
たチケット予約情報を野外劇会場に持ち込み，チケット予約者の持つ受付番号と照会を行
う．チケット予約者は，野外劇の会から提示された金額を支払いチケットを受け取る．
（※文責: 安藤 大岳）
3.8
新システム
3.8.1
概要
新システムは，大きく分けて 2 つの目的で使用する．1 つ目は，システム利用者が函館野外劇の
チケット予約手続きと公演情報等の確認を行うことである．2 つ目は，システム管理者が函館野外
劇に関する公演情報や予約情報の管理とソーシャルメディアを用いて函館野外劇の PR を行うこと
である．
以上を踏まえたうえで，新システムは既存システムの機能を踏襲しながら拡張し，以下の機能を
備える．
Group Report of 2013 SISP
- 11 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers• チケット予約に関する機能
• 予約情報の確認に関する機能
• メール送信に関する機能
• システム自動処理に関する機能
新システムでは新しく以下の機能を追加した．
• 管理ページへのログインに関する機能
• 公演日情報の設定に関する機能
• チケットの設定に関する機能
• Twitter,Facebook との連携に関する機能
• バックアップ機能
（※文責: 安藤 大岳）
3.8.2
機能詳細
以下に新システムの機能の詳細を記述する．この機能詳細で使われるチケット種別とという用語
は，チケット名，販売価格，割引額，対象人数といったチケットの種類を定義する情報である．
• チケット予約に関する機能
チケットの予約
チケット予約者は氏名・フリガナ・メールアドレスを入力し，予約する公演日・予約する
チケット種別とその枚数を選択することで，函館野外劇のチケットの予約ができる．予約が
完了すると，各予約ごとに受付番号が発行される．ただし，本システム上ではチケットの決
済は行わない．
チケットの予約確認
予約時に発行された受付番号と氏名またはメールアドレスを入力することで，既に登録さ
れたチケット予約の予約者氏名や予約した公演日などの予約情報を確認することができる．
チケットの予約変更
チケットの予約確認を行った時，そのチケット予約の予約内容を変更することができる．
この機能では，氏名・フリガナ・メールアドレス・予約する公演日・予約するチケット種別
とその枚数を変更することができる．
チケットの予約キャンセル
予約時に発行された受付番号と氏名またはメールアドレスを入力することで，既に登録さ
れたチケット予約のキャンセルを行うことができる．
Group Report of 2013 SISP
- 12 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
受付番号の確認
受付番号を忘れてしまった際，予約した公演日とメールアドレスを入力することで，対象
となる予約の受付番号確認用メールを受け取ることができる．
アクセスマップの確認
野外劇会場や野外劇の会事務所などの場所を地図から確認できる．また，各場所名のリン
クを選択することで，選択されたポイントの詳細情報が確認できる．
• 予約情報の確認に関する機能
全公演日の予約状況の確認
管理者 TOP ページから直接，全公演日の予約数などを閲覧することができる．
公演日別チケット予約状況詳細確認
特定の公演日に対応する詳細ボタンを押すことで，その公演日の予約者名などの予約の詳
細が確認できる．
過去の予約情報の確認
過去の予約者数を調べる場合などは，過去の予約情報のリンクから，指定した年度の予約
者数などの予約状況を確認することができる．
予約情報の印刷
予約者表を作成する際には，各公演日の詳細画面からその公演日の予約者リストの印刷を
行うことができる．
• メール送信に関する機能
メール作成
各公演日ごとに，チケット予約者へのお知らせ用メールを作成・送信することができる．
メールの作成の際には，メールのタイトルと本文を入力する必要がある．
メールテンプレートの設定
本システムで送信できる各メールのうち，選択されたもメールのタイトルや本文を設定す
ることができる．この機能により，本システムが自動的に送信するメールのタイトルや本文
を編集出来る．
Group Report of 2013 SISP
- 13 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
メール差出人の設定
管理者のメールアドレスを入力することで，入力したメールアドレスを本システムで送信
できる各メールの差出人アドレスに設定することができる．この機能で設定したメールアド
レスはシステムで送信できる全メールに反映される．
• システム自動処理に関する機能
年度初めの予約受付開始
毎年 5 月 1 日午前 0 時に自動的にチケット予約の受付を開始する．
年度ごとの受付終了
毎年 9 月 1 日午前 0 時に自動的にチケット予約の受付を終了する．
公演日ごとの受付終了
各公演日当日の午前 12 時に，自動的にその公演日のチケット予約の受付を終了する．
リマインダーメールの送信
チケット予約者に，予約した公演日の前日午後 5 時に公演日を知らせるメールを送信す
る．
• 管理ページへのログインに関する機能
管理者のログイン
管理者メールアドレスとパスワードを入力することで，管理者 TOP ページや各管理者用
機能にアクセスすることができる．
管理者のログアウト
ログアウトのリンクを選択することで，管理者 TOP ページや各管理者用機能からログア
ウトすることができる．
管理者パスワードの変更
変更前のパスワード・変更後のパスワード・確認用の変更後のパスワードを入力すること
で，ログイン機能で利用するパスワードを変更することができる．
• 公演日の設定に関する機能
Group Report of 2013 SISP
- 14 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
公演日の設定
公演日に指定されていない日付をカレンダーから選択することで，その日付を公演日とし
て本システムに登録することができる．
公演日の設定削除
公演日に指定されている日付をカレンダーから選択することで，その日付の公演日設定を
削除できる．ただし，削除するとき既に該当公演日に予約が登録されていた場合，該当公演
日の予約者へ連絡用のメールを送信した後に公演日を削除する．
手動での予約受付の開始
手動で本システムのチケット予約の受付を開始することができる．ただし，この機能はチ
ケット予約の受付開始日を前倒しするためのもののため，各年度の 1 月 1 日午前 0 時から 5
月 1 日午前 0 時までの間までしかこの機能は利用することができない．
手動での予約受付の終了
手動で本システムのチケット予約の受付を終了することができる．ただし，この機能は
誤って予約受付の開始をしてしまった際に修正するためのもののため，各年度の 1 月 1 日午
前 0 時から 5 月 1 日午前 0 時までの間までしかこの機能は利用することができない．
• チケットの設定に関する機能
チケット価格設定
価格設定欄にチケット価格を入力することで，対応するチケット種別のチケット価格を設
定することができる．
チケット種別追加
チケット名・チケット価格・割引額・対象人数を入力することで，予約が可能なチケット
種別を新しく追加することができる．ただし，この機能はチケットの予約受付が開始状態の
ときは使用することができない．
チケット種別変更
既に登録されている各チケット種別のチケット名・チケット価格・割引額・対象人数を変
更することができる．ただし，この機能はチケットの予約受付が開始状態のときは使用する
ことができない．
Group Report of 2013 SISP
- 15 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
チケット種別削除
指定したチケット種別を削除し，そのチケットで予約することができないようにする．た
だし，この機能はチケットの予約受付が開始状態のときは使用することができない．
チケットマスタの履歴
毎年 9 月 1 日に，その年の確定版のチケットマスタの設定 (チケット名・チケット価格・
割引額・対象人数) を年度ごとに保存する．
• Twitter,Facebook との連携に関する機能
Twitter，Facebook への一括投稿
野外劇の PR 機能として，入力した文章を Twitter，Facebook へのメッセージとして一
括投稿を行うことができる．その際利用する Twitter，Facebook のアカウントは Twitter，
Facebook アカウントの設定機能から設定をする．
Twitter，Facebook アカウントの設定
管理者の Twitter，Facebook アカウントをシステムに登録することで Twitter，Facebook
への一括投稿機能で利用する Twitter，Facebook アカウントをシステムに設定できる．
• バックアップ機能
データのバックアップ
現在の予約情報・過去の予約情報・チケットマスタ情報・公演日情報・管理者情報をまと
めて SQL 形式でバックアップを取ることができる．
（※文責: 齋藤 尊）
3.8.3
運用体制
新システムは，未来大学から切り離して運用する．そのため，野外劇の会へレンタルサーバの契
約と，本グループで定めた非機能要件に従った運用を依頼した．サーバの移行に関しては，新シス
テムを野外劇の会が契約したレンタルサーバにセットアップして引き渡すことで実現する．
（※文責: 安藤 大岳）
Group Report of 2013 SISP
- 16 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
3.9
成果物一覧
WBS
WBS とは，プロジェクト全体で行わければならない作業をすべて洗い出し，細かく分割したも
のである．前期の活動の反省として，スケジュールが曖昧で現在何をするべきなのか，今後どう
いったことを行うのかが明確に示されていなかったり，１つの作業にどれだけの時間がかかるのか
見積が十分にできなかったという点が挙げられる．その結果，行うべきであった作業を行わず次の
工程に進んでしまったことや，１つの作業に予想以上に時間がかかってしまうといった問題が生じ
た．後期ではこのような失敗を繰り返さないために WBS を作成した．WBS を作成することで本
プロジェクト全体としてどのような作業が必要なのか見通しがつきやすくなり，洗い出した作業か
ら具体的にどのような活動を行えば良いのかという見積をうまく行うことが出来た．しかし，活動
を進めていく中で，成果物の整合性を確認する作業や，レビューでの指摘内容を修正する作業が新
たに必要だと明らかになった．そのような作業が WBS に追加されることや見積が完全にできてお
らず作業に遅れが出ることがいくつかあった．このことについては WBS 作成者や確認を行ったメ
ンバーのプロジェクト経験が浅く，タスクの洗い出し，見積が確実なものにならなかったことが理
由だと感じている．今回のプロジェクトではスケジュールを立て直すことで対策としたが，今後新
しいプロジェクトで WBS を作成するときは今回洗い出しきれなかったり見積りきれなかった作
業をはじめから考慮に入れて WBS を作成したい．後期に本グループが作成した WBS を図 3.2 に
示す．
図 3.2 WBS
（※文責: 花田 洋貴）
リスク管理表
リスク管理表は，プロジェクト遂行における事故や遅延などを未然に防ぐために，プロジェクト
が潜在的に抱えるリスク要因を洗い出し，その影響度や優先度の検討及び対策を行うために作成す
Group Report of 2013 SISP
- 17 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersるものである．例えば，メンバー間で意見が対立し、話が進まなくなるリスクという項目をあげて
それで発生する問題点としてスケジュールの遅れをあげた．また，その代替・軽減案としてそれぞ
れが納得できる妥協点を探る等の項目を決めた．本グループにおいても潜在するリスクとして，メ
ンバー間の連携欠如やマスタスケジュールの遅延，外部サーバの停止といった点を挙げて有事に備
えるものとして利用した．本グループが本開発の際に作成したリスク管理表を図 3.3 に示す．
図 3.3
リスク管理表
（※文責: 安藤 大岳）
プロトタイプ
プロトタイプは，メンバー間でのシステムのフローやイメージの共有と，野外劇の会の方へシス
テムの提案を円滑に行うために作成された．また，本グループでは野外劇の会の方から具体的な要
求を引き出すのに有用であり，要件定義においても利用され，設計の足がかりにもなった．
プロトタイプは，実装時と同じプラットフォームを用いてメンバーの PC のローカル環境で作成
された．実装においては，各画面の遷移，フォームやデータベースからの情報取得等，最低限の実
現に留めた．また，要件定義の段階でプロトタイプを拡張し，新たに追加することになった機能へ
の対応を行った．プロトタイプの画面例を図 3.4 及び図 3.5 に示す．なお，図 3.4 はチケット予約
のフォーム画面，3.5 は管理 TOP ページである．
図 3.4 プロトタイプ画面例 1
Group Report of 2013 SISP
- 18 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
図 3.5
プロトタイプ画面例 2
（※文責: 安藤 大岳）
プロジェクト計画書
プロジェクト計画書は, プロジェクトを進行させる上で考慮しなければいけない事項を，プロ
ジェクトの目的，現状の問題点と要望，改善策の提案，システム概要，システム化対象範囲の説明，
制約の説明，リスク管理の概要，開発体制の説明，開発環境，スケジュールといった項目でまとめ
た文書である．この文書はこの先どのようにプロジェクトを進行させるかの予定を定めるだけでは
なく，プロジェクト進行中に目的がすり替わってしまわないように，またプロジェクトで扱う業務
の範囲が思わぬところで拡大しないようにするための重要な文書である．そのため，この文書はシ
ステムの開発を始める前に作成する必要がある．
プロジェクトの目的では本グループが活動する目的を説明する．現状の問題点と要望では本グ
ループで解決すべき事項を説明する．改善策の提案では，解決すべき事項に対して本グループがど
のような提案をしたのかを説明する．システム概要では，解決すべき事項を解決するために本グ
ループで提案したシステムについてを説明する．システム化対象範囲の説明では，本グループで提
案したシステムが扱う業務の範囲と，扱わない業務の範囲についてを説明する．制約の説明では，
本グループを進行させるうえでの制限事項についてを説明する．リスク管理の概要では，本グルー
プを進行させるうえで発生するリスクとその対策についてを説明する．開発体制の説明では，本グ
ループを進行させるうえでのプロジェクトメンバーやステークホルダーについて図を用いて説明
する．開発環境では，本グループを進行させるうえで開発に使用する環境や動作検証を実施する環
境についてを説明する．最後にスケジュールではシステムの提案から要件定義，設計，実装，テス
ト，マニュアル作成，試験運用，納品までのスケジュールを図で説明する．
（※文責: 吉田 匡孝）
システム提案書
システム提案書は，プロジェクトを進める際に野外劇の会と合意を得るために，システム提案の
背景，現状の問題点と要望，解決へ向けた提案，システムの特徴，提案したシステムの概要，提案
Group Report of 2013 SISP
- 19 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersしたシステムの構成や機能一覧，システムを開発するにあたっての開発体制，システムをどのよう
に納品するか，システムを開発するスケジュールを盛り込んだ文書である．この文書を用いて野外
劇の会へプロジェクトの内容や開発するシステムの説明をするので，わかりやすい内容にするため
に詳細なサーバ構成や動作検証時の詳細な環境を記さないようにした．
本グループが作成したシステム提案書は以下の内容を盛り込んだ．
• システム提案の背景
• 現状の課題点と要望
• 解決へ向けた提案
• システムの特徴
• システム構成
• 機能一覧
• 開発体制
• 納品物一覧
• 開発スケジュール
基本的にプロジェクト計画書の内容を野外劇の会へわかりやすく説明するように作成した．機能
一覧にて本グループで開発するシステムの中で既存のシステムには無い新機能を含めて説明した．
納品物の一覧や開発スケジュールでシステムをどのように納品するかについて説明した．
（※文責: 吉田 匡孝）
要件定義書
要件定義書は，システムの提案や要件定義の工程を実施した結果，最終的に要件を定義し野外劇
の会と合意を得るために作成された文書である．
本グループでは，以下の内容を要件定義書に盛り込んだ．
• 要件定義書の位置づけ
• システム再構築の目的
• システム概要
• 機能要件・機能一覧
・機能詳細
• 非機能要件・提案レンタルサーバサービス
・非機能要件一覧
・障害時対応詳細
サーバの提案ではシステムを動作させるレンタルサーバを決定し，その詳細についてはレンタル
サーバのカタログを添付資料として用いて説明した．
機能一覧では，システム提案書で説明した内容とは違い，機能をユースケース図と対応させ，優
先度を設定した．また，各機能について，必要なデータや操作などの詳細な説明を追加した．非機
能要件では，システムを動作させるサーバについてサーバのプランや契約料金などを説明し，非機
能要件を可用性，性能・拡張性，運用・保守性，移行性，セキュリティについて説明した．障害時
Group Report of 2013 SISP
- 20 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersにおける対応について，保守契約の期間や対応の流れについてを説明した．
（※文責: 吉田 匡孝）
非機能要件
非機能要件は，製品品質に関して使いやすさや性能，信頼性，拡張性，運用性，セキュリティ等
に関する取り決めを顧客と同意するために作成するものである．非機能要件では，IPA の定める項
目サマリ [3] をもとに運用サーバの移行や運用後のサポート体制関しての取り決めを中心に作成し
た．また，障害発生時の対応方法やセキュリティの方針についても策定した．本グループが作成し
た非機能要件を図 3.6 に示す．
（※文責: 安藤 大岳）
図 3.6 非機能要件
Group Report of 2013 SISP
- 21 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
ユースケース図
ユースケース図とは UML の一種で，開発するシステムがどういった機能を有するのかを一覧で
表現することが可能な図である．今回は野外劇の会の方と話し合いを行う中で，本グループが想定
しているシステムの機能が野外劇の会の方と相違がないか確認するために用いた．また，どういっ
たシステムを構築するかチーム内で共通認識を作るために作成した．以下に本グループが想定し
た機能の一覧を列挙する．また，本グループが本開発において作成したユースケース図を図 3.7 に
示す．
• チケットの予約
• チケットの予約確認
• チケットの予約変更
• チケットの予約キャンセル
• 受付番号の確認
• アクセスマップの確認
• 全公演日の予約状況の確認
• 公演日別チケット予約状況詳細確認
• 過去の予約情報の確認
• 予約情報の印刷
• メール作成
• メールテンプレートの設定
• メール差出人の設定
• 年度初めの予約受付開始
• 年度ごとの受付終了
• リマインダーメールの送信
• 管理者のログイン
• 管理者のログアウト
• 管理者パスワードの変更
• 公演日の設定
• 公演日の設定削除
• 手動での予約受付の開始
• 手動での予約受付の終了
• チケット価格設定
• チケット種別追加
• チケット種別変更
• チケット種別削除
• チケットマスタの履歴
• Twitter，Facebook への一括投稿
• Twitter，Facebook アカウントの設定
• データのバックアップ
（※文責: 花田 洋貴）
Group Report of 2013 SISP
- 22 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
図 3.7 ユースケース図
ユースケース記述
ユースケース記述とは，利用者が目的を達成するために，システムがどのような振る舞いをする
べきなのかを記述した文書である．本グループでは，要件定義書の機能詳細や付録として，また利
用者とシステムがどのようなやり取りを行うのかを明文化するため，ユースケース記述を作成し
た．ユースケース記述は本システムの機能ごとに 1 つずつ作成した．ユースケース記述では，本シ
ステムの各機能ごとに利用者・利用の目的・目的達成のため標準的な流れ・例外が発生した際の流
れ・ユースケースの実行前後の状態を記述した．ユースケース記述はユースケース図や画面遷移図
と整合性が取れるように作成し，業務フロー図の作成に役立てた．ユースケース記述の具体例を図
3.8 に示す．図 3.8 はチケットの予約を行う際のユースケース記述である．
（※文責: 齋藤 尊）
Group Report of 2013 SISP
- 23 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
図 3.8
ユースケース記述例
画面遷移図
画面遷移図は，開発するシステムにおいて，どのような条件でどのような操作をしたときにどの
画面を表示するのかを網羅的に表した図である．画面遷移図の例を図 3.9 で示す．システムで使用
する画面を網羅的に表しているため，実装段階でどの画面を用意すればよいのかがわかる．また，
野外劇の会がシステムでどの画面を使うのかが理解できる図である．本グループでは，チケット予
約システム管理者ページとチケット予約ページに分けて画面遷移図を 2 つ作成した．
図 3.9
チケット予約ページの画面遷移図
（※文責: 吉田 匡孝）
業務フロー図
業務フロー図は，ユーザがシステムを使って業務を進める手順を図にしたものである．例として
本グループが作成した業務フロー図を図 3.10 で示す．この図では業務にシステムを用いる際，ど
のように用いられるのかがわかる．業務は図の黒丸から開始し，矢印の通り下へ向かって進行す
る．途中条件によって分岐する場合がある．図は縦にユーザー、システム、データベースと別れて
いるが，それぞれの領域に入っている業務を担当する．本グループで業務フロー図はシステム画面
遷移の確認や業務の流れで分岐点を洗い出す事ができて，ER 図やクラス図等のシステム設計図作
Group Report of 2013 SISP
- 24 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers成に役立てた． 図 3.10
チケット予約時の業務フロー図
（※文責: 吉田 匡孝）
Group Report of 2013 SISP
- 25 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
ER 図
ER 図は，データを実体，属性，関連で図に表すためのものである．今回は，データ構造の設計
とチーム内での設計資料としてプロトタイプを足がかりに ER 図を作成した．また，構造の妥当性
の確認や処理量の考慮を行うためにも役立てた．本グループが作成した ER 図を図 3.11 に示す．
この図は新システムで用いるデータの実体や関連を示している．
図 3.11
ER 図
（※文責: 安藤 大岳）
クラス図
クラス図は，UML の一種で，システムを構成するクラスとそれらの関係を表したものである．
今回は，MVC を考慮したシステムの構成設計とチーム内での設計資料としてプロトタイプを足が
かりにクラス図を作成した．
本グループが作成したクラス図を図 3.12 に示す．この図は新システムに含まれる全てのクラス
を表している．
（※文責: 安藤 大岳）
Group Report of 2013 SISP
- 26 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
図 3.12 クラス図
Group Report of 2013 SISP
- 27 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
3.10
今後の予定
今後は 3 月中旬の納品に向けて，1 月に実装を行い 2 月に試験とマニュアル作成を行う．実装の
際にはコーディング規約を作成し，その規約をもとにプログラミングを行う．試験の際にはテスト
計画書を作成し，計画書に則ってテストを実施する．テスト結果は試験成績表として記録する．納
品の際に野外劇の会へ提出するものとして，新システム，テスト計画表，試験成績表，エラーメッ
セージ表，システムマニュアルを想定している．また，要件定義の際にサーバの保守管理等につい
て，株式会社エスイーシーと合意をいただくことができなかったため，後日，打ち合わせしなけれ
ばならない．
（※文責: 齋藤 尊）
Group Report of 2013 SISP
- 28 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
第4章
スケジュール
この章では，本グループ全体・模擬開発・本開発におけるスケジュールについて説明する．
（※文責: 齋藤 尊）
4.1
全体
模擬開発，本開発のグループに分かれずに行ったプロジェクト全体での活動のスケジュールを以
下に列挙する．
• 5月
・プロジェクト発足
・プロジェクトリーダー決定
・グループ分け決定
・グループリーダー決定
・Subversion 勉強会
・方針決定
・合同キックオフ
・懇親会
・CakePHP 勉強会
・Redmine の使い方確認
・日本語運用ミニ講座
• 6月
・中間発表準備開始
・発表スライド作成
・発表ポスター作成
・発表練習
• 7月
・プロジェクト担当教員・TA からの発表レビュー
・企業講師からの発表スライドレビュー
・中間報告書着手
・中間発表会
・中間発表反省
・中間報告書提出
• 8月
・オープンキャンパス出展
Group Report of 2013 SISP
- 29 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers・自主学習
• 9月
・自主学習
・後期プロジェクト開始
• 10 月
・アカデミックリンク出展準備
• 11 月
・アカデミックリンク出展
・成果発表会準備開始
・発表スライド作成
・発表ポスター作成
• 12 月
・成果発表会
・後期振り返り会
・最終報告書着手
• 1月
・最終報告書提出
・打ち上げ
• 2月
・課外成果発表会
（※文責: KIM SUN WOO）
4.2
模擬開発
模擬開発の活動のスケジュールを以下に列挙する．
• 5月
・模擬開発開始
・開始時説明
・依頼書・元システムのソース配布
・サーバの説明・設定
・システム開発依頼書・既存システムの要件定義書の確認
・システム開発依頼者へのヒアリング
• 6月
Group Report of 2013 SISP
- 30 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers・要件定義
・要件定義書作成
・設計
・ユースケース図作成
・業務フロー図作成
・ユースケース記述作成
・ER 図作成
・テレビ会議での企業講師レビュー
・実装開始
・企業講師レビュー
• 7月
・中間発表会
・テストに関するミニ講義
・テスト
・中間報告書提出
• 8月
・オープンキャンパス出展
・システム納品
・模擬開発終了
（※文責: KIM SUN WOO）
本開発
4.3
野外劇班の活動のスケジュールを以下に列挙する．12 月までは実績，1 月以降は予定を列挙
する．
• 5月
・函館野外劇の現状調査
・現状の予約システム調査
・問題点洗い出し
・提案する項目検討
・「函館野外劇」の会へのヒアリング
• 6月
・ヒアリング結果まとめ
・今後の方針検討
• 7月
・中間発表会
Group Report of 2013 SISP
- 31 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers・今後の方針検討
・中間報告書提出
• 8月
・オープンキャンパス出展
・開発用語集作成
・リスク管理表作成
・プロジェクト計画書作成
・システム提案書作成
• 9月
・プロジェクト計画書作成
・システム提案書作成
• 10 月
・プロジェクト計画書作成
・システム提案書作成
・システムのプロトタイプ作成
• 11 月
・システム提案
・アカデミックリンク出展
・要件定義書作成
• 12 月
・システム設計
・依頼者へのヒアリング
・成果発表会
• 1月
・システム設計
・実装
・最終報告書提出
• 2月
・実装
・テスト
・試験運用
• 3月
・試験運用
・システム修正
Group Report of 2013 SISP
- 32 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers・本運用
（※文責: KIM SUN WOO）
Group Report of 2013 SISP
- 33 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
第5章
個人の活動
この章では，メンバー各個人が本プロジェクトで行った活動とそこで得た学びを説明する．
（※文責: 齋藤 尊）
5.1
花田 洋貴
• プロジェクト概要説明
5 月初旬に私は本プロジェクトに参加することを決意した．第１回目の時間には伊藤先生
により本プロジェクトの概要を説明していただき，更に企業講師の方にプロジェクト活動で
必要な技術についてお話いただいた．
• 体制決定
まず，自己紹介と共にプロジェクトのリーダーを話し合い，決定した．リーダーを中心に
野外劇班とイベント班のメンバーを決定することになった．その結果，私は野外劇班として
活動することが決定した．その後グループリーダーを決める話し合いがあったので，リー
ダーになることを希望し，それが確定した．
• 前期プロジェクトキックオフ
貢献したい内容の説明
私が本プロジェクトで貢献できる内容について本プロジェクト全体に説明を行った，私は
PHP の Web アプリケーションフレームワークである CakePHP による開発に携わったこ
とがあったので，CakePHP でのプログラミングで貢献したいという旨と，リーダーとして
チームをまとめることで貢献したいという話を行った．
アイスブレイク
アイスブレイクとして制限時間内にペーパータワーをどれだけ高くすることができるかを
模擬開発のグループごとに競った．結果，私のグループは３つのグループの中で最下位に
なってしまった．このペーパータワーはプロジェクトの縮図で，リーダーのファシリテー
ション能力やメンバーの協調性などが必要であったとアイスブレイクの後に説明があった．
私はプロジェクトに必要な能力がまだ全く持てていないことを再確認し，これから身につけ
るべき技術，能力について多くの課題があると感じた．
• バージョン管理についての説明会
Subversion について TA からお話があり，バージョン管理を用いたシステム開発の手法
について学ぶことが出来た．Subversion を用いたバージョン管理についてはかつて経験が
Group Report of 2013 SISP
- 35 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersあったので，インストール方法等をメンバーに教えることができた．
• CakePHP 勉強会
本プロジェクト全体で CakePHP の勉強会が行われた．全４回の講義の中でシステム
を開発するための環境を整えるところから始まり，最終的には Model，View，Controller
の関連を理解し，簡単なシステムを開発することが可能なレベルに達することができた．
CakePHP でのプログラミングでチームに貢献したいと意気込んでいたが，忘れていた内容
もあり，思い出しながらの活動になってしまった．しかし，演習を通した講義の中で行き詰
まっているメンバーにアドバイスを積極的に行った．その結果，メンバーから感謝されると
ともに自分自身の理解を深めることが出来た．
• 模擬開発
模擬開発の概要について伊藤先生から説明があり，私が参加しているグループ A は，奥
野先生を依頼者とする面談予約システムの開発を行うことが決定した．
現状分析のためのヒアリング
依頼者である奥野先生がどのようなシステムを求めているかをヒアリングで聞き出し，そ
の内容についてメンバーで話し合いどのようなシステムを作成するかを決めた．
ユースケース図作成
私は依頼者と本グループのメンバーで話し合ったシステムの機能をユースケース図にする
作業を行った．ユースケース図の作成方法を書籍などで確認することで，深く知識を得るこ
とができた．
TV 会議による企業講師レビュー
業務フロー図が完成した段階で企業講師による TV 会議が行われた．私は企業講師の方
へ現状の報告とこれからの展望を説明した．その結果，画面遷移図において他のグループよ
りよくできているという感想をいただくことができた．さらに，成果物間の整合性の取り方
についてアドバイスをいただくことができた．
メンバーの担当割り振り
各メンバーに担当を割り振り，ユースケース記述，業務フロー図をメンバーと協力しなが
ら作成した．また，ユースケース図，業務フロー図を作成している間に作業が割り振られて
いないメンバーに画面遷移図を担当させるという割り振りを行った．TV 会議の次の演習か
らは ER 図，テーブル定義書の作成のために担当を割り振りを私は行った．
Group Report of 2013 SISP
- 36 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
画面モックアップの作成
文書のみでは依頼者にシステムの説明が難しいと考え，画面のモックアップの作成を行っ
た．その際私はリーダーとして話し合いをまとめる役目をつとめていたが，メンバー同士の
意見が対立した時にどちらの意見を採用するか非常に悩んだ．TA に相談したところチーム
として何を１番優先するべきと考えているかで採用するべき意見は変わるのではないかと
いった指摘をいただいた．その後から会議の話し合いごとに何が 1 番重要なのかに注意をは
らうようになった．
要件確定のためのヒアリング
最終的なシステムの仕様に合意を得るためにもう一度依頼者にヒアリングを行った．私が
システムについての説明をおこなった結果，システムで実現する機能の優先度を考えること
が必要であると指摘があった．前途の指摘については，時間があればこのレベルまで，時間
がなければ最低限このレベルまで完成させるといった内容をを約束することでシステムの仕
様を決めることができた．その後，合意を得ることができたので実装を開始した．
実装
システム実装については演習時間外に行わないといけないことが多かった．しかし，メン
バーの授業時間の関係で演習時間外に集まることが難しいという状況が発生した．その結果
プログラミング技術で分からないことが分からないままになってしまっているといった問題
が発生した．そういった問題を以後，発生させないために，それ以降はわからないことが
あったら早めに相談することを私は義務付けた．結果スケジュールに遅れはあったが，無事
システムを完成させるところまでこぎつけることができた．
納品会
私は諸事情で参加できなかったが模擬開発で完成したシステムの納品会があった．メン
バーが私の代わりにグループ A が構築したシステムについて説明したが，あまりうまく説
明できていなかったと後ほど話を聞いた．理由は私が納品会のための準備をうまく指示でき
ていなかったためである．このことから準備の重要性とリーダー及びメンバーがイベントに
参加できなかった時の対策は綿密に行わないとうまくいかないことを学んだ．
中間発表会準備の担当割り振り
模擬開発での活動とは別に７月の中間発表会に向けてスライドとポスターを作成しなけれ
ばならなかったので誰をどういった担当にするかを私が中心となり話し合い，実際に作成し
始めた．私は特に担当を持たず，スライドのレビューに参加したり，ポスターの説明方法に
ついてアドバイスを行うような全体のサポートにまわることで作成に貢献した．
Group Report of 2013 SISP
- 37 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
中間発表会用スライド・ポスターのレビュー
スライドとポスターのレビューでは，先生や TA，企業講師の方からご指摘をいただくこ
とが多々あり，修正は連日深夜まで及んだが，メンバー全員でもっと良いものを作りたいと
努力した．私はスライドのレビューなどを行ったり，発表方法のアドバイスを行った．
中間発表会
メンバーの努力の結果，7 月 12 日の中間発表会当日に企業講師の方に発表内容が素晴ら
しかったとコメントしていただくことができた．さらに発表アンケートでもよく頑張ってい
るといった意見が多く見受けられた．私はメンバーと努力することで，必ず良い結果は得ら
れるのだとを感じた．
• 中間報告書の作成
前期の活動についてまとめるため，中間報告書の作成を行なった．私は中間報告書の目次
を考え，担当を割り振りした後に自分の担当の作成をし，無事完成することができた．
• 本開発
本開発のための現状調査
本開発のための現状調査として 5 月の段階で現在運用されているシステムを利用し，問題
点を洗い出した．また，伊藤先生からステークホルダーについての説明や業務上の問題点な
どを教えていただき現状の理解を深めることができた．
第１回ヒアリング
野外劇の会の方へ要望を聞き出すために 5 月下旬にヒアリングを実施し，貴重な意見を
いただくことができた．私はリーダーとしてチームをまとめようとしたが，会議時にうまく
ファシリテートできず，ヒアリング時に役割分担が曖昧で進行が滞ってしまう状況があっ
た．この反省から，ヒアリング時の役割決めをきちんとすること，そのためのルールを定め
た．
WBS 作成
後期の本開発のスケジュールを正確に立てるため 8 月上旬に，WBS を作成した．前期に
全体のスケジュールを曖昧にしてしまったことで時間の見積もり等がうまくいかなかったと
いう失敗を踏まえて，工程ごとに必要な作業内容をあらかじめすべて洗い出した．その後，
その作業を達成するために必要な活動を最小の単位に分けた．最小の単位に分けることでそ
の活動にどれだけ時間がかかるか見積が立てやすく，ボトムアップの要領でスケジュール全
体の時間見積を済ませた．また，WBS を基に活動を行うことをメンバー全員に了承を得た．
Group Report of 2013 SISP
- 38 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
開発用語集・リスク管理表作成
8 月下旬に開発用語集とリスク管理表をメンバーと相談しながら作成した．これらを作成
することで用語の意味の捉えかたやリスクが起きてしまった時の対策をグループ内で共通認
識として統一することができた．
プロジェクト計画書の作成
本グループとしての目的を明確にするために作成するプロジェクト計画書の目次，目的を
考え，制約の明確化を行った．夏休みだったこともあり，あまり活発に活動を行うことがで
きなかった．しかし Skype 等を用いて遠隔会議を行うなど対策を行うことでメンバーの進
捗を把握することができていたことは良い点だったと感じる．
後期プロジェクトキックオフ
後期の早い段階で１度企業講師の方が本プロジェクトの進捗を確認するために未来大にい
らっしゃる機会があり，プロジェクト計画書のスコープについてアドバイスをしていただい
た．その他，会議の進行についてもアドバイスをいただき，私はファシリテーションの技術
について教えていただくとともに参考書籍を貸していただいた．また，野外劇の会の方へ本
プロジェクトが考えているシステムを提案するため，システム提案書の作成にも手をつけ
た．
システム提案書の作成
10 月上旬にはシステム提案書を用いて提案を行うための準備としてヒアリングシートを
作成した．また，システム提案書のみでの説明は難しいと考え，新しく提案するシステムの
プロトタイプの実装を安藤に任命した．
第 2 回ヒアリング
新システム提案を行うために２回目のヒアリングを行なった．プロトタイプを重点的に説
明することで，野外劇の会の方がシステムの内容について理解しやすくなり，話し合いを活
発にすることができた．さらに，あらかじめヒアリングシートを作成していたことで質問し
なければならない項目が整理されており，スムーズに質問とその回答を受け答えすることが
できた．
ユースケース図の作成
ヒアリング時にいただいた新システムの機能についての意見を反映させたユースケース図
を私が作成した．新システムとして考えられる機能は多かったが，前期に作成したことでス
ムーズに作成することができた．
Group Report of 2013 SISP
- 39 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
各担当割り振り
ユースケース図を作成すると同時に非機能要件ついても他のメンバーに作成するように担
当を割り振った．ユースケース図が完成した後，それを基に業務フロー図，ユースケース記
述，画面遷移図を私とメンバーで担当箇所を分けて作成した．アカデミックリンクでのポス
ターセッションのためにポスターを作成しなければならなかったので，私はポスターを作成
するメンバー，本開発を作成するメンバーに分けて担当を振り分けた．
アカデミックリンク
アカデミックリンクのためのポスターはギリギリの完成になってしまったために発表の練
習に時間が取れなかったことが反省しなければならない点であったと私は感じた．また，私
のポスター発表を TA に見ていただいた結果，説明が長く相手に伝わりづらいといった指摘
を受けた．改めて相手に伝えることの難しさと重要性を学んだ．実際の発表のときは自分が
説明ばかりするのではなく相手の質問に答えることを主に考え発表を行った．
要件定義書の作成
要件定義書については以前作成したユースケース図やユースケース記述，画面遷移図など
を用いて作成したが，各成果物ごとに内容に差異があった．その差異を取り除くことに時間
がかかってしまい，最終的な完成がスケジュールより遅れてしまった．想定外の遅れが生じ
てしまったので以後同じ失敗を繰り返さないために私はその原因と対策についてメンバーと
話し合いの時間を設け，納得のいく対策方法を話し合った．
第 3 回ヒアリング
本グループとして作成するシステムを最終決定するために 3 回目のヒアリングを行なっ
た．いくつかの意見を頂いたが，その意見を踏まえたシステムを構築することで合意を得る
ことができた．資料の作成がヒアリング直前になってしまったので，説明のスケジュールを
考えることができていなかった．うまく説明することができたが，今後は事前の準備に余裕
を持たせることが必要だと学んだ．
最終成果発表会準備
最終成果発表会のためにポスターとスライドを作成しなければならなかった．私はスライ
ドを作成する人，ポスターを作成する人，本開発を進める人に分けて担当を振り分けた．以
前まではメンバーの希望通りになるようにあまり深く考えず担当を分けていたが，今回はメ
ンバーの得意な項目によって担当を分けた．これは，メンバーの性格や得意分野を踏まえた
人選をするべきだという企業講師のアドバイスを踏まえたもので，前期の模擬開発によって
メンバーの得意な分野が理解できたことから実現したことだと考えている．その中で私はス
ライドの作成を担当した．スライド作成の際は，発表時間が限られているためにどれだけ少
ない枚数で正確に本プロジェクトが行ってきた活動について説明するかを念頭に置いてい
Group Report of 2013 SISP
- 40 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersた．
最終成果発表会用資料のレビュー
完成したスライドを TA や教員の方にレビューしていただき内容の修正を行った．いくつ
かの指摘があったので私とメンバーの 1 人で修正を担当したが，修正したスライドを用いて
発表練習を行った時に内容を説明しにくい部分があった．そのことから新しくスライドに追
記することや発表の際に説明する内容をメンバー間で話し合った．
最終成果発表会・発表練習
話し合った結果をスライドに反映させ，発表練習を行った．発表練習の際は私を含め多く
のメンバーが体を揺らしながら説明してしまったり，レーザーポインタを振り回してしまっ
ていたので，そのような点を自分自身が行わないようにするとともにメンバーに指摘するよ
う心がけた．
最終成果発表会
成果発表会当日の私は落ち着いて説明することができ，メンバーも上手に説明することが
できていた．発表練習の時に気になっていた点もあまり気にならず，堂々と話すことが私も
メンバーもできていたと思う．また，発表アンケートの内容も非常に良かったという意見が
多く有り，とても達成感が大きかった．
最終報告書の作成
成果発表会が終わった次の演習時間から，最終報告書の作成に取り掛かった．私は最終報
告書の目次作成をメンバーの 1 人に行うよう担当を決め，作成してきた目次のレビューを行
なった．
ER 図の作成
ER 図の作成については，正規化を意識するあまり，データの受け渡し方法やテーブルの
必要性について考えておらず，TA からその点について考えが足らないとの指摘があった．
私ともう一人のメンバーで話し合い，レビューと修正を何回か繰り返した結果 TA から教員
レビューまで進んでもいいのではないかと納得を頂いたので教員へレビューをお願いした．
修正点や質問を受けたがこれを修正し，ER 図は完成した．
• 個人の学び
私の学びの多くは，チームマネジメントにおけるファシリテーションの能力である．プロ
ジェクトの初期はメンバーの一人ひとりが我が強く，自分の意見を通そうと他の人の意見を
聞かないことが多かった．リーダーとしてそれをまとめる役割ではあったが，あまりうまく
まとめきれていない部分があった．初めはなぜお互い融通がきかず反発し合っているのだろ
Group Report of 2013 SISP
- 41 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersうと不思議だったが，よく話を聞いてみるとそれぞれが，自分の意見が最良だと考えてし
まっていたのだ．私はお互いの意見を尊重しつつもっとプロジェクトをよくするにはどう
いった方法を取るべきかというスタンスで話し合いを行うように意識した．その結果，うま
く話し合いができるようになった．また，メンバーひとりひとり性格が違い，積極的に話を
するメンバーやあまり話が得意でないメンバーがいたり，得意な分野もそれぞれ違ってい
た．その中でプロジェクトをうまく進行するには話し合いの場でメンバーによって異なった
対応が必要だった．例えばあまり意見を言うのが得意でないメンバーにはこちらから積極的
に話をするようにしたり，話に集中しすぎて話題が脱線してしまうことが多いメンバーには
今話すべき話題がなんなのかを明確な状態にするよう務めた．このように話し合いを円滑に
行えるファシリテーション能力をプロジェクト活動を行っていくうちに学ぶことができた．
（※文責: 花田 洋貴）
5.2
安藤 大岳
• 準備
5 月 2 日に本プロジェクトが始まり，始めにメンバー全員の自己紹介をした．そして，メ
ンバー全体で話し合い，プロジェクトリーダーを決定した．また，Subversion など活動し
ていくために用いる環境の設定を行った．5 月 8 日に Subversion の詳しい使い方について
の講習を受けた．同時に，本プロジェクトでのチーム分けを行い，私を含む野外劇班及び模
擬開発時の A グループの 5 人のチームが結成された．
• 前期プロジェクトキックオフ
5 月 10 日に，企業講師を交えたキックオフが行われた．キックオフでは，教員や講師か
らプロジェクト学習に関しての講習を受けた．アイスブレイクや目標の設定も行い，プロ
ジェクト学習に期待することや頑張りたいことをグループで発表するなどした．
• CakePHP 勉強会
5 月 15 日から 2 週にかけて CakePHP 勉強会が行われた．1 回目は基本的な説明と
XAMPP など開発環境の構築をした．開発環境の構築は特に問題なく進めることが出来た．
2 回目は Form の作り方を学び，3 回目ではデータベースの利用法を学んだ．2 回目と 3 回
目では，それぞれ学んだ知識を利用する演習課題が出されたが，いずれもそれほど苦労する
ことなく作成することが出来た．
• 模擬開発
5 月 27 日から模擬開発が始まり，担当教員を依頼主として既存システムの改善を行うこ
ととなった．A グループは奥野先生から依頼を受けた．
Group Report of 2013 SISP
- 42 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
現状分析のためのヒアリング
5 月末から現状分析のためのヒアリングを行うため，メンバー全員で質問項目を検討し
た．6 月 5 日に模擬開発のヒアリング項目を確定した．ヒアリング項目はこの段階まで何を
聞けばいいのかわからず低迷していたが，TA のアドバイスにより１つの機能を見てこのま
まで開発を進めることが出来るかを考えることで曖昧な点が浮かび上がり，質問項目として
まとめることが出来た．奥野先生へのヒアリングは 6 月 6 日に行い，具体的な要望や質問に
対する回答をいただいた．更に，質問時に話を行ったり来たりするのはよくないといった今
後のヒアリングに関するアドバイスもいただいた．
ユースケース記述の作成
6 月 7 日に作成する成果物を決めてユースケース記述を作成した．私は面談の予約に関
する機能のユースケース記述を担当した．作成の際，ユースケースの書き方が他のメンバー
と違っていたり，それぞれ思い思いの手順を考えていたために作成に手間がかかった．
業務フロー図の作成
6 月 10 日に業務フロー図の作成を開始した．私は面談開始前のフローを担当した．
TV 会議による企業講師レビュー
6 月 12 日に TV 会議による企業講師からのレビューが行われた．このレビューにおい
て，企業講師の方にドキュメント作成する際に，意思統一のためにある程度の草分けとなる
ような人物は必要だというアドバイスをいただいた．6 月 14 日にレビューの反省会を行っ
た．
ER 図の作成
6 月 10 日に ER 図を作成し，6 月 14 日に ER 図とテーブル定義書のチームレビューを
行った．レビューでは，テーブルのカラムの物理名やどの情報が必要かということで私の意
見が他のメンバーの意見と対立し，TA のアドバイスなどもいただいたが議論は難航した．
画面モックアップの作成
6 月 14 日にメンバー全員でユースケース記述作成時と同じ役割分担をし，画面モック
アップを作成した．6 月 16 日に画面モックアップのチームレビューを行ったが，ボタンの
配置位置や画面遷移の仕方でメンバー間の意見がまとまらず，議論は難航した．
Group Report of 2013 SISP
- 43 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
要件確定のためのヒアリング
6 月 19 日に奥野先生への 2 度目のヒアリングを行い，画面モックアップや要求定義書を
用いて説明を行った．また，このヒアリングを基に画面モックアップやユースケース記述を
修正した．
実装
実装に入る前に各画面の命名規則を定めたインデックス命名記述を作成した．実装は 6 月
21 日から開始した．私は面談予約の機能とカレンダー機能の実装を担当した．また，フォー
ムでの確認画面の実装も行った．CakePHP での実装にはまだ慣れていなかったため，カレ
ンダーや確認画面の実装に多くの時間を要した．
企業講師レビュー
6 月 28 日に企業講師の方によるレビューが行われ，膨大な指摘をいただいた．総評とし
ては，情報共有をしっかりする必要があるということと，お互いを認め合い意見を出し合う
ことが大切であるというアドバイスをいただいた．また，ドキュメントの抽象度ということ
に関して，作成する成果物は抽象度の違いはあっても全てが繋がっているというアドバイス
をいただいた．
ミニ講義・ミニ演習
19 日に伊藤先生からシステムテストに関してのミニ講義を受けた．また，SeleniumIDE
の導入と使い方の演習も同時に行った．
中間発表会
中間発表の準備は 6 月 21 日から始まった．私は，ポスターに載せる概要や野外劇班の活
動の説明文とその英訳を担当した．6 月 28 日に TA にポスターのレビューをいただき，文
章や英訳の修正を行った．7 月 3 日にプロジェクトメンバー及び TA，教員からポスターの
レビューをいただき，箇条書きを使い文章を短くした方が良いというアドバイスをいただい
た．7 月 5 日にレビューを基にポスターの文章の再構成を行った．7 月 10 日には中間報告
書の目次決めを行い，野外劇班とイベント班で内容が別れるところ，一緒にできるところな
ども決めた．
7 月 12 日に中間発表会が行われた．私は，模擬開発で開発したシステムのデモの説明を
担当した．デモの説明は順調に行うことができ，こんなものがあったら使ってみたいという
声もいただくことができた．また，企業講師の方やプロジェクト担当教員からも良い反応を
いただくことができた．7 月 17 日にプロジェクトメンバー全員で中間発表で撮影した映像
を確認しながら反省会を行った．ポスターの配置場所や発表練習の不足が反省として挙げら
れた．
Group Report of 2013 SISP
- 44 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
中間報告書の作成
7 月 17 日に中間報告書の作成が始まった．私は，模擬開発に関しての文章を担当した．
22 日，23 日にプロジェクトメンバーでレビューを行い，24 日に提出した．
納品会
8 月 6 日に模擬開発の納品会が行われた．リーダーが欠席していたため，教員への説明は
私が行った．発表に際して，要求分析の甘さや顧客やメンバーとのコミュニケーションの密
度に関して指摘をいただいた．
• 本開発
第 1 回ヒアリング
5 月の下旬から末まで野外劇の現状分析を行った．始めに，実際に野外劇チケット予約シ
ステムを利用した予約を実際にしてみることで，使いづらい点や改善点などを検討した．同
時に，年間の大まかなスケジュールについても検討した．その後伊藤先生から野外劇の会の
体制やシステムの運用に関しての話を伺い，質問事項の洗い出しをした．野外劇の会へのヒ
アリングは 5 月 27 日に行い，野外劇や野外劇の会の現状からシステムの利用状況や要望な
ど様々な話を伺った．ヒアリング後にチームで内容をまとめて今後の活動に生かせるように
した．
活動計画の策定
8 月 19 日に今後の予定を立てるためにリーダーの作成した WBS を基にタスクの漏れな
どがないかなどを確認した．また，メンバーごとにどのような役割でプロジェクトを進め
ていくのかを決めた．私は，ドキュメントの責任者という担当を担った．8 月 29 日にメン
バーの活動可能日を共有しスケジュールの調整を行った．9 月 27 日に企業講師の方に WBS
のレビューをいただいたところ，計画に無理があると指摘を受け，当初 12 月を予定してい
た納品を 3 月まで引き下げて WBS を組みなおすことをチームで合意した．レビューの際，
計画は現実的に無理のないものでなければならないことや，実現困難な計画を実現するには
根性論ではなく 1 日の作業時間を増やすか全体の作業期間を延ばすかしかないということを
アドバイスいただいた．10 月 2 日にチームで開発期間を延長した WBS を確認した．10 月
4 日には，プロジェクトメンバー全員で後期のプロジェクト全体のスケジュールを確認した．
リスク管理表の作成
8 月 26 日にリスク管理表を作成を担当し，プロジェクトに潜在するリスクの洗い出しと
その対策を決定した．8 月 28 日にリスク管理表の管理担当者を決定した．
Group Report of 2013 SISP
- 45 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
プロジェクト計画書の作成
8 月 26 日に，チーム内でプロジェクト計画書の目次の検討を行った．8 月 28 日に既存
システムの問題点の洗い出しと文章化を行った．9 月 25 日に伊藤先生を交えてチームで開
発システムをどのようなものにするかを話し合った結果，野外劇の会の方々が管理しやすい
という点を念頭に置いたシステムにするという方向で話が固まった．この決定を受けて，私
はプロジェクト計画書の修正を行った．9 月 27 日にプロジェクトの管理者が管理しやすい
などの大まかなスコープを決定した．10 月 4 日にプロジェクト計画書のチームレビューを
行った．10 月 9 日にプロジェクト計画書の教員レビューをいただいた．レビューでは，主
に見やすさという点での指摘をいただいた．10 月 11 日にプロジェクト計画書の確認を行っ
た．
システム提案書の作成
9 月 25 日に WBS を基に作成する成果物の一覧を作成した．9 月 30 日に開発システム
で検討している機能の一覧を作成した．10 月 1 日にプロジェクト計画書及びシステム提案
書の各メンバーの担当文章のレビューを行った．私は，機能一覧に関して優先度の付け方
について指摘をいただいた．10 月 9 日にシステム提案書の教員レビューをいただいた．レ
ビューでは，ではお客様に見せる際に不足している部分という点での指摘を多くいただい
た．10 月 11 日にシステム提案書の確認を行った．10 月 15 日にシステム提案書の再度レ
ビューをいただいた．
プロトタイプの作成
10 月 2 日に WBS を修正していたリーダーからプロトタイプの作成を計画に組み込みた
いと相談を受け，私がその作成を担当することとなった．同日にプロトタイプを作成するた
めの足がかりとなる構想を考えた．10 月 4 日にプロトタイプに用いるデータベースを設計
した．10 月 5 日から 8 日にかけて個人作業でプロトタイプの作成を継続した．予約ページ
は既存のシステムを踏襲したものにする予定だったが，既存システムの実装が Java Servlet
であったため，当該ページを CakePHP で問題なく処理できるよう修正した．10 月 12 日か
ら 14 日にかけて個人作業でプロトタイプを完成させた．管理ページは既存システムから刷
新する予定だったため，全く新しく画面を構成した．また，チケット価格の設定や公演日の
設定など新しく追加する機能については実験的に画面遷移を表現した．10 月 15 日には教員
を含めたチームでのプロトタイプのレビューが行われた．指摘は主にユーザビリティに関す
るものであったが，メールアドレスも変えれた方が良い，チケットの種別を追加できるよう
にした方が良いといった機能の追加検討に関する指摘もいただいた．10 月 18 日には企業講
師の方からプロトタイプのレビューをいただいた．私はプロトタイプの説明を行い，説明の
仕方について指摘をいただいた．
Group Report of 2013 SISP
- 46 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
後期プロジェクトキックオフ
9 月 27 日に企業講師による後期キックオフが行われ，段取り力というお話をいただいた．
第 2 回ヒアリング
10 月 11 日にチームでヒアリングの日程について確認し，ヒアリング時の質問項目を作
成されたたたき台を基に決定した．野外劇の会へのシステム提案は，10 月 16 日に野外劇事
務所で行った．私は，プロトタイプの説明を担当し，各画面についてこのようなイメージで
作りたいということで随時確認した．説明中に野外劇の方から，予約時の入力項目を減らせ
る，地図のピンの場所を変えてほしい，チケットの種別を個別に変えるようにしたいといっ
た要望をいただくことができた．また，プロトタイプ説明時に聞けなかった質問項目は個別
に質問し回答をいただいた．システムの提案は，野外劇の会の方々にこの日出た要望をのシ
ステムに盛り込むことを約束し，承諾をいただいた．この後，ヒアリング内容を確認し，共
有は次回行うこととした．
見学者対応
10 月 18 日にプロジェクト学習の見学に来た高校生に向けてペーパータワーを用いたア
イスブレイクを行い．計画の見通しや役割分担といったチームワークに大事なことを実際の
体験を通して教唆した．
グループ会議
10 月 22 日には，前期に会議中に度々意見が対立し，進行が滞ったことからリーダーが制
定した会議を行う際のルールを確認した．更に，レビューを行う際に指摘事項を整理するた
めに用いるレビューシートについてもメンバーから説明があった．10 月 23 日に TA から議
事録の書き方についてのアドバイスをいただいた．11 月 15 日には，SVN によるバージョ
ン管理の方法が議題にあげられ，ver1.1 のようにメジャーバージョン毎にファイルを保存し
た方が良いのではないかということが今後の検討課題になった．
非機能要件の作成
10 月 18 日に非機能要件の作成を開始した．10 月 22 日に非機能要件を策定するために
記述方法の調査を実施し，IPA が定めるテンプレートを採用することにした．10 月 23 日
には非機能要件の策定に関して本プロジェクトでは対応の難しい部分があったため，その点
を保留して作業を進めた．10 月 25 日に非機能要件の教員レビューが行われた．レビューで
は，書き方が曖昧だった部分に関してアドバイスをいただけた．10 月 30 日に非機能要件
TA を交えたレビューを行った．非機能要件の記述の足りない部分についてアドバイスいた
だけた．11 月 15 日に障害時の対応の提案を提唱し，非機能要件の保留事項となっていた項
目の補足事項とした．
Group Report of 2013 SISP
- 47 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
ユースケース図の作成
10 月 22 日にユースケース図のチームレビューを行った．10 月 23 日に再度ユースケー
スの変更について確認を行った．10 月 25 日にユースケース図教員レビューが行われた．
画面遷移図の作成
10 月 29 日に画面遷移図のチームレビューを行った．11 月 13 日に画面遷移の教員レ
ビューを行った．
業務フロー図の作成
11 月 1 日に業務フロー図の TA を交えたレビューを行った．業務フロー図のレビュー中
にメンバーから，仕様について決まっていない部分があったので作成中にどうすればいいの
かわからなかったという意見があったため，この場合の対策をメンバーで話し合い，ルール
に追加した．11 月 21 日に業務フロー図のチームレビューを行った．
要件定義書の作成
10 月 30 日に要件定義書の目次の TA を交えたレビューを行った．11 月 1 日に再度要件
定義書の目次の TA を交えたレビューを行った．11 月 6 日に要件定義書のはじめに，本書
の位置付け，システム再構築の目的を作成した．特に，はじめにを書くにあたってビジネス
文書における季節のあいさつを調べるなどした．11 月 15 日に開発システムにおいてログイ
ン方法を BASIC 認証からフォーム認証に変えることをメンバー間で合意したため，この変
更の影響を受ける成果物を洗い出し，修正個所を特定した．11 月 29 日にヒアリングのため
の最終準備として要件定義書の修正と印刷を行った．
アカデミックリンク
10 月 30 日にアカデミックリンク用のポスターテンプレートの TA を交えたレビューを
行った．11 月 5 日にアカデミックリンク用ポスターのチームレビューを行った．11 月 8 日
にアカデミックリンク用ポスターのチームレビューを行った．その後，企業講師の方のアド
バイスを参考にアカデミックリンクの発表準備を行った．アドバイスは，まず通りかかる人
に興味を持ってもらう必要があること，話をする相手によって説明方法を変える必要があ
る，相手をがっかりさせないような発表方法を考える必要があるという点に関していただい
た．また，チームで成果物のうちのいくつかを印刷して展示することを決め，急きょこれら
を準備することにした．
アカデミックリンクは 11 月 9 日に青年センターで行われた．本プロジェクトでは，野外
劇班とイベント班で別々にブースを設けた．野外劇班のブースではポスターのほかに，野外
劇のポスターやパンフレット，成果物，プロトタイプを展示した．プロトタイプは私のノー
ト PC にモニタを接続して展示した．私は，事前に決めたシフトに従いポスターセッション
を行った．システムやシステムの利用フローに関して何点か質問に回答したが，想定外の質
Group Report of 2013 SISP
- 48 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers問をいただくことはなかった．
11 月 12 日にアカデミックリンクでいただいた意見や質問をまとめた．11 月 13 日には
もう一度アカデミックリンクのまとめを行った．特に，野外劇の収容人数については想定し
ていなかったため，次回のヒアリング項目とした．
ユースケース記述の作成
11 月 11 日にユースケース記述のチームレビューを行った．11 月 13 日にユースケース
記述の教員レビューを行った．
プロトタイプ拡張
11 月 20 日にプロトタイプのデータ構造をチケット種別の変更に対応できるよう修正し
た．11 月 22 日に個人作業として過去の予約情報の閲覧機能を作成した．11 月 27 日にプロ
トタイプのログイン画面の作成を行った．11 月 29 日にプロトタイプを完成させてエラーが
起こっていないかを確認した．
第 3 回ヒアリング
11 月 13 日にヒアリングまでの日程や必要な作業などの情報共有を行った．11 月 15 日
に前回と同様にヒアリング時の質問項目を作成されたたたき台を基に決定した．
野外劇の会への 3 回目のヒアリングは 11 月 30 日に野外劇事務所で行われた．私は，前
回のヒアリングと同様にプロトタイプを用いた機能説明を行った．説明中に野外劇の会の方
から，チケットの変更履歴を残しておいてほしいという要望を得ることができた．また，野
外劇の会の方からは，新しいシステムは便利になりそう，未来大の方にこのシステムを使っ
て野外劇を見に来ていただきたいといった反響を得ることができ，新しいシステムに十分満
足いただけた．この後，ヒアリング内容を確認し，ヒアリングの質問回答のまとめとヒアリ
ング内容のまとめは私が担った．
最終成果発表会
11 月 22 日に最終成果発表用ポスターの TA を交えたレビューが行われた．11 月 27 日
に最終成果発表用ポスターのチームレビューを行った．12 月 4 日に最終成果発表用スライ
ドの TA を交えたレビューを行い，その後の全体練習で教員からのレビューをいただいた．
スライドの修正と発表の練習はメンバー全員で行った．12 月 5 日に最終成果発表用スライ
ドを完成させ，発表の練習と想定される質問の検討を行った．
最終成果発表会は 12 月 6 日に行われた．私は，前半最後のみ発表を担当し，その際シス
テムの使いやすさについて可用性など環境的な面は考慮しないのかという質問を受けたた
め，機能的な使いやすさに焦点を当てている旨を説明した．また，発表会には野外劇の会の
方の姿も見られた．
Group Report of 2013 SISP
- 49 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
ER 図の作成
12 月 2 日にプロトタイプを基に ER 図を作成した．12 月 13 日に作成した ER 図の共
有を行った．データベース構造の説明は私が行った．12 月 18 日には，ER 図のチームレ
ビューと教員レビューを行った．レビューでは，保存するデータ量や発行するクエリ量を中
心にアドバイスいただいた．12 月 19,20 日にかけて TA のアドバイスを参考に ER 図を修
正した．
データ定義の作成
12 月 3 日には ER 図からデータ定義を作成した．12 月 19,20 日にかけて TA のアドバイ
スを参考にデータ定義の修正を行った．データ定義に関して，わかりやすい名前を考えた方
が良いというアドバイスをいただいたため，物理名の再考をした．
クラス図の作成
12 月 4 日にプロトタイプを基にクラス図を作成した．
振り返り会
12 月 20 日に企業講師によるプロジェクト学習の振り返りを行い．どんなことがあり，ど
のような学びに繋がったのかということをまとめた．
• 個人の学び
私は，このプロジェクトを通して 3 つの視点からの学びを得ることができた．1 つ目は，
チームワークに関しての学び,，2 つ目は実装技術に関しての学び，3 つ目は開発工程に関し
ての学びである．チームワークに関しては経験的な学びが多く，他は知識的な学びが多く得
られた
チームワークに関しては以下のような学びがあった．前期の活動では，チームで集まって
会議をすると意見が対立して話が進まないという局面が多く見られた．これに関して，私は
様々な方からアドバイスをいただきどうすれば状況を改善できるかを常々考えていた.．得
られたアドバイスとしては，相手の意見のメリットを考える，納得のいくまで話し合うと
いったものがあった．後期からは，会議ルールを制定したり，相手の意見を踏まえた発言を
心掛けることでチームでの会議がスムーズに進むようになった．また，私は企業講師の方か
ら成果物の指摘するだけのレビュアーになっていてチームの一員らしくないという指摘をい
ただいていた．この指摘を受けて，後期からは足りないまたは違うと思う点に対してもっと
こうした方が良いというような，建設的な意見を積極的に述べるよう心掛けた．加えて，前
期の活動ではメンバーで分担して 1 つの成果物を作成する際に，個々人が自分なりの書き方
で作成してしまったため，同じ成果物間で不整合が起こったり，全体として統一性のないド
キュメントが作成されて修正に苦労するということがあった．そのため，後期からは書き方
を統一するためにテンプレートを作成し，作成した成果物の内容共有を徹底し，更にドキュ
メント責任者を設けることでスムーズに作成が進むよう心掛けた．活動時に作成する議事録
Group Report of 2013 SISP
- 50 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersに関しても，TA からのアドバイスをいただき書き方を改善した．大きな議題ごとに，何が
あり，どういうことが決まり，どのくらい進んでるのかという点でまとめることで後で見直
した際に活動内容が分かりやすい議事録をかけるようになった．
実装技術に関しては，以下のような学びがあった．今回用いた PHP のフレームワークで
ある CakePHP は，今まで経験してきたスタンドアロンで動作するプログラミング言語とは
少し違っていた．今回，データベースを用いた WEB システムを構築することで WEB サー
バや SQL などの関連知識を深めることができた．また，CakePHP に限らず様々なシステ
ムを構築するための基礎となる知識や経験を得ることができた．更に，プロトタイプの作成
を通して CakePHP を用いた実装能力の向上につなげることができた．
開発工程に関しては，以下のような学びがあった．前期は，タスクの洗い出しなどをする
ことなく，個々の成果物について作成する理由などをあまり深く考えず作成していた．後期
からは，WBS をしっかりと作成して成果物間の関連を考えてドキュメントを作っていくこ
とで品質の向上に繋げられた．また，作成する成果物がメンバー間での意識共有としても用
いることができるということを知った．更に，抽象度の高い成果物を作成してからそれを補
足するような詳細な成果物を作成することで少しずつシステムの全体像を明確にして行ける
ことに気付いた．成果物全体で見たときに全ての成果物が 1 つのシステムを様々な角度から
表現したものであることをしり，全ての成果物は独立せずに繋がっているということに気付
いた．全体を通して，システム開発を経験していく中で，お客様の要求を正しく分析するこ
との難しさ，分析した要件を適切にシステム化することの難しさ，コミュニケーションの大
切さ，全ての整合性を保ちながら開発を進めることの難しさなどを身をもって体感すること
ができた．
（※文責: 安藤 大岳）
5.3
齋藤 尊
• 体制決定
5 月 2 日に本プロジェクトが始まり，まずメンバー全体で自己紹介をした後，プロジェ
クトリーダーを決定した．8 日にグループ分けをメンバー全体で行った．そこで私は野外劇
班として活動を行うことに決めた．10 日にアイスブレイクとグループディスカッションを
行った．
• 環境構築
5 月 2 日にプロジェクト管理ツールとして Subversion と TortoriseSVN のダウンロード
を行った．
• CakePHP 勉強会
5 月 15 日には CakePHP 勉強会の 1 回目が始まり，私は TA の助力を受けつつ，開発環
境の導入と CakePHP の基本的な使い方を学習した．17 日には 2 回目の CakePHP 勉強会
として，Form ヘルパーの使い方の勉強を行った．2 回目の演習課題は苦戦したが，当日に
回答できた．22 日に 3 回目の CakePHP 勉強会に参加し，データベースとの連携について
Group Report of 2013 SISP
- 51 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers学んだ．この回の演習問題は残念ながら当日中に回答することができなかったため，次回の
答えあわせで解き方の確認を行った．
• Redmine 運用班
5 月 22 日に Redmine を今後どの様に運用していくかを決めるため，Redmine 運用班を
新しく設置し，私は Redmine 運用班のリーダーとして他のメンバーへ運用ルール草案の作
成担当を割り振った．
6 月 3 日に Redmine 運用班を集めて，草案のレビューと修正およびチケット発行のルー
ル策定を行った．チケット発行のルールは，チケット名の付け方や優先度の設定基準などの
設定を行った．5 日に Redmine 運用班として運用ルールをメンバーに発表した．その際，
ステータスに入力する値の定義をもっとしっかりしてほしいという要望をメンバーからいた
だいた．
• 模擬開発
5 月 27 日から模擬開発が始まり，まず 27 日と 31 日に模擬開発のヒアリングのための質
問項目をチームで洗い出した．
現状分析，要件確定のためのヒアリング
6 月 6 日に奥野先生へのヒアリングを実施した．ヒアリングの際は，直接先生と話をして
いた花田のサポートを行った．21 日に奥野先生への 2 度目のヒアリングを実施し，システ
ムの仕様を詳細に詰めた．
ユースケース記述の作成
6 月 7 日にどのような成果物を作成するかをチームで決め，面談日時関連および代理予約
関連のユースケース記述の作成を行った．
業務フロー図の作成
6 月 10 日に業務フロー図の作成担当の割り振りを受けた．私はユースケース記述をもと
に，面談前日の際のリマインダーメールに関する業務フロー図作成を担当した．
TV 会議による企業講師レビュー
6 月 12 日に TV 会議で企業講師からの成果物のレビューを受け，14 日にその会議の反省
を行った．
画面モックアップの作成
6 月 14 日にメンバー全体でそれぞれが担当する機能の画面モックアップを作成した．こ
の画面モックアップは 16 日にメンバー全員でレビューを行った．19 日には奥野先生からの
Group Report of 2013 SISP
- 52 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers御意見を頂き，モックアップの修正とシステム仕様の修正を行った．
実装
6 月２ 8 日から実装作業を開始し，私は面談の候補日時の登録・変更・削除機能と，教員
による面談の代理予約等の機能を担当した．翌日にシステム実装のレビューを行った．その
際，TA から「自分ではできないところはメンバーにちゃんと報告しないと全体の進捗が遅
れてしまう」という御意見をいただいた．
ミニ講義・ミニ演習
7 月 19 日には，伊藤恵先生からのミニ講義とミニ演習を受けた．ミニ講義ではシステ
ム開発におけるテストの説明をしていただき，ミニ演習ではテストツールとして Selenium
IDE の利用を行った．
納品会
8 月 6 日に，模擬開発で作成したシステムの納品会へ参加した．納品会の際には，メン
バー間やお客様のコミュニケーションをもっと上手に行う必要があるという点について指摘
をいただいた．
中間発表会用スライドの作成
6 月 21 日に中間発表のためのスライド作成準備を始めた．23 日にはスライドの叩き台と
して，目的，体制，活動内容，模擬開発についてのスライドの内容を決定した．その後，6
ページの活動内容の担当として，該当箇所のスライド作成を始めた．２ 8 日に中間発表用ス
ライドのレビューをスライド班で行った．
7 月 3 日には，スライド班として再び中間発表用のスライドのレビューを実施した．同様
に中間発表用ポスターのプロジェクトメンバー全員でレビューも実施した．5 日にはスライ
ド発表の練習を行い，TA から姿勢やスライド中の修正すべき点の指摘をいただいた．10 日
には 4 限目にレビューを元にしたスライドの修正を行った．そして 5 限目に中間発表会の
会場での発表練習を行った．発表練習とともにチームおよび TA によるレビューを受け，修
正ヶ所を確認した．
中間発表会
7 月 5 日にメンバー全員で発表会当日に必要なものの洗い出しと，当日の役割分担を行っ
た．7 月 12 日に，プロジェクト学習の中間発表会で，後半の野外劇班のスライド発表担当
として，本プロジェクトの発表を行った．スライド発表の際には，野外劇の会からの要望を
取り入れるのであればシステムの再構築ではないのではないか．などといった質問の受け答
えを行った．また，中間発表会にきていただいた企業講師の高森さんから，スライドの構成
や発表の方法についての指摘をいただいた．加えて，私の発表の時ではないが，発表最中に
Group Report of 2013 SISP
- 53 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersプロジェクタが破損するというトラブルも発生した．17 日にはプロジェクトメンバー全員
で中間発表会の際録画していたビデオを再生しながら，中間発表会の反省を行った．大きな
反省点として，スライド発表の練習が不足しているということが挙げられた．
中間報告書の作成
7 月 17 日の 5 限目から，中間報告書の作成作業を始めた．その日はグループ報告書の記
述担当の分担を行い，私は成果と学びの中の，Redmine・テレビ会議・A グループの模擬開
発・本開発全体部分・野外劇の本開発の文章の作成を始めた．22 日と 23 日の 5 限には，メ
ンバー全員でグループ報告書のレビューを行った．そして，24 日には中間報告書の手直し
を行い，提出を行った．
• 本開発
本開発は，まず 8 月 19 日に今後の予定を立て，メンバーそれぞれがどのような役割でプ
ロジェクトを進めるのかを決めた．私はチケット管理の担当として，メンバー全員の作業
の進捗管理を行うこととなった．29 日に夏休み中の活動可能日時の報告をメンバーに行い，
メンバー全員で新しく追加したタスクの日程調整の確認を行った．
第 1 回ヒアリング
5 月 21 日にはまずチーム全員で現行の野外劇チケット予約システムを利用し，改善が必
要であろう点の洗い出しを行った．改善点の洗い出しを行った結果，予約の変更の際のユー
ザインターフェースが紛らわしいのではないかという指摘を行った．24 日に伊藤恵先生と
打ち合わせを行い，野外劇の会スタッフの体制やシステムの利用状況を伺った後，野外劇の
会へのヒアリングのための事前確認項目の洗い出しを行った．27 日にチームで野外劇の会
へのヒアリングを実施し，そこで野外劇の会からの要望 を伺った．31 日にヒアリングのま
とめと反省を行い，今後ヒアリングを行う際の方針を決めた．
プロジェクト計画書の作成
8 月 26 日に一度野外劇班で集まり，メンバー全体で開発用語集の作成とプロジェクト計
画書に含める内容の策定と目次等の作成を行い，個人の活動としてシステム対象化範囲の規
定を行った．その後，次回までの課題としてプロジェクト計画書作成のため，本プロジェク
トの制約の洗い出しと文章化を行った．
成果物一覧の作成
9 月 19 日に，作成した成果物をまとめるためのドキュメント作成を行った．このドキュ
メントはリーダーが作成したドキュメントを基に，今後作成する成果物の名称と作成者，成
果物のファイル名を記入できるように作成を行った．
10 月 1 日にはメンバー全員で，それぞれの成果物に対するチームレビューを行った．そ
こで成果物一覧のレビューを受けた．
Group Report of 2013 SISP
- 54 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
後期プロジェクトキックオフ
9 月 27 日に後期キックオフとして，プロジェクトメンバー全体で企業講師の方による，
「段取り力」の講義を拝聴した．
システム提案書の作成
9 月 27 日の 5 限から，システム提案書の内容に含める，システムの特徴を示す文章の作
成を始めた．
10 月 1 日にシステムの特徴を表す文章のレビューを受けた．その結果，システムの特徴
に含める内容として，Twitter，Facebook についての内容は検討しているという旨に変更す
る．エンドユーザという表記を利用者に変更すべきという指摘をメンバーからいただいた．
10 月 2 日にプロジェクト計画書やシステム提案書の内容作成を各メンバーで分担して作成
を行った．私はシステムの制約部分の文章作成をこの時間に行った．4 日の 5 限目からは作
成したメンバー全員でプロジェクト計画書のレビューを行った．9 日には，まず 4 限目に作
成したプロジェクト計画書とシステム提案書の教員レビューを受けた．そのレビューの中
で，システム提案書はお客様に見せるものなので，冒頭部分に挨拶という章が必要だという
指摘をいただいた．そのため，5 限目には指摘箇所の修正を行った．特に私はシステム提案
書冒頭の挨拶部分の作成を行った．その後，11 日にメンバー全員でプロジェクト計画書と
それに含まれるスケジュール表と体制図，野外劇の会とのヒアリング時に用いるヒアリング
シートの確認を行った．15 日には，16 日に行うヒアリングのためにシステムのプロトタイ
プとシステム提案書の教員レビューを受けた．プロトタイプのレビューでは，主に UI につ
いて指摘をいただき，システム提案書のレビューでは主に表現についての指摘を受けた．16
日には，メンバー全員でシステム提案書のヒアリング直前の修正と確認を行い，システム提
案書を印刷した．
チケット管理
10 月 4 日の 4 限目にリーダーからの連絡を受けた後，個人作業として用語集の作成と各
メンバーの活動を Redmine のチケットとして発行した．10 月 18 日にはメンバー全員のタ
スク管理を行い，今後の課題として業務フロー図とユースケース記述の作成を担当した．
非機能要件の作成
10 月 4 日のプロジェクト計画書のレビューの後，次回までの活動として要件定義書に利
用する非機能要件の文章作成を担当することになった．しかし非機能要件は項目の作成にと
どめ，システム提案書の修正優先してを行った．
Group Report of 2013 SISP
- 55 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
レビュー記録表の作成
10 月 9 日に，プロジェクトで計画していた成果物と別にレビューの際の指摘内容を分か
りやすく残すために，レビュー記録表を独自に作成し，メンバーに共有した．23 日に各自作
業として，レビュー記録表の使い方を文章として，レビュー記録表のテンプレートに追加し
た．22 日にグループメンバーで集まり，まず今後の会議ルールの策定を行った際に，メン
バー全員に作成したレビュー記録表の使い方についての具体的な説明を行った．
見学者対応
10 月 18 日には，プロジェクトメンバー全員で 4 限目に高校生の見学者への説明とアイ
スブレイクを行った．私は，アイスブレイクの際のアドバイス等を担当した．
業務フロー図の作成
10 月 23 日の 5 限目には，非機能要件の作成を他のメンバーに任せ，業務フロー図の番
号付けと項目作成を行った．25 日の教員レビューの後，各個人作業として業務フロー図の
作成を行った．私はエンドユーザが用いる機能の業務フロー図を担当し，エンドユーザ側機
能の業務フロー図を作成した．
11 月 1 日にと業務フロー図の TA レビューを受けた．業務フロー図のレビューでは，場
合わけの際の入力ボタンの扱いなどを指摘していただいた．そして，画面遷移図担当者と業
務フロー図担当者が話し合って，画面やボタンの整合性を合わせる必要があることが分かっ
た．15 日に，これまで作成してきた成果物中にログイン機能についての記述がなかったた
め，ログインおよびログアウトの仕様を定め，メンバー全体で各成果物の修正を行うことと
なった．私は業務フロー図にログインとログアウトを追加する作業を行った．20 日にはま
ずリーダーが各個人の作業を分担し，個人作業に勤めた．私は，業務フロー図のと要件定義
書の修正を担当した．その結果，業務フロー図の修正が終了した．21 日にメンバーが集ま
り，業務フロー図のレビューを実施した．そのレビューで用語の統一や必要な文言の追加を
行った．22 日にはメンバー全員でそれまでの進捗報告を行った後，引き続き業務フロー図
の修正を続けた．
要件定義書の作成
10 月 29 日に要件定義書のテンプレートを作成することを任された．10 月 30 日にはメン
バー全員の進捗の後に要件定義書のテンプレートのレビューを行った．レビューでは章のタ
イトルの付け方や内容の順序などについて指摘をいただいた．レビュー後は指摘を受けて，
要件定義書の修正を行った．
11 月 1 日に要件定義書の目次の TA レビューを受けた．要件定義書の目次レビューの際
には，具体的にどのような流れで野外劇の会へ説明するのかを踏まえて，目次の各項目でど
のような内容を書くのか説明を行った．その結果として，要件定義書に添付する画面遷移図
は何のために使うのかによって位置づけが変わる．というアドバイスをいただいた．これま
で作成してきた成果物中にログイン機能についての記述がなかったため，22 日までにその
Group Report of 2013 SISP
- 56 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers部分の修正を完了させることとなった．この修正が必要となったため，11 月 23 日を予定し
ていた野外劇の会へのヒアリングを 1 週間遅らせることとなった．29 日には，学校の入出
制限が掛かるまでの間，要件定義書の修正を行った．具体的な修正として，今までレビュー
出てきた指摘内容の修正とその確認，そしてこれまでに作成してきた成果物との整合性の確
認をおこなった．要件定義書の全内容の確認が終了したら，各成果物の印刷を行った．印刷
の際，ユースケース記述で用いている表の枠が印刷されないという問題があったため，必要
な部分を手作業で修正した．
アカデミックリンク
11 月 5 日には，まずメンバー全員でアカデミックリンク用ポスターのレビューを実施し
た．チームメンバーでのレビューの際には，システムという章がシステムのメリットについ
て書かれている等といった指摘が出された．その後，指摘箇所を修正されたポスターを再度
レビューした．2 度目のレビューでは，野外劇予約システムの章に含める内容についての意
見を出すなど，具体的な内容についての指摘を行った．
6 日はアカデミックリンク用ポスターのレビューを予定していたが，ポスターの修正が
間に合わなかったため，取りやめとなった．8 日にはまず 1，2 限目にチームメンバーで集
まり，6 日にできなかったアカデミックリンク用ポスターのチームレビューを実施した．レ
ビューではまず前回からの修正点の報告を受けた後，ポスター内容の指摘を行った．私は，
ヘッダの誤植や句読点，言い回しについての指摘をおこなった．同日 4 限目からは，企業講
師の方にポスター発表の際のアドバイスをいただいた．アドバイスとして，ポスターに書か
れていない内容をきちんと口頭で説明する練習が必要である．や，聞きに来る人がどのよう
な人かを考えた発表内容にするべきという意見をいただいた．そのため，アカデミックリン
クにはどのような人が来て，その人ごとにどのような内容を話せばよいのかをチーム内で検
討した．また，アカデミックリンク当日の役割分担と，に何が必要なのかを洗い出した．そ
の洗い出しによって，これまでの成果物のうちの幾つかを展示することが決まったため，そ
の印刷を行った．
9 日にアカデミックリンクに参加した．アカデミックリンクでは野外劇班のブースを設置
し，ポスターセッションを実施した．その際，見に来られた方から，システムでは最大どの
くらいの予約者の数を想定しているのか．といった，今まで想像していなかった事を質問し
ていただいた．
12 日には 9 日のアカデミックリンクのまとめを行った．その際に，メンバー全体でア
カデミックリンクの際に受けた質問と回答を全員で共有した．13 日には，まず再びアカデ
ミックリンクのまとめを行い，システムのレイアウトの問題点や想定外の質問に関して検討
が必要であるという結論に至った．
ユースケース記述の作成
10 月 18 日の 5 限から，ユースケース記述の作成を始めた．
11 月 6 日に担当していたユースケース記述がまだ作成途中であることを報告した後，管
理者側機能のうち，設定関連の機能を示すユースケース記述の作成を行った．11 日には，
ユースケース記述のチームレビューを実施した．レビューの際には，各担当部分ごとにレ
Group Report of 2013 SISP
- 57 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersビューを実施した．私が担当したチケット予約機能と設定関連機能のユースケース記述につ
いてレビューを受けた．チケット予約機能のレビューでは代替系列や例外系列の表記ゆれや
ユースケースの終了ヶ所について指摘を受けた．設定関連機能のレビューでは，チケット価
格等の設定のユースケースを分割したほうが良いという事や，起こりうる代替系列が書かれ
ていないなどの指摘を受けた．そのため，今後の課題としてユースケース記述の指摘箇所の
修正を行うこととなった．ユースケース記述の教員レビューを受けた．その際には，チケッ
ト価格の設定に下限や上限などをしっかり設定すべきなどという指摘をいただいた．そのた
め，次の活動までにユースケース記述の修正を行うことになった．
第 3 回ヒアリング
まず 11 月 13 日にメンバー全体で今後野外劇班としてすべきことを共有してから，野外劇
の会への 3 度目のヒアリングの候補日時の確認をした．29 日には，野外劇の会との話し合
い前日のため，まずその準備として必要な物品の準備を行った．
30 日に野外劇の会への 3 度目の話し合いを実施した．私は，書記として話し合いの際に
言われたことなどを記録した．はじめに要件定義書や参考資料を野外劇の会の方々に配布
し，内容の説明を行った．その際，具体的な各機能については触れなかった．次に，システ
ムのプロトタイプで各機能の説明を行った．そして最後に非機能要件の説明と質疑応答を
行った．話し合い終了後，リーダーの家でまとめを行ったところ，野外劇の会事務所へ行く
までに準備が不足し，あわててしまったという反省点が上がった．
Subversion によるバージョン管理
11 月 15 日には，まず SVN のバージョン管理について話し合った．現在の利用方法で
は，文書のどこが変わったのかが分からないという問題が発生したため，それが今後の検討
課題となった．
最終成果発表会用資料のレビュー
11 月 22 日に最終成果発表用ポスターのチーム・TA レビューを実施した．そのレビュー
では，関係企業の表記についての指摘などを行った．27 日には，最終成果発表用ポスターの
チームレビューを実施した．その際に私は，内容中の文章に不必要ものがある．という点を
指摘した．
最終成果発表会用スライドの作成
11 月 29 日の 5 限目終了までは最終成果発表用のスライド作成を行った．
12 月 4 日には，まず最終成果発表用のスライドの TA およびチームレビューを実施し
た．その際に指摘された内容として，ページ番号の重複や用語の表記ずれ等の表記上のミス
や，頑張った点が分からない．失敗からの学びがほしい．等の内容についての指摘をいただ
いた．その次に教員を含めたプロジェクト全体でのスライドレビューを実施した．その際に
は，スライド中の写真がぼけている．スケジュールの凡例に納品を入れるべき．などの指摘
Group Report of 2013 SISP
- 58 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersをいただいた．その後，それまでに受けた指摘箇所の修正を行った．
最終成果発表会
12 月 6 日には，まず 2 限目に最終成果発表の会場であるミュージアムで会場設営を行っ
た．設営の際は予備のプロジェクタを用意するなど，中間発表の反省を生かした準備を行っ
た．そして，4 限目から最終成果発表を行った．私は 1 度目と 2 度目の野外劇班スライドの
発表担当として，発表を行った．1 度目の発表には野外劇の会の理事の方にも来ていただい
た．発表の質疑応答を行った際に，依頼されていた内容ならば，野外劇班のほうに人員を割
いたほうが良かったのではないか．という指摘をいただいた．
ER 図のレビュー
12 月 13 日にグループメンバ全員で集まり，ER 図のピアレビューを実施した．18 日に
は，まずグループメンバで集まり，修正した ER 図とデータ定義書のレビューを行った．そ
の後 4 限目からは ER 図の TA および教員レビューを実施した．レビューの際には伊藤恵
先生から，お客様の微妙なニュアンスをちゃんと確認して作業を行うことが大切である．と
いうアドバイスをいただいた．
データ定義書のレビュー
12 月 13 日には，メンバー全員で今後の予定を決定した後，18 日までに個人が行う作業
の確認をした．そこで私は 18 日までにデータ定義書のレビューを実施する事となった．18
日には，まずグループメンバで集まり，修正したデータ定義書のレビューを行った．
• 最終報告書の作成
個人作業として，私は野外劇報告書班のリーダーとして，まず報告書の構成を検討した．
20 日には，報告書班として，グループメンバ全員に報告書の作成担当の割り振りを行った．
担当割り振りは，他のタスクも掛け持ちしているメンバーは比較的容易な部分の担当に割り
当てるなどの配慮をした．
• 振り返り会
20 日には，企業講師の方による振り返り会に参加した．振り返り会では，これまでの活
動でどのようなことをしたのかや，どのような学びがあったのかを振り返った．
• 個人の学び
私はこのプロジェクト学習を通して，スケジュール通りに作業を進めることがとても難し
いという事，そして，スケジュール通りにプロジェクト進めるためにはメンバーそれぞれ
が，さまざまな形で努力を行わなければならないということを学んだ．この学んだ必要な努
力とは，主にメンバー間の情報共有と，個人で自主的に進める活動である．メンバー間の情
報共有が大切であると分かったのは，業務フロー図やユースケース記述の作成を行っていた
際，分岐の描き方や代替系列等の表記の仕方などをメンバー間で統一できていなかったた
Group Report of 2013 SISP
- 59 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersめ，レビュー際には度々そのような書式の統一不足が指摘された．そのため，詳細なテンプ
レートを作成する必要があるとともに，成果物作成の際には，少しでも気になる点は同じ作
業を行っているメンバーと連絡を取り，確認を行うことが重要だと理解した．
また，個人で進める作業が重要であるとしたのは，模擬開発の際の実装技術の準備不足が
あったからだ．模擬開発の際，設計工程での成果物作成のみ行っていて，開発言語の勉強を
怠っていた．そのため，実装工程を進めながら開発言語の習得を行った．これにより，開発
に遅延が発生してしまった．プロジェクト内で指定された課題をこなすだけではなく，自ら
が考え必要な作業を行うことが円滑にプロジェクトを進める上で重要であると学ぶことがで
きた．この経験を踏まえ，本開発の際にはレビューで得られた指摘内容をより分かりやすく
する必要があると考え，レビュー記録表を独自に作成した．これにより，修正すべき点が明
確になり，円滑な成果物修正ができるようになった．
（※文責: 齋藤 尊）
5.4
吉田 匡孝
• 前期プロジェクトキックオフ
プロジェクト開始直後のキックオフ・イベントで野外劇班（チーム）とイベント班（チー
ム）に分かれて，このプロジェクト学習で期待することや向上させたいことを発表した．私
は野外劇班へ所属することになった．その後プロジェクトメンバー内で野外劇班とイベント
班に分かれ，私は野外劇班へ所属することとなった．
• CakePHP 勉強会
プロジェクトキックオフ・イベントの次に CakePHP 勉強会が始まった．5 月中旬から下
旬までの期間で全 4 回あり，1 回目は XAMPP を使った環境構築から始まった．XAMPP
は以前に PHP の勉強をする時によく使っていたため，環境構築は速やかにできたものの，
構築する環境でソフトウェアのバージョンが指定されていたため，最新版を使いたいのに
使ってしまったらこの先上手くいかないのかと不安になってしまった．2 回目の勉強会で
データベースへの変更が反映されずに時間がかかってしまったところがあったが，勉強会で
用意された課題を次々取り組んだ．
• 模擬開発
CakePHP 勉強会が終わるとそこで学んだことを生かす模擬開発が始まった．模擬開発
の期間は 5 月下旬から 8 月上旬までであった．模擬開発では教員を開発依頼者と想定し，教
員と面談を希望する際の予約を管理するシステムを開発した．
模擬開発用サーバのセッティング
初めに，模擬開発で使用するサーバをセッティングした．模擬開発用のサーバで CakePHP
を動作させようとすると，エラーメッセージだけが表示された．エラーメッセージから調査
して，数時間かけてようやくエラーの原因と解決策にたどり着いた．そのエラーメッセージ
Group Report of 2013 SISP
- 60 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersと対策法をドキュメントにまとめ，他のチームでサーバ設定に躓いているところを手助けし
た．
現状分析のためのヒアリング
6 月では模擬開発に関するドキュメントを作成するため，ヒアリングを実施した．ヒアリ
ング中はパソコンでメモを取りつつ資料をプロジェクターで映したが，実施後に「パソコン
でメモを取ろうとしないでできるだけ筆記でメモすべき」という指摘をいただいた．
ドキュメント作成
ヒアリング結果を踏まえ模擬開発を進めるためのドキュメントを作成し，私はシステム全
体の画面遷移図とシステムを使って面談予約した後の業務フロー図を担当した．
でき上がった画面遷移図は内容が非常に画面数が多く，閲覧性が悪いことが懸念された
が，後のチームレビューで「よくできている」と言われ，システムで使用され得る画面を網
羅的にまとめることが得意だったことがわかった．
画面モックアップの作成
ドキュメントのレビューを進めるうちにプロジェクトメンバー各々の考えていたことの相
違が起きたため，一度考えていたことをしっかりとした図に残すべきと，画面モックアップ
の作成を提案した．その結果，プロジェクトメンバー各々の考えていたことがはっきりとわ
かり，メンバー間との調整が取れ，作業スピードが上がった．
TV 会議による企業講師レビュー
6 月中旬には企業講師の方々と TV 会議を実施し，画面遷移図の内容について余すことな
く伝え，「よくできた画面遷移図」といった評価をいただいた．さらに，画面を網羅的に記
すだけではなく，図の左上を起点にしたことも高評価につながった．
TV 会議後にシステムの実装が始まり，私はログイン画面とログイン状況に応じた処理を
担当した．
中間発表会の準備
7 月の中間発表会ではスライドを作成するチームに入り，スライドのデザインを提案し
た．その後，発表練習をした．発表時間を気にしていたのか，プロジェクトメンバーから
「早口になってしまっている」という指摘を受けた．また，発表練習中にスライドの内容を
思い出せない時がいくつかあった点に気付き，練習が必要だと感じた．練習を重ねるにつ
れ，スライドの内容が頭に残り，早口ではない余裕を持った発表になってきた．中旬に中間
発表会があり，その時は緊張で多少引っかかった場面もあったが発表でよく説明できたと感
じた．
Group Report of 2013 SISP
- 61 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
中間報告書の作成
中間発表会の後に，プロジェクト学習 WG へ提出する中間報告書を作成した．私はその
うちの野外劇班における本開発の概要を担当した．担当した部分の文章量としてはそんなに
多くなかったため，その後の報告書を印刷して紙媒体にする作業で最終版のファイルをコン
パイルしたり，印刷前のファイル最終版のチェック，印刷の作業といった作業が中心だった．
ミニ講義・ミニ演習
中間報告書作成の途中で Web アプリケーションのテストを実行する Selenium IDE の使
い方に関する講義と演習があった．この段階では模擬開発のシステムが完成していなかった
が，ログイン・ログアウト処理のテストが実行できた．
オープンキャンパスの準備
中間報告書提出後，プロジェクトメンバー内で発表者としてオープンキャンパスに参加す
る人を数名決定し，その中で私が決まった．
オープンキャンパス
8 月の初めに，オープンキャンパスがあった．そこではポスターを用いて説明するポス
ターセッションと，実際のシステムを触って体験させるデモに分かれてプロジェクト学習で
実施した模擬開発を説明した．当日になるまで模擬開発のシステムを調整した関係もあった
からか，デモを使った説明はひっかかりもなくできたが，ポスターセッションでは，どこか
ら説明すべきなのかがわからなくなってしまい口が止まってしまった．オープンキャンパス
に向けてポスターを用いた説明の練習をすべきだったと感じた．
納品会
8 月のオープンキャンパスの次に模擬開発で完成したシステムを納品する納品会へ参加し
た．パソコンの画面をプロジェクターに映し，管理者用の画面と面談予約者用の画面につい
て説明できたが，模擬開発の活動について「ヒアリングの回数が少なすぎる」「要望が勝手
に変わってしまっている」といった指摘をいただいた．
• 本開発
本開発では野外劇のチケット予約システムをより使いやすいものへ再構築する．提案工程
から要件定義，設計，実装，テスト，納品までの活動をする．本開発の期間は 8 月中旬から
翌年 3 月末までであるが，期間前に先行して実施した作業がある．
Group Report of 2013 SISP
- 62 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
問題点の分析，第 1 回ヒアリング
模擬開発の途中であったが，5 月に野外劇のチケット予約ページを操作してみて使いづ
らいところや動作の誤りなどを指摘する作業を並行して実施した．その時に予約ページで
XSS（クロスサイトスクリプティング）対策がされていたことがわかったが，範囲外の数値
が入力された場合のチェックに漏れがある所を指摘できた．
また，システムの現状や野外劇の会の要望などを聞き取るために野外劇とのヒアリングを実
施した．まず，ヒアリングの前に質問項目をチームメンバー内で考えた．そして，ヒアリン
グ当日は主に議事録を残す，技術的な質問の受け答えや提示をした．ヒアリングはチームメ
ンバー全員が参加したが，ヒアリングの場所に対して多すぎたといった反省があった．
本開発の準備
納品会が終わった後も，本開発に向けて今後の作業を決めた．サーバを構築する授業の演
習が得意だったことからサーバ管理とデータベースの構築・保守を担当することになった．
9 月に入ると，担当教員と本開発で提案するシステムの相談をした．その後に個人作業に
進み本開発用のサーバを設定した．
その次にスコープを定め，本開発でどのようなシステムを作りたいのかその基礎を固め
た．さらに WBS の企業講師レビューがあり，この計画では無理があると指摘されたため，
チームメンバー全員で WBS の見直しを実施した．スケジュールが遅れていることから，期
限内にプロジェクトが終了するようにできるだけスコープを絞ってチームメンバー全員でス
コープを決めた．
プロジェクト計画書とシステム提案書の作成
プロジェクト計画書とシステム提案書の作成を始めた，私はシステムの概要図やシステム
構成図，さらにシステムを使ったチケット予約の流れを説明する図を作成した．
システム化対象範囲の作成
システム提案書に盛り込むシステム化対象範囲を作成した．その後のチームレビューで
「システムが関わる部分しか表現できていないのでわかりづらい」「チケットの予約から引き
換えまでの全体の流れの図も作るべき」という指摘を受けた．
議事録フォーマットの変更
議事録の書き方について，「見出しをつけるように」といった指摘があった．以前から見
出しを意識して議事録を書いたが，Redmine へ書き込む際に見出しを設定していなかった．
以降の議事録で見出しを設定して書いた．
Group Report of 2013 SISP
- 63 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
第 2 回ヒアリング
野外劇の会との 2 回目のヒアリングは，第 1 回のヒアリングでチームメンバー全員が参加
すると人数が多すぎるという反省を踏まえ，事前に参加者を決めた．参加者に私が選ばれな
かったため，個人の活動としてはなかった．
納品先のサーバを調査
10 月中旬から月末にかけてシステムを納品先となるサーバについて，システムで使われ
る予定の機能が正しく動作するかどうかの検証をした．
ユースケース図のチームレビュー
ユースケース図のチームレビューを実施し，図に不足しているユースケースや矛盾した
ユースケースを指摘できた．
見学者対応
10 月中旬には見学に来た高校生に向けてプロジェクトメンバー全体でプロジェクト学習
の説明や，チームでできるだけ高く紙のタワーを作り上げる作業を通してプロジェクトの運
用力を試すペーパータワーのアクティビティを実施した．高校生がグループに分かれてアク
ティビティをしたのだが，そのグループに対して道具の配布やルールの説明など上手に仕切
ることができた．
画面遷移図と業務フロー図の作成
10 月末に画面遷移図と業務フロー図を作成した．画面遷移図は予約者側と管理者側の画
面遷移図に分かれ，役割を分担した．私は管理者側の画面遷移図を担当した．画面遷移図の
のチームレビューでは，もう一方の予約者側の図について不足している要素や正しくない説
明などを指摘できた．
レビューを受けた画面遷移図を修正した後は，業務フロー図の作成を始めた．私は管理
ページで Twitter/Facebook といった SNS と連携した業務の部分を担当した．
連絡方法に関するルールの決定
11 月に入ってすぐにメンバー間での連絡に不備が見つかり，連絡が取れないという状態
が起きたため，連絡方法に関するルールの決定がなされた．従来の Skype による連絡に加
え，野外劇班独自で作成したメーリングリストで連絡するようにした．
Group Report of 2013 SISP
- 64 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
ユースケース記述の作成
11 月に入った段階では，11 月 9 日に開催されるアカデミックリンク用のポスターは作
成中であったため，ポスターのレビューを実施せずユースケース記述を作成した．ユース
ケース記述は，予約ページ関連, 管理ページ予約状況確認関連, 管理ページメール送信関連,
管理ページ Twitter/Facebook 関連, 管理ページシステム設定関連の 5 つのセクションに分
けて，それぞれ担当を割り振った．私はそのうちの管理ページメール送信関連と管理ページ
Twitter/Facebook 関連を担当した．
Subversion によるバージョン管理
Subversion を用いたファイルの扱いについて，プロジェクトメンバーから，テスト中に
ファイルを勝手に更新しないこと．ファイルの移動・削除が追跡可能にならないので，バー
ジョン管理システムを介さないでファイルの移動や削除をしてはならない．といった指摘を
受けた．
これらの指摘を受けて，オペレーティングシステム標準のファイラー上で直接ファイルの
移動・削除してからコミットするのではなく，バージョン管理システム用のクライアントで
操作するようにした．また，ファイルの更新を伴うコミットでは事前にチームメンバーと連
絡を取るようにした．
アカデミックリンク用ポスターのチームレビュー
ユースケース記述の作成後，アカデミックリンク用ポスターが完成したので，このポス
ターのチームレビューを実施した．ポスター内での配置などデザイン面に関して指摘でき
た．
そしてアカデミックリンクに参加し，ポスターとデモを用いて説明した．事前に想定され
る質問を考えていたのだが，「このシステムが動作するプラットフォームは何か」「PHP で
はよろしくないのでは」といった想定の範囲外で，かつやや技術的な質問をいただいた．
ユースケース記述のチームレビュー
アカデミックリンク終了後は，ユースケース記述のチームレビューを実施した．代替系
列, 例外系列のステップの表記が統一されていなかったので，チーム全員で話し合いの元決
定した．
第 3 回ヒアリング
11 月末に実施される野外劇の方との 3 回目のヒアリングに向けてドキュメントを準備し
た．ヒアリング直前までユースケース記述を修正し，ドキュメントを印刷した．ヒアリング
直前になって体調を崩しヒアリングに参加できなかったが，ドキュメントの準備といった点
では貢献できた．第 3 回ヒアリングは体調不良のため参加できなかった．
Group Report of 2013 SISP
- 65 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
最終成果発表会
12 月の最終発表会に向けて，まず最初にまず何を伝えたいのか大まかな発表の内容を決
定した．次に発表スライドを作成し，スライド作成後にプロジェクトメンバー全員で練習も
実施したが，練習した後でスライドの表現について大量の問題点が見つかった．そしてその
修正が何度も発生したため，スライドの内容が頭に入らないといった事態が発生した．ま
た，他の人の発表を観ると，体を揺らして発表しないこと．という指摘があったので，私の
発表ではなるべく体を動かさないように意識したところ，しっかりと説明するところを指す
ように．といった指摘を受けた．
最終発表会では，スライド，ポスター，デモを用いた発表をすべて担当したが，スライド
の発表途中で内容を思い出せなくなる事態が起きた．スライドの内容を発表直前まで修正し
ないようなスケジュールが必要だと感じた．
最終発表会の後は，最終報告書の大まかな内容である目次や概要を決めた．さらに，ER
図とデータベース定義書のレビューを実施し，システムで取り扱うデータの内容を確認し
た．
振り返り会
12 月最後の活動は企業講師の方々との最後のイベントとなり，プロジェクト学習開始直
後で宣言した学びたいことがしっかりと学ぶことができたかを踏まえてプロジェクト学習を
振り返った．初めはナカナカ学びが思い浮かばなかったが、プロジェクトでの活動を最初か
ら思い出すことにより，イベント後半でたくさんの学びが生まれた．
• 個人の学び
技術的な面では，フレームワークである CakePHP を用いた開発技術やサーバ上へデプロ
イするときの注意点を習得することができた．また，Web アプリを開発する上で XSS 対策
の一つであるサニタイジングを講ずることができた．さらに，Subversion を用いた共同作
業時のバージョン管理について，バージョン管理システムの使い方のみならず，バージョン
管理されたファイルの扱いについていくつかの注意点を学んだ．
プロジェクト学習の過程で，個人個人ごとに考えていることが違うため，進捗報告や仕様
の提案などで自分の伝えたいことが伝わらないと感じ，メンバー間の情報共有についての重
要性を認識した．次に，プロジェクトメンバー各自が考えていたことをしっかりと図に残そ
うと提案したところ，理解が進んで作業をしやすくなったため，良い情報共有の方法を提案
できた．
その一方で，プロジェクト学習もしくはそれ以外で発生したタスクを消化することが中心
になってしまい，長期的にプロジェクト学習を通じて成長したいことが意識できていなかっ
た点があった．
（※文責: 吉田 匡孝）
Group Report of 2013 SISP
- 66 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
5.5
金 善 禹
• 体制決定
プロジェクトのはじめの活動として 15 人のメンバーを野外劇の 5 人とイベント班の 10
人に分けることにした．私は実際に野外劇という公演のためにシステムを作ってそれを使っ
てもらえるという点に引かれて野外劇班のメンバーとしてプロジェクト授業を受けることに
した．野外劇班のリーダーは花田が勤めることになった．
また，Subversoin と TortoriseSVN を使ってチーム間でどうファイルを共有する方法を
学び，使うときのルールを決めた．
• CakePHP 勉強会
これからの開発のために必要な PHP のフレームワークである CakePHP の勉強会を行っ
た．CakePHP はプロジェクトの TA の方に教わった．勉強会ではまずいくつかの例題を
TA の方と一緒に解いて，CakePHP の機能を理解した後，出題された課題を各自が解いて
TA の方が確認するという方式で進んだ．私は当時日本語が上手ではなかったので聞き逃す
ことが多く，プログラムの記述や TA 方の説明等，授業についていけない事が多かった．し
かし，自分が遅れたとき TA の方や隣のメンバーができるだけ助けてくれたので，何とか最
低限ついていくことができた．
• 前期プロジェクトキックオフ
アイスブレイクという制限時間内にペーパータワーをどれだけ高くすることができるかを
グループごとに競った．計画を立てて決めた時間内にどれだけの成果を挙げられるのかを経
験するきっかけになった．まだ親しくないメンバーそれぞれの特性や話し方を知る機会も
なった．私たちのチームは 3 個のグループの中で最下位になった．その原因としては，作業
をする前に役割分担を決めたが各自の作業の仕方を統一してないため，作ったものがそれぞ
れ違ったのが問題だった．また，頭の中で想定したより時間が足りなくて，立てた計画が甘
かったのも問題の 1 つだった．これから進むプロジェクトに活かせる大事な教訓を得る事が
できた．
• 後期プロジェクトキックオフ
最初の授業では企業講師の方が訪問して，今までの進捗状況を確認して，これからのプロ
ジェクトの方向性を考える機会を得た．私たちがシステムを作ることにあたって重要なス
コープはなにかを話し合って決めた．また，企業講師の方に会議の進め方と仕事担当の決め
方等，チームとしてうまく進めていくためのアドバイスをもらった．
• 模擬開発
現状分析のためのヒアリング
6 月上旬に依頼者がどのような要望があるかを聞くために 1 回目のヒアリングを行った．
模擬開発での依頼者は奥野先生に担当していただいた．模擬開発の依頼内容は，先生と学生
の面談予約を支援するシステムだった．私たちは依頼者とのヒアリングで洗い出した要望を
Group Report of 2013 SISP
- 67 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersチーム内で話し合った．
要件定義工程
1 回目のヒアリングで聞いた依頼者の要望を基にしてシステムに必要な機能を洗い出し
た．そして，その機能をまとめて可視化するため，ユースケース図を作った．そのユース
ケース図の機能の詳細についてはユースケース記述としてメンバーと何箇所か分けて作っ
た．それを元に，システムの仕様を話し合ほぼ決めて要件定義書としてまとめた．私はこれ
までシステム開発に関して学んだことがなかったため，ずいぶん戸惑ったが他のメンバーの
助けもあり何とか作業を進めることができた．それから，各作業にそれぞれ担当を分けて設
計を進む事になった．
TV 会議による企業講師のレビュー
開発を進めていく中で，企業講師による TV 会議が行われた．TV 会議ではまず，企業講
師にチームの進捗状況と成果物を説明してそれらに関してのレビューをもらった．成果物の
中で，画面遷移図が細かくて見やすいという意見をもらった．しかし，成果物の中でチーム
での共通認識があるのかという指摘もあった．また，チームの作成物同士の整合性を取るた
めにいくつかのアドバイスをもらった．TV 会議で私が作業した部分があったが，私は日本
語で誰かに説明するのが怖くて自分の作業にも関わらず他の人に発表を任せてしまった．発
表が苦手なら，練習して自分の部分を自分でちゃんと説明するべきだった．
要件確定のためのヒアリング
6 月下旬にはシステムの仕様をほとんど決めて依頼者に確認してもらうために 2 回目の
ヒアリングを行った．模擬開発なので，一般的なヒアリングとは違い先生や TA の方にシス
テムに関してのいろんなアドバイスをもらうことができた．最初のヒアリングでは出た要望
を全部機能としてシステムに取り入れるのは難しいと判断したので，実装可能な機能を再度
洗い出してそれを依頼者に確認してもらった．先生方には作業が遅れることは仕方ないとし
てその対応策をどうとるかを学ぶかが大事だというアドバイスをもらった．そこで，これか
らは作業にきちんと優先順位を付けてそれに従い作業を進めることをチーム内で決めた．
設計工程
画面遷移図を作って利用者がどのようにシステムを使うかにたいしたメンバー間の整合性
をとるようにした．また，利用者が作業するときシステムがどのような動きをするかを判断
する資料として業務フロー図を作った．
実装工程
中間発表会である程度まで作ったシステムを見せるため，急いで作業を進むようになっ
た．私も一緒にしたが，実装の実力が劣るため，大きく役に立つことができなかった．シス
Group Report of 2013 SISP
- 68 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersテム実装の個人的な勉強が必要だということを痛感した．そして，中間発表会のポスターを
作る事に取り組みすぎて実装の練習があまりできなかったのも問題点だった．
中間発表会
7 月には本格的に中間発表会に向かって準備を始めた．3 つのグループをスライド班とポ
スター班に分けた．私はポスター班として中間発表会の準備を進めた．ヒューマンインタ
フェイスの授業で Illustrater の使い方を学んだので，ポスターを作るのに役に立てる考え
た．ポスター班内では 3 人ずつ 2 つのチームに分かれてポスターを 1 枚ずつ作って計 2 枚
を作る事に決めた．私のチームでは，模擬開発に関してのポスターを担当した．私はポス
ターのデザインと図を作ることにして，他の二人は文章を担当し，作業を進めた．ポスター
のデザインは初めてなので載せる内容の選択や分かりやすい図の作り方等に迷う事が多かっ
たが，チームのメンバーや TA，先生のアドバイスをもらって何とか自分の納得のいくポス
ターを作ることができた．
中間発表会では記録係を担当した．スライド発表でもらった質問をまとめて，発表者がど
のように返答したかをできるだけ聞き取って書くことにした．しかし，日本語が上手に聞き
取れなくて聞き流したことが多かった事から，自分の言語能力がまだ足りないのを感じた．
発表練習と同時にシステムの実装も行った．しかし，私がポスターや他の作業に時間をか
けすぎたため実装にはほとんど参加できず，他のメンバーに全部任せてしまったので自分が
システム方向では成長できなかったという問題があった．積極的にシステム関係に参加して
CakePHP の勉強をしておくべきだった．これが原因で作業の状況がわからなくなり，今後
の作業に影響を与えた．
• 脱走と復帰
8 月には私はプロジェクト学習を受けることをあきらめることになった．試験のストレス
に加え食中毒にかかってしまいやけになってしまったのが原因だった．しかし，あくまでも
これはきっかけで 1 番の問題は自分の頑張りや責任感が足りなかったことである．チームと
の連絡を切ってしまったのも問題の 1 つだ．まず，自分がだめだと感じた時には自分で抱え
るのではなく他のメンバーや頼りになる人に相談するべきだった．チームとして他の人に頼
ることの大事さと自分の精神的な面で足りない点を確認できる機会になった．
9 月下旬から本格的にプロジェクトの活動が始まる前にまず，プロジェクト担当先生の
方々を訪問して相談し，プロジェクトに参加する事を許可してもらった．先生方からはチー
ムのメンバーときちんと話し合う事，連絡を切らないこと，困ったことがある時にすぐ相談
することの大事さを教えてもらった．また，怒ることはなく，むしろこれから頑張ればいい
と励ましてくださった．チームのみんなも自分勝手に戻った自分を責めずにチームとして受
け入れてくれた．
• 本開発
Group Report of 2013 SISP
- 69 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
第 1 回ヒアリング
5 月下旬に初めて野外劇の会へヒアリングを行った．初めてのヒアリングのため，チー
ム全員で訪問した．ヒアリングの目的は依頼者の要望がどういうものかを洗い出すことだっ
た．また，現在運用されているシステムのどのような点が不便なのかも一緒に聞いた．自分
たちが想定している問題点や要望とは異なっている点が多かったため，実際の依頼者との連
携が大事だということを学んだ．また，ヒアリング時の記録係や発表の担当者など，作業分
担が正確に分かれなかったり映像や写真のデータを残してなかったりという問題があったの
で，次のヒアリングに生かすことを反省会で決めた．
システム提案工程
10 月では 5 月に行ったヒアリングを基にしてシステム提案書の作成に入った．チーム内
で作るシステムに対して共通の認識を持つためにプロジェクト計画書も一緒に作成した．依
頼者の要望を反映してシステムに必要な機能を話し合って決めた．そして，その機能をユー
スケース図として完成させた．しかし，依頼者に文章と図だけでは説明しづらいという意見
をもらい安藤がプロトタイプを作ることになった．
私は画面遷移図を作ったり，Illustrator を利用してスケジュール表を作ったり，文章の
チェックをした．しかし，言語的な問題があって文章的には役に立てなかった．しかし，画
面遷移図は模擬開発に作るのを見ていたのでメンバーに助けてもらいながら進めることがで
きた．しかし，業務フロー図を作るとき手助けができなかったので，学習不足を痛感した．
デザインに関してもいくつか学ぶことができた．理由もなく色をたくさん使って図を作る
のはむしろ見る人が混乱するということを分かった．また，日本語で文章を書くときはどの
ような形式でまとめるのがいいか学ぶいい経験になった．必要な情報を最低限選んで，読む
人に見やすい図を作るコツがわかった．
第 2 回ヒアリング
10 月下旬にシステム提案のため，2 回目のヒアリングを行った．システム提案書とプロ
トタイプを使ってリーダーとプロトタイプ作成者が説明したが，プロトタイプのように目で
見えるものがあるので非常に説明が分かりやすかった．私は記録係を担当して，依頼者と話
し合った内容を記録して写真や映像を取った．
アカデミックリンク
10 月下旬からアカデミックリンクの準備をどのようにするかの話し合い始めた．私は，
中間発表会でポスターを作った経験を活かしてポスターを作ることになった．リーダーの花
田と話し合いながら作業を進め，他のメンバーは本開発の作業を進めることになった．
11 月上旬には本格的にアカデミックリンクの準備を行った．私はプロジェクト計画書を
主に参考して，ポスター作成に本格的に取り掛かった．ポスター作成で一番困ったことは，
アカデミックリンクが一般の人に向けて説明するということだった．ICT に関しての基本
知識がない方が多くなるので今まで作成物に乗せている文面では分かりづらいということ
Group Report of 2013 SISP
- 70 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersだ．そこで，メンバーや TA，先生方に意見をもらい，文章を最小限に減らし，大事な部分
だけ残し，分かりやすく図や写真を載せ，本プロジェクトに関係ない方も気軽に読んでもら
えるようにポスターを作った．そして，他のメンバーにそのポスターで発表してもらい，発
表しやすいか意見を聞いてポスターの構成に反映した．実際の発表では，ポスターと安藤が
作ったプロトタイプを使って説明を行った．私が説明担当する時は，人が少なくてあまり発
表できなかったが，色々な大学で多くの発表をしていたのでいい経験になった．特に韓国語
の学習方法についての研究は韓国人の私にとって興味深いものだった．
要件定義工程
アカデミックリンクが終わってから，野外劇班は要件定義書やプロトタイプの作成，最終
成果発表会の準備に取り組んだ．私は要件定義書に載せる図と最終成果発表会で使うポス
ターを担当することになった．中間発表会とは違い，野外劇班の 5 人しかないのでポスター
はほとんど私 1 人で作ることになった．中間発表会とアカデミックリンクでポスター作成に
関してはある程度自信がついたので今回は以前と比べて円滑に作業を進めることができた．
ポスターの構成に関してチームメンバーと TA の方に意見をもらって作成し，文面も他のメ
ンバーの助けてもらって完成することができた．自分の納得のいく成果物ができたので，自
分も成長した点があると感じた．
一方，システムの設計や要件定義書ではあまり役に立ってなく，そもそも作成にほとんど
参加してないのでこの点では成長できなかった．他の作業にも目を配って自分にもできそう
な作業には参加するべきだった．
また，メンバー間で仕様の相違があり，各自が作った成果物に不整合が出たので，それを
直すために時間がかかってしまった事があった．メンバー間の意見の食い違いが 1 番の問題
だった．そこで，対策としてチームとして共通認識を持つためのルールや手段を決めた．
第 3 回ヒアリング
11 月下旬に私たちが決めたシステムの詳細に対して合意を得るため，3 回目のヒアリン
グを行った．以前の 3 回のヒアリングの経験があって今回は円滑にヒアリングを進行する事
ができた．システム提案書とプロトタイプを使って説明を行ったが無駄な説明を省いて依頼
者に必要な点を出して伝えられた．私は記録係りとして文書や写真映像を撮って修正し，レ
ポジトリにデータをあげた．写真は成果発表会とポスターに使うのを想定し，それに合わせ
ていろんな観点で撮るようにした．
最終成果発表会
12 月上旬には最終成果発表会に向かってスライドとポスタの修正と発表練習を主に行っ
た．私は始めは野外劇ポスターの作成を完了していたため要件定義書の修正を手伝ったが，
途中でメインポスターと模擬開発のポスターを修正する必要が出てきて，急いで修正した．
最初に計画を立てるとき，メインと模擬開発のポスターの修正にかかる期間を考慮するべき
だった．イベント班のポスターも少し遅れがあったのでメインと模擬開発のポスターの全体
的な修正は私が担当して，英訳を後でイベント班にしてもらう形で作業を進めた．
Group Report of 2013 SISP
- 71 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers 最終成果発表会では野外劇の活動を発表した．日本語での発表にはなれていなく，言葉が
出なかったり抑揚を間違ったりしたが最後まできちんと発表することができた．私が世話に
なっている知り合いもわざわざ見に来て下ったので自分にとって非常にいい経験になった．
アンケートの内容もいい評価が多かったのでやり遂げた達成感も感じることができた．
現状と今後の予定
最終成果発表会が終わってからは本格的に設計が始まった．野外劇班では ER 図を作り，
他の作成物を修正する作業が行われた．同時に最終報告書のための作業を始めた．まず，目
次と各項目の担当者を決めた．最終報告書の作業が終わり次第，設計の作業に参加する予定
である．
• 個人の学び
私がチームで一番貢献したのはデザイン的なことが多かった．Illustrator でポスターや図
などを作ることができたので，これに関して多くのものを得た．自分が得意とする分野では
なかったが，作業が進むと同時にいくつかのコツや知識，技術を学ぶことができた．
また，日本語的にも著しく発展したと思う．授業の最初は日本語で文書を書くことは考え
られなかった．しかし，今では相当量の長文も書けるようになった．今でも，文章的な面で
他のメンバーに苦労をかけるのは相変わらずだが，以前よりは全然よくなった．一般会話で
使う日本語だけではなく専門用語も多く覚える良い機会になった．
システムがどんな過程を踏んで開発するのかを経験する事ができた．私も韓国でシステム
に関して学んだが，依頼者から依頼をもらって各工程を踏んで作業するのは初めてだった．
この経験は後に会社に入っても活かせるし，入社する時の自己 PR でも役に立てることがで
きる．
最後にチームとして作業を進むことで大事なものが何かを学ぶことができた．チーム内で
の意見交換の仕方や話し方等を学んだ．グループメンバは個性があるので，その個性に合わ
せて話し方を変える必要があることを分かった．自分の意見がある時，会議でどのように自
分の意見をいつ出してどう説明するかを身につけた．
（※文責: KIM SUN WOO）
Group Report of 2013 SISP
- 72 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
第6章
成果と学び
この章では，本プロジェクト中で得られた成果と学びについて説明する．
（※文責: 齋藤 尊）
6.1
キックオフ
企業講師の方からプロジェクトにおける開発工程や，役割分担が重要になるなど，プロジェクト
をどう進めていくと良いのかを学んだ．アイスブレイクで各グループでペーパータワーを作成する
ことによって，メンバーの先頭に立って物事を進めるタイプ，一歩引いて進行のサポートに回るタ
イプなどの問題解決におけるグループメンバーごとの特性を知る事ができた．チームワークがうま
くいかなかった経験で役割分担の大事さを体験した．また，共同作業をみんなでし，お互い意見を
話し合う事によって私達がチームだという認識を持つきっかけになった．
（※文責: KIM SUN WOO）
6.2
CakePHP 勉強会
CakePHP によるプログラミングを学ぶことで模擬開発，本開発におけるシステム実装の知識を
得た．勉強会は 4 回に分けて行われ，それぞれの回で，Form ヘルパーの使い方，データベース利
用の基本，バリデーションの利用，テーブル連携について学んだ．さらに各回で簡単な Web アプ
リケーションを実装する演習を行い理解を深めた．演習ではチェックボックス，ラジオボタンと
いったさまざまなフォームの作成，データベース操作といった内容を取り扱った．最後には，これ
らの機能を持った簡単なシステムを開発した．勉強会を通して，Web アプリケーションを開発す
る技術を習得することができた．さらに，メンバー間での教え合いの様子も多く見られ，チーム
ワークの向上にもつながった．
（※文責: 花田 洋貴）
6.3
Redmine によるプロジェクト管理
タスク管理や議事録管理，情報共有のために Redmine を用いている．しかし，チケット発行や
Wiki の使い方などの運用上のルールがなかったために，具体的なタスク管理が出来ていなかった．
そのため Redmine 運用ルール作成班を設け，運用ルールを作成した結果，担当している学生や現
在の進行状況をプロジェクト全体で共有できるようになった．このことから，タスク管理ツールに
ついても具体的な運用ルールを設けることが，チームでの開発では大切なことであると学んだ．ま
た，活動の議事録は Redmine のフォーラム機能を利用して，管理を行った．議事録についても運
用ルールを定めることで，全体の議事録やグループごとの議事録，発表準備時の議事録などを上手
く整理して管理できるようになり，情報共有が円滑に進んだ．
Group Report of 2013 SISP
- 73 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers 後期の活動では，Redmine の管理担当をチーム内で決めることで，グループ全員の進捗管理を
行った．また，WBS を参照してプロジェクトの進捗ごとに必要なチケットを用意するという工夫
を行った．しかし，具体的な活動内容をチケット担当の活動に定めていなかったため，メンバー間
がチケット更新が滞ってしまった．この問題を解決するため，Redmine のフォーラム機能等を用
いて，メンバーのチケット更新を促した．そのため，グループの一人だけではなく，メンバー全員
が進捗の報告をしっかり行うことが必要であると改めて認識した．
（※文責: 齋藤 尊）
6.4
Subversion によるバージョン管理
Subversion を利用することで複数人でバージョン管理をすることができた．うまく作業分担が
できていなかったために，コミット時にコンフリクトを起こしたり，うまく使いこなさないと，ど
のファイルが最新版なのか分かりにくくなってしまったりとバージョン管理の難しさが分かった．
チーム全体のリビジョン番号が 1200 を超え，その中で，誤って他のメンバーの成果物を消してコ
ミットしてしまったり，コミットとアップデートを間違って行ってしまうなどの問題が発生した．
しかし，担当箇所をはっきり決めることや復元を行うなどの対策を行い，問題の解決を行うことが
できた．こういった問題を解決していく中でバージョン管理と Subversion についての理解を深め
ていくことができた．
（※文責: 花田 洋貴）
6.5
テレビ会議によるレビュー
6 月 12 日に企業講師の方々にグループ A・B・C それぞれの班が行った模擬開発の進捗レビュー
をいただいた．その結果として「要求定義書のビジネスプロセスを幾つかに分けたほうが良い」な
ど，ユースケース図や要求定義書，画面遷移図などをより良くする指摘をいただいた．また，ユー
スケース記述や業務フロー図作成の際に各メンバー全員の書式が揃わないことについて改善案を
伺ったところ，「いきなり全員で作業を分担するのではなく，まず誰かが叩き台を作ってから作業
分担を行うほうが良い」などレビュー後のチーム開発の状況をより良くするためのアイデアをいた
だいた．
（※文責: 齋藤 尊）
6.6
企業講師レビュー会でのレビュー
企業講師の方々に実際に未来大学にお越しいただき，UML や設計プロセスの問題点を指摘して
いただいた．
「設計においては情報共有が重要であり，そのために Redmine を用いてしっかりとタ
スク管理を行うことが必要」といった，本開発で活かせるノウハウを学んだ．
さらに，模擬開発で得た知識をどう本開発に活かしていくのか，どういったシステムの構築を考
えていけばいいのか一緒に協議していただくことで，チームの方針を見直すことができた．加え
て，中間発表会のスライドについてもレビューしていただいた．その結果，スライドの全体の流
Group Report of 2013 SISP
- 74 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customersれ，スライド 1 枚の情報量などについて指摘をいただき，よりよいスライド作成につなげることが
できた．
（※文責: 安藤 大岳）
6.7
中間発表会
中間発表会での発表資料を作る上で，限られた発表時間やスペースでこれまでのプロジェクト全
体の成果をスライドやポスターでどのような見せ方をするかを学んだ．また，何が重要な情報で何
がそれほど重要ではないのか考える事で，情報を見極めることを学んだ．発表場所がミュージアム
に決定したことで，模擬開発で作成した各グループの成果物をどのように展示し，どこでスライド
発表を行い，ポスターをどこに展示するかを教員の方々のご協力をいただき決定することができ
た．発表練習を重ねることで，発表資料を読むのではなく，相手に聞いてもらえるような発表がで
きるように相手の方を見てわかりやすく発表する方法を学んだ．中間発表会当日の発表中にプロ
ジェクタが破損し，代わりのプロジェクタを用意していなかったことから，リスク管理の重要性を
学んだ．
発表のフィードバックを集計した結果，発表技術点数の平均が 6.8 点，発表内容点数の平均が
6.5 点という結果が出た．発表技術コメントとして，「話している内容がとてもシンプルで分かり
やすかった」や「提案についてのスライドの図があるおかげで全体の提案や現状などがわかりまし
た」などのコメントをいただき，発表技術コメントとして，「問題点，それに対してのアプローチ，
解決方法が明確でプロジェクトの方針が良くわかった」や「フィードバックをもらう仕組みが明示
されていないので問題点が見えなかった」や「問題を挙げるところでも図などがあるとよりよかっ
たです」などのコメントをいただいた．これらの結果よりこちらが伝えようとしていることが，な
かなか相手に伝わらない事を学んだ．更に相手に伝わる発表をするために発表の練習にもっと時間
を割くべきだった．
（※文責: 安藤 大岳）
6.8
オープンキャンパス
8 月 4 日に行ったオープンキャンパスでは，主にシステムのプロトタイプを用いたデモを行っ
た．その経験によって，デモを使ってどのように説明をしたら良いのかを学ぶことができた．しか
し，パネルセッションとして発表を行っていた際，ただパネルを読むだけではいけないと考えてい
たのだが，逆にそれを意識するあまり発表で言葉に詰まることが複数回あった．そのため，パネル
セッションを行うときには事前に展示物の内容をしっかり把握し，それを踏まえてどのような発表
構成で発表を行うのかを事前に考えておき，練習をする必要があるのだと学んだ．
また，デモを説明するために必要そうなものを印刷して展示していたが，実際に使った場面がな
かった．そのため，発表準備の際にも，想定している発表構成にあわせた物品の準備が大切である
ということを学んだ．
（※文責: 齋藤 尊）
Group Report of 2013 SISP
- 75 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
6.9
札幌オープンキャンパス
9 月 20 日に，札幌市地下歩行空間で本プロジェクトの紹介を行った．高校生を主な対象とし，本
プロジェクトの現状と今後の展望を説明した．高校生に対して説明する際は難しい言葉を使わず，
わかりやすい説明をするように努めた結果，本プロジェクトの活動に興味を持ってもらうことが
出来た．また，説明を聞きに来ていただいた企業の方から，本システムを汎用化することで他のチ
ケット予約システムとして使用できるかもしれないという今後の展望についてアドバイスをいただ
くことができ，本プロジェクトを客観的に見ることができる良い機会となった．
（※文責: 花田 洋貴）
6.10
後期キックオフ
前期と同じく後期の最初にも企業講師に現状を報告し，本開発に必要なアドバイスをもらった．
企業講師の方による，「段取り力」の講義を受けてこれからのプロジェクトの計画を立てる時に活
かす事ができた．
また，チームの内で本開発を円滑に進むためのルールやスコープを話し合い，それに関しての意
見を企業講師の方からもらった．作業に優先順位をつけて活動するのが効率的で問題が発生した時
対処しやすいということを学んだ．
（※文責: KIM SUN WOO）
6.11
アカデミックリンク
11 月 9 日に開催されたアカデミックリンクに参加した結果，入賞は逃してしまったものの，来
場した方々から本プロジェクトと本システムについて様々な御意見・御質問をいただくことができ
た．その際，いただいた御質問の中で，システムを修正するのか．それとも一から作り直すのか．
や，この活動は今年度から始まったものなのか．といった質問は，事前に回答を用意できていた．
しかし，何人まで予約が可能なシステムを想定しているのか．管理 TOP ページのプロトタイプ通
り，ボタンを大量に並べるのか．それともラジオボタン等を利用するのか．といったシステムの開
発に関係があるが，今までは想定していなかった内容を指摘していただいた．これらの質問から，
システムの一部機能の UI やシステムでどこまでの量の予約を扱うのか等，些細と思えるようなこ
とでも依頼者との協議を行って決める必要があるのだと改めて実感できた．これらのアカデミック
リンクの際に回答を用意できていなかった内容は，要件定義の際に野外劇の会への追加の質問項目
として，ヒアリングを行った．また，他のシステムと統合した，大規模な観光用システムを構築し
てみてはどうか．野外劇以外のチケット予約にも対応した汎用的な予約システムにしてはどうか．
等といった御意見をいただいた．そこから，我々の活動は今年度以降にも続けることのできる検討
事項があることを知ることができた．
（※文責: 齋藤 尊）
Group Report of 2013 SISP
- 76 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
6.12
最終成果発表会
最終成果発表会の際の発表資料作成の際，前期の中間成果発表会の際に学んだことを活かし，よ
り発表を見に来ていただいた方に分かりやすく，私たちが伝えたいことを正確に伝えるための発表
準備を行うことができた．発表用スライド・ポスター双方とも，発表内容を分かりやすくするため
の構成を検討することができるようになった．また，プロジェクトの目的をどのように達成したの
かを効果的に伝える方法の検討を行うことができた．発表用会場の設営を行う際にも，中間成果発
表会の学びを活かし，効率の良い設置や見せ方の工夫を行うことができた．
また，発表評価シートの評価を集計したところ，発表技術点数の平均が 7.8 点，発表内容点数の
平均が 8 点となった．中間発表会の際には発表技術得点の平均が 6.8 点，発表内容点数の平均が
6.5 点だったため，最終成果発表会では双方 1 点ほど上昇した．そのため，プロジェクトメンバー
全体の発表技術や発表内容がより良くなっていることが分かった．また評価シートのコメントか
ら，発表内容から，活動に熱意が感じられた．かなり発表練習をしていることがわかった．ICT や
地域貢献というテーマが良く，計画性もしっかりしていると感じた．という御意見をいただくこと
ができた．しかし，デモをしてほしかった．スライドとデモのどちらを見ればよいのか分からな
かった．という意見もあったため，スライド発表を見ていると，作成したシステムを見てもらう時
間がなくなってしまうという問題が分かった．そのため，発表の際には来た人がどのように発表
ブースを見るのかも考えた発表構成を行わなければならないことを学んだ．
（※文責: 齋藤 尊）
6.13
振り返り会
12 月最後の活動日に実施され，プロジェクト全体を通して前期キックオフ・イベントで定めた
目標を達成できたかを振り返るイベントであった．野外劇班では，開発工程，メンタル，プロジェ
クト学習について，スケジュール管理，コミュニケーション，プレゼンテーション，留学生の活動
といった項目に分け，これらについてそれぞれ自身で学んだこと，これから今後に向けてどうすれ
ばよかったのかを振り返った．振り返り会の結果，以下の学びが得られた．
• 良かった事
・システム開発のプロセスを正式な手順にしたがって体験することができた．
・他のメンバーと話し合いながらプロジェクトを進む過程で円滑に意見を交換するためのノ
ウハウを習得できた．
・TA や先生，企業講師の方からもらったレビューや意見をチーム内で話し合い，開発の方
向性を決めて作業を進むようになった．
・仕事に優先順位をつけて作業を進むことによって効率的に作業を進めるようになった．
• 悪かった事
・プロジェクトの進行が遅れた時の予備の時間も考えてスケジューリングするべきだった．
・仕様決定時にレビューが不足していると最良とはいえない状態だった．
Group Report of 2013 SISP
- 77 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers・発表スライドを何度も修正すると，練習のための時間が不足してスライドの内容が頭に入
らなくなって，最終的に発表当日で非常に困った．
（※文責: 吉田 匡孝）
6.14
模擬開発
成果
グループ A は模擬開発によって，以下の成果物を得ることが出来た．
• 要件定義工程
・用語集
・ヒアリング質問項目
・ユースケース図
・ユースケース記述
・画面遷移図
・業務フロー図
• 設計工程
・データベース・テーブル定義書
・ER 図
・要求定義書
・画面モックアップ
• 実装工程
・インデックス命名記述
・面談予約管理システム
学び
模擬開発では上流工程の際にメンバー全員が分担した作業を一斉に行うのではなく，まず誰か
一人が叩き台を作ってから他のメンバーも設計を始めたほうが，作業をする上で効率が良いという
ことを知ることが出来た．また，実装作業の時間が足りなくなってしまったことから，正しい見積
もりと作業計画を行うことが大切だと理解した．加えて，メンバー内で実装に手間取っているのに
報告を怠っていたために遅れが生じる事があった．そのためメンバー各自が自身の活動についてこ
まめに報告をすることで，情報共有を漏れなく行わなければならないと知った．
また，模擬開発で制作したシステムの納品会の際，メンバーのスケジュールが合わずリーダーが
出席できなかった．そのため，最も実装を多く担当したメンバーが質疑応答を行うこととなった．
このことから，事前にメンバーのスケジュールをしっかりと把握し，それぞれがどのような事がで
きなければならないのかを考える必要があることが分かった．
（※文責: 齋藤 尊）
Group Report of 2013 SISP
- 78 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
6.15
本開発
既存システムの問題点の分析
函館野外劇のチケット予約システムの現状を知るため，メンバー全員で利用してみることで問題
点を探った．その結果，年齢やメールアドレスの欄で不適切な入力を受け付けてしまうという問題
点を発見した．
ヒアリング
5 月 27 日に函館野外劇を主催している野外劇の会へのヒアリングを行った結果，現在の野外劇
の会の体制やサーバ移行の必要性，予約システムの利用者について知ることが出来た．その結果か
ら，決済システムが導入できるか否かや外国語対応版システムの作成等といったことについて，検
討しなければならないと判明した．しかし，ヒアリングを行っている最中，私たちのプロジェクト
では関わり難い話に脱線することが多々あり，また漠然とした質問をして野外劇の会の方を困らせ
てしまうといった場面があった．そのため，今後ヒアリングを実施する際には，自分たちが取り組
める内容をしっかり確認した上で，相手方にも何を答えればよいのか分かりやすい質問をしなけれ
ばならないと理解した．2 回目のヒアリング以降は，提案したシステムのイメージを見せるために
プロトタイプを作成し，合意がとりやすかった．
アカデミックリンク，最終成果発表会
本開発中のアカデミックリンクや最終成果発表会といったプロジェクトの成果を発表するイベン
トでは，相手に伝えたいことを伝えられるように事前に大まかな内容を決定することで，発表に用
いるポスターやスライドの作成が楽になった．しかし，スライドの作成が発表のための準備にも影
響した．最終成果発表会では発表までの余裕がなくなる状態までスライドを修正したため，スライ
ドの内容が頭に入らないといった声があがった．スライド完成後，どれくらいの指摘を受け修正点
が発生するのかを予測するのは難しいが，余裕を持ったスケジュールを立てるべきだと理解した．
本開発全体
本開発全体での反省として，後期に入ってくると他の授業や課題でメンバーの時間的な余裕がな
くなったので，課題が多すぎて時間がなくなるというリスクを考慮し，余裕をさらに設けてスケ
ジュールすべきと理解した．
また，成果物のレビュー後に出た指摘箇所についてチーム内で修正の方針を決めていなかったた
め，不要な修正や不整合が起きてしまった．これを受けてチーム内で修正方針を決めてから，修正
作業を開始するように対処した．
さらに，修正後の内容確認とチーム内での情報共有が十分でなかったため，成果物間の不整合が
発生した．この点については成果物の確認をする担当を設け，他の成果物との整合性の確認を実施
した.
（※文責: 吉田 匡孝）
Group Report of 2013 SISP
- 79 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
第7章
おわりに
本グループは，本プロジェクトの ICT で地域をデザインするという目的を達成するため，函館野
外劇のチケット予約システムを再構築することで，お客様に使って頂けるようなシステム開発技術
を学びながら，野外劇の会が予約システムをより管理しやすく，チケット予約者も容易にチケット
が予約できるように活動を行ってきた．現在は 2013 年 11 月 30 日の野外劇の会との打ち合わせに
よって，サーバの保守管理を除き，要件定義書に合意をいただいた．本グループが作成するシステ
ムは一般のレンタルサーバ上で構築し，株式会社エスイーシーの保守のもと，野外劇の会が 2014
年度の函館野外劇公演の際に利用していただくことを想定している．そのため，今後はサーバの保
守管理についての合意を頂き，3 月中旬の納品に向けて，設計，実装を行うことを予定している．
（※文責: 齋藤 尊）
Group Report of 2013 SISP
- 81 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
謝辞
本グループがプロジェクトの目的を目指すにあたって，多くの方々にお世話になりました．ここ
に深く感謝の意を表します．
企業講師の高森満様，木下実様にはたびたびお越し頂き，本グループの活動や成果物に対して熱
心な御指導を賜りました．また，アカデミックリンクの発表準備の際には，発表を聞く人がどのよ
うな人物なのかを考える必要があるという旨を御指導していただきました．ここに感謝の意を表し
ます．
本プロジェクトの担当教員として，チケット管理に関する講義やバージョン管理について御指
導して頂いた大場みち子教授に感謝致します．奥野拓准教授には，模擬開発の際のお客様として御
指導していただいたほか，本開発でも様々な成果物のレビューをして頂き，ありがとうございまし
た．また，伊藤恵准教授には，Redmine や Subversion の環境構築や，試験工程に関する講義や演
習を開いてくださいました．深く感謝申し上げます．
また，文書作成の際にアドバイスをして頂いたり，成果物のレビューをして頂いた TA の皆様に
感謝申し上げます．
最後になりますが，本グループの活動において，度重なる話し合いを快く引き受けてくださっ
た NPO 法人「函館野外劇」の会の里美泰彦様，住山省悟様，株式会社エスイーシーの佐藤眞紀夫
様，相田紘人様には，感謝の言葉もありません．また，NPO 法人「函館野外劇」の会の里美泰彦
様におかれましては，本グループが御提案したチケット予約システムに対し，快い賛同を頂き，誠
にありがとうございます．本グループ一同，心より感謝申し上げます．
（※文責: 齋藤 尊）
Group Report of 2013 SISP
- 83 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
付録 A
新規習得技術
• プロジェクトマネージメント
• 開発技術
・UML
・フレームワーク
・開発言語
• システム環境構築
• テスト技法
• 発表技術
• ドキュメントおよび報告書作成技術
Group Report of 2013 SISP
- 85 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
付録 B
活用した講義
• ソフトウェア設計論 I
• ソフトウェア設計論 II
• システム管理方法論
• 情報マネージメント論
• プリンタ講習会
• TeX 講座
• 科学技術リテラシ
• データベース工学
• プロジェクトマネージメント
• ヒューマンインターフェース
• 情報機器概論
Group Report of 2013 SISP
- 87 -
Group Number 3/A
Regional Design with ICT -Construction of Useful Systems for Customers-
参考文献
[1] 長崎観光/旅行ポータルサイトながさき旅ネット, http://www.nagasaki-tabinet.com/.
[2] 東京の観光情報サイト トーキョーブックマーク, http://tokyobookmark.net/.
[3] 非機能要求グレードの研修教材と利用ガイド [活用編] を公開：IPA 独立行政法人 情報処理推
進機構, http://www.ipa.go.jp/sec/softwareengineering/reports/20130311.html
しょうだ つ
や
の
[4] 掌田津耶乃. CakePHP 2.1 による Web アプリケーション開発. 秀和システム, 2012.
すずきけんじ
あんどう けんいち
や ま だ なおあき
や
ぎ てるお
やまもと よしゆき
か わ い かつひこ
[5] 鈴木憲治, 安藤建一, 山田直明, 八木照朗, 山本義之, 河合勝彦. PHP 逆引きレシピ. 翔泳社,
2009.
ほしの か
ほ
こ
[6] 星野香保子. ゼロからわかる PHP 超入門 Web プログラミングの第一歩. 技術評論社, 2000.
かわいあきお
[7] 河合昭男. ゼロからわかる UML 超入門. 技術評論社, 2012.
たきもとまさゆき
おおもり く み
こ
いとうかずお
よ し の じゅん
き た に つよし
[8] 滝本雅之, 大森久美子, 伊藤和夫, 吉野 順 , 木谷 強 . 実例で学ぶソフトウェア開発. オーム社,
2011.
Group Report of 2013 SISP
- 89 -
Group Number 3/A