第 章 1 学習内容 1. IT 分野におけるプロジェクトマネジメントの重要性 2. プロジェクトの意味と IT プロジェクトの例 3. プロジェクトマネジメント・フレームワークの構成要素 4. プロジェクトマネジメントと周辺分野との関係 5. プロジェクトマネジメントの歴史 6. 認定、研究、ソフトウェアなどプロジェクトマネジメント職を取り巻く環境 オープニング事例 大規模な小売チェーンを展開する会社の新しい CPO（Chief Project Officer：プロジェクト担 当副社長）として着任したアン・ロバートは、会社の講堂に集まった 500 人の社員を前に、新しい 戦略について話そうとしているところです。これはインターネットを通じて世界中にいる従業員、 供給業者、その他ステークホルダーにも配信されます。会社はこれまで、在庫管理の改善やウェブ 経由の商品販売、営業、流通プロセスの整備など新しい情報システムを導入するために長い時間を かけてきました。しかし、株価は下がり、景気は低迷しており、皆不安な面持ちで企業の新しい戦 略に耳を傾けています。 アンは、話し始めました。「おはようございます。皆さんはもうお聞きになっていると思います が、このたび社長より新たにプロジェクト担当副社長の役を申し受けました。今やわれわれの活動 の多くがプロジェクトに関わっています。私の任務は、適切なプロジェクトの選択と管理によって、 会社の業績を回復することです。われわれに与えられた課題は、この厳しい状況において、お客様 に高品質な製品とサービスを提供し、利益を上げるために一致団結することです。これを実現する には、複雑な問題を解決するための協力体制が不可欠です。最もビジネスに貢献できるプロジェク トはどれか、IT をビジネスにどう生かすか、いかに人材を有効活用してプロジェクトの計画・実行 をつつがなく進めるか、これらを皆で考えていかなくてはいけません。これに成功した時に、われ われは一流の企業となれるのです。 」 「失敗した時は？」聴衆からの質問にアンは答えました。 「失敗 という選択肢はないものとしましょう！」 16 第 1 章 プロジェクトマネジメント概要 1-1 はじめに 今プロジェクトマネジメントの分野にあらためて関心が寄せられています。1980 年代までのプ ロジェクトマネジメントは、おもに軍や建設業界において、スケジュールやリソースに関するデー タを経営陣に報告するためのものでした。今日でもこれらの主要なデータを把握することは大事 ですが、今ではそれだけでなくさらに広いマネジメントが行われるようになり、あらゆる業界の 人々がプロジェクトマネジメントを進めています。また、多くのビジネスにおいて新しい技術が 多大な影響力を持ってきており、コンピューター、ソフトウェア、ネットワークなどの活用が進 み、分野を越えた世界規模のチームでの活動もあって、仕事環境は劇的に変わりました。以下の 統計データが現代社会におけるプロジェクトマネジメントの重要さを示しています。 ■ 米国は、毎年四半期分の国民総生産に相当する ■ 世界全体では、40.7 ■ 1,600 兆ドルの総生産のうち 10 兆ドルをプロジェクトで使っています。 万人以上の人がプロジェクトマネジメントに関わる職業についています。 ■ プロジェクト・マネジャーは、平均 ■ 2000 2.3 兆ドルをプロジェクトに費やしています。 82,000 ドルの年収を得ています※ 1 。 年中に 30 万、2001 年中に 50 万以上の IT アプリケーション開発プロジェクトが実施さ れました※ 2 。 ■ 著名なビジネス書の著者やコンサルタントがプロジェクトマネジメントの重要性を強調して います。トム・ピータースは著書『Reinventing Work: the Project 50』で「今日を生き残る ためにはプロジェクト手法を身につけることだ。 」と述べています。 今日の企業、政府、NPO における成功の鍵は、モダンプロジェクトマネジメントの手法を熟知 することにあるのです。 失敗例 1995 年にスタンディッシュ・グループは CHAOS（カオス）と呼ばれる有名な研究結果を発表 しました※ 3 。この一流コンサルティング会社は、8,380 以上の異なる IT アプリケーションを管理 する米国の 365 人の CIO に調査を行いました。タイトルのとおり、IT プロジェクトはまさにカオ ス状態でした。1990 年代の前半には、米国の企業は、約 17 万 5,000 の IT アプリケーション 開発プロジェクトで 2,500 億ドルものコストをかけていました。たとえば、運輸省のデータベー ス開発、レンタカーやホテルの予約システム、銀行のクライアント・サーバー・システム導入など のプロジェクトがありました。大企業における IT 開発プロジェクトの平均コストは、230 万ドル 以上でした。中堅企業では、130 万ドル、小さな企業でも 43 万 4,000 ドル超を費やしていまし た。また、IT プロジェクトの成功率は、たったの 16.2%でした。ここでいう成功の基準は、プロ ※1 ※2 Project Management Institute（PMI）, The PMI Project Management Fact Book, Second Edition, 2001 The Standish Group, "CHAOS 2001:A Recipe for Success" （wwww.standishgroup.com） （2001） 1-2 プロジェクトとは 17 ジェクトの目標を予定どおりの期限と予算で達成できたかどうかで判断しています。1995 年に ジェクトはカオスである。われわれは、これ以上失敗を無視し続けるわけにはいかない。」 多くの組織で以下のようなプロジェクトマネジメントの利点をあげています。 ■ 財務的、物理的、人的資源の有効活用 ■ 顧客との関係向上 ■ 開発期間の短縮 ■ コスト削減 ■ 品質と信頼性の向上 ■ 利益率の向上 ■ 生産性の向上 ■ 社内調整の改善 ■ モラルの向上 本章では、プロジェクトとプロジェクトマネジメントについて紹介します。他の分野との違い、 プロジェクトマネジメントの歴史、また仕事としての広がりの様子もお伝えします。多くの異な る業界のさまざまなタイプのプロジェクトがありますが、本書は特に IT（情報技術）に特化して 説明していきます。 1-2 プロジェクトとは プロジェクトマネジメントについて話をするためには、プロジェクトの概念をしっかり理解し ておく必要があります。 「プロジェクト」とは、 「独自の製品やサービスを創造するために実施さ れる有限的な活動」※ 4 と定義されます。プロジェクトは通常相互に関係のあるいくつかの作業を 複数の人で実施します。プロジェクトの受益者（顧客）は、リソースを有効に活用し、適切な期 間内にそれを完了することを求めます。 ■ 独自な目的：どのプロジェクトも明確な目標があります。オープニング事例の CPO であるア ン・ロバートは、会社の業務改善に役立つ IT プロジェクト候補のリストを作成して初期分析 を行うために、IT コラボレーション・プロジェクトに投資することにします。ここでの独自 な目的は、全社員からのアイデアを基に報告書を作成することです。その結果に基づき、さ らに深い議論や次のプロジェクトへとつなげることができます。このように、プロジェクト ※3 ※4 The Standish Group "CHAOS" www.standishgroup.com/chaos.html（1995） Jim Johnson "CHAOS: The Dollar Drain of IT Project Failures" Application Development Trends（1995 年 1 月） r Project Management Institute, Inc. A Guide to the Project Management Body of Knowledge（PMBOK Guide） （2000）p.4 1 章 IT 業界におけるプロジェクトマネジメントの必要性を説いてこう言っています。「ソフト開発プロ 第 は、IT プロジェクトの 31%が 810 億ドルもの損失を出して中断されました。この研究の著者は、 18 第 1 章 プロジェクトマネジメント概要 は必ずユニークな製品、サービス、成果物などを生み出します。 ■ 有期性：プロジェクトには必ず開始と終了があります。アンのプロジェクトでは、すぐにチー ムを編成して、1 ヵ月以内に報告書をまとめ、取締役への結果説明を行うことが期待されて います。 ■ さまざまなリソースの使用：リソースには、人、ハード、ソフト、その他の資産を含みます。 プロジェクトが複数の部署や組織にまたがって行われることは珍しくありません。IT コラボ レーション・プロジェクトの事例では、情報システム、マーケティング、営業、流通、他の部 署が協力してアイデアを出しあう必要があるでしょう。また、外部のコンサルタントを雇っ てアドバイスを受ける必要があるかもしれません。実施プロジェクトを決定した後は、具体 的なハード、ソフト、ネットワーク機器などのリソースが必要になるでしょう。製品業者や コンサルタントなど他社からの人材も目的達成に必要な大事なリソースです。どのリソース も無限に使えるわけではありません。プロジェクトや企業の目標を達成するために有効に活 用しましょう。 ■ 主要な受益者（顧客）またはスポンサー：どのプロジェクトにも多くの関係者またはステー クホルダーがいますが、誰かが必要な経費の支払い責任を持たなければなりません。通常ス ポンサーがプロジェクトに投資し指針を決定します。IT コラボレーション・プロジェクトの 場合、アン・ロバートがスポンサーです。ただし、実施プロジェクトが決定した場合、その プロジェクトのスポンサーは、関連する部署のマネジャーになるでしょう。たとえば、営業 部門がインターネットを使った直接販売を手がける場合には、営業副社長がスポンサーにな ります。また、インターネットに関連した複数のプロジェクトを立ち上げる場合には、それ らを束ねてプログラムを作ります。複数のプロジェクトをひとまとめに扱うことによって、 個別に管理していたのでは得られないメリットを得ることができます※ 5 。プログラム・マネ ジャーは、それら複数のプロジェクトのプロジェクト・マネジャーや（おそらく複数の部署 にまたがる）スポンサーをまとめます。 ■ 不確実性：プロジェクトはユニークであるがゆえに、目的を明確に定義したり、期間やコス トを見積るのが難しい場合があります。この不確実性がプロジェクトマネジメントを難しい ものにする最大の要因です。新しい技術が絡む場合は特にそうです。 良いプロジェクト・マネジャーは、プロジェクトの成功に不可欠です。プロジェクト・マネジャー は、スポンサーやチーム・メンバー等と協力して、プロジェクトの目標達成の責任を負います。 どのプロジェクトも、スコープ、タイム、コストに関する異なる目標があり、これら 3 つの目 標が制約になります。これを「 制約 3 条件」と呼びます。プロジェクトを成功に導くためには、 時に競合するこれら制約 3 条件のバランスをとりながら進める必要があります。プロジェクト・ マネジャーはいつも以下の 3 つを気に留めておく必要があります ■ スコープ：何を達成するか。顧客やスポンサーが期待しているユニークな製品やサービスと はどんなものか。 ※5 r Project Management Institute, Inc. A Guide to the Project Management Body of Knowledge（PMBOK Guide） （2000）p.10 1-2 プロジェクトとは 19 ■ タイム：プロジェクトを完了するための期間はどのくらい必要か。スケジュールはどうす 第 るか。 図 1-1 は、制約 3 条件の次元を示しており、プロジェクトごとに各次元の目標があります。オー プニング事例としてあげた IT コラボレーション・プロジェクトでは、30 ある IT プロジェクト の候補に関して 40〜50 ページ程度の報告書を作成し、1 時間の報告会を実施するという初期のス コープがあります。プロジェクト・マネジャーは、各プロジェクト候補ごとに何を調べるかを決め ることでスコープをより詳細に定義します。他社での同じようなプロジェクトの実施状況、時間 とコストの概算見積り、リスクと利益見通しの 3 段階評価などです。当初の時間見積りを 1 ヵ月 とし、コスト見積りを 5 万ドルとします。このように具体的な期待値を定義することで、スコー プ、タイム、コストの各次元の目標が決まってきます。 プロジェクトマネジメントの成功とは、 3つの目標（スコープ、タイム、コスト） をすべて達成してスポンサーの満足を 得ること！ ターゲット 図 1-1 プロジェクトマネジメントの制約 3 条件 制約 3 条件を管理するということは、スコープ、タイム、コストの間のトレードオフを調整する ことにほかなりません。たとえば、スコープとタイムの目標を達成するために予算を増やさなけ ればならないかもしれません。もしくは、タイムとコストを優先させてスコープを多少狭めると いう手もあります。不確実性やリソースの制約などから、当初の予定どおりのスコープ、タイム、 コストでプロジェクトを完了できるケースは非常にまれです。プロジェクトが進むにつれて、ス 1 章 ■ コスト：プロジェクトを完了するためのコストはどのくらい必要か。 20 第 1 章 プロジェクトマネジメント概要 ポンサー、チーム・メンバー、その他のステークホルダーそれぞれが異なる見方を持つようになり ます。たとえば、IT コラボレーション・プロジェクトで、プロジェクト候補案を募るために、全 社員にアンケートメールを送り、解答のとりまとめを行う担当者を各部署に 1 週間だけ配置しま す。しかし、良いアイデアが少ししか集まらず、中には非協力的または不適任な担当者がいたと します。アンケート結果の分析を担当できる専門家を社内で調達できなかった場合どうしましょ う。追加予算をかけて外部のコンサルタントを雇うべきでしょうか。時間を延長するべきでしょ うか。それともスコープを見直すように交渉するべきでしょうか。また、たとえば CEO がプロ ジェクト候補を 30 ではなく 40 見つけてくるように主張した場合はどうすべきでしょうか。コス トやスケジュールを変更することなくこの追加要求を受入れるべきでしょうか。このような場合 にスコープ、タイム、コスト目標に関して現実的な決定を下すために、メンバーやスポンサーに 交渉することがプロジェクト・マネジャーの重要な役割なのです。 制約 3 条件は、プロジェクトの基本要素が相互に作用しあっていることを示唆していますが、 ほかにも重要な役割を果たす要素があります。顧客やスポンサーの満足に関係する「品質」も重 要な要素です。品質も含めて、スコープ、タイム、コスト、品質の 4 つの制約という場合もあり ます。顧客満足や品質を考慮することは、スコープ、タイム、コストの目標設定に内在されるも のだと言う人もいます。これを考慮しなければ、スコープ、タイム、コストの目標を達成できて も、品質標準を満たさないために、スポンサーの満足を得られないケースもあるということです。 たとえば、アン・ロバートが予定どおりのコストとスケジュールで、30 のプロジェクト候補に関 する 50 ページの報告書を受け取り、発表会で説明を受けることができたとしても、その品質が納 得いくものでなければどうでしょうか。アンの見解は、チーム・メンバーとは大きく異なるもの になるはずです。 どうすれば、このような問題を避けることができるでしょうか。その答えは、制約 3 条件を超 えたプロジェクトマネジメントが必要だということになるでしょう。 1-3 プロジェクトマネジメントとは プロジェクトマネジメントとは、プロジェクトの目的を達成するためのアクティビティに対し て知識、スキル、技法を適用することです※ 6 。プロジェクト・マネジャーは、特定のスコープ、 タイム、コスト、品質の目的を追求するだけでなく、プロジェクトに参加したり、影響をうける すべての人々の期待と要求に応えるようプロセス全体を調整しなければいけません。 図 1-2 は、プロジェクトマネジメントのフレームワークを示しています。フレームワークの主 要な要素には、ステークホルダー、知識エリア、ツールと技法、企業への貢献などが含まれます。 ステークホルダーは、プロジェクトの参加者やプロジェクト活動に何らかの影響を受ける人の ことで、スポンサー、チーム・メンバー、サポート要員、顧客、ユーザー、供給業者、そしてプロ ジェクトに反対する人々も含みます。各ステークホルダーは、それぞれまったく異なる要求や期 待を持っています。たとえば、家の建築はプロジェクトの例としてよく使われるものですが、こ こでもたくさんのステークホルダーがいます。 ※6 r Project Management Institute, Inc. A Guide to the Project Management Body of Knowledge（PMBOK Guide） （2000）P.6 1-3 プロジェクトマネジメントとは 21 プロジェクト・ ポートフォリオ 第 スコープ タイム コスト ツールと技法 品質 プロジェクト統合マネジメント ステーク ホルダー の要件と 期待 コミュニ 人的資源 ケーション リスク 1 企業 の成功 プロジェクト の成功 調達 補助機能 図 1-2 プロジェクトマネジメント・フレームワーク ■ スポンサー：この場合、スポンサーは新しい家の持ち主になる人です。また、その家に住む ために家賃を支払う人も含まれます。彼らは、予算が厳しいため、なるべく正確な見積りを 業者に要求しました。いつ引越しができるかとか予算内でどんな家が建てられるのか等も知 りたいでしょう。予算内に納めるために重要な決定を下さなくてはならないかもしれません。 すぐに基礎工事を終わらせることができるか、もしできるのであれば、引越し予定日に影響 が出るか、この例では、スポンサーが同時に成果物（家）の顧客兼ユーザーとなります。 ■ プロジェクト・マネジャー：この例でプロジェクト・マネジャーは、家の建設を請け負うゼ ネコン業者です。プロジェクト・マネジャーはすべてのステークホルダーのニーズや期待に 応える必要があります。 ■ プロジェクト・メンバー：家を建てるには、何人かの建築士、電気工事士、大工などが関わる でしょう。彼らは、何をいつやらなければいけないか確実に知る必要があります。また、必 要な部材や機材が現場に用意されているのか、それとも彼ら自身で用意しなければいかない のか。それぞれの作業が相互に関係しあっているため、それらを調整する必要があります。 たとえば、壁ができていないと大工がキッチンの戸棚を作りつけることができません。 ■ 支援者：購入者の雇用主、ゼネコンの秘書など他のステークホルダーを支援する人々のこと です。購入者の雇用主は、従業員に対して自分の仕事をきちんと遂行することを望むでしょ うが、たまに現場に行ったり、家の建築に関わる電話を受けたりする程度のことは許可する 柔軟性を持っているでしょう。ゼネコンの秘書は、顧客である購入者、受注業者、供給業者 などの間のミーティングの調整などを通してプロジェクトを支援します。 ■ 供給業者：家の建設には多くの部材が必要になります。供給業者は、木材、窓、床材、電気 製品などを供給します。彼らは、具体的にどの品目をいつどこに納品すればよいかを知る必 要があります。 ■ 対抗者：たとえば、建設工事の騒音が気になって家で仕事がはかどらないとか、寝ている子 供が起きてしまうといった苦情を持っている近所の人がいるかもしれません。苦情を聞いた 章 9つの知識エリア コア機能 プロジェクト1 プロジェクト2 プロジェクト3 プロジェクト4 プロジェクト5 プロジェクト6 22 第 1 章 プロジェクトマネジメント概要 り、正式な書面を用意するために作業を中断せざるを得ないかもしれません。または、近隣 関係の約束で新しい家のデザインや構造について規定があるかもしれません。その規定に従 わなければ、法的に建設を中止せざるを得ない事態もありえます。 このように、プロジェクトにさまざまなステークホルダーがおり、それぞれ異なるニーズと期 待を持っているのです。これらのニーズと期待はプロジェクトの開始から終了まで非常に重要で す。成功するプロジェクト・マネジャーは必ず、ステークホルダーのニーズと期待をしっかりと 理解し、彼らと良い関係を築いています。 プロジェクトマネジメントの知識エリアは、プロジェクト・マネジャーが持つべき主要な能力 を示しています。図 1-2 の中央部分に 9 つの知識エリアを示しています。スコープ、タイム、コ スト、品質の 4 つの知識エリアがコアとなります。これはいずれも、具体的なプロジェクトの目 的に関わるコア知識エリアです。 ■ スコープ：プロジェクト成功に必要なすべての作業を定義してそれらを管理します。 ■ タイム：作業の達成に必要な時間を見積り、現実的なスケジュールを作成し、計画どおりに プロジェクトを完了できるようにします。 ■ コスト：プロジェクトに必要な予算を確保して、それをコントロールします。 ■ 品質：約束した規定の要件、または想定された要件を満たすことを保証します。 このほかに 4 つの補助的な知識エリアがあります。これらはプロジェクトの目的達成のために 用いられるプロセス群です。以下にそれぞれの簡単な説明を述べます。 ■ 人的資源：プロジェクトに参加する人々の有効活用 ■ コミュニケーション：プロジェクト情報の生成、収集、配布、保存 ■ リスク：プロジェクトに関わるリスクの識別、分析、対応 ■ 調達：プロジェクト実施組織の外部からの物やサービスの調達 9 つ目のプロジェクト統合マネジメントは、すべての知識エリアと相互に関係し、全体を統括 する役割を果たします。プロジェクト・マネジャーはこれらすべての知識とスキルを習得しなけ ればなりません。 プロジェクトマネジメントのツールと技法は、実際にスコープ、タイム、コスト、品質などの マネジメントの支援をします。また、人的資源、コミュニケーション、リスク、調達、統合の各 エリアを支援するツールもあります。たとえば、有名なタイム・マネジメント・ツールとしては、 ガント・チャートやネットワーク図、クリティカル・パス分析などがあります。表 1-1 に知識エ リアごとによく使われるツールと技法をまとめてあります。これらのツールについては、より詳 しく、本書のそれぞれの章で学習します。 プロジェクト・マネジャーは、主要なステークホルダーとともにプロジェクトの成功指標を定 義し、適切なツールと技法を適用して、プロジェクトを成功させなければなりません。また、同 時にポートフォリオ・マネジメントによって、重要なビジネス戦略を支援しなければなりません。 これは、複数のプロジェクトを、企業全体の成功への貢献度によって分類し、投資計画をコント ロールするための手法で、第 7 章コスト・マネジメントで詳しく学習します。 1-3 プロジェクトマネジメントとは 表 1-1 23 知識エリアごとのツールと技法 スコープ・マネジメント NPV、投資対効果、回収期間 プロジェクト計画 重み付け得点モデル プロジェクトマネジメント・ソフトウェア ビジネスケース 変更管理委員会 プロジェクト憲章 コンフィギュレーション・マネジメント スコープ記述書 状況確認会議 ワーク・ブレークダウン・ストラクチャー 作業認可システム 作業範囲記述書（SoW） リーダーシップ 要件分析 マネジメントによる資金協力 タイム・マネジメント スコープ変更コントロール コスト・マネジメント ガント・チャート アーンド・バリュー・マネジメント ネットワーク図 プロジェクト・ポートフォリオ・マネジメント クリティカル・パス分析 コスト見積り PERT コスト・マネジメント計画書 クリティカル・チェーン・スケジューリング 財務ソフトウェア クラッシング ファスト・トラッキング マイルストーン・レビュー 品質マネジメント 人的資源マネジメント シックス・シグマ モチベーション技法 品質管理図 共感リスニング パレート図 チーム契約 魚の骨（石川）ダイアグラム 責任分担マトリックス 品質監査 資源ヒストグラム 成熟モデル 資源投下 統計的手法 資源平準化 チーム形成トレーニング コミュニケーション・マネジメント 調達マネジメント コミュニケーション・マネジメント計画書 内外製分析 コンフリクト・マネジメント 契約書 コミュニケーション・メディア選択 RFP と RFQ コミュニケーション基盤 発注先選定 状況報告書 交渉 ミーティング 電子調達 仮想コミュニケーション テンプレート プロジェクト・ウェブサイト リスク・マネジメント リスク・マネジメント計画書 可能性・影響度表 リスク順位 モンテカルロ・シミュレーション 上位 10 リスク項目トラッキング 1 章 ステークホルダー分析 第 統合マネジメント 24 第 1 章 プロジェクトマネジメント概要 成功例 スタンディッシュ・グループが 1998 年に行った 2 回目の調査では、IT プロジェクトにいくら かの改善が見られました。失敗プロジェクトのコストは 1995 年の 810 億ドルから 750 億ドル に減り、コスト超過は 590 億から 220 億ドルに減りました。また、1998 年の調査では、スコー プ、タイム、コストすべての目標を達成した IT プロジェクトは 26%、予算超過とスケジュール遅 延はあったが一応完了したのが 46%、完了できなかったものが 28%でした※ 7 。 2001 年の調査では、1995 年と比較して IT プロジェクトの明らかな改善が見られました。 ■ スケジュール遅延は、222%から ■ コスト超過は、189%から ■ 機能要件を満たした比率は 163%に劇的に改善 145%に減少 61%から 67%に増加 ■ 米国における成功プロジェクト数は ■ IT 28000 から 78000 に増加 プロジェクトの成功率は、16%から 28%に改善※ 8 このように IT プロジェクトにおいて著しい改善を果たしてはいるものの、まだ改善の余地がありま す。プロジェクト・マネジャーが成功のコツをつかんできているという良い話もあります。 「成功プ ロジェクトが増えてきている理由はさまざまでしょうが、まずプロジェクトの平均コストは半分以 下になっています。良い進捗管理ツールが考案され、よりスキルの高いプロジェクト・マネジャー が、良い管理プロセスを使うようになっていますが、最も重要なのは複数のプロセスが存在してい るという事実そのものでしょう※ 9 。」 プロジェクトマネジメントには、多くのメリットがありますが、成功を保証する特効薬という わけではありません。それは非常に広く、時に複雑な分野です。あるプロジェクトでうまくいっ た手法が他では通用しないこともしばしばあります。よってプロジェクト・マネジャーはたえず 実際のプロジェクト経験から学び続けなければいけないのです。ステークホルダー、組織、ビジ ネス環境などプロジェクトのユニーク性が、プロジェクトの難しさであり、かつ大きな魅力なの です。 1-4 プロジェクトマネジメントとその他の分野の関係 プロジェクトマネジメントに必要な知識の多くは、プロジェクトマネジメントに特有なもので す。しかし、プロジェクトマネジメントには、組織マネジメントの知識や経験、プロジェクトに ※7 ※8 ※9 The Standish Group, "1998 CHAOS Report" 1998. Cabanis, Jeanette, "Standish Research Indicates IT Project Success," PM Network （1998 年 9 月） The Standish Group "CHAOS 2001: A Recipe for Success" （2001） 同上 1-4 プロジェクトマネジメントとその他の分野の関係 25 関わる業界や技術に関する業務知識なども必要になります。たとえば、組織論や財務分析、計画 モバイル・コンピューティングなどについての理解が必要でしょう。 プロジェクト・マネジャーは、組織のマネジメントに関する知識やスキルが必要ですが、その役 割はまったく異なります。プロジェクト自体がもつ性質が、その 2 つの役割を大きく隔てていま す。プロジェクトは、ユニークかつ期間限定で、さまざまなリソースを使用するため、プロジェ クトの成功に必要なすべての作業を統合しなければなりません。一方、組織のマネジャーに求め られるのは、日常業務のように繰り返し継続的に行われることです。 また、組織のマネジメントは、特定分野に特化しています。たとえば、会計部門のマネジャー は、会計を専門としています。会計部門の IT プロジェクトを担当するプロジェクト・マネジャー は情報システムだけでなく会計についての知識も必要になるでしょう。しかし、プロジェクト・ マネジャーの責任は、会計や情報システムの機能を使いこなすことではなく、プロジェクトその ものをマネージすることです。 プロジェクト・マネジャーには、特定のプロジェクトに関わる業界や業務に関する知識も必要 です。たとえば、本書は IT プロジェクト、つまりコンピューターのハード、ソフト、通信技術な どに関連するプロジェクトを対象としていますが、IT 業界での経験に乏しいプロジェクト・マネ ジャーが大規模な IT プロジェクトを管理するのは難しいでしょう。他のマネジャーや取引業者と 渡り合うだけでなく、チームのメンバーから信頼を得るのに苦労するでしょう。だからといって IT の専門家である必要はありません。さまざまな技術の活用方法、さらにはそれらを利用してど のようにビジネスを拡大できるかを考えることがより重要になります。優秀な組織のマネジャー はプロジェクト・マネジャーとしても力を発揮できるものです。つまり、ビジネス要件に応える という使命は同じであり、技術の詳細については、主要なプロジェクト・メンバーや専門家に委 ねればすむことだからです。プロジェクト・チームをうまくリードしていくためには、IT の専門 家になることよりも、より良いプロジェクト・マネジャーになるべく努力したほうがよいのです。 IT とそれ以外の分野におけるプロジェクトの相違については、活発に議論がなされています。 いくつかの相違点もありますが、それ以上に類似する点があります。建設プロジェクトとソフト 開発プロジェクトの相違について次のように言われることがあります。 「古いビルをダイナマイ トで爆破して作り直すように、古い情報システムを一から作り直すことは不可能だし、IT の世界 には皆で共有できる工学原理や建築基準法訳注 1 のようなものは存在しません。」とはいえ、IT プ ロジェクト・マネジャーも、他の分野のプロジェクト・マネジャーと同じように、チーム・メン バーやスポンサーなどのステークホルダーと協力して、プロジェクトや組織の目標を達成する責 任を負っています。プロジェクト・マネジャーは、プロジェクトマネジメントだけでなく、組織 のマネジメントや業界についての知識や経験も積んでいかなければならないのです。 訳注 1： 建築基準法（Building Code）と IT におけるプログラミング（Building Code）をかけた一種のジョークです。 1 章 営業支援ソフト（Sales Force Automation）に関連するものであれば、営業プロセス、SFA 製品、 第 手法など一般的なマネジメントの概念を理解しておく必要があります。もしあるプロジェクトが、
© Copyright 2026 Paperzz
