プロジェクト報告書（最終）Project Final Report
提出日 (Date) 2012/01/18
使い物になる実践型システム開発 2011
Practical Development of “Usable” System 2011
1009103 浅井 信 Shin Asai
1 背景
1.1
本プロジェクトの背景
現在、大学のカリキュラムにより育成される人材と企
して使い物になるシステム開発を進めていく。
2 課題の設定と到達目標
顧客の現状における問題点を本プロジェクトで開発す
業が求めている人材の間にはギャップが存在している。
るシステムにより改善できること。すなわち、使い物に
企業は、大学に対して文書作成能力や文章力などの基礎
なるシステムとして顧客にシステムを納品することが大
能力、チームワークやリーダーシップなどのコミュニ
きな課題である。その中でも特に上流工程における顧客
ケーション能力やマネジメント能力を持つ人材を求めて
の課題を分析する能力や問題を解決する能力を身につけ
いる。しかし、大学でのカリキュラムによる机上の勉強
られるような活動を行う。その活動によってメンバーそ
だけでは、企業が求めている実践的なスキルを身に付け
れぞれがシステムエンジニアの実務やシステム開発の一
ることは難しい。スキルを身に付けていくために本プロ
連の工程を経験し、それによって就職後にシステム開発
ジェクトは、PBL(Project Based Learning) 形式で活
の即戦力になる能力習得を図ることである。さらに、今
動を進めていった。
回の PBL の活動の中で問題解決をテーマとした、顧客
今回、本プロジェクトはお客様である森町様 (以下、
の課題や問題点を解決することを通じて地域への貢献を
顧客) より提案依頼書 (以下、RFP) を受領して活動を
することである。本プロジェクトの到達目標としては大
行った。顧客の施設予約管理で現在問題となっている点
きく分けて 2 つある。1 つは、現在の紙媒体による予約
をシステム化することにより改善できないかという依頼
管理業務をシステム導入によって効率化を図ることで
である。つまり、本プロジェクトでは本来システムエン
ある。2 つ目は、上記のシステムを構築する過程でプロ
ジニアが経験する工程を RFP 受領後の提案から運用ま
ジェクトメンバがシステムエンジニアの実践経験を積む
での全行程を通してシステムを開発することで実践的な
ことである。その中で、作成していくドキュメントの品
スキルを身に付けていく。また、本プロジェクトメンバ
質の向上やプロジェクトメンバ間でのやり取りを通して
は全員システム開発においては素人同然であるため、日
コミュニケーション能力を身に付けることが本プロジェ
本アイ・ビー・エム株式会社 (以下、アドバイザ) にアド
クトの到達目標である。
バイスやレビューをしていただきながら公共施設予約管
理システムの開発に取り組んだ。
1.2
現状における問題点
3 課題解決のプロセスとその結果
本プロジェクトは顧客より RFP を受領しこれを基に
顧客の町内公共施設利用において利用者が予約すると
開発を行うために、ウォーターフォールモデルに従って
きの手続きに煩雑さがみられる。これが原因で町内在住
活動を行っていった。提案工程、要件定義工程、設計工
の若年層に公共施設を利用できる制度を把握されていな
程、実装工程、テスト工程、納品の順番に開発を進めた。
い可能性が高く、活発な施設利用ができなくなってしま
それぞれの工程で、顧客から承認を得るためにどのよう
うという実態がある。さらに、各施設では予約管理の事
な成果物を作成するかを考え議論しながら決めていき成
務も紙媒体で行われていて利用状況等の統計情報の集計
果物を追って開発工程を進める形をとった。
もその都度手作業で行っているので業務に多大な時間が
提案工程では、RFP を基にして本プロジェクトで開
掛かると考えられる。本プロジェクトは、これらの課題
発していくシステムの内容を提案した。提案するにあた
を解決するために顧客から受領した RFP の内容を基に
り現在使われているサイトを調査して開発するシステム
のイメージをある程度共有していきながら取り組んで
に示す。これにより、気付かなかった点も多く存在した
いった。最終的に提案書を作成し、この提案書をもって
ため As-Is 業務フロー図を修正し、さらに新たに必要に
顧客から承認を得ることができた。しかし、提案書提出
なった要件をまとめていくことになった。
時に必要なこととして、今回開発するシステムの費用の
見積もりと費用対効果についても顧客を納得させるため
の説明をすることが必要であることも学ばせていただい
た。
提案工程で承認いただいた提案書を基にして要件定義
工程への活動へと移った。ここでは、提案したシステム
の機能の詳細についての仕様を固めるために非常に重要
な工程でもあった。この段階で、システムが使い物にな
るかどうかが左右されると言っても過言ではない工程に
図2
森町公民館訪問（2011 年 6 月 22 日）
なる。重要になる理由としては、顧客自身が改善に必要
な部分があるのに気付かない点も多く存在しているから
要件定義では、最終的に要件定義書という要件定義工
である。まずは、現状業務を把握するために As-Is 業務
程で作成した成果物をまとめたものにより顧客から承認
フロー図を作成し、次にシステム導入後の業務の流れを
をいただいて次の工程へと進めていった。
示す To-Be 業務フロー図を作成することで顧客へ確認
設計工程では、実装に入る前に必要な分析に関するド
していただいた。そして、顧客に本プロジェクトで開発
キュメントを作成していった。特に重要となったのは、
するシステムの機能の概要を把握できるようにユース
分析ロバストネス図と分析シーケンス図からそれぞれ作
ケース図を作成してご確認いただいた。非常にシンプル
られた詳細クラス図と詳細シーケンス図である。本プロ
で理解しやすい図となり顧客へのシステム説明の媒体と
ジェクトの実装はこの 2 つの詳細設計のドキュメントを
して非常に役に立った。具体的にどのようなユースケー
基にしてコーディングを行うための設計を行った。この
ス図を作ったかについては図 1 に示す。
工程では設計担当者を 1 名に任せたままで進めてしまっ
たことで、設計段階で意見の交換があまり行われなかっ
た。せめてもう 1 名くらいを設計担当に回していれば、
よりブラッシュアップされた詳細設計の成果物を仕上げ
ることができたはずである。しかしながら、本プロジェ
クトの担当者が作成した詳細設計は後にも大きな実装の
材料として活躍していった。詳細クラス図について一部
を図 3 に示す。
図1
ユースケース図
以上のような活動を通じても実際の業務を見たわけで
はないので、顧客の業務を確認することが必要であっ
た。そのために、2011 年 6 月 22 日に森町公民館を訪問
し実際に行っている業務の確認をした。その様子を図 2
図 3 詳細クラス図（一部）
このドキュメントを用いて共通となるロジックを使い
承認していただいて取り組んでいくことにした。実装に
まわすことが可能になるなどの工夫がされていて貴重な
どれだけの時間を費やすかを計り、これを基に実現でき
成果物となっていった。担当者 1 名で作成していったた
るスケジュールを立てていった。また、各納品の場面で
めにすべての設計を行うことができなかったので、本プ
今後のことについて相談させていただく機会もいただ
ロジェクトで実装する優先度の高い順である予約の機能
き、テストを行った機能をその結果と共に納品しいく形
についての設計から行うことにした。
をとった。
さらにここでは、実装に利用するためにデータモデル
これ以上の遅れを出さないためにもこの時点からは
の準備も行い、実装工程を始めるための下準備が行われ
WBS による進捗管理を行うようにした。これによって
ていた。顧客から進行については一任されていたため、
遅れているタスクがすぐに全員で確認でき、作業の全体
設計工程がある程度完了したことを確認した後に、実装
感についても把握できる。未着手のものや完了した作業
工程へ切り替えていった。
についても記録として残せるため非常に便利な進捗管理
本プロジェクトの活動の一環で、設計工程の途中に中
間発表会を行う形となった。この時点では、動くシステ
の方法として利用できていた。実際に使用していた進捗
管理表の一部については図 4 に示す。
ム部分はなくドキュメントとして成果物がある状態だっ
たので、発表の仕方に工夫が必要であったが、うまく発
表することができなかった。その原因として、対象が学
生であったのにも関わらず専門用語を多用していたため
に内容が難しいというアンケートの結果が多かった。し
かし、それだけやっている内容については認められてい
た集計結果となっていた。また、利用者の意見を聞くな
どの機会は設けようとしているかなどの質問が多く、今
回本プロジェクトは顧客からの依頼でシステム開発を
行っているので、まずは顧客に満足していただくことが
優先であり、利用者についてはその次のステップである
ことを伝えることを発表内で説明できていなかった。最
後にある成果発表会では上手く説明できるように反省を
行うことで気を付けるべき点を整理した。
前半の活動の最後には顧客を本学へ招いてのデザイン
レビューも行われた。ここでは、本プロジェクトが考え
ているイメージを HTML で作成したものでご確認いた
だく機会とした。少々遠方であるために直接会って意見
を聞く機会を有意義に使うためにも貴重な時間であっ
た。
後半の活動の大半は、実装工程とテスト工程が主に行
われた。実装に入る前に大きな体制変更やリスケジュー
ルを行う必要性があり、大きな計画変更をすることに
なった。この時点で、当初の納品予定日に間に合わせる
ことは不可能であるとアドバイザに指摘され、どう対応
すれば納品していけるかについての方法についてもいく
つかの案をいただいた。本プロジェクトとしては、3 回
に分け段階的に納品させていただくという案を顧客から
図4
進捗管理表（一部）
進捗管理表の使い方に関しては、会議のある時間まで
に定量評価によって各担当者に記述してもらうことで進
捗管理を行った。色の付けた部分に関しては遅れている
タスクを示しており、開始予定日と開始実績日などの項
目を得ることで予定通りに活動できているタスクなども
確認できるようにした。フィルターをかけることによっ
て現在把握したい状況を知るために非常に便利なドキュ
メントとして機能していた。
テスト工程については、テスト開始時は同じサーバ内
でディレクトリを変えてテストを行っていた。しかし、
顧客との話し合いが進むにつれて使用サーバの変更など
があり、これに伴い新しくサーバを用意して取り組む状
況となったのでテスト環境と実装環境を分ける形へシフ
トすることになった。これによって、システムを導入し
た後と同様の環境でテストすることが可能になったの
で、環境によるバグの発生は抑えられた。また、テスト
工程で重要であったのはテスト後の修正の管理が少々煩
雑であったために誰がいつまでにそのエラーを直すかを
アクションプランを立てて取り組むことができなかっ
た。浮いたままのタスクとなってしまい、しばらくその
プロジェクト立ち上げた時点から行うことが必要であっ
ままの状態で残されることもあったので対策が必要で
た。タスクの遅れの原因についての対処方法やバック
あった。
アップ体制についても考えておくことが重要である。し
納品については、事前に顧客へ当日のアジェンダなど
かし、遅れながらもあきらめずに最後まで活動を行うこ
1 週間前には予定を組みリマインダメールを送るなどし
とで、着実にプロジェクト開始当初と比べると身に付け
て、当日の進行をスムーズに行うために必要なことは何
るべき能力をそれぞれ得ていることが各成果物を通して
かを考えながら取り組んだ。また、3 段階に分けての納
も確認できた。
品であるため今後の予定を話し合う準備も行った。さら
5 今後の課題
に、納品に関して RFP より指定された納入物はもちろ
んのこと、本プロジェクトが必要であると判断した納入
顧客が指定してきた納期を約束通りに守ることが可能
物についても整理し納入物とした。本プロジェクトは
であるかを早い段階で判断し、顧客とコミットメントす
ずっと活動を続けるわけではないので、運用・保守につ
る前に相談して決め守ることができる納期を設定する必
いてある程度カバーしていただけるように必要なものと
要があった。そのためにも、今回のプロジェクト活動で
して、システム仕様書や画面仕様書、データベース仕様
の体験は 1 つの尺度とし、今後の活動ではコミットメ
書を納品した。
ントには十分な根拠を持って取り付けることが必要であ
成果発表会で本プロジェクトで開発したシステムや作
る。私達が努力してどうにかするということだけではど
成したドキュメントを公開した。中間発表を受け、専門
うすることもできないので、初めてのことに対しては時
用語をなるべく少なくし理解しやすいような発表資料作
間をいただき工数を見積もり顧客と相談していくことが
りを心掛けた。しかし、成果発表会のときにスライドの
重要である。
完成が発表当日まで修正をしていたために、まともにリ
また、今回の活動では実運用の保守まで関わることが
ハーサルもできないまま本番を迎えてしまう形になって
できなかった。この点については今後の課題として残っ
しまった。その中でも、各メンバが一年間やってきたこ
てしまうと考えられる。他にも、顧客の要求に対してま
とを全体の本筋を外さずに自分の言葉で発表できていた
だまだ対応し切れていない点もあるので、活動を続ける
ので結果としては十分であった。さらには、中間発表会
のであれば徐々に吸収していくことも考えていかなけれ
に多く出ていた質問もなくなり評価のコメントについて
ばならない。
も中間発表会と比べると気を付けるべき点はしっかり抑
参考文献
えられていたので、発表の内容自体も中間発表会よりは
良い結果になった。
つ る ほ せいしろ
こ ま や しょういち
[1] 鶴保 征城 , 駒谷 昇 一 . ずっと受けたかったソフト
ウェアエンジニアリングの授業 1 増補改訂版. 翔泳
社, 2011.
4 結果の評価
本プロジェクトが到達目標としておいていたシステム
導入による業務の効率化については実運用まで進める
ことができなかったため、確認できないままとなってし
まった。一方、プロジェクトメンバ全員がシステムエン
つ る ほ せいしろ
こ ま や しょういち
[2] 鶴保 征城 , 駒谷 昇 一 . ずっと受けたかったソフト
ウェアエンジニアリングの授業 2 増補改訂版. 翔泳
社, 2011.
[3] NTT データ ソフトウェア工学推進センタ 編著. 実
例で学ぶソフトウェア開発. オーム社, 2008.
しょうだ つ や の
ジニアとしての実践的な経験を得たことは間違いないこ
[4] 掌田津耶乃. CakePHP 1.3 による Web アプリケー
とである。結果を見る限りでは、当初の目標通りに進め
ション開発―オープンソース徹底活用. 秀和システ
ることができないことは悔やまれた。顧客とコミットメ
ム. 2010.
ントしたことについてはどんなことがあっても守られて
当然である。今回の失敗を学びとして次回に活かすため
にも、時間の見積もりやスケジュール、進捗確認などを