自治体向け各種管理表の書き方・作り方

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

はじめに　要約と結論

自治体向け各種管理表は、プロジェクトの出来事を並べる記録簿ではなく、誰が、何を、いつまでに、どの根拠で判断するかを明確にする統制資料です。課題、リスク、変更、成果物、要員、会議・連絡、ライセンス、機器・資産、依頼、決定、品質、試験、不具合、移行、教育などを、共通の識別番号と更新ルールでつなぎます。

結論は、表を増やす前に管理目的、正本、更新者、更新契機、期限、エスカレーション、完了条件を決めることです。自治体向け各種管理表の書き方では、Excelの体裁より、未処理事項が確実に担当者へ届き、会議で判断され、証跡が残り、契約・要件・設計・試験・納品へ追跡できることを優先します。

想定読者

想定読者は、自治体のプロジェクト責任者、業務主管課、情報政策部門、契約・調達担当、個人情報保護・情報セキュリティ担当、PMO、受託事業者のプロジェクトマネージャー、設計・開発・試験・移行・運用担当、監査担当です。小規模案件では一人が複数役を担う場合もありますが、起票、対応、確認、承認の役割は可能な範囲で分けます。

1　管理表全体の章立て

各種管理表を一つの管理台帳群として扱い、最初に「管理表運用要領」を置きます。

1. 管理目的と適用範囲
2. 管理表一覧と正本の保管場所
3. ID体系、状態、優先度、日付、担当の共通ルール
4. 起票、更新、レビュー、承認、完了、再オープンの手順
5. 会議体と報告周期
6. 期限超過・重大事象のエスカレーション
7. アクセス権、機密区分、保存、廃棄
8. 各管理表の項目定義
9. メトリクスと定例報告
10. 終了時の確定、移管、アーカイブ

管理表一覧そのものにも、台帳ID、名称、目的、管理責任者、更新担当、更新頻度、正本URLまたは保管先、閲覧権限、保存期間、関連会議、確定版の出力形式を記載します。

2　共通の書き方・作り方

2.1　一行一事項にする

一つの行に複数の課題や依頼を書かないでください。「認証と帳票と移行を確認する」では担当も期限も完了条件も分けられません。論点が分かれた時点で別IDを採番し、親子関係で結びます。

2.2　事実、影響、対応を分ける

件名だけでなく、「現状の事実」「未対応の場合の影響」「必要な判断または対応」を別列にします。感想や推測は、根拠、仮定、確認方法とセットにします。自治体の意思決定が必要な事項は、選択肢、費用、日程、住民・業務への影響も記載します。

2.3　担当を個人または役割で一意にする

「自治体」「ベンダー」「関係者」は担当者名ではありません。責任者、対応担当、確認者を分け、組織変更に備えて所属・役割も記載します。個人名の取扱いは閲覧権限と保存方針に従います。

2.4　期限と完了条件をセットにする

「早急に」「調整中」は期限ではありません。回答期限、対応期限、承認期限を年月日で管理します。完了条件は「検討完了」ではなく「情報政策課が設計書第2.1版を承認し、変更票CHG-014へ反映」のように証跡を指定します。

2.5　状態を定義する

状態は、未着手、対応中、回答待ち、承認待ち、保留、完了、却下などに限定し、意味と変更権限を定義します。「ほぼ完了」のような自由入力は使いません。完了後に問題が再発した場合は履歴を消さず、再オープン日時と理由を残します。

2.6　表同士をIDで関連付ける

課題から変更が生じたら、課題IDと変更IDを相互参照します。変更から要件、設計、見積、スケジュール、試験、成果物へリンクします。メールやチャットのURLだけに依存せず、正式決定は決定管理表や議事録へ要約します。

3　各管理表の目的とテンプレート

3.1　課題管理表

課題は、すでに発生しており、解決・判断が必要な事象です。リスクと混同しません。

記載例は、「ISS-023：外部連携先の受入可能日が未確定。結合試験開始が最大10営業日遅延する可能性がある。連携先へ候補日と回答期限を提示し、期限までに確定しない場合は模擬環境で先行試験する。責任者は連携担当、回答期限は20XX年X月X日」です。

3.2　リスク管理表

