評価委員による最終評価

目次
コラマネ全体の評価
各プロジェクトの評価
学生に対するコメント

準JUN

  • プレゼンの仕方として,最初に成果物を示したのは良いのですが,最後にも成果物も示して欲しかったです.
  • システムを提供するという事は,たんに必要な機能を実装すれば良い訳ではないので,これからも何が重要で何をプラスできるのか常に考えて下さい.
  • クライアントとのネゴシエーションはオンサイトカスタマでやるのが良い.
  • スライドの切り替えが早すぎて,読み取れないものがありました.少なくとも30秒以上は画面を見せて下さい.
  • 社会の活動はほとんどプロジェクト活動です.その中で重要なのは,コミュニケーションと個人の魅力です.
  • どのようなプロジェクトでも,プロジェクトの上流の分析が重要です.この段階で,クライアントとの合意形成ができていないと,後日,費用面での難題が降りかかってきたときに,トラブルを回避できなくなることもあります.気をつけましょう.  学ぶことが多かったプロジェクトだったと思いますが,最後まで問題解決ができ,大変良かったと思います.
  • (1) 嶋津先生が「不安だった」ことをプロジェクトメンバは知っていましたか? その対策を実施しましたか? 顧客窓口であった院生とのメールを嶋津先生にCcするだけで,ある程度の不安は解消されると思いますが,どう考えますか? プロジェクト遂行時には,顧客キーマンを早く見つけましょう.これはPMだけの仕事ではありません.

    (2) 要件定義が始めから終わりまで活動しているようなスケジュールでしたが,実際には,要求変更の監視・コントロールを実施していたのだと推測します.これは非常に重要で,忘れられがち(初めに決めたどおりに物事が進むと錯覚しがち)なことです.非常によかったことではないかと思います.
  • システムを発注するサイドで考えて見ますと,プログラムの塊が欲しくて,システム開発を発注する会社は存在しないでしょう.みんな,システムが作り出す世界が欲しいわけです.システムが実現する世界のクオリティは要件定義に大きく依存しています.要件定義を大切にしてください. ・皆さんの力で,日本を発展させるイノベーションを実現してください.
  • 途中で目的を逸したとのことですが,最終的には目標が達成したようですね.目標の重要性を認識する上で良い体験になる.
  • 今回,プロジェクトの目標設定の重要性と顧客との打ち合わせ会議で成果を上げるために,準備すること,積極的に提案を行うことの大切さを体得できたことはとても良かったとおもいます.顧客要件を把握するためには「先入観無く,耳を傾ける」大切さとともに「決して受身ではなく」「それを能動的に進めていく」(適確な提案力)ことが大変難しいですが,重要と認識しました.

g-mod

  • とても分かり易い発表だと思います.
  • ユーザの操作性については,プロトタイプを使った確認など,事前に解決しておく必要がある.次回は,新規プロジェクトをやって違いを体感して欲しい.
  • ダウングレード→デグレート
  • 操作性の悪さ→評価を高めるにはどうすれば良いかを考えると良いでしょう.
  • プロジェクトで経験した事が実際の世の中のシステム開発で起きています.基本に忠実に作業を進めましょう.
  • システム改善の難しさを理解できたのは,大変よかったと思います.実社会での問題解決では,この類の課題がたくさんあります.改善プロジェクトを体験したことによって,既存システムの文書に,どのような情報を残しておいて欲しかったかが,よく理解できたと思います.次にシステムを改変する人のために,どのような情報を残すべきかを考えて最後のまとめをしてください.よい学習ができてよかったですね.お疲れ様でした.
  • これからみなさんが経験するソフトウエア関連のプロジェクトは,既存システムの改版が多いと思います.準JUNプロジェクトで,“まず,既存システムの調査を実施する“ということを勉強できたと思います.これを忘れずに,今後のプロジェクトに取り組んでください.
  • エンジンのところは大変よくできたようですね.おめでとう.しかし,自動車はエンジンだけでなく,ブレーキや,方向指示器やライトや・・様々な部分のトータル機能で評価されます.これからは,トータルパフォーマンスを常に意識して何事にも取り組んでください.
  • 主体的に取り組むとか,コミュニケーションを重視するなど適切な目標をもって取り組みよい結果を得たと思います.これからも,この成果をもとにさらに精進してください.
  • 「何のために作るのか?」,「誰が使うのか?」と言った,本来であれば当たり前のことが再認識できたプロジェクトですね.
  • 改版作業を体験「ソースコメント」の重要性を体験できたことは,とても良かったとおもいます.「何故それが必要なのか」これがわかると鬼に金棒です!(自分をふりかえっても,また,周りをみても「開発経験の豊富な人程わかり易いコメント書いていた.コメントの書き方をみると,コーディングスキルがわかる」だった(10年前の記憶ですが・・・)と思い出しました)

