JP2018173881A - 評価処理プログラム、装置、及び方法 - Google Patents

Abstract

【課題】クラウド環境のプラットフォームへの移行を支援するプラットフォーム移行支援装置、方法を提供する。
【解決手段】プラットフォーム移行支援装置２０において、受付部２１が、移行元のシステムの移行元情報を受け付ける。シミュレーション部２５が、機能の提供形式を特定し、機能の組み合わせのバリエーションごとに、機能の性能の差を計算し、機能の組み合わせのバリエーションごとに、コストを計算する。提供部２６が、シミュレーション結果をクライアント端末に提供する。
【選択図】図４

Description

本発明は、評価処理プログラム、装置、及び方法に関する。

サービス提供環境のサーバを、クラウド環境上に移行させるにあたって、移行した場合に、どの程度の性能となり、移行のコストはどの程度掛かるのかといった移行支援を行うための技術がある。

移行支援のための技術の一例として、テンプレートに規定された機能を実現するために用いられる、コンピュータ資源提供サービス及び当該コンピュータ資源提供サービスにおける機能の組み合わせを複数抽出し、各々について性能指標値を算出する技術がある。

また、容易にクラウド化可能なアプリケーションの発見型の識別および移行のための技法がある。この技法では、エンティティの複数の既存のアプリケーションのインフラストラクチャを分析して、クラウドへの移行のために該少なくとも一つのインフラストラクチャを選択する。

特開２０１５−１６６９６３号公報 特表２０１４−５３２２４７号公報 特開２０１６−３５６４２号公報

しかし、上記の従来技術は、オンプレ（オンプレミス環境）−ＩａａＳ（Infrastructure as a Service）間、ＩａａＳ−ＩａａＳ間の移行支援に関する技術である。一方、ＰａａＳ（Platform as a Service）やＳａａＳ（Software as a Service）の移行支援の技術は提供されていない。

ＰａａＳやＳａａＳでは、次々に新機能の追加が行われるが、新機能リリースの度に属人的な構成検討を行うのは限界がある。

特に、ＰａａＳへの移行時にはシステムの機能毎にサーバが分割され、構成のパターンが複雑になる場合がある。また、ＰａａＳの基盤側の情報は利用者側では確認することができない。このように、ＰａａＳへの移行を検討している利用者が、性能面の影響や費用面の効果を確認することは容易ではない。

本発明は、一つの側面として、クラウド環境のプラットフォームへの移行を支援することを目的とする。

一つの態様として、クラウドに構築されるプラットフォームにおいて提供される機能のうち、移行元のシステムで利用している複数の機能を特定する入力を受け付ける。前記複数の機能間における連携状態の入力、及び前記移行元のシステムでの前記複数の提供形式の入力を受け付ける。前記プラットフォームにおける各機能の提供形式を記憶する記憶部を参照して、入力を受け付けた前記複数の機能の前記プラットフォームでの提供形式を特定する。前記移行元のシステムでの前記機能の性能と前記クラウドに構築される前記プラットフォームにおける機能の連携状態の違いに基づく前記機能の性能の差を出力する。又は、前記機能の前記移行元のシステムでの提供形式と前記クラウドに構築される前記プラットフォームでの提供形式の違いに基づく前記機能の性能の差を出力する。

一つの側面として、クラウド環境のプラットフォームへの移行を支援することができる、という効果を有する。

移行元環境の構成と、移行先のクラウド環境のＰａａＳの構成の一例を示す図である。 本実施形態の基盤提供型サービス、及びＡＰＩ提供型サービスの一例を示す図である。 本発明の実施形態に係る移行支援システムの概略構成を示すブロック図である。 本発明の実施形態のプラットフォーム移行支援装置の機能ブロック図である。 入力画面の画面イメージの一例を示す図である。 入力画面の画面イメージの一例を示す図である。 入力画面の画面イメージの一例を示す図である。 入力画面の画面イメージの一例を示す図である。 入力画面の画面イメージの一例を示す図である。 入力画面の画面イメージの一例を示す図である。 入力画面の画面イメージの一例を示す図である。 入力画面の画面イメージの一例を示す図である。 性能情報ＤＢの一例を示す図である。 移行情報ＤＢの一例を示す図である。 カタログ情報ＤＢの一例を示す図である。 入力される移行元環境の移行元情報、及び移行先のクラウド環境の構成の一例である。 機能の性能の差の計算の一例を示す図である。 費用面のコストの計算の一例を示す図である。 シミュレーション結果の画面イメージの一例である。 プラットフォーム移行支援装置として機能するコンピュータの概略構成を示すブロック図である。 プラットフォーム移行支援処理の一例を示すフローチャートである。

以下、図面を参照して本発明に係る実施形態の一例を詳細に説明する。

オンプレミスなどの移行元環境と、移行先のＰａａＳ（Platform as a Service）では、システム構成が異なるため、性能やコストに違いが生じる。例えば、図１に示すように、移行元環境は、Ｗｅｂ及びＡＰ（アプリ）サーバとＤＢサーバとの２台のサーバでシステムが構成されており、Ｗｅｂ及びＡＰサーバでアプリケーション（以下、「アプリ」と略記する場合もある）、バッチ、帳票、ストレージの機能を持ち、ＤＢサーバがＤＢの機能を持っている。一方、移行先のクラウド環境では、ＰａａＳによって、Ｗｅｂ及びＡＰサービス、バッチサービス、帳票サービス、及びＤＢサービスの４つのサービスでシステムが構成され、それぞれに機能を持つ場合が想定される。ＰａａＳを含むクラウド環境への移行には、このようなシステム構成の違いによる性能面、及びコスト面の差を把握することが必要である。

そこで、本発明の実施形態では、利用者が、移行元環境の情報を入力することで、ＰａａＳに移行した場合の性能面の影響やコスト面の効果を手軽に確認できる仕組みを提供できるようにする。

また、複数のクラウド環境のそれぞれで稼動しているＰａａＳやＩａａＳ（Infrastructure as a Service）のプラットフォームから収集した性能情報を、性能情報ＤＢに蓄積しておく。また、プラットフォームの運用コストをカタログ情報ＤＢに蓄積しておく。

入力された移行元環境と、性能情報ＤＢ、移行情報ＤＢ、及びカタログ情報ＤＢの情報を比較し、性能変化と費用をシミュレーションし、シミュレーション内容を画面へ出力する。

本実施形態では、オンプレミス環境で運用されているサービスのうち、Ｗｅｂ及びＡＰサービス、バッチ基盤サービス、ＤＢサービス、及び帳票サービスのＰａａＳへの移行を支援する仕組みについて説明する。

図２に示すように、これらのサービスのうちＷｅｂ及びＡＰサービス、バッチサービス、ＤＢサービスは基盤提供型サービスである。帳票サービスはＡＰＩ提供型サービスである。

Ｗｅｂ及びＡＰサービスは、Ｗｅｂ及びＡＰ実行基盤を提供するサービスである。バッチサービスは、バッチ実行基盤を提供するサービスである。ＤＢサービスは、ＲＤＢ（Relational Database）機能を搭載したインスタンスを提供するサービスである。帳票サービスは、ＷｅｂＡＰＩで帳票出力機能を利用できるサービスである。

