2020年9月9日、一般社団法人日本データマネジメント・コンソーシアムが主催する「第52回 定例セミナー」がオンライン開催された。同セミナーではアイ・ティ・イノベーションのシニアコンサルタント、中山嘉之氏が登壇し、「ITアーキテクチャのセオリー」をテーマにした講演を行った。
なぜ今「アーキテクチャの重要性」に着目するべきなのか
大手製造業で長年に渡り、情報システムの企画や設計開発、運用に携わってきた中山氏は、これまで業務を通じて培ってきたさまざまな経験や知見を基に、現在「データセントリックな適材適所のアーキテクチャ」を提唱しており、このコンセプトをベースにしたコンサルティング活動を展開している。
また、これまでの活動の集大成として、2018年に自著「システム構築の大前提— ITアーキテクチャのセオリー」（リックテレコム刊）を上梓し、自身が編み出したアーキテクチャ設計の方法論を広く公開している。
同書の中で中山氏はまず、「なぜ今、アーキテクチャ設計に着目すべきなのか」について持論を展開している。
「近年の企業システムは巨大化・複雑化が進み、企業自身がそのすべてを設計・開発するのが難しい状況です。そのため、作業の多くを外部ベンダーにアウトソースするようになりましたが、さまざまなステークホルダーによってシステムの増改築が繰り返された結果、システムの整合性がだんだん取れなくなってきています。
こうした経過を辿った結果、システムが本来、目指していたはずのゴールや理想形が見えにくくなってしまいました」（中山氏）
ましてや、多くの企業は今後「デジタルトランスフォーメーション（DX）の実現」を標榜して、さらにシステム規模の拡大を目指すことが予想されるため、上記のような傾向はさらに強まると予想される。
そこで、今あらためて「企業システムが本来目指すべき姿」を明らかにし、「将来の青写真としてのアーキテクチャ」をきちんと描くことが求められている。
その際に留意すべきポイントの1つとして、同氏は「“プロジェクト”より“プロダクト”の成功を重視する」ことを挙げる。
「ベンダーは、システムの開発プロジェクトが終わった時点で投資を回収しますが、ユーザー企業は、システムが完成してから3年、4年、5年と使い続けていく中で投資を回収していきます。
そのため本体は『プロジェクトの成功』を目指すのではなく、ユーザーに長く使われ続ける魅力的なシステムの実現を目指さすべきなのです」（中山氏）
同氏はITアーキテクチャの設計を、都市計画における「都市計画法」になぞらえて説明する。都市計画がおろそかにされたまま、無秩序に都市開発が進められると、徐々に都市周辺部にスラム街が生成されるようになる。そのため、長期的な視野に立って将来の青写真を描いた都市計画の策定が不可欠となる。
企業システムも同様に、将来のあるべき姿をアーキテクチャとしてきちんと定めておかないと、余剰に開発されて陳腐化したシステムが乱立する「スラム化」の現象が発生してしまう、というわけだ。
こうした問題を回避するためには、「適材適所を可能にするシステム構造」が重要だと同氏は説く。つまり、社内の各業務ごとに「最適なシステムを過不足なく適材適所で配置」できれば、必要以上のものを作らずに済む。
その一方で、ただ単に業務ごとに個別にシステムを導入していくだけでは、互いに孤立したシステムがばらばらに散在する「サイロ化」状態が生まれるだけだ。
そこで同氏が提唱するのが、「エンタープライズHUB」と呼ばれるアーキテクチャの適用だ。
各業務に「固有の色が付いていない全社共通のデータ」を、「共通マスタデータベース」「共通トランザクションデータベース」として切り出す。その上で、各業務システムは自身が内包する独自データベースではなく、この共通データベースをなるべく使うようにする。
こうしたアーキテクチャを採用することで、複数のアプリケーションが同じようなデータを重複して持ってしまったり、社内のあちこちでデータのコピー＆ペーストが行われてデータが散らかってしまうような事態を回避できる。
DA（データ・アーキテクチャ）を中心にアーキテクチャを検討する
中山氏が提唱するこのアーキテクチャは、もともとは「EA」（Enterprise Architecture）の考え方をベースにしている。EAの基本的なコンセプトは、既存のITシステムの構造を可視化するとともに、将来目指すべきシステムの姿を明確に描き、この両者の間のギャップを洗い出すことで目指すべきIT戦略の道筋を示し、環境変化に素早く追随できる企業システムを実現しようというものだ。
EAの方法論では、システムを「BA（ビジネス・アーキテクチャ）」「DA（データ・アーキテクチャ）」「AA（アプリケーション・アーキテクチャ）」「TA（アプリケーション・アーキテクチャ）」の4層構造でとらえるが、中でも最も変化のサイクルが長い「DA」に着目してアーキテクチャを検討することが重要だと同氏は強調する。
「テクノロジーの進化やビジネスモデルの変化のスピードなどと比べれば、データ構造はそうそう簡単に変わるものではありません。そこで、最も変わりにくく、構造が安定しているDAを中心に据えれば、安定性の高いアーキテクチャを構築できます。
また、実際にアーキテクチャ設計を行う際には、得てして現状分析を精緻に行うことにこだわりがちですが、必要以上にこだわってもいたずらに時間と労力を浪費するだけですから、必要な部分のみに対象を絞って素早く行うことをお勧めしています」（中山氏）
自社内で行われているさまざまな業務は、自社特有の価値を生み出すための「コア業務」と、どんな会社でもほぼ共通して行われている「ノンコア業務」に分けた上で、それぞれに対する投資の優先順位を明確に設定するのもポイントだ。
その際には、各業務を「バックオフィスか、それともフロントオフィスか」「変更が多いか、それとも少ないか」という2軸を基準にした4象限マトリクス上にマッピングした上で、それぞれに適した実装技術を判断する。
なお、DAを中心に据えたアーキテクチャを設計するとなると、当然のことながら「データモデルの適切な設計」が何より重要になる。
具体的にはER図を使ってデータモデルの設計作業を進めていくことになるが、その際には「微に入り細に入りすべてのデータ構造を精緻に書き表すこと」を目指すのではなく、むしろ、ITの専門家ではないビジネスユーザーが見てもビジネスの全体構造が容易に見渡せるよう、「表記法をあえてシンプルに留めたり、補足説明を付記する」といったさまざまな工夫が必要になってくる。
これはAAの設計においても同様で、まずは全社レベルで「どのようなシステムが存在しており、その間のデータ連携やデータベースはどのような構成になっているか」をざっと俯瞰できる図を作成する。その際も精緻な描写よりも、むしろ「ビジネスの全体像を1枚の絵にシンプルにまとめる」ことを意識して分かりやすい絵を描くことが重要だ。
「データHUB」を中心としたハブ＆スポーク型のアーキテクチャ
こうしたアーキテクチャの中心に位置するのが、「データHUB」と呼ばれる仕組みだ。
各業務システム間のデータ連携を無計画に個別実装していくと、1対1のデータ連携インタフェースがシステムの数だけ出来上がっていき、システムの数が増えていくに従ってデータ連携がスパゲッティ状に複雑に絡み合った構造が生まれてしまう。そこで、システム間のデータ連携を仲介するためのデータHUBを中心に配置し、すべてのシステムがここに接続する「ハブ＆スポーク」の構成をとれば、スパゲッティ化現象を食い止められるようになる。
こうした構成を実装するに当たり、一般的にはETLやEAIといったデータ連携ツールが使われることが多いが、実際にはこうしたツールを導入するだけでは不十分だと中山氏は指摘する。
「ETLツールやEAIツールを導入してハブ＆スポーク構成を組んでも、各システム間でデータフォーマットがばらばらのままだと、実質的にはピア・ツー・ピア構成と変わらずデータ連携に多くのコストと人手を要することになります。こうした勘違いはいまだに多くのプロジェクトで繰り返されているため、注意が必要です」（中山氏）
データHUBは、まさにこうした課題を解決するための仕組みだ。具体的には、各システム間で共通して使われるデータを抽出し、全社共通のマスタデータベースとトランザクションデータベースを構築する。各システムで共通データが更新された際には、データHUBが実装する「データ変換」機能を介して共通データベースに対する書き出しを行い、また共通データベースの内容を参照したい場合は同じくデータ変換機能を通じてデータの読み込みを行う。
こうしてシステム間のデータ連携を行う際に必ずデータHUBの共通データベースとデータ変換機能を介在させることでシステム間の疎結合アプローチを実現し、ひいては環境変化に応じて柔軟にシステムコンポーネントを入れ替え可能な「変化に強いアーキテクチャ」が可能となる。
こうした仕組みを実際に構築するには、まず前項で挙げた「概念データモデル」や「全社アプリケーション俯瞰図」などを作成し、これらを基に共有度合いの高いエンティティを選別する。次にこれらのエンティティを正規化したデータベース構造へと落とし込み、共通マスタデータベースと共通トランザクションデータベースを構築した上で、これらのデータベースへデータを変換して集信するための仕組みを実装する。
また、同様に、アプリケーションからこれらのデータベースのデータを読み出せるように、「データ項目を各アプリケーション内部のデータ構造に適切にマッピング・変換する処理」も実装する。
「こうした一連の仕組みを実現することで、システム間でシェアすべきデータをきれいなデータモデルの形でデータHUB上で一元管理できるようになり、データの重複だらけのスラム化した状態から脱却できるようになります」（中山氏）
データセントリックなアーキテクチャへいかにスムーズに移行するか
ただし、こうしたアーキテクチャは、一朝一夕では実現できない。大抵の企業は既に、何らかのシステムを導入しており、それらを運用するためのプロセスや体制を長年に渡り回し続けているため、これを一気に新たな仕組みへと切り替えるのはあまりにもリスクが高い。そこで中山氏は、「段階的なアーキテクチャの移行」を推奨する。
近年の基幹系システムは、同じアプリケーションの中に共通マスタ管理システムや各種業務アプリケーションの機能を密結合で内包しているため、これらの機能を少しずつ分割していって、段階を踏みながら疎結合アーキテクチャへと移行させていく。
具体的には、まず共通マスタ管理機能を既存システムから切り出して別システムとして設け、次に共通トランザクションデータベースをこれに加えてデータHUBの機能を確立する。そして最後に既存の密結合システムの各アプリケーション機能を個別に切り出して、データHUB経由の疎結合モデルへと移行していく。
こうしたアーキテクチャ転換を進める上では、プロジェクトが目指すべき方向にきちんと向かっているかを適宜チェックするための体制が不可欠だ。そのために、CIO直下に「AMO（Architecture Management Office）」と呼ばれる組織を設置し、各プロジェクトの方向性がアーキテクチャ転換の全体ロードマップに沿っているか常にチェックするとともに、全体ロードマップ自体も定期的に見直してビジネス環境の変化に適合しているかどうか確認する必要がある。
なお、グローバルに事業を展開している大企業の場合は、国や地域ごとに文化や商習慣が異なるため、世界中のすべての拠点を単一のデータHUBで束ねるのは現実的ではない。そこで拠点ごとにそれぞれ共通データを一元管理するデータHUBを設置した上で、それらをコード変換して本社のデータHUBと連携させる「データHUBの階層構造」を構成する。
最後に中山氏は、今後DXが進展して業務アプリケーションに先進デジタル技術がどんどん取り込まれていくにつれ、データセントリックなアーキテクチャの重要性もさらに増していくだろうと述べる。
「業務アプリケーションに対するデータの入力は、これまではかなりの部分を人間の手に頼ってきましたが、これからはAIやIoT技術の導入によってデータがアプリケーションに自動的に集まってくるようになります。こうなるとより大量のデータを扱う必要が出てくるため、本日紹介したデータセントリックなアーキテクチャの重要性は、今後ますます増してくることでしょう」（中山氏）
執筆
吉村哲樹
早稲田大学政治経済学部卒業後、メーカー系システムインテグレーターにてソフトウェア開発に従事。その後、外資系ソフトウェアベンダーでコンサルタント、IT系Webメディアで編集者を務めた後、現在はフリーライターとして活動中。