JP2012079259A - 更新管理装置、更新管理方法および更新管理プログラム - Google Patents

Abstract

【課題】複数の種類のデータを含むデータ集合の版数管理を容易にする。
【解決手段】検出手段１ｂは、記憶手段１ａに格納されたデータ集合２ａの中の１またはそれ以上の種類のデータの更新を検出する。管理手段１ｃは、検出結果に応じて、複数の種類に対応する複数の部分を含む記号列３ａを生成し、データ集合２ａの版数を示す情報として記憶手段１ａに格納する。管理手段１ｃは、更新前の版数を示す記号列３から、複数の部分のうち更新が検出されたデータの種類に対応する部分の記号Ｑ１を記号Ｑ２に変更し、更新後の版数を示す記号列３ａとする。
【選択図】図１

Description

本発明は、データの更新を管理する更新管理装置、更新管理方法および更新管理プログラムに関する。

情報処理システムでは、ユーザの業務の進行に伴って、記憶装置に格納されたデータが繰り返し更新される場合がある。そこで、データの更新状況を効率的に管理するために、リビジョン管理システムが利用されることがある。リビジョン管理は、バージョン管理や版数管理と呼ばれることもある。リビジョン管理システムは、データの更新日時や更新内容などの更新履歴を保持し、過去のある時点のデータを確認できるようにする。

リビジョン管理システムは、複数のユーザが共有データを更新する場合に用いられることもある。例えば、プロジェクトに関するデータを複数人で共有するために、リビジョン管理の機能をもつプロジェクト管理システムが利用されることがある。プロジェクト管理システムに関し、修正されたファイルを登録する際、当該ファイルの修正版数を更新し、修正内容を示す差分情報と修正版数とを対応付けて記憶するものが提案されている。

なお、ファイル管理装置に関し、ファイルを更新する際、当該ファイルの変更量が所定の基準限度を超えるときは、新規なベースファイルとして指定されるように、変更量が基準限度を超えないときは、差分情報として利用されるように、更新後のファイルを管理するものが提案されている。

特開２００４−１３９５８８号公報（段落［００４５］） 特開平６−１８７２０６号公報（段落［００１２］）

ところで、データを管理する場合、個々のデータの単位ではなく、複数の種類のデータを含むデータ集合の単位で、更新状況を管理したい場合がある。例えば、プロジェクト管理では、プロジェクトのスケジュールを記載した文書やプロジェクトで作成された成果物など、複数の種類のデータを管理することがある。その場合、プロジェクトに関するデータ全体の更新状況を一括して把握したいということが考えられる。

しかし、複数の種類のデータを含むデータ集合の版数をどのように管理するかが問題となる。例えば、ユーザが明示的にデータ集合に版数を付与する方法では、ユーザの作業負担が大きい、版数の定義ミスが生じやすいといった問題が生じる。また、版数を示す整数（例えば、１，２，３，…）をデータ集合に付与し、データ集合に含まれる何れかのデータが更新される毎に整数を機械的にインクリメントしていく方法では、複数の種類のデータの間の関係を把握するのが容易でないという問題がある。

本発明はこのような点に鑑みてなされたものであり、複数の種類のデータを含むデータ集合の版数管理を容易にする更新管理装置、更新管理方法および更新管理プログラムを提供することを目的とする。

上記課題を解決するために、複数の種類のデータを含むデータ集合の更新を管理する更新管理装置が提供される。更新管理装置は、検出手段と管理手段を有する。検出手段は、記憶装置に格納されたデータ集合の中の１またはそれ以上の種類のデータの更新を検出する。管理手段は、検出結果に応じて、複数の種類に対応する複数の部分を含む記号列を生成し、データ集合の版数を示す情報として記憶装置に格納する。管理手段は、更新前の版数を示す記号列から、複数の部分のうち更新が検出されたデータの種類に対応する部分の記号を変更し、更新後の版数を示す記号列とする。

また、上記課題を解決するために、複数の種類のデータを含むデータ集合の更新を管理するコンピュータによって実行される更新管理方法が提供される。更新管理方法では、記憶装置に格納されたデータ集合の中の１またはそれ以上の種類のデータの更新を検出する。検出結果に応じて、複数の種類に対応する複数の部分を含む記号列を生成し、データ集合の版数を示す情報として記憶装置に格納する。記号列の生成では、更新前の版数を示す記号列から、複数の部分のうち更新が検出されたデータの種類に対応する部分の記号を変更し、更新後の版数を示す記号列とする。また、上記課題を解決するために、更新管理方法をコンピュータに実行させる更新管理プログラムが提供される。

上記更新管理装置、更新管理方法および更新管理プログラムによれば、複数の種類のデータを含むデータ集合の版数管理が容易となる。

第１の実施の形態の更新管理装置を示す図である。 第２の実施の形態のプロジェクト管理システムを示す図である。 プロジェクト管理装置のハードウェア構成を示す図である。 プロジェクト管理装置の機能を示すブロック図である。 プロセスデータのデータ構造例を示す図である。 タスクデータのデータ構造例を示す図である。 成果物データの具体例を示す図である。 リビジョン管理テーブルのデータ構造例を示す図である。 更新ログテーブルのデータ構造例を示す図である。 リポジトリのディレクトリ構造例を示す図である。 制御テーブルのデータ構造例を示す図である。 バックアップ処理を示すフローチャートである。 バックアップデータ抽出処理を示すフローチャートである。 リビジョン番号選択画面の例を示す図である。

以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の更新管理装置を示す図である。更新管理装置１は、複数の種類のデータの更新を管理する。更新管理装置１は、記憶手段１ａ、検出手段１ｂおよび管理手段１ｃを有する。

記憶手段１ａは、複数の種類のデータを含むデータ集合２を記憶する。データ集合２には、複数の種類（図１の例では、３種類）のデータＡ１，Ｂ１，Ｃ１が含まれる。また、記憶手段１ａは、データ集合２の版数を示す記号列３を記憶する。記号列３には、複数の種類に対応する複数の部分（図１の例では、記号Ｐ１，Ｑ１，Ｒ１に相当する部分）が含まれる。図１において、記号Ｐ１はデータＡ１に対応し、記号Ｑ１はデータＢ１に対応し、記号Ｒ１はデータＣ１に対応している。記号Ｐ１，Ｑ１，Ｒ１は、数字でもよい。

なお、記憶手段１ａは、更新管理装置１の外部の記憶装置であってもよい。例えば、記憶手段１ａは、更新管理装置１が接続されたネットワーク上のデータベース装置により実現されてもよい。

検出手段１ｂは、記憶手段１ａに格納されたデータ集合２ａの中の１またはそれ以上の種類のデータの更新を検出する。更新を検出するタイミングは、記憶手段１ａにデータが書き込まれた後でもよいし、データが書き込まれる前（例えば、データ書き込み命令が入力された時点）でもよい。

管理手段１ｃは、検出手段１ｂの検出結果に応じて、複数の種類に対応する複数の部分を含む記号列３ａを生成し、データ集合２ａの版数を示す情報として記憶手段１ａに格納する。このとき、管理手段１ｃは、更新前の版数を示す記号列３から、複数の部分のうち更新が検出されたデータの種類に対応する部分の記号を変更し、更新後の版数を示す記号列３ａとする。２以上の種類のデータの更新が検出された場合、２以上の部分の記号を同時に変更してもよい。また、複数の部分のうち更新が検出されなかったデータの種類に対応する部分の記号は、変更しなくてもよい。

