注目の書籍

好評発売中!

IT業界徹底研究就職ガイド2013年版

IT/ネット業界で働くと いうことを分かりやす く解説。2013年3月卒 業の学生向けの1冊。

必聴講座ご紹介

Cloud Days Tokyo 2012
クラウド時代を勝ち抜く企業戦略を考える

エムオーテックス


Cloud Days Tokyo 2012
クラウド時代の企業インフラとユーザー環境の姿

ヴイエムウェア


Cloud Days Osaka 2012
クラウドでIT維新を〜ビジネスを加速させるベストプラクティス

アマゾン データ サービス ジャパン

情報システム

記者の眼

ITpro

「動かないコンピュータ」とコンサルタントの関係

2002/10/31

 今回の主題は,「動かないコンピュータの影にコンサルタントあり」というものである。動かないコンピュータとは,情報システム構築プロジェクトの失敗など,当初計画の通り,動かなかったコンピュータを指す。筆者は5〜6年前から,講演などでは「コンサルティングと詐欺は紙一重」などと滅茶苦茶なことを話していた。だが,原稿にするのは難しく,きちんと書いてはいなかった。

 なぜ書くのが難しいかというと,確たる裏付けがない話だからである。筆者は,「動かないコンピュータ」の取材をライフワークにしているので,日ごろから情報システムのプロジェクトについて情報を収集している。うまくいかないプロジェクトの原因を調べていくと,コンサルタントに突き当たることが多い。これは5〜6年前からの傾向のように思う。

 「日本のプロジェクトをお前は全部取材しているのか。数件そうした事例があったからといって,コンサルタント全部がダメといわんばかりの論を展開するのはけしからん」と立腹されるコンサルタントの方もいるだろう。しかし,本記事で筆者が言いたいのは,単純なコンサルタント批判ではない。ここまで読んで怒ったコンサルタントの方もぜひ最後まで読んでいただきたい。

 まず具体例をいくつか列挙する。企業名は伏せるがいずれも実話である。本来は,実名を出して日経コンピュータの看板コラム「動かないコンピュータ」に書くべきであった。だが,すでに時効になっているプロジェクトもあり,今回は匿名にする。

数億円払って使わないバインダを作る

 ある流通業の例である。経営トップの陣頭指揮で,情報システムの再構築を始めた。まずはなにをすべきか,戦略とシステム要件を固めようということで,コンサルティング会社を呼んだ。コンサルティング会社は,コンサルタントを数十人投入し,社内の各部署でインタビューをするなど,1年半ほど作業をした。

 できあがった成果物は,10冊近くあるバインダである。コンサルタントは,「要件定義書が入っているので,後はシステム・インテグレータにこの通り作らせればいいです」と言った。しかし,流通業の社員が読んでも,そのバインダはよく分からない。

 不思議なことに,その流通業は再構築に使うパッケージ・ソフトをあらかじめ決めていた。というのは,経営トップが海外の事例セミナーでそのパッケージの説明を聞いて感心し,「当社でもあのパッケージを入れて,業務改革をしよう」と言い出したのがプロジェクトの発端だったからである。その流通業は,パッケージを使う前提でコンサルティングを依頼したはずであったが,なぜかパッケージとは無縁なバインダがでてきてしまった。

 その流通業は,コンサルティング会社とは別のシステム・インテグレータにパッケージの導入作業を依頼した。ところが,コンサルティング会社にバインダ代として,数億円を支払ってしまったため,パッケージ導入プロジェクトの金が足りなくなり,プロジェクトは中途半端になっている。バインダはロッカーにしまわれたままだ。

使わないソフトを大量購入,無理やりオープンシステムへ移行

 次は製造業の例である。グローバルに事業を展開しているある製造業は,経営トップの号令により,サプライチェーン・マネジメントのプロジェクトを開始した。サプライチェーンのノウハウがないと考えたその製造業はコンサルタントを使うことにした。

 コンサルティングの結果,あるサプライチェーン・マネジメント・ソフトをグローバルで導入すべし,という方針が出た。そこでその製造業は,グローバルに展開する前提で,ソフトの導入契約を結んだ。ところが,実際にプロジェクトを進めてみると,工場や物流体制の見直しが相当にやっかいであり,国内の一事業部門がそのソフトを入れただけにとどまっている。グローバルどころか,国内における展開のメドすら立っていない。

 流通,製造ときたので金融の例も挙げておく。ある金融業は,大手インテグレータに委託している基幹系システムの再構築を始めた。再構築にあたっては,そのインテグレータをあえて外し,コンサルティング会社を呼んで,構想を練った。金融業の経営者に,「どうも今のシステム経費は高すぎるのではないか」という問題意識があったからである。

 コンサルティングの結果,「既存システムを捨てて,最新技術を使って作り直せばずっと安くなる」という答申が出た。そのコンサルティング会社が引き続き,システムの要件定義とインテグレータの選定,プロジェクトマネジメントを請け負うことになった。

 ところがそのコンサルティング会社は金融システムの経験はあまりなかった。実際の開発はコンピュータ・メーカーに担当させることにしたものの,そのコンサルティング会社の指示が曖昧で,プロジェクトはほとんど進んでいない。

