これまでの連載では，ユーザー企業のIT部門，業務部門においての陥りがちな失敗例と，そこからの教訓を事例に基づき紹介してきた。今回はITプロジェクトにかかわるもう1人のプレイヤーであるシステム・インテグレータの場合を見てみたいと思う。

　今回の主人公は，大手システム・インテグレータのプロジェクトマネージャAさん。Aさんはユーザー企業X社の社内ポータル構築を任されている。筆者はこのプロジェクトに，コンサルタントとして途中から加わったのだが，Aさんはどうも苦戦しているようだ。プロジェクトの始まりからの展開を振り返ってみよう。

ユーザー企業の期待を受けての船出

　X社は，今回，全社員を対象ユーザーとした社内ポータルを構築しようとしていた。全社にまたがるプロジェクトであったため，IT部門が主体となった。IT部門としては，Aさんの会社からの「ユーザー部門に絶大なベネフィットを与える」という魅力的な提案を受けてスタートの判断をしたということもあって，これを機会に社内での信用を増そうという期待をかけていた。

　ところが，Aさんがいざプロジェクトを開始して1カ月たたないうちにさまざまな問題が生じた。まず，X社側の要件がいつまでたっても固まらない。IT部門が主体となって進めるとのことだったが，どうにも社内関連部門の意見の取りまとめができているとは言いがたい。ミーティングで議論をし，いったん結論を出しても，次のミーティングのときにはすっかり話しが変わっているということもたびたびあった。Aさんは期限を設けて，X社側への依頼事項をまとめていたが，どうにも前に進まない。

　はじめはAさん側の聞き逃しや本意をくみ取れない部分があったのかと思った。そこでAさんはできるだけ漏れがないようにと，ミーティングのつど，設計メンバー，パッケージ担当，業種担当，営業，開発を委託する外注先を加え，同席者がどんどん膨れ上がっていった。そうしたところで要件はまとまらず，むしろX社からは「がん首を揃えられても困る。誰に話したらよいか分からない。そもそもAさんの役割は？」とかえって，ひんしゅくを買ってしまった。

　ようやくAさんがまとめあげた「要件定義書」をX社側に投げかけても，忙しいという理由でなかなかよいとも悪いとも返事が返ってこない状態が続いた。

振り返り1：果たしてコミュニケーション能力だけの問題か？

　以前からこの種の話しはよく問題にされた。その際に，SEやプロジェクトマネージャのコミュニケーション能力，ヒアリング能力，業務知識の問題，と漠然とした便利な言葉で片付けられた傾向が強い。

　だが，こうした便利な言葉ですませられるのはシステム・インテグレータが受動的でいてよかった過去の話し。現在のようにユーザー企業自らがITを使ってダイナミックに自社の仕事のあり方や企業文化までをも変えていこうという時代にあっては通用しない。

　ユーザー企業から要求が出てこないことをただユーザー企業のせいにするだけというのでは，いささかシステム・インテグレータが提供すべき「ITサービス」自体が持つパワーを軽く見すぎているように思える。

　たしかにシステム・インテグレータがユーザー企業に乗り込んでいって，行司役を見事にやってのけるというのは厳しい注文かもしれない。ただ，自身がやらないまでもユーザー企業自身の意識醸成を喚起したり，打開策を推奨するくらいの努力はしてもよいのではないだろうか。言い換えると，そこまでを含めた，顧客を成功に導くための懐の深いプロジェクトマネジメントがシステム・インテグレータに求められているのである。

　結局はユーザーの仕切りの悪さはシステム・インテグレータに跳ね返ってくる。そこが与件である以上は，トップや外部を利用するなどの方法も含めてなんらかの対策をしないと，結局は作り手側が傷だらけになってしまうのである。

期待と実態のギャップ

　要件定義フェーズも終盤を迎え，どうにか形にした要件定義書をベースに詳細設計が始まった。だが，X社へのヒアリングを通じて決めたはずの要件定義書がどんどん骨抜きにされていく。Aさんが一番頭を痛めたのは「日次の経営幹部向けの情報提供」の要件が議論に挙がったときである。

