自治体・公共機関のシステム開発外注｜官公庁案件特有の要件と選定基準

自治体や公共機関のシステム開発を外注する場面では、民間企業の開発発注とはまったく異なるルールと制約に直面します。会計法や地方自治法施行令が定める調達手続き、公平性・透明性の担保、単年度予算の制約、そして2024年改正地方自治法により2026年4月1日から義務化された『サイバーセキュリティ基本方針』への対応まで、押さえるべき論点は多岐にわたります。

なかでも担当者を最も悩ませるのは、「公平性・透明性という制約のなかで、必要な品質をどう確保するか」という設計判断です。安く発注すれば議会や監査には説明しやすいものの、要件を満たさないベンダーが落札してしまえばプロジェクト全体が破綻します。逆に品質重視で総合評価やプロポーザルを選んでも、評価基準の設計が甘ければ「なぜこの事業者が選ばれたのか」を説明できず、透明性を疑われかねません。

とくに前任者からの引き継ぎで初めて大規模な調達を担当することになった担当者にとっては、参考にできる庁内先例が限られ、他自治体の事例と自庁の状況の差異も判断しづらい状況が続きます。「これで品質の高いベンダーから提案が来るのか」「そもそも一般競争入札で発注してよいのか」といった根本的な問いに答えるための判断軸がないまま、仕様書ドラフトの作成に着手してしまうケースも珍しくありません。

本記事では、自治体・公共機関のシステム開発外注を「調達設計」という切り口で整理します。民間との構造的な違いから始まり、契約方式の選び方、RFP作成の実務、ベンダー評価基準の設計、契約後のトラブル防止までを、発注者が「今どこで何を判断すべきか」を明確にできる形で解説します。単なる用語解説や事業者ランキングではなく、自庁の案件に応用できる判断フレームワークとしてお読みください。

自治体・公共機関のシステム開発外注が民間と根本的に違う理由

自治体・公共機関のシステム開発外注が難しいのは、担当者のスキル不足が原因ではありません。民間企業の発注とは根本的に異なる4つの制約――法令が定める調達ルール、公平性・透明性の絶対的要請、単年度予算と議会承認、そしてセキュリティ制度枠組み――が同時に働くためです。この4つを構造的に理解しないまま「なんとなく前例に従う」形で調達を進めると、後段のRFP設計やベンダー評価で判断根拠を説明できなくなります。

会計法・地方自治法施行令が定める調達ルールの制約

民間企業であれば、社内稟議さえ通れば取引先を自由に選べます。しかし公共機関では、会計法（国の機関）または地方自治法・地方自治法施行令（地方公共団体）が調達手続きを規定しており、原則として一般競争入札が求められます。総合評価落札方式やプロポーザル方式、随意契約は「一般競争入札を原則としつつ、要件を満たす場合の例外」として位置づけられている点が重要です。

したがって「なぜこの契約方式を選んだか」を庁内・議会・監査に説明する責任が、常に発注担当者に発生します。「品質重視だからプロポーザルにした」という感覚的な理由では通らず、地方自治法施行令第167条の2各号（随意契約の要件）や、総合評価落札方式・プロポーザル方式の運用要領との対応関係を示す必要があります。この説明責任を意識するかどうかが、調達設計の質を大きく分けます。

一次情報として、総務省の情報システムに係る政府調達の基本指針 実務手引書は、各契約方式の位置づけと選択基準を体系的に整理しており、自治体・公共機関の発注者にとって基本文献となります。

公平性・透明性の担保が絶対条件である理由（随意契約の原則禁止）

公共調達では「公金を使う以上、事業者選定のプロセスが誰から見ても公平で、選定理由が透明でなければならない」という原則が働きます。これは倫理的な建前ではなく、住民監査請求・情報公開請求・議会質疑という具体的な仕組みで担保されている実務上の制約です。

そのため、随意契約は原則禁止され、実施する場合は地方自治法施行令第167条の2に列挙された要件のいずれかに該当する必要があります。また、総合評価やプロポーザルでも「評価委員の主観で決まった」と受け取られないよう、評価項目・配点・採点基準を事前に公表することが求められます。

この制約は、民間発注のように「過去に取引実績があるから」「担当者同士の相性が良いから」といった理由でベンダーを選ぶことを認めません。逆に言えば、実績のある信頼できる事業者に発注したい場合でも、その事業者が客観的な評価で選ばれる形の設計を組み立てる必要があります。この設計の難しさこそが、公共調達の実務でつまずきやすい最大のポイントです。

単年度予算・議会承認プロセスとスケジュール制約

公共機関の予算は原則として単年度で編成されます。年度をまたぐシステム開発では「債務負担行為」または「継続費」として議会の承認を事前に得る必要があり、承認スケジュールが調達全体のマスタースケジュールを規定します。

