JP6580535B2 - 開発支援システム及び方法 - Google Patents

Description

本発明は、システムの開発を支援する技術に関する。

企業が社内で利用する情報システム（「企業情報システム」という）は、社内外の環境の変化に伴い、新たな機能が必要となったり、過去の機能が不要となったりする。企業情報システムを再開発する際に、不要な機能を除外することは、企業情報システムの肥大化及び複雑化を抑止するために必要である。従来、システムエンジニアは、自分の経験やスキルに基づき、企業情報システムの利用者にヒアリングを行って現行の企業情報システムの利用実態を捉えることで、企業情報システムの不要と考えられる機能を特定している。また、非特許文献１には、企業情報システムの稼動ログにおいて利用実績のあるプログラム一覧と、設計仕様に含まれるプログラム一覧とを対比し、未稼動なプログラムを特定することが開示されている。

富士通株式会社、"アプリケーション＆ポートフォリオマネジメント資産分析サービス"、インターネット(URL:http://www.fujitsu.com/jp/services/application-services/application-management-outsourcing/apm/services/assetanalyse/service/index.html)

上述のとおり、システムエンジニアが企業情報システムの機能の要否を適切に判断することは難しい上、その判断のために要する作業負荷も高い。そこで、本発明の目的は、情報システムの機能の要否の判断を支援するシステム及び方法を提供することにある。

一実施形態に係る、情報システムが有する機能の要否判断を支援する開発支援システムは、
情報システムが有する各機能の利用実態に関する情報を含む利用実態情報に基づいて、各機能の利用実態の特徴を導出する機能特徴導出手段と、
情報システムが有する各機能に対する過去の要否の分析結果に関する情報を含む過去要否分析情報から、特徴導出手段によって導出された利用実態の特徴と適合する利用実態の特徴を有する機能と、当該機能に対する過去の要否の分析結果と、を抽出する過去要否抽出手段と、
過去要否抽出手段によって抽出された機能及び当該機能に対する過去の要否の分析結果を表示する表示手段と、を有する。

本発明によれば、情報システムの機能の要否を容易に判断することができる。

開発支援システムの構成例。 プログラム稼動情報テーブルの構成例。 プログラムと機能の関係テーブル、及び、端末と拠点の関係テーブルの構成例。 利用実績集計部の処理例を示すフローチャート。 機能利用実態の構成例。 分析事例の構成例。 第１の実施形態に係る機能要否判断部の処理例を示すフローチャート。 第１の実施形態に係る出力画面例。 第２の実施形態に係る機能要否判断部の処理例を示すフローチャート。 第２の実施形態に係る出力画面例。

以下、実施形態を説明する。以下の説明では、「ａａａテーブル」の表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ａａａテーブル」を「ａａａ情報」と呼ぶことができる。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び通信インターフェイスデバイスのうちの少なくとも１つを用いながら行うため、処理の主語が、プロセッサ、そのプロセッサを有する装置とされてもよい。プロセッサが行う処理の一部又は全部が、ハードウェア回路で行われてもよい。コンピュータプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア（例えば可搬型の記憶メディア）であってもよい。

（第１の実施形態）

図１は、第１の実施形態に係るシステム構成例を示す。

開発支援システム（１００）は、機能として、利用実績集計部（１１０）、及び、機能要否判断部（１３０）を有する。開発支援システム（１００）は、ＣＰＵ及びメモリを備え、ＣＰＵがメモリ（例えばＤＲＡＭ）に格納されたコンピュータプログラムを実行することにより、これらの機能を実現してよい。

開発支援システム（１００）は、データとして、機能利用実態（１２０）、及び、分析事例（１４０）を有する。これらのデータは、開発支援システム（１００）が備えるメモリ又は記憶デバイス（例えばＨＤＤ又はＳＳＤ）に格納されてよい。

利用実績集計部（１１０）は、入力されたログ（２００）及び辞書（３００）を集計し、機能利用実態（１２０）を生成する。機能利用実態（１２０）は、企業情報システムの機能の利用状況を特徴付ける１以上の属性で構成される情報である。

機能要否判断部（１３０）は、分析事例（１４０）に基づき、機能利用実態（１２０）と類する利用実態情報を有する機能の要否を判断する。

分析事例（１４０）は、過去に実施された、企業情報システムの機能に対する要否分析の事例を含む情報である。分析事例（１４０）は、機能の利用実態情報、機能に対する要否の判断の結果及び理由を含んでよい。

開発支援システム（１００）は、処理結果をユーザに表示するためのインタフェース（１５０）を有して良い。インタフェース（１５０）は、利用要否判断部（１３０）における要否判断の結果及び理由などを表示する。インタフェース（１５０）の例は、ディスプレイモニタである。

ログ（２００）は、企業情報システムの稼働に関する情報（「システム稼働情報」という）を含む。システム稼働情報には、例えば、企業情報システムの基盤製品が出力する稼動情報、アプリケーションプログラムが出力する稼動情報などがある。システム稼動情報は、企業情報システムの開発及び運用に活用したり、不具合発生時の原因究明に活用したりするために、常時出力されていることが多い。ログ（２００）には、機能の要否判断に必要な期間（例えば１年間）のシステム稼動情報が含まれてよい。

辞書（３００）は、ログ（２００）に含まれるシステム稼動情報を補足するための情報である。辞書（３００）には、例えば、システム稼動情報に含まれるプログラムＩＤに対応するプログラム名称などが含まれる。補足情報は、企業情報システムの設計仕様などから生成されてよい。

図２は、プログラム稼動情報テーブル（２１０）の例を示す。

プログラム稼働情報テーブル（２１０）の内容は、ログ（２００）に含まれてよい。プログラム稼動情報テーブル（２１０）は、データ項目として、日付（２１１）、プログラムＩＤ（２１２）、端末ＩＤ（２１３）、利用数（２１４）を有して良い。

図２のプログラム稼働情報テーブル（２１０）の１行目のレコードは、日付（２１１）「２０１６年６月２９日」に、端末ＩＤ（２１３）「Ｔ＿１１」の端末から、プログラムＩＤ（２１２）「Ｐ＿α」のプログラムが、利用数（２１４）「３回」利用されたことを示す。

図３は、プログラムと機能の関係テーブル（３１０）及び端末と拠点の関係テーブル（３２０）の例を示す。

プログラムと機能の関係テーブル（３１０）及び端末と拠点の関係テーブル（３２０）の内容は、辞書（３００）に含まれてよい。プログラムと機能の関係テーブル（３１０）は、データ項目として、機能ＩＤ、機能名称、プログラムＩＤ、プログラム名称を有して良い。

図３のプログラムと機能の関係テーブル（３１０）の１行目及び２行目のレコードは、機能ＩＤ「Ｆ＿Ω」（機能名称「機能Ω」）は、プログラムＩＤ「Ｐ＿α」（プログラム名称「プログラムα」）及びプログラムＩＤ「Ｐ＿β」（プログラム名称「プログラムβ」）から構成されていることを示す。

端末と拠点の関係テーブル（３２０）は、データ項目として、端末ＩＤ、設置拠点を有して良い。

図３の端末と拠点の関係テーブル（３２０）の１行目のレコードは、端末ＩＤ「Ｔ＿１１」の端末は、設置拠点「東京事務所」に設置されていることを示す。

図４は、利用実績集計部（１１０）の処理の一例を示すフローチャートである。

利用実績集計部（１１０）は、開発支援システム（１００）を操作するユーザから、インターフェース（１５０）を経由して分析開始のトリガを受信すると、次の処理を開始する。

利用実績集計部（１１０）は、プログラムと機能の関係テーブル（３１０）に含まれる機能ＩＤ毎に、機能が利用された数を集計する（ステップ１１１）。

機能が利用された数の集計結果は、機能を構成するプログラムの利用数の総和であってよい。図２のプログラム稼動情報テーブル（２１０）と、図３のプログラムと機能の関係テーブル（３１０）とを参照し、機能名称「機能Ω」を例に説明する。「機能Ω」は、プログラムと機能の関係テーブル（３１０）から、プログラムα（プログラムＩＤはＰ＿α）とプログラムβ（プログラムＩＤはＰ＿β）とによって構成されていることがわかる。そして、プログラム稼動情報テーブル（２１０）におけるプログラムＩＤ「Ｐ＿α」及び「Ｐ＿β」の（１、２、４、５行目）の利用数（２１４）を加算すると、「２５」となる。したがって、「機能Ω」の利用数は「２５」であることがわかる。なお、この集計方法はあくまでも一例であり、別の集計方法を採用してもよい。

利用実績集計部（１１０）は、ステップ１１１で集計した各機能が利用された数をスコアリングし、機能利用実態（１２０）に出力する（ステップ１１２）。

例えば、利用実績集計部（１１０）は、閾値θを１つ定め、機能が利用された数が、θ以上の場合は「多」、θ未満の場合は「少」の２値にスコアリングする。なお、機能が利用された数が数回〜数百万回に幅広く分布するような場合には、機能が利用された数の対数値を用いてスコアリングしてもよい。なお、他の方法でスコアリングしてもよい。例えば、複数の閾値を設定し多段階にスコアリングしても良い。

利用実績集計部（１１０）は、プログラムと機能の関係テーブル（３１０）に含まれる機能ＩＤ毎に、機能が利用された拠点の偏り度合を算出する（ステップ１１３）。

例えば、利用実績集計部（１１０）は、機能が利用された拠点の偏り度合を、拠点別の機能が利用された数を降順に並び替えたグラフ（縦（ｙ）軸は機能が利用された数、横軸（ｘ）は拠点）について、指数近似して得られる減衰率（上記グラフを「ｙ＝Ｃ×ｅｘｐ（−ａ×ｘ）」で近似したときのａ値）として算出する。ここで、減衰率の値が大きい（グラフが急激に減衰する）場合は、機能が利用された拠点が限られている場合であり、減衰率の値が小さい（グラフが緩やかに減衰する）場合は、機能が利用された拠点が広範に渡っている場合である。なお、他の方法で偏り度合を算出してもよい。

利用実績集計部（１１０）は、ステップ１１３で算出した各機能が利用されている拠点の偏り度合をスコアリングし、機能利用実態（１２０）に出力する（ステップ１１４）。

例えば、利用実績集計部（１１０）は、ステップ１１２と同様に、閾値σを１つ定め、機能が利用されている拠点の偏り度合が、σ以上の場合は「大」、σ未満の場合は「小」の２値にスコアリングする。なお、他の方法で偏り度合を算出してもよい。例えば、複数の閾値を設定し多段階にスコアリングしてもよい。

また、利用実績集計部（１１０）は、機能が利用された数に関する処理（ステップ１１１及び１１２）と、機能が利用された拠点の偏り度合に関する処理（ステップ１１３及び１１４）の何れを先に実行しても良い。

図５は、機能利用実態（１２０）の構成例を示す。

機能利用実態（１２０）は、企業情報システムが有する各機能の利用実態に関する情報を含む。機能利用実態（１２０）は、データ項目として、機能ＩＤ（１２１）、機能名称（１２２）、機能が利用された数（１２３）、機能が利用された拠点の偏り度合（１２４）を有して良い。

機能ＩＤ（１２１）は、プログラムと機能の関係テーブル（３１０）に含まれる機能ＩＤである。

機能名称（１２２）は、プログラムと機能の関係テーブル（３１０）に含まれる機能名称である。

利用数（１２３）は、入力されたログ（２００）及び辞書（３００）に基づいて利用実績集計部（１１０）が出力した、機能が利用された数のスコアである。

機能が利用された拠点の偏り度合（１２４）は、入力されたログ（２００）及び辞書（３００）に基づいて利用実績集計部（１１０）が出力した、機能が利用された拠点の偏り度合のスコアである。

本実施形態では、機能が利用された数（１２３）と、機能が利用された拠点の偏り度合（１２４）とに基づいて、機能の利用実態の特徴を導出している。しかし、機能の利用実態の特徴の導出に、これ以外の要素も用いられてよい。例えば、機能が利用された時期の偏り度合（常時利用された、又は、一時期に集中的に利用されたなど）も用いられてもよい。例えば、ソースコードの解析結果、例えば、機能の結合度なども用いられてよい。結合度は、他機能との実装上の関連の強さの指標の１つである。結合度の大きい機能は、当該機能の除外による影響範囲が広いため、維持が必要と判定されやすくてよい。

図６は、分析事例（１４０）の構成例を示す。

分析事例（１４０）は、企業情報システムが有する各機能に対する過去の要否の分析結果に関する情報を含む。分析事例（１４０）は、データ項目として、分析事例識別子（１４１）、機能が利用された数（１４２）、機能が利用された拠点の偏り度合（１４３）、機能の要否判断（１４４）、判断理由（１４５）、分析時期（１４６）を有して良い。

分析事例識別子（１４１）には、過去に実施された機能の要否分析事例を識別するための識別子が格納される。分析事例識別子（１４１）は、分析対象とした企業情報システムの名称及び機能の名称などで構成される文字列であってよい。

機能が利用された数（１４２）には、分析対象とした機能が利用された数をスコアリングしたものが格納される。機能利用実態（１２０）の機能が利用された数（１２３）を２値にスコアリングした場合、この機能が利用された数（１４２）も２値のスコアリング（例えば「多」又は「少」）となってよい。

機能が利用された拠点の偏り度合（１４３）には、分析対象とした機能が利用された拠点の偏り度合をスコアリングしたものが格納される。機能利用実態（１２０）の機能が利用された拠点の偏り度合（１２４）を２値にスコアリングした場合、この機能が利用された拠点の偏り度合（１４３）も２値のスコアリング（例えば「大」又は「小」）となってよい。

機能の要否判断（１４４）には、分析対象とした機能の要否判断の結果が格納される。機能の要否判断（１４４）には、必要と判断された事例には「必要」、不要と判断された事例には「不要」が格納されてよい。

判断理由（１４５）には、分析対象とした機能の要否判断（１４４）をそのように判断した理由が格納される。

分析時期（１４６）には、分析対象とした機能の要否判断（１４４）の分析を実施した時期が格納される。

図７は、機能要否判断部（１３０）の処理例を示すフローチャートである。

機能要否判断部（１３０）は、利用実績集計部（１１０）における処理の終了をトリガとして、次の処理を開始する。機能要否判断部（１３０）は、機能利用実態（１２０）から１行を読み込む（ステップ１３１）。

次に、機能要否判断部（１３０）は、分析事例（１４０）から、ステップ１３１で読み込んだ行の機能に係る利用実態の特徴と同様の利用実態の特徴を有する行を取得する（ステップ１３２）。

例えば、機能要否判断部（１３０）は、ステップ１３１において図５の機能利用実態（１２０）の１行（１２９）を読み込む。この読み込んだ行の機能名称「機能Ω」（機能ＩＤ「Ｆ＿Ω」）の利用実態の特徴は、その機能が利用された数（１２３）が「少」、且つ、その機能が利用された拠点の偏り度合（１２４）が「大」である。そこで、分析事例（１４０）から、利用実態の特徴において、その機能が利用された数（１４２）が「少」、且つ、その機能が利用された拠点の偏り度合（１４３）が「大」である行（分析事例（１４０）の１、２、４、５、６行目）を取得する。

次に、機能要否判断部（１３０）は、ステップ１３２で取得した分析事例の行について、要否判断（１４４）が「不要」である行の割合を算出する（ステップ１３３）。

例えば、機能要否判断部（１３０）は、ステップ１３２で図６の分析事例（１４０）の１、２、４、５、６行目（全５行）を取得した場合、この中で要否判断「不要」の事例は４行であるので、「不要」である行の割合を８０％（＝４行／全５行）と算出する。

次に、機能要否判断部（１３０）は、ステップ１３２で分析事例から取得した行を、分析時期（１４６）の降順で並び替える（ステップ１３４）。

次に、機能要否判断部（１３０）は、機能利用実態（１２０）から次の１行を読込むことができる場合、ステップ１３１以降を繰り返す（ステップ１３５）。

機能要否判断部（１３０）における処理の結果は、インターフェース（１５０）を経由して画面等に出力されてよい。

図８は、開発支援システム（１００）の出力画面（８００）の例を示す。

出力画面（８００）には、機能及び不要判断事例割合の一覧（８１０）と、抽出された分析事例一覧（８２０）とが表示されてよい。

機能及び不要判断事例割合の一覧（８１０）は、機能名称（８１１）、不要判断事例の割合（８１２）、事例（８１３）を含んでよい。

機能名称（８１１）は、機能利用実態（１２０）の機能名称（１２２）である。

不要判断事例の割合（８１２）は、機能名称（８１１）の機能の利用実態の特徴と同様の利用実態の特徴を有する機能の要否判断事例に対する不要判断事例の割合である。この割合は、機能要否判断部（１３０）がステップ１３３で算出した割合であってよい。

事例（８１３）は、機能名称（８１１）の機能の利用実態の特徴と同様の利用実態の特徴を有する機能の要否判断事例である。これは、機能要否判断部（１３０）がステップ１３２で取得した行の内容であってよい。複数の事例が存在する場合は、ボタンなど、所定の要素が押下されると、抽出された分析事例一覧（８２０）が表示されてもよい。

抽出された分析事例一覧（８２０）は、分析事例識別子（８２１）、要否判断（８２２）、判断理由（８２３）、分析時期（８２４）を含んでよい。分析事例識別子（８２１）は、分析事例（１４０）の分析事例識別子（１４１）である。要否判断（８２２）は、分析事例（１４０）の要否判断（１４４）である。判断理由（８２３）は、分析事例（１４０）の判断理由（１４５）である。分析時期（８２４）は、分析事例（１４０）の分析の時期（１４６）である。

本実施形態によれば、過去の分析事例に基づく各機能の要／不要の判断の通例を、企業情報システムの各機能の要／不要を判断するための情報として、システムエンジニアに提示することができる。これにより、システムエンジニアは、企業情報システムに係る機能の要／不要を、より客観的に判断することができる。

（第２の実施形態）

第１の実施形態によれば、システムエンジニアは、過去の分析事例に基づく各機能の要／不要の判断の通例を、企業情報システムの各機能の要／不要を判断するための情報として参照することができる。

しかし、企業情報システムの各機能に対する要／不要の判断は、例えば、関連する技術動向、企業の経営方針、法令などからも影響を受ける。すなわち、機能の必要／不要の判断の通例が通用しない場合がある。このような場合には、各機能の要／不要の判断の反例が有用な場合もある。

図９は、第２の実施形態に係る機能要否判断部の処理例を示すフローチャートである。

図９の処理は、図７の処理におけるステップ１３４が後述のステップ１３６に置き換えられている点において相違し、それ以外において同じである。以下、ステップ１３６について説明する。

機能要否判断部は、ステップ１３２で取得した分析事例を、要否判断（１４４）の値が少数派の事例が上位となるように並び替える。なお、この並び替え方法はあくまで一例であり、他の方法であってもよい。例えば、分析事例（１４０）の判断理由（１４５）を、自然言語解析技術などを用いて解釈した内容に応じて、並び替えてもよい。

図１０は、第２の実施形態に係る開発支援システム（１００）の出力画面の例を示す。

抽出された分析事例一覧（８２０）において、１件の事例（８２５）は、全５件の事例に対して唯一「必要」と判断された事例、すなわち少数派の事例であるため、上位に並び替えられている。

本実施形態によれば、機能の要／不要の判断の通例が通用しない場合であっても、システムエンジニアは、企業情報システムに係る機能の要／不要を、より客観的に判断することができる。

上述した実施形態は、本発明の説明のための例示であり、本発明の範囲を実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。

例えば、開発支援システムを、単体の計算機で構築しても良いし、クライアント−サーバシステムとして構築してもよい。クライアント−サーバシステムで構築する場合、サーバ側で開発支援システムの主な処理を実行し、クライアント側で表示処理のみを実行してもよい。

また、上述した実施形態における具体的な値は、あくまで説明のための例であり、本発明はこれらの値に限定されるものではない。

また、上述した実施形態に係る機能の一部又は全ては、集積回路などのハードウェアで実現されてもよいし、ソフトウェアで実現してされてもよい。また、各機能を実行するコンピュータプログラム、データテーブル、ファイルなどの情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などの記憶装置又はＣＤ、ＤＶＤなどの記憶媒体に格納されてよい。

１００：開発支援システム １１０：利用実績集計部 １２０：機能利用実態 １３０：機能要否判断部 １４０：分析事例 １５０：インターフェース ２００：ログ ３００：辞書

Claims (7)

1. 情報システムが有する機能の要否判断を支援する開発支援システムであって、プロセッサ及びメモリを有し、
   前記プロセッサは、
   前記情報システムが有する各機能の利用実態に関する情報を含む利用実態情報に基づいて、各機能の利用実態の特徴を導出する機能特徴導出手段と、
   前記情報システムが有する各機能に対する過去の要否の分析結果に関する情報を含む過去要否分析情報から、前記特徴導出手段によって導出された利用実態の特徴と適合する利用実態の特徴を有する機能と、当該機能に対する過去の要否の分析結果と、を抽出する過去要否抽出手段と、
   前記過去要否抽出手段によって抽出された機能及び当該機能に対する過去の要否の分析結果を表示する表示手段と、を実行する
   開発支援システム。
2. 前記機能に対する過去の要否の分析結果は、当該機能に対する過去の要否の判断結果と、その判断理由とを含む
   請求項１に記載の開発支援システム。
3. 機能の利用実態の特徴は、当該機能が利用された数と、当該機能を利用した拠点の偏り度合に基づいて決定される
   請求項１に記載の開発支援システム。
4. 機能の利用実態の特徴は、さらに、当該機能を実現する複数のプログラムの間の結合度に基づいて決定される
   請求項３に記載の開発支援システム。
5. 前記表示手段は、さらに、前記過去要否抽出手段によって抽出された各機能に対する過去の要否の判断結果の内の不要の判断結果の割合を表示する
   請求項１に記載の開発支援システム。
6. 前記表示手段は、前記機能に対する過去の要否の判断結果の内、最も少数派の判断結果を、他の判断結果と区別可能な態様で表示する
   請求項１に記載の開発支援システム。
7. コンピュータが、情報システムが有する機能の要否判断を支援する方法であって、
   機能特徴導出手段が、前記情報システムが有する各機能の利用実態に関する情報を含む利用実態情報に基づいて、各機能の利用実態の特徴を導出し、
   過去要否抽出手段が、前記情報システムが有する各機能に対する過去の要否の分析結果に関する情報を含む過去要否分析情報から、前記機能特徴導出手段によって導出された利用実態の特徴と適合する利用実態の特徴を有する機能と、当該機能に対する過去の要否の分析結果と、を抽出し、
   表示手段が、前記過去要否抽出手段によって抽出された機能及び当該機能に対する過去の要否の分析結果を表示する
   開発支援方法。

Images