筆者はコンサルタントとして，過去20年間にわたりIT戦略策定，IT構築，BPR（Business Process Reengineering），合併に伴うIT統合のプランニングなど様々なプロジェクトを通じて，いろいろな企業とお付き合いしてきた。ほとんどの場合，導入企業（ユーザー），ITベンダー，コンサルティング・ファームがプロジェクトマネジメント・チームを組織し，マネジメントしていたのだが，必ずしも“幸せな結末”を迎えるとは限らなかった。

　どうして傷だらけのプロジェクトになってしまったのか。筆者および同僚たちが現実のコンサルティング現場で見聞きしてきた，陥りがちなわなや失敗に向かってしまうマネジメントを異なる角度から取り上げつつ，問題提起をしていきたい。第1回はユーザー企業のIT部門における傷だらけプロジェクトを考える。まず，筆者たちが身近に見聞きしたことを元にした2つの事例をみてみよう。

事例1：谷間に落ちたボール

　Aさんは大手企業X社の情報システム部に勤めていた。X社は7年前にシステム子会社を作り，自社システムの開発・保守・運用を全面的に任せることにした。情報システム部員の大半はシステム子会社に移ったが，Aさんは本社に残った。Aさんは，かつての同僚たちに，システム構築を発注する立場になった。「これこれ，こういったシステムを作りたい」と頼めば，システム子会社のスタッフたちがあ・うんの呼吸で良きに計らってくれた。

　昨年になってX社はそのシステム子会社を大手アウトソーシング・ベンダーY社に売却した。それに伴い，X社の情報システム部はIT戦略部と名称を変えた。

　IT戦略部となったAさんは，ある社内システムの更新を担当することになった。システム構築はY社に委託することになった。Aさんにとっては，システム子会社売却後，はじめてのY社との仕事だった。Y社に要望事項を送り，見積もりを出させ，予算を確保。本格的にシステム設計が進みはじめた。ところが，システム移行の詳細計画を作る段になって，問題が発覚した。

　ベンダーY社とのミーティングの席上，大型サーバーなどのハードウエアを誰も調達していないことが明らかになったのだ。Y社はハードウエアの調達はSI契約に含まれていないことを主張。“谷間に落ちたボール”を誰も拾っていなかったのだ。X社が自ら調達しなければならなかった。

　大型サーバーなので，パソコンのように秋葉原ですぐに買ってくるというわけにはいかない。ソフト開発ができてもハードがそろわないと，予定したスケジュールではシステム切り替えができない可能性が出てきた。

　Aさんはあわてて大型サーバー調達に向けてハード・ベンダーと折衝を始めた。なんとか，発注がすんでほっとしたのもつかの間。社内りん議を通したシステム移行プロジェクトの予算には，ハードウエア費用が含まれてないことが判明した。再びAさんは社内で頭を下げ続け，社内りん議を通し，なんとか，ハードを調達することができた。

事例2：見切り発車の恐怖

　Bさんがシステム部に勤めるZ社は，全国各地に支店・販売子会社を持つ商社である。そのZ社の販売統括部門にS氏が統括役員として就任した。着任早々のS統括役員を，大手コンサルティング会社，データ・ウエアハウス，パッケージ・ソリューション・ベンダーの一団が訪れた。Bさんもシステム部代表として参加を求められた。

　コンサルタントたちは，全支店・販売子会社の販売実績をリアルタイムに集約し，経営陣向けにレポートするシステムを提案した。パッケージ・ソリューション・ベンダーは導入の簡便さを，コンサルタントは効果の大きさをそれぞれうたった。同席した販売統括部のTさんは，これで残業が減ると目を輝かせた。S統括役員は「就任早々これで実績を立てられる」と役員会で報告している自分の姿を夢見た。「では，予算を付けるからシステム部でシステム構築をしてくれたまえ」とBさんに仕事が振られた。

　ミーティング後，Bさんは提案書を読み返すうちに，このレポート・システムは既存システムからのデータだけでは成り立たないことに気がついた。一部の販売データは各拠点で入力しないと，リアルタイム集計はできない。この点をミーティングで目を輝かせていた販売促進部のTさんに確認すると，「では，データ入力画面を作ってください」とそっけない返事。

　これではらちが明かないと思ったBさんは，意を決してS統括役員を訪れる。各拠点でのデータ入力が必要なことを提案するが，S統括役員は「そんなことはこちらで簡単にできる。システム部はシステムだけ作っていればいいんだ。早くやってくれたまえ」と迷惑がられるだけに終わった。

　Bさんは，きっと販売統括部がデータはなんとかしてくれるだろうと思いこむことにして，開発作業をスタートさせた。多変量解析パッケージを導入したことにより，システムそのものは比較的短時間で導入できた。既存システムからデータを取り込む部分も機能した。サンプル・データを入力して，レポートを望み通りのものが出力された。これで開発完了として，販売統括部に引き渡した。

　ところがシステム稼働日早々，BさんはS統括役員に呼び出された。レポートの数字が合わないのだという。そんなはずはないと思いながら，パッケージ・ソリューション・ベンダーのスタッフと原因究明の乗り出した。

　難航の末，判明したのは，各拠点によって異なるローカル・ルールが存在しており，各拠点のデータを同じようには扱えないということだった。各拠点のワークフローが違っているため，そのままでは集約できないのだ。基準がまちまちのデータでは，当初，思い描いた一目で全国の販売状況が分かるレポートはできないも当然だった。

　そのままシステムは動かない状況が続き，販売統括部周辺からは「システム部は金をかけて，使えないシステムを作った」と非難の声が聞こえてくるようになってしまった。担当したBさんが責められる結果となってしまった。システムはちゃんと作ったんだから，なんで自分が責められなくてはならないんだと憤りを感じつつも，「このままでは動きません」ということを強硬に言っておくべきだったと後悔している。

