4hands 予約支援システム開発プロジェクト

Presentation on theme: "4hands 予約支援システム開発プロジェクト"— Presentation transcript:

1 4hands 予約支援システム開発プロジェクト
PM　　　　　 江木　典之 環境情報3年　向吉　学 環境情報3年　安藤　亮一 環境情報2年　真野　恵理子

2 目次 プロジェクト概要・ デモンストレーション 苦労点・工夫点 まとめ PMからの報告

3 プロジェクト概要 クライアントの紹介 現状と要望 デモンストレーション 提案内容の検討 提案内容

4 クライアントの紹介 たかくさき療術院 大岩研究室行き付けの療術院 客一人に対して二人でマッサージ（4つの手） 予約状況を公開したい

5 クライアントの紹介

6

7

8 プロジェクト概要 クライアントの紹介 現状と要望 デモンストレーション 提案内容の検討 提案内容

9 現状 予約方法（患者様） 管理方法（高草木様） 電話、メールで予約する 紙の予約表 出張時のために携帯にも入力
予約したい時間が空いてるかは連絡しないと分からない 管理方法（高草木様） 紙の予約表 時間表に名前を書き込む 出張時のために携帯にも入力 ヒアリングいって現状きいたよ

10

11 高草木様の要望 予約状況を公開したい アナログ（現状の予約表）の使い勝手を保ちたい 携帯で予約の管理をしたい 療術院の情報を公開したい
Webを通して治療相談や商品の販売をしたい

12 プロジェクト概要 クライアントの紹介 現状と要望 デモンストレーション 提案内容の検討 提案内容

13 デモンストレーション 予約状況の管理（携帯アプリ） 予約状況の参照（PC） 予約状況の参照（携帯）

14 プロジェクト概要 クライアントの紹介 現状と要望 デモンストレーション 提案内容の検討 提案内容 現状の問題点 全体構想と開発範囲
患者様へのアンケート 提案内容 検討の流れを説明しよっか

15 現状の問題点 患者様は実際にやり取りするまで予約の空き状況が分からない 高草木様は患者様に空き状況を聞かれる度に教えなければいけない
紙の予定表と携帯のスケジュール、両方に予約情報を入力しなければならない

16 システム要件 たかくさき療術院の予約状況を患者様が参照し、希望時間の空き状況を確認できるようにすること
携帯の入力を簡易に実施できるようにすること

17 全体構想と開発範囲 開発範囲の策定は高草木さんの要望が強かったものを優先して決めたよ

18 アンケートの対象・目的 対象 人数 目的 たかくさき療術院の患者様 12人 本当に患者様が利用してくれるのか
もし使われないようであれば、開発方針を再考する必要がある

19 アンケート項目 携帯・PCを持っているか インターネットを利用しているか 現在の予約方法に対する意見 その他で利用できたらいいと思うサービス

20 アンケート結果 ・全員が携帯かPCを所持 ・ほとんどの人がネットとメールを利用 ・利用したい人が半数以上
・面白かったのが携帯でネットは少なかったが、携帯でシステムを利用したい人が多かったので、いんじゃないかな

21 プロジェクト概要 クライアントの紹介 現状と要望 提案内容の検討 提案内容

22 提案内容 予約支援システム 高草木様が管理する予約状況を患者様がインターネットで参照できるシステム

23 システムの内容 予約状況の管理 予約状況の参照 利用者：高草木様 利用環境：携帯 概要：現在の療術院の予約状況と高草木様の予定を更新する
利用者：患者様 利用環境：PC・携帯 概要：現在の予約の空き状況を確認できる

24 リリース計画 反復型開発による3度のリリース リリース#1 リリース#2 本番リリース
推敲、作成、移行フェーズの終わりにそれぞれリリースを行う クライアントがシステムのイメージを早期につかむことができ、クライアントの意見を取り込むことができる リリース#1 プロトタイプとしてお試し用に作成した試作版 リリース#2 リリース#1のフィードバックを基に改善した評価版 本番リリース

25 スケジュール(計画) 4つのフェーズからなる反復型開発を採用 方向付け 推敲 作成 移行 10月 11月 12月 1月 2月 2 9 16
23 30 6 13 20 27 4 11 18 25 1 8 15 22 29 5 12 19 中間発表 最終発表 方向付け 推敲 作成 移行 リリース#1 リリース#2 移行完了 プロジェクト計画の確定 提案書の承認 移行方針の確定 提案書 の作成 リリース#1の設計/開発 リリース#1のテスト 現行業務調査 設計 / 開発 テスト 移行 全体構想の立案 アーキテクチャの確定 移行方針の検討 移行の準備 プロジェクト対象範囲と開発方針の確定 操作ガイドの 作成 技術アセスメント 作成フェーズの計画作成

