「密結合」より「疎結合」なアーキテクチャが求められる理由

この連載では、毎回、DXの推進に有用と考えられる「テクノロジー」と「プロセス」を取り上げ、それがどのような特性を持っており、どういった課題が解決できるのかについて、分かりやすく解説していきます。また、その「テクノロジー」や「プロセス」を通じてDXを実現していくために不可欠な「組織のあり方」についても触れていきます。

DX時代のIT部門に求められるスキルと実行力

企業システムの企画、構築、運用に携わるITプロフェッショナルの方々は、「2025年の崖」という言葉をご記憶だと思います。この言葉は、2018年9月に経済産業省が公開した「DXレポート」に登場しました。DXレポートでは「デジタルトランスフォーメーション」（DX）の重要性を訴えると同時に、日本企業の多くが、その重要性を認識しつつも、思うように進められていない状況へ警鐘を鳴らしていました。「2025年の崖」は、もし状況が変わらなければ「2025年には、最大で年間12兆円の経済損失が、企業および日本に生じる可能性がある」という最悪のシナリオを示すものでした。

あれから4年が経過し、「2025年の崖」は3年後に迫っています。ただ、現時点までの取り組みを振り返り「DXをうまく進められている」と自己評価できる企業は、それほど多くないかもしれません。

その理由のひとつとして、DXでは「IT」の領域だけでなく、経営者の意識やビジネスモデル、組織風土といったものも含めた、複合的な変化が求められることが挙げられます。「テクノロジー」と「非テクノロジー」の両面から、組織のあり方を変えていく必要があるのです。

こうした状況の中、DXに寄与する情報システムのあり方を考え、実現していくIT部門が果たすべき役割は、特に「テクノロジー」の観点から、最新の技術動向を正しく把握し、自社にとって価値の高いものを、適切に取り入れていくことです。

過去に蓄積してきたスキルやノウハウ、確立してきたスキームの維持にこだわり過ぎず、新しい技術をフラットに評価し、良い部分を取り入れて、変えるべき部分を変えていく。DX時代のIT組織には、そうした「テクノロジーの目利き」としてのスキルと実行力が求められます。

Ridgelinez（リッジラインズ）では、DXに取り組む企業を支援する事業を展開しています。この連載では、DXの推進に有用と考えられる「テクノロジー」と「プロセス」を取り上げ、それが事業会社、ITベンダー、SIerのどのような課題を解決できるのかを解説していきます。加えて、これらを活用しDXを実現していく上で不可欠な「組織のあり方」についても触れていく予定です。

• 図１「DX以前」（これまで）と「DX以降」（これから）におけるプロセスとテクノロジーの変化の例（出典元 Ridgelinez）

「密結合」か「疎結合」か－それが問題

第1回のテーマは、「“密結合”と“疎結合”なアーキテクチャ」です。ITにおける「アーキテクチャ」は、システムを構成するさまざまな「要素」と、その要素間の「関係」が、どのようなものかを指して使われます。「密結合」は、要素間の関係性が強く、個々の要素が他の要素へ及ぼす影響が大きな状態、逆に「疎結合」は要素間の関係が相対的に緩く、独立性が高い状態です。

「密結合」「疎結合」という言葉を聞き慣れていなくても、「モノリシック」や「マイクロサービス」という単語は耳にしたことがあるかもしれません。「モノリシック」（“一枚岩”な状況を表す形容詞）は「密結合」な状態、「マイクロサービス」は、文字どおり「小さなサービス」を組み合わせることで「疎結合」なアーキテクチャによるサービスやシステムを実現する手法のことを指しています。

• 図２「密結合」と「疎結合」なアーキテクチャの違い（出典元 Ridgelinez）

近年では、これまで運用してきた「密結合」なアーキテクチャのシステムを、マイクロサービスによる「疎結合」な状態へ移行していくことに取り組む企業が出てきています。では、「疎結合」への要求は、どのように生まれてきたのでしょうか。

急速な変化への対応が難しくなっている「密結合」

まず「密結合」なアーキテクチャによるシステムが、近年、どのような課題を抱えるようになったのかについて考えます。

DX時代には、市場ニーズやビジネス環境が急速に変化します。企業は、そうした変化に適応できるよう、ビジネスプロセスを変えていくことで、競争力を確保したいと考えます。この時、ビジネスプロセスをつかさどるITシステムには、ビジネス側のニーズに応え、新たなプロセスへの対応を迅速に行うことが求められます。

国内企業の多くでは、基幹システム、業務システムが、それぞれ独立して運用されてきました。そうしたシステムは、長い運用年数の中で、その時々の業務部門の要求に対応するため、構築時の古いアーキテクチャの上に「建て増し」するような形で機能が追加されてきました。そのため、構造が複雑化し、利用している技術の老朽化、システム全体のブラックボックス化が進んでいます。

多くの企業では、そうしたシステムが、業務にとって不可欠なものになっている状況があります。現行のビジネスプロセスを維持するために、古いシステムの運用保守、維持管理に、IT予算の大部分を費やさなければならず、DXへ向けた取り組みや新技術の導入に回すリソースが確保できなくなります。さらに、システムの複雑化、老朽化、ブラックボックス化による、予期せぬシステムトラブルの発生や、データ消失のリスクも高まっています。DX推進を阻害する「負のスパイラル」が起こっているわけです。

