The Rational Edge

プロジェクトに1人で果敢に取り組んだ
あるプロジェクトリーダーの日記

−ラショナル統一プロセスの実践−

---

　

支払いの約束（月曜の昼）

　早い話、Garyは昼飯をおごってくれるほどこれを気に入っている。メインの料理がくるまでの間に、持ってきた5枚の紙（そして自分の手帳）に2人で次々に書き込みをしていった。

　ただ1つ困ったのは、私が要求事項を完全に理解できていなかったことだ。Garyは自社のデベロッパー全員に社内LAN経由で1つのデータベースにデータを蓄積してもらいたいと考えている。データのマージ作業がそれほど容易ではないことから、彼は個々のデベロッパーが自分のデータベースにデータを蓄積するようなことをさせたくないのだ。また、特にテストのときなどは、彼らが常に同じマシンを使って作業をすることもない。小変更を多少加えて要求を明確にするが、ネットワーク機能には不安が残った。これは自分のアーキテクチャと因果関係があり、より多くの設定やテストが必要になる。しかも、データベースのメンテナンスを行う管理者まで特定しなくてはならない。

　そこで、朝に用意した資料を多少大急ぎで修正する。

■「開発構想（改訂版）」

　私は開発構想を変更し、ネットワーク機能を加える。また、これをビジネスにする話を持ち出した際に説明した今後の開発作業に向けたアイデアも2つほど加えた。今回のバージョンにはこれらをインプリメントしないが、設計上の選択肢が制約を受ける可能性がある。

■「プラン（改訂版）」

　私はあまり冒険をしないことにした。大掛かりなアーキテクチャのリスクを緩和するため、私はLCAマイルストーン（「推敲」の終わり）を火曜日の夕食時まで延期した。「作成」には2日をかけ、2回「反復」して行うつもりだ。最初の反復では「シングルユーザー」バージョンが問題なく機能することを水曜日に確認し、テストを行って、木曜日にはネットワーク経由のクライアント／サーバ機能の開発とテストを行う。そのため「移行」は金曜日にずれ込み、最終的な製品の引き渡しは金曜日の夜になる。さらにGaryは、私が金曜日の朝に彼のオフィスに出向き、ベータ版をインストールしてこれを現場でテストすることも希望している。

月曜日	火曜日	水曜日	木曜日	金曜日	土曜日
方向付け 開発構想 プラン ビジネスケース リスク	プロトタイプ リスクの緩和	作成（シングルユーザー） 設計 コーディング テスト	作成（クライアント／サーバ） 設計 コーディング テスト	移行 改善作業？ IOC：最初のベータ版を見せる
LCO：Gary承認
推敲 プロトタイプ	LCA：Gary承認 ユースケース テスト	設計 コーディング テスト	設計 コーディング テスト	引き渡し

■リスク一覧（改訂版）

　これで以下のような5つの新しいリスクが加わる。

パーソナルタイマツール：リスク（改訂版） データベースに対する更新処理の同期を取る 複数のマシン間での作業、プロジェクト、およびユーザーの一貫性 管理者および通常ユーザー向けのアクセス権ポリシー 2カ所の異なるマシンから同一ユーザーが接続する可能性と、それによって生じる結果 1人のユーザーとのやりとりが何らかの理由によって中断し、ほかの全ユーザーが使用不能になる

　一方、自分にとって最大のリスクは、もし何か問題が発生すれば週末に予定していたハイキングが台無しになってしまうことだ。

■ビジネスケース（改訂版）

　これで1週間フルに作業することになったため、見積額を上げることにする。Garyは彼の投資をわずか8カ月半で回収できることになるが、火曜日の夜までにLCAマイルストーンに到達した場合には、プロジェクト代金の4割を支払うのが妥当な取引契約だという考えだ。彼は「推敲」フェーズに向け、オフィスに戻り次第、発注書を送付することを約束する。

格闘（月曜の午後）

　オフィスに戻った私は次の2つの主なユースケースについて詳細の検討に入る。

