satoimo

名前	役割	所属
吉田浩二	PM	株式会社アトムシステム
篠崎友識	学生メンバー	環境情報学部4年
野上大輔	学生メンバー	環境情報学部4年
姉崎祐樹	学生メンバー	環境情報学部3年

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

・厳研の6つの要求とは何か？

・本プロジェクトの目的とは何か？その背景は何か？これらを理解しないと提案はできないのでは？

・｢環境問題への取り組み｣がキーワードと思うが，それがシステムにどう関連しているのか？

・技術の話はいろいろでてくるが，その前に目的意識を明確にする必要があるのでは？

・｢携帯電話で読み書きできるBlog｣などのコンセプトを考えるとおもしろいのでは？
新規性の高いソフトウェアの開発を行うことに固執していないでしょうか．限られた期間とリリースで実現可能性のチェックをするとよいでしょう．他の研究室とのコラボレーションであるのですから自己実現を多少犠牲にしても，クライアントの満足を優先してはいかがでしょう．
ニーズ機能要求間でトレーサビリティーがきちんと付けられており，クライアントとのベースラインの合意をとっているのはとてもよい．プロジェクトの目的は｢地域に密着したコンテンツの増加｣ですか？そのあたりを明確にした上でプレゼンするとよいと思います．
システム利用のイメージは解かり易かったが，プロジェクトの目的が曖昧であった．要求型の開発から提案型開発に変更した経緯は理解できた．但し，機能の詳細は見えなかった．
・携帯で投稿できるということで，本当にコンテンツ増加になるのでしょうか？　確かに，投稿できる方法を増やすことは，増やす一つの手段としてありえるものですが，このケースの場合，本当に増えるのでしょうか？　増えると判断したり理由が知りたいです．また，同じ目的を達成するために，他の手段の検討，比較はしたのでしょうか？

・共有したいとしている情報は，誰にも受け入れられるだけのものになっているでしょうか？　知られたくない情報，利害が発生する情報，プライバシーにかかわる情報，誤った情報，悪意のある情報，コンプライアンス上問題がある情報，そういった情報の取り扱い検討など，仕組み作りの何倍も時間と，手間がかかります．そのあたり，検討のまな板に載せてもらいたいです．

・パワーポイントが少々，ビジーでした．もう少し大きな字，図にすると，よいかと思います．

・3つの提案は，ハウレベルだったのが残念．

・プロジェクトが最後まで，うまく行くのかどうか，ちょっと不安になりました．ここが気になったというところは無いのですが，プロジェクト破綻リスク管理もしっかりやってください．

・開発する機能と，対象外になった機能があると思います．そのあたり，詳細に聞きたかったです．

・進捗管理で，情報共有が今回とりわけ大切とされた点は，よくわかりますが，どういう情報が共有すべき情報で，どのような仕組み，ルールを設定し共有を実現するのか知りたかったです．

・画面は，モックアップレベルで十分ユーザーニーズを引き出せます．紙芝居レベルのものでも，活用すれば効率的に要件を確定させることができますから活用を検討してください．
携帯からWebに投稿する手法も最近の流行のようである．すでにmoblogでできることをあえて開発する意味がどこにあるのか分からない．既存のもので流用できるなら，それを利用して安く早く開発することも重要である．
質疑応答でも指摘がありましたが，プロジェクトチームの目的とクライアントの目的が融合してしまっており，なおかつメンバーにその自覚がありません．作ろうとしているモノ自体のコンセプトと方法論は明確ですので，システムを作ること自体はうまくいく確率が高いと思います．ただそれは何のために？　ということが問題です．
(1)システムの目的が不明
プロジェクトを構成する3基本要素(目的，期間，資源)のうち，目的が最も大切である．しかるに，本発表では目的や機能がはっきりしていない．したがって，効果が推定できない．時にGPS機能付携帯電話機の使用を前提としてる様な発表であったが，必然性が把握できない．システム要件の検討にあたっては，その条件を与えれられる(given)ものと変えることのできるものに整理しておくことが大切である．CMSはgivenか．そうでないとすれば，全国展開のためのものを考えることもできる．｢地域住民からの原稿投稿｣の主体を置くためのCMSへの機能拡充提案もあり得る．

