PM用語集

プロジェクトがうまくいくために発生する外部の状況やイベントがある。

そのようなイベントが発生すると思っているのなら、それは、前提条件である（リスクの定義と比較される）。

プロジェクト・チームがコントロールできるイベント、例えば、ある期日までテストを完了させるなどは前提条件ではない。

それはアプローチの一部である。

イベントが100％の確率で起こるのであれば、それは前提条件ではない。

可能性やリスクが関わることではなく、まさに事実なのである。

前提条件の例としては、「必要なときに予算と資源が利用可能である」「新規ソフトウェアのリリースが製造フェーズの開始までに行われる」などである。

これは簡単な前提条件の定義である。

プロジェクトやサービスの受益を直接受ける人やグループ。

その人々のためにプロジェクトが実施される（直接的ではない受益者は、おそらくステークホルダーである）。

受益者が会社内部の人やグループであるのなら、彼らのことを「クライアント」を呼び、外部であれば、「顧客、またはカスタマー」と使い分ける場合もある。

制約条件は、プロジェクト・チームのコントロール下にない制限であり、それらをマネジメントする必要がある。

制約条件は必ずしも問題となるとは限らないし、必ずしもイベント・リスクであるとも限らない。

しかし、プロジェクト・マネジャーは、制約条件を意識すべきである。と

いうのも、プロジェクトは制約条件の中で実行するものとして制限を示すからである。

期日の制約条件では、特定のイベント、たとえば、プロジェクト終了日が制約条件であれば、その期日までに行わなければない制限を示す。

また、資源が無制限に供給されることはありえないので、ほとんどの場合、資源は、制約条件となる。

たとえば、一度プロジェクト予算が設定されたら、プロジェクトはその金額の中でまかなわなければならない制約条件となる。

プロジェクト全体をスケジュールどおりに完了するために、必ずスケジュールどおりに完了しなくてはならない連続したアクティビティのことである。

スケジュールの中で、最長の所要期間のパスである。

クリティカル・パス上のアクティビティティが一日遅れたら、プロジェクト全体が1日遅れることとなる。

（クリティカル・パス上のほかのアクティビティが1日早くならない場合）

プロジェクトやサービスの直接の受益者である人やグループである。

プロジェクトは、彼らのために実行される（直接的ではない受益者は、おそらくステークホルダーである）。

受益者が会社内部の人やグループであるのなら彼らのことを「クライアント」を呼ぶ。

外部であれば、テンステップのプロセスでは、「顧客、またはカスタマー」と呼ぶ場合もある。

要素成果物は、プロジェクトが作成する有形の成果物である。

これらには、文書、計画書、コンピュータ・システム、建物、航空機などがある。

内部の要素成果物には、プロジェクト実行の結果として生成されたもの、および通常、プロジェクト・チームだけが必要とするものがある。

外部の要素成果物は、クライアントやステークホルダーのために作成するものである。

機能部門マネジャーは、機能型組織における上司に当たるマネジャーである。

通常、あなたの人事考課を行う人が該当する。

プロジェクト・マネジャーが機能部門マネジャーである場合もあるが、必ずしもそうである必要はない。

プロジェクト・マネジャーがあなたの所属する機能部門のマネジャーと違っていたならば、組織はマトリックス型マネジメントであることを意味する。

ガント・チャートは、アクティビティを行う期間を棒で表わす棒グラフの一種である。

棒の始めと終わりは、アクティビティの開始と終了に対応する。

この用語は、プロジェクトが生成する要素成果物を構築したり、サポートしたりするために使われるプロセスを指す（プロジェクトには開始日と終了日があるので、ソリューションの長期のサポートは通常、プロジェクトが完了後に実施される）。

ソフトウェア開発の包括的なライフサイクルは、計画、分析、設計、製作／テスト、実行およびサポートから構成される。

マイルストーンは、スケジュール上のイベントであり、主要な要素成果物や一連の関連する要素成果物などの完了などを特定するものである。

マイルストーンの定義は、所要期間がゼロで、作業工数が伴わないものである。

マイルストーンに関係する作業はない。

スケジュールにフラグを立て、他の作業が完了したことを明らかにする。

通常、マイルストーンは、プロジェクトのチェックポイントとして使われ、プロジェクトの進捗状況を評価し、残作業を再評価する。

プロジェクトの進捗を評価するマネジメント層向けにハイレベルの視点からのスナップショットとして使われる。

多くの場合、マイルストーンの時点で意思決定する事項がある。

マイルストーンは、通常、カレンダーに基づいたものではなく、1つ以上の要素成果物の完成に基づいたものである。

プロジェクトが達成しようとしていることを明確に記述したものである。

