自治体向けシステム開発の発注方法【入札・随意契約・外注のポイント】

自治体向けシステム開発の発注は、予算の確保から検収まで、法令の定める手続きに沿って進めます。調達方式や仕様、評価基準を先に定め、審査と契約を透明に保つことで、発注の公平性を確保します。

  • 予算と計画:予算要求と調達方式を、早い段階で整理する
  • 仕様と評価:RFP、評価基準、審査体制を明確にする
  • 契約と管理:契約手続き、開発、検収までを管理する

テーマ全体は、次の完全ガイドで詳しく扱っています。

▼全体ガイドの記事をご覧ください:自治体向けシステム開発の完全ガイドをご確認ください。

自治体向けシステム開発発注の基本的な流れ

自治体システム調達を予算確保から開発・検収まで5段階で示す図
計画と文書作成を経て、審査・契約へ進む構成です。

自治体のシステム調達は、予算の確保から始まる一連のプロセスです。続いて調達方式を選び、仕様書を作って公告し、提案を受け付けて審査します。

そのうえで契約を結び、開発と検収へと進みます。どの段階でも、法令で定められた手続きを適切に行うことが求められます。

予算確保・調達計画の策定

自治体のシステム開発は、まず予算を確保することから始まります。年度予算の枠内での調達が原則のため、翌年度に予算計上する場合は、前年度の秋〜冬(9〜12月頃)に予算要求を行います。予算規模の見積もりが不明なときは、事前に複数のベンダーへ情報提供依頼(RFI:Request for Information)を出し、概算費用と技術的な実現可能性を確かめることが有効です。

RFIの回答をもとに現実的な予算規模を把握してから予算要求し、予算が確保できたら調達計画を策定します。調達計画には、調達方式、評価体制(審査委員の構成)、スケジュールを含めます。

調達方式は、一般競争入札、指名競争入札、プロポーザルから選ぶほか、随意契約も選択肢に入ります。スケジュールでは、公告日、提案締切日、審査日を先に押さえ、契約締結日や開発開始日、本番稼働日も計画に入れます。大規模なシステム調達の場合は、調達計画書を議会に提出し、議決を得ることが必要なケースもあります。

RFP(提案依頼書)・仕様書の作成

RFP・仕様書は、調達の核となる文書です。記載があいまいだと、各社の提案がバラバラになって比較しにくくなるため、要件はできる限り具体的に書きます。RFPには、調達の背景・目的・期待効果を書き、業務要件では業務の概要と業務フロー、対象業務の件数を示します。

業務要件には利用者数も含め、機能要件では必要な機能の一覧と優先度を示します。非機能要件では、性能、可用性、セキュリティを定め、拡張性と移行性も書きます。さらに、既存システムとの連携、データ移行、運用・保守の要件も記載します。

納入物一覧やスケジュールに加えて、提案に求める事項(提案書の構成・説明会の有無)、選定基準・評価点の配分、契約条件(支払い条件・再委託の可否)も示します。RFP作成に不慣れな場合は、他自治体の調達事例を参考にしたり、ITコーディネーターや外部専門家の支援を受けたりすると有効です。

ポイント

予算要求は前年度の秋から冬が目安なので、RFPや仕様書の作成まで含めて調達の全体から逆算して準備を始めると、手順の抜けを防ぎやすくなります。

発注先の種類と選び方(入札・随意契約・共同調達)

一般競争入札、随意契約、共同調達の特徴を3枚のパネルで示す図
方式ごとに、選択時に見る観点が異なります。

自治体のシステム調達には、いくつかの調達方式があります。契約金額や業務の緊急性、専門性に応じて、適切な方式を選ぶことが大切です。

一般競争入札・総合評価落札方式

一般競争入札は、公告で広く参加者を募り、価格競争によって最低価格の業者と契約する方式です。透明性と公平性が高く、地方自治法上の原則的な調達方式とされています。

