(57)【要約】【課題】分析プロジェクトの作業手順を解析できるようにした分析用作業手順記録支援システムを提供すること。【解決手段】分析プロジェクト１の作業手順の解析を支援する分析プロジェクト用作業手順解析支援システム１００は、分析プロジェクトに含まれる各処理プログラム３の操作履歴であるプログラム操作履歴データを取得するプログラム操作履歴データ取得部１１０と、各処理プログラムの構成を示すプログラム構成データを取得するプログラム構成データ取得部１２０と、プログラム操作履歴データとプログラム構成データとに基づいて、分析プロジェクトの作業手順の要約を生成する作業手順解析部１６０と、を備える。【選択図】図１
2018147198.tif 000002
【特許請求の範囲】
【請求項１】
分析プロジェクトの作業手順の解析を支援する分析プロジェクト用作業手順解析支援システムであって、
前記分析プロジェクトに含まれる各処理プログラムの操作履歴であるプログラム操作履歴データを取得するプログラム操作履歴データ取得部と、
前記各処理プログラムの構成を示すプログラム構成データを取得するプログラム構成データ取得部と、
前記プログラム操作履歴データと前記プログラム構成データとに基づいて、前記分析プロジェクトの作業手順の要約を生成する作業手順解析部と、
を備える分析プロジェクト用作業手順解析支援システム。
【請求項２】
前記作業手順解析部は、前記各処理プログラムのいずれかを用いて部分的に繰り返し実行される作業処理を抽出してグループ化し、抽出したグループ毎に作業内容を推定することにより、前記作業手順を解析する、
請求項１に記載の分析プロジェクト用作業手順解析支援システム。
【請求項３】
前記作業手順解析部は、前記作業処理の内容が所定値以上変化する作業処理を変化点として抽出することにより、前記作業処理をグループ化する、
請求項２に記載の分析プロジェクト用作業手順解析支援システム。
【請求項４】
前記作業手順解析部は、前記グループごとの前記処理プログラムの構成に関する適合度と実行順序に関する適合度とに基づいて、前記グループごとの作業内容を推定する、
請求項２に記載の分析プロジェクト用作業手順解析支援システム。
【請求項５】
前記作業手順解析部は、前記作業手順の解析結果をユーザに確認し、ユーザからの情報を前記作業手順の解析結果に反映させる、
請求項１に記載の分析プロジェクト用作業手順解析支援システム。
【請求項６】
前記作業手順解析部は、同一グループに複数の処理プログラムが関係する場合は、前記変化点に対応する作業処理に関わる処理プログラムを当該グループの代表処理プログラムとして選択する、
請求項３に記載の分析プロジェクト用作業手順解析支援システム。
【請求項７】
前記作業手順解析部は、前記代表処理プログラムを構成するサブ手順に関する情報を含むように前記作業手順の要約を生成する、
請求項６に記載の分析プロジェクト用作業手順解析支援システム。
【請求項８】
前記サブ手順に関する情報には、前記サブ手順ごとの修正内容の統計値が少なくとも含まれる、
請求項７に記載の分析プロジェクト用作業手順解析支援システム。
【請求項９】
前記分析プロジェクトは複数存在し、
前記作業手順解析部は、前記分析プロジェクトごとに作業手順の要約を生成し、前記分析プロジェクト間の類似性に基づいて前記分析プロジェクト間の関係性を算出する、
請求項１に記載の分析プロジェクト用作業手順解析支援システム。
【請求項１０】
前記分析プロジェクト間の関係性には、前記分析プロジェクト間で共通する作業内容に関わる処理プログラムの優劣に関する情報が含まれる、
請求項９に記載の分析プロジェクト用作業手順解析支援システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分析プロジェクト用作業手順解析支援システムに関する。
【背景技術】
【０００２】
近年、IoT（Internet of Things）技術、すなわち、各種設備、機械、機器に設置されたセンサからの情報をネットワーク経由等で収集して機械の稼動状態をモニタリングし、運用や保守に活用するための技術が普及しつつある。
【０００３】
IoT分野では、センサデータを収集して何らかの診断をする分析処理プログラムが必須である。この分析処理プログラムは、対象設備や機械の種類、業務上の目的などに応じて内容は様々であり、カスタマイズのための試行錯誤を減らすためには、分析処理プログラムの構築作業に関するノウハウの蓄積と伝達が必要である。
【０００４】
ノウハウの伝達のための最も基本的な手段は構築経験者による知見の対面伝達であるが、それを行うためには経験者が伝達のために多くの作業時間を消費する。別の手段として、経験者による作業マニュアルの整備も望ましい伝達方法であるが、同様にマニュアル作成のための多くの作業時間が必要となる。そのため、なるべく作業量を少なくしつつ、かつ必要な情報伝達を可能とする方法が望まれる。例えば、経験者の操作履歴を自動取得して、そこから作業手順が構成できることが望ましい。
【０００５】
もし、経験者がＩＴ機器上のソフトウェア上で分析プログラムを構築する場合、作業段階で何らかの履歴を自動記録すれば、その履歴を基礎情報として作業手順の自動記録に用いることが期待できる。すなわち、分析プログラムの作業ログの活用である。
【０００６】
関連する従来技術として、操作履歴や動作履歴を含む情報機器の稼動ログを要約し可視化する技術が挙げられる。例えば、特許文献１では、複数の監視対象機器のログを、その生起パターンや同時生起性情報を用いて要約し、発生時間に基づいてグラフに可視化する技術が提供されている。
【０００７】
分析処理手順の支援という観点では、処理のプロセスをフロー図として構築して、そのまま実行可能とする処理フローの開発支援ソフトウェアが浸透しつつある。そこでは、構築のための知識として、処理フローをどのように構築するかの順序や設定などの方法を推薦する機能を持つものもある。例えば、ＫＮＩＭＥ（米国登録商標）として知られるワークフロー型プラットフォームでは、フローの構築の際に、過去のコミュニティでの設計情報を元に、どのような機能モジュールをつなげばよいかを重み付きで推薦することで、フロー構築を支援する機能が提供されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特許第５９１３１４５号
【発明の概要】
【発明が解決しようとする課題】
【０００９】
従来技術を用いて操作ログの要約を生成することはできる。しかし、IoT分野などで用いられる分析プロジェクトにおいては、単に操作ログから特徴的なパターンを持つ部分を抽出するだけでは、作業手順の内容を十分に特定することができない。
【００１０】
例えば、同じプロセス内であっても、複数の処理フローを変えながら分析プロジェクトを進める場合がある。また、同じ処理フローであるが読込みデータや動作させる部分を変えて違った段階で使用する場合等もある。いずれの場合も、操作ログには同じ処理フローの利用履歴が残るのみであり、区別することができない。
【００１１】
他の例として、処理フローの開発履歴上で、ある処理フローの開発から他の処理フローの開発へ切り替わった場合をあげる。この場合、前者の開発が不首尾であったために後者の開発へ切り替わったのか、それとも前者の開発が成功して結論が得られたために後者の開発へ切り替わったのかを知る方法がない。
【００１２】
さらに、処理フローの構築作業では、過去に構築されたフローをどのように修正すればよいかについての情報が必要であることが多いが、操作ログの要約のみでは修正の内容を示すことはできない。
【００１３】
本発明は上記課題に鑑みてなされたもので、その目的は、分析プロジェクトの作業手順を解析できるようにした分析用作業手順記録支援システムを提供することにある。
【課題を解決するための手段】
【００１４】
上記課題を解決すべく、本発明の一つの観点に従う分析用作業手順記録支援システムは、分析プロジェクトの作業手順の解析を支援する分析プロジェクト用作業手順解析支援システムであって、分析プロジェクトに含まれる各処理プログラムの操作履歴であるプログラム操作履歴データを取得するプログラム操作履歴データ取得部と、各処理プログラムの構成を示すプログラム構成データを取得するプログラム構成データ取得部と、プログラム操作履歴データとプログラム構成データとに基づいて、分析プロジェクトの作業手順の要約を生成する作業手順解析部と、を備える。
【発明の効果】
【００１５】
本発明によれば、プログラム操作履歴データとプログラム構成データとに基づいて、分析プロジェクトの作業手順の要約を生成することができる。
【図面の簡単な説明】
【００１６】
【図１】本実施例の全体概要を示す説明図である。
【図２】本システムを単独の計算機で実現する場合の構成図である。
【図３】本システムをクライアント・サーバ方式で実現する場合の構成図である。
【図４】操作履歴データの構成例である。
【図５】処理フローの内容の記述例（処理フローの構成例）を示す。
【図６】操作履歴と内容の記述とから分析プロジェクトの作業手順を解析する処理を示すフローチャートである。
【図７】変化点を検出する処理を示すフローチャートである。
【図８】作業内容を推定する処理を示すフローチャートである。
【図９】ユーザに確認を求める画面を表形式で示す説明図である。
【図１０】実施済プロジェクトの全体手順画面を表形式で示す説明図である。
【図１１】フロー修正情報の構成例である。
【図１２】フロー修正内容を表示する画面例である。
【図１３】プロジェクト間の関連性を表示する画面例である。
【図１４】処理フローの比較情報を表示する画面を表形式で示す説明図である。
【発明を実施するための形態】
【００１７】
以下、図面に基づいて、本発明の実施の形態を説明する。本実施形態では、データ分析作業の内容まで含めた手順要約の生成を支援する。そのために本実施形態では、計算機中の処理部に分析作業記録支援プログラムを置き、記憶装置中の操作履歴のログ、及び、処理プログラム記述内容を参照して作業手順を抽出する。抽出手順は、操作履歴中の変化点を抽出し、繰り返し作業をまとめた作業グループにまとめ、各作業グループの作業内容の推定を行い、ユーザに提示確認する。また処理プログラム内のサブ手順ごとの修正率や修正箇所を集計提示する。
【００１８】
本実施形態では、処理フローの操作履歴のログ及びフローの記述内容の双方を用いて作業手順を抽出する。ここで、操作履歴のログは、上述した処理フローアプリのログを中心とするが、バージョン管理システムに記録されたログを用いることもある。
【００１９】
抽出手順は、操作履歴中の変化点、繰り返される類似の作業を一まとまりにした作業グループ、また、各作業グループがそれぞれどのような作業を行っているか、作業内容の推定を行う。さらに、本実施形態では、これらの抽出内容をユーザに確認のために提示して、作業中の判断理由などの加筆修正を求める機能を持つ。また、本実施形態では、抽出された手順の活用を支援するために、上記抽出内容に基づいた全体手順を提示する機能を持つ。さらに、本実施形態では、過去修正が多いノードの修正履歴を提示して修正支援を行う機能を提供する。
【００２０】
本実施形態によれば、処理フローの操作履歴のログ及び処理フローの記述内容の双方を用いて作業内容を推定することで、分析作業に特化した作業手順を、内容の類似性まで含めて精度良く抽出することが可能となる。また、本実施形態によれば、ユーザの確認画面によって、自動推定の誤りの修正、及び、自動では抽出しきれない処理内容の変更理由などの追加情報の入力が可能となる。さらに、本実施形態によれば、以上の処理、及び、入力による全体手順の一覧や各フローの修正箇所の一覧が可能な機能の提供によって、未経験者が過去のプロジェクトの概要を短時間で知ることが可能となる。
【実施例１】
【００２１】
図１〜図１２を用いて実施例を説明する。図１は、分析プロジェクト用作業手順解析支援システム１００の全体概要を示す説明図である。
【００２２】
図１（ａ）は、データ分析プロジェクト１、プロセス２、分析処理プログラム３、処理ノード４の関係を示す。
【００２３】
「処理プログラム」としての分析処理プログラム３は、複数のサブモジュール４から構成され、それらサブモジュール４上を順に処理が流れていくものとして表現できる。以後、一つの分析処理プログラム３を「処理フロー３」と、処理フロー３を構成するサブモジュール４を「処理ノード４」と呼ぶ。案件に対応して、様々な検討を行って処理手順を構築する為の一連の作業を、以後「分析処理構築プロジェクト１」、「データ分析プロジェクト１」、「分析プロジェクト１」と呼ぶ。
【００２４】
ここで、一つの「分析プロジェクト１」は、一般に、特徴量の選択を検討したり、異常検出のアルゴリズムを検討したりと複数のプロセス２（手順）から成る。各プロセス２は、いろいろな試行錯誤を実験的に行っていくことが多く、その結果、履歴を見ると複数の処理フロー３を少しずつ変えながら用いることが多い。以上をまとめると、一つの「分析プロジェクト１」は複数の「プロセス２（手順）」からなり、一つの「プロセス２（手順）」は、履歴上、複数の「処理フロー３」を利用する。さらに、一つの「処理フロー３」は、複数の「処理ノード４」を連結して構成されるという階層構想となっている。
【００２５】
図１（ｂ）は、分析プロジェクト用作業手順解析支援システム１００の機能構成を示している。以下、分析プロジェクト用作業手順解析支援システム１００を作業手順解析支援システム１００、支援システム１００と略記する場合がある。
【００２６】
作業手順解析支援システム１００は、例えば、操作履歴データ取得部１１０、処理フロー構成データ取得部１２０、変化点抽出部１３０、作業内容推定部１４０、ユーザ確認部１５０を備える。変化点抽出部１３０、作業内容推定部１４０およびユーザ確認部１５０は、作業手順解析部１６０を構成する。
【００２７】
「プログラム操作履歴データ取得部」としての操作履歴データ取得部１１０は、「処理プログラム」としての処理フロー３の操作履歴を取得する機能である。「プログラム構成データ取得部」としての処理フロー構成データ取得部１２０は、処理フロー３の構成（どのような内容が記述されているか）を示すデータを取得する機能である。
【００２８】
作業手順解析部１６０は、分析プロジェクト１を解析して作業手順の要約を生成する機能である。作業手順解析部１６０は、例えば、変化点抽出部１３０、作業内容推定部１４０、ユーザ確認部１５０を含む。
【００２９】
変化点抽出部１３０は、作業処理内容が所定値以上変化する処理フロー３を変化点ＣＰとして抽出する機能である。変化点抽出部１３０は、処理フロー３による作業処理の中から同一作業に属する作業処理を抽出してグループ化する。つまり、作業処理の内容に基づいて作業処理を分類する。作業内容推定部１４０は、各グループの作業内容を推定する機能である。ユーザ確認部１５０は、作業内容の推定結果をユーザへ提示して確認を求めると共に、ユーザからの情報を作業手順の解析結果、つまり要約に反映させる。
【００３０】
図１（ｃ）は、作業手順解析支援システム１００がユーザへ提供する画面例である。縦軸は作業内容を示し、横軸は時間の経過を示す。画面には、例えば、処理フロー３を象徴するフローアイコン３Ａ、処理フロー３のグループであるプロセス２を象徴するグループ２Ａ、作業内容を表示するラベル５とが含まれている。
【００３１】
図１中のラベル５（１）〜５（３）の一部または全部は、作業手順解析部１６０が自動的に設定することができる。自動的に設定されたラベル５（１）〜５（３）の一部または全部について、分析プロジェクトに関わるユーザが修正することができる。
【００３２】
なお、図１（ｃ）では省略しているが、例えば、修正頻度の高いノード４に関する情報、他の分析プロジェクト１との関係性を示す情報、追記情報（その作業を行った理由、手戻りが発生した理由、作業の留意事項等）を含めることもできる。
【００３３】
このように、作業手順解析部１６０は、分析プロジェクト１の作業手順の要約を作成し、ユーザの確認を得ることができる。ユーザが確認して必要な情報を追記した作業手順の要約は、分析プロジェクト１の開発を担当する後継者等に引き継ぐことができ、作業効率を向上することができる。
【００３４】
図２に、単独の計算機にて処理フロー設計を行うと同時に作業手順の解析を支援する場合の構成例を示す。計算機１０００は、例えば、処理部１００１、記憶装置１００２、ユーザインターフェース部１００３を含む。ユーザインターフェース部１００３は、ＵＩ装置１０１０に接続されている。計算機１０００は、ＵＩ装置１０１０を介して、分析者であるユーザＵに対して情報を提供したり、ユーザＵから入力される情報を受け取る。ＵＩ装置とは、ユーザインターフェース装置の略であり、例えば、ディスプレイ、プリンタ、音声合成装置、音声認識装置、キーボード、タッチパネル、押釦スイッチ、マウス等のような装置が該当する。
【００３５】
計算機１０００の処理部１００１では、例えば、分析作業解析支援プログラム１０、処理フロー構築・操作プログラム２０、バージョン管理プログラム３０等のコンピュータプログラムが動作可能となっている。詳しくは、処理部１００１に含まれるマイクロプロセッサは、上述のコンピュータプログラム１０，２０，３０をメモリ（いずれも不図示）から読み込んで実行することにより、所定の機能を実現する。
【００３６】
分析作業解析支援プログラム１０は、分析プロジェクトの作業手順の解析を支援するコンピュータプログラムである。マイクロプロセッサが分析作業解析支援プログラム１０を実行することにより、図１で述べた支援システム１００が実現される。
【００３７】
処理フロー構築・操作プログラム２０は、分析プロジェクトにおいて、処理フローを構築して動作させるためのプラットフォームとなるコンピュータプログラムである。このプログラム２０の例として、上述のＫＮＩＭＥ等を用いることができる。
【００３８】
バージョン管理プログラム３０は、開発中の処理フローの改変内容を管理するコンピュータプログラムである。このバージョン管理プログラム３０も、開発物の改変が管理可能な既存のプログラムを用いることができる。
【００３９】
記憶装置１００２には、例えば、分析対象データＴ１、処理フロー構成データＴ２、操作履歴データＴ３の各データが格納される。
【００４０】
分析対象データＴ１は、分析プロジェクトにおいて分析対象となるデータである。処理フロー構成データＴ２は、作成された処理フローの構成情報である。フロー構成データＴ２には、例えば、データの読込みをどこから行って、どのような処理を行って、どのような出力を行うかが記述されている。操作履歴データＴ３は、ユーザＵが処理フロー構築・操作プログラム２０を操作した履歴が格納されているログデータである。データの形式は後述する。このデータＴ３は、処理フロー構築・操作プログラム２０がユーザＵの操作に沿って出力するものを用いることを想定している。もし、処理フロー構築・操作プログラム２０の履歴内容が不足している場合には、より下位層のソフトウェアからの情報を用いればよい。例えば、キー操作の情報をＯＳレベルで取得すれば、その情報からユーザの操作内容を再構成することができる。
【００４１】
図３には、いわゆるクライアント・サーバ型システムで運用する例を示す。サーバとなる計算機１１００とクライアント端末１２００とは、通信ネットワークＣＮを介して接続されている。
【００４２】
計算機１１００は、例えば、処理部１１０１、記憶装置１１０２、通信部１１０３を備えている。処理部１１０１は、上述の各プログラム１０，２０，３０を実行可能となっている。記憶装置１１０２は、上述の各データＴ１，Ｔ２，Ｔ３を格納する。
【００４３】
クライアント端末１２００は、例えば、処理部１２０１と通信部１２０２を備えており、通信部１２０２は通信ネットワークＣＮを介して計算機１１００の通信部１１０３に接続されている。
【００４４】
クライアント端末１２００の処理部１２０１は、ユーザインターフェースプログラム４０を実行することで、ＵＩ装置１２１０を介してユーザＵへ情報を提供したり、ユーザＵから情報を受領したりする。ユーザインターフェースプログラム４０は、例えばウェブブラウザである。図３の構成例では、開発処理およびデータの実体はサーバ１１００側に置き、クライアント端末１２００には、ユーザインターフェースプログラム４０があるのみである。
【００４５】
さらに、図２、図３どちらでもない中間的な構成をとることも可能である。例えば、各種プログラムはクライアント側に配置し、データはサーバに配置して、クライアント側のプログラムは必要に応じてサーバからデータを読み込む形態でもよい。クライアントとサーバの両方に同じプログラムを配置して、両方のプログラム間で作業を振り分ける形態でもよい。これらのうちどの構成を用いるかは、例えば、データ量、計算量、許されるリソース等に応じて適宜選択する。以下では基本的にどの構成を用いても可能な処理として説明を行う。構成を特定する必要がある部分に関してはその都度特定して述べる。
【００４６】
図４に、操作履歴データＴ３の構成内容の一例を示す。操作履歴データＴ３は、一般に、図４に示すとおり、操作ごとに各レコードが構成される。各レコードは、例えば、レコードＩＤ  Ｔ３０、時刻Ｔ３１、作業者ＩＤ  Ｔ３２、操作対象Ｔ３３、操作内容Ｔ３４、結果Ｔ３５などから構成される。
【００４７】
レコードＩＤ  Ｔ３０は、各レコードを識別する情報である。時刻Ｔ３１は、レコードの作成時刻、つまり処理フローの操作時刻である。作業者ＩＤ  Ｔ３２とは、各レコードの操作がどの作業者によって行われたかを記録したものである。ログがあらかじめ作業者ごとに分割されている場合など、別の方法で作業者を特定できる場合には、作業者ＩＤは不要である。
【００４８】
操作対象Ｔ３３は、現在操作の対象となっている処理フローを示す情報である。ここで、ある時点で一旦特定の処理フローを開いたら、次に閉じるまで一つの同じフローを用いることに限定されている場合には、操作対象Ｔ３３は略される場合もある。操作内容Ｔ３４は、どのような操作を行ったかを記録したものである。ここで、操作とは、処理フローを開く、改変する、実行する、部分的に実行する、保存する、閉じる、などである。結果Ｔ３５は、動作の結果が正常であったかエラーであったか、さらには結果がエラーの場合、どのような内容であったかなどの記録である。
【００４９】
もし、これらの操作履歴情報が処理フローの出力する履歴だけからでは得られない場合、複数の履歴を併用することによって同様の情報を得られるのであれば、そのような代替処理を行えばよい。例えば、処理フロー構築・操作プログラム２０の操作履歴データだけでは、改変の内容（どの処理ノードを改変したか等）がわからない場合、別途バージョン管理プログラム３０の履歴データを併用することでわかる場合などが想定される。
【００５０】
図５に、処理フロー構成データＴ２の例を示す。処理フロー構成データＴ２は、処理フローの内容を記述した情報である。図１で述べたように、処理フロー３は、単一の処理を行う処理ノード４を複数結合して構成される。
【００５１】
処理フローの構成を記述する方法として、図５ではXML（Extensible Markup Language）のようなマークアップ言語で記述した例を示している。但し、図５は、本実施例を説明するための例示であり、タグの名称等は実在するものとは異なる。また、実装上は、各種情報（パラメータ値、結合情報など）は別のファイルに分割されているような構成となっている場合もある。図５は、各種情報を一つに統合した場合の概念図である。
【００５２】
上半分の領域Ｔ２１が単一処理を示す各処理ノードに関する記述である。下半分の領域Ｔ２２は、各処理ノードを結合させた状況を示す。処理ノードの記述例として、領域Ｔ２３で示す部分は“ReadTable”という種類（名称）のノードであり、“FileName1”というパラメータを持つ。“ReadTable”という種類の処理ノードは、ファイルからデータを読み込むノードである。“Parameter1”が読込みファイル名であることが既知の場合、この記述でどのようなデータ入力をするフローであるかがわかる。また、領域Ｔ２４で示す部分は、結合情報の１ブロックである。この結合情報は、“N001”のノードから“N002”のノードへの結合があり、”DataFlow”という種類（名称）の結合であることを示す。つまり、図５では、ノード“N001”から“N002“へのデータ結合があることを示す。
【００５３】
図６のフローチャートを用いて、本実施例における作業手順の解析支援の全体処理を説明する。まず、本実施例の解析支援の動作パターンについて説明する。動作パターンは２種類に大別される。一つは、全ての処理を分析プロジェクトの特定のタイミングで順に動作させる方法である。もう一つは、高頻度で部分的な処理のみ行い、その結果に応じて残りの処理を行うかどうか判断する方法である。
【００５４】
前者の動作パターンで解析支援を行う場合、支援システム１００は、操作履歴データＴ３及び処理フロー構成データＴ２を読み込む（Ｓ１０，Ｓ１１）。次に、支援システム１００は、変化点の検出（Ｓ１２）、ユーザによる確認（Ｓ１４）、作業内容の推定（Ｓ１５）、ユーザへの最終確認（Ｓ１６）の順に処理を行う。これら各処理については、後述する。なお、図６に示す一連の手順を動作させるタイミングとしては、例えば、予め設定した期間が経過した時、分析プロジェクトの終了時、技術移転時などが想定される。
【００５５】
次に、後者の動作パターンで解析支援を行う場合の手順を説明する。支援システム１００は、操作履歴データＴ３及び処理フロー構成データＴ２を読み込んだ後（Ｓ１０，Ｓ１１）、変化点の検出処理を実行する（Ｓ１２）。変化点検出処理（Ｓ１２）の詳細は図７で後述する。
【００５６】
支援システム１００は、変化点検出処理（Ｓ１２）によって新たに変化点の発生が検知されると（Ｓ１３：ＹＥＳ）、ユーザ確認処理（Ｓ１４）、作業内容推定処理（Ｓ１５）、ユーザ最終確認処理（Ｓ１６）を行う。なお、動作頻度の例として、日次作業の終了時等に図６に示す本処理を起動させて、変化点が発生した段階で自動的に残りの処理を実行することを想定している。
【００５７】
図７を用いて、支援システム１００の変化点抽出部１３０の実行する変化点検出処理（Ｓ１２）の詳細を説明する。前提として、同一分析プロジェクト内の履歴から、用いられた処理フローが複数あり、それらの処理フローは時間順に抽出されているとする。すなわち、本実施例では、操作履歴データＴ３中に複数のプロジェクトの履歴が混じっていないものとする。
【００５８】
支援システム１００の変化点抽出部１３０は、処理フローの操作履歴データＴ３から以下に述べる方法で、作業内容の変化した点（変化点ＣＰ）を算出する。
【００５９】
支援システム１００は、最も古い処理フローから順に、変化点であるか否かを判別する着目フローを指定していく（Ｓ１２０）。支援システム１００は、着目フローを一つ指定した後、その着目フローを含んで過去側に連続したWp個の処理フローの情報を読み込む（Ｓ１２１）。また、支援システム１００は、着目フローの次から連続したWf個の処理フローの情報を読み込む（Ｓ１２２）。以下、前者を「過去フロー群」と、後者を「未来フロー群」と呼ぶ。着目フローは「過去フロー群」に含む。
【００６０】
支援システム１００は、過去フロー群と未来フロー群とに基づいて、過去フロー群と未来フロー群との乖離度dを算出する（Ｓ１２３）。ここで、乖離度とは、処理フローの特徴がどの程度異なっているかを定量化したものである。乖離度は、目的に応じてさまざまな定義が可能である。本実施例では、分析プロジェクトの定型的なステージごとに分類するために適した乖離度を定義する。分析プロジェクトのステージとは、最終的な分析処理フローを確立するまでの定型的な処理、すなわち例えば、「特徴量検討」、「アルゴリズム検討」、「学習・テスト」、「後処理検討」などである。従って、それらの各ステージの違いを端的にあらわす乖離度をステージごとに採用すればよい。また一般的に、処理フローのファイル名称などを乖離度の算出に使用してもよい。以上の考察から、例えば乖離度を下記の（式１）で定義する。
【００６１】
（過去フロー群と未来フロー群の乖離度）
＝（ファイル名の非共通割合）＋（処理ノード種類の非共通割合）…（式１）
【００６２】
ここで、「ファイル名の非共通割合」とは、過去フロー群と未来フロー群に共通に登場しないファイルの数の割合である。例えば、過去ブロー群Wp個中Cp個が、未来フロー群Wf個中Cf個と共通のファイル名を持っていると算出された場合、非共通割合は、下記の（式２）で求められる。
【００６３】
非共通割合＝（Wp−Cp）＊（Wf− Cf）／（Wp + Wf）…（式２）
【００６４】
ここで例えば「FeatureTest3」の「3」のように、少し改変した処理フロー名は共通したファイル名として処理することが適当な場合が多い。そこで、通常はファイル名の語尾を何文字か無視して、ファイル名が共通するか否か判定する。
【００６５】
（式１）の２項目の「処理ノード種類の非共通割合」は、各処理フローを構成する処理ノードの種類から、何個の処理ノードが共通していないかを割合で示すものである。例えば、過去フロー群の中の処理ノードの種類の構成状況を見て、「ReadFile」がA個、「SelectData」がB個、などと積算カウントする。未来フロー群も処理ノードの種類ごとにカウントする。
【００６６】
その後、支援システム１００は、各処理ノードで共通する個数をカウントする。例えば「ReadFile」について過去フロー群ではA個、未来フロー群ではZ個であれば、｜A−Z｜個が共通していると算出する（｜｜は絶対値）。その結果、過去フロー群のトータルTp個のフロー中、未来フロー群と共通する処理ノードがCp個であり、同様に、未来フロー群中のトータルTf個のフロー中、過去フロー群と共通する処理ノードがCf個あったとすると、処理ノード種類の非共通割合は、下記の（式３）から算出できる。
【００６７】
処理ノード種類の非共通割合
＝（Tp−Cp）＋（Tf−Cf）／（Tp＋Tf）…（式３）
【００６８】
上述の乖離度は、時系列中の順序は不問である。これに代えて、複数の処理フローを順に用いて処理を行う場合、順序を考慮した乖離度を用いてもよい。例えば変化点の前には「ＡＢＡＢ・・・」と２つの処理フローを繰り返し用いるパターンが抽出され、変化点の後では「ＣＢＣＢ・・・」というパターンが抽出される場合、過去フロー群｛aWp, ...., a2, a1｝、未来フロー群{b1, b2, ..., bWf}として、下記の（式４）から乖離度を算出してもよい。
【００６９】
（過去フロー群と未来フロー群の乖離度）＝（aWとb1の乖離度）+（a{W-1}とb2の乖離度）+...+（a1とbWの乖離度）…（式４）
【００７０】
ここでW= min{Wp, Wf}とする。乖離度の定義は、上記のW個を併せた場合でW=1とみなして算出したものを用いればよい。
【００７１】
以上で述べた手順では、分析プロジェクトの各ステージを分離する観点での乖離度の定義を述べたが、これに代えて、乖離度の内容を変えることで、複数の観点の変化点をそれぞれ算出してもよい。例えば、読込みデータの種類（ファイルかデータベースか）、実行時間などの違いを乖離度とすることで、テスト用の小規模トライか本番トライかの変化を抽出する等である。  
【００７２】
なお、上記では、新たにWp+Wf個の処理フローを全て読み込んで算出する場合を説明したが、これは説明の簡単のためである。これに代えて、過去の処理内容との差分を用いる等の高速化を行うことができる。
【００７３】
支援システム１００は、ステップＳ１２３で算出した乖離度dと予め定めた閾値Thdとを比較し、乖離度dが閾値Thdより大きいか判定する（Ｓ１２４）。支援システム１００は、乖離度dが閾値Thdより大きいと判定すると（Ｓ１２４：ＹＥＳ）、着目フローは変化点であると判定する（Ｓ１２５）。これに対し、支援システム１００は、乖離度dが閾値Thd以下であると判定すると（Ｓ１２４：ＮＯ）、着目フローは変化点ではないと判定する（Ｓ１２６）。支援システム１００の変化点抽出部１３０は、以上で述べた処理をプロジェクト内のフローが終了するまで（Ｓ１２７）、着目フローをシフトさせながら繰り返す。
【００７４】
なお、履歴の両端（最初の方と最後の方）に近い部分を着目フローとする場合、Wpの変わりにmin{Wp,（開始から着目フローまでの数）}をWpと読み替え、同様にWfのかわりにmin{Wf,（着目フローの次から最後までの数）}をWpと読み替えて、上記処理を行えばよい。なお、時系列中の最後の処理フローはWf=0となるため、記算出は不可能であるが、処理の便宜上常に変化点とする。
【００７５】
支援システム１００は、全ての処理フローに対して変化点検出を終了すると（Ｓ１２７：ＹＥＳ）、算出した変化点をグループ化する（Ｓ１２８）。本実施例では、操作履歴データＴ３に複数プロジェクトの履歴は混じらないという前提であるため、ある変化点から次の変化点までで区切られる処理フローの組を一つのグループと定義できる。すなわち、最初の処理フローから最初の変化点までが一つのグループ、最初の変化点の次の処理フローから、次の変化点までが２番目のグループ、として順にグループ化する。最後のグループは、最後から２番目の変化点の次の処理フローから最後の処理フロー（上述した定義より最後の変化点でもある）までで構成される。
【００７６】
以上の手順で、変化点検出とグルーピングが完了する。この後、各グループがどのような処理を行っているかを推定する作業内容推定（Ｓ１５）へ進むことができる。作業内容を自動推定する前に、グループ化処理の結果を分析者であるユーザへ提示して、ユーザによる確認を得るのが望ましい。その理由は、もしグループ化の段階で失敗している場合、その正確でないグループに対して作業内容推定をしても意味が無いためである。結局はグルーピングの修正、作業内容の推定の修正を行わなければならず、手戻り量が多くなって無駄になるためである。もし精度や手戻り時間をいとわない場合、この段階でのユーザに対する確認プロセスは省略することも可能である。しかし一般には、ユーザの確認を得てから処理を進めるのが望ましい。
【００７７】
ステップＳ１４によるユーザ確認の手順は、以下のとおりである。支援システム１００のユーザ確認部１５０は、ＵＩ装置１０１０，１２１０に表示する画面を通じて、処理フローを時系列でユーザへ提示する。時系列で示された各処理フローのうち、変化点であると判定された処理フローには、他の処理フローと区別がつくように、マークや強調表示等が付与される。分析者であるユーザは、その時系列提示を一覧して、変化点と判定された部分のうち変化点としてふさわしくないものを発見した場合、ＵＩ装置から情報を入力して修正することができる。これとは逆に、変化点と判断されていない箇所を変化点とすべき場合も、ユーザは情報を入力して修正することができる。
【００７８】
変化点の検出とグループ化およびユーザ確認が終了した後、支援システム１００は、各グループでの処理を推定する作業内容の自動推定処理を実行する（Ｓ１５）。すなわち、支援システム１００の作業内容推定部１４０は、各グループに対して、それぞれ一つの作業内容を推定して割り振る。
【００７９】
作業内容を推定する方法の一例として、本実施例では、各グループの処理内容の適合度とそれぞれの作業が生起する順序の両方とを最適化する評価関数を用いる。図８に沿ってその手順を説明する。
【００８０】
支援システム１００の作業内容推定部１４０は、各グループに初期の作業内容（初期ラベル）を割り当てる（Ｓ１５０）。以下、「割り当てる」を「割り振る」と表現する場合がある。
【００８１】
初期ラベルはランダムに割り振ってもよい。ランダムに割り振る方法に代えて、データ分析プロジェクトにおける通常の手順にしたがって初期ラベルを割り当ててもよい。すなわち、「データ可視化」、「データ選択」、「アルゴリズム選択」、「学習・テスト」、「後処理」、「本番フロー作成」、の順に行われたと仮定して、これらの順に初期ラベルを配分する。これにより、後述するラベル変更処理（ラベル修正処理）を減らすことができる。
【００８２】
最初のラベルの割当てをデータ分析プロジェクトの通常の手順（プロセス）にしたがって行う方法の例を説明する。データから特定された変化点（グループ）が１０個あったとして、上記６つのステータスを順序を維持して、平均１０／６＝１．５個当てはまるように割り振る。例えば、「データ可視化×２、データ選択×１、アルゴリズム選択×２、学習・テスト×１、後処理×２、本番フロー作成×２」などと割り振る。
【００８３】
次に、割り振りに対して適合度cvを算出する（Ｓ１５１）。ここで、適合度は、上述した各グループの処理内容の適合度とそれぞれの作業が生起する順序との両方を最適化する評価関数とする。例えば、下記の（式５）のように構成する。
【００８４】
（作業内容割り振り適合度cv）
＝aΣ_{各グループi}（iの割振り作業内容との合致度）
+ bΣ_{隣のグループi, i+1}（i, i+1間の順序整合性） …（式５）
【００８５】
ここでa, bは、合致度と順序整合性のどちらを重視するかに関する事前に定める重み係数である。
【００８６】
第１項の「割振り作業内容との合致度」は、変化点もしくはグループ内全部の処理フロー中の処理ノードの種類を用いて合致度を算出する。その手法の一例として、変化点検出で用いたのと同様に、グループ内の全ての処理ノードの構成状況を見て「ReadFile」がA個、「SelectData」がB個、などと積算カウントする。その積算値と予め一般的な生起割合を集計しておいた処理ノードの割合とを比較して、一致する割合を適合度とする。その際「テストノード」等の特徴的なノードがある場合は合致度を高くする等の処理を行ってもよい。これとは逆に、どの処理フローにもあるような処理ノードは考慮しない等の処理も可能である。
【００８７】
第２項の「順序整合性」は、標準的な順序を予め設定しておき、例えばそれを、od[作業内容]=順序と整理する。今、iとi+1の作業内容work[i]とwork[i+1]が推定されたとき、それらの順序整合を使って整合性を例えば下記の（式６）のように定義する。
【００８８】
（i, i+1間の順序整合性） = 1 if od[work[i+1]] ? od[work[i]]= 1
-10 if od[work[i+1]] ? od[work[i]] >=2
0 if od[work[i+1]] ? od[work[i]] <= 0…（式６）
【００８９】
次に来るべき作業内容であれば高ポイントを与える。次に来るべき作業内容を飛び越えた場合は、分析プロジェクトの順序としてありえないので負のポイントを与える。手戻り（グループは異なるが同じ状態にいる場合も手戻りとした）は、高ポイントと負のポイントとの中間の値、例えば０ポイントを与える。
【００９０】
次に、支援システム１００の作業内容推定部１４０は、適合度の最適化を行うために繰り返し計算を行う。そのためにはいろいろな手順が可能であるが、ここでは例えば微少変化と適合度判定を繰り返す。
【００９１】
まず、作業内容推定部１４０は、先ほど算出した合致度が最も悪いグループの作業内容を、最も合致度が高い作業内容へ変更し、ラベルの仮変更状態とする（Ｓ１５２）。そして、繰り返し計算の回数kをカウントする（Ｓ１５３）。
【００９２】
作業内容推定部１４０は、ラベルを仮変更した状態で再度適合度を算出し、適合度が改善したか判定する（Ｓ１５４）。適合度が改善した場合（Ｓ１５４：ＹＥＳ）、ステップＳ１５２でのラベル変更を採用する（Ｓ１５５）。
【００９３】
作業内容推定部１４０は、改善した適合度cvが予め定めた閾値Thcvを超えるか判定する（Ｓ１５６）。適合度cvは改善したが閾値Thcvを超えない場合（Ｓ１５６：ＮＯ）、Ｓ１５２へ戻ってラベルを再度変更する。
【００９４】
適合度が改善していなければ（Ｓ１５４：ＮＯ）、作業内容推定部１４０は、ステップＳ１５２へ戻り、再度ラベルを変更する（Ｓ１５２）。なお、ラベル変更の回数kが規定の上限値ULに達した場合（Ｓ１５７：ＹＥＳ）、本処理を抜けて図６のフローチャートへ戻る。
【００９５】
すなわち、作業内容推定部１４０は、適合度が改善するまで、合致度が最も悪いグループの作業内容を適合度が２番目の作業内容に変える、２番目でも駄目なら３番目に変更する、といった計算を繰り返す。改善しない場合は合致度が２番目に悪いグループで同じ処理を繰り返す。適合度cvが閾値Thcvを越える（Ｓ１５６：ＹＥＳ）か、試行回数kが上限ULを超えるまで（Ｓ１５７：ＹＥＳ）、この処理を繰り返す。
【００９６】
上述の計算処理に付随して、手戻りの位置を検出することができる。すなわち、本来の標準的な手順（プロセス）から逆行している部分（上記整合性が０ポイントのところ）は、「手戻り」の生じた箇所である。そこで、手戻り発生箇所を記録してユーザへ提供する画面上に表示すれば、分析者であるユーザはその情報を利用して分析プロジェクトの開発に活かすことができる。
【００９７】
図６に戻る。作業内容推定が完了すると（Ｓ１５）、支援システム１００は、結果確認と追加情報の記入促進のために、ユーザによる最終確認を実行する（Ｓ１６）。図９に、ユーザによる確認画面（問合せ画面）Ｇ１の一例を示す。ここでは、画面Ｇ１を表形式でユーザへ提供する。これに代えて、時系列グラフや他の表現方法を用いて、ユーザへ提供する画面を構成してもよい。
【００９８】
図９の画面Ｇ１では、各行が履歴のプロセスを示す。画面Ｇ１は、例えば、ステータス欄Ｇ１０、フロー欄Ｇ１１、グループ欄Ｇ１２、作業内容欄Ｇ１３、動作欄Ｇ１４、変更ノード欄Ｇ１５、変更理由欄Ｇ１６を含む。
【００９９】
ステータス欄Ｇ１０には、変化点かどうかを示す情報が示される。フロー欄Ｇ１１には、処理フローの名称が示される。グループ欄Ｇ１２は、変化点検出に伴う処理フローのグループ番号を示す。もし自動的なグループ分割を間違えている場合は、ユーザが修正できるようになっている。
【０１００】
作業内容欄Ｇ１３は、上述の方法で自動的に推定した作業の内容である。自動的に推定した作業内容が実際の作業内容と異なる場合、ユーザは画面上で修正できる。動作欄Ｇ１４は、履歴中の「開く」「動作」「保存」「閉じる」、のどの動作であったかの区別を示すものである。図９の例では「保存」のみを集めた（「保存」でフィルタリングした）例を示す。変更ノード欄Ｇ１５は、修正があった場合に、処理フロー中のどの処理ノードが修正されたかを示す。バージョン管理プログラム３０のログから自動抽出することで、列Ｇ１５へ修正箇所の情報を格納できる。あるいは、「保存」の際の処理フローの差分を別途とって記録することで、列Ｇ１５に修正箇所の情報を格納してもよい。
【０１０１】
変更理由欄Ｇ１６は、ユーザに記入を促す部分であり、なぜ変更したかの理由を記入させる。図９の例では、４行目に「特徴量を規格化 」という理由が記入されている。他の行では理由は記入されていない。なお、実装に際しては、画面Ｇ１上で入力の場所を指定するごとに、文字数の多い詳細な記入が可能なように、画面Ｇ１とは別ウインドウの記入エリアが起動してもよい。
【０１０２】
以上、「特徴量抽出」「アルゴリズム検討」などのデータ分析プロジェクトの通常のプロセスに従ってラベルを設定する場合を述べた。その他の作業状況についても、同様の方法でラベル付けしたり、関係性を整理したりしてもよい。
【０１０３】
例えば、実行履歴中で、処理フローの読込み履歴を分析することにより、本番データでの実行か試行データでのプレ実行であるかを判別することができる。また、変化点ではあるが、次のグループとの処理ノードの類似性が見られる場合には、トライアルが成功してその結果が反映されている、と判別することができる。また、逆に全く類似性が無く、完全に断絶している場合には、トライアルが失敗して廃棄された可能性が高い、と判別することができる。このように関係性を整理することができる。
【０１０４】
次に、分析者としてのユーザの分析プロジェクトの解析結果を、引継者であるユーザが活用する例を説明する。引継者は、過去のデータ分析プロジェクトの解析結果を利用することで、データ分析プロジェクトを改善することができる。
【０１０５】
過去のデータ分析プロジェクトを活用する手順では、第１ステップとして、引継者に対し、過去のデータ分析プロジェクトの全体手順を提示する。図１０に、実施済プロジェクトの全体手順を解析した画面Ｇ２を示す。実施済プロジェクトとは、支援システム１００により全体手順が解析された過去のデータ分析プロジェクトである。
【０１０６】
図１０では、表形式の画面Ｇ２を引継者へ提示する。画面Ｇ２の各行が手順の概要を示しており、例えば、作業内容欄Ｇ２０、代表フロー欄Ｇ２１、代表フロー概要欄Ｇ２２、コメント欄Ｇ２３を含む。プロセスは、上の行から下の行へ進む。これらは、図９までの抽出作業にて抽出した各グループとその作業内容の推定結果に相当する。
【０１０７】
作業内容欄Ｇ２０は、推定した作業内容の分類を示す。代表フロー欄Ｇ２１は、作業内容の分類を示す代表的なフローの名前を示す。この代表フローでは、上記で算出した変化点におけるフローが表示されている。
【０１０８】
代表フロー概要欄Ｇ２２は、その概要フロー中の特徴的な処理ノードの概要を表示したものである。引継者がさらに詳細情報が必要となった場合のために、「処理ノード」からのリンクを構成して、実態の処理ノードの実体を見ることができる機能や、さらには処理フロー構築・操作プログラム２０が立ち上がって処理ノードを確認できる機能が実現できる構成が望ましい。
【０１０９】
コメント欄Ｇ２３は、全体処理フロー中の特徴的な状況の自動抽出情報や、分析者であるユーザの残したコメントを表示する。例えば２行目の「特徴量は規格化」は、図９で入力した変更理由Ｇ１６である。３行目の「手戻り」は、支援システム１００が作業内容を推定した際に自動検出した手戻りの発生箇所を示す。
【０１１０】
なお、図１０で示す手順概要はそのまま報告書の概要とすることも可能である。さらに図１０をコンテンツとして、報告書の定型のテンプレートへ入れ込むことで、報告書の下書きを作成することもできる。
【０１１１】
引継者が過去の分析プロジェクトを参照する際の第２ステップを説明する。上述した全体手順の概要の次に必要な第２ステップは、フローの修正内容を知ることである。そのために本実施例では、フローの修正内容の要約を積算して提示する機能を持つ。修正内容の要約を積算して提示する機能について説明する。前提として、上記で述べた処理フローのグループの算出と作業内容の推定は終了しているものとする。
【０１１２】
まず、支援システム１００は、修正内容の積算提示をするベースとなる情報のドメインを指定する。例えば、一つの分析プロジェクト全体とするのか、特定のグループ内とするのか、等である。
【０１１３】
支援システム１００は、指定したドメインの範囲での同じ作業内容の処理フローを全て集める。支援システム１００は、バージョン管理プログラム３０での履歴を用いて、集めた処理フローの修正履歴ごとに修正箇所がどこの処理ノードであるのかを積算し、積算修正履歴データを作成する。
【０１１４】
途中で新規に処理ノードを付け足した場合は、付け足した後からの集積とする。途中で処理ノードを減らした場合は、以後空白とする。順序を入れ替えた場合は、追跡不可能として、２つの新規ノードが付け加わったとしてもよい。バージョン管理プログラム３０の差分機能で追跡できた場合は、それぞれ元の積算を継続してもよい（実際にどちらが正しいかは入れ替えの内容によるため、誤差が生じることは止むを得ないとする）。
【０１１５】
図１１に、整理されたフロー修正情報Ｔ４の概要を示す。図１１では、「アルゴリズム検討」のフローに限定して、各処理ノードごとに列で整理し、変更のあった箇所と内容（パラメータ）を集積したイメージを示している。
【０１１６】
フロー修正情報Ｔ４は、例えば、修正日時を示す日時Ｔ４０と、修正対象を示すフローＴ４１と、修正内容の種別を示す作業内容Ｔ４２と、修正の具体的内容を示す処理ノード修正情報Ｔ４３とを含む。
【０１１７】
図１２に、フロー修正情報Ｔ４をＧＵＩ（Graphical User Interface）画面Ｇ３で提示する例を示す。
【０１１８】
画面Ｇ３では、その上段に手順概要が示される（Ｇ３０）。手順概要Ｇ３０では、上述のように、処理フローを象徴するアイコン３Ａが順に表示される。手順概要Ｇ３０のうちの任意の処理フローをクリックすると、その処理フローからポップアップする形で、フローの修正履歴の要約が表示される（Ｇ３１）。
【０１１９】
図１２の例では「アルゴリズム検討」のフローの詳細が示されている。それぞれの四角が処理ノードを象徴するアイコン４Ａである。処理ノードごとにさらにポップアップする形で、詳細メモＧ３２が表示される。詳細メモＧ３２には、例えば、修正率、修正箇所とその割合が表示される。引継者などのユーザは、詳細メモＧ３２を参照することで、まずどこの変更を試みるべきかを知ることができる。
【０１２０】
このように構成される本実施例によれば、支援システム１００は、プログラム操作履歴データとプログラム構成データとに基づいて、分析プロジェクトの作業手順を解析し、その要約を生成することができる。したがって、分析者であるユーザは、支援システム１００を利用することにより、引継資料を作成する手間を省略することができ、使い勝手が向上する。引継者であるユーザは、支援システム１００を利用することにより、過去に開発された分析プロジェクトの全体手順や修正箇所を容易に参照することができ、新プロジェクトの開発や既存プロジェクトの改善に役立てることができ、使い勝手が向上する。
【実施例２】
【０１２１】
図１３，図１４を用いて第２実施例を説明する。本実施例では、複数の分析プロジェクトを参照して活用する例につて述べる。
【０１２２】
分析者であるユーザが過去の分析プロジェクトを参照して現在の分析プロジェクトに対応する場合、第１実施例で述べた一つの分析プロジェクト内の概要と詳細を知ることは必要であるが、それと同時に複数の分析プロジェクトを比較することも必要である。その際、個別に分析プロジェクトを理解して参照するだけであれば、第１実施例で述べた手順で十分である。これに対し、複数の分析プロジェクトの内容を比較して、どの分析プロジェクトの方がより今回の事例に似ているか、類似の課題に対する解決方法のうちどの分析プロジェクトを参照すべきか等の比較を行いたい場合には、第１実施例の構成のみでは足りず追加手段が必要である。
【０１２３】
そこで、本実施例では、（１）複数分析プロジェクトの一覧機能、（２）分析プロジェクトの間の関連情報提提示機能、（３）処理フロー一覧機能、（４）処理フロー比較情報提供機能を実現する例を述べる。以下順に内容を説明する。
【０１２４】
複数分析プロジェクト一覧機能は、過去に関連した分析プロジェクトを検索して提示する機能である。ここで、分析プロジェクトの検索は、各分析プロジェクト中の処理フローの名称や処理ノードの出現頻度や、第１実施例で記入した修正理由やコメント等を検索対象とする。報告書等の付属ドキュメントがある場合は、それも全文検索対象とする。以上の対象からキーワード検索を行うことにより、ユーザは、関心のある分析プロジェクトの一覧を得ることができる。
【０１２５】
分析プロジェクト間の関連情報提示では、各分析プロジェクトが持つ処理フローの類似性を用いる。処理フローの類似度は、第１実施例の変化点を算出した際の乖離度を逆にして用いればよい。分析プロジェクト間の関連性としては、分析プロジェクト全体に含まれる全部のフローの類似度を用いた分析プロジェクト全体の類似性が算出できる。また、特に関連性の深い処理フローが含まれる場合には、部分的な処理に類似性があることを提示することも可能である。
【０１２６】
図１３に、グラフ表示した分析プロジェクト間関連性のイメージを示す。図中、実線（５１）が分析プロジェクトの内容全体の観点から類似性が高いと判断したものを示し、点線（５２）が一部の処理フローに強い類似性を持つものがあることを示す。
【０１２７】
矢印の向きは開発時期がより遅い方に向けている。遅い方が類似の案件で改良が施されていることが多いため、より優先的に参照するなどの利用が可能である。実線上の数字は、類似度（本例では1.0満点で規格化）を示す。点線上の数字は、関連が最も強い処理フローのみ考慮した部分類似度（同じく1.0満点で規格化）と、その関連の強いフローの作業内容とを示す。
【０１２８】
次に、処理フロー一覧機能は、複数の分析プロジェクトの処理フローを全て集めて、作業内容ごとに提示する機能である。但し、それぞれの処理フローがどのような機械のデータを対象とした分析案件であるのかは、処理フローによってばらばらであるため、処理フローの属性として、分析プロジェクトの対象や特徴などを追加情報として持つことが望ましい。それらの追加情報は、各分析プロジェクト中の報告書などのドキュメントのタイトルや要約のキーワードを抽出して、各処理フローの追加属性として持たせることで自動付加することが可能である。
【０１２９】
複数分析プロジェクト中の処理フローの比較情報提示機能について述べる。この機能は、類似の案件を通じて処理構築の手順がより洗練され、処理フロー自体も改良を加えられているような例で、どの処理フローをより参照すべきかの情報を提供するものである。その処理手順は「流用経歴」を追跡することで行う。その手順は以下のとおりである。まず、２つの分析プロジェクト中の同じ作業内容に属する処理フローを付きあわせて、全く同じものがあれば流用関係ありとする。時間順序から流用元と流用先を特定する。次に流用先とされた処理フローについて、同一グループ内でたどって変化点にあるフローを特定し、それを派生フローと位置づける。
【０１３０】
但し、特殊な例に流用して結果として改悪になったりしている場合も存在する。そのような場合のために、改良情報をユーザ提示の際に消去できる機能を持たせても良い。もし、幸いにも同一課題での比較を行った履歴を持っている場合には、信頼できる優劣情報として活用する。逆に同一課題での比較がされていない流用関係については、「要比較」タグを表示する機能を持たせて、かならずしも優劣が判明していない例として表示し、将来の比較を促すようにする。
【０１３１】
図１４に、処理フローの比較情報提示機能の表示画面Ｇ４の一例を示す。図１４の例では、画面Ｇ４を表形式で表示している。画面Ｇ４は、作業内容「特徴量選択」フローに限定して、各分析プロジェクトの処理フローを互いに比較する表で構成している。
【０１３２】
その他の表示方法として、ノードとアークを用いてグラフ状に表示してもよい。表では、各行の処理フローが、各列の処理フローに対してどのような関係、及び、優劣があるかを示す。例えば、第３行第１列（Ｇ４０）を説明する。これは、分析プロジェクトＣの特徴量選択フローは、分析プロジェクトＡの特徴量選択フローに対して、精度が10%向上し、速度が20%向上したエビデンスがあり、ユーザがそれを記入したことを示す。
【０１３３】
このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施例によれば、支援システム１００は、分析プロジェクトごとに作業手順の要約を生成し、分析プロジェクト間の類似性に基づいて分析プロジェクト間の関係性を算出することができるため、使い勝手がさらに向上する。
【０１３４】
さらに、本実施例では、分析プロジェクト間の関係性には、分析プロジェクト間で共通する作業内容に関わる処理プログラムの優劣に関する情報を含むことができ、使い勝手が向上する。
【０１３５】
なお、本発明は上記各実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記各実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
【０１３６】
また、上記の各構成、機能、処理部、および処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。  また、上記の各構成、機能、処理部、および処理手段等は、それらの一部又は全部を、例えば仮想マシンで設計する等によりクラウドシステムで実現してもよい。
【０１３７】
また、上記の各構成、および機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。  各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
【０１３８】
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【０１３９】
また、本発明の各構成要素は、任意に取捨選択することができ、取捨選択した構成を具備する発明も本発明に含まれる。さらに特許請求の範囲に記載された構成は、特許請求の範囲で明示している組合せ以外にも組み合わせることができる。
【０１４０】
上述した実施例を以下のように、分析プロジェクトの作業手順の解析を支援する分析プロジェクト用作業手順解析支援方法と表現することもできる。
【０１４１】
その支援方法は、分析プロジェクトに含まれる各処理プログラムの操作履歴であるプログラム操作履歴データを取得し、各処理プログラムの構成を示すプログラム構成データを取得し、プログラム操作履歴データとプログラム構成データとに基づいて、分析プロジェクトの作業手順の要約を生成する。
【符号の説明】
【０１４２】
１：データ分析プロジェクト、２：プロセス、３：処理フロー、４：処理ノード、１００：分析プロジェクト用作業手順解析支援システム、１１０：操作履歴データ取得部、１２０：処理フロー構成データ取得部、１３０：変化点抽出部、１４０：作業内容推定部、１５０：ユーザ確認部、１６０：作業手順解析部
【図１】
2018147198.tif 000003
【図２】
2018147198.tif 000004
【図３】
2018147198.tif 000005
【図４】
2018147198.tif 000006
【図５】
2018147198.tif 000007
【図６】
2018147198.tif 000008
【図７】
2018147198.tif 000009
【図８】
2018147198.tif 000010
【図９】
2018147198.tif 000011
【図１０】
2018147198.tif 000012
【図１１】
2018147198.tif 000013
【図１２】
2018147198.tif 000014
【図１３】
2018147198.tif 000015
【図１４】
2018147198.tif 000016