合併時の代理戦争には気を付けろ！：情マネ流マーフィーの法則（6）

今回は、企業合併における“システム合併”についての法則を紹介する。

[木暮 仁，＠IT]

　企業合併などに伴うシステム合併では、情報システム構築の遅れや準備不足によるトラブルが話題になる。それを回避するために、IT部門がとるべき対策とは何だろうか。

情マネ流マーフィーの法則その26

合併時の代理戦争に巻き込まれるな

情マネ流マーフィーの法則その27

情報システムの重要性は、合併時に認識される

　情報システムは仕事のやり方を規制する。

　合併時にどちらの情報システムにするのかは、「どちらの仕事のやり方を採用するか？」の問題であり、「どちらが業務の主導権を握るか」の問題なのである。そこで、利用部門は自社システムを採用するように、IT部門に圧力をかける。

　また、これまでの主要ベンダから、各社のシステムを採用するような働き掛けがある。これを機会に参入を図る新ベンダもいる。各社がIT部門に直接、あるいは経営層を通して間接的に働き掛けてくる。

　双方のIT部門は、自社システムの欠点を知っている。合併では予算が十分に得られるので、これを機会に抜本的な再構築をしたいと思っている（時間があればの話だが）。それなのに、外部の圧力によって代理戦争を強いられ、心ならずも自社システムが優れていると主張する。

　代理戦争をしている間に、抜本的に再構築をする時間が失われ、どちらか一方に片寄せすることになる。勝った側の情報システムが、実は欠点だらけということはすぐに分かる。これにより、双方のIT部門に不信感が生じる。このような状況でシステム構築をしたら、トラブルが起こるのは仕方がない。

情マネ流マーフィーの法則その28

システム合併では、新CIOに期待するな

　合併時には、主要人事での駆け引きが付きものである。社長がA社ならば副社長はB社、営業がA社なら経理はB社というように、○勝○敗のバランスが重視される。

　CIOの重要度は低いし兼任が多いので、他業務の都合で人事が行われる。最終段階でのバランス調整によって、初めてCIOが決定する。そのCIOが、旧会社でのCIOである確率は低い。

　すなわち、かなり後になってから、どちらのシステムも知らない（ITそのものを知らない）素人が、両社のITを担当することになる。だから、新CIOの指示を待っていたのでは、合併システム構築のスタートが遅れ、合併の足を引っ張ることになるのは目に見えている。

情マネ流マーフィーの法則その29

シノニム・ホモニムの呪い（バベルの塔）

　倉庫、出荷基地、デポ、在庫場所などが、同じものなのか違うものなのか。「支店別売上」というとき、支店には本社直売部は入るのかどうか。「見本納入」や「他支店転送」は売り上げに加えるのかどうか。これらがベンダが業務を理解するのを妨げる。しかも、上流工程でその誤解に気付くことはまれで、帳票が印刷されてから気付くことが多い。

　これらの用語・概念は、仕事のやり方の象徴である。各人が自分が用いている用語・概念の採用を主張する。それが部門をまたぐシステム、企業合併での統一システムに時間がかかり、トラブルが発生する原因になる。

情マネ流マーフィーの法則その30

合併システムの第2次システムは実現しない（今日できることを明日に延ばすな）

　一般に合併システムでは、費用は比較的潤沢であるが、要求機能はあいまいで、短期間に実施することが要求される。そこで、重点を絞り込んで、取りあえず動くものを第1次システムとして構築し、その後落ち着いた時点で、理想的な第2次システムを検討しようと考える。

　ところが、第1次システムでのトラブル対処に忙殺されること、合併後の変更への対処に振り回されることなどにより、なかなか第2次システムに取り掛かれない。取り掛かれるようになったときには、そのための費用が得られない。

情マネ流マーフィーの法則その31

ないものねだりのRFP合併システム成功のカギはIT部門の団結にある

　合併システム検討でモタモタしていると、上記のような外部からのノイズが増大する。外部が事の重要性に気付かない間に、両社のIT部門が相談して既成事実を積み重ねておくのが成功の秘訣（ひけつ）である。

　システムを片寄せするのか新規に開発するのか、ハード構成をどうするのか、両社の用語の対応表作成と統一案などは、外野がいなければ案外短期間に作業できる。

　外部が騒ぎ出す前に両社のトップに共同案を示し、お墨付きを得ておくことにより、余計なトラブルに巻き込まれるのを回避することができる。

著者紹介

▼著者名　木暮 仁（こぐれ ひとし）

東京生まれ。東京工業大学卒業。コスモ石油、コスモコンピュータセンター、東京経営短期大学教授を経て、現在フリー。情報関連資格は技術士（情報工学）、中小企業診断士、ITコーディネータ、システム監査など。経営と情報の関係につき、経営側・提供側・利用側からタテマエとホンネの双方からの検討に興味を持ち、執筆、講演、大学非常勤講師などをしている。著書は「教科書 情報と社会」（日科技連出版社）、「もうかる情報化、会社をつぶす情報化」（リックテレコム）など多数。http://www.kogures.com/hitoshi/にて、大学での授業テキストや講演の内容などを公開している

「情マネ流マーフィーの法則」バックナンバー

• 情マネ流マーフィーの妖誤集〜その3
• 情マネ流マーフィーの妖誤集〜その2
• 情マネ流マーフィーの妖誤集
• 情報科学の法則を復習しよう
• 社会科学法則の「情マネ流マーフィー」への適用
• 自然科学法則の「情マネ流マーフィー」への適用
• コンピュータが発展すると人間はバカになる
• バグとの長い長い付き合い
• なぜソフトウェアの部品化／再利用は進まないのか？
• “バカ・マジメ”をメンバーに入れるな！
• なぜIT部門は提案できない／しないのか？
• ユーザーニーズを基にシステムを作るな
• 成果の出ないIT戦略
• IT技術者、どう評価する？
• 何かが足りない日本のIT教育政策
• 電子政府の研究はIT推進の教科書として最適だ
• 日本にはびこる素人CIO
• IT部門の戦略部門化は矛盾だらけ
• なぜIT部門アウトソーシングがうまくいかないのか？
• IT部門の社内的地位が低い“本当の原因”は？
• 役に立たないグループウェア
• ユーザーの過度体裁愛好症が問題だ
• ユーザーの過度依存症とIT部門の没我的愛情症
• ああ、上司と部下の悲しいすれ違い
• IT系アンケート結果は信用できない
• “クラウドコンピューティング○×”の寿命
• 羊頭狗肉のIT用語、誇大表示を告発する
• そして、歴史は繰り返す − 2度目は喜劇として
• ITエンジニア今昔物語
• “リスク管理のリスク管理”が必要だ
• 納期とは遅れるものだ
• ITの効果とはプロジェクトの効果だ
• 費用対効果を追求することで出銭が増える愚かさ
• そもそも、IT計画が実現すること自体が奇跡だ
• 経営者にITの費用対効果を説明するのは難しい
• ERPパッケージの不思議あれこれ
• 合併時の代理戦争には気を付けろ！
• ないものねだりのRFP
• 標準化にメリットはあるのか？
• システム開発の可視化で何が見える？
• 「他人のふんどし指向アプローチ」を考える
• マーフィーの法則がIT版になって帰ってきた！