座標参照系の違いで主題図と背景地図の重ね合わせ位置がずれる
原課ごとに管理してきたデータと共用空間データで座標参照系が異なると、主題図と背景地図の位置が一致せず、窓口で示す区域の根拠が成り立ちません。
GENZ, Inc.
第三者検証サービス
統合型GISの
第三者検証サービス
統合型GISの主題図と公開画面を第三者視点で検証
共用空間データ、原課の主題図、公開画面、台帳連携の境界。検収日が近づくなかで、どこまでを検証範囲とするかをGENZが文書で示します。
支援事例
支援実績5,000件以上
統合型GISでよくある不具合
統合型GISの不具合は、共用空間データと原課の主題図の重ね合わせ、台帳システムとの連携、法規制レイヤの更新、公開範囲の設定という部署をまたぐ境界で表面化します。更改時に検証すべき代表的な不具合を挙げます。
座標参照系の
結合キーが一致せず、固定資産の主題図に対象外の区画の属性が表示される
固定資産台帳との結合キーが一致しないと、対象外の区画の属性が主題図へ表示され、窓口での照会回答を誤ります。
法規制レイヤの更新が反映されず旧版の区域が表示される
都市計画や法規制の改定データがレイヤへ反映されないと、旧版の区域のまま表示され、改定後の区域を前提にした窓口回答ができません。
大容量のポリゴンを含む範囲で描画が完了せず、タイムアウトが発生する
広域のポリゴンを含む範囲では描画に時間がかかりタイムアウトが発生し、庁内閲覧と住民向け公開画面で地図自体が表示できません。
非公開属性が住民向け画面に表示される
権限と公開範囲の設定が切り分けられていないと、庁内向けの属性が住民向け画面に表示され、公開の設定根拠を説明できません。
残存した不具合により生じる問題
更改時の検証で見落とされた不具合は、リリース後に原課の業務と住民対応へ表面化します。残存した不具合が引き起こす代表的な問題を挙げます。
静的テスト（レビュー）でおさえるべき観点
統合型GISの検証では、実施前に仕様書どうしを突き合わせる静的テストが欠かせません。共用空間データと主題図の定義の不整合は、設計書の段階で検出するほど手戻りを抑えられます。レビューの観点を挙げます。
属性項目の欠落に気づかないまま受け入れへ進むと、主題図の表示不整合がリリース直後の窓口照会で表面化します。設計書との照合なしには切り分けが進まず、暫定対応と不具合票の往復で安定化が遅れます。
共用空間データ仕様と主題図要件の整合を確認する
統合型GISでは、共用空間データに加え、都市計画や法規制の図面と属性情報を管理します。共用空間データ仕様書と主題図の要件を突き合わせ、表示や検索に必要な属性項目の欠落がないかを確認します。
確認する資料
- データ仕様書
- 主題図要件書
- 属性項目一覧
結合キーの不整合が残ると、台帳と地図を突合する業務で誤った属性が表示されるおそれがあります。固定資産など窓口回答に直結する画面では、回答のやり直しという対外的な業務増につながります。
設計書と台帳の項目定義を照合し結合キーの一意性を確認する
台帳システムとの連携では、結合キーが一意に定まることが前提です。設計書の項目定義と固定資産・道路台帳など各台帳の項目定義を照合し、キーの重複や欠落、型の不一致がないかを確認します。
確認する資料
- DB設計書
- 項目定義書
- 結合キー一覧
API定義と表示仕様の不整合を見逃すと、住民向け公開画面に旧版の区域が表示される事象につながります。原課の更新手順とベンダーの配信処理の双方にまたがり、原因の切り分けが属人的になります。
API定義と地図表示仕様の照合点を確認する
地図配信基盤のAPI定義と表示仕様書を照合し、レイヤの名称・更新単位・配信形式が一致しているかを確認します。定義の更新漏れがあると、庁内閲覧と住民向け公開画面で表示内容が異なります。
確認する資料
- API定義書
- 表示仕様書
- 配信手順書
除外条件の漏れは、非公開情報が公開画面へ表示される重大事象になり得ます。システム監査で公開範囲の設定根拠を示せず、是正対応の工数が次年度の計画へ食い込みます。
権限設計と公開区分の運用を照合し除外条件を確認
庁内閲覧と住民向け公開の権限区分を、権限設計書と公開区分表で照合します。非公開とする主題図や属性が公開画面へ出ない除外条件が、部署単位・役職単位のどの運用でも成立するかを確認します。
確認する資料
- 権限設計書
- 公開区分表
- 運用管理要領
判別基準が曖昧なままでは移行対象の確認が検証範囲から抜け落ち、原課が個別GISの継続利用へ戻ります。基盤の整備費と個別GISの運用費が同時に発生し、重複投資の防止という導入目的が成立しなくなります。
移行対象と対象外の判別基準を確認する
既存の個別GISをすべて廃止する必要はありません。移行計画書と調達仕様書を照合し、移行対象と継続利用を分ける判別基準が業務単位で明確かを確認します。基準が曖昧では確認項目を定義できません。
確認する資料
- 移行計画書
- 調達仕様書
- 業務棚卸表
- 判別基準表
動的テストの設計・実行のポイント
統合型GISの検証はリリース判断の前に集中します。工程ごとに確認対象と成果物を分け、受け入れでの確認漏れを防ぎます。
STEP 01
ユニットテストの設計と実行境界値の特定には設計書との照合が前提となります
どう確かめるか
ユニットテストで座標変換と面積・距離の計算順序を境界値分析により検証する
座標参照系の変換と面積・距離の計算順序を、境界値分析で異常な入力を与えて検証します。共用空間データの端点や区域の境界値で計算結果が変わる箇所を特定し、設計書との照合根拠を記録します。
- 01座標変換の入力条件と境界値を洗い出してテスト項目へ落とします
- 02面積・距離の計算順序を設計書と照合し期待結果を確定します
- 03境界値の入力で計算結果を検証し差異を不具合票へ記録します
OUTPUT計算結果の検証記録
STEP 02
統合テストの設計と実行結合キーの対応表が最新でないと切り分けが止まります
どう確かめるか
統合テストで共用空間データの取り込みと主題図表示のモジュール間の連携を検証する
更新された共用空間データの取り込みから主題図への反映まで、モジュール間の連携を検証します。台帳システムとの結合キーの整合も対象に含め、原課と基盤側の不整合をリリース前に検知します。
- 01共用空間データの取り込み手順と反映先の主題図を一覧化します
- 02台帳システムとの結合キーの整合を連携単位で検証します
- 03主題図の表示結果を原課の定義と突合して不整合を切り分けます
OUTPUT連携確認の実施記録
STEP 03
システムテストの設計と実行性能の目標値は非機能要件にもとづき事前に確定します
どう確かめるか
システムテストで業務シナリオと応答性能を検証する
窓口照会や年次更新の反映確認といった業務シナリオを実行し、画面表示と応答時間を検証します。住民向け公開画面を含め、想定する利用状況で性能の目標値を満たすかを測定して記録します。
- 01窓口照会と年次更新の業務シナリオを手順化して実行環境へ展開します
- 02想定利用状況の負荷で公開画面の応答時間を測定します
- 03測定結果を目標値と比較し未達の箇所は原因別に整理します
OUTPUT性能測定の結果報告書
STEP 04
受け入れテストと回帰テスト確認の深さが部署で異なるため項目書で基準を揃えます
どう確かめるか
受け入れテストで原課ごとのテスト項目書にもとづく確認と回帰テストを実施する
原課ごとのテスト項目書にもとづき、主題図の表示と権限・公開範囲を確認します。不具合修正後は回帰テストで再検証し、リリース判断の材料となる実施記録と残存リスクの一覧を提出します。
- 01原課ごとの確認項目をテスト項目書として配布し回収期限を定めます
- 02権限と公開範囲の設定が設計どおりかを部署単位で確認します
- 03不具合修正後に回帰テストを実施し残存リスクを一覧化します
OUTPUTテスト項目書と不具合票
GENZ が代行する統合型GISのテスト
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 検証範囲の線引きを文書で定義してお渡しします
- 原課へ配れる統一の確認項目を用意します
- 残存リスクを一覧化しリリース判断の材料にします
- 第三者の視点で設計書と実装を照合します
共用空間データから起こす第三者検証
統合型GISの検証は、共用空間データ・主題図・住民向け公開画面・台帳連携のどこまでを対象とするかで工数が変わります。GENZは発注側にも受託側にも属さない第三者の視点で、設計書と実装の照合を担います。
共用空間データの構成からテスト設計を組む
共用空間データの座標参照系・レイヤ構成・更新周期を仕様書から読み解き、データの取り込みと突合を軸にテスト設計を組みます。
主題図から住民公開画面まで検証する
都市計画や道路など原課ごとの主題図の表示・結合キーの整合から、住民向け公開画面の権限と公開範囲まで、一貫した深さで検証します。
既存の体制に合わせて範囲を分担する
品質保証が受託側にある体制でも、発注側の受け入れテストだけを切り出す形でも、開発工程と並行して検証範囲を分担して受け持ちます。
報告書と不具合票で共有する
テスト項目書・実施記録・不具合票・報告書を提供し、残存リスクを言語化した報告で、部門の承認手続きと監査対応に使える状態にします。
ご相談から納品までの流れ
ご相談から報告書の納品まで、第三者検証の進め方と各工程の成果物をご説明します。
ご相談・ヒアリング
更改工程や移行対象の現状を伺い、検証が必要な範囲をともに洗い出します。
テスト設計と見積もり
洗い出した範囲からテスト観点を整理し、対象と工数を見積もりでご提示します。
テストの実施と進捗の共有
設計したテストを実行し、検出した不具合を不具合票として随時共有します。
報告書の納品と再確認
テスト項目書・実施記録・報告書を納品し、残存リスクの扱いを再確認します。
統合型GISの検証範囲からご相談いただけます
統合型GISの検証範囲と優先順位を GENZ にご相談ください
ご相談いただいた段階で、対象システムの検証範囲の切り分け、優先順位の考え方、必要工数の見立て、関連テストの要否まで、リリース判断の材料として使える形で整理してお返しします。