さらに、予算要求は前年度の夏〜秋にかけて査定が進むため、実質的には「調達仕様書を書き始める前に予算額の根拠を固める必要がある」という順序の逆転が起こります。民間のように「要件が固まってから見積もりを取り、予算化する」という流れではなく、RFI（情報提供依頼）などで得た概算を根拠に予算要求し、その後で詳細仕様を詰めていく形になります。

この構造を理解していないと、「予算超過で議会説明が必要になった」「単年度で終わらせるために要件を無理に削った」といった問題が発生します。予算・スケジュール・要件の三者を並行して調整する意識が必要です。

セキュリティ制度枠組みが調達に与える影響

2024年改正の地方自治法（2026年4月1日施行）により、地方公共団体には『サイバーセキュリティ基本方針』の策定・公表が義務づけられました。基本方針は「自治体としてサイバーセキュリティ確保に向けてどのような考え方で取り組むか」を宣言する上位文書で、施行日までにほぼすべての自治体が策定を終えています。

一方、実務レベルの遵守事項を定める『情報セキュリティポリシー』は、総務省の地方公共団体における情報セキュリティポリシーに関するガイドライン（2026年3月改定）に基づき、従来から各自治体が任意で策定・改定してきた別文書です。基本方針が「何を守るか」の宣言、情報セキュリティポリシーが「どう守るか」の実務ルールと整理すると分かりやすいでしょう。両者は法令上の位置づけが異なる別文書である点を、まず押さえておく必要があります。

したがって、現在の調達現場で問われているのは「これから策定する」ではなく、「策定・公表済みのサイバーセキュリティ基本方針と、それを具体化した情報セキュリティポリシーが、実際の調達仕様書・契約書・評価基準にどこまで反映されているか」の点検です。両者は策定して公表しただけでは効果を発揮せず、個別の調達案件で以下のような形で具体化されて初めて機能します。

• 参加資格の必須条件として、事業者側のセキュリティ体制（ISMS認証・プライバシーマーク等）を求めるか
• クラウドサービスを利用する場合、ISMAP（政府情報システムのためのセキュリティ評価制度）登録サービスに限定するか
• 契約書に、委託先管理・監査受入・情報漏えい時の報告義務・再委託先の管理をどこまで盛り込むか

これらを個別に検討するには、まず自庁の情報セキュリティポリシーが何を要求しているかを再確認し、案件で扱う情報の機密性区分を明確化する必要があります。制度の具体的な評価軸への落とし込みは、のちほど「事業者選定で見るべき評価基準と加点項目」で、契約後の運用対応は「契約後のトラブルを防ぐ実務ポイント」で詳しく扱います。ここでは「サイバーセキュリティ基本方針の策定・公表は既に施行済みの義務であり、これから問われるのは調達要件への具体的な反映である」という前提を押さえておいてください。

官公庁システム調達で使われる契約方式と使い分けの判断軸

契約方式の選択は、調達設計における最初の大きな分岐点です。一般競争入札・総合評価落札方式・プロポーザル方式・随意契約（例外）の4種類を、単に並列に紹介するのではなく、「案件の性質から契約方式を逆算する」判断軸で整理します。

一般競争入札(最低価格落札方式)が向く案件

一般競争入札の最低価格落札方式は、価格のみで落札者を決定する方式です。公平性・透明性の観点からは最もクリアで、説明責任も果たしやすいという長所があります。

この方式が適するのは、要件が明確で、事業者による品質差が生じにくい案件です。具体的には、既製パッケージ製品のライセンス調達、明確な仕様書に基づく機器調達、定型的な保守業務の継続契約などが該当します。

一方、要件が抽象的にしか書けないシステム開発（業務改革を伴う基幹システム更改、AI・データ分析基盤の構築など）では、この方式は不向きです。事業者はコストダウンを最大化するため最低限の要件だけを満たそうとし、結果として品質不足に陥る典型的な失敗パターンが発生します。「安かろう悪かろう」を避けるためには、次項以降の方式を検討することになります。

総合評価落札方式が向く案件

総合評価落札方式は、価格点と技術点を合算した総合評価値で落札者を決定する方式です。価格と品質のバランスを取りたい案件、あるいは技術的な差別化はあるものの提案の自由度はそれほど大きくない案件に向いています。

具体的には、既存パッケージのカスタマイズ、要件がある程度固まっているが実装アプローチに幅がある案件、既存システムの機能拡張などが該当します。評価項目・配点・採点基準を事前に公表することで透明性を確保しつつ、「価格だけで決まらない」設計が可能になります。

