評価委員による中間評価

目次
コラマネ全体の評価

コラマネ全体に対する評価>

コラマネ全体に対する評価
  • メンバーとして参加経験からですが,非常にいろいろなことが学べて有用であると思います.(評価:5)
  • 普通を期待する.(評価:5)
  • プロジェクト実践を通じて,一つ一つの知識が命を得る効果があると思います.(評価:5)
  • いよいよ成果が見えてきたと実感できました.方法論は正しいとおもいます.やはり,シラバスとカリキュラムという観点を入れる必要を感じました.(評価:4)
  • 明日のIT業界の活性化,価値創造への人材育成の場として,有効性を改善していけると良いと思います。(評価:4)
  • 「目新しさ」「とにかくやってみる」というフェーズから,「効果の特定」「Good(評価:3)

学生に対する教育という視点からの評価>

学生に対する教育という視点からの評価
  • 学生が実務に近い経験をすることは,成功・不成功(プロジェクトの)にかかわらず大きな効果があると思います.ただし,学習目標を明確にする必要があると思います. (評価:5)
  • 上記,全体に対する評価と同じ.(評価:5)
  • いいテーマに出あえるかどうかによるところはお大きいと思いますが,社会人との共同作業は授業からは得られないものを習得できると思う.(評価:4)
  • PBLとして有効である.(評価:4)
  • この3期を通じて,学生の能力が伸びてきているのは如実に見て取れます.ただ,学生個々人としてはそれぞれに「良い経験」をしたのでしょうが,このプロジェクト全体で統計的有意さをもって「何が得られたか」を振り返るべきであるように思います.(評価:4)
  • 特に要求分析について,貴重な実践教育の場となると認識した。(評価:4)

PMに対する教育という視点からの評価

PMに対する教育という視点からの評価
  • どんな小さくても,企業のプロジェクトで起こるような課題・問題もでてきて,それを解決していくということを体験でき,とても成長できると思います.(評価:5)
  • 技術を使うことと,技術を持っている人を使うこととは全く違う能力です.(評価:5)
  • PMに個人差があるが,効果はあると思う.(評価:4)
  • 特に週一ミーティング等の制限から,コミュニケーションマネージメントの工夫。(評価:4)
  • 良い面と悪い面の2通りがあるので,3としました.PMに対する予備知識がないために2通に分かれています.つまり,リーダシップを発揮する人と仲良クラブに入ってしまう人で後者の教育効果には疑問があり,事前のオリエンテーションが必要と思います.(評価:3)

自由記述欄

  • ・PMミーティングの(概要でよいので)議事録を拝見させて頂きたい。・学生,PM自身の教育の有効性から,やはりPMはサブリーダあるいはリーダ経験がある元気な若手技術社が望ましい
各プロジェクトの評価
学生に対するコメント

準JUN

  • 三期以上参加している学生が中心になっているので,チームワークが良い. 評価委員等で始めて参加している人もいるので,ソフトウェアの説明にもう少し時間を取った方が良かった.
  • 提案書のP6?P13はクライアントとの面談で使ったものですか.そうならば,すばらしい.
  • プロジェクトコメントにも書きましたが,大切なことは理由,根拠です.どうしてこうなったのかの説明力が,品質を上げる鍵です.こういう理由でこうなりました,ということでこれからこういう選択をします.といった類のことではありますが,システム開発の管理には有効です.
  • 依頼者(client)の必要性(needs)を十分に理解して用件(repuirements)として確立させるには依頼者側の世界における業務知識(domainknowledge)が不可欠である.この場合,語学の教育であり,さらには中国語まで含まれる.この点を十分に配慮することが,実際に使われるシステムの開発につながる.
  • 要件定義をつめるプロセスをきちんと,計算し,実施している/いこうとしていることは素晴らしいと思った. プロジェクト終了時,その成果を是非評価・分析して最終報告会で発表していただきたい.