図３に示すように、本実施形態に係るプラットフォーム移行支援システム１００は、クライアント端末１０と、プラットフォーム移行支援装置２０と、クラウド環境３０とを備えている。クライアント端末１０と、プラットフォーム移行支援装置２０と、クラウド環境３０とは、インターネット等のネットワーク１５を介して接続される。

クライアント端末１０は、プラットフォーム移行支援システム１００の利用者が利用する情報処理端末である。クライアント端末１０では、移行元情報の入力画面を表示し、利用者から移行元情報の入力を受け付ける。具体的な入力項目については後述する。クライアント端末１０は、例えば、ノート型ＰＣ、タブレット端末等で実現することができる。

プラットフォーム移行支援装置２０は、クライアント端末１０から移行元環境の移行元情報を受け付け、クラウド環境３０のＰａａＳを含むプラットフォームへ移行する際の性能及びコストに関するシミュレーションを行う装置である。プラットフォーム移行支援装置２０は、シミュレーション結果をクライアント端末１０に出力することで利用者に移行支援を提供する。また、シミュレーションに必要なクラウド環境３０の性能情報、移行情報、及びカタログ情報を取得する。プラットフォーム移行支援装置２０が、評価処理装置の一例である。

クラウド環境３０は、それぞれでＩａａＳやＰａａＳを含むプラットフォームが稼動するクラウド環境である。クラウド環境３０では、ＰａａＳで稼動する帳票サービスについて、帳票サービス性能情報として、帳票出力の実行ログから帳票出力時間の実測値を取得し、平均値を算出して保持しておく。また、クラウド環境３０では、ＰａａＳが稼動する各リージョン、及びＰａａＳで提供している各サービスに検証用インスタンスを作成し、定期的にサービス間通信性能の測定を行う。各リージョン及び各サービスの組み合わせごとに測定値の平均値を算出し保持している。また、ミドルウェア移行費用、及びクラウドサービス利用時発生費用を保持している。プラットフォーム移行支援装置２０がクラウド環境３０から取得して格納する情報については後述する。

プラットフォーム移行支援装置２０は、図４に示すように、機能的には、受付部２１と、取得部２２と、性能情報ＤＢ２３と、移行情報ＤＢ２４ａと、カタログ情報ＤＢ２４ｂと、シミュレーション部２５と、提供部２６とを含む。

受付部２１は、クライアント端末１０の入力画面から利用者が入力した移行元情報を受け付ける。

図５〜図１２に移行元情報の入力項目を提示する入力画面の画面イメージの一例を示す。入力画面は、提供部２６によって、クライアント端末１０に提示してもよいし、クライアント端末１０に予めダウンロードしておいてもよい。

図５に示す入力画面には、入力項目領域６０ａ、及びボタン７０が含まれる。

図５に示すように、入力項目領域６０ａでは、サーバ情報として、機能の利用有無、機能の連携情報、及び機能を備えるサーバのサーバスペックの入力を受け付ける。以下では、機能として、Ｗｅｂ、ＡＰ、帳票、バッチ、及びＤＢがある場合を例に説明する。利用有無は、機能を移行元で利用しているかを選択可能なチェックボックス形式で入力される。連携情報は、それぞれの機能について、いずれの機能と連携しているかを選択可能なチェックボックス形式で入力される。サーバスペックは、ＣＰＵのコア数、及びメモリ容量（ＧＢ単位）の数値の入力が可能な形式で入力される。利用者は、入力項目領域６０ａの入力項目を入力後、ボタン７０を押下することで次の入力画面に遷移する。なお、機能の連携情報が、移行元のシステムの機能の連携状態の一例である。

図６に示す入力画面は、入力項目領域６０ｂ〜６０ｄ、及びボタン７０を含む。

図６に示すように、入力項目領域６０ｂでは、サーバ台数、入力項目領域６０ｃでは、サーバ内の機能、入力項目領域６０ｄでは、サーバ間のネットワーク性能の入力を受け付ける。入力項目領域６０ｂの入力は、サーバ台数の数値の入力が可能な形式である。入力項目領域６０ｃの入力は、サーバ内の機能として、Ｗｅｂ、ＡＰ、帳票、バッチ、及びＤＢを選択可能なチェックボックス形式である。入力項目領域６０ｄの入力は、サーバ間のネットワーク性能として、サーバ間のスループット（Ｇｂｐｓ（gigabits per second）単位）、及びレイテンシ（ミリ秒単位）の数値の入力が可能な形式である。

また、入力項目領域６０ｃ、及び入力項目領域６０ｄは入力したサーバ台数の数によって入力項目が増減する。図６の太枠部分はサーバ台数を３とした場合に出現する入力項目である。このように移行元環境の構成によって必要な入力項目が増える場合がある。

図７に示す入力画面は、入力項目領域６０ａの利用有無でＷｅｂを選択した場合に表示される入力画面であり、入力項目領域６０ｅ〜６０ｇ、及びボタン７０を含む。

図７に示すように、入力項目領域６０ｅでは、ミドルウェア情報、入力項目領域６０ｆでは、Ｗｅｂサーバのミドルウェア選択、入力項目領域６０ｇでは、画面規模の入力を受け付ける。入力項目領域６０ｅのミドルウェア情報は、ＷｅｂサーバはＡｐａｃｈｅを利用しているかを、「はい」又は「いいえ」で選択可能な形式で入力される。入力項目領域６０ｆは、入力項目領域６０ｅで「いいえ」を選択した場合に出現する入力項目であり、ドロップダウンの選択肢として、「Ｗｅｂサーバの種類」、及び「その他」が選択可能な形式である。「Ｗｅｂサーバの種類」としては、後述する移行情報ＤＢ２４ａの「ミドルウェア移行費用テーブル」の移行前のＷｅｂのミドルウェアの種類を用いる。入力項目領域６０ｇの画面規模は、Ｗｅｂサーバのソースコードの長さを、ＫＳ（キロステップ）単位で表した数値で入力が可能な形式で入力される。なお、ミドルウェア情報の利用を確認する対象は、移行先のクラウド環境で使用されているミドルウェアの一例であり、以下においても同様である。

図８に示す入力画面は、入力項目領域６０ａの利用有無でＡＰを選択した場合に表示される入力画面であり、入力項目領域６０ｈ〜６０ｊ、及びボタン７０を含む。

図８に示すように、入力項目領域６０ｈでは、ＡＰサーバのミドルウェア情報、入力項目領域６０ｉでは、ミドルウェア選択、入力項目領域６０ｊでは、アプリ規模の入力を受け付ける。入力項目領域６０ｈのミドルウェア情報は、ＡＰサーバはＴｏｍｃａｔを利用しているか否かを、「はい」又は「いいえ」で選択可能な形式で入力される。入力項目領域６０ｉは、入力項目領域６０ｈで「いいえ」を選択した場合に出現する入力項目であり、ドロップダウンの選択肢として、「ＡＰサーバの種類」、及び「その他」が選択可能な形式である。「ＡＰサーバの種類」としては、後述する移行情報ＤＢ２４ａの「ミドルウェア移行費用テーブル」の移行前のＡＰのミドルウェアの種類を用いる。入力項目領域６０ｊのアプリ規模は、ＡＰサーバのソースコードの長さを、ＫＳ（キロステップ）単位で表した数値で入力が可能な形式で入力される。

