プロジェクトのはじめに計画を立てるのは無謀/プロジェクトの状態を評価する：パート1（前編）：The Rational Edge（2/2 ページ）

[Kurt Bittner，IBM新技術プログラムディレクター]

評価と反復開発

　反復型アプローチの重要なメリットの1つが、下の図2のようにプロジェクト全体で分散を意識的に削減することだ。このイラストが図1のサンプルを横にしたもので、反復型ライフサイクルの最後に向かって分布をかなり狭めていることに注意したい。

図2 プロジェクト全体で分散を削減する反復開発アプローチ

　「x」軸は予測の期待値を示し、上下の点線はこれらの予想の変動を示す。図3にあるように、プロジェクト全体を通じてリスクが減れば変動も減少する。

図3 反復プロジェクトでは、分散と不確定要素に大きく寄与するリスクが徐々に低下していく

　図3にある「方向付け」「推敲」「構築」、そして「移行」の4つのフェイズは、さまざまなタイプのリスク軽減にそれぞれが重点を置いている。その結果、各フェイズの目標も異なってくる。つまり、プロジェクトの目標達成に向けた進ちょくの監視に利用する評価値はフェイズごとに変化していく必要がある。

評価に誤りがある場合

　多くの組織が進める手法で絶対に最悪なのが「詳細な計画を立ててから計画の評価を行う」ことだ。計画と評価自体は悪いことではないが、実際のところ大半の組織が採用するタイミングは、単独のどの手法よりも誤った行動につながりやすい。以下に典型的な例を述べる。

　■ プロジェクトが始まると、プロジェクトマネージャはその最初の行動の1つとしてプロジェクトの計画を立てる。プロジェクトマネージャは、解決する問題に関する大ざっぱな情報と漠然とした目標に基づき、スケジュールとコストの「推測」に最善を尽くす

　■ 計画が一時的なものであること。どれだけ警告しても、計画は独り歩きする。組織の上層部は、初期の計画が実際には基にされた仮定と有効性が変わらない思考実験にすぎない、という事実を見失う。計画は、成功を想像した予言のようなものになり、管理の焦点は、プロジェクトを成功に導く作業よりも、計画からの偏差を評価することに移ってしまう。計画はプロジェクトマネージャに重くのしかかる制約のようなものとなる。[注1]

---

[注1] 制約の参照が分かりにくい場合は、Samuel Taylor Coleridgeの「老水夫行」をお読みいただきたい。

---

　■ 計画がプロジェクトの日常の現実と懸け離れた完全な虚構であることが全員にとって明白でも、プロジェクトチームのメンバーは計画に合わない行動をためらう。計画が理論的に正しくても、これがそうなる確率はかなり低い。このような計画が未来の完全な予想に失敗することが避けられないと、それにちゅうちょすることなく従うマネージャは自分のチームやプロジェクトを失敗へと追い込んでしまう。

　計画が現実に沿わない場合の唯一の論理的対策は、計画を逸脱することだけだが、管理システムが計画からの逸脱を許さない場合、たとえそうでなくても計画に従っているのだと自分たちに思い込ませるしか、チームには選択肢がなくなる。このような行動は誰にとっても良いことではない。

　なぜこのようなことが起こるのだろうか？ 問題は本質的な計画ではなく、現実を見ず、経験に反して計画を立てることにある。問題は、情報が不十分で全く計画できないことまで細かく計画し、構成に従う「責任」をチームに課すことだ。

　アプローチとしては、プロジェクトの着地点を理解し、その目標に向け、プロジェクト全体を通じて柔軟に方向付けを行う方が良い。そのためには、プロジェクトの各場面ごとに適切な情報を探す必要がある。

あらかじめ詳細な計画を立てるのはなぜ悪いのか？

　プロジェクトのはじめに詳細な計画を立てることがなぜ悪いのかは前述したが、このような手法は、幅広く普及し、その利用を控えるのに特別な注意が必要なほどプロジェクト管理ではあまりにも慣例化している。手短にいえば、プロジェクトの初期段階で詳細な計画を立てて管理を行うことは、以下の理由から誤りである。

　■ プロジェクトマネージャにはプロジェクトの各作業と、その技術作業のタイミングを決めるのに必須の深い技術力があるはずだ、と想定するのは非現実的だ。マイルストーンや目標は決められるが、これらの目標達成に必要な実際の作業は、プロジェクトマネージャの技術的理解を超えるものだ。十分意味のある精度で計画を立てるのに必要な技術専門知識には、大規模な開発チームの関与が必要であり、プロジェクトマネージャによる「計画作業」は、いずれもせいぜい憶測の域を出ないレベルである可能性が高い

　■ プロジェクト開始初期における具体的なアプローチの不確実性は非常に高く、開発チームの立てた詳細な計画でもかなり不確実だ。プロジェクト開始後数日もしくは数週間は、解決すべき問題や達成すべき目標に関するものでさえ、信頼性の高い情報に欠けるのが特徴だ。この不足する情報に照らした詳細な計画は時間の無駄にすぎない

　■ もし詳細な計画の立案が時間の無駄であるなら、プロジェクトの初期段階で作成した詳細な計画に合わせた評価は危険であり、プロジェクトを失敗へと追い込むことが多い。脆弱性や欠陥のある計画で人を責めれば、情報を得られたときに適切な行動に出ようとするやる気を失わせてしまう。また、計画の指示だからといって間違った行動に出ることを余儀なくさせる可能性もあるし、もっと多いのが、「二重計画書」の用意を促すケースだ。これは、「本物」のプロジェクト作業用の計画だけでなく、オリジナルにさかのぼれるが脆弱性のある評価用の計画も用意するというものだ。どちらにしても、早めに詳細な計画を立てると誤った行動が助長される

　では、詳細なプロジェクト計画に付け合わせてプロジェクトを評価するのが適切なアプローチでないのであれば、プロジェクトが順調かどうかを保証するには何を評価すればよいのだろうか？

フェイズごとの評価対象決定

　簡単にいえば、プロジェクトではポイントごとに評価が必要なものも変わる。プロジェクトは、統合プロセスの4つのフェイズ（「方向付け」「推敲」「構築」、そして「移行」）に分解でき、それぞれが関連するリスクに付随した異なる目標に重点を置く。つまり、フェイズごとに異なるリスクの軽減に重点を置くのだ。

　しかし、リスクについて説明する前に、図4で推奨されるフェイズごとの大まかな目標を理解することが重要だ。

図4 4つのライフサイクルフェイズそれぞれに関連する目標と目的（クリックすると拡大）

　今回および次回以降では、これらの目標達成に向けてプロジェクトが順調に進んでいるかどうか判断するための、適切な評価値の確認方法について説明する。

---

本記事は「The Rational Edge」に掲載された「Measuring project health: Part One」をアットマーク・アイティが翻訳したものです。

---

「The Rational Edge」バックナンバー

• トランザクション管理の複雑性を克服する（パート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プロジェクトを見える化する
• ユーザー要件を引出すテクニック： ユースケースかストーリーボードか
• オブジェクト指向を超えて
• ルネサンスの巨匠たちに学ぶエンジニアリングの技
• ソフトウェア開発の「いま」と「近未来」の話
• 中国のソフトウェア開発現場はこんなにスゴイ
• 隣のテストチームが優秀ないくつかの理由（後編）
• 隣のテストチームが優秀ないくつかの理由（前編）