Comments
Description
Transcript
公立はこだて未来大学 2011 年度 システム情報科学実習 グループ報告書
公立はこだて未来大学 2011 年度 システム情報科学実習 グループ報告書 Future University Hakodate 2011 System Information Science Practice Group Report プロジェクト名 使い物になる実践型システム開発 2011 Project Name Practical Development of “Usable” System 2011 グループ名 グループ A Group Name Group A プロジェクト番号/Project No. 10-A プロジェクトリーダ/Project Leader 1009103 Shin Asai 浅井信 グループリーダ/Group Leader 1009103 Shin Asai 浅井信 グループメンバ/Group Member 1205005 太田和輝 Kazuki Ota 1009007 金谷祥平 Shouhei Kanaya 1009103 浅井信 Shin Asai 1009118 藤原哲 Tetsu Fujiwara 1009121 若山将太 Shota Wakayama 1009195 武田麻依 Mai Takeda 1009217 長坂明輝 Akiteru Nagasaka 1009228 江戸太樹 Taiki Edo 1009246 池田政人 Masato Ikeda 指導教員 大場みち子 伊藤恵 Advisor Michiko Oba Kei Ito 提出日 2012 年 1 月 18 日 Date of Submission January 18, 2012 概要 現在、企業等により開発された情報システムの機能には使われないものも多く、顧客の業務 を理解し有用なシステムを開発できる人材の育成が求められている。一方、そうした人材育成 と大学のカリキュラムには間隙があり、大学で講義を受けるだけでは実践的なスキルは身に付 かない。そこで、本プロジェクトでは PBL(Project Based Learning) を通じて実践的なスキ ルを磨いていく。 PBL の題材として、北海道森町より町内施設の予約を管理するシステムの開発依頼を受け た。受領した RFP(Request For Proposal) に基づき、森町役場の抱える課題である予約手続 きおよび集計業務の煩雑さを解決する。そして、提案から構築までの生の開発工程を通じて 「使い物になるシステム」を開発する能力を身に付ける。 キーワード 使い物になる、予約システム、RFP(Request For Proposal)、UML(Unified Modeling Language) （※文責: 江戸太樹） -i- Abstract Today there are many unusable functions in information systems developed by enterprises, so the industry demands IT assets which are able to understand clients’ needs and develop useful systems. On the other hand, a gap exists between the training such assets and academic curriculums. It means the practical skill is not acquired only by lecture in colleges. Therefore, we develop the practical skill through PBL(Project Based Learning). As a theme of PBL, we received request from Mori, a town in Hokkaido, to develop a system managing reservations of facilities there. This project has two purposes. First one is offering solution to cumbersome procedures of reservation and counting work. Second one is acquiring the skill to develop “usable” system through practical experience covering phases from proposal to implementation based on RFP (Request For Proposal) from Mori. Keyword “Usable”, Reservation System, RFP(Request For Proposal), UML(Unified Modeling Language) (*Responsibility for writing : Taiki Edo) - ii - 目次 第1章 はじめに 1 1.1 本プロジェクトの背景 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 大学教育の問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 顧客が抱える問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 課題の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 到達目標 3 第2章 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1 通常の授業ではなく、プロジェクト学習で行う利点 . . . . . . . . . . . . . 3 2.1.2 地域との関連性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 具体的な手順・課題設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1 PBL におけるプロジェクト活動の手順・課題設定 . . . . . . . . . . . . . . 4 2.2.2 顧客のシステムを作成するための手順・課題設定 . . . . . . . . . . . . . . 4 課題の割り当て . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 課題解決のプロセスの概要 11 3.1 担当者の決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 スケジュールの決定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 素案作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 プロジェクトメンバ間での議論 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5 素案修正 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.6 顧客との話し合い（合意） . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 課題解決のプロセスの詳細 14 4.1 開発の進め方 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2 開発体制 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1 顧客 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2 アドバイザ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.3 開発メンバ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 各工程での具体的な開発プロセス . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.1 提案工程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3.2 要件定義工程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.3.3 設計工程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3.4 実装工程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.5 試験工程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.3.6 納品 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.3.7 イベント . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.1 2.2 2.3 第3章 第4章 4.3 第5章 本プロジェクトにおける目的 45 個々の課題への取り組み - iii - 5.1 各人の課題の概要とプロジェクト内における位置づけ . . . . . . . . . . . . . . . 45 5.2 担当課題解決過程と他の課題との連携の詳細 . . . . . . . . . . . . . . . . . . . . 47 第6章 5.2.1 太田和輝 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.2.2 金谷祥平 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5.2.3 浅井信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.2.4 藤原哲 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.2.5 若山将太 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.6 武田麻依 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.2.7 長坂明輝 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.2.8 江戸太樹 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.2.9 池田政人 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 結果 77 プロジェクトの結果 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.1.1 結果の詳細 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.1.2 本プロジェクトの成果物 . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.2 成果の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.3 担当分担課題の評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6.3.1 太田和輝 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6.3.2 金谷祥平 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.3.3 浅井信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.3.4 藤原哲 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6.3.5 若山将太 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 6.3.6 武田麻依 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 6.3.7 長坂明輝 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.3.8 江戸太樹 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 6.3.9 池田政人 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.1 第7章 102 今後の課題と展望 7.1 課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 7.2 展望 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 第8章 謝辞 104 付録 A 新規習得技術 105 付録 B 活用した講義 106 付録 C 相互評価 107 108 参考文献 - iv - Practical Development of “Usable” System 2011 第1章 1.1 はじめに 本プロジェクトの背景 現在、大学のカリキュラムにより育成される人材と企業が求めている人材との間にはギャップが 存在している。大学では、プログラミング技術や計算機科学などを重要視している傾向がある。こ れに対して企業が大学に期待しているものは、参考サイト [1] よりシステム・ソフトウェア設計や 文書作成能力・文章力などの基礎能力、チームワークやリーダーシップなどのコミュニケーション 能力やマネジメント能力を求めているのである。以上のようにギャップが存在している中、さらに は大学の講義を受けるだけの机上の勉強では根本的な理解には結びつかず、企業が求めている実践 的なスキルが身に付かない。そのため本プロジェクトは、PBL(Project Based Learning) を通し て実践的なスキルを身に付けていくために活動をすすめていく。実際のプロジェクトと同じような 体制で取り組むことで必要となるコミュニケーション力や技術力を学んでいくことが実践的なスキ ルを身に付けるために重要である。現在、開発されているシステムの機能の大半は使われていない という実態がある。使われない機能が半分もあるシステムは果たして顧客が本当に作成してほしい システムと言えるのか疑問である。そこで、本プロジェクトは使い物になるシステムとはどのよう なものであるかを十分に考え、顧客の業務を理解して実際に使ってもらえるシステムを開発するた めに活動を行う。 今回は提案依頼書 (以下、RFP) に基づくシステム開発を進めていくことになった。RFP は顧客 よりこのようなシステム開発をして欲しいということが具体的に記述されている。本プロジェクト は、RFP の内容はもちろんのこと、顧客の要求や業務内容をより詳細に理解した上で必要だと思 われる機能を追加していき、使い物になるシステム開発をしていく。そして、今回は顧客として森 町様 (以下、顧客) のご協力により実践に近い形で本プロジェクトを進めていくことになったので ある。顧客の RFP によると作成して欲しいというシステムの内容や、2011 年 11 月 30 日までに 開発したシステムを納品し、運用は 2012 年 1 月 10 日を開始するとの内容も含まれていた。本プ ロジェクトは本来システムエンジニアが経験する工程を RFP 受領後の提案から実運用・保守まで の全行程を通してすすめていく。本プロジェクトメンバは全員システム開発においては素人同然で あるため、日本アイ・ビー・エム株式会社 (以下、アドバイザ) にアドバイスやレビューをしていた だきながら公共施設予約管理システム開発に取り組んだ。 （※文責: 浅井信） 1.2 大学教育の問題点 大学のカリキュラムはプログラミングや計算など技術面を重視したものが多いのに対して、企業 が求める人材はシステム・ソフトウェア設計や文書作成能力・文章力、チームワークを重視してお り、大学のカリキュラムとのギャップがある。さらには、大学での講義を受けるだけでは知識とし てしか蓄積されず、実践的なスキルとして企業が求めるスキルを定着させるための環境がない。企 業が求めるスキルを身に付けるには、チームワークや文書作成能力、システム・ソフトウェア設計 の技術を得るため、実際にシステムエンジニアが行っている仕事を体験することが、企業が求める Group Report of 2011 SISP -1- Group Number 10-A Practical Development of “Usable” System 2011 スキルを身に付ける最善の方法である。その経験の場があまりにも少ないため、実践的なスキルが 身に付いていないまま就職していくことになってしまう。使い物になるシステム開発を行っていく ために重要となる実践的なスキルが不足してしまう問題が挙げられる。 （※文責: 浅井信） 1.3 顧客が抱える問題点 顧客が管理している町内公共施設の住民利用は、各施設へ電話するか直接施設へ訪問して予約を 取る必要があるため、利用者が予約するときの手続きに煩雑さがある。さらに、これが原因で町内 在住の若年層に公共施設を利用できる制度を把握されていない可能性が高く、知ったときには既に すべての予約を継続的に取られてしまい利用できなくなってしまうという事態がある。さらに、各 施設での予約管理の業務も紙媒体で行われていて利用状況等の統計情報の集計も、その都度手作業 で行っているので業務に負荷があると考えられる。本プロジェクトは、これらの課題を解決するた めに顧客から提案された内容を基にして使いやすいシステム開発を進めていく。 （※文責: 浅井信） 1.4 課題の概要 大学のカリキュラムでは企業が求めるスキルをカバーしきれないことが挙げられているので、こ れを本プロジェクトの活動を通して身に付けていくことがそれぞれの課題である。使い物になるシ ステムを開発していくためにも、本プロジェクトが掲げる目標は提案通りのシステム開発をするだ けではなく、顧客に実際に使っていただき、満足していただける特徴ある機能を盛り込んだシステ ムを開発することである。そのためには、顧客の業務の内容をよく理解し、顧客が抱えている問題 点をどのように解決していくかを提案し開発を進めていく必要がある。そして、何よりも考えてい かなければならないことは「使い物になるシステム」を開発していかなければならないということ が本プロジェクトの課題である。その中でも、システムを導入する前の業務を阻害する（既存の業 務を固定化）ことなく業務の効率化を図らなくてはならない。 （※文責: 浅井信） Group Report of 2011 SISP -2- Group Number 10-A Practical Development of “Usable” System 2011 第2章 2.1 到達目標 本プロジェクトにおける目的 本プロジェクトの目的は大きく分けて 2 つある。 1 つ目は、メンバ各々が本学の授業では学ぶことの出来ないシステムエンジニアとしての実戦経 験を本プロジェクト内で行う PBL を通じて積むことである。その中でも特に上流工程における顧 客の課題を分析する能力や問題を解決する能力を身につけられるような活動を行う。その活動に よってメンバそれぞれがシステムエンジニアの実務やシステム開発の一連の工程を経験し、それに よって就職後にシステム開発の即戦力になる能力習得を図ることである。 もう 1 つは、今回の PBL の活動の中で問題解決のテーマとした、顧客の課題や問題点を解決す ることを通じて地域への貢献をすることである。 （※文責: 藤原哲） 2.1.1 通常の授業ではなく、プロジェクト学習で行う利点 本プロジェクトでは、実際に森町役場が抱える問題を解決することをテーマとして行う。そのた め、まず始めに森町役場職員から RFP を受領する。その RFP を基に我々が提案工程から納品ま でのシステム開発における一連の工程を実践するプロジェクトとなる。そこでは、ソフトウェア設 計論 I・II などの授業で学んだシステム構築設計の知識や技術の実践・応用することができ、逆に プログラミング演習や情報アーキテクチャ演習などのプログラミングの授業では学ぶことの出来な い範囲の実践を行うことが出来る。特にシステム開発における上流工程の経験は本学の授業の範囲 で体験できる機会が特に少ないため、本プロジェクトの活動で上流工程の経験から知識や技術を得 ることがそれぞれのメンバのシステム開発の実践経験となる。 また、本プロジェクトを進めるにあたって、必要なコミュニケーション能力の取得も行える。本 プロジェクトでは、メンバが開発者という立場で顧客と様々な場面でコミュケーションが求められ る。そこでは、本学のコミュニケーション授業で行われる活動では得られないコミュニケーション 技術を習得しながら、プロジェクトを進めていくことが出来る。 （※文責: 藤原哲） 2.1.2 地域との関連性 今回の PBL で作成されるシステムを導入することによって、森町役場の公共施設予約管理業務 のシステム化を行う。それによって森町役場の公共施設予約管理業務の改善・効率化が図られるこ とや公共施設利用率の向上に貢献することが出来る。また森町民がシステムを利用することによっ て公共施設利用制度の利便性を向上させることも出来る。 また作成されたシステムは、顧客からの RFP に基づき開発を行い、森町の人口や町の規模に合 わせて作成されたものである。しかし、顧客が抱えている行政の課題は渡島地方のその他の近隣市 Group Report of 2011 SISP -3- Group Number 10-A Practical Development of “Usable” System 2011 町村でも同様に抱えていることが予想される。故に、今回森町役場に導入する公共施設予約システ ムの汎用化を行いパッケージ化を行うことが出来れば、森町役場と同様に予算や規模の面での理由 から商品化されて市場に出回っているシステムの導入をためらっている市町村への貢献が出来る可 能性も秘めている。 （※文責: 藤原哲） 2.2 具体的な手順・課題設定 2.2.1 PBL におけるプロジェクト活動の手順・課題設定 PBL を進めていくにあたって、顧客から受領した RFP を基にウォーターフォールモデルに沿っ て以下に記述する工程でシステム開発を進めていった。 • 提案工程 • 要件定義工程 • 設計工程 • 実装工程 • テスト工程 • 納品 これらの各工程では、原則としてその工程で作成している全ての成果物が明確に定義された後に、 次の工程に移行する。それぞれの工程は前の工程の成果物を基に成果物を定義していくため、原則 として可能な限り工程の手戻りが発生しないように活動を行った。 各工程の終了は、顧客から各成果物に関して了承を得られた段階で完了とした。 また PBL の活動を促進し円滑に開発を進めるために、各工程を進める際にアドバイザから様々 なアドバイスを受けた。具体的には各工程を進めるためのプロセスの説明、その中での各成果物の 説明と作成に求められる技術、更には各成果物の評価や修正点のアドバイスを受けながら開発を進 めた。 （※文責: 藤原哲） 2.2.2 2.2.2.1 顧客のシステムを作成するための手順・課題設定 前期 前期で設定した課題及びその解決手順について以下に示す。 1. 背景・現状の把握 課題：顧客より受領した RFP の中より顧客の施設管理業務や施設利用状況に関する現状を 把握し、現状業務の問題点やシステム化における課題・目標を設定する。 2. 提案するシステムの概略決定 課題：RFP に挙げられている課題や問題に対する解決策としてのシステムの概略を決定し、 顧客に説明する。 3. システム構成決定 課題：システムの機能を実現するために利用する既存ソフトウェア及びハードウェアをソフ Group Report of 2011 SISP -4- Group Number 10-A Practical Development of “Usable” System 2011 トウェア構成・ハードウェア構成として纏める。また、対応ブラウザ及び対応キャリアを規 定する。決定した構成を図や文書により表現し、システム提案書の一部として文書化し、顧 客の合意を得る。 4. 開発体制の決定 課題：システム開発に際して、本プロジェクトがどのような体制で開発を行っていくかを決 定し、システム開発における各関係者の役割と責任の所在、顧客など外部組織との関連を明 示する。 5. 作成する成果物の決定 課題：プロジェクト全体を通して作成する成果物について、その概要と作成される開発 フェーズを纏めた一覧を作成する。 6. 開発スケジュール決定 課題：顧客より RFP を受領した段階から、システムの納入までの各開発のスケジュールを 開発工程の単位で決定する。作成したスケジュールは、各開発工程内の詳細なスケジュール を組み立てるために利用する。 7. 機能の決定 課題：システムが持つ機能の一覧を作成する。機能には RFP から抽出したものの他に、本 プロジェクトで考案・提案した機能もあり、いずれも漏れなく記載する必要がある。また、 RFP の記述だけでは曖昧な部分についてはヒアリング等を行い決定する。 8. 開発コストの見積り 課題：本プロジェクトで必要となる工数と必要経費を見積もり、一般的なシステム開発の人 件費を基に費用見積もりを作成する。提案した見積もりが、開発するシステムの価値に相応 であるかについて顧客の合意を得る。 9. 用語の整理 課題：開発の中で定義される機能や画面、帳票、その他説明が必要と考えられる用語を用語 集として纏める。ドキュメントや画面等の全ての成果物内で使用される用語はこの用語集に 記載されているもので統一し、記載されていない用語についても必要に応じて追加する。 10. プロジェクトの効果とその目標値設定 課題：本システムの導入により、森町役場における業務がどれだけ効率化されるか、施設利 用者数や施設利用制度への周知度がどの程度増加すると考えられるかといった、システム導 入による効果の具体的な目標値を設定する。 11. 開発モデル決定 課題：開発の進行をどのような工程を経て進めていくかを決定する。これによって、プロ ジェクトの目標の１つとしているシステムエンジニアの実務経験を積むプロセスを明確に する。 12. 文書管理規定の策定 課題：プロジェクト活動内で作成されるドキュメント文書の管理方法を規定し、成果物によ る文書表記のゆれや体裁の統一を図る。開発の中で作成される成果物の文章表現の形態を統 一することで、解釈の違いによるリスクを排除し、可読性に優れ、誤りの無い文書の作成を 確実にする。 13. ステークホルダーの整理 課題：プロジェクトの関係者・関係組織をステークホルダー (利害関係者) と捉え、本プロ ジェクトに対する利害関係をステークホルダーリストとして纏める。利害関係を整理するこ Group Report of 2011 SISP -5- Group Number 10-A Practical Development of “Usable” System 2011 とで本プロジェクトの社会的な立ち位置を明確にし、適切な対外交渉の指針を作る。 14. リスク管理 課題：システム開発中やシステム導入後にプロジェクト内や顧客の環境に存在するリスクに ついて検討する。具体的にはそれぞれのリスクについて、リスク下で発生し得る事象、発生 した事象の影響度、対応策をそれぞれ検討し、リスク管理計画書として整理する。 15. 関連サイト調査 課題：今回作成するシステムと類似した予約システムを探し、予約までの流れや他の機能と してどのようなものがあるのかを、想定される利用者の規模や層と共に調査する。また、調 査結果を基に森町の規模や利用者の特性に配慮したシステムとしての機能や品質、ユーザビ リティを検討する。 16. 現状業務の分析 課題：顧客の施設予約管理に関連する現状業務を、RFP や顧客へのヒアリング・施設への訪 問により把握する。明らかになった現状業務について、UML のアクティビティ図を用いて As-Is 業務フロー図を作成する。業務フロー図で表現する業務とは、今回のシステム化対象 範囲である予約及びその関連業務のプロセスのことである。作成した業務フロー図を RFP と照合しながら問題点や課題を抽出する。 17. システム導入後の業務フロー検討 課題：As-Is 業務フロー図作成で分析された現状業務に対して、システム導入による改善案 を検討し、導入後の業務の流れを表す To-Be 業務フロー図を作成する。また、各フローの 中で確認される機能についても、その振る舞いを定義していく。 18. 帳票プロトタイプ作成と要求確認 課題：顧客から要求された施設利用統計の表示・出力機能について、RFP を基に画面レイア ウトのプロトタイプを作成する。作成したプロトタイプについて顧客からレビューを受け、 今後の画面作成に活用する。 19. 画面遷移の検討 課題：To-Be 業務フロー図で定義したシステム導入後の業務の流れを実現するために、必要 となる全画面と、その間の遷移を図示する。 20. 画面プロトタイプ作成と要求確認 課題：システムの持つ画面がどのような遷移、デザインになるかを具体的に検討する為に作 成する。このプロトタイプの作成を通じて技術的な検証や画面のレイアウトに関する顧客の 要求を引き出し、以後の画面設計に反映する。 21. 非機能要件の抽出 課題：システムに要求されるパフォーマンスやセキュリティ指針、運用時間、バックアップ 間隔といった、機能要件で定義されないシステムの品質に関する側面を、顧客へのヒアリン グや運用環境の調査結果から分析し、システムの運用・開発方針として定義する。決定した 運用・開発の方針は非機能要件として文書化する。 22. データ項目整理 課題：システムが持つデータについて、どういった項目が存在し、それぞれがどのような意 味を持つのかを定義する。本システムでは RFP や、顧客への質問の回答や現状の業務で利 用されている帳票を基にし、システムがデータベース上で保持する項目について定義する。 23. データ操作機能の確認 課題：CRUD 図を作成し、各データ項目がシステム中のどの機能で作成、参照、更新、削除 Group Report of 2011 SISP -6- Group Number 10-A Practical Development of “Usable” System 2011 されるかを整理する。CRUD 図中で上記４つの基本機能のいずれかを持たないデータ項目 が存在する場合は機能の不足と見なし、機能を再検討する。 24. データテーブルの関連定義 課題：データ項目整理を受けて、データベースが保持するデータテーブルとそれら相互の関 連を定義した E-R 図を作成する。要件定義で作成される E-R 図は概念レベルのモデルであ り、データベース設計ではデータ項目に物理名を与えた E-R 図を作成する。 25. ユースケースの定義 課題：システムで提供される個々の機能をユースケースとして定義し、アクター（システム の利用者）との関連で結ぶ。システムの機能の全容について表す為、業務フロー図や機能一 覧など他の成果物と関連を考えて作成する。 26. ユースケースの振る舞いの定義 課題：ユースケース図で定義した個々のユースケースについて、詳細な振る舞いを定義す る。ユースケースに関連するアクターと、ユースケースが実行される前後で満たされるべき 条件、ユースケース実行の基本的なフローとそれに代替するフロー、例外として想定される フローについて明確に記述する。 27. ロバストネス分析 課題：ロバストネス分析では、ロバストネス図の作成により、システムの構成要素を三種類 のクラスに分類し、システムをモデル化する。ユースケース記述よりアクター、バウンダリ (画面やインターフェースとなるもの)、コントロール (エンティティやバウンダリに対して 処理を行うもの)、エンティティ (システムで永続的に保持されるデータ実体) の各クラスを 抽出し、システムの静的な構造を分析する。 28. 分析シーケンス図による動作面の分析 課題：ロバストネス図及びユースケース記述を基に、分析シーケンス図を作成する。シーケ ンス図とはシステムの動的な振る舞いについて記述するものである。本図では特に、概念レ ベルでのシステムの動作を表す。ロバストネス図で抽出した各クラス間でどういったメッ セージのやり取りが起きているのかをユースケース記述の系列より時系列順に抽出する。 （※文責: 金谷祥平） 2.2.2.2 後期 後期で設定した課題及びその解決手順について以下に示す。 1. 夏休み中の活動の確認 課題：夏季休暇中に行った活動や技術習得を今後の PBL に活かし、円滑に遂行するために プロジェクトメンバ全員で共有する。また、ここで行った技術習得を基にプロジェクトの計 画を再検討する。 2. UI サンプル作成 課題：システムを構築する上で、画面の確認・技術検証・システムの仕様を確認するため、 また後に作成する UI 設計書の叩き台のために作成する。これを基に実装工程では本システ ムの画面を HTML で作成する。 3. 開発体制図更新 課題：システム開発に際して、後期以降に本プロジェクトがどのような体制で開発を行なっ ていくかを決定することで、システム開発におけるそれぞれの役割と責任の所在を顧客と共 Group Report of 2011 SISP -7- Group Number 10-A Practical Development of “Usable” System 2011 有するために作成する。当初よりも効率よく本開発を行うために更新する。 4. 開発スケジュール更新 課題：後期からシステムの納入までの各開発工程のスケジュールを顧客と共有する。作成後 は実際にスケジュールとし利用し、工程毎の詳細なスケジュールを組み立てる為の目安とす る。また、ここではタスクの細分化を行いより具体性のあるものにする。当初よりも効率よ く本開発を行うために更新する。 5. 進捗管理表作成 課題：プロジェクトメンバがそれぞれの課題を行う際に、お互いの活動内容を把握・共有し、 効率的にシステム開発を行うために作成、随時更新する。これを利用しタスクの遅れをすぐ に確認し、本開発の遅れを防止する。 6. 懸案事項管理表作成 課題：プロジェクトメンバがそれぞれの課題を行う際に発生した懸案事項を整理し、プロ ジェクトメンバ全体で共有するために利用し、解決策・担当者を明確にするために作成する。 7. 詳細クラス図作成 課題：今回はロバストネス図を基に作成する。ロバストネス分析で抽出されたバウンダ リ、コントロール、エンティティの各クラスの静的な関連とシステム実装のために PHP や CakePHP のメソッドを考慮した属性や操作を定義する。実装工程ではこれを随時確認し、 システムを構築する。 8. クラス定義書作成 課題：本開発において、プログラムに使われる全ての変数・メソッドを定義するために作成 する。これは納品時に顧客に受け渡す文書としても必要となる。 9. 設計シーケンス図作成 課題：分析シーケンス図を基に作成する。また、設計クラス図と並行で作成する。分析シー ケンス図で定義された概念的なシステムの振る舞いを同時に作成する設計クラス図で定義さ れた属性や操作を基に各クラスでのメッセージのやり取りを時系列で定義する。 10. クラス命名規約の確認 課題：今回のシステム構築のために使用する CakePHP フレームワークにおけるクラスの命 名規則と各クラス名として使用する日本語の単語を定義することでその後の工程でのソース 名や各成果物での定義名を統一する。 11. テーブル定義書作成 課題：E-R 図や CRUD 図を基に作成する。各テーブルに属するカラムと主キーや外部キー との関係、型やサイズなどを細かく定義する。これを基に本システムで使用するデータベー スを作成する。 12. コード定義書作成 課題：テーブル定義書を基に作成する。各テーブルのカラムの値を定義し、その意味を定義 する。 13. 画面仕様書作成 課題：本システムにおいて、画面に表示される項目の一覧とその項目の仕様を明確にするた めに作成する。 14. 画面イメージ一覧作成 課題：本システムにおいて、全ての画面の仕様を決定し顧客と共有するために作成する。こ れを基にシステム構築する。 Group Report of 2011 SISP -8- Group Number 10-A Practical Development of “Usable” System 2011 15. バッチ処理一覧作成 課題：本システムに組み込むバッチ処理をリスト化したもの。構築するバッチ処理を明確に し、顧客と共有するために作成する。 16. サーバ構築 課題：システムを構築する上で、ソースコードのバージョン管理や試験を行うためにサーバ 環境を整える。ここでは顧客が利用するサーバ環境も踏まえ、OS や PHP を導入する。 17. データベース構築 課題：テーブル定義書を基に構築する。本システムで利用するテーブルを作成し、システム 内で使用するカラムを揃える。 18. SVN リポジトリ作成 課題：システムを構築する際に、ソースコードのバージョン管理を行うために作成する。 バージョン管理を行うことで、ソースコードの過去の状態や変更内容を確認したり、変更前 の状態を復元することが容易になる。 19. 携帯端末用サイトの調査 課題：携帯端末からでも本システムを利用できるようにシステムを構築する上で、携帯端末 のブラウザでも利用できるライブラリの調査や技術検証を行う。この調査により後に発生す る懸案事項や問題の発生を事前に確認、防止する。 20. システム構築 課題：サーバ構築・データベース構築・携帯端末用サイトの調査結果を基に顧客の環境で稼 働するシステムを構築する。プロジェクトメンバ間で進度を随時確認しつつ、構築を行う。 21. エラーメッセージ表作成 課題：システム内でエラーが発生した場合に画面に表示するエラーをエラー内容・エラー発 生条件・定義名と共にリスト化したものを作成し、表記の揺れを事前に防ぐ。 22. システム仕様書作成 課題：ソフトウェアの実装上のクラス構造を定義した詳細クラス図や実装される各クラスに ついての詳細な定義を記述したクラス定義書を一纏めにしたものを、顧客と共有するために 作成する。 23. マニュアル作成 課題：本システムの納品後、顧客や一般の利用者が本システムを利用ための利用手順を示し たものを作成する。 24. テスト計画書作成 課題：テスト計画の目的・内容とテストの詳細を定義するために作成する。テスト計画書を 用いて後に試験を行い、試験成績表を作成する。 25. 試験成績表作成 課題：テスト計画書を基に、試験する内容・使用するブラウザ・使用するテストケースを纏 めたものを作成する。試験成績表に試験結果を記載し、バグ修正に利用する。また、最終的 にこの試験成績表を顧客に納品し、試験結果を共有するために利用する。 26. 障害管理表作成 課題：試験で発生した障害について、その障害内容と障害が発生する手順を記載し、その障 害修正の担当者を明確にするために作成する。障害管理表で障害内容をプロジェクトメンバ で共有し、対応策を検討する。 27. ソフトウェア格納 CD-ROM 作成 Group Report of 2011 SISP -9- Group Number 10-A Practical Development of “Usable” System 2011 課題：本システムを顧客に納品する際に、ソースコード・画面仕様書・試験成績表・データ ベース仕様書・利用者マニュアルを電子化し、CD-ROM に格納する。これを顧客に納める ことで納品とする。 （※文責: 若山将太） 2.3 課題の割り当て 各メンバがシステム開発の実践をする上で学びたい部分の希望やそれぞれの得意分野、習得済み 技術などの点を考慮しながら、課題を割り振った。また、全体の進捗状況を考慮しながら、遅延し ている課題の部分へスケジュールが早期に終わった課題担当者を割り振るなどして全体スケジュー ルに影響が出ないような割り当ても行った。 （※文責: 藤原哲） Group Report of 2011 SISP - 10 - Group Number 10-A Practical Development of “Usable” System 2011 第3章 3.1 課題解決のプロセスの概要 担当者の決定 本プロジェクトは全体のプロジェクト進行を務めるプロジェクトリーダーの他にそれぞれの課題 を解決していくために各課題ごとに担当者とリーダーを決めた。メンバの全員が開発に対して未経 験者であったため各工程、各課題に対して意欲やメンバの推薦によって担当者を決めた。 （※文責: 太田和輝） 3.2 スケジュールの決定 本プロジェクト全体のスケジュールはアドバイザとのレビュー日程があらかじめ決められてい た。また、アドバイザから各工程の期間を含めて分けられた約１年間の全体スケジュール案が出さ れていた。本プロジェクトの全体スケジュールはそのスケジュール案に乗って前期は活動した。し かし、要件定義工程で要件定義の漏れによる遅れが発生した為、後期ではメンバで相談をして残り の期間のスケジュールの変更を行った。 各課題ごとに解決していく為のスケジュールはメンバと担当者による見積もりによって決められ た。成果物の大半が過去に作成した経験がない物の為、プロジェクトリーダーと担当者がどのくら いの時間がかかるかを予想で見積もって各課題ごとに解決までのスケジュールを決めた。ただし後 期の開発工程では各課題に対する成果物で最初に作成するのにかかった時間から他の同じような成 果物の作成にかかる時間を見積もってスケジュールを決定した。各課題ごとのスケジュールは進捗 管理表によって管理された。進捗管理表へ担当者がプロジェクトメンバ間での議論の前に進捗を記 入した。進捗状況によってはスケジュールの変更が行われた。 （※文責: 太田和輝） 3.3 素案作成 各成果物に対応する担当者はその対応する成果物を作成するための始まりから終わりまでの一連 の流れの案を素案として作成した。素案作成のためにすでにできている成果物・参考資料・アドバ イザの意見と助言を集めて資料とした。そして担当者なりにシステムの開始から終了までの形を作 成した。時間が許す限り担当者は改善点や不具合点を修正した。作成された素案は誰が見ても常に 最新がわかるように「Ver.」を成果物名の後に付けて Doropbox によって管理された。 （※文責: 太田和輝） Group Report of 2011 SISP - 11 - Group Number 10-A Practical Development of “Usable” System 2011 3.4 プロジェクトメンバ間での議論 議論はプロジェクトリーダーやアドバイザが作成したアジェンダに従って行われた。議論の初め にはその議論の議事録作成者の決定・各担当者が議論開始前に記入した進捗管理表の確認を行っ た。議事録は議事録担当者を議論の初めに決定した。議事録担当者はその日の決議事項・懸案事項 などの議論の記録を取り、その記録から議事録を作成した。進捗管理表の確認ではメンバで相談を して今後の方針と成果物作成の為のスケジュールを決定した。成果物の作成では担当者が作成した 素案をメンバで議論した。担当者が素案の説明を行った後にメンバが素案の疑問点や修正点を議論 した。担当者も素案作成時に発生した疑問点を出して議論を行った。議論した内容は担当者以外の 記録者がパソコンや紙に記録をして議論した後にメンバと共有した。 （※文責: 太田和輝） 3.5 素案修正 プロジェクトメンバ間での議論で修正が必要とされた素案を修正した。修正後は「Ver.」を上げ てアドバイザに見てもらった。修正された素案は成果物となり「Ver.1.0」とした。森町様との話 し合いにて合意を得られたら完了したとされるが修正が必要な場合は再度修正をして森町様の合意 が得られるまで行った。更に修正が行われるたびに最新の成果物がわかるように「Ver.」は上げて いった。 （※文責: 太田和輝） 3.6 顧客との話し合い（合意） 話し合いは公立はこだて未来大学で 5 回、森町公民館で 2 回行われた。そのほかには間接的で はあるが本プロジェクトリーダーと顧客代表者によるメール・電話での話し合いが行われた。直接 の話し合いではスライドと紙によるレビューと質疑応答が行われて、メール・電話では質疑応答が 行われた。公立はこだて未来大学ではプロジェクト初回時に顔合わせがあり、その他の回ではレ ビューが行われた。レビューではアジェンダを作成して限られた時間内に見てもらいたい所、議 論する所をレビュー前にまとめて、資料やスライドを作成した。レビューは複数回行われた。レ ビューごとに成果物となった課題を森町様に確認、そして合意してもらう事で１つの課題は解決さ れたとした。合意してもらえなかった成果物は合意されるまで議論と修正を行い、レビューを繰り 返した。顧客との直接の話し合いではビデオカメラによる録画や写真撮影によって記録が残され た。 公立はこだて未来大学では顔合わせで顧客から本プロジェクトに本システムを作成することを 要求した RFP が提出された。RFP に対して 1 回目のレビューでシステム提案書をレビューして もらった。システム提案書のレビューではシステム作成の為の見積もりコストが高かったこと・本 システム導入による効果の目標値に理由がなかった為、修正を行って承認をもらった。その他のレ ビューではサーバのスペックの確認・本システムの画面イメージを提案・各種成果物の納品順序の 相談・納品を行った。 森町公民館ではメンバが役場管理者に質問と本システムの確認を行う班・公民館の担当者に質問 Group Report of 2011 SISP - 12 - Group Number 10-A Practical Development of “Usable” System 2011 と現状の業務確認をする班の２つに分かれて話し合いが行われた。役場管理者に質問と本システ ムの確認を行う班では To-Be 業務フロー図による予約確定までの流れと機能一覧の確認を行った。 現状の業務確認では顧客の役場担当者の案内によって実際にシステム導入前の業務とその形式を間 近に見て理解するした。そしてシステム導入前の予約を実際に行ってみることで本システムの予約 の流れのイメージをつかむことができた。さらに利用実績の記録用紙とその記入方法や施設内で 共通して使用できる備品の貸出があったこと、講堂が２階あったこと・利用できる部屋が地下にも あった等の施設の部屋がどこにあるのかという RFP だけでは見落としていたシステムを作る為に 重要であった情報を確認した。 メールや電話ではレビュー外の時に課題や問題に対して回答がほしい時に行われた。課題や問題 は質問事項リストをデータファイルにすることでお互いがどのような質問と確認を行ったのかを メールの添付ファイルとしてメンバーと顧客が共に更新して共有した。質問事項リストには図 3.1 のように項番・優先度・回答希望日時・質問の意図・回答・記入者の欄を設けて共有した。限られ た時間内で課題を解決するためには問題はいち早く解決していかなければならないため、お客様と お互いに要求や意見・質問事項を頻繁に確認しあうメール・電話での話し合いはほぼ毎週 1 回以上 は行われた。また、当初の 11 月 30 日を期限とした納品日がお互いに日程が合わないため日にちを ずらした事などの重要な連絡の取り合いを行った。 図 3.1 質問事項リスト （※文責: 太田和輝） Group Report of 2011 SISP - 13 - Group Number 10-A Practical Development of “Usable” System 2011 第 4 章 課題解決のプロセスの詳細 4.1 開発の進め方 本プロジェクトでは、開発工程のモデルとしてウォーターフォールモデルを採用した。開発の流 れとしては、提案工程を経た後、要件定義工程を行い、設計工程の後に実装工程を行い、その後テ スト工程となる。前の工程での不備から手戻りが発生することがしばしばあったが、アドバイザら の助言を参考にし、修正を行った。要件定義工程以降の工程においては、ユースケース駆動開発を 取り入れ開発を遂行した。 （※文責: 武田麻依） 4.2 4.2.1 開発体制 顧客 本プロジェクトには、顧客が存在した。本プロジェクトの顧客は、隣町である森町であった。 そのうち、森町役場にて情報システムを管理する部署に勤められている山形巧哉様、山本康信様、 安藤仁様の 3 名、特に、山形様と山本様の 2 名の方が中心となり、本プロジェクトに関わった。彼 らには度々本校に訪問してもらい、システムの詳細な仕様を話し合った。それ以外でも、システム に疑問点等があった場合は、メールを使って細かにやり取りを行った。また、メンバが実際に森町 に訪問し、施設の調査を行った際は、公民館の職員二名にご協力頂いた。 （※文責: 武田麻依） 4.2.2 アドバイザ 本プロジェクトでは、日本アイ・ビー・エム株式会社より、3 名の方々に本システムのレビュー をするアドバイザとして、本プロジェクトを支援して頂いた。アドバイザには、現在の成果のレ ビューをして頂き、メンバ全体、時にはメンバ個人にアドバイス等の支援をして頂けた。また、本 校にいない時でも、メール、電話、遠隔会議、Skype 通信のほか、サイボウズ Live というグルー プウェアを通じて、度々プロジェクトの進捗を見て頂き、アドバイス等を頂いた。 （※文責: 武田麻依） 4.2.3 開発メンバ 本プロジェクトのメンバは計 9 名だった。プロジェクト始動時のプロジェクトリーダーは江戸 太樹、サブリーダーは浅井信と藤原哲の 2 名であった。設計工程から、各自のタスクを考慮した上 で、より作業の効率化を図るためにプロジェクトリーダーを江戸から浅井に変更した。以上のこの 3 名を中心とし、本プロジェクトは活動を行った。各工程での作業が多く、作業内容が多岐に渡っ Group Report of 2011 SISP - 14 - Group Number 10-A Practical Development of “Usable” System 2011 ていたため、メンバは各工程にて、幾つかの班に分かれて活動した。工程によって各班のメンバの 組み合わせは異なっているので、下方にその詳細を記す。なお、提案工程においては、メンバは班 分けすることはなく、全員で作業を行っていた。また、要件定義工程の遅れにより、実装工程の完 了を待ってから試験工程に取り組むということが難しくなったため、実装工程と試験工程を実質同 時にに行うことになった。また、携帯端末用ページ実装の担当者である若山は携帯端末用ページ実 装における調査と開発、携帯端末のテストを担当したため、開発班と試験班両班に所属とした。江 戸は UI 設計を担当すると共に、各メンバの技術面をサポートするスキルサポーターとして、試験 班、マニュアル班のサポートも行った。 • 要件定義工程 – プロセス班：浅井 (チームリーダー), 池田, 太田, 長坂 – 業務フロー班：藤原 (チームリーダー), 江戸, 若山, 金谷, 武田 • 設計工程 – プロセス班：浅井 (チームリーダー), 江戸, 金谷 – データ項目班：池田 (チームリーダー), 太田, 若山 – プロトタイプ班：藤原 (チームリーダー), 長坂, 武田 • 実装工程 – スケジュール変更前 ∗ 詳細設計班：金谷, 江戸 ∗ 内部実装班：藤原, 池田, 若山, 武田 ∗ ビュー班：浅井, 長坂, 太田, 江戸 – スケジュール変更後 ∗ PC 向けおよび共通部分 · 実装班：浅井, 藤原, 金谷, 池田, 長坂 · UI 設計班：江戸 · マニュアル班：太田 ∗ 携帯電話向け部分 · 実装班：若山 · UI 設計班：若山 • 試験工程 – PC 向けおよび共通部分 ∗ 試験班：武田 – 携帯電話向け部分 ∗ 試験班：若山, 武田 （※文責: 武田麻依） Group Report of 2011 SISP - 15 - Group Number 10-A Practical Development of “Usable” System 2011 4.3 4.3.1 4.3.1.1 各工程での具体的な開発プロセス 提案工程 技術・類似システム調査 システム構築の内容については RFP に沿って作成する方針が決まっていたため、それに必要な 技術の調査や類似システムの調査を行った。プロジェクトとして始めの活動であり、今後の土台と なる部分でもあったので、メンバ全員で調査活動を行うことになった。スケジュールも 1 週間とい う短期間しかなかったのにも関わらずそれぞれ調査の結果を発表し合い、我々がシステム開発をす るために現実的な結果を導き出すことができた。なお、各調査の議論内容や結果の詳細は次のよう になっている。 技術調査は、今回システムを構築するにあたり使用するプログラミング言語の選定を行った。選 定の際に注目した点については、以下の点である。 • Web によるシステム開発 • プログラミング習得にかかる時間短縮（フレームワークがあるもの） • 複数人でのプログラミング（コーディング理解の容易さ） • 使用経験があるプログラミング言語（経験のある言語に近い言語） Web によるシステム開発ということで、使用する言語は PHP、Ruby、Perl、Python という候 補が上がった。これを基にして、プログラミングの習得時間や経験のある言語または、他人の書い たコードの理解が容易であることなどを考慮した結果、使用するプログラミング言語を PHP に決 定した。最終的には、顧客にこの言語を使う利点を挙げて承認を得る形となった。 類似システム調査においては、なにもない状態から期間内にシステムを作成することは難しいこ とが考えられ、参考になる類似システムである Web サイトでの予約サイトを調査した。2 名で参 考となる予約サイトを調査し素案をまとめ上げ、プロジェクト全体に提案し議論を繰り返しながら まとめていった。特に議論した内容で重要となった点については以下の点である。 • 誰でも簡単に使うことができる予約サイト • 携帯電話での利用もできる予約サイト • 手続きが簡単な予約サイト 各サイトからこのような点について良いところを探し出して本プロジェクトが作成するシステム のイメージを想像しやすいようにしていった。 （※文責: 浅井信） 4.3.1.2 システム提案書 前節で挙げた技術・類似システムの調査を踏まえつつ、RFP に対する回答としてシステム提案 書を作成した。 本プロジェクトで作成したシステム提案書の構成は以下の通りである。 • 本件の背景 – 提案に至るまでの経緯 Group Report of 2011 SISP - 16 - Group Number 10-A Practical Development of “Usable” System 2011 本プロジェクトが顧客への提案に至るまでの背景を記述する。また、問題点や導入効果 について簡単に紹介する。 – 現状の課題 顧客が現在抱える課題に対する問題提起を行う。 • 提案システムの説明 – 提案システム概要提案システムの担う役割について記述する。 – システム化対象領域 現状業務のどの範囲がシステム化されるのかを図示する。 – 提案システム概要図 提案システム概要のほか、大まかな処理の流れを図示する。 – システム化に伴う目標値 施設の利用者数増加、予約管理業務の業務時間削減などの切り口から根拠を添えて導入 効果とその目標値を説明する。 – 本提案の特徴 RFP の要件に加えて本プロジェクトが提案する拡張機能（Google Maps による施設検 索・よくある質問の登録・新着情報表示・アカウント管理機能の拡張）を記載する。 – 機能一覧 RFP の要件から抽出した基本的な機能と、提案機能を一覧にまとめる。 • システム構成 – ハードウェア構成図 提案システムがどのようなハードウェア構成で実現可能かを図示する。 – ソフトウェア構成図 前節の技術調査を踏まえ、サーバのソフトウェア構成（サーバ OS・Web サーバ・メー ルサーバ・開発言語・データベース）を図示する。 – 対応ブラウザ 本システムで対応するブラウザについて記載する。 • 開発体制 本プロジェクトの開発体制を図示するほか、顧客との連絡系統やプロジェクト外との協力体 制について記載する。 • 成果物一覧 顧客に納めて合意を取得する必要がある成果物を一覧化し、その概要と納入期をまとめる。 • 開発スケジュール 工程毎の予定をまとめる。その中で顧客に関わりのある局面があればその旨についても記載 する。 • 見積もり 本システムのランニングコスト、導入コストを見積もる。ただし、本プロジェクトにおいて は顧客との間に一切の金銭のやり取りはない。 メンバの中に類似したシステム提案の経験を持つ者はいなかった。そこで、一般的な提案書の構 成を調査し、それを本件に見合う内容へ修正する形で構成を検討した。そして、作成した提案書を 森町へ提出し、承認を受けた。 （※文責: 江戸太樹） Group Report of 2011 SISP - 17 - Group Number 10-A Practical Development of “Usable” System 2011 4.3.1.3 プロジェクト計画書 プロジェクト定義に示されたゴール・到達目標を達成するために何をするべきかの計画を明確に し、プロジェクトメンバで共有するために作成した。具体的には下記に示す 9 つの内容について記 載した。 • プロジェクトの目的 • プロジェクトの効果とその目標値 • システム概要 • 開発体制 • 開発環境 • 開発モデル • 成果物一覧 • 導入スケジュール • 文書管理規定 プロジェクト計画書を作成するにあたって、まず本プロジェクトの目標を具体的に記し、明確化 した。これを軸にシステム概要を作成・確認し、目標を達成するために開発体制・開発環境・開発 モデルを決定した。また、本プロジェクトを円滑に進めるために全体のスケジュールを作成した。 このプロジェクト計画書は顧客とも共有した。 （※文責: 若山将太） 4.3.2 要件定義工程 4.3.2.1 機能要件 要件定義工程は、提案工程で本プロジェクトが提案したシステムについての承認を得られた後に 行われた。 要件定義における機能要件とは、提案工程で提案したシステムで顧客の要求を正確に把握するこ とが求められる。その際には、顧客が RFP をまとめる中でシステム化する上での潜在的な要求を 明確にし、それらを全てまとめてシステム化範囲を顧客と協議し、合意を得ることが目的となる。 本プロジェクトでは、提案工程終了後に下記の 4 つの成果物を作成した。 • As-Is 業務フロー図 • To-Be 業務フロー図 • ユースケース図 • ユースケース記述 As-Is 業務フロー図 As-Is 業務フロー図は顧客の現行業務の分析を行うために作成した。現行業務の分析を行 うことによって、現行業務の流れを把握することとその中で何が問題であるかを把握し、更 には顧客と共有するために作られ、システム化範囲や機能を決定するために作成した。 以下が As-Is 業務フロー図で分析された業務フロー一覧である。 • 施設検索 • 予約 Group Report of 2011 SISP - 18 - Group Number 10-A Practical Development of “Usable” System 2011 • 予約内容変更・キャンセル • 予約情報の管理 • 利用情報統計 To-Be 業務フロー図 To-Be 業務フロー図は、現行業務の把握に作成した As-Is 図から問題を抽出し、それを 解決するためのシステム化によって業務がどのようになるかを定義するために作成した。 To-Be 業務フロー図はシステム化後の業務で現行業務ではなかった問題点がないことや課 題の解決がなされる機能であるかどうかを確認するために作成した。 以下が To-Be 業務フロー図で定義された業務フロー一覧である。 • 施設予約の検索 • 仮予約・予約確定・リマインダメール送信 • 予約変更・キャンセル • ユーザ登録 • 問い合わせ • 強制キャンセル • 施設情報作成 • 施設情報編集 • 利用実績登録 • レポートの出力 • 新着情報 • メンテナンス • 入力情報の自動チェック • リマインダメール送信 図 4.1 は仮予約・予約確定・リマインダメール送信に関する To-Be 業務フロー図である。 ユースケース図 ユースケース図は、作成した To-Be 業務フロー図を基に作成した。システムの中で必要 とされる機能を抽出し、各機能について機能を利用するユーザー (アクター) を定義して、シ ステムの機能と各ユーザーの利用可能範囲の定義を行った。 図 4.2 は本システムのユースケース図である。 ユースケース記述 ユースケース記述はユースケース図と To-Be 業務フロー図を基に作成した。ユースケー ス図で定めた機能について、各アクターがそれぞれの機能をどのように利用するかを時系列 順に記述した。ユースケース記述は、To-Be 業務フロー図で定義された予約のフローや事務 手続きのフローをシステムがどのように処理するかを詳細に記述した。 ユースケース記述の作成に当たって、記述の際には事前条件と事後条件の定義、例外フ ローの定義に時間を費やした。 更にユースケース記述を作成後には、画面遷移図や画面プ ロトタイプの作成を行い、システムの全体像の把握を試みた。 上記成果物は顧客とメール、本学での会議を複数回行う中で確認、修正を行いながら作成 を行い、最終的に顧客の現場を訪問しプロジェクトメンバ側の分析を行いながら、要件定義 の合意を進めていった。 （※文責: 藤原哲） Group Report of 2011 SISP - 19 - Group Number 10-A Practical Development of “Usable” System 2011 図 4.1 図 4.2 Group Report of 2011 SISP 業務フロー図 ユースケース図 - 20 - Group Number 10-A Practical Development of “Usable” System 2011 4.3.2.2 データ項目の分析 システムでのデータ化が必要な項目を分析するために既存業務で使用されている帳票を顧客から 提供して頂き、帳票からシステムに取り入れるべき項目をリストアップした。 また、システム化するにあたって必要な項目は顧客から受領した RFP から取り入れた。アドバイ ザからのアドバイスやプロジェクト内での議論を参考に進めたところ最終的にデータ項目は 157 項目、エンティティと呼ばれるデータのまとまり、すなわち実体を表すものは 12 個になった。 これらの項目をデータ項目一覧としてドキュメントにまとめ、設計工程においてデータ項目を データベースで扱うために必要となるデータ設計と機能の詳細設計で使用した。 （※文責: 池田政人） 4.3.2.3 非機能要件 そもそも非機能要件とはどのようなものかわからないため、非機能要件について調査することか ら始めた。まずは、非機能要件についてプロジェクトメンバへ説明するために調査を進めることに なった。メンバ内でも非機能要件について知識のある人がいなかったため非機能要件の基準を定め るために、独立行政法人情報処理推進機構（以下 IPA）のサイトにある「非機能要求グレード」を 参考にしてまとめることにした。 非機能要件で重要になるキーワードとしては性能や信頼性，拡張性，セキュリティなどがあり、 どれもシステム作成または顧客にシステムを納めるにあたり重要な項目が挙げられていた。これを 基にしてメンバへ非機能要件をまとめる方向性を示し、作成したドキュメントを通してメンバ間で の承認を受けることができた。「非機能要求グレード」には、この項目について詳細にまとめられ ており、本プロジェクトが必要だと思う項目を抜き出して各項目毎にグレードを定め顧客に承認を いただいたのである。 実際に作成した非機能要件について、顧客の導入先のサーバ変更などに伴い非機能要件の変更に ついても考えられたため、やり取りをする際に変更がわかるように工夫をした。項目については IPA のサイトにあるものを基にして、必要である項目を絞って内容についてもわかりやすいように 書きなおした。どのようなドキュメントで承認を得ていったかは作成した非機能要件の一部である スクリーンショットを図 4.3 に示す。 （※文責: 浅井信） 4.3.3 設計工程 4.3.3.1 システム設計 設計工程は分析フェーズと詳細設計フェーズの二段階で行った。 分析 設計の準備段階として、要件定義工程で抽出された要件仕様に対し論理的な分析を行いな がら実現手法を検討した。本工程ではロバストネス分析と分析シーケンス図の作成を通じて 要件の分析を行った。ロバストネス分析では、要件定義工程で作成したユースケース記述 から、システムの構成に必要なバウンダリ・コントローラ・エンティティの三種類のクラス Group Report of 2011 SISP - 21 - Group Number 10-A Practical Development of “Usable” System 2011 図 4.3 作成した非機能要件の一部 (構造上の単位) を抽出し、抽出したクラスとそれら相互の関連を定義したロバストネス図 (図 4.4 参照) を作成する。これにより、ロバストネス図はシステムの静的な構造を表す事が 出来る。 構造を表すロバストネス図に対し、分析シーケンス図 (図 4.5 参照) はシステムの動的な 振る舞い、即ち稼働時のクラスオブジェクト (クラスを具現化した実行上の単位) 同士のや り取りや状態の変化を時系列順に記述する。分析シーケンス図作成を通して、ロバストネス 分析で抽出したクラスの切り分けが適切であるかや、クラス間の関連に過不足が無いかを見 直した。 参考した書籍 [3] によると、本来はロバストネス分析で抽出したエンティティクラスにつ いて分析クラス図を作成し、関連や多重度をより明確に定義するようである。しかし、本プ ロジェクトではデータ関連の分析を専門に行う班が存在し、E-R 図等の成果物で分析クラス 図作成の目的は達成されていたと考えることができた為、分析クラス図作成を省略した。 ロバストネス図は小さな機能単位で作成した。図 4.4 に示すのは予約機能についてのロバ ストネス図である。左側をユーザとして、ユーザと接するバウンダリクラス、動作の中心と なるコントローラクラス、そして、データを扱うエンティティクラスの順番に並んでいる。 図 4.4 と同様の機能について作成した分析シーケンス図の一部を図 4.5 に示す。上部にあ るのがロバストネス分析で定義されたクラスであり、それに対し、ユースケース記述のシナ リオを基にクラス間のメッセージを決定している。 詳細設計 要件定義工程及び分析の完了後に、内部的なシステム設計に取り掛かった。この工程は、 要件定義で抽出した顧客要件や技術調査、分析の結果を受け、実装可能なシステムの構成を 決定することを目的とするものである。分析と違う点は、フレームワークやサーバ環境の アーキテクチャや、プログラミング言語の特性といった物理的な条件を考慮する必要がある ことである。また、本工程での作業は UML によるシステムモデルの記述が中心となり、UI 設計における画面イメージ・項目作成や、データベースの設計と深く連携を取りながら進行 していった。システム設計では UML のクラス図・シーケンス図によりシステムの記述及び プログラム仕様の決定を行った。クラス図 (図 4.6 参照) については分析工程のロバストネ ス図を、シーケンス図 (図 4.7 参照) については同工程の分析シーケンス図を、それぞれよ り内部的なモデルとして詳細化する手順を取った。本工程におけるクラス図・シーケンス図 Group Report of 2011 SISP - 22 - Group Number 10-A Practical Development of “Usable” System 2011 図 4.4 図 4.5 ロバストネス図 分析シーケンス図 を、便宜的に、詳細クラス図・詳細シーケンス図と呼び分ける。また、プログラム仕様につ いてはクラス・メソッドレベルでの仕様を文書化し、上記モデルと併用した。 本プロジェクトでは MVC(Model View Controller) モデルをベースとしたシステム設計 を試みた。MVC を利用することで、フレームワークのアーキテクチャに対して極めて自然 なモデルが作成できたが、一方で、前工程のロバストネス分析におけるクラスを MVC での 役割を持つクラスへと変換する必要性が生じた。詳細化に関しては、実装レベルでのクラス の定義後、詳細シーケンス図を記述し、クラス間のやり取りをメソッドとして定義した。そ の過程で必要となるデータを導出し、仕様を整理していった。 上記のようなプロセスによりシステム設計を進行していった。実際には工期の遅れなども Group Report of 2011 SISP - 23 - Group Number 10-A Practical Development of “Usable” System 2011 あり、実装範囲全体をカバーする設計ができなかったといった失敗はあった。しかしなが ら、プログラムの実装に即した仕様を定義できたことは、システム構成を決定するだけでは なく、実装作業の分担や、担当者同士での意思疎通を効率的に行う為にも役立った。 図 4.6 は予約機能の部分について記述したクラス図である。図では黄色が MVC における コントローラクラス、空色がモデルクラス、赤はコンポーネントクラス (フレームワークの 特性上存在する機能クラス) となっている。ビューについてはコントローラ・メソッドから 存在が明確であり、詳細については UI 設計で記述されることで省略した。 図 4.6 詳細クラス図 図 4.7 は、図 4.6 と同様の範囲について作成した詳細シーケンス図である。分析シーケン ス図同様、クラス間のメッセージのやり取り (ここではクラス・メソッド) を決定している。 図 4.7 詳細シーケンス図 （※文責: 金谷祥平） Group Report of 2011 SISP - 24 - Group Number 10-A Practical Development of “Usable” System 2011 4.3.3.2 データ設計 本節ではシステムの性能や使い勝手を大きく左右する重要な項目であるデータベースの設計過程 を述べる。 データベースの設計にはシステムのデータモデルを表現するために実体関連モデル（Entity- relationship Model）を用いた。 データ項目の正規化 要件定義工程で作成したデータ項目一覧では施設の利用目的など複数のデータが入りうる 項目が多数あり、このままではリレーショナルデータベースでは利用出来ないために正規化 を行った。 正規化を行うことで複数のデータが入りうる項目を別のエンティティとし、エンティティ 間のリレーションシップを構築することで複数のデータを扱うことが出来る様になった。最 終的にデータ項目は 200 個、エンティティは 26 個になった。 E-R 図作成 E-R 図とは実体関連モデルを用いたデータベース設計においてエンティティ間の関連を 図にしたものである。 要件定義工程では正規化前のデータモデルを、設計工程では正規化後のデータモデルにつ いて E-R 図の作成を行った。正規化後の E-R 図を図 4.8 に示す。 CRUD 図作成 CRUD とは Create（生成）、Read（読み取り）、Update（更新）、Delete（削除）のリ レーショナルデータベースの基本機能の頭文字を取ったものである。本システムが持つ機能 と E-R 図にあるエンティティの対応を表すために CRUD 図を作成することで機能とデー タモデルの双方に過不足がないかを発見する事ができた。 コード定義 システムで利用するデータを一意識別する為の ID やデータの状況を 0 や 1 などで識別す る為のコードを定義しデータベースで利用している。これらのコードを定義しコード定義書 としてドキュメントにまとめた。コード定義の一部を図 4.9 に示す。 サンプルレコード作成 顧客へ設計したデータベースの説明を行う際、システムに対するユーザの操作によるデー タの挿入等によりデータベース内がどのように変化するかを示す為にサンプルレコードの作 成を行った。サンプルレコードの中から利用者による予約によって変化する様子を図 4.10 に示す。 データベース定義 正規化を行ったデータモデル、コード定義書を用いて論理データモデルを物理データモデ ルとし、データベースマネージメントシステムで利用するために各データの型や長さ、制約 を定義しテーブル定義書を作成した。次工程である物理データベース構築に向けてテーブル 定義書を元にテーブル作成をための SQL を作成した。 Group Report of 2011 SISP - 25 - Group Number 10-A Practical Development of “Usable” System 2011 図 4.8 Group Report of 2011 SISP 作成した E-R 図（正規化後） - 26 - Group Number 10-A Practical Development of “Usable” System 2011 図 4.9 図 4.10 Group Report of 2011 SISP コード定義（一部抜粋） サンプルレコード（抜粋） - 27 - Group Number 10-A Practical Development of “Usable” System 2011 （※文責: 池田政人） 4.3.3.3 UI 設計 この節では本システムにおけるユーザインタフェース設計のプロセスを記す。 画面遷移の検討 要件定義工程にて定義されたユースケースを実現するためにどのような画面が必要である か、実用性があるかを現場の帳票などを元に洗い出し、それら同士を結びつけて画面遷移図 として整理した。画面遷移を定義し顧客から承認を得ることによって、後の設計や実装の土 台とすることが目的である。各画面には画面 ID を付与し、その後の開発において成果物間 のトレーサビリティが保てるようにした。また、エラー発生時やその他の制御時にどの画面 へと戻るのかを明記することに留意した。作成した画面遷移図の一部を図 4.11 に示す。 図 4.11 再検討後の画面遷移図 画面イメージ作成 整理された個々の画面について、画面遷移図と併せて顧客に画面仕様を確認するための詳 細な画面イメージを作成した。イメージ作成の際には内部設計の担当者と、本システムで用 いるフレームワークにおける実現可能性、および構築にかかる工数について綿密に打ち合わ せた。なお、今回の開発においては、画面項目の配置を確認するためだけの簡易な画面イ メージではなく、画像編集ソフトを用いて実システムの画面上で用いるボタン等の素材作成 Group Report of 2011 SISP - 28 - Group Number 10-A Practical Development of “Usable” System 2011 を並行して取り組んだ。その狙いは間際に控えた対外的な発表のために、システム構築と並 行してスタイルシートを用いた整形へと早期に着手することであった。 本プロジェクトでは通常、顧客との打ち合わせの媒体は電子メールによるものであったた め、一目で多くの仕様を確認できる画面イメージは顧客とのやり取りに多いに役立った。 画面項目定義 画面イメージ中のラベル、コンボボックス、チェックボックス等の論理項目各々について 以下の情報を定義した。 • 画面項目 ID • 論理項目名 • 論理項目種別 • 物理項目名 • 初期値 • 入力チェック • 備考 画面イメージのみでは画面上リスト項目をデータベース中のいずれのテーブルからいずれ の属性を取得すればいいのか等、開発時におけるメンバ間での意識のずれを解消するために 以上の情報を定義した。また、顧客への納品時にはこれを仕様書として納めることで、保守 管理に役立ててもらうことも狙いとした。作成された仕様書の一部を図 4.12 に示す。以下 の形式で計 23 画面についての画面仕様をまとめた。 図 4.12 画面仕様書 ロゴ制作 本システムのイメージ伝達を担うロゴ制作へと取り組んだ。これについてはメンバの中に 手の空いている者がいなかったため、同学にてデザインを専攻する学生と共に制作する運び になった。 具体的な手順としては、まずは本案件におけるシステム化の背景や導入後の狙いなどを伝 え、コンセプトの共有を図った。この際にその時点での開発中の画面イメージを資料として Group Report of 2011 SISP - 29 - Group Number 10-A Practical Development of “Usable” System 2011 提供し、それにマッチするロゴの提案を数件依頼した。その後チーム内でディスカッション を行い、選定されたロゴを顧客へ提案するという流れであった。作成されたロゴを図 4.13 にて紹介する。 図 4.13 森町施設予約管理システム - ロゴ （※文責: 江戸太樹） 4.3.4 4.3.4.1 実装工程 サーバ構築 サーバ構築は、プロトタイプ作成の一環として構築を開始した。サーバはシステムの実装、テス トを円滑に行うために、森町とまったく同じ環境ではなく自前で管理者権限を持つサーバを学内に 設置するものである。サーバ構築はまず、森町の RFP や聞き取り調査、レンタルしている会社の ホームページやカタログの調査を行い、そのサーバのディストリビューションや使用可能ソフト ウェア (WEB、データベース、スケジュール管理) を把握した。 次に、本プロジェクトが作成するシステムを稼働させるうえで必要なソフトウェアを抽出し、そ れに該当するレンタルサーバ側のソフトウェアのバージョンを調査し、プロジェクトが構築する開 発・テスト用サーバにインストールを行った。 具体的には、Web サーバソフトウェアとして Apache、Web ページ作成プログラミング言語と して PHP、データベースソフトウェアとして MySQL をインストールした。更に、顧客がデータ 管理の面でのシステム運用を補助するために phpMyAdmin の使用を提案し、了承を得た後、イン ストールを行った。 また、開発用サーバ構築の際には、システム稼働上必要なソフトウェアだけでなく、実装工程で 複数人作業によるファイルの差分競合を防止することやファイルの損失を防ぐために Subversion によるソースのバージョン管理環境を構築した。 実装工程中盤であった顧客との会議の中で決議された、顧客がシステムの本稼働前に自前で構築 したサーバで試験的な運用をしたいという話に対しては、顧客担当者が Linux をまったく経験し たことがないとのことだったので、システム稼働用のサーバとして構築しやすいディストリビュー ションを提案し、同時に学内にもそのディストリビューションで構築したサーバを追加設置した。 （※文責: 藤原哲） 4.3.4.2 データベース構築 本節では設計工程のデータ設計において設計したデータベースを実際に物理データベースへ適用 した過程とデータベースのチューニング、設計変更による作業について述べる。 Group Report of 2011 SISP - 30 - Group Number 10-A Practical Development of “Usable” System 2011 サーバでの物理データベース構築 学内に設置したサーバへは phpMyAdmin を利用し設計工程で作成したデータベース定義 の SQL を実行することで物理データベースを構築した。 phpMyAdmin はブラウザから MySQL 等のデータベースマネージメントシステムを操 作することが出来る。ターミナルからコマンドで操作することと比べると非常に簡単であ り、通常使用ではコマンドを知らなくとも操作が可能であることから世界中で利用されてい る。phpMyAdmin のスクリーンショットを図 4.14 に示す。 図 4.14 実際に稼動している phpMyAdmin データベースのチューニング データベースを構築した後、実際にシステムの設計規模に準じた大量データを入力し応答 時間を計測する等のテストを行い不都合があれば修正を行った。また、主に頻繁に検索され る項目についてはインデックスを作成することでデータベースでの応答時間を短縮する事が 出来た。 設計変更 データベースを構築したが設計に漏れが見つかったこと、機能実装において担当者からの フィードバックや顧客との話し合いにおいて変更が生じたことから実装担当者と連携しデー タベースの設計変更を行い、物理データベースへ変更点の反映を行った。 （※文責: 池田政人） 4.3.4.3 機能実装 10 月以降は機能の実装を行った。 本システムでは以下のユースケースを機能毎に切り分けた単位で実装を行った。 1. 仮予約 (施設選択) 2. 仮予約 (イベント選択) 3. 仮予約 (施設予約) 4. 仮予約 (総合予約) Group Report of 2011 SISP - 31 - Group Number 10-A Practical Development of “Usable” System 2011 5. 仮予約 (携帯版施設予約) 6. 仮予約 (携帯版総合予約) 7. 予約確定 8. 予約変更/キャンセル 9. 予約変更/キャンセル (携帯版) 10. 予約変更/キャンセル (管理者版) 11. 管理メイン 12. 代理予約 (施設予約) 13. 代理予約 (総合予約) 14. メンテナンス (アクセスコントローラ) 15. マスターデータ管理 16. 予約状況の閲覧 この切り分けによると、各実装単位にコントローラクラスを一つ持ち、機能を提供することな る。また、機能によっては共通のコントローラロジックを持っていたり、モデルクラスのメソッド の使い回しが可能である為、そういった部分も各担当者や設計担当者の間で連携を取りながら進行 していった。 本システムの機能の大部分は、CakePHP という PHP 向けのフレームワークを利用して実装 した。CakePHP の導入により、MVC に基づいた開発が保障され、バリデーションや DB アク セスに関する豊富なライブラリを利用することができるという利点があった。一方で、メンバに CakePHP に対する知識や利用経験が無かった為に、事前調査と調査担当者によるスキルトランス ファーが必要となった。しかし、CakePHP 自体がそれ程難解なフレームワークではなく、書籍や Web 等の参考資料も豊富であった為、メンバ間で密にコミュニケーションを取りながら互いの知 識を補っていくことができた。 本システムの目玉である予約機能の実装では、MVC の各層での作業分担を試みた。理由として は、各自で専門化した範囲を担当することで、開発作業の効率化とプログラム品質の向上を図った 為である。結果として、あまり期待した通りの効果は得られなかった。この人数では特定のメンバ への依存や負荷が高くなり過ぎるといった為であると考えられる。 開発の中盤に入ると、メンバの技能の向上が見られ、機能単位で担当者を立てて、実装を一任す る形を取った。これにより、タスクの依存関係による工期の無駄や、設計仕様の漏れによる手戻り を吸収することができた。機能毎に進捗状況が前後する為、優先度に基づいた見積もりが困難にな るといった問題はあるものの、手の空いたメンバが他のメンバの補助に入ることで解消した。 （※文責: 金谷祥平） 4.3.4.4 マニュアル作成 作成する予約システムに対するマニュアルというのを普段目にしたことがなかった。その為にど のような形式で作られているのかマニュアル作成の参考資料として他の予約システムのマニュア ルを探した。そして見やすくわかりやすい本システムの画面としてマニュアルで１ページごとに １画面（１手順）ずつ載せていく形式にすることに決定した。マニュアルには実際の画面を図とし て編集して載せて説明していく形式を取ろうとした。その為に PC 画面を画像として保存できる キャプチャソフト「カハマルカの瞳」と「Lunascape6」とその画像を編集するための画像編集ソ フト「ペイント」を使用した。予約システムを利用するためのマニュアルとして利用者用マニュア Group Report of 2011 SISP - 32 - Group Number 10-A Practical Development of “Usable” System 2011 ル・管理者用マニュアルがあった。そして phpMyAdmin によるデータベース直接入力のための phpMyAdmin マニュアルがあった。 利用者用マニュアル・管理者用のマニュアルで載せるべき事柄は成果物のユースケース記述・機 能一覧・RFP・スケジュール表で確認しながら図 4.15 のように表でまとめた。 それぞれ機能毎に一連の流れを実際に行った。そして１ページごとに表示された最初の状態を キャプチャした。システムのページが上下に長くブラウザウィンドウ１画面に収まらない場合は最 下部もキャプチャして初期状態と最下部を編集して合わせて掲載した。どのように操作すればいい のか例が必要だとされた部分はさらに画面中で操作や入力を行った状態の本システムの画面をキャ プチャして入力例などとして用意した。全てのキャプチャ画像は次の手順へ進む方法や操作するべ き部分を画像に色分けした数字と対応した色の線で操作部分を囲い画像の下に注釈として必要な手 順を記入して作成した。管理者用マニュアルの一部を図 4.16 に示す。 phpMyAdmin 用マニュアルはコード定義書とテーブル定義書を参照してそれぞれのカラム名 の意味と作成順序を確認しつつ作成した。また、利用者用と管理者用マニュアルと同様に手順ご とに本システムの画面をキャプチャして編集したものを画像として載せ、注釈を加えて作成した。 phpMyAdmin 用マニュアルは最初に本システムの予約をするためのプログラムの概念を知ってお かなければ phpMyAdmin で登録・編集・削除ができないので本システムの構成を説明する部分を 設けた。そして施設の作成から時間在庫の作成までをマニュアルに書いてある順に行っていけば しっかり利用者側から予約できるようになるように順番を考えて phpMyAdmin 用マニュアルを 作成した。時間在庫の生成など大量の登録が必要な部分は SQL 文直接入力で一括登録ができると いうことを補足という形で、対応する工程の最後に付け足した。また、各工程で使われるカラム名 とその入力方法をそのページ毎にコード定義書を用いて表で掲載した。 Group Report of 2011 SISP - 33 - Group Number 10-A Practical Development of “Usable” System 2011 図 4.15 管理者マニュアルの掲載項目確認の為の表 図 4.16 管理者マニュアルの一部 （※文責: 太田和輝） 4.3.5 4.3.5.1 試験工程 試験計画作成 テスト計画書 テスト計画書を作成するに当たって、まず、テスト計画書とは何かを、インターネットを Group Report of 2011 SISP - 34 - Group Number 10-A Practical Development of “Usable” System 2011 利用して調べた。また、計画書に必要だと思われる項目を、同じくインターネットを用いて 調べた。複数のサイトを参考に、その中から今回のテスト計画書に必要だと思われる項目を 選んだ。そうして項目を絞った後、項目の順序を考え、目次を作成して計画書を構成した。 内容を記述する際、スケジュールの見積もり・テストに動員する人員など、その時点では確 定できない事項があったので、それらは確定し次第計画書に盛り込んだ。また、テスト環 境・障害発生時の対策といった、現在確定されていないが、早急に確定する必要がある事項 も出てきたため、メンバに相談し、早急に決定、もしくはいつまでに詳細を確定できるのか を確認した。そしてそれもまた、決定し次第、計画書に盛り込んだ。携帯のテストの実施に ついては携帯機能の担当者に一任したが、テスト環境、使用するツール、テストを行うブラ ウザについては全体のテスト責任者と携帯機能の担当者が相談の上決定し、その詳細をテス ト計画書に盛り込んだ。また、テストを効率化するためにテストデータを自動入力できる ツールの使用を検討したが、上手く使いこなせず、調査に使う時間を他の作業に回した方が 効率的であると判断して、ツールの使用を断念した。しかし、品質向上テストはツール無し では非常に困難なため、使用ツールとして計画書に盛り込んだ。また、工程の遅れにより、 テストにかけられる期間が短くなっていたため、テストの一部を省略することにした。本来 は InternetExPlore・Firefox・Google・Chrome・Opera・Safari の 5 ブラウザにてシステ ムの機能を確認するのが望ましいところだったが、省略し、全てのテストケースを確認する のは InternetExplore のみにした。他のブラウザについては、基本シナリオとビューを確認 するのみとした。 テストケース 各 UC（ユースケース）の基本シナリオを軸として、エラーメッセージが表示されるケー ス、予想される誤動作のケース、各 UC の操作を組み合わせたケースを追加し、作成した。 そしてそれらのテストケースの手順、使用するテストデータ、テストの成否などを記録す る、テストの記録ともいえる試験成績表を作成した。試験成績表の詳細については後述す る。エラーメッセージについては、同じページで行う作業は一つのケースにまとめ、テスト ケース数の削減を図った。誤動作のケースについては、UI 設計とシステム仕様書を基に作 成した。複数の UC を組み合わせたケースは、各 UC の実装が完了するごとに、新たな組 み合わせを追加していくことにした。携帯のテストケースについては、携帯ではテストを行 わない UC があること、携帯では行えない動作があることから、PC 用のものとは別に作成 した。また、逆に携帯のテストにのみ必要なテストケースもあるので、それらのケースを別 途追加した。テストケースは、実際にテストを行ってみて初めて発見されるものもあるだろ うと考えられたので、シナリオテストと、考えられるだけのテストケースを作成したところ で、一度作業を終了した。そして、テストと同時並行で、新たに発見したテストケースを追 加していくことにした。また、施設予約と総合予約は、内部の仕組みは独立しているため、 手順がほぼ変わらないケースでも、施設予約用、総合予約用とそれぞれ分けて作成した。 以下の図 4.17 が実際にテストにて使用した試験成績表の一部である。全体的に読みやす いように、セルの幅や改行に気をつけるようにした。また、テストケースは UC ごとに整 列させた。また、それぞれのテストケースにテストケースの ID という意味で TCID という ID を割り当て、管理が行いやすいようにした。また、一目でテストの意図が分かるように、 テストの確認内容の項目には、なるべう詳細にそのテストケースの目的を記載するように心 がけた。また、テストデータの ID は、次の項目で説明しているものに対応させた。 テストには、確認結果が書かれていない試験成績表を試験成績表の雛形とし、テストのた Group Report of 2011 SISP - 35 - Group Number 10-A Practical Development of “Usable” System 2011 びにその雛形に結果を書き加え、別名をつけて保存、という形を取った。このため試験成績 表には、上部にテストのバージョンを記録するための欄と、テスト実施日を記録するための 欄を作成した。テストの最中に発見されたテストケースについては、そのテストに用いてい る試験成績表にそのテストケースを加えた後、雛形の試験成績表にも追加し、TCID などを ふりなおした。最終的には、テストの確認結果が全て可になっている状態を、テストの終了 とすることにした。 図 4.17 試験成績表 テストデータ テストの計画の作成を始めた時点では、森町にどのような施設があり、どのようなイベン トがあるかが分からなかったため、テスト責任者の方で仮の施設と予約を想定し、システム に入力するテストデータを作成した。顧客から施設とイベントに関するデータを貰った後 は、それらを基にしてテストデータを作り直した。テストデータは、シナリオテストに用い るデータを最初に作成し、そこにエラーメッセージを表示させるためのテストデータを追加 していく形を取った。携帯のテストケースは PC のものと異なっているので、テストデータ も携帯用に別途に作成した。テストデータにテストケースと同様にそれぞれ ID をふり、管 理しやすくすると同時に、テストデータと試験成績表を対応させやすくした。日付について は、システムの仕様上、予約できる期間が限られているため、当初作ったテストデータの日 付を越えてしまった場合は、テストの度に、新しい日付に修正した。また UC02 の管理者の 機能においては予約の一覧表示数の変更、予約のソートを行う際に障害が出ないかを確認す るテストがあるので、三十件の予約のテストデータを用意した。このテストデータはソート 機能の確認に用いるため、日付・施設・部屋・時間のいずれかを一致させることを意識して 作成した。 以下に実際にテストに用いたテストデータの一例 (図 4.18) を掲載した。これは顧客から 貰ったデータに基づいて作り直したものである。項番というのが各テストデータに割り振っ た ID のことであり、上から順に割り振った。ST というのはシナリオテストの略である。 Group Report of 2011 SISP - 36 - Group Number 10-A Practical Development of “Usable” System 2011 これらのテストデータはシナリオテスト・エラーケースのテスト双方に使用するものだが、 ここでは各予約の情報自体はある一つのシナリオであると考え、ST とした。利用者名には メンバの名前を使用し、施設名、部屋名、時間については情報を貰った施設のものを使用し た。利用人数・年齢・電話番号については、入力する値の大きさ自体には条件はないため、 Excel の機能を使用し、適当なものを使用した。メルアド、つまりメールアドレスは、仮予 約後の確認メールを受け取るあて先となるので、テスト担当者のメールアドレスを使用し た。町民であるかどうかの情報は「はい」と「いいえ」が両方正確に登録されていれば良い ので、一つ以上それぞれの選択肢を使用する、ということだけ決定しておき、後は適当に割 り振った。備品と連絡事項の欄については、その情報が必要なテストケースに対応したテス トデータにのみ必要なので、殆どのデータで空欄とした。他、ここには掲載しないが、団体 予約用のテストデータ、施設検索時に用いるテストデータ、代理予約用のテストデータなど も作成した。 図 4.18 テストデータ表 また、リマインダメールを同時に 100 通送信できるかどうかのテストのため、リマインダ メール送信の最低限の条件だけを満たした 100 件の空予約のテストデータを用意し、データ ベースにインポートできるよう、CSV 形式で保存した。この方法については、リマインダ メールのテストを効率よく行う方法を考案している際に、この機能を実装したメンバから提 案を受け、使用することにした。インターネットでデータベースへのインポートのやり方、 インポートするための条件を調べて、CSV を作成した。 4.3.5.2 試験実施 このシステムで最も重要な予約の機能である UC01 から、シナリオテスト、エラーメッセージ が表示されるエラーケース、誤操作によるエラーケース、複数の UC を組み合わせたケース、の順 にテストを行った。テスト実施中に、新たにテストケースが発見された場合はその都度試験成績表 にそのテストケースを追加し、それに伴い、必要な場合はテストデータも追加した。 テスト実施の前準備として、毎回各テストの前に、開発用の環境とは別にテスト用の環境を作 成した。テスト用の環境のディレクトリ名には SVN のリビジョン番号を管理番号に用い、テスト 用の環境のソースがいつのものなのか、特定できるようにした。メンバ全員にメールが行き渡る メーリングリストを用いて、ある時間までに開発バージョンの更新を済ませてもらい、その後、開 発用の環境をテスト用の環境に移設した。その際、環境を移設中に開発用の環境を更新しないよ う、事前のメールリストで併せて通達しておいた。また URL が変わったことによって不具合が生 じるので、その点は毎回環境移設後にテスト担当者が修正を加えた。 テスト中に障害が発生した場合は、下に掲載した障害管理表 (図 4.19) に、障害番号、テス ト ID、障害内容、障害が発生する手順、障害発生画面、障害発生日付、障害発見者、修正者を記入 し、テスト終了後に、テスト結果と共にメンバに連絡した。発生した障害については、明確に障害 Group Report of 2011 SISP - 37 - Group Number 10-A Practical Development of “Usable” System 2011 が発生する手順を見極められるまで、そのテストケースを繰り返し行った。なお、調べた結果、障 害の原因が開発用の環境とテスト用の環境の URL が違うことによるものだと考えられた場合は、 テスト担当者自らで修正できる範囲ならばその都度修正を行い、修正したことを障害管理表に記録 した。他、障害がテスト担当者自らの手に負えない場合は、テスト結果を通達する際に該当部分の 実装者を修正者に指名して、修正した。そして実装者には、修正が終了した後に、修正日付を障害 管理表に記入して貰った。もしその実装者の指名が誤っていた場合は、実装者同士で確認を取り、 障害管理表の修正者の項目を修正した。 障害管理表にも、管理がしやすいように ID を割り振った。BA というのは障害を意味する英 単語から取り、命名した。どの UC のテストで発生したか分かりやすいように UCID も記載して いるが、機能の中には UCID が存在しないものもあるので、その機能の場合は UCID の欄は空白 にした。障害発生画面は、画面の名前がメンバによって定められていた場合はその名前を使用し、 まだ決まっていなかった場合は、テスト担当者がなるべく分かりやすい仮画面名を考案し、記載し た。備考の欄には、障害が発生した画面をキャプチャしたもののファイル名、より詳しい障害発生 状況など、他の欄に書きにくい障害の詳細についてを主に記載した。 図 4.19 障害管理表 テスト中、システムの処理が正しく行われているかを確認するため、必要に応じてデータベー スにアクセスし、データの確認を行った。特にリマインダメールに関するテストの場合は、効率よ くテストを行うため、前述した空予約の CSV をデータベースにインポートし、空予約を挿入、そ の後にリマインダメールの機能を単独で実行させた。この際、リマインダメールの仕様上、予約の 日付はテスト日の翌日である必要があったため、テストのたびに日付を変更した。 携帯のテストに関しては、使用するソースは PC 版のとまとめて管理しているため、PC 版の テストと同時に開始した。テストは PC 版と同じように試験成績表の手順どおりに行い、結果を試 験成績表に記し、障害については PC 版とはまた別途の障害管理表に記述した。テストと、障害へ の対応の大まかな手順は、PC 版と同様に行った。 テスト終了後は、テスト中に新たなテストケースが発見されていた場合は、それを大元となる 試験成績表に反映させた。テスト中では無くても、新たなテストケースが発見された場合は、その 都度試験成績表に反映させた。また、実装者から障害の説明を求められた場合は、同じくその都度 それに応じ、障害の解説を行い、障害管理表の分かりにくかった点を尋ねた。そしてその意見を参 考に、障害管理表の内容・項目に修正を加えた。テスト計画に変更があった場合は毎回テスト計画 書も修正し、それらと平行して、テスト工程に関する調査を引き続き行った。発生した障害の修正 が完了、もしくは一つ以上の UC の実装が完成した時に、再びテストの準備をし、テストを行った。 （※文責: 武田麻依） Group Report of 2011 SISP - 38 - Group Number 10-A Practical Development of “Usable” System 2011 4.3.6 4.3.6.1 納品 システム導入 システムの導入は、試験工程の結果を反映させることに注意してソースプログラムをまとめる手 順を決定した。また、顧客に検収をしていただくために、本プロジェクトと同様のシステム環境を 用意していただき、ここに開発したシステムを納入させていただいた。システムを納品するにあた り納入物と顧客への当日アジェンダの提出や当日納入物のチェックリストなど事前準備の重要性に ついてはこれまでの工程より学んでおり滞りなくできた。また、本プロジェクトは当初予定してい た 11 月 30 日に納品を行うことができず、納品の対象を縮小し 3 回に分けて納品することで承認 をいただく形となってしまった。納期を守れないことは非常に惜しまれる結果となったが、顧客に 使っていただけるシステムを開発してきている本プロジェクトとしては、どのように納品したら実 際に使っていただけるシステムを最終的に納品できるかを考慮して段階的に納品を行うことになっ た。 1 回目の納品は、本システムは予約システムがメインとなるために利用者が予約し、各施設の担 当者がその予約を処理するのに必要な機能を納めた。 2 回目の納品は、各施設の担当者が本システムへ代理で予約できる機能や利用者用に携帯で予約 できる機能を納めた。 3 回目の納品は、導入した本システムを管理するために必要な機能である、各種マスタ情報（施 設情報、部屋情報、職員情報など）の登録や編集をする機能と 1 日単位で予約状況を確認できる機 能を納めた。 システム導入にあたり顧客へ納品した納入物は以下の通りである。 • 利用者マニュアル • 管理者マニュアル • 試験成績表 • ソースプログラム (morit) • システム利用実施手順書 • phpMyAdmin マニュアル • システム仕様書 • 画面仕様書 • データベース仕様書 • 更新履歴 • DVD-ROM 利用者マニュアルは、納品後利用者の方々に本システムを利用していただく際に使い方を説明す るため、顧客からいただいた RFP に納品するようにと記されていたために作成したものである。 管理者マニュアルも納品後にシステム管理者にシステムの使い方について説明するため、顧客から 納品するようにと指示されていたので作成した。 試験成績表は、本プロジェクトが行ったテストの結果について、システム導入後にその環境で同 様に動作するかをテストしていただくために作成したものである。ソースプログラムについてはテ ストを行った後のものを納品の対象とし更新して納入していった。これに伴って、システム仕様書 や画面仕様書、データベース仕様書を納品した。特に、システム仕様書については本プロジェクト はこの先続いて保守できる状況ではなくなるので、システムについての詳細クラス図やクラス定義 Group Report of 2011 SISP - 39 - Group Number 10-A Practical Development of “Usable” System 2011 書を納めることである程度の保守ができるようにと納品することにした。画面仕様書については画 面イメージと項目の説明をまとめ顧客へシステム画面についての仕様を確認いただくために納品し た。データベース仕様書については、本システムで使用するテーブルなどを確認していただくため に作成し納品した。 更新履歴については、納品時に前回の納品より更新された納入物が確認しやすいように納品した ものである。以上のデータについてまとめ DVD-ROM に書き込み納品を行った。 納品 1 週間前には顧客へ当日のアジェンダを送り、当日の活動をスムーズに行えるように心がけ た。納品毎に納入物のチェックをしていただけるようにドキュメントを作成した。 （※文責: 浅井信） 4.3.6.2 サーバ導入支援 顧客が森町公共施設管理予約システムの導入試験を行うにあたり、森町役場にシステムサーバを 設置することとなった。導入するシステムは、システム構築用サーバに使用しているディストリ ビューションの最新版を利用することとした。それは、システム構築用に設置したサーバでの技術 的な工数が格段に増えることが懸念されていたので、作業量を減ら競るような方針を採ったためで ある。その際、上述したように、構築中の森町公共施設予約管理システムの動作確認を行うために CentOS5.5 と CentOS6.0 のサーバを構築した。 顧客と同じ環境を構築するための方法として、実装班がシステム運用に必要な環境を先に構築 し、その際に取った手順を Linux のコマンドログと作成・編集したファイルやディレクトリを 1 つ ずつ分析しながら、具体的な作業手順をまとめたマニュアルを作成した。 顧客がマニュアルを基に森町役場へ設置を試みている際に、実行不可能な手順に関しては納品工 程の納品物と並行して、サーバ導入補助を行った。サーバ導入補助は 2 回行い、1 回目はシステム 運用に必要なソフトウェアパッケージのインストールとその設定を主に行った。2 回目は森町公共 施設予約管理システムをサーバで作動させるためのアプリケーション本体に関する設定を行った。 （※文責: 藤原哲） 4.3.7 イベント 本開発の途中で、顧客との打ち合わせや成果の確認が三度、また学内で本 PBL の成果を報告す る成果発表会が二度あった。ここではそれらのイベントについて我々が行った準備、成果を時系列 を追って示す。 （※文責: 若山将太） 4.3.7.1 森町訪問 6 月 22 日に、プロジェクトメンバ全員で森町公民館へ訪問した。その目的は現状業務の把握で あり、提案工程で提案したシステムで顧客の要求を正確に把握するすることであった。 これまでプロジェクトではメール等で現状業務への質問をしていたが、それだけでは不十分だと 感じていたためだからである。 森町の訪問に向けて、実際に訪問し質疑応答を行える滞在時間や、滞在中に訪問できる施設の有 Group Report of 2011 SISP - 40 - Group Number 10-A Practical Development of “Usable” System 2011 無、プロジェクトメンバ間で列挙した質問事項などを一週間前まで確認した。 1 時間という限られた訪問時間で効率よく議論が行えるよう、質問事項に優先順位を付けた。 また、それを基にタイムテーブルを作成し当日メンバと顧客がどのように行動するかを決め、顧 客へメールでお渡しし確認・合意して頂いた。 当日は公民館へ訪問できることが可能ということがわかったため、公民館へ実際に業務見学を行 う班と、顧客である役場管理者に現状業務やシステムへの質問事項を確認するヒアリング版と 2 つ の班に分かれて行動することとなった。 さらに効率よく議事録を残すために、議事録に加えて写真やビデオ撮影を行う記録係という役割 も設定し当日行動するようにした。 当日、公民館へ向かった班は施設担当者に帳票の取り扱い方を確認し、定期予約と競合する予約 の取り扱い方や帳票の判の意味など予約業務に関する質問をした。その後は業務フロー図と現状業 務を比較し差異が無いかどうかなども確認し、実際に予約業務の一連の流れを見学した。 一方のヒアリング班は、施設や貸し出し対象となっている備品等のシステムの予約対象物の確認 や、サーバのハードウェアスペックやインストールしてあるソフトウェアの内容、予約時間の単位 などシステムの仕様の決定につながる質問を行った。その後、メンバ間で列挙したシステム名の案 をシステム名の候補として提案した。最後に全員で全体に対する質問を行い訪問の日程は終了し た。 この訪問を通して As-Is 業務フロー図をより現状業務の形に近づけることができたり、帳票の項 目の意味も確認でき E-R 図など要件定義の成果物も現状業務から大きく外れた仕様とならずに済 むことができた。 （※文責: 長坂明輝） 4.3.7.2 中間発表会 7 月 15 日に行われた中間発表会では、まず準備のために担当者と優先度を決定した。プロジェ クトメンバ毎に他のタスクを抱えていたので、優先度をつけてシステム開発の進捗が滞らないよう に担当者を決めた。 ここで大きく分けて発表用スライド作成班とポスター作成班に分かれ各班で作業を進めた。 発表用スライド作成では、まず成果発表会で言いたい内容を明確にし、発表の流れが不自然にな らないように、またプロジェクトメンバが行なってきた内容を網羅しているかどうかを意識しなが ら作成した。 ポスター班では、限られたスペースに前期中本プロジェクトが行った活動について纏める必要が あり、また読み易いように見た目を工夫しながら作成した。 スライドの叩き台の作成が終わった段階でプロジェクトメンバで集まり、発表の練習を行った。 練習する期間が少なかったため、一回の発表を二人で行う形にして、一人の発表部分を短くして 行った。 当日の発表ではスライド発表の他に前期中に本プロジェクトが作成した文書を公開し、発表中に それらの文書を利用することで聴衆者に行った内容を理解してもらえるように工夫した。 （※文責: 若山将太） Group Report of 2011 SISP - 41 - Group Number 10-A Practical Development of “Usable” System 2011 4.3.7.3 デザインレビュー 8 月 2 日に、学内において顧客である森町様とアドバイザである IBM メンバとご一緒にデザイ ンレビューを行った。その目的は要件定義の成果物について最終確認を行うためであった。 実際に確認を行った成果物は、ユースケース図、To-Be 業務フロー図、プロトタイプ (画面遷移 図と画面プロトタイプ, トップページデザイン案)、データモデル関連物 (ER 図, レコードサンプ ル, データ項目一覧, コード定義書)、非機能要件とシステムに実装する機能一覧である。これらの ドキュメントはすべて印刷され、顧客及びアドバイザ全員へお渡しした。 森町訪問と同様に、タイムスケジュールやアジェンダを作成し事前にお渡ししておくと同時に質 問事項に優先順位をつけた。直前までメンバは質問事項や懸案事項を列挙し続けた。 またアドバイザのご助言を基に、座席の位置決めを行ったり確認する内容の一覧を先に提示する などプレゼンテーションにも工夫を凝らした。 ユースケース図を用いて、顧客とシステム全体像の把握を行い機能の過不足がないか確認でき た。システム化後の業務の流れを表現した To-Be 業務フロー図を用いて、システム利用の具体的 な流れの確認を行い現状業務と比べて不都合はないか確認することができた。 画面遷移図を用いたことによってシステムの持つ画面に過不足がないかを確認することができ た。実際に画面プロトタイプをご覧になっていただき、画面が持つ機能が必要十分であるかを確認 することができた。画面プロトタイプではデザイン面を排除したが、トップページデザイン案をご 覧になって頂きデザインを決定したことにより、デザインのみに集中してレビューして頂くことが できた。 データモデルの説明を行ったことで、必要な項目は揃っているかを確認することができ、予約時 のデータの動きも確認できた。機能一覧と非機能要件（パフォーマンスやセキュリティ等機能とし て定義されない部分）について確認して頂き、お互いにシステムの持つ機能を確認することもでき た。 データベース内の関係性を示した E-R 図、実際にデータベースにどんなデータが入るかを示し たレコードサンプル、データベースに含まれる項目を一覧にしたデータ項目一覧、データ項目にお いてどのようにコードを使われるか示したコード定義書をご覧になって頂いた。それにより、実際 にシステムが予約情報をデータベースに読み書きされていくかデータの流れを確認することができ た。 このイベントを通して、噛んでしまったりお客様に向かってしゃべることができない、資料のタ イトルのつけ忘れがあった、時間管理が甘くメンバ集合に時間がかかった点などが反省点として挙 げられた。お客様と面と向かって会話ができなければ説得力も欠け、印象に残らないプレゼンテー ションとなるし、資料送付が遅れたり噛んでしまったりする点に至ってはリハーサル不足が根本的 な原因だとわかった。 （※文責: 長坂明輝） 4.3.7.4 画面仕様確認 11 月 4 日に行われた画面仕様確認では、8 月 2 日に行われたデザインレビューと同様に顧客の 森町様に学内へ来て頂いた上で行われた。本来はシステムの画面の仕様を決定づけるためが目的だ が、今回はそれに加えて 9 月 30 日にプロジェクトの進捗管理方法を見直したことをきっかけに 10 Group Report of 2011 SISP - 42 - Group Number 10-A Practical Development of “Usable” System 2011 月 7 日に新体制としてプロジェクトを再発足し、実装する機能に優先順位をつけ順に実装を行える ようなリスケジュールの内容についてご承認を頂くことも含まれており、どちらの目的も大きいも のであった。 実装の進捗管理において定量的な評価方法を採用するのに時間がかかり、その上実装も遅れてし まったため、体制を組みなおしてプロジェクトを立て直すという姿勢を見せる意味も目的に含まれ ていた。 今回もスライドとアジェンダ、画面仕様書や WBS、質問事項リスト等を事前に用意し印刷した。 また事前にスライドをチームでレビューを行いアジェンダの調整も行った。 まず初めにユースケース図を用いてシステムが果たす役割・機能をご確認して頂いた後に、画面 遷移図を用いてユースケースに登場する画面の流れの概要を説明した。 その後、実際の開発中の画面をプロジェクタで投影し、実際に動く様子を見ながら確認して頂い た。しかし実装途中の画面と画面仕様書には差異があり、今後のシステム実装でどちらを正式に仕 様として決定づけるか悩ませることとなった。 その点を除けば、「営業日」等語句の表記変更や施設の連絡先を表示するタイミング、管理者画 面で予約を確定する際の予約一覧のソート順、メールアドレスの確認画面での文言やシステム障害 発生時の対応方法なども細かい懸案事項も画面を通じて確認することができ有意義だった。また、 レポート出力機能を phpMyAdmin の CSV 出力で代用して頂くことを承認して頂いたり、 11 月 30 日の納品分マニュアルはシステム導入手順書と利用者マニュアルの 2 つとしてよい点、docomo の 2009 年夏以前の携帯電話を動作保障外として良い点、ブラウザ対応の優先順位など今後の納品 物に関する打ち合わせも行うことができた。 顧客と直接ご対面できる機会は少なかったため、それらに加えてさらにプロジェクト内でたまっ ていた質問事項もいくつか確認することができた。それにより、施設によっては時期や時間帯に よって料金体系が異なる点など把握することができ、今後システムに大きく影響を与えそうな仕様 と現状業務とのずれを確認することができ良かったと考える。 （※文責: 長坂明輝） 4.3.7.5 成果発表会 12 月 9 日に行われた最終成果発表会では、まず中間発表会と同じように担当者と優先度を決定 した。この時は納品の期日を間近に控えていたので発表用スライド作成班とポスター作成班を中間 発表会の時よりも減らして準備を進めた。 発表用スライドは中間発表会の評価シートで指摘された内容を踏まえて作成し、プロジェクトメ ンバが集まる都度全体で共有し、修正を加えていった。 ポスターは中間発表会のときのものを基に後期の内容を加えて作成した。 中間発表会のときは練習する期間が短く、一回の発表を二人の発表者で行ったため発表がスムー ズに行えず、その点の指摘も評価シートに書かれていた。それらを踏まえ、今回は発表者を一人に し、発表前から発表後の流れまでを明確に決めて発表全体がスムーズに流れるように行った。ま た、今回はシステムが聴衆者に見せることが出来る段階まで出来上がっていたのでこれを使用した デモも担当者を用意して行った。 また今回はアドバイザに発表用スライドと各発表者に対してレビューを頂いて中間発表会のとき よりも完成度が高いスライド、発表に仕上がった。 Group Report of 2011 SISP - 43 - Group Number 10-A Practical Development of “Usable” System 2011 当日の発表では、中間発表会のとき、評価シートの多くに声が小さいと書かれていたのでプロ ジェクトメンバ全体で意識し、発表もスムーズに行えた。 （※文責: 若山将太） Group Report of 2011 SISP - 44 - Group Number 10-A Practical Development of “Usable” System 2011 第5章 5.1 個々の課題への取り組み 各人の課題の概要とプロジェクト内における位置づけ 太田和輝の担当課題は以下のとおりである。 4月 関連サイト・技術調査とツールの準備 5月 システム提案書の修正 5 月-7 月 画面遷移図作成・中間成果発表会 10 月-12 月 マニュアル作成 11 月 成果発表会スライド作成 12 月 納品・最終成果発表会 （※文責: 太田和輝） 金谷祥平の担当課題は以下のとおりである。 4月 関連サイト・技術調査とツールの準備 5月 開発体制図作成ハードウェア構成図作成 5 月-6 月 業務フロー図作成 6 月-7 月 ユースケース記述作成・ロバストネス図作成・分析シーケンス図作成・中間成果発表会 9 月-10 月 詳細設計 (詳細クラス図・詳細シーケンス図) 作成 10 月-1 月 機能実装 12 月 納品・最終成果発表会 （※文責: 金谷祥平） 浅井信の担当課題は以下のとおりである。 4月 関連サイト・技術調査とツールの準備 5月 携帯サイト調査機能一覧作成 6月 非機能要件作成 6 月-7 月 ユースケース記述作成・ロバストネス図作成・中間発表用スライドの作成・中間発表会 10 月 新体制案の提案とリスケジュール・WBS の作成 10 月-1 月 機能実装進捗管理 11 月 プロジェクト活動報告 12 月 納品・最終発表会 （※文責: 浅井信） 藤原哲の担当課題は以下のとおりである。 Group Report of 2011 SISP - 45 - Group Number 10-A Practical Development of “Usable” System 2011 4月 関連サイト・技術調査とツールの準備 5月 開発コスト見積作成 5 月-6 月 業務フロー図作成 6 月-7 月 プロトタイプ作成・FreeBSD サーバ構・中間発表会 8 月-9 月 システム環境構築 (FreeBSD) 10 月 システム環境構築 (CentOS 5.5)・システム開発環境構築とメンバ環境設定 11 月 システム環境構築 (CentOS 6.0)・サーバ導入マニュアル作成 10 月-1 月 システム開発 12 月 納品・顧客サーバ構築補助・最終発表会 （※文責: 藤原哲） 若山将太の担当課題は以下のとおりである。 4月 関連サイト・技術調査とツールの準備 5月 プロジェクト計画書の素案作成・ステークホルダリスト作成 5 月-6 月 業務フロー図作成・ユースケース図作成 6 月-7 月 ER 図作成・CRUD 図作成・データ項目の正規化 7月 要件定義書作成・中間発表会 8 月-9 月 PHP 技術習得・HTML 技術習得・CSS 技術習得 10 月 携帯端末用ページ作成のための技術調査 10 月-12 月 携帯端末用ページの実装 12 月 画面仕様書作成・試験成績表作成・納品・最終成果発表会 （※文責: 若山将太） 武田麻依の担当課題は以下のとおりである。 4月 関連サイト・技術調査とツールの準備 5 月-6 月 As-Is・To-Be 業務フロー図作成 6 月-7 月 プロトタイプ作成 7月 画面設計の基盤の作成・中間発表会 8月 テスト工程の調査 9 月-10 月 エラーメッセージの作成 9 月-10 月 テスト計画の考案 11 月-12 月 テスト実施・最終発表会 （※文責: 武田麻依） 長坂明輝の担当課題は以下のとおりである。 4月 関連サイト・技術の調査と報告 5月 システム提案書の作成 5 月-6 月 帳票プロトタイプ (CSV 版、HTML 版) FreeBSD サーバ構築 6 月-7 月 プロトタイプの作成 FreeBSD サーバ構築 8 月-9 月 HTML 技術習得・CSS 技術習得・JavaScript 技術習得 10 月-12 月 システムのビュー制作・最終発表会 Group Report of 2011 SISP - 46 - Group Number 10-A Practical Development of “Usable” System 2011 （※文責: 長坂明輝） 江戸太樹の担当課題は以下のとおりである。 4月 関連サイト・技術調査 5月 提案書の作成・全体スケジュールの立案 5 月-6 月 業務フローの記述・森町訪問に向けての資料作成 6 月-7 月 ユースケース記述作成・ロバストネス図作成・中間発表会 7月 中間発表ポスター制作 9月 新体制に向けての準備 10-11 月 ユーザインタフェース設計 12 月 最終発表ポスター制作・納品・最終発表会 （※文責: 江戸太樹） 池田政人の担当課題は以下のとおりである。 4月 関連サイト・技術調査とツールの準備 5月 提案，ソフトウェア構成図作成 5 月-7 月 データ項目の抽出 6 月-7 月 森町訪問，データ項目の正規化・E-R 図作成 CRUD 図作成 7 月-8 月 コード定義作成・データベース設計・中間発表会 8 月-9 月 データベースの運用に関する学習・MySQL の学習・実装に向けた cakePHP の学習・ Web アプリケーションのセキュリティに関する学習 10 月 データベース構築 10-12 月 データベース調整・実装・納品準備・納品・顧客サポート・最終成果発表会 （※文責: 池田政人） 5.2 担当課題解決過程と他の課題との連携の詳細 5.2.1 太田和輝 4月 関連サイト・技術調査とツールの準備 予約システム作成のために Web 上で予約を行う方法とその使いやすさ、見やすさを 調査した。調査のために別の町の公共施設予約システムや旅館予約システムを参考にし た。それぞれトップページの見やすさと予約方法を利用の流れなどを見て調査した。予 約のためには検索による絞込みも必要だったため、その方法もチェックボックスやコン ボボックス等があったためどのような形が見やすく検索しやすいか等を調査した。公共 施設の予約ページには運営中のみ予約ができるというものも存在したため、それを発見 するまで自分の中では常識だと感じていたインターネット上では 24 時間いつでも予約 できるという事が覆され検討が必要だと思われた部分を発見していった。システム構築 の為のプログラミング言語の調査と選択ではインターネットサイトによってそれぞれの 特徴を学校の授業で習った言語に一番近いものを候補にしようと考えつつ調査した。そ Group Report of 2011 SISP - 47 - Group Number 10-A Practical Development of “Usable” System 2011 して成果物作成の為、astah*をインストールした。さらに成果物をアドバイザやメンバ と共有するために Web 上でのデータ共有ができるサイボウズ Live への登録を行った。 サイボウズ Live ではその使用方法を確認した。 5月 システム提案書の修正 システム提案書にある用語と文体の統一がとれているかを確認し、さらにアドバイザ からの指摘も参考にして修正していった。特に図の修正で図の中の文体を新たに作成す る文体と統一するのに手間を取ってしまった。システム提案書を成果物として完成させ る為に 1 カ月も時間がかかってしまったが提案書の修正によって用語集での言葉の確認 と修正も並行して行った。 5 月-7 月 画面遷移図 画面遷移図作成のために astah*を機能と使い方を確認して利用した。予約システム 作成の時の画面の遷移を明らかにするために RFP・システム提案書・機能一覧・As-Is 業務フロー図・To-Be 業務フロー図・ユースケース図を基に作成し、利用者用 PC サイ ト・利用者用携帯サイト・役場担当者用サイト・役場管理者用サイトを astah*にて作成 した。作成開始当初はそれぞれの成果物が完成していなかったため、RFP から抜粋し どのようなページが存在するのかを Web 上の関連サイトを参考にして作成した。その 後成果物との競合性を取りながら修正を加えていった。画面遷移図によってそれぞれの 機能がシステムのどの部分とつながって利用されてどのような画面が必要であったのか がわかるようにした。しかし、大まかに決まっているところからさらに掘り下げていく と画面 1 ページでまとめられるはずのページが複数のページに渡っている事や検索機能 の分岐があいまいであったので改善していく余地があった。そのため１ページに収まる ことになった機能は枠線で囲みページ内にどのようなリンクがあるのかを記した。 10 月-12 月 マニュアル 全体のマニュアル作成の参考のためにまずは他のインターネットサイトでの予約シス テムのマニュアルを複数調べた。そしてまずは私が見やすくわかりやすいというものと はどういうマニュアルなのかというのを考えながらマニュアルを作成した。作成には ワープロソフトとパソコン画面を画像にするためのキャプチャソフト「カハマルカの 瞳」と「Lunascape」 、画像編集の為にペイントソフト「ペイント」を利用して利用者マ ニュアル、管理者マニュアル、phpMyAdmin マニュアルの 3 つを作成した。 利用者と管理者のマニュアル作成ではそれぞれに使用される機能を成果物のユース ケース記述・機能一覧・RFP・スケジュール表を用いて確認と抜粋をしていった。そし て作成開始時は予約システムが未完成だったので画面と画面遷移のイメージをつかむた めに UI 設計画面・画面遷移図を利用した。UI 設計画面を一時的にマニュアルに挿入 して画面遷移がわかるようにした。さらに注釈を入れて一度マニュアルの基盤を作成し た。予約システム実装後は実際の予約システム画面をキャプチャして使用した。キャプ チャ時の画面のサイズを各ページで統一するためにキャプチャソフトの機能にあった キャプチャ範囲の登録を行ってからキャプチャすることによって画面の大きさの統一を 行った。ページの画面は UI 設計の画面名を用いた。キャプチャした画像はそのまま使 用するのではなく、その画面では何をするべきなのかとどこへ入力したらよいのか、そ Group Report of 2011 SISP - 48 - Group Number 10-A Practical Development of “Usable” System 2011 して最後にどこを選択したら次の手順（画面）へ移れるのかをキャプチャした画像に工 程ごとに色分けしたマークと数字を記入し、画面図下方に注釈とするべき事柄の詳細を 書き込んでいった。1 ページが縦に広く、PC 画面に収まりきらないときは最初に表示 される部分とそのページの最後の部分をキャプチャしてページの中間は中略として編集 して１枚の画像に収めた。実際にわかりづらいであろう一部の入力部分や 1 ページが 大きくて収まりきらなかった部分は個別にページ内に入力例などを実際に入力してから キャプチャをした。また、注目するべきところは表示画面を拡大してキャプチャした。 phpMyAdmin マニュアルはデータベースへの入力が要求されていた。コード定義書・ テーブル定義書を参照してそれぞれのテーブルにどのような情報がどのような形で格納 されているのかを実際に入力してシステムでの反映を確かめながらマニュアルを作成し ていった。データベースへの直接入力によって予約ができるようになるには、その仕組 みが理解できないと手順通りにやってできても実際には何を入力しているのかわからな いと私が実感したということと、作成の順序を間違えると新規で予約用データや予約用 空き時間を作成できないことがわかった。だから最初に予約システムのデータベースの 形とそのデータのつながりを表と文による説明を入れた。マニュアルの順序は概念から 始まって順を追っていけば自然と利用者側が予約できる形になるように構成した。利用 者マニュアル・管理者マニュアルと同じようにして 1 ページ 1 画面を基本として遷移す るためのボタン、入力例を書き加えていった。phpMyAdmin では直接 SQL 文章を打 ち込むことで情報を入力できたことと、予約用の時間在庫は 1 日に数十個必要であった 為、一度にたくさんの入力ができるように SQL 文章での入力方法が良い所はそうでき るように入力例の画面を用いて各画面の最後に補足という形で作成した。 11 月 成果発表会スライド作成 成果発表会の為のスライドを作成するために章立てを行った。章立てでは中間発表会 で使用されたスライドをもとに年間通しての活動報告の発表内容の順番を決めた。次に 議事録・アドバイザーから頂いた資料・成果物を確認して活動報告のスライドを作成し た。活動報告のスライドの後には結果と反省を加えた。スライドはメンバとレビューを 繰り返してスライドの前後での流れがつながっているのか・本システム作成で発生した 出来事とその解決過程がきちんと盛り込まれているかどうか・成果発表で伝えたかった 事が盛り込めているのかどうかを確かめてメンバと作成した。作成したスライドはさら に発表練習によって聞き手による見やすさを文字と図の位置・図の表現の変更によって 改善させた。 成果発表会 成果発表会ではスライド発表を行った。成果発表会スライドを確認して各スライドで 聞き手に注目してほしい所と補足して言葉で説明するところを発表練習でメンバで意見 を交換し合った。特に当日の発表前の練習ではお互いに発表に対するレビューとアドバ イザの指摘で姿勢と言葉の良い点悪い点、声の大きさを確かめ合った。 12 月 納品 納品の第 1 回目は利用者マニュアル・phpMyAdmin マニュアルを PDF 形式のデー タファイルの用意とプリンタによる印刷を行った。納品前の顧客との本システムの確認 では要望・質問を記録した。納品の第 2 回目は管理者マニュアルを PDF 形式のデータ Group Report of 2011 SISP - 49 - Group Number 10-A Practical Development of “Usable” System 2011 ファイルを作成して準備をした。 その他年間を通して 用語集 各成果物で使用する言葉を統一することと言葉の意味の理解を共有する目的で用語集 に定期的に言葉とその意味を追加して編集を行った。用語集は Google ドキュメントに よる共有で誰でも編集と確認ができた。成果物を作成するには別の成果物と言葉を統一 するために成果物作成時には常に目を通した。レビューやグループディスカッションで 出てきた言葉は用語集で確認をし、言葉が無かったときは追加を行った。 議事録 レビューやグループディスカッションの時はメンバ内で議事録担当者を決めて議事録 を記録して共有した。議事録はレビューやディスカッション中は議事録メモを取り、議 事録メモから議事録を PDF ファイルにして Doropbox を用いて共有を行った。 前期での議事録作成はメンバが先に作成していた議事録を参考に作成した。議事録メ モではワープロソフトを使用した。議事録メモのデータを言葉の見直しを用語集を用い て修正した後に議事録とした。その為見づらいものになっていた。 後期では議事録メモを３色ボールペンと蛍光ペンを用いて紙に記録した。レビューや グループディスカッション中に議論されたことや板書を時間軸順に議事録メモとして記 録していった。特に言葉による説明や問いは聞き逃さないようにした。質問とその解答 は矢印を使う事で後から見てわかりやすいようにした。特に決議事項となりえるところ と質問や問題、そしてその解決方法と回答はメモ中に蛍光ペンや赤ペンによるマーキン グを行った。レビューでは決議事項と質問やその回答等は最後にまとめとして発表する 為にレビュー中に議事録と並行して纏めやすいようにマークを付けた。 議事録メモから議事録を作成するときはワープロソフトを使用した。議事録にはその日 時と場所、参加者を記入した。更に議事録メモから決議事項と質問やその解答等をセク ションごとに分けて記入してメンバが見てわかりやすいようにした。 （※文責: 太田和輝） 5.2.2 金谷祥平 4月 関連サイト・技術調査とツールの準備 4 月の終わりに各種の調査と今後使用するツールの準備を行った。まず、今回開発す るシステムに類似したシステムの調査を行った。調査の際にはまず、予約サイトに目を 付け、Web 上から予約を行えるサイトを探した。次に、使用可能なプログラミング言 語の比較を行った。予備知識が殆ど無かった為、Web 上から断片的に情報を集める程 度に留まった。また、astah*のインストールと、サイボウズ Live への登録はスムーズ に完了した。astah*は UML やマインドマップ等の図が描ける事を確認し、サイボウズ Live ではファイル共有やメッセージの機能がある事を確認した。 5月 開発体制図作成 提案工程では、提案書に掲載する開発体制図を作成した。開発体制図は本プロジェ クトがどういった体制で進行してゆくのかを顧客にご確認頂く為の図である。私は Group Report of 2011 SISP - 50 - Group Number 10-A Practical Development of “Usable” System 2011 このような図を描くのは初めてであったので、アドバイザのスライドを見たり、リー ダーから助言を貰うなどしてより正確な図を作成する事ができた。また、作成には OpenOffice.org Impress(MS Office PowerPoint に相当) を使用した。この作業を通し て、本プロジェクトのあり方と外部との関わり等が理解できた。また、体制図の中でプ ロジェクト内の作業分担についても考える機会があり、今後の開発の形をイメージする ことができた。 ハードウェア構成図 提案工程では、ハードウェア構成図の作成も行った。作成に当たっては、RFP の別紙 として配布されたシステムの概略図と、レンタルサーバのスペックに関する資料を参照 した。当初、OpenOffice で描画できる矩形と円だけで図を表現しようとしたが、提案 書としては見易さが重要だと考え、Web 上からフリー素材を探して利用するに至った。 5 月-6 月 業務フロー図作成 要件定義工程では、業務フロー図の作成に当たった。業務フロー図には As-Is と To-Be の二種類があり、As-Is の方は現状 (システム化前) の森町役場の施設予約関連 業務を図示した物である。私は、施設予約の業務フロー図を作成したが、当初手違いで フローチャートで作成してしまった為、他の図に合わせてアクティビティ図で描き直す 事にした。また、To-Be の作成は予想以上に困難であった。まず、To-Be は As-Is と違 い、こちらで新たに定義していく必要がある為、提案段階で決定した機能に曖昧な部分 があると、詳細な業務フロー図の作成は困難であることが挙げられる。これについては 順次メンバと検討を行い解消していった。そして、システムが絡み、表現しなければい けない範囲が広がった事により、図が巨大になり、見難くなってしまった事が挙げられ る。複数回に渡るレビューによる指摘を受け、作成者全員で図の描き方やアクション名 の記法を統一する事で可読性については向上した。この課題は前期の活動中最も多くの 時間を掛けたが、その分システムに関する理解や UML 図を描く際の注意点について気 づく事ができたので非常に大きな学びとなった。 6 月-7 月 ユースケース記述作成 ユースケース図と業務フロー図を基に、ユースケースの詳細を文章化するユースケー ス記述を作成した。私は、以前に業務フロー図を作成していたのでその時の担当範囲に 該当する部分を作成した。ユースケース記述は図ではなく、文章で全てを表現するもの である為、曖昧な表現とならないよう注意が必要となった。また、顧客に見せるもので ある為に可読性にも注意して書かなければならず、業務フロー図以上に粒度に気を使う ことになった。また、全記述のチェックと修正も行ったが、表現の違いが多々あり、統 一に苦労した。 ロバストネス図作成 設計工程の初めとして、ロバストネス図を作成した。作成に当たっては、以前作成し たユースケース記述からバウンダリ・コントロール・エンティティクラスに該当するも のを抽出して、それらを線で結んでいった。当初は一つの記述から複数のコントロール が抽出されたが、あまりに膨大な数となってしまい、後のシーケンス図の作成が困難に なると予測された為、アドバイザのアドバイスに従い一度コントロールを 1∼2 個に纏 める事とした。また、エンティティについては、データ班によるデータ項目・E-R 図 Group Report of 2011 SISP - 51 - Group Number 10-A Practical Development of “Usable” System 2011 の正規化が行われたので、それを参照し、整合性を持たせた。この図を作成した事によ り、今後の設計の大まかな指針ができた。 分析シーケンス図作成 システムの静的な構造を記述したロバストネス図に対し、動的な振る舞いを記述する シーケンス図の作成が必要となり、作成した。ユースケース記述で記述されている系列 に従い、ユーザとシステムのやり取りや、システム内の各クラス間のやり取りを時系 列的に記述した。図の表記は UML に準拠し、必要に応じてメモを付記した。この図の 作成からロバストネス図の修正点を見つけ出し、より洗練した分析モデルを作成して いった。 8 月-9 月 設計についての調査 設計の手法について、書籍や Web サイトから情報を集めた。調査内容を基に、9 月 の下旬頃から詳細設計に取り掛かることができた。 9 月-10 月 詳細設計・詳細クラス図作成 ロバストネス図をより内部的なモデルとして詳細化し、詳細クラス図・詳細シーケン ス図に落とし込むという手順を取った。詳細クラス図はロバストネス図の概念的な構造 を実装レベルのクラスにブレークダウンしたものを作成した。また、その際モデルクラ スについてはデータベース設計の成果を参照しながら定義していった。各クラスにおい て定義されるメソッドやプロパティは、分析で導出されたものの他、並行して行った詳 細シーケンス図作成で導出されたものも含み、いずれも実装レベルでの定義を行った。 ここで定義された仕様は実装に反映されたが、想定していなかった仕様漏れや仕様変更 が生じた部分については後追いで設計図の方を修正するということが多かった。 詳細設計・詳細シーケンス図作成 一連のユーザとシステムのやり取りの中でのシステムの動的な振る舞い及び各クラス のやり取りを記述するシーケンス図を作成した。分析シーケンス図との違いは、詳細 シーケンス図では詳細クラス図を用い、実装レベルのシステムの振る舞いを記述してい る点である。この図の作成を通して、詳細クラス図のクラス定義を過不足ないものとし て調整することができた。 10 月-1 月 機能実装 システムが提供する機能のうち、幾つかの作成を担当した。また、モデルクラスは全 体の機能に関わる部分である為、詳細設計に基づいて必要なメソッドやプロパティを実 装した。また、CakePHP ではモデル及びコントローラについてユーザ定義可能な共通 基底クラスが存在する為、共通のロジックや管理者・利用者向けの機能やレイアウトを 統括的に制御する機構を設けたりした。 この工程では、機能実装をユースケースを幾つかの機能に分けた単位で行った。具体 的には、一つの実装単位で MVC におけるコントローラクラスを一つ持つ形となる。私 が担当した範囲については詳細設計に含まれない範囲があった為、実質的に設計も含む 作業となった。その際、コントローラが肥大化しないよう、モデルクラスで用意された メソッドを再利用するようにし、コントローラに書かれたロジックで共通化できたり、 データ構造に関連する部分を基底クラスのメソッドやモデルメソッドとして整理し直し Group Report of 2011 SISP - 52 - Group Number 10-A Practical Development of “Usable” System 2011 た。 モデルクラス実装は設計に基づいて基本的な機能を整備していった。設計で仕様化し たのはメソッドの外部的な仕様までなので、実装の際に仕様通りの機能を実現するア ルゴリズムを考慮した。その際に特に意識したのが、データベースアクセスによるパ フォーマンスの低下や、サーバへの負荷を軽減する為にクエリ発行回数をなるべく減ら すという点である。例えば、プログラム中のループ命令中で行っていた検索を、検索条 件の見直しにより一回の検索命令に置き換えるといった工夫を凝らし、大幅にパフォー マンスを向上させる事に成功した。 実装の大まかな作業は上記の通りであるが、その他にも本システムの特徴として挙げ られる管理者/利用者での機能分離を実施する為には工夫が必要であった。特に、複数 のメンバが実装に携わり、共通のモデルやエラー関連のクラスを利用するという都合 上、統括的に機能分離に対応する事が必要となった。具体的には、設計段階でモデルク ラス等の実装を分離して運用できるように設計しておく、または、基底クラスでの制御 機構の実装と多態性を利用した振り分けが考えられた。今回は後者の方針で、モデルク ラスやエラー関連クラスの挙動をコントローラ毎に振り分けるように実装した。 12 月 納品 納品に際して、システム仕様書の取り纏めを行った。システム仕様書では、設計工程 で作成した詳細クラス図に実装時に発生した仕様変更のフィードバックを行い、その 他に必要と思われるクラス定義書を作成した。クラス定義書では、各クラス実装者に PHPdoc でのクラス及びメソッドの仕様記述を依頼し、その取り纏め及び HTML 出力 を行った。 （※文責: 金谷祥平） 5.2.3 浅井信 4月 関連サイト・技術調査とツールの準備 本プロジェクトで構築していくべきサイトの機能について参考となる類似サイトの調 査を行い、今回の規模やシステムの内容に合う機能は何かを考えた。開発していく顧客 の施設予約サイトに必要だと思われる機能の原案をまとめることで、システム提案書に 盛り込むべき機能を整理することができた。さらには、本システム開発にあたり相応し い技術についての調査も行った。それぞれの技術について調べ長所と短所をまとめて本 プロジェクトチームで使えそうな技術をリストアップしていった。他のメンバの調査結 果を含め全員で話し合って決定することができた。ツールについては、グループウェア や開発に必要なツールの準備を行ったが、予めインストールしており、問題なく使用で きる状態であった。 5月 機能一覧作成 顧客へ使っていただくシステムで必要な機能を確認するために本プロジェクトが提案 する特徴ある機能を含めたものを機能一覧としてまとめた。しかし、本プロジェクトが 提案する予約したい施設を検索する方法の詳細が定まらない状態だったので、提案時は Group Report of 2011 SISP - 53 - Group Number 10-A Practical Development of “Usable” System 2011 RFP 通りの機能を想定した。要件定義工程の終わりでこれが確定したので機能一覧は 成果物として顧客へ確認していただけるものとなった。 実際に作成した機能一覧の一 部は図 5.1 に示す。作成の際に注意したことは要件定義の時点で担当者をできるだけ明 確にしていったところでしたが、機能を実装していく中でさらに機能を詳細にしなけれ ばならない部分や要件定義で曖昧になっていた部分が出てきてしまった。 図 5.1 機能一覧の一部 6月 非機能要件作成 提案したシステムの品質や性質を保証するために非機能要件を定義していった。しか し、細かいシステムの応答やシステムの反応はサーバに依存するためサーバスペックの 詳細が必要だった。顧客へ問い合わせたところレンタルサーバのスペックは教えること ができないとのことで、品質を保証するために必要である項目が欠けている状況であ る。今後、本プロジェクトとして非機能要件はどこまで品質を保証するのかを決める必 要がある。 6 月-7 月 ユースケース記述作成 To-Be 業務フロー図を基にしてユースケース記述を作成した。これはあるユース ケースにおいてアクターとシステムがどのように応答し合うのかをイメージしやすくす るために作成した。これによって顧客へ確認していただくための成果物が出来上がった ので、このユースケースでいいかを合意をしていただくだけの段階である。 ロバストネス図作成 大まかなクラスを把握するためにユースケース記述を基にしてロバストネス図を作成 した。ロバストネス図は、設計としてまだ大まかなものである成果物となるので、今後 詳細設計としてシーケンス図やクラス図の作成するための前段階として確認に必要な成 果物である。 中間発表用スライドの作成 この時点までの全成果物や活動について章立てを作成し、プロジェクトメンバより意 見をもらうためにスライドのたたき台を作成して、レビューを何度も繰り返した。レ Group Report of 2011 SISP - 54 - Group Number 10-A Practical Development of “Usable” System 2011 ビューの度に修正をしていき本番前日には全員で発表の練習を行うこともできた。一般 向けに発表するには少々スライドでの説明が足りないと感じていたがリハーサルもした ので発表でカバーする形を取ってもらうことにした。 10 月 新体制案の提案とリスケジュール 後半の活動開始時に現在の状況のままでは予定通り納品できないため、新体制案の提 案と実現可能な予定を立てるためにリスケジュールを行った。新体制については、私が 後期活動のリーダーに任命されたため素案をプロジェクトメンバに提案し、それぞれの 担当やタスクを明確にして後期活動が開始された。また、実現可能なスケジュールを立 てるために実装にかかる時間を見積もり、根拠のあるスケジュール立てを行った。これ により当初予定していた納品日に納品することができる機能も把握できた。この変更に 伴い顧客に変更の承認をいただき後期活動を進めていくことができたのである。 WBS の作成 全体の作業量がどれだけあるかを理解するために、WBS の作成を行った。これまで の活動は感覚的な部分が多かったので、後半の活動ではどれだけやらなければならない ことがあるかなどを把握することに努めた。これにより、全体の進捗の管理を行うこと が可能になり、依存タスクの確認なども行えることができた。また、WBS をどんどん 更新することで扱いやすさを考慮していくことで会議での進捗管理の促進がなされた。 10 月-1 月 機能実装 機能実装の人数が足りなかったため、CakePHP 言語の勉強をしながら実装に取り組 んだ。先に技術を習得しているプロジェクトメンバがいたので、その人達が書いたコー ディングを参考にした。さらには、CakePHP の参考書も読みながら実践的にプログラ ミングをしていった。不明な点は設計者である担当者に問い合わせ、技術の指導をいた だきながら試行錯誤も繰り返し実装に取り組んだ。 進捗管理 前半の活動時は明確な進捗管理がなされていなかったので、後半の活動からは WBS を基に現在のタスクの進捗を確認することに努めた。これにより遅れているタスクが明 確になり、遅れの原因や対処を考えることができた。一番は全体性を確認することがで きたので作業の抜けがないかなどを確認できるのに役立った。特に後半の活動では定量 評価を取り入れるなどして進捗の管理を行っていった。また、色を付けるなどして遅れ ているタスクを全体で確認するなどの工夫もして全体感を常に把握するようにした。実 際に活動時に利用していた一部分であるスクリーンショットを図 5.2 に示す。 11 月 プロジェクト活動報告 顧客の上司の方へこれまでのプロジェクト活動を報告しに顧客のもとへ訪れた。報告 にあたり報告書を作成し、私達のこれからの活動の予定をまとめ提出し話合ったのであ る。後半の活動に入り当初の予定を守ることができなかったために謝罪とともに今後の 活動の予定を報告した。ここでプロジェクトメンバそれぞれが顧客のためにシステムを 作る努力をしていることも伝え、これ以上オーバーコミットしないように今後の確認を 取ることができた。他のメンバには体験できない貴重な体験ができたという点について Group Report of 2011 SISP - 55 - Group Number 10-A Practical Development of “Usable” System 2011 図 5.2 2011 年 11 月 14 日時点での進捗管理表 は自分のためになった。しかし、メンバの努力も理解している私に取っては非常に悔し さの残るものでもありました。 12 月 納品 納品についての事前準備や顧客への当日のアジェンダや事前連絡などに努めた。顧客 への連絡は 1 週間前には当日のアジェンダを送り、さらには前日に再度連絡を入れる ようにすることで当日の進行をスムーズにできるように促すことができた。さらには、 プロジェクトメンバの各担当者に予定通り納入物の準備をしていただくこともでき、ア ジェンダ通りに納品を終えることができたのである。納品物をチェックしていただける ようにドキュメントも作成し、当日に配布することで実際の納入物の確認をしていただ くこともでき、納品は滞りなく行うことができた。 （※文責: 浅井信） 5.2.4 藤原哲 4 月-5 月 関連サイト・技術調査とツールの準備 森町に導入するシステムをどういったものにするか検討する上で、類似サイトの機 能の調査を行った。また同時に、Web ページを作るにあたって使用可能な言語 (PHP, Ruby, Perl,Python) の特徴の調査を行った。5 月の初めには調査内容に関してメンバ 向けにプレゼンを行った。また、astah*のインストールとサイボウズ Live の使用法の 確認も行い、順調に完了した。 5月 開発コスト見積作成 提案依頼書段階では、顧客にシステム開発に関わるコストがどのくらいかを提示する ため、講義「ソフトウェア設計論 I」の講義で取得した、人月による予算の算出で、シ ステム開発に関わる見積り書を作成した。 Group Report of 2011 SISP - 56 - Group Number 10-A Practical Development of “Usable” System 2011 5 月-6 月 業務フロー図作成 要件定義段階では、講義「ソフトウェア設計論 I」の講義で学んだ業務フロー図の作 成を行い、森町役場の施設管理に関わる現状業務のフロー図作成と、システム導入後の フロー図の作成を行った。その際、UML 記述の技術の一部としてフロー図の書き方を 習得した。また、6 月 22 日には実際に森町公民館を訪れ、As-Is 業務フロー図の確定と 業務フロー図作成時の懸案事項の解決を行った。 6 月-7 月 プロトタイプ作成 設計工程段階では、プロトタイプ作成を行った。プロトタイプは To-Be 業務フロー 図、ユースケース記述、画面遷移図を基に、まずシステムの中心部分となる機能の HTML による画面プロトタイプの作成を行った。その際に、HTML 記述の技術の習得 に励んだ。さらに、7 月以降では、6 月に作成した画面プロトタイプに対して、CakePHP による処理を含ませる画面プロトタイプへの以降のために CakePHP の技術習得時間 を設けた。 FreeBSD サーバ構築 実際に森町役場で使用されているサーバと類似した環境を構築するために FreeBSD でのサーバ構築を行った。その際、講義「システム管理方法論」で習得したコマンドな どを利用した。 8 月-9 月 システム環境構築 (FreeBSD) 6 月 か ら 7 月 に か け て 設 置 し た FreeBSD サ ー バ で Apache, PHP, CakePHP, MySQL, phpMyAdmin の各種設定を行った。構築のために、まず森町がレンタル しているサーバの使用可能ソフトウェアの種類やそのバージョンを詳細に調査し、同じ バージョンのソフトウェアのインストールを行った。 10 月 システム環境構築 (CentOS 5.5) 8 月にあった森町との会議の中で検討事項となっていた公共施設予約システム専用 のサーバレンタルの件の結果から、新たに借りるレンタルサーバのディストリビュー ションに合わせてサーバの環境の変更を行った。サーバは FreeBSD をインストール したサーバに CentOS をインストールしなおし、FreeBSD と同様に Apache, PHP, CakePHP, MySQL, phpMyAdmin のインストールと各種設定を行った。また森町 が契約予定のサーバのソフトウェアと同じバージョンをインストールするためには、 CentOS の公式パッケージリポジトリに登録されているソフトウェアではバージョンが 合わないことや phpMyAdmin が登録されていないことが判明したため、リポジトリの 追加やその使用方法を調査しながら環境構築を行った。 システム開発環境構築とメンバ環境設定 新しい CentOS サーバでシステム開発を円滑に進めるために、Subversion による ソースコードのバージョン管理が出来る環境を構築した。サーバ側では Subversion の インストールと Apache の設定を行い、クライアント側 (プロジェクトメンバ PC) では Group Report of 2011 SISP - 57 - Group Number 10-A Practical Development of “Usable” System 2011 TortoiceSVN を使用した Windows のフォルダ上での管理方法の導入や、Eclipse プラ グインによる管理方法の導入を支援した。 11 月 システム環境構築 (CentOS 6.0) 11 月 11 日に行われた森町への報告の中でレンタルサーバ契約とシステム導入・運用 のための試験段階として森町役場内に自前のサーバを設置する方針があったので、構築 がしやすい当時最新ディストリビューションである CentOS6.0 でのサーバ構築の提案 と学内でシステムテスト用のサーバを新たに構築した。 学内の CentOS サーバは森町が構築しやすいように CentOS 公式リポジトリ内 でインストール出来るソフトウェアを主に使った。公式リポジトリでは賄えない phpMyAdmin に関してのみ、最小限での設定でリポジトリの追加を行った。 サーバ導入マニュアル作成 学内での CentOS6.0 サーバの導入と同時に、Linux をはじめて触る森町役場職員が 円滑にサーバの導入が出来るようにサーバの導入方法と使用ソフトウェアをまとめたマ ニュアルを作成した。 10 月-1 月 システム開発 サーバ構築完了後、詳細設計を基にシステムの構築を行った。システムは優先度順に 作成されたユースケースを基に構築していった。開発工程着手当初、それまでの各々の メンバの役割の引継ぎの関係からコントローラ部分の実装に着手した。自分の担当部分 として予約管理システムのエンドユーザ (町民) が使用する機能のコントローラ部分を シーケンス図とモデル内に定義されたメソッドを基にデータの処理と画面出力データの 成形を主に行ったが、モデルが完成しなければコントローラが完成しないこと、更には コントローラが完成しないことにはビューが完成しないことがわかり、開発メンバ間の コミュニケーションが必要以上に求められることがわかり開発体制の変更を検討した。 上記の失敗から行った検討の結果、途中からユースケース単位で開発を行った。ユー スケース単位で行った開発では森町役場職員や施設職員が利用するマスターデータに関 わる部分を実装した。そこではシステム全体を管理する管理者とシステム利用者のデー タを扱う施設担当職員が利用できる範囲 (権限) に特に気をつけてシステムの管理機能 を実装していった。また、担当した機能部分の全てにおいて、セキュリティの観点で脆 弱にならないようなデータの扱いに常に気をつけながら実装を行っていった。 12 月 納品 システムの納品の際に提出する DVD-ROM を作成した。必要なデータを取りまとめ る際に特に必要とされるテスト済みシステムのソースバージョンや各種提出書類データ のバージョンを間違えないように、各納品データ責任者と連携に多くの時間を割いた。 顧客サーバ構築補助 第 1 回・第 2 回納品時に顧客がサーバ導入マニュアルで理解、実行できなかった設定 の補助を行いながら森町のサーバ環境を整えた。構築の際に、実際の環境で使用するた めの必要な設定ではあるが学内では設定することが出来ない部分の列挙やその説明、そ れだけでは補足不可能な部分のメール対応など細かい部分の設定まで手伝うことが出来 るようにした。 Group Report of 2011 SISP - 58 - Group Number 10-A Practical Development of “Usable” System 2011 （※文責: 藤原哲） 5.2.5 若山将太 4月 関連サイト・技術調査とツールの準備 本プロジェクトで開発するシステムに類似する予約システムの調査を行った。ここで はウェブを中心に調査行い、その予約システムの特徴や機能を纏め、プロジェクトメン バ全員で共有した。そして FreeBSD やシステム開発言語として PHP, Ruby, Python, Perl に関しても調査を行った。 またツールの準備として astah*のインストールとサイボウズ Live への登録を行った。 5月 プロジェクト計画書の素案 プロジェクト計画書を作成するのは始めてであったため、まずこれを作成する意義を 調査し明確にした。そこで記載すべき項目とその項目について調べ、どういった内容を 記述すべきか検討し、プロジェクトの目的、目標について明確化した。 ステークホルダリスト作成 本プロジェクトの利害関係者を表すステークホルダリストについて、プロジェクト計 画書と同様に調査し、ステークホルダの主な責務や影響について調査・検討し作成した。 5 月-6 月 業務フロー図作成 業務フロー図は現状の業務の流れを表す As-Is 業務フロー図とシステム導入後の業務 の流れを表す To-Be 業務フロー図を作成した。 As-Is 業務フロー図では、現在、顧客が行なっている予約管理業務を把握しそれに基 づいて作成した。具体的には RFP を確認しながら作成し、情報の足りない部分は顧客 へヒアリングを行った。ヒアリングの手段としてメールのやり取りや現地訪問行った。 To-be 業務フロー図では、まず機能一覧や RFP、そして As-Is 業務フロー図を確認 しならが作成した。この業務フロー図がシステムの流れの基を表すことになるので作成 には十分に配慮した。また、他のメンバの作成した業務フロー図を確認し、全ての業務 フロー図で整合性が取れるように何度も確認・修正を行った。 ユースケース図作成 To-Be 業務フロー図を基にシステムに対する要件を特定するためにユースケース図 を作成した。これは顧客にシステムの概要を把握してもらうための重要な資料となるた め、見やすく簡潔に書くために書籍やウェブ、アドバイザからのレビューを参考にし完 成させた。これも他の成果物との整合性に配慮しつつ、矛盾のないよう心掛けた。 6 月-7 月 E-R 図・CRUD 図作成・データ項目正規化 データ項目については、データベース管理システムに必要とされる 4 つの機能を表し た CRUD 図や、データを実態、関連、属性の 3 つの構成要素でモデル化し図で表した E-R 図を作成した。この 2 つの成果物を作成する上で、To-Be 業務フロー図や機能一 覧を確認し、他の成果物との整合性を意識した。データ項目の正規化では、本システム で使用するデータ項目を整理し、データ項目の不備が無いか、またデータ項目同士の繋 Group Report of 2011 SISP - 59 - Group Number 10-A Practical Development of “Usable” System 2011 がりを明確にするために作成した。 7月 要件定義書作成 要件定義工程で作成された下記に示す 7 つの事柄・成果物を纏めて文書の体裁を整 え、要件定義書を作成した。 • システム導入の目的と目標 • システムの概要/システムの構想 • 業務フロー図 • 機能要求 • 帳票プロトタイプ • 非機能要件 • 画面遷移図 これを顧客と共有し、本システムの仕様について、合意を頂いた。 8 月-9 月 PHP 技術習得 システムを開発する際に使用する言語は PHP と決定したので、後期以降の活動のた めに PHP についてウェブや書籍を用いて技術習得を行った。 HTML・CSS 技術習得 システムを開発する際に PHP 以外にもウェブページを構築する上で HTML 技術が 必要となってくるので HTML や CSS に関しても PHP 技術習得と同様の方法で技術習 得を行った。 10 月 携帯端末用ページ作成のための技術調査 本システムはパソコンからだけではなく携帯端末からも利用されることが想定されて いるので、携帯端末用ページ作成のための技術調査を行った。 主にパソコン用サイトで使用しているフレームワークである CakePHP のライブラ リとして KtaiLibrary が使用可能かどうか、また実際にプロトタイプを作成し携帯端末 の実機、またはシミュレータで意図したとおりに稼働するかどうか確認を行った。 10 月-12 月 携帯端末用ページの実装 携帯端末用ページは本システムを利用する一般ユーザのページのみを実装した。本シ ステムは MVC モデルを採用しており、モデルはパソコン用ページと同じソースコー ドを利用できたがコントローラとビューは一部の携帯端末で cookie が使用出来なかっ たりパソコン用ページの HTML と同じ記述が使用出来なかったりという問題点が多々 あったためパソコン用ページ実装で作成されたソースコードを基に携帯端末用ページ用 に書き換える必要があった。特にビューではほとんどの記述が携帯端末から閲覧すると 崩れてしまっているので大部分を書き換える必要があった。また、携帯端末からのア クセスかどうかを判別するために携帯端末用ページ作成のための技術調査で利用した KtaiLibrary を利用した。 結果として図 5.3 と図 5.4 に示すようにシミュレータ、実機共に動作が確認できる状 態となった。 Group Report of 2011 SISP - 60 - Group Number 10-A Practical Development of “Usable” System 2011 図 5.3 携帯端末用システムトップページ (シミュレータ) 図 5.4 Group Report of 2011 SISP 携帯端末用システムトップページ (実機) - 61 - Group Number 10-A Practical Development of “Usable” System 2011 12 月 画面仕様書作成 顧客に納品する際に携帯端末用ページの画面仕様書を作成する必要があったので、パ ソコン用に作られた画面仕様書を基に携帯端末用ページとの差異を記述した。 12 月 試験成績表作成 携帯端末用ページ実装の際にテスト計画を基に作られた試験成績表に沿って試験を 行った。試験を行い、意図した通りに動作しなかった部分を障害管理表に纏めてプロ ジェクトメンバ全体で共有し、対策方法を検討し、バグ修正を行った。この作業を繰り 返しシステムの品質を向上させた。 障害管理表作成 携帯端末用の試験を行った際に発生した障害・バグを纏め、その状況を記載した文 書である障害管理表を試験成績表と平行して作成した。 12 月 納品 画面仕様書と試験成績表を PDF 形式に落としてパッケージングの準備を整えた。 （※文責: 若山将太） 5.2.6 武田麻依 4月 他地域の施設予約システム、使用候補のプログラミング言語の調査 本格的な取り組みの前段階として、他地域の施設予約システムと、おそらく使用すると 予想されている幾つかのプログラミング言語の調査を行った。これは各自で調査を行 い、プロジェクトの時間を用いて、適当に決定したグループで発表を行った。調査につ いては、インターネットを用いて行った。他地域の施設予約システムは、「公共施設」・ 「予約」の単語で検索をかけて、表示された予約システムを対象に調べた。プログラミ ング言語はウィキペディアに加えて、個人が発表しているページなども調べた。特に、 個人名などが表記されていて、文章の責任者が分かりやすいサイトを中心に調べた。そ して他のメンバ二人とそれぞれの調査結果を照らし合わせて、発表の準備を行った。 5-6 月 As-Is 業務フロー図・To-Be 業務フロー図の作成 As-Is、To-Be 共に、業務フロー班でタスクを分担して取り組んだ。今まで使ったこと のない Astah というツールで作成することになったので、本格的な作成に入る前に、何 度かそのツールを試用してみた。しかし、全く基準などを決めずに取り組み始めてし まったため、粒度や表記方法にばらつきが出てしまった。その点については、To-Be に 取り組み始めた辺りで基準を制定して共有し、各自それに沿った成果物を作成するよう にした。As-Is は森町の情報があまりない状態で始まったので、自分で公共施設の予約 業務はどのようなものであるかを想像して作成した。To-Be の方はメンバでシステムを 考えながら作成した。また、As-Is 業務フロー図の時点ではややタスクの負担に偏りが あり、特定の一個人の負荷が多くなってしまっていた。このことを受け、To-Be 業務フ ロー図ではタスクの負担の大きさを考え、タスクを割り振った。 Group Report of 2011 SISP - 62 - Group Number 10-A Practical Development of “Usable” System 2011 6-7 月 プロトタイプの作成 設計工程にて、プロトタイプ班としてプロトタイプの作成を行った。まずは学内のサー バに FreeBSD に入れることから始めた。導入する OS についてはメンバで話し合って 決めていたので、導入の前にインターネットで FreeBSD について調べた。FreeBSD の 公式サイトや、FreeBSD の導入方法などが書かれた個人のブログなどを主に調べた。 その際、前期に受けたシステム管理方法論の授業で学んだことが非常に役に立った。し かし、まだサーバについての知識がとても浅かったので、なるべく分からないところは メンバに尋ねるように心がけた。また、画面のプロトタイプとしての HTML ページの 作成も始まったので、今まで学んだ HTML の知識を復習した。CSS の勉強も、幾つか のサイトを回って少しずつ始めた。 7月 画面設計の基盤の作成 設計工程の段階で、各班から一人ずつ選び、その三人で特別に画面設計班を結成した。 これは、画面設計班での決議事項を、各班に運ぶことを狙ってのものだった。活動とし ては、三人で画面設計の基礎となる、各画面での共通フッダ・ヘッダについて考案した。 項目などについては、RFP を確認し、また、他の施設予約システムも多少参考にした。 だが、メニューのおき方や全体のイメージなど、重要な箇所については三人で議論して 決めた。デザインの議論でもあったので、口頭ではやりにくいと判断し、議論は三人が 集まっていた時に、割り当てられていた教室のホワイトボードを用い、実際に書き出し ながら行った。デザインの大元の基盤にはプロトタイプ班が作っていた画面を用いた。 その基盤に、三人で修正を加えていった。また、ある程度のデザインが固まった後、実 際に画面を作成してみる必要があったので、まず、HTML だけで作成を行った。その 後、より効率よく画面を作成するために、CSS の勉強をして、フッダ・ヘッダが全ペー ジに表示されるような CSS を作成した。 9-10 月 エラーメッセージの作成 実装工程から試験工程にかけての段階で、システムのエラー時に表示するエラーメッ セージを考案し、リストを作ると共に、そのエラーメッセージをシステムで使えるよう にした。ただし、作成時点では正確にどのエラーメッセージが必要で、どのエラーメッ セージが不要なのかが分からなかったため、考えうるエラーメッセージを全てリスト アップし、実装に伴って削っていく方針を取った。その際は、現在できているシステム を実際に動かし、エラーメッセージを書き出した。また、実装班の方が、システムを作 成しながら、エラーメッセージを修正・追加した場合は後からリストに反映させた。ま た、後のテスト計画を考案している際にも新たなエラーケースが発見されたため、それ も後に付け加えた。リストアップしたエラーメッセージはエラーケースとして試験成績 表にも反映し、システムに不要と判断されたエラーケースは、試験成績表から削除して いった。 9-10 月 テスト計画の考案 テスト工程に向け、テスト計画の考案を行った。大まかな内容としてテスト内容、テス ト手順、テスト環境、障害発生時の対応についてテスト計画書にまとめた。テスト計画 Group Report of 2011 SISP - 63 - Group Number 10-A Practical Development of “Usable” System 2011 書の作成は未経験だったため、インターネットや本校の情報ライブラリの書籍などから 情報収集を行い、たびたびメンバや教員、アドバイザの方々に助言を求め、その度に修 正を行った。そして改訂版をメンバ、教員、アドバイザの方々に公開し、アドバイス、 修正点があれば指摘をもらえるように請い、何か指摘をもらえたならば修正、の作業を 繰り返した。テスト内容、テスト手順を考案する際に、品質向上テストも視野に入れて いたが、最優先で行うべきはシステムとして稼動するかどうかを見る結合テストと考 え、品質向上テストは、結合テストが終了した後に実施することにした。結合テストの 内容を考えるにあたって、エラーケースはエラーメッセージを基に作成した。他、誤動 作のテストケースは実際にシステムを操作しながら考案した。 テスト計画を立てる際、よりテストを円滑に行うため、ツールの使用を考えた。テスト データの入力、テストの進行を素早く行うために、Selenium というテスト自動化ツー ルと、品質向上テストを行うために、Jmater という同時に多数のリクエストの送信な どを行えるツールについて、主にインターネットを用いて調べた。しかし、Selenium は Firefox のブラウザにはアドオンを追加するだけで簡単に動くものの、実際にテスト を行う InternetExplore には対応するアドオンが存在していなかった。他のテストを予 定していたブラウザにも対応しておらず、また、それらのブラウザで Selenium を使う 方法を調べてはみたが、良い方法は見つからなかった。結局、テスト開始日時が迫って いたため、使用法を調べる時間の方が惜しいとして、そのツールの使用は断念すること になった。Jmeter の方は、多数のリクエストに対する処理能力を見るには必要だった ので、もう少し調査を進めた。ティーチャーアシスタントやアドバイザにも、積極的に 使い方などを尋ねた。しかしシステムが完全に完成していなかったこともあり、実際に 開発を行っているサーバーで起動実験をするのも躊躇われたため、実際に使ってみるこ とができなかった。ちゃんと使用方法を把握する前に開始日時が訪れてしまったため、 結局ツールの使用は双方とも断念した。 テスト時にシステムに入力するテストデータについては、顧客に実際に現場で用いられ ているデータを添付してもらうのが遅れていたため、おそらく用いられるだろうデー タ、テストに必要なデータをこちらで考案し、それをテストに用いることにした。その 際は、テストケースに準じ、時間だけ違う予約、部屋だけ違う予約、備品のある無しな どを調節して、様々な場合に対応したテストができるようなテストケースを作成した。 そしてテストケースの条件に関わる項目以外の項目は、時間の短縮のために、内容をさ して考えずに作成した。 11-12 月 テスト実施 実装工程と平行しながら、実装の完成した優先度の高い機能から、順々にテストを行っ ていった。予め用意した試験成績表を基にし、試験結果を試験成績表に書き込んだ後、 そのファイルを別名で保存した。テスト最中、もしくはテスト後に発覚したテストケー スは、発覚するたびに試験成績表に追記を行った。障害が発生した場合は、事前にテス ト計画書にまとめていた方法で対応し、また、障害の対応を行う際、実装者から障害の 内容が掴みにくいという要請があったので、より効率よく障害を修正するために、障害 対策を改めた。具体的な手段としてはどのような手順が書かれているのがより分かりや すいかを各実装者に尋ね、適宜手順を修正、テスト計画書にも反映した。障害管理表だ けに障害の詳細を書くのが難しかった場合は、テキストファイルに細かい詳細内容を記 Group Report of 2011 SISP - 64 - Group Number 10-A Practical Development of “Usable” System 2011 述し、メンバに公開した。またエラーを起こしている画面がどのようになっていたか、 どのようなエラーが表示されているか分かった方が良いという申請を受け、テストを行 うブラウザである InternetExplore にメンバの一人にすすめられた SnapCrab のアド オンを追加し、エラーが起きている画面をキャプチャし、障害番号に対応したファイル 名をつけ、障害の詳細を書いたテキストファイルと同じようにメンバに公開した。キャ プチャを行う際、CakePHP によるエラーが表示されていた場合はそれを表示してか らキャプチャを行うようにした。また、エラー箇所が分かりにくいと判断した場合は、 キャプチャした画像に描画ソフトで印やコメントを入れるなどしてから、メンバに公開 した。 顧客に試験成績表を納品する際は、試験成績表、テストデータに加え、顧客からの要望 に応え、不可になったテストの詳細を記した不可テスト詳細を添付した。また、試験成 績表の項目もより詳しく記述するようにした。 4 月-1 月 議事録 全工程を通して、各 PBL の活動時間の中で行ったことを交代交代で議事録に記録した。 議事録の担当となる者は活動時間の最初に決定し、自分が担当になった時はメンバの発 言を逐一記録するようにした。しかしそれだけでは記録にも、取りまとめにも時間がか かるため、メンバのアドバイスを受けて、記録を最小限にするように心がけた。またメ ンバからは、読みやすい議事録の構成の仕方、文章の表現の仕方などのアドバイスも受 けたので、それらも議事録に反映させるようにした。顧客とシステムの確認を行った際 は、活動時間の最後にそれまでの決定事項と懸案事項を確認するようになったので、記 録をとりながら簡単な取りまとめも行うようにした。その際、記録と取りまとめを同時 に行うと混乱してしまったため、結論が出るのに時間がかかりそうな議論、余談などの 最中に取りまとめを行うようにした。 （※文責: 武田麻依） 5.2.7 長坂明輝 4月 関連サイト・技術の調査と報告 顧客の RFP に基づいて、開発を行うシステムと類似するサイトやサービスを調査し た。またそれらのサイトやサービスにおいてどのような技術が利用されているか、関連 すると思う技術やサービスも調べ、プレゼンテーションとして報告した。 5月 システム提案書の作成 システム提案書の作成において、システム化の背景の章を担当した。顧客の提案依頼 書を熟読し理解しなければ書けない部分であったため、より提案依頼書の理解を深める ことができた。 今後は Google ドキュメントや Dropbox など外部のファイル共有サービスを利用し、 効率よく共同編集するようになった。 5 月-6 月 帳票プロトタイプ (CSV 版、HTML 版) Group Report of 2011 SISP - 65 - Group Number 10-A Practical Development of “Usable” System 2011 帳票プロトタイプとは、実際のシステムの利用実績など（帳票）をシステムが CSV や HTML として出力する成果物の試作品のことである。実際に試作品を製品に先行し て制作することにより、早期に正確に顧客の要求を把握し要件定義と現状業務との差を 埋めることが期待できるからである。 他の類似サイト等や顧客が実際に利用している帳票、および RFP を基に CSV と HTML を制作した。 CSV 版の帳票プロトタイプの作成ではカラム名を考える必要があったため、池田が 担当したデータ項目一覧とこの帳票を参考にして整合性を図った。データ項目一覧は、 この顧客が実際に利用している帳票を基にデータ項目を抽出してあるからだ。 HTML 版の帳票プロトタイプの作成では、CSV 版の帳票プロトタイプに加えて他 の現存サイトを参考にして制作した。その際、月や年ごとの利用者数の統計や、性別や 施設名などでの絞込みしてからのレポート出力機能など、管理者の立場から見たら役に 立つのではないかと思う機能も考え帳票プロトタイプに盛り込んだ。 さらに帳票としての意味だけではなくデザイン面まで考慮して作成し、HTML と CSS を 1 からコーディングができた。また、HTML 版の帳票プロトタイプは今後制 作する（システム全体としての画面）プロトタイプの参考となった。実際に制作した HTML 版の帳票プロトタイプを図 5.5 に示す。 CSV 版及び HTML 版の帳票プロトタイプは、4.3.7.3 節で説明したデザインレ ビューで顧客にレビューして頂いた。なお、帳票プロトタイプはシステムでレポート 出力機能として実装する予定だったが、データベースをブラウザ上から管理できる phpMyAdmin を利用して予約情報をダウンロードし、顧客側で情報を加工して利用し て頂く形となった。実装の進捗に遅れが発生し、全ての機能を実装することができなく なってしまったからである。 6 月-7 月 プロトタイプの作成 プロトタイプの作成では HTML と CSS のコーディングを担当した。活動当初で調 べた既存する類似サービスのサイトなどを参考に、トップページや施設の検索画面、予 約の申し込み画面など施設予約の一連の流れの画面プロトタイプを制作した。 この時点ではデザイン面より内容に注視して顧客にレビューして頂く必要があるた め、アドバイザから頂いた助言を基に、画面上のデザインは必要最低限に抑えて制作し た。画面プロトタイプのうち、トップページのスクリーンショットを図 5.6 に示す。画 像や色などデザインに必要な要素がほぼ排除されており、システムの概要を顧客に説明 するにあたって必要最低限の情報のみが掲載されていることがスクリーンショットから 読み取ることができる。 また、同時期に太田が作成した画面遷移図を基に画面を制作することで画面同士のリ ンクや画面のタイトル等の整合性をとった。画面の表示される項目についても池田が 作った E-R 図内のデータ項目を基に作成し整合性をとった。 ここで制作した画面プロトタイプは、夏季休業に制作したトップページの画面プロト タイプ及び後期で開発するシステムのビューとして流用されていった。また、この画面 プロトタイプは 4.3.7.3 節で説明したデザインレビューでシステムの利用の流れの確認 として顧客にレビューして頂いた。 8 月-9 月 Group Report of 2011 SISP - 66 - Group Number 10-A Practical Development of “Usable” System 2011 HTML、CSS、JavaScript の技術習得 前期では帳票プロトタイプや画面プロトタイプを制作したため、夏季休暇中の各メン バのタスクとして割り振られたタスクから、HTML、CSS、JavaScript の技術習得を 選択した。実際に習得した技術をより正確に学び、今後取り組む工程である実装につい てコーディングを通してより貢献していきたいと考えたからである。 HTML についてはもう一度基本的な構文の書き方から学び、システムに必要となる タグ等も含めタグの使い方を学習した。また CSS の構文や利用方法を学習し、よく使 われるプロパティなどの意味を理解し、実際に前期で制作したシステムのトップページ デザイン案を基にオリジナルのデザインによるトップページのプロトタイプを制作し た。 なお、この時制作したプロトタイプについては、CSS の学習も兼ねてデザイン面も考 慮して、CSS 及び背景に使われる画像なども制作した。また JavaScript も同様に基本 的な構文を学習し、ブラウザや OS 毎の挙動など仕様もチェックし、前期で挙げられて いたアイディアであるシステムに実装したい「未来大独特」の機能のうち、文字サイズ 変更機能と Google マップの API の利用方法なども調査し実際にプロトタイプに実装 した。 そして作られたそのプロトタイプは今後、システムの基本的なビュー（デザイン）と して採用されることとなり CSS や画像、JavaScript で実装した文字サイズ変更機能も そのまま流用されることとなった。 10 月-12 月 システムのビュー制作 はじめにシステムのビューを制作するに当たり、夏季休業中に自習した HTML、 CSS、JavaScript に加えてシステム開発に使う言語である PHP 並びに PHP フレーム ワークである CakePHP の利用方法を学ぶ必要があった。 そのため初めに PHP の基本と共に CakePHP を利用したアプリケーション開発の手 法を、書籍を通して学ぶこととなった。それを経た上で、夏季休業中に制作したトップ ページの画面プロトタイプを CakePHP のビューとして移植した。 さらに利用者情報入力画面などの施設予約に関するビュー全てについてもコーディン グを担当し制作することとなった。その際、HTML や CSS だけではなく、CakePHP の機能（例えば HTML タグを自動生成する HTML ヘルパーや、セッションで保存さ れた変数を呼び出す機能等）を引き出す必要があった。 初めて CakePHP の機能を利用することとなったため、機能の利用方法に慣れず初め て作ったビューについては 2 週間以上かかってしまった。その後は UI 設計のイメージ と現存のビューとの誤差を微調整した。 また、武田が主導で進めたテスト計画及びテストにおいてビューに対するエラー（表 示がブラウザによって崩れてしまう、文字サイズを変更すると表示されない部分がある 等）が毎回発生したため、その修正にも追われた。加えて、RFP に対応ブラウザとし て記載されていた IE、Firefox、Chrome、Opera、Safari に対応する必要があり、各ブ ラウザで表示が微妙に異なったりレイアウトが崩れてしまうことがあったため、ブラウ ザや OS 毎での表示の違いを比較し修正する作業が続いた。 同じ OS、同じフォントであっても各ブラウザのデフォルトのフォントサイズが異 なったことなど、様々な利用者の状況を想定しての作業は HTML や CSS のコーディ Group Report of 2011 SISP - 67 - Group Number 10-A Practical Development of “Usable” System 2011 ング作業より大きく時間を取られることとなった。 前期で制作した画面プロトタイプに UI 設計を適用し、実際にシステムで使わられて いる画面を図 5.7 に示す。必要最低限の情報のみを載せた画面プロトタイプと比較する と、画像や色などデザインに関する情報が多く載っていることがわかる。 全体的に使用されている色の色彩が統一されており、画像を非表示にしている環境で も問題なく視認できるようにしたり、メニューバーに使われる文字を画像ではなくテキ ストとして表示させることによって文字サイズ変更機能に対応させるなど、アクセシビ リティにも考慮してコーディングを行った。 画像のデザインや UI 設計以外は、全体のシステムのビューの半分程度を担当し HTML と CSS をコーディングした。特に、CSS 約 700 行は自分のみで行った。作成 したこの利用者側画面のビューを基に、携帯版のビューを若山が制作し、管理者側画面 のビューを金谷や藤原、長坂が制作した。 図 5.5 Group Report of 2011 SISP HTML で制作した帳票プロトタイプ - 68 - Group Number 10-A Practical Development of “Usable” System 2011 図 5.6 図 5.7 UI 設計適用前の画面プロトタイプ UI 設計適用後のシステム画面 （※文責: 長坂明輝） 5.2.8 江戸太樹 4月 類似サイトの調査 予約システムの一般を知らなければ魅力的な予約システムを構築することは不可能で あろう。そこで、Web 上に公開されている自治体の類似サイト、別事業の予約サイト などを閲覧することで、基本的な構成を学び、特徴的なコンテンツを抽出した。これを 参考に RFP に記載されている以外の提案機能として、Google Maps による施設の位置 特定機能、ユーザ管理機能、お問い合わせフォーム、新着情報登録機能を考案した。ま た、システム利用方法を図示することによる視覚的なわかりやすさ、高齢者への配慮と Group Report of 2011 SISP - 69 - Group Number 10-A Practical Development of “Usable” System 2011 しての文字サイズの変更機能など、提案内容とは別に Web サイトを構築する上で参考 になる点が多く見つかった。 5月 提案書の作成 顧客からの RFP への回答としてシステム提案書を作成した。提案書作成で私は全体 の構成検討および取りまとめを担当した。メンバには競合サイト調査、システム構成 検討、導入コストの見積り等、それぞれに作業担当を割り振った。私自身は担当者の作 成した資料を受け取り、提案書内での整合性、妥当性をチェックした。しかし、メンバ 各々には作業の全体像が見えず、作業負担が一部の人間に集中するという問題が発生 した。 全体スケジュールの立案 プロジェクト開始時点で開発作業全体のスケジュールをガントチャートにより立案し た。しかし、これだけでは各工程内での詳細な作業内容が把握できないため、それらを 詳細な WBS として記述することで明確化を図った。但し、この段階ではスケジュール に根拠がなく実現可能性に欠けていただけでなく、WBS に全ての作業が定義しきれて いなかった。したがって、検討の上これをさらに詳細化していくことが必要であった。 5-6 月 業務フローの記述 システム導入後の業務フローを明確にし、業務という観点からシステムの機能要件を 過不足なく定義するために業務フロー図を作成した。まずは顧客へと現状業務の確認を とる必要がある。そこでは、予め現状業務の流れを想定で記述することにより、少ない コンタクト回数で細かい点まで深堀してヒアリングを行うことができた。また、現状業 務の流れとシステム導入後の業務の流れを比較して説明することにより、顧客との確認 の際に新たに発生する業務や改善する業務が明らかにした。但し作業の面では、分担し た業務フローの間で記述方法や解釈に齟齬が発生し、それを摺り合わせて解消するため に多くの時間をかけてしまった。 森町訪問に向けての資料作成 実際の業務を細部まで調査することを目的に顧客の元へと訪問した。事前準備とし て、当日確認すべきことを重要度を踏まえたうえでリスト化して整理しておいた。その 他に、メンバを現場を見学して業務の細部を調査する班と顧客側の責任者に向けてヒア リングを行う班とに役割分担を行った。 6 月-7 月 ユースケース記述作成 導入後の業務フローを元として、実際に機能を利用する際の利用者とシステムとのや り取りを詳細に検討し、ユースケース記述としてまとめた。ユースケース記述作成にお いても担当者それぞれで作業を分担して取り組んだが、はじめに担当者の間で 1 つの ユースケース記述を共同作成して記述方法を確認した結果、業務フロー図作成時のよう な記述規則および方針の食い違いは少なかった。ここでのサンプル作成は共同作業にお ける方針の確認という点で非常に役立ったが、プロジェクトにおける計画立案では何を 行うかによらず規模感を掴み所要時間を算出することが重要である。サンプルの作成は 非常にいい取組み方であると学んだ。 ロバストネス図作成 Group Report of 2011 SISP - 70 - Group Number 10-A Practical Development of “Usable” System 2011 ユースケース記述を入力として、それに含まれる画面、帳票、処理系、データなどの エンティティを抽出した。ユースケース記述作成時と同様に一つの図表を作成し、メン バ間での表記ぶれを防いだ。また、ユースケース記述に抜けや漏れがあった場合に後に 支障がでる場合が考えられたので、それに明文化されていないエンティティにも注意し て作成を進めた。 7月 中間発表ポスター制作 PBL の前期活動を締めくくる学内中間発表会に向けて、発表用ポスターを制作した。 ポスター制作ではわかりやすく聴衆の目を引く構成を目指し、図要素を大きく配置し た。それによりポスター全体的にはわかりやすくはなったが、システム概要や各工程で の活動内容の詳細までを盛り込むことができなかった。プロジェクトの活動内や魅力を 知るには少々物足りないという指摘を、プロジェクトの背景を知らない人から多くいた だけたため、最終発表のポスター制作では複数枚を用いた紙面に余裕のある構成にし、 より活動の詳細まで記載できるようにしたい。 9月 新体制発足に向けての準備 後期 PBL は新体制で以て進行することとなった。具体的にはプロジェクトリーダの 交代である。その理由としては 2 点あり、1 点目は前期活動において私のプロジェクト マネジメントの甘さにより成果に遅れが出たため、2 点目はプロジェクトマネジメント の体験機会を他のメンバにも共有するためである。これに伴い、新リーダへこれまでの 作業内容を伝えて引き継ぎ作業、プロジェクトの再計画を行った。プロジェクト再計画 では、実現可能なスケジュールを立案するために一つの機能を構築するのに要する時間 を初めに計測し、それにより全機能を実現するためにはどれだけの期間が必要であるか を見積もった。この段階で本格的なプロトタイプ作成に着手したともいえる。再見積も りの結果として、PBL の活動期間中に顧客へ提案した全ての機能を構築することは不 可能であることが裏付けられた。 そこで、本プロジェクトでは実装する機能に次のように優先順位をつけた。第一に本 システムが予約システムとして成立するために必要不可欠である機能（予約機能、予約 閲覧機能など）、第二に本来は重要であるが既成のソフトウェアやコマンドラインにて 代用できるもの（データベースメンテナンスツールなど） 、第三に RFP にはないが本プ ロジェクトが利便性向上のために提案したもの（ユーザ管理機能、新着情報）である。 以上のような事情を踏まえて顧客との交渉の末、優先順位の高いものについては当初の 納品日までに、その他については以降段階的に納品するという形で承認を受けた。 10 月-11 月 ユーザインタフェース設計 ユーザインタフェース設計では大きく分けて以下 3 つの作業をトップダウンに行っ た。1 つ目に本システムで実現する機能における画面遷移の再検討、2 つ目に各画面に おける画面レイアウトの検討、3 つ目に各画面項目におけるデータベースや他画面との 関連の定義である。 • 画面遷移の再検討 要件定義で行った画面遷移の検討を再び行った。その理由としては、要件定義の 段階で取り組んだ同作業では画面間の結び付きのみが定義されており、エラー発生 Group Report of 2011 SISP - 71 - Group Number 10-A Practical Development of “Usable” System 2011 時やその他制御が行われる場合の画面遷移の定義が不十分であったためである。ま た、プロジェクト再計画を踏まえた要件の変更にも対応できていなかった。画面遷 移の再検討の際には、この点に十分注意して取り組んだ。また、要件定義の完了レ ビューにて顧客からいただいた要望から生じた変更点を洗い出し、新たに必要・不 要となった画面を遷移に反映させた。 • 画面レイアウトの検討 画面遷移に沿って、各画面にどのように画面項目を配置するのかを検討し、画像 編集ソフトを用いて画面イメージを作成した。また、この作業を行った段階では既 に機能実装を開始していたため、スタイルシートを用いた画面レイアウトの整理に 利用する Web 素材の作成も並行して行った。 具体的な画面レイアウトを検討していると、これまで検討していなかった要件定 義の漏れが浮き彫りになってくることが多々あった。余裕期間が少なかったため、 要件の漏れについては内部設計および実装の担当者と打ち合わせ、対応に要する時 間や重要度を見積った上で顧客への確認をとるように心がけた。 • 画面項目の定義 まず作成した画面イメージ中の画面項目それぞれに対して一画面中で一意とな る番号を採番した。ここで画面項目としているのは、ラベル、サブミットボタン、 チェックボックス、コンボボックス等の画面上における論理項目である。そして、 これらがデータベース中のいずれのテーブルのいずれの属性から取得されるもので あるか、また初期値や制御について定義した。 12 月 最終発表ポスター制作 一年間の PBL を締めくくる学内成果発表会に向けて、発表用ポスターを制作した。 前期のポスター制作での反省を活かし、この際は 2 枚目をサブポスターとして作成し た。後にポスターセッション形式の対外発表を行う可能性を考慮し、サブポスターはメ インポスターにて大まかに示された内容を詳細に説明できる形にし、2 枚のポスターを 用いてプロジェクトの活動を一環して説明できるようにした。具体的には、システム提 案から要件定義、設計、実装、試験までの一連の流れ、およびに大きな転機となる部分 を記載し、それぞれで得られた学びや創意工夫を記述する形をとった。最終的に作成さ れた 2 枚のポスターを図 5.8 及び図 5.9 に示す。 Group Report of 2011 SISP - 72 - Group Number 10-A Practical Development of “Usable” System 2011 図 5.8 図 5.9 メインポスター サブポスター 納品 納品の準備として画面仕様書の取りまとめを行った。既に画面項目 ID が付与されて いる全ての画面イメージを一覧としてまとめ、それに対して対応する画面項目の情報を 整理し直して画面仕様書としてまとめた。納品前に改めてソースプログラムと画面仕様 書との間の整合性をチェックし、システム構築作業の途中で生じた仕様変更に対応しき れていない点などを洗い出した。 （※文責: 江戸太樹） 5.2.9 池田政人 4月 関連サイト・技術調査とツールの準備 関連サイトの調査として今回開発するシステムに類似するシステムの調査を行った。 調査結果として、浦安市や福岡市の公共施設予約システムが類似システムとして挙げ、 システムの規模、デザインやインターフェースについて参考となった。 技術調査としてシステム開発に用いる言語について、PHP，Perl，Python，Ruby に ついて自らの経験とインターネット上の情報を元に比較検討を行った。顧客と同環境を 用意し開発を行うためにオペレーティングシステムである FreeBSD のインストール方 法、PHP や MySQL 等のアプリケーションの導入方法について調査を行った。 ツールの準備として、アドバイザやプロジェクト内のコミュニケーションはグループ ウェアを用いた。グループウェアはサイボウズ Live であり、同グループウェアのアカウ ントのセットアップを行った後、サイボウズ Live の web ページから入手可能である「で きるサイボウズ Live」 （http://magazine.cybozulive.com/2011/03/dekiru.html）を読 んだ後、実際に操作をすることで使用方法を会得した。クラス図等を作成する際に利用 するソフトウェアである astah*の導入を行った。導入に際しては利用経験があるため スムーズに行うことが出来た。 5月 Group Report of 2011 SISP - 73 - Group Number 10-A Practical Development of “Usable” System 2011 提案 顧客から受領した RFP を基に提案を行った。プロジェクト内のディスカッションで 出された RFP に記載されていない機能を提案した。提案書を作成する工程ではソフト ウェア構成図の制作を行った。リーダーを中心としたメンバからのアドバイスを参考に RFP や顧客への問い合わせで判明した各ソフトウェアの構成を図としてまとめた。 5 月-7 月 データ項目の抽出 システム利用され、データベースで扱うべきデータ項目を抽出するために現在業務で 使用されている帳票と RFP を用いた。結果としてシステムに必要なデータ数は 157 項 目に及んだ。 6 月-7 月 森町訪問 システム導入後にシステムが利用される現場の一つである森町公民館を訪問した。主 な仕事は記録係として写真を撮影した。公民館内の部屋の見学、実際の施設利用手続き を体験した。 データ項目の正規化 抽出したデータ項目についてアドバイザのアドバイスやガイダンス、文献を参考に データベースで扱うために正規化を行った。 E-R 図作成 抽出したデータ項目及び関連を表現する E-R 図の作成を行った。また、データ項目 の正規化に合わせて E-R 図の正規化も行った。初めて作成する成果物の為手探りの作 業ではあったが、形にすることが出来た。 CRUD 図作成 Create（生成）、Read（読み取り）、Update（更新）、Delete（削除）のデータベー スが持つ基本機能と本システムが持つ機能がどう対応しているかを表す CRUD 図を作 成した。CRUD 図作成に当たっては機能一覧にある項目が必要となる為、随時進捗を 共有しながら作業を行った。こちらも E-R 図同様初めて作成するものであったが、形 にすることが出来た。 7 月-8 月 コード定義作成 データベースに格納されるデータに用いられる施設 ID などのコードを定義し、それ らをまとめたコード定義書を作成した。 データベース設計 正規化したデータ項目をシステムから利用出来るように物理データベースでの制約を 考慮して設計を行った。 テーブル定義を作成した後にローカル環境でのテストを行った。設計をする際の不明 点などは書籍やウェブサイト、アドバイザからのアドバイスを元に繰り返し設計・テス トを行うことでデータベース設計の奥深さを知る事が出来たと同時に設計技術を身につ けることが出来た。 8 月-9 月 データベースの運用に関する学習 後期からの実装工程に向けてデータベースの運用に関する学習を書籍やウェブサイ Group Report of 2011 SISP - 74 - Group Number 10-A Practical Development of “Usable” System 2011 ト、現役のシステムエンジニアからのアドバイスを参考に行った。 MySQL の学習 実際のシステムを稼働させるデータベースを構築するのは初めてであった為、書籍 やウェブサイトを参考にローカル環境でデータベースを構築し実際に SQL 文を作成し データベースマネージメントシステムを動かす実習形式での学習を行った。 実装に向けた cakePHP の学習 PHP での開発経験があるものの、初めて扱うフレームワークである cakePHP につ いて公式サイトのチュートリアルや解説しているウェブサイトを参考に実際に手を動か して簡単なブログシステムを構築した。 Web アプリケーションのセキュリティに関する学習 2011 年 9 月 10 日（土）に東京都大田区産業プラザ PiO で開催された PHP Confer- ence Japan 2011 に参加した。 PHP アプリケーションのセキュリティに関する書籍として広く知られる「体系的に学 ぶ 安全な Web アプリケーションの作り方」の著者である徳丸浩氏のセッション「徳丸 本に学ぶ 安全な PHP アプリ開発の鉄則 2011」を聴き SQL インジェクションを代表と する攻撃への対策を学んだ。 10 月 データベース構築 テーブル定義を元に、サーバにインストールされた phpMyAdmin を用いて構築を 行った。 10-12 月 データベース調整 同時にスタートした実装の担当者からのフィードバック、顧客との話し合いにより提 示されたリクエストを元にデータベースの設計変更・調整を行った。 ドキュメント作成・更新 データベース調整において発生したテーブル定義書やコード定義書などの関連ドキュ メントのアップデートを行った。 また、システムが実際に動作する顧客のサーバにおいて必要なデータベースの定期バッ クアップなどのバッチ処理の設定に関するマニュアルの作成を行った。 実装 実装工程おいて Google Maps API を用いて地図から施設を検索する機能を実現する ために、住所から緯度経度へ変換するメソッドを Google Maps API を用いて実装し た。 遅延が生じているユースケースの開発補助を行った。また、スケジュールの遅延に伴 い未着手のユースケース（機能）の実装を行った。実装した機能は管理者が利用する施 設をデータベースに登録しシステムで利用可能にする機能、予約に必要な在庫生成の機 能、利用日前日に利用者へリマインダメールを送信する機能であった。 納品準備 データベースに関しては設計・構築・変更したデータベースを顧客の環境で動作させ るためにデータベースを学内の開発サーバから phpMyAdmin のエクスポート機能を用 いて SQL ファイルを出力し、出力されたファイルの手直しを行った。 納品 Group Report of 2011 SISP - 75 - Group Number 10-A Practical Development of “Usable” System 2011 パッケージング担当者と連携し、納品するマニュアルやソースコードのチェックを 行った。 顧客サポート 納品後の受け入れテストにおいて、顧客からのデータベースに関する問い合わせへの 対応や報告された不具合の改修を行った。特に在庫を生成する機能ではメモリ不足、タ イムアウトにより在庫が生成されない問題を解決した。 納品したマニュアルでは不十分であった点を説明すると同時にシステムの導入、サーバ の設定等のサポートを行った。 最終成果発表会 発表会の準備として、当時までに作成されたドキュメントの項目数・ページ数、本プ ロジェクトのメンバが作成したプログラムのファイル数と無効行を除いた行数をカウン トしドキュメントにまとめた。発表スライドのディスカッションを行い発表スライドを ブラッシュアップした。 発表会での担当は最後の発表時間であった。 （※文責: 池田政人） Group Report of 2011 SISP - 76 - Group Number 10-A Practical Development of “Usable” System 2011 第6章 6.1 6.1.1 結果 プロジェクトの結果 結果の詳細 本 PBL の大きな目的はシステムエンジニアの業務の一連の流れを体験することである。前期で は提案から要件定義、設計までの工程、後期では設計から開発、テスト、運用の工程と、ウォー ターフローモデルの一通りの工程を学んだ。 前期では、はじめにプロジェクト提案書など開発に必要なドキュメント作りを経験した。その 際、アドバイザのレビューから、成果物の添削や議論の進め方など、実際にシステムエンジニアと して就業している人からアドバイスをテレビ会議や対面で頂くことができた。 このアドバイスを基にプロジェクトメンバ間で成果物の制作を行っているうちに、質問事項や懸 案事項が数多く浮上した。そこで顧客の予約業務や背景を知る必要があったため、実際にメールや 対面 (未来大でのミーティング、森町への訪問) を通してヒアリングの重要性について学んだ。 それらの活動から、工程、日程などの段取りを決定し、進捗管理を行うプロジェクトマネジメン トを実際に体験することができた。後期に入ってからは実際にシステムが導入されるサーバの仕様 に合わせた開発用のサーバを用意し、コーディングとテストを繰り返した。 しかし、実装の段階で顧客の業務把握が足りない点があることに気が付き、そのため実装に手戻 りが多々発生したため進捗がかなり遅れることとなった。その結果として当初予定していた納期予 定日もずれ込み、すべての機能を実装して顧客へシステムをお渡しすることができなかった。その 代わり顧客と合意を得た上で、納品するタイミングを増やし徐々に機能を追加実装していくという 形となった。 今後も納品し、システムを運用するに必要な機能が全て揃った状態で実際にシステムが運用され ることとなるだろう。 （※文責: 長坂明輝） 6.1.2 本プロジェクトの成果物 本プロジェクトが各工程を経て作成した成果物は以下の通りである。 提案工程 • プロジェクト計画書 • システム提案書 • ステークホルダリスト • リスク管理計画書 • システム開発見積コスト表 要件定義工程 Group Report of 2011 SISP - 77 - Group Number 10-A Practical Development of “Usable” System 2011 • 要件定義書 • ユースケース図 • ユースケース記述 • 機能一覧 • As-Is 業務フロー図 • To-Be 業務フロー図 • 帳票プロトタイプ • 画面遷移図 • 非機能要件 設計工程 • ロバストネス図 • シーケンス図 • 詳細クラス図 • メソッド定義書 • データ項目 • システム設定用データ項目 • コード定義書 • テーブル定義書 • E-R 図 • CRUD 図 • データベース仕様書 • 画面プロトタイプ • 画面イメージ • 画面仕様書 • バッチ処理リスト 実装工程 • FreeBSD サーバ • CentOS5.5 サーバ • CentOS6.0 サーバ • 森町公共施設予約管理システム • 利用者マニュアル 試験工程 • テスト計画書 • 試験成績表 • 障害管理表 • エラーメッセージ表 納品 • 森町公共施設予約管理システムアプリケーション DVD-ROM Group Report of 2011 SISP - 78 - Group Number 10-A Practical Development of “Usable” System 2011 また、各工程で随時下記の成果物を作成した。 • 文書管理規定 • 用語集 • 懸案事項リスト • 議事録 • 進捗管理表 • 懸案事項管理表 （※文責: 若山将太） 6.2 成果の評価 本プロジェクトの 2 つの目標についての評価 システムエンジニアの業務を体験することが一つ目の目標である。 前期では、まず初めに類似サービスの調査、開発言語の選定などを行った。その後、上流 工程 (提案、要求定義、設計) を体験する事が出来たことから、この目標を達成したと考え る。 反省点として、顧客へヒアリングを行うタイミングが遅くなったことを含め、開発スケ ジュールに遅れが生じてしまった。 後期では、前期のスケジュールの遅延をカバーしきれず結果的に機能の削減を行った。問題 が生じたら速やかに顧客へヒアリング・確認を行う、進捗管理を徹底してなるべく作業を止 めずスケジュールに遅れを生じさせないなど前期の反省を活かしプロジェクトを進めた。 これは実際のシステム開発の現場でも顧客に説明し同意を得て行われていることであること で、システムエンジニアの業務を体験する目標を達成する上で貴重な体験が出来たと考え る。 二つ目の目標は顧客の課題や問題点を解決することである。 前期では提案工程に於いて、RFP に記載されている機能以外にも様々な機能を提案した が、スケジュールの遅延により機能を削減して納品する事となった。 顧客の担当者からの評価がよく、実際に本システムを利用したいとおっしゃっていることか ら顧客の抱える問題点を解決するだけではなく、日常の業務の効率化につながるシステムが 開発できたと考える。しかし提案した全機能を実装し納品する事が出来ず悔いが残る。 成果物の評価 各工程での顧客との合意を形成する、コミュニケーションを図るために作成する成果物で ある提案書、要件定義書などは現状の顧客の業務を反映することや RFP に記載されている 事項はもちろん、それ以外に本プロジェクトとして提案する機能を盛り込むことで顧客の合 意を得ることができ、成果物の効果は想定に沿っていると考えられる。 システムの設計に関わる成果物 (データ項目、非機能要件など) はシステムの実装・テス トにおいて十分に活用され成果物の効果は想定に沿うものである。 各種設計は実装工程において変更があったが機能を実装する上で活用され効果は想定に沿っ ていると考える。 システムを構成するソースコードは機能を実現しておりテストを通して品質の向上、リファ Group Report of 2011 SISP - 79 - Group Number 10-A Practical Development of “Usable” System 2011 クタリングを行うことでよりよいシステムを開発する事が出来たことから成果物の効果は想 定に沿うものである。 利用者が読むマニュアルはスクリーンショットを多用し分かりやすさに配慮したものにな り実際にシステムが稼動した際には活用されるものと考えられる。 本プロジェクトで作成した成果物は改善の余地は多々あるものの顧客とのコミュニケー ションを図るため、次工程で役だったことから概ね効果の想定に沿うものであると考える。 最終発表会時点ではドキュメントの項目数は約 400 個、ページ数は約 300 ページであった。 モデル・ビュー・コントローラなどのプログラムとスタイルシートなど合わせたファイル数 と行数（コメントアウト・空行を除く）を表 6.1 に示す。さらに図 6.1 と図 6.2 に示すグラ フより、種別によるファイル数と行数の割合を見ると html を記述するためにビューの割合 が大きくなる事が分かる。 表 6.1 図 6.1 プログラムのファイル数・行数 種別 ファイル数 行数 コントローラ 17 3296 モデル 18 1148 ビュー 97 6715 スタイルシート 5 696 JavaScript 2 12 システム設定ファイル他 2 83 合計 141 11950 種別による行数の割合 図 6.2 種別によるファイル数の割合 （※文責: 池田政人） 6.3 担当分担課題の評価 6.3.1 太田和輝 画面遷移図 どのようなものでどこで使われるかという知識がなかったので作成に時間がかかってし まった。作成するためにはそれにつながる先の成果物の知識とシステムの流れを把握する必 要があった。それはこの画面遷移図によってページ毎にあるリンクや入力するべき事柄など の要素やページとページのつながりが一目でわかる必要があったためであった。最終的には Group Report of 2011 SISP - 80 - Group Number 10-A Practical Development of “Usable” System 2011 トップページにある要素とそこからつながる画面は何かというのがわかるようになったので 良かった。 システム提案書の修正 修正後の意見交換ができていなかった。アドバイザの指摘後にもっとメンバと共有して相 談するべきであった。最終的にはシステム提案書として完成したが、説明とそれに関連する 図がしっかりできていればもっと良いものになっていた。 マニュアル マニュアルとして利用者用・管理者用・phpMyAdmin 用を作った。他のサイトのマニュ アルを参考に自分で表現を考えて１ページに１画面を大きく載せることにしたことでシステ ム利用者が現在どの部分を行っているのかがすぐわかるように表現できた。さらに入力例を キャプチャして例として挙げて作成したことで画面上で動くものを静的な紙で伝えられるよ うにしたことでパソコン初心者にもわかりやすいものになった。しかし、phpMyAdmin 用 マニュアルでは実際に使ってもらったときに時間の在庫生成ができていなかった。そのた め、利用者予約画面で予約ができないという事態が発生してしまった。在庫の生成概念は phpMyAdmin 用マニュアルの最初に説明を書いて、マニュアルに書いてある通りに行って もらえれば利用者が予約までたどり着けると思っていたがそうではなかった。このことから 在庫生成に関する説明が不足していたこと、そしてどの時点で利用者が予約できるようにな るのかをもっと丁寧に説明を明記する必要があったと感じた。 成果発表会スライド作成 成果発表会スライドを作成するために議事録を全て見直した。初めは章立てによってスラ イドの流れを考えたが本システムのデモを含めても発表時間が余ってしまう状態であった。 私の成果発表会のイメージでは本システム作成の手順の発表を考えていた。しかし実際に作 成されて成果発表会で使われたスライドはメンバがどのようにして課題を解決していったの かを発表するものであった。章立てを行う時に自分の成果発表会のイメージを伝えられてい なかったのは反省点であり、スライドを作成するには発表者それぞれが伝えたいことについ て早めに確認をする必要があった。それができなかったため、スライド案を作成してもその ほとんどが反映できない状態になってしまった。そして成果発表会スライド作成で一部メン バに任せる状態になってしまった。これを改善するために早めの図と表の作成を行う必要が あった。そうすることでスライドのイメージをメンバに伝えやすくすることとスライド全体 の完成を早くすることができたのではないかと感じた。 成果発表会 成果発表会スライドの完成が遅くなってしまったために説明を行う為の練習時間を十分に 確保できなかった。本番では発表の時に聴講者の方を向いて発表するという事を説明に夢中 になってしまったために忘れてしまい、発表時間の大半をスライドを見ながらの発表になっ てしまったので聴講者の方を向くという事を意識しながら発表する必要があった。声は他の プロジェクトの発表よりも出せていたが、発表直前の緊張によって発表の出だしでスライド とセリフの棒読みがあったので練習によって発表に慣れていればもっとよい発表になってい たはずなので発表練習はもっと行う必要があった。 議事録 前期では議事録を見直す事が私の課題解決での見直しの時だけであったことと、議事録を 作成するという事が５回にも満たなかったためにどのような議事録が見やすいのかがわかっ ていなかった。その為後期ではその議論場で議事録を作成していくのではなくて、議事録メ Group Report of 2011 SISP - 81 - Group Number 10-A Practical Development of “Usable” System 2011 モを一度取った後に議事録を作成した。議事録メモの取り方として即座に図や表を作成する には手書きが一番早く、修正もしやすかったため、紙による作成を行った。また、重要であ ろう部分は色ペンによるマークを付けた。その結果議事録メモから議事録に掲載するべき事 柄を拾う時のわかりやすさと議事録としてまとめる作成速度が格段に上がった。後期の議事 録は後から見てもわかりやすいものになった。 （※文責: 太田和輝） 6.3.2 金谷祥平 開発体制図・ハードウェア構成図 システム提案書の中の、開発体制図とハードウェア構成図を作成した。まず、開発体制図 については本プロジェクトがどのように外部のアドバイザや顧客と関わり、また、開発の進 行の為にどういった組織の配置を行うかを理解して頂く事に役立った。ただ、プロジェクト 内部の班分け等の配置については実際の工程に於いて動的に変更する必要があった。次に、 ハードウェア構成図については RFP から抽出したシステムのハードウェア的な構成につい て、顧客に再確認して頂くという目的を達成できた。 業務フロー図 As-Is 業務フロー図は顧客の現状業務の流れを分析し、最適なシステム構築に利用するこ とが目的となる。その為、ヒアリング等を行い、問題が無い事を確認して作成した。また、 To-Be 業務フロー図作成に当たって、詳細が未定義の機能も多々あったので、顧客へのヒア リングやメンバとの協議、アドバイザのレビューによる指摘を何度も経て決定していった。 To-Be 業務フロー図については、顧客を交えたレビューにて合意を取り確定する必要がある が、業務フロー図を作成した事によりユースケース記述の作成等が捗り、成果物としての役 割を果たしたと考えられる。 ユースケース記述 ユースケース記述作成に当たり、アイ・ビー・エムメンバのレビューや、複数メンバによ り何度も編集とチェックを繰り返し、成果物としての完成度を高めていった。現在は、未解 決の検討事項を解決すると共に、顧客の合意を得て確定する段階である。また、途中ではあ るが設計工程のロバストネス図やシーケンス図作成の基とすることができた。 ロバストネス図 本図は大まかな分類レベルでのクラスの抽出が目的である為、図の見易さを考えて複数の コントロールを一つにまとめた。図の作成を通してシステムの構造の把握や、機能実現に必 要なデータアクセスとインターフェースの再検討を行い、ユースケース記述へのフィード バックを行うことができた。また、以後の工程でのモデル作成の為の土台を作ることができ た。一方で、本図の作成には当初の予想を超える時間を費やしてしまい、後に予定していた 分析クラス図の作成ができなかった。分析という工程に明確な終わりを見出すのは難しいこ とを痛感した。 分析シーケンス図 分析シーケンス図作成の目的は二つあった。一つは、ロバストネス図で表現不可能なシス テムの動的な振る舞いを記述することである。そして、もう一つは、ロバストネス図で定義 されたクラスについて、シーケンス図上での動作を追うことで、適切な切り分けができてい るかを評価することである。それらの観点から見て、本図は目的を達成できたと言える。特 Group Report of 2011 SISP - 82 - Group Number 10-A Practical Development of “Usable” System 2011 に、ロバストネス図に対するフィードバックをもたらすという点において、大きな効果を得 られた。また、後期の設計工程において、本図を詳細化する形で詳細シーケンス図を作成す ることにも役立った。そして、並行して作成したロバストネス図同様、区切りを付けられず に夏休み中盤まで食い込んでしまった点には問題があったと言える。 詳細クラス図 本図の作成に際して、正式なドキュメントではないがメソッド仕様についても記述した。 しかし、実装の中で何度も内部仕様を変更・修正することとなった為、実装に混乱を生じさ せてしまった。MVC で各層が連携して動作する為には、メッセージのやり取りを明確に仕 様化する必要があることが分かった。特に、連想配列のような不透明なデータの受け渡し を設計で統制する必要性を感じ、設計の難しさとオブジェクト指向の奥深さを知る機会と なった。 詳細シーケンス図 詳細クラス図と同様に、何度も仕様変更が発生してしまった点は問題であった。また、概 念レベルである分析シーケンス図を詳細化するにあたり、どの程度の粒度で記述すれば良い のか掴めなかった為、実装に混乱を生じさせてしまった。一方で、本図の作成により詳細ク ラス図に対するフィードバックをもたらし、品質を向上できた。 機能実装 納期については、1 月まで食い込むことはあったが必要な機能を実装することはできそう である。一方で、実際に自分達の手元を離れて運用されるシステムということで品質につい ても重要な評価対象であった。これについては、実装と並行して試験を行って貰い、不具合 や品質への要件追求に随時対応していくことができた。私は設計工程にも携わっていた為、 設計の視点からシステム全体のアーキテクチャの整理を重視し、モデルクラスやコードの再 利用によるリファクタリングに注力した。自分の担当部分については勿論、全体のリファク タリングについての指針を得ることができた。 クラス定義書 この成果物は本来設計で作成するはたずであったクラス・メソッドの仕様記述を、実装時 の仕様変更が大きいという理由から、各実装担当者に依頼することとなった。私は各自の記 述分の取り纏めと HTML への出力を担当した。記述方法や文書フォーマットについては早 い段階で全体に告知しておいた為、問題は無かった。HTML への出力も、早い段階に方法 を調査し、問題なく出力できるようになった。しかし、各自の記述 (自分の分も含め) につい て、内容の査読を満足に行えなかった為、記述漏れや誤りに気付くのが遅れ、納品直前に収 拾に追われてしまう結果となった。納品物として品質にもう少し責任を持つべきであった。 システム仕様書 (取り纏め) この成果物は設計工程でのドキュメントの取り纏めであるが、納品対象である為、顧客に とっての必要性を考えながら作成した。プログラムの内部的な構造・仕様に言及したドキュ メントということで、すぐに活用される類のものではないが、本システムの運用・保守の局 面において必ず必要となるものとなると考えた。上記のクラス定義書の整理で多少の混乱は あったものの、設計工程で作成済みの成果物の修正と見直しが殆どであった為、落ち着いて 作成できた。 （※文責: 金谷祥平） Group Report of 2011 SISP - 83 - Group Number 10-A Practical Development of “Usable” System 2011 6.3.3 浅井信 関連サイト・技術調査とツールの準備 関連サイトの調査をすることで本プロジェクトが開発するシステムの規模感や顧客に重要 となる機能がどのようなものかを定める 1 つの基準とすることができた。また、それぞれの 調査したサイトの良いところを発見することで開発するシステムに盛り込みたいものなども 発見することができた。何よりも初めて取り組むことに対しての基にすることができた。既 存のサイトから学び得ること、自分達で考えてメンバへ提案していく力も身に付けられた。 いろんな技術がある中、今回の開発を意識した調査を行うことができた。Web 開発をキー として調査を行い、習得がある程度容易であるものを考えて抽出していった。ツールについ ては事前に準備していたため、問題なく利用することができた。 機能一覧作成 本プロジェクトが開発するシステムの機能の全貌この段階で把握するために非常に役に立 つものであった。しかし、工程が進むにつれて機能に曖昧な部分が出てしまい後に更新が必 要となってしまった。これを受けて初期の段階で機能の詳細を決定しておく必要性があるこ とを学ぶことができた。さらには、実装工程に入り、細かい機能単位で誰が対象となる機能 であるかも整理しておくことの重要性についても十分な理解が得られた。例えば施設の登録 については管理者しか行えないが、編集は管理者と担当者のどちらも使える機能であること が挙げられる。要件定義で作成したこの機能一覧をもっと修正して確定できていれば手戻り も起きなかったことも考えられた。 非機能要件作成 機能要件で以外のことであるシステムの品質や性能、セキュリティなどを保証するために 必要なことをまとめて顧客に承認をいただくということは理解できた。しかし、レンタル サーバなどへシステムを導入する場合にはどこまで非機能要件をまとめるべきかを定めるの に苦労した。一度は方針を決め非機能要件を整理して承認をいただいたが後に修正が必要に なることが度々起きてしまった。変更が最小限で済むように非機能要件をまとめることが必 要であったと痛感する結果となってしまいました。もっと詳しいところも勉強してこれから の経験に活かせていけるように、もう一度勉強し直せば自分の力になると確信できました。 もっと経験を積んでみたい作業になりました。 ユースケース記述作成 本プロジェクトはユースケース駆動でシステムの設計・実装を行ってきたが、ユースケー ス記述ではカバーし切れていない機能があることが後になって判明することになってしまい ました。予約システムとして重要な機能であったので、大きな抜けができてしまったこと は残念ではありましたがユースケースが本プロジェクトにとって重要なものでありました。 ユースケース記述も顧客に機能の概要を理解していただくためにも重要な役割を果たすもの で、十分な結果を出すことができた成果物でありました。後半で確認した機能についての抜 けなどの分の更新も行っていけるとより良い成果物となっていたはずである。 ロバストネス図作成 要件定義工程を設計工程をつなぐ成果物としてとても役に立つものであったが、ここに多 大な時間を割く結果となってしまい、分析クラス図など当初予定していた成果物に着手する ことができなかった。しかし、ロバストネス図は機能実現においてデータのやり取りやどの ような画面インターフェースが存在するかを確認することができたので、この点においては Group Report of 2011 SISP - 84 - Group Number 10-A Practical Development of “Usable” System 2011 作成しておいてよかったと感じられました。ロバストネス図という成果物への理解も含め 1 つの良い経験となりました。 中間発表用スライドの作成 実際に発表を終えた後のアンケート結果を集計して確認したところ専門用語がたくさん使 われていて理解するのが難しいとの意見がたくさん出ていた。リハーサルでは、発表ででき る限り補うようにもしていたが、いざ本番になるとスライドを見て発表してしまう傾向が あったために専門用語の補足が足りなかったことが原因であった。対象が学生であることを 考慮して用語についてもっと説明や言い方を変える必要性があったと感じました。この結果 を受けて最後にある成果発表会の発表スライド作成時については専門用語などについて十分 に気を付けて作成してもらえるようにも心掛けることもできたので、ここでの反省が活かせ る結果を出せたので活動した甲斐があった。 新体制案の提案とリスケジュール 後半の活動を受け、プロジェクト全体の体制の見直しとリスケジュールを行った。その結 果顧客へ使い物になるシステムとして納品するために段階的な納品をさせていただくスケ ジュールを立て、承認をいただけるように根拠のある予定を立てていくことができた。体制 についてはリーダーを経験させていただく機会もいただくことができ、その大変さとやりが いを感じた。私はリーダーである以前にプロジェクトのメンバの一員であるので一人で背負 わずメンバへ相談することが大切であることも学びました。リスケジュールの際にも、メ ンバと相談し実装工程にかかる時間の見積もり方についても議論して推し進めることがで きた。 WBS の作成 これまでのスケジュールとタスクの管理は MicrosoftProject を利用して行ってきたが、 後半の活動に入って Excel を利用することにした。Excel による WBS の作成によってタス ク量を細かく分割することで、全体感やタスクに対して担当者も確認できる形にして、これ を用いて進捗管理を行えるように調整した。このような変更により本プロジェクトがどれだ けやることが残っているのかが目で見て確認することができたので、全体を把握するために 非常に重要なものが作成でき、実際に進捗管理に利用することができました。さらに、予定 と実績についても記録として残しておくことができるので、プロジェクトの結果の 1 つとし て記録に残るものになりました。 機能実装 実装班の人数が足りていないということで管理者の機能の一部を担当することになった。 新たに実装メンバの一員となったためにコーディングの勉強をしながら実装をする形となり 非常に効率は悪かったと感じた。しかし、すでに書かれた部分があったり技術を理解してい るメンバもいたため習得までの時間は思っているよりはかからなかった。予定より遅れは出 てしまったが、メンバの支えもあり実装していくことができた。反面、全体の進捗管理の立 場でありながらコーディングに没頭する場面もできてしまい非効率であることは間違いあり ませんでした。私自信の要領の悪さもあったかもしれませんが、予定を守れない状況であっ たためプロジェクトメンバに対してオーバーコミットをしてしまう形となってしまいまし た。この経験より、メンバ一人に対して割り当てられるタスクの量の限界についても考えて いかなければならないことに気付かされました。 進捗管理 後半の活動より WBS を用いて進捗管理を行った。WBS のみの管理では実装の進捗の細 Group Report of 2011 SISP - 85 - Group Number 10-A Practical Development of “Usable” System 2011 かい部分までは確認することができないので、実装の進捗については実装の担当者に別で管 理してもらう形を取ることで WBS で管理する粒度を調整した。これにより、全体でメンバ それぞれが現在何に着手しているかを確認でき、さらには予定通りに進んでいるかどうかも 確認することができました。遅れが出ているタスクについても把握でき、担当者に対して遅 れの原因を問うことでメンバで解決できる形にすることはできた。しかし、進捗管理に時間 をかけ過ぎて会議全体の時間をうまく使うことができずにいたので事前にどれだけ進捗を報 告してもらうかが問題点として残ってしまいました。実践してみるとするのであれば、進捗 管理を 9 名全員の分を行うのではなく、メンバを２つに分けそれぞれで進捗管理をしてもら う方法である。1 名で全員の進捗を管理することが難しいのでサブリーダー単位で進捗管理 をしてみるのも一つの手段であると感じました。 プロジェクト活動報告 顧客のもとを訪れてプロジェクトの活動を報告するという非常に貴重な経験をすることが できました。ここでは、後半の活動で本プロジェクトが予定通りに納品することができなく なってしまったので、今後どのようにして納品させていただくかも報告し承認していただき ました。プロジェクトを代表し納期を守ることができないことに対しての謝罪をする機会と なってしまったことは本当に悔しい結果であったことは残念でした。これまでのプロジェク トメンバの努力についてはよく知っていたので言葉に出せない悔しさを味わうことになりま した。学生のうちに数少ない経験をすることができ、私個人としては報告書の作成方法につ いても学ぶことができましたし、この経験はとても忘れられないものとなりました。 納品 納品については当初予定していた納品日にすべての機能を納品し切れなかったことは非常 に残念であった。しかし、最終的に顧客に使っていただけるシステムを納品するためにプロ ジェクトメンバ全員で議論してどのようにすれば良いかを決め、顧客へ承認をいただくこと ができた過程についてはとても重要な経験となりました。このような機会がまたあれば次は 絶対に納期を守りシステムを納めたい。最終的には段階的な納品を行うことができたが、顧 客の要求を受け入れていく余裕がもう少しほしいとことでした。 （※文責: 浅井信） 6.3.4 藤原哲 関連サイト調査 顧客から RFP を受領後、提案フェーズの提案書作成作業に取り掛かる前に、既存の類似 サイトの機能を調査することで森町役場に導入するシステムに必要な機能をどのようなもの にすべきか考えた。これによって、人口やそれぞれのシステムを導入するユーザに関わら ず、施設予約サイトとして絶対に必要な機能と森町の人口やニーズに合わせて提案すべき機 能の考案などが出来た。 開発コスト見積り 顧客にシステムを開発する際に掛かるコストの見積りを行って、人月ベースでの人件費や 導入コスト、運用コストがどのようなものになるかを算出した上で顧客に提案したが、本来 のシステム開発のコスト算出としてファンクションポイント法という機能の大きさに合わせ てやる必要があった。今回提出した見積もりは、本来の提案に向くものではないので、機能 の面から算出しなおすことが出来ればもっと具体的な契約を踏まえた提案として行えたと Group Report of 2011 SISP - 86 - Group Number 10-A Practical Development of “Usable” System 2011 思う。 As-Is 業務フロー図作成 システムの機能や利用手順を検討するにあたって、現状業務の把握と問題点や課題を抽出 するために As-Is 業務フロー図を作成した。作成の際に、メールでのヒアリングを通じての 現状業務を緻密に把握していき、最終的な確認として自分自身で森町公民館職員の方とのヒ アリングによるメール応対時のお互いの意識の行き違いの修正、更には窓口業務の見学と調 査によって自分が作成した As-Is の業務フロー図の確定を行うことが出来たので、必要なフ ロー図は作成出来た。 To-Be 業務フロー図作成 As-Is の業務フロー図を作成後に、具体的どのような機能や手順を取り、現状の問題点や 課題を解決・改善するかを検討するために To-Be 業務フロー図を作成した。作成にあたり、 日本アイ・ビーエムの方からアドバイスをいただき、機能として実現不可能な部分やもれて いる必要・不必要な機能の指摘をいただきながら業務内容を検討していき、システム導入後 の具体的な業務を検討できた。しかし、システム導入後の検討を顧客に提示が遅れてしま い、その後のユースケース記述に大きな遅延を発生させたので前期の一番の反省点である。 プロトタイプ作成 システム実装時の実現可能性と顧客のデザイン的な機能の合意のためにプロトタイプを作 成した。作成は、システムのメインの部分のみを作成した。しかし、プロトタイプは HTML 記述のみであり、スタイルシートによるレイアウトの統一や PHP による処理の実現可能性、 サーバとの兼ね合いによる使用可能機能の調査を行った上でのプロトタイプの作成が出来な かった。それによって実際にシステム実装への橋渡しとしてのプロトタイプは着手すること が出来ず、画面モックアップの段階で止まってしまった点は、技術検証を踏まえてもう一段 階深くやる必要があった。 FreeBSD サーバ構築 システム構築用に FreeBSD でサーバを構築しようとしたが、自分が今まで触ってきた UNIX(Linux のみ) との違いが大きくあり、実際に操作しようとしたところ、コマンドや ディレクトリとファイル構成の把握、BSD 特有のソフトウェア管理システムである ports の使い方など操作自体に手間取ってしまった。インストールが必要なソフトウェアや設定項 目の調査をしただけでは不十分であり、余計な時間を使ってしまったのは自分のプロジェク トへの取り組み態度として問題があった。 CentOS5.5 サーバ構築 顧客が新たにレンタルする先と同じサーバとして CentOS5.5 をインストールするときに は、FreeBSD サーバ構築のときの調査不十分な点からの反省を活かし、自分の PC 内に仮 想 PC 環境を作り必要な手順を可能な限り再現出来たのは非常に良かったと思う。また、顧 客が使用するサーバのソフトウェアのバージョンやスペックの調査も事細かに行うことが出 来、その結果ほぼ同じ環境のサーバを構築出来たのはその後の開発のために非常に良かっ た。また、事前調査を細かくやったので作業がストップすることも少なく、時間的にも最小 限の作業に済ませることが出来た。 システム開発環境構築とメンバ環境設定 CentOS5.5 のサーバ構築の中で、システム開発・運用の際に使うソフトウェア群以外に、 開発に関わるソースコードのバージョン管理用のソフトウェアである Subversion を導入し た。この導入によって、一つのファイル内で作業を複数人が行う場合の競合回避がサーバ側 Group Report of 2011 SISP - 87 - Group Number 10-A Practical Development of “Usable” System 2011 で行えた。また、誤ったソースの上書きや削除が見られたがその点についても最小限の工数 で回避出来る環境にすることが出来たので、プロジェクトを円滑に進めるために非常に有用 だった。 システム環境構築 (CentOS 6.0) 顧客との会議の結果、顧客が我々の開発するシステムをテストのためのサーバを自前で作 るという話が上がった。そこから、現在開発のために使用しているソフトウェアの環境を保 ちながら、Linux がまったくの未経験である顧客が構築しやすいサーバを提案するための検 討を行い、CentOS6.0 を提案するに至った。このディストリビューションでは、CentOS5.5 のサーバを構築のときに苦労した後悔されているソフトウェアの最新バージョンと CentOS 公式リポジトリに登録されている最新パージョンの差が小さくなっており、自分で構築す る際にも CentOS5.5 構築時のおよそ半分の時間で構築が完了出来る程だった。その点を踏 まえて、Linux 未経験者に提案するサーバとしても、11 月のシステム開発の真っ最中で工 数が割けない状況の中であまり工数が掛からない作業にすることが出来たので、非常に良 かった。 サーバ導入マニュアル作成 CentOS6.0 でのサーバ導入時に、顧客が導入する際の手順説明を作成した。自分では設 定をしながら可能な限り説明したつもりではあったが、顧客側の設定の際には対応出来てい ない情報が部分的にあった。最終的に顧客はマニュアルに沿ってサーバ導入が出来ず、複数 回のメール対応と本学にお越しいただいての直接対応となってしまったので、実際にマニュ アルを他人に評価してもらうなど客観的な情報の評価を得るべきだったと考える。 システム開発 システム開発に対する私の課題は、まずプロトタイプ作成の中の CakePHP 調査からだっ た。夏休みに CakePHP についての調査と技術習得が課題であったが、PHP の調査の必要 性に気づくことが出来ず、フレームワークとしての本質部分を調査することが出来なかっ た。その結果、夏休みに詳細設計としてクラス図やシーケンス図を担当しているメンバの方 が、自分よりも調査が進んでいた。これはそもそも自分の技術習得方法に問題があり、書籍 の利用方法や基礎知識取得後の応用方針や実践方針の立て方など、実装するシステムに主眼 を置いての計画など様々な面での改善が必要とされるものであった。 実際に開発を開始した当初のコントローラ部分実装では、クラス図やシーケンス図、デー タ項目一覧などの作成済み成果物から実装が可能になる予定であったが、結果的にはモデル 部分の実装が完了するまでの間を待機してしまい、非常に大きな時間をロスしてしまった。 また私のコントローラの実装によって、ビュー部分への遅延も多く発生してしまったので、 後にする開発体制の変更以外にも、改善のための方法を考える必要があったと感じる。 開発体制変更でユースケース毎の実装を開始してからは、データの受け渡しなどの MVC 毎に分担したことによって生じていた、データの受け渡し間違い等の単純なミスも劇的に改 善され効率的な開発に移行出来たので、開発体制の変更の提案や実際にそれが出来たのはプ ロジェクトの進捗に大きくプラスに出来た部分であった。 納品 納品は、顧客が RFP で指定してきたデータとシステムを導入・運用する上で必要になる もの、または補助するものを DVD に保存する作業であった。その際の取りまとめとして、 テストのスケジュールの計画ミスや納品書類の校正などの作業に遅延や抜けが生じてしま い、DVD に保存する作業が納品前日であったり、当日に DVD の作成し直しなど慌ただし Group Report of 2011 SISP - 88 - Group Number 10-A Practical Development of “Usable” System 2011 い作業となってしまったので、もっと手前の工程の管理が必要であった。 顧客サーバ構築補助 上記のサーバ導入マニュアルでは顧客がサーバを構築しきれなかったため、本学内におい てサーバ構築の補助を行った。作業は 2 回に分けて行われ、予定されていた時間よりも早 く終わるなど非常にスムーズに行えたこと、顧客担当者への技術支援 (指導) も行えたので、 システム運用のために必要以上の部分を行えた点で非常に良かった。 （※文責: 藤原哲） 6.3.5 若山将太 プロジェクト計画書素案・ステークホルダリストの作成 プロジェクト計画書は項目や内容について検討が足りなかった箇所がプロジェクトの目的 や目標等いくつかあり、これからも必要な文書なので修正が必要である。また、ステークホ ルダリストは利害関係者の責務や影響について RFP 等を確認し作成出来た。 業務フロー図とユースケース図の作成、要件定義書の調整 業務フロー図とユースケース図は作成したことがないものだったのでウェブの検索機能を 使い情報を集めながら作成する形となった。業務フロー図については、機能要求やその意図 を理解し簡潔に書くことや他のメンバの成果物との整合性取ることが大変であった。ユース ケース図は業務フロー図や機能一覧を基に作成した。どちらもプロジェクトメンバ間で共有 し、顧客から合意を頂くこともできたので納得出来る成果物となった。 データ項目の正規化、E-R 図・CRUD 図の作成 これらは、現段階でまだ確定したものは出来ていないが、これも同様に他の成果物と矛盾 が無いように気をつけた。またデータ項目の細かい部分まで検討する必要がある。 要件定義書作成（取り纏め） デザインレビューの際に要件定義書として、下記の 7 つの成果物を纏めたものが必要と なったので作成した。 • システム導入の目的と目標 • システムの概要/システムの構想 • 業務フロー図 • 機能要求 • 帳票プロトタイプ • 非機能要件 • 画面遷移図 これらの成果物は既に完成していたのでそれらを取り纏め、各成果物の確認を行い、体裁 を整えた。 携帯端末用ページ作成のための技術調査 この技術調査ではまず CakePHP の携帯端末用ライブラリである KtaiLibrary の調査を 行い、その後実際にその機能が使用できるかを技術検証した。まず KtaiLibrary の調査で は利用できる機能やその使用方法について調べ、それから実際にソースコードを書き、その 機能が携帯端末で意図した通りに動くかを確認した。このときは携帯端末かどうかを判別す る機能と携帯端末の物理ボタンと連動した keyaccess の機能の 2 点しか確認していなかった ので、後に一部の携帯端末では Cookie の機能が搭載されていなくセッションが利用出来な Group Report of 2011 SISP - 89 - Group Number 10-A Practical Development of “Usable” System 2011 かった。このため手戻りが発生し、システム開発の遅延の原因の一つになってしまった。 携帯端末用ページの実装 本システムは MVC モデルを採用しており、パソコン用のページと同じ機能を携帯端末用 ページに実装する必要があった。 モデルはパソコン用のファイルをそのまま利用することが出来た。しかし携帯端末用ペー ジを実装するにあたって足りない記述や使用できない記述が存在したため、担当者に対応を 依頼した。 コントローラとビューでは携帯端末用ページ作成のための技術検証に上記で示したような 抜けがあり、一部の携帯端末では Cookie の機能が使用出来ずセッションが使用出来なかっ たのでコントローラ・ビューで共に大きな手戻りが発生し、仕様を変更して修正する必要が あった。またビューではデバックの多くをパソコンで行なっていたため、試験で携帯端末で は使用できない HTML 記述が使用されていることに気付き、納期間近になってから修正を することになってしまった。この二つの手戻りが原因で携帯端末用ページの全てのファイル を書きなおす必要があった。 画面仕様書作成 携帯端末用サイトの実装を行ったため画面仕様書も作成することになった。当初はパソコ ン用の画面仕様書と同じように画面イメージを作成し、それとあわせて画面項目説明書を作 成する予定だったが、スケジュール管理のミスにより納品間近から画面仕様書を作成するこ とになってしまい、パソコン用の画面仕様書に携帯端末用ページとの差異を記述する形と なってしまい画面イメージを作成することが出来なかった。 試験成績表作成 早い段階から試験を行なっていたが、バグ・不具合の修正が追いつかず試験成績表を納品 する時点でシステム稼働には問題ないがバグを残す形となってしまった。試験機種は RFP に記載してあった 3 キャリアで行った。試験は各キャリアから 1 機種ずつシミュレータで 行い、1 キャリアのみ実機で行った。これはそのキャリアのみブラウザが RFP の要求にあ る期間で変わっており、古いブラウザを搭載した機種と新しいブラウザを搭載した機種とで 試験を行うためこのような形を取って行った。計 4 機種で試験を行ったがその中で特定の 機種だけ試験成績表のあるテストケースが可または不可になるといった機種依存は見られな かった。 障害管理表作成 試験成績表と平行して作成し、試験成績表との矛盾がないように、また障害・バグの状況 がわかりやすいように気をつけた。さらにプロジェクトメンバ間で共有し、パソコン用ペー ジでも起こりそうな障害があれば確認出来るように行った。試験成績表で不可の部分が一部 あったため障害管理表の項目が増えてしまったが、これは今後の納品で排除していく。 納品 携帯端末用ページのソースコードと画面仕様書、試験成績表を作成し、納品する成果物は 期日までに作成することが出来たが、その内容には上記の [携帯端末用ページの実装]、[画面 仕様書作成]、[試験成績表作成] で上げたような不備が残ってしまい、バージョンアップで補 完する形となった。 （※文責: 若山将太） Group Report of 2011 SISP - 90 - Group Number 10-A Practical Development of “Usable” System 2011 6.3.6 武田麻依 他地域の施設予約システム、使用候補のプログラミング言語の調査 発表自体は滞りなく行えた。発表の内容もそれなりに詳しいものになり、軽いプレゼンテー ションの練習にもなったが、調査してきた内容が似通っている節がやや見られた。特に、プ ログラミング言語については、それぞれの言語の違いなどははっきりとした違いを見つける ことはできなかった。また、本システムでは重要となる携帯サイトについて調べてきた者は 殆どいなかった。これらの原因は、検索エンジンにかけたときに、上がって来たものを順番 に、ある程度見て回ったことだと思われる。大人数で同じことを調べるのは、非効率だと思 われる。このことから、各自で調査等を行う際は、他者が調べて来ていないだろうと思われ るような内容を探すようにすべきだと思った。 As-Is・To-Be 業務フローの作成 As-Is、To-Be 共に、業務フロー班でタスクを分担して取り組んだ。ツールは初めて使うも のだったが、事前にいくらか練習したこともよかったのか、作成自体にはそれほど支障はな かった。この作業で作成した業務フロー図は、顧客にシステム導入による業務の変化を伝え るだけでなく、私たちにとっても、システムを構成するための良い指針となった。途中で必 要だと判断して作成した粒度や表記方法の基準は、業務フロー図を作成する時に忘れないよ うに意識して心がけた。これにより、各業務フロー図に統一感を出すことが出来た。また、 この作業の際に各作業のタスクの負担を考えて作業を割り振ったが、このやり方はこの後の 作業でも大いに役立てることが出来た。しかし、この作業を行っている頃はまだメンバと 知り合って間もなかったので、心なし関係が気まずく、あまり積極的にメンバに疑問点を 尋ねることができなかった。そして、そのことが作業に影響を与えてしまったことも多々 あった。 プロトタイプの作成 設計工程にて、プロトタイプ班はプロトタイプの作成を目的として作業を行った。現時点で はサーバの構築、サーバの整備、雛形となる HTML の作成しか行っていないが、この時点 でもスペック、画面遷移などの問題点を発見できた。サーバの構築、整備については、少々 教員のアドバイスを受けつつも、基本的にはメンバで調べたことを合わせて行った。構築に ついては、メンバの一人が詳しく調査をしており、作業は比較的スムーズに進んだが、自分 は殆ど役に立つことはできなかった。この点については、他のメンバも同程度とまでは行か なくても、もう少し FreeBSD についての程度の情報を調べておくべきだったと思った。ま た、この時点で作成したものは、デザインの基盤というべきもので、プロトタイプとはいえ なかった。このため、プロトタイプの技術検証という目的は果たせず、その後の設計・実装 工程が非常に困難なものになってしまった。この時、プロトタイプとはどういうものなのか を、事前にきちんと調べておくべきだったと思った。これらのことから、一応この課題は多 少はプロジェクトに貢献できたとは思うが、プロトタイプを作成することの本来の目的は全 く果たせなかった 画面設計の基盤の作成 画面設計の基盤の話し合いは多少時間がかかったが、ひとまずメンバが合意できる画面の基 盤は作成できた。主な成果としては各画面の共通部分の項目や、レイアウトなど大まかな UI 設計を考案したことだった。後にシステムには大幅に修正が加えられることになり、こ の基盤が殆ど原型そのまま採用されることは無かった。しかし、全体のイメージは、その後 Group Report of 2011 SISP - 91 - Group Number 10-A Practical Development of “Usable” System 2011 の UI 設計、画面仕様書の作成に流用されることになったので、少しはプロジェクトの役に 立てた。このことから、画面設計の基盤の作成としては、本当に簡単な基盤ではあったが、 一応の目的を果たすことができた。 エラーメッセージ システムで必要になると思われる、エラーメッセージの文を考案した。エラーメッセージの 作成は殆どテスト計画の考案と同時に行うことになった。エラーケースを作成する上でもエ ラーメッセージは必要だったので、テストのことも考慮に入れながら文を考えた。その際、 システムを実際に操作し、必要だと思われる箇所を考えた。結果としては、エラーメッセー ジを考案することで、実装者の負担を少しでも減らすことが出来たし、システムのどの部分 にエラーメッセージが必要なのかについてもメンバで検討することが出来た。また、エラー ケースについて考えることで、テストケースにはどのようなものが必要なのかについても深 く考えることができた。このように、エラーメッセージを作成することの目的は果たすこと ができた。もっとも、結果的には、当初考案した文の半分ほどしか実際には使われてはいな いが、元々可能な限り考案した後、必要なものだけを残して削る予定だったので、このこと に関しては問題は無いと考えた。 テスト計画の考案 テスト環境の構築の詰めが甘かったため、後にテストを行いながら環境を整えることになっ てしまった。詳しい内容は次項で説明するが、テストに問題がないように修正は行えたの で、テストを始めることはできた。テスト計画書を作成したものの、メンバにテスト計画書 の閲覧の促進を怠ってしまったため、テスト手順を知らないメンバがいるままテストに突入 してしまい、結果としてテストに遅延が発生した。テストの全体的な流れを説明するのに時 間を割いてしまい、後の作業に影響を与えてしまった。また、テスト計画書を作成する際 に、実装者に相談したことが少なかったため、考案した障害対策では実装者とスムーズに連 携が取れず、修正のやり取りに語弊が生じ、それもまたテストの遅延の一因となってしまっ た。以上の深刻な問題がいくつも発生したため、テスト計画の考案は成功とは言えないと考 えられる。しかし、その後テスト計画は修正は加えたものの、大筋は変わらず、テスト実施 の指針とはなったので、テスト計画を考案することの目的は果たし、プロジェクトに貢献す ることができた。 テスト実施 テスト経験が足りなかったことと、テスト計画が甘かったため、想定よりもスムーズにテス トを行うことが出来ず、全体的に遅延が発生してしまった。具体的には、テストを開始して 初めて発見したテストケースが多々あり、その追加・修正に時間がかかってしまった。携帯 用のテストケースも、実際に行ってみて、さらに必要なテストケースや、逆に不要なテスト ケースなどが発見されたため、そちらも携帯テスト実施者の要望に合わせて修正をおこなっ た。また、当初はテスト環境を構築する際はソースのコピーだけで良いと思っていたが、構 築の際、環境に合わせて書き換えなければならないソースがあった。その発見が遅れてし まったため、テストに予想外の時間がかかってしまった。テスト環境の構築ついては、ソー ス管理に用いた SVN の構造・使い方を理解するのに時間がかかり、上手く環境構築が出来 ないことも多々あった。これらの点については、開発環境を構築し、その内容に詳しいメン バに助言を仰ぎ、修正を行った。以後は、テスト環境を構築した際は、毎回最初にその修正 を行うようにした。他、自分の視点で障害管理表を作成したため、実装者にとって情報が不 十分で、修正が思うようにいかなかった。また、システムの仕様が明確に決まっていなかっ Group Report of 2011 SISP - 92 - Group Number 10-A Practical Development of “Usable” System 2011 たため、テスト工程の最中にシステム仕様の変更が起こり、それによってもテストケース・ テストデータの修正が発生した。以上、環境構築のほかにもテストの実施中に様々な問題が 発生したが、問題それぞれの改善策を考え、実行したおかげで、少しずつ改善されるように なった。 テスト開始当時は不慣れなこともあり、あまり大きな障害は発見できなかったが、次第にテ ストに必要な項目が分かるようになり、後半のテストではきちんとシステムに貢献できる障 害を見つけられるようになった。また、テストの当初はまだ少しメンバに思い切った質問を するのにためらいがあったが、それも少しずつだが改善していった。 議事録 メンバからアドバイスをもらいながら作成し続けたおかげで、他人に読みやすい文章を作る コツが少しわかるようになってきた。その力は議事録に限らず、他の文書の作成にも生かす ことが出来た。また、議事録は読みやすく、要点だけきれいにまとまっているので、他の作 業中に以前の決議事項について確認する際に非常に役立った。プロジェクトの当初は集中力 が切れやすく、議事録を書き切ることがなかなかできなかったが、回数を重ねるごとに、そ の点も改善できるようになった。議事録を記録することは、将来も行う可能性が十二分にあ るので、この PBL 学習で学べたことは就職後にも役立てることができると思う。 （※文責: 武田麻依） 6.3.7 長坂明輝 関連サイト・技術の調査と報告 顧客の RFP に基づいて現存する類似サイトを調査しプレゼンテーションとして報告し た。これによりどのような物を作成するかというイメージも膨らますことができた上に、現 存の類似サイトに存在する問題点 (アクセシビリティや使いやすさ、予約方法の煩雑さ等) を発見することができ、今後の成果物にもそのような問題を起こさないように注意すること ができるようになった。 また、開発に使う言語を調査し選定したことにより、文法や概念の予習ともなりグループ 全体から見ても全員がプログラミングの予習ができたと考える。ただし発表したプレゼン テーションについて、発言内容が長くなってしまい理解しやすいとは言いにくいとの指摘も あったため、今後 1 年間 PBL を通して気を付けていくべき点だと感じた。 システム提案書の作成 システム提案書の作成において、システム化の背景の章を担当した。顧客の提案依頼書を 熟読し理解しなければ書けない部分であったため、より提案依頼書の内容の理解を深めるこ とができた。 また初めてドキュメント作成し、初めてドキュメントを共有したため連帯感や責任感を実 際に感じながら作業を行うことができた。今後もドキュメントなど成果物を制作する際に は、その成果物を見て頂く目的などを考えた上で制作していきたいと考えた。 また、ウォーターフォールモデルに基づく開発の過程それぞれで発生するドキュメントは どのようなものがあるのか、そしてそれらはどのような内容なのかなど興味を抱くことがで き自習しようと考えた。 帳票プロトタイプ (CSV 版、HTML 版) HTML 版の帳票プロトタイプの作成で、他の現存サイトを参考にして制作した点につい Group Report of 2011 SISP - 93 - Group Number 10-A Practical Development of “Usable” System 2011 て帳票としての意味だけではなく、レポート出力機能や CSV ダウンロード等の機能面から デザイン面まで考慮して作成することができた。 HTML や CSS を 1 からコーディングができたのは良い点だが、レビューの時はかえっ てデザイン面での指摘が多くなり本来の帳票としてのレビューを頂けなくなる可能性がある とアドバイザからご指摘を受けた。現場を経験した方からそのような意見を頂き、結果とし て顧客からのレビューで起こり得る懸念を先に学ぶことができたのはとても良かったと考え る。 その考え方を応用すれば、システムのプロトタイプをより早く制作しシステムに対する懸 案事項をより早い段階から引き出せたのではないかと考えた。 また、顧客が実際に利用している帳票をもっと早い段階に見ることができれば、より顧客 の想像されているシステムと PBL の想像しているシステムとのギャップを発見し埋めるこ とができたのではないか。 プロトタイプの作成 プロトタイプの作成では HTML と CSS のコーディングを担当した。当初はプロトタイ プ班のリーダを務めていたが、連絡やコミュニケーションを積極的に行わずメンバ全員に迷 惑をかけた影響が大きかった。 その理由としては、グループワーキングの経験が不足しており報告・連絡・相談などの基 本的なコミュニケーションに対し不安があったためであった。それが長坂本人には大きく響 いてしまい、対人関係にまで影響が出始め、最終的には前期と後期で数日（プロジェクトだ けでなくサークルや講義までも）無断欠席してしまう事態となってしまった。 この件については当時のプロジェクトリーダであった江戸とプロジェクトの担当教員と 3 者で面談を行い、長坂のその心打ちを正直に打ち明け、学内のカウンセラーを受けることに より問題を和らげることができた。 結果としては、プロトタイプ制作班のリーダを交代し長坂がコーディングに集中すること で作業の効率化を図ることとなった。作業内容より、むしろチームワークとコミュニケー ションの大切さを大きく感じさせた。 当時完成させたプロトタイプは静的な成果物であったが、実際に動作するものとして制作 すればより早い段階からシステムに対する問題点を発見できたのではないかと繰り返しアド バイザからご助言を頂いた点があった。 また、複数人でプロトタイプを分担して作成したがデザイン面まで考慮して作成してしま う人がいたため、成果物に対する共通認識がメンバ間で取れていないことがわかった。その ため、今後は成果物を作成する際には成果物の目的や制作時に気を付けることなどをメンバ 間で確認して認識しておくようにしようと考えるようになった。時間短縮や効率化のために も、認識を統一させることはチームワークにとってとても重要だ。 FreeBSD サーバ構築 顧客が実際に導入すると想定したサーバ構築の作業で、OS のセットアップを担当した。 その環境を整えることにより実際に導入した後の環境によるトラブル（OS やソフトウェア、 ネットワーク等の環境の変化）を減らすことができると考えたからである。 履修していたシステム管理方法論によって学習したコマンドの利用方法などにより難なく セットアップ自体は完了したが、今後のことを考えずにソフトウェアツール群 (Ports) を同 時に入れなかったため、後のソフトウェアのセットアップや環境構築に遅延を発生させてし まった。 Group Report of 2011 SISP - 94 - Group Number 10-A Practical Development of “Usable” System 2011 セットアップの手法を知ることだけではなく、今後その OS をどう利用していくのかを考 えた上で最適なセットアップを行えればよかった。また、システムを導入する予定のサーバ の仕様が変更されることがあり、サーバ構築及びソフトウェアのセットアップ等多大な作業 量の手戻りが発生した。その時にシステムのビュー作りだけでなくそちらにも手掛けること ができれば今後実施する予定だった実装工程の遅延も少し食い止めることができたのではな いかと考えた。 HTML、CSS、JavaScript の技術習得 夏季休暇という 2 か月の期間を考えると、特に JavaScript を盛り込んだプロトタイプ（例 えば Google マップからの施設検索機能、検索機能の Ajax 化及び Ajax を問いいれた PHP システムのテスト等）をより多く制作できたのではないかと考える。実際に制作したプロト タイプはトップページの 1 ページのみであったからだ。 またその影響からか、後期に実装していくシステムの画面デザインがそのプロトタイプが 基となり大幅なデザインの修正や代替案の提案が行われることがなかった。それにより本来 UI 設計が先行して行われるべきが、プロトタイプのデザインを基に UI 設計をしていくとい う逆転の事態となってしまった。 前期の段階でトップページのデザイン案が 2 つ存在していたため、それらを基にしたプロ トタイプを制作した上でメンバへ展示することができれば、よりデザインに関する意見を頂 くことができたのではないかと考えた。 また、後節のシステムのビュー制作にあたっては HTML や CSS のコーディングそのも のよりも各ブラウザの仕様で発生する画面上のズレに合わせる、CSS ハックに多大な時間 を取られてしまい、そこまで予習できれば良かったと考えた。なぜならば、後期に担当した システムのビュー制作において一番時間がかかった内容が CSS ハックであったからだ。実 際に利用されるお客様の環境を考えたり、RFP を一度熟読していればそこに早く気が付け たのかもしれない。 システムのビュー制作 はじめにシステムのビューを制作するに当たり、システム開発に使う言語である PHP 及 び PHP フレームワークである CakePHP の利用方法を学ぶ必要があった。そのため初め に PHP の基本と共に CakePHP を利用したアプリケーション開発の手法を学ぶこととなっ た。 その影響で、実装の初期段階においてビューの実装の進捗が大幅に遅れてしまった。 CakePHP を利用した開発自体も、Web サーバ上で開発しデバッグすること自体も初めて であったため、例えば白紙のページが表示される等初歩的なトラブルが多数発生し、解決す ること自体にも相当な時間を取られてしまった。 またシステムの仕様上、コントローラが制作されたとしてもビューが無ければ動作ができ ないため、コントローラ担当者とうまく進捗を合わせることができなければ動作確認すらで きなかったためである。それに加えて一人の考えで行ったプロトタイプ制作と違う点が、UI 設計に基づいて多数のページを作成するという点だった。UI 設計者と積極的に連絡を取ら なかったため、自分と相手との考えのギャップを埋めることも遅くなった。 長坂の活動全体に言えることだが、より連絡をしていればより成果物の品質を早い段階に 上げることができたと言える。またビューに対する微調整などの修正点がなかなか減ること はなかったため、UI 設計担当者等と分担して行うべきであった。そうすればビューの品質 がより向上できたかもしれない。 Group Report of 2011 SISP - 95 - Group Number 10-A Practical Development of “Usable” System 2011 さらに言えば、HTML や CSS、PHP で書かれたビューのソースコードについて可読性を 踏まえてコーディングできていれば他メンバからより容易に流用されることができたかもし れない。 他の人が利用しやすいように、例えばテンプレートを用意してコードのみならず見た目で も利用しやすくするべきだった。コメント記述量も増やせば容易に他メンバからも修正が行 えたかもしれない。 （※文責: 長坂明輝） 6.3.8 江戸太樹 類似サイトの調査 Web 上に公開されている自治体の類似サイト、別事業の予約サイトなどを参考に特徴的 なコンテンツを抽出した。これを参考に提案機能を考案するだけでなく、システム利用方法 の図による視覚的な表現、高齢者への配慮としての文字サイズの変更機能など、提案するほ どではないが Web サイトを構築する上で参考になる点が多く見つかった。既成物から案件 にマッチするコンテンツを抽出し、結合して利用することで経験のなさを補うことも可能で あることを学んだ。 提案書の作成 提案書作成において、私は提案書全体の構成の検討、取りまとめを担当した。そこでは担 当者の作成したファイルを全てチェックしていたため、チーム全体で作業の全体像が共有さ れず、作業負担が一部のメンバに集中するという事態が発生した。この事態に対し、後に続 く要件定義ではプロジェクト内を複数のサブプロジェクトに分け、それぞれに責任者を設置 することで連絡系統の整備、資料チェックの負荷分散に成功した。 今回作成した提案書の構成は 4.3.1.2 節で示した通りであるが、概要と概要図が別々の節 に分けられている等、冗長性の高い構成となっている。提案書は顧客に提出するものである ために直感的でわかりやすい方が受けが良い場合もある。今後また提案の機会があれば今回 の反省を役立てたい。 全体スケジュールの記述 開始時点で、各工程にどのような成果物を作成するか、という粒度で開始予定と終了予定 だけを示した全体のスケジュールをガントチャートの形式で記述した。この段階でのスケ ジュールには根拠がなく、実現可能性に欠けていた。実質無計画に活動へと取り組んでいた ようなものである。本来であれば危機感を覚えるべきところであるが、この段階では初めて の取り組みに対して正確な見積りを立てることの重要性がわかっていなかった。また、成果 物を基準としてスケジュールを立てていたために、見かけ上では計画通りに進行しているよ うに見えてしまっていたところも計画の再見積りへと乗り出せなかった一つの原因である。 これが後の大きな遅れにつながる。 業務フローの記述 現状業務の流れを事前に想定で記述することにより、顧客との少ないコンタクト回数で細 かい点まで深堀してヒアリングができた。また、現状業務の流れとシステム導入後の業務の 流れを比較することにより、新たに発生する業務や改善する業務が明らかになり、顧客との 確認の際に非常に役立った。作業の面では、分担した業務フローの間で記述方法や解釈に齟 齬が発生し、その解決に時間をかけてしまった。 Group Report of 2011 SISP - 96 - Group Number 10-A Practical Development of “Usable” System 2011 森町訪問に向けて資料作成 チーム内で当日確認すべきことを整理しておくことで、ヒアリングの目的が明確になっ た。これにより、当日に議論が逸れることもなく、電子的なやり取りでは得られない有意義 な情報が得られた。また、咄嗟に話を持ちかけた際の顧客の反応などから、顧客の趣向が掴 めた。ただし、議事日程の確認を顧客へとることが遅れてしまったために、当日の進行に支 障をきたしてしまった。今後は計画に抜け漏れがないか事前にリハーサル等を行うことに よって綿密に確認し、メンバ全員が万全な状態で顧客との打ち合わせに臨めるようにする必 要がある。 ユースケース記述作成 はじめに担当者の間で 1 つのユースケース記述を共同作成して記述方法を確認した結果、 業務フロー図作成時のような記述規則や方針の食い違いは少なかった。プロジェクトにおい ては何を行うかによらず規模感を掴み所要時間を算出することが重要であるため、サンプル の作成は非常にいい取組み方であると学んだ。 内容の面では、ユーザとシステムの対話となる基本系列、その例外系列や代替系列について は非常に詳細に記述できた。しかし、各系列における入力項目や出力項目、ビジネスルール については記述できず、それが要件定義の漏れ及び後の手戻りを発生させる原因となってし まった。 ロバストネス図作成 初めにメンバ間で表記方法を確認することで、記述規則の確認まではユースケース記述作 成の際と同様に取り組めた。しかし、メンバそれぞれで着眼点が異なるため、エンティティ の抽出の仕方までは統一するに至らなかった。こういったモデルの作成においては、複数あ る作業対象の担当をメンバそれぞれに均一に割り振るのではなく、主となってモデルの作成 に取り組む責任者を予め決めておき、責任者が行うモデル作成の補佐役、その妥当性を検証 する担当者、などと異なる役割をもったメンバでチームを構成して取り組むのが望ましいと いえる。ロバストネス図作成の過程で発覚したユースケース記述の修正に手がまわらなかっ たが、これについても「誰が」修正を行うのが明確になっていなかったからだといえる。こ こでは明確な役割分担および責任の所在を明らかにすることの重要性を学んだ。 中間発表ポスター制作 中間発表はスライドを用いた発表が主体となるため、当時のポスター制作では人目を惹き つけやすくわかりやすい構成を目指し、図要素を大きく配置した。それにより全体的に簡略 にはなったが、システム概要や活動内容の詳細までを盛り込むことができなかった。活動内 容の魅力を知るには物足りないという指摘を、プロジェクトの背景を知らない人から多くい ただけたため、最終発表のポスター制作では複数枚を用いた構成にし、より詳細まで記載で きるようにした。中間発表はスライドを用いた発表が主体となるため、当時のポスター制作 では人目を惹きつけやすくわかりやすい構成を目指し、図要素を大きく配置した。それによ り全体的に簡略にはなったが、システム概要や活動内容の詳細までを盛り込むことができな かった。活動内容の魅力を知るには物足りないという指摘をプロジェクトの背景を知らない 人から多くいただけたため、最終発表のポスター制作では複数枚を用いた構成にし、より詳 細まで記載できるようにした。 新体制発足に向けての準備 遅延の認知が遅れ、契約の変更という形で顧客に多大な迷惑をかけてしまったことから具 体的かつ実現可能性のあるスケジュールを立てることの重要性を学んだ。苦悩して検討した Group Report of 2011 SISP - 97 - Group Number 10-A Practical Development of “Usable” System 2011 計画も、絵に描いた餅では意味がない。仮に前期活動の時点で、後期に行う構築期間の見通 しをたてるためにプロトタイプ作成に取り組んでいられたならば、早期から開発範囲の縮小 を検討し得たのではないか。 また、進捗管理やタスク管理も徹底しなければ意味が薄い。管理によって得られた情報か ら課題を見出しアクションプランを立てられないのであれば、管理に要する作業は無駄コス トでしかなくなるからである。遅延の認知が遅れ、契約の変更という形で顧客に多大な迷惑 をかけてしまったことから具体的かつ実現可能性のあるスケジュールを立てることの重要性 を学んだ。苦悩して検討した計画も、絵に描いた餅では意味がない。仮に前期活動の時点 で、後期に行う構築期間の見通しをたてるためにプロトタイプ作成に取り組んでいられたな らば、早期から開発範囲の縮小を検討し得たのではないか。 また、進捗管理やタスク管理も徹底しなければ意味が薄い。管理によって得られた情報から 課題を見出しアクションプランを立てられないのであれば、管理に要する作業は無駄なコス トでしかなくなるからである。 ユーザインタフェース設計 • 画面遷移の再検討 画面遷移を検討する際には、チーム内で具体的なイメージを共有することが必須であ る。時折議論が込み合ってしまい、言葉の投げかけ合いだけになってしまうこともあっ た。ホワイトボードや紙などを用いて議論を行うのが望ましい。画面遷移を検討する際 には、チーム内で具体的なイメージを共有することが必須である。時折議論が込み合っ てしまい言葉のみでやり取りを交わしてしまうことがあったが、そういった場合には論 じる対象や認識がずれやすい。ホワイトボードや紙などを用いて議論を行うのが望ま しい。 • 画面レイアウト 画面レイアウトを検討し、イメージを作成することにより、改めて機能面の仕様確認 を行えたともいえる。5.2.8 節にて、これにより要件の漏れが浮き彫りになったとした が、裏を返せば画面イメージの作成により要件の漏れが可視化できることもあるという ことである。したがって、要件定義の段階で画面イメージを用いるのも効率的であると 考えられる。ただし、画面イメージを用いて顧客の要望を聞き始めると、機能実装にお いて重要な要件のほかにユーザインタフェースやデザインに関する要求まで浮き出てく る可能性がある。顧客にその傾向が見られる場合は単にレイアウトを示すだけの簡素な ものを用いると議論が捗ると考えられる。 • 画面項目の定義 画面項目の定義においては制御系の振る舞い、物理データの所在について内部設計お よびデータベースの担当者との打ち合わせが頻繁に行われた。ここでは改めて、ユーザ インタフェースが外部の表層だけに関与するものではないことを認識させられた。ま た、これは通年の活動を通して得た学びでもあるが、画面項目の定義においてもトレー サビリティが重要となってくる。画面項目それぞれについての情報が漏れなく定義され ているかどうか、画面遷移図や画面イメージ、その他成果物と矛盾していないかの確認 が必要となる。画面項目の定義においては制御系の振る舞い、物理データの所在につい て内部設計およびデータベースの担当者との打ち合わせが頻繁に行われた。ここでは改 めて、ユーザインタフェースがシステムの外面だけに関与するものではないことを認識 させられた。また、これは通年のプロジェクト活動を通して言えることであるが、画面 Group Report of 2011 SISP - 98 - Group Number 10-A Practical Development of “Usable” System 2011 項目の定義においてもトレーサビリティを保持することが肝要であった。設計ドキュメ ント間で不整合が生じている場合、その影響範囲は実システムにまで及ぶことがあるか らである。画面項目それぞれについての情報が漏れなく定義されているかどうか、画面 遷移図や画面イメージ、その他成果物と矛盾していないかの確認が必要となる。 最終発表ポスター制作 中間発表ポスター制作での反省を活かしてプロジェクト活動の詳細を多く記載したのはよ いが、いささか文章の比率が大きい。図表にまとめられるところも残っており、今回為して きたことの全てを伝え切れているとはいえない。したがって、改善の余地は十分にあると言 える。中間発表ポスター制作での反省を活かしてプロジェクト活動の詳細を多く記載したの はよいが、いささか文章の比率が大きい。図表にまとめられるところも残っており、今回の PBL において為してきたことを効果的に伝え切れているとはいえない。したがって、改善 の余地は十分にあると言える。 納品 納品前の準備として、画面仕様書と構築されたシステムとの間で整合性をとる作業を行っ た。納品直前に対外発表を控えていたために余裕のないスケジュールとなってしまったが、 設計された仕様が実現されているかどうかの確認はユーザインタフェース設計担当者として 責任をもって事前に執り行わなければならない。なぜなら、仕様との整合性がとれていない 箇所が直前に見つかった場合、それに対応するための余裕期間があるとは限らないからで ある。 （※文責: 江戸太樹） 6.3.9 池田政人 プロジェクトの目標 一つ目の目標である「SE の業務を体験する」については、本プロジェクトが初めての実 践的な取り組みであったこと、ひとつのシステムを構築するためにはたくさんの仕事がある ことが分かり、システムの開発には幅広い知識が求められている事が分かった。 実際に取り組む事で SE の業務を体験するという目標を達成出来た。 二つ目の目標である「顧客の課題や問題点を解決する」については、顧客の課題や問題点 を解決するために必要なデータ項目を抽出し、データベースを設計・構築の途中で度重なる 変更を経てよりよいシステムとなり実際に使うことが出来るようになったこと、機能を実装 することで予約管理を電子化し顧客の課題や問題点を解決するという目標を達成したと考 える。 データ項目の抽出 システム内で利用されるデータの収集・整理を行うために、顧客から受領した RFP と現 在の業務で使用されている帳票を元にデータ項目の洗い出しを行った。 最終的にはデータ項目は 157 個になった。これらを元にデータ項目をどのようにデータベー スで取り扱うか整理をするデータ項目の正規化フェーズへ進むことが十分可能であると考え られ、データ項目を洗い出す目的は達成されたと考える。 森町訪問 公民館に訪問することで現場の業務を知った。実際に施設を見たことで様々な機能のアイ ディアが浮かび、それらの機能を実現するために必要な項目をデータ項目へ追加する事が出 Group Report of 2011 SISP - 99 - Group Number 10-A Practical Development of “Usable” System 2011 来た。 E-R 図・CRUD 図の作成 システムで利用されるデータのまとまりであるエンティティと他のエンティティとの関連 性を定義するために E-R 図を作成した。 設計フェーズにおいて機能一覧等と E-R 図に示されるエンティティとの関係を明らかにす る為に CRUD 図を作成することで双方に過不足がないかを確認することやデータベースに おけるエンティティの分け方を改良することが出来た。 データ項目の正規化 アドバイザのアドバイスや書籍、ウェブサイトを参考に正規化を行った。 施設の予約に関して空き情報、すなわち在庫の持ち方に関してアドバイザのアドバイスを参 考にプロジェクト内で議論を行い様々な方法を検討した。 正規化を行いデータベース定義書を作成し実際にデータベースを構築することは、システム のパフォーマンスを決める重要なフェーズであり後のデータベース設計・構築に役だったと 考える。 データベースの設計・構築 初めて実システムで稼働するデータベースを 1 から設計・構築であった。書籍やウェブ サイト、アドバイザからのアドバイスを参考に行うことが出来た。改善の余地は多々あるも のの実システムのデータベースを構築することが出来たと考える。今回データベースを一貫 して扱ったことでデータベースへの興味が湧いた。今後もデータベースに関する学習を続け データベースに関する資格に挑戦したい。 データベースの知識 個人的な取り組みとしてデータベースを操作する事があったがあまり知識がなかったため に、実システムで稼働するデータベースを扱うにあたっては本学の講義であるデータベース 工学が大いに役立った。例えばテーブルの結合を用いることで無駄のないクエリを書く事が 出来た。実際のデータベースを扱うことで得られた知識や経験は大きいと考える。 実装 大きな機能では在庫生成と施設追加機能、リマインダメール送信機能を実装し、データ ベースの定期バックアップを行うスクリプトを作成した。 在庫生成では膨大なデータをデータベースに格納するようなプログラムを書く上でメモリ の使用量や応答時間を意識した。 施設追加機能では、見やすく間違いにくいページの配置を考えながらビューを作成した。 地図から検索する機能のために施設の住所から緯度経度に変換するモジュールの作成では Google Maps API を用いることで実現した。 リマインダメール送信機能では、メール文等を容易に変更できるように配慮したと共に、 データベースサーバへのクエリを効率的な物とし問い合わせ回数を削減した。 データベースの定期バックアップを行うスクリプトの作成ではシェルスクリプトを用いる ことでシェルスクリプトに関する知識を得る事が出来た。 機能の実装を通して顧客のみな らずエンドユーザにとって使いやすくする為にはどのようにすればよいか、コードをメンテ ナンスする際にわかりやすくするにはどのようにすればよいかを深く考え、コードを書くこ とで成長する事が出来た。 今までのプログラミンやウェブデザインの経験と知識を活かす 事で進捗の遅れを取り戻す手助けになったこと、他メンバのサポートが出来たことからプロ ジェクトに貢献できたと考える。 Group Report of 2011 SISP - 100 - Group Number 10-A Practical Development of “Usable” System 2011 実装した機能は少ないものの、モデル・ビュー・コントローラ全てを書いた事により cakePHP での開発経験を得ることが出来た。 ドキュメント作成 データ項目一覧、コード定義書、テーブル定義書を作成した。 ドキュメントは他者に読まれるものであり、作成・更新したものに相違はないかの確認はも ちろん、表記方法の改善を行うことでどのようにすれば読みやすくなるかを深く考え実行す ることが出来た。 納品 顧客の環境で動作するように調整したデータベースを作成するクエリを作成し、実際に データベースを構築する事が出来た。 リマインダメールを送信するスクリプト、データ ベースの定期バックアップを行うスクリプトを設定し顧客のサーバで動作する事を確認し た。 実際に顧客に納品することでシステム開発の一区切りを体験する事が出来た。 顧客サポート 必ずしも顧客の担当者は自分たちのように専門的な知識があることはほとんどない。自分 たちが作成したマニュアルを含めたドキュメントでは理解されなかった点、記載されていな い点のサポートを相手の立場で分かりやすく説明することの難しさと問題が解決した時の達 成感を共有出来た事、感謝された事が大きな経験になった。 （※文責: 池田政人） Group Report of 2011 SISP - 101 - Group Number 10-A Practical Development of “Usable” System 2011 第 7 章 今後の課題と展望 本プロジェクトでは前後期を通してシステム開発の全工程を経験した。 提案した機能を削減したもののシステムを開発する過程でシステムエンジニアの仕事を体験する 事が出来た。 本章では本プロジェクトと開発したシステムの今後の課題と展望を述べる。 7.1 課題 削減した機能の実装 開発したシステムはスケジュールの遅延により提案したが削減された機能が多く、今後は これらの機能を実現できればと考える。 コードの改修 現在はモデル・ビュー・コントローラ、スタイルシート、JavaScript を含めて本プロジェ クトのメンバがコーディングしたファイルに関してはコメントアウト等を除き約 12,000 行 ある。 しかしながら同じ機能を複数ヶ所で実装するなどの無駄が多くこれらを解消することで可読 性を向上しメンテナンスしやすくする必要があると考える。 ドキュメントの見直し 本プロジェクトでの活動を通して身につけた知識・経験を元にドキュメントを見直し、よ り良いドキュメントとする必要があると考える。 （※文責: 池田政人） 7.2 展望 開発の継続 本プロジェクトの一部メンバが所属する本学の高度 ICT コースでの取り組みの 1 つとし て、課題に挙げた削減した機能の実装・コードの改修を行いデザインの調整を含めてシステ ム全体の改良などを目標にシステムの開発を継続する計画がある。 システムの汎用化 実際のシステム開発において、特定の顧客にシステムを開発したノウハウを活用してシス テムを汎用化し特定の業務向けのパッケージとして販売する事例が多々あることから 本 プロジェクトが開発したシステムは顧客である北海道森町の施設に特化しているが、本シス テムをベースに汎用化し他自治体でも利用可能な汎用公共施設予約システムとして公開出来 ればと考える。 一般利用者への開放 現在、納品したシステムは顧客である北海道森町のイントラネットを通じて稼動しテスト を行った後、予約管理システムの対象施設において担当職員が利用者から受け付けた施設利 用予約を管理するためのシステムとして稼動することになっている。 Group Report of 2011 SISP - 102 - Group Number 10-A Practical Development of “Usable” System 2011 将来的に一般利用者に施設予約システムを提供しインターネットを通じて施設予約を可能 にする予定である。一般利用者への開放に際してはレンタルサーバを利用するとのことであ り、レンタルサーバの環境に合わせるためにデータベースなどのシステム全体の設定・最適 化を含めた移行サポートを行うことを考えている。 （※文責: 池田政人） Group Report of 2011 SISP - 103 - Group Number 10-A Practical Development of “Usable” System 2011 第 8 章 謝辞 本大学の教授 大場 みち子先生, 講師 伊藤 恵先生には指導教員として本 PBL の機会を与えて頂 き、終始ご指導を頂いた。ここに深謝の意を表する。 北海道森町様には本 PBL の顧客としてご協力を頂き、森町への訪問とヒアリングの機会を頂き システムを利用して頂いた。ここに深謝の意を表する。 日本アイ・ビー・エム株式会社 高森 満様, 瀧場 英彦様, 木下 実様にはアドバイザとしてご協力 を頂き、終始ご指導や資料を提供して頂いた。ここに深謝の意を表する。 IPA 独立行政法人情報処理推進機構 鈴木 俊男様, 並びに経済産業省 村上様にはスポンサーとし てご協力を頂き、本 PBL の活動の機会を与えて頂いた。ここに深謝の意を表する。 （※文責: 長坂明輝） Group Report of 2011 SISP - 104 - Group Number 10-A Practical Development of “Usable” System 2011 付録 A 新規習得技術 プロジェクトマネジメント 進捗管理、タスク管理、リスク管理といった管理手法を学んだ。また、それらを怠った際に 陥る事態についても身をもって体感することができた。 UML 要件定義工程、設計工程にて使用。アクティビティ図、ユースケース図、ロバストネス図、 クラス図、シーケンス図を作成。 HTML/CSS システムのビュー構築時に使用。 PHP システムの内部ロジックを記述する際に使用。 フレームワークを用いた実装技術 今回は構築の工数削減のために PHP 向けのフレームワークである CakePHP を用いた。そ こからフレームワークを用いる際に留意すべきことを学んだ。 UNIX サーバ構築 FreeBSD を用いて顧客サーバと同一の仮想環境を構築するために習得。 Group Report of 2011 SISP - 105 - Group Number 10-A Practical Development of “Usable” System 2011 付録 B 活用した講義 ソフトウェア設計論 I 要件定義で UML 記述や非機能要件定義の際に参考にした。 情報アーキテクチャ特論 上記に同じ ソフトウェア設計論 II 設計の際に参考にした。 システム管理方法論 FreeBSD によるサーバ構築の際に参考にした。 ヒューマンインターフェース ユーザインタフェース設計の際に、レイアウトや論理項目の用い方の際に参考にした。 データベース工学 データベース設計の参考にした。 情報機器概論 システム概要を検討する際に参考にした。 Group Report of 2011 SISP - 106 - Group Number 10-A Practical Development of “Usable” System 2011 付録 C 相互評価 Group Report of 2011 SISP - 107 - Group Number 10-A Practical Development of “Usable” System 2011 参考文献 [1] IPA. IT 人材市場動向予備調査. http://www.ipa.go.jp/jinzai/itss/activity/activity2.html. 2012/1/15 アクセス [2] 鶴保 征城, 駒谷 昇一. ずっと受けたかったソフトウェアエンジニアリングの授業 1 増補改訂版. 翔泳社. 2011 [3] 鶴保 征城, 駒谷 昇一. ずっと受けたかったソフトウェアエンジニアリングの授業 2 増補改訂版. 翔泳社. 2011 [4] NTT データ ソフトウェア工学推進センタ 編著. 実例で学ぶソフトウェア開発. オーム社, 2008. [5] 株式会社テクノロジックアート 著, 長瀬嘉秀・橋本大輔 監修. 独習 UML 第 4 版. 翔泳社, 2009. [6] 掌田 津耶乃. CakePHP 1.3 による Web アプリケーション開発―オープンソース徹底活用. 秀 和システム. 2010 [7] 速水治夫, 宮崎収兄, 山崎晴明. IT Text データベース. 株式会社オーム社. 2008 [8] 鈴木憲治, 安藤健一, 山田直明, 八木照郎, 山本義之, 河合勝彦. PHP 逆引きレシピ. 株式会社翔 泳社. 2010 [9] 滝下真玄.PHP で作る携帯サイト デベロッパーズガイド. 秀和システム. 2009. [10] 菅野裕, 今田忠博, 近藤正裕 (株式会社豆蔵), 杉本琢磨 (株式会社イージフ). Trac 入門. 技術評 論社.2008 [11] デージーネット. はじめての CentOS6 Linux サーバ構築編 秀和システム. 2011 Group Report of 2011 SISP - 108 - Group Number 10-A