自治体向け構築スケジュールの書き方・作り方

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

はじめに――構築スケジュールの結論

自治体向け構築スケジュールは、日付を並べた工程表ではありません。調達、契約、設計、製造、データ移行、庁内調整、住民周知、試験、研修、切替、検収、支払までの依存関係を可視化し、誰が、何を、いつまでに、どの承認と証跡をもって完了させるかを管理する基準です。よい構築スケジュールは、遅延が起きる前に兆候を検知し、停止基準、回復策、ロールバック、意思決定期限まで示します。

自治体案件では、予算年度、債務負担行為、議会、契約手続、年度末・年度初め、税務繁忙期、選挙、災害対応、法改正施行日、国の補助金・交付金期限など、民間案件とは異なる固定条件があります。自治体向け構築スケジュールの書き方では、技術工程だけでなく行政手続、原課確認、個人情報保護・セキュリティ審査、住民への説明を同じ計画上で扱うことが重要です。

要点：期限から逆算するだけでなく、承認待ち、調達リードタイム、レビュー再提出、障害復旧、災害や選挙による作業禁止期間を含む「実行可能な余白」を設計します。

想定読者

• 自治体の情報政策部門、業務原課、契約・会計・法務・広報担当
• CIO補佐官、情報セキュリティ責任者、個人情報保護担当
• 受託事業者のプロジェクトマネージャー、PMO、各技術チーム
• クラウド、回線、機器、パッケージ、データ移行等の再委託先
• 検収責任者、監査担当、運用引継ぎ担当、サービスデスク

経営層にはマイルストーンとリスク、現場には詳細タスクと前後関係、原課にはレビュー・受入試験・研修の拘束期間を示します。一つの巨大な表で全員の用途を満たそうとせず、全体マイルストーン、工程別WBS、直近詳細計画の三層に分けると管理しやすくなります。

標準的な章立て

1. 目的、対象、前提、関連文書
2. 契約期間、サービス開始日、固定期限
3. 体制、カレンダー、稼働時間、承認者
4. 全体工程、マイルストーン、クリティカルパス
5. WBS、担当、成果物、完了条件
6. 調達・行政手続・外部依存
7. 設計・構築・移行・試験・研修・切替
8. 承認、レビュー、検収、証跡
9. リスク、バッファ、停止基準、回復計画
10. 変更管理、進捗測定、報告
11. ロールバック、予備日、緊急時対応
12. チェックリスト、更新履歴

1. 前提条件と固定期限を確定する

最初に動かせない日付を特定します。契約始期・終期、法改正施行日、現行契約終了日、クラウド利用開始日、議会・選挙、住民通知発送日、データ基準日、年度末の支払期限などです。日付の根拠、決定者、変更可能性を記載し、「希望日」と「必達日」を区別します。

休日は国民の祝日だけではありません。閉庁日、庁舎停電、システム一斉保守、繁忙期、凍結期間、地域行事、災害訓練をカレンダーに登録します。受託者の営業日と自治体の開庁日が異なる場合、レビュー回答日数は双方の営業日で定義します。

前提条件表の例

2. マイルストーンの作り方

マイルストーンは単なる日付ではなく、客観的な通過条件です。「基本設計完了」ではなく、「全レビュー指摘が解消または課題管理され、自治体承認者が版1.0を承認」と定義します。各マイルストーンに責任者、判定会議、必要証跡、未達時の影響を付けます。

代表的なマイルストーンは、キックオフ、要件確定、基本設計承認、詳細設計承認、環境準備完了、構築完了、単体試験完了、結合試験完了、総合試験完了、移行リハーサル合格、受入試験合格、運用引継ぎ完了、切替判定、サービス開始、検収です。

行政側のマイルストーンとして、個人情報保護に関する審査、クラウド利用審査、セキュリティ審査、契約変更、住民広報、庁内通知、議会説明が必要になる場合があります。自治体の内部手続を受託者だけで推測せず、自治体側の担当と所要日数を合意します。

3. WBSの分解

WBSは成果物単位で分解し、原則として一タスクを数日から二週間程度で完了・判定できる大きさにします。「システム構築 60日」のような大項目だけでは遅延を検知できません。タスクID、名称、成果物、開始、終了、期間、先行タスク、担当、レビュー者、完了条件、進捗率、状態を持たせます。

作業は、プロジェクト管理、要件、設計、基盤、アプリ、データ、連携、セキュリティ、試験、教育、移行、運用、調達、広報、検収に分けます。自治体側タスクも同じWBSに含めます。ただし契約上の責任を曖昧にしないよう、自治体作業、受託者作業、共同作業を明示します。

WBS記載例

4. 依存関係とクリティカルパス