配点設計では、価格点と技術点のウエイトをどう置くかが実務上の判断ポイントです。技術点のウエイトを高くしすぎると価格競争のインセンティブが弱まり、逆に低すぎると事実上の最低価格落札と変わらなくなります。案件の複雑度に応じて設計する必要があり、詳細はのちほど「事業者選定で見るべき評価基準と加点項目」で扱います。

プロポーザル方式（企画競争）が向く案件

プロポーザル方式は、事業者の企画提案の内容そのものを評価して契約相手を選ぶ方式です。総合評価落札方式と混同されがちですが、性質は大きく異なります。プロポーザル方式では価格は主評価軸ではなく、「どんな体制で、どのようなアプローチで、どんな成果を出すか」の企画提案が主評価対象になります。

この方式が向くのは、要件を発注者側だけで完全に定義できない案件です。業務改革を伴う基幹システム再構築、DX推進の中核となる新規サービス設計、庁内のワークスタイル変革を含むシステム更改などが該当します。事業者側のノウハウ・実績・提案力に頼らざるを得ない領域では、事業者に「あるべき姿」の提案を求めることが最も合理的です。

ただしプロポーザル方式は「公平性・透明性の担保が最も難しい方式」でもあります。評価委員の主観が入り込みやすく、選定理由の説明も複雑になりがちです。評価委員会の構成、評価項目の設計、採点集計方法まで、事前の枠組み作りが特に重要になります。

随意契約・指名競争入札の例外的活用

随意契約は「地方自治法施行令第167条の2各号のいずれかに該当する場合」に限って認められる例外的な方式です。少額随契（一定金額以下）、緊急随契（時間的余裕がない場合）、特命随契（性質または目的が競争入札に適さない場合）などの類型があります。

システム開発の文脈で該当しやすいのは「既存システムの機能拡張・保守で、他事業者が対応不可能な場合」のような特命随契ですが、この場合でも「なぜ他事業者では対応不可能か」を客観的に説明できる資料の準備が必要です。競争性の排除に該当するため、監査で厳しく問われるポイントであり、安易に採用すべき方式ではありません。

指名競争入札は、参加事業者を発注者側で指名する方式で、地方自治法施行令第167条各号に該当する場合に採用可能です。特殊な技術・地域性が要件になる案件で使われることがありますが、これも例外的な位置づけである点は変わりません。

契約方式選択のフローチャート

以上を踏まえ、案件の性質から契約方式を逆算する判断フローを整理します。

1. 要件が仕様書レベルで完全に定義できるか
   • Yes → 一般競争入札（最低価格落札）を第一候補にする
   • No → 次の質問へ
2. 事業者側の提案自由度は限定的か（実装アプローチには幅があるが、成果物の輪郭は決まっているか）
   • Yes → 総合評価落札方式を検討する
   • No → 次の質問へ
3. 事業者に「あるべき姿」自体の提案を求めるか（業務改革・新規サービス設計を含むか）
   • Yes → プロポーザル方式を検討する
   • No → 要件の再整理に戻る（ここでプロポーザルを選ぶと評価がぶれる）
4. 上記いずれにも該当せず、地方自治法施行令の要件を満たす特殊事情があるか
   • Yes → 随意契約・指名競争入札の可能性を検討する（監査対応の準備が必要）

このフローに従えば、「なぜこの契約方式を選んだか」の説明を、案件の性質に基づく客観的な論理として組み立てられます。感覚的な選択ではなく、逆算による選択がポイントです。

システム開発外注の全体プロセスとフェーズ移行のゲート判断基準

システム開発の調達は、大まかに6つのフェーズで進みます。ただし、単に順序を並べただけの標準プロセス解説では実務判断の助けになりません。ここでは各フェーズで「何を確認できれば次のフェーズに進んでよいか」というゲート判断基準を明示することで、自庁の進捗が「今どこで詰まっているか」を自己診断できるようにします。

現状把握とニーズの特定

最初のフェーズでは、現行システムの課題を洗い出し、次期システムに求める要件の骨格を固めます。ここでの成果物は「現行システムの何が問題で、何を実現したいのか」を庁内で共有できるドキュメントです。

このフェーズで陥りがちなのは、利用部門のヒアリング結果をそのまま要件化してしまうことです。ヒアリングでは「機能不足の不満」「保守終了への不安」「制度変更への対応要請」「他自治体との比較で見えた劣後」など、性質の異なる課題が混在して出てきます。これらを整理せずに要件化すると、優先度が付かず、後段のRFPが肥大化します。

ゲート判断基準:

• 現行システムの課題が「機能不足」「保守終了」「制度変更対応」「業務プロセス変革」のいずれに該当するか、案件全体として特定できているか
• 利用部門ヒアリングの結果が、要件優先度（Must / Want）と紐付いた形で整理されているか
• 対象業務のスコープ（どの業務システムまでを更改対象とするか）が明確化されているか

