DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

今回は企業のＭ＆Ａ（Mergers（合併）and Acquisitions（買収））の際に、どのようにモデルを用いてシステム統合のシナリオを描くかについてお話したい。また、本ブログシリーズではあまり登場しない“ＣＩＯの振舞い“にも少しだけ触れてみた。幸か不幸か私は３０年間のユーザ企業システム部門生活の中で、大小６つのＭ＆Ａ対応を経験している。会社統合パターン別に分類すると、自社への吸収合併が２件、相手先への吸収合併が２件、50-50%出資の新社設立が２件で、その規模は大小半々といったところ。この会社統合パターンと規模の組み合わせによってほぼシステム統合のフレームは決まって来るが、新社のＩＴアーキテクチャはまさにＥＡ（エンタープライズ・アーキテクチャ）におけるモデリングアプローチにより決定される。本ブログではＰＭ的観点には触れず、システムアーキテクチャ設計に絞って説明したい。

第１フェーズでは新社のＡＡ（Application Architecture）を描く。ＡＡの図表現はバックナンバー2014.7.1「ＡＡ（アプリケーション・アーキテクチャ）への入り口」で用いたもので良い。まずは両社（３社以上でも可）のＡＡ図を描くところから始まる。既存のＡＡ図が無ければ統合プロジェクトで素早く作成する。このＡＡ図はあくまでも細部にこだわらない事が肝心だ。次に両者のシステム併合案（図１を参照）を描くが、この図がＭ＆Ａシステム統合の最重要成果物であり、この1枚がシステムのみならずＭ＆Ａの雌雄を決定づける。ＣＩＯにとってこの場面は数少ない会社を代表しての大一番である。そして私の経験から統合のセオリーは以下の３つである。①会計システムをはじめとするバックオフィスシステム（ＯＡアプリも含む）は統合スキームの存続会社側に片寄せする事。②工場や現場系のオペレーション主体のシステムは現場の事業継続性を最優先して決定する事（相手由来のバックオフィスとの連携はブリッジを作成）。③新社スタート後のあるべき姿を描き、そこへ向けてＳＴＥＰ別移行計画を立てておく事。①～③いずれもビジネススキームがシステムアーキテクチャを牽引することに変わりはない。（図１参照）。

読者の皆さんは「そんなの当たり前じゃないの？」と思われるかも知れないが、現実にはビジネス側からの様々なプレッシャーやノイズが降りかかる。ＣＩＯの次なる出番はここで、業務分科会の外圧に屈する事なく上記セオリーを貫くことが大事だ。無理難題を突き付けられた際は「Ｘ－ＤＡＹに業務が回らなくてもいいのですか？」とクールに言い放つ事だ。そして、（受入側、送出側）どちらの立場でも“新社のビジネスにとって何が最適か”だけを考える事だ。“誤った自社のひいき“に惑わされてはならない。どうでもいいようなＯＡアプリも案外もめるネタになったりするが、クラウド化で両成敗もありだ。

話を戻し、第2フェーズでは新社のＤＡ（Data Architecture）を設計する。まずは両社の論理データモデル（主にマスタ系）を描くところから始まる。こちらも既存の概念ＥＲ図がなければプロジェクトで素早く簡潔に作成する。そして両社のデータモデルのＦＩＴ＆ＧＡＰを行なうと同時に、コード変換やエンティティの汎化／特化といった（存続会社に向かった）モデル変換ロジックを設計する。このロジックは片寄せ箇所ではデータ移行時のセットアップデータ変換として用いられ、ブリッジング箇所には常設のデータコンバータとして用いられ、それぞれの実装に繋がる設計ドキュメントとなる。

第１、第２フェーズの設計が終了すれば、ひたすらＸ－ＤＡＹに向けての実装とテストを残すのみである。インフラ環境についても（調達リードタイムが長いものは先行する必要があるが）この段階でＡＡに基づく最適なものを用意することになる。そしてこれから先ＣＩＯはビジネス側への安心・安全の報告と、プロジェクトメンバーへの応援と労いに邁進すれば良い。

最後に、本ブログではＭ＆Ａのシステム統合に言及したが、システム以外の面では綺麗ごとでは済まない事だらけであることを付け加えておきたい。Ｍ＆Ａは歴史と文化が異なる２つの組織の合体であり、そこには生身の従業員がいる。経営者が頭でっかちに考えるより遥かに現場（工場、営業など）でのストレスは大きい。企業システムは“経営と現場”の両者が満足する設計でなければいけない。統合時の情報システム分科会は最大限に細やかな配慮が必要である。