データ活用やDXがどんどん解る用語集　　
疎結合

疎結合（loose coupling）とは、システムが構成要素の組みあわせで作られており、それぞれの構成要素同士の依存関係が高くなく、互いに独立性が高い（密ではなく疎である）状態のことを言います。
主にITシステムに対して用いられる言葉ですが、組織やビジネスに対しても、あるいは多数のITシステムやクラウドサービスなどを組み合わせて作る企業情報システム全体に対しても有用な観点です。システムを疎結合に保つことで変更可能性などを良好に保つことができます。

疎結合の説明は基本的に上記の通りで、それは知っている人もいるかもしれません。ITに関係されている方でも、何となく聞くけれども意味の理解はぼんやりしたままになっている人もいるかもしれません。むしろ解りにくいのは「どうして必要なこととして推奨されているか」ではないかと思います。そこで、疎結合が実現されていない場合に、どのような問題が生じるのかを説明をします。

モノリシック（一枚岩のようなシステム）

特に何も考えずにシステムを開発すると、ほとんどの場合にモノリシック（monolithic）なシステムが出来上がります。システムの各部分が分割されず、一枚岩のように全体が一つの固まりになっている状態をそう呼びます。意図して分割するよう配慮しないと、通常そのようなシステムが出来上がります。

一枚岩のようなシステムは、推奨されてできてしまうこともあります。今も、分割することが良いことばかりかなあ？と思って読んでいる人もいるかもしれません。世間でワンチームという言葉が好きな人がいるように、一つにまとめることが大事であると考えてそうなることもあります。

一枚岩（モノリシック）なシステムには強みもあります。ITシステムなら、モノリシックな実装にした方が動作は効率的で性能が出やすい傾向があります。また、分割した作りにするには配慮すべきことが増え開発工数が増えることもありますが、そのような面倒がなく開発もスムーズに済むことがあります。

しかし困ったことになりやすいのは開発した後です。業務が変わったのでITシステムを改修したいとします。全体が一つの部分になっているので、どの部分が変更すべき箇所か、変更を実施した場合のどこに影響が及ぶのか、確認と理解をシステム全体に対して行う必要がでてきます。最初に作られたあと、変更や追加が繰り返されるとどうしても何がどうなっているのかわからなくなってきますが、その状態で毎回全体を確認しないといけないため変更が困難になってきます。

一部の変更の影響が全体に及んでしまうため、複数人での開発チームや、複数チームでの開発作業で互いの作業への配慮が大変になります。大人数の開発が難しくなるだけでなく、ソフトウェアを部分的にリリースできず毎回システム全体でのリリースをするしかないため、何かちょっと変更するだけで毎回大変なリリース作業が必要になってしまうこともあります。

モノリシックなシステムは、動作しているときにも分割されていないため、何かあるたびにシステムの機能全部がクラッシュしやすくなります。

また、せっかく作ったソフトウェア資産ですから、再利用したり派生製品を作ったりしたいところですが、どこをどう切り出して再利用できるのか良く解らなくなり、再利用性が低下します。

このような問題は、ITシステムだけでなく同様な構造を持つ組織やビジネスでも発生します。

密結合(tight coupling)

分割しないと問題が起こりうることはわかりました。しかしなぜ「分割しましょう」ではなく「疎結合にしましょう」なのでしょう。それは、分割しただけでは「密結合」の状態に陥ってしまうことが多いためです。

システムを構成要素に分割したとしても、構成要素間が複雑に絡み合ってしまっていたら、シンプルになるどころか、よりいっそう何が何だかわからなくなってしまいます。

そんなことにならないよう、考えてきちんと分割する必要があります。しかしながら、最初はきちんと分割出来ていても、改修されるうちにだんだんと意味不明になってしまうこともあります。

現在だけではなく、将来の変更を見越してどのように分割するか考える必要があります。さらには、その分割で開発チームの分業やリリースがスムーズに行えるかも考えておく必要があります。再利用を考えているなら、同じく考慮をしておく必要があります。そのような様々な配慮が十分ではないと、システムを部分に分解することが良い結果をもたらさないことがあります。

このような「良くない状態」では、構成要素（システムの各部分）の間で無用に複雑な依存関係（機能の呼び出しなど）があり、それより各部分が（無用に）密に関連している状態になっています。このような状態を「密結合」と呼びます。

