-LINPRESS BLOG-


catch-img

PMBOKとは?プロジェクト管理の基礎を学ぼう


===
この記事ではプロジェクト管理技法として代表的な「PMBOK」をご紹介していきます。

プロジェクト管理の基礎を学べる1Day研修はこちら(https://www.linpress.co.jp/lp_pl/pl)
===


こんにちは。リンプレスの川上です。

プロジェクトを成功へと導くためには、プロジェクトを適切に管理していくことが重要です。

この記事ではプロジェクト管理技法として代表的な「PMBOK」をご紹介していきます。


目次[非表示]

  1. 1.プロジェクトマネジメントとは?
  2. 2.PMBOKとは 
  3. 3.PMIとは
  4. 4.PMPとは
  5. 5.PMBOKのメリット
  6. 6.PMBOK活用の注意点
  7. 7.PMBOKの計画プロセス
    1. 7.1.スコープ・マネジメント
      1. 7.1.1.不十分なスコープ・マネジメント
      2. 7.1.2.スコープ・マネジメントの計画
      3. 7.1.3.要求事項の収集
      4. 7.1.4.スコープの定義
      5. 7.1.5.WBSの作成
    2. 7.2.スケジュール・マネジメント
      1. 7.2.1.無理なスケジュールは立てない
      2. 7.2.2.スケジュール・マネジメントの計画
      3. 7.2.3.アクティビティの定義
      4. 7.2.4.アクティビティの順序設定
      5. 7.2.5.アクティビティの所要期間見積もり
      6. 7.2.6.スケジュールの作成
    3. 7.3.コスト・マネジメント
      1. 7.3.1.コスト見積りは難しい
      2. 7.3.2.コスト・マネジメントの計画
      3. 7.3.3.コストの見積り
      4. 7.3.4.予算の設定
    4. 7.4.品質マネジメント
      1. 7.4.1.品質のポイントは「上流工程で予防」する
      2. 7.4.2.品質マネジメントの計画
  8. 8.終わりに


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

システム構築におけるプロジェクトマネジメントとは、システム構築プロジェクトを計画された通りに遂行させることです。言い換えるとQCD(品質、コスト、納期)を計画通りに終わらせる事とも言えます。

つまり、プロジェクトマネジメントとはQCDを守ることです。

では、どのようにマネジメントをすればいいのでしょうか。


プロジェクトマネジメント技法として代表的なPMBOKがあります。

PMBOKをプロジェクト活動に適用すればプロジェクトマネジメントが可能となります。

PMBOKとは 

PMBOK(Project Management Body Of Knowledge)とは「プロジェクトマネジメントの知識体系」です。

プロジェクトマネジメントに必要なプロセスが定義されており、各プロセスには目的や概要、インプット、アウトプット、ツールと技法が体系的に定義されています。また、従来のQCD達成にとどまらず、管理項目などを含めた全体最適を目的としています。


PMBOKの歴史は古く、1987年にPMI(Project Management Institute:PM協会)から発表され、現在はPMBOKガイド第6版(2017年)となります。


PMIとは

PMBOKガイドの原文は英語で、日本語のほか多くの言語に翻訳されておりPMIが監修を行って発行されています。


現在では国際的標準マネジメント技法としてPMBOKが広く活用されています。
また、PMIはプロジェクトマネジメント・プロフェッショナル(PMP)の資格認定も行っており、プロジェクトマネジメントを広く普及させる活動もしています。


PMPとは

PMPとは、プロジェクトマネジメントの認定資格です。

試験ではPMBOKガイドに定められた用語が採用されており、概念やプロセスの目的・活動に関するインプット情報、ツール・技法、アウトプット情報が出題されます。


出題内容はPMBOKガイドのみではなく、マネジメントスキルやPMIの倫理規定も出題されます。

また、受験申請の条件もあり、プロジェクトマネジメントの学習実績とプロジェクトマネジメントの指導・監督の経験も必要となります。


PMP以外にも、CAPM(Certified Associate in Project Management)試験もあります。

CAPMはプロジェクトマネジメントの実務経験は不要です。プロジェクトメンバや経験の浅いプロジェクトマネジャー、学生を対象にしたもので、経験や知識の度合いをはかることを目的にしています。


PMBOKのメリット

現在のPMBOK(第6版)では10個の知識エリアと5つのプロセスで分類されています。知識エリアをマネジメントと読み替えてもいいでしょう。

5つのプロセスはプロジェクトの開始から終結までの流れ(立上げ、計画、実行、監視・コントロール終結)、

10個の知識エリアは統合、スコープ、スケジュールコスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダーとなっており、計49のプロセス(手順/処理)があります

PMBOKでは、プロジェクトの状況により実施するプロセスを選択することを推奨しています。小規模プロジェクトなどでは必要なプロセスを選択すればよいということです。これは該当プロジェクト用に仕立て直すという意味合いでテーラーリングとも言われています。

また、マネジメントとして何をやるべきか、何をやらないのか、漏れは無いかという観点でのチェックリストとして活用できます。


PMBOK活用の注意点

プロジェクトマネジメント技法として優れたPMBOKですが、プロジェクトを推進する「人」に関しては、あまり触れられていません。


プロジェクトを推進するのはPM(プロジェクトマネジャー)やPL(プロジェクトリーダー)です。推進する人にどのような能力(スキル)が必要なのかは触れられていないのです。


さらにプロジェクトメンバも人です。プロジェクトは人の集まりです。いかに思い通りに動かない人を思い通り動いてもらうか、これがプロジェクト推進の神髄と言っても過言ではありません。

経験豊富なPM/PLであれば、これまでの経験や人との関係でうまく推進できるでしょう。しかし経験の浅いPLはどうでしょう。

プロジェクトの中には様々な人がいます。年長者、声の大きい人、無口で何を考えているか分からない人、技術力が高い人などです。さらに視野を広げると利用部門や発注者など多くの人が関わります。


プロジェクトを成功させるためには、プロジェクトマネジメント技法の習得だけではなく、ヒューマンスキル(対人能力)も重要だということです。


PMBOKの計画プロセス

計画プロセスとは、その名の通りプロジェクトの計画を立てることです。
つまり、システム構築プロジェクトであれば、システム構築の実作業を行う前に実施しておくべきことです。

計画プロセスは全ての知識エリアにおいて計画を実施する必要があります。では、計画を行うとはどういうことでしょうか。



私たちは、限られた資源を最大限に活用し、利用者(ユーザー)が求めるシステムを、高い品質で、決められた期限までに作り上げることが求められています。無計画にプロジェクトを進めるのではなく、成功させるための計画を立ててプロジェクトを進めることが大切です。


スコープ・マネジメント

計画プロセスでの「スコープ」知識エリアでは、4つのプロセスが定義されています。

  • スコープ・マネジメントの計画
  • 要求事項の収集
  • スコープの定義
  • WBSの作成

スコープとは、要求事項の範囲と、成果物や作業の範囲のことです。
つまり、要求者(ユーザーや利用者、発注者)の要求事項をどの範囲まで対象とするのか。その要求事項をシステム化するために、どういう成果物が必要で、そのためにどういう作業が必要なのか、を明確にするということです。


不十分なスコープ・マネジメント


スコープが不明確・合意できていない状況では、多くの場合がトラブルもしくはそれに近い状況になっています。


例えば要求事項のスコープが合意されない状態でプロジェクトが進み、設計や製造のフェーズになって「この機能が足りない」、「この画面が無いと業務が回らない」といった追加要求が発生した場合、トラブルの元となります。

また、作成する成果物が不明確だった場合は、「この設計書が無いと製造ができない」ということで、新たな成果物を作成することになります。
計画していない要求事項や成果物を対象にするということは、計画したリソースでは対処できないということです。このような事象は私自身も経験がありますし、周りのプロジェクトでもよく見られる事象です。


スコープとは、プロジェクト活動の範囲です。この範囲が変動するということは、コストや納期を守れないことを意味します。

逆にコストと納期を守ろうとすれば品質を犠牲にすることになります。


つまり「QCD(品質、コスト、納期)を守れない=トラブルになる」とも言えるでしょう。
プロジェクト活動においてスコープとは、それほど重要なものだということをご理解下さい。


スコープ・マネジメントの計画


プロジェクト活動の範囲を定めるものであり、プロジェクト活動中に計画範囲を維持しているかどうかを判断する拠り所となります。

また、プロジェクト企画書やRFPに記述されたプロジェクトの範囲をより詳細化することを目的としています。


プロジェクト・スコープとして、システム開発のみか、それとも導入やシステム利用教育、データ移行も対象とするのか。

ここで大切なことは、「実施しないことは何か」を明確にするということです。要求者は「やってくれると思ってた」、受託者は「対象外のつもりだった」ということがあってはスコープが合意できたと言えません。そして、要求事項のスコープ(範囲)が変わったときにはどのような対応を行うのか、なども明確にします。


要求事項の収集


要求事項の収集は各社様々な方法を活用されていますが、代表的なものは要求者からのインタビュー(打合せ等)になるでしょう。その際に業務フローを活用したり、ユースケースを活用したりして、スコープの認識を合わせることが大切です。


スコープの定義


プロジェクト計画の中核業務であるスケジュール計画、資源計画、費用計画を設定するための基本情報となるものです。

  • プロジェクトのアウトプットとなる全ての成果物を明確にする
  • 成果物を作成するために必要な作業構造を概要レベルで構造的に把握する
  • 概要レベルの作業要素ごとに役割を決定する


WBSの作成


WBS(Work Breakdown Structure)はその名の通り、必要となる作業(Work)をトップダウン的に分析(Breakdown)し、階層構造(Structure)で表したものです。

プロジェクトに必要な全ての作業を洗い出し、抜け漏れが無いようにしなければなりません。「必要な全ての作業」ですから要求者の作業、受託者の作業の全てを洗い出すことが望ましいです。導入作業やデータ移行、システム利用教育などは忘れがちなので注意が必要です。

また、プロジェクトリーダーが実施するマネジメントに関する作業も洗い出すようにしましょう。このあとWBSをもとにスケジュールを計画します。マネジメント作業もWBSで明確にしておかないと、スケジュール化されなくなり、想定外の時間を費やすことになってしまいます。


スケジュール・マネジメント

計画プロセスでの「スケジュール」知識エリアは、5つのプロセスが定義されています。

  • スケジュール・マネジメントの計画
  • アクティビティの定義
  • アクティビティの順序設定
  • アクティビティの所要期間見積もり
  • スケジュールの作成

スケジュール・マネジメントは、スコープ・マネジメントで定めた要求事項範囲の成果物作成や作業をいつ・誰が、どれだけの時間を掛けて行うのかを具体的にします。


無理なスケジュールは立てない


担当者に作業を割り当てる際には、担当者の能力や生産性なども考慮する必要があります。経験の浅いメンバや能力が十分でないメンバに難しい作業を割り当てると見積もった工数・期間では完了できない場合が多いので以下の点に考慮が必要です。

-      経験の浅いメンバには所要時間を1.5~2倍にする

-      サポートメンバを付ける

-      難易度の高い機能要件や作業の場合は所要時間や期間の余裕を十分に持たせる

-      利用するDBや開発言語がメンバにとって未経験のものであれば、教育や学習時間の考慮をする

仮にメンバの1人が計画した期日通り完成できなかった場合、それは遅延となり そのメンバの後続作業も遅れます。他メンバの作業にも影響する可能性があります。当然のことながら後工程にも大きく影響する可能性が高くなります。

大切なことは、無理なスケジュールは立てない、出来るスケジュールを計画するということです。


スケジュール・マネジメントの計画


スケジュール・マネジメント計画書を作成します。計画書では以下の内容を明確にする必要があります。


スケジュールの計画・策定基準


以下の内容を参考に設定します。

  • 生産性基準

 精度の高い生産性基準を適用

  • 全体スケジュールの単位分画と単位ごとの計画・評価

 長期プロジェクトでは全行程の詳細スケジュールを計画するのは困難です。フェーズごとに詳細計画をたてる手法も有効(PPP:Phased Project Planning(段階的プロジェクト計画法)

  • 作業割り当てと責任の明確化

 工程や成果物に対して、承認者や実施者を明確にする(TRM:Task Responsibility Matrix) 

  • 日程計画の多段化

 大日程(月レベル)、中日程(週レベル)、小日程(日レベル)など粒度を分ける。これにより全体進捗を見るときは大日程で、詳細進捗は小日程で、という使い分けが可能

  • マイルストーンの明確化

 工程別の成果物完成時期やイベントなどを明確化


進捗管理の方法


  • 管理指標の明確化

 各工程の進捗状況を計る指標を明確にします(設計書完了数、プログラム完成数、テスト消化率、バグ発生数と解決数、など)

  • 期限管理と消化率管理

 予定・実績の定量的把握を行うための管理方法を取り決めます(50/50法や各社独自の進捗率定義など)


監視・コントロールプロセス実施の方針および手順


  • 進捗管理の徹底

 日々の進捗実績登録、短期サイクル(週単位など)での進捗ミーティング、進捗状況報告書作成(定量的・具体的な現状把握、遅延状況、問題発生状況など)を定めます

  • 遅延・問題発生時の迅速な対策・対応

 遅延や問題が顕在化したとき報告ルートや報告資料等を明確にするとともに、問題種類ごとの対応策方針を明確にします


アクティビティの定義

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

アクティビティの所要期間見積もり


WBSをブレークダウンした最下位レベルの成果物を生み出す作業項目をワークパッケージと呼び、ワークパッケージを完了するために必要な作業のことをアクティビティと呼ぶ。

ワークパッケージ毎に必要となるアクティビティの洗い出しを行い、アクティビティの実施順序を明確にするとともに、各アクティビティの所要時間の見積りを行う


スケジュールの作成


スコープ・マネジメントで作成したWBSと定義したアクティビティ(順序設定、所要期間見積り済み)により、プロジェクトとしてやる事が明確になりました。
これをスケジュール管理ツール(Excelやタスク管理製品など)で明文化します。アクティビティ毎に担当者の割り当てを行い、開始日・終了日も明確にする必要があります。


コスト・マネジメント

計画プロセスでの「コスト」知識エリアは、3つのプロセスが定義されています。

  • コスト・マネジメントの計画
  • コストの見積り
  • 予算の設定

コスト・マネジメントは、スコープ・マネジメントで定めたWBSおよびスケジュール・マネジメントで定めたアクティビティを実行するための費用を算出します。


コスト見積りは難しい


見積りを正確に行うことは困難です。例えばこれから要件定義を始めようとするタイミングで見積りを行った場合、プロジェクトが終了した時点での実績値と比較すると大きな乖離がでることが多くあります。

要件定義はシステムとしてどのようなシステム機能が必要となるのかを具現化する工程です。要件定義を行う中で「この機能が必要、こんな画面があれば業務効率が上がる」などの理由でシステム機能数は増減します。すなわち不確実な状態を見積もっているということです。


特に見積りを一人で行った場合、私の周辺ではこの傾向が多いように感じます。人によって感じ方受け止め方は様々です。一人の目線で見積りをすると見逃しや認識違いが発生するためだと思っています。
しかしながら、予算確保のためには見積りは必要不可欠です。出来る限り正確な見積りを行うためには以下に留意することをお勧めします。

  • 複数名が各々見積りを行い、全員で精査する
  • 過去の類似プロジェクトでの生産性などを活用する

コスト見積りは上流工程になればなるほど実態との乖離幅が広がる可能性があると言われています。この特性を表すのが「不確実性コーン」 です。

中央の実線が実際に掛かるコストとしたとき、要定義完了時点でコスト見積りを行うと0.67~1.5倍の範囲で誤差が発生する可能性があるというものです。詳細設計が完了した時点で0.9~1.1倍まで誤差は狭くなります。
つまり要件定義でシステムとして必要なシステム機能を洗い出せたとしても、基本設計や詳細設計でシステム機能を設計していく中でコスト見積りが変動する場合があるということです。


見積りを行うタイミングで見積りの正確性が変動することを認識しておいてください。


コスト・マネジメントの計画


コスト・マネジメントの計画書を作成します。
計画書には測定単位(人時、人日など)と監視のための閾値を定めます。
必要に応じて費用の追加・変動時の資金調達方法なども取り決めておきます。
また、為替変動への対応が必要であれば、変動時の対処なども定めておきます。


コストの見積り


アクティビティに必要な資源(人的資源、物的資源)のコストを算出します。
システム開発プロジェクトにおいては、多くの場合「工数」として人時、人日、人月などで算出します。
コストの算出には様々な見積り技法が存在しますが、各社各様で独自の技法を使用しています。
以下は代表的な見積り技法です。コスト見積りの際には見積りの根拠となる情報も残しておきます。


予算の設定


コスト見積りの結果をスケジュールに合わせて時系列に予算配分し、ステークホルダーの承認を得ます。


品質マネジメント

計画プロセスでの「品質」知識エリアは、1つのプロセスが定義されています。

  • 品質マネジメントの計画

品質目標を達成するための方針や手順、実施方法や資源などを計画書に記述します。


品質のポイントは「上流工程で予防」する


品質を向上させる手段として「レビュー」と「テスト」があります。
-    レビュー ・・・不具合の混入を予防する目的で実施する
-    テスト  ・・・不具合を検出する目的で実施する

テストをしっかり実施すれば品質が良くなるからテストに注力しよう。という考え方もありますが、私はレビューをしっかり実施して不具合の混入を防ぐ手段にも注力することをお勧めします。


下の図はテスト工程で発見した不具合が、設計工程で混入した「設計不良」だった場合の例です。
発見はテスト工程ですが、混入は設計工程です。この例では設計工程まで戻ってシステム設計を変更し、関連するプログラムを変更して、改めてテストを実施し直しています。

設計・製造・テストをやり直すということは、想定外のコストと時間を掛けることになります。下流工程で不具合を発見するということは、上流工程まで手戻りする可能性があるということです。

この「設計不良」を設計工程で発見できていればどうでしょう。

設計工程で発見できれば、工程を跨いだ手戻りはありません。不具合への対応は最低限のコストと時間で済みます。


下流工程で発見する不具合は手戻りによるロス(コストと時間)が大きくなります。いかに上流工程で不具合を発見するかが大切ということです。
つまり、要件定義や設計工程でしっかりとレビューを実施し、不具合を予防することで、プロジェクト資産であるコストと時間のロスを減らすことができると言えるでしょう。

テストも重要な品質向上の手段ですが、レビューとの組み合わせで更なる品質向上が見込めます。品質マネジメントの計画では、プロジェクトに応じて適切な予防(レビュー)と検出(テスト)の計画を立てる必要があります。


品質マネジメントの計画


品質マネジメントの計画書を作成します。
計画書には品質目標、対象とする成果物と実施プロセス、使用するツールなどを記述します。
つまり、どの様に品質確保するのか、どれぐらいのコスト(工数)を掛けるのかを検討します。

記述内容は以下を参考にして下さい。

記述内容
説明
使用する品質基準
自社の品質基準やシステム/ソフトウェア製品品質(JIS X 25010:2013)など、どのような品質基準を適用するのか検討する
品質目標
対象成果物毎に定量的な指標を定義する。レビュー指摘密度、テスト密度、バグ密度などを設定する
品質に関する役割と責任
レビューやテストなど品質保証活動の実施責任者や品質保証責任者などを定義する
対象となる成果物とプロセス
工程ごとの成果物に対して、品質保証活動の対象要否とプロセス(レビュー手法やテスト技法など)を定める
品質マネジメントの活動
成果物毎の品質評価指標を設定し品質合否の閾値を定め、品質管理のプロセスを検討する
品質ツール
品質管理を行うためのツールを検討する
基準不適合や是正処置への対処手順
品質保証活動(レビューやテストなど)で「品質が悪い」と判断した場合の改善方針などを定める



終わりに

PMBOKガイドでは概念やプロセスの目的・活動に関するインプット情報、ツール・技法、アウトプット情報が記述されており、文章を読むと難しく感じます。


しかし、実際のマネジメントと照らし合わせると、普段実施しているプロセスだったりします。あまり難しく考えず、PMBOKの利用経験者に話を聞くなどするとよいでしょう。


これからプロジェクトリーダーを目指す方は、まずはプロジェクト管理の基礎知識としてPMBOKを学ぶことをお勧めします。

そのうえでプロジェクト管理技法だけではなく、プロジェクトリーダーに必要なコミュニケーション力や決断・交渉力といった実践の場において必要な能力を強化していくことが重要です。


リンプレスでは約50年にわたるITプロジェクトの経験から生まれた、プロジェクト管理の基礎を学べる研修をご提供しています。
こちらもあわせてぜひご覧ください。

​​​​


===
リンプレスでは約50年にわたるITプロジェクトの経験から生まれた、プロジェクト管理の基礎を学べる研修をご提供しています。

プロジェクト管理の基礎を学べる1Day研修はこちら(https://www.linpress.co.jp/lp_pl/pl)
===

川上 淳一
川上 淳一

株式会社リンプレス イノベーション事業部 パフォーマー 主に金融業や製造業、製薬業、通販業、通信業など汎用機・C/S・Webのシステム構築に幅広く携わってきた。 多くのプロジェクトでプロジェクトリーダーやプロジェクトマネージャを経験し、2019年から現職に至る。 現在は要求分析・IT企画研修やプロジェクトリーダー研修を担当。

人気記事ランキング

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25