■プロジェクトと定常業務

 

ビジネスは、『プロジェクト』と『定常業務』に大別できます。

両者は共に、人・予算・時間という制約条件の中で、計画・実行・コントロールされます。

 

しかし、両者には大きな違いが2つあります。

 

「有期性」と「独自性」です。

 

まず、「有期性」につきまして、

『プロジェクト』では、明確な開始と終了があります。

『定常業務』では、継続的に行われます。終わりがありません。

 

次に、「独自性」につきましては、

『プロジェクト』では、創造という語が端的に表現していると思いますが、今までに存在しなかったような製品やサービスを創出する作業と言えます。

『定常業務』では、規定の手順や指示に従って、繰り返し行われます。ルーチン・ワークと言えるでしょう。

 

プロジェクトには様々な制約条件が存在しますが、どのようなプロジェクトであっても共通した制約条件として、以下の3つがあります。

 

「スコープ」「タイム」「コスト」です。

 

「スコープ」とは、作業範囲を指します。

若しくは、対象範囲と理解することもできるでしょう。

 

「タイム」とは、文字どおり時間です。

プロジェクトでは必ず開始と終了の時期が設定されます。

その間の期間は大きな制約条件となります。

 

「コスト」とは、プロジェクトの目的達成のために許容される費用を指します。

 

したがって、「工期内に全てを完成できず、未完成部分が若干残ったが、皆で協力し、様々なことを学べたから、プロジェクトは成功だ。」という表現は適切ではありません。

これを言うならば、

「工期内に全てを完成できず、プロジェクトとしては失敗だが、皆の協力には感謝している。また、プロジェクトから様々な教訓を得たという別な成果があった。」と言うべきでしょう。

 

このように、プロジェクトに与えられる制約条件が満たされない時、プロジェクトは「失敗」と位置づけられるのです。

 

■プロジェクト・マネジメントとは

 

プロジェクト・マネジメントとは、プロジェクトに必要な知識やスキルを活用し、プロジェクトを成功させるための活動と言えます。

 

プロジェクトの成功は、目標達成だけではなく、制約条件を満足する必要があります。

 

制約条件の共通項は前記のとおりですが、これ以外にも各プロジェクトには様々な制約条件が存在します。

それらは、大抵の場合、相互に関連性を持っています。

しかも、それらは相反する制約条件となる場合が少なくありません。

つまり、シーソーになる制約条件と理解すれば分かり易いでしょう。

二つの制約条件があって、片方を優先すれば、残りの片方の制約条件が満足できない状態です。

これをトレードオフ課題と言います。

このトレードオフ課題を解決するためには、二つの制約条件を満足できる状態を、上手くバランスを取りながら探しだし、実行することが必要になります。

 

これが、プロジェクト・マネジメントの必要性と言えます。

 

プロジェクト・マネジメントの有無による違いを示す典型的な例があります。

 

それは旅行です。

 

マネジメントされたプロジェクトとしての「旅行」とそうでない「旅行」を想像してみて下さい。

 

前者は、出発定点から目的地までの予定がしっかり計画されていますが、後者は、目的地は決まっているものの、準備無く出かける行き当たりばったりです。

したがって、後者は、時間的なスケジュールが不明のため、目的地への到着時刻は運任せですし、所持金が不足する事態も発生する可能性があります。

 

まさか、実際のプロジェクトにおいて、前記の後者のような無計画さは決して許されませんね。

 

■PMBOKとは

 

PMBOKとはProject Body Of Knowledgeのことで、PMIProject Management Institute)が作り上げたプロジェクト・マネジメントの知識体系です。

PMIにはあらゆる分野の業界関係者が参加していらっしゃいます。

このため、PMBOKはデファクト・スタンダードとして広く認識されています。

 

多くの異分野の方々が参加されるプロジェクトでは、コミュニケーションが大変重要となります。

コミュニケーション・ミスによって、プロジェクトの失敗を招く場面が少なくないからです。

このため、「言語の統一」が不可欠となります。

これがPMBOKの大きな価値と言えるのです。

PMBOKでは、プロジェクト・マネジメントに必要な知識が網羅されており、しかも体系化されているからです。

 

■プロジェクト・マネージャーとは

 

プロジェクト・マネージャーは、「プロジェクトをマネジメントすることに責任を有する人」と定義されています。

しかし、これは組織によって大きく異なります。

 

プロジェクト・マネージャーの権限は、大きく3つに分類できます。

 

「プロジェクト型」「機能型」「マトリックス型」です。

 

「プロジェクト型」は、プロジェクト・マネージャーの権限は大変大きく、経営者に直接報告を行うようなケースを指します。

 

「機能型」は、前者とは逆に権限の範囲が極めて小さく、組織部門の配下におかれているようなケースが該当します。

 