• 作業の時間計測
• データの一致

　私はほかの2枚の紙にこれについて詳細に書き留め、手元のホワイトボードにシーケンス図を描く。

　さらに私には、3つのクラスを使ってアプレット形式でこのコードをデザインするに当たってのアイデアが浮かんできた。また、タイマがだいたいどのような外観になるのか草案を作成してみる。

　作業が進むに従って、「作業リストはあらかじめ定義しておき変更できないようにするか？」（おそらくそうはしないだろう）、「おのおののデベロッパーは新規リストを作成できるのか、それとも既存のリストにアクセスするだけか？」、など頭の中には疑問や問題点がどんどん浮かんできた。Garyは不在でボイスメールでしかコンタクトが取れないため、明日にでも見せられるよう浮かんだ疑問を書き留めておく。

　夜までには次のように画面表示されるアプレットが出来上がった。

　また、（真のXPスタイルで）自分で考えつく限りのテストと併せ、テキストファイルで何とか作業データを用意することもできた。1日分の作業にしては悪くない。

続行（火曜日）

　リスクを1つ外すと2つ加えなければならないというように、今日は浮き沈みの激しい日だが、かなりの数の発見があった。データベースとのインターフェイスがうまくいかないので昼食はオフィスに残ってピザを注文した。ソフトウェアがクラッシュしたのは、手元にあったソフトウェアのバージョンがあまりにも古かったためだ。また、APIの仕様も十分注意深く目を通していなかったこともある。技術サポートで1時間を無駄にしたが、適切なバージョンをダウンロードして、マニュアルを注意して読んだ。

　あまり進展がなく、プロジェクトが全体的に間違っていたのでは、と考えるようになっている。たとえこのようにものすごく小さなアプリケーションでも、失敗の可能性を秘めた部分はいくらでもあるものだ。

　1つのクラス図と2つのコラボレーション図だけのものだが、UMLモデルは完成した。この作業と並行でアーキテクチャシートに基づいてコンポーネント図も作成したのでアーキテクチャシートは不要になる。そして、残りの紙をすべて壁に貼った。

　作成したリスク一覧が乱雑になってきたため、これをExcelファイルにして自分のPCに保存した。

　「開発構想」は変えはしないが、いまではこれが疑問や問題の書かれた17枚もの付せん紙でいっぱいになってしまっている。そして、さらに以下のような条件を加えていく。

• このコードはWindows NTもしくはUNIX上で動作する
• データベースはWindows NT 4.0以上に対応する

　Garyが同僚のEricと一緒に夕食を食べに現れたとき、私はそこそこ実情に沿ったプロトタイプの仕上げに取り掛かっていた。ユーザーが1人（「Gary」）で作業も「考える」しかないなど、データはすべて詰め込まれており、「作業の時間計測」のユースケースに対する拡張機能として「中断と再開」をオンザフライで実行することができた。データベースが私のデスクトップ上で動作し、アプレットはインターネットを経由して私のラップトップ上で動作する。これで私の頭の中にあるリスクの一覧は、簡単なものを少し残すのみとなった。

　Ericがクラッシュさせるまで、われわれはこのプロトタイプを5分ほどいじった。彼にはショックだったようだが、今回は堅牢性や完成度が目的ではないことを説明した。その後、アプレットのルック＆フィールについて話し合い、フィールドの配置を多少変更し、用意した質問の一覧を検討した。Ericは、カウンターの動作中にマシンを再起動しなければならずにデータを失ってしまうことをかなり心配した。私は調査することを約束したものの、彼が気にしなくてよいといってくることを期待していた。この問題には言及すべきではなかったのかもしれない。

　結局は、リスク一覧に新たなリスクが2つと、「開発構想」ドキュメントに要求事項が5〜6件ほど加わることになったが、それほど悪くはない。「プラン」については変更せずそのままとした。「開発構想」については「システム運用」向けにさらにユースケースを加える。

• データベースのクリーンアップ
• ユーザーの登録
• 作業リストのクリーンアップ

