「プロジェクト管理」を管理するために：The Rational Edge （25）（5/5 ページ）

[Michael F. Hanford（IBM），＠IT]

◇ プログラムの立案

　プログラムの立案では、大半のマネージャがプログラムの個々のコンポーネントプロジェクト向けに繰り返される計画を特定し、実行するボトムアップの手法を取るのが一般的だ。最初に、スタンドアロンプロジェクトで用いるプランニングと同様のテクニックと手法を使って、プロジェクトの製品や結果を出すために必要な資源を各プロジェクトマネージャが見積もり、割り当てる計画を立てる。

　そして、計画の次の段階では、マネージャがプログラムのプロジェクト間のつながりと依存を特定し、自分たちのプロジェクト計画を洗練させ、立て直して、ほかと統合する。この統合作業では、各プロジェクトで計画された製品、必要な資源の種類と量、そして当然ながらスケジュールの調整が必要になる場合が多い。プロジェクト間の管理と調整を継続するマネージャの能力は、プログラムの成功を決定付ける重要な要素だ。この能力は、プロジェクト計画の要件とプログラム計画との間の重要な差別化要因でもある。

○ プログラム計画

　個々のプロジェクト計画が統合されたところで、今度はプログラムの立案作業を開始する。プログラム計画とは一体何だろうか？ 辞書を引くと、計画とは「目的達成のためにあらかじめ用意されたスキーマ、プログラム、あるいは手法、例：攻撃計画」とある。しかし、プログラム計画の立て方と使い方を見ると、それらがこの定義にはきれいに当てはまらないことに気付く。

　まず、プログラムのプロジェクト計画とは対照的に、プログラム計画は一連の反復作業では立てられないのが一般的だ。その代わり、立案作業には、個々のプロジェクト計画に対する一連の見直しと、その内容の要約を作り出す作業が関連してくる。このプロセスの中では、プロジェクト同士の衝突が明白になり、解決策が必要になる場合もある。この要約作業の目的は、すべてのプログラム作業に対する簡潔で有用な見解、タイムフレーム、そして必要とされる結果を生み出すことだ。例えば、1万件の作業を記述するプログラム計画にはこのような特性がない。

　プログラム計画は、作業の指示や資源の割り当てのためには使わない。これは、個々のプロジェクト計画の仕事だ。プログラム計画は、プログラム作業という地下の揺れが与える潜在的な影響を検知し、計測する地震計のようなものだと考えると良いかもしれない。コンポーネントプロジェクトが進行し、個々のプロジェクト計画が完成率、資源の費用、作業活動の暫定（最終）日程を記録していくと、プログラム計画がこれらのデータを統合し、これらの集合的な影響を示す。これにより、マネージャがプログラムの進ちょく度を評価し、潜在的な問題を検知できるようになる。例えば、あるプロジェクトが構築を進めているコンポーネントにクライアントが新機能の追加を求めると、これがほかのプロジェクトへのコンポーネントの納入を遅らせてしまい、これらにも遅れを生じさせてしまう。

　要するに、プログラム計画が重要な計画活動と個々のプロジェクトの成果を統合して示すことにより、マネージャは、これまで積み重ねられてきたプログラム作業の進ちょくが分かるようになる。マネージャは、これを使うことで、プログラムが業務目標の達成に向かって正しい方向に進んでいることを確認し、計画にない変更が発生している可能性のある場所を特定し、その潜在的な影響を評価して、考えられる調整や修正作業の影響についてモデリングやテストを行う。

◇ 結論

　本稿では、プロジェクト・マネジメントとプログラム・マネジメントとの違いについて考えてみた。プログラムでは、プロジェクト・マネジメントの分野では一般に必要とされない機能や資源が必要で、これがプログラムの成功に直接結び付くことを学んだ。

　一般には、大半のプロジェクト作業よりプログラム作業の方が規模も影響も大きい。プログラム作業の成果は、ビジネスと製品の存在価値に大きな影響を与える場合がある。これらの作業は、資金も潤沢に必要とし、これがプログラム全体もしくは一部の継続か中止という厳しい選択を迫られる状況にもつながる。例えば、1960年代の米国の宇宙計画は人間を月に立たせ、米国経済に大量の新製品と工学力をもたらしたが、そのために納税者の数百億ドルもの税金が使われ、ほかの国家構想を不可能にしてしまった。この計画への資金投入は、数多くの難しい選択を下した結果だった。

　一般的には、多数のスタッフが関与するプログラム作業の方がスタンドアロンプロジェクトより士気が高まる。この士気は、プログラムが膨大な作業を達成するために役立つ（利点）が、同時にプログラムの方向転換の妨げともなる。ビジョンの欠如、ビジョンの変更、方向付けのまずさは、プログラムが真の価値や有益な結果を生み出すことなく、比較的短期間で膨大な費用を支出することにつながってしまう。

　幸いにも、プログラム・マネジメント固有の論理的に正しいテクニックと手法を適用すれば、作業の成功とリスク低下の可能性が高まる。企業レベルの作業では、これらの手法によって組織がビジネス戦略を追求し、競争力を維持できるようになる。

［筆者について］

Michael F. Hanford

　Michael F. Hanfordは、IBM SUMMIT Ascendant方法論部門の方法論責任者で、IBM Rational市販方法論コンテンツチームのメンバーでもある。同氏には方法論に関する著作があり、大手コンサルティング会社でマネージャを経験したほか、IBM Rationalや英PriceWaterhouseCoopers Consulting（PWCC）では企業プロセスの評価および転換作業を指揮している。PWCC入社前は、Fidelity Investments Systems Companyでソフトウェアエンジニアリング事業部長を務めていた。

［参考文献］

▼IBM Rational SUMMIT Ascendant, 『The Program Management Method.』 Version 8.1, 2004年2月刊

▼Office of Government Commerce（OGC）：HMSO, 『Managing Successful Programmes.』Copyright 2003.

▼Deborah Kezsbom, et al., Dynamic Project Management John Wiley & Sons, 1989年刊

---

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

---

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