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：パーソナル統合プロセス）と呼んでいる。
「Rational Unified Process」、Rational Software著（2002年刊）
- トランザクション管理の複雑性を克服する（パート1）
- アジャイルとシステムテストの新たな関係（後編）
- アジャイルとシステムテストの新たな関係（前編）
- アジャイル開発の広範な普及を目指して
- 見積もりの精度 Accuracy of Estimation
- 複雑性を理解する（後編）：ソフトウェアの複雑性を手なずける
- 複雑性を理解する（前編）：ソフトウェアが複雑なのは仕方がない？
- 鈍重な開発チームは鈍重なシステムを作る？/パート3：役割とポリシー（後編）
- 人事評価と開発者のモチベーション/パート3：役割とポリシー（中編）
- 自己管理型チームの利点と弱点/パート3：役割とポリシー（前編）
- プロセスはチャンスが訪れるたびに改善する/パート2：プロセスと基準（後編）
- 開発プロセス導入のアンチパターン/パート2：プロセスと基準（中編）
- 反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）
- 開発プロジェクト「統治」のピンポイント解説/パート1：原則と組織（後編）
- 開発プロジェクトを「統治」するベストプラクティス/パート1：原則と組織（前編）
- 初歩の「Perl」「Python」「Ruby」
- ビルドが全滅する原因/プロジェクトの状態を評価する：パート2（後編）
- 不完全なコードは推敲フェイズで潰しておきたい/プロジェクトの状態を評価する：パート2（前編）
- UMLを使ったビジネスモデリング（後編）：そうだったのか！ システムユースケース
- UMLを使ったビジネスモデリング（前編）:なるほど！ ビジネスユースケース
- 「この開発プロジェクトは中止！」の基準/プロジェクトの状態を評価する：パート1（後編）
- プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する：パート1（前編）
- 専門家に聞くモデル駆動開発のメカニズム
- 「設計」や「構築」よりも重宝されるスキル
- キミのコードが汚い理由
- 汎用グラフィカルモデリング言語「SysML」 パート2：グラフィカルなモデル言語で製品構造を記述
- 汎用グラフィカルモデリング言語「SysML」 パート1： 要件、ユースケース、およびテストケースのモデリング
- ウォーターフォールから反復型への移行手順
- ソフトウェアアーキテクティングのメリット
- ソフトウェアアーキテクティングのプロセス
- ソフトウェアアーキテクトの役割
- ソフトウェアアーキテクチャって何なの？（後編）
- ソフトウェアアーキテクチャって何なの？（前編）
- ITプロジェクトを見える化する
- ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
- オブジェクト指向を超えて
- ルネサンスの巨匠たちに学ぶエンジニアリングの技
- ソフトウェア開発の「いま」と「近未来」の話
- 中国のソフトウェア開発現場はこんなにスゴイ
- 隣のテストチームが優秀ないくつかの理由（後編）
- 隣のテストチームが優秀ないくつかの理由（前編）
Copyright © ITmedia, Inc. All Rights Reserved.