MLBTix
今は、２００３年１２月７日。あなたは期間の短い複雑なプロジェクトのチームメンバーに 選ばれました。大まかな目標は把握しているが、実装方法などはプロジェクトを進行しつつ 決めます。
背景
:
ここ十年で大リーグの来客は上昇。ボストンなど都心の試合は全て売り切れとなり、通常経 路でのチッケット購入は不可能に近い。
MLB
の規約により、利益のための二次販売を禁じ、制御している。チケットの主な販売元は
EBAY
であり、そこでの販売は定価程度の手数料が限 度としながらも、何らかの工夫をして１０倍の価格で販売されているのが現状。プロジェクト
:
MLB
委員会がチケットの二次販売を制御するプロジェクトを決定し、最近MLB
以外の団体ま た個人のチケットの二次販売を禁止する法律が施行され、それに伴いMLBTix
というサイトを 構築し、そのサイト上のみ二次販売許可する。EBAY
と同様の機能を持ちつつMLB
チケットに限定し、オンラインで販売購入の機能を提供する。主な特徴としては、売り手が上下限度なく販売価格が設定でき、さらに期間も自由に 設定できる。売買契約が確立した時に、買い手は
MLB
が提供するカード決済機能を使い支払 う。支払いが確認でき次第、売り手に発送の指示を出し、配達確認後、手数料の２５％を差 し引いた金額の小切手を売り手に郵送する。MLBTix (2)
２００４年１月１５日に
MLB
委員会のコミッショナーが記者会見でシステムの発 表する予定。コミッショナーの希望は、ある程度の機能がシーズン開始日の３月３ ０日までに公開ができ、さらに7
月１８日のオールスター試合までに全ての基本機 能をサイト上で公開できること。1.
２００４年３月３０日MLBTix
のサイトを公開し、売り手と買い手の登録ができる。売り手は希望価格で販売でき、買い手がカード決済で全額払い、購入す ることを可能とする。
MLBTix
は仲介であり、チケットの発送などは売り手と買い 手の責任。仲介手数料としてMLBTix
は決済金額２５％を天引する。2.
２００４年６月３０日 オークション機能を追加3.
２００４年８月３０日 グループ席購入、席の場所を球場の図面で確認でき、チケットの在庫確認を公開する。
プロジェクトのための予算は十分確保してあるので、プロジェクトの機能制限の要 因にはならない。機能をスケジュール通りに納品するのが第一優先。納品日に間に 合わせるため、他社製品などを利用して開発してもよい。記者会見の前に、会長へ スケジュール通りに納品できるかどうかを報告しなければならない。
MLBTix (3)
必須機能：
売り手が登録でき、ユーザ
ID
とパスワードを割り当てる。買い手が登録でき、ユーザ
ID
とパスワードを割り当てる。ユーザ
ID
にひもづくプロフィールが作成でき、メールアドレス、住所、カード情報等の設定が可能。チケットをオークションに出品し、初期価格、開始日時、終了日時が設定でき、買い手が入札の判断 ができる適度の情報を表示する。（日付、チーム、シートの数と場所など）
オークションを自動制御する。
オークション終了後、確実に最高入札者に販売することを決定しカードから課金し、
MLBTix
の口座に 入金する。売り手に売買契約の成立を通知し、郵送のための情報を提示する。
買い手に適度な期間（終了時＋１週間？）内でチケットが受け取れなかったと問合せできる仕組みを 提供する。
期間内に買い手から問合せがない場合、２５％の手数料を差引いた金額を送金する。
２５％の手数料と利子分を自動的に
MLBTix
の口座からMLB
の口座に送金する。在庫とチーム、チケット、日付、席を場所による在庫検索を提供する。
MLBTix
での広告および宣伝の仕組みを提供する。不正利用者を検知し、利用権利およびアカウントの取り消しを可能とする仕組みを提供する。
MLBTix (4)
非機能要件
:
•
２５万同時ユーザで一秒以下のレスポンス•
市場規模にあったレベルのセキュリティー対策（予測では一日２０００枚で平均価格が＄５０）•
１００万同時ユーザまでスケーリング可能• 99.99999
％アップタイム ２４x
７開発環境と現状
:
• .NET
の環境を常に用意。ハードはインテルのマシンに限定し、サーバ環境は.NET
ソフトウエアとSQL
サーバー。•
開発チーム全員はオフィスから楽な通勤距離以内に在住。•
現在オフィスは個人の作業スペースを設けてある。•
開発環境は無線LAN
を設置してあり、LAN
環境と電源環境は整っている。•
開発環境はマイクロソフト製開発ツールのVisual Studio
などは完備してある。•
ソースコードライブラリーを使って、コードに変更があった度にチェックインしなければならない。最低、一日に一回ビル ドし、ビルドの結果をユニットと承認テストをしなければならない。•
スクラムを開発技法として使わなければならないが、XP
やほかの技法も取り入れることはチームの判断に任す。•
開発チームは全員熟練プログラマーだが、スクラムやXP
の話はよくきくけどまだ経験がない。•
開発チームはマイクロソフト製品で平均１０年経験を持ち、難易度の高いプロジェクトを納品実績のあるエンジニアたち。コーディングと設計のスキルは確かのものだが、テストとドキュメンテーションも任されている。
•
開発チーム全員は野球の大ファン• QA
の環境はある。•
テストツール、常時ビルドツール、リファクタリングツールは不十分で、VSS
は物足りない。演習： MLBTix
• MLBTix
でのみ二次販売を合法とする法律を通すのに、MLB
は約5.54
億ドルを使った。その法律を有効とするためには、
MLBTix
の機能を3/30
まで に開発しなければならない。•
１２月７日の時点で、３月末までに（４スプリントの間）コミッショナーの
Bud Selig
氏の依頼により、少なくともチケットの販売購入できるシステムを提供しなければならない。間に合わないと６００億で無理に通した 法律も台無しになる。予算ならいくらでもあるが、外注や共同開発の許 可はおりない。
•
そこでコミッショナーが知りたいのは、基本システムの納品は間に合う か？委員会所属の広報部は、会長が１月１５日の記者会見で発表するよう準 備している。記者会見で発表できるかどうか、また、その発表の内容はど うしたらよいでしょう？
レガシー
レガシー コード
•
殆どの新機能はそのシステムを基礎として利用される。•
インフラストラクチャーまたはレガシーソフトウエア（コア機能）と 呼ばれる事もある。•
変更に対し不具合を起こし易く、テストハーネス（自動テスト）もない 場合も多い。•
扱い方の知識を持つ人も関わりたい人も殆どいない。•
通常より多く作業時間を必要とする。開発ペースの差
新機能開発
レガシーを基礎とする開発
イテレーション数
（時間）
要件、 プロダクトバックログ
締め切りは
どうして間に合う？
根本原因は？
要件、 プロダクトバックログ