ただし、純粋な価格競争では、技術力や実績が十分でない業者が落札するおそれがあります。そのため、システム開発の調達では「総合評価落札方式」が多く採用されています。この方式では、技術提案点(実績・体制・セキュリティ対応・保守計画など)と価格点を一定の比率(例:技術60点:価格40点)で評価し、総合スコアが高い業者と契約します。

プロポーザル方式は、技術力や提案内容を重視した選定方式で、特に複雑な要件のシステム開発では有効です。さらに、プレゼンテーションや対話形式の審査を取り入れることで、提案内容の理解を深めたうえで選定できます。

随意契約・指名競争入札の活用条件

随意契約は、競争の手続きを経ずに、特定の業者と直接契約する方式です。地方自治法施行令では、随意契約が認められる条件が定められています。主なものは、「契約金額が少額の場合」(都道府県・市区町村ごとに金額基準が異なる)、「特殊な技術・設備が必要で競争に適さない場合」、「緊急に契約が必要な場合」などです。

既存システムの保守・運用契約(現行ベンダーとの継続)も、互換性や継続性の観点から随意契約が認められるケースが多いです。ただし、随意契約は透明性が低くなりやすいため、複数社から見積もりを集める「見積合わせ」を行い、競争原理を確保するのが望ましいです。

なお、指名競争入札は、あらかじめ選定した複数の業者(一般的に3〜10社程度)に参加資格を与えて競争させる方式です。一般競争入札より手続きを簡略化できる利点があります。

共同調達・広域連携の活用

共同調達は、近隣自治体や同規模の自治体が、共同でシステムを調達・利用する方式です。1自治体あたりの負担を大幅に減らせるため、予算規模の小さい町や村にとって特に有効な手段です。

都道府県が主導して、管内の市区町村のシステムを共同調達・共同利用するモデルも増えています。デジタル庁や総務省が進める自治体情報システムの標準化・共通化も、広い意味では共同調達と捉えられます。さらに、標準準拠のクラウドサービスを複数の自治体で共同利用すると、スケールメリットによるコスト削減と品質向上が期待できます。

共同調達を検討する際は、参加自治体間の意思決定プロセス、費用按分方式、責任分担の明確化を押さえておく必要があります。都道府県の担当部署や、地域の自治体情報セキュリティ支援・評価機関(J-LIS等)に相談すると、近隣自治体との共同調達の可能性を探れます。

ポイント

一般競争入札、随意契約、共同調達は、契約金額や業務の緊急性、専門性によって向き不向きが分かれます。まず調達するシステムの規模と要件を整理し、それに合う方式を選ぶのが基本です。

発注時の注意点(仕様書作成・評価基準)

提案評価の実績・信頼性、技術力、プロジェクト体制、保守・サポート体制、価格の妥当性を示す図
評価軸をそろえると、提案の見比べ方が明確になります。

発注時の失敗を防ぐには、仕様書の品質、評価基準の設計、契約条件の確認に注意が必要です。

仕様書の品質と要件の明確化

仕様書の品質が低いと、提案内容がバラバラになって公平な比較ができなくなります。さらに、契約後の追加要件や仕様変更により、費用が増えやすくなります。仕様書を作る際は、まず業務フローを明確にすることが欠かせません。

現行の業務フローを図解し、新システムの業務フロー(To-Be)も可能な範囲で示しておくと、提案会社との認識を合わせやすくなります。次に、非機能要件は詳しく書きます。「セキュリティに配慮すること」と書くだけでなく、「LGWAN接続対応・ISO27001取得・年1回の脆弱性診断の実施」のように、具体的な要件として記載します。

データ移行要件では、移行対象データの種類、件数、旧システムのデータ形式を仕様書に含めることで、移行費用の見積もり精度が上がります。また、どの条件を満たせば検収完了とするかを事前に定めると、検収時のトラブル防止になります。

評価基準の設計と公正な審査体制

