4hands

名前	役割	所属
江木典之	PM	大手IT企業I社
安藤亮一	学生メンバー	環境情報学部3年
向吉学	学生メンバー	環境情報学部3年
真野恵理子	学生メンバー	環境情報学部2年

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

システムの開発範囲は？　開発範囲の規模は？　開発メンバーの能力を考慮した所要時間の見積もりは？　通常の予約システムと同じような内容 -そのままで作成するのか？ -何か拡張機能(or工夫)を盛り込むのか？将来を考慮した今回の計画方針はどうなっているのか？
クライアントの要求を満たすことは，目的を実現することであり，手段にとらわれると見失います．また論理的なアプローチでフィージビリティをチェックせずに物を作ることは危険です．このようなプロジェクトの落とし穴に落ちないようにPMは学生を指導して下さい．
きちんとマーケティングしている点は評価できる．初めてのPM，初めてのチームリーダー(複数回参加者) 初めてのプロジェクトとしては最適な規模，テーマだと思う．PMのしゃべりすぎている気がします．学生との共同プロジェクト特有のリスクを述べてるつもりだろうが，個々の理由が学生であることに起因しているだけで，リスクそのものは通常のプロジェクトと変わらない気がする．仕様書中，｢たかくさき｣と｢高草木｣が混在しているが，これは意図的か？　つまり用語の統一は意識されているか？
お客様の要求をユースケースでまとめ，スコープをきちんと定義し，合意を得ているのはとてもよい．実際に設計を行っていく際にはスコープ外の要求も考慮して，後々拡張できるようにしていくとよいと思います．
プロジェクトの目的が明確でよかった．開発プロセスの説明が解かり易かった．PM依存度の高いように感じられた．
・予約表の公開については，表示項目に注意してください．例えば，プライバシー保護の観点からは，予約者氏名は，院の人には見えるようにし，外からのアクセスでは見えないように作る必要があります．そのあたり，しっかり詰めてください．
・予約変更で他人の予約を変えてしまわないようにする工夫も必要になります．
・要件を聞いていると，一つの情報管理ファイルに対して，院での入力は，普通の会社で言えば営業窓口入力，ＴＥＬ分はコールセンター入力，加えてＷＥＢ入力があるといったところですね．同時間枠に対する，同時アクセスの排他制御の設計をしっかりやってください．
・キャンセル対応，誤入力，誤消去，復活といった各入力方法毎にオペレーショナルな分野での必須対応事項をしっかり検討してください．
・悪意に対する対応策は不要でしょうか？
・障害対応設計が気になります．バックアップ，リカバリー，復活できなかった予約情報対策，こういった障害対策を発生時誰がやるのかの検討，等システムかすると人間がやっていたとき以上に手間のかかる局面が発生しますから，あとでもめないように，あらゆる状況をシミュレートし対策を決め，必要な作りこみ，教育，マニュアルの作成をお願いします．
・キャパシティ設計をお願いします．あわせて古い情報の削除についても決めてください．
・蓄積情報の個人情報保護も検討してください．
準junシステムと同様，この予約システムは歯医者の予約システムにも応用できる．携帯から予約できたり，予約状態が確認できれば歯科医，患者双方に便利なはずである．会場でも述べたが，google calendarなど既存の予約システムの応用は考えなかったのか．satoimoのコメントでも述べたが，既存システムが利用できたら，もっと早く安く開発できるかもしれない．その可能性をどれだけ事前に調査したのだろうか．
至極｢真っ当な｣プロジェクトであって，だからこそプロジェクトの目的意識が問われると思います．普通のものを普通に作っても，クライアントにとっては無料サービスなのであれば文句を言う筋合いは無い，ということになるでしょうけれども，それでは物足りないような気もします．何か面白い新機軸を発見してくれることを祈っています．
(1)学生用の開発プロジェクトとしては手頃で扱い易い．良題材．
(2)実現は問題ないと思われるが，運用(利用)において予約機能の実現が問題となる．
1.予約機能を実現対象外としている．開発においては，試験を実施し難くしていい．運用においては，入手の手間が掛かり，面倒．
2.予約機能自体はこれまでも会合調整などで実現して来ているから，それを参考にした実現法を考えるべきである．現実には排他制御や衝突の問題が難しいが，基本機能として実現すべきである．
3.開発型は，螺旋(反復)型であるが，リリース♯2の機能(UC05)の選定理由が不明である．リリースk＃1で3機能(UC01，02，05)を実現し，♯2で予約(UC05)あるいは逆にUC03→UC01，02， 05とすべきであろう．
まず，プロジェクト＆システム名称(ネーミング)が，その由来から，納得，とても気に入りました．発注元が学外の方，使用ユーザも，発注元およびその患者様ら(一般)ということ．発注元の現状の問題をシステム化で解決しようというものであり，是非，解決に寄与して，ご満足していただけるシステム提供を期待したい．そのために，早期にプロトタイプで，試用いただき，使い勝手を確認する，これは重要と認識．又，一般ユーザということから，ユーザも気づかない仕様上の問題も早期に気づいていただき，反映いただくことを期待する．

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

