連載
» 2005年08月09日 12時00分 UPDATE

システム部門Q&A(6):企業合併でシステムが止まらない方法教えます! (1/4)

ライブドアとフジテレビの買収問題がお茶の間をにぎわし、企業買収が注目を集めている。競争力を高めるための企業買収や合併も、日常的になってきた。一方で、銀行における合併時のシステム不具合の発生など、システム合併におけるトラブルもよく聞く。企業合併時に、システム部門はどのような対応をすればよいのだろうか?

[木暮 仁,@IT]

質問

銀行が合併したときのような情報システムのトラブルを回避するには、どうすればよいのでしょうか?

中堅卸売業の情報システム部長です。この業界では、競争力強化のためには企業合併が必至だといわれており、当社もいずれは合併することになるでしょう。企業合併における情報システムのトラブルをよく見聞しますが、そのような事態にならないようにするには、IT部門としてどのような対処をすればよいでしょうか。


意見

 合併目的を実現するには、適切な情報システムが不可欠です。また、合併は情報システム抜本的改革の絶好の機会でもあります。ところが、合併システムは、方針や仕様決定が遅れ、開発期間が短く、トラブルが発生するケースがマスコミなどで多く取り上げられています。ここでは「合併システムを成功させるために、IT部門はどのような戦略を取るべきか」について、「代理戦争に引き込まれるな」「バベルの塔を解決せよ」「ユーザーをうまく使え」が効果的であることを示します。そして、これらを円滑に行うために「IT部門よ、団結せよ!!」と提案します。



 もはや情報システムは、業務活動に不可欠な存在になっています。新しい組織が活動するには、組織ができる前に情報システムが構築されていなければなりません。ところが、その構築に時間がかかり、それがクリティカルパスになってしまうことがよくあります。昔は、「情報システムにより組織改革を推進する」といわれたのに、現在では「情報システムは組織改革の障壁である」とすら、いわれる始末です。

 経営環境は激変しています。それに伴い、情報システムへの改訂要求が頻出し、しかも迅速な対応が求められます。すなわち、「良いシステム」とは、改訂が容易にできるシステムだといえます。オブジェクト指向やEAなどが注目されていますが、これらも環境変化に柔軟に対応できる情報システムにするための技法だともいえましょう。

 多様な事情により、現状の情報システムは複雑怪奇な状態になっています。IT部門としては、それを抜本的に解決したいと思っているのですが、費用や労力の面から実施できないでいるのが実情でしょう。企業合併は、経営方針から組織構成、仕事の仕方まで全般的に抜本的に見直すことになりますので、情報システムの抜本的解決に絶好の機会だといえます。

トラブルの原因は短期間開発にある

 銀行合併システムのトラブルが社会問題になったように、合併システムの開発では、多くのトラブルが発生します。その原因はいろいろあるでしょうが、開発期間が短いことが最大の原因だと思います。ここでは、それを中心に検討します。

r8image01.jpg 図1 企業合併時のシステムトラブル発生のメカニズム

 合併は機密事項ですので、IT部門にも知らされないのが通例でしょう。従って、発表以前に準備ができません。また、合併発表から新会社発足までの期間は非常に短いし、新会社発足までに新システムを稼働させることが至上命令になります。すなわち、通常の情報システム開発だとしても、あまりにも期間が短いのです。

 しかも、合併が発表されても、IT化の具体的な方針はなかなか決まらず、開発するべき情報システムへの要求事項も決まりません。さらには、どちらの情報システムをベースにするのか、新規開発するのかなどの綱引きも起こります。そして、やっと作業開始になったときには、「完了期限が目の前に迫っている」といった事態になります。さらに、システム開発作業を開始した後からも、システムに大きく影響する変化が続出します。そのために、多くの手戻り作業が発生します。

 その間にも期限は迫ってきます。システムの進ちょくが遅れているからといって合併を遅らせることはできません。突貫工事でテストも不十分なまま、本番稼働になります。その結果、重大なトラブルが発生するのは、むしろ当然だといえましょう。

r8image02.jpg

 このような状況変化は、新会社発足後も続出します。組織変更が頻繁に行われるし、旧会社の子会社の吸収もあるし、新たに分社化することもあります。業務の方法も試行錯誤が続きます。IT以外においても検討不十分なままに合併を迎えたのですから、むしろ多くの手直しがここから始まるのです。

 それに対処するには、改訂が容易な「良いシステム」にしておくことが重要になのです。しかし、続出する変更に対して、その場しのぎの対応を重ねて突貫工事で開発するのですから、実際には作っている段階ですでにめちゃくちゃなシステムになり、以前に夢想していた「良いシステム」とは、あまりにも懸け離れたシステムになっています。続出する改訂要求に対応できず、トラブルが慢性化した状態になります。IT部門としては、「もう1度抜本的に作り直したい」気持ちになります。


       1|2|3|4 次のページへ

Copyright© 2016 ITmedia, Inc. All Rights Reserved.

Loading

ピックアップコンテンツ

- PR -

注目のテーマ