ITパスポート単語帳 - プロジェクトマネジメント

プロジェクトとは、開始と終了や期限が決まっており、具体的な成果物や目標が定義され、一時的に組成された組織によって遂行される短期間(数週間から数年程度)の一連の活動の集合であり、そのマネジメントは永続的な組織や事業、業務のそれとは異なる部分がある。

プロジェクトの計画や管理に焦点を絞り、手法や工程の体系化、標準化を進める試みがモダンプロジェクトマネジメントであり、その源流は1950年代後半に米国防総省が取り組み始めた軍事プロジェクトのマネジメントについての研究であるとされる。

日本では大企業や官公庁などに導入する大規模な情報システムやソフトウェアの開発プロジェクトを効率的に管理する手法として紹介され、普及してきた経緯があるため、IT分野のマネジメント手法だと思われていることが多いが、基本的にはあらゆるプロジェクトに応用可能な汎用的な手法である。実際、大規模建築物の建設や企業経営から軍備に至るまで、様々な分野に適用事例がある。

PMIとPMBOK

その後、分野を問わず適用できる標準化されたマネジメント手法として発展し、現在ではアメリカの非営利団体PMI(Project Management Institute/プロジェクトマネジメント協会)が発行する「PMBOK」(Project Management Body Of Knowledge)と呼ばれる知識体系が有力な標準として世界的に広く普及している。

PMBOKでは、プロジェクトを「立ち上げ」「計画」「実行」「監視・制御」「終結」の5つの工程(プロセス)に分け、それぞれをさらに詳細な標準プロセスの集合として定義している。また、マネジメントの対象領域を「統合」「スコープ」「スケジュール」「コスト」「品質」「人的資源」「コミュニケーション」「リスク」「調達」「ステークホルダー」の10の知識エリアに分け、それぞれに必要なプロセスや有効な技法、ツールなどを挙げている。

従来のプロジェクト管理は、ベテランの管理職従業員などに個人的に蓄積された経験や知識、技能に頼ったり、各企業などが独自に制定したプロセスを用いることが多かったが、モダンプロジェクトマネジメントの導入により、長年の間に様々な組織や機関が研究や検証を重ね洗練されたプロセスを極力属人性を排した形で実施することができる。

PMBOKではプロジェクトマネージャがいつどういった点に注意して何を行うべきかについてある程度具体的に定めている部分もあるが、分野によらず応用できるよう汎用的・抽象的な原則が記述されているところも多く、個別のプロジェクトでどのように応用するかはプロジェクトマネージャの理解の深さや技量によるところも大きい。

PMIではPMBOKを深く理解しプロジェクトに適用する知識や技能を身に付けていることを認定する国際的な資格「PMP」(Project Management Professional)試験を実施している。日本でも一般社団法人PMI日本支部が日本語で試験を実施している。

事業や業務、行動などのうち、期間や目標、ゴールが定義され、事前に終了までの計画を立てた上で実施・遂行されるようなものを指す。永続的な組織名や活動名の一部としてプロジェクトの語を用いる場合もあるが、何らかの目的や目標を強く指向していることを表現するためであることが多い。

プロジェクトは個人で行う場合もあるが、集団や組織、複数の組織の合同で行われることが多い。プロジェクト実施のために組成された組織を「プロジェクトチーム」(project team)、その責任者を「プロジェクトリーダー」(project leader)という。企業などでは常設の部署とは別に一時的な組織として設置され、メンバーが各部署から集められる。メンバーの所属はプロジェクト側に移転する場合と、もとの部署と兼務の場合がある。

また、体系化された方法論に基づいてプロジェクトの計画の策定や進捗の管理を行うことを「プロジェクトマネジメント」(project management)と呼び、そのようなマネジメント業務を行う人や役職のことを「プロジェクトマネージャ」(project manager)という。

そのプロジェクトの目的や目標、範囲や成果物の定義、前提条件、制約条件、想定されるリスク、期間や期限、予算の概算や上限、任命されたプロジェクトマネージャ(PM)、その権限・責任の範囲、利害関係者のリストなどが含まれる。

原則としてはプロジェクトのオーナーやスポンサーが作成してPMに提示する文書だが、組織内のプロジェクトなどでは実務上はPM(やその候補)が作成してオーナーなどの承認を受けて発行される場合もある。組織によっては組織内の決裁文書などがその役割を果たし、「プロジェクト憲章」という名称では作成しないこともある。

プロジェクトの目的や利害関係者の要求、予算や期間、人員などの制約に基づいて、初期の計画段階で「何を作るのか」「何をやるのか」「どこまでやるのか」といった範囲(scope)をスコープ記述書などの形で定義する(スコープ計画)。