リスクは、まだ発生していない不確実な事象です。発生確率と影響度を別々に評価し、回避、低減、移転、受容の方針を決めます。

必須項目は、リスクID、原因、リスク事象、結果、発生確率、影響度、評価値、兆候、予防策、発生時対応、対応責任者、監視期限、残存リスク、受容承認者です。「人員不足」の一語ではなく、「データ移行担当が一名で、並行稼働中に欠員が生じるとリハーサルが延期される」のように因果で書きます。

3.3　変更管理表

変更管理表は、要件・設計・構成・契約・日程・運用の変更を、実施前に評価・承認する表です。

口頭指示や会議の雰囲気で変更を着手してはいけません。緊急変更には簡略化した事前承認と、事後レビューの期限を用意します。

3.4　成果物管理表

成果物管理表には、成果物ID、名称、契約・仕様上の根拠、作成者、レビュー者、承認者、初回提出日、確定期限、版、状態、形式、保管先、関連成果物、検収条件、指摘件数、再提出日を記載します。ファイルが存在するだけで完了にせず、内容レビュー、指摘反映、承認、納品形式、ウイルスチェック、機密区分を確認します。

成果物の粒度が大きすぎる場合は、章または別紙単位のレビュー状態を子行で管理します。自治体が受領後に更新できるよう、PDFだけでなく編集可能形式、図の元データ、設定のエクスポート、依存フォント等も納品条件に従って確認します。

3.5　要員・体制・権限管理表

要員管理表には、組織、氏名または要員ID、役割、責任範囲、参画期間、稼働条件、保有スキル、代替要員、連絡手段、承認権限、システム権限、入退場・貸与物、教育受講、誓約・手続状況を記載します。要員の交代時は、引継ぎ資料、アカウント停止、新規付与、媒体・端末返却、秘密保持、連絡網更新を一つのチェックリストで処理します。

必要以上の個人情報を管理表へ集めず、閲覧者を限定します。詳細な勤務評価や本人確認書類などは、プロジェクト管理表と分離します。

3.6　会議・連絡・決定管理表

会議体一覧には、会議名、目的、開催頻度、招集者、参加必須役割、議題締切、資料締切、意思決定範囲、議事録作成者、承認期限を記載します。連絡先一覧には通常連絡、障害、重大インシデント、個人情報事故、災害、報道照会などの連絡区分と、一次・二次・最終連絡先を設けます。

決定管理表には、決定ID、論点、選択肢、決定内容、理由、制約、決定者、決定日、発効日、見直し条件、関連資料を残します。後日「なぜこの方式か」を説明できるため、自治体向け各種管理表の中でも重要です。

3.7　ライセンス・契約・クラウド利用管理表

ライセンス管理表には、製品・サービス、契約ID、用途、環境、メトリクス（利用者数、端末数、CPU、容量、API回数等）、数量、単価、契約期間、更新期限、自動更新、保守期限、管理者、利用条件、第三者ソフトウェア、終了時のデータ取得・削除を記載します。

無料枠、試用版、個人アカウントを本番前提にしません。オープンソースソフトウェアも、名称、版、ライセンス、入手元、改変有無、脆弱性対応、著作権表示の要否を管理します。契約終了後もログ保管やデータ移行が必要な場合は、読出し費用と期間を確認します。

3.8　機器・資産・媒体管理表

資産ID、品名、製造番号、構成要素ID、設置場所、所有者、利用者、取得日、保守期限、機密区分、ネットワーク識別、貸出・返却、廃棄方法、データ消去証跡を記載します。USB媒体やバックアップ媒体を利用する場合は、持出承認、暗号化、保管、受渡し、返却、消去を追跡します。

3.9　品質・試験・不具合管理表

品質管理表では、レビュー対象、規模、レビュー時間、指摘数、重大度、再確認結果を記録します。不具合管理表では、不具合ID、検出試験、再現手順、期待結果、実際結果、環境、証跡、重大度、優先度、原因、修正範囲、影響分析、再試験、横展開、クローズ承認を管理します。件数だけで品質を判断せず、未解決の重大度、再発、偏り、要件カバレッジを見ます。

3.10　移行・教育・運用引継ぎ管理表

