プロジェクトマネジメントの知識体系ＰＭＢＯＫから考えるＳＩ業界の課題[SOLE]：ロジスティクス・ビジネス[LOGI-BIZ]バックナンバー

2011年11号

*下記はPDFよりテキストを抽出したデータです。閲覧はPDFをご覧下さい。

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