アプリケーションマネジメントの導入方法

ここでは、アプリケーションマネジメントについて次の観点で解説します。

• なぜアプリケーションマネジメントが必要なのか
• アプリケーションマネジメントとは何か
• アプリケーションマネジメントの導入方法
• 関連動画

なぜアプリケーションマネジメントが必要なのか

変化が激しく、不透明で先行きが予測できない昨今の経営環境を、

• Volatility（変動性）
• Uncertainty（不確実性）
• Complexity（複雑性）
• Ambiguity（不透明性）

の頭文字をとってVUCA（ブーカ）という言葉で表すことがあります。
それは、SNSやモバイル技術によって人と人がつながる時間や距離が短くなったことで、
個人の欲望や考えが、複雑なネットワークを介してすぐに世界中に広がり、
いつどこで、どんな需要が生まれるか読みづらく、欲求の新陳代謝も激しくなっているからではないでしょうか。
このような時代、環境の変化にアジャイルに対応しながらビジネスを展開していく必要がありますが、複雑化、ブラックボックス化した既存の業務やシステムが足かせとなってスムーズに適応できない会社が多々あるようです。

多くの会社が、
ビジネスの変化が加速し、ビジネスとITが密接化する中、全体の設計図もなく、必要に応じてシステムを導入してきた結果、

• 大規模で複雑なシステムがサイロのように乱立している
• 重複して整合していないデータが散在している
• 個別の業務やシステムは詳しいが全体を理解できる人や資料がない

というカオスで雁字搦めな状況に陥っています。
経済産業省が2018年に出したDXレポート ～ITシステム「2025年の崖」の克服とDXの本格的な展開～ではでは、企業がDXに対応できない現状を、

• 既存システムが、事業部門ごとに構築されて、全社横断的なデータ活用ができなかったり、過剰なカスタマイズがなされているなどにより、複雑化・ブラックボックス化している
• 経営者がDXを望んでも、データ活用のために上記のような既存システムの問題を解決し、そのためには業務自体の見直しも求められる中(=経営改革そのもの)、現場サイドの抵抗も大きく、いかにこれを実行するかが課題となっている

と分析した上で、このような状況を改善できない場合、

• データを活用しきれず、DXを実現できないため、市場の変化に対応して、ビジネス・モデルを柔軟・迅速に変更することができずデジタル競争の敗者になる
• 多くの技術的負債を抱え、業務基盤その ものの維持・継承が困難になる
• 保守運用の担い手不在で、サイバーセキュリティや事故・災害によるシステムトラブルやデータ滅失等のリスクの高まる

