楽水

人々の創造が自由に表現できる舞台づくり

DX アプリケーション

アプリケーションポートフォリオの設計

投稿日:


アプリケーションポートフォリオとは、企業のアプリケーションタイプの構成です。
アプリケーションは、情報資産の一つで、アプリケーションタイプは、アプリケーションの型を表します。
ここでは、アプリケーションポートフォリオを構成するアプリケーションは、マイクロサービスの単位になるものと考えます。
ここでは、アプリケーションポートフォリオの設計について、次の観点で説明します。

アプリケーションの種類

書籍戦略マップ バランスト・スコアカードの新・戦略実行フレームワークでは、アプリケーションを次の3つに分類しています。

  • トランザクション処理アプリケーション
    企業の基本的な定型業務を自動化するアプリケーション。これは、会計や受注管理など社内業務に関わる情報を記録するためのSoR(System of Record)のことです。
  • 変革アプリケーション
    企業の現行のビジネスモデルを変革するアプリケーション。例えば、個人向けカスタムメイドジーンズ注文用のインタラクティブなシステムなど、SoRによって蓄積されたデータを活用して、顧客や従業員との関係を強化するためのSoE(System of Engagement)が該当します。
  • 分析アプリケーション
    分析、解釈、情報と知識の共有を促進するアプリケーション。データ分析から得られた顧客や従業員の隠れたニーズや深層心理、つまりインサイトを理解するためのSoI(System of Insight)が該当します。

さて、ソフトウェアのアーキテクチャパターンの一つにコマンド・クエリ責務分離(CQRS)パターンがあります。
これは、データストアに対する更新操作を集めたコマンド処理と、読み取り操作(クエリ)を集めたクエリ処理を完全に分離するアーキテクチャパターンです。
CQRSでは、クライアントからのコマンドは一方通行で書き込み用データストアに届き、クエリは別の読み込み用データストアに対して発行します。
コマンド処理によって書き込み用データストアを更新するタミングで、読み込み用データストアも更新し、互いの同期をとります。
書き込み用データストアには、通常、リレーショナル・データベースを適用し、読み込み用データストアには、通常、データウェアハウスやNoSQLを適用します。

ここでは、トランザクション処理アプリケーションをコマンド処理のアプリケーション、分析アプリケーションをクエリ処理のアプリケーションと考えます。
※帳票出力などレポート処理もクエリ処理として、トランザクション処理アプリケーションから分離します。

それでは、変革アプリケーションはどういう位置づけかというと、次の図のように、これまで人が行ってきた記録業務(コマンド処理)や分析業務(クエリ処理)をAIが代行する機能だと考えます。

トランザクション処理アプリケーションの分類

トランザクション処理アプリケーションは、業務活動の結果としての事実(データ)を記録するアプリケーションです。
ここでは、職務(ジョブ)にトランザクション処理アプリケーションを対応させます。
ジョブは、内部統制による職務分掌や、同じスキルセット、ドメイン知識を持つ機能単位として考えられているので、ジョブ単位にトランザクション処理アプリケーションを分割することで、業務機能とアプリケーションを対応させることができます。
これは、結果的に、ソフトウェア設計原則の単一責任の原則情報エキスパートにも則ることになり、そういう意味でも適切な粒度になります。
ジョブは、活動領域ごとに考えます。
例えば、会社の活動領域を次のように分類した場合を考えます。

この活動領域をベースに、ジョブを次のように分類します。

以下、ジョブを分掌したときの考え方について説明します。

  • 生産管理者と製造担当者の分掌
    戦略目標「製品/部品の安定供給および適正在庫」を実現するためには、在庫のムラを防ぐためには、需要予測の精度上げるとともに、需要予測の結果と生産能力を考慮して生産計画を策定し適正数部品を仕込むことが重要です。
    そこで、製造と生産管理の職務を分掌し生産計画の専門性を強化するようにします。
  • 製造担当者と品質担当者の分掌
    戦略目標「製品品質の維持向上」を実現するために、製造と品質管理の職務を分掌し品質管理の専門性を強化します。
  • 購買管理者、入荷管理者、支払管理者の分掌
    もし、購買管理者が部品の発注、入荷、代金の支払をすべて行うと、どのようなリスクが発生するでしょか。
    不正などにより購買管理者が発注した部品が棚卸資産として計上されない可能性があります。
    また、購買管理者に会計に知識がない場合、代金が入金されても買掛金が消し込みされない可能性があります。
    これは、棚卸資産や買掛金の実在性に対するリスクになります。
    なので、財務報告の信頼性リスクを統制するために、購買管理者、入荷管理者、支払管理者の職務を分掌(ぶんしょう)し、部品の発注、入荷、代金の支払の責務を分けることにします。
  • 販売管理者、出荷管理者、請求管理者の分掌
    もし、販売管理者が製品の受注、出荷、代金の請求をすべて行うと、どのようなリスクが発生するでしょか。
    不正などにより販売管理者が受注した製品が棚卸資産として計上されない可能性があります。
    また、販売管理者に会計に知識がない場合、代金が回収されても売掛金が消し込みされない可能性があります。
    これは、棚卸資産や売掛金の実在性に対するリスクになります。
    なので、財務報告の信頼性リスクを統制するために、販売管理者、出荷管理者、請求管理者の職務を分掌し、製品の受注、出荷、代金の請求の責務を分けることにします。
  • 在庫管理者と会計管理者の分掌
    物財を扱う在庫管理者が帳簿を扱うと、不正などにより正しく棚卸資産が計上されない可能性があります。
    なので、財務報告の信頼性リスクを統制するために、物財を扱う在庫管理者と帳簿を扱う会計管理者を分掌し、正しく棚卸資産が計上されるようにします。

