自治体向け試験計画書の書き方・作り方

行政AIヤマトにおいては「DX・情報」の「自治体システム書類作成」のボタンで、この仕様の通り、AI出力できます。

はじめに――試験計画書の結論

自治体向け試験計画書は、「予定した試験を行う」ためだけの文書ではありません。住民サービス、行政事務、個人情報、法令遵守、災害対応を含め、システムが本番利用に耐えることを誰がどの証拠で判定するかを定める品質保証の基準です。よい試験計画書は、要件との追跡可能性、環境とデータ、役割、合否基準、欠陥管理、停止・再開基準、承認、証跡を明確にします。

自治体システムでは、機能が動くだけでは合格になりません。権限のない職員や他自治体のデータが見えないこと、個人情報がログへ不要に出ないこと、窓口繁忙時の性能、障害・災害時の継続、帳票・外字・和暦、国や都道府県との連携、アクセシビリティも確認します。自治体向け試験計画書の書き方では、正常系・異常系・境界値・運用系をバランスよく設計します。

要点：試験の目的は欠陥ゼロを宣言することではなく、残存リスクを可視化し、自治体が本番移行の可否を説明可能な証跡で判断できるようにすることです。

想定読者

• 自治体の情報政策部門、業務原課、受入試験担当
• 情報セキュリティ責任者、個人情報保護担当、監査担当
• 受託事業者のPM、品質管理、試験管理、開発・基盤担当
• データ移行、ネットワーク、クラウド、運用、ヘルプデスク担当
• 外部接続先、共同利用団体、再委託先、検収責任者

原課には業務シナリオと期待結果、技術者には環境・データ・ログ、管理者には進捗・品質指標と判定基準が必要です。本文、試験一覧、詳細手順、要件トレーサビリティ、欠陥票を分離し、一つの文書へ過剰に詰め込まないようにします。

標準的な章立て

1. 目的、背景、適用範囲、関連文書
2. 品質目標、対象・対象外、前提条件
3. 試験レベル、試験種別、試験方針
4. 要件トレーサビリティと網羅性
5. 体制、役割、承認、独立性
6. 環境、構成、ツール、日程
7. 試験データ、個人情報、秘密情報
8. 開始・完了・合否・停止・再開基準
9. 欠陥・課題・変更管理
10. 非機能・セキュリティ・運用試験
11. 証跡、報告、保管、廃棄
12. リスク、ロールバック、承認履歴

1. 目的・範囲・品質目標

目的は「総合試験を実施する」ではなく、「承認済み要件に対する機能・性能・セキュリティ・運用性を検証し、本番移行判定に必要な証拠を提供する」と書きます。対象機能、環境、バージョン、連携先、自治体、データ範囲を明示し、対象外とその理由も記載します。

品質目標は測定可能にします。必須要件の試験実施率100%、重大欠陥0件、ピーク時95パーセンタイル応答2秒以内、権限逸脱0件、バックアップ復元成功、RTO・RPO達成などです。数値は契約・要件・リスクに基づき、後から都合よく変更しません。

対象外にした項目は、別試験、事業者保証、運用監視等の代替根拠を示します。「時間がない」は対象外の合理的理由ではありません。法令・標準仕様・製品仕様が変わった場合の再評価条件も記載します。

2. 試験レベルと試験種別

単体試験は個々のモジュールや設定、結合試験は内部・外部インターフェース、総合試験はシステム全体、受入試験は自治体業務と契約要件を確認します。移行試験、運用試験、性能試験、セキュリティ試験、障害試験、バックアップ復元試験、災害復旧試験を必要に応じて計画します。

同じケースの繰返しだけではレベルの違いになりません。下位では技術的な分岐、上位では窓口・電子申請・決裁・帳票・外部連携を通した業務シナリオを確認します。住民、職員、管理者、委託先等のロール別に認証・認可を試験します。

回帰試験は変更影響分析に基づき選びます。共通認証、住所、組織・職員、通知、決済、帳票等の共通部品変更は広範囲へ影響します。自動化する場合、スクリプト自体の版・レビュー・結果保全を管理します。