タスクの前後関係には、終了後開始だけでなく、開始後開始、終了同時、一定日数の待ちを設定します。例えば証明書はDNS確定後、回線試験は開通後、移行試験はマッピングと匿名化承認後でなければ着手できません。人員や検証環境の競合というリソース依存も確認します。

クリティカルパス上のタスクに余裕はありません。回線・機器納期、クラウド審査、外部機関との接続試験、データ移行、受入試験は長期化しやすいため、早期に着手します。総合バッファだけを最後に置くのではなく、不確実性の高い工程後に管理バッファを配置します。

クリティカルパスを短縮するとき、承認や試験を省略してはいけません。並行化できる作業と、品質・セキュリティ上順序を守る作業を区別します。設計未承認のまま本番構築を始める場合は手戻りと統制逸脱が生じるため、限定着手の範囲、リスク、承認を明記します。

5. 見積りと期間設定

期間は作業量だけでなく、レビュー待ち、修正、再試験、承認、担当者不在を含めます。類似案件実績、三点見積り（楽観・最頻・悲観）、担当者ヒアリングを組み合わせます。人数を増やせば単純に短縮できるとは限らず、引継ぎや調整コストも考慮します。

自治体レビューは複数部署にまたがることがあります。「自治体確認5日」と一括せず、原課、情報政策、セキュリティ、個人情報、法務の順序と並行可否を確認します。文書量に応じたレビュー期間を確保し、回答期限前日に大量提出する計画は禁止します。

祝日、年末年始、年度末、異動期を実日数へ反映します。4月の人事異動で承認者や原課担当が変わる場合、引継ぎ期間をタスク化します。納入機器は半導体不足や物流遅延、クラウドは契約・アカウント発行のリードタイムを確認します。

6. 設計・構築・試験のゲート

工程の間に品質ゲートを設けます。要件未確定のまま設計を完了扱いにせず、設計未承認のまま構築を開始せず、重大欠陥が残るまま受入試験へ進めません。ゲート条件は、成果物承認、欠陥残数、試験合格率、性能、安全性、バックアップ復元試験、運用体制、教育完了などで定義します。

例として、総合試験終了ゲートは「重要度A・Bの欠陥ゼロ、重要度Cは回避策と解消期限を自治体承認、必須試験100%実施、個人情報誤表示ゼロ、性能目標達成」とします。数値は案件のリスクと契約に合わせます。

切替判定ゲートでは、移行リハーサル、ロールバック訓練、監視、問い合わせ体制、住民周知、業務代替、バックアップ、緊急連絡網を確認します。作業時間内に完了できない見込みが出た場合の停止時刻と、切戻し開始の最終時刻をスケジュール上に明記します。

7. データ移行と個人情報保護

データ移行は、抽出、受領、マッピング、クレンジング、変換、投入、照合、原課確認、差分移行、旧環境保全、消去までを分解します。件数・金額・ハッシュ・代表サンプル等の照合方法と、誰が合否を承認するかを設定します。

本番個人情報を扱う期間と場所を最小化し、暗号化、アクセス制御、授受記録、保管期限、消去証明をタスク化します。媒体搬送がある場合は封印、授受者、時刻、経路を記録します。個人番号を含む場合、委託・再委託、作業場所、ログ、権限について特定個人情報の管理要件を確認します。

移行失敗時のロールバックには、新システムで受け付けた更新の扱い、旧システム再開、差分同期、住民・職員への案内を含めます。リハーサルで実測した所要時間を本番計画へ反映し、推測値のまま切替日に入らないことが重要です。

8. 進捗測定と報告

進捗率は担当者の感覚ではなく、0/50/100ルール、成果物ページ・機能単位、試験消化数など、客観的基準で測ります。「90%完了」が何週間も続く状態を防ぎます。開始遅延、終了遅延、残作業、課題、次週予定、意思決定依頼を週次報告にまとめます。

主要指標には、計画対実績、マイルストーン達成率、成果物承認率、レビュー指摘残数、欠陥件数と滞留日数、試験実施・合格率、課題期限超過、クリティカルパス余裕を使います。数字だけでなく、住民サービス、個人情報、法令遵守への影響を説明します。

遅延の報告は、判明した時点で行います。期限当日に初めて伝えることを禁止し、予兆閾値を設定します。例として、クリティカルタスクが1日遅延、レビュー指摘が想定の150%超、欠陥解消速度が発生速度を下回る場合に黄色判定とします。

9. スケジュール変更管理

基準スケジュールを承認後に固定し、実績・予測とは別に保存します。変更時は、理由、変更前後、クリティカルパス、費用、品質、セキュリティ、契約、住民影響を評価します。受託者内の判断だけで納期や試験期間を変更してはいけません。

