2011年11月号
SOLE
SOLE
プロジェクトマネジメントの知識体系ＰＭＢＯＫから考えるＳＩ業界の課題
69 NOVEMBER 2011
SOLE 日本支部フォーラムの報告
The International Society of Logistics
プロジェクトマネジメントの知
識体系「Ｐ Ｍ Ｂ Ｏ Ｋ（Project
Management Body of Knowledge）」
によって、システムインテグレーショ
ン（ＳＩ）業界のプロジェクトマネジメ
ントの水準は大きく底上げされた。
Ｐ ＭＢＯＫは幅広いプロジェクトに適用 できる普遍的なマネジメント基盤であ り、各業界の経験と英知の集大成だ。
その知識を改めて整理すると、開発 期間や顧客企業との意思共有、技術 管理など、ＳＩプロジェクトのさらな る課題が見えてきた。
（ＳＥＴソフトウェア 河野誠二） 各業界の経験と英知の集大成 ＰＭＢＯＫの発展と浸透により、 ＳＩプロジェクトのマネジメントへの 関心が高まっている。
しかも発注者 側と供給者側の両方から、さらには 同じ基礎を共有して発展しているこ とは大変望ましいことである。
ＳＩプロジェクトの観点からＰＭＢ ＯＫの効果を整理してみると、次の ことが言えると考える。
まず第一に、プロジェクトの経験と 英知を各分野から集めたものという ことである。
ＳＩ業界よりもはるか 以前からプロジェクトで仕事をしてき た業界は多くあり、それらの業界か らプロジェクトマネジメントを学ぶこ とができることは、ＳＩ業界にとっ て何ものにも変えがたい幸せと言うべ きである。
思い返せば、ＳＩプロジェクトのプ ロセス、すなわち、要件定義、設計、 製造（プログラミング）、テスト等の エンジニアリング工程については、製 造業という大先輩からもっと早く多く を学ぶべきであったと思わざるを得な い。
しかしプロジェクトマネジメント については他の主だった業界からその エッセンスを得ることができた。
第二にプロジェクトマネジメントと いう一見とらえどころのないものに ついて、多くの関連技術から厳選し た九つの知識エリア、すなわち ?総合管理 ?スコープ・マネジメント ?タイム・マネジメント ?コスト・マネジメント ?品質マネジメント ?人的資源マネジメント ?コミュニケーション・マネジメント ?リスク・マネジメント ?調達マネジメント に集約されて体系が提示されたこと である。
マネジメントにはいろいろな要素が あり得る。
プロジェクトの種類によっ ても異なるし、またプロジェクトの規 模によっても個々の要素の強弱は大い に異なる。
さらに個々の要素は単独で はあり得ず、相互に関連し合っている のが通常であり、そのことも整理し 難い要因である。
これまでも多くの 議論がなされたにも拘わらず、結局 は個々人の経験に基づくものに留まっ ており、包括的に理解されるような 形にはなっていなかった。
これまでのプロジェクトマネジメン トの議論では、エンジニアリング・プ ロセスをなぞるものや会計的視点から の言及、または人と人との関係におけ る情緒的な面からのリーダーシップ的 な視点（ことに日本では受けがよかっ たように思われる）などいろいろな 面からの示唆があり、それぞれなる ほどと思われる一面がある。
しかし 一方で、それですべて足りるかとい うと不安もしくは不満が残ったのも事 実であった。
そこに九つの知識エリアとして体系 化されたプロジェクトマネジメント論 が、多くの業界の多くの経験を裏付 けとして提示された。
これは納得感 とともに、ともかくこの九つを実行 すればある程度のマネジメントができ るという安心感や期待感を与えた。
第三に、九つの知識エリア毎に、 その概念と合わせて実践するための 理解が得られるよう、インプット、ツ ール、アウトプットの三要素で構成さ れた説明が施されていることである。
マネジメントの真髄は簡単には理解し づらいものとして語られ、見よう見 まねでやった結果の経験からのみ得 られると考えられたことからすれば、 実践的で実務的、理解から実践への 壁を非常に低くした。
最後にＰ Ｍ Ｂ Ｏ Ｋそのもので はないが、Ｐ Ｍ Ｂ Ｏ Ｋをベースに した国際資格「Ｐ Ｍ Ｐ（Project Management Professional）」である。
資格試験については賛否両論あるか と思う。
しかしこの試験によって、Ｐ ＭＢＯＫを十分に理解した人が相当 数生まれたという事実には大きな意 味がある。
マネジメントはそれがどのような対 プロジェクトマネジメントの知識体系 ＰＭＢＯＫから考えるＳＩ業界の課題 NOVEMBER 2011 70 目標であるシステムがプロジェクト構 造の基本要素であることは自然なこ とに思われる。
三つ目の基本要素はあるか、ある とすれば何か。
第一要素の意思から 第二要素のシステムが生まれる、もし くは変換するために不可欠な要素は 人、すなわちプロジェクト・チームで ある。
遠い未来において、要求者が マイクに向かって欲しいシステムの要 件を録音すると翌朝までに自動的に システムができている、などという時 代が来るかもしれないが、今のとこ ろ意思から具体的なシステムへ変換で きるのは人だけである。
そう考える と、第三の基本要素として人、もし くはチームを加えるべきと考えた。
これで、プロジェクトは三つの基本 要素を持った構造として見ることが できる。
意思─システム─チームであ る（図１）。
ほかにも重要な要素がな いとは言えない。
今たちまちには思 プロジェクトの基本構造とは まずプロジェクトマネジメントの九 つの要素を再確認するために、プロジ ェクトマネジメントを再度理解し直そ うと考えた。
そのために、プロジェク トの構造を改めて問い直してみた。
プロジェクトはどこから始まるの か？ ＳＩプロジェクトでは多くの場 合、顧客企業の事業計画等が直接の 上位目的としてあり、その目的を達 成する手段としてコンピューターシス テムの導入や改修（機能強化など）が 発案される。
すなわちそこには何ら かの目的と目標を持った意思が存在す る。
事業をこうしたい、サービスをもっ とよくしたい、早く処理したい、効 率よくコストを抑えたい、等々将来 に向けての構想があり、それを実現 したいという意思がプロジェクトの根 源にある。
それがプロジェクトの第一 の基本要素であり、プロジェクトの開 始点は意思そのものであると考えた。
二つ目の基本要素は何か、第一要 素の意思からつながっているものは何 かと考えてみると、システムそのもの であろうと考えた。
システムとは意思 が目的達成のために手段として選択 したものであり、プロジェクトの結果 として生まれるものである。
または 未来の姿である。
ＳＩプロジェクトの 象であれ、個人個人の経験によるも のとされ、同じ仕事を共同で実施し た仲間であれば分かり合えるが、そ うでなければ理解し合うこと自体に困 難を感じていた。
そもそもマネジメン トまたはマネジメントの個々の要素に 対する概念が異なるため、理解し合 いかつ理解を深めるためのコミュニケ ーションが成り立たない。
そこに試験そのものに功罪がある とはいえ、ＰＭＰによってＰＭＢＯ Ｋを理解する人が増えてきたことに より、多くの前提を置かずともプロ ジェクトマネジメントの会話が成り立 つようになってきた。
例えば本稿で も何気なく使っている「コミュニケー ション」や「リスク」等の言葉は本 来は非常に幅の広い意味を持ってい るが、ことＰＭＢＯＫをベースにし て会話する上では、コミュニケーショ ン・マネジメントやリスク・マネジメ ントの意味をそれほど違えることな く議論し合える状況が生まれた。
これらのことからだけでも、ＳＩ 業界全体がＰＭＢＯＫによって得ら れた利益は非常に大きい。
さらなる活用可能性を探る しかし、それで十分かという疑問 が筆者の中にはくすぶっていた。
ＰＭ ＢＯＫのについての重要性は理解で きるし、そのどれ一つをとっても不要 と思われるものはない。
無論、個々 のプロジェクトに適用する場合にはそ の必要性の強弱があり得るが、恒久 的に不要と考えられる知識エリアはな い。
それぞれ必要なものである。
た だＰＭＢＯＫには九つの知識エリアが 突如として、あるいは既定事実であ るかのように提示される。
なぜ九つ の知識エリアであるか、それ以上でも 以下でもないか、についてはつまび らかではない。
想像するに、いろいろな業界の有 志による経験とノウハウの集大成で あるＰＭＢＯＫを構想する段階では もっと多種多様なマネジメント課題が 提示されたであろうが、それらを整 理・統合し、また特定の業界によら ず、普遍的な、最も重要な知識エリ アとして厳選したものがこの九つの 知識エリアであろうと思われる。
とするなら、ことＳＩプロジェク トにおけるプロジェクトマネジメント の観点からもう一度見直してみたら、 多少違ったように見えるかもしれない。
九つの知識エリアがなくなることはな いにしても、いくつかＳＩプロジェク トに固有なものとしてのマネジメント 要素が発見できる可能性もある。
ま た、そうした考察から、なぜ九つの 知識エリアが重要であるかのヒントが 得られるかもしれない。
そう考えた ことが本稿執筆のきっかけとなった。
意 思 チームシステム 図１ プロジェクトは意思、チー ム、システムの３つの基本要素か ら構成される 71 NOVEMBER 2011 しかしながら、意思の共有の重要 性が少なくなるわけではない。
ＰＭ ＢＯＫでもコミュニケーション・マネ ジメントによるステークホルダーとの 関係構築の重要性は繰り返し強調さ れているし、さらに版を重ねる毎に その主張はより強くなってきている。
先に意思とシステムをつなぐものと してＷＢＳを挙げたが、ＷＢＳと「共 有」ではコンセプトとしてバランスが 取れていない。
このため、「共有」と いう言葉あるいは概念が意思とチーム をつなぐ関係として適切なのかにつ いてはまだ再考の余地があると思わ れるが、ここはいったん「共有」を 置いて進めてみる。
なおチームに直接関係する知識エリ アとして、人的資源マネジメントと調 達マネジメントがある。
共有にはコミ ュニケーション・マネジメントが直接 関連する。
チームとシステムの関係 チームとシステムの関係はどのよう なものか。
まずベクトルがどちらに向 かっているのかが気になった。
意思 はすべてにおいて開始点であるから、 素直に意思からシステムへ、また意思 からチームへとベクトルが向かってい るとしたが、チームとシステムはどう だろうか。
そこで思い出したのは、「組織は戦 システムの間にＷＢＳを置いてみると、 これに関連していくつかのＰＭＢＯ Ｋの知識エリアが紐付けされること に気がつく。
スコープ・マネジメント、 タイム・マネジメントおよびコスト・ マネジメントである。
これらのマネジ メント領域はＷＢＳによって関連付け られ統合され、プロジェクトの基本計 画を形作る。
意思からチームへ 同様に、意思とチームの関係を 考えてみた。
チームは意思を理解し、 受け継ぎ、意思に代わって（意思を 持っている人に代わって）システムを 設計し、製造する。
とすると意思と チームは一種の運命共同体のように目 標を共有する仲間ではないか。
目的 や目標を共有して、意思が思い描く システムを具体的に実現していくのが チームである。
そこで、意思とチーム をつなぐものとして「共有」をおい てみた（図３）。
ＳＩプロジェクトの場合には、共 有したはずのものを形にした契約を取 り交わし、実際には契約に沿って仕事 が行われる。
そのため意思の共有と いう面は契約という形に置き換えられ、 それ以降は意思の共有のための努力 が薄くなっていることが多い。
費用と いう現実的な問題を同時に解決する必 要に迫られるためということもある。
いるものはＷＢＳ（Work Breakdown Structure）であろうと見当をつけた （図２）。
Ｐ Ｍ Ｂ Ｏ ＫではＷ Ｂ Ｓはスコー プ・マネジメントやタイム・マネジメ ントのツールに過ぎないが、実際にプ ロジェクトを実行する上でＷＢＳの役 割は大きい。
例えば計画の具体化で あり、見積もりの基礎であり、作業 指示であり、進捗の確認であり、問 題やリスクの発見であり、さまざまな 活動がこのＷＢＳに集約され表現さ れる。
したがって、ＷＢＳをもっと表に 出してもよいのではないか。
意思と いつかないだけかもしれないが、こ こは三つの要素が見いだせたことで よしとしたい。
三つの基本要素はそれぞれ関連が ある。
どのような関連があるかを次 に検討してみる。
意思からシステムへ 意思とシステムの関係は、「意思」 が思い描いているものが「システム」 であり、構想から具体化への変化で ある。
つまり時間の経過とともに変化 し、やがてシステムそのものを形作る。
そこで、意思とシステムの関係を時間 軸を通してプロジェクトの中で表して 意 思 チームシステム 図２ プロジェクトとWBS の関係。
意思とシステムをつ なぎ、各マネジメント領域を関連づける WBS スコープM タイムM コストM チームシステム 意 思 コミュニケーションM 共有 人的資源M 調達M 図３ 意思とチームを「共有」がつなぐ。
プロジェクトでは契約締 結後も意思の共有が非常に重要になる NOVEMBER 2011 72 ＳＩ業界への処方箋 意思、システム、チームをプロジ ェクトの基本要素としてそれぞれの関 連を調べる中から、ＰＭＢＯＫの知 識エリアとの関連も見えてきた。
ここ までのところ、関連付けでまだ出てい ないものとしては総合管理とリスク・ マネジメントが残っている。
これら二 つの知識エリアはその他のすべてに関 連するものであるので、意思とシステ ムとチームのトライアングルの中央に 位置づけるとよさそうである（図５）。
こうして改めて見ると、意思、シ ステム、チームというプロジェクトの 三つの基本要素とＰＭＢＯＫの知識 エリアの関連が分かり、やはりＰＭＢ ＯＫの定義している知識エリアはプロ ジェクトマネジメントにおいて重要な 要素であることが理解できる。
その 上で、ＳＩプロジェクトにおけるプロ ジェクトマネジメントでは技術管理に ついて検討していくことがさらなる 発展に寄与すると考えられる。
ＳＩ業界ではスピードアップ、コ ストダウン、高品質の要求に加え、 安全性（セキュリティ）、標準化等の 要請が日増しに厳しくなっている。
ま た、海外でのオフショア開発の圧力か ら、エンジニアの実勢単価レベルは落 ちている。
そのようなビジネス環境に おいて競争力をつけていくには、契 トにとってＰＭＢＯＫに不足がある とするなら、技術管理ではないかと 思われる。
ＳＩプロジェクトで必要になる技術 として、まずプロセスモデルとその各 工程で使われる技術がある。
設計技 術やプログラミング技術、テスト技術 などである。
図４にそれらを総合し てプロセスモデルと記した。
加えてド メイン技術も必要になる。
経理システ ムであれば、管理会計の知識・技術 が必要である。
その他に構成管理や 品質管理も重要である。
なお、品質は結果としてはシステム そのものに関係するが、品質を作り 込むという意味では、むしろ構築戦 略に紐づけるほうが理にかなうと考え た。
必要な技術がある程度明確である等、 状況が異なることから、各業界でそ れぞれ必要に応じて管理するよう任さ れることになったのではないか。
一方ＳＩプロジェクトでは、多種 多様なシステムが存在し開発と改修が 繰り返されている中で、ドメインが違 えばそこで必要な技術は大きく変わる。
単にＪａｖａ（プログラミング言語の 一つ）でプログラミングできれば事足 りるというものではない。
さらに実 際のプロジェクトの現場では、開発チ ームがそのシステムのドメイン技術に 精通している者だけで構成されるの は稀である。
したがって、そのプロジェクト を実行するために必要な技術は何 か、従事するメンバーはどれだけの 知識を持っているべきかについて事 前に整理し、トレーニングを計画す る等の施策はプロジェクトのＱＣＤ （Quality,Cost,Delivery）に大きく関 連する重大事である。
しかるに現実のＳＩプロジェクトで はこの点がまだ非常に弱い。
数名の経 験者による属人的な対応に依存して おり、その貴重な知識を十分に、ま た効果的に活用していないプロジェク トが多く存在する（もちろんこの点 を十分考慮して技術管理を行い、実 効果を上げているプロジェクトも一部 では存在する）。
もしＳＩプロジェク 略に従う」という言葉である。
この場 合の戦略とは目標となるシステムが分 かっているのだから、システムをいか に構築するかという「構築戦略」で はないかと考え、これをチームとシス テムの間に置いてみることにした。
し たがって、ベクトルはシステムからチ ームへと向かう。
チームは構築戦略に 沿って構成されるということになる。
構築戦略はシステムをいかに作るか であるから、技術的なさまざまな要 素を含む。
主なものとしてはインフラ （ハードウェアやＯＳ、ミドルウェア の選択と構成）、システム・アーキテ クチャ（ソフトウェアの基本構成、機 能分担の考え方等）、設計手法、プ ログラミング手法、テスト手法等の構 築技術に関するもの、それらの構築 作業をどのように進めるかの開発プロ セスの選択、技術管理、構成管理等 技術に関するマネジメントの技術内容 の整備等である。
この点に関してはＰＭＢＯＫには 関連するものが見当たらない。
技術 管理については意図的か否かは不明 だが、知識エリアに含まれていない。
想像するに、他の業界ではプロジェク トにおけるドメイン技術（特定顧客・ 業界のための技術）は相当高度に管 理されていたり、例えば建築業では 一級建築士のような資格と認可によ って相当なレベルを保証しているため 意 思 チーム 構築戦略 システム プロセスモデル品質M ドメイン技術の管理構成の管理 図４ チームとシステムの関係。
チームはシステムをい かに構築するかという「構築戦略」に沿って構成される 73 NOVEMBER 2011 約通りにプロジェクトを完了 させる以上の付加価値を創出 することが必要である。
これ らの課題について、意思─シ ステム─チームのトライアング ルから検討してみる。
意思とシステムの関係から は計画の正確さとそれを基礎 とした開発のスピードアップ が課題であろう。
どれだけ早 くシステムを構築できるかは、 顧客企業にとってますます重 要な要素になる。
またコスト をいかに低減するかについて は議論の余地がない。
意思とチームの関係から、 チームがどれだけ顧客企業、 特に経営層と視点を共有し、 システム構築に生かすことが できるかが問われる。
ある調査によ ると、システムで装備した機能のうち 全く使っていない機能は三〇〜五〇 ％、ほとんど使っていない機能は約 三〇％に上る。
裏を返せばよく利用 する機能は二〇〜三〇％程度に過ぎ ないという結果である。
顧客の責任 も同程度あるが、このような状況が あってなお、期間が短い、十分な予 算がないとこぼすのは議論の矛先が 違う。
ＳＩ業界からももっと進言す べきことがある。
さらにチームとシステムの関連では すでに述べたように、ＳＩプロジェク トにおいては技術管理によるプロジェ クト技術の高度化である。
これによ ってスピード、コスト、品質のいずれ をも強化する余地が、まだ十分にあ ると考える。
次回フォーラムのお知らせ 次回フォーラムは11月15日（火）、構造 計画研究所製造ビジネスソリューション部の 野本真輔技術担当部長による講演「ORソ リューション紹介／最上流から業務改革」を 予定している。
このフォーラムは年間計画 に基づいて運用しているが、単月のみの参 加も可能。
1回の参加費は6,000円。
ご希 望の方は事務局（ s-sogabe@mbb.nifty. ne.jp）までお問い合わせ下さい。
※ Ｓ Ｏ Ｌ Ｅ（The International Society of Logistics：国際ロジスティクス学会）は一 九六〇年代に設立されたロジスティクス団体。
米国に本部を置き、会員は五一カ国・三〇 〇〇〜三五〇〇人に及ぶ。
日本支部では毎 月「フォーラム」を開催し、講演、研究発表、 現場見学などを通じてロジスティクス・マネ ジメントに関する活発な意見交換、議論を行 っている。
意 思 チーム 構築戦略 システム プロセスモデル 人的資源M 調達M 品質M 総合M リスクM ドメイン技術の管理構成の管理 図５ プロジェクトの基本要素とPMBOK の知識エリアの全体像。
今後のプロ ジェクトマネジメントの発展に向けた課題が見えてくる WBS スコープM タイムM コストM 共有 コミュニケーションM
Ｐ ＭＢＯＫは幅広いプロジェクトに適用 できる普遍的なマネジメント基盤であ り、各業界の経験と英知の集大成だ。
その知識を改めて整理すると、開発 期間や顧客企業との意思共有、技術 管理など、ＳＩプロジェクトのさらな る課題が見えてきた。
（ＳＥＴソフトウェア 河野誠二） 各業界の経験と英知の集大成 ＰＭＢＯＫの発展と浸透により、 ＳＩプロジェクトのマネジメントへの 関心が高まっている。
しかも発注者 側と供給者側の両方から、さらには 同じ基礎を共有して発展しているこ とは大変望ましいことである。
ＳＩプロジェクトの観点からＰＭＢ ＯＫの効果を整理してみると、次の ことが言えると考える。
まず第一に、プロジェクトの経験と 英知を各分野から集めたものという ことである。
ＳＩ業界よりもはるか 以前からプロジェクトで仕事をしてき た業界は多くあり、それらの業界か らプロジェクトマネジメントを学ぶこ とができることは、ＳＩ業界にとっ て何ものにも変えがたい幸せと言うべ きである。
思い返せば、ＳＩプロジェクトのプ ロセス、すなわち、要件定義、設計、 製造（プログラミング）、テスト等の エンジニアリング工程については、製 造業という大先輩からもっと早く多く を学ぶべきであったと思わざるを得な い。
しかしプロジェクトマネジメント については他の主だった業界からその エッセンスを得ることができた。
第二にプロジェクトマネジメントと いう一見とらえどころのないものに ついて、多くの関連技術から厳選し た九つの知識エリア、すなわち ?総合管理 ?スコープ・マネジメント ?タイム・マネジメント ?コスト・マネジメント ?品質マネジメント ?人的資源マネジメント ?コミュニケーション・マネジメント ?リスク・マネジメント ?調達マネジメント に集約されて体系が提示されたこと である。
マネジメントにはいろいろな要素が あり得る。
プロジェクトの種類によっ ても異なるし、またプロジェクトの規 模によっても個々の要素の強弱は大い に異なる。
さらに個々の要素は単独で はあり得ず、相互に関連し合っている のが通常であり、そのことも整理し 難い要因である。
これまでも多くの 議論がなされたにも拘わらず、結局 は個々人の経験に基づくものに留まっ ており、包括的に理解されるような 形にはなっていなかった。
これまでのプロジェクトマネジメン トの議論では、エンジニアリング・プ ロセスをなぞるものや会計的視点から の言及、または人と人との関係におけ る情緒的な面からのリーダーシップ的 な視点（ことに日本では受けがよかっ たように思われる）などいろいろな 面からの示唆があり、それぞれなる ほどと思われる一面がある。
しかし 一方で、それですべて足りるかとい うと不安もしくは不満が残ったのも事 実であった。
そこに九つの知識エリアとして体系 化されたプロジェクトマネジメント論 が、多くの業界の多くの経験を裏付 けとして提示された。
これは納得感 とともに、ともかくこの九つを実行 すればある程度のマネジメントができ るという安心感や期待感を与えた。
第三に、九つの知識エリア毎に、 その概念と合わせて実践するための 理解が得られるよう、インプット、ツ ール、アウトプットの三要素で構成さ れた説明が施されていることである。
マネジメントの真髄は簡単には理解し づらいものとして語られ、見よう見 まねでやった結果の経験からのみ得 られると考えられたことからすれば、 実践的で実務的、理解から実践への 壁を非常に低くした。
最後にＰ Ｍ Ｂ Ｏ Ｋそのもので はないが、Ｐ Ｍ Ｂ Ｏ Ｋをベースに した国際資格「Ｐ Ｍ Ｐ（Project Management Professional）」である。
資格試験については賛否両論あるか と思う。
しかしこの試験によって、Ｐ ＭＢＯＫを十分に理解した人が相当 数生まれたという事実には大きな意 味がある。
マネジメントはそれがどのような対 プロジェクトマネジメントの知識体系 ＰＭＢＯＫから考えるＳＩ業界の課題 NOVEMBER 2011 70 目標であるシステムがプロジェクト構 造の基本要素であることは自然なこ とに思われる。
三つ目の基本要素はあるか、ある とすれば何か。
第一要素の意思から 第二要素のシステムが生まれる、もし くは変換するために不可欠な要素は 人、すなわちプロジェクト・チームで ある。
遠い未来において、要求者が マイクに向かって欲しいシステムの要 件を録音すると翌朝までに自動的に システムができている、などという時 代が来るかもしれないが、今のとこ ろ意思から具体的なシステムへ変換で きるのは人だけである。
そう考える と、第三の基本要素として人、もし くはチームを加えるべきと考えた。
これで、プロジェクトは三つの基本 要素を持った構造として見ることが できる。
意思─システム─チームであ る（図１）。
ほかにも重要な要素がな いとは言えない。
今たちまちには思 プロジェクトの基本構造とは まずプロジェクトマネジメントの九 つの要素を再確認するために、プロジ ェクトマネジメントを再度理解し直そ うと考えた。
そのために、プロジェク トの構造を改めて問い直してみた。
プロジェクトはどこから始まるの か？ ＳＩプロジェクトでは多くの場 合、顧客企業の事業計画等が直接の 上位目的としてあり、その目的を達 成する手段としてコンピューターシス テムの導入や改修（機能強化など）が 発案される。
すなわちそこには何ら かの目的と目標を持った意思が存在す る。
事業をこうしたい、サービスをもっ とよくしたい、早く処理したい、効 率よくコストを抑えたい、等々将来 に向けての構想があり、それを実現 したいという意思がプロジェクトの根 源にある。
それがプロジェクトの第一 の基本要素であり、プロジェクトの開 始点は意思そのものであると考えた。
二つ目の基本要素は何か、第一要 素の意思からつながっているものは何 かと考えてみると、システムそのもの であろうと考えた。
システムとは意思 が目的達成のために手段として選択 したものであり、プロジェクトの結果 として生まれるものである。
または 未来の姿である。
ＳＩプロジェクトの 象であれ、個人個人の経験によるも のとされ、同じ仕事を共同で実施し た仲間であれば分かり合えるが、そ うでなければ理解し合うこと自体に困 難を感じていた。
そもそもマネジメン トまたはマネジメントの個々の要素に 対する概念が異なるため、理解し合 いかつ理解を深めるためのコミュニケ ーションが成り立たない。
そこに試験そのものに功罪がある とはいえ、ＰＭＰによってＰＭＢＯ Ｋを理解する人が増えてきたことに より、多くの前提を置かずともプロ ジェクトマネジメントの会話が成り立 つようになってきた。
例えば本稿で も何気なく使っている「コミュニケー ション」や「リスク」等の言葉は本 来は非常に幅の広い意味を持ってい るが、ことＰＭＢＯＫをベースにし て会話する上では、コミュニケーショ ン・マネジメントやリスク・マネジメ ントの意味をそれほど違えることな く議論し合える状況が生まれた。
これらのことからだけでも、ＳＩ 業界全体がＰＭＢＯＫによって得ら れた利益は非常に大きい。
さらなる活用可能性を探る しかし、それで十分かという疑問 が筆者の中にはくすぶっていた。
ＰＭ ＢＯＫのについての重要性は理解で きるし、そのどれ一つをとっても不要 と思われるものはない。
無論、個々 のプロジェクトに適用する場合にはそ の必要性の強弱があり得るが、恒久 的に不要と考えられる知識エリアはな い。
それぞれ必要なものである。
た だＰＭＢＯＫには九つの知識エリアが 突如として、あるいは既定事実であ るかのように提示される。
なぜ九つ の知識エリアであるか、それ以上でも 以下でもないか、についてはつまび らかではない。
想像するに、いろいろな業界の有 志による経験とノウハウの集大成で あるＰＭＢＯＫを構想する段階では もっと多種多様なマネジメント課題が 提示されたであろうが、それらを整 理・統合し、また特定の業界によら ず、普遍的な、最も重要な知識エリ アとして厳選したものがこの九つの 知識エリアであろうと思われる。
とするなら、ことＳＩプロジェク トにおけるプロジェクトマネジメント の観点からもう一度見直してみたら、 多少違ったように見えるかもしれない。
九つの知識エリアがなくなることはな いにしても、いくつかＳＩプロジェク トに固有なものとしてのマネジメント 要素が発見できる可能性もある。
ま た、そうした考察から、なぜ九つの 知識エリアが重要であるかのヒントが 得られるかもしれない。
そう考えた ことが本稿執筆のきっかけとなった。
意 思 チームシステム 図１ プロジェクトは意思、チー ム、システムの３つの基本要素か ら構成される 71 NOVEMBER 2011 しかしながら、意思の共有の重要 性が少なくなるわけではない。
ＰＭ ＢＯＫでもコミュニケーション・マネ ジメントによるステークホルダーとの 関係構築の重要性は繰り返し強調さ れているし、さらに版を重ねる毎に その主張はより強くなってきている。
先に意思とシステムをつなぐものと してＷＢＳを挙げたが、ＷＢＳと「共 有」ではコンセプトとしてバランスが 取れていない。
このため、「共有」と いう言葉あるいは概念が意思とチーム をつなぐ関係として適切なのかにつ いてはまだ再考の余地があると思わ れるが、ここはいったん「共有」を 置いて進めてみる。
なおチームに直接関係する知識エリ アとして、人的資源マネジメントと調 達マネジメントがある。
共有にはコミ ュニケーション・マネジメントが直接 関連する。
チームとシステムの関係 チームとシステムの関係はどのよう なものか。
まずベクトルがどちらに向 かっているのかが気になった。
意思 はすべてにおいて開始点であるから、 素直に意思からシステムへ、また意思 からチームへとベクトルが向かってい るとしたが、チームとシステムはどう だろうか。
そこで思い出したのは、「組織は戦 システムの間にＷＢＳを置いてみると、 これに関連していくつかのＰＭＢＯ Ｋの知識エリアが紐付けされること に気がつく。
スコープ・マネジメント、 タイム・マネジメントおよびコスト・ マネジメントである。
これらのマネジ メント領域はＷＢＳによって関連付け られ統合され、プロジェクトの基本計 画を形作る。
意思からチームへ 同様に、意思とチームの関係を 考えてみた。
チームは意思を理解し、 受け継ぎ、意思に代わって（意思を 持っている人に代わって）システムを 設計し、製造する。
とすると意思と チームは一種の運命共同体のように目 標を共有する仲間ではないか。
目的 や目標を共有して、意思が思い描く システムを具体的に実現していくのが チームである。
そこで、意思とチーム をつなぐものとして「共有」をおい てみた（図３）。
ＳＩプロジェクトの場合には、共 有したはずのものを形にした契約を取 り交わし、実際には契約に沿って仕事 が行われる。
そのため意思の共有と いう面は契約という形に置き換えられ、 それ以降は意思の共有のための努力 が薄くなっていることが多い。
費用と いう現実的な問題を同時に解決する必 要に迫られるためということもある。
いるものはＷＢＳ（Work Breakdown Structure）であろうと見当をつけた （図２）。
Ｐ Ｍ Ｂ Ｏ ＫではＷ Ｂ Ｓはスコー プ・マネジメントやタイム・マネジメ ントのツールに過ぎないが、実際にプ ロジェクトを実行する上でＷＢＳの役 割は大きい。
例えば計画の具体化で あり、見積もりの基礎であり、作業 指示であり、進捗の確認であり、問 題やリスクの発見であり、さまざまな 活動がこのＷＢＳに集約され表現さ れる。
したがって、ＷＢＳをもっと表に 出してもよいのではないか。
意思と いつかないだけかもしれないが、こ こは三つの要素が見いだせたことで よしとしたい。
三つの基本要素はそれぞれ関連が ある。
どのような関連があるかを次 に検討してみる。
意思からシステムへ 意思とシステムの関係は、「意思」 が思い描いているものが「システム」 であり、構想から具体化への変化で ある。
つまり時間の経過とともに変化 し、やがてシステムそのものを形作る。
そこで、意思とシステムの関係を時間 軸を通してプロジェクトの中で表して 意 思 チームシステム 図２ プロジェクトとWBS の関係。
意思とシステムをつ なぎ、各マネジメント領域を関連づける WBS スコープM タイムM コストM チームシステム 意 思 コミュニケーションM 共有 人的資源M 調達M 図３ 意思とチームを「共有」がつなぐ。
プロジェクトでは契約締 結後も意思の共有が非常に重要になる NOVEMBER 2011 72 ＳＩ業界への処方箋 意思、システム、チームをプロジ ェクトの基本要素としてそれぞれの関 連を調べる中から、ＰＭＢＯＫの知 識エリアとの関連も見えてきた。
ここ までのところ、関連付けでまだ出てい ないものとしては総合管理とリスク・ マネジメントが残っている。
これら二 つの知識エリアはその他のすべてに関 連するものであるので、意思とシステ ムとチームのトライアングルの中央に 位置づけるとよさそうである（図５）。
こうして改めて見ると、意思、シ ステム、チームというプロジェクトの 三つの基本要素とＰＭＢＯＫの知識 エリアの関連が分かり、やはりＰＭＢ ＯＫの定義している知識エリアはプロ ジェクトマネジメントにおいて重要な 要素であることが理解できる。
その 上で、ＳＩプロジェクトにおけるプロ ジェクトマネジメントでは技術管理に ついて検討していくことがさらなる 発展に寄与すると考えられる。
ＳＩ業界ではスピードアップ、コ ストダウン、高品質の要求に加え、 安全性（セキュリティ）、標準化等の 要請が日増しに厳しくなっている。
ま た、海外でのオフショア開発の圧力か ら、エンジニアの実勢単価レベルは落 ちている。
そのようなビジネス環境に おいて競争力をつけていくには、契 トにとってＰＭＢＯＫに不足がある とするなら、技術管理ではないかと 思われる。
ＳＩプロジェクトで必要になる技術 として、まずプロセスモデルとその各 工程で使われる技術がある。
設計技 術やプログラミング技術、テスト技術 などである。
図４にそれらを総合し てプロセスモデルと記した。
加えてド メイン技術も必要になる。
経理システ ムであれば、管理会計の知識・技術 が必要である。
その他に構成管理や 品質管理も重要である。
なお、品質は結果としてはシステム そのものに関係するが、品質を作り 込むという意味では、むしろ構築戦 略に紐づけるほうが理にかなうと考え た。
必要な技術がある程度明確である等、 状況が異なることから、各業界でそ れぞれ必要に応じて管理するよう任さ れることになったのではないか。
一方ＳＩプロジェクトでは、多種 多様なシステムが存在し開発と改修が 繰り返されている中で、ドメインが違 えばそこで必要な技術は大きく変わる。
単にＪａｖａ（プログラミング言語の 一つ）でプログラミングできれば事足 りるというものではない。
さらに実 際のプロジェクトの現場では、開発チ ームがそのシステムのドメイン技術に 精通している者だけで構成されるの は稀である。
したがって、そのプロジェクト を実行するために必要な技術は何 か、従事するメンバーはどれだけの 知識を持っているべきかについて事 前に整理し、トレーニングを計画す る等の施策はプロジェクトのＱＣＤ （Quality,Cost,Delivery）に大きく関 連する重大事である。
しかるに現実のＳＩプロジェクトで はこの点がまだ非常に弱い。
数名の経 験者による属人的な対応に依存して おり、その貴重な知識を十分に、ま た効果的に活用していないプロジェク トが多く存在する（もちろんこの点 を十分考慮して技術管理を行い、実 効果を上げているプロジェクトも一部 では存在する）。
もしＳＩプロジェク 略に従う」という言葉である。
この場 合の戦略とは目標となるシステムが分 かっているのだから、システムをいか に構築するかという「構築戦略」で はないかと考え、これをチームとシス テムの間に置いてみることにした。
し たがって、ベクトルはシステムからチ ームへと向かう。
チームは構築戦略に 沿って構成されるということになる。
構築戦略はシステムをいかに作るか であるから、技術的なさまざまな要 素を含む。
主なものとしてはインフラ （ハードウェアやＯＳ、ミドルウェア の選択と構成）、システム・アーキテ クチャ（ソフトウェアの基本構成、機 能分担の考え方等）、設計手法、プ ログラミング手法、テスト手法等の構 築技術に関するもの、それらの構築 作業をどのように進めるかの開発プロ セスの選択、技術管理、構成管理等 技術に関するマネジメントの技術内容 の整備等である。
この点に関してはＰＭＢＯＫには 関連するものが見当たらない。
技術 管理については意図的か否かは不明 だが、知識エリアに含まれていない。
想像するに、他の業界ではプロジェク トにおけるドメイン技術（特定顧客・ 業界のための技術）は相当高度に管 理されていたり、例えば建築業では 一級建築士のような資格と認可によ って相当なレベルを保証しているため 意 思 チーム 構築戦略 システム プロセスモデル品質M ドメイン技術の管理構成の管理 図４ チームとシステムの関係。
チームはシステムをい かに構築するかという「構築戦略」に沿って構成される 73 NOVEMBER 2011 約通りにプロジェクトを完了 させる以上の付加価値を創出 することが必要である。
これ らの課題について、意思─シ ステム─チームのトライアング ルから検討してみる。
意思とシステムの関係から は計画の正確さとそれを基礎 とした開発のスピードアップ が課題であろう。
どれだけ早 くシステムを構築できるかは、 顧客企業にとってますます重 要な要素になる。
またコスト をいかに低減するかについて は議論の余地がない。
意思とチームの関係から、 チームがどれだけ顧客企業、 特に経営層と視点を共有し、 システム構築に生かすことが できるかが問われる。
ある調査によ ると、システムで装備した機能のうち 全く使っていない機能は三〇〜五〇 ％、ほとんど使っていない機能は約 三〇％に上る。
裏を返せばよく利用 する機能は二〇〜三〇％程度に過ぎ ないという結果である。
顧客の責任 も同程度あるが、このような状況が あってなお、期間が短い、十分な予 算がないとこぼすのは議論の矛先が 違う。
ＳＩ業界からももっと進言す べきことがある。
さらにチームとシステムの関連では すでに述べたように、ＳＩプロジェク トにおいては技術管理によるプロジェ クト技術の高度化である。
これによ ってスピード、コスト、品質のいずれ をも強化する余地が、まだ十分にあ ると考える。
次回フォーラムのお知らせ 次回フォーラムは11月15日（火）、構造 計画研究所製造ビジネスソリューション部の 野本真輔技術担当部長による講演「ORソ リューション紹介／最上流から業務改革」を 予定している。
このフォーラムは年間計画 に基づいて運用しているが、単月のみの参 加も可能。
1回の参加費は6,000円。
ご希 望の方は事務局（ s-sogabe@mbb.nifty. ne.jp）までお問い合わせ下さい。
※ Ｓ Ｏ Ｌ Ｅ（The International Society of Logistics：国際ロジスティクス学会）は一 九六〇年代に設立されたロジスティクス団体。
米国に本部を置き、会員は五一カ国・三〇 〇〇〜三五〇〇人に及ぶ。
日本支部では毎 月「フォーラム」を開催し、講演、研究発表、 現場見学などを通じてロジスティクス・マネ ジメントに関する活発な意見交換、議論を行 っている。
意 思 チーム 構築戦略 システム プロセスモデル 人的資源M 調達M 品質M 総合M リスクM ドメイン技術の管理構成の管理 図５ プロジェクトの基本要素とPMBOK の知識エリアの全体像。
今後のプロ ジェクトマネジメントの発展に向けた課題が見えてくる WBS スコープM タイムM コストM 共有 コミュニケーションM