仕事の基礎知識

PMO（Project Management Office）/プロジェクトマネジメントオフィス

プロジェクトマネジメントオフィス（PMO）とは、プロジェクトの生産性を上げるための活動を行う組織を指す。具体的には、各フェーズで必要なマネジメントプロセス（進捗管理・課題管理・リスク管理・変更管理・障害管理・QA管理・リソース管理・コスト管理など）の定義を行い、各プロセスをプロジェクト現場に導入・定着化させるまで地道に活動を行い、プロジェクト状況の見える化を行う。また、プロジェクトマネジャーが誤った意思決定をしないように適切な情報をいつでも提供できるようにし、プロジェクト成功への確率を高める役割も担っている。

PgMO・部門PMO（Program Management Office）／プログラムマネジメントオフィス

プログラムマネジメントとは、複数プロジェクトを統括マネジメントすることを指す。プログラムマネジメントオフィスは、部門内で複数プロジェクトが遂行されている状況で、それぞれのプロジェクトの個別最適を考えるのではなく、プロジェクト間の優先度決め、整合性の確認、リソースの最適化など全体最適を考え、各プロジェクトのフェーズごとの開始・終了の判定やリスク評価を行う。また、生産性を上げるためにプロセスの標準化や各種テンプレートの提供を行い、企業・組織としてパフォーマンスを最大化させる役割も担う。プロジェクトマネジメントオフィス（PMO）とは、役割機能が異なるため注意が必要。

EPM・全社PMO（Enterprise Project Management）／エンタープライズマネジメントオフィス

エンタープライズマネジメントオフィスとは、全社レベルでのマネジメントを行う組織体を指す。プロジェクトマネジメントオフィス（PMO）は、単体プロジェクトでのマネジメントを行う組織で、プログラムマネジメントオフィス（PgMO）は事業部・部門内でのマネジメントを行う組織を指し、そしてエンタープライズマネジメントオフィスはその上位概念の組織を指す。 社内の各個別プロジェクトに対して全社的な観点からの状況判断（収支状況や品質、リスク）や支援（人的リソースや技術的サポートなど）を行う。また、会社組織としてのプロジェクトナレッジの蓄積や各プロジェクトへのフィードバックを行い、各プロジェクトの生産性を上げる為の活動を行う。

プロジェクトマネジメントツール

プロジェクトマネジメントツールとは、プロジェクト管理ツールとも言われ、主にプロジェクトに必要な各種管理プロセスを効率化する目的に使用されるツールを総称して指している。Microsoft社のMicrosoft Office Projectをはじめ、弊社のPROEVERなどのツールがある。プロジェクトマネジメントツールには、使用目的やその背景により多くの機能がある。例えば、弊社のPROEVERは進捗管理・課題管理・リスク管理・変更管理・ToDo管理・ドキュメント管理・議事録作成機能といったプロジェクトで必要なマネジメントノウハウを提供している。

プロジェクトマネジメントプロセス

プロジェクトマネジメントプロセスとは、「PMBOK®ガイド」では立上げ、計画、実行、監視コントロール、および終結の5つのプロセス群と定義している。弊社では実際のプロジェクトでは進捗管理、課題管理、リスク管理、変更管理、コミュニケーション管理、障害管理、品質管理、QA管理など、各プロジェクトにおいて必要なプロセスをオーダーメイドで用意して適用している。

進捗管理

進捗管理とは、プロジェクトの計画通りに進捗が進んでいるかをチェックし、遅延が発生している場合には遅延原因を特定し、どのようにリカバリーを行うかの計画を立て、実施していく一連のプロセスである。進捗管理においては、プロジェクトの作業を構造化したWBSを利用してガントチャートを作成して、進捗管理を行うのが一般的である。

課題管理

課題管理とは、日々の活動において発生する問題を適切に管理し、解決までモニタリングするプロセスを指す。問題・課題・リスク・ToDoを混同してしまうと、問題の本質が見落とされ、気がついたときには遅かったという事態になる恐れがある。そのような事態を避けるために、課題管理を導入・定着させるポイントは、PMOのようなプロジェクトマネジメント専門部隊が適切なプロセスを設計し、実施状況のモニタリングを行いながら、地道にPDCAを回しプロセスの改善活動を実践していくことである。

