空間データの品質

第9回 空間データの品質と環境

地理情報の様々な標準規格や仕様に際して守るべきルーを決めたJPGISが定められています。それに合わせて、平成17年に地図情報レベル2500データ作成製品仕様書(案)が、平成20年に作業規程の準則が告示されています。これらの規程及び仕様書には、品質規定が明記されています。しかし、計画機関の製品仕様書や品質評価手順書の整備があまり進んでいないようです。そこで、今回は空間データの品質の最終回として品質を取巻く環境について考えたいと思います。


ほとんど市町村で製品仕様書が作成されていない

筆者の調査でも、第三者機関への聞き取り調査でも、市町村が作成する地形図(DM)は、ほとんど製品仕様書を作成しておりません。従来のプロセス管理の手法で作成しています。
国土地理院の方々もずいぶん苦労されて、製品仕様書の講習会を開催しています。しかし、市町村の出席率は極端に悪いようです。その原因は、市町村の担当は業務上で地図を利用することに対して精通していますが、地図を作る技術について手が回っていません。なぜ手が回らないかというと、3年から4年で担当が変わりますから、業務を精通することが最優先で空間データを作成するための測量のことを勉強することは二の次の状態にあります。
従って、市町村が製品仕様書を自ら作成することはほとんど不可能の状態にあると言っても良いでしょう。
実は、市町村でも、発注物件の納品物に製品仕様書の作成を記述している場合があり、すでに製品仕様書が用意されている場合があります。しかし、次の発注にその製品仕様書が使われていないケースがあります。それは次の理由によると考えられます。

(1) 製品仕様書の内容が理解できない。
(2) 理解できたとしても、その製品仕様書が今回の案件に適合しているかわからない。
(3) 庁内決済を得るために、製品仕様書の内容を説明できない。質問に答えられない。


なんといっても、製品仕様書に記述されているXMLは、地方公務員にとってハードルの高いものがあります。地方公務員の技術系職員が、測量やXMLをマスターし、待遇面で優遇されたとしてもマスターすべき最優先課題は、業務に精通するにあります。このようなことから、地方公務員の技術職がXMLの技術をマスターすることに悲観的にならざるを得ません。
一方、空間データを作業機関の生産設備は、XMLで記述した生産システムで生産しているわけではありません。XMLは文書やデータの意味や構造を記述するためのマークアップ言語の一つです。従って、生産システムがXMLで動いているわけではなく、生産した空間データから空間データやメタデータをXMLフォーマット変換に変換しています。同様にGISもXMLフォーマットを読み込めるようにしているにしているにすぎません。
このように考えると、製品仕様書の実施率を上げるためには、次の選択を行う必要があるのではないかと考えています。

(1) XMLを理解した人材がいる部門に空間データ整備の所管を移し、そこで集中的にかつ恒久的に人材を確保する。
(2) 発想を変えて、製品仕様書の形式をXML形式ではなく、自治体の担当者がわかるような書式で行う。


前者は、空間データを整備・更新している部門が複数の部門に渡ります。そして、自治体はXML方式の製品仕様書をそれぞれの担当部門が理解し運用することが困難と考えます。そこで、空間データを整備・更新する部門を統合して、その部門がリテラシーを向上させることによって運用するという考え方です。この方法は、空間データの整備・更新のことだけを解決するには、良い解決策の一つであることは間違いありません。しかし、実現性となると、かなり難しく、庁内の意見の一致をみるまでに、かなりの時間とエネルギーが必要となります。
一方、後者は、自治体の空間データ整備・更新部門がXMLの理解すること自体が困難であると考え、自分たち自身の身の丈に合った製品仕様書で運用しようとする考え方です。
この方法は、前者と比較して容易に自治体の担当者が理解できる仕様書を作ることができます。筆者も幾つかの自治体に対して基本仕様書という形で作成して、利用いただいております。従って、自治体の皆さんが理解でき、作業機関へのポイントをきちっと抑えた情報を記載した方法としてこの形式をお薦めます。


作業機関は品質を軽視していないか

