赤字プロジェクトの増加は、ベンダーの業績を揺るがすまでになった。ベンダーは“個人”任せだったプロジェクトマネジメントを、“組織”レベルで体系化しようと必死だ。CMMI(能力成熟度モデル統合)を利用しつつ、現場に役立つ仕組みを確立しようする企業が増えている。
こうした動向をPart1で解説し、Part2で各社の取り組みを具体的に紹介する。日本IBMや富士通、NEC、NTTデータ、日立ソフトウェアエンジニアリング、東芝などの現場の活動を示す。

(鈴木 孝知)

この記事の「記者からもう一言」を読む
【記者の引き出し】掲載の関連記事(本特集の“予習”)[日経コンピュータ定期購読者限定ページ]を読む

Part1プロジェクト・マネジャを“組織で育てる”
Part2“押し付け”ではなく“支援”で現場を動かす


【無料】サンプル版を差し上げます本記事は日経コンピュータ2003年3月24日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。なお本号のご購入はバックナンバー、または日経コンピュータの定期ご購読をご利用ください。

Part1
プロジェクト・マネジャを“組織で育てる”

情報システム構築のプロジェクトの失敗例が増えている。プロジェクト・マネジャを取り巻く環境は厳しさを増すばかりだ。もはや、個人任せのマネジメントでは成功はおぼつかない。ITベンダーは場当たり的な対処をやめ標準プロセスを作成・改良している。CMMIという“教科書”を利用しつつ、現場で活用されるように工夫を凝らす。

 契約金額5億円で受注したプロジェクトの開発費が最終的に10億円にも達し、大赤字になってしまった」――。これはある大手国内ITベンダーのプロジェクト・マネジャがふと漏らした話である。続いて「最近は小粒のプロジェクトが多い。この5億円の赤字を埋めるためには、何十件ものプロジェクトを着実にこなさねばならないが、それだけやればまた失敗プロジェクトが出てくる。悪循環だ」と語り、ため息をついた。

 IT産業の低迷が続き、ベンダーの事業環境は厳しくなっている。「昔はハードを販売した利益でソフト開発の赤字を吸収できたが、今はハードの利幅が薄くなったので、とてもそんな余裕はない。従来のどんぶり勘定のコスト・マネジメントは、社内で認められなくなった」(NEC)。「本当に赤字プロジェクトが許されない時代になっている。泥沼のプロジェクトが数件でも出れば、事業部全体が赤字に陥りかねない」(日立製作所)。

 こうした悲鳴は、決して局所的なものではない。あらゆる国内ベンダーから聞こえてくる。この原因をたどると、最終的にはプロジェクト・マネジャの能力の不足とバラつきに行き着く。

利害関係の調整に追われる

図1●プロジェクトが“火を吹く”要因が多すぎて、プロジェクト・マネジャ個人では対処しきれなくなっている
 「企業統合の案件では、労働組合もステークホルダー(利害関係者)だ。労使交渉が進まずプロジェクトが足踏みすることがある」(日本IBM)。部門間や企業間のシステム連携が当たり前になり、ステークホルダーが増えた。その上、オープン化で複数のベンダーが参加し、短期で仕上げねばならない、というようにプロジェクトは複雑になる一方だ(図1[拡大表示])。そんな複雑な状況のなかで利害関係の調整に追われるベンダーが増えている。プロジェクトの難度は上がり、ベンダーのマネジャには高い能力が求められている。

 この背景には、ユーザー企業のプロジェクトマネジメント能力が落ちているという問題がある。従来、大手のユーザー企業は、自分自身でプロジェクトマネジメントを実施できる能力を持っていた。しかし、「大型プロジェクトを経験する機会がなくなったり情報システム部門が縮小されたりして、ユーザー企業のマネジメント能力が弱くなっている」と日立製作所の南野猛プロジェクトマネジメント本部公共・社会プロジェクトマネジメントエンジニアリング部長は指摘する。

(中略)

 もはやスーパーSEと言われる個人の“技”に頼ってはいられない。プロジェクト・マネジャの育成には、優れたマネジャのノウハウを組織的に抽出・蓄積し、企業全体でプロジェクトマネジメントの改善活動の基盤を作らねばならない(図2[拡大表示])。こうした「組織レベルのプロジェクトマネジメント」に国内ベンダーはようやく本腰を入れ始めた。

図2●組織全体で人とプロジェクトを支援する企業が増える。プロジェクト・マネジャ個人の努力に任せるだけでなく、組織的にプロジェクトマネジメントを実施することが必要になった

“現場が利用する”標準プロセスを作る

 国内ベンダーは「組織レベルのプロジェクトマネジメント」によって、赤字プロジェクトを繰り返すプロジェクト・マネジャの能力を一定水準以上に引き上げようとしている。これは従来のOJT(オン・ザ・ジョブ・トレーニング)といった個人レベルの取り組みでは難しかったことだ。そのため、組織全体のノウハウを盛り込んだ標準プロセスを新たに整備している。

 ベンダーは、標準プロセスを開発・改良するときにCMMI(能力成熟度モデル統合)を利用し始めた。日本IBMや日立製作所、日立ソフトウェアエンジニアリングなどが昨年、日本ユニシスや東芝などが今年に入ってから、相次いでCMMIを導入している。このほかにもCMMIへの取り組みを表明している企業は多い。

 ただし、作成した標準プロセスをプロジェクト・マネジャに順守してもらうのは、容易でない。「もともと自分なりのマネジメント手法を持っているからこそプロジェクト・マネジャを務められる」(日本ユニシスの服部克己サービスビジネス推進部CMMセンター長)からだ。

 しかもCMMIなどを使ってプロセス標準化・評価を推進してきた品質保証担当者とプロジェクト・マネジャは、仲が悪いことが少なくない。プロジェクト・マネジャが標準プロセスを受け入れるためには、人材育成やプロジェクト支援に直結する“役に立つ”仕組みを作ることが重要である(図4[拡大表示])。

