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

最近では、デジタルトランスフォーメーション（以下、DXとあらわします）という言葉を耳にしない日はありません。DXをテーマにしたオンラインセミナーも頻繁に開催され、世の中の関心の高さが伺えます。しかし企業が本当にDXに取り組めているかと言うと、遅々として進んでいない状況です。この状況を打破するには、エンタープライズアーキテクチャ（以下、EAとあらわします）への取り組みが不可欠です。しかし、その認識はまだまだ浸透していないように感じます。ですので、この機会にあらためて「EAとは何か」ということをみなさんと考えてみたいと思います。今回はまず、EAの考え方がなぜ必要となるのかを考えてみましょう。

＊＊＊
＜企業システムが陥る悪循環＞
昨年12月20日にＤＸレポート2が公開されました。本レポートには、企業の取り組み状況と、中長短期のそれぞれでこれから求められる対応や政策が書かれています。これを読んでまず目を引くのが、ほとんどの企業が未だ「DX未着手、危機感なし」という残念な状況です。「どうすればDXになるのかがわからない」「DXの進め方が分からない」という企業の戸惑いもあるようです。このことは、企業が長年抱えてきた問題のあらわれといえます。以前のコラムでも述べたように、DXの取り組みは古くて新しい問題なのです。背後には根の深い構造的な問題があります。美辞麗句に飾られたスローガンや、先進事例を真似ただけの対処療法で解決することはできないのです。

左図をご覧ください。私は多くの企業がこのような「混沌に至るループ」に陥っていると感じています。どの企業も多かれ少なかれ企業ITシステムを持ちますが（いわゆる基幹系システム、情報系システムと言われるものです）、そのシステムの複雑化さは近年ますます増大しています。その要因には、例えばビジネスのグローバル化や情報量の増大とスピード化といったものがあります。特に老舗企業や大企業では、長年のシステム投資の積み重ねで複雑化の傾向は顕著です。それにより、多くの企業ではシステム全体像への理解が失われました。これに輪をかけるのが、ベンダーへの丸投げ、IT／ビジネスがわかる社内人材の不足、事業部門とIT部門の縦割り化、などです。しかし、そのような状況でもシステム投資を止めるわけにはいきません。結果として、近視眼的で場当たり的な対応を誘発する構造となりました。そこには、戦略の不在、過度のベンダー依存、そしてソリューション先行といった要因も絡んでいます。現行踏襲のうえに屋上屋を重ねたかのようなシステムも散見されます。そして、さらなるシステムの複雑化を増幅します。このループの行き着く先が、企業システムの混沌（カオス）化です。これでは、DXに取り組むこともままならないということは自明です。自分のところはそこまでひどくはないと言われるかもしれません。しかし、IT業界に長年身を置く私から見て、多くの企業システムは今まさに混沌とした状況といえます。

＜ソリューションアーキテクチャの限界＞
ここで歴史的な考察をしてみます。私はIT業界に身を置き30年以上になりますが、その間の国内ITトレンドのイメージをおおざっぱに描いてみました。

この図では、「混沌に至るループ」に陥る大きな転機が、過去何度もあったということをあらわしています。一つの大きな転機は、1990年代の集中アーキテクチャから分散アーキテクチャへの変化です。私がIT業界に入ったこの頃、世の中では汎用機などの集中管理からオープン化への波が押し寄せていました。現在の情シスで生き字引と言われるような方々も、この前後に社会人になられた方が多いと思います。そして2000年代に入ってのパッケージ全盛時代。分散アーキテクチャから集中アーキテクチャへの揺り戻しです。この時期に、統合パッケージ導入や全社データベース統合に取り組まれた企業も多いのではないでしょうか。そして、マイクロサービス技術などを中心に分散アーキテクチャへの回帰。このようにITアーキテクチャのトレンドは振り子のように往復してきました。そしてその転機のたびに、企業システムはどんどんブラックボックス化していきました。見かけのアーキテクチャは綺麗に整えられたかも知れません。しかし、ビジネスの根幹となるドメイン知識やデータ資産はシステムのあちこちに散在し、全体を把握することが誰にもできなくなってしまいました。なぜこのようなことが起こったのか？その理由は、ソリューションアーキテクチャがもつ限界にあると考えます。