例えば、検出手段１ｂは、データ集合２ａについて、データ集合２に含まれるデータＢ１がデータＢ２に更新されたことを検出する。すると、管理手段１ｃは、記号列３に含まれる記号Ｐ１，Ｑ１，Ｒ１のうち更新が検出されたデータＢ２に対応する部分の記号Ｑ１を記号Ｑ２に変更し、記号列３ａを得る。記号Ｐ１，Ｑ１，Ｒ１のうち更新が検出されなかったデータＡ１，Ｃ１に対応する部分の記号Ｐ１，Ｒ１は変更しなくてもよい。その場合、記号列３ａは、記号Ｐ１，Ｑ２，Ｒ１を含むことになる。

更新管理装置１によれば、検出手段１ｂにより、記憶手段１ａに格納されたデータ集合２の中の１またはそれ以上の種類のデータの更新が検出される。管理手段１ｃにより、検出結果に応じて、複数の種類に対応する複数の部分を含む記号列３ａが生成され、データ集合２ａの版数を示す情報として記憶手段１ａに格納される。このとき、管理手段１ｃにより、更新前の版数を示す記号列３から、複数の部分のうち更新が検出されたデータの種類に対応する部分の記号が変更され、更新後の版数を示す記号列３ａとされる。

これにより、複数の種類のデータを含むデータ集合の版数管理が容易となる。具体的には、記号列３，３ａを確認すれば、それぞれの時点で、データ集合２，２ａに含まれる各種類のデータがどの程度まで更新されていたかを容易に把握できる。例えば、記号列３ａを確認すれば、データＡ１，Ｂ１，Ｃ１のうちデータＡ１，Ｃ１は更新されておらずデータＢ１がデータＢ２に更新されている、という時点が存在することを把握することができる。このため、過去のある時点における複数の種類のデータのレビューなどが容易になる。

なお、検出手段１ｂは、更新の検出時、各種類のデータが更新の前後でどの程度変更されたかを表す指標（変更量）を算出してもよい。変更量としては、例えば、更新前後でのデータサイズの変化割合や、更新前後での文字数または行数の変化割合などを用いることができる。管理手段１ｃは、検出手段１ｂで算出された変更量が所定の基準値より大きい場合に記号列３ａを生成し、変更量が基準値より大きくない場合に記号列３ａを生成しないようにしてもよい。これにより、変更量が大きい場合に限定して、データ集合２の版数が変更されるようにすることができる。

以下に説明する第２の実施の形態では、更新管理装置１をシステム開発プロジェクトの管理を支援するプロジェクト管理システムに適用した場合の例を説明する。ただし、第１の実施の形態の更新管理装置１は、プロジェクト管理システム以外の情報処理システム、例えば、ファイルサーバなどに適用することもできる。

［第２の実施の形態］
図２は、第２の実施の形態のプロジェクト管理システムを示す図である。第２の実施の形態に係るプロジェクト管理システムは、システム開発を行うプロジェクトの管理を支援する。第２の実施の形態のプロジェクト管理システムは、端末装置２１，２２，２３およびプロジェクト管理装置１００を含む。端末装置２１，２２，２３およびプロジェクト管理装置１００は、ネットワーク１０に接続されている。

端末装置２１，２２，２３は、システム開発エンジニアなどのプロジェクトの参加者が操作するコンピュータである。端末装置２１，２２，２３のユーザは、端末装置２１，２２，２３を用いてデータの作成や更新などの作業を行う。

プロジェクト管理装置１００は、プロジェクトの進捗状況の管理を支援するサーバコンピュータである。プロジェクト管理装置１００は、プロジェクトに関する情報（プロジェクト情報）を保持するリポジトリを有する。プロジェクト情報は、複数の種類のデータを含むデータ集合である。プロジェクト情報には、以下の３種類のデータが含まれる。

（１）第１の種類のデータは、プロセスデータである。プロセスデータは、プロジェクトの工程（プロセス）を示すデータである。プロセスは、複数の作業単位（タスク）を含む。プロセスデータには、例えば、複数のタスクの実行順序および各タスクの実行予定日を示すレコードが含まれる。

（２）第２の種類のデータは、タスクデータである。タスクデータは、プロセスに含まれる複数のタスクそれぞれの具体的な内容に関するデータである。タスクデータには、例えば、各タスクの進捗状況を示すレコードが含まれる。

（３）第３の種類のデータは、成果物データである。成果物データは、タスクの実行の過程で成果物として得られるデータである。成果物データの中には、タスクの途中で作成されるものもあるし、タスクの完了時点で作成されるものもある。また、作成された成果物データは、同一または異なるタスクの中で更新されることもある。例えば、「設計」というタスクでは、成果物データとして設計書のデータが作成されることが考えられる。「見積」というタスクでは、見積書のデータが作成されることが考えられる。

ユーザは、端末装置２１，２２，２３を操作して、プロジェクト管理装置１００に格納されたプロジェクト情報を閲覧および更新できる。プロジェクト管理装置１００は、プロジェクト情報を一元管理することで、効率的にプロジェクト管理を行えるよう支援する。

図３は、プロジェクト管理装置のハードウェア構成を示す図である。プロジェクト管理装置１００は、ＣＰＵ（Central Processing Unit）１０１、ＲＯＭ（Read Only Memory）１０２、ＲＡＭ（Random Access Memory）１０３、ＨＤＤ（Hard Disk Drive）１０４、グラフィック処理装置１０５、入力インタフェース１０６、記録媒体読取装置１０７および通信インタフェース１０８を有する。

ＣＰＵ１０１は、ＯＳ（Operating System）プログラムやアプリケーションプログラムを実行して、プロジェクト管理装置１００全体を制御する。
ＲＯＭ１０２は、プロジェクト管理装置１００の起動時に実行されるＢＩＯＳ（Basic Input / Output System）プログラムなどの所定のプログラムを記憶する。ＲＯＭ１０２は、書き換え可能な不揮発性メモリであってもよい。

ＲＡＭ１０３は、ＣＰＵ１０１が実行するＯＳプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０３は、ＣＰＵ１０１の処理に用いられるデータの少なくとも一部を一時的に記憶する。

ＨＤＤ１０４は、ＯＳプログラムやアプリケーションプログラムを記憶する。また、ＨＤＤ１０４は、ＣＰＵ１０１の処理に用いられるデータを記憶する。なお、ＨＤＤ１０４に代えて（または、ＨＤＤ１０４と併せて）、ＳＳＤ（Solid State Drive）など他の種類の不揮発性の記憶装置を用いてもよい。

グラフィック処理装置１０５は、モニタ１１に接続される。グラフィック処理装置１０５は、ＣＰＵ１０１からの命令に従って、画像をモニタ１１に表示させる。
入力インタフェース１０６は、キーボード１２やマウス１３などの入力デバイスに接続される。入力インタフェース１０６は、入力デバイスから送られる入力信号をＣＰＵ１０１に出力する。

