基本情報技術者単語帳 - プロジェクトマネジメント

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

プロジェクトの計画や管理に焦点を絞り、手法や工程の体系化、標準化を進める試みがモダンプロジェクトマネジメントであり、その源流は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)という。

プロジェクトの推移を論理的な順序に従って区切ったもので、一般的には「開始」(立ち上げ)、「準備」(計画)、「実行」(実施)、「終了」(集結)の4つの段階からなる。それぞれが一定の方法論に基づいて管理され、対応する成果物が定義されることが望ましいとされる。

プロジェクトマネジメント手法の標準の一つであるPMBOKでは、初期に計画を確定する、いわゆるウォーターフォールモデルに相当する「予測型」のライフサイクルに加え、アジャイル開発モデルなどに見られる「反復型・漸進型」や「適応型」のライフサイクルも定義している。

開発プロセスやプロジェクトマネジメントなどには方法論を体系化した標準や規格が存在し、大企業などでは全社的な標準が定められていることもある。これに従って工程を計画・管理することで業務の効率化や品質の向上、属人性の軽減などを進めることができる。

こうした規格や標準はどのような対象や組織、状況に対してもなるべく汎用的に適用できるよう、一般的、抽象的な表現で定義したり、原則や方針を示すのみの項目が存在するなど、個別の事例や対象にどのように適用すべきかが必ずしも自明でないことも多い。

これを個別の組織や業務、プロジェクト、顧客などに適用する際に、対象に応じて具体化したり、詳細を定めたり、一部を改変したりする作業のことをテーラリングという。

プロジェクトを「立ち上げ」「計画」「実行」「監視・制御」「終結」の5つの工程(プロセス)に分け、それぞれをさらに詳細な標準プロセスの集合として定義している。また、着目すべき観点として「統合」「スコープ」「スケジュール」「コスト」「品質」「人的資源」「コミュニケーション」「リスク」「調達」「ステークホルダー」の10の知識エリアを挙げている。

このように細分化され整理された各領域について、入力(前提として必要となる文書など)、ツールと技法(管理を実践するための個別の手法)、出力(プロセスの結果生み出される成果物など)が定められている。

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

PMIではPMBOKに基づくプロジェクト管理が可能な知識や技能を身に付けていることを認定する国際的な資格「PMP」(Project Management Professional)試験を実施している。3年毎の更新制で、期間内に所定の学習や活動を行ったことを証明しなれば失効する。

PMBOKは1987年に最初に公表されたが、書籍の形にまとめられ「PMBOKガイド」の初版が刊行されたのは1996年である。以降は4～5年ごとに改訂されている。1998年にはPMI日本支部が開設され、翻訳書の刊行とPMP試験の実施を行っている。

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

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

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

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

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

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

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

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

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

組織内におけるプロジェクトマネジメントに関する専門部署で、社内のPMO手法の標準化、研修などを通じた知識や事例の共有や普及、実施中のプロジェクトのマネジメント業務の支援、プロジェクト間の社内の共有リソースの調整などを行う。

プロジェクトマネジメント業務の質の担保や人材育成を現場のプロジェクトマネージャ任せにせず、全社的に取り組むことで質の向上や平準化を図ることができる。また、経営の観点からプロジェクト間のリソース配分を全体最適化することにも役立つ。

並行して常にいくつもプロジェクトが実施されているような業態や規模の企業などで設置されるが、自社でPMOを設置できない規模の企業などに向けて、PMO業務をサービスとして提供する企業も現れている。

製品の質について何らかの基準や要件を定義し、これを満たすために行われる組織的な活動の総体である。設備や人員、原料などを適切に管理する「工程管理」、計測や検査で不良がないことを確かめる「品質検証」、製造工程の改善を行う「品質改善」などの活動で構成される。

日本の製造業で発展した品質管理の技法として、製造現場の作業者が小集団で管理や工程の改善に取り組む「QCサークル活動」、計測に基づく数値で品質を管理するSQC(Statistical QC：統計的品質管理)を発展させ、図や表で現状を可視化して分析や議論を行う「QC七つ道具」などがある。

QC七つ道具は主に定量的な分析を行う手法のセットで、「チェックシート」「グラフ」「管理図」「パレート図」「特性要因図」「ヒストグラム」「散布図」で構成される。また、主に定性的な分析を行うための「連関図法」「親和図法」「系統図法」「アローダイアグラム法」「マトリックス図法」「マトリックスデータ解析法」「PDPC法」を「新QC七つ道具」と呼ぶことがある。

QCの考え方や活動を製造現場だけでなく他部門に広げ、全社的に取り組むようにしたものを「TQC」(Total Quality Control)という。また、QCあるいはTQCを現場主導のボトムアップの活動だけでなく、経営管理の一環としてトップダウンで取り組むことを「TQM」(Total Quality Management)という。

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

リスク管理とは、将来のリスクを考えうる限り想定し、それぞれについて事前に対処方針を定め、実際にリスクが顕在化した際に方針に則って対処するという一連の行動を、組織内の仕組みとして明確なプロセスの元に実施することを意味する。

一般的な流れとしては、まずリスク特定、リスク分析、リスク評価からなる「リスクアセスメント」(risk assessment)を実施してリスクの洗い出しと対処方針の策定を行う。その後、事業を遂行する中で実際に遭遇した事象に対してリスク対応を行う。一定の期間が経過したら、記録を元に振り返り(レビュー)を行い、対処方針の改善などを行う。これを一つのサイクルとして、事業年度ごとなどの単位で繰り返し実施する。

システムへの変更が野放図に行われることでサービスの提供に支障が生じたり、無計画なサービスの中断が起きることを防ぎ、停止時間(ダウンタイム)の最小化、サービス品質の安定、変更に伴うリスクの管理を可能とする。

変更管理の対象は分野や業務により様々だが、ITシステムの場合にはオペレーティングシステム(OS)やアプリケーションソフトの新規導入やアップデート、機器や配線などの増設や交換、撤去、移動、組織体制の変更や担当者の異動、担当業務の変更、業務運用の見直しなどがある。ソフトウェアやシステムの導入については「リリース管理」「デプロイ管理」などとして別に管理することもある。

