4hands

4hands
予約支援システム開発プロジェクト
PM
江木典之
環境情報3年向吉学
環境情報3年安藤亮一
環境情報2年真野恵理子
目次
プロジェクト概要・
デモンストレーション
苦労点・工夫点
まとめ
PMからの報告
プロジェクト概要
クライアントの紹介
現状と要望
デモンストレーション
提案内容の検討
提案内容
クライアントの紹介
たかくさき療術院
大岩研究室行き付けの療術院
客一人に対して二人でマッサージ（4つの
手）
予約状況を公開したい
クライアントの紹介
プロジェクト概要
クライアントの紹介
現状と要望
デモンストレーション
提案内容の検討
提案内容
現状
予約方法（患者様）
電話、メールで予約する
予約したい時間が空いてるかは連絡しないと分
からない
管理方法（高草木様）
紙の予約表
時間表に名前を書き込む
出張時のために携帯にも入力
高草木様の要望
予約状況を公開したい
アナログ（現状の予約表）の使い勝手
を保ちたい
携帯で予約の管理をしたい
療術院の情報を公開したい
Webを通して治療相談や商品の販売を
したい
プロジェクト概要
クライアントの紹介
現状と要望
デモンストレーション
提案内容の検討
提案内容
デモンストレーション
予約状況の管理（携帯アプリ）
予約状況の参照（PC）
予約状況の参照（携帯）
プロジェクト概要
クライアントの紹介
現状と要望
デモンストレーション
提案内容の検討
現状の問題点
全体構想と開発範囲
患者様へのアンケート
提案内容
現状の問題点
患者様は実際にやり取りするまで予約
の空き状況が分からない
高草木様は患者様に空き状況を聞かれ
る度に教えなければいけない
紙の予定表と携帯のスケジュール、両
方に予約情報を入力しなければならな
い
システム要件
たかくさき療術院の予約状況を患者様
が参照し、希望時間の空き状況を確認
できるようにすること
携帯の入力を簡易に実施できるように
すること
全体構想と開発範囲
アンケートの対象・目的
対象
たかくさき療術院の患者様
人数
12人
目的
本当に患者様が利用してくれるのか
もし使われないようであれば、開発方針を再考す
る必要がある
アンケート項目
携帯・PCを持っているか
インターネットを利用しているか
現在の予約方法に対する意見
その他で利用できたらいいと思うサー
ビス
アンケート結果
12
PC
12
PC
10
携帯
8
8
6
10
携帯
6
携帯
4
4
2
2
0
0
インターネット
PC
メール
PC 携帯
携帯
PC
PC
携帯
利用したい
利用したくない
余計面倒くさい
その他
プロジェクト概要
クライアントの紹介
現状と要望
提案内容の検討
提案内容
提案内容
予約支援システム
高草木様が管理する予約状況を患者様がイ
ンターネットで参照できるシステム
システムの内容
予約状況の管理
利用者：高草木様
利用環境：携帯
概要：現在の療術院の予約状況と高草木様の予定を更新す
る
予約状況の参照
利用者：患者様
利用環境：PC・携帯
概要：現在の予約の空き状況を確認できる
リリース計画
反復型開発による3度のリリース
推敲、作成、移行フェーズの終わりにそれぞれリ
リースを行う
クライアントがシステムのイメージを早期につか
むことができ、クライアントの意見を取り込むこ
とができる
リリース#1
プロトタイプとしてお試し用に作成した試作版
リリース#2
リリース#1のフィードバックを基に改善した評価版
本番リリース
スケジュール(計画)
10月
11月
12月
4つのフェーズからなる反復型開発を採用
2
9
16
23
30
6
13
20
27
4
11
18
1月
25
1
8
15
2月
22
29
5
中間発表
プロジェクト
計画の確定
現行業務調査
提案書の承認
提案書
の作成
19
最終発表
推敲
方向付け
12
作成
リリース#1
リリース#1のリリース#1の
設計/開発
テスト
移行
移行方針の
確定
設計 / 開発
リリース#2
テスト
移行完了
移行
全体構想の立案
アーキテクチャの確定
プロジェクト対象範囲
と開発方針の確定
技術アセスメント
移行方針の検討
移行の準備
操作ガイドの
作成
作成フェーズの計画作成
目次
プロジェクト概要・
デモンストレーション
苦労点・工夫点
まとめ
PMからの報告
苦労点・工夫点
開発プロセス
アンケート
アーキテクチャの確定
携帯アプリの開発
携帯アプリのインターフェース
携帯の参照画面
たかくさき療術院HP
開発プロセス
反復型のプロジェクト
クライアントとの認識の差を縮めることが
できる
早い段階でクライアントにシステムの形を
イメージしてもらえる
より具体的な意見を聞けた
アンケート
説明がお客様への説明ではなくたかく
さき様への説明
項目が全て記述式
答える側のことを考えていなかった
アーキテクチャの確定
予約の入力は携帯アプリ
携帯ブラウザ、NintendoDS、既存のアプリケー
ションなどを比較検討
⇒コストがかからず、自由度の高い携帯アプリを使用する
ことを提案
予約状況の参照はPHP
システム規模があまり大きくない
メンバーが経験あり
データはテキストファイルで保持
データ量が少ないため
携帯アプリの開発
携帯キャリア独自のjava
GUIの作成も初めて
エミュレータと実機での動作の違い
携帯アプリのインターフェース
シンプルに見易く
時間の入力に文字入力キーを使わない
ようにした
Before
After
携帯参照画面
記号による表現では無理がある
表を画像にして表示することで解決
Before
After
たかくさき療術院HP
デザインのドラフト版が決定するまで時間が
かかった
案をいくつか用意し良い部分をマージ
クライアントの意見を多く取り入れるように
ヒアリングを多く行った
見易さの工夫
目に優しい色の組み合わせ
パソコンの設定によっては色合いが少し変わってしまう
場合がある
ナビゲーション(メニューバー)を大きく見易く
目次
プロジェクト概要・
デモンストレーション
苦労点・工夫点
まとめ
PMからの報告
まとめ
開発プロセスの違いによる利点を学んだ
プロジェクト成功に向けてモチベーションが
あがった
文章の作成において、いかに今まで読む側の
ことを考慮できていなかったかを痛感
実際に使ってもらえるものを作成でき、クラ
イアントの喜ぶ顔を見ることができた！
目次
プロジェクト概要・
デモンストレーション
苦労点・工夫点
まとめ
PMからの報告
報告内容
プロジェクトの実績
スケジュール実績
開発規模（画面数、ステップ数）
作業時間、EVM
Lesson & Learned
スケジュール実績
ベースライン
実績
開発規模
画面数
予約情報の入力(携帯アプリ)：3画面
予約情報の参照
携帯ブラウザ用：2画面
Webブラウザ用：5画面（予約情報参照以外のWebサイトを含む）
ステップ数(NCSS：コメントを除く)
Java(携帯アプリ)：1119ステップ
PHP(PCブラウザ)：604ステップ
実績工数(単位:時間)
フェーズ
方向付け
推敲
作成
移行
合計
計画
実績
差異
116
101
186
116
143
87
0
42
-99
51
19
-32
453
364
-89
※ 方向付けフェーズの作業
時間実績は概算としている
EVM
PV,EV,AC,EAC推移
500.0
方向付け
推敲
作成
移行
450.0
400.0
350.0
300.0
250.0
200.0
PV(point)
150.0
EV(point)
AC(point)
100.0
BAC(point)
50.0
1/
10
1/
17
1/
24
1/
31
1/
3
0.0
9/
27
10
/4
10
/1
1
10
/1
8
10
/2
5
11
/1
11
/8
11
/1
5
11
/2
2
11
/2
9
12
/6
12
/1
3
12
/2
0
12
/2
7
p
o
i
n
t
Lesson & Learned
反復型開発の利点
最初の反復でメンバーのスキルが把握できる
推敲フェーズでは，アーキテクチャの確定に加え，お客様からGUIに関す
る要望を多くいただけた
プロジェクトマネジメント
しっかりとした計画が重要
計画を立てるだけでなく、計画と進捗状況をメンバーと共有すること
Backup
参考
危機感(遅れ)を共有するのに効果的であった方法
例えば、現在12月15日とします
コーディング
統合テスト
運用ガイド
12月20日
1月8日
ユーザーテスト
1月15日
サービスイン
1月31日
⇒ローリングバックという考え方
CCPM(クリティカルチェーンPM)のプロセスの一つ
ご清聴ありがとうございました。

Download Report