移行管理表には、対象データ、抽出元、変換、検証、件数、エラー、再処理、承認、切戻しを記載します。教育管理表には、対象者、役割、教材、実施日、受講、理解度、追加支援を記載します。運用引継ぎ表には、手順、アカウント、監視、定例作業、障害、連絡、既知問題、未完了課題、操作訓練、受領承認を含めます。

4　管理表間のつながり

次のような流れを標準化します。

リスク RSK-012 が顕在化
  → 課題 ISS-034 を起票
  → 対応に設計変更が必要
  → 変更 CHG-009 で費用・日程・安全性を評価
  → 承認後、要件 REQ-045／設計 DD-018 を改訂
  → 試験 TST-122 を追加
  → 成果物 DLV-007 の版を更新
  → 決定 DEC-021 と議事録 MIN-015 に証跡
  → 課題の完了条件を確認してクローズ

リンクを張るだけでなく、各表には相手IDと要点を残します。ツールを変更しても関連性を復元できるためです。

5　優先度とエスカレーション

最重大・高・中・低等の基準を定め、住民の生命・安全、個人情報事故、全庁的停止は即時、主要業務や納期・予算への重大影響は当日など、初動と報告先を決めます。確率と影響度の積だけでなく、法令、住民影響、信頼、復旧困難性も考慮し、自治体の危機管理・情報セキュリティ・契約上の報告要件と整合させます。

6　自治体特有の観点

年度・予算・契約

会計年度、議会、予算執行、契約変更、検収、支払の期限はプロジェクト日程を強く制約します。変更管理表では、技術的に可能かだけでなく、契約範囲、予算科目、変更契約の要否、検収への影響を担当部門と確認します。

多部門・外部機関との調整

主管課だけで決められない事項に、情報政策、法務・個人情報、文書管理、財政、契約、広報、窓口、外部団体があります。課題表に「自治体回答待ち」と書くだけでなく、回答責任部署、決裁経路、必要資料、回答期限を明確にします。

公文書・情報公開・個人情報

管理表、議事録、メール、チャット、レビュー記録が公文書や開示対象となる可能性を考慮し、事実と判断根拠を適切に記録します。一方で、個人情報、脆弱性情報、認証情報、セキュリティ構成を必要以上に一般台帳へ載せません。保存、廃棄、開示、不開示の取扱いは、案件に適用される法令、条例、規則、自治体の文書管理・情報セキュリティ方針の最新版を担当部門と確認します。

住民サービスの継続

優先度は開発チームの都合ではなく、住民影響、窓口混雑、福祉・健康・防災等の業務特性、代替手段、繁忙期を含めて判断します。重大課題は技術復旧と住民案内を分けて管理します。

7　運用上の重要事項

定例会議では、表の全行を読み上げるのではなく、期限超過、今週期限、高優先度、状態変化、承認待ち、関連変更を抽出します。会議後に決定内容、担当、期限を更新し、議事録と食い違わないようにします。

週次のダッシュボード例は、未完了課題数、期限超過数、高リスク数、未承認変更数、成果物の予定対実績、重大不具合数、ライセンス更新接近数です。数字が改善して見えるように行を削除したり、完了条件前に閉じたりしてはいけません。

SaaS上の管理表は、契約終了、障害、アカウント喪失に備え、定期的に標準形式で出力し、マイルストーンごとの確定版を保存します。

8　禁止事項

管理表運用のポイント

管理表は、正本を一つに定め、一行一事項、担当者一意、期限は日付、完了条件は証跡付きとします。定例会議では全件の読み上げではなく、重大、期限超過、承認待ち、状態変化を優先します。表を更新すること自体を目的にせず、判断、実行、確認、関係文書の改訂まで閉じることが重要です。

1. 一つのセルに複数事項を詰め込むこと。
2. 担当を「関係者」「ベンダー側」など不明確にすること。
3. 期限を空欄、未定、なるべく早くのまま放置すること。
4. 完了条件を確認せず担当者の自己申告だけで閉じること。
5. 行を削除して履歴や期限超過を隠すこと。
6. 承認前の変更を実装し、後から変更票を作ること。
7. 課題、リスク、不具合、依頼を無秩序に一表へ混在させること。
8. メール・チャットだけを正式決定の証跡にすること。
9. パスワード、秘密鍵、個人情報、未公開脆弱性を一般管理表へ記載すること。
10. ライセンス条件やクラウド利用条件を確認せず複製・転用すること。
11. 自治体と受託者で別々の正本を持つこと。
12. 法令・条例・ガイドラインの最新版確認なしに適合を断定すること。

