【事例】システム共通化に奔走した1年半
初期の4カ月遅れを取り戻す---日本コムシスなど3社（下）

◆2004年7月～10月
移行システムで遅れを取り戻す

図3●移行システムを開発しプロジェクトの遅延を取り戻す 移行システムは「中間テーブル」「プロシージャ」の2つで構成する。移行元はCSV形式でデータを受け渡せばよい

図4●ユーザーIDをユニーク化し運用の負荷を軽減 3システムが併存しても運用の負荷が高くならない方法を考え出した。会社をまたぐ異動があっても，人事台帳を変更するだけでアプリケーションのアクセス権まで自動的に反映される。利用者のIDは退職するまで変わらない

図5●現場を支えたプロジェクト体制 コード体系の変更など利用者の使い勝手に大きな変更を伴った。エンドユーザーを含むワーキング・グループを組織したおかげで，業務の移行が比較的スムーズに進んだ

　2004年7月，開発に入る。この時点で残り10カ月を切っていた。ここから10月までの3カ月間で，プロトタイプの開発からテストまでを完了させる必要があった。既にあるアプリケーションを展開するだけなので，プログラミングの工数はあまり必要ない。最大の難関はデータ移行だった。

　3社のデータベースはそれぞれスキーマが複雑に入り組んでいる。日本コムシスの技術者は他社のデータベース構造が分からないし，移行元2社の技術者も日本コムシスのデータベース構造が分からない。「例えば，施工案件の設計情報に変更が起きたとき，どういう入力があってどこに反映されるかが分からない。それらを理解して移行プログラムを作成していては，とても間に合わない」（藤本氏）。

　そこで，以前から考えていた“移行システム”の具体化に乗り出した。この移行システムは，双方の技術者が理解しやすい構造の中間テーブルを介して，データを受け渡すものだ（図3[拡大表示]）。「中間テーブル」と「プロシージャ」で構成する。プロシージャには，データの存在や整合性をチェックしたり，本体のテーブルにデータをコピーしたりする機能を持たせる。

　移行元からCSV形式でデータを受け取ると，Oracle上の中間テーブルに格納する。中間テーブル上では，データの存在や整合性をチェックしたり，必要に応じて値を集計したりする。外注システムであれば「外注管理番号設定ルールに沿っているか」「支払金額と契約金額，出来高率の整合性は取れているか」などをチェックする。

　エラーが出たら，小さなものは手作業で修正する。大きなものは，CSVファイルにデータを変換するプログラムに手を入れる。チェックが完了したら中間テーブルから本体のテーブルにデータを移行する。

　データ移行作業の役割分担は，CSVファイルで受け渡すまでを移行元2社の担当とした。中間テーブル上での各種チェック以降は日本コムシス側が受け持った。「移行システムがなかったら，移行期限までに間に合わなかっただろう。これを作ったことで，次に経営統合があったときにもそのまま使える」（藤本氏）。

サーバー併存に伴う運用問題を克服

　データ移行と並行して，ユーザー・アカウントやそれを管理するディレクトリを整備した。3サーバーが別々に併存するため，システム管理者の負荷が高くなるからだ。会社間の出向や転籍があるたびに，アカウントの追加や削除の手間が発生する。それを避けるために，3社間でディレクトリ・サーバーを連携させることにした（図4[拡大表示]）。

　日本コムシスは，以前からノベルの「eDirectory」を使って業務システムのログインを一元化している。これ自体は一般的なディレクトリ・サーバーの使い方だが，ここからが藤本氏の自信作である。

　まず，グループ会社内で各従業員にID（ユーザー・アカウント）を一意に割り振るため，3社共通のマスター・テーブルをOracle上に用意した。グループ会社のいずれかに従業員が入社すると，入社順にIDが割り振られる。

　このマスター・テーブルの変更は，各社の人事台帳に即座に反映される。さらにノベルのメタディレクトリ「DirXML」（現在の製品名はNsure Identity Manager）を経由して，Active Directoryなど業務システムのログインに利用する複数のディレクトリにも受け渡される。

　異動の際も，各社の人事台帳の変更がわずか数分でディレクトリに反映される。つまり，人事台帳の変更だけで各業務システムへのアクセス権が変更される。

　この仕組みの優れたところは，グループ会社間でIDの体系を一元化していることにある。出向や転籍があっても，ID/パスワードを登録し直す必要がない。前の会社で使っていたID/パスワードをそのまま使える。日本コムシスでは，これを「IDのポータビリティ化」と呼んでいる。

◆2004年11月～2005年4月
無事，稼働。運も良かった

　2004年11～12月に月次決算をテスト稼働し，2005年1～3月のエンドユーザー教育に入る。厳しい状況の中，ここまでスケジュール通り進められた理由を，藤本氏は「プロジェクト体制にあった」と振り返る（図5[拡大表示]）。

　キックオフまでの苦労が大きかった半面，その後はトップダウンの体制作りに現場はかなり救われている。プロジェクトはエンドユーザーも参画するワーキング・グループが核になり進められた。情報システム部門はそれを支援する立場と位置付けられた。もし情報システム部門がエンドユーザーを説得する形で進めることになっていたら，スケジュール通りに進んだかどうか分からない。その意味では運が良かったという。

　三和エレック，東日本システム建設の2社は，事業所部門，社員，工事，受注，取引先などすべてのコードを日本コムシスの体系に合わせることになる。エンドユーザーの反発も一部にないわけではなかったが，概ね藤本氏の考えを理解し賛同してくれた。

　ワーキング・グループは，運用マニュアル作成や教育まで含めて主体的に実施した。大きな問題もなく進み，2005年4月，無事に本稼働を迎えられた。