トップ ／ コラム ／ 自治体のシステム調達

自治体・官公庁のシステム調達で発注側が用意するもの｜仕様書が書けないときの進め方

システムを入れ替えたいが、仕様書が書けない。自治体・官公庁のご担当者から、よく伺うご相談です。公募やプロポーザルにかけるには仕様書が要る。けれど仕様書を書くには、どんなシステムができるのかが分かっていないと書けない。この順番で詰まります。

ただ、詰まっているのは書く力の問題ではありません。仕様書の材料は、たいてい庁内にすでにあります。住民からの問い合わせの記録、いま使っている様式、過去に取った調査、条例や要綱で決まっている条件。仕様書の形になっていないだけで、中身としてはそろっています。

このページでは、調達の前に発注側で用意できるもの、公募の仕様書に書くこと・書かないこと、庁内で先に決めておくことを整理します。費用の目安は業務システムの開発費用はいくらかかるのかに分けています。

「仕様書を先に書く」という順番でつまずく

調達の手続きは、仕様書を作り、予算を確保し、公募または入札にかけ、契約する、という順番で進みます。手続きとしては、この順番しかありません。問題はその最初にあります。

仕様書に書くのは「何を作るか」です。ところが何を作るかは、業務を細かく見ていくうちに決まっていくもので、手続きの最初の時点では決まっていません。そこで多くの場合、前回の仕様書を書き換えるか、事業者から参考見積りとあわせて仕様書の案をもらうことで、形を整えることになります。

前回の仕様書を使うと、前回と同じ規模のものが出てきます。事業者に案を作ってもらうと、その事業者が作りやすい形になります。どちらも手続きは通りますが、いま困っていることが仕様に入っているかどうかは、別の話です。

発注側がすでに持っている材料は、だいたいこの5つ

新しく調べ直すところから始める必要はありません。次の5つは、たいていどこかの課に残っています。

この5つのうち、3つめの調査データは見落とされやすいところです。

pegが官公庁の入札案件として構築した、予防接種に関するLINE上のAIチャットで材料にしたのは、仕様書ではなく、保護者の意識や不安に関する調査データと、ご担当者へのヒアリングでした。調査データには、保護者が実際にどんなことに不安を感じているかが表れています。そこから、AIチャットが答えるべき内容と、答え方の方針を組み立てました。

その調査は、施策を検討するために取ったもので、システムのために取ったものではありません。それでも、何に答える仕組みが要るかを決める材料としては十分でした。すでにある資料が使えるかどうかは、取った目的ではなく中身で決まります。

「一式」で出すと、落札後に中身を決めることになる

材料をそろえずに公募にかけると、仕様書は「業務システム一式」に近い書き方になります。手続きとしては成立しますが、そのあとに次のことが起きます。

1. 事業者が決まる。範囲が決まっていないので、契約したあとの打ち合わせで中身を決めることになります。
2. 現場の課から要望が出てくる。仕様書に書かれていなかった要望が、打ち合わせの場で初めて出てきます。
3. 範囲かどうかの話になる。書かれていないものは、追加なのか当然含まれるのか、解釈の話になります。
4. 年度の期限が近づく。判断が付かないまま時間が過ぎ、決まっている部分から作り始めることになります。
5. とりあえず動くものが納品される。いちばん困っていたことは、次の更新に回ります。

この流れは、事業者の姿勢とは関係なく起きます。何を作るかが決まっていない契約では、決める作業そのものが契約に入っていないからです。

逆に、範囲が書かれていれば提案の比べ方も変わります。各社に同じ条件を渡していれば、出てくる提案は比べられる形になります。比べ方は複数の開発会社から提案をもらうときの比べ方に書いています。

仕様書に書くこと・書かないこと

細かく書けば書くほど安全、とは限りません。画面の作り方や使う技術まで書き込むと、提案の幅がなくなり、結果として前回と同じものが出てきます。書くところと、あえて書かないところを分けます。

3つめの「変えてはいけない条件」は、必ず書いておきます。制度で決まっている判定は、あとから変わるからです。

pegが構築したドローン操縦士協会の講習・実技管理では、実技が10時間に満たない受講者は修了にできない、要件を満たしていない講師の記録は登録できない、という判定をシステム側の条件として持たせました。判定がシステムの中にあると、制度が変わったときに直す場所が決まります。職員が毎回、手元の表と見比べて確認する形にしておくと、制度が変わったことに気づけるかどうかが担当者しだいになります。

自治体の業務では、制度改正は必ず来ます。来ることが分かっているものは、仕様書に条件として書いておきます。

