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

今回のブログは「XXXXの誤解」シリーズの最後になる。私からみて近年の究極の誤解は、この「システム再構築」の誤解である。このところ以下のような背景からシステム再構築を企画する企業が増えている。最も大掛かりなケースが、長い間使い続けたメインフレームのダウンサイジングとともに基幹系システムを再構築するもの。次が2000 年前後に構築したオープン系システム（ERP含む）の老朽化により再構築するもの等であろうか。本ブログではこのような再構築に際し、せっかく高額投資の承認を得たにもかかわらずとても残念な結果にならないよう、再構築の意味を再考してみたい。

本ブログシリーズでも度々触れているが、企業を取り巻くビジネスやIT環境は、10数年もたてば何らかの変化があって当然であり、それに応じたアーキテクチャの転換が必要となってくる。その転換を必要とするサイクルはEAの層別に言えばTA⇒AA､DA⇒BAの順に長くなる。最も進化の速いTAにおいては7～8年毎に転換期が訪れ、ハードウェアや新たなネートワークサービスなどは比較的安価に部分的な転換が可能である。そしてAAやDAはIT-SEEDS主導のTAほど速くはないが、それでも14～15年もすれば何らかのビジネス環境が変わり、それに応じてDA、AAの転換が必要となってくるものである（挿入図を参照）。

 さて問題となるのは、各層別のライフサイクルに即してアーキテクチャの転換がなされているかという点である。というのも、15年に一度の再構築のチャンスに、事もあろうにDA、AAに手を加えずにTAだけの入れ替え（ これを業界ではマイグレーションと呼ぶ）で終える事例が増えているように思えるからである。そしてその理由が既存システムのビジネスロジックがブラックBOXだからという情け無いものだったりする。挙げ句の果てに、この“ストレートコンバージョン”に本来の再構築に匹敵する費用をかける結末になったりすれば、もはや開いた口が塞がらない。

ベンターの言うマイグレ・サービスも時には使いようである。例えば、あるレガシー環境（メインフレームやオフコン）上の業務アプリをオープン環境で本来の再構築をする際に、ビジネス側から変更要請のない枯れたアプリがレガシー環境に残ったとしよう。この残存アプリに“マイグレ”を施してレガシー環境を完全撤去に持ち込み、結果、大幅な固定費削減を実現する。このケースのマイグレ・サービスはとても有効な手段である。しかし、マイグレが再構築プロジェクト全体の主役には到底なり得ない。だいたいツールでコンバージョンされた汚いソースを誰がメンテナンスしたいと思うだろうか。

企業内情報システム部門には将来の環境変化に耐えられる情報基盤を提供する責務がある。自分の世代だけが平穏無事に終わればよいというわけではないのだ。いったいツールコンバージョンされたソースを任される次世代がどんな気持ちがするかを考えてみた事があるのだろうか。これもベンダーに任せるからよいのだろうか。メンテナンスの話もそうだが、本来、15年に一度の再構築では、次の15年先のビジネス環境への適合を考慮したDA、AAの見直しが必須である。なぜなら、前後合わせて30年もの間ビジネス環境が変わらない企業は極めて稀だからだ。

これらの事は冷静に考えれば誰でも分かるが、プロジェクトの完成だけを極度に意識する現場（中堅マネジメント層が中心）では十分にあり得る事だ。行き着くところ本物のCIOが不在の日本では先送りされても致し方ない。ITに疎いCEOにはストレートコンバージョンと再構築の見分けはつかない。そしてベンダーは手離れの良いTAの転換には積極的だが、ややこしいDA、AAの転換には消極的である。かつてのSIerにはDA、AAのスペシャリストがいたが、パッケージシステムの勃興とともに明らかに減少しているのが実態である。

このように、システム再構築の誤解はユーザ企業自らが自社のシステムの将来を真剣に考えないことに起因している。裏を返せばエンタープライズアーキテクチャはユーザ企業自らが考えるしかないという事だ。BAはもとより、DA、AA はいくらお金を積んでもベンダーから調達する事は難しい。我々のようなコンサルタントも助言することは可能であるが、決めるのはユーザ企業自身という事になる。必要な社内リソースを投入し計画性をもってすれば再構築は可能である。ただし丸投げは禁じ手である。システム再構築に直面されている企業の方々、今一度、自社のシステムがどのような局面に差し掛かっているかを考えてみてはいかがであろうか。せっかくの高額投資の機会をムダにしない為に。