反復開発の「ここはぜひカバーしたいポイント」/パート2：プロセスと基準（前編）：The Rational Edge（2/2 ページ）

» 2007年10月25日 12時00分 公開
[Scott W. Ambler, Per Kroll，IBM]
前のページへ 1|2 　　　　　　

反復開発のメリット

　1つのプロジェクトをタイムボックスで分割された一連の反復に分割し、各反復の一環としてテスト済みの実行イメージを配布することで、有効なガバナンスにつながる多くのことを達成する。

1）　タイムボックスは、素早い意思決定と重要な点への明確な集中を余儀なくさせる。期限までまだ2年あると、期限が4週間後のときほど配布や決定に対する切迫感を感じない。

2）　可動ソフトウェアを定期的に配布すればフィードバックを得る機会が増える。テスト済みのコードを頻繁に配布すれば、コンパイル、統合、各種テストツール、そして重要な利害関係者から、可動コードの評価に役立つ非常に貴重なフィードバックを得ることができる。このフィードバックがあれば、修正コストが最も掛からない時点で問題を容易に見つけられる。まだ時間や余力があるときに是正処置を講じることで、プロジェクトが一段と高い事業価値を提供できるようになる。

3）　ファクトベースのガバナンス。どれほど嫌だとしても、プロジェクト前半3分の2の間に行われる議論の大半は、「アーキテクチャを見直してみたが私の意見では大きな脆弱（ぜいじゃく）性がいくつかある」といった主観的なものだ。反復開発では、これらの主観的議論から、「パフォーマンステストのデータを見たが、アーキテクチャが必要な負荷に耐えられないという私の見解が確認できた」といった客観的もしくはファクトベースの議論へと変わる。

4）　反復開発では、利害関係者の真のニーズを満たすシステムの構築力が高まる。ソフトウェア経済学の観点から見ると、反復開発の方がはるかに有利なプログレス曲線を描く。数カ月あるいは数年もテストせずに軌道を大きく外れたシステムとは異なり、多くの比較的小さい軌道修正で済むためにテスト済みのシステムが一段と早く作成できるようになるのだ。反復開発は戦略目的を厳守したシステムに結び付くが、オリジナルの（そして脆弱性のある）詳細な要件仕様ではそうはいかない。

ALT 図1 頻繁なデモと利害関係者のフィードバックをベースにした反復（「モダン」）プロジェクトのライフサイクル初期段階における小さい軌道修正は、「ウォーターフォール」プロジェクトよりも素早い成功へとつながる （クリックすると拡大）

・トレードオフ

　反復開発への移行時には、以下のような要検討のトレードオフが多数ある。

　トレーニングと指導。反復開発では、導入の成功を保証するための再教育とコーチングに対する投資が必要になる。旧来のIT専門家は　あらかじめすべてを熟慮しておくという誤った防護処置を捨てる必要が出てくる。また、プロジェクトの作業から作業へとより簡単に移動できるよう、既存の専門外のスキルのトレーニングも必要になってくる。IT幹部やビジネスの利害関係者は、どのタイミングで何が入って何が配布されるのかを理解する必要が出てくる。このトレーニングと指導は徐々に拡大していけばよい。

　個人のスキルセットの要件は変化する。反復開発には異なるスキルセットと一連の役割定義が必須だ。従来のプロジェクト管理では、専門分野の狭いチームメンバーを必要とした。反復開発では、専門家が幅広いスキルセットを持っている方がうまくいく。例として、デザインもしくはインプリメントが専門のチームメンバーの代わりに、開発者にデザインやインプリメンテーションも期待する。中には効率的に反復開発に移行できない人もいるかもしれない。

　プロジェクトのリソースは変化する。反復テクニックでは、特定のスキルセットが必要とされる場合は人員の再配置が必要となる。例えば、テストはプロジェクト後半だけでなく全体を通じて行われるため、テスターはライフサイクルの初期から必要とされる。同様に、初期に対応したアーキテクチャ関連の問題［注1］はプロジェクト全体を通じて継続的に評価が行われるため、アーキテクトはライフサイクルの後半でも必要とされる。これには、従業員の再教育とバランスの見直しが必要になっていく。


　プロジェクト管理には深い関与が必要だ。反復開発は、特にプロジェクトの前半3分の1の部分でプロジェクトマネージャーに掛かる負担が大きい。これは、反復開発が早い段階での難しい判断を余儀なくさせ、プロジェクトの可動部品も多いためだ。全員に要件定義を3カ月間やらせるのではなく、反復ごとに要件、アーキテクチャ、デザイン、インプリメンテーション、そしてテストを少しずつやらせる。そうすることで、大きな失望やプロジェクト後半での期待値の難しい見直しが頻繁に発生するのを回避できるメリットがある。反復の推奨者がプロジェクト管理方法の変化をプロジェクトマネージャーや中間管理職に売り込む能力は、反復開発手法の導入成功にとって極めて重大なのだ。

アンチパターン

　以下のアンチパターンは、反復開発が（適切に）適用されていないことを示唆する。

　詳細な推測計画。ライフサイクル全体を詳細にプランニングし、計画との食い違いを追跡して、プロジェクトの進行に合わせて詳細をアップデートする（ただし、あまり詳細なプランニングはプロジェクトマネージャーによる生産性の高い管理活動を疎外するため、プロジェクトの失敗につながりかねない）。

　ドキュメント主導の追跡。テスト結果や可動ソフトウェアのデモの状況を評価するのではなく、仕様と中間成果物の審査に頼って、プロジェクトが3分の2に達するまでに状況の評価を行う。

　長期反復。相当数の少ない、もしくはかなり長期にわたる反復を利用し、利害関係者からのフィードバックは可能な限り先延ばしにして是正処置を回避する。反復開発を行うのは、フィードバックを得たら素早くこれを反映させるためだ。反復の回数が4回未満もしくは1つの反復の期間が2カ月以上にわたると、この手法の最大のメリットが失われると思われる。

・推奨デフォルト

　デフォルトでは4週間にわたる反復を推奨する［注2］。各自の状況で別の反復期間が適切だと思われたら、反復期間を変更する。反復期間は環境に合わせて可能な限り短くしたい。反復の間に空白の時間を作らないこと。

［注2］　Scott Ambler氏は2007年8月のDr. Dobb's Journalで、アジャイル開発チームの大半が2?4週間の反復期間で作業していることを示した調査をまとめている。

本記事は「The Rational Edge」に掲載された「Best practices for lean development governance Part II: Processes and measures」をアットマーク・アイティが翻訳したものです。

著者プロフィール

Scott W. Ambler,

Practice Leader, Agile Development,

Rational Methods Group, IBM

Per Kroll

Manager of Methods, IBM Rational, IBM



「The Rational Edge」バックナンバー
前のページへ 1|2 　　　　　　

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