図９に示す入力画面は、入力項目領域６０ａの利用有無でバッチを選択した場合に表示される入力画面であり、入力項目領域６０ｋ〜６０ｎ、及びボタン７０を含む。

図９に示すように、入力項目領域６０ｋでは、バッチのＯＳ情報、入力項目領域６０ｌでは、ミドルウェア選択、入力項目領域６０ｍでは、バッチ規模、入力項目領域６０ｎでは、処理情報の入力を受け付ける。入力項目領域６０ｋのバッチのＯＳ情報は、バッチはｂａｓｈを利用しているか否かを、「はい」又は「いいえ」で選択可能な形式で入力される。入力項目領域６０ｌは、入力項目領域６０ｋで「いいえ」を選択した場合に出現する入力項目であり、ドロップダウンの選択肢として、「バッチサーバの種類」、及び「その他」が選択可能な形式である。「バッチサーバの種類」としては、後述する移行情報ＤＢ２４ａの「ミドルウェア移行費用テーブル」の移行前のバッチのミドルウェアの種類を用いる。入力項目領域６０ｍのバッチ規模は、バッチサーバのソースコードの長さを、ＫＳ（キロステップ）単位で表した数値の入力が可能な形式で入力される。入力項目領域６０ｎの処理情報は、バッチ処理時のファイル平均転送容量を通信量（ＭＢ）単位で表した数値で入力が可能な形式で入力される。

図１０に示す入力画面は、入力項目領域６０ａの利用有無で帳票を選択した場合に表示される入力画面であり、入力項目領域６０ｏ〜６０ｒ、及びボタン７０を含む。

図１０に示すように、入力項目領域６０ｏでは、帳票のミドルウェア情報、入力項目領域６０ｐでは、ミドルウェア選択、入力項目領域６０ｑでは、帳票関連ソース規模、入力項目領域６０ｒでは、処理情報の入力を受け付ける。入力項目領域６０ｏの帳票のミドルウェア情報は、帳票はＬｉｓｔＣｒｅａｔｏｒを利用しているか否かを、「はい」又は「いいえ」で選択可能な形式で入力される。入力項目領域６０ｐは、入力項目領域６０ｏで「いいえ」を選択した場合に出現する入力項目であり、ドロップダウンの選択肢として、「帳票サーバの種類」、及び「その他」が選択可能な形式である。「帳票サーバの種類」としては、後述する移行情報ＤＢ２４ａの「ミドルウェア移行費用テーブル」の移行前の帳票のミドルウェアの種類を用いる。入力項目領域６０ｑの帳票関連ソース規模は、帳票サーバのソースコードの長さを、ＫＳ（キロステップ）単位で表した数値で入力が可能な形式で入力される。入力項目領域６０ｒの処理情報は、帳票処理時間のミリ秒単位の数値、１画面当たりの平均帳票数の数値、及び帳票多重実行数がいくつであるかの数値の入力が可能な形式で入力される。なお、入力項目領域６０ｎの処理情報が、帳票の機能に関する、移行元のシステムでの提供形式の一例である。

図１１に示す入力画面は、入力項目領域６０ａの利用有無でＤＢを選択した場合に表示される入力画面であり、入力項目領域６０ｓ〜６０ｖ、及びボタン７０を含む。

図１１に示すように、入力項目領域６０ｓでは、ＤＢのミドルウェア情報、入力項目領域６０ｔでは、ミドルウェア選択、入力項目領域６０ｕでは、ＤＢソース規模、入力項目領域６０ｖでは、処理情報の入力を受け付ける。入力項目領域６０ｓのＤＢのミドルウェア情報は、ＤＢはＰｏｓｔｇｒｅＳＱＬを利用しているか否かを、「はい」又は「いいえ」で選択可能な形式で入力される。入力項目領域６０ｔは、入力項目領域６０ｓで「いいえ」を選択した場合に出現する入力項目であり、ドロップダウンの選択肢として、「ＤＢサーバの種類」、及び「その他」が選択可能な形式である。「ＤＢサーバの種類」としては、後述する移行情報ＤＢ２４ａの「ミドルウェア移行費用テーブル」の移行前のＤＢのミドルウェアの種類を用いる。入力項目領域６０ｕのＤＢ関連ソース規模は、ＤＢサーバのソースコードの長さを、ＫＳ（キロステップ）単位で表した数値の入力が可能な形式で入力される。入力項目領域６０ｖの処理情報は、１画面当たりの平均ＤＢアクセス数をＭＢ単位で表した数値の入力が可能な形式で入力される。

図１２に示す入力画面は、入力項目領域６０ｗ、及びボタン７０を含む。図１２に示すように、入力項目領域６０ｗでは、移行元環境費用の入力を受け付ける。入力項目領域６０ｗの移行元環境費用は、移行元環境の開発費、及び月平均運用費を万円単位で表した数値で入力が可能な形式で入力される。

以上が受付部２１で受け付ける移行元情報の入力画面における入力項目である。

次に、性能情報ＤＢ２３、移行情報ＤＢ２４ａ、及びカタログ情報ＤＢ２４ｂに格納されている情報について説明する。なお、上記入力項目でいう「機能」が以下の「サービス」に相当する。

取得部２２は、定期的にクラウド環境３０から帳票サービス性能情報、及びサービス間通信性能を取得して、図１３に示す、性能情報ＤＢ２３の帳票サービス性能情報６２ａ、及びサービス間通信性能６２ｂとして格納する。また、取得部２２は、定期的にクラウド環境３０からミドルウェア移行費用、及びクラウドサービス利用時発生費用を取得する。取得した情報を、図１４に示す移行情報ＤＢ２４ａのミドルウェア移行費用６４ａ、及び図１５に示すカタログ情報ＤＢ２４ｂのクラウドサービス利用時発生費用６４ｂとして格納する。

性能情報ＤＢ２３には、図１３に示すように、クラウド環境３０から取得部２２が取得して格納した帳票サービス性能情報６２ａ、及びサービス間通信性能６２ｂが含まれる。帳票サービス性能情報６２ａとしては、クラウド環境３０のリージョン（サーバが設置されているデータセンタの場所）、ＡＰＩの帳票出力時間（ミリ秒単位）、及び多重実行可能数が格納されている。ＡＰＩの帳票出力時間は、クラウド環境３０の実行ログから実測値を取得して得られた平均値が格納される。また、多重実行可能数にはクラウド環境３０の帳票の機能の仕様により定義された上限値が格納される。例えば図１３では、帳票サービス性能情報６２ａの１レコード目に、リージョンが日本ＤＣ１、帳票出力時間が３０、多重実行可能数が５と格納されている。サービス間通信性能６２ｂとしては、各リージョン及び各サービスの組み合わせのレイテンシ（ミリ秒単位）、及びスループット（Ｍｂｐｓ単位）が格納されている。例えば図１３では、サービス間通信性能６２ｂの１レコード目に、リージョンＡが日本ＤＣ１、リージョンＡにあるサービスＡがＩａａＳ、リージョンＢが日本ＤＣ１、リージョンＢにあるサービスＢがＷｅｂ及びＡＰの組み合わせがあり、この組み合わせについてのレイテンシが１ミリ秒、スループットが１０，０００Ｍｂｐｓと格納されている。

