変化に強いシステムを創る

ここでは、環境の変化に柔軟に適応できるシステムを創るポイントについて以下の観点で説明します。

• 変化に強いシステムが求められる背景
• 変化に強いシステムを創るための３つのポイント
• 変化に強い情報システム
• 関連動画

ここでいうシステムとは、情報システムやビジネスなど
相互に影響を及ぼし合う要素から構成される、まとまりや仕組みの全体
のことです。

変化に強いシステムが求められる背景

変化が激しく、不透明で先行きが予測できない昨今の経営環境を、

• Volatility（変動性）
• Uncertainty（不確実性）
• Complexity（複雑性）
• Ambiguity（不透明性）

の頭文字をとってVUCA（ブーカ）という言葉で表すことがあります。
それは、SNSやモバイル技術によって人と人がつながる時間や距離が短くなったことで、
個人の欲望や考えが、複雑なネットワークを介してすぐに世界中に広がり、
いつどこで、どんな需要が生まれるか読みづらく、欲求の新陳代謝も激しくなっているからではないでしょうか。
このような時代、仮説と検証を繰り返しながら、ビジネスや情報システムを環境の変化に俊敏に適応させながら進む必要があります。
現在、多くの会社が、
ビジネスの変化が加速し、ビジネスと情報システムが密接化する中、全体の設計図もなく、必要に応じて情報システムを導入してきた結果、

• 大規模で複雑なシステムがサイロのように乱立している
• 重複して整合していないデータが散在している
• 個別の業務やシステムは詳しいが全体を理解できる人や資料がない

というカオスで雁字搦めな状況に陥っています。

それでは、どのようにすれば、環境の変化に柔軟に適応できるシステムを創ることができるのでしょうか。

変化に強いシステムを創るための３つのポイント

変化に強いシステムとは、ビジネスや情報システムが生産性や保守性が高い仕組みになっているということです。

• 生産性が高い仕組み
  新しいビジネスや情報システムがすぐに構築できる。
• 保守性が高い仕組み
  既存のビジネスや情報システムをすぐに変更できる。

変化に強い構造を創るときのポイントは次の３つです。

• モジュール化
  モジュールとは、システムを構成する交換可能な要素、部品のことです。
  モジュール化とは、ビジネスや情報システムの構成要素を、インターフェース（仕様）と実装（実現）部分に分離し、相手の要素にはインターフェースだけを公開し、実装（実現）部分はブラックボックにすることです。
  これによって、相手の要素にはインターフェースだけにアクセスできるようになり、実装（実現）部分を変更しても影響を受けることはありません。
  なので、実装部分が自由に交換でき、保守性が向上するとともに、モジュールを再利用することによって生産性が向上します。
  つまり、モジュール化によって交換可能性と再利用性が上がり、結果的に保守性と生産性を高めるのです。
  
• レイヤ化
  レイヤ化とは、ビジネスや情報システムを抽象レベルによって階層化することです。
  ここでは、システムを、抽象レベルが高い順に、概念レベル、論理レベル、物理レベルと定義しています。
  抽象レベルの高いレイヤは、環境が変化しても変化しにくい部分で、低いレイヤは、環境の変化に応じて変化します。
  抽象レベルによって変化しにくい本質の部分と、変化しやすい現象の部分を分け、下位の要素が上位の要素に依存する関係にすることで、環境が変化した場合、変化する部分だけ置き換えることができるようになり、環境の変化に柔軟に適応できるようになります。
  レイヤ化の要は、システムの本質を見極めることです。
  ビジネスであれば、誰に何の価値をどのように提供するのかというビジネスモデルです。
  不変的なビジネスモデルを見極めた上で、それを実現するため手段を柔軟に変えることができることが重要なのです。
  
• プロセス統合
  プロセス統合とは、ビジネスや情報システムの構成要素（モジュール）を、情報システムのユーザーやビジネスのステークホルダーなどに価値を提供するプロセスをベースに統合することで、これによってビジネスや情報システムを価値を提供する仕組にすることができます。
  

このように、変化に強いシステムを創るための３つのポイントは、システムを、それを構成要素に分けて、価値を提供する構造にする分析と統合のプロセスなのです。

変化に強い情報システム

情報システムの例を見ていきましょう。

モジュール化

次の図は、モジュール化された情報システムと、モジュール化されていない情報システムを比較したものです。