という状況に陥り、DXが実現できないのみでなく、2025年以降、全体で最大12兆円/年(現在の約3倍)の経済損失が生じる可能性(2025年の崖）と予想しています。
技術的負債(Technical debt)とは、短期的な観点でシステムを開発し、結果として、長期的に保守費や運用費が高騰している状態（要は金食い虫）のことです。
次の図は、技術的負債が発生するメカニズム、つまり、システムが収益を生まない金食い虫になるメカニズムを示したものです。

これを見ると、様々な原因が重なって、機能追加・変更に対応できるコストの低下を招いていることがわかります。
つまり、「機能追加・変更に対応できるコストの低下」が技術的負債を発生させる根源になります。
そこで、これを解消するために「低コストで品質を確保し迅速に機能追加・変更できる仕組の導入」という新しい原因を追加します。
すると、次の図のように、これまで問題となっていた事象を防いで、結果的に障害対応コストの増加を抑えるとともにIT人材を確保することができるようになります。

アプリケーションマネジメントは、低コストで品質を確保し迅速に機能追加・変更できる仕組で、これを導入することで、技術的負債の増加を防ぎ、IT投資の効果を最大化することができるようになります。

アプリケーションマネジメントとは何か

アプリケーションマネジメントは、DevOpsやマイクロサービスアーキテクチャを適用することで、ビジネスの変化に合わせて、迅速に、品質の高いアプリケーションを導入するための仕組みです。
アプリケーションマネジメントは、次のような課題を解決します。

• 作業のムリ、ムダ、ムラをなくすことによるリードタイムの短縮化
• フィードバックによる問題の早期発見と解決
• 継続的な学習と実験によるプロセス品質の改善
• 小規模で自律的なアプリケーションおよび組織による生産性と保守性の向上

DevOpsの適用

DevOpsとは、開発 (Development) と運用 (Operations) を組み合わせることで、ソフトウェアを迅速に高い頻度で開発することを可能にする手法のことです。
「The DevOps ハンドブック 理論・原則・実践のすべて」という書籍には、DevOpsを支える次の３つの実践原則について言及しています。

1. フローの原則
   開発→運用→顧客の左から右へのワークフローを高速にすること。
   
   書籍では、これを実現するため必要な方法として次のことを上げています。
   • 作業を可視化すること
   • WIP（仕掛り）を制限すること
   • バッチサイズを縮小すること
   • プロセスを自動化して受け渡しの数を削減すること
   • 絶えず制約条件（ボトルネック）を見つけ出すこと
   • バリューストリームからムダを取り除くこと

   これを見ると、作業のムリ、ムダ、ムラをなくすといいうリーン生産方式、および、アジャイル開発の考え方が反映されていることがわかります。
   バリューストリームとは、ビジネス上の仮説を立案してから、顧客に価値を送り届ける技術サービスを生み出すまでの間に必要なプロセスのことです。
   バリューチェーンで言えば、主要活動の流れということになります。
   また、上記プロセスの自動化には、テストからデプロイまでを自動化する継続的デリバリの考え方が反映されていますし、マイクロサービスアーキテクチャを適用することで、バッチサイズを縮小することができます。

2. フィードバックの原則
   バリューストリームのあらゆるステージで、すばやくてコンスタントな右から左へのフィードバックフローを実現すること。
   
   書籍では、これを実現するため必要な方法として次のことを上げています。
   • 発生と同時に問題を知ること
   • 新しい知識を作り上げるために組織が一丸となって問題解決に当たること
   • 上流での（早めの）品質確保を追求すること
   • 下流の（次の）ワークセンターのために最適な出力をすること

   これを見ると、フィードバックによって問題の早期発見と解決を図ることで、問題を先延ばしすることなく、安全で回復力（レジリエンス）のある作業システムを構築することができることがわかります。

3. 継続的な学習と実験の原則
   ダイナミックで統制がとれた科学的なアプローチに基づく実験とリスクテイクを支持し、成功と失敗の両方から組織として学習し教訓を得ていく生産的な高信頼マネジメントの企業文化を生み出すこと。
   
   書籍では、これを実現するため必要な方法として次のことを上げています。
   • 日常業務の改善を制度化すること
   • ローカルな発見をグローバルな改善に転化すること
   • 日常業務に回復力を鍛えるパターンを注入すること
   • リーダーが学習する文化を奨励すること

   これを見ると、継続的な学習と実験によってプロセスを改善する文化をつくりだすことが重要だということがわかります。

マイクロサービスアーキテクチャの適用

マイクロサービスとは、協調して動作する小規模で自律的なソフトウェア部品のことです。
マイクロサービスについては、

• マイクロサービスアーキテクチャ
• モノリスからマイクロサービスへ

が参考になります。

既存の基幹システムをマイクロサービスとしてモジュール化することによって、アプリケーション開発の生産性と保守性を上げることができます。

この例では、画面まわりを処理するフロントエンドアプリケーションが、ビジネスロジックとデータアクセスを制御するマイクロサービスを使う構造になっています。
これによって、新しいフロントエンドアプリケーションを開発するとき、すでに在るマイクロサービスを部品として再利用することができるので、開発の生産性が上がり、企業を変化に強い構造にすることができます。
また、データ構造が変わった場合、関連するマイクロサービスは影響を受けますが、そのマイクロサービスを利用するフロントエンドアプリケーションは一切影響受けないので、高い保守性を実現することができ、企業を変化に強い構造にすることができます。
マイクロサービスという技術を活用して企業全体のアプリケーションをモジュール化（部品化）し一元管理することで、システムの保守性、安全性など品質を向上させ、企業を「変化に強い構造」にすることができます。
次の図は、全社IT基盤におけるアプリケーション基盤のイメージです。

記録システム（System of Record：SoR）である基幹システムをマイクロサービスとして様々なアプリケーションから利用される形にすることによってアプリケーション基盤を構築することができます。

アプリケーションマネジメントの位置づけ

バリューチェーンを構成する活動の中でアプリケーションマネジメントをみると、情報管理の活動に該当します。

ここでは、次の図のように、情報管理の活動を

• アプリケーションマネジメント
• データマネジメント
• ITサービスマネジメント

に分けて考えます。
アプリケーションサービスマネジメントは、情報管理活動の中の、個々のアプリケーションと企業全体のアプリケーションを管理する活動という位置づけになります。

アプリケーションマネジメントの導入方法

それでは、アプリケーションマネジメントはどのように導入すればよいのでしょうか。
アプリケーションマネジメントを導入するためのタスクは次のようになります。

上図の設計、戦略、構築、運用フェーズの関係は、次の図のようになります。

つまり、

• 設計は、ほぼ不変的なパーパス（目的）を目指す活動で、
• 戦略、構築は、長期的なビジョンを目指す活動、
• 運用は、短期的なゴール（目標）を管理する活動

です。
なので、活動の流れは、次のように分けて考えることができます。

• アプリケーションマネジメント導入プロセス
  アプリケーションマネジメントの設計、戦略、構築の流れ。
• アプリケーションマネジメントプロセス
  アプリケーションマネジメントの運用の流れ。

ここでは、設計フェーズと戦略フェーズに絞って、データマネジメントの骨格を次の観点で説明します。

• アプリケーションアーキテクチャの設計
• アプリケーションマネジメントジョブの設計
• アプリケーションマネジメントプロセスの設計
• アプリケーション戦略の策定
• アプリケーション基盤の構築
• アプリケーションマネジメント組織の構築

この中の

• アプリケーションアーキテクチャの設計
• アプリケーション戦略の策定
• アプリケーション基盤の構築

は、

1. まず、あるべきアプリケーションの型をつくり（アプリケーションのモデル化）
2. その型をベースに既存のアプリケーションを最適化（統合、分割、追加、削除）し（アプリケーションの最適化）、
3. 個々のアプリケーションを交換可能な部品として実装する（アプリケーションのモジュール化）

することで、変化に強いアプリケーション基盤を構築する流れになります。

アプリケーションアーキテクチャの設計

アプリケーションアーキテクチャは、あるべきアプリケーションの構造を全社レベルでモデル化します。
アプリケーションアーキテクチャは次の手順で設計します。

• コンテキストマップの設計
• アプリケーション統合方式の設計
• 要件定義
• 外部設計

要件定義と外部設計は、個々のアプリケーションの開発と重なる工程ですが、全社レベルでアプリケーションを統合し、全体最適化を図る場合、個別のアプリケーションだけの視点でだけではなく、全社レベルの視点が不可欠になります。

コンテキストマップの設計

コンテキストマップ（Context Map）

は、ドメイン駆動設計の概念で、個々のアプリケーションのコンテキスト境界間の関係を描いたものです。
詳細は、ドメイン駆動設計・戦略的設計を参照してください。
コンテキストマップは、ビジネスアーキテクチャのバリューストラクチャに基づいて以下の観点で設計します。

• アプリケーションタイプの定義
  コンテキストマップを構成するコンテキスト境界は、ビジネスアーキテクチャのジョブと同じ単位になり、ここでは、アプリケーションタイプ（アプリケーションの型）と呼びます。
• 上流（Upstream）と下流（Downstream）の識別
  上流は、モデルの変更が相手に影響を与える側で、下流は、相手のモデルの変更の影響を受ける側です。
• データタイプの特定
  各アプリケーションタイプが管理するデータタイプを特定します。

次の図は、俺のフレンチのバリューストラクチャをコンテキストマップに展開した例です。

アプリケーション統合方式の設計

次に、上記コンテキストマップを構成する個々のアプリケーションタイプを、どのように連携させ統合するか次の観点で設計します。

• 組織パターン
• 統合パターン
• システム統合方式
• 連携形態

組織パターン

アプリケーションタイプを管理する組織は異なる可能性があります。
なので、まず、組織の関係がどうなっているのか考慮する必要があります。
ドメイン駆動設計では、組織の関係を組織パターンとしてまとめています。

統合パターン

アプリケーションタイプを管理する組織の関係がわかったら、その関係に応じて、アプリケーション同士をどう統合するか方針を決める必要があります。
ドメイン駆動設計では、アプリケーション同士をどう統合するかを統合パターンとしてまとめています。

システム統合方式

次に、アプリケーション同士を連携して、システム全体を統合するときの方式を決めます。
アプリケーションがN対Nで接続される場合、管理コストの削減という観点から、メディエーターとしてのデータ連携基盤の導入を検討します。

データ連携基盤を介してシステムを統合するときの方式には次の３つがあります。

• アプリケーション統合
  ESB、あるいは、EAIを介してアプリケーション同士を連携して統合する方式です。
• データ統合
  マスターデータや生データを管理するデータウェアハウス（データレイク）である全社データ基盤を介してシステムを統合する方式です。
  全社データ基盤は、次のような機能を担います。
  • 全社データのバックアップ
  • マスターデータの履歴管理
  • 非正規化データ（生データ）の管理
• ハイブリッド統合
  アプリケーション統合とデータ統合のハイブリッドで、全社データ基盤をESB/EAIの一ノードとして位置づける方式です。

次の図は、データ統合を実現した例です。

連携形態

統合パターンとして、公開ホストサービスを採用した場合、アプリケーションタイプを連携するときの代表的な形態には次の２つがあります。

• リクエスト/レスポンス
  受信側がリクエストを発行し、送信側のレスポンスを待つ形態。
  通常、送信側と受信側の処理は同期しますが、送信側にコールバックを登録することで非同期通信をすることも可能です。
  
• イベントドリブン
  送信側に起きたイベントを受信側に通知することで、受信側の処理が駆動される形態。
  送信側は、受信側に処理の指示を出すわけではなく、イベントを通知するだけで、受信側の処理もレスポンスも待ちません（非同期通信）。
  

リクエスト/レスポンスの場合、もし、受信側に不具合が生じた場合、送信側の処理が続行できなくなりますが、イベントドリブンの場合、そのようなことはありません。
つまり、イベントドリブンの方が相手に対する依存度が低く疎結合になります。
従って、独立性が高いアプリケーションタイプ同士の連携で、相手のレスポンスの結果がリアルタイムに必要ではない場合、アプリケーション間の疎結合を実現するイベントドリブンを選択するほうが効果的だと言えます。
書籍「モノリスからマイクロサービスへ」でも、アプリケーション同士を連携するときは、疎結合を実現するイベントドリブンを推奨しています。
さて、リクエスト/レスポンスの実装技術の例としては、RESTfulなHTTP（REST/HTTP）があります。
また、イベントドリブンの実装技術の例としては非同期メッセージングがあります。
例えば、ActiveMQやRabbitMQなどMOM（Message Oriented Middleware）のQueueやTopicを使うことで、非同期メッセージングを実現することができます。
下図は、Topicを使ってPublisher-Subscriber（Pub/Sub）パターンを実現した非同期メッセージングの例です。
Pub/Subパターンとは、発行者（Publisher）からメッセージを発行(publishes)し、購読者（Subscriber）にそのメッセージを配信(delivers)するデザインパターンです。

Pub/Subパターンにおけるメッセージのあて先（Destination)はTopicになります。
まず、購読者はTopicに対し購読依頼(Subscribes)を行います。
すると、発行者がTopicにメッセージを発行する都度、Topicに購読依頼している全ての購読者にメッセージが配信されます。

