1.2.4. アプリケーションアーキテクチャ

1. 概要

　アプリケーションアーキテクチャ（Application Architecture：AA）とは、エンタープライズアーキテクチャ（EA）を構成する重要な要素の一つであり、組織の目標を実現するための業務とそれを支えるアプリケーションソフトウェアの関係を体系的に整理したものです。AAは、ビジネス戦略と情報システム戦略を結びつける架け橋として機能し、組織全体の情報システムを効率的かつ効果的に構築・運用するための基盤となります。

　情報システム戦略において、AAの重要性は年々高まっています。これは、ビジネス環境の急速な変化に対応するために、情報システムの柔軟性と拡張性が強く求められているからです。適切に設計されたAAは、ビジネス要件の変化に迅速に対応できるシステム構造を実現し、組織の競争力強化に貢献します。

flowchart TB
    subgraph EA["エンタープライズアーキテクチャ(EA)"]
        BA["ビジネスアーキテクチャ"]
        AA["アプリケーションアーキテクチャ\n(本記事の対象)"]
        DA["データアーキテクチャ"]
        TA["テクノロジーアーキテクチャ"]
    end
    
    BA -->|実現| AA
    AA -->|利用| DA
    AA -->|稼働基盤| TA
    
    class AA emphasis
    
    classDef emphasis fill:#f96,stroke:#333,stroke-width:2px

図1: エンタープライズアーキテクチャの構成要素と位置づけ

2. 詳細説明

2.1. アプリケーションアーキテクチャの構成要素

　AAは主に以下の要素から構成されています：

業務機能と情報システムの対応関係：組織の業務機能とそれを支援する情報システムの関係を明確にします。
アプリケーション間の連携：複数のアプリケーション間のデータや処理の連携方法を定義します。
情報システムの機能構成：システム全体の機能構成と各機能の役割を明確にします。
開発・運用ポリシー：アプリケーションの開発・運用に関する方針やルールを定めます。

アーキテクチャ	主な目的	対象	主な成果物
ビジネスアーキテクチャ	組織の戦略と業務プロセスの整理	組織構造、業務プロセス、ビジネス機能	業務機能体系図、業務フロー図、組織図
アプリケーションアーキテクチャ	業務とアプリケーションの関係の体系化	業務アプリケーション、情報システム機能	情報システム関連図、情報システム機能構成図
データアーキテクチャ	組織全体のデータ資産の整理	データ項目、データモデル、データフロー	エンティティ関連図、データフロー図
テクノロジーアーキテクチャ	技術基盤の整理	ハードウェア、ネットワーク、ミドルウェア	システム構成図、ネットワーク構成図

表1: エンタープライズアーキテクチャにおける各アーキテクチャの比較

2.2. 情報システム関連図

　情報システム関連図は、AAを視覚化するための重要なツールの一つです。この図は、組織内の情報システム間の関連性や連携を表現し、以下のような情報を含みます：

システム間のデータの流れ
システム間のインターフェース
外部システムとの連携
システムの依存関係

　情報システム関連図を作成することで、システム全体の構造を俯瞰でき、重複機能の特定や統合の可能性、システム間の連携における問題点などを発見することができます。

flowchart TB
    subgraph External["外部システム"]
        CustomerSystem["顧客システム"]
        SupplierSystem["取引先システム"]
    end
    
    subgraph Internal["社内システム"]
        SalesSystem["販売管理システム"]
        InventorySystem["在庫管理システム"]
        AccountingSystem["会計システム"]
        HRSystem["人事システム"]
        ProductionSystem["生産管理システム"]
    end
    
    CustomerSystem -->|受注データ| SalesSystem
    SalesSystem -->|販売実績| AccountingSystem
    SalesSystem -->|出荷指示| InventorySystem
    InventorySystem -->|在庫データ| SalesSystem
    InventorySystem -->|在庫不足通知| ProductionSystem
    ProductionSystem -->|生産実績| InventorySystem
    InventorySystem -->|仕入実績| AccountingSystem
    ProductionSystem -->|原価データ| AccountingSystem
    SupplierSystem -->|納品データ| InventorySystem
    HRSystem -->|人件費データ| AccountingSystem
    
    classDef internal fill:#b5d8ff,stroke:#333,stroke-width:1px
    classDef external fill:#ffd9b5,stroke:#333,stroke-width:1px
    
    class SalesSystem,InventorySystem,AccountingSystem,HRSystem,ProductionSystem internal
    class CustomerSystem,SupplierSystem external

図2: 情報システム関連図の例

2.3. 情報システム機能構成図

　情報システム機能構成図は、情報システムの機能を階層的に表現したものです。組織の業務を支援するために必要な機能を体系的に整理し、以下のような構造で表現します：

大分類：経営管理、営業、生産、人事など
中分類：各大分類の下位機能
小分類：具体的な業務機能

　この図により、組織のどの業務がどのアプリケーションによってサポートされているかを明確にし、機能の過不足や重複を特定することができます。また、新しいビジネス要件が発生した際に、どのシステムを拡張または新規開発すべきかの判断材料となります。