このような問題を起こさないように、密結合にならないように考えて構成要素に分割されていることを「疎結合」と言います。以下、ITシステムの開発を例に説明しますが、組織やビジネスの設計など、その他システムについても同じようなことがあります。

結びつきが緩やかで、各部分の独立性が高い

密結合になってしまわないように、全体の構造をよく考えて設計することで、各部分の依存関係を少なくした状態のことを「疎結合」と呼びます。

理解しやすくなる（全部理解しなくてもよい）

各部分の独立性が高くなり、システムの他の部分とは整理された呼び出し+関係だけになるので、しっかり理解するのはその部分だけで済むようになります。システム全体の確認や理解が必要な状況が少なくなり、開発や運用において効率や品質が向上します。

変更しやすくなる（変更の影響確認が簡単になる）

ある部分を変更する際に、変更の影響を受ける部分が局在化されます。変更作業が容易になり、影響範囲を確認し変更して大丈夫かの確認も簡単になります。システムの変更が迅速かつ低コストにできれば、事業展開も迅速にできることになり、すなわちビジネスの迅速性や効率性そのものを改善することになります。

将来に向けて変更が容易になる

適切に疎結合化されている場合、将来に向けた様々な変更もスムーズになります。一般的にシステム改修は新規開発よりも容易でなく、開発者にも負担をかけることが多いのですが、この問題が緩和されます。

さらには変更後のシステムが修正により複雑になることも緩和できます。改修により複雑怪奇になりにくいことは、システムの寿命を延ばすことにつながります。すなわち現在の複雑さを緩和するだけでなく、将来の複雑さも緩和することができます。

依存関係が少なくなることで、それぞれの作業担当範囲をきれいに分割しやすくなり、多人数での開発、あるいは複数チームでの開発がスムーズになります。リリース作業も全体での調整の必要性が少なくなり、各部分で独自に進められるようになります。

整理されて部分に分割されているので、再利用がやりやすくなります。既存の資産を使って新システムを低コスト迅速に開発する取り組みや、あるいは複数のシステムで同じモジュールを共用する取り組みが容易になります。

さらには利用している部品を差し替えやすくなります、Linux向けに作ったアプリのOS依存部分を差し替えてWindowsで動作させるようなことも容易になります。

また「業務の構成要素」を単位として再利用可能部品の整備をしておけば、ビジネスのニーズに応じて、必要なシステムを部品を組み合わせて素早く開発できる環境も用意できます。

モノリシックなシステムでの密な最適化が理想だと思っても、クラウドサービスや他社システムとの連携ではそれができません。クラウドサービスの仕様を自社の都合に合わせて変えてもらうことは出来ないからです。

今後ますますITを介した他社との協業が盛んになるはずですが、広範な連携になればなるほど、他社との密な調整による連携ではなく、疎結合の考え方による連携が求められるようになるはずです。

まず大事なことは、疎結合の概念自体を知って意識することでしょう。もしかすると、密なチームワークを徹底して乗り切るようなことが素晴らしいと思っていた人にとって、ここまで書いてきたことは考慮すらなかった視点かもしれません。

もう一つは、だからと言って単に分割すればいいわけではなく、さらには分割にはコストもかかることです。分割には設計センスが必要であり、そもそもどの程度どのように分割するかについても判断や設計のセンスが必要になります。

昨今、クラウド上でのシステム開発でマイクロサービスという考え方が注目されていますが、これはシステムを多数の独立した小さい単位に分割して開発する考え方です。一方で、内部の論理的構造が疎結合的に整理されたモノリシックなアプリケーション（モジュラーモノリス）が現実的だという主張もあります。

状況に応じた適切な設計センスが必要になりますが、組織なら組織の設計論が、ソフトウェアなら長年多くの議論が続けられてきたソフトウェア設計の方法論の世界があります。以下、簡単なものですが、考え方の目安となるようなものです。

• 構成要素で適切に完結しているか
  何かするためにあちこちを呼び出す必要がある状況だと、呼び出し関係の全体構造そのものが必然的に密結合になってしまいます。一方で、何でも内部で済ませると肥大化するので「何かをするため」に必要なことが、その構成要素内で適切なレベルで完結している必要があります。
• 外から利用できること/利用できるべきではないこと
  APIなどの形で整えられ、長期的に維持される公式のインタフェースを介して呼び出すようにすることで、管理や維持が難しい依存関係（モジュール内部機能の直接呼出しなど）が生じにくくなります。