これらを満たしていない状態で市場調査フェーズに進むと、事業者への情報提供依頼の質問設計自体がぶれてしまい、フェーズ全体がやり直しになります。

市場調査とRFI（情報提供依頼）の実施

現状把握が固まったら、次は市場調査です。ここではRFI（情報提供依頼）を発出し、想定ソリューションの実現可能性・概算価格・実装形態（パッケージ／スクラッチ／SaaS）を確認します。

RFIは調達の一部ではなく「情報収集」の位置づけなので、事業者側も参加ハードルは低く、幅広い情報が得られます。ただし、RFI回答をそのまま特定事業者への有利誘導につなげてはならず、得られた情報は仕様書に匿名化して反映する運用が求められます。

ゲート判断基準:

• 想定ソリューションを提供できる事業者が複数（原則3社以上）存在することを確認できたか
• パッケージ／スクラッチ／SaaSの選択肢を、市場実態と自庁のセキュリティポリシー・運用体制と照合して比較できたか
• 概算価格レンジが得られ、次フェーズの予算算定に使える形になっているか

3社以上の候補が確保できない場合は、要件の見直し、あるいはプロポーザル方式・随意契約の適否を再検討する必要があります。

予算算定と議会承認プロセスの設計

市場調査で得られた価格レンジを根拠に、予算要求を組み立てます。前述のとおり公共機関では単年度予算が原則のため、複数年度にまたがる開発では債務負担行為または継続費の設定が必要になります。

このフェーズでは、予算要求資料に「なぜこの金額か」を説明する根拠を添える必要があります。RFIの回答レンジ、他自治体の類似案件の予算実績、パッケージ製品の公表価格などが典拠になります。「見積もりを取って積算した」という民間流の説明は通用しません。

ゲート判断基準:

• RFIで得た市場価格レンジと予算要求額の乖離が、合理的に説明可能な範囲にあるか
• 単年度予算では収まらない場合の債務負担行為・継続費の設計方針が固まっているか
• 保守・運用費用（イニシャルコスト以外のランニング費）を含めた総所有コスト（TCO）で議論できているか

TCOの視点が抜けると、開発費だけを見て「安い提案が来た」と判断してしまい、5年後のトータルで大幅な予算超過を招く典型的な失敗パターンに陥ります。

RFP作成・調達仕様書の準備

予算が確保できたら、いよいよRFP（提案依頼書）・調達仕様書の作成に入ります。ここが調達品質を決定づける最重要フェーズです。

RFPの品質については、のちほど「品質の高い提案を引き出すRFP作成の実務」で詳しく扱いますが、ゲート判断基準としては以下を押さえておきます。

ゲート判断基準:

• 要件が「必須要件（Must）」「加点要件（Want）」に分類され、加点配点との対応関係が説明可能か
• 過剰要件（不必要に厳しい制約）・曖昧表現（複数解釈が可能な記述）の点検が済んでいるか
• 現行業者への有利誘導になっていないか（特定製品名指定、既存環境依存の要件等）が確認できているか
• 提案期間・質疑応答期間が事業者にとって現実的な長さ（最低4〜6週間程度）で設定されているか

これらの点検が不十分なままRFPを公告すると、提案の質にばらつきが出るか、そもそも参加事業者数が想定を下回るリスクがあります。

入札公告・事業者選定・契約締結

RFPを公告した後は、質疑応答・提案書受領・評価委員会での審査・落札者決定・契約締結という流れになります。このフェーズで発注者が果たすべき役割は、「事前に定めた評価枠組みに従って粛々と運用する」ことです。

質疑応答は透明性の観点で重要な位置を占めます。特定事業者からの質問への回答は、他の全参加事業者にも公開する運用が原則です。回答内容が仕様書の解釈を変える場合は、正式に仕様書の改訂として公告し直す必要があります。

ゲート判断基準:

• 質疑応答で追加された論点が、仕様書・評価基準に正しく反映されているか
• 評価委員会の評点集計に、個人裁量が入り込む余地を排除できているか(採点根拠のドキュメント化、複数評価者の合議など)
• 落札者決定の理由書（総合評価・プロポーザルの場合）が、監査・情報公開請求に耐える形で整備できているか

評価委員の主観が入り込んだ選定は、後日の情報公開請求・議会質疑で問題化するリスクが高くなります。

契約後のプロジェクト管理・受入検査・運用移行

契約締結で調達フェーズは終わりではありません。契約後のプロジェクト管理、受入検査、運用移行までを見据えた設計が求められます。契約後のトラブル防止については、のちほど「契約後のトラブルを防ぐ実務ポイント」で詳しく扱いますが、ゲート判断基準としては以下を押さえます。