ITの分野では、装置やソフトウェア、システムなどの仕様や構造、設計、使い方、注意点などを体系的に文書としてまとめることを意味する場合が多い。マニュアルや取扱説明書のように製品の利用者に使い方などを説明するために行われる場合と、仕様書や設計書のように他の開発者に設計情報などを伝達・共有するために行われる場合がある。

コンピュータプログラムの場合、プログラミング言語で書かれたソースコード中に注釈を記述できる「コメント」機能を用いて、コードの中に関数の引数や返り値の説明などを直に記述する形で文書化を行う場合も多い。Javadocのように、コメントに一定の書式で説明を記述すると見やすく整形して出力してくれる仕組みが用意されている場合もある。

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

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

タイポグラフィのベースライン

フォントや文書デザインなどでは、アルファベットの大文字の底辺の高さ(また、底辺が接する直線)のことをベースラインという。

日本語の文字揃えとは異なり、小文字の一部(g/j/p/q/y)はベースラインの下にはみ出すため、日欧混合の文などでは表示が不自然にならないよう注意が必要な場合がある。

プロジェクト管理のベースライン

プロジェクトマネジメントなどでは、進捗や予算、成果物などのスケジュール上での基準値や予定値、また、その推移を図表で書き表したものをベースラインということがある。

実施前の想定した計画値などを指し、実績値と比較することにより現在の進捗が計画より進んでいるのか遅れているのかを判断することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OBS/CBS

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

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

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

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

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

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

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

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

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

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

OBS/CBS

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

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

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

WBSの最下層に並べられる作業単位で、進捗やパフォーマンスを計ったり状況をコントロールする際の最小単位となる。実務上はより小さな複数のアクティビティ(タスクとも呼ばれる)で成り立っていることが多いが、それらは意味のある単位の成果物を生み出さない。

ワークパッケージの大きさ(粒度)はプロジェクトの種類や規模などにより異なるが、同じWBS内にあるワークパッケージ同士はなるべく等しい規模感となることが望ましいとされる。大規模プロジェクトではワークパッケージをサブプロジェクトとして独立にマネジメントする場合もある。

ワークパッケージに担当する人員を配置していけばプロジェクトを遂行する組織図であるOBS(Organization Breakdown Structure)ができる。コスト管理はワークパッケージ単位だと細かすぎることが多く、複数のワークパッケージを束ねた管理単位であるコントロールアカウントを用いることが多い。

プロジェクトマネジメントでは、計画時にプロジェクト全体を段階的に小さな工程に分解していき、小さな作業(ワークパッケージ)の構成図であるWBS(Work Breakdown Structure)という表を作成することがある。

WBSは工程を分解したものだが、最小単位となる個々のワークパッケージに担当チームや責任者、担当者を配置したものをOBSという。どの作業を誰が、どのチームが担当するのかを一覧でき、プロジェクトを遂行する組織図となる。

通常、各チームあるいはメンバーはプロジェクト中に複数の異なる作業を担当するため、WBSの図中で作業の並びに対して直交するようにチームを並べて表(マトリクス)を構成し、各チームが担当する作業に印をつける作図法が一般的である。

過去に類似の事例が存在する点についてはその事例の実績値を採用し、事例がない点については経験や勘を元に見積もっていく。

そのプロジェクト特有の事情などは反映されにくく、精度は担当者の知識や経験に大きく左右される。過去に類例の乏しい特殊な案件や新しい種類の案件など、類推が難しい場合もある。

要件や機能などが明確に定義される以前の初期の段階でも適用可能なため、詳しい状況が確定する以前の企画の初期に見積もりが必要な場合に用いられることがある。精度が低く客観性や根拠にも乏しいため、要件定義以降の詳細な見積もりには適さないとされる。

過去のプロジェクトに実際にかかったコストや工数のデータをもとに統計的な法則性を見出し、新規のプロジェクトについてコード行数や投入人員といった過去と同じ項目の値を集めて算定式に当てはめることでコストや工数を導き出す手法である。

見積り法の大きな分類の一つで、「パラメトリック見積り」という一つの具体的な手法があるわけではない。パラメトリック見積りに分類される具体的な手法として、LOC法、ファンクションポイント法(FP法)、COCOMO、CoBRAなどがよく知られる。

1980年代前後に活発に研究された手法で、類推法(トップダウン法)や標準タスク法(ボトムアップ法)などノンパラメトリックな手法と対比される。ある特定の環境を前提に構築された算定モデルを別の環境にそのまま適用すると精度が落ちてしまうため、分野や企業ごとに係数の較正(キャリブレーション)を行う必要がある。

過去の経験などから最も可能性が高いと考えられる最頻値、最も順調に進んだ場合の楽観値、最も悪条件が重なった場合の悲観値の3つの値を見積もる。これらがベータ分布に従って起きると仮定し、平均値 (楽観値＋最頻値×4＋悲観値)/6、分散 {(楽観値-悲観値)/6}²、標準偏差(分散の平方根)を求める。

このような統計的な処理を行うことにより、平均値±標準偏差に収まる確率は約68%、平均値±標準偏差×2に収まる確率は約95%などといった具合に確からしさを範囲と確率の関係で表すことができる。工程や予算、人員、関係する組織などが多い大規模な開発プロジェクトに向いているとされる。

PERTでは各工程を「前の工程が終わらないと次の工程が始められない」という依存関係に従って矢印で繋いでいき、それぞれの工程には所要時間を記入していく。

出来上がったネットワーク図(アローダイアグラム、PERT図とも呼ばれる)にはプロジェクト開始から終了まで通常いくつかの経路が現れる。経路をたどって各工程の所要時間を足し合わせていくとその経路の所要時間が求められ、その中で最大のものがプロジェクト全体の工期の見積りとなる。

クリティカルパス

所要時間が最大となる経路に存在する工程はどれか一つでも遅れると全体が遅延するため、重要な工程のみが集まった「クリティカルパス」(critical path)と呼ばれる。

全体の工期を短縮するにはクリティカルパスを短縮しなければならないため、スケジュールや人員配置の変更、資源の集中投下などの判断を行うことが必要となる。

その際、ある工程の所要時間が変化すると、これまでとは別の経路がクリティカルパスになる場合があるため、PERT図の作成と分析はプロジェクト進行中に何度も繰り返し行なうことが重要となる。

