[1] [7]
[6]
[4]
[3] [5]
[2]
[1]スコープ定義
[2]蓄積されたプロジェクト実績データ [3]進捗データの配付
[4]プロジェクトマネジメント･チームによるコントロール [5]公式のコミュニケーション･チャネル
[6]カレント･ベスト･プラクティス [7]プロシージャー･マニュアル
へ伝達すればよいのかを理解することができる。
ワークフローはまた、メンバーがプロジェクトを通じて獲得した行動様式を明文化する ことにより、それまで個人の暗黙知であったプロジェクトマネジメントのノウハウを｢組織 の知的資源｣として蓄積･共有することができる。
〔２〕再定義した構成要素間の関係
ここでは、上図に示した概念モデルの構成要素を結びつける矢印の意味について説明す る。
[1] スコープ定義
スコープ定義においては当初の内容との差異はない。ただしプロジェクト･スコープの 語意には、(1)プロジェクトの成果物を生み出す作業 と(2)これらの作業を統合または調整 するマネジメント業務 の２つの仕事が併存していると考えられる。プロジェクトを立ち上 げる際には、プロジェクトの目的と最終成果物ならびに要求事項や制約条件を考慮したう えで、プロジェクトの要素成果物とそれを創出するプロジェクト･スコープをＷＢＳ要素と して定義する必要がある。
[2] 蓄積されたプロジェクト実績データ
ワークパッケージの完了時あるいはプロジェクトの終結時において、プロジェクトデー タを保存･共有することである。そうすることにより、ワークパッケージ･レベルで類似す るスコープの実績を参照することが可能となり、見積りの精度を向上させることができる。
またリニューアル(Renewal)に際しても、過去のリソース要件を知る手掛かりとなる。
[3] 進捗データの配付
進捗データの配付については、当初の定義と同意である。
[4] プロジェクトマネジメント･チームによるコントロール
これも基本的には、以前の内容と変わりはない。なお、プロジェクトとＯＢＳに架かる 矢印の両端に鏃が付いているのは、以前の枠組みにある｢プロジェクトを通じて獲得したノ ウハウ｣で説明した行動事象が、ここで生起していると推考したからである。それに加えて、
プロジェクトマネジメント･チームのメンバーがステークホルダーと交流し、ＷＢＳ要素毎 にパフォーマンスを測定したデータに基づいて意思疎通をはかることで｢場｣が形成される と考えられる。さらには、メンバー間の｢情報的相互作用｣を活性化することにより、プロ ジェクト全体(マクロレベル)の情報が秩序化され、結果として組織全体としての協働が生 まれやすくなる。
[5] 公式のコミュニケーション･チャネル
ＯＢＳ(マトリックス組織)の構造に起因する問題点として、二重の権限関係から生じる 組織内部の緊張関係が挙げられる。ワークフローでは、ＯＢＳの成員が当該プロジェクト に関する活動を行なう際にはプロジェクトマネジャーに従属し、彼がプロジェクト以外の 活動を行なう場合には、職能部門長に属するという｢命令一元性の原理｣を適用することで、
コンフリクトの発生を未然に防いでいる。
さらに、階層構造による垂直的コミュニケーション･チャネルに加えて、非公式である ことが多かった水平的チャネルを公式化することにより、ＯＢＳ内の情報の整合性と処理 量を能率化するだけでなく、アクティビティ(イベント)間の調整を改善することができる。
またワークフローからＯＢＳへ向かう矢印は、マトリックス組織の編成後もプロジェクト 内外環境の変化に応じて公式の情報伝達ルートを変更できることを示している。
[6] プロジェクトマネジメントのカレント･ベスト･プラクティス
現時点における最も効果的･効率的なプロジェクトマネジメントの実践方法は、ワーク フローに記録･蓄積されていることが事例研究から明らかとなった。ＯＢＳからワークフロ ーへ向かう矢印は、個人の経験で積み重ねられたノウハウを組織の標準的なビジネス･プロ セスとして定式化し、それらを組織の知的経営資源とすることでプロジェクトマネジメン トの質の向上を図ることを意味している。
[7] プロジェクトマネジメントのプロシージャー･マニュアル(Procedure Manual) ワークフローには、プロジェクト･フェーズごとに実施するアクティビティと情報処理 の手順が記載されている。プロジェクトマネジメント･チームのメンバーおよび母体組織の 成員は、それを参考にすることで自身の職位や権限に則して進行中のプロジェクトで担当 する職務を確認することができる。加えて、情報の伝達先を可能な限り明細にすることで、
成員間のコンフリクトを防除している。
５.５.４. 研究課題４の論考から導出される仮説命題
この論文の第４の研究課題は、｢ＷＢＳとＯＢＳのあいだには、その編成過程とコミュ ニケーションの観点からどのような特徴があるのだろうか｣であった。そこで、ＯＢＳの組 織構造とコミュニケーションの観点からＷＢＳとの関連性について考察した。
事例研究からは、ＷＢＳの階層とＯＢＳの階層構造がデータ授受の視点から整合するこ とが確認できた。そこでは、各自が担当するＷＢＳレベルのデータを集計して、上位のＷ ＢＳレベルで報告することになっていた。このようにＷＢＳの階層構造は、そこで管理す るデータとそれを利用する職位を結び付けることができるということである。
次に、既存研究からは、ステークホルダーとの意思疎通や情報伝達にＷＢＳを利用して いたことが確認できた。そこでは、ＷＢＳはプロジェクトを遂行する組織内で利用するだ
けでなく、組織間の情報伝達のためのツールとしても利用できるということであった。こ れと同じようなことは、事例研究においても確認することができた。例えば、日本下水道 事業団のＷＢＳは、以下のような利用がなされていた。
(1)プロジェクトの要 素成果物と それを生成 するための アクティビ ティとコス トおよび スケジュールを確認するための管理項目
(2)プロジェクトマネジメント業務を支援するための情報のキャリアー (3)複数の外部組織のあいだで通用する共通言語
日本下水道事業団では、プロジェクト情報を早く正確に伝達する目的から、プロジェク トマネジメント･チームを起点とするステークホルダーとのコミュニケーション活動でＷ ＢＳを利用していた。このことは、エクスターナルＷＢＳによるコミュニケーション･チャ ネルの構築が、ＯＢＳを中心とするハブ･アンド･スポーク型で設計されることを示唆して いる。
｢プ ロ ジ ェ ク ト を 通 じ て 獲 得 し た 知 識 が Ｗ Ｂ Ｓ を 介 し て 組 織 に 蓄 積 さ れ る の か ｣と い っ た問いについては、『ワークフロー』の比較分析と職員へのインタビュー調査から、そのよ うな事実を確認することはできなかった。ワークフローに追記されていたのは、プロジェ クトマネジャーがステークホルダーとの接触を通じて体得した行動様式であり、彼らはそ れをプロジェクトマネジメントの知的資源として共有していた。このほか、プロジェクト マネジメント導入の有効性を評価する社内アンケート調査からは、回答者の７割が｢コス ト･スケジュールの把握｣や｢協定金額の見積り精度｣が改善されたと評価していた。このこ とは、ＷＢＳの有効性を裏付けるものと理解できる。
以上のことから、コミュニケーション･ツールとしてのＷＢＳの実用性においては、以 下のような仮説命題が導き出される。
[1]ＷＢＳ要素で管理するデータとそれを利用するＯＢＳの職位を一致させておけば、組 織階層における情報処理の負荷を軽減することができる。
[2]要素成果物の識別符としてＷＢＳ(コード)を利用すれば、ステークホルダー間の共通 言語として通用できるようになる。
[3]エクスターナルＷＢＳによるコミュニケーション･チャネルの設計は、ＯＢＳを起点 とするホイール型もしくはハブ･アンド･スポーク型で構築するとよい。
５.６. 複雑な仕事を分けるための簡単なルール
本節における研究課題は、｢ＷＢＳはプロジェクトやＯＢＳの特性をどのように反映し ているか｣である。５.４.において、ＷＢＳはプロジェクトの要素成果物を作製するのに必 要なリソースやアクティビティを定義し、それらを適切に管理するための仕事の枠組みを 提供することが明らかにできた。ここでは、ＷＢＳの構成要素を類別する基準を探索する ことと、ワークパッケージを定義する指標を解明することを目指す。プロジェクトの最終
成果物を細分化するルールとＷＢＳの階層構造との関係を理解する見識が提示できれば、
ＷＢＳの開発はより適確で簡易になると思われる。
以下の項では、ＷＢＳの階層構造を規定する属性の観点から、プロジェクトを細分化す るためのルールとＷＢＳ要素の抜け洩れを未然に防ぐ方法について考察していく。
５.６.１. ＷＢＳの階層数を制約するもの
５.５.２.で明らかにしたように、ＷＢＳはプロジェクトマネジャーとオーナーとのあ いだで、プロジェクト･スコープの共通認識を深めるために用いられていた。そこでは、マ スタースケジュールに記載されたワークパッケージごとにプロジェクトの対象施設とそれ を建造するためのアクティビティ(工事),コストおよびスケジュールが明示されており、オ ーナーはプロジェクト全体の概略を要素成果物と作業の視点から把握することができた。
このように、プロジェクトの進捗状況を地方公共団体に報告する業務形態を日本下水道事 業 団 で は ｢ オ ー ナ ー ズ Ｐ Ｍ ｣ と 称 し て い た 。 オ ー ナ ー ズ Ｐ Ｍ (Owner’s Project Management)とは、地方公共団体から委託を受けて、日本下水道事業団が下水道施設の 設計と工事の監督管理および維持管理などを代行するプロジェクトマネジメント(ＰＭ)の 形態を指している。それゆえ、日本下水道事業団ではＷＢＳを介してプロジェクトの進捗 状況を報告する経路によって、独自のプロジェクトマネジメント機構を構築していたとい える。
このほかには、ＪＳ標準ＷＢＳの階層は事業費の見積体系と一致していたことが挙げら れる。４.２.４.においては、ＷＢＳの最下層である５〜６レベルに調達もしくは外注する 役務や資機材の金額を入力することで｢見積項目明細仕様｣と称する詳細見積を完成させて いた。そしてこれらを集計し、４レベルのパッケージで発生する間接費を加算したのが｢見 積項目明細｣であった。マスタースケジュールに記載されたワークパッケージごとの事業費 は、４レベルの見積項目明細に諸経費を加法して算定されたものであった。ＷＢＳの階層 数が積算細目と関連していることを窺わせる発見事実は、｢見積りの詳細のレベルは、正確 さとその金額への信頼を反映しており、ＷＢＳの階層数の視点から詳細事項が定義される
(11)｣という、SmithとMandakovic(1985)の主張とも整合している。
Prentis(1989)によると、｢もし、ＷＢＳのワークパッケージの数やレベル(階層)が充分 でないと、計画やコントロールが難しくなる。[……] 1)プロジェクトの複雑性や技術的な 要求が高まるほど、ＷＢＳの階層とワークパッケージの数が多くなる。2)プロジェクトの コストや期間が増すほど、ＷＢＳの階層とワークパッケージの数が多くなる(12)｣という。
この引用は、｢ＷＢＳの階層数とワークパッケージの数は、プロジェクトの複雑性とその規 模(コストと所要期間)に比例して増加する｣ことを指摘している。それでは、このことは事 例研究で扱った｢ＪＳ標準ＷＢＳ｣にも当て嵌まるのであろうか。
まず、プロジェクトの複雑性とは、プロジェクトで創出される成果物に必要な要素が複 雑に絡み合っている様相であり、プロジェクトの諸状況を事前に予測することが困難な状