g-mod

  • チームワークは大変良いと思いますが,少し仲良しクラブになっていると思います.学習目標を明確にするともうすこしプロジェクトのゴールが明確になると思います.
  • 品質のよいものを目指すのであれば,設計のレビューを有職者交えて,しっかりやるといいと思います.
  • クライアントとの間で何故思いの違いがあるったのか分析することが必要です.
  • 先進的技術志向性の高さに,チャレンジ精神を感じました. しっかり勉強して,21世紀の技術立国の主役になってください.
  • 「余裕」というのは何の根拠をもって「余裕」なのですか? そういう気がする,ということでしょうか?
  • 機能仕様から見ると,実現は容易と思われるが,部分システム開発には,本体との係わりが色濃く生じることがあるので,この経験を積んで欲しいと考える.個人で実施するのは容易でも,組織的な活動となると,制約が生まれる点である.
  • DMCシステムの新機能の分担開発であり,開発モジュールの位置付けを理解の上,品質(性能を含めて)造り込み(DMC側との設計,試験項目レビュー等)のプロセス,問題摘出(連動試験,環境構築,実施)のプロセス等,インターフェース上のトラブル防止へのプロセスを明確にして実施してください.

satoimo

  • 自己実現・学習・クライアントニーズと多種の目的を同時に実現しようとしているが難易度が高くなって今期中の実現がむずかしいのでは心配です.最低限クライアントニーズの一部を満足させるという目標はクリアできるように計画をレビューして下さい.
  • 実現の可能性は高い.設計書を残て下さい.
  • 新しい技術が,新しいビジネスを生み出すということは真実です.21世紀はますますその傾向が強くなると思います.従って,道具から何ができるか考え,それが提案にまでなり,うまくニーズを喚起し世の中を変えていくのはすばらしいことですし,エンジニア冥利に尽きます.ただ,やはり,システムは道具であることも忘れずにお願いします.
  • シナリオをアニメーション化したりして,使用シーンが明確に意識されているのはとても良いと思います.
  • システム要件の分析・定義においてはっきりさせておく方がよいものは「与えられる」条件と「規定可能な」条件である.これは区別すると,観念的に「変えられない」と考えていたものが,実は変更できるということによく遭遇する.これは新たな提案や発想につながる.
  • モバイル,地図情報との連携等,技術的にも,大変学べることが多いプロジェクトと認識します. 学習目標とその達成結果についても,是非,最終報告会で発表して下さい.

さうんど おんりぃ2

  • ゲーム開発はゴールが明確になりづらいのでプロジェクトの目標設定は難しいと思います.従って学習目標や成果物の標準基準を明確にする必要があると思います.
  • テーマが明確でない段階では,個々人がプロトタイピングしてみるのは,そこからアイデアがでる可能性もあるのでよいと思う. そればかり続けていもいい物は作れないので,本日提案されたものや,自分達のアイデアをプロジェクトで検討して,ゴールを目指して下さい. 楽しいものができることを期待しています!
  • C++で開発できるようになったのはよかったです.楽しいゲームになることを期待します.音声が明瞭になると良いと思います.
  • 研究成果よりも,課題の面白さに気をとられてしまいました.ということもあり,プロジェクト自体の進め方等について,目がいかなくなりごめんなさい.
  • 人間の脳の不思議なところは,音の位相差を自動的に3次元位置情報にマッピングできる ことです.「サウンド」ではなくて「サラウンド」デバイスをを使うということは,脳に直接3次元情報をインプットすることができるということです. 実際には何も動いていないのに,そこに「何か」が存在し,動いている,ということを脳に伝えることができるデバイスなのです. また,ゲームの醍醐味は,単に対話的であることではなくて,自分の決定や行動の結果が,ゲーム内の世界に影響を与えることができる点です.ただプレイヤーの行動だけを評価して採点するゲームは,究極的に身体能力測定と同じです.行動によって状況のものが変化していき,変化した状況に合わせた行動がさらに求められていくことこそがゲームの面白さだと,私は思っています.
  • 音のみの世界としてラジオ放送がある.音声や音楽でない音によってある意図する情景を生み出す素組があり,好評とのことである.この様な方向を検討してはどうか? 音のみの「ゲーム」の実現⇔期間,技術,着想の点において成功は難しい.
  • 自由な発想で,楽しく開発を進めていただきたいです.

