ここでは、アプリケーションについて次の観点で説明します。
- アプリケーションとは
- アプリケーションの種類
- アプリケーションアーキテクチャ
- アプリケーションの分類
- アプリケーション戦略
- ストラングラーアプリケーションパターンによるマイクロサービス化
- アプリケーションの開発
アプリケーションとは
次の図は、情報システムの構成を表したものです。
アプリケーションソフトウェアとは、基本ソフトウェアに対する応用ソフトウェアという意味で、共通アプリケーションと個別アプリケーションに分類することができます。
共通アプリケーションとは、企業の業務や組織に関係なくすべてのメンバーが共通に使用するアプリケーションのことです。
個別アプリケーションとは、販売管理システム、購買管理システムなど企業の業務や組織の機能に特化したアプリケーションのことです。
それから、ミドルウェアとは、アプリケーションソフトウェアに共通する機能を集めたソフトウェアで、基本ソフトウェアとアプリケーションソフトウェアの中間に位置づけることができます。
ここでは、個別アプリケーションを「アプリケーション」と呼ぶことにします。
また、個別アプリケーションに、それに関連するIT基盤を含めた範囲を「アプリケーションシステム」あるいは単に「システム」と呼ぶことにします。
アプリケーションの種類
書籍戦略マップ バランスト・スコアカードの新・戦略実行フレームワークでは、アプリケーションを次の３つに分類しています。
- トランザクション処理アプリケーション
企業の基本的な定型業務を自動化するアプリケーション。これは、会計や受注管理など社内業務に関わる情報を記録するためのSoR（System of Record）のことです。 - 変革アプリケーション
企業の現行のビジネスモデルを変革するアプリケーション。例えば、個人向けカスタムメイドジーンズ注文用のインタラクティブなシステムなど、SoRによって蓄積されたデータを活用して、顧客や従業員との関係を強化するためのSoE（System of Engagement）が該当します。 - 分析アプリケーション
分析、解釈、情報と知識の共有を促進するアプリケーション。データ分析から得られた顧客や従業員の隠れたニーズや深層心理、つまりインサイトを理解するためのSoI（System of Insight）が該当します。
さて、ソフトウェアのアーキテクチャパターンの一つにコマンド・クエリ責務分離（CQRS）パターンがあります。
これは、データストアに対する更新操作を集めたコマンド処理と、読み取り操作（クエリ）を集めたクエリ処理を完全に分離するアーキテクチャパターンです。
CQRSでは、クライアントからのコマンドは一方通行で書き込み用データストアに届き、クエリは別の読み込み用データストアに対して発行します。
コマンド処理によって書き込み用データストアを更新するタミングで、読み込み用データストアも更新し、互いの同期をとります。
書き込み用データストアには、通常、リレーショナル・データベースを適用し、読み込み用データストアには、通常、データウェアハウスやNoSQLを適用します。
ここでは、トランザクション処理アプリケーションをコマンド処理のアプリケーション、分析アプリケーションをクエリ処理のアプリケーションと考えます。
※帳票出力などレポート処理もクエリ処理として、トランザクション処理アプリケーションから分離します。
それでは、変革アプリケーションはどういう位置づけかというと、次の図のように、これまで人が行ってきた記録業務（コマンド処理）や分析業務（クエリ処理）をAIが代行する機能だと考えます。
アプリケーションアーキテクチャ
アプリケーションアーキテクチャ（AA）とは、ビジネス要件（戦略の実現、各種報告の信頼性確保、各種法規の遵守）を実現するアプリケーションの機能や品質を確保するため、企業のアプリケーション全体の仕組をモデル（青写真）として表したものです。
アプリケーションアーキテクチャは、次のように、静的モデルと動的モデルに分けることができます。
- 静的モデル（構造）
アプリケーションアーキテクチャの静的モデルはアプリケーション構成です。
アプリケーション構成は、アプリケーションポートフォリオともいいます。 - 動的モデル（振舞）
アプリケーションアーキテクチャの動的モデルはアプリケーション連携モデルです。
アプリケーション連携モデルは、アプリケーション間のデータ連携を表したデーフローになります。
次の図は、デザイン思考経営の設計フェーズ、戦略フェーズ、構築フェーズで作るアプリケーションアーキテクチャの成果物を、それぞれ、設計レベル、戦略レベル、実例レベルに分けて表したものです。
これら設計レベル、戦略レベル、実例レベルのアプリケーションアーキテクチャ、ビジネスストラクチャマトリクスビジネスストラクチャマトリクスでいうと次の図の赤枠の部分をモデル化したものになります。
アプリケーションの分類
それでは、アプリケーションはどのように分類すればよいのでしょうか。
ここでは、アプリケーションを分類し、アプリケーションアーキテクチャの静的モデルであるアプリケーションタイプ（概念レベルのアプリケーション）の構成を設計する方法について説明します。
トランザクション処理アプリケーションのポートフォリオ
トランザクション処理アプリケーションのアプリケーションタイプは、職務（ジョブ）に対応させます。
すべての起点は、活動領域で、活動領域をベースにジョブとビジネスプロセスを設計します。
ジョブは、内部統制による職務分掌や、同じスキルセット、ドメイン知識を持つ機能単位として考えられているので、ジョブ単位にトランザクション処理アプリケーションを分割することで、業務機能とアプリケーションタイプを対応させることができます。
これは、結果的に、ソフトウェア設計原則の単一責任の原則「変更する理由が同じものは集める、変更する理由が違うものは分ける」に則ることになり、ドメイン駆動設計のドメインの単位になります。
例えば、ジョブが次のように設計されたとします。
すると、それをベースにしてトランザクション処理アプリケーションのアプリケーションタイプの構成は次のように設計することができます。
ここでは、戦略目標「製品品質の維持向上」を実現するために、顧客に導入した納入機（製品個体）の状態を監視し予防保全を実現するため納入機管理システムを導入しています。
また、得意先元帳や仕入先元帳に対応するシステムを導入し債権債務を細かく管理するため会計管理システムから売上管理システムと仕入管理システムを独立させています。
アプリケーションポートフォリオを一覧化すると次のようになります。
分析アプリケーションのポートフォリオ
次に、分析アプリケーションのアプリケーションタイプの構成ですが、これは、ソフトウェア設計原則の単一責任の原則に従うよう、分析の目的別に分類します。
例えば、売上分析をしたい場合は、売上分析システムになります。
次の図のように、BSCのKPIが定義されている場合、KPIごとに分析システムを設定することができます。
アプリケーション戦略
次に、あるべきアプリケーションカテゴリ（論理レベルのアプリケーション）の構成についての戦略を策定します。
次の図は、企業のアプリケーションを、業務活動の特殊性と規模で分類したものです。
これを見ると、業務活動の規模が大きくて特殊なアプリケーションはスクラッチ開発がよく、業務活動の規模が大きくて汎用的なアプリケーションは業務パッケージを適用したほうがよいとなっています。
なぜならば、業務活動の規模が大きくて特殊なアプリケーションは、ビジネスのノウハウが機能として蓄積されていく部分なので変更可能性が高く、自分たちが自由に変更しづらい汎用的な業務パッケージが足かせになる可能性が高いからです。
マイケル・ポーターのバリューチェーンは主要活動と支援活動から構成されていますが、価値を創り、伝え、届ける主要活動の部分は、ビジネスの根幹となる部分であり特殊性が高く、支援活動は汎用性が高いと考えることができます。
特に、会計や給与計算などは、会社によって機能が変わるわけではなく法改正による機能変更をいちいち自社で行う必要はないので、それこそ既成の業務パッケージを適用するほうがよいと考えます。
そして、この業務活動の規模が大きくて特殊性が高いアプリケーションこそマイクロサービスを適用すべきだと考えます。
なぜならば、ビジネスの根幹となる業務を支援するアプリケーションは高い保守性や可用性が求められるからです。
マイクロサービスを適用することで、システムがモジュール化され、比較的柔軟に機能を追加、変更することができます。
また、マイクロサービスは、分散システムを形成するので障害耐性が強く可用性を高くします。
次の図は、アプリケーションポートフォリオで業務パッケージを適用する部分とマイクロサービスを適用する部分を分けた図です。
これを見ると、会計や人事など規模が大きく汎用的なアプリケーションには業務パッケージを適用し、大規模で特殊性の高いSCMやCRM、PLMにはマイクロサービスを適用していることがわかります。
これは、企業が、アプリケーション戦略としてマイクロサービスアーキテクチャを適用した例になります。
DXを進めるときは、アプリケーション戦略に基づいて、現行の基幹システムの構成をあるべき基幹システムの構成にトランスフォームするようにします。
※
SCM
サプライチェーン管理（SCM：Supply Chain Management、以下、SCM）とは、製品やサービスを提供するために必要な資材や部品などを供給するネットワーク全体を統合的に管理するソリューションです。
CRM
顧客関係管理（CRM：Customer Relationship Management、CRM）とは、顧客との関係を強化し、顧客とのコミュニケーションや相互作用を最適化するための戦略的なアプローチや技術の総称です。
PLM
製品ライフサイクル管理（PLM：Product Lifecycle Management、以下、PLM）とは、製品開発力や企業競争力を強化するために、製品ライフサイクル全体（製品企画・設計、調達、製造、販売、物流、保守サービス）に渡って発生する様々な技術情報を集約してエンジニアリングチェーンを繋いで管理するソリューションです。
ERP
エンタープライズ・リソース・プランニング（ERP: Enterprise Resource Planning）とは、企業全体を経営資源（人、物、金、情報）の有効活用の観点から統合的に管理し、経営の効率化を図るための手法です。
それから、アプリケーション戦略では、シングルサインオンを導入するかどうかなど、アプリケーションカテゴリ全体に関係する方針も決めます。
マイクロサービスの構成を考えるときは、ビジネスの活動領域を担うサービスだけでなく、ロギングサービスや認証・認可サービスなど業務機能に共通の機能をマイクロサービス化することも考えます。
マイクロサービスは、購買管理サービス、生産管理サービス、販売管理サービスなど業務視点で分けて考えるとともに、認証・認可サービス、ロギングサービス、構成管理サービスなど業務横断的なシステム視点でも分けて考えます。
例えば、シングルサインオンを導入する場合、それを実現する認証サーバーをマイクロサービス（認証サービス）として実現することができます。
シングルサインオン（Single Sign-On：SSO）とは、認証と認可を分けることで、最初のアプリケーションを利用する時に、一度だけログインすれば、以降は全てのアプリケーションやサービスを再ログインなしに利用できるようにする仕組のことです。
上図は、シングルサインの仕組を表したものです。
流れを説明すると次のようになります。
- ユーザーがUIのサインイン画面でIDとパスワードを入力します。
- UIはSSOゲートウェイにIDとパスワードを渡します。
- SSOゲートウェイは認証サービスにIDとパスワードを渡します。
- 認証サービスはユーザーのIDとパスワードを検証し、成功すると認証トークン（例えばJWT：JSON Web Token）を生成してSSOゲートウェイに返します。
- SSOゲートウェイは認証トークンをUIに渡します。
- UIは認証トークンを付加してバックエンドのアプリケーションやマイクロサービスにリクエストを送信します。
- アプリケーションやマイクロサービスは、認証トークンを検証し、ユーザーのリクエストに応じた処理を行います。
認証サービスとは、ユーザーの認証を行うマイクロサービスです。
認証サービスが認証した結果を認証トークンとして第三者に渡すことで、認証と認可を分離することができます。
認証トークンを受け取ったシステムは、それに応じたデータへのアクセスが認可されます。
それから、認証サービスは、多要素認証することもできます。
多要素認証とは、IDとパスワードに加え、第二の認証要素（例えば、スマートフォンの認証アプリ、SMSコード、生体認証など）を要求する認証方法です。
なお、上図のSSOゲートウェイとは、シングルサインオンゲートウェイのことで、アプリケーションやマイクロサービスと認証サービスとのやりとりを中継する機能です。
さて、どの部分に業務パッケージを適用し、どの部分にマイクロサービスを適用するか決まったら、どいう手順でマイクロサービス化していくかアクションプランを立案します。
その場合、多くのマイクロサービスに共通したマスターデータを管理する顧客管理システムや商品管理システムは共通部品になるので、先にマイクロサービス化すると比較的リスクとコストを抑えて進めることができます。
それでは、基幹システムなどモノリシックなシステムをマイクロサービス化するにはどうすればよいのでしょうか。
ストラングラーアプリケーションパターンによるマイクロサービス化
ここでは、基幹システムなどモノリシックなシステムを段階的にモダナイズして、マイクロサービスへ移行する方法、ストラングラーアプリケーションパターンについて紹介します。
ストラングラーアプリケーションパターン（Strangler Application Pattern）とは、既存のシステム（特にレガシーシステム）を一度に全面リプレースするのではなく、機能単位で段階的にマイクロサービスへ移行していくソフトウェア開発戦略のことです。
ストラングラーアプリケーションパターンのストラングラーとは「絞め殺しのイチジク（Strangler Fig）」という植物に由来します。
新旧システムを共存させながら徐々に新しいシステムへ移行する手法を、イチジクが他の木に絡みつき、徐々に元の木を包み込み、最終的に置き換えてしまう様子になぞらえているのです。
具体的にみていきましょう。
例えば、SCM（サプライチェーンマネジメント）全体を一元管理するモノリシックな基幹システムがあったとします。
このSCMシステムの内部には、販売管理や生産管理など多くの業務機能が含まれています。
そこで、まず、SCMシステムの業務機能を、業務ドメイン単位に論理的に分類します。
次に、業務ドメイン単位に論理的に分類された業務機能ごとにAPIを整備します。
基幹システムがフロントエンドアプリケーションがAPIを介してバックエンドアプリケーションに接続する構成になっていない場合、フロントエンドアプリケーションがAPIを介してバックエンドアプリケーションに接続するようにします。
この段階で、論理的に分割されたAPIが整備されますが、マイクロサービス化するには、並行して各業務ドメイン単位にマイクロサービスを構築します。
次に、段階的にAPIの実装部分を従来の機能からマイクロサービスに置き換えていきます。
このプロセスを繰り返し、最後の機能が置き換わるまで実施します。
そして、すべてのSCM機能がマイクロサービスに置き換わった時点で移行が完了します。
アプリケーションの開発
一般的なアプリケーションの開発は、企画段階でシステム開発の背景、目的、効果などを明確にした後、次のような工程で進めます。
要件定義
システムの外部要素（ユーザーや外部システム）のユースケースを洗い出すことでシステムの機能の範囲（スコープ）を明確にします。
システムのユースケースは、システムの機能要件になります。
要件定義では、機能要件だけでなく、非機能要件（システムの品質要件や制約条件）も定義します。
なお、要件定義の際、システムの概念データモデルとデータ要件を定義します。
次の図は、要件定義で作成するユースケース図の例です。
また、次の図は、UMLのクラス図で描いた注文管理システムの概念データモデル（ドメインモデル）の例です。
クラス図のクラスをエンティティを表すアイコンを使って描くこともできます。
基本設計
基本設計では、要件定義で定義された機能要件と非機能要件を実現するシステムの基本的な構造と振舞を設計します。
機能要件と非機能要件を実現するための考え方（設計思想）と、それに基づいたシステムの基本的な仕組をシステムのアーキテクチャといいます。
なお、基本設計の際、システムの論理データモデルを設計します。
基本設計は、外部設計と内部設計に分けることができます。
外部設計
システムと外部要素とのインターフェースと相互作用を設計します。
次の図は、外部設計で作成する注文管理システムの画面構成の例です。
次は、ユーザーとシステムの相互作用を表した、注文管理システムの「商品の注文」ユースケースのイベントフローの例です。
- 事前条件
- 会員がログインしていること
- システムは商品注文画面を表示していること
- メインフロー
- 会員が商品注文画面で商品を押下すると、システムは商品詳細画面を表示する。
- 会員が商品詳細画面で商品を選択すると、システムは商品注文画面を変更する。
- 会員が商品注文画面で注文を確定すると、システムは注文完了画面を表示する。
- 代替フロー
a.３で、注文が確定できない場合、#2「注文できませんでした」というメッセージを出力する。- 事後条件
注文が登録されていること。
次の図は、注文管理システムの「商品の注文」の画面遷移を状態マシン図で表した例です。
上記イベントフローと整合しています。
内部設計
外部設計で設計された外部要素とのインターフェースと相互作用を実現する、システム内部のモジュール間の構造と相互作用を設計します。
次の図は、モジュール間の相互作用を表す図です。
モジュール間の相互作用を分析することで、そのモジュール構造でユースケースが実現できるか、モジュール構造の妥当性を検証します。
モジュール間の相互作用の設計を通して、モジュールのインターフェースを設計します。
次の図は、注文管理システムの「商品の注文」ユースケースを実現するクラスの構造（分析モデル）の例です。
この場合、注文管理クラスなど各クラスがモジュールという位置づけになります。
そして、次の図は、注文管理システムの「商品の注文」ユースケースを実現するクラスの構造（分析モデル）を検証するために作成したシーケンス図の例になります。
詳細設計
詳細設計は、システム内部の個々のモジュールのインターフェースを実現する内部構造や振舞を設計します。
例えば、上記シーケンス図の注文管理オブジェクト（モジュール）が「商品情報の取得」メソッド（API）をどう実現するのか詳細設計します。
なお、詳細設計の際、システムの物理データモデルを設計します。
実装
モジュールを実装します。
テスト
モジュールの単体テスト（実装に対するテスト）、モジュール間の結合テスト（内部設計に対するテスト）、システム全体のシステムテスト（外部設計に対するテスト）に分けることができます。
それでは、マイクロサービスアーキテクチャを適用した場合、システム開発はどのようになるのですしょうか。
マイクロサービスを開発するときは、ユーザーとのインターフェースを担うフロントエンドシステムと、マイクロサービス間の相互作用としてシステムを設計します。
なので、要件定義で定義するシステムのユースケースは次のようになります。
次に、基本設計の外部設計で、フロントエンドシステムと、マイクロサービス間の相互作用を設計します。
フロントエンドシステムと、マイクロサービス間では、コンシューマ駆動契約（Consumer-Driven Contracts、CDC）を結び、APIに対する実現を保証するようにします。
そして、内部設計で、フロントエンドシステムと締結したコンシューマ駆動契約を実現すべく、サービス内部の構造と相互作用を設計します。
なお、詳細設計では、サービスを構成する各コンポーネントの構造と振舞を設計します。
具体的な例を見てみましょう。
次の図は、フロントエンドシステムである販売管理システムで受注を登録するユースケースの例です。
基本設計の外部設計では、次のように販売管理システムと各マイクロサービス間の構造と相互作用を設計します。
次の図は、販売管理システムと各マイクロサービス間の構造を表した論理レベルのアプリケーション連携モデルです。
BFFとはBackends For Frontendsの略で、アーキテクチャパターンの1つで、フロントエンドとバックエンドの中間に位置し、双方の複雑な処理を緩和させる役割を担うサーバー機能のことです。
また、次の図は、販売管理システムと各マイクロサービス間の相互作用を表したものです。
ここでは、「受注の登録」APIに対するコンシューマ駆動契約を締結していることがわかります。
そして、内部設計では、コンシューマ駆動契を実現すべく、サービスの内部の構造と相互作用を設計します。
次の図は、ドメイン駆動設計で、販売管理サービスの内部のクラス間の相互作用を設計した例になります。
