自治体のシステム調達、慣れないRFP・仕様書づくりで迷ったら｜公示前に確認する7つの観点

その仕様書、公示する前に。仕様書・RFP案を公示前にチェックし、入札には参加しない第三者としてレビューする流れ

自治体のシステム調達では、仕様書やRFP（提案依頼書）を公示した瞬間から、中身を直しにくくなります。公示後の修正は、質問回答や仕様変更の手続きを伴い、スケジュールにも響きます。そして、公示前に見落とした一文は、入札不調、契約後の追加費用、何年も続くベンダーロックインといった形で、あとから返ってきます。

特に、異動で初めてシステム調達を任された、情報システムの専任がいない、前回の調達から何年も空いている——そんな状況で慣れないRFPや入札の仕様書を作っている方に向けて書いています。

この記事では、仕様書・RFP案を公示前に確認しておきたい7つの観点と、利害関係のない第三者にレビューを頼むときの考え方を、受託開発の現場にいる立場から整理します。

1. なぜ「公示前」なのか

システム調達の失敗は、多くの場合、開発が始まってからではなく仕様書を書いた時点で決まっています。

公示後に仕様を変えるには、手続きと時間がかかる
入札・提案を受けてから「実は要件が足りなかった」と気づいても、同じ条件で比較し直すのは難しい
契約後に見つかった要件の抜けは、**追加費用（変更契約）**として処理されることが多い

逆に言えば、公示前の数週間は、最も安く、最も確実に直せる期間です。

2. 公示前に確認したい7つの観点

#	観点	見落とすと起きること
1	目的と範囲が書けているか	業者ごとに解釈が割れ、提案が比較できない
2	要件の粒度がそろっているか	見積もりの前提がそろわず、価格差の理由が読めない
3	特定の製品・事業者に寄った記述がないか	参加者が限られ、競争が働かない
4	工期は実現できる長さか	入札不調、または品質を削った納品
5	予算の見立ては妥当か	不調・辞退、あるいは過大な予定価格
6	データと契約終了時の扱いが決まっているか	次の更改で乗り換えられない（ロックイン）
7	運用・保守まで書けているか	稼働後の費用が読めず、毎年の予算が膨らむ

① 目的と範囲 — 「何を解決するか」が一文で書けているか

「〇〇システムの更改」だけでは、事業者は何を重視すべきか判断できません。何の業務の、どの困りごとを、どこまで解決するのか。対象外の業務も明記しておくと、提案の比較がしやすくなります。

② 要件の粒度 — 詳しい所と薄い所が混ざっていないか

画面の項目まで細かく書いてある一方で、帳票・外部連携・データ移行が一行しかない、という仕様書はよく見かけます。薄い部分は、事業者ごとに見積もりの前提が変わる部分です。価格差が大きいとき、その理由の多くはここにあります。

③ 特定の製品・事業者に寄った記述

現行システムの資料や、特定の事業者の提案書を下敷きにすると、意図せずその製品でしか満たせない表現が紛れ込みます。機能の名前ではなく「何ができればよいか」で書けているかを確認します。

近隣の自治体の仕様書を参考にするのは、限られた人員で進めるうえで現実的なやり方です。ただし、そのまま写すと、前の案件で選ばれた製品の前提まで一緒に写してしまうことがあります。自分の自治体に合わせて書き直すべき箇所を見極めます。

④ 工期 — 移行・テスト・研修の時間が入っているか

開発期間だけで工期を組むと、データ移行、職員の受入テスト、研修、年度末の繁忙期が抜けがちです。現実的でない工期は、入札不調か、品質を削った納品のどちらかになりやすいです。

⑤ 予算の見立て — 参考見積もりの前提をそろえたか

参考見積もりを複数取っても、前提がそろっていなければ比較になりません。何人月の、どの範囲の作業を想定しているかを見比べると、過大・過小のどちらにも気づけます。

⑥ データと契約終了時の扱い — 次の更改で乗り換えられるか

ベンダーロックインは、契約後ではなく仕様書の段階で生まれます。データを標準的な形式で出せること、ドキュメントの納品、契約終了時の引き継ぎ協力を、あらかじめ要件にしておきます。

⑦ 運用・保守 — 稼働後の費用まで読めるか

初期費用だけを比べると、保守料・ライセンス更新・制度改正への対応費で、数年後に逆転することがあります。5年程度の総額で比べられるよう、運用・保守の範囲と条件を書いておきます。

3. 担当者だけで抱え込みやすい理由

こうした確認は、本来は発注する側で行うものです。ただ、現実には次のような事情があります。

情報システムの担当が少人数で、異動も多い
前回の調達から数年空いていて、経験が引き継がれていない
事業者に相談すると、その事業者に有利な内容になりやすい（相談した事業者が入札に参加する可能性がある）

最後の点が、特に悩ましいところです。技術的なことを聞ける相手ほど、その案件の受注候補でもあるからです。

4. 第三者レビューを頼むときの3つの条件

外部に仕様書のレビューを頼むなら、少なくとも次の3点を確認しておくと安心です。

その案件の入札・提案に参加しないこと（利益相反がない）
受託開発の実務を知っていること（見積もり・工期・移行の現実が分かる）
特定の製品を売っていないこと（製品寄りの助言にならない）

5. SIAのスポット契約（公示前レビュー）

SIAは、CTO顧問サービスの一つとして、市町村など自治体の入札・公募の前に、仕様書・要件・RFP案をレビューするスポット契約をお受けしています。

仕様書・要件・RFP案の妥当性レビュー
技術的な実現性・工期・予算感の評価
支援した案件の本体入札には参加しません（中立性の担保）
料金は 50万円（税別）〜。案件の規模・調査範囲に応じて都度お見積もり
対応は基本的にリモート（オンライン会議・メール・書面）。遠方の自治体でも、移動の時間や費用はかかりません
単発のご契約で、最低契約期間はありません

特にお役に立ちやすいのは、次のような場面です。

情報システムの専任がいない、または少人数の市町村
初めて、あるいは久しぶりにRFP・仕様書を作る
近隣の自治体の仕様書を参考にしながら、比較的コンパクトな調達を形にしたい

案件の規模や内容によっては、ご相談のうえで、お手伝いできる範囲を一緒に決めさせていただきます。

現在も、ある町の協議会で、キャッシュレスシステム導入に向けた仕様書づくりをアドバイザーとして支援しています。近隣の町の仕様書を下敷きにした案の整理、県が整備するデータ連携基盤との整合、事業者の選定基準の確認など、公示前の段階から関わっています。

私たちは、2003年の創業以来、製造・物流・小売・自治体など100件を超えるシステムを受託開発してきました。見積もる側・作る側の事情を知っていることが、このレビューのいちばんの強みです。

6. まとめ

システム調達の失敗は、仕様書を書いた時点でほぼ決まる。公示前が、最も安く確実に直せる期間
確認したいのは、目的と範囲・要件の粒度・特定事業者への偏り・工期・予算・データと契約終了時の扱い・運用保守の7点
ベンダーロックインは、契約後ではなく仕様書の段階で生まれる
外部に頼むなら、入札に参加しない・実務を知っている・製品を売っていない第三者を選ぶ
初めてのRFPでも、公示前に一度「外の目」を入れるだけで防げる失敗は多い

▶ CTO顧問サービス — スポット契約（発注前レビュー・自治体・官公庁向け） ▶ まずはDXセルフチェック（無料・個人情報入力不要） ▶ お問い合わせ（CTO顧問・スポット契約のご相談）