記録媒体読取装置１０７は、記録媒体１４に記憶されたデータを読み取る読取装置である。記録媒体１４には、例えば、プロジェクト管理装置１００に実行させるプログラムが記録されている。プロジェクト管理装置１００は、例えば、記録媒体１４に記録されたプロジェクト管理プログラムを実行することで、後述するようなプロジェクト管理機能を実現することができる。すなわち、プロジェクト管理の処理内容を記述したプログラムは、コンピュータ読み取り可能な記録媒体１４に記録して配布することが可能である。

記録媒体１４としては、例えば、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリを使用できる。磁気記録装置には、ＨＤＤ、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−Ｒ／ＲＷ／ＲＡＭなどがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。半導体メモリには、ＵＳＢ（Universal Serial Bus）メモリなどのフラッシュメモリがある。

通信インタフェース１０８は、ネットワーク１０に接続される。通信インタフェース１０８は、ネットワーク１０を介して端末装置２１，２２，２３とデータ通信を行える。
なお、ネットワーク１０に接続された他のサーバ装置（図示せず）にプロジェクト管理プログラムを格納しておいてもよい。その場合、プロジェクト管理装置１００は、当該サーバ装置からプログラムをダウンロードして実行することもできる。端末装置２１，２２，２３もプロジェクト管理装置１００と同様のハードウェア構成により実現できる。

図４は、プロジェクト管理装置の機能を示すブロック図である。プロジェクト管理装置１００は、リポジトリ１１０、制御データ記憶部１２０、更新部１３０、変更量算出部１４０、リビジョン管理部１５０、データ管理部１６０、抽出部１７０および表示処理部１８０を有する。これらのユニットの機能は、ＣＰＵ１０１がプロジェクト管理プログラムを実行することにより、プロジェクト管理装置１００上に実現される。ただし、これらのユニットの機能の全部または一部を専用のハードウェアで実装してもよい。

リポジトリ１１０は、プロジェクト情報を記憶する記憶領域（例えば、ＲＡＭ１０３またはＨＤＤ１０４に確保された領域）である。プロジェクト情報には、前述の通り、プロセスデータ、タスクデータおよび成果物データが含まれる。プロジェクト情報は、プロジェクトの進行に伴って更新される。リポジトリ１１０は、最新のプロジェクト情報に加えて、各版のプロジェクト情報のバックアップデータを、リビジョン番号を付与して管理する。リビジョン番号は、プロジェクト情報全体の版数を表す記号列である。リポジトリ１１０は、リビジョン番号の一覧を示すリビジョン管理テーブルを記憶する。

制御データ記憶部１２０は、制御データを記憶する。制御データは、変更量算出部１４０、リビジョン管理部１５０およびデータ管理部１６０の動作を設定するための設定データである。

更新部１３０は、端末装置２１，２２，２３からチェックインのコマンドを受け付け、リポジトリ１１０に格納されたプロジェクト情報を更新する。チェックインでは、端末装置２１，２２，２３がプロジェクト管理装置１００に、新規データの追加や既存データの更新を依頼する。端末装置２１，２２，２３は、端末装置２１，２２，２３上で作成・編集されたデータについてユーザがチェックインの操作を行うと、チェックインのコマンドをプロジェクト管理装置１００に送信する。更新部１３０は、受け付けたチェックインのコマンドに基づいて、リポジトリ１１０へのデータの追加やリポジトリ１１０に格納されたデータの上書きなど、プロジェクト情報の更新を行う。また、更新部１３０は、プロジェクト情報の更新を行うと、変更量算出部１４０にその旨を通知する。

変更量算出部１４０は、更新部１３０からプロジェクト情報の更新を行った旨の通知を受けると、３種類のデータのうち何れの種類のデータが更新されたか検出する。また、変更量算出部１４０は、最新のバックアップデータと更新後のデータとを比較し、データの変更量を算出する。そして、算出した変更量に基づいて、リビジョン番号を変更するか否か判定する。リビジョン番号を変更すると判定した場合、変更量算出部１４０は、更新されたデータの種類をリビジョン管理部１５０に通知し、変化量をデータ管理部１６０に通知する。

リビジョン管理部１５０は、変更量算出部１４０から更新されたデータの種類が通知されると、リポジトリ１１０に格納されているリビジョン管理テーブルを参照し、最新のリビジョン番号を確認する。そして、最新のリビジョン番号の中の更新されたデータに対応する部分を特定し、特定した部分の記号を変更した新たなリビジョン番号を生成する。リビジョン管理部１５０は、生成したリビジョン番号をデータ管理部１６０に通知する。

データ管理部１６０は、データの変更量に応じた方法で、プロジェクト情報のバックアップを行う。具体的には、データ管理部１６０は、変更量算出部１４０から通知された変更量に応じて、完全バックアップまたは差分バックアップを選択し、更新後のプロジェクト情報についてのバックアップデータを作成する。そして、リビジョン管理部１５０から通知されたリビジョン番号と作成したバックアップデータとを対応付けて、リポジトリ１１０に格納する。その際、リビジョン管理テーブルを更新する。

抽出部１７０は、端末装置２１，２２，２３からチェックアウトのコマンドを受け付け、リポジトリ１１０に格納されたプロジェクト情報を抽出する。チェックアウトでは、端末装置２１，２２，２３がプロジェクト管理装置１００に、最新または特定のリビジョン番号のプロジェクト情報の抽出を依頼する。端末装置２１，２２，２３は、ユーザがチェックアウトの操作を行うと、チェックアウトのコマンドをプロジェクト管理装置１００に送信する。抽出部１７０は、受け付けたコマンドに基づいて、最新または指定されたリビジョン番号のプロジェクト情報を、リポジトリ１１０から抽出する。

表示処理部１８０は、ユーザがチェックアウトの操作を行うためのＧＵＩ（Graphical User Interface）を、端末装置２１，２２，２３に提供する。例えば、表示処理部１８０は、リポジトリ１１０に格納されたリビジョン管理テーブルからリビジョン番号の一覧を取得し、リビジョン番号を選択するための画面のデータを端末装置２１，２２，２３に送信する。ユーザは、例えば、端末装置２１，２２，２３のモニタに表示された操作画面を見て入力デバイスを操作し、抽出するプロジェクト情報のリビジョン番号を選択することができる。また、表示処理部１８０は、ユーザのチェックアウト操作に応じて、プロセスデータなどのデータを表示した画面を提供してもよい。

なお、端末装置２１，２２，２３は、チェックアウトによりプロジェクト管理装置１００から取得したデータをユーザに提示することができる。ユーザは、取得されたデータを更新し、更新後のデータについてチェックイン操作を行うことも可能である。

次に、プロセスデータ、タスクデータおよび成果物データのバックアップデータについて説明する。リポジトリ１１０は、バックアップデータをデータの種類毎に管理する。各種類のバックアップデータには、プロジェクト情報全体のリビジョンを示すリビジョン番号とは別に、各種類内でのリビジョンを示す（すなわち、各種類内でバックアップデータの作成された順序を示す）リビジョンＩＤが付与される。