「マトリックス型」では、前の二者を複合させたようなケースです。

 

プロジェクト・マネージャーは、プロジェクトにおける権限とその範囲について知ることは重要な事項と言えます。

 

プロジェクト・マネージャーは専門技術を有している必要はありません。

 

しかし、専門技術者を利用する術を知らなければなりません。

そのためには、専門技術の持つ意味を知る必要があります。

 

このため、PMBOKを基礎としながら、プロジェクトで必要となるスキルを随時追加して習得する姿勢が重要となるのです。

 

また、プロジェクト・マネージャーは、次の3点には注意が必要です。

 

「動揺の防止」「傲慢の戒め」「資質向上」です。

 

「動揺の防止」とは、プロジェクト関係者への動揺の伝播を防止する目的があります。

プロジェクト・マネージャーの同様なプロジェクトに参加している全要員に伝播し、プロジェクトの進捗に対して悪影響を及ぼすからです。

 

「傲慢の戒め」とは、プロジェクトの円滑な推進を阻害するからです。

プロジェクト・マネージャーの傲慢さは、情報管理を停滞させたり、或いは意思疎通の欠如を生み出すからです。

 

「資質向上」とは、マネジメントを行うためのコミュニケーションに必要となる程度の専門技術は習得しなければ意思決定が出来ないからです。


PMBOKの基本用語

 ○ステークホルダー:プロジェクトの実行・完了により利益に影響の出る人・組織

  ・プロジェクト・スポンサー(プロジェクト・オーナー)・・・財政的資源の提供者

  ・プロジェクト・マネージャー・・・プロジェクトのマネジメントに責任を持つ人

  ・プロジェクト・マネジメント・チーム・・・プロジェクトのマネジメントに関わる人

  ・プロジェクト・チーム・メンバー・・・プロジェクトの作業者

 ○要素成果物:測定可能な成果・サービス

 ○プロジェクト・マネジメント・プロセス:定義された44プロセス中の一連のアクティビティ

 ○プロジェクト・マネジメント・プロセス群:44プロセスは、作業位置により5つのプロジェクト・マネジメント群に分類されます。

  ・立ち上げプロセス群・・・プロジェクトの定義

  ・計画プロセス群・・・目標達成のための計画

  ・実行プロセス群・・・作業の実行

  ・監視・コントロールプロセス群・・・計画との差異識別監視と差異解消のマネジメント

  ・終結プロセス群・・・要素成果物引き渡し

 ○プロジェクトのフェーズライフサイクル:プロジェクトをコントロールし易くするため、プロジェクト・マネージャーはプロジェクトをいくつかのフェーズに分けます。

フェーズは、逐次実行可能な定義を行い、各フェーズに要素成果物を定義します。

フェーズの集合は、プロジェクト・ライフサイクルと言われます。

プロジェクト・ライフサイクルには、次のような共通特性があります。

  ・コスト・要員数は、プロジェクトの開始時に少なく、中間フェーズで最も多くなり、終了に向かって急激に減少します。

  ・プロジェクトの失敗リスクは、プロジェクトの開始時が最大で、終了に向かって低下します。

  ・ステークホルダーのプロジェクトに対する影響力は、プロジェクトの開始時が最大で、終了に向かって低下します。

 ○9つの知識エリア44プロセスは、マネジメントの対象によって9つの知識エリアに分類します。

  ・統合マネジメント・・・他の8つの知識エリアで定義されたプロセスを統合する

  ・スコープ・マネジメント・・・プロジェクト成功のための必要作業を過不足無く洗い出すためのプロセス定義

  ・タイム・マネジメント・・・期間内にプロジェクトを完了させるためのプロセス定義

  ・コスト・マネジメント・・・予算内にプロジェクトを完了させるためのプロセス定義

  ・品質マネジメント・・・確保すべき品質をマネジメントするためのプロセス定義

  ・人的資源マネジメント・・・プロジェクト・チームを組織化し、マネジメントするためのプロセス定義

  ・コミュニケーション・マネジメント・・・ステークホルダー等との円滑な意思疎通を図るためのプロセス定義

  ・リスク・マネジメント・・・リスクの認知・分析・対応策・監視・マネジメントのためのプロセス定義

  ・調達マネジメント・・・プロジェクトに必要な資機材やサービスの外部調達に関するプロセス定義

 

 ○段階的詳細化:プロジェクトの初期段階においては、大まかに定義し、プロジェクトの進行に伴って取得できる詳細情報に従って、詳細化を図る手法

