アットマーク・アイティ @IT| @IT情報マネジメント| @IT自分戦略研究所| QA@IT| イベントカレンダー  
 
 @IT > .NETエンタープライズ新時代 > 相対立するパラダイム 〜「Visual Studio Team Systemで実践するソフトウェアエンジニアリング」
 
@IT Special

 

PR

「Visual Studio Team Systemで実践する
ソフトウェアエンジニアリング」


相対立するパラダイム
プロジェクトマネジメントの不確実性を管理する手法として、従来の「ワークダウン手法」に代わり広がりつつあるのが「バリューアップ手法」だ。バリューアップ手法では、各時点での提供価値を測定し、入力情報を固定的集合ではなく可変フローと見なす。両者の違いを解説しよう。

本記事は、日経BPソフトプレス社が発行する書籍「Visual Studio Team Systemで実践するソフトウェアエンジニアリング〜成功する開発プロジェクト運営のために〜」の第1章 1.2「相対立するパラダイム」を、同社の許可を得て転載したものです。

本書は Visual Studio Team System の開発チームにおいてプロダクト プランナーを務めた Sam Guckenheimer が Juan J. Perez と共著で書き記した書籍です。本書ではそもそも Visual Studio Team System という製品を通じて開発者の方々に提供したかったバリューは何なのか説明を行い、またそのバリューを最大限に受け取っていただくために理解いただきたい理論的な背景を、抽象的過ぎずまた細部にとらわれすぎることなく解説を行なっています。

ご注意:本記事は、書籍の内容を改訂することなく、そのまま転載したものです。このため用字用語の統一ルールなどは@ITのそれとは一致しません。また注釈、図版番号に関しても書籍内容のまま転載しています。あらかじめご了承ください。

 ソフトウェアプロジェクトには特有の不確実性があるため、タスクを正確に予測することは難しく、大きなばらつきが発生する可能性があります。ばらつきがあってもプラスマイナスの相殺でほぼ同じ結果になると誤解されがちです。しかし、ソフトウェアプロジェクトはタスクが互いに依存し合う長い連鎖で構成されるため、ばらつきが積み重なれば下流工程で遅れが生じます。(注u)

 残念ながら、プロジェクトマネジメントについての定評ある知恵の多くは建設業界から来ています。建設業界では、設計のリスクは低く、設計コストは建築コストに比べて安く、できた部分から引き渡すということもほとんどありません(半分だけ仕上げた橋では渡れません)。このような形態のプロジェクトマネジメントでは、最初にエンジニアリング設計を決定し、その設計を基に入念にタスクを割り出し、依存関係や確保できるリソースに基づいて各タスクにスケジュールとリソースを割り当て、各タスクの完了具合(達成率)を確認しながらプロジェクトの進行を管理します。便宜上、ここではこのようなプロジェクトマネジメント手法を「ワークダウン(順次終わらせる)」手法と呼びます。リスト内のタスクを1つずつ消していくイメージです。

 ワークダウン手法が適しているエンジニアリングプロジェクトとは、リスクが低く、 計画のばらつきが少なく、設計が理解されやすいプロジェクトです。たとえば多くのITプロジェクトは、基幹業務ソフトなどの既存のCOTS(commercial-off-theshelf :商用既製品)ソフトウェアをカスタマイズする作業です。このようなプロジェクトでは多くの場合、プロジェクトにおいて開発作業が占める割合は、業務分析やプロジェクトマネジメント、テスト作業に比べて小さくなります。一般に、このようなプロジェクトは新規開発プロジェクトほどの高い可変度はなく、道路や橋の建設で培われた手法を適用してもうまく適合します。

 1992年以降(注1)、ソフトウェアプロセスにワークダウン手法を適用することの難しさが明らかになりました。その代わりとして広がりつつある新しいパラダイムを一言で表すことはできませんが、ここでは「バリューアップ」手法と呼ぶことにします。他の新しいパラダイムの例にもれず、バリューアップの考え方は突発的に登場しました(図1-2 を参照)。


図1-2
 ワークダウン手法とバリューアップ手法では測定基準が異なる。ワークダウン手法では、プロジェクトを何らかのコストを投入して達成すべきタスクの固定的集合と見なし、それらのタスクのコストを測定する。バリューアップ手法では、各時点での提供価値を測定し、入力情報を固定的集合ではなく可変フローと見なす。

 バリューアップ手法の考えの1つが、アジャイルプロジェクトマネジメント宣言である「相互依存宣言(Declaration of Interdependence)」です。(注o)

 この宣言では、以下の6つの原則でバリューアップ手法を表しています。

■ 継続する価値フローを重視することによって投資収益率を上げる。

■ 顧客との密接な対話およびオーナーシップの共有によって、信頼性の高い結果を提供する。

■ 不確実性を想定し、反復、予想、適応によってこれに対処する。

■ 究極の価値の源泉は個人にあることを認識し、個人が力を出せる環境を構築することで創造性と革新を生み出す。

■ 結果に対するグループの責務およびチームの実効性に対する責任を共有することでパフォーマンスを促進する。

■ 状況に応じた戦略、プロセス、および実践を通して、効率と信頼性を向上させる。

 この原則の背景には、作業の進め方に対するワークダウン手法とバリューアップ手法の考え方の大きな違いがあります。この違いについて、次の表1-1に示します。

▼表1-1 ワークダウン手法とバリューアップ手法の考え方の違い