図５は、プロセスデータのデータ構造例を示す図である。プロセスデータ１１１，１１１ａ，１１１ｂ，・・・は、リポジトリ１１０に格納される。プロセスデータ１１１，１１１ａ，１１１ｂ，・・・は、プロセスデータの各リビジョンのバックアップデータである。プロセスデータ１１１は、最も古いリビジョン（リビジョンＩＤ＝ｖ１）のデータである。プロセスデータ１１１ａは、ｖ１の次のリビジョン（ｖ２）のデータであり、プロセスデータ１１１ｂは、ｖ２の次のリビジョン（ｖ３）のデータである。なお、以下の説明では、プロセスデータ１１１のデータ構造例を説明するが、プロセスデータ１１１ａ，１１１ｂ，・・・のデータ構造もプロセスデータ１１１と同様である。

プロセスデータ１１１には、タスクＩＤ、タスク名、開始予定日および終了予定日の項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、プロセスデータの１つのレコードを構成する。タスクＩＤの項目には、タスクを識別するための識別情報が設定される。タスク名の項目には、タスクの名称が設定される。開始予定日の項目には、タスクの開始予定日が設定される。終了予定日の項目には、タスクの終了予定日が設定される。

例えば、プロセスデータ１１１には、タスクＩＤが“１”、タスク名が“設計工程”、開始予定日が“２０１０／１／１”、終了予定日が“２０１０／１／５”というレコードが記録される。これは、設計工程はプロセスの最初に実行するタスクであり、開始予定日が２０１０年１月１日、終了予定日が２０１０年１月５日であることを示している。

図６は、タスクデータのデータ構造例を示す図である。タスクデータ１１２，１１２ａ，１１２ｂ，・・・は、リポジトリ１１０に格納される。タスクデータ１１２，１１２ａ，１１２ｂ，・・・は、タスクデータの各リビジョンのバックアップデータである。タスクデータ１１２は、最も古いリビジョン（リビジョンＩＤ＝ｖ１）のデータである。タスクデータ１１２ａは、ｖ１の次のリビジョン（ｖ２）のデータであり、タスクデータ１１２ｂは、ｖ２の次のリビジョン（ｖ３）のデータである。なお、以下の説明では、タスクデータ１１２のデータ構造例を説明するが、タスクデータ１１２ａ，１１２ｂ，・・・のデータ構造もタスクデータ１１２と同様である。

タスクデータ１１２には、タスクＩＤ、作業内容およびタスク属性の項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのタスクの具体的な内容を示す。タスクＩＤの項目には、タスクを識別するための識別情報が設定される。作業内容の項目には、タスクの具体的な作業内容を示すテキストが設定される。タスク属性の項目には、タスクの進捗実績を示す情報が設定される。タスク属性には、例えば、タスクの実際の開始日、現在の進捗率、タスクの実際の終了日などが含まれる。

例えば、タスクデータ１１２には、タスクＩＤが“１”、タスク名が“仕様書作成”、開始日が“２０１０／１／３”、進捗率が“３０％”、終了日が“−”（未設定）というレコードが記録される。これは、設計工程の作業内容は“設計書作成”であり、２０１０年１月３日に開始され、予定作業量の３０％まで作業が進んでいることを示している。

図７は、成果物データの具体例を示す図である。成果物データ１１３，１１３ａ，１１４，１１４ａ，・・・は、リポジトリ１１０に格納される。成果物データ１１３，１１３ａ，１１４，１１４ａ，・・・は、成果物データ（例えば、文書ファイル）の各リビジョンのバックアップデータである。成果物データ１１３，１１４は、最も古いリビジョン（リビジョンＩＤ＝ｖ１）のデータである。成果物データ１１３ａ，１１４ａは、ｖ１の次のリビジョン（ｖ２）のデータである。

成果物データ１１３，１１３ａは、仕様を記載した仕様書ファイルである。成果物データ１１３のファイル名は“仕様書ｖ１．ｄａｔ”であり、成果物データ１１３ａのファイル名は“仕様書ｖ２．ｄａｔ”である。設計書ファイル１１４，１１４ａは、設計内容を記載した設計書ファイルである。成果物データ１１４のファイル名は“設計書ｖ１．ｄａｔ”であり、成果物データ１１４ａのファイル名は“設計書ｖ２．ｄａｔ”である。

図８は、リビジョン管理テーブルのデータ構造例を示す図である。リビジョン管理テーブル１１５は、リポジトリ１１０に格納される。リビジョン管理テーブル１１５には、リビジョン番号、親番号および保存日時の項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つのリビジョンに関する情報を構成する。

リビジョン番号の項目には、プロジェクト情報全体のリビジョンを示すリビジョン番号が設定される。親番号の項目には、リビジョン番号の項目が示すリビジョンの１つ前のリビジョンに付与されていたリビジョン番号が設定される。保存日時の項目には、新たなリビジョン番号が付与されてバックアップデータが作成された日時が設定される。

ここで、リビジョン番号は、“ｘ．ｙ．ｚ”のように３桁の値を含む。“．（ピリオド）”は、各桁を区切るための区切り記号である。“ｘ”を１桁目、“ｙ”を２桁目、“ｚ”を３桁目とする（すなわち、１桁目を最上位桁、３桁目を最下位桁とする）。第１桁（ｘ）はプロセスデータのリビジョンＩＤに対応し、第２桁（ｙ）はタスクデータのリビジョンＩＤに対応し、第３桁（ｚ）は成果物データのリビジョンＩＤに対応する。

例えば、リビジョン管理テーブル１１５には、リビジョン番号が“１．０．０”、親番号が“−”（未設定）、保存日時が“２０１０／１／１ １０：００”というレコードが記録される。これは、プロジェクト情報に対して最初のリビジョン番号が２０１０年１月１日１０時００分に付与されたことを示している。また、このとき、リポジトリ１１０にプロセスデータが登録され、タスクデータおよび成果物データは未登録であることを示している。なお、下位の桁の“０”を省略して表記してもよい。例えば、“１．０．０”を“１”と表記してもよい。

また、例えば、リビジョン管理テーブル１１５には、リビジョン番号が“１．１．０”、親番号が“１．０．０”、保存日時が“２０１０／１／２ １０：００”というレコードが記録される。これは、プロジェクト情報に対して、“１．０．０”の次のリビジョン番号として、“１．１．０”が２０１０年１月２日１０時００分に付与されたことを示している。また、このとき、プロセスデータは前リビジョンから変更がなく（または、変更量が小さく）、リポジトリ１１０にタスクデータが登録され、成果物データは未登録であることを示している。なお、上記のように、下位の桁の“０”を省略して、“１．０．０”を“１．１”と表記してもよい。

更に、例えば、リビジョン管理テーブル１１５には、リビジョン番号が“１．２．０”、親番号が“１．１．０”、保存日時が“２０１０／１／３ １０：００”というレコードが記録される。これは、プロジェクト情報に対して、“１．１．０”の次のリビジョン番号として、“１．２．０”が２０１０年１月３日１０時００分に付与されたことを示している。また、このとき、プロセスデータは前リビジョンから変更がなく（または、変更量が小さく）、前リビジョンからタスクデータが更新され、成果物データは未登録であることを示している。