satoimo

  • 色々な良い経験をされたと思います.
  • 要件定義を受け入れて,プロジェクトをやっていく経験も必要.
  • ・プログラムが出来ても,本projectは失敗であるということが認識出来たら,社会人として一人前である.

    ・将来,仕事に就し,このPMを真似しなければ,うまくいく可能性がある
  • 3回目の方が2人いましたが,今回のプロジェクトで新たに学んだことは何ですか?前回までの失敗を今回はどのように修正しましたか?その効果はありましたか?
  • プロジェクトの一番重要なのは,メンバ間のコミュニケーションです.社会に出ても,これを忘れないで下さい.
  • 最後にチームプレイができるようになったとの報告を聞いて安心しました.捕まえ難い目標でしたが,成功したのは立派でした.
  • (1) 自分たちでプロジェクトマネジメントし,プロジェクトを成功に導いたことはすばらしいと思います.プロジェクトマネジメント活動はPMだけの役割ではないということを覚えておいてください.

    (2) プロジェクト計画段階で,責任分担を決めることは重要です(RAMという表を作ることもあります.).みなさんは,プロジェクトマネジメントはPMの責任分担だと決めつけていませんでしたか? 責任分担についてプロジェクト内で議論することは大切です.今後のプロジェクト活動に役立ててください.
  • 他の会社のシステムを買って使うということは,よくあることです.時には,プログラムを買わず,開発ドキュメントだけを買って,それを元にシステムを自分たちで作るということもします.私の経験でも,団体定期保険のシステムドキュメントを買って,プログラムはゼロから作ったという経験があります.ビジネスの世界にはいろいろなシステム開発があるのですよ.
  • プロジェクト内のコミュニケーションの重要性とコミュニケーションを確立する方法を直接学べた事はたいへん貴重な経験です.次回プロジェクトにもこの経験を活かしてください.
  • 「チーム力を向上させること」は基本的にリーダのタスクですが,そのためにメンバがリーダーそして他のメンバを活かし,自分を活かす「フォロアーシップ」が重要と言われています.今のプロジェクト成功にあたって,フォロアーシップの発揮があったのではないかと感じたが,どうだったのでしょうか・・・・

さうんど おんりぃ2

  • 同一のテーマで,二人のPMを体感され良かったと思います.今回のゲーム開発手法のみならず,システム開発手法の良いところを取り,学習していって下さい.
  • 出来の良い学生である.
  • ゲームで"おもしろい"が高品質ソフトですね.
  • アイデアの乏しさが気になりましたが,遊び心が少ないのかもしれません.これを克服できれば,エンドユーザが急増すると思います.そこが今後の課題ですね.
  • (1) 成果物,プロジェクト活動とも,すばらしいプロジェクトだったと思います.ゲーム開発とソフトウエア開発の融合を試みて,2人とも多くを得ることができたのではないかと思います.また,プロジェクトメンバ自身のプロジェクトマネジメントの必要性を感じることができたのではないかと思います.今後のプロジェクト活動に生かしてもらいたいと思います.

    (2) 今後,大規模なプロジェクトを経験することもあるでしょう.その際には,今回のような進め方は難しくなってくるということは頭の片隅に置いておいたほうがよいと思います.大規模なプロジェクトでも,上手にサブプロジェクトに細分化されたプロジェクトなら,今回の手法も使える場面がありますので,そのことも覚えておきましょう.また,自分がプロジェクトマネージャになった場合には,プロジェクトの細分化がプロジェクトを成功させる上で大切であることを考えるようにしてください.
  • ・大切なことにたくさん気がついたようで,よいPBLになったようですね.
    ・ 発表はわかりやすく,私も大変勉強になりました.ありがとうございます.
  • 前回と異なったPMのリーダーシップスタイルを経験できたことは,たいへん貴重な経験だったと思います.リーダーシップスタイルも各種ありますので,どのよな時にどのようなスタイルが適しているか研究してみると良いでしょう.
  • 面白い楽しんで貰えるゲーム開発プロジェクト,成功おめでとうございます.創造性をキーとするゲーム開発は,業務アプリ等の開発とは異なったプロセス,視点があると思いますが,「正解をリードするITエンジニア」として,基本をベースとした上で,「発想力」豊かに常に「新規性」へ挑戦する姿勢を忘れずに,今後の活躍を期待します.