ゲート判断基準:

• 受入検査の合格基準が、RFP・契約書の記述と一致しているか（後出しの追加検査項目になっていないか）
• 運用移行後のトラブル切り分け責任（発注者側／受注者側／第三者製品側）が、契約書または別途覚書で明確化されているか
• 保守フェーズの体制・SLA・費用が、開発契約と一体で議論できているか

これらの整理を先送りすると、運用開始後に「これは誰の責任か」を巡って不毛な調整が続くことになります。

品質の高い提案を引き出すRFP作成の実務

RFP（提案依頼書）は、事業者に「どんな提案をしてほしいか」を伝える中心的なドキュメントです。RFPの品質が、提案の質・価格の妥当性・後段のトラブル防止のすべてに直結します。

RFPに記載すべき5つの必須項目

RFPで最低限記載すべき項目を、目的別に整理します。

1. 調達の背景と目的: なぜ今このシステムを調達するのか、業務上の課題と達成したい成果を明示する。事業者はこの記述から「発注者が何を重視しているか」を読み取り、提案の方向性を組み立てます。
2. 要件（機能要件・非機能要件）: 必須要件（Must）と加点要件（Want）を分離して記述する。非機能要件（性能・可用性・セキュリティ・運用性）は機能要件と同等以上に重要な検討対象です。
3. 前提条件・制約条件: 既存システムとの連携、利用可能なインフラ、法令・ガイドラインへの準拠要件、対象データの機密性区分などを明示する。
4. プロジェクト体制・スケジュール: 発注者側の体制、期待するプロジェクト運営方法、成果物の納期、検収の想定時期などを示す。
5. 提案書に含めるべき事項: 事業者に提案書で回答してほしい項目のリストと、様式の指定（あれば）。評価項目との対応関係も併記すると、事業者は評価軸を意識した提案を作りやすくなります。

これらの項目のうち、多くの発注者がおろそかにしがちなのは非機能要件と提案書構成の指定です。この2つが曖昧だと、事業者ごとに提案内容の粒度が大きくばらつき、評価委員会で比較評価そのものが困難になります。

日立システムズが公開している失敗しないRFP（提案依頼書）の書き方や、NTTデータ経営研究所の大規模システム調達成功に向けて RFPで意識すべきポイントは、RFP品質を高めるための実務的な観点が整理されており、参考文献としても有用です。

失敗しやすいRFP記載パターン

RFPで頻出する失敗パターンを、実務目線で整理します。

過剰要件: 「あったらいいな」レベルの要件をすべて必須要件に組み入れてしまうと、提案価格が跳ね上がり、要件不適合を理由に応札事業者数が絞られます。「なくてもプロジェクトの成否に影響しない」要件は加点要件に落とすのが原則です。

曖昧表現: 「使いやすいUIとすること」「十分な性能を確保すること」といった記述は、複数の解釈を許してしまい、事業者ごとに提案粒度がばらつく原因になります。定量的な基準（応答時間、同時接続数、UI設計ガイドラインの参照など）に置き換えるのが望ましいです。

仕様書との重複・矛盾: RFPと仕様書（詳細仕様書・技術仕様書）を分けて管理している場合、両者の記述が重複したり矛盾したりすると、事業者は「どちらを正とすべきか」判断できません。役割分担を明確に決めた上で、優先順位も明示するのが安全です。

現行環境依存の記述: 「現行システムAと連携すること」というだけの記述だと、現行システムの仕様を熟知した既存業者に有利になります。連携インターフェースの技術仕様を可能な限り公開する、あるいは事業者が現行環境調査を実施できる期間を提案期間に含めるなどの工夫が必要です。

現行業者への有利誘導を避ける工夫

公共調達で特にセンシティブなのが、既存の業務委託業者・システム構築業者への有利誘導を避けることです。悪意なく発注者側の慣れで書いた記述が、結果として現行業者に有利になっているケースは少なくありません。

避けるべき記述の例:

• 特定製品名を必須要件として指定する（同等品を認めない）
• 既存業務プロセスの詳細知識を前提とする要件記述
• 現行システムの内部仕様に依存する連携要件
• 提案期間を短く設定し、現行業者以外に情報収集の時間を与えない設計

これらを避けるための実務的な工夫として、以下が有効です。

• 製品指定が必要な場合は「同等以上の機能を有する製品」と明記する
• 業務プロセスの前提知識が必要な部分は、RFP添付資料として業務フロー・データフローを開示する
• 現地調査・環境調査の機会を、参加希望事業者全員に等しく提供する
• 提案期間は最低4〜6週間、大型案件では8週間以上を確保する

