劇団おでんくん 最終発表会 ＰＭ 鈴木 熊谷 学生 村上 河野 清水 将志 哲孝 季穂 仁奈 啓太郎 目次 プロジェクト概要 活動内容 デモンストレーション 学習成果 プロジェクトマネジメント実績報告 ビデオ プロジェクト概要 プロジェクト体制 背景 システム提案 目的・目標 プロジェクト体制（１） 期間 ・2007/10/4～2008/1/31 人員 ・ＰＭ ・ＰＮ（ﾌﾟﾛｼﾞｪｸﾄ･ﾅﾋﾞｹﾞｰﾀｰ） ・学生3名（I期目x1名） 劇団おでんくんの特徴 ・ＰＭが、PM・ＰＮの2人体制 ・学生が全員新規履修者（javaのﾌﾟﾛｸﾞﾗﾐﾝｸﾞ経験あり） でシステム開発がはじめて プロジェクト体制（２） 顧客 荒木氏 ＰＭ コンサルタント 鈴木将志 大岩研究室 ＰＮ ユーザー 小塚氏 劇団員 熊谷哲孝 メンバー メンバー メンバー 村上季穂 河野仁奈 清水啓太郎 プロジェクト背景（１） 大岩研究会所属の荒木恵さんが所属する劇 団（劇団員約10名、年2回ほど公演）のチケッ ト予約管理が現在、劇団員同士のメールとノ ートの手作業にて行われている ↓ 非常に手間がかかってしまっている ↓ システム化によりチケット予約管理の負担を減 らすことができないか？ プロジェクト背景（２） 小劇団の、劇団内部向けチケット予約管理システム 顧客：荒木恵さん ユーザ：小塚早希子さん、劇団員のみなさま 背景 チケットノルマ制 チケットを決められた枚数それぞれ団員が買い取り、 売った額だけ本人にお金が戻る 多様な販売方法 前売り、取り置き、当日精算、チケットのみ当日渡しなど・・・ 変更・キャンセル・曖昧な情報も多い 例：前売り 団員 事務 ① ② チケット 金 客 例：取り置き ⑤金の返却 団員 事務 ②メール ①約束 チケット ④劇場に行く CHECK! 河野で す メール・ノートに書く内容 金 ○担当者 ○客の名前 ○日付 ○枚数 ○いくらで売るか ③書き込み 客 ノート つまり… あいまい、 不十分なことも！ ○担当者 ○客の名前 ○日付・○枚数 ○いくらで売るか メール 依頼 客 確認・・・ 団員 書き込み ノート 事務 送信 システム 印刷 “とっとこ”システム 提案内容 携帯Webアプリを使用した、予約・変更・閲覧システムを提案。 従来のノート・メールに代わるものとして劇団員自身がWebに登録・変更を 行う事で、劇団員・事務員双方の負担を軽減する。 利点 劇団員 文章形態のメールを送ることに手間がかかっているが、 システム化により、少ない作業・時間で必要な情報を送ることが出来る。 変更の際、何度も事務員にメールをする心理的負担が軽減される。 事務員 メールの内容をノートに記録していた多大な時間がなくなる。 フォーマットが統一されるため、得られる情報にあいまいさや不足がなくなる。 キャンセルや変更情報も整理されて更新されるので混乱がおこらない。 劇団員としての作業の合間に記録作業を行っていたという現状があるが、 システム化によりその必要が無くなり、劇団活動に専念できる。 目的・目標 目的 劇団のチケット管理の現状と顧客の要求を分析し、シス テム化により劇団員のチケット管理を効率化し、３月以 降、実際に使ってもらえるシステムを開発すること。 目標 『携帯』という気軽さを活かし、いつでもどこでもわずらわ しくなく予約処理ができるように… 使用するのは主に劇団員なので、彼らの負担軽減を最 優先とする。 『事務員にメールを送る作業』以下の作業になるように … デモンストレーション まずは ご覧くださいませ・・・ プロジェクトの活動内容 要求分析 設計 実装 運用テスト・評価 要求分析 内容 ヒアリング 体験ワークショップ アクティビティ図作成 ユースケース図作成（顧客に依頼） 問題点 現在の販売方法を活かしながらそのままシステム化する方向で固 まっていた？ ⇒もっと冒険できたかもしれない 細かい設定で顧客・ユーザに聞いておくべきだった部分を自分達で 決めてしまった点が多かった。 ⇒調査不足から生じる問題も発生 要求が達成されていなかった部分が出てくる 要求分析 成果 図表は上手く活用できず。 どう使えばいいのか学生がわからなかった。 “分析”の難しさを知る 要求分析が十分にできていなければその後の 工程が揺らいでしまうということを学んだ。 要求分析・・・体験ワークショップ 顧客からの提案・提供 目的：実体験を通してユーザーが抱える問題を 把握する 成果：要求をまとめやすくなった その後、入力可能な画面サンプルを作成。 団員役がそれぞれ１５人程の登録作業をするの にかかったそれぞれの１５分⇒５分に 事務役がかかった４０分⇒印刷するだけ 実際に顧客にも体験していただいた。 好感触！ 設計 内容（作ったもの） 画面設計（HTMLで、アプリの簡易版作成。画面遷移含む） フローチャート ファイル相関図（実装に入ってから必要性を感じ、作成） 問題点 実装に関する設計図（クラス図・画面遷移図など）をほとんど作成し なかった。 関数ファイルとその参照の関係などがあいまいで、 実装に無駄が多くなってしまった。 成果 設計～実装の流れ、各書類が実装にどう影響するのかを知った。 実装 内容 役割分担し、それぞれの実装を進める。 スケジュールの遅れを取り戻すため、年末年始も集合 単体・結合テスト 問題点 始めに関数を作らなかった 共有できる部分を共有せず、それぞれ作成してしまった。 時間不足により、結合テストが丁寧になされなかった。 バグを残したまま、運用テストに入ってしまうことに・・・ バグの心配を招く ユーザーの使い易さの考慮不足 もっとチーム内で激論があってもよかった！？ 実装 成果 実装は完全な個人作業ではなく、 メンバー内で共有するべき事項も多い作業だと学んだ。 『使う人がいる』ことを意識することの重要性 インターフェース 『テスト』の意義・重要性 ⇒時間不足でも、雑なシステムはNG！ なんとか、完成！ 運用テスト 内容 顧客の荒木さん、ユーザの小塚さ んが所属する創作集団『必志組』 に公演を打っていただき、チケット 管理の際、システムを使っていた だく 期間 2008年1月13日（日）テスト開始 運用テスト～利用者数 公演 来場者 システム 利用者 システム 利用率 １日目 ２０ １５ ７５％ ２日目 ５ ５ １００％ ※1日目：システム登録者のうち5名が当日キャンセル、当日来場5名 運用テスト～利用者と方法 3チケット予約 劇団員 登録数 2チケット予約 A（事務員） ８ B ４ C ３ D ５ Ｅ １ ※当日キャンセル含む 1チケット予約 運用テスト～登録件数 12 10 8 6 4 2 0 サ ー ビ ス イ ン 2 月 1 3 日 2 月 1 6 日 2 月 1 8 日 2 月 1 9 日 ※当日キャンセル含む 後に修正されたものは含まない 2 月 2 1 日 公 演 前 々 日 公 演 前 日 公 演 当 日 運用テスト～評価 形式 １日目の公演終演後：インタビュー ２日目の公演終演後：アンケート＋インタビュー 評価 事務側（パソコン）の画面がわかりにくい 多少のバグの指摘 タイトルの１文字目が欠落 携帯で『未定』をチェックして登録するとパソコンでは「mitei」と表示され てしまう 印刷画面はもっと充実させるべき 情報が曖昧ではなくなり、確認する手間が省けた。楽になった。 「これからも使いたい」との声！ 納品に際し、バグ・印刷画面などの多少の修正を行う 学習成果 学習成果 村上 システムを開発する流れ 『わからない』ことをそのままにしておくこと＝罪 誰かの存在を意識して行動する 河野 清水 顧客のニーズに対応したモノを作ることの難しさを身をもって体験でき た。顧客の視点に立つことの難しさを知った。 プロジェクトを進めていく上でチーム内で情報を共有することがいかに 難しいことであるかを知った。 新しい言語を学ぶことで、新しいプログラムの作り方を会得することが できた。 ウォーターフォール各工程を進めていく上で、それぞれの工程の重要 さを１つ１つ学ぶことができた。 プロジェクトマネジメント報告 開発規模 ステップ数 ＰＨＰ：４９９７ 画面数：３３ テスト数 単体テスト件数：３０６件 結合テスト件数：９９件 実際の公演でのユーザーテスト（1/26・27）： 予約者数21組25名 スケジュール 2007年 10月 4 予定 11 18 11月 25 1 8 15 12月 22 29 6 13 20 1月 27 3 10 17 24 要件定義 設計 実装・テスト ユーザーテスト 予定２ 実装・テスト ユーザーテスト ※Webアプリ作成ソフト活用時 実績 要件定義 設計 実装・テスト ユーザーテスト ※チーム全体の作業可能時間数をもとにＷＢＳで作成 コスト 項目 計画 実績 差分 要求分析 設計 実装＋テスト（単体＋結合） 165 125 125 138 115 318 -27 -10 183 75 82 7 135 126 -9 合計 625 779 154 間接時間（勉強、気になった時間等） － 運用テスト 各種資料作成（ﾌﾟﾛｼﾞｪｸﾄ定義書、WBS、ｽｹｼﾞｭｰ ﾙ、ﾌﾟﾛｼﾞｪｸﾄ計画書、中間発表資料、進捗報告 書、週報、最終ﾄﾞｷｭﾒﾝﾄ） ※計画はチーム全体で５時間/１日作業と仮定 約 100 実装におけるコスト超過原因 （詳細）設計不足 →重複コードの発生、共有ファイル情報の欠如 InterAgentを利用した工期短縮の見誤り →次ページ（リスク項目）で説明 ＰＨＰでの実装経験が初めて リスク計画 リスク 対応策 学生全員が新規履修者であり 実装に不安が残る InterAgent（ウエブアプリ作成ソフ ト）を活用する 週1回のミーティングのみによ るメンバー情報共有の欠落 メーリングリスト連絡及びWikiを活 用し、情報を共有する 顧客想定物とチーム成果物の 差異 頻繁かつ綿密な顧客との打ち合わせ を行う 実装においてInterAgentが活 用できない場合がある エニィウェア様と再打ち合わせ、及 びそれでもだめな場合は、一人ひと りの作業時間を増やしたうえで、 InterAgent活用部分を実装する リスク計画（実績） InterAgent（Webアプリ作成ソフト）によるコスト短縮 ・InterAgentを利用したコスト短縮がＰＭの楽観的予測 →マニュアルなしでの操作の困難 →メンバー全員のﾌﾟﾛｸﾞﾗﾐﾝｸﾞへのﾓﾁﾍﾞｰｼｮﾝ →システムが小規模で複雑な画面遷移もない 週一回のミーティングだけによるコミュニケーション不足 ・顔を会わす以上の手段はなし！ ＰＭとしての総括 プロジェクトはＰＭ次第でかわっていく しっかりとした計画と進捗状況をメンバーと共有 すること リスクを早めに洗い出し、きちんとつぶしていく 重要性 ＰＮとしての総括 要求分析は先入観を持たずに行う方が良い結 果が生まれる 設計は文章よりも図が大事 ＰＮはＰＭ以上の知識と経験が必要なのでは？ ビデオ上映☆ ユーザの皆様に 協力していただきました! ご静聴ありがとうございました。 劇団おでんくん一同
© Copyright 2024 ExpyDoc
