g-mod

名前	役割	所属
谷田部学	PM	株式会社ネクストウェア
佐藤俊之	学生メンバー	環境情報学部4年
平澤秀幸	学生メンバー	環境情報学部3年
松田航	学生メンバー	環境情報学部3年

評価委員からのコメント（中間発表会）

・｢高品質プログラムを開発する｣というのはとても良いことと思います．
・googleが提供するgeocodingAPIに付加する機能は何か？
・規模見積もりは？
・自分たちのスキルレベルを把握して所要時間を把握すること
・コード品質を上げるためにデザインレビュー，インスペクションなども取り入れた方が良いのでは？
ややもすると，御用聞プロジェクトになってしまう危険を感じます．学習目標を明確にする必要があると思います．クライアントの要求を満足させることがプロジェクトの目標であるとは問題ないと思いますので，このあたりの推進にPMのリーダーシップが発揮されることを期待します．
品質バグの少ないプログラミングを作成する？　→日本語がおかしい．具体的にどうやって？　どんな手法？　 PMの役割は？　(⇒形式的すぎる．資料を作ればバグが減るわけではない．)　いわゆる｢マッシュアップ｣の１つ？　メールの返事がない時点で疑問に思わなかったのか？　電話しなかったのか？　⇒コミュニケーション問題(顧客とのコミュニケーション不足で失敗するシステムは多々ある．)
お客様の要求された仕様をきちんと理解しており，既存システムへの追加ということで，品質の高いものを作ろうとする心がけはとてもよい．嶋津先生もおっしゃっていましたが，｢g-mod｣の目標・目的が伝わってこなかったように思えますので，今一度よく考えてみることを提案します．今回はDMCからかなり詳細な詳細が出されていますが，それであっても｢なぜDMCはこの機能が必要なのか？｣をきちんと理解しておくことが重要です．
何のためのプロジェクト(Module開発)であるかの説明があいまいである．機能の説明は解かり易かった．
・どういうシステムができるかは，わかったのですが，そのシステムが何を実現するのかよくわかりませんでした．従って，それが十分なものなのかどうか，優先順位として正しいものなのか等，よくわかりませんでした．
・技術活用内容の説明はよくわかりました．ただ，そういった仕組みにした理由といいましょうか，根拠といいましょうか，妥当性といいましょうか，そういった点について，もう少し話してもらいたかったです．
・レビューポイントが，聞いていてわからなくなってしまったことは事実です．(私の，能力の問題もありますが・・)レビューアーの知見，能力を引き出すための工夫もいるように思います．
・資料更新とコミュニケーションを絡めて，問題解決対策を説明されていましたが，コミュニケーションという，人によってレベルに差のでる抽象的な解決策でとめるのではなく，更新や，連絡といったことについての仕組みを策定し間違いなく行われることにするほうがよいでしょう．
・管理は，完了ベースで管理したほうが効果的です，何事もそうでしょうが，仕掛けたことベースで管理しても，うまく行かないのが一般的と思います．
・プロジェクトでおこっている事は，正しくつかんでいると思いましたが，おこっている事の評価(どの程度のこと)と，それに対し，対策といったアクションプランとの因果関係といいましょうか，繋がりが見えませんでした．
googleMAPの表示は最近の流行のようである．文献検索後その文献が地図上でどこにあるか，一目で分かるからといって，and so what？　といいたくなる．付加価値といえるのかどうか．その文献はどこの図書館にあるのか，借り出せるのか，コピーはとれるのか，といった情報が表示できる方が有用だと思う．
プロジェクトの性質として下請け開発そのものであり，要件定義は｢業務要件｣ではなく｢設計要件｣の定義をしているにすぎません．となると，このプロジェクトでは実装精度以外に追求するものはない，ということになります．この問題は性質的なものですから今更変えられないとなれば，せめて実装精度については徹底的な追求がなされないと，ただ漫然と下請け開発をしました，というだけになってしまいます．
(1)開発形態の明確化
本システムの開発形態は，他プロジェクトとは異なり，DMCより与えられた機能仕様に基づいた部分システム(sub system)の開発である．企業活動で言えば，｢受講｣である．この特徴を主張すべきである．この場合，管理上からは設計変更(機能仕様の変更)に対する対応が大切となる．DMC側どの様な手順によって変更を行うかを規定しておくことが肝要である．

