アプリケーションポートフォリオとは、企業のアプリケーションタイプの構成です。
アプリケーションは、情報資産の一つで、アプリケーションタイプは、アプリケーションの型を表します。
ここでは、アプリケーションポートフォリオを構成するアプリケーションは、マイクロサービスの単位になるものと考えます。
ここでは、アプリケーションポートフォリオの設計について、次の観点で説明します。
アプリケーションの種類
書籍戦略マップ バランスト・スコアカードの新・戦略実行フレームワークでは、アプリケーションを次の３つに分類しています。
- トランザクション処理アプリケーション
企業の基本的な定型業務を自動化するアプリケーション。これは、会計や受注管理など社内業務に関わる情報を記録するためのSoR（System of Record）のことです。 - 変革アプリケーション
企業の現行のビジネスモデルを変革するアプリケーション。例えば、個人向けカスタムメイドジーンズ注文用のインタラクティブなシステムなど、SoRによって蓄積されたデータを活用して、顧客や従業員との関係を強化するためのSoE（System of Engagement）が該当します。 - 分析アプリケーション
分析、解釈、情報と知識の共有を促進するアプリケーション。データ分析から得られた顧客や従業員の隠れたニーズや深層心理、つまりインサイトを理解するためのSoI（System of Insight）が該当します。
さて、ソフトウェアのアーキテクチャパターンの一つにコマンド・クエリ責務分離（CQRS）パターンがあります。
これは、データストアに対する更新操作を集めたコマンド処理と、読み取り操作（クエリ）を集めたクエリ処理を完全に分離するアーキテクチャパターンです。
CQRSでは、クライアントからのコマンドは一方通行で書き込み用データストアに届き、クエリは別の読み込み用データストアに対して発行します。
コマンド処理によって書き込み用データストアを更新するタミングで、読み込み用データストアも更新し、互いの同期をとります。
書き込み用データストアには、通常、リレーショナル・データベースを適用し、読み込み用データストアには、通常、データウェアハウスやNoSQLを適用します。
ここでは、トランザクション処理アプリケーションをコマンド処理のアプリケーション、分析アプリケーションをクエリ処理のアプリケーションと考えます。
※帳票出力などレポート処理もクエリ処理として、トランザクション処理アプリケーションから分離します。
それでは、変革アプリケーションはどういう位置づけかというと、次の図のように、これまで人が行ってきた記録業務（コマンド処理）や分析業務（クエリ処理）をAIが代行する機能だと考えます。
トランザクション処理アプリケーションの分類
トランザクション処理アプリケーションは、業務活動の結果としての事実（データ）を記録するアプリケーションです。
ここでは、職務（ジョブ）にトランザクション処理アプリケーションを対応させます。
ジョブは、内部統制による職務分掌や、同じスキルセット、ドメイン知識を持つ機能単位として考えられているので、ジョブ単位にトランザクション処理アプリケーションを分割することで、業務機能とアプリケーションを対応させることができます。
これは、結果的に、ソフトウェア設計原則の単一責任の原則や情報エキスパートにも則ることになり、そういう意味でも適切な粒度になります。
ジョブは、活動領域ごとに考えます。
例えば、会社の活動領域を次のように分類した場合を考えます。
この活動領域をベースに、ジョブを次のように分類します。
ジョブの分類に対応させてトランザクション処理アプリケーションの構成を次のように設計します。
戦略目標「製品品質の維持向上」を実現するために、顧客に導入した納入機（製品個体）の状態を監視し予防保全を実現するため納入機管理システムを導入します。
得意先元帳や仕入先元帳に対応するシステムを導入し債権債務を細かく管理するため会計管理システムから売上管理システムと仕入管理システムを独立させます。
分析アプリケーションの分類
次に分析アプリケーションの分類ですが、これは、ソフトウェア設計原則の単一責任の原則や情報エキスパートに従って、分析の目的別に分類します。
例えば、売上分析をしたい場合は、売上分析システムになります。
次の図のように、BSCのKPIが定義されている場合、KPIごとに分析システムを設定することができます。
マイクロサービス化
先行きが不透明で予測困難な昨今、業務とシステムを、環境の変化に合わせて機敏に適応できるようにするためにもマイクロサービスアーキテクチャを採用することをオススメします。
マイクロサービスとは、協調して動作する小規模で自律的なソフトウェア部品のことです。
企業では、様々なアプリケーションがありますが、ここでは、どのアプリケーションををマイクロサービス化し、どの部分に既成の業務パッケージを適用するか、その考え方について説明します。
次の図は、企業のアプリケーションを、業務活動の特殊性と規模で分類したものです。
これを見ると、業務活動の規模が大きくて特殊なアプリケーションはスクラッチ開発がよく、業務活動の規模が大きくて汎用的なアプリケーションは業務パッケージを適用したほうがよいとなっています。
なぜならば、業務活動の規模が大きくて特殊なアプリケーションは、ビジネスのノウハウが機能として蓄積されていく部分なので変更可能性が高く、自分たちが自由に変更しずらい汎用的な業務パッケージが足かせになる可能性が高いからです。
マイケル・ポーターのバリューチェーンは主要活動と支援活動から構成されていますが、価値を創り、伝え、届ける主要活動の部分は、ビジネスの根幹となる部分であり特殊性が高く、支援活動は汎用性が高いと考えることができます。
特に、会計や給与計算などは、会社によって機能が変わるわけではなく法改正による機能変更をいちいち自社で行う必要はないので、それこそ既成の業務パッケージを適用するほうがよいと考えます。
そして、この業務活動の規模が大きくて特殊で変更可能性が高いアプリケーションこそマイクロサービスを適用すべきだと考えます。
次の図は、トランザクション処理アプリケーションのポートフォリオで、SCMシステム、PLMシステム、CRMシステムをバリューチェーンの主要活動、ERPの部分をバリューチェンの支援活動とし、主要活動の部分をサービスにし、支援活動の部分に業務パッケージを適用した例です。
次に分析システムですが、これは、分析の目的の単位に分けられているので、次の図のように、すべてマイクロサービスと考えることができます。
マイクロサービスは、さらに、次の観点から分割することができます。
- 業務機能横断的機能のサービス化
ロギングサービスや認証サービスなど業務機能に共通の機能をマイクロサービスにします。 - BFF（Backend For Frontend）パターンの適用
UIごとのバックエンド機能をマイクロサービスにします。
昨今の生成AIの飛躍により、次の図のように、今後、人間の作業がAIに置き換えられて業務が変革されていくことが考えられます。
日本では、ファーストリテイリング社（ユニクロ運営会社）が、2015年からECサイトのアプリケーションやスマートフォンアプリ「ユニクロ・アプリ」などにマイクロサービスを適用しはじめ、商品管理や在庫管理など従来パッケージ製品を適用していた基幹システムの領域までマイクロサービス化しているようです。
パッケージ製品は、カスタマイズの自由度が低く、変更に時間が掛かるため、基幹業務システムで、会社のコアのナレッジがたまっている部分は、パッケージを使うのではなく、今後は自分たちで作るべきだと判断したようです。
会社のコアの業務は、できるだけマイクロサービス化して、環境の変化に機敏に適応できるようにしておくことが得策なのではないでしょうか。
[…] アプリケーションポートフォリオの設計 […]