3. 要件トレーサビリティ

要件ID、設計ID、実装単位、試験ケースID、結果、欠陥IDを結びます。要件ごとに少なくとも一つの試験を持つだけでなく、正常、異常、境界、権限、監査の観点を確認します。試験できない要件は、レビュー、解析、証明書等の代替検証方法を記載します。

トレーサビリティ表の例

要件追加・変更時は試験への影響を自動またはレビューで追跡し、該当ケースを更新します。削除要件のケースを誤実行しないよう版管理します。トレーサビリティは検収と監査における重要な証跡です。

4. 体制と責任

試験管理者、環境管理者、データ管理者、実施者、結果確認者、欠陥判定者、自治体承認者を定義します。開発者の自己試験だけで完結させず、重要機能は独立した確認者を置きます。受入試験は自治体が主体となり、受託者は環境・操作・障害対応を支援します。

個人情報を扱う担当者、アクセス権、作業場所を限定します。再委託先の範囲、監督、ログ、データ返却・消去も明記します。欠陥重要度を巡る意見不一致に備え、最終判断者とエスカレーション経路を決めます。

5. 試験環境

本番同等性を、構成、版、設定、データ量、ネットワーク帯域、セキュリティ制御、外部連携で評価します。完全同一でない場合は差異一覧を作り、結果への影響と本番での追加確認を定めます。共有環境では他チームの変更・負荷を管理します。

環境のベースラインを固定し、試験開始後の変更は申請・承認・記録を行います。ケースごとの初期状態、データリセット、時刻操作、外部サービスのスタブ条件を示します。試験失敗が製品欠陥か環境不備かを区別できる監視とログを準備します。

外部接続試験は相手先の利用時間、データ形式、証明書、障害連絡を合意します。本番接続先へ誤送信しないよう、接続先識別と送信抑止を二者確認します。

6. 試験データと個人情報

原則として、架空・合成・匿名化したデータを使います。年齢、世帯、住所、外字、DV等支援措置、死亡、転出入、課税・非課税など、業務上重要な組合せを網羅しつつ、実在住民を再識別できないようにします。

本番データが必要な場合は、必要性、法的根拠、対象範囲、承認、抽出者、暗号化、授受、保管、アクセス、マスキング、消去期限を定めます。個人番号は特定個人情報として、通常の個人情報より厳格に管理します。試験結果やスクリーンショットにも個人情報を残さないよう設計します。

データの期待値を事前に作り、試験対象システムの出力から期待値を生成しないようにします。件数、金額合計、状態遷移、文字コード、日付境界、うるう年、和暦、タイムゾーン、NULL、ゼロ、最大長を含めます。

7. 開始・完了・合否基準

開始基準には、対象版の固定、環境構築完了、前段試験合格、重大欠陥解消、データ準備、手順承認、アカウント発行、監視・ログ準備を含めます。開始条件未達のまま日程優先で実施すると、結果の信頼性を失います。

ケース合否は期待結果との一致で判定し、部分的成功を勝手に合格にしません。試験レベル完了基準は、必須ケース実施率、合格率、欠陥残数、再試験、証跡、未実施項目のリスク承認で定義します。

条件付き合格は例外として、残存欠陥、回避策、影響、解消期限、所有者、監視方法を自治体が明示承認します。個人情報誤表示、権限逸脱、データ破壊等の重大欠陥を条件付き合格にしないことを原則とします。

8. 停止・再開基準とロールバック

停止基準は、環境不安定、対象版相違、重大欠陥多発、個人情報漏えいのおそれ、データ破壊、外部システム影響、期待値不備、合格率の急低下等です。閾値、判断者、停止範囲を決めます。

停止時は、追加操作を中止し、ログ・画面・時刻・データ状態を保全します。試験環境を初期状態へ戻すロールバック手順を用意し、データ復元後の整合性を確認します。本番相当データを使う場合、漏えい疑いでは自治体の事故対応へ移行します。