プロジェクトを構成する工程をすべて列挙し、それぞれの所要時間を見積もって、各工程の前後関係(依存関係)に従って連結していくと、必ずしも一直線に繋がるとは限らず、開始から終了までの間に複数の経路(工程の組み合わせ)が現れることがある。

このうち、経路内の工程の見積もられた所要時間の合計が最も大きいものがクリティカルパス法であり、プロジェクト全体の所要時間を決定付けている。なぜなら、他の経路上の工程をいくら短縮しても、最長であるクリティカルパス法上の工程がすべて終わるまでプロジェクトは終了しないからである。

プロジェクトの期間を短縮したり遅れを取り戻したければ、まずはクリティカルパス法の工程の改善を考える必要がある。また、クリティカルパス法内の工程が遅れればプロジェクト全体の遅延に直結するため、十分な資源を投じて遅延が生じないよう重視すべきとされる。

クリティカルパス法を見つけるには、プロジェクトの工程をガントチャートやPERT図などに図示し、それぞれの工程の所要時間と依存関係を書き入れて最長となる経路を見つけ出す。現代ではプロジェクト管理を支援するソフトウェアを用いて算出を行うのが一般的である。クリティカルパス法に基づいてスケジュールの策定やプロジェクト管理を行う手法を「クリティカルパス法法」(CPM：Critical Path Method)という。

なお、プロジェクトが進行するとクリティカルパス法上の工程が短縮されて必要な期間が短くなることがあるが、別の経路が新たにクリティカルパス法となる場合がある。工程の進行具合が当初の予定と異なっている場合は、クリティカルパス法が元の経路から変わっていないか随時確かめる必要がある。

各工程は矩形で表し、中央に作業名と所要時間(あるいは所要日数など)、左上に最早開始時刻(あるいは日、以下同)、右上に最早終了時刻、左下に最遅開始時刻、右下に最遅終了時刻を書き入れる。工程間の関係は矢印で表すが、工程の開始を矩形の左端、終了を右端として、これら左右端の間を矢印で結んでいくことで工程間の依存関係を表す。

作業Aの終了から作業Bの開始に伸びた矢印は「FS」(Finish-to-Start：終了-開始関係)で、「作業Aが終わったら作業Bを開始する」という関係を表す。作業Aの開始から作業Bの終了に伸びた矢印は「SF」(Start-to-Finish：開始-終了関係)で、「作業Aが開始されたら作業Bを終了する」という関係を表す。

作業Aの開始から作業Bの開始に伸びた矢印は「SS」(Start-to-Start：開始-開始関係)で、「作業Aが始まったら作業Bも開始する」という関係を表す。作業Aの終了から作業Bの終了に伸びた矢印は「FF」(Finish-to-Finish：終了-終了関係)で、「作業Aが終わったら作業Bも終了する」という関係を表す。

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

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

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

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

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

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

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

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

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

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

原義の「マイル標」は、幹線道路の道路脇に1マイルごとに設置される、起点からの距離を記した標識のことで、時系列の出来事の流れを道路になぞらえ、途中の節目となる重大なポイントをマイルストーンと呼ぶ。

ビジネス分野では、プロジェクトのスケジュール管理などにおいて、進捗の目安として着目する重要な節目、区切り、目処のことをマイルストーンという。「設計完了」「出荷開始」など、工程全体を分割する大項目の開始や終了などを設定することが多い。

進捗管理を行うのにプロジェクト全体では大きすぎ、個々の作業項目では小さすぎる場合に、途中にいくつかのマイルストーンを設定し、常に次のマイルストーンを目標とすることで、スタッフのモチベーションの維持や正確で効率的な進捗管理が可能となる。

また、何らかの分野や業界、製品カテゴリーなどの歴史やこれまでの過程を振り返り、現在から見て節目や転換点、到達点、集大成だったと評価されるような重要な出来事や事件、画期的な新技術・製品などのことをマイルストーンということもある。

プロジェクトの開始から終了まで、依存関係・前後関係にある工程間を繋いでできる複数の経路のうち、経路上のいずれかの工程が遅延するとプロジェクト全体が遅延する経路を「クリティカルパス」(critical path)という。

クラッシングではこのような経路上に存在する工程に対して人員の追加といった資源の投入を行いスケジュールを早める。クリティカルパスが複数ある場合はそれらが同時に同じ期間短縮できるよう複数の工程でクラッシングを行う。

当該工程が短縮された結果、クリティカルパスが別の経路に移行する場合があるため、一度に極端な短縮は避け、短縮後の計画を事前に確認したほうがよいとされる。また、業務の内容によっては人員を後から追加しても期待通りに工期の短縮が進まないリスクもある。

本来は順番に実行するはずだった各工程について、前工程の完了を待たずに次工程に着手し、一部を並行して実行する。前工程で既に作業が済んだ成果物を利用して次工程の作業をできるところまで進めるといった手法が取られる。

直接的にコストを増やさずに遅れを挽回できる手法であり、他の手法に比べ選択されやすいが、本来並行して行わない複数の工程に人員を分割して割り当てることになるため、人的負担が大きく、連携が円滑に進まないと混乱が生じることがある。

また、ファストトラッキング開始後に前工程で重大な変更や修正などが発生し、これを元に進めていた次工程の完了部分を破棄してやり直し(手戻り)を迫られるリスクもある。

ITの分野では、コンピュータなどの利用者が操作を行ってからそれが処理や表示などに反映されるまでに経過する時間や、通信やネットワークでこちらから送信を行なってから相手に届くまでに経過する時間などのことをラグということが多い。

オンラインゲームでは、プレイヤーによる操作がゲームの状態を管理するサーバ側に反映されるまでに生じる遅延のことをラグということが多い。想定外に利用者が増えた場合やサーバの処理能力が不十分な場合などには多くの利用者で大きなラグが生じ、ゲームの進行に深刻な支障をきたすこともある。俗に「ラグる」「ラグい」といったように動詞や形容詞として用いることもある。

英語では “lag” という表現の他に “delay”(ディレイ)や “latency”(レイテンシ)もほぼ同じ意味合いで用いられるが、分野によってはそれぞれ異なる意味で用いられることもある。「ラグ」には外来語として同音異義語になる単語に “rug” があり、(小さめの)敷物、じゅうたんという意味になる。