さて、統合方式が決まったら、コンテキストマップに連携方式を記載します。

一対一の非同期メッセージング連携の場合Queueを使用しますが、一対多の非同期メッセージング連携の場合Topicを使用します。
上図は、ポイントツーポイントで各アプリケーションタイプが連携していますが、全社データ基盤を中心に統合する場合、次の図のようになります。


また、ESB/EAIを中心に統合する場合、次の図のようになります。

要件定義

次に、すべてのアプリケーションタイプの

• 機能要件
• 非機能要件

を定義します。
要件定義については、システム開発プロセス・要件定義を参照してください。

機能要件の定義

アプリケーションタイプの機能をユースケースとして定義します。
次の図は、上記コンテキストマップの販売（アプリケーションタイプ）のユースケースモデルの例です。

非機能要件の定義

次に、アプリケーションタイプの非機能要件を定義します。
次の図は、販売アプリケーションのデータ要件としての概念データモデルの例です。

アプリケーションタイプの概念データモデルは、データアーキテクチャの概念データモデルとして定義されたものから選択します。

外部設計

アプリケーションタイプの外部設計は次のタスクより構成されます。

• ユースケースの外部分析
• APIの設計
• 非同期メッセージングの設計

ユースケースの外部分析

コンテキストマップのアプリケーションタイプ同士がどのように相互作用してユースケースを実現するか分析し、ユースケースの実現可能性を検証します。
次の図は、上記「商品の注文」ユースケースを上記コンテキストマップのアプリケーションタイプどのように実現するかをシーケンス図で示した例です。