プロジェクト全体のスコープの概要が決まったら、これを成果物や対応するタスクに分解してスケジュールや組織体制を策定する(スコープ定義)。プロジェクトの進行中は、各タスクで生み出される成果物がスコープに適合しているかを確認する(スコープ検収)。進行途上で初期の計画通りに進まないことが分かった場合は成果物や作業の見直しを行う(スコープコントロール)。

プロダクトスコープ (product scope/成果物スコープ)

プロジェクト全体を通じて、また、途中の各段階で「何を作り出すのか」を定義したものを「プロダクトスコープ」(product scope)あるいは「成果物スコープ」という。スコープ計画ではまず開発すべきシステムやプログラム、設計文書などの成果物について定義を行い、発注者などの利害関係者で合意と共有が行われる必要がある。

プロジェクトスコープ (project scope/作業スコープ)

プロジェクトを構成する各タスクで「何を行うのか」を定義したものを「プロジェクトスコープ」(project scope)あるいは「作業スコープ」と呼ぶ。プロダクトスコープを元に、成果物を生み出すために必要なタスクを洗い出し、WBS(Work Breakdown Structure)などの形で体系化する。

スコープコントロール (scope control/スコープ変更管理)

プロジェクトの進行途上で当初の計画通りに進まない、あるいは進める必要がないことが判明した場合に、成果物や作業の追加や削減、変更を行うことを「スコープコントロール」(scope control)あるいは「スコープ変更管理」(scope change control)という。

例えば、連携を予定していた外部のオンラインサービスが廃止となり、連携機能が不要になったといった場合、この機能に関連する成果物と作業をスコープから削除し、予算やスケジュール、人員の配置なども再定義する変更が行われる。

変更点や変更後のスコープは文書化してプロジェクト内および利害関係者で共有する必要があり、これが行われず「なし崩し」的にスコープが変化(大抵の場合は要件の肥大化)してしまう状態を「スコープクリープ」(scope creep)という。

定められた期限までにプロジェクトの目標を達成するため、与えられた予算や人材、設備、物資などを用いて実施計画を立て、適宜修正しながら進捗の管理を行う。このようなプロジェクトの管理業務を「プロジェクトマネジメント」(PM：Project Management)という。

進行の遅延や中断を引き起こすリスクの洗い出しや影響の見積もり、対応方針の策定や、顕在化した問題への対処、プロジェクトオーナー(顧客)など外部の利害関係者(ステークホルダー)との連絡や調整の窓口など、プロジェクトを円滑に進めるための諸業務を担う。

また、プロジェクトチームの中心として、メンバー間の情報共有や意思疎通、議論や意思統一、仕事の割当や指示、進捗状況や問題の把握など、チームを目標に向けて一つにまとめることも重要となる。

プロジェクトマネジメントの手法は様々に研究されてきたが、アメリカの非営利団体PMI(Project Management Institute)が「PMBOK」(Project Management Body Of Knowledge)としてまとめた知識体系が事実上の標準として世界中の様々な分野で広く受け入れられている。PMIではPMBOKに準拠した国際的な認定制度「PMP」(Project Management Professional)を展開している。

また、日本の情報処理推進機構(IPA)では情報処理技術者試験の試験区分の一つとして、情報システムの開発プロジェクトを監督する能力を認定する「プロジェクトマネージャ試験」を実施している。プロジェクトマネージャ職に就く条件としてこうした資格や試験を要求する企業も増えている。

プロジェクトリーダーとの違い

組織やプロジェクトによっては、プロジェクトマネージャのことをプロジェクトリーダー(PL：Project Leader)と呼んだり、プロジェクト内にマネージャ職とは別にリーダー職を設置している場合がある。

マネージャとリーダーが両方存在する場合の位置付けや役割分担は組織により様々だが、よくあるパターンの一つは、マネージャがプロジェクト全体のトップとして計画・管理業務に専念し、マネージャを補佐するリーダーが内部の小チームごとに置かれ、現場の人員を束ねて工程の実施に責任を持つという体制である。

また、マネージャが顧客など外部との窓口、リーダーが内部での管理・執行の責任者という分担や、マネージャが顧客への提案や受注、計画の策定などを行い、プロジェクトが実施段階に移るとリーダーに引き継いで納品までを行なう、という分担になっていることもある。

企業の場合、直接的なステークホルダとしては金銭の授受や損益が生じる株主や経営者、従業員、労働組合、債権者、発注先、提携先、貸主や地主、顧客、取引金融機関、税務当局などが含まれる。