• 一緒になっているべきではないものを分割し整理する
  明らかに関連性のないものが一つにまとめられている場合はもちろん、本来少しずつ違うものを配慮不十分にまとめてしまっていると、解りにくく複雑になってしまうことがあります。
• 共通部分や共通する概念を散在させない
  システムのあちこちに同一のものが（理由もなく）散在するのは良い状況とは言えません。例えば、各システムで印刷機能を個別に実装しているなら、それらを一つにまとめると意味があることがあります。共通する概念や関心や責務を、分散させずにそこに集めると、意味的な複雑さをシンプルにできることがあります。
• 「本質」や「不変性」を見つけてモデリングする
  例えば業務システムを作っているなら、その事業や事業の機能の備える本質を反映したモデリングを行えば、事業の本質と結びついた質の良い疎結合性や再利用性も備えることになるでしょう。また、時間や状況が変わっても変化しない要素に注目すれば、長い間その構造を維持しやすくなるでしょう。
• 「つなぐ」手段を用いる方法：直接呼び出さない、連携基盤を用いる
  「つなぐ」手段を間にはさむ方法で、依存関係が複雑になることを抑えることができます。個々の連携から生じる依存関係の緩和や、連携全体の管理や変更を容易にできることがあります。
  例えばシステムから他システムの機能を直接呼び出すと、呼び出し元と呼び出し先での多対多で複雑な相互依存関係が発生しやすいですが、直接呼出しの代わりに一度ファイルに書き出してから連携すれば、各システムと共通ファイル形式の関係性に依存関係が整理されます。これも一種の疎結合化と言えます。
  また、EAIやiPaaSなどの「つなぐ」技術を連携基盤として、連携処理をそこに集約すれば、連携処理がスムーズに開発実現できるだけでなく、依存関係そのものが連携基盤上に一元的に集約され、依存関係の管理や整理をしやすくなるので、密結合に陥ることを抑止できることがあります。

• EAI
  • -システム間をデータ連携して「つなぐ」ことで、絡み合った密結合にせずに、分散したシステムやデータを連携させる手段です。
• ファイル連携
  • -ファイルを経由することで、呼び出し元と呼び出し先の依存関係を減らす手段としても使うことができます。
• iPaaS
  • -システムやデータを「つなぐ」力をクラウドサービスとして提供したものがiPaaSです。
• API
• クラウド連携
• Excel連携

興味を持たれましたら、ITシステムやクラウドなど様々なシステムを、それぞれの独立性を保ったまま「つなぐ」考え方で連携する製品を実際に試してみてください。

当社で開発販売しているデータ連携ツール「DataSpider」は、長年の実績がある、「つなぐ」ツールです。

通常のプログラミングのようにコードを書くこと無くGUIだけ（ノーコード）で開発できるので、ビジネスについて良く理解し、自社のサイロ化の具体的な課題についても把握できる業務の現場が自ら活用に取り組めることも特徴です。

簡易な連携できるツールは世の中に多くありますが、GUIだけでプログラマではなくても十分に使える使いやすさをもちつつ、「高い開発生産性」「業務の基盤（プロフェッショナルユース）を担えるだけの本格的な性能」を備えています。IT利活用の成功を妨げている「バラバラになったシステムやデータをつなぐ」問題をスムーズに解決することができます。

無料体験版や、無償で実際使ってみることができるオンラインセミナーも開催しておりますので、ぜひ一度お試しいただけますと幸いです。

ファイル連携基盤の決定版「HULFT」

国内で圧倒的な実績がある、国産ファイル連携ミドルウェアのデファクトスタンダードである「HULFT（ハルフト）」を是非お試しください。

ITシステムに対して最高度の対応が求められる金融機関でその基盤として長年使われているなど圧倒的な実績があります。あらゆる環境が、あっという間にファイルでつながった世界が出来上がります。

ファイル連携は古い技術であるような印象もあるかもしれませんが、ほとんど全ての環境やプログラミング言語などが対応しているファイルを経由した連携により、多種多様な呼び出し元と呼び出し先の依存関係を減らして疎結合を実現する手段としても長年利用されてきました。

• ファイル転送の仕組みを学ぶ HULFT 製品紹介・ハンズオンセミナー
• HULFT-WebConnect 製品紹介・ハンズオンセミナー