10年前とは違うことが求められるIT部門

　なぜ，“谷間に落ちたボール（事例1）”や“見切り発車の恐怖（事例2）”といった事態に陥ってしまったのだろうか。その背景として，ここ10年くらいで，特に大企業のIT部門が本質的に求められている事項が大きく変化した，と筆者は考える。

　まず，1990年代初頭までは情報化積極推進の時代だったといえる。

　この時代の大企業のモチベーションは，自社業務処理の機械化だった。人間の手作業では膨大な手間暇のかかる作業をITに肩代わりさせることにより業務の効率化の向上を求めた時代である。この時期のIT部門は，他の部門が持たないコンピュータの知識を駆使して業務処理を要求通りにプログラムに翻訳するということが求められていた。システム作ることが最大のミッションであった。大雑把に言えば，システムを作れば他社優位に立てるという大儀があった。

　しかし，1990年代前半から流れは変わる。ITコスト見直しの時代である。

　情報化積極推進の結果，IT資産は膨れあがった。結果としてメンテナンスや機能拡張・修正の追加投資がかさむことになり，バブル期以降にはコスト問題がクローズアップされるようになってきた。

　この時期，コスト削減の一環として，多くの企業は，「システムを作る」という専門性を分社化あるいはアウトソーシングにより切り離した。本社に残ったIT部門はシステム構築・維持能力を価値とする部門から，IT企画管理を行う責任・機能を担うことが求められるようになった。

　一方，インターネットが社会基盤として普及することになってから，IT自体がビジネスに与えるインパクトが大きくなってきた。大手のコンサルティング会社，ソリューション・ベンダーはこぞってビジネス・プロセスの抜本的な革新，事業構造の抜本的な革新をうたってきている。IT部門の役割は，ITを使ったビジネス・プロセスの革新を企画し，プロジェクト遂行管理を行う役割に変化したといえる。

　だが，こうした変化に，IT部門スタッフの意識や業務のスタンス，スキルがキャッチアップできていないと，事例のような笑うに笑えない，とんでもないストーリーが生まれる。

事例1を振り返る：あ・うんの呼吸では進まなかった

　“谷間に落ちたボール”の事例1は，従来の延長で仕事をしようとしたために，危機に陥ってしまったと言える。システム子会社に発注すれば終わりは過去のこと。自らプロジェクト全体を管理する必要があった。

　Aさんとしては，プロジェクト・メンバーにかつてのシステム子会社のメンバーが含まれていたことの安心感からか，これまでと同じようにかゆいところに手が届くあ・うんの呼吸をうすうす期待していた。しかしそのメンバーはすでに子会社のスタッフではなく，Y社の人となっている。そして，SI契約に，ハードウエア調達の項目は範囲に含まれていなかった。

　であるなら，X社側でハードウエアの見積り，予算化，発注をする必要が出てくる。プロジェクトに関与するプレーヤの隙間にハードウエア調達の仕事が落ちていたにもかかわらず，だれも拾っていなかった。責任分担，役割分担を明確に意識せず，慣れ親しんだやり方から抜け出せない人たちは思わぬところでこける。

事例2を振り返る：システムの不満はIT部門にかぶさってくる

　“見切り発車の恐怖”に陥ってしまったBさんは，業務部門にシステムを納める社内下請けのような立場になってはいなかっただろうか。それゆえにS統括役員をはじめとする販売統括部にシステム開発を押し切られてしまった。

　しかし，「見通しが甘いよ。そのまま行くと，もしかすると大変なことになるよ」と指摘する立場はシステム部にあったのではないだろうか。確かに販売統括部が見通しを誤ったということは問題だが，「危ないよね」と思いつつ，それを阻止する強硬なウォーニングをシステム部は出し切れなかったために，結果的に見切り発車になってしまった。ところがシステムについてのあらゆる文句はシステム部に回ってくる構図があるため，Bさんのような悲劇が生じてしまった。

　システム部のトップがS統括役員を含めた社内に対して，システム部の立場をきちんと説明していなかったという指摘もあるかもしれないが，コンサルティングの合間に見聞きする現実はもっと複雑である。

　システム部員からまずい部門長に伝えて，しかるべき時には他部署に対して部門長から仕切ってもらうことができれば，それに越したことはない。ところが上の人は「問題があったら早めに手を挙げろ」とは言うものの，いざ手を挙げてみると「そもそも君のミスじゃないか」とか「なるほど分かった。でも今はどうしようもないので，とにかくがんばれ」といったことを言うことが多い。このため，システム部内で下から上へのコミュニケーションがうまくいっていない光景もよく見かけるのである。

☆　　　☆　　　☆　　　☆　　　☆

　次回はIT部門の事例をもう1つご紹介しよう。業務部門から押し寄せるシステム化要求に対してIT部門自らがボトルネックになってしまったケースである。

■著者紹介： きたむら　かずひこ。サイエント ジャパン取締役副社長。1983年，慶應義塾大学法学部を卒業後，アンダーセンコンサルティング（現アクセンチュア）に入社。顧客企業の基幹システムの構築およびコンサルティングに携わる。1999年にパートナーに就任。以降，金融サービス業担当パートナーとして日本国内外の金融機関のIT戦略，オペレーション戦略，組織改革などに関するコンサルティングに従事したのち，2001年セピエント バイスプレジデントに就任。製造業における，クロスファンクショナルなBPRのコンサルティングに従事。特に日本企業の縦割り体質の中での部門横断的なプロジェクト推進を通じて，業務・IT，組織・人の変革を手がける。2003年1月，サイエント ジャパン取締役副社長に就任。現在に至る。