|
よく分かる「プロジェクト管理におけるDIKWモデル」
1. はじめに
PMBOK® 第5版でDIKW (Data, Information, Knowledge, Wisdom) モデルが導入されパフォーマンス情報が体系的に整理されました。しかし、そのモデルを実践で適用するための具体的事例が乏しいのが現状であると筆者は考えております。そこで当記事では、パフォーマンス情報をDIKWモデルに従って現場でどのように活用するのか、具体的事例とその勘所を下記のポイントで説明したいと思います。
| ・ |
PMBOK® におけるDIKWモデルを理解する。 |
| ・ |
パフォーマンスデータの特定とその収集方法を計画するためのポイントと勘所を理解する。 |
| ・ |
パフォーマンスデータを収集し、パフォーマンス情報として活用する際の留意点を理解する。 |
なお、本内容は、PMAJ® PM研究・研修部会で2015/1/30に開催された「プロジェクト管理におけるDIKWモデルの実践的適用方法 ～パフォーマンス情報の現場への活用方法及び、具体的事例とその勘所」というセミナーで発表した内容に基づいてその概要を整理したものです。
2. PMBOK® におけるDIKWとは？
DIKWモデルとはRussell L. Ackoff (1919-2009) さんが1980年頃に定義したモデルであり、Data (生データ)、Information (情報)、Knowledge (知識)、Wisdom (知恵)の4つの頭文字から命名されたモデルです。PMBOK® では、そのDIKWモデルを第5版 図3-5にて整理しております。(下図参照)
仮にプロジェクト実施上、重要な“進捗管理”を例に取れば、Dataは作業パフォーマンスデータ(＝進捗データ)、Informationは作業パフォーマンス情報(＝進捗情報)、Knowledge・Wisdomは作業パフォーマンス報告書(＝進捗報告書作成)及び報告となります。より具体的には、進捗データとは設計工程では外部設計を10頁完了した、テスト工程では2月10日に10件のテストを実施した等のそれだけでは何も判断できない素のデータを指します。また、進捗情報とは先の例で言えば外部設計が10頁完了したので進捗率が15%、テスト工程では2月10日に10件のテストを実施し進捗率50%等の情報を加工したものであり、それを報告書に作成する際に、計画と実績の差異を分析して進捗通りなのか遅延しているのか等、情報を第三者が理解しやすいよう報告書として整理し、報告するのが進捗報告となります。
3. プロジェクト管理におけるDIKWとは？
ここでは、前記2章と同様に進捗管理を例に取り説明したいと思います。進捗管理とDIKWの関連を示したものが下表となります。
DIKWモデルでは上表の通り、「1. Data ⇒ 2. Information ⇒ 3. Knowledge ⇒ 4. Wisdom」の順序性となります。それに対応するように進捗管理では「① ⇒ ③ ⇒ ⑤ ⇒ ⑦・⑨」となり、また進捗管理に内包される課題管理についても、「② ⇒ ④ ⇒ ⑥ ⇒ ⑧・⑩」となり対応関係が分かるかと思います。ここでは、進捗管理 (課題管理含む) にフォーカスしポイントを説明したいと思います。
ところで、進捗管理は何の為に行うのでしょうか？もちろんプロジェクトのQCD (品質、コスト、納期) を達成するため、言い換えればプロジェクトを成功するために行うものであることに異論はないかと思います。より具体的には上表⑨ ⑩の「部下・ベンダ等からの報告」を鵜呑みにせずに正しく状況を把握し、リスクや課題があれば早期に改善策を立案・実行する。それでQCDを遵守するということです。
よくプロジェクトを実施していると、「プロジェクト初期段階では順調に見える」にも関わらず、「プロジェクトの最終段階では完成する見込みが立たない(≒後の祭り状態)」になってしまった経験は無いでしょうか (下図参照)。この現象は一般的に“学生症候群”と呼ばれます。これは、学生はテストの際に直前にならないと勉強しない、最悪一夜漬けで挽回するという、いわゆる追い詰められないと本気になれない、ということを指しており、皆さんも同様の経験があるのではないでしょうか。この現象はまさしく仕事にも当てはまり、アクティビティの予定終了日間際になるかもしくはプロジェクトのカットオーバーが近づくまでは本気を出せず惰性で仕事をしてしまってプロジェクト終盤になってあたふたしてしまうということになってしまいます。
そのため、プロジェクト初期の段階から上図のようにならないため、上表⑨ ⑩の「部下・ベンダ等からの報告」を正しく把握することが極めて重要なポイントになります。筆者の経験上、正しく把握するために下記の勘所を意識して報告を把握するのが良いと考えます。
■ 進捗報告を正しく把握するための勘所
| ① |
スケジュール報告に関して |
| |
・ |
仮に進捗通りの場合、現在報告を受けている進捗率を鵜呑みにはせず、管理者自身が下図の現在の生産性から計画終了日までの傾きを試算し、現実的に間に合うのか等の確認をする。 |
| |
・ |
仮に進捗遅延の場合、原因・対策の記載有無を確認し、その原因・対策が妥当であるかの確認を行う。また、どのくらいで回復するかの見通しの記載有無の確認を行う。 |
| ② |
課題報告に関して |
| |
・ |
スケジュールに影響を与える課題があった場合、その課題内容・対策案・検討／対応状況等の記載有無を確認する。また、前週あがっていた課題が今週の報告でどのような状況であるか時系列での確認が重要である。 |
| |
・ |
プログラム(複数プロジェクトで1つシステム等)の場合、1つのプロジェクトの課題が他のプロジェクトへ影響を与える可能性は高い。その際、「課題発生時の他プロジェクトへの影響範囲及び対策の記載の有無」があるかの確認を行う。 |
■ 進捗データを読み解き進捗情報とする留意点
■ 表 1 報告を受けた(受領した)進捗データ
■ 表 2 進捗報告を元に上図の分析の実施結果 (丸付き番号は上図の番号と対応)
表 1 はテスト工程におけるタスクA及びBの進捗報告日時点のデータをプロットした表です。その表 1 のデータを元に上図の考え方に基づいて分析 (試算) した結果が表 2 となります。
ここで、Task Aの予想終了日(表 2 の④)は6月4日、Task Bは6月10日となっています。計画上はそれぞれ6月17日及び5月15日になっていることを考えると、報告日時点の1日当たりの平均テスト件数 (生産性：表 2 の②) と計画完了日までの残平均テスト件数 (表 2 の③) を比較した場合、Task Aは現実的に可能な範囲で作業できるのに対し (表 2 の① ： 現時点の生産数よりも低い率で作業が可能)、Task Bは現状の6.2倍程度の作業負荷がかかり計画終了日までにテストを完了させるようにすると、何らかの是正策が必要となります (例：計画終了日の見直しや、要員補充等の対応等)。以上のように現在の数値データを基に種々の分析をすることで、進捗報告を鵜呑みにはせず正しく把握することが可能となります。
4. 最後に
いかがでしたでしょうか、DIKWモデルとプロジェクト管理のうち進捗管理(課題管理含む)との関連を示しました。そして、プロジェクトを成功させるための進捗管理のポイントについて述べてまいりました。DIKWモデルの考え方が何故PMBOK® で採用されたのか、恐らくプロジェクト管理をやる上でのより思考を整理させ体系化させるのが狙いだと筆者は考えております。皆様には、この体系化された考え方を上記したとおり成功のための勘所も含めてご理解頂いて、それを実践頂ければと思います。当記事の考え方が1つでも多くのプロジェクトの成功に寄与する結果となれば幸いです。最後までお読み頂きましてありがとうございました。
参考書籍
| ・ |
プロジェクトマネジメント知識体系ガイド第5版 (PMBOK® Guide第5版) |
| ・ |
DIKWについて (  こちら をご覧ください。) |
以上
|
1973年生まれ。国立茨城大学工学部卒。
