官公庁のシステム開発の発注/外注/依頼/委託方法について

官公庁のシステム開発は、標準化方針を踏まえて要件を整理し、RFPから保守まで一貫して計画して進めます。

  • 法令と標準化方針を確認し、対象業務と必要な機能を整理する
  • RFP、調達方式、契約条件を比較し、発注先と体制を決める
  • 検収、セキュリティ、保守の条件を定め、稼働後も改善する

地方自治法・会計法に基づく手続きは、初めて担当する職員には複雑に感じられることも多いでしょう。近年はデジタル庁のガバメントクラウド移行・標準化への対応も加わり、発注プロセスが複雑になっています。

▼全体ガイドの記事
・官公庁のシステム開発の完全ガイド

発注前の準備と要件整理

発注前に確認する業務課題、目的、予算、標準化方針との整合を示すチェックリスト
4項目をそろえると、RFP作成へ進みやすくなります。

発注の成功は準備段階で決まります。そのため、現状の業務課題を把握し、システム化の目的を明確にして、予算を確保しておきます。デジタル庁の標準化方針との整合も、あわせて確かめておきます。

標準化方針との整合確認

発注前に確認すべき最も重要な事項は、デジタル庁が定める「自治体情報システムの標準化・共通化」への対応が必要かどうかです。

具体的には、2025年度末を期限として、住民基本台帳・税・社会保障など主要20業務については、デジタル庁が定める標準仕様に準拠したシステムへの移行が自治体に義務付けられています。これらの対象業務では、独自仕様のスクラッチ開発よりも、標準準拠のパッケージシステムへの移行が求められます。

まずは、対象業務かどうかを確認し、デジタル庁が示す移行スケジュールと国庫補助の活用可能性を事前に調べます。そのうえで、調達方式・スケジュール・予算を決めます。総務省・デジタル庁が提供する「自治体情報システム標準化・共通化チェックシート」なども活用できます。

RFP(提案依頼書)の作成

官公庁のシステム調達では、RFP(提案依頼書)を詳細に作成することが大切です。

RFPには、「調達の概要(目的・背景・対象業務)」「業務要件(現行業務フロー・必要な機能一覧)」「技術要件(性能・セキュリティ・可用性・標準化への準拠要件)」を盛り込みます。さらに、「接続要件(マイナンバーシステム・LGWAN・外部システムとの連携)」「プロジェクト体制・スケジュール要件」「評価基準(技術評価・価格評価の配点)」を明記します。提出書類・提出期限も、あわせて示します。

デジタル庁・総務省が公開している「システム調達に関するガイドライン」「調達のためのTechリスト」も参考になります。RFP作成の負荷が大きい場合は、外部のITコンサルタントや技術専門家の支援を受けることも選択肢です。

ポイント

標準化の対象業務かどうかを先に確かめ、業務要件と技術要件をRFPに書き出せるかで、準備の進み具合を判断します。

調達方式と選定プロセス

官公庁のシステム調達では、地方自治法・会計法に基づいて、適切な調達方式を選ぶ必要があります。調達金額やシステムの特性、スケジュールなどに応じて、最も合う方式を決めます。

入札方式の種類と特徴

官公庁のシステム調達で用いられる主な調達方式は4種類あります。①一般競争入札:予算規模が一定以上(国の場合250万円以上が基準)の調達に適用される原則的な方式です。競争性・透明性が高い反面、価格のみの評価となりがちで、品質が低下するリスクがあります。

②総合評価落札方式:価格点と技術評価点を組み合わせた評価方式で、品質も考慮した選定が可能です。そのため、システム開発に適した方式として、採用する自治体・省庁が増えています。③公募型プロポーザル方式:技術提案を重視する方式で、提案内容を評価したうえで最優秀者と価格交渉を行い、複雑なシステム開発や高度な専門性が求められる案件に適しています。

④随意契約:一定の条件下で特定のベンダーと直接契約する方式で、緊急性が高い場合・少額案件・特殊な技術を保有するベンダーが限定される場合等に認められます。透明性確保のため、随意契約の理由と価格の妥当性を文書で記録しておくことが重要です。

アジャイル調達の活用

デジタル庁は、従来の大規模一括調達(ウォーターフォール型)から、小規模・短期間の反復型調達(アジャイル型)への転換を推進しています。アジャイル調達では、まず概念実証(PoC)や最小限の機能(MVP)を小規模・短期間で開発・評価し、その後に本格開発へ移行する進め方をとります。

これにより、仕様の不確実性が高いプロジェクトでも、リスクを管理しながら開発を進められます。

ただし、従来の一括調達に慣れた職員やベンダーにとっては、プロセスが異なるため、外部の技術支援や研修が必要な場合もあります。デジタル庁が公開している「アジャイル開発実践ガイドブック」も参考になります。

ポイント

判断に迷ったら、調達金額・システムの特性・スケジュールの3点を基準に方式を選びます。品質を重視するなら、総合評価落札方式やプロポーザル方式が候補になります。