コンテキストマップを構成するアプリケーションタイプである販売と商品管理がREST/HTTPで連携して「商品の注文」ユースケースを実現していることがわかります。
これは、REST/HTTPで同期通信をする例ですが、メッセージングによって非同期通信を実現すると次の図のようになります。

商品管理の商品情報が更新される都度、非同期メッセージングによって販売に商品情報が配信されます。
なので、注文管理システムは、販売から最新の商品情報を取得することができます。

フロントエンドアプリケーションとアプリケーションタイプの間の通信は即時性を求められるのでREST/HTTPでを適用して同期を取る方法を推奨しますが、独立性が高いアプリケーションタイプ間の送受信で、即時性を要求されない場合、疎結合が実現される非同期メッセージングを適用することをお勧めします。

APIの設計

外部分析の結果からアプリケーションタイプに必要なAPIを抽出して、その仕様を定義します。
販売と商品管理の間の「商品の取得」メッセージのように、アプリケーションタイプ間がREST/HTTPで連携する場合、APIの仕様を、エンドポイント、HTTPメソッド、リクエストパラメータ、メッセージ、HTTPヘッダー、HTTPステータスコードなどで定義ます。

非同期メッセージングの設計

非同期メッセージングの場合、メッセージやQueue、Topicを定義します。