一般の外来語としては、集団の先頭に立って率いることや、主導権を握って積極的に意見を表明したり方針を示すこと、スポーツなどの競技や競争で優位に立ったり勝ち越すこと(また、点差など後続に対する優位性の大きさ)、犬など動物に付ける引き綱などを表すことが多い。

見込み客

ビジネスにおけるセールスやマーケティングの分野では、見込み客のことをリードという。まだ購入や契約には至っていないが、自社や製品と何らかの関係を持ち、行動を起こしたり興味を示している相手を表す。宣伝などで新たなリードを開拓する過程を「リードジェネレーション」、関係を深めて成約へ導く過程を「リードナーチャリング」という。

テックリード

IT業界では、ITエンジニアのチームを率いるリーダーのことを「テックリード」(tech lead)と呼ぶことがある。ソフトウェア開発などの業種や部門でよく見られる職位で、部署やプロジェクトのエンジニアを束ね、技術面での方針を定めたり、メンバーへの技術指導、外部との技術面での窓口などを担うことが多い。

業務の現場で技術的な側面を主導する職位であり、人材や予算、計画の進捗などを管理する管理職(マネージャ職)とは異なる。部署内にテックリード職とマネージャ職(プロジェクトマネージャやプロダクトマネージャなど)がそれぞれ別に配置される場合もあれば、小規模な現場では一人が両方を兼務する場合もある。

リードとラグ

スケジュール管理において、前後関係にある2つの活動で、先行する活動に対して後続の活動の開始を前倒しする時間のことをリードということがある。逆に、先行する活動に対して後続の活動の開始を遅らせる時間のことは「ラグ」(lag)という。

read

日本語の外来語(カタカナ語)として同音異義語になる言葉として、英語の “read” に由来する「リード」がある。「読む」という意味で、IT分野ではデータを通信回線や記憶媒体などから読み込むことを指すことが多い。書き込むことは「ライト」(write)、追記することは「アペンド」(append)、削除することは「デリート」(delete)または「イレース」(erase)という。

プロジェクト全体をWBS(Work Breakdown Structure)などを用いて細かい工程に分割し、各工程にかかる予算コストを見積もる。これをスケジュールに沿って積算し、各時点での計画値(PV：Planned Value)を用意する。プロジェクト完了時のPV、すなわち計画上の総予算を「BAC」(Budget At Completion：完成時総予算)という。

プロジェクト開始後、ある時点までに完了した工程の予算額の合計が出来高(EV：Earned Value)である。EVMにおける最も基本的かつ重要な指標で、ある時点までに完了した工程の予算コストの合計である。作業の到達度を金銭的な価値に換算したものと考えることができる。定義上、EVがBACに達するとプロジェクト終了となる。

また、その時点までにかかった実際のコストの積算値を実コスト(AC：Actual Cost)という。ある時点におけるEVがPV(計画上消化済みのはずの予算額)と異なる場合、両者の差が計画と実際のスケジュール差異(SV：Schedule Variance)となる。一方、ACがEV(計画上かかるはずだったコスト)と異なる場合、両者の差が計画と実際のコスト差異(CV：Cost Variance)となる。

例

例えば、全体が3つの工程に分かれ、それぞれ工期1か月、予算100万円(全体では3か月、300万円)という見積りのプロジェクトがあり、2か月が過ぎた時点で150万円を支払って1つ目の工程が完了したとする。

この時点でのEVは1つ目の工程にかかるはずだったコストの100万円、PVは2か月で完了しているはずの2つの工程の予算である200万円、ACは実際に消費した150万円である。計画と実際のコスト差異(CV)は100-150で-50万円、スケジュール差異は100-200で-100万円である。

これを見て分かる通り、CVが正ならコストが予算に収まっており、負なら予算超過である。SVが正なら計画より早く進行しており、負なら遅延が生じている。スケジュールの進捗状況も金額に換算して表現される点が特徴的である。

グラフ

EVMでは進捗を積み上げ折れ線グラフに図示することで、状況の推移を視覚的に分かりやすく把握することができる。原点をプロジェクト開始時として、横軸を時間、縦軸を金額としてPV、EV、ACの3本の折れ線グラフを描画する。

プロジェクト開始時には原点から右上に伸びるPVのみが描画される。進行に伴って原点からEV、ACが徐々に右上に伸びていく。PVの線に対してEVが上方ならばスケジュールは順調で、下方ならば遅延している。また、EVに対してACが上方ならば予算超過で、下方ならば予算内に収まっている。

EVMの意義

EVを中心に考えることで、プロジェクトの進行中にコスト、スケジュール両面の進捗状況を統一的な尺度で把握することができる。それまでの計画とのズレの大きさから、完成までの総時間、総コストを予測することもできる。

EVMは1960年代に米軍で考案された手法で、アメリカ政府では一定額以上の入札に関して事業者にEVMに対応することを義務付けている。プロジェクトマネジメントの標準的な手法をまとめたPMBOKでも進捗管理の基本的な方法論として紹介されている。近年では日本でも情報システムの公共調達などで、EVMによる管理と進捗の報告を入札条件とする案件が多く見られる。

補助的な指標

EVMではEV、PV、AC、BAC、CV、SVといった主要な指標や値の他に、様々な分析や管理を行うために以下のような補助的な指標を算出して用いることがある。

• CPI(Cost Performance Index：コスト効率指数)は、ある時点までに投入した実コスト(AC)に対する出来高(EV)の比率である。実際のコストが予算に対してどの程度節約、あるいは超過したかを表す指標で、EV/AC という式で求められる。1を上回っていれば予算内、下回っていれば予算超過である。
• SPI(Schedule Performance Index：スケジュール効率指数)は、ある時点の計画値(PV)に対する出来高(EV)の比率である。現在の進捗が予定よりどの程度先行あるいは遅延しているかを表す指標で、EV/PV という式で求められる。1を上回っていれば進捗は計画より早く、下回っていれば計画より遅れている。
• EAC(Estimate At Completion：完成時総コスト見積り)は、ある時点における完成時の総コストの見積り額である。作業が現状のペースで推移したら最終的にどのくらいのコストがかかりそうかを推計したもので、AC+(BAC-EV)/CPI(あるいは、ETCを用いて AC+ETC)という式で算出される。
• ETC(Estimate To Completion：残作業コスト見積り)は、ある時点における完成までの残り作業量を、相当する予算コストの金額で表したものである。EVと同じように作業量をその過程で消化する予定の金額に換算して表したもので、(BAC-EV)/CPI(あるいは、EACを用いて EAC-AC)という式で算出される。
• VAC(Variance At Completion：完成時コスト差異)は、ある時点における完成時の総コストの見積り(EAC)と、計画上の総予算(BAC)との差異である。BACからEACを引いたもので、負の値であればEACの方が小さく、予算内でプロジェクトが完了しそうだが、正の値であればBACの方が小さく、総コストが予算を超過しそうであると分かる。