9　管理表の記入例と自治体統制

課題管理表の完成形例

「外部連携が未確定」のような件名だけでは行動につながりません。次のように、事実、影響、選択肢、期限、完了条件を分けます。

課題ID：ISS-041
件名：戸籍関連外部サービスの総合試験日が未確定
事実：接続先から本番相当環境の提供日はX月第2週以降との一次回答があった。
影響：当初計画のX月1日開始では試験できず、移行判定会議までの修正期間が短くなる。
選択肢A：模擬サービスで内部試験を先行し、接続後に差分試験を行う。
選択肢B：全体日程を延期する。契約・住民周知への影響評価が必要。
推奨：A。接続仕様とエラー応答を模擬環境へ反映することを条件とする。
責任者：連携統括　回答期限：20XX年X月X日
完了条件：接続日を双方が承認し、試験計画TST-PLAN-02と工程表を改訂する。
関連：RSK-014、CHG-011、MIN-018

この書き方なら、遅延という事実と将来の可能性、受託者ができる先行対応、自治体が判断すべき契約・周知影響を分けられます。

リスク管理表の完成形例

リスクID：RSK-026
原因：年度末の申請集中に対する実測データが少ない。
事象：ピーク時の同時利用が想定を超える。
結果：画面応答が遅延し、窓口問い合わせと重複申請が増える。
兆候：一時間当たり受付件数が計画値の80%を超える。
予防策：本番相当データ量で性能試験し、段階的な負荷制御を準備する。
発生時対応：受付を継続しつつ重い集計を停止し、案内を掲出して増強判断する。
残存リスク：外部認証側の制限は自治体単独では解消できない。
受容判断：主管課長と情報政策責任者が移行判定会議で確認する。

変更管理表の完成形例

住民向け通知を郵送だけからメール併用へ変更する場合、通知機能の追加だけを評価してはいけません。メールアドレスの取得目的、同意・訂正、誤送信、本文の情報量、送信失敗、再送、郵送への切替、問い合わせ、配信サービス契約、ログ保存、操作マニュアル、試験データを影響範囲へ含めます。変更後の住民負担が増えないか、オンラインを利用しない住民の代替手段が維持されるかも自治体側の承認事項です。

成果物と指摘の統制例

成果物を「レビュー中」の一語で管理せず、初回提出、自治体確認、指摘回答、再提出、承認、納品の状態を定義します。指摘は、必須修正、確認、提案、誤記等に区分し、受託者回答、自治体再確認、反映版を残します。回答済みでも成果物へ未反映なら完了にしません。複数文書へ横展開すべき指摘には親IDを付け、類似箇所の確認結果も証跡化します。

要員交代の統制例

要員交代申請には、交代理由、役割、必要スキル、予定日、引継ぎ期間、自治体承認の要否を記載します。交代日に、旧要員の庁内・クラウド・チケット・共有フォルダー権限を停止し、貸与端末・カード・媒体を返却します。新要員には必要最小限の権限だけを付与し、情報セキュリティ教育、業務説明、緊急連絡訓練の完了を確認します。「同じ会社の後任だから」と手続を省略しません。

ライセンス更新の統制例

更新日の九十日前、六十日前、三十日前などに通知し、継続、数量変更、代替、終了を判断します。自動更新契約でも、利用数、単価改定、不要アカウント、データ持出し、解約期限を確認します。年度予算をまたぐ契約は、予算担当・契約担当と早期に調整し、更新失念で住民サービスが停止しないよう代替策を用意します。

管理表の品質監査

PMOまたは管理責任者は、期限空欄、担当不明、長期保留、完了条件なし、関連IDなし、重大度の不整合を定期抽出します。完了件数だけでなく、再オープン率、期限超過日数、同一原因の再発、承認待ち滞留を見ます。自治体回答待ちが多い場合は、担当職員の責任だけにせず、必要な判断材料、決裁経路、会議日程が適切かを改善します。