庁内で先に決めておく3つのこと

事業者に聞かれて止まるのは、たいていこの3つです。どれも庁内でしか決められません。

• 誰が決めるのか（決裁の線）。画面の項目を一つ変えるのに決裁が要るのか、担当者で決めてよいのか。ここが決まっていないと、試作画面を見ていただいても返事が返ってこず、作業が止まります。担当者で決める範囲と、決裁に上げる範囲を先に線引きしておきます。
• 個人情報をどう扱うか。どのデータを事業者に渡すのか、渡さずに庁内で作業するのか。置き場所の指定も、庁内の規程と所管課の判断で決まります。pegは法律事務所ではありませんので、最終的な判断は所管課と顧問の弁護士にご確認ください。委託するときの確認項目は会員名簿を外部のシステム会社に渡して大丈夫かに整理しています。
• 年度の区切りをどう置くか。単年度で全部を納品するのか、設計と構築を分けるのか。期限を年度末に置くと、テストの期間が最後に圧縮されます。切り替えを4月に合わせる必要があるのかどうかは、業務によって違います。

3つめの年度については、いつまでにではなく「なぜその時期なのか」を書いておくと、無理のない工程の提案が出てきます。期限の理由が制度改正やサポート終了であれば動かせませんが、慣例であれば調整の余地があります。サポート終了を理由に動くときの考え方はOS・ソフトのサポート終了で業務システムを更新するときの進め方に書いています。

調達までの進め方6ステップ

1. 材料を集める。前の章の5つを、課をまたいで集めます。新しく作るものはありません。あるものを1か所に置くだけです。
2. 業務の名前で一覧にする。機能の名前ではなく、いまやっている業務の名前で並べます。範囲に入れるものと入れないものを分けます。
3. 変えてはいけない条件を書き出す。条例・要綱・国の制度で決まっている判定を、所管課に確認して一覧にします。
4. 決裁の線と個人情報の扱いを決める。庁内で決めることを先に片付けます。ここが残っていると、契約したあとに止まります。
5. 公募の前に、複数の事業者に話を聞く。参考見積りや情報提供の依頼として伺います。この段階でできることの幅が分かるので、仕様書に書きすぎずに済みます。進め方は庁内の規程と調達の担当課の判断に合わせてください。
6. 仕様書にまとめる。1から5をそのまま項目に置き換えます。書くところと書かないところは、前の章の表のとおりです。

1から4までは、事業者に頼まなくても進められます。この4つが終わっていれば、仕様書は前回の写しにはなりません。

手元で整理するための雛形として、提案依頼書（RFP）のテンプレートとヒアリングシートを公開しています。公募の仕様書そのものの様式は庁内の規程に合わせていただく必要がありますが、中身を考える順番は同じです。いまの状況から次の一手を確かめたい場合は簡易診断もお使いいただけます。

pegのやり方

pegは、仕様書がそろっていない段階からのご相談を前提にしています。

• 業務のヒアリングから始めます。機能の一覧からは入りません。日本眼科医会の会員管理システムでは、大手ベンダーから前のシステムと同じ規模の刷新提案が出ていましたが、事務局の業務を伺うところから始めて、必要な範囲を先に決めました。
• 試作画面で見え方を確認してから、中身の開発に入ります。画面を見ていただくと、資料には出てこなかった例外が出てきます。決裁に上げる判断も、画面があるほうが早く進みます。
• すでにある資料を材料にします。調査データ、様式、問い合わせの記録。新しく調べ直すところからは始めません。
• 納品物を契約に明記します。プログラム、設計資料、管理者権限を納品物として契約に書きます。担当者が替わっても引き継げる形にしておくためです。
• 必ず2名以上で担当し、引き継ぎ資料を最新に保ちます。自治体の案件では担当課の異動があります。事業者側の担当が1名だと、どちらかが替わった時点で経緯が消えます。
• 納品後3か月の無償の不具合対応を契約に明記します。切り替えた直後にしか出てこない不具合があるためです。

データの整理や、職員によるテストは、発注側で担っていただくことがあります。そのほうが人工（にんく）を抑えられるためです。範囲と条件が合わない場合は、追加のご相談をするか、お断りすることもあります。無理にお受けして途中で止めるより、先に申し上げるほうが確かだと考えています。

納品したあとの分担は業務システムの保守・運用は誰がやるのかに、移行の詰まりどころは業務システムの入れ替えでデータ移行が詰まる5つのことに書いています。職員に使ってもらうための研修とマニュアルは新しい業務システムを職員に使ってもらうにはをご覧ください。

よくあるご質問