こうした既存システムの多くは、かつてユーザー企業がITベンダーやSIerに発注し、事業ごとの個別最適を優先した要求に基づいて構築されてきました。そこには、構築を担当したIT企業独自の技術やノウハウが採用されており、多くの場合「密結合」なアーキテクチャに基づいて作られています。

「密結合」なアーキテクチャは、一部の改修や部分的な変更が、システム全体に与える影響が大きくなるため、例えば、データの利活用のために、既存システムと外部のシステムとを連携したいというニーズがあったとしても、その対応は限定的、あるいは煩雑な運用を伴うものとなりがちです。さらに、運用年数が長くなればなるほど、保守に必要な知識やスキルを持った要員の退職や、アーキテクチャを支える製品のサポート終了などにより、システムを維持していくこと自体が困難で、高コストになります。

クラウドベンダーが中心となって発展させてきた「疎結合」

上記のような課題を抱える「密結合」なアーキテクチャに対し、「疎結合」なアーキテクチャは、ビジネスニーズに応える迅速なシステムの改善や変更、柔軟な連携を可能にするものとして作り上げられてきました。その技術を、近年中心的な立場で開発、発展させてきたのは、AWS、Microsoft Azure、Googleなどのクラウドベンダーだと言えるでしょう。

クラウドベンダーでは、サービス運用を維持しながら、利用者向けの新しい機能の追加や改善を、短期間のうちに繰り返します。実際に、ユーザーに受け入れられるかどうかが未知数の機能やサービスでも、まずは競合より早く提供をはじめ、フィードバックを元に、継続して改善を加えていく。受け入れられれば、改善を続けながらサービスをスケールし、見込みがなければ、大きな損失が出る前に方針を転換するか、クローズする。そうした事業の進め方が主流です。

このプロセスを実現するアーキテクチャは、ビジネス機会の損失を最小化できるよう、高い可用性を確保しながら、継続的に機能を改善していけることを主眼に構築され、発展してきました。個々のサービスは、Web APIをベースに「疎結合」な状態で連携し、「仮想化」「コンテナ」「CI/CD」「DevOps」といった新しい技術やコンセプトと組み合わせて、一連のシステムとして提供されます。DXを推進する上で、「クラウドの活用が不可欠」とされる理由のひとつには、クラウドが、これらの技術をベースに、クラウドベンダー自身が求める、高い柔軟性と俊敏性を備えたインフラであることが挙げられます。

疎結合の「メリット」と「デメリット」を理解する

では「疎結合」が、企業のITシステムにおけるすべての課題を解決するかといえば、答えは「ノー」です。どのような技術や手法も、すべての課題を解決する「銀の弾丸」にはなり得ません。重要なのは、それらが登場した背景と、特性を正しく理解して、自社の目指す姿に当てはまるかどうかを検討することです。ここからは「疎結合」のメリットとデメリットについて考えます。

「疎結合」のメリットは、適切な単位で切り分けられ、モジュール化されたサービス（マイクロサービス）の組み合わせで構成されることに由来します。例えば、障害時には、障害の原因となっているサービスのみを、全体から切り離して入れ替えるといったことができるため、システム停止のリスク軽減が可能です。同様に、新たなビジネスプロセスをサービス単位で導入できることで、変化への適応性を向上させることができます。

サービスの呼出やデータのやり取りは、密結合なシステムでは特定の言語やオブジェクトの仕様に依存するやり方で行われることが多いのですが、疎結合なシステムでは、非同期な「メッセージ通信」で行われるのが一般的です。これによって、各サービスの独立性が増し、他のサービスに影響を与えずに機能拡張や入れ替えを行うことが容易になります。こうした特性は、要件の変化に柔軟に対応しながらシステムを作り上げていく「アジャイル」的な手法や、短いサイクルでシステムの改善とリリースを繰り返して完成度を上げていくといった開発スタイルと非常に相性が良いものです。

疎結合なアーキテクチャの持つデメリットは、これらのメリットの裏返しと言えます。

システムを小さな単位に切り分けてサービス化すると、それぞれのサービスを個別に運用、管理する必要が出てきます。そのため、各サービスを動かすクラウドリソースのコスト、運用管理のコストは増加する傾向があります。疎結合なアーキテクチャを実装する際には、サービスのコンテナ化、リソース確保をはじめとする運用作業の自動化、システム全体の監視の仕組みをどうするかといったことを、あらかじめ計画し、同時に導入を進めるべきでしょう。

また、「処理速度」が問題になるケースもあります。先ほど、疎結合ではサービス間の呼び出しに「メッセージ通信」を使うのが一般的だと述べました。サービスの呼出ごとにネットワークを介してメッセージング処理が行われるため、状況によっては、システムに求められる処理速度が得られないことがあります。同様の理由で、複数のサービスが関わる処理の途中で障害が発生した場合、データの整合性を担保することが難しいことがあります。

「疎結合」を採用する場合には、これらの特性を踏まえてシステムを設計する必要があります。また、システムの目的に、疎結合の特性が合わないと判断できるのであれば「採用しない」という決断も必要です。

• 図3 それぞれのアーキテクチャの特性と違いを理解して検討することが重要　(出典元 Ridgelinez)

企業がビジネスの変化に対応することを目的に、疎結合なシステムを導入、運用していくためには、新しいアーキテクチャを構成する技術の習得に加えて、それが必要とされる背景を理解し、戦略的にプロセス、組織、体制を刷新していくことが成功のカギです。