Transcript 最終発表会資料 - CreW Lectures

2007年2月23日 最終報告会
2007年2月23日
C re W
C re a tiv e W o rk s p a c e
目次
I.
II.
III.
IV.
プロジェクト説明
成果物発表（デモ）
進捗発表
総括
プロジェクト説明
担当者： 松田航
プロジェクト説明
 目次
クライアント紹介
プロジェクト背景
プロジェクト体制
成果物説明
クライアント紹介
 クライアント
慶応義塾大学
デジタルメディアコンテンツ統合研究機構（DMC）
「DMCシステム構築プロジェクト」リーダー
嶋津 恵子 様
＊DMCシステムとは
慶應義塾大学が所有するコンテンツを登録・検索ができるシステム
プロジェクト背景
 DMCシステム機能拡張
 DMCの持っているコンテンツを自然言語解析で地名を取
り出して、その地名からコンテンツをMap上に配置する機
能
 DMCシステム新機能拡張への弊害
 GeocodingAPIはアクセス制限がある
 コンテンツをMap上に配置する毎にアクセスしなければな
らない
プロジェクト体制
 g-modプロジェクト
 g-modプロジェクトへの依頼
 一度取得した情報はDBに格納し、そのDBに問い合わせる
ようにしてほしい
 同名異地点の取得を工夫して欲しい
目的
 地名から緯度経度情報を返すシステムを構築する
作成したもの
 GeocodingModule
プロジェクト体制
慶應義塾大学
デジタルメディア・コンテンンツ研究機構チーム
DMC
齋藤様
慶應義塾大学
大岩研究会 g-modプロジェクトチーム
S E
佐藤 俊之
DMC
嶋津様
DMC
遠峰様
・・・
P M
谷田部 学
S E
平澤 秀幸
S E
松田 航
成果物説明
 GeocodingModuleの基本機能
緯度経度情報を文字列で返してくれる
一度取得した緯度経度情報をDBに格納される
一度検索された地名は何日か経つと更新される
 同名異地点に対する処理
複数地名がある場合は複数取得する
取得する数は設定できるようになっている
成果物説明
地理情報
キャッシュテーブル
緯度経度情報を取得する
データ読み込み
データ書き込み
緯度経度情報を追加/更新
設定ファイル
設定を読み込む
Geocoding
Module
成果物説明
DMCシステム
統合UI
Map型UI
検索
モジュール
コンテンツ登録
モジュール
Geocoding
Module
既存の緯度経度情報算出サービス
成果物説明
 GeocodingModuleの利点
一度地理情報を取得していれば検索が早い
 一度取得した情報はDBに格納されるので、制限を受けるこ
とがない
大量に緯度経度情報を取得したい時に便利
同名異地点
 候補の緯度経度情報を再検索することなく複数返してくれる
緯度経度情報が文字で返ってくる
 XMLの知識を持たない人にも使用することが出来る
特徴
 Geocoding APIと比べて・・・
単純に速度で勝る
同名異地点がある場合、緯度経度取得が楽
大量に緯度経度情報を取得したい時に便利
上記のことを踏まえ、応用例を考えてみました
応用例
 新聞配達で、契約している人達の住所を一括で
地図に表示し、どの方面に固まっているかを調
べる
プロジェクト経緯
担当者： 平澤秀幸
プロジェクト経緯
10月
11月
12月
1月
要件定義
設計
実装・テスト
リリース
要件定義
10月
11月
12月
1月
要件定義
 活動内容
クライアントから渡された要求定義書と機能仕様書を
熟読
プロジェクト提案書の作成
要件定義
 問題点
「簡単に作れる」という落とし穴
 根拠も無い安心感を抱いた
クライアントとの意思共有を怠ってしまった
プロジェクト目的と目標を見失っていた
 結果
ずっと用件定義を行っていた
設計
10月
11月
12月
1月
設計
 活動内容
実現性調査
 技術調査 （GeocodingAPIの使用法、JDBC、XML、ソケッ
ト通信）
機能とデータベースの設計
テスト項目の設計
実装・テスト
10月
11月
12月
1月
実装・テスト
 活動内容
プログラムの実装
単体・結合テスト
 JUnitを用いてテストプログラムを作成
