BOOK Preview 新訳 ソフトウェアプロジェクトサバイバルガイド 第1章 サバイバルのトレーニングの勧め 第2章 サバイバルテスト マイクロソフトプレスの書籍紹介ページ 書籍情報のページ 2005/07/30

Page1 Page2

本コーナーは、.NET関連の新刊書籍から主要なチャプターをそのまま転載し、その内容を紹介するものです。 　同書は『Code Complete 第2版』などで著名なSteve McConnell氏による、開発プロジェクトを失敗させないための本です。プロジェクトを最後まで存続させるための基本的なサバイバル術となる、要求管理、プロジェクト計画、進捗状況の追跡、品質保証、変更管理などのマネジメント技法が平易かつ具体的に示されています。 　同書は、1998年に発行された書籍の新訳版（PMBOKに基づいて用語等が見直されている）ですが、その内容は現在でもまったく色あせておらず、プロジェクト開発の本質を突いていることに驚かされます。例えば、現在では主流となりつつあるアジャイル開発という言葉は当時まだありませんでしたが、ここでは「ステージ別納品」という、アジャイル開発の源流ともいえる開発方法が紹介されています。 　本稿では、書籍冒頭部分である第1章と第2章を転載しています。 　第1章ではプロジェクトのサバイバルを実現させるための第1歩として必要な要素を明確にします。続く第2章はプロジェクトの成功確率を評価するためのテストとなっています。現在あなたの手掛けているプロジェクトが生き残れるかどうかテストしてみてください。プロジェクトが失敗するか成功するかは前もって判断することができます。そして本書はその能力を身につけるための書籍です。 　なお、書籍の詳細については書籍情報のページをご覧ください。

　ソフトウェアプロジェクトが完了段階まで存続できる確率は、多くの場合、低い。しかし、この確率の低さは必然ではない。ソフトウェアプロジェクトを完了させるための第１歩は、プロジェクトを正しい手順を踏んで開始することである。きちんとした形で開始できれば、単に完了できるという以上のメリットが得られる。

第1章 ソフトウェアプロジェクトサバイバルのトレーニングの勧め

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

　私たちは、ソフトウェア製品に信じられないほど高い性能を期待する。それに比べて、ソフトウェア開発プロジェクトのパフォーマンスへの期待値は低い。ソフトウェア製品にユーザーがこぞって期待するのは、何時間実行し続けてもクラッシュしないこと、つまり何百万行というソースコード命令を実行しても、ほとんどあるいはまったくエラーが発生しないことである。しかし、ソフトウェアの開発者たちはソフトウェアプロジェクトにはるかに低い期待しか抱かない。ユーザーやクライアントは、製品の完成が1か月、3か月、あるいは半年遅れたり、製品が使いにくかったり、あるいは重要な機能が不足していれば苦情を言うだろう。しかし、ほとんどのソフトウェア開発者は、計画されていたソフトウェア製品がとりあえず一揃い完成すれば、どんなにコストが予算をオーバーしようと、納期が遅れようと、プロジェクトが成功したと考えるものである。あまりに数多くのプロジェクトの失敗を経験してきたために、プロジェクト全体が崩壊さえしなければ、失敗だとは思えなくなってしまっているからだ。

　ソフトウェア業界の経営責任者たちは、現在行われているレベルよりも高いレベルを達成するためには何が必要なのか、何年も前からわかっている。プロジェクトが成功したと言えるためには、コスト、スケジュール、品質の目標を満たしていなければならない。機能を大きく削ったり、スケジュールを引き伸ばしたり、予算の膨張を許したりしてはならない。詳細な計画案が作成されるようになった現在では［注1-1］、プロジェクトの目標を±10%以内の誤差で達成することが可能になっている。このレベルは、平均的なソフトウェアプロジェクトのプロジェクトマネジャーにとって達成可能なものであるが、多くの場合、経営者、役員、クライアント、出資者、エンドユーザー代表などのプロジェクトの「部外者」から、かなりの影響を受ける。

注1-1 Capers Jones 著『Assessment and Control of Software Risks』（Yourdon Press、1994年）

　筆者はConstrux Software Builders にチーフソフトウェアエンジニアとして勤務している間、多くの失敗プロジェクトについての調査を依頼された。経験を積んだ目から見れば、失敗の原因は多くの場合明白である。調査の結果、ソースコードが20,000 〜 250,000 行程度の中規模のソフトウェアプロジェクトの場合、ほとんどの失敗は避け得るものだった。もう1つ筆者が発見したのは、ソフトウェアプロジェクトというものは、いくつかの目標の中の1つに合わせて最適化できるということだ。最短のスケジュール、最低のコスト、最良の品質をはじめ、どんな目標でも達成可能である。しかし、これらの目標のすべてを同時に達成することは不可能だ。そこで本書では、これらの目標の最適なバランスを見つけ、効率的なスケジュールに従って、適正なコストで、高品質な製品をリリースできるようにする手法を説明する。