リスク管理

リスク管理とは、メンバー間でリスクの感度を統一化し、将来問題として顕在化する可能性のある事象（＝リスク）に対して、可能な限り発生しないように対策を練り、発生確率を低くすることだ。一方で、発生してしまった際の対処方法もある程度決めておき、課題化しても焦ることがないようにする活動も含まれる。

ToDo管理

ToDo管理とは、プロジェクトにて発生する実施すべき事項（ToDo・タスク）を管理すること。一般的にはToDo（タスク）一覧の表形式の一覧にて管理を行う。管理する内容は、担当者、状況、期限、優先度、他のToDoへの影響、進捗率、ToDoクローズの条件などがある。管理を行うためには、対象ToDoの担当者、実施方法や期限が明確になっており、ToDoを実行する上での問題が解消されていることが望ましい。ToDoを実行する上で問題がある場合は、課題管理として取り扱い、リスク的な要素の場合はリスク管理として扱う。ToDo管理内に、課題やリスクを混同してしまうと問題の本質が見えなくなる恐れがあるため、明確に分けた管理が必要となる。

品質管理

品質管理とは、顧客要求を満たした成果（システムや商品やサービス）を実現するための品質を担保していく活動を指す。品質を高めるためには、品質目標を立て、計画と実績の比較、評価を実施し、改善を行うPDCAサイクルが必要となる。

QA管理

QA管理とは、プロジェクト活動内で発生したQA（質問と回答）を管理（質問票の起票から回答までの一連のプロセス。）する事を指す。一般的に質問は、仕様を詰める際・設計書を開発会社に引渡す際・エンドユーザーにプロジェクトの説明を実施する際・テストを実施する際、とさまざまなタイミングで発生する性質を持っている。各タイミングに合ったプロセスを用意することで、マネジメントプロセスが上手く回るようにする点がポイント。QA管理単独で考えるのではなく、インシデント管理内の1つの事象として捉えて管理することが多い。

障害管理（不具合）・バグ管理

障害（不具合）管理とは、システムや商品、サービスにおいて障害が発生したときの、状況把握から修復までの一連の管理プロセスを指す。障害箇所と障害原因の特定、修理結果の確認、障害記録の整理などを含む。安全性、厳格性と迅速性のバランスを取りながら、プロジェクトごとに最適化された管理プロセスを作成することが必要となる。

インシデント管理

インシデントとは「管理すべき事項」のことで、障害、顧客からのクレーム、要望、リスク、発生した問題、変更依頼、QAなどを指す。そしてインシデント管理は、解決すべき障害や問題などの、インシデントの検知から対策の策定、実施・解決の確認までの一連の管理プロセスのことである。インシデント管理のうち、長期的な改善や抜本的な見直しが必要なものは、別途課題として管理することもある。 インシデント（管理すべき事項）は、顧客からの要望が問題に発展したり、QAとなったりと複数のプロジェクト、管理プロセスと紐付く内容のため、各プロジェクト、管理プロセスを複数束ねた概念でプロセスを策定する点がポイントとなる。

コミュニケーション管理

コミュニケーション管理とは、プロジェクト内におけるコミュニケーションを通じた意思決定のあり方を定義するものである。具体的には、プロジェクトマネジャーへのレポーティングルール、会議体の整理、議事録ルール、メールに関するルール、各ステークホルダーとのコミュニケーションの方法などを定義し、コミュニケーションミスを防ぎ、プロジェクトにおける意思決定の質とスピードを上げることを目的とする。

アーンドバリューマネジメント