なお、性能情報ＤＢ２３では、帳票サービス性能情報６２ａで、ＡＰＩ提供型サービスのみテーブルを定義し、基盤提供型サービスについては、テーブルを定義していない。これは、基盤提供型サービスは、移行前後でＣＰＵ数及びメモリ容量をそろえることで、性能面の影響がほぼ出ないように設計することが可能だからである。また、帳票サービス性能情報６２ａが、帳票の機能に関する、クラウドに構築されるプラットフォームでの提供形式の一例である。サービス間通信性能６２ｂが、クラウドに構築されるプラットフォームの機能の連携状態の一例である。

移行情報ＤＢ２４ａには、図１４に示すように、クラウド環境３０から取得部２２が取得して格納したミドルウェア移行費用６４ａが含まれる。ミドルウェア移行費用６４ａとしては、サービスの種類、移行前のサービスのミドルウェアの種類、サービスのソースコードの規模（ＫＳ（キロステップ）単位）、移行に必要だった工数（人月単位）が格納されている。例えば図１４では、ミドルウェア移行費用６４ａの１レコード目に、サービスがＤＢ、移行前のＤＢのミドルウェアの種類がｍｙｓｑｌ、規模が５ＫＳ、工数が１．５人月と格納されている。

なお、ミドルウェア移行費用６４ａの工数は、過去の移行実績から、ソース規模ごとの移行費用実績の平均値を算出して得た値が格納されている。算出の際、ソースコードのＫＳ（キロステップ）を小数第一位で四捨五入し、１レコードにまとめている。例えば、０．５ＫＳ〜１．４ＫＳまでの実績値の費用平均を規模１ＫＳのレコードとして格納する。

カタログ情報ＤＢ２４ｂには、図１５に示すように、クラウドサービス利用時発生費用６４ｂが含まれる。クラウドサービス利用時発生費用６４ｂとしては、サービスの種類、サービスのＣＰＵのコア数、サービスのメモリ容量（ＧＢ単位）、サポート利用の有無、サービス月額利用料（円単位）、運用工数（人月単位）が格納されている。例えば図１５では、クラウドサービス利用時発生費用６４ｂの１レコード目に、サービスがＩａａＳの仮想マシン提供（例えばＣｅｎｔＯＳ）、ＣＰＵのコア数が４、メモリが１６ＧＢ、サポート利用が有、サービス月額利用料が４５，０００円、運用工数が０．０３人月と格納されている。

なお、クラウドサービス利用時発生費用６４ｂのサービス月額利用料はクラウドサービスとして定義されている利用料の月額を格納する。例えば１月あたりのライセンス料、及びサポート料＋１時間あたりの利用料×２４時間×３０日として計算した利用料である。また、運用工数は、利用中サービスを管理するための工数について、過去の運用項目の実績の平均値を算出したものとする。運用項目としては、ＩａａＳでのＯＳアップデート、バックアップ、及び運用監視や、ＰａａＳでのバックアップ、運用監視などである。

シミュレーション部２５は、受付部２１で受け付けた移行元情報と、性能情報ＤＢ２３の帳票サービス性能情報６２ａ、及びサービス間通信性能６２ｂとに基づいて、移行元のシステムの機能の提供形式と、移行後の機能の提供形式とを特定する。そして、機能の組み合わせのバリエーションごとに、特定した機能の提供形式の違いを比較して、機能の性能の差を計算する。また、シミュレーション部２５は、機能の組み合わせのバリエーションごとに、連携状態の違いに基づく機能の性能の差を計算する。また、シミュレーション部２５は、移行元情報と、移行情報ＤＢ２４ａのミドルウェア移行費用６４ａ、及びカタログ情報ＤＢ２４ｂのクラウドサービス利用時発生費用６４ｂとに基づいて、機能の組み合わせのバリエーションごとにコストを計算する。移行元のシステムでの機能の提供形式は、入力画面から入力された移行元情報から特定される。例えば、図６の入力項目領域６０ｃで入力されたサーバ内機能の例では、サーバ１がＷｅｂ、ＡＰ、バッチ、及び帳票の機能を有し、サーバ２がＤＢの機能を有している。そして、移行元のシステムでの機能の提供形式としては、例えば帳票の機能について、入力項目領域６０ｒで入力された処理情報が特定され、具体的には、帳票処理時間、１画面当たりの平均帳票数、及び帳票多重実行数が特定されることになる。移行後のクラウド環境のプラットフォームでの機能の提供形式としては、例えば帳票の機能について、性能情報ＤＢ２３の帳票サービス性能情報６２ａの帳票出力時間、及び多重実行可能数が特定される。

具体的な計算例について以下に説明する。

図１６に示すように、移行元環境が、Ｗｅｂ及びＡＰサーバ、ＤＢサーバで構成されており、Ｗｅｂ及びＡＰサーバで、Ｗｅｂ、ＡＰ、バッチ、及び帳票の機能が稼動し、ＤＢサーバでＤＢの機能が稼動している。移行後は、Ｗｅｂ、及びＡＰの機能をＩａａＳのサーバで提供し、帳票、バッチ、及びＤＢの機能をＰａａＳのサービスとして提供する構成とする場合を例に説明する。なお、以下の説明では、図１６に示した情報が入力画面の各入力項目から入力された前提で説明する。機能の連携情報としては、Ｗｅｂ、及びＡＰが帳票、及びＤＢと連携しており、バッチがＤＢと連携している想定である。また、Ｗｅｂ、及びＡＰは一体のものとして扱う。

まず、帳票の機能の性能の差の計算の例について説明する。図１６に示すように、移行元環境では、逐次実行時の帳票処理時間は１００ミリ秒／帳票であり、１０多重で実行が可能である。そのため、並列実行時の１帳票当たりの処理時間は、１００／１０＝１０ミリ秒である。一方、移行後の帳票の性能は、上記図１３の性能情報ＤＢ２３の帳票サービス性能情報６２ａを参照すると、リージョンが日本ＤＣ１のＡＰＩの帳票出力時間は１２０ミリ秒／帳票であり、５多重実行が可能である。そのため、並列実行時の１帳票当たりの処理時間は、１２０／５＝２４ミリ秒である。よって、帳票出力時間の性能の差のオーバーヘッド（ＡＰＩ利用によるオーバーヘッド）は１４ミリ秒／帳票となる。

このように、移行元のシステムの機能に帳票が含まれる場合には、移行後の機能に帳票を含む想定とする。そして、帳票の処理時間などの提供形式を特定し、移行元情報の入力項目領域６０ｎで入力された処理情報と、帳票サービス性能情報６２ａとを比較して機能の性能の差を計算する。