提案期間・質疑応答期間の適切な設定

提案期間の設計は、事業者側の準備品質を大きく左右します。短すぎる期間設定は「事実上、現行業者以外は応札できない」という有利誘導と同じ効果を持ちます。

目安としては、以下のレンジを参考にできます。

• 中小規模の業務システム更改: 提案期間4〜6週間、質疑応答期間はその中盤に配置
• 大規模基幹システム更改: 提案期間8週間以上、質疑応答は2回程度を想定
• 業務改革を伴うプロポーザル案件: 提案期間8〜12週間、必要に応じて中間ヒアリングを設定

質疑応答期間の運用では、質問の締切日から回答の公表日までのタイムラグを明示し、事業者が回答を踏まえて提案を修正できる時間を確保することも重要です。

事業者選定で見るべき評価基準と加点項目

事業者選定の評価基準は、総合評価落札方式・プロポーザル方式の実施要領で定義します。「実績のないベンダーを排除しつつ競争性を確保する」という一見矛盾する要請に応えるには、参加資格と評価配点の設計を分離して考えることが有効です。

参加資格の設計

参加資格は「これを満たさなければ応札できない」というふるい分け条件です。ここで一定のレベルを担保することで、応札事業者全体の品質を底上げできます。

一般的な参加資格の設計要素:

• 入札参加資格等級: 自治体・国が定める競争入札参加資格の等級区分（A・B・Cなど）を指定する
• 同種業務実績: 過去N年以内に、同種業務（例: 同規模自治体の基幹システム構築）を受注・完了した実績があること
• 有資格者の配置: プロジェクトマネージャに情報処理技術者試験の高度区分、または同等資格を保有する者を配置できること
• 企業体制: ISMS認証、プライバシーマーク、CMMIレベル等の企業体制認証

ただし、参加資格を厳しくしすぎると応札事業者数が極端に減り、競争性の確保という原則に反することになります。実績要件は「原則3〜5社が満たせる程度」を目安に設計するのが実務的です。

提案内容の評価軸

参加資格を通過した事業者からの提案は、以下の観点で評価します。

• 実施方針: 発注者の目的・課題への理解、プロジェクト全体のアプローチ、期待成果の実現可能性
• 体制: プロジェクトマネージャの実績、主要メンバーの経験、要員配置の妥当性、稼働率・稼働時間の計画
• 技術力: 技術的アプローチの妥当性、リスクへの対応方針、品質保証・テスト計画
• 業務理解: 発注者の業務プロセスへの理解度、業務要件の分析深度、業務改善提案の質

各観点をさらに小項目に分解し、5段階または10段階での採点基準を事前に定めます。「なぜこの点数を付けたか」を採点シート上で説明できる形にしておくことが、監査対応と情報公開請求対応の両面で重要です。

セキュリティ対応を評価軸に落とし込む

先述したセキュリティ制度枠組み（サイバーセキュリティ基本方針・情報セキュリティポリシー・ISMAP）を、参加資格および評価配点にどう反映するかを整理します。

参加資格としての反映:

• ISMAP登録クラウドサービスの活用が必要な案件区分の判断: 案件で扱う情報が機密性2以上（政府統一基準における情報区分）に該当する場合、クラウドサービス利用はISMAP登録サービスに限定する運用が推奨されます。自庁の情報セキュリティポリシーで機密性区分と対応するクラウド利用基準が定められているはずなので、それと照合して要件化します。
• 情報セキュリティポリシー適合性の確認: 応札事業者に、自庁の情報セキュリティポリシーへの適合を宣誓する誓約書の提出を求める運用が一般的です。

加点項目としての反映:

• ISMS認証（ISO/IEC 27001）の取得: 5〜10点程度の加点
• プライバシーマークの取得: 2〜5点程度の加点
• セキュリティ関連の資格保有者（情報処理安全確保支援士等）の配置: 案件によって加点配点を設計
• 過去N年以内の重大セキュリティインシデントの有無: 減点基準として設計する場合もある

配点の絶対値は案件の重要度によって調整しますが、セキュリティ加点の合計が全技術点の10〜20%程度になるような設計が目安になります。

地域貢献・その他加点項目の扱い

自治体の調達では、地域貢献（地元事業者活用・地元雇用等）を加点項目に含めることがあります。ただし、地域貢献の加点比率が高すぎると、技術力による競争が働かなくなり、品質確保という本来の目的を損なう恐れがあります。

地域貢献の加点は、あくまで「技術評価で拮抗した場合の判定要素」の位置づけとして、全評価点の5%以下に抑えるのが実務的なバランスです。過去に地域貢献加点の比率が高すぎたために選定結果が変わった事例が報道された自治体もあり、住民監査請求のリスクを含めた設計が必要です。