契約締結と発注後の管理

契約書を中心に、開発範囲、納品物、知的財産権、情報セキュリティ、再委託の制限を示す図
変更管理の記録とあわせて、契約条件を確認できます。

ベンダーが選定されたら、契約締結とプロジェクト管理の体制を整えます。官公庁向けのシステム開発契約には、民間よりも厳格な管理が求められます。

契約書のポイント

官公庁向けシステム開発の契約書には、必ず定めておきたい内容があります。まず、開発範囲の明確化(機能要件・非機能要件・接続先システム)と、納品物の定義(システム・ソースコード・設計書・操作マニュアル等)を定めます。あわせて、マイルストーンと進捗報告義務や、知的財産権(納品物の権利は原則として発注者側に帰属)も盛り込みます。

情報セキュリティ(個人情報保護・セキュリティ基準への準拠義務・事故時の報告義務)と、再委託の制限(下請け・再委託の範囲と承認手続き)も取り決めます。さらに、瑕疵担保責任(納品後の不具合対応の範囲・期間)と、SLA(稼働率・障害対応時間等の数値基準)も定めます。

特に「知的財産権の帰属」は、ソースコードを将来の保守・改修で他社へ移行できるよう、発注者側に権利があることを明確にしておくことが重要です。

プロジェクト管理体制

官公庁のシステム開発プロジェクトでは、発注者側にも適切な管理体制を整えておく必要があります。具体的には、PMO(プロジェクト管理室)を設置し、IT専門職員または外部技術顧問を配置します。そのほか、週次進捗会議の実施と変更管理プロセスの整備も求められます。

中でも欠かせないのが「変更管理」です。仕様変更が起きたときは、変更内容、影響(コスト・スケジュール)、承認者を記録します。口頭だけで変更に合意することは避けます。

また、プロジェクトの途中で、デジタル庁・総務省などの指針改訂やセキュリティガイドラインの改定が起きることもあります。その対応も、変更管理のプロセスを通じて適切に進める必要があります。

ポイント

契約書に知的財産権の帰属とSLAを定め、変更内容と承認者を記録して進められる体制があるかどうかが判断の目安です。

検収・受け入れと保守契約

UATの最低2〜4週間、稼働率99.9%以上、初回応答1時間以内、Critical障害の復旧目標4時間以内を示す4項目の図
期間とSLAの値を並べて、契約条件を見比べられます。

システムの納品・検収と、その後の保守契約の締結は、発注プロセスの最終段階にあたります。検収と保守の条件を順に確かめながら進めます。

検収基準とUAT(ユーザー受け入れテスト)

官公庁向けシステムの検収では、事前に「検収基準チェックリスト」を作成し、全ての要件が満たされているかを確認します。特に重要な確認項目は、①全機能の動作確認(RFPに記載された要件の充足)、②セキュリティ要件の充足確認(第三者セキュリティ評価の実施・結果確認)、③アクセシビリティ確認(JIS X 8341-3への対応)です。

そのほか、④マイナンバーシステム等との連携確認、⑤性能テスト結果の確認(ピーク時のアクセスへの耐性)、⑥設計書・ソースコード・操作マニュアルの納品確認も挙げられます。

業務担当職員によるUAT(ユーザー受け入れテスト)は、本番業務に近い環境で、十分な期間(最低2〜4週間)をかけて行います。

保守・サポート契約の要点

本番稼働後の保守・サポート契約では、SLAを明確に定めておく必要があります。具体的には、官公庁向けシステムの保守SLAの主要項目として、「稼働率(例:99.9%以上)」「障害時の初回応答時間(例:1時間以内)」「障害復旧目標時間(RTO:例:Critical障害は4時間以内)」があります。

そのほか、「法改正対応の対応期限(例:施行1か月前までに対応完了)」「定期的な脆弱性診断の実施(例:年1回)」なども定めます。また、住民サービスに直結する重要システムの場合、24時間365日の障害対応体制が求められることもあります。

保守費用は毎年度の予算計画に含めます。そのうえで、複数年契約(3〜5年)にすると、コストの安定化と質の確保につながります。

ポイント

検収では、UATを最低2〜4週間行えたかを見ます。保守は、SLAの数値基準を契約に入れて決めます。

まとめ

官公庁のシステム開発の発注を成功させるには、標準化方針との整合を確認し、詳細なRFPを作って、適切な調達方式を選ぶ必要があります。そのうえで、契約を厳格に結び、プロジェクト管理の体制を整えます。

調達方式は案件の特性に応じて、総合評価落札方式、プロポーザル方式、アジャイル調達などを使い分けます。契約書には、知的財産権の帰属、セキュリティ要件、SLAを明確に定めます。あわせて、ベンダーリスク管理も徹底します。

検収では、業務担当職員によるUATとセキュリティ評価を徹底します。本番稼働後も、適切な保守・サポート体制を維持することが大切です。

▼全体ガイドの記事
・官公庁のシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。