10　実務チェックリスト

導入時

• [ ] 管理表ごとの目的、責任者、正本、更新頻度を決めた
• [ ] ID、日付、状態、優先度、担当、完了条件を標準化した
• [ ] アクセス権、機密区分、バックアップ、アーカイブを決めた
• [ ] 契約、要件、設計、試験、成果物との関連IDを定めた
• [ ] 期限超過と重大事象の報告ルートを合意した

定例会議

• [ ] 高優先度、期限超過、承認待ち、状態変化を抽出した
• [ ] 決定事項に決定者、理由、発効日がある
• [ ] 課題から生じた契約・費用・日程影響を確認した
• [ ] 次回までの担当と期限を読み合わせた
• [ ] 会議後、正本と議事録を同じ内容へ更新した

完了・納品時

• [ ] 未完了事項を運用課題または瑕疵対応へ正式移管した
• [ ] 完了行も含めた履歴を確定版として保存した
• [ ] ライセンス、アカウント、貸与物、媒体の引継ぎを確認した
• [ ] 成果物の承認、版、形式、保管先が一致する
• [ ] 保持不要な作業用複製をルールに従い廃棄した

11　FAQ　自治体向け各種管理表の作り方

Q1　管理表は一つのExcelにまとめるべきですか

小規模案件では一つのブックでも構いませんが、表ごとに目的、権限、更新者が異なります。行数や機密性が増えたら分割し、管理表一覧と共通IDでつなぎます。最重要なのは正本が一つであることです。

Q2　課題とリスクの違いは何ですか

課題はすでに発生し対応が必要な事象、リスクは将来発生する可能性がある不確実な事象です。リスクが発生したら課題IDを起票し、元のリスクIDを関連付けます。

Q3　優先度は誰が決めますか

起票者が仮設定し、定義済み基準に基づき管理責任者が確定する方法が実務的です。重大な住民影響、情報セキュリティ、個人情報、法令・契約影響は専門担当と責任者が判断します。

Q4　完了した行は削除してよいですか

削除しません。完了日、確認者、証跡、結果を残し、表示上はフィルターで除外します。誤登録も削除ではなく、取消理由と履歴を残す運用が安全です。

Q5　管理表の更新頻度はどの程度ですか

重大事項は発生時に即時、通常事項は日次または週次など、管理表ごとに決めます。定例会議直前だけの更新では、期限超過や事故報告が遅れます。

Q6　口頭で承認された変更はどうしますか

緊急時を除き実施前に正式記録を作ります。緊急変更は、承認者、理由、影響、実施内容を最低限記録し、定めた期限内に事後評価、文書改訂、恒久承認を行います。

Q7　ライセンス管理で見落としやすい点は何ですか

非本番環境、待機系、管理者、外部委託先、API回数、ログ容量、バックアップ読出し、更新後単価、契約終了時のデータ移行です。オープンソースの表示・再配布条件も確認します。

Q8　個人名を管理表へ書いてよいですか

業務上必要な範囲で、閲覧権限と保存ルールを定めて記載します。公開範囲の広い表では役割IDを使う方法もあります。不要な連絡先や評価情報は分離します。

Q9　管理ツールを導入すれば管理品質は上がりますか

ツールだけでは上がりません。項目定義、責任、更新契機、会議運用、完了条件が先です。選定時はアクセス制御、監査ログ、エクスポート、長期保存、自治体の利用条件を確認します。

Q10　どの時点で管理表を閉じますか

検収時に未完了事項を消すのではなく、運用、保守、別契約へ責任者・期限・証跡とともに移管します。移管先が受領した後、プロジェクト版を確定・アーカイブします。

まとめ

自治体向け各種管理表の書き方は、列を増やす技術ではありません。事実、影響、判断、担当、期限、完了条件を一行一事項で記録し、課題・リスク・変更・成果物・要員・連絡・ライセンスを共通IDで結ぶ仕事です。自治体向け各種管理表を会議、契約、設計、試験、運用と一体で更新すれば、抜け漏れの早期発見、説明責任、円滑な引継ぎに役立ちます。