The Rational Edge

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

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

---

　

Nickのプロセス

　われわれはNickの話からプロセスについて何を学ぶことができるだろうか？ 彼の言葉と行動をもっと詳しく見ていこう。

　Nickは、技術的なこと（技術、言語、インターフェイス、そしてパフォーマンス）とビジネス的なこと（スケジュール、経費、そして不慮の事態）の両方のリスクを十分に承知している。彼は、これらのリスクの緩和、アイデアの迅速な試行と検証、カスタマーからのフィードバック入手、そして四面楚歌的状況の回避のために反復プロセスを採用している。彼はまた、わずか1週間という期間のプロジェクトであるにもかかわらず、明確に規定したマイルストーンをいくつか設定して計画を立てている。

　このプロジェクトに着手するに当たって、Nickにはシンプルなビジネスケースが1つと、自分の経費と潜在的な収益に対する適当な見積もりがあった。そして彼は、基本要求事項が変化したことを知ると、このビジネスケースを修正するのだ。

　Nickは、かなり早い時期から試行する全体のアーキテクチャを手始めにデザインを進めていく。彼はまた、正しい手法が明確になっていないと思われる分野については詳細にデザインを推敲している。

　NickとGaryは、それぞれにお互いのニーズを確実に理解しようと努め、Nickはどのようなものが出来上がるのかをGaryに正確に認識させようとする。Nickは、先走ってGaryが必要だと思われるものを考えるのではなく、ある程度の時間を割いて要求、機能、そして制約を書き留める。そして、これをGaryと一緒に何度も検証し、この製品に対してお互いが持っている開発構想が同じであることを確認するのだ。

　Nickは優先度の最も高い作業に時間を割こうとし、いかなる問題にもすぐに対処するという考え方をする。テストの失敗から製品に問題が見つかったり、Garyが新しい要求事項やさらに優れたアイデアを持ってくると、Nickはこれを変更リクエストという形で理解するほか、変更リクエストの管理と優先順位変更を常に継続し、自分の1時間刻みのスケジュールを進めていく。

　Nickは、製品コード以外にも早い時期から要求事項の多くに対応する一連のテスト事例を用意しており、彼が反復プロセスを利用した結果、これらのテストの多くは、製品の開発が進むにつれ熟慮され、絞り込まれ、そして徐々に改善されていった。

　事故（ディスクのクラッシュなど）や自分自身のミスによるプレッシャーからコードの一部を紛失するようなことを避けるため、Nickはシンプルな戦略でソフトウェアを管理しており、ファイルは複数バージョンの履歴を残し、テスト対象となる一連のバージョンはスナップショットを作成して残した。彼はこれらの各バージョンを基準にした進展部分と変更部分をトラッキングしているため、失敗を犯しても確認済みのコンフィグレーションに戻ることができる。

　最後に、Nickはこのリリースの説明、インストール方法、および制限事項に関するセクションを含んだもの、リリースノート的なもの、そして製品の使い方についてのもの（つまりユーザーガイド）といった簡単なユーザー向けのドキュメントを書いている。

　これこそNickが利用する非常に簡単なエンジニアリングプロセスの神髄だ。これは、わずかな数の成果物や製品にしかフォーカスしない「あまり形式張らない」プロセスだ。成果物の多くがコンフィグレーション管理ツール、デザインツール、オフィスツールといった形でさまざまな開発ツールの中に保存されているため、あまり多くの事務処理は必要としない。これらの成果物の数はわずかだが、製品開発の初期段階だけでなく、将来的に新たなリリースが出るときも価値を生み出してくれる。3カ月経過してGaryがNickにバージョン2の開発を依頼しても、これらの成果物がNickに計り知れぬほど貴重な情報を提供し、もっと良い仕事ができるようにしてくれる。これによって、重要なコストを見積もることができ、一部デザインやコードの再利用が可能になり、教訓（繰り返しを避けることのできる失敗）も得られるのだ。

　まさかとは思われるだろうが、Nickが採用したシンプルなプロセスには「Rational Unified Process：ラショナル統一プロセス」（RUP）にある重要な手順すべてが含まれており、多数の複雑な指示を詳しく調べることなく容易に再現できる。RUPは数百人のデベロッパーが参加する巨大プロジェクトにしか適用できないということは決してない。これは1人だけで構成するチームがRUPを非常に効果的に利用した好例だ。Nickは愛情を込めてこれを彼の「Personal Unified Process」（PUP：パーソナル統合プロセス）と呼んでいる。

[参考文献]

『Extreme Programming Explained: Embrace Change』、Kent Beck著（Addison-Wesley、2000年刊）

「Rational Unified Process」、Rational Software著（2002年刊）

「The Ten Essentials of RUP」、Leslee Probasco著（The Rational Edge、2000年12月刊）

「What Is the Rational Unified Process？」、Philippe Kruchten著（The Rational Edge、2001年1月刊）

『The Rational Unified Process: An Introduction 2nd ed.』、Philippe Kruchten著（Addison-Wesley、2000年3月刊）

『Introduction to the Personal Software Process（sm）』、Watts Humphrey著（Addison-Wesley、1996年12月刊）

Development Style 連載記事一覧

3/3

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

本記事は「The Rational Edge」に掲載された「A Software Development Process for a Team of One」をアットマーク・アイティが翻訳したものです。