次に、ＤＢの機能の性能の差の計算の例について説明する。図１６に示すように、移行元環境では、画面表示に５ＭＢのＤＢ読み込みが発生し、そのスループットが３Ｇｂｐｓ(＝(３×１０００/８)ＭＢ/ｓ)である。そのため、Ｗｅｂ１画面の表示に発生する遅延時間は、５／(３×１０００/８)＝０．０１３(秒)と計算でき、ミリ秒換算では１３ミリ秒である。一方、移行後のＤＢでは、上記図１３の性能情報ＤＢ２３のサービス間通信性能情報６２ｂを参照すると、通信元及び通信先リージョンが日本ＤＣ１であり、通信元サービスがＩａａＳ、通信先サービスがＤＢである場合のスループットは１，０００Ｍｂｐｓである。そのため、Ｗｅｂ１画面の表示に発生する遅延時間は、５／(１×１０００/８)＝０．０３９(秒)と計算でき、ミリ秒換算では３９ミリ秒である。よって、ＤＢのＷｅｂの１画面の表示に発生する遅延時間の性能の差のオーバーヘッド（サービス間通信によるオーバーヘッド）は２６ミリ秒となる。

次に、バッチの機能の性能の差の計算の例について説明する。図１６に示すように、移行元環境では、バッチ処理中に平均して５ＧＢのデータ転送が発生したと仮定すると、そのスループットが３Ｇｂｐｓ(＝(３／８)ＧＢ／ｓ)である。そのため、ＤＢとの通信によるバッチ処理時間の増加は、５／(３／８)＝１３(秒)と計算できる。一方、移行後のＤＢでは、上記図１３の性能情報ＤＢ２３のサービス間通信性能情報６２ｂを参照すると、通信元及び通信先リージョンが日本ＤＣ１であり、通信元サービスがバッチ、通信先サービスがＤＢである場合のスループットは８００Ｍｂｐｓである。そのため、ＤＢとの通信によるバッチ処理時間の増加は、５／(０．８／８)＝５０(秒)と計算できる。よって、ＤＢとの通信によるバッチ処理時間の増加における性能の差のオーバーヘッドは３７秒となる。図１７に示すように、１画面あたりのＷｅｂ画面表示の遅延は、ＡＰＩ利用によるオーバーヘッド、及びサービス間通信によるオーバーヘッドにより計算できる。図１７の場合の１画面あたりのＷｅｂ画面表示の遅延は、１４ミリ秒×１０（１画面あたりの平均帳票数）＋２６ミリ秒で、合計１６６ミリ秒となる。また、これに加えてバッチ処理時間増加が３７秒掛かる。

このように、複数の機能がある場合には、移行元情報の入力項目領域６０ｄで入力されたサーバ間のネットワーク性能のスループットと、移行後の連携状態であるサービス間通信性能情報６２ｂのスループットとを比較して、機能の性能の差を計算する。

次に、コストの計算の例について説明する。シミュレーションの際は、改修費については、機能のソースコードの規模が一致する上記図１４の移行情報ＤＢ２４ａのミドルウェア移行費用６４ａのレコードを参照する。また、運用費については、ＣＰＵのコア数、及びメモリ容量が一致する図１５のカタログ情報ＤＢ２４ｂのクラウドサービス利用時発生費用６４ｂのレコードを参照する。なお、改修費について、機能のソースコードの規模が一致するレコードがない場合には、入力された規模に対して、規模の近い前後の２つのレコードの工数を参照して工数を予測して用いればよい。

図１６に示すように、移行元環境では、ｍｙｓｑｌのソースコードの規模は５ＫＳである。また、月平均運用費は２３万円である。一方、上記図１４の移行情報ＤＢ２４ａのミドルウェア移行費用６４ａの規模が一致するレコードを参照すると、移行前のＤＢがｍｙｓｑｌで規模が５ＫＳの場合の改修に必要な工数は１．５人月である。また、ＤＢ以外の機能のうちＷｅｂ、及びＡＰについては、ＩａａＳへの単純移行であるため改修は不要であり、バッチ、及び帳票についてはＰａａＳへの移行だがミドルウェアに変更がないため改修は不要であると想定する。ここで１人月は単金１００万円と仮定すると、改修費は１５０万円となる。また、図１５のカタログ情報ＤＢ２４ｂのクラウドサービス利用時発生費用６４ｂのＣＰＵのコア数、及びメモリ容量が一致するレコードを参照すると、１月あたりの運用費（月額費用＋運用工数）は、ＩａａＳの仮想マシン提供で４５，０００円＋０．０３（人月）×１０，０００円、帳票で２５，０００円＋０．００５（人月）×１０，０００円、バッチで２５，０００＋０．００５（人月）×１０，０００円、ＤＢで３０，０００円＋０．００５（人月）×１０，０００円となり、１２．５万円＋４．５万円＝１７万円となる。図１８には費用面のコストとして、改修費、運用費、及び累積費用逆転時期が挙げられる。移行後にコストが逆転する累積費用逆転時期は、移行前の月平均運用費が２３万円であるため、差額の６万円で改修費１５０万円を割ると２５ヶ月＝２年１月後と計算される。

また、移行前の構成が上記の計算例と同様で、移行後の機能の組み合わせのバリエーションが異なる場合について説明する。移行後は、Ｗｅｂ、ＡＰ、及びバッチの機能をＩａａＳのサーバで提供し、帳票、ＤＢの機能をＰａａＳのサービスとして提供する構成とする場合、次の部分の計算が上記の計算例と異なる。すなわち、通信元サービスがＩａａＳ、通信先サービスがＤＢとなる。この場合、ＤＢとの通信によるバッチ処理時間の増加は、５／(１／８)＝４０(秒)と計算できるから、ＤＢとの通信によるバッチ処理時間の増加における性能の差のオーバーヘッドは２７秒となる。また、コストについては、運用費のバッチの機能を、仮想マシン提供の項目で４５，０００円＋０．０３（人月）×１０，０００円と計算すればよい。

提供部２６は、シミュレーション部２５で計算された、機能の組み合わせのバリエーションごとに算出された性能の差、及び機能の組み合わせのバリエーションごとに算出されたコストをマージし、クライアント端末１０に提供する。

クライアント端末１０へ提供するシミュレーション結果の画面イメージの一例を図１９示す。図１９には、全ての機能にＰａａＳを適用した場合６６ａ、帳票及びＤＢの機能にＰａａＳを適用した場合６６ｂ、及びＤＢの機能のみにＰａａＳを適用した場合６６ｃの３つの機能の組み合わせのバリエーションの一例である。３つの機能の組み合わせのバリエーションのそれぞれについて、計算された機能の性能の差、及び計算されたコストを表示している。図１９では、機能の組み合わせのバリエーションごとに、１画面あたりのＷｅｂ画面表示の遅延、バッチ処理時間増加、及び費用面のコストが表示されている。また、帳票及びＤＢの機能にＰａａＳを適用した場合６６ｂ、及びＤＢの機能のみにＰａａＳを適用した場合６６ｃには、ＰａａＳ以外で稼動させる機能を識別可能なアイコン７２を表示させる。帳票及びＤＢの機能にＰａａＳを適用した場合６６ｂでは、Ｗｅｂ及びＡＰサーバにアイコン７２が付されており、Ｗｅｂ及びＡＰサーバにあるアプリ、及びバッチの機能はＰａａＳ以外の、例えばＩａａＳで稼動することがわかる。また、ＤＢの機能のみにＰａａＳを適用した場合６６ｃでは、Ｗｅｂ及びＡＰサーバにアイコン７２が付されており、Ｗｅｂ及びＡＰサーバにあるアプリ、バッチ、及び帳票の機能はＰａａＳ以外の、例えばＩａａＳで稼動することがわかる。また、機能の組み合わせのバリエーションについては、機能の数がｎであればｎ^ｎ通り考えられるため、例えば、上記シミュレーション部２５での計算例のように、帳票、バッチ、及びＤＢの機能にＰａａＳを適用した場合を含めてもよい。