　朗報なのは、Garyが見たものに満足し、このプロジェクト全体を先に進めてほしいといってくれたことだ。また、彼は制約条件にも異論がない。

さらなる進展と変更（水曜日）

　やった！ Ericの指摘した問題に対するソリューションを見つけた。

　私は自分が間違って変更を把握しきれなくなってしまうことが心配なので、作業を進めながらコードとテストをすべてコンフィグレーション管理ツールに入れている。すべての反復した過程におけるスナップショットを完全に残しておくという単純な戦略である。

　さらに、ユースケースを基にして実施するテストを完全に網羅した一覧を作成する。

　これで作業は、データを抽出し、ソートして、見栄えの良いグラフを作成するためにExcelで読み込めるフォーマットにするダイアログボックスへと進む。

　午前11時30分ごろにEricが電話をかけてくる。彼は要求を1つ伝え忘れたという。1人の人間が複数の作業を進める可能性があり、複数のカウンターを同時にアクティブにする必要があるのだ。

　これは痛い。「開発構想」の変更である。難しくなる可能性があるためリスク一覧に加える。

近づく完成（木曜日）

　テストを実施する。ネットワーク関係を試したところ問題点が複数見つかる。

　要求事項についてGaryと再び交渉し、Ericが昨日伝えてきた新しい事項を自分のリストの中にあったものと入れ替えてもらうようにした。Garyの会社ではどうしても大半の社員が同時に複数のプロジェクトを進めるため、作業とプロジェクトの両方を処理しなくてはならないのだ。

　ユースケースに基づき、HTMLを使った簡単なWebベースのユーザーガイドの作成に取りかかった。

　修正しなくてはならないことがかなりあるため、ここでもっと整理しておく必要がある。これらを整理するためにリストを作成し、GaryとEricからの変更要求をまとめて、改善に向けたアイデアもいくつか加える。

　さらにテストを行う。まずは処理能力テストを行う。問題はない。次に、データベースを2台のマシンから同時に更新する同時処理テストを実施する。あまり良くない。同期処理については本格的な再検討が必要だ。2台のマシンから同一ユーザーが同じ作業とプロジェクトの組み合わせを処理するとデータが1つ紛失してしまう問題が発生する。

　だが、深夜になって問題の原因に気付いた。これでほぼすべての機能がうまく動く。

ベータテストと出荷（金曜日）

　朝、最初のベータ版を持ってGaryの会社を訪れた。われわれはこれを複数のマシンにインストールし、私がデータベースの設定と彼の部下への簡単な説明を行い、彼らがこれをいじり始める。メモを取る用意をして各自の席を回り、改善に向けた提案を書き留めていく。

　自分のバグ一覧に2件の大きな問題と、12件の小さい問題（大半は好みの問題）を書き加えた。

　昼食時には自分のオフィスに戻る。重要な問題をすべて修正し、さほど重要ではない3つについては無視する。また、主に体系的なテストの実施によって、自分で新たに4つの問題に気付く。そして、ついに次のリリースの準備が整う。これには自分のコンフィグレーション管理システムの中で0.9というバージョンを付けた。0.91や0.92も用意しなくてはならないように思え、悲観的になり始める。

　深夜になり、一息つきながらリリースノートを書き、簡単なインストーラを用意する。そして、午前1時（土曜日）には作業が終わる。CD-ROMを焼いて「V1.0の出荷だ！」と叫んだ。

　ビールを1本開ける（冷蔵庫にシャンパンが1本もなかったのだ）。

　終わった。とにかくこのバージョンは終わりである。

2/3

INDEX
先駆者に学ぶ「開発プロセス改善の原則」
	Page1 単独作業によるソフトウェアプロジェクト
	Page2 支払いの約束（月曜日） 格闘(月曜の午後） 続行（火曜日） さらなる進展と変更（水曜日） 近づく完成（木曜日） ベータテストと出荷（金曜日）
	Page3 Nickのプロセス