更に、例えば、リビジョン管理テーブル１１５には、リビジョン番号が“１．３．１”、親番号が“１．２．０”、保存日時が“２０１０／１／５ １０：００”というレコードが記録される。これは、プロジェクト情報に対して、“１．２．０”の次のリビジョン番号として、“１．３．１”が２０１０年１月５日１０時００分に付与されたことを示している。また、このとき、プロセスデータは前リビジョンから変更がなく（または、変更量が小さく）、前リビジョンからタスクデータが更新され、リポジトリ１１０に成果物データが登録されたことを示している。

なお、リビジョン番号のフォーマットは、上記形式に限らず種々の形式を採用することができる。例えば、各桁の値（ｘ，ｙ，ｚ）は、１０進数ではなく２進数・８進数・１６進数などで表記してもよい。また、例えば単調増加させるものではなく、単調減少させるものでもよい。更に多くの種類のデータを扱う場合には、３よりも多くの桁数を設けてもよい。また、プロジェクト責任者の操作により、桁数を増減できるようにしてもよい。また、上記説明では各桁を区切る区切り記号（例えば、ピリオド）を用いたが、他の方法により各桁を識別可能としてもよい。例えば、各桁で表現すべき数値の上限を予め予測し、各桁の字数を固定してもよい。例えば、３種類のデータそれぞれのリビジョンを４文字で表現する（すなわち、リビジョン番号全体を１２文字とする）と定義しておけば、区切り記号を使用せず、“０００１０００２０００３”といったフォーマットで表現できる。

図９は、更新ログテーブルのデータ構造例を示す図である。更新ログテーブル１１６，１１６ａ，１１６ｂは、データ管理部１６０がデータの種類毎に生成してリポジトリ１１０に格納する。更新ログテーブル１１６は、プロセスデータの更新ログを記録したテーブルであり、更新ログテーブル１１６ａは、タスクデータの更新ログを記録したテーブルであり、更新ログテーブル１１６ｂは、成果物データの更新ログを記録したテーブルである。なお、以下の説明では、更新ログテーブル１１６のデータ構造例を説明するが、更新ログテーブル１１６ａ，１１６ｂのデータ構造も更新ログテーブル１１６と同様である。

更新ログテーブル１１６には、リビジョンＩＤ、方式およびファイル名の項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、プロセスデータの１つのリビジョンについての情報を構成する。リビジョンＩＤの項目には、プロセスデータのリビジョンを示すＩＤが設定される。方式の項目には、バックアップが完全バックアップであるか差分バックアップであるかを示す情報（“完全”または“差分”）が設定される。ファイル名の項目には、バックアップデータのファイル名が設定される。

例えば、更新ログテーブル１１６には、リビジョンＩＤが“ｖ１”、方式が“完全”、ファイル名が“プロセスｖ１．ｄａｔ”という情報が設定される。これは、リビジョン“ｖ１”のプロセスデータが、完全バックアップとしてバックアップされ、“プロセスｖ１．ｄａｔ”としてリポジトリ１１０に保存されていることを示している。なお、リビジョンＩＤ＝ｖ１は、プロジェクト情報全体のリビジョン番号の第１桁の“１”に対応する。

また、例えば、更新ログテーブル１１６には、リビジョンＩＤが“ｖ２”、方式が“差分“、ファイル名が“プロセスｖ２．ｄａｔ”という情報が設定される。これは、リビジョン“ｖ２”のプロセスデータが、差分バックアップとしてバックアップされ、“プロセスｖ２．ｄａｔ”としてリポジトリ１１０に保存されていることを示している。なお、リビジョンＩＤ＝ｖ２は、リビジョン番号の第１桁の“２”に対応する。

ここで、プロセスデータの差分バックアップでは、直前のリビジョンのプロセスデータからの差分がバックアップデータに記録される。すなわち、“プロセスｖ２．ｄａｔ”には、直前のリビジョン(ｖ１)のバックアップデータである“プロセスｖ１．ｄａｔ”からの差分が記録されている。これに対し、完全バックアップでは、プロセスデータ全体がバックアップデータに記録される。すなわち、“プロセスｖ１．ｄａｔ”には、プロセスデータ全体が記録されている。

なお、完全バックアップと差分バックアップの何れを選択するかは、データの種類毎に決定することが可能である。すなわち、複数の種類のデータを同時にバックアップする場合、プロセスデータのバックアップが完全か差分か、タスクデータのバックアップが完全か差分か、成果物データのバックアップが完全か差分か、はそれぞれ独立に選択できる。そして、データの種類毎に、完全バックアップまたは差分バックアップが実行される。

また、データの種類によって、データが１つのファイルに纏めて記録される場合と、複数のファイルに分散して記録される場合とが有り得る。例えば、プロセスデータとタスクデータは、それぞれ１つのファイルに記録しておくことが考えられる。一方、成果物データは、複数のファイル（例えば、仕様書ファイルと設計書ファイル）の集合であることが考えられる。ここで、前者と後者とではバックアップの具体的な方法が異なってもよい。

例えば、前者の種類のデータについては、完全バックアップでは１つのファイル全体をコピーし、差分バックアップではファイルに記載された内容の差分を算出して差分を示すデータを生成する方法が考えられる。一方、後者の種類のデータについては、完全バックアップでは全てのファイルをコピーし、差分バックアップでは複数のファイルのうち更新されたファイルをコピーする方法が考えられる。例えば、仕様書ファイルのみが更新された場合、完全バックアップでは仕様書ファイルと設計ファイルの両方をコピーし、差分バックアップでは更新された仕様書ファイルのみをコピーすることが考えられる。ただし、後者の種類のデータの差分バックアップでも、前者の種類の差分バックアップと同様に、ファイルに記載された内容の差分を算出して差分を示すデータを生成してもよい。

図１０は、リポジトリのディレクトリ構造例を示す図である。リポジトリ１１０は、バックアップデータを管理するため、図１０に示すような階層構造を有するディレクトリ５０，５１，５１ａ，５１ｂ，５１ｃを保持する。

ディレクトリ５０は、ルートディレクトリである。ディレクトリ５１は、ディレクトリ５０の配下のディレクトリであり、“ｄａｔ”という名前が付与されている。ディレクトリ５１ａ，５１ｂ，５１ｃは、ディレクトリ５１の配下のディレクトリであり、それぞれ“ｐｒｏｃｅｓｓ”，“ｔａｓｋ”，“ｒｅｓｕｌｔ”という名前が付与されている。また、ディレクトリ５１には、リビジョン管理テーブル１１５が格納されている。

ディレクトリ５１ａは、プロセスデータ１１１，１１１ａ，・・・とプロセスデータに関する更新ログテーブル１１６とを格納する。ディレクトリ５１ｂは、タスクデータ１１２，１１２ａ，・・・とタスクデータに関する更新ログテーブル１１６ａとを格納する。ディレクトリ５１ｃは、成果物データ１１３，１１３ａ，１１４，１１４ａ・・・と成果物データに関する更新ログテーブル１１６ｂとを格納する。

図１１は、制御テーブルのデータ構造例を示す図である。制御テーブル１２１は、制御データ記憶部１２０に格納される。制御テーブル１２１には、項番、ルール名および条件の項目が設けられている。各項目の横方向に並べられた情報同士が互いに関連付けられて、１つの制御ルールを示す情報を構成する。