先に断っておきますと、ソリューションアーキテクチャを悪と言いたいわけではありません。私自身がSIベンダーで活動していくなかで知り合った技術者やアーキテクト仲間は本当に優秀な方が多く、ユーザーにとって価値のあるシステムを構築したいという志を持って取り組んでいることを知っています。一方で、私自身もソリューションアーキテクトとして限界を感じることもありました。それが良い悪いではなくて、プロジェクトという枠のなかでアーキテクチャに取り組むがゆえの限界があるということです。例えば、以下の観点があげられます。

・ビジネス／IT戦略の観点
しっかり練られたビジネス／IT戦略がなければ、良いソリューションアーキテクチャをデザインすることはできません。加えて、緊急性はないが重要でかつ長期的に取り組むべき戦略テーマに対しては、プロジェクトの枠を超えた取り組みが必要となります。
・全体最適の観点
決まったQCDの制約のなかでの合理性、効率性を優先するがゆえに、アーキテクチャが部分最適にならざるを得ない場合があります。また、プロジェクトゴールそのものが企業全体でみて部分最適なものであったとしても、それをプロジェクトチームが察知することはなかなかできません。
・アーキテクチャ全体整合性の観点
企業システム全体として見たとき、アーキテクチャの一貫性や整合性は、プロジェクトの枠を超えた枠組みで扱われるべきです。しかし、多くの企業では全体アーキテクチャがブラックボックスのため、目に見える表層的な部分だけで判断することを余儀なくされます。

特定のビジネス課題を解決するためにプロジェクトを立ち上げ、プロジェクトのゴールやスコープを前提にソリューションアーキテクチャをデザインし、プロダクトやサービスを構築する。このソリューション志向のパラダイム（ものの見方、考え方）自体は合理的です。しかし、ここで述べたようにそのパラダイムだけでは限界があり、混沌への流れを止めることは出来ません。

＜もう一つのパラダイム＞
そこで求められるもう一つのパラダイムが、EA（エンタープライズアーキテクチャ）です。
EAの話は次回に譲りますが、ソリューションアーキテクチャとEAの違いは、西洋医学と東洋医学の違いに例えるとわかりやすいかもしれません。

西洋医学は体の悪い部分に直接アプローチし、投薬や手術といった方法で原因を取り除いて治療していくことを特徴とします。一方で、東洋医学は患者の全身観察とそれに基づく全身改善を目的とし、内側から根本的に治すことを考えます。西洋医学は、病気の種類や悪い箇所によって外科、内科など分野がはっきりと分かれます。まさに、ソリューションアーキテクトの世界ですね。東洋医学では、その故障した場所にとらわれずに、まず体全体を俯瞰的にみて診断する、そして一人ひとりの体の個性に合わせて治療方針を考えるそうです。
ソリューション志向のパラダイムでは、前節で述べたように部分な構造にフォーカスをあてることを宿命づけられていました。しかし表層にある部分的な問題を解決しても、根本的な解決にならない場合があります。例えば西洋医学は腫瘍があればこれを取り除く。しかし、真の原因はその人の免疫力であったり血液の循環障害であったりするのかもしれません。それをわからずに腫瘍だけを切り取っても原因は残っているということです。そして、形を変えた問題となって別の所に出てくる。企業システムも同じで、その背後にある全体的な構造に目を向けることが重要です。そして、そこに本質的な問題を見つけることが出来れば、別々の問題に見えていたことが一気に解決するということも多々あります。

西洋医学と東洋医学の融合という考え方があるそうです。今までの西洋医学偏重を改め東洋医学の知見を組み合わせることで、あらたな治療の可能性を拓く試みだそうです。EAについても同様と思います。今こそ、EAに取り組むその意味と価値が認識されるべきと考えます。

＊＊＊
『問題は引き起こした時と同じ考えでは解決することができない』というアインシュタインの有名な言葉があります。現在、多くの企業システムは混沌への道を進んでいるように見えます。このループから抜け出さなければいけません。そのための考え方として企業全体を観察し、改善していくというパラダイムの必要性をお伝えしました。それがＥＡです。次回は、ＥＡの考え方とDXとの関係について取り上げたいと思います。
お楽しみに！