プロジェクト全体の大枠のスケジュールを示したもので、重要な日程として開始と終了、節目となる出来事(マイルストーン)などを配置する。作業計画は工程を単位に実施期間などを帯などで示すに留め、細かな個々の作業などは省略する。

プロジェクトの関係者の間で全体的なスケジュールを確認、共有するために作成される。これとは別に、実際の工程管理を行うため、WBS(Work Breakdown Structure)などを元に詳細な作業工程表とスケジュールを作成する必要がある。

プロジェクト全体をWBS(Work Breakdown Structure)などを用いて細かい工程に分割し、各工程にかかる予算コストを見積もる。これをスケジュールに沿って積算し、各時点での計画値(PV：Planned Value)を用意する。プロジェクト完了時のPV、すなわち計画上の総予算を「BAC」(Budget At Completion：完成時総予算)という。

プロジェクト開始後、ある時点までに完了した工程の予算額の合計が出来高(EV：Earned Value)である。実コストにおける最も基本的かつ重要な指標で、ある時点までに完了した工程の予算コストの合計である。作業の到達度を金銭的な価値に換算したものと考えることができる。定義上、EVがBACに達するとプロジェクト終了となる。

また、その時点までにかかった実際のコストの積算値を実コスト(AC：Actual Cost)という。ある時点におけるEVがPV(計画上消化済みのはずの予算額)と異なる場合、両者の差が計画と実際のスケジュール差異(SV：Schedule Variance)となる。一方、ACがEV(計画上かかるはずだったコスト)と異なる場合、両者の差が計画と実際のコスト差異(CV：Cost Variance)となる。

例

例えば、全体が3つの工程に分かれ、それぞれ工期1か月、予算100万円(全体では3か月、300万円)という見積りのプロジェクトがあり、2か月が過ぎた時点で150万円を支払って1つ目の工程が完了したとする。

この時点でのEVは1つ目の工程にかかるはずだったコストの100万円、PVは2か月で完了しているはずの2つの工程の予算である200万円、ACは実際に消費した150万円である。計画と実際のコスト差異(CV)は100-150で-50万円、スケジュール差異は100-200で-100万円である。

これを見て分かる通り、CVが正ならコストが予算に収まっており、負なら予算超過である。SVが正なら計画より早く進行しており、負なら遅延が生じている。スケジュールの進捗状況も金額に換算して表現される点が特徴的である。

グラフ

実コストでは進捗を積み上げ折れ線グラフに図示することで、状況の推移を視覚的に分かりやすく把握することができる。原点をプロジェクト開始時として、横軸を時間、縦軸を金額としてPV、EV、ACの3本の折れ線グラフを描画する。

プロジェクト開始時には原点から右上に伸びるPVのみが描画される。進行に伴って原点からEV、ACが徐々に右上に伸びていく。PVの線に対してEVが上方ならばスケジュールは順調で、下方ならば遅延している。また、EVに対してACが上方ならば予算超過で、下方ならば予算内に収まっている。

EVMの意義

EVを中心に考えることで、プロジェクトの進行中にコスト、スケジュール両面の進捗状況を統一的な尺度で把握することができる。それまでの計画とのズレの大きさから、完成までの総時間、総コストを予測することもできる。

実コストは1960年代に米軍で考案された手法で、アメリカ政府では一定額以上の入札に関して事業者に実コストに対応することを義務付けている。プロジェクトマネジメントの標準的な手法をまとめたPMBOKでも進捗管理の基本的な方法論として紹介されている。近年では日本でも情報システムの公共調達などで、実コストによる管理と進捗の報告を入札条件とする案件が多く見られる。

補助的な指標

実コストではEV、PV、AC、BAC、CV、SVといった主要な指標や値の他に、様々な分析や管理を行うために以下のような補助的な指標を算出して用いることがある。

• CPI(Cost Performance Index：コスト効率指数)は、ある時点までに投入した実コスト(AC)に対する出来高(EV)の比率である。実際のコストが予算に対してどの程度節約、あるいは超過したかを表す指標で、EV/AC という式で求められる。1を上回っていれば予算内、下回っていれば予算超過である。
• SPI(Schedule Performance Index：スケジュール効率指数)は、ある時点の計画値(PV)に対する出来高(EV)の比率である。現在の進捗が予定よりどの程度先行あるいは遅延しているかを表す指標で、EV/PV という式で求められる。1を上回っていれば進捗は計画より早く、下回っていれば計画より遅れている。
• EAC(Estimate At Completion：完成時総コスト見積り)は、ある時点における完成時の総コストの見積り額である。作業が現状のペースで推移したら最終的にどのくらいのコストがかかりそうかを推計したもので、AC+(BAC-EV)/CPI(あるいは、ETCを用いて AC+ETC)という式で算出される。
• ETC(Estimate To Completion：残作業コスト見積り)は、ある時点における完成までの残り作業量を、相当する予算コストの金額で表したものである。EVと同じように作業量をその過程で消化する予定の金額に換算して表したもので、(BAC-EV)/CPI(あるいは、EACを用いて EAC-AC)という式で算出される。
• VAC(Variance At Completion：完成時コスト差異)は、ある時点における完成時の総コストの見積り(EAC)と、計画上の総予算(BAC)との差異である。BACからEACを引いたもので、負の値であればEACの方が小さく、予算内でプロジェクトが完了しそうだが、正の値であればBACの方が小さく、総コストが予算を超過しそうであると分かる。