アプリケーションマネジメントジョブの設計

情報管理に関わるジョブは次のようになります。

• アプリケーション開発
  個別のアプリケーションを開発する役割。
• アプリケーション管理
  企業全体のアプリケーションを統合する役割。
• データ管理
  データマネジメントを行う役割。
  詳細は、データマネジメントジョブの設計を参照してください。
• 情報セキュリティ管理
  企業全体の情報セキュリティを管理する役割。
  情報セキュリティについては、データセキュリティとはを参照してください。
• IT基盤管理
  IT基盤の品質を維持向上する役割。

このうち、アプリケーション開発とアプリケーション管理がアプリケーションマネジメントのジョブになります。
なお、情報セキュリティ管理とIT基盤管理は、ITサービスマネジメントの役割になります。

アプリケーションマネジメントプロセスの設計

アプリケーションマネジメントプロセスには、個別のアプリケーション開発プロセスと企業全体のアプリケーションを統合するプロセスがあります。
個別のアプリケーション開発プロセスは次の図のようになります。

この中で、企業全体のアプリケーションを統合するプロセスが関係するのは次のタスクになります。

• 制約条件の定義
  アプリケーション管理者は、アプリケーション開発者に既存のマイクロサービスを活用することを推進します。
• 機能要件の定義
  アプリケーション開発者は、活用するマイクロサービスをユースケースのアクターとして定義します。
• 品質要件の定義
  アプリケーション開発者は、システムに求められる品質要件として、外部システムとの相互運用性を定義します。