価格点と技術点の配点バランス設計

総合評価落札方式では、価格点と技術点の配点バランスが最重要の設計判断となります。一般的なパターンとして以下があります。

• 価格重視型（価格点70%: 技術点30%）: 定型的な機器調達、パッケージ導入で要件が固まっている案件
• バランス型（価格点50%: 技術点50%）: 標準的なシステム構築・カスタマイズ案件
• 技術重視型（価格点30%: 技術点70%）: 業務改革を伴う基幹システム更改、DX推進案件

プロポーザル方式では価格は主評価軸から外れますが、価格点として一定の配点を残し、「明らかに割高な提案は選ばれにくくする」設計が現実的です。

配点比率を決めた後は、その根拠を庁内・議会に説明できるようドキュメント化しておく必要があります。「なぜこの案件では技術点を70%にしたか」を、案件の性質・リスク・過去の類似案件の実績を交えて説明できる形が理想です。

契約後のトラブルを防ぐ実務ポイント

契約締結は調達の終着点ではなく、プロジェクト管理の出発点です。契約書の設計と、契約後の運用体制の設計が、後段のトラブル発生率を大きく左右します。

契約書に盛り込むべき条項

システム開発の契約書で、公共機関発注者として押さえるべき条項を整理します。

変更管理条項: プロジェクト進行中の要件変更・仕様変更に、どのような手続きで対応するかを規定します。変更要求の起票・影響評価・費用/期間への影響見積り・双方合意・変更契約締結という一連のプロセスを明文化しておくと、後段の「言った/言わない」問題を大幅に減らせます。

遅延損害金条項: 納期遅延時の損害金の算定方法を規定します。公共機関の標準契約書には通常盛り込まれていますが、対象期間・上限金額・免責条件の設定は案件ごとに検討する必要があります。

契約不適合責任条項: 民法改正で「瑕疵担保責任」から「契約不適合責任」に変更された後の運用に沿った条項を採用します。追完請求・代金減額請求・損害賠償請求・契約解除の各権利と、通知期間・除斥期間を明示することが重要です。

知的財産権条項: 開発成果物の著作権の帰属、既存ソフトウェア・OSSの利用条件、事業者側の既存ノウハウの取り扱いなどを規定します。特にオープンソースソフトウェアを利用する案件では、ライセンス条件と発注者側の利用範囲を明確化しておく必要があります。

個人情報保護条項: 個人情報保護法・個人情報保護条例・情報セキュリティポリシーへの適合、事故発生時の報告義務、監督責任などを規定します。

進捗管理・受入検査の実務

契約後は、プロジェクト管理と受入検査の実務が発注者側の主要な役割になります。

進捗管理: 定例会議の頻度（週次〜隔週）、報告様式、リスク管理台帳の運用、変更管理の運用などを、契約締結後の早い段階で発注者・受注者間で合意します。工程マイルストーン（要件定義完了、基本設計完了、詳細設計完了、単体テスト完了、結合テスト完了、総合テスト完了）ごとに、成果物確認と次工程移行の承認プロセスを設計します。

受入検査: 総合テスト完了後、発注者側が実施する受入検査は「契約書・RFP・仕様書で合意した要件が満たされているか」を検証する重要な工程です。受入検査の合格基準は、契約書または別途覚書で事前に明示しておかないと、検査段階で「これは合格か不合格か」を巡って紛糾するリスクがあります。

受入検査における発注者側の準備:

• テストシナリオ・テストデータの準備（本番相当の業務パターンを網羅）
• 検査実施者の割り当て（利用部門の実務担当者を含む）
• 不合格判定時の対応プロセス（是正要求・追加検査・契約解除の判断基準）

業務委託先管理・情報セキュリティ監査条項の実務対応

情報セキュリティポリシーで求められる業務委託先管理は、契約書上の条項として具体化する必要があります。冒頭の「セキュリティ制度枠組みが調達に与える影響」で整理したサイバーセキュリティ基本方針と情報セキュリティポリシーは、ここで契約実務に落とし込まれます。

委託先管理条項:

• 事業者が本業務のために講じるべきセキュリティ対策の水準（自庁の情報セキュリティポリシーへの適合、ISMS認証の維持等）
• 事業者側の作業場所、作業要員の管理、入退室管理、機器・記録媒体の管理に関する遵守事項
• 事業者が定期的に発注者に報告する事項（セキュリティ体制、事故発生状況等）

監査・報告義務:

• 発注者による監査（現地監査・書面監査）の実施権と、監査への協力義務
• 事業者側の定期報告（月次・四半期等）の内容と様式
• インシデント発生時の即時報告義務（発生後24時間以内等の時間規定を含む）

