"共有ソフトウェアを格納するデータベースとしてのソフトウェア資産管理リポジトリと、該データベースを管理する管理処理部とを備え、前記共有ソフトウェアを利用する複数の利用者端末とネットワークで接続される、共有ソフトウェアのリポジトリ管理システムであって、前記管理処理部は、前記利用者端末から前記共有ソフトウェアに関する複数の変更提案のデータを受け付け、前記複数の変更提案が、統合できる蓋然性の高い所定の制約を満たしているとき、統合変更案を作成し、該統合変更案による統合変更の可否判定の合議を関連部署に依頼する機能と、該合議の結果を受け取って前記共有ソフトウェアに適用する機能とを有することを特徴とする共有ソフトウェアのリポジトリ管理システム。請求項1において、前記統合できる蓋然性の高い所定の制約とは、該所定の制約と一部の付加情報のみで、前記複数の変更提案から前記統合変更案を自動生成できるものであり、該一部の付加情報は前記合議において与えられるものであることを特徴とする共有ソフトウェアのリポジトリ管理システム。請求項2において、前記所定の制約を全て満たすとは、次の条件1~5を全て満たす場合である1関数のパラメータには変更がなく、2第1パラメータは機能番号を表し、3この変更では機能追加のみを行い、4従来プログラムへのコード変更も追加のみ、5変数への代入は予め決められた変数の集合、あるいは、追加した変数のみことを特徴とする共有ソフトウェアのリポジトリ管理システム。請求項3において、前記所定の制約とは、前記複数の変更提案が前記条件1~5を満たし、かつ、前記関数のパラメータには決まったデータ型のパラメータの追加が許されるものであることを特徴とする共有ソフトウェアのリポジトリ管理システム。請求項3において、前記管理処理部は、前記複数の変更提案が複数の類似する機能を含む場合に、前記複数の類似する機能を拡張した機能で前記複数の類似する機能を統合する案を生成することを特徴とする共有ソフトウェアのリポジトリ管理システム。請求項4において、前記管理処理部は、追加された前記パラメータの型や説明が類似している場合に、それらを1つにできないか前記合議を図る資料を生成することを特徴とする共有ソフトウェアのリポジトリ管理システム。請求項2において、前記統合できる蓋然性の高い所定の制約とは、前記複数の変更提案が、元の関数から呼び出している関数を、より性能のよい関数に置き換える範囲内の変更であることを特徴とする共有ソフトウェアのリポジトリ管理システム。請求項7において、前記管理処理部は、前記複数の部署から同じ関数が異なる関数に置き換える提案があった場合は、どのように変更するかを決める合議資料を生成し、全ての置換えが矛盾なく実行できる場合は全て採用する合議資料を生成することを特徴とする共有ソフトウェアのリポジトリ管理システム。請求項2において、前記利用者端末から受け付ける前記変更提案のデータには、変更されるファイル名称、それが前記予め決められた制約を満たすのかどうか、変更される対象の関数、及び、変更の内容が記述されていることを特徴とする共有ソフトウェアのリポジトリ管理システム。請求項2において、前記管理処理部は、前記端末からの前記共有ソフトウェアの変更提案データを受け付ける変更受付部と、送られてきた前記変更提案データを蓄えておく変更提案ストック用データベースと、前記複数の変更提案データから統合変更提案を作成する統合変更案作成部と、作成された前記統合変更提案を前記関連部署の端末に送りって、該関連部署間の合議を依頼する合議実行部と、前記関連部署間の合議結果を受け取って変更結果として前記共有ソフトウェアに適用する共有ソフトウェア変更部と、前記変更結果を前記利用者に配信するソフトウェア配信部とからなり、前記統合変更案作成部は、前記変更提案データから前記共有ソフトウェアの同一項目に対する変更を纏め、それらが全て前記予め決められた制約を満たす場合、前記統合変更案を作成して、前記合議実行部に該統合変更案で前記合議の実施を依頼するように指示し、その結果を前記ソフトウェア変更部に送って前記共有ソフトウェアを変更させ、該変更されたソフトウェアを前記ソフトウェア配信部に指示し、前記利用者の各端末に配信することを特徴とする共有ソフトウェアのリポジトリ管理システム。共有ソフトウェアを格納するデータベースとしてのソフトウェア資産管理リポジトリと、制約番号と統合方式の対の集まりからなる統合方式データベースと、更提案データを蓄えておく変更提案ストック用データベースと、管理処理部とを備え、前記共有ソフトウェアを利用する複数の利用者端末とネットワークで接続される、共有ソフトウェアのリポジトリ管理システムであって、前記管理処理部は、前記利用者端末から前記共有ソフトウェアに関する複数の変更提案データを受け付ける機能と、同一項目に対する前記変更提案が、予め決められた制約を満たすか調べる際に、それらの変更提案が前記統合方式データベースの同一の制約番号を満たすかを調べる機能と、前記複数の変更提案が、統合できる蓋然性の高い所定の制約を満たしているとき、前記制約番号に登録されている統合方式を実行することにより作成された統合変更案による統合変更の可否判定の合議を関連部署に依頼する機能と、該合議の結果を受け取って前記共有ソフトウェアに適用する機能とを備えることを特徴とする共有ソフトウェアのリポジトリ管理システム。請求項11において、前記統合できる蓋然性の高い所定の制約とは、該所定の制約と一部の付加情報のみで、前記複数の変更提案から前記統合変更案を自動生成できるものであり、該一部の付加情報は前記合議において与えられるものであることを特徴とする共有ソフトウェアのリポジトリ管理システム。請求項12において、前記利用者の端末から送られてくる前記変更提案データには、変更されるファイル名称、それが予め決められた前記制約を満たすのかどうか、変更される対象の関数、変更の内容が記述されていることを特徴とする共有ソフトウェアのリポジトリ管理システム。共有ソフトウェアを格納するデータベースとしてのソフトウェア資産管理リポジトリと、共有ソフトウェア更新ルールデータベースと、変更提案データを蓄えておく変更提案ストック用データベースと、管理処理部とを備え、前記共有ソフトウェアを利用する複数の利用者端末とネットワークで接続される、共有ソフトウェアのリポジトリ管理システムであって、前記共有ソフトウェア更新ルールデータベースは、前記変更提案ストックの統合や変更の前記共有ソフトウェアへの適用を行う条件を記述した条件部と、その方法を記述した統合方法の組からなるルールを格納しており、前記管理処理部は、時間や変更提案データを受け付けたイベントにより、前記共有ソフトウェア更新ルールデータベースのルールを実行する機能と、前記複数の変更提案が、統合できる蓋然性の高い所定の制約を満たしているとき、前記ルールを実行することで、統合変更案を作成し、該統合変更案による統合変更の可否判定の合議を関連部署に依頼する機能と、該合議の結果を受け取って前記共有ソフトウェアに適用する機能とを有することを特徴とする共有ソフトウェアのリポジトリ管理システム。請求項14において、前記統合できる蓋然性の高い所定の制約とは、該所定の制約と一部の付加情報のみで、前記複数の変更提案から前記統合変更案を自動生成できるものであり、該一部の付加情報は前記合議において与えられるものであることを特徴とする共有ソフトウェアのリポジトリ管理システム。共有ソフトウェアを管理する部門では、複数の開発部署から整合性のない複数の変更、例えば、1つの関数などソフトウェアの同一項目に複数の変更が提案されたとき、それらの整合性の解消方法などを検討し、関連部署を呼んで、変更の合議を行い、確定させる必要がある。このため、共有ソフトウェアの管理工数がかかる。複数の変更提案がお互いに整合性を満たさないとき、できるだけ少ない管理工数でそれらの不整合を解消するリポジトリ管理システムが求められる。さらに、共有ソフトウェアを管理する部門が、複数の開発部署からの変更提案に対して柔軟に対処できるリポジトリ管理システムが望ましい。特許文献1に記載されたものは、複数の作業者が分担してソフトウェアの開発を行う場合において、複数のプログラムモジュール間に整合性がないと判断された場合、整合性がない旨を示す結果、バグ情報、バグ情報に該当するプロセス名などを含む整合性判断情報を表示部に表示し、作業者は、整合性判断情報を確認しながら、プログラムモジュール群の修正を編集画面上で行う。すなわち、個々の作業者が、整合性判断情報を確認しながら整合性があるようにプログラムモジュールを修正し、同階層のプログラムモジュール間のマージが行えるようにする。特許文献1に開示された発明は、ソフトウェアの共同開発を対象としており、整合性の要件は限られた範囲のものである。特許文献1には、広範囲の変更の提案が整合性を満たさないときに、それらを効率良くかつ柔軟に解消するための共有ソフトウェアの管理方法は記載されていない。本発明は、共有ソフトウェアの変更提案の要求に対して、整合性の解消を合理的かつ柔軟な手法で行い、管理部門の工数を大幅に削減することのできる、共有ソフトウェアのリポジトリ管理システムを提供することを目的としている。上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、共有ソフトウェアを格納するデータベースとしてのソフトウェア資産管理リポジトリと、該データベースを管理する管理処理部とを備え、前記共有ソフトウェアを利用する複数の利用者端末とネットワークで接続される、共有ソフトウェアのリポジトリ管理システムであって、前記管理処理部は、前記利用者端末から前記共有ソフトウェアに関する複数の変更提案のデータを受け付け、前記複数の変更提案が、統合できる蓋然性の高い所定の制約を満たしているとき、統合変更案を作成し、該統合変更案による統合変更の可否判定の合議を関連部署に依頼する機能と、該合議の結果を受け取って前記共有ソフトウェアに適用する機能とを有することを特徴とする。本発明によれば、複数の開発部署から同じ共有ソフトウェアに対する異なるが来た場合でも、整合性を合理的かつ柔軟な手法で解消した、共有ソフトウェアの変更統合案を自動作成する。そして、それを合議資料として配布し、合議の結果に従い、修正する。これにより、リポジトリ管理のための工数を大幅に削減することができる。本発明の代表的な実施例によれば、共有ソフトウェアのリポジトリ管理システムは、共有ソフトウェアを格納するデータベースを持ち、該データベースを管理する管理処理部と該データベースに格納されているソフトウェアを利用するための複数の端末とがネットワークで接続され、該管理処理部は、端末からの共有ソフトウェアの変更提案データを受け付ける変更受付部と、送られてきた変更提案データを蓄えておく変更提案ストックと、複数の変更提案から統合された変更提案を作成する統合変更案作成部と、作成された統合変更提案を関連部署に送りって部署間の合議を依頼する合議実行部と、合議結果を受け取ってその内容を共有ソフトウェアに適用する共有ソフトウェア変更部と、変更結果を利用者に配信するソフトウェア配信部からなり、該統合変更案作成部は、共有ソフトウェアの同一項目に対する変更を纏め、それらが全て予め決められた制約を満たす場合、統合変更案を作成して、該合議実行部に該当号変更案で合議実施を依頼するように指示し、その結果をソフトウェア変更部に送って共有ソフトウェアを変更させ、変更結果の共有ソフトウェアをソフトウェア配信部に指示し、利用している端末に配信する。これにより、ソ複数の開発部署から同じ共有ソフトウェアに対する異なる変更提案が来た場合でも、それらの変更提案が、統合できる蓋然性の高い所定の制約を満たしているときは、自動的に共有ソフトウェアの変更統合案を作成する。そして、合議により、一部の付加情報の付加のみで変更提案の統合ができるか否かの良否判定を行う。このような合議結果に基づき、共有ソフトウェアの信頼性を確保しつつニーズに応じた柔軟な修正をすることができる。また、リポジトリ管理のための工数を大幅に削減することができる。本発明の他の実施例の共有ソフトウェアのリポジトリ管理システムによれば、予め決められた制約を守った変更提案の統合方法が複数ある場合に、次々にそのような方法を登録して行く。これにより、整合性を満たす所定の制約について、タイプの異なる複数の制約を登録することで、より広い範囲の不整合を合理的な手法で柔軟に解決することができるようになる。さらに、本発明の他の実施例の共有ソフトウェアのリポジトリ管理システムによれば、変更統合や合議のタイミングをルールで決めたり、また、条件によっては合議をしないで直接共有ソフトウェアを変更し、関連部署に配信するなど、多様な共有ソフトウェア管理を行う。すなわち、合議を開いたり、直接共有ソフトウェアを変更して通知したり、管理する部門の運用方法を変更することができるようにし、より柔軟な運用が可能となる。以下、図面を用いて実施例を説明する。本発明の第1の実施例の共有ソフトウェアのリポジトリ管理システムでは、予め決めた制約を満たす変更提案が複数の開発部署から送られてきたとき、類似した複数の変更提案が、統合できる蓋然性の高い所定の制約を満たしているとき、それらを統合した変更案を作成して、関連部署に合議を案内する。その合議結果により、共有ソフトウェアを更新する。図1を使って、第1の実施例の構成を説明する。図1は、第1の実施例に係る、共有ソフトウェアのリポジトリ管理システムの構成例を示す図である。本実施例の共有ソフトウェアのリポジトリ管理システムは、まず、複数の利用者にソフトウェアを配信する基本的な構成として、共有ソフトウェアの管理を行う管理処理部1002と、複数の利用者側の端末1006がネットワーク1015で接続された形態になっている。また、管理処理部1002には、共有ソフトウェア1003を蓄積するソフトウェア資産管理リポジトリ1001がある。端末1006を使っている利用者は、管理処理部1002から共有ソフトウェア1003を配信してもらい、自分たちが開発する利用側ソフトウェアからそれらの共有ソフトウェア1003を呼び出すことにより、利用する。本発明ではこの基本的な構成に加え、管理処理部1002が、利用者側からの変更提案1005を受け付ける変更提案受付部1007、受け取った変更提案を蓄積しておく変更提案ストック用データベース1004、蓄積された変更提案1005を纏めなおし、統合的な変更案を作成する統合変更案作成部1008、統合変更案作成部が作成した統合変更案を元に関連部署に合議を促し、結果を受け取る合議実行部1012、合議結果に従って共有ソフトウェア1003を実際に変更するソフトウェア変更部1013、その結果の共有ソフトウェアを利用者に配信するソフトウェア配信部1014からなる。管理処理部1002は、さらに、入出力装置の一部として、リポジトリ管理システムを管理する部門の担当者のための、GUI機能付き管理者用ディスプレイ1020も備えている。統合変更案作成部1008は、複数の変更を統合し合議を開催するために、類似した複数の変更提案を纏める変更提案纏め機能1009、類似した複数の変更提案を予め与えられたルールに従って1つに纏めるための統合変更案若しくは統合変更検討案の自動生成機能1010、及び、合議開催指示機能1011の3つの機能を備えている。なお、統合変更案には、複数の変更提案が類似しているものの所定のルールでは1つに統合する具体的な統合変更案を示せない場合にそれを合議の対象とする案件も含まれる。次に、図2、図3により、本実施例による共有ソフトウェアのリポジトリ管理の処理の概要を説明する。管理処理部1002は、利用者側からの変更提案1005を受け付け、変更提案ストック用データベース1004に蓄積するS201。利用者の端末から送られてくる変更提案1005には、変更されるファイル名称、それが予め決められた制約ここでは制約Pとするを満たすのかどうか、変更される対象の関数、変更の内容3000本例では追加等が記述されている。統合変更案作成部1008では、変更提案纏め機能1009により、所定期間、例えば1週間毎に、あるいは所定件数、例えば10件乃至20件毎に、同一項目に対する、換言すると類似した、複数の変更提案を纏めるS202。すなわち、変更提案ストック1004にある変更提案を調べ、同じソフトウェアの項目関数などに対する変更どうしを纏める。次に、統合変更案の自動生成機能1010により、変更提案の全てが、統合できる蓋然性の高い所定の制約を満たす場合に、統合変更案を自動生成するS202。変更提案を統合できる蓋然性が高い所定の制約の例として、関数のパラメータを変えず、新たな機能を追加するのみで、複数の変更提案を統合する場合がある。ここでは、この制約をより明確に定義した制約P300の例を、図3に示す。すなわち、制約P300に該当する例とは、次の条件1~5を全て満たす場合である。1関数のパラメータには変更がなく、2第1パラメータは機能番号を表し、3この変更では機能追加のみを行い、4従来プログラムへのコード変更も追加のみ、5変数への代入は予め決められた変数の集合、あるいは、追加した変数のみ。なお、制約Pの具体的な条件は、上記例に限定されるものでは無い。統合変更案の自動生成機能1010は、それぞれの同じ項目に対する変更提案が上記制約Pを全て満たしているかを調べ、もし、満たしていれば、それらの変更提案を統合した統合変更案を作成するS203。なお、複数の変更提案が上記制約Pを全て満たしている場合に、これらを、合議無しに、リポジトリ管理システムで自動的に統合変更して1つの共有ソフトウェアを自動変更することも考えられる。しかし、予め決めた制約Pによる文言の定義の上では上記条件1~5を満たしていても、この定義を、全ての状態を想定した完全なものにすることは困難であり、一部の事例については実態に合わない事態が発生する可能性がある。例えば、送られてきた追加機能の中には既にあるものと重複するものがあるかもしれない。あるいは、定義された文言上では類似しており統合可能に見える関数、文字列、顧客名等が、実際には明確に区別すべきものであったりすることも考えられる。すべて自動処理するとこれらの事態を排除できず、共有ソフトウェアの信頼性を低下させる要因となる。一方で、上記条件1~5を満たす変更提案については、人間が若干の情報を与えるだけでより統合の可否の正確な判定が可能になり、共有ソフトウェアの信頼性を維持することができる。これを実現するために、統合変更案作成部が作成した統合変更案を元に関連部署に合議を促し、一部の付加情報合議による、統合変更案の良否判定を行うS204。すなわち、合議実行部1012において、関連部署に合議をはかり、統合変更案の承認、あるいは、修正して承認することを依頼してもらう。合議の結果、例えば、似たコードや説明の機能を統合するかどうかが、付加情報として与えられる。この合議実施の結果に基づき、ソフトウェア変更部1013がソフトウェア資産管理リポジトリ1001の共有ソフトウェア1003を変更するS205。この共有ソフトウェア1003の変更は、例えば、管理者が管理者用ディスプレイ1020のGUI機能を使用しながら実行する。そして、変更結果のソフトウェアを、ソフトウェア配信部1014から利用者端末に配信するS206。上記制約Pを採用することにより、共有ソフトウェアの全く自由な編集は制限されるが、複数の追加変更の間にほとんど干渉がない、信頼性の高いソフトウェア構造を、人から一部若干の付加情報を合議で得るのみで、換言するとほぼ自動的に、作ることが可能になる。また、合議の対象になるのは、変更提案を統合できる蓋然性が高い統合変更案のみに限られるので、合議に要する時間も短くて良く、共有ソフトウェアの統合変更処理を効率的に行うことができる。図4は、本発明の装置を実現するコンピュータシステムの例である。本システムの構成要素である図1の管理処理部1002の各機能をコンピュータに実現させるためのプログラムを図4の補助記憶装置404に記憶しておき、またそれぞれの利用者の端末1006の情報をそれぞれ実行時に別のコンピュータシステムの記憶装置403に読み込み、それぞれのコンピュータのCPU402で実行し、キーボード、マウスなどの入力装置404やディスプレイ、スピーカなどの出力装置405を用いてソフトウェア部品のパラメータ設定やそのテスト結果の登録を行うことで本発明の装置を実現することができる。また、図1の構成や機能をコンピュータに実現させるためのプログラムを全て記憶装置403に読み込み、ネットワークに接続された形態ではなく、スタンドアローンの形態で利用者が1人だけの場合でも、従来の利用におけるテスト結果データを活用しながら部品の利用を行うことができる。また、別の実装の方法としては、図1の各部を直接ハードウェアで実現することもできる。次に、図5を使って、統合変更案作成部1008の処理フローを詳細に説明する。まず、処理S5001で、変更提案ストックの中で同じ関数に対する変更提案を纏める。そして、処理S5002で、I=1toNの間、処理S5003以下で各ProposalIに対して統合変更案を作成する処理を繰り返す。条件判定処理S5003で、ProposalIの変更提案は全て制約Pに収まっているかを調べ、この条件が成立するときは、処理S5004以下の一連の処理で統合変更案作成を行なう。まず、処理S5004で、全ての変更提案で追加される機能名、説明、構文要素への操作列をとする。次に、処理S5005で、FNjに重複があれば、名前を変更して解消する。次に、処理S5006で、複数のFNj間のEXPLANATIONjやMODSEQjを比較して、文字列の一致度などで類似度が高いものがあれば、同一の機能の可能性があることを記録する。最後に、処理S5007で、変更統合の合議書を変更対象の関数の記述提案部署のリスト関連部署として、利用している部署と管理部門追加される機能名、説明、変更内容、類似しているものを作成し、合議実行部に依頼して合議を開く。判定処理S5003で条件が成立しないときには、処理S5008で、別の方法で合議する。別の合議の例としては、全ての変更提案を束ねて、関連部署に配り、対面の会議を行うなどである。図6は、複数の開発部署での共有ソフトウェアを統合した例を示している。この例では、開発部署1からの変更提案1005aでは部分2001のように変更したいという提案が来ており、開発部署2からの変更提案1005bでは部分2002のように変更したいという提案が来ている。これらの変更は関数の型を変えていない。この例では、最初のパラメータfnにはこの関数で実行してもらいたい機能の番号が送られるとする。開発部署1からの変更提案1005aでは新しい機能の番号NEWFN1とその実装処理1、開発部署2からの変更提案1005bではでは同じく、新しい機能番号NEWFN2とその実装処理2が追加されている。処理1と処理2の間に干渉がなければ、これらは、変更提案を統合できる蓋然性が高い所定の制約を満たす案件として、統合変更案作成部で統合変更案を作成し、この案を元に関連部署に合議を促し、一部の付加情報合議による、統合変更案の良否判定を行う。統合変更案が採用されると、新しい共有ソフトウェア1050のように2つの変更提案部分2003、2004を取り入れて、開発部署1と開発部署2の両方で利用できる共有ソフトウェアにすることができる。ここで、2つの実装の間に干渉がないというのは、例えば、12つの処理で同じ変数に対して代入していない場合2結果を返すなどの予め許された変数に対しては両方で代入しているが、それ以外では同じ変数に代入していないなどである。図6の例は、合議を省略しても良いようなごく簡単な例である。実際には、このように2つ以上の部署から別々の機能追加の提案が来たとしても、これらが別々の機能であるとは限らない。たまたま、複数の開発部署で同じ、あるいは、片方での変更がより一般的で、それをもう一方の開発部署が使うことができる場合もある。もともと、共有ソフトウェアを複数の開発で利用する目的は、開発量を減らすことなので、このような場合は1つに纏める必要がある。通常、このような機能仕様の決定のためには共有ソフトウェアの管理部署が関係者を集めて合議する必要があり、時間がかかる。本発明はこのような合議を効率化することも目的としており、合議の際の資料として、これらを纏めるかどうかの項目を有する統合変更案を生成する。この統合変更案を生成について、図7~図9を使って説明する。図7は、本発明での変更提案1005の内容を説明する。変更内容3001には、共有ソフトウェアの構文項目個別の宣言文、条件文、場合わけの分、繰り返し文に対する編集操作が書かれている。この例では宣言文DEC001にintx;を追加し、場合わけ文SWITCH001にCMD05の場合の処理を追加することを表している。構文項目を識別するためのDEC001やSWITCH001は最初に共有ソフトウェアを作成するとき、全ての文につけておいても良いし、あるいは、変更提案を出す開発部署がその場でつけて、ほかの開発部署がつけたものと指すものが一致するかどうか調べて、複数の開発部署からの変更が同じものにつけられているかどうか調べても良い。図8は、この変更提案を施すことで変更された共有ソフトウェア1050の例を示している。部分4002がDEC001への追加操作として、部分4003がSWITCH001への追加操作の結果として変更されている。図9は、複数の変更提案を纏め、合議に使う合議書5000の例を表している。合議書5000は、変更提案のタイトル、提案部署変更提案を出してひとつに纏められた部署の集まり、関連部署その共有ソフトウェアを利用している部署の集まり、予め決められた制約制約P内の変更であること、その制約の元に機能拡張として、部分5001に記述されているように、機能名FNA1,FNA2,FNA3,FNB1,FNB2,FNB3,FNC1,FNC2が追加されている。これらの機能にはそれぞれの提案部署、説明、変更内容具体的な共有ソフトウェアへの編集操作が書かれている。また、さらに部分5002は、説明や変更内容が類似なため、同一な変更であったり、あるいはそのうちのいくつかは別の変更の部分として実現できる可能性があったりする部分である。この部分5002は、統合変更案作成部1008が複数の変更提案1005を処理することにより作り出す。また、合議の際は、これらの類似部分5003をどのように纏めるかをこの合議書の上で纏めて、ソフトウェア変更部1013に渡すことで、合議した内容を、即、共有ソフトウェア1003に反映することができる。ここで合議書の上で纏めるとは、例えば、類似部分5003に関して合議書のまま、全部別々でよければ、そのまま承認して、そのデータをソフトウェア変更部1013に渡し、あるいは、FNB2,FNB3がFNB1と同一であることを合議すれば、FNB2,FNB3を消してしまい、あるいは、FNB1を拡張することでFNB2とFNB3がカバーできるなら、FNB2,FNB3を消して、FNB1の説明、変更内容を修正して、ソフトウェア変更部1013に渡せばよい。次に、図10を使って、ソフトウェア変更部1013の処理フローを詳細に説明する。処理S10001で、合議結果で合議された新機能について、処理S10002以下の一連の処理を繰り返し、変更を共有ソフトウェアに取り入れていく。まず、処理S10002で、その機能の構文要素への操作列を適用し共有ソフトウェアを更新する。そして、処理S10003で、ソフトウェア配信部に指示して、更新したソフトウェアを利用先に配信する。本実施例によれば、変更提案が統合できる蓋然性の高い所定の制約を満たしているときは、自動的に共有ソフトウェアの変更統合案を作成する。そして、合議による一部の付加情報の付加のみで、変更提案の統合ができるか否かの良否判定を行う。このような合議結果に基づき、共有ソフトウェアの信頼性を確保しつつニーズに応じた柔軟な修正をすることができる。また、変更統合案を自動的に作成するので、リポジトリ管理のための工数を大幅に削減することができる。さらに、合議の対象になるのは、変更提案を統合できる蓋然性が高い統合変更案のみであり、この点でも、リポジトリ管理を効率的に行うことができる。次に、本発明の実施例2に係る共有ソフトウェアのリポジトリ管理システムついて述べる。実施例2は、複数の変更提案を統合できる蓋然性の高い所定の制約として、実施例1で述べた制約Pのような、予め決められた制約を守った変更提案の統合方法が複数ある場合に、次々にそのような方法を登録して行くことができる共有ソフトウェアのリポジトリ管理システムである。実施例1で述べた制約P以外に、複数の変更提案を統合できる蓋然性が高い制約の例としては、例えば、以下の制約Q、制約Rのようなものがある。制約Q:制約Pにおいて、関数のパラメータには決まったデータ型のパラメータの追加が許される。制約Qのときの統合変更案作成方法:追加されたパラメータの型や説明が類似している場合には、それらを1つにできないか合議を図る資料を生成する。制約R:元の関数から呼び出している関数を、より性能のよい関数に置き換える範囲内の変更である。制約Rのときの統合案作成方法:複数の部署から同じ関数を異なる関数に置き換える提案があった場合は、合議資料を生成しどのように変更するかを決める。そうでなく、全ての置換えが矛盾なく実行できる場合は全て採用する。また、共有ソフトウェア関連部署内で取り決めを行うことにより、複数の案の統合方法と合議事項を決めることができる場合がある。本実施例では、このような場合に共有ソフトウェアのリポジトリ管理システムにそれらの統合方法を組み込む実施例を説明する。図11は、複数の予め決められた制約が複数ある場合の共有ソフトウェアのリポジトリ管理システムの構成図である。この図11では、図1のシステムに対して統合方式データベース1060が追加されている。統合方式データベース1060には、制約番号1,2,...,nとそのときの変更提案の集合を統合する複数の方法Q,R,Zの組6000が登録されている。統合変更案作成部1008は、複数の変更を統合し合議を開催するために、同一項目に対する変更提案纏め機能1082、変更提案での制約に共通な統合方式の検索機能1083、登録されている統合方法の実行機能1084、及び、合議開催指示機能の各機能を備えている。統合変更案作成部1008の統合方式の検索機能1083はこのデータベース1060を検索することで、同じ関数に対する複数の部署からの変更提案1005が同じ制約番号を守っている場合は、それらの変更提案を纏める方法を取り出し、統合方法の実行機能1084により、取り出された方法に従って統合変更案を作成し、合議開催指示機能による合議などを行う。利用者の端末から送られてくる変更提案1005には、変更されるファイル名称、それが予め決められた制約ここでは制約Pとするを満たすのかどうか、変更される対象の関数、変更の内容3002本例では追加等が記述されている。図12を使って、変更案統合機能を複数利用可能な変更案作成部1008の処理フローを詳細に説明する。まず、処理S11001で、変更提案ストックの中で同じ関数に対する変更提案を纏める。そして、処理S11002で、I=1toNの間、処理S11003を繰り返す。条件判定処理S11003で、ProposalIの変更提案が全て同じ制約番号noの制約に収まっているかを調べ、この条件が成立するときは、処理S11004以下の一連の処理を行ない、ProposalIごとの統合変更案を作成する。まず、処理S11004で、統合方式データベースから制約番号noの統合方法を検索し、それをIntegrateMethodsとする。ここで、IntegrateMethodsは統合変更案を作成するための手続きの列であるそして、処理S11005で、ここで作成した統合変更案で合議実行部に依頼して合議を行う。判定処理S11003で条件が成立しないときには、処理S11006で、別の方法で合議する。次に、上記統合方式データベース1060に登録保持される予め決められた制約Qの具体的な例を図13で説明する。図13の共有ソフトウェア1051では、図8の共有ソフトウェア1050に加え、関数fのパラメータに4004のchararg2の部分が追加されている。ここでは、制約Pにおいて決まったデータ型として文字列charが定められているとして、記述している。図13の制約Qを満たす変更提案書1005の例を、図14に示す。ここでは、追加されたパラメータの型や説明が類似している場合には、それらを1つにできないか合議を図る資料を生成する。という統合変更案作成方法に基づき、説明文の中に新たなパラメータ4004が追加されることが示され、また変更内容3003の1行目に関数FUNC001に引数が追加するという内容が書かれている。さらに、上記統合方式データベース1060に登録保持される予め決められた制約Rの具体的な例を図15で説明する。図15の共有ソフトウェア1052では、制約Rを満たすパラメータ4010,4011,4012の変更の例を表している。すなわち、元の関数から呼び出している関数を、より性能のよい関数に置き換える範囲内の変更である。図15の制約Rを満たす変更提案書1005の例を、図16に示す。こでは説明文の中に、速度の問題から呼んでいる関数を高速なものに置き換えるという説明があり、変更内容3004の1行目に2行目にそれぞれ、関数ComputeXCoordinateとComputeYCoordinateを置き換えることが指示されている。統合案作成方法に基づき、複数の部署から同じ関数が異なる関数に置き換える提案があった場合は、合議資料を生成しどのように変更するかを決める。このとき、複数の部署からの変更提案において、速度の問題で置き換える関数に重複がなければ、全ての置換えが矛盾なく実行できるので、それら全てを置き換えればよいが、例えば、部署1と部署2から同じ関数ComputeXCoordinateを、部署1ではFastComputeXCoordinateに、部署2ではQuickComputeXCoordinateに置き換えることを提案された場合は、どちらを採用するか合議が必要である。このように、本実施例では、整合性を満たす所定の制約について、P,Q,R,...のようにタイプの異なる複数の制約を統合方式データベース1060に登録し、これらを変更提案の作成、統合変更案の作成、及び合議実行、ひいては共有ソフトウェアの変更に利用することで、ソフトウェアの信頼性を確保しつつ、より広い範囲の不整合を柔軟に解決することができるようになる。実施例3では、実施例1や実施例2をベースにして、さらに、変更統合や合議のタイミングをルールで決めたり、また、条件によっては合議をしないで直接共有ソフトウェアを変更し、関連部署に配信するなど、より柔軟な共有ソフトウェア管理を行うことができる、共有ソフトウェアのリポジトリ管理システムの例を説明する。図17を使ってこの場合の実施例3の構成を説明する。本実施例では、図1に対して管理処理部1002に共有ソフトウェア更新ルールデータベース1070と共有ソフトウェア更新ルール実行部7003とが追加されている。共有ソフトウェア更新ルールデータベース1070は条件部と統合方法の組の集合ルール7000を保持している。本実施例では変更提案を統合するタイミングもルールで決定できるように時間を計り、通知するタイマー7002も追加してある。共有ソフトウェア更新ルール実行部7003は、変更提案受付部1007やタイマー7002から変更提案受信や一定の時間経過などのイベントを受け取り、それにより起動され、共有ソフトウェア更新ルールデータベース1070のルール7000を調べ、共有ソフトウェアの更新を次に示すように実施する。変更ストック1004に蓄積されている変更提案1005の数や内容、共有ソフトウェア1003を利用している部署の数によっては、合議を行うかどうか、あるいは合議を行う範囲などを柔軟に決めたいことがある。例えば、変更内容としてインタフェース変更を含まず、性能を悪化させない変更で、統合変更案が1つなら、合議を行わず変更を実施して、その通知のみ利用者の端末に送ればよい場合もある。また、利用している部署が多く、かつ、変更提案が少数でかつ、それらを自動的に統合できない場合は、共有としていたものをコピーして、それら少数の変更提案元の関数として別に配布してしまう場合も考えられる。本実施例の共有ソフトウェアのリポジトリ管理システムでは、これらの変更提案に関する統合を管理部門が柔軟に行うため、共有ソフトウェア更新ルール7000を設定することで運用を柔軟に行うことができる。上記の運用例はルールとして書けば以下のようになる。If項目fに対する変更提案の集合をProposalsとする、かつProposalsの個数が1つである、かつProposalsの変更提案はインタフェースを変更しない、かつProposalsの変更提案は性能の悪化がないと記載されている。ThenProposalsの変更提案を実施する。変更された共有ソフトウェアの利用者の端末に通知する。上記の2つ目の例は以下のように記述される。If項目fに対する変更提案の集合をProposalsとする、かつFの利用者数10、かつProposalsの変更提案を統合する方法がない。ThenfをコピーしてProposalsの変更提案を実施する。図18を使って、共有ソフトウェア更新ルール実行部7003の処理フローを詳細に説明する。本手続きは時間経過、変更提案受信などのイベントごとに呼び出される。まず、処理S12001で、管理処理部1002が受信したイベントをEとする。そして、処理S12002で、共有ソフト更新ルール7000が動かなくなるまでの間、処理S12003を繰り返す。処理S12003で、全てのルールRについて、処理S12004を繰り返す。条件判定処理S12004で、ルールRの条件部がイベントEに関連し、かつ、成立するかを調べ、この条件が成立するときは、処理S12005で、ルールRの帰結部を実行する。本実施例によれば、共有ソフトウェア更新ルール実行部7003の機能により、合議を開いたり、直接共有ソフトウェアを変更して通知したり、管理する部門の運用方法を変更することができるようにし、より柔軟で効率の良い運用が可能な共有ソフトウェアのリポジトリ管理システムを提供できる。"