変更には承認者と証跡が必要です。軽微な順序入替えの許容範囲も事前に決めます。契約期間、納入物、検収、支払に影響する変更は、契約担当と協議し、必要な契約変更手続を行います。版番号、更新日、変更箇所、承認日を履歴に残します。

10. 停止基準、回復計画、ロールバック

構築中の停止基準は、重大な設計不整合、個人情報漏えいのおそれ、承認外の構成、バックアップ失敗、重大欠陥の増加、外部依存未成立、必要要員不在等です。停止は失敗ではなく、被害拡大を防ぐ統制です。停止判断者、報告先、証拠保全、再開承認を決めます。

スケジュール回復策は、再優先順位付け、要員再配置、段階リリース、予備日利用、非クリティカル機能の合意済み延期です。試験・レビュー・バックアップ・個人情報保護を削って回復させてはいけません。範囲変更は要件、費用、契約、住民影響を合意してから行います。

本番切替スケジュールには、作業ごとの予定と上限時間、継続判定、切戻し開始最終時刻を設定します。ロールバック工程も本番工程と同じ粒度でWBS化し、復旧確認、原課確認、住民周知まで含めます。

自治体特有の重要事項

• 予算年度と契約期間を越える作業の法的・会計的根拠を確認する。
• 議会、選挙、税、給付、福祉、災害等の繁忙・凍結期間を反映する。
• 住民向けオンラインサービスは閉庁後も動く前提で影響を評価する。
• 原課レビュー、庁内決裁、セキュリティ・個人情報審査を工程化する。
• 国・都道府県・共同利用団体・外部事業者の接続日程を早期合意する。
• 法改正や標準仕様の施行日と、経過措置・移行期間を確認する。
• 検収条件と支払期限から逆算して、修補・再検査の期間を確保する。
• 法令、政府ガイドライン、自治体規程、標準仕様は最新版を公式情報で確認する。

禁止事項

• 根拠のない一律バッファ、担当者の希望だけによる日付設定
• 承認、レビュー、セキュリティ審査、受入試験の省略や形骸化
• クリティカルパスを把握しないままの一律前倒し
• 自治体側作業を「別途」として期間・担当を設定しないこと
• 本番データ授受、個人情報消去、権限削除のタスク漏れ
• 遅延を隠すための進捗率操作、基準日程の無断上書き
• 重大欠陥を未解決のまま後工程へ送ること
• 切戻し所要時間を確保しない本番作業計画
• 災害・選挙等の禁止期間に無承認で変更作業を置くこと
• 古い法令・標準・カレンダーを未確認で使用すること

実務チェックリスト

初版作成

• [ ] 契約、予算、法改正、現行終了等の固定期限を確認した
• [ ] 自治体と受託者の営業日・作業可能時間を登録した
• [ ] 議会、選挙、繁忙期、災害対応等の禁止期間を確認した
• [ ] 全成果物、レビュー、承認、検収をWBS化した
• [ ] 回線・機器・クラウド・外部接続のリードタイムを確認した
• [ ] 自治体側と再委託先のタスク・責任者を明記した
• [ ] データ移行、個人情報審査、消去証明を工程化した
• [ ] クリティカルパスと管理バッファを確認した

運用中

• [ ] 基準、実績、最新予測を区別して更新している
• [ ] タスク完了条件を証跡で確認している
• [ ] クリティカルパスの余裕を定期確認している
• [ ] レビュー指摘、欠陥、課題の滞留を監視している
• [ ] 遅延予兆を期限前にエスカレーションしている
• [ ] 変更理由と承認記録を残している
• [ ] 重要会議の意思決定期限を管理している
• [ ] 法令・仕様変更を定期的に確認している

切替前

• [ ] 移行リハーサルの実測時間を反映した
• [ ] バックアップとロールバック訓練が成功した
• [ ] 開始・継続・停止・再開の判定時刻を設定した
• [ ] 個人情報の授受、保管、消去の担当と時刻を設定した
• [ ] 住民・職員への周知と問い合わせ体制が整った
• [ ] 翌営業日の業務開始確認を工程に含めた
• [ ] 予備日と予備日使用の承認条件がある

具体例：12か月プロジェクトの骨格

4月：契約、キックオフ、現行調査、詳細計画承認
5～6月：要件確認、セキュリティ・個人情報審査着手
7～8月：基本設計、外部接続・回線申請、設計承認
9～10月：詳細設計、環境構築、移行ツール作成
11月：単体・結合試験、運用設計、研修教材作成
12月：総合試験、性能・セキュリティ・障害試験
1月：移行リハーサル、受入試験、職員研修
2月：是正、第二回移行リハーサル、切替判定
3月：本番移行、監視強化、検収、旧環境データ消去計画確定

