PR

システム部門に企画機能だけを残し,開発・運用・保守を外部に委託するアウトソーシングが流行りだ。しかしアウトソーシングでは,発注側の意図や開発手法,ルール,評価の基準などを,自社開発以上に明確にしておくことが不可欠である。システムが出来上がった後に,「こんなはずではなかった」ということも多い。さまざまな点を十分に考慮してアウトソーシングに踏み切らないと,真の恩恵は得られない。

本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが,この記事で焦点を当てたITマネジメントの本質は今でも変わりません。

 部品メーカーのO社では,生産計画・物流計画・原材料調達・売れ筋分析などに役立てるために,データ・ウエアハウスを構築することになった。基幹系システムに毎日入力したデータをデータ・ウエアハウス・サーバーに移し,必要なデータを自由に引き出せるデータベースを構築して,いつでもどんな視点からでもデータの分析を行えるようにしたいという経営陣の発想が発端になった。

 O社では,1年ほど前からシステム開発業務は外部企業にアウトソーシングをしている。これに伴い社内の情報システム部門の業務は,企画とプロジェクト・マネジメントが中心になった。新システム構築の要請を受けたシステム部門では,直ちに担当者としてF氏をアサインした。F氏が中心になって,日ごろから開発を発注している複数のソフト会社に開発提案を依頼した。

 ところがどのソフト会社も,利用部門単位に簡単な表計算やデータベースソフトを作った程度の実績しかない。今回のように,販売から物流や購買のデータまですべてを取り込んだ分析システムを一から開発するだけの実力があるかどうかは未知数だった。そこで,将来のことも考えて新しい分析ツールを導入することにして,新システムの開発にも適用することになった。ソフト会社は,ツールの利用に関する実績を考慮して,これまで取引のなかったM社を選定した。

 これまでO社では,開発案件を数社に限定して発注してきたので,委託先もO社の社内システムについて熟知している。開発途中で発生するいろいろなやり取りについてもあまり厳密なルールを決めずに,何か問題が起こればその都度対処してきた。ところが,これまで付き合いのなかったM社と一緒に仕事をしてみると,今までのやり方とはずいぶん違うことにF氏はとまどいを感じた。

 まずO社とM社の役割分担をこと細かく決めるようM社から求められた。O社からは仕様固めや概要設計に関する詳細な資料をM社に渡すことになった。会議はその都度議事録を作成して,変更が生じた場合には必ずその理由を明記して両社で確認する。設計変更やプログラム修正は書面でソフト会社に渡す。電話でのやり取りも必ず書面に落としたものを確認としてメールで受け渡しをする。このように,これまではほとんどソフト会社任せだった点が一つひとつ明確にされた。

 今までは要件定義の段階で利用部門の了解を取り付けるのが難しいため,ある程度まで見込みで開発を進め,後から修正するのが常だった。アウトソーシング先がO社の社内システムをよく知っていたのと,利用部門とも親しかったので,それで問題は起こらなかった。しかし今回は初めての発注先ということもあって,打ち合わせには毎回かなりの時間を要した。

 M社は,F氏に対して要件の一つひとつを確認するように求め,利用部門の意見もF氏のところで集約するように要請してきた。しかし,担当者のF氏もすべての要件を把握しているわけではなく,利用部門にこと細かに確認している時間もないことから,あいまいな返事をせざるを得なかった。

検収印を盾に追加料金を求められる

 本番稼働をしてみると,データの不整合が真っ先に問題になった。各部署から基幹系システムに入力しているデータが部署間で整合が取れていないことがわかった。日付のつけ方が違っていたり,データのとらえ方が異なったり,同じ項目に異なる内容が入力されていたり,同じ項目が複数あるといったことが多発した。ある条件を設定して検索をかけてもうまく結果が得られなかったり,時間がかかりすぎたり,明らかに間違っている結果が出るといったことが続いた。

 O社としては初の情報系システムということもあって,利用部門も使い勝手がわからずにやみくもに条件を指定して検索することも多く,そのたびにシステムがダウンした。困ったF氏は,問題点を早急に改善するようM社に要請した。するとM社からは「基幹系システムのデータの内容についてはすべてそのままでよいというO社側の承認を得て開発したもので,F氏の検収印ももらっている。指摘されているようなシステムの修正は,データベースの構築し直しに等しいので,別途契約で見積もらせてほしい」と言われてしまった。

 F氏が開発内容の不備の可能性を指摘すると,「今まで作ったものはすべて承認をもらっているし,承認をもらっていないものもO社側の事情で内容が確定しないので,そのまま開発してほしいと言われたものだ。この点は議事録にも残っている。我々には,落ち度はないはずだ」と押し切られてしまった。

 O社側には出来上がったシステムを評価する基準がなく,文書類もソフト会社側で作成されたものばかりで反論のしようがない。社内からの風当たりも強くなり,F氏は頭を抱えている。