基本的な前提 ワークダウン手法 バリューアップ手法
プロセスの計画と変更 計画と設計は正確に行うことが重要である。これは最初に行う必要があり、計画に基づいて分担を決め、計画に沿っていることを監視し、変更が入り込まないように注意しなければならない。 変更は発生するものである。喜んで受け入れよう。計画と設計は、プロジェクト期間を通して継続的に行う。したがって、計画と設計は、リスクの把握とその後の小さな追加が可能な程度に行う
測定基準 タスクの達成度で評価する。目標達成に必要な各工程を把握しているので、計画における完成までの全時間 数に対する現時点までの作業時間数 の割合によって、中間成果の評価と価値の達成度を測定できる。 顧客が満足する成果物(動作するソフトウェア、完成した文書など)のみを 評価する。ワークストリームのフローは完成した顧客価値のキューを管理することで測定し、すべての中間成果物は懐疑的に扱う必要がある。
品質の定義 仕様遵守。そのため、仕様は最初から正確に作らなければならない。 顧客価値。顧客価値の認識は変わることがある。顧客は、動作する試作ソフトウェアを見るまで、求めているものを明確に伝えられないことがある。したがって、選択の余地を残し、継続的な納品が可能な体制を保ち、早い時期にあまり詳細に限定しすぎないようにする。
ばらつきの受容 タスクは確定的に計画して決定できる。ばらつきを考慮する必要はない。 ばらつきはどんなプロセスフローにもあり、人間がかかわる以上はごく自然 なことである。予測可能性を実現するには、ばらつきを理解し、これを減らす努力が必要である。
中間成果物 文書、モデル、その他の中間成果物は、計画と設計をタスクに分割するために必要であり、中間進行度の測定に必要な手段となる。 中間文書は、フロー改善のために不確実性とばらつきを最小限にすることを目的として使われる。それ以外の目的には不要である。
トラブルシューティング 何を達成できるかは、時間、リソース、機能、品質によって決まる。このいずれかを調整すると、他も調整することが必要になる。変更は慎重に管理し、計画に対して管理されていない変更が発生しないようにする。 制約事項は、時間、リソース、機能、品質に必ずしも関係しない。それよりも、価値のフローで最も大きいボトルネックを特定し、それを小さくするように対処し、それから次のボトルネックに取り組む。フローがより円滑になるようにばらつきをなくし続ける。
信頼性への取り組み 人員が基準に従っているかどうか監視する。経営者は、計画と照らし合わせた実績に応じて個人への報奨制度 を活用する。 仕事に対する誇りとチームワークの方が、個人への報奨金よりもモチベーションを上げる。信頼できる透明性をもって、チーム構成員全員がチーム全体の実績データを参照できるようにする方が、上司から命令されるよりも効果がある。

(注u) ばらつきと依存事項の相互作用による負の影響は、制約理論の中核である。たとえば次の書籍を参照。 Eliyahu M. Goldratt, The Goal (North River Press, 1986). 【邦訳】『ザ・ゴール― 企業の究極の目的とは何か』三本木亮訳(ダイヤモンド社、2001 年)

(注1)ここでバリューアップ手法と呼んでいる手法を最初に大きく取り上げたのは、次の書籍である。 Gerald M. Weinberg, Quality Software Management, Volume I: Systems Thinking (New York: Dorset House, 1992). 【邦訳】『ワインバーグのシステム思考法― ソフトウェア文化を創る(1)』大野徇郎訳(共立出版、1994 年)


(注o)アジャイルプロジェクト宣言についてはhttp://www.pmdoi.org/を参照。これもバリューアップ手法の一例である。


Microsoft .NETはエンタープライズのシステム基盤として、多くの企業向けシステムでの開発基盤、および運用プラットフォームという形で導入が進んでいる。 .NETにかかわるキーマンたちの声を聞き、実際の導入事例を見て、.NETが開発をどう変えるのかを知ろう。
【注目インタビュー】 〜 .NETのキーマンがエンタープライズ戦略を語る
Visual Studio Team Systemで実践する ソフトウェアエンジニアリング
【導入事例】 〜 SIerに聞く。エンタープライズ向け.NET導入の実際
第1回
日本ユニシス株式会社
第2回
株式会社 富士通関西システムズ
第3回
アバナード株式会社
第4回
株式会社アークウェイ
第5回
株式会社ビジネス・インフィニティ & 株式会社NTTデータ

提供:マイクロソフト株式会社
企画:アイティメディア 営業局
制作:@IT編集部
掲載内容有効期限:2007年6月29日
 



■関連リンク


マイクロソフト株式会社

Microsoft .NET

Microsoft .NET Framework

Microsoft Visual Studio 2005 Team System

■Microsoft .NET関連記事


Microsoft Visual Studio 2005による Webアプリケーションテスト技法
第3章 VSTSとTFSによるソフトウェアテストの全体
第4章 4.3 データアクセスクラスに対する単体機能テスト
第5章 テストチームによる結合機能テストの実施
【連載】.NETの動作原理を基礎から理解する!
第1回 .NETアプリケーションを動かす土台
第2回 .NETアプリケーションが起動する仕組み
第3回 .NETアプリケーションが実行される仕組み
■ 連載完 ■
【特集】.NET開発者のための開発プロセス入門
【前編】 アジャイル開発を導入できていない.NET開発者たちへ
【後編】 .NETでアジャイルを導入するための実践テクニック
【連載】.NETで始めるデザインパターン
第1回 .NET開発におけるデザインパターンの有用性
第2回 うまくデザインパターンを使うための心得
第3回 リファクタリングにより導き出すStrategyパターン
第4回 リファクタリングで導き出すTemplate Methodパターン
第5回 Compositeパターンを導き出すための準備

第6回 リファクタリングにより導き出すCompositeパターン
第7回 デザインパターンの落とし穴

■ 連載完 ■


 
@ITトップ|@IT Special インデックス|会議室|利用規約|プライバシーポリシー|サイトマップ