失敗パターンを抽出する

 筆者はこうした実例を多数収集している。無理やり,典型パターンを抽出してみると次のようになる。まず経営トップが情報システムについて問題意識を持つ。発端は,経営者同士の集まりである。経営者はほかの経営者から「うちは今度,サプライチェーンの見直しを始めました」といった話を聞き込んでくる。自社に戻って,システム部長を呼び,「うちもサプライチェーンをやるぞ」と伝える。

 驚いたシステム部長は出入りの大手コンピュータ・メーカーに相談するが,なかなか具体案が作れない。そのうちに業を煮やした経営トップは,「うちのシステム部はダメだ。コンサルティング会社に頼もう」と言い出す。

 ベテランのコンサルタントが颯爽(さっそう)と現れる。何を言っているかよく分からないシステム部長とは雲泥の差である。経営トップの琴線にふれる話を次々にしてくれる。すっかりコンサルタントに惚れ込んだ経営トップは,「プロジェクトもお任せします」と発注する。

 ところがプロジェクトが始まると,ベテランに替わって,異様に若いコンサルタントが大挙して登場する。どう見ても社会人になって数年しかたっていないが,そのコンサルティング会社の方法論を習得しているそうで,コンサルタントの月額料金は一人300万〜400万円という。10人来ただけで月4000万,年間5億円かかる。

 5億円払うと,バインダができてくる。インテグレータを選定する。選ばれたインテグレータはバインダを見るなり,「これは会議の議事録にすぎない。システム要件としてはまったく整理されていない」とつぶやく。しかし,経営トップはコンサルティング会社を信用しきっており,「バインダ通りにやれ」と指示を出す。しかたなく,インテグレータのシステムズ・エンジニアが顧客の現場にいちいち確認しながら,システムを開発していく。

 顧客の現場は怒る。「この間,コンサルタントに話したことをなぜまた聞くのか。現場は忙しいんだ」。こうなるとインテグレータは現場に聞きにくくなる。いきおい,バインダの議事録の行間を読み,「たぶんこういうことだろう」と考えてシステムを作っていく。

 コンサルティング会社はバインダだけおいて消え去ることが多いが,時にはプロジェクトマネジメントをすると称して残ることもある。しかし,「ちゃんとやってください」ぐらいしか言わない。複数の協力ソフト会社にまたがる仕事の調整をするわけでもない。中にはプロジェクト計画の中に,旧システムから新システムへの移行作業を入れ忘れる豪傑コンサルタントもいる。後で移行作業が抜けていたことがわかり,インテグレータが突貫工事で移行ソフトを作る。

 こうした苦労の末,いよいよシステムが完成した。システムの説明を聞いて,あれこれ質問していた経営トップは最後に怒り出す。「俺はこんなものを頼んだ覚えはない」。インテグレータは作り直しを命じられる。しかし大赤字でやり続けるわけにはいかないので,追加料金を要求する。さらに経営トップは怒る。コンサルティング会社に泣きついてみるが,「うちはちゃんと御社のいう通りに要件を定義し,プロジェクトを管理しました。作れなかったインテグレータが悪いのです」とあしらわれ,なす術がない。

コンサルタントが悪いと言い切れない

 以上のパターンは筆者が妄想を膨らませて作文したわけではない。実際のシステム開発をされている現場のエンジニアの方はこうした事例を見聞きされているだろう。しっかりしたコンサルタントの方は,「俺はそんないい加減な仕事はしていない」とさらに怒っておられるかもしれない。

 ようやく本題に入る。冒頭に述べたように,「いい加減なコンサルタントが多いから気を付けろ」とコンサルタント批判をするつもりはない。言いたいのは,「経営トップが馬鹿だから,プロジェクトに失敗する」という,いつもの話である。

 確かにコンサルティング会社は豊富な事例を持っているし,方法論をコンサルタントに教育している。若くても優秀な人材を集めている。しかし,そのコンサルタントがプログラミングの経験がなかったり,データ・モデリングなど要件定義の技法を知らなかったとすると,情報システムのプロジェクトを仕切るのは無理だ。

 そもそも業務改革をし,それに必要な情報システムを作るという大仕事を赤の他人であるコンサルタントだけでできるはずがない。自社の社員とコンサルタント,自社のシステムを熟知しているインテグレータらが一緒になって汗を流すべき仕事である。

 次に批判の矛先を情報システム部門やインテグレータに向けたい。酷な物言いだが,経営トップがコンサルタントに幻惑されるのは,システム部門とその相方である既存システムを手掛けたインテグレータがだらしないからである。経営トップが外部の意見ばかり重用するのであれば,システム部門がコンサルティング会社を呼んできて経営トップを動かすくらいの政治力がほしい。

 最後に,恐れ多くも読者を批判して締めくくりとする。情報システム部門やインテグレータがだらしないとすると,それはシステム部門やインテグレータ,その協力ソフト会社にいる,一線のエンジニアにも責任がある。「冗談ではない。現場には権限も責任もない」という反発があろう。一線のエンジニアに筆者が期待していることは,「システムズ・エンジニアが日本を救う」に書いたのでここでは繰り返さない。

 今回は,コンサルタント,経営者,システム部門,インテグレータ,エンジニアと,あらゆる人々にけんかをうる原稿になってしまった。日経コンピュータのWebサイトにある「動かないコンピュータ・フォーラム(日経コンピュータ定期購読者限定ページ)」でもこのテーマを取り上げている。反論も含め,ご意見をいただければと思う。

(谷島 宣之=コンピュータ第一局編集委員)

この記事に対するfacebookコメント

nikkeibpITpro

読みましたか? 〜 未読記事をご紹介