(2)試験方法の明確化
本システムの試験は，1.部分システム(本プロジェクト)に対するもの，および 2.本体(DMCシステム)に組み込んで運用するものの2段階が必要である．2の試験の実施主体はDMCと想像される．｢本番環境リリース｣がこれに相当するのか？　明確化する必要あり．また，この場合，トラブルの発生に対する対象方法を規定しておくとより，トラブルによっては本体に原因があったり，解析を要するものも生じる可能性がある．

(3)保守の明確化
DMC本体に組み込んだ後の保存についての規定を明確化しておく必要がある．

(4)機能に関する感想
これは，本プロジェクトの外側であるが，実現しようとしている機能の効果(使い方)が腑に落ちない．
DMCシステム新機能の分担開発とのこと，品質(性能を含めて)をいかに造り込むかという観点で，計画したプロセスの実施，評価そして課題を明確にして下さい．

評価委員からのコメント（最終発表会）

いろいろあったようですが，地味ではありますが，実用の品質レベルの成果物であり，その点では成功であると思います．
色々と苦労されたが，がんばられたと思います．”顧客からは永遠に要求/要件は出ない”，”だから最初から要件をあてにしない”というプロジェクトの進め方の考え方もあります．次回があるとすれば，そういう観点で行なってみたらいかがでしょう．
要件定義というプロジェクトの根幹に係わるものの重要性を理解したことは，非常に意味がある．顧客とのネゴシエーションは常に問題になる事であり，これからも常に意識する事が必要である．今回の経験はこれからの活動に有効だと思われる．問題点の解決方法については，もう少し考えないと，本当のプロジェクトでは有効ではないかもしれない．
・用件/要件の混在：発表ドキュメント中
・発表の仕方：good
・プロジェクトとしての経験，適度な失敗もあり，成功するより遥かに大きいものを持っている．そういう意味では，成功プロジェクトといえる．
・目的，目標の明確化とそれによるモチベーションの高まりは大変良い
・プログラム開発についても，充分な知識を得られたようで成功といえる．
・要求仕様書では良い経験を持ったようだ
・5点満点で，4.5点．順位2位．
｢DMCに使ってもらえるもの｣とは具体的には何か？　｢品質の高いソフトウェア｣は具体的にどのような基準で評価するのか？
1．目的・目標顧客のニーズ自分たちの活動の狙い→要件定義に時間を要した
2．報連相（報告，連絡，相談）の不足
3．納期とは上流を経験して，プロジェクトの推進に必要な行動様式を習得できた様です．
要件定義は何故必要かについて，正しく理解しておきましょう．要件定義をした後の工程で，プロジェクトの内容を変更せざるをえない場合も少なくありませんが，このときは変更管理とするのがよいと思います．以上は，コメントです．いろいろありましたが，無事検収が済んでよかったですね．プロジェクトは，成功したといえるでしょう．お疲れ様でした．実運用で使ってもらえるといいですね．
まず，PMとして担当した谷田部氏のコメントに，「本プロジェクトに参加した学生は，すぐに実戦配備できる」との評価があったが，企業において，基礎知識レベルのスキルマップ把握が必要なのではと疑問が残る．コラマネの指針として非シナリオ型による生きた実際の題材があることは重々承知している．また，命令系統（業務命令）無しに，モチベーション持続を行わなければならない特殊性も考慮した場合プロジェクトとしては，プログラムとしては「完成」という目標には達したと思われる．しかしながら，本プロジェクトに参加した学生の基礎知識であるが，ソフトウエア工学の専門学部生と比較した場合，残念ながら保有スキルは不足している．故に，参加した学生のスキルアップ効果がどの程度向上したのか，参加前，参加後に評価することが必要だと考える．これは，本プロジェクト全体を通して感じたことであるが，初期の段階では参加している個々の学生が自分自身のプロジェクトでの役割を把握できていない印象があったが，最終発表の段階ではかなり役割を強く認識していると感じられた．つまり，コラマネでは，具体的なITスキル向上よりも，PMとの人間関係，学友との関係，コミュニケーションに関する重要性を認識できるようになったとすれば，一定の成果は認められる．また，見積りなどの規模予測は，FP法により規模予測を行ってもSLCP等ソフトウエア工学の基礎知識が無ければ，計測の意義が正確に把握できない．本プロジェクトも事前の規模予測を行ったようであるが，予測と完了規模に乖離が認められる場合は完了後のFP値を計測する必要がある．また，参加した学生から企業のPMから何を学んだのかについての回答も，反省点は挙がってもプロジェクト遂行の厳しさはあまり感じられなかった．これは，OSSにも見られることであるが，プロとアマの圧倒的な差は，強烈な生業の責任を背負うことである．プロジェクトは終了したが，やはり，アマチュア域である．
【総合評価】
g-modプロジェクトは，C評価（ユーザテストでよい評価，あと一歩で使える）と評価します．

