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

今回のテーマは、”移行”について取り上げてみたい。通常は、システム開発のクライマックスに位置するこの”移行”であるが、理想的な移行とは、一世一代の清水の舞台から飛び降りるようなものではなく、限りなく平常時に近い波風の立たないものでありたい。この事は、バックナンバー2013.12.16 DevOpsで言わんとする事に通じる。システムの新機能がどんなに期待多きものであったとしても、移行のビジネスリスクを最小化できるに越したことはない。

近年私は、移行設計をシステム開発後の切替え手順設計という狭い意味で捉えるのではなく、最小リスクでの切替えを何時でも可能とするシステムアーキテクチャの設計と捉えるようにしている。このことは、前職32年のシステム部門生活を通じて一時も開発は止まる事なく、マイグレーション（移行）の連続であったという経験から来ている。若い皆さんは大規模開発が終われば、やがて安定期が訪れるという希望的観測をお持ちの方もおられると思うが、ITの進化が続く限りシステム環境の変化は止まらないと思った方が間違いないだろう。

即ち、移行環境は暫定的なものではなく常設とした方が効率的であることが分かってくる（ベンダー丸投げ開発の場合には、これを撤去して引き上げるので発想も湧かない）。そしてさらに発想を豊かにすると、移行環境をそのまま温存するのではなく、システムそのもののアーキテクチャに組み入れられないか？となる。

ここで登場してくるのが、DBを介した疎結合アーキテクチャである。通常の暫定的な移行環境では、ファイルやメッセージベースでのデータ連携を仮設ブリッジングするケースが多いが、こちらは要（かなめ）となるトランザクションをDB化しておき、いつなんどきアクセスしてもデータ品質が保証される状況を保つようにしておく。紛れもなく常設のシステムアーキテクチャとして。（図1に両者の違いを図示）

このトランザクションDBへの格納処理（Inbound）及び、DBからの抽出処理（Outbound）を常設化したものが、度々バックナンバーで紹介している”トランザクションHUB“（略：TR-HUB）である。このTR-HUBに実装するエンティティは、SCM領域で言えば最も再利用性の高い取引明細データが該当する。そしてこの取引明細データは売上、購入、生産、移動といったあらゆる社内外取引をプールして汎用フォーマット化しておくと取り扱いがさらに楽である。余談であるが、2009年に前職で構築したこのTR-HUBとほぼ同等の機能が、最近、米大手ETLベンダーにてパッケージ製品化されている。

そして、TR-HUBのInbound、Outbound処理には、TR-HUB上のDBを境界とした異なる２つの世界のデータ変換を行なう機能を実装することが可能である。複数システム間のデータ変換処理は、いたるところで記述されるのではなく、当HUB上で一元管理されることがデータ品質を保証する上で重要である。このことは、あたかもネットワーク機器としてのHUBのインテリジェント化に酷似している。さらに付け加えるならば、データ変換は行うが業務アプリケーション機能は有しない。この事もどちらのHUBにも共通である。

最後にTR-HUBの移行適用の種類であるが、大規模システムの段階的移行への適用以外に、M&Aにおける企業システム統合時への適用、クラウド環境への移行時の適用等が挙げられる。これらはいずれもHUBの“常設”を前提とした方がビジネス変化に俊敏に対応できると考える。今後ますます加速する“エンタープライズ・アジリティ”へ貢献するには、疎結合なシステムアーキクチャが求められることは間違いないだろう。