項番の項目には、制御ルールのレコードを識別するための番号が設定される。ルール名の項目には、どの様な処理に関する判定ルールであるかを示す名称が設定される。条件の項目には、判定ルールの具体的な内容が設定される。

例えば、制御テーブル１２１には、項番が“１”、ルール名が“リビジョン更新判定ルール”、条件が“前回リビジョン更新から変更量３０％以上”というレコードが記録される。これは、更新後のプロジェクト情報に新たなリビジョン番号を付与してバックアップを行うか否かを判定するためのルールである。そして、前リビジョンからの変更量が３０％以上である場合に新たなリビジョン番号を付与する（すなわち、変更量が３０％未満であれば新たなリビジョン番号を付与しない）ことを示している。

また、例えば、制御テーブル１２１には、項番が“２”、ルール名が“バックアップ取得判定ルール”、条件が“変更量が５０％以上では完全バックアップ、変更量が５０％未満では差分バックアップ”というレコードが記録される。これは、完全バックアップと差分バックアップの何れを実行するか判定するためのルールである。そして、データの種類毎に、前リビジョンからの変更量が５０％以上か否かによって、何れのバックアップ方法を選択するか判定することを示している。変更量が５０％以上の場合、完全バックアップが実行され、変更量が５０％未満の場合、差分バックアップが実行される。

ここで、リビジョン更新判定ルールは、変更量算出部１４０により参照される。変更量算出部１４０は、データの種類毎に、リポジトリ１１０に格納された更新前後のデータを比較して変更量を算出することで、リビジョン更新判定ルールに従った判定を行う。変更量を算出する方法として、例えば、次のような方法が考えられる。

（１）プロセスデータでは、タスク数の増加・減少や予定日の変更が発生し得る。そこで、変更量算出部１４０は、更新前後のプロセスデータの間で変更があったレコードの数をカウントすることで、変更量を算出する方法が考えられる。例えば、更新後のプロセスデータに含まれる全レコードのうち、更新前のプロセスデータと同一のものが存在しないレコード（更新または追加されたレコード）の割合を算出することが考えられる。そして、上記の項番“１”の判定ルールに従えば、変更量算出部１４０は、算出した割合が３０％以上であるか否かの判定を行う。

（２）タスクデータでは、作業内容およびタスク属性の追記・修正が発生し得る。そこで、変更量算出部１４０は、タスクデータに含まれる全項目（作業内容・開始日・進捗率・終了日など）のうち、更新前のタスクデータから変更があった項目の割合を算出することが考えられる。そして、上記の項番“１”の判定ルールに従えば、変更量算出部１４０は、算出した割合が３０％以上であるか否かの判定を行う。

（３）成果物データでは、文章や図面などのデータを含むファイルの追加やファイルの内容の修正が発生し得る。そこで、変更量算出部１４０は、更新前の成果物データからのデータサイズの変更量を算出する方法が考えられる。また、更新前後のファイルの内容を分析し、文章の文字数や行数の変更量を算出する方法も考えられる。そして、上記の項番“１”の判定ルールに従えば、変更量算出部１４０は、算出した数量が更新前の成果物データの数量（データサイズ・文字数・行数など）全体の何パーセントに相当するか算出して、算出した割合が３０％以上であるか否かの判定を行う。

また、バックアップ取得判定ルールは、データ管理部１６０により参照される。データ管理部１６０は、データの種類毎に、変更量算出部１４０が算出した変更量を用いてバックアップ取得判定ルールに従った判定を行う。上記の項番“２”の判定ルールに従えば、データ管理部１６０は、変更量が５０％以上の場合には完全バックアップを選択し、変更量が５０％未満の場合には差分バックアップを選択する。

なお、図１１に示した判定ルールは一例であり、プロジェクト責任者は、制御テーブル１２１を更新することで、判定ルールを変更できる。例えば、リビジョン更新判定ルールの閾値を小さくすることで、短い時間間隔でリビジョン番号が更新され、プロジェクト情報の更新状況を細かく管理できるようになる。一方、リビジョン更新判定ルールの閾値を大きくすることで、バックアップが実行される時間間隔を長くでき、リポジトリ１１０の記憶領域を節約することができる。

また、リビジョン更新判定ルールでは、データの種類毎に閾値を変えてもよい。例えば、プロセスデータについては、更新量に拘わらずバックアップを実行する、という条件を設定してもよい。また、バックアップ取得判定ルールでは、経過期間やバックアップ回数に基づいて判定するようにしてもよい。例えば、前回完全バックアップを実行してから１ヶ月以上経過していれば、変更量に拘わらず完全バックアップを実行する、という条件を設定してもよい。また、差分バックアップを５回連続で実行した後は、変更量に拘わらず完全バックアップを実行する、という条件を設定してもよい。

同じ種類のルールとして複数の条件が設定された場合、これら複数の条件はＯＲ（論理和）として適用することが考えられる。例えば、バックアップ取得判定ルールとして、図１１に示した変更量基準、上記の経過期間基準およびバックアップ回数基準の３つの条件が規定されている場合、データ管理部１６０は、何れか１つの条件に合致すれば完全バックアップを実行すると判定するようにしてもよい。

次に、プロジェクト管理装置１００で実行されるバックアップ処理を説明する。
図１２は、バックアップ処理を示すフローチャートである。以下、図１２に示す処理をステップ番号に沿って説明する。

（ステップＳ１１）更新部１３０は、端末装置２１，２２，２３からチェックインのコマンドを受け付ける。これにより、プロセスデータ、タスクデータおよび成果物データのうち少なくとも１種類のデータが更新されたことを認識する。更新部１３０は、データ更新が発生したことを変更量算出部１４０に通知する。その際、更新部１３０は、更新されたデータの種類を変更量算出部１４０に通知してもよい。

（ステップＳ１２）変更量算出部１４０は、更新されたデータの種類を判定する。すなわち、更新されたデータが、プロセスデータ、タスクデータおよび成果物データの何れであるかを判定する。なお、複数の種類のデータが同時に更新されることも有り得る。

（ステップＳ１３）変更量算出部１４０は、ステップＳ１２で判定した種類について、更新後の最新のデータと１つ前のリビジョンのデータ（バックアップデータ）とを、リポジトリ１１０から取得する。そして、各種類のデータの変更量を算出する。変更量の算出方法は、図１１で説明した方法を用いることができる。例えば、成果物データであれば、ファイルのデータサイズの増加量（または減少量）や、ファイル内の文字数や行数の増加量（または減少量）を算出する方法が考えられる。

（ステップＳ１４）変更量算出部１４０は、制御データ記憶部１２０に記憶された制御テーブル１２１を参照して、リビジョン更新判定ルールを確認する。そして、変更量算出部１４０は、リビジョン更新判定ルールの条件に合致するか否か判定する。例えば、ステップＳ１３で算出した変更量が３０％以上か否か判定する。条件に合致する場合、処理をステップＳ１５に進める。条件に合致しない場合、処理を終了する。なお、複数の種類のデータが更新されている場合、変更量算出部１４０はデータの種類毎に判定を行い、少なくとも１つの種類のデータについて条件に合致すれば、処理をステップＳ１５に進める。