筆者の経験と、第三者機関への調査結果でも、品質検査及び品質検定を一回で合格することがまれです。
石油ストーブ、自動車等に見られるように一般産業界の企業において、品質管理はもし事故を起こしたら企業の存続に影響を与えかねないだけに、大変重視しております。また、自治体が発注する土木や建築案件が、検査に不合格になった場合には、次年度の入札に参加することができなくなる場合があります。しかし、空間データは間違っていても、人が死なないためか、このような不合格、又は納品後に欠陥が見つかった場合でも、入札参加資格を停止するという措置を行った例を見たことがありません。このように品質の良否が企業経営に影響を与えていないことが、1回で合格していないことに影響しているのでしょうか。
入札参加資格の停止はともかく、作業機関が社内検査で合格としたものが、第三者機関で不合格とされている現状は、正常な状態ではありません。作業機関の中には、第三者機関の判定に、不満をもつ方もおいでになりますし、同様に、第三者機関の方にも、どうして1回で合格するデータを提出しないのか不満を持つ方もいらっしゃいます。
筆者は、ヒヤリングをした第三者機関の方々に、温情で合格するまでの複数回の検査費用を無償にしているようですが、そのことが作業機関の品質向上を遅らせていると申し上げました。例えば、作業機関が検定を合格するのに3回要したとすれば、その費用はばかにならず、経営者は、必ず1回で検定を合格するように社内の調査と対策を立てざるを得ないでしょう。一体、作業機関の経営者の方で、自社の空間データの品質検定の結果が何回で合格しているかをご存じの方は何人居られるでしょうか。
品質検定を1回で合格しないことは、業界全体と第三者機関を交えて原因の調査と対策に取り組む問題ではないでしょうか。業界の努力に期待したいものです。


1つの空間データを異なる検査プログラムで処理した結果は同じ結果になるのか

筆者がGISのコンサルタントをしていると、作業機関から “品質検査のプログラムはどのプログラムを使っていますか”という言葉を聞きます。また、“そのプログラムで検査しますから、それをください”とおっしゃいます。
また、第三者機関への調査では、第三者機関が同じ空間データをそれぞれが検査を行って、その結果が全ての第三者機関で同じ結果となるかを調査したことはないと言っています。
このことは、何を意味するかといいますと、作業機関は、自身が持っている検査プログラムの仕様と、計画機関あるいは第三者機関が持っている検査プログラムの仕様が異なっているということを、経験的に知っているのではないかと推測しています。なぜなら、完全性の検査、論理一貫性の位相検査で指摘したように、エラーの定義が統一あるいは規格化されていないことにあります。従って、現状では、同じ空間データを異なる機関が検査した場合に、異なる結果が出ることが当然の結果であると考えています。

このような現状を考えると、早急に次の作業を行う必要性があると考えています。
(1) エラー定義を統一あるいは規格化する。
(2) 同じ空間データ(標準検査用空間データ)で第三者機関、作業機関、計画機関の所有しているプログラムで処理して、それぞれの結果がどのように異なるかを分析し、問題を抽出する。
(3) 検査プログラムのガイドラインを作成する。
(4) 検査プログラム開発者は、このガイドラインを満たしていることを明示する。
(5) 社内検査には必ず検査プログラムの名称とガイドラインの内容を明示する。


エラーの定義は、一度で終わるものでなく、仕様の変更や、今まで見過ごされていたものが発見されることが予想されます。そこで、エラー定義を管理運営する機関を設ける必要があります。この機関を仮にA機関とします。計画機関、及び第三者機関が新たなるエラーが発見された場合には、A機関に報告するものとします。A機関は報告を受けて、ニュースレターを発表することとします。品質検査プログラム開発者は、この情報によりプログラムの対応と処置を行い、その改良したプログラムの検定をA機関に持ち込みます。A機関は、テストデータで試験を行い、ニュースレターの内容が処理されているかを判定して、承認を行います。
従って、国土地理院、第三者機関、計画機関は、検査した検査プログラムのリリースバージョン又は承認番号によって成果物の信頼性を知ることができます。
このようなシステムを作り上げることによって、品質結果の水準を一定に保つことができると考えています。


おわりに

品質は空間データの要です。そのためには、計画機関である自治体が理解できる製品仕様書でなければなりません。また、関係者が一致して共通のエラーの定義を明確にして、その定義を厳格に運用した検査ソフトによって品質検査を行ってこそ品質が保たれるものと考えています。そのようにすることによって、初めて公正なる品質が維持できるとものと信じています。


9回に渡り『空間データ品質』についてお付き合いいただきまして、ありがとうございました。今回で『空間データ品質』を終了させていただきます。

Share on FacebookTweet about this on TwitterShare on LinkedInEmail this to someonePrint this page

目次へ戻る