4hands

  • クライアントの要求が明確なときほど,技術者は注意が必要だと思います.予約されていない状態と予約されている状態の中間の状態が存在する以上,論理的自己むじゅんをおこすことに気がつかなければなりません.
  • 提案書にはチームメンバー名を入れよう! 実現可能性が高いと感じました.実装を期待しています.
  • 作って使い始めてから起こることについて,徹底的に考え,洗い出し,開発要件に加えてください.もちろん,全部システムに作りこめばよいというものではないのですが,人手に振る場合は,システムとの連携をうまく設計しないといけません.決めておかなかったことで,突然の対応が発生した場合,人間は決めていなかったことについてすぐに対応できますが,システムにするとうまく行きません.人間は決めた通りにもできるし,決めていなかったことにも,その時点で決めて動けるのです.機械はそういうわけにはいきません.システムは完成したとたんに,条件と制約の塊になるということを忘れないでください.
  • 今回のクライアントは,お客さん自身が現状の問題点と,その対処法をわりとはっきりとイメージしておられるようです.しかし,お客さんがイメージしているものをそのとおりに作って,良い結果になるとは限りません.自分が医者に行って,熱があると言えば解熱剤を,洟が出ると言えば鼻炎薬を処方してくれるお医者さんは信用できますか? 「斬新な発想」は必ずしもいらないのですが,仕事を請けるからにはプロとして,そのやり方でうまくいくかどうか,他にもっと良いやり方がないかどうかをよく検証することを意識してください.
  • 本システムの開発を種にして,会議予約,診療予約,電子カルテなどのシステムを理解すると本経験が生かされよう.
  • 現在,困っている問題をシステム化することで,解決するというプロジェクトであり,是非,喜んでもらえるシステムを開発し,達成感を味わって欲しい. システム化のスムーズな移行へ,ユーザ向けの操作ガイド作成上の工夫点等も,最終報告会で発表いただきたい.
PMに対するコメント

準JUN

  • ソフトウェア開発プロセスを推進するための知識と経験が不足していると思われる.アドバイザのかたの助言が必要と思います.
  • 概念設計は理解できました.実装が心配です. 指導をがんばって下さい.
  • 本システムの開発型は,滝型(waterfall model)というより,螺旋型の1段階を滝型で開発(改版)すると考えた方が適切である.学生にもこの点を強調する必要あり,何故なら,今回の開発後に更に改版される可能性が強いからである.
  • ここでは,「PMの工数が最大で,予 完結しても超過」ということだが,プロジェクトの立ち上げが終了した今後は,是時各メンバが各学習目標の達成,プロジェクトの成果へ向けて,充分力を発揮していく. リーダとしてのアプローチを実践していっていただきたい.

g-mod

  • 学生の相談相手としては優れていると思いますが,リーダーシップをどのように発揮すれば良いのか思案しているように感じます.少なくとも一線を引いて,仲良しクラブからプロジェクトチームへ進歩させて下さい.
  • 前DMCプロジェクトのPMです.地理的な問題もあり,私もコミュニケーションでは苦労しました. メーリングリストだけではなく,直接嶋津先生宛や電話なども積極的に活用するとよいと思います.
  • 時間厳守に要注意! PMの役割が不明瞭でした.
  • このプロジェクトの目的はなんでしょう? そのシステムを作ってもお金がもらえるわけではないですよね. であれば,「期日までにちゃんと作る」だけでは,何のためにわざわざ時間を使って開発するのかわからないということになります. 目的をしっかり意識していればそれは大丈夫と思います.
  • 部分システム開発の特徴をメンバ(学生)に解説する必要がある.
  • 学生の学習目標,PMの学習目標に対するPDCAも含めて,最終報告会で発いただきたい.

satoimo

  • スケジュールと工数管理を中心にマネージしている様ですが,開発工程のメルクマールを設定して管理した方が良いと思います.
  • システム開発とは何かをメンバーに理解させて下さい.
  • 目的が比較的明確で,技術的にもそれほどハードルの高いものでもなさそうです. であるからこそ,チームがプロジェクトを通して何を得たか,が問われることになると思います.
  • 開発線表をもう少し具体的(詳細化)する必要がある.
  • ポータルサイトの活性,さらに,環境保護への貢献等,ユーザ要求は広く深い内容,かつモバイル使用,地図情報連携と技術的にも,難易度の高いプロジェクトと認識しました. 最終報告会で,特に苦労した点,どう克服したか等,お聴きしたいです.

