準JUN

名前	役割	所属
寺沢尚史	PM	株式会社CIJ
荒木恵	学生メンバー	総合政策学部4年
川口将司	学生メンバー	環境情報学部3年
黒木雄太	学生メンバー	環境情報学部3年

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

・画面イメージでログイン画面やユーザ管理画面などが多く含まれているが，システムをmoodleのモジュールとして開発すれば，添削機能の開発に集中できるのでは？(実装技術になるが，現システムをmoodleに組み込む作業を今学期の目標とする)
・発注者の先生(重松先生)とのインタビューを詳しく記録して，分析することが重要だと思います．インタビューの不完全さを後でチェックすることもできるし，発注者の言いたいことをより正確に理解できると思います．
全体としては重松先生とのおもしろいコラボレーションだと思います．しかし，開発プロセスのゴールを明確にして，メルクマールとマイルストーンを定義しなおしてみる必要があるかもしれません．ウォーターフォール型の開発であれば上級工程のメルクマールが達成されていないと下級工程のブレが大きくなるので心配です．
お客様とも許すかぎりのコミュニケーションをとっているのがよい．自分たちの作るものに対して，責任を持っているという姿勢も評価できます．気になった点は，クライアントが現行のシステムに不満を持っているのに，そこは我慢して私達の作るところは満足してもらうと言っているように聞こえた所です．現状のままで｢添削システム｣として成り立つかをきちんと分析してみて下さい．
PM依存の傾向が見える(実績値より)． →分析が必要ではないか．プレゼンはわかり易かった．
・プロジェクトの進めかたについては，基本的なところはきちんと押さえていると思います．

・発表については，何をやったか，このようにやったというところはわかりました．ただ，どうして，そのことをやることにしたのか，どうして，そのようにやったのかはわかりませんでした．理由がわかりませんと，それがよいのか悪いのかわかりません．

・ウォーターフォールとしたことは，何の問題もありません．ただ，実際の開発はいくつかのブロック，サブシステムに分けて開発することが普通です．例えて言えば，白糸の滝型ですね．そういった場合，開発の線は複数になり，前後します．ということで，言いたいことは，開発の線は一本ではなく，複数引いてもかまいません．より作業実態がわかるように工夫してください．

・マイルストーンの設定は，大切なことです．設定基準，やマイルストーン到達時の完了基準といったことを，明確にしておくとよいです．そうすれば活用できます．単なる，一里塚にしないようにしてください．

・実績工数を把握して管理することは重要なことです．システム開発は人手によるところが大半ですから，実績工数の推移は業務の状況をつかむためのよいセンサーとなります．せっかく，楽観・悲観といった物差しを設けたわけですから，工数の経過状況をつかんで，楽観・悲観の基準と比較しながら，EVM的管理につなげるとよいでしょう．

・システム開発はシステムを作ることを目的にしていますが，システムを作るのはシステムが欲しいからというより，システムが実現するものが欲しいわけです．システムが実現するものの，評価，レベルをもっと突き詰めて検討してください．そうしませんと，せっかく完成しても，出来たことにならない，などということになります．

・プロジェクトは決めたとおりに進みません．変更が多く発生します．理由は様々です．事情が変わった，考え落ちがあった，洗い出し不足であった，承認が取れていなかった，リソースの見積もりが甘かった，エトセトラです．システム開発を始めるにあたっては，開発要件のベースラインを最初に吟味設定し，そのベースラインに対して変更管理ができるようにしておくことが必要です．
中国語で添削支援システムができるなら，英語，アラビア語など他の言語教育にも活用できるのではないか．汎用科目にも適用できる可能性がある．このプロジェクトに限らない話だが，発注が特定目的であっても，開発側が，広い視野から多目的への応用を提案できるといいのではないか．より広い市場を獲得でき，投資コストの回収が早まることが期待できる．
(1)既存部学習
海底開発においては既存部分の理解が最も大切である．この考えに添って，開発の初期段階において，既存部の学習を重視したことは開発管理上から評価できる．ただし，できれば，学習を兼ね，試験データを作成し，徹底した試験を実施すると，さらに効果的に考える．これは改定開発においては，既存部の問題点が，新規分もしくは，修正分に影響することが少ないので，流用分については徹底した確認が将来に貢献するからである．

