PM研究・研修部会
先号　　　次号

私の統合マネジメント思考

(有)デム研究所　城戸　俊二　[プロフィール]　：5月号
筆者はPMS (注 ： Performance Management System) の分野に携わって30年以上になる。筆者がこれの担当部署 (今で言うPMO的な職務グループ) に配属された頃はPMS機能を司る組織としては明示されず、スケジュール担当、コスト管理担当などと、プロジェクトマネジャーの職務の一部を担う担当者として認識されていた。昨今ではPMOやPMSなどはプロジェクトマネジメント組織の中でその存在価値や位置付けもPMBOK®ガイド やP2M、PRINCE2®などのプロジェクトマネジメント手法を通して国際的なレベルで認識されているが、当時プロジェクトマネジメントは米国国防総省が開発した手法が民間にも普及し始めた時期で、期せずしてPMS機能がプロジェクト組織の中で重要職務の1つとして認識され、筆者はその組織の立ち上げを担うことになった。以降現在までプロジェクトマネジメントに携わっているが、中でもこの手法の中核であるWBS (Work Breakdown Structure) に思いを込めて研鑽を重ねている。
本寄稿はPM研究・研修部会長 (氏は筆者の来歴およびPMAJでのWBS Sig活動をご承知) の指名を受けて執筆するが、その依頼の中で2点のコメントを頂いた。①「テーマはPMに係るものであれば自由に選定して構はない」、②「今までのWBSに対する云十年の思いについて綴っても良いかと・・」。これに甘えて本稿は筆者の過去の成果 (と自認するツール) を掘り起こし、統合マネジメントの参考に供することが出来そうなものを選び紹介する。筆者の稚拙さを暴露するもの、賢者 (?) として自認できるものなどが混在するがご容赦願う。
昨今WBSの参考書はPMI®のWBS標準など、素晴らしい参考書を容易に入手できる。これらのガイドブックには沢山の事例や約束事などが普遍的に解説されているので、入門レベルの知識は容易に習得できる。しかし、筆者が接するPM関係者との情報交換などで“実務に際して納得できるWBSを作ろうとして取り掛かると意外と難しい”、“WBSの見本は豊富にあるが自分の目的に叶う事例はなかなか得られない”、一歩引いて“頼りになるガイドも容易に見つからない”等の談をしばしば耳にする。
昨今では素晴らしい参考書や研修の機会を容易に入手できるのに、何故ことに当たってからもなお、このような悩みを抱え込むのか！　これらの根底には何らかの共通課題があるような気がする。

筆者もその課題に対応するため各種の方策を講じてきた。本稿はその中から今回の寄稿目的に有効と思われるものを棚下ろし紹介する。

筆者のPMSアーカイブスから
30年以上に亘って蓄えてきた知見、手法の内から“統合マネジメント”に役立ちそうなもの4件を選択した。
A ) ダイアモンド思考 (東洋エンジニアリング(株) 起案 (1989)、デム研究所編集)
B ) 奴凧 (東洋エンジニアリング(株) 起案 (1990)、デム研究所編集)
C ) 奴凧とPMS情報のライフサイクル (東洋エンジニアリング(株) 起案 (1990)、デム研究所編集)
D ) プロジェクトの成果管理に関わる情報の種類とフェーズを跨ぐ変遷 (デム研究所技術資料)

A ) ダイアモンド思考　(東洋エンジニアリング(株) 起案 (1989)、デム研究所編集)

図-A　ダイアモンド思考 要件・条件の相互関係整理の要領
図 - A　ダイアモンド思考
要件・条件の相互関係整理の要領

このツールは取り立てて“ツール”と言えるものではないが　プロジェクトの企画、計画の初期段階で解法も見つからなくて藁にも縋るような時の手法の1つとして便利である。プロジェクトマネジメントの企画・計画では各種の或いは多様な要件分析が必要であり、そこで加味される要件は多次元のマトリックスになるため上図のような簡単な要件設定ができる要領を心得ると便利である。筆者は課題や要件を簡単に上図の絵姿に描き思考や課題を整理する要領として慣れ親しんでいる。
PMSは要件が入れ組んだシステムなので初期段階でより正確に要求項目を取り込んでおかないと、構築したシステムを実用する段階で気が付いて慌てる羽目になっては、無理無駄が頻発する羽目になる。PMSに手慣れた人はこの段階は不用と判断する。また入門レベルの人でもWBSの要件を繋ぎ合わせれば一応の合格点が取れる。とは言え要件、条件をすべて洗い出すのは大変な作業である。プロジェクト実務レベルに叶うWBSは契約要件を完全に満たしたものであらねばならないのでこのための支援ツールはできるだけ使い易いものでありたい。

B ) 奴凧　(東洋エンジニアリング(株) 起案 (1990)、デム研究所編集)
PMBOK®ガイド にも示すようにプロジェクトマネジメントでは色々な管理手法を組み合わせて使う。この中でもWBS、スケジュール、組織、成果勘定法がプロジェクトのパフォーマンスを管理するためのコアで、夫々が機能に応じて役目を果たす。特にWBSはコアのコアである。ここではWBS、スケジュール、組織、成果勘定法がコアで、WBSがコアのコアである理由を述べる。