さうんど おんりぃ2

  • 相談相手ではなく,リーダーとしてプロジェクトをどのように推進するかをアドバイザーと相談すると良いと思います.成果物の標価基準を明確にするためにクライアントをうまくコミュニケーションを取ってください.
  • ゲーム開発の特徴を文書で残しておくことを希望します.
  • 当日は結局質問の答えがいただけなかったのですが,PMとして何をマネジメントしていくべきだとお考えか,ぜひお聞かせいただきたいと思います. 何をマネジメントするのかということは,何をコミットメントするのか,ということに等しいはずです. あなたはこのプロジェクトを通じて,何を成果としてコミットメントしますか?
  • 本プロジェクトにおけるPMの役割を明快に示すことができれば興味深い.
  • 前回は,結果的に,従来型のソフトウェア開発のプロジェクト管理の元に実施されたと認識. 今回,開発メンバから創造力,発想力を引き出すという意味で,アイデアが勝負のゲーム開発プロジェクトと他のソフトウェア開発との有効なマネージメントの違いについての分析を期待したい.

4hands

  • PMはプロジェクトの一員ですが,第3者としての立場を持たないとプロジェクトをうまくナビゲーションできないと思います.その点に注意して下さい.
  • もう少し学生を前に出してはどうですか.PMのスキルはかなり高いと感じています.
  • お客様は本当に現在の運用の改善を希求しているのでしょうか? 改善で限界があるのなら,新価値の付与を考えていく必要があると思います.
  • 実現機能順序については再考の要がある.
  • プロトタイプで作成したものを,確認後の本番開発で利用するかどうか?利用する・しない各々のメリット・デメリット等を是非,最終発表会で伺いたい. 一般ユーザターゲットにて,プロトタイピング方式操作ガイド作成,システム移行導入支援等,スケジュールが厳しいことが予想される.タイムマネジメントへの工夫についても,是非お聴きしたいです.
運営者に対するコメント

準JUN

  • (全プロジェクト共通です.) ・PMとメンバが協力して発表し,質疑に対応するやり方は良いと思います. ・配布資料としてプロジェクト提案書・定義書をいただきありがとうございます.教育として実践しているという観点からは,できれば,前回配布いただいた各自のプロフィール・学習目標の資料があるとありがたいです.

g-mod

  • 評価が難しいプロジェクトだと思います.「作りました」「そうですか」以上の価値をどのように方向付けていくかが重要だと思います. PMの性格からして,状況が切羽詰ってきても方法論ではなく根性論でなんとかしようとすることが予想されるので,何かしら手を打っておいたほうがよいと思います.
  • おそらく学生は,この様システム開発の経験が将来役に立つであろう.そうかどうかはPMの能力による.

satoimo

  • アイデアを実現する過程を明確にすると良い事例になると思います.
  • クライアント研究室のメンバーに自分たちもjoinして追加研究開発をする,ではただの研究委託か人材派遣であって,本研究の主旨から外れていると思います. あくまで自分たち=仮想SIerとクライアントは分離して捉えられるべきですが,本来の企業間取引であればクライアントとSIerが互いの目的を混同してしまうことはありえないわけで,両者とも大学の研究であるという今回の特殊な関係においてのみ発生する状況ではないかと思われます.
  • 「こうゆうプロジェクトはPMが相当しっかりしていないと学生は困るだろうな」…感想

さうんど おんりぃ2

  • 興味深いプロジェクトですが,だからといってあらゆる面で特別扱いはされるべきでないと思います.「ゲームだからしょうがない」を言い訳にすることは,メンバーあるいは評価側のいずれにおいても禁句だと思います.
  • 本プロジェクトは題目名「映像のない…」を除けば改版開発とは言えない.学生固有の'from the scratch'の典型と感じた.PMもオリジナル版を把握してるようには感ぜられない.

4hands

  • リリース後の保守を考えると,さらに発展しますね.システムの運用保守まで評価に入れると更によくなるでしょうね.
  • うっかりするとただの平凡な開発プロジェクトに終わってしまいそうです. それはそれで良いのかもしれませんが.