Point
1. 3社の経営統合に伴い，システムを共通化して効率を高めた
2. キックオフ時点で4カ月の遅れが発生したが，移行システムの構築で挽回
3. 3サーバーの併存に起因するユーザーIDの問題をポータビリティ化で解消
| ||
|
日本コムシスなど3社の経営統合に伴うシステム共通化のプロジェクトは，最初から難航を予感させた。藤本晴彦氏（日本コムシス ITビジネス事業本部 ソリューション部 社内IT部門 担当課長）らに課せられたプロジェクト完遂のリミットは2005年4月。遅れは許されない。しかし，各社の経営層の了解を取り付けるのに手間取ってしまう。必然的に，開発期間にそのしわ寄せがきた。
マスター・スケジュールを作成した段階で，既にギリギリだった。システム開発の現場では，時間に追われる日が続いた（図1[拡大表示]）。システム共通化プロジェクトの立ち上げから，無事に新システム稼働にこぎ着けた2005年4月までの軌跡を追う。
◆2003年10月～2004年2月
経営層との話し合いに時間を費やす
経営統合したのは，日本コムシス，三和エレック（2005年4月，サンワコムシスエンジニアリングに社名変更），東日本システム建設の3社。いずれも電気/通信設備工事会社の中堅～大手である。2003年9月に経営統合すると同時に，経営や業務の効率化を目指した各種の分科会が発足。そこでの成果を情報システムに反映させる役を藤本氏らが任命された。
システム対応の期限は2005年4月に設定された。対象は，営業，経理，人事，給与，外注など基幹システムのすべてである。
当初はERPを導入して，3社が一斉に同じシステムへ移行する形を検討した。実現性をベンダーに相談したが，これは期限に間に合わないと判断し，すぐに断念。3社の中で最大手である日本コムシスのシステムに，残り2社のシステムを合わせる方法を採用することにした。この時点では，藤本氏は1年半かけてじっくりシステム対応していけばよいと考えていた。
しかし，このもくろみはいきなり崩れる。システムの移行策を，各社の社長がなかなか承認してくれなかったからだ。「日本コムシス以外の2社には，マスターからコード体系，業務手順などすべてをガラリと変えてもらわなければならなかった」（藤本氏）。
話し合いを重ねて経営会議を通すまでに2カ月。各社の企画部門と打ち合わせて方向性を固めたころには，さらに2カ月が過ぎていた。
◆2004年2月～6月
各社が1台ずつサーバーを運用
2004年2月，概要設計に取りかかる。ベースとなる日本コムシスの基幹システムは，DB/APサーバーがOracle/UNIX，WebサーバーがWebSphere/Linuxという組み合わせである。アプリケーションは，Web系がJava，クライアント/サーバー系がPowerBuilderで開発したものだ。これと同じ構成のシステムを，全く違うOSと業務パッケージで運用している他の2社に導入することがシステム共通化の概要である（図2[拡大表示]）。
システムを1つに統合せず3つ重複して持つのは，主にセキュリティ上の理由による。経営統合したとはいえ，「3社は別会社なのでデータも分けなければならない。各社のデータを同じテーブルに入れるわけにはいかない」（藤本氏）のだ。
ディスクのパーティションを分けたり，Oracleのインスタンスを複数起動したりすることで，1台のハードウエアに集約する選択肢もあり得た。しかし，それは耐障害性の観点から見送ることになった。「ハードウエアに起因するシステム障害を起こすと，3社すべてが影響を受ける。それを避けたかった」（藤本氏）。
性能の問題もある。日本コムシスのサーバーは自社の業務で既にぎりぎりまでリソースを使っているので，ここに相乗りさせるだけの余力は残っていない。かといって，3社の業務を1台で収容できる性能のサーバーは高価だった。そのため，「（比較的企業規模の小さい）2社の業務を収容するサーバーをそれぞれ購入するのが現実的」と藤本氏は判断した。
2社の業務を日本コムシスの業務にそろえることを原則としたが，どうしても変えられない点はカスタマイズした。例えば日本コムシスは支払日が5日と決まっていたが，他の2社は案件ごとにバラバラで，5日にそろえることは無理だった。支払日のテーブルを作成し，そのマスターを参照するようにアプリケーションを作り替えた。