再委託先の管理:

• 再委託の可否と、再委託を認める場合の事前承認プロセス
• 再委託先にも同等の遵守事項を課すことの明示
• 再委託先の一覧の提出義務

これらの条項は、自庁の情報セキュリティポリシーで求められる委託先管理の水準を、個別契約に落とし込む形で設計します。ポリシーが「委託先に対して〇〇の管理を求める」と定めているのに、個別契約書にその条項がなければ、ポリシーは形骸化してしまいます。

運用移行・保守フェーズの体制設計

システム稼働後の運用移行・保守フェーズは、開発フェーズとは異なる体制設計が必要になります。

運用移行期: 開発事業者・保守事業者・発注者・利用部門の間で、トラブル発生時の切り分け責任を明確化します。特に「これは開発の瑕疵か、運用の問題か、利用者側の操作誤りか」の判定プロセスを事前に設計しておかないと、稼働直後のトラブル対応で不毛な調整が発生します。

保守契約: 開発契約とは別に、保守契約を締結するのが一般的です。保守契約では、SLA（サービスレベルアグリーメント）、稼働時間、障害対応の優先度区分、月次報告の内容、変更管理・改善提案のプロセスなどを規定します。

次期更改の見据え: 稼働開始と同時に、次期システム更改（通常5〜10年後）を見据えた運用ドキュメントの蓄積を始めることも重要です。運用実績データ、障害履歴、改修履歴、業務要件の変化などを蓄積しておくと、次期調達のRFP作成時に発注者側の主体性を確保しやすくなります。

公平性と品質を両立する調達設計のチェックリスト

ここまでの内容を、実務チェックリストの形で総括します。契約方式選択・RFP設計・ベンダー評価・契約後管理の各観点で、「これを押さえておけば大きな失敗は避けられる」というポイントを整理します。

契約方式選択のチェックポイント:

• 要件が仕様書レベルで完全定義可能かを確認したか（Yesなら一般競争入札を第一候補）
• 事業者提案の自由度から契約方式を逆算できているか（総合評価落札方式／プロポーザル方式の選び分け）
• 選択した契約方式の根拠を、地方自治法施行令の該当条文または運用要領との対応で説明できるか
• 随意契約を検討する場合、地方自治法施行令第167条の2各号の該当性を客観的に説明できるか

RFP設計のチェックポイント:

• 要件を必須要件（Must）と加点要件（Want）に分類し、加点配点との対応関係が説明可能か
• 非機能要件を定量的な基準で記述できているか（応答時間・可用性・同時接続数等）
• 現行業者への有利誘導になる記述（特定製品名指定・現行環境前提の要件等）を点検したか
• 提案期間が事業者にとって現実的な長さで確保されているか（中小規模で4〜6週間以上）
• RFPと仕様書の役割分担・優先順位が明示されているか

ベンダー評価のチェックポイント:

• 参加資格が「原則3〜5社が満たせる程度」の水準に設計されているか
• 評価項目・配点・採点基準が事前に公表され、事業者が評価軸を意識した提案を作れる状態か
• セキュリティ関連の評価軸（ISMAP登録要件・ISMS認証等）が自庁のサイバーセキュリティ基本方針・情報セキュリティポリシーと整合しているか
• 地域貢献加点が全評価点の5%以下に収まっているか
• 価格点と技術点の配点比率の根拠を庁内・議会に説明できるか

契約後管理のチェックポイント:

• 契約書に変更管理・遅延損害金・契約不適合責任・知的財産権・個人情報保護の各条項が盛り込まれているか
• 受入検査の合格基準が契約書または別途覚書で事前に明示されているか
• 業務委託先管理条項が、自庁の情報セキュリティポリシーで求める水準を反映しているか
• 監査・報告義務・再委託先管理の条項が具体的なプロセスとして規定されているか
• 運用移行後のトラブル切り分け責任が、発注者側／受注者側／第三者製品側で明確化されているか

これらのチェックリストを、案件開始時・RFP公告前・契約締結前・稼働開始前の各タイミングで自己点検することで、公平性・透明性を担保しつつ品質を確保する調達設計の姿勢を組織として維持できます。

自治体・公共機関のシステム開発外注は、民間発注とは異なる制約下で、必要な品質を確保する調達設計の技能が求められる領域です。「制約が多いから難しい」のではなく、「制約を理解した上で判断軸を組み立てれば、説明責任を果たしつつ品質確保が可能になる」というのが本記事の一貫したメッセージでした。前任者からの引き継ぎで実務経験が浅い担当者であっても、本記事で示した判断フレームワークとチェックリストを起点に、自庁の案件を客観的に評価・設計する第一歩を踏み出してみてください。