お客さまの情報システムにおいて、業務モデル（論理モデル）の視点ならびに論理アーキテクチャ（責務）の視点での、アプリケーションの可視化プロダクトをご提供させていただきます。
現行システムの保守開発や運用の場面では、担当者の変更や高齢化が進むとともにシステム資産のレガシー化が進行しており、「現状業務の理解不足」などによるシステム改修の難しさを抱えています。現行システムの再構築時の調査対象外となる機能については、「現行通りの仕様で」とするなどシステム開発部門やベンダーに調査作業を一任（丸投げ）しており、下流工程の大きなリスクとなるにも上流工程での把握や可視化は難しいのが現状です。
ここでは、システム可視化ソリューションの「システム保守支援機能」プロダクトをご紹介いたします。
従来のアプリケーション資産の可視化支援は、一般的には以下の４点を提供します。（①）
また、業務の可視化支援となるビジネスモデリング（モデリングサービス）は、現行業務モデル（As-Is）や新業務モデル（To-Be）を作成し、業務に定義するデータ（モノ）とプロセス（コト）を可視化します。（②）
以下はデータドメインで表現した業務モデル図（例：電気業種の論理モデル）
①は業務の可視化の視点が不足し、②は現行システムのアプリケーション資産を結びつけるには、現行業務を理解している担当者が不足している中では、それなりの工数と期間を要します。システムを改修するうえでは現行システムの「ビジネスに必要な業務の流れと情報」に結びついた、アプリケーション資産を可視化するための手段が必要であり重要です。
エンジニアが影響調査や分析作業を実施する際は、対象のシステム全体を俯瞰したうえで対象となる機能や範囲を特定し、それらに含まれる具体的なプログラムなどの処理を理解する進め方が一般的です。この処理解析ステップ（順序）を意識することが重要なポイントです。
※影響調査や分析のステップを示します（≠単純なステートメント修正時などの手順）
現行システム全体を俯瞰したうえで対象となる機能や範囲を特定するためには、「ビジネスに必要な業務の流れと情報」に結びついたアプリケーション資産を、可視化する手段が必要であり重要です。
このことから、業種標準の「業務モデル（論理モデル）のデータドメイン」とそれらに含まれる「モノ一覧」に、現行システムのデータ項目となる要素を結びつけることで、現行システムのアプリケーション資産を業務モデル（論理モデル）の視点で可視化します。このようにすることで、業種パッケージと同様の視点で現行システムを可視化することが可能となります。
※データの流れおよび処理アクセスの線や図形の一部は省略しています
ホスト系の開発手法の手続き型や関数型は、手続きに沿った処理の流れに共通化などを考慮し、手続きごとの集まりをアプリケーションとして作成します（”線”を作る）。オブジェクト指向型の開発手法では、開発の単位はモノ（情報や状態）とコト（振る舞い、操作）の最小単位の集まりをアプリケーションとして作成します（”点”を作る）。
このことから、特にオブジェクト指向型の開発手法では、各アプリケーションを構成と関係性で集める（結びつける）だけでは影響範囲や結びつきを把握できても、一連の手続きの流れを可視化することは難しい（粒度の細かな”点”を集めるだけの）ため、論理アーキテクチャとアプリケーションの配置箇所やアプリケーション種別などを可視化します。