間接的には、事業の監督官庁や所管官庁、事業所所在地の周辺住民や自治体などが含まれることもある。企業とステークホルダを対置する文脈では、経営者や株主については企業自身と一体の存在である(企業を「取り巻く」存在ではない)としてステークホルダから外す考え方もある。

また、規模や事業内容、文脈によっては、同業企業(競合企業)や業界団体、政治家、従業員の家族、(顧客以外の)消費者、求職者、証券会社や株式市場、投資家、報道機関、研究機関、事業分野に企業活動に関連するNPOやNGO(環境団体や人権団体など)などがステークホルダに含まれることもある。

企業に限らず、官公庁や非営利団体など様々な種類の組織や集団、人物、事件、製品、案件などについて、利害関係のある人や組織を総称してステークホルダという。

なお、個別のある利害関係者について、株主を指すなら株主、従業員を指すなら従業員と言えば良いため、あえて「ステークホルダ」という言い回しをするのは、複数の異なる種類の利害関係者をまとめて総称する必要がある場面に限られる。

一般的なWBSの作成法では、まずプロジェクト全体の成果物を定義し、これを得るのに必要な各段階における工程や成果物に分解していく。その際、全体を大きな単位に分割してから、それぞれの部分についてより細かい単位に分割していき、階層的に構造化していく。

十分細かい単位に分解できたら、これを得るために必要な具体的な作業や業務(一つとは限らない)を考え、最下層に配置していく。一つの成果物を得るための一連の作業のかたまりのことを「ワークパッケージ」(work package)と呼ぶ。

図表として表す際は、左端が大項目で右へ向かって細分化されていく表や、大項目から順に枝分かれしていく木構造の図で表現されることが多い。表の右側に担当部門やスケジュールを表すガントチャートなどを書き加え、計画や進捗の管理に用いる場合もある。

成果物指向とプロセス指向

プロジェクト全体を細かな単位に分解する際の方針は、主に産み出される成果物に着目する成果物指向(成果物型、成果物ベース)の考え方と、主に作業工程に着目するプロセス指向(プロセス型、作業ベース)の考え方に分かれる。

成果物指向は「○×社財務管理システム」のようにプロジェクト全体が生み出す最終成果物を設定し、これを構成単位の中間成果物に分解していく考え方である。ワークパッケージは最小単位の成果物を産み出すための作業工程となる。完成品の仕様や設計などが明確な場合に適している。

プロセス指向は「オフィスの移転」のようにプロジェクト全体を大きな工程と捉え、これを構成単位の中間工程に分解していく考え方である。ワークパッケージは最小単位の作業工程となる。製品のような形を持った成果物が目的ではないプロジェクトや、初期に最終成果が明確に定義できない中長期的なプロジェクトに適している。

OBS/CBS

WBSから派生する構成図に「OBS」(Organization Breakdown Structure)と「CBS」(Cost Breakdown Structure)がある。それぞれWBSのワークパッケージにチーム、コストを割り振ったもので、プロジェクト遂行に必要な人員や予算の計画のために必要となる。

OBSはワークパッケージに担当チームや責任者、担当者を配置したもので、プロジェクトを遂行する組織図となる。図中で作業の並びに対して直交するようにチームを並べて表(マトリクス)を構成し、各チームが担当する作業に印をつける作図法が一般的である。

CBSはプロジェクトのコスト構造を示した図で、各ワークパッケージに予算を割り当てて全体の予算を見積もったり、プロジェクト進行中に消化した予算の実績値を書き入れてコストを管理するのに用いられる。OBSと同じように、作業と直交するように費目を並べ、各作業についてどの費目にいくらかかるのかを書き入れる作図法が用いられることもある。

プロジェクトマネジメントではプロジェクトを構成する工程の前後関係を一覧して把握するために作成される。このような図を用いて計画や管理を行う手法を「PERT」(Program Evaluation and Review Technique)ということから、「PERT図」(パート図)とも呼ばれる。

複数の工程からなるプロジェクトでは、工程間に「前の工程が終わらないと次の工程が始められない」という依存関係が存在する場合がある。一方で、どちらを先に行っても良い、並列に進めても良いという関係になっているものもある。

アローダイアグラムでは矢印が個々の工程を表しており、内容と所要時間を付記する。工程間に依存関係がある場合、間に丸印(◯)で表される「結合点」を挟んで矢印同士を連結する。プロジェクトの開始と終了も結合点として表す。すべての工程を配置すると、開始から終了までどの順序で工程を進めればよいか、どの工程を並列に進められるかを一覧できるようになる。

開始から終了までの間には、いくつかの経路が現れることがあるが、経路上の工程の所要時間を足し合わせていくと、それぞれの経路全体の所要時間を求めることができる。その中で最も所要時間が長い経路は、プロジェクト全体の最短工期を表しており、これを「クリティカルパス」(critical path)という。