目標は具体的なレベルで記述されるものであり、プロジェクトの終了時点で達成できたか、否かを評価する。

うまく書かれた目標は、具体的（Specific）、測定可能（Measurable）、達成可能（Attainable/Achievable）、現実的（Realistic）、時間制約（Timebound）なものであり、頭文字をとってSMARTと呼ばれる。

プログラムは、関連する一連のプロジェクトをマネジメントするためにアンブレラ構造に設定されたものである。

プログラムは、プロジェクトの要素成果物を生成はしない。

プロジェクト・チームが、プロジェクトの要素成果物すべてを生成する。

プログラムの目的は、全体的な方向性と指針を提供するものであり、関連するプロジェクトに関して効果的なコミュニケーションがとれるように、クライアントとプロジェクト・チームがコンタクトする中心となることである。

さらに、すべての作業を成功して完了させるために個々のプロジェクトをどのように定義するか決定する。

プログラムをマネジメントする権限をもつ人。

（これは役割であることに注意。プログラム・マネジャーがプログラムの中の複数のプロジェクトに責任をもつこともある。プログラム・マネジャーと、その配下のプロジェクトのプロジェクト・マネジャーを勤めることもある。）

プログラム・マネジャーは、プログラムの包括的な計画とマネジメントをリードする。

プログラム内のすべてのプロジェクト・マネジャーは、プログラム・マネジャーに報告義務がある。

A structure to complete a specific defined deliverable or set of deliverables.
A project has a specific begin date and end-date, specific objectives and specific resources assigned to perform the work.
A project manager has overall responsibility and authority over a project.

When the objectives are met, the project is considered complete.

具体的に定義された要素成果物や一連の要素成果物を完了するための構造のことである。

プロジェクトには、明確な開始日と終了日があり、明確な目標と作業を実施するために割り当てられた具体的な資源がある。

プロジェクト・マネジャーは、プロジェクトに対して、包括的な責任と権限がある。

目標を達成したら、プロジェクトが完了したものと考えられる

プロジェクトを開始する前に、プロジェクトの全体的な目標、スコープ、要素成果物、リスク、前提条件、プロジェクト組織図などを知っておくことは重要である。

プロジェクト憲章は、これらの関係する情報を取り上げた文書である。

プロジェクト・マネジャーは、プロジェクト憲章を作成する責任がある。

プロジェクト憲章は、スポンサーが承認するものであり、プロジェクト・マネジャーとスポンサーがプロジェクトのこれらの重要な観点について合意したことを明確にするものである。

The person with authority to manage a project.
This includes leading the planning and the development of all project deliverables.

The project manager is responsible for managing the budget and workplan and all Project Management Procedures (scope management, issues management, risk management, etc.).

プロジェクトをマネジメントする権限をもつ人。

これには、すべてのプロジェクト要素成果物の計画策定、生成をリードすることが含まれる。

プロジェクト・マネジャーは、予算と作業計画、およびすべてのプロジェクトマネジメント・プロセス（スコープ・マネジメント、課題マネジメント、リスク・マネジメントなど）をマネジメントする責任がある。

フェーズは、プロジェクトに関する作業を論理的に分類した作業グループである。

フェーズは、主な要素成果物や一連の要素成果物の完了を示すものであったりする。

IT発プロジェクトにおける論理的なフェーズは、計画、分析、デザイン、製作（テストも含む）、実装である。

The project team consists of the full-time and part-time resources assigned to work on the deliverables of the project.
They are responsible for

• Understanding the work to be completed
• Planning out the assigned activities in more detail if needed.
• Completing assigned work within the budget, timeline and quality expectations
• Informing the project manager of issues, scope changes, risk and quality concerns
• Proactively communicating status and managing expectations

The project team can consist of human resources within one functional organization or it can consist of members from many different functional organizations.

A cross-functional team has members from multiple organizations.
Having a cross-functional team is usually a sign of your organization utilizing matrix management.

プロジェクト・チームは、従業員がフルタイム、またはパートタイムで仕事に割り当てられ、要素成果物を作成していく。

彼らは次のことに、責任をもつ。

• 完了すべき仕事を理解する。
• 必要に応じて、割り当てられたアクティビティを詳細に計画する。
• 割り当てられた仕事を予算、時間、品質の期待の中で完了する。
• 課題、スコープ変更、リスク、品質に関する懸念事項をプロジェクト・マネジャーに知らせる。
• プロアクティブに状況をコミュニケーションし、期待をマネジメントする。

プロジェクト・チームは、1つの機能組織のなかで人的資源が構成されたり、異なる機能組織からの人的資源で構成されたりする。

機能部門を横断したチームは、複数の組織からのメンバーである。