(以上、Part

 

それではこれから9つの知識エリアを個別に眺めていきましょう。

 

まずは、「プロジェクト統合マネジメント」です。

この点から始まるのがPMですし、PMBOKだなぁ。。。と感じますね。

青本も同様の作りなのですが、第1章のネーミングが悪いのと、十分内容がこなれていないと感じてしまいます。

 

■プロジェクト統合マネジメント

7つのプロセスの説明

 ・立ち上げプロセス群・・・プロジェクト憲章作成、プロジェクト・スコープ記述書暫定版作成

 ・計画プロセス群・・・プロジェクト・マネジメント計画書作成

 ・実行プロセス群・・・プロジェクト実行の指揮・マネジメント

 ・監視コントロール・プロセス群・・・プロジェクト作業の監視コントロール、統合変更管理

 ・終結プロセス群・・・プロジェクト終結

 

 §プロジェクト憲章作成・・・プロジェクト案を精査・選定し、内容をプロジェクト憲章としてまとめ、プロジェクトを正式に決定することが目的です。

  また、プロジェクト選定においては、代替案の選択が含まれます。

  ・顧客、スポンサー、ステークホルダー等の要求事項

  ・プロジェクトの概要、目的

  ・プロジェクトの要素成果物

  ・制約条件と前提条件

  ・プロジェクト・マネージャーの決定、任命、権限レベル

  ・ステークホルダーの関与

  ・スケジュールと予算の要約

  上記から分かるとおり、このプロセスはプロジェクト・マネージャーの作業ではありません。

 

§プロジェクト・スコープ記述書暫定版作成・・・スポンサー等から提供される情報を基に、作成され、これをスコープ定義プロセスにてプロジェクト・マネジメント・チームが詳細化して作成します。

 

 §プロジェクト・マネジメント計画書作成・・・プロジェクトの開始から完了までの必要な作業・手順・レベル・手段をまとめます。

  他の8つの知識エリアで作成する各計画書を収集し、文書化する作業を指します。

 

 §プロジェクト実行の指揮・マネジメント・・・要素成果物作成活動をプロジェクト・マネージャーとプロジェクト・マネジメント・チームが指揮・マネジメントします。

  メンバーの配置・トレーニング、納入者の選定、資機材の調達や、プロジェクトの進行に伴う変更要求などが活動対象となります。

  プロジェクト・マネージャーの作業量は、プロジェクトの実現度に依存します。実現可能性が高ければ、プロジェクトは計画どおりに進みますが、実現可能性が低くければ、計画の変更やトラブル対応などで作業量は増大が避けられません。

 

 §プロジェクト作業の監視コントロール・・・立ち上げ・計画・実行・終結のプロジェクトに関する各プロセスを監視し、必要措置を講じます。

  計画書と実績の比較やリスク分析を行うための情報提供を行います。

 

 §統合変更管理・・・開始から終了までに発生する変更のマネジメントを行います。

  プロジェクトで発生する変更には以下の4種類があります。

  ・変更要求・・・スコープの拡大・縮小、方針、プロセス、計画、手順、コスト及び予算等の修正やスケジュールの改訂

  ・是正措置・・・プロジェクト・マネジメント計画書と実績の差異解消

  ・予防措置・・・リスク低減措置

  ・欠陥修正・・・品質検査や監視プロセスで発見された欠陥修正

  上記の各変更は、対応状況によりステータスが、「提案済み」「要求済み」「承認済み」「却下済み」「実施済み」と遷移します。

 


 

 

テキスト ボックス: 計画・実行・監視コントロールの各プロセス
変更対応フロー
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 §プロジェクト終結・・・プロセス作業を終了し、プロジェクト・フェーズを正式に終了させます。

  ・契約終結

 

○プロジェクト6つの発生理由

 ・市場要求

 ・ビジネス・ニーズ

 ・顧客要求

 ・技術の進歩

 ・法的要求

 ・社会的ニーズ

 

(以上、Part2

 

■プロジェクト・スコープ・マネジメント

○概要

 ・プロジェクトの目的・目標確認後、最初にする作業

 ・スコープ・・・成果物スコープ(機能・特性),プロジェクト・スコープ(成果物作成のための作業)

5つのプロセスの説明

 ・スコープ計画

 ・スコープ定義

 ・WBS作成

 ・スコープ検証

 ・スコープ・コントロール

   プロジェクト・スコープ・マネジメント

プロセス群

プロセス

計画プロセス群

スコープ計画、スコープ定義、WBS作成

監視コントロール・プロセス群

スコープ検証、スコープ・コントロール

 

 §スコープ計画・・・プロジェクト・スコープの定義とマネジメントのための手順決定

          検討項目の洗い出し

 §スコープ定義・・・プロジェクト・スコープ記述書へのとりまとめ

          ªプロジェクトの目

          ªプロジェクトの要素成果物

          ª成果物受入基準

          ª作業範囲

          ª作業一覧

          ªスコープ外事項

          ª制約条件

          ª前提条件

          ª想定リスク

          ª概算予算

          ªプロジェクト組織

          ª要約スケジュール

 §WBS作成・・・要素成果物作成のためのプロジェクト作業の階層的要素分解

        WBS辞書の作成

 §スコープ検証・・・要素成果物検査、作業完了と要素成果物の公式な承認

 §スコープ・コントロール・・・承認済み変更内容に基づき、プロジェクト・スコープ記述書、WBSWBS辞書、スコープ・ベースライン、プロジェクトマネジメント計画書のコントロールとスケジュールやコストの変更要求。

 §制約条件と前提条件

   ª制約条件・・・プロジェクト作業の制限事項

   ª前提条件・・・確証は無いが確実と考えた事項

 ※スコープ外事項は重要

(以上、Part3

 

■プロジェクト・タイム・マネジメント

○概要

 ・スケジュール内での完了が成否判断指標

6つのプロセスの説明

 ・アクティビティ定義

 ・アクティビティ順序設定

 ・アクティビティ資源見積り

 ・アクティビティ所用期間見積り

 ・スケジュール作成

 ・スケジュール・コントロール

   プロジェクト・タイム・マネジメント

プロセス群

プロセス

計画プロセス群

アクティビティ定義、アクティビティ順序設定、アクティビティ資源見積り、アクティビティ所用期間見積り、スケジュール作成

監視コントロール・プロセス群

スケジュール・コントロール

 

 §アクティビティ定義・・・スケジュール・アクティビティの定義

             WBS最下層の要素成果物≫(分解)≫スケジュール・アクティビティ

             ≫アクティビティ・リスト&アクティビティ属性

 §アクティビティ順序設定・・・アクティビティ間の論理的順序関係の設定

               アクティビティ・リスト&アクティビティ属性

≫プレシデント・ダイアグラム法(PDM)、アロー・ダイアグラム法(ADM

≫プロジェクト・スケジュール・ネットワーク図

 §アクティビティ資源見積り・・・資源・いつ・量の見積り

 §アクティビティ所用期間見積り・・・作業期間の決定

   ªコンティンジェンシー予備・・・追加時間

                  プロジェクトの進行に伴い、低減or削減

 §スケジュール作成・・・進捗確認のベースライン

            継続的改訂

            クリティカル・パス法≫前提条件・制約条件の満足

                      ≫資源使用可能度チェック(≦100%

 §スケジュール・コントロール・・・承認済み変更要求に基づくスケジュールの変更マネジメント

                 パフォーマンス測定、差異分析

 §リードとラグ

   ªリード・・・先行アクティビティ終了前に後続アクティビティを開始できる場合のギャップ時間

                         

 

   ªラグ・・・先行アクティビティ終了後に後続アクティビティの開始までに生じる空き時間

 

 


 §所要期間の見積り法

   ▼類推見積り・・・過去の類似アクティビティを参考とする。

   ▼係数見積り・・・基準値÷投入資源量(単位期間当たり)

            基準値=作業量×生産性

            投入資源量(単位期間当たり)=総資源量×作業時間(単位期間当たり)

   ▼三点見積り・・・重みつけ平均

           最頻値(通常の見積り)、楽観値(最良シナリオの見積り)、悲観値(最悪シナリオの見積り)の重みつけ平均により算出

 §クリティカル・パス法・・・プロジェクト・スケジュール・ネットワーク図に基づく、アクティビティの論理的な最早開始日・最早終了日、最遅開始日・最遅終了日を算出します。

   ▼フロート・・・最遅終了日−最早終了日=最遅開始日−最早開始日

   ▼クリティカル・パス・・・各フロート=0の径路

     ↓プロジェクト全体の所要時間把握

     ↓作業遅延に基づくプロジェクトへの影響確認

     ↓所要期間短縮のための検討アクティビティの発見

     ↓アクティビティの開始時期・余裕の把握

 §資源平準化・・・要員に対する作業負荷の平準化

         資源平準化に伴い、完了期限は延伸することが多い点に留意が必要です。

 §所用期間の短縮・・・プロジェクト・スコープを変更することなく、プロジェクト・スケジュールを短縮する方法

  ▼クラッシング・・・クリティカル・パス上のアクティビティに追加資源を投入する。

           ※クラッシングを行うことにより、クルティカル・パスが変更になる可能性があるため、クラッシング後に再度クリティカル・パスを算出しなければなりません。

  ▼ファスト・トラッキング・・・順番に行うべきアクティビティを並行して行うこと。

                ※机上仮説と実際では効果が大きく異なる場合がありますから、無理のない範囲で行うことが必要です。

(以上、Part4

 

■プロジェクト・コスト・マネジメント

○概要

 ・プロジェクトの進捗に伴って生じる、立ち上げ時予算・時間との差異分析と完了予測を行います。

 ・差異分析の結果、必要に応じた対応を図ることになります。

 

3つのプロセスの説明

 ・コスト見積り

コストの予算化

コスト・コントロール

   プロジェクト・コスト・マネジメント

プロセス群

プロセス

計画プロセス群

コスト見積り、コストの予算化

監視コントロール・プロセス群

コスト・コントロール

 

 §コスト見積り・・・各アクティビティ完了に必要な資源コストの算出

   ・プロジェクト環境、過去の経験を参考としながら、リスクを考慮した見積りを行います。

   ・コスト見積りは、継続的な見直しが必要です。

   ・コスト見積りの蔡には、想定外の事象に対処するためコンティンジェンシー予備と言われる予備費の計上が一般的です。

 

 §コストの予算化・・・プロジェクトのパフォーマンス測定に必要なコスト・ベースラインを設定します。

   ・要素成果物・期間毎にコストを集約します。

   ・コスト・ベースラインは、必要コストの時系列展開です。

   ・横軸:時間、縦軸:累積コストのグラフでは、コスト・ベースラインは通常S字カーブとなります。

 

 §コスト・コントロール・・・統合変更管理プロセスからの承認済み変更要求に基づき、コスト・ベースラインの変更をマネジメントします。

   ・アーンド・バリュー法によりパフォーマンス分析を行い、コスト・スケジュールの差異把握やプロジェクト完了時の総予算予測を行います。

   ・前記に基づき、是正措置提案や変更要求を行います。

   ・承認済み変更要求に応じてコスト・ベースラインを変更します。

 

 §コストの見積り法

   ▼類推見積り・・・過去の類似プロジェクトのコストを参考に見積る方法

   ▼ボトムアップ見積り・・・詳細レベルのアクティビティ・コストを見積り集計する方法

   ▼係数見積り・・・過去の実績データとそれに影響を及ぼす変数との関係を統計処理し、定義したコスト見積り算出式に基づき見積る方法

 

 §アーンド・バリュー法

   ・プロジェクト・スケジュール、コスト・ベースライン、測定時の作業進捗状況に基づく方法です。

   ・測定時のコスト差異、スケジュール差異、完成時の総コスト見積りなどを算出します。

   ・実績測定に利用される方法です。

 

(以上、Part5

 

■プロジェクト・品質マネジメント

 

○概要

 ・「品質は計画により達成される」ものであり、検査によるものではありません。

 ・プロジェクト自体とプロジェクト成果物のマネジメントを目的としています。

 

3つのプロセスの説明

 ・品質計画

 ・品質保証

 ・品質管理

   プロジェクト・品質マネジメント

プロセス群

プロセス

計画プロセス群

品質計画

実行プロセス群

品質保証

監視コントロール・プロセス群

品質管理

 

 §品質計画・・・品質管理の対象・基準が何で、どのように実現するか。

   ・品質基準を満足するための作業手順、品質尺度を、各種分析手法により品質マネジメント計画として整理します。

   ・プロジェクトの実行フェーズに対する品質チェックリストを準備します。

 

 §品質保証・・・品質マネジメントが計画どおり実行されているか確認すると同時に、改善に役立てます。

   ・第三者による品質監査

   ・非効率プロセス・手順の調査

 

 §品質管理・・・品質マネジメント計画に基づく品質確保の監視と不適合の場合の原因と改善方法の特定を行います。

   ・プロジェクトの全プロセスで継続的に行います。

   ・「QC7つ道具」を利用します。

 

 §顧客満足

   ・要求事項への適合・・・規定品質の確保

   ・使用適合性・・・真の顧客ニーズの満足度

 

 ◇検査よりも予防

   ・品質低下の有無を検査により明らかにするのではありません。

   ・品質低下が発生しないよう予防することに力点を置くべきです。

 

 ◇QC7つ道具

   ・特性要因図・・・問題点に影響を及ぼす要員を整理・図示したもの。問題点の本質を検討するために用いられます。

 

   ・管理図・・・観測値の時系列変動と許容限度に対する確認を行います。

 

   ・フローチャート化・・・問題点の予測・解析

 

   ・ヒストグラム・・・棒グラフで示し、分布の形と幅から原因を識別します。

 

   ・パレート図・・・問題原因の発生頻度の多い順に並べた図で、原因の絞り込みに用いられます。

     ◇少数原因(20%)が、大部分(80%)の問題に起因するというパレートの法則を利用した管理方法です。

 

   ・ラン・チャート・・・データ発生順に折れ線グラフで示し、時系列における傾向・変動を分析します。

 

   ・散布図・・・2項目間の相関性を判断します。

     ◇正の相関・・・右肩上がりの傾向

     ◇負の相関・・・右肩下がりの傾向

     ◇相関なし・・・バラツキが大きい

 

 

   ※「QC7つ道具」についてはWEBにも種々詳しいサイトがあります。ここでは次のサイトをご紹介させて頂きます。

     「品質改善.comhttp://www.hinkai.com/

 

 ◇過剰品質

   ・要素成果物は、要求品質事項を最低限満足する必要があります。

   ・過度に高い品質追求は控えるべきです。

   ・過剰品質は、プロジェクトの制約条件(時間・コスト)に大きな影響を与えることになります。

 

(以上、Part6

 

■プロジェクト・人的資源マネジメント

 

○概要

 ・プロジェクト・チーム・メンバーは、適切なタイミングで適切な能力・スキル及び経験を有する人材が必要となります。

 ・個人・チームが、最大のパフォーマンスを発揮できるよう、表彰・報奨制度や非公式コミュニケーション及びチーム育成が求められます。

 

4つのプロセスの説明

 ・人的資源計画

 ・プロジェクト・チーム編成

 ・プロジェクト・チーム育成

 ・プロジェクト・チーム・マネジメント

   プロジェクト・人的資源マネジメント

プロセス群

プロセス

計画プロセス群

人的資源計画

実行プロセス群

プロジェクト・チーム編成、プロジェクト・チーム育成

監視コントロール・プロセス群

プロジェクト・チーム・マネジメント

 

 §人的資源計画・・・要員マネジメント計画と役割・責任、報告関係を決定します。

  ・要員マネジメント計画:プロジェクト・チーム・メンバーの調達方法、調達時期、離任時期、表彰・報奨制度などを規定します。

  ・役割・責任の記述方法:以下の3種類があります。

   □階層型チャート:通常組織図と言われる記述方法

マトリックス型チャート:責任分担マトリックス(RAMhttp://www.atmarkit.co.jp/aig/04biz/ram.htmlに代表される記述方法

   □テキスト形式:役割単位での記述方法

 

 §プロジェクト・チーム編成・・・人的資源の選出と任命を行います。

  ・要員の選出には以下の5つ検討項目があります。

   □参加可能時期

   □保有能力・スキル

   □類似作業の成功体験

   □プロジェクトに対する興味

   □要員確保コスト

 

 §プロジェクト・チーム育成・・・能力強化と交流促進によりプロジェクトのパフォーマンス向上を図ります。

  ・人間関係スキルの向上が重要と言えます。

 

 §プロジェクト・チーム・マネジメント・・・パフォーマンス追跡・フィードバック・課題解決支援を行います。

  ・プロジェクト全体のパフォーマンス向上が目的です。

  ・プロジェクト・チーム・メンバーの体調・精神状態などの問題把握とその対処

  ・要員同士の摩擦解消

 

 ◇チーム育成段階・・・4段階における動乱期間を短縮し、素早く遂行期の入ることが、マネージャーのあるべき姿です。

  ・成立期:メンバー招集段階で、意思の疎通は図れていません。

  ・動乱期:縄張り争いや対立が激化する時期です。

  ・安定期:共同の精神が萌芽する時期です。

  ・遂行期:メンバー相互の尊重と共通の問題意識によりプロジェクトを前向きに捉える時期です。

 

 ◇バーチャル・チーム・・・メンバー相互がほとんど顔を合わさないチーム形態です。

  ・メンバー間の連絡:電子メール、ビデオ会議など

  ・コスト低減:作業場所の確保不要、移動・出張費用の低減

  ・プロジェクト・リスク:人間関係の構築が困難

 

ここでは概念だけでした。

あくまでも今は、PMBOKの基礎知識を習得している段階ですから、この程度でOKですね。

これから段階的詳細化していけば良い訳ですから。

 

(以上、Part7

 

■プロジェクト・コミュニケーション・マネジメント

 

○概要

 ・プロジェクト・マネージャーは、8090%の時間をコミュニケーションに費やしている。

 ・ステークホルダーとのコンセンサス形成が何より重要です。

 ・5W2Hに基づく情報の収集・配布の鍵を握るのが、コミュニケーション・マネジメントです。

 

4つのプロセスの説明

 ・コミュニケーション計画

 ・情報配布

 ・実績報告

 ・ステークホルダー・マネジメント

   プロジェクト・コミュニケーション・マネジメント

プロセス群

プロセス

計画プロセス群

コミュニケーション計画

実行プロセス群

情報配布

監視コントロール・プロセス群

実績報告、ステークホルダー・マネジメント

 

 §コミュニケーション計画・・・ステークホルダーに対する情報と伝達方法の明示をします。

  ・5W2Hが重要です。

  ・計画が不十分だと漏れや間違いが発生し、情報錯乱状態に陥りますから、注意が必要です。

 

 §情報配布・・・コミュニケーション計画で定めた内容にしたがい、適切な時期に情報を配布します。

 ・情報手段に拘わらず、発信者は明確・完全な情報提供に心がけ、受信者が確実・正確に理解できるよう配慮することが重要です。

 

 §実績報告・・・プロジェクトの進捗状況とパフォーマンス情報をステークホルダーへ実績報告書としてまとめます。

  ・分析に当たっては、アーンド・バリュー法を用います。

  ・是正措置や変更の必要性に気づいた場合は、統合変更管理プロセスにて対応します。

 

 §ステークホルダー・マネジメント・・・ステークホルダーとコミュニケーションを通じて課題解決を図ります。

  ・プロジェクトの進捗について、ステークホルダーとの認識差を是正すると共に、最善策を検討します。

 

(以上、Part8

 

■プロジェクト・リスク・マネジメント

 

○概要

 ・プロジェクト目標に対するリスクを事前に抽出し、その原因や影響を調査します。

 ・プロジェクトにおけるリスクは、天災や事故のような不可避なものばかりでなく、組織活動に起因するリスクがあります。

 ・すべてのリスクが悪影響をもたらす訳ではなく、プロジェクトにとって好機となるリスクもあります。

 

6つのプロセスの説明

 ・リスク・マネジメント計画

 ・リスク識別

 ・定性的リスク分析

 ・定量的リスク分析

 ・リスク対応計画

 ・リスクの監視コントロール

   プロジェクト・リスク・マネジメント

プロセス群

プロセス

計画プロセス群

リスク・マネジメント計画、リスク識別、定性的リスク分析、定量的リスク分析、リスク対応計画

監視コントロール・プロセス群

リスクの監視コントロール

 

 §リスク・マネジメント計画・・・プロジェクトで発生するリスクに対する対応計画を行います。

  ・リスクの識別・分析・対応計画・監視の方法について定義を行います。

  ・リスク・マネジメントを行うための役割と責任の明確化を行います。

  ・リスクの発生確率と影響度の定義を行います。

 

 §リスク識別・・・内外要因に基づくリスクをまとめ、根本原因の追及・分類を行い、リスク登録簿を作成します。

・リスク識別は、継続して行わなければなりません。

  ・プロジェクトの進捗に伴って、新たなリスクの発生が生じる場合があるからです。

  ・リスクは、ライフサイクルに合わせた見直しが不可欠です。

 

 §定性的リスク分析・・・リスク対応の優先順位を決定し、リスク登録簿へ追記します。

  ・リスクの発生順に対応したのでは非効率となります。

  ・リスク登録簿等を基にリスク査定を行います。

  ・リスク査定は、リスクの発生確率と影響度を基に優先順位を決定します。

  ・WBSやプロジェクト・フェーズによる分類や即対応の要否をリスク登録簿へ記載します。

 

 §定量的リスク分析・・・リスクのコストやスケジュールに及ぼす影響や目標達成確率を算出します。

  ・感度分析、デシジョン・ツリー分析、モデル化とシミュレーション等の技法を利用します。

  ・結果をリスク登録簿へ追記します。

 

 §リスク対応計画・・・優先順位に従い、リスク対応戦略の検討・選択・処置を行います。

  ・リスク処理方法について代替案を列挙します。

  ・リスク低減レベルを検討します。HSISEHow safe is safe enough?

  ・リスク特性の把握とプロジェクトに対する致命的リスクの回避が求められます。

 

 §リスクの監視コントロール・・・内外環境変化に起因する新たなリスク発生の監視を行います。

  ・既存リスクの再分析

  ・残存リスクの監視

  ・リスク対応策効果の評価

  ・新たなリスクの識別・分析・対応計画策定

  ・リスク登録簿に基づき監視し、定期的なリスク再査定を行います。

  ・承認済み変更要求よる新たなリスク発生や既存リスクの変更発生を検討します。

 

◇マイナス(脅威)・リスクの対応戦略・・・「回避」「転嫁」「軽減」「受容」

  ・回避:リスクの影響を避けます。

  ・転嫁:マイナス影響を第三者に移転します。

  ・軽減:リスクの発生確率及び影響度を受容できるレベルまで低減します。

  ・受容:リスクの軽減や回避をせず、リスク影響を受け入れます。

 

◇プラス(好機)・リスクの対応戦略・・・「活用」「共有」「強化」「受容」

  ・活用:好機を確実にする対応を図ります。

  ・共有:好機を得やすい人と共同します。

  ・強化:確率やプラス影響を増加させ、好機規模を修正します。

  ・受容:リスクの軽減や回避をせず、受け入れます。

 

◇二次リスク・・・対応戦略を行った結果として発生するリスクを指します。

 

(以上、Part9

 

■プロジェクト・調達マネジメント

 

○概要

 ・プロジェクト外部からのプロダクト、サービスの購入手順、方法を規定します。

 

6つのプロセスの説明

 ・購入・取得計画

 ・契約計画

 ・納入者回答依頼

 ・納入者選定

 ・契約管理

 ・契約終結

   プロジェクト・調達マネジメント

プロセス群

プロセス

計画プロセス群

購入・取得計画、契約計画

実行プロセス群

納入者回答依頼、納入者選定

監視コントロール・プロセス群

契約管理

終結プロセス群

契約終結

 

 §購入・取得計画・・・プロジェクト外部からプロダクト・サービスを購入・取得する場合の方針を決定します。

  ・要素成果物の全部もしくはその一部を外部から取得する必要があるかどうかを判定します。

  ・外部調達の判定に当たって重要なことは、内部調達のメリットとデメリットを明確にすることです。

  ・外部取得の必要性がある場合は、いつまでに、どの部分を、どのような契約によって取得すべきかを検討します。

  ・外部調達では、プロジェクト内部に保有しない知識やノウハウが必要な場合です。

  ・前記の場合であっても、内部調達とする場合は、知識やノウハウを内部に蓄積する必要がある場合です。

 

 §契約計画・・・納入候補者への調達文書と納入者選定のための評価基準を作成します。

  ・調達文書、評価基準は、調達マネジメント計画、契約作業範囲記述書、プロジェクト・スケジュール、コスト・ベースラインなどを基に作成します。

  ・調達文書とは、入札招請書、提案依頼書(RFP)、見積依頼書などが該当します。

  ・評価基準は、受領した提案書を評価・採点するためのものです。

  ・要素成果物の品質が同じであれば、評価基準は価格が支配します。

  ・複雑な手順、高度な技術、長い期間を要する要素成果物の場合は、手順のマネジメント力、必要な技術力、財務力がそれぞれ評価基準になることがあります。

 

 §納入者回答依頼・・・調達文書を納入候補者へ配布し、回答を受理します。

  ・調達文書配布先の候補者リスト作成が重要なポイントです。

  ・調達内容の理解を深めるため、入札説明会を開きます。

  ・納入候補者を対等に扱うことが重要な要素です。

 

 §納入者選定・・・納入候補者からの回答を受理し、評価基準にしたがって評価選定を行います。

  ・先入観を排除し、客観性を確保することが重要です。

  ・評価基準に対する「重みつけ」を行うのが一つの方法です。

  ・「重みつけ×評価点」で各評価項目を算定し、合計点で納入者を決定する方法です。

 

 §契約管理・・・納入者が、契約に従った活動をしていることを確認します。

  ・進捗状況の評価及び検査・監視により確認します。

 

 §契約終結・・・契約全作業と要素成果物の受入れが可能かを検証し、契約を完了します。

  ・取得計画から契約管理までのプロセスにおける調達作業のレビューを行います。

  ・プロジェクトにおけるレビューは、プロダクトレビューとプロセスレビューに大別することができます。

・プロダクトレビューとは成果物レビューとも呼ばれ、成果物が仕様通りに作られているか、又、その品質は十分であるかを確認する目的で開催されるレビューを指します。

・納品前に実施されるレビューは、プロダクトレビューの一部です。

・納品前だけでなく、プロジェクトが進行する過程で、定期的にプロダクトレビューを実施することにより、高品質の成果物を、大きな手戻りなく作成することが可能になります。

 

 ◇契約タイプ

  ・定額契約または一括請負契約:請負金額を予め定める契約方式です。

   要素成果物が取得できた段階で、請負金額を支払いします。

   購入者は、費用変動リスクを納入者に転嫁できます。

   一般的に請負金額は上昇する傾向となります。

   変更が発生しない場合に用いられる契約方式です。

  ・実費償還契約:成果物取得費用と納入者利益を加えた金額の支払い契約です。

   契約時に総額が不明というリスクを購入者は負います。

   要素成果物が変更になる可能性が高い場合用いられる契約方式です。

   納入者にコスト意識が生まれにくく、非効率となる可能性があります。

  ・タイム・アンド・マテリアル契約:定額契約と実費償還契約の中間的な契約方式です。

   単位時間あたりのレート×作業時間=費用で契約します。

   資源レートを事前に決定する点は、定額契約の概念です。

   契約時に総額が不明という点は、実費償還契約の概念です。

 

(以上、Part10