EVMとは、プロジェクトの計画と実績を比較して、進捗状況を分析し、プロジェクト完了までにかかる時間やコストを定量的に予測するための管理方式を指す。
EVMを用いれば、あるプロジェクトが、将来のある時点でどの段階まで進行しているかを予測することが可能となる。つまり、プロジェクトマネジャーはその予測に基づいて、リソース管理や計画の見直しといった重要な判断を下すことができるようになる。ただし、EVMを実際に運用する際は、プロジェクトの実績を正確に細かく把握するため、それ相応の管理工数が発生する。そのため、長期的に維持運用していくためには、PMOのようなプロジェクト管理プロセスの導入定着化を推進していく組織体が無いと、形骸化してしまう可能性も高い。

ファンクションポイント法

ファンクションポイント法とは見積もり対象の機能に注目し、その機能数と重み付けによって規模を計算する方法。開発現場ではCOCOMO、WBSからのボトムアップ見積もりなどと並びよく使用される見積もり方法だ。

【公式】 ファンクションポイント＝基準値×（0.65＋調整値／100）

基準値とは、①外部入力先数 ②外部出力先数 ③外部照合先数 ④内部論理ファイル数 ⑤外部インターフェイス数の 5つをポイント化（難易度に応じて重み付け）したものである。
調整値とは、システム特性を鑑みてその難易度を0～5の6段階で評価し、それを合計した数値である。

COCOMO（constructive cost model）

COCOMOとは、ソフトウェア開発の工数・期間の見積もり手法。1981年にバリー・ベーム（Barry Boehm）博士が提唱した。具体的には開発するソフトウェアの予想されるコード行数に、エンジニアの能力や要求の信頼性といった補正係数を掛け合わせて（名目工数×努力係数）、開発に必要な工数、期間、要員、生産性を算出する。実装言語の違いに左右されず、客観的な数値を算出できるといわれている。また基本の数式モデルについても、実際のプロジェクトにおける適用結果をフィードバックし、精緻化を重ねている。

しかしCOCOMOでは分析・設計工程の見積もりが不可能なことに加え、組織全体の開発能力の成熟度や、開発・テスト・検証を重ねる「繰り返し型開発プロジェクト」に適していないという問題があった。そこで従来のCOCOMOを拡張し、ファンクションポイント法やCMMの概念を取り入れ、より正確な工数算出を実現したCOCOMO IIが提唱されている。 Boehm氏自身、Rational Unified Process（RUP）のような反復型開発スタイルにCOCOMO IIを適用した事例を「Software Cost Estimation With Cocomo II」の中で著している。COCOM IIのマニュアルは南カリフォルニア大学のWebサイトから入手可能。

マスタースケジュール

プロジェクトの開始から完了までに必要な作業を洗い出し、それらを順序付けたものがマスタースケジュール。各チームはマスタースケジュールに基づきより詳細なWBSを作成し進捗管理を実施する。大抵のプロジェクトでは、マネジメント上層部への進捗管理報告は、マスタースケジュールをベースに報告し、プロジェクト内での進捗管理報告はWBSを基に報告を行う事が多い。 マスタースケジュールの変更はマネジメント上層部の承認が必要になり、変更に伴うインパクトが大きくなることが一般的である。

役割責任

役割責任とは、組織やプロジェクトにおける役割と責任を明確にすること。一般的に体制図と照らし合わせながら、各担当の割り当てられた役割と責任を把握するために使用する。役割責任をより明確にするために、RACI（レイシー）を作成する場合もある。

RACI／レイシー

RACIとは、組織やプロジェクト内の各担当の役割をResponsible（実行責任者）、Accountable（説明責任者） 、Consulted（協業先）、Informed（報告先） の4つに分けて整理していく方法である。一人の担当が複数の役割を持つこともある。

体制図

体制図とは、プロジェクトを進める上での体制を表した図。プロジェクトにおいて一般的には、ピラミッド型の階層構造で表現される。階層構造は情報や指示命令系統の流れが見やすいという特徴がある。また、体制図はフェーズごとに役割責任とともに見直す必要がある。

CCB（Change Control Board）／変更管理委員会

CCB（変更管理委員会）とは、プロジェクトで日々発生する個々の変更依頼を分析し、どのように対応するか決定および承認し、担当者をアサインする会議体を指す。変更管理プロセスを策定する際に、CCB（変更管理委員会）を盛り込むプロセスにすることが多い。具体的には、変更依頼を実現するためにどの程度の工数がかかるか、調査するかどうかの承認可否と調査後の対応実施可否の2段階の承認を意思決定する。