実装・テスト
 実装環境
 使用言語： JDK 1.5.10
 実装環境： Eclipse 3.2.1
 データベース： MySQL 5.0.24
 問題点
 プログラム設計に不備
 テスト項目が足りない/不適切
 技術的なトラブル
 結果
 大規模なリファクタリング作業を行う必要があった
リリース
10月
11月
12月
1月
リリース
 活動内容
本番環境構築
提出ドキュメントの作成
検収用に提出
リリース
 問題点
本番環境構築に手間取ってしまった
 「簡単にできる」と思ってしまった
一度提出した後、バグが発見された
 提出後にソースコードをいじってしまった
 結果
何度も納品日を延長してしまった
学習成果
担当者：佐藤俊之
主な学習成果
 全体
目的・目標の設定の重要さ
ネゴシエーションの仕方
 技術面
ネットワークアプリケーションの作り方
テストファースト手法
DBの設計
UNIX環境における環境整備の仕方
目的・目標
 目的・目標の設定
発表において「何をしているのか分からない」という言
葉を多く頂いた
プロジェクト提案書が通らなかったとき、何をすればい
いのかわからなくなった
目的・目標
 反省点
目的・目標を決めずにプロジェクトを開始してしまった
 自分たちがどういうプロジェクトで、何のために活動をするの
かを考えていなかった
 発表でも「何をお願いされたのか」ということばかり説明して
おり、プロジェクトの説明をしなかった
目的・目標
 目的・目標設定
DMCプロジェクトの一部ではない
 つまりDMCに言われたものをつくるプロジェクトではない
DMCに使って貰えるものを作るプロジェクト
 どのようにすれば貢献することができるか
 どのようにすれば使って貰えるのか
 ということを考えるプロジェクトである
品質の高いものを作ることを目標とする
目的・目標
 目的・目標設定の効果
自分たちが何をすべきなのか明確になった
 ただ作るだけではないということで、モチベーションも高まっ
た
発表で「わからない」と言われることが減った
クライアントに提案をすることができた
 設定ファイルの項目
 DBのテーブルレイアウト
 キャッシュクリア期間
ネゴシエイション
 序盤、クライアントとの話し合いがうまく行かず、
時間の浪費をしてしまった
書類を持っていき、レビューをされてまた次週持って
行く、の繰り返し
嶋津先生から「不安である」という言葉を貰った
 プロジェクトの経過が見えない
 「本当にやってくれるのか」
ネゴシエイション
 ミーティングの準備に原因があるのではないか
何のためにミーティングを行うのかを決めていなかっ
た
 こういうことを聞かなきゃいけないよね、という感じで漠然とし
たことしか考えていなかった
何を決める必要があるのかを考える必要があった
同時に、こちらの意図を相手に伝えることが必要
ネゴシエイション
 ミーティング前に決めること
特にこの3点が特に大事
 なぜミーティングをするのか（Why）
 何を決める必要があるのか（What）
 いつまでにお願いするのか（When）
ネゴシエイション
 なぜミーティングをするのか（Why）
 本当にミーティングの必要があるのか
 メールや電話で済む用事ではないか
 全員で集まる必要があることなのか
 お互いの都合を合わせるのは大変
 「話し合い」が必要になりそうなら、集まったほうがいい
 なぜミーティングするのかが決まったら、それを相手に伝える
 「ミーティングをしたい」だけでは不十分！
ネゴシエイション
 何を決める必要があるのか（What）
 話し合う内容について、どこまで決める必要があるかを考える
 例1・書類を見せ、ボツを貰った場合
 持って帰って検討しなおすのでいいのか
 どこを直せば許可を貰えるのかを話し合う必要があるのか
 序盤はただ持って帰って何がいけなかったのかをチーム内で検討して
いた
 例2・お願いが却下されたとき
 素直にそのまま従えばいいのか
 どうすればOKが貰えるのか、交渉をする
 序盤はただ「そうですか、わかりました」だけであった
 話し合いになっていなかった
ネゴシエイション
 いつまでにお願いするのか（When）