（ステップＳ１５）リビジョン管理部１５０は、リポジトリ１１０に格納されたリビジョン管理テーブル１１５から、１つ前のリビジョン番号を取得する。そして、リビジョン番号に含まれる複数の桁の中で、ステップＳ１４で条件に合致すると判定されたデータの種類に対応する桁を特定する。すなわち、プロセスデータであれば第１桁、タスクデータであれば第２桁、成果物データであれば第３桁を特定する。

（ステップＳ１６）リビジョン管理部１５０は、ステップＳ１５で特定した桁の数値をインクリメント（１だけ加算）した、新たなリビジョン番号を生成する。そして、リビジョン管理部１５０は、生成したリビジョン番号をデータ管理部１６０に通知する。ステップＳ１４で条件に合致すると判定されたデータの種類が複数ある場合、複数の桁の数値がインクリメントされる。例えば、タスクデータの変更量と成果物データの変更量が共に３０％以上であるとき、１つ前のリビジョン番号の第２桁と第３桁の数値がそれぞれインクリメントされる。

（ステップＳ１７）データ管理部１６０は、制御テーブル１２１を参照して、バックアップ取得判定ルールを確認する。そして、データ管理部１６０は、バックアップ取得判定ルールの条件に合致するか否か判定する。例えば、ステップＳ１３で算出した変更量が５０％以上か否か判定する。条件に合致する場合（完全バックアップと判定される場合）、処理をステップＳ１８に進める。条件に合致しない場合（差分バックアップと判定される場合）、処理をステップＳ１９に進める。なお、バックアップを実行するデータの種類が複数ある場合、データの種類毎に判定を行う。

（ステップＳ１８）データ管理部１６０は、ステップＳ１７で条件に合致すると判定された種類のデータについて、完全バックアップを実行する。そして、処理をステップＳ２０に進める。なお、完全バックアップの方法は、前述の方法を用いることができる。

（ステップＳ１９）データ管理部１６０は、ステップＳ１７で条件に合致しないと判定された種類のデータについて、差分バックアップを実行する。そして、処理をステップＳ２０に進める。なお、差分バックアップの方法は、前述の方法を用いることができる。

（ステップＳ２０）データ管理部１６０は、更新ログテーブル１１６，１１６ａ，１１６ｂのうち、バックアップを実行したデータの種類に対応する更新ログテーブルを更新する。また、リビジョン管理部１５０から通知されたリビジョン番号を、親番号（１つ前のリビジョン番号）および保存日時と併せてリビジョン管理テーブル１１５に設定する。

このようにして、リビジョン管理部１５０は、データの変更量が第１の条件を満たすとき、リビジョン番号の更新を行う。データ管理部１６０は、データの変更量が第２の条件を満たすか否かに応じて、更新後の最新データについて完全バックアップまたは差分バックアップを実行する。また、データ管理部１６０は、新たなリビジョン番号をバックアップデータと対応付けてリポジトリ１１０に記録する。

次に、プロジェクト管理装置１００で実行されるバックアップデータ抽出処理を説明する。抽出部１７０は、更新ログテーブル１１６，１１６ａ，１１６ｂを参照することで、リビジョン番号に対応するプロジェクト情報（プロセスデータ、タスクデータおよび成果物データを含む）を抽出することができる。

図１３は、バックアップデータ抽出処理を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。
（ステップＳ２１）抽出部１７０は、端末装置２１，２２，２３からチェックアウトのコマンドを受け付ける。チェックアウトのコマンドには、所望のリビジョンを示すリビジョン番号が含まれる。ここでは、一例として、リビジョン番号＝“１．５．２”が指定されたものとする。

（ステップＳ２２）抽出部１７０は、ステップＳ２１で取得したリビジョン番号から、第１桁の値を抽出する。リビジョン番号＝“１．５．２”の場合、“１”を抽出する。
（ステップＳ２３）抽出部１７０は、プロセスデータに関する更新ログテーブル１１６から、ステップＳ２２で抽出した値に対応するリビジョンＩＤのレコードを検索する。そして、抽出部１７０は、検索されたレコードが示すファイル名のデータを、リポジトリ１１０から取得する。リビジョン番号＝“１．５．２”の場合、リビジョンＩＤ＝“ｖ１”のレコードが検索され、“プロセスｖ１．ｄａｔ”がリポジトリ１１０から取得される。

なお、抽出部１７０は、取得したデータが差分バックアップのデータである場合、その直近の完全バックアップまでのデータを遡って取得し、完全バックアップおよび差分バックアップのデータから、所望のリビジョンのプロセスデータを復元する。

（ステップＳ２４）抽出部１７０は、ステップＳ２１で取得したリビジョン番号から、第２桁の値を抽出する。リビジョン番号＝“１．５．２”の場合、“５”を抽出する。
（ステップＳ２５）抽出部１７０は、タスクデータに関する更新ログテーブル１１６ａから、ステップＳ２４で抽出した値に対応するリビジョンＩＤのレコードを検索する。そして、抽出部１７０は、検索されたレコードが示すファイル名のデータを、リポジトリ１１０から取得する。リビジョン番号＝“１．５．２”の場合、リビジョンＩＤ＝“ｖ５”のレコードが検索され、“タスクｖ５．ｄａｔ”がリポジトリ１１０から取得される。

なお、抽出部１７０は、取得したデータが差分バックアップのデータである場合、プロセスデータの場合と同様にして、所望のリビジョンのタスクデータを復元する。例えば、“タスクｖ５．ｄａｔ”が差分バックアップのデータの場合、抽出部１７０は、完全バックアップのデータ“タスクｖ３．ｄａｔ”と差分バックアップのデータ“タスクｖ４．ｄａｔ”をリポジトリ１１０から更に取得する。そして、“タスクｖ３．ｄａｔ”，“タスクｖ４．ｄａｔ”，“タスクｖ５．ｄａｔ”から、タスクデータを復元する。

（ステップＳ２６）抽出部１７０は、ステップＳ２１で取得したリビジョン番号から、第３桁の値を抽出する。リビジョン番号＝“１．５．２”の場合、“２”を抽出する。
（ステップＳ２７）抽出部１７０は、成果物データに関する更新ログテーブル１１６ｂから、ステップＳ２６で抽出した値に対応するリビジョンＩＤのレコードを検索する。そして、抽出部１７０は、検索されたレコードが示すファイル名のデータを、リポジトリ１１０から取得する。リビジョン番号＝“１．５．２”の場合、リビジョンＩＤ＝“ｖ２”のレコードが検索され、“仕様書ｖ２．ｄａｔ”がリポジトリ１１０から取得される。

なお、抽出部１７０は、取得したデータが差分バックアップのデータである場合、他の種類のデータの場合と同様に、所望のリビジョンの成果物データを復元する。例えば、“仕様書ｖ２．ｄａｔ”が差分バックアップのデータの場合、抽出部１７０は、完全バックアップのデータ“仕様書ｖ１．ｄａｔ”をリポジトリ１１０から更に取得する。そして、“仕様書ｖ１．ｄａｔ”，“仕様書ｖ２．ｄａｔ”から、成果物データを復元する。ただし、成果物データの差分バックアップがファイル単位で行われる場合は、“仕様書ｖ１．ｄａｔ”を“仕様書ｖ２．ｄａｔ”に置き換えることで、成果物データを復元できる。

