ITコンサルティング会社がかかわったシステム開発プロジェクトで今、様々な問題が起きている。ユーザー企業やシステム・インテグレータがITコンサルティング会社に批判の目を向けるようになった。ただし、システム開発ではユーザー企業に適切な支援が必要なのも確か。ITコンサルティング会社の実態をとらえ、活用の方策を探る。
|
本記事は日経コンピュータ2003年5月19日号からの抜粋です。そのため図や表が一部割愛されていることをあらかじめご了承ください。本「特集」の全文をお読みいただける【無料】サンプル版を差し上げます。お申込みはこちらでお受けしています。なお本号のご購入はバックナンバー、または日経コンピュータの定期ご購読をご利用ください。数億円という価格でユーザー企業の業務改革計画やシステム企画を請け負い、バインダーにまとめた報告書を提出する。あるいはバインダーにまとめたシステム企画に基づいて、ユーザー企業のシステムの設計、構築も手がける。場合によっては、システム開発の報酬は数十億円に達する。
こういったITコンサルティング会社のプロジェクトが、トラブルに直面するケースが増え始めた。
例えば、日本航空の整備業務の管理システムの開発が現在、難航している。開発にはコンサルティング会社のプライスウォーターハウスクーパース（PwC）コンサルティングが当たった。PwCは昨年11月に日本IBMのコンサルティング部門と合併、整備業務管理システムの開発は合併後のIBMビジネスコンサルティングサービス（IBCS）が引き継いだ。同プロジェクトにかかわる複数の関係者は「予定していた今年7月の本稼働は非常に難しい」という。
しんきん情報システムセンター（SSC）は、信用金庫業界の業界統一システムを作ろうとしたが、今年に入ってプロジェクトの中断に追い込まれた。SSCはフューチャーシステムコンサルティングの協力を仰いだが、成功しなかった。
もちろん成功するプロジェクトもあるが、ITコンサルティング会社がらみのトラブルが目立ってきたのも事実。本来なら成功請負人、企業参謀になるはずなのに、極端な場合にはシステムが完成しない。システムが稼働したとしても、稼働時期が当初の予定よりも大幅に遅れたり、10億円単位で開発コストが超過してしまうケースもある。
費用の膨張は構造的な問題
「甘い汁を吸うつもりだったとしか思えない」――あるユーザー企業の破綻プロジェクトの“火消し（トラブルの収拾）”に当たっているベンダーの技術者は、大手コンサルティング会社についてこう語った。
「システムに詳しくない経営トップを口説き大型案件に仕立てる、パッケージ選定ではニーズを無視して自社が扱っているものを勧める、システムのひな型を作るプロトタイピングの開発費用を必要以上に膨らませる、といったことが横行していた」と言う。
このように本来なら成功をもたらすはずのITコンサルティング会社が、実際にはプロジェクトを混乱させてしまう例は、決して珍しいことではない（図1[拡大表示]）。もちろん、すべてのプロジェクトが問題を抱えているわけではないが、ITコンサルティング会社がからむ案件は、「常にこういう事態に陥る危険性をはらんでいる」（大手システム・インテグレータ）。
 |