顧客満足度や計画の予実績のずれのなさ，メンバーのモチベーションという意味で非常に成功したプロジェクトに思います．
良いプロジェクトだったと思います．また，日常生活に近いテーマに感銘を受けました．クライアント様のコメントも大変良好だったと感銘でした．
予約管理システムは製品もサービスも多数存在する．携帯，アプリとして実装した事の優劣は，判断する必要を感じる．動作する機種や確認等，通常ならコストがかかる部分がどうなっているのか気になる部分である．反復型開発では，メリットだけでなくデメリットもあるので，デメリット部分も聞いてみたい．クライアントの満足度が高く，メンバーの満足も感じられる．
・発表の仕方：大変うまい
・全体にうまくいきすぎている．きちんとしている．プログラムも使用されていていうことはない．

・開発規模も適正である．
・学生が優秀なのだとおもうが，PMが優秀すぎたのではないだろうか．
・もっとあれこれ失敗して欲しかった．5点満点で4．8点．順位1．
計画段階からよく考えて準備ができていると思います．「成功要因は何か？」をまとめて，他のプロジェクトにも移転できるようにすることが大切だと思います．
1．開発の手順
オーソドックスに着実に進めている様です．

2．（読めない）インターフェイス
"ユニバーサルデザイン"の考慮が重要です．
インタフェースの改善によって，人間系（ユーザ）と機械系の協調ができたシステムになったように思います．使い手と作り手の思いの共有ができたことも良かったと思います．良いシステムとはユーザが使いたくなるようなシステムと言えそうですね．成功，おめでとう．
【総合評価】
4handsプロジェクトは，A評価（継続的に使われている）と評価します．

【詳細な気付き事項】
(1)今回の成功の1番の要因は，スコープ定義にあったと思います．“お客が予約できない“という範囲にスコープを絞りこんだことを高く評価します．

(2)プレゼンテーションにおいて，最初にデモを持ってきたところより推測するに，プレゼン練習及び評価を繰り返し実施したものと推測します．1番よいプレゼンだったと思います．

(3) アンケートの作成方法を反省している点もすばらしいと思います．単なる成功に終わらず，次の課題を見つけた点で，教育プロジェクトの成果もあったと評価します．
施術院の予約管理システムを新たに開発した．プロジェクト管理としては，反復型開発を行ない，３つのリリースを顧客に提示した．エンドユーザむけの小規模システム開発としては，オーソドックスな手法である．また，ＰＭがとてもしっかりしているという印象である．問題サイズがちょうどよかったという点も見逃せない．質疑応答，ならびに，クライアント本人からのコメントにより，事情がよくわかった．こうしたクライアント側の事情をいかに把握し，その変化をいかにひきだしたのか，そうした点をプレゼンテーションにおいても説明してほしかった．
・システムは，システムが実現する世界の内容で価値が決まります．今回のシステムは，使いやすく，ユーザビリティがよく考えられており，真に価値あるシステムになったようですね．

・ユーザーと開発者の役割分担がよく理解され，やらなくてはならないことをうまく共同して進められたシステム開発は成功する確率が高いものです．発注者はシステム開発を知らない，開発者は業務を知らない．これが，一般的なシステム開発の構図です．よく克服しました．学生時代のこの経験は，大変貴重なものに思えます．大切にしてください．

・人物金時間…，システム開発はリソースとの戦いです．今回のシステム開発は限られたＰＢＬのリソースの中で見事なプロジェクトマネジメントが実現できたように思います．
開発プロジェクトとしては，ユーザの評価もたいへん高く，成功したプロジェクトの典型例であろう．学生側にプロジェクト失敗の不安がなく，モチベーションも高かったことが全てを物語っています．特に，クライアントとのコミュニケーションの質が変わったことが，貴重な体験になっています．
クライアントからの評価も良く，良くできていると思います．一点，今後の運営はどうなのでしょうか．同じPBLを主催・企画した立場から，企業のプロジェクトと大学等のプロジェクトの違いは，運用・メインテナンスの点です．大学，特に学生さん主体のプロジェクトの場合，運用・保守は余り気にしません．今回の場合，作りました．しかし，運用・保守は知りませんでは済まないのでは．
とにかく，ユーザであるたかくさき寮術院様にたいへん満足頂いていることそれを知った，近所の美容院等からも引き合いがでていることは本当に素晴らしいと思います．PM，メンバ，PMO，皆様の大きな成果と認識しました．発表でユーザの生の声「途中まで要望が理解されず諦めはじめていたこと．」「松澤さんからの『使い難いものは無理に使うことはない』という助言から開発側にNOと伝えることができ，真のコミュニケーションの構築に繋がったこと」，大変，貴重なお話を拝聴でき，ありがとうございました．

4hands

たかくさき療術院予約支援システム

たかくさき療術院予約支援システムイメージ

プロジェクトの活動概要

中間成果物

最終成果物

メンバー

メンバーの声

ソフトウェアの規模

工数・スケジュール

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

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