SWOT分析

SWOT分析とは、企業や組織の内的環境と外的環境を評価することにより、企業や組織が置かれている状況を網羅的に評価する分析手法を指す。SWOTは、その分析で必要となる、強み（Strengths）・弱み（Weaknesses）・機会（Opportunities）・脅威（Threats）の頭文字をとったものである。通常、これら4要素をマトリックスにして分析を行う。内的環境の評価には、組織がもつ強み（Strengths）・弱み（Weaknesses）を、外的環境の評価には、外的環境に潜む機会（Opportunities）や脅威（Threats）を明らかにし、評価を行う。

フェーズ

フェーズとは、プロジェクト全体をまとまったある期間･規模で区切った単位を指す。一般的には、下記のような区切り方をする。

1. 立上げ段階：顧客の期待を明らかにしてプロジェクト憲章をまとめる。
2. 計画段階：プロジェクトの目標、範囲をもとに、工程、予算をまとめる。
3. 実行段階：プロジェクトチームを運営して、設計、調達、工事を行い、プロジェクトを遂行する。
4. 終了段階：プロジェクトの実績、反省をまとめる。
5. 運用段階：プロジェクトで作成したものを実際に使用し始める。

なお、プロジェクトの性質毎にフェーズの考え方は異なるため、プロジェクト初期の段階でフェーズを定義しておくのが一般的である。フェーズを決めておくことで、フェーズ開始条件とフェーズ終了条件を明確にしておき、その条件が満たない場合は、期間延長をするのか、代替案を出して進めるのか、中止するのかといった意思決定に利用することもある。

バランススコアカード

バランススコアカードとは企業のもつ重要な要素が、企業のビジョン・戦略にどのように影響し業績に現れているのかを可視化するための業績評価手法である。財務の視点、顧客の視点、業務プロセスの視点、成長と学習の視点の4つの視点で評価を行なうことが一般的で、企業のもつ有形資産、無形資産、未来への投資などを含めた今を総合的に評価する手法だ。可視化する際のKPIを設定し、意思決定に繋げるPDCAサイクルが構築されるようにしていく点がポイントとなる。

Project Management Professional (PMP)

PMPとは、「PMBOK（Project Management Body of Knowledge）」の知識体系に準拠して実施される試験である。受験者はPMBOKの知識（プロジェクトマネジメントに対する方法論、プロフェッショナリズムなど）を問われ、合格したものに対してPMPの認定が与えられる。試験はパソコンを使用した選択方式。受験のためには、指定された時間の実務経験と認定機関での研修が必要。また、試験合格後は資格継続のためPDUとういう資格継続のための単位を取得する必要がある。詳細は、PMI日本支部のwebサイトを参照。

プロジェクト憲章

プロジェクト憲章とは、プロジェクトの開始に際しマネジメントトップやプロジェクト責任者が行う、プロジェクト実施の理由と目的の明確化を指す。プロジェクトのオーソライズ（承認）、プロジェクトゴール、プロマネの任命とプロジェクトへの支援の宣言、さらにプロジェクト目標（工程短縮、安全確保、技術移転など）を簡潔に述べる。以下のような内容を文書化したプロジェクトにおけるバイブルとなるものである。

• プロジェクト名
• 背景、要求事項
• 最終成果物
• 終了条件
• 予算，期限
• 組織体制
• 各メンバーの権限と責任
• コミュニケーション手段
• 制約条件

プロジェクト計画書

プロジェクト計画書とは、プロジェクト憲章に準拠した内容で、プロジェクト実行のための詳細な計画を文書化した資料を指す。プロジェクト計画書は、プロジェクト活動の基本となるべき内容を明示していなければならない。 具体的には、プロジェクトの目標、業務内容、スケジュールなどのプロジェクト内容の記述、プロジェクト組織、責任分担表、コミュニケーション計画などを規定する。プロジェクト計画書に記載されたスケジュールやコストがプロジェクトのベースラインとして設定されることが一般的である。