(2)プロジェクトの目的の理解
本システムの利用方法に考えを巡らすことが大切．現方式は，学生からの入力を得た上で，添削し，その後教師の添削結果や統計データを適宜即時(realtime)に参照すると理解できる．処理状態(processing mode)からは，学生の入力と添削は｢一括(batch)｣データ(添削結果や統計量)参照は｢即時(realtime)｣である．本システムの将来型として，この｢一括｣処理形態を｢即時｣にする方式である．この場合は，学生は回答を即時入力し，教師はこれに即時に添削するシステムである．こうした対案(alternatives)を発注元に対して提案する姿勢が必要と考える．特にPMに対しては望みたい．
・前回の「中国語添削システムの機能拡張」を行う．ユーザーに満足いただける機能提供をめざして，PDCAを回しているところが，大変良いと思った．

・特に，前回の問題｢何人の人が同じ間違いをしていたかの算出｣についてユーザである重松先生の暗黙の要求事項を吸い上げられなかった点についても，｢学生の間違いの傾向を確認する機能｣としてサポートし，かつ｢プロジェクト提案書｣で開始時の要件を合意した上で，設計・実装を進めながら，毎週，ユーザに確認を取って行くという改善に継がっているところが，良いと思う．

・PMは「ウォータホール」と説明していたが，｢アジャイル開発｣にも近い．短期間で，ユーザニーズとの乖離を防ぐ，手堅い進め方と認識した．

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

とても分かり易い発表でした．改版であることもありますが，最終outputも良い出来だと思います．開発プロセスについての説明があまりなかったのが，若干残念です．
前回開発システムを改修するという事で新規の開発とは違う困難さある．前回開発分の理解するところから始まるし，前回の実装にしばられる部分もある．DBの再設計というのは，かなり思い切った判断である．規模が小さいから出来るが現実には出来ないことが多い．リファクタリングで苦労している事は，これからの設計・コーディングの指標として役立つものと思う．ユーザとしての学生をどう取り込むは課題として残っている．プレゼンはかなりうまい．
・発表の仕方：good
・やさしすぎたのか，学生の出来が良すぎたのか，RDBを許可しなおしているのに，プロジェクト推進の困難さを体験出来なかったようである．

・本来のプロジェクトならこういう風に推進されるべきだが，本プロジェクトはもっと失敗して欲しかった．5満点3点．順位3．
前のJUNプロジェクトの何が問題なのかを明確にしてから計画を立てる必要があったのでは？（プロジェクトの目標が明確でない印象が強い）　「運等可能なシステムを作成する」のが目標だったが，実際にはリファクタリングに時間を費やしてしまった．リファクタリングは保守や拡張を容易にするための手法なので目的に対して違うことをやってしまったのではないか？
システムのV.up作業(機能追加)→”CAI”添削支援システム
全面的な新規開発とどちらが良いか，判断基準は？

・実際にv.upの際のトラブルをいろいろと体験した．その経験は今後，非常に役立つはず．
・ヒューマンインターフェイスの重要性を体験して良かった．
ソースコードをきちんと読むことの重要性を主張していましたが，大規模システムの拡張や改善では，そのようなことは殆ど不可能です．何のためにいろいろな設計文書を残すのかを，もう一度考えてみてください．上流工程での作業のやり直しになりましたが，ここでの工数は，コスト超過の原因に繋がります．早い段階でのシステム分析の重要性がよくわかったと思います．
コラマネとして，具体的なコスト感覚を得るための工数＝金額の概念は入れていないとのことであるが，企業の立場から見れば，最後まで違和感が残った．昨今のビジネスシステムの受託開発が主流の企業では，お金の話は営業と分けて考えることは殆ど無くなっている．特に，人と相対する場面では，いとも簡単にコストの話が出るのは当然の事である．人が規模を予測するのはFP値ではない．コストでその規模を予測するのである．つまり，ソフトウエアの開発，ハードウエアの調達，環境構築，一切全てを含んだ規模予測はコスト以外に不可能である．本コラマネが「産学」としながらも，産のベネフィットが一向に見えてこない一因はここにもある．
【総合評価】
準JUNプロジェクトは，C～D評価（顧客はよい評価だが，そのままでは使えない）と評価します．