| 図1●ITコンサルティング失敗の構図 |
開発費用が簡単に膨らんでしまいがちなのは、構造的な問題があるからだ。ITコンサルティング会社は、ユーザー企業の経営トップにセールスをかけ、全社的な業務改善プロジェクトを立ち上げて、構想段階からかかわることが多い。
社の全権を握る経営トップを口説けば、プロジェクトの規模を肥大化させやすい。プロジェクトの途中でも、システムのひな型やカスタマイズ・ソフトを作る過程で，開発費用をかなり増大させることができる。
一方で現在、売り上げを伸ばすことに必死になっているコンサルティング会社は多い。特に、株式を上場したコンサルティング会社は、業績の拡大に注力せざるを得ない。コンサルティング会社の各プロジェクトの責任者であるパートナも、拡大する一方の予算の達成に追われている。予算を達成できないパートナは、会社を辞めなけらばならない。
性急な売り上げ拡大策は、コンサルティングの内容そのものにも必然的に悪影響を及ぼす。質より量を重視することになるからだ。もともとITコンサルティング会社は、ユーザー企業よりもその会社の業務に詳しいわけではない。頼めば必ず素晴らしい改革案を提供してくれるようなものでもない。大量のコンサルタントを投入してシステム開発に取りかかったにもかかわらず，プロジェクトを失敗させたコンサルティング会社は少なくない。
手の内を知って使いこなす
このような問題は一過性のものではない。背景には、コンサルタントの人数と勤務時間でコンサルティング会社の報酬が決まる、ユーザー企業が報告書の内容や出来上がったシステムなどの成果物を評価できない、といった業界全体の問題がある。
さらに、本来ならITコンサルティング会社を使いこなすべきユーザー企業も問題を抱えている。経営トップなどシステムに詳しくない担当者が、具体的なイメージがないままにシステムを使って業務改革を実行しようとするケースが増えている。こういった企業では、ばく然とITコンサルティング会社を利用して時間とカネを浪費してしまうことになりがちだ。
ではコンサルティング会社を利用しないことは可能か。そう簡単に片付けるわけにもいかない。経営戦略に沿ったプロジェクトの計画策定、開発期間や予算の見積もりの手法を知るユーザー企業は少ない。情報システムが経営と深く結びつき、技術的に複雑になるなかで、ユーザー企業が外部の専門的な知識を必要とする機会は増している。むしろITコンサルティング会社の重要性は高まっているのだ。
この特集では、コンサルティング業界の実態と問題点を分析し、ユーザー企業がとるべき対策を探る。
| “顧客軽視”に走りがち 失敗プロジェクトも相次ぐ |
ITコンサルティング会社に限らず、本来コンサルティング会社やコンサルタントは、ユーザーにない知識やノウハウを提供することで、対価を得るビジネスであるはずだ。しかし、ITコンサルティング会社の開発事例を見ると、本当にユーザー企業の課題を解決できる能力を提供しているのか疑問に思えるケースがある。
難航するe-整備プロジェクト
最近、問題が表れた例が、日本航空（JAL）が2001年度からスタートさせたe-整備プロジェクトである。稼働予定は今年7月だが、JAL関係者からはすでに「7月の稼働は難しい。いっそプロジェクトを中止してはどうか」という声も上がっている。
e-整備プロジェクトは、航空機の整備業務の管理システムを再構築して一元化するプロジェクト。主に独SAPのERPパッケージ（統合業務パッケージ）「R/3」を利用して、システムを構築する。JALは、昨年度末までの3年の中期経営計画で、積極的にIT化を進めるe-JAL構想を打ち出した。整備業務の管理を目的としたe-整備プロジェクトはもともと、e-JAL構想の一環として始まったものだった。
e-整備プロジェクトの導入を手がけているのは、IBMの子会社のIBCSである。同社の前身の一部である旧PwCコンサルティングが、整備業務の管理システムに利用できそうなテンプレートを扱った経験があることなどが評価されて、PwC主導でプロジェクトを進めることが決まったという。
だが、IBCSによる導入作業は難航している。本誌の取材を総合すると、プロジェクトの関係者にヒヤリングして要件を固め、R/3のプロトタイピングの作成までは進んでいる。しかし、プロトタイピングの結果を基にJALの部品管理システムを構築できない。
旧PwCコンサルティングは、R/3を使った会計システムの導入を中心に実績を重ねてきた。しかし、会計に比べて生産管理や販売管理、在庫管理や部品調達などは業務分析が難しい。ヒヤリングとプロトタイピングだけで、システムの仕様を固めようとしても、例外処理などが多く、実際のシステムにまとめきれないようだ。
航空会社の部品管理システムはかなり特殊である。部品点数の多さや、品質管理の厳しさなどの問題がある。例えばJALの整備部品は、空港内の倉庫ごとに管理している。こういった独自の業務処理を理解した上で、プロジェクトを進めていかなければならない。
旧PwCコンサルティングは公共・エネルギー・発電関係で実績のある部品調達システム用のテンプレートを流用すれば順調にシステム構築が進むだろうと考えたが、その“読み”がはずれた。このテンプレートに詳しい人間が少ないことも、プロジェクトの難航に拍車をかけている。
本誌の問い合わせに対し日本航空システム広報部からは、「現在、当社から50人、IBCSが150人のスタッフを投入してプロジェクトを真摯かつ慎重に進めている」という趣旨の回答があった。
IBCSは「顧客のことなので回答できない」としている。
続きは日経コンピュータ2003年5月19日号をお読み下さい。この号のご購入はバックナンバー、または日経コンピュータの定期ご購読をご利用ください。