4hands

  • 実際の開発作業では,実ユーザと直接のやり取りがなく"お客様の喜ぶ顔を見れないことも多いかと思います"非常に良い経験をされたのでは?
  • "まとめ"で示した内容を今後に生かして下さい.
  • クライアントとの対話により,システムが良くなってい過程を経験できたので今後も活かしてもらいたい.
  • 顧客の立場でシステム作りをする事が一番です.
  • アンケートの作り方は,従来からいろいろと議論されてます.心理学系の書籍でも扱っていたと思います.資料を探して研究しておいてください.
  • (1) みなさんは,非常に大きな成功経験を得られたと思います.一般的に正しいと言われているやり方(PMBOKによるプロジェクトマネジメント)をすれば,プロジェクトの成功確率が高くなるということを経験されました.計画の大切さを忘れないで下さい.

    (2) 今回のプロジェクトは障害が少なかったプロジェクトだったと思います.これは計画が正確で緻密だったこともありますが,環境が穏やかだったということもあります.現実には,荒波状態のプロジェクトがほとんどです.プロジェクト活動期間中に,常にプロジェクトの成功のために考えることを忘れないようにしてください.敢えて厳しいことを言うと,プロジェクトマネージャの言うことを聞いていればよいというプロジェクトメンバは,まだまだ半人前です.プロジェクトマネージャに提言できるようなプロジェクトメンバになるよう,これからがんばってください.
  • ユーザー,プロジェクトマネージャー,開発者三位一体となった.成功ですね.おめでとうございます.
  • よくできていると思います.アジャイル型(繰り返し型)でうまくいったのは,開発者が利用者の立場に立ち,利用者の観点から要求をまとめ,分かり易く説明したからだと思います.コミュニケーション力が良かったからですね.
  • プロジェクト成功,お客様に喜んで使ってもらっていること本当におめでとうございます.時に,この成功がすんなりといったわけでなく,お客様の評価を得るまで沢山の苦労が体験されたということに価値があると思います.
PMに対するコメント

準JUN

  • プロジェクト憲章を作らなかったため学生がスコープを持てなかったのではないか?プロジェクトの後期プロセスに苦労された様ですが,むしろ初期プロセスに時間をかけた方が良いのでは?
  • 要件定義がふれるのは,大問題なので,プロジェクトの最初に決める手法を身に付けて下さい.
  • 実現性調査は良い.実際のプロジェクトでも常に必要である.(常にそういう部分がないものは悪品として,売れない)
  • 要件定義が長引いて確定はしなかったとのことですが,設計や実装が要件定義よりも早く終わっているのはおかしいのでは?
  • 当初,上流工程の詰めの甘さが気になりましたが,その重要性が学習できたようで,安心しました.この経験が,PMとしてのスキルアップに繋がったと思います.合格ですね.
  • (1) 周囲が達成の難易度が低いプロジェクトと見ていた分,難しいプロジェクトだったと思います.早い段階で,g-modプロジェクトとしてのスコープを定義できれば,中盤以降ももう少し楽にプロジェクトを遂行できたのではないかと思いました.

    (2) プロジェクトマネジメントの基礎知識は,PMBOKで学習できます.是非,スコープ定義→WBS作成→スケジュール作成までの技術習得をすることをお勧めします.そうすれば,スコープを見越した細かな作業指示(フォロー・コントロール)が実現しやすくなります.ただし,PMBOKはあくまでも入口です.ヒューマンスキルを磨くことにも努めてください.
  • 時間的に難しいのかもしれませんが,テストの量,ドキュメントの量が少し少なかったのでは.
  • 多くのステークホルダー,制約条件の中で,「メンバが主体に動けるよう導く」ことでプロジェクを成功させることは本当に難しいことと思います.(私は特に苦手です)一つ一つ経験し,実感し,体得していくことが,PMとしての成長の必須条件と考えます.今,経験を活かして,挑戦(チャレンジ)していってください.