(2)開発線表における試験
12月の3週間が｢開発｣とあるが，これは実現(実装)implemantationで製造のことと思うが，これに比して試験は2週間である．試験の準備(環境整備，試験項目列挙．データ作成など)に時間が掛る様に予想される．なお，ここで言う｢移行｣の意味が分からない．通常は旧システムにおけるデータベースなどを新システムに持ち込むことを言う．

(3)疑問
即時性をもつ(現時点+現時刻)原稿は果して価値があるのか不明．
・私事ですが，茅ヶ崎の住人であり，かつ実は親戚が遠藤(里山地域)在住にて，大変興味深い内容であり，是非，地域の人々が積極的に訪れ，お互いに活用できるサイトになると良いと認識しました．

・とはいっても，プロジェクトとしては，資源(日程・人)が限られていることから，スコープの整理，調整が重要と認識し，｢プロジェクト提案書｣で開発対象項目と対象外項目の両方を記載していることは，大変良いと思った．

・最終報告会では，成果の評価方法について，御聴きしたいです．

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

モチベーションの点で難しいプロジェクトであったようですが，顧客から一定の評価もあり，成功といってよいと思います．ただし，成果物としては，既存のサービスとの類似性が強く，独自の部分を発表でもう少し聞きたかったと思いました．
委員や一般見学者が知りたいことを説明して頂いて，とても良い発表でした．また，Output(里撮)も魅力的で良い出来と感じています．
機能としては面白い事を実現している．ドキュメントに関しては，必要十分なものを作るという見極めが大切である．スケジュールに関しては，常に問題になる部分でこれから実践を通して，学んでもらいたい．要件定義をクライアントの要求ではなく，提案型にしたのは疑問が残る．通常ではありえない．
・発表の仕方：他チームほどは洗練されていない
・Projectのideaにすぐれている．SNS，携帯，GPS
・場所的な近さのideaは良いが，実際には意味がないと思う．
・開発量が少ないと思う．もう少し（読めない）いように計画すると，問題が起こり，ためになるprojectになったと思う．

・もっとチームメンバーが楽しく作業できることを考えるべきである．5点満点中2点．順位5．
スケジュールの管理はどのようにやっていたのか？　遅延したとのことだが，具体的にどの程度遅れたのか？　プロダクト品質への影響はどの程度？　ドキュメントはどの程度作成レビューしたのか？　ドキュメントの品質や価値はどの程度？　失敗したとき，それを繰り返さないようにするための工夫や経験の蓄積，スタートアップ時の教育＆意識合わせが重要だと思います．
1．"ドキュメント"の価値について，より深く考察して下さい．ドキュメントは"ソフトウェア保守"の要です．通常，大規模システムでは，開発費用：保守費用＝2：8ぐらいです．

2．サービス機能はなかなか良い．発展性がありそう．
クライアントの目的が良く見えなかったのは残念です．ドキュメント作成におけるメンバーの意識の違いがあちこちで見られ，気になりました．しかし，最後の追込みは頑張りましたね．セキュリティ対策は重要です．ネットワーク環境で，もの作りをする場合には，不可欠な要件であることを自覚しておくことが重要です．お疲れ様でした．
このプロジェクトもリアルなユーザを対象にした地図情報であるが，携帯とGPSの発想は非常に面白くマッシュアップサイトの一機能になれば，結構注目されると感じた．但し，SNS「湘南の風」としながらシステムのコンセプトにWeb2.0などコンシューマメディアに関する「集合知」観点が全く入っていないことに，若干失望した．また，このプロジェクトは他のプロジェクトと比較してメンバー間のコミュニケーション力に難があったとの反省点があった．
【総合評価】
里撮プロジェクトは，A～B評価（実際に使われている，継続的かはこれからの評価）と評価します．