過去に類似の事例が存在する点についてはその事例の実績値を採用し、事例がない点については経験や勘を元に見積もっていく。

そのプロジェクト特有の事情などは反映されにくく、精度は担当者の知識や経験に大きく左右される。過去に類例の乏しい特殊な案件や新しい種類の案件など、類推が難しい場合もある。

要件や機能などが明確に定義される以前の初期の段階でも適用可能なため、詳しい状況が確定する以前の企画の初期に見積もりが必要な場合に用いられることがある。精度が低く客観性や根拠にも乏しいため、要件定義以降の詳細な見積もりには適さないとされる。

過去のプロジェクトに実際にかかったコストや工数のデータをもとに統計的な法則性を見出し、新規のプロジェクトについてコード行数や投入人員といった過去と同じ項目の値を集めて算定式に当てはめることでコストや工数を導き出す手法である。

見積り法の大きな分類の一つで、「パラメトリック見積り」という一つの具体的な手法があるわけではない。パラメトリック見積りに分類される具体的な手法として、LOC法、ファンクションポイント法(FP法)、COCOMO、CoBRAなどがよく知られる。

1980年代前後に活発に研究された手法で、類推法(トップダウン法)や標準タスク法(ボトムアップ法)などノンパラメトリックな手法と対比される。ある特定の環境を前提に構築された算定モデルを別の環境にそのまま適用すると精度が落ちてしまうため、分野や企業ごとに係数の較正(キャリブレーション)を行う必要がある。

過去の経験などから最も可能性が高いと考えられる最頻値、最も順調に進んだ場合の楽観値、最も悪条件が重なった場合の悲観値の3つの値を見積もる。これらがベータ分布に従って起きると仮定し、平均値 (楽観値＋最頻値×4＋悲観値)/6、分散 {(楽観値-悲観値)/6}²、標準偏差(分散の平方根)を求める。

このような統計的な処理を行うことにより、平均値±標準偏差に収まる確率は約68%、平均値±標準偏差×2に収まる確率は約95%などといった具合に確からしさを範囲と確率の関係で表すことができる。工程や予算、人員、関係する組織などが多い大規模な開発プロジェクトに向いているとされる。

利用者から見たソフトウェアの持つ機能を分解し、外部との入出力、ファイルとの入出力など種類ごとに整理してそれぞれいくつあるかを数える。利用者が認識しない内部的なデータ処理などはカウントしない。

それぞれの機能について過去の類似の事例などから導き出された複雑度の評価を行い、その機能の持つ点数(ファンクションポイント)とする。これをプログラム全体に渡って合算した合計値に、システムに要求される特性(データ通信が必要、分散処理が必要)に応じて決定される上下35%(0.65～1.35)の幅を持つ係数を掛け合わせて評価値とする。

ソースコード行数(LOC：Line Of Code)などによる評価・見積もりに比べ、プログラミング言語の種類や書き方、機能の実装方法などに依存しない、データフローダイアグラムやER図など設計段階で作成される資料から算出できる、利用者から見た機能に基づくため利用者側(開発依頼側)の納得を得やすいといった利点がある。

一方、機能の複雑度の判定などは主観が入り込みやすく、過去に類似の事例のない場合の評価が難しいといった難点もある。アメリカでは1986年に業界団体のIFPUG(International Function Point Users Group)が設立され、評価法についての標準的なガイドラインを発行している。これに基づく算出法のことをIFPUG法ということがある。

計測対象となるソフトウェアについて、人間に理解しやすいプログラミング言語で記述されたプログラムであるソースコードの行数を数え上げ、これを規模とする手法である。

プログラムの大きさを表す単位は「行」(LOC：Line Of Code)となるが、規模の大きなソフトウェアの場合は、補助単位を用いてKLOC(キロLOC：1000行)や、MLOC(メガLOC：100万行)などの単位で表すこともある。

基準が明白で計測しやすく、計測の自動化も簡単だが、言語やアルゴリズムの種類、記述者の癖や力量などで同じ機能を記述しても大きく行数が異なる場合があり、基準としての信頼性が低いのが難点である。

また、現在普及しているプログラミング言語は、文の途中での改行や、空行やコメント行の記述について柔軟で自由度が高いものが多いため、計測時に空行などを自動的に排除したり、開発の開始前にあらかじめ標準的な記法(コード規約)を定めておくなどの工夫が必要になる。

COCOMOでは、開発するプログラムの想定ソースコード行数を元に、プログラマの習熟度や再利用できるソフトウェアの量などの様々な要因から開発規模を見積もり、これに十数個の補正係数(「コストドライバ」と呼ばれる)を掛け合わせて工数を見積もり、最後に工数から開発期間を見積もる。

1995年には南カリフォルニア大学(USC)に移った同氏により、ファンクションポイント法(FP法)や繰り返し型開発などを考慮した「COCOMO II」が発表された。当初発表されたCOCOMOは新しいものと区別するために「COCOMO 81」などと呼ばれることもある。2000年には多くの開発プロジェクトから得られたデータをフィードバックした「COCOMO II.2000」が発表されている。

COCOMO IIでは、開発するプログラムの想定ソースコード行数を元に、プログラマの習熟度や再利用できるソフトウェアの量などの様々な要因から開発規模を見積もり、これに十数個の補正係数(「コストドライバ」と呼ばれる)を掛け合わせて工数を見積もり、最後に工数から開発期間を見積もる。

1995年には南カリフォルニア大学(USC)に移った同氏により、ファンクションポイント法(FP法)や繰り返し型開発などを考慮した「COCOMO II II」が発表された。当初発表されたCOCOMO IIは新しいものと区別するために「COCOMO II 81」などと呼ばれることもある。2000年には多くの開発プロジェクトから得られたデータをフィードバックした「COCOMO II II.2000」が発表されている。

プロジェクト全体をWBS(Work Breakdown Structure)などを用いて細かい工程に分割し、各工程にかかる予算コストを見積もる。これをスケジュールに沿って積算し、各時点での計画値(PV：Planned Value)を用意する。プロジェクト完了時のPV、すなわち計画上の総予算を「BAC」(Budget At Completion：完成時総予算)という。