図3: 情報システム機能構成図の例

2.4. SOA（Service Oriented Architecture：サービス指向アーキテクチャ）

　SOAは、AAの実現アプローチの一つであり、業務機能をサービスという単位でモジュール化し、それらを組み合わせて柔軟なシステムを構築する考え方です。SOAの主な特徴は以下の通りです：

サービスの独立性：各サービスは独立して開発・運用可能
標準インターフェース：標準化されたインターフェースによる連携
再利用性：サービスの再利用による開発効率の向上
柔軟性：ビジネス変化に対応した柔軟なシステム構成

　SOAを採用することで、ビジネス要件の変化に迅速に対応できるシステム構造を実現し、開発コストの削減や保守性の向上が期待できます。また、レガシーシステムと新システムの連携も容易になります。

flowchart TB
    subgraph BusinessProcesses["業務プロセス"]
        OrderProcess["受注プロセス"]
        ShippingProcess["出荷プロセス"]
        InvoiceProcess["請求プロセス"]
    end
    
    subgraph Services["共通サービス"]
        CustomerService["顧客情報\nサービス"]
        ProductService["商品情報\nサービス"]
        InventoryService["在庫管理\nサービス"]
        AccountService["会計\nサービス"]
    end
    
    subgraph SystemLayers["システム層"]
        Legacy["レガシー\nシステム"]
        DB["データベース"]
        External["外部システム"]
    end
    
    OrderProcess -->|利用| CustomerService
    OrderProcess -->|利用| ProductService
    OrderProcess -->|利用| InventoryService
    
    ShippingProcess -->|利用| CustomerService
    ShippingProcess -->|利用| InventoryService
    
    InvoiceProcess -->|利用| CustomerService
    InvoiceProcess -->|利用| AccountService
    
    CustomerService -->|データ参照/更新| Legacy
    CustomerService -->|データ参照/更新| DB
    
    ProductService -->|データ参照/更新| DB
    InventoryService -->|データ参照/更新| DB
    InventoryService -->|データ連携| External
    
    AccountService -->|データ参照/更新| DB
    AccountService -->|データ参照/更新| Legacy
    
    classDef processes fill:#ffcc99,stroke:#f66,stroke-width:1px
    classDef services fill:#ccffcc,stroke:#6a6,stroke-width:1px
    classDef systems fill:#ccccff,stroke:#66a,stroke-width:1px
    
    class OrderProcess,ShippingProcess,InvoiceProcess processes
    class CustomerService,ProductService,InventoryService,AccountService services
    class Legacy,DB,External systems

図4: SOA（サービス指向アーキテクチャ）の概念図

2.5. 情報技術者が理解すべきポイント

　情報技術者は、アプリケーションアーキテクチャに関して以下のポイントを理解する必要があります。

AAの定義と目的：AAが組織の業務とアプリケーションソフトウェアの関係を体系化したものであることの理解
AAの位置づけ：EAの中でのAAの位置づけや他のアーキテクチャとの関係性の理解
情報システム関連図と機能構成図：これらの図の目的と内容、作成方法の理解
SOAの概念と特徴：サービス指向アーキテクチャの基本概念と従来のアーキテクチャとの違いの理解

　これらの概念を単に暗記するだけでなく、実際のビジネスケースに当てはめて考えられるようにしておくことが重要です。

3. 応用例

3.1. 金融業界での適用例

　大手銀行では、口座管理、融資、投資信託、保険など多様な業務システムが存在します。これらのシステムは個別に開発されてきた歴史があり、連携が困難な状況がありました。そこで、AAの考え方に基づいてシステム全体を見直し、情報システム関連図や機能構成図を作成して重複機能や連携の問題点を特定しました。

　具体的には、「顧客情報管理」機能が各システムに重複して実装されており、顧客データの不整合が発生していました。また、システム間のインターフェースが標準化されておらず、システム連携のためのプログラム開発に多大なコストがかかっていました。

　そこで、SOAを導入し、以下のような共通サービスを定義しました：

顧客情報サービス：顧客基本情報を一元管理し、各業務システムに提供
口座管理サービス：口座残高や取引履歴を管理し、各業務システムに提供
取引サービス：入出金、振込などの基本取引機能を提供

　この結果、システム間の連携が容易になり、新しい金融商品の導入に伴うシステム開発期間が従来の半分に短縮されました。また、顧客情報の一元管理により、顧客サービスの質も向上しました。

3.2. 製造業での適用例

　ある大手製造業では、受注管理、生産管理、在庫管理、出荷管理など多くのシステムが部門ごとに独立して開発・運用されていました。部門間の連携は紙の帳票やExcelファイルのやり取りで行われており、情報の遅延や転記ミスが発生していました。

　そこで、AAの考え方を導入し、まず情報システム機能構成図を作成して業務機能とシステムの対応関係を明確にしました。その結果、以下のような課題が明らかになりました：