提案評価では、価格以外の技術的な要素を適切に評価できる審査体制と評価基準の設計が欠かせません。評価基準の主な項目は5つです。

「実績・信頼性」では、類似業務システムの開発実績、公共案件の実績、企業財務状況を見ます。「技術力」では、提案システムのアーキテクチャやセキュリティ設計、自治体標準化対応の方針を確かめます。「プロジェクト体制」では、担当チームの経験やPMの資格、下請けへの依存度を押さえます。

「保守・サポート体制」では、法改正対応の実績、ヘルプデスク体制、SLAの内容を確認します。「価格の妥当性」では、見積もりの根拠と、追加費用発生リスクへの対応方針を見極めます。また、審査委員会には、情報政策課や業務担当課の職員に加えて、外部のIT専門家(ITコーディネーター等)を入れると、技術的な評価の精度を高められます。

ポイント

仕様書は、業務フローや非機能要件、データ移行、検収基準まで具体的に書くほど、提案を比べやすくなります。評価基準は、価格以外の技術要素を評価できる審査体制と合わせて設計します。

発注を成功させるポイント

発注を成功させるには、要件を細かく詰めるだけでなく、社内の体制を整え、開発会社と良好にやり取りすることが欠かせません。

調達前の情報収集と早期相談の重要性

調達を成功させるうえで最も欠かせないのは、十分な準備期間を確保することです。公告から契約締結まで最低2〜3ヶ月かかるため、開発着手の半年以上前から準備を始めるのが理想的です。

準備段階では、RFI(情報提供依頼)を使って複数のベンダーから技術情報と概算費用を集め、市場の動向と適正なコストを把握します。また、他自治体の調達事例を参照するのも有効です。総務省やデジタル庁のウェブサイト、自治体情報セキュリティ支援・評価機関(J-LIS)が提供する情報を使い、標準的な調達プロセスと評価基準を把握しておくことをお勧めします。

RFP策定や評価基準の設計に不慣れな場合は、ITコーディネーターや、自治体向けシステム開発の実績がある会社に事前に相談すると、調達の精度を高められます。

契約書・SLAの重要ポイント

契約を結ぶ際は、開発契約と保守契約の内容を詳しく確かめます。開発契約では、納入物の一覧、検収基準、著作権を明確にし、ソースコードの帰属、再委託の可否、損害賠償規定も定めておきます。

特に著作権は、開発したシステムのソースコードが自治体に帰属するか、開発会社に留保されるかを、事前に確認・交渉しておきます。

保守契約では、SLA(サービスレベル合意)として、障害発生時の対応時間(例:重大障害は2時間以内に初動対応)、定期メンテナンスの頻度、法改正対応の対象範囲と費用負担を明確に定めます。さらに、保守期間(一般的に5〜10年)とその後の移行支援の義務化も盛り込むと、いわゆるベンダーロックイン(特定ベンダーへの過度な依存)のリスクを軽減できます。

ポイント

準備は、公告から契約締結まで最低2〜3ヶ月かかることを踏まえ、開発着手の半年以上前から始めるのが目安です。契約では、著作権とSLAを事前に確認しておくと、後のトラブルを減らせます。

まとめ

自治体向けシステム開発の発注は、地方自治法に基づく公共調達のルールに沿って、透明性と公平性を保ちながら進める必要があります。

一般競争入札、随意契約、共同調達は、それぞれ特性が異なるため、システムの規模や要件に合う方式を選ぶことが求められます。

発注を成功させるには、十分な準備期間を確保することと、質の高いRFPと仕様書を作ることが欠かせません。そのうえで、技術評価を重視した評価基準を設計し、明確な契約とSLAを結ぶことが、ポイントになります。

発注の進め方に迷ったときは、実績のある専門家や開発会社に早めに相談することで、調達の質を高められます。

▼全体ガイドの記事をご覧ください:自治体向けシステム開発の完全ガイドをご確認ください。

会社紹介

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

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

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

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

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

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