サバイバルニーズ

　ソフトウェアプロジェクトを成功させるための第1歩は、プロジェクトの最低限のサバイバルニーズを認識することである。アブラハム・マズローの学説によれば［注1-2］、人間の欲求は階層構造をなしており、人間は自然に、最下層の欲求からより高い欲求へと順に満たそうとする。この最下層の欲求が「サバイバルニーズ」である。これは、生存するために最低限必要な人間の肉体的な欲求を指している。図1-1で点線の下に示されている下位の欲求が満たされなければ、人間はその上の階層を満たそうとはしない。つまり、食料、空気、水に対する生理的欲求が満たされたとき初めて、その上の階層の「帰属」と愛、自尊心、あるいは自己実現という欲求に基づいた行動に移ることができるのである。

注1-2 Robert A. Baron、Donn Byrne、Baryy H. Kantowitz 共著『Psychology: Understanding Behavior 2nd edition』（Holt, Rinehartand Winston、1980年）

　筆者は、ソフトウェアプロジェクトにも同じような欲求（ニーズ）の階層が存在することに気付いた。これは、筆者ばかりでなく、多くのソフトウェアの専門家が気付いていることだろう。ソフトウェアプロジェクトにも基礎となるサバイバルニーズがあり、これが満たされなければ、プロジェクトチームはそのプロジェクトの高度なレベルのニーズを満たすための行動に移ることができない。そして、この階層の高度なレベルでこそ、品質と生産性を劇的に改善することができるのである。

図1-1 マズローが示した人間の欲求の階層図。下の層の欲求が満たされて初めて、上の層の欲求を追求できるようになる。

　具体的に述べれば、プロジェクトチームは、そのプロジェクトを必ず完遂できるという確信が持てたときに初めて、スケジュールやコスト面で予算の± 10%以内を達成できるかどうかに関心を向けることができる。また、プロジェクトチームはスケジュールどおりに納品できるようになって初めて、短いスケジュール、限られた予算で最高の製品を作れるようにプロジェクトを洗練させていくことができるのである。

　図1-2に示したのは、ソフトウェアプロジェクトのニーズの階層構造である。これは、プロジェクトの個々の参画者の欲求とは必ずしも一致しない。たとえば開発者なら一般的に、健全なチーム力学に対する欲求よりは、個人の自己評価を重要なものと考えるだろう。しかし、プロジェクト自体にとっては［注1-3］、チームの個々のメンバーの高い自己評価に対する欲求より、健全なチーム力学に対する欲求の方が一般的に大きくなるのである。

注1-3 『Information and Software Technology』第35巻第8号（1993年）のB. Lakhanpal 著「Understanding the Factors Influencing the Perfomance of Software Development Groups: An Exploratory Group-Level Analysis」（pp.468-473）

　本書では、ソフトウェアプロジェクトのニーズのうち、最下層のレベルに焦点を当てて解説する。上のレベルについて触れるのは、主に下の層の必要性を満たす前に上のレベルについて検討する必要がある場合に限る。

図1-2 ソフトウェアプロジェクトのニーズの階層。プロジェクトのニーズは参画者個人の欲求とは微妙に食い違う場合がある。

サバイバルに関する権利

　ごたごたの多いプロジェクトは、関係者のサバイバルニーズを脅かす。顧客にしてみれば、プロジェクトの完了が遅れて目的が達成できないのではないか、あるいは、完了したときにはコストが予算限度を超えてしまうのではないか、そもそも完了しないのではないかなどの不安を抱いている。マネジャーの立場では、顧客がプロジェクトをキャンセルして自分が無能だと思われてしまうのではないか、あるいは、開発者たちにプロジェクトを完了できるだけの力量がないのではないかと心配になる。開発者は、自分が解雇されるのではないか、解雇されないためには自分の余暇を何百時間も犠牲にし、プロジェクトに対する忠誠心を示さなければならないのではないかと悩まされることになる。こうした状況に陥ると、それぞれの立場の個人は、プロジェクトのニーズの下層レベルに後退してしまい、取りあえず自分の責任をまっとうするという「安全性のニーズ」を満たすことにばかり専念することになってしまう。こうした対応の結果、各個人は上位レベルの要求を満たすことをあきらめることになり、したがって、上位レベルのニーズである品質と生産性の向上が達成できなくなるのである。

　17世紀のイギリスの哲学者トマス・ホッブスによれば、群衆による支配の下での人生は、孤独で、貧しく、不快で、野蛮で、短命に終わるそうである。正しく運営されていないソフトウェアプロジェクトの仕事も、孤独で、貧しく、不快で、野蛮で、しかも不必要に長いように感じられることだろう。ソフトウェアプロジェクトのサバイバルを実現するための第1歩は、すべての関係者が互いを敬意をもって遇するという了解である。そこで、ソフトウェアプロジェクトに適用することを想定して、互いを尊重するための規則をまとめた「顧客の権利章典」というものを作成してみた［注1-4］。場合によっては、プロジェクトに特定の顧客がいないこともある。こうした場合、次に紹介する権利は、顧客の代わりにプロダクトマネジャー、営業担当者、エンドユーザー代表の権利だと考えてもよいだろう。

