"複数のクライアントと管理サーバとを有するシステムにおいて、前記クライアントは、ファイル名を指定して複数のノードから構成されるソースファイルのダウンロードを前記管理サーバに要求し、前記ダウンロードしたソースファイルのノードについて作業者により変更されたソースファイルのテストをし、前記テストの際に前記変更されたノードを含むノードの経路情報を実行ノード情報として記録し、前記記録された実行ノード情報とともに前記変更したソースファイルを前記管理サーバにアップロード要求を行うことにより、前記ソースファイルを複数の前記作業者が並行して変更する際に、前記変更されたソースファイルの構成を管理するソース構成管理方法であって、前記管理サーバは、記憶部に、ファイル名とクライアント名と版番とを関連付けた配布管理情報と、ファイル名と版番と変更されたノードとを関連付けた変更管理情報とが記憶されており、前記管理サーバは、前記クライアントからアップロード要求があった場合、前記クライアント名および前記ファイル名に基づいて前記配布管理情報から前記クライアントに配布したソースファイルの版番を取得し、前記取得した版番のソースファイルと前記変更したソースファイルとを比較して変更されたノードを抽出し、前記変更されたノードが前記変更管理情報に基づいて既に変更されたノードと競合があるか否かの競合判定をし、前記競合判定で競合がない場合、前記変更されたノードを前記最新の版番のソースファイルと統合するとともに、変更した情報を前記変更管理情報に記録し、前記競合判定の際に、前記変更管理情報を参照して、前記クライアントに配布した版番より新しい履歴にある既に変更された既変更ノードを取得し、前記変更されたノードが前記既変更ノードに含まれるか否かを判定し、前記既変更ノードに含まれない場合、前記既変更ノードが、前記実行ノード情報に含まれているか否かを判定し、前記実行ノード情報に含まれていない場合、前記競合判定を競合がないと判定することを特徴とするソース構成管理方法。前記管理サーバは、前記クライアントからダウンロード要求があった場合、前記変更管理情報から前記指定されたファイル名の最新の版番を特定し、前記特定された版番のソースファイルを要求元の前記クライアントに配布するとともに、前記配布した情報を含むダウンロード要求のエントリを前記配布管理情報に記録することを特徴とする請求項1に記載のソース構成管理方法。前記管理サーバは、前記競合判定で競合がないと判定し前記変更されたノードを前記最新の版番のソースファイルと統合した場合、前記アップロード要求があったクライアントについて前記ダウンロード要求のエントリを前記配布管理情報から削除することを特徴とする請求項2に記載のソース構成管理方法。前記管理サーバは、前記クライアントからアップロード要求があった場合、かつ、前記配布管理情報に前記要求元のクライアントの前記ダウンロード要求のエントリがない場合、前記要求元のクライアントに再ダウンロード要求をする旨の通知をすることを特徴とする請求項3に記載のソース構成管理方法。前記管理サーバは、前記競合判定の際に、前記競合判定を競合すると判定した場合、前記アップロード要求のクライアントに、アップロードが失敗した旨を通知することを特徴とする請求項1に記載のソース構成管理方法。前記ノードは、前記ノードの機能を実現できる複数のステップのコードを含んでおり、前記ノード内のステップコードの競合判定を行う際には、前記管理サーバは、前記記憶部に、ファイル名と版番と変更されたステップとを関連づけた前記変更管理情報が記憶されており、前記実行ノード情報は、前記変更されたステップの経路情報であることを特徴とする請求項1に記載のソース構成管理方法。複数のクライアントと管理サーバとを有するシステムにおいて、前記クライアントは、ファイル名を指定して複数のノードから構成されるソースファイルのダウンロードを前記管理サーバに要求し、前記ダウンロードしたソースファイルのノードについて作業者により変更されたソースファイルのテストをし、前記テストの際に前記変更されたノードを含むノードの経路情報を実行ノード情報として記録し、前記記録された実行ノード情報とともに前記変更したソースファイルを前記管理サーバにアップロード要求を行うことにより、前記ソースファイルを複数の前記作業者が並行して変更する際に、前記変更されたソースファイルの構成を管理するソース構成管理プログラムであって、コンピュータに、記憶部に、ファイル名とクライアント名と版番とを関連付けた配布管理情報と、ファイル名と版番と変更されたノードとを関連付けた変更管理情報とを記憶する処理と、前記クライアントからアップロード要求があった場合、前記クライアント名および前記ファイル名に基づいて前記配布管理情報から前記クライアントに配布したソースファイルの版番を取得し、前記取得した版番のソースファイルと前記変更したソースファイルとを比較して変更されたノードを抽出し、前記変更されたノードが前記変更管理情報に基づいて既に変更されたノードと競合があるか否かの競合判定をし、前記競合判定で競合がない場合、前記変更されたノードを前記最新の版番のソースファイルと統合するとともに、変更した情報を前記変更管理情報に記録する構成管理処理と、前記競合判定の際に、前記変更管理情報を参照して、前記クライアントに配布した版番より新しい履歴にある既に変更された既変更ノードを取得し、前記変更されたノードが前記既変更ノードに含まれるか否かを判定し、前記既変更ノードに含まれない場合、前記既変更ノードが、前記実行ノード情報に含まれているか否かを判定し、前記実行ノード情報に含まれていない場合、前記競合判定を競合がないと判定する競合判定処理とを実行させるためのソース構成管理プログラム。特許文献1の場合、修正箇所を指定する際に、プログラムのどこを修正するのかを修正作業を開始する前に確定する必要があるが、熟練した作業者でなければ、短時間で修正箇所を確定することができない問題がある。また、修正箇所の確定が完了するまでは、ソースファイルにロックがかかった状態となり、他の作業者が作業できない問題がある。特許文献2の場合、他の作業者が実施している作業内容を把握できる利点はある。しかしながら、基本的には、他の作業者が同一のソースファイルを修正していると認識しているとわかった場合、その作業が終わるのを待ってから自分の修正をいれるのが通常の流れである。従来から、作業者には、他の作業者の開発状況に関わらずもっと自由に開発に専念したいという要望があるが、管理者にとっては、ソースファイルの版番バージョン管理が大変であり効率よい管理方法が望まれていた。また、同じソースファイルを複数の作業者で修正した場合、自動的に統合する方法が望まれていた。管理者には、変更内容を統合するための専門知識と作業時間が要求され、統合に失敗することもよくあった。本発明は、前記の課題を解決するための発明であって、複数の作業者が並行開発している複数のノードから構成されるソースファイルを効率よく管理することができるソース構成管理方法およびソース構成管理プログラムを提供することを目的とする。前記目的を達成するため、本発明のソース構成管理方法は、複数のクライアントと管理サーバとを有するシステムにおいて、複数のノードから構成されるソースファイルを複数の作業者が並行して変更する際に、変更されたソースファイルの構成を管理するソース構成管理方法である。クライアントは、ファイル名を指定してソースファイルのダウンロードを管理サーバに要求し、ダウンロードしたソースファイルのノードについて作業者により変更されたソースファイルのテストをし、テストの際に変更されたノードを含むノードの経路情報を実行ノード情報例えば、実行ノードテーブル227として記録し、記録された実行ノード情報とともに変更したソースファイルとを管理サーバにアップロード要求をする。管理サーバには、記憶部に、ファイル名とクライアント名と版番とを関連付けた配布管理情報例えば、配布管理テーブル126と、ファイル名と版番と変更されたノードとを関連付けた変更管理情報例えば、変更管理テーブル127とが記憶されている。管理サーバは、クライアントからアップロード要求があった場合、クライアント名およびファイル名に基づいて配布管理情報からクライアントに配布したソースファイルの版番を取得し、取得した版番のソースファイルと変更したソースファイルとを比較して変更されたノードを抽出し、変更されたノードが変更管理情報に基づいて既に変更されたノードと競合があるか否かの競合判定をし、競合判定で競合がない場合、変更されたノードを最新の版番のソースファイルと統合するとともに、変更した情報を変更管理情報に記録する。競合判定の際に、変更管理情報を参照して、クライアントに配布した版番より新しい履歴にある既に変更された既変更ノードを取得し、変更されたノードが既変更ノードに含まれるか否かを判定し、既変更ノードに含まれない場合、既変更ノードが、実行ノード情報に含まれているか否かを判定し、実行ノード情報に含まれていない場合、競合判定を競合がないと判定することを特徴とする。本発明によれば、複数の作業者が並行開発している複数のノードから構成されるソースファイルを効率よく管理することができる。以下、本発明の実施形態を図面に基づいて詳細に説明する。図1は、本発明の実施形態に係るソース構成管理システムの構成を示す図である。ソース構成管理システムは、ソースファイルを管理する管理サーバ装置100管理サーバと、複数のクライアント装置200クライアントを含んで構成され、管理サーバ装置100とクライアント装置200とは、ネットワーク300で接続されている。管理サーバ装置100は、CPU110、メモリ120記憶部、HDD130、NIC140を有し、システムバス150を介して接続されている。メモリ120には、OS123のほか、複数のソースファイルからなるマスタソースの構成を管理する構成管理処理部121図7、図8参照、作業者が変更したソースファイルの部位が他の作業者の変更部位と競合するか否かを検出する競合検出処理部122図9参照、配布管理テーブル126図4参照、変更管理テーブル127図5参照が格納されている。HDD130には、マスタソースである複数のソースファイルが格納されている。なお、CPUはCentralProcessingUnitの略、HDDはHardDiskDriveの略、NICはNetworkInterfaceCardの略である。クライアント装置200は、CPU210、メモリ220、HDD230、NIC240を有し、システムバス250を介して接続されている。メモリ220には、OS223のほか、変更した部位を含む経路をテスト実行するテスト実行処理部221、変更した部位を含む経路の部位の識別情報を記録する実行ノード記録処理部222、ユーザがソースファイルを変更するための編集部226、ソースファイルを管理サーバ100からダウンロードするダウンロード処理部224、変更したソースファイルをアップロードするアップロード処理部225、および実行ノードテーブル227図6参照が格納される。HDD230には、変更対象となるソースファイルが格納される。なお、アップロードとは、ネットワーク300を通じて、クライアント装置200に保存されているデータを管理サーバ装置100に転送することを意味し、逆をダウンロードという。また、ソースファイルは、複数の部位以下、ノードと称する。から構成されており、各ノードは、ノードの機能を実現できる複数のステップコードを含んでいる。図2は、ソース構成管理システムの処理概要を示す図である。図2を参照して、ソース構成管理システムの処理概要を説明する。主要な箇所にステップ符号を付加している。<ダウンロードに係る処理概要>1管理サーバ装置100は、クライアント装置200のダウンロード処理部224からソースファイルのダウンロード要求配布要求があると、構成管理処理部121は、マスタソースの最新版をHDD130から取り出し要求元のクライアント装置200に配布するステップS1。また、構成管理処理部121は、配布に関する情報を配布管理テーブル126に記録するステップS2。2クライアント装置200の編集部226は、配布されたソースファイルを変更後、コンパイルしてオブジェクトにするステップS3。3クライアント装置200のテスト実行処理部221は、テスト環境でオブジェクトのテスト実行の際、実行ノード記録処理部222を呼び出すステップS4。テスト実行処理部221は、変更ノードの妥当性を確認するため、既存のノードを変更した場合は、変更したノードを経路とするソースファイルのテストを実行する。既存のノードを削除した場合は、削除ノードに伴う他のノードを経路とするソースファイルのテスト実行する。4クライアント装置200の実行ノード記録処理部222は、テスト実行されたノードを経路情報の形で実行ノードテーブル227に記録するステップS5。<アップロードに係る処理概要>5クライアント装置200のアップロード処理部225は、実行ノードテーブル227を添えて変更済みソースファイルをアップロード要求するステップS6。6管理サーバ装置100の構成管理処理部121は、アップロード要求を受理すると、競合検出処理部122を呼び出すステップS7。7競合検出処理部122は、変更管理テーブル127と受理した実行ノードテーブル227を参照し、他の作業者が既に変更したノードと競合しないか否かの競合の有無を判定し、判定結果を構成管理処理部121に通知するステップS88構成管理処理部121は、判定結果に競合がない場合、アップロードを許可し、変更済みソースファイルの内容を最新版のマスタソースに統合し更新するステップS9。また、構成管理処理部121は、変更管理テーブル127にマスタソースの変更ノードの識別情報などを記録するステップS10。以上、図2においてソース構成管理システムの処理概要を示したが、具体的なソースファイルを例に、変更済みソースファイルの内容を最新版のマスタソースに統合できるか否かについて、図3を参照して説明する。図3は、クライアント装置によるソースファイルの変更と統合可否を示す図である。ソースファイルは、図3に示すノードN1からノードN8を有して構成されているとする。複数のクライアント装置200であるクライアントA、クライアントB、クライアントCにおいて、ほぼ同時にソースファイルを変更した場合について考える。具体的には、クライアントAは、ノードN3を変更し、クライアントBはノードN4を変更し、クライアントCは、ノードN6を変更した。前記の変更の場合、例えば、クライアントA、クライアントB、クライアントCにおいて、変更ノードの妥当性を確認するための実行ノードテーブル227には、テスト実行ノードとして下記の妥当性の確認に必要な1以上の経路情報が記録される。なお、括弧書きが変更ノードを示す。クライアントAの場合:ノードN1,N2,N3,N5,N6,N8ノードN1,N2,N3,N5,N7,N8なお、ノードN3を変更した場合、ノードN5で分岐があるので、2つの経路情報が記録される。クライアントBの場合:ノードN1,N2,N4,N5,N6,N8ノードN1,N2,N4,N5,N7,N8なお、ノードN4を変更した場合、ノードN5で分岐があるので、2つの経路情報が記録される。クライアントCの場合:ノードN1,N2,N3,N5,N6,N8ノードN1,N2,N4,N5,N6,N8なお、ノードN6を変更した場合、ノードN2で分岐があるので、2つの経路情報が記録される。競合検出処理部122は、クライアントAのノードN3の変更が先にマスタソースに統合されていた場合において、クライアントBの実行ノードテーブル227には、ノードN3が含まれていないため、競合しないと判定する。同様に、クライアントBのノードN4の変更が先にマスタソースに統合されていた場合において、クライアントAの実行ノードテーブル227には、ノードN4が含まれていないため、競合しないと判定する。競合検出処理部122は、クライアントAのノードN3の変更が先にマスタソースに統合されていた場合において、クライアントCの実行ノードテーブル227には、ノードN3が含まれているため、競合すると判定する。同様に、クライアントCのノードN6の変更が先にマスタソースに統合されていた場合において、クライアントAの実行ノードテーブル227には、ノードN6が含まれているため、競合すると判定する。また、競合検出処理部122は、クライアントBのノードN4の変更が先にマスタソースに統合されていた場合において、クライアントCの実行ノードテーブル227には、ノードN4が含まれているため、競合すると判定する。同様に、クライアントCのノードN6の変更が先にマスタソースに統合されていた場合においても、クライアントBの実行ノードテーブル227には、ノードN6が含まれているため、競合すると判定する。図3に示す例の場合、クライアントA,B,Cで同時に変更した場合に、クライアントAとクライアントBの変更は競合しないため統合可能、クライアントAとクライアントC、または、クライアントBとクライアントCの変更は競合するため統合不可能と機械的に判断し、並行開発における統合を容易にするものである。本実施形態では、クライアント装置200でプログラムを変更した際のテストで実行したノードに着目し、その実行ノードが最新版のマスタソースでも変化されていない場合は、クライアント装置200でのテストが有効なものとみなし、クライアント装置200の変更内容をマスタに統合することができる。図3の例を参照して、例えばクライアントA→B→Cの順で変更内容を統合しようとしたとすると下記のような結果になる。A1マスタソースには他の変更が統合されていないため、クライアントAの変更を統合できる。マスタソースにクライアントAの変更が統合される。A2マスタソースにはクライアントAの変更が統合されているが、変更部位がクライアントBの実行ノードテーブル227と競合しないため、クライアントBのテストは最新版のマスタソースに対しても有効である。クライアントBの変更はクライアントAの変更と統合できる。マスタソースにはクライアントAの変更に加えて、クライアントBの変更が統合される。A3マスタソースにはクライアントAとBの変更が統合されている。変更部位がクライアントCのテスト実行ノードと競合するため、クライアントCのテストは最新版のマスタソースに対して有効ではない。クライアントCの変更はマスタソースに統合できない。なお、統合できなかったクライアントCは、再度マスタソースを取得しなおした上、変更およびテストを実行する必要がある。また、図3の例を参照して、クライアントC→A→Bの順で変更内容を統合しようとしたとすると下記のような結果になる。C1マスタソースには他の変更が統合されていないため、クライアントCの変更を統合できる。マスタソースにクライアントCの変更が統合される。C2マスタソースにはクライアントCの変更が統合されている。変更部位がクライアントAのテスト実行ノードと競合するため、クライアントAのテストは最新版のマスタソースに対して有効ではない。クライアントAの変更はマスタソースに統合できない。なお、統合できなかったクライアントAは、再度マスタソースを取得しなおした上、変更およびテストを実行する必要がある。C3マスタソースにはクライアントCの変更が統合されている。変更部位がクライアントBのテスト実行ノードと競合するため、クライアントBのテストは最新版のマスタソースに対して有効ではない。クライアントBの変更はマスタソースに統合できない。なお、統合できなかったクライアントBは、再度マスタソースを取得しなおした上、変更およびテストを実行する必要がある。本実施形態によれば、ソースファイルの変更を確認するため、テスト実行処理部221で実行したノードの経路情報変更に伴う影響範囲を実行ノード記録処理部222が記録し、競合検出処理部122は、該変更に伴う影響範囲を他の作業者が変更加えていなかった場合に競合がないと判定することができる。次に各種テーブルについて説明する。図4は、配布管理テーブルの一例を示す図である。配布管理テーブル126は、ファイル名41、クライアント名42、および版番43を含んで構成される。具体的には、図4を参照すると、クライアントAは、ファイル名source1.cの版番1をダウンロードしていることがわかる。同様に、クライアントBも、ファイル名source1.cの版番1をダウンロードしていることがわかる。クライアントCは、ファイル名source1.cの版番3をダウンロードしていることがわかる。図5は、変更管理テーブルの一例を示す図である。変更管理テーブル127は、ファイル名51、版番52、および変更部位53を含んで構成される。変更部位53は、その版番で変更された部位を示し、マスタソースとしては、最新の版番までの変更部位が考慮される。具体的には、図5を参照すると、ファイル名source1.cの版番1は、変更部位が記録されていない状態である。ファイル名source1.cの版番2は、変更部位としてノードN3があり、ファイル名source1.cの版番3は、変更部位としてノードN4であるとわかる。図5に示す例の場合、マスタソースのファイル名source1.cの版番3には、ノードN3とノードN4の変更がされていることを意味する。図6は、実行ノードテーブルの一例を示す図である。実行ノードテーブル227は、ファイル名61および実行ノード62を含んで構成される。実行ノードには、図3で既に、説明した経路情報が記録されている。図6の場合は、図3で示したクライアントCの場合である。次に各処理フローについて説明する。図7は、構成管理処理部のクライアントからのダウンロード要求処理を示すフローチャートである。適宜図1を参照して説明する。構成管理処理部121は、クライアント装置200からのダウンロード要求があると、ダウンロード要求に含まれるクライアント名とファイル名を取得しステップS701、HDD130ディスクから該ファイル名のソースファイルの最新版を取得するステップS702。構成管理処理部121は、配布情報として図4に示す配布管理テーブル126にファイル名41とクライアント名42と版番43を記録しステップS703、要求元のクライアント装置200にソースファイルを配布しステップS704、処理を終了する。なお、ステップS703とステップS704の処理については、順序が入れ替わってもよい。図8は、構成管理処理部のクライアントからのアップロード要求処理を示すフローチャートである。適宜図1を参照して説明する。構成管理処理部121は、クライアント装置200からのアップロード要求があると、配布管理テーブル126図4参照を参照して、クライアント名とファイル名とに基づいて、クライアント装置200に配布したマスタソースの版番を取得するステップS801。構成管理処理部121は、ステップS801でクライアント名とファイル名とに基づく版番を取得できたか否かにより、エントリがあるか否かを判定するステップS802。エントリがあればステップS802,Yes、ステップS803に進み、エントリがなければステップS802,No,アップロード要求したファイル名について再ダウンロードの必要性があることを要求元に通知しステップS821、処理を終了する。構成管理処理部121が、ステップS802でエントリがあるか否かを判定するのは、ダウンロードされていないソースファイルを不正にアップロードすることを防止するためである。また、一度、変更対象となるソースファイルをダウンロードしたあとに、異なるノードを修正したソースファイルを、二重にアップロードする場合の不具合を防止するためである。詳細な説明は後記する。構成管理処理部121は、ステップS801で取得した版番のマスタソースをHDD130ディスクから取得するステップS803。そして、構成管理処理部121は、アップロード要求に含まれる変更済みのソースソースファイルとステップS803で取得したマスタソースと比較し変更内容を抽出するステップS804。具体的には、二つのファイルを比較処理すると、抽出コードが特定されその抽出コードの変更部位のノードを特定するとよい。本実施形態では、クライアント装置200側には作業者が変更した変更履歴を取らずに、自由に変更できるようにしている。すなわち、管理サーバ装置100が、ダウンロードしたソースファイルと、アップロードしたソースファイルとを比較することにより、変更内容の部位を抽出していることがひとつの特徴となっている。構成管理処理部121は、競合検出処理部122を呼び出しステップS805、競合があるか否かを判定するステップS806。構成管理処理部121は、競合があればステップS806,Yes、要求元にアップロードの失敗を通知しステップS822、処理を終了し、競合がなければステップS806,No、ステップS807に進む。ステップS807において、構成管理処理部121は、マスタソースの最新版をHDD130ディスクから取得しステップS807、マスタソースに変更内容を統合しステップS808、統合したマスタソースをディスクに格納するステップS809。そして、構成管理処理部121は、変更情報を変更管理テーブル127図5参照に記録しステップS810、要求元にアップロードの成功を通知しステップS811、配布管理テーブル126図4参照の要求元のクライアントのエントリを消去しステップS812、一連の処理を終了する。なお、ステップS812で、エントリを消去するのではなく、配布履歴を残すため、無効化処理としてもよい。図9は、競合検出処理部の競合検出処理を示すフローチャートである。図8におけるステップS805の呼び出し後の処理について説明する。競合検出処理部122は、変更管理テーブル127図5参照を参照し、配布した版番より新しい履歴の変更部位を取得しステップS901、変更部位があるか否かを判定するステップS902。競合検出処理部122は、変更部位があればステップS902,Yes、ステップS903に進み、変更部位がなければステップS902,No、競合なしと判定しステップS908、構成管理処理部121の処理図8参照に戻る。ステップS903において、競合検出処理部122は、ステップS804で抽出した変更内容について、変更部位に含まれているかを検索しステップS903、含まれている場合ステップS904,Yes、競合ありと判定しステップS907、構成管理処理部121の処理図8参照に戻る。含まれていない場合ステップS904,No、ステップS905に進む。ステップS905において、競合検出処理部122は、それぞれの変更部位について、アップロード要求に添付されてきた実行ノードテーブル227に含まれているか検索しステップS906、含まれている場合ステップS906,Yes、競合ありと判定しステップS907、構成管理処理部121の処理図8参照に戻る。一方、含まれていない場合ステップS906,No、競合なしと判定しステップS908、構成管理処理部121の処理図8参照に戻る。図8に戻り、ステップS802でエントリを判定している理由、すなわち、エントリ判定しない場合の二重アップロードの場合の不整合について説明する。具体的には、図3で示した例で説明すると、クライアントAが版番1のソースファイルに対しノードN3を変更したものをアップロードし、さらに、クライアントAがさらに版番1のソースファイルに対しノードN7を変更したものをアップロードする場合を考える。クライアントAが版番1のソースファイルに対しノードN3を変更後アップロードすると、構成管理処理部121は、アップロード要求された変更部位が版番1のマスタソースと比較してノードN3と特定される。そして、マスタソースにはノードN3の変更が統合されて版番2になる。さらに、クライアントAが版番1のソースファイルに対しノードN7を変更しアップロードすると、構成管理処理部121は、アップロード要求された変更部位のノードが版番1のマスタソースと比較してノードN7と特定されるが、マスタソースの最新版は版番2であるため、版番1からの変更部位がノードN3である。このため、実行ノードテーブル227に、ノードN1,N2,N3,N5,N7,N8があり、ノードN3が競合するためアップロードが成功しないと判定され、版番の不整合による不具合が生じる。これに対し、クライアントAは、一度アップロードすると、最新版である版番2をダウンロードしてから、ノードN7を変更したものをアップロードすると、版番の不整合による不具合は生じない。図10は、実行ノード記録処理部によるサンプルプログラムのノード番号の採番を示す図である。配布管理テーブル126図4参照のファイル名source1.cのソースファイルの例である。図3に示した例と同様である。実行ノード記録処理部222は、実行ノードを記録するために、始点、終点、処理ボックス、および判定ボックスごとにノード番号を採番する。図10に示す例では、始点をノードN1、判定ボックスをノードN2、処理ボックスをノードN3,N4、判定ボックスをノードN5、処理ボックスをノードN6,N7、および終点をノードN8としている。図11は、実行ノード記録処理部によるサンプルプログラムの実行ノード記録例を示す図であり、aは実行ノードテーブルの例であり、bは複数のソースプログラムを同時にテストした場合の実行ノードテーブルの例である。ここでは、図10に示したソースファイルをクライアント装置200においてノードN3を変更し、変更したノードの動作を確認するテストをする場合について、実行ノード記録処理部222の記録例を説明する。図11aに示す実行ノードテーブル227には、変更したノードN3を含む経路情報が記録されており、ノードN1,N2,N3,N5,N6,N8と、ノードN1,N2,N3,N5,N7,N8が記録される。なお、図10に示すソースファイルの場合、ノードN5で分岐があるので、2つの経路情報が記録される。図11bは、ファイル名source1.cのソースファイルに関連あるファイル名source2.cも同時にダウンロードざれ、テスト実行された場合である。図11bに示す実行ノードテーブル227には、変更したノードN3を含む経路情報が記録されており、ノードN1,N2,N3,N5,N6,N8と、ノードN1,N2,N3,N5,N7,N8が記録されるとともに、ノードN10,N11,N12が記録される。なお、ファイル名source1.cのソースファイルの場合、ノードN5で分岐があるので、2つの経路情報が記録される。次に、各実施例について説明する。前提条件として、図10に示したファイル名source1.cのソースファイルは、マスタソースとして管理サーバ装置100に格納済みであり、変更管理テーブル127には、版番1として登録されている。クライアントA、クライアントB、クライアントCがソースファイルをダウンロードし、ソースファイルの変更をし、アップロードするが、アップロードが成功する例、アップロードが失敗する例について、複数の実施例実施例1~実施例10について、詳細に説明する。実施例1図12は、実施例1の変更元が最新版のため既存ノード変更のアップロードに成功するケースにおける各テーブルの状態を示す図であり、aはアップロード前の配布管理テーブルの状態、bはアップロード前の変更管理テーブルの状態、cは実行ノードテーブルの状態、dはアップロード後の変更管理テーブルの状態、eはアップロード後の配布管理テーブルの状態を示す。図13は、実施例1において、aは版番1に基づいたクライアントAによる変更と実行ノードを説明する図であり、bはアップロード後の版番2のマスタの状態を示す図である。なお、以下の実施例の説明において、変更のあったノードを明確にするため、図面の該当部分を網掛け表示することにより、明示しています。実施例1では、クライアントAが版番1のノードN3を変更してアップロードする例を示す。図12aに示すように、クライアントA、クライアントB、クライアントCがダウンロード要求して、版番1のファイル名source1.cのソースファイルをダウンロードしている。図12bに示すように、版番1には変更部位がない。図12cのクライアントAの実行ノードテーブル227には、変更したノードN3を含む経路情報が記録されている図13a参照。クライアントAがアップロード要求をすると、構成管理処理部121は、配布管理テーブル126図12aを参照し、クライアントAに配布したソースファイルの版番1を取得し、競合検出処理部122は、変更管理テーブル127図12bを参照し、配布した版番より新しい履歴がないため、変更部位がないことを確認し、競合なしと判定する。マスタソースの最新版と同じ版番を基に変更した場合は、競合する変更が存在しないため、アップロードが成功する。図12dに示すように、変更管理テーブル127には、変更部位がノードN3として版番2が登録される。登録されたアップロード後のマスタソースの状態は、図13bに示す。クライアントAは、引き続きソースファイルを変更するため、また、今後の変更に備えてダウンロード要求をすると、配布管理テーブル126は、図12eに示すようにクライアントAについて版番2を登録する。実施例2図14は、実施例2の変更管理テーブルの変更部位と同じ既存ノード変更でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、aはアップロード前の配布管理テーブルの状態、bはアップロード前の変更管理テーブルの状態、cは実行ノードテーブルの状態、dはアップロードの失敗後の変更管理テーブルの状態を示す。図15は、実施例2において、aはアップロード前の版番2のマスタの状態を示す図であり、bは版番1に基づいたクライアントBによる変更と実行ノードを説明する図である。実施例2では、実施例1を行った後のクライアントBが版番1のノードN3を変更してアップロードする例を示す。図14aに示すように、クライアントAについては版番2をダウンロードしているが、クライアントB、クライアントCは、版番1を既にダウンロードしている。図14bに示すように、版番2には変更部位としてノードN3がある図15a参照。図14cのクライアントBの実行ノードテーブル227には、変更したノードN3を含む経路情報が記録されている図15b参照。クライアントBがアップロード要求をすると、構成管理処理部121は、配布管理テーブル126図14aを参照し、クライアントBに配布したソースファイルの版番1を取得し、競合検出処理部122は、変更管理テーブル127図14bを参照し、配布した版番より新しい履歴版番2があるため、変更部位としてノードN3を取得し、クライアントBの変更内容であるノードN3が変更部位に含まれるため、競合ありと判定する。すなわち、マスタソースの変更履歴と同じ部位を変更した場合は、アップロードに失敗する。アップロードに失敗したため、クライアントBのアップロード要求による変更内容は統合されず、マスタソースの状態は図15のままで変化しない。すなわち、図14dに示すように変更管理テーブル127には、版番2が登録されたままで変化しない。実施例3図16は、実施例3の変更管理テーブルの変更部位と同じ既存ノード削除でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、aはアップロード前の配布管理テーブルの状態、bはアップロード前の変更管理テーブルの状態、cは実行ノードテーブルの状態、dはアップロードの失敗後の変更管理テーブルの状態を示す。図17は、実施例3において、aはアップロード前の版番2のマスタの状態を示す図であり、bは版番1に基づいたクライアントBによる変更と実行ノードを説明する図である。実施例3では、実施例1を行った後のクライアントBが版番1のノードN3を削除してアップロードする例を示す。図16aに示すように、クライアントAは版番2をダウンロードしているが、クライアントB、クライアントCは、版番1を既にダウンロードしている。図16bに示すように、版番2には変更部位としてノードN3がある図17a参照。図16cのクライアントBの実行ノードテーブル227には、ノードN3を削除したことを確認するための経路情報が記録されている図17b参照。クライアントBがアップロード要求をすると、構成管理処理部121は、配布管理テーブル126図16aを参照し、クライアントBに配布したソースファイルの版番1を取得し、競合検出処理部122は、変更管理テーブル127図16bを参照し、配布した版番より新しい履歴版番2があるため、変更部位としてノードN3を取得し、クライアントBの変更内容であるノードN3が変更部位に含まれるため、競合ありと判定する。すなわち、マスタソースの変更履歴と同じ部位を削除した場合は、アップロードに失敗する。アップロードに失敗したため、クライアントBのアップロード要求による変更内容は統合されず、マスタソースの状態は図17のままで変化しない。すなわち、図16dに示すように変更管理テーブル127には、版番2が登録されたままで変化しない。実施例4図18は、実施例4の変更管理テーブルの変更部位と競合しない既存ノード変更でアップロードに成功するケースにおける各テーブルの状態を示す図であり、aはアップロード前の配布管理テーブルの状態、bはアップロード前の変更管理テーブルの状態、cは実行ノードテーブルの状態、dはアップロード後の変更管理テーブルの状態、eはアップロード後の配布管理テーブルの状態を示す。図19は、実施例4において、aは版番1に基づいたクライアントBによる変更と実行ノードを説明する図であり、bはアップロード後の版番3のマスタの状態を示す図である。実施例4では、実施例1を行った後のクライアントBが版番1のノードN4を変更してアップロードする例を示す。図18aに示すように、クライアントAについては版番2がダウンロードされているが、クライアントB、クライアントCは、版番1を既にダウンロードしている。図18bに示すように、版番2には変更部位としてノードN3がある。図18cのクライアントBの実行ノードテーブル227には、変更したノードN4を含む経路情報が記録されている図19a参照。クライアントBがアップロード要求をすると、構成管理処理部121は、配布管理テーブル126図18aを参照し、クライアントBに配布したソースファイルの版番1を取得し、競合検出処理部122は、変更管理テーブル127図18bを参照し、配布した版番より新しい履歴版番2があるため、変更部位としてノードN3を取得し、クライアントBの変更内容であるノードN4は、変更部位に含まれていないと判定する。さらに、競合検出処理部122は、実行ノードテーブル227図18cを参照して、変更部位N3が実行ノードに存在しないため、競合なしと判定する。すなわち、マスタソースに変更があっても、テスト実行で通らない部分の場合は、アップロードに成功する。アップロードに成功したため、図18dに示すように変更管理テーブル127には、版番3が登録される。登録されたアップロード後のマスタソースの状態は、図19bに示す。クライアントBは、引き続きソースファイルを変更するため、また、今後の変更に備えてダウンロード要求をすると、配布管理テーブル126は、図18eに示すようにクライアントBについて版番3を登録する。実施例5図20は、実施例5の変更管理テーブルの変更部位と同じ既存ノード変更でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、aはアップロード前の配布管理テーブルの状態、bはアップロード前の変更管理テーブルの状態、cは実行ノードテーブルの状態、dはアップロードの失敗後の変更管理テーブルの状態を示す。図21は、実施例5において、aはアップロード前の版番3のマスタの状態を示す図であり、bは版番1に基づいたクライアントCによる変更と実行ノードを説明する図である。実施例5では、実施例4を行った後のクライアントCが版番1のノードN6を変更してアップロードする例を示す。図20aに示すように、クライアントAは版番2をダウンロードし、クライアントBは版番3をダウンロードし、クライアントCは版番1を既にダウンロードしている。図20bに示すように、版番2には変更部位としてノードN3があり、版番3には変更部位としてノードN4がある図21a参照。図20cのクライアントCの実行ノードテーブル227には、変更したノードN6を含む経路情報が記録されている図21b参照。クライアントCがアップロード要求をすると、構成管理処理部121は、配布管理テーブル126図20aを参照し、クライアントCに配布したソースファイルの版番1を取得し、競合検出処理部122は、変更管理テーブル127図20bを参照し、配布した版番より新しい履歴版番2、版番3があるため、変更部位としてノードN3,N4を取得し、クライアントCの変更内容であるノードN6は、変更部位に含まれていないと判定する。次に、競合検出処理部122は、実行ノードテーブル227図20cを参照して、変更部位N3,N4が実行ノードに存在するため、競合ありと判定し、アップロードに失敗する。テスト実行で通った部分にマスタソースの変更がある場合は、アップロードに失敗する。アップロードに失敗したため、クライアントCのアップロード要求による変更内容は統合されず、マスタソースの状態は図21のままで変化しない。すなわち、図20dに示すように変更管理テーブル127は、版番3のままで変化しない。実施例6図22は、実施例6のマスタの再取得により変更管理テーブルの変更部位と競合しない既存ノード変更でアップロードに成功するケースにおける各テーブルの状態を示す図であり、aはアップロード前の配布管理テーブルの状態、bはアップロード前の変更管理テーブルの状態、cは実行ノードテーブルの状態、dはアップロード後の変更管理テーブルの状態、eはアップロード後の配布管理テーブルの状態を示す。図23は、実施例6において、aは版番3に基づいたクライアントCによる変更と実行ノードを説明する図であり、bはアップロード後の版番4のマスタの状態を示す図である。実施例6では、実施例5でアップロードに失敗したクライアントCが、再度ソースファイルのダウンロード要求をし、最新版である版番3のソースファイルを取得し、ノードN6を変更してアップロードする例を示す。図22aに示すように、クライアントCは版番3をダウンロードしている。図22bに示すように、版番2には変更部位としてノードN3があり、版番3には変更部位としてノードN4がある。図22cのクライアントCの実行ノードテーブル227には、変更したノードN6を含む経路情報が記録されている図23a参照。クライアントCがアップロード要求をすると、構成管理処理部121は、配布管理テーブル126図22aを参照し、クライアントCに配布したソースファイルの版番3を取得し、競合検出処理部122は、変更管理テーブル127図22bを参照し、配布した版番より新しい履歴がないため、変更部位はなしを取得し、変更部位がないため、競合なしと判定する。すなわち、マスタソースの最新版と同じ版番を基に変更した場合、競合する変更が存在しないため、アップロードに成功する。アップロードに成功したため、図22dに示すように変更管理テーブル127には、版番4が登録される。登録されたアップロード後のマスタソースの状態は、図23bに示す。クライアントCは、引き続きソースファイルを変更するため、また、今後の変更に備えてダウンロード要求をすると、配布管理テーブル126は、図22eに示すようにクライアントCについて版番4を登録する。実施例7図24は、実施例7の変更管理テーブルの変更部位と競合する新規ノード追加でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、aはアップロード前の配布管理テーブルの状態、bはアップロード前の変更管理テーブルの状態、cは実行ノードテーブルの状態、dはアップロードの失敗後の変更管理テーブルの状態を示す。図25は、実施例7において、aはアップロード前の版番4のマスタの状態を示す図であり、bは版番2に基づいたクライアントAによる変更と実行ノードを説明する図である。実施例7では、実施例6を行った後にクライアントAが版番2のノードN1とノードN2の間にノードN9を追加してアップロードする例を示す。図24aに示すように、クライアントAは版番2をダウンロードしている。図24bに示すように、版番2には変更部位としてノードN3があり、版番3には変更部位としてノードN4があり、版番4には、変更部位としてノードN6がある図25a参照。図24cのクライアントAの実行ノードテーブル227には、変更したノードN9を含む経路情報が記録されている図25b参照。クライアントAがアップロード要求をすると、構成管理処理部121は、配布管理テーブル126図24aを参照し、クライアントAに配布したソースファイルの版番2を取得し、クライアントAの変更内容として、ノードN1,N2,N9を取得する。なお、構成管理処理部121は、追加ノードはN9であるがノード間のつながりも変更されているので、変更内容としてノードN1,N2も取得している。すなわち、ノードを追加した場合は、追加したノードの前後のノードも変更内容として抽出することで、追加位置と影響範囲が管理される。競合検出処理部122は、変更管理テーブル127図24bを参照し、配布した版番より新しい履歴版番3、版番4があるため、変更部位としてノードN4,N6を取得し、クライアントAの変更内容は、変更部位に含まれていないと判定する。次に、競合検出処理部122は、実行ノードテーブル227図24cを参照して、変更部位N4,N6が実行ノードに存在するため、競合ありと判定し、アップロードに失敗する。アップロードに失敗したため、クライアントAのアップロード要求による変更内容は統合されず、マスタソースの状態は図25のままで変化しない。すなわち、図24dに示すように変更管理テーブル127は、版番4のままで変化しない。実施例8図26は、実施例8のマスタの再取得により新規ノード追加でアップロードに成功するケースにおける各テーブルの状態を示す図であり、aはアップロード前の配布管理テーブルの状態、bはアップロード前の変更管理テーブルの状態、cは実行ノードテーブルの状態、dはアップロード後の変更管理テーブルの状態を示す。図27は、実施例8において、aは版番4に基づいたクライアントAによる変更と実行ノードを説明する図であり、bはアップロード後の版番5のマスタの状態を示す図である。実施例8では、実施例7でアップロードに失敗したクライアントAが、再度ソースファイルのダウンロード要求をし、最新版である版番4のソースファイルを取得し、ノードN1とノードN2間にノードN9を追加してアップロードする例を示す。図26aに示すように、クライアントAは版番4をダウンロードしている。図26bに示すように、版番2には変更部位としてノードN3があり、版番3には変更部位としてノードN4があり、版番4には、変更部位としてノードN6がある。図26cのクライアントAの実行ノードテーブル227には、追加したノードN9を含む経路情報が記録されている図27a参照。クライアントAがアップロード要求をすると、構成管理処理部121は、配布管理テーブル126図26aを参照し、クライアントAに配布したソースファイルの版番4を取得し、クライアントAの変更内容として、ノードN1,N2,N9を取得する。競合検出処理部122は、変更管理テーブル127図26bを参照し、配布した版番より新しい履歴がないため、変更部位はなしを取得し、変更部位がないため、競合なしと判定する。すなわち、マスタソースの最新版と同じ版番を基に変更した場合、競合する変更が存在しないため、アップロードに成功する。アップロードに成功したため、図26dに示すように変更管理テーブル127には、版番5が登録される。登録されたアップロード後のマスタソースの状態は、図27bに示す。クライアントAは、引き続きソースファイルを変更するため、また、今後の変更に備えてダウンロード要求をすると、配布管理テーブル126は、クライアントAについて版番5を登録する。実施例9図28は、実施例9の変更管理テーブルの変更部位と競合する既存ノード削除でアップロードに失敗するケースにおける各テーブルの状態を示す図であり、aはアップロード前の配布管理テーブルの状態、bはアップロード前の変更管理テーブルの状態、cは実行ノードテーブルの状態、dはアップロードの失敗後の変更管理テーブルの状態を示す。図29は、実施例9において、aはアップロード前の版番5のマスタの状態を示す図であり、bは版番3に基づいたクライアントBによる変更と実行ノードを説明する図である。実施例9では、実施例8を行った後にクライアントBが版番3のノードN7を削除してアップロードする例を示す。図28aに示すように、クライアントBは版番3をダウンロードしている。図28bに示すように、版番2には変更部位としてノードN3があり、版番3には変更部位としてノードN4があり、版番4には変更部位としてノードN6があり、版番5には変更部位としてノードN1,N2,N9がある図29a参照。図28cのクライアントBの実行ノードテーブル227には、削除したノードN7を含まない経路情報が記録されている図29b参照。クライアントBがアップロード要求をすると、構成管理処理部121は、配布管理テーブル126図28aを参照し、クライアントBに配布したソースファイルの版番3を取得し、競合検出処理部122は、変更管理テーブル127図28bを参照し、配布した版番より新しい履歴版番4、版番5があるため、変更部位としてノードN1,N2,N6,N9を取得し、クライアントBの削除ノードN7は、変更部位に含まれていないと判定する。次に、競合検出処理部122は、実行ノードテーブル227図28cを参照して、変更部位N1,N2,N6が実行ノードに存在するため、競合ありと判定し、アップロードに失敗する。テスト実行で通った部分にマスタソースの変更部位がある場合は、アップロードに失敗する。アップロードに失敗したため、クライアントBのアップロード要求による変更内容は統合されず、マスタソースの状態は図29のままで変化しない。すなわち、図28dに示すように変更管理テーブル127は、版番5のままで変化しない。実施例10図30は、実施例10のマスタの再取得により既存ノード削除でアップロードに成功するケースにおける各テーブルの状態を示す図であり、aはアップロード前の配布管理テーブルの状態、bはアップロード前の変更管理テーブルの状態、cは実行ノードテーブルの状態、dはアップロード後の変更管理テーブルの状態を示す。図31は、実施例10において、aは版番5に基づいたクライアントBによる変更と実行ノードを説明する図であり、bはアップロード後の版番6のマスタの状態を示す図である。実施例10では、実施例9でアップロードに失敗したクライアントBが、再度ソースファイルのダウンロード要求をし、最新版である版番5のソースファイルを取得し、ノードN7を削除してアップロードする例を示す。図30aに示すように、クライアントBは版番5をダウンロードしている。図30bに示すように、版番2には変更部位としてノードN3があり、版番3には変更部位としてノードN4があり、版番4には、変更部位としてノードN6があり、版番5には変更部位としてノードN1,N2,N6がある。図30cのクライアントBの実行ノードテーブル227には、削除したノードN7を含まない経路情報が記録されている図31a参照。クライアントBがアップロード要求をすると、構成管理処理部121は、配布管理テーブル126図30aを参照し、クライアントBに配布したソースファイルの版番5を取得する。競合検出処理部122は、変更管理テーブル127図30bを参照し、配布した版番より新しい履歴がないため、変更部位はなしを取得し、変更部位がないため、競合なしと判定する。すなわち、マスタソースの最新版と同じ版番を基に変更した場合、競合する変更が存在しないため、アップロードに成功する。アップロードに成功したため、図30dに示すように変更管理テーブル127には、版番6が登録される。登録されたアップロード後のマスタソースの状態は、図31bに示す。以上の実施例では、クライアント装置200がひとつのソースファイルをダウンロードし、アップロードする例について説明した。しかし、これに限定される必要はなく複数のソースファイルの場合にも本実施形態は適用することができる。改善箇所や新規機能を実現するために、複数のソースファイルを同時に変更する必要がある。関連あるソースファイルを1つずつアップロードすると、ソースファイルのどれかで競合が発生してアップロードに失敗した場合、一部のソースファイルだけアップロードされてしまい、全体として不完全な状態が発生する可能性がある。具体的には、source1.cおよびsource2.cを同時に変更し、相互に呼び出し関係があるとする。source1.cのアップロードに成功したあと、source2.cのアップロードに失敗すると、管理サーバ装置100では、source1.cのマスタソースしか更新されず、不整合によりコンパイラエラーなどが発生する場合がある。これに対処するため、図32を参照して複数のソースファイルのアップロード要求処理をする場合について説明する。図32は、構成管理処理部のクライアントからの他のアップロード要求処理を示すフローチャートである。図32のフローチャートは図8のフローチャートに基づいており、追加ステップは、複数のソースファイルについて繰り返すペアのループ端であるステップS821およびステップS822、同様にペアのループ端であるステップS831およびステップS832である。変更ステップは、アップロードされたいずれかのソースファイルに競合があるか否かを判定するステップS806Aである。他のステップは、図8と同様であるので説明を省略する。図32によれば、アップロード要求されたソースファイルのすべてについて、ステップS821からステップS822のループ処理で、各変更済みのソースファイルとマスタソースのファイルとに競合があるか否かを判定し、いずれかのファイルに競合がある場合ステップS806A,Yes、ステップS822に進む。一方、すべてのファイルに競合がない場合ステップS806A,No、ステップS831からステップS832のループ処理で、マスタソースに変更内容を統合する。実施例1~10においては、テスト実行処理部221図1参照は、変更対象となるソースファイルをテストした例について示したが、変更したファイルだけでなく、テストの前提となる経路呼び出し元などに競合がないことを確認することで、マスタソースに変更ファイルを統合する際の品質向上を図ることができる。図33は、aは複数のソースファイルが親子の関係にある場合の実行ノードテーブルを示す図であり、bは呼び出し元から変更対象のソースファイルの実行ノードを説明する図である。図33bに示すように、テスト実行処理部221は、例えば、呼び出し元source2.cのノードN13から呼び出し先source3.cを実行する。クライアントAがsource3.cを変更する場合、その呼び出し元であるsource2.cも管理サーバ100から配布を受けてテスト実行する。図33aに示すクライアントAの実行ノードテーブル227には、source3.cだけでなく、source2.cのテスト実行ノードも記録され、競合検出の範囲を拡大することができる。本実施形態では、実行ノード記録処理部222図1参照において、実行ノードを記録している。ノードは、図10では、処理ブロック、判定ブロックなどとして説明しているが、ステップごとに記録してもよい。ステップとは、コンピュータの処理段階を表す単位のことであり、処理の大きさを何ステップであると表現することが一般的である。なお、ステップ数はソースプログラムの命令後の数と対応するが、必ずしもプログラミング言語の単語数とは一致せず、言語によっては複数の単語で1ステップの処理が定義されている場合もある。また、本実施形態では、ノードをモジュールやライブラリと設定することで、複数のモジュールやライブラリから構成されるシステムを変更する際の競合を検出することができる。本実施形態によれば、管理サーバ装置100からダウンロードしたソースファイルについて、クライアント装置200のテスト実行処理部221が作業者が変更したノードを含むソースファイルをテストをする際に、実行ノード記録処理部222がテストで実行したノードの経路情報変更に伴う影響範囲を記録し、アップロード処理部225がノードの経路情報を添付して変更したソースファイルのアップロード要求を管理サーバ装置100にする。管理サーバ装置100は、競合検出処理部122が該変更に伴う影響範囲を他の作業者が変更加えていなかった場合に競合がないと判定し、構成管理処理部121がマスタソースに変更したソースファイルの統合をする。複数の作業者が並行開発している複数のノードから構成されるソースファイルを効率よく管理することができる。"