工事進行基準

工事進行基準とは、工事（開発）の進捗度合いに応じて工事（開発）に関する収益と原価を案分して計上する方法で、2009年4月に導入された会計基準のことを指す。従来のシステム業界の多くは、工事完成基準と呼ばれる考えで売り上げを計上してきた。この工事完成基準は工事が完成し、引き渡しが完了した日に工事収益を認識する事を指す。進捗度を表す方法としては原価比例法（工事原価の見積もり総額に占める実際原価の割合から進捗度を導く方法）や定量的なアウトプット割合や実工数などから求めるEVM方法がある。工事進行基準を適用するに当たり、プロジェクト状況の見える化も同時に行われないと何故そのような状況になったのかといった原因把握が出来なくなるために、そのためのプロジェクト管理プロセスの導入は必須事項でもある。

ERM（Enterprise risk management）／エンタープライズリスクマネジメント

ERM（エンタープライズリスクマネジメント）とは、全社レベルでのリスク管理手法のこと。各企業が事業を遂行していく中で、発生するリスクを統合的にコントロールし企業価値向上につなげていく活動を指す。各プロジェクト内で行われるリスク管理は、PMO（プロジェクトマネジメントオフィス）が運用を行い、事業部単位で行われるリスク管理は、PgMO(プログラムマネジメントオフィス）が運用を行う。ERMは、EPM（エンタープライズプロジェクトマネジメント）にて行うイメージを持っていただくと理解がしやすい活動となる。 ERMという言葉は、2004年に米国トレッドウェイ委員会組織委員会（COSO）がCOSO ERMフレームワークを公表したことで、広くERMという言葉が使われるようになった。

WBS（Work Breakdown Structure）／ワークブレークダウンストラクチャー

WBSとは、プロジェクト作業を構造化した作業の一覧であり、作業間の先行・後続関係を明示したものである。一般的にマスタースケジュールをインプットにして作成されることが多い。また、WBSの最下層の作業をワークパッケージと呼び作業の最小単位として進捗の管理を行う。

ガントチャート

ガントチャートとは、WBSに担当者や開始予定日、終了予定日を設定し、また、その実績を記録することによって作業の進捗をグラフとして直観的に分かりやすく表現した図である。

ステークホルダー

ステークホルダーとは、プロジェクトにおける利害関係者のことである。

ステークホルダー管理

ステークホルダー管理とは、プロジェクトにおける利害関係者を特定し、プロジェクトに対して良い影響を及ぼすように期待値や関係性を維持していく一連の活動のことを指す。

ファシリテーション

ファシリテーションとは会議や打ち合わせにおいて、目的を効率よく達成するための司会進行のことを指す。アジェンダの設定や雰囲気づくりから、活発な議論が行われるための進行や議論の内容の見える化などが求められる。進行役を務める役割の人はファシリテーターと呼ばれる。

クリティカルパス

クリティカルパスとは、プロジェクトにおいて遅延が許されない作業の流れ（作業と作業つながり）のことを指す。言い換えると、もし、クリティカルパス上にある作業が遅延した場合は、プロジェクト全体が遅延することを意味する。進捗管理上もっとも注意してマネジメントしなければならない一連の主要作業である。

コンティンジェンシー

コンティンジェンシーとは、プロジェクト期間中に発生しうる予想外の出来事のことを指す。
コンティンジェンシーに備えるための計画を、コンティンジェンシープランといい、プロジェクトの成否を左右するような重要な作業や出来事に対しては、通常コンティンジェンシープランを作成する。コンティンジェンシープラン発動のためのコストをコンティンジェンシーリザーブ（コンティンジェンシー費用）と言う。俗称として「プランB」という場合もある。

リソース平準化（負荷平準化）

リソースの平準化とは、プロジェクト内の作業の負荷を平準化することを指す。特定の担当者の負荷が極端に高くなり、その担当者がボトルネックにならないように作業負荷を軽減させることを指す。