図-B 奴凧(東洋エンジニアリング(株)起案(1990)、デム研究所編集) WBSを核にした多重要件チェックマトリックス
図 - B 奴凧 (東洋エンジニアリング(株) 起案 (1990)、デム研究所編集)
WBSを核にした多重要件チェックマトリックス

誰でももの事に臨む時は何らかの計画をする。対処しなければならないもの事が大きい或いは複雑なときは、整理した作業を更に束ねて体系化する。これがWBS①の手始めである。次いでこれの管理責任を明確にするために管理担当者⑥を置くが、このとき担当範囲が広すぎる或いは内容が難しすぎる場合は適切な管理が出来るように細分化、或いは妥当な技量を持った人④を配する。作業に当たる人が多くなれば必然的に組織が重要となる。ここには「作業」と「管理担当」の関係があり、管理の対象 (WP ： Work Package) とその管理担当者⑦を明確にする必要性が出てくる。即ちプロジェクト組織とWBS／WPで「役割分担表」⑥を作り、相互の業務責任や分担を明確にする。
片や、もの事は手順を決め段取をして掛からなければ、時間だけが無為に進み、予定通りの目的を達成することが難しくなる。これには予め②作業スケジュールを整えておくことが大切である。 即ち②「作業」とその「手順と時間」の関係が在る。個々の作業はWPに包含されているので、ここでWPと手順・時間の関係が必然の要件となる。
また、もの事は達成してその喜びを味わうことが出来るが、作業量が多くて達成するまでに時間がかかる場合は、途中の状態を知り、途上での達成感を味わいたくなる。企業性や公共性が重視される場合は、その達成度合いがより客観的に判ることを求められる。もの事を行うには何らかの物を消費したり道具を使い、それに伴い費用が発生する。即ち作業と資機材の調達やコスト消費の関係④が在る。この時 消費する資源量を使って作業を定量化し、成果や達成度合いを勘定⑤することができる。自分で掌握できるサイズでもの事を捉え、その進捗状態を把握できれば鬼に金棒で、プロジェクト進行途上で多少の変動が起きても容易に対処できる。これもそこで扱う状況判断がWBSの枠組みの上で為されるからである。
上述の通りWBSはプロジェクトマネジメントの要にあるので、その位置づけと他の知識要素との関わりを理解しておくことが重要である。

C ) 奴凧とPMS情報のライフサイクル (東洋エンジニアリング(株) 起案 (1990)、デム研究所編)
下図にPMSの構築と運用の手順を示す。プロジェクト管理の作業は大略図の左下から右上へと段階を追って進行する。
プロジェクト情報処理の最終目的はプロジェクトのPDCA ： Plan、Do、Check 、Actionに必要な情報を適時適切に管理者と作業実施者間で共有することであり、この中で最も重要な情報がパフォーマンス管理に関わる情報である。これは論理的に裏付けられたものであるため、目的に合う情報が得られるように、予め管理のためのしくみを作業手順の中に埋め込んでおかねばならない。

図-C　奴凧とPMS情報のライフサイクル パフォーマンス管理技術とパフォーマンスデータの流れ
図 - C　奴凧とPMS情報のライフサイクル
パフォーマンス管理技術とパフォーマンスデータの流れ

　実行計画段階を図の左下から中央迄の部分に示す。図の左中央部の作業階層① (≒WBSの枠組み)の基でプロジェクト進捗状況や、成果を把握するための作業管理単位 (Work Package ： WP) を設定し並行してその管理担当者②を決め、それらの内容と実行管理責任を明確にする (役割分担割付)。併せてWPに予算額を割り付③け (WBS vs CBS (Cost Breakdown Structure))、次いでこれらのWPと作業スケジュール④ (CPMネットワーク) のリンクを明確にする。これにより管理ベースライン⑤が得られる。
　実行管理段階を図の中央から右上迄に示す。作業が進むに従い実績スケジュールが逐次更新されるが、このとき計画 (PV) の消化率を算出して出来高 (EV) が得られる。更に予算消費実績 (AC) も得られるので、予算消費額と出来高、及び計画の累積カーブ3本線) ⑥ (を総合的に比較して作業成果を評価し、必要に応じて対策⑦を講じる。上述の通りWBSはプロジェクトマネジメントの要であるので、その位置づけと他の知識要素との関わりを理解しておくことが肝要である。

D ) プロジェクトの成果管理に関わる情報の種類とフェーズを跨ぐ変遷
プロジェクトの成果管理に係る情報は図 - Bおよび C に垣間見るように多種多様である。かつこれらの情報はプロジェクトの作業の進捗に伴って変遷する。即ちプロジェクトの成果管理で心得ておかねばならないセンスは、プロジェクトのライフサイクルに亘っての作業項目 (図の横軸) に係る情報は勿論のこと、プロジェクトの実行成果の進捗に伴い管理情報が逐次変遷 (図の縦軸) して行くのを常に掌握しなければならない。
図 - D にプロジェクトの成果管理に係る情報の種類、それらのプロジェクトフェーズを跨いだ変遷などを例示する。

本項の視点での要求分析や要件設定は筆者としては緒に就いたばかりの段階である。今後これの推敲を重ねる何らかの形で発表したい。

図-D　Project Performance Management Process(参考)(デム研究所技術資料)
図 - D　Project Performance Management Process (参考) (デム研究所技術資料)
ページトップに戻る