【詳細な気付き事項】
(1)プレゼン資料に誤字がありました．レビューが不十分ではないかと推測します．
(2) 発表者全員が早口なのが残念でした．プレゼンの範囲を絞る工夫が必要だったと思います．
(3) JUnitを利用したことは高く評価できると思います．
(4) プログラムの構成管理（バージョンアップ管理）ができていなかったと推測します．
(5) FP法の結果と実績との差異がないというのが信じられません．FP法で見積もったどおりのプログラムを完成させることができたプロジェクトだったのでしょうか？　発表を聞いている限りでは，そのようなプロジェクトではなかったのではないかと推測します．
APIのボトルネックを解消しようとするソフトウェアである．ソフトウェアの開発としてはよくできている．発表はコラマネを意識してか，開発ソフトウェア自体に関する部分が少なかった．せっかく顧客とのミーティングにおいて目的，目標，すなわち，何を話すべきか，何を示すべきかが大事と知ったのだから，本プレゼンテーションでも，聞き手の目的，意図をおもんぱかり，プロジェクト・マネジメントに関わる事柄のみならず，開発ソフトウェアに関する説明も行なうべきである．開発ソフトウェア，コラマネとも（真のプロジェクトから見れば，入門段階であるが）きちんとできていることは評価できる．コラボレーション・スキルとしてどのようなことが身についたかも聞きたかった．
・三田という住所について
こういう事例は一般的なシステム開発には山のように発生します．会社名，銀行の支店名，顧客名，通称など，です．解決方法はその業務の内容によって違ってきます．よい機会ですから，考えてみてください．

・一覧表示
新しい店を出店する場所など検討するとき，地図を使ったシステムは大活躍します．コンビニや，ファーストフード店の地図システム利用法など研究するとよいでしょう．

・技術習得と物つくりのノーハウについては多くを学んだように感じました．
・新しい技術が，新しいビジネスの仕組み，新しい商品の機能を実現します．技術力をさらに磨いてください．
GooglemAPを使った健康福祉APIを研究開発している点からも，面白く聞かせていただきました．
日程ぎりぎりで，ユーザ検収いただけたということで，無事プロジェクトが終了して良かったです．今回の５つのプロジェクトの中で，これほど要件が明確になっている案件はないと認識にいたので，要件定義でトラブったというこが不思議でしたが，「moduleスペック」等，詳細な条件がでているだけに，プロジェクトの目標設定が難しかったと認識しました．当初，プロジェクトの目的．目標の明確化が遅れ，要件定義に時間がかかったとのことだが，最終的に定めた目標「高品質」の達成にあたって，工夫した点とその結果の評価・分析結果を知りたいと思いました．（例えば，レビューの実施方法，発見したバグの類似バグの摘出状況は…等）また，後半，目的を明確にした会議の進め方の重要性を認識でき，改善・字xt串できたことは素晴らしかったと思いました．

g-mod

緯度経度取得モジュール『GeocodingModule』の開発

『GeocodingModule』イメージ

プロジェクトの活動概要

中間成果物

最終成果物

メンバー

メンバーの声

ソフトウェアの規模

工数・スケジュール

評価委員からのコメント（中間発表会）

評価委員からのコメント（最終発表会）