横断型のチームであれば、組織がマトリックス型組織であることを示す。

Requirements are descriptions of how a product or service should act, appear or perform.
Requirements generally refer to the features and functions of the deliverables you are building on your project.
Requirements are considered to be a part of project scope.
High-level scope is defined in your Project Charter.

The requirements form the detailed scope.
After your requirements are approved, they can be changed through the scope change management process.

要求事項は、プロダクトやサービスがどのようなことを行ったり、どのような形で現れたり、どのように実行するかを記述したものである。

要求事項は、通常、プロジェクトにおいて構築する要素成果物の特徴や機能を参照する。

要求事項は、プロジェクト・スコープの一部として考えられる。

ハイレベルのスコープは、プロジェクト憲章で定義される。要求事項は、スコープを詳細にしたものである。

一度、要求事項が承認されたら、スコープに関する変更は、スコープ変更マネジメント・プロセスを通して実施される。

それが起こったらプロジェクトの成功に影響を及ぼす外部の状況やイベントのことである。

そのイベントが発生すると思われるなら、それはリスクとなる（前提条件の定義と比較すること）。

リスクはその姿が見えてくるにつれて、特定されるものであり、プロアクティブにリスク・マネジメント計画を実施する。これはプロジェクト・リスクの簡単な定義である。

プロジェクト・スケジュールは、「どのように」プロジェクトを完了するか伝えるものである。

スケジュールは、必要なアクティビティ、作業の順序、作業へ割り当てられた担当者、作業量の見積もり、作業の期日など、プロジェクト・マネジャーにとって重要な情報を記述する。

スケジュールは、プロジェクト・マネジャーがプロジェクトを完了するために必要な作業を特定することを可能にし、さらに、プロジェクトがスケジュールどおりに進んでいるかを判断できるように、作業の監視を可能にする。

スコープは、プロジェクトの境界を記述する方法である。

プロジェクトが何を生成し、何を生成しないかを定義する。

大規模プロジェクトでは、影響を受ける組織、影響を受ける取引き、含まれるデータの種類などがある。

プロジェクトに関して最終的な権限をもつ人物である。

エグゼクティブ・スポンサーは、プロジェクトの資金を調達し、課題やスコープ変更を解決し、主な要素成果物を承認し、ハイレベルの方向性を提供する。

組織内のプロジェクトのチャンピオンでもある。

プロジェクト、およびエグゼクティブ・スポンサーの組織の地位によっては、日々の実務的なマネジメントをプロジェクト・スポンサーに委任する。

任命されたプロジェクト・スポンサーは日常の実務に関してエグゼクティブ・スポンサーの代理として、スポンサーの承認を要する意思決定を行う。

決定事項が重要なことであるなら、プロジェクト・スポンサーは、エグゼクティブ・スポンサーにそれをもっていく。

プロジェクトの成果物に利害関係をもつ特定の人やグループ。

常、ステークホルダーは、企業内におり、内部のクライアント、マネジメント層、従業員、管理者などを含む。

プロジェクトには、外部のステークホルダーもおり、サプライヤー、投資家、コミュニティ・グループ、政府組織などがある。

A standard is a required approach for conducting an activity or task, utilizing a product, etc.

Many times a standard is a best practice that must be followed to have a better chance of overall success.

アクティビティやタスクの実行、プロダクトを利用するためなどに要求されるアプローチ。

多くの場合、標準化は、成功の機会を高めるために従うべきベストプラクティスである。

A Steering Committee is usually a group of high-level stakeholders that are responsible for providing guidance on overall strategic direction.

They do not take the place of a Sponsor, but help to spread the strategic input and buy-in to a larger portion of the organization.

The Steering Committee is usually made up of organizational peers, and is a combination of direct clients and indirect stakeholders.

運営委員会は、通常ハイレベルのステークホルダーのグループであり、包括的な戦略の方向性の指針を提供する責任がある。

スポンサーの位置づけではなく、戦略的な情報を広く提供し、組織の多くの人を取りこむ。

運営委員会は、通常、組織の人材から構成され、直接的なクライアントと間接的なステークホルダーとの組み合わせになる。

Templates are pre-existing forms that include standard text and spaces to fill-in-the-blanks with standard information.

Templates saves time since each person does not have to create the document format on their own.

Templates also allow information to be presented in standardized and recognizable formats for the reader.

テンプレートは、既に作成された様式であり、標準的なテキストやすでに標準的な情報が書きこまれ穴埋めができるようなものである。

テンプレートは、自分自身で始めから文書を作成する必要がないので、時間を節約できる。

テンプレートは、標準化され、読み手が認識できる様式で表現された情報の提供を可能にする。