プラットフォーム移行支援装置２０は、例えば図２０に示すコンピュータ４０で実現することができる。コンピュータ４０は、Central Processing Unit（ＣＰＵ）４１と、一時記憶領域としてのメモリ４２と、不揮発性の記憶部４３とを備える。また、コンピュータ４０は、入出力装置４４と、記憶媒体４９に対するデータの読み込み及び書き込みを制御するRead/Write（Ｒ／Ｗ）部４５と、インターネット等のネットワークに接続される通信インターフェース（Ｉ／Ｆ）４６とを備える。ＣＰＵ４１、メモリ４２、記憶部４３、入出力装置４４、Ｒ／Ｗ部４５、及び通信Ｉ／Ｆ４６は、バス４７を介して互いに接続される。

記憶部４３は、Hard Disk Drive（ＨＤＤ）、Solid State Drive（ＳＳＤ）、フラッシュメモリ等によって実現できる。記憶媒体としての記憶部４３には、コンピュータ４０をプラットフォーム移行支援装置２０として機能させるための移行支援プログラム５０が記憶される。移行支援プログラム５０は、受付プロセス５２と、取得プロセス５４と、計算プロセス５６と、提供プロセス５８とを有する。また、記憶部４３は、性能情報ＤＢ２３、移行情報ＤＢ２４ａ、及びカタログ情報ＤＢ２４ｂが保持される情報記憶領域５９を有する。

ＣＰＵ４１は、移行支援プログラム５０を記憶部４３から読み出してメモリ４２に展開し、移行支援プログラム５０が有するプロセスを順次実行する。ＣＰＵ４１は、受付プロセス５２を実行することで、図４に示す受付部２１として動作する。また、ＣＰＵ４１は、取得プロセス５４を実行することで、図４に示す取得部２２として動作する。また、ＣＰＵ４１は、計算プロセス５６を実行することで、図４に示すシミュレーション部２５として動作する。また、ＣＰＵ４１は、提供プロセス５８を実行することで、図４に示す提供部２６として動作する。また、ＣＰＵ４１は、情報記憶領域７０から情報を読み出して、性能情報ＤＢ２３、移行情報ＤＢ２４ａ、及びカタログ情報ＤＢ２４ｂの内容をメモリ４２に展開する。これにより、移行支援プログラム５０を実行したコンピュータ４０が、プラットフォーム移行支援装置２０として機能することになる。なお、プログラムを実行するＣＰＵ４１はハードウェアである。

なお、移行支援プログラム５０により実現される機能は、例えば半導体集積回路、より詳しくはApplication Specific Integrated Circuit（ＡＳＩＣ）等で実現することも可能である。

次に、本実施形態に係るプラットフォーム移行支援システム１００の作用について説明する。図２１のフローチャートを参照して、処理部間での情報のやり取りについて説明する。

まず、ステップＳ３０では、取得部２２が、定期取得のタイミングかを判定し、定期取得のタイミングであれば、ステップＳ３１に移行し、定期取得のタイミングでなければステップＳ３２に移行する。

ステップＳ３１では、取得部２２が、クラウド環境３０から帳票サービス性能情報、及びサービス間通信性能を取得して、図１３に示す、性能情報ＤＢ２３の帳票サービス性能情報６２ａ、及びサービス間通信性能６２ｂとして格納する。また、取得部２２が、クラウド環境３０からミドルウェア移行費用、及びクラウドサービス利用時発生費用を取得する。取得した情報を、図１４に示す移行情報ＤＢ２４ａのミドルウェア移行費用６４ａ、及び図１５に示すカタログ情報ＤＢ２４ｂのクラウドサービス利用時発生費用６４ｂとして格納する。

ステップＳ３２では、移行元情報をクライアント端末１０から受け付けたかを判定し、受け付けた場合には、ステップＳ３３に移行し、受け付けていない場合には、ステップＳ３０に戻って処理を繰り返す。

ステップＳ３３では、シミュレーション部２５が、ステップＳ３２で受け付けた移行元情報と、性能情報ＤＢ２３の帳票サービス性能情報６２ａ、及びサービス間通信性能６２ｂとに基づいて、移行元のシステムの機能の提供形式を特定する。同様に、移行後の機能の提供形式を特定する。

ステップＳ３４では、シミュレーション部２５が、ステップＳ３３で特定された機能の提供形式、及び機能の連携状態の違いに基づいて、機能の組み合わせのバリエーションごとに、機能の性能の差を計算する。

ステップＳ３５では、シミュレーション部２５が、機能の組み合わせのバリエーションごとに、コストを計算する。

ステップＳ３６では、提供部２６が、ステップＳ３４で機能の組み合わせのバリエーションごとに計算された機能の性能の差と、ステップＳ３４で機能の組み合わせのバリエーションごとに計算されたコストとをマージする。マージしたシミュレーション結果に、ＰａａＳ以外で稼動させる機能を識別可能なアイコン７２を表示させて、クライアント端末１０に提供する。

以上説明したように、本実施形態に係るプラットフォーム移行支援システムによれば、移行元のシステムの移行元情報を受け付け、機能の提供形式を特定する。機能の組み合わせのバリエーションごとに、機能の性能の差を計算し、機能の組み合わせのバリエーションごとに、コストを計算し、クライアント端末１０に提供する。このため、クラウド環境のプラットフォームへの移行を支援することができる。

また、本実施形態に係るプラットフォーム移行支援システムによれば、提供部２６が、シミュレーション結果に、ＰａａＳ以外で稼動させる機能を識別可能なアイコン７２を表示させて、クライアント端末１０に提供する。このため、利用者に視覚的にわかりやすい表示によって、クラウド環境のプラットフォームへの移行を支援することができる。

なお、上述した実施形態では、ＡＰＩ利用によるオーバーヘッドと、サービス間通信によるオーバーヘッドとをいずれも計算して提供する場合を例に説明したが、これに限定されるものではない。例えば、ＡＰＩ利用によるオーバーヘッドと、サービス間通信によるオーバーヘッドとのいずれかを計算して提供するようにしてもよい。

また、上述した実施形態では、機能の性能の差、及びコストをいずれも計算してシミュレーション結果として提供する場合を例に説明したが、これに限定されるものではなく、機能の性能の差、及びコストのいずれか一方を提供するようにしてもよい。