プロジェクト開始後、ある時点までに完了した工程の予算額の合計が出来高(EV：Earned Value)である。EVMにおける最も基本的かつ重要な指標で、ある時点までに完了した工程の予算コストの合計である。作業の到達度を金銭的な価値に換算したものと考えることができる。定義上、EVがBACに達するとプロジェクト終了となる。

また、その時点までにかかった実際のコストの積算値を実コスト(AC：Actual Cost)という。ある時点におけるEVがPV(計画上消化済みのはずの予算額)と異なる場合、両者の差が計画と実際のスケジュール差異(SV：Schedule Variance)となる。一方、ACがEV(計画上かかるはずだったコスト)と異なる場合、両者の差が計画と実際のコスト差異(CV：Cost Variance)となる。

例

例えば、全体が3つの工程に分かれ、それぞれ工期1か月、予算100万円(全体では3か月、300万円)という見積りのプロジェクトがあり、2か月が過ぎた時点で150万円を支払って1つ目の工程が完了したとする。

この時点でのEVは1つ目の工程にかかるはずだったコストの100万円、PVは2か月で完了しているはずの2つの工程の予算である200万円、ACは実際に消費した150万円である。計画と実際のコスト差異(CV)は100-150で-50万円、スケジュール差異は100-200で-100万円である。

これを見て分かる通り、CVが正ならコストが予算に収まっており、負なら予算超過である。SVが正なら計画より早く進行しており、負なら遅延が生じている。スケジュールの進捗状況も金額に換算して表現される点が特徴的である。

グラフ

EVMでは進捗を積み上げ折れ線グラフに図示することで、状況の推移を視覚的に分かりやすく把握することができる。原点をプロジェクト開始時として、横軸を時間、縦軸を金額としてPV、EV、ACの3本の折れ線グラフを描画する。

プロジェクト開始時には原点から右上に伸びるPVのみが描画される。進行に伴って原点からEV、ACが徐々に右上に伸びていく。PVの線に対してEVが上方ならばスケジュールは順調で、下方ならば遅延している。また、EVに対してACが上方ならば予算超過で、下方ならば予算内に収まっている。

EVMの意義

EVを中心に考えることで、プロジェクトの進行中にコスト、スケジュール両面の進捗状況を統一的な尺度で把握することができる。それまでの計画とのズレの大きさから、完成までの総時間、総コストを予測することもできる。

EVMは1960年代に米軍で考案された手法で、アメリカ政府では一定額以上の入札に関して事業者にEVMに対応することを義務付けている。プロジェクトマネジメントの標準的な手法をまとめたPMBOKでも進捗管理の基本的な方法論として紹介されている。近年では日本でも情報システムの公共調達などで、EVMによる管理と進捗の報告を入札条件とする案件が多く見られる。

補助的な指標

EVMではEV、PV、AC、BAC、CV、SVといった主要な指標や値の他に、様々な分析や管理を行うために以下のような補助的な指標を算出して用いることがある。

• CPI(Cost Performance Index：コスト効率指数)は、ある時点までに投入した実コスト(AC)に対する出来高(EV)の比率である。実際のコストが予算に対してどの程度節約、あるいは超過したかを表す指標で、EV/AC という式で求められる。1を上回っていれば予算内、下回っていれば予算超過である。
• SPI(Schedule Performance Index：スケジュール効率指数)は、ある時点の計画値(PV)に対する出来高(EV)の比率である。現在の進捗が予定よりどの程度先行あるいは遅延しているかを表す指標で、EV/PV という式で求められる。1を上回っていれば進捗は計画より早く、下回っていれば計画より遅れている。
• EAC(Estimate At Completion：完成時総コスト見積り)は、ある時点における完成時の総コストの見積り額である。作業が現状のペースで推移したら最終的にどのくらいのコストがかかりそうかを推計したもので、AC+(BAC-EV)/CPI(あるいは、ETCを用いて AC+ETC)という式で算出される。
• ETC(Estimate To Completion：残作業コスト見積り)は、ある時点における完成までの残り作業量を、相当する予算コストの金額で表したものである。EVと同じように作業量をその過程で消化する予定の金額に換算して表したもので、(BAC-EV)/CPI(あるいは、EACを用いて EAC-AC)という式で算出される。
• VAC(Variance At Completion：完成時コスト差異)は、ある時点における完成時の総コストの見積り(EAC)と、計画上の総予算(BAC)との差異である。BACからEACを引いたもので、負の値であればEACの方が小さく、予算内でプロジェクトが完了しそうだが、正の値であればBACの方が小さく、総コストが予算を超過しそうであると分かる。

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

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

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

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

リスク管理とは、将来のリスクを考えうる限り想定し、それぞれについて事前に対処方針を定め、実際にリスクが顕在化した際に方針に則って対処するという一連の行動を、組織内の仕組みとして明確なプロセスの元に実施することを意味する。

一般的な流れとしては、まずリスク特定、リスク分析、リスク評価からなる「リスクアセスメント」(risk assessment)を実施してリスクの洗い出しと対処方針の策定を行う。その後、事業を遂行する中で実際に遭遇した事象に対してリスク対応を行う。一定の期間が経過したら、記録を元に振り返り(レビュー)を行い、対処方針の改善などを行う。これを一つのサイクルとして、事業年度ごとなどの単位で繰り返し実施する。

情報の出し手は相手や状況などを特定せず、情報を共通の蓄積場所に掲示する。受け手はその中から自分に必要なものを選んで情報を受け取る。(電子)掲示板やナレッジベース、イントラネットサイトに構築された情報共有システムなどを利用することで実現できる。

即時性を保証したり双方向的なやり取りを行うのは難しいが、受け手が出し手の都合に左右されず自分のタイミングで情報に触れることができる利点がある。多数に広く共有する必要がある情報、誰がいつ必要になるか明確には分からない情報の伝達に適している。

これに対し、電話や会議のようにメンバー間で相互に情報が交わされる様態を「相互型コミュニケーション」、電子メールやメッセンジャー、手紙、メモ、報告書などのように情報の出し手が特定の相手に向かって能動的に情報を送る様態を「プッシュ型コミュニケーション」という。

広義には、電子的な手段でメッセージを交換するシステムやサービス、ソフトウェア全般を指し、携帯電話のSMSや、各種のネットサービスやアプリ内で提供される利用者間のメッセージ交換機能などを含む。