再開は、原因、影響範囲、修正、環境再構築、代表ケースの確認、自治体承認を条件とします。原因不明のまま繰返し実行して証跡を上書きしません。日程不足時は範囲を無断削減せず、リスクと代替を報告します。

9. 欠陥管理

欠陥票には、ID、発見日、環境、対象版、手順、期待結果、実結果、再現条件、証跡、重要度、優先度、担当、原因、修正、再試験、横展開を記載します。個人情報をそのまま貼らず、参照権限を制限した証跡へリンクします。

重要度は住民影響、業務停止、データ完全性、機密性、法令、回避策の有無で判定します。修正後は当該ケースだけでなく影響範囲の回帰試験を行います。同根原因の欠陥が他機能にないか横断確認します。

欠陥を仕様扱いに変更する場合、承認済み要件・設計との整合、住民・業務影響、契約を確認し、自治体の明示承認を得ます。件数を減らす目的で分類を変えてはいけません。

10. 自治体特有の試験観点

• 窓口、郵送、オンライン、コンビニ等のチャネル間整合
• 組織改編、人事異動、兼務、代理、年度切替の権限
• 住所・氏名・外字・旧字・通称・長い名称・多言語
• 和暦改元、年度、課税年度、うるう年、日付境界
• DV等支援措置など閲覧制限情報の非表示と監査
• 帳票の様式、印字位置、バーコード、アクセシビリティ
• 国、都道府県、他自治体、金融機関等との連携
• 災害、回線断、停電、クラウド障害時の業務継続
• 大量一斉申請、給付、税繁忙期の性能と待ち行列
• 監査ログ、保存期間、情報公開請求に耐える追跡性

標準準拠、ガバメントクラウド、マイナンバー関連等では、適用される最新の標準仕様、法令、ガイドラインを公式情報で確認します。自治体独自条例・規則、業務手順との差異も原課と確認します。

11. 非機能・セキュリティ・運用試験

性能試験は平均だけでなくパーセンタイル、同時数、データ量、バッチ競合を測ります。可用性試験では冗長化、フェイルオーバー、復帰、データ整合を確認します。バックアップは取得だけでなく復元し、RTO・RPOを実測します。

セキュリティ試験は、認証、認可、セッション、入力検証、暗号化、ログ、脆弱性、設定を対象とします。高負荷・侵入試験を本番へ無断実施せず、範囲・時間・停止基準・連絡を承認します。発見情報は機密として管理します。

運用試験では、監視、アラート、一次対応、エスカレーション、定期処理、証明書更新、アカウント棚卸し、問い合わせ、障害報告を実際の担当者が行います。マニュアルを読むだけでなく、訓練で所要時間と連絡の有効性を確認します。

12. 証跡と報告

ケースID、対象版、実施者、日時、入力、結果、ログ、画面、判定をひも付けます。証跡の命名、保管先、アクセス権、改ざん防止、保存期間、廃棄を定めます。自動試験結果も実行条件とツール版を保存します。

日次・週次報告には、計画対実績、合否、未実施、欠陥推移、停止事象、リスク、意思決定依頼を示します。最終報告は、網羅性、結果、残存欠陥、残存リスク、条件付き事項、推奨判定をまとめ、自治体承認を記録します。

書き方のポイント

1. 要件IDと試験IDを必ず結ぶ。
2. 合否を数値・状態で客観化する。
3. 試験環境と本番の差異を隠さない。
4. 個人情報を使わない設計を優先する。
5. 欠陥重要度を住民・業務影響で評価する。
6. 停止・再開・ロールバックを計画に含める。
7. 自治体原課の受入試験時間を確保する。
8. 法令・標準の最新版確認担当を置く。

重要事項

• 必須要件、個人情報、権限、データ完全性の試験を省略しない。
• 本番同等性と環境差異を明示する。
• 本番データ利用は例外管理し、承認・暗号化・消去を行う。
• 合格基準は試験結果を見る前に承認する。
• 重大欠陥と残存リスクを自治体へ完全に報告する。
• 試験停止基準と再開承認を定義する。
• 法令・標準・製品仕様は試験時点の最新版を確認する。