ジョブの分類に対応させてトランザクション処理アプリケーションの構成を次のように設計します。

戦略目標「製品品質の維持向上」を実現するために、顧客に導入した納入機(製品個体)の状態を監視し予防保全を実現するため納入機管理システムを導入します。
得意先元帳や仕入先元帳に対応するシステムを導入し債権債務を細かく管理するため会計管理システムから売上管理システムと仕入管理システムを独立させます。

分析アプリケーションの分類

次に分析アプリケーションの分類ですが、これは、ソフトウェア設計原則の単一責任の原則情報エキスパートに従って、分析の目的別に分類します。
例えば、売上分析をしたい場合は、売上分析システムになります。
次の図のように、BSCKPIが定義されている場合、KPIごとに分析システムを設定することができます。

マイクロサービス化

先行きが不透明で予測困難な昨今、業務とシステムを、環境の変化に合わせて機敏に適応できるようにするためにもマイクロサービスアーキテクチャを採用することをオススメします。
マイクロサービスとは、協調して動作する小規模で自律的なソフトウェア部品のことです。
企業では、様々なアプリケーションがありますが、ここでは、どのアプリケーションををマイクロサービス化し、どの部分に既成の業務パッケージを適用するか、その考え方について説明します。
次の図は、企業のアプリケーションを、業務活動の特殊性と規模で分類したものです。

これを見ると、業務活動の規模が大きくて特殊なアプリケーションはスクラッチ開発がよく、業務活動の規模が大きくて汎用的なアプリケーションは業務パッケージを適用したほうがよいとなっています。
なぜならば、業務活動の規模が大きくて特殊なアプリケーションは、ビジネスのノウハウが機能として蓄積されていく部分なので変更可能性が高く、自分たちが自由に変更しにく汎用的な業務パッケージが足かせになる可能性が高いからです。
マイケル・ポーターのバリューチェーンは主要活動と支援活動から構成されていますが、価値を創り、伝え、届ける主要活動の部分は、ビジネスの根幹となる部分であり特殊性が高く、支援活動は汎用性が高いと考えることができます。
特に、会計や給与計算などは、会社によって機能が変わるわけではなく法改正による機能変更をいちいち自社で行う必要はないので、それこそ既成の業務パッケージを適用するほうがよいと考えます。
そして、この業務活動の規模が大きくて特殊で変更可能性が高いアプリケーションこそマイクロサービスを適用すべきだと考えます。
次の図は、トランザクション処理アプリケーションのポートフォリオで、SCMシステム、PLMシステム、CRMシステムをバリューチェーンの主要活動、ERPの部分をバリューチェンの支援活動とし、主要活動の部分をサービスにし、支援活動の部分に業務パッケージを適用した例です。

次に分析システムですが、これは、分析の目的の単位に分けられているので、次の図のように、すべてマイクロサービスと考えることができます。

マイクロサービスは、さらに、次の観点から分割することができます。

  • 業務機能横断的機能のサービス化
    ロギングサービスや認証サービスなど業務機能に共通の機能をマイクロサービスにします。
  • BFF(Backend For Frontend)パターンの適用
    UIごとのバックエンド機能をマイクロサービスにします。

昨今の生成AIの飛躍により、次の図のように、今後、人間の作業がAIに置き換えられて業務が変革されていくことが考えられます。

日本では、ファーストリテイリング社(ユニクロ運営会社)が、2015年からECサイトのアプリケーションやスマートフォンアプリ「ユニクロ・アプリ」などにマイクロサービスを適用しはじめ、商品管理や在庫管理など従来パッケージ製品を適用していた基幹システムの領域までマイクロサービス化しているようです。
パッケージ製品は、カスタマイズの自由度が低く、変更に時間が掛かるため、基幹業務システムで、会社のコアのナレッジがたまっている部分は、パッケージを使うのではなく、今後は自分たちで作るべきだと判断したようです。
会社のコアの業務は、できるだけマイクロサービス化して、環境の変化に機敏に適応できるようにしておくことが得策なのではないでしょうか。

-DX, アプリケーション

執筆者:


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連記事

【実践!DX】DX戦略の考え方

ここでは、以下の観点で、DX&# …

エンタープライズアーキテクチャ(EA)とは【わかりやすく解説】

ここでは、以下の観点で、&#12 …

データドリブン経営

これは、データドリブン経&#21 …

クラス図を使った概念モデルの作り方

ここでは、UMLのクラス図を使& …

オブジェクトの性質【同一性、等価性、不変性、参照透過性】

ここでは、オブジェクトの&#24 …