受注情報から生産計画、在庫確認、出荷指示までの一連の流れがシステム的に分断されている
同じ商品マスタが複数のシステムで個別に管理されている
各システムのインターフェースが異なり、データ連携に人手による作業が必要

　これらの課題を解決するために、SOAに基づいて以下のサービスを定義しました：

商品情報サービス：商品マスタを一元管理
受注サービス：受注データの登録と関連システムへの通知
在庫確認サービス：リアルタイムの在庫情報提供
生産計画サービス：受注と在庫に基づく生産計画の自動作成
出荷指示サービス：生産完了と受注情報に基づく出荷指示の自動作成

　これらのサービスをオーケストレーションすることで、受注から出荷までの一連のプロセスが自動化され、リードタイムが30%短縮されました。また、人手による転記作業がなくなり、ヒューマンエラーも大幅に減少しました。

4. 例題

例題1

問題：アプリケーションアーキテクチャ（AA）の主な目的として、最も適切なものを選びなさい。

ハードウェアとソフトウェアの関係を定義すること
データベースの構造を設計すること
組織の業務とアプリケーションソフトウェアの関係を体系化すること
ネットワークトポロジーを最適化すること

解答と解説

解答：c

解説：AAの主な目的は、組織としての目標を実現するための業務と、それを実現するアプリケーションソフトウェアの関係を体系化することです。aはテクノロジーアーキテクチャ、bはデータアーキテクチャ、dはネットワークアーキテクチャに関連する内容です。

例題2

問題：SOA（サービス指向アーキテクチャ）の特徴として、誤っているものを選びなさい。

業務機能をサービスという単位でモジュール化する
各サービスは独立して開発・運用可能である
サービス間の連携には専用のプロトコルを使用する必要がある
サービスの再利用により開発効率の向上が期待できる

解答と解説

解答：c

解説：SOAでは、サービス間の連携に専用のプロトコルを使用する必要はなく、むしろHTTPやSOAPなどの標準的なプロトコルや標準化されたインターフェースを使用することが特徴です。標準インターフェースの採用により、異なるシステム間の連携が容易になります。

例題3

問題：ある製造業の情報システムを設計するにあたり、情報システム機能構成図を作成しました。以下の記述のうち、情報システム機能構成図の役割として最も適切なものを選びなさい。

システム間のデータの流れを可視化する
システムのハードウェア構成を明確にする
組織の業務機能とそれを支援する情報システムの機能を階層的に整理する
システムの性能要件を定義する

解答と解説

解答：c

解説：情報システム機能構成図は、組織の業務機能とそれを支援する情報システムの機能を階層的に整理するためのものです。aは情報システム関連図、bはインフラストラクチャアーキテクチャ、dは非機能要件定義に関連する内容です。

例題4

問題：アプリケーションアーキテクチャと情報システム関連図に関する記述として、適切なものを選びなさい。

情報システム関連図は、ハードウェアの物理的な接続関係を示すものである
情報システム関連図は、システム間のデータの流れや連携を表現するものである
アプリケーションアーキテクチャは、データベースのテーブル設計を主な対象とする
アプリケーションアーキテクチャは、ビジネスプロセスの最適化を主な目的とする

解答と解説

解答：b

解説：情報システム関連図は、組織内の情報システム間の関連性や連携を表現するもので、システム間のデータの流れやインターフェースを示します。aはネットワーク構成図、cはデータアーキテクチャ、dはビジネスアーキテクチャに関連する内容です。

5. まとめ

　アプリケーションアーキテクチャ（AA）は、組織の目標を実現するための業務とそれを支援するアプリケーションソフトウェアの関係を体系化したものであり、エンタープライズアーキテクチャ（EA）の重要な構成要素です。AAを適切に設計することで、以下のメリットが得られます：

ビジネス戦略と情報システムの整合性確保
システム間の連携強化と重複機能の排除
ビジネス要件の変化に迅速に対応できる柔軟な構造
開発・運用の効率化とコスト削減

　AAを実現するためのツールとして、情報システム関連図や情報システム機能構成図があり、これらを活用することでシステム全体の構造を俯瞰できます。また、SOA（サービス指向アーキテクチャ）は、AAの実現アプローチの一つであり、業務機能をサービスという単位でモジュール化することで、柔軟性と再利用性の高いシステム構造を実現します。

　情報技術者は、AAの基本概念と目的、実現手法としてのSOA、そして情報システム関連図や機能構成図などの表現方法について理解しておくことが重要です。また、実際のビジネスケースにおいてAAがどのように活用され、どのような効果をもたらすかについても考えられるようにしておきましょう。

　最後に、AAはビジネスアーキテクチャとデータアーキテクチャ、テクノロジーアーキテクチャをつなぐ重要な役割を持っており、EA全体の中で適切に位置づけて理解することが必要です。情報システム戦略の立案においては、AAの視点を持つことで、より効果的なシステム構築・運用が可能になります。