• ユースケースの外部分析
  アプリケーション管理者は、アプリケーション開発者がマイクロサービスのインターフェースを分析するとき支援します。
• API設計
  アプリケーション管理者は、アプリケーション開発者がマイクロサービスのAPIを設計するとき支援します。
  APIを設計するとき、アプリケーション開発者は、マイクロサービスに対する相互運用性を考慮します。
• 実装
  アプリケーション管理者は、アプリケーション開発者が実装の一環としてマイクロサービスと連携するとき支援します。

個別アプリケーションの開発プロセスは、DevOpsとマイクロサービスアーキテクチャを適用してバリューストリームとして設計します。
次の図は、バリューストリームの例です。

次に、バリューストリームのうち、ビルド、統合テスト、システムテスト、運用テストの流れ（ビルドバイプライン）を自動化し、実装の都度、運用テストまで迅速にできる仕組（継続的デリバリ）を構築します。

書籍「マイクロサービスアーキテクチャ」では、マイクロサービスごとに一つのソースリポジトリを持ち、一つのビルドを生成することを推奨しています。

具体的には、次のような手順で、マイクロサービスごとに、自動化されたビルドパイプラインを構築します。

• バージョン管理システム（ソースリポジトリ）の準備
• 開発環境、テスト環境、ステージング環境、本番環境の準備
• 各環境に対するコンテナ型仮想環境（Dockerなど）の作成と配布
• CI/CDサーバーによるビルドパイプラインの構築

アプリケーション戦略の策定

アプリケーション戦略では、アプリケーションアーキテクチャに従って、既存のアプリケーションを統合、分割、追加、削除することで最適化します。
まず、会社内で☓☓システムと呼ばれている基幹システムをアプリケーションカテゴリ（アプリケーションタイプの分類）として洗い出します。
その上で、現行アプリケーションカテゴリのユースケースを洗い出し詳細化します。
次に、アプリケーションカテゴリを、アプリケーションアーキテクチャの構成要素であるアプリケーションタイプにマッピングします。
最後に、次の観点でアプリケーションカテゴリを最適化します。

• 複数のアプリケーションカテゴリが一つアプリケーションタイプにマッピングされる場合、ムダが生じているのでアプリケーションカテゴリを統合する
  統合するときは、アプリケーションカテゴリのユースケースが、アプリケーションタイプのユースケースに整合しているか確認します。
• 一つのアプリケーションカテゴリが複数のアプリケーションタイプにマッピングされる場合、ムリが生じているのでアプリケーションカテゴリを分割する
  分割するときは、アプリケーションカテゴリのユースケースとアプリケーションタイプのユースケースを対応させます。
• 必要なアプリケーションタイプに対するアプリケーションカテゴリがない場合、アプリケーションカテゴリを追加する
  アプリケーションタイプのユースケースから追加するアプリケーションカテゴリのユースケースを導きます。
• どのアプリケーションタイプにもマッピングされないアプリケーションカテゴリがある場合、アプリケーションカテゴリの削除（廃止）を検討する

アプリケーション基盤の構築

ここでは、アプリケーション戦略で最適化された個々のアプリケーションをマイクロサービスとしてモジュール化することで変化に強いシステム基盤を構築します。

マイクロサービス

マイクロサービスとは、ビジネス機能を一つのサービスとして提供するソフトウェア部品です。
書籍「モノリスからマイクロサービスへ」では、マイクロサービスを、ビジネスドメインに基づいてモデル化された、独立してデプロイ可能なサービスと言っています。
つまり、マイクロサービスは、論理的な概念ではなく、物理的なソフトウェアコンポーネントになります。
これをレイア構造で表すと次の図のようになります。

• 上述したアプリケーションタイプは、ジョブ（職務）を実現するアプリケーションの型。
• アプリケーションタイプを分類した論理的単位がアプリケーションカテゴリ。
• アプリケーションカテゴリの実例となる物理的な単位がマイクロサービス。

アプリケーション基盤