【詳細な気付き事項】
(1) 重松先生の要求ヒアリングを“夢が聞けた”と思える気持ちはすばらしいと思います．「人に使ってもらえる，喜んでもらえる」ものを作ろうとしていた意思が見えました．

(2)リファクタリングを実施したとありますが，ソフトウエアの動作を変えることなく内部構造の変更を行ったのでしょうか？　ソフトウエアの動作を変えてしまって，内部構造変更を実施していたとすると，何をやっているのかわからない状態に陥ります．

(3)既存システムの調査を早期に実施すること，中国語履修生の評価をもっと早い段階に実施することができていれば，A～B評価になったと思います．おしいですが，重要な点が抜けてしまっていると評価します．
学内で現に使用されているシステムの改良・改善を行なった．プレゼンテーション後の質疑応答にあったように，この程度のサイズでは，新規開発で十分である．クライアントのビジョンをしっかり受け止めることの重要性に気づいたことは評価できる．それなら，例えば，システム開発者として，「学生側は，できあいのソフトウェアを使いましょう．ここでは，そのソフトウェアの上で，先生の行ないたい処理をサポートするプラグインを作りますよ」という提案をできなかったか．すなわち，ソフトウェアを作らない，というソフトウェア開発もあるのだから．
・ＤＢ設計は，エンタープライズ系システムの場合，基本となる仕事です．情報を洗い出し，その使われかたを，５Ｗ１Ｈで分析します．要求・要件情報から名詞と動詞をつかみ整理するという方法も用いられます．ともあれ，ＤＯＡのように整理された方法論もありますからよい機会なので勉強してください．

・発表は大変わかりやすく，よく整理されていたと思います．
・操作性は確かに悪そうですね．出来上がったシステムは利用マーケットが評価します．利用者の声を聞くことを基本動作にしてください．

・コストについて話題になりましたが，修正の対象となる現行システムがある場合は，実際のビジネスでも見積もりが大変難しいです．ただ，現実は既存のシステムを手直しするような開発が，そうですね，金融システムなどでは仕事の９０％を超すと思います．それだけ，すべての分野が既にシステム化されているのですね．よい勉強になったと思います．
SWの改版プロジェクトの典型的なトラブルの様相を呈したように見えます．つまり，動いているプログラムがあるという気の緩みからオリジナルバージョンを十分に調査しないで改修に望んだ結果，プロジェクトの規模が計画を上回ってしまうというのは実際にも良くみるトラブルです．「手を抜いたところがトラブル」とは世の常ですが，対処方法は基本に忠実に取り組むことと多くの経験を重ねる事でしょう．なぜなら，予測できないものは対処できないし，予測できるようになるためには多くの経験を必要とします．その点では，学生時代にこのような経験を積み重ねることはたいへん良いです．なお，このチームは多少のトラブルはあっても愉しんでやってきた様子が表情に表れていました．この点からも学生の成長が分かりました．
汎用性の高いシステムの構築に関するプロジェクトである．使って貰えるシステム構築という目標から明らかなように，利用者の操作性，機能性を重視した支援システム構築という点が特徴的．
前期からの課題（機能）を実現する改版のプロジェクトを，一定の評価を得て，無事終了することができ，良かったです．教授と学生，両ユーザに使って貰った生の声から，さらなる課題（問題点）を明確にすることができたことも重要であり，原因分析を行い，是非今後に活かして欲しいと思います．改版（エンハンス）・・・現場のプロジェクトの多くは実はこのパターンを行う際のリスク，問題点を身をもって体験できたこともメンバ（学生）にとって，貴重な経験だったと思います．継続して，次に活かす場があると良いと認識しました．

準JUN

和文中訳問題添削支援システム『JUN-JUN』の開発

『JUN-JUN』イメージ

プロジェクトの活動概要

中間成果物

最終成果物

メンバー

メンバーの声

ソフトウェアの規模

工数・スケジュール

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

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