　もともとは幹部向け情報についての要件は意識していなかった。IT部門もこのニーズを完全に見逃していた。ところが，全社ポータル構築のうわさを聞いたある役員が，外部セミナーで聞いてきたことをもとに，日常の判断に必要な情報をリアルタイムで見たいという期待を口にしたのだった。

　IT部門は上層部からの要求ということで，優先度“高”の要件として追加するようにと要望してきた。しかし現実はそう簡単ではない。現状のシステムから必要なデータを取り出すには既存システムについての開発が想像以上にかかるし、どこまで詳しい情報を提供するかの決定にまた時間を要することは一目瞭然であった。

　詳細設計を進めるにつれて，こういった要件定義書にはなかった案件がいくつか浮かんできた。こうした状況にどこまで応えたらよいものか。X社からは「このプロジェクトはBPRにつながると聞かされてスタートした」と言われるなかで，Aさんは要件定義書に書かれた機能と，X社側の期待との間に大きなギャップがあることを徐々に知る羽目になった。

　この状況はまずいと考え，Aさんは自社内のX社担当営業に相談しようとした。ところが，このプロジェクトの企画持ち込みから一連の営業の主役であったBさんは既に異動していた。後任の担当営業は，そもそもの約束がどうなっているのか分からぬまま，あいまいな答えをするだけであった。現場としてはX社からの要求に応えざるを得ず，Aさんは「これはまずい」と思いながらも，要員を追加して顧客ニーズに応えようとするしかなかった。

振り返り2：Aさんは犯人か，犠牲者か

　これは，単に見積もりや事前調査が甘かった，という話ではない。システム・インテグレータ自身の姿勢の問題が背景にあるのではないだろうか。混とんとしたSIビジネスの競争環境のなかで，「御社のビジネスパートナーになります」「最初に相談してもらえる存在になります」という姿勢を打ち出すシステム・インテグレータが見受けられるが，聞こえのよいこうしたフレーズが実は悲劇を招いている場合がある。

　聞こえのいい提案だけが1人歩きして，実際は自社ができることのスコープと顧客の期待がずれたまま走り出してしまう。こうしたケースがAさんのプロジェクトだけでなく，ちらほら見受けられる。

　例えば，システムだけではビジネスの課題は解決できないのにもかかわらず，すぐに「ROI（投資対効果）が何％」「導入効果で生産性何％向上」という提案営業の教科書のような表現を用いて仕事を取りにいく。さらに少しでも説得力を増そうと，自社をショーケースにして構築時の苦労話と成果を聞かせて，その気にさせてしまうわけだ。

　現実には成果を手に入れるには，組織や機能分担，業務プロセスの変化とそれを実現できる人の能力，それらを支えるITマネジメント体制など必要なものはあまりにも多い。そういった部分はあまりにユーザー企業ごとにまちまちなので，ショーケースに飾られた事例では全く語られない。

　このようにシステム・インテグレータの中途半端なスタンスで獲得した仕事を担当するAさんのような人は悲劇である。特にこのケースのように，最初に大風呂敷を広げた張本人はすでにいなくなっていることは大企業ではしばしば見受けられる。

傷だらけのカットオーバー

　こうした状態が続いたまま，結局当初のスケジュールから常に3週間遅れでプロジェクトは進んでいた。そんななか，X社のCIOも出席してのIT部門のプロジェクト・レビューが開かれた。CIOはこのプロジェクトについての報告を聞くと，「なんでポータル構築程度のプロジェクトでこんなに予算・納期ともにオーバーするのだ」と怒りだした。レビュー会議で検討の結果，そのCIOが以前使ったことのあるコンサルタントを呼ぶことになった。そうして，このプロジェクトに加わったのが筆者である。