禁止事項

• 要件との対応がない場当たり的な試験
• 実施していないケースの合格扱い、証跡の捏造・改変
• 本番個人情報の無承認利用、無制限コピー、期限超過保管
• 開発者の自己判定だけによる重大欠陥のクローズ
• 合格率を上げるためのケース削除・重要度変更
• 停止基準到達後の独断継続
• 本番や外部接続先への無承認負荷・侵入試験
• 不具合再現時の個人情報を一般チケットへ貼付
• ロールバック不能なデータ更新を無準備で行うこと
• 古い法令・ガイドラインを最新版確認なしに適用すること

実務チェックリスト

計画作成

• [ ] 目的、対象、対象外、品質目標が明確
• [ ] 要件・設計・試験のトレーサビリティがある
• [ ] 正常・異常・境界・権限・運用を網羅
• [ ] 自治体特有の業務・文字・年度観点を反映
• [ ] 環境差異と外部依存を評価
• [ ] 試験データの個人情報リスクを評価
• [ ] 開始・完了・停止・再開基準を定量化
• [ ] 欠陥重要度、報告、承認経路を定義
• [ ] ロールバックと証跡保管を計画

実施・完了

• [ ] 対象版・環境・データを開始時に確認
• [ ] 実施者、時刻、結果、証跡を記録
• [ ] 想定外時に停止し、証拠を保全
• [ ] 修正後に再試験と回帰試験を実施
• [ ] 個人情報を含むデータ・証跡を適切に管理
• [ ] 未実施・未解決・条件付き事項を明示
• [ ] 暫定権限、データ、環境を復旧・消去
• [ ] 自治体による最終結果承認を取得

テンプレート

# ○○システム試験計画書
文書番号／版／対象リリース／承認
## 1. 目的・範囲・品質目標
## 2. 試験レベル・種別・方針
## 3. 要件トレーサビリティ
## 4. 体制・役割・日程
## 5. 環境・ツール・データ
## 6. 個人情報・セキュリティ
## 7. 開始・完了・合否基準
## 8. 停止・再開・ロールバック
## 9. 欠陥・変更・進捗管理
## 10. 証跡・報告・承認
## 11. リスク・改訂履歴

FAQ――自治体向け試験計画書の作り方

Q1. 試験計画書と試験手順書の違いは何ですか。

試験計画書は範囲、方針、体制、環境、基準、管理方法を定め、試験手順書はケースごとの入力、操作、期待結果を示します。計画が統制、手順が実行を中心にします。

Q2. 全要件に試験ケースが必要ですか。

原則として検証方法が必要です。実行試験が不適切な要件はレビュー、解析、証明等を使い、要件IDから結果へ追跡できるようにします。

Q3. 本番データを使わないと性能を測れない場合は。

統計的特性を再現した合成データを優先します。本番データが不可欠なら、最小化、承認、匿名化、暗号化、アクセス制限、消去を計画し、法令・規程を確認します。

Q4. 条件付き合格は認められますか。

軽微で回避策があり、住民・法令・データへの重大影響がなく、所有者と期限を明示して自治体が承認する場合に限ります。重大欠陥の先送りには使いません。

Q5. 欠陥件数が多いときの停止基準は。

重大度別件数、発生率、修正速度、環境安定性で定めます。重大欠陥1件で即時停止する領域もあります。案件リスクに応じ事前承認します。

Q6. 受入試験は受託者が代行できますか。

準備・操作支援はできますが、業務適合性と受入の最終判断は自治体が行います。責任分界は契約・計画で明確にします。

Q7. セキュリティ試験は本番で行いますか。

原則として管理された環境で行います。本番実施が必要なら、範囲、承認、停止基準、監視、復旧、住民影響を厳格に管理します。

Q8. 自動試験の結果だけで合格にできますか。

対象範囲、スクリプト妥当性、環境、結果をレビューします。アクセシビリティや業務判断など、人の確認が必要な項目を補います。

Q9. 法令改正中の試験はどう計画しますか。

