「変革の時代の組織リテラシー」第1講：そもそもプロジェクト・マネジメントとはなにか？
第1講では「そもそもプロジェクト・マネジメントとはなにか？」についてお話しします。
導入講で述べた「PM2.0からPM3.0へ」を考える前提として、プロジェクト・マネジメントの源流とPM2.0の骨格的方法論について理解し、その有効性と限界を理解いただくことを目指しています。
プロジェクト・マネジメントを学ぶ際、学術的な理論と現場でどうプロジェクトを回すかという実践方法がそれぞれ別に語られており、それらをつなげたものがないと感じてきたため、この講義では理論と実践方法をつないで語ることを意識しました。
2月22日に導入講をアップロードしてから、多くの方々からアクセスやコメントを頂き、私達と同じような問題意識や悩みを持っている方が沢山おられるのだと再認識しました。noteとして公開することは緊張と労力を伴いますが、反面大変楽しいことでもあり、アスリートの方々の「ゲームを楽しみたい」という発言が少し理解できた思いです。今回は、前回の倍くらいの文量ですが、最後までお付き合い頂ければ幸いです。
このnoteは、多摩大学大学院の講義で使用してきた教材を下敷きに、その大幅改定のためのドラフトを、クリエイティブコモンズ［©中分毅 (Licensed under CC BY-NC-ND 4.0)］として公開するものです。
この記事の最後に、教材詳細版のPDFダウンロードリンクを載せていますので、ご関心ある方はぜひご活用ください。
では講義に入りましょう。
はじめに-第1講の構成
私達は、正統派プロジェクト・マネジメントPM2.0の欠落点を補い、PM3.0を目指している訳ですが、その為にはPM2.0の骨格をなす方法論を、その源流に遡り、どの様な問題意識の下にその方法論が編み出されたのか、を理解しておくことが重要です。
正統派プロジェクト・マネジメントPM2.0の根幹は
「分割して統合せよ」と表すことができます。
これは、正統派プロジェクト・マネジメントの源流が、
・規模が大きい
・前例がない
・構成要素が膨大で要素間に相互関係がある
・設定されたスケジュール目標が極めて意欲的（タイト）
といった特徴を持つ、国家レベルの建設プロジェクトや宇宙・軍事開発であることの当然の帰結と言えるでしょう。
この様な特徴への対応として、プロジェクト・マネジメントの個別手法の開発や体系化がなされてきました。その骨格を構成するのはスライドに青字で示した4つの手法です。
これらを批判的に（否定的ではありません）検討する本講の構成は、以下の通りです。
1. 4手法を用いたPM2.0の骨格的な流れの要点を説明
2. 4手法の源流を紹介
3. 簡単化された新治療法導入プロジェクトを事例に、各手法がどの様に適用されるかを説明
4. 現在も広く活用されている手法について詳しく説明①PERT
5. 現在も広く活用されている手法について詳しく説明②WBS
6. 4手法の持つ基本的問題点を指摘し、その様な問題点に陥らいなための活用法を検討
今回取り扱った内容は、それ自体で1冊の本や2単位程度の講義になるものです。
それを1回の講義に集約したので、詰込み感は否めませんが、ここをこのペースで片づけておかないと、PM3.0を展望することは難しいので、ご理解ください。
1.PM2.0ではどの様なマネジメントを行うのか
まずは下記の図を元に、PM2.0の骨格的な流れの要点を説明します。
PM2.0の特徴は「分割して統合せよ」ですが、時系列でみると、マネジメントは上のスライドの様に展開されます。
スライド中の番号に沿って説明します。
① 出発点は、プロジェクトの使命・目的・目標を確認することです。確認であることに注意してください。所与の使命を一方向で伝達・確認するだけではプロジェクトは上手く進まないことは、導入講で述べた通りです。
そして分割です。
② プロジェクトの使命を達成するために実施すべき業務の範囲を確定し、これを、漏れなく重複なく細分化し、系統的な階層構造として規定します。これがWBS：Work Breakdown Structureです。WBSは、誰が何を担当するのか、どの様な順序で何時までに行うのか（工程）、各業務にどの程度の費用をかけるのか（コスト）、プロジェクトは円滑に進んでいるか等の、マネジメントを行う上での出発点となる中核的な概念です。
③ プロジェクトの実行を担う組織を編成します。この組織とは、プロジェクト期間中に組成される期間限定の組織（つまりプロジェクト・ティーム）で、ティームの編成を示すのがOBS：Organizational Breakdown Structureです。
④ WBSで分割された業務を、OBSの誰が担当するのかを規定します。これによって、責任を明確にし、漏れを防ぐことができます。WBSの各業務の遂行に必要な人的資源、費用、期間を割り当てることで、業務計画を策定することができます。
次に統合です。
⑤ WBSの各業務の順序や相互関係を考慮して、業務のネットワークを組みます。各業務に所用時間を割り付けることで、最も時間のかかる経路（Critical Path）を見出し、これが期限に間に合うよう、スケジュールを計画します。これは、PERT：Program Evaluation and Review Techniqueと呼ばれます。
⑥ 工程ネットワークを、分かりやすい工程表Gannt Chartとして表現し、プロジェクト・ティームで工程表を共有し、プロジェクトの進行を管理します。
⑦ WBSの各業務の実行に必要な費用に全体の調整などの諸費用を加えて、予算計画Budget Planを策定します。この様にして算出した費用が、予算の枠内に収まることは殆どないので、何度かの見直しを経て実行予算が定まることになります。
⑧ プロジェクトの進捗管理では、時間、出来高、費用の3者を統合的に管理します。この為の管理手法がEVM：Earned Value Managementで、WBSやPERTと並ぶプロジェクト・マネジメントの中核的概念です。プロジェクト・マネージャーは、出来高や費用の実績値を計画値と比較し、必要な措置を講じます。
以上の活動を簡略化し、導入講で述べた戦略策定→プロジェクト→オペレーションという全体の流れに埋め込むと、上のスライドの様に表すことができます。
青色で着色された領域が、正統派のプロジェクト・マネジメントの守備範囲となります。
本講義ではその様な限定を取り外そうとしていることは、導入講で述べた通りです。
2.プロジェクト・マネジメントの源流を訪ねる
現代的なプロジェクト・マネジメントは、1930年代のHoover Damの建設にはじまり、後にCPM（Critical Path Method）やEVM（Earned Value Management）として統合されるいくつかの手法が開発された1950年代に本格化するとするのが妥当でしょう。
今日においても広く活用されている、Gantt Chart、PERT、WBS、EVMをPM手法の源流として、歴史が長いものから順に紹介します。
Gantt Chart
プロジェクト・スケジュールの表示方法として、現在も広く用いられているのがガント・チャート（Gantt Chart）で、皆さんにも馴染み深い工程表のことです。ガントは（写真上）、機械技師で、科学的管理法の父（the father of scientific management）とも呼ばれた、テイラー・システムで有名なFrederick Taylor（写真下）の助手として、労働力や原材料、機械類の効率的な利用法の探求に携わりました。第一次世界大戦中は造船に従事し、ここでの経験に基づきガント・チャートが考案されたといわれています。
元祖ガント・チャートでは、業務単位ではなく個人単位でのスケジュール一覧が可視化されています。下記3点の効能により、計画通りのあるいはより早いプロジェクトの終了が可能となったとされています。
① 個人の仕事のスケジューリング
② これに基づく進捗状況の計測と管理
③ 計画達成時のボーナス
ガント・チャートは、不況政策でも有名なHoover Damの建設 （1931年着工、1936年竣工、BOX03参照）やEisenhower Highway（1956年供用開始）に用いられ、効果を発揮しました。
上のスライドは、最も単純なGannt Chartです。
プロジェクト・マネジメントにおけるガント・チャートの意義は、
このチャートによって、何が、いつなされるべきかを共有することができることにあると言えます。
具体的には、以下の点が挙げられます。
① どのような業務があるか、全貌を理解する
② 業務がいつ始まり、いつ終わるかを知る
③ 業務の実施期間を知る
④ 業務間の重複の有無、期間を知ることができる
⑤ プロジェクト全体の開始・終了時点を知ることができる
現在のガント・チャートは、機能的にもより洗練され、支援ツールも幾つか販売されています。
PERT(Program Evaluation and Review Technique)
スライド中の切手の写真は、上がスプートニクの打ち上げ成功を祝うソ連発行の記念切手、下がポラリスの成功を祝う米国発行の記念切手です。
1956年米国海軍のSPO（The Navy's Special Projects Office）は、ポラリス潜水艦や艦船弾道ミサイル計画という大規模な計画を開始しました（the Polaris-Submarine weapon system and the Fleet Ballistic Missile capability）。冷戦下にあったソ連による1957年のスプートニック1号の打上成功にショックを受けたからです。米国では、ミサイルギャップを埋めるための早期の開発完了が重大な軍事的使命となり、このためのOR（Operations Research）ティームが設置されました。
このティームが構想し、実践化した手法がPERTであり、複雑で不確実性のある研究開発を、如何に迅速に実施するかが、基本的な問題意識であったとされています。1958年にはPERTのガイドブックが既に刊行されています。スライドの真ん中が表紙の写真です。
PERTでは、ネットワークを用いて、最も時間のかかる経路であるクリティカル・パス（Critical Path）を見いだし、これに焦点を当てて、目標とする時点でプロジェクトが終了するように、修正を加えながらスケジュール計画を策定します。現在もスケジュール・マネジメントの中核的な手法と見做されていますが、一方で厳しい批判も寄せられています。この点については、後で触れます。
WBS(Work Breakdown Structure)
WBSは、ポラリス潜水艦や艦船弾道ミサイル開発において、米国国防総省DODにより、PERTと並行して開発された手法で、1962年DODとNASAはPERTによるスケジュール・マネジメントとコスト・マネジメントを統合したPERT COSTを公表しました。
この中で、スケジュール・マネジメント、コスト・マネジメントの両者のベースとなるWBS （Work Breakdown Structure：業務分割構成）に関する記述がなされています。
WBSは、複雑なプロジェクトを系統的・階層的にマネジメントの容易な規模の分割する手法で、工程管理やプロジェクトに必要な人材や資金等の資源管理の基本をなすものです。開発後60年を経た今日も、プロジェクト・マネジメント・ツールとして広く活用されており、プロジェクト・マネジメントの最も重要な方法論であると述べる専門家もいます。
WBSの基本的発想として、以下の5点を取り出すことができます。
① WBSは、成果物志向のツール（a product-oriented family tree）で系統図表現を採用している。
② WBSでは、プロジェクトを構成する業務を、マネジメント可能な単位に段階的・階層的に分割する。
③ WBSは、プロジェクトの初期段階で作成される必要がある。
④ WBSは、コスト、スケジュール、クオリティに関する計画と管理を有効なものとする。
⑤ WBSは、ハードウエア、ソフトウエア、サービス、組織、その他の成果物など、プロジェクトの目的達成に必要なあらゆるものを対象とする。
WBSは、全体の業務を漏れなく重複なく分割するもので、ロジカルシンキングにおいて重視されるMECE（Mutually Exclusive, Collectively Exhaustive）の先駆けであると言えます。
また、WBSにおいて定義されていない業務は行ってはならず、その様な業務が必要とされる場合には、プロジェクト・マネージャーはプロジェクト計画を変更しなければなりません。
EVM（Earned Value Management）
EVM：Earned Value Managementは、WBSやPERT COSTを集大成したもので、スケジュールとコストを統合的に管理することを意図しています。日本語では、土木・建築用語である出来高管理がこれに近い概念であるといえます。
EVMの考え方を実務に最初に導入したのもDODで、アーンド・ヴァリューの概念を体系化し1967年にthe Cost/Schedule Control Systems, C/SCSC（the Cost/Schedule Control Systems Criteria）が策定されました。C/SCSCは、国防総省が発注する一定金額以上のプロジェクトに対して適用が義務づけられ、国防総省のプロジェクトを受注したベンダーは、C/SCSCのルールに従ってプロジェクトの状況を国防総省に報告することとなりました。
EVMは、1970年代後半には建設業界においても紹介され、1987年に発行されたPMIのホワイトペーパーにおいても言及されています。当初C/SCSCは財務・予算管理の手法とみられがちであったとのことですが、1プロジェクト・マネジメントにおける統合的な手法として普及・発展しています。我が国においても、2003年に経済産業省・情報処理振興事業協会により『EVM活用型プロジェクト・マネジメント導入ガイドライン』が公開されています。
EVMでは、プロジェクトの進行に伴う、出来高やコストの積み上がりを金銭表示で示す、計画出来高（Planned Value）、実際の出来高（Earned Value）、実際に消費したコスト（Actual Cost）の3指標が用いられ、進捗状況の評価には、計画と実績の不一致指標が用いられます。
3.事例を用いてWBS, Gannt Chart, EVM, クリティカル・パスを理解する
この章では簡単化された新治療法導入プロジェクトを事例に、各手法がどの様に適用されるかを説明します。
WBSからEVMへの展開は、正統派プロジェクト・マネジメントの核心というべき部分であり、今日でも広く用いられている方法論です。またPM3.0においても継承されるべき部分は継承されるべきであると考えます。そこで、数値例を用いた具体的な説明によって、確実に理解して頂くことを期待します。
紹介事例は、医療サービスの改善に向けてプロジェクト・マネジメント導入の必要性が強く意識されている米国の医療領域において、プロジェクト・マネジメント導入を勧める啓蒙的論文から、採ってくることにしました。この論文では、新療法導入プロジェクト「Implementing new clinical practice」におけるWBSとGantt Chartが紹介されています。それに筆者がEVMとクリティカル・パスの検討を追加しました。本事例は「変革はプロジェクトである」という本講義の基本的立場と合致するものです。ただし、本事例ではChange Managementについての配慮が不足しているのではないか？と思われる方もおられると思います。この点については、巻末の補足を参照して下さい。
(1)事例でみるWBS
まず、新しい治療方法を導入するプロジェクトで、これがWBSの第1層に記述されています。
次に、第2層では、業務が5つに分割されています。
・エビデンス調査：新治療方法を導入した際に変更しなければならない点を明確にします。
・新手順定式化と承認：エビデンス調査に基づいて新手順を定式化し、病院の意思決定機関の承認を得ます。
・新手順の検証：新手順の承認に必要な検証を行います。
・スタッフの研修：新手順の実践の中核を担うスタッフの研修を行います。
・実践の展開：病院全体に新治療方法の周知を行い、実践を開始します。
最後に、第3層では第2層の業務を更に分割していきます。
一例としてスタッフの研修についてみると下記の様に分割されています。
・研修受講者の設定：どの範囲の医療業務従事者を研修の対象とするかを設定します。
・研修案内の送付：対象者に研修案内を送付します。
・研修の実行：文字通り研修を実行します。
・研修完了の確認：必要な役職員に対して研修が完了したかを確認します。
■WBSは成果物志向になっているか、確認してみましょう
このWBSは、後出のGannt Chartから分かる様に時系列に対応していますが、他方、下表に示す様に、第2層は成果物に対応していると見なすことができます。この事例では、プロジェクトの構造が比較的単純で、フィードバックがあまりないので、時系列対応≒成果物対応が成立していることになります。
(2)事例でみるGantt Chart
■プロジェクト・フローを可視化する
プロジェクトのスケジュールを検討し、工程表Gannt Chartを策定する上で、業務の流れを把握し可視化することが必要です。
実際のプロジェクトでは、WBS作成の前段階にプロジェクト・フローを検討する、という流れとなるでしょう。
・プロジェクト・フローでは、第2層のWBSを単位として描くことによって、プロジェクトの流れを構造的に把握することが可能となります。
・図中赤枠を付した箇所は、プロジェクト進捗の上で節目となるマイルストーン/Milestoneを示しています。このプロジェクトでは、新手順が承認されること、主要なスタッフの研修が終了し実践開始の条件が整うこと、の2つがマイルストーンとなっています。
・実際のプロジェクトでは、先ず何をマイルストーンとして設定するか、それを何時に置くか、の2点が極めて重要で、多数のワーク・パッケージからなるプロジェクトでは、マイルストーンだけの相互関係を示すマイルストーン・チャートを先ず作成することになります。
■プロジェクト・フローから工程表Gantt Chartへ
プロジェクト・フローに基づき、プロジェクトを目標とする期日に終了させるために各業務に所用時間を割り当てて、工程表Gantt Chartを作成します。
・このプロジェクトは、6週間という短期のプロジェクトなので、各ワーク・パッケージ（WBSの最下位レベルの業務分割で通常ワーク・パッケージWork Packageとよばれる）のスケジュールは日単位で計画されています。もっと短期間のプロジェクトや、長いスケジュールのプロジェクトでも非常にクリティカルな局面の場合には、時間単位でスケジュールを計画する場合もあります。逆に日単位のスケジュールに意味がない場合は、週単位、月単位など適切な時間尺度を選択することになります。
・図中赤枠を付した◆の記号は、プロジェクト進捗の上で節目となるマイルストーン/Milestoneを示しています。このプロジェクトでは、新手順が承認されること、主要なスタッフの研修が終了し実践開始の条件が整うこと、の2つがマイルストーンとなっていることは、プロジェクト・フローで説明した通りです。
・図中青枠を付したWBS第2層の業務の関係は、基本的に前の業務が終了すると、次の業務に着手することになりますが、例外は、図中橙色の楕円で示した「新手順の定式化と承認」と「新手順の検証」です。新手順の定式化の後、これが検証されないと承認は降りないので、両者は入れ子の関係になっています。では何故、「新手順の検証」を「新手順の定式化と承認」に含めて一直線の流れにしないのかというと、検証が極めて重要であること、検証は別のメンバーによって行われること、等の理由により、分離しておいた方がプロジェクトの構造がより明確になる、という理由が考えられます。
このように、業務間に相互関係がある場合、スケジュールや情報の流れに対する一層の配慮が重要です。
(3)事例でみるEVM
下の表には、「エビデンス調査」の部分のPV, AC, EV3指標の計画値や実績の計測値が示されています。プロジェクトの管理単位は、最小の業務分割単位であるワーク・パッケージなので、ワーク・パッケージ毎に数値が示されています。表が小さくて読み難いと思いますので、元のエクセル表も添付しています。
① PV：Planned Value/計画出来高
各ワーク・パッケージの遂行によって実現する価値（出来高）を示します。通常、業務に投入する資源量（計画工数）で出来高を表します。ソフトウエア開発や設計業務等では、計画工数として投入するマンパワーを用いることになるので、一種の労働価値説といえます。
アウトプットの価値は、要求品質を充たしていることを条件として、計画されたインプットで計測します。
従って、計画出来高と計画予算は一致することになります。計画予算をここでは実績コストAC（Actual Cost）に対比させて、PC（Planned Cost）という略称で表すことにします。
例えば、「新しい方法の調査」は第2日から第4日の3日間で行い、第2日には3単位、第3日には4単位、第4日には5単位の資源（この場合はマンパワーを金額表示するのが自然）を投入し、それに見合った成果を上げることを期待しています。
② AC：Actual Cost/実績原価
ACは、実際に発生した費用を示しています。
「新しい方法の調査」の第2日と3日には、計画通りそれぞれ3単位、4単位が実際に投入されていますが、第4日は、計画の5に対して1多い6単位が投入されています。
③ EV：Earned Value/実績出来高
ある期間で達成された成果を示しています。
「新しい方法の調査」の第2日目は計画通り3の成果が上がっていますが、第3日目では計画の4に対して3の成果しか上がっていません。そこで後れを挽回するために、第4日目には計画の5より1多い6の資源を投入し、6の成果を実現することによって、後れを挽回しています。あるワーク・パッケージの途中段階で、出来高を厳密に定義することは現実的には難しく、適当な補間方法や経験的判断を用いることになります。業務が中断された場合、必ずと言っていい程、発注者と受注者で見解が対立し、紛争の原因となります。
④ コストの超過
「新しい方法の調査」では、計画した資源の投入量（PC=PVなので3+4+5=12）に対し、実績原価は13（3+4+6）と1単位のコスト超過が発生してしまいました。
⑤ スケジュールの遅延・挽回・遅延
「新しい方法の調査」では、途中の遅れを挽回することができました。しかし「現行方法の確認」では、元々1日しか割り当てられていなかったので、後れを挽回することができません。
この影響が「変更箇所の決定」に及び、第10日目では計画の10に対して投入が5に抑制されています。これは、前作業の遅れのために、10を投入してもそれに見合った業務を行うことができない、との判断によります。
この遅れを挽回するために土日に業務が行われ、「変更の影響の評価」は計画通り開始することができました。しかし、土日の無理な出勤のため、計画の7に対して5の投入しか確保できず、結局「エビデンス調査の収量は1日遅延することになりました。
⑥ アイドリング
「エビデンス調査」は何とかスケジュール通りに終わるだろうと期待されおり、遅延していることが、次の段階の業務である「手順書作成」ティームに伝達されていなかったので、「手順書作成」の初日である第11日に計画されていた業務を行うことができず、8人がアイドリングすることになってしましました。
まさかこんな事が、と思う方も多いかもしれませんが、現実ではしばしば発生する事態です。
業務の一部を外部に委託する場合には起こりがちな現象です。インハウスの場合であっても、費用が発生している事には変わりはありません。
この様な状態の発生を防ぐのが、プロジェクト・マネージャーの役割の一つといえます。
プロジェクトの全工程に関するPV, AC, EVは下表の様でした。
表の右の赤枠の部分が3指標の累計値で、これに着目してマネジメントを行います。
先程の表の3指標累計値をグラフにしたのが下のグラフです。
・PV：Planned Value（計画出来高・計画予算）の累計値を緑色、EV：Earned Value実績出来高の累計値を青色、AC：Actual Cost実績原価の累計値を赤色の線で示しています。
・計画予算（緑）より実績原価（赤）が上にあることは、予算の消化スピードが計画よりも早いことを示しています。予算消化が早くても出来高がそれに追随している場合もありますが、予算超過の場合が殆どです。
・計画出来高（緑）より実績出来高（青）が下にあるということは、実績が計画を下回っていること、つまりスケジュールが遅延していることを表しています。
・実績原価（赤）が実績出来高（青）の上にあるということは、予算超過（Cost Overrun）が発生していることを表しています。
一例として、プロジェクト半ばの20日を見てみると、以下の状況となっていることが分かります。
・実績出来高累計値は（EVc）118は計画出来高168の70%に過ぎず、遅延が発生しています
・実績出来高118は17.5日時点の計画出来高に相当しており、2.5日（20-17.5）の遅延が生じています
・実績原価は177で、実績出来高118に対して50%の費用超過が発生しています。
最終的に本プロジェクトは6日遅延して完了し、原価は29%の超過となっています。
この様に、EVMはプロジェクトの計画と実績との乖離を、出来高、原価、時間の3点から総合的に、可視化して把握する標準的な方法を提供しています。
■3指標間の比率によって状況を把握します：EV/PV, AC/EV, AC/PV
EVMにおける各指標の比は、以下の様にマネジメント指標として用いられています（下のスライドを参照して下さい）。
・EV/PV（Earned Value/Planned Value）は業務の遅延状況を表しています。
実績出来高と計画出来高の比であるので、進捗状況を直截に示す評価指標といえます。
本例では、19日で0.702と最も低い値となっており、その後計画出来高に近付ける努力がなされていますが、依然として値は変動し、目標完了日である第42日でも0.898に過ぎません。EV/PVはSPI（Schedule Performance Index）とも呼ばれスケジュールに関する評価指標とされています。
・AC/EV（Actual Cost/Earned Value）は費用の超過状況を表しています。
後出AC/PVの問題点を解消する指標であり、EVMによって初めて導入されました。
本例では第12日や20日に50％のコストオーバーとなっています。ちなみに12日の時点でのAC/PVは115％に過ぎないので、AC/PVを費用超過の指標とすることは問題であることが分かります。その後コスト改善の努力がなされており、最終的には30％のコスト・オーバーランに改善されています。
・AC/PV（Actual Cost/Planned Value）は予算に対する支出の先行状況を示しています。
WBS導入前はEVを考慮することなく、また、PV＝PC＝EVと単純化して、実際に要したコストと計画コストの比で進捗管理がなされてきました（つまり、AC/PV＝AC/EVと見做しました）。プロジェクトの資金繰り上は意味がありますが、実際の出来高を考慮していないので、全般的な進捗管理指標としては問題です。しかし、このレベルにとどまっている企業も多いものと思われます。資金繰り上の意味は、プロジェクトの費用が前倒しで消費されるとその資金を投資に回した場合に、前倒し期間中に得られる利益を失うことになる、と考えれば理解できるのではないでしょうか。
■スケジュールに焦点を当てるES：Earned Schedule
ある時点の実績出来高はどの時点の計画出来高に相当するのか、を示すのがES:Earned Scheduleです。
ESは、Alexandre Rodrigesが、2015年に Effective Management of Time Performance Using Earned Value Managementで提案したものです。PMBOK第6版のProject Cost Managementにおいても簡単に触れられています。
本事例でのESの推移を下図に示します。ESを示すのが青線です。
・計画通りにプロジェクト進捗している場合には、当然のことながら両者は一致します。
・実績値が計画値の下にあることが、プロジェクトの遅延を表しており、両者の乖離が拡大することは、プロジェクトの遅延状況が悪化していることを示しています。
・第20日の実績出来高118は17.5日の計画出来高に過ぎないので、2.5日の遅延が生じています。この差分は、下図の赤線と青線の差に相当しています。
(4)事例でみるクリティカル・パスCritical Path
本事例のプロジェクト・フローを下図の左に再掲しました。プロジェクトの所要時間は、単線の経路となる実線の矢印で決まるので、クリティカル・パスは存在していません（あるいは、すべての業務がクリティカル・パス上にあります）。
これではクリティカル・パス分析を説明できないので、このプロジェクト・フローの原型を変形して複線型にしたのが、下図右のコンカレント型です。
■複線型経路が存在する場合のクリティカル・パス
コンカレント型の手順は、プロジェクトの所要時間を短縮するため用いられる常套手段の一つと言えるでしょう。本事例の場合では、ややリスキーなところがありますが、新手順の手順書が策定出来た時点では承認の見通しが立つと考えて、手順書の承認獲得を待つことなくスタッフの研修に着手する、つまり、新手順の検証とスタッフの研修を並行して行うというものです。
・コンカレント型では、手順書の作成から実践の展開からプレゼ資料作成に至る一本のルートは、左側の新手順検証→手順書の承認獲得という経路と、右側のスタッフの研修という経路の2本の経路が存在します。
・左側の経路の所用日数は5日（2+2+1）、左側の経路は8日（1+1+5+1）で、プロジェクトの所用日数は右側で決まることになります。そこで、右側の赤い矢印を付した経路をクリティカル・パスと呼び、スケジュール計画やスケジュール管理の焦点を当てることになります。
■クリティカル・パスに注目したスケジュール計画やスケジュール管理
・複線型にすることによる所用日数の短縮で十分であるとすると、スケジュール管理上は、新手順の検証以上にスタッフ研修に注力すべきである、ということになります。
・この短縮では不十分で、さらに所用日数を短縮したい場合には、どうすればよいでしょうか？新手順の検証を短縮することには意味がなく、クリティカル・パスである赤の線上にあるワーク・パッケージの日数を短縮する、スタッフ研修の開始時点を早めコンカレントの度合いを高める、等クリティカル・パスを短縮することの実行可能性を検討することになります。
・ここで、スタッフ研修の所要時間を8日から4日に短縮する可能性が高いことが分かった場合、今度は5日を要する左側の経路にクリティカル・パスが移動することになるので、左側をそのままにして4日に短縮することには意味がない（5日への短縮で十分）といえます。
このように、クリティカル・パスを中心に、全体のバランスを見たスケジュール調整が必要とされます。
4.PM2.0の中核① PERT（Program Evaluation and Review Technique）を知る
事例の最後でクリティカル・パスについて簡単に触れたので、もう少し説明を加えることにします。
私が初めてPERTを知ったのは、1965年に出版された加藤昭吉著『計画の科学』を通じてです。大変優れた入門書だと思いますので、関心のある方は是非読んでみてください。以下の記述は、同書に多くを拠っています。
■PERTの基本的発想
PERT開発における中心的課題は、下記の3点であったと加藤氏は述べています。科学的論理性と、変更や不確定要因への対応性を確保することが基本となっています。
① 経験とか勘に頼る手法ではなく、手法そのものが、科学的論理性によって貫かれているような手法であること。
② 大規模なプロジェクトに対しても、全体的な見地からスケジュールしコントロールすることが可能で、設計変更等の変更要因に対しても即刻対応できる手法であること。
③ 大規模であると同時に、新しい製品の開発であるから、可能性の追求といった一面を持っている。したがって、プロジェクトの進行過程に付きまとう不確定要因に、効率的かつ効果的に対処できるような手法であること
■クリティカル・パスに着目したスケジュール計画
最初に想定したスケジュールで目標の期日を充たすことができれば苦労はない訳で、目標を充たすためのスケジュール短縮が実践的な課題となります。簡単な例で説明します。
上のスライドは、健康食品の開発プロセスを単純化したものと思ってください。4つあるフローの中で、右上の図が業務フローを、左上図が当初の想定スケジュールを示しています。太線がクリティカル・パスです。
当初想定のスケジュールは48日、目標期間は41日なので、7日の短縮が必要です。クリティカル・パスを7日間短縮する2案が下の段に示されています。短縮する業務が赤丸で示されています。
短縮案①も短縮案②も、クリティカル・パスを7日間短縮しているのに、全体の工程で見ると、案①では41日と目標を充たす一方、案②では43日と2日超過する結果となっています。何故でしょうか？
案②では、元のクリティカル・パスの経路短縮のため、赤矢印にクリティカルパスが移行してしまったためです。
クリティカル・パスなんて経験と勘で見つけることができる・・・という反論もあるでしょう。しかし、業務要素が150程度のネットワークでも経路数は数万のオーダーとなり、経験と勘で把握できる範囲を超えていることは明白です。現在では、ネットワーク作成やクリティカル・パスの同定には、専用のソフトウエアが用いられます。
■PERTの功罪について考えてみる
殆どのプロジェクトでは当初に試算したスケジュールでは期日に間に合わないので、スケジュール短縮を検討する必要がありますが、その際、闇雲に頑張るのではなく、プロジェクトを業務のネットワークとして捉え、クリティカル・パスに焦点を当てるPERTのアプローチには説得力があります。最初にPERTの思想に触れた時には、目からうろこが落ちる思いがしました。
一方、欧米系の企業がPMを担うプロジェクトに参加した際に、PERTやPMBOKの教条主義的適応に辟易した経験もあります。
私の個人的な経験も織り交ぜて、PERTの功罪について考えてみたいと思います。
■PERTの優れた点
OR（Operations Research）やMBA等で開発された手法の内、短命に終わるものが多い中で、PERTは現代的PMの定番手法として命脈を保っています。これは、米国の国家機関が使用を義務付けているということ以外に、PERTには優れた点があるからに他ならないと思われますが、加藤氏は、著書の中でPERTの優れた点として以下を挙げています。
① ネットワークを通して仕事の全貌が把握でき、仕事の着手前に工程上の問題点が明確にされる。
② 計画工程が納期オーバーになる場合、もしくは工程の途中で問題が提起された場合、明確な根拠に基づいて対策が打てる。
③ 工程全体からみると、クリティカルではないところに資金を投じて急がせるという無駄の発生を防止できる。
④ クリティカル・パスに当たるイベント（分割された業務）は全体の10％以下であることが経験的に分っており、効率的・効果的に重点管理を行うことができる。
⑤ 人員や特殊設備等の諸資源をクリティカルな作業に優先配分したり、時点の近い作業間で融通したりするなど、諸資源の利用効率を高めることができる。
⑥ 工程がどのように複雑化しても、担当者や担当部門間での共通認識醸成が容易である。
⑦ 計画通り進まなかった場合、遅延の影響度を推定するとともに、変更要因に対応した計画変更をネットワークに織り込むことができる。
⑧ クリティカル・パスの入ったネットワークは、発注者や下請けに対する有力な説明材料、意思疎通手段となる。
ここで注目したいのは、例えば④や⑤の様に、経験的根拠に基づく論理的な主張があるのと同時に、⑥や⑧の様に関係者間のコミュニケーション手段としての有効性に触れている点です。
■PERT神話の崩壊/The Flawed Foundation of PERT
PERTに対しては、実際にはプロジェクトでは活用されていなかった、との手厳しい批判もなされています。導入講で引用したAlexander Laufer氏の著書『Breaking the Code of Project Management, 2009』からPERT批判の部分を下記に引用します（下線付与、訳出は筆者）。同氏は、NASA Academyのアドバイザリー・ボードのメンバーを務めておりアウトサイダーからの批判ではないと思われ、下記の記述も複数の関係者へのインタビューに基づいています。
・PERTは実際にはシステム建設には使用されておらず、Polarisプロジェクトが成功したのは、素晴らしいリーダシップやマネジメント、関係者が共有する使命感に負っている。
PERT was not actually used to build the system…Instead Polaris’s success was the result of inspired leadership, good management and a shared spirit of commitment.
・PERTは見学者に先端のマネジメント手法を印象付け、神話の創成に使われたに過ぎない。
PERT was used primarily to impress visitors…and to build up a myth of management effectiveness.
私は、この様な批判の一因は、PERTの機械的・教条主義的な適用にあるのではないかと考えます。機械的・教条主義的な適用とは何を意味するのか、私の気付いた点を何点か述べることにします。
・PERT作成の基本となる業務分割WBSを推し進めると、大規模なプロジェクトでは非常に大きな要素数となり、これだけの要素数全数からなるPERTの作成と維持には相当の工数と時間を要します。
例えば100億円のプロジェクトを100万円単位のワーク・パッケージに分割すると、1万のパッケージ数となります。
・当初のスケジュール策定においては、全工程を対象とするWBSを詳細に作成することに意味がなく、PERT作成に必要だとの理由で、現場に詳細なWBS作成が強いられると、結果の信頼性も低く、メンバーの動機付けを損なうという、二重の弊害が発生することになります。
・プロジェクト実施中のスケジュール管理においては、当初想定していなかった外的事態の発生やプロジェクト・オーナーの要求変更などに対応しながらスケジュール遅延を防ぐことが、最大の課題となります。つまり、チェンジ・マネジメント（Change Management/変更管理）が重要となるのです。
・この様な外生的・内生的変化によってクリティカル・パスは変化して行き、新たに発生したクリティカル・パスの全体への影響を最小化するための、極めて具体的な解決策が重要となります。
場合によっては、局部的に時間単位でのスケジュール策定と管理が必要になることもあります。
・この問題解決において、PERT全体はもはや有効ではなく（全体PERTの内のある部分のみが有効）、教条主義的にPERT全体に修正を加えることは、有効性を欠く作業でしかありません。
従って、プロジェクトの局面に応じた詳細化のレベル、対象とする業務の範囲、必ずしもPERTにこだわらない手法の採用が重要だと考えるのですが、これらについては6で検討します。
5.PM2.0の中核② WBS（Work Breakdown Structure）：業務分割構成を知る
WBSもPM2.0の中核ですので、もう少し見ておくことにします。
■WBSの約束事
WBSを紹介した本や記事は数多くありますが、日立製作所の初田賢司氏と神子秀雄氏が執筆した『WBSがプロジェクトとあなたを変える』は、コンパクトで分かり易い有益な案内だと思います。両氏はその中で、下図を用いて、WBSの三つの約束事を以下のように述べています。
① Workは、「目的を達成するために必要な作業」のことです。例えば、プロジェクトの最終的な目的が「在庫管理システムを作る」ことであれば、WBSでは在庫管理システムを作るためにどういう作業が必要で、その結果、成果物としてどんなプログラムやドキュメントを作成するかを洗い出します。
② Breakdownは、「漏れなく分解」することです。プロジェクトの目的である「在庫管理システムを作る」を最上位のレベルに位置付け、そこから在庫管理システムを分解した構成要素を下位レベルとして定義していきます。ここではあえて「漏れなく」と断っているのがポイントです。
③ Structureは、「構造化して見える化」することです。必要な作業、結果として作成される成果物をツリー構造によって階層化して表します。上位のレベルが、下位のレベルの構成要素によって出来上がるように可視化します。
整理すると、WBSとは「目的を達成するために必要な作業」を「漏れなく分解」し、「構造化して見える化」するという意味になります。
■WBSの階層数はどの程度が適当か？
NASAのハンドブックでは以下の様に記述されています。要点を訳出して紹介します。
① WBSは承認されたプロジェクトの業務範囲をすべてカバーするものでなくてはならない。
② 必要なレベルまで細分化しうるものでなくてはならないが、NASAの中核的な財務システムでは7階層を上限としている。
③ レベル1はプロジェクト全体、レベル2は主要な成果物であって、これがさらに複雑性に応じて3から7のレベルまで階層化されることになる（下図左参照）。
④ 最下位レベルは、通常ワーク・パッケージ（Work Package）と呼ばれる。
⑤ またここで重要なのは、分割された各要素が一定のルールに基づいてコード化されることである（下図右参照）。
日立の初田氏、神子氏は、3層構成（NASA基準では4層構成）が適切だとして、下表を提案しています。
① プロジェクト全体（全工程）の作業内容とスケジュールを示す「大日程計画」
② ティーム単位の作業内容やスケジュールを示す「中日程計画」
③ 個人レベルの作業内容とスケジュールである「小日程計画」
この提案では、プロジェクト・オーナー等のステイクホルダーへの報告は「大日程計画」レベルで対応することとなっています。プロジェクト・オーナーは、一般には実行の細部に興味は持たないので、このレベルで報告することは妥当です。
しかし、WBSがプロジェクト実行側の観点から行われている場合には、階層のレベルの問題ではなく、分割の仕方そのものがプロジェクト・オーナーの関心を喚起しない可能性があります。これだと、事務的・形式的な進捗報告となってしまい、プロジェクト・オーナーとプロジェクト実行側の信頼醸成に負の効果をもたらす恐れがあります。
この点の解決には、プロジェクトの目的とWBSをつなぐMBS：Mission Breakdown Structureが有効です。MBSは本講では簡単に触れ、第3講で詳しく紹介します。
■何を切り口として業務を分割するか
PMBOKでは、WBSの作成方法として以下の3タイプが示されています。
① ワーク・パッケージに依拠
② プロジェクトのフェーズ（段 階区分）に依拠
③ 主要成果物に依拠
PMBOKに掲載されている事例は、同一のプロジェクトを3タイプで表している訳ではないので、少し分かり難い様に思われます。そこで、建築プロジェクトの企画から着工までを対象に、3タイプのWBSを作成しました。これを下図に示します。
一番上が時系列でPMBOKの言う②に相当しています。建築プロジェクトの場合、時系列が明確なのですっきりしたWBSになります。日本ででは、伝統的に意匠設計者がプロジェクト・リーダーとしてマネジメントを行うものと思われてきたので、このWBSではマネジメントは明示されていません。
中段は業務区分ベースで、業務区分を時系列で並べたので、WBSとしては横向きになっています。設計事務所では業務区分に基づく組織編制を採用しているので、実行する組織のティーム編成を表すものとなっています。
成果物ベースが一番下で、成果物を時系列で並べたので、こちらもWBSとしては横向きになっています。プロジェクト・マネジメント業務の成果とは何かですが、ここでは、成果は作成される管理ドキュメントではなく、プロジェクトの円滑な進行そのものである、としました。建築主にとっては、この表現が一番分かり易いと思われます。
■テーマを入り口とするWBS：MBS(Mission Breakdown Structure）からWBSへ
NASAのガイドブックは、WBSを成果物志向の業務系統樹a product-oriented family treeと規定しています。プロジェクト・オーナーにとっては成果物が最大の関心事であることから、当然の原則であると言えます。
2009年に出版されたWBSに関する専門書『BUILDING A PROJECT WORK BREAKD OWN STRUCTURE, VISUALIZING OBJECTIVES, DELIVERABLES, ACTIVITIES, AND SCHEDULES』の著者のDENNIS P. MILLER氏は、WBSを以下の3層の概念で構成すべきであると述べ、先ず成果に依拠するPBSの作成から着手しワーク・パッケージに対応する活動の分割ABSや活動を担う主体OBSへと歩を進めるべきであると主張しています。
・最上位層PBS：Product Breakdown Structure (Deliverables)
・中間層ABS：Activity Breakdown Structure(Activities)
・最下位層OBS：Organizational Breakdown Structure
ここで、成果からもう一歩踏み込んで、何のための成果なのかという目的に着目し、
・プロジェクトは、目的実現のため解決すべき課題・テーマやミッションの集合体
・課題の解決された状態が成果である
と捉えると、WBSを解決すべき課題をベースとして組立てるという発想が出てくる筈です。
プロジェクトをテーマやミッションによって分割し、テーマに対応させて業務分割をしていくと、成果志向のWBSが導かれ、目的からのWBSの遊離という事態を避けることができると考えられます。
これは、解決すべき課題に優先順位を設定して業務を実行していくというアジャイルの発想とも近いと言えます。
「MBS－WBS連携」については、第3講で詳しく検討したいと思います。
■WBSと実行組織OBSを結びつけます
WBSで分解された業務を分担するティームが決まっていないと、計画立案そのものができません。実践上は、機能単位の編成が一般的な組織構成（例：企画部、設計部、エンジニアリング部、製造部、調達部、財務部、等々）の中で、プロジェクト・ティームを編成することが重要な課題となります（導入講BOX02「機能型組織・マトリックス型組織・プロジェクト型組織マトリックス型組織」参照）。
このために、WBSで分解された業務毎にそれを分担するティームを割り当てておく必要があります。これがOBS（Organizational Breakdown Structure）と呼ばれるもので、WBSとOBSが関連付けられて計画されることが必要です。
WBSとOBSの交点に付された青い丸はCA（Control Account）と呼ばれプロジェクト予算の策定やコスト管理の基本単位となるものです。コントロール・アカウントは、同図赤枠内にも示されている様に更に再分割され、これはWP（Work Packages）/PP（Planning Packages）と呼ばれます。実際の作業を管理する上での基本単位となります。
■計画立案の8ステップ
WBSは本講の冒頭で紹介したプロジェクト計画策定の中核となる部分ですので、スケジュール計画を含めてその立案プロセスを紹介しておきます。
前述したPBS-ABS-OBSというWBSの3層の概念構成を提唱するMiller氏は、これに対応したWBSに計画手順として、下図に示す8ステップを提案しています。
・最初の3ステップがProductBSの策定です。PBS案を作成した後、プロジェクト・オーナーなど関係者のレビューを経て、PBSとして確定します。
・PBSに基づいて成果物の実現に必要な業務を洗い出し、ActivityBSを作成します。通常のWBSに相当するのがこのABSです。
・ABSの個々の業務を誰が行うのかを定めるOrganizationalBSの策定は4ステップ目です。
・ステップ5〜8は、ABSの相互関係を分析し、ネットワークを作成し、目標期日に間に合う様にスケジュールを策定するプロセスで、PERTに相当します。
■EVMの「PV」で計画の現実性を評価します
最終的に、プロジェクトの目標期日（due dateと呼ばれます）を含む様々な制約条件を考慮して、スケジュールを見直し、現実的で、しかもステイクホルダーが合意できる状態にまで持っていくのがスケジュール調整です。
特に「人的資源の配分は適切か」、「期間ごとの業務負荷のバランスはとれているか」と言う点に重点を置いてチェックします。このバランスを見るのに適したツールが、各工程の工数を月単位や週単位などの適切な期間で積み上げた「工数山積み表」です。
■WBSはPM2.0の要です
ここで、プロジェクト・マネジメントにおけるWBSの位置付けを整理したいと思います。一言で言うと、WBSはPM2.0の要である、となります。
上図のダイアグラムを用いて確認します。
① プロジェクトの遂行に必要な人的資源やその他のリソースは、WBSのコントロール・アカウント（場合によってはワーク・パッケージ）に基づいて算定されます。予算やスケジュールとの調整を経て、動員計画が策定されます。
② これに基づいてコスト推定が行われますが、通常は予算を上回るので、上記のリソースの見直しやスケジュール等の調整を経て、予算計画が策定されます。
③ WBSに基づき、スケジュール計画が策定されます。スケジュール計画の策定においては、予算計画やリソース動員計画との相互調整がなされることは、前述の通りです。
④ 成果物志向で構成されるWBSは、要求事項を抽出して整理する上での基本単位ともなります。
⑤ 抽出された要求事項は、品質マネジメントにおける品質基準として展開されることになります。
⑥ 品質基準は、WBSにおける業務単位が完了したか否かを判断し、意思決定する基準となります。
⑦ 要求事項や品質基準が細部に至るまで事前に確定しているとは限らないので、成果物やコントロール・アカウント単位でこれを決定するための意思決定が必要です。
⑧ 分割された業務の開始や終了、必要な意思決定等、WBSはプロジェクト・ティーム間やプロジェクト・オーナーとプロジェクト・マネージャー間等の関係者間のコミュニケーション・マネジメントの軸となります。
⑨ リスク・マネジメントの前提としてリスク分析を行う必要がありますが、WBSを単位とするリスク分析が有効です。
なお、上のスライドで赤字で示したQ品質、Cコスト、T時間は、鉄の三角形Iron Triangleと呼ばれるプロジェクト・マネジメントの基幹的なマネジメント要素です。
■WBSへの疑問：詳細なWBSをいつ作成するのか？
これまでの記述からは、WBSは良い事尽くめに見えますが、決してその様な事はありません。
WBSの運用上の最大の問題一つは、ここでの表題でもある「詳細なWBSをいつ作成するのか？」です（もう一つの問題はプロジェクトの目的との連携のさせ方です）。
例えば期間が2年のプロジェクトの全期間のWBSを、当初に同じ詳細度で作成することには、殆んど意味がないと思われます。
しかし、プロジェクト・マネージャーの中には、WBSを機械的・教条主義的に適用し、同じ詳細度で作成できないのなら、プロジェクト・ティームが提示するコスト計画やスケジュール計画に根拠がないのではないか、と考え、無理やり作成させる場合があります。
1997年に発行された先駆的な著作『Simultaneous Management』において、著者ローファー（Alexander Laufer）は次のように述べ、この様な傾向を痛烈に批判しています（訳出及び下線付与は筆者）。
精緻であるが間違っている
・詳細化する事によってよりよい管理が可能になるという幻想が、多くのプロジェクト・オーナーが過度に詳細で包括的なプロジェクト計画を要求する原因となっている。コントラクター（一般的には契約を実行する建設会社やエンジニアリング会社）は、洗練された手法を用いることを強いられ、詳細なネットワークとして表現されるスケジュールを作成するのだが、これがプロジェクト作成の鍵だという雰囲気が醸成される。しばしばこの様なマネジメント不能なガラクタの山とでもいうべきネットワークが、プロジェクトの全貌を見えなくさせてしまうのであるが、専門的なプロジェクト・マネジメントの精髄と見做されている。…精緻であるが間違っているより大まかだが当たっている、の方が常に望ましい。
The illusion that better control is available at a greater level of detail has led many owners to require an overly detailed and comprehensive master plan. Contractors must comply and are forced to go through the ritual of applying sophisticated tools to produce cumbersome plans in the form of scheduling networks, while conveying the impression that this is the key to success. Often these unmanageable and cluttered networks, which obscure the overview of the project, are marked as symbols of managerial professionalism.… It is always better to be approximately right than precisely wrong.
「精緻であるが間違っている」は大変印象的な言葉です。
多くの方法論が精緻化する傾向を持っていますが、研究者にとって論文を書き易いからではないか、と皮肉な疑いを持ちたくなります。
WBSの問題点とその解決の方向性は、PERTやEVMの問題点と合わせて、6で検討します。
6.WBS, PERT, EVMの問題点を集約し解決の方向性を提案する
この章では、これまで扱ってきた「WBS, PERT, EVM」それぞれの手法における問題点を指摘し、解決の方向性を提案します。
誰しも、プロジェクトを幾つかの業務に分割すること、スケジュールや予算をたてて進行を管理ことを行っている訳ですが、これを一貫して系統的に取り扱うWBS-PERT-EVMの流れは極めて論理的であり、成るほどこれがプロジェクト・マネジメントの骨格である、と思わせるものがあると思います。
しかし、PERTやWBSの手法の紹介でも述べた様に、決して良い事尽くめなのではなく、解決すべき重要な問題を孕んでいると言えます。
ここでは、散発的に述べてきたPERT、WBSの問題点に加え、EVMの抱える問題点も整理し、その解決の方法を探っていきたいと思います。この努力はPM3.0の構築への一歩であると考えます。
■WBS・PERTの孕む問題点
PERTやEVMは、WBSを出発点として展開されるものなので、WBSの孕む問題点を引継ぐことになり、WBSの問題点は様々な問題の源泉となりうるものです。
PERTの問題点としては、PERTの前提となるWBSの有効性に加えて、単一モデルによる全体の管理という発想が現実的なのか、を追加することができるでしょう。
■問題点A,Bの問題に対する４つの提案
解決方法として4つの方向性を提案します。
問題点Aに対して：目的-ミッション-WBSを関連付ける。
① MBS:Mission Breakdown StructureからWBSを作成
② MBU:Mission Build UpからWBSを作成
問題点Bに対して：PERTに多元的な時間軸を導入する。
③ ローリング・ウェーブ法の活用
④ リザルト・パスを軸としたマイルストーン・マネジメントと現場に密着した時間計画の両者を活用
■問題点Aに対して：目的－ミッション—WBSを関連付ける
提案① MBS:Mission Breakdown StructureからWBSを作成
プロジェクト・マネージャーにとって、WBSは、誰が何を行うかを定めて系統的に可視化している、という点で極めて重要ですが、一方プロジェクト・オーナーがプロジェクトの進捗状況を把握し、オーナーとして必要な意思決定や行動を行うためにも必要です。
この点から、WBSは実施側だけが理解できていれば良いものでは決してなく、プロジェクト・オーナーにとって理解可能で関心を保持できるものであること、が大変重要です。つまり、WBSには、コミュニケーションの媒体として大きな役割を担うことが期待されています。
従って、WBSはプロジェクト・オーナーの最大の関心事である成果志向で組み立てられていることが前提となりますが、ここで、成果がプロジェクトの目的と明快に結び付けられている必要があります。
一般に、プロジェクトの目的は抽象度が高いので、プロジェクトの目的を直接成果物に結びつけることが可能な場合は限られていて、プロジェクトの目的を、それを実現するのに必要な複数のミッション（下位目的ともよばれる）に展開し、このミッションが達成されるために必要なプロジェクトの成果を規定していく、という流れが適切です。
これは、MBS：Mission Breakdown Structureを導入することに他なりません。
MBSに関心のある方は、提唱者であるErling S. Andersen 氏の論文『Value Creation using the Mission Breakdown Structure』 International Journal of Project Management, Vol 32, 2014を参照ください。第3講で紹介する予定です。
抽象度の高い目的を具体性のあるミッションへと展開していくプロセスは、戦略側から実行側への一方的な情報の伝達ではなく、両者の相互浸透が重要で、双方の主要なメンバーが一堂に会した双方的なセッションが有力な場の一つです。
抽象的な目的を、プロジェクト実施側が自分のフレームで解釈し、その結果できあがった成果がプロジェクト・オーナーの期待と合わない、といった頻繁に発生する事態を起こさないためにも、MBS→PBS→WBSという流れは重要です。
一見煩雑に見えるかもしれませんが、決してそうではありません。具体的な事例を見ればお分かり頂けると思いますので、第3講「プロジェクトの目標や要求事項の設定」で紹介することに致します。
提案② MBU:Mission Build UpからWBSを作成
提案①の場合には、プロジェクトの目的の抽象度が高くても、関係者間のコミュニケーションによって、比較的円滑にミッションへの具体化が可能であることが想定されています。
しかし、目的が曖昧性を孕み、その解釈が多義的な（ステイクホルダーによって解釈が異なる）場合や、元々活動領域を異にする主体が協働してプロジェクトを企画・実行する場合には、目的→ミッションの展開が上手く進まない可能性があります。
この様な場合には、Breakdownという発想をBuild Upに切り替えるMBU：Mission Build UPが必要だと思います。
※MBS：Mission Breakdown Structureという概念は、最近欧米のプロジェクト・マネジメント界では言及されることが多いのですが、MBUは私の造語なのでご注意ください。
上図の右側は、提案①のMBSを縮小したものですが、いきなりMBSに入る前に、各ステイクホルダーがプロジェクトに参加する目的や関心事（つまり動機）を明らかにした上で、それらを包括しうる共通目的を導き出し（共通目的はCommon Purposeですが、上位目的という言葉でも構いません）、これをプロジェクトの目的に据えて、その後MBSに進む、という流れです。実は提案①における目的のミッションへの展開においても、参加者は夫々のフレームを用いて目的の解釈や具体化をしている訳ですから、MBUのプロセスは程度の差はあれ含まれている、と言えます。
この時、いきなり共通目的とは何か、を議論しても生産的な議論ができるとは限りません。むしろ、一見迂回的に見えても、各ステイクホルダーが何を解決すべき問題と考えているかを明らかにし、それらを構造化した後に、構造化された問題を解決する上で有効な共通目標を導き出す、というプロセスが有効であると考えます。
この事例も、第3講で紹介します。
■問題点Bに対して：PERTに多元的な時間軸を導入する
提案③ローリング・ウェーブ法の活用
WBSに限らず、プロジェクト・マネジメント方法論の機械的、教条主義的適用は、余分な作業をプロジェクト・ティームのメンバーに強い、かつその結果を盾にとられて無理な指示がプロジェクト・マネージャーからなさられる等、有害無益であり、絶対に避けたいところです。
では、この様な事態をどの様にして回避すればよいのでしょうか。その一つの方法が、Alexander Laufer氏（PERT神話の崩壊で著作を引用した）が提案したローリング・ウェーブ計画法です。
この方法では、プロジェクト計画のレベルとして、下記の3レベルが設定されています。
① マスター・プラン（Master Plan）：プロジェクト全期間を対象とするもので、各フェーズの終了などの主要なマイルストーンのみが示されています。
② 中期計画（Medium Detail Plans）：4から6ヶ月を対象とするもので、マイルストーンの下位レベルの主要な事項（例：プロトタイプのテスト、主要な発注業務）が示されています。
③ 作業計画（Detailed Work Plans）：数週間を対象とする作業計画です。
原型を提案したLaufer氏は、多元的時間尺度/Multiple Time Horizonsという発想に基づき、ローリング・ウェーブ計画法の原型を提案しました（Simultaneous Project Management 1997）。
Laufer氏は、多次元的な時間尺度の導入には、以下の様な原則論レベルでの効用があると述べています。
① 時間に関する計画のジレンマ「いつ計画を立てるべきか、早期か情報が集まってからか？/The timing dilemma of planning, When should one plan: early or late?」に決着をつけるものである。
② 意思決定において、直近の結果とその時点での将来の見通しを活用する事が可能な学習を、明示的に組込んだ計画のサイクルを機能させることが出来る。
③ 中期計画によって、先ず行動しその後で考える/act first-think laterというやり方が適切な業務を見出すことが出来る。
④ 全体的な展望と直近の行動計画の間の一貫性、整合性を保つことが出来る。
私は、この表で注目していただきたい点として、次の2点を挙げたいと思います。
【注目点1】時間尺度によって、マネジメントの焦点が異なることを明示している点です。マスター・プランでの焦点は成果物、作業計画では工程、両者の媒介項である中期計画では、工程及び成果物としている点です。
【注目点2】時間尺度によって、計画の性格が異なることを明示している点です。作業計画や中期計画は実行を保証することを示すものですが、マスター・プランは、策定時点では不確実性が高いので予測を表すもので、プロジェクトが進行し、プロジェクト・オーナーの求めるものが明確化する、実現方法が具体化する、外部環境が変化する、などの追加情報によって修正されるべきものである、としています。
提案④ 全体を見渡すリザルト・パスとと現場に密着した時間計画を併用する
■不確実性マトリックス
上図左の不確実性マトリックスの縦軸は何を/What？に関する不確実の程度を示し（上に行くほど不確実性が高い）、横軸は如何に/How？に関する不確実性を示しています（左に行くほど高い）。矢印の付いた軌跡は、プロジェクトの進行に伴う不確実性の解消をモデル化したものです。
この論文で大変興味深いのは、詳細な設計図が作成されているので、何を作るのかについての不確実性は低い筈だと見做されている建設プロジェクトにおいても、プロジェクト初期に、施工者は「何を、に関する不確実性/What Uncertainty」が高いと認識している点です。
■リザルト・パス
上図の中央は3で用いた事例のリザルト・パスです。
「何を、に関する不確実性/What Uncertainty」が高いプロジェクトの出発時点で、詳細なWBSやPERTを作成することに意味がないというのが、提案③のローリング・ウェーブ法の背景にある認識ですが、そうであるとすれば、プロジェクトの出発時点で作成するマイルストーン・スケジュール（マスター・プラン）が重要となります。
WBSがそもそも成果志向なのですから、マイルストーン・スケジュールも同様に成果志向であるのが必然と言えます。
目的→MBS→PBSのプロセスにおいて、求められる成果とは何かを明確にして共有するとともに、成果の相互関係、つまりある成果を得る上で、どの成果が前提として必要とされるのか、を明らかにしていく必要があります。これが、リザルト・パス/a Result Pathと呼ばれるものです。
■現場に密着した時間計画
現場に密着した時間計画で重要なことは、プロジェクト・ティームのメンバーが、プロジェクト・マネージャーから指示されたスケジュールに従うという一方向の流れではなく、ティームメンバーが時間計画の策定に参加し、なぜその順番と時間枠で当該業務を実行することが必要なのか、を理解し、納得していることです。
上図右は、アジャイルで用いられるバーンダウン・チャートで現場に密着した時間計画の一例です。
提案⑤ そもそもプロジェクトの目的は何かを共有するための前駆プロジェクトを導入する
ローリング・ウエーブの発想には賛同できるが、抽象的で曖昧さを孕んだ目的から出発するファジーなプロジェクトの始まりと整合しないのではないか？と思った方もおられると思います。
曖昧な出発点で短期のスケジュールを詳細にたてることは意味がない、と思われるからです。この点は、プロジェクトの目的—ミッションを明晰にし共有するための一定期間の活動を、プロジェクトの初動期に配置することで解決できるのではないでしょうか。
この活動は有期で固有の目的を持つ一プロジェクトでもあり、前駆プロジェクトと呼びたいと思います。
前駆プロジェクトの内容は以下です。
・提案①のMBS、提案②におけるMBUやそのための問題構造化をプロジェクトの初動期に実施する
・この活動をプロジェクト・オーナー側とプロジェクト・マネージャーやプロジェクト・ティームが共同で行う
これによって、目的を明晰にするとともに、共有を図ることが可能となります。
プロジェクトによっては、一定の成果が出てきた段階で、プロジェクトの目的がより豊かになったり、鮮明になったりするという、創発戦略と同様の現象が起こりうるので、「前駆プロジェクト⇒プロジェクト」が継起的に行われることになります（スライドの下の図のパターンでの展開）。
このプロセスは、ORで提案されたソフト・パラダイムとハード・パラダイムを交互に用いるMultimethodologyとの類似性が高いと言えますが、目的は当初は曖昧であると見做している点で、アジャイル・アプローチと同じ発想の上に立っているとも言えるのではないでしょうか。
Multimethodologyに関心のある方は、J. Pollack Multimethodology in Series and Parallel: Strategic Using Hard and Soft OR The Journal of the Operational Research Society Vol.60 2009を参照してください。
■WBS-EVMをどう活用するか
WBS-EVMの発想と論理は正にその通り、という所ですが、実践上は以下の問題点に遭遇することになります。
① プロジェクト予算設定の詳細度とWBSの詳細度が合致していない。前者の方が大雑把である。
② 会社の経理システムとEVM・WBSの間に、時間的なずれ、原価の集計単位のずれ、計上基準のずれがあり、プロジェクト専用のシステムが必要になる。
③ EVMに頼らないとマネージャーはプロジェクトを運営できないのか？これは、根源的な疑問で、『先制型プロジェクト・マネジメント』の著者長尾精一氏は、「実はEVMの有用性は、継続的に現場を見ているプロジェクト・マネージャーより、現場にたまにしか足を運ばない上位の管理者、または顧客にとってこそ大きいのである」と述べています。全く同感です。
④ 日本の契約形態とは親和性が低い。プロジェクト・オーナーにとっては全体の費用が問題で、内訳にはあまり関心がない場合が多いのです。
⑤ 成果の価値（交換価値）を設定・計測するのが困難である。
その導入が、プロジェクトの円滑な運営を支援するものではなく、上から目線の管理の道具になってしまうと、現場の余分な労力が増え、ティーム・メンバーの動機付けを棄損したり、酷い場合にはモラル低下につながる危険性もあり、その様にして得られた情報が、状況を適切に反映しているという保証はありません。
従って、WBS-EVMを現実に適用する際には、目的や文脈を十分考慮する必要があります。
少なくとも、以下の3つのレベルが考えられます。
① 経営的な立場の人が、プロジェクト群の進捗状況を把握したい
② プロジェクト・マネージャーがプロジェクトを適切に運営したい
③ プロジェクト・ティーム内で進捗状況を把握し行動に反映させたい
この場合、①～③に一つの一貫したシステムで対応することが効率的かつ効果的であるとは限らない訳で、②や③をベースに、なるべく手間のかからない方法で①に必要な情報を提供する、やり方を考えるべきです。
プロジェクト・ティーム内の進捗管理であれば、現場のマネジメントに近い方法、例えばAgileで用いられるバーンダウンチャートの様な方法の方が有効だと考えます。
プロジェクト全体については、前述のリザルト・パスの様な手法を用いて、プロジェクトを時系列及び内容の両面から適度な塊に分割した上で、ローリング・ウェーブの視点に立ち、WBS-EVMの精度を変えたマネジメントを行うべきです。
経営者の「プロジェクト群をマネジメントしたい」との要望に応えるのが、プログラム・マネジメントやポートフォリオ・マネジメントと呼ばれる方法論です。時間があれば、どこかで触れたいと思いますが、重要なのは、管理のために現場に余分な労力をかけない方法を見いだすことが基本である、ということです。
PMBOKの手法を機械的・教条主義的に適用するのではなく、その手法が考案された文脈を理解しつつ、自身が対象としている文脈と比較しながら、選択や修正を加えて用いることが重要です。
まとめ
今回は、導入講で述べた「PM2.0からPM3.0へ」を考える前提の一つとして、プロジェクト・マネジメントの源流とPM2.0の骨格について振り返り、理解することが目的でした。
まず、プロジェクト・マネジメントとは何か？についてその骨格を構成する4つの手法（Gantt Chart、PERT、WBS、EVM）の源流を辿り、具体的な事例を用いて理解を深めました。
さらに、中核であるPERTとWBSについて深掘りして紹介し、その問題点を指摘しました。
問題点の解決の方向として、「目的とミッションとWBSの関連付け 」という観点と「PERTに多元的な時間軸を導入する」という観点、そして両者を結びつける「目的を明晰にし共有するための前駆プロジェクト」を提案しました。
これらは、変革の時代のPM3.0を考えるにあたっての重要なポイントである
・目的を、どの様に創り上げ、共有するのか？
・目的を、どの様に現実化するのか？
密接にかかわってくることになります。
ところで、TGS（多摩大学大学院）の講義では、毎回演習課題を出しています。
参考までに、今回分の演習課題を記しておきます。私は、解答例のない演習課題を記載するのは、独立したテキストとしてはアンフェアだと思っているので、解答例は準備しています。ご関心があれば、こちらもアップロードする心算です。
① プロジェクト・マネジメントを受講するあなたの動機とは何でしょうか？具体的に記述してください。
② あなたが属している/属していた組織の活動をプロジェクトと見立てて、4層（NASAの定義での）程度のWBSとして表現してください。
③ 本日紹介したPM手法で、使ってみようと思うものを一つ取り上げ、どの様に適用するかを記述してください。
次回（4月22日）は、プロジェクトの成功をどの様に評価するのか？と、プロジェクトを失敗（成功）に導く要因とは何か？の2つのテーマを扱いたいと思います。
前者はプロジェクトの成功、後者はプロジェクト・マネジメントの成功に関する事柄ですが、私が若い頃には、プロジェクト・マネジメントの成功＝鉄の三角形QCTの達成＝プロジェクトの成功、と教えられ、そう信じてきました。実は今でも、気持ちの半分ではそう信じているのですが、PM3.0ではその様な訳には行かないと考えます。この点を掘り下げたいと思っています。
以上です。
引用論文や詳細の解説はこちらからご覧ください。
尚、以下の資料もクリエイティブコモンズとして公開します。
©中分毅 (Licensed under CC BY-NC-ND 4.0)
補足
＜チェンジ・マネジメント＞
組織における変革が簡単には成就しないことから、変革を対象とするマネジメント＝Change Managementという領域が成立しています。
プロジェクト・マネジメントでは、チェンジ・マネジメントを以下の2つのレベルで捉えることが重要です。
① プロジェクト＝変革なので、プロジェクト・マネジメントそのものがチェンジ・マネジメントと重なり合う。
② プロジェクトの実施の中で、当初の計画からの変更は不可避である。このレベルでのチェンジ・マネジメントも重要であるが、その方法論はあまり発達しているとは言えない。
上記①のレベルのチェンジ・マネジメントを支援する専門的なコンサルタントであるProsci社が1994年に設立されていることを、今回Noteの読者の方から教えて頂きました。Prosci社の資料では、プロジェクト・マネジメントとチェンジ・マネジメントの相違は以下の様に記述されています。
同社に関心のある方は、Prosci社HPや著作を参照してください。
・プロジェクト・マネジメントの重点：現在の状態から将来の状態への移行における技術的側面
・チェンジ・マネジメントの重点：現在の状態から将来の状態への移行における人的側面
導入講ではPM3.0に向けた着眼点の2として
・プロジェクトは人間によって担われる。人間的側面を重視する必要がある。
を挙げましたが、Prosci社の主張するチェンジ・マネジメントの問題意識とピタリと重なっています。
3で取り上げた事例では、Prosci社の提案するチェンジ・マネジメントには十分配慮されていませんが、チェンジ・マネジメントについては、補講（予定外の第11講）で取り扱いたいと考えています。
これまでの講義についてはマガジンにまとめています。
この記事が気に入ったらサポートをしてみませんか？