これを見るとモジュール化された情報システムのほうがシンプルでわかりやすいことがわかります。
モジュール化されていない場合、サブルーチンを構成する処理に、他の処理が直接アクセスするので、さまざま処理な処理にさまざまな処理がアクセスし、複雑になるとともに、処理を変更することで、それにアクセスする多くの処理影響を及ぼすことになります。
つまり、サブルーチンはホワイトボックスなので、他の処理によって雁字搦めになり、交換かつ再利用不可能な状態になります。
一方、モジュール化された情報システムの場合、モジュールのインターフェースだけ公開しているので、ブラックボックス化された実装（実現）部分を交換しても、他のモジュールに影響することはなく、再利用可能な単位として活用することができます。
オブジェクト指向プログラミングは、オブジェクトというモジュール同士の相互作用（メッセージパッシング）によってソフトウェアを組み立てることで、ソフトウェアの再利用性を高める手法です。

特に、オブジェクトとの多態性（ポリモーフィズム）という性質を利用することによって、オブジェクトと再利用性を上げることができます。
さて、次の図は、企業のアプリケーションシステムをマイクロサービスでモジュール化した例です。
マイクロサービスとは、ビジネス機能を一つのサービスとして提供したソフトウェア部品のことです。

この例では、画面まわりを処理するフロントエンドアプリケーションが、ビジネスロジックとデータアクセスを制御するマイクロサービスを使う構造になっています。
これによって、新しいフロントエンドアプリケーションを開発するとき、すでに在るマイクロサービスを部品として再利用することができるので、開発の生産性が上がり、企業を変化に強い構造にすることができます。
また、データ構造が変わった場合、関連するマイクロサービスは影響を受けますが、そのマイクロサービスを利用するフロントエンドアプリケーションは一切影響受けないので、高い保守性を実現することができ、企業の情報システムを変化に強い構造にすることができます。

レイヤ化

情報システムのレイヤ構造の例として、MDA（Model-Driven Architecture：モデル駆動アーキテクチャ）を紹介します。
MDAは、標準化団体であるOMG(Object Management Group)が「20年持続するソフトウェアアーキテクチャ」を目標として2001年に提唱した概念で、以下の３つのモデルから構成されています。

• CIM（Computation Independent Model）

計算機処理に依存しないモデル。

• PIM（Platform Independent Model）

IT基盤に依存しないモデル。

• PSM（Platform Specific Model）

IT基盤に特化したモデル。

MDAでは、システムを構築するとき、この３つのモデルを分けて考え、CIM→PIM→PSMという流れで設計することで、より堅牢なシステムをつくることができるとしています。
まず、CIMですが、これは、業務の概念構造を表すモデルで、
業務がシステムに依存してはならない（システムが業務に依存する）
という考え方に基づいて設計します。
概念構造とは、私たちが認識する概念の意味的な関係に基づいて、構成要素を組み立てた（統合した）モデルのことです。
デジタル技術は時代とともに進化していきます。
なので、システムも、デジタル技術の進化に伴って新しいものに置き換わっていきます。
目的は、価値を生む業務を設計することで、システムは、そのための手段です。
目的である業務が手段であるシステムに依存して左右されてはならないのです。
次に、PIMとPSMですが、PIMがシステムの論理的構造、PSMがシステムの物理的構造を表すモデルで、
システムの論理構造が物理構造に依存してはならない（物理構造が論理構造に依存する）
という考え方に基づいて設計します。
論理的構造とは、理論やルールに基づいて、構成要素を組み立てた（統合した）モデルのことで、物理的構造とは、物理法則に基づいて、構成要素を組み立てた（統合した）モデルのことです。
CIMの業務課題を解決する論理的構造（目的）であるPIMが、それを実現するデジタル技術の物理的構造（手段）を表すPSMに依存してはならないのです。
このように、CIM、PIM、PSMを分けることで、変わりやすい部分と、変わりにくい部分を切り分けて考えることができるようになります。
例えば、デジタル技術が進歩し、新しい技術を導入したい場合、PSMだけ置き換えればよく、本質的な業務や、それを実現するメカニズムは変える必要はないのです。
このシステムから業務への依存関係、物理構造から論理構造への依存関係は、ソフトウェアの設計原則の一つ依存性逆転の原則（DIP）と同じ考え方です。

プロセス統合

情報システムの場合、ユーザーに価値を提供するプロセスをシステムのユースケースとして考えます。
このユースケースを起点としてシステム開発の各工程が進められる考え方をユースケース駆動開発といいます。
ユースケース駆動開発では、まず、要件定義で、システムが実現すべき機能をユースケースとして定義し、そのあとの工程で、その機能を、システムを構成するモジュールがどう実現するのか分析、設計し、実装します。

ユースケース駆動開発によって、情報システムを構成するモジュールがユースケースによって統合され、ユーザーに価値を提供するシステムを実現します。

【関連動画】