確定要件と未確定要件を分け、複数シナリオ、確認担当、判断期限、再試験条件を置きます。施行日・仕様は公式な最新版を継続確認します。

Q10. AIで試験ケースを作れますか。

観点抽出の補助には使えますが、機密・個人情報を未承認AIへ入力せず、要件との対応と期待値を人が確認します。AI生成だけで網羅性や法令適合を保証できません。

品質判定会議の設計

試験終了時の品質判定会議には、自治体の原課、情報政策、セキュリティ、個人情報保護、受託者の品質責任者が参加します。資料は合格率だけでなく、要件網羅率、重要度別欠陥、再発・再オープン、未実施、環境差異、残存リスク、運用回避策を示します。数値の分母を変えてよく見せないよう、集計ルールを計画段階で固定します。

判定は「合格」「条件付き合格」「不合格」「判定延期」から選び、理由と承認者を記録します。条件付き合格の場合は、対象欠陥、住民・業務影響、回避策、監視、所有者、期限、未解消時の行動を定めます。重要な権限逸脱、個人情報誤表示、データ欠損、法令違反のおそれは、原則として本番移行前に解消します。

品質サマリー例

必須要件：240件中240件に検証結果あり
試験：1,286件中1,286件実施、合格1,280、不合格6
重大度A：0件、B：0件、C：6件（回避策あり、2週間以内改修）
性能：ピーク想定120%で95%応答1.8秒、基準2.0秒以内
セキュリティ：権限逸脱0件、脆弱性高・重大0件
復旧：実測2時間18分、RTO 4時間以内
未解決リスク：帳票余白の軽微差異。窓口業務への影響なし
推奨判定：条件付き合格。C欠陥の期限管理を条件とする

実務的なカバレッジ補完

ケース数だけでは網羅性を判断できません。要件、画面、API、ロール、業務状態、外部連携、ブラウザ・端末の軸でカバレッジ表を作ります。特に「閲覧はできないがCSVから見える」「画面ではマスキングされるが通知に出る」といった経路差を確認します。

自治体内の組織改編や人事異動を想定し、権限付与、変更、失効のライフサイクルを試験します。大規模災害時の一斉アクセスや、給付開始日の急増は、通常平均ではなく想定ピークと余裕率で性能を評価します。試験で再現できない極端な災害は、机上訓練や設計レビューで代替し、その限界を残存リスクとして明記します。

受入試験シナリオの選定

受入試験は機能一覧の上から操作するだけでなく、実際の一日・一年度の業務を基に選びます。窓口受付、オンライン申請、審査、決裁、通知、収納、集計、外部報告までを通し、途中の差戻し、取消、職員交代も含めます。原課は頻度の高い業務だけでなく、頻度は低くても住民影響が大きいケースを選びます。

シナリオごとに業務責任者を定め、期待する帳票、会計・統計上の結果、翌日バッチへの引継ぎを確認します。複数課をまたぐ場合、前課で合格したデータが後課で正しく見えるか、責任の受渡し点を試験します。受託者が操作を代行する場合でも、自治体担当者自身が結果を理解し、受入可否を判断した証跡を残します。

計画変更の扱い

試験中にケース追加、環境変更、対象版更新が起きた場合は、変更理由、影響範囲、再試験、日程、承認を記録します。欠陥修正を含む新ビルドは、変更箇所だけでなく共通部品への影響を評価します。基準を緩めて日程に合わせる変更は行わず、納期・範囲の調整が必要なら契約・変更管理の手続へつなぎます。

まとめ

自治体向け試験計画書の書き方では、要件から証跡までを切れ目なく追跡し、住民・業務・個人情報へのリスクを合否判断へ反映します。客観的な開始・完了・停止基準、欠陥管理、承認、ロールバックを事前に決めることが重要です。自治体向け試験計画書の作り方を標準化し、残存リスクを隠さず報告することで、自治体は安全な本番移行を判断できます。実施時点の法令、政府ガイドライン、自治体規程、標準仕様、製品仕様の最新版を必ず確認してください。