【#02】「正解のない問題」を解こう！ システムに柔軟性をもたらすエンタープライズアーキテクチャ
「システム設計と人生設計は同じ！」「システム設計の考え方を人生設計にも役立てよう！」をテーマに技術的で意識高い系の記事を投稿しています。
今回は、企業のITシステムのあり方を示したエンタープライズアーキテクチャと、エンタープライズアーキテクチャがシステムにもたらす柔軟性ついて考察しています。
今回の結論はこちらです！
✅ エンタープライズアーキテクチャは変更の範囲を限定できる。
✅ エンタープライズアーキテクチャの４層構造がシステムに「柔軟性」をもたらす。
✅ システムに「柔軟性」をもたらすためには「正解のない問題」から逃げてはいけない。
エンタープライズアーキテクチャは変更の範囲を限定できる。
ITシステムを設計するときに、何の指針もない状態で設計を始めるのはさすがに大変です。でも、大丈夫。先人達が企業のITシステムを設計するときの指針として「エンタープライズアーキテクチャ」という知識体系をまとめてくれています。エンタープライズアーキテクチャについては、IT用語辞典に以下のような解説があります。
エンタープライズアーキテクチャとは、大企業や政府機関などといった巨大な組織の資源配置や業務手順、情報システムなどの標準化、全体最適化を進め、効率よい組織を生み出すための設計手法。
（出典：IT用語辞典）
つまり、エンタープライズアーキテクチャとは、エンタープライズ（事業）を行うためのITシステムを効率よく設計するための設計手法の１つです。詳細は専門書を参照ください。個人的には「システム構築の大前提－－ITアーキテクチャのセオリー（リックテレコム）」をよく参考にしています。
このような設計手法がまとめられている背景には、エンジニアが思い思いにシステムを設計した場合、作り直しが頻発したり、後々メンテナンスできなくなるなど、非効率な事例が多々発生したことがあったのではないかと思われます。
エンタープライズアーキテクチャでは、システムを４種類のアーキテクチャが層状に積み重なったものとして捉えます。その４種類のアーキテクチャは、最上位層（第４層）から順に「ビジネスアーキテクチャ（BA）」「データアーキテクチャ（DA）」「アプリケーションアーキテクチャ（AA）」「テクノロジーアーキテクチャ（TA）」と名付けられています。
そして、各層では、以下のようなアーキテクチャを設計することが唱えられています。
第４層：ビジネスアーキテクチャ（BA）
事業の目的を達成するための組織と組織間の関係
第３層：データアーキテクチャ（DA）
各組織が利用するデータとデータ間の関係
第２層：アプリケーションアーキテクチャ（AA）
各データを参照するアプリケーションとアプリケーション間の関係
第１層：テクノロジーアーキテクチャ（TA）
各アプリケーションが動作するのハード及びソフトウェアとハード及びソフトウェア間の関係
最下層にあるTA（ハード及びソフトウェア）がAA（アプリケーション）を支え、AAがDA（データ）を支え、DAがBA（組織）を支え、BAが事業の目的達成を支えているという４層構造です。
そして、エンタープライズアーキテクチャでは、基本的には第４層（BA）〜第１層（TA）の順でシステム設計を進めていくことが唱えられています。まず、事業の目的を達成するためにBAを設計し、BAを実現するためのDAを設計し、DAを実現するためにのAAを設計し、最後にAAを実現するためにのTAを設計するという具合です。
実際には、BAから順番に設計を進めるものの、「技術的に実現できるかどうか？」という観点でTAの設計を頭の片隅に置きつつ、第１層〜第４層を行ったり来たりしながら設計を進めていきます。そして、最終的には「いかにも、BA→DA→AA→TAの順番で設計したかのような設計結果」にまとめます。
このような設計とすることで、各階層に変更を加えた場合の影響を一方方向にできます。
例えば、DAはBAを実現するために設計しているため、BAに変更を加えた場合、その変更の影響はDAに及び、DAを再設計することになります。しかし、その逆で、DAに変更を加えた場合、その変更の影響はBAに及ぶことはないため、BAを再設計する必要はありません。ある階層に変更を加えた場合、その変更の影響は、変更を加えた層よりも下の層にしか及ばないということになります。
その結果、エンタープライズアーキテクチャの設計方法に従って設計されたシステムは、以下のような特徴を持つことになります。
・BAに変更を加えた場合は、DA、AA、TAを再設計する。
・DAに変更を加えた場合は、AA、TAを再設計する。
・AAに変更を加えた場合は、TAを再設計する。
・TAに変更を加えた場合は、他の階層の再設計は必要ない。
つまり、エンタープライズアーキテクチャの設計方法に従い設計することで、システムに加えた変更によって再設計しないといけない範囲を限定することができます。
エンタープライズアーキテクチャの４層構造がシステムに「柔軟性」をもたらす。
では、エンタープライズアーキテクチャで設計した場合、最も嬉しいことは何でしょうか？それは、システムに環境の変化に柔軟に対応できる力が備わることです！そうなんです。ビジネスを成功に導くための柔軟性が備わるのです！
その秘密は、BA、DA、AA、TAの４層構造にあります。
実は、この４層は「変化スピードの早い順」に重なっています。つまり、TAの変化スピードが一番早く、BAが一番遅いといことになります。そして、TAの変化スピードが一番早いということは、TAに変更を加える頻度が一番多いということになります。エンタープライズアーキテクチャの設計方法に従い設計されたシステムの場合、TAに変更を加えても他の層への影響が及ばないため、頻繁に発生するTAへの変更を素早く行うことができるのです。
逆に、TAへの変更が他の層に及ぶような設計になっている場合、他の層の影響箇所の再設計が必要になるため、頻繁に発生するTAへの変更を素早く行うことはできません。
では、TAに起こる変化とは具体的にどのようなものでしょうか？
TAはハード及びソフトウェアの階層です。システムを構成するコンピュータ機器、利用している市販ソフトウェア、エンジニアが作成したプログラムなどが相当します。TAに起こる変化とは、具体的にはコンピュータ機器のCPU性能の向上や、市販ソフトウェアへの新機能追加、作成したプログラムの修正などが該当します。確かに頻繁に変化が起こっているイメージではないかと思います。
特に、クラウドサービスを用いてシステムを構築されているエンジニアの方はその変化の激しさを実感されているのではないでしょうか？クラウドサービス最大手であるAWSの場合、年間約1000回（１日２〜３回）ものアップデートが行われています。そのため、現状の最適な設計が、１年後に時代遅れになってしまっていることも少なくありません。
このようにシステムが動作しているハード及びソフトウェアの変化（いや、「進化」と呼ぶべき！）を受けて、コスト効率化や性能向上を目的にシステムのTAに変更が加えられることになります。
でも、大丈夫。エンタープライズアーキテクチャなら、４層構造で環境の変化に柔軟に対応することが出来ます。もし、変化が起こったとしても、歓迎して受け入れることができるでしょう。
システムに「柔軟性」をもたらすためには「正解のない問題」から逃げてはいけない。
ここまで読まれて「お〜なるほど、なるほど。じゃ、エンタープライズアーキテクチャで設計すればいいわけだ。。。でも、事業目的を達成するということを起点に、組織、データ、アプリケーションの順番にシステムを設計するって・・・当たり前じゃね？」と感じたない方も多いのではないでしょうか？
その通りです。エンタープライズアーキテクチャは、システム設計として、当たり前の設計方法です
。ですので、全てのエンジニアが当たり前のことを、当たり前のように行っていれば、全てのシステムに柔軟性が備わっていることになります。
しかし、実際にはそうなっていません。
その原因は、多くのエンジニアにとってBA ・DA・AAを設計することは、非常に面倒臭い作業であり、ついついTAの設計から始めてしまうためです。
一言でシステム設計といっても、BA ・DA・AAの設計とTAの設計とでは種類が違うと言えます。BA ・DA・AAの設計は、組織構造やデータの関連など、論理的な「あるべき姿」を設計する論理設計です。一方、TAの設計は、ハードウェアやソフトウェアなど、物理的に存在するものを設計する物理設計です。論理設計では、抽象的な議論が必要である一方、物理設計はより具体的な議論を行います。
そして、物理設計を得意とするエンジニアは多数いる一方、論理設計が得意なエンジニアは少数である、というのが私の印象です。ある程度キャリアを積んでいても、物理設計を主戦場としているエンジニアの方は、論理設計と物理設計の違いすら理解できていないこともあります。
この状況は、安宅和人さんの著書「シン・ニホン」の第4章「データ×ＡＩ世界で戦うには」における以下の解説にも通じるものがあると考えています。なぜなら、解説にある「ビジネス課題とサイエンス、エンジニアリングをつなぐアーキテクト的な人材が必要だが、ほとんどの会社で枯渇している。」に関して、「ビジネス課題とサイエンス、エンジニアリングをつなぐ」ことは、まさにBA ・DA・AAの設計（つまり、論理設計）だからです。
おそらく５００～１０００万人程度いると思われるミドル・マネジメント層の現状だ。（中略）。また、この層にこそビジネス課題とサイエンス、エンジニアリングをつなぐアーキテクト的な人材が必要だが、ほとんどの会社で枯渇している。ちなみに経団連のＡＩ活用原則ＴＦ（報告書「ＡＩ活用戦略」２０１９年２月発表）の委員として検討した際の見立てでは、ほぼすべての企業にこのような人がいないという状況だ。
（出典：安宅和人. シン・ニホン AI×データ時代における日本の再生と人材育成）
では、なぜ、論理設計が得意なエンジニアは少数なんでしょうか？
それは、具体的で正解のある物理設計と、抽象的で正解のない論理設計を比べた場合、論理設計は圧倒的に面倒臭いからです。
物理設計には明確が正解があります。ちょっとインターネットを調べればドンピシャの答があったり、プログラミングの間違いはコンパイラが教えてくれたりします。「動けば正解」の世界です。しかし、論理設計はそうはいきません。ある程度、経験者が導いてくれたとしても、誰も正解を知りません。エンジニアは、ステークホルダーが納得する「納得解」を探るしかありません。この作業は、早くプログラミングしたくてウズウズしているエンジニアにとっては、苦痛で面倒な作業になります。
そして、多くのエンジニアは、耐えきれなくなってTAの設計から始めてしまいます。「CI/CDでDevOpsだ！」とか「ローコードで爆速開発！」などという流行りの最新技術ワードが耳に飛び込んで来た瞬間、反射的にTAの設計に飛びついてしまうのです。しかも、TAの設計から始めても、それなりのシステムが出来上がってしまうので、そのアプローチに疑問を感じることも少ないのでないかと思います。
その結果、TAを起点としたシステムが出来上がります。このシステムはエンタープライズアーキテクチャの真逆の構造を持っています。TAに変更を加えた場合、全ての層に影響が及ぶというシステムです。当然、柔軟性は備わっていません。時が進めば使われなくなります。（もちろん、短期間しか使わないシステムであれば、それでもOKです。）
システムは私達エンジニアの大切な命の時間を費やして開発した作品です。その作品がビジネス価値を生み続けるためにも、「正解のない問題」から逃げてはいけません。流行りの最新技術に反射的に飛びつくよりも、「正解のない問題」にじっくり向きあることの方が大切です。
そして、それは人生も同じです。
まとめ
今回の記事のまとめです。
✅ エンタープライズアーキテクチャは変更の範囲を限定できる。
✅ エンタープライズアーキテクチャの４層構造がシステムに「柔軟性」をもたらす。
✅ システムに「柔軟性」をもたらすためには「正解のない問題」から逃げてはいけない。
次回は、エンタープライズアーキテクチャの設計方法を、私達の人生設計にも活かす方法を考察したいと思います。
【参考文献】
この記事が気に入ったらサポートをしてみませんか？