（ステップＳ２８）抽出部１７０は、ステップＳ２３で取得したプロセスデータ、ステップＳ２５で取得したタスクデータ、および、ステップＳ２７で取得した成果物データを纏めて、プロジェクト情報として出力する。出力されたプロジェクト情報は、端末装置２１，２２，２３に直接送信してもよい。また、表示処理部１８０が提供する操作画面上にプロジェクト情報へのリンクを作成し、ユーザの操作によりダウンロード可能な状態にしてもよい。また、プロジェクト情報の少なくとも一部の内容を含む表示画面を、表示処理部１８０が端末装置２１，２２，２３に提供するようにしてもよい。

このようにして、抽出部１７０は、リビジョン番号を含むコマンドを受け付け、リビジョン番号に含まれる３桁の値を参照することで、３種類のデータを含むプロジェクト情報をリポジトリ１１０から抽出することができる。抽出されたプロジェクト情報は、リビジョン番号が示すリビジョンのプロジェクト情報（すなわち、過去のある時点におけるプロジェクト情報）である。ユーザは、例えば、端末装置２１，２２，２３のモニタに表示されるリビジョン番号選択画面を見て、チェックアウトの操作を行うことができる。

図１４は、リビジョン番号選択画面の例を示す図である。リビジョン番号選択画面２００は、表示処理部１８０によって提供される操作画面であり、端末装置２１，２２，２３のモニタに表示される。表示処理部１８０は、リポジトリ１１０に記憶されたリビジョン管理テーブル１１５に基づいて、リビジョン番号選択画面２００を生成する。リビジョン番号選択画面２００は、リビジョン情報表示領域２１０および取り出しボタン２２０を含む。

リビジョン情報表示領域２１０は、プロジェクト情報のリビジョン番号と、当該リビジョン番号が示すリビジョンについての情報とを対応付けて表示する表示領域である。具体的には、各リビジョンでのデータの更新状況（何れの種類のデータが更新されたか）や、各リビジョンのバックアップデータの保存日時の一覧が表示される。図１４において、丸印（○）が付された種類のデータは、１つ前のリビジョンから更新されていることを示しており、ハイフン（−）が付された種類のデータは、１つ前のリビジョンから更新されていないことを示している。

また、リビジョン情報表示領域２１０内には、リビジョン番号を選択するためのチェックボックスが設けられている。ユーザは、入力デバイスを用いて、チェックボックスをオン／オフにする操作を行える。チェックボックスがオンになった状態（チェックマークが入力された状態）は、特定のリビジョン番号が選択された状態を示している。図１４では、リビジョン番号“１．５．２”が選択されている。

取り出しボタン２２０は、リビジョン情報表示領域２１０で選択されたリビジョン番号に対応するプロジェクト情報を、プロジェクト管理装置１００から取得するためのボタンである。ユーザの操作により取り出しボタン２２０が押下されると、端末装置２１，２２，２３は、リビジョン情報表示領域２１０で選択されたリビジョン番号を含むチェックアウトのコマンドを、プロジェクト管理装置１００に送信する。プロジェクト管理装置１００の抽出部１７０は、チェックアウトのコマンドを受け付け、図１３に示した方法で、選択されたリビジョン番号に対応するプロジェクト情報をリポジトリ１１０から抽出する。

このように、プロジェクト管理装置１００は、リビジョン番号により複数の種類のデータの更新状況を管理する。リビジョン番号に含まれる３つの桁は、３種類のデータに対応している。このため、更新前のリビジョン番号と更新後のリビジョン番号とを比較することで、何れの種類のデータが更新されたかを容易に特定することができる。

このため、リビジョン番号選択画面２００を参照し、リビジョン番号の各桁の変化を確認することで、データの種類毎の更新状況を容易に把握することができる。また、ある時点において、プロジェクト情報に含まれる複数の種類のデータがどの様な状態であったかを容易に確認することができる。その結果、過去のある時点におけるプロジェクト情報全体のレビューを容易に行えるようになる。

更に、データの変更量に応じて、バックアップの方法（完全バックアップまたは差分バックアップ）を自動的に選択することができる。このため、常に完全バックアップを実行する方法に比べて、バックアップデータを記憶するための記憶領域を節約できる。また、最初に完全バックアップを実行した後は常に差分バックアップを実行する方法と比べて、任意のリビジョンのプロジェクト情報を復元する処理の負荷が抑制される。

１ 更新管理装置
１ａ 記憶手段
１ｂ 検出手段
１ｃ 管理手段
２，２ａ データ集合
３，３ａ 記号列

Claims (6)

1. 複数の種類のデータを含むデータ集合の更新を管理する更新管理装置であって、
   記憶装置に格納された前記データ集合の中の１またはそれ以上の種類のデータの更新を検出する検出手段と、
   検出結果に応じて、前記複数の種類に対応する複数の部分を含む記号列を生成し、前記データ集合の版数を示す情報として前記記憶装置に格納する管理手段と、を有し、
   前記管理手段は、更新前の版数を示す記号列から、前記複数の部分のうち更新が検出されたデータの種類に対応する部分の記号を変更し、更新後の版数を示す記号列とする、
   ことを特徴とする更新管理装置。
2. 前記管理手段は、前記複数の部分のうち更新が検出されなかったデータの種類に対応する部分の記号を変更しないことを特徴とする請求項１記載の更新管理装置。
3. 前記管理手段は、前記データ集合に含まれるデータの少なくとも一部を複製し、複製したデータと生成した前記更新後の版数を示す記号列とを対応付けて前記記憶装置に格納することを特徴とする請求項１または２記載の更新管理装置。
4. 前記記憶装置では、前記複数の種類のデータの更新履歴がデータの種類毎に管理され、
   前記データ集合の版数を示す記号列が入力されると、データの種類毎に、入力された記号列に含まれる当該種類に対応する部分の記号に基づいて前記記憶装置からデータを抽出する抽出手段を更に有する、
   ことを特徴とする請求項１乃至３の何れか一項に記載の更新管理装置。
5. 複数の種類のデータを含むデータ集合の更新を管理するコンピュータによって実行される更新管理方法であって、
   記憶装置に格納された前記データ集合の中の１またはそれ以上の種類のデータの更新を検出し、
   検出結果に応じて、前記複数の種類に対応する複数の部分を含む記号列を生成し、前記データ集合の版数を示す情報として前記記憶装置に格納する、処理を含み、
   記号列の生成では、更新前の版数を示す記号列から、前記複数の部分のうち更新が検出されたデータの種類に対応する部分の記号を変更し、更新後の版数を示す記号列とする、
   ことを特徴とする更新管理方法。
6. 複数の種類のデータを含むデータ集合の更新を管理する更新管理プログラムであって、コンピュータに、
   記憶装置に格納された前記データ集合の中の１またはそれ以上の種類のデータの更新を検出し、
   検出結果に応じて、前記複数の種類に対応する複数の部分を含む記号列を生成し、前記データ集合の版数を示す情報として前記記憶装置に格納する、処理を実行させ、
   記号列の生成では、更新前の版数を示す記号列から、前記複数の部分のうち更新が検出されたデータの種類に対応する部分の記号を変更し、更新後の版数を示す記号列とする、
   ことを特徴とする更新管理プログラム。

Images