(57)【要約】【課題】本発明では、ソースプログラムファイルの差分を自動的に検出するファイル管理システムを提供する。【解決手段】第１サーバと第２サーバから構成されるファイル管理システムで、第１サーバで生成された第１プログラムファイルを第２サーバに送信して第２プログラムファイルとして動作させ、前記第１サーバは前記第１プログラムファイルを更新した第３プログラムファイルを生成し、第１サーバないし第２サーバが、第１プログラムファイルと第２プログラムファイルとを比較し、差分が無い場合は第２プログラムファイルを第３プログラムファイルに置き換え、差分が有る場合は第２プログラムファイルを第３プログラムファイルに置き換えない。【選択図】図６
2016009345.tif 000002
【特許請求の範囲】
【請求項１】
第１サーバと第２サーバから構成されるファイル管理システムであって、
前記ファイル管理システムは、
前記第１サーバで生成された第１プログラムファイルを、前記第２サーバに送信して第２プログラムファイルとして動作させ、
前記第１サーバは前記第１プログラムファイルを更新した第３プログラムファイルを生成し、
前記第１サーバが、前記第１プログラムファイルと前記第２プログラムファイルとを比較し、
前記第１プログラムファイルと前記第２プログラムファイルとの間に、差分が無い場合は、前記第２プログラムファイルを前記第３プログラムファイルに置き換え、
差分が有る場合は、前記第２プログラムファイルを前記第３プログラムファイルに置き換えない
ことを特徴とするファイル管理システム。
【請求項２】
請求項１記載のファイル管理システムであって、前記ファイル管理システムの前記第１サーバが第１表示部を備え、
前記第１サーバが前記第１表示部に、
前記第１プログラムファイルと前記第２プログラムファイルとの間に、差分が無い場合は、プログラムファイルを置き換える旨の表示を行い、
差分が有る場合は、プログラムファイルを置き換えない旨の表示を行う
ことを特徴とするファイル管理システム。
【請求項３】
請求項１記載のファイル管理システムであって、
前記第１サーバが、前記第１プログラムファイルと前記第２プログラムファイルとの間に差分が有る場合は、差分を前記第３プログラムファイルに反映した第４プログラムファイルを生成し、
前記第２サーバが、前記第４プログラムファイルを動作させて正常に動作するかを判断し、当該判断結果を前記第１サーバへ送信し、
前記判断結果が正常であれば、前記第４プログラムファイルを前記第３プログラムファイルに置き換え、
前記判断結果が異常であれば、前記第４プログラムファイルを前記第３プログラムファイルに置き換えない
ことを特徴とするファイル管理システム。
【請求項４】
請求項３記載のファイル管理システムであって、前記ファイル管理システムの前記第１サーバが第１表示部を備え、
前記第１サーバが前記第１表示部に、
前記判断結果が正常であれば、正常である旨と前記第２プログラムファイルを前記第４プログラムファイルで置き換える旨の表示を行い、
前記判断結果が異常であれば、異常である旨と前記第２プログラムファイルを前記第４プログラムファイルで置き換えない旨の表示を行う
ことを特徴とするファイル管理システム。
【請求項５】
請求項３記載のファイル管理システムであって、前記第１サーバが、
前記判断結果と前記第２サーバ動作で発生した問題履歴とを比較し、
前記判断結果が前記問題履歴に存在する場合、許容できる問題かを判断して許容できる場合に前記第２プログラムファイルを前記第４プログラムファイルで置き換え、
前記判断結果が前記問題履歴に存在しない場合、許容できる問題かを判断して許容できかを判断し、前記発生した問題内容と許容結果を前記問題履歴に追加し、
許容できる場合に前記第２プログラムファイルを前記第４プログラムファイルで置き換え、
許容できない場合に前記第２プログラムファイルを前記第４プログラムファイルで置き換えない
ことを特徴とするファイル管理システム。
【請求項６】
第１サーバと第２サーバから構成されるファイル管理システムのファイル管理方法であって、
前記ファイル管理システムは、
前記第１サーバで生成された第１プログラムファイルを、前記第２サーバに送信して第２プログラムファイルとして動作させ、
前記第１サーバは前記第１プログラムファイルを更新した第３プログラムファイルを生成し、
前記第１サーバないし前記第２サーバが、前記第１プログラムファイルと前記第２プログラムファイルとを比較し、
前記第１プログラムファイルと前記第２プログラムファイルとの間に、差分が無い場合は、前記第２プログラムファイルを前記第３プログラムファイルに置き換え、
差分が有る場合は、前記第２プログラムファイルを前記第３プログラムファイルに置き換えない
ことを特徴とするファイル管理システムのファイル管理方法。
【請求項７】
請求項１記載のファイル管理システムのファイル管理方法であって、前記ファイル管理システムの前記第１サーバが第１表示部を備え、
前記第１サーバが前記第１表示部に、
前記第１プログラムファイルと前記第２プログラムファイルとの間に、差分が無い場合は、プログラムファイルを置き換える旨の表示を行い、
差分が有る場合は、プログラムファイルを置き換えない旨の表示を行う
ことを特徴とするファイル管理システムのファイル管理方法。
【請求項８】
請求項１記載のファイル管理システムのファイル管理方法であって、
前記第１サーバが、前記第１プログラムファイルと前記第２プログラムファイルとの間に差分が有る場合は、差分を前記第３プログラムファイルに反映した第４プログラムファイルを生成し、
前記第２サーバが、前記第４プログラムファイルを動作させて正常に動作するかを判断し、当該判断結果を前記第１サーバへ送信し、
前記判断結果が正常であれば、前記第４プログラムファイルを前記第３プログラムファイルに置き換え、
前記判断結果が異常であれば、前記第４プログラムファイルを前記第３プログラムファイルに置き換えない
ことを特徴とするファイル管理システムのファイル管理方法。
【請求項９】
請求項３記載のファイル管理システムのファイル管理方法であって、前記ファイル管理システムの前記第１サーバが第１表示部を備え、
前記第１サーバが前記第１表示部に、
前記判断結果が正常であれば、正常である旨と前記第２プログラムファイルを前記第４プログラムファイルで置き換える旨の表示を行い、
前記判断結果が異常であれば、異常である旨と前記第２プログラムファイルを前記第４プログラムファイルで置き換えない旨の表示を行う
ことを特徴とするファイル管理システムのファイル管理方法。
【請求項１０】
請求項３記載のファイル管理システムのファイル管理方法であって、前記第１サーバが、
前記判断結果と前記第２サーバ動作で発生した問題履歴とを比較し、
前記判断結果が前記問題履歴に存在する場合、許容できる問題かを判断して許容できる場合に前記第２プログラムファイルを前記第４プログラムファイルで置き換え、
前記判断結果が前記問題履歴に存在しない場合、許容できる問題かを判断して許容できかを判断し、前記発生した問題内容と許容結果を前記問題履歴に追加し、
許容できる場合に前記第２プログラムファイルを前記第４プログラムファイルで置き換え、
許容できない場合に前記第２プログラムファイルを前記第４プログラムファイルで置き換えない
ことを特徴とするファイル管理システムのファイル管理方法。
【請求項１１】
第１サーバと第２サーバから構成されるファイル管理システムのファイル管理プログラムであって、
前記ファイル管理システムのファイル管理プログラムは、
前記第１サーバで生成された第１プログラムファイルを、前記第２サーバに送信して第２プログラムファイルとして動作させる機能と、
前記第１サーバは前記第１プログラムファイルを更新した第３プログラムファイルを生成する機能と、
前記第１サーバないし前記第２サーバが、前記第１プログラムファイルと前記第２プログラムファイルとを比較する機能と、
前記第１プログラムファイルと前記第２プログラムファイルとの間に、差分が無い場合は、前記第２プログラムファイルを前記第３プログラムファイルに置き換える機能と、
差分が有る場合は、前記第２プログラムファイルを前記第３プログラムファイルに置き換えない機能とを有する
ことを特徴とするファイル管理システムのファイル管理プログラム。
【請求項１２】
請求項１１記載のファイル管理システムのファイル管理プログラムであって、
前記第１サーバが、前記第１プログラムファイルと前記第２プログラムファイルとの間に差分が有る場合は、差分を前記第３プログラムファイルに反映した第４プログラムファイルを生成する機能と、
前記第２サーバが、前記第４プログラムファイルを動作させて正常に動作するかを判断する機能と、
前記判断結果を前記第１サーバへ送信する機能と、
前記判断結果が正常であれば、前記第４プログラムファイルを前記第３プログラムファイルに置き換える機能と、
前記判断結果が異常であれば、前記第４プログラムファイルを前記第３プログラムファイルに置き換えない機能とを有する
ことを特徴とするファイル管理システムのファイル管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイル管理システム、ファイル管理方法及びファイル管理プログラムに関する。
【背景技術】
【０００２】
大規模なシステム開発には、数多くのプログラムの開発が必要となる。また、プログラム開発には多数のプログラマーが関わり、プログラマーそれぞれがソースプログラムを開発する。そして、開発したソースプログラムを組み合わせて最終的な実行プログラムを完成させる。各プログラマーによるプログラムへの変更が矛盾なく行われるためには、開発中のプログラムの変更履歴を管理する必要があり、管理履歴をサーバ等の記憶領域に格納するシステムが知られている。
【０００３】
また、どのようなシステムでも、プログラムの変更作業は必ず発生する。例えば、保守点検等で不具合を発見し、その不具合対策用のソースプログラムを作成し、元のプログラムを更新する。また、新機能の追加時も、ソースプログラムを変更する。プログラム更新に関する技術として、例えば、特許文献１がある。特許文献１の技術は、サーバが、クライアント上にアプリケーションの最新のバージョンが存在しているかを確認し、最新のバージョンがクライアント上に存在しない場合は、そのアプリケーションの最新のバージョンを含むアーカイブファイルをダウンロードしインストール（更新）するものである。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】日本公開特許２００３−１６２４１５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来技術では、最新バージョンのアプリケーションソフトウェアがクライアント上に存在しない場合、つまり差分が有る場合でも自動的に、最新バージョンのアプリケーションソフトウェアで既存のアプリケーションソフトウェアを書き換えてしまう。
【０００６】
しかしながら、プログラムの使用環境でＳＥ（システムエンジニア）等が、プログラムに不具合（バグ）を発見し、その修正をソースプログラムファイルに対して行うこともある。そのため、使用環境側で使用されているソースプログラムファイルと、開発側（ソースプログラム提供側）で開発され管理されているソースプログラムファイルとが、相違することがある。
【０００７】
また、不具合の内容によっては、例えば、特定画面での一部表示不良等の軽微な不具合では１本のソースプログラムファイル当たりの修正量は少ないが、非常に多数（数百本以上）のソースプログラムファイルを修正・変更するケースもある。そのため、非常に多数（数百本以上）のソースプログラムファイルが、使用環境側と開発側とで相違する可能性もある。
【０００８】
この相違を解消するには、１本ずつのソースプログラムファイルを比較し、相違が存在するか否かを判断する必要がある。更に、相違があったソースプログラムファイルのどの箇所にどのような相違があるかを判断しなければならない。このような複雑な作業を現地側（使用環境）で使用される全てのソースプログラムファイルに対して、開発側（開発環境）でのソースプログラムファイルと比較して、相違有無の確認と相違内容の把握を行う必要があり、その作業量は莫大で作業時間も非常に大きい。また、人手による確認であるので、確認漏れなどのミスも必ず発生する。このことが、システムを運用する上での致命的な障害を発生させる要因となる。ここでの致命的な障害とは、システムダウン、管理データの一部損失または完全損失、各種情報の格納不可があるが、これは障害の一部であり、想定されない障害が発生する可能性もある。
【０００９】
そこで、本発明の目的は、ソースプログラムファイルの差分を機械的に把握でき確認漏れ等の人的なミスを低減できるファイル管理システムを提供することにある。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明の一実施形態であるファイル管理システムは、第１サーバと第２サーバから構成され、第１サーバで生成された第１プログラムファイルを第２サーバに送信して第２プログラムファイルとして動作させ、前記第１サーバは前記第１プログラムファイルを更新した第３プログラムファイルを生成し、第１サーバないし第２サーバが、第１プログラムファイルと第２プログラムファイルとを比較し、差分が無い場合は第２プログラムファイルを第３プログラムファイルに置き換え、差分が有る場合は第２プログラムファイルを第３プログラムファイルに置き換えない。
【発明の効果】
【００１１】
本発明では、ソースプログラムファイルの差分を機械的に把握できるので、確認漏れ等の人的なミスを低減できる。また、数多くのソースファイルの差分を短時間で抽出でき、差分の箇所も迅速に把握できる。更に、使用環境側での修正内容を、開発側で修正したソースファイルに適用した場合の問題発生の有無も把握できる。加えて、発生した問題の履歴を累積することで、問題抽出精度が向上する。効率化を実現できる。なお、前述以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【００１２】
【図１】図１は、本発明の一実施形態であるファイル管理システムの全体構成を示すブロック図である。
【図２】図２は、サーバの内部構成を示すブロック図である。
【図３】図３は、開発用サーバに格納するプログラム及びデータの構成例を示す図である。
【図４】図４は、ソースファイルの履歴を示すソースファイル履歴テーブルの構成例である。
【図５】図５は、ファイル管理プログラムの構造を示す図である。
【図６】図６は、ファイル管理における第１の処理を示すフローチャートである。
【図７】図７は、ファイル管理における第２の処理を示すフローチャートである。
【図８】図８は、ファイル管理における第３の処理を示すフローチャートである。
【発明を実施するための形態】
【００１３】
以下、図面を参照しながら実施の形態を説明する。なお、以下の説明では、「管理テーブル」等の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。また、データ構造に依存しないことを示すために「管理テーブル」を「管理情報」と呼ぶことができる。
【００１４】
また、「プログラム」を主語として処理を説明する場合がある。そのプログラムは、プロセッサ、例えば、ＭＰ（Ｍｉｃｒｏ  Ｐｒｏｃｅｓｓｏｒ）やＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）によって実行されるもので、定められた処理をするものである。なお、適宜に記憶資源（例えばメモリ）及び通信インターフェース装置（例えば、通信ポート）を用いながら行うため、処理の主語がプロセッサとされてもよい。プロセッサは、ＣＰＵの他に専用ハードウェアを有していても良い。コンピュータプログラムは、プログラムソースから各コンピュータにインストールされても良い。プログラムソースは、例えば、プログラム配布サーバ又は記憶メディアなどで提供されるものであっても良い。
【００１５】
また、各要素、例えば、コントローラは番号などで識別可能であるが、識別可能な情報であれば、名前など他種の識別情報が用いられても良い。本実施例の図及び説明において同一部分には同一符号を付与しているが、本発明が本実施例に制限されることは無く、本発明の思想に合致するあらゆる応用例が本発明の技術的範囲に含まれる。また、特に限定しない限り、各構成要素は複数でも単数でも構わない。
【００１６】
＜ファイル管理システム全体構成＞
図１は、本発明の一実施形態であるファイル管理システムの全体構成を示すブロック図である。発明のユースケースとして、病院でのファイル管理システム１を挙げる。
【００１７】
ファイル管理システム１は、Ａ病院本院２１ａ／Ａ病院Ｂ分院２１ｂ／Ａ病院Ｃ分院  ２１ｃ／Ａ病院Ｄ分院２１ｄを通信で接続するネットワーク２５、Ｗ病院２２／Ｙ病院２３／Ｚ病院２４を通信で接続するネットワーク２６、各病院で使用されるプログラムを開発する開発サイドの開発センタ２０を備える。
【００１８】
病院、例えば、Ａ病院本院２１ａ（以下、病院２１ａと略す）には、医師や看護師などが電子カルテを使用するための端末４、患者情報や治療記録を管理するための管理サーバ２１２、端末４−管理サーバ２１２間ないしネットワーク２５と通信で接続する通信装置２１１を備える。
【００１９】
開発センタ２０には、開発用サーバ３と、開発用サーバ３がネットワーク２５／２６と通信で接続するための通信装置２０１を備える。
【００２０】
前述の電子カルテを管理・制御する電子カルテプログラムや、患者情報や治療記録を管理する管理プログラムのソースプログラムファイルは開発センタ２０で開発され、ソースプログラムファイル毎のバージョンやリビジョンも管理されるのが一般的である。しかしながら、プログラムの使用環境、すなわち、現地の病院２１ａにおいてＳＥ（システムエンジニア）等が、プログラムに不具合（バグ）を発見し、その修正を現地の病院２１ａで使用しているソースプログラムファイルそのものに対して行うこともある。そのため、病院２１ａ側（使用環境）で使用されているソースプログラムファイルと、開発側（開発センタ）で開発され管理されているソースプログラムファイルとが、相違することがある。また、不具合の内容によっては、例えば、特定画面での一部表示不良等の軽微な不具合でも、１本のソースプログラムファイル当たりの修正量は少ないが、非常に多数（数百本以上）のソースプログラムファイルを現地の病院２１ａで、修正・変更するケースもある。そのため、非常に多数（数百本以上）のソースプログラムファイルが、病院２１ａ側（使用環境）での使用されているものと、開発センタ２０側（開発環境）で管理されているものが相違する可能性が大きい。
【００２１】
この相違を解消するには、１本ずつのソースプログラムファイルを比較し、相違が存在するか否かを判断する必要がある。更に、相違があったソースプログラムファイルのどの箇所にどのような相違があるかを判断しなければならない。このような複雑な作業を現地の病院２１ａ側で使用される全てのソースプログラムファイルに対して、相違有無の確認と相違内容の把握を行う必要があり、その作業量は莫大で作業時間を非常に大きい。また、人手による確認であるので、確認漏れなどのミスも必ず発生する。このことが、システムを運用する上での致命的な障害を発生させる要因となる。ここでの致命的な障害とは、システムダウン、管理データの一部損失または完全損失、治療記録などの情報の格納不可などである。
【００２２】
本発明の一実施形態では、相違が存在するソースプログラムファイルの特定を短時間で効率的に行えるシステムと方法を提供する。以下の説明では、ソースプログラムファイルをソースファイルと呼ぶことがある。
【００２３】
＜サーバ内部構成＞
図２は、サーバの内部構成を示すブロック図である。病院２１ａ側の端末４／管理サーバ２１２、開発センタ２０側の開発用サーバ３は、ＣＰＵ３１、メモリ３２、記憶部３３、入力部３４、出力部３５、表示部３６、通信部３７の構成要素を備える。
【００２４】
ＣＰＵ３１は、装置全体を制御するプロセッサである。メモリ３２は、各種プログラム及び後述する各種データ（テーブル）などを一時的に記憶するデバイスである。記憶部３３は、各種プログラム及び後述する各種データなどを恒久的に記憶するデバイスで、例えばＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）やＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）である。入力部３４は、入力を受け付けるデバイスで、例えば、キーボードである。
【００２５】
出力部３５は、情報やデータを出力するデバイスで、例えば、スピーカやプリンタである。表示部３６は、情報やデータを表示するデバイスで、例えば、液晶ディスプレイである。通信部３７は、ネットワーク（図示せず）を介し他のサーバや他の装置との間を接続するデバイスである。以上の構成要素は内部バスで相互に接続される。なお、入力部３４、出力部３５、表示部３６のいずれかの構成要素を各装置に備えない構成とすることもできる。
【００２６】
＜プログラム・データ構成＞
図３は、開発用サーバに格納するプログラム及びデータの構成例を示す図である。
【００２７】
開発用サーバ３のメモリ３２には、オペレーティングシステム（ＯＳ）３２１、通信プログラム３２２、ファイル管理プログラム３２３、ファイル更新プログラム３２４が格納される。オペレーティングシステム（ＯＳ）３２１は、アプリケーションプログラムなどのソフトウェアを動作させるための基本的な制御ソフトウェアである。通信プログラム３２２は、開発用サーバ３と他のサーバや端末との通信を制御するプログラムである。ファイル管理プログラム３２３は、ソースファイルプログラムのファイル名や作成日、更新日、サイズ、バージョン、リビジョンなどを管理するプログラムである。ファイル更新プログラム３２４は、ソースファイルプログラムを更新するためのプログラムで、更新内容やリビジョン変更等の情報をファイル管理プログラム３２３に伝える。
【００２８】
開発用サーバ３の記憶部３３には、開発ソースファイル（改修前）３３１、開発ソースファイル（改修後）３３２、現地使用ソースファイル３３３、開発ソースファイル（現地更新適用版）３３４、問題解析結果ファイル３３５、過去問題発生履歴ファイル３３６が格納される。開発ソースファイル（改修前）３３１は、発見された不具合を解消する前の開発ソースファイルで、改修後に新たな不具合が発見された場合に、改修されたソースファイルを元の状態に戻すためのソースファイルである。開発ソースファイル（改修後）３３２は、発見された不具合を解消するために改修した開発ソースファイルである。
【００２９】
現地使用ソースファイル３３３は、現地（病院２１ａ側）で使用されている最新ソースファイルである。開発ソースファイル（現地更新適用版）３３４は、現地（病院２１ａ側）で不具合を解消するために現地で更新した内容を適用したソースファイルである。問題解析結果ファイル３３５は、発生した不具合を解析した結果であり、解析結果（問題発生日時、問題種別、問題内容等）を管理するファイルである。その解析結果をプログラマーが判断し許容できる問題か致命的な問題かを判断し、その判断結果も含めプログラム実行上の不具合として過去問題発生履歴ファイル３３６に格納し蓄積する。このように、過去問題発生履歴ファイル３３６は、過去に発生したプログラム実行上の不具合を纏めたファイルである。
【００３０】
＜ソースファイル履歴テーブル＞
図４は、ソースファイルの履歴を示すソースファイル履歴テーブルの構成例である。
【００３１】
図４（１）は、開発ソースファイル（改修前）３３１と、現地使用ソースファイル３３３との間に「相違がない（差分なし）」場合である。つまり、開発ソースファイル（改修前）３３１のファイル内容と現地使用ソースファイル３３３のファイル内容は、完全に一致している場合である。
【００３２】
図４（２）は、開発ソースファイル（改修前）３３１と、現地使用ソースファイル３３３との間に「相違がある（差分あり）」場合である。つまり、開発ソースファイル（改修前）３３１のファイル内容に対して、現地使用ソースファイル３３３のファイル内容に相違があり、差分が発生している。
【００３３】
本例では、ソースファイルとして、“００００１．ｓｃｒｐｔ”、“００００２．ｓｃｒｐｔ”、“００００３．ｓｃｒｐｔ”、“００００４．ｓｃｒｐｔ”の４つのファイルが存在する例を示している。それぞれのファイルには、ファイル作成（更新）日時（例えば、“２０１２／０１／０１  ０：００：００”）と、ファイルサイズ（例えば、“１２０ＫＢ”）が格納される。このファイル作成（更新）日時ないしファイルサイズを、ファイル管理プログラム３２３が比較することで差分の有無を判断することができる。
【００３４】
この４つのソースファイルの中で、現地使用ソースファイル３３３のソースファイル“００００２．ｓｃｒｐｔ”が、開発ソースファイル（改修前）３３１のソースファイル“００００２．ｓｃｒｐｔ”との間に差分がある。つまり、開発ソースファイル（改修前）３３１におけるソースファイル“００００２．ｓｃｒｐｔ”のファイル作成（更新）日時は“２０１２／０１／０１  ０：００：００”で、ファイルサイズは“１４５ＫＢ”である。それに対し、現地使用ソースファイル３３３におけるソースファイル“００００２．ｓｃｒｐｔ”のファイル作成（更新）日時は“２０１３／０２／０１  ０：００：００”で、ファイルサイズは“１５１ＫＢ”である。この２つのファイルのファイル名は同じであるが、内容は異なり差分が発生している。
【００３５】
＜ファイル管理プログラム構造＞
図５は、ファイル管理プログラムの構造を示す図である。ファイル管理プログラム３２３は、入力機能部３２３１、比較機能部３２３２、更新機能部３２３３、異常検知・処理終了機能部３２３４から構成される。
【００３６】
入力機能部３２３１は、現地環境（病院２１ａ）の管理サーバ２１２に開発部門提供の開発ソースファイル（改修前）３３１と開発ソースファイル（改修後）３３２を格納する機能部である。
比較機能部３２３２は、現地使用ソースファイル３３３と業務システム開発部門提供の開発ソースファイル（改修前）３３１を比較する機能部である。
更新機能部３２３３は、比較機能部３２３２での比較で差分が発生しなかった場合に、開発ソースファイル（改修後）３３２を現地使用ソースファイル３３３に適用する機能部である。つまり、現在、使用環境（病院２１ａ）で使用している現地使用ソースファイル３３３を開発ソースファイル（改修後）３３２で置き換える。
異常検知・処理終了機能部３２３４は、差分が発生した場合に処理を中止する機能部である。
【００３７】
このファイル管理プログラム３２３が、開発部門提供の開発ソースファイル（改修前）３３１と、使用環境（病院２１ａ）で使用している現地使用ソースファイル３３３とを比較することで、差分を検出できる。また、ファイル管理プログラム３２３が比較することで、人的なミス（確認漏れ）がなくなる。また、ファイル管理プログラム３２３は高速なサーバ上で動作するため比較処理を高速に実行できる。そのため、比較すべきソースファイルが多数存在しても、短い処理時間で比較を完了することができる。
【００３８】
＜ファイル管理の第１処理＞
図６は、ファイル管理における第１の処理を示すフローチャートである。本処理は、差分を検出する処理である。なお、本処理を使用環境側（病院２１ａ）で行ってもよいし、開発側（開発センタ２０）で行ってもよい。本例では、使用環境側（病院２１ａ）で行うものとする。また、処理の主体をサーバ２１２のＣＰＵ３１として説明するが、サーバ２１２本体（ないし、開発環境（開発センタ２０）では、サーバ３本体）でもよい。更に、ＣＰＵ３１上で動作するファイル管理プログラム３２３でもよい。
【００３９】
Ｓ６００で、ＣＰＵ３１は、処理を開始する。Ｓ６０１（入力）で、ＣＰＵ３１は、現地環境（病院２１ａ）の管理サーバ２１２に開発部門提供の開発ソースファイル（改修前）３３１と開発ソースファイル（改修後）３３２を格納する。
【００４０】
Ｓ６０２（比較）で、ＣＰＵ３１は、現地使用ソースファイル３３３と業務システム開発部門提供の開発ソースファイル（改修前）３３１を比較する。Ｓ６０３（判断）で、ＣＰＵ３１は、現地使用ソースファイル３３３と開発ソースファイル（改修前）３３１とが完全に一致するかを判断する。一致していると判断した場合（Ｙｅｓ）、ＣＰＵ３１はＳ６０４を、不一致（一致しない）と判断した場合（Ｎｏ）はＳ６０５を実行する。
【００４１】
Ｓ６０４（更新）で、ＣＰＵ３１は、差分が発生しなかった場合に改修後ソースファイル３３２を現地環境に適用する。つまり、ＣＰＵ３１は、現地使用ソースファイル３３３を開発ソースファイル（改修後）３３２で置き換える（更新する）。そして、処理を終了する。Ｓ６０５（異常終了）で、ＣＰＵ３１は、差分が発生した場合、即座に処理を中止する。
【００４２】
以上の処理で、開発ソースファイル（改修前）３３１に対し、差分が発生している現地使用ソースファイル３３３を特定できる。そのため、差分が発生していないソースファイルだけを、開発ソースファイル（改修後）３３２で更新できる。また、差分が発生している現地使用ソースファイル３３３を特定できるので、現地使用ソースファイル３３３の開発ソースファイル（改修後）３３２に対する修正部分を解析することも可能となる。
【００４３】
＜ファイル管理の第２処理＞
図７は、ファイル管理における第２の処理を示すフローチャートである。本処理は、差分を検出し、差分ソースファイルに改修後ソースファイルの適用可否を判断する処理である。なお、本処理を使用環境側（病院２１ａ）で行ってもよいし、開発側（開発センタ２０）で行ってもよい。本例では、使用環境側（病院２１ａ）で行うものとする。また、処理の主体をサーバ２１２のＣＰＵ３１として説明するが、サーバ２１２本体（ないし、開発環境（開発センタ２０）では、サーバ３本体）でもよい。更に、ＣＰＵ３１上で動作するファイル管理プログラム３２３ないしファイル更新プログラム３２４でもよい。
【００４４】
Ｓ７００で、ＣＰＵ３１は、処理を開始する。Ｓ７０１（差分抽出）で、ＣＰＵ３１は、現地使用ソースファイル３３３と開発ソースファイル（改修前）３３１とを比較して、差分を抽出する。
【００４５】
Ｓ７０２（改修ソースへ差分パッチ）で、ＣＰＵ３１は、抽出した差分ソース部分を開発ソースファイル（改修後）３３２に適用し更新する。Ｓ７０３（動作確認）で、ＣＰＵ３１は、差分適用した開発ソースファイル（改修後）３３２で動作を確認する。
【００４６】
Ｓ７０４で、ＣＰＵ３１は、動作に問題が有るかを判断する。動作に問題が有る場合（Ｙｅｓ）、ＣＰＵ３１はＳ７０６を実行し、問題が無い場合（Ｎｏ）、Ｓ７０５を実行する。  Ｓ７０５（格納・使用）で、ＣＰＵ３１は、動作に問題が発生しない場合差分適用した改修後ソースを現地環境で使用する。そして、ＣＰＵ３１は、正常終了を表示部３６に表示してファイル管理者に報告する。Ｓ７０６（異常終了）で、ＣＰＵ３１は、動作に問題が発生した場合、差分適用を中止する。そして、ＣＰＵ３１は、異常終了を表示部３６に表示してファイル管理者に警告する。
【００４７】
以上のように、現地での修正内容（ソースファイルの更新部分）を開発部門が改修した開発ソースファイル（改修後）３３２に適用し問題ないかを確認することで、自動的に開発ソースファイル（改修後）３３２へ現地での修正内容を追加できる。そのため、ソースファイルの修正工数を低減でき、開発期間も短縮できるという効果がある。
【００４８】
＜ファイル管理の第２処理＞
図８は、ファイル管理における第３の処理を示すフローチャートである。本処理は、
（１）差分の検出
（２）差分ソースファイルに改修後ソースファイルの適用可否の判断
（３）問題発生履歴の蓄積
（４）許容できる問題か否かの判断
を行い、差分適用の可否を判断する処理である。なお、本処理を使用環境側（病院２１ａ）で行ってもよいし、開発側（開発センタ２０）で行ってもよい。本例では、使用環境側（病院２１ａ）で行うものとする。また、処理の主体をサーバ２１２のＣＰＵ３１として説明するが、サーバ２１２本体（ないし、開発環境（開発センタ２０）では、サーバ３本体）でもよい。更に、ＣＰＵ３１上で動作するファイル管理プログラム３２３ないしファイル更新プログラム３２４でもよい。
【００４９】
Ｓ８００で、ＣＰＵ３１は、処理を開始する。Ｓ８０１（差分抽出）で、ＣＰＵ３１は、現地使用ソースファイル３３３と開発ソースファイル（改修前）３３１とを比較して、差分を抽出する。本処理はＳ７０１と同じである。
【００５０】
Ｓ８０２（改修ソースへ差分パッチ）で、ＣＰＵ３１は、抽出した差分ソース部分を開発ソースファイル（改修後）３３２に適用し更新する。本処理はＳ７０２と同じである。  Ｓ８０３（動作確認）で、ＣＰＵ３１は、差分適用した開発ソースファイル（改修後）３３２で動作を確認する。本処理はＳ７０３と同じである。
【００５１】
Ｓ８０４（問題判断）で、ＣＰＵ３１は、動作に問題が有るかを判断する。動作に問題が有る場合（Ｙｅｓ）、ＣＰＵ３１はＳ８０６を実行し、問題が無い場合（Ｎｏ）、Ｓ８０５を実行する。Ｓ８０５（格納・使用）で、ＣＰＵ３１は、差分適用した改修後ソースを現地環境で使用する。そして、ＣＰＵ３１は、正常終了を表示部３６に表示してファイル管理者に報告する。正常終了を報告する。
【００５２】
Ｓ８０６（異常検知）で、ＣＰＵ３１は、異常検知時、差分適用を一旦中止し、異常終了を表示部３６に表示してファイル管理者に警告する。そして、ＣＰＵ３１は、問題を解析して内容を把握する。ＣＰＵ３１は、問題解析結果（問題解析結果ファイル３３５）を記憶部３３に格納する。Ｓ８０７（過去問題履歴の取得）で、ＣＰＵ３１は、過去に発生した問題履歴（過去発生問題履歴ファイル３３６）を記憶部３３から取得する。
【００５３】
Ｓ８０８（過去発生問題判断）で、ＣＰＵ３１は、今回発生した問題が過去に発生した問題かを判断する。判断方法は、過去に発生した問題履歴の中の項目（エラー名）やエラー種別（致命的なエラー、単純エラー、警告レベル、無視可能レベルなど）など）に、今回発生した問題が該当する項目が含まれているかをＣＰＵ３１が判断する。なお、この過去に発生した問題履歴が、発生した問題が許容できるかの判定基準となる。また、この判定基準は、開発者（プログラマーなど）が最初に設定し、適宜、開発者（プログラマーなど）により追加されると共に、本処理で問題が発生する度に判定基準（過去発生問題履歴ファイル３３６）が更新されていく。過去に発生した問題であれば（Ｙｅｓ）、ＣＰＵ３１はＳ８０９を実行し、過去に発生していない問題であれば（Ｎｏ）、Ｓ８１０を実行する。
【００５４】
Ｓ８０９（許容判断）で、ＣＰＵ３１は、許容できる問題かを判断する。その判断方法は、前述のエラー種別で判断する。例えば、エラー種別が“致命的なエラー”であれば、ＣＰＵ３１は許容できない問題が発生したと判断する。また、エラー種別が“警告レベル”または“無視可能レベル”であれば、ＣＰＵ３１は許容できる問題であると判断する。許容できる問題であれば（Ｙｅｓ）、ＣＰＵ３１はＳ８１０を実行し、許容できない問題であれば（Ｎｏ）、Ｓ８１４を実行する。
【００５５】
Ｓ８１０（問題の解析結果取得）で、ＣＰＵ３１は、発生した問題の内容を表示部３６に表示する。解析者（開発者であるプログラマーや、品質保証部員など）が、発生した問題の内容を解析し、問題に対するエラー名やエラー種別を定義する。解析者は、定義された解析結果を入力部３４で入力し、ＣＰＵ３１がその入力結果（問題解析結果）を取得する。
【００５６】
Ｓ８１１（許容判断）で、ＣＰＵ３１は、許容できる問題かをＳ８１０で取得した問題解析結果（エラー種別）で判断する。許容できる問題であれば（Ｙｅｓ）、ＣＰＵ３１はＳ８１２を実行し、許容できない問題であれば（Ｎｏ）、Ｓ８１３を実行する。Ｓ８１２（問題履歴更新）で、ＣＰＵ３１は、問題の解析結果で問題履歴を更新する。Ｓ８１３の処理はＳ８１２の処理と同じである。Ｓ８１４（差分適用中止）で、ＣＰＵ３１は、致命的な問題なため、差分適用を中止し異常終了を表示部３６に表示してファイル管理者に警告する。
【００５７】
以上の処理で、問題発生履歴を積み上げていくことで、問題抽出精度の向上と問題解決時間の短縮が図れる。
【００５８】
以上説明したように、本発明の実施形態では、
（ｅ１）ソースファイルの差分を機械的に把握できるので、確認漏れ等の人的なミスを低減できる。
（ｅ２）数多くのソースファイルの差分を短時間で抽出できる。
（ｅ３）差分の箇所も迅速に把握できる。
（ｅ４）使用環境側での修正内容を、開発側で修正したソースファイルに適用した場合の問題発生の有無も把握できる。
（ｅ５）発生した問題の履歴を累積することで、問題抽出精度が向上する。
という効果がある。
【００５９】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。また、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。
【００６０】
各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置いてもよい。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【００６１】
１：ファイル管理システム
３：開発用サーバ
４：端末
２０、２７：データセンタ（開発側）
２１：病院（ユーザ側）
２５、２６：ネットワーク
３１：ＣＰＵ
３２：メモリ
３３：記憶部
３４：入力部
３５：出力部
３６：表示部
３７：通信部
２０１、２１１：通信装置
２１２：管理サーバ
３２１：オペレーティングシステム（ＯＳ）
３２２：通信プログラム
３２３：ファイル管理プログラム
３２４：ファイル更新プログラム
３３１：開発ソースファイル（改修前）
３３２：開発ソースファイル（改修後）
３３３：現地使用ソースファイル
３３４：開発ソースファイル（現地更新適用版）
３３５：問題解析結果ファイル
３３６：過去発生問題履歴ファイル
３２３１：入力機能部
３２３２：比較機能部
３２３３：更新機能部  
３２３４：異常検知・処理終了機能部
【図１】
2016009345.tif 000003
【図２】
2016009345.tif 000004
【図３】
2016009345.tif 000005
【図４】
2016009345.tif 000006
【図５】
2016009345.tif 000007
【図６】
2016009345.tif 000008
【図７】
2016009345.tif 000009
【図８】
2016009345.tif 000010