クリティカルパスに現れない工程をどんなに急いでも工期は短縮しないため、遅延を防止したり工期を短縮するにはクリティカルパス上の工程に注力する必要がある。このようにクリティカルパスに着目してマネジメント活動を行う手法を「クリティカルパス法」(CPM：Critical Path Method)という。

1910年代にアメリカの機械エンジニア、経営コンサルタントのヘンリー・ガント(Henry L. Gantt)が考案した図で、横軸に時間、縦軸に工程を並べた二次元の表を用意し、各工程の開始から終了までを帯として書き入れていく。

プロジェクトの開始時にはスケジュールを表す帯が並んでいるだけだが、時間が進むに従って工程の進捗状況や完了などが書き込まれていく。進捗度合いに応じて帯の色や柄を塗り分けて状況を視覚的に表現する場合もある。

表の左端に並んだ工程には場所や担当、開始日や終了日、見積もり工数などを書き入れたり、大項目から小項目へ階層状に分割して各工程の全体での位置が分かるようにすることがある。

工程間に依存関係(工程Aが終わらなければ工程Bに着手できないという関係)がある場合には前工程の終了と次工程の開始を矢印で結ぶが、複雑で大規模なプロジェクトでは矢印が交錯して直感的に把握しにくいという問題もある。

全体の計画や進捗をひと目で確認できる図法として現在も広く普及している。表部分に記載する項目や内容、グラフ部分に書き入れる注釈や進捗の表現方法などに様々なバリエーションがあり、分野や企業、部署によって異なる規約で運用される。

リスク(risk)とは将来起こりうる悪い出来事、および、その確率や損害の程度のことを指す。特に、全く偶発的に外部からもたらされる災禍ではなく、組織や個人の何らかの行動や意思決定、あるいはその欠如によって起こり得るものを指すことが多い。

リスク対応では、リスクアセスメントによって特定、分析、評価したリスクについて、それぞれのリスクの性質に基づいてどのように対処するかを決定する。施策の実施が必要なものについては導入計画の策定や実施なども行う。

対応策はいくつかの類型に分類することができる。主な類型として、リスク要因を除去する「リスク回避」、リスクの発生率や影響度を下げる「リスク低減」(リスク軽減)、リスクを外部と共有する「リスク共有」(リスク分散)、リスクを外部へ移す「リスク転嫁」(リスク移転)、リスクを甘んじて受容する「リスク保有」(リスク許容/リスク受容)がある。

リスク(risk)とは将来起こりうる悪い出来事、および、その確率や損害の程度のことを指す。組織のリスクマネジメントでは、想定される様々なリスクを洗い出し、それぞれついてどのような対策を行うか検討する。

リスク回避はリスク対応の方策の一つで、リスクを伴う活動自体の中止や、リスクを引き起こす要因の根本的な排除などを指す。例えば、投資の引き揚げ、製品の生産終了、取得した個人情報の破棄などが該当する。

リスク(risk)とは将来起こりうる悪い出来事、および、その確率や損害の程度のことを指す。組織のリスクマネジメントでは、想定される様々なリスクを洗い出し、それぞれついてどのような対策を行うか検討する。

リスク軽減はリスク対応の方策の一つで、リスク要因の予防や被害拡大を防止する措置を講じることなどを指す。例えば、火災に備えてスプリンクラーを設置したり、自然災害に備えてデータセンターを地理的に離れた複数箇所に分散するといった方策が該当する。

リスク(risk)とは将来起こりうる悪い出来事、および、その確率や損害の程度のことを指す。組織のリスクマネジメントでは、想定される様々なリスクを洗い出し、それぞれついてどのような対策を行うか検討する。

リスク受容はリスク対応の方策の一つで、事前に特に手を打たず、顕在化した場合の損失を丸ごと引き受けることを指す。そもそも他の対応策が極めて困難あるいは不可能な場合(戦争や政変など)や、発生確率や頻度、損害が極めて小さい場合、どの対応策を選んでもコストが想定損害額を上回ると試算される場合などに選択されることがある。

リスク(risk)とは将来起こりうる悪い出来事、および、その確率や損害の程度のことを指す。組織のリスクマネジメントでは、想定される様々なリスクを洗い出し、それぞれついてどのような対策を行うか検討する。

リスク転嫁はリスク対応の方策の一つで、契約などを結んで他者にリスクを移転する手法を指す。典型的なリスク移転策は保険への加入で、一定の対価を支払うことでリスクが顕現した際の損失を保険会社に引き受けさせることができる。アウトソーシングなど部分的なリスクの移転を含め「リスク共有」と同義とすることもある。