不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータに実行させるデータチェックプログラムであって、第1システムが有する前記管理データから生成されるチェック用データを取得し、前記第1システムと、当該第1システムとは異なる第2システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第2システムに適合するか否かを判定し、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する、処理を前記コンピュータに実行させるデータチェックプログラム。前記判定する処理を前記第1システムから前記第2システムへの管理データ移行の前に行うことを特徴とする請求項1に記載のデータチェックプログラム。前記判定する処理は、前記条件に基づいて、複数のチェック用データ間の整合が取れているか否かを判定することを特徴とする請求項1又は2に記載のデータチェックプログラム。前記判定する処理は、前記条件が複数ある場合に、当該複数の条件それぞれに基づいて判定し、前記出力する処理では、前記複数の条件の種別と前記第2システムに適合しないチェック用データの数量とを一覧にて出力することを特徴とする請求項1~3のいずれか一項に記載のデータチェックプログラム。前記出力する処理では、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する場合に、判定に用いた条件の重大度を出力することを特徴とする請求項1~4のいずれか一項に記載のデータチェックプログラム。不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータが実行するデータチェック方法であって、第1システムが有する前記管理データから生成されるチェック用データを取得する取得工程と、前記第1システムと、当該第1システムとは異なる第2システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第2システムに適合するか否かを判定する判定工程と、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する出力工程と、を前記コンピュータが実行することを特徴とするデータチェック方法。不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックするデータチェック装置であって、第1システムが有する前記管理データから生成されるチェック用データを取得する取得部と、前記第1システムと、当該第1システムとは異なる第2システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第2システムに適合するか否かを判定する判定部と、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する出力部と、を備えるデータチェック装置。しかしながら、従来行われていたテスト稼動では、上述のように、新システムのプログラムそのもののバグを修繕するという点に視線が注がれていた。また、特許文献1の移行プログラムは、移行データ抽出プログラムが作成した移行データが正しく変換編集されているかをチェックするに過ぎない特許文献1では、移行プログラムは、実質的に、移行インタフェースに合ったデータ形式であるか程度しかチェックできないため。このため、旧システムが管理するデータが、正当性、整合性が保証されないデータであったとしても、当該データが旧システムから新システムにそのまま移行されてしまうおそれがあった。このよう正当性、整合性が保証されていないデータが新システムに移行された場合、新システムが当該データを正しいデータとして扱い、その後の処理を実施してしまうことになる。これにより、新システムにおいて処理エラーが頻発してしまったり、あるいはエラーとはならないものの、誤った計算結果が正しいものとして出力されたりするおそれがある。このため、新システムにおいて処理エラー等を引き起こすデータは、データ移行前に修正しておくことが好ましい。そこで本件は上記の課題に鑑みてなされたものであり、管理データの修正に必要な人員や期間などを適切に推測するための情報を出力することが可能なデータチェックプログラム、データチェック方法及びデータチェック装置を提供することを目的とする。本発明者は、自治体等において利用される業務システムを開発する上で、現在利用されている業務システムの問題点や、新システムへの移行における問題点などを検討した。その結果、本発明者は、1自治体等において古くから用いられている業務システムは、利用者が独自に度重なる改修を施したようなホスト系のシステムである場合が多いため、データベースの構造が煩雑であったり、データ入力時の入力値チェックが実施されなかったりする場合があること、及び2旧システムにおいて入力値チェックが実施され、正当な入力値が入力されたとしても、その後に利用者によりデータ修正等が行われることもあるため、データの正当性、整合性は必ずしも保証されないこと、などについて着目した。そして、本発明者は、自治体等において利用されているシステムに蓄積されたデータそのものの正当性、整合性をチェックすることは、新システムへの移行において非常に重要であるという結論に達した。本明細書では、このような新規知見に基づいて、以下に示すデータチェックプログラム、データチェック方法及びデータチェック装置を開示する。本明細書に記載のデータチェックプログラムは、不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータに実行させるデータチェックプログラムであって、第1システムが有する前記管理データから生成されるチェック用データを取得し、前記第1システムと、当該第1システムとは異なる第2システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第2システムに適合するか否かを判定し、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する、処理を前記コンピュータに実行させるデータチェックプログラムである。本明細書に記載のデータチェック方法は、不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータが実行するデータチェック方法であって、第1システムが有する前記管理データから生成されるチェック用データを取得する取得工程と、前記第1システムと、当該第1システムとは異なる第2システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第2システムに適合するか否かを判定する判定工程と、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する出力工程と、を前記コンピュータが実行するデータチェック方法である。本明細書に記載のデータチェック装置は、不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックするデータチェック装置であって、第1システムが有する前記管理データから生成されるチェック用データを取得する取得部と、前記第1システムと、当該第1システムとは異なる第2システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第2システムに適合するか否かを判定する判定部と、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する出力部と、を備えるデータチェック装置である。本明細書に記載のデータチェックプログラム、データチェック方法及びデータチェック装置は、管理データの修正に必要な人員や期間などを適切に推測するための情報を出力することができるという効果を奏する。以下、一実施形態について、図1~図11に基づいて詳細に説明する。図1は、自治体で利用されている住民情報管理用のシステムを第1システムとしての現行システム100から第2システムとしての新システム200に移行する場合における、データ移行と当該データ移行前に行われるデータチェックとを示す概念図である。現行システム100は、例えばレガシーと呼ばれるシステムであり、新システム200は、オープンシステムであるものとする。これら現行システム100と新システム200では、OSOperatingSystemやDBDatabase、使用プログラム言語など種々の点で異なっている。このため、本実施形態では、図1に示す現行システム100から新システム200への管理データ以下、単にデータと呼ぶの移行に、システム間の相違の影響を受けずにデータを移行するためのデータ移行プログラムが用いられる。また、本実施形態では、システム間におけるデータ移行の前に、現行システム100が保有するデータをデータチェック装置としてのチェックツール端末10にてチェックし、当該チェック結果を出力プリントアウト等する処理が行われる。なお、チェック担当者又はデータ移行担当者以下、単に作業者と呼ぶは、チェックツール端末10から出力されたチェック結果を参照して、現行システム100が保有するデータの修正に要する人員数、時間等を割り出し、データの修正を実行する。図2には、チェックツール端末10のハードウェア構成図が示されている。図2に示すように、チェックツール端末10は、CPU90、ROM92、RAM94、記憶部ここではHDDHardDiskDrive96、入力部93、出力部95、及び可搬型記憶媒体用ドライブ99等を備えている。チェックツール端末10の構成各部は、バス98に接続されている。入力部93は、キーボードやマウスなどの入力装置のほか、外部機器USBメモリや外付けHDDなどが接続可能なインタフェースUSBインタフェースなども含む。出力部95は、ディスプレイやプリンタなどを含む。チェックツール端末10では、ROM92あるいはHDD96に格納されているプログラムデータチェックプログラム、或いは可搬型記憶媒体用ドライブ99が可搬型記憶媒体91から読み取ったプログラムデータチェックプログラムをCPU90が実行することにより、図3に示す各部取得部12、判定部としてのデータチェック部14、出力制御部16が実現される。なお、取得部12、データチェック部14、出力制御部16が実行する処理については、後述する。なお、図3では、図示の便宜上、HDD96等に格納されている条件テーブル22やエラーDB20についてもCPU90内に図示している。図3は、現行システム100とチェックツール端末10におけるデータ処理の流れ及び機能構成を模式的に示す図である。以下、図3に基づいて、現行システム100とチェックツール端末10におけるデータ処理について説明する。図3に示すように、現行システム100では、データ移行プログラムの処理により、データベース102に格納されているデータから、新システム200で用いるデータ抽出データ104を抽出する。次いで、現行システム100では、データ移行プログラムの処理により、抽出データ104を変換加工し、チェック用データ106を生成する。ここで、変換加工には、文字コード変換や個人情報のマスキングなどの処理が含まれる。上記のようにして生成されたチェック用データ106は、現行システム100から、チェックツール端末10に対して転送される。なお、現行システム100からチェックツール端末10に対するチェック用データ106の転送には、USBメモリなどの情報記憶媒体を用いることとしてもよいし、LANLocalAreaNetworkなどのネットワークを用いることとしてもよい。これに対し、チェックツール端末10では、取得部12が、現行システム100から転送されてきたチェック用データ106を取得する。次いで、データチェック部14は、取得部12で取得されたチェック用データ106を取り込み、条件テーブル22に基づいてデータチェックを行う。このデータチェックは、新システム200に対するチェック用データ106の適合不適合に関するチェックである。なお、データチェック部14が実行するデータチェックの詳細については、後述する。データチェック部14におけるチェック結果エラー種別毎のエラー数は、エラーDB20に格納される。エラーDB20に格納されたチェック結果は、出力制御部16によって読み込まれる。そして、出力制御部16は、エラーの種別毎のエラー数を一覧表示したエラーデータ集計表を作成し、出力部95を制御して作成したエラーデータ集計表を出力する。なお、出力部95がディスプレイである場合には、エラーデータ集計表を画面上に表示するものとする。また、出力部95がプリンタである場合には、エラーデータ集計表を紙に印刷するものとする。なお、本実施形態では、出力制御部16と出力部95とにより、エラーデータ集計表を出力する処理が実現されている。次に、データチェック部14の具体的処理について、詳細に説明する。データチェック部14は、チェック用データ106が新システム200に対して適合するか否かを種々の観点から判定チェックする。このチェックには、図4aに示すようなエラーチェックが含まれる。例えば、未入力チェックでは、必須入力項目に対して、値が設定されているかのチェックを行い、不正日チェックでは、ありえない日付が設定されていないかのチェックを行う。また、整合性チェックでは、医療、介護、支援金の各保険料の合計と保険料額の比較等、複数テーブルの項目間の整合性のチェック行い、関連チェックでは、同一世帯主個人番号での世帯主期間が重複していないか等、項目間の関連チェックを行う。以下、データチェック部14で行われる整合性チェックの一例としてのテーブル間整合性チェック、及び年税額チェックについて詳細に説明する。<テーブル間整合性チェック>テーブル間整合性チェックでは、データチェック部14が、図5のフローチャートに沿った処理を実行する。この図5の処理の前提として、データチェック部14は、テーブル間整合性チェックを行う前に、条件テーブル22のうちの1つのチェック項目及びチェック内容を読み込んでいるものとする。ここで、条件テーブル22には、現行システム100では満足しなくても問題とはならない条件であるが、新システム200では満足しなければ問題となる条件、すなわち、現行システム100と新システム200との機能差に起因する条件が含まれているものとする。なお、ここでは、データチェック部14は、図4bのNo.34の条件を読み込んだものとする。このNo.34の条件は、テーブル間整合性チェックの条件であり、現行システム100と新システム200との機能差に起因する条件である。データチェック部14は、図5のステップS10において、図4bの条件テーブル22No.34のチェック項目及びチェック内容の欄に基づいて、世帯被保テーブルの読み込みを行う。ここで、世帯被保テーブルは、図3に示すチェック用データ106のうちの1つであり、図6aに示すようなデータ構造を有している。より具体的には、世帯被保テーブルは、記号番号、世帯被保連番、資格区分の各フィールドを有している。記号番号のフィールドには各世帯に振られた通し番号が入力され、世帯被保連番のフィールドには、世帯に含まれる被保険者に振られた通し番号が入力される。また、資格区分のフィールドには、世帯主であれば1、世帯主以外であれば0が入力される。図5に戻り、次のステップS12では、データチェック部14が、図4bの条件テーブル22No.34のチェック項目及びチェック内容の欄に基づいて、世帯主テーブルの読み込みを行う。ここで、世帯主テーブルは、チェック用データ106のうちの1つであり、図6bに示すようなデータ構造を有している。より具体的には、世帯主テーブルは、記号番号、世帯被保連番の各フィールドを有している。この世帯主テーブルには、各世帯の世帯主の記号番号と世帯被保連番が入力されることになる。すなわち、図6aの世帯被保テーブルにおいて、資格区分が1となっている人が、図6bの世帯主テーブルに纏められている。図5に戻り、次のステップS14では、データチェック部14が、世帯被保テーブルの中から未選択の世帯主レコードを1つ選択する。ここで、世帯主レコードとは、図6aの世帯被保テーブルの資格区分の値が1になっているレコードを意味する。ここでは、データチェック部14は、記号番号0000000121、世帯被保番号1のレコードを選択したものとする。次いで、ステップS16では、データチェック部14が、条件テーブル22No.34のチェック内容の欄に基づいて、世帯被保テーブルの世帯主レコードに対応する世帯主テーブルのレコードが存在するか否かを判断する。この場合、ステップS14で選択した記号番号0000000121、世帯被保番号1のレコードは、図6bの世帯主テーブルに存在しているので、判断は肯定され、ステップS20に移行する。なお、ステップS16の判断が肯定された場合、選択されているレコードは、新システム200に適合しているレコードであるといえる。ステップS20に移行すると、データチェック部14は、全ての世帯被保テーブルのレコードの選択が完了したか否かを判断する。このステップS20の判断が否定された場合には、ステップS14に戻る。そして、ステップS14では、世帯被保テーブルの次の世帯主レコードを選択する。ここでは、データチェック部14は、記号番号0000000122、世帯被保番号1のレコードを選択したものとする。次いで、ステップS16では、データチェック部14が、世帯被保テーブルの世帯主レコードに対応する世帯主テーブルのレコードが存在するか否かを判断するが、ここでの判断は肯定されるので、ステップS20に移行する。そして、ステップS20の判断が否定された場合には、再度ステップS14に戻る。ステップS14に戻ると、データチェック部14は、次の世帯主レコード記号番号0000000123、世帯被保番号1を選択する。そして、次のステップS16では、データチェック部14が、選択した世帯主レコードが世帯主テーブル図6bに存在しているか否かを判断する。ここでは、図6bに選択した世帯主レコードが存在していないので、ステップS16の判断は否定され、ステップS18に移行する。この場合、選択されているレコードは、新システム200に適合していないレコードであるといえる。ステップS18に移行すると、データチェック部14は、条件テーブル22の備考欄に基づいて、No.279資格のエラーをエラーDB20に格納する。なお、エラーDB20は、エラーNo.毎のエラー個数が格納されるデータベースである。その後は、ステップS20に移行する。上記のように、処理を繰返し、全ての世帯被保テーブルの世帯主レコードの選択が完了した段階で、図5の全処理が終了する。以上のような処理により、条件テーブル22のNo.34に関するエラーチェックが完了する。なお、図5の処理でエラーが生じた場合、世帯被保テーブルの世帯主レコードと世帯主テーブルのいずれが正しいかを、現行システム100のデータ移行プログラム等が自動で判断することは難しい。これは、世帯被保テーブルや世帯主テーブルのデータは、住民不特定多数の人の申請に基づいて登録するデータであるため、いずれのデータが正しいかは、当事者である住民に確認をとらなければ分からないからである。<年税額チェック>次に、年税額チェックについて説明する。年税額チェックでは、データチェック部14は、図8のフローチャートに沿った処理を実行する。この図8の処理の前提として、データチェック部14は、年税額チェックを行う前に、条件テーブル22のうちの1つの条件図7のNo.52を読み込んだものとする。このNo.52の条件は、前述したNo.34の条件と同様、現行システム100と新システム200との機能差に起因する条件である。データチェック部14は、図8のステップS30において、図7の条件テーブル22No.52のチェック項目及びチェック内容の欄に基づいて、賦課ファイル再計算の読み込みを行う。ここで、賦課ファイル再計算は、データ移行プログラムが生成したチェック用データ106のうちの1つであり、データ移行される国民健康保険の資格情報や税の情報を基に、新たに賦課計算を行った結果を格納するファイルである。より具体的には、賦課ファイル再計算は、図9aに示すような課税年度、課税識別番号、納税義務者連番、基礎納税額の各フィールドを有している。課税年度のフィールドには、実際に課税された年度が入力され、課税識別番号のフィールドには、課税の種別を示す課税識別番号が入力される。また、納税義務者連番のフィールドには、納税義務者に振られた通し番号が入力され、基礎納税額のフィールドには、データ移行プログラムによる再計算後の基礎納税額が入力される。図8に戻り、次のステップS32では、データチェック部14が、図7の条件テーブル22No.52のチェック項目及びチェック内容の欄に基づいて、期別賦課ファイル現行の読み込みを行う。ここで、期別賦課ファイル現行は、データ移行プログラムが生成したチェック用データ106のうちの1つであり、現行システム100が元々保持していた賦課計算結果を格納するファイルである。この期別賦課ファイル現行は、図9bに示すように、賦課ファイル再計算と同様、課税年度、課税識別番号、納税義務者連番、基礎納税額の各フィールドを有している。次いで、ステップS34では、データチェック部14が、賦課ファイル再計算の未選択のレコードを1つ選択する。次いで、ステップS36では、データチェック部14が、条件テーブル22No.52の上段に基づいて、選択したレコードに対応する期別賦課ファイル現行のレコードが存在するか否かを判断する。ここでの判断が否定された場合、すなわち、選択されているレコードが新システム200に適合しないレコードである場合には、ステップS38において、データチェック部14は、条件テーブル22の備考欄に基づいて、No.106賦課のエラーをエラーDB20に格納する該当エラーNo.のエラー個数がカウントアップされる。その後は、ステップS44に移行する。一方、ステップS36の判断が肯定された場合には、ステップS40において、データチェック部14が、条件テーブル22No.52の下段に基づいて、選択した賦課ファイル再計算のレコードと期別賦課ファイル現行の基礎納付額が同額であるか否かを判断する。ここでの判断が否定された場合、すなわち、選択されているレコードが新システム200に適合しない場合、ステップS42に移行し、データチェック部14は、条件テーブル22の備考欄に基づいて、No.112賦課のエラーをエラーDB20に格納する該当エラーNo.のエラー個数がカウントアップされる。その後は、ステップS44に移行する。一方、ステップS40の判断が肯定された場合には、ステップS42を経ずにステップS44に移行する。そして、ステップS44では、データチェック部14が、全てのレコードの選択が完了したか否かを判断する。ここでの判断が否定された場合には、ステップS34に戻り、ステップS34以降の処理を実行する。一方、ステップS44の判断が肯定された場合には、図8の全処理を終了する。以上のような処理により、条件テーブル22のNo.52に関するエラーチェックが完了する。なお、図8の処理でエラーが生じた場合、賦課ファイル再計算と期別賦課ファイル現行のいずれが正しいかを、現行システム100のデータ移行プログラム等が自動で判断することは難しい。これは、賦課ファイル再計算と期別賦課ファイル現行は、住民不特定多数の人が申請したデータから派生した情報を含んでいるため、いずれのデータが正しいかは、当事者である住民に確認をとらなければ分からない場合が多いからである。なお、本実施形態のチェックツール端末10では、上述したテーブル間整合性チェックや年税額チェックのような多種多様なデータチェックが多数実行される。すなわち、条件テーブル22には、多種多様な条件が定義されている。例えば、データチェック部14が条件テーブル22から読み込んだ条件が不正日チェックであった場合には、現行システム100のデータベース102に格納されている全ての日付データと、年月日のパターンを格納するカレンダテーブルデータチェック部14が保持しているとを比較する。そして、データチェック部14は、日付データと同一の日付がカレンダテーブルに存在していない場合に、エラーと判定する。また、例えば、データチェック部14が条件テーブル22から読み込んだ条件が範囲チェック図4a参照であった場合には、ある値が所定の範囲に含まれているか否かをチェックする。ここで、新システム200において値Aと値Bの差A-Bを求める処理があるとする。また、値Bは正の値であるべきであるのに、現行システム100において負-の値に変更されたとする。この場合、負の値Bをエラーとしないと、値AとBの差A-Bの算出値が誤ってしまう増大してしまう。この場合、新システム200では、算出値の大小からエラーを判断できない判断が難しいが、本実施形態では、現行システム100が管理する値の範囲をチェックすることができるので、上記のような新システム200における算出値の誤りの発生を抑制することが可能となる。以上のような多種多様なチェックを行った結果、エラーとなった場合には、エラーの種別ごとに、エラーDB20に格納される該当エラーNo.のエラー個数がカウントアップされることになる。次に、出力部95から出力されるエラーデータ集計表について説明する。図10にはエラーデータ集計表資格の例が示され、図11には、エラーデータ集計表賦課の例が示されている。これらのエラーデータ集計表には、No.レコード名、チェック項目、チェック内容、エラー内容、件数、前回件数、重大度の各項目が設けられている。なお、No.レコード名、チェック項目、チェック内容、エラー内容、重大度の各項目には、それぞれの内容が予め入力されているものとする。ここで、重大度には、A:重度、B:軽度C:対処不要、D:確認不要等が入力される。この重大度A~Dの区分は、順に、自治体の住民本人に対する確認をしなければ修正できないエラー、作業者が確認すれば修正できるエラー、システム上で自動的に修正されるエラー、修正の必要がないエラーなどとすることができる。出力制御部16は、全てのエラーチェックが終了した段階等のタイミングで、エラーDB20を読み込み、エラーNo.ごとのエラー件数を集計する。そして、出力制御部16は、集計したエラー件数を対応するエラーデータ集計表の件数の欄に入力する。なお、前回件数の欄には、前回エラーチェックを行ったときの件数が入力されることになる。なお、図10のエラーデータ集計表資格では、重大度がA:重度のNo.279のエラーは0件前回件数も0件であることが分かる。また、図11のエラーデータ集計表賦課では、重大度がA:重度のNo.106のエラーは8件前回件数は20件であり、重大度がA:重度のNo.112のエラーは70件前回件数は73件であることが分かる。本実施形態では、このようなエラーデータ集計表が出力されることにより、作業者は、エラーの修正にどの程度の人員が必要か、どの程度の期間を割けばよいか、新システム200稼動までにどの程度の工数が必要か、などを推測することができる。なお、重大度が低いCやDエラーについては、現行システム100内において自動修正するものとする。以上、詳細に説明したように、本実施形態によると、チェックツール端末10は、不特定多数の住民から申請されたデータ例えば世帯のデータ及び当該申請されたデータに基づいて生成されるデータ例えば賦課のデータの少なくとも一方を含むデータをチェックする装置であり、現行システム100が有するデータから生成されるチェック用データ106を取得する取得部12と、現行システム100と、新システム200との機能差に起因する条件条件テーブル22に基づいて、チェック用データ106のエラー新システム200に対する適合不適合をチェックするデータチェック部14と、条件の種別エラーNo.やエラー内容などと、新システム200に適合しないチェック用データの数量とを出力部95を用いて出力する出力制御部16とを備えている。これにより、本実施形態では、データの修正に必要な人員や期間、新システム200稼動までの工数などを適切に推測するための情報を出力することができるので、出力結果を確認した作業者は、エラーの修正に必要な人員や期間、新システム200稼動までの工数などを適切に推測することが可能となる。また、本実施形態では、エラーデータ集計表に、複数のエラーの件数を一覧で表示することとしているので、エラーの修正に必要な人員や期間を複数のエラーを総合して判断推測することが可能である。また、本実施形態では、エラーデータ集計表に重大度の欄を設けているため、作業者は、エラーの重大度を考慮して、エラーの修正に必要な人員や期間を推測することができる。この場合、住民の確認が必要か否かなどを考慮して重大度を設定することで、適切な推測が可能となる。なお、上記実施形態では、エラーデータ集計表に、エラーの件数を表示する場合について説明したが、これに限られるものではない。エラーの数以外の数量、例えば、エラーの出現頻度割合をエラーデータ集計表に表示することとしてもよい。なお、上記実施形態では、現行システム100から新システム200にデータを移行する前に移行前段階で、データのチェックを行う場合について説明したが、これに限られるものではない。例えば、データのシステム間移行とは無関係にシステム間移行を前提とせずに、上記実施形態と同様のデータチェックを行うこととしてもよい。なお、上記実施形態では、自治体の業務システムにおけるシステム移行時のデータチェックに本明細書記載のデータチェックプログラム、データチェック方法及びデータチェック装置を適用した場合について説明した。しかしながら、これに限られるものではない。例えば、国や企業等において、不特定多数の人から申請されたデータや当該申請されたデータに基づいて生成されるデータを扱うシステムにおけるシステム移行やデータチェックに、本明細書記載のデータチェックプログラム、データチェック方法及びデータチェック装置を適用することとしてもよい。なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。プログラムを流通させる場合には、例えば、そのプログラムが記録されたDVDDigitalVersatileDisc、CD-ROMCompactDiscReadOnlyMemoryなどの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施できる。なお、以上の説明に関して更に以下の付記を開示する。付記1不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータに実行させるデータチェックプログラムであって、第1システムが有する前記管理データから生成されるチェック用データを取得し、前記第1システムと、当該第1システムとは異なる第2システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第2システムに適合するか否かを判定し、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する、処理を前記コンピュータに実行させるデータチェックプログラム。付記2前記判定する処理を前記第1システムから前記第2システムへの管理データ移行の前に行うことを特徴とする付記1に記載のデータチェックプログラム。付記3前記判定する処理は、前記条件に基づいて、複数のチェック用データ間の整合が取れているか否かを判定することを特徴とする付記1又は2に記載のデータチェックプログラム。付記4前記判定する処理は、前記条件が複数ある場合に、当該複数の条件それぞれに基づいて判定し、前記出力する処理では、前記複数の条件の種別と前記第2システムに適合しないチェック用データの数量とを一覧にて出力することを特徴とする付記1~3のいずれかに記載のデータチェックプログラム。付記5前記出力する処理では、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する場合に、前記判定に用いた条件の重大度を出力することを特徴とする付記1~4のいずれかに記載のデータチェックプログラム。付記6不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータが実行するデータチェック方法であって、第1システムが有する前記管理データから生成されるチェック用データを取得する取得工程と、前記第1システムと、当該第1システムとは異なる第2システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第2システムに適合するか否かを判定する判定工程と、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する出力工程と、を前記コンピュータが実行することを特徴とするデータチェック方法。付記7前記判定工程を前記第1システムから前記第2システムへの管理データ移行の前に行うことを特徴とする付記6に記載のデータチェック方法。付記8前記判定工程では、前記条件に基づいて、複数のチェック用データ間の整合が取れているか否かを判定することを特徴とする付記6又は7に記載のデータチェック方法。付記9前記判定工程では、前記条件が複数ある場合に、当該複数の条件それぞれに基づいて、前記判定を行い、前記出力工程では、前記複数の条件の種別と前記第2システムに適合しないチェック用データの数量とを一覧にて出力することを特徴とする付記6~8のいずれかに記載のデータチェック方法。付記10前記出力工程では、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する場合に、判定に用いた条件の重大度を出力することを特徴とする付記6~9のいずれかに記載のデータチェック方法。付記11不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックするデータチェック装置であって、第1システムが有する前記管理データから生成されるチェック用データを取得する取得部と、前記第1システムと、当該第1システムとは異なる第2システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第2システムに適合するか否かを判定する判定部と、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する出力部と、を備えるデータチェック装置。付記12前記判定部は、前記判定を前記第1システムから前記第2システムへの管理データ移行の前に行うことを特徴とする付記11に記載のデータチェック装置。付記13前記判定部は、前記条件に基づいて、複数のチェック用データ間の整合が取れているか否かを判定することを特徴とする付記11又は12に記載のデータチェック装置。付記14前記判定部は、前記条件が複数ある場合には、複数の条件それぞれに基づいて、前記判定を行い、前記出力部は、前記複数の条件の種別と前記第2システムに適合しないチェック用データの数量とを一覧にて出力することを特徴とする付記11~13のいずれかに記載のデータチェック装置。付記15前記出力部は、前記条件の種別と当該条件に基づく判定の結果得られた前記第2システムに適合しないチェック用データの数量とを出力する場合に、前記判定に用いた条件の重大度を出力することを特徴とする付記11~14のいずれかに記載のデータチェック装置。