また、上述した実施形態では、機能のうち、ＡＰＩ提供型サービスの帳票に関するＡＰＩ利用によるオーバーヘッドは計算している。一方、基盤提供型サービスのＷｅｂ、ＡＰ、バッチ、及びＤＢについてはオーバーヘッドを計算していないが、これに限定されるものではない。例えば、性能情報ＤＢ２３に、Ｗｅｂ、ＡＰ、バッチ、及びＤＢのそれぞれの性能情報テーブルを設け、基盤提供型サービスについても、より詳細なオーバーヘッドを計算するようにしてもよい。

また、上述した実施形態において扱う機能は、基盤提供型サービスではＷｅｂ、ＡＰ、バッチ、及びＤＢ、ＡＰＩ提供型サービスでは帳票であるが、これに限定されるものではなく、他の機能を対象としてもよい。例えば、ＡＰＩ提供型サービスであれば、地図検索や、音声操作といった機能を対象としてもよい。また、例えば、基盤提供型サービスであれば、コンテナサービスのようなコンテナ形式でアプリが実行可能な機能を対象としてもよい。

以上の実施形態に関し、更に以下の付記を開示する。

（付記１）
クラウドに構築されるプラットフォームにおいて提供される機能のうち、移行元のシステムで利用している複数の機能を特定する入力を受け付けるとともに、前記複数の機能間における連携状態の入力、及び前記移行元のシステムでの前記複数の提供形式の入力を受け付け、
前記プラットフォームにおける各機能の提供形式を記憶する記憶部を参照して、入力を受け付けた前記複数の機能の前記プラットフォームでの提供形式を特定し、
前記移行元のシステムでの前記機能の性能と前記クラウドに構築される前記プラットフォームにおける機能の連携状態の違いに基づく前記機能の性能の差、及び前記機能の前記移行元のシステムでの提供形式と前記クラウドに構築される前記プラットフォームでの提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力する、
処理をコンピュータに実行させることを特徴とする評価処理プログラム。

（付記２）
前記移行元のシステムのコストの入力を更に受け付け、前記プラットフォームにおける各機能のコストを記憶する記憶部を参照して、前記移行元のシステムでのコストと前記クラウドに構築される前記プラットフォームでのコストとの違いに基づくコストを更に出力する付記１に記載の評価処理プログラム。
（付記３）
前記移行元のシステムで利用しているミドルウェア、及び前記ミドルウェアで利用しているソースコードの長さを特定する入力を更に受け付け、前記プラットフォームにおけるミドルウェアのコストを記憶する記憶部を参照して、前記移行元のシステムで利用しているミドルウェアと、前記クラウドに構築される前記プラットフォームで利用されるミドルウェアとが異なる場合に、前記ソースコードの改修に必要なコストを更に出力する付記１又は付記２に記載の評価処理プログラム。

（付記４）
入力を受け付けた前記機能が複数ある場合には、前記移行元のシステムで利用している複数の機能のうち、前記クラウドに構築される前記プラットフォームに移行する機能の組み合わせのバリエーションごとに、前記機能の連携状態の違いに基づく前記移行元のシステムでの前記機能の性能と前記クラウドに構築される前記プラットフォームでの前記機能の性能の差、及び前記機能の前記移行元のシステムでの提供形式と前記クラウドに構築される前記プラットフォームでの提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力する付記１〜付記３のいずれかに記載の評価処理プログラム。

（付記５）
前記移行元のシステムで利用している機能のうちの一部の機能を、前記クラウドに構築される前記プラットフォームのうちのＰａａＳ（Platform as a Service）に移行するものとした場合における、前記機能の連携状態の違いに基づく前記機能の性能の差、及び前記提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力するときに、前記機能の性能の差と共に、前記ＰａａＳに移行する機能、及び前記ＰａａＳ以外で稼動させる機能を識別可能に表示して出力する付記１〜付記３のいずれかに記載の評価処理プログラム。

（付記６）
クラウドに構築されるプラットフォームにおいて提供される機能のうち、移行元のシステムで利用している複数の機能を特定する入力を受け付けるとともに、前記複数の機能間における連携状態の入力、及び前記移行元のシステムでの前記複数の提供形式の入力を受け付ける受付部と、
前記プラットフォームにおける各機能の提供形式を記憶する記憶部を参照して、入力を受け付けた前記複数の機能の前記プラットフォームでの提供形式を特定するシミュレーション部と、
前記移行元のシステムでの前記機能の性能と前記クラウドに構築される前記プラットフォームにおける機能の連携状態の違いに基づく前記機能の性能の差、及び前記機能の前記移行元のシステムでの提供形式と前記クラウドに構築される前記プラットフォームでの提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力する提供部と、
を含む評価処理装置。

（付記７）
前記受付部は、前記移行元のシステムのコストの入力を更に受け付け、前記シミュレーション部は、前記プラットフォームにおける各機能のコストを記憶する記憶部を参照して、前記提供部は、前記移行元のシステムでのコストと前記クラウドに構築される前記プラットフォームでのコストとの違いに基づくコストを更に出力する付記６に記載の評価処理装置。

（付記８）
前記受付部は、前記移行元のシステムで利用しているミドルウェア、及び前記ミドルウェアで利用しているソースコードの長さを特定する入力を更に受け付け、前記シミュレーション部は、前記プラットフォームにおけるミドルウェアのコストを記憶する記憶部を参照して、前記提供部は、前記移行元のシステムで利用しているミドルウェアと、前記クラウドに構築される前記プラットフォームで利用されるミドルウェアとが異なる場合に、前記ソースコードの改修に必要なコストを更に出力する付記６又は付記７に記載の評価処理装置。

（付記９）
前記提供部は、入力を受け付けた前記機能が複数ある場合には、前記移行元のシステムで利用している複数の機能のうち、前記クラウドに構築される前記プラットフォームに移行する機能の組み合わせのバリエーションごとに、前記機能の連携状態の違いに基づく前記移行元のシステムでの前記機能の性能と前記クラウドに構築される前記プラットフォームでの前記機能の性能の差、及び前記機能の前記移行元のシステムでの提供形式と前記クラウドに構築される前記プラットフォームでの提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力する付記６〜付記８のいずれかに記載の評価処理装置。

（付記１０）
前記提供部は、前記移行元のシステムで利用している機能のうちの一部の機能を、前記クラウドに構築される前記プラットフォームのうちのＰａａＳ（Platform as a Service）に移行するものとした場合における、前記機能の連携状態の違いに基づく前記機能の性能の差、及び前記提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力するときに、前記機能の性能の差と共に、前記ＰａａＳに移行する機能、及び前記ＰａａＳ以外で稼動させる機能を識別可能に表示して出力する付記６〜付記９のいずれかに記載の評価処理装置。

（付記１１）
クラウドに構築されるプラットフォームにおいて提供される機能のうち、移行元のシステムで利用している複数の機能を特定する入力を受け付けるとともに、前記複数の機能間における連携状態の入力、及び前記移行元のシステムでの前記複数の提供形式の入力を受け付け、
前記プラットフォームにおける各機能の提供形式を記憶する記憶部を参照して、入力を受け付けた前記複数の機能の前記プラットフォームでの提供形式を特定し、
前記移行元のシステムでの前記機能の性能と前記クラウドに構築される前記プラットフォームにおける機能の連携状態の違いに基づく前記機能の性能の差、及び前記機能の前記移行元のシステムでの提供形式と前記クラウドに構築される前記プラットフォームでの提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力する、
処理をコンピュータに実行させることを特徴とする評価処理方法。