さて、アプリケーションマネジメントを導入する目的は、
企業のシステムを変化に強い構造にすること
です。
大規模で複雑になり手がつけられなくなった既存システムを、管理可能な小さな機能単位に分けて、それらを疎結合することでシステム全体の生産性（再利用性）や保守性を上げることです。

なので、全社レベルの業務が最適化されたマイクロサービスが連携し、個別業務に特化したフロントエンドアプリケーションがマイクロサービスにアクセスするアプリケーションアーキテクチャを実現することを目指します。
なお、アプリケーション基盤を構築する場合、次のテクノロジーアーキテクチャも考慮する必要があります。

• マイクロサービスを実現する技術
• ActiveMQなどマイクロサービスを連携する技術の選定
• ESBなどのデータ連携基盤を導入する場合、その技術の選定

次の図は、マイクロサービスが非同期メッセージングで連携したイメージを表しています。

マイクロサービスがESB（Enterprise Service Bus）などのデータ連携基盤を介して連携される場合は、次の図のようになります。

モノリスからマイクロサービスへ

それでは、まるで、絡み合った糸を解していくように既存システムをマイクロサービスに転換（transform）するためにはどうすればよいのでしょうか？
ポイントは、複雑化した既存のシステムの中身を解読するのではなく、あるべきシステムを描いて、それを既存システムに投影するというアプローチです。
アプリケーション戦略で、あるべきアプリケーションタイプに、既存システム（アプリケーションカテゴリ）を次のような手順でマッピンします。

• ユースケースの洗い出し
  まず、既存システムのユースケースを洗い出します。
• ユースケースの詳細化
  次に各ユースケースを詳細化します。
  ユースケースの詳細化については、システム開発プロセス・外部設計を参照してください。
• ユースケースの最適化
  最後に、既存システムのユースケースをアプリケーションタイプのユースケースに合わせて適切なかたちに変更します。

ここで重要なのは、ユースケース（機能要件）を定義することで、既存システムが本来実現すべき機能が明確になることです。
これよって、技術的負債である既存システムの仕様部分がナレッジという知的資産に変換されます。
既存システムが本来実現すべき機能が明確になったら、それをどうマイクロサービスとして実現していくか設計します。
書籍「モノリスからマイクロサービスへ」では、大規模で複雑になり手がつけられなくなった既存システム（書籍では、これをモノリスと読んでいます）をマイクロサービス化する方法として「ストラングラーアプリケーション」パターンを紹介しています。
「ストラングラーアプリケーション」パターンは、既存システムから移行対象の機能を切り出して、段階的にマイクロサービス化していくという手法です。

アプリケーションマネジメント組織の構築

アプリケーションマネジメントジョブの設計では職務を設計しますが、アプリケーションマネジメント組織は、アプリケーションマネジメントのビジョンをどう実現するか考えた上で、ジョブに部門を割り当てて設計します。
部門は経営環境の変化に応じて変わりますが、ジョブは不変です。
一昔前は、アプリケーションの開発も含めて情報システム部門がすべての職務を担っていました。

最近では、個々のアプリケーション開発は業務部門が担い、すべてのアプリケーションで共通する機能を情報システム部門が担うという形態になってきました。

この図のドメインですが、業務部門が遂行する業務領域で、事業単位の事業ドメインではなく、ジョブの単位の機能（ジョブ）ドメインを意味しています。

アプリケーションマネジメントでは、アプリケーションをマイクロサービスという小規模で自律した単位に分けて開発します。
なので、個々のマイクロサービスが独立してデリバリできるように次の図のような組織を設計します。

まず、内部統制を働かせるために、情報管理の職務を、情報管理を監督する側と、実行する側で分掌し、各業務部門に、情報管理を実行するすべての職務をアサインし、情報システム部門は、各業務部門で行われる情報管理の実行を監督するようにします。
そして、各業務部門ごとに、それが関係するアプリケーション（マイクロサービス）の開発から導入までの責任を負わせるようにします。
こうするこで、デリバリのバッチサイズが小さくなり、ビジネスの変化に合わせて、迅速に、品質の高いアプリケーションを導入することができるようになります。

【関連動画】