「予定合わせ支援ツール」
イベント参加者の予定の調査、日程の通知、出席確認などを簡単に行うことができるWebアプリケーション。 幹事の情報収集、集計の労力を軽減し、開催日の決定を迅速に行うことができる。
『フリーダム』イメージ
※クリックすると拡大画像が表示されます
開発の背景
従来の予定あわせは，メールかスケジュール表に書き込むことが多かった。しかし、メールの場合は回答率の低さや書式が統一されていないことが、スケジュール表に書き込む場合は書き込む手間や予定の管理の面倒さが問題であり、幹事が非常に苦労していた。この問題を解決するために、記入・把握・管理が容易であり、幹事が行う予定合わせを支援するようなツールを開発することにした。
開発の目的
次の機能を実現することで、予定あわせにおける幹事の手間を軽減させること。
- 参加者の予定を調査、集計をツールによって自動化する
- 参加者への日程決定の通知、参加者への出欠確認を自動化する
- データ
-
メンバー
名前 役割 所属 猪野尾丈晴 PM 株式会社ネクストウェア 藤原育実 学生メンバー 環境情報学部4年 野上大輔 学生メンバー 環境情報学部4年 向吉学 学生メンバー 環境情報学部3年 メンバーの声
スケジュール
予定されたスケジュール
開発スケジュール（実績）- 4月：要求分析
- 5月：要件定義、詳細設計
- 6月：詳細設計、実装（第I期）
- 7月：運用試験、ユーザレビュー、実装（第II期）、ユーザレビュー（II）
- 4月：要求分析
- 5月：要求分析、要件定義
- 6月：要求分析、要件定義、詳細設計
- 7月：実装（第I期）、運用試験、ユーザレビュー
○要求分析・要件定義での試行錯誤が多く、反復型の開発を目指していたがI期の段階で時間切れとなりました。
ソフトウェアの規模
Java関連- 全ステップ数（空行・コメント含む）：4,550
- 有効ステップ数（空行・コメント以外）：3,269
- コメント行数：1,281
- コメント含有率：28%
- 全ステップ数（空行・コメント含む）：2,122
- 有効ステップ数（空行・コメント以外）：1,989
- コメント行数：133
- コメント含有率：5%
作業時間
メンバー個人ごとの詳細な作業時間は不明ですが、3人で合計300時間強です。
- 評価
-
成果発表会の様子
評価委員からのコメント
- クライアントが自分自身という事で、最後までどんなものを作るか迷いが在ったように感じられる。時間的な制約で難しかった思うが、既存のサイトにはない、ユニークな機能を１つでも入れて欲しかった。（重要人物の設定というのはあったが、もう一つ工夫が欲しい）
- このシステムについては、実社会で非常に利用度が高いと感じる。会社の大小に関わらず、会議を開く、関係者を集める等の手段は、神経を使っても足りない事はない。
効率よく、趣旨を伝え、案内が出来る事が可能になれば、素晴らしいコミュニュケーションの場になると思います。一般的に使えるソフトにするには、実際に学生、実務で使い改良を重ねて下さい。汎用性は高い。
欠席者の意見聴集出来る事（メールでいい）集合場所の情報（地図、アクセスなど）会議資料の回収等の機能が欲しい。 - レビューをやったとのことですが、ユーザインタフェースや使い勝手を中心としたものになっているのではないかと感じました。
設計や仕様のレビューをきちんと行うと、教育効果も高まるのではないかと思いました。（ソフトウェア工学的にもそのほうが良いと思います） - プロジェクトの目標にソフトウェア工学や情報システムについて学ぶということがあげられていますが、ソフトウェア開発における品質の作り込みについての活動が不十分だったのではないでしょうか。「PMにレビュをお願いした」という回答がありましたが、本来は自分たちでレビュをきちんと行うことが必要だったと思います。どちらかというと作成することに集中していて、学ぶべき目標を達成していないのではないでしょうか。
発注者と開発者は同じであった、というの件については、私も学生の認識がおかしいと思いました。授業で、本質的なことが学ばれていないのではないか、と思います。 - 発注者＝開発者に関わらずスムースに進まなかったのは何故？
要求定義がうまくいかなかったのか？
ユーザは要求を持っていると思うのは錯覚？
殆どのユーザは要件を言えない。ITべンダーがホームページを作ろうとして、Webデザイナーにキッチリ要件を言えるかどうか？
１回目レビューはバグを潰していないのに行なったようである。レビュアーに失礼である。レビューの日程を変えるか日程に合わせ頑張るか。 - 1．仕様面
（1）全体に○をつける機能は不要で、最初から全てに○をつけておくべき。
（2）プロジェクトとしてやさしすぎるテーマではないか。しかし、バグが多いとか、反復が出来なかったと報告があるので適切なレベルだったかもしれない。
2．運営面
（1）工程遅れの原因が、要求定義にあると分析したのは立派。
（2）シーケンス図を作ったが、あまり使わなかったというのは良い。（自分で意味があると思うものを使うということで） - 動機が弱いです。なぜソフトウェアを作らないといけないかが見えてこない（たぶんプロジェクトメンバーにも見えていない）感じがします。「問題があるからソフトウェアで解決する」というよりも、「ソフトウェアを作らないといけないから問題を作った」ように見えます。（実際にそうであったとしても「そう見えてしまう」ことは問題です）
発表質疑で話題になった「開発者と発注者が同じ」点についても、「同じ」というよりも「発注者がいない」状態だったのだろうと思います。NEEDSがないから、適当な仕事をしてしまうのです。 - ・ユーザは学生だけですか。
・人数は何名まで利用可能ですか。
（人数が多くなると、決定のプロセスが種々考えられる。決定プロセスの選択が必要かもしれない）
・要件分析が一番重要な分野のアプリケーションだと考えます。 - システムの利用対象者を一般に広げるために、今回のシステムの機能をどのように再利用できるかまで考えることができれば、このプロジェクトは成功です。このように小さなテーマでも、扱い方によって、情報システムのいろいろな側面に対応することができ、教材や知見をたくさん蓄積できると思いました。
- ・唯一発注者のいないプロジェクトということで、ソフトウェアの要求を定義することに苦労しているようだった。しかし、なぜ発注者がいないと要求定義に苦労するかという原因について、深く掘り下げられていない点が残念だった。
・今回は、発注者がいなくても、自分たちが作りたいシステムに対して思い入れがあれば、システムの規模が大きくなることはあっても、要件が不明確になることは無かったと思う。