各月の終端には成果物と承認ゲートを置きます。これは例であり、対象業務の繁忙期、調達方式、法改正、規模に合わせて組み替えます。年度末本番化は会計・人事・税等の繁忙と重なりやすいため、合理的な理由がなければ余裕のある時期を検討します。

テンプレート

# ○○システム構築スケジュール
基準日／版／作成者／承認者／機密区分

## 1. 目的・対象・関連文書
## 2. 契約期間・サービス開始・固定期限
## 3. カレンダー・作業可能時間・禁止期間
## 4. 体制・責任分界・承認経路
## 5. 全体マイルストーンと通過条件
## 6. 工程別WBSと依存関係
## 7. クリティカルパス・バッファ
## 8. レビュー・試験・移行・研修・検収
## 9. リスク・停止基準・回復計画
## 10. ロールバック・予備日
## 11. 進捗報告・変更管理
## 12. 更新・承認履歴

FAQ――自治体向け構築スケジュールの作り方

Q1. ガントチャートだけで十分ですか。

十分ではありません。各タスクの成果物、完了条件、依存関係、担当、承認、証跡、リスクを持つWBSが必要です。ガントチャートはそれを時間軸で見せる一つの表現です。

Q2. どの粒度でタスクを分けますか。

進捗と完了を客観的に判定できる粒度にします。通常は数日から二週間以内が目安ですが、重要・高リスク作業はより細かく分けます。管理工数とのバランスも取ります。

Q3. 自治体の承認期間はどう見積もりますか。

対象部署、会議・決裁経路、標準処理日数、差戻し実績を確認します。作成期間とレビュー期間を重ねず、指摘反映と再承認も確保します。

Q4. 遅延したとき試験期間を短縮してよいですか。

品質と安全の合格基準は維持します。自動化、優先順位、要員配置、段階リリース等を検討し、範囲・納期変更は自治体承認と契約手続を経ます。

Q5. バッファはどこに置きますか。

外部調達、設計承認、移行リハーサル等の不確実性が高い箇所の後と、プロジェクト終端に置きます。誰でも自由に消費できる余白ではなく、利用判断者を決めます。

Q6. 進捗率90%のまま進まない問題を防ぐには。

成果物の提出・レビュー・承認、試験件数などに基づく客観的ルールを使います。残作業と完了条件を明示し、時間消費を進捗として扱いません。

Q7. 法改正日が確定していない場合はどうしますか。

複数シナリオと判断期限を設定し、公式情報の確認担当を決めます。特定日を勝手に確定値とせず、施行日・標準仕様の最新版を継続確認します。

Q8. 個人情報保護はスケジュールにどう表しますか。

審査、承認、匿名化、授受、アクセス付与・削除、消去、証明書受領を独立タスクにします。単なる注意書きでは、担当と期限が抜け落ちます。

Q9. 災害で自治体担当者が対応できない場合は。

自治体の業務継続計画を優先し、作業延期・安全停止条件を定めます。連絡不能時に独断で本番変更せず、システムを安全な状態に保ちます。

Q10. スケジュール変更はいつ契約変更になりますか。

契約期間、納期、成果物、費用、検収条件等へ影響する場合は契約担当に確認します。判断は契約内容と自治体規程によるため、最新版の規程・契約を基に正式手続を行います。

月次・週次レビューの実践例

週次会議では、終了予定を過ぎたタスクだけでなく、今後四週間のクリティカルタスクを確認します。担当者は「着手済み」ではなく、残作業、完了条件、必要な意思決定、予測完了日を報告します。自治体が回答すべき照会には、回答期限と未回答時の影響を付けます。

月次会議では、基準日程との差、クリティカルパス、費用・契約への影響、品質指標、個人情報・セキュリティ課題を統合します。例えば回線開通が二週間遅れる場合、結合試験開始、外部接続試験、受入試験、切替判定への連鎖を示し、仮設環境、工程順序変更、サービス開始変更の三案を比較します。各案について費用、品質、住民影響、承認期限を示すと意思決定ができます。

議事録には決定事項だけでなく、却下案と理由も残します。担当、期限、承認者を定め、次回会議で完了証跡を確認します。黄色・赤色の判定を見栄えのために緑へ戻すのではなく、原因と回復条件が成立したときだけ変更します。

まとめ

自治体向け構築スケジュールの書き方で重要なのは、すべての行政・技術・業務タスクを、依存関係と完了条件でつなぐことです。承認と証跡、個人情報保護、客観的な停止基準、ロールバック時間、住民周知、予備日を工程の外に置かないでください。自治体向け構築スケジュールの作り方を標準化し、基準計画と実績を正直に比較すれば、遅延の予兆を早く捉え、安全な意思決定ができます。実行時には、法令、国の標準、自治体の条例・規程、契約、休日、各サービス仕様の最新版を必ず確認してください。