データチェックプログラム、データチェック方法及びデータチェック装置
【課題】データの修正に必要な人員や期間などを適切に推測するための情報を出力する。
【解決手段】チェックツール端末１０は、不特定多数の住民から申請されたデータ（例えば世帯のデータ）及び当該申請されたデータに基づいて生成されるデータ（例えば賦課のデータ）の少なくとも一方を含むデータをチェックする装置であり、現行システム１００が有するデータから生成されるチェック用データ１０６を取得する取得部１２と、現行システムと新システムとの機能差に起因する条件（条件テーブル２２）に基づいて、チェック用データのエラーを判定（チェック）するデータチェック部１４と、条件の種別（エラーＮｏ．やエラー内容など）と新システムに適合しないチェック用データの数とを出力部９５を用いて出力する出力制御部１６とを備えている。
【解決手段】チェックツール端末１０は、不特定多数の住民から申請されたデータ（例えば世帯のデータ）及び当該申請されたデータに基づいて生成されるデータ（例えば賦課のデータ）の少なくとも一方を含むデータをチェックする装置であり、現行システム１００が有するデータから生成されるチェック用データ１０６を取得する取得部１２と、現行システムと新システムとの機能差に起因する条件（条件テーブル２２）に基づいて、チェック用データのエラーを判定（チェック）するデータチェック部１４と、条件の種別（エラーＮｏ．やエラー内容など）と新システムに適合しないチェック用データの数とを出力部９５を用いて出力する出力制御部１６とを備えている。
【発明の詳細な説明】
【技術分野】
【０００１】
本件は、データチェックプログラム、データチェック方法及びデータチェック装置に関する。
【背景技術】
【０００２】
従来、自治体等で利用される業務システムでは、システム利用者の入力支援等を目的とした種々の機能が設けられている。例えば、業務システムの中には、画面上に入力された入力値に対して入力値チェックを実施し、エラーがあった場合に警告を発してシステム利用者にエラーを認知させる機能を有しているシステムもある。このような入力値チェックには、例えば、名前の入力が必須となっている欄に名前が入力されていないにもかかわらず、入力完了のボタンが押された場合にエラーとするチェックや、生年月日の欄にありえない数値（2010/2/30など）が入力された場合にエラーとするチェックが含まれる。入力値がエラーとなった場合、システムではその入力値の受け入れを一切行わないのが一般的である。また、元号等の値をリストボックスから選択させたり、日付をカレンダーから入力させたりすることで、エラーを発生させないようにしている場合もある。すなわち、システムに受け入れられた入力値は、以降の処理において正当な入力値として取り扱われる。
【０００３】
自治体等では、業務に使用しているシステムが老朽化したり、新たに高性能なシステムが開発されたりなどすると、使用しているシステム（現行（旧）システム）から新しいシステム（新システム）への移行を行う場合がある。この場合、データ移行用プログラムを用いて、旧システムで利用していたデータを新システムに移行する必要がある。また、従来は、データを新システムに移行した後に、新システムのプログラムが正常に動くかどうかを移行後のデータを用いてテストするテスト稼動を行っていた。なお、テスト稼動においてエラーが出た場合、システム開発者等は原因分析を行い、新システムのプログラムのバグやデータ移行用プログラムのバグを改修する。そして、その後に新システムの実稼動が開始されることになる。
【０００４】
なお、特許文献１には、介護保険事務支援システムの旧システムから新システムへデータを移行する方法について開示されている。この特許文献１では、移行データ抽出プログラムが、旧システムから新システムで用いるデータを抽出し、当該データを新システム用に変換・編集して移行データを作成する。そして、移行プログラムは、移行データから移行後データを作成するとともに、データチェックを行う。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−２４０５２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来行われていたテスト稼動では、上述のように、新システムのプログラムそのもののバグを修繕するという点に視線が注がれていた。また、特許文献１の移行プログラムは、移行データ抽出プログラムが作成した移行データが正しく変換・編集されているかをチェックするに過ぎない（特許文献１では、移行プログラムは、実質的に、移行インタフェースに合ったデータ形式であるか程度しかチェックできないため）。このため、旧システムが管理するデータが、正当性、整合性が保証されないデータであったとしても、当該データが旧システムから新システムにそのまま移行されてしまうおそれがあった。
【０００７】
このよう正当性、整合性が保証されていないデータが新システムに移行された場合、新システムが当該データを正しいデータとして扱い、その後の処理を実施してしまうことになる。これにより、新システムにおいて処理エラーが頻発してしまったり、あるいはエラーとはならないものの、誤った計算結果が正しいものとして出力されたりするおそれがある。このため、新システムにおいて処理エラー等を引き起こすデータは、データ移行前に修正しておくことが好ましい。
【０００８】
そこで本件は上記の課題に鑑みてなされたものであり、管理データの修正に必要な人員や期間などを適切に推測するための情報を出力することが可能なデータチェックプログラム、データチェック方法及びデータチェック装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明者は、自治体等において利用される業務システムを開発する上で、現在利用されている業務システムの問題点や、新システムへの移行における問題点などを検討した。その結果、本発明者は、（１）自治体等において古くから用いられている業務システムは、利用者が独自に度重なる改修を施したようなホスト系のシステムである場合が多いため、データベースの構造が煩雑であったり、データ入力時の入力値チェックが実施されなかったりする場合があること、及び（２）旧システムにおいて入力値チェックが実施され、正当な入力値が入力されたとしても、その後に利用者によりデータ修正等が行われることもあるため、データの正当性、整合性は必ずしも保証されないこと、などについて着目した。
【００１０】
そして、本発明者は、自治体等において利用されているシステムに蓄積されたデータそのものの正当性、整合性をチェックすることは、新システムへの移行において非常に重要であるという結論に達した。本明細書では、このような新規知見に基づいて、以下に示すデータチェックプログラム、データチェック方法及びデータチェック装置を開示する。
【００１１】
本明細書に記載のデータチェックプログラムは、不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータに実行させるデータチェックプログラムであって、第１システムが有する前記管理データから生成されるチェック用データを取得し、前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定し、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する、処理を前記コンピュータに実行させるデータチェックプログラムである。
【００１２】
本明細書に記載のデータチェック方法は、不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータが実行するデータチェック方法であって、第１システムが有する前記管理データから生成されるチェック用データを取得する取得工程と、前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定する判定工程と、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する出力工程と、を前記コンピュータが実行するデータチェック方法である。
【００１３】
本明細書に記載のデータチェック装置は、不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックするデータチェック装置であって、第１システムが有する前記管理データから生成されるチェック用データを取得する取得部と、前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定する判定部と、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する出力部と、を備えるデータチェック装置である。
【発明の効果】
【００１４】
本明細書に記載のデータチェックプログラム、データチェック方法及びデータチェック装置は、管理データの修正に必要な人員や期間などを適切に推測するための情報を出力することができるという効果を奏する。
【図面の簡単な説明】
【００１５】
【図１】一実施形態の構成及び処理を示す概念図である。
【図２】図１のチェックツール端末のハードウェア構成を示す図である。
【図３】現行システムとチェックツール端末におけるデータ処理の流れを模式的に示す図である。
【図４】図４（ａ）は、エラーチェックの一例を示す表であり、図４（ｂ）は、条件テーブルの例を示す図である。
【図５】データ間整合性チェックの処理を示すフローチャートである。
【図６】図６（ａ）は、世帯被保テーブルの一例を示す図であり、図６（ｂ）は、世帯主テーブルの一例を示す図である。
【図７】条件テーブルの例を示す図である。
【図８】年税額チェックの処理を示すフローチャートである。
【図９】図９（ａ）は、賦課ファイル（再計算）の一例を示す図であり、図９（ｂ）は、期別賦課ファイル（現行）の一例を示す図である。
【図１０】エラーデータ集計表（資格）の一例を示す図である。
【図１１】エラーデータ集計表（賦課）の一例を示す図である。
【発明を実施するための形態】
【００１６】
以下、一実施形態について、図１〜図１１に基づいて詳細に説明する。図１は、自治体で利用されている住民情報管理用のシステムを第１システムとしての現行システム１００から第２システムとしての新システム２００に移行する場合における、データ移行と当該データ移行前に行われるデータチェックとを示す概念図である。
【００１７】
現行システム１００は、例えばレガシーと呼ばれるシステムであり、新システム２００は、オープンシステムであるものとする。これら現行システム１００と新システム２００では、ＯＳ（Operating System）やＤＢ（Database）、使用プログラム言語など種々の点で異なっている。このため、本実施形態では、図１に示す現行システム１００から新システム２００への管理データ（以下、単に「データ」と呼ぶ）の移行に、システム間の相違の影響を受けずにデータを移行するためのデータ移行プログラムが用いられる。
【００１８】
また、本実施形態では、システム間におけるデータ移行の前に、現行システム１００が保有するデータをデータチェック装置としてのチェックツール端末１０にてチェックし、当該チェック結果を出力（プリントアウト等）する処理が行われる。なお、チェック担当者又はデータ移行担当者（以下、単に「作業者」と呼ぶ）は、チェックツール端末１０から出力されたチェック結果を参照して、現行システム１００が保有するデータの修正に要する人員数、時間等を割り出し、データの修正を実行する。
【００１９】
図２には、チェックツール端末１０のハードウェア構成図が示されている。図２に示すように、チェックツール端末１０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、入力部９３、出力部９５、及び可搬型記憶媒体用ドライブ９９等を備えている。チェックツール端末１０の構成各部は、バス９８に接続されている。入力部９３は、キーボードやマウスなどの入力装置のほか、外部機器（ＵＳＢメモリや外付けＨＤＤなど）が接続可能なインタフェース（ＵＳＢインタフェースなど）も含む。出力部９５は、ディスプレイやプリンタなどを含む。
【００２０】
チェックツール端末１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（データチェックプログラム）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（データチェックプログラム）をＣＰＵ９０が実行することにより、図３に示す各部（取得部１２、判定部としてのデータチェック部１４、出力制御部１６）が実現される。なお、取得部１２、データチェック部１４、出力制御部１６が実行する処理については、後述する。なお、図３では、図示の便宜上、ＨＤＤ９６等に格納されている条件テーブル２２やエラーＤＢ２０についてもＣＰＵ９０内に図示している。
【００２１】
図３は、現行システム１００とチェックツール端末１０におけるデータ処理の流れ及び機能構成を模式的に示す図である。以下、図３に基づいて、現行システム１００とチェックツール端末１０におけるデータ処理について説明する。
【００２２】
図３に示すように、現行システム１００では、データ移行プログラムの処理により、データベース１０２に格納されているデータから、新システム２００で用いるデータ（抽出データ１０４）を抽出する。次いで、現行システム１００では、データ移行プログラムの処理により、抽出データ１０４を変換加工し、チェック用データ１０６を生成する。ここで、変換加工には、文字コード変換や個人情報のマスキングなどの処理が含まれる。
【００２３】
上記のようにして生成されたチェック用データ１０６は、現行システム１００から、チェックツール端末１０に対して転送される。なお、現行システム１００からチェックツール端末１０に対するチェック用データ１０６の転送には、ＵＳＢメモリなどの情報記憶媒体を用いることとしてもよいし、ＬＡＮ（Local Area Network）などのネットワークを用いることとしてもよい。
【００２４】
これに対し、チェックツール端末１０では、取得部１２が、現行システム１００から転送されてきたチェック用データ１０６を取得する。次いで、データチェック部１４は、取得部１２で取得されたチェック用データ１０６を取り込み、条件テーブル２２に基づいてデータチェックを行う。このデータチェックは、新システム２００に対するチェック用データ１０６の適合・不適合に関するチェックである。なお、データチェック部１４が実行するデータチェックの詳細については、後述する。データチェック部１４におけるチェック結果（エラー種別毎のエラー数）は、エラーＤＢ２０に格納される。エラーＤＢ２０に格納されたチェック結果は、出力制御部１６によって読み込まれる。そして、出力制御部１６は、エラーの種別毎のエラー数を一覧表示したエラーデータ集計表を作成し、出力部９５を制御して作成したエラーデータ集計表を出力する。なお、出力部９５がディスプレイである場合には、エラーデータ集計表を画面上に表示するものとする。また、出力部９５がプリンタである場合には、エラーデータ集計表を紙に印刷するものとする。なお、本実施形態では、出力制御部１６と出力部９５とにより、エラーデータ集計表を出力する処理が実現されている。
【００２５】
次に、データチェック部１４の具体的処理について、詳細に説明する。データチェック部１４は、チェック用データ１０６が新システム２００に対して適合するか否かを種々の観点から判定（チェック）する。このチェックには、図４（ａ）に示すようなエラーチェックが含まれる。例えば、「未入力チェック」では、必須入力項目に対して、値が設定されているかのチェックを行い、「不正日チェック」では、ありえない日付が設定されていないかのチェックを行う。また、「整合性チェック」では、医療、介護、支援金の各保険料の合計と保険料額の比較等、複数テーブルの項目間の整合性のチェック行い、「関連チェック」では、同一世帯主個人番号での世帯主期間が重複していないか等、項目間の関連チェックを行う。
【００２６】
以下、データチェック部１４で行われる整合性チェックの一例としてのテーブル間整合性チェック、及び年税額チェックについて詳細に説明する。
【００２７】
＜テーブル間整合性チェック＞
テーブル間整合性チェックでは、データチェック部１４が、図５のフローチャートに沿った処理を実行する。この図５の処理の前提として、データチェック部１４は、テーブル間整合性チェックを行う前に、条件テーブル２２のうちの１つのチェック項目及びチェック内容を読み込んでいるものとする。ここで、条件テーブル２２には、現行システム１００では満足しなくても問題とはならない条件であるが、新システム２００では満足しなければ問題となる条件、すなわち、現行システム１００と新システム２００との機能差に起因する条件が含まれているものとする。なお、ここでは、データチェック部１４は、図４（ｂ）のＮｏ．３４の条件を読み込んだものとする。このＮｏ．３４の条件は、テーブル間整合性チェックの条件であり、現行システム１００と新システム２００との機能差に起因する条件である。
【００２８】
データチェック部１４は、図５のステップＳ１０において、図４（ｂ）の条件テーブル２２（Ｎｏ．３４）のチェック項目及びチェック内容の欄に基づいて、世帯被保テーブルの読み込みを行う。ここで、世帯被保テーブルは、図３に示すチェック用データ１０６のうちの１つであり、図６（ａ）に示すようなデータ構造を有している。より具体的には、世帯被保テーブルは、「記号番号」、「世帯被保連番」、「資格区分」の各フィールドを有している。「記号番号」のフィールドには各世帯に振られた通し番号が入力され、「世帯被保連番」のフィールドには、世帯に含まれる被保険者に振られた通し番号が入力される。また、「資格区分」のフィールドには、世帯主であれば「１」、世帯主以外であれば「０」が入力される。
【００２９】
図５に戻り、次のステップＳ１２では、データチェック部１４が、図４（ｂ）の条件テーブル２２（Ｎｏ．３４）のチェック項目及びチェック内容の欄に基づいて、世帯主テーブルの読み込みを行う。ここで、世帯主テーブルは、チェック用データ１０６のうちの１つであり、図６（ｂ）に示すようなデータ構造を有している。より具体的には、世帯主テーブルは、「記号番号」、「世帯被保連番」の各フィールドを有している。この世帯主テーブルには、各世帯の世帯主の記号番号と世帯被保連番が入力されることになる。すなわち、図６（ａ）の世帯被保テーブルにおいて、資格区分が「１」となっている人が、図６（ｂ）の世帯主テーブルに纏められている。
【００３０】
図５に戻り、次のステップＳ１４では、データチェック部１４が、世帯被保テーブルの中から未選択の世帯主レコードを１つ選択する。ここで、世帯主レコードとは、図６（ａ）の世帯被保テーブルの「資格区分」の値が「１」になっているレコードを意味する。ここでは、データチェック部１４は、記号番号「０００００００１２１」、世帯被保番号「１」のレコードを選択したものとする。
【００３１】
次いで、ステップＳ１６では、データチェック部１４が、条件テーブル２２（Ｎｏ．３４）のチェック内容の欄に基づいて、世帯被保テーブルの世帯主レコードに対応する世帯主テーブルのレコードが存在するか否かを判断する。この場合、ステップＳ１４で選択した記号番号「０００００００１２１」、世帯被保番号「１」のレコードは、図６（ｂ）の世帯主テーブルに存在しているので、判断は肯定され、ステップＳ２０に移行する。なお、ステップＳ１６の判断が肯定された場合、選択されているレコードは、新システム２００に適合しているレコードであるといえる。
【００３２】
ステップＳ２０に移行すると、データチェック部１４は、全ての世帯被保テーブルのレコードの選択が完了したか否かを判断する。このステップＳ２０の判断が否定された場合には、ステップＳ１４に戻る。そして、ステップＳ１４では、世帯被保テーブルの次の世帯主レコードを選択する。ここでは、データチェック部１４は、記号番号「０００００００１２２」、世帯被保番号「１」のレコードを選択したものとする。次いで、ステップＳ１６では、データチェック部１４が、世帯被保テーブルの世帯主レコードに対応する世帯主テーブルのレコードが存在するか否かを判断するが、ここでの判断は肯定されるので、ステップＳ２０に移行する。そして、ステップＳ２０の判断が否定された場合には、再度ステップＳ１４に戻る。
【００３３】
ステップＳ１４に戻ると、データチェック部１４は、次の世帯主レコード（記号番号「０００００００１２３」、世帯被保番号「１」）を選択する。そして、次のステップＳ１６では、データチェック部１４が、選択した世帯主レコードが世帯主テーブル（図６（ｂ））に存在しているか否かを判断する。ここでは、図６（ｂ）に選択した世帯主レコードが存在していないので、ステップＳ１６の判断は否定され、ステップＳ１８に移行する。この場合、選択されているレコードは、新システム２００に適合していないレコードであるといえる。
【００３４】
ステップＳ１８に移行すると、データチェック部１４は、条件テーブル２２の備考欄に基づいて、Ｎｏ．２７９（資格）のエラーをエラーＤＢ２０に格納する。なお、エラーＤＢ２０は、エラーＮｏ．毎のエラー個数が格納されるデータベースである。その後は、ステップＳ２０に移行する。
【００３５】
上記のように、処理を繰返し、全ての世帯被保テーブルの世帯主レコードの選択が完了した段階で、図５の全処理が終了する。以上のような処理により、条件テーブル２２のＮｏ．３４に関するエラーチェックが完了する。なお、図５の処理でエラーが生じた場合、世帯被保テーブルの世帯主レコードと世帯主テーブルのいずれが正しいかを、現行システム１００のデータ移行プログラム等が自動で判断することは難しい。これは、世帯被保テーブルや世帯主テーブルのデータは、住民（不特定多数の人）の申請に基づいて登録するデータであるため、いずれのデータが正しいかは、当事者である住民に確認をとらなければ分からないからである。
【００３６】
＜年税額チェック＞
次に、年税額チェックについて説明する。年税額チェックでは、データチェック部１４は、図８のフローチャートに沿った処理を実行する。この図８の処理の前提として、データチェック部１４は、年税額チェックを行う前に、条件テーブル２２のうちの１つの条件（図７のＮｏ．５２）を読み込んだものとする。このＮｏ．５２の条件は、前述したＮｏ．３４の条件と同様、現行システム１００と新システム２００との機能差に起因する条件である。
【００３７】
データチェック部１４は、図８のステップＳ３０において、図７の条件テーブル２２（Ｎｏ．５２）のチェック項目及びチェック内容の欄に基づいて、賦課ファイル（再計算）の読み込みを行う。ここで、賦課ファイル（再計算）は、データ移行プログラムが生成したチェック用データ１０６のうちの１つであり、データ移行される国民健康保険の資格情報や税の情報を基に、新たに賦課計算を行った結果を格納するファイルである。より具体的には、賦課ファイル（再計算）は、図９（ａ）に示すような「課税年度」、「課税識別番号」、「納税義務者連番」、「基礎納税額」の各フィールドを有している。「課税年度」のフィールドには、実際に課税された年度が入力され、「課税識別番号」のフィールドには、課税の種別を示す課税識別番号が入力される。また、「納税義務者連番」のフィールドには、納税義務者に振られた通し番号が入力され、「基礎納税額」のフィールドには、データ移行プログラムによる再計算後の基礎納税額が入力される。
【００３８】
図８に戻り、次のステップＳ３２では、データチェック部１４が、図７の条件テーブル２２（Ｎｏ．５２）のチェック項目及びチェック内容の欄に基づいて、期別賦課ファイル（現行）の読み込みを行う。ここで、期別賦課ファイル（現行）は、データ移行プログラムが生成したチェック用データ１０６のうちの１つであり、現行システム１００が元々保持していた賦課計算結果を格納するファイルである。この期別賦課ファイル（現行）は、図９（ｂ）に示すように、賦課ファイル（再計算）と同様、「課税年度」、「課税識別番号」、「納税義務者連番」、「基礎納税額」の各フィールドを有している。
【００３９】
次いで、ステップＳ３４では、データチェック部１４が、賦課ファイル（再計算）の未選択のレコードを１つ選択する。
【００４０】
次いで、ステップＳ３６では、データチェック部１４が、条件テーブル２２（Ｎｏ．５２の上段）に基づいて、選択したレコードに対応する期別賦課ファイル（現行）のレコードが存在するか否かを判断する。ここでの判断が否定された場合、すなわち、選択されているレコードが新システム２００に適合しないレコードである場合には、ステップＳ３８において、データチェック部１４は、条件テーブル２２の備考欄に基づいて、Ｎｏ．１０６（賦課）のエラーをエラーＤＢ２０に格納する（該当エラーＮｏ．のエラー個数がカウントアップされる）。その後は、ステップＳ４４に移行する。
【００４１】
一方、ステップＳ３６の判断が肯定された場合には、ステップＳ４０において、データチェック部１４が、条件テーブル２２（Ｎｏ．５２の下段）に基づいて、選択した賦課ファイル（再計算）のレコードと期別賦課ファイル（現行）の基礎納付額が同額であるか否かを判断する。ここでの判断が否定された場合、すなわち、選択されているレコードが新システム２００に適合しない場合、ステップＳ４２に移行し、データチェック部１４は、条件テーブル２２の備考欄に基づいて、Ｎｏ．１１２（賦課）のエラーをエラーＤＢ２０に格納する（該当エラーＮｏ．のエラー個数がカウントアップされる）。その後は、ステップＳ４４に移行する。一方、ステップＳ４０の判断が肯定された場合には、ステップＳ４２を経ずにステップＳ４４に移行する。
【００４２】
そして、ステップＳ４４では、データチェック部１４が、全てのレコードの選択が完了したか否かを判断する。ここでの判断が否定された場合には、ステップＳ３４に戻り、ステップＳ３４以降の処理を実行する。一方、ステップＳ４４の判断が肯定された場合には、図８の全処理を終了する。以上のような処理により、条件テーブル２２のＮｏ．５２に関するエラーチェックが完了する。なお、図８の処理でエラーが生じた場合、賦課ファイル（再計算）と期別賦課ファイル（現行）のいずれが正しいかを、現行システム１００のデータ移行プログラム等が自動で判断することは難しい。これは、賦課ファイル（再計算）と期別賦課ファイル（現行）は、住民（不特定多数の人）が申請したデータから派生した情報を含んでいるため、いずれのデータが正しいかは、当事者である住民に確認をとらなければ分からない場合が多いからである。
【００４３】
なお、本実施形態のチェックツール端末１０では、上述したテーブル間整合性チェックや年税額チェックのような多種多様なデータチェックが多数実行される。すなわち、条件テーブル２２には、多種多様な条件が定義されている。例えば、データチェック部１４が条件テーブル２２から読み込んだ条件が不正日チェックであった場合には、現行システム１００のデータベース１０２に格納されている全ての日付データと、年月日のパターンを格納するカレンダテーブル（データチェック部１４が保持している）とを比較する。そして、データチェック部１４は、日付データと同一の日付がカレンダテーブルに存在していない場合に、エラーと判定する。
【００４４】
また、例えば、データチェック部１４が条件テーブル２２から読み込んだ条件が範囲チェック（図４（ａ）参照）であった場合には、ある値が所定の範囲に含まれているか否かをチェックする。ここで、新システム２００において値Ａと値Ｂの差（Ａ−Ｂ）を求める処理があるとする。また、値Ｂは正（＋）の値であるべきであるのに、現行システム１００において負（−）の値に変更されたとする。この場合、負の値Ｂをエラーとしないと、値ＡとＢの差（Ａ−Ｂ）の算出値が誤ってしまう（増大してしまう）。この場合、新システム２００では、算出値の大小からエラーを判断できない（判断が難しい）が、本実施形態では、現行システム１００が管理する値の範囲をチェックすることができるので、上記のような新システム２００における算出値の誤りの発生を抑制することが可能となる。
【００４５】
以上のような多種多様なチェックを行った結果、エラーとなった場合には、エラーの種別ごとに、エラーＤＢ２０に格納される（該当エラーＮｏ．のエラー個数がカウントアップされる）ことになる。
【００４６】
次に、出力部９５から出力されるエラーデータ集計表について説明する。図１０にはエラーデータ集計表（資格）の例が示され、図１１には、エラーデータ集計表（賦課）の例が示されている。これらのエラーデータ集計表には、「Ｎｏ．」「レコード名」、「チェック項目」、「チェック内容」、「エラー内容」、「件数」、「前回件数」、「重大度」の各項目が設けられている。なお、「Ｎｏ．」「レコード名」、「チェック項目」、「チェック内容」、「エラー内容」、「重大度」の各項目には、それぞれの内容が予め入力されているものとする。ここで、「重大度」には、「Ａ：重度」、「Ｂ：軽度」「Ｃ：対処不要」、「Ｄ：確認不要」等が入力される。この重大度Ａ〜Ｄの区分は、順に、自治体の住民本人に対する確認をしなければ修正できないエラー、作業者が確認すれば修正できるエラー、システム上で自動的に修正されるエラー、修正の必要がないエラーなどとすることができる。
【００４７】
出力制御部１６は、全てのエラーチェックが終了した段階等のタイミングで、エラーＤＢ２０を読み込み、エラーＮｏ．ごとのエラー件数を集計する。そして、出力制御部１６は、集計したエラー件数を対応するエラーデータ集計表の「件数」の欄に入力する。なお、「前回件数」の欄には、前回エラーチェックを行ったときの「件数」が入力されることになる。
【００４８】
なお、図１０のエラーデータ集計表（資格）では、重大度が「Ａ：重度」のＮｏ．２７９のエラーは０件（前回件数も０件）であることが分かる。また、図１１のエラーデータ集計表（賦課）では、重大度が「Ａ：重度」のＮｏ．１０６のエラーは８件（前回件数は２０件）であり、重大度が「Ａ：重度」のＮｏ．１１２のエラーは７０件（前回件数は７３件）であることが分かる。本実施形態では、このようなエラーデータ集計表が出力されることにより、作業者は、エラーの修正にどの程度の人員が必要か、どの程度の期間を割けばよいか、新システム２００稼動までにどの程度の工数が必要か、などを推測することができる。なお、重大度が低い（ＣやＤ）エラーについては、現行システム１００内において自動修正するものとする。
【００４９】
以上、詳細に説明したように、本実施形態によると、チェックツール端末１０は、不特定多数の住民から申請されたデータ（例えば世帯のデータ）及び当該申請されたデータに基づいて生成されるデータ（例えば賦課のデータ）の少なくとも一方を含むデータをチェックする装置であり、現行システム１００が有するデータから生成されるチェック用データ１０６を取得する取得部１２と、現行システム１００と、新システム２００との機能差に起因する条件（条件テーブル２２）に基づいて、チェック用データ１０６のエラー（新システム２００に対する適合・不適合）をチェックするデータチェック部１４と、条件の種別（エラーＮｏ．やエラー内容など）と、新システム２００に適合しないチェック用データの数量とを出力部９５を用いて出力する出力制御部１６とを備えている。これにより、本実施形態では、データの修正に必要な人員や期間、新システム２００稼動までの工数などを適切に推測するための情報を出力することができるので、出力結果を確認した作業者は、エラーの修正に必要な人員や期間、新システム２００稼動までの工数などを適切に推測することが可能となる。
【００５０】
また、本実施形態では、エラーデータ集計表に、複数のエラーの件数を一覧で表示することとしているので、エラーの修正に必要な人員や期間を複数のエラーを総合して判断（推測）することが可能である。
【００５１】
また、本実施形態では、エラーデータ集計表に「重大度」の欄を設けているため、作業者は、エラーの重大度を考慮して、エラーの修正に必要な人員や期間を推測することができる。この場合、住民の確認が必要か否かなどを考慮して重大度を設定することで、適切な推測が可能となる。
【００５２】
なお、上記実施形態では、エラーデータ集計表に、エラーの件数を表示する場合について説明したが、これに限られるものではない。エラーの数以外の数量、例えば、エラーの出現頻度（割合）をエラーデータ集計表に表示することとしてもよい。
【００５３】
なお、上記実施形態では、現行システム１００から新システム２００にデータを移行する前に（移行前段階で）、データのチェックを行う場合について説明したが、これに限られるものではない。例えば、データのシステム間移行とは無関係に（システム間移行を前提とせずに）、上記実施形態と同様のデータチェックを行うこととしてもよい。
【００５４】
なお、上記実施形態では、自治体の業務システムにおけるシステム移行時のデータチェックに本明細書記載のデータチェックプログラム、データチェック方法及びデータチェック装置を適用した場合について説明した。しかしながら、これに限られるものではない。例えば、国や企業等において、不特定多数の人から申請されたデータや当該申請されたデータに基づいて生成されるデータを扱うシステムにおけるシステム移行やデータチェックに、本明細書記載のデータチェックプログラム、データチェック方法及びデータチェック装置を適用することとしてもよい。
【００５５】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。
【００５６】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【００５７】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【００５８】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施できる。
【００５９】
なお、以上の説明に関して更に以下の付記を開示する。
（付記１） 不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータに実行させるデータチェックプログラムであって、
第１システムが有する前記管理データから生成されるチェック用データを取得し、
前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定し、
前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する、処理を前記コンピュータに実行させるデータチェックプログラム。
（付記２） 前記判定する処理を前記第１システムから前記第２システムへの管理データ移行の前に行うことを特徴とする付記１に記載のデータチェックプログラム。
（付記３） 前記判定する処理は、前記条件に基づいて、複数のチェック用データ間の整合が取れているか否かを判定することを特徴とする付記１又は２に記載のデータチェックプログラム。
（付記４） 前記判定する処理は、前記条件が複数ある場合に、当該複数の条件それぞれに基づいて判定し、
前記出力する処理では、前記複数の条件の種別と前記第２システムに適合しないチェック用データの数量とを一覧にて出力することを特徴とする付記１〜３のいずれかに記載のデータチェックプログラム。
（付記５） 前記出力する処理では、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する場合に、前記判定に用いた条件の重大度を出力することを特徴とする付記１〜４のいずれかに記載のデータチェックプログラム。
（付記６） 不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータが実行するデータチェック方法であって、
第１システムが有する前記管理データから生成されるチェック用データを取得する取得工程と、
前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定する判定工程と、
前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する出力工程と、を前記コンピュータが実行することを特徴とするデータチェック方法。
（付記７） 前記判定工程を前記第１システムから前記第２システムへの管理データ移行の前に行うことを特徴とする付記６に記載のデータチェック方法。
（付記８） 前記判定工程では、前記条件に基づいて、複数のチェック用データ間の整合が取れているか否かを判定することを特徴とする付記６又は７に記載のデータチェック方法。
（付記９） 前記判定工程では、前記条件が複数ある場合に、当該複数の条件それぞれに基づいて、前記判定を行い、
前記出力工程では、前記複数の条件の種別と前記第２システムに適合しないチェック用データの数量とを一覧にて出力することを特徴とする付記６〜８のいずれかに記載のデータチェック方法。
（付記１０） 前記出力工程では、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する場合に、判定に用いた条件の重大度を出力することを特徴とする付記６〜９のいずれかに記載のデータチェック方法。
（付記１１） 不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックするデータチェック装置であって、
第１システムが有する前記管理データから生成されるチェック用データを取得する取得部と、
前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定する判定部と、
前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する出力部と、を備えるデータチェック装置。
（付記１２） 前記判定部は、前記判定を前記第１システムから前記第２システムへの管理データ移行の前に行うことを特徴とする付記１１に記載のデータチェック装置。
（付記１３） 前記判定部は、前記条件に基づいて、複数のチェック用データ間の整合が取れているか否かを判定することを特徴とする付記１１又は１２に記載のデータチェック装置。
（付記１４） 前記判定部は、前記条件が複数ある場合には、複数の条件それぞれに基づいて、前記判定を行い、
前記出力部は、前記複数の条件の種別と前記第２システムに適合しないチェック用データの数量とを一覧にて出力することを特徴とする付記１１〜１３のいずれかに記載のデータチェック装置。
（付記１５） 前記出力部は、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する場合に、前記判定に用いた条件の重大度を出力することを特徴とする付記１１〜１４のいずれかに記載のデータチェック装置。
【符号の説明】
【００６０】
１０ チェックツール端末（データチェック装置）
１２ 取得部
１４ データチェック部（判定部）
１６ 出力制御部（出力部の一部）
２２ 条件テーブル（条件）
９５ 出力部（出力部の一部）
１００ 現行システム（第１システム）
２００ 新システム（第２システム）
【技術分野】
【０００１】
本件は、データチェックプログラム、データチェック方法及びデータチェック装置に関する。
【背景技術】
【０００２】
従来、自治体等で利用される業務システムでは、システム利用者の入力支援等を目的とした種々の機能が設けられている。例えば、業務システムの中には、画面上に入力された入力値に対して入力値チェックを実施し、エラーがあった場合に警告を発してシステム利用者にエラーを認知させる機能を有しているシステムもある。このような入力値チェックには、例えば、名前の入力が必須となっている欄に名前が入力されていないにもかかわらず、入力完了のボタンが押された場合にエラーとするチェックや、生年月日の欄にありえない数値（2010/2/30など）が入力された場合にエラーとするチェックが含まれる。入力値がエラーとなった場合、システムではその入力値の受け入れを一切行わないのが一般的である。また、元号等の値をリストボックスから選択させたり、日付をカレンダーから入力させたりすることで、エラーを発生させないようにしている場合もある。すなわち、システムに受け入れられた入力値は、以降の処理において正当な入力値として取り扱われる。
【０００３】
自治体等では、業務に使用しているシステムが老朽化したり、新たに高性能なシステムが開発されたりなどすると、使用しているシステム（現行（旧）システム）から新しいシステム（新システム）への移行を行う場合がある。この場合、データ移行用プログラムを用いて、旧システムで利用していたデータを新システムに移行する必要がある。また、従来は、データを新システムに移行した後に、新システムのプログラムが正常に動くかどうかを移行後のデータを用いてテストするテスト稼動を行っていた。なお、テスト稼動においてエラーが出た場合、システム開発者等は原因分析を行い、新システムのプログラムのバグやデータ移行用プログラムのバグを改修する。そして、その後に新システムの実稼動が開始されることになる。
【０００４】
なお、特許文献１には、介護保険事務支援システムの旧システムから新システムへデータを移行する方法について開示されている。この特許文献１では、移行データ抽出プログラムが、旧システムから新システムで用いるデータを抽出し、当該データを新システム用に変換・編集して移行データを作成する。そして、移行プログラムは、移行データから移行後データを作成するとともに、データチェックを行う。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−２４０５２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来行われていたテスト稼動では、上述のように、新システムのプログラムそのもののバグを修繕するという点に視線が注がれていた。また、特許文献１の移行プログラムは、移行データ抽出プログラムが作成した移行データが正しく変換・編集されているかをチェックするに過ぎない（特許文献１では、移行プログラムは、実質的に、移行インタフェースに合ったデータ形式であるか程度しかチェックできないため）。このため、旧システムが管理するデータが、正当性、整合性が保証されないデータであったとしても、当該データが旧システムから新システムにそのまま移行されてしまうおそれがあった。
【０００７】
このよう正当性、整合性が保証されていないデータが新システムに移行された場合、新システムが当該データを正しいデータとして扱い、その後の処理を実施してしまうことになる。これにより、新システムにおいて処理エラーが頻発してしまったり、あるいはエラーとはならないものの、誤った計算結果が正しいものとして出力されたりするおそれがある。このため、新システムにおいて処理エラー等を引き起こすデータは、データ移行前に修正しておくことが好ましい。
【０００８】
そこで本件は上記の課題に鑑みてなされたものであり、管理データの修正に必要な人員や期間などを適切に推測するための情報を出力することが可能なデータチェックプログラム、データチェック方法及びデータチェック装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明者は、自治体等において利用される業務システムを開発する上で、現在利用されている業務システムの問題点や、新システムへの移行における問題点などを検討した。その結果、本発明者は、（１）自治体等において古くから用いられている業務システムは、利用者が独自に度重なる改修を施したようなホスト系のシステムである場合が多いため、データベースの構造が煩雑であったり、データ入力時の入力値チェックが実施されなかったりする場合があること、及び（２）旧システムにおいて入力値チェックが実施され、正当な入力値が入力されたとしても、その後に利用者によりデータ修正等が行われることもあるため、データの正当性、整合性は必ずしも保証されないこと、などについて着目した。
【００１０】
そして、本発明者は、自治体等において利用されているシステムに蓄積されたデータそのものの正当性、整合性をチェックすることは、新システムへの移行において非常に重要であるという結論に達した。本明細書では、このような新規知見に基づいて、以下に示すデータチェックプログラム、データチェック方法及びデータチェック装置を開示する。
【００１１】
本明細書に記載のデータチェックプログラムは、不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータに実行させるデータチェックプログラムであって、第１システムが有する前記管理データから生成されるチェック用データを取得し、前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定し、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する、処理を前記コンピュータに実行させるデータチェックプログラムである。
【００１２】
本明細書に記載のデータチェック方法は、不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータが実行するデータチェック方法であって、第１システムが有する前記管理データから生成されるチェック用データを取得する取得工程と、前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定する判定工程と、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する出力工程と、を前記コンピュータが実行するデータチェック方法である。
【００１３】
本明細書に記載のデータチェック装置は、不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックするデータチェック装置であって、第１システムが有する前記管理データから生成されるチェック用データを取得する取得部と、前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定する判定部と、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する出力部と、を備えるデータチェック装置である。
【発明の効果】
【００１４】
本明細書に記載のデータチェックプログラム、データチェック方法及びデータチェック装置は、管理データの修正に必要な人員や期間などを適切に推測するための情報を出力することができるという効果を奏する。
【図面の簡単な説明】
【００１５】
【図１】一実施形態の構成及び処理を示す概念図である。
【図２】図１のチェックツール端末のハードウェア構成を示す図である。
【図３】現行システムとチェックツール端末におけるデータ処理の流れを模式的に示す図である。
【図４】図４（ａ）は、エラーチェックの一例を示す表であり、図４（ｂ）は、条件テーブルの例を示す図である。
【図５】データ間整合性チェックの処理を示すフローチャートである。
【図６】図６（ａ）は、世帯被保テーブルの一例を示す図であり、図６（ｂ）は、世帯主テーブルの一例を示す図である。
【図７】条件テーブルの例を示す図である。
【図８】年税額チェックの処理を示すフローチャートである。
【図９】図９（ａ）は、賦課ファイル（再計算）の一例を示す図であり、図９（ｂ）は、期別賦課ファイル（現行）の一例を示す図である。
【図１０】エラーデータ集計表（資格）の一例を示す図である。
【図１１】エラーデータ集計表（賦課）の一例を示す図である。
【発明を実施するための形態】
【００１６】
以下、一実施形態について、図１〜図１１に基づいて詳細に説明する。図１は、自治体で利用されている住民情報管理用のシステムを第１システムとしての現行システム１００から第２システムとしての新システム２００に移行する場合における、データ移行と当該データ移行前に行われるデータチェックとを示す概念図である。
【００１７】
現行システム１００は、例えばレガシーと呼ばれるシステムであり、新システム２００は、オープンシステムであるものとする。これら現行システム１００と新システム２００では、ＯＳ（Operating System）やＤＢ（Database）、使用プログラム言語など種々の点で異なっている。このため、本実施形態では、図１に示す現行システム１００から新システム２００への管理データ（以下、単に「データ」と呼ぶ）の移行に、システム間の相違の影響を受けずにデータを移行するためのデータ移行プログラムが用いられる。
【００１８】
また、本実施形態では、システム間におけるデータ移行の前に、現行システム１００が保有するデータをデータチェック装置としてのチェックツール端末１０にてチェックし、当該チェック結果を出力（プリントアウト等）する処理が行われる。なお、チェック担当者又はデータ移行担当者（以下、単に「作業者」と呼ぶ）は、チェックツール端末１０から出力されたチェック結果を参照して、現行システム１００が保有するデータの修正に要する人員数、時間等を割り出し、データの修正を実行する。
【００１９】
図２には、チェックツール端末１０のハードウェア構成図が示されている。図２に示すように、チェックツール端末１０は、ＣＰＵ９０、ＲＯＭ９２、ＲＡＭ９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、入力部９３、出力部９５、及び可搬型記憶媒体用ドライブ９９等を備えている。チェックツール端末１０の構成各部は、バス９８に接続されている。入力部９３は、キーボードやマウスなどの入力装置のほか、外部機器（ＵＳＢメモリや外付けＨＤＤなど）が接続可能なインタフェース（ＵＳＢインタフェースなど）も含む。出力部９５は、ディスプレイやプリンタなどを含む。
【００２０】
チェックツール端末１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（データチェックプログラム）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（データチェックプログラム）をＣＰＵ９０が実行することにより、図３に示す各部（取得部１２、判定部としてのデータチェック部１４、出力制御部１６）が実現される。なお、取得部１２、データチェック部１４、出力制御部１６が実行する処理については、後述する。なお、図３では、図示の便宜上、ＨＤＤ９６等に格納されている条件テーブル２２やエラーＤＢ２０についてもＣＰＵ９０内に図示している。
【００２１】
図３は、現行システム１００とチェックツール端末１０におけるデータ処理の流れ及び機能構成を模式的に示す図である。以下、図３に基づいて、現行システム１００とチェックツール端末１０におけるデータ処理について説明する。
【００２２】
図３に示すように、現行システム１００では、データ移行プログラムの処理により、データベース１０２に格納されているデータから、新システム２００で用いるデータ（抽出データ１０４）を抽出する。次いで、現行システム１００では、データ移行プログラムの処理により、抽出データ１０４を変換加工し、チェック用データ１０６を生成する。ここで、変換加工には、文字コード変換や個人情報のマスキングなどの処理が含まれる。
【００２３】
上記のようにして生成されたチェック用データ１０６は、現行システム１００から、チェックツール端末１０に対して転送される。なお、現行システム１００からチェックツール端末１０に対するチェック用データ１０６の転送には、ＵＳＢメモリなどの情報記憶媒体を用いることとしてもよいし、ＬＡＮ（Local Area Network）などのネットワークを用いることとしてもよい。
【００２４】
これに対し、チェックツール端末１０では、取得部１２が、現行システム１００から転送されてきたチェック用データ１０６を取得する。次いで、データチェック部１４は、取得部１２で取得されたチェック用データ１０６を取り込み、条件テーブル２２に基づいてデータチェックを行う。このデータチェックは、新システム２００に対するチェック用データ１０６の適合・不適合に関するチェックである。なお、データチェック部１４が実行するデータチェックの詳細については、後述する。データチェック部１４におけるチェック結果（エラー種別毎のエラー数）は、エラーＤＢ２０に格納される。エラーＤＢ２０に格納されたチェック結果は、出力制御部１６によって読み込まれる。そして、出力制御部１６は、エラーの種別毎のエラー数を一覧表示したエラーデータ集計表を作成し、出力部９５を制御して作成したエラーデータ集計表を出力する。なお、出力部９５がディスプレイである場合には、エラーデータ集計表を画面上に表示するものとする。また、出力部９５がプリンタである場合には、エラーデータ集計表を紙に印刷するものとする。なお、本実施形態では、出力制御部１６と出力部９５とにより、エラーデータ集計表を出力する処理が実現されている。
【００２５】
次に、データチェック部１４の具体的処理について、詳細に説明する。データチェック部１４は、チェック用データ１０６が新システム２００に対して適合するか否かを種々の観点から判定（チェック）する。このチェックには、図４（ａ）に示すようなエラーチェックが含まれる。例えば、「未入力チェック」では、必須入力項目に対して、値が設定されているかのチェックを行い、「不正日チェック」では、ありえない日付が設定されていないかのチェックを行う。また、「整合性チェック」では、医療、介護、支援金の各保険料の合計と保険料額の比較等、複数テーブルの項目間の整合性のチェック行い、「関連チェック」では、同一世帯主個人番号での世帯主期間が重複していないか等、項目間の関連チェックを行う。
【００２６】
以下、データチェック部１４で行われる整合性チェックの一例としてのテーブル間整合性チェック、及び年税額チェックについて詳細に説明する。
【００２７】
＜テーブル間整合性チェック＞
テーブル間整合性チェックでは、データチェック部１４が、図５のフローチャートに沿った処理を実行する。この図５の処理の前提として、データチェック部１４は、テーブル間整合性チェックを行う前に、条件テーブル２２のうちの１つのチェック項目及びチェック内容を読み込んでいるものとする。ここで、条件テーブル２２には、現行システム１００では満足しなくても問題とはならない条件であるが、新システム２００では満足しなければ問題となる条件、すなわち、現行システム１００と新システム２００との機能差に起因する条件が含まれているものとする。なお、ここでは、データチェック部１４は、図４（ｂ）のＮｏ．３４の条件を読み込んだものとする。このＮｏ．３４の条件は、テーブル間整合性チェックの条件であり、現行システム１００と新システム２００との機能差に起因する条件である。
【００２８】
データチェック部１４は、図５のステップＳ１０において、図４（ｂ）の条件テーブル２２（Ｎｏ．３４）のチェック項目及びチェック内容の欄に基づいて、世帯被保テーブルの読み込みを行う。ここで、世帯被保テーブルは、図３に示すチェック用データ１０６のうちの１つであり、図６（ａ）に示すようなデータ構造を有している。より具体的には、世帯被保テーブルは、「記号番号」、「世帯被保連番」、「資格区分」の各フィールドを有している。「記号番号」のフィールドには各世帯に振られた通し番号が入力され、「世帯被保連番」のフィールドには、世帯に含まれる被保険者に振られた通し番号が入力される。また、「資格区分」のフィールドには、世帯主であれば「１」、世帯主以外であれば「０」が入力される。
【００２９】
図５に戻り、次のステップＳ１２では、データチェック部１４が、図４（ｂ）の条件テーブル２２（Ｎｏ．３４）のチェック項目及びチェック内容の欄に基づいて、世帯主テーブルの読み込みを行う。ここで、世帯主テーブルは、チェック用データ１０６のうちの１つであり、図６（ｂ）に示すようなデータ構造を有している。より具体的には、世帯主テーブルは、「記号番号」、「世帯被保連番」の各フィールドを有している。この世帯主テーブルには、各世帯の世帯主の記号番号と世帯被保連番が入力されることになる。すなわち、図６（ａ）の世帯被保テーブルにおいて、資格区分が「１」となっている人が、図６（ｂ）の世帯主テーブルに纏められている。
【００３０】
図５に戻り、次のステップＳ１４では、データチェック部１４が、世帯被保テーブルの中から未選択の世帯主レコードを１つ選択する。ここで、世帯主レコードとは、図６（ａ）の世帯被保テーブルの「資格区分」の値が「１」になっているレコードを意味する。ここでは、データチェック部１４は、記号番号「０００００００１２１」、世帯被保番号「１」のレコードを選択したものとする。
【００３１】
次いで、ステップＳ１６では、データチェック部１４が、条件テーブル２２（Ｎｏ．３４）のチェック内容の欄に基づいて、世帯被保テーブルの世帯主レコードに対応する世帯主テーブルのレコードが存在するか否かを判断する。この場合、ステップＳ１４で選択した記号番号「０００００００１２１」、世帯被保番号「１」のレコードは、図６（ｂ）の世帯主テーブルに存在しているので、判断は肯定され、ステップＳ２０に移行する。なお、ステップＳ１６の判断が肯定された場合、選択されているレコードは、新システム２００に適合しているレコードであるといえる。
【００３２】
ステップＳ２０に移行すると、データチェック部１４は、全ての世帯被保テーブルのレコードの選択が完了したか否かを判断する。このステップＳ２０の判断が否定された場合には、ステップＳ１４に戻る。そして、ステップＳ１４では、世帯被保テーブルの次の世帯主レコードを選択する。ここでは、データチェック部１４は、記号番号「０００００００１２２」、世帯被保番号「１」のレコードを選択したものとする。次いで、ステップＳ１６では、データチェック部１４が、世帯被保テーブルの世帯主レコードに対応する世帯主テーブルのレコードが存在するか否かを判断するが、ここでの判断は肯定されるので、ステップＳ２０に移行する。そして、ステップＳ２０の判断が否定された場合には、再度ステップＳ１４に戻る。
【００３３】
ステップＳ１４に戻ると、データチェック部１４は、次の世帯主レコード（記号番号「０００００００１２３」、世帯被保番号「１」）を選択する。そして、次のステップＳ１６では、データチェック部１４が、選択した世帯主レコードが世帯主テーブル（図６（ｂ））に存在しているか否かを判断する。ここでは、図６（ｂ）に選択した世帯主レコードが存在していないので、ステップＳ１６の判断は否定され、ステップＳ１８に移行する。この場合、選択されているレコードは、新システム２００に適合していないレコードであるといえる。
【００３４】
ステップＳ１８に移行すると、データチェック部１４は、条件テーブル２２の備考欄に基づいて、Ｎｏ．２７９（資格）のエラーをエラーＤＢ２０に格納する。なお、エラーＤＢ２０は、エラーＮｏ．毎のエラー個数が格納されるデータベースである。その後は、ステップＳ２０に移行する。
【００３５】
上記のように、処理を繰返し、全ての世帯被保テーブルの世帯主レコードの選択が完了した段階で、図５の全処理が終了する。以上のような処理により、条件テーブル２２のＮｏ．３４に関するエラーチェックが完了する。なお、図５の処理でエラーが生じた場合、世帯被保テーブルの世帯主レコードと世帯主テーブルのいずれが正しいかを、現行システム１００のデータ移行プログラム等が自動で判断することは難しい。これは、世帯被保テーブルや世帯主テーブルのデータは、住民（不特定多数の人）の申請に基づいて登録するデータであるため、いずれのデータが正しいかは、当事者である住民に確認をとらなければ分からないからである。
【００３６】
＜年税額チェック＞
次に、年税額チェックについて説明する。年税額チェックでは、データチェック部１４は、図８のフローチャートに沿った処理を実行する。この図８の処理の前提として、データチェック部１４は、年税額チェックを行う前に、条件テーブル２２のうちの１つの条件（図７のＮｏ．５２）を読み込んだものとする。このＮｏ．５２の条件は、前述したＮｏ．３４の条件と同様、現行システム１００と新システム２００との機能差に起因する条件である。
【００３７】
データチェック部１４は、図８のステップＳ３０において、図７の条件テーブル２２（Ｎｏ．５２）のチェック項目及びチェック内容の欄に基づいて、賦課ファイル（再計算）の読み込みを行う。ここで、賦課ファイル（再計算）は、データ移行プログラムが生成したチェック用データ１０６のうちの１つであり、データ移行される国民健康保険の資格情報や税の情報を基に、新たに賦課計算を行った結果を格納するファイルである。より具体的には、賦課ファイル（再計算）は、図９（ａ）に示すような「課税年度」、「課税識別番号」、「納税義務者連番」、「基礎納税額」の各フィールドを有している。「課税年度」のフィールドには、実際に課税された年度が入力され、「課税識別番号」のフィールドには、課税の種別を示す課税識別番号が入力される。また、「納税義務者連番」のフィールドには、納税義務者に振られた通し番号が入力され、「基礎納税額」のフィールドには、データ移行プログラムによる再計算後の基礎納税額が入力される。
【００３８】
図８に戻り、次のステップＳ３２では、データチェック部１４が、図７の条件テーブル２２（Ｎｏ．５２）のチェック項目及びチェック内容の欄に基づいて、期別賦課ファイル（現行）の読み込みを行う。ここで、期別賦課ファイル（現行）は、データ移行プログラムが生成したチェック用データ１０６のうちの１つであり、現行システム１００が元々保持していた賦課計算結果を格納するファイルである。この期別賦課ファイル（現行）は、図９（ｂ）に示すように、賦課ファイル（再計算）と同様、「課税年度」、「課税識別番号」、「納税義務者連番」、「基礎納税額」の各フィールドを有している。
【００３９】
次いで、ステップＳ３４では、データチェック部１４が、賦課ファイル（再計算）の未選択のレコードを１つ選択する。
【００４０】
次いで、ステップＳ３６では、データチェック部１４が、条件テーブル２２（Ｎｏ．５２の上段）に基づいて、選択したレコードに対応する期別賦課ファイル（現行）のレコードが存在するか否かを判断する。ここでの判断が否定された場合、すなわち、選択されているレコードが新システム２００に適合しないレコードである場合には、ステップＳ３８において、データチェック部１４は、条件テーブル２２の備考欄に基づいて、Ｎｏ．１０６（賦課）のエラーをエラーＤＢ２０に格納する（該当エラーＮｏ．のエラー個数がカウントアップされる）。その後は、ステップＳ４４に移行する。
【００４１】
一方、ステップＳ３６の判断が肯定された場合には、ステップＳ４０において、データチェック部１４が、条件テーブル２２（Ｎｏ．５２の下段）に基づいて、選択した賦課ファイル（再計算）のレコードと期別賦課ファイル（現行）の基礎納付額が同額であるか否かを判断する。ここでの判断が否定された場合、すなわち、選択されているレコードが新システム２００に適合しない場合、ステップＳ４２に移行し、データチェック部１４は、条件テーブル２２の備考欄に基づいて、Ｎｏ．１１２（賦課）のエラーをエラーＤＢ２０に格納する（該当エラーＮｏ．のエラー個数がカウントアップされる）。その後は、ステップＳ４４に移行する。一方、ステップＳ４０の判断が肯定された場合には、ステップＳ４２を経ずにステップＳ４４に移行する。
【００４２】
そして、ステップＳ４４では、データチェック部１４が、全てのレコードの選択が完了したか否かを判断する。ここでの判断が否定された場合には、ステップＳ３４に戻り、ステップＳ３４以降の処理を実行する。一方、ステップＳ４４の判断が肯定された場合には、図８の全処理を終了する。以上のような処理により、条件テーブル２２のＮｏ．５２に関するエラーチェックが完了する。なお、図８の処理でエラーが生じた場合、賦課ファイル（再計算）と期別賦課ファイル（現行）のいずれが正しいかを、現行システム１００のデータ移行プログラム等が自動で判断することは難しい。これは、賦課ファイル（再計算）と期別賦課ファイル（現行）は、住民（不特定多数の人）が申請したデータから派生した情報を含んでいるため、いずれのデータが正しいかは、当事者である住民に確認をとらなければ分からない場合が多いからである。
【００４３】
なお、本実施形態のチェックツール端末１０では、上述したテーブル間整合性チェックや年税額チェックのような多種多様なデータチェックが多数実行される。すなわち、条件テーブル２２には、多種多様な条件が定義されている。例えば、データチェック部１４が条件テーブル２２から読み込んだ条件が不正日チェックであった場合には、現行システム１００のデータベース１０２に格納されている全ての日付データと、年月日のパターンを格納するカレンダテーブル（データチェック部１４が保持している）とを比較する。そして、データチェック部１４は、日付データと同一の日付がカレンダテーブルに存在していない場合に、エラーと判定する。
【００４４】
また、例えば、データチェック部１４が条件テーブル２２から読み込んだ条件が範囲チェック（図４（ａ）参照）であった場合には、ある値が所定の範囲に含まれているか否かをチェックする。ここで、新システム２００において値Ａと値Ｂの差（Ａ−Ｂ）を求める処理があるとする。また、値Ｂは正（＋）の値であるべきであるのに、現行システム１００において負（−）の値に変更されたとする。この場合、負の値Ｂをエラーとしないと、値ＡとＢの差（Ａ−Ｂ）の算出値が誤ってしまう（増大してしまう）。この場合、新システム２００では、算出値の大小からエラーを判断できない（判断が難しい）が、本実施形態では、現行システム１００が管理する値の範囲をチェックすることができるので、上記のような新システム２００における算出値の誤りの発生を抑制することが可能となる。
【００４５】
以上のような多種多様なチェックを行った結果、エラーとなった場合には、エラーの種別ごとに、エラーＤＢ２０に格納される（該当エラーＮｏ．のエラー個数がカウントアップされる）ことになる。
【００４６】
次に、出力部９５から出力されるエラーデータ集計表について説明する。図１０にはエラーデータ集計表（資格）の例が示され、図１１には、エラーデータ集計表（賦課）の例が示されている。これらのエラーデータ集計表には、「Ｎｏ．」「レコード名」、「チェック項目」、「チェック内容」、「エラー内容」、「件数」、「前回件数」、「重大度」の各項目が設けられている。なお、「Ｎｏ．」「レコード名」、「チェック項目」、「チェック内容」、「エラー内容」、「重大度」の各項目には、それぞれの内容が予め入力されているものとする。ここで、「重大度」には、「Ａ：重度」、「Ｂ：軽度」「Ｃ：対処不要」、「Ｄ：確認不要」等が入力される。この重大度Ａ〜Ｄの区分は、順に、自治体の住民本人に対する確認をしなければ修正できないエラー、作業者が確認すれば修正できるエラー、システム上で自動的に修正されるエラー、修正の必要がないエラーなどとすることができる。
【００４７】
出力制御部１６は、全てのエラーチェックが終了した段階等のタイミングで、エラーＤＢ２０を読み込み、エラーＮｏ．ごとのエラー件数を集計する。そして、出力制御部１６は、集計したエラー件数を対応するエラーデータ集計表の「件数」の欄に入力する。なお、「前回件数」の欄には、前回エラーチェックを行ったときの「件数」が入力されることになる。
【００４８】
なお、図１０のエラーデータ集計表（資格）では、重大度が「Ａ：重度」のＮｏ．２７９のエラーは０件（前回件数も０件）であることが分かる。また、図１１のエラーデータ集計表（賦課）では、重大度が「Ａ：重度」のＮｏ．１０６のエラーは８件（前回件数は２０件）であり、重大度が「Ａ：重度」のＮｏ．１１２のエラーは７０件（前回件数は７３件）であることが分かる。本実施形態では、このようなエラーデータ集計表が出力されることにより、作業者は、エラーの修正にどの程度の人員が必要か、どの程度の期間を割けばよいか、新システム２００稼動までにどの程度の工数が必要か、などを推測することができる。なお、重大度が低い（ＣやＤ）エラーについては、現行システム１００内において自動修正するものとする。
【００４９】
以上、詳細に説明したように、本実施形態によると、チェックツール端末１０は、不特定多数の住民から申請されたデータ（例えば世帯のデータ）及び当該申請されたデータに基づいて生成されるデータ（例えば賦課のデータ）の少なくとも一方を含むデータをチェックする装置であり、現行システム１００が有するデータから生成されるチェック用データ１０６を取得する取得部１２と、現行システム１００と、新システム２００との機能差に起因する条件（条件テーブル２２）に基づいて、チェック用データ１０６のエラー（新システム２００に対する適合・不適合）をチェックするデータチェック部１４と、条件の種別（エラーＮｏ．やエラー内容など）と、新システム２００に適合しないチェック用データの数量とを出力部９５を用いて出力する出力制御部１６とを備えている。これにより、本実施形態では、データの修正に必要な人員や期間、新システム２００稼動までの工数などを適切に推測するための情報を出力することができるので、出力結果を確認した作業者は、エラーの修正に必要な人員や期間、新システム２００稼動までの工数などを適切に推測することが可能となる。
【００５０】
また、本実施形態では、エラーデータ集計表に、複数のエラーの件数を一覧で表示することとしているので、エラーの修正に必要な人員や期間を複数のエラーを総合して判断（推測）することが可能である。
【００５１】
また、本実施形態では、エラーデータ集計表に「重大度」の欄を設けているため、作業者は、エラーの重大度を考慮して、エラーの修正に必要な人員や期間を推測することができる。この場合、住民の確認が必要か否かなどを考慮して重大度を設定することで、適切な推測が可能となる。
【００５２】
なお、上記実施形態では、エラーデータ集計表に、エラーの件数を表示する場合について説明したが、これに限られるものではない。エラーの数以外の数量、例えば、エラーの出現頻度（割合）をエラーデータ集計表に表示することとしてもよい。
【００５３】
なお、上記実施形態では、現行システム１００から新システム２００にデータを移行する前に（移行前段階で）、データのチェックを行う場合について説明したが、これに限られるものではない。例えば、データのシステム間移行とは無関係に（システム間移行を前提とせずに）、上記実施形態と同様のデータチェックを行うこととしてもよい。
【００５４】
なお、上記実施形態では、自治体の業務システムにおけるシステム移行時のデータチェックに本明細書記載のデータチェックプログラム、データチェック方法及びデータチェック装置を適用した場合について説明した。しかしながら、これに限られるものではない。例えば、国や企業等において、不特定多数の人から申請されたデータや当該申請されたデータに基づいて生成されるデータを扱うシステムにおけるシステム移行やデータチェックに、本明細書記載のデータチェックプログラム、データチェック方法及びデータチェック装置を適用することとしてもよい。
【００５５】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。
【００５６】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【００５７】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【００５８】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施できる。
【００５９】
なお、以上の説明に関して更に以下の付記を開示する。
（付記１） 不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータに実行させるデータチェックプログラムであって、
第１システムが有する前記管理データから生成されるチェック用データを取得し、
前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定し、
前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する、処理を前記コンピュータに実行させるデータチェックプログラム。
（付記２） 前記判定する処理を前記第１システムから前記第２システムへの管理データ移行の前に行うことを特徴とする付記１に記載のデータチェックプログラム。
（付記３） 前記判定する処理は、前記条件に基づいて、複数のチェック用データ間の整合が取れているか否かを判定することを特徴とする付記１又は２に記載のデータチェックプログラム。
（付記４） 前記判定する処理は、前記条件が複数ある場合に、当該複数の条件それぞれに基づいて判定し、
前記出力する処理では、前記複数の条件の種別と前記第２システムに適合しないチェック用データの数量とを一覧にて出力することを特徴とする付記１〜３のいずれかに記載のデータチェックプログラム。
（付記５） 前記出力する処理では、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する場合に、前記判定に用いた条件の重大度を出力することを特徴とする付記１〜４のいずれかに記載のデータチェックプログラム。
（付記６） 不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータが実行するデータチェック方法であって、
第１システムが有する前記管理データから生成されるチェック用データを取得する取得工程と、
前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定する判定工程と、
前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する出力工程と、を前記コンピュータが実行することを特徴とするデータチェック方法。
（付記７） 前記判定工程を前記第１システムから前記第２システムへの管理データ移行の前に行うことを特徴とする付記６に記載のデータチェック方法。
（付記８） 前記判定工程では、前記条件に基づいて、複数のチェック用データ間の整合が取れているか否かを判定することを特徴とする付記６又は７に記載のデータチェック方法。
（付記９） 前記判定工程では、前記条件が複数ある場合に、当該複数の条件それぞれに基づいて、前記判定を行い、
前記出力工程では、前記複数の条件の種別と前記第２システムに適合しないチェック用データの数量とを一覧にて出力することを特徴とする付記６〜８のいずれかに記載のデータチェック方法。
（付記１０） 前記出力工程では、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する場合に、判定に用いた条件の重大度を出力することを特徴とする付記６〜９のいずれかに記載のデータチェック方法。
（付記１１） 不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックするデータチェック装置であって、
第１システムが有する前記管理データから生成されるチェック用データを取得する取得部と、
前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定する判定部と、
前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する出力部と、を備えるデータチェック装置。
（付記１２） 前記判定部は、前記判定を前記第１システムから前記第２システムへの管理データ移行の前に行うことを特徴とする付記１１に記載のデータチェック装置。
（付記１３） 前記判定部は、前記条件に基づいて、複数のチェック用データ間の整合が取れているか否かを判定することを特徴とする付記１１又は１２に記載のデータチェック装置。
（付記１４） 前記判定部は、前記条件が複数ある場合には、複数の条件それぞれに基づいて、前記判定を行い、
前記出力部は、前記複数の条件の種別と前記第２システムに適合しないチェック用データの数量とを一覧にて出力することを特徴とする付記１１〜１３のいずれかに記載のデータチェック装置。
（付記１５） 前記出力部は、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する場合に、前記判定に用いた条件の重大度を出力することを特徴とする付記１１〜１４のいずれかに記載のデータチェック装置。
【符号の説明】
【００６０】
１０ チェックツール端末（データチェック装置）
１２ 取得部
１４ データチェック部（判定部）
１６ 出力制御部（出力部の一部）
２２ 条件テーブル（条件）
９５ 出力部（出力部の一部）
１００ 現行システム（第１システム）
２００ 新システム（第２システム）
【特許請求の範囲】
【請求項１】
不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータに実行させるデータチェックプログラムであって、
第１システムが有する前記管理データから生成されるチェック用データを取得し、
前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定し、
前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する、処理を前記コンピュータに実行させるデータチェックプログラム。
【請求項２】
前記判定する処理を前記第１システムから前記第２システムへの管理データ移行の前に行うことを特徴とする請求項１に記載のデータチェックプログラム。
【請求項３】
前記判定する処理は、前記条件に基づいて、複数のチェック用データ間の整合が取れているか否かを判定することを特徴とする請求項１又は２に記載のデータチェックプログラム。
【請求項４】
前記判定する処理は、前記条件が複数ある場合に、当該複数の条件それぞれに基づいて判定し、
前記出力する処理では、前記複数の条件の種別と前記第２システムに適合しないチェック用データの数量とを一覧にて出力することを特徴とする請求項１〜３のいずれか一項に記載のデータチェックプログラム。
【請求項５】
前記出力する処理では、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する場合に、判定に用いた条件の重大度を出力することを特徴とする請求項１〜４のいずれか一項に記載のデータチェックプログラム。
【請求項６】
不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータが実行するデータチェック方法であって、
第１システムが有する前記管理データから生成されるチェック用データを取得する取得工程と、
前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定する判定工程と、
前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する出力工程と、を前記コンピュータが実行することを特徴とするデータチェック方法。
【請求項７】
不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックするデータチェック装置であって、
第１システムが有する前記管理データから生成されるチェック用データを取得する取得部と、
前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定する判定部と、
前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する出力部と、を備えるデータチェック装置。
【請求項１】
不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータに実行させるデータチェックプログラムであって、
第１システムが有する前記管理データから生成されるチェック用データを取得し、
前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定し、
前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する、処理を前記コンピュータに実行させるデータチェックプログラム。
【請求項２】
前記判定する処理を前記第１システムから前記第２システムへの管理データ移行の前に行うことを特徴とする請求項１に記載のデータチェックプログラム。
【請求項３】
前記判定する処理は、前記条件に基づいて、複数のチェック用データ間の整合が取れているか否かを判定することを特徴とする請求項１又は２に記載のデータチェックプログラム。
【請求項４】
前記判定する処理は、前記条件が複数ある場合に、当該複数の条件それぞれに基づいて判定し、
前記出力する処理では、前記複数の条件の種別と前記第２システムに適合しないチェック用データの数量とを一覧にて出力することを特徴とする請求項１〜３のいずれか一項に記載のデータチェックプログラム。
【請求項５】
前記出力する処理では、前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する場合に、判定に用いた条件の重大度を出力することを特徴とする請求項１〜４のいずれか一項に記載のデータチェックプログラム。
【請求項６】
不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックする処理をコンピュータが実行するデータチェック方法であって、
第１システムが有する前記管理データから生成されるチェック用データを取得する取得工程と、
前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定する判定工程と、
前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する出力工程と、を前記コンピュータが実行することを特徴とするデータチェック方法。
【請求項７】
不特定多数の人から申請されたデータ及び当該申請されたデータに基づいて生成されるデータの少なくとも一方を含む管理データをチェックするデータチェック装置であって、
第１システムが有する前記管理データから生成されるチェック用データを取得する取得部と、
前記第１システムと、当該第１システムとは異なる第２システムとの機能差に起因する条件に基づいて、前記チェック用データが前記第２システムに適合するか否かを判定する判定部と、
前記条件の種別と当該条件に基づく判定の結果得られた前記第２システムに適合しないチェック用データの数量とを出力する出力部と、を備えるデータチェック装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１３−９３０００（Ｐ２０１３−９３０００Ａ）
【公開日】平成２５年５月１６日（２０１３．５．１６）
【国際特許分類】
【出願番号】特願２０１１−２３６３１８（Ｐ２０１１−２３６３１８）
【出願日】平成２３年１０月２７日（２０１１．１０．２７）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【公開日】平成２５年５月１６日（２０１３．５．１６）
【国際特許分類】
【出願日】平成２３年１０月２７日（２０１１．１０．２７）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
[ Back to top ]