開発プロセス導入のアンチパターン/パート2：プロセスと基準（中編）：The Rational Edge（2/2 ページ）

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

プロセスの導入

　開発プロセスはプロジェクトのニーズに合わせて適応させることが重要だ［注3］。プロセスが多いから良いわけでも、少ないから良いわけでもない。むしろ、プロジェクトの儀式の量、精度、コントロールは、チームの規模や配分、外部の制約量、プロジェクトのフェーズ、そしてプロジェクト監査力やトレーサビリティのニーズなどの各種要因に合わせる必要がある。

［注3］　この部分は、Kroll and MacIsaac氏による「Agility and Discipline Made Easy -- Practices from OpenUP and RUP」からの抜粋。

　最初に、利用する成果物の多さ、制作する詳細な文書の多さ、開発や保守を行う同期の必要なモデルの多さ、もしくは正式なレビューの多さなど、プロセスが多いからといって必ずしもそれが良いとは限らない。むしろ、プロセスはプロジェクトのニーズに合わせて導入すべきだ。プロジェクトの規模が拡大し、より分散され、より複雑な技術を採用するようになり、利害関係者が増え、必要な標準へのコンプライアンスが厳しくなれば、プロセスはもっと構造化される必要がある。しかし、チームが同じ場所に配置され、既知の技術を使う規模の小さいプロジェクトでは、プロセスをもっと能率的にする必要がある。

　2番目に、プロジェクトはライフサイクルのフェーズに合わせてプロセスの儀式を適応させる必要がある。プロジェクトの最初には一般的にかなりの不確実性が付き物で、ビジネスニーズに対応するアプリケーションの開発には多くの創造性を奨励したい。一般的に、プロセスが多いと創造性が低下するので、不確実性にあふれたプロジェクトの最初はプロセスの数を抑えたい。その一方で、プロジェクトが進んだら、後から判明した欠陥に関連した望ましくない創造性やリスクを排除するために、機能の凍結や、変更管理委員会といったコントロールの強化を行いたい。これは、プロジェクトが進むにつれてプロセスが増えていくことを意味する。

　3番目に、組織はプロセスの継続的改善に努める必要がある。反復やプロジェクトが終わるごとに評価を行い、そこから学んだ教訓を把握し、その知識を活用してプロセスを改善する。チームメンバー全員に継続的に改善の機会を探すよう促し、その改善を社内のソフトウェアプロセス改善組織（SEPG）など、プロセス改善に熱心な組織に提供する。これらの活動には予算と時間を十分に割り当てる必要がある。

　4番目に、プロジェクトの計画や関連する見積もりとプロジェクトの不確実性のバランスを取る必要がある。つまり、一般的に不確実性が大きいプロジェクトの早い時期の計画と関連する見積もりでは、明らかに存在し得ない高い精度を目指すよりも、全体のプランニングや概要に重点を置く。開発初期の活動では不確実性を洗い出し、それから徐々にプランニングの精度向上を目指すべきだ。

ALT 図4 必要な専門プロセス量を決める要因。プロジェクトの規模、チームの配分、技術の複雑性、利害関係者の数、コンプライアンス要件、プロジェクトの特定ステージなど、必要なプロセスの構造化レベルは多くの要因によって決まる

・メリット

　プロセスの適応には複数のメリットがある。

　生産性の向上。プロジェクトのニーズに適応されたプロセスは、チームを一体化させる力となり、（オーバーヘッドにならない）生産的な活動を目指す作業が増え、プロジェクトの（邪魔にならず）生産性を向上させる。また、テンプレート、例、指針が提供されることで個々のチームメンバーの生産性も向上する。

　結果の再現性。適合プロセスでは、チームが戦術的なプロジェクトのニーズに適合できる。これにより、再現性のある結果の実現に必要なサポートと柔軟性がチームに与えられる。しかし、再現性のある結果は多くの場合、プロセスの中で戦術的なニーズに合わせる何らかの適合性を必要とする。この場合の「再現性」は、単純にプロセスの100％同じ複製ではなく、了解された範囲のペース、成果、および基準で進行するプロセスステージの再現性を意味する。

　早期の価値創成とリスク削減。プロセスの儀式をプロジェクトの不確実性に適合させ、低減することで、技術革新が実現する。プロジェクトの早い段階で生まれる価値が増え、早期のリスク削減も実現する。

　チームとプロジェクト間での教訓の共有。前回のプロジェクトから学んだ教訓に基づいてプロセスを適合させれば、チーム間で効果的に知識を共有できるようになる。

・トレードオフ

　プロセスの適合には多数の重要なトレードオフがある。

　投資の必要性。プロセスを効果的に適合させ、導入するため、プロセスの適合には知識への投資が必要になる。

　見識の必要性。プロセスを正しく導入するために、組織は手法選定の可否を決める状況と適合範囲を理解するために、ソフトウェアエンジニアリングの十分な見識を持つ必要がある。

　管理のバリエーション。チームがプロセスを導入できるようにすると、一連のプロジェクト全体で適切なベストプラクティスに確実に追従させるところを中心にプロジェクト管理が難しくなる。これは、チームがさまざまなタイミングでさまざまなレベルの成果物を出してくるためだ。

・アンチパターン

　プロセスの適合には以下のようなアンチパターンがある。

　プロセスは多いほど良い。初期の見積もり作成と、その見積もりの厳守を強要するなど、プロセスの多さ、マニュアルの多さ、そして詳細な事前計画を良しとする。

　首尾一貫した反復可能なプロセス。たとえ何があっても、常に同じプロセスを利用する（実際は、各プロジェクトが成功するようなバリエーションを可能にするのが目標だ。従って、常に同じプロセスを利用し、プロジェクト全体を通じて同量のプロセスを利用することは障害につながるアンチパターンである。真の目標は首尾一貫した再現性のある結果だ）。

　場当たり的プロセス。進行に合わせてプロセスを作り出したり、プロジェクトごとに全くプロセスを認識できないほど広範囲にプロセスを導入する（プロセスを全く定義しないと、結果も全く予測できず、リスクを特定することも低減することもできず、チーム間で教訓も共有できない）。

・推奨デフォルト

　プロジェクトのニーズに基づいてカスタマイズされた独創的な配布プロセスによるRUPプロセスフレームワークの強化を推奨する。

本記事は「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.

注目のテーマ