（付記１２）
前記移行元のシステムのコストの入力を更に受け付け、前記プラットフォームにおける各機能のコストを記憶する記憶部を参照して、前記移行元のシステムでのコストと前記クラウドに構築される前記プラットフォームでのコストとの違いに基づくコストを更に出力する付記１１に記載の評価処理方法。

（付記１３）
前記移行元のシステムで利用しているミドルウェア、及び前記ミドルウェアで利用しているソースコードの長さを特定する入力を更に受け付け、前記プラットフォームにおけるミドルウェアのコストを記憶する記憶部を参照して、前記移行元のシステムで利用しているミドルウェアと、前記クラウドに構築される前記プラットフォームで利用されるミドルウェアとが異なる場合に、前記ソースコードの改修に必要なコストを更に出力する付記１１又は付記１２に記載の評価処理方法。

（付記１４）
入力を受け付けた前記機能が複数ある場合には、前記移行元のシステムで利用している複数の機能のうち、前記クラウドに構築される前記プラットフォームに移行する機能の組み合わせのバリエーションごとに、前記機能の連携状態の違いに基づく前記移行元のシステムでの前記機能の性能と前記クラウドに構築される前記プラットフォームでの前記機能の性能の差、及び前記機能の前記移行元のシステムでの提供形式と前記クラウドに構築される前記プラットフォームでの提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力する付記１１〜付記１３のいずれかに記載の評価処理方法。

（付記１５）
前記移行元のシステムで利用している機能のうちの一部の機能を、前記クラウドに構築される前記プラットフォームのうちのＰａａＳ（Platform as a Service）に移行するものとした場合における、前記機能の連携状態の違いに基づく前記機能の性能の差、及び前記提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力するときに、前記機能の性能の差と共に、前記ＰａａＳに移行する機能、及び前記ＰａａＳ以外で稼動させる機能を識別可能に表示して出力する付記１１〜付記１４のいずれかに記載の評価処理方法。

１０ クライアント端末
１５ ネットワーク
２０ プラットフォーム移行支援装置
２１ 受付部
２２ 取得部
２３ 性能情報ＤＢ
２４ａ 移行情報ＤＢ
２４ｂ カタログ情報ＤＢ
２５ シミュレーション部
２６ 提供部
３０ クラウド環境
４０ コンピュータ
４１ ＣＰＵ
４２ メモリ
４３ 記憶部
４９ 記憶媒体
５０ 移行支援プログラム
１００ プラットフォーム移行支援システム

Claims (7)

1. クラウドに構築されるプラットフォームにおいて提供される機能のうち、移行元のシステムで利用している複数の機能を特定する入力を受け付けるとともに、前記複数の機能間における連携状態の入力、及び前記移行元のシステムでの前記複数の提供形式の入力を受け付け、
   前記プラットフォームにおける各機能の提供形式を記憶する記憶部を参照して、入力を受け付けた前記複数の機能の前記プラットフォームでの提供形式を特定し、
   前記移行元のシステムでの前記機能の性能と前記クラウドに構築される前記プラットフォームにおける機能の連携状態の違いに基づく前記機能の性能の差、及び前記機能の前記移行元のシステムでの提供形式と前記クラウドに構築される前記プラットフォームでの提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力する、
   処理をコンピュータに実行させることを特徴とする評価処理プログラム。
2. 前記移行元のシステムのコストの入力を更に受け付け、前記プラットフォームにおける各機能のコストを記憶する記憶部を参照して、前記移行元のシステムでのコストと前記クラウドに構築される前記プラットフォームでのコストとの違いに基づくコストを更に出力する請求項１に記載の評価処理プログラム。
3. 前記移行元のシステムで利用しているミドルウェア、及び前記ミドルウェアで利用しているソースコードの長さを特定する入力を更に受け付け、前記プラットフォームにおけるミドルウェアのコストを記憶する記憶部を参照して、前記移行元のシステムで利用しているミドルウェアと、前記クラウドに構築される前記プラットフォームで利用されるミドルウェアとが異なる場合に、前記ソースコードの改修に必要なコストを更に出力する請求項１又は請求項２に記載の評価処理プログラム。
4. 入力を受け付けた前記機能が複数ある場合には、前記移行元のシステムで利用している複数の機能のうち、前記クラウドに構築される前記プラットフォームに移行する機能の組み合わせのバリエーションごとに、前記機能の連携状態の違いに基づく前記移行元のシステムでの前記機能の性能と前記クラウドに構築される前記プラットフォームでの前記機能の性能の差、及び前記機能の前記移行元のシステムでの提供形式と前記クラウドに構築される前記プラットフォームでの提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力する請求項１〜請求項３のいずれか１項に記載の評価処理プログラム。
5. 前記移行元のシステムで利用している機能のうちの一部の機能を、前記クラウドに構築される前記プラットフォームのうちのＰａａＳ（Platform as a Service）に移行するものとした場合における、前記機能の連携状態の違いに基づく前記機能の性能の差、及び前記提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力するときに、前記機能の性能の差と共に、前記ＰａａＳに移行する機能、及び前記ＰａａＳ以外で稼動させる機能を識別可能に表示して出力する請求項１〜請求項４のいずれか１項に記載の評価処理プログラム。
6. クラウドに構築されるプラットフォームにおいて提供される機能のうち、移行元のシステムで利用している複数の機能を特定する入力を受け付けるとともに、前記複数の機能間における連携状態の入力、及び前記移行元のシステムでの前記複数の提供形式の入力を受け付ける受付部と、
   前記プラットフォームにおける各機能の提供形式を記憶する記憶部を参照して、入力を受け付けた前記複数の機能の前記プラットフォームでの提供形式を特定するシミュレーション部と、
   前記移行元のシステムでの前記機能の性能と前記クラウドに構築される前記プラットフォームにおける機能の連携状態の違いに基づく前記機能の性能の差、及び前記機能の前記移行元のシステムでの提供形式と前記クラウドに構築される前記プラットフォームでの提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力する提供部と、
   を含む評価処理装置。
7. クラウドに構築されるプラットフォームにおいて提供される機能のうち、移行元のシステムで利用している複数の機能を特定する入力を受け付けるとともに、前記複数の機能間における連携状態の入力、及び前記移行元のシステムでの前記複数の提供形式の入力を受け付け、
   前記プラットフォームにおける各機能の提供形式を記憶する記憶部を参照して、入力を受け付けた前記複数の機能の前記プラットフォームでの提供形式を特定し、
   前記移行元のシステムでの前記機能の性能と前記クラウドに構築される前記プラットフォームにおける機能の連携状態の違いに基づく前記機能の性能の差、及び前記機能の前記移行元のシステムでの提供形式と前記クラウドに構築される前記プラットフォームでの提供形式の違いに基づく前記機能の性能の差の少なくとも一方を出力する、
   ことを含む処理をコンピュータが実行することを特徴とする評価処理方法。