狭義には、SMTPやPOP3、IMAP4、MIMEなどインターネット標準の様々なプロトコル(通信規約)やデータ形式を組み合わせて構築されたメッセージ交換システムを指し、現代では単に電子メールといえば一般にこちらを表すことが多い。

メールアドレス

電子メールの送信元や宛先は住所や氏名の代わりに「メールアドレス」(email address)と呼ばれる統一された書式の文字列が用いられる。これは「JohnDoe@example.com」のように「アカウント名@ドメイン名」の形式で表され、ドメイン名の部分が利用者が所属・加入している組織の管理するネットワークの識別名を表し、アカウント名がその中での個人の識別名となる。

企業や行政機関、大学などがメールサーバを運用して所属者にメールアドレスを発行しているほか、インターネットサービスプロバイダ(ISP)や携帯電話事業者などがインターネット接続サービスの一環として加入者にメールアドレスを発行している。

また、ネットサービス事業者などが誰でも自由に無料でメールアドレスを取得して利用できる「フリーメール」(free email)サービスを提供している。一人の人物が立場ごとに複数のアドレスを使い分けたり、企業の代表アドレスのように特定の個人に紐付けられず組織や集団などで共有されるアドレスもある。

メールサーバとメールクライアント

インターネットに接続されたネットワークには「メールサーバ」(mail server)と呼ばれるコンピュータが設置され、利用者からの要請により外部のネットワークに向けてメールを送信したり、外部から利用者に宛てて送られてきたメールを受信し、本人の使うコンピュータに送り届ける。利用者や他のサーバに対する窓口であり、郵便制度における郵便局のような役割を果たす。

メールサーバ内には利用者ごとに私書箱に相当する受信メールの保管領域(メールボックス)が用意され、外部から着信したメールを一時的に保管する。利用者が手元で操作するメールソフト(メールクライアント、メーラーなどと呼ばれる)は通信回線を介してメールサーバに問い合わせ、メールボックス内のメールを受信して画面に表示する。

Webメール

利用者の操作画面をWebアプリケーションとして実装し、Webブラウザからアクセスしてメールの作成や送信、受信、閲覧、添付ファイルのダウンロードなどをできるようにしたシステムを「Webメール」(webmail)という。

フリーメールサービスの多くは標準の操作画面をWebメールの形で提供しており、メールクライアントなどを導入・設定しなくてもWebブラウザのみでメールの送受信を行うことができるようになっている。企業などの組織で運用されるメールシステムでもWebメールを提供する場合があり、自宅や出先のコンピュータなどからアクセスできるようになっている。

メッセージの形式

電子メールには原則として文字(テキスト)データのみを記載することができる。特別な記法や書式を用いずに素の状態の文字データのみが記されたメールを「テキストメール」という。WebページのようにHTMLやCSSなどの言語を用いて書式や装飾、レイアウトなどの指定が埋め込まれたものは「HTMLメール」という。

また、画像や音声、動画、データファイル、プログラムファイルなどテキスト形式ではないデータ(バイナリデータ)を一定の手順でテキストデータに変換して文字メッセージと一緒に送ることができる。こうしたデータをメッセージ中に埋め込む方式の標準として「MIME」(Multipurpose Internet Mail Extension/マイム)が規定されており、これを利用してメールに埋め込んだファイルを「添付ファイル」(attachment file)という。

電子メールの普及と応用

電子メールはWeb(WWW)と共にインターネットの主要な応用サービスとして広く普及し、情報機器間でメッセージを伝達する社会インフラとして機能している。現在ではパソコンやスマートフォン、タブレット端末などのオペレーティングシステム(OS)の多くは標準でメールクライアントを内蔵しており、誰でもすぐに利用できるようになっている。

電子メールシステムでは一通のメールを複数の宛先へ同時に送信する同報送信・一斉配信も容易なため、グループ共通のアドレスを用意してメンバー間の連絡や議論などに用いる「メーリングリスト」(mailing list)や、発行者が購読者に定期的にメールで情報を届ける「メールマガジン」(mail magazine)などの応用システムも活発に利用されている。

一方、広告メールを多数のメールアドレスに宛て無差別に送信する「スパムメール」(spam mail)や、添付ファイルの仕組みをコンピュータウイルスの感染経路に悪用する「ウイルスメール」(virus mail)、送信元を偽って受信者を騙し秘密の情報を詐取する「フィッシング」(phishing)など、電子メールを悪用した迷惑行為や犯罪なども起きており、社会問題ともなっている。

カメラやマイクのあるコンピュータを用いて、それぞれ離れた別の場所にいる人達の間で映像と音声による通話を行うことができる。2人(2箇所)の間を繋ぐ「テレビ電話」(ビデオ電話)とは異なり、3人(3箇所)以上を同時に繋ぐことができる。2箇所を繋いでテレビ電話として使うこともできる。

画面上には自分の姿と共に、他の参加者の姿が映し出され、音声も各箇所のものが合成されて流れる。参加者が増えても一定の通話品質を保てるよう、端末同士を相互に相対接続するのではなく、サービス提供元のサーバで参加者から送られてくる映像や音声を統合して各端末に配信する方式のものが多い。

テレビ会議のシステムを基盤に、資料やデータを共有して共同作業を行ったり、操作画面を共有したり、文字メッセージを交換するチャットを行う機能などを統合したものは「Web会議」という。会議だけでなく離れた場所にいるメンバー同士が共同で作業や業務を進めることができる。

テレビ会議やWeb会議の仕組みは以前から存在したが、新型コロナウイルス感染症の突然の大流行で外出が大きく制限されたことをきっかけに2020年から一気に普及・浸透が進んだ。仕事上の会議や打ち合わせ、商談だけでなく「オンライン飲み会」など社交の場としても活用された。

著名な製品およびサービスとしては、米ズーム・ビデオコミュニケーションズ(Zoom Video Communications)社の「Zoom Meetings」、米マイクロソフト(Microsoft)社の「Microsoft Teams」および「Skype for Business」、米シスコシステムズ(Cisco Systems)社の「Cisco Webex」、米グーグル(Google)社の「Google Meet」(旧Hangouts Meet)などがある。これらの製品はいずれも仕事で使えるようにWeb会議の機能を備えている。