【詳細な気付き事項】
(1)何のためにドキュメントを作るんだろう」という視点は非常に重要です．ドキュメントに限らず，目的を持って，プロジェクト内の各活動ができていたのではないかと評価します．

(2)非常に小さな成果物スコープであったため，詳細な計画立案を実施しなかったようですが，そのことをプロジェクトメンバやその他のステークホルダーに理解を求めるべきだったと思います．詳細な計画を立案しないやり方は良い点もあるので否定しませんが，リスクとして認識し，常に監視・コントロールすべきであったと思います．

(3)プロジェクトメンバが，自主的にプロジェクトマネジメントし，プロジェクトを成功に導いたと評価します．プロジェクト開始時に役割分担を明確にしており，プロジェクトメンバのプロジェクトマネジメント活動の比重が高いという計画で進んでいたのであれば，これは高く評価することができます．しかしながら，実際にはそうではなかったと推定します．

(4)PMとプロジェクトメンバには，十分なコミュニケーションがなかったと評価します．
ＧＰＳつきケータイからの地域ＳＮＳへのアクセス支援システムを開発した．クライアントの初期ニーズではないものを作ったように受けとれた．実際は，どうだったのか．クライアントがきちんと要求をださなかっただけなのか．あるいは，クライアントとのネゴシエーションの成果なのか．いずれであるか（も大事であるが）より，そうした点をきちんと把握し，プレゼンにおいて説明しきれていない点が気になる．また，スケジューリングをＰＭまかせにしていたことを十分承知し，反省していた点は評価できる．プレゼンテーション自体はよくできており面白かった．ただ，報告者の覇気が感じられず，残念である．
・運用に係るピーク，キャパシティ，アクセス数の増減など要素をもう少し深く検討するとよいように思いました．

・ドキュメント類は，その作成目的が理解できていて，納得できるものでなければプログラム作成に直接つながらないものについては，作るのがいやになります．ただ，システムは作ってからの方が手間のかかることが多く，できるだけ完成後の，変更改定に対応したドキュメントを残しておくことが必要です．完成後どのようなときにシステムに手をいれることになるか考えて，そのためのドキュメントを作っておくことは必要でしょう．作っているときのため以外のドキュメントも考えてください．

・ちなみに，ドキュメントもお金をもらって作るものです．エンタープライズ系システムでは当然のことながらドキュメントの作成量で開発コストが違ってきます．
このチームはモチベーションが高いということであったが，学生はどこまで愉しめたのだろうかと思います．このチームの滑り出しはモチベーションが低いという問題を抱えていましたが，それをクライアントに対する受身の姿勢から提案するという主体的に提案する姿勢に転換した事をきっかけにしてコミュニケーションも円滑になったとの報告です．しかし，学生たちのレポートを読むと，1月5日の打合せが2泊3日の合宿になってから意識が高まったが，それまではモチベーションが低い事が問題であったと読み取れます．これまでの間に，PMがとった処置とその効果が気にかかるところですが，残念ながら学生レポートからはPMの存在が見えてきません．余裕あるという誤った思い込みよってスケジュール遅延を招いたのは，プロジェクトの進捗を定量的にみていなかったことの証でしょう．
最後には和解できたとのことであるが，全体を通してチームプレイが悪いなか，このレベルまでできたことはいい．要件をシステム開発者がクライアントに提示していることは，良い．
体験レポートおよび発表方法が他プロジェクトとはどこか違うと感じ，開発成果よりもい「このプロジェクトのチームワークはどうだったのだろう？」「PMとメンバの意思の疎通は？」ということが気になりました．プロジェクトの結果として，一定の成果が得られて，課題も明確になったとのことで，地域のポータルサイトとして多くの人々が活用するサイトに発展していくよう，継続的にサポートしていけると良いと思いました．

satoimo

記事投稿支援システム『里撮』の開発

『里撮』イメージ

プロジェクトの活動概要

中間成果物

最終成果物

メンバー

メンバーの声

ソフトウェアの規模

工数・スケジュール

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

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