“組織化”は世界的な潮流

図4●組織レベルのプロジェクトマネジメントを実践するのに必要なスキル。標準プロセス策定など知識面の強化にCMMIを利用する企業が増えた。そのプロセスを実現するためには、「経験」や「ビジネス・スキル」の強化など独自の取り組みが必要
 もともとプロジェクトマネジメントの関係者の間では、組織化は避けて通れない大きな課題になっていた。昨年後半から、富士通や日立製作所などの国内大手ベンダーが相次いで、プロジェクト・マネジャの実務を支援する組織「PMO(プロジェクトマネジメント・オフィス)」を設置し始めている。

 また、世界最大のプロジェクトマネジメント推進団体であるPMI(プロジェクトマネジメント・インスティチュート)は12月までに、「組織的プロジェクトマネジメント成熟度モデル(OPM3)」を策定する予定である。OPM3には、プロジェクトマネジメント手法の標準化、プロジェクトマネジメントに携わる組織の能力の測定、プロジェクトの実績の測定と評価、継続的改善を実施するためのガイドラインなどを盛り込む。CMMIのプロジェクトマネジメント版といった性格を持つ。

 PMOもOPM3も、まさに「組織レベルのプロジェクトマネジメント」の基準を整理し、実施する体制を整えようとするものである。つまり、これで個人レベルのプロジェクトマネジメントの限界を超えようとしている。

 では、なぜ組織レベルにする必要があるのか。現在のシステム構築計画は、複数のプロジェクトから成る場合が多く、構築計画全体の最適化を図る必要があるからだ。そのためには、どのプロジェクトを優先し、プロジェクト・マネジャや開発要員をどう配置するのか、といったことを最適化し、ときには素早く変更しなければならない。しかし、プロジェクト・マネジャの能力がバラバラだと、結局は優秀なプロジェクト・マネジャの時間に合わせた計画しか立てることができない。このような組織で、プロジェクト全体の最適化を図るのはほとんど不可能だ。

 また、個々のプロジェクトの進捗によっては、要員の追加や変更、ステークホルダーとの交渉などといった支援策を臨機応変に打ち出さねばならない。その際に、マネジメント手法が統一されていないと、現場の状況を把握するだけで時間がかかってしまい、対策が遅れてしまう。

プロジェクトマネジメントとCMMIを連携

 プロジェクトマネジメント学会前会長である日本IBMの冨永専務も、プロジェクトマネジメントを組織化する上で、「どのプロセスを改善すべきかを見つけられるCMMIは有効」と述べる。「組織的にプロジェクトマネジメントを実行するときに、CMMIという目標があるとわかりやすい。CMMIでプロセスを改革しようとすると、プロジェクトマネジメントと、プログラミングや開発手法といったソフトウエア・エンジニアリングの両方に取り組まねばならないことがわかる。それは取りも直さず、日本のIT業界に欠けていたことである」と指摘する。

 プロジェクトマネジメント学会の理事を務める千葉工業大学社会システム科学部プロジェクトマネジメント学科の関哲朗助教授も、「単一プロジェクトではなく企業・組織という視点で見た場合、CMMIとプロジェクトマネジメントを連携させることは有効だ。プロジェクトマネジメントとCMMIを比べて、どちらのカバー範囲が広いか、優れているのはどっちか、などという議論を聞くこともあるが、それは無意味」と語る。


続きは日経コンピュータ2003年3月24日号をお読み下さい。この号のご購入はバックナンバー、または日経コンピュータの定期ご購読をご利用ください。




 CMMI、ISO、標準プロセス、どんな言い方をしても、現場から嫌がられることには変わりはありません。

 ただし、現場のプロジェクト・マネジャやメンバーのなかには、自分一人でトラブルを解決できず、悩んでいる人たちがたくさんいます。企業は、そういう人を一人でも多く手助けできるように、努力して頂きたい。
 せっかくの標準プロセスを、「こうやらなければ、ダメなプロジェクト・マネジャだ」、「決めた通りにできなかったから、このプロジェクトはダメなんだ」という、現場を押さえ込むムチには決して使ってほしくない。

 CMMI、ISO、標準プロセスとは、現場が困っていることを解決できる仕組みのことです。会社が決めたやり方に従わせるため、もしくは受注を獲得するための道具ではありません。

 CMMIやISO、標準プロセスを導入しようとしている経営者、推進担当者で、「現場が受け入れてくれない」、「CMMIやISOは形骸化した規格」だと悩んでいる方がいらっしゃったら、この間違いをおかしていないか、再度確認してみてください。

 そして、もし、現場が困っていることを解決できる仕組みを作ろうとしている会社があったならば、現場の方々もなるべくうまく行くように協力してあげてください。(鈴木 孝知)