g-mod

  • 発表に含まれなかったせいかもしれませんが,プロジェクト初期の計画がうまくいかなかった印象があります.しっかりと計画を立てられると良いと思います.
  • 見積は難しい部分もあるが,違いがでてしまった原因を分析する必要がある.
  • 途中から全面作り直しに変わりましたが,やはり上流工程での分析が不十分だったと言わざるを得ないでしょう.最終成果に対し,学生たちが少しもやもやとした感じを抱いていたのはかわいそうでした.このシステム開発でのトラブル原因を次に継承しないために,プロジェクトの終了宣言をどのような形でしておくのがよいかについて,考えるのもPMの役割でしょうね.難しいプロジェクトへの挑戦,ご苦労様でした.
  • 改版プロジェクトという他の4プロジェクトにはない要素に取り組まれて,学ぶ点が多かったのではないかと思います.実務では改版プロジェクトが多いので,是非,今回の経験を生かしてほしいと思います.特にPMとしては,スタート(改版前のもの)がどういうもので,ゴール(改版後のもの)をどういうものに仕上げるかということがスコープとなります.検収の基準にもなりますので,十分に注意することをお勧めします.
  • プロジェクトメンバーのモチベーション向上を心掛けて臨んだ事が良い結果につながったと思います.
  • 今回,コストの観点から,工数管理を実施したうえで「顧客に使って貰える」「満足いただける」機能の実現の重要性を再認識さrたということ,是非,今後,現場で活かしていって下さい.業務と併行の非常に厳しい作業だったと思います.お疲れ様でした

satoimo

  • 短い期間で苦しまれ,御苦労様でした.おそらく,より長い期間であれば,カバーリングできたと判断します.本経験は必ず生かせると思いますので,今後がんばって下さい.コミュニケーションに関する研究を行なわれることを提言します.
  • ・Teamの運営をもっと考えた方がよい.
    ・メンバとPMの意識が一体化してない.
    ・学生に問題があるのではなく,PMに問題があったと考えるべきである.
  • PMミーティングで議論した内容はプロジェクトマネジメントを行なう上でどのように役立ちましたか?
  • チームのまとめは,もっと積極的に推進したほうがよかったかもしれません.PMとメンバーの距離が少しあったように感じました.
  • (1) 難しいマネジメント手法を敢えて選択して,自由にプロジェクトメンバに活動させたという点は非常に勇気のある行動であると思います.できれば,そのことをプロジェクトメンバに周知して欲しかった.そうすれば,プロジェクトメンバの理解を得られたと思います.

    (2) 実務でも(1)のような手法を用いる場合は,それをリスクと捉え,リスクの監視・コントロールを実施することをお勧めします.プロジェクトメンバを自由に活動させて,プロジェクトを成功に導くことは究極のプロジェクトマネジメントの姿ではないかと思います.是非,がんばってください.
  • 最終報告におけるプレゼンテーションを工夫(学生みたい)
  • 昨年6月,評価委員として参加させていただいた時から感じていることですが,企業のPMにとってはじめて,顔を合わせる学生の方々をメンバーとして,業務遂行で多忙の中,週1回のミーティングで,PMの任を果たすことは,非常に難易度が高いと認識しています.が,また,このような過酷な条件の中で重要なポイントをどこに置き,どこに注力して進めるか自分なりに目標を定め,成果をめざして頑張ることで得られることも少なくないと思います.今回発見したこと,得たこと,現場で活かして下さい.

