標準化時代の調達の特徴
自治体システム標準化に伴い、自治体側の調達は「個別仕様での開発調達」から「標準準拠ソフトウェアの選定調達」へ転換します。要件は標準仕様書で固定され、ベンダー間の差別化は機能ではなく運用・移行支援・コスト・実績へ移ります。本記事では、自治体側が押さえるべきRFP作成・選定・契約の実務を解説します。
制度の概要は 自治体システム標準化（全体像）、移行プロジェクト全体は 移行プロジェクト実務 をご覧ください。
調達スケジュールの基本形
| 段階 | 主な作業 | 所要 |
|---|---|---|
| 1. 情報収集（RFI） | 標準準拠製品ベンダーへの情報照会、概算費用・前提条件の把握 | 1〜2か月 |
| 2. RFP作成 | 提案依頼書の作成、評価基準の策定、配点の合意 | 2〜3か月 |
| 3. 公募・提案受付 | 公告、提案書受領、質問対応 | 1〜2か月 |
| 4. 提案評価 | 書類審査、プレゼン、デモ、評価会議 | 1〜2か月 |
| 5. 優先交渉者決定・契約 | 条件交渉、契約締結、議会承認（必要な場合） | 1〜2か月 |
RFPに盛り込むべき項目
標準化時代のRFPは「機能要件」より「非機能・運用・移行・コスト」の比重が高くなります。
必須記載項目
- 業務スコープ：対象20業務のうちどれを発注するか、関連システム連携範囲
- 標準準拠の証明：標準仕様書バージョンへの準拠状況、適合性確認書
- 稼働基盤：ガバメントクラウド利用前提、対象クラウド事業者、リージョン
- 非機能要件：稼働率、応答時間、データ保管期間、災害対策。IPA非機能要求グレード をベースに記述
- 移行要件：旧システムからの移行範囲、移行支援、データクレンジング、リハーサル
- 運用・保守：監視、障害対応、ヘルプデスク、定期保守、SLA
- セキュリティ要件：ISMAP登録、LGWAN-ASP認定、ログ・暗号化・認証
- 連携要件：庁内他システム・データ連携基盤・マイナンバー情報連携
- BPR支援：業務側の見直し（書かない窓口・ワンストップ等）への支援可否
- 費用構造：初期費用、年間費用、変動費の前提、5〜10年TCO
- 契約期間と更新：基本契約年数、更新条件、解約・データ移行性
- 体制と実績：プロジェクト体制、PM経験、類似自治体への導入実績
SaaS型・IaaS型の選び方
標準準拠ソフトウェアは大きくSaaS型（マルチテナント）とIaaS／PaaS上の自治体個別構築型に分かれます。それぞれメリット・デメリットがあり、業務特性で使い分けます。
| 項目 | SaaS型 | IaaS／個別構築型 |
|---|---|---|
| 初期コスト | 低い | 高い |
| 運用コスト | 月額固定または従量制 | 運用工数が高めに |
| 標準仕様変更への追随 | ベンダー側で一括対応 | 個別追加対応が必要 |
| カスタマイズ | 原則不可（標準範囲のみ） | 限定的に可能 |
| 連携の自由度 | API経由で限定的 | 柔軟性高い |
| ガバナンス | ベンダーに依存 | 自治体側で制御 |
| データの所有・移管性 | SaaS終了時のデータ取得方法を契約で明記必要 | 自治体保持が容易 |
| 適性業務 | 定型業務（住民記録、税、福祉等） | 独自度が高い周辺業務 |
原則としてSaaS型を第一候補とし、特殊な連携や独自要件で対応困難な業務のみIaaS／個別構築を検討する流れが主流です。
評価軸と配点の設計
提案評価は「価格点＋技術点」の総合評価方式が一般的です。標準化時代は機能差が小さくなるため、運用・実績・移行支援の配点を厚くするのが鉄則。
| 大分類 | 配点目安 | 評価項目例 |
|---|---|---|
| 標準準拠・機能 | 20〜25点 | 標準仕様書準拠率、必須機能、任意項目対応 |
| 非機能・運用 | 15〜20点 | 稼働率実績、監視体制、ヘルプデスク |
| 移行支援 | 15〜20点 | データ移行ツール、リハーサル支援、教育プログラム |
| BPR支援 | 10〜15点 | 窓口DX・オンライン申請の伴走支援 |
| セキュリティ | 10〜15点 | ISMAP登録、認証・ログ、運用監視 |
| 体制・実績 | 10〜15点 | 類似自治体導入数、PM経験、国内体制 |
| 価格点 | 20〜30点 | 初期費用、5〜10年TCO |
契約・SLAのポイント
- SLA明文化：稼働率、応答時間、障害対応時間、復旧目標。未達時のペナルティ・改善義務を明記
- 標準仕様改訂への追随：標準仕様書のバージョンアップに対する対応義務・期限・追加費用の有無
- データの所有・移管性：契約終了時のデータエクスポート形式、移行期間、費用
- 第三者監査・証憑：SOC2／ISMAP／ISMS等のレポート提出義務
- 運用変更：マイナンバー情報連携の改正等、制度変更対応の費用負担ルール
- サブコン・委託先：再委託の事前承認、再委託先のセキュリティ要件遵守
- ベンダーロックイン回避：データ標準（標準データレイアウト）準拠、APIの公開、移行容易性
- 個人情報・特定個人情報：取扱条項、漏洩時の通報義務、対応費用
- 契約期間と中途解約：5年契約が主流。中途解約条件、自動更新の可否
共同調達と単独調達
同一ベンダー製品を採用する近隣自治体間で共同調達を行うケースが増えています。
| 項目 | 共同調達のメリット | 共同調達のデメリット |
|---|---|---|
| コスト | スケールメリットで単価低下 | 個別要件が反映しにくい |
| 運用 | 運用ノウハウの相互参照 | 意思決定が複雑化 |
| 体制 | 事務局負担の分担 | 幹事自治体への負担集中 |
| 移行スケジュール | 横並びの進捗管理 | 1自治体の遅延が全体に波及 |
都道府県主導の協議会、近隣市町村のグループ調達、システム共通プラットフォームへの参加など、自治体の規模・体制に応じた選択肢があります。
費用構造の見方と補助金
- 初期費用：環境構築、設定、データ移行支援、職員研修
- 年間運用費：ライセンス／利用料、運用監視、ヘルプデスク、保守
- 追加費用：標準仕様改訂対応、業務量増加、追加トレーニング
- 5〜10年TCO：契約期間全体の総保有コストで比較
- 移行費用補助金：デジタル庁・総務省の補助制度を活用。要件と申請スケジュールを確認
調達でよくある落とし穴
- 機能要件の過剰記述：標準仕様書を超える要件が紛れ込み、ベンダー側で「対応不可」と返答され失格
- SLAの曖昧さ：「ベストエフォート」のままで運用後に問題化
- 移行支援の評価不足：移行段階でベンダー側の手薄さが露呈
- 長期契約の硬直化：5年契約後も同ベンダーが事実上ロックイン
- SaaS終了時のデータ移行性軽視：契約終了時にデータ取得が困難になる
- BPR支援の見落とし：システムは入ったが業務改革が進まない
まとめ
自治体システム標準化の調達は、機能カスタマイズの世界から運用・移行・実績で勝負する世界へ転換しています。RFPでは非機能・運用・移行支援・BPR支援を厚く設計し、SaaS型／IaaS型の特性を踏まえて業務ごとに最適解を選ぶことが重要です。契約条項ではSLA・標準仕様改訂対応・データ移行性・ロックイン回避を明文化し、共同調達・補助金活用も視野に入れることで、長期的に持続可能な運用基盤を構築できます。