26 目次 プロジェクト概要・ デモンストレーション 苦労点・工夫点 まとめ PMからの報告
では、このシステム開発での苦労点や工夫点について説明させていただきます。

27 苦労点・工夫点 開発プロセス アンケート アーキテクチャの確定 携帯アプリの開発 携帯アプリのインターフェース 携帯の参照画面
たかくさき療術院HP このような苦労点・工夫点

28 開発プロセス 反復型のプロジェクト クライアントとの認識の差を縮めることができる 早い段階でクライアントにシステムの形をイメージしてもらえる
より具体的な意見を聞けた

29 アンケート 説明がお客様への説明ではなくたかくさき様への説明 項目が全て記述式 答える側のことを考えていなかった
アンケートの対象がお客様なのに、説明がたかくさき様への説明になってしまっていたということや、項目がすべて記述式になっていたことなど、答える側のことを考えていなかったという反省点が挙げられます。

30 アーキテクチャの確定 予約の入力は携帯アプリ 予約状況の参照はPHP データはテキストファイルで保持
携帯ブラウザ、NintendoDS、既存のアプリケーションなどを比較検討 ⇒コストがかからず、自由度の高い携帯アプリを使用することを提案 予約状況の参照はPHP システム規模があまり大きくない メンバーが経験あり データはテキストファイルで保持 データ量が少ないため 予約管理側の入力は携帯アプリを採用することにしました。これは、携帯ブラウザやNintendoDS、インターネット上などの既存のアプリケーションなどを比較検討した結果、やはり携帯アプリがコストがかからず、表現や操作性などの自由殿が高いということで、採用することにしました。 予約状況の参照はPHPを使用

31 携帯アプリの開発 携帯キャリア独自のjava GUIの作成も初めて エミュレータと実機での動作の違い
理解するのにとか、技術調査にちょっと苦労した GUIの作成も初めてだったので、どうやって作るかなども悩んだ エミュレータでは動くが実機では動かず、落ちてしまう。原因が分からなくて苦労した。結局実機側のバグの問題だと分かり、解決した。

32 携帯アプリのインターフェース シンプルに見易く 時間の入力に文字入力キーを使わないようにした

33 Before After

34 携帯参照画面 記号による表現では無理がある 表を画像にして表示することで解決 Before After

35 たかくさき療術院HP デザインのドラフト版が決定するまで時間がかかった 案をいくつか用意し良い部分をマージ
クライアントの意見を多く取り入れるようにヒアリングを多く行った 見易さの工夫 目に優しい色の組み合わせ パソコンの設定によっては色合いが少し変わってしまう場合がある ナビゲーション(メニューバー)を大きく見易く

36 目次 プロジェクト概要・ デモンストレーション 苦労点・工夫点 まとめ PMからの報告

37 まとめ 開発プロセスの違いによる利点を学んだ プロジェクト成功に向けてモチベーションがあがった
文章の作成において、いかに今まで読む側のことを考慮できていなかったかを痛感 実際に使ってもらえるものを作成でき、クライアントの喜ぶ顔を見ることができた！

38 目次 プロジェクト概要・ デモンストレーション 苦労点・工夫点 まとめ PMからの報告

39 報告内容 プロジェクトの実績 スケジュール実績 開発規模（画面数、ステップ数） 作業時間、EVM Lesson & Learned

40 スケジュール実績 ベースライン 実績

41 開発規模 画面数 ステップ数(NCSS：コメントを除く) 実績工数(単位:時間) ※ 方向付けフェーズの作業時間実績は概算としている
予約情報の入力(携帯アプリ)：3画面 予約情報の参照 携帯ブラウザ用：2画面 Webブラウザ用：5画面（予約情報参照以外のWebサイトを含む） ステップ数(NCSS：コメントを除く) Java(携帯アプリ)：1119ステップ PHP(PCブラウザ)：604ステップ 実績工数(単位:時間) ※ 方向付けフェーズの作業時間実績は概算としている

42 EVM 方向付け 推敲 作成 移行

43 Lesson & Learned 反復型開発の利点 プロジェクトマネジメント 最初の反復でメンバーのスキルが把握できる
推敲フェーズでは，アーキテクチャの確定に加え，お客様からGUIに関する要望を多くいただけた プロジェクトマネジメント しっかりとした計画が重要 計画を立てるだけでなく、計画と進捗状況をメンバーと共有すること

44 Backup

45 参考 危機感(遅れ)を共有するのに効果的であった方法 ⇒ローリングバックという考え方 CCPM(クリティカルチェーンPM)のプロセスの一つ
サービスイン 1月31日 例えば、現在12月15日とします コーディング 12月20日 統合テスト 1月8日 ユーザーテスト 運用ガイド 1月15日 ⇒ローリングバックという考え方 CCPM(クリティカルチェーンPM)のプロセスの一つ

46 ご清聴ありがとうございました。