　そのプロジェクトの仕切り直しを託された筆者は，X社の各部署のインタビュや資料分析を繰り返した。その間，いったんプロジェクトは中断するような形になった。調査の結果，筆者は「プロジェクトの体制とマネジメントの建て直しをすれば, 現状のシステム・インテグレータ増員体制で何とかカットオーバーは可能。やりきらないとプロジェクトを始めた意味がない。」という報告をした。この結果，このプロジェクトは継続することになった。

　システム・インテグレータのプロジェクトマネージャAさんはプロジェクトを再開し，黙々と作業を続けた。すでに増やしてしまった要員を抱えつつ，本当にこの追加部分は回収できるのだろうかと疑問に思ったことだろう。

　それから4カ月後，最終的になんとかカットオーバーにこぎつけた。ところが数週間たっても，想定ユーザーは，この新しいポータルを活用せず，従来の個別のシステムを使い続けていた。導入前にはもちろんユーザー・テストは行い，機能の検証は十分済ませたはずなのだが。

　その後ユーザーの声を聞く機会があり確認してみたところ，「こんな使いにくいツールは役に立たない」という厳しい評価だった。たしかに，なじみのある従来のシステムを直接使うことで用は足りる。では，この苦労して作ったポータルは何だったのだろうか。Aさんは顧客のビジネス課題を解決したい仕事に打ち込んできたのに，こうしたグレーな結末を迎えることになってしまった。

振り返り3：なぜ使われないシステムになってしまうのか？

　今回ケースに挙げたEIP（企業情報ポータル）のようなものは，筆者から見ると，そもそもシステム・インテグレータのマッチポンプ的なソリューションという気がしてならない。それはさておき，従来の××管理システムといった機能別の切り口では，ユーザーは複数のシステムを扱わなくてはならなかった。それを「ユーザー」という切り口で情報を整理していこうという試みはユーザー企業にとって好ましいことだと思っている。

　ただ，それによって何が起こっているかというと，ユーザーの目が肥えて，これまで以上にシステムの使い勝手を求めるようになったという点がある。特に社内ポータルのように，日々ユーザーが触れることを目的としたものの場合，単に機能面を充実させるだけではすまなくなっている。昨今のようなさまざまな就業形態が前提で，さまざまなリテラシの社員がいる企業では，直感的に使いやすいユーザー・インタフェースになっていないと，日常ツールとしては使われない。

　このようにコンセプトからして従来とは異なるITツールが次々と登場するなかで，システム構築自体もただ「作る」というゴールから「活用されるようにする」というゴールまで見据えて，システム・インテグレータとしても必要なメソッドやスキルセットを蓄積していくべきであろう。

　以上，Aさんのケースを基にシステム・インテグレータを取り巻く環境変化とプロジェクトを進めるうえで生じる「傷」を挙げてみた。ユーザー企業，テクノロジ，自社のポジショニングの取り方など，さまざまな変化に合わせてプロジェクトを成功させるための体制，手法，人材をそろえていかないと取り返しのつかない傷が残ってしまう可能性がある。ぜひともユーザー企業とシステム・インテグレータの望ましい関係を作りつつ，より幸せな結末を迎えられるプロジェクトを増やしていっていただきたいと願っている。

■著者紹介： よこやま　しょうご。1991年大学卒業後，ブリヂストンの営業部門勤務を経て，日本能率協会コンサルティングに入社。通信，ハイテク，製造業を中心とした大企業におけるコンサルティングに従事。マーケティング・営業関連の戦略立案，業務改革，評価制度設計などのプロジェクトに携わる。ソリューション営業や問題解決スキル向上をテーマとした研修・セミナー講師も務める。その後，シスコシステムズのコンサルティング部門インターネット・ビジネス・ソリューション・グループの日本での立上げに関わり，大企業，官公庁などのEビジネス化推進のアドバイザーを歴任。2002年9月サイエント　ジャパン入社。サイエントではクライアント側に立って真に使われるシステム構築をすべく，戦略策定，業務設計，システム導入までの一連のサービスを提供している。大阪外国語大学卒。中小企業診断士。