このプロジェクトで最後まで徹底できなかった部分
 明確なデッドラインを決める必要があった
 危険な回答
 「週末」
 「出来次第」
 すぐにでも
 何日の何時まで、というのを毎回決めなければならない
 最後までできなかったので反省しなければならない
プロジェクト分析
担当； 谷田部
スケジュール
工数
No.
工程
見積工数（h）
工数差分
（実績-見積）
実績工数（h）
1 要件定義
40
124.5
84.5
2 実現性調査
20
45
25
3 詳細設計
40
103
63
4 テスト設計
40
52
12
5 実現性調査２
20
13
-7
144
107.5
-36.5
7 単体テスト
16
57
41
8 結合テスト
24
21
-3
9 ドキュメント作成
40
7
-33
10 本番環境リリース
16
15
-1
合計（人時）
400
545
145
合計（人日）
50
68
18
6 実装
スケジュールと工数
※（）内は工数差分,単位は時間
 要件定義（８４．５）
 合意の遅延
 クライアントとのコミュニケーション不足
 成功報酬の検討時間
 プロジェクトとしての目的、目標の勘違い
 実現性調査１ （２５ ）， 実現性調査２（－７）
 要件定義の遅延から追加したタスク
 気にした時間（１８h）を工数として換算した為
 工数集計時に「気にした時間」の定義があいまいだった為
 詳細設計（６３）
 実装方法の調査時間
 Servlet化の検討
 修正
 複数クライアント接続への対応方法検討
 DB設計の修正
スケジュールと工数
※（）内は工数差分,単位は時間
 テスト設計（１２）
 詳細設計の変更による影響
 実装（－３６．５）
 実現性調査の効果
 単体テスト（４１）、結合（－３）
 単体テスト：ソースレビューにより設計レベルの変更
 ドキュメント作成（－３３）
 クライアントが技術者
 当初想定よりも簡素化できた
 本番環境リリース（－１）
 リスク考慮
 環境による違いを考慮していたため大きな差異がなかった
ステップ数と実装工数
No.
ファイル名
Type
1
geocode/APIManager.java
Java
196
29
101
326
2
geocode/GeoDataManager.java
Java
77
11
38
126
3
geocode/RequestProcessor.java
Java
41
11
21
73
4
geocode/DBManager.java
Java
319
33
105
457
5
geocode/GeoData.java
Java
34
15
21
70
6
geocode/Geocoder.java
Java
57
14
47
118
7
log/SystemLogger.java
Java
23
22
6
51
8
log/LogWriter.java
Java
90
26
93
209
9
log/AccessLogger.java
Java
11
11
6
28
10
main/GeocodingModule.java
Java
78
16
32
126
11
setting/GeocodeSettings.java
Java
179
50
82
311
1105
238
552
1895
合計
実行
空行
コメント
合計
ステップ数と実装工数（FP）
ステップ数と実装工数（FP）
ステップ数と実装工数（FP）
工数（人月） 1.133
工数（人時） １８１．３
＝1.133×20日/月×８時間/日
LOC １１９０
＝３４FP×３５ LOC/FP
生産性基準
※（LOC/FP）Cobol：100、Java：３５で換算
Cobol：15 の2倍で換算
ステップ数と実装工数（FP）
 実装工数 実績
 実装：107h
(実現性調査1,2：58h)
 LOC 実績
 １１０５ Step
 FP算出結果
 実装：181.3 h
 LOC:1190 Step
 実績・FP比較結果
 工数実績：FP
 107+58 = 165 :181.3
 実績：FP
 1105:1190
ステップ数と実装工数（FP）
実績
実装工数（ｈ）
LOC
107+58=165
107
1,105
実現性調査1,2：58h
FP見積
181.3
1,190
成長点
 佐藤俊之
 リーダーシップを発揮できるようになった。
 平澤秀幸
 目的、目標に対する意識が強くなった。
 サブリーダーとして与えられた指示を・・・
 松田航
 各フェーズでの成果物や成果物の内容を理解した。
 プレゼンテーションが上手くなった。
 谷田部
 プロジェクトを通して「教育」する事を知った。
 プロジェクト進行をイメージする大切さを知った。
 プロジェクト目的、目標が大事である事を知った。
プロジェクト結果
最後に
・・・
質疑応答
ご清聴ありがとう
ございました。