さうんど おんりぃ2

  • 素晴らしかったと思います.
  • プロのゲーム開発手法を伝達していただいて,学生もいろいろな学習ができたと思います.控えめながら,学生をよく導いていたと思います.
  • ゲーム開発の場面に,ソフトウエア開発手法,プロジェクトマネジメント手法を導入することを期待します.きっと,役立つ場面があるのではないかと思います.私も,ゲーム開発手法をソフトウエア開発に応用してみようと思います.
  • システム開発手法のよいところをゲーム開発の場でも実践してみてください.
  • 業務システム開発のプロジェクト管理とは違ったマネージメント力が必要と思いました.
  • ゲーム開発の専門家であるPMが「システム開発との違い」を認識し,「ゲーム開発へも取り入れるべき点をシステム開発の方法から得た」ということがとても良かったと思う.発想力豊かで,高品質はユーザに喜んで使って貰えるソフトの効率的な開発方法をめざして下さい.

4hands

  • 反復型開発のメリットを最大限に活かす方法を考えてください.
  • このプロジェクトを通して,学生は学ぶことが多かったと思います.ありがとうございました.
  • (1) 計画立案・共有,プロジェクトメンバの観察がすばらしかったと思います.是非,私も見習いたいと思っております.

    (2) プロジェクト実行フェーズにおけるプロジェクト監視・コントロールも重要です.特に変更管理は重要でありますので,今後は,その点にも留意することをお勧めします.
  • 非常に良く,マネージメントされていると感じました.「使えないものは作るな」はいいですね.
  • 推敲フェーズと作成フェーズの反復型でユーザの望んでいることを明らかにするkとができたとのこと.プロトタイプによるニーズの明確化ができたのだと思います.
運営者に対するコメント

準JUN

  • 本評価用紙にメモ欄が欲しいです.スライド等が事前に配布されない場合,覚えていられません.
  • 改修案件が出来たのは興味深い.改修の場合には,少し指導も変えなければならない.
  • ・既プロジェクトの機能追加というのは,本コラマネの目的からずれているようだ.今後は新規プロジェクトのみにするのがよい. ・CPUスイッチがあると,PC切替が楽です.
  • 新規開発よりもレベルアップすれば,よりプロジェクト経験としては,効果があるかもしれない.
  • システム改善プロジェクトを体験できたのは,大変よかったと思います.改善での苦労話を整理しておくとともに,失敗をしないために設計段階でどのような文書を整理しておくべきかを考えさせることが重要かとおもいます.

g-mod

  • ・学生,PM共に得られたものがあり,良いプロジェクトでした. ・3期目2名,1期目1名ということで,プログラム知識が豊富なことは了解できた.このプロジェクトは2期目までしか参加させないのがいいと思う.困難を経験でのりこえるのではなく,考えてのりきることを,プログラミングを勉強しながら問題解決しなければならないというシチュエーションが大切.
  • このプロジェクトの事例は,プロジェクトの上流の工程での管理の重要性を教える上で,良い事例となると思います.

satoimo

  • チームに対してPMがプッシュするタイミングについて,少し考える必要があるかも知れませんね.
  • 今回,配布頂いた体験レポートはとても率直な忌憚のない内容がとても参考になり,拝読させていただきました.一部,学生の方からのPMへの思いの記載で「際どい」内容が載っていたと思いました.学生の方々がどうとらえらるか等興味深い反面,企業名,個人名が特定できる資料であり,公開範囲は難しい面があると思いました.

さうんど おんりぃ2

  • ゲーム開発と言う特殊な手法をコラマネに追加しておきましょう.

4hands

  • このプロジェクトから顧客の積極性・フィールドバック,PMの経験値により,プロジェクトの成否が大きく左右されるのではと感じました.PMOや運営サイトのサポートでその部分を護衛する必要を感じました.
  • 地味ですが,よいプロジェクトです.
  • 計画段階から,抑えるべきところをしっかり抑えていたと思います.良い展開事例として,今後の参考にできればと思います.
  • 本プロジェクトのプロジェクト内コミュニケーションの成功要因を分析して欲しいです.
  • プロジェクトでの第三者の損崎は非常に大きな意味があると思いました.時に,難しいプロジェクトであればあるほど,渦中に入り,みえにくくなることがあります.又,しがらみ等で判断を遅らせることもあるかもしれません.「機能するPMO」大変参考になりました.