注1-4 関連する内容を持つ資料として、Tom Gilb 著『Principles of Software Engineering Management』（Addison-Wesley、1988 年）の「Company Communication Bill of Rights」がある。

表1-1 顧客の権利章典 顧客は次の権利を持つものとする。 1. プロジェクトの目標を設定し、その目標に従ってプロジェクトを進めさせる。 2. ソフトウェアプロジェクトが必要とする期間とコストを把握する。 3. ソフトウェアに含める機能、ソフトウェアから除外する機能を決定する。 4. プロジェクトの全期間を通じ、要求に妥当性のある変更を加え、その変更に要するコストを把握する。 5. プロジェクトの状況を明確かつ確実に把握する。 6. コスト、スケジュール、品質に影響を及ぼす可能性のあるリスクについて定期的な評価を受け、発生しうる問題に関する対応策の提案を受ける。 7. プロジェクトの全期間を通じ、プロジェクトの成果物を速やかに参照できる。

　筆者が最もよく知っている権利と言えば、アメリカ合衆国の「権利章典」に列挙されている権利である。これらの権利は、単に「あれば嬉しい」というだけのものではない。議会制民主主義を運用する上で不可欠のものである。同様に、ソフトウェアプロジェクトに関する権利も、ソフトウェアプロジェクトをより快適にするためだけのものではなく、ソフトウェアプロジェクトを適正に維持管理するために不可欠なものである。

　ソフトウェアプロジェクトに関する考え方で、もう1つアメリカ合衆国の「権利章典」と共通しているのは、一方にとっての「権利」は、他方にとっての「義務」になるという前提である。私たちは皆、「言論の自由」という権利を享受している。しかし、自分がその権利を享受するためには、その代償として他人の言論の自由の権利を認めなければならない。たとえ、自分がその人の意見に反対であっても、あるいはその人の発言に気分を害されるようなことがあっても、許容する必要がある。ソフトウェアプロジェクトの場合なら、顧客は自分に与えられた権利の代償として、プロジェクトチームの権利を認めなければならないのである。プロジェクトチームの権利を次に紹介する。

表1-2 プロジェクトチームの権利章典 プロジェクトチームは次の権利を持つものとする。 1. プロジェクトの目標を把握し、優先事項を明確にする。 2. どのような製品を作ることを求められているのかを詳細に把握し、製品の定義が不明確な場合には明確にする。 3. ソフトウェアの機能に関する決定に責任を持つ顧客、マネジャー、営業担当者などと速やかに連絡を取れる。 4. プロジェクトの各フェーズにおいて、技術的に確実な作業を行う。特に、プロジェクトの仕様が整わないうちから、コーディングを開始するよう強制されない。 5. 自分が担当する作業について、どのような作業であってもその工数とスケジュールの見積りに発言権を持つ。この権利には、次のような権利も含まれる。 　 ・ プロジェクトの各ステージにおいて論理的に可能なコストとスケジュールの見積りのみを行う。 　 ・ 適正な見積りを作成するために必要な時間を取る。 　 ・ プロジェクトの要求が変更された場合には必ず見積りをし直す。 6. 自分のプロジェクトの状況報告が顧客と経営上層部に正確に伝わる。 7. 頻繁に作業を中断させられたり集中力を乱されたりすることなく、生産的な環境で作業できる。特に、プロジェクトの核心部分のときにはなおさらである。

　プロジェクトを成功させるための第1歩は、プロジェクトの成功を可能にするこれらの権利を、すべての関係者が互いに認め合うことである。そして次の１歩は、各関係者のサバイバルニーズが完全に満たされ、どの関係者も脅威を感じることがない方法でプロジェクトを運営することである。具体的な方法は、本書の第2章以降で説明する。

サバイバルチェック

　各章の最後にサバイバルチェックを用意してある。それぞれの項目は、プロジェクトを客観的に評価する際の目安となる特徴を述べたものである。これを利用して、プロジェクトの健全度を判断していただきたい。

　成功への鍵となるポイントには、親指を立てたOKサインが付いている。これらの特徴が見られるプロジェクトは、成功に向かっていると言える。危険な落とし穴には爆弾のマークが付いている。この特徴が見られるプロジェクトは、危険な状態にあると言える。

サバイバルチェック プロジェクトチームのサバイバルニーズが満たされている。 顧客とプロジェクトチームが、ソフトウェアプロジェクトに関する相互の権利を尊重することに同意している。 　 原則的な同意が、実際には守られていない。

　

INDEX
	新訳 ソフトウェアプロジェクトサバイバルガイド
	第1